Dave Airlie [Fri, 14 Aug 2015 00:15:24 +0000 (10:15 +1000)]
Merge tag 'drm-amdkfd-next-fixes-2015-08-05' of git://people.freedesktop.org/~gabbayo/linux into drm-next
Two small bug fixes for the code you pulled for 4.3:
- Used a SHIFT define instead of a MASK define to check if a bit is turned on
when destroying hqd. Luckily, this is in gfx7 interface file with amdgpu,
which was used only for bring-up purposes of amdgpu, so no real effect on
a running system
- Used a logical AND instead of a bitwise AND operator, when initializing
sdma virtual memory when using SDMA queues
* tag 'drm-amdkfd-next-fixes-2015-08-05' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: fix bug when initializing sdma vm
drm/amdgpu: fix bug when amdkfd destroys hqd
Dave Airlie [Fri, 14 Aug 2015 00:14:23 +0000 (10:14 +1000)]
Merge branch 'drm-sti-next-atomic-2015-08-11' of http://git.linaro.org/people/benjamin.gaignard/kernel into drm-next
This serie of patches fix minor bugs around how driver sub-components are
bind and planes z-ordering.
The main part is about atomic support: using more atomic helpers allow us
to simplify the code (~300 lines removed) and to ahve a better match between
drm concepts (planes and crtc) and hardware split.
[airlied: fixed up conflict in atomic code]
* 'drm-sti-next-atomic-2015-08-11' of http://git.linaro.org/people/benjamin.gaignard/kernel:
drm/sti: atomic crtc/plane update
drm/sti: rename files and functions
drm/sti: code clean up
drm/sti: fix dynamic z-ordering
drm: sti: fix sub-components bind
Dave Airlie [Fri, 14 Aug 2015 00:02:21 +0000 (10:02 +1000)]
Merge tag 'topic/drm-misc-2015-08-13' of git://anongit.freedesktop.org/drm-intel into drm-next
Final drm-misc pull for 4.3:
- fbdev emulation Kconfig option for everyone thanks to Archit. It's not
everything yet bit this is fairly tricky since it spawns all drivers.
- vgaarb & vgaswitcheroo polish from Thierry
- some drm_irq.c cleanups (Thierry)
- struct_mutex crusade from me
- more fbdev panic handling removal
- various things all over in drm core&helpers
* tag 'topic/drm-misc-2015-08-13' of git://anongit.freedesktop.org/drm-intel: (65 commits)
drm/atomic: Use KMS VBLANK API
drm/irq: Document return values more consistently
drm/irq: Make pipe unsigned and name consistent
drm/irq: Check for valid VBLANK before dereference
drm/irq: Remove negative CRTC index special-case
drm/plane: Remove redundant extern
drm/plane: Use consistent data types for format count
vga_switcheroo: Remove unnecessary checks
vga_switcheroo: Wrap overly long lines
vga_switcheroo: Use pr_fmt()
vga_switcheroo: Cleanup header comment
vga_switcheroo: Use pr_*() instead of printk()
vgaarb: Fix a few checkpatch errors and warnings
vgaarb: Use vgaarb: prefix consistently in messages
vgaarb: Stop complaining about absent devices
drm/atomic: fix null pointer access to mode_fixup callback
drm/i915: Use CONFIG_DRM_FBDEV_EMULATION
drm/core: Set mode to NULL when connectors in a set drops to 0.
drm/atomic: Call ww_acquire_done after check phase is complete
drm/atomic: Paper over locking WARN in default_state_clear
...
Thierry Reding [Wed, 12 Aug 2015 15:00:35 +0000 (17:00 +0200)]
drm/atomic: Use KMS VBLANK API
Instead of using the legacy VBLANK API, use the new KMS API. This is
part of an effort to convert all existing users so that the KMS API can
be changed to properly use per-CRTC data.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thierry Reding [Wed, 12 Aug 2015 15:00:31 +0000 (17:00 +0200)]
drm/irq: Make pipe unsigned and name consistent
Name all references to the pipe number (CRTC index) consistently to make
it easier to distinguish which is a pipe number and which is a pointer
to struct drm_crtc.
While at it also make all references to the pipe number unsigned because
there is no longer any reason why it should ever be negative.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thierry Reding [Wed, 12 Aug 2015 15:00:30 +0000 (17:00 +0200)]
drm/irq: Check for valid VBLANK before dereference
When accessing the array of per-CRTC VBLANK structures we must always
check that the index into the array is valid before dereferencing to
avoid crashing.
Signed-off-by: Thierry Reding <treding@nvidia.com>
[danvet: Squash in my own whitespace ocd fixup in drm_vblank_count.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thierry Reding [Wed, 12 Aug 2015 15:00:24 +0000 (17:00 +0200)]
drm/irq: Remove negative CRTC index special-case
The drm_send_vblank_event() function treats negative CRTC indices as
meaning that a driver doesn't have proper VBLANK handling. This is the
only place where DRM needs negative CRTC indices, so in order to enable
subsequent cleanup, remove this special case and replace it by the more
obvious check for whether or not VBLANK support was initialized.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thierry Reding [Wed, 12 Aug 2015 14:32:11 +0000 (16:32 +0200)]
vga_switcheroo: Wrap overly long lines
Wrap overly long lines to make checkpatch happy. While at it, also add
blank lines after declarations to eliminate additional problems flagged
by checkpatch.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thierry Reding [Wed, 12 Aug 2015 14:32:10 +0000 (16:32 +0200)]
vga_switcheroo: Use pr_fmt()
Use pr_fmt() to define the "vga_switcheroo: " prefix that is prepended
to all output messages emitted by pr_*() functions. This allows making
existing strings much shorter and eliminates a bunch of warnings from
checkpatch about lines being overly long.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thierry Reding [Wed, 12 Aug 2015 14:32:07 +0000 (16:32 +0200)]
vgaarb: Fix a few checkpatch errors and warnings
Wrap overly long lines (offending lines were mostly comments, so trivial
to fix up) and a number of other coding style issues pointed out by the
checkpatch tool.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thierry Reding [Wed, 12 Aug 2015 14:32:05 +0000 (16:32 +0200)]
vgaarb: Stop complaining about absent devices
Some setups do not register a default VGA device, in which case the VGA
arbiter will still complain about the (non-existent) PCI device being a
non-VGA device.
Fix this by making the error message conditional on a default VGA device
having been set up. Note that the easy route of erroring out early isn't
going to work because otherwise priv->target won't be properly updated.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 10 Aug 2015 11:34:08 +0000 (13:34 +0200)]
drm/i915: Use CONFIG_DRM_FBDEV_EMULATION
Instead of our own duplicated one. This fixes a bug in the driver
unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
try to unregister the nonexistent fbdev drm_framebuffer.
drm/atomic: Only destroy connector states with connection mutex held
I tried to fix races of atomic commits against connector
hot-unplugging. The idea is to ensure lifetimes by holding the
connection_mutex long enough. That works for synchronous commits, but
not for async ones.
For async atomic commit we really need to fix up connector lifetimes
for real. But that's a much bigger task, so just add more duct-tape:
For cleaning up connector states we currently don't need the connector
itself. So NULL it out and remove the locking check. Of course that
check was to protect the entire sequence, but the modeset itself
should be save since currently DP MST hot-removal does a dpms-off. And
that should synchronize with any outstanding async atomic commit.
Or at least that's my hope, this is all a giant mess.
Daniel Vetter [Thu, 9 Jul 2015 21:32:46 +0000 (23:32 +0200)]
drm/qxl: Don't take dev->struct_mutex in bo_force_delete
It really doesn't protect anything which doesn't have other locks
already. It also doesn't seem to be wired up into the driver unload
code fwiw, but that's a different issue.
Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:32:42 +0000 (23:32 +0200)]
drm/rockchip: Don't grab dev->struct_mutex for in mmap offset ioctl
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Aside: I stumbled over the mmap handler which directly does a
dma_mmap_attrs. But totally fails to grab a reference on the
underlying object and hence looks like it happily just leaks the ptes
since there's no guarantee the mmap isn't still around when
gem_free_object is called. Which the kerneldoc of dma_mmap_attrs
explicitly forbids.
v2: Fixup compile fail 0-day spotted.
Cc: Mark Yao <mark.yao@rock-chips.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:32:41 +0000 (23:32 +0200)]
drm/cma-helper: Don't grab dev->struct_mutex for in mmap offset ioctl
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:32:40 +0000 (23:32 +0200)]
drm/cirrus: Don't grab dev->struct_mutex for in mmap offset ioctl
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:32:39 +0000 (23:32 +0200)]
drm/mga200g: Hold a proper reference for cursor_set
Looking up an obj, immediate dropping the acquired reference and then
continuing to use it isn't how this is supposed to work. Fix this by
holding a reference for the entire function.
While at it stop grabbing dev->struct_mutex, it doesn't protect
anything here.
Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:32:38 +0000 (23:32 +0200)]
drm/mga200g: Don't grab dev->struct_mutex for in mmap offset ioctl
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:32:37 +0000 (23:32 +0200)]
drm/bochs: Don't grab dev->struct_mutex for in mmap offset ioctl
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:32:36 +0000 (23:32 +0200)]
drm/ast: Don't grab dev->struct_mutex for in mmap offset ioctl
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Archit Taneja [Wed, 5 Aug 2015 06:58:57 +0000 (12:28 +0530)]
drm: Add top level Kconfig option for DRM fbdev emulation
Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
Most modesetting drivers enable provide fbdev emulation by default by
selecting KMS FB helpers. A few provide a separate Kconfig option for the
user to enable or disbale fbdev emulation.
Enabling fbdev emulation is finally a distro-level decision. Having a top
level Kconfig option for fbdev emulation helps by providing a uniform way
to enable/disable fbdev emulation for any modesetting driver. It also lets
us remove unnecessary driver specific Kconfig options that causes bloat.
With a top level Kconfig in place, we can stub out the fb helper functions
when not needed without breaking functionality. Having stub functions also
prevents drivers to require wrapping fb helper function calls with #ifdefs.
DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev
emulation by default and majority of distributions expect the fbdev
interface in the kernel.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/drm_fb_helper.c:390:13: warning: 'drm_fb_helper_force_kernel_mode' defined but not used [-Wunused-function]
static bool drm_fb_helper_force_kernel_mode(void)
^
Move drm_fb_helper_force_kernel_mode() inside the existing #ifdef to fix
this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As of commit 5ea1f752ae04be40 ("drm: add
drm_fb_helper_restore_fbdev_mode_unlocked()"),
drm_fb_helper_restore_fbdev_mode() is no longer public, and drivers
should call drm_fb_helper_restore_fbdev_mode_unlocked() from their
->lastclose callbacks instead.
Update the documentation to reflect this, and absorb the one liner
drm_fb_helper_restore_fbdev_mode() into its single caller.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
v3:
- Don't touch remove_conflicting_framebuffers
v2:
- remove unused goto label 'out'
Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
we started checking the locking in drm_for_each_connector but somehow
I totally missed drm_mode_config_reset. There's no problem there since
this function should only be called in single-threaded contexts
(driver load or resume), so just wrap the loop with the right lock.
Daniel Vetter [Tue, 28 Jul 2015 11:18:41 +0000 (13:18 +0200)]
drm/fb-helper: Stop using trylocks in force_restore
Since the panic handling is gone this is only used for force-restoring
the fbdev/fbcon from sysrq, and that's done with a work item. No need
any more to do trylocks, we can just do normal locking.
Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Tue, 28 Jul 2015 11:18:40 +0000 (13:18 +0200)]
drm/fbdev: Return -EBUSY when oopsing
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic handler isn't enough. We need to block all fbdev
callbacks when oopsing.
There was already one in the blank handler, but it failed silently.
That makes it impossible for drivers (like i915) who subclass these
functions to figure this out.
Instead consistently return -EBUSY so that everyone knows that we
really don't want to be bothered right now. This also allows us to
remove a pile of FIXMEs from the i915 fbdev code (since due to the
failure code they now won't attempt to grab dangerous locks any more).
Cc: Dave Airlie <airlied@gmail.com> Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
Cc: Rob Clark <robdclark@gmail.com> Cc: Stephane Viau <sviau@codeaurora.org> Cc: Hai Li <hali@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the newly created wrapper drm_fb_helper functions instead of calling
core fbdev functions directly. They also simplify the fb_info creation.
This is an effort to create a top level drm fbdev emulation option.
Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Rob Clark <robdclark@gmail.com> Cc: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb_helper: Create a wrapper for fb_set_suspend
Some drm drivers call fb_set_suspend. Create a drm_fb_helper function
that wraps around these calls.
This is part of an effort to prevent drm drivers from calling fbdev
functions directly, in order to make fbdev emulation a top level drm
option.
v3:
- Fixed kerneldoc errors
v2:
- Added kerneldocs
- Added a check for non-NULL fb_helper before proceeding. This will
make the helpers work when we have a module param for fbdev emulation
- Follow the drm way of aligning of arguments in func definitions
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb_helper: Create wrappers for blit, copyarea and fillrect funcs
drm drivers that emulate fbdev populate their fb_fillrect, fb_copyarea
and fb_imageblit fb_ops with the help of cfb_* or sys_* fbdev core
helper functions.
Create drm_fb_helper functions that wrap around these calls.
This is part of an effort to prevent drm drivers from calling fbdev
functions directly, in order to make fbdev emulation a top level drm
option.
v3:
- Fixed kerneldoc errors
v2:
- Added kerneldocs
- Follow the drm way of aligning of arguments in func definitions
- Remove unnecessary checks for non NULL fb_info
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb_helper: Create a wrapper for unlink_framebuffer
Some drm drivers call unlink_framebuffer. Create a drm_fb_helper function
that wraps around these calls.
This is part of an effort to prevent drm drivers from calling fbdev
functions directly, in order to make fbdev emulation a top level drm
option.
v2:
- Added kerneldocs
- Added a check for non-NULL fb_helper before proceeding. This will
make the helpers work when we have a module param for fbdev emulation
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb_helper: Add drm_fb_helper functions to manage fb_info creation
Every drm driver calls framebuffer_alloc, fb_alloc_cmap,
unregister_framebuffer, fb_dealloc_cmap and framebuffer_release in
order to emulate fbdev support.
Create drm_fb_helper functions that perform the above operations.
This is part of an effort to prevent drm drivers from calling fbdev
functions directly. It also removes repetitive code from drivers.
There are some drivers that call alloc_apertures after framebuffer_alloc
and some that don't. Make the helper always call alloc_apertures. This
would make certain drivers allocate memory for apertures but not use
them. Since it's a small amount of memory, it shouldn't be an issue.
v2:
- Added kerneldocs
- Added a check for non-NULL fb_helper before proceeding. This will
make the helpers work when we have a module param for fbdev emulation
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Vincent Abriou [Mon, 3 Aug 2015 12:22:16 +0000 (14:22 +0200)]
drm/sti: atomic crtc/plane update
Better fit STI hardware structure.
Planes are no more responsible of updating mixer information such
as z-order and status. It is now up to the CRTC atomic flush to
do it. Plane actions (enable or disable) are performed atomically.
Disabling of a plane is synchronize with the vsync event.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Vincent Abriou [Fri, 31 Jul 2015 09:32:13 +0000 (11:32 +0200)]
drm/sti: code clean up
Purpose is to simplify the STI driver:
- remove layer structure
- consider video subdev as part of the compositor (like mixer subdev)
- remove useless STI_VID0 and STI_VID1 enum
Signed-off-by: Vincent Abriou <vincent.abriou@st.com> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Vincent Abriou [Fri, 31 Jul 2015 09:31:38 +0000 (11:31 +0200)]
drm/sti: fix dynamic z-ordering
Apply the plane depth when the plane is updated.
If the depth is different from the previous plane update,
the register controlling the plane depth is cleaned and updated
with the new depth.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Fix misunderstanding in how use component framework.
drm_platform_init() is now call only when all the
sub-components are register themselves instead of the
previous broken two stages mechanism.
Update bindings documentation.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
A logical AND operation was used during mask and shift, instead of a
bitwise AND operation. This patch fixes this bug by changing the
operation to bitwise AND.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Thu, 30 Jul 2015 02:45:11 +0000 (12:45 +1000)]
Merge tag 'topic/drm-misc-2015-07-28' of git://anongit.freedesktop.org/drm-intel into drm-next
More drm-misc, mostly fine-tuning of atomic helpers. They're mostly
driver-wide interface changes of the helpers and I need them for i915
work, so I plan to pull this tag into drm-intel-next too.
* tag 'topic/drm-misc-2015-07-28' of git://anongit.freedesktop.org/drm-intel:
drm/atomic: Update legacy DPMS state during modesets, v3.
drm: Make the connector dpms callback return a value, v2.
drm/atomic: pass old crtc state to atomic_begin/flush.
drm/atomic: add connectors_changed to separate it from mode_changed, v2
drm: Fix DP_TEST_COUNT_MASK
drm/atomic: Update legacy DPMS state during modesets, v3.
This is required for DPMS to work correctly, during a modeset
the DPMS property should be turned off, unless the state is
crtc is made active in which case it should be set to DPMS on.
Changes since v1:
- Set DPMS to off when a connector is removed from a crtc too.
- Update the legacy dpms property too.
- Add an exception for the legacy dpms paths, it updates its own state.
Changes since v2:
- Do not preserve dpms property.
Cc: dri-devel@lists.freedesktop.org Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm: Make the connector dpms callback return a value, v2.
This is required to properly handle failing dpms calls.
When making a wait in i915 interruptible, I've noticed
that the dpms sequence could fail with -ERESTARTSYS because
it was waiting interruptibly for flips. So from now on
allow drivers to fail in their connector dpms callback.
Encoder and crtc dpms callbacks are unaffected.
Changes since v1:
- Update kerneldoc for the drm helper functions.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Resolve conflicts due to different merge order.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/atomic: pass old crtc state to atomic_begin/flush.
In intel it's useful to keep track of some state changes with old
crtc state vs new state, for example to disable initial planes or
when a modeset's prevented during fastboot.
Cc: dri-devel@lists.freedesktop.org Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
[danvet: squash in fixup for exynos provided by Maarten.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/atomic: add connectors_changed to separate it from mode_changed, v2
This can be a separate case from mode_changed, when connectors stay the
same but only the mode is different. Drivers may choose to implement specific
optimizations to prevent a full modeset for this case.
Changes since v1:
- Update kerneldocs slightly.
Cc: dri-devel@lists.freedesktop.org Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By Vesa's DP 1.2 Spec this counter has 4 bits [3:0].
This mask is wrong since when the counter was introduced by myself
on commit ad9dc91b6e21266bfc6f466db4b95e10211f31ee
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date: Tue Sep 16 19:18:12 2014 -0400
Dave Airlie [Fri, 24 Jul 2015 04:30:29 +0000 (14:30 +1000)]
Merge tag 'topic/connector-locking-2015-07-23' of git://anongit.freedesktop.org/drm-intel into drm-next
connector hotplug locking cleanup and fixes to make it save against
atomic. Note that because of depencies this is based on top of the
drm-intel-next pull, so that one needs to go in before this one.
I've also thrown in the mode_group removal on top since it's defunct,
never worked really, no one seems to care and the code can be resurrected
easily.
* tag 'topic/connector-locking-2015-07-23' of git://anongit.freedesktop.org/drm-intel:
drm: gc now dead mode_group code
drm: Stop filtering according to mode_group in getresources
drm: Roll out drm_for_each_{plane,crtc,encoder}
drm/cma-helper: Fix locking in drm_fb_cma_debugfs_show
drm: Roll out drm_for_each_connector more
drm: Amend connector list locking rules
drm/radeon: Take all modeset locks for DP MST hotplug
drm/i915: Take all modeset locks for DP MST hotplug
drm: Check locking in drm_for_each_fb
drm/i915: Use drm_for_each_fb in i915_debugfs.c
drm: Check locking in drm_for_each_connector
drm/fbdev-helper: Grab mode_config.mutex in drm_fb_helper_single_add_all_connectors
drm/probe-helper: Grab mode_config.mutex in poll_init/enable
drm: Add modeset object iterators
drm: Simplify drm_for_each_legacy_plane arguments
Dave Airlie [Fri, 24 Jul 2015 04:30:04 +0000 (14:30 +1000)]
Merge tag 'topic/crc-pmic-2015-07-23' of git://anongit.freedesktop.org/drm-intel into drm-next
crystalcove pmic support from Shobhit. Patch series has all acks/r-bs from
other mainainers so ok to pull into drm-next. But I'm cc'ing all other
maintainers as fyi and in case they want to pull it into their trees too
to avoid conflicts.
* tag 'topic/crc-pmic-2015-07-23' of git://anongit.freedesktop.org/drm-intel:
mfd: Add GPIOLIB dependency if INTEL_SOC_PMIC is to be enabled
drm/i915: Backlight control using CRC PMIC based PWM driver
drm/i915: Use the CRC gpio for panel enable/disable
pwm: crc: Add Crystalcove (CRC) PWM driver
mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM
mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC
mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO signal
gpiolib: Add support for removing registered consumer lookup table
Dave Airlie [Fri, 24 Jul 2015 04:29:06 +0000 (14:29 +1000)]
Merge tag 'drm-intel-next-2015-07-17' of git://anongit.freedesktop.org/drm-intel into drm-next
- prelim hw support dropped for skl after Damien fixed an ABI issue around
planes
- legacy modesetting is done using atomic infrastructure now (Maarten)!
- more gen9 workarounds (Arun&Nick)
- MOCS programming (cache control for better performance) for skl/bxt
- vlv/chv dpll improvements (Ville)
- PSR fixes from Rodrigo
- fbc improvements from Paulo
- plumb requests into execlist submit functions (Mika)
- opregion code cleanup from Jani
- resource streamer support from Abdiel for mesa
- final fixes for 12bpc hdmi + enabling support from Ville
drm-intel-next-2015-07-03:
- dsi improvements (Gaurav)
- bxt ddi dpll hw state readout (Imre)
- chv dvfs support and overall wm improvements for both vlv and chv (Ville)
- ppgtt polish from Mika and Michel
- cdclk support for bxt (Bob Pauwe)
- make frontbuffer tracking more precise
- OLR removal (John Harrison)
- per-ctx WA batch buffer support (Arun Siluvery)
- remvoe KMS Kconfig option (Chris)
- more hpd handling refactoring from Jani
- use atomic states throughout modeset code and integrate with atomic plane
update (Maarten)
drm-intel-next-2015-06-19:
- refactoring hpd irq handlers (Jani)
- polish skl dpll code a bit (Damien)
- dynamic cdclk adjustement (Ville & Mika)
- fix up 12bpc hdmi and enable it for real again (Ville)
- extend hsw cmd parser to be useful for atomic configuration (Franscico Jerez)
- even more atomic conversion and rolling state handling out across modeset code
from Maarten & Ander
- fix DRRS idleness detection (Ramalingam)
- clean up dsp address alignment handling (Ville)
- some fbc cleanup patches from Paulo
- prevent hard-hangs when trying to reset the gpu on skl (Mika)
* tag 'drm-intel-next-2015-07-17' of git://anongit.freedesktop.org/drm-intel: (386 commits)
drm/i915: Update DRIVER_DATE to 20150717
drm/i915/skl: Drop the preliminary_hw_support flag
drm/i915/skl: Don't expose the top most plane on gen9 display
drm/i915: Fix divide by zero on watermark update
drm/i915: Invert fastboot check
drm/i915: Clarify logic for initial modeset
drm/i915: Unconditionally check gmch pfit state
drm/i915: always disable irqs in intel_pipe_update_start
drm/i915: Remove use of runtime pm in atomic commit functions
drm/i915: Call plane update functions directly from intel_atomic_commit.
drm/i915: Use full atomic modeset.
drm/i915/gen9: Add WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
drm/i915/gen9: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround
drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaround
drm/i915: Enable WA batch buffers for Gen9
drm/i915/gen9: Implement WaDisableKillLogic for gen 9
drm/i915: Use expcitly fixed type in compat32 structs
drm/i915: Fix noatomic crtc disabling, v2.
drm/i915: fill in more mode members
drm/i915: Added BXT check in HAS_CORE_RING_FREQ macro
...
Dave Airlie [Fri, 24 Jul 2015 04:28:16 +0000 (14:28 +1000)]
Merge tag 'topic/drm-misc-2015-07-23' of git://anongit.freedesktop.org/drm-intel into drm-next
Update drm-misc pull request since the first one didn't go in yet. Few
atomic helper patches, rejecting some old dri1 crap for modern drivers and
a few trivial things on top.
* tag 'topic/drm-misc-2015-07-23' of git://anongit.freedesktop.org/drm-intel:
drm/mgag200: remove unneeded variable
drm/mgag200: remove unused variables
drm/atomic: Only update crtc->x/y if it's part of the state, v2.
drm/fb: drop panic handling
drm: Fix warning with make xmldocs caused by drm_irq.c
drm/gem: rip out drm vma accounting for gem mmaps
drm/fourcc: Add formats R8, RG88, GR88
drm/atomic: Cleanup on error properly in the atomic ioctl.
drm: Update plane->fb also for page_flip
drm: remove redundant code form drm_ioc32.c
drm: reset empty state in transitional helpers
drm/crtc-helper: Fixup error handling in drm_helper_crtc_mode_set
drm/atomic: Update old_fb after setting a property.
drm: Remove useless blank line
drm: Reject DRI1 hw lock ioctl functions for kms drivers
drm: Convert drm_legacy_ctxbitmap_init to void return type
drm: Turn off Legacy Context Functions
Dave Airlie [Fri, 24 Jul 2015 04:26:53 +0000 (14:26 +1000)]
Merge tag 'drm-amdkfd-next-2015-07-20' of git://people.freedesktop.org/~gabbayo/linux into drm-next
- Add Carrizo support for amdkfd, using the new amdgpu driver as the relevant
kgd. The support includes interfaces with amdgpu both for gfx7 (Kaveri) and
gfx8 (Carrizo). However, gfx7 interface is used for debugging purposes only,
so amdkfd defaults to using radeon when Kaveri is installed.
I would like to note that no new IOCTLs are being introduced, and there is no
change in the current IOCTLs, as they are suited both for gfx7 and gfx8.
* tag 'drm-amdkfd-next-2015-07-20' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: Set correct doorbell packet type for Carrizo
drm/amdkfd: Use generic defines in new amd headers
drm/amdkfd: Implement create_map_queues() for Carrizo
drm/amdkfd: fix runlist length calculation
drm/amdkfd: Add support for VI in DQM
drm/amdkfd: add support for VI in MQD manager
drm/amdkfd: add CP HWS packet headers for VI
drm/amdkfd: add supported CZ devices PCI IDs to amdkfd
drm/amdkfd: Add dependency of DRM_AMDGPU to Kconfig
drm/amdgpu: Add amdgpu <--> amdkfd gfx8 interface
drm/amdgpu: add amdgpu <--> amdkfd gfx7 interface
drm/amdgpu: Add H/W agnostic amdgpu <--> amdkfd interface
drm/radeon: Modify kgd_engine_type enum to match CZ
Daniel Vetter [Thu, 9 Jul 2015 21:44:37 +0000 (23:44 +0200)]
drm: gc now dead mode_group code
Two nice things here:
- drm_dev_register will truly register everything in the right order
if the driver doesn't have a ->load callback. Before this we had to
init the primary mode_group after the device nodes where already
registered.
- Less things to keep track of when reworking the connector locking,
yay!
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:44:36 +0000 (23:44 +0200)]
drm: Stop filtering according to mode_group in getresources
It's been dead code since forever since mode groups haven't ever been
implemented. On top of that it's also been non-functional since we
only ever filtered the getresources ioctl and not any of the others
nor the mode object lookup code.
Given overwhelming evidence it looks like this isn't a feature we
need, hence remove it.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:32:34 +0000 (23:32 +0200)]
drm/cma-helper: Fix locking in drm_fb_cma_debugfs_show
This function takes two locks, both of them the wrong ones. This
wasn't an oversight from my fb locking rework since both patches
landed in parallel. We really only need fb_lock when walking that
list, since everything we can reach from that is refcounted properly
already.
v2: Drop unused dev spotted by 0day.
Cc: Rob Clark <robdclark@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:44:34 +0000 (23:44 +0200)]
drm: Roll out drm_for_each_connector more
Now that we also grab the connection_mutex and so fixed the race with
atomic modeset we can use the iterator there too.
The other special case is drm_connector_unplug_all which would have a
locking inversion with the sysfs store/show functions if we'd grab the
mode_config.mutex around the unplug. We could just grab
connection_mutex instead, but that's a bit too much a dirty trick for
my taste. Also it's only used by udl, which doesn't do any other kind
of connector hotplugging, so should be race-free. Hence just stick
with a comment for now.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:44:33 +0000 (23:44 +0200)]
drm: Amend connector list locking rules
Now that dp mst hotplug takes all locks we can amend the locking rules
for the iterators. This is needed before we can roll these out in the
atomic code to avoid getting burried in WARNINGs.
v2: Rebase onto the extracted list locking assert and add a comment to
explain the rules.
v3: Fixup German->English translation fail in the comment.
Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:44:32 +0000 (23:44 +0200)]
drm/radeon: Take all modeset locks for DP MST hotplug
Similar with the i915 take all modeset locks for mst hotplug. This is
needed to make sure radeon holds both mode_config.mutex and
mode_config.connection_mutex when updating the connector_list, which
is the new (interim) locking regime we want for that.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:44:31 +0000 (23:44 +0200)]
drm/i915: Take all modeset locks for DP MST hotplug
While auditing various users of the connector/encoder lists I realized
that the atomic code is a very prolific user of them. And it only ever
grabs the mode_config->connection_mutex, but not the
mode_config->mutex like all the other code walking encoder/connector
lists.
The problem is that we can't grab the mode_config.mutex late in atomic
code since that would lead to locking inversions. And we don't want to
grab it unconditionally like the legacy set_config modeset path since
that would render all the fine-grained locking moot.
Instead just grab more locks in the dp mst hotplug code. Note that
drm_connector_init (which is the one adding the connector to these
lists) already uses drm_modeset_lock_all.
The other reason for grabbing all locks is that the dpms off in the
unplug function amounts to a modeset, so better to take all required
locks for that.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:44:30 +0000 (23:44 +0200)]
drm: Check locking in drm_for_each_fb
Ever since framebuffers are reference counted we have a special lock
for the global fb list. Make sure users of that list do hold that
lock when using the new iterators.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:44:28 +0000 (23:44 +0200)]
drm: Check locking in drm_for_each_connector
Because of DP MST connectors can now be hotplugged and we must hold
the right lock when walking the connector lists. Enforce this by
checking the locking in our shiny new list walking macros.
v2: Extract the locking check into a small static inline helper to
help readability. This will be more important when we make the
read list access rules more complicated in later patches. Inspired by
comments from Chris. Unfortunately, due to header loops around the
definition of struct drm_device the function interface is a bit funny.
v3: Encoders aren't hotadded/removed. For each dp mst encoder we
statically create one fake encoder per pipe so that we can support as
many mst sinks as the hw can (Dave).
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:44:27 +0000 (23:44 +0200)]
drm/fbdev-helper: Grab mode_config.mutex in drm_fb_helper_single_add_all_connectors
This is now truly only duct-tape to keep locking checks happy since
calling this function when hpd or polling are already enabled is a
bug. The fbdev helper can't cope with hotplug changes yet at this
point, only after that.
Otoh a bit more robustness in this function can't hurt, and with this
fbdev can actually cope with hotplug changes. And it's also more
consistent with the connector hotadd/remove dp mst needs to do.
Therefore document this as new official behavior.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 9 Jul 2015 21:44:26 +0000 (23:44 +0200)]
drm/probe-helper: Grab mode_config.mutex in poll_init/enable
So on first looks this seems superflous since drivers should ensure
correct ordering to not make this a problem. Otoh ordering constraints
between hdp, fbdev load and enabling polling are already tricky on
some hardware and it helps to be more robust.
But the real goal is to just shut up a locking WARN_ON I'd like to
add, which means init code gets some additional locks just for
uniformity.
v2: Also grab the lock for the public poll_enable, not just poll_init
which is used for resume, with the same justification.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
projects / linux-beck.git / log