And use it in radeon to replace all the ioctls no longer valid in kms
mode. I plan to also use this later on when nuking the ums support for
i915.

Note that setting the function pointer in the ioctl table to NULL
would amount to the same, but that results in some debug output from
the drm_ioctl() function. I've figured it's cleaner to have a
special-purpose function.

Cc: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already express the drm/agp depencies correctly in Kconfig, so we
can rip this remnant from the shared drm core days.

Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
if ttm would provide dummy functions. I'm not going to volunteer for
that though.

v2: Use IS_ENABLED(CONFIG_AGP) as suggested by Ville

v3: Polish from Ville's review.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com> (v2)
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

linedur_ns, and especially pixeldur_ns are becoming rather inaccurate
to be used for the vblank timestamp correction. With 4k@60 the pixel
duration is already below 2ns, so the amount of error due to the
truncation to nanoseconds is introducing quite a bit of error.

We can avoid such problems if we instead calculate the timestamp
delta_ns directly from the dislay timings, avoiding the use of
these intermediate truncated values.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Squash in fixup from Thierry Reding for amdgpu.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Collect the timestamping constants alongside the rest of the relevant
stuff under drm_vblank_crtc.

We can now get rid of the 'refcrtc' parameter to
drm_calc_vbltimestamp_from_scanoutpos().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just adds the quirk for MSI R7 370 Armor 2X
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=91294Signed-off-by: NMaxim Sheviakov <mrader3940@yandex.ru>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

In

commit 7a3f3d66
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 9 23:44:28 2015 +0200

    drm: Check locking in drm_for_each_connector

I added locking checks to drm_for_each_connector but failed that
through drm_helper_connector_dpms -> drm_helper_choose_encoder_dpms
it's used in a few more places in the radeon resume/suspend code.

Fix them up.

Note that we could use the connector iterator macros in there too, but
that's for the future.
Reported-and-tested-by: NBorislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.

Looks like radeon doesn't do anything special with the request type,
so hopefully just treating it the same as a i2c write is enough.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the radeon driver loaded the HP Compaq dc5750
Small Form Factor machine fails to resume from suspend.
Adding a quirk similar to other devices avoids
the problem and the system resumes properly.
Signed-off-by: NJeffery Miller <jmiller@neverware.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.

Port of:
drm/radeon/atom: Send out the full AUX address
to radeon non-atom aux path
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Support for output_csc is only available on DCE5 and newer so
don't mess with the HDMI quantization_range on pre-DCE5 asics.

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

Most of the time this isn't an issue since hotplugging an adaptor will
trigger a crtc mode change which in turn, causes the driver to probe
every DisplayPort for a dpcd. However, in cases where hotplugging
doesn't cause a mode change (specifically when one unplugs a monitor
from a DisplayPort connector, then plugs that same monitor back in
seconds later on the same port without any other monitors connected), we
never probe for the dpcd before starting the initial link training. What
happens from there looks like this:

	- GPU has only one monitor connected. It's connected via
	  DisplayPort, and does not go through an adaptor of any sort.

	- User unplugs DisplayPort connector from GPU.

	- Change in HPD is detected by the driver, we probe every
	  DisplayPort for a possible connection.

	- Probe the port the user originally had the monitor connected
	  on for it's dpcd. This fails, and we clear the first (and only
	  the first) byte of the dpcd to indicate we no longer have a
	  dpcd for this port.

	- User plugs the previously disconnected monitor back into the
	  same DisplayPort.

	- radeon_connector_hotplug() is called before everyone else,
	  and tries to handle the link training. Since only the first
	  byte of the dpcd is zeroed, the driver is able to complete
	  link training but does so against the wrong dpcd, causing it
	  to initialize the link with the wrong settings.

	- Display stays blank (usually), dpcd is probed after the
	  initial link training, and the driver prints no obvious
	  messages to the log.

In theory, since only one byte of the dpcd is chopped off (specifically,
the byte that contains the revision information for DisplayPort), it's
not entirely impossible that this bug may not show on certain monitors.
For instance, the only reason this bug was visible on my ASUS PB238
monitor was due to the fact that this monitor using the enhanced framing
symbol sequence, the flag for which is ignored if the radeon driver
thinks that the DisplayPort version is below 1.1.
Signed-off-by: NStephen Chandler Paul <cpaul@redhat.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We apparantly get a hotplug irq before we've initialised
modesetting,

