Fill in gpu details for hawaii.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Uses the same code as bonaire.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This updates atombios.h with the latest changes
required for hawaii.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Set the PA_SC_RASTER_CONFIG[_1] registers for hawaii.
The rest is the same as the other asics.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This updates the CI dpm (dynamic power management)
support for hawaii.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Has same version of UVD as other CIK parts.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This just updates the firmware loading functions
to look for the appropriate firmware files for
hawaii.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The formula needs to be adjusted since there are 4 RBs
per SH rather than 2 as on previous asics.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The golden register settings are optimal settings for
certain registers from the hardware team.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Hawaii uses a different tiling configuration.  Add support
for it.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Skip programming a register that was removed and
adjust the mask of the VM client status.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This adds the hawaii asic specific configuration
details.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Hawaii is a new CI-based dGPU.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Spotted by Brad Smith when porting to OpenBSD.
Noticed-by: NBrad Smith <brad@comstyle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The new HDP flush method doesn't seem to work reliably on
sDMA either, so use the old method here too.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

To plug the VRAM memory leak (see previous patch for
details) we must unpin the frame buffer when disabling the
CRTC. This warrants the addition of disable function for legacy
CRTC, which puts the CRTC in DPMS-OFF state and unpins the
frame buffer if there is one associated with the CRTC.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

When drm_helper_disable_unused_functions calls disable
function of the CRTC, it also sets the crtc->fb pointer
to NULL. This can later (when the mode on that CRTC is setup
again from user space) cause ***_do_set_base functions to
"think" that there is no old buffer and skip the unpinning
code. Consequently, the buffer that has been NULL-ified in
drm_helper_disable_unused_functions will never be unpinned
causing a leak in VRAM.

This patch plugs the leak by unpinning the frame buffer
in crtc_disable function.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The current code writing SADs to the audio registers seems to assume
that there is at most a single SAD per audio format.

However, that is not the case. Especially for PCM it is somewhat common
for sinks to have two SADs, one for 8-channel and one for 2-channel
audio, which may have different supported sample rates (i.e. the sink
supports stereo audio at higher sample rates than multichannel audio).

Because of this, only the 2-channel SAD may be used if it appears before
the 8-channel SAD. Unless other SADs require otherwise, this may cause
the ALSA HDA driver to allow stereo playback only.

Fix the code to pick the PCM SAD with the highest number of channels,
while merging the rate masks of PCM SADs with lower amount of channels
into the additional stereo rate mask byte.

Technically there are even more cases to handle (multiple non-PCM SADs
of the same type, more than two PCM SADs with varying channel counts,
etc), but those have not actually been encountered in the field and
handling them would be non-trivial.

Example affected EDID from Onkyo TX-SR674 specifying 192kHz stereo
support and 96kHz 8-channel support (and other 8-channel compressed
formats):
00ffffffffffff003dcb010000000001
ffff0103800000780a0dc9a057479827
12484c00000001010101010101010101
010101010101011d8018711c1620582c
2500c48e2100009e011d007251d01e20
6e285500c48e2100001e000000fc0054
582d53523637342020202020000000fd
00313d0f2e08000a202020202020019b
02032f724f8504030f0e07069413121e
1d1615012f097f070f1f071707503707
503f07c0834f000066030c00ffff808c
0ad08a20e02d10103e9600c48e210000
18011d80d0721c1620102c2580c48e21
00009e011d00bc52d01e20b8285540c4
8e2100001e8c0ad090204031200c4055
00c48e210000180000000000000000a8
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Tested-by: NAndre Heider <a.heider@gmail.com>
Cc: Rafał Miłecki <zajec5@gmail.com>
Acked-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Don't block forever if there is nothing to wait for.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Tested-by: NRafa? Mi?ecki <zajec5@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Let's be a bit more consistent with our error values.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Move the ktime_get() clock readouts and potential preempt_disable()
calls from drm core into kms driver to make it compatible with the
api changes in the drm core.

This should not introduce any change in functionality or behaviour
in radeon-kms, just a reshuffling of code.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Sharing PPLLs seems to cause problems on some boards.

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

PPSMC_EXTRAFLAGS_AC2DC_GPIO5_POLARITY_HIGH should be
set in extraFlags, not systemFlags.
Noticed-by: NSylvain BERTRAND <sylware@legeek.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

