- 09 Nov, 2014 1 commit
-
-
Oded Gabbay authored
Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Oded Gabbay <oded.gabbay@amd.com>
-
- 19 Nov, 2014 1 commit
-
-
Alexey Skidanov authored
Reviewed-by:
Alexey Skidanov <Alexey.Skidanov@amd.com> Signed-off-by:
-
- 17 Nov, 2014 1 commit
-
-
Oded Gabbay authored
amdkfd uses cpu_relax() in its sync_with_hw() function. Because cpu_relax() is defined as 'REP; NOP' on x86_64, it will block the CPU from servicing IOMMU PPR requests. This may cause a deadlock, because sync_with_hw() won't be completed until the PPR request has been served. Therefore, we need to use schedule() instead of cpu_relax() as it is the minimum requirement to allow other threads to execute. Reviewed-by:
-
- 20 Nov, 2014 9 commits
-
-
Jay Cornwall authored
struct device_process_node was allocated during process registration but not released at process deregistration. Reviewed-by:
Jay Cornwall <jay.cornwall@amd.com> Signed-off-by:
-
Oded Gabbay authored
This patch was done due to sparse warning. It changes the definition of doorbell_ptr in queue_properties to be with __iomem attribute, so it would match the type which the doorbell module functions are returning. Reviewed-by:
-
Oded Gabbay authored
Reviewed-by:
-
Oded Gabbay authored
Reviewed-by:
-
Oded Gabbay authored
Reviewed-by:
-
kbuild test robot authored
Reviewed-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
kbuild test robot authored
Reviewed-by:
-
Oded Gabbay authored
Reviewed-by:
-
Oded Gabbay authored
Reviewed-by:
-
- 25 Nov, 2014 8 commits
-
-
Philipp Zabel authored
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>
-
Philipp Zabel authored
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:
-
Dave Airlie authored
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 ...
-
git://people.freedesktop.org/~robclark/linuxDave Airlie authored
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 authored
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>
-
Gustavo Padovan authored
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:
-
Inki Dae authored
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 authored
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:
-
- 24 Nov, 2014 20 commits
-
-
Julia Lawall authored
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 authored
Use 'for' statemant instead of hard-coded 'if' statement. Signed-off-by: -
Gustavo Padovan authored
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 authored
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:
-
Andrzej Hajda authored
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:
-
Andrzej Hajda authored
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 authored
The patch replaces accesses to display->ctx pointer by container_of construct. It will allow to remove ctx field in the future. Signed-off-by:
-
Andrzej Hajda authored
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 authored
The patch replaces accesses to display->ctx pointer by container_of construct. It will allow to remove ctx field in the future. Signed-off-by:
-
Andrzej Hajda authored
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 authored
The patch replaces accesses to display->ctx pointer by container_of construct. It will allow to remove ctx field in the future. Signed-off-by:
-
Andrzej Hajda authored
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 authored
The patch replaces accesses to manager->ctx pointer by container_of construct. As fimd was the last user of ctx the patch removes this field as well. Signed-off-by:
-
Andrzej Hajda authored
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 authored
The patch replaces accesses to manager->ctx pointer by container_of construct. It will allow to remove ctx field in the future. Signed-off-by:
-
Andrzej Hajda authored
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 authored
The patch replaces accesses to manager->ctx pointer by container_of construct. It will allow to remove ctx field in the future. Signed-off-by:
-
Andrzej Hajda authored
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:
-
YoungJun Cho authored
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:
-
YoungJun Cho authored
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:
-
