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>

DPM seems to be stable on these asics and it drastically
improves performance depending on the boot clocks.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Avoids spamming the system log for chips where dpm is enabled by
default, but prints then messages when users force it on for other
asics.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Currently radeon devices are not properly shutdown during kexec. This
causes a varity of issues, e.g. dpm initialization failures.
Fix this by implementing a radeon_pci_shutdown function, that unloads
the driver cleanly.
Signed-off-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Needed by the hda driver to properly set up synchronization
on the audio side.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

Needed by the hda driver to properly set up synchronization
on the audio side.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

No need to continue with the loops once we've matched
the appropriate connector.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The plain [EN|DIS]ABLE functions do the same thing and more
and aren't broken on some systems like [EN|DIS]ABLE_OUTPUT.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The plain [EN|DIS]ABLE functions do the same thing and more
and aren't broken on some systems like [EN|DIS]ABLE_OUTPUT.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

On SI asics, the SMC will automatically force the performance
level to the lowest level if there are no displays active.  This
prevents automatic performance scaling on PowerXpress systems or
for offscreen rendering or compute when displays are disabled.

Going forward, it would be best to dynamically change this, but
for now leave scaling enabled.

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

Uses the CP ring rather than the DMA ring.  Useful
for debugging and benchmarking.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The rv6xx_clocks_per_unit() function pretends it can set flags in a u64
bitfield but really because "1" is an int it doesn't work for more than
32 bits.  The only caller truncates the high bits away anyway.  I've
just changed it to be a u32.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Uses CP DMA packet just like previous asics.
Useful for debugging and benchmarking.  Uses
same packet format as prior asics.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Seems to be stable enough for the majority of users.
It can be disabled on the fly via connector attributes.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This hooks radeon up to the runtime PM system to enable
dynamic power management for secondary GPUs in switchable
and powerxpress laptops.

v2: agd5f: clean up, add module parameter
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This is a pre-requisite for runtime pm on powerxpress systems.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Allows you to enable dither in the display hardware
when the monitor supports lower a lower bpc than the
current framebuffer format.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The FMT blocks control how data is sent from the backend
of the display pipe to to monitor.  Proper set up of the
FMT blocks are required for 30bpp formats.  Additionally,
dithering can be enabled on for better display with 18 and
24bpp displays.  The exception is LVDS/eDP which atom
takes care of in the SelectCRTC_Source table.  For now
just enable truncation until we test dithering more.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

device_unregister() already drops its reference to the struct device, so
explicitly calling put_device() before device_unregister() can cause the
device to have been freed before it can be unregistered.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

To disable a monitor, a Spice client sends a monitor config with the
monitor resolution to 0x0.

However, before qxl_crtc_disable() is reached after the hotplug event,
it can happen that another monitor is reconfigured, and
qxl_send_monitors_config() is called with the old config, which will
re-enable the monitor on the client.

Reset config if monitor is found disconnected, during
drm_helper_hpd_irq_event().
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

All hard-coded resolutions are passing this check.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

By default, 1024x768 is the preferred resolution. However, when a
monitor config is given, it should be the only preferred resolution.

Note that the monitor config resolution is passed to
qxl_add_common_modes() to avoid adding a duplicate mode without the
preferred resolution. That would discard the previous monitor config
preferred bit.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In commit 38d5487d, Keith explained:
    This patch simply merges the two mode type bits together; that seems
    reasonable to me, but perhaps only a subset of the bits should be
    used? None of these can be user defined as they all come from
    looking at just the hardware.

However, merging the bits means that a flag becomes sticky. It is not
possible, for example to update the mode type to remove the
DRM_MODE_TYPE_PREFERRED bit.

After a brief discussion with Dave Airlie on irc, it was agreed to
propose that change, instead of introducing another function to remove a
bit from exisiting modes type.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>