[drm] Loading R100 Microcode
BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [<c125f56f>] __mutex_lock_slowpath+0x23/0x91
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys
CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf674028 #111
Hardware name: MicroLink                               /D850MV                         , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003
Workqueue: events radeon_hotplug_work_func [radeon]
task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000
EIP: 0060:[<c125f56f>] EFLAGS: 00010282 CPU: 0
EIP is at __mutex_lock_slowpath+0x23/0x91
EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe
ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0
Stack:
 f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca
 f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0
 c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940
Call Trace:
 [<c103c4c1>] ? dequeue_task_fair+0xa4/0xb7
 [<c125f162>] ? mutex_lock+0x9/0xa
 [<f8b0faca>] ? radeon_hotplug_work_func+0x17/0x57 [radeon]
 [<c1034741>] ? process_one_work+0xfc/0x194
 [<c1034b58>] ? worker_thread+0x18d/0x218
 [<c10349cb>] ? rescuer_thread+0x1d5/0x1d5
 [<c103742a>] ? kthread+0x7b/0x80
 [<c12601c0>] ? ret_from_kernel_thread+0x20/0x30
 [<c10373af>] ? init_completion+0x18/0x18
Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63
Reported-and-Tested-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We already grab 2 device-global locks (write-sema rdev->pm.mclk_lock
and rdev->ring_lock), adding another global mutex won't serialize this
code more. And since there's really nothing interesting that gets
protected in radeon by dev->struct mutex (we only have the global z
buffer owners and it's still serializing gem bo destruction in the drm
core - which is irrelevant since radeon uses ttm anyway internally)
this doesn't add protection. Remove it.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It really doesn't protect anything which doesn't have other locks
already. Also this is run from driver unload code so not much need for
locks anyway.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This allows you to send different audio to each audio capable
display.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.

v3:
- Don't touch remove_conflicting_framebuffers

v2:
- Fix build break because of missing include of drm_fb_helper in
  radeon_drv.c

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fixes a broken hsync start value uncovered by:
abc0b144
(drm: Perform basic sanity checks on probed modes)

The driver handled the bad hsync start elsewhere, but
the above commit prevented it from getting added.

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

Need to setup the deep color and avi packets regardless of
audio setup.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

1. Always assign audio function pointers even if the display does
not support audio.  We need to properly disable the audio stream
when when using a non-audio capable monitor.  Fixes purple line
on some hdmi monitors.

2. Check if a pin is in use by another encoder before disabling
it.

v2: make sure we've fetched the edid before checking audio and
    look up the encoder before calling audio_detect since
    connector->encoder may not be assigned yet.  Separate
    pin and afmt.  They are allocated at different times and
    have no dependency on eachother.
v3: fix connector fetching in encoder functions
v4: fix missed dig->pin check in dce6_afmt_write_latency_fields

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

This is required to properly handle failing dpms calls.
When making a wait in i915 interruptible, I've noticed
that the dpms sequence could fail with -ERESTARTSYS because
it was waiting interruptibly for flips. So from now on
allow drivers to fail in their connector dpms callback.

Encoder and crtc dpms callbacks are unaffected.

Changes since v1:
- Update kerneldoc for the drm helper functions.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Resolve conflicts due to different merge order.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Two nice things here:
- drm_dev_register will truly register everything in the right order
  if the driver doesn't have a ->load callback. Before this we had to
  init the primary mode_group after the device nodes where already
  registered.

- Less things to keep track of when reworking the connector locking,
  yay!
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Similar with the i915 take all modeset locks for mst hotplug. This is
needed to make sure radeon holds both mode_config.mutex and
mode_config.connection_mutex when updating the connector_list, which
is the new (interim) locking regime we want for that.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This patch splits the KGD_ENGINE_SDMA to KGD_ENGINE_SDMA1 and
KGD_ENGINE_SDMA2 to match CZ definitions.
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

This has been a source of confusion.  Make it debug only.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Port of amdgpu patch 9298e52f.
Signed-off-by: NChristian König <christian.koenig@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This can be the case when the GPU is powered off, e.g. via vgaswitcheroo
or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin
flushes the TLB after setting rdev->gart.ptr to non-NULL.

Fixes panic on powering off R7xx GPUs.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

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

Cayman does not have vce.  There were a few places in the
shared cayman/TV code where we were trying to do vce stuff.

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

