GPU with low amount of ram can fails at pinning new framebuffer before
unpinning old one. On such failure, retry with unpinning old one before
pinning new one allowing to work around the issue. This is somewhat
ugly but only affect those old GPU we care about.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Useless to count the register index in number of bytes we are writing.
Fixes a regression with hw i2c enabled.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
With CONFIG_ACPI=n the following build warning is seen:
drivers/gpu/drm/radeon/cypress_dpm.c:302:31: warning: unused variable 'eg_pi' [-Wunused-variable]
Protect eg_pi with CONFIG_ACPI.
Based on patch from: Fabio Estevam <fabio.estevam@freescale.com>
but doesn't mix allocation and code.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
With CONFIG_ACPI=n the following build warning is seen:
drivers/gpu/drm/radeon/ni_dpm.c:3448:31: warning: unused variable 'eg_pi' [-Wunused-variable]
Move the definition of eg_pi inside the CONFIG_ACPI 'if' block.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This reverts commit 555b1b651a.
Let's try this again for 3.13. It's required for proper
interaction with alsa. Was disabled previously in 3.12
to be on the safe side since it caused problems on older
asics.
In order to have any realistic chance of calculating proper
ACR values, we need to be able to calculate both N and CTS,
not just CTS. We still aim for the ideal N as specified in
the HDMI spec though.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The values were taken from the HDMI spec, but they assumed
exact x/1.001 clocks. Since we round the clocks, we also need
to calculate different N and CTS values.
Note that the N for 25.2/1.001 MHz at 44.1 kHz audio is out of
spec. Hopefully this mode is rarely used and/or HDMI sinks
tolerate overly large values of N.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This just updates the firmware loading functions
to look for the appropriate firmware files for
hawaii.
Signed-off-by: Alex 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: Alex Deucher <alexander.deucher@amd.com>
The golden register settings are optimal settings for
certain registers from the hardware team.
Signed-off-by: Alex 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: Alex 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: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Alex 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: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Alex 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: Anssi Hannula <anssi.hannula@iki.fi>
Tested-by: Andre Heider <a.heider@gmail.com>
Cc: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Bit a bit -fixes pull request in the merge window than usual dua to two
feauture-y things:
- Display CRCs are now enabled on all platforms, including the odd DP case
on gm45/vlv. Since this is a testing-only feature it should ever hurt,
but I figured it'll help with regression-testing -fixes. So I left it
in and didn't postpone it to 3.14.
- Display power well refactoring from Imre. Would have caused major pain
conflict with the bdw stage 1 patches if I'd postpone this to -next.
It's only an relatively small interface rework, so shouldn't cause pain.
It's also been in my tree since almost 3 weeks already.
That accounts for about two thirds of the pull, otherwise just bugfixes:
- vlv backlight fix from Jesse/Jani
- vlv vblank timestamp fix from Jesse
- improved edp detection through vbt from Ville (fixes a vlv issue)
- eDP vdd fix from Paulo
- fixes for dvo lvds on i830M
- a few smaller things all over
Note: This contains a backmerge of v3.12. Since the -internal branch
always applied on top of -nightly I need that unified base to merge bdw
patches. So you'll get a conflict with radeon connector props when pulling
this (and nouveau/master will also conflict a bit when Ben doesn't
rebase). The backmerge itself only had conflicts in drm/i915.
There's also a tiny conflict between Jani's backlight fix and your sysfs
lifetime fix in drm-next.
* tag 'drm-intel-fixes-2013-11-07' of git://people.freedesktop.org/~danvet/drm-intel: (940 commits)
drm/i915/vlv: use per-pipe backlight controls v2
drm/i915: make backlight functions take a connector
drm/i915: move opregion asle request handling to a work queue
drm/i915/vlv: use PIPE_START_VBLANK interrupts on VLV
drm/i915: Make intel_dp_is_edp() less specific
drm/i915: Give names to the VBT child device type bits
drm/i915/vlv: enable HDA display audio for Valleyview2
drm/i915/dvo: call ->mode_set callback only when the port is running
drm/i915: avoid unclaimed registers when capturing the error state
drm/i915: Enable DP port CRC for the "auto" source on g4x/vlv
drm/i915: scramble reset support for DP port CRC on vlv
drm/i915: scramble reset support for DP port CRC on g4x
drm/i916: add "auto" pipe CRC source
...
Conflicts:
MAINTAINERS
drivers/gpu/drm/i915/intel_panel.c
drivers/gpu/drm/nouveau/core/subdev/mc/base.c
drivers/gpu/drm/radeon/atombios_encoders.c
drivers/gpu/drm/radeon/radeon_connectors.c
Don't block forever if there is nothing to wait for.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Rafa? Mi?ecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave 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: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I want to merge in the new Broadwell support as a late hw enabling
pull request. But since the internal branch was based upon our
drm-intel-nightly integration branch I need to resolve all the
oustanding conflicts in drm/i915 with a backmerge to make the 60+
patches apply properly.
We'll propably have some fun because Linus will come up with a
slightly different merge solution.
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_drv.c
drivers/gpu/drm/i915/intel_crt.c
drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_drv.h
All rather simple adjacent lines changed or partial backports from
-next to -fixes, with the exception of the thaw code in i915_dma.c.
That one needed a bit of shuffling to restore the intent.
Oh and the massive header file reordering in intel_drv.h is a bit
trouble. But not much.
v2: Also don't forget the fixup for the silent conflict that results
in compile fail ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PPSMC_EXTRAFLAGS_AC2DC_GPIO5_POLARITY_HIGH should be
set in extraFlags, not systemFlags.
Noticed-by: Sylvain BERTRAND <sylware@legeek.net>
Signed-off-by: Alex 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: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Clear page tables after allocating them in case
we don't completely fill them later.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The DMA ring seems to be stable now.
v2: remove pt_ring_index as well
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex 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: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It is said to cause hangs.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The parameter is in bytes not dwords.
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex 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: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Typo in the register offset.
Noticed-by: Sylvain BERTRAND <sylware@legeek.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The buffers needs to be in little endian format.
Noticed-by: Sylvain BERTRAND <sylware@legeek.net>
Signed-off-by: Alex 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=70654
Signed-off-by: Alex 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: Alex 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: Alex Deucher <alexander.deucher@amd.com>
Christian König