op 08-10-13 18:58, Thomas Hellstrom schreef:
> On 10/08/2013 06:47 PM, Jerome Glisse wrote:
>> On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote:
>>> On 10/08/2013 04:55 PM, Jerome Glisse wrote:
>>>> On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
>>>>> Am 08.10.2013 16:33, schrieb Jerome Glisse:
>>>>>> On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
>>>>>>> Allocate and copy all kernel memory before doing reservations. This prevents a locking
>>>>>>> inversion between mmap_sem and reservation_class, and allows us to drop the trylocking
>>>>>>> in ttm_bo_vm_fault without upsetting lockdep.
>>>>>>>
>>>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
>>>>>> I would say NAK. Current code only allocate temporary page in AGP case.
>>>>>> So AGP case is userspace -> temp page -> cs checker -> radeon ib.
>>>>>>
>>>>>> Non AGP is directly memcpy to radeon IB.
>>>>>>
>>>>>> Your patch allocate memory memcpy userspace to it and it will then be
>>>>>> memcpy to IB. Which means you introduce an extra memcpy in the process
>>>>>> not something we want.
>>>>> Totally agree. Additional to that there is no good reason to provide
>>>>> anything else than anonymous system memory to the CS ioctl, so the
>>>>> dependency between the mmap_sem and reservations are not really
>>>>> clear to me.
>>>>>
>>>>> Christian.
>>>> I think is that in other code path you take mmap_sem first then reserve
>>>> bo. But here we reserve bo and then we take mmap_sem because of copy
>>> >from user.
>>>> Cheers,
>>>> Jerome
>>>>
>>> Actually the log message is a little confusing. I think the mmap_sem
>>> locking inversion problem is orthogonal to what's being fixed here.

> >>> This patch fixes the possible recursive bo::reserve caused by
> >>> malicious user-space handing a pointer to ttm memory so that the ttm
> >>> fault handler is called when bos are already reserved. That may
> >>> cause a (possibly interruptible) livelock.

>>> Once that is fixed, we are free to choose the mmap_sem ->
>>> bo::reserve locking order. Currently it's bo::reserve->mmap_sem(),
>>> but the hack required in the ttm fault handler is admittedly a bit
>>> ugly.  The plan is to change the locking order to
>>> mmap_sem->bo::reserve

> >>> I'm not sure if it applies to this particular case, but it should be
> >>> possible to make sure that copy_from_user_inatomic() will always
> >>> succeed, by making sure the pages are present using
> >>> get_user_pages(), and release the pages after
> >>> copy_from_user_inatomic() is done. That way there's no need for a
> >>> double memcpy slowpath, but if the copied data is very fragmented I
> >>> guess the resulting code may look ugly. The get_user_pages()
> >>> function will return an error if it hits TTM pages.

>>> /Thomas
>> get_user_pages + copy_from_user_inatomic is overkill. We should just
>> do get_user_pages which fails with ttm memory and then use copy_highpage
>> helper.
>>
>> Cheers,
>> Jerome
> Yeah, it may well be that that's the preferred solution.
>
> /Thomas
>
I still disagree, and shuffled radeon_ib_get around to be called sooner.

How does the patch below look?
8<-------
Allocate and copy all kernel memory before doing reservations. This prevents a locking
inversion between mmap_sem and reservation_class, and allows us to drop the trylocking
in ttm_bo_vm_fault without upsetting lockdep.

Changes since v1:
- Kill extra memcpy for !AGP case.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Clear page tables after allocating them in case
we don't completely fill them later.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The DMA ring seems to be stable now.

v2: remove pt_ring_index as well
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT.
Consolidate the two wait sequence implementations into just one function.
Activate all waiters and remember if the reset was already done instead of
trying to reset from only one thread.

v2: clear reset flag earlier to avoid timeout in IB test
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It is said to cause hangs.
Signed-off-by: NMarek Olšák <marek.olsak@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The parameter is in bytes not dwords.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Make sure the UVD clocks are still active before sending
the destroy message, otherwise the hw might hang.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Typo in the register offset.
Noticed-by: NSylvain BERTRAND <sylware@legeek.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The buffers needs to be in little endian format.
Noticed-by: NSylvain BERTRAND <sylware@legeek.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If the user has forced the state high or low, retain that preference
even when we switch power states.

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

If the thermal state is active, we are in the lowest performance level
to cool down the chip.  Don't let the user force it higher.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Seems to be stable on them.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Seems to be stable on them.  There are still some issues
with the performance states staying in the highest levels
on certain cards when multiple monitors are attached, but
being that the the cards are always in their highest power
state at boot up anyway, this doesn't really change anything
and improves things in all other cases.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Seems to be stable on them.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Seems to be stable on them and improves peformance
as most SI asics have very low boot clocks.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>