summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2014-12-02Merge tag 'topic/core-stuff-2014-11-28' of ↵Dave Airlie16-75/+226
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
2014-12-02ARM: shmobile: marzen: Remove DU platform deviceLaurent Pinchart1-58/+0
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>
2014-12-02ARM: shmobile: lager: Remove DU platform deviceLaurent Pinchart1-58/+0
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>
2014-11-27drm/atomic: clear plane's CRTC and FB when shutting downRob Clark1-6/+13
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>
2014-11-27drm: Handle atomic state properly in kms getfoo ioctlDaniel Vetter1-3/+46
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>
2014-11-27drm: use mode_object_find helpersRob Clark1-9/+4
Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-27drm: fix indentationRob Clark1-1/+1
Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-27drm/msm: switch to atomic-helpers iterator macrosRob Clark3-30/+8
Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-27drm/atomic: add plane iterator macrosRob Clark3-0/+38
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>
2014-11-27drm/atomic: track bitmask of planes attached to crtcRob Clark4-14/+38
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>
2014-11-27Merge branch 'drm/du/adv7511' of git://linuxtv.org/pinchartl/fbdev into drm-nextDave Airlie77-524/+2232
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
2014-11-27Merge branch 'amdkfd-next-3.19' of ↵Dave Airlie12-64/+76
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
2014-11-26drm: Add adv7511 encoder driverLars-Peter Clausen4-0/+1307
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. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2014-11-26video: Add ADV751[13] DT bindings documentationLaurent Pinchart1-0/+88
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. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2014-11-26drm: Decouple EDID parsing from I2C adapterLars-Peter Clausen2-13/+35
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>
2014-11-26drm: rcar-du: Add HDMI encoder and connector supportLaurent Pinchart9-7/+375
SoCs that integrate the DU have no internal HDMI encoder, support external encoders only. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2014-11-26drm: rcar-du: Replace drm_encoder with drm_slave_encoderLaurent Pinchart1-3/+4
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. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2014-11-26drm: rcar-du: Replace direct DRM encoder access with cast macroLaurent Pinchart4-7/+13
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. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2014-11-26drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init()Laurent Pinchart3-4/+6
The encoder DT node will be needed to register an external HDMI encoder. Pass it to the rcar_du_encoder_init() function to prepare for HDMI support. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2014-11-26drm: rcar-du: Remove platform data supportLaurent Pinchart10-151/+38
All platforms now instantiate the DU through DT, platform data support isn't needed anymore. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2014-11-26drm: rcar-du: fix error return codeJulia Lawall1-1/+1
Propagate the error code on failure. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier ret; expression e1,e2; @@ ( if (\(ret < 0\|ret != 0\)) { ... return ret; } | ret = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2014-11-26drm/udl: properly check for error pointersHaixia Shi1-3/+3
The drm_prime_pages_to_sg() function never returns NULL pointers, only error pointers and valid pointers. Signed-off-by: Haixia Shi <hshi@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-26drm/udl: handle page mapping in dmabuf export.Haixia Shi3-4/+9
Fixes dmabuf export failure with -E_NOMEM when the page is not mapped. Signed-off-by: Haixia Shi <hshi@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-26MAINTAINERS: add maintainer for i.MX DRM driverPhilipp Zabel1-0/+7
Add myself as the maintainer of the i.MX DRM driver. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-26drm: imx: Move imx-drm driver out of stagingPhilipp Zabel20-20/+3
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>
2014-11-26Merge tag 'tags/renesas-dt-du-for-v3.19' into drm/next/adv7511-baseLaurent Pinchart52-343/+370
Renesas ARM Based SoC DT DU Updates for v3.19 * Enable DU using DT on marzen/r8a7779, lager/r8a7790 and koelsch/r8a7791
2014-11-26Merge branch 'exynos-drm-next' of ↵Dave Airlie17-666/+609
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 ...
2014-11-25amdkfd: delete some dead codeDan Carpenter1-5/+0
This is dead code. We don't need to unbind here, we can just return directly. Reviewed-by: Oded Gabbay <oded.gabbay@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-11-25amdkfd: Fix memory leak of mqds on dqm finiOded Gabbay1-0/+4
The mqds array members are not freed when dqm is uninitialized. Reviewed-by: Ben Goz <Ben.Goz@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-11-25drm: Free atomic state during cleanupThierry Reding1-0/+13
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>
2014-11-25drm: Make drm_atomic.h standalone includibleThierry Reding1-0/+2
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>
2014-11-25drm: Make drm_atomic_helper.h standalone includibleThierry Reding1-0/+2
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>
2014-11-25drm/plane: Add missing kerneldocThierry Reding1-0/+4
The plane helpers aren't pulled into the DocBook yet, so these weren't noticed. 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>
2014-11-25drm/plane: Pass old state to ->atomic_update()Thierry Reding5-5/+11
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>
2014-11-25drm/atomic_helper: Cope with plane->crtc == NULL in disable helperJasper St. Pierre1-0/+11
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>
2014-11-25drm/atomic: Drop per-plane locking TODODaniel Vetter1-6/+0
I've forgotten to remove that in my per-plane locking patch. Reported-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-25drm/atomic-helper: Skip vblank waits for unchanged fbsDaniel Vetter1-1/+33
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>
2014-11-25drm: Document that drm_dev_alloc doesn't need a parentDaniel Vetter1-0/+2
Possible for purely virtual debug devices. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-25Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into ↵Dave Airlie24-739/+1737
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
2014-11-25amdkfd: fix an error handling bug in pqm_create_queue()Dan Carpenter1-1/+1
The call to kernel_queue_uninit(NULL) will trigger a BUG(), and also the error code is incorrect. Fixes: 45102048f77e ('amdkfd: Add process queue manager module') Reviewed-by: Oded Gabbay <oded.gabbay@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-11-25amdkfd: fix some error handling in ioctlDan Carpenter1-2/+2
There is a typo here so the errors from kfd_bind_process_to_device() are not detected. Reviewed-by: Oded Gabbay <oded.gabbay@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-11-25drm/exynos: avoid leak if exynos_dpi_probe() failsGustavo Padovan1-2/+4
The component must be deleted if the probe fails. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-25drm/exynos: Fix exynos_dpi_remove() parameterGustavo Padovan1-1/+4
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. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-25drm/exynos: vidi: add component supportInki Dae1-16/+45
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. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-25drm/exynos: fix exynos_drm_component_delInki Dae1-2/+0
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. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24drm/exynos/ipp: fix error return codeJulia Lawall1-0/+3
Propagate the returned error code on failure. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier ret; expression e1,e2; @@ ( if (\(ret < 0\|ret != 0\)) { ... return ret; } | ret = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24drm/exynos: clean up machine compatible string checkInki Dae1-3/+15
Use 'for' statemant instead of hard-coded 'if' statement. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24drm/exynos: move Exynos platform drivers registration to initGustavo Padovan1-57/+48
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 Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24Revert "drm/exynos: fix null pointer dereference issue"Gustavo Padovan1-8/+9
This reverts commit cea24824ab432f8acabb254d6805e9aa756de6af. 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. We need to find a smarter way to fix this issue. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24drm/exynos/dpi: stop using display->ctx pointerAndrzej Hajda2-4/+2
The patch replaces accesses to display->ctx pointer by container_of construct. The field is removed as well as dpi was the last user of it. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-03 03:18:50 +0000