Dave Airlie [Mon, 1 Dec 2014 22:59:34 +0000 (08:59 +1000)]
Merge tag 'topic/core-stuff-2014-11-28' of git://anongit.freedesktop.org/drm-intel into drm-next
So here's a pile of atomic fixes and improvements from various people.
There's still more patches in-flight, so I think I'll keep collecting them
in a separate branch.
* tag 'topic/core-stuff-2014-11-28' of git://anongit.freedesktop.org/drm-intel:
drm/atomic: clear plane's CRTC and FB when shutting down
drm: Handle atomic state properly in kms getfoo ioctl
drm: use mode_object_find helpers
drm: fix indentation
drm/msm: switch to atomic-helpers iterator macros
drm/atomic: add plane iterator macros
drm/atomic: track bitmask of planes attached to crtc
drm: Free atomic state during cleanup
drm: Make drm_atomic.h standalone includible
drm: Make drm_atomic_helper.h standalone includible
drm/plane: Add missing kerneldoc
drm/plane: Pass old state to ->atomic_update()
drm/atomic_helper: Cope with plane->crtc == NULL in disable helper
drm/atomic: Drop per-plane locking TODO
drm/atomic-helper: Skip vblank waits for unchanged fbs
drm: Document that drm_dev_alloc doesn't need a parent
Laurent Pinchart [Thu, 27 Nov 2014 15:19:13 +0000 (17:19 +0200)]
ARM: shmobile: marzen: Remove DU platform device
Platform data support has been removed from the DU driver, drop DU
support from the legacy Marzen board file. The multiplatform DT-based
Marzen support should be used instead.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Dave Airlie <airlied@redhat.com>
Laurent Pinchart [Thu, 27 Nov 2014 15:19:12 +0000 (17:19 +0200)]
ARM: shmobile: lager: Remove DU platform device
Platform data support has been removed from the DU driver, drop DU
support from the legacy Lager board file. The multiplatform DT-based
Lager support should be used instead.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Dave Airlie <airlied@redhat.com>
Rob Clark [Wed, 26 Nov 2014 23:58:04 +0000 (18:58 -0500)]
drm/atomic: clear plane's CRTC and FB when shutting down
Otherwise we'd still end up w/ the plane attached to the CRTC, and
seemingly active, but without an FB. Which ends up going *boom*
in the drivers.
Slightly modified version of Daniel's irc suggestion.
Note that the big problem isn't drivers going *boom* here (since we
already have the situation of planes being left enabled when the crtc
goes down). The real issue is that the core assumes the primary plane
always goes down when calling ->set_config with a NULL mode. Ignoring
that assumption leads to the legacy state pointers plane->fb/crtc
getting out of sync with atomic, and that then leads to the subsequent
*boom* all over the place.
CC: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Rob Clark <robdclark@gmail.com>
[danvet: Drop my opinion of what's going sidewides here into the
commit message as a note.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 25 Nov 2014 22:50:05 +0000 (23:50 +0100)]
drm: Handle atomic state properly in kms getfoo ioctl
So the problem with async commit (especially async modeset commit) is
that the legacy pointers only get updated after the point of no
return, in the async part of the modeset sequence. At least as
implemented by the current helper functions. This is done in the
set_routing_links function in drm_atomic_helper.c.
Which also means that access isn't protected by locks but only
coordinated by synchronizing with async workers. No problem thus far,
until we lock at the getconnector/encoder ioctls.
So fix this up by adding special cases for atomic drivers: For those
we need to look at state objects. Unfortunately digging out the
correct encoder->crtc link is a bit of work, so wrap this up in a
helper function.
Moving the assignments of connector->encoder and encoder->crtc earlier
isn't a good idea because the point of the atomic helpers is that we
stage the state updates. That way the disable functions can still
inspect the links and rely upon them.
v2: Extract full encoder->crtc lookup into helper (Rob).
v3: Extract drm_connector_get_encoder too since - we need to always
return state->best_encoder when there is a state otherwise we might
return stale data if there's a pending async disable (and chase
unlocked pointers, too). Same issue with encoder_get_crtc but there
it's a bit more tricky to handle.
Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Lightly-Tested-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Rob Clark [Wed, 26 Nov 2014 01:29:46 +0000 (20:29 -0500)]
drm/atomic: add plane iterator macros
Add helper macros to iterate the current, or incoming set of planes
attached to a crtc. These helpers are only available for drivers
converted to use atomic-helpers.
Signed-off-by: Rob Clark <robdclark@gmail.com>
[danvet: Squash in fixup from Rob to move the planemask iterator to
drm_crtc.h and document it. That one is needed by the atomic ioctl so
can't be in a helper library.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rob Clark [Fri, 21 Nov 2014 20:28:31 +0000 (15:28 -0500)]
drm/atomic: track bitmask of planes attached to crtc
Chasing plane->state->crtc of planes that are *not* part of the same
atomic update is racy, making it incredibly awkward (or impossible) to
do something simple like iterate over all planes and figure out which
ones are attached to a crtc.
Solve this by adding a bitmask of currently attached planes in the
crtc-state.
Note that the transitional helpers do not maintain the plane_mask. But
they only support the legacy ioctls, which have sufficient brute-force
locking around plane updates that they can continue to loop over all
planes to see what is attached to a crtc the old way.
Signed-off-by: Rob Clark <robdclark@gmail.com>
[danvet:
- Drop comments about locking in set_crtc_for_plane since they're a
bit misleading - we already should hold lock for the current crtc.
- Also WARN_ON if get_state on the old crtc fails since that should
have been done already.
- Squash in fixup to check get_plane_state return value, reported by
Dan Carpenter and acked by Rob Clark.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dave Airlie [Wed, 26 Nov 2014 22:36:19 +0000 (08:36 +1000)]
Merge branch 'drm/du/adv7511' of git://linuxtv.org/pinchartl/fbdev into drm-next
The branch is based on a merge of drm-next and Simon's tags/renesas-dt-du-for-
v3.19 available at
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git, the latter
having been pulled in the ARM SoC tree for v3.19.
Compared to v1, I've rebased my branch on a later drm-next, added Julia's
error return code fix, and documented the "drm: Decouple EDID parsing from I2C
adapter" patch properly.
v1:
Here's a pull request that adds HDMI support to the R-Car DU driver, including
a new slave encoder driver for the adv7511.
* 'drm/du/adv7511' of git://linuxtv.org/pinchartl/fbdev:
drm: Add adv7511 encoder driver
video: Add ADV751[13] DT bindings documentation
drm: Decouple EDID parsing from I2C adapter
drm: rcar-du: Add HDMI encoder and connector support
drm: rcar-du: Replace drm_encoder with drm_slave_encoder
drm: rcar-du: Replace direct DRM encoder access with cast macro
drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init()
drm: rcar-du: Remove platform data support
drm: rcar-du: fix error return code
ARM: shmobile: koelsch: Enable DU device in DT
ARM: shmobile: koelsch-reference: Remove DU platform device
ARM: shmobile: lager: Enable DU device in DT
ARM: shmobile: lager-reference: Remove DU platform device
ARM: shmobile: marzen: Enable DU device in DT
ARM: shmobile: dts: Add common file for AA104XD12 panel
ARM: shmobile: r8a7791: Add DU node to device tree
ARM: shmobile: r8a7790: Add DU node to device tree
ARM: shmobile: r8a7779: Add DU node to device tree
ARM: shmobile: Remove FSF address from copyright headers
Dave Airlie [Wed, 26 Nov 2014 22:28:22 +0000 (08:28 +1000)]
Merge branch 'amdkfd-next-3.19' of git://people.freedesktop.org/~gabbayo/linux into drm-next
- Fixes for sparse warnings
- Memory leak fixes
- Fix for deadlock between amdkfd and iommu
* 'amdkfd-next-3.19' of git://people.freedesktop.org/~gabbayo/linux:
amdkfd: delete some dead code
amdkfd: Fix memory leak of mqds on dqm fini
amdkfd: fix an error handling bug in pqm_create_queue()
amdkfd: fix some error handling in ioctl
amdkfd: Remove DRM_AMDGPU dependency from Kconfig
amdkfd: explicitely include io.h in kfd_doorbell.c
amdkfd: Clear ctx cb before suspend
amdkfd: Instead of using get function, use container_of
amdkfd: use schedule() in sync_with_hw
amdkfd: Fix memory leak on process deregistration
amdkfd: add __iomem attribute to doorbell_ptr
amdkfd: fence_wait_timeout() can be static
amdkfd: is_occupied() can be static
amdkfd: Fix sparse warnings in kfd_flat_memory.c
amdkfd: pqm_get_kernel_queue() can be static
amdkfd: test_kq() can be static
amdkfd: Fix sparse warnings in kfd_topology.c
amdkfd: Fix sparse warnings in kfd_chardev.c
This patch adds a driver for the Analog Devices adv7511. The adv7511 is
a standalone HDMI transmitter chip. It features a HDMI output interface
on one end and video and audio input interfaces on the other.
The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters
compatible with HDMI 1.4 and DVI 1.0. They're described in DT using the
OF graph bindings and a list of custom properties pertaining to the
input video bus configuration.
The drm_get_edid() function performs direct I2C accesses to read EDID
blocks, assuming that the monitor DDC interface is directly connected to
the I2C bus. It can't thus be used with HDMI encoders that control the
DDC bus and expose EDID blocks through a different interface.
Refactor drm_do_get_edid() to take a block read callback function
instead of an I2C adapter, and export it for direct use by drivers.
As in the general case the DDC bus is accessible by the kernel at the
I2C level, drivers must make all reasonable efforts to expose it as an
I2C adapter and use drm_get_edid() instead of abusing this function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Laurent Pinchart [Sun, 30 Mar 2014 23:52:01 +0000 (01:52 +0200)]
drm: rcar-du: Replace drm_encoder with drm_slave_encoder
DRM slave encoders require their associated struct drm_encoder instance
to be embedded in a struct drm_slave_encoder. This makes processing
encoders regardless of their types needlessly and painfully complex in
drivers that use a mix of slave encoders and custom encoders. Such a
driver will need to either create drm_slave_encoder instances that fake
their embedded encoder instance, or to turn all drm_encoder instances
into drm_slave_encoder instances.
Between the two evils, one must choose the lesser. Use drm_slave_encoder
everywhere.
Laurent Pinchart [Sun, 30 Mar 2014 23:50:16 +0000 (01:50 +0200)]
drm: rcar-du: Replace direct DRM encoder access with cast macro
Add a new macro to downcast an rcar_du_encoder pointer to a drm_encoder
pointer and use it. This prepares for the replacement of the
rcar_drm_encoder encoder field with a drm_slave_encoder.
Philipp Zabel [Mon, 24 Nov 2014 15:33:34 +0000 (16:33 +0100)]
drm: imx: Move imx-drm driver out of staging
The imx-drm driver was put into staging mostly for the following reasons,
all of which have been addressed or superseded:
- convert the irq driver to use linear irq domains
- work out the device tree bindings, this lead to the common of_graph
bindings being used
- factor out common helper functions, this mostly resulted in the
component framework and drm of_graph helpers.
Before adding new fixes, and certainly before adding new features,
move it into its proper place below drivers/gpu/drm.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Tue, 25 Nov 2014 23:19:36 +0000 (09:19 +1000)]
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
Add Exynos4415 SoC support, some fixups and cleanups.
Summary:
- Resolve kernel lockup issue incurred by probe request in probe context.
. For this, it moves all register codes of sub drivers into init function
and adds component binding support for vidi driver.
- Add Exynos4415 SoC support.
- Make each manager and display object to be embedded
in each driver context.
- Fix and clean up FIMD and MIPI-DSI drivers.
- Clean up unnecesary or wrong descriptions.
- And trivial cleanups.
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (58 commits)
drm/exynos: avoid leak if exynos_dpi_probe() fails
drm/exynos: Fix exynos_dpi_remove() parameter
drm/exynos: vidi: add component support
drm/exynos: fix exynos_drm_component_del
drm/exynos/ipp: fix error return code
drm/exynos: clean up machine compatible string check
drm/exynos: move Exynos platform drivers registration to init
Revert "drm/exynos: fix null pointer dereference issue"
drm/exynos/dpi: stop using display->ctx pointer
drm/exynos/dpi: embed display into private context
drm/exynos/dp: stop using display->ctx pointer
drm/exynos/dp: embed display into private context
drm/exynos/vidi: stop using display->ctx pointer
drm/exynos/vidi: embed display into private context
drm/exynos/hdmi: stop using display->ctx pointer
drm/exynos/hdmi: embed display into private context
drm/exynos/fimd: stop using manager->ctx pointer
drm/exynos/fimd: embed manager into private context
drm/exynos/vidi: stop using manager->ctx pointer
drm/exynos/vidi: embed manager into private context
...
Thierry Reding [Tue, 25 Nov 2014 11:09:49 +0000 (12:09 +0100)]
drm: Free atomic state during cleanup
The current state of CRTCs, planes and connectors currently leaks during
DRM driver ->unload() unless drivers explicitly clean it up. Since there
is nothing driver-specific about it, that cleanup can be done within the
DRM core.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thierry Reding [Tue, 25 Nov 2014 11:09:48 +0000 (12:09 +0100)]
drm: Make drm_atomic.h standalone includible
This header file makes use of a bunch of structures declared in the
drm_crtc.h header file. Include that to make sure the drm_atomic.h
header can be included standalone.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thierry Reding [Tue, 25 Nov 2014 11:09:47 +0000 (12:09 +0100)]
drm: Make drm_atomic_helper.h standalone includible
This header uses a bunch of declarations from the drm/drm_crtc.h header,
so make sure to include that as well so that drm_atomic_helper.h can be
included standalone.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thierry Reding [Tue, 25 Nov 2014 11:09:44 +0000 (12:09 +0100)]
drm/plane: Pass old state to ->atomic_update()
In most situations it will be useful to have the old state passed to the
->atomic_update() callback. For example if a plane is being disabled the
new state's .crtc field will be NULL, but some drivers may rely on this
field to program the CRTCs registers.
v2: rename variable to old_plane_state and remove redundant comment as
suggested by Daniel Vetter, remove an Exynos hunk that doesn't apply to
drm-next and add a hunk for pending MSM mdp5 changes
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/atomic_helper: Cope with plane->crtc == NULL in disable helper
The drm core can call the plane disable hook multiple times, which
means it can get called when plane->crtc is already NULL. That in turn
means we can't get at the implicit acquire ctx we use in the atomic
helpers for legacy entries points.
We could try to pass drm_modeset_legacy_acquire_ctx a drm_device
pointer so that it can cope with a NULL crtc. But that still doesn't
work since the cursor ioctls (remapped with the universal cursor plane
support code) only grabs the crtc locks. So the global acquire context
isn't set eitehr.
The real solution here would be to bite the bullet and wire up
explicit acquire context parameters to all relevant functions. We need
to do that anyway (to be able to get rid of some small allocations
which we can't cope with failing). But that's a lot of work and better
done once atomic has settled a bit.
So meanwhile just catch this case in the helper and bail out.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net> Reviewed-by: Rob Clark <robdclark@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Completely rewrite commit message and comment but keep
Jasper's logic and author credits since his patch is the only
short-term solution that works.] Tested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 24 Nov 2014 19:42:42 +0000 (20:42 +0100)]
drm/atomic-helper: Skip vblank waits for unchanged fbs
Especially with legacy cursor ioctls existing userspace assumes that
you can pile up lots of updates in one go. The super-proper way to
support this would be a special commit mode which overwrites the last
update. But getting there will be quite a bit of work.
Meanwhile do what pretty much all the drivers have done for the plane
update functions: Simply skip the vblank wait for the buffer cleanup
if the buffer is the same. Since the universal cursor plane code will
not recreate framebuffers needlessly this allows us to not slow down
legacy pageflip events while someone moves the cursor around.
v2: Drop the async plane update hunk from a previous attempt at this
issue.
v3: Fix up kerneldoc.
v4: Don't oops so badly. Reported by Jasper.
Cc: Rob Clark <robdclark@gmail.com> Cc: "Jasper St. Pierre" <jstpierre@mecheye.net> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net> Tested-by: Jasper St. Pierre <jstpierre@mecheye.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Dave Airlie [Tue, 25 Nov 2014 12:10:53 +0000 (22:10 +1000)]
Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next
Now that we have the bits needed for mdp5 atomic, here is the followup
pull request I mentioned. Main highlights are:
1) mdp5 multiple crtc and public plane support (no more hard-coded mixer setup!)
2) mdp5 atomic conversion
3) couple atomic helper fixes for issues found during mdp5 atomic
debug (reviewed by danvet.. but he didn't plane to send an
atomic-fixes pull request so I agreed to tack them on to mine)
* 'msm-next' of git://people.freedesktop.org/~robclark/linux:
drm/atomic: shutdown *current* encoder
drm/atomic: check mode_changed *after* atomic_check
drm/msm/mdp4: fix mixer setup for multi-crtc + planes
drm/msm/mdp5: dpms(OFF) cleanups
drm/msm/mdp5: atomic
drm/msm: atomic fixes
drm/msm/mdp5: remove global mdp5_ctl_mgr
drm/msm/mdp5: don't use void * for opaque types
drm/msm: add multiple CRTC and overlay support
drm/msm/mdp5: set rate before enabling clk
drm/msm/mdp5: introduce mdp5_cfg module
drm/msm/mdp5: make SMP module dynamically configurable
drm/msm/hdmi: remove useless kref
drm/msm/mdp5: get the core clock rate from MDP5 config
drm/msm/mdp5: use irqdomains
Gustavo Padovan [Mon, 24 Nov 2014 17:19:49 +0000 (15:19 -0200)]
drm/exynos: Fix exynos_dpi_remove() parameter
exynos_dpi_remove() should receive a exynos_drm_display but when
DRM_EXYNOS_DPI was disabled it was receiving a struct device resulting in
ia compiler warning.
Inki Dae [Mon, 24 Nov 2014 05:55:41 +0000 (14:55 +0900)]
drm/exynos: vidi: add component support
This patch adds component support for vidi driver.
vidi driver is a kms driver so it doesn't need to be registered
to exynos_drm_subdrv_list. For this, it changes for the component
framework to be used for vidi driver.
This patch fixes below error also,
# echo 1 > /sys/devices/platform/exynos-drm-vidi/connection
[ 55.618529] ------------[ cut here ]------------
[ 55.621960] WARNING: CPU: 0 PID: 1397 at drivers/gpu/drm/drm_irq.c:1203 exynos_drm_crtc_dpms+0x88/0x17c()
[ 55.631268] Modules linked in:
[ 55.634278] CPU: 0 PID: 1397 Comm: sh Not tainted 3.18.0-rc2-146253-g31449d7 #1154
[ 55.641885] [<c0014400>] (unwind_backtrace) from [<c0011570>] (show_stack+0x10/0x14)
[ 55.649597] [<c0011570>] (show_stack) from [<c04764f4>] (dump_stack+0x84/0xc4)
[ 55.656802] [<c04764f4>] (dump_stack) from [<c00218b8>] (warn_slowpath_common+0x6c/0x88)
[ 55.664866] [<c00218b8>] (warn_slowpath_common) from [<c0021970>] (warn_slowpath_null+0x1c/0x24)
[ 55.673632] [<c0021970>] (warn_slowpath_null) from [<c027a780>] (exynos_drm_crtc_dpms+0x88/0x17c)
[ 55.682482] [<c027a780>] (exynos_drm_crtc_dpms) from [<c027a910>] (exynos_drm_crtc_commit+0x14/0x44)
[ 55.691622] [<c027a910>] (exynos_drm_crtc_commit) from [<c025521c>] (drm_crtc_helper_set_mode+0x3d0/0x51c)
[ 55.701233] [<c025521c>] (drm_crtc_helper_set_mode) from [<c0255d68>] (drm_crtc_helper_set_config+0x87c/0x9dc)
[ 55.711230] [<c0255d68>] (drm_crtc_helper_set_config) from [<c026afa8>] (drm_mode_set_config_internal+0x58/0xd4)
[ 55.721380] [<c026afa8>] (drm_mode_set_config_internal) from [<c025c208>] (restore_fbdev_mode+0xcc/0xec)
[ 55.730834] [<c025c208>] (restore_fbdev_mode) from [<c025c244>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x1c/0x30)
[ 55.741424] [<c025c244>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c025e0a8>] (drm_fb_helper_set_par+0x1c/0x60)
[ 55.752271] [<c025e0a8>] (drm_fb_helper_set_par) from [<c025e174>] (drm_fb_helper_hotplug_event+0x88/0xc4)
[ 55.761906] [<c025e174>] (drm_fb_helper_hotplug_event) from [<c02571c4>] (drm_helper_hpd_irq_event+0xc8/0x134)
[ 55.771898] [<c02571c4>] (drm_helper_hpd_irq_event) from [<c028e27c>] (vidi_store_connection+0x90/0xc8)
[ 55.781268] [<c028e27c>] (vidi_store_connection) from [<c0125f80>] (kernfs_fop_write+0xc0/0x180)
[ 55.790045] [<c0125f80>] (kernfs_fop_write) from [<c00cdf60>] (vfs_write+0xa0/0x1ac)
[ 55.797757] [<c00cdf60>] (vfs_write) from [<c00ce468>] (SyS_write+0x44/0x9c)
[ 55.804790] [<c00ce468>] (SyS_write) from [<c000e6a0>] (ret_fast_syscall+0x0/0x30)
[ 55.812328] ---[ end trace 3c0fe4386702d4dd ]---
This issue occurs when modeset to vidi is tried in case that drm_vblank_init
is called prior to crtc creation of vidi driver. In this case, crtc number
of vidi is invalid so any requests with the crtc number will fail.
This patch guarantees drm_vblank_init to be called after all kms drivers
are ready by using component framework.
Inki Dae [Mon, 24 Nov 2014 07:58:48 +0000 (16:58 +0900)]
drm/exynos: fix exynos_drm_component_del
This patch resolves the issue that component object isn't removed
correctly.
A given component object couldn't be placed to head of drm_component_list
so all component objects added to the drm_component_list should be checked
to remove the given component object.
Gustavo Padovan [Mon, 24 Nov 2014 07:37:26 +0000 (16:37 +0900)]
drm/exynos: move Exynos platform drivers registration to init
Registering the Exynos DRM subdevices platform drivers in the probe
function is causing an infinite loop. Fix this by moving it to the
exynos_drm_init() function to register the drivers on module init.
Registering drivers in the probe functions causes a deadlock in the parent
device lock. See Grant Likely explanation on the topic:
"I think the problem is that exynos_drm_init() is registering a normal
(non-OF) platform device, so the parent will be /sys/devices/platform.
It immediately gets bound against exynos_drm_platform_driver which
calls the exynos drm_platform_probe() hook. The driver core obtains
device_lock() on the device *and on the device parent*.
Inside the probe hook, additional platform_drivers get registered.
Each time one does, it tries to bind against every platform device in
the system, which includes the ones created by OF. When it attempts to
bind, it obtains device_lock() on the device *and on the device
parent*.
Before the change to move of-generated platform devices into
/sys/devices/platform, the devices had different parents. Now both
devices have /sys/devices/platform as the parent, so yes they are
going to deadlock.
The real problem is registering drivers from within a probe hook. That
is completely wrong for the above deadlock reason. __driver_attach()
will deadlock. Those registrations must be pulled out of .probe().
Registering devices in .probe() is okay because __device_attach()
doesn't try to obtain device_lock() on the parent."
INFO: task swapper/0:1 blocked for more than 120 seconds.
Not tainted 3.18.0-rc3-next-20141105 #794
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
swapper/0 D c052534c 0 1 0 0x00000000
[<c052534c>] (__schedule) from [<c0525b34>] (schedule_preempt_disabled+0x14/0x20)
[<c0525b34>] (schedule_preempt_disabled) from [<c0526d44>] (mutex_lock_nested+0x1c4/0x464
[<c0526d44>] (mutex_lock_nested) from [<c02be908>] (__driver_attach+0x48/0x98)
[<c02be908>] (__driver_attach) from [<c02bcc00>] (bus_for_each_dev+0x54/0x88)
[<c02bcc00>] (bus_for_each_dev) from [<c02bdce0>] (bus_add_driver+0xe4/0x200)
[<c02bdce0>] (bus_add_driver) from [<c02bef94>] (driver_register+0x78/0xf4)
[<c02bef94>] (driver_register) from [<c029e99c>] (exynos_drm_platform_probe+0x34/0x234)
[<c029e99c>] (exynos_drm_platform_probe) from [<c02bfcf0>] (platform_drv_probe+0x48/0xa4)
[<c02bfcf0>] (platform_drv_probe) from [<c02be680>] (driver_probe_device+0x13c/0x37c)
[<c02be680>] (driver_probe_device) from [<c02be954>] (__driver_attach+0x94/0x98)
[<c02be954>] (__driver_attach) from [<c02bcc00>] (bus_for_each_dev+0x54/0x88)
[<c02bcc00>] (bus_for_each_dev) from [<c02bdce0>] (bus_add_driver+0xe4/0x200)
[<c02bdce0>] (bus_add_driver) from [<c02bef94>] (driver_register+0x78/0xf4)
[<c02bef94>] (driver_register) from [<c029e938>] (exynos_drm_init+0x70/0xa0)
[<c029e938>] (exynos_drm_init) from [<c00089b0>] (do_one_initcall+0xac/0x1f0)
[<c00089b0>] (do_one_initcall) from [<c074bd90>] (kernel_init_freeable+0x10c/0x1d8)
[<c074bd90>] (kernel_init_freeable) from [<c051eabc>] (kernel_init+0x8/0xec)
[<c051eabc>] (kernel_init) from [<c000f268>] (ret_from_fork+0x14/0x2c)
3 locks held by swapper/0/1:
#0: (&dev->mutex){......}, at: [<c02be908>] __driver_attach+0x48/0x98
#1: (&dev->mutex){......}, at: [<c02be918>] __driver_attach+0x58/0x98
#2: (&dev->mutex){......}, at: [<c02be908>] __driver_attach+0x48/0x98
Changelog v2:
- call platform_driver_register after all kms and non kms drivers are
registered
- rebased it to exynos-drm-next
Moving subdriver probe to exynos_drm_platform_probe() was making
exynos_drm_device_subdrv_probe() fail because the platform data wasn't set
yet. It only gets set in exynos_drm_load.
Andrzej Hajda [Mon, 17 Nov 2014 08:54:26 +0000 (09:54 +0100)]
drm/exynos/dpi: embed display into private context
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dpi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple dpi devices in the system.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Andrzej Hajda [Mon, 17 Nov 2014 08:54:24 +0000 (09:54 +0100)]
drm/exynos/dp: embed display into private context
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dp
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple dp devices in the system.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Andrzej Hajda [Mon, 17 Nov 2014 08:54:22 +0000 (09:54 +0100)]
drm/exynos/vidi: embed display into private context
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to vidi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple vidi devices in the system.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Andrzej Hajda [Mon, 17 Nov 2014 08:54:20 +0000 (09:54 +0100)]
drm/exynos/hdmi: embed display into private context
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to hdmi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple hdmi devices in the system.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Andrzej Hajda [Mon, 17 Nov 2014 08:54:18 +0000 (09:54 +0100)]
drm/exynos/fimd: embed manager into private context
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple FIMD devices in the system.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Andrzej Hajda [Mon, 17 Nov 2014 08:54:16 +0000 (09:54 +0100)]
drm/exynos/vidi: embed manager into private context
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to vidi private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple mixer devices in the system.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Andrzej Hajda [Mon, 24 Nov 2014 05:12:46 +0000 (14:12 +0900)]
drm/exynos/mixer: embed manager into private context
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple mixer devices in the system.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
YoungJun Cho [Mon, 17 Nov 2014 13:00:16 +0000 (22:00 +0900)]
drm/exynos: dsi: set TE GPIO IRQ status as IRQ_NOAUTOEN
The exynos_dsi_te_irq_handler() works only dsi(DPMS) is on.
So it is enough to enable and disable TE GPIO IRQ in
exynos_dsi_enable(disable)_irq() like DSI IRQ.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com>a Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
YoungJun Cho [Mon, 17 Nov 2014 13:00:15 +0000 (22:00 +0900)]
drm/exynos: dsi: move TE irq handler registration position
The drm_helper_hpd_irq_event() does dpms control and
the panel is initialized and displayed on by it.
So the exynos_dsi_te_irq_handler() should be registered
beforehand.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
YoungJun Cho [Mon, 17 Nov 2014 13:00:13 +0000 (22:00 +0900)]
drm/exynos: fimd: add triggering unset routine in fimd_trigger()
There is a case like set config which requires triggering
but vblank is not enabled yet.
So triggering unset routine is required to exit from
triggering mode.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
For the I80 interface, the video interrupt pending register(VIDINTCON1)
should be handled in fimd_irq_handler() and the video interrupt control
register(VIDINTCON0) should be handled in fimd_enable_vblank() and
fimd_disable_vblank() like RGB interface.
So this patch moves each set / unset routines into proper positions.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
YoungJun Cho [Mon, 17 Nov 2014 13:00:11 +0000 (22:00 +0900)]
drm/exynos: fimd: add fimd_enable_shadow_channel_path() to cleanup
This function is valid only the SoC has SHADOWCON register
and it should be used together with fimd_enable_video_output()
to match the ENWIN_F bit in WINCON# and C#_EN_F bit in SHADOWCON.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Joonyoung Shim [Mon, 17 Nov 2014 13:00:08 +0000 (22:00 +0900)]
drm/exynos: move triggering checking
It's better to be checking whether triggerring in fimd_trigger function.
Also it will return if in triggerring on fimd_te_handler, then it can't
execute remain codes.
Joonyoung Shim [Fri, 14 Nov 2014 02:36:02 +0000 (11:36 +0900)]
drm/exynos: add has_vtsel flag
The exynos fimd provides video type selection bits from system register
but exynos3 series don't has it, so needs has_vtsel flag and we can
distinguish whether set video type selection bits.
drm/exynos: Fix DSI resuming fail because power domain being off
During system resume from suspend to RAM the Exynos DRM driver forced
CRTC mode thus turning display on (DPMS_ON). This lead to runtime resuming
of DSI which failed because whole LCD power domain was off and it was
not allowed to turn on because of system resume in progress.
Forcing mode should not be needed and removing it solves this particular
problem.
This necessary fix for following scenario reproduced on Exynos DRM:
1. Power domain is off before suspending the system.
2. System is suspended to RAM.
3. Resuming starts. The Exynos DRM driver resume callback is called.
4. The Exynos DRM driver calls drm_helper_resume_force_mode() which turns
on the screen by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON.
5. The Exynos DSI driver calls pm_runtime_get. The driver runtime
resumes and this should turn LCD power domain on.
6. Unfortunately the domain cannot be turned on because system resume is
in progress and genpd->prepared_count is positive.
Steps to reproduce:
1. Add runtime PM to Exynos DSI driver.
2. Build Exynos DRM/FB without FRAMEBUFFER_CONSOLE.
3. Enable the connector and screen (e.g. with modeset-vsync).
4. echo 3 > /sys/devices/platform/exynos-drm/graphics/fb0/blank
5. echo mem > /sys/power/state
6. Resume.
[ 77.712469] PM: early resume of devices complete after 3.854 msecs
[ 77.712739] exynos-dsi 11c80000.dsi: pm_genpd_resume()
[ 77.712758] exynos4-fimc 11800000.fimc: pm_genpd_resume()
[ 77.712774] exynos4-fimc 11810000.fimc: pm_genpd_resume()
[ 77.712787] exynos-drm-fimc 11820000.fimc: pm_genpd_resume()
[ 77.712802] exynos-drm-fimc 11830000.fimc: pm_genpd_resume()
[ 77.712815] s5p-mipi-csis 11880000.csis: pm_genpd_resume()
[ 77.712829] s5p-mipi-csis 11890000.csis: pm_genpd_resume()
[ 77.712843] exynos-fimc-lite 12390000.fimc-lite: pm_genpd_resume()
[ 77.712856] exynos-fimc-lite 123a0000.fimc-lite: pm_genpd_resume()
[ 77.713788] exynos4-fb 11c00000.fimd: pm_genpd_resume()
[ 77.713912] wake disabled for irq 184
[ 77.713923] wake disabled for irq 185
[ 77.714082] wake disabled for irq 173
[ 77.715676] wake disabled for irq 176
[ 77.718540] exynos4-fb 11c00000.fimd: pm_genpd_runtime_resume()
[ 77.718567] exynos4-fb 11c00000.fimd: state restore latency exceeded, new value 1708 ns
[ 77.718636] exynos-dsi 11c80000.dsi: pm_genpd_runtime_resume()
[ 77.892366] exynos-dsi 11c80000.dsi: PLL failed to stabilize
[ 77.892377] exynos-dsi 11c80000.dsi: failed to configure DSI PLL
[ 78.192168] exynos-dsi 11c80000.dsi: timeout waiting for reset
[ 78.211578] exynos-dsi 11c80000.dsi: waiting for bus lanes timed out
[ 78.307173] exynos-dsi 11c80000.dsi: xfer timed out: d1 00 (null)
[ 78.307190] panel_s6e8aa0 11c80000.dsi.0: error -110 reading dcs seq(0xd1)
[ 78.307199] panel_s6e8aa0 11c80000.dsi.0: read id failed
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
YoungJun Cho [Wed, 1 Oct 2014 06:19:13 +0000 (15:19 +0900)]
drm/exynos: dsi: move DSIM_STATE_ENABLED set position
The command mode panel should draw image earlier than the display
on command execution to prevent showing garbage GRAM screen data.
So should set dsi->state as DSIM_STATE_ENABLED between calling
exynos_dsi_set_display_enable() and drm_panel_enable() to transmit
image data before executing display on command.
And moves the display on command execution routine from prepare()
to enable() in drm_panel_funcs also.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
YoungJun Cho [Wed, 1 Oct 2014 06:19:10 +0000 (15:19 +0900)]
drm/exynos: fimd: move handle vblank position in TE handler
For providing VBLANK information, drm_handle_vblank() should
be called properly, but it is blocked by wait_vsync_event
condition which is set by manager_ops->wait_for_vblank().
So moves it out from wait_vsync_event routine.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com>
The exynos_drm_crtc_dpms() waits until pended page flip
queue is empty, calls the drm_vblank_off() then calls
manager->ops->dpms() when mode is DRM_MODE_DPMS_OFF.
The fimd_dpms() is one of manager->ops->dpms()s and
finally calls fimd_window_suspend().
But there is no active window and vblank is already off
when it is called.
So addtional waiting vblank is not necessary any more.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Vivek Gautam [Wed, 12 Nov 2014 09:42:10 +0000 (15:12 +0530)]
drm/exynos: dp: Remove support for unused dptx-phy
Now that we have moved to generic phy based bindings,
we don't need to have any code related to older dptx-phy.
Nobody is using this dptx-phy anymore, so removing the
same.
Andrzej Hajda [Tue, 7 Oct 2014 12:01:08 +0000 (14:01 +0200)]
drm/exynos: dsi: remove global variable exynos_dsi_display
exynos_dsi_display is used by internal Exynos DRM framework for
representing pair encoder->connecter. As it should be mapped 1:1 to dsi
private context it seems more reasonable to embed it directly
in that context. As a result further code simplification will be possible.
Moreover it will be possible to handle multiple DSI devices in the system.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Andrzej Hajda [Thu, 13 Nov 2014 07:37:57 +0000 (16:37 +0900)]
drm/exynos: remove ifdeferry from initialization code
The patch replaces separate calls to driver (de)registration by
loops over the array of drivers. As a result it significantly
decreases number of ifdefs. Additionally it moves device registration
related ifdefs to header file.
Changelog v2:
- Rebased.
- Consider non kms driver in respect to infinite loop issue.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Inki Dae [Thu, 13 Nov 2014 07:05:12 +0000 (16:05 +0900)]
drm/exynos: fix null pointer dereference issue
This patch fixes null pointer dereference issue incurred
when ipp driver is enabled and Exynos drm driver is closed.
Non kms driver should register its own sub driver to setup necessary
resources, which is done by load(). So null pointer dereference
occurs when ipp driver is enabled and Exynos drm driver is closed
because ipp core device is registered after component_master_add_with_match
call.
This patch makes exynos_drm_device_subdrv_probe() to be called after all non
kms drivers are registered.
Inki Dae [Fri, 7 Nov 2014 12:32:34 +0000 (21:32 +0900)]
drm/exynos: fix possible infinite loop issue
This patch fixes possible infinite loop issue by postponing
registration to non kms drivers after component_master_add_with_match
call, which can be incurred in all cases that non kms driver is probed
and then component bind is failed
This patch should be applied on top of below patches,
http://comments.gmane.org/gmane.comp.video.dri.devel/117740
http://www.spinics.net/lists/linux-samsung-soc/msg38624.html
Inki Dae [Fri, 7 Nov 2014 11:31:08 +0000 (20:31 +0900)]
drm/exynos: g2d: fix null pointer dereference
This patch fixes a null pointer dereference issue incurred by
calling g2d_remove when exynos_drm_platform_probe is failed.
cmdlist_pool of g2d is allocated when g2d sub driver is probed.
So if exynos_drm_platform_probe is failed, the g2d sub driver is
not probed and the cmdlist_pool is still NULL.
Inki Dae [Thu, 6 Nov 2014 14:00:37 +0000 (23:00 +0900)]
drm/exynos: resolve infinite loop issue on non multi-platform
This patch resovles the infinite loop issue incurred
when Exyno drm driver is enabled but all kms drivers
are disabled on Exynos board by returning -EPROBE_DEFER
only in case that there is kms device registered.
Inki Dae [Thu, 6 Nov 2014 10:23:35 +0000 (19:23 +0900)]
drm/exynos: resolve infinite loop issue on multi-platform
This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.
Rob Clark [Thu, 20 Nov 2014 20:40:36 +0000 (15:40 -0500)]
drm/atomic: shutdown *current* encoder
In disable_outputs() we need to shut down the outgoing encoder, not the
incoming one (we have already swapped-state at this point). Without
this, we end up telling the driver to crtc->dpms(OFF) without first
encoder->dpms(OFF), and that makes some hw quite unhappy.
v2: missing WARN_ON() hunk and comment
Reviewed-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
projects / linux-beck.git / log