avivo chips

Copied from pre-avivo code.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Board is DVI+VGA, not DVI+DVI
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

R4xx cards don't have lvds pll dividers since they use atom.

should fix rh bug 541562
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Acked-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Unit typo noticed by taiu on IRC
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The locking & protection of radeon object was somewhat messy.
This patch completely rework it to now use ttm reserve as a
protection for the radeon object structure member. It also
shrink down the various radeon object structure by removing
field which were redondant with the ttm information. Last it
converts few simple functions to inline which should with
performances.

airlied: rebase on top of r600 and other changes.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We really don't need to process every irq that comes in, we only
really want to do SW irq processing when we are actually waiting for
a fence to pass. I'm not 100% sure this is race free esp on non-MSI systems
so it needs some testing.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This enables the use of interrupts on r6xx/r7xx hardware.
Interrupts are implemented via a ring buffer.  The GPU adds
interrupts vectors to the ring and the host reads them off
in the interrupt handler.  The interrupt controller requires
firmware like the CP.  This firmware must be installed and
accessble to the firmware loader for interrupts to function.

MSIs don't seem to work on my RS780.  They work fine on all
my discrete cards.  I'm not sure about other RS780s or
RS880s.  I've disabled MSIs on RS780 and RS880, but it would
probably be worth checking on some other systems.

v2 - fix some checkpatch.pl problems;
     re-read the disp int status reg if we restart the ih;

v3 - remove the irq handler if r600_irq_init() fails;
     remove spinlock in r600_ih_ring_fini();
     move ih rb overflow check to r600_get_ih_wptr();
     move irq ack to separate function;
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

found while working on displayport.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Don't overwritte  crtc_gen_cntl or crtc_gen_cntl2 or we may loose the
cursor. This especialy happen when changing video mode. Fix bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=529146Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Lets user select tv-standard.  The property was there,
just not hooked up.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If we find a GPU but we can't find its BIOS and it isn't posted,
then ignore it.
Signed-off-by: NDave Airlie <airlied@redhat.com>

If the chip isn't initialised properly this can happen.
also fix return value in combios clocks function.
Signed-off-by: NDave Airlie <airlied@redhat.com>

sync polarity, etc.  This will likely fix LVDS problems
on some laptops.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

On IGP if you pass option agpmode=-1 you would overwrite the set_page
function callback with improper function which endup in non functioning
hw. This patch will disable agp when giving agpmode=-1 parameter only
if we are dealing with an AGP GPU.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Reconfiguring one CRTC whilst another is running can cause a hang under
some circumstances. Unfortunately we haven't pinpointed exactly what those
circumstances are, so disable all CRTCs for every mode switch.
Signed-off-by: NPierre Ossman <pierre@ossman.eu>
Acked-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

R4xx mobility chips use atombios, which does not store
the LVDS_GEN_CNTL parameter setup like combios.  Rather,
it's configured in LVDSEncoderControl.  As such,
LVDS_GEN_CNTL is set wrong when on resume.  Call
LVDSEncoderControl to set it properly.

Should fix fdo bug 25336
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

rendercheck under kms on r600s was failing due to HDP flushing not happening.

This adds HDP flushing to the object wait function for r100->r700 families.

rendercheck passes basic tests on r600 with this change.
Acked-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch varies from the original and just removes memory for kernel
pinned objects.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

making the pinned console smaller gives X a bit more room to play with.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The RN50 really needs this since its a single crtc card,
however other gpus may benefit from it as well.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Just do nothing if crct_set_base() is called with no FB.

The oops happens when the user switches between X & vt or in some case
when changing mode.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

doesn't have a tv-out port
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some systems have multiple connectors connected to the same encoder;
e.g., DVI and HDMI connected to the same encoder with the same ddc
line. Since we expose connectors as xrandr outputs, randr treats them
separately which results in it trying to source the same encoder to
different crtcs. If we have an HDMI and DVI-D port on the same encoder,
pick the one to be considered connected based on the edid (HDMI if edid
indicates HDMI, DVI otherwise).

Should fix fdo bug 25150
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

