Re: [PATCH] efifb: Ensure graphics device for efifb stays at PCI D0
Hi Am 22.02.21 um 08:08 schrieb Kai-Heng Feng: On Mon, Feb 1, 2021 at 11:21 PM Alex Deucher wrote: On Sat, Jan 30, 2021 at 6:27 AM Kai-Heng Feng wrote: We are seeing root ports on some desktop boards support D3cold for discrete graphics card. So when efifb is in use while graphics device isn't bound to a driver, PCI and ACPI will put the graphics to D3cold when runtime suspend kicks in, makes efifb stop working. So ensure the graphics device won't be runtime suspended, to keep efifb work all the time. Signed-off-by: Kai-Heng Feng Reviewed-by: Alex Deucher A gentle ping... Thanks for your patch. I've added it to drm-misc-next. Best regards Thomas --- drivers/video/fbdev/efifb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index e57c00824965..19edd7206409 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include /* For drm_get_panel_orientation_quirk */ @@ -575,6 +576,7 @@ static int efifb_probe(struct platform_device *dev) goto err_fb_dealoc; } fb_info(info, "%s frame buffer device\n", info->fix.id); + pm_runtime_get_sync(&efifb_pci_dev->dev); return 0; err_fb_dealoc: @@ -601,6 +603,7 @@ static int efifb_remove(struct platform_device *pdev) unregister_framebuffer(info); sysfs_remove_groups(&pdev->dev.kobj, efifb_groups); framebuffer_release(info); + pm_runtime_put(&efifb_pci_dev->dev); return 0; } -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drivers: gnu: drm: i915: gvt: Fixed couple of spellings in the file gtt.c
s/negtive/negative/ s/possilbe/possible/ Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/i915/gvt/gtt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c index 897c007ea96a..dc5834bf4de2 100644 --- a/drivers/gpu/drm/i915/gvt/gtt.c +++ b/drivers/gpu/drm/i915/gvt/gtt.c @@ -1159,8 +1159,8 @@ static inline void ppgtt_generate_shadow_entry(struct intel_gvt_gtt_entry *se, * @vgpu: target vgpu * @entry: target pfn's gtt entry * - * Return 1 if 2MB huge gtt shadowing is possilbe, 0 if miscondition, - * negtive if found err. + * Return 1 if 2MB huge gtt shadowing is possible, 0 if miscondition, + * negative if found err. */ static int is_2MB_gtt_possible(struct intel_vgpu *vgpu, struct intel_gvt_gtt_entry *entry) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build warning after merge of the pm tree
Hi all,
On Mon, 15 Feb 2021 11:39:39 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> In file included from drivers/gpu/drm/gma500/mdfld_output.c:28:
> arch/x86/include/asm/intel_scu_ipc.h:23:12: warning: 'struct module' declared
> inside parameter list will not be visible outside of this definition or
> declaration
>23 | struct module *owner);
> |^~
> arch/x86/include/asm/intel_scu_ipc.h:33:17: warning: 'struct module' declared
> inside parameter list will not be visible outside of this definition or
> declaration
>33 | struct module *owner);
> | ^~
>
> Introduced by commit
>
> bfc838f8598e ("drm/gma500: Convert to use new SCU IPC API")
>
> OK, these will go away when the drm-misc tree removes this file in commit
>
> e1da811218d2 ("drm/gma500: Remove Medfield support")
>
> So, if you don't want to see these warnings in Linus' build testing,
> you need to make sure that the drm-misc tree is merged before the pm
> tree (or the drivers-x86 tree). Or you need to include module.h in
> mdfld_output.c before intel_scu_ipc.h (or in intel_scu_ipc.h itself).
The above drm-misc commit is now in Linus' tree.
--
Cheers,
Stephen Rothwell
pgp5TAfn6E8ro.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff
Hi Daniel, On Fri, 19 Feb 2021 18:45:00 +0100 Daniel Vetter wrote: > On Fri, Feb 19, 2021 at 5:17 PM Steven Price wrote: > > > > On 19/02/2021 15:13, Daniel Vetter wrote: > > > On Fri, Feb 19, 2021 at 01:36:06PM +, Steven Price wrote: > > >> On 18/02/2021 18:20, Daniel Vetter wrote: > > >>> On Thu, Feb 18, 2021 at 6:16 PM Rob Herring wrote: > > >>> > > > > On Thu, Feb 18, 2021 at 10:51 AM Steven Price > > wrote: > > > > > > On 18/02/2021 16:38, Rob Herring wrote: > > >> On Thu, Feb 18, 2021 at 10:15 AM Steven Price > > >> wrote: > > >>> > > >>> On 18/02/2021 15:45, Alyssa Rosenzweig wrote: > > > Yeah plus Cc: stable for backporting and I think an igt or > > > similar for > > > panfrost to check this works correctly would be pretty good too. > > > Since > > > if it took us over 1 year to notice this bug it's pretty clear > > > that > > > normal testing doesn't catch this. So very likely we'll break this > > > again. > > > > Unfortunately there are a lot of kernel bugs which are noticed > > during actual > > use (but not CI runs), some of which have never been fixed. I do > > know > > the shrinker impl is buggy for us, if this is the fix I'm very > > happy. > > >>> > > >>> I doubt this will actually "fix" anything - if I understand > > >>> correctly > > >>> then the sequence which is broken is: > > >>> > > >>> * allocate BO, mmap to CPU > > >>> * madvise(DONTNEED) > > >>> * trigger purge > > >>> * try to access the BO memory > > >>> > > >>> which is an invalid sequence for user space - the attempt to access > > >>> memory should cause a SIGSEGV. However because drm_vma_node_unmap() > > >>> is > > >>> unable to find the mappings there may still be page table entries > > >>> present which would provide access to memory the kernel has freed. > > >>> Which > > >>> is of course a big security hole and so this fix is needed. > > >>> > > >>> In what way do you find the shrinker impl buggy? I'm aware there's > > >>> some > > >>> dodgy locking (although I haven't worked out how to fix it) - but > > >>> AFAICT > > >>> it's more deadlock territory rather than lacking in locks. Are there > > >>> correctness issues? > > >> > > >> What's there was largely a result of getting lockdep happy. > > >> > > > btw for testing shrinkers recommended way is to have a debugfs > > > file > > > that just force-shrinks everything. That way you avoid all the > > > trouble > > > that tend to happen when you drive a system close to OOM on > > > linux, and > > > it's also much faster. > > > > 2nding this as a good idea. > > > > >>> > > >>> Sounds like a good idea to me too. But equally I'm wondering > > >>> whether the > > >>> best (short term) solution is to actually disable the shrinker. I'm > > >>> somewhat surprised that nobody has got fed up with the "Purging xxx > > >>> bytes" message spam - which makes me think that most people are not > > >>> hitting memory pressure to trigger the shrinker. > > >> > > >> If the shrinker is dodgy, then it's probably good to have the > > >> messages > > >> to know if it ran. > > >> > > >>> The shrinker on kbase caused a lot of grief - and the only way I > > >>> managed > > >>> to get that under control was by writing a static analysis tool for > > >>> the > > >>> locking, and by upsetting people by enforcing the (rather dumb) > > >>> rules of > > >>> the tool on the code base. I've been meaning to look at whether > > >>> sparse > > >>> can do a similar check of locks. > > >> > > >> Lockdep doesn't cover it? > > > > > > Short answer: no ;) > > >>> > > >>> It's pretty good actually, if you correctly annotate things up. > > >> > > >> I agree - it's pretty good, the problem is you need reasonable test > > >> coverage, and getting good test coverage of shrinkers is hard. > > >> > > > The problem with lockdep is that you have to trigger the locking > > > scenario to get a warning out of it. For example you obviously won't > > > get > > > any warnings about the shrinker without triggering the shrinker (which > > > means memory pressure since we don't have the debugfs file to trigger > > > it). > > > > Actually, you don't need debugfs. Writing to /proc/sys/vm/drop_caches > > will do it. Though maybe there's other code path scenarios that > > wouldn't cover. > > >>> > > >>> Huh didn't know, but it's a bit a shotgun, plus it doesn't use > > >>> fs_reclaim shrinker annotations, which means you don't have lockdep > > >>>
Re: [PATCH v4 24/80] drm/omap: dsi: move TE GPIO handling into core
On 18/02/2021 07:57, Tony Lindgren wrote: > * Tomi Valkeinen [210217 07:42]: >> On 11/02/2021 19:35, Tony Lindgren wrote: >>> * Tomi Valkeinen [210211 07:35]: On 08/02/2021 19:55, Tony Lindgren wrote: > Hi, > > * Tomi Valkeinen [201124 12:47]: >> From: Sebastian Reichel >> >> In preparation for removing custom DSS calls from the DSI >> panel driver, this moves support for external tearing event >> GPIOs into the DSI host driver. This way tearing events are >> always handled in the core resulting in simplification of >> the panel drivers. >> >> The TE GPIO acquisition follows works in the same way as the >> exynos DSI implementation. > > Looks like this patch causes the following warnings: > > DSI: omapdss DSI error: Failed to receive BTA > DSI: omapdss DSI error: bta sync failed > DSI: omapdss DSI error: vc(0) busy when trying to config for VP > DSI: omapdss DSI error: Failed to receive BTA > DSI: omapdss DSI error: bta sync failed > DSI: omapdss DSI error: vc(0) busy when trying to config for VP > DSI: omapdss DSI error: Failed to receive BTA > DSI: omapdss DSI error: bta sync failed > DSI: omapdss DSI error: vc(0) busy when trying to config for VP > ... > > Any ideas? The display works for me despite the constant > warnings. Which board is that? Do the errors start right from the boot, or only after running something in userspace? >>> >>> This is with droid4, that's about the only device I use with a display >>> on regular basis. I'm pretty sure some earlier version of Sebastian's >>> patches worked fine. >> >> OMAP4 SDP doesn't produce these errors and the HW looks rather >> identical. Although I noticed something odd there, running kmstest >> --flip on the first display works fine, but running on the second >> display gets a bit erratic fps. Which is a bit odd as everything should >> be identical. > > Oh cool that you have those running again/still :) In this case there > is no te-gpios if that might make a difference. No, GPIO TE is not used on OMAP4 SDP either. >> So these errors start from the boot? Or only when running something >> specific? > > They start from the boot when modules are loaded. Normally there are no updates happening unless an userspace app is running, but I guess you have fb console enabled, with the blinking cursor which makes the updates. I usually don't have fbcon enabled, but OMAP4 SDP works fine for me with fbcon too... >> Is there a bootloader that initializes the display? > > Yes it boots with kexec. Is that open source? Can you disable the display setup from the bootloader? Maybe the DSS or the panel is left into a state that for whatever reason makes the kernel drivers break. Or maybe a DSS or DSI reset via SYSCONFIG at probe would help, or panel reset if it has such a feature. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC v3 2/3] virtio: Introduce Vdmabuf driver
Hi Gerd, > > On Fri, Feb 12, 2021 at 08:15:12AM +, Kasireddy, Vivek wrote: > > Hi Gerd, > > [Kasireddy, Vivek] Just to confirm my understanding of what you are > > suggesting, are you saying that we need to either have Weston allocate > > scanout buffers (GBM surface/BO) using virtio-gpu and render into them > > using i915; or have virtio-gpu allocate pages and export a dma-buf and > > have Weston create a GBM BO by calling gbm_bo_import(fd) and render into > > the BO > using i915? > > Not sure what the difference between the former and the latter is. [Kasireddy, Vivek] Oh, what I meant is whether you were suggesting that we create a GBM device and create a GBM surface and BOs using this device or just create a raw/dumb GEM object and create a GBM BO by importing it. As we just discovered, the former means we have to initialize virgl which complicates things so we went with the latter. > > > [Kasireddy, Vivek] We are only interested in Qemu UI at the moment but > > if we were to use virtio-gpu, we are going to need to add one more vq > > and support for managing buffers, events, etc. > > Should be easy and it should not need any virtio-gpu driver changes. [Kasireddy, Vivek] Vdmabuf v4, that implements your suggestion -- to have Vdmabuf allocate pages -- is posted here: https://lists.freedesktop.org/archives/dri-devel/2021-February/297841.html and tested it with Weston Headless and Qemu: https://gitlab.freedesktop.org/Vivek/weston/-/blob/vdmabuf/libweston/backend-headless/headless.c#L522 https://lists.nongnu.org/archive/html/qemu-devel/2021-02/msg02976.html Having said that, after discussing with Daniel Vetter, we are now switching our focus to virtio-gpu to compare and contrast both solutions. > > You can use virtio-gpu like a dumb scanout device. Create a dumb bo, create a > framebuffer for the bo, map the framebuffer to the crtc. > > Then export the bo, import into i915, use it as render target. When > rendering is done flush > (DRM_IOCTL_MODE_DIRTYFB). Alternatively allocate multiple bo's + framebuffers > and pageflip. [Kasireddy, Vivek] Since we are testing with Weston, we are looking at pageflips (4 color buffers). And, this part so far seems to work where virtio-gpu is used for kms (max_outputs=1) and Iris/i915 is used for rendering. We are currently glueing virtio-gpu and i915 in Weston but eventually the plan is to glue them (virgl/virtio-gpu and Iris) in Mesa if possible using KMSRO (KMS render only) to avoid having to change Weston or X or other user-space components. > > Pretty standard workflow for cases where rendering and scanout are handled by > different > devices. As far I know not uncommon in the arm world. > > Right now this will involve a memcpy() for any display update because qemu is > a bit > behind on supporting recent virtio-gpu features. [Kasireddy, Vivek] IIUC, I think you are referring to creating the Pixman image in set_scanout. What additional features need to be implemented or what is your recommendation in terms of what needs to be done to turn the memcpy() into a dma-buf? Also, how should we ensure that access to the guest fb/dmabuf is synchronized to ensure that the Guest and the Host do not access the backing storage of the dmabuf at the same time? Thanks, Vivek > > take care, > Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/11] drm/atomic: Pass the full state to planes atomic_check
Am 19.02.21 um 13:00 schrieb Maxime Ripard:
The current atomic helpers have either their object state being passed as
an argument or the full atomic state.
The former is the pattern that was done at first, before switching to the
latter for new hooks or when it was needed.
Let's convert all the remaining helpers to provide a consistent
interface, starting with the planes atomic_check.
The conversion was done using the coccinelle script below plus some
manual changes for vmwgfx, built tested on all the drivers.
@@
identifier plane, plane_state;
symbol state;
@@
struct drm_plane_helper_funcs {
...
int (*atomic_check)(struct drm_plane *plane,
- struct drm_plane_state *plane_state);
+ struct drm_atomic_state *state);
...
}
@ plane_atomic_func @
identifier helpers;
identifier func;
@@
static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_check = func,
...,
};
@@
struct drm_plane_helper_funcs *FUNCS;
identifier f;
identifier dev;
identifier plane, plane_state, state;
@@
f(struct drm_device *dev, struct drm_atomic_state *state)
{
<+...
- FUNCS->atomic_check(plane, plane_state)
+ FUNCS->atomic_check(plane, state)
...+>
}
@ ignores_new_state @
identifier plane_atomic_func.func;
identifier plane, new_plane_state;
@@
func(struct drm_plane *plane, struct drm_plane_state *new_plane_state)
{
... when != new_plane_state
}
@ adds_new_state depends on plane_atomic_func && !ignores_new_state @
identifier plane_atomic_func.func;
identifier plane, new_plane_state;
@@
func(struct drm_plane *plane, struct drm_plane_state *new_plane_state)
{
+ struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(state, plane);
...
}
@ depends on plane_atomic_func @
identifier plane_atomic_func.func;
identifier plane, new_plane_state;
@@
func(struct drm_plane *plane,
- struct drm_plane_state *new_plane_state
+ struct drm_atomic_state *state
)
{ ... }
@ include depends on adds_new_state @
@@
#include
@ no_include depends on !include && adds_new_state @
@@
+ #include
#include
Reviewed-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
Changes from v1:
- Rewording and removal of a coccinelle rule suggested by Laurent
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 4 +++-
drivers/gpu/drm/arm/hdlcd_crtc.c | 4 +++-
drivers/gpu/drm/arm/malidp_planes.c | 4 +++-
drivers/gpu/drm/armada/armada_plane.c | 4 +++-
drivers/gpu/drm/armada/armada_plane.h | 2 +-
drivers/gpu/drm/ast/ast_mode.c| 8 ++--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 ++-
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
drivers/gpu/drm/drm_simple_kms_helper.c | 4 +++-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +++-
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 5 -
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 4 +++-
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +++-
drivers/gpu/drm/imx/dcss/dcss-plane.c | 4 +++-
drivers/gpu/drm/imx/ipuv3-plane.c | 4 +++-
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 4 +++-
drivers/gpu/drm/ingenic/ingenic-ipu.c | 4 +++-
drivers/gpu/drm/kmb/kmb_plane.c | 4 +++-
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 4 +++-
drivers/gpu/drm/meson/meson_overlay.c | 4 +++-
drivers/gpu/drm/meson/meson_plane.c | 4 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 -
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c| 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 4 +++-
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 4 +++-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 5 -
drivers/gpu/drm/omapdrm/omap_plane.c | 4 +++-
drivers/gpu/drm/qxl/qxl_display.c | 4 +++-
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +++-
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +++-
drivers/gpu/drm/sti/sti_cursor.c | 4 +++-
drivers/gpu/drm/sti/sti_gdp.c | 4 +++-
drivers/gpu/drm/sti/sti_hqvdp.c | 4 +++-
drivers/gpu/drm/stm/ltdc.c| 4 +++-
drivers/gpu/drm/sun4i/sun8i_ui_layer.c| 4 +++-
drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 4 +++-
drivers/gpu/drm/tegra/dc.c| 8 ++--
drivers/gpu/drm/tegra/hub.c | 4 +++-
drivers/gpu/drm/tidss/tidss_plane.c | 4 +++-
drivers/gpu/drm/tilcdc/tilcdc_plane.c | 4 +++-
drivers/gpu/drm/v
Re: [PATCH v3 02/11] drm: Rename plane atomic_check state names
Am 19.02.21 um 16:12 schrieb Maxime Ripard:
Hi Thomas,
Thanks for your review!
On Fri, Feb 19, 2021 at 03:49:22PM +0100, Thomas Zimmermann wrote:
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 075508051b5f..1873a155bb26 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -337,12 +337,12 @@ static const struct drm_plane_funcs ipu_plane_funcs = {
};
static int ipu_plane_atomic_check(struct drm_plane *plane,
- struct drm_plane_state *state)
+ struct drm_plane_state *new_state)
This function uses a different naming convention then the others?
{
struct drm_plane_state *old_state = plane->state;
So, the function already had a variable named old_state, so I was
actually trying to make the drivers consistent here: having one variable
with old_state and new_plane_state felt weird.
The heuristic is thus to use the convention of the driver if one exists
already, and if there's none pick new_plane_state.
It makes it indeed inconsistent across drivers, but it felt more natural
to be consistent within a single driver.
Makes sense.
Maxime
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/11] drm: Use the state pointer directly in planes atomic_check
Am 19.02.21 um 13:00 schrieb Maxime Ripard:
Now that atomic_check takes the global atomic state as a parameter, we
don't need to go through the pointer in the plane state.
This was done using the following coccinelle script:
@ plane_atomic_func @
identifier helpers;
identifier func;
@@
static struct drm_plane_helper_funcs helpers = {
...,
.atomic_check = func,
...,
};
@@
identifier plane_atomic_func.func;
identifier plane, state;
identifier plane_state;
@@
func(struct drm_plane *plane, struct drm_atomic_state *state) {
...
- struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(state,
plane);
<... when != plane_state
- plane_state->state
+ state
...>
}
@@
identifier plane_atomic_func.func;
identifier plane, state;
identifier plane_state;
@@
func(struct drm_plane *plane, struct drm_atomic_state *state) {
...
struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(state,
plane);
<...
- plane_state->state
+ state
...>
}
Reviewed-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
Changes from v1:
- Fixed the formatting in zynqmp_disp
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 2 +-
drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +-
drivers/gpu/drm/armada/armada_plane.c | 4 ++--
drivers/gpu/drm/ast/ast_mode.c| 4 ++--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 2 +-
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +-
drivers/gpu/drm/imx/dcss/dcss-plane.c | 2 +-
drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 2 +-
drivers/gpu/drm/ingenic/ingenic-ipu.c | 2 +-
drivers/gpu/drm/kmb/kmb_plane.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +-
drivers/gpu/drm/meson/meson_overlay.c | 2 +-
drivers/gpu/drm/meson/meson_plane.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 2 +-
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 +-
drivers/gpu/drm/omapdrm/omap_plane.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
drivers/gpu/drm/sti/sti_cursor.c | 2 +-
drivers/gpu/drm/sti/sti_gdp.c | 2 +-
drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
drivers/gpu/drm/sun4i/sun8i_ui_layer.c| 2 +-
drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 2 +-
drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
drivers/gpu/drm/tilcdc/tilcdc_plane.c | 2 +-
drivers/gpu/drm/vboxvideo/vbox_mode.c | 8
drivers/gpu/drm/virtio/virtgpu_plane.c| 2 +-
drivers/gpu/drm/vkms/vkms_plane.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
drivers/gpu/drm/xlnx/zynqmp_disp.c| 3 +--
drivers/gpu/drm/zte/zx_plane.c| 4 ++--
35 files changed, 41 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1cdff048b0c0..22124f76d0b5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6451,7 +6451,7 @@ static int dm_plane_atomic_check(struct drm_plane *plane,
return 0;
new_crtc_state =
- drm_atomic_get_new_crtc_state(new_plane_state->state,
+ drm_atomic_get_new_crtc_state(state,
new_plane_state->crtc);
if (!new_crtc_state)
return -EINVAL;
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index 96a6fe95a4e7..13582c174bbb 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -84,7 +84,7 @@ komeda_plane_atomic_check(struct drm_plane *plane,
if (!new_plane_state->crtc || !new_plane_state->fb)
return 0;
- crtc_st = drm_atomic_get_crtc_state(new_plane_state->state,
+ crtc_st = drm_atomic_get_crtc_state(state,
new_plane_state->crtc);
if (IS_ERR(crtc_st) || !crtc_st->enable) {
DRM_DEBUG_ATOMIC("Cannot update plane on a disabled CRTC.\n");
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 9da9d0581ce9..028ec39c8484 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -244,7 +244,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane,
Re: [PATCH v3 06/11] drm: Use state helper instead of plane state pointer in atomic_check
Am 19.02.21 um 13:00 schrieb Maxime Ripard:
Many drivers reference the plane->state pointer in order to get the
current plane state in their atomic_check hook, which would be the old
plane state in the global atomic state since _swap_state hasn't happened
when atomic_check is run.
Use the drm_atomic_get_old_plane_state helper to get that state to make
it more obvious.
This was made using the coccinelle script below:
@ plane_atomic_func @
identifier helpers;
identifier func;
@@
static struct drm_plane_helper_funcs helpers = {
...,
.atomic_check = func,
...,
};
@ replaces_old_state @
identifier plane_atomic_func.func;
identifier plane, state, plane_state;
@@
func(struct drm_plane *plane, struct drm_atomic_state *state) {
...
- struct drm_plane_state *plane_state = plane->state;
+ struct drm_plane_state *plane_state =
drm_atomic_get_old_plane_state(state, plane);
...
}
@@
identifier plane_atomic_func.func;
identifier plane, state, plane_state;
@@
func(struct drm_plane *plane, struct drm_atomic_state *state) {
struct drm_plane_state *plane_state =
drm_atomic_get_old_plane_state(state, plane);
<...
- plane->state
+ plane_state
...>
}
@ adds_old_state @
identifier plane_atomic_func.func;
identifier plane, state;
@@
func(struct drm_plane *plane, struct drm_atomic_state *state) {
+ struct drm_plane_state *old_plane_state =
drm_atomic_get_old_plane_state(state, plane);
<...
- plane->state
+ old_plane_state
...>
}
@ include depends on adds_old_state || replaces_old_state @
@@
#include
@ no_include depends on !include && (adds_old_state || replaces_old_state) @
@@
+ #include
#include
Reviewed-by: Ville Syrjälä
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
However, I find 'old plane state' somewhat confusing in this context,
because it's actually the current plane state. Would it make sense to
use drm_atomic_get_existing_plane_state() instead?
Best regards
Thomas
---
Changes from v2:
- s/.../<.../ in the coccinelle script as suggested by Ville
---
drivers/gpu/drm/imx/ipuv3-plane.c | 3 ++-
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 16 +---
drivers/gpu/drm/ingenic/ingenic-ipu.c | 8 +---
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 +++-
drivers/gpu/drm/tilcdc/tilcdc_plane.c | 3 ++-
5 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index b5f6123850bb..6484592e3f86 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -341,7 +341,8 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
{
struct drm_plane_state *new_state =
drm_atomic_get_new_plane_state(state,
plane);
- struct drm_plane_state *old_state = plane->state;
+ struct drm_plane_state *old_state =
drm_atomic_get_old_plane_state(state,
+
plane);
struct drm_crtc_state *crtc_state;
struct device *dev = plane->dev->dev;
struct drm_framebuffer *fb = new_state->fb;
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index e6d7d0a04ddb..c022d9f1e737 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -361,11 +361,13 @@ static void ingenic_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
static int ingenic_drm_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
+ struct drm_plane_state *old_plane_state =
drm_atomic_get_old_plane_state(state,
+
plane);
struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(state,
plane);
struct ingenic_drm *priv = drm_device_get_priv(plane->dev);
struct drm_crtc_state *crtc_state;
- struct drm_crtc *crtc = new_plane_state->crtc ?: plane->state->crtc;
+ struct drm_crtc *crtc = new_plane_state->crtc ?: old_plane_state->crtc;
int ret;
if (!crtc)
@@ -399,12 +401,12 @@ static int ingenic_drm_plane_atomic_check(struct
drm_plane *plane,
* its position, size or depth.
*/
if (priv->soc_info->has_osd &&
- (!plane->state->fb || !new_plane_state->fb ||
-plane->state->crtc_x != new_plane_state->crtc_x ||
-plane->state->crtc_y != new_plane_state->crtc_y ||
-plane->state->crtc_w != new_plane_state->crtc_w ||
-plane->state->crtc_h != new_plane_state->crtc_h ||
-plane->state->fb->format->format !
[PATCH 0/2] Standardize DSI driver logging system
The use of DRM logging macros was removed and dev_err_probe() replaces condition, showing errors but not EPROBE_DEFER. Yannick Fertre (2): drm/stm: dsi: Avoid printing errors for -EPROBE_DEFER drm/stm: dsi: Use dev_ based logging drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 58 +-- 1 file changed, 29 insertions(+), 29 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/stm: dsi: Avoid printing errors for -EPROBE_DEFER
From: Yannick Fertre
Don't print error when probe deferred error is returned.
Signed-off-by: Raphael Gallais-Pou
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 2e1f2664495d..8399d337589d 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -363,8 +363,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
dsi->vdd_supply = devm_regulator_get(dev, "phy-dsi");
if (IS_ERR(dsi->vdd_supply)) {
ret = PTR_ERR(dsi->vdd_supply);
- if (ret != -EPROBE_DEFER)
- DRM_ERROR("Failed to request regulator: %d\n", ret);
+ dev_err_probe(dev, ret, "Failed to request regulator\n");
return ret;
}
@@ -377,9 +376,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
dsi->pllref_clk = devm_clk_get(dev, "ref");
if (IS_ERR(dsi->pllref_clk)) {
ret = PTR_ERR(dsi->pllref_clk);
- if (ret != -EPROBE_DEFER)
- DRM_ERROR("Unable to get pll reference clock: %d\n",
- ret);
+ dev_err_probe(dev, ret, "Unable to get pll reference clock\n");
goto err_clk_get;
}
@@ -419,7 +416,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
dsi->dsi = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
if (IS_ERR(dsi->dsi)) {
ret = PTR_ERR(dsi->dsi);
- DRM_ERROR("Failed to initialize mipi dsi host: %d\n", ret);
+ dev_err_probe(dev, ret, "Failed to initialize mipi dsi host\n");
goto err_dsi_probe;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] topic/kcmp-kconfig
Hi Linus, One patch pull request for you to ponder in the hopefully less stressful 2nd week of the merge window :-) It's also marked cc: stable so people can stop building kernels that don't work so well. topic/kcmp-kconfig-2021-02-22: kconfig for kcmp syscall drm userspaces uses this, systemd uses this, makes sense to pull it out from the checkpoint-restore bundle. Kees reviewed this from security pov and is happy with the final version. LWN coverage: https://lwn.net/Articles/845448/ Cheers, Daniel The following changes since commit f40ddce88593482919761f74910f42f4b84c004b: Linux 5.11 (2021-02-14 14:32:24 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/topic/kcmp-kconfig-2021-02-22 for you to fetch changes up to bfe3911a91047557eb0e620f95a370aee6a248c7: kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE (2021-02-16 09:59:41 +0100) kconfig for kcmp syscall drm userspaces uses this, systemd uses this, makes sense to pull it out from the checkpoint-restore bundle. Kees reviewed this from security pov and is happy with the final version. LWN coverage: https://lwn.net/Articles/845448/ Chris Wilson (1): kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE drivers/gpu/drm/Kconfig | 3 +++ fs/eventpoll.c| 4 ++-- include/linux/eventpoll.h | 2 +- init/Kconfig | 11 +++ kernel/Makefile | 2 +- tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- 6 files changed, 19 insertions(+), 5 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ast: fix memory leak when unload the driver
Am 22.02.21 um 03:33 schrieb Tong Zhang: a connector is leaked upon module unload, it seems that we should do similar to sample driver as suggested in drm_drv.c. Adding drm_atomic_helper_shutdown() in ast_pci_remove to prevent leaking. [ 153.822134] WARNING: CPU: 0 PID: 173 at drivers/gpu/drm/drm_mode_config.c:504 drm_mode_config_cle0 [ 153.822698] Modules linked in: ast(-) drm_vram_helper drm_ttm_helper ttm [last unloaded: ttm] [ 153.823197] CPU: 0 PID: 173 Comm: modprobe Tainted: GW 5.11.0-03615-g55f62bc873474 [ 153.823708] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-4 [ 153.824333] RIP: 0010:drm_mode_config_cleanup+0x418/0x470 [ 153.824637] Code: 0c 00 00 00 00 48 8b 84 24 a8 00 00 00 65 48 33 04 25 28 00 00 00 75 65 48 81 c0 [ 153.825668] RSP: 0018:888103c9fb70 EFLAGS: 00010212 [ 153.825962] RAX: 888102b0d100 RBX: 888102b0c298 RCX: 818d8b2b [ 153.826356] RDX: dc00 RSI: 7fff RDI: 888102b0c298 [ 153.826748] RBP: 888103c9fba0 R08: 0001 R09: ed1020561857 [ 153.827146] R10: 888102b0c2b7 R11: ed1020561856 R12: 888102b0c000 [ 153.827538] R13: 888102b0c2d8 R14: 888102b0c2d8 R15: 111020793f70 [ 153.827935] FS: 7f24bff456a0() GS:88815b40() knlGS: [ 153.828380] CS: 0010 DS: ES: CR0: 80050033 [ 153.828697] CR2: 01c39018 CR3: 000103c9 CR4: 06f0 [ 153.829096] DR0: DR1: DR2: [ 153.829486] DR3: DR6: fffe0ff0 DR7: 0400 [ 153.829883] Call Trace: [ 153.830024] ? drmm_mode_config_init+0x930/0x930 [ 153.830281] ? cpumask_next+0x16/0x20 [ 153.830488] ? mnt_get_count+0x66/0x80 [ 153.830699] ? drm_mode_config_cleanup+0x470/0x470 [ 153.830972] drm_managed_release+0xed/0x1c0 [ 153.831208] drm_dev_release+0x3a/0x50 [ 153.831420] release_nodes+0x39e/0x410 [ 153.831631] ? devres_release+0x40/0x40 [ 153.831852] device_release_driver_internal+0x158/0x270 [ 153.832143] driver_detach+0x76/0xe0 [ 153.832344] bus_remove_driver+0x7e/0x100 [ 153.832568] pci_unregister_driver+0x28/0xf0 [ 153.832821] __x64_sys_delete_module+0x268/0x300 [ 153.833086] ? __ia32_sys_delete_module+0x300/0x300 [ 153.833357] ? call_rcu+0x372/0x4f0 [ 153.833553] ? fpregs_assert_state_consistent+0x4d/0x60 [ 153.833840] ? exit_to_user_mode_prepare+0x2f/0x130 [ 153.834118] do_syscall_64+0x33/0x40 [ 153.834317] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 153.834597] RIP: 0033:0x7f24bfec7cf7 [ 153.834797] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d6 41 [ 153.835812] RSP: 002b:7fff72e6cb58 EFLAGS: 0202 ORIG_RAX: 00b0 [ 153.836234] RAX: ffda RBX: 7f24bff45690 RCX: 7f24bfec7cf7 [ 153.836623] RDX: RSI: 0080 RDI: 01c2fb10 [ 153.837018] RBP: 01c2fac0 R08: 2f2f2f2f2f2f2f2f R09: 01c2fac0 [ 153.837408] R10: fefefefefefefeff R11: 0202 R12: 01c2fac0 [ 153.837798] R13: 01c2f9d0 R14: R15: 0001 [ 153.838194] ---[ end trace b92031513bbe596c ]--- [ 153.838441] [drm:drm_mode_config_cleanup] *ERROR* connector VGA-1 leaked! Signed-off-by: Tong Zhang I've added the patch to drm-misc-next. Thanks a lot! Best regards Thomas --- drivers/gpu/drm/ast/ast_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c index 667b450606ef..b047c0ea43e8 100644 --- a/drivers/gpu/drm/ast/ast_drv.c +++ b/drivers/gpu/drm/ast/ast_drv.c @@ -30,6 +30,7 @@ #include #include +#include #include #include #include @@ -138,6 +139,7 @@ static void ast_pci_remove(struct pci_dev *pdev) struct drm_device *dev = pci_get_drvdata(pdev); drm_dev_unregister(dev); + drm_atomic_helper_shutdown(dev); } static int ast_drm_freeze(struct drm_device *dev) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/compat: more dummy implementations
drm_noop really doesnt do much, and who cares about the permission checks.
So let's delete some code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioc32.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index dc734d4828a1..33390f02f5eb 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -302,12 +302,8 @@ static int compat_drm_getstats(struct file *file, unsigned
int cmd,
unsigned long arg)
{
drm_stats32_t __user *argp = (void __user *)arg;
- int err;
-
- err = drm_ioctl_kernel(file, drm_noop, NULL, 0);
- if (err)
- return err;
+ /* getstats is defunct, just clear */
if (clear_user(argp, sizeof(drm_stats32_t)))
return -EFAULT;
return 0;
@@ -820,13 +816,8 @@ typedef struct drm_update_draw32 {
static int compat_drm_update_draw(struct file *file, unsigned int cmd,
unsigned long arg)
{
- drm_update_draw32_t update32;
-
- if (copy_from_user(&update32, (void __user *)arg, sizeof(update32)))
- return -EFAULT;
-
- return drm_ioctl_kernel(file, drm_noop, NULL,
- DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY);
+ /* update_draw is defunct */
+ return 0;
}
#endif
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/compat: Clear bounce structures
Some of them have gaps, or fields we don't clear. Native ioctl code
does full copies plus zero-extends on size mismatch, so nothing can
leak. But compat is more hand-rolled so need to be careful.
None of these matter for performance, so just memset.
Also I didn't fix up the CONFIG_DRM_LEGACY or CONFIG_DRM_AGP ioctl, those
are security holes anyway.
Reported-by: syzbot+620cf21140fc7e772...@syzkaller.appspotmail.com # vblank
ioctl
Cc: syzbot+620cf21140fc7e772...@syzkaller.appspotmail.com
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioc32.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index f86448ab1fe0..dc734d4828a1 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -99,6 +99,8 @@ static int compat_drm_version(struct file *file, unsigned int
cmd,
if (copy_from_user(&v32, (void __user *)arg, sizeof(v32)))
return -EFAULT;
+ memset(&v, 0, sizeof(v));
+
v = (struct drm_version) {
.name_len = v32.name_len,
.name = compat_ptr(v32.name),
@@ -137,6 +139,9 @@ static int compat_drm_getunique(struct file *file, unsigned
int cmd,
if (copy_from_user(&uq32, (void __user *)arg, sizeof(uq32)))
return -EFAULT;
+
+ memset(&uq, 0, sizeof(uq));
+
uq = (struct drm_unique){
.unique_len = uq32.unique_len,
.unique = compat_ptr(uq32.unique),
@@ -265,6 +270,8 @@ static int compat_drm_getclient(struct file *file, unsigned
int cmd,
if (copy_from_user(&c32, argp, sizeof(c32)))
return -EFAULT;
+ memset(&client, 0, sizeof(client));
+
client.idx = c32.idx;
err = drm_ioctl_kernel(file, drm_getclient, &client, 0);
@@ -852,6 +859,8 @@ static int compat_drm_wait_vblank(struct file *file,
unsigned int cmd,
if (copy_from_user(&req32, argp, sizeof(req32)))
return -EFAULT;
+ memset(&req, 0, sizeof(req));
+
req.request.type = req32.request.type;
req.request.sequence = req32.request.sequence;
req.request.signal = req32.request.signal;
@@ -889,6 +898,8 @@ static int compat_drm_mode_addfb2(struct file *file,
unsigned int cmd,
struct drm_mode_fb_cmd2 req64;
int err;
+ memset(&req64, 0, sizeof(req64));
+
if (copy_from_user(&req64, argp,
offsetof(drm_mode_fb_cmd232_t, modifier)))
return -EFAULT;
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/stm: dsi: Use dev_ based logging
From: Yannick Fertre
Standardize on the dev_ based logging.
Signed-off-by: Raphael Gallais-Pou
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 49 ++-
1 file changed, 26 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 8399d337589d..a7226bb3d0e8 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -76,6 +76,7 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
+ struct device *dev;
struct clk *pllref_clk;
struct dw_mipi_dsi *dsi;
u32 hw_version;
@@ -110,7 +111,8 @@ static inline void dsi_update_bits(struct dw_mipi_dsi_stm
*dsi, u32 reg,
dsi_write(dsi, reg, (dsi_read(dsi, reg) & ~mask) | val);
}
-static enum dsi_color dsi_color_from_mipi(enum mipi_dsi_pixel_format fmt)
+static enum dsi_color dsi_color_from_mipi(struct dw_mipi_dsi_stm *dsi,
+ enum mipi_dsi_pixel_format fmt)
{
switch (fmt) {
case MIPI_DSI_FMT_RGB888:
@@ -122,7 +124,7 @@ static enum dsi_color dsi_color_from_mipi(enum
mipi_dsi_pixel_format fmt)
case MIPI_DSI_FMT_RGB565:
return DSI_RGB565_CONF1;
default:
- DRM_DEBUG_DRIVER("MIPI color invalid, so we use rgb888\n");
+ dev_dbg(dsi->dev, "MIPI color invalid, so we use rgb888\n");
}
return DSI_RGB888;
}
@@ -205,14 +207,14 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
SLEEP_US, TIMEOUT_US);
if (ret)
- DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
+ dev_dbg(dsi->dev, "!TIMEOUT! waiting REGU, let's continue\n");
/* Enable the DSI PLL & wait for its lock */
dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
SLEEP_US, TIMEOUT_US);
if (ret)
- DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
+ dev_dbg(dsi->dev, "!TIMEOUT! waiting PLL, let's continue\n");
return 0;
}
@@ -221,7 +223,7 @@ static void dw_mipi_dsi_phy_power_on(void *priv_data)
{
struct dw_mipi_dsi_stm *dsi = priv_data;
- DRM_DEBUG_DRIVER("\n");
+ dev_dbg(dsi->dev, "\n");
/* Enable the DSI wrapper */
dsi_set(dsi, DSI_WCR, WCR_DSIEN);
@@ -231,7 +233,7 @@ static void dw_mipi_dsi_phy_power_off(void *priv_data)
{
struct dw_mipi_dsi_stm *dsi = priv_data;
- DRM_DEBUG_DRIVER("\n");
+ dev_dbg(dsi->dev, "\n");
/* Disable the DSI wrapper */
dsi_clear(dsi, DSI_WCR, WCR_DSIEN);
@@ -267,11 +269,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
if (pll_out_khz > dsi->lane_max_kbps) {
pll_out_khz = dsi->lane_max_kbps;
- DRM_WARN("Warning max phy mbps is used\n");
+ dev_warn(dsi->dev, "Warning max phy mbps is used\n");
}
if (pll_out_khz < dsi->lane_min_kbps) {
pll_out_khz = dsi->lane_min_kbps;
- DRM_WARN("Warning min phy mbps is used\n");
+ dev_warn(dsi->dev, "Warning min phy mbps is used\n");
}
/* Compute best pll parameters */
@@ -281,7 +283,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
ret = dsi_pll_get_params(dsi, pll_in_khz, pll_out_khz,
&idf, &ndiv, &odf);
if (ret)
- DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
+ dev_warn(dsi->dev, "Warning dsi_pll_get_params(): bad
params\n");
/* Get the adjusted pll out value */
pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
@@ -299,13 +301,12 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
/* Select the color coding */
dsi_update_bits(dsi, DSI_WCFGR, WCFGR_COLMUX,
- dsi_color_from_mipi(format) << 1);
+ dsi_color_from_mipi(dsi, format) << 1);
*lane_mbps = pll_out_khz / 1000;
- DRM_DEBUG_DRIVER("pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
-pll_in_khz, pll_out_khz, *lane_mbps);
-
+ dev_dbg(dsi->dev, "pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
+ pll_in_khz, pll_out_khz, *lane_mbps);
return 0;
}
@@ -352,11 +353,13 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
if (!dsi)
return -ENOMEM;
+ dsi->dev = dev;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dsi->base = devm_ioremap_resource(dev, res);
if (IS_ERR(dsi->base)) {
ret
Re: [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window
Cc all the mailing lists ... my usual script crashed and I had to
hand-roll the email and screwed it up ofc :-/
-Daniel
On Mon, Feb 22, 2021 at 11:23 AM Daniel Vetter wrote:
>
> Hi Linus,
>
> Another small pull from you to ponder.
>
> This is the first part of a patch series I've been working on for a while:
>
> https://lore.kernel.org/dri-devel/20201127164131.2244124-1-daniel.vet...@ffwll.ch/
>
> I've stumbled over this for my own learning and then realized there's a
> bunch of races around VM_PFNMAP mappings vs follow pfn.
>
> If you're happy with this then I'll follow up with the media patches to
> mark their leftover use of follow_pfn as unsafe (it's uapi, so unfixable
> issue, all we can do is a config option to harden the kernel). Plus
> hopefully kvm and vfio are then fixed too (you've been on the recent kvm
> thread where this popped up again) so that we can sunset follow_pfn usage
> completely.
>
> The last two patches have only been in linux-next in their current form
> for a week, there was some issue for platforms with HAVE_PCI_LEGACY (not
> that many) which took some sorting out. But looks all good now.
>
> Cheers, Daniel
>
> The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:
>
> Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm
> tags/topic/iomem-mmap-vs-gup-2021-02-22
>
> for you to fetch changes up to 636b21b50152d4e203223ee337aca1cb3c1bfe53:
>
> PCI: Revoke mappings like devmem (2021-02-11 15:59:19 +0100)
>
>
> Fixes around VM_FPNMAP and follow_pfn
>
> - replace mm/frame_vector.c by get_user_pages in misc/habana and
> drm/exynos drivers, then move that into media as it's sole user
> - close race in generic_access_phys
> - s390 pci ioctl fix of this series landed in 5.11 already
> - properly revoke iomem mappings (/dev/mem, pci files)
>
>
> Daniel Vetter (13):
> drm/exynos: Stop using frame_vector helpers
> drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
> misc/habana: Stop using frame_vector helpers
> misc/habana: Use FOLL_LONGTERM for userptr
> mm/frame-vector: Use FOLL_LONGTERM
> media: videobuf2: Move frame_vector into media subsystem
> mm: Close race in generic_access_phys
> PCI: Obey iomem restrictions for procfs mmap
> /dev/mem: Only set filp->f_mapping
> resource: Move devmem revoke code to resource framework
> sysfs: Support zapping of binary attr mmaps
> PCI: Also set up legacy files only after sysfs init
> PCI: Revoke mappings like devmem
>
> drivers/char/mem.c| 86
> +
> drivers/gpu/drm/exynos/Kconfig| 1 -
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48
> -
> drivers/media/common/videobuf2/Kconfig| 1 -
> drivers/media/common/videobuf2/Makefile | 1 +
> {mm => drivers/media/common/videobuf2}/frame_vector.c | 55
> +++---
> drivers/media/common/videobuf2/videobuf2-memops.c | 3 +--
> drivers/media/platform/omap/Kconfig | 1 -
> drivers/misc/habanalabs/Kconfig | 1 -
> drivers/misc/habanalabs/common/habanalabs.h | 6 +++--
> drivers/misc/habanalabs/common/memory.c | 52
> +++-
> drivers/pci/pci-sysfs.c | 11 +
> drivers/pci/proc.c| 6 +
> fs/sysfs/file.c | 11 +
> include/linux/ioport.h| 6 +
> include/linux/mm.h| 45
> ++
> include/linux/sysfs.h | 2 ++
> include/media/frame_vector.h | 47
>
> include/media/videobuf2-core.h| 1 +
> kernel/resource.c | 98
> ++-
> mm/Kconfig| 3 ---
> mm/Makefile | 1 -
> mm/memory.c | 46
> ---
> 23 files changed, 287 insertions(+), 245 deletions(-)
> rename {mm => drivers/media/common/videobuf2}/frame_vector.c (85%)
> create mode 100644 include/media/frame_vector.h
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_
Re: [PATCH v2 1/4] hmm: Device exclusive memory access
On Friday, 19 February 2021 8:47:41 PM AEDT Christoph Hellwig wrote:
> > page = migration_entry_to_page(swpent);
> > else if (is_device_private_entry(swpent))
> > page = device_private_entry_to_page(swpent);
> > + else if (is_device_exclusive_entry(swpent))
> > + page = device_exclusive_entry_to_page(swpent);
>
> > page = migration_entry_to_page(swpent);
> > else if (is_device_private_entry(swpent))
> > page = device_private_entry_to_page(swpent);
> > + else if (is_device_exclusive_entry(swpent))
> > + page = device_exclusive_entry_to_page(swpent);
>
> > if (is_device_private_entry(entry))
> > page = device_private_entry_to_page(entry);
> > +
> > + if (is_device_exclusive_entry(entry))
> > + page = device_exclusive_entry_to_page(entry);
>
> Any chance we can come up with a clever scheme to avoid all this
> boilerplate code (and maybe also what it gets compiled to)?
If I open code the entry_to_page() functions as suggested below then these
simplify down to single if statements like so:
if (is_migration_entry(entry) ||
is_device_private_entry(entry) ||
is_device_exclusive_entry(entry))
page = pfn_to_page(swp_offset(entry));
I could simplify further by hiding that in a single static inline like so:
static inline bool is_special_entry(swp_entry_t entry)
{
return is_migration_entry(entry) ||
is_device_private_entry(entry) ||
is_device_exclusive_entry(entry);
}
My only concern with doing that is these entries can't *always* be treated the
same so it might make it too easy to overlook the subtle differences.
> > diff --git a/include/linux/hmm.h b/include/linux/hmm.h
> > index 866a0fa104c4..5d28ff6d4d80 100644
> > --- a/include/linux/hmm.h
> > +++ b/include/linux/hmm.h
> > @@ -109,6 +109,10 @@ struct hmm_range {
> > */
> > int hmm_range_fault(struct hmm_range *range);
> >
> > +int hmm_exclusive_range(struct mm_struct *mm, unsigned long start,
> > + unsigned long end, struct page **pages);
> > +vm_fault_t hmm_remove_exclusive_entry(struct vm_fault *vmf);
>
> Can we avoid the hmm naming for new code (we should probably also kill
> it off for the existing code)?
Sure. I ended up stuffing it in there for the moment because I didn't know of
any other "obvious" spot to put it. How about these for names:
int make_device_exclusive_range(struct mm_struct *mm, unsigned long start,
unsigned long end, struct page **pages);
vm_fault_t remove_device_exclusive_entry(struct vm_fault *vmf);
I am open to any alternative naming suggestions though.
> > +#define free_swap_and_cache(e) ({(is_migration_entry(e) ||
is_device_private_entry(e) \
> > + || is_device_exclusive_entry(e)); })
> > +#define swapcache_prepare(e) ({(is_migration_entry(e) ||
is_device_private_entry(e) \
> > + || is_device_exclusive_entry(e)); })
> Can you turn these into properly formatted inline functions? As-is this
> becomes pretty unreadable.
Ok, if I add a is_special_entry() function as suggested above these could just
use that.
> > +static inline void make_device_exclusive_entry_read(swp_entry_t *entry)
> > +{
> > + *entry = swp_entry(SWP_DEVICE_EXCLUSIVE_READ, swp_offset(*entry));
> > +}
>
> s/make_device_exclusive_entry_read/mark_device_exclusive_entry_readable/
> ??
See my next comment.
> > +
> > +static inline swp_entry_t make_device_exclusive_entry(struct page *page,
bool write)
> > +{
> > + return swp_entry(write ? SWP_DEVICE_EXCLUSIVE_WRITE :
SWP_DEVICE_EXCLUSIVE_READ,
> > +page_to_pfn(page));
> > +}
>
> I'd split this into two helpers, which is easier to follow and avoids
> the pointlessly overlong lines.
I assume you mean separate read and write functions instead of using the write
flag?
These are based on the existing device private functions which themselves
looked to be based on the migration entry functions. It would be good to keep
these consistent so when making the changes above I would also refactor the
existing make_device_private_entry() and make_migration_entry() functions to
match as well.
As a test I tried refactoring the migration entry functions into the below and
it seemed to make things a bit easier to follow if not a little verbose:
static inline int is_writable_migration_entry(swp_entry_t entry);
static inline swp_entry_t make_readable_migration_entry(pgoff_t offset);
static inline swp_entry_t make_writable_migration_entry(pgoff_t offset);
static inline int is_migration_entry(swp_entry_t entry);
So I can do that along with the same refactoring of device private accessor
functions as a prep patch if that seems reasonable
Re: [PATCH] drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features
On Mon, Feb 22, 2021 at 3:21 PM Andrzej Hajda wrote:
>
> Hi Nicolas,
>
> W dniu 22.02.2021 o 06:31, Nicolas Boichat pisze:
> > On Mon, Feb 22, 2021 at 3:08 AM Laurent Pinchart
> > wrote:
> >> Hi Nicolas,
> >>
> >> Thank you for the patch.
> >>
> >> On Thu, Feb 11, 2021 at 11:33:55AM +0800, Nicolas Boichat wrote:
> >>> Many of the DSI flags have names opposite to their actual effects,
> >>> e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually
> >>> be disabled. Fix this by including _NO_ in the flag names, e.g.
> >>> MIPI_DSI_MODE_NO_EOT_PACKET.
> >>>
> >>> Signed-off-by: Nicolas Boichat
> >> This looks good to me, it increases readability.
> >>
> >> Reviewed-by: Laurent Pinchart
> >>
> >> Please however see the end of the mail for a comment.
>
>
> Reviewed-by: Andrzej Hajda
>
> And comment at the end.
>
> >>
> >>> ---
> >>> I considered adding _DISABLE_ instead, but that'd make the
> >>> flag names a big too long.
> >>>
> >>> Generated with:
> >>> flag=MIPI_DSI_MODE_VIDEO_HFP; git grep $flag | cut -f1 -d':' | \
> >>>xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HFP/" {}
> >>> flag=MIPI_DSI_MODE_VIDEO_HBP; git grep $flag | cut -f1 -d':' | \
> >>>xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HBP/" {}
> >>> flag=MIPI_DSI_MODE_VIDEO_HSA; git grep $flag | cut -f1 -d':' | \
> >>>xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HSA/" {}
> >>> flag=MIPI_DSI_MODE_EOT_PACKET; git grep $flag | cut -f1 -d':' | \
> >>>xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_NO_EOT_PACKET/" {}
> >>> (then minor format changes)
> >> Ever tried coccinelle ? :-)
> > Fun project for next time ,-)
> >
> >>> drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +-
> >>> drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
> >>> drivers/gpu/drm/bridge/cdns-dsi.c| 4 ++--
> >>> drivers/gpu/drm/bridge/tc358768.c| 2 +-
> >>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8
> >>> drivers/gpu/drm/mcde/mcde_dsi.c | 2 +-
> >>> drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
> >>> drivers/gpu/drm/msm/dsi/dsi_host.c | 8
> >>> drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c | 2 +-
> >>> drivers/gpu/drm/panel/panel-dsi-cm.c | 2 +-
> >>> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +-
> >>> drivers/gpu/drm/panel/panel-khadas-ts050.c | 2 +-
> >>> drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 2 +-
> >>> drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> >>> drivers/gpu/drm/panel/panel-novatek-nt35510.c| 2 +-
> >>> drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c | 2 +-
> >>> drivers/gpu/drm/panel/panel-samsung-s6d16d0.c| 2 +-
> >>> drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 2 +-
> >>> drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c| 2 +-
> >>> drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 4 ++--
> >>> drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 2 +-
> >>> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> >>> drivers/gpu/drm/panel/panel-sony-acx424akp.c | 2 +-
> >>> drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c | 2 +-
> >>> include/drm/drm_mipi_dsi.h | 8
> >>> 25 files changed, 36 insertions(+), 36 deletions(-)
> >>>
> >>> []
> >>> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> >>> index 360e6377e84b..ba91cf22af51 100644
> >>> --- a/include/drm/drm_mipi_dsi.h
> >>> +++ b/include/drm/drm_mipi_dsi.h
> >>> @@ -119,15 +119,15 @@ struct mipi_dsi_host
> >>> *of_find_mipi_dsi_host_by_node(struct device_node *node);
> >>> /* enable hsync-end packets in vsync-pulse and v-porch area */
> >>> #define MIPI_DSI_MODE_VIDEO_HSE BIT(4)
> >> We're mixing bits that enable a feature and bits that disable a feature.
> >> Are these bits defined in the DSI spec, or internal to DRM ? In the
> >> latter case, would it make sense to standardize on one "polarity" ? That
> >> would be a more intrusive change in drivers though.
> > Yes, that'd require auditing every single code path and reverse the
> > logic as needed. I'm not volunteering for that ,-P (hopefully the
> > current change is still an improvement).
> >
> > Hopefully real DSI experts can comment (Andrzej?), I think the default
> > are sensible settings?
>
> Hehe, "real DSI expert" :), ok I've read spec few times :)
>
> If I remember correctly the spec did not prioritizes these modes, specs
> are publicly available if somebody want to check it feel free.
>
> These values were taken from defaults for Exynos DSI, as nobody at the
> time has better idea.
>
> We could try to optimize it by looking for example in different dsi
> hosts defaults, or maybe dsi devices, but I am not sure if it is worth time.
Little git grep experiment:
# git grep compatible -- drivers/gpu/drm/panel
Re: [PATCH] doc: use KCFLAGS instead of EXTRA_CFLAGS to pass flags from command line
On 2021-02-21 16:25, Masahiro Yamada wrote:
You should use KCFLAGS to pass additional compiler flags from the
command line. Using EXTRA_CFLAGS is wrong.
EXTRA_CFLAGS is supposed to specify flags applied only to the current
Makefile (and now deprecated in favor of ccflags-y).
It is still used in arch/mips/kvm/Makefile (and possibly in external
modules too). Passing EXTRA_CFLAGS from the command line overwrites
it and breaks the build.
I also fixed drivers/gpu/drm/tilcdc/Makefile because commit
816175dd1fd7
("drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in
EXTRA_CFLAGS") was based on the same misunderstanding.
Signed-off-by: Masahiro Yamada
---
Documentation/process/4.Coding.rst| 2 +-
Documentation/process/submit-checklist.rst| 2 +-
Documentation/translations/it_IT/process/4.Coding.rst | 2 +-
Documentation/translations/it_IT/process/submit-checklist.rst | 2 +-
Documentation/translations/zh_CN/process/4.Coding.rst | 2 +-
drivers/gpu/drm/tilcdc/Makefile | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
Acked-by: Federico Vaga
--
Federico Vaga
http://www.federicovaga.it/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
KMSAN: kernel-infoleak in compat_drm_wait_vblank
Hello, syzbot found the following issue on: HEAD commit:29ad81a1 arch/x86: add missing include to sparsemem.h git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=111e6312d0 kernel config: https://syzkaller.appspot.com/x/.config?x=c8e3b38ca92283e dashboard link: https://syzkaller.appspot.com/bug?extid=620cf21140fc7e772a5d compiler: Debian clang version 11.0.1-2 userspace arch: i386 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+620cf21140fc7e772...@syzkaller.appspotmail.com = BUG: KMSAN: kernel-infoleak in kmsan_copy_to_user+0x9c/0xb0 mm/kmsan/kmsan_hooks.c:249 CPU: 1 PID: 26999 Comm: syz-executor.2 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:120 kmsan_report+0xfb/0x1e0 mm/kmsan/kmsan_report.c:118 kmsan_internal_check_memory+0x484/0x520 mm/kmsan/kmsan.c:437 kmsan_copy_to_user+0x9c/0xb0 mm/kmsan/kmsan_hooks.c:249 instrument_copy_to_user include/linux/instrumented.h:121 [inline] _copy_to_user+0x1ac/0x270 lib/usercopy.c:33 copy_to_user include/linux/uaccess.h:209 [inline] compat_drm_wait_vblank+0x36f/0x450 drivers/gpu/drm/drm_ioc32.c:866 drm_compat_ioctl+0x3f6/0x590 drivers/gpu/drm/drm_ioc32.c:995 __do_compat_sys_ioctl fs/ioctl.c:842 [inline] __se_compat_sys_ioctl+0x53d/0x1100 fs/ioctl.c:793 __ia32_compat_sys_ioctl+0x4a/0x70 fs/ioctl.c:793 do_syscall_32_irqs_on arch/x86/entry/common.c:79 [inline] __do_fast_syscall_32+0x102/0x160 arch/x86/entry/common.c:141 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:166 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:209 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c RIP: 0023:0xf7f47549 Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:f55415fc EFLAGS: 0296 ORIG_RAX: 0036 RAX: ffda RBX: 0003 RCX: c018643a RDX: 2100 RSI: RDI: RBP: R08: R09: R10: R11: R12: R13: R14: R15: Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 compat_drm_wait_vblank+0x43c/0x450 drivers/gpu/drm/drm_ioc32.c:865 drm_compat_ioctl+0x3f6/0x590 drivers/gpu/drm/drm_ioc32.c:995 __do_compat_sys_ioctl fs/ioctl.c:842 [inline] __se_compat_sys_ioctl+0x53d/0x1100 fs/ioctl.c:793 __ia32_compat_sys_ioctl+0x4a/0x70 fs/ioctl.c:793 do_syscall_32_irqs_on arch/x86/entry/common.c:79 [inline] __do_fast_syscall_32+0x102/0x160 arch/x86/entry/common.c:141 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:166 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:209 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c Local variable req@compat_drm_wait_vblank created at: compat_drm_wait_vblank+0x7b/0x450 drivers/gpu/drm/drm_ioc32.c:849 compat_drm_wait_vblank+0x7b/0x450 drivers/gpu/drm/drm_ioc32.c:849 Bytes 12-15 of 16 are uninitialized Memory access of size 16 starts at 88814ffe3c98 Data copied to user address 2100 = --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm/prime: Only call dma_map_sgtable() for devices with DMA support
USB-based drivers cannot use DMA, so the importing of dma-buf attachments currently fails for udl and gm12u320. This breaks joining/mirroring of displays. The fix is now a little series. To solve the issue on the importer side (i.e., the affected USB-based driver), patch 1 introduces a new PRIME callback, struct drm_driver.gem_prime_create_object, which creates an object and gives more control to the importing driver. Specifically, udl and gm12u320 can now avoid the creation of a scatter/gather table for the imported pages. Patch 1 is self-contained in the sense that it can be backported into older kernels. Patches 2 and 3 update SHMEM and CMA helpers to use the new callback. Effectively this moves the sg table setup from the PRIME helpers into the memory managers. SHMEM now supports devices without DMA support, so custom code can be removed from udl and g12u320. Tested by joining/mirroring displays of udl and radeon under Gnome/X11. v2: * move fix to importer side (Christian, Daniel) * update SHMEM and CMA helpers for new PRIME callbacks Thomas Zimmermann (3): drm: Support importing dmabufs into drivers without DMA drm/shmem-helper: Implement struct drm_driver.gem_prime_create_object drm/cma-helper: Implement struct drm_driver.gem_prime_create_object drivers/gpu/drm/drm_gem_cma_helper.c| 62 ++--- drivers/gpu/drm/drm_gem_shmem_helper.c | 38 ++- drivers/gpu/drm/drm_prime.c | 43 +++-- drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_gem.c | 6 +-- drivers/gpu/drm/panfrost/panfrost_gem.h | 4 +- drivers/gpu/drm/pl111/pl111_drv.c | 8 ++-- drivers/gpu/drm/v3d/v3d_bo.c| 6 +-- drivers/gpu/drm/v3d/v3d_drv.c | 2 +- drivers/gpu/drm/v3d/v3d_drv.h | 5 +- include/drm/drm_drv.h | 12 + include/drm/drm_gem_cma_helper.h| 12 ++--- include/drm/drm_gem_shmem_helper.h | 6 +-- 14 files changed, 120 insertions(+), 88 deletions(-) -- 2.30.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm: Support importing dmabufs into drivers without DMA
USB devices cannot perform DMA and hence have no dma_mask set in their
device structure. Importing dmabuf into a USB-based driver fails, which
break joining and mirroring of display in X11. A corresponding error
message is shown below.
[ 60.050199] [ cut here ]
[ 60.055092] WARNING: CPU: 0 PID: 1403 at kernel/dma/mapping.c:190
dma_map_sg_attrs+0x8f/0xc0
[ 60.064331] Modules linked in: af_packet(E) rfkill(E) dmi_sysfs(E)
intel_rapl_msr(E) intel_rapl_common(E) snd_hda_codec_realtek(E)
snd_hda_codec_generic(E) ledtrig_audio(E) snd_hda_codec_hdmi(E)
x86_pkg_temp_thermal(E) intel_powerclam)
[ 60.064801] wmi(E) video(E) btrfs(E) blake2b_generic(E) libcrc32c(E)
crc32c_intel(E) xor(E) raid6_pq(E) sg(E) dm_multipath(E) dm_mod(E)
scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) msr(E) efivarfs(E)
[ 60.170778] CPU: 0 PID: 1403 Comm: Xorg.bin Tainted: GE
5.11.0-rc5-1-default+ #747
[ 60.179841] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24
10/24/2018
[ 60.187145] RIP: 0010:dma_map_sg_attrs+0x8f/0xc0
[ 60.191822] Code: 4d 85 ff 75 2b 49 89 d8 44 89 e1 44 89 f2 4c 89 ee 48 89
ef e8 62 30 00 00 85 c0 78 36 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 0b <0f> 0b 31
c0 eb ed 49 8d 7f 50 e8 72 f5 2a 00 49 8b 47 50 49 89 d8
[ 60.210770] RSP: 0018:c90001d6fc18 EFLAGS: 00010246
[ 60.216062] RAX: RBX: 0020 RCX: b31e677b
[ 60.223274] RDX: dc00 RSI: 888212c10600 RDI: 8881b08a9488
[ 60.230501] RBP: 8881b08a9030 R08: 0020 R09: 888212c10600
[ 60.237710] R10: ed10425820df R11: 0001 R12:
[ 60.244939] R13: 888212c10600 R14: 0008 R15:
[ 60.252155] FS: 7f08ac2b2f00() GS:8887cbe0()
knlGS:
[ 60.260333] CS: 0010 DS: ES: CR0: 80050033
[ 60.266150] CR2: 55831c899be8 CR3: 00015372e006 CR4: 001706f0
[ 60.273369] Call Trace:
[ 60.275845] drm_gem_map_dma_buf+0xb4/0x120
[ 60.280089] dma_buf_map_attachment+0x15d/0x1e0
[ 60.284688] drm_gem_prime_import_dev.part.0+0x5d/0x140
[ 60.289984] drm_gem_prime_fd_to_handle+0x213/0x280
[ 60.294931] ? drm_prime_destroy_file_private+0x30/0x30
[ 60.300224] drm_ioctl_kernel+0x131/0x180
[ 60.304291] ? drm_setversion+0x230/0x230
[ 60.308366] ? drm_prime_destroy_file_private+0x30/0x30
[ 60.313659] drm_ioctl+0x2f1/0x500
[ 60.317118] ? drm_version+0x150/0x150
[ 60.320903] ? lock_downgrade+0xa0/0xa0
[ 60.324806] ? do_vfs_ioctl+0x5f4/0x680
[ 60.328694] ? __fget_files+0x13e/0x210
[ 60.332591] ? ioctl_fiemap.isra.0+0x1a0/0x1a0
[ 60.337102] ? __fget_files+0x15d/0x210
[ 60.340990] __x64_sys_ioctl+0xb9/0xf0
[ 60.344795] do_syscall_64+0x33/0x80
[ 60.348427] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 60.353542] RIP: 0033:0x7f08ac7b53cb
[ 60.357168] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff ff ff
85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 75 ba 0c 00 f7 d8 64 89 01 48
[ 60.376108] RSP: 002b:7ffeabc89fc8 EFLAGS: 0246 ORIG_RAX:
0010
[ 60.383758] RAX: ffda RBX: 7ffeabc8a00c RCX: 7f08ac7b53cb
[ 60.390970] RDX: 7ffeabc8a00c RSI: c00c642e RDI: 000d
[ 60.398221] RBP: c00c642e R08: 55831c691d00 R09: 55831b2ec010
[ 60.405446] R10: 7f08acf6ada0 R11: 0246 R12: 55831c691d00
[ 60.412667] R13: 000d R14: 007e9000 R15:
[ 60.419903] irq event stamp: 672893
[ 60.423441] hardirqs last enabled at (672913): []
console_unlock+0x44d/0x500
[ 60.432230] hardirqs last disabled at (672922): []
console_unlock+0x443/0x500
[ 60.441021] softirqs last enabled at (672940): []
__do_softirq+0x3dd/0x554
[ 60.449634] softirqs last disabled at (672931): []
asm_call_irq_on_stack+0x12/0x20
[ 60.458871] ---[ end trace f2f88696eb17806c ]---
This patch introduces struct drm_driver.gem_prime_create_object, which
creates a GEM object during the import. Drivers should implement this
callback and handle DMA S/G table support by themselves. For USB-based
drivers, the patch adds an implementation without DMA-related code.
The original interface struct drm_driver.gem_prime_import_sg_table
is deprecated. All drivers should switch over.
Tested by joining/mirroring displays of udl and radeon un der Gnome/X11.
Signed-off-by: Thomas Zimmermann
Fixes: 6eb0233ec2d0 ("usb: don't inherity DMA properties for USB devices")
Cc: Christoph Hellwig
Cc: Greg Kroah-Hartman
Cc: Alan Stern
Cc: Johan Hovold
Cc: Andy Shevchenko
Cc: Sebastian Andrzej Siewior
Cc: Mathias Nyman
Cc: "Ahmed S. Darwish"
Cc: Oliver Neukum
Cc: Thomas Gleixner
Cc: Felipe Balbi
Cc: # v5.10+
---
drivers/gpu/drm/drm_prime.c | 43 +
drivers/gpu/drm/tiny/gm12u320.c | 7 +
[PATCH v2 2/3] drm/shmem-helper: Implement struct drm_driver.gem_prime_create_object
Moves the scatter/gather-table setup from PRIME helpers into SHMEM
helpers. USB-based drivers don't support DMA, so make the sg table
optional. This cleans up rsp code in udl and gm12u320.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 38 +
drivers/gpu/drm/lima/lima_drv.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_gem.c | 6 ++--
drivers/gpu/drm/panfrost/panfrost_gem.h | 4 +--
drivers/gpu/drm/tiny/gm12u320.c | 7 -
drivers/gpu/drm/udl/udl_drv.c | 7 -
drivers/gpu/drm/v3d/v3d_bo.c| 6 ++--
drivers/gpu/drm/v3d/v3d_drv.c | 2 +-
drivers/gpu/drm/v3d/v3d_drv.h | 5 ++--
include/drm/drm_gem_shmem_helper.h | 6 ++--
11 files changed, 38 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index c8a6547a1757..d11154ec0db5 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -711,36 +711,50 @@ struct sg_table *drm_gem_shmem_get_pages_sgt(struct
drm_gem_object *obj)
EXPORT_SYMBOL_GPL(drm_gem_shmem_get_pages_sgt);
/**
- * drm_gem_shmem_prime_import_sg_table - Produce a shmem GEM object from
- * another driver's scatter/gather table of pinned pages
+ * drm_gem_shmem_prime_create_object - Produce a shmem GEM object from
+ * another driver's DMA-BUF attachment
* @dev: Device to import into
* @attach: DMA-BUF attachment
- * @sgt: Scatter/gather table of pinned pages
*
- * This function imports a scatter/gather table exported via DMA-BUF by
- * another driver. Drivers that use the shmem helpers should set this as their
- * &drm_driver.gem_prime_import_sg_table callback.
+ * This function imports a DMA-BUF attachment exported by another driver.
+ * If supported, it sets a scatter/gather table of pinned pages. Drivers
+ * that use the shmem helpers should set this as their
+ * &drm_driver.gem_prime_create_object callback.
*
* Returns:
* A pointer to a newly created GEM object or an ERR_PTR-encoded negative
* error code on failure.
*/
struct drm_gem_object *
-drm_gem_shmem_prime_import_sg_table(struct drm_device *dev,
- struct dma_buf_attachment *attach,
- struct sg_table *sgt)
+drm_gem_shmem_prime_create_object(struct drm_device *dev,
+ struct dma_buf_attachment *attach)
{
size_t size = PAGE_ALIGN(attach->dmabuf->size);
+ struct sg_table *sgt = NULL;
struct drm_gem_shmem_object *shmem;
+ int ret;
+
+ if (dev->dev->dma_mask) {
+ sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+ if (IS_ERR(sgt))
+ return ERR_CAST(sgt);
+ }
shmem = __drm_gem_shmem_create(dev, size, true);
- if (IS_ERR(shmem))
- return ERR_CAST(shmem);
+ if (IS_ERR(shmem)) {
+ ret = PTR_ERR(shmem);
+ goto err;
+ }
shmem->sgt = sgt;
DRM_DEBUG_PRIME("size = %zu\n", size);
return &shmem->base;
+
+err:
+ if (sgt)
+ dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+ return ERR_PTR(ret);
}
-EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
+EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_create_object);
diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index 7b8d7178d09a..c8090289ecc7 100644
--- a/drivers/gpu/drm/lima/lima_drv.c
+++ b/drivers/gpu/drm/lima/lima_drv.c
@@ -277,8 +277,8 @@ static const struct drm_driver lima_drm_driver = {
.gem_create_object = lima_gem_create_object,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_import_sg_table = drm_gem_shmem_prime_import_sg_table,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .gem_prime_create_object = drm_gem_shmem_prime_create_object,
.gem_prime_mmap = drm_gem_prime_mmap,
};
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 83a461bdeea8..8c0979e1926e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -564,7 +564,7 @@ static const struct drm_driver panfrost_drm_driver = {
.gem_create_object = panfrost_gem_create_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_import_sg_table = panfrost_gem_prime_import_sg_table,
+ .gem_prime_create_object = panfrost_gem_prime_create_object,
.gem_prime_mmap = drm_gem_prime_mmap,
};
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 3e0723bc36bd..69bb70180ac1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++
[PATCH v2 3/3] drm/cma-helper: Implement struct drm_driver.gem_prime_create_object
Moves the scatter/gather-table setup from PRIME helpers into CMA
helpers. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_cma_helper.c | 62
drivers/gpu/drm/pl111/pl111_drv.c| 8 ++--
include/drm/drm_gem_cma_helper.h | 12 ++
3 files changed, 42 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 7942cf05cd93..7200d0ae2e38 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -404,37 +404,44 @@ struct sg_table *drm_gem_cma_get_sg_table(struct
drm_gem_object *obj)
EXPORT_SYMBOL_GPL(drm_gem_cma_get_sg_table);
/**
- * drm_gem_cma_prime_import_sg_table - produce a CMA GEM object from another
- * driver's scatter/gather table of pinned pages
+ * drm_gem_cma_prime_create_object - produce a CMA GEM object from another
+ * driver's DMA-BUF attachment
* @dev: device to import into
* @attach: DMA-BUF attachment
- * @sgt: scatter/gather table of pinned pages
*
- * This function imports a scatter/gather table exported via DMA-BUF by
- * another driver. Imported buffers must be physically contiguous in memory
- * (i.e. the scatter/gather table must contain a single entry). Drivers that
- * use the CMA helpers should set this as their
- * &drm_driver.gem_prime_import_sg_table callback.
+ * This function imports a DMA-BUF exported by another driver. It sets a
+ * scatter/gather table of pinned pages. Imported buffers must be physically
+ * contiguous in memory (i.e. the scatter/gather table must contain a single
+ * entry). Drivers that use the CMA helpers should set this as their
+ * &drm_driver.gem_prime_create_object callback.
*
* Returns:
* A pointer to a newly created GEM object or an ERR_PTR-encoded negative
* error code on failure.
*/
struct drm_gem_object *
-drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
- struct dma_buf_attachment *attach,
- struct sg_table *sgt)
+drm_gem_cma_prime_create_object(struct drm_device *dev, struct
dma_buf_attachment *attach)
{
+ struct sg_table *sgt;
struct drm_gem_cma_object *cma_obj;
+ int ret;
+
+ sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+ if (IS_ERR(sgt))
+ return ERR_CAST(sgt);
/* check if the entries in the sg_table are contiguous */
- if (drm_prime_get_contiguous_size(sgt) < attach->dmabuf->size)
- return ERR_PTR(-EINVAL);
+ if (drm_prime_get_contiguous_size(sgt) < attach->dmabuf->size) {
+ ret = -EINVAL;
+ goto err;
+ }
/* Create a CMA GEM buffer. */
cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size);
- if (IS_ERR(cma_obj))
- return ERR_CAST(cma_obj);
+ if (IS_ERR(cma_obj)) {
+ ret = PTR_ERR(cma_obj);
+ goto err;
+ }
cma_obj->paddr = sg_dma_address(sgt->sgl);
cma_obj->sgt = sgt;
@@ -442,8 +449,12 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
DRM_DEBUG_PRIME("dma_addr = %pad, size = %zu\n", &cma_obj->paddr,
attach->dmabuf->size);
return &cma_obj->base;
+
+err:
+ dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+ return ERR_PTR(ret);
}
-EXPORT_SYMBOL_GPL(drm_gem_cma_prime_import_sg_table);
+EXPORT_SYMBOL_GPL(drm_gem_cma_prime_create_object);
/**
* drm_gem_cma_vmap - map a CMA GEM object into the kernel's virtual
@@ -509,18 +520,17 @@ int drm_gem_cma_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
/**
- * drm_gem_cma_prime_import_sg_table_vmap - PRIME import another driver's
- * scatter/gather table and get the virtual address of the buffer
+ * drm_gem_cma_prime_create_object_vmap - produce a CMA GEM object from another
+ * driver's DMA-BUF attachment and gets the virtual address of the buffer
* @dev: DRM device
* @attach: DMA-BUF attachment
- * @sgt: Scatter/gather table of pinned pages
*
- * This function imports a scatter/gather table using
- * drm_gem_cma_prime_import_sg_table() and uses dma_buf_vmap() to get the
kernel
+ * This function imports a DMA-BUF using
+ * drm_gem_cma_prime_create_object() and uses dma_buf_vmap() to get the kernel
* virtual address. This ensures that a CMA GEM object always has its virtual
* address set. This address is released when the object is freed.
*
- * This function can be used as the &drm_driver.gem_prime_import_sg_table
+ * This function can be used as the &drm_driver.gem_prime_create_object
* callback. The &DRM_GEM_CMA_DRIVER_OPS_VMAP macro provides a shortcut to set
* the necessary DRM driver operations.
*
@@ -529,9 +539,7 @@ EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
* error code on failure.
*/
struct drm_gem_object *
-drm_gem_cma_prime_import_sg_table_vmap(struct dr
Re: [PATCH v2 0/3] drm/prime: Only call dma_map_sgtable() for devices with DMA support
Am 22.02.21 um 13:43 schrieb Thomas Zimmermann: USB-based drivers cannot use DMA, so the importing of dma-buf attachments currently fails for udl and gm12u320. This breaks joining/mirroring of displays. The fix is now a little series. To solve the issue on the importer side (i.e., the affected USB-based driver), patch 1 introduces a new PRIME callback, struct drm_driver.gem_prime_create_object, which creates an object and gives more control to the importing driver. Specifically, udl and gm12u320 can now avoid the creation of a scatter/gather table for the imported pages. Patch 1 is self-contained in the sense that it can be backported into older kernels. Mhm, that sounds like a little overkill to me. Drivers can already import the DMA-bufs all by them selves without the help of the DRM functions. See amdgpu for an example. Daniel also already noted to me that he sees the DRM helper as a bit questionable middle layer. Have you thought about doing that instead? Christian. Patches 2 and 3 update SHMEM and CMA helpers to use the new callback. Effectively this moves the sg table setup from the PRIME helpers into the memory managers. SHMEM now supports devices without DMA support, so custom code can be removed from udl and g12u320. Tested by joining/mirroring displays of udl and radeon under Gnome/X11. v2: * move fix to importer side (Christian, Daniel) * update SHMEM and CMA helpers for new PRIME callbacks Thomas Zimmermann (3): drm: Support importing dmabufs into drivers without DMA drm/shmem-helper: Implement struct drm_driver.gem_prime_create_object drm/cma-helper: Implement struct drm_driver.gem_prime_create_object drivers/gpu/drm/drm_gem_cma_helper.c| 62 ++--- drivers/gpu/drm/drm_gem_shmem_helper.c | 38 ++- drivers/gpu/drm/drm_prime.c | 43 +++-- drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_gem.c | 6 +-- drivers/gpu/drm/panfrost/panfrost_gem.h | 4 +- drivers/gpu/drm/pl111/pl111_drv.c | 8 ++-- drivers/gpu/drm/v3d/v3d_bo.c| 6 +-- drivers/gpu/drm/v3d/v3d_drv.c | 2 +- drivers/gpu/drm/v3d/v3d_drv.h | 5 +- include/drm/drm_drv.h | 12 + include/drm/drm_gem_cma_helper.h| 12 ++--- include/drm/drm_gem_shmem_helper.h | 6 +-- 14 files changed, 120 insertions(+), 88 deletions(-) -- 2.30.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/prime: Only call dma_map_sgtable() for devices with DMA support
Hi Am 22.02.21 um 14:09 schrieb Christian König: Am 22.02.21 um 13:43 schrieb Thomas Zimmermann: USB-based drivers cannot use DMA, so the importing of dma-buf attachments currently fails for udl and gm12u320. This breaks joining/mirroring of displays. The fix is now a little series. To solve the issue on the importer side (i.e., the affected USB-based driver), patch 1 introduces a new PRIME callback, struct drm_driver.gem_prime_create_object, which creates an object and gives more control to the importing driver. Specifically, udl and gm12u320 can now avoid the creation of a scatter/gather table for the imported pages. Patch 1 is self-contained in the sense that it can be backported into older kernels. Mhm, that sounds like a little overkill to me. Drivers can already import the DMA-bufs all by them selves without the help of the DRM functions. See amdgpu for an example. Daniel also already noted to me that he sees the DRM helper as a bit questionable middle layer. And this bug proves that it is. :) Have you thought about doing that instead? There appears to be some useful code in drm_gem_prime_import_dev(). But if the general sentiment goes towards removing gem_prime_import_sg_table, we can work towards that as well. Best regards Thomas Christian. Patches 2 and 3 update SHMEM and CMA helpers to use the new callback. Effectively this moves the sg table setup from the PRIME helpers into the memory managers. SHMEM now supports devices without DMA support, so custom code can be removed from udl and g12u320. Tested by joining/mirroring displays of udl and radeon under Gnome/X11. v2: * move fix to importer side (Christian, Daniel) * update SHMEM and CMA helpers for new PRIME callbacks Thomas Zimmermann (3): drm: Support importing dmabufs into drivers without DMA drm/shmem-helper: Implement struct drm_driver.gem_prime_create_object drm/cma-helper: Implement struct drm_driver.gem_prime_create_object drivers/gpu/drm/drm_gem_cma_helper.c | 62 ++--- drivers/gpu/drm/drm_gem_shmem_helper.c | 38 ++- drivers/gpu/drm/drm_prime.c | 43 +++-- drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_gem.c | 6 +-- drivers/gpu/drm/panfrost/panfrost_gem.h | 4 +- drivers/gpu/drm/pl111/pl111_drv.c | 8 ++-- drivers/gpu/drm/v3d/v3d_bo.c | 6 +-- drivers/gpu/drm/v3d/v3d_drv.c | 2 +- drivers/gpu/drm/v3d/v3d_drv.h | 5 +- include/drm/drm_drv.h | 12 + include/drm/drm_gem_cma_helper.h | 12 ++--- include/drm/drm_gem_shmem_helper.h | 6 +-- 14 files changed, 120 insertions(+), 88 deletions(-) -- 2.30.1 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/6] Add Unisoc's drm kms module
ChangeList: RFC v1: 1. only upstream modeset and atomic at first commit. 2. remove some unused code; 3. use alpha and blend_mode properties; 3. add yaml support; 4. remove auto-adaptive panel driver; 5. bugfix RFC v2: 1. add sprd crtc and plane module for KMS, preparing for multi crtc&encoder 2. remove gem drivers, use generic CMA handlers 3. remove redundant "module_init", all the sub modules loading by KMS RFC v3: 1. multi crtc&encoder design have problem, so rollback to v1 RFC v4: 1. update to gcc-linaro-7.5.0 2. update to Linux 5.6-rc3 3. remove pm_runtime support 4. add COMPILE_TEST, remove unused kconfig 5. "drm_dev_put" on drm_unbind 6. fix some naming convention issue 7. remove semaphore lock for crtc flip 8. remove static variables RFC v5: 1. optimize encoder and connector code implementation 2. use "platform_get_irq" and "platform_get_resource" 3. drop useless function return type, drop unless debug log 4. custom properties should be separate, so drop it 5. use DRM_XXX replase pr_xxx 6. drop dsi&dphy hal callback ops 7. drop unless callback ops checking 8. add comments for sprd dpu structure RFC v6: 1. Access registers via readl/writel 2. Checking for unsupported KMS properties (format, rotation, blend_mode, etc) on plane_check ops 3. Remove always true checks for dpu core ops RFC v7: 1. Fix DTC unit name warnings 2. Fix the problem of maintainers 3. Call drmm_mode_config_init to mode config init 4. Embed drm_device in sprd_drm and use devm_drm_dev_alloc 5. Replace DRM_XXX with drm_xxx on KMS module, but not suitable for other subsystems 6. Remove plane_update stuff, dpu handles all the HW update in crtc->atomic_flush 7. Dsi&Dphy Code structure adjustment, all move to "sprd/" v0: 1. Remove dpu_core_ops stuff layer for sprd drtc driver, but dpu_layer need to keeping. Because all the HW update in crtc->atomic_flush, we need temporary storage all layers for the dpu pageflip of atomic_flush. 2. Add ports subnode with port@X. v1: 1. Remove dphy and dsi graph binding, merge the dphy driver into the dsi. 2. Add commit messages for Unisoc's virtual nodes. v2: 1. Use drm_xxx to replace all DRM_XXX. 2. Use kzalloc to replace devm_kzalloc for sprd_dsi/sprd_dpu structure init. 3. Remove dpu_core_ops midlayer. v3: 1. Remove dpu_layer midlayer and commit layers by aotmic_update v4: 1. Move the devm_drm_dev_alloc to master_ops->bind function. 2. The managed drmm_mode_config_init() it is no longer necessary for drivers to explicitly call drm_mode_config_cleanup, so delete it. 3. Use drmm_helpers to allocate crtc ,planes and encoder. 4. Move allocate crtc ,planes, encoder to bind funtion. 5. Move rotation enum definitions to crtc layer reg bitfields. Kevin Tang (6): dt-bindings: display: add Unisoc's drm master bindings drm/sprd: add Unisoc's drm kms master dt-bindings: display: add Unisoc's dpu bindings drm/sprd: add Unisoc's drm display controller driver dt-bindings: display: add Unisoc's mipi dsi controller bindings drm/sprd: add Unisoc's drm mipi dsi&dphy driver .../display/sprd/sprd,display-subsystem.yaml | 64 + .../display/sprd/sprd,sharkl3-dpu.yaml| 77 + .../display/sprd/sprd,sharkl3-dsi-host.yaml | 102 ++ drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/sprd/Kconfig | 13 + drivers/gpu/drm/sprd/Makefile |8 + drivers/gpu/drm/sprd/dw_dsi_ctrl.c| 794 + drivers/gpu/drm/sprd/dw_dsi_ctrl.h| 1475 + drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c| 157 ++ drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h| 26 + drivers/gpu/drm/sprd/megacores_pll.c | 317 drivers/gpu/drm/sprd/megacores_pll.h | 146 ++ drivers/gpu/drm/sprd/sprd_dpu.c | 964 +++ drivers/gpu/drm/sprd/sprd_dpu.h | 109 ++ drivers/gpu/drm/sprd/sprd_drm.c | 219 +++ drivers/gpu/drm/sprd/sprd_drm.h | 19 + drivers/gpu/drm/sprd/sprd_dsi.c | 1132 + drivers/gpu/drm/sprd/sprd_dsi.h | 104 ++ 19 files changed, 5729 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml create mode 100644 Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml create mode 100644 Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml create mode 100644 drivers/gpu/drm/sprd/Kconfig create mode 100644 drivers/gpu/drm/sprd/Makefile create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.c create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.h create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c create mode 100644 drivers/gpu/drm/sprd/megacores_pll.h create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c create mode 10
[PATCH v4 1/6] dt-bindings: display: add Unisoc's drm master bindings
From: Kevin Tang
The Unisoc DRM master device is a virtual device needed to list all
DPU devices or other display interface nodes that comprise the
graphics subsystem
Unisoc's display pipeline have several components as below
description, multi display controllers and corresponding physical interfaces.
For different display scenarios, dpu0 and dpu1 maybe binding to
different encoder.
E.g:
dpu0 and dpu1 both binding to DSI for dual mipi-dsi display;
dpu0 binding to DSI for primary display, and dpu1 binding to DP for external
display;
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
Reviewed-by: Rob Herring
---
.../display/sprd/sprd,display-subsystem.yaml | 64 +++
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
diff --git
a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
new file mode 100644
index 0..3d107e943
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/sprd,display-subsystem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc DRM master device
+
+maintainers:
+ - Kevin Tang
+
+description: |
+ The Unisoc DRM master device is a virtual device needed to list all
+ DPU devices or other display interface nodes that comprise the
+ graphics subsystem.
+
+ Unisoc's display pipeline have several components as below description,
+ multi display controllers and corresponding physical interfaces.
+ For different display scenarios, dpu0 and dpu1 maybe binding to different
+ encoder.
+
+ E.g:
+ dpu0 and dpu1 both binding to DSI for dual mipi-dsi display;
+ dpu0 binding to DSI for primary display, and dpu1 binding to DP for external
display;
+
+ +-+
+ | |
+ |+-+ |
+ ++ | +++-+|DPHY/CPHY| | +--+
+ |+->+dpu0+--->+MIPI|DSI +--->+Combo+->+Panel0|
+ |AXI | | +++-++-+ | +--+
+ || | ^ |
+ || | | |
+ || | +---+ |
+ || | | |
+ |APB | | +--+-++---++---+ | +--+
+ |+->+dpu1+--->+DisplayPort+--->+PHY+->+Panel1|
+ || | +++---++---+ | +--+
+ ++ | |
+ +-+
+
+properties:
+ compatible:
+const: sprd,display-subsystem
+
+ ports:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description:
+ Should contain a list of phandles pointing to display interface port
+ of DPU devices.
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+display-subsystem {
+compatible = "sprd,display-subsystem";
+ports = <&dpu_out>;
+};
+
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/6] drm/sprd: add Unisoc's drm kms master
Adds drm support for the Unisoc's display subsystem.
This is drm kms driver, this driver provides support for the
application framework in Android, Yocto and more.
Application framework can access Unisoc's display internel
peripherals through libdrm or libkms, it's test ok by modetest
(DRM/KMS test tool) and Android HWComposer.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
v4:
- Move the devm_drm_dev_alloc to master_ops->bind function.
- The managed drmm_mode_config_init() it is no longer necessary for drivers
to explicitly call drm_mode_config_cleanup, so delete it.
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/sprd/Kconfig| 12 ++
drivers/gpu/drm/sprd/Makefile | 5 +
drivers/gpu/drm/sprd/sprd_drm.c | 217
drivers/gpu/drm/sprd/sprd_drm.h | 16 +++
6 files changed, 253 insertions(+)
create mode 100644 drivers/gpu/drm/sprd/Kconfig
create mode 100644 drivers/gpu/drm/sprd/Makefile
create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8bf103de1..9d6ce2867 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -382,6 +382,8 @@ source "drivers/gpu/drm/tidss/Kconfig"
source "drivers/gpu/drm/xlnx/Kconfig"
+source "drivers/gpu/drm/sprd/Kconfig"
+
# Keep legacy drivers last
menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 02c229392..42d211d9c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -126,3 +126,4 @@ obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
obj-$(CONFIG_DRM_MCDE) += mcde/
obj-$(CONFIG_DRM_TIDSS) += tidss/
obj-y += xlnx/
+obj-$(CONFIG_DRM_SPRD) += sprd/
diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
new file mode 100644
index 0..6e80cc9f3
--- /dev/null
+++ b/drivers/gpu/drm/sprd/Kconfig
@@ -0,0 +1,12 @@
+config DRM_SPRD
+ tristate "DRM Support for Unisoc SoCs Platform"
+ depends on ARCH_SPRD || COMPILE_TEST
+ depends on DRM && OF
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DSI
+ help
+ Choose this option if you have a Unisoc chipset.
+ If M is selected the module will be called sprd_drm.
+
diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
new file mode 100644
index 0..86d95d93a
--- /dev/null
+++ b/drivers/gpu/drm/sprd/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
+subdir-ccflags-y += -I$(srctree)/$(src)
+
+obj-y := sprd_drm.o
diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
new file mode 100644
index 0..a1d3ed655
--- /dev/null
+++ b/drivers/gpu/drm/sprd/sprd_drm.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Unisoc Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sprd_drm.h"
+
+#define DRIVER_NAME"sprd"
+#define DRIVER_DESC"Spreadtrum SoCs' DRM Driver"
+#define DRIVER_DATE"20200201"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+static const struct drm_mode_config_helper_funcs sprd_drm_mode_config_helper =
{
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
+static const struct drm_mode_config_funcs sprd_drm_mode_config_funcs = {
+ .fb_create = drm_gem_fb_create,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static void sprd_drm_mode_config_init(struct drm_device *drm)
+{
+ drm->mode_config.min_width = 0;
+ drm->mode_config.min_height = 0;
+ drm->mode_config.max_width = 8192;
+ drm->mode_config.max_height = 8192;
+ drm->mode_config.allow_fb_modifiers = true;
+
+ drm->mode_config.funcs = &sprd_drm_mode_config_funcs;
+ drm->mode_config.helper_private = &sprd_drm_mode_config_helper;
+}
+
+DEFINE_DRM_GEM_CMA_FOPS(sprd_drm_fops);
+
+static struct drm_driver sprd_drm_drv = {
+ .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+ .fops = &sprd_drm_fops,
+
+ /* GEM Operations */
+ DRM_GEM_CMA_DRIVER_OPS,
+
+ .name = DRIVER_NAME,
+ .desc = DRIVER_DESC,
+ .date = DRIVER_DATE,
+ .major = DRIVER_MAJOR,
+ .minor = DRIVER_MINOR,
+};
+
+static int sprd_drm_bind(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct drm_device *drm;
+ struct sprd_drm *sprd;
+ int ret;
+
+ sprd = devm_drm_dev_alloc(dev, &sprd_drm_drv, struct sprd_drm, drm);
+ if (IS_ERR(sprd))
+ retur
[PATCH v4 3/6] dt-bindings: display: add Unisoc's dpu bindings
From: Kevin Tang
DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
which transfers the image data from a video memory buffer to an internal
LCD interface.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
Reviewed-by: Rob Herring
---
.../display/sprd/sprd,sharkl3-dpu.yaml| 77 +++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
diff --git
a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
new file mode 100644
index 0..4ebea60b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc Sharkl3 Display Processor Unit (DPU)
+
+maintainers:
+ - Kevin Tang
+
+description: |
+ DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
+ which transfers the image data from a video memory buffer to an internal
+ LCD interface.
+
+properties:
+ compatible:
+const: sprd,sharkl3-dpu
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+minItems: 2
+
+ clock-names:
+items:
+ - const: clk_src_128m
+ - const: clk_src_384m
+
+ power-domains:
+maxItems: 1
+
+ iommus:
+maxItems: 1
+
+ port:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the output endpoint, usually output to
+ the associated DSI.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+dpu: dpu@6300 {
+compatible = "sprd,sharkl3-dpu";
+reg = <0x6300 0x1000>;
+interrupts = ;
+clock-names = "clk_src_128m", "clk_src_384m";
+
+clocks = <&pll CLK_TWPLL_128M>,
+ <&pll CLK_TWPLL_384M>;
+
+dpu_port: port {
+dpu_out: endpoint {
+remote-endpoint = <&dsi_in>;
+};
+};
+};
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/6] dt-bindings: display: add Unisoc's mipi dsi controller bindings
From: Kevin Tang
Adds MIPI DSI Controller
support for Unisoc's display subsystem.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
Reviewed-by: Rob Herring
---
.../display/sprd/sprd,sharkl3-dsi-host.yaml | 102 ++
1 file changed, 102 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
diff --git
a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
new file mode 100644
index 0..d439f688f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dsi-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc MIPI DSI Controller
+
+maintainers:
+ - Kevin Tang
+
+properties:
+ compatible:
+const: sprd,sharkl3-dsi-host
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 2
+
+ clocks:
+minItems: 1
+
+ clock-names:
+items:
+ - const: clk_src_96m
+
+ power-domains:
+maxItems: 1
+
+ ports:
+type: object
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the input endpoint, usually coming from
+ the associated DPU.
+ port@1:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the output endpoint, usually output to
+ the associated panel.
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+dsi: dsi@6310 {
+compatible = "sprd,sharkl3-dsi-host";
+reg = <0x6310 0x1000>;
+interrupts = ,
+ ;
+clock-names = "clk_src_96m";
+clocks = <&pll CLK_TWPLL_96M>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+dsi_in: endpoint {
+remote-endpoint = <&dpu_out>;
+};
+};
+port@1 {
+reg = <1>;
+dsi_out: endpoint {
+remote-endpoint = <&panel_in>;
+};
+};
+};
+};
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/6] drm/sprd: add Unisoc's drm display controller driver
Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem. It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. Cc: Orson Zhai Cc: Chunyan Zhang Signed-off-by: Kevin Tang v2: - Use drm_xxx to replace all DRM_XXX. - Use kzalloc to replace devm_kzalloc for sprd_dpu structure init. v3: - Remove dpu_layer stuff layer and commit layers by aotmic_update v4: - Use drmm_helpers to allocate crtc and planes. - Move rotation enum definitions to crtc layer reg bitfields. - Move allocate crtc and planes to bind funtion. --- drivers/gpu/drm/sprd/Kconfig| 1 + drivers/gpu/drm/sprd/Makefile | 4 +- drivers/gpu/drm/sprd/sprd_dpu.c | 964 drivers/gpu/drm/sprd/sprd_dpu.h | 109 drivers/gpu/drm/sprd/sprd_drm.c | 1 + drivers/gpu/drm/sprd/sprd_drm.h | 2 + 6 files changed, 1079 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig index 6e80cc9f3..9b4ef9aea 100644 --- a/drivers/gpu/drm/sprd/Kconfig +++ b/drivers/gpu/drm/sprd/Kconfig @@ -3,6 +3,7 @@ config DRM_SPRD depends on ARCH_SPRD || COMPILE_TEST depends on DRM && OF select DRM_KMS_HELPER + select VIDEOMODE_HELPERS select DRM_GEM_CMA_HELPER select DRM_KMS_CMA_HELPER select DRM_MIPI_DSI diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile index 86d95d93a..6c25bfa99 100644 --- a/drivers/gpu/drm/sprd/Makefile +++ b/drivers/gpu/drm/sprd/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -subdir-ccflags-y += -I$(srctree)/$(src) +obj-y := sprd_drm.o \ + sprd_dpu.o -obj-y := sprd_drm.o diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c b/drivers/gpu/drm/sprd/sprd_dpu.c new file mode 100644 index 0..75b7e40d9 --- /dev/null +++ b/drivers/gpu/drm/sprd/sprd_dpu.c @@ -0,0 +1,964 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Unisoc Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include "sprd_drm.h" +#include "sprd_dpu.h" + +/* Global control registers */ +#define REG_DPU_CTRL 0x04 +#define REG_DPU_CFG0 0x08 +#define REG_PANEL_SIZE 0x20 +#define REG_BLEND_SIZE 0x24 +#define REG_BG_COLOR 0x2C + +/* Layer0 control registers */ +#define REG_LAY_BASE_ADDR0 0x30 +#define REG_LAY_BASE_ADDR1 0x34 +#define REG_LAY_BASE_ADDR2 0x38 +#define REG_LAY_CTRL 0x40 +#define REG_LAY_SIZE 0x44 +#define REG_LAY_PITCH 0x48 +#define REG_LAY_POS0x4C +#define REG_LAY_ALPHA 0x50 +#define REG_LAY_CROP_START 0x5C + +/* Interrupt control registers */ +#define REG_DPU_INT_EN 0x1E0 +#define REG_DPU_INT_CLR0x1E4 +#define REG_DPU_INT_STS0x1E8 + +/* DPI control registers */ +#define REG_DPI_CTRL 0x1F0 +#define REG_DPI_H_TIMING 0x1F4 +#define REG_DPI_V_TIMING 0x1F8 + +/* MMU control registers */ +#define REG_MMU_EN 0x800 +#define REG_MMU_VPN_RANGE 0x80C +#define REG_MMU_VAOR_ADDR_RD 0x818 +#define REG_MMU_VAOR_ADDR_WR 0x81C +#define REG_MMU_INV_ADDR_RD0x820 +#define REG_MMU_INV_ADDR_WR0x824 +#define REG_MMU_PPN1 0x83C +#define REG_MMU_RANGE1 0x840 +#define REG_MMU_PPN2 0x844 +#define REG_MMU_RANGE2 0x848 + +/* Global control bits */ +#define BIT_DPU_RUNBIT(0) +#define BIT_DPU_STOP BIT(1) +#define BIT_DPU_REG_UPDATE BIT(2) +#define BIT_DPU_IF_EDPIBIT(0) + +/* Layer control bits */ +#define BIT_DPU_LAY_EN BIT(0) +#define BIT_DPU_LAY_LAYER_ALPHA(0x01 << 2) +#define BIT_DPU_LAY_COMBO_ALPHA(0x02 << 2) +#define BIT_DPU_LAY_FORMAT_YUV422_2PLANE (0x00 << 4) +#define BIT_DPU_LAY_FORMAT_YUV420_2PLANE (0x01 << 4) +#define BIT_DPU_LAY_FORMAT_YUV420_3PLANE (0x02 << 4) +#define BIT_DPU_LAY_FORMAT_ARGB(0x03 << 4) +#define BIT_DPU_LAY_FORMAT_RGB565 (0x04 << 4) +#define BIT_DPU_LAY_DATA_ENDIAN_B0B1B2B3 (0x00 << 8) +#define BIT_DPU_LAY_DATA_ENDIAN_B3B2B1B0 (0x01 << 8) +#define BIT_DPU_LAY_NO_SWITCH (0x00 << 10) +#define BIT_DPU_LAY_RB_OR_UV_SWITCH(0x01 << 10) +#define BIT_DPU_LAY_MODE_BLEND_NORMAL (0x00 << 16) +#define BIT_DPU_LAY_MODE_BLEND_PREMULT (0x01 << 16) +#define BIT_DPU_LAY_ROTATION_0 (0x00 << 20) +#define BIT_DPU_LAY_ROTATION_90(0x01 << 20) +#define BIT_DPU_LAY_ROTATION_180 (0x02 << 20) +#de
[PATCH v4 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver
Adds dsi host controller support for the Unisoc's display subsystem.
Adds dsi phy support for the Unisoc's display subsystem.
Only MIPI DSI Displays supported, DP/TV/HMDI will be support
in the feature.
v1:
- Remove dphy and dsi graph binding, merge the dphy driver into the dsi.
v2:
- Use drm_xxx to replace all DRM_XXX.
- Use kzalloc to replace devm_kzalloc for sprd_dsi structure init.
v4:
- Use drmm_helpers to allocate encoder.
- Move allocate encoder and connector to bind funtion.
---
drivers/gpu/drm/sprd/Makefile |7 +-
drivers/gpu/drm/sprd/dw_dsi_ctrl.c | 794 +
drivers/gpu/drm/sprd/dw_dsi_ctrl.h | 1475
drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c | 157 +++
drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h | 26 +
drivers/gpu/drm/sprd/megacores_pll.c | 317 +
drivers/gpu/drm/sprd/megacores_pll.h | 146 +++
drivers/gpu/drm/sprd/sprd_drm.c|1 +
drivers/gpu/drm/sprd/sprd_drm.h|1 +
drivers/gpu/drm/sprd/sprd_dsi.c| 1132 ++
drivers/gpu/drm/sprd/sprd_dsi.h| 104 ++
11 files changed, 4158 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.c
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.h
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h
create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c
create mode 100644 drivers/gpu/drm/sprd/megacores_pll.h
create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.c
create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.h
diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
index 6c25bfa99..d49f4977b 100644
--- a/drivers/gpu/drm/sprd/Makefile
+++ b/drivers/gpu/drm/sprd/Makefile
@@ -1,5 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
obj-y := sprd_drm.o \
- sprd_dpu.o
-
+ sprd_dpu.o \
+ sprd_dsi.o \
+ dw_dsi_ctrl.o \
+ dw_dsi_ctrl_ppi.o \
+ megacores_pll.o
diff --git a/drivers/gpu/drm/sprd/dw_dsi_ctrl.c
b/drivers/gpu/drm/sprd/dw_dsi_ctrl.c
new file mode 100644
index 0..1034aba4a
--- /dev/null
+++ b/drivers/gpu/drm/sprd/dw_dsi_ctrl.c
@@ -0,0 +1,794 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Unisoc Inc.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "dw_dsi_ctrl.h"
+
+/*
+ * Modify power status of DSI Host core
+ */
+void dsi_power_enable(struct dsi_context *ctx, int enable)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ writel(enable, ®->SOFT_RESET);
+}
+/*
+ * Enable/disable DPI video mode
+ */
+void dsi_video_mode(struct dsi_context *ctx)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ writel(0, ®->DSI_MODE_CFG);
+}
+/*
+ * Enable command mode (Generic interface)
+ */
+void dsi_cmd_mode(struct dsi_context *ctx)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ writel(1, ®->DSI_MODE_CFG);
+}
+
+bool dsi_is_cmd_mode(struct dsi_context *ctx)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ return readl(®->DSI_MODE_CFG);
+}
+/*
+ * Configure the read back virtual channel for the generic interface
+ */
+void dsi_rx_vcid(struct dsi_context *ctx, u8 vc)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x1C virtual_channel_id;
+
+ virtual_channel_id.val = readl(®->VIRTUAL_CHANNEL_ID);
+ virtual_channel_id.bits.gen_rx_vcid = vc;
+
+ writel(virtual_channel_id.val, ®->VIRTUAL_CHANNEL_ID);
+}
+/*
+ * Write the DPI video virtual channel destination
+ */
+void dsi_video_vcid(struct dsi_context *ctx, u8 vc)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x1C virtual_channel_id;
+
+ virtual_channel_id.val = readl(®->VIRTUAL_CHANNEL_ID);
+ virtual_channel_id.bits.video_pkt_vcid = vc;
+
+ writel(virtual_channel_id.val, ®->VIRTUAL_CHANNEL_ID);
+}
+/*
+ * Set DPI video mode type (burst/non-burst - with sync pulses or events)
+ */
+void dsi_dpi_video_burst_mode(struct dsi_context *ctx, int mode)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x38 vid_mode_cfg;
+
+ vid_mode_cfg.val = readl(®->VID_MODE_CFG);
+ vid_mode_cfg.bits.vid_mode_type = mode;
+
+ writel(vid_mode_cfg.val, ®->VID_MODE_CFG);
+}
+/*
+ * Set DPI video color coding
+ */
+void dsi_dpi_color_coding(struct dsi_context *ctx, int coding)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x20 dpi_video_format;
+
+ dpi_video_format.val = readl(®->DPI_VIDEO_FORMAT);
+ dpi_video_format.bits.dpi_video_mode_format = coding;
+
+ writel(dpi_video_format.val, ®->DPI_VIDEO_FORMAT);
+}
+/*
+ * Configure the Horizontal Line time
+ * param "byte_cycle" taken to transmit the total of the horizontal line
+ */
+void dsi_dpi_hline_time(struct dsi_context *ctx, u16 byte_cycle)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
Re: [PATCH v2] drm/scheduler: Fix hang when sched_entity released
Ping
Andrey
On 2021-02-20 7:12 a.m., Andrey Grodzovsky wrote:
On 2/20/21 3:38 AM, Christian König wrote:
Am 18.02.21 um 17:41 schrieb Andrey Grodzovsky:
On 2/18/21 10:15 AM, Christian König wrote:
Am 18.02.21 um 16:05 schrieb Andrey Grodzovsky:
On 2/18/21 3:07 AM, Christian König wrote:
Am 17.02.21 um 22:59 schrieb Andrey Grodzovsky:
Problem: If scheduler is already stopped by the time sched_entity
is released and entity's job_queue not empty I encountred
a hang in drm_sched_entity_flush. This is because
drm_sched_entity_is_idle
never becomes false.
Fix: In drm_sched_fini detach all sched_entities from the
scheduler's run queues. This will satisfy drm_sched_entity_is_idle.
Also wakeup all those processes stuck in sched_entity flushing
as the scheduler main thread which wakes them up is stopped by now.
v2:
Reverse order of drm_sched_rq_remove_entity and marking
s_entity as stopped to prevent reinserion back to rq due
to race.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 31
+++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 908b0b5..c6b7947 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -897,9 +897,40 @@ EXPORT_SYMBOL(drm_sched_init);
*/
void drm_sched_fini(struct drm_gpu_scheduler *sched)
{
+ int i;
+ struct drm_sched_entity *s_entity;
BTW: Please order that so that i is declared last.
if (sched->thread)
kthread_stop(sched->thread);
+ /* Detach all sched_entites from this scheduler once it's
stopped */
+ for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >=
DRM_SCHED_PRIORITY_MIN; i--) {
+ struct drm_sched_rq *rq = &sched->sched_rq[i];
+
+ if (!rq)
+ continue;
+
+ /* Loop this way because rq->lock is taken in
drm_sched_rq_remove_entity */
+ spin_lock(&rq->lock);
+ while ((s_entity = list_first_entry_or_null(&rq->entities,
+ struct drm_sched_entity,
+ list))) {
+ spin_unlock(&rq->lock);
+
+ /* Prevent reinsertion and remove */
+ spin_lock(&s_entity->rq_lock);
+ s_entity->stopped = true;
+ drm_sched_rq_remove_entity(rq, s_entity);
+ spin_unlock(&s_entity->rq_lock);
Well this spin_unlock/lock dance here doesn't look correct at all
now.
Christian.
In what way ? It's in the same same order as in other call sites
(see drm_sched_entity_push_job and drm_sched_entity_flush).
If i just locked rq->lock and did list_for_each_entry_safe while
manually deleting entity->list instead of calling
drm_sched_rq_remove_entity this still would not be possible as the
order of lock acquisition between s_entity->rq_lock
and rq->lock would be reverse compared to the call sites mentioned
above.
Ah, now I understand. You need this because
drm_sched_rq_remove_entity() will grab the rq lock again!
Problem is now what prevents the entity from being destroyed while
you remove it?
Christian.
Right, well, since (unfortunately) sched_entity is part of
amdgpu_ctx_entity and amdgpu_ctx_entity is refcounted
there is a problem here that we don't increment amdgpu_ctx.refcount
when assigning sched_entity
to new rq (e.g. before drm_sched_rq_add_entity) and not decrement
before removing. We do it for
amdgpu_cs_parser.entity for example (in amdgpu_cs_parser_init and
amdgpu_cs_parser_fini by
calling amdgpu_ctx_get and amdgpu_ctx_put). But this seems a bit
tricky due to all the drm_sched_entity_select_rq
logic.
Another, kind of a band aid fix, would probably be just locking
amdgpu_ctx_mgr.lock around drm_sched_fini
when finalizing the fence driver and around idr iteration in
amdgpu_ctx_mgr_fini (which should be lock protected
anyway as I see from other idr usages in the code) ... This should
prevent this use after free.
Puh, that's rather complicated as well. Ok let's look at it from the
other side for a moment.
Why do we have to remove the entities from the rq in the first place?
Wouldn't it be sufficient to just set all of them to stopped?
Christian.
And adding it as another condition in drm_sched_entity_is_idle ?
Andrey
Andrey
Andrey
+
+ spin_lock(&rq->lock);
+ }
+ spin_unlock(&rq->lock);
+
+ }
+
+ /* Wakeup everyone stuck in drm_sched_entity_flush for this
scheduler */
+ wake_up_all(&sched->job_scheduled);
+
/* Confirm no work left behind accessing device structures */
cancel_delayed_work_sync(&sched->work_tdr);
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Candrey.grodzovsky%40amd.com%7Cd948a126eeb84abf3e1308d8d598ca2f%7C3
Re: [PATCH v2 1/3] drm: Support importing dmabufs into drivers without DMA
On Mon, Feb 22, 2021 at 01:43:26PM +0100, Thomas Zimmermann wrote: ... > > [ 60.050199] [ cut here ] > [ 60.055092] WARNING: CPU: 0 PID: 1403 at kernel/dma/mapping.c:190 > dma_map_sg_attrs+0x8f/0xc0 > [ 60.064331] Modules linked in: af_packet(E) rfkill(E) dmi_sysfs(E) > intel_rapl_msr(E) intel_rapl_common(E) snd_hda_codec_realtek(E) > snd_hda_codec_generic(E) ledtrig_audio(E) snd_hda_codec_hdmi(E) > x86_pkg_temp_thermal(E) intel_powerclam) > [ 60.064801] wmi(E) video(E) btrfs(E) blake2b_generic(E) libcrc32c(E) > crc32c_intel(E) xor(E) raid6_pq(E) sg(E) dm_multipath(E) dm_mod(E) > scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) msr(E) efivarfs(E) > [ 60.170778] CPU: 0 PID: 1403 Comm: Xorg.bin Tainted: GE > 5.11.0-rc5-1-default+ #747 > [ 60.179841] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24 > 10/24/2018 > [ 60.187145] RIP: 0010:dma_map_sg_attrs+0x8f/0xc0 > [ 60.191822] Code: 4d 85 ff 75 2b 49 89 d8 44 89 e1 44 89 f2 4c 89 ee 48 89 > ef e8 62 30 00 00 85 c0 78 36 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 0b <0f> 0b > 31 c0 eb ed 49 8d 7f 50 e8 72 f5 2a 00 49 8b 47 50 49 89 d8 > [ 60.210770] RSP: 0018:c90001d6fc18 EFLAGS: 00010246 > [ 60.216062] RAX: RBX: 0020 RCX: > b31e677b > [ 60.223274] RDX: dc00 RSI: 888212c10600 RDI: > 8881b08a9488 > [ 60.230501] RBP: 8881b08a9030 R08: 0020 R09: > 888212c10600 > [ 60.237710] R10: ed10425820df R11: 0001 R12: > > [ 60.244939] R13: 888212c10600 R14: 0008 R15: > > [ 60.252155] FS: 7f08ac2b2f00() GS:8887cbe0() > knlGS: > [ 60.260333] CS: 0010 DS: ES: CR0: 80050033 > [ 60.266150] CR2: 55831c899be8 CR3: 00015372e006 CR4: > 001706f0 > [ 60.273369] Call Trace: > [ 60.275845] drm_gem_map_dma_buf+0xb4/0x120 > [ 60.280089] dma_buf_map_attachment+0x15d/0x1e0 > [ 60.284688] drm_gem_prime_import_dev.part.0+0x5d/0x140 > [ 60.289984] drm_gem_prime_fd_to_handle+0x213/0x280 > [ 60.294931] ? drm_prime_destroy_file_private+0x30/0x30 > [ 60.300224] drm_ioctl_kernel+0x131/0x180 > [ 60.304291] ? drm_setversion+0x230/0x230 > [ 60.308366] ? drm_prime_destroy_file_private+0x30/0x30 > [ 60.313659] drm_ioctl+0x2f1/0x500 > [ 60.317118] ? drm_version+0x150/0x150 > [ 60.320903] ? lock_downgrade+0xa0/0xa0 > [ 60.324806] ? do_vfs_ioctl+0x5f4/0x680 > [ 60.328694] ? __fget_files+0x13e/0x210 > [ 60.332591] ? ioctl_fiemap.isra.0+0x1a0/0x1a0 > [ 60.337102] ? __fget_files+0x15d/0x210 > [ 60.340990] __x64_sys_ioctl+0xb9/0xf0 > [ 60.344795] do_syscall_64+0x33/0x80 > [ 60.348427] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 60.353542] RIP: 0033:0x7f08ac7b53cb > [ 60.357168] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff ff ff > 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 8b 0d 75 ba 0c 00 f7 d8 64 89 01 48 > [ 60.376108] RSP: 002b:7ffeabc89fc8 EFLAGS: 0246 ORIG_RAX: > 0010 > [ 60.383758] RAX: ffda RBX: 7ffeabc8a00c RCX: > 7f08ac7b53cb > [ 60.390970] RDX: 7ffeabc8a00c RSI: c00c642e RDI: > 000d > [ 60.398221] RBP: c00c642e R08: 55831c691d00 R09: > 55831b2ec010 > [ 60.405446] R10: 7f08acf6ada0 R11: 0246 R12: > 55831c691d00 > [ 60.412667] R13: 000d R14: 007e9000 R15: > > [ 60.419903] irq event stamp: 672893 > [ 60.423441] hardirqs last enabled at (672913): [] > console_unlock+0x44d/0x500 > [ 60.432230] hardirqs last disabled at (672922): [] > console_unlock+0x443/0x500 > [ 60.441021] softirqs last enabled at (672940): [] > __do_softirq+0x3dd/0x554 > [ 60.449634] softirqs last disabled at (672931): [] > asm_call_irq_on_stack+0x12/0x20 > [ 60.458871] ---[ end trace f2f88696eb17806c ]--- > Copy-pasting the etnire stack trace to the commit log really hurts readability and provides no additional value to the reader, IMHO. > This patch introduces struct drm_driver.gem_prime_create_object, which ^ Documentation/process/submitting-patches.rst: Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behaviour. > Cc: Christoph Hellwig > Cc: Greg Kroah-Hartman > Cc: Alan Stern > Cc: Johan Hovold > Cc: Andy Shevchenko > Cc: Sebastian Andrzej Siewior > Cc: Mathias Nyman > Cc: "Ahmed S. Darwish" > Cc: Oliver Neukum > Cc: Thomas Gleixner > Cc: Felipe Balbi That's a *huge* Cc list, and a most of it seems to be generated by "scripts/get_maintainer.pl --git", which can be overly verbose. Thanks, -- Ahmed S. Darwish
[PATCH v3] drm/gem: Move drm_gem_fb_prepare_fb() to GEM atomic helpers
The function drm_gem_fb_prepare_fb() is a helper for atomic modesetting,
but currently located next to framebuffer helpers. Move it to GEM atomic
helpers, rename it slightly and adopt the drivers. Same for the rsp
simple-pipe helper.
Compile-tested with x86-64, aarch64 and arm. The patch is fairly large,
but there are no functional changes.
v3:
* remove out-comented line in drm_gem_framebuffer_helper.h
(Maxime)
v2:
* rename to drm_gem_plane_helper_prepare_fb() (Daniel)
* add tutorial-style documentation
Signed-off-by: Thomas Zimmermann
Acked-by: Maxime Ripard
---
drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 4 +-
drivers/gpu/drm/drm_gem_atomic_helper.c | 96 +++-
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 63 -
drivers/gpu/drm/drm_gem_vram_helper.c| 4 +-
drivers/gpu/drm/imx/dcss/dcss-plane.c| 4 +-
drivers/gpu/drm/imx/ipuv3-plane.c| 4 +-
drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 3 +-
drivers/gpu/drm/ingenic/ingenic-ipu.c| 4 +-
drivers/gpu/drm/mcde/mcde_display.c | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 6 +-
drivers/gpu/drm/meson/meson_overlay.c| 8 +-
drivers/gpu/drm/meson/meson_plane.c | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 4 +-
drivers/gpu/drm/msm/msm_atomic.c | 4 +-
drivers/gpu/drm/mxsfb/mxsfb_kms.c| 6 +-
drivers/gpu/drm/pl111/pl111_display.c| 4 +-
drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 4 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +-
drivers/gpu/drm/stm/ltdc.c | 4 +-
drivers/gpu/drm/sun4i/sun4i_layer.c | 4 +-
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 4 +-
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 4 +-
drivers/gpu/drm/tegra/plane.c| 4 +-
drivers/gpu/drm/tidss/tidss_plane.c | 4 +-
drivers/gpu/drm/tiny/hx8357d.c | 4 +-
drivers/gpu/drm/tiny/ili9225.c | 4 +-
drivers/gpu/drm/tiny/ili9341.c | 4 +-
drivers/gpu/drm/tiny/ili9486.c | 4 +-
drivers/gpu/drm/tiny/mi0283qt.c | 4 +-
drivers/gpu/drm/tiny/repaper.c | 3 +-
drivers/gpu/drm/tiny/st7586.c| 4 +-
drivers/gpu/drm/tiny/st7735r.c | 4 +-
drivers/gpu/drm/tve200/tve200_display.c | 4 +-
drivers/gpu/drm/vc4/vc4_plane.c | 4 +-
drivers/gpu/drm/vkms/vkms_plane.c| 3 +-
drivers/gpu/drm/xen/xen_drm_front_kms.c | 3 +-
include/drm/drm_gem_atomic_helper.h | 8 ++
include/drm/drm_gem_framebuffer_helper.h | 7 --
include/drm/drm_modeset_helper_vtables.h | 2 +-
include/drm/drm_plane.h | 4 +-
include/drm/drm_simple_kms_helper.h | 2 +-
41 files changed, 176 insertions(+), 145 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
index 20c2197b270f..098f96d4d50d 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
@@ -9,8 +9,8 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
#include
@@ -220,7 +220,7 @@ static const struct drm_simple_display_pipe_funcs
aspeed_gfx_funcs = {
.enable = aspeed_gfx_pipe_enable,
.disable= aspeed_gfx_pipe_disable,
.update = aspeed_gfx_pipe_update,
- .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
+ .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
.enable_vblank = aspeed_gfx_enable_vblank,
.disable_vblank = aspeed_gfx_disable_vblank,
};
diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c
b/drivers/gpu/drm/drm_gem_atomic_helper.c
index fa4eae492b81..a005c5a0ba46 100644
--- a/drivers/gpu/drm/drm_gem_atomic_helper.c
+++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
@@ -1,6 +1,10 @@
// SPDX-License-Identifier: GPL-2.0-or-later
+#include
+
#include
+#include
+#include
#include
#include
#include
@@ -12,8 +16,33 @@
*
* The GEM atomic helpers library implements generic atomic-commit
* functions for drivers that use GEM objects. Currently, it provides
- * plane state and framebuffer BO mappings for planes with shadow
- * buffers.
+ * synchronization helpers, and plane state and framebuffer BO mappings
+ * for planes with shadow buffers.
+ *
+ * Before scanout, a plane's framebuffer needs to be synchronized with
+ * possible writers that draw into the framebuffer. All drivers should
+ * call drm_gem_plane_helper_prepare_fb() from their implementation of
+ * struct &drm_plane_helper.prepare_fb . It sets the plane's fence from
+ * the framebuffer so that the DRM core can synchronize access automatically.
+ *
+ * drm_gem_plane_helper_prepare_fb() can also be used directly as
+ * implementation of prepare_fb. For drivers based on
+ * struct drm_simple_display_pipe, d
Re: [PATCH] drivers: gnu: drm: i915: gvt: Fixed couple of spellings in the file gtt.c
On 2/22/21 12:18 AM, Bhaskar Chowdhury wrote: > > s/negtive/negative/ > s/possilbe/possible/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/i915/gvt/gtt.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c > index 897c007ea96a..dc5834bf4de2 100644 > --- a/drivers/gpu/drm/i915/gvt/gtt.c > +++ b/drivers/gpu/drm/i915/gvt/gtt.c > @@ -1159,8 +1159,8 @@ static inline void ppgtt_generate_shadow_entry(struct > intel_gvt_gtt_entry *se, > * @vgpu: target vgpu > * @entry: target pfn's gtt entry > * > - * Return 1 if 2MB huge gtt shadowing is possilbe, 0 if miscondition, > - * negtive if found err. > + * Return 1 if 2MB huge gtt shadowing is possible, 0 if miscondition, > + * negative if found err. > */ > static int is_2MB_gtt_possible(struct intel_vgpu *vgpu, > struct intel_gvt_gtt_entry *entry) > -- -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers: gnu: drm: i915: gvt: Fixed couple of spellings in the file gtt.c
On 2/22/21 6:21 AM, Randy Dunlap wrote: > On 2/22/21 12:18 AM, Bhaskar Chowdhury wrote: >> >> s/negtive/negative/ >> s/possilbe/possible/ >> >> Signed-off-by: Bhaskar Chowdhury > > Acked-by: Randy Dunlap except the Subject has a typo in it. s/gnu/gpu/ >> --- >> drivers/gpu/drm/i915/gvt/gtt.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c >> index 897c007ea96a..dc5834bf4de2 100644 >> --- a/drivers/gpu/drm/i915/gvt/gtt.c >> +++ b/drivers/gpu/drm/i915/gvt/gtt.c >> @@ -1159,8 +1159,8 @@ static inline void ppgtt_generate_shadow_entry(struct >> intel_gvt_gtt_entry *se, >> * @vgpu: target vgpu >> * @entry: target pfn's gtt entry >> * >> - * Return 1 if 2MB huge gtt shadowing is possilbe, 0 if miscondition, >> - * negtive if found err. >> + * Return 1 if 2MB huge gtt shadowing is possible, 0 if miscondition, >> + * negative if found err. >> */ >> static int is_2MB_gtt_possible(struct intel_vgpu *vgpu, >> struct intel_gvt_gtt_entry *entry) >> -- > > -- ~Randy Reported-by: Randy Dunlap ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff
Hi
Am 17.02.21 um 17:59 schrieb Neil Roberts:
When mmapping the shmem, it would previously adjust the pgoff in the
vm_area_struct to remove the fake offset that is added to be able to
identify the buffer. This patch removes the adjustment and makes the
fault handler use the vm_fault address to calculate the page offset
instead. Although using this address is apparently discouraged, several
DRM drivers seem to be doing it anyway.
The problem with removing the pgoff is that it prevents
drm_vma_node_unmap from working because that searches the mapping tree
by address. That doesn't work because all of the mappings are at offset
0. drm_vma_node_unmap is being used by the shmem helpers when purging
the buffer.
I just want to ask if this is how the mmap callbacks are supposed to
work now?
I have a number of patches in here that convert several drivers to the
GEM object's mmap callback. They might not be affected by the vm_pgoff
bug, but I'd like to submit something that could work in the longer term.
Best regards
Thomas
It looks like panfrost is using drm_gem_shmem_purge so this might fix a
potential bug there.
Signed-off-by: Neil Roberts
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 9825c378dfa6..4b14157f1962 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -526,11 +526,16 @@ static vm_fault_t drm_gem_shmem_fault(struct vm_fault
*vmf)
struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
loff_t num_pages = obj->size >> PAGE_SHIFT;
struct page *page;
+ pgoff_t page_offset;
- if (vmf->pgoff >= num_pages || WARN_ON_ONCE(!shmem->pages))
+ /* We don't use vmf->pgoff since that has the fake offset */
+ page_offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
+
+ if (page_offset < 0 || page_offset >= num_pages ||
+ WARN_ON_ONCE(!shmem->pages))
return VM_FAULT_SIGBUS;
- page = shmem->pages[vmf->pgoff];
+ page = shmem->pages[page_offset];
return vmf_insert_page(vma, vmf->address, page);
}
@@ -581,9 +586,6 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
struct drm_gem_shmem_object *shmem;
int ret;
- /* Remove the fake offset */
- vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
-
if (obj->import_attach) {
/* Drop the reference drm_gem_mmap_obj() acquired.*/
drm_gem_object_put(obj);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/20] Manual replacement of all strlcpy in favor of strscpy
strlcpy() copy a C-String into a sized buffer, the result is always a valid NULL-terminated that fits in the buffer, howerver it has severals issues. It reads the source buffer first, which is dangerous if it is non NULL-terminated or if the corresponding buffer is unbounded. Its safe replacement is strscpy(), as suggested in the deprecated interface [1]. We plan to make this contribution in two steps: - Firsly all cases of strlcpy's return value are manually replaced by the corresponding calls of strscpy() with the new handling of the return value (as the return code is different in case of error). - Then all other cases are automatically replaced by using coccinelle. This series covers manual replacements. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy Romain Perier (20): cgroup: Manual replacement of the deprecated strlcpy() with return values crypto: Manual replacement of the deprecated strlcpy() with return values devlink: Manual replacement of the deprecated strlcpy() with return values dma-buf: Manual replacement of the deprecated strlcpy() with return values kobject: Manual replacement of the deprecated strlcpy() with return values ima: Manual replacement of the deprecated strlcpy() with return values SUNRPC: Manual replacement of the deprecated strlcpy() with return values kernfs: Manual replacement of the deprecated strlcpy() with return values m68k/atari: Manual replacement of the deprecated strlcpy() with return values module: Manual replacement of the deprecated strlcpy() with return values hwmon: Manual replacement of the deprecated strlcpy() with return values s390/hmcdrv: Manual replacement of the deprecated strlcpy() with return values scsi: zfcp: Manual replacement of the deprecated strlcpy() with return values target: Manual replacement of the deprecated strlcpy() with return values ALSA: usb-audio: Manual replacement of the deprecated strlcpy() with return values tracing/probe: Manual replacement of the deprecated strlcpy() with return values vt: Manual replacement of the deprecated strlcpy() with return values usb: gadget: f_midi: Manual replacement of the deprecated strlcpy() with return values usbip: usbip_host: Manual replacement of the deprecated strlcpy() with return values s390/watchdog: Manual replacement of the deprecated strlcpy() with return values arch/m68k/emu/natfeat.c | 6 +-- crypto/lrw.c| 6 +-- crypto/xts.c| 6 +-- drivers/dma-buf/dma-buf.c | 4 +- drivers/hwmon/pmbus/max20730.c | 66 + drivers/s390/char/diag_ftp.c| 4 +- drivers/s390/char/sclp_ftp.c| 6 +-- drivers/s390/scsi/zfcp_fc.c | 8 +-- drivers/target/target_core_configfs.c | 33 - drivers/tty/vt/keyboard.c | 5 +- drivers/usb/gadget/function/f_midi.c| 4 +- drivers/usb/gadget/function/f_printer.c | 8 +-- drivers/usb/usbip/stub_main.c | 6 +-- drivers/watchdog/diag288_wdt.c | 12 +++-- fs/kernfs/dir.c | 27 +- kernel/cgroup/cgroup.c | 2 +- kernel/module.c | 4 +- kernel/trace/trace_uprobe.c | 11 ++--- lib/kobject_uevent.c| 6 +-- net/core/devlink.c | 6 +-- net/sunrpc/clnt.c | 6 ++- security/integrity/ima/ima_policy.c | 8 ++- sound/usb/card.c| 4 +- 23 files changed, 129 insertions(+), 119 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/20] dma-buf: Manual replacement of the deprecated strlcpy() with return values
The strlcpy() reads the entire source buffer first, it is dangerous if
the source buffer lenght is unbounded or possibility non NULL-terminated.
It can lead to linear read overflows, crashes, etc...
As recommended in the deprecated interfaces [1], it should be replaced
by strscpy.
This commit replaces all calls to strlcpy that handle the return values
by the corresponding strscpy calls with new handling of the return
values (as it is quite different between the two functions).
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
Signed-off-by: Romain Perier
---
drivers/dma-buf/dma-buf.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..515192f2f404 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -42,12 +42,12 @@ static char *dmabuffs_dname(struct dentry *dentry, char
*buffer, int buflen)
{
struct dma_buf *dmabuf;
char name[DMA_BUF_NAME_LEN];
- size_t ret = 0;
+ ssize_t ret = 0;
dmabuf = dentry->d_fsdata;
spin_lock(&dmabuf->name_lock);
if (dmabuf->name)
- ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
+ ret = strscpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
spin_unlock(&dmabuf->name_lock);
return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/a6xx: fix for kernels without CONFIG_NVMEM
On 2/19/2021 9:30 PM, Rob Clark wrote:
On Fri, Feb 19, 2021 at 2:44 AM Akhil P Oommen wrote:
On 2/18/2021 9:41 PM, Rob Clark wrote:
On Thu, Feb 18, 2021 at 4:28 AM Akhil P Oommen wrote:
On 2/18/2021 2:05 AM, Jonathan Marek wrote:
On 2/17/21 3:18 PM, Rob Clark wrote:
On Wed, Feb 17, 2021 at 11:08 AM Jordan Crouse
wrote:
On Wed, Feb 17, 2021 at 07:14:16PM +0530, Akhil P Oommen wrote:
On 2/17/2021 8:36 AM, Rob Clark wrote:
On Tue, Feb 16, 2021 at 12:10 PM Jonathan Marek
wrote:
Ignore nvmem_cell_get() EOPNOTSUPP error in the same way as a
ENOENT error,
to fix the case where the kernel was compiled without CONFIG_NVMEM.
Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618 gpu")
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ba8e9d3cf0fe..7fe5d97606aa 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1356,10 +1356,10 @@ static int a6xx_set_supported_hw(struct
device *dev, struct a6xx_gpu *a6xx_gpu,
cell = nvmem_cell_get(dev, "speed_bin");
/*
-* -ENOENT means that the platform doesn't support
speedbin which is
-* fine
+* -ENOENT means no speed bin in device tree,
+* -EOPNOTSUPP means kernel was built without CONFIG_NVMEM
very minor nit, it would be nice to at least preserve the gist of the
"which is fine" (ie. some variation of "this is an optional thing and
things won't catch fire without it" ;-))
(which is, I believe, is true, hopefully Akhil could confirm.. if not
we should have a harder dependency on CONFIG_NVMEM..)
IIRC, if the gpu opp table in the DT uses the 'opp-supported-hw'
property,
we will see some error during boot up if we don't call
dev_pm_opp_set_supported_hw(). So calling "nvmem_cell_get(dev,
"speed_bin")"
is a way to test this.
If there is no other harm, we can put a hard dependency on
CONFIG_NVMEM.
I'm not sure if we want to go this far given the squishiness about
module
dependencies. As far as I know we are the only driver that uses this
seriously
on QCOM SoCs and this is only needed for certain targets. I don't
know if we
want to force every target to build NVMEM and QFPROM on our behalf.
But maybe
I'm just saying that because Kconfig dependencies tend to break my
brain (and
then Arnd has to send a patch to fix it).
Hmm, good point.. looks like CONFIG_NVMEM itself doesn't have any
other dependencies, so I suppose it wouldn't be the end of the world
to select that.. but I guess we don't want to require QFPROM
I guess at the end of the day, what is the failure mode if you have a
speed-bin device, but your kernel config misses QFPROM (and possibly
NVMEM)? If the result is just not having the highest clk rate(s)
Atleast on sc7180's gpu, using an unsupported FMAX breaks gmu. It won't
be very obvious what went wrong when this happens!
Ugg, ok..
I suppose we could select NVMEM, but not QFPROM, and then the case
where QFPROM is not enabled on platforms that have the speed-bin field
in DT will fail gracefully and all other platforms would continue on
happily?
BR,
-R
Sounds good to me.
You probably should do a quick test with NVMEM enabled but QFPROM
disabled to confirm my theory, but I *think* that should work
BR,
-R
I tried it on an sc7180 device. The suggested combo (CONFIG_NVMEM + no
CONFIG_QCOM_QFPROM) makes the gpu probe fail with error "failed to read
speed-bin. Some OPPs may not be supported by hardware". This is good
enough clue for the developer that he should fix the broken speedbin
detection.
-Akhil.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/a6xx: fix for kernels without CONFIG_NVMEM
On Mon, Feb 22, 2021 at 7:45 AM Akhil P Oommen wrote:
>
> On 2/19/2021 9:30 PM, Rob Clark wrote:
> > On Fri, Feb 19, 2021 at 2:44 AM Akhil P Oommen
> > wrote:
> >>
> >> On 2/18/2021 9:41 PM, Rob Clark wrote:
> >>> On Thu, Feb 18, 2021 at 4:28 AM Akhil P Oommen
> >>> wrote:
>
> On 2/18/2021 2:05 AM, Jonathan Marek wrote:
> > On 2/17/21 3:18 PM, Rob Clark wrote:
> >> On Wed, Feb 17, 2021 at 11:08 AM Jordan Crouse
> >> wrote:
> >>>
> >>> On Wed, Feb 17, 2021 at 07:14:16PM +0530, Akhil P Oommen wrote:
> On 2/17/2021 8:36 AM, Rob Clark wrote:
> > On Tue, Feb 16, 2021 at 12:10 PM Jonathan Marek
> > wrote:
> >>
> >> Ignore nvmem_cell_get() EOPNOTSUPP error in the same way as a
> >> ENOENT error,
> >> to fix the case where the kernel was compiled without CONFIG_NVMEM.
> >>
> >> Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618 gpu")
> >> Signed-off-by: Jonathan Marek
> >> ---
> >> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++---
> >> 1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >> index ba8e9d3cf0fe..7fe5d97606aa 100644
> >> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> >> @@ -1356,10 +1356,10 @@ static int a6xx_set_supported_hw(struct
> >> device *dev, struct a6xx_gpu *a6xx_gpu,
> >>
> >>cell = nvmem_cell_get(dev, "speed_bin");
> >>/*
> >> -* -ENOENT means that the platform doesn't support
> >> speedbin which is
> >> -* fine
> >> +* -ENOENT means no speed bin in device tree,
> >> +* -EOPNOTSUPP means kernel was built without CONFIG_NVMEM
> >
> > very minor nit, it would be nice to at least preserve the gist of
> > the
> > "which is fine" (ie. some variation of "this is an optional thing
> > and
> > things won't catch fire without it" ;-))
> >
> > (which is, I believe, is true, hopefully Akhil could confirm.. if
> > not
> > we should have a harder dependency on CONFIG_NVMEM..)
> IIRC, if the gpu opp table in the DT uses the 'opp-supported-hw'
> property,
> we will see some error during boot up if we don't call
> dev_pm_opp_set_supported_hw(). So calling "nvmem_cell_get(dev,
> "speed_bin")"
> is a way to test this.
>
> If there is no other harm, we can put a hard dependency on
> CONFIG_NVMEM.
> >>>
> >>> I'm not sure if we want to go this far given the squishiness about
> >>> module
> >>> dependencies. As far as I know we are the only driver that uses this
> >>> seriously
> >>> on QCOM SoCs and this is only needed for certain targets. I don't
> >>> know if we
> >>> want to force every target to build NVMEM and QFPROM on our behalf.
> >>> But maybe
> >>> I'm just saying that because Kconfig dependencies tend to break my
> >>> brain (and
> >>> then Arnd has to send a patch to fix it).
> >>>
> >>
> >> Hmm, good point.. looks like CONFIG_NVMEM itself doesn't have any
> >> other dependencies, so I suppose it wouldn't be the end of the world
> >> to select that.. but I guess we don't want to require QFPROM
> >>
> >> I guess at the end of the day, what is the failure mode if you have a
> >> speed-bin device, but your kernel config misses QFPROM (and possibly
> >> NVMEM)? If the result is just not having the highest clk rate(s)
>
> Atleast on sc7180's gpu, using an unsupported FMAX breaks gmu. It won't
> be very obvious what went wrong when this happens!
> >>>
> >>> Ugg, ok..
> >>>
> >>> I suppose we could select NVMEM, but not QFPROM, and then the case
> >>> where QFPROM is not enabled on platforms that have the speed-bin field
> >>> in DT will fail gracefully and all other platforms would continue on
> >>> happily?
> >>>
> >>> BR,
> >>> -R
> >>
> >> Sounds good to me.
> >>
> >
> > You probably should do a quick test with NVMEM enabled but QFPROM
> > disabled to confirm my theory, but I *think* that should work
> >
> > BR,
> > -R
> >
>
> I tried it on an sc7180 device. The suggested combo (CONFIG_NVMEM + no
> CONFIG_QCOM_QFPROM) makes the gpu probe fail with error "failed to read
> speed-bin. Some OPPs may not be supported by hardware". This is good
> enough clue for the developer that he should fix the broken speedbin
> detection.
>
Ok, great.. then sounds like selecting NVMEM is a good approach
BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v4] drm/msm/disp/dpu1: turn off vblank irqs aggressively in dpu driver
On Thu, Feb 18, 2021 at 4:36 AM Kalyan Thota wrote:
>
> Set the flag vblank_disable_immediate = true to turn off vblank irqs
> immediately as soon as drm_vblank_put is requested so that there are
> no irqs triggered during idle state. This will reduce cpu wakeups
> and help in power saving.
>
> To enable vblank_disable_immediate flag the underlying KMS driver
> needs to support high precision vblank timestamping and also a
> reliable way of providing vblank counter which is incrementing
> at the leading edge of vblank.
>
> This patch also brings in changes to support vblank_disable_immediate
> requirement in dpu driver.
>
> Changes in v1:
> - Specify reason to add vblank timestamp support. (Rob).
> - Add changes to provide vblank counter from dpu driver.
>
> Changes in v2:
> - Fix warn stack reported by Rob Clark with v2 patch.
>
> Changes in v3:
> - Move back to HW frame counter (Rob).
>
could you let me know what the delta was in v4? (No need to resend
yet, if needed I can amend the commit msg when applying)
BR,
-R
> Signed-off-by: Kalyan Thota
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 80
> ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 30
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h| 11 +++
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 1 +
> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 26 +++
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h| 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 5 ++
> 8 files changed, 155 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index d4662e8..9a80981 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -65,6 +65,83 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
> kfree(dpu_crtc);
> }
>
> +static struct drm_encoder *get_encoder_from_crtc(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_encoder *encoder;
> +
> + drm_for_each_encoder(encoder, dev)
> + if (encoder->crtc == crtc)
> + return encoder;
> +
> + return NULL;
> +}
> +
> +static u32 dpu_crtc_get_vblank_counter(struct drm_crtc *crtc)
> +{
> + struct drm_encoder *encoder;
> +
> + encoder = get_encoder_from_crtc(crtc);
> + if (!encoder) {
> + DRM_ERROR("no encoder found for crtc %d\n", crtc->index);
> + return false;
> + }
> +
> + return dpu_encoder_get_frame_count(encoder);
> +}
> +
> +static bool dpu_crtc_get_scanout_position(struct drm_crtc *crtc,
> + bool in_vblank_irq,
> + int *vpos, int *hpos,
> + ktime_t *stime, ktime_t *etime,
> + const struct drm_display_mode
> *mode)
> +{
> + unsigned int pipe = crtc->index;
> + struct drm_encoder *encoder;
> + int line, vsw, vbp, vactive_start, vactive_end, vfp_end;
> +
> + encoder = get_encoder_from_crtc(crtc);
> + if (!encoder) {
> + DRM_ERROR("no encoder found for crtc %d\n", pipe);
> + return false;
> + }
> +
> + vsw = mode->crtc_vsync_end - mode->crtc_vsync_start;
> + vbp = mode->crtc_vtotal - mode->crtc_vsync_end;
> +
> + /*
> +* the line counter is 1 at the start of the VSYNC pulse and VTOTAL at
> +* the end of VFP. Translate the porch values relative to the line
> +* counter positions.
> +*/
> +
> + vactive_start = vsw + vbp + 1;
> + vactive_end = vactive_start + mode->crtc_vdisplay;
> +
> + /* last scan line before VSYNC */
> + vfp_end = mode->crtc_vtotal;
> +
> + if (stime)
> + *stime = ktime_get();
> +
> + line = dpu_encoder_get_linecount(encoder);
> +
> + if (line < vactive_start)
> + line -= vactive_start;
> + else if (line > vactive_end)
> + line = line - vfp_end - vactive_start;
> + else
> + line -= vactive_start;
> +
> + *vpos = line;
> + *hpos = 0;
> +
> + if (etime)
> + *etime = ktime_get();
> +
> + return true;
> +}
> +
> static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer,
> struct dpu_plane_state *pstate, struct dpu_format *format)
> {
> @@ -1243,6 +1320,8 @@ static const struct drm_crtc_funcs dpu_crtc_funcs = {
> .early_unregister = dpu_crtc_early_unregister,
> .enable_vblank = msm_crtc_enable_vblank,
> .disable_vblank = msm_crtc_disable_vblank,
> + .get_vblank_timestamp = drm_crtc_vblank_helper_get_vblank_timestamp,
> + .get_vblank_counter = dpu_crtc_get_vblank_counter,
> };
>
> sta
Re: [PATCH v2 0/3] drm/prime: Only call dma_map_sgtable() for devices with DMA support
On Mon, Feb 22, 2021 at 2:24 PM Thomas Zimmermann wrote: > > Hi > > Am 22.02.21 um 14:09 schrieb Christian König: > > > > > > Am 22.02.21 um 13:43 schrieb Thomas Zimmermann: > >> USB-based drivers cannot use DMA, so the importing of dma-buf attachments > >> currently fails for udl and gm12u320. This breaks joining/mirroring of > >> displays. > >> > >> The fix is now a little series. To solve the issue on the importer > >> side (i.e., the affected USB-based driver), patch 1 introduces a new > >> PRIME callback, struct drm_driver.gem_prime_create_object, which creates > >> an object and gives more control to the importing driver. Specifically, > >> udl and gm12u320 can now avoid the creation of a scatter/gather table > >> for the imported pages. Patch 1 is self-contained in the sense that it > >> can be backported into older kernels. > > > > Mhm, that sounds like a little overkill to me. > > > > Drivers can already import the DMA-bufs all by them selves without the > > help of the DRM functions. See amdgpu for an example. > > > > Daniel also already noted to me that he sees the DRM helper as a bit > > questionable middle layer. > > And this bug proves that it is. :) The trouble here is actually gem_bo->import_attach, which isn't really part of the questionable midlayer, but fairly mandatory (only exception is vmwgfx because not using gem) caching to make sure we don't end up with duped imports and fun stuff like that. And dma_buf_attach now implicitly creates the sg table already, so we're already in game over land. I think we'd need to make import_attach a union with import_buf or something like that, so that you can do attachment-less importing. > > Have you thought about doing that instead? > > There appears to be some useful code in drm_gem_prime_import_dev(). But > if the general sentiment goes towards removing > gem_prime_import_sg_table, we can work towards that as well. I still think this part is a bit a silly midlayer for no good reason, but I think that's orthogonal to the issue at hand here. I'd suggest we first try to paper over the issue by using prime_import_dev with the host controller (which hopefully is dma-capable for most systems). And then, at leisure, try to untangle the obj->import_attach issue. -Daniel > > Best regards > Thomas > > > > > Christian. > > > >> > >> Patches 2 and 3 update SHMEM and CMA helpers to use the new callback. > >> Effectively this moves the sg table setup from the PRIME helpers into > >> the memory managers. SHMEM now supports devices without DMA support, > >> so custom code can be removed from udl and g12u320. > >> > >> Tested by joining/mirroring displays of udl and radeon under Gnome/X11. > >> > >> v2: > >> * move fix to importer side (Christian, Daniel) > >> * update SHMEM and CMA helpers for new PRIME callbacks > >> > >> Thomas Zimmermann (3): > >>drm: Support importing dmabufs into drivers without DMA > >>drm/shmem-helper: Implement struct drm_driver.gem_prime_create_object > >>drm/cma-helper: Implement struct drm_driver.gem_prime_create_object > >> > >> drivers/gpu/drm/drm_gem_cma_helper.c| 62 ++--- > >> drivers/gpu/drm/drm_gem_shmem_helper.c | 38 ++- > >> drivers/gpu/drm/drm_prime.c | 43 +++-- > >> drivers/gpu/drm/lima/lima_drv.c | 2 +- > >> drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- > >> drivers/gpu/drm/panfrost/panfrost_gem.c | 6 +-- > >> drivers/gpu/drm/panfrost/panfrost_gem.h | 4 +- > >> drivers/gpu/drm/pl111/pl111_drv.c | 8 ++-- > >> drivers/gpu/drm/v3d/v3d_bo.c| 6 +-- > >> drivers/gpu/drm/v3d/v3d_drv.c | 2 +- > >> drivers/gpu/drm/v3d/v3d_drv.h | 5 +- > >> include/drm/drm_drv.h | 12 + > >> include/drm/drm_gem_cma_helper.h| 12 ++--- > >> include/drm/drm_gem_shmem_helper.h | 6 +-- > >> 14 files changed, 120 insertions(+), 88 deletions(-) > >> > >> -- > >> 2.30.1 > >> > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: panel: simple: Set enable delay for BOE NV110WTM-N61
Panel power sequence says timing T8 (time from link idle to turn on
the backlight) should be at least 50 ms. This is what the .enable
delay in simple-panel is for, so set it. NOTE: this overlaps with the
80 ms .prepare_to_enable delay on purpose. The data sheet says that
at least 80 ms needs to pass between HPD going high and turning on the
backlight and that at least 50 ms needs to pass between the link idle
and the backlight going on. Thus it works like this on the system in
front of me:
* In bridge chip pre_enable call drm_panel_prepare()
* drm_panel_prepare() -> panel_simple_prepare()
* Wait for HPD GPIO to go high.
* Start counting for 80 ms (store in prepared_time)
* In bridge chip enable, train link then call drm_panel_enable()
* drm_panel_enable() -> panel_simple_enable()
* panel_simple_enable() does hardcoded 50 ms delay then enforces 80 ms
from HPD going high (in case the bridge took less than 30 ms to
enable / link train).
* drm_panel_enable() -> backlight_enable().
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 9858079f9e14..9d36b74357ae 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1445,6 +1445,7 @@ static const struct panel_desc boe_nv110wtm_n61 = {
.delay = {
.hpd_absent_delay = 200,
.prepare_to_enable = 80,
+ .enable = 50,
.unprepare = 500,
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
--
2.30.0.617.g56c4b15f3c-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff
On Mon, Feb 22, 2021 at 09:34:43AM +0100, Boris Brezillon wrote: > Hi Daniel, > > On Fri, 19 Feb 2021 18:45:00 +0100 > Daniel Vetter wrote: > > > On Fri, Feb 19, 2021 at 5:17 PM Steven Price wrote: > > > > > > On 19/02/2021 15:13, Daniel Vetter wrote: > > > > On Fri, Feb 19, 2021 at 01:36:06PM +, Steven Price wrote: > > > >> On 18/02/2021 18:20, Daniel Vetter wrote: > > > >>> On Thu, Feb 18, 2021 at 6:16 PM Rob Herring > > > >>> wrote: > > > > > > On Thu, Feb 18, 2021 at 10:51 AM Steven Price > > > wrote: > > > > > > > > On 18/02/2021 16:38, Rob Herring wrote: > > > >> On Thu, Feb 18, 2021 at 10:15 AM Steven Price > > > >> wrote: > > > >>> > > > >>> On 18/02/2021 15:45, Alyssa Rosenzweig wrote: > > > > Yeah plus Cc: stable for backporting and I think an igt or > > > > similar for > > > > panfrost to check this works correctly would be pretty good > > > > too. Since > > > > if it took us over 1 year to notice this bug it's pretty clear > > > > that > > > > normal testing doesn't catch this. So very likely we'll break > > > > this > > > > again. > > > > > > Unfortunately there are a lot of kernel bugs which are noticed > > > during actual > > > use (but not CI runs), some of which have never been fixed. I do > > > know > > > the shrinker impl is buggy for us, if this is the fix I'm very > > > happy. > > > >>> > > > >>> I doubt this will actually "fix" anything - if I understand > > > >>> correctly > > > >>> then the sequence which is broken is: > > > >>> > > > >>> * allocate BO, mmap to CPU > > > >>> * madvise(DONTNEED) > > > >>> * trigger purge > > > >>> * try to access the BO memory > > > >>> > > > >>> which is an invalid sequence for user space - the attempt to > > > >>> access > > > >>> memory should cause a SIGSEGV. However because > > > >>> drm_vma_node_unmap() is > > > >>> unable to find the mappings there may still be page table entries > > > >>> present which would provide access to memory the kernel has > > > >>> freed. Which > > > >>> is of course a big security hole and so this fix is needed. > > > >>> > > > >>> In what way do you find the shrinker impl buggy? I'm aware > > > >>> there's some > > > >>> dodgy locking (although I haven't worked out how to fix it) - but > > > >>> AFAICT > > > >>> it's more deadlock territory rather than lacking in locks. Are > > > >>> there > > > >>> correctness issues? > > > >> > > > >> What's there was largely a result of getting lockdep happy. > > > >> > > > > btw for testing shrinkers recommended way is to have a debugfs > > > > file > > > > that just force-shrinks everything. That way you avoid all the > > > > trouble > > > > that tend to happen when you drive a system close to OOM on > > > > linux, and > > > > it's also much faster. > > > > > > 2nding this as a good idea. > > > > > > >>> > > > >>> Sounds like a good idea to me too. But equally I'm wondering > > > >>> whether the > > > >>> best (short term) solution is to actually disable the shrinker. > > > >>> I'm > > > >>> somewhat surprised that nobody has got fed up with the "Purging > > > >>> xxx > > > >>> bytes" message spam - which makes me think that most people are > > > >>> not > > > >>> hitting memory pressure to trigger the shrinker. > > > >> > > > >> If the shrinker is dodgy, then it's probably good to have the > > > >> messages > > > >> to know if it ran. > > > >> > > > >>> The shrinker on kbase caused a lot of grief - and the only way I > > > >>> managed > > > >>> to get that under control was by writing a static analysis tool > > > >>> for the > > > >>> locking, and by upsetting people by enforcing the (rather dumb) > > > >>> rules of > > > >>> the tool on the code base. I've been meaning to look at whether > > > >>> sparse > > > >>> can do a similar check of locks. > > > >> > > > >> Lockdep doesn't cover it? > > > > > > > > Short answer: no ;) > > > >>> > > > >>> It's pretty good actually, if you correctly annotate things up. > > > >> > > > >> I agree - it's pretty good, the problem is you need reasonable test > > > >> coverage, and getting good test coverage of shrinkers is hard. > > > >> > > > > The problem with lockdep is that you have to trigger the locking > > > > scenario to get a warning out of it. For example you obviously > > > > won't get > > > > any warnings about the shrinker without triggering the shrinker > > > > (which > > > > means memory pressure since we don't have the debug
Re: [PATCH] drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff
On Mon, Feb 22, 2021 at 03:24:17PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 17.02.21 um 17:59 schrieb Neil Roberts:
> > When mmapping the shmem, it would previously adjust the pgoff in the
> > vm_area_struct to remove the fake offset that is added to be able to
> > identify the buffer. This patch removes the adjustment and makes the
> > fault handler use the vm_fault address to calculate the page offset
> > instead. Although using this address is apparently discouraged, several
> > DRM drivers seem to be doing it anyway.
> >
> > The problem with removing the pgoff is that it prevents
> > drm_vma_node_unmap from working because that searches the mapping tree
> > by address. That doesn't work because all of the mappings are at offset
> > 0. drm_vma_node_unmap is being used by the shmem helpers when purging
> > the buffer.
>
> I just want to ask if this is how the mmap callbacks are supposed to work
> now?
>
> I have a number of patches in here that convert several drivers to the GEM
> object's mmap callback. They might not be affected by the vm_pgoff bug, but
> I'd like to submit something that could work in the longer term.
Yeah we pretty much require the uniq vm_pgoff for runtime unmapping.
Especially with more dynamic memory managers like ttm that move buffers
around - for more static ones (most of the armsoc ones) it's just a bit a
security issue since you can potentially access memory after it's gone.
-Daniel
> Best regards
> Thomas
>
> >
> > It looks like panfrost is using drm_gem_shmem_purge so this might fix a
> > potential bug there.
> >
> > Signed-off-by: Neil Roberts
> > ---
> > drivers/gpu/drm/drm_gem_shmem_helper.c | 12 +++-
> > 1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > index 9825c378dfa6..4b14157f1962 100644
> > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > @@ -526,11 +526,16 @@ static vm_fault_t drm_gem_shmem_fault(struct vm_fault
> > *vmf)
> > struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> > loff_t num_pages = obj->size >> PAGE_SHIFT;
> > struct page *page;
> > + pgoff_t page_offset;
> > - if (vmf->pgoff >= num_pages || WARN_ON_ONCE(!shmem->pages))
> > + /* We don't use vmf->pgoff since that has the fake offset */
> > + page_offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
> > +
> > + if (page_offset < 0 || page_offset >= num_pages ||
> > + WARN_ON_ONCE(!shmem->pages))
> > return VM_FAULT_SIGBUS;
> > - page = shmem->pages[vmf->pgoff];
> > + page = shmem->pages[page_offset];
> > return vmf_insert_page(vma, vmf->address, page);
> > }
> > @@ -581,9 +586,6 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj,
> > struct vm_area_struct *vma)
> > struct drm_gem_shmem_object *shmem;
> > int ret;
> > - /* Remove the fake offset */
> > - vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
> > -
> > if (obj->import_attach) {
> > /* Drop the reference drm_gem_mmap_obj() acquired.*/
> > drm_gem_object_put(obj);
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: atyfb: add stubs for aty_{ld,st}_lcd()
On Sun, Feb 21, 2021 at 07:28:53PM -0800, Randy Dunlap wrote:
> Fix build errors when these functions are not defined.
>
> ../drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_power_mgmt':
> ../drivers/video/fbdev/aty/atyfb_base.c:2002:7: error: implicit declaration
> of function 'aty_ld_lcd'; did you mean 'aty_ld_8'?
> [-Werror=implicit-function-declaration]
> 2002 | pm = aty_ld_lcd(POWER_MANAGEMENT, par);
> ../drivers/video/fbdev/aty/atyfb_base.c:2004:2: error: implicit declaration
> of function 'aty_st_lcd'; did you mean 'aty_st_8'?
> [-Werror=implicit-function-declaration]
> 2004 | aty_st_lcd(POWER_MANAGEMENT, pm, par);
>
> Signed-off-by: Randy Dunlap
> Reported-by: kernel test robot
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jani Nikula
stuffed into drm-misc-next-fixes for 5.12, thanks for your patch.
-Daniel
> ---
> drivers/video/fbdev/aty/atyfb_base.c |9 +
> 1 file changed, 9 insertions(+)
>
> --- linux-next-20210219.orig/drivers/video/fbdev/aty/atyfb_base.c
> +++ linux-next-20210219/drivers/video/fbdev/aty/atyfb_base.c
> @@ -175,6 +175,15 @@ u32 aty_ld_lcd(int index, const struct a
> return aty_ld_le32(LCD_DATA, par);
> }
> }
> +#else /* defined(CONFIG_PMAC_BACKLIGHT) || defined(CONFIG_FB_ATY_BACKLIGHT) \
> + defined(CONFIG_FB_ATY_GENERIC_LCD) */
> +void aty_st_lcd(int index, u32 val, const struct atyfb_par *par)
> +{ }
> +
> +u32 aty_ld_lcd(int index, const struct atyfb_par *par)
> +{
> + return 0;
> +}
> #endif /* defined(CONFIG_PMAC_BACKLIGHT) || defined
> (CONFIG_FB_ATY_GENERIC_LCD) */
>
> #ifdef CONFIG_FB_ATY_GENERIC_LCD
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/prime: Only call dma_map_sgtable() for devices with DMA support
Hi Am 22.02.21 um 17:10 schrieb Daniel Vetter: On Mon, Feb 22, 2021 at 2:24 PM Thomas Zimmermann wrote: Hi Am 22.02.21 um 14:09 schrieb Christian König: Am 22.02.21 um 13:43 schrieb Thomas Zimmermann: USB-based drivers cannot use DMA, so the importing of dma-buf attachments currently fails for udl and gm12u320. This breaks joining/mirroring of displays. The fix is now a little series. To solve the issue on the importer side (i.e., the affected USB-based driver), patch 1 introduces a new PRIME callback, struct drm_driver.gem_prime_create_object, which creates an object and gives more control to the importing driver. Specifically, udl and gm12u320 can now avoid the creation of a scatter/gather table for the imported pages. Patch 1 is self-contained in the sense that it can be backported into older kernels. Mhm, that sounds like a little overkill to me. Drivers can already import the DMA-bufs all by them selves without the help of the DRM functions. See amdgpu for an example. Daniel also already noted to me that he sees the DRM helper as a bit questionable middle layer. And this bug proves that it is. :) The trouble here is actually gem_bo->import_attach, which isn't really part of the questionable midlayer, but fairly mandatory (only exception is vmwgfx because not using gem) caching to make sure we don't end up with duped imports and fun stuff like that. And dma_buf_attach now implicitly creates the sg table already, so we're already in game over land. I think we'd need to make import_attach a union with import_buf or something like that, so that you can do attachment-less importing. Creating the sg table is not the problem; mapping it is. So dma_buf_attach shouldn't be a problem. Have you thought about doing that instead? There appears to be some useful code in drm_gem_prime_import_dev(). But if the general sentiment goes towards removing gem_prime_import_sg_table, we can work towards that as well. I still think this part is a bit a silly midlayer for no good reason, but I think that's orthogonal to the issue at hand here. I'd suggest we first try to paper over the issue by using prime_import_dev with the host controller (which hopefully is dma-capable for most systems). And then, at leisure, try to untangle the obj->import_attach issue. I really don't want to do this. My time is also limited, and I''ll spend time papering over the thing. And then more time for the real fix. I'd rather pull drm_gem_prime_import_dev() in to USB drivers and avoid the dma_buf_map(). Best regard Thomas -Daniel Best regards Thomas Christian. Patches 2 and 3 update SHMEM and CMA helpers to use the new callback. Effectively this moves the sg table setup from the PRIME helpers into the memory managers. SHMEM now supports devices without DMA support, so custom code can be removed from udl and g12u320. Tested by joining/mirroring displays of udl and radeon under Gnome/X11. v2: * move fix to importer side (Christian, Daniel) * update SHMEM and CMA helpers for new PRIME callbacks Thomas Zimmermann (3): drm: Support importing dmabufs into drivers without DMA drm/shmem-helper: Implement struct drm_driver.gem_prime_create_object drm/cma-helper: Implement struct drm_driver.gem_prime_create_object drivers/gpu/drm/drm_gem_cma_helper.c| 62 ++--- drivers/gpu/drm/drm_gem_shmem_helper.c | 38 ++- drivers/gpu/drm/drm_prime.c | 43 +++-- drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_gem.c | 6 +-- drivers/gpu/drm/panfrost/panfrost_gem.h | 4 +- drivers/gpu/drm/pl111/pl111_drv.c | 8 ++-- drivers/gpu/drm/v3d/v3d_bo.c| 6 +-- drivers/gpu/drm/v3d/v3d_drv.c | 2 +- drivers/gpu/drm/v3d/v3d_drv.h | 5 +- include/drm/drm_drv.h | 12 + include/drm/drm_gem_cma_helper.h| 12 ++--- include/drm/drm_gem_shmem_helper.h | 6 +-- 14 files changed, 120 insertions(+), 88 deletions(-) -- 2.30.1 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Support importing dmabufs into drivers without DMA
On Mon, Feb 22, 2021 at 01:43:26PM +0100, Thomas Zimmermann wrote:
> USB devices cannot perform DMA and hence have no dma_mask set in their
> device structure. Importing dmabuf into a USB-based driver fails, which
> break joining and mirroring of display in X11. A corresponding error
> message is shown below.
>
> [ 60.050199] [ cut here ]
> [ 60.055092] WARNING: CPU: 0 PID: 1403 at kernel/dma/mapping.c:190
> dma_map_sg_attrs+0x8f/0xc0
> [ 60.064331] Modules linked in: af_packet(E) rfkill(E) dmi_sysfs(E)
> intel_rapl_msr(E) intel_rapl_common(E) snd_hda_codec_realtek(E)
> snd_hda_codec_generic(E) ledtrig_audio(E) snd_hda_codec_hdmi(E)
> x86_pkg_temp_thermal(E) intel_powerclam)
> [ 60.064801] wmi(E) video(E) btrfs(E) blake2b_generic(E) libcrc32c(E)
> crc32c_intel(E) xor(E) raid6_pq(E) sg(E) dm_multipath(E) dm_mod(E)
> scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) msr(E) efivarfs(E)
> [ 60.170778] CPU: 0 PID: 1403 Comm: Xorg.bin Tainted: GE
> 5.11.0-rc5-1-default+ #747
> [ 60.179841] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24
> 10/24/2018
> [ 60.187145] RIP: 0010:dma_map_sg_attrs+0x8f/0xc0
> [ 60.191822] Code: 4d 85 ff 75 2b 49 89 d8 44 89 e1 44 89 f2 4c 89 ee 48 89
> ef e8 62 30 00 00 85 c0 78 36 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 0b <0f> 0b
> 31 c0 eb ed 49 8d 7f 50 e8 72 f5 2a 00 49 8b 47 50 49 89 d8
> [ 60.210770] RSP: 0018:c90001d6fc18 EFLAGS: 00010246
> [ 60.216062] RAX: RBX: 0020 RCX:
> b31e677b
> [ 60.223274] RDX: dc00 RSI: 888212c10600 RDI:
> 8881b08a9488
> [ 60.230501] RBP: 8881b08a9030 R08: 0020 R09:
> 888212c10600
> [ 60.237710] R10: ed10425820df R11: 0001 R12:
>
> [ 60.244939] R13: 888212c10600 R14: 0008 R15:
>
> [ 60.252155] FS: 7f08ac2b2f00() GS:8887cbe0()
> knlGS:
> [ 60.260333] CS: 0010 DS: ES: CR0: 80050033
> [ 60.266150] CR2: 55831c899be8 CR3: 00015372e006 CR4:
> 001706f0
> [ 60.273369] Call Trace:
> [ 60.275845] drm_gem_map_dma_buf+0xb4/0x120
> [ 60.280089] dma_buf_map_attachment+0x15d/0x1e0
> [ 60.284688] drm_gem_prime_import_dev.part.0+0x5d/0x140
> [ 60.289984] drm_gem_prime_fd_to_handle+0x213/0x280
> [ 60.294931] ? drm_prime_destroy_file_private+0x30/0x30
> [ 60.300224] drm_ioctl_kernel+0x131/0x180
> [ 60.304291] ? drm_setversion+0x230/0x230
> [ 60.308366] ? drm_prime_destroy_file_private+0x30/0x30
> [ 60.313659] drm_ioctl+0x2f1/0x500
> [ 60.317118] ? drm_version+0x150/0x150
> [ 60.320903] ? lock_downgrade+0xa0/0xa0
> [ 60.324806] ? do_vfs_ioctl+0x5f4/0x680
> [ 60.328694] ? __fget_files+0x13e/0x210
> [ 60.332591] ? ioctl_fiemap.isra.0+0x1a0/0x1a0
> [ 60.337102] ? __fget_files+0x15d/0x210
> [ 60.340990] __x64_sys_ioctl+0xb9/0xf0
> [ 60.344795] do_syscall_64+0x33/0x80
> [ 60.348427] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 60.353542] RIP: 0033:0x7f08ac7b53cb
> [ 60.357168] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff ff ff
> 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 8b 0d 75 ba 0c 00 f7 d8 64 89 01 48
> [ 60.376108] RSP: 002b:7ffeabc89fc8 EFLAGS: 0246 ORIG_RAX:
> 0010
> [ 60.383758] RAX: ffda RBX: 7ffeabc8a00c RCX:
> 7f08ac7b53cb
> [ 60.390970] RDX: 7ffeabc8a00c RSI: c00c642e RDI:
> 000d
> [ 60.398221] RBP: c00c642e R08: 55831c691d00 R09:
> 55831b2ec010
> [ 60.405446] R10: 7f08acf6ada0 R11: 0246 R12:
> 55831c691d00
> [ 60.412667] R13: 000d R14: 007e9000 R15:
>
> [ 60.419903] irq event stamp: 672893
> [ 60.423441] hardirqs last enabled at (672913): []
> console_unlock+0x44d/0x500
> [ 60.432230] hardirqs last disabled at (672922): []
> console_unlock+0x443/0x500
> [ 60.441021] softirqs last enabled at (672940): []
> __do_softirq+0x3dd/0x554
> [ 60.449634] softirqs last disabled at (672931): []
> asm_call_irq_on_stack+0x12/0x20
> [ 60.458871] ---[ end trace f2f88696eb17806c ]---
>
> This patch introduces struct drm_driver.gem_prime_create_object, which
> creates a GEM object during the import. Drivers should implement this
> callback and handle DMA S/G table support by themselves. For USB-based
> drivers, the patch adds an implementation without DMA-related code.
>
> The original interface struct drm_driver.gem_prime_import_sg_table
> is deprecated. All drivers should switch over.
>
> Tested by joining/mirroring displays of udl and radeon un der Gnome/X11.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 6eb0233ec2d0 ("usb: don't inherity DMA properties for USB devices")
> Cc: Christoph Hellwig
> Cc: Greg Kroah-Hartman
> Cc: Alan Stern
> Cc: Johan Hovold
> Cc:
Re: [PATCH v2 2/2] drm/msm/dp: add supported max link rate specified from dtsi
On 2021-02-19 14:46, Stephen Boyd wrote: Quoting khs...@codeaurora.org (2021-02-19 08:39:38) On 2021-02-18 15:02, Stephen Boyd wrote: > Quoting Kuogee Hsieh (2021-02-18 12:55:04) >> Allow supported link rate to be limited to the value specified at >> dtsi. If it is not specified, then link rate is derived from dpcd >> directly. Below are examples, >> link-rate = <162000> for max link rate limited at 1.62G >> link-rate = <27> for max link rate limited at 2.7G >> link-rate = <54> for max link rate limited at 5.4G >> link-rate = <81> for max link rate limited at 8.1G >> >> Changes in V2: >> -- allow supported max link rate specified from dtsi > > Please don't roll this into the patch that removes the limit. The > previous version of this patch was fine. The part that lowers the limit > back down should be another patch. > > We rejected link-rate in DT before and we should reject it upstream > again. As far as I can tell, the maximum link rate should be determined > based on the panel or the type-c port on the board. The dp controller > can always achieve HBR3, so limiting it at the dp controller is > incorrect. The driver should query the endpoints to figure out if they > want to limit the link rate. Is that done automatically sometimes by > intercepting the DPCD? ok, i will roll back to original patch and add the second patch for max link rate limited purpose. panel dpcd specified max link rate it supported. At driver, link rate is derived from dpcd directly since driver will try to use the maximum supported link rate and less lane to save power. Therefore it is not possible that limit link rate base on dpcd. AS i understand we are going to do max link rate limitation is due to old redriver chip can not support HBR3. How can I acquire which type-c port on the board so that I can trigger max link rate limitation? The driver already seems to support lowering the link rate during link training. Can't we try to train at the highest rate and then downgrade the link speed until it trains properly? I sort of fail to see why we need to introduce a bunch of complexity around limiting the link rate on certain boards if the driver can figure out that link training doesn't work at HBR3 so it should try to train at HBR2 instead. yes, dp driver did support down grade link rate during link training procedure. But link training is kind of setting up agreement between host and panel with assumption that there are no other limitations in between. The problem we are discussing here is the limitation of usb re driver link rate support. Since we do not know how usb re driver behavior, I am not sure link training will work appropriately for this case. It may end up link status keep toggling up and down. Both link-lane and link-rate specified at dtsi are for the limitation of Trogdor hardware platform. Both link-lane and link-rate specified at dtsi are NOT for panel since panel have specified its capability at its DPCD. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/prime: Only call dma_map_sgtable() for devices with DMA support
On Mon, Feb 22, 2021 at 05:25:46PM +0100, Thomas Zimmermann wrote: > Hi > > Am 22.02.21 um 17:10 schrieb Daniel Vetter: > > On Mon, Feb 22, 2021 at 2:24 PM Thomas Zimmermann > > wrote: > > > > > > Hi > > > > > > Am 22.02.21 um 14:09 schrieb Christian König: > > > > > > > > > > > > Am 22.02.21 um 13:43 schrieb Thomas Zimmermann: > > > > > USB-based drivers cannot use DMA, so the importing of dma-buf > > > > > attachments > > > > > currently fails for udl and gm12u320. This breaks joining/mirroring of > > > > > displays. > > > > > > > > > > The fix is now a little series. To solve the issue on the importer > > > > > side (i.e., the affected USB-based driver), patch 1 introduces a new > > > > > PRIME callback, struct drm_driver.gem_prime_create_object, which > > > > > creates > > > > > an object and gives more control to the importing driver. > > > > > Specifically, > > > > > udl and gm12u320 can now avoid the creation of a scatter/gather table > > > > > for the imported pages. Patch 1 is self-contained in the sense that it > > > > > can be backported into older kernels. > > > > > > > > Mhm, that sounds like a little overkill to me. > > > > > > > > Drivers can already import the DMA-bufs all by them selves without the > > > > help of the DRM functions. See amdgpu for an example. > > > > > > > > Daniel also already noted to me that he sees the DRM helper as a bit > > > > questionable middle layer. > > > > > > And this bug proves that it is. :) > > > > The trouble here is actually gem_bo->import_attach, which isn't really > > part of the questionable midlayer, but fairly mandatory (only > > exception is vmwgfx because not using gem) caching to make sure we > > don't end up with duped imports and fun stuff like that. > > > > And dma_buf_attach now implicitly creates the sg table already, so > > we're already in game over land. I think we'd need to make > > import_attach a union with import_buf or something like that, so that > > you can do attachment-less importing. > > Creating the sg table is not the problem; mapping it is. So dma_buf_attach > shouldn't be a problem. dma_buf_attach will create a cached sg-mapping for you if the exporter is dynamic. Currently that's only the case for amdgpu, I guess you didn't test with that. So yeah dma_buf_attach is a problem already. And if we can't attach, the entire obj->import_attach logic in drm_prime.c falls over, and we get all kinds of fun with double import and re-export. > > > > Have you thought about doing that instead? > > > > > > There appears to be some useful code in drm_gem_prime_import_dev(). But > > > if the general sentiment goes towards removing > > > gem_prime_import_sg_table, we can work towards that as well. > > > > I still think this part is a bit a silly midlayer for no good reason, > > but I think that's orthogonal to the issue at hand here. > > > > I'd suggest we first try to paper over the issue by using > > prime_import_dev with the host controller (which hopefully is > > dma-capable for most systems). And then, at leisure, try to untangle > > the obj->import_attach issue. > > I really don't want to do this. My time is also limited, and I''ll spend > time papering over the thing. And then more time for the real fix. I'd > rather pull drm_gem_prime_import_dev() in to USB drivers and avoid the > dma_buf_map(). Yeah I understand, it's just (as usual :-/) more complex than it seems ... -Daniel > > Best regard > Thomas > > > -Daniel > > > > > > > > Best regards > > > Thomas > > > > > > > > > > > Christian. > > > > > > > > > > > > > > Patches 2 and 3 update SHMEM and CMA helpers to use the new callback. > > > > > Effectively this moves the sg table setup from the PRIME helpers into > > > > > the memory managers. SHMEM now supports devices without DMA support, > > > > > so custom code can be removed from udl and g12u320. > > > > > > > > > > Tested by joining/mirroring displays of udl and radeon under > > > > > Gnome/X11. > > > > > > > > > > v2: > > > > > * move fix to importer side (Christian, Daniel) > > > > > * update SHMEM and CMA helpers for new PRIME callbacks > > > > > > > > > > Thomas Zimmermann (3): > > > > > drm: Support importing dmabufs into drivers without DMA > > > > > drm/shmem-helper: Implement struct > > > > > drm_driver.gem_prime_create_object > > > > > drm/cma-helper: Implement struct > > > > > drm_driver.gem_prime_create_object > > > > > > > > > >drivers/gpu/drm/drm_gem_cma_helper.c| 62 > > > > > ++--- > > > > >drivers/gpu/drm/drm_gem_shmem_helper.c | 38 ++- > > > > >drivers/gpu/drm/drm_prime.c | 43 +++-- > > > > >drivers/gpu/drm/lima/lima_drv.c | 2 +- > > > > >drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- > > > > >drivers/gpu/drm/panfrost/panfrost_gem.c | 6 +-- > > > > >drivers/gpu/drm/panfrost/panfrost_gem.h | 4 +- > > > > >drivers/gpu/drm/pl111/pl111_drv.c |
Re: [RFC PATCH 1/3] drm/vkms: decouple cursor plane setup from crtc_init
On Sat, Feb 20, 2021 at 11:38:50AM -0300, Melissa Wen wrote:
> Initialize CRTC only with primary plane (without cursor) as a preparation
> to init overlay plane before cursor plane and keep cursor on the top.
>
> Signed-off-by: Melissa Wen
Why can't we first initialize all the planes (primary, cursor, overlay)
and then the crtc?
For drivers where there's not really a functional difference between these
planes (like vkms, since it's all sw, only difference is z position
really) the usual approach is to initialize all planes in a loop. And then
call crtc init with the first and last plane for that crtc.
Passing NULL for the cursor for crtc_init and then patching it up
afterwards is a bit a hack, so would be good to avoid that.
-Daniel
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 4 ++--
> drivers/gpu/drm/vkms/vkms_drv.h| 2 +-
> drivers/gpu/drm/vkms/vkms_output.c | 14 +-
> 3 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 0443b7deeaef..2d4cd7736933 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -270,12 +270,12 @@ static const struct drm_crtc_helper_funcs
> vkms_crtc_helper_funcs = {
> };
>
> int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> -struct drm_plane *primary, struct drm_plane *cursor)
> +struct drm_plane *primary)
> {
> struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
> int ret;
>
> - ret = drm_crtc_init_with_planes(dev, crtc, primary, cursor,
> + ret = drm_crtc_init_with_planes(dev, crtc, primary, NULL,
> &vkms_crtc_funcs, NULL);
> if (ret) {
> DRM_ERROR("Failed to init CRTC\n");
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 35540c7c4416..9ad5ad8b7737 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -110,7 +110,7 @@ struct vkms_device {
>
> /* CRTC */
> int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> -struct drm_plane *primary, struct drm_plane *cursor);
> +struct drm_plane *primary);
>
> int vkms_output_init(struct vkms_device *vkmsdev, int index);
>
> diff --git a/drivers/gpu/drm/vkms/vkms_output.c
> b/drivers/gpu/drm/vkms/vkms_output.c
> index f5f6f15c362c..05d3bb45e6c1 100644
> --- a/drivers/gpu/drm/vkms/vkms_output.c
> +++ b/drivers/gpu/drm/vkms/vkms_output.c
> @@ -47,6 +47,10 @@ int vkms_output_init(struct vkms_device *vkmsdev, int
> index)
> if (IS_ERR(primary))
> return PTR_ERR(primary);
>
> + ret = vkms_crtc_init(dev, crtc, primary);
> + if (ret)
> + goto err_crtc;
> +
> if (vkmsdev->config->cursor) {
> cursor = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_CURSOR, index);
> if (IS_ERR(cursor)) {
> @@ -55,9 +59,9 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
> }
> }
>
> - ret = vkms_crtc_init(dev, crtc, primary, cursor);
> - if (ret)
> - goto err_crtc;
> + crtc->cursor = cursor;
> + if (cursor && !cursor->possible_crtcs)
> + cursor->possible_crtcs = drm_crtc_mask(crtc);
>
> ret = drm_connector_init(dev, connector, &vkms_connector_funcs,
>DRM_MODE_CONNECTOR_VIRTUAL);
> @@ -100,11 +104,11 @@ int vkms_output_init(struct vkms_device *vkmsdev, int
> index)
> err_connector:
> drm_crtc_cleanup(crtc);
>
> -err_crtc:
> +err_cursor:
> if (vkmsdev->config->cursor)
> drm_plane_cleanup(cursor);
>
> -err_cursor:
> +err_crtc:
> drm_plane_cleanup(primary);
>
> return ret;
> --
> 2.30.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/3] drm/vkms: add overlay support
On Sat, Feb 20, 2021 at 11:42:12AM -0300, Melissa Wen wrote:
> Add support to overlay plane, in addition to primary and cursor
> planes. In this approach, the plane composition still requires an
> active primary plane and planes are composed associatively in the
> order: (primary <- overlay) <- cursor
>
> It enables to run the following IGT tests successfully:
> - kms_plane_cursor:
> - pipe-A-[overlay, primary, viewport]-size-[64, 128, 256]
> - kms_atomic:
> - plane-overlay-legacy
> and preserves the successful execution of kms_cursor_crc,
> kms_writeback and kms_flip
>
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 27 +--
> drivers/gpu/drm/vkms/vkms_drv.c | 5 +
> drivers/gpu/drm/vkms/vkms_drv.h | 1 +
> drivers/gpu/drm/vkms/vkms_output.c | 17 +++--
> drivers/gpu/drm/vkms/vkms_plane.c| 20 +++-
> 5 files changed, 53 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index be8f1d33c645..2116da9b5a43 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -144,11 +144,12 @@ static void compose_planes(struct vkms_composer
> *primary_composer,
>
> static int composite(void **vaddr_out,
>struct vkms_composer *primary_composer,
> - struct vkms_composer *cursor_composer)
> + struct vkms_crtc_state *crtc_state)
> {
> struct drm_framebuffer *fb = &primary_composer->fb;
> struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> struct drm_gem_shmem_object *shmem_obj = to_drm_gem_shmem_obj(gem_obj);
> + int i;
>
> if (!*vaddr_out) {
> *vaddr_out = kzalloc(shmem_obj->base.size, GFP_KERNEL);
> @@ -163,8 +164,14 @@ static int composite(void **vaddr_out,
>
> memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
>
> - if (cursor_composer)
> - compose_planes(primary_composer, cursor_composer, *vaddr_out);
> + /* If there are other planes besides primary, we consider the active
> + * planes should be in z-order and compose them associatively:
> + * ((primary <- overlay) <- cursor)
> + */
> + for (i = 1; i < crtc_state->num_active_planes; i++)
> + compose_planes(primary_composer,
> +crtc_state->active_planes[i]->composer,
> +*vaddr_out);
>
> return 0;
> }
> @@ -186,7 +193,7 @@ void vkms_composer_worker(struct work_struct *work)
> struct drm_crtc *crtc = crtc_state->base.crtc;
> struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> struct vkms_composer *primary_composer = NULL;
> - struct vkms_composer *cursor_composer = NULL;
> + struct vkms_plane_state *act_plane = NULL;
> bool crc_pending, wb_pending;
> void *vaddr_out = NULL;
> u32 crc32 = 0;
> @@ -210,11 +217,11 @@ void vkms_composer_worker(struct work_struct *work)
> if (!crc_pending)
> return;
>
> - if (crtc_state->num_active_planes >= 1)
> - primary_composer = crtc_state->active_planes[0]->composer;
> -
> - if (crtc_state->num_active_planes == 2)
> - cursor_composer = crtc_state->active_planes[1]->composer;
> + if (crtc_state->num_active_planes >= 1) {
> + act_plane = crtc_state->active_planes[0];
> + if (act_plane->base.plane->type == DRM_PLANE_TYPE_PRIMARY)
> + primary_composer = act_plane->composer;
> + }
>
> if (!primary_composer)
> return;
> @@ -222,7 +229,7 @@ void vkms_composer_worker(struct work_struct *work)
> if (wb_pending)
> vaddr_out = crtc_state->active_writeback;
>
> - ret = composite(&vaddr_out, primary_composer, cursor_composer);
> + ret = composite(&vaddr_out, primary_composer, crtc_state);
> if (ret) {
> if (ret == -EINVAL && !wb_pending)
> kfree(vaddr_out);
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 2173b82606f6..027ffe759440 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -44,6 +44,10 @@ static bool enable_writeback = true;
> module_param_named(enable_writeback, enable_writeback, bool, 0444);
> MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector
> support");
>
> +static bool enable_overlay;
> +module_param_named(enable_overlay, enable_overlay, bool, 0444);
> +MODULE_PARM_DESC(enable_overlay, "Enable/Disable overlay support");
> +
> DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
>
> static void vkms_release(struct drm_device *dev)
> @@ -198,6 +202,7 @@ static int __init vkms_init(void)
>
> config->cursor = enable_cursor;
> config->writeback = enable_writeback;
> + config->overlay = enable_overlay;
>
>
Re: [PATCH 00/20] Manual replacement of all strlcpy in favor of strscpy
On 2/22/21 8:12 AM, Romain Perier wrote: strlcpy() copy a C-String into a sized buffer, the result is always a valid NULL-terminated that fits in the buffer, howerver it has severals issues. It reads the source buffer first, which is dangerous if it is non NULL-terminated or if the corresponding buffer is unbounded. Its safe replacement is strscpy(), as suggested in the deprecated interface [1]. We plan to make this contribution in two steps: - Firsly all cases of strlcpy's return value are manually replaced by the corresponding calls of strscpy() with the new handling of the return value (as the return code is different in case of error). - Then all other cases are automatically replaced by using coccinelle. Cool. A quick check shows me 1031 strscpy() calls with no return checks. All or some of these probably need to be reviewed and add return checks. Is this something that is in the plan to address as part of this work? thanks, -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v2 2/2] drm/msm/dp: add supported max link rate specified from dtsi
On Mon, Feb 22, 2021 at 11:31 AM wrote: > > On 2021-02-19 14:46, Stephen Boyd wrote: > > Quoting khs...@codeaurora.org (2021-02-19 08:39:38) > >> On 2021-02-18 15:02, Stephen Boyd wrote: > >> > Quoting Kuogee Hsieh (2021-02-18 12:55:04) > >> >> Allow supported link rate to be limited to the value specified at > >> >> dtsi. If it is not specified, then link rate is derived from dpcd > >> >> directly. Below are examples, > >> >> link-rate = <162000> for max link rate limited at 1.62G > >> >> link-rate = <27> for max link rate limited at 2.7G > >> >> link-rate = <54> for max link rate limited at 5.4G > >> >> link-rate = <81> for max link rate limited at 8.1G > >> >> > >> >> Changes in V2: > >> >> -- allow supported max link rate specified from dtsi > >> > > >> > Please don't roll this into the patch that removes the limit. The > >> > previous version of this patch was fine. The part that lowers the limit > >> > back down should be another patch. > >> > > >> > We rejected link-rate in DT before and we should reject it upstream > >> > again. As far as I can tell, the maximum link rate should be determined > >> > based on the panel or the type-c port on the board. The dp controller > >> > can always achieve HBR3, so limiting it at the dp controller is > >> > incorrect. The driver should query the endpoints to figure out if they > >> > want to limit the link rate. Is that done automatically sometimes by > >> > intercepting the DPCD? > >> > >> ok, i will roll back to original patch and add the second patch for > >> max > >> link rate limited purpose. > >> panel dpcd specified max link rate it supported. > >> At driver, link rate is derived from dpcd directly since driver will > >> try > >> to use the maximum supported link rate and less lane to save power. > >> Therefore it is not possible that limit link rate base on dpcd. > >> AS i understand we are going to do max link rate limitation is due to > >> old redriver chip can not support HBR3. > >> How can I acquire which type-c port on the board so that I can trigger > >> max link rate limitation? > >> > >> > > > > The driver already seems to support lowering the link rate during link > > training. Can't we try to train at the highest rate and then downgrade > > the link speed until it trains properly? I sort of fail to see why we > > need to introduce a bunch of complexity around limiting the link rate > > on > > certain boards if the driver can figure out that link training doesn't > > work at HBR3 so it should try to train at HBR2 instead. > > yes, dp driver did support down grade link rate during link training > procedure. > But link training is kind of setting up agreement between host and panel > with assumption that there are no other limitations in between. > The problem we are discussing here is the limitation of usb re driver > link rate support. > Since we do not know how usb re driver behavior, I am not sure link > training will work appropriately for this case. > It may end up link status keep toggling up and down. > IMO we should just fail link training if the redriver doesn't support a link count/rate and fallback to the next count/rate. This should be handled the same as if there were a cable incapable of achieving a link rate. Adding the link rate to the device tree (at least on the dp block) seems suspicious. If you really wanted to model the redriver's limitations in software, you'd probably want to introduce a bridge driver/connector which rejects modes that cannot be achieved by the redriver. This should prevent the dp driver from trying to train at the unsupported rates. Sean > Both link-lane and link-rate specified at dtsi are for the limitation of > Trogdor hardware platform. > Both link-lane and link-rate specified at dtsi are NOT for panel since > panel have specified its capability at its DPCD. > > > > > > > > > ___ > Freedreno mailing list > freedr...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/freedreno ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/dp_mst: Set CLEAR_PAYLOAD_ID_TABLE as broadcast
On Mon, Feb 22, 2021 at 12:00:27PM +0800, Wayne Lin wrote: > [Why & How] > According to DP spec, CLEAR_PAYLOAD_ID_TABLE is a path broadcast request > message and current implementation is incorrect. Fix it. > > Signed-off-by: Wayne Lin > Cc: sta...@vger.kernel.org > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > b/drivers/gpu/drm/drm_dp_mst_topology.c > index 713ef3b42054..6d73559046e5 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -1072,6 +1072,7 @@ static void build_clear_payload_id_table(struct > drm_dp_sideband_msg_tx *msg) > > req.req_type = DP_CLEAR_PAYLOAD_ID_TABLE; > drm_dp_encode_sideband_req(&req, msg); > + msg->path_msg = true; > } > > static int build_enum_path_resources(struct drm_dp_sideband_msg_tx *msg, > @@ -2722,7 +2723,8 @@ static int set_hdr_from_dst_qlock(struct > drm_dp_sideband_msg_hdr *hdr, > > req_type = txmsg->msg[0] & 0x7f; > if (req_type == DP_CONNECTION_STATUS_NOTIFY || > - req_type == DP_RESOURCE_STATUS_NOTIFY) > + req_type == DP_RESOURCE_STATUS_NOTIFY || > + req_type == DP_CLEAR_PAYLOAD_ID_TABLE) > hdr->broadcast = 1; Looks correct. Reviewed-by: Ville Syrjälä Hmm. Looks like we're missing DP_POWER_DOWN_PHY and DP_POWER_UP_PHY here as well. We do try to send them as path requests, but apparently forget to mark them as broadcast messages. > else > hdr->broadcast = 0; > -- > 2.17.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/dp_mst: Revise broadcast msg lct & lcr
On Mon, Feb 22, 2021 at 12:00:26PM +0800, Wayne Lin wrote:
> [Why & How]
> According to DP spec, broadcast message LCT equals to 1 and LCR equals
> to 6. Current implementation is incorrect. Fix it.
>
> Signed-off-by: Wayne Lin
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 17dbed0a9800..713ef3b42054 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2727,8 +2727,14 @@ static int set_hdr_from_dst_qlock(struct
> drm_dp_sideband_msg_hdr *hdr,
> else
> hdr->broadcast = 0;
> hdr->path_msg = txmsg->path_msg;
> - hdr->lct = mstb->lct;
> - hdr->lcr = mstb->lct - 1;
> + if (hdr->broadcast) {
> + hdr->lct = 1;
> + hdr->lcr = 6;
> + } else {
> + hdr->lct = mstb->lct;
> + hdr->lcr = mstb->lct - 1;
> + }
> +
> if (mstb->lct > 1)
> memcpy(hdr->rad, mstb->rad, mstb->lct / 2);
We should also do something about RAD no?
>
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/dp_mst: Revise broadcast msg lct & lcr
On Mon, Feb 22, 2021 at 07:02:03PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 22, 2021 at 12:00:26PM +0800, Wayne Lin wrote:
> > [Why & How]
> > According to DP spec, broadcast message LCT equals to 1 and LCR equals
> > to 6. Current implementation is incorrect. Fix it.
> >
> > Signed-off-by: Wayne Lin
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 10 --
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 17dbed0a9800..713ef3b42054 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -2727,8 +2727,14 @@ static int set_hdr_from_dst_qlock(struct
> > drm_dp_sideband_msg_hdr *hdr,
> > else
> > hdr->broadcast = 0;
> > hdr->path_msg = txmsg->path_msg;
> > - hdr->lct = mstb->lct;
> > - hdr->lcr = mstb->lct - 1;
> > + if (hdr->broadcast) {
> > + hdr->lct = 1;
> > + hdr->lcr = 6;
> > + } else {
> > + hdr->lct = mstb->lct;
> > + hdr->lcr = mstb->lct - 1;
> > + }
> > +
> > if (mstb->lct > 1)
> > memcpy(hdr->rad, mstb->rad, mstb->lct / 2);
>
> We should also do something about RAD no?
Just skip the RAD stuff by s/mstb->lct/hdr->lct/ here I guess?
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv1 3/6] dt-bindings: vendor-prefixes: add congatec
Document binding for congatec. Signed-off-by: Sebastian Reichel --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 041ae90b0d8f..a32db51df6c8 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -239,6 +239,8 @@ patternProperties: description: Colorful GRP, Shenzhen Xueyushi Technology Ltd. "^compulab,.*": description: CompuLab Ltd. + "^congatec,.*": +description: congatec GmbH "^coreriver,.*": description: CORERIVER Semiconductor Co.,Ltd. "^corpro,.*": -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv1 1/6] rtc: m41t80: add support for protected clock
Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The modules SQW clock output defaults to 32768 Hz. This behaviour is used to provide the i.MX6 CKIL clock. Once the RTC driver is probed, the clock is disabled and all i.MX6 functionality depending on the 32 KHz clock has undefined behaviour. On systems using hardware watchdog it seems to likely trigger a lot earlier than configured. The proper solution would be to describe this dependency in DT, but that will result in a deadlock. The kernel will see, that i.MX6 system clock needs the RTC clock and do probe deferral. But the i.MX6 I2C module never becomes usable without the i.MX6 CKIL clock and thus the RTC's clock will not be probed. So from the kernel's perspective this is a chicken-and-egg problem. Technically everything is fine by not touching anything, since the RTC clock correctly enables the clock on reset (i.e. on battery backup power loss) and also the bootloader enables it in case a kernel without this support has been booted. The 'protected-clocks' property is already in use for some clocks that may not be touched because of firmware limitations and is described in Documentation/devicetree/bindings/clock/clock-bindings.txt. Signed-off-by: Sebastian Reichel --- Documentation/devicetree/bindings/rtc/rtc-m41t80.txt | 1 + drivers/rtc/rtc-m41t80.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt index c746cb221210..ea4bbf5c4282 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt +++ b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt @@ -19,6 +19,7 @@ Optional properties: - interrupts: rtc alarm interrupt. - clock-output-names: From common clock binding to override the default output clock name +- protected-clocks: Bool, if set operating system should not handle clock. - wakeup-source: Enables wake up of host system on alarm Example: diff --git a/drivers/rtc/rtc-m41t80.c b/drivers/rtc/rtc-m41t80.c index 160dcf68e64e..3296583853a8 100644 --- a/drivers/rtc/rtc-m41t80.c +++ b/drivers/rtc/rtc-m41t80.c @@ -546,6 +546,9 @@ static struct clk *m41t80_sqw_register_clk(struct m41t80_data *m41t80) struct clk_init_data init; int ret; + if (of_property_read_bool(node, "protected-clocks")) + return 0; + /* First disable the clock */ ret = i2c_smbus_read_byte_data(client, M41T80_REG_ALARM_MON); if (ret < 0) -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv1 6/6] ARM: dts: imx6: Add GE B1x5v2
This adds device tree files for the General Electric Healthcare
(GEHC) B1x5v2 series. All models make use of Congatec's QMX6 module,
which is described in its own device tree include, so that it can
also be used by other boards.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/Makefile| 5 +
arch/arm/boot/dts/imx6dl-b105pv2.dts | 35 ++
arch/arm/boot/dts/imx6dl-b105v2.dts | 35 ++
arch/arm/boot/dts/imx6dl-b125pv2.dts | 33 ++
arch/arm/boot/dts/imx6dl-b125v2.dts | 33 ++
arch/arm/boot/dts/imx6dl-b155v2.dts | 36 ++
arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi | 434 ++
arch/arm/boot/dts/imx6dl-b1x5v2.dtsi | 61 +++
arch/arm/boot/dts/imx6dl-qmx6.dtsi| 623 ++
9 files changed, 1295 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-b105pv2.dts
create mode 100644 arch/arm/boot/dts/imx6dl-b105v2.dts
create mode 100644 arch/arm/boot/dts/imx6dl-b125pv2.dts
create mode 100644 arch/arm/boot/dts/imx6dl-b125v2.dts
create mode 100644 arch/arm/boot/dts/imx6dl-b155v2.dts
create mode 100644 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi
create mode 100644 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi
create mode 100644 arch/arm/boot/dts/imx6dl-qmx6.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3d1ea0b25168..cd6bf51d27ec 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -513,6 +513,11 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-dms-ba16.dtb \
imx6q-emcon-avari.dtb \
imx6q-evi.dtb \
+ imx6dl-b105v2.dtb \
+ imx6dl-b105pv2.dtb \
+ imx6dl-b125v2.dtb \
+ imx6dl-b125pv2.dtb \
+ imx6dl-b155v2.dtb \
imx6q-gk802.dtb \
imx6q-gw51xx.dtb \
imx6q-gw52xx.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-b105pv2.dts
b/arch/arm/boot/dts/imx6dl-b105pv2.dts
new file mode 100644
index ..0d5be2f9471f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b105pv2.dts
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B105Pv2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5pv2.dtsi"
+
+/ {
+ model = "General Electric B105Pv2";
+ compatible = "ge,imx6dl-b105pv2", "congatec,qmx6", "fsl,imx6dl";
+
+ panel {
+ compatible = "auo,g101evn010";
+ status = "okay";
+ };
+};
+
+&i2c3 {
+ touchscreen@41 {
+ reg = <0x41>;
+ compatible = "ilitek,ili251x";
+
+ pinctrl-names = "default";
+ pinctrl-0 =<&pinctrl_q7_gpio0>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&tca6424a 21 GPIO_ACTIVE_LOW>;
+
+ touchscreen-size-x = <1280>;
+ touchscreen-size-y = <800>;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6dl-b105v2.dts
b/arch/arm/boot/dts/imx6dl-b105v2.dts
new file mode 100644
index ..72a085348304
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b105v2.dts
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B105v2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5v2.dtsi"
+
+/ {
+ model = "General Electric B105v2";
+ compatible = "ge,imx6dl-b105v2", "congatec,qmx6", "fsl,imx6dl";
+
+ panel {
+ compatible = "auo,g101evn010";
+ status = "okay";
+ };
+};
+
+&i2c3 {
+ touchscreen@41 {
+ reg = <0x41>;
+ compatible = "ilitek,ili251x";
+
+ pinctrl-names = "default";
+ pinctrl-0 =<&pinctrl_q7_gpio0>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&tca6424a 21 GPIO_ACTIVE_LOW>;
+
+ touchscreen-size-x = <1280>;
+ touchscreen-size-y = <800>;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6dl-b125pv2.dts
b/arch/arm/boot/dts/imx6dl-b125pv2.dts
new file mode 100644
index ..8fd6c8ed6750
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b125pv2.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B125Pv2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5pv2.dtsi"
+
+/ {
+ model = "General Electric B125Pv2";
+ compatible = "ge,imx6dl-b125pv2", "congatec,qmx6", "fsl,imx6dl";
+
+ panel {
+ compatible = "auo,g121ean01";
+ status = "okay";
+ };
+};
+
+&i2c3 {
+ touchscreen@2a {
+ reg = <0x2a>;
+ compatible = "eeti,exc80h60";
+
+ pinctrl-names = "default";
+ pinctrl-0 =<&pinctrl_q7_gpio0>;
+ interrupt-par
[PATCHv1 0/6] Support for GE B1x5v2
Hi, This series adds support for another General Electric patient monitor series (similar to existing Bx50v3), which is based on i.MX6DL using Congatec's QMX6 module. The module uses an I2C RTC to provide the i.MX6 32768 Hz clock, so it's important to keep it enabled. Not doing so results in incorrect timings of watchdog and i.MX6 RTC. The bootloader enables the watchdog, so disabling the clock results in system reboot. [0] The second patch is required for B155v2, which uses a 1366x768 G156XTN01 panel. The 1366 width is not supported by the display pipeline and result in boot hanging without the patch. [1] Patches 3+4 are updating DT bindings for the new board compatible values. Patch 5 adds missing sst25vf032b to spi-nor bindings. Checkpatch still complains, since the binding lists all chips without vendor prefix. This probably should be fixed when the files is moved to YAML, but is non-trivial since those chips are manufactured by multiple vendors. E.g. sst25vf032b can be sourced from at least sst and microchip. Finally patch 6 adds the board files. Thanks, [0] There has been a discussion for the problem on the mailinglists last year. The discussion died off, when I told people their ideas don't work. I hope using protected-clocks is fine for this usecase. https://lore.kernel.org/linux-clk/20191108170135.9053-1-sebastian.reic...@collabora.com/ [1] I've sent this before as a separate patch in September, but nobody seemed to care. This adds full context for the problem. https://lore.kernel.org/dri-devel/20200910162831.321556-1-sebastian.reic...@collabora.com/ -- Sebastian Sebastian Reichel (6): rtc: m41t80: add support for protected clock drm/imx: Add 8 pixel alignment fix dt-bindings: vendor-prefixes: add congatec dt-bindings: arm: fsl: add GE B1x5pv2 boards dt-bindings: mtd: jedec,spi-nor: add sst25vf032b ARM: dts: imx6: Add GE B1x5v2 .../devicetree/bindings/arm/fsl.yaml | 11 + .../devicetree/bindings/mtd/jedec,spi-nor.txt | 1 + .../devicetree/bindings/rtc/rtc-m41t80.txt| 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile| 5 + arch/arm/boot/dts/imx6dl-b105pv2.dts | 35 + arch/arm/boot/dts/imx6dl-b105v2.dts | 35 + arch/arm/boot/dts/imx6dl-b125pv2.dts | 33 + arch/arm/boot/dts/imx6dl-b125v2.dts | 33 + arch/arm/boot/dts/imx6dl-b155v2.dts | 36 + arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi | 434 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi | 61 ++ arch/arm/boot/dts/imx6dl-qmx6.dtsi| 623 ++ drivers/gpu/drm/imx/imx-drm-core.c| 19 +- drivers/gpu/drm/imx/imx-ldb.c | 5 + drivers/gpu/drm/imx/ipuv3-crtc.c | 11 +- drivers/gpu/drm/imx/ipuv3-plane.c | 19 +- drivers/gpu/ipu-v3/ipu-dc.c | 5 + drivers/gpu/ipu-v3/ipu-di.c | 7 + drivers/rtc/rtc-m41t80.c | 3 + 20 files changed, 1373 insertions(+), 6 deletions(-) create mode 100644 arch/arm/boot/dts/imx6dl-b105pv2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b105v2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b125pv2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b125v2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b155v2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi create mode 100644 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi create mode 100644 arch/arm/boot/dts/imx6dl-qmx6.dtsi -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv1 5/6] dt-bindings: mtd: jedec,spi-nor: add sst25vf032b
The binding is already used by the driver. Update documentation accordingly. Signed-off-by: Sebastian Reichel --- Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt index f03be904d3c2..40e626e82ed0 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt @@ -31,6 +31,7 @@ Required properties: s25sl12801 s25fl008k s25fl064k + sst25vf032b sst25vf040b m25p40 m25p80 -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv1 4/6] dt-bindings: arm: fsl: add GE B1x5pv2 boards
Document the compatible for GE B1x5pv2 boards. Signed-off-by: Sebastian Reichel --- Documentation/devicetree/bindings/arm/fsl.yaml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 34000f7fbe02..dd2b566314a0 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -393,6 +393,17 @@ properties: - const: armadeus,imx6dl-apf6 # APF6 (Solo) SoM - const: fsl,imx6dl + - description: i.MX6DL based congatec QMX6 Boards +items: + - enum: + - ge,imx6dl-b105v2 # General Electric B105v2 + - ge,imx6dl-b105pv2 # General Electric B105Pv2 + - ge,imx6dl-b125v2 # General Electric B125v2 + - ge,imx6dl-b125pv2 # General Electric B125Pv2 + - ge,imx6dl-b155v2 # General Electric B155v2 + - const: congatec,qmx6 + - const: fsl,imx6dl + - description: i.MX6DL based DFI FS700-M60-6DL Board items: - const: dfi,fs700-m60-6dl -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv1 2/6] drm/imx: Add 8 pixel alignment fix
Some standard resolutions like 1366x768 do not work properly with
i.MX6 SoCs, since the horizontal resolution needs to be aligned
to 8 pixels (so 1360x768 or 1368x768 would work).
This patch allocates framebuffers allocated to 8 pixels. The extra
time required to send the extra pixels are removed from the blank
time. In order to expose the correct display size to userspace,
the stride is increased without increasing the width.
Suggested-by: Boris Brezillon
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/imx/imx-drm-core.c | 19 ++-
drivers/gpu/drm/imx/imx-ldb.c | 5 +
drivers/gpu/drm/imx/ipuv3-crtc.c | 11 ++-
drivers/gpu/drm/imx/ipuv3-plane.c | 19 +++
drivers/gpu/ipu-v3/ipu-dc.c| 5 +
drivers/gpu/ipu-v3/ipu-di.c| 7 +++
6 files changed, 60 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index d1a9841adeed..1bcf740b7f4f 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -145,9 +145,26 @@ static const struct drm_ioctl_desc imx_drm_ioctls[] = {
/* none so far */
};
+static int imx_drm_dumb_create(struct drm_file *file_priv,
+ struct drm_device *drm,
+ struct drm_mode_create_dumb *args)
+{
+ u32 width = args->width;
+ int ret;
+
+ args->width = ALIGN(width, 8);
+
+ ret = drm_gem_cma_dumb_create(file_priv, drm, args);
+ if (ret)
+ return ret;
+
+ args->width = width;
+ return ret;
+}
+
static const struct drm_driver imx_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
- DRM_GEM_CMA_DRIVER_OPS,
+ DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(imx_drm_dumb_create),
.ioctls = imx_drm_ioctls,
.num_ioctls = ARRAY_SIZE(imx_drm_ioctls),
.fops = &imx_drm_driver_fops,
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 41e2978cb1eb..9c7710c719d7 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -257,6 +257,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder
*encoder,
"%s: mode exceeds 85 MHz pixel clock\n", __func__);
}
+ if (!IS_ALIGNED(mode->hdisplay, 8)) {
+ dev_warn(ldb->dev,
+"%s: hdisplay does not align to 8 byte\n", __func__);
+ }
+
if (dual) {
serial_clk = 3500UL * mode->clock;
imx_ldb_set_clock(ldb, mux, 0, serial_clk, di_clk);
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 7ebd99ee3240..1ab970bcd52b 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -305,10 +305,19 @@ static void ipu_crtc_mode_set_nofb(struct drm_crtc *crtc)
sig_cfg.vsync_pin = imx_crtc_state->di_vsync_pin;
drm_display_mode_to_videomode(mode, &sig_cfg.mode);
+ if (!IS_ALIGNED(sig_cfg.mode.hactive, 8)) {
+ unsigned int new_hactive = ALIGN(sig_cfg.mode.hactive, 8);
+
+ dev_warn(ipu_crtc->dev, "8-pixel align hactive %d -> %d\n",
+sig_cfg.mode.hactive, new_hactive);
+
+ sig_cfg.mode.hfront_porch = new_hactive - sig_cfg.mode.hactive;
+ sig_cfg.mode.hactive = new_hactive;
+ }
ipu_dc_init_sync(ipu_crtc->dc, ipu_crtc->di,
mode->flags & DRM_MODE_FLAG_INTERLACE,
-imx_crtc_state->bus_format, mode->hdisplay);
+imx_crtc_state->bus_format, sig_cfg.mode.hactive);
ipu_di_init_sync_panel(ipu_crtc->di, &sig_cfg);
}
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 8a4235d9d9f1..5dd43e8c4d9e 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -29,6 +29,11 @@ to_ipu_plane_state(struct drm_plane_state *p)
return container_of(p, struct ipu_plane_state, base);
}
+static unsigned int ipu_src_rect_width(const struct drm_plane_state *state)
+{
+ return ALIGN(drm_rect_width(&state->src) >> 16, 8);
+}
+
static inline struct ipu_plane *to_ipu_plane(struct drm_plane *p)
{
return container_of(p, struct ipu_plane, base);
@@ -418,6 +423,12 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (old_fb && fb->pitches[0] != old_fb->pitches[0])
crtc_state->mode_changed = true;
+ if (ALIGN(fb->width, 8) * fb->format->cpp[0] >
+ fb->pitches[0] + fb->offsets[0]) {
+ dev_warn(dev, "pitch is not big enough for 8 pixels alignment");
+ return -EINVAL;
+ }
+
switch (fb->format->format) {
case DRM_FORMAT_YUV420:
case DRM_FORMAT_YVU420:
@@ -590,7 +601,7 @@ static void ipu_pla
Re: [PATCH] drm/prime: Only call dma_map_sgtable() for devices with DMA support
Den 22.02.2021 08.54, skrev Thomas Zimmermann:
> Hi
>
> Am 20.02.21 um 14:02 schrieb Noralf Trønnes:
>>
>>
>> Den 19.02.2021 14.40, skrev Thomas Zimmermann:
>>> Fixes a regression for udl and probably other USB-based drivers where
>>> joining and mirroring displays fails.
>>>
>>> Joining displays requires importing a dma_buf from another DRM driver.
>>> These devices don't support DMA and therefore have no DMA mask. Trying
>>> to map imported buffers from a DMA-able memory zone fails with an error.
>>> An example is shown below.
>>>
>>> [ 60.050199] [ cut here ]
>>> [ 60.055092] WARNING: CPU: 0 PID: 1403 at kernel/dma/mapping.c:190
>>> dma_map_sg_attrs+0x8f/0xc0
>>> [ 60.064331] Modules linked in: af_packet(E) rfkill(E) dmi_sysfs(E)
>>> intel_rapl_msr(E) intel_rapl_common(E) snd_hda_codec_realtek(E)
>>> snd_hda_codec_generic(E) ledtrig_audio(E) snd_hda_codec_hdmi(E)
>>> x86_pkg_temp_thermal(E) intel_powerclam)
>>> [ 60.064801] wmi(E) video(E) btrfs(E) blake2b_generic(E)
>>> libcrc32c(E) crc32c_intel(E) xor(E) raid6_pq(E) sg(E) dm_multipath(E)
>>> dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) msr(E)
>>> efivarfs(E)
>>> [ 60.170778] CPU: 0 PID: 1403 Comm: Xorg.bin Tainted: G
>>> E 5.11.0-rc5-1-default+ #747
>>> [ 60.179841] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS
>>> A24 10/24/2018
>>> [ 60.187145] RIP: 0010:dma_map_sg_attrs+0x8f/0xc0
>>> [ 60.191822] Code: 4d 85 ff 75 2b 49 89 d8 44 89 e1 44 89 f2 4c 89
>>> ee 48 89 ef e8 62 30 00 00 85 c0 78 36 5b 5d 41 5c 41 5d 41 5e 41 5f
>>> c3 0f 0b <0f> 0b 31 c0 eb ed 49 8d 7f 50 e8 72 f5 2a 00 49 8b 47 50
>>> 49 89 d8
>>> [ 60.210770] RSP: 0018:c90001d6fc18 EFLAGS: 00010246
>>> [ 60.216062] RAX: RBX: 0020 RCX:
>>> b31e677b
>>> [ 60.223274] RDX: dc00 RSI: 888212c10600 RDI:
>>> 8881b08a9488
>>> [ 60.230501] RBP: 8881b08a9030 R08: 0020 R09:
>>> 888212c10600
>>> [ 60.237710] R10: ed10425820df R11: 0001 R12:
>>>
>>> [ 60.244939] R13: 888212c10600 R14: 0008 R15:
>>>
>>> [ 60.252155] FS: 7f08ac2b2f00() GS:8887cbe0()
>>> knlGS:
>>> [ 60.260333] CS: 0010 DS: ES: CR0: 80050033
>>> [ 60.266150] CR2: 55831c899be8 CR3: 00015372e006 CR4:
>>> 001706f0
>>> [ 60.273369] Call Trace:
>>> [ 60.275845] drm_gem_map_dma_buf+0xb4/0x120
>>> [ 60.280089] dma_buf_map_attachment+0x15d/0x1e0
>>> [ 60.284688] drm_gem_prime_import_dev.part.0+0x5d/0x140
>>> [ 60.289984] drm_gem_prime_fd_to_handle+0x213/0x280
>>> [ 60.294931] ? drm_prime_destroy_file_private+0x30/0x30
>>> [ 60.300224] drm_ioctl_kernel+0x131/0x180
>>> [ 60.304291] ? drm_setversion+0x230/0x230
>>> [ 60.308366] ? drm_prime_destroy_file_private+0x30/0x30
>>> [ 60.313659] drm_ioctl+0x2f1/0x500
>>> [ 60.317118] ? drm_version+0x150/0x150
>>> [ 60.320903] ? lock_downgrade+0xa0/0xa0
>>> [ 60.324806] ? do_vfs_ioctl+0x5f4/0x680
>>> [ 60.328694] ? __fget_files+0x13e/0x210
>>> [ 60.332591] ? ioctl_fiemap.isra.0+0x1a0/0x1a0
>>> [ 60.337102] ? __fget_files+0x15d/0x210
>>> [ 60.340990] __x64_sys_ioctl+0xb9/0xf0
>>> [ 60.344795] do_syscall_64+0x33/0x80
>>> [ 60.348427] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>
>> I'm working on a USB display driver and got the same splat (although
>> from i915_gem_map_dma_buf) and silenced it using:
>>
>> ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64));
>>
>> But I understand now that this is not the solution.
>>
>> Since the USB host controller can do DMA, would the following be an
>> acceptable solution?
>
> Not all controllers can do DMA AFAIK, so it's maybe not reliable. I'll
> send out another patch to address the issue later today.
>
I looked at your other attempt at fixing this and the discussion about
how much work it is to fix this properly.
For my use case I think I just won't support import on a USB controller
without DMA:
if (!usb->bus->controller->dma_mask)
return -ENOSYS;
A USB controller without DMA must be rare and I'll deal with that later
should the need arise.
Thanks for bringing this issue to my attention.
Noralf.
> Best regards
> Thomas
>
>>
>> static struct drm_gem_object *gud_gem_prime_import(struct drm_device
>> *drm, struct dma_buf *dma_buf)
>> {
>> struct usb_device *usb = gud_to_usb_device(to_gud_device(drm));
>>
>> drm_dbg_prime(drm, "usb->bus->controller=%s\n",
>> dev_name(usb->bus->controller));
>>
>> return drm_gem_prime_import_dev(drm, dma_buf, usb->bus->controller);
>> }
>>
>> static const struct drm_driver gud_drm_driver = {
>> .gem_prime_import = gud_gem_prime_import,
>> };
>>
>>
>> Noralf.
>>
>>> [ 60.353542] RIP: 0033:0x7f08ac7b53cb
>>> [ 60.357168] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c
>>> ff ff ff 85 c0 78 ba 4c 89 e0 5b 5d
Re: [Freedreno] [PATCH v2 2/2] drm/msm/dp: add supported max link rate specified from dtsi
On 2021-02-22 08:55, Sean Paul wrote: On Mon, Feb 22, 2021 at 11:31 AM wrote: On 2021-02-19 14:46, Stephen Boyd wrote: > Quoting khs...@codeaurora.org (2021-02-19 08:39:38) >> On 2021-02-18 15:02, Stephen Boyd wrote: >> > Quoting Kuogee Hsieh (2021-02-18 12:55:04) >> >> Allow supported link rate to be limited to the value specified at >> >> dtsi. If it is not specified, then link rate is derived from dpcd >> >> directly. Below are examples, >> >> link-rate = <162000> for max link rate limited at 1.62G >> >> link-rate = <27> for max link rate limited at 2.7G >> >> link-rate = <54> for max link rate limited at 5.4G >> >> link-rate = <81> for max link rate limited at 8.1G >> >> >> >> Changes in V2: >> >> -- allow supported max link rate specified from dtsi >> > >> > Please don't roll this into the patch that removes the limit. The >> > previous version of this patch was fine. The part that lowers the limit >> > back down should be another patch. >> > >> > We rejected link-rate in DT before and we should reject it upstream >> > again. As far as I can tell, the maximum link rate should be determined >> > based on the panel or the type-c port on the board. The dp controller >> > can always achieve HBR3, so limiting it at the dp controller is >> > incorrect. The driver should query the endpoints to figure out if they >> > want to limit the link rate. Is that done automatically sometimes by >> > intercepting the DPCD? >> >> ok, i will roll back to original patch and add the second patch for >> max >> link rate limited purpose. >> panel dpcd specified max link rate it supported. >> At driver, link rate is derived from dpcd directly since driver will >> try >> to use the maximum supported link rate and less lane to save power. >> Therefore it is not possible that limit link rate base on dpcd. >> AS i understand we are going to do max link rate limitation is due to >> old redriver chip can not support HBR3. >> How can I acquire which type-c port on the board so that I can trigger >> max link rate limitation? >> >> > > The driver already seems to support lowering the link rate during link > training. Can't we try to train at the highest rate and then downgrade > the link speed until it trains properly? I sort of fail to see why we > need to introduce a bunch of complexity around limiting the link rate > on > certain boards if the driver can figure out that link training doesn't > work at HBR3 so it should try to train at HBR2 instead. yes, dp driver did support down grade link rate during link training procedure. But link training is kind of setting up agreement between host and panel with assumption that there are no other limitations in between. The problem we are discussing here is the limitation of usb re driver link rate support. Since we do not know how usb re driver behavior, I am not sure link training will work appropriately for this case. It may end up link status keep toggling up and down. IMO we should just fail link training if the redriver doesn't support a link count/rate and fallback to the next count/rate. This should be handled the same as if there were a cable incapable of achieving a link rate. Adding the link rate to the device tree (at least on the dp block) seems suspicious. If you really wanted to model the redriver's limitations in software, you'd probably want to introduce a bridge driver/connector which rejects modes that cannot be achieved by the redriver. This should prevent the dp driver from trying to train at the unsupported rates. Sean I am not familiar with drm arch that well. Can you elaborate more how bridge can work in this case? When dp driver received plug-in interrupt, it read panel capability dpcd and start link training with link rate specified at dpcd. How bridge can propagate link rate (limited by redriver) before link training happen? Both link-lane and link-rate specified at dtsi are for the limitation of Trogdor hardware platform. Both link-lane and link-rate specified at dtsi are NOT for panel since panel have specified its capability at its DPCD. ___ Freedreno mailing list freedr...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: atyfb: add stubs for aty_{ld,st}_lcd()
On Sun, Feb 21, 2021 at 07:28:53PM -0800, Randy Dunlap wrote:
> Fix build errors when these functions are not defined.
>
> ../drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_power_mgmt':
> ../drivers/video/fbdev/aty/atyfb_base.c:2002:7: error: implicit declaration
> of function 'aty_ld_lcd'; did you mean 'aty_ld_8'?
> [-Werror=implicit-function-declaration]
> 2002 | pm = aty_ld_lcd(POWER_MANAGEMENT, par);
> ../drivers/video/fbdev/aty/atyfb_base.c:2004:2: error: implicit declaration
> of function 'aty_st_lcd'; did you mean 'aty_st_8'?
> [-Werror=implicit-function-declaration]
> 2004 | aty_st_lcd(POWER_MANAGEMENT, pm, par);
> Signed-off-by: Randy Dunlap
> Reported-by: kernel test robot
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jani Nikula
> ---
> drivers/video/fbdev/aty/atyfb_base.c |9 +
> 1 file changed, 9 insertions(+)
>
> --- linux-next-20210219.orig/drivers/video/fbdev/aty/atyfb_base.c
> +++ linux-next-20210219/drivers/video/fbdev/aty/atyfb_base.c
> @@ -175,6 +175,15 @@ u32 aty_ld_lcd(int index, const struct a
> return aty_ld_le32(LCD_DATA, par);
> }
> }
> +#else /* defined(CONFIG_PMAC_BACKLIGHT) || defined(CONFIG_FB_ATY_BACKLIGHT) \
> + defined(CONFIG_FB_ATY_GENERIC_LCD) */
A better fix would seem to be to include these functions if
CONFIG_PPC_PMAC is enabled. Otherwise the PM code will surely
not work correctly. Though I'm not sure if that PPC PM
code makes any sense w/o LCD/backlight support anyway.
> +void aty_st_lcd(int index, u32 val, const struct atyfb_par *par)
> +{ }
> +
> +u32 aty_ld_lcd(int index, const struct atyfb_par *par)
> +{
> + return 0;
> +}
> #endif /* defined(CONFIG_PMAC_BACKLIGHT) || defined
> (CONFIG_FB_ATY_GENERIC_LCD) */
>
> #ifdef CONFIG_FB_ATY_GENERIC_LCD
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: stream's id should reduced after stream destruct
On 2021-02-20 1:30 a.m., ZhiJie.Zhang wrote: Signed-off-by: ZhiJie.Zhang --- drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c index c103f858375d..dc7b7e57a86c 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c @@ -137,6 +137,8 @@ static void dc_stream_destruct(struct dc_stream_state *stream) dc_transfer_func_release(stream->out_transfer_func); stream->out_transfer_func = NULL; } + + stream->ctx->dc_stream_id_count--; This is supposed to be a unique identifier so we shouldn't be reusing any old ID when creating a new stream. Regards, Nicholas Kazlauskas } void dc_stream_retain(struct dc_stream_state *stream) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/panel: Add inx Himax8279d MIPI-DSI LCD panel driver
Add STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel
Signed-off-by: Zhengqiao Xia
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-innolux-himax8279d.c | 520 ++
3 files changed, 530 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-innolux-himax8279d.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4894913936e9..288d9268cead 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -132,6 +132,15 @@ config DRM_PANEL_ILITEK_ILI9881C
Say Y if you want to enable support for panels based on the
Ilitek ILI9881c controller.
+config DRM_PANEL_INNOLUX_HIMAX8279D
+ tristate "INX 2081101qfh032011-53g 1200x1920 video panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to support for inx 2081101qfh032011-53g
+ 1200x1920 video panel.
+
config DRM_PANEL_INNOLUX_P079ZCA
tristate "Innolux P079ZCA panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index cae4d976c069..06be76db0a5b 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) +=
panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
+obj-$(CONFIG_DRM_PANEL_INNOLUX_HIMAX8279D) += panel-innolux-himax8279d.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
diff --git a/drivers/gpu/drm/panel/panel-innolux-himax8279d.c
b/drivers/gpu/drm/panel/panel-innolux-himax8279d.c
new file mode 100644
index ..4420303ec709
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-innolux-himax8279d.c
@@ -0,0 +1,520 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021, Huaqin Telecom Technology Co., Ltd
+ * Author: Zhengqiao Xia
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int bpc;
+
+ /**
+* @width_mm: width of the panel's active display area
+* @height_mm: height of the panel's active display area
+*/
+ struct {
+ unsigned int width_mm;
+ unsigned int height_mm;
+ } size;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ const struct panel_init_cmd *init_cmds;
+ unsigned int lanes;
+ bool discharge_on_disable;
+};
+
+struct inx_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *dsi;
+
+ const struct panel_desc *desc;
+
+ enum drm_panel_orientation orientation;
+ struct regulator *pp1800;
+ struct regulator *avee;
+ struct regulator *avdd;
+ struct gpio_desc *enable_gpio;
+
+ bool prepared;
+};
+
+enum dsi_cmd_type {
+ INIT_DCS_CMD,
+ DELAY_CMD,
+};
+
+struct panel_init_cmd {
+ enum dsi_cmd_type type;
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_DCS_CMD(...) { \
+ .type = INIT_DCS_CMD, \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+#define _INIT_DELAY_CMD(...) { \
+ .type = DELAY_CMD,\
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const struct panel_init_cmd starry_qfh032011_53g_init_cmd[] = {
+ _INIT_DCS_CMD(0xB0, 0x05),
+ _INIT_DCS_CMD(0xC0, 0x04),
+ _INIT_DCS_CMD(0xC2, 0x03),
+ _INIT_DCS_CMD(0xD9, 0x04),
+ _INIT_DCS_CMD(0xDB, 0x03),
+ _INIT_DCS_CMD(0xB0, 0x01),
+ _INIT_DCS_CMD(0xC3, 0x4F),
+ _INIT_DCS_CMD(0xC4, 0x40),
+ _INIT_DCS_CMD(0xC5, 0x40),
+ _INIT_DCS_CMD(0xC6, 0x40),
+ _INIT_DCS_CMD(0xC7, 0x40),
+ _INIT_DCS_CMD(0xC8, 0x4D),
+ _INIT_DCS_CMD(0xC9, 0x52),
+ _INIT_DCS_CMD(0xCA, 0x51),
+ _INIT_DCS_CMD(0xCD, 0x5D),
+ _INIT_DCS_CMD(0xCE, 0x5B),
+ _INIT_DCS_CMD(0xCF, 0x4B),
+ _INIT_DCS_CMD(0xD0, 0x49),
+ _INIT_DCS_CMD(0xD1, 0x47),
+ _INIT_DCS_CMD(0xD2, 0x45),
+ _INIT_DCS_CMD(0xD3, 0x41),
+ _INIT_DCS_CMD(0xD7, 0x50),
+ _INIT_DCS_CMD(0xD8, 0x40),
+ _INIT_DCS_CMD(0xD9, 0x40),
+ _INIT_DCS_CMD(0xDA, 0x40),
+ _INIT_DCS_CMD(0xDB, 0x40),
+ _INIT_DCS_CMD(0xDC, 0x4E),
+ _INIT_DCS_CMD(0xDD, 0x52),
+ _INIT_DCS_CMD(0xDE, 0x51),
+ _INIT_DCS_CMD(0xE1, 0x5E),
+ _INIT_DCS_CMD(0xE2, 0x5C),
+ _INIT_D
Re: [git pull] drm for 5.12-rc1
On Sun, Feb 21, 2021 at 6:45 PM Nathan Chancellor wrote:
>
> On Sun, Feb 21, 2021 at 03:07:17PM -0800, Linus Torvalds wrote:
> > On Thu, Feb 18, 2021 at 10:06 PM Dave Airlie wrote:
> > >
> > > Let me know if there are any issues,
> >
> > gcc was happy, and I obviously already pushed out my merge, but then
> > when I did my clang build afterwards, it reports:
> >
> > drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:764:2: warning:
> > variable 'structure_size' is used uninitialized whenever switch
> > default is taken [-Wsometimes-uninitialized]
> > default:
> > ^~~
> > drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:770:23: note:
> > uninitialized use occurs here
> > memset(header, 0xFF, structure_size);
> >^~
> >
> > and clang is very very right. That "default" case is completely
> > broken, and will generate a randomly sized memset. Not good.
> >
> > Presumably that default case never happens, but if so it shouldn't exist.
> >
> > Perhaps better yet, make the "default" case just do a "return" instead
> > of a break. Breaking out of the switch statement to code that cannot
> > possibly work is all kinds of mindless.
> >
> > Kevin/Alex? This was introduced by commit de4b7cd8cb87
> > ("drm/amd/pm/swsmu: unify the init soft gpu metrics function")
> >
> > Linus
>
> I sent https://lore.kernel.org/r/20210218224849.5591-1-nat...@kernel.org/
> a few days ago and Kevin reviewed it, just seems like Alex needs to pick
> it up.
Yeah, sorry, I meant to include it, but it slipped through the cracks
last week. Will include it in my -fixes PR this week.
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] doc: use KCFLAGS instead of EXTRA_CFLAGS to pass flags from command line
Masahiro Yamada writes:
> You should use KCFLAGS to pass additional compiler flags from the
> command line. Using EXTRA_CFLAGS is wrong.
>
> EXTRA_CFLAGS is supposed to specify flags applied only to the current
> Makefile (and now deprecated in favor of ccflags-y).
>
> It is still used in arch/mips/kvm/Makefile (and possibly in external
> modules too). Passing EXTRA_CFLAGS from the command line overwrites
> it and breaks the build.
>
> I also fixed drivers/gpu/drm/tilcdc/Makefile because commit 816175dd1fd7
> ("drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in
> EXTRA_CFLAGS") was based on the same misunderstanding.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Documentation/process/4.Coding.rst| 2 +-
> Documentation/process/submit-checklist.rst| 2 +-
> Documentation/translations/it_IT/process/4.Coding.rst | 2 +-
> Documentation/translations/it_IT/process/submit-checklist.rst | 2 +-
> Documentation/translations/zh_CN/process/4.Coding.rst | 2 +-
> drivers/gpu/drm/tilcdc/Makefile | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
I've applied this, fixing the conflict with submit-checklist.rst in the
process.
Thanks,
jon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
2021 X.Org Board of Directors Elections Nomination period is NOW
We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2021 election are now open and will remain open until Sunday, the 7th of March. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2020 were Eric Anholt, Mark Filion, Keith Packard, and Harry Wentland. They will continue to serve until their term ends in 2022. Current directors whose term expires in 2021 are Samuel Iglesias Gonsálvez, Manasi D Navare, Lyude Paul, and Daniel Vetter. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the member's account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations must be received before the end of day on Sunday, the 7th of March. Membership applications or renewals and completed personal statements must be received no later than the end of day on Thursday, the 11tth of March. The slate of candidates will be published on Monday, the 15th of March and candidate Q&A will begin then. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Cheers, Harry Wentland, on behalf of the X.Org elections committee ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/pm/swsmu: Avoid using structure_size uninitialized in smu_cmn_init_soft_gpu_metrics
Applied. Thanks!
Alex
On Thu, Feb 18, 2021 at 6:12 PM Wang, Kevin(Yang) wrote:
>
> thanks,
>
> Reviewed-by: Kevin Wang
>
> Regards,
> Kevin
>
> > 在 2021年2月19日，06:49，Nathan Chancellor 写道：
> >
> > Clang warns:
> >
> > drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:764:2: warning:
> > variable 'structure_size' is used uninitialized whenever switch default
> > is taken [-Wsometimes-uninitialized]
> >default:
> >^~~
> > drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:770:23: note:
> > uninitialized use occurs here
> >memset(header, 0xFF, structure_size);
> > ^~
> > drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:753:25: note:
> > initialize the variable 'structure_size' to silence this warning
> >uint16_t structure_size;
> > ^
> >= 0
> > 1 warning generated.
> >
> > Return in the default case, as the size of the header will not be known.
> >
> > Fixes: de4b7cd8cb87 ("drm/amd/pm/swsmu: unify the init soft gpu metrics
> > function")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1304
> > Signed-off-by: Nathan Chancellor
> > ---
> > drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> > b/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> > index bb620fdd4cd2..bcedd4d92e35 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> > @@ -762,7 +762,7 @@ void smu_cmn_init_soft_gpu_metrics(void *table, uint8_t
> > frev, uint8_t crev)
> >structure_size = sizeof(struct gpu_metrics_v2_0);
> >break;
> >default:
> > -break;
> > +return;
> >}
> >
> > #undef METRICS_VERSION
> > --
> > 2.30.1
> >
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu/swsmu/navi1x: Remove unnecessary conversion to bool
Applied. Thanks! Alex On Sun, Feb 21, 2021 at 10:15 PM Quan, Evan wrote: > > [AMD Official Use Only - Internal Distribution Only] > > Reviewed-by: Evan Quan > > -Original Message- > From: amd-gfx On Behalf Of Jiapeng > Chong > Sent: Saturday, February 20, 2021 10:55 AM > To: Deucher, Alexander > Cc: Jiapeng Chong ; airl...@linux.ie; > linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; > amd-...@lists.freedesktop.org; dan...@ffwll.ch; Koenig, Christian > > Subject: [PATCH v2] drm/amdgpu/swsmu/navi1x: Remove unnecessary conversion to > bool > > Fix the following coccicheck warnings: > > ./drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c:900:47-52: WARNING: > conversion to bool not needed here. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong > --- > drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c > b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c > index cd7efa9..58028a7 100644 > --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c > @@ -897,7 +897,7 @@ static bool navi10_is_support_fine_grained_dpm(struct > smu_context *smu, enum smu > dpm_desc = &pptable->DpmDescriptor[clk_index]; > > /* 0 - Fine grained DPM, 1 - Discrete DPM */ > - return dpm_desc->SnapToDiscrete == 0 ? true : false; > + return dpm_desc->SnapToDiscrete == 0; > } > > static inline bool navi10_od_feature_is_supported(struct > smu_11_0_overdrive_table *od_table, enum SMU_11_0_ODFEATURE_CAP cap) > -- > 1.8.3.1 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cevan.quan%40amd.com%7C443a5df938954827326108d8d6582201%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495021310885387%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6ETadiVbRBgbXfEbkXbxTX%2F1Ozg1wp3Nr9lHGF3SKHk%3D&reserved=0 > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display/dc/core/dc_link_ddc: Remove unnecessary conversion to bool
Applied. Thanks! Alex On Sat, Feb 20, 2021 at 2:16 AM Jiapeng Chong wrote: > > Fix the following coccicheck warnings: > > ./drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c:544:34-39: WARNING: > conversion to bool not needed here. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong > --- > drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c > b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c > index c5936e0..45a59cf 100644 > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c > @@ -541,7 +541,7 @@ bool dal_ddc_service_query_ddc_data( > /* should not set mot (middle of transaction) to 0 > * if there are pending read payloads > */ > - payload.mot = read_size == 0 ? false : true; > + payload.mot = !(read_size == 0); > payload.length = write_size; > payload.data = write_buf; > > -- > 1.8.3.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/sdma5.2: Remove unnecessary conversion to bool
Applied. Thanks! Alex On Sat, Feb 20, 2021 at 3:35 AM Jiapeng Chong wrote: > > Fix the following coccicheck warnings: > > ./drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:1621:40-45: WARNING: conversion > to bool not needed here. > > ./drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:1619:40-45: WARNING: conversion > to bool not needed here. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong > --- > drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c > b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c > index f1ba36a..9ed79a9 100644 > --- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c > +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c > @@ -1616,9 +1616,9 @@ static int sdma_v5_2_set_clockgating_state(void *handle, > case CHIP_VANGOGH: > case CHIP_DIMGREY_CAVEFISH: > sdma_v5_2_update_medium_grain_clock_gating(adev, > - state == AMD_CG_STATE_GATE ? true : false); > + state == AMD_CG_STATE_GATE); > sdma_v5_2_update_medium_grain_light_sleep(adev, > - state == AMD_CG_STATE_GATE ? true : false); > + state == AMD_CG_STATE_GATE); > break; > default: > break; > -- > 1.8.3.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/6] drm/sprd: add Unisoc's drm kms master
On Mon, Feb 22, 2021 at 9:28 PM Kevin Tang wrote:
>
> Adds drm support for the Unisoc's display subsystem.
>
> This is drm kms driver, this driver provides support for the
> application framework in Android, Yocto and more.
>
> Application framework can access Unisoc's display internel
> peripherals through libdrm or libkms, it's test ok by modetest
> (DRM/KMS test tool) and Android HWComposer.
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
>
> v4:
> - Move the devm_drm_dev_alloc to master_ops->bind function.
> - The managed drmm_mode_config_init() it is no longer necessary for drivers
> to explicitly call drm_mode_config_cleanup, so delete it.
> ---
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile| 1 +
> drivers/gpu/drm/sprd/Kconfig| 12 ++
> drivers/gpu/drm/sprd/Makefile | 5 +
> drivers/gpu/drm/sprd/sprd_drm.c | 217
> drivers/gpu/drm/sprd/sprd_drm.h | 16 +++
> 6 files changed, 253 insertions(+)
> create mode 100644 drivers/gpu/drm/sprd/Kconfig
> create mode 100644 drivers/gpu/drm/sprd/Makefile
> create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
> create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 8bf103de1..9d6ce2867 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -382,6 +382,8 @@ source "drivers/gpu/drm/tidss/Kconfig"
>
> source "drivers/gpu/drm/xlnx/Kconfig"
>
> +source "drivers/gpu/drm/sprd/Kconfig"
> +
> # Keep legacy drivers last
>
> menuconfig DRM_LEGACY
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 02c229392..42d211d9c 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -126,3 +126,4 @@ obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
> obj-$(CONFIG_DRM_MCDE) += mcde/
> obj-$(CONFIG_DRM_TIDSS) += tidss/
> obj-y += xlnx/
> +obj-$(CONFIG_DRM_SPRD) += sprd/
> diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> new file mode 100644
> index 0..6e80cc9f3
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/Kconfig
> @@ -0,0 +1,12 @@
> +config DRM_SPRD
> + tristate "DRM Support for Unisoc SoCs Platform"
> + depends on ARCH_SPRD || COMPILE_TEST
> + depends on DRM && OF
> + select DRM_KMS_HELPER
> + select DRM_GEM_CMA_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_MIPI_DSI
> + help
> + Choose this option if you have a Unisoc chipset.
> + If M is selected the module will be called sprd_drm.
> +
> diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
> new file mode 100644
> index 0..86d95d93a
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +subdir-ccflags-y += -I$(srctree)/$(src)
> +
> +obj-y := sprd_drm.o
> diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
> new file mode 100644
> index 0..a1d3ed655
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/sprd_drm.c
> @@ -0,0 +1,217 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Unisoc Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "sprd_drm.h"
> +
> +#define DRIVER_NAME"sprd"
> +#define DRIVER_DESC"Spreadtrum SoCs' DRM Driver"
Prefer to s/Spreadtrum/Unisoc.
Spreadtrum was acquired by Unisoc and never existed any more.
But "sprd" as a vendor prefix is kept for historical reasons.
-Orson
> +#define DRIVER_DATE"20200201"
> +#define DRIVER_MAJOR 1
> +#define DRIVER_MINOR 0
> +
> +static const struct drm_mode_config_helper_funcs sprd_drm_mode_config_helper
> = {
> + .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> +};
> +
> +static const struct drm_mode_config_funcs sprd_drm_mode_config_funcs = {
> + .fb_create = drm_gem_fb_create,
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +static void sprd_drm_mode_config_init(struct drm_device *drm)
> +{
> + drm->mode_config.min_width = 0;
> + drm->mode_config.min_height = 0;
> + drm->mode_config.max_width = 8192;
> + drm->mode_config.max_height = 8192;
> + drm->mode_config.allow_fb_modifiers = true;
> +
> + drm->mode_config.funcs = &sprd_drm_mode_config_funcs;
> + drm->mode_config.helper_private = &sprd_drm_mode_config_helper;
> +}
> +
> +DEFINE_DRM_GEM_CMA_FOPS(sprd_drm_fops);
> +
> +static struct drm_driver sprd_drm_drv = {
> + .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> + .fops = &sprd_drm_fops,
> +
> + /* GEM Operations */
> + DRM_GEM_CMA_DRIVER_OPS,
> +
> + .name = DRIVER_NAME,
> +
[PATCH] drivers: gpu: drm: bridge: fix kconfig dependency on DRM_KMS_HELPER
When DRM_TOSHIBA_TC358762 is enabled and DRM_KMS_HELPER is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && DRM_KMS_HELPER [=n] Selected by [y]: - DRM_TOSHIBA_TC358762 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && OF [=y] This is because DRM_TOSHIBA_TC358762 selects DRM_PANEL_BRIDGE, without depending on or selecting DRM_KMS_HELPER, despite that config option depending on DRM_KMS_HELPER. Signed-off-by: Julian Braha --- drivers/gpu/drm/bridge/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index e4110d6ca7b3..909d0a5643c2 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -183,6 +183,7 @@ config DRM_TOSHIBA_TC358762 tristate "TC358762 DSI/DPI bridge" depends on OF select DRM_MIPI_DSI + select DRM_KMS_HELPER select DRM_PANEL_BRIDGE help Toshiba TC358762 DSI/DPI bridge driver. -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1 1/6] rtc: m41t80: add support for protected clock
On 22/02/2021 18:12:42+0100, Sebastian Reichel wrote: > Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The > modules SQW clock output defaults to 32768 Hz. This behaviour is > used to provide the i.MX6 CKIL clock. Once the RTC driver is probed, > the clock is disabled and all i.MX6 functionality depending on > the 32 KHz clock has undefined behaviour. On systems using hardware > watchdog it seems to likely trigger a lot earlier than configured. > > The proper solution would be to describe this dependency in DT, > but that will result in a deadlock. The kernel will see, that > i.MX6 system clock needs the RTC clock and do probe deferral. > But the i.MX6 I2C module never becomes usable without the i.MX6 > CKIL clock and thus the RTC's clock will not be probed. So from > the kernel's perspective this is a chicken-and-egg problem. > Reading the previous paragraph, I was going to suggest describing the dependency and wondering whether this would cause a circular dependency. I guess this will keep being an issue for clocks on an I2C or SPI bus... > Technically everything is fine by not touching anything, since > the RTC clock correctly enables the clock on reset (i.e. on > battery backup power loss) and also the bootloader enables it > in case a kernel without this support has been booted. > > The 'protected-clocks' property is already in use for some clocks > that may not be touched because of firmware limitations and is > described in Documentation/devicetree/bindings/clock/clock-bindings.txt. > > Signed-off-by: Sebastian Reichel Acked-by: Alexandre Belloni > --- > Documentation/devicetree/bindings/rtc/rtc-m41t80.txt | 1 + > drivers/rtc/rtc-m41t80.c | 3 +++ > 2 files changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt > b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt > index c746cb221210..ea4bbf5c4282 100644 > --- a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt > +++ b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt > @@ -19,6 +19,7 @@ Optional properties: > - interrupts: rtc alarm interrupt. > - clock-output-names: From common clock binding to override the default > output >clock name > +- protected-clocks: Bool, if set operating system should not handle clock. > - wakeup-source: Enables wake up of host system on alarm > > Example: > diff --git a/drivers/rtc/rtc-m41t80.c b/drivers/rtc/rtc-m41t80.c > index 160dcf68e64e..3296583853a8 100644 > --- a/drivers/rtc/rtc-m41t80.c > +++ b/drivers/rtc/rtc-m41t80.c > @@ -546,6 +546,9 @@ static struct clk *m41t80_sqw_register_clk(struct > m41t80_data *m41t80) > struct clk_init_data init; > int ret; > > + if (of_property_read_bool(node, "protected-clocks")) > + return 0; > + > /* First disable the clock */ > ret = i2c_smbus_read_byte_data(client, M41T80_REG_ALARM_MON); > if (ret < 0) > -- > 2.30.0 > -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1 1/6] rtc: m41t80: add support for protected clock
On 22/02/2021 22:20:47+0100, Alexandre Belloni wrote: > On 22/02/2021 18:12:42+0100, Sebastian Reichel wrote: > > Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The > > modules SQW clock output defaults to 32768 Hz. This behaviour is > > used to provide the i.MX6 CKIL clock. Once the RTC driver is probed, > > the clock is disabled and all i.MX6 functionality depending on > > the 32 KHz clock has undefined behaviour. On systems using hardware > > watchdog it seems to likely trigger a lot earlier than configured. > > > > The proper solution would be to describe this dependency in DT, > > but that will result in a deadlock. The kernel will see, that > > i.MX6 system clock needs the RTC clock and do probe deferral. > > But the i.MX6 I2C module never becomes usable without the i.MX6 > > CKIL clock and thus the RTC's clock will not be probed. So from > > the kernel's perspective this is a chicken-and-egg problem. > > > > Reading the previous paragraph, I was going to suggest describing the > dependency and wondering whether this would cause a circular dependency. > I guess this will keep being an issue for clocks on an I2C or SPI bus... > > > Technically everything is fine by not touching anything, since > > the RTC clock correctly enables the clock on reset (i.e. on > > battery backup power loss) and also the bootloader enables it > > in case a kernel without this support has been booted. > > > > The 'protected-clocks' property is already in use for some clocks > > that may not be touched because of firmware limitations and is > > described in Documentation/devicetree/bindings/clock/clock-bindings.txt. > > > > Signed-off-by: Sebastian Reichel > Acked-by: Alexandre Belloni Or maybe you expected me to apply the patch, how are the following patches dependent on this one? -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu/display: initialize the variable 'i'
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9804:38:
>> warning: variable 'i' is uninitialized when used here
>> [-Wuninitialized]
timing = &edid->detailed_timings[i];
^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9714:7:
note: initialize the variable 'i' to silence this warning
int i;
^
= 0
1 warning generated.
Initialize the variable 'i'.
Reported-by: kernel test robot
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a22a53d..e96d3d9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9717,7 +9717,7 @@ static bool parse_hdmi_amd_vsdb(struct
amdgpu_dm_connector *aconnector,
void amdgpu_dm_update_freesync_caps(struct drm_connector *connector,
struct edid *edid)
{
- int i;
+ int i = 0;
struct detailed_timing *timing;
struct detailed_non_pixel *data;
struct detailed_data_monitor_range *range;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/display: initialize the variable 'i'
On Monday, February 22nd, 2021 at 8:25 PM, Souptick Joarder
wrote:
> >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9804:38:
> >> warning: variable 'i' is uninitialized when used here
> >> [-Wuninitialized]
>timing = &edid->detailed_timings[i];
> ^
>drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9714:7:
> note: initialize the variable 'i' to silence this warning
>int i;
> ^
> = 0
>1 warning generated.
>
> Initialize the variable 'i'.
Hm, I see this variable already initialized in the loop:
for (i = 0; i < 4; i++) {
This is the branch agd5f/drm-next.
> Reported-by: kernel test robot
> Signed-off-by: Souptick Joarder
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a22a53d..e96d3d9 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -9717,7 +9717,7 @@ static bool parse_hdmi_amd_vsdb(struct
> amdgpu_dm_connector *aconnector,
> void amdgpu_dm_update_freesync_caps(struct drm_connector *connector,
> struct edid *edid)
> {
> - int i;
> + int i = 0;
> struct detailed_timing *timing;
> struct detailed_non_pixel *data;
> struct detailed_data_monitor_range *range;
> --
> 1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/display: initialize the variable 'i'
On Mon, Feb 22, 2021 at 11:05:17PM +, Simon Ser wrote:
> On Monday, February 22nd, 2021 at 8:25 PM, Souptick Joarder
> wrote:
>
> > >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9804:38:
> > >> warning: variable 'i' is uninitialized when used here
> > >> [-Wuninitialized]
> >timing = &edid->detailed_timings[i];
> > ^
> >drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9714:7:
> > note: initialize the variable 'i' to silence this warning
> >int i;
> > ^
> > = 0
> >1 warning generated.
> >
> > Initialize the variable 'i'.
>
> Hm, I see this variable already initialized in the loop:
>
> for (i = 0; i < 4; i++) {
>
> This is the branch agd5f/drm-next.
That is in the
if (amdgpu_dm_connector->dc_sink->sink_signal ==
SIGNAL_TYPE_DISPLAY_PORT
|| amdgpu_dm_connector->dc_sink->sink_signal ==
SIGNAL_TYPE_EDP) {
branch not the
} else if (edid && amdgpu_dm_connector->dc_sink->sink_signal ==
SIGNAL_TYPE_HDMI_TYPE_A) {
branch, where i is indeed used uninitialized like clang complains about.
I am not at all familiar with the code so I cannot say if this fix is
the proper one but it is definitely a legitimate issue.
Cheers,
Nathan
> > Reported-by: kernel test robot
> > Signed-off-by: Souptick Joarder
> > ---
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index a22a53d..e96d3d9 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -9717,7 +9717,7 @@ static bool parse_hdmi_amd_vsdb(struct
> > amdgpu_dm_connector *aconnector,
> > void amdgpu_dm_update_freesync_caps(struct drm_connector *connector,
> > struct edid *edid)
> > {
> > - int i;
> > + int i = 0;
> > struct detailed_timing *timing;
> > struct detailed_non_pixel *data;
> > struct detailed_data_monitor_range *range;
> > --
> > 1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/display: initialize the variable 'i'
On Tuesday, February 23rd, 2021 at 12:44 AM, Nathan Chancellor
wrote:
> On Mon, Feb 22, 2021 at 11:05:17PM +, Simon Ser wrote:
> > On Monday, February 22nd, 2021 at 8:25 PM, Souptick Joarder
> > wrote:
> >
> > > >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9804:38:
> > > >> warning: variable 'i' is uninitialized when used here
> > > >> [-Wuninitialized]
> > >timing = &edid->detailed_timings[i];
> > > ^
> > >drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9714:7:
> > > note: initialize the variable 'i' to silence this warning
> > >int i;
> > > ^
> > > = 0
> > >1 warning generated.
> > >
> > > Initialize the variable 'i'.
> >
> > Hm, I see this variable already initialized in the loop:
> >
> > for (i = 0; i < 4; i++) {
> >
> > This is the branch agd5f/drm-next.
>
> That is in the
>
> if (amdgpu_dm_connector->dc_sink->sink_signal ==
> SIGNAL_TYPE_DISPLAY_PORT
> || amdgpu_dm_connector->dc_sink->sink_signal ==
> SIGNAL_TYPE_EDP) {
>
> branch not the
>
> } else if (edid && amdgpu_dm_connector->dc_sink->sink_signal ==
> SIGNAL_TYPE_HDMI_TYPE_A) {
>
> branch, where i is indeed used uninitialized like clang complains about.
>
> I am not at all familiar with the code so I cannot say if this fix is
> the proper one but it is definitely a legitimate issue.
I think you have an outdated branch. In my checkout, i is not used in the first
branch, and is initialized in the second one.
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c?h=drm-next#n9700
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/display: initialize the variable 'i'
On Mon, Feb 22, 2021 at 11:50:06PM +, Simon Ser wrote:
> On Tuesday, February 23rd, 2021 at 12:44 AM, Nathan Chancellor
> wrote:
>
> > On Mon, Feb 22, 2021 at 11:05:17PM +, Simon Ser wrote:
> > > On Monday, February 22nd, 2021 at 8:25 PM, Souptick Joarder
> > > wrote:
> > >
> > > > >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9804:38:
> > > > >> warning: variable 'i' is uninitialized when used here
> > > > >> [-Wuninitialized]
> > > >timing = &edid->detailed_timings[i];
> > > > ^
> > > >drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9714:7:
> > > > note: initialize the variable 'i' to silence this warning
> > > >int i;
> > > > ^
> > > > = 0
> > > >1 warning generated.
> > > >
> > > > Initialize the variable 'i'.
> > >
> > > Hm, I see this variable already initialized in the loop:
> > >
> > > for (i = 0; i < 4; i++) {
> > >
> > > This is the branch agd5f/drm-next.
> >
> > That is in the
> >
> > if (amdgpu_dm_connector->dc_sink->sink_signal ==
> > SIGNAL_TYPE_DISPLAY_PORT
> > || amdgpu_dm_connector->dc_sink->sink_signal ==
> > SIGNAL_TYPE_EDP) {
> >
> > branch not the
> >
> > } else if (edid && amdgpu_dm_connector->dc_sink->sink_signal ==
> > SIGNAL_TYPE_HDMI_TYPE_A) {
> >
> > branch, where i is indeed used uninitialized like clang complains about.
> >
> > I am not at all familiar with the code so I cannot say if this fix is
> > the proper one but it is definitely a legitimate issue.
>
> I think you have an outdated branch. In my checkout, i is not used in the
> first
> branch, and is initialized in the second one.
>
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c?h=drm-next#n9700
That branch is the outdated one:
https://git.kernel.org/linus/a897913a819191550ab2fa2784d3c3ada3a096d3
Please see:
https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L9854
It was introduced by commit f9b4f20c4777 ("drm/amd/display: Add Freesync
HDMI support to DM").
Cheers,
Nathan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1 5/6] dt-bindings: mtd: jedec,spi-nor: add sst25vf032b
On Mon, Feb 22, 2021 at 11:13 AM Sebastian Reichel wrote: > > The binding is already used by the driver. Update documentation > accordingly. > > Signed-off-by: Sebastian Reichel > --- > Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 1 + > 1 file changed, 1 insertion(+) This is now DT schema format. Landed in Linus' tree today. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/display: initialize the variable 'i'
I think Alex moved to gitlab for his branches
On Tue, Feb 23, 2021, 12:50 AM Simon Ser wrote:
> On Tuesday, February 23rd, 2021 at 12:44 AM, Nathan Chancellor <
> nat...@kernel.org> wrote:
>
> > On Mon, Feb 22, 2021 at 11:05:17PM +, Simon Ser wrote:
> > > On Monday, February 22nd, 2021 at 8:25 PM, Souptick Joarder <
> jrdr.li...@gmail.com> wrote:
> > >
> > > > >>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9804:38:
> > > > >> warning: variable 'i' is uninitialized when used here
> > > > >> [-Wuninitialized]
> > > >timing = &edid->detailed_timings[i];
> > > > ^
> > > >
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9714:7:
> > > > note: initialize the variable 'i' to silence this warning
> > > >int i;
> > > > ^
> > > > = 0
> > > >1 warning generated.
> > > >
> > > > Initialize the variable 'i'.
> > >
> > > Hm, I see this variable already initialized in the loop:
> > >
> > > for (i = 0; i < 4; i++) {
> > >
> > > This is the branch agd5f/drm-next.
> >
> > That is in the
> >
> > if (amdgpu_dm_connector->dc_sink->sink_signal ==
> SIGNAL_TYPE_DISPLAY_PORT
> > || amdgpu_dm_connector->dc_sink->sink_signal ==
> SIGNAL_TYPE_EDP) {
> >
> > branch not the
> >
> > } else if (edid && amdgpu_dm_connector->dc_sink->sink_signal ==
> SIGNAL_TYPE_HDMI_TYPE_A) {
> >
> > branch, where i is indeed used uninitialized like clang complains about.
> >
> > I am not at all familiar with the code so I cannot say if this fix is
> > the proper one but it is definitely a legitimate issue.
>
> I think you have an outdated branch. In my checkout, i is not used in the
> first
> branch, and is initialized in the second one.
>
>
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c?h=drm-next#n9700
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v1 5/6] xen-swiotlb: convert variables to arrays
On Fri, 19 Feb 2021, Konrad Rzeszutek Wilk wrote:
> On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
> > On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
> > > So one thing that has been on my mind for a while: I'd really like
> > > to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb
> > > to swiotlb the main difference seems to be:
> > >
> > > - additional reasons to bounce I/O vs the plain DMA capable
> > > - the possibility to do a hypercall on arm/arm64
> > > - an extra translation layer before doing the phys_to_dma and vice
> > >versa
> > > - an special memory allocator
> > >
> > > I wonder if inbetween a few jump labels or other no overhead enablement
> > > options and possibly better use of the dma_range_map we could kill
> > > off most of swiotlb-xen instead of maintaining all this code duplication?
> >
> > So I looked at this a bit more.
> >
> > For x86 with XENFEAT_auto_translated_physmap (how common is that?)
>
> Juergen, Boris please correct me if I am wrong, but that
> XENFEAT_auto_translated_physmap
> only works for PVH guests?
ARM is always XENFEAT_auto_translated_physmap
> > pfn_to_gfn is a nop, so plain phys_to_dma/dma_to_phys do work as-is.
> >
> > xen_arch_need_swiotlb always returns true for x86, and
> > range_straddles_page_boundary should never be true for the
> > XENFEAT_auto_translated_physmap case.
>
> Correct. The kernel should have no clue of what the real MFNs are
> for PFNs.
On ARM, Linux knows the MFNs because for local pages MFN == PFN and for
foreign pages it keeps track in arch/arm/xen/p2m.c. More on this below.
xen_arch_need_swiotlb only returns true on ARM in rare situations where
bouncing on swiotlb buffers is required. Today it only happens on old
versions of Xen that don't support the cache flushing hypercall but
there could be more cases in the future.
> >
> > So as far as I can tell the mapping fast path for the
> > XENFEAT_auto_translated_physmap can be trivially reused from swiotlb.
> >
> > That leaves us with the next more complicated case, x86 or fully cache
> > coherent arm{,64} without XENFEAT_auto_translated_physmap. In that case
> > we need to patch in a phys_to_dma/dma_to_phys that performs the MFN
> > lookup, which could be done using alternatives or jump labels.
> > I think if that is done right we should also be able to let that cover
> > the foreign pages in is_xen_swiotlb_buffer/is_swiotlb_buffer, but
> > in that worst case that would need another alternative / jump label.
> >
> > For non-coherent arm{,64} we'd also need to use alternatives or jump
> > labels to for the cache maintainance ops, but that isn't a hard problem
> > either.
With the caveat that ARM is always XENFEAT_auto_translated_physmap, what
you wrote looks correct. I am writing down a brief explanation on how
swiotlb-xen is used on ARM.
pfn: address as seen by the guest, pseudo-physical address in ARM terminology
mfn (or bfn): real address, physical address in ARM terminology
On ARM dom0 is auto_translated (so Xen sets up the stage2 translation
in the MMU) and the translation is 1:1. So pfn == mfn for Dom0.
However, when another domain shares a page with Dom0, that page is not
1:1. Swiotlb-xen is used to retrieve the mfn for the foreign page at
xen_swiotlb_map_page. It does that with xen_phys_to_bus -> pfn_to_bfn.
It is implemented with a rbtree in arch/arm/xen/p2m.c.
In addition, swiotlb-xen is also used to cache-flush the page via
hypercall at xen_swiotlb_unmap_page. That is done because dev_addr is
really the mfn at unmap_page and we don't know the pfn for it. We can do
pfn-to-mfn but we cannot do mfn-to-pfn (there are good reasons for it
unfortunately). The only way to cache-flush by mfn is by issuing a
hypercall. The hypercall is implemented in arch/arm/xen/mm.c.
The pfn != bfn and pfn_valid() checks are used to detect if the page is
local (of dom0) or foreign; they work thanks to the fact that Dom0 is
1:1 mapped.
Getting back to what you wrote, yes if we had a way to do MFN lookups in
phys_to_dma, and a way to call the hypercall at unmap_page if the page
is foreign (e.g. if it fails a pfn_valid check) then I think we would be
good from an ARM perspective. The only exception is when
xen_arch_need_swiotlb returns true, in which case we need to actually
bounce on swiotlb buffers.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1 1/6] rtc: m41t80: add support for protected clock
Hi, On Mon, Feb 22, 2021 at 10:26:26PM +0100, Alexandre Belloni wrote: > On 22/02/2021 22:20:47+0100, Alexandre Belloni wrote: > > On 22/02/2021 18:12:42+0100, Sebastian Reichel wrote: > > > Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The > > > modules SQW clock output defaults to 32768 Hz. This behaviour is > > > used to provide the i.MX6 CKIL clock. Once the RTC driver is probed, > > > the clock is disabled and all i.MX6 functionality depending on > > > the 32 KHz clock has undefined behaviour. On systems using hardware > > > watchdog it seems to likely trigger a lot earlier than configured. > > > > > > The proper solution would be to describe this dependency in DT, > > > but that will result in a deadlock. The kernel will see, that > > > i.MX6 system clock needs the RTC clock and do probe deferral. > > > But the i.MX6 I2C module never becomes usable without the i.MX6 > > > CKIL clock and thus the RTC's clock will not be probed. So from > > > the kernel's perspective this is a chicken-and-egg problem. > > > > > > > Reading the previous paragraph, I was going to suggest describing the > > dependency and wondering whether this would cause a circular dependency. > > I guess this will keep being an issue for clocks on an I2C or SPI bus... Yes, it is a circular dependency on this particular system on module. It only works because the RTC enables the clock by default. The i.MX6 CKIL is expected to be always enabled. > > > Technically everything is fine by not touching anything, since > > > the RTC clock correctly enables the clock on reset (i.e. on > > > battery backup power loss) and also the bootloader enables it > > > in case a kernel without this support has been booted. > > > > > > The 'protected-clocks' property is already in use for some clocks > > > that may not be touched because of firmware limitations and is > > > described in Documentation/devicetree/bindings/clock/clock-bindings.txt. > > > > > > Signed-off-by: Sebastian Reichel > > Acked-by: Alexandre Belloni > > Or maybe you expected me to apply the patch, how are the following > patches dependent on this one? The last patch, which introduces a new board has a runtime dependency on this patch. Without this feature the board goes into a reboot loop because its bootloader enables the i.MX6 watchdog and without the CKIL its timing is messed up. But it's a pure runtime dependency for a new board, so it should be fine to merge this via your tree. It basically means the board is only working once your tree and arm tree have been merged, which seems ok from my POV. -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1 5/6] dt-bindings: mtd: jedec,spi-nor: add sst25vf032b
Hi, On Mon, Feb 22, 2021 at 06:15:11PM -0600, Rob Herring wrote: > On Mon, Feb 22, 2021 at 11:13 AM Sebastian Reichel > wrote: > > > > The binding is already used by the driver. Update documentation > > accordingly. > > > > Signed-off-by: Sebastian Reichel > > --- > > Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 1 + > > 1 file changed, 1 insertion(+) > > This is now DT schema format. Landed in Linus' tree today. Indeed and it already contains sst,sst25vf032b. This patch can be ignored. Thanks, -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window
On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter wrote:
>
> Cc all the mailing lists ... my usual script crashed and I had to
> hand-roll the email and screwed it up ofc :-/
Oh, and my reply thus also became just a reply to you personally.
So repeating it here, in case somebody has comments about that
access_process_vm() issue.
On Mon, Feb 22, 2021 at 2:23 AM Daniel Vetter wrote:
>
> I've stumbled over this for my own learning and then realized there's a
> bunch of races around VM_PFNMAP mappings vs follow pfn.
>
> If you're happy with this [..]
Happy? No. But it seems an improvement.
I did react to some of this: commit 0fb1b1ed7dd9 ("/dev/mem: Only set
filp->f_mapping") talks about _what_ it does, but not so much _why_ it
does it. It doesn't seem to actually matter, and seems almost
incidental (because you've looked at f_mapping and i_mapping just
didn't matter but was adjacent.
And generic_access_phys() remains horrific. Does anything actually use
this outside of the odd magical access_remote_vm() code?
I'm wondering if that code shouldn't just be removed entirely. It's
quite old, I'm not sure it's really relevant. See commit 28b2ee20c7cb
("access_process_vm device memory infrastructure").
I guess you do debug the X server, but still.. Do you actually ever
look at device memory through the debugger? I'd hope that you'd use an
access function and make gdb call it in the context of the debuggee?
Whatever. I've pulled it, and I'm not _unhappy_ with it, but I'd also
not call myself overly giddy and over the moon happy about this code.
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] topic/kcmp-kconfig
The pull request you sent on Mon, 22 Feb 2021 10:37:27 +0100: > git://anongit.freedesktop.org/drm/drm tags/topic/kcmp-kconfig-2021-02-22 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4b5f9254e4f4375ac845cb17f1732037dd8adeeb Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window
On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter wrote: > > Cc all the mailing lists ... my usual script crashed and I had to > hand-roll the email and screwed it up ofc :-/ Oh, and you also didn't get a pr-tracker-bot response for this for the same reason. Even your fixed email was ignored by the bot (I think because of the "Re:" in the subject line). So consider this your manual pr-tracker-bot replacement. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Remove unnecessary conversion to bool
Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/amdgpu/athub_v2_1.c:79:40-45: WARNING: conversion to bool not needed here. ./drivers/gpu/drm/amd/amdgpu/athub_v2_1.c:81:40-45: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/amdgpu/athub_v2_1.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c b/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c index 7b1b183..2ac4988 100644 --- a/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c +++ b/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c @@ -74,10 +74,8 @@ int athub_v2_1_set_clockgating(struct amdgpu_device *adev, case CHIP_SIENNA_CICHLID: case CHIP_NAVY_FLOUNDER: case CHIP_DIMGREY_CAVEFISH: - athub_v2_1_update_medium_grain_clock_gating(adev, - state == AMD_CG_STATE_GATE ? true : false); - athub_v2_1_update_medium_grain_light_sleep(adev, - state == AMD_CG_STATE_GATE ? true : false); + athub_v2_1_update_medium_grain_clock_gating(adev, state == AMD_CG_STATE_GATE); + athub_v2_1_update_medium_grain_light_sleep(adev, state == AMD_CG_STATE_GATE); break; default: break; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/2] drm/dp_mst: Revise broadcast msg lct & lcr
[AMD Public Use]
> -Original Message-
> From: Ville Syrjälä
> Sent: Tuesday, February 23, 2021 1:09 AM
> To: Lin, Wayne
> Cc: Brol, Eryk ; Zhuo, Qingqing ;
> sta...@vger.kernel.org; Zuo, Jerry
> ; dri-devel@lists.freedesktop.org; Kazlauskas, Nicholas
>
> Subject: Re: [PATCH 1/2] drm/dp_mst: Revise broadcast msg lct & lcr
>
> On Mon, Feb 22, 2021 at 07:02:03PM +0200, Ville Syrjälä wrote:
> > On Mon, Feb 22, 2021 at 12:00:26PM +0800, Wayne Lin wrote:
> > > [Why & How]
> > > According to DP spec, broadcast message LCT equals to 1 and LCR
> > > equals to 6. Current implementation is incorrect. Fix it.
> > >
> > > Signed-off-by: Wayne Lin
> > > Cc: sta...@vger.kernel.org
> > > ---
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 10 --
> > > 1 file changed, 8 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 17dbed0a9800..713ef3b42054 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -2727,8 +2727,14 @@ static int set_hdr_from_dst_qlock(struct
> > > drm_dp_sideband_msg_hdr *hdr,
> > > else
> > > hdr->broadcast = 0;
> > > hdr->path_msg = txmsg->path_msg;
> > > -hdr->lct = mstb->lct;
> > > -hdr->lcr = mstb->lct - 1;
> > > +if (hdr->broadcast) {
> > > +hdr->lct = 1;
> > > +hdr->lcr = 6;
> > > +} else {
> > > +hdr->lct = mstb->lct;
> > > +hdr->lcr = mstb->lct - 1;
> > > +}
> > > +
> > > if (mstb->lct > 1)
> > > memcpy(hdr->rad, mstb->rad, mstb->lct / 2);
> >
> > We should also do something about RAD no?
>
> Just skip the RAD stuff by s/mstb->lct/hdr->lct/ here I guess?
Thanks Ville!
Since LCT=1, broadcast message doesn't have a RAD and this is taken
care while we're constructing the header in drm_dp_encode_sideband_msg_hdr().
In drm_dp_encode_sideband_msg_hdr(), we skip stuffing RAD if LCT=1.
>
> --
> Ville Syrjälä
> Intel
Regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
