- Complete overhaul to the main IOCTL function, kfd_ioctl(), according to
drm_ioctl() example. This includes changing the IOCTL definitions, so it
breaks compatibility with previous versions of the userspace. However,
because the kernel was not officialy released yet, and this the first
kernel that includes amdkfd, I assume I can still do that at this stage.
- A couple of bug fixes for the non-HWS path (used for bring-ups and
debugging purposes only).
* tag 'amdkfd-fixes-2015-01-06' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: rewrite kfd_ioctl() according to drm_ioctl()
drm/amdkfd: reformat IOCTL definitions to drm-style
drm/amdkfd: Do copy_to/from_user in general kfd_ioctl()
drm/amdkfd: unmap VMID<-->PASID when relesing VMID (non-HWS)
drm/radeon: Assign VMID to PASID for IH in non-HWS mode
drm/radeon: do not leave queue acquired if timeout happens in kgd_hqd_destroy()
drm/amdkfd: Load mqd to hqd in non-HWS mode
drm/amd: Fixing typos in kfd<->kgd interface
some minor radeon fixes.
* 'drm-fixes-3.19' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: integer underflow in radeon_cp_dispatch_texture()
drm/radeon: adjust default bapm settings for KV
drm/radeon: properly filter DP1.2 4k modes on non-DP1.2 hw
drm/radeon: fix sad_count check for dce3
drm/radeon: KV has three PPLLs (v2)
- Fix BUG() on !SMP builds
- Fix for OOPS on pre-NV50 that snuck into -next
- MCP7[789A] hang fix where firmware hasn't already setup NISO pollers
- NV4x IGP MSI disable, it doesn't appear to work correctly
- Add GK208B to recognised boards (no code change aside from adding
chipset recognition)
* 'linux-3.19' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/nouveau: Do not BUG_ON(!spin_is_locked()) on UP
drm/nv4c/mc: disable msi
drm/nouveau/fb/ram/mcp77: enable NISO poller
drm/nouveau/fb/ram/mcp77: use carveout reg to determine size
drm/nouveau/fb/ram/mcp77: subclass nouveau_ram
drm/nouveau: wake up the card if necessary during gem callbacks
drm/nouveau/device: Add support for GK208B, resolves bug 86935
drm/nouveau: fix missing return statement in nouveau_ttm_tt_unpopulate
drm/nouveau/bios: fix oops on pre-nv50 chipsets
This patch changes kfd_ioctl() to be very similar to drm_ioctl().
The patch defines an array of amdkfd_ioctls, which maps IOCTL definition to the
ioctl function.
The kfd_ioctl() uses that mapping to call the appropriate ioctl function,
through a function pointer.
This patch also declares a new typedef for the ioctl function pointer.
v2: Renamed KFD_COMMAND_(START|END) to AMDKFD_...
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
This patch reformats the ioctl definitions in kfd_ioctl.h to be similar to the
drm ioctls definition style.
v2: Renamed KFD_COMMAND_(START|END) to AMDKFD_...
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
This patch moves the copy_to_user() and copy_from_user() calls from the
different ioctl functions in amdkfd to the general kfd_ioctl() function, as
this is a common code for all ioctls.
This was done according to example taken from drm_ioctl.c
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
The test:
if (size > RADEON_MAX_TEXTURE_SIZE) {
"size" is an integer and it's controled by the user so it can be
negative and the test can underflow. Later we use "size" in:
dwords = size / 4;
...
RADEON_COPY_MT(buffer, data, (int)(dwords * sizeof(u32)));
It causes memory corruption to copy a negative size buffer.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Enabling bapm seems to cause clocking problems on some
KV configurations. Disable it by default for now.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The check was already in place in the dp mode_valid check, but
radeon_dp_get_dp_link_clock() never returned the high clock
mode_valid was checking for because that function clipped the
clock based on the hw capabilities. Add an explicit check
in the mode_valid function.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=87172
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc:stable@vge.kernel.org
Enable all three in the driver. Early documentation
indicated the 3rd one was used for something else, but
that is not the case.
v2: handle disable as well
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
This patch fixes a bug where deallocate_vmid() didn't actually unmap the
VMID<-->PASID mapping (in the registers).
That can cause undefined behavior.
This bug only occurs in non-HWS mode.
Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Highlights:
- Link order changes in drm/Makefile and drivers/Makefile to fix issue
when amdkfd, radeon and amd_iommu_v2 are compiled inside the kernel
image.
- Consider kernel configuration (using #IFDEFs) when radeon initializes
amdkfd, due to a specific configuration that makes symbol_request()
return a non-NULL value when a symbol doesn't exists. Rusty Russel
is helping me to find the root cause, but it may take a while because
of year-end so I'm sending this as a band-aid solution.
* tag 'amdkfd-fixes-2014-12-30' of git://people.freedesktop.org/~gabbayo/linux:
drm/radeon: Init amdkfd only if it was compiled
amdkfd: actually allocate longs for the pasid bitmask
drm: Put amdkfd before radeon in drm Makefile
drivers: Move iommu/ before gpu/ in Makefile
amdkfd: Remove duplicate include
amdkfd: Fixing topology bug in building sysfs nodes
amdkfd: Fix accounting of device queues
I've had these since before -rc1, but they missed my last pull
request. Real bug fixes and mostly cc: stable material.
* tag 'drm-intel-next-fixes-2014-12-30' of git://anongit.freedesktop.org/drm-intel:
drm/i915: add missing rpm ref to i915_gem_pwrite_ioctl
Revert "drm/i915: Preserve VGACNTR bits from the BIOS"
drm/i915: Don't call intel_prepare_page_flip() multiple times on gen2-4
drm/i915: Kill check_power_well() calls
This patch changes the radeon_kfd_init(), which is used to initialize the
interface between radeon and amdkfd, so the interface will be initialized only
if amdkfd was build, either as module or inside the kernel image.
In the modules case, the symbol_request() will be used (same as old code). In
the in-image compilation case, a direct call to kgd2kfd_init() will be done.
For other cases, radeon_kfd_init() will just return false.
This patch is necessary because in case of the following specific
configuration: kernel 32-bit, no modules support, random kernel base and no
hibernation, the symbol_request() doesn't work as expected - it doesn't return
NULL if the symbol doesn't exists - which makes the kernel panic.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Commit "amdkfd: use sizeof(long) granularity for the pasid bitmask" calculated
the number of longs it will need, but ended up allocating that number of
bytes rather than longs.
Fix that silly error and allocate the amount of data really required.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
This reverts commit 355a701838.
This had some bad side effects under normal operation, and should
have been dropped earlier.
Signed-off-by: Dave Airlie <airlied@redhat.com>
- Display MEC fw version in topology. Without this, the HSA userspace
stack is broken.
- Init apertures information only once per process
* tag 'amdkfd-fixes-2014-12-23' of git://people.freedesktop.org/~gabbayo/linux:
amdkfd: init aperture once per process
amdkfd: Display MEC fw version in topology node
drm/radeon: Add implementation of get_fw_version
drm/amd: Add get_fw_version to kfd-->kgd interface
This is a set of fixes for two regressions and one bug in the IOMMU
mapping code. It turns out that all of these issues turn up primarily
on Tegra30 hardware. The IOMMU mapping bug only manifests on buffers
that aren't multiples of the page size. I happened to be testing HDMI
with 1080p while writing the code and framebuffers for that happen to
fit exactly within 2025 pages of 4 KiB each.
One of the regressions is caused by the IOMMU code allocating pages from
shmem which can have associated cache lines. If the pages aren't flushed
then these cache lines may be flushed later on and cause framebuffer
corruption. I'm not sure why I didn't see this before. Perhaps the board
that I was using had enough RAM so that the pages shmem would hand out
had a better chance of being unused. Or maybe I didn't look too closely.
The fix for this is to fake up an SG table so that it can be passed to
the DMA API. Ideally this would use drm_clflush_*(), but implementing
that for ARM causes DRM to fail to build as a module since some of the
low-level cache maintenance functions aren't exported. Hopefully we can
get a suitable API exported on ARM for the next release.
The second regression is caused by a mismatch between the hardware pipe
number and the CRTC's DRM index. These were used inconsistently, which
could cause one code location to call drm_vblank_get() with a different
pipe than the corresponding drm_vblank_put(), thereby causing the
reference count to become unbalanced. Alexandre also reported a possible
race condition related to this, which this series also fixes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUkYzSAAoJEN0jrNd/PrOhFWgP+wYiyXiLot7Wo3+HM779fQ9a
MZkOycfxyNJ+TxJjvIlJh/2y641G4Elw3rod/QhUKg1b0L2uqVrVRKvEsx5sR5Ci
XASwkx9UFLRxN6/Cr/X8SKmE7nFUSwGd3wSoVrT42ldo0DOOlHuVT9NLFoCfDmFa
GN5pxUW/WHS7WgCVpG9GgoFmFZXyrwx9ZRHqL49eJqAvjBngmBbZeyhFeZdu71fl
rm4qMiLkZZsLZEm3uP53pbdkAf7yZGV3WPWKO43LXgykSMfQ56WcN7JJsGygB3I1
uEMP65Tf3TdynW6Wz2dywq81uITJhd8y6Zhr6j2bsNINTHDz67YOxKfS50axZN/P
2PbqDLyJF7MT1ydQ7weeEv4gkRF8Vt6K3aBfL5gm8PM6jm2sdZytsjLM+/RCIkl3
cDtkC+XmPmGxLTEnV3iWMCbCfOrNvqzkp9jvilIEbxIvgX72T6EQPJnfe7Sv95Cr
VBFWoi26XtFhN9wWEGjc7fRTUwNdg4D21/ns8TY3MgOFQcdP01pp2KRTdPDC/6Mt
kknXwDaZRY6EjGQmRKkxKf1c64nmY8V7MJx2CSbPc3HgGdSXaa0AOZE2d60beste
ASpgMQIbERCmAbdmb5JN6fsKcpJrJL15zbrGcDwSnIk96x4HAC8zB9Xln2ubdCwc
IP4cm/Abz6Cfd6I1cQRr
=eVlK
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-3.19-rc1-fixes' of git://people.freedesktop.org/~tagr/linux into drm-fixes
drm/tegra: Fixes for v3.19-rc1
This is a set of fixes for two regressions and one bug in the IOMMU
mapping code. It turns out that all of these issues turn up primarily
on Tegra30 hardware. The IOMMU mapping bug only manifests on buffers
that aren't multiples of the page size. I happened to be testing HDMI
with 1080p while writing the code and framebuffers for that happen to
fit exactly within 2025 pages of 4 KiB each.
One of the regressions is caused by the IOMMU code allocating pages from
shmem which can have associated cache lines. If the pages aren't flushed
then these cache lines may be flushed later on and cause framebuffer
corruption. I'm not sure why I didn't see this before. Perhaps the board
that I was using had enough RAM so that the pages shmem would hand out
had a better chance of being unused. Or maybe I didn't look too closely.
The fix for this is to fake up an SG table so that it can be passed to
the DMA API. Ideally this would use drm_clflush_*(), but implementing
that for ARM causes DRM to fail to build as a module since some of the
low-level cache maintenance functions aren't exported. Hopefully we can
get a suitable API exported on ARM for the next release.
The second regression is caused by a mismatch between the hardware pipe
number and the CRTC's DRM index. These were used inconsistently, which
could cause one code location to call drm_vblank_get() with a different
pipe than the corresponding drm_vblank_put(), thereby causing the
reference count to become unbalanced. Alexandre also reported a possible
race condition related to this, which this series also fixes.
* tag 'drm/tegra/for-3.19-rc1-fixes' of git://people.freedesktop.org/~tagr/linux:
drm/tegra: dc: Select root window for event dispatch
drm/tegra: gem: Use the proper size for GEM objects
drm/tegra: gem: Flush buffer objects upon allocation
drm/tegra: dc: Fix a potential race on page-flip completion
drm/tegra: dc: Consistently use the same pipe
drm/irq: Add drm_crtc_vblank_count()
drm/irq: Add drm_crtc_handle_vblank()
drm/irq: Add drm_crtc_send_vblank_event()
misc i915 fixes.
* tag 'drm-intel-next-fixes-2014-12-17' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Disable PSMI sleep messages on all rings around context switches
drm/i915: Force the CS stall for invalidate flushes
drm/i915: Invalidate media caches on gen7
drm/i915: sanitize RPS resetting during GPU reset
drm/i915: move RPS PM_IER enabling to gen6_enable_rps_interrupts
drm/i915: vlv: fix IRQ masking when uninstalling interrupts
Yeah a pull for one patch is a bit overkill but I started to assemble the
various patches for 3.20 in a branch for atomic props/ioctl and didn't
realize that this bugfix here at the beginnning of the branch should be in
3.19 (because msm is using the helpers arleady). So if you'd merge we'd
have it twice or or I need to shuffle branches again. Can do if you want.
* tag 'topic/atomic-fixes-2014-12-17' of git://anongit.freedesktop.org/drm-intel:
drm/atomic: fix potential null ptr on plane enable
A few msm fixes for 3.19:
* hdmi regulators fix
* hdmi fix for spurious HPD interrupts
* fix for sync atomic update after async update (which could show
up with a setcrtc following a pageflip)
* couple little Coccinelle cleanups
* 'msm-fixes-3.19' of git://people.freedesktop.org/~robclark/linux:
drm/msm/hdmi: rework HDMI IRQ handler
drm/msm/hdmi: enable regulators before clocks to avoid warnings
drm/msm/mdp5: update irqs on crtc<->encoder link change
drm/msm: block incoming update on pending updates
drm/msm: Deletion of unnecessary checks before the function call "release_firmware"
drm/msm: Deletion of unnecessary checks before two function calls
nouveau userspace back at 1.0.1 used to call the X server
DRIOpenDRMMaster interface even for DRI2 (doh!), this attempts
to map the sarea and fails if it can't.
Since 884c6dabb0 from Daniel,
this fails, but only ancient drivers would see it.
Revert the nouveau bits of that fix.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # 3.18
Signed-off-by: Dave Airlie <airlied@redhat.com>
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The failure paths if we fail to wake the card are less than desirable,
but there's not really a graceful way to handle this case currently.
I'll keep this situation in mind when I get to fixing other vm-related
issues.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_ttm_tt_unpopulate() is supposed to return right after calling
ttm_dma_unpopulate() in the case of a coherent buffer. The return
statement was omitted, leading to the pages being unmapped twice. Fix
this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When amdkfd and radeon are compiled inside the kernel image (not as modules),
radeon will load before amdkfd, which will cause a bug when radeon will probe
the GPUs.
When the two drivers are compiled as modules, amdkfd is loaded after radeon is
loaded but before radeon starts probing the GPUs. This is done because radeon
loads the amdkfd module through symbol_request function.
This patch makes amdkfd load before radeon when they are both compiled inside
the kernel image, which makes the behavior similar to the case when they are
modules, and prevents the kernel bug.
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
If crtc <-> encoder linkage changes, we could end up with the CRTC
listening for the wrong error or vsync irqs. Generally this problem
would correct itself relatively quickly, since we update the global
irqmask after dispatching irqs, but to be sure let the CRTC trigger
update_irq().
Signed-off-by: Rob Clark <robdclark@gmail.com>
We can't have multiple updates pending on a given CRTC, and we don't
want a sync update to race w/ an async update that preceeded it. So
keep track of which CRTCs have updates in flight, and block later
updates that would conflict.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Without this RPM ref we can hit the device suspended WARN via:
i915_gem_object_pin()->ggtt_bind_vma->gen6_ggtt_insert_entries(). I
noticed this on my BYT while keeping the i915 device in runtime
suspended state for a while. I chose this place to take the ref to
avoid the possible deadlock via the mutex_lock taken both later in this
function and in the runtime suspend handler. This can happen if an RPM
suspend event is queued and need to be flushed before taking the RPM
ref.
Testcase: igt/pm_rpm/gem-evict-pwrite
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87363
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The VGA_2X_MODE bit apparently affects the display even when the VGA
plane is disabled. The bit will set by the BIOS when the panel width
is at least 1280 pixels. So by preserving the bit from the BIOS we
end up with corrupted display on machines with such high res panels.
I only have 1024x768 panels on my gen2 machines so never ran into
this problem.
The original reason for preserving the VGACNTR register was to make
my 830 survive S3 with acpi_sleep=s3_bios option. However after
further 830 fixes that option is no longer needed to make S3 work
and preserving VGACNTR doesn't seem to be necessary without it,
so we can just revert the entire patch.
This reverts
commit 69769f9a42
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Aug 15 01:22:08 2014 +0300
drm/i915: Preserve VGACNTR bits from the BIOS
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87171
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The flip stall detector kicks in when pending>=INTEL_FLIP_COMPLETE. That
means if we first call intel_prepare_page_flip() but don't call
intel_finish_page_flip(), the next stall check will erroneosly think
the page flip was somehow stuck.
With enough debug spew emitted from the interrupt handler my 830 hangs
when this happens. My theory is that the previous vblank interrupt gets
sufficiently delayed that the handler will see the pending bit set in
IIR, but ISR still has the bit set as well (ie. the flip was processed
by CS but didn't complete yet). In this case the handler will proceed
to call intel_check_page_flip() immediately after
intel_prepare_page_flip(). It then tries to print a backtrace for the
stuck flip WARN, which apparetly results in way too much debug spew
delaying interrupt processing further. That then seems to cause an
endless loop in the interrupt handler, and the machine is dead until
the watchdog kicks in and reboots. At least limiting the number of
iterations of the loop in the interrupt handler also prevented the
hang.
So it seems better to not call intel_prepare_page_flip() without
immediately calling intel_finish_page_flip(). The IIR/ISR trickery
avoids races here so this is a perfectly safe thing to do.
v2: Fix typo in commit message (checkpatch)
Cc: stable@vger.kernel.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88381
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85888
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
pps_{lock,unlock}() call intel_display_power_{get,put}() outside
pps_mutes to avoid deadlocks with the power_domain mutex. In theory
during aux transfers we should usually have the relevant power domain
references already held by some higher level code, so this should not
result in much overhead (exception being userspace i2c-dev access).
However thanks to the check_power_well() calls in
intel_display_power_{get/put}() we end up doing a few Punit reads for
each aux transfer. Obviously doing this for each byte transferred via
i2c-over-aux is not a good idea.
I can't think of a good way to keep check_power_well() while eliminating
the overhead, so let's just remove check_power_well() entirely.
Fixes a driver init time regression introduced by:
commit 773538e860
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Sep 4 14:54:56 2014 +0300
drm/i915: Reset power sequencer pipe tracking when disp2d is off
Credit goes to Jani for figuring this out.
v2: Add the regression note in the commit message.
Cc: stable@vger.kernel.org (v3.18+)
Cc: Egbert Eich <eich@suse.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86201
Tested-by: Wendy Wang <wendy.wang@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When a plane is being enabled, plane->crtc has not been set yet. Use
plane->state->crtc.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The release_firmware() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The functions framebuffer_release() and vunmap() perform also input
parameter validation. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
In finish pageflip, the driver was not selecting the root window when
dispatching events. This exposed a race where a plane update would
change the window selection and cause tegra_dc_finish_page_flip to check
the wrong base address.
This patch also protects access to the window selection register as well
as the registers affected by it.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
If the requested buffer size wasn't a multiple of the page size, the
IOMMU code would round down the size to the next multiple of the page
size, thereby causing translation errors. To fix this we no longer pass
around the requested size but reuse the computed size of the GEM object.
This is already rounded to the next page boundary, so mapping that size
works out fine.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Buffers obtained via shmem may still have associated cachelines. If they
aren't properly flushed they may cause framebuffer corruption if the
cache gets flushed after the application has drawn to it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Page-flip completion could race with page-flip submission, so extend the
critical section to include all accesses to page-flip related data.
Reported-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The hardware pipe numbers don't always match the DRM CRTC indices. This
can happen for example if the first display controller defers probe,
causing it to be registered with DRM after the second display
controller. When that happens the hardware pipe numbers and DRM CRTC
indices become different. Make sure that the CRTC index is always used
when accessing per-CRTC VBLANK data. This can be ensured by using the
drm_crtc_vblank_*() API, which will do the right thing automatically
given a struct drm_crtc *.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This function is the KMS native variant of drm_vblank_count(). It takes
a struct drm_crtc * instead of a struct drm_device * and an index of the
CRTC.
Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
