It happens on occasion that developers of generic user-space applications
abuse the dumb buffer API to get hold of drm buffers that they can both
mmap() and use for GPU acceleration, using the assumptions that dumb buffers
and buffers available for GPU are
a) The same type and can be aribtrarily type-casted.
b) fully coherent.
This patch makes the most widely used drivers warn nicely when that happens,
the next step will be to fail.
v2: Move drmP.h changes to drm_gem.h. Fix Radeon dumb mmap breakage.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This way the necessary VM update is kicked off immediately
if all BOs involved are in GPU accessible memory.
v2: fix vm lock
v3: immediately update unmaps as well
v4: use drm_free_large instead of kfree
Tested-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Only invalidating PTEs needs to be executed synchronized to using the PT.
v2: fix sync to uses
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We never invalidate PD entries and making them valid can
run with other users in parallel.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This allows us to finally remove the VM fence and
so allow concurrent use of it from different engines.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use multiple VMIDs for each VM, one for each ring. That allows
us to execute flushes separately on each ring, still not ideal
cause in a lot of cases rings can share IDs.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Note for each fence if it's a VM page table update or not. This allows
us to determine the last VM update in a sync object and so to figure
out if we need to flush the TLB or not.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This allows us to add the real execution fence as shared.
v2: fix typo
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Previously we just allocated space for four hardware semaphores
in each software semaphore object. Make software semaphore objects
represent only one hardware semaphore address again by splitting
the sync code into it's own object.
v2: fix typo in comment
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The PD/PTs reservation object now contains everything needed.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
That's useless when all callers drop the reservation
immediately after calling the function.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use ring structure instead of index and provide vm_id and pd_addr separately.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The current code always reprogrammed the sclk levels,
but we don't currently handle disp sclk requirements
so just skip it.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Enable smc fan control for CI boards. Should
reduce the fan noise on systems with a higher
default fan profile.
v2: disable by default, add additional fan setup, rpm control
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73338
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Enable smc fan control for SI boards. Should
reduce the fan noise on systems with a higher
default fan profile.
v2: disable by default, add rpm controls
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73338
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Always need to set bit 0 of RLC_CGTT_MGCG_OVERRIDE
to avoid unreliable doorbell updates in some cases.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The cursor_set2 hook provides the cursor hotspot position within the
cursor image. When the hotspot position changes, we can adjust the cursor
position such that the hotspot doesn't move on the screen. This prevents
the cursor from appearing to intermittently jump around on the screen
when the position of the hotspot within the cursor image changes.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This patch allows framebuffers for cirrus to be created with
32bpp pixel formats provided that they do not violate certain
restrictions of the cirrus hardware.
v2: Use pci resource length for vram size.
Signed-off-by: Zach Reizner <zachr@google.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Only importing an FD to a handle is currently supported on UDL,
but the exporting functionality is equally useful.
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
By default set udl_gem_object as cacheable, but set WC flag when attaching
dmabuf. In udl_gem_mmap() update cache attributes based on the flags, similar
to exynos_drm_gem_mmap().
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Before this patch, cirrus_device_init could have failed while
cirrus_mm_init succeeded and the driver would have reported overall
success on load. This patch causes cirrus_device_init to return on
the first error encountered.
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Oversight from my kerneldoc cleanup when doing the original atomic
helper series - I've only applied this clarification to the modeset
related helpers, and not the plane update code. Remedy this asap.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I guess for hysterical raisins this was meant to be the way to read
blob properties. But that's done with the two-stage approach which
uses separate blob kms object and the special-purpose get_blob ioctl.
Shipping userspace seems to have never relied on this, and the kernel
also never put any blob thing onto that property. And nowadays it
would blow up, e.g. in drm_property_destroy. Also it makes no sense to
return values in an ioctl that only returns metadata about everything.
So let's ditch all the internal code for the blob list, rename the
list to be unambiguous and sprinkle comments all over the place to
explain this peculiar piece of api.
v2: Squash in fixup from Rob to remove now unused variables.
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- Make it clear that it's a negative errno (more in line with
everything else).
- Clean up the confusion around get_properties vs. getproperty ioctls:
One reads per-obj property values, the other reads property
metadata.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Yet another fallout from not considering DP MST hotplug. With the
previous patches we have stable indices, but it might still happen
that a connector gets added between when we allocate the array and
when we actually add a connector. Especially when we back off due to
ww mutex contention or similar issues.
So store the sizes of the arrays in struct drm_atomic_state and double
check them. We don't really care about races except that we want to
use a consistent value, so ACCESS_ONCE is all we need. And if we
indeed notice that we'd overrun the array then just give up and
restart the entire ioctl.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise the connector might have been unplugged and destroyed while
we didn't look. Yet another fallout from DP MST hotplugging that I
didn't consider.
To make sure we get this right add an appropriate WARN_ON to
drm_atomic_state_clear (obviously only when we actually have a state
to clear up). And reorder all the state_clear and backoff calls to
make it work out properly.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I've totally forgotten that with DP MST connectors can now be
hotplugged. And failed to adapt Rob's drm_atomic_state code (which
predates connector hotplugging) to the new realities.
The first step is to make sure that the connector indices used to
access the arrays of pointers are stable. The connection mutex gives
us enough guarantees for that, which means we won't unecessarily block
on concurrent modesets or background probing.
So add a locking WARN_ON and shuffle the code slightly to make sure we
always hold the right lock.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Let's make things a bit easier to debug when things go bad (potentially
under console_lock).
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Andrew Morton wrote:
> On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> > Andrew Morton wrote:
> > > Poor ttm guys - this is a bit of a trap we set for them.
> >
> > Commit a91576d791 ("drm/ttm: Pass GFP flags in order to avoid deadlock.")
> > changed to use sc->gfp_mask rather than GFP_KERNEL.
> >
> > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
> > - GFP_KERNEL);
> > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> >
> > But this bug is caused by sc->gfp_mask containing some flags which are not
> > in GFP_KERNEL, right? Then, I think
> >
> > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL);
> >
> > would hide this bug.
> >
> > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag)
>
> Well no - ttm_page_pool_free() should stop calling kmalloc altogether.
> Just do
>
> struct page *pages_to_free[16];
>
> and rework the code to free 16 pages at a time. Easy.
Well, ttm code wants to process 512 pages at a time for performance.
Memory footprint increased by 512 * sizeof(struct page *) buffer is
only 4096 bytes. What about using static buffer like below?
----------
>From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Thu, 13 Nov 2014 22:21:54 +0900
Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions.
Commit a91576d791 ("drm/ttm: Pass GFP flags in order to avoid
deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags
which are not in GFP_KERNEL.
https://bugzilla.kernel.org/show_bug.cgi?id=87891
Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would
avoid the BUG_ON(), but avoiding memory allocation from shrinker
function is better and reliable fix.
Shrinker function is already serialized by global lock, and
clean up function is called after shrinker function is unregistered.
Thus, we can use static buffer when called from shrinker function
and clean up function.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit f9b9faf6d94dd29eab8c128905c7d091f955481d "drm: flip-work: change
drm_flip_work_init prototype" changed the drm_flip_work_init prototype
to a void function, which makes 'ret' an unused variable.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Implement crtc page_flip callback for bochsdrm. The qemu stdvga has no
vblank signaling, so we have to fake it. We do so by instantly calling
drm_send_vblank_event. Tested with kmscon.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remove the mapping offset from the bo backing the fbdev framebuffer.
Wire up fbdev mmap function to map the backing bo using ttm_fbdev_mmap.
With that patch in place mmap(/dev/fb0) works as expected.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Recently (qemu 2.2+) the qemu stdvga got a register to switch the vga
framebuffer endianness. This patch adds code to explicitly set the
endianness of the framebuffer. In most cases this has no effect as
the default is guest architecture endianness. It is needed though in
case a architecture supports both big and little endian, i.e. for
ppc64le.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Main pull for 3.19. I may have another pull in a few days with some
mdp5 bits (and hopefully mdp5 atomic), but I figured there was no need
to hold up what we have already. Main highlights so far:
1) a4xx gpu support (userspace gallium bits on mesa master)
2) mdp4/hdmi/core bits for atomic helpers. Still missing mdp5
conversion, main hold up there is current hard-coded mixer setup isn't
clever enough to deal with disabling primary plane while crtc active.
3) various other misc cleanup/fixes/etc..
* 'msm-next' of git://people.freedesktop.org/~robclark/linux: (21 commits)
drm/msm: a4xx support for msm-drm
drm/msm: Handle register offset differences between a3xx and a4xx
drm/msm: small mmap offset cleanups
drm/msm/mdp4: atomic
drm/msm/hdmi: atomic
drm/msm: atomic core bits
drm/msm: bit of fb error checking
drm/msm: fb prepare/cleanup
drm/msm: remove unused compile-test stub
drm/msm: small fence cleanup
drm/msm/mdp5: drop attached planes table
drm/msm/mdp4: drop attached planes table
drm/msm/mdp4: don't care about fb in crtc
drm/msm/mdp5: drop private primary ptr
drm/msm/mdp4: drop private primary ptr
drm/msm: Fix fbdev for 16- and 24-bit modes.
drm/msm: Allow exported dma-bufs to be mapped
drm/msm/hdmi: refactor bind/init
drm/msm: update generated headers
drm/msm/adreno: slight init order cleanup
...
Register offsets have changed between a3xx and a4xx GPUs.
To be able access these registers in common code, we create
a lookup table, and set of read-write APIs to access the
register through the lookup table.
Signed-off-by: Aravind Ganesan <aravindg@codeaurora.org>
[robclark: remove REG_ADRENO_UNDEFINED, just use zero, and minor
tweaks for latest generated headers]
Signed-off-by: Rob Clark <robdclark@gmail.com>
Use pre-computed iova when unmapping, to reduce the places we assume iova
and mmap offset are (at the moment) the same. And get rid of an extra
drm_gem_free_mmap_offset() call (since it is already called from
drm_gem_object_release())
Signed-off-by: Rob Clark <robdclark@gmail.com>
It's a problem that can't happen yet, since we don't support any
multi-planar formats yet. But let's avoid nasty surprises when the
time comes.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Atomic wants to split the prepare/pin from where we actually program the
scanout address (so that any part that can fail is done synchronously).
Add some fb/gem apis to make this easier to use from the kms parts.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Give ourselves a way to wait for certain fence #.. makes it easier to
wait on a set of bo's, which we'll need for atomic.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Simplify things a bit for atomic, gets rid of some bookkeeping, and
makes the code cleaner.
TODO move iterator macro somewhere common.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since we are configuring things via MDP4_PIPE regs in the plane, it seems
like setting the dimensions of the primary plane on the OVLP/DMA regs in
crtc is unnecessary. This will make life easier when we want to do a
nofb modeset.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Currently forcing the video mode from the kernel command line (for example
video=HDMI-A-1:1280x720-16@60) does not correctly set the number of bits
per pixel. This is due to a rather aggressive override in
msm_fbdev_create(). This is a particular problem for Android bring up
because the software EGL fallbacks don't support 32bpp.
Since the overrides are actually the default values anyway then this
problem can be trivially fixed by removing the overrides completely.
Change was tested by dd'ing a test image to /dev/fb0 with no video=
(still 32bpp), video=1920x1080-32@60, video=1920x1080-24@60 and
video=1920x1080-16@60 .
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Currently msm does not implement gem_prime_mmap. Without this it is not
possible to draw onto a dma-buf from userspace (making its very hard to
implement the Android rendering model).
Fixing this is just a matter of adding a little boilerplate.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Split up hdmi_init() into hdmi_init() (done at hdmi sub-device
bind/probe time) and hdmi_modeset_init() done from master driver's
modeset_init().
Anything that can fail due to dependencies on other drivers which
may be missing or not probed yet should go in hdmi_init(), so that
devm error/cleanup paths work properly.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Move anything that can fail after call to base class msm_gpu_init().
This way, if we fail, active_list has already been initialized so we
don't trip 'WARN_ON(!list_empty(&gpu->active_list))' in
msm_gpu_cleanup().
Signed-off-by: Rob Clark <robdclark@gmail.com>
Fixes a potential error, spotted by Felipe with randconfig:
-----
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ‘mdp4_kms_init’:
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \
of function ‘devm_regulator_get_exclusive’ [-Werror=implicit-function-declaration]
mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
^
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:16: error: assignment makes \
pointer from integer without a cast [-Werror]
mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
^
-----
Also add a brief comment explaining the use of _get_exclusive()
Reported-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Some drivers erroneously treat the .pitch and .size fields of struct
drm_mode_create_dumb as inputs. While the include/uapi/drm/drm_mode.h
header has a comment denoting them as outputs, that seemingly wasn't
enough to make drivers use them properly.
The result is that some userspace doesn't explicitly zero out those
fields, assuming that the kernel won't use them. That causes problems
since the data within the structure might be uninitialized, so bogus
data may end up confusing drivers (ridiculously large values for the
pitch, ...).
This series attempts to improve the situation by fixing all drivers to
not use the output fields. Furthermore to spare new drivers this bad
surprise, the DRM core now zeros out these fields prior to handing the
data structure to the driver.
Lessons learned from this are that future IOCTLs should be properly
documented (in the DRM DocBook for example) and should be rigorously
defined. To prevent misuse like this, userspace should be required to
zero out all output fields. The kernel should check for this and fail
if that's not the case.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUZKbcAAoJEN0jrNd/PrOh57QQAKdX7ASd4XVhMC6fuVGXHUXI
HVZuJ3Own+e3aAJKhZ2DZ263+PtBLfe3+eEF1WRWqZcDu647Nj3wSV64celdZdIl
WHU2RokxneHTPHlttZ+MLhVwtzSddO8712iLU/2B7Rg/MNlN9tv9tbRtGqPWwlzg
IZNAdU5etnm+YDYil8/I8f84+5vT59Z/X2NHbq+jReD3V6I2WBAK6zlRIy4o54io
fccK7M6+uGlbNmtPwoKXufeiqTxxdYYelZoQzO4NjWEhdU0LoUnTFdfqISSdt3HV
26NwTmqVTx38AD5bGwot2b1VFEkja5tkP7G+DeFkj0DRHbFfAQK/tNeqdf9xq4gQ
UEVjljyEW6dauibtT6ASk2RoTmQmMVWw44aSulcaz6eVqa21zpEwOZVMX/VW3QM+
vKh4Vy6eVbCHmdOiXgtQSexQAN6uO1o9cHEGamJQpMshm+kax9T7hBdcHMH0ORtL
uEYHXzqB/bbkhAodHTraoZ5aM8YFwS2TgGtCJoYw1GHehMhjpJG9HaDlL50lkObk
LDUShta8AwN9iu3/qmkaYaxkbBPEnRtU9d9qO6S1NsZugBmmEUj6lNKFOK13U9Ho
vjKWTpB4USgKdrTwJXEAXJTBmubwrPBnZb1vdCovCtC3JS7sXUH8AM/E6tp4Q0Go
idGCjMglaSFO8EUeScFT
=QZIW
-----END PGP SIGNATURE-----
Merge tag 'drm/gem-cma/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux into drm-next
drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input
Some drivers erroneously treat the .pitch and .size fields of struct
drm_mode_create_dumb as inputs. While the include/uapi/drm/drm_mode.h
header has a comment denoting them as outputs, that seemingly wasn't
enough to make drivers use them properly.
The result is that some userspace doesn't explicitly zero out those
fields, assuming that the kernel won't use them. That causes problems
since the data within the structure might be uninitialized, so bogus
data may end up confusing drivers (ridiculously large values for the
pitch, ...).
This series attempts to improve the situation by fixing all drivers to
not use the output fields. Furthermore to spare new drivers this bad
surprise, the DRM core now zeros out these fields prior to handing the
data structure to the driver.
Lessons learned from this are that future IOCTLs should be properly
documented (in the DRM DocBook for example) and should be rigorously
defined. To prevent misuse like this, userspace should be required to
zero out all output fields. The kernel should check for this and fail
if that's not the case.
* tag 'drm/gem-cma/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux:
drm/cma: Remove call to drm_gem_free_mmap_offset()
drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input
drm/rcar: gem: dumb: pitch is an output
drm/omap: gem: dumb: pitch is an output
drm/cma: Introduce drm_gem_cma_dumb_create_internal()
drm/doc: Add GEM/CMA helpers to kerneldoc
drm/doc: mm: Fix indentation
drm/gem: Fix a few kerneldoc typos
This passes the guest preferences for a where to place the
outputs through to userspace. Userspace would need to be updated
to take note of this information, X server and GNOME.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Virtual GPUs would like to give the guest some indication where on the screen
the outputs are layed out. So far we only provide modes, these
properties could be exposed to userspace so the desktop environment
could use them as hints to set the correct offsets.
v2: rename properties to be more consistent.
Signed-off-by: Dave Airlie <airlied@redhat.com>
While looking through drm_crtc.c to double-check make locking changes
I've noticed that there's a few other places that would now benefit
from simplified return value handling.
So let's flatten the control flow and replace and always 0 ret with 0
where possible.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The highlights in this pull request are:
* IOMMU support: The Tegra DRM driver can now deal with discontiguous
buffers if an IOMMU exists in the system. That means it can allocate
using drm_gem_get_pages() and will map them into IOVA space via the
IOMMU API. Similarly, non-contiguous PRIME buffers can be imported
from a different driver, which allows better integration with gk20a
(nouveau) and less hacks.
* Universal planes: This is precursory work for atomic modesetting and
will allow hardware cursor support to be implemented on pre-Tegra114
where RGB cursors were not supported.
* DSI ganged-mode support: The DSI controller can now gang up with a
second DSI controller to drive high resolution DSI panels.
Besides those bigger changes there is a slew of fixes, cleanups, plugged
memory leaks and so on.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUZM29AAoJEN0jrNd/PrOhd1EP/iGBGppcPiYhFI6CC2V5IyGO
j4GaNU656QQj0RNS3RH0Oby0oHdQum2rFNtHnkGYjoXFiSznId3OwVQ1+Y1s5804
BkPSR1Q3fyIfsQdGA9DEkVGuyavCEbJ9yOalIBLda456nxfkPFBJdNjq5AJDT2N1
J54MSRtV3fV5Uerd7WbmiNdLyuly4Gyyb7ApotOQEsfYvaGgobdpMRGyp38tvYbD
pNDZ69iYBSJmaVaF1a/NxFw3/25CSHakY5J95R9eXK1Y3BKDBhqHo7b1L1XMt1L5
yKEy+eqjnnB7/itszjKG3dnMHunKsch9C+nyxR4xKMf036Pesz65tMbg07Pd0cIy
oYZMDGdm380d0mu41LydN7zK/ZZf6bBfcZallnxk1CSEQB6BcMZhOmQP2aa8r9rU
VdaNGlNio7XAjVGDsd8Y652y27NH7VJTpx3nxXB0f7eyGg7AlfLKxOFehDE+beVJ
OAzRQrHJ63vOIAUg21G84W4cvpsVSG4FomgRTXC8Se6WcwP3TWD5MmOzLYNjbFnb
ayuIiIfNtyu2KJU60hCOqWQg05UcWIYRkvxmdnQQcFyItmw4qJzh9ep7ebAqTx0t
0p0y5/O7KGYKS1pB7o1XJtL84N7SPiNGB3fdwiGryl9Z7hypuhKS7/lRBDTiiTAd
Ok1HHSRDxTaiGhrN3TKH
=v4QW
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux into drm-next
drm/tegra: Changes for v3.19-rc1
The highlights in this pull request are:
* IOMMU support: The Tegra DRM driver can now deal with discontiguous
buffers if an IOMMU exists in the system. That means it can allocate
using drm_gem_get_pages() and will map them into IOVA space via the
IOMMU API. Similarly, non-contiguous PRIME buffers can be imported
from a different driver, which allows better integration with gk20a
(nouveau) and less hacks.
* Universal planes: This is precursory work for atomic modesetting and
will allow hardware cursor support to be implemented on pre-Tegra114
where RGB cursors were not supported.
* DSI ganged-mode support: The DSI controller can now gang up with a
second DSI controller to drive high resolution DSI panels.
Besides those bigger changes there is a slew of fixes, cleanups, plugged
memory leaks and so on.
* tag 'drm/tegra/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux: (44 commits)
drm/tegra: gem: Check before freeing CMA memory
drm/tegra: fb: Add error codes to error messages
drm/tegra: fb: Properly release GEM objects on failure
drm/tegra: Detach panel when a connector is removed
drm/tegra: Plug memory leak
drm/tegra: gem: Use more consistent data types
drm/tegra: fb: Do not destroy framebuffer
drm/tegra: gem: dumb: pitch and size are outputs
drm/tegra: Enable the hotplug interrupt only when necessary
drm/tegra: dc: Universal plane support
drm/tegra: dc: Registers are 32 bits wide
drm/tegra: dc: Factor out DC, window and cursor commit
drm/tegra: Add IOMMU support
drm/tegra: Fix error handling cleanup
drm/tegra: gem: Use dma_mmap_writecombine()
drm/tegra: gem: Remove redundant drm_gem_free_mmap_offset()
drm/tegra: gem: Cleanup tegra_bo_create_with_handle()
drm/tegra: gem: Extract tegra_bo_alloc_object()
drm/tegra: dsi: Set up PHY_TIMING & BTA_TIMING registers earlier
drm/tegra: dsi: Replace 1000000 by USEC_PER_SEC
...
This is a small collection of fixes that I've been carrying around for a
while now. Many of these have been posted and reviewed or acked. The few
that haven't I deemed too trivial to bother.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUZKenAAoJEN0jrNd/PrOhNwkQAJTGxhol/k0Vj+P+HVj+MROU
9EEw67mh/c2Y4zQxEmWRE/rHdIgoz4zPL5hoJLLjPmorvKil6BIfURUybxYu9n3b
MrunoA7adxvL+Uce+XMkuvWUE2fxFNaEwU+FT66Ib+Lo8A25FZXBqo125/RmhAHZ
EQKcr0MBH76jybYoyB1H1pf/O3i6qODmh3kXT4Fved3jf5mZNPl5wgCSSr/4ilOZ
wx3pzG3BvIrsyvGF6Q0oAjDEbaBTOhglfAvPFhC16cfhtPJMzVvx6v/abtipMjRv
pUY3t96BvL1pyszcEc/ykjDX/ODlY00uOe1GgRSSXS/bThF0HJP14rTpjO+6ycON
rap17o2feRuK3c2NzLMqv4bjkaNF/ut+2YnByulJWnpg1dDjIpJOzJ6Heep5D6+H
lV5QP0B9LGI4718le2tv5hkH0NnQygiyRlACRzLBpq9gnXuSoSZYxjo6SuVid1X8
Ebs+QKNoTl1NEYeEvT/CnC552MdWzntcNjE9SA1yj0RgrIS87x8bmXqh/zAwa2dI
1Lq1wZ965ruDUPCGrd6jE8JiiEEXJjJr0y6zA4LBnR+OvmR/2GN7KCwjX+jwBthq
9dyO9YEnxSXT/dFEUumx3F4ZKcPUntT61pT6ZblIljiJ5vw6SegDXdWDc+eZ4QyD
y2YyxRL+KxPftkeyfU4j
=OUaP
-----END PGP SIGNATURE-----
Merge tag 'drm/fixes/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux into drm-next
drm: Miscellaneous fixes for v3.19-rc1
This is a small collection of fixes that I've been carrying around for a
while now. Many of these have been posted and reviewed or acked. The few
that haven't I deemed too trivial to bother.
* tag 'drm/fixes/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux:
video/hdmi: Relicense header under MIT license
drm/gma500: mdfld: Reuse video/mipi_display.h
drm: Make drm_mode_create_tv_properties() signature consistent
drm: Implement drm_get_pci_dev() dummy for !PCI
drm/prime: Use unsigned type for number of pages
drm/gem: Fix typo in kerneldoc
drm: Use const data when creating blob properties
drm: Use size_t for blob property sizes
This contains support for a couple of new panels, updates for some GPIO
API changes and a bunch of updates to the MIPI DSI support that should
make it easier to write panel drivers in the future.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUZKsmAAoJEN0jrNd/PrOhvoQP/Ryl8OHSEOB6vNxn7cmz3nQf
0l+2Q3V3qpJALC3Dlm57kSF1760mHNjPuwiVLhjINn5zcDS4kB3Llgx/dmAzgTZA
Ikm8iDgcOmlBUBE1W5YuzdSCXJK8Eth9JQiA4yQVS0RWi+WEClwb+F7KBLi+9Ep3
1C3qURrBAfe9DRzU4GswrsCzBQACCKH8f+2OcYeFMW0eMa7ejHNs+n0wi6lMLvLn
JrxEuMBKWdXbM2sw4UXvpVZm3CTh8dJtXBkpwOBK75XhY9DSsrqmbdk0qKIDCY+y
JB/5UTU2sg37ZFnvhFoHN10AtXWnGbwS2iCitNSmKaBOARVbcoWk9pJtR3AHc44c
cpLVTsJgZStYZAydtVZKQDJWLNTnTMtyLPcy9eq6kLMc8sVe930U8IsGQyihyyUU
cSDP8Z6THZ2zHqfDnmogjm8XWsUa+LimNwAgm5oub8JKxdqGb49J8ry+Ny4a19cS
MgqVZE85K9aF7e/VxeGFiIpUb5ax5bLQxrcpVJg/d2TFuftNBslmL3FOkvEbwrLM
WS9KJ8e8VIRNoI5dtemfx0+LGlLwoPaUWSeWpb8OxUAuy6e5NabazkFQuCb5E+HM
JLqnMFCCVvwtGyr+DrFiF4ye8ZTZNcFcdidgB4mr9D5k7RksyeZTT4vz13y2JyAr
VcfbBQICIQzn91osEetJ
=+xMK
-----END PGP SIGNATURE-----
Merge tag 'drm/panel/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux into drm-next
drm/panel: Changes for v3.19-rc1
This contains support for a couple of new panels, updates for some GPIO
API changes and a bunch of updates to the MIPI DSI support that should
make it easier to write panel drivers in the future.
* tag 'drm/panel/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux: (31 commits)
drm/panel: Add Sharp LQ101R1SX01 support
drm/dsi: Do not require .owner field to be set
drm/dsi: Resolve MIPI DSI device from phandle
drm/dsi: Implement DCS set_{column,page}_address commands
drm/dsi: Implement DCS {get,set}_pixel_format commands
drm/dsi: Implement DCS get_power_mode command
drm/dsi: Implement DCS soft_reset command
drm/dsi: Implement DCS nop command
drm/dsi: Add to DocBook documentation
drm/dsi: Implement some standard DCS commands
drm/dsi: Implement generic read and write commands
drm/panel: s6e8aa0: Use standard MIPI DSI function
drm/dsi: Add mipi_dsi_set_maximum_return_packet_size() helper
drm/dsi: Constify mipi_dsi_msg
drm/dsi: Make mipi_dsi_dcs_{read,write}() symmetrical
drm/dsi: Add DSI transfer helper
drm/dsi: Add message to packet translator
drm/dsi: Introduce packet format helpers
drm/panel: s6e8aa0: Fix build warnings on 64-bit
drm/panel: ld9040: Fix build warnings on 64-bit
...
- skl watermarks code (Damien, Vandana, Pradeep)
- reworked audio codec /eld handling code (Jani)
- rework the mmio_flip code to use the vblank evade logic and wait for rendering
using the standard wait_seqno interface (Ander)
- skl forcewake support (Zhe Wang)
- refactor the chv interrupt code to use functions shared with vlv (Ville)
- prep work for different global gtt views (Tvrtko Ursulin)
- precompute the display PLL config before touching hw state (Ander)
- completely reworked panel power sequencer code for chv/vlv (Ville)
- pre work to split the plane update code into a prepare and commit phase
(Gustavo Padovan)
- golden context for skl (Armin Reese)
- as usual tons of fixes and improvements all over
* tag 'drm-intel-next-2014-11-07-fixups' of git://anongit.freedesktop.org/drm-intel: (135 commits)
drm/i915: Use correct pipe config to update pll dividers. V2
drm/i915: Plug memory leak in intel_shared_dpll_start_config()
drm/i915: Update DRIVER_DATE to 20141107
drm/i915: Add gen to the gpu hang ecode
drm/i915: Cache HPLL frequency on VLV/CHV
Revert "drm/i915/vlv: Remove check for Old Ack during forcewake"
drm/i915: Make mmio flip wait for seqno in the work function
drm/i915: Make __wait_seqno non-static and rename to __i915_wait_seqno
drm/i915: Move the .global_resources() hook call into modeset_update_crtc_power_domains()
drm/i915/audio: add DOC comment describing HDA over HDMI/DP
drm/i915: make pipe/port based audio valid accessors easier to use
drm/i915/audio: add audio codec enable debug log for g4x
drm/i915/audio: add audio codec disable on g4x
drm/i915: enable audio codec after port
drm/i915/audio: add vlv/chv/gen5-7 audio codec disable sequence
drm/i915/audio: rewrite vlv/chv and gen 5-7 audio codec enable sequence
drm/i915/skl: Enable Gen9 RC6
drm/i915/skl: Gen9 Forcewake
drm/i915/skl: Log the order in which we flush the pipes in the WM code
drm/i915/skl: Flush the WM configuration
...
Don't BUG out if the link reports an invalid (or plain unknown)
bandwidth value, but report the failure and fail gracefully.
Fixes a trivial compiler warning in case the BUG is ever compiled away.
Link: http://lkml.kernel.org/p/1415785566-12758-1-git-send-email-geert@linux-m68k.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For async commit, it is *intentional* that those locks are not held.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now that we're using lists instead of kfifo to store drm flip-work tasks
we do not need the size parameter passed to drm_flip_work_init function
anymore.
Moreover this function cannot fail anymore, we can thus remove the return
code.
Modify drm_flip_work_init users to take account of these changes.
[airlied: fixed two unused variable warnings]
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make use of lists instead of kfifo in order to dynamically allocate
task entry when someone require some delayed work, and thus preventing
drm_flip_work_queue from directly calling func instead of queuing this
call.
This allow drm_flip_work_queue to be safely called even within irq
handlers.
Add new helper functions to allocate a flip work task and queue it when
needed. This prevents allocating data within irq context (which might
impact the time spent in the irq handler).
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use the new pipe config values to calculate the updated pll dividers.
This regression was introduced in
commit 0dbdf89f27b17ae1eceed6782c2917f74cbb5d59
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Wed Oct 29 11:32:33 2014 +0200
drm/i915: Add infrastructure for choosing DPLLs before disabling crtcs
and
commit 00d958817dd3daaa452c221387ddaf23d1e4c06f
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Wed Oct 29 11:32:36 2014 +0200
drm/i915: Covert remaining platforms to choose DPLLS before disabling CRTCs
v2: Use intel_pipe_will_have_type() to look at new configuration - Ander
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
CC: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
dma_free_writecombine() must not be called on a buffer that couldn't be
allocated. Check for a valid virtual address before attempting to free
the memory to avoid a crash.
Reported-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When fbdev initialization fails, make sure to unreference the GEM
objects properly. Note that we can't do this in the general error
unwinding path because ownership of the GEM object references is
transferred to the framebuffer upon creation.
Signed-off-by: Thierry Reding <treding@nvidia.com>
When the DRM device is torn down and the connector is removed, make sure
to detach the panel to make sure there are no dangling pointers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Drop a reference instead of directly calling the framebuffer .destroy()
callback at fbdev free time. This is necessary to make sure the object
isn't destroyed if anyone else still has a reference.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
IOCTL, only the width, height, bpp and flags parameters are inputs. The
caller is not guaranteed to zero out or set handle, pitch and size, so
the driver must not treat these values as possible inputs.
Fixes a bug where running the Weston compositor on Tegra DRM would cause
an attempt to allocate a 3 GiB framebuffer to be allocated.
Fixes: de2ba664c3 ("gpu: host1x: drm: Add memory manager and fb")
Cc: stable@vger.kernel.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
The hotplug handling needs access to the DRM device, which only appears
at ->init() time. Disable interrupts up until that time. Similarly, when
an output is removed, disable the hotplug interrupt again because the
DRM device (and with it the hotplug infrastructure) is going away.
Also make sure to only access the DRM device if it's available. Given
the above change for the hotplug interrupt this should really never
happen, but the extra check doesn't hurt either.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This allows the primary plane and cursor to be exposed as regular
DRM/KMS planes, which is a prerequisite for atomic modesetting and gives
userspace more flexibility over controlling them.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Using an unsigned long type will cause these variables to become 64-bit
on 64-bit SoCs. In practice this should always work, but there's no need
for carrying around the additional 32 bits.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The sequence to commit changes to the DC, window or cursor configuration
is repetitive and can be extracted into separate functions for ease of
use.
Signed-off-by: Thierry Reding <treding@nvidia.com>
When an IOMMU device is available on the platform bus, allocate an IOMMU
domain and attach the display controllers to it. The display controllers
can then scan out non-contiguous buffers by mapping them through the
IOMMU.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The DRM driver's ->load() implementation didn't do a good job (no job at
all really) cleaning up on failure. Fix that by undoing any prior setup
when an error occurs. This requires a bit of rework to make it possible
to clean up fbdev midway.
This was tested by injecting errors at various points during the
initialization sequence and verifying that error cleanup didn't crash
and no memory leaked (using kmemleak).
Reported-by: Stéphane Marchesin <marcheu@chromium.org>
Reported-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The drm_gem_object_release() function already performs this cleanup, so
there is no reason to do it explicitly.
Signed-off-by: Thierry Reding <treding@nvidia.com>
There is only a single location where the function needs to do cleanup.
Skip the error unwinding path and call the cleanup function directly
instead.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This function implements the common buffer object allocation used for
both allocation and import paths.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Make sure the DSI PHY_TIMING and BTA_TIMING registers are initialized
when the clocks are set up as opposed to when the output is enabled.
This makes sure that the PHY timings are properly set up when the panel
is prepared and that DCS commands sent at that time use the appropriate
timings.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support for sending MIPI DSI command packets from the host to a
peripheral. This is required for panels that need configuration before
they accept video data.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Implement ganged mode support for the Tegra DSI driver. The DSI host
controller to gang up with is specified via a phandle in the device tree
and the resolved DSI host controller used for the programming of the
ganged-mode registers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
In preparation for adding ganged-mode support, this commit splits out
the tegra_dsi_set_timeout() function so that it can be reused for the
slave DSI controller.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support for DC-driven command mode. This is a mode where the video
stream sent by the display controller is packed into DCS command packets
(write_memory_start and write_memory_continue) by the DSI controller. It
can be used for panels with a remote framebuffer and is useful to save
power when used with a dynamic refresh rate (not yet supported by the
driver).
Signed-off-by: Thierry Reding <treding@nvidia.com>
For command mode panels, the DSI controller needs to be enabled and
configured so that panel drivers can send commands prior to the video
stream being enabled.
Move code from the monolithic output enable/disable functions into
smaller, reusable units to allow more fine-grained control over the
controller state.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The driver wasn't even attempting to do any cleanup when probing failed.
Fix this by releasing any resources acquired up to the point of failure
and putting the device back into the original state (reset, clocks off).
Signed-off-by: Thierry Reding <treding@nvidia.com>
DSI panels can always be hotplugged via the DSI bus' attach/detach
infrastructure, so unconditionally mark the connector hotpluggable.
While at it, also make sure that when a panel is detached the connector
is marked unconnected before calling into the DRM hotplug helpers to
reflect the correct state.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The common clock framework will take care of preparing and enabling the
parent of the DSI clock automatically.
Signed-off-by: Thierry Reding <treding@nvidia.com>
In preparation for supporting command mode panels, don't disable the
clock when the output is disabled. The output will be enabled only after
the panel has been programmed in command mode, so the clock must always
remain on.
As a side-effect, pad calibration now only needs to be done at driver
probe time, since neither power nor controller state will go away before
driver removal. While at it, use a 32-bit variable to store register
content because the registers are 32-bit even on 64-bit Tegra.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Rather than hardcoding them as macros, make the host and video FIFO
depths parameters so that they can be more easily adjusted if a new
generation of the Tegra SoC changes them.
While at it, set the depth of the video FIFO to the correct value of
1920 *words* rather than *bytes*.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Previously the panel and output were only enabled on encoder->dpms(). If
userspace called dpms on before doing a modeset, the driver would get into
a state where the connector had a dpms state of ON, but the encoder and output
were not enabled (because the encoder is not yet attached to the connector).
Subsequent dpms ON calls are ignored b/c the connector's state already matches
the desired state.
This patch enables/disables the panel and output on modeset as well, so we
can catch the above case.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Both display controllers are in their own power partition. Currently the
driver relies on the assumption that these partitions are on (which is
the hardware default). However some bootloaders may disable them, so the
driver must make sure to turn them back on to avoid hangs.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The introduction of the COMPILE_TEST dependency in commit 158b50aefa
(drm/tegra: Increase compile test coverage) removes the dependency on
COMMON_CLK (implicitly selected via ARCH_TEGRA, ARCH_MULTI_V7 and
ARCH_MULTIPLATFORM).
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This panel requires dual-channel mode. The device accepts command-mode
data on 8 lanes and will therefore need a dual-channel DSI controller.
The two interfaces that make up this device need to be instantiated in
the controllers that gang up to provide the dual-channel DSI host.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Drivers now no longer need to set the .owner field. It will be
automatically set at registration time.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add a function, of_find_mipi_dsi_device_by_node(), that can be used to
resolve a phandle to a MIPI DSI device.
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Provide small convenience wrappers to set the column and page extents of
the frame memory accessed by the host processors.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Provide small convenience wrappers to query or set the pixel format used
by the interface.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Provide a small convenience wrapper that transmits a DCS get_power_mode
command. A set of bitmasks for the mode bits is also provided.
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Provide a small convenience wrapper that transmits a DCS soft_reset
command.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Provide a small convenience wrapper that transmits a DCS nop command.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Integrate the MIPI DSI helpers into DocBook and clean up various
kerneldoc warnings. Also add a brief DOC section and clarify some
aspects of the mipi_dsi_host struct's .transfer() operation.
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add helpers for the {enter,exit}_sleep_mode, set_display_{on,off} and
set_tear_{on,off} DCS commands.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
[treding: kerneldoc and other minor cleanup]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Implement generic read and write commands. Selection of the proper data
type for packets is done automatically based on the number of parameters
or payload length.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use the newly introduced mipi_dsi_set_maximum_return_packet_size()
function to replace an open-coded version.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This function can be used to set the maximum return packet size for a
MIPI DSI peripheral.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
[treding: endianess, kerneldoc, return value]
Signed-off-by: Thierry Reding <treding@nvidia.com>
struct mipi_dsi_msg is a read-only structure, drivers should never need
to modify it. Make this explicit by making all references to the struct
const.
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Currently the mipi_dsi_dcs_write() function requires the DCS command
byte to be embedded within the write buffer whereas mipi_dsi_dcs_read()
has a separate parameter. Make them more symmetrical by adding an extra
command parameter to mipi_dsi_dcs_write().
The S6E8AA0 driver relies on the old asymmetric API and there's concern
that moving to the new API may be less efficient. Provide a new function
with the old semantics for those cases and make the S6E8AA0 driver use
it instead.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
A common pattern is starting to emerge for higher level transfer
helpers. Create a new helper that encapsulates this pattern and avoids
code duplication.
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This commit introduces a new function, mipi_dsi_create_packet(), which
converts from a MIPI DSI message to a MIPI DSI packet. The MIPI DSI
packet is as close to the protocol described in the DSI specification as
possible and useful in drivers that need to write a DSI packet into a
FIFO to send a message off to the peripheral.
Suggested-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add two helpers, mipi_dsi_packet_format_is_{short,long}(), that help in
determining the format of a packet.
Signed-off-by: Thierry Reding <treding@nvidia.com>
drm_gem_object_release() called later in the drm_gem_cma_free_object()
function already calls this, so there's no need to do this explicitly.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Some drivers treat the pitch and size fields as inputs and will use them
as minima provided by userspace so that they are only overwritten if the
minimal requirements of the driver exceed them.
This can cause strange behaviour when applications don't zero out these
fields, causing whatever was on the stack to be passed to the IOCTL. In
a typical case this would become visible as a failed allocation if the
pitch or size were unusually high. But this could also cause more subtle
bugs like overallocating dumb framebuffers.
To prevent drivers from misusing these values, make the DRM core zero
out the pitch and size fields before passing the structure to the driver
implementation.
While at it, also set the output handle field to zero for good measure,
even though it's less likely to be abused.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
IOCTL, only the width, height, bpp and flags fields are inputs. The
caller is not guaranteed to zero out or set handle, pitch and size.
Drivers must not treat these values as possible inputs, otherwise they
may use uninitialized memory during the computation of the framebuffer
size.
The R-Car DU driver treats the pitch passed in from userspace as minimum
and will only overwrite it when the driver-computed pitch is larger,
allowing userspace to, intentionally or not, overallocate framebuffers.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
IOCTL, only the width, height, bpp and flags fields are inputs. The
caller is not guaranteed to zero out or set handle, pitch and size.
Drivers must not treat these values as possible inputs, otherwise they
may use uninitialized memory during the computation of the framebuffer
size.
The OMAP driver uses the pitch field passed in by userspace as a minimum
and only override it if the driver-computed pitch is larger than what
userspace provided. To prevent this from causing overallocation, fix the
minimum pitch to 0 to enforce the driver-computed pitch.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This function is similar to drm_gem_cma_dumb_create() but targetted at
kernel internal users so that they can override the pitch and size
requirements of the dumb buffer.
It is important to make this difference because the IOCTL says that the
pitch and size fields are to be considered outputs and therefore should
not be used in computations of the framebuffer size. Internal users may
still want to use this code to avoid duplication and at the same time
pass on additional, driver-specific restrictions on the pitch and size.
While at it, convert the R-Car DU driver, the single user that overrides
the pitch, to use the new internal helper.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Most of the functions already have the beginnings of kerneldoc comments
but are using the wrong opening marker. Use the correct opening marker
and flesh out the comments so that they can be integrated with the DRM
DocBook document.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
While at it, adjust the drm_gem_handle_create() function declaration to
be more consistent with other functions in the file.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The GMA500 driver redefines many constants already found in the generic
header. Replace uses of the custom defines by the standard ones and get
rid of the duplicate defininitions.
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The prototype and the function implementation differ in their signature.
Make them consistent and use an unsigned integer for the number of modes
while at it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The number of pages can never be negative, so an unsigned type is
enough. This also matches the type of the n_pages argument of the
sg_alloc_table_from_pages() function.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Creating a blob property will always copy the input data so the data
that is passed in can be const.
Signed-off-by: Thierry Reding <treding@nvidia.com>
size_t is the standard type when dealing with sizes of all kinds. Use it
consistently when instantiating DRM blob properties.
Signed-off-by: Thierry Reding <treding@nvidia.com>
These two arrays don't change, just make them constant,
reduces data segment by a few bytes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
DRM_MM_SEARCH_BEST gets the smallest hole which can fit the BO. That seems
against the idea of TTM_PL_FLAG_TOPDOWN:
* The smallest hole may be in the overall bottom of the area
* If the hole isn't much larger than the BO, it doesn't make much
difference whether the BO is placed at the bottom or at the top of the
hole
Reviewed-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If the BO should be placed at the top of the area, we should start looking
for holes from the top.
Reviewed-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
I wasn't sure if TTM_PL_FLAG_TOPDOWN works correctly with non-0 lpfn, but
AFAICT it does.
Reviewed-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This avoids them getting in the way of BOs which might be accessed by
the CPU. They can still go to the CPU accessible part of VRAM though if
there's no space outside of it.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The cleanup path would reset pll->new_config to NULL but wouldn't free
the allocated memory.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Motivated by the per-plane locking I've gone through all the get*
ioctls and reduced the locking to the bare minimum required.
v2: Rebase and make it compile ...
v3: Review from Sean:
- Simplify return handling in getplane_res.
- Add a comment to getplane_res that the plane list is invariant and
can be walked locklessly.
v4: Actually git add.
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Turned out to be much simpler on top of my latest atomic stuff than
what I've feared. Some details:
- Drop the modeset_lock_all snakeoil in drm_plane_init. Same
justification as for the equivalent change in drm_crtc_init done in
commit d0fa1af40e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Sep 8 09:02:49 2014 +0200
drm: Drop modeset locking from crtc init function
Without these the drm_modeset_lock_init would fall over the exact
same way.
- Since the atomic core code wraps the locking switching it to
per-plane locks was a one-line change.
- For the legacy ioctls add a plane argument to the locking helper so
that we can grab the right plane lock (cursor or primary). Since the
universal cursor plane might not be there, or someone really crazy
might forgoe the primary plane even accept NULL.
- Add some locking WARN_ON to the atomic helpers for good paranoid
measure and to check that it all works out.
Tested on my exynos atomic hackfest with full lockdep checks and ww
backoff injection.
v2: I've forgotten about the load-detect code in i915.
v3: Thierry reported that in latest 3.18-rc vmwgfx doesn't compile any
more due to
commit 21e88620aa
Author: Rob Clark <robdclark@gmail.com>
Date: Thu Oct 30 13:39:04 2014 -0400
drm/vmwgfx: fix lock breakage
Rebased and fix this up.
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
v1: original
v2: danvet's kerneldoc nitpicks
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUX/DqAAoJEHm+PkMAQRiGLtQH/iAt3fRHlYDXjaJian/KG1Cb
wVP0I+HWZmvVmmd0PzyaxCZLgRNwdmmYHEH4QLy2JwZ3jZfFHlxhy+hDWCgz+67t
bIzkLs0Pf1T4kJ2+r8qW2kBEz9PWJHGTQw7NTqZ++Ts3rPptBA6Fg4mEJ6fQigXy
qRIY68DpipUkXV9BWBWijnTmrvP5tt7JtPzBr4DC8frMjvWct8+XwYhc2k2tEv2j
LwLYb1OW6PUpPv2BQBfWjqqH77vYNQVhJwuwGcDe2YZdI0UFkDheL24+RbbPcZ4f
OnrLjJSSgzv6lBWkAaXZK7/WJ/JZbXxEqHzWZQ3xXoQov97bm7lEYJqqi5gDasQ=
=6Qpa
-----END PGP SIGNATURE-----
Merge tag 'v3.18-rc4' into drm-next
backmerge to get vmwgfx locking changes into next as the
conflict with per-plane locking.
Backmerge drm-next so that I can keep merging patches. Specifically I
want:
- atomic stuff, yay!
- eld parsing patch from Jani.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
These two didn't get documented properly, do so.
Pointed out by Daniel.
v1.1: add missing boilerplate (Daniel)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
So here's my atomic series, finally all debugged&reviewed. Sean Paul has
done a full detailed pass over it all, and a lot of other people have
commented and provided feedback on some parts. Rob Clark also converted
msm over the w/e and seems happy. The only small thing is that Rob wants
to export the wait_for_vblank, which imo makes sense. Since there's other
stuff still to do I think we should apply Rob's patch (once it has grown
appropriate kerneldoc) later on top of this.
This is just the core<->driver interface plus a big pile of helpers. Short
recap of the main ideas:
- There are essentially three helper libraries in this patch set:
* Transitional helpers to use the new plane callbacks for legacy plane
updates and in the crtc helper's ->mode_set callback. These helpers are
only temporarily used to convert drivers to atomic, but they allow a
nice separation between changing the driver backend and switching to
the atomic commit logic.
* Legacy helpers to implement all the legacy driver entry points
(page_flip, set_config, plane vfuncs) on top of the new atomic driver
interface. These are completely driver agnostic. The reason for having
the legacy support as helpers is that drivers can switch step-by-step.
And they could e.g. even keep the legacy page_flip code around for some
old platforms where converting to full-blown atomic isn't worth it.
* Atomic helpers which implement the various new ->atomic_* driver
interfaces in terms of the revised crtc helper and new plane helper
hooks.
- The revised crtc helper implemenation essentially implements all the
lessons learned in the i915 modeset rework (when using the atomic helpers
only):
* Enable/disable sequence for a given config are always the same and
callbacks are always called in the same order. This contrast starkly
with the crtc helpers, where the sequence of operations is heavily
dependent on the previous config.
One corollary of this is that if the configuration of a crtc only
partially changes (e.g. a connector moves in a cloned config) the
helper code will still disable/enable the full display pipeline. This
is the only way to ensure that the enable/disable sequence is always
the same.
* It won't call disable or enable hooks more than once any more because
it lost track of state, thanks to the atomic state tracking. And if
drivers implement the ->reset hook properly (by either resetting the hw
or reading out the hw state into the atomic structures) this even
extends to the hardware state. So no more disable-me-harder kind of
nonsense.
* The only thing missing is the hw state readout/cross-check support, but
if drivers have hw state readout support in their ->reset handlers it's
simple to extend that to cross-check the hw state.
* The crtc->mode_set callback is gone and its replacement only sets crtc
timings and no longer updates the primary plane state. This way we can
finally implement primary planes properly.
- The new plane helpers should be suitable enough for pretty much
everything, and a perfect fit for hardware with GO bits. Even if they
don't fit the atomic helper library is rather flexible and exports all
the functions for the individual steps to drivers. So drivers can pick
what matches and implement their own magic for everything else.
- A big difference compared to all previous atomic series is that this one
doesn't implement async commit in a generic way. Imo driver requirements
for that are too diverse to create anything reasonable sane which would
actually work on a reasonable amount of different drivers. Also, we've
never had a helper library for page_flips even, so it's really hard to
know what might work and what's stupid without a bit of experience in the form
of a few driver implementations.
I think with the current flexibility for drivers to pick individual
stages and existing helpers like drm_flip_queue it's rather easy though
to implement proper async commit.
- There's a few other differences of minor importance to earlier atomic
series:
* Common/generic properties are parsed in the callers/core and not in
drivers, and passed to drivers by directly setting the right members in
atomic state structures. That greatly simplifies all the transitional
and legacy helpers an removes a lot of boilerplate code.
* There's no crazy trylock mode used for the async commit since these
helpers don't do async commit. A simple ordered flip queue of atomic
state updates should be sufficient for preventing concurrent hw access
anyway, as long as synchronous updates stall correctly with e.g.
flush_work_queue or similar function. Abusing locks to enforce ordering
isn't a good idea imo anyway.
* These helpers reuse the existing ->mode_fixup hooks in the atomic_check
callback. Which means that drivers need to adapat and move a lot less code
into their atomic_check callbacks.
Now this isn't everything needed in the drm core and helpers for full
atomic support. But it's enough to start with converting drivers, and
except for actually testing multiplane and multicrtc updates also enough to
implement full atomic updates. Still missing are:
- Per-plane locking. Since these helpers here encapsulate the locking
completely this should be fairly easy to implement.
- fbdev support for atomic_check/commit, so that multi-pipe finally works
sanely in fbcon.
- Adding and decoding shared/core properties. That just needs to be rebased
from Rob's latest patch series, with minor adjustments so that the
decoding happens in the core instead of in drivers.
- Actually adding the atomic ioctl. Again just rebasing Rob's latest patch
should be all that's needed.
- Resolving how to deal with DPMS in atomic. Atomic is a good excuse to fix up
the crazy semantics dpms currently has. I'm floating an RFC about this topic
already.
- Finally I couldn't test connector/encoder stealing properly since my test
vehicle here doesn't allow a connector on different crtcs. So drivers
which support this might see some surprises in that area. There is no semantic
change though in how encoder stealing and assignment works (or at least no
intended one), so I think the risk is minimal.
As just mentioned I've done a fake conversion of an existing driver using
crtc helpers to debug the helper code and validate the smooth transition
approach. And that smooth transition was the really big motivation for
this. It seems to actually work and consists of 3 phases:
Phase 1: Rework driver backend for crtc/plane helpers
The requirement here is that universal plane support is already implement. If
universal plane support isn't implement yet it might be better though to just do
it as part of this phase, directly using the new plane helpers. There are two
big things to do:
- Split up the existing ->update/disable_plane hooks into check/commit
hooks and extract the crtc-wide prep/flush parts (like setting/clearing
GO bits).
- The other big change is to split the crtc->mode_set hook into the plane
update (done using the plane helpers) and the crtc setup in a new
->mode_set_nofb hook.
When phase 1 is complete the driver implements all the new callbacks which
push the software state into hardware, but still using all the legacy entry
points and crtc helpers. The transitional helpers serve as impendance
mismatch here.
Phase 2: Rework state handling
This consists of rolling out the state handling helpers for planes, crtcs
and connectors and reviewing all ->mode_fixup and similar hooks to make
sure they don't depend upon implicit global state which might change in the
atomic world. Any such code must be moved into ->atomic_check functions which
just rely on the free-standing atomic state update structures.
This phase also adds a few small pieces of fixup code to make sure the
atomic state doesn't get out of sync in the legacy driver callbacks.
Phase 3: Roll out atomic support
Now it's just about replacing vfuncs with the ones provided by the helper
and filling out the small missing pieces (like atomic_check logic or async
commit support needed for page_flips). Due to the prep work in phase 1 no
changes to the driver backend functions should be required, and because of
the prep work in phase 2 atomic implementations can be rolled out
step-by-step. So if async commit ins't implemented yet page_flip can be
implemented with the legacy functions without wreaking havoc in the other
operations.
* tag 'topic/atomic-helpers-2014-11-09' of git://anongit.freedesktop.org/drm-intel:
drm/atomic: Refcounting for plane_state->fb
drm: Docbook integration and over sections for all the new helpers
drm/atomic-helpers: functions for state duplicate/destroy/reset
drm/atomic-helper: implement ->page_flip
drm/atomic-helpers: document how to implement async commit
drm/atomic: Integrate fence support
drm/atomic-helper: implementatations for legacy interfaces
drm: Atomic crtc/connector updates using crtc/plane helper interfaces
drm/crtc-helper: Transitional functions using atomic plane helpers
drm/plane-helper: transitional atomic plane helpers
drm: Add atomic/plane helpers
drm: Global atomic state handling
drm: Add atomic driver interface definitions for objects
drm/modeset_lock: document trylock_only in kerneldoc
drm: fixup kerneldoc in drm_crtc.h
drm: Pull drm_crtc.h into the kerneldoc template
drm: Move drm_crtc_init from drm_crtc.h to drm_plane_helper.h
amdkfd uses cpu_relax() in its sync_with_hw() function. Because cpu_relax() is
defined as 'REP; NOP' on x86_64, it will block the CPU from servicing
IOMMU PPR requests.
This may cause a deadlock, because sync_with_hw() won't be completed
until the PPR request has been served.
Therefore, we need to use schedule() instead of cpu_relax() as it is the
minimum requirement to allow other threads to execute.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
struct device_process_node was allocated during process registration but
not released at process deregistration.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jay Cornwall <jay.cornwall@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
This patch was done due to sparse warning. It changes the definition of
doorbell_ptr in queue_properties to be with __iomem attribute, so it would
match the type which the doorbell module functions are returning.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
We need the HPLL frequency when calculating cdclk. Currently we read
that out from the hardware every single time, which isn't going to fly
very well if the device is runtime suspended. So cache the HPLL
frequency in dev_priv and use the cached value.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 5cb13c07da.
While the relevance for WaRsDontPollForAckOnClearingFWBits is under
investigation, revert this as regression.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85684
Tested-by: Tested-by: lu hua <huax.lu@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: S, Deepak <deepak.s@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This simplifies the code quite a bit compared to iterating over all
rings during the ring interrupt.
Also, it allows us to drop the mmio_flip spinlock, since the mmio_flip
struct is only accessed in two places. The first is when the flip is
queued and the other when the mmio writes are done. Since a flip cannot
be queued while there is a pending flip, the two paths shouldn't ever
run in parallel. We might need to revisit that if support for replacing
flips is implemented though.
v2: Don't hold dev->struct_mutext while waiting (Chris)
v3: Make the wait uninterruptable (Chris)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So that it can be used by the flip code to wait for rendering without
holding any locks.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We may need to access various hardware bits in the .global_resources()
hook, so move the call to occur after enabling all the newly required
power wells, but before disabling all the now unneeded wells. This
should guarantee that we have all the sufficient hardware resources
available during the .global_resources() call. And if not, any additional
resources must be explicitly acquired by the .global_resorces() hook.
For instance on VLV/CHV we need to access the gunit mailbox so that we
can talk to punit/cck over sideband. In addition some PFI credit
reprogramming may need to be addes as well, which may require the disp2d
well.
This should also make the power domain refcounts consistent on platforms
which don't have a .global_resource() hook since now they too will
call modeset_update_crtc_power_domains() which will drop the init power.
Previously init power was just left enabled for such platforms.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: include the section in the drm docbook.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
