This function is not limited to r100, but it can dump a
(raw) packet for any ASIC. Rename it accordingly and move
its declaration to radeon.h
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

WAIT_REG_MEM on register does not allow the use of PFP.
Enforce this restriction when checking packets sent from
userland.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

vline packet parsing function for R600 and Evergreen+ are
the same, except that they use different registers. Factor
out the algorithm into a common function that uses register
table passed from ASIC-specific caller.

This reduces ASIC-specific function to (trivial) setup
of register table and call into the common function.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Once we factored out radeon_cs_packet_parse function,
evergreen_cs_next_is_pkt3_nop and r600_cs_next_is_pkt3_nop
functions became identical, so they can be factored out
into a common function.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We now have a common radeon_cs_packet_parse function
that is good for all ASICs. Hook it up and eliminate
ASIC-specific versions.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

CS packet parse functions have a lot of in common across
all ASICs. Implement a common function and take care of
small differences between families inside the function.

This patch is a prep for major refactoring and consolidation
of CS parsing code.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Preparatory patch: patches to follow will touch a piece of code
that had broken indentication, so fix it before touching it.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

length_dw field was assigned twice. While at it, move user_ptr
assignment together with all other assignments to p->chunks[i]
structure to make the code more readable.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For large VM page table updates, we can sometimes generate
more packets than there is space on the ring.  This happens
more readily with the DMA ring since it is 64K (vs 1M for the
CP).  For now, switch back to the CP.  For the next kernel,
I have a patch to utilize IBs for VM PT updates which
alleviates this problem.

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

If the requested number of DWs on the ring is larger than
the size of the ring itself, return an error.

In testing with large VM updates, we've seen crashes when we
try and allocate more space on the ring than the total size
of the ring without checking.

This prevents the crash but for large VM updates or bo moves
of very large buffers, we will need to break the transaction
down into multiple batches.  I have patches to use IBs for
the next kernel.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

When kzalloc() failed in radeon_user_framebuffer_create(), need to
call object_unreference() to match the object_reference().
Signed-off-by: Nliu chuansheng <chuansheng.liu@intel.com>
Signed-off-by: Nxueminsu <xuemin.su@intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Some chips seem to need a little delay after blacking out
the MC before the requests actually stop. Stop DMAR errors
reported by Shuah Khan.
Reported-by: NShuah Khan <shuahkhan@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Some chips seem to need a little delay after blacking out
the MC before the requests actually stop.

May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
https://bugs.freedesktop.org/show_bug.cgi?id=57567Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Make sure at least one RB is enabled in
r6xx_remap_render_backend() to avoid an division by
zero in some corner cases.

See:
https://bugzilla.redhat.com/show_bug.cgi?id=892233Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Need to adjust the backend map depending on which
RB is enabled.

Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=892233Reported-by: NMikko Tiihonen <mikko.tiihonen@iki.fi>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

vbios says external TMDS while the board is actually
internal TMDS.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=60037Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Newer versions of mesa emit this.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Force the crtc mem requests on/off immediately rather
than waiting for the double buffered updates to kick in.
Seems we miss the update in certain conditions.  Also
handle the DCE6 case.
Signed-off-by: NChristopher Staite <chris@yourdreamnet.co.uk>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Fixes GPU hang during DMA ring IB test.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59672Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If one (but not both) allocations of p->chunks[].kpage[]
in radeon_cs_parser_init fail, the error path will free
the successfully allocated page, but leave a stale pointer
value in the kpage[] field. This will later cause a
double-free when radeon_cs_parser_fini is called.
This patch fixes the issue by forcing both pointers to NULL
after kfree in the error path.

The circumstances under which the problem happens are very
rare. The card must be AGP and the system must run out of
kmalloc area just at the right time so that one allocation
succeeds, while the other fails.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm_mode_addfb() expects fb_create return error code
instead of NULL.
Signed-off-by: Nxueminsu <xuemin.su@intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Aruba and newer gpu does not need the avivo cursor work around,
quite the opposite this work around lead to corruption.

agd5f: check DCE6 rather than ARUBA since the issue is DCE
version specific rather than family specific.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This reverts commit d025e9e2.

This causes corruption for a number of users and needs further
investigation in the next cycle.
https://bugzilla.kernel.org/show_bug.cgi?id=52491
https://bugs.freedesktop.org/show_bug.cgi?id=58659
http://lists.freedesktop.org/archives/dri-devel/2013-January/032961.htmlSigned-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Probably not a candidate for stable kernels because of conflicts
in DRM versioning.
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fixes a hard lock in the gpu reset code after the
rework for DMA support (0ecebb9e
"drm/radeon: switch to a finer grained reset for evergreen")
due to not bailing before the MC shutdown if the relevant engines
are idle.

Discussion:
http://lists.freedesktop.org/archives/dri-devel/2013-January/032985.htmlReported-by: NEldad Zack <eldad@fogrefinery.com>
Tested-by: NEldad Zack <eldad@fogrefinery.com>
Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We were checking the index against the size of the relocation buffer
instead of against the last index. This fix kernel segfault when
userspace submit ill formated command stream/relocation buffer pair.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Those rn50 chip are often connected to console remoting hw and load
detection often fails with those. Just don't try to load detect and
report connect.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Index into chunks[] array doesn't look right.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

parser->chunks[.].kpage[.] is not always kmalloc-ed
by the parser initialization, so parser_fini should
not try to kfree it if it didn't allocate it.

This patch fixes a kernel oops that can be provoked
in UMS mode.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

In UMS mode parser->rdev is NULL, so dereferencing
will cause an oops.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Increasing ref counts of both dma-buf and gem for imported dma-buf come from gem
makes memory leak. release function of dma-buf cannot be called because f_count
of dma-buf increased by importing gem and gem ref count cannot be decrease
because of exported dma-buf.

So I add dma_buf_put() for imported gem come from its own gem into each drivers
having prime_import and prime_export capabilities. With this, only gem ref
count is increased if importing gem exported from gem of same driver.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NKyungmin.park <kyungmin.park@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
configuration space is not restored correctly, resulting in MSI not working after switch.

Only useful item in dmesg is:

[   33.922807] radeon 0000:01:00.0: Refused to change power state, currently in D3

I did some testing, dumping the difference in ms between first succesful switch
from D3 to D0, and it seems that there is slightly more than 20 ms difference when
the device is re-enabled through vga-switcheroo.

So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not working
on my system after switcheroo-ing. Default d3_delay value is PCI_PM_D3_WAIT, 10 ms.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Was using the r7xx format.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

- r6xx actually uses a slightly different packet format,
although both formats seem to work ok.
- r7xx doesn't have the count multiple of 2 limitation.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

No change in functionality as we currently set all the reset
flags.

v2: fix typo
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

No change in functionality as we currently set all the reset
flags.
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

No change in functionality as we currently set all the reset
flags.
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

No change in functionality as we currently set all the reset
flags.
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>