Not really a nice way to split this up further for submission. This
provides all the DRM interfacing logic, the headers and relevant glue.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Again this might be a candidate for sharing later.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some of this should one day become a library shared by i915 and gma500 I
suspct. Best however to deal with that later once it is all nice and
stably merged.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The devices have various internal differences so we have some abstractions
to hide the ugly differences and we then wrap them up in standard
interfaces. Add these bits
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We support 2D acceleration on some devices but we try and do tricks with
the GTT as a starting point as this is far faster. The GTT logic could be
improved further but for most display sizes it already makes a pretty good
decision.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fits alongside the GEM support to manage our resources on the card
itself. It's not actually clear we need to configure the MMU at all.
Further research is needed before removing it entirely. For now we suck it
in (slightly abused) from the old semi-free driver.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The driver uses GEM along with a couple of small bits of wrapping of its
own. The only real oddity here is the support for using the 'stolen' memory
rather than wasting several MB.

We use a simple resource manager as we don't need to manage our space
intensively at all as we only do 2D work. We also have a GTT which is
entirely GPU facing so in the Cedarview case are not even allocating from
host address space.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This driver supports unaccelerated KMS display, and accelerated console
handling on the Intel Poulsbo, Oaktrail, Cedarview and Medfield hardware.

For the initial merge Medfield will be left out as it needs considerable
further work to reach a decent standard

Begin by adding the Makefiles and Kconfig. These are not yet plumbed into
the DRM layer so will have no effect on their own
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Enough to get cursors working under Wayland.
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Make it possible to use explicit placement
(although not hooked up with a user-space interface yet)
and relax the single framebuffer limit to only apply to implicit placement.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It isn't used for anything. Replace with an active bool.

Also make a couple of functions return void instead of int
since their return value wasn't checked anyway.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakbo Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Remove unused member.
No need to pin / unpin fb.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

After GPU lockup VRAM gart table is unpinned and thus its pointer
becomes unvalid. This patch move the unpin code to a common helper
function and set pointer to NULL so that page update code can check
if it should update GPU page table or not. That way bo still bound
to GART can be unbound (pci_unmap_page for all there page) properly
while there is no need to update the GPU page table.

V2 move the test for null gart out of the loop, small optimization
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Bail if we hit the timeout limit.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Supposedly both NUTMEG and TRAVIS should use the same
panel mode, but switching the panel mode for TRAVIS
gets things working.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41569Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Polarity needs to be set accordingly to connector status (connected
or disconnected). Set it up in hpd_init() so first hotplug works
reliably no matter what is the initial set of connector. hpd_init()
also covers resume so HPD will work correctly after resume as well.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Jerome Glisse <j.glisse@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Allow the user to override whether MSIs are enabled
or not on supported ASICs.  MSIs are disabled by default
on IGP chips as they tend not to work.  However certain
IGP chips only seem to work with MSIs enabled.

I suspect this is a chipset or bios issue, but I'm not sure
what the proper fix is.  This will at least make diagnosing
and working around the problem much easier.

See:
https://bugs.freedesktop.org/show_bug.cgi?id=37679Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some Dell laptops only seem to work with MSIs.  This
looks like a platform/bios bug.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=37679Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some HP laptops only seem to work with MSIs.  This
looks like a platform/bios bug.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=37679Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This makes it easier to add quirks for certain systems.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

We need to redefine a connector as "connected" if it matches a window
in the host preferred GUI layout.
Otherwise "smart" window managers would turn on Xorg outputs that we don't
want to be on.

This reinstates the update_layout and adds the following information to
the modesetting system.
a) Connection status <-> Equivalent to real hardware connection status
b) Preferred mode <-> Equivalent to real hardware reading EDID
c) Host window position <-> Equivalent to a real hardware scanout address
dynamic register.

It should be noted that there is no assumption here about what should be
displayed and where. Only how to access the host windows.

This also bumps minor to signal availability of the new IOCTL.

Based on code originally written by Jakob Bornecrantz
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Rather than having a quirk list just always check the EDID header
when probing.  This is the recommended behavior according to the
display team.  This avoids problems with improperly terminated
i2c lines on some boards.  This is also what the proprietary
driver does.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The function didn't work with DP, eDP, or DP bridge
connectors and thus confused users as it lead them to
believe nothing was connected or the EDID was invalid
when in fact is was, just on the aux bus rather an i2c.

It should also speed up module loading as it avoids a
bunch of extra DDC probing.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use the table version to determine which params to use.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

set up the params based on the table version number.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use table version numbers for param setup.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Leave the common code in radeon_encoders.c and move the atom
specific code to atombios_encoders.c.  This matches legacy
encoder setup and crtc setup.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The vram scratch was originally only used on some 7xx asics
to work around a hw bug.  Allocate the scratch page on all 6xx+
radeons and set the MC_VM_SYSTEM_APERTURE_DEFAULT_ADDR to point
to it.  We shouldn't ever hit it since we limit the system
aperture to vram or vram and AGP, but better safe than sorry.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

DP MST is DP multi-stream support, part of DP 1.2.

v2: switch to a helper macro as suggested by Michel.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The existing function was getting too big and complex.
Break it down into a more manageable set of functions.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use the regular logic for other bridge chips.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Return the encoder id rather than a boolean.  This is needed
for differentiate between multiple DP bridge chips.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

radeon_driver_irq_preinstall_kms and radeon_driver_irq_uninstall_kms
hard code the loop to 6 which happens to be the current maximum
number of crtcs and hpd pins; if one day an ASIC with more crtcs
(or hpd pins) comes out, this is a trouble waiting to happen.

introduce constants for maximum CRTC count, maximum HPD pins count
and maximum HDMI blocks count (per FIXME in radeon_irq structure)
and correct the loops in radeon_driver_irq_preinstall_kms and
radeon_driver_irq_uninstall_kms

v2: take care of goofs pointed out by Alex Deucher
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Cayman seems to be particularly sensitive to read cache returning
old data after bind/unbind to GTT. Flush read cache for GTT range
with each fences for all new hw. Should fix several rendering glitches.
Like

V2 flush whole address space
V3 also flush shader read cache

https://bugs.freedesktop.org/show_bug.cgi?id=40221
https://bugs.freedesktop.org/show_bug.cgi?id=38022
https://bugzilla.redhat.com/show_bug.cgi?id=738790Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>