[PATCH 1/3] drm/exynos: free DP if probe fails to find a panel or bridge
Hi Gustavo,
On Fri, Nov 21, 2014 at 5:24 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> DP was leaked everytime function returns EPROBE_DEFER, free it before
> returning.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 85762cf..6fd4a46 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1336,8 +1336,10 @@ static int exynos_dp_probe(struct platform_device
> *pdev)
> if (panel_node) {
> dp->panel = of_drm_find_panel(panel_node);
> of_node_put(panel_node);
> - if (!dp->panel)
> - return -EPROBE_DEFER;
> + if (!dp->panel) {
> + ret = -EPROBE_DEFER;
> + goto free_dp;
> + }
> }
>
> endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> @@ -1346,10 +1348,14 @@ static int exynos_dp_probe(struct platform_device
> *pdev)
> if (bridge_node) {
> dp->bridge = of_drm_find_bridge(bridge_node);
> of_node_put(bridge_node);
> - if (!dp->bridge)
> - return -EPROBE_DEFER;
> - } else
> - return -EPROBE_DEFER;
> + if (!dp->bridge) {
> + ret = -EPROBE_DEFER;
> + goto free_dp;
> + }
> + } else {
> + ret = -EPROBE_DEFER;
> + goto free_dp;
> + }
> }
>
> exynos_dp_display.ctx = dp;
> @@ -1359,6 +1365,9 @@ static int exynos_dp_probe(struct platform_device *pdev)
> exynos_drm_component_del(&pdev->dev,
> EXYNOS_DEVICE_TYPE_CONNECTOR);
>
> +free_dp:
> + devm_kfree(dev, dp);
I guess the driver core takes care of freeing the devm memory when the
probe fails?
Will it not happen during PROBE_DEFER?
Inki/Jingoo - Is this change really necessary?
Ajay
> return ret;
> }
>
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] amdkfd-next-3.19
Hi Dave, first batch of amdkfd patches after initial merge. Highlights: - Fixes for sparse warnings - Memory leak fix - Fix for deadlock between amdkfd and iommu The following changes since commit ed1e8777a56f3523712506d608a29f57ed37b613: Merge branch 'drm-next-3.19' of git://people.freedesktop.org/~agd5f/linux into drm-next (2014-11-21 12:17:43 +1000) are available in the git repository at: git://people.freedesktop.org/~gabbayo/linux amdkfd-next-3.19 for you to fetch changes up to 48d7761d23d00ce40c70172727b802a9b5a54962: amdkfd: Remove DRM_AMDGPU dependency from Kconfig (2014-11-21 22:55:31 +0200) Alexey Skidanov (1): amdkfd: Instead of using get function, use container_of Jay Cornwall (1): amdkfd: Fix memory leak on process deregistration Oded Gabbay (10): amdkfd: Fix sparse warnings in kfd_chardev.c amdkfd: Fix sparse warnings in kfd_topology.c amdkfd: Fix sparse warnings in kfd_flat_memory.c amdkfd: is_occupied() can be static amdkfd: fence_wait_timeout() can be static amdkfd: add __iomem attribute to doorbell_ptr amdkfd: use schedule() in sync_with_hw amdkfd: Clear ctx cb before suspend amdkfd: explicitely include io.h in kfd_doorbell.c amdkfd: Remove DRM_AMDGPU dependency from Kconfig kbuild test robot (2): amdkfd: test_kq() can be static amdkfd: pqm_get_kernel_queue() can be static drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 16 ++--- drivers/gpu/drm/amd/amdkfd/kfd_device.c| 1 + .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 27 +++ drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 1 + drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c | 11 +++--- drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 14 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 6 ++-- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 4 ++- .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 3 +- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 40 +++--- 11 files changed, 69 insertions(+), 56 deletions(-)
[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi, I have rebased my bridge series on top of linux-next. This is my git log: 4b38a6f Revert "Revert "ARM: exynos_defconfig: Enable options for display panel support"" 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints aee649c ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge 581257f Documentation: bridge: Add documentation for ps8622 DT properties 178e8b9 Documentation: devicetree: Add vendor prefix for parade 0ceea75 Documentation: drm: bridge: move to video/bridge f143e2e drm/bridge: ptn3460: use gpiod interface 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach 32ac563 drm/bridge: ptn3460: support drm_panel 91c6c30 drm/exynos: dp: support drm_bridge 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model 602f343 drm/bridge: make bridge registration independent of drm flow 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 28655d1 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I have attached the rebased patches as well. I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*. Display is totally fine with exynos_defconfig (booting is fine even with CONFIG_SND_SOC_SNOW=y) Regards, Ajay Kumar On Fri, Nov 21, 2014 at 5:03 PM, Andreas Färber wrote: > Am 21.11.2014 um 00:49 schrieb Paolo Pisati: >> vanilla kgene/for-next as of today: >> >> 7552917 Revert "ARM: exynos_defconfig: Enable options for display panel >> support" >> ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next >> 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next >> cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next >> 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers >> 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device >> 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow >> fc14f9c Linux 3.18-rc5 >> ... >> >> plus >> >> 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy >> 36d908e drm/exynos: dp: Remove support for unused dptx-phy >> 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices >> 68944e3 Revert "Revert "ARM: exynos_defconfig: Enable options for display >> panel >> support"" >> >> vanilla exynos_defconfig with SND_SOC_SNOW disabled. >> >> I should probably try linux-next at this point, but i wonder if people who >> reported kgene/for-next working were testing with a vanilla exynos_defconfig >> on >> a peach pi. > > On Spring, I am able to boot my kgene/for-next based queue with just: > > mfd: syscon: Decouple syscon interface from platform devices > arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy > > with DRM_EXYNOS*=y (except IOMMU) and SND_SOC_SNOW=m enabled in the > config, while using simplefb rather than the Exynos DRM and thus > clk_ignore_unused. > > Regarding SND_SOC_SNOW: Note that I recently submitted a patch to enable > module-loading, which is missing in kgene/for-next and -rc5 but is in > linux-next.git - it might uncover problems that previously went > unnoticed: https://patchwork.kernel.org/patch/5235951/ > exynos_defconfig has SND_SOC_SNOW=y, whereas multi_v7_defconfig doesn't > have it. > > Regards, > Andreas > > -- > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- next part -- A non-text attachment was scrubbed... Name: Tot.tar.bz2 Type: application/x-bzip2 Size: 20037 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/67f5f5a4/attachment-0001.bin>
[PATCH resend] amdkfd: Remove DRM_AMDGPU dependency from Kconfig
This patch removes the dependency of amdkfd upon DRM_AMDGPU symbol in amdkfd's Kconfig file. This is done because amdgpu driver is not yet upstreamed and therefore, DRM_AMDGPU symbol is not present in any Kconfig file. Reviewed-by: Alex Deucher Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig b/drivers/gpu/drm/amd/amdkfd/Kconfig index e13c67c..8dfac37 100644 --- a/drivers/gpu/drm/amd/amdkfd/Kconfig +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig @@ -4,6 +4,6 @@ config HSA_AMD tristate "HSA kernel driver for AMD GPU devices" - depends on (DRM_RADEON || DRM_AMDGPU) && AMD_IOMMU_V2 && X86_64 + depends on DRM_RADEON && AMD_IOMMU_V2 && X86_64 help Enable this if you want to use HSA features on AMD GPU devices. -- 2.1.0
[PATCH] amdkfd: Remove DRM_AMDGPU dependency from Kconfig
Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig b/drivers/gpu/drm/amd/amdkfd/Kconfig index e13c67c..8dfac37 100644 --- a/drivers/gpu/drm/amd/amdkfd/Kconfig +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig @@ -4,6 +4,6 @@ config HSA_AMD tristate "HSA kernel driver for AMD GPU devices" - depends on (DRM_RADEON || DRM_AMDGPU) && AMD_IOMMU_V2 && X86_64 + depends on DRM_RADEON && AMD_IOMMU_V2 && X86_64 help Enable this if you want to use HSA features on AMD GPU devices. -- 2.1.0
[Bug 85421] radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.
https://bugzilla.kernel.org/show_bug.cgi?id=85421 --- Comment #12 from Hin-Tak Leung --- Created attachment 158451 --> https://bugzilla.kernel.org/attachment.cgi?id=158451&action=edit /var/log/message, another GPU crash under mesa 10.3.3 Fedora shipped mesa 10.3.3 http://koji.fedoraproject.org/koji/buildinfo?buildID=593648 and it upgraded my custom-built 10.2.9 . Bad idea! The GPU crashed again the first time resuming from a suspend. I have been suspending/resuming under 10.2.9 happily for two+ weeks and generally happy with it for that period. Though it looks like I upgraded from kernel 3.17.2-200 to 3.17.3-200 yesterday and have not needed to suspend during that time. This time the log is interesting in that an hour into using the newer 10.3.3, I have a pile of: Nov 21 13:47:47 localhost kernel: radeon :00:01.0: GPU fault detected: 146 0x02690004 Nov 21 13:47:47 localhost kernel: radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x7D93 Nov 21 13:47:47 localhost kernel: radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0904 Nov 21 13:47:47 localhost kernel: VM fault (0x04, vmid 4) at page 32147, write from 'CB0' (0x43423000) (0) though it looks like I continue to use the machine for another hour, suspend, then GPU crash on resume. Oh, just firefox (plus a few terminals) in gnome-shell class mode in gnome 2.12 copr. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] amdkfd: explicitely include io.h in kfd_doorbell.c
This patch fixes a compilation error when using certain configuration by including the file io.h in kfd_doorbell.c Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c index 0dcb787..b5791a5 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c @@ -23,6 +23,7 @@ #include #include #include +#include /* * This extension supports a kernel level doorbells management for -- 2.1.0
randconfig build error with next-20141121, in drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
On 11/21/2014 07:04 PM, Jim Davis wrote: > Building with the attached random configuration file, > > drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c: In function > âkfd_doorbell_initâ: > drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c:97:2: error: implicit > declaration of function âioremapâ > [-Werror=implicit-function-declaration] > kfd->doorbell_kernel_ptr = ioremap(kfd->doorbell_base, > ^ > drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c:97:27: warning: assignment > makes pointer from integer without a cast [enabled by default] > kfd->doorbell_kernel_ptr = ioremap(kfd->doorbell_base, >^ > drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c: In function > âwrite_kernel_doorbellâ: > drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c:217:3: error: implicit declaration > of > function âwritelâ [-Werror=implicit-function-declaration] >writel(value, db); >^ > cc1: some warnings being treated as errors > make[4]: *** [drivers/gpu/drm/amd/amdkfd/kfd_doorbell.o] Error 1 > Thanks, I'm now sending a patch that fixes this problem. Oded
[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Ajay,
On 11/21/2014 06:32 PM, Ajay kumar wrote:
> Hi,
>
> I have rebased my bridge series on top of linux-next.
>
> This is my git log:
> 4b38a6f Revert "Revert "ARM: exynos_defconfig: Enable options for
> display panel support""
> 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge
> and panel using videoport and endpoints
> aee649c ARM: dts: snow: represent the connection between bridge and
> panel using videoport and endpoints
> 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
> 581257f Documentation: bridge: Add documentation for ps8622 DT properties
> 178e8b9 Documentation: devicetree: Add vendor prefix for parade
> 0ceea75 Documentation: drm: bridge: move to video/bridge
> f143e2e drm/bridge: ptn3460: use gpiod interface
> 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach
> 32ac563 drm/bridge: ptn3460: support drm_panel
> 91c6c30 drm/exynos: dp: support drm_bridge
> 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model
> 602f343 drm/bridge: make bridge registration independent of drm flow
> 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
> 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups
> 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> 28655d1 drm/exynos: Move platform drivers registration to module init
> ed6778a Add linux-next specific files for 20141121
>
> I have attached the rebased patches as well.
> I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*.
> Display is totally fine with exynos_defconfig (booting is fine even
> with CONFIG_SND_SOC_SNOW=y)
>
Thanks for forward porting your patches to linux-next. Unfortunately I
won't have time to test them until Monday but I wonder why you didn't
have the boot issues that we have with next-20141121.
I found that the commit ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add
runtime Power Management support v12") had to be reverted in order to
boot linux-next.
Best regards,
Javier
[PATCH] amdkfd: Remove DRM_AMDGPU dependency from Kconfig
On Fri, Nov 21, 2014 at 10:40:17PM +0200, Oded Gabbay wrote: > Signed-off-by: Oded Gabbay You should provide a rationale for this change in the commit message. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/725d4a45/attachment-0001.sig>
[PATCH 2/2] drm/atomic: add plane iterator macros
On Fri, Nov 21, 2014 at 03:28:32PM -0500, Rob Clark wrote: > 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 > --- > Documentation/DocBook/drm.tmpl | 1 + > include/drm/drm_atomic_helper.h | 26 ++ > 2 files changed, 27 insertions(+) I'd personally do s/crtc/CRTC/ in the commit message and kerneldoc descriptions, but perhaps not everyone shares that same pedantry. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/068c8ae6/attachment.sig>
[PATCH 2/2] drm/atomic: add plane iterator macros
On Fri, Nov 21, 2014 at 09:38:40PM +0100, Daniel Vetter wrote: > On Fri, Nov 21, 2014 at 03:28:32PM -0500, Rob Clark wrote: > > 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 > > --- > > Documentation/DocBook/drm.tmpl | 1 + > > include/drm/drm_atomic_helper.h | 26 ++ > > 2 files changed, 27 insertions(+) > > > > diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl > > index 8c54f9a..3789f2d 100644 > > --- a/Documentation/DocBook/drm.tmpl > > +++ b/Documentation/DocBook/drm.tmpl > > @@ -2343,6 +2343,7 @@ void intel_crt_init(struct drm_device *dev) > > Atomic State Reset and Initialization > > !Pdrivers/gpu/drm/drm_atomic_helper.c atomic state reset and initialization > > > > +!Iinclude/drm/drm_atomic_helper.h > > !Edrivers/gpu/drm/drm_atomic_helper.c > > > > > > diff --git a/include/drm/drm_atomic_helper.h > > b/include/drm/drm_atomic_helper.h > > index 64b4e91..42d56e6 100644 > > --- a/include/drm/drm_atomic_helper.h > > +++ b/include/drm/drm_atomic_helper.h > > @@ -96,5 +96,31 @@ drm_atomic_helper_connector_duplicate_state(struct > > drm_connector *connector); > > void drm_atomic_helper_connector_destroy_state(struct drm_connector > > *connector, > > struct drm_connector_state *state); > > > > +/** > > + * drm_crtc_for_each_plane - iterate over planes currently attached to crtc > > + * @plane: the loop cursor > > + * @crtc: the crtc whose planes are iterated > > + * > > + * This iterates over the current state, useful (for example) when applying > > + * atomic state after it has been checked and swapped. To iterate over the > > + * planes which *will* be attached (for ->atomic_check()) see > > + * drm_crtc_for_each_pending_plane() > > + */ > > +#define drm_crtc_for_each_plane(plane, crtc) \ > > + list_for_each_entry((plane), &(crtc)->dev->mode_config.plane_list, > > head) \ > > + if ((crtc)->state->plane_mask & (1 << drm_plane_index(plane))) > > Implement this as drm_crtc_for_each_pending_plane(plane, (crtc)->state)? > Which means _pending is a strange name ... Yeah, I think the drm_crtc_for_each_pending_plane() could be drm_crtc_state_for_each_plane(), then your suggestion makes perfect sense. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/8456bd83/attachment.sig>
[PATCH 2/2] drm/atomic: add plane iterator macros
On Fri, Nov 21, 2014 at 03:28:32PM -0500, Rob Clark wrote: > 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 > --- > Documentation/DocBook/drm.tmpl | 1 + > include/drm/drm_atomic_helper.h | 26 ++ > 2 files changed, 27 insertions(+) > > diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl > index 8c54f9a..3789f2d 100644 > --- a/Documentation/DocBook/drm.tmpl > +++ b/Documentation/DocBook/drm.tmpl > @@ -2343,6 +2343,7 @@ void intel_crt_init(struct drm_device *dev) > Atomic State Reset and Initialization > !Pdrivers/gpu/drm/drm_atomic_helper.c atomic state reset and initialization > > +!Iinclude/drm/drm_atomic_helper.h > !Edrivers/gpu/drm/drm_atomic_helper.c > > > diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h > index 64b4e91..42d56e6 100644 > --- a/include/drm/drm_atomic_helper.h > +++ b/include/drm/drm_atomic_helper.h > @@ -96,5 +96,31 @@ drm_atomic_helper_connector_duplicate_state(struct > drm_connector *connector); > void drm_atomic_helper_connector_destroy_state(struct drm_connector > *connector, > struct drm_connector_state *state); > > +/** > + * drm_crtc_for_each_plane - iterate over planes currently attached to crtc > + * @plane: the loop cursor > + * @crtc: the crtc whose planes are iterated > + * > + * This iterates over the current state, useful (for example) when applying > + * atomic state after it has been checked and swapped. To iterate over the > + * planes which *will* be attached (for ->atomic_check()) see > + * drm_crtc_for_each_pending_plane() > + */ > +#define drm_crtc_for_each_plane(plane, crtc) \ > + list_for_each_entry((plane), &(crtc)->dev->mode_config.plane_list, > head) \ > + if ((crtc)->state->plane_mask & (1 << drm_plane_index(plane))) Implement this as drm_crtc_for_each_pending_plane(plane, (crtc)->state)? Which means _pending is a strange name ... -Daniel > + > +/** > + * drm_crtc_for_each_pending_plane - iterate over attached planes in new > state > + * @plane: the loop cursor > + * @crtc_state: the incoming crtc-state > + * > + * Similar to drm_crtc_for_each_plane(), but iterates the planes that will be > + * attached if the specified state is applied. Useful during (for example) > + * ->atomic_check() operations, to validate the incoming state > + */ > +#define drm_crtc_for_each_pending_plane(plane, crtc_state) \ > + list_for_each_entry((plane), > &(crtc_state)->state->dev->mode_config.plane_list, head) \ > + if ((crtc_state)->plane_mask & (1 << drm_plane_index(plane))) > > #endif /* DRM_ATOMIC_HELPER_H_ */ > -- > 1.9.3 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] modetest: Use threads for cursors instead of SIGALRM
This fixes an issue when trying to use -v and -C together. When trying
to read the page flip event, we are interrupted by the SIGALRM that
comes in, and so we think we timed out when we simply got EINTR. While
we could just loop checking for EINTR, SIGALRM is just bad idea to
begin with, so just rewrite it to use a thread.
---
tests/modetest/Makefile.am | 3 ++-
tests/modetest/cursor.c| 57 +++---
2 files changed, 31 insertions(+), 29 deletions(-)
diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
index 0a6af01..8fc924a 100644
--- a/tests/modetest/Makefile.am
+++ b/tests/modetest/Makefile.am
@@ -19,7 +19,8 @@ modetest_SOURCES = $(MODETEST_FILES)
modetest_LDADD = \
$(top_builddir)/libdrm.la \
- $(top_builddir)/libkms/libkms.la
+ $(top_builddir)/libkms/libkms.la \
+ -lpthread
if HAVE_CAIRO
AM_CFLAGS += $(CAIRO_CFLAGS)
diff --git a/tests/modetest/cursor.c b/tests/modetest/cursor.c
index 60f240a..62a50ef 100644
--- a/tests/modetest/cursor.c
+++ b/tests/modetest/cursor.c
@@ -34,6 +34,8 @@
#include
#include
#include
+#include
+#include
#include "xf86drm.h"
#include "xf86drmMode.h"
@@ -59,6 +61,9 @@ struct cursor {
static struct cursor cursors[MAX_CURSORS];
static int ncursors;
+static pthread_t cursor_thread;
+static int cursor_running;
+
/*
* Timer driven program loops through these steps to move/enable/disable
* the cursor
@@ -137,33 +142,29 @@ static struct cursor_step steps[] = {
{ set_cursor, 10, 0, 0 }, /* disable */
};
-/*
- * Cursor API:
- */
-
-static void run_step(int sig)
+static void *cursor_thread_func(void *data)
{
- struct cursor_step *step = &steps[indx % ARRAY_SIZE(steps)];
- struct itimerval itimer = {
- .it_value.tv_usec = 1000 * step->msec,
- };
- int i;
-
- for (i = 0; i < ncursors; i++) {
- struct cursor *cursor = &cursors[i];
- step->run(cursor, step);
- }
-
- /* iterate to next count/step: */
- if (count < step->repeat) {
- count++;
- } else {
- count = 0;
- indx++;
+ while (cursor_running) {
+ struct cursor_step *step = &steps[indx % ARRAY_SIZE(steps)];
+ int i;
+
+ for (i = 0; i < ncursors; i++) {
+ struct cursor *cursor = &cursors[i];
+ step->run(cursor, step);
+ }
+
+ /* iterate to next count/step: */
+ if (count < step->repeat) {
+ count++;
+ } else {
+ count = 0;
+ indx++;
+ }
+
+ usleep(1000 * step->msec);
}
- /* and lastly, setup timer for next step */
- setitimer(ITIMER_REAL, &itimer, NULL);
+ return NULL;
}
int cursor_init(int fd, uint32_t bo_handle, uint32_t crtc_id,
@@ -194,16 +195,16 @@ int cursor_init(int fd, uint32_t bo_handle, uint32_t
crtc_id,
int cursor_start(void)
{
- /* setup signal handler to update cursor: */
- signal(SIGALRM, run_step);
+ cursor_running = 1;
+ pthread_create(&cursor_thread, NULL, cursor_thread_func, NULL);
printf("starting cursor\n");
- run_step(SIGALRM);
return 0;
}
int cursor_stop(void)
{
- signal(SIGALRM, NULL);
+ cursor_running = 0;
+ pthread_join(cursor_thread, NULL);
printf("cursor stopped\n");
return 0;
}
--
2.1.0
[RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support
On Fri, Nov 21, 2014 at 09:27:04PM +0100, Thierry Reding wrote: > On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote: > > on vlv, if ipvr is installed, it need be manually unloaded before > > i915, otherwise user might run into use-after-free issue. > > Huh? That doesn't sound right. What exactly is it that's going wrong? > You should never have to do this. If you do you're almost certainly > doing something wrong in the kernel module. It's the hilarity called platform devices. Removing them is somewhat racy, so doing that upfront makes the entire thing a bit safer. The use after free is on the text, since grabbing a module refcount for the platform device doesn't work (it would pin the module forever). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v5 08/24] amdkfd: Add amdkfd skeleton driver
On 11/21/2014 12:24 PM, Paul Bolle wrote: > On Sat, 2014-11-08 at 20:37 +0200, Oded Gabbay wrote: >> This patch adds the amdkfd skeleton driver. The driver does nothing except >> define a /dev/kfd device. >> >> It returns -ENODEV on all amdkfd IOCTLs. >> >> v3: Move bool field to the end of structure, removed the pmc ioctls and added >> a meaningful error message for ioctl error. >> >> v5: >> >> Create a new folder drm/amd and move amdkfd from drm/radeon/ to drm/amd/ >> Remove scheduler_class from kfd_priv.h as it was never used >> Add skeleton implementation of the Get Version IOCTL >> >> Signed-off-by: Oded Gabbay > > It seems v6 of this patch is included in today's linux-next (ie, > next-20141121). > >> drivers/gpu/drm/Kconfig | 2 + >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/amd/amdkfd/Kconfig | 10 ++ >> drivers/gpu/drm/amd/amdkfd/Makefile | 9 ++ >> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 210 >> +++ >> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 130 +++ >> drivers/gpu/drm/amd/amdkfd/kfd_module.c | 101 +++ >> drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 81 >> 8 files changed, 544 insertions(+) >> [...] >> diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig >> b/drivers/gpu/drm/amd/amdkfd/Kconfig >> new file mode 100644 >> index 000..a2ae6d4 >> --- /dev/null >> +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig >> @@ -0,0 +1,10 @@ >> +# >> +# Heterogenous system architecture configuration >> +# >> + >> +config HSA_AMD >> +tristate "HSA kernel driver for AMD GPU devices" >> +depends on (DRM_RADEON || DRM_AMDGPU) && AMD_IOMMU_V2 && X86_64 > > There's currently no Kconfig symbol DRM_AMDGPU (nor anything similar). > Will that symbol be added in a future patch? > The DRM_AMDGPU symbol belongs to AMD's new Linux kernel graphic driver, called amdgpu. That driver is not yet upstreamed, so its symbol is not present in any Kconfig file. However, internally we work with that driver so that's why it appears in my patch. I can remove it if it violates some rule. I have no problem adding it back once amdgpu is upstreamed. Oded >> +default m >> +help >> + Enable this if you want to use HSA features on AMD GPU devices. > > > Paul Bolle >
[RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support
On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote: > on vlv, if ipvr is installed, it need be manually unloaded before > i915, otherwise user might run into use-after-free issue. Huh? That doesn't sound right. What exactly is it that's going wrong? You should never have to do this. If you do you're almost certainly doing something wrong in the kernel module. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/0a1aab0c/attachment.sig>
[PATCH v5 08/24] amdkfd: Add amdkfd skeleton driver
On Fri, Nov 21, 2014 at 09:34:45PM +0200, Oded Gabbay wrote: > The DRM_AMDGPU symbol belongs to AMD's new Linux kernel graphic > driver, called amdgpu. That driver is not yet upstreamed, so its > symbol is not present in any Kconfig file. However, internally we work > with that driver so that's why it appears in my patch. > > I can remove it if it violates some rule. Yes it does: no out-of-tree symbols. Please remove it. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[git pull] drm fixes
Hi Linus, just two radeon and two intel fixes, endian and regression fixes. Dave. The following changes since commit fc14f9c1272f62c3e8d01300f52467c0d9af50f9: Linux 3.18-rc5 (2014-11-16 16:36:20 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to a0fc608178a9b38a5f782331909fcc208b742a7b: Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2014-11-21 12:19:19 +1000) Alex Deucher (2): drm/radeon: disable native backlight control on pre-r6xx asics (v2) drm/radeon: fix endian swapping in vbios fetch for tdp table Daniel Vetter (2): drm/i915: drop WaSetupGtModeTdRowDispatch:snb drm/i915: Kick fbdev before vgacon Dave Airlie (2): Merge tag 'drm-intel-fixes-2014-11-19' of git://anongit.freedesktop.org/drm-intel into drm-fixes Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux into drm-fixes drivers/gpu/drm/i915/i915_dma.c | 10 ++ drivers/gpu/drm/i915/intel_pm.c | 5 - drivers/gpu/drm/radeon/r600_dpm.c| 2 +- drivers/gpu/drm/radeon/radeon_encoders.c | 3 +++ 4 files changed, 10 insertions(+), 10 deletions(-)
[PATCH] drm/vgem: implement virtual GEM
ajax: The consumer of this will be software renderers. We're working on one right now that will be using dma-bufs from userspace. Daniel: Thanks for your suggestions. I'll work on it and submit a v2. On Fri Nov 21 2014 at 6:02:45 AM Adam Jackson wrote: > On Thu, 2014-11-20 at 16:26 -0800, Zach Reizner wrote: > > This patch implements the virtual GEM driver with PRIME sharing which > > allows vgem to import a gem object from other drivers for the purpose > > of mmap-ing them to userspace. > > The reason I initially wanted this was to get zero-copy llvmpipe, since > (besides making GLX conformance impossible) the image transfer parts of > drisw are easily the biggest part of the runtime overhead. Is there a > userspace consumer of this anywhere? > > - ajax > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/5c52ecdf/attachment.html>
gma500_gfx black LVDS if VGA connected
[1.] gma500_gfx black LVDS if VGA connected [2.] bugs.launchpad.net/ubuntu/+source/linux/+bug/1393945 [3.] gma500_gfx lvds vga [4.] 3.18.0-031800rc5-generic
[Bug 85320] [RV630] GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #19 from Eugene --- This is quite strange cause my xorg log shows a lot of error messages. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/1b9dc304/attachment.html>
[PATCH] drm/locking: Allow NULL crtc in drm_modeset_legacy_acquire_ctx
On Fri, Nov 21, 2014 at 04:40:18PM +0100, Daniel Vetter wrote:
> I've missed checking this and so didn't notice that there's a NULL
> check missing. Since depending upon calling context the crtc might not
> even be there (disable-me-harder does happen around planes, especially
> in cleanup code) we need to dodge the oops and look at the global
> acquire ctx.
>
> Reported-by: "Jasper St. Pierre"
> Cc: "Jasper St. Pierre"
> Cc: Rob Clark
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_modeset_lock.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c
> b/drivers/gpu/drm/drm_modeset_lock.c
> index 474e4d12a2d8..93d28269e3bd 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -209,7 +209,7 @@ EXPORT_SYMBOL(drm_modeset_lock_crtc);
> struct drm_modeset_acquire_ctx *
> drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
> {
> - if (crtc->acquire_ctx)
> + if (crtc && crtc->acquire_ctx)
> return crtc->acquire_ctx;
>
> WARN_ON(!crtc->dev->mode_config.acquire_ctx);
^^
How's that going to work without the crtc?
> --
> 2.1.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
[PATCH 5/5] drm: Free atomic state during cleanup
On Fri, Nov 21, 2014 at 05:23:53PM +0100, Thierry Reding wrote: > From: Thierry Reding > > 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. > > Signed-off-by: Thierry Reding Patches 2, 4 & this one here are Reviewed-by: Daniel Vetter Cheers, Daniel > --- > drivers/gpu/drm/drm_crtc.c | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index de09c1ff0714..9f736417a95d 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -721,6 +721,10 @@ void drm_crtc_cleanup(struct drm_crtc *crtc) > drm_mode_object_put(dev, &crtc->base); > list_del(&crtc->head); > dev->mode_config.num_crtc--; > + > + WARN_ON(crtc->state && !crtc->funcs->atomic_destroy_state); > + if (crtc->state && crtc->funcs->atomic_destroy_state) > + crtc->funcs->atomic_destroy_state(crtc, crtc->state); > } > EXPORT_SYMBOL(drm_crtc_cleanup); > > @@ -918,6 +922,11 @@ void drm_connector_cleanup(struct drm_connector > *connector) > connector->name = NULL; > list_del(&connector->head); > dev->mode_config.num_connector--; > + > + WARN_ON(connector->state && !connector->funcs->atomic_destroy_state); > + if (connector->state && connector->funcs->atomic_destroy_state) > + connector->funcs->atomic_destroy_state(connector, > +connector->state); > } > EXPORT_SYMBOL(drm_connector_cleanup); > > @@ -1244,6 +1253,10 @@ void drm_plane_cleanup(struct drm_plane *plane) > if (plane->type == DRM_PLANE_TYPE_OVERLAY) > dev->mode_config.num_overlay_plane--; > drm_modeset_unlock_all(dev); > + > + WARN_ON(plane->state && !plane->funcs->atomic_destroy_state); > + if (plane->state && plane->funcs->atomic_destroy_state) > + plane->funcs->atomic_destroy_state(plane, plane->state); > } > EXPORT_SYMBOL(drm_plane_cleanup); > > -- > 2.1.3 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/5] drm/plane: Pass old state to ->atomic_update()
On Fri, Nov 21, 2014 at 05:23:49PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> 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.
>
> Signed-off-by: Thierry Reding
> ---
> Note that I based this patch on a local tree which has Daniel's Exynos
> prototype conversion, so the Exynos specific parts may not apply to
> anything else. I can respin if that's a problem.
>
> drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
> drivers/gpu/drm/drm_plane_helper.c| 2 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 3 ++-
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 3 ++-
> include/drm/drm_plane_helper.h| 3 ++-
> 5 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 690360038dc1..d55f4d0ce990 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1011,6 +1011,7 @@ void drm_atomic_helper_commit_planes(struct drm_device
> *dev,
> for (i = 0; i < nplanes; i++) {
> struct drm_plane_helper_funcs *funcs;
> struct drm_plane *plane = old_state->planes[i];
> + struct drm_plane_state *state = old_state->plane_states[i];
>
> if (!plane)
> continue;
> @@ -1020,7 +1021,8 @@ void drm_atomic_helper_commit_planes(struct drm_device
> *dev,
> if (!funcs || !funcs->atomic_update)
> continue;
>
> - funcs->atomic_update(plane);
> + /* NOTE: state is the old state here. */
Call the variable old_plane_state and remove the comment imo. Otherwise
Reviewed-by: Daniel Vetter
> + funcs->atomic_update(plane, state);
> }
>
> for (i = 0; i < ncrtcs; i++) {
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c
> index 2dd30518f9a2..aa399db5d36d 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -443,7 +443,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
> crtc_funcs[i]->atomic_begin(crtc[i]);
> }
>
> - plane_funcs->atomic_update(plane);
> + plane_funcs->atomic_update(plane, plane_state);
>
> for (i = 0; i < 2; i++) {
> if (crtc_funcs[i] && crtc_funcs[i]->atomic_flush)
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index c218f7f5a5e5..b903937204a3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -311,7 +311,8 @@ static int exynos_plane_atomic_check(struct drm_plane
> *plane,
> return 0;
> }
>
> -static void exynos_plane_atomic_update(struct drm_plane *plane)
> +static void exynos_plane_atomic_update(struct drm_plane *plane,
> +struct drm_plane_state *old_state)
> {
> struct exynos_plane *exynos_plane = to_exynos_plane(plane);
> int ret;
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> index 76d0a40c7138..1e5ebe83647d 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> @@ -107,7 +107,8 @@ static int mdp4_plane_atomic_check(struct drm_plane
> *plane,
> return 0;
> }
>
> -static void mdp4_plane_atomic_update(struct drm_plane *plane)
> +static void mdp4_plane_atomic_update(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> {
> struct drm_plane_state *state = plane->state;
> int ret;
> diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
> index 00ad3b3c5324..d3122cd0609b 100644
> --- a/include/drm/drm_plane_helper.h
> +++ b/include/drm/drm_plane_helper.h
> @@ -59,7 +59,8 @@ struct drm_plane_helper_funcs {
>
> int (*atomic_check)(struct drm_plane *plane,
> struct drm_plane_state *state);
> - void (*atomic_update)(struct drm_plane *plane);
> + void (*atomic_update)(struct drm_plane *plane,
> + struct drm_plane_state *old_state);
> };
>
> static inline void drm_plane_helper_add(struct drm_plane *plane,
> --
> 2.1.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 3/5] drm/plane: Add optional ->atomic_disable() callback
On Fri, Nov 21, 2014 at 05:23:51PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> In order to prevent drivers from having to perform the same checks over
> and over again, add an optional ->atomic_disable callback which the core
> calls under the right circumstances.
>
> Signed-off-by: Thierry Reding
One comment below, looks good otherwise.
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 13 -
> drivers/gpu/drm/drm_plane_helper.c | 9 -
> include/drm/drm_crtc.h | 24
> include/drm/drm_plane_helper.h | 3 +++
> 4 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index d55f4d0ce990..810818fe8fdf 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1017,8 +1017,19 @@ void drm_atomic_helper_commit_planes(struct drm_device
> *dev,
> continue;
>
> funcs = plane->helper_private;
> + if (!funcs)
> + continue;
> +
> + /*
> + * Special-case disabling the plane if drivers support it.
> + */
> + if (drm_plane_disabled(plane) && funcs->atomic_disable) {
> + /* NOTE: state is the old state here. */
> + funcs->atomic_disable(plane, state);
> + continue;
> + }
>
> - if (!funcs || !funcs->atomic_update)
> + if (!funcs->atomic_update)
> continue;
>
> /* NOTE: state is the old state here. */
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c
> index aa399db5d36d..881e0100fa49 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -443,7 +443,14 @@ int drm_plane_helper_commit(struct drm_plane *plane,
> crtc_funcs[i]->atomic_begin(crtc[i]);
> }
>
> - plane_funcs->atomic_update(plane, plane_state);
> + /*
> + * Drivers may optionally implement the ->atomic_disable callback, so
> + * special-case that here.
> + */
> + if (drm_plane_disabled(plane) && plane_funcs->atomic_disable)
> + plane_funcs->atomic_disable(plane, plane_state);
> + else
> + plane_funcs->atomic_update(plane, plane_state);
>
> for (i = 0; i < 2; i++) {
> if (crtc_funcs[i] && crtc_funcs[i]->atomic_flush)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 6da67dfcb6fc..7b8750e79383 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -795,6 +795,30 @@ struct drm_plane {
> struct drm_plane_state *state;
> };
>
> +/*
> + * drm_plane_disabled - check whether a plane is being disabled
> + * @plane: plane object
> + *
> + * Checks the atomic state of a plane to determine whether it's being
> disabled
> + * or not. This also WARNs if it detects an invalid state (both CRTC and FB
> + * need to either both be NULL or both be non-NULL).
> + *
> + * RETURNS:
> + * True if the plane is being disabled, false otherwise.
> + */
> +static inline bool drm_plane_disabled(struct drm_plane *plane)
> +{
> + /*
> + * When disabling a plane, CRTC and FB should always be NULL together.
> + * Anything else should be considered a bug in the atomic core, so we
> + * gently warn about it.
> + */
> + WARN_ON((plane->state->crtc == NULL && plane->state->fb != NULL) ||
> + (plane->state->crtc != NULL && plane->state->fb == NULL));
> +
> + return plane->state->crtc == NULL || plane->state->fb == NULL;
I think we should only detect disabling edges here so that multiple
disables (userspace or drm core might do stupid things) don't result in
multiple disable calls. So would amount to passing the old state and
changing the check to
return old_state->crtc && !plane->state->crtc;
Imo keeping the || here is redudant, the WARN_ON is good enough.
-Daniel
> +}
> +
> /**
> * struct drm_bridge_funcs - drm_bridge control functions
> * @mode_fixup: Try to fixup (or reject entirely) proposed mode for this
> bridge
> diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
> index 0f2230311aa8..680be61ef20a 100644
> --- a/include/drm/drm_plane_helper.h
> +++ b/include/drm/drm_plane_helper.h
> @@ -52,6 +52,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc
> *crtc,
> * @cleanup_fb: cleanup a framebuffer when it's no longer used by the plane
> * @atomic_check: check that a given atomic state is valid and can be applied
> * @atomic_update: apply an atomic state to the plane
> + * @atomic_disable: disable the plane
> *
> * The helper operations are called by the mid-layer CRTC helper.
> */
> @@ -65,6 +66,8 @@ struct drm_plane_helper_funcs {
> struct drm_plane_state *state);
>
[PATCH] drm/locking: Allow NULL crtc in drm_modeset_legacy_acquire_ctx
I've missed checking this and so didn't notice that there's a NULL
check missing. Since depending upon calling context the crtc might not
even be there (disable-me-harder does happen around planes, especially
in cleanup code) we need to dodge the oops and look at the global
acquire ctx.
v2: Actually fix the oops for real and don't just move it two lines
down. That requires that we pass a drm_device pointer for the cases
where crtc could be NULL.
Reported-by: "Jasper St. Pierre"
Cc: "Jasper St. Pierre"
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 12
drivers/gpu/drm/drm_modeset_lock.c | 12
include/drm/drm_modeset_lock.h | 3 ++-
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ca839bd9bb0d..32c34b5d5f68 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1171,7 +1171,8 @@ int drm_atomic_helper_update_plane(struct drm_plane
*plane,
if (!state)
return -ENOMEM;
- state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+ state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc,
+ plane->dev);
retry:
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
@@ -1239,7 +1240,8 @@ int drm_atomic_helper_disable_plane(struct drm_plane
*plane)
if (!state)
return -ENOMEM;
- state->acquire_ctx = drm_modeset_legacy_acquire_ctx(plane->crtc);
+ state->acquire_ctx = drm_modeset_legacy_acquire_ctx(plane->crtc,
+ plane->dev);
retry:
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
@@ -1391,7 +1393,8 @@ int drm_atomic_helper_set_config(struct drm_mode_set *set)
if (!state)
return -ENOMEM;
- state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+ state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc,
+ crtc->dev);
retry:
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state)) {
@@ -1676,7 +1679,8 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
if (!state)
return -ENOMEM;
- state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+ state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc,
+ crtc->dev);
retry:
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state)) {
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 474e4d12a2d8..655958d4f23e 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -200,21 +200,25 @@ EXPORT_SYMBOL(drm_modeset_lock_crtc);
/**
* drm_modeset_legacy_acquire_ctx - find acquire ctx for legacy ioctls
* @crtc: drm crtc
+ * @dev: device
*
* Legacy ioctl operations like cursor updates or page flips only have per-crtc
* locking, and store the acquire ctx in the corresponding crtc. All other
* legacy operations take all locks and use a global acquire context. This
* function grabs the right one.
+ *
+ * Note that either @crtc or @dev can be NULL, but not both.
*/
struct drm_modeset_acquire_ctx *
-drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
+drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc,
+ struct drm_device *dev)
{
- if (crtc->acquire_ctx)
+ if (crtc && crtc->acquire_ctx)
return crtc->acquire_ctx;
- WARN_ON(!crtc->dev->mode_config.acquire_ctx);
+ WARN_ON(!dev->mode_config.acquire_ctx);
- return crtc->dev->mode_config.acquire_ctx;
+ return dev->mode_config.acquire_ctx;
}
EXPORT_SYMBOL(drm_modeset_legacy_acquire_ctx);
diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
index 28931a23d96c..cdbfd822e52f 100644
--- a/include/drm/drm_modeset_lock.h
+++ b/include/drm/drm_modeset_lock.h
@@ -135,7 +135,8 @@ void drm_modeset_lock_crtc(struct drm_crtc *crtc);
void drm_modeset_unlock_crtc(struct drm_crtc *crtc);
void drm_warn_on_modeset_not_all_locked(struct drm_device *dev);
struct drm_modeset_acquire_ctx *
-drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc);
+drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc,
+ struct drm_device *dev);
int drm_modeset_lock_all_crtcs(struct drm_device *dev,
struct drm_modeset_acquire_ctx *ctx);
--
2.1.1
[Bug 86432] llvm Unreal Elemental rendering regression
https://bugs.freedesktop.org/show_bug.cgi?id=86432 --- Comment #14 from Andy Furniss --- (In reply to Marek Olšák from comment #13) > Mesa commit 645b471d619b654d3bacfa8598f759833e08db4e should fix this. Yes, it works with or without patches on current mesa head. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/1e248912/attachment.html>
[RFC] drm: add plane iterator macros
On Fri, Nov 21, 2014 at 07:39:11AM -0500, Rob Clark wrote:
> Inspired in part by some cute iterator macros I noticed in i915. I
> currently have these in drm/msm, but seems like they should be useful
> for others. Quite possibly other iterators would be useful to add for
> other drivers.
>
> Signed-off-by: Rob Clark
> ---
> NOTE: to actually merge this, depending on the order this is merged
> vs drm/msm/mdp5 atomic support, these would have to be removed from
> msm_kms.h.
>
> include/drm/drm_crtc.h | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index bc1cc3c..5ea46ec 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -773,6 +773,34 @@ struct drm_plane {
> struct drm_plane_state *state;
> };
>
> +/* iterate over the planes *currently* attached to a crtc, useful
> + * to apply current state to hw:
> + */
> +#define for_each_plane_on_crtc(_crtc, _plane) \
> + list_for_each_entry((_plane), &(_crtc)->dev->mode_config.plane_list,
> head) \
> + if ((_plane)->state->crtc == (_crtc))
Perhaps throw in a drm_ prefix (for this and the below iterator). Or
maybe rename to something like:
drm_crtc_for_each_plane()
to make the argument list more intuitive?
> +static inline bool
> +__plane_will_be_attached_to_crtc(struct drm_atomic_state *state,
> + struct drm_plane *plane, struct drm_crtc *crtc)
> +{
> + int idx = drm_plane_index(plane);
> +
> + /* if plane is modified in incoming state, use the new state: */
> + if (state->plane_states[idx])
> + return state->plane_states[idx]->crtc == crtc;
> +
> + /* otherwise, current state: */
> + return plane->state->crtc == crtc;
> +}
Maybe drm_crtc_plane_pending(crtc, state, plane) for somewhat more
cohesive naming?
> +
> +/* iterate over the planes that *will be* attached to a crtc,
> + * useful for ->atomic_check() operations:
> + */
> +#define for_each_pending_plane_on_crtc(_state, _crtc, _plane) \
> + list_for_each_entry((_plane), &(_crtc)->dev->mode_config.plane_list,
> head) \
> + if (__plane_will_be_attached_to_crtc((_state), (_plane),
> (_crtc)))
Similarily as for the above, perhaps:
drm_crtc_for_each_pending_plane(_crtc, _state, _plane)
might be more intuitive.
Irrespective of the bike-shedding and with Daniel's comments addressed,
this is:
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/352435c6/attachment.sig>
[PATCH 5/5] drm: Free atomic state during cleanup
From: Thierry Reding 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. Signed-off-by: Thierry Reding --- drivers/gpu/drm/drm_crtc.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index de09c1ff0714..9f736417a95d 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -721,6 +721,10 @@ void drm_crtc_cleanup(struct drm_crtc *crtc) drm_mode_object_put(dev, &crtc->base); list_del(&crtc->head); dev->mode_config.num_crtc--; + + WARN_ON(crtc->state && !crtc->funcs->atomic_destroy_state); + if (crtc->state && crtc->funcs->atomic_destroy_state) + crtc->funcs->atomic_destroy_state(crtc, crtc->state); } EXPORT_SYMBOL(drm_crtc_cleanup); @@ -918,6 +922,11 @@ void drm_connector_cleanup(struct drm_connector *connector) connector->name = NULL; list_del(&connector->head); dev->mode_config.num_connector--; + + WARN_ON(connector->state && !connector->funcs->atomic_destroy_state); + if (connector->state && connector->funcs->atomic_destroy_state) + connector->funcs->atomic_destroy_state(connector, + connector->state); } EXPORT_SYMBOL(drm_connector_cleanup); @@ -1244,6 +1253,10 @@ void drm_plane_cleanup(struct drm_plane *plane) if (plane->type == DRM_PLANE_TYPE_OVERLAY) dev->mode_config.num_overlay_plane--; drm_modeset_unlock_all(dev); + + WARN_ON(plane->state && !plane->funcs->atomic_destroy_state); + if (plane->state && plane->funcs->atomic_destroy_state) + plane->funcs->atomic_destroy_state(plane, plane->state); } EXPORT_SYMBOL(drm_plane_cleanup); -- 2.1.3
[PATCH 4/5] drm: Make drm_atomic_helper.h standalone includible
From: Thierry Reding 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. Signed-off-by: Thierry Reding --- include/drm/drm_atomic_helper.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h index 64b4e91b93bc..70a83197ef66 100644 --- a/include/drm/drm_atomic_helper.h +++ b/include/drm/drm_atomic_helper.h @@ -28,6 +28,8 @@ #ifndef DRM_ATOMIC_HELPER_H_ #define DRM_ATOMIC_HELPER_H_ +#include + int drm_atomic_helper_check(struct drm_device *dev, struct drm_atomic_state *state); int drm_atomic_helper_commit(struct drm_device *dev, -- 2.1.3
[PATCH 3/5] drm/plane: Add optional ->atomic_disable() callback
From: Thierry Reding
In order to prevent drivers from having to perform the same checks over
and over again, add an optional ->atomic_disable callback which the core
calls under the right circumstances.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic_helper.c | 13 -
drivers/gpu/drm/drm_plane_helper.c | 9 -
include/drm/drm_crtc.h | 24
include/drm/drm_plane_helper.h | 3 +++
4 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d55f4d0ce990..810818fe8fdf 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1017,8 +1017,19 @@ void drm_atomic_helper_commit_planes(struct drm_device
*dev,
continue;
funcs = plane->helper_private;
+ if (!funcs)
+ continue;
+
+ /*
+* Special-case disabling the plane if drivers support it.
+*/
+ if (drm_plane_disabled(plane) && funcs->atomic_disable) {
+ /* NOTE: state is the old state here. */
+ funcs->atomic_disable(plane, state);
+ continue;
+ }
- if (!funcs || !funcs->atomic_update)
+ if (!funcs->atomic_update)
continue;
/* NOTE: state is the old state here. */
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index aa399db5d36d..881e0100fa49 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -443,7 +443,14 @@ int drm_plane_helper_commit(struct drm_plane *plane,
crtc_funcs[i]->atomic_begin(crtc[i]);
}
- plane_funcs->atomic_update(plane, plane_state);
+ /*
+* Drivers may optionally implement the ->atomic_disable callback, so
+* special-case that here.
+*/
+ if (drm_plane_disabled(plane) && plane_funcs->atomic_disable)
+ plane_funcs->atomic_disable(plane, plane_state);
+ else
+ plane_funcs->atomic_update(plane, plane_state);
for (i = 0; i < 2; i++) {
if (crtc_funcs[i] && crtc_funcs[i]->atomic_flush)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6da67dfcb6fc..7b8750e79383 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -795,6 +795,30 @@ struct drm_plane {
struct drm_plane_state *state;
};
+/*
+ * drm_plane_disabled - check whether a plane is being disabled
+ * @plane: plane object
+ *
+ * Checks the atomic state of a plane to determine whether it's being disabled
+ * or not. This also WARNs if it detects an invalid state (both CRTC and FB
+ * need to either both be NULL or both be non-NULL).
+ *
+ * RETURNS:
+ * True if the plane is being disabled, false otherwise.
+ */
+static inline bool drm_plane_disabled(struct drm_plane *plane)
+{
+ /*
+* When disabling a plane, CRTC and FB should always be NULL together.
+* Anything else should be considered a bug in the atomic core, so we
+* gently warn about it.
+*/
+ WARN_ON((plane->state->crtc == NULL && plane->state->fb != NULL) ||
+ (plane->state->crtc != NULL && plane->state->fb == NULL));
+
+ return plane->state->crtc == NULL || plane->state->fb == NULL;
+}
+
/**
* struct drm_bridge_funcs - drm_bridge control functions
* @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
index 0f2230311aa8..680be61ef20a 100644
--- a/include/drm/drm_plane_helper.h
+++ b/include/drm/drm_plane_helper.h
@@ -52,6 +52,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc
*crtc,
* @cleanup_fb: cleanup a framebuffer when it's no longer used by the plane
* @atomic_check: check that a given atomic state is valid and can be applied
* @atomic_update: apply an atomic state to the plane
+ * @atomic_disable: disable the plane
*
* The helper operations are called by the mid-layer CRTC helper.
*/
@@ -65,6 +66,8 @@ struct drm_plane_helper_funcs {
struct drm_plane_state *state);
void (*atomic_update)(struct drm_plane *plane,
struct drm_plane_state *old_state);
+ void (*atomic_disable)(struct drm_plane *plane,
+ struct drm_plane_state *old_state);
};
static inline void drm_plane_helper_add(struct drm_plane *plane,
--
2.1.3
[PATCH 2/5] drm/plane: Add missing kerneldoc
From: Thierry Reding The plane helpers aren't pulled into the DocBook yet, so these weren't noticed. Signed-off-by: Thierry Reding --- include/drm/drm_plane_helper.h | 4 1 file changed, 4 insertions(+) diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h index d3122cd0609b..0f2230311aa8 100644 --- a/include/drm/drm_plane_helper.h +++ b/include/drm/drm_plane_helper.h @@ -48,6 +48,10 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc, /** * drm_plane_helper_funcs - helper operations for CRTCs + * @prepare_fb: prepare a framebuffer for use by the plane + * @cleanup_fb: cleanup a framebuffer when it's no longer used by the plane + * @atomic_check: check that a given atomic state is valid and can be applied + * @atomic_update: apply an atomic state to the plane * * The helper operations are called by the mid-layer CRTC helper. */ -- 2.1.3
[PATCH 1/5] drm/plane: Pass old state to ->atomic_update()
From: Thierry Reding
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.
Signed-off-by: Thierry Reding
---
Note that I based this patch on a local tree which has Daniel's Exynos
prototype conversion, so the Exynos specific parts may not apply to
anything else. I can respin if that's a problem.
drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
drivers/gpu/drm/drm_plane_helper.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 3 ++-
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 3 ++-
include/drm/drm_plane_helper.h| 3 ++-
5 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 690360038dc1..d55f4d0ce990 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1011,6 +1011,7 @@ void drm_atomic_helper_commit_planes(struct drm_device
*dev,
for (i = 0; i < nplanes; i++) {
struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = old_state->planes[i];
+ struct drm_plane_state *state = old_state->plane_states[i];
if (!plane)
continue;
@@ -1020,7 +1021,8 @@ void drm_atomic_helper_commit_planes(struct drm_device
*dev,
if (!funcs || !funcs->atomic_update)
continue;
- funcs->atomic_update(plane);
+ /* NOTE: state is the old state here. */
+ funcs->atomic_update(plane, state);
}
for (i = 0; i < ncrtcs; i++) {
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index 2dd30518f9a2..aa399db5d36d 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -443,7 +443,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
crtc_funcs[i]->atomic_begin(crtc[i]);
}
- plane_funcs->atomic_update(plane);
+ plane_funcs->atomic_update(plane, plane_state);
for (i = 0; i < 2; i++) {
if (crtc_funcs[i] && crtc_funcs[i]->atomic_flush)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index c218f7f5a5e5..b903937204a3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -311,7 +311,8 @@ static int exynos_plane_atomic_check(struct drm_plane
*plane,
return 0;
}
-static void exynos_plane_atomic_update(struct drm_plane *plane)
+static void exynos_plane_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
{
struct exynos_plane *exynos_plane = to_exynos_plane(plane);
int ret;
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
index 76d0a40c7138..1e5ebe83647d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
@@ -107,7 +107,8 @@ static int mdp4_plane_atomic_check(struct drm_plane *plane,
return 0;
}
-static void mdp4_plane_atomic_update(struct drm_plane *plane)
+static void mdp4_plane_atomic_update(struct drm_plane *plane,
+struct drm_plane_state *old_state)
{
struct drm_plane_state *state = plane->state;
int ret;
diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
index 00ad3b3c5324..d3122cd0609b 100644
--- a/include/drm/drm_plane_helper.h
+++ b/include/drm/drm_plane_helper.h
@@ -59,7 +59,8 @@ struct drm_plane_helper_funcs {
int (*atomic_check)(struct drm_plane *plane,
struct drm_plane_state *state);
- void (*atomic_update)(struct drm_plane *plane);
+ void (*atomic_update)(struct drm_plane *plane,
+ struct drm_plane_state *old_state);
};
static inline void drm_plane_helper_add(struct drm_plane *plane,
--
2.1.3
[Bug 85320] [RV630] GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #18 from Daniele --- Created attachment 109807 --> https://bugs.freedesktop.org/attachment.cgi?id=109807&action=edit dmesg log, gpu hangs -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/4094f6d8/attachment.html>
[Bug 85320] [RV630] GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #17 from Daniele --- I see the same happening here with a HD4200 (RS880) GPU. I tried with: - kernel 3.18rc3 - latest radeon ucode firmware files from the 23rd of August - updated mesa, xserver and libs from the oibaf ubuntu ppa I observed the same behavior: video starts well for a second, then the image freeze (but mouse cursor is still alive) and I can't do anything, not even switching to another vt. After a while the screen becomes black. In the meantime I can hear the sound of the video correctly, and indeed if I log in with ssh from another pc everything is working well; still xserver doesn't work until a reboot is performed. I attach a piece of the dmesg log taken from the ssh session right after the video was played where the GPU hang is reported. Xorg doesn't log any error. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/61412e1a/attachment-0001.html>
[PATCH] drm/locking: Allow NULL crtc in drm_modeset_legacy_acquire_ctx
I've missed checking this and so didn't notice that there's a NULL
check missing. Since depending upon calling context the crtc might not
even be there (disable-me-harder does happen around planes, especially
in cleanup code) we need to dodge the oops and look at the global
acquire ctx.
Reported-by: "Jasper St. Pierre"
Cc: "Jasper St. Pierre"
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 474e4d12a2d8..93d28269e3bd 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -209,7 +209,7 @@ EXPORT_SYMBOL(drm_modeset_lock_crtc);
struct drm_modeset_acquire_ctx *
drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
{
- if (crtc->acquire_ctx)
+ if (crtc && crtc->acquire_ctx)
return crtc->acquire_ctx;
WARN_ON(!crtc->dev->mode_config.acquire_ctx);
--
2.1.1
[PATCH] drivers:gpu:qlx: Change incorrect return value of EINVAL to ENODEV in qxl_drv.c
Fixes not returning correct error code value in qxl_drv.c for the function,
qxl_pci_probe as this is a error with the device rather then an incorrect
value as stated by the DRM_ERROR statement above the return if this function
returns a error.
Signed-off-by: Nicholas Krause
---
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 1d9b80c..bbe2a34 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -65,7 +65,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (pdev->revision < 4) {
DRM_ERROR("qxl too old, doesn't support client_monitors_config,"
" use xf86-video-qxl in user mode");
- return -EINVAL; /* TODO: ENODEV ? */
+ return -ENODEV;
}
return drm_get_pci_dev(pdev, ent, &qxl_driver);
}
--
1.9.1
[RFC] drm: add plane iterator macros
On Fri, Nov 21, 2014 at 07:39:11AM -0500, Rob Clark wrote:
> Inspired in part by some cute iterator macros I noticed in i915. I
> currently have these in drm/msm, but seems like they should be useful
> for others. Quite possibly other iterators would be useful to add for
> other drivers.
>
> Signed-off-by: Rob Clark
Since they are both atomic specific perhaps better to put them into
drm_atomic.h? And kerneldoc please ;-)
With that fixed this is Reviewed-by: Daniel Vetter
> ---
> NOTE: to actually merge this, depending on the order this is merged
> vs drm/msm/mdp5 atomic support, these would have to be removed from
> msm_kms.h.
>
> include/drm/drm_crtc.h | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index bc1cc3c..5ea46ec 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -773,6 +773,34 @@ struct drm_plane {
> struct drm_plane_state *state;
> };
>
> +/* iterate over the planes *currently* attached to a crtc, useful
> + * to apply current state to hw:
> + */
> +#define for_each_plane_on_crtc(_crtc, _plane) \
> + list_for_each_entry((_plane), &(_crtc)->dev->mode_config.plane_list,
> head) \
> + if ((_plane)->state->crtc == (_crtc))
> +
> +static inline bool
> +__plane_will_be_attached_to_crtc(struct drm_atomic_state *state,
> + struct drm_plane *plane, struct drm_crtc *crtc)
> +{
> + int idx = drm_plane_index(plane);
> +
> + /* if plane is modified in incoming state, use the new state: */
> + if (state->plane_states[idx])
> + return state->plane_states[idx]->crtc == crtc;
> +
> + /* otherwise, current state: */
> + return plane->state->crtc == crtc;
> +}
> +
> +/* iterate over the planes that *will be* attached to a crtc,
> + * useful for ->atomic_check() operations:
> + */
> +#define for_each_pending_plane_on_crtc(_state, _crtc, _plane) \
> + list_for_each_entry((_plane), &(_crtc)->dev->mode_config.plane_list,
> head) \
> + if (__plane_will_be_attached_to_crtc((_state), (_plane),
> (_crtc)))
> +
> /**
> * struct drm_bridge_funcs - drm_bridge control functions
> * @mode_fixup: Try to fixup (or reject entirely) proposed mode for this
> bridge
> --
> 1.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm_atomic_helper: Copy/paste fix for calling already disabled planes
On Fri, Nov 21, 2014 at 07:17:48AM -0500, Rob Clark wrote:
> On Fri, Nov 21, 2014 at 3:31 AM, Daniel Vetter wrote:
> > On Thu, Nov 20, 2014 at 07:59:15PM -0800, Jasper St. Pierre wrote:
> >> This code was in drm_plane_helper, but missing from drm_atomic_helper,
> >> causing various crashes when the plane was already disabled. Just copy
> >> over the quick return there to prevent a crash.
> >>
> >> Signed-off-by: Jasper St. Pierre
> >> Reviewed-by: Rob Clark
> >> Cc: Daniel Vetter
> >> ---
> >> drivers/gpu/drm/drm_atomic_helper.c | 5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index fad2b93..d96dac3 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -1246,6 +1246,11 @@ int drm_atomic_helper_disable_plane(struct
> >> drm_plane *plane)
> >> struct drm_plane_state *plane_state;
> >> int ret = 0;
> >>
> >> + /* crtc helpers love to call disable functions for already disabled
> >> hw
> >> + * functions. So cope with that. */
> >
> > Comment here is misleading since this isn't called by the crtc helpers but
> > directly by the drm core code to handle the setplane ioctl.
> >
> > Now the real problem with this is that it's at the wrong spot. If we
> > really need to filter this then it should be done in the atomic_commit
> > function as a noop and not here. This is just the legacy ->disable_plane
> > entry hook, userspace could still throw multiple disable plane calls at
> > the driver. And they would get past this check.
> >
> > As-is it's actually a design feature of the atomic plane helpers that they
> > don't filter out any no-op updates, but just pass the new state into the
> > ->atomic_update hook (through the plane->state pointer). We could extend
> > that (Thierry is iirc working ona an ->atomic_disable callback), and then
> > it would make sense to have some filtering in the helpers. But if we add
> > that it must be done in drm_atomic_helper_commit_planes not here.
>
> I guess I'm (a) not entirely sure what the point of a no-op disable
> is, and (b) quite sure how you plane to make a
> 'drm_modeset_legacy_acquire_ctx(plane->crtc)' work if plane->crtc is
> NULL..
For a) atm atomic helpers just don't filter that out, and imo the core
should (since it's really tricky to figure out whether userspace has done
an elaborate noop ioctl when there's driver-specific properties and maybe
some autodetection involved).
For b) the commit message completely failed to mention the Oops. The fix
for that is
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 474e4d12a2d8..93d28269e3bd 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -209,7 +209,7 @@ EXPORT_SYMBOL(drm_modeset_lock_crtc);
struct drm_modeset_acquire_ctx *
drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
{
- if (crtc->acquire_ctx)
+ if (crtc && crtc->acquire_ctx)
return crtc->acquire_ctx;
WARN_ON(!crtc->dev->mode_config.acquire_ctx);
I somehow missed that implication of the "pick crtc acquire context or if
that's not there the global one".
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
3.18-rc regression: drm/nouveau: use shared fences for readable objects
On Thu, Nov 20, 2014 at 12:53 AM, Maarten Lankhorst wrote: > Op 20-11-14 om 05:06 schreef Michael Marineau: >> On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst >> wrote: >>> Hey, >>> >>> On 19-11-14 07:43, Michael Marineau wrote: On 3.18-rc kernel's I have been intermittently experiencing GPU lockups shortly after startup, accompanied with one or both of the following errors: nouveau E[ PFIFO][:01:00.0] read fault at 0x000734a000 [PTE] from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown] nouveau E[ DRM] GPU lockup - switching to software fbcon I was able to trace the issue with bisect to commit 809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared fences for readable objects". The lockups appear to have cleared up since reverting that and a few related followup commits: 809e9447: "drm/nouveau: use shared fences for readable objects" 055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1" e3be4c23: "drm/nouveau: specify if interruptible wait is desired in nouveau_fence_sync" 15a996bb: "drm/nouveau: assign fence_chan->name correctly" >>> Weird. I'm not sure yet what causes it. >>> >>> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect&id=86be4f216bbb9ea3339843a5658d4c21162c7ee2 >> Building a kernel from that commit gives me an entirely new behavior: >> X hangs for at least 10-20 seconds at a time with brief moments of >> responsiveness before hanging again while gitk on the kernel repo >> loads. Otherwise the system is responsive. The head of that >> fixed-fences-for-bisect branch (1c6aafb5) which is the "use shared >> fences for readable objects" commit I originally bisected to does >> feature the complete lockups I was seeing before. > Ok for the sake of argument lets just assume they're separate bugs, and we > should look at xorg > hanging first. > > Is there anything in the dmesg when the hanging happens? > > And it's probably 15 seconds, if it's called through nouveau_fence_wait. > > Try changing else if (!ret) to else if (WARN_ON(!ret)) in that function, and > see if you get some dmesg spam. :) Adding the WARN_ON to 86be4f21 repots the following: [ 1188.676073] [ cut here ] [ 1188.676161] WARNING: CPU: 1 PID: 474 at drivers/gpu/drm/nouveau/nouveau_fence.c:359 nouveau_fence_wait.part.9+0x33/0x40 [nouveau]() [ 1188.676166] Modules linked in: rndis_host cdc_ether usbnet mii bnep ecb btusb bluetooth rfkill bridge stp llc hid_generic usb_storage joydev mousedev hid_apple usbhid bcm5974 nls_iso8859_1 nls_cp437 vfat fat nouveau snd_hda_codec_hdmi coretemp x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm iTCO_wdt crct10dif_pclmul iTCO_vendor_support crc32c_intel evdev aesni_intel mac_hid aes_x86_64 lrw glue_helper ablk_helper applesmc snd_hda_codec_cirrus cryptd input_polldev snd_hda_codec_generic mxm_wmi led_class wmi microcode hwmon snd_hda_intel ttm snd_hda_controller lpc_ich i2c_i801 mfd_core snd_hda_codec i2c_algo_bit snd_hwdep drm_kms_helper snd_pcm sbs drm apple_gmux i2ccore snd_timer snd agpgart mei_me soundcore sbshc mei video xhci_hcd usbcore usb_common apple_bl button battery ac efivars autofs4 [ 1188.676300] efivarfs [ 1188.676308] CPU: 1 PID: 474 Comm: Xorg Tainted: GW 3.17.0-rc2-nvtest+ #147 [ 1188.676313] Hardware name: Apple Inc. MacBookPro11,3/Mac-2BD1B31983FE1663, BIOS MBP112.88Z.0138.B11.1408291503 08/29/2014 [ 1188.676316] 0009 88045daebce8 814f0c09 [ 1188.676325] 88045daebd20 8104ea5d 88006a6c1468 fff0 [ 1188.676333] 88006a6c1000 88045daebd30 [ 1188.676341] Call Trace: [ 1188.676356] [] dump_stack+0x4d/0x66 [ 1188.676369] [] warn_slowpath_common+0x7d/0xa0 [ 1188.676377] [] warn_slowpath_null+0x1a/0x20 [ 1188.676439] [] nouveau_fence_wait.part.9+0x33/0x40 [nouveau] [ 1188.676496] [] nouveau_fence_wait+0x16/0x30 [nouveau] [ 1188.676552] [] nouveau_gem_ioctl_cpu_prep+0xef/0x1f0 [nouveau] [ 1188.676578] [] drm_ioctl+0x1ec/0x660 [drm] [ 1188.676590] [] ? _raw_spin_unlock_irqrestore+0x36/0x70 [ 1188.676600] [] ? trace_hardirqs_on+0xd/0x10 [ 1188.676655] [] nouveau_drm_ioctl+0x54/0xc0 [nouveau] [ 1188.676663] [] do_vfs_ioctl+0x300/0x520 [ 1188.676671] [] ? sysret_check+0x22/0x5d [ 1188.676677] [] SyS_ioctl+0x41/0x80 [ 1188.676683] [] system_call_fastpath+0x16/0x1b [ 1188.676688] ---[ end trace 6f7a510865b4674f ]--- Here are the fence events that fired during that particular fence_wait: Xorg 474 [004] 1173.667645: fence:fence_wait_start: driver=nouveau timeline=Xorg[474] context=2 seqno=56910 Xorg 474 [004] 1173.667647: fence:fence_enable_signal: driver=nouveau timeline=Xorg[474] context=2 seqno=56910 swapper 0 [007] 1173.667688: fence:fence_signaled: driver=nouveau timeline=Xorg[474] context=2 seqno=56900 swapper 0 [007] 1173.6
[pull] drm/msm: msm-next for 3.19 (part 2)
2014-11-21 16:10 GMT-05:00 Rob Clark : > Hi Dave, > > 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 s/plane/plan/ ... I guess I've been doing too much kms! > atomic-fixes pull request so I agreed to tack them on to mine) > > I didn't have time to review the eDP patches, so those will wait until > the next time. > > The following changes since commit ed1e8777a56f3523712506d608a29f57ed37b613: > > Merge branch 'drm-next-3.19' of > git://people.freedesktop.org/~agd5f/linux into drm-next (2014-11-21 > 12:17:43 +1000) > > are available in the git repository at: > > > git://people.freedesktop.org/~robclark/linux msm-next > > for you to fetch changes up to 46df9adb2e7709e56ab8aacaff2fc997a6d17239: > > drm/atomic: shutdown *current* encoder (2014-11-21 16:06:15 -0500) > > > Rob Clark (11): > drm/msm/mdp5: use irqdomains > drm/msm/hdmi: remove useless kref > drm/msm/mdp5: set rate before enabling clk > drm/msm/mdp5: don't use void * for opaque types > drm/msm/mdp5: remove global mdp5_ctl_mgr > drm/msm: atomic fixes > drm/msm/mdp5: atomic > drm/msm/mdp5: dpms(OFF) cleanups > drm/msm/mdp4: fix mixer setup for multi-crtc + planes > drm/atomic: check mode_changed *after* atomic_check > drm/atomic: shutdown *current* encoder > > Stephane Viau (4): > drm/msm/mdp5: get the core clock rate from MDP5 config > drm/msm/mdp5: make SMP module dynamically configurable > drm/msm/mdp5: introduce mdp5_cfg module > drm/msm: add multiple CRTC and overlay support > > drivers/gpu/drm/drm_atomic_helper.c | 17 +- > drivers/gpu/drm/msm/Makefile| 2 + > drivers/gpu/drm/msm/hdmi/hdmi.c | 57 ++-- > drivers/gpu/drm/msm/hdmi/hdmi.h | 17 -- > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 3 +- > drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 4 +- > drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c| 70 +++-- > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 7 - > drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 207 + > drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 91 ++ > drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 430 > ++-- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 322 + > drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 122 > drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 24 ++ > drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 94 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 262 +++-- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 131 +++-- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 327 + > drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 241 +--- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h | 23 +- > drivers/gpu/drm/msm/msm_atomic.c| 2 +- > drivers/gpu/drm/msm/msm_drv.h | 1 - > drivers/gpu/drm/msm/msm_fb.c| 2 + > drivers/gpu/drm/msm/msm_kms.h | 20 +- > 24 files changed, 1737 insertions(+), 739 deletions(-) > create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c > create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h > create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c > create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h
[pull] drm/msm: msm-next for 3.19 (part 2)
Hi Dave, 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) I didn't have time to review the eDP patches, so those will wait until the next time. The following changes since commit ed1e8777a56f3523712506d608a29f57ed37b613: Merge branch 'drm-next-3.19' of git://people.freedesktop.org/~agd5f/linux into drm-next (2014-11-21 12:17:43 +1000) are available in the git repository at: git://people.freedesktop.org/~robclark/linux msm-next for you to fetch changes up to 46df9adb2e7709e56ab8aacaff2fc997a6d17239: drm/atomic: shutdown *current* encoder (2014-11-21 16:06:15 -0500) Rob Clark (11): drm/msm/mdp5: use irqdomains drm/msm/hdmi: remove useless kref drm/msm/mdp5: set rate before enabling clk drm/msm/mdp5: don't use void * for opaque types drm/msm/mdp5: remove global mdp5_ctl_mgr drm/msm: atomic fixes drm/msm/mdp5: atomic drm/msm/mdp5: dpms(OFF) cleanups drm/msm/mdp4: fix mixer setup for multi-crtc + planes drm/atomic: check mode_changed *after* atomic_check drm/atomic: shutdown *current* encoder Stephane Viau (4): drm/msm/mdp5: get the core clock rate from MDP5 config drm/msm/mdp5: make SMP module dynamically configurable drm/msm/mdp5: introduce mdp5_cfg module drm/msm: add multiple CRTC and overlay support drivers/gpu/drm/drm_atomic_helper.c | 17 +- drivers/gpu/drm/msm/Makefile| 2 + drivers/gpu/drm/msm/hdmi/hdmi.c | 57 ++-- drivers/gpu/drm/msm/hdmi/hdmi.h | 17 -- drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 3 +- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 4 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c| 70 +++-- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 7 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 207 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 91 ++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 430 ++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 322 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 122 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 24 ++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 94 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 262 +++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 131 +++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 327 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 241 +--- drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h | 23 +- drivers/gpu/drm/msm/msm_atomic.c| 2 +- drivers/gpu/drm/msm/msm_drv.h | 1 - drivers/gpu/drm/msm/msm_fb.c| 2 + drivers/gpu/drm/msm/msm_kms.h | 20 +- 24 files changed, 1737 insertions(+), 739 deletions(-) create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h
[PATCH] drm/gem: Warn on illegal use of the dumb buffer interface v2
On 11/21/2014 03:51 PM, Chris Wilson wrote: > On Fri, Nov 21, 2014 at 03:48:33PM +0100, Thomas Hellstrom wrote: >> On 11/21/2014 03:14 PM, Chris Wilson wrote: >>> On Thu, Nov 20, 2014 at 09:56:25AM +0100, Thomas Hellstrom wrote: It happens on occasion that developers of generic user-space applications abuse the dumb buffer API to get hold of drm buffers that they can both mmap() and use for GPU acceleration, using the assumptions that dumb buffers and buffers available for GPU are a) The same type and can be aribtrarily type-casted. b) fully coherent. >>> Both (a) and (b) are true for intel and it turns out to be a requirement >>> for smooth transitions from the boot splash screens into X, and relied >>> upon by userspace. >>> -Chris >>> >> So when you say relied upon by user-space, do you mean generic >> user-space or driver-specific user-space? >> >> With that, I mean what component is responsible for deciding that the >> dumb buffer can be accelerated? The Intel xorg driver? > There is no way for the driver to know it has a dumb buffer. It copies > the contents of the current framebuffer onto its replacement framebuffer > so that it can do a seamless switch. Sure, but inside the driver is the only place this is happening, right? It's not happening in generic code? If it's in the driver, it's legitimate, and my patch incorrect, because the driver should really be allowed to typecast any buffer... /Thomas > -Chris >
[PATCH] amdkfd: explicitely include io.h in kfd_doorbell.c
On Fri, Nov 21, 2014 at 3:07 PM, Oded Gabbay wrote: > This patch fixes a compilation error when using certain configuration by > including the file io.h in kfd_doorbell.c > > Signed-off-by: Oded Gabbay Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c > b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c > index 0dcb787..b5791a5 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > > /* > * This extension supports a kernel level doorbells management for > -- > 2.1.0 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 86432] llvm Unreal Elemental rendering regression
https://bugs.freedesktop.org/show_bug.cgi?id=86432 --- Comment #13 from Marek Olšák --- Mesa commit 645b471d619b654d3bacfa8598f759833e08db4e should fix this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/76ad3c29/attachment.html>
[PATCH] drm/gem: Warn on illegal use of the dumb buffer interface v2
On 11/21/2014 03:14 PM, Chris Wilson wrote: > On Thu, Nov 20, 2014 at 09:56:25AM +0100, Thomas Hellstrom wrote: >> It happens on occasion that developers of generic user-space applications >> abuse the dumb buffer API to get hold of drm buffers that they can both >> mmap() and use for GPU acceleration, using the assumptions that dumb buffers >> and buffers available for GPU are >> a) The same type and can be aribtrarily type-casted. >> b) fully coherent. > Both (a) and (b) are true for intel and it turns out to be a requirement > for smooth transitions from the boot splash screens into X, and relied > upon by userspace. > -Chris > So when you say relied upon by user-space, do you mean generic user-space or driver-specific user-space? With that, I mean what component is responsible for deciding that the dumb buffer can be accelerated? The Intel xorg driver? /Thomas
[PATCH] amdkfd: Remove DRM_AMDGPU dependency from Kconfig
On Fri, Nov 21, 2014 at 3:40 PM, Oded Gabbay wrote: > Signed-off-by: Oded Gabbay Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig > b/drivers/gpu/drm/amd/amdkfd/Kconfig > index e13c67c..8dfac37 100644 > --- a/drivers/gpu/drm/amd/amdkfd/Kconfig > +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig > @@ -4,6 +4,6 @@ > > config HSA_AMD > tristate "HSA kernel driver for AMD GPU devices" > - depends on (DRM_RADEON || DRM_AMDGPU) && AMD_IOMMU_V2 && X86_64 > + depends on DRM_RADEON && AMD_IOMMU_V2 && X86_64 > help > Enable this if you want to use HSA features on AMD GPU devices. > -- > 2.1.0 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/edid: Tighten checksum conditions for CEA blocks
On Thu, 20 Nov 2014, Stefan Brüns wrote:
> Checksumming was disabled for CEA blocks by
>
> commit 4a638b4e38234233f5c7e6705662fbc0b58d80c2
> Author: Adam Jackson
> Date: Tue May 25 16:33:09 2010 -0400
>
> drm/edid: Allow non-fatal checksum errors in CEA blocks
>
> If only the checksum is wrong, reading twice should result in identical
> data, whereas a bad transfer will most likely corrupt different bytes.
> Comparing checksums is not sufficient, as there is a considerable chance
> of two bad transfers having the same checksum.
>
> Signed-off-by: Stefan Brüns
> ---
> drivers/gpu/drm/drm_edid.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3a10f3f..55963d5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1203,6 +1203,7 @@ drm_do_get_edid(struct drm_connector *connector, struct
> i2c_adapter *adapter)
> {
> int i, j = 0, valid_extensions = 0;
> u8 *block, *new;
> + u8 *saved_block = NULL;
> bool print_bad_edid = !connector->bad_edid_counter || (drm_debug &
> DRM_UT_KMS);
>
> if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> @@ -1233,12 +1234,27 @@ drm_do_get_edid(struct drm_connector *connector,
> struct i2c_adapter *adapter)
>
> for (j = 1; j <= block[0x7e]; j++) {
> u8 *ext_block = block + (valid_extensions + 1) * EDID_LENGTH;
> + u8 csum, last_csum = 0;
> for (i = 0; i < 4; i++) {
> if (drm_do_probe_ddc_edid(adapter, ext_block, j,
> EDID_LENGTH))
> goto out;
> - if (drm_edid_block_valid(ext_block, j, print_bad_edid))
> {
> + csum = drm_edid_block_csum(ext_block);
> + if (!csum) {
> valid_extensions++;
> break;
> + } else if (ext_block[0] == CEA_EXT) {
> + /*
> + * Some switches mangle CEA contents without fixing the
> checksum.
> + * Accept CEA blocks when two reads return identical
> data.
> + */
> + if (saved_block && csum == last_csum &&
> + !memcmp(ext_block, saved_block,
> EDID_LENGTH)) {
> + valid_extensions++;
> + break;
> + }
> + kfree(saved_block);
> + saved_block = kmemdup(ext_block, EDID_LENGTH,
> GFP_KERNEL);
> + last_csum = csum;
I still feel like this should be embedded in drm_edid_block_valid
somehow. Who's going to print the bad edid now? Is it simply no longer
printed in this loop?
I'll defer to others; any better suggestions?
Jani.
> }
> }
>
> @@ -1249,6 +1265,9 @@ drm_do_get_edid(struct drm_connector *connector, struct
> i2c_adapter *adapter)
>
> connector->bad_edid_counter++;
> }
> +
> + kfree(saved_block);
> + saved_block = NULL;
> }
>
> if (valid_extensions != block[0x7e]) {
> @@ -1270,6 +1289,7 @@ carp:
> connector->bad_edid_counter++;
>
> out:
> + kfree(saved_block);
> kfree(block);
> return NULL;
> }
> --
> 2.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH 2/3] drm/edid: calculate address of current extension block only once
On Thu, 20 Nov 2014, Stefan Brüns wrote:
> Signed-off-by: Stefan Brüns
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index b072041..3a10f3f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1232,12 +1232,11 @@ drm_do_get_edid(struct drm_connector *connector,
> struct i2c_adapter *adapter)
> block = new;
>
> for (j = 1; j <= block[0x7e]; j++) {
> + u8 *ext_block = block + (valid_extensions + 1) * EDID_LENGTH;
> for (i = 0; i < 4; i++) {
> - if (drm_do_probe_ddc_edid(adapter,
> - block + (valid_extensions + 1) * EDID_LENGTH,
> - j, EDID_LENGTH))
> + if (drm_do_probe_ddc_edid(adapter, ext_block, j,
> EDID_LENGTH))
> goto out;
> - if (drm_edid_block_valid(block + (valid_extensions + 1)
> * EDID_LENGTH, j, print_bad_edid)) {
> + if (drm_edid_block_valid(ext_block, j, print_bad_edid))
> {
> valid_extensions++;
> break;
> }
> --
> 2.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH 1/3] drm/edid: new drm_edid_block_checksum helper function
On Thu, 20 Nov 2014, Stefan Brüns wrote:
> The function will also be used by a later patch, so factor it out.
>
> Signed-off-by: Stefan Brüns
> ---
> drivers/gpu/drm/drm_edid.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ec4f91f..b072041 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1048,8 +1048,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool
> print_bad_edid)
> }
> }
>
> - for (i = 0; i < EDID_LENGTH; i++)
> - csum += raw_edid[i];
> + csum = drm_edid_block_checksum(raw_edid);
With this change, it's no longer necessary to initialize csum to 0 in
drm_edid_block_valid.
> if (csum) {
> if (print_bad_edid) {
> DRM_ERROR("EDID checksum is invalid, remainder is
> %d\n", csum);
> @@ -1188,6 +1187,17 @@ static bool drm_edid_is_zero(u8 *in_edid, int length)
> return true;
> }
>
> +static u8
> +drm_edid_block_checksum(u8 *raw_edid)
const u8 *raw_edid, please.
Those fixed,
Reviewed-by: Jani Nikula
> +{
> + int i;
> + u8 csum = 0;
> + for (i = 0; i < EDID_LENGTH; i++)
> + csum += raw_edid[i];
> +
> + return csum;
> +}
> +
> static u8 *
> drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
> {
> --
> 2.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/edid: shorten log output in case of all zeroes edid block
On Thu, 20 Nov 2014, Stefan Brüns wrote:
> There is no need to dump the whole EDID block in case it contains no
> information. Just print a single line stating the block is empty instead
> of 8 lines containing only zeroes.
>
> Signed-off-by: Stefan Brüns
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3bf9991..ec4f91f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1080,9 +1080,13 @@ bool drm_edid_block_valid(u8 *raw_edid, int block,
> bool print_bad_edid)
>
> bad:
> if (print_bad_edid) {
> - printk(KERN_ERR "Raw EDID:\n");
> - print_hex_dump(KERN_ERR, " \t", DUMP_PREFIX_NONE, 16, 1,
> + if (drm_edid_is_zero(raw_edid, EDID_LENGTH)) {
> + printk(KERN_ERR "EDID block is all zeroes\n");
> + } else {
> + printk(KERN_ERR "Raw EDID:\n");
> + print_hex_dump(KERN_ERR, " \t", DUMP_PREFIX_NONE, 16, 1,
> raw_edid, EDID_LENGTH, false);
> + }
> }
> return false;
> }
> --
> 2.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH 2/2] 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 --- Documentation/DocBook/drm.tmpl | 1 + include/drm/drm_atomic_helper.h | 26 ++ 2 files changed, 27 insertions(+) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 8c54f9a..3789f2d 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2343,6 +2343,7 @@ void intel_crt_init(struct drm_device *dev) Atomic State Reset and Initialization !Pdrivers/gpu/drm/drm_atomic_helper.c atomic state reset and initialization +!Iinclude/drm/drm_atomic_helper.h !Edrivers/gpu/drm/drm_atomic_helper.c diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h index 64b4e91..42d56e6 100644 --- a/include/drm/drm_atomic_helper.h +++ b/include/drm/drm_atomic_helper.h @@ -96,5 +96,31 @@ drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector); void drm_atomic_helper_connector_destroy_state(struct drm_connector *connector, struct drm_connector_state *state); +/** + * drm_crtc_for_each_plane - iterate over planes currently attached to crtc + * @plane: the loop cursor + * @crtc: the crtc whose planes are iterated + * + * This iterates over the current state, useful (for example) when applying + * atomic state after it has been checked and swapped. To iterate over the + * planes which *will* be attached (for ->atomic_check()) see + * drm_crtc_for_each_pending_plane() + */ +#define drm_crtc_for_each_plane(plane, crtc) \ + list_for_each_entry((plane), &(crtc)->dev->mode_config.plane_list, head) \ + if ((crtc)->state->plane_mask & (1 << drm_plane_index(plane))) + +/** + * drm_crtc_for_each_pending_plane - iterate over attached planes in new state + * @plane: the loop cursor + * @crtc_state: the incoming crtc-state + * + * Similar to drm_crtc_for_each_plane(), but iterates the planes that will be + * attached if the specified state is applied. Useful during (for example) + * ->atomic_check() operations, to validate the incoming state + */ +#define drm_crtc_for_each_pending_plane(plane, crtc_state) \ + list_for_each_entry((plane), &(crtc_state)->state->dev->mode_config.plane_list, head) \ + if ((crtc_state)->plane_mask & (1 << drm_plane_index(plane))) #endif /* DRM_ATOMIC_HELPER_H_ */ -- 1.9.3
[PATCH 1/2] 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
---
drivers/gpu/drm/drm_atomic.c| 25 -
drivers/gpu/drm/drm_atomic_helper.c | 8
include/drm/drm_atomic.h| 4 ++--
include/drm/drm_crtc.h | 14 +++---
4 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d3b4674..8effbba 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -350,7 +350,8 @@ EXPORT_SYMBOL(drm_atomic_get_connector_state);
/**
* drm_atomic_set_crtc_for_plane - set crtc for plane
- * @plane_state: atomic state object for the plane
+ * @state: the incoming atomic state
+ * @plane: the plane whose incoming state to update
* @crtc: crtc to use for the plane
*
* Changing the assigned crtc for a plane requires us to grab the lock and
state
@@ -363,20 +364,34 @@ EXPORT_SYMBOL(drm_atomic_get_connector_state);
* sequence must be restarted. All other errors are fatal.
*/
int
-drm_atomic_set_crtc_for_plane(struct drm_plane_state *plane_state,
- struct drm_crtc *crtc)
+drm_atomic_set_crtc_for_plane(struct drm_atomic_state *state,
+ struct drm_plane *plane, struct drm_crtc *crtc)
{
+ struct drm_plane_state *plane_state =
+ drm_atomic_get_plane_state(state, plane);
struct drm_crtc_state *crtc_state;
- if (crtc) {
+ /* acquire outgoing crtc lock, and clear bit in outgoing crtc mask: */
+ if (plane_state->crtc) {
crtc_state = drm_atomic_get_crtc_state(plane_state->state,
- crtc);
+ plane_state->crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
+
+ crtc_state->plane_mask &= ~(1 << drm_plane_index(plane));
}
plane_state->crtc = crtc;
+ /* acquire incoming crtc lock, and set bit in incoming crtc mask: */
+ if (crtc) {
+ crtc_state = drm_atomic_get_crtc_state(plane_state->state,
+ crtc);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+ crtc_state->plane_mask |= (1 << drm_plane_index(plane));
+ }
+
if (crtc)
DRM_DEBUG_KMS("Link plane state %p to [CRTC:%d]\n",
plane_state, crtc->base.id);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a17b8e9..d765d37 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1187,7 +1187,7 @@ retry:
goto fail;
}
- ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
+ ret = drm_atomic_set_crtc_for_plane(state, plane, crtc);
if (ret != 0)
goto fail;
drm_atomic_set_fb_for_plane(plane_state, fb);
@@ -1255,7 +1255,7 @@ retry:
goto fail;
}
- ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
+ ret = drm_atomic_set_crtc_for_plane(state, plane, NULL);
if (ret != 0)
goto fail;
drm_atomic_set_fb_for_plane(plane_state, NULL);
@@ -1426,7 +1426,7 @@ retry:
goto fail;
}
- ret = drm_atomic_set_crtc_for_plane(primary_state, crtc);
+ ret = drm_atomic_set_crtc_for_plane(state, crtc->primary, crtc);
if (ret != 0)
goto fail;
drm_atomic_set_fb_for_plane(primary_state, set->fb);
@@ -1698,7 +1698,7 @@ retry:
goto fail;
}
- ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
+ ret = drm_atomic_set_crtc_for_plane(state, plane, crtc);
if (ret != 0)
goto fail;
drm_atomic_set_fb_for_plane(plane_state, fb);
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 9d91916..6ff8775 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -44,8 +44,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state *state,
struct drm_connector *connector);
int __must_check
-drm_atomic_set_crtc_for_plane(struct drm_plane_state *plane_state,
- struct drm_crtc *crtc);
+dr
[PATCH 2/3] drm/exynos: avoid race condition when adding a drm component
On 2014ë
11ì 21ì¼ 08:54, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> exynos_drm_component_add() correctly checks if a component is present on
> drm_component_list however it release the lock right after the check
> and before we add the new component to the list. That just creates room
> to add the same component more than once to the list.
A little bit strange. drm_component_list is protected from race
condition with mutex_lock. How the same component can be added to the
drm_component_list again? And a new cdev object cannot be same cdev
object already added to the drm_component_list because the new cdev
object is allocated by kzalloc(). And the only case the same kms driver
can request to add a new cdev to drm_component_list again is when the
probe of the driver failed. However, in this case, the driver will call
exynos_drm_component_del function to remove previous cdev. So the same
cdev cannot be added to the drm_component_list even in such case.
Thanks,
Inki Dae
>
> The lock should be held for the whole journey while adding a new
> component.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index cb3ed9b..230573d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -402,10 +402,8 @@ int exynos_drm_component_add(struct device *dev,
>* added already just return.
>*/
> if (cdev->dev_type_flag == (EXYNOS_DEVICE_TYPE_CRTC |
> - EXYNOS_DEVICE_TYPE_CONNECTOR)) {
> - mutex_unlock(&drm_component_lock);
> - return 0;
> - }
> + EXYNOS_DEVICE_TYPE_CONNECTOR))
> + goto unlock;
>
> if (dev_type == EXYNOS_DEVICE_TYPE_CRTC) {
> cdev->crtc_dev = dev;
> @@ -417,14 +415,11 @@ int exynos_drm_component_add(struct device *dev,
> cdev->dev_type_flag |= dev_type;
> }
>
> - mutex_unlock(&drm_component_lock);
> - return 0;
> + goto unlock;
> }
> }
>
> - mutex_unlock(&drm_component_lock);
> -
> - cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
> + cdev = kzalloc(sizeof(*cdev), GFP_ATOMIC);
> if (!cdev)
> return -ENOMEM;
>
> @@ -436,10 +431,9 @@ int exynos_drm_component_add(struct device *dev,
> cdev->out_type = out_type;
> cdev->dev_type_flag = dev_type;
>
> - mutex_lock(&drm_component_lock);
> list_add_tail(&cdev->list, &drm_component_list);
> +unlock:
> mutex_unlock(&drm_component_lock);
> -
> return 0;
> }
>
>
[PATCH] drm/gem: Warn on illegal use of the dumb buffer interface v2
On Fri, Nov 21, 2014 at 03:48:33PM +0100, Thomas Hellstrom wrote: > On 11/21/2014 03:14 PM, Chris Wilson wrote: > > On Thu, Nov 20, 2014 at 09:56:25AM +0100, Thomas Hellstrom wrote: > >> It happens on occasion that developers of generic user-space applications > >> abuse the dumb buffer API to get hold of drm buffers that they can both > >> mmap() and use for GPU acceleration, using the assumptions that dumb > >> buffers > >> and buffers available for GPU are > >> a) The same type and can be aribtrarily type-casted. > >> b) fully coherent. > > Both (a) and (b) are true for intel and it turns out to be a requirement > > for smooth transitions from the boot splash screens into X, and relied > > upon by userspace. > > -Chris > > > > So when you say relied upon by user-space, do you mean generic > user-space or driver-specific user-space? > > With that, I mean what component is responsible for deciding that the > dumb buffer can be accelerated? The Intel xorg driver? There is no way for the driver to know it has a dumb buffer. It copies the contents of the current framebuffer onto its replacement framebuffer so that it can do a seamless switch. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm/gem: Warn on illegal use of the dumb buffer interface v2
On Thu, Nov 20, 2014 at 09:56:25AM +0100, Thomas Hellstrom wrote: > It happens on occasion that developers of generic user-space applications > abuse the dumb buffer API to get hold of drm buffers that they can both > mmap() and use for GPU acceleration, using the assumptions that dumb buffers > and buffers available for GPU are > a) The same type and can be aribtrarily type-casted. > b) fully coherent. Both (a) and (b) are true for intel and it turns out to be a requirement for smooth transitions from the boot splash screens into X, and relied upon by userspace. -Chris -- Chris Wilson, Intel Open Source Technology Centre
Question about removing spinlock in qxt_fb.c
Greetings David, I am wondering whether we can remove the fix me in this file related to not needing a spin lock or should I remove the comment for locks and then remove the FIX ME if we need the lock here. Regards Nick
[PATCH 1/2] drm/exynos: fix null pointer dereference issue
2014-11-21 Inki Dae : > On 2014ë 11ì 21ì¼ 08:12, Gustavo Padovan wrote: > > 2014-11-13 Inki Dae : > > > >> 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. > > > > This patch is breaking exynos initialization, > > exynos_drm_device_subdrv_probe() > > needs the drvdata but it is still NULL at this point which make the whole > > exynos init fails. The drvdata is only set in exynos_drm_load() so we need > > call exynos_drm_device_subdrv_probe() after that. > > There might be my missing point but with this patch, > exynos_drm_device_subdrv_probe() will be called after exynos_drm_load() > call because all kms drivers are probed before > component_master_add_with_match call so exynos_drm_load() must be called > by component_master_add_with_match function before > exynos_drm_device_subdrv_probe call. > > So could you show me the error messages you faced with? There might be a > corner case I missed. I've added some debug output to it. It fails on exynos_drm_device_subdrv_probe() because the drvdata is NULL. I've added debug output to exynos_drm_load() and as you can see it doesn't get called before subdrv_probe(). I'm testing this on snow. [1.767835] [drm] Initialized drm 1.1.0 20060810 [1.771120] [drm:exynos_drm_init] [1.774774] [drm:exynos_drm_platform_probe] [1.778760] platform exynos-drm: Driver exynos-drm requests probe deferral [1.786178] platform 145b.dp-controller: Driver exynos-dp requests probe deferral [1.794374] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully. [1.800372] [drm:exynos_drm_device_subdrv_probe] dev (null) Gustavo
[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Am 21.11.2014 um 00:49 schrieb Paolo Pisati: > vanilla kgene/for-next as of today: > > 7552917 Revert "ARM: exynos_defconfig: Enable options for display panel > support" > ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next > 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next > cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next > 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers > 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device > 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow > fc14f9c Linux 3.18-rc5 > ... > > plus > > 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy > 36d908e drm/exynos: dp: Remove support for unused dptx-phy > 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices > 68944e3 Revert "Revert "ARM: exynos_defconfig: Enable options for display > panel > support"" > > vanilla exynos_defconfig with SND_SOC_SNOW disabled. > > I should probably try linux-next at this point, but i wonder if people who > reported kgene/for-next working were testing with a vanilla exynos_defconfig > on > a peach pi. On Spring, I am able to boot my kgene/for-next based queue with just: mfd: syscon: Decouple syscon interface from platform devices arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy with DRM_EXYNOS*=y (except IOMMU) and SND_SOC_SNOW=m enabled in the config, while using simplefb rather than the Exynos DRM and thus clk_ignore_unused. Regarding SND_SOC_SNOW: Note that I recently submitted a patch to enable module-loading, which is missing in kgene/for-next and -rc5 but is in linux-next.git - it might uncover problems that previously went unnoticed: https://patchwork.kernel.org/patch/5235951/ exynos_defconfig has SND_SOC_SNOW=y, whereas multi_v7_defconfig doesn't have it. Regards, Andreas -- SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg
[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Inki, On 11/20/2014 06:01 PM, Inki Dae wrote: > Ah, sorry. There was my misunderstanding. drm-next already is merged > to linux-next so I think we can do the integration test if > exynos-drm-next is merged to drm-next earlier. Anyway, I will try to > consider your opinion. > Cool, having exynos-drm-next in linux-next will be very useful indeed. BTW, I didn't have time to forward port $subject yesterday but Gustavo did and posted a series [0] that supersedes $subjects and also solves other issues. It would be great if you can take a loot to those patches. Best regards, Javier [0]: http://www.spinics.net/lists/linux-samsung-soc/msg39306.html
[RFC] add a struct page* parameter to dma_map_ops.unmap_page
On Fri, Nov 21 2014 at 03:48:33 AM, Stefano Stabellini wrote:
> On Mon, 17 Nov 2014, Stefano Stabellini wrote:
>> Hi all,
>> I am writing this email to ask for your advice.
>>
>> On architectures where dma addresses are different from physical
>> addresses, it can be difficult to retrieve the physical address of a
>> page from its dma address.
>>
>> Specifically this is the case for Xen on arm and arm64 but I think that
>> other architectures might have the same issue.
>>
>> Knowing the physical address is necessary to be able to issue any
>> required cache maintenance operations when unmap_page,
>> sync_single_for_cpu and sync_single_for_device are called.
>>
>> Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
>> sync_single_for_device would make Linux dma handling on Xen on arm and
>> arm64 much easier and quicker.
>>
>> I think that other drivers have similar problems, such as the Intel
>> IOMMU driver having to call find_iova and walking down an rbtree to get
>> the physical address in its implementation of unmap_page.
>>
>> Callers have the struct page* in their hands already from the previous
>> map_page call so it shouldn't be an issue for them. A problem does
>> exist however: there are about 280 callers of dma_unmap_page and
>> pci_unmap_page. We have even more callers of the dma_sync_single_for_*
>> functions.
>>
>>
>>
>> Is such a change even conceivable? How would one go about it?
>>
>> I think that Xen would not be the only one to gain from it, but I would
>> like to have a confirmation from others: given the magnitude of the
>> changes involved I would actually prefer to avoid them unless multiple
>> drivers/archs/subsystems could really benefit from them.
>
> Given the lack of interest from the community, I am going to drop this
> idea.
Actually it sounds like the right API design to me. As a bonus it
should help performance a bit as well. For example, the current
implementations of dma_sync_single_for_{cpu,device} and dma_unmap_page
on ARM while using the IOMMU mapper
(arm_iommu_sync_single_for_{cpu,device}, arm_iommu_unmap_page) all call
iommu_iova_to_phys which generally results in a page table walk or a
hardware register write/poll/read.
The problem, as you mentioned, is that there are a ton of callers of the
existing APIs. I think David Vrabel had a good suggestion for dealing
with this:
On Mon, Nov 17 2014 at 06:43:46 AM, David Vrabel
wrote:
> You may need to consider a parallel set of map/unmap API calls that
> return/accept a handle, and then converting drivers one-by-one as
> required, instead of trying to convert every single driver at once.
However, I'm not sure whether the costs of having a parallel set of APIs
outweigh the benefits of a cleaner API and a slight performance boost...
But I hope the idea isn't completely abandoned without some profiling or
other evidence of its benefits (e.g. patches showing how drivers could
be simplified with the new APIs).
-Mitch
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 2/2] drm/radeon: Move hotspot handling out of radeon_set_cursor
From: Michel Dänzer
It's only needed in radeon_crtc_cursor_set2.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_cursor.c | 36 --
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/gpu/drm/radeon/radeon_cursor.c
index 44dcbde6..45e5406 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -227,8 +227,7 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
return ret;
}
-static int radeon_set_cursor(struct drm_crtc *crtc, struct drm_gem_object *obj,
-int hot_x, int hot_y)
+static int radeon_set_cursor(struct drm_crtc *crtc, struct drm_gem_object *obj)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_device *rdev = crtc->dev->dev_private;
@@ -267,19 +266,6 @@ static int radeon_set_cursor(struct drm_crtc *crtc, struct
drm_gem_object *obj,
WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
radeon_crtc->legacy_cursor_offset);
}
- if (hot_x != radeon_crtc->cursor_hot_x ||
- hot_y != radeon_crtc->cursor_hot_y) {
- int x, y;
-
- x = radeon_crtc->cursor_x + radeon_crtc->cursor_hot_x - hot_x;
- y = radeon_crtc->cursor_y + radeon_crtc->cursor_hot_y - hot_y;
-
- radeon_cursor_move_locked(crtc, x, y);
-
- radeon_crtc->cursor_hot_x = hot_x;
- radeon_crtc->cursor_hot_y = hot_y;
- }
-
return 0;
fail:
@@ -323,7 +309,21 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
radeon_crtc->cursor_height = height;
radeon_lock_cursor(crtc, true);
- ret = radeon_set_cursor(crtc, obj, hot_x, hot_y);
+
+ if (hot_x != radeon_crtc->cursor_hot_x ||
+ hot_y != radeon_crtc->cursor_hot_y) {
+ int x, y;
+
+ x = radeon_crtc->cursor_x + radeon_crtc->cursor_hot_x - hot_x;
+ y = radeon_crtc->cursor_y + radeon_crtc->cursor_hot_y - hot_y;
+
+ radeon_cursor_move_locked(crtc, x, y);
+
+ radeon_crtc->cursor_hot_x = hot_x;
+ radeon_crtc->cursor_hot_y = hot_y;
+ }
+
+ ret = radeon_set_cursor(crtc, obj);
if (ret)
DRM_ERROR("radeon_set_cursor returned %d, not changing
cursor\n",
@@ -368,9 +368,7 @@ void radeon_cursor_reset(struct drm_crtc *crtc)
radeon_cursor_move_locked(crtc, radeon_crtc->cursor_x,
radeon_crtc->cursor_y);
- ret = radeon_set_cursor(crtc, radeon_crtc->cursor_bo,
- radeon_crtc->cursor_hot_x,
- radeon_crtc->cursor_hot_y);
+ ret = radeon_set_cursor(crtc, radeon_crtc->cursor_bo);
if (ret)
DRM_ERROR("radeon_set_cursor returned %d, not showing "
"cursor\n", ret);
--
2.1.3
[PATCH 1/2] drm/radeon: Re-show the cursor after a modeset
From: Michel Dänzer
Setting a mode seems to clear the cursor registers, so we need to
re-program them to make sure the cursor is visible.
Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c | 1 +
drivers/gpu/drm/radeon/radeon_cursor.c | 89 +
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 1 +
drivers/gpu/drm/radeon/radeon_mode.h| 1 +
4 files changed, 68 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 30d242b..d59ec49 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -2039,6 +2039,7 @@ int atombios_crtc_mode_set(struct drm_crtc *crtc,
atombios_crtc_set_base(crtc, x, y, old_fb);
atombios_overscan_setup(crtc, mode, adjusted_mode);
atombios_scaler_setup(crtc);
+ radeon_cursor_reset(crtc);
/* update the hw version fpr dpm */
radeon_crtc->hw_mode = *adjusted_mode;
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/gpu/drm/radeon/radeon_cursor.c
index 85f38ee..44dcbde6 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -227,11 +227,25 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
return ret;
}
-static void radeon_set_cursor(struct drm_crtc *crtc, struct drm_gem_object
*obj,
- uint64_t gpu_addr, int hot_x, int hot_y)
+static int radeon_set_cursor(struct drm_crtc *crtc, struct drm_gem_object *obj,
+int hot_x, int hot_y)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_device *rdev = crtc->dev->dev_private;
+ struct radeon_bo *robj = gem_to_radeon_bo(obj);
+ uint64_t gpu_addr;
+ int ret;
+
+ ret = radeon_bo_reserve(robj, false);
+ if (unlikely(ret != 0))
+ goto fail;
+ /* Only 27 bit offset for legacy cursor */
+ ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
+ ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
+ &gpu_addr);
+ radeon_bo_unreserve(robj);
+ if (ret)
+ goto fail;
if (ASIC_IS_DCE4(rdev)) {
WREG32(EVERGREEN_CUR_SURFACE_ADDRESS_HIGH +
radeon_crtc->crtc_offset,
@@ -265,6 +279,13 @@ static void radeon_set_cursor(struct drm_crtc *crtc,
struct drm_gem_object *obj,
radeon_crtc->cursor_hot_x = hot_x;
radeon_crtc->cursor_hot_y = hot_y;
}
+
+ return 0;
+
+fail:
+ drm_gem_object_unreference_unlocked(obj);
+
+ return ret;
}
int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
@@ -276,10 +297,7 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
int32_t hot_y)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- struct radeon_device *rdev = crtc->dev->dev_private;
struct drm_gem_object *obj;
- struct radeon_bo *robj;
- uint64_t gpu_addr;
int ret;
if (!handle) {
@@ -301,41 +319,64 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
return -ENOENT;
}
- robj = gem_to_radeon_bo(obj);
- ret = radeon_bo_reserve(robj, false);
- if (unlikely(ret != 0))
- goto fail;
- /* Only 27 bit offset for legacy cursor */
- ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
- ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
- &gpu_addr);
- radeon_bo_unreserve(robj);
- if (ret)
- goto fail;
-
radeon_crtc->cursor_width = width;
radeon_crtc->cursor_height = height;
radeon_lock_cursor(crtc, true);
- radeon_set_cursor(crtc, obj, gpu_addr, hot_x, hot_y);
- radeon_show_cursor(crtc);
+ ret = radeon_set_cursor(crtc, obj, hot_x, hot_y);
+
+ if (ret)
+ DRM_ERROR("radeon_set_cursor returned %d, not changing
cursor\n",
+ ret);
+ else
+ radeon_show_cursor(crtc);
+
radeon_lock_cursor(crtc, false);
unpin:
if (radeon_crtc->cursor_bo) {
- robj = gem_to_radeon_bo(radeon_crtc->cursor_bo);
+ struct radeon_bo *robj =
gem_to_radeon_bo(radeon_crtc->cursor_bo);
ret = radeon_bo_reserve(robj, false);
if (likely(ret == 0)) {
radeon_bo_unpin(robj);
radeon_bo_unreserve(robj);
}
- drm_gem_object_unreference_unlocked(radeon_crtc->cursor_bo);
+ if (radeon_crtc->cursor_bo != obj)
+
drm_gem_object_unreference_unlocked(radeon_crtc->cursor_bo);
}
radeon_crtc->cursor_bo = obj;
return 0;
-fail:
- drm_gem_obje
[RFC] add a struct page* parameter to dma_map_ops.unmap_page
On Mon, 17 Nov 2014, Stefano Stabellini wrote:
> Hi all,
> I am writing this email to ask for your advice.
>
> On architectures where dma addresses are different from physical
> addresses, it can be difficult to retrieve the physical address of a
> page from its dma address.
>
> Specifically this is the case for Xen on arm and arm64 but I think that
> other architectures might have the same issue.
>
> Knowing the physical address is necessary to be able to issue any
> required cache maintenance operations when unmap_page,
> sync_single_for_cpu and sync_single_for_device are called.
>
> Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
> sync_single_for_device would make Linux dma handling on Xen on arm and
> arm64 much easier and quicker.
>
> I think that other drivers have similar problems, such as the Intel
> IOMMU driver having to call find_iova and walking down an rbtree to get
> the physical address in its implementation of unmap_page.
>
> Callers have the struct page* in their hands already from the previous
> map_page call so it shouldn't be an issue for them. A problem does
> exist however: there are about 280 callers of dma_unmap_page and
> pci_unmap_page. We have even more callers of the dma_sync_single_for_*
> functions.
>
>
>
> Is such a change even conceivable? How would one go about it?
>
> I think that Xen would not be the only one to gain from it, but I would
> like to have a confirmation from others: given the magnitude of the
> changes involved I would actually prefer to avoid them unless multiple
> drivers/archs/subsystems could really benefit from them.
Given the lack of interest from the community, I am going to drop this
idea.
> Cheers,
>
> Stefano
>
>
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index d5d3881..158a765 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -31,8 +31,9 @@ struct dma_map_ops {
> unsigned long offset, size_t size,
> enum dma_data_direction dir,
> struct dma_attrs *attrs);
> - void (*unmap_page)(struct device *dev, dma_addr_t dma_handle,
> -size_t size, enum dma_data_direction dir,
> + void (*unmap_page)(struct device *dev, struct page *page,
> +dma_addr_t dma_handle, size_t size,
> +enum dma_data_direction dir,
> struct dma_attrs *attrs);
> int (*map_sg)(struct device *dev, struct scatterlist *sg,
> int nents, enum dma_data_direction dir,
> @@ -41,10 +42,10 @@ struct dma_map_ops {
>struct scatterlist *sg, int nents,
>enum dma_data_direction dir,
>struct dma_attrs *attrs);
> - void (*sync_single_for_cpu)(struct device *dev,
> + void (*sync_single_for_cpu)(struct device *dev, struct page *page,
> dma_addr_t dma_handle, size_t size,
> enum dma_data_direction dir);
> - void (*sync_single_for_device)(struct device *dev,
> + void (*sync_single_for_device)(struct device *dev, struct page *page,
> dma_addr_t dma_handle, size_t size,
> enum dma_data_direction dir);
> void (*sync_sg_for_cpu)(struct device *dev,
>
[PATCH v5 08/24] amdkfd: Add amdkfd skeleton driver
On Sat, 2014-11-08 at 20:37 +0200, Oded Gabbay wrote: > This patch adds the amdkfd skeleton driver. The driver does nothing except > define a /dev/kfd device. > > It returns -ENODEV on all amdkfd IOCTLs. > > v3: Move bool field to the end of structure, removed the pmc ioctls and added > a meaningful error message for ioctl error. > > v5: > > Create a new folder drm/amd and move amdkfd from drm/radeon/ to drm/amd/ > Remove scheduler_class from kfd_priv.h as it was never used > Add skeleton implementation of the Get Version IOCTL > > Signed-off-by: Oded Gabbay It seems v6 of this patch is included in today's linux-next (ie, next-20141121). > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/amd/amdkfd/Kconfig | 10 ++ > drivers/gpu/drm/amd/amdkfd/Makefile | 9 ++ > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 210 > +++ > drivers/gpu/drm/amd/amdkfd/kfd_device.c | 130 +++ > drivers/gpu/drm/amd/amdkfd/kfd_module.c | 101 +++ > drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 81 > 8 files changed, 544 insertions(+) > [...] > diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig > b/drivers/gpu/drm/amd/amdkfd/Kconfig > new file mode 100644 > index 000..a2ae6d4 > --- /dev/null > +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig > @@ -0,0 +1,10 @@ > +# > +# Heterogenous system architecture configuration > +# > + > +config HSA_AMD > + tristate "HSA kernel driver for AMD GPU devices" > + depends on (DRM_RADEON || DRM_AMDGPU) && AMD_IOMMU_V2 && X86_64 There's currently no Kconfig symbol DRM_AMDGPU (nor anything similar). Will that symbol be added in a future patch? > + default m > + help > + Enable this if you want to use HSA features on AMD GPU devices. Paul Bolle
3.18-rc regression: drm/nouveau: use shared fences for readable objects
On Nov 20, 2014 12:53 AM, "Maarten Lankhorst" < maarten.lankhorst at canonical.com> wrote: > > Op 20-11-14 om 05:06 schreef Michael Marineau: > > On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst > > wrote: > >> Hey, > >> > >> On 19-11-14 07:43, Michael Marineau wrote: > >>> On 3.18-rc kernel's I have been intermittently experiencing GPU > >>> lockups shortly after startup, accompanied with one or both of the > >>> following errors: > >>> > >>> nouveau E[ PFIFO][:01:00.0] read fault at 0x000734a000 [PTE] > >>> from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown] > >>> nouveau E[ DRM] GPU lockup - switching to software fbcon > >>> > >>> I was able to trace the issue with bisect to commit > >>> 809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared > >>> fences for readable objects". The lockups appear to have cleared up > >>> since reverting that and a few related followup commits: > >>> > >>> 809e9447: "drm/nouveau: use shared fences for readable objects" > >>> 055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1" > >>> e3be4c23: "drm/nouveau: specify if interruptible wait is desired in > >>> nouveau_fence_sync" > >>> 15a996bb: "drm/nouveau: assign fence_chan->name correctly" > >> Weird. I'm not sure yet what causes it. > >> > >> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect&id=86be4f216bbb9ea3339843a5658d4c21162c7ee2 > > Building a kernel from that commit gives me an entirely new behavior: > > X hangs for at least 10-20 seconds at a time with brief moments of > > responsiveness before hanging again while gitk on the kernel repo > > loads. Otherwise the system is responsive. The head of that > > fixed-fences-for-bisect branch (1c6aafb5) which is the "use shared > > fences for readable objects" commit I originally bisected to does > > feature the complete lockups I was seeing before. > Ok for the sake of argument lets just assume they're separate bugs, and we should look at xorg > hanging first. > > Is there anything in the dmesg when the hanging happens? Nothing in dmesg, I will try some more experiments shortly including the ones you suggest below. Just in case it wasn't clear those xorg hangs do not happen on the branch head if I get lucky and manage to log in without the GPU lockup so if they are different bugs it at least appears that both present at the same time. > > And it's probably 15 seconds, if it's called through nouveau_fence_wait. > > Try changing else if (!ret) to else if (WARN_ON(!ret)) in that function, and see if you get some dmesg spam. :) > > > >> On the EDITED patch from fixed-fences-for-bisect, can you do the following: > >> > >> In nouveau/nv84_fence.c function nv84_fence_context_new, remove > >> > >> fctx->base.sequence = nv84_fence_read(chan); > >> > >> and add back > >> > >> nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x); > > Making your suggested change on top of each 86be4f21 and 1c6aafb5 made > > no noticeable difference in either of the two behaviors. > > > >> If that fails you should compile your kernel with trace events, to get some debugging info from the fences. I'll post debugging info if this does not fix it. > > Happy to gather whatever debug log or tracing data you need :) > > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/4614ffb4/attachment-0001.html>
[PATCH 1/2] drm/exynos: fix null pointer dereference issue
On 2014ë 11ì 21ì¼ 08:12, Gustavo Padovan wrote: > 2014-11-13 Inki Dae : > >> 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. > > This patch is breaking exynos initialization, exynos_drm_device_subdrv_probe() > needs the drvdata but it is still NULL at this point which make the whole > exynos init fails. The drvdata is only set in exynos_drm_load() so we need > call exynos_drm_device_subdrv_probe() after that. There might be my missing point but with this patch, exynos_drm_device_subdrv_probe() will be called after exynos_drm_load() call because all kms drivers are probed before component_master_add_with_match call so exynos_drm_load() must be called by component_master_add_with_match function before exynos_drm_device_subdrv_probe call. So could you show me the error messages you faced with? There might be a corner case I missed. > > Do you have the crash output for this? What is the issue you are fixing? Ok, below is the error messages, # modetest [5.653291] [ cut here ] [5.656469] WARNING: CPU: 2 PID: 1404 at kernel/locking/mutex.c:511 __mutex_lock_slowpath+0x3d4/0x3d8() [5.665816] DEBUG_LOCKS_WARN_ON(l->magic != l) [5.670069] Modules linked in: [5.673286] CPU: 2 PID: 1404 Comm: modetest Not tainted 3.18.0-rc3-146775-gbcfef97 #1149 [5.681389] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [5.689090] [] (show_stack) from [] (dump_stack+0x84/0xc4) [5.696304] [] (dump_stack) from [] (warn_slowpath_common+0x6c/0x88) [5.704364] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [5.713047] [] (warn_slowpath_fmt) from [] (__mutex_lock_slowpath+0x3d4/0x3d8) [5.721984] [] (__mutex_lock_slowpath) from [] (mutex_lock+0xc/0x24) [5.730069] [] (mutex_lock) from [] (ipp_subdrv_close+0x4c/0x13c) [5.737881] [] (ipp_subdrv_close) from [] (exynos_drm_subdrv_close+0x3c/0x4c) [5.746731] [] (exynos_drm_subdrv_close) from [] (drm_release+0x94/0x4c8) [5.755228] [] (drm_release) from [] (__fput+0x80/0x1c8) [5.762268] [] (__fput) from [] (task_work_run+0xac/0xe4) [5.769382] [] (task_work_run) from [] (do_work_pending+0x94/0xb4) [5.777275] [] (do_work_pending) from [] (work_pending+0xc/0x20) [5.784994] ---[ end trace bb48a41ae89d1f25 ]--- [5.789598] Unable to handle kernel NULL pointer dereference at virtual address [5.797664] pgd = ee3b8000 [5.800354] [] *pgd=6e366831, *pte=, *ppte= [5.806610] Internal error: Oops: 817 [#1] PREEMPT SMP ARM [5.812074] Modules linked in: [5.815117] CPU: 2 PID: 1404 Comm: modetest Tainted: GW 3.18.0-rc3-146775-gbcfef97 #1149 [5.824314] task: eea90800 ti: ee33c000 task.ti: ee33c000 [5.829704] PC is at __mutex_lock_slowpath+0xf4/0x3d8 [5.834730] LR is at __mutex_lock_slowpath+0xdc/0x3d8 [5.839765] pc : []lr : []psr: 8093 [5.839765] sp : ee33de88 ip : ee33de98 fp : c06cb814 [5.851220] r10: ee0f5854 r9 : c0700784 r8 : eea90800 [5.856429] r7 : ee33c008 r6 : 6013 r5 : ee0f5844 r4 : ee0f5840 [5.862938] r3 : r2 : r1 : ee33de88 r0 : ee0f5840 [5.869451] Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [5.876654] Control: 10c5387d Table: 6e3b804a DAC: 0015 [5.882383] Process modetest (pid: 1404, stack limit = 0xee33c240) [5.888544] Stack: (0xee33de88 to 0xee33e000) [5.892888] de80: ee0f5854 ee33de88 0001d030 ee0f5840 [5.901048] dea0: c06b1d94 ee0f5810 c0705e4c ee0eeb00 ee0f5840 ee0f5810 c0477a5c [5.909207] dec0: eeb4a510 c028e6fc ee14a434 eeb4a510 c06b2fe4 ee14a400 ee33c000 eeb4a510 [5.917366] dee0: c06b1d94 ee0eeb00 ee14a400 ee14a434 0008 ee0eea08 c027a51c [5.925525] df00: c0705e4c ee0eeb00 ee0eea00 ee14a400 ee14a434 c025eadc ee0eea08 0001 [5.933684] df20: eebce000 0021 ee0eea00 ee3354e0 [5.941843] df40: ee32a250 ee711428 0008 ee0eea08 c00cbdd4 [5.950002] df60: eea90b4c c06ca604 eea90800 c000e824 ee33c000 c0037840 [5.958161] df80: ee33c018 c000e824 ee33dfb0 ee33c000 c000e824 c00110f8 0003 0001 [5.966320] dfa0: beff0a4c 0006 c000e824 c000e6e0 0001d000 0003 0001d000 [5.974479] dfc0: 0003 0001 beff0a4c 0006 [5.982639] dfe0: beff09a4 b6f74257 b6eef626 40
[PATCH 1/2] drm/radeon: Re-show the cursor after a modeset
On Thu, Nov 20, 2014 at 9:48 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Setting a mode seems to clear the cursor registers, so we need to
> re-program them to make sure the cursor is visible.
>
> Signed-off-by: Michel Dänzer
> Reviewed-by: Alex Deucher
Applied the series to my -next tree. Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/atombios_crtc.c | 1 +
> drivers/gpu/drm/radeon/radeon_cursor.c | 89
> +
> drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 1 +
> drivers/gpu/drm/radeon/radeon_mode.h| 1 +
> 4 files changed, 68 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index 30d242b..d59ec49 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -2039,6 +2039,7 @@ int atombios_crtc_mode_set(struct drm_crtc *crtc,
> atombios_crtc_set_base(crtc, x, y, old_fb);
> atombios_overscan_setup(crtc, mode, adjusted_mode);
> atombios_scaler_setup(crtc);
> + radeon_cursor_reset(crtc);
> /* update the hw version fpr dpm */
> radeon_crtc->hw_mode = *adjusted_mode;
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
> b/drivers/gpu/drm/radeon/radeon_cursor.c
> index 85f38ee..44dcbde6 100644
> --- a/drivers/gpu/drm/radeon/radeon_cursor.c
> +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
> @@ -227,11 +227,25 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
> return ret;
> }
>
> -static void radeon_set_cursor(struct drm_crtc *crtc, struct drm_gem_object
> *obj,
> - uint64_t gpu_addr, int hot_x, int hot_y)
> +static int radeon_set_cursor(struct drm_crtc *crtc, struct drm_gem_object
> *obj,
> +int hot_x, int hot_y)
> {
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> struct radeon_device *rdev = crtc->dev->dev_private;
> + struct radeon_bo *robj = gem_to_radeon_bo(obj);
> + uint64_t gpu_addr;
> + int ret;
> +
> + ret = radeon_bo_reserve(robj, false);
> + if (unlikely(ret != 0))
> + goto fail;
> + /* Only 27 bit offset for legacy cursor */
> + ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
> + ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
> + &gpu_addr);
> + radeon_bo_unreserve(robj);
> + if (ret)
> + goto fail;
>
> if (ASIC_IS_DCE4(rdev)) {
> WREG32(EVERGREEN_CUR_SURFACE_ADDRESS_HIGH +
> radeon_crtc->crtc_offset,
> @@ -265,6 +279,13 @@ static void radeon_set_cursor(struct drm_crtc *crtc,
> struct drm_gem_object *obj,
> radeon_crtc->cursor_hot_x = hot_x;
> radeon_crtc->cursor_hot_y = hot_y;
> }
> +
> + return 0;
> +
> +fail:
> + drm_gem_object_unreference_unlocked(obj);
> +
> + return ret;
> }
>
> int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
> @@ -276,10 +297,7 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
> int32_t hot_y)
> {
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> - struct radeon_device *rdev = crtc->dev->dev_private;
> struct drm_gem_object *obj;
> - struct radeon_bo *robj;
> - uint64_t gpu_addr;
> int ret;
>
> if (!handle) {
> @@ -301,41 +319,64 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
> return -ENOENT;
> }
>
> - robj = gem_to_radeon_bo(obj);
> - ret = radeon_bo_reserve(robj, false);
> - if (unlikely(ret != 0))
> - goto fail;
> - /* Only 27 bit offset for legacy cursor */
> - ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
> - ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
> - &gpu_addr);
> - radeon_bo_unreserve(robj);
> - if (ret)
> - goto fail;
> -
> radeon_crtc->cursor_width = width;
> radeon_crtc->cursor_height = height;
>
> radeon_lock_cursor(crtc, true);
> - radeon_set_cursor(crtc, obj, gpu_addr, hot_x, hot_y);
> - radeon_show_cursor(crtc);
> + ret = radeon_set_cursor(crtc, obj, hot_x, hot_y);
> +
> + if (ret)
> + DRM_ERROR("radeon_set_cursor returned %d, not changing
> cursor\n",
> + ret);
> + else
> + radeon_show_cursor(crtc);
> +
> radeon_lock_cursor(crtc, false);
>
> unpin:
> if (radeon_crtc->cursor_bo) {
> - robj = gem_to_radeon_bo(radeon_crtc->cursor_bo);
> + struct radeon_bo *robj =
> gem_to_radeon_bo(radeon_crtc->cursor_bo);
> ret = radeon_bo_reserve(robj, false);
> if (likely(ret == 0)) {
> radeon_bo_unpin(robj);
>
[PATCH 12/12] amdkfd: Clear ctx cb before suspend
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 9beb6f7..43884eb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -267,6 +267,7 @@ void kgd2kfd_suspend(struct kfd_dev *kfd)
if (kfd->init_complete) {
kfd->dqm->stop(kfd->dqm);
+ amd_iommu_set_invalidate_ctx_cb(kfd->pdev, NULL);
amd_iommu_free_device(kfd->pdev);
}
}
--
2.1.0
[PATCH 11/12] amdkfd: Instead of using get function, use container_of
From: Alexey Skidanov
Signed-off-by: Alexey Skidanov
Signed-off-by: Oded Gabbay
---
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 21 +
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 ++
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index bc8961c3..904eb38 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -67,26 +67,21 @@ static inline unsigned int get_pipes_num_cpsch(void)
return PIPE_PER_ME_CP_SCHEDULING;
}
-static unsigned int get_sh_mem_bases_nybble_64(struct kfd_process *process,
- struct kfd_dev *dev)
+static inline unsigned int
+get_sh_mem_bases_nybble_64(struct kfd_process_device *pdd)
{
- struct kfd_process_device *pdd;
uint32_t nybble;
- pdd = kfd_get_process_device_data(dev, process, 1);
nybble = (pdd->lds_base >> 60) & 0x0E;
return nybble;
}
-static unsigned int get_sh_mem_bases_32(struct kfd_process *process,
- struct kfd_dev *dev)
+static inline unsigned int get_sh_mem_bases_32(struct kfd_process_device *pdd)
{
- struct kfd_process_device *pdd;
unsigned int shared_base;
- pdd = kfd_get_process_device_data(dev, process, 1);
shared_base = (pdd->lds_base >> 16) & 0xFF;
return shared_base;
@@ -96,10 +91,13 @@ static uint32_t compute_sh_mem_bases_64bit(unsigned int
top_address_nybble);
static void init_process_memory(struct device_queue_manager *dqm,
struct qcm_process_device *qpd)
{
+ struct kfd_process_device *pdd;
unsigned int temp;
BUG_ON(!dqm || !qpd);
+ pdd = qpd_to_pdd(qpd);
+
/* check if sh_mem_config register already configured */
if (qpd->sh_mem_config == 0) {
qpd->sh_mem_config =
@@ -111,11 +109,11 @@ static void init_process_memory(struct
device_queue_manager *dqm,
}
if (qpd->pqm->process->is_32bit_user_mode) {
- temp = get_sh_mem_bases_32(qpd->pqm->process, dqm->dev);
+ temp = get_sh_mem_bases_32(pdd);
qpd->sh_mem_bases = SHARED_BASE(temp);
qpd->sh_mem_config |= PTR32;
} else {
- temp = get_sh_mem_bases_nybble_64(qpd->pqm->process, dqm->dev);
+ temp = get_sh_mem_bases_nybble_64(pdd);
qpd->sh_mem_bases = compute_sh_mem_bases_64bit(temp);
}
@@ -707,8 +705,7 @@ static int stop_cpsch(struct device_queue_manager *dqm)
destroy_queues_cpsch(dqm, true);
list_for_each_entry(node, &dqm->queues, list) {
- pdd = kfd_get_process_device_data(dqm->dev,
- node->qpd->pqm->process, 1);
+ pdd = qpd_to_pdd(node->qpd);
pdd->bound = false;
}
kfd2kgd->free_mem(dqm->dev->kgd,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index d0bcafc..f9fb81e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -414,6 +414,8 @@ struct kfd_process_device {
bool bound;
};
+#define qpd_to_pdd(x) container_of(x, struct kfd_process_device, qpd)
+
/* Process data */
struct kfd_process {
/*
--
2.1.0
[PATCH 10/12] amdkfd: use schedule() in sync_with_hw
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. Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c index 5055fc9..9abac48 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c @@ -25,6 +25,7 @@ #include #include #include +#include #include "kfd_kernel_queue.h" #include "kfd_priv.h" #include "kfd_device_queue_manager.h" @@ -274,7 +275,7 @@ static int sync_with_hw(struct kernel_queue *kq, unsigned long timeout_ms) *kq->wptr_kernel, *kq->rptr_kernel); return -ETIME; } - cpu_relax(); + schedule(); } return 0; -- 2.1.0
[PATCH 2/3] drm/exynos: avoid race condition when adding a drm component
2014-11-21 Inki Dae : > On 2014ë 11ì 21ì¼ 08:54, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > exynos_drm_component_add() correctly checks if a component is present on > > drm_component_list however it release the lock right after the check > > and before we add the new component to the list. That just creates room > > to add the same component more than once to the list. > > A little bit strange. drm_component_list is protected from race > condition with mutex_lock. How the same component can be added to the > drm_component_list again? And a new cdev object cannot be same cdev > object already added to the drm_component_list because the new cdev > object is allocated by kzalloc(). And the only case the same kms driver > can request to add a new cdev to drm_component_list again is when the > probe of the driver failed. However, in this case, the driver will call > exynos_drm_component_del function to remove previous cdev. So the same > cdev cannot be added to the drm_component_list even in such case. Hmm, right. I haven't payed attention that each one of them is called just once. I did this patch in my first days working with this code so I ignored what exynos_drm_component_add() was really doing. Gustavo
[PATCH 09/12] amdkfd: Fix memory leak on process deregistration
From: Jay Cornwall
struct device_process_node was allocated during process registration but
not released at process deregistration.
Signed-off-by: Jay Cornwall
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 718f50e..bc8961c3 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -409,6 +409,7 @@ static int unregister_process_nocpsch(struct
device_queue_manager *dqm,
list_for_each_entry_safe(cur, next, &dqm->queues, list) {
if (qpd == cur->qpd) {
list_del(&cur->list);
+ kfree(cur);
dqm->processes_count--;
goto out;
}
--
2.1.0
[PATCH 08/12] amdkfd: add __iomem attribute to doorbell_ptr
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.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 9 -
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
index 424ddcc..5055fc9 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
@@ -66,8 +66,7 @@ static bool initialize(struct kernel_queue *kq, struct
kfd_dev *dev,
if (kq->mqd == NULL)
return false;
- prop.doorbell_ptr =
- (uint32_t *)kfd_get_kernel_doorbell(dev, &prop.doorbell_off);
+ prop.doorbell_ptr = kfd_get_kernel_doorbell(dev, &prop.doorbell_off);
if (prop.doorbell_ptr == NULL)
goto err_get_kernel_doorbell;
@@ -172,7 +171,7 @@ err_rptr_allocate_vidmem:
kfd2kgd->free_mem(dev->kgd, (struct kgd_mem *) kq->pq);
err_pq_allocate_vidmem:
pr_err("kfd: error init pq\n");
- kfd_release_kernel_doorbell(dev, (u32 *)prop.doorbell_ptr);
+ kfd_release_kernel_doorbell(dev, prop.doorbell_ptr);
err_get_kernel_doorbell:
pr_err("kfd: error init doorbell");
return false;
@@ -195,7 +194,7 @@ static void uninitialize(struct kernel_queue *kq)
kfd2kgd->free_mem(kq->dev->kgd, (struct kgd_mem *) kq->wptr_mem);
kfd2kgd->free_mem(kq->dev->kgd, (struct kgd_mem *) kq->pq);
kfd_release_kernel_doorbell(kq->dev,
- (u32 *)kq->queue->properties.doorbell_ptr);
+ kq->queue->properties.doorbell_ptr);
uninit_queue(kq->queue);
}
@@ -255,7 +254,7 @@ static void submit_packet(struct kernel_queue *kq)
#endif
*kq->wptr_kernel = kq->pending_wptr;
- write_kernel_doorbell((u32 *)kq->queue->properties.doorbell_ptr,
+ write_kernel_doorbell(kq->queue->properties.doorbell_ptr,
kq->pending_wptr);
}
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index 41e608d..d0bcafc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -279,7 +279,7 @@ struct queue_properties {
uint32_t queue_percent;
uint32_t *read_ptr;
uint32_t *write_ptr;
- uint32_t *doorbell_ptr;
+ uint32_t __iomem *doorbell_ptr;
uint32_t doorbell_off;
bool is_interop;
bool is_active;
--
2.1.0
[PATCH 07/12] amdkfd: fence_wait_timeout() can be static
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 8c40d04..718f50e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -789,8 +789,9 @@ out:
return retval;
}
-int fence_wait_timeout(unsigned int *fence_addr, unsigned int fence_value,
- unsigned long timeout)
+static int fence_wait_timeout(unsigned int *fence_addr,
+ unsigned int fence_value,
+ unsigned long timeout)
{
BUG_ON(!fence_addr);
timeout += jiffies;
--
2.1.0
[PATCH 06/12] amdkfd: is_occupied() can be static
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
index 59d2407..adc3147 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
@@ -179,9 +179,9 @@ static int destroy_mqd(struct mqd_manager *mm, void *mqd,
pipe_id, queue_id);
}
-bool is_occupied(struct mqd_manager *mm, void *mqd,
- uint64_t queue_address, uint32_t pipe_id,
- uint32_t queue_id)
+static bool is_occupied(struct mqd_manager *mm, void *mqd,
+ uint64_t queue_address, uint32_t pipe_id,
+ uint32_t queue_id)
{
return kfd2kgd->hqd_is_occupies(mm->dev->kgd, queue_address,
--
2.1.0
[PATCH 05/12] amdkfd: Fix sparse warnings in kfd_flat_memory.c
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c
b/drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c
index 2dfc4c0..66df4da 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c
@@ -276,21 +276,22 @@
*/
#define MAKE_GPUVM_APP_BASE(gpu_num) \
- (((uint64_t)(gpu_num) << 61) + 0x1)
+ (((uint64_t)(gpu_num) << 61) + 0x1L)
#define MAKE_GPUVM_APP_LIMIT(base) \
- (((uint64_t)(base) & 0xFF00) | 0xFF)
+ (((uint64_t)(base) & \
+ 0xFF00UL) | 0xFFL)
#define MAKE_SCRATCH_APP_BASE(gpu_num) \
- (((uint64_t)(gpu_num) << 61) + 0x1)
+ (((uint64_t)(gpu_num) << 61) + 0x1L)
#define MAKE_SCRATCH_APP_LIMIT(base) \
- (((uint64_t)base & 0x) | 0x)
+ (((uint64_t)base & 0xUL) | 0x)
#define MAKE_LDS_APP_BASE(gpu_num) \
(((uint64_t)(gpu_num) << 61) + 0x0)
#define MAKE_LDS_APP_LIMIT(base) \
- (((uint64_t)(base) & 0x) | 0x)
+ (((uint64_t)(base) & 0xUL) | 0x)
int kfd_init_apertures(struct kfd_process *process)
{
--
2.1.0
[PATCH 04/12] amdkfd: pqm_get_kernel_queue() can be static
From: kbuild test robot
Signed-off-by: Fengguang Wu
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
index c7859fc..de2c163 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
@@ -325,7 +325,8 @@ int pqm_update_queue(struct process_queue_manager *pqm,
unsigned int qid,
return 0;
}
-struct kernel_queue *pqm_get_kernel_queue(struct process_queue_manager *pqm,
+static __attribute__((unused)) struct kernel_queue *pqm_get_kernel_queue(
+ struct process_queue_manager *pqm,
unsigned int qid)
{
struct process_queue_node *pqn;
--
2.1.0
[PATCH 03/12] amdkfd: test_kq() can be static
From: kbuild test robot
Signed-off-by: Fengguang Wu
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
index 555af45..424ddcc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
@@ -321,7 +321,7 @@ void kernel_queue_uninit(struct kernel_queue *kq)
kfree(kq);
}
-void test_kq(struct kfd_dev *dev)
+static __attribute__((unused)) void test_kq(struct kfd_dev *dev)
{
struct kernel_queue *kq;
uint32_t *buffer, i;
--
2.1.0
[PATCH 02/12] amdkfd: Fix sparse warnings in kfd_topology.c
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 40 +++
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index 77cd7d5..5733e28 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -96,7 +96,7 @@ static int kfd_topology_get_crat_acpi(void *crat_image,
size_t *size)
return -EINVAL;
}
- if (*size >= crat_table->length && crat_image != 0)
+ if (*size >= crat_table->length && crat_image != NULL)
memcpy(crat_image, crat_table, crat_table->length);
*size = crat_table->length;
@@ -183,7 +183,7 @@ static int kfd_parse_subtype_mem(struct crat_subtype_memory
*mem)
list_for_each_entry(dev, &topology_device_list, list) {
if (mem->promixity_domain == i) {
props = kfd_alloc_struct(props);
- if (props == 0)
+ if (props == NULL)
return -ENOMEM;
if (dev->node_props.cpu_cores_count == 0)
@@ -231,7 +231,7 @@ static int kfd_parse_subtype_cache(struct
crat_subtype_cache *cache)
if (id == dev->node_props.cpu_core_id_base ||
id == dev->node_props.simd_id_base) {
props = kfd_alloc_struct(props);
- if (props == 0)
+ if (props == NULL)
return -ENOMEM;
props->processor_id_low = id;
@@ -282,7 +282,7 @@ static int kfd_parse_subtype_iolink(struct
crat_subtype_iolink *iolink)
list_for_each_entry(dev, &topology_device_list, list) {
if (id_from == i) {
props = kfd_alloc_struct(props);
- if (props == 0)
+ if (props == NULL)
return -ENOMEM;
props->node_from = id_from;
@@ -415,9 +415,9 @@ static struct kfd_topology_device
*kfd_create_topology_device(void)
struct kfd_topology_device *dev;
dev = kfd_alloc_struct(dev);
- if (dev == 0) {
+ if (dev == NULL) {
pr_err("No memory to allocate a topology device");
- return 0;
+ return NULL;
}
INIT_LIST_HEAD(&dev->mem_props);
@@ -428,7 +428,7 @@ static struct kfd_topology_device
*kfd_create_topology_device(void)
sys_props.num_devices++;
return dev;
- }
+}
static int kfd_parse_crat_table(void *crat_image)
{
@@ -752,11 +752,11 @@ static void kfd_remove_sysfs_node_entry(struct
kfd_topology_device *dev)
if (iolink->kobj) {
kfd_remove_sysfs_file(iolink->kobj,
&iolink->attr);
- iolink->kobj = 0;
+ iolink->kobj = NULL;
}
kobject_del(dev->kobj_iolink);
kobject_put(dev->kobj_iolink);
- dev->kobj_iolink = 0;
+ dev->kobj_iolink = NULL;
}
if (dev->kobj_cache) {
@@ -764,22 +764,22 @@ static void kfd_remove_sysfs_node_entry(struct
kfd_topology_device *dev)
if (cache->kobj) {
kfd_remove_sysfs_file(cache->kobj,
&cache->attr);
- cache->kobj = 0;
+ cache->kobj = NULL;
}
kobject_del(dev->kobj_cache);
kobject_put(dev->kobj_cache);
- dev->kobj_cache = 0;
+ dev->kobj_cache = NULL;
}
if (dev->kobj_mem) {
list_for_each_entry(mem, &dev->mem_props, list)
if (mem->kobj) {
kfd_remove_sysfs_file(mem->kobj, &mem->attr);
- mem->kobj = 0;
+ mem->kobj = NULL;
}
kobject_del(dev->kobj_mem);
kobject_put(dev->kobj_mem);
- dev->kobj_mem = 0;
+ dev->kobj_mem = NULL;
}
if (dev->kobj_node) {
@@ -788,7 +788,7 @@ static void kfd_remove_sysfs_node_entry(struct
kfd_topology_device *dev)
sysfs_remove_file(dev->kobj_node, &dev->attr_props);
kobject_del(dev->kobj_node);
kobject_put(dev->kobj_node);
- dev->kobj_node = 0;
+ dev->kobj_node = NULL;
}
}
@@ -939,7 +939,7 @@ static int kfd_topology_update_sysfs(void)
int ret;
pr_info("Creating topology SYSFS entries\n");
- if (sys_props.kobj_topology == 0) {
+ if (sys_props.kobj_topology
[PATCH 01/12] amdkfd: Fix sparse warnings in kfd_chardev.c
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 64c73ba..3b3fce7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -149,7 +149,9 @@ static int set_queue_properties_from_user(struct
queue_properties *q_properties,
}
if ((args->ring_base_address) &&
- (!access_ok(VERIFY_WRITE, args->ring_base_address,
sizeof(uint64_t {
+ (!access_ok(VERIFY_WRITE,
+ (const void __user *) args->ring_base_address,
+ sizeof(uint64_t {
pr_err("kfd: can't access ring base address\n");
return -EFAULT;
}
@@ -159,12 +161,16 @@ static int set_queue_properties_from_user(struct
queue_properties *q_properties,
return -EINVAL;
}
- if (!access_ok(VERIFY_WRITE, args->read_pointer_address,
sizeof(uint32_t))) {
+ if (!access_ok(VERIFY_WRITE,
+ (const void __user *) args->read_pointer_address,
+ sizeof(uint32_t))) {
pr_err("kfd: can't access read pointer\n");
return -EFAULT;
}
- if (!access_ok(VERIFY_WRITE, args->write_pointer_address,
sizeof(uint32_t))) {
+ if (!access_ok(VERIFY_WRITE,
+ (const void __user *) args->write_pointer_address,
+ sizeof(uint32_t))) {
pr_err("kfd: can't access write pointer\n");
return -EFAULT;
}
@@ -325,7 +331,9 @@ static int kfd_ioctl_update_queue(struct file *filp, struct
kfd_process *p,
}
if ((args.ring_base_address) &&
- (!access_ok(VERIFY_WRITE, args.ring_base_address,
sizeof(uint64_t {
+ (!access_ok(VERIFY_WRITE,
+ (const void __user *) args.ring_base_address,
+ sizeof(uint64_t {
pr_err("kfd: can't access ring base address\n");
return -EFAULT;
}
--
2.1.0
[PATCH 00/12] amdkfd fixes (sparse and some more)
Hi, This patch-set contains mostly fixes for sparse warnings. In addition, there is a fix for a memory leak, for suspend operation and a patch that prevents the blocking of IOMMU PPR handling while waiting to sync with hw Oded Alexey Skidanov (1): amdkfd: Instead of using get function, use container_of Jay Cornwall (1): amdkfd: Fix memory leak on process deregistration Oded Gabbay (8): amdkfd: Fix sparse warnings in kfd_chardev.c amdkfd: Fix sparse warnings in kfd_topology.c amdkfd: Fix sparse warnings in kfd_flat_memory.c amdkfd: is_occupied() can be static amdkfd: fence_wait_timeout() can be static amdkfd: add __iomem attribute to doorbell_ptr amdkfd: use schedule() in sync_with_hw amdkfd: Clear ctx cb before suspend kbuild test robot (2): amdkfd: test_kq() can be static amdkfd: pqm_get_kernel_queue() can be static drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 16 ++--- drivers/gpu/drm/amd/amdkfd/kfd_device.c| 1 + .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 27 +++ drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c | 11 +++--- drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 14 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 6 ++-- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 4 ++- .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 3 +- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 40 +++--- 9 files changed, 67 insertions(+), 55 deletions(-) -- 2.1.0
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #54 from John --- Please forget my last 2 comments, I still get these messages in the terminal, so there's obviously an issue there, but I found some game workarounds that allow me to play the game, so I guess these messages are unrelated to my issue. Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/e2ad202f/attachment-0001.html>
[PATCH 00/12] amdkfd fixes (sparse and some more)
On Fri, Nov 21, 2014 at 3:38 AM, Oded Gabbay wrote: > Hi, > This patch-set contains mostly fixes for sparse warnings. > In addition, there is a fix for a memory leak, for suspend operation and > a patch that prevents the blocking of IOMMU PPR handling while waiting > to sync with hw Series is: Reviewed-by: Alex Deucher > > Oded > > Alexey Skidanov (1): > amdkfd: Instead of using get function, use container_of > > Jay Cornwall (1): > amdkfd: Fix memory leak on process deregistration > > Oded Gabbay (8): > amdkfd: Fix sparse warnings in kfd_chardev.c > amdkfd: Fix sparse warnings in kfd_topology.c > amdkfd: Fix sparse warnings in kfd_flat_memory.c > amdkfd: is_occupied() can be static > amdkfd: fence_wait_timeout() can be static > amdkfd: add __iomem attribute to doorbell_ptr > amdkfd: use schedule() in sync_with_hw > amdkfd: Clear ctx cb before suspend > > kbuild test robot (2): > amdkfd: test_kq() can be static > amdkfd: pqm_get_kernel_queue() can be static > > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 16 ++--- > drivers/gpu/drm/amd/amdkfd/kfd_device.c| 1 + > .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 27 +++ > drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c | 11 +++--- > drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 14 > drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 6 ++-- > drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 4 ++- > .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 3 +- > drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 40 > +++--- > 9 files changed, 67 insertions(+), 55 deletions(-) > > -- > 2.1.0 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
randconfig build error with next-20141121, in drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
Building with the attached random configuration file, drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c: In function âkfd_doorbell_initâ: drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c:97:2: error: implicit declaration of function âioremapâ [-Werror=implicit-function-declaration] kfd->doorbell_kernel_ptr = ioremap(kfd->doorbell_base, ^ drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c:97:27: warning: assignment makes pointer from integer without a cast [enabled by default] kfd->doorbell_kernel_ptr = ioremap(kfd->doorbell_base, ^ drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c: In function âwrite_kernel_doorbellâ: drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c:217:3: error: implicit declaration of function âwritelâ [-Werror=implicit-function-declaration] writel(value, db); ^ cc1: some warnings being treated as errors make[4]: *** [drivers/gpu/drm/amd/amdkfd/kfd_doorbell.o] Error 1 -- next part -- # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.18.0-rc5 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_FHANDLE is not set CONFIG_USELIB=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # # RCU Subsystem # CONFIG_TINY_RCU=y CONFIG_TASKS_RCU=y # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_MEMCG is not set CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set CONFIG_CHECKPOINT_RESTORE=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y # CONFIG_RD_LZ4 is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_LTO_MENU=y # CONFIG_LTO_DISABLE is not set CONF
[RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers
On 11/20/2014 03:37 PM, Inki Dae wrote:
> On 2014ë
11ì 20ì¼ 23:23, Andrzej Hajda wrote:
>> On 11/20/2014 02:56 PM, Inki Dae wrote:
>>> On 2014ë
11ì 20ì¼ 22:19, Andrzej Hajda wrote:
On 11/20/2014 11:24 AM, Inki Dae wrote:
> This patch makes kms drivers to be independent drivers.
> For this, it removes all register codes to kms drivers
> from exynos_drm_drv module and adds module_init/exit
> for each kms driver so that each kms driver can be
> called independently.
>
> Changelog v3:
> - Use module_platform_driver macro instead module_init/exit.
> - Configure all kms drivers to be built in kernel image.
>
> Changelog v2:
> - none
>
> Signed-off-by: Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c |2 ++
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 43
> +++---
> drivers/gpu/drm/exynos/exynos_drm_drv.h |5
> drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 ++
> drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
> drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
> drivers/gpu/drm/exynos/exynos_mixer.c|2 ++
> 7 files changed, 13 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index ed818b9..30ebf5d 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = {
> },
> };
>
> +module_platform_driver(dp_driver);
If you try to build exynosdrm as module you will receive errors due to
multiple definitions of init_module, ie module_init/module_*_driver
macros can be used once per module.
>>> Ah, right. we had ever tried same way before but failed in same problem.
>>> I didn't realize that. Anyway, I will try to find out a better way. I'd
>>> really like to remove all register codes of sub drivers from
>>> exynos_drm_drv somehow.
>> I have proposed once solution with sparse arrays, using linker scripts
>> [1]. Something similar is used with clock controllers as I remember.
>> I do not see other possibilities to fully separate components of
>> exynos_drm_drv.
>>
>> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/103816
>>
> I know this patch. I wasn't sure that the use of the private linker
> section is reasonable and overuse it. Actually, Mr. Park opposed this
> way. It might be a good idea if no problem for device drivers use the
> private linker section. Is there any device driver using the private
> linker section?
No, there are no dev drivers using it, but it is hardly used anyway.
Quick look at include/asm-generic/vmlinux.lds.h shows following sparse
arrays:
#define CLKSRC_OF_TABLES() OF_TABLE(CONFIG_CLKSRC_OF, clksrc)
#define IRQCHIP_OF_MATCH_TABLE() OF_TABLE(CONFIG_IRQCHIP, irqchip)
#define CLK_OF_TABLES() OF_TABLE(CONFIG_COMMON_CLK, clk)
#define RESERVEDMEM_OF_TABLES() OF_TABLE(CONFIG_OF_RESERVED_MEM,
reservedmem)
#define CPU_METHOD_OF_TABLES() OF_TABLE(CONFIG_SMP, cpu_method)
#define EARLYCON_OF_TABLES()OF_TABLE(CONFIG_SERIAL_EARLYCON, earlycon)
The number of arrays slowly grows over time, so some day they can start
appear in drivers as well :)
Such array in driver doesn't look like much different to me, it is just
a workaround for language limitations,
but it would be good to have an opinion of people more involved in
linker scripts.
On the other side having list of component drivers in exynos_drm_drv and
registering them
in module init maybe is not pretty, but it does the same thing and is
quite clear and standard.
Regards
Andrzej
>
> Thanks,
> Inki Dae
>
>> Regards
>> Andrzej
>>
Anyway I am afraid exynosdrm seems to be still fragile to order of
successful probes of their components.
It can be easily observed on the system with two display pipelines with
one of them probe deferring. For example universal with fimd/dpi + vidi:
1. fimd defers probe because panel is not yet probed.
2. vidi probes ok.
3. drmdev is initialized.
4. fimd probes ok, but it is too late!!!
So you can reproduce the scenario on any target when one of the
components defers and vidi is present (vidi never defers I suppose).
>>> Thanks for checking,
>>> Inki Dae
>>>
Regards
Andrzej
> +
> MODULE_AUTHOR("Jingoo Han ");
> MODULE_DESCRIPTION("Samsung SoC DP Driver");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index eab12f0..02d4772 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -484,12 +484,6 @@ static struct component_match
> *exynos_drm_match_add(struct device *dev)
>
> mutex_lock(&drm_component_lock);
>
[PATCH] drm_atomic_helper: Copy/paste fix for calling already disabled planes
On Thu, Nov 20, 2014 at 07:59:15PM -0800, Jasper St. Pierre wrote: > This code was in drm_plane_helper, but missing from drm_atomic_helper, > causing various crashes when the plane was already disabled. Just copy > over the quick return there to prevent a crash. > > Signed-off-by: Jasper St. Pierre > Reviewed-by: Rob Clark > Cc: Daniel Vetter > --- > drivers/gpu/drm/drm_atomic_helper.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index fad2b93..d96dac3 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1246,6 +1246,11 @@ int drm_atomic_helper_disable_plane(struct drm_plane > *plane) > struct drm_plane_state *plane_state; > int ret = 0; > > + /* crtc helpers love to call disable functions for already disabled hw > + * functions. So cope with that. */ Comment here is misleading since this isn't called by the crtc helpers but directly by the drm core code to handle the setplane ioctl. Now the real problem with this is that it's at the wrong spot. If we really need to filter this then it should be done in the atomic_commit function as a noop and not here. This is just the legacy ->disable_plane entry hook, userspace could still throw multiple disable plane calls at the driver. And they would get past this check. As-is it's actually a design feature of the atomic plane helpers that they don't filter out any no-op updates, but just pass the new state into the ->atomic_update hook (through the plane->state pointer). We could extend that (Thierry is iirc working ona an ->atomic_disable callback), and then it would make sense to have some filtering in the helpers. But if we add that it must be done in drm_atomic_helper_commit_planes not here. So NACKed from me. -Daniel > + if (!plane->crtc) > + return 0; > + > state = drm_atomic_state_alloc(plane->dev); > if (!state) > return -ENOMEM; > -- > 2.1.0 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/vgem: implement virtual GEM
On Thu, Nov 20, 2014 at 04:26:16PM -0800, Zach Reizner wrote:
> This patch implements the virtual GEM driver with PRIME sharing which
> allows vgem to import a gem object from other drivers for the purpose
> of mmap-ing them to userspace.
>
> Reviewed-by: Stéphane Marchesin
> Signed-off-by: Adam Jackson
> Signed-off-by: Ben Widawsky
> Signed-off-by: Zach Reizner
Awesome that someone resurrects this, I still like the idea (after all
I've suggested this to Ben ages ago). Bunch of comments below to update
the driver to latest drm changes. Whit those address this looks good.
Cheers, Daniel
> ---
> drivers/gpu/drm/Kconfig | 9 +
> drivers/gpu/drm/Makefile| 1 +
> drivers/gpu/drm/vgem/Makefile | 4 +
> drivers/gpu/drm/vgem/vgem_dma_buf.c | 169 +++
> drivers/gpu/drm/vgem/vgem_drv.c | 407
>
> drivers/gpu/drm/vgem/vgem_drv.h | 62 ++
> 6 files changed, 652 insertions(+)
> create mode 100644 drivers/gpu/drm/vgem/Makefile
> create mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
> create mode 100644 drivers/gpu/drm/vgem/vgem_drv.c
> create mode 100644 drivers/gpu/drm/vgem/vgem_drv.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index e3b4b0f..39909bc 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -165,6 +165,15 @@ config DRM_SAVAGE
> Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
> chipset. If M is selected the module will be called savage.
>
> +config DRM_VGEM
> + tristate "Virtual GEM provider"
> + depends on DRM
> + help
> + Choose this option to get a virtual graphics memory manager,
> + as used by Mesa's software renderer for enhanced performance.
> + If M is selected the module will be called vgem.
> +
> +
> source "drivers/gpu/drm/exynos/Kconfig"
>
> source "drivers/gpu/drm/vmwgfx/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index c3cf64c..c1e4a0e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_DRM_SIS) += sis/
> obj-$(CONFIG_DRM_SAVAGE)+= savage/
> obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
> obj-$(CONFIG_DRM_VIA)+=via/
> +obj-$(CONFIG_DRM_VGEM) += vgem/
> obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
> obj-$(CONFIG_DRM_EXYNOS) +=exynos/
> obj-$(CONFIG_DRM_GMA500) += gma500/
> diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
> new file mode 100644
> index 000..1055cb7
> --- /dev/null
> +++ b/drivers/gpu/drm/vgem/Makefile
> @@ -0,0 +1,4 @@
> +ccflags-y := -Iinclude/drm
> +vgem-y := vgem_drv.o vgem_dma_buf.o
> +
> +obj-$(CONFIG_DRM_VGEM) += vgem.o
> diff --git a/drivers/gpu/drm/vgem/vgem_dma_buf.c
> b/drivers/gpu/drm/vgem/vgem_dma_buf.c
> new file mode 100644
> index 000..8450124
> --- /dev/null
> +++ b/drivers/gpu/drm/vgem/vgem_dma_buf.c
> @@ -0,0 +1,169 @@
> +/*
> + * Copyright © 2012 Intel Corporation
> + * Copyright © 2014 The Chromium OS Authors
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Ben Widawsky
> + *
> + */
> +
> +#include
> +#include "vgem_drv.h"
> +
> +#define VGEM_FD_PERMS 0600
> +
> +static struct sg_table *vgem_gem_map_dma_buf(struct dma_buf_attachment
> *attach,
> + enum dma_data_direction dir)
> +{
> + struct drm_vgem_gem_object *obj = attach->dmabuf->priv;
> + struct sg_table *sg;
> + int ret;
> +
> + ret = vgem_gem_get_pages(obj);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + /* VGEM assumes cache coherent access. Normally we might have to flush
> + * caches here */
> +
> + BUG_ON(obj->pages == NULL);
> +
> + sg = drm_prime_pages_to_sg(obj->pages, obj->base.size / PAGE_SIZE);
> + if (!sg) {
[PATCH] drm/vgem: implement virtual GEM
On Thu, 2014-11-20 at 16:26 -0800, Zach Reizner wrote: > This patch implements the virtual GEM driver with PRIME sharing which > allows vgem to import a gem object from other drivers for the purpose > of mmap-ing them to userspace. The reason I initially wanted this was to get zero-copy llvmpipe, since (besides making GLX conformance impossible) the image transfer parts of drisw are easily the biggest part of the runtime overhead. Is there a userspace consumer of this anywhere? - ajax
[RFC] drm: add plane iterator macros
Inspired in part by some cute iterator macros I noticed in i915. I
currently have these in drm/msm, but seems like they should be useful
for others. Quite possibly other iterators would be useful to add for
other drivers.
Signed-off-by: Rob Clark
---
NOTE: to actually merge this, depending on the order this is merged
vs drm/msm/mdp5 atomic support, these would have to be removed from
msm_kms.h.
include/drm/drm_crtc.h | 28
1 file changed, 28 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bc1cc3c..5ea46ec 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -773,6 +773,34 @@ struct drm_plane {
struct drm_plane_state *state;
};
+/* iterate over the planes *currently* attached to a crtc, useful
+ * to apply current state to hw:
+ */
+#define for_each_plane_on_crtc(_crtc, _plane) \
+ list_for_each_entry((_plane), &(_crtc)->dev->mode_config.plane_list,
head) \
+ if ((_plane)->state->crtc == (_crtc))
+
+static inline bool
+__plane_will_be_attached_to_crtc(struct drm_atomic_state *state,
+ struct drm_plane *plane, struct drm_crtc *crtc)
+{
+ int idx = drm_plane_index(plane);
+
+ /* if plane is modified in incoming state, use the new state: */
+ if (state->plane_states[idx])
+ return state->plane_states[idx]->crtc == crtc;
+
+ /* otherwise, current state: */
+ return plane->state->crtc == crtc;
+}
+
+/* iterate over the planes that *will be* attached to a crtc,
+ * useful for ->atomic_check() operations:
+ */
+#define for_each_pending_plane_on_crtc(_state, _crtc, _plane) \
+ list_for_each_entry((_plane), &(_crtc)->dev->mode_config.plane_list,
head) \
+ if (__plane_will_be_attached_to_crtc((_state), (_plane),
(_crtc)))
+
/**
* struct drm_bridge_funcs - drm_bridge control functions
* @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
--
1.9.3
[PATCH] drm_atomic_helper: Copy/paste fix for calling already disabled planes
On Fri, Nov 21, 2014 at 3:31 AM, Daniel Vetter wrote: > On Thu, Nov 20, 2014 at 07:59:15PM -0800, Jasper St. Pierre wrote: >> This code was in drm_plane_helper, but missing from drm_atomic_helper, >> causing various crashes when the plane was already disabled. Just copy >> over the quick return there to prevent a crash. >> >> Signed-off-by: Jasper St. Pierre >> Reviewed-by: Rob Clark >> Cc: Daniel Vetter >> --- >> drivers/gpu/drm/drm_atomic_helper.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c >> b/drivers/gpu/drm/drm_atomic_helper.c >> index fad2b93..d96dac3 100644 >> --- a/drivers/gpu/drm/drm_atomic_helper.c >> +++ b/drivers/gpu/drm/drm_atomic_helper.c >> @@ -1246,6 +1246,11 @@ int drm_atomic_helper_disable_plane(struct drm_plane >> *plane) >> struct drm_plane_state *plane_state; >> int ret = 0; >> >> + /* crtc helpers love to call disable functions for already disabled hw >> + * functions. So cope with that. */ > > Comment here is misleading since this isn't called by the crtc helpers but > directly by the drm core code to handle the setplane ioctl. > > Now the real problem with this is that it's at the wrong spot. If we > really need to filter this then it should be done in the atomic_commit > function as a noop and not here. This is just the legacy ->disable_plane > entry hook, userspace could still throw multiple disable plane calls at > the driver. And they would get past this check. > > As-is it's actually a design feature of the atomic plane helpers that they > don't filter out any no-op updates, but just pass the new state into the > ->atomic_update hook (through the plane->state pointer). We could extend > that (Thierry is iirc working ona an ->atomic_disable callback), and then > it would make sense to have some filtering in the helpers. But if we add > that it must be done in drm_atomic_helper_commit_planes not here. I guess I'm (a) not entirely sure what the point of a no-op disable is, and (b) quite sure how you plane to make a 'drm_modeset_legacy_acquire_ctx(plane->crtc)' work if plane->crtc is NULL.. BR, -R > So NACKed from me. > -Daniel > >> + if (!plane->crtc) >> + return 0; >> + >> state = drm_atomic_state_alloc(plane->dev); >> if (!state) >> return -ENOMEM; >> -- >> 2.1.0 >> > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
2014-11-21 0:26 GMT+09:00 Javier Martinez Canillas : > Hello Inki, > > On 11/20/2014 04:06 PM, Inki Dae wrote: >>> BTW, it would be great if exynos-drm-next is pulled in linux-next. That is >>> what most people use to test integration issues so you can catch earlier any >>> regression that may arise. >>> >>> You have to email Stephen Rothwell and point to >>> your >>> tree and branch and he will be able to add it to linux-next. >> >> Thanks for information. Actually, I received a similar email privately >> before. However, exynos-drm-next should go to drm-next first and than to >> mainline by Dave who is DRM subsystem maintainer. I think all vendor >> specific drm drivers would need to be checked by drm subsystem >> maintainer because these changes might be affect drm subsystem or other >> vendor specific drm drivers before go to mainline. >> > > This is orthogonal to the normal upstreaming path. linux-next is an > integration > tree that is created daily. So all the remote branches are merged and a git > tag > published. The branch does not get rebased and history is not preserved > between > two published linux-next tags. > > This is just to test the integration of different subsystems to be sure that a > commit in one tree does not cause a regression in another one so issues can be > spot earlier. For example in the case of $subject, a change in the OF caused a > regression in the Exynos DRM driver. > >> If needed, I will make a new branch, which is based on top of linux-next >> so other people can check their systems. >> > > You don't really need another branch, git will take care of merge everything > in linux-next :) Ah, sorry. There was my misunderstanding. drm-next already is merged to linux-next so I think we can do the integration test if exynos-drm-next is merged to drm-next earlier. Anyway, I will try to consider your opinion. Thanks, Inki Dae > >> Thanks, >> Inki Dae >> > > Best regards, > Javier > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] intel: Fix decode of Gen7 3DSTATE_VERTEX_BUFFERS
Buffer index / access mode bits are the same as on Gen6.
Signed-off-by: Chris Forbes
---
intel/intel_decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 7d5cbe5..adda29a 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -3383,7 +3383,7 @@ decode_3d_965(struct drm_intel_decode *ctx)
for (i = 1; i < len;) {
int idx, access;
- if (IS_GEN6(devid)) {
+ if (IS_GEN6(devid) || IS_GEN7(devid)) {
idx = 26;
access = 20;
} else {
--
2.1.3
[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
On Thu, Nov 20, 2014 at 10:22:54AM -0800, Kevin Hilman wrote: > Javier Martinez Canillas writes: > > > Hello, > > > > For completeness I'll comment what we talked with Kevin on IRC > > since probably this is the same issue that Paolo is facing. > > > > On 11/20/2014 05:41 PM, Kevin Hilman wrote: > >> Peach # setenv preboot "usb start; sleep 1"setenv bootargs > >> console=tty1 console=ttySAC3,115200 debug earlyprintk rw > >> root=/dev/mmcblk1p3 rootwait rootfstype=ext3 > > > > My kernel command line is almost the same with the difference that I'm using > > clk_ignore_unused and I just checked that not passing that parameter, makes > > linux-next to hang showing the same output log that Kevin reported. > > Ah! Good find. I confirm that adding clk_ignore_unused is getting me > booting again, but of course that is just masking a problem, so I hope > someone can shed light on which clock isn't being correctly managed. > > Might I also suggest that folks have their default command-line to *not* > use clk_ignore_unused, since it's primary job is to workaround clock > bugs. i'm testing kgene/for-next (not linux-next), with: flag at peachpi:~/linux$ cat /proc/cmdline console=tty1 console=ttySAC3,115200 debug earlyprintk rw rootwait root=/dev/mmcblk1p3 adding clk_ignore_unused didn't make any difference: it hangs on boot showing a black screen with backlight on. vanilla kgene/for-next as of today: 7552917 Revert "ARM: exynos_defconfig: Enable options for display panel support" ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 ... plus 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36d908e drm/exynos: dp: Remove support for unused dptx-phy 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices 68944e3 Revert "Revert "ARM: exynos_defconfig: Enable options for display panel support"" vanilla exynos_defconfig with SND_SOC_SNOW disabled. I should probably try linux-next at this point, but i wonder if people who reported kgene/for-next working were testing with a vanilla exynos_defconfig on a peach pi. -- bye, p.
[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi Javier, On 2014ë 11ì 20ì¼ 23:28, Javier Martinez Canillas wrote: > Hello Inki, > > On 11/20/2014 03:07 PM, Inki Dae wrote: >> Could you re-base this patch on top of exynos-drm-next? I tried to >> separate sub drivers into independent drivers but it seems that we need >> more times. So I will merge your patch. >> > > Sure, I'll rebase on top of exynos-drm-next and re-post so you can apply it. > > BTW, it would be great if exynos-drm-next is pulled in linux-next. That is > what most people use to test integration issues so you can catch earlier any > regression that may arise. > > You have to email Stephen Rothwell and point to your > tree and branch and he will be able to add it to linux-next. Thanks for information. Actually, I received a similar email privately before. However, exynos-drm-next should go to drm-next first and than to mainline by Dave who is DRM subsystem maintainer. I think all vendor specific drm drivers would need to be checked by drm subsystem maintainer because these changes might be affect drm subsystem or other vendor specific drm drivers before go to mainline. If needed, I will make a new branch, which is based on top of linux-next so other people can check their systems. Thanks, Inki Dae > >> Thanks, >> Inki Dae >> > > Best regards, > Javier >