DVI-I port is actually DVI-D
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Keep requested scaler type in radeon_encoder
and the actual scaler type used in radeon_crtc.
This prevents us from enabling the scaler when it's
not required (i.e., the requested mode is the native
mode).  Also, always set the adjusted mode equal
to the native mode for lvds.

Should fix:
https://bugzilla.redhat.com/show_bug.cgi?id=522271Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Acked-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Call to set active device was missing.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We might not hit this yet, but when if we do any sort of writeback
we really need to enable PCI bus mastering on these systems from
what I can see.

This enables PCI BM on all radeons that require it.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This enables initialization of external tmds chips on pre-atom
and mac systems.  Macs are untested.  Also, some macs have single
link tmds chips while others have dual link tmds chips.  We need
to figure out which ones have which.

This gets external TMDS working on my RS485 and RV380.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- Change reg/mask names to match what we use internally
and in the bios
- Clarify how i2c over gpio on radeon actually works
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We need this for supporting things other than ddc on i2c.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The driver requires shmfs as the backing filesystem to handle the buffer
objects, so ensure it is selected if the user chooses to build our
driver.

Fixes: Bug 14662 - Dell E5500 kernel panic with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=14662

The revealing nature of the panic is the NULL function pointer
dereference in read_cache_page_async().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: NMateusz Kaduk <mateusz.kaduk@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Cc: stable@kernel.org

For CRT hotplug detect status, we have four test results as blue
channel only, green channel only, both blue and green channel, and
no channel attached. Origin code only marks both blue and green channel
case as connected, but ignore other possible connected states. This one
trys to detect CRT by checking no channel attached case instead.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

When the framebuffer driver does not publish detailed timing information
for the current video mode, the correct value for the pixclock field is
zero, not -1.

Since pixclock is actually unsigned, the value -1 would be interpreted
as 4294967295 picoseconds (i.e., about 4 milliseconds) by
register_framebuffer() and userspace programs.

This patch allows X.org's fbdev driver to work.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Tested-by: NPaulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some architectures compute ->vm_page_prot depending on ->vm_flags, so we
need to update the protections after adjusting the flags.

AFAIK this only affects running X under Xen; without this patch you get
lots of coloured blobs on the screen, or maybe a complete lockup.  Or
anything really.

But that still depends on lots of out-of-tree stuff, so I don't think
there are any consequences for anyone else.  But it is wrong in principle.
Reported-by: NJan Beulich <JBeulich@novell.com>
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

On broken EDID we were reporting vga connector to be disconnected
even if ddc probe did found a monitor. This patch report that the
connector is connected on such case. This allow drm to add a fail
safe mode (800x600 at the time of this patch) thus user can boot
and later add a mode which match its monitor capabilities.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

unused_nodes modification needs to be protected by unused_lock spinlock.
Here is an example of an usage where there is no such protection without
this patch.

  Process 1: 1-drm_mm_pre_get(this function modify unused_nodes list)
             2-spin_lock(spinlock protecting mm struct)
             3-drm_mm_put_block(this function might modify unused_nodes
               list but doesn't protect modification with unused_lock)
             4-spin_unlock(spinlock protecting mm struct)
  Process2:  1-drm_mm_pre_get(this function modify unused_nodes list)
At this point Process1 & Process2 might both be doing modification to
unused_nodes list. This patch add unused_lock protection into
drm_mm_put_block to avoid such issue.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

RS400,RC410,RS480 chipset seems to report a lot of false positive
with load detect on TV output. We haven't yet found a way to make
load detect reliable on those chipset, thus just disable it for TV
output. Would avoid user to experience phantom screen because X
believe there is a monitor connected to the TV output.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes RH bugzilla #527874.

On resume the atom posting wasn't working, however vbe posting was
going fine, after 2 weeks over irc, and 8 hrs with the hardware,
I tracked it down to the memory device table and it access the MC
registers via IIO, it appears the rv515 atom iio table might not
be fully functional, so adding a readback before doing a write
either provides enough delay to make things resume correctly.

Thanks to Peng Huang at Red Hat for coming to Brisbane.
Signed-off-by: NDave Airlie <airlied@redhat.com>