Otherwise we try to clear BO_VAs without an address.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91141Signed-off-by: NChristian König <christian.koenig@amd.com>
Test-by: hadack@gmx.de
Tested-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We need to allways add the VM clear duplicate of the BO_VA,
no matter what the old status was.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Test-by: hadack@gmx.de
Tested-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit ac913490.

We've fixed the underlying problem with cursors, so re-enable
this.

Reviewed-by: NGrigori Goronzy <greg@chown.ath.cx>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Everything is evicted from VRAM before suspend, so we need to make
sure all BOs are unpinned and re-pinned after resume. Fixes broken
mouse cursor after resume introduced by commit b9729b17.

[Michel Dänzer: Add pinning BOs on resume]

v2:
[Alex Deucher: merge cursor unpin into fb unpin loop]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541
Cc: stable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
Signed-off-by: NGrigori Goronzy <greg@chown.ath.cx>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Take a GEM reference for and pin the new cursor BO, unpin and drop the
GEM reference for the old cursor BO in radeon_crtc_cursor_set2, and use
radeon_crtc->cursor_addr in radeon_set_cursor.

This fixes radeon_cursor_reset accidentally incrementing the cursor BO
pin count, and cleans up the code a little.

Cc: stable@vger.kernel.org
Reviewed-by: NGrigori Goronzy <greg@chown.ath.cx>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The "if (pass_size > buf->total)" can underflow so I have changed the
type of size and pass_size to unsigned to avoid this problem.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Newer ASICs have more VRAM on average and allocating more GART as
well can have advantages. Also see commit edcd26e8.

Ideally, we should scale GART size based on actual VRAM size, but
that requires significant restructuring of initialization.

v2: extract small helper, apply to error paths
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NGrigori Goronzy <greg@chown.ath.cx>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This was regressed by commit 39e7f6f8, although I don't know of any
actual issues caused by it.

The storage domain is read without TTM locking now, but the lock
never helped to prevent any races.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NGrigori Goronzy <greg@chown.ath.cx>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We don't need to call the (expensive) radeon_bo_wait, checking the
fences via RCU is much faster. The reservation done by radeon_bo_wait
does not save us from any race conditions.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NGrigori Goronzy <greg@chown.ath.cx>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Trying to resolve issues with missed vblanks and impossible
values inside delivered kms pageflip completion events showed
that radeon's irq handling sometimes doesn't handle valid irqs,
but silently skips them. This was observed for vblank interrupts.

Although those irqs have corresponding events queued in the gpu's
irq ring at time of interrupt, and therefore the corresponding
handling code gets triggered by these events, the handling code
sometimes silently skipped processing the irq. The reason for those
skips is that the handling code double-checks for each irq event if
the corresponding irq status bits in the irq status registers
are set. Sometimes those bits are not set at time of check
for valid irqs, maybe due to some hardware race on some setups?

The problem only seems to happen on some machine + card combos
sometimes, e.g., never happened during my testing of different PC
cards of the DCE-2/3/4 generation a year ago, but happens consistently
now on two different Apple Mac cards (RV730, DCE-3, Apple iMac and
Evergreen JUNIPER, DCE-4 in a Apple MacPro). It also doesn't happen
at each interrupt but only occassionally every couple of
hundred or thousand vblank interrupts.

This results in XOrg warning messages like

"[  7084.472] (WW) RADEON(0): radeon_dri2_flip_event_handler:
Pageflip completion event has impossible msc 420120 < target_msc 420121"

as well as skipped frames and problems for applications that
use kms pageflip events or vblank events, e.g., users of DRI2 and
DRI3/Present, Waylands Weston compositor, etc. See also

https://bugs.freedesktop.org/show_bug.cgi?id=85203

After some talking to Alex and Michel, we decided to fix this
by turning the double-check for asserted irq status bits into a
warning. Whenever a irq event is queued in the IH ring, always
execute the corresponding interrupt handler. Still check the irq
status bits, but only to log a DRM_DEBUG message on a mismatch.

This fixed the problems reliably on both previously failing
cards, RV-730 dual-head tested on both crtcs (pipes D1 and D2)
and a triple-output Juniper HD-5770 card tested on all three
available crtcs (D1/D2/D3). The r600 and evergreen irq handling
is therefore tested, but the cik an si handling is only compile
tested due to lack of hw.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
CC: Michel Dänzer <michel.daenzer@amd.com>
CC: Alex Deucher <alexander.deucher@amd.com>
CC: <stable@vger.kernel.org> # v3.16+
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>