- 30 Aug, 2021 3 commits
-
-
Daniel Vetter authored
It might be good enough on x86 with just READ_ONCE, but the write side should then at least be WRITE_ONCE because x86 has total store order. It's definitely not enough on arm. Fix this proplery, which means - explain the need for the barrier in both places - point at the other side in each comment Also pull out the !sched_list case as the first check, so that the code flow is clearer. While at it sprinkle some comments around because it was very non-obvious to me what's actually going on here and why. Note that we really need full barriers here, at first I thought store-release and load-acquire on ->last_scheduled would be enough, but we actually requiring ordering between that and the queue state. v2: Put smp_rmp() in the right place and fix up comment (Andrey) Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Steven Price <steven.price@arm.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210805104705.862416-4-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Originally drm_sched_job_init was the point of no return, after which drivers really should submit a job. I've split that up, which allows us to fix this issue pretty easily. Only thing we have to take care of is to not skip to error paths after that. Other drivers do this the same for out-fence and similar things. v2: It's not really a bugfix, just an improvement, since all drm_sched_job_arm does is reserve the fence number. And gaps should be fine, as long as the drm_sched_job doesn't escape anywhere at all. For robustness it's still better to align with other drivers here and not bail out after job_arm(). v3: I misplaced drm_sched_job_arm by _one_ line! Thanks to Rob for testing and debug help. Cc: Rob Clark <robdclark@chromium.org> Cc: Rob Clark <robdclark@gmail.com> Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210826093334.1117944-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
This is a very confusingly named function, because not just does it init an object, it arms it and provides a point of no return for pushing a job into the scheduler. It would be nice if that's a bit clearer in the interface. But the real reason is that I want to push the dependency tracking helpers into the scheduler code, and that means drm_sched_job_init must be called a lot earlier, without arming the job. v2: - don't change .gitignore (Steven) - don't forget v3d (Emma) v3: Emma noticed that I leak the memory allocated in drm_sched_job_init if we bail out before the point of no return in subsequent driver patches. To be able to fix this change drm_sched_job_cleanup() so it can handle being called both before and after drm_sched_job_arm(). Also improve the kerneldoc for this. v4: - Fix the drm_sched_job_cleanup logic, I inverted the booleans, as usual (Melissa) - Christian pointed out that drm_sched_entity_select_rq() also needs to be moved into drm_sched_job_arm, which made me realize that the job->id definitely needs to be moved too. Shuffle things to fit between job_init and job_arm. v5: Reshuffle the split between init/arm once more, amdgpu abuses drm_sched.ready to signal gpu reset failures. Also document this somewhat. (Christian) v6: Rebase on top of the msm drm/sched support. Note that the drm_sched_job_init() call is completely misplaced, and hence also the split-out drm_sched_entity_push_job(). I've put in a FIXME which the next patch will address. v7: Drop the FIXME in msm, after discussions with Rob I agree it shouldn't be a problem where it is now. Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Melissa Wen <mwen@igalia.com> Cc: Melissa Wen <melissa.srw@gmail.com> Acked-by: Emma Anholt <emma@anholt.net> Acked-by: Steven Price <steven.price@arm.com> (v2) Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> (v5) Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Qiang Yu <yuq825@gmail.com> Cc: Rob Herring <robh@kernel.org> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Adam Borowski <kilobyte@angband.pl> Cc: Nick Terrell <terrelln@fb.com> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: Paul Menzel <pmenzel@molgen.mpg.de> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Nirmoy Das <nirmoy.das@amd.com> Cc: Deepak R Varma <mh12gx2825@gmail.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: Kevin Wang <kevin1.wang@amd.com> Cc: Chen Li <chenli@uniontech.com> Cc: Luben Tuikov <luben.tuikov@amd.com> Cc: "Marek Olšák" <marek.olsak@amd.com> Cc: Dennis Li <Dennis.Li@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: Sonny Jiang <sonny.jiang@amd.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Tian Tao <tiantao6@hisilicon.com> Cc: etnaviv@lists.freedesktop.org Cc: lima@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: Emma Anholt <emma@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20210817084917.3555822-1-daniel.vetter@ffwll.ch
-
- 29 Aug, 2021 1 commit
-
-
Alyssa Rosenzweig authored
Minor typofix noticed when reading the KMS documentation. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20210829160401.4588-1-alyssa@rosenzweig.io
-
- 28 Aug, 2021 1 commit
-
-
F.A.Sulaiman authored
This patch fixes style issues in drm_ioctl.c Signed-off-by: F.A.Sulaiman <asha.16@itfac.mrt.ac.lk> Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20210828123942.1556-1-asha.16@itfac.mrt.ac.lk
-
- 27 Aug, 2021 2 commits
-
-
Christian König authored
Switch back to using a spinlock again by moving the IOMMU unmap outside of the locked region. This avoids contention especially while freeing pages. v2: Add a comment explaining why we need sync_shrinkers(). Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210820120528.81114-3-christian.koenig@amd.com
-
Christian König authored
While unplugging a device the TTM shrinker implementation needs a barrier to make sure that all concurrent shrink operations are done and no other CPU is referring to a device specific pool any more. Taking and releasing the shrinker semaphore on the write side after unmapping and freeing all pages from the device pool should make sure that no shrinker is running in paralell. This allows us to avoid the contented mutex in the TTM pool implementation for every alloc/free operation. v2: rework the commit message to make clear why we need this v3: rename the function and add more doc as suggested by Daniel Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Acked-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210820120528.81114-2-christian.koenig@amd.com
-
- 26 Aug, 2021 7 commits
-
-
Philip Chen authored
Reorg the macros as follows: (1) Group the registers on the same page together. (2) Group the register and its bit operation together while indenting the macros of the bit operation with one space. Also fix a misnomer for the number of mipi data lanes. Signed-off-by: Philip Chen <philipchen@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210824181140.v2.1.I8ead7431357409f2526e5739ec5bc3ddfd242243@changeid
-
Lukas Bulwahn authored
Commit 55b68fb8 ("drm/omap: squash omapdrm sub-modules into one") removes the config OMAP2_DSS in ./drivers/gpu/drm/omapdrm/dss/Kconfig, while moving the other configs into./drivers/gpu/drm/omapdrm/Kconfig, but misses to remove an obsolete selection of OMAP2_DSS in config DRM_OMAP. Hence, ./scripts/checkkconfigsymbols.py warns: OMAP2_DSS Referencing files: drivers/gpu/drm/omapdrm/Kconfig Remove this reference in an obsolete selection. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210819112253.16484-6-lukas.bulwahn@gmail.com
-
Lukas Bulwahn authored
Commit 89d4f98a ("ARM: remove zte zx platform") removes the config ARCH_ZX. So, since then, the DRM Support for ZTE SoCs (config DRM_ZTE) depends on this removed config ARCH_ZX and cannot be selected. Fortunately, ./scripts/checkkconfigsymbols.py detects this and warns: ARCH_ZX Referencing files: drivers/gpu/drm/zte/Kconfig So, remove this obsolete DRM support. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210819112253.16484-5-lukas.bulwahn@gmail.com
-
Lukas Bulwahn authored
Commit 57692c94 ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") adds the config DRM_V3D, which depends on "ARCH_BCMSTB". Although, a bit confusing: all Broadcom architectures in ./arch/arm/mach-bcm/Kconfig have the prefix "ARCH_BCM", except for ARCH_BRCMSTB, i.e., the config for Broadcom BCM7XXX based boards. So, correct the reference ARCH_BCMSTB to the intended ARCH_BRCMSTB. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210819112253.16484-4-lukas.bulwahn@gmail.com
-
Lukas Bulwahn authored
commit 1f0f0151 ("drm/rockchip: Add support for Rockchip Soc RGB output interface") accidently adds to select the non-existing config DRM_RGB in ./drivers/gpu/drm/rockchip/Kconfig. Luckily, ./scripts/checkkconfigsymbols.py warns on non-existing configs: DRM_RGB Referencing files: drivers/gpu/drm/rockchip/Kconfig So, remove the reference to the non-existing config DRM_RGB. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210819112253.16484-2-lukas.bulwahn@gmail.com
-
Alyssa Rosenzweig authored
Use upper_32_bits/lower_32_bits helpers instead of open-coding them. This is easier to scan quickly compared to bitwise manipulation, and it is pleasingly symmetric. I noticed this when debugging lock_region, which had a particularly "creative" way of writing upper_32_bits. v2: Use helpers for one more call site and add review tag (Steven). Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Rob Herring <robh@kernel.org> (v1) Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210825153348.4980-1-alyssa.rosenzweig@collabora.com
-
Maxime Ripard authored
Merge tag 'drm-misc-intel-oob-hotplug-v1' of git://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux into drm-misc-next Topic branch for drm-misc / drm-intel for OOB hotplug support for Type-C connectors Signed-off-by: Maxime Ripard <maxime@cerno.tech> # -----BEGIN PGP SIGNATURE----- # # iQFIBAABCAAyFiEEuvA7XScYQRpenhd+kuxHeUQDJ9wFAmEf5msUHGhkZWdvZWRl # QHJlZGhhdC5jb20ACgkQkuxHeUQDJ9xUFQgAtBkpLk/oBn6uRcIXCc8KIGs5NqWG # orVB7c1Ilsd8jdsap6uD2fVVlS7fn5I6hkiyjdRz5A96aLxkF7oCGLATmxGtYd1k # lZTUOLXGdl2ye798vuwaO8UzpN7s2yiIaI44GCGLT5Qwrpq9D1tykY3ggXH/03t2 # Z8xOB+XLKbcibnWVQL/4Fz+cQ3KzJ8lo10oiZ131b1ytwf/zdKx0fA3yrPA9C0Kv # V3dbWxYMWfkO+IUieZgMzl2LrbChp8fC6zmPJYdvlpB7AZXrOKD+4K8JdlKPMZNE # hi5xF4X1tPeTiOo1jju5JN2hnjsc30JuBLemDcV7CLeL01Y4VLdAwHPwyw== # =Zar+ # -----END PGP SIGNATURE----- # gpg: Signature made Fri 20 Aug 2021 07:29:15 PM CEST # gpg: using RSA key BAF03B5D2718411A5E9E177E92EC4779440327DC # gpg: issuer "hdegoede@redhat.com" # gpg: Can't check signature: No public key From: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/34f13e21-9b1a-5f54-7e03-9705a6b51428@redhat.com
-
- 23 Aug, 2021 7 commits
-
-
Krzysztof Kozlowski authored
Correct indentation warning: ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but found 8 (indentation) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210819101020.26368-1-krzysztof.kozlowski@canonical.com
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below. It has been compile tested. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/46ccdd7bffdba1273a1ebb3d6cd2fbe186e0795a.1629667572.git.christophe.jaillet@wanadoo.fr
-
Christian König authored
Move the functionality into ttm_tt_fini and ttm_bo_tt_destroy instead. We don't need this any more since we removed the unbind from the destroy code paths in the drivers. Also add a warning to ttm_tt_fini() if we try to fini a still populated TT object. v2: instead of reverting the patch move the functionality to different places. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728130552.2074-5-christian.koenig@amd.com
-
Christian König authored
Doing this in radeon_ttm_tt_destroy() is to late. It turned out that this is not a good idea at all because it leaves pointers to freed up system memory pages in the GART tables of the drivers. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728130552.2074-4-christian.koenig@amd.com
-
Christian König authored
Doing this in nouveau_ttm_tt_destroy()/nouveau_sgdma_destroy() is to late. It turned out that this is not a good idea at all because it leaves pointers to freed up system memory pages in the GART tables of the drivers. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728130552.2074-3-christian.koenig@amd.com
-
Christian König authored
Doing this in amdgpu_ttm_backend_destroy() is to late. It turned out that this is not a good idea at all because it leaves pointers to freed up system memory pages in the GART tables of the drivers. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728130552.2074-2-christian.koenig@amd.com
-
Christian König authored
Doing this in vmw_ttm_destroy() is to late. It turned out that this is not a good idea at all because it leaves pointers to freed up system memory pages in the GART tables of the drivers. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728130552.2074-1-christian.koenig@amd.com
-
- 20 Aug, 2021 6 commits
-
-
Hans de Goede authored
Use the new drm_connector_oob_hotplug_event() functions to let drm/kms drivers know about DisplayPort over Type-C hotplug events. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20210817215201.795062-9-hdegoede@redhat.com
-
Hans de Goede authored
Make dp_altmode_notify() handle the dp->data.conf == 0 case too, rather then having separate code-paths for this in various places which call it. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20210817215201.795062-8-hdegoede@redhat.com
-
Hans de Goede authored
Add a new drm_connector_oob_hotplug_event() function and oob_hotplug_event drm_connector_funcs member. On some hardware a hotplug event notification may come from outside the display driver / device. An example of this is some USB Type-C setups where the hardware muxes the DisplayPort data and aux-lines but does not pass the altmode HPD status bit to the GPU's DP HPD pin. In cases like this the new drm_connector_oob_hotplug_event() function can be used to report these out-of-band events. Changes in v2: - Make drm_connector_oob_hotplug_event() take a fwnode as argument and have it call drm_connector_find_by_fwnode() internally. This allows making drm_connector_find_by_fwnode() a drm-internal function and avoids code outside the drm subsystem potentially holding on the a drm_connector reference for a longer period. Changes in v3: - Drop the data argument to the drm_connector_oob_hotplug_event function since it is not used atm. This can be re-added later when a use for it actually arises. Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20210817215201.795062-5-hdegoede@redhat.com
-
Hans de Goede authored
Add a function to find a connector based on a fwnode. This will be used by the new drm_connector_oob_hotplug_event() function which is added by the next patch in this patch-set. Changes in v2: - Complete rewrite to use a global connector list in drm_connector.c rather then using a class-dev-iter in drm_sysfs.c Changes in v3: - Add forward declaration for struct fwnode_handle to drm_crtc_internal.h (fixes warning reported by kernel test robot <lkp@intel.com>) Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20210817215201.795062-4-hdegoede@redhat.com
-
Hans de Goede authored
Add a fwnode pointer to struct drm_connector and register an acpi_bus_type for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled). The adding of the fwnode pointer allows drivers to associate a fwnode that represents a connector with that connector. When the new fwnode pointer points to an ACPI-companion, then the new acpi_bus_type will cause the ACPI subsys to bind the device instantiated for the connector with the fwnode by calling acpi_bind_one(). This will result in a firmware_node symlink under /sys/class/card#-<connecter-name>/ which helps to verify that the fwnode-s and connectors are properly matched. Changes in v2: - Make drm_connector_cleanup() call fwnode_handle_put() on connector->fwnode and document this Co-developed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20210817215201.795062-3-hdegoede@redhat.com
-
Hans de Goede authored
Give connector sysfs devices there own device_type, this allows us to check if a device passed to functions dealing with generic devices is a drm_connector or not. A check like this is necessary in the drm_connector_acpi_bus_match() function added in the next patch in this series. Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20210817215201.795062-2-hdegoede@redhat.com
-
- 18 Aug, 2021 3 commits
-
-
Robert Foss authored
During the sp_tx_edid_read() call the return value of sp_tx_edid_read() is ignored, which could cause potential errors to go unhandled. All errors which are returned by sp_tx_edid_read() are handled in anx7625_get_edid(). Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210818171318.1848272-2-robert.foss@linaro.org
-
Robert Foss authored
The return value of sp_tx_rst_aux() is not propagated, which means both compiler warnings and potential errors not being handled. Fixes: 8bdfc5da ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP") Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210818171318.1848272-1-robert.foss@linaro.org
-
Javier Martinez Canillas authored
Commit 6104c370 ("fbcon: Make fbcon a built-time depency for fbdev") changed the FRAMEBUFFER_CONSOLE Kconfig symbol from tristate to bool. But the drm_kms_helper_init() function still attempts to load the fbcon module, even when this is always built-in since the mentioned change. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210818120948.451896-1-javierm@redhat.com
-
- 17 Aug, 2021 4 commits
-
-
Hans de Goede authored
The Chuwi Hi10 Pro uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20210530110428.12994-5-hdegoede@redhat.com
-
Hans de Goede authored
The Samsung Galaxy Book 10.6 uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20210530110428.12994-4-hdegoede@redhat.com
-
Hans de Goede authored
The KD Kurio Smart C15200 2-in-1 uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20210530110428.12994-3-hdegoede@redhat.com
-
Hans de Goede authored
2 improvements to the Lenovo Ideapad D330 panel-orientation quirks: 1. Some versions of the Lenovo Ideapad D330 have a DMI_PRODUCT_NAME of "81H3" and others have "81MD". Testing has shown that the "81MD" also has a 90 degree mounted panel. Drop the DMI_PRODUCT_NAME from the existing quirk so that the existing quirk matches both variants. 2. Some of the Lenovo Ideapad D330 models have a HD (800x1280) screen instead of a FHD (1200x1920) screen (both are mounted right-side-up) add a second Lenovo Ideapad D330 quirk for the HD version. Changes in v2: - Add a new quirk for Lenovo Ideapad D330 models with a HD screen instead of a FHD screen Link: https://github.com/systemd/systemd/pull/18884Acked-by: Simon Ser <contact@emersion.fr> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210530110428.12994-2-hdegoede@redhat.com
-
- 16 Aug, 2021 6 commits
-
-
David Stevens authored
Implement virtgpu specific map_dma_buf callback to support mapping exported vram object dma-bufs. The dma-buf callback is used directly, as vram objects don't have backing pages and thus can't implement the drm_gem_object_funcs.get_sg_table callback. Signed-off-by: David Stevens <stevensd@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210813005441.608293-1-stevensd@chromium.orgSigned-off-by: Gerd Hoffmann <kraxel@redhat.com>
-
Charan Teja Reddy authored
It is expected from the clients to follow the below steps on an imported dmabuf fd: a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf o Here the kernel does some slab allocations, say for dma_buf_attachment and may be some other slab allocation in the dmabuf->ops->attach(). c) Client may need to do dma_buf_map_attachment(). d) Accordingly dma_buf_unmap_attachment() should be called. e) dma_buf_detach () // Clients detach to the dmabuf. o Here the slab allocations made in b) are freed. f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last reference. Now say an erroneous client failed at step c) above thus it directly called dma_buf_put(), step f) above. Considering that it may be the last reference to the dmabuf, buffer will be freed with pending attachments left to the dmabuf which can show up as the 'memory leak'. This should at least be reported as the WARN(). Signed-off-by: Charan Teja Reddy <charante@codeaurora.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1627043468-16381-1-git-send-email-charante@codeaurora.orgSigned-off-by: Christian König <christian.koenig@amd.com>
-
Christian König authored
Entirely unused. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210729070330.41443-1-christian.koenig@amd.com
-
Thierry Reding authored
Rather than open-coding the vendor extraction operation, use the newly introduced helper macro. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210610111236.3814211-3-thierry.reding@gmail.com
-
Thierry Reding authored
Rather than open-coding the vendor extraction operation, use the newly introduced helper macro. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210610111236.3814211-2-thierry.reding@gmail.com
-
Thierry Reding authored
When working with framebuffer modifiers, it can be useful to extract the vendor identifier or check a modifier against a given vendor identifier. Add one macro that extracts the vendor identifier and a helper to check a modifier against a given vendor identifier. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210610111236.3814211-1-thierry.reding@gmail.com
-