RE: [Intel-gfx] [RFC 1/1] drm/i915/dgfx: Avoid parent bridge rpm on mmap mappings
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Tuesday, August 9, 2022 8:36 PM
> To: Gupta, Anshuman
> Cc: intel-...@lists.freedesktop.org; dan...@ffwll.ch; Wilson, Chris P
> ; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [RFC 1/1] drm/i915/dgfx: Avoid parent bridge rpm on
> mmap mappings
>
> On Mon, Aug 08, 2022 at 04:05:55PM +0530, Anshuman Gupta wrote:
> > As per PCIe Spec Section 5.3,
> > When a Type 1 Function associated with a Switch/Root Port (a “virtual
> > bridge”) is in a non-D0 power state, it will emulate the behavior of a
> > conventional PCI bridge in its handling of Memory, I/O, and
> > Configuration Requests and Completions. All Memory and I/O requests
> > flowing Downstream are terminated as Unsupported Requests.
> >
> > Due to above limitations when Intel DGFX Cards graphics PCI func's
> > upstream bridge(referred as VSP) enters to D3, all mmap memory mapping
> > associated with lmem objects reads 0xff, therefore avoiding VSP
> > runtime suspend accordingly.
> >
> > This will make sure that user can read valid data from lmem, while
> > DGFX Card graphics PCI func is in D3 state.
> >
> > Signed-off-by: Anshuman Gupta
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 11
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8 ++
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 35
> > drivers/gpu/drm/i915/intel_runtime_pm.h | 2 ++
> > 4 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > index 0c5c43852e24..968bed5b56d3 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > @@ -845,6 +845,10 @@ static void vm_open(struct vm_area_struct *vma)
> > struct drm_i915_gem_object *obj = mmo->obj;
> >
> > GEM_BUG_ON(!obj);
> > +
> > + if (i915_gem_object_is_lmem(obj))
> > + intel_runtime_pm_get_vsp(to_i915(obj->base.dev));
> > +
> > i915_gem_object_get(obj);
> > }
> >
> > @@ -854,6 +858,10 @@ static void vm_close(struct vm_area_struct *vma)
> > struct drm_i915_gem_object *obj = mmo->obj;
> >
> > GEM_BUG_ON(!obj);
> > +
> > + if (i915_gem_object_is_lmem(obj))
> > + intel_runtime_pm_put_vsp(to_i915(obj->base.dev));
> > +
> > i915_gem_object_put(obj);
> > }
> >
> > @@ -972,6 +980,9 @@ int i915_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> > return PTR_ERR(anon);
> > }
> >
> > + if (i915_gem_object_is_lmem(obj))
> > + intel_runtime_pm_get_vsp(to_i915(obj->base.dev));
> > +
> > vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND |
> VM_DONTDUMP | VM_IO;
> >
> > /*
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > index 5a5cf332d8a5..bcacd95fdbc1 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > @@ -1101,6 +1101,10 @@ static void ttm_vm_open(struct vm_area_struct
> *vma)
> > i915_ttm_to_gem(vma->vm_private_data);
> >
> > GEM_BUG_ON(!obj);
> > +
> > + if (i915_gem_object_is_lmem(obj))
> > + intel_runtime_pm_get_vsp(to_i915(obj->base.dev));
> > +
> > i915_gem_object_get(obj);
> > }
> >
> > @@ -1110,6 +1114,10 @@ static void ttm_vm_close(struct vm_area_struct
> *vma)
> > i915_ttm_to_gem(vma->vm_private_data);
> >
> > GEM_BUG_ON(!obj);
> > +
> > + if (i915_gem_object_is_lmem(obj))
> > + intel_runtime_pm_put_vsp(to_i915(obj->base.dev));
> > +
> > i915_gem_object_put(obj);
> > }
>
> we need to ensure the runtime pm get / put at dma buf attach & detach as well,
> no?
>
> >
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 6ed5786bcd29..a5557918674f 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -646,3 +646,38 @@ void intel_runtime_pm_init_early(struct
> > intel_runtime_pm *rpm)
> >
> > init_intel_runtime_pm_wakeref(rpm);
> > }
> > +
> > +void intel_runtime_pm_get_vsp(struct drm_i915_private *i915) {
> > + struct pci_dev *pdev = to_pci_dev(i915->drm.dev), *vsp;
> > +
> > + if (!IS_DGFX(i915))
> > + return;
> > +
> > + vsp = pci_upstream_bridge(pdev);
> > + if (!vsp) {
> > + drm_err(>drm, "Failed to get the PCI upstream
> bridge\n");
> > + return;
> > + }
> > +
> > + pci_dbg(vsp, "get runtime usage count\n");
>
> we should always prefer the drm_dbg in our subsystem
>
> > + pm_runtime_get_sync(>dev);
>
> why? I believe that grabbing our own ref would be enough to block the
> upstream chain. I don't understand why this is such an special case that we
> don't
> see any other driver in the linux tree having to do such a thing. what am I
> missing?
Hi Rodrigo ,
I was trying to get wakeref for i915 device in i915_gem_map, vm_open, vm_close
hook.
But
Re: [RFC PATCH 02/14] drm/qaic: Add uapi and core driver file
On 16/08/2022 21:22, Jeffrey Hugo wrote:
> + if (datapath_polling) {
> + poll_datapath = true;
> + pr_info("qaic: driver initializing in datapath polling mode\n");
No pr() in normal path of init/exit.
>>>
>>> This is not the normal path. datapath_polling is a module parameter.
>>> This is something the user can enable, and so it would be good to have
>>> the user informed that the option took effect.
>>
>> No, not really. User always can check via sysfs and there is no point in
>> polluting dmesg on module load. It might be printed (if someone has such
>> modprobe setting) on every system, even without the actual device.
>
> So, I guess this is limited to platform devices?
> I see GIC, IOMMU, and PCI doing the same
> I guess, will remove.
None of regular drivers should print anything during init/exit. If one
is printing, I think a patch removing it will be accepted.
However you mention platform devices, so a "device" implies probe, not
init. This is a different case.
Best regards,
Krzysztof
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/dg2: Add additional tuning settings
On Tue, Aug 16, 2022 at 02:06:01PM -0700, Matt Roper wrote: Some additional MMIO tuning settings have appeared in the bspec's performance tuning guide section. One of the tuning settings here is also documented as formal workaround Wa_22012654132 for some steppings of DG2. However the tuning setting applies to all DG2 variants and steppings, making it a superset of the workaround. v2: - Move DRAW_WATERMARK to engine workaround section. It only moves into the engine context on future platforms. (Lucas) - CHICKEN_RASTER_2 needs to be handled as a masked register. (Lucas) Bspec: 68331 Cc: Lucas De Marchi Cc: Lionel Landwerlin Signed-off-by: Matt Roper Reviewed-by: Lucas De Marchi Lucas De Marchi
Re: [PATCH 3/3] drm: omapdrm: Do no allocate non-scanout GEMs through DMM/TILER
Hi, Ivaylo On Mon, 15 Aug 2022 at 14:23, Ivaylo Dimitrov wrote: > > Hi Liu, > > On 14.08.22 г. 17:27 ч., Yongqin Liu wrote: > > Hi, IvayIo > > > > Thanks very much for the reply! > > > > On Sat, 13 Aug 2022 at 14:58, Ivaylo Dimitrov > > wrote: > >> > >> Hi Liu, > >> > >> On 12.08.22 г. 7:35 ч., Yongqin Liu wrote: > >>> Hi, Ivaylo, Tomi > >>> > >>> We have one X15 Android AOSP master build, it could not have the home > >>> screen displayed > >>> on the hdmi monitor connected with this change, with the following > >>> message printed on the serial console > >>> [ 607.404205] omapdrm omapdrm.0: Failed to setup plane plane-0 > >>> [ 607.410522] omapdrm omapdrm.0: Failed to setup plane plane-1 > >>> [ 607.416381] omapdrm omapdrm.0: Failed to setup plane plane-2 > >>> [ 607.422088] omapdrm omapdrm.0: Failed to setup plane plane-3 > >>> > >>> # for details, please check the link here: http://ix.io/47m1 > >>> > >>> It will work with home screen displayed on the hdmi monitor if this > >>> change is reverted. > >>> > >>> Is this the broken problem you talked about here? > >>> > >>> And could you please give some suggestions on how to have the x15 > >>> Android build work with this change? > >>> > >> > >> Make sure scanout (i.e. those to be displayed) buffers are actually > >> allocated as such - OMAP_BO_SCANOUT flag must be set when calling > >> omap_bo_new(). > > > > I am not familiar with this area, I am sorry if I asked quite silly > > questions:( > > I googled omap_bo_new, and found it's a function of libdrm here[1], is > > it what you meant here? > > > > Yes, calling this function from userspace ends in kernel code the > $subject patch is part of. > > > If it's the omap_bo_new that we should pass OMAP_BO_SCANOUT when it is > > called, > > then is it the correct way to update omap_bo_new to add the OMAP_BO_SCANOUT > > flag > > before it calls omap_bo_new_impl? > > > > omap_bo_new() is fine and does not need any updates/fixes, it is the > code that uses it (whoever it is, I am not familiar with the userspace > you are using) that shall pass correct flags (third parameter) when > calling it. Sorry, I do not get the point here. Like you said, the code that calls omap_bo_new needs to pass OMAP_BO_SCANOUT, then IMO omap_bo_new should be the best place to add the OMAP_BO_SCANOUT flag, (like via flags = flags | OMAP_BO_SCANOUT), that could help avoid missing the flag by some code, and also avoids hacks/changes on the possible blob binaries. Do I misunderstand somewhere? Or is there some case that OMAP_BO_SCANOUT shouldn't be passed when omap_bo_new is called? > BTW you shall really find who and how uses OMAP BO API, in theory it > might use ioctls directly and not call omap_bo_xxx functions. Do you mean the DRM_OMAP_GEM_NEW ioctl api? There is no place in the AOSP tree to call that except the omap_bo_new_impl function, which is called by the omap_bo_new and omap_bo_new_tiled functions. The omap_bo_new should not be called with the OMAP_BO_TILED flag, while the omap_bo_new_tiled should be called with the OMAP_BO_TILED flag Regarding to the omap_bo_new function, there are 2 places call it in the AOSP tree: #1 ./external/libkmsxx/kms++/src/omap/omapframebuffer.cpp #2 ./device/ti/beagle_x15/gpu/gralloc.am57x.so #1 seems not used in AOSP yet, and #2 is one blob binary we do not have the source for. > strace > would be your friend there. or gdb, or whatever tools are used on > android. Or put some printfs() in omap_bo_new() that output the PID of > the calling process, etc. Thanks a lot for these great suggestions! Will use them when possible. > > And another question is that, since the userspace(libdrm) will be used > > to work with different kernel versions, > > like the old 4.14, 4.19, etc, do you think there will be problem to > > pass OMAP_BO_SCANOUT > > from the userspace side with the old kernels(which does not have this > > change)? > > does this change need to be backported to the old kernel versions? > > There should not be any issue. The changes could be backported if one > hits the issues this $series is fixing, but there is no need. Thanks for the confirmation! I just boot-tested with adding OMAP_BO_SCANOUT in the omap_bo_new function, and it worked with the current 4.14, 4.19, and the mainline kernels. # via adding line "flags = flags | OMAP_BO_SCANOUT" in the omap_bo_new function. > > > > And the last question is that, omap_bo_new might be called by some > > property binaries what not everyone > > could get the source to update, for such case what's your suggestions? > > > > Hard to say without knowing what that library would be. > > When I hit issues with closed blobs, sometimes I reverse-engineer them > to fix the issue, example: > > https://github.com/maemo-leste/sgx-ddk-um/tree/master/dbm > > This is REed libdbm from sgx-ddk-um 1.17.4948957, that is responsible > for allocating BOs (what omap_bo_new() does) but it uses DUMB buffers > API, instead of OMAP
Re: [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
On Wed, Aug 17, 2022 at 9:49 AM Karol Herbst wrote: > > On Wed, Aug 17, 2022 at 3:18 AM Kai-Heng Feng > wrote: > > > > On Wed, Aug 17, 2022 at 2:50 AM Karol Herbst wrote: > > > > > > On Tue, Aug 16, 2022 at 4:53 AM Kai-Heng Feng > > > wrote: > > > > > > > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to > > > > dGFX so external monitors are routed to dGFX, and more monitors can be > > > > supported as result. > > > > > > > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20 > > > > on intel_dsm_guid2. This method is described in Intel document 632107. > > > > > > > > > > Can we please not do things like this just because? > > > > I there's a very good reason to support more external monitors, > > especially when eDP is already 4K so iGPU don't have enough buffer for > > more displays. > > > > well.. they do have it. What's the limit? 3 or 4 4K displays with gen > 11th+? I find conflicting information, but 3 4K displays are no > problem. It might be if you get to higher refresh rates or something. > > I know that 2 work quite reliably and I know I can put even more on > the Intel GPU. More monitors can be supported via a thunderbolt dock. > > > > > > > It forces the discrete GPU to be on leading to higher thermal pressure > > > and power consumption of the system. Lower battery runtime or higher > > > fan noise is the result. Not everybody wants to use an AC simply just > > > because they attach an external display. > > > > The system is designed in this way. > > > > ?!? This makes no sense. If the discrete GPU is turned on, it means > the system has to cool away more heat, because it consumes more power. > It then causes louder fans. No idea how a "system design" can just go > around simple physics... The spec from HP [1] says: Multi Display Support Without HP Thunderbolt™ Dock G2 UMA Graphics: Unit supports up to 4 independent displays. Any combination of displays outputs may be used except one of Thunderbolt™ 4 and HDMI. Hybrid Graphics: Unit supports up 5 simultaneous displays (4 from dGPU + 1 from iGPU). Any combination of displays outputs may be used except when using one USBC and HDMI are exclusive With HP Thunderbolt™ Dock G2 UMA Graphics: Unit supports up to 4 simultaneous displays. Any combination of displays outputs may be used except one of Thunderbolt™ 4 and HDMI. Hybrid Graphics (NVIDIA): Unit supports up to 5 simultaneous displays (4 from dGPU + 1 from iGPU). Any combination of displays outputs may be used except when using one USBC and HDMI are exclusive Hybrid Graphics (AMD): Unit supports up to 5 simultaneous displays (5 from dGPU + 1 from iGPU). Any combination of displays outputs may be used except when using one USBC and HDMI are exclusive So it's "designed" to use dGPU on the hybrid configs. Let's hope the copper tubes have can dissipate the heat fast enough. > > Even the CPU consumes more power, because on some systems it prevents > deeper package sleeping modes due to the active PCIe bridge > controller. > > But if you have certain systems where you want to enable this behavior > despite the drawbacks, maybe maintain a list of systems where to apply > this method? The behavior will be enabled only when _DSM function 20 is present. So it's already a selected few. > > > And many (if not all) gaming laptops and mobile workstations use > > discrete GPU for external monitors. > > We just recently found out we have to use a switch to make it work. > > > > yeah some do, and if people buy those, they already deal with loud > fans and just accept this fact. > > Others might want silent fans... and why do you have to switch? Out of > the box Intel GPUs support 3 4K displays. I want to see the general > use case for 4 4K displays. It's not for us to decide. When a user buys a laptop according to the spec, the expectation is to have those supported. > > So what systems are actually affected and do users have the option to > disable it, if they prefer a more silent system? Maybe adding a new i915 option to override the default behavior? But it depends on i915 maintainers' opinion. > > > > > > > If the problem is "we run out of displays" then can we have something > > > more dynamic, where we are doing this only and only if we run out of > > > resources to drive as that many displays. > > > > This is a boot-time switch, so it's not possible to switch it dynamically. > > > > This makes it even worse. > > > > > > > Most users will be fine with ports being driven by the iGPU. Why hurt > > > most users, because of some weird special case with mostly only > > > drawbacks? > > > > This is a use case that hardware vendor never bother to test. > > And this is not a special case - the system is designed to use dGPU > > for external monitors. > > > > Kai-Heng > > > > so instead of hard wiring, they added a software switch to do the same thing? I think it's a TGL-H thing, to provide a way so discrete GPU can use the generic TCSS. I don't
Re: [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
On Wed, Aug 17, 2022 at 3:18 AM Kai-Heng Feng wrote: > > On Wed, Aug 17, 2022 at 2:50 AM Karol Herbst wrote: > > > > On Tue, Aug 16, 2022 at 4:53 AM Kai-Heng Feng > > wrote: > > > > > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to > > > dGFX so external monitors are routed to dGFX, and more monitors can be > > > supported as result. > > > > > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20 > > > on intel_dsm_guid2. This method is described in Intel document 632107. > > > > > > > Can we please not do things like this just because? > > I there's a very good reason to support more external monitors, > especially when eDP is already 4K so iGPU don't have enough buffer for > more displays. > well.. they do have it. What's the limit? 3 or 4 4K displays with gen 11th+? I find conflicting information, but 3 4K displays are no problem. It might be if you get to higher refresh rates or something. I know that 2 work quite reliably and I know I can put even more on the Intel GPU. > > > > It forces the discrete GPU to be on leading to higher thermal pressure > > and power consumption of the system. Lower battery runtime or higher > > fan noise is the result. Not everybody wants to use an AC simply just > > because they attach an external display. > > The system is designed in this way. > ?!? This makes no sense. If the discrete GPU is turned on, it means the system has to cool away more heat, because it consumes more power. It then causes louder fans. No idea how a "system design" can just go around simple physics... Even the CPU consumes more power, because on some systems it prevents deeper package sleeping modes due to the active PCIe bridge controller. But if you have certain systems where you want to enable this behavior despite the drawbacks, maybe maintain a list of systems where to apply this method? > And many (if not all) gaming laptops and mobile workstations use > discrete GPU for external monitors. > We just recently found out we have to use a switch to make it work. > yeah some do, and if people buy those, they already deal with loud fans and just accept this fact. Others might want silent fans... and why do you have to switch? Out of the box Intel GPUs support 3 4K displays. I want to see the general use case for 4 4K displays. So what systems are actually affected and do users have the option to disable it, if they prefer a more silent system? > > > > If the problem is "we run out of displays" then can we have something > > more dynamic, where we are doing this only and only if we run out of > > resources to drive as that many displays. > > This is a boot-time switch, so it's not possible to switch it dynamically. > This makes it even worse. > > > > Most users will be fine with ports being driven by the iGPU. Why hurt > > most users, because of some weird special case with mostly only > > drawbacks? > > This is a use case that hardware vendor never bother to test. > And this is not a special case - the system is designed to use dGPU > for external monitors. > > Kai-Heng > so instead of hard wiring, they added a software switch to do the same thing? And then don't bother to test both possibilities? Anyway.. it doesn't make any sense and this opens up more questions than I initially had. I honestly still don't see the point here and still doubt that pleasing a handful of users is worth accepting the drawbacks. I also have no say if it comes to the i915 driver, but from a user perspective none of this makes much sense tbh. > > > > > Signed-off-by: Kai-Heng Feng > > > --- > > > drivers/gpu/drm/i915/display/intel_acpi.c | 18 +- > > > 1 file changed, 17 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c > > > b/drivers/gpu/drm/i915/display/intel_acpi.c > > > index e78430001f077..3bd5930e2769b 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_acpi.c > > > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c > > > @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid = > > > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c); > > > > > > #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */ > > > +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */ > > > > > > static const guid_t intel_dsm_guid2 = > > > GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260, > > > @@ -187,6 +188,7 @@ void intel_dsm_get_bios_data_funcs_supported(struct > > > drm_i915_private *i915) > > > struct pci_dev *pdev = to_pci_dev(i915->drm.dev); > > > acpi_handle dhandle; > > > union acpi_object *obj; > > > + int supported = 0; > > > > > > dhandle = ACPI_HANDLE(>dev); > > > if (!dhandle) > > > @@ -194,8 +196,22 @@ void intel_dsm_get_bios_data_funcs_supported(struct > > > drm_i915_private *i915) > > > > > > obj = acpi_evaluate_dsm(dhandle, _dsm_guid2, > > > INTEL_DSM_REVISION_ID, > > >
[PATCH libdrm v3 0/2] Add Writeback Support for Modetest
Add writeback support to modetest with the below options: - Passing in -c will now also show the writeback connector - Test a built-in mode on writeback connector - Test a custom mode from user input on writeback connector Usage: "./modetest -M msm -x : -a -P @:+0+0@RG24." Refer to --help for exact syntax - Dump the writeback output buffer to bitstream Usage: "./modetest -M msm -s : -a -o -P @:+0+0@RG24" This currently supports a singular writeback connector. This patch also fixes a bug for running modetest with the atomic flag. Changes made in V2: - Added helper method that checks if user pipe has writeback connector - Added error message for dump flag if no writeback connector is found - Polls on the writeback fence fd until writeback is complete Changes made in V3: - Resolved compiler warnings - Defined ETIME to ETIMEDOUT in cases where ETIME is undefined Rohith Iyer (2): tests/modetest: Allocate drmModeAtomicReq before setting properties tests/modetest: Add support for writeback connector tests/modetest/buffers.c | 19 tests/modetest/buffers.h | 1 + tests/modetest/modetest.c | 187 ++ 3 files changed, 187 insertions(+), 20 deletions(-) -- 2.35.1
Re: [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
On Wed, Aug 17, 2022 at 2:50 AM Karol Herbst wrote:
>
> On Tue, Aug 16, 2022 at 4:53 AM Kai-Heng Feng
> wrote:
> >
> > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > dGFX so external monitors are routed to dGFX, and more monitors can be
> > supported as result.
> >
> > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
> > on intel_dsm_guid2. This method is described in Intel document 632107.
> >
>
> Can we please not do things like this just because?
I there's a very good reason to support more external monitors,
especially when eDP is already 4K so iGPU don't have enough buffer for
more displays.
>
> It forces the discrete GPU to be on leading to higher thermal pressure
> and power consumption of the system. Lower battery runtime or higher
> fan noise is the result. Not everybody wants to use an AC simply just
> because they attach an external display.
The system is designed in this way.
And many (if not all) gaming laptops and mobile workstations use
discrete GPU for external monitors.
We just recently found out we have to use a switch to make it work.
>
> If the problem is "we run out of displays" then can we have something
> more dynamic, where we are doing this only and only if we run out of
> resources to drive as that many displays.
This is a boot-time switch, so it's not possible to switch it dynamically.
>
> Most users will be fine with ports being driven by the iGPU. Why hurt
> most users, because of some weird special case with mostly only
> drawbacks?
This is a use case that hardware vendor never bother to test.
And this is not a special case - the system is designed to use dGPU
for external monitors.
Kai-Heng
>
> > Signed-off-by: Kai-Heng Feng
> > ---
> > drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > index e78430001f077..3bd5930e2769b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
> > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> >
> > #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> > +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
> >
> > static const guid_t intel_dsm_guid2 =
> > GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> > @@ -187,6 +188,7 @@ void intel_dsm_get_bios_data_funcs_supported(struct
> > drm_i915_private *i915)
> > struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > acpi_handle dhandle;
> > union acpi_object *obj;
> > + int supported = 0;
> >
> > dhandle = ACPI_HANDLE(>dev);
> > if (!dhandle)
> > @@ -194,8 +196,22 @@ void intel_dsm_get_bios_data_funcs_supported(struct
> > drm_i915_private *i915)
> >
> > obj = acpi_evaluate_dsm(dhandle, _dsm_guid2,
> > INTEL_DSM_REVISION_ID,
> > INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED,
> > NULL);
> > - if (obj)
> > + if (obj) {
> > + if (obj->type == ACPI_TYPE_INTEGER)
> > + supported = obj->integer.value;
> > +
> > ACPI_FREE(obj);
> > + }
> > +
> > + /* Tiger Lake H DP-IN Boot Time Switching from iGfx to dGfx */
> > + if (supported & BIT(20)) {
> > + obj = acpi_evaluate_dsm(dhandle, _dsm_guid2,
> > + INTEL_DSM_REVISION_ID,
> > + INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
> > + NULL);
> > + if (obj)
> > + ACPI_FREE(obj);
> > + }
> > }
> >
> > /*
> > --
> > 2.36.1
> >
>
Re: [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
On Wed, Aug 17, 2022 at 2:36 AM Lyude Paul wrote:
>
> On Tue, 2022-08-16 at 14:24 -0400, Lyude Paul wrote:
> > On Tue, 2022-08-16 at 19:29 +0800, Kai-Heng Feng wrote:
> > > On Tue, Aug 16, 2022 at 4:06 PM Jani Nikula
> > > wrote:
> > > >
> > > > On Tue, 16 Aug 2022, Kai-Heng Feng wrote:
> > > > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch
> > > > > to
> > > > > dGFX so external monitors are routed to dGFX, and more monitors can be
> > > > > supported as result.
> > > > >
> > > > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function
> > > > > 20
> > > > > on intel_dsm_guid2. This method is described in Intel document 632107.
> >
> > Is this documentation released anywhere? We've been wondering about these
> > interfaces for quite a long time, and it would be good to know if there's
> > docs
> > for this we haven't really been seeing.
> >
> > > >
> > > > Is this the policy decision that we want to unconditionally make,
> > > > though?
> > >
> > > I believes so, so more external monitors can be supported at the same
> > > time.
> > >
> > > Kai-Heng
> >
> > Is this for systems with dual Intel GPUs? I ask because if this affects
> > Intel/Nvidia hybrid systems then this is a huge no from me. Nouveau is able
> > to
> > support these systems, but at a limited capacity. This would imply that we
> > are
> > making external displays work for users of the nvidia proprietary driver, at
> > the expense making external display support for mainline kernel users
> > substantially worse for people who are using the mainline kernel. Which
> > isn't
> > a choice we should be making, because nvidia's OOT driver is not a mainline
> > kernel driver.
>
> Doing some quick research, unless the models mentioned in the commit message
> are unreleased some of them are definitely Intel/Nvidia hybrids. So I'm going
> to say:
>
> NAK-by: Lyude Paul
>
> If you'd like to resubmit this for systems with amdgpus and Intel only, that's
> perfectly fine with me if the Intel folks are ok with it. But please hold off
> on this for Nvidia systems, at least until we've got GSP reworks functional in
> nouveau. If nvidia's interested in making this work for their driver, they're
> welcome to do the work there. For reference: the main limitations you would
> hit as a result of this patch would be lagginess on the external displays as a
> result of us not being able to reclock the GPU, which means PCIe bandwidth
> will be pretty limited.
The change should be agnostic to any discrete GPU, so I don't think
it's easy to make i915 be aware of the presence of AMD or NVIDIA.
As I replied in previous mail, the external displays may not even work
on Intel GPU, so I really hope we can get this merged.
Will the 'GSP rework' finish anytime soon?
Kai-Heng
>
> >
> > If this is just for Intel/Intel systems though that's probably fine, and it
> > might also be fine for AMD systems.
> >
> > >
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > > >
> > > > > Signed-off-by: Kai-Heng Feng
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
> > > > > 1 file changed, 17 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > > index e78430001f077..3bd5930e2769b 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > > @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
> > > > > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> > > > >
> > > > > #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> > > > > +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
> > > > >
> > > > > static const guid_t intel_dsm_guid2 =
> > > > > GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> > > > > @@ -187,6 +188,7 @@ void
> > > > > intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> > > > > struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > > > > acpi_handle dhandle;
> > > > > union acpi_object *obj;
> > > > > + int supported = 0;
> > > > >
> > > > > dhandle = ACPI_HANDLE(>dev);
> > > > > if (!dhandle)
> > > > > @@ -194,8 +196,22 @@ void
> > > > > intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> > > > >
> > > > > obj = acpi_evaluate_dsm(dhandle, _dsm_guid2,
> > > > > INTEL_DSM_REVISION_ID,
> > > > >
> > > > > INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, NULL);
> > > > > - if (obj)
> > > > > + if (obj) {
> > > > > + if (obj->type == ACPI_TYPE_INTEGER)
> > > > > + supported = obj->integer.value;
> > > > > +
> > > > > ACPI_FREE(obj);
> > > > > + }
> > > > > +
> > > > > + /* Tiger Lake H DP-IN Boot Time Switching from iGfx to dGfx */
> > > > > + if (supported & BIT(20)) {
> > > > > +
Re: [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
On Wed, Aug 17, 2022 at 2:24 AM Lyude Paul wrote:
>
> On Tue, 2022-08-16 at 19:29 +0800, Kai-Heng Feng wrote:
> > On Tue, Aug 16, 2022 at 4:06 PM Jani Nikula
> > wrote:
> > >
> > > On Tue, 16 Aug 2022, Kai-Heng Feng wrote:
> > > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > > > dGFX so external monitors are routed to dGFX, and more monitors can be
> > > > supported as result.
> > > >
> > > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
> > > > on intel_dsm_guid2. This method is described in Intel document 632107.
>
> Is this documentation released anywhere? We've been wondering about these
> interfaces for quite a long time, and it would be good to know if there's docs
> for this we haven't really been seeing.
>
> > >
> > > Is this the policy decision that we want to unconditionally make,
> > > though?
> >
> > I believes so, so more external monitors can be supported at the same time.
> >
> > Kai-Heng
>
> Is this for systems with dual Intel GPUs? I ask because if this affects
> Intel/Nvidia hybrid systems then this is a huge no from me. Nouveau is able to
> support these systems, but at a limited capacity. This would imply that we are
> making external displays work for users of the nvidia proprietary driver, at
> the expense making external display support for mainline kernel users
> substantially worse for people who are using the mainline kernel. Which isn't
> a choice we should be making, because nvidia's OOT driver is not a mainline
> kernel driver.
Yes it's for Intel/NVIDIA hybrid systems.
The problem is that hardware vendor design the systems to use NVIDIA
for external displays, so using external displays on Intel are never
tested by the vendors.
I don't think that's any good either.
Kai-Heng
>
> If this is just for Intel/Intel systems though that's probably fine, and it
> might also be fine for AMD systems.
>
> >
> > >
> > > BR,
> > > Jani.
> > >
> > > >
> > > > Signed-off-by: Kai-Heng Feng
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
> > > > 1 file changed, 17 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > index e78430001f077..3bd5930e2769b 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
> > > > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> > > >
> > > > #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> > > > +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
> > > >
> > > > static const guid_t intel_dsm_guid2 =
> > > > GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> > > > @@ -187,6 +188,7 @@ void intel_dsm_get_bios_data_funcs_supported(struct
> > > > drm_i915_private *i915)
> > > > struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > > > acpi_handle dhandle;
> > > > union acpi_object *obj;
> > > > + int supported = 0;
> > > >
> > > > dhandle = ACPI_HANDLE(>dev);
> > > > if (!dhandle)
> > > > @@ -194,8 +196,22 @@ void
> > > > intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> > > >
> > > > obj = acpi_evaluate_dsm(dhandle, _dsm_guid2,
> > > > INTEL_DSM_REVISION_ID,
> > > >
> > > > INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, NULL);
> > > > - if (obj)
> > > > + if (obj) {
> > > > + if (obj->type == ACPI_TYPE_INTEGER)
> > > > + supported = obj->integer.value;
> > > > +
> > > > ACPI_FREE(obj);
> > > > + }
> > > > +
> > > > + /* Tiger Lake H DP-IN Boot Time Switching from iGfx to dGfx */
> > > > + if (supported & BIT(20)) {
> > > > + obj = acpi_evaluate_dsm(dhandle, _dsm_guid2,
> > > > + INTEL_DSM_REVISION_ID,
> > > > + INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
> > > > + NULL);
> > > > + if (obj)
> > > > + ACPI_FREE(obj);
> > > > + }
> > > > }
> > > >
> > > > /*
> > >
> > > --
> > > Jani Nikula, Intel Open Source Graphics Center
> >
>
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
Re: build failure of next-20220811 due to b1a63a0b48ad ("drm/amd/display: consider DSC pass-through during mode validation")
Hi all,
On Fri, 12 Aug 2022 09:07:31 +1000 Stephen Rothwell wrote:
>
> On Thu, 11 Aug 2022 18:10:48 +0100 "Sudip Mukherjee (Codethink)"
> wrote:
> >
> > Not sure if it has been reported, builds of riscv, alpha, s390, arm,
> > arm64, xtensa, mips, csky allmodconfig have failed to build next-20220811
> > with the error:
> >
> > ERROR: modpost: "dc_dsc_compute_bandwidth_range"
> > [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> > ERROR: modpost: "dc_dsc_get_policy_for_timing"
> > [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> >
> > git bisect pointed to b1a63a0b48ad ("drm/amd/display: consider DSC
> > pass-through during mode validation")
> > And, reverting that commit has fixed the build failure.
> >
> > I will be happy to test any patch or provide any extra log if needed.
>
> I have reverted that commit in today's linux-next.
I have removed that revert. Sudip, can you recheck when linux-next is
released, please?
--
Cheers,
Stephen Rothwell
pgpTBWs2dCjlI.pgp
Description: OpenPGP digital signature
Re: [PATCH] drm/i915/guc: skip scrub_ctbs selftest if reset is disabled
On 7/8/2022 15:41, Daniele Ceraolo Spurio wrote: The test needs GT reset to trigger the scrubbing logic, so we can only run it when reset is enabled. Signed-off-by: Daniele Ceraolo Spurio Cc: John Harrison Cc: Matthew Brost Reviewed-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c index 1df71d0796ae..5bd804f29b32 100644 --- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c +++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c @@ -54,6 +54,9 @@ static int intel_guc_scrub_ctbs(void *arg) struct intel_engine_cs *engine; struct intel_context *ce; + if (!intel_has_gpu_reset(gt)) + return 0; + wakeref = intel_runtime_pm_get(gt->uncore->rpm); engine = intel_selftest_find_any_engine(gt);
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
On Tue, Aug 16, 2022 at 4:45 AM Dmitry Osipenko
wrote:
>
> On 8/12/22 18:01, Rob Clark wrote:
> > On Fri, Aug 12, 2022 at 7:57 AM Rob Clark wrote:
> >>
> >> On Fri, Aug 12, 2022 at 4:26 AM Dmitry Osipenko
> >> wrote:
> >>>
> >>> On 8/11/22 02:19, Rob Clark wrote:
> On Wed, Aug 10, 2022 at 3:23 PM Dmitry Osipenko
> wrote:
> >
> > On 8/11/22 01:03, Rob Clark wrote:
> >> On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko
> >> wrote:
> >>>
> >>> On 8/10/22 18:08, Rob Clark wrote:
> On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter
> wrote:
> >
> > On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote:
> >> On 7/6/22 00:48, Rob Clark wrote:
> >>> On Tue, Jul 5, 2022 at 4:51 AM Christian König
> >>> wrote:
>
> Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
> > Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers
> > don't
> > handle imported dma-bufs properly, which results in mapping of
> > something
> > else than the imported dma-buf. On NVIDIA Tegra we get a hard
> > lockup when
> > userspace writes to the memory mapping of a dma-buf that was
> > imported into
> > Tegra's DRM GEM.
> >
> > Majority of DRM drivers prohibit mapping of the imported GEM
> > objects.
> > Mapping of imported GEMs require special care from userspace
> > since it
> > should sync dma-buf because mapping coherency of the exporter
> > device may
> > not match the DRM device. Let's prohibit the mapping for all
> > DRM drivers
> > for consistency.
> >
> > Suggested-by: Thomas Hellström
> >
> > Signed-off-by: Dmitry Osipenko
>
> I'm pretty sure that this is the right approach, but it's
> certainly more
> than possible that somebody abused this already.
> >>>
> >>> I suspect that this is abused if you run deqp cts on android..
> >>> ie. all
> >>> winsys buffers are dma-buf imports from gralloc. And then when
> >>> you
> >>> hit readpix...
> >>>
> >>> You might only hit this in scenarios with separate gpu and
> >>> display (or
> >>> dGPU+iGPU) because self-imports are handled differently in
> >>> drm_gem_prime_import_dev().. and maybe not in cases where you end
> >>> up
> >>> with a blit from tiled/compressed to linear.. maybe that narrows
> >>> the
> >>> scope enough to just fix it in userspace?
> >>
> >> Given that that only drivers which use DRM-SHMEM potentially
> >> could've
> >> map imported dma-bufs (Panfrost, Lima) and they already don't
> >> allow to
> >> do that, I think we're good.
> >
> > So can I have an ack from Rob here or are there still questions
> > that this
> > might go boom?
> >
> > Dmitry, since you have a bunch of patches merged now I think would
> > also be
> > good to get commit rights so you can drive this more yourself. I've
> > asked
> > Daniel Stone to help you out with getting that.
>
> I *think* we'd be ok with this on msm, mostly just by dumb luck.
> Because the dma-buf's we import will be self-import. I'm less sure
> about panfrost (src/panfrost/lib/pan_bo.c doesn't seem to have a
> special path for imported dma-bufs either, and in that case they
> won't
> be self-imports.. but I guess no one has tried to run android cts on
> panfrost).
> >>>
> >>> The last time I tried to mmap dma-buf imported to Panfrost didn't work
> >>> because Panfrost didn't implement something needed for that. I'll need
> >>> to take a look again because can't recall what it was.
> >>> Upd: I re-checked Panfrost using today's linux-next and mapping of
> >>> imported dma-buf works, I mapped imported buf from video decoder.
> >>> Apparently previously I had some local kernel change that broke the
> >>> mapping.
> >>>
> What about something less drastic to start, like (apologies for
> hand-edited patch):
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 86d670c71286..fc9ec42fa0ab 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object
> *obj, unsigned long obj_size,
> {
> int ret;
>
> + WARN_ON_ONCE(obj->import_attach);
> >>>
> >>> This will hang NVIDIA Tegra, which is what
Re: [PATCH] drm/amdgpu: Fix use-after-free on amdgpu_bo_list mutex
Applied. Thanks!
Alex
On Mon, Aug 15, 2022 at 10:56 AM Melissa Wen wrote:
>
> On 08/15, Maíra Canal wrote:
> > If amdgpu_cs_vm_handling returns r != 0, then it will unlock the
> > bo_list_mutex inside the function amdgpu_cs_vm_handling and again on
> > amdgpu_cs_parser_fini. This problem results in the following
> > use-after-free problem:
> >
> > [ 220.280990] [ cut here ]
> > [ 220.281000] refcount_t: underflow; use-after-free.
> > [ 220.281019] WARNING: CPU: 1 PID: 3746 at lib/refcount.c:28
> > refcount_warn_saturate+0xba/0x110
> > [ 220.281029] [ cut here ]
> > [ 220.281415] CPU: 1 PID: 3746 Comm: chrome:cs0 Tainted: G W L --- ---
> > 5.20.0-0.rc0.20220812git7ebfc85e2cd7.10.fc38.x86_64 #1
> > [ 220.281421] Hardware name: System manufacturer System Product Name/ROG
> > STRIX X570-I GAMING, BIOS 4403 04/27/2022
> > [ 220.281426] RIP: 0010:refcount_warn_saturate+0xba/0x110
> > [ 220.281431] Code: 01 01 e8 79 4a 6f 00 0f 0b e9 42 47 a5 00 80 3d de
> > 7e be 01 00 75 85 48 c7 c7 f8 98 8e 98 c6 05 ce 7e be 01 01 e8 56 4a
> > 6f 00 <0f> 0b e9 1f 47 a5 00 80 3d b9 7e be 01 00 0f 85 5e ff ff ff 48
> > c7
> > [ 220.281437] RSP: 0018:b4b0d18d7a80 EFLAGS: 00010282
> > [ 220.281443] RAX: 0026 RBX: 0003 RCX:
> >
> > [ 220.281448] RDX: 0001 RSI: 988d06dc RDI:
> >
> > [ 220.281452] RBP: R08: R09:
> > b4b0d18d7930
> > [ 220.281457] R10: 0003 R11: a0672e2fffe8 R12:
> > a058ca360400
> > [ 220.281461] R13: a05846c50a18 R14: fe00 R15:
> > 0003
> > [ 220.281465] FS: 7f82683e06c0() GS:a066e2e0()
> > knlGS:
> > [ 220.281470] CS: 0010 DS: ES: CR0: 80050033
> > [ 220.281475] CR2: 3590005cc000 CR3: 0001fca46000 CR4:
> > 00350ee0
> > [ 220.281480] Call Trace:
> > [ 220.281485]
> > [ 220.281490] amdgpu_cs_ioctl+0x4e2/0x2070 [amdgpu]
> > [ 220.281806] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
> > [ 220.282028] drm_ioctl_kernel+0xa4/0x150
> > [ 220.282043] drm_ioctl+0x21f/0x420
> > [ 220.282053] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
> > [ 220.282275] ? lock_release+0x14f/0x460
> > [ 220.282282] ? _raw_spin_unlock_irqrestore+0x30/0x60
> > [ 220.282290] ? _raw_spin_unlock_irqrestore+0x30/0x60
> > [ 220.282297] ? lockdep_hardirqs_on+0x7d/0x100
> > [ 220.282305] ? _raw_spin_unlock_irqrestore+0x40/0x60
> > [ 220.282317] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu]
> > [ 220.282534] __x64_sys_ioctl+0x90/0xd0
> > [ 220.282545] do_syscall_64+0x5b/0x80
> > [ 220.282551] ? futex_wake+0x6c/0x150
> > [ 220.282568] ? lock_is_held_type+0xe8/0x140
> > [ 220.282580] ? do_syscall_64+0x67/0x80
> > [ 220.282585] ? lockdep_hardirqs_on+0x7d/0x100
> > [ 220.282592] ? do_syscall_64+0x67/0x80
> > [ 220.282597] ? do_syscall_64+0x67/0x80
> > [ 220.282602] ? lockdep_hardirqs_on+0x7d/0x100
> > [ 220.282609] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > [ 220.282616] RIP: 0033:0x7f8282a4f8bf
> > [ 220.282639] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10
> > 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00
> > 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00
> > 00
> > [ 220.282644] RSP: 002b:7f82683df410 EFLAGS: 0246 ORIG_RAX:
> > 0010
> > [ 220.282651] RAX: ffda RBX: 7f82683df588 RCX:
> > 7f8282a4f8bf
> > [ 220.282655] RDX: 7f82683df4d0 RSI: c0186444 RDI:
> > 0018
> > [ 220.282659] RBP: 7f82683df4d0 R08: 7f82683df5e0 R09:
> > 7f82683df4b0
> > [ 220.282663] R10: 1d04000a0600 R11: 0246 R12:
> > c0186444
> > [ 220.282667] R13: 0018 R14: 7f82683df588 R15:
> > 0003
> > [ 220.282689]
> > [ 220.282693] irq event stamp: 6232311
> > [ 220.282697] hardirqs last enabled at (6232319): []
> > __up_console_sem+0x5e/0x70
> > [ 220.282704] hardirqs last disabled at (6232326): []
> > __up_console_sem+0x43/0x70
> > [ 220.282709] softirqs last enabled at (6232072): []
> > __irq_exit_rcu+0xf9/0x170
> > [ 220.282716] softirqs last disabled at (6232061): []
> > __irq_exit_rcu+0xf9/0x170
> > [ 220.282722] ---[ end trace ]---
> >
> > Therefore, remove the mutex_unlock from the amdgpu_cs_vm_handling
> > function, so that amdgpu_cs_submit and amdgpu_cs_parser_fini can handle
> > the unlock.
> >
> > Fixes: 90af0ca047f3 ("drm/amdgpu: Protect the amdgpu_bo_list list with a
> > mutex v2")
> > Reported-by: Mikhail Gavrilov
> > Signed-off-by: Maíra Canal
> > ---
> > Thanks Melissa and Christian for the feedback on mutex_unlock.
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 8 ++--
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > index d8f1335bc68f..b7bae833c804
[PATCH v2 2/2] drm/i915/dg2: Add additional tuning settings
Some additional MMIO tuning settings have appeared in the bspec's
performance tuning guide section.
One of the tuning settings here is also documented as formal workaround
Wa_22012654132 for some steppings of DG2. However the tuning setting
applies to all DG2 variants and steppings, making it a superset of the
workaround.
v2:
- Move DRAW_WATERMARK to engine workaround section. It only moves into
the engine context on future platforms. (Lucas)
- CHICKEN_RASTER_2 needs to be handled as a masked register. (Lucas)
Bspec: 68331
Cc: Lucas De Marchi
Cc: Lionel Landwerlin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 ++
drivers/gpu/drm/i915/gt/intel_workarounds.c | 27 ++---
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index b3b49f6d6d1c..f64fafe28f72 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -259,6 +259,9 @@
#define GEN9_PREEMPT_GPGPU_COMMAND_LEVEL GEN9_PREEMPT_GPGPU_LEVEL(1, 0)
#define GEN9_PREEMPT_GPGPU_LEVEL_MASK
GEN9_PREEMPT_GPGPU_LEVEL(1, 1)
+#define DRAW_WATERMARK _MMIO(0x26c0)
+#define VERT_WM_VAL REG_GENMASK(9, 0)
+
#define GEN12_GLOBAL_MOCS(i) _MMIO(0x4000 + (i) * 4) /*
Global MOCS regs */
#define RENDER_HWS_PGA_GEN7_MMIO(0x4080)
@@ -374,6 +377,9 @@
#define CHICKEN_RASTER_1 _MMIO(0x6204)
#define DIS_SF_ROUND_NEAREST_EVENREG_BIT(8)
+#define CHICKEN_RASTER_2 _MMIO(0x6208)
+#define TBIMR_FAST_CLIP REG_BIT(5)
+
#define VFLSKPD_MMIO(0x62a8)
#define DIS_OVER_FETCH_CACHE REG_BIT(1)
#define DIS_MULT_MISS_RD_SQUASH REG_BIT(0)
@@ -1124,6 +1130,8 @@
#define RT_CTRL_MMIO(0xe530)
#define DIS_NULL_QUERY REG_BIT(10)
+#define STACKID_CTRL REG_GENMASK(6, 5)
+#define STACKID_CTRL_512 REG_FIELD_PREP(STACKID_CTRL,
0x2)
#define EU_PERF_CNTL1 _MMIO(0xe558)
#define EU_PERF_CNTL5 _MMIO(0xe55c)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a68d279b01f0..31e129329fb0 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -568,6 +568,7 @@ static void icl_ctx_workarounds_init(struct intel_engine_cs
*engine,
static void dg2_ctx_gt_tuning_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
{
+ wa_masked_en(wal, CHICKEN_RASTER_2, TBIMR_FAST_CLIP);
wa_write_clr_set(wal, GEN11_L3SQCREG5, L3_PWM_TIMER_INIT_VAL_MASK,
REG_FIELD_PREP(L3_PWM_TIMER_INIT_VAL_MASK, 0x7f));
wa_add(wal,
@@ -2195,15 +2196,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_write_or(wal, XEHP_L3NODEARBCFG, XEHP_LNESPARE);
}
- if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_A0, STEP_C0) ||
- IS_DG2_G11(i915)) {
- /* Wa_22012654132:dg2 */
- wa_add(wal, GEN10_CACHE_MODE_SS, 0,
- _MASKED_BIT_ENABLE(ENABLE_PREFETCH_INTO_IC),
- 0 /* write-only, so skip validation */,
- true);
- }
-
/* Wa_14013202645:dg2 */
if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_C0) ||
IS_DG2_GRAPHICS_STEP(i915, G11, STEP_A0, STEP_B0))
@@ -2692,6 +2684,23 @@ add_render_compute_tuning_settings(struct
drm_i915_private *i915,
if (IS_DG2(i915)) {
wa_write_or(wal, XEHP_L3SCQREG7, BLEND_FILL_CACHING_OPT_DIS);
+ wa_write_clr_set(wal, RT_CTRL, STACKID_CTRL, STACKID_CTRL_512);
+ wa_write_clr_set(wal, DRAW_WATERMARK, VERT_WM_VAL,
+REG_FIELD_PREP(VERT_WM_VAL, 0x3FF));
+
+ /*
+* This is also listed as Wa_22012654132 for certain DG2
+* steppings, but the tuning setting programming is a superset
+* since it applies to all DG2 variants and steppings.
+*
+* Note that register 0xE420 is write-only and cannot be read
+* back for verification on DG2 (due to Wa_14012342262), so
+* we need to explicitly skip the readback.
+*/
+ wa_add(wal, GEN10_CACHE_MODE_SS, 0,
+ _MASKED_BIT_ENABLE(ENABLE_PREFETCH_INTO_IC),
+ 0 /* write-only, so skip validation */,
+ true);
}
}
--
2.37.1
GPU device resource reservations with cgroups?
Hello cgroup experts, I have a GPU device [1] that supports organizing its resources for the purposes of supporting containers. I am attempting to determine how to represent this in the upstream kernel, and I wonder if it fits in cgroups. The device itself has a number of resource types – compute cores, memory, bus replicators, semaphores, and dma channels. Any particular workload may consume some set of these resources. For example, a workload may consume two compute cores, 1GB of memory, one dma channel, but no semaphores and no bus replicators. By default all of the resources are in a global pool. This global pool is managed by the device firmware. Linux makes a request to the firmware to load a workload. The firmware reads the resource requirements from the workload itself, and then checks the global pool. If the global pool contains sufficient resources to satisfy the needs of the workload, the firmware assigns the required resources from the global pool to the workload. If there are insufficient resources, the workload request from Linux is rejected. Some users may want to share the device between multiple containers, but provide device level isolation between those containers. For example, a user may have 4 workloads to run, one per container, and each workload takes 1/4th of the set of compute cores. The user would like to reserve sets of compute cores for each container so that container X always has the expected set of resources available, and if container Y malfunctions, it cannot “steal” resources from container X. To support this, the firmware supports a concept of partitioning. A partition is a pool of resources which are removed from the global pool, and pre-assigned to the partition’s pool. A workload can then be run from within a partition, and it consumes resources from that partition’s pool instead of from the global pool. The firmware manages creating partitions and assigning resources to them. Partitions do not nest. In the above user example, the user can create 4 partitions, and divide up the compute cores among them. Then the user can assign each individual container their own individual partition. Each container would be limited to the resources within it’s assigned partition, but also that container would have exclusive access to those resources. This essentially provides isolation, and some Quality of Service (QoS). How this is currently implemented (in downstream), is perhaps not ideal. A privileged daemon process reads a configuration file which defines the number of partitions, and the set of resources assigned to each. That daemon makes requests to the firmware to create the partitions, and gets a unique ID for each. Then the daemon makes a request to the driver to create a “shadow device”, which is a child dev node. The driver verifies with the firmware that the partition ID is valid, and then creates the dev node. Internally the driver associates this shadow device with the partition ID so that each request to the firmware is tagged with the partition ID by the driver. This tagging allows the firmware to determine that a request is targeted for a specific partition. Finally, the shadow device is passed into the container, instead of the normal dev node. The userspace within the container operates the shadow device normally. One concern with the current implementation is that it is possible to create a large number of partitions. Since each partition is represented by a shadow device dev node, this can create a large number of dev nodes and exhaust the minor number space. I wonder if this functionality is better represented by a cgroup. Instead of creating a dev node for the partition, we can just run the container process within the cgroup. However it doesn’t look like cgroups have a concept of resource reservation. It is just a limit. If that impression is accurate, then I struggle to see how to provide the desired isolation as some entity not under the cgroup could consume all of the device resources, leaving the containers unable to perform their tasks. So, cgroup experts, does this sound like something that should be represented by a cgroup, or is cgroup the wrong mechanism for this usecase? [1] - https://lore.kernel.org/all/1660588956-24027-1-git-send-email-quic_jh...@quicinc.com/
[PATCH 1/2] drm/i915/uc: Support for version reduced and multiple firmware files
From: John Harrison
There was a misunderstanding in how firmware file compatibility should
be managed within i915. This has been clarified as:
i915 must support all existing firmware releases forever
new minor firmware releases should replace prior versions
only backwards compatibility breaking releases should be a new file
Hence this patch cleans up the single fallback file support that was
added as a quick fix emergency effort. That is now removed in
preference to supporting arbitrary numbers of firmware files per
platform as normal.
The patch also adds support for having GuC firmwrae files that are
named by major version only (because the major version indicates
backwards breaking changes that affect the KMD) and for having HuC
firmware files with no version number at all (because the KMD has no
interface requirements with the HuC).
For GuC, the driver will report via dmesg if the found file is older than
expected. For HuC, the KMD will no longer require updating for any new
HuC release so will not be able to report what the latest expected
version is.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 396 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 33 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 16 +-
5 files changed, 275 insertions(+), 184 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0d17da77e7872..d1715971fdd79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1868,7 +1868,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
if (guc->submission_initialized)
return 0;
- if (guc->fw.major_ver_found < 70) {
+ if (guc->fw.file_found.major_ver < 70) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2303,7 +2303,7 @@ static int register_context(struct intel_context *ce,
bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_found.major_ver >= 70)
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2315,7 +2315,7 @@ static int register_context(struct intel_context *ce,
bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_found.major_ver >= 70)
guc_context_policy_init_v70(ce, loop);
}
@@ -2921,7 +2921,7 @@ static void __guc_context_set_preemption_timeout(struct
intel_guc *guc,
u16 guc_id,
u32 preemption_timeout)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_found.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(, guc_id);
@@ -3186,7 +3186,7 @@ static int guc_context_alloc(struct intel_context *ce)
static void __guc_context_set_prio(struct intel_guc *guc,
struct intel_context *ce)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_found.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(, ce->guc_id.id);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index f2e7c82985efd..0697128cc3362 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -436,8 +436,8 @@ static void print_fw_ver(struct intel_uc *uc, struct
intel_uc_fw *fw)
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
drm_info(>drm, "%s firmware %s version %u.%u\n",
-intel_uc_fw_type_repr(fw->type), fw->path,
-fw->major_ver_found, fw->minor_ver_found);
+intel_uc_fw_type_repr(fw->type), fw->file_found.path,
+fw->file_found.major_ver, fw->file_found.minor_ver);
}
static int __uc_init_hw(struct intel_uc *uc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 58547292efa0a..eb3a15f0fa479 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -41,7 +41,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
"%s firmware -> %s\n",
intel_uc_fw_type_repr(uc_fw->type),
status == INTEL_UC_FIRMWARE_SELECTED ?
- uc_fw->path : intel_uc_fw_status_repr(status));
+
[PATCH 2/2] drm/i915/uc: Enable version reduced firmware files for newest platforms
From: John Harrison Going forwards, the intention is for GuC firmware files to be named for their major version only and HuC firmware files to have no version number in the name at all. This patch adds those entries for DG2 and ADL-P/S. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index eb3a15f0fa479..deb01dddeb3e5 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -53,6 +53,8 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * firmware as TGL. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ + fw_def(DG2, 0, guc_maj(dg2, 70, 0)) \ + fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 0)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 69, 0, 3)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \ @@ -71,7 +73,9 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, fw_def(SKYLAKE, 0, guc_mmp(skl, 70, 1, 1)) #define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_raw, huc_mmp) \ + fw_def(ALDERLAKE_P, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_P, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(ALDERLAKE_S, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_S, 0, huc_mmp(tgl, 7, 9, 3)) \ fw_def(DG1, 0, huc_mmp(dg1, 7, 9, 3)) \ fw_def(ROCKETLAKE, 0, huc_mmp(tgl, 7, 9, 3)) \ -- 2.37.2
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
On 8/16/22 15:03, Christian König wrote: > Am 16.08.22 um 13:44 schrieb Dmitry Osipenko: >> [SNIP] >>> The other complication I noticed is that we don't seem to keep around >>> the fd after importing to a GEM handle. And I could imagine that >>> doing so could cause issues with too many fd's. So I guess the best >>> thing is to keep the status quo and let drivers that cannot mmap >>> imported buffers just fail mmap? >> That actually should be all the drivers excluding those that use >> DRM-SHMEM because only DRM-SHMEM uses dma_buf_mmap(), that's why it >> works for Panfrost. I'm pretty sure mmaping of imported GEMs doesn't >> work for the MSM driver, isn't it? >> >> Intel and AMD drivers don't allow to map the imported dma-bufs. Both >> refuse to do the mapping. >> >> Although, AMDGPU "succeeds" to do the mapping using >> AMDGPU_GEM_DOMAIN_GTT, but then touching the mapping causes bus fault, >> hence mapping actually fails. I think it might be the AMDGPU >> driver/libdrm bug, haven't checked yet. > > That's then certainly broken somehow. Amdgpu should nerve ever have > allowed to mmap() imported DMA-bufs and the last time I check it didn't. I'll take a closer look. So far I can only tell that it's a kernel driver issue because once I re-applied this "Don't map imported GEMs" patch, AMDGPU began to refuse mapping AMDGPU_GEM_DOMAIN_GTT. >> So we're back to the point that neither of DRM drivers need to map >> imported dma-bufs and this was never tested. In this case this patch is >> valid, IMO. Actually, I'm now looking at Etnaviv and Nouveau and seems they should map imported dma-buf properly. I know that people ran Android on Etnaviv. So maybe devices with a separated GPU/display need to map imported display BO for Android support. Wish somebody who ran Android on one of these devices using upstream drivers could give a definitive answer. I may try to test Nouveau later on. -- Best regards, Dmitry
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
Den 16.08.2022 11.49, skrev Maxime Ripard: > On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote: >> >> >> Den 16.08.2022 10.26, skrev Maxime Ripard: >>> Hi, >>> >>> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote: Den 29.07.2022 18.34, skrev Maxime Ripard: > The TV mode property has been around for a while now to select and get the > current TV mode output on an analog TV connector. > > Despite that property name being generic, its content isn't and has been > driver-specific which makes it hard to build any generic behaviour on top > of it, both in kernel and user-space. > > Let's create a new bitmask tv norm property, that can contain any of the > analog TV standards currently supported by kernel drivers. Each driver can > then pass in a bitmask of the modes it supports. > > We'll then be able to phase out the older tv mode property. > > Signed-off-by: Maxime Ripard > Please also update Documentation/gpu/kms-properties.csv Requirements for adding a new property is found in Documentation/gpu/drm-kms.rst >>> >>> I knew this was going to be raised at some point, so I'm glad it's that >>> early :) >>> >>> I really don't know what to do there. If we stick by our usual rules, >>> then we can't have any of that work merged. >>> >>> However, I think the status quo is not really satisfactory either. >>> Indeed, we have a property, that doesn't follow those requirements >>> either, with a driver-specific content, and that stands in the way of >>> fixes and further improvements at both the core framework and driver >>> levels. >>> >>> So having that new property still seems like a net improvement at the >>> driver, framework and uAPI levels, even if it's not entirely following >>> the requirements we have in place. >>> >>> Even more so since, realistically, those kind of interfaces will never >>> get any new development on the user-space side of things, it's >>> considered by everyone as legacy. >>> >>> This also is something we need to support at some point if we want to >>> completely deprecate the fbdev drivers and provide decent alternatives >>> in KMS. >>> >>> So yeah, strictly speaking, we would not qualify for our requirements >>> there. I still think we have a strong case for an exception though. >> >> Which requirements would that be? The only one I can see is the >> documentation and maybe an IGT test. > > This is the one I had in mind > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements > Oh right, I had forgotten about that one. One benefit of having a userspace implementation is that it increases the chance of widespread adoption having a working implementation to look at. I don't think the reason tv.mode is not used anywhere (that I know of) is because the driver picks the enum values resulting in no standard names. It's a niche thing and way down on the todo list. nouveau and ch7006 has a tv_norm module parameter which certainly doesn't help in moving people/projects over to the DRM property (downstream rpi also has it now). mpv[1] is a commandline media player that after a quick look might be a candidate for implementing the property without too much effort. How do you test the property? I've used modetest but I can only change to a tv.mode that matches the current display mode. I can't switch from ntsc to pal for instance. I have tried changing mode on rpi-5.15 (which I will switch to for the gud gadget), but I always end up with flip timeouts when changing the value: $ cat /proc/cpuinfo | grep Model Model : Raspberry Pi 4 Model B Rev 1.1 $ uname -a Linux pi4t 5.15.56-v7l+ #1575 SMP Fri Jul 22 20:29:46 BST 2022 armv7l GNU/Linux $ sudo dmesg -C $ modetest -M vc4 -s 45:720x480i -w 45:mode:1 setting mode 720x480i-29.97Hz on connectors 45, crtc 73 failed to set gamma: Function not implemented $ dmesg $ modetest -M vc4 -s 45:720x480i -w 45:mode:0 setting mode 720x480i-29.97Hz on connectors 45, crtc 73 failed to set gamma: Function not implemented $ dmesg [ 95.193059] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:73:crtc-1] flip_done timed out [ 105.433112] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out [ 105.433519] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:73:crtc-1] commit wait timed out [ 115.673095] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out [ 115.673498] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:63:plane-1] commit wait timed out [ 125.913106] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out [ 125.913510] vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit [ 136.153411] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:73:crtc-1] flip_done timed out I doesn't help to reload vc4, I have to reboot to get it working again. I get this when
Re: [BUG][5.20] refcount_t: underflow; use-after-free
On Mon, Aug 15, 2022 at 3:37 PM Mikhail Gavrilov wrote: > > Thanks, I tested this patch. > But with this patch use-after-free problem happening in another place: Does anyone have an idea why the second use-after-free happened? >From the trace I don't understand which code is related. I don't quite understand what the "Workqueue" entry in the trace means. [ 408.358737] [ cut here ] [ 408.358743] refcount_t: underflow; use-after-free. [ 408.358760] WARNING: CPU: 9 PID: 62 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [ 408.358769] Modules linked in: uinput snd_seq_dummy rfcomm snd_hrtimer nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink qrtr bnep sunrpc binfmt_misc snd_seq_midi snd_seq_midi_event mt76x2u mt76x2_common snd_hda_codec_realtek mt76x02_usb snd_hda_codec_generic iwlmvm snd_hda_codec_hdmi mt76_usb intel_rapl_msr snd_hda_intel mt76x02_lib intel_rapl_common snd_intel_dspcfg snd_intel_sdw_acpi mt76 snd_hda_codec vfat fat snd_usb_audio snd_hda_core edac_mce_amd mac80211 snd_usbmidi_lib snd_hwdep snd_rawmidi mc snd_seq btusb kvm_amd iwlwifi snd_seq_device btrtl btbcm libarc4 btintel eeepc_wmi snd_pcm iwlmei kvm btmtk asus_wmi ledtrig_audio irqbypass joydev snd_timer sparse_keymap bluetooth platform_profile rapl cfg80211 snd video wmi_bmof soundcore i2c_piix4 k10temp rfkill mei [ 408.358853] asus_ec_sensors acpi_cpufreq zram hid_logitech_hidpp amdgpu igb dca drm_ttm_helper ttm iommu_v2 crct10dif_pclmul gpu_sched crc32_pclmul ucsi_ccg crc32c_intel drm_buddy nvme typec_ucsi drm_display_helper ghash_clmulni_intel ccp typec nvme_core sp5100_tco cec wmi ip6_tables ip_tables fuse [ 408.358880] Unloaded tainted modules: amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 fjes():1 [ 408.358953] pcc_cpufreq():1 pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 [ 408.358967] CPU: 9 PID: 62 Comm: kworker/9:0 Tainted: G W L --- --- 6.0.0-0.rc1.13.fc38.x86_64+debug #1 [ 408.358971] Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 4403 04/27/2022 [ 408.358974] Workqueue: events drm_sched_entity_kill_jobs_work [gpu_sched] [ 408.358982] RIP: 0010:refcount_warn_saturate+0xba/0x110 [ 408.358987] Code: 01 01 e8 d9 59 6f 00 0f 0b e9 a2 46 a5 00 80 3d 3e 7e be 01 00 75 85 48 c7 c7 70 99 8e 92 c6 05 2e 7e be 01 01 e8 b6 59 6f 00 <0f> 0b e9 7f 46 a5 00 80 3d 19 7e be 01 00 0f 85 5e ff ff ff 48 c7 [ 408.358990] RSP: 0018:b124003efe60 EFLAGS: 00010286 [ 408.358994] RAX: 0026 RBX: 9987a025d428 RCX: [ 408.358997] RDX: 0001 RSI: 928d0754 RDI: [ 408.358999] RBP: 9994e4ff5600 R08: R09: b124003efd10 [ 408.359001] R10: 0003 R11: 99952e2fffe8 R12: 9994e4ffc800 [ 408.359004] R13: 998600228cc0 R14: 9994e4ffc805 R15: 9987a025d430 [ 408.359006] FS: () GS:9994e4e0() knlGS: [ 408.359009] CS: 0010 DS: ES: CR0: 80050033 [ 408.359012] CR2: 27ac39e78000 CR3: 0001a66d8000 CR4: 00350ee0 [ 408.359015] Call Trace: [ 408.359017] [ 408.359020] process_one_work+0x2a0/0x600 [ 408.359032] worker_thread+0x4f/0x3a0 [ 408.359036] ? process_one_work+0x600/0x600 [ 408.359039] kthread+0xf5/0x120 [ 408.359044] ? kthread_complete_and_exit+0x20/0x20 [ 408.359049] ret_from_fork+0x22/0x30 [ 408.359061] [ 408.359063] irq event stamp: 5468 [ 408.359064] hardirqs last enabled at (5467): [] _raw_spin_unlock_irq+0x24/0x50 [ 408.359071] hardirqs last disabled at (5468): [] __schedule+0xe2c/0x16d0 [ 408.359076] softirqs last enabled at (2482): [] rht_deferred_worker+0x708/0xc00 [ 408.359079] softirqs last disabled at (2480): [] rht_deferred_worker+0x1f7/0xc00 [ 408.359082] ---[ end trace ]--- Full kernel log is here:
Re: [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
On Tue, Aug 16, 2022 at 4:53 AM Kai-Heng Feng
wrote:
>
> On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> dGFX so external monitors are routed to dGFX, and more monitors can be
> supported as result.
>
> To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
> on intel_dsm_guid2. This method is described in Intel document 632107.
>
Can we please not do things like this just because?
It forces the discrete GPU to be on leading to higher thermal pressure
and power consumption of the system. Lower battery runtime or higher
fan noise is the result. Not everybody wants to use an AC simply just
because they attach an external display.
If the problem is "we run out of displays" then can we have something
more dynamic, where we are doing this only and only if we run out of
resources to drive as that many displays.
Most users will be fine with ports being driven by the iGPU. Why hurt
most users, because of some weird special case with mostly only
drawbacks?
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index e78430001f077..3bd5930e2769b 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
> 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
>
> #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
>
> static const guid_t intel_dsm_guid2 =
> GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> @@ -187,6 +188,7 @@ void intel_dsm_get_bios_data_funcs_supported(struct
> drm_i915_private *i915)
> struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> acpi_handle dhandle;
> union acpi_object *obj;
> + int supported = 0;
>
> dhandle = ACPI_HANDLE(>dev);
> if (!dhandle)
> @@ -194,8 +196,22 @@ void intel_dsm_get_bios_data_funcs_supported(struct
> drm_i915_private *i915)
>
> obj = acpi_evaluate_dsm(dhandle, _dsm_guid2,
> INTEL_DSM_REVISION_ID,
> INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED,
> NULL);
> - if (obj)
> + if (obj) {
> + if (obj->type == ACPI_TYPE_INTEGER)
> + supported = obj->integer.value;
> +
> ACPI_FREE(obj);
> + }
> +
> + /* Tiger Lake H DP-IN Boot Time Switching from iGfx to dGfx */
> + if (supported & BIT(20)) {
> + obj = acpi_evaluate_dsm(dhandle, _dsm_guid2,
> + INTEL_DSM_REVISION_ID,
> + INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
> + NULL);
> + if (obj)
> + ACPI_FREE(obj);
> + }
> }
>
> /*
> --
> 2.36.1
>
Re: [PATCH] drm/nouveau/kms/nv140-: Disable interlacing
On Tue, Aug 16, 2022 at 8:04 PM Lyude Paul wrote: > > As it turns out: while Nvidia does actually have interlacing knobs on their > GPU still pretty much no current GPUs since Volta actually support it. > Trying interlacing on these GPUs will result in NVDisplay being quite > unhappy like so: > > nouveau :1f:00.0: disp: chid 0 stat 4802 reason 4 [INVALID_ARG] mthd > 2008 data 0001 code 0008 > nouveau :1f:00.0: disp: chid 0 stat 10005080 reason 5 [INVALID_STATE] > mthd 0200 data 0001 code 0001 > > So let's fix this by following the same behavior Nvidia's driver does and > disable interlacing entirely. > > Signed-off-by: Lyude Paul > Cc: sta...@vger.kernel.org > --- > drivers/gpu/drm/nouveau/nouveau_connector.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c > b/drivers/gpu/drm/nouveau/nouveau_connector.c > index 43a9d1e1cf71..8100c75ee731 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_connector.c > +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c > @@ -504,7 +504,8 @@ nouveau_connector_set_encoder(struct drm_connector > *connector, > connector->interlace_allowed = > nv_encoder->caps.dp_interlace; > else > - connector->interlace_allowed = true; > + connector->interlace_allowed = > + drm->client.device.info.family < > NV_DEVICE_INFO_V0_VOLTA; > connector->doublescan_allowed = true; > } else > if (nv_encoder->dcb->type == DCB_OUTPUT_LVDS || > -- > 2.37.1 > Reviewed-by: Karol Herbst
Re: [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
On Tue, 2022-08-16 at 14:24 -0400, Lyude Paul wrote:
> On Tue, 2022-08-16 at 19:29 +0800, Kai-Heng Feng wrote:
> > On Tue, Aug 16, 2022 at 4:06 PM Jani Nikula
> > wrote:
> > >
> > > On Tue, 16 Aug 2022, Kai-Heng Feng wrote:
> > > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > > > dGFX so external monitors are routed to dGFX, and more monitors can be
> > > > supported as result.
> > > >
> > > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
> > > > on intel_dsm_guid2. This method is described in Intel document 632107.
>
> Is this documentation released anywhere? We've been wondering about these
> interfaces for quite a long time, and it would be good to know if there's docs
> for this we haven't really been seeing.
>
> > >
> > > Is this the policy decision that we want to unconditionally make,
> > > though?
> >
> > I believes so, so more external monitors can be supported at the same time.
> >
> > Kai-Heng
>
> Is this for systems with dual Intel GPUs? I ask because if this affects
> Intel/Nvidia hybrid systems then this is a huge no from me. Nouveau is able to
> support these systems, but at a limited capacity. This would imply that we are
> making external displays work for users of the nvidia proprietary driver, at
> the expense making external display support for mainline kernel users
> substantially worse for people who are using the mainline kernel. Which isn't
> a choice we should be making, because nvidia's OOT driver is not a mainline
> kernel driver.
Doing some quick research, unless the models mentioned in the commit message
are unreleased some of them are definitely Intel/Nvidia hybrids. So I'm going
to say:
NAK-by: Lyude Paul
If you'd like to resubmit this for systems with amdgpus and Intel only, that's
perfectly fine with me if the Intel folks are ok with it. But please hold off
on this for Nvidia systems, at least until we've got GSP reworks functional in
nouveau. If nvidia's interested in making this work for their driver, they're
welcome to do the work there. For reference: the main limitations you would
hit as a result of this patch would be lagginess on the external displays as a
result of us not being able to reclock the GPU, which means PCIe bandwidth
will be pretty limited.
>
> If this is just for Intel/Intel systems though that's probably fine, and it
> might also be fine for AMD systems.
>
> >
> > >
> > > BR,
> > > Jani.
> > >
> > > >
> > > > Signed-off-by: Kai-Heng Feng
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
> > > > 1 file changed, 17 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > index e78430001f077..3bd5930e2769b 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
> > > > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> > > >
> > > > #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> > > > +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
> > > >
> > > > static const guid_t intel_dsm_guid2 =
> > > > GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> > > > @@ -187,6 +188,7 @@ void intel_dsm_get_bios_data_funcs_supported(struct
> > > > drm_i915_private *i915)
> > > > struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > > > acpi_handle dhandle;
> > > > union acpi_object *obj;
> > > > + int supported = 0;
> > > >
> > > > dhandle = ACPI_HANDLE(>dev);
> > > > if (!dhandle)
> > > > @@ -194,8 +196,22 @@ void
> > > > intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> > > >
> > > > obj = acpi_evaluate_dsm(dhandle, _dsm_guid2,
> > > > INTEL_DSM_REVISION_ID,
> > > >
> > > > INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, NULL);
> > > > - if (obj)
> > > > + if (obj) {
> > > > + if (obj->type == ACPI_TYPE_INTEGER)
> > > > + supported = obj->integer.value;
> > > > +
> > > > ACPI_FREE(obj);
> > > > + }
> > > > +
> > > > + /* Tiger Lake H DP-IN Boot Time Switching from iGfx to dGfx */
> > > > + if (supported & BIT(20)) {
> > > > + obj = acpi_evaluate_dsm(dhandle, _dsm_guid2,
> > > > + INTEL_DSM_REVISION_ID,
> > > > + INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
> > > > + NULL);
> > > > + if (obj)
> > > > + ACPI_FREE(obj);
> > > > + }
> > > > }
> > > >
> > > > /*
> > >
> > > --
> > > Jani Nikula, Intel Open Source Graphics Center
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
On Tue, 2022-08-16 at 19:29 +0800, Kai-Heng Feng wrote:
> On Tue, Aug 16, 2022 at 4:06 PM Jani Nikula
> wrote:
> >
> > On Tue, 16 Aug 2022, Kai-Heng Feng wrote:
> > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > > dGFX so external monitors are routed to dGFX, and more monitors can be
> > > supported as result.
> > >
> > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
> > > on intel_dsm_guid2. This method is described in Intel document 632107.
Is this documentation released anywhere? We've been wondering about these
interfaces for quite a long time, and it would be good to know if there's docs
for this we haven't really been seeing.
> >
> > Is this the policy decision that we want to unconditionally make,
> > though?
>
> I believes so, so more external monitors can be supported at the same time.
>
> Kai-Heng
Is this for systems with dual Intel GPUs? I ask because if this affects
Intel/Nvidia hybrid systems then this is a huge no from me. Nouveau is able to
support these systems, but at a limited capacity. This would imply that we are
making external displays work for users of the nvidia proprietary driver, at
the expense making external display support for mainline kernel users
substantially worse for people who are using the mainline kernel. Which isn't
a choice we should be making, because nvidia's OOT driver is not a mainline
kernel driver.
If this is just for Intel/Intel systems though that's probably fine, and it
might also be fine for AMD systems.
>
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Kai-Heng Feng
> > > ---
> > > drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
> > > 1 file changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > index e78430001f077..3bd5930e2769b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
> > > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> > >
> > > #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> > > +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
> > >
> > > static const guid_t intel_dsm_guid2 =
> > > GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> > > @@ -187,6 +188,7 @@ void intel_dsm_get_bios_data_funcs_supported(struct
> > > drm_i915_private *i915)
> > > struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > > acpi_handle dhandle;
> > > union acpi_object *obj;
> > > + int supported = 0;
> > >
> > > dhandle = ACPI_HANDLE(>dev);
> > > if (!dhandle)
> > > @@ -194,8 +196,22 @@ void intel_dsm_get_bios_data_funcs_supported(struct
> > > drm_i915_private *i915)
> > >
> > > obj = acpi_evaluate_dsm(dhandle, _dsm_guid2,
> > > INTEL_DSM_REVISION_ID,
> > > INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED,
> > > NULL);
> > > - if (obj)
> > > + if (obj) {
> > > + if (obj->type == ACPI_TYPE_INTEGER)
> > > + supported = obj->integer.value;
> > > +
> > > ACPI_FREE(obj);
> > > + }
> > > +
> > > + /* Tiger Lake H DP-IN Boot Time Switching from iGfx to dGfx */
> > > + if (supported & BIT(20)) {
> > > + obj = acpi_evaluate_dsm(dhandle, _dsm_guid2,
> > > + INTEL_DSM_REVISION_ID,
> > > + INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
> > > + NULL);
> > > + if (obj)
> > > + ACPI_FREE(obj);
> > > + }
> > > }
> > >
> > > /*
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [RFC PATCH 02/14] drm/qaic: Add uapi and core driver file
On 8/16/2022 12:00 PM, Krzysztof Kozlowski wrote:
On 16/08/2022 20:47, Jeffrey Hugo wrote:
+static int qaic_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ int ret;
+ int i;
+ int mhi_irq;
+ struct qaic_device *qdev;
+
+ qdev = kzalloc(sizeof(*qdev), GFP_KERNEL);
+ if (!qdev) {
return -ENOMEM;
So, no centralized exit per the coding style? Ok.
Centralized exit except for cases where it is simply return. >
+ ret = -ENOMEM;
+ goto qdev_fail;
+ }
+
+ if (id->device == PCI_DEV_AIC100) {
+ qdev->num_dbc = 16;
+ qdev->dbc = kcalloc(qdev->num_dbc, sizeof(*qdev->dbc),
+ GFP_KERNEL);
Why not devm?
We were having issues with devm and the PCI stuff. Looking at this
again, I think we can apply that here.
+ if (!qdev->dbc) {
+ ret = -ENOMEM;
+ goto device_id_fail;
+ }
+ } else {
+ pci_dbg(pdev, "%s: No matching device found for device id %d\n",
+ __func__, id->device);
How this can happen?
Badly functioning hardware. That hardware has been removed from
circulation. Given that this is an init path and not performance
critical, having this handle the scenario in a sane way instead of
having the driver blow up in a weird way much later on makes me feel better.
How badly functioning hardware can bind and then report some different
ID? If it reports different ID, it cannot bind...
It was one of those issues that was painful enough that I still remember
it occurring, but long ago enough that I don't remember the specifics.
I don't think I'll be able to recreate the issue to re-debug it, so I'll
just remove this.
+static int __init qaic_init(void)
+{
+ int ret;
+
+ if (datapath_polling) {
+ poll_datapath = true;
+ pr_info("qaic: driver initializing in datapath polling mode\n");
No pr() in normal path of init/exit.
This is not the normal path. datapath_polling is a module parameter.
This is something the user can enable, and so it would be good to have
the user informed that the option took effect.
No, not really. User always can check via sysfs and there is no point in
polluting dmesg on module load. It might be printed (if someone has such
modprobe setting) on every system, even without the actual device.
So, I guess this is limited to platform devices?
I see GIC, IOMMU, and PCI doing the same
I guess, will remove.
+ }
+
+ qaic_logging_register();
+
+ ret = mhi_driver_register(_mhi_driver);
+ if (ret) {
+ pr_debug("qaic: mhi_driver_register failed %d\n", ret);
+ goto free_class;
+ }
+
+ ret = pci_register_driver(_pci_driver);
+
No need for such blank lines.
Agreed.
+ if (ret) {
+ pr_debug("qaic: pci_register_driver failed %d\n", ret);
+ goto free_mhi;
+ }
+
+ qaic_telemetry_register();
+ qaic_ras_register();
+ qaic_ssr_register();
+ goto out;
return 0.
Ok.
+
+free_mhi:
+ mhi_driver_unregister(_mhi_driver);
+free_class:
+out:
+ if (ret)
+ qaic_logging_unregister();
+
+ return ret;
+}
+
+static void __exit qaic_exit(void)
+{
+ pr_debug("qaic: exit\n");
No pr() in normal path of init/exit.
Sure.
+ link_up = true;
This is confusing...
Will add a comment. This ties into MHI, and how it can tear down in two
different ways, usually based on the link state.
Shouldn't this be link_up=false?
No. module_exit() will be triggered on rmmod. exit() will unregister
the driver, which will cause qaic_pci_remove() to be called. remove()
calls qaic_mhi_free_controller() which uses the link state.
However, a hotplug event will also trigger qaic_pci_remove().
rmmod - link is up
hotplug - link is down
In this case, we are doing a clean tear down where the link is still up,
and so we should have MHI do the extra tear down that leaves the device
in a good state, in the event the driver gets added again.
Best regards,
Krzysztof
[PATCH] drm/nouveau/kms/nv140-: Disable interlacing
As it turns out: while Nvidia does actually have interlacing knobs on their GPU still pretty much no current GPUs since Volta actually support it. Trying interlacing on these GPUs will result in NVDisplay being quite unhappy like so: nouveau :1f:00.0: disp: chid 0 stat 4802 reason 4 [INVALID_ARG] mthd 2008 data 0001 code 0008 nouveau :1f:00.0: disp: chid 0 stat 10005080 reason 5 [INVALID_STATE] mthd 0200 data 0001 code 0001 So let's fix this by following the same behavior Nvidia's driver does and disable interlacing entirely. Signed-off-by: Lyude Paul Cc: sta...@vger.kernel.org --- drivers/gpu/drm/nouveau/nouveau_connector.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 43a9d1e1cf71..8100c75ee731 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -504,7 +504,8 @@ nouveau_connector_set_encoder(struct drm_connector *connector, connector->interlace_allowed = nv_encoder->caps.dp_interlace; else - connector->interlace_allowed = true; + connector->interlace_allowed = + drm->client.device.info.family < NV_DEVICE_INFO_V0_VOLTA; connector->doublescan_allowed = true; } else if (nv_encoder->dcb->type == DCB_OUTPUT_LVDS || -- 2.37.1
Re: [RFC PATCH 02/14] drm/qaic: Add uapi and core driver file
On 16/08/2022 20:47, Jeffrey Hugo wrote:
>>> +static int qaic_pci_probe(struct pci_dev *pdev,
>>> + const struct pci_device_id *id)
>>> +{
>>> + int ret;
>>> + int i;
>>> + int mhi_irq;
>>> + struct qaic_device *qdev;
>>> +
>>> + qdev = kzalloc(sizeof(*qdev), GFP_KERNEL);
>>> + if (!qdev) {
>>
>> return -ENOMEM;
>
> So, no centralized exit per the coding style? Ok.
Centralized exit except for cases where it is simply return.
>
>>
>>> + ret = -ENOMEM;
>>> + goto qdev_fail;
>>> + }
>>> +
>>> + if (id->device == PCI_DEV_AIC100) {
>>> + qdev->num_dbc = 16;
>>> + qdev->dbc = kcalloc(qdev->num_dbc, sizeof(*qdev->dbc),
>>> + GFP_KERNEL);
>>
>> Why not devm?
>
> We were having issues with devm and the PCI stuff. Looking at this
> again, I think we can apply that here.
>
>>
>>> + if (!qdev->dbc) {
>>> + ret = -ENOMEM;
>>> + goto device_id_fail;
>>> + }
>>> + } else {
>>> + pci_dbg(pdev, "%s: No matching device found for device id %d\n",
>>> + __func__, id->device);
>>
>> How this can happen?
>
> Badly functioning hardware. That hardware has been removed from
> circulation. Given that this is an init path and not performance
> critical, having this handle the scenario in a sane way instead of
> having the driver blow up in a weird way much later on makes me feel better.
How badly functioning hardware can bind and then report some different
ID? If it reports different ID, it cannot bind...
(...)
>>> +static int __init qaic_init(void)
>>> +{
>>> + int ret;
>>> +
>>> + if (datapath_polling) {
>>> + poll_datapath = true;
>>> + pr_info("qaic: driver initializing in datapath polling mode\n");
>>
>> No pr() in normal path of init/exit.
>
> This is not the normal path. datapath_polling is a module parameter.
> This is something the user can enable, and so it would be good to have
> the user informed that the option took effect.
No, not really. User always can check via sysfs and there is no point in
polluting dmesg on module load. It might be printed (if someone has such
modprobe setting) on every system, even without the actual device.
>
>>
>>> + }
>>> +
>>> + qaic_logging_register();
>>> +
>>> + ret = mhi_driver_register(_mhi_driver);
>>> + if (ret) {
>>> + pr_debug("qaic: mhi_driver_register failed %d\n", ret);
>>> + goto free_class;
>>> + }
>>> +
>>> + ret = pci_register_driver(_pci_driver);
>>> +
>>
>> No need for such blank lines.
>
> Agreed.
>
>>
>>> + if (ret) {
>>> + pr_debug("qaic: pci_register_driver failed %d\n", ret);
>>> + goto free_mhi;
>>> + }
>>> +
>>> + qaic_telemetry_register();
>>> + qaic_ras_register();
>>> + qaic_ssr_register();
>>> + goto out;
>>
>> return 0.
>
> Ok.
>
>>
>>> +
>>> +free_mhi:
>>> + mhi_driver_unregister(_mhi_driver);
>>> +free_class:
>>> +out:
>>> + if (ret)
>>> + qaic_logging_unregister();
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static void __exit qaic_exit(void)
>>> +{
>>> + pr_debug("qaic: exit\n");
>>
>> No pr() in normal path of init/exit.
>
> Sure.
>
>>
>>> + link_up = true;
>>
>> This is confusing...
>
> Will add a comment. This ties into MHI, and how it can tear down in two
> different ways, usually based on the link state.
Shouldn't this be link_up=false?
>
> In this case, we are doing a clean tear down where the link is still up,
> and so we should have MHI do the extra tear down that leaves the device
> in a good state, in the event the driver gets added again.
>
>>
Best regards,
Krzysztof
Re: [RFC PATCH 02/14] drm/qaic: Add uapi and core driver file
On 8/16/2022 5:06 AM, Krzysztof Kozlowski wrote:
On 15/08/2022 21:42, Jeffrey Hugo wrote:
Add the QAIC driver uapi file and core driver file that binds to the PCIe
device. The core driver file also creates the drm device and manages all
the interconnections between the different parts of the driver.
Thank you for your patch. There is something to discuss/improve.
Change-Id: I28854e8a5dacda217439be2f65a4ab67d4dccd1e
This has to go...
Yep, made this mistake in the entire series. I have a note to do better
next time. It won't be necessary to continue pointing this out for the
rest of the series.
Since this is RFC and not expected to be merged anyways, I'm hoping it's
not necessary to respin just to enable further reviews.
+static int qaic_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ int ret;
+ int i;
+ int mhi_irq;
+ struct qaic_device *qdev;
+
+ qdev = kzalloc(sizeof(*qdev), GFP_KERNEL);
+ if (!qdev) {
return -ENOMEM;
So, no centralized exit per the coding style? Ok.
+ ret = -ENOMEM;
+ goto qdev_fail;
+ }
+
+ if (id->device == PCI_DEV_AIC100) {
+ qdev->num_dbc = 16;
+ qdev->dbc = kcalloc(qdev->num_dbc, sizeof(*qdev->dbc),
+ GFP_KERNEL);
Why not devm?
We were having issues with devm and the PCI stuff. Looking at this
again, I think we can apply that here.
+ if (!qdev->dbc) {
+ ret = -ENOMEM;
+ goto device_id_fail;
+ }
+ } else {
+ pci_dbg(pdev, "%s: No matching device found for device id %d\n",
+ __func__, id->device);
How this can happen?
Badly functioning hardware. That hardware has been removed from
circulation. Given that this is an init path and not performance
critical, having this handle the scenario in a sane way instead of
having the driver blow up in a weird way much later on makes me feel better.
+ ret = -EINVAL;
+ goto device_id_fail;
+ }
+
+ qdev->cntl_wq = alloc_workqueue("qaic_cntl", WQ_UNBOUND, 0);
+ if (!qdev->cntl_wq) {
+ ret = -ENOMEM;
+ goto wq_fail;
+ }
+ qdev->tele_wq = alloc_workqueue("qaic_tele", WQ_UNBOUND, 0);
+ if (!qdev->tele_wq) {
+ ret = -ENOMEM;
+ goto tele_wq_fail;
+ }
+ qdev->ssr_wq = alloc_workqueue("qaic_ssr", WQ_UNBOUND, 0);
+ if (!qdev->ssr_wq) {
+ ret = -ENOMEM;
+ goto ssr_wq_fail;
+ }
+ pci_set_drvdata(pdev, qdev);
+ qdev->pdev = pdev;
+ mutex_init(>cntl_mutex);
+ INIT_LIST_HEAD(>cntl_xfer_list);
+ init_srcu_struct(>dev_lock);
+ mutex_init(>tele_mutex);
+ INIT_LIST_HEAD(>tele_xfer_list);
+ INIT_LIST_HEAD(>bootlog);
+ mutex_init(>bootlog_mutex);
+ INIT_LIST_HEAD(>qaic_drm_devices);
+ mutex_init(>qaic_drm_devices_mutex);
+ for (i = 0; i < qdev->num_dbc; ++i) {
+ mutex_init(>dbc[i].handle_lock);
+ spin_lock_init(>dbc[i].xfer_lock);
+ idr_init(>dbc[i].buf_handles);
+ qdev->dbc[i].qdev = qdev;
+ qdev->dbc[i].id = i;
+ INIT_LIST_HEAD(>dbc[i].xfer_list);
+ init_srcu_struct(>dbc[i].ch_lock);
+ init_waitqueue_head(>dbc[i].dbc_release);
+ INIT_LIST_HEAD(>dbc[i].bo_lists);
+ }
+
+ qdev->bars = pci_select_bars(pdev, IORESOURCE_MEM);
+
+ /* make sure the device has the expected BARs */
+ if (qdev->bars != (BIT(0) | BIT(2) | BIT(4))) {
+ pci_dbg(pdev, "%s: expected BARs 0, 2, and 4 not found in device.
Found 0x%x\n",
+ __func__, qdev->bars);
+ ret = -EINVAL;
+ goto bar_fail;
+ }
+
+ ret = pci_enable_device(pdev);
+ if (ret)
+ goto enable_fail;
+
+ ret = pci_request_selected_regions(pdev, qdev->bars, "aic100");
+ if (ret)
+ goto request_regions_fail;
+
+ pci_set_master(pdev);
+
+ ret = dma_set_mask(>dev, DMA_BIT_MASK(64));
+ if (ret)
+ goto dma_mask_fail;
+ ret = dma_set_coherent_mask(>dev, DMA_BIT_MASK(64));
+ if (ret)
+ goto dma_mask_fail;
+ ret = dma_set_max_seg_size(>dev, UINT_MAX);
+ if (ret)
+ goto dma_mask_fail;
+
+ qdev->bar_0 = pci_ioremap_bar(pdev, 0);
+ if (!qdev->bar_0) {
+ ret = -ENOMEM;
+ goto ioremap_0_fail;
+ }
+
+ qdev->bar_2 = pci_ioremap_bar(pdev, 2);
+ if (!qdev->bar_2) {
+ ret = -ENOMEM;
+ goto ioremap_2_fail;
+ }
+
+ for (i = 0; i < qdev->num_dbc; ++i)
+ qdev->dbc[i].dbc_base = qdev->bar_2 +
Re: [PATCH v2 1/3] dma-buf: Add ioctl to query mmap coherency/cache info
On Tue, Aug 16, 2022 at 9:51 AM Christian König
wrote:
>
> Am 16.08.22 um 16:26 schrieb Rob Clark:
> > On Tue, Aug 16, 2022 at 1:27 AM Christian König
> > wrote:
> >> Am 15.08.22 um 23:15 schrieb Rob Clark:
> >>> From: Rob Clark
> >>>
> >>> This is a fairly narrowly focused interface, providing a way for a VMM
> >>> in userspace to tell the guest kernel what pgprot settings to use when
> >>> mapping a buffer to guest userspace.
> >>>
> >>> For buffers that get mapped into guest userspace, virglrenderer returns
> >>> a dma-buf fd to the VMM (crosvm or qemu). In addition to mapping the
> >>> pages into the guest VM, it needs to report to drm/virtio in the guest
> >>> the cache settings to use for guest userspace. In particular, on some
> >>> architectures, creating aliased mappings with different cache attributes
> >>> is frowned upon, so it is important that the guest mappings have the
> >>> same cache attributes as any potential host mappings.
> >>>
> >>> Signed-off-by: Rob Clark
> >>> ---
> >>> v2: Combine with coherency, as that is a related concept.. and it is
> >>> relevant to the VMM whether coherent access without the SYNC ioctl
> >>> is possible; set map_info at export time to make it more clear
> >>> that it applies for the lifetime of the dma-buf (for any mmap
> >>> created via the dma-buf)
> >> Well, exactly that's a conceptual NAK from my side.
> >>
> >> The caching information can change at any time. For CPU mappings even
> >> without further notice from the exporter.
> > You should look before you criticize, as I left you a way out.. the
> > idea was that DMA_BUF_MAP_INCOHERENT should indicate that the buffer
> > cannot be mapped to the guest. We could ofc add more DMA_BUF_MAP_*
> > values if something else would suit you better. But the goal is to
> > give the VMM enough information to dtrt, or return an error if mapping
> > to guest is not possible. That seems better than assuming mapping to
> > guest will work and guessing about cache attrs
>
> Well I'm not rejecting the implementation, I'm rejecting this from the
> conceptual point of view.
>
> We intentional gave the exporter full control over the CPU mappings.
> This approach here breaks that now.
>
> I haven't seen the full detailed reason why we should do that and to be
> honest KVM seems to mess with things it is not supposed to touch.
>
> For example the page reference count of mappings marked with VM_IO is a
> complete no-go. This is a very strong evidence that this was based on
> rather dangerous halve knowledge about the background of the handling here.
>
> So as long as I don't see a full explanation why KVM is grabbing
> reference to pages while faulting them and why we manually need to
> forward the caching while the hardware documentation indicates otherwise
> I will be rejecting this whole approach.
Didn't we cover this on the previous iteration already. From a host
kernel PoV these are just normal host userspace mappings. The
userspace VMM mapping becomes the "physical address" in the guest and
the stage 2 translation tables map it to the guest userspace.
The resulting cache attrs from combination of S1 and S2 translation
can differ. So ideally we setup the S2 pgtables in guest aligned with
host userspace mappings
BR,
-R
>
> Regards,
> Christian.
>
> >
> > BR,
> > -R
> >
> >> If the hardware can't use the caching information from the host CPU page
> >> tables directly then that pretty much completely breaks the concept that
> >> the exporter is responsible for setting up those page tables.
> >>
> >> Regards,
> >> Christian.
> >>
> >>>drivers/dma-buf/dma-buf.c| 63 +++--
> >>>include/linux/dma-buf.h | 11 ++
> >>>include/uapi/linux/dma-buf.h | 68
> >>>3 files changed, 132 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >>> index 32f55640890c..262c4706f721 100644
> >>> --- a/drivers/dma-buf/dma-buf.c
> >>> +++ b/drivers/dma-buf/dma-buf.c
> >>> @@ -125,6 +125,32 @@ static struct file_system_type dma_buf_fs_type = {
> >>>.kill_sb = kill_anon_super,
> >>>};
> >>>
> >>> +static int __dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct
> >>> *vma)
> >>> +{
> >>> + int ret;
> >>> +
> >>> + /* check if buffer supports mmap */
> >>> + if (!dmabuf->ops->mmap)
> >>> + return -EINVAL;
> >>> +
> >>> + ret = dmabuf->ops->mmap(dmabuf, vma);
> >>> +
> >>> + /*
> >>> + * If the exporter claims to support coherent access, ensure the
> >>> + * pgprot flags match the claim.
> >>> + */
> >>> + if ((dmabuf->map_info != DMA_BUF_MAP_INCOHERENT) && !ret) {
> >>> + pgprot_t wc_prot = pgprot_writecombine(vma->vm_page_prot);
> >>> + if (dmabuf->map_info == DMA_BUF_COHERENT_WC) {
> >>> + WARN_ON_ONCE(pgprot_val(vma->vm_page_prot) !=
> >>>
[PATCH 2/3] iommu/dma: Move public interfaces to linux/iommu.h
The iommu-dma layer is now mostly encapsulated by iommu_dma_ops, with
only a couple more public interfaces left pertaining to MSI integration.
Since these depend on the main IOMMU API header anyway, move their
declarations there, taking the opportunity to update the half-baked
comments to proper kerneldoc along the way.
Signed-off-by: Robin Murphy
---
Note that iommu_setup_dma_ops() should also become internal in a future
phase of the great IOMMU API upheaval - for now as the last bit of true
arch code glue I consider it more "necessarily exposed" than "public".
arch/arm64/mm/dma-mapping.c | 2 +-
drivers/iommu/dma-iommu.c | 15 ++--
drivers/irqchip/irq-gic-v2m.c | 2 +-
drivers/irqchip/irq-gic-v3-its.c | 2 +-
drivers/irqchip/irq-gic-v3-mbi.c | 2 +-
drivers/irqchip/irq-ls-scfg-msi.c | 2 +-
drivers/vfio/vfio_iommu_type1.c | 1 -
include/linux/dma-iommu.h | 40 ---
include/linux/iommu.h | 36
9 files changed, 54 insertions(+), 48 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 599cf81f5685..7d7e9a046305 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -7,7 +7,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 17dd683b2fce..6809b33ac9df 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1633,6 +1633,13 @@ static struct iommu_dma_msi_page
*iommu_dma_get_msi_page(struct device *dev,
return NULL;
}
+/**
+ * iommu_dma_prepare_msi() - Map the MSI page in the IOMMU domain
+ * @desc: MSI descriptor, will store the MSI page
+ * @msi_addr: MSI target address to be mapped
+ *
+ * Return: 0 on success or negative error code if the mapping failed.
+ */
int iommu_dma_prepare_msi(struct msi_desc *desc, phys_addr_t msi_addr)
{
struct device *dev = msi_desc_to_dev(desc);
@@ -1661,8 +1668,12 @@ int iommu_dma_prepare_msi(struct msi_desc *desc,
phys_addr_t msi_addr)
return 0;
}
-void iommu_dma_compose_msi_msg(struct msi_desc *desc,
- struct msi_msg *msg)
+/**
+ * iommu_dma_compose_msi_msg() - Apply translation to an MSI message
+ * @desc: MSI descriptor prepared by iommu_dma_prepare_msi()
+ * @msg: MSI message containing target physical address
+ */
+void iommu_dma_compose_msi_msg(struct msi_desc *desc, struct msi_msg *msg)
{
struct device *dev = msi_desc_to_dev(desc);
const struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c
index b249d4df899e..6e1ac330d7a6 100644
--- a/drivers/irqchip/irq-gic-v2m.c
+++ b/drivers/irqchip/irq-gic-v2m.c
@@ -13,7 +13,7 @@
#define pr_fmt(fmt) "GICv2m: " fmt
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 5ff09de6c48f..e7d8d4208ee6 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -11,9 +11,9 @@
#include
#include
#include
-#include
#include
#include
+#include
#include
#include
#include
diff --git a/drivers/irqchip/irq-gic-v3-mbi.c b/drivers/irqchip/irq-gic-v3-mbi.c
index a2163d32f17d..e1efdec9e9ac 100644
--- a/drivers/irqchip/irq-gic-v3-mbi.c
+++ b/drivers/irqchip/irq-gic-v3-mbi.c
@@ -6,7 +6,7 @@
#define pr_fmt(fmt) "GICv3: " fmt
-#include
+#include
#include
#include
#include
diff --git a/drivers/irqchip/irq-ls-scfg-msi.c
b/drivers/irqchip/irq-ls-scfg-msi.c
index b4927e425f7b..527c90e0920e 100644
--- a/drivers/irqchip/irq-ls-scfg-msi.c
+++ b/drivers/irqchip/irq-ls-scfg-msi.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -18,7 +19,6 @@
#include
#include
#include
-#include
#define MSI_IRQS_PER_MSIR 32
#define MSI_MSIR_OFFSET4
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index c766aa683110..e65861fdba7b 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -37,7 +37,6 @@
#include
#include
#include
-#include
#include
#include "vfio.h"
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 24607dc3c2ac..e83de4f1f3d6 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -15,27 +15,10 @@
/* Domain management interface for IOMMU drivers */
int iommu_get_dma_cookie(struct iommu_domain *domain);
-int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
void iommu_put_dma_cookie(struct iommu_domain *domain);
-/* Setup call for arch DMA mapping code */
-void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit);
int iommu_dma_init_fq(struct iommu_domain *domain);
-/* The DMA API isn't _quite_ the whole story, though... */
[PATCH 1/3] iommu/dma: Clean up Kconfig
Although iommu-dma is a per-architecture chonce, that is currently implemented in a rather haphazard way. Selecting from the arch Kconfig was the original logical approach, but is complicated by having to manage dependencies; conversely, selecting from drivers ends up hiding the architecture dependency *too* well. Instead, let's just have it enable itself automatically when IOMMU API support is enabled for the relevant architectures. It can't get much clearer than that. Signed-off-by: Robin Murphy --- arch/arm64/Kconfig | 1 - drivers/iommu/Kconfig | 3 +-- drivers/iommu/amd/Kconfig | 1 - drivers/iommu/intel/Kconfig | 1 - 4 files changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 571cc234d0b3..59af600445c2 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -209,7 +209,6 @@ config ARM64 select HAVE_KPROBES select HAVE_KRETPROBES select HAVE_GENERIC_VDSO - select IOMMU_DMA if IOMMU_SUPPORT select IRQ_DOMAIN select IRQ_FORCED_THREADING select KASAN_VMALLOC if KASAN diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 5c5cb5bee8b6..1d99c2d984fb 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -137,7 +137,7 @@ config OF_IOMMU # IOMMU-agnostic DMA-mapping layer config IOMMU_DMA - bool + def_bool ARM64 || IA64 || X86 select DMA_OPS select IOMMU_API select IOMMU_IOVA @@ -476,7 +476,6 @@ config VIRTIO_IOMMU depends on VIRTIO depends on (ARM64 || X86) select IOMMU_API - select IOMMU_DMA select INTERVAL_TREE select ACPI_VIOT if ACPI help diff --git a/drivers/iommu/amd/Kconfig b/drivers/iommu/amd/Kconfig index a3cbafb603f5..9b5fc3356bf2 100644 --- a/drivers/iommu/amd/Kconfig +++ b/drivers/iommu/amd/Kconfig @@ -9,7 +9,6 @@ config AMD_IOMMU select PCI_PASID select IOMMU_API select IOMMU_IOVA - select IOMMU_DMA select IOMMU_IO_PGTABLE depends on X86_64 && PCI && ACPI && HAVE_CMPXCHG_DOUBLE help diff --git a/drivers/iommu/intel/Kconfig b/drivers/iommu/intel/Kconfig index 39a06d245f12..c48005147ac5 100644 --- a/drivers/iommu/intel/Kconfig +++ b/drivers/iommu/intel/Kconfig @@ -19,7 +19,6 @@ config INTEL_IOMMU select DMAR_TABLE select SWIOTLB select IOASID - select IOMMU_DMA select PCI_ATS help DMA remapping (DMAR) devices support enables independent address -- 2.36.1.dirty
[PATCH 0/3] iommu/dma: Some housekeeping
Hi All, It's been a while now since iommu-dma grew from a library of DMA ops helpers for arch code into something more abstracted and closely coupled to the IOMMU API core, so it seemed about time to do some housekeeping in the more neglected areas to reflect that. The header reorganisation does touch a range of areas (a couple of which seemingly had no reason to be involved anyway), but hopefully these are all low-impact changes that nobody minds going through the IOMMU tree. Now for the build-bots to tell me what I've missed... Thanks, Robin. Robin Murphy (3): iommu/dma: Clean up Kconfig iommu/dma: Move public interfaces to linux/iommu.h iommu/dma: Make header private arch/arm64/Kconfig | 1 - arch/arm64/mm/dma-mapping.c | 2 +- drivers/acpi/viot.c | 1 - drivers/gpu/drm/exynos/exynos_drm_dma.c | 1 - drivers/iommu/Kconfig | 3 +- drivers/iommu/amd/Kconfig | 1 - drivers/iommu/amd/iommu.c | 2 +- drivers/iommu/apple-dart.c | 3 +- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +- drivers/iommu/arm/arm-smmu/arm-smmu.c | 2 +- drivers/iommu/dma-iommu.c | 18 +++- drivers/iommu/dma-iommu.h | 38 + drivers/iommu/intel/Kconfig | 1 - drivers/iommu/intel/iommu.c | 2 +- drivers/iommu/iommu.c | 3 +- drivers/iommu/virtio-iommu.c| 3 +- drivers/irqchip/irq-gic-v2m.c | 2 +- drivers/irqchip/irq-gic-v3-its.c| 2 +- drivers/irqchip/irq-gic-v3-mbi.c| 2 +- drivers/irqchip/irq-ls-scfg-msi.c | 2 +- drivers/vfio/vfio_iommu_type1.c | 1 - include/linux/dma-iommu.h | 93 - include/linux/iommu.h | 36 23 files changed, 105 insertions(+), 116 deletions(-) create mode 100644 drivers/iommu/dma-iommu.h delete mode 100644 include/linux/dma-iommu.h -- 2.36.1.dirty
Re: [PATCH v2 4/4] drm/format-helper: Add drm_fb_build_fourcc_list() helper
Hi Thomas,
On Tue, Aug 16, 2022 at 03:48:53PM +0200, Thomas Zimmermann wrote:
> Add drm_fb_build_fourcc_list() function that builds a list of supported
> formats from native and emulated ones. Helpful for all drivers that do
> format conversion as part of their plane updates. Update current caller.
>
> v2:
> * use u32 instead of uint32_t (Sam)
> * print a warning if output array is too small (Sam)
> * comment fixes (Sam)
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_format_helper.c | 103
> drivers/gpu/drm/tiny/simpledrm.c| 47 ++---
> include/drm/drm_format_helper.h | 11 ++-
> 3 files changed, 118 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index 56642816fdff..fe1db7dbda3f 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -793,3 +793,106 @@ void drm_fb_xrgb_to_mono(struct iosys_map *dst,
> const unsigned int *dst_pitc
> kfree(src32);
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_mono);
> +
> +static bool is_listed_fourcc(const uint32_t *fourccs, size_t nfourccs,
> uint32_t fourcc)
> +{
> + const uint32_t *fourccs_end = fourccs + nfourccs;
> +
> + while (fourccs < fourccs_end) {
> + if (*fourccs == fourcc)
> + return true;
> + ++fourccs;
> + }
> + return false;
> +}
> +
> +/**
> + * drm_fb_build_fourcc_list - Filters a list of supported color formats
> against
> + *the device's native formats
> + * @dev: DRM device
> + * @native_fourccs: 4CC codes of natively supported color formats
> + * @native_nfourccs: The number of entries in @native_fourccs
> + * @extra_fourccs: 4CC codes of additionally supported color formats
> + * @extra_nfourccs: The number of entries in @extra_fourccs
> + * @fourccs_out: Returns 4CC codes of supported color formats
> + * @nfourccs_out: The number of available entries in @fourccs_out
> + *
> + * This function create a list of supported color format from natively
> + * supported formats and the emulated formats.
> + * At a minimum, most userspace programs expect at least support for
> + * XRGB on the primary plane. Devices that have to emulate the
> + * format, and possibly others, can use drm_fb_build_fourcc_list() to
> + * create a list of supported color formats. The returned list can
> + * be handed over to drm_universal_plane_init() et al. Native formats
> + * will go before emulated formats. Other heuristics might be applied
> + * to optimize the order. Formats near the beginning of the list are
> + * usually preferred over formats near the end of the list.
> + *
> + * Returns:
> + * The number of color-formats 4CC codes returned in @fourccs_out.
> + */
> +size_t drm_fb_build_fourcc_list(struct drm_device *dev,
> + const u32 *native_fourccs, size_t
> native_nfourccs,
> + const u32 *extra_fourccs, size_t extra_nfourccs,
> + u32 *fourccs_out, size_t nfourccs_out)
> +{
> + u32 *fourccs = fourccs_out;
> + const u32 *fourccs_end = fourccs_out + nfourccs_out;
> + bool found_native = false;
> + size_t nfourccs, i;
> +
> + /*
> + * The device's native formats go first.
> + */
> +
> + nfourccs = min_t(size_t, native_nfourccs, nfourccs_out);
If nfourccs < nfourccs_out then there is not enough room for the
formats. I know this is unlikely, but anyway.. Maybe warn here too?
I would use min() here, as the types are all compatible, so no need to
cast to size_t.
> +
> + for (i = 0; i < nfourccs; ++i) {
> + u32 fourcc = native_fourccs[i];
> +
> + drm_dbg_kms(dev, "adding native format %p4cc\n", );
> +
> + if (!found_native)
> + found_native = is_listed_fourcc(extra_fourccs,
> extra_nfourccs, fourcc);
> + *fourccs = fourcc;
> + ++fourccs;
> + }
> +
> + /*
> + * The plane's atomic_update helper converts the framebuffer's color
> format
> + * to a native format when copying to device memory.
> + *
> + * If there is not a single format supported by both, device and
> + * driver, the native formats are likely not supported by the conversion
> + * helpers. Therefore *only* support the native formats and add a
> + * conversion helper ASAP.
> + */
> + if (!found_native) {
> + drm_warn(dev, "Format conversion helpers required to add extra
> formats.\n");
> + goto out;
> + }
> +
> + /*
> + * The extra formats, emulated by the driver, go second.
> + */
> +
> + nfourccs = min_t(size_t, extra_nfourccs, fourccs_end - fourccs);
fourccs_end is a pointer which is subtracted with fourccs * sizeof(fourccs_end)
So the result is a pointer. I do not think this does
Re: [RFC 2/4] dt-bindings: phy: phy-rockchip-inno-dsidphy: add compatible for rk3568
On Fri, 12 Aug 2022 09:32:45 -0500, Chris Morgan wrote: > From: Chris Morgan > > Add a compatible string for the rk3568 dsi-dphy. > > Signed-off-by: Chris Morgan > --- > .../devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [RFC 1/4] dt-bindings: display: rockchip-dsi: add rk3568 compatible
On Fri, 12 Aug 2022 09:32:44 -0500, Chris Morgan wrote: > From: Chris Morgan > > The rk3568 uses the same dw-mipi-dsi controller as previous Rockchip > SOCs, so add a compatible string for it. > > Signed-off-by: Chris Morgan > --- > .../bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
[Bug 216359] [amdgpu] ring gfx timeout after waking from suspend and exiting X
https://bugzilla.kernel.org/show_bug.cgi?id=216359 Shlomo (shl...@fastmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED --- Comment #2 from Shlomo (shl...@fastmail.com) --- Moved to GitLab. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2 1/3] dma-buf: Add ioctl to query mmap coherency/cache info
Am 16.08.22 um 16:26 schrieb Rob Clark:
On Tue, Aug 16, 2022 at 1:27 AM Christian König
wrote:
Am 15.08.22 um 23:15 schrieb Rob Clark:
From: Rob Clark
This is a fairly narrowly focused interface, providing a way for a VMM
in userspace to tell the guest kernel what pgprot settings to use when
mapping a buffer to guest userspace.
For buffers that get mapped into guest userspace, virglrenderer returns
a dma-buf fd to the VMM (crosvm or qemu). In addition to mapping the
pages into the guest VM, it needs to report to drm/virtio in the guest
the cache settings to use for guest userspace. In particular, on some
architectures, creating aliased mappings with different cache attributes
is frowned upon, so it is important that the guest mappings have the
same cache attributes as any potential host mappings.
Signed-off-by: Rob Clark
---
v2: Combine with coherency, as that is a related concept.. and it is
relevant to the VMM whether coherent access without the SYNC ioctl
is possible; set map_info at export time to make it more clear
that it applies for the lifetime of the dma-buf (for any mmap
created via the dma-buf)
Well, exactly that's a conceptual NAK from my side.
The caching information can change at any time. For CPU mappings even
without further notice from the exporter.
You should look before you criticize, as I left you a way out.. the
idea was that DMA_BUF_MAP_INCOHERENT should indicate that the buffer
cannot be mapped to the guest. We could ofc add more DMA_BUF_MAP_*
values if something else would suit you better. But the goal is to
give the VMM enough information to dtrt, or return an error if mapping
to guest is not possible. That seems better than assuming mapping to
guest will work and guessing about cache attrs
Well I'm not rejecting the implementation, I'm rejecting this from the
conceptual point of view.
We intentional gave the exporter full control over the CPU mappings.
This approach here breaks that now.
I haven't seen the full detailed reason why we should do that and to be
honest KVM seems to mess with things it is not supposed to touch.
For example the page reference count of mappings marked with VM_IO is a
complete no-go. This is a very strong evidence that this was based on
rather dangerous halve knowledge about the background of the handling here.
So as long as I don't see a full explanation why KVM is grabbing
reference to pages while faulting them and why we manually need to
forward the caching while the hardware documentation indicates otherwise
I will be rejecting this whole approach.
Regards,
Christian.
BR,
-R
If the hardware can't use the caching information from the host CPU page
tables directly then that pretty much completely breaks the concept that
the exporter is responsible for setting up those page tables.
Regards,
Christian.
drivers/dma-buf/dma-buf.c| 63 +++--
include/linux/dma-buf.h | 11 ++
include/uapi/linux/dma-buf.h | 68
3 files changed, 132 insertions(+), 10 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 32f55640890c..262c4706f721 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -125,6 +125,32 @@ static struct file_system_type dma_buf_fs_type = {
.kill_sb = kill_anon_super,
};
+static int __dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+ int ret;
+
+ /* check if buffer supports mmap */
+ if (!dmabuf->ops->mmap)
+ return -EINVAL;
+
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+
+ /*
+ * If the exporter claims to support coherent access, ensure the
+ * pgprot flags match the claim.
+ */
+ if ((dmabuf->map_info != DMA_BUF_MAP_INCOHERENT) && !ret) {
+ pgprot_t wc_prot = pgprot_writecombine(vma->vm_page_prot);
+ if (dmabuf->map_info == DMA_BUF_COHERENT_WC) {
+ WARN_ON_ONCE(pgprot_val(vma->vm_page_prot) !=
pgprot_val(wc_prot));
+ } else {
+ WARN_ON_ONCE(pgprot_val(vma->vm_page_prot) ==
pgprot_val(wc_prot));
+ }
+ }
+
+ return ret;
+}
+
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct
*vma)
{
struct dma_buf *dmabuf;
@@ -134,16 +160,12 @@ static int dma_buf_mmap_internal(struct file *file,
struct vm_area_struct *vma)
dmabuf = file->private_data;
- /* check if buffer supports mmap */
- if (!dmabuf->ops->mmap)
- return -EINVAL;
-
/* check for overflowing the buffer's size */
if (vma->vm_pgoff + vma_pages(vma) >
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
- return dmabuf->ops->mmap(dmabuf, vma);
+ return __dma_buf_mmap(dmabuf, vma);
}
static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
@@ -326,6 +348,27 @@ static long dma_buf_set_name(struct
drm warning with mainline due to 467e30171b5b ("drm/vc4: hdmi: Move HDMI reset to pm_resume")
Hi All,
Not sure if it has been reported but the mainline kernel shows a drm warning
on RPI4B.
[ 14.821276] WARNING: CPU: 3 PID: 187 at
drivers/gpu/drm/vc4/vc4_hdmi_regs.h:487 vc5_hdmi_reset+0x1f8/0x240 [vc4]
[ 14.837288] Modules linked in: hci_uart btqca btrtl btbcm btintel btsdio(+)
bluetooth bcm2835_v4l2(C) bcm2835_mmal_vchiq(C) videobuf2_vmalloc
videobuf2_memops videobuf2_v4l2 videobuf2_common brcmfmac videodev brcmutil
vc4(+) ecdh_generic ecc drm_display_helper mc raspberrypi_hwmon cec
crct10dif_ce drm_cma_helper cfg80211 dwc2 udc_core i2c_brcmstb roles
snd_bcm2835(C) drm_kms_helper pwm_bcm2835 drm xhci_pci xhci_pci_renesas
snd_soc_core phy_generic ac97_bus snd_pcm_dmaengine snd_pcm snd_timer snd
fb_sys_fops syscopyarea sysfillrect sysimgblt uio_pdrv_genirq uio aes_neon_bs
aes_neon_blk
[ 14.889917] CPU: 3 PID: 187 Comm: systemd-udevd Tainted: G C
6.0.0-rc1-568035b01cfb #1
[ 14.899355] Hardware name: Raspberry Pi 4 Model B (DT)
[ 14.904561] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 14.911620] pc : vc5_hdmi_reset+0x1f8/0x240 [vc4]
[ 14.916433] lr : vc5_hdmi_reset+0x38/0x240 [vc4]
[ 14.921151] sp : 8a85b640
[ 14.923079] uart-pl011 fe201000.serial: no DMA platform data
[ 14.924504] x29: 8a85b640 x28: x27: 56626080
[ 14.937472] x26: 8128e2d8 x25: 8128e988 x24:
[ 14.944708] x23: 40a58000 x22: fb832978 x21: 56626c90
[ 14.951944] x20: x19: 56626080 x18: 0014
[ 14.959180] x17: e6b317d8 x16: c03e2fab x15: 002ffc4a
[ 14.966416] x14: x13: 0010 x12: 0101010101010101
[ 14.973650] x11: ff7f7f7f7f7f7f7f x10: 840003584d5b x9 : 81276518
[ 14.980886] x8 : 0101010101010101 x7 : x6 : 40e5d140
[ 14.988120] x5 : x4 : 8a85b580 x3 :
[ 14.995355] x2 : 0001 x1 : 0002 x0 : 812901c0
[ 15.002591] Call trace:
[ 15.005063] vc5_hdmi_reset+0x1f8/0x240 [vc4]
[ 15.009514] vc4_hdmi_runtime_resume+0x74/0x2dc [vc4]
[ 15.014671] vc4_hdmi_bind+0x22c/0xa40 [vc4]
[ 15.019038] component_bind_all+0x114/0x264
[ 15.023293] vc4_drm_bind+0x160/0x2a4 [vc4]
[ 15.027565] try_to_bring_up_aggregate_device+0x1e4/0x2d0
[ 15.033044] component_master_add_with_match+0xcc/0x110
[ 15.038340] vc4_platform_drm_probe+0xc4/0xfc [vc4]
[ 15.043327] platform_probe+0x74/0xd0
[ 15.047037] really_probe+0xc8/0x3ec
[ 15.050662] __driver_probe_device+0x84/0x190
[ 15.055079] driver_probe_device+0x44/0x100
[ 15.059318] __driver_attach+0xd8/0x1d0
[ 15.063206] bus_for_each_dev+0x7c/0xe0
[ 15.067090] driver_attach+0x30/0x3c
[ 15.070711] bus_add_driver+0x188/0x244
[ 15.074595] driver_register+0x84/0x140
[ 15.078482] __platform_driver_register+0x34/0x40
[ 15.083247] vc4_drm_register+0x5c/0x1000 [vc4]
[ 15.087881] do_one_initcall+0x50/0x2bc
[ 15.091770] do_init_module+0x50/0x1f0
[ 15.095569] load_module+0x1a28/0x1fa0
[ 15.099366] __do_sys_finit_module+0xac/0x12c
[ 15.103779] __arm64_sys_finit_module+0x2c/0x40
[ 15.108368] invoke_syscall+0x50/0x120
[ 15.112166] el0_svc_common.constprop.0+0x6c/0x1b4
[ 15.117021] do_el0_svc+0x38/0xcc
[ 15.120378] el0_svc+0x30/0xd0
[ 15.123472] el0t_64_sync_handler+0x11c/0x150
[ 15.127886] el0t_64_sync+0x1a0/0x1a4
[ 15.131595] ---[ end trace ]---
git bisect pointed to 467e30171b5b ("drm/vc4: hdmi: Move HDMI reset to
pm_resume")
and reverting this commit has fixed the warning.
I will be happy to test any patch or provide any extra log if needed.
--
Regards
Sudip
Re: [PATCH v3] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
On 8/15/2022 10:08 AM, Stephen Boyd wrote: Quoting Kuogee Hsieh (2022-08-11 08:20:01) On 8/10/2022 6:00 PM, Abhinav Kumar wrote: Even then, you do have a valid point. DRM framework should not have caused the disable path to happen without an enable. I went through the stack mentioned in the issue. Lets see this part of the stack: dp_ctrl_push_idle+0x40/0x88 dp_bridge_disable+0x24/0x30 drm_atomic_bridge_chain_disable+0x90/0xbc drm_atomic_helper_commit_modeset_disables+0x198/0x444 msm_atomic_commit_tail+0x1d0/0x374 In drm_atomic_helper_commit_modeset_disables(), we call disable_outputs(). AFAICT, this is the only place which has a protection to not call the disable() flow if it was not enabled here: https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_atomic_helper.c#L1063 But that function is only checking crtc_state->active. Thats set by the usermode: https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_atomic_uapi.c#L407 Now, if usermode sets that to true and then crashed it can bypass this check and we will crash in the location kuogee is trying to fix. That seems bad, no? We don't want userspace to be able to crash and then be able to call the disable path when enable never succeeded. From the issue mentioned in https://gitlab.freedesktop.org/drm/msm/-/issues/17, the reporter did mention the usermode crashed. So this is my tentative analysis of whats happening here. Ideally yes, we should have been protected by the location mentioned above in disable_outputs() but looks to me due to the above hypothesis its getting bypassed. Can you fix the problem there? Not fixing it means that every driver out there has to develop the same "fix", when it could be fixed in the core one time. The reporter is running GNOME Display Manager (gdm3) instead of chrome. We can not duplicate this problem locally. Hence we can not confirm this is the root cause of this bug or not. Do you know who is more proper to investigate more into this? Ideally drivers are simple. They configure the hardware for what the function pointer is asking for. State management and things like that should be pushed into the core framework so that we don't have to duplicate that multiple times. Thanks Abhinav Ii sound likes that there is a hole either at user space or drm. But that should not cause dp_bridge_disable() at dp driver to crash. Agreed. Therefore it is properly to check hdp_state condition at dp_bridge_disable() to prevent it from crashing. Disagree. Userspace shouldn't be able to get drm into a wedged state. not sure for this. I agree if this is simple driver such as i2c which does not need to maintain any states during operation. but mdp/dp is far more complexity. we really do not want to have any crash happen at mdp/dp in the filed. would you please reconsider our point to add this hdp_state checking here to prevent any crash happen.
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote: > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or > > > > > handle them through "@". The latter would impact "[PATCH v1 > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as > > > > > currently a named mode and a refresh rate can't be specified both. > > > > > > > > I think the former would make more sense. It simplifies a bit the > > > > parser, and we're going to use a named mode anyway. > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a > > > > > command-line option" uses a separate "tv_mode" option, and not the > > > > > main > > > > > mode name, I think you want to add them here. > > > > > > > > It's a separate story I think, we could have a named mode hd720p50, > > > > which would be equivalent to 1280x720,tv_mode=hd720p > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"? > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p > > Above you said "I think the former would make more sense", so that > should be "1280x720,tv_mode=hd720p50"? No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p Maxime signature.asc Description: PGP signature
[linux-next:master] BUILD REGRESSION e1084bacab44f570691c0fdaa1259acf93ed0098
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: e1084bacab44f570691c0fdaa1259acf93ed0098 Add linux-next specific files for 20220816 Error/Warning reports: https://lore.kernel.org/linux-doc/202208162058.7appivkl-...@intel.com Error/Warning: (recently discovered and may have been fixed) Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/gpio/gpio-xilinx.txt drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1046:5: warning: no previous prototype for 'fill_dc_scaling_info' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1222:6: warning: no previous prototype for 'handle_cursor_update' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:152:6: warning: no previous prototype for 'modifier_has_dcc' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1576:5: warning: no previous prototype for 'amdgpu_dm_plane_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:157:10: warning: no previous prototype for 'modifier_gfx9_swizzle_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:752:5: warning: no previous prototype for 'fill_plane_buffer_attributes' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:83:31: warning: no previous prototype for 'amd_get_format_info' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:88:6: warning: no previous prototype for 'fill_blending_from_plane_state' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:992:5: warning: no previous prototype for 'dm_plane_helper_check_state' [-Wmissing-prototypes] drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:905:28: warning: variable 'top' set but not used [-Wunused-but-set-variable] include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'? Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-amd_get_format_info | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-amdgpu_dm_plane_init | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-dm_plane_helper_check_state | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_blending_from_plane_state | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_dc_scaling_info | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_plane_buffer_attributes | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-handle_cursor_update | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-modifier_gfx9_swizzle_mode | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-modifier_has_dcc | `-- drivers-gpu-drm-msm-disp-dpu1-dpu_kms.c:warning:variable-top-set-but-not-used |-- arc-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-amd_get_format_info | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-amdgpu_dm_plane_init | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-dm_plane_helper_check_state | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_blending_from_plane_state | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_dc_scaling_info | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_plane_buffer_attributes | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-handle_cursor_update | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-modifier_gfx9_swizzle_mode | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-modifier_has_dcc | `-- drivers-gpu-drm-msm-disp-dpu1-dpu_kms.c:warning:variable-top-set-but-not-used |-- arm-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-amd_get_format_info | |-- drivers-gpu-drm-amd-amdgpu
[PATCH 12/12] drm/udl: Sync pending URBs at the end of suspend
It's better to perform the sync at the very last of the suspend
instead of the pipe-disable function, so that we can catch all pending
URBs (if any).
While we're at it, drop the error code from udl_sync_pending_urb()
since we basically ignore it; instead, give a clear error message
indicating a problem.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.c | 8 +++-
drivers/gpu/drm/udl/udl_drv.h | 2 +-
drivers/gpu/drm/udl/udl_main.c| 6 ++
drivers/gpu/drm/udl/udl_modeset.c | 2 --
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 0ba88e5472a9..91effdcefb6d 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -21,8 +21,14 @@ static int udl_usb_suspend(struct usb_interface *interface,
pm_message_t message)
{
struct drm_device *dev = usb_get_intfdata(interface);
+ int ret;
- return drm_mode_config_helper_suspend(dev);
+ ret = drm_mode_config_helper_suspend(dev);
+ if (ret)
+ return ret;
+
+ udl_sync_pending_urbs(dev);
+ return 0;
}
static int udl_usb_resume(struct usb_interface *interface)
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index d943684b5bbb..b4cc7cc568c7 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -77,7 +77,7 @@ struct drm_connector *udl_connector_init(struct drm_device
*dev);
struct urb *udl_get_urb(struct drm_device *dev);
int udl_submit_urb(struct drm_device *dev, struct urb *urb, size_t len);
-int udl_sync_pending_urbs(struct drm_device *dev);
+void udl_sync_pending_urbs(struct drm_device *dev);
void udl_urb_completion(struct urb *urb);
int udl_init(struct udl_device *udl);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index c1f4b6199949..df92f6518e1c 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -294,10 +294,9 @@ int udl_submit_urb(struct drm_device *dev, struct urb
*urb, size_t len)
}
/* wait until all pending URBs have been processed */
-int udl_sync_pending_urbs(struct drm_device *dev)
+void udl_sync_pending_urbs(struct drm_device *dev)
{
struct udl_device *udl = to_udl(dev);
- int ret = 0;
spin_lock_irq(>urbs.lock);
/* 2 seconds as a sane timeout */
@@ -305,9 +304,8 @@ int udl_sync_pending_urbs(struct drm_device *dev)
udl->urbs.available == udl->urbs.count,
udl->urbs.lock,
msecs_to_jiffies(2000)))
- ret = -ETIMEDOUT;
+ drm_err(dev, "Timeout for syncing pending URBs\n");
spin_unlock_irq(>urbs.lock);
- return ret;
}
int udl_init(struct udl_device *udl)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index bca31c890108..9d72288d9967 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -391,8 +391,6 @@ udl_simple_display_pipe_disable(struct
drm_simple_display_pipe *pipe)
buf = udl_dummy_render(buf);
udl_submit_urb(dev, urb, buf - (char *)urb->transfer_buffer);
-
- udl_sync_pending_urbs(dev);
}
static void
--
2.35.3
[PATCH 07/12] drm/udl: Add parameter to set number of URBs
From: Thomas Zimmermann
For further debugging and optimization purpose, allow users to adjust
the number of URBs via a new module parameter, numurbs.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 2b7eafd48ec2..3c97f647883f 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -8,6 +8,8 @@
* Copyright (C) 2009 Bernie Thompson
*/
+#include
+
#include
#include
#include
@@ -23,6 +25,9 @@
#define WRITES_IN_FLIGHT (20)
#define MAX_VENDOR_DESCRIPTOR_SIZE 256
+static uint udl_num_urbs = WRITES_IN_FLIGHT;
+module_param_named(numurbs, udl_num_urbs, uint, 0600);
+
static int udl_parse_vendor_descriptor(struct udl_device *udl)
{
struct usb_device *udev = udl_to_usb_device(udl);
@@ -294,6 +299,8 @@ int udl_init(struct udl_device *udl)
struct drm_device *dev = >drm;
int ret = -ENOMEM;
+ drm_info(dev, "pre-allocating %d URBs\n", udl_num_urbs);
+
DRM_DEBUG("\n");
udl->dmadev = usb_intf_get_dma_device(to_usb_interface(dev->dev));
@@ -311,7 +318,7 @@ int udl_init(struct udl_device *udl)
if (udl_select_std_channel(udl))
DRM_ERROR("Selecting channel failed\n");
- if (!udl_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
+ if (!udl_alloc_urb_list(dev, udl_num_urbs, MAX_TRANSFER)) {
DRM_ERROR("udl_alloc_urb_list failed\n");
goto err;
}
--
2.35.3
[PATCH 09/12] drm/udl: Fix potential URB leaks
A couple of error handlings forgot to process the URB completion.
Those are both with WARN_ON() so should be visible, but we must fix
them in anyway.
Fixes: 7350b2a3fbc6 ("drm/udl: Replace BUG_ON() with WARN_ON()")
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 8 +---
drivers/gpu/drm/udl/udl_transfer.c | 5 -
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 3c97f647883f..8bbb4e2861fb 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -265,11 +265,13 @@ int udl_submit_urb(struct drm_device *dev, struct urb
*urb, size_t len)
struct udl_device *udl = to_udl(dev);
int ret;
- if (WARN_ON(len > udl->urbs.size))
- return -EINVAL;
-
+ if (WARN_ON(len > udl->urbs.size)) {
+ ret = -EINVAL;
+ goto error;
+ }
urb->transfer_buffer_length = len; /* set to actual payload len */
ret = usb_submit_urb(urb, GFP_ATOMIC);
+ error:
if (ret) {
udl_urb_completion(urb); /* because no one else will */
DRM_ERROR("usb_submit_urb error %x\n", ret);
diff --git a/drivers/gpu/drm/udl/udl_transfer.c
b/drivers/gpu/drm/udl/udl_transfer.c
index a431208dda85..b57844632dbd 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -180,8 +180,11 @@ int udl_render_hline(struct drm_device *dev, int log_bpp,
struct urb **urb_ptr,
u8 *cmd = *urb_buf_ptr;
u8 *cmd_end = (u8 *) urb->transfer_buffer + urb->transfer_buffer_length;
- if (WARN_ON(!(log_bpp == 1 || log_bpp == 2)))
+ if (WARN_ON(!(log_bpp == 1 || log_bpp == 2))) {
+ /* need to finish URB at error from this function */
+ udl_urb_completion(urb);
return -EINVAL;
+ }
line_start = (u8 *) (front + byte_offset);
next_pixel = line_start;
--
2.35.3
[PATCH 08/12] drm/udl: Drop unneeded alignment
The alignment of damaged area was needed for the original udlfb driver
that tried to trim the superfluous copies between front and backend
buffers and handle data in long int. It's not the case for udl DRM
driver, hence we can omit the whole unneeded alignment, as well as the
dead code.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_modeset.c | 34 ++---
drivers/gpu/drm/udl/udl_transfer.c | 40 --
2 files changed, 8 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index c34d564773a3..bca31c890108 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -243,28 +243,6 @@ static long udl_log_cpp(unsigned int cpp)
return __ffs(cpp);
}
-static int udl_aligned_damage_clip(struct drm_rect *clip, int x, int y,
- int width, int height)
-{
- int x1, x2;
-
- if (WARN_ON_ONCE(x < 0) ||
- WARN_ON_ONCE(y < 0) ||
- WARN_ON_ONCE(width < 0) ||
- WARN_ON_ONCE(height < 0))
- return -EINVAL;
-
- x1 = ALIGN_DOWN(x, sizeof(unsigned long));
- x2 = ALIGN(width + (x - x1), sizeof(unsigned long)) + x1;
-
- clip->x1 = x1;
- clip->y1 = y;
- clip->x2 = x2;
- clip->y2 = y + height;
-
- return 0;
-}
-
static int udl_handle_damage(struct drm_framebuffer *fb,
const struct iosys_map *map,
int x, int y, int width, int height)
@@ -277,15 +255,19 @@ static int udl_handle_damage(struct drm_framebuffer *fb,
struct drm_rect clip;
int log_bpp;
+ if (width <= 0 || height <= 0)
+ return 0;
+
ret = udl_log_cpp(fb->format->cpp[0]);
if (ret < 0)
return ret;
log_bpp = ret;
- ret = udl_aligned_damage_clip(, x, y, width, height);
- if (ret)
- return ret;
- else if ((clip.x2 > fb->width) || (clip.y2 > fb->height))
+ clip.x1 = x;
+ clip.y1 = y;
+ clip.x2 = x + width;
+ clip.y2 = y + height;
+ if (clip.x2 > fb->width || clip.y2 > fb->height)
return -EINVAL;
ret = drm_gem_fb_begin_cpu_access(fb, DMA_FROM_DEVICE);
diff --git a/drivers/gpu/drm/udl/udl_transfer.c
b/drivers/gpu/drm/udl/udl_transfer.c
index 176ef2a6a731..a431208dda85 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -25,46 +25,6 @@
#define MIN_RAW_PIX_BYTES 2
#define MIN_RAW_CMD_BYTES (RAW_HEADER_BYTES + MIN_RAW_PIX_BYTES)
-/*
- * Trims identical data from front and back of line
- * Sets new front buffer address and width
- * And returns byte count of identical pixels
- * Assumes CPU natural alignment (unsigned long)
- * for back and front buffer ptrs and width
- */
-#if 0
-static int udl_trim_hline(const u8 *bback, const u8 **bfront, int *width_bytes)
-{
- int j, k;
- const unsigned long *back = (const unsigned long *) bback;
- const unsigned long *front = (const unsigned long *) *bfront;
- const int width = *width_bytes / sizeof(unsigned long);
- int identical = width;
- int start = width;
- int end = width;
-
- for (j = 0; j < width; j++) {
- if (back[j] != front[j]) {
- start = j;
- break;
- }
- }
-
- for (k = width - 1; k > j; k--) {
- if (back[k] != front[k]) {
- end = k+1;
- break;
- }
- }
-
- identical = start + (width - end);
- *bfront = (u8 *) [start];
- *width_bytes = (end - start) * sizeof(unsigned long);
-
- return identical * sizeof(unsigned long);
-}
-#endif
-
static inline u16 pixel32_to_be16(const uint32_t pixel)
{
return (((pixel >> 3) & 0x001f) |
--
2.35.3
[PATCH v6] drm: Add initial ci/ subdirectory
And use it to store expectations about what the DRM drivers are
supposed to pass in the IGT test suite.
Also include a configuration file that points to the out-of-tree CI
scripts.
By storing the test expectations along the code we can make sure both
stay in sync with each other, and so we can know when a code change
breaks those expectations.
This will allow all contributors to drm to reuse the infrastructure
already in gitlab.freedesktop.org to test the driver on several
generations of the hardware.
v2:
- Fix names of result expectation files to match SoC
- Don't execute tests that are going to skip on all boards
v3:
- Remove tracking of dmesg output during test execution
v4:
- Move up to drivers/gpu/drm
- Add support for a bunch of other drivers
- Explain how to incorporate fixes for CI from a
${TARGET_BRANCH}-external-fixes branch
- Remove tests that pass from expected results file, to reduce the
size of in-tree files
- Add docs about how to deal with outages in automated testing labs
- Specify the exact SHA of the CI scripts to be used
v5:
- Remove unneeded skips from Meson expectations file
- Use a more advanced runner that detects flakes automatically
- Use a more succint format for the expectations
- Run many more tests (and use sharding to finish in time)
- Use skip lists to avoid hanging machines
- Add some build testing
- Build IGT in each pipeline for faster uprevs
- List failures in the GitLab UI
v6:
- Rebase on top of latest drm-next
- Lower priority of LAVA jobs to not impact Mesa CI as much
- Update docs
Signed-off-by: Tomeu Vizoso
Reviewed-by: Neil Armstrong
Reviewed-by: Rob Clark
---
Documentation/gpu/automated_testing.rst | 86 +++
drivers/gpu/drm/ci/amdgpu-stoney-fails.txt| 17
drivers/gpu/drm/ci/amdgpu-stoney-flakes.txt | 20 +
drivers/gpu/drm/ci/amdgpu-stoney-skips.txt| 2 +
drivers/gpu/drm/ci/gitlab-ci.yml | 13 +++
drivers/gpu/drm/ci/i915-amly-flakes.txt | 32 +++
drivers/gpu/drm/ci/i915-amly-skips.txt| 2 +
drivers/gpu/drm/ci/i915-apl-fails.txt | 29 +++
drivers/gpu/drm/ci/i915-apl-flakes.txt| 1 +
drivers/gpu/drm/ci/i915-apl-skips.txt | 2 +
drivers/gpu/drm/ci/i915-cml-flakes.txt| 36
drivers/gpu/drm/ci/i915-glk-flakes.txt| 40 +
drivers/gpu/drm/ci/i915-glk-skips.txt | 2 +
drivers/gpu/drm/ci/i915-kbl-fails.txt | 8 ++
drivers/gpu/drm/ci/i915-kbl-flakes.txt| 24 ++
drivers/gpu/drm/ci/i915-kbl-skips.txt | 2 +
drivers/gpu/drm/ci/i915-tgl-fails.txt | 19
drivers/gpu/drm/ci/i915-tgl-flakes.txt| 6 ++
drivers/gpu/drm/ci/i915-tgl-skips.txt | 8 ++
drivers/gpu/drm/ci/i915-whl-fails.txt | 30 +++
drivers/gpu/drm/ci/i915-whl-flakes.txt| 1 +
drivers/gpu/drm/ci/mediatek-mt8173-fails.txt | 29 +++
drivers/gpu/drm/ci/mediatek-mt8183-fails.txt | 10 +++
drivers/gpu/drm/ci/mediatek-mt8183-flakes.txt | 14 +++
drivers/gpu/drm/ci/meson-g12b-fails.txt | 5 ++
drivers/gpu/drm/ci/meson-g12b-flakes.txt | 4 +
drivers/gpu/drm/ci/msm-apq8016-fails.txt | 15
drivers/gpu/drm/ci/msm-apq8016-flakes.txt | 4 +
drivers/gpu/drm/ci/msm-apq8096-fails.txt | 2 +
drivers/gpu/drm/ci/msm-apq8096-flakes.txt | 4 +
drivers/gpu/drm/ci/msm-apq8096-skips.txt | 2 +
drivers/gpu/drm/ci/msm-sc7180-fails.txt | 22 +
drivers/gpu/drm/ci/msm-sc7180-flakes.txt | 14 +++
drivers/gpu/drm/ci/msm-sc7180-skips.txt | 18
drivers/gpu/drm/ci/msm-sdm845-fails.txt | 44 ++
drivers/gpu/drm/ci/msm-sdm845-flakes.txt | 33 +++
drivers/gpu/drm/ci/msm-sdm845-skips.txt | 2 +
drivers/gpu/drm/ci/rockchip-rk3288-fails.txt | 75
drivers/gpu/drm/ci/rockchip-rk3288-flakes.txt | 9 ++
drivers/gpu/drm/ci/rockchip-rk3288-skips.txt | 46 ++
drivers/gpu/drm/ci/rockchip-rk3399-fails.txt | 86 +++
drivers/gpu/drm/ci/rockchip-rk3399-flakes.txt | 26 ++
drivers/gpu/drm/ci/rockchip-rk3399-skips.txt | 5 ++
drivers/gpu/drm/ci/virtio_gpu-none-fails.txt | 38
drivers/gpu/drm/ci/virtio_gpu-none-flakes.txt | 0
drivers/gpu/drm/ci/virtio_gpu-none-skips.txt | 6 ++
46 files changed, 893 insertions(+)
create mode 100644 Documentation/gpu/automated_testing.rst
create mode 100644 drivers/gpu/drm/ci/amdgpu-stoney-fails.txt
create mode 100644 drivers/gpu/drm/ci/amdgpu-stoney-flakes.txt
create mode 100644 drivers/gpu/drm/ci/amdgpu-stoney-skips.txt
create mode 100644 drivers/gpu/drm/ci/gitlab-ci.yml
create mode 100644 drivers/gpu/drm/ci/i915-amly-flakes.txt
create mode 100644 drivers/gpu/drm/ci/i915-amly-skips.txt
create mode 100644 drivers/gpu/drm/ci/i915-apl-fails.txt
create mode 100644 drivers/gpu/drm/ci/i915-apl-flakes.txt
create mode 100644 drivers/gpu/drm/ci/i915-apl-skips.txt
create mode 100644
Re: [PATCH v7 06/13] dt-bindings: mfd: Add MediaTek MT6370
On Tue, Aug 9, 2022 at 7:14 AM Lee Jones wrote:
>
> On Fri, 05 Aug 2022, ChiaEn Wu wrote:
>
> > From: ChiYuan Huang
> >
> > Add MediaTek MT6370 binding documentation.
> >
> > Reviewed-by: Krzysztof Kozlowski
> > Signed-off-by: ChiYuan Huang
> > Signed-off-by: ChiaEn Wu
> > ---
> > .../devicetree/bindings/mfd/mediatek,mt6370.yaml | 280
> > +
> > include/dt-bindings/iio/adc/mediatek,mt6370_adc.h | 18 ++
> > 2 files changed, 298 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> > create mode 100644 include/dt-bindings/iio/adc/mediatek,mt6370_adc.h
>
> Applied, thanks.
Without the backlight schema applied, this is the result:
./Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml: Unable
to find schema file matching $id:
http://devicetree.org/schemas/leds/backlight/mediatek,mt6370-backlight.yaml
/builds/robherring/linux-dt/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
pmic@34: backlight: False schema does not allow {'compatible':
['mediatek,mt6370-backlight'], 'mediatek,bled-channel-use': b'\x0f'}
From schema:
/builds/robherring/linux-dt/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
/builds/robherring/linux-dt/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
pmic@34: charger: False schema does not allow {'compatible':
['mediatek,mt6370-charger'], 'interrupts': [[48], [68], [6]],
'interrupt-names': ['attach_i', 'uvp_d_evt', 'mivr'], 'io-channels':
[[1, 5]], 'usb-otg-vbus-regulator': {'regulator-name':
['mt6370-usb-otg-vbus'], 'regulator-min-microvolt': [[435]],
'regulator-max-microvolt': [[580]], 'regulator-min-microamp':
[[50]], 'regulator-max-microamp': [[300]], 'phandle': [[2]]}}
From schema:
/builds/robherring/linux-dt/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
/builds/robherring/linux-dt/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
pmic@34: tcpc: False schema does not allow {'compatible':
['mediatek,mt6370-tcpc'], 'interrupts-extended': [[4294967295, 4, 8]],
'connector': {'compatible': ['usb-c-connector'], 'label': ['USB-C'],
'vbus-supply': [[2]], 'data-role': ['dual'], 'power-role': ['dual'],
'try-power-role': ['sink'], 'source-pdos': [[570527844]], 'sink-pdos':
[[570527944]], 'op-sink-microwatt': [[1000]], 'ports':
{'#address-cells': [[1]], '#size-cells': [[0]], 'port@0': {'reg':
[[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}},
'port@2': {'reg': [[2]], 'endpoint': {'remote-endpoint':
[[4294967295]]}
From schema:
/builds/robherring/linux-dt/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
/builds/robherring/linux-dt/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
pmic@34: indicator: False schema does not allow {'compatible':
['mediatek,mt6370-indicator'], '#address-cells': [[1]], '#size-cells':
[[0]], 'multi-led@0': {'reg': [[0]], 'function': ['indicator'],
'color': [[9]], 'led-max-microamp': [[24000]], '#address-cells':
[[1]], '#size-cells': [[0]], 'led@0': {'reg': [[0]], 'color': [[1]]},
'led@1': {'reg': [[1]], 'color': [[2]]}, 'led@2': {'reg': [[2]],
'color': [[3]]}}, 'led@3': {'reg': [[3]], 'function': ['indicator'],
'color': [[0]], 'led-max-microamp': [[6000]]}}
From schema:
/builds/robherring/linux-dt/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
/builds/robherring/linux-dt/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
pmic@34: flashlight: False schema does not allow {'compatible':
['mediatek,mt6370-flashlight'], '#address-cells': [[1]],
'#size-cells': [[0]], 'led@0': {'reg': [[0]], 'led-sources': [[0]],
'function': ['flash'], 'color': [[0]], 'function-enumerator': [[1]],
'led-max-microamp': [[20]], 'flash-max-microamp': [[50]],
'flash-max-timeout-us': [[1248000]]}, 'led@1': {'reg': [[1]],
'led-sources': [[1]], 'function': ['flash'], 'color': [[0]],
'function-enumerator': [[2]], 'led-max-microamp': [[20]],
'flash-max-microamp': [[50]], 'flash-max-timeout-us':
[[1248000]]}}
From schema:
/builds/robherring/linux-dt/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
/builds/robherring/linux-dt/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
backlight: mediatek,bled-channel-use: b'\x0f' is not of type 'object',
'array', 'boolean', 'null'
From schema:
/usr/local/lib/python3.10/dist-packages/dtschema/schemas/dt-core.yaml
[PATCH 06/12] drm/udl: Increase the default URB list size to 20
It seems that the current size (4) for the URB list is too small on some devices, and it resulted in the occasional stalls. Increase the default URB list size to 20 for working around it. Signed-off-by: Takashi Iwai --- drivers/gpu/drm/udl/udl_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c index 6aed6e0f669c..2b7eafd48ec2 100644 --- a/drivers/gpu/drm/udl/udl_main.c +++ b/drivers/gpu/drm/udl/udl_main.c @@ -20,7 +20,7 @@ #define NR_USB_REQUEST_CHANNEL 0x12 #define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE) -#define WRITES_IN_FLIGHT (4) +#define WRITES_IN_FLIGHT (20) #define MAX_VENDOR_DESCRIPTOR_SIZE 256 static int udl_parse_vendor_descriptor(struct udl_device *udl) -- 2.35.3
[PATCH 05/12] drm/udl: Suppress error print for -EPROTO at URB completion
The driver may receive -EPROTO at the URB completion when the device
gets disconnected, and it's a normal situation. Suppress the error
print for that, too.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index a9f6b710b254..6aed6e0f669c 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -126,6 +126,7 @@ void udl_urb_completion(struct urb *urb)
if (urb->status) {
if (!(urb->status == -ENOENT ||
urb->status == -ECONNRESET ||
+ urb->status == -EPROTO ||
urb->status == -ESHUTDOWN)) {
DRM_ERROR("%s - nonzero write bulk status received:
%d\n",
__func__, urb->status);
--
2.35.3
[PATCH 10/12] drm/udl: Fix inconsistent urbs.count value during udl_free_urb_list()
In the current design, udl_get_urb() may be called asynchronously
during the driver freeing its URL list via udl_free_urb_list().
The problem is that the sync is determined by comparing the urbs.count
and urbs.available fields, while we clear urbs.count field only once
after udl_free_urb_list() finishes, i.e. during udl_free_urb_list(),
the state becomes inconsistent.
For fixing this inconsistency and also for hardening the locking
scheme, this patch does a slight refactoring of the code around
udl_get_urb() and udl_free_urb_list(). Now urbs.count is updated in
the same spinlock at extracting a URB from the list in
udl_free_url_list().
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.h | 8 +---
drivers/gpu/drm/udl/udl_main.c | 37 --
2 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 5923d2e02bc8..d943684b5bbb 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -74,13 +74,7 @@ static inline struct usb_device *udl_to_usb_device(struct
udl_device *udl)
int udl_modeset_init(struct drm_device *dev);
struct drm_connector *udl_connector_init(struct drm_device *dev);
-struct urb *udl_get_urb_timeout(struct drm_device *dev, long timeout);
-
-#define GET_URB_TIMEOUTHZ
-static inline struct urb *udl_get_urb(struct drm_device *dev)
-{
- return udl_get_urb_timeout(dev, GET_URB_TIMEOUT);
-}
+struct urb *udl_get_urb(struct drm_device *dev);
int udl_submit_urb(struct drm_device *dev, struct urb *urb, size_t len);
int udl_sync_pending_urbs(struct drm_device *dev);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 8bbb4e2861fb..19dc8317e843 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -28,6 +28,8 @@
static uint udl_num_urbs = WRITES_IN_FLIGHT;
module_param_named(numurbs, udl_num_urbs, uint, 0600);
+static struct urb *__udl_get_urb(struct udl_device *udl, long timeout);
+
static int udl_parse_vendor_descriptor(struct udl_device *udl)
{
struct usb_device *udev = udl_to_usb_device(udl);
@@ -151,15 +153,17 @@ void udl_urb_completion(struct urb *urb)
static void udl_free_urb_list(struct drm_device *dev)
{
struct udl_device *udl = to_udl(dev);
- int count = udl->urbs.count;
struct urb_node *unode;
struct urb *urb;
DRM_DEBUG("Waiting for completes and freeing all render urbs\n");
/* keep waiting and freeing, until we've got 'em all */
- while (count--) {
- urb = udl_get_urb_timeout(dev, MAX_SCHEDULE_TIMEOUT);
+ while (udl->urbs.count) {
+ spin_lock_irq(>urbs.lock);
+ urb = __udl_get_urb(udl, MAX_SCHEDULE_TIMEOUT);
+ udl->urbs.count--;
+ spin_unlock_irq(>urbs.lock);
if (WARN_ON(!urb))
break;
unode = urb->context;
@@ -169,7 +173,8 @@ static void udl_free_urb_list(struct drm_device *dev)
usb_free_urb(urb);
kfree(unode);
}
- udl->urbs.count = 0;
+
+ wake_up(>urbs.sleep);
}
static int udl_alloc_urb_list(struct drm_device *dev, int count, size_t size)
@@ -233,33 +238,43 @@ static int udl_alloc_urb_list(struct drm_device *dev, int
count, size_t size)
return udl->urbs.count;
}
-struct urb *udl_get_urb_timeout(struct drm_device *dev, long timeout)
+static struct urb *__udl_get_urb(struct udl_device *udl, long timeout)
{
- struct udl_device *udl = to_udl(dev);
- struct urb_node *unode = NULL;
+ struct urb_node *unode;
+
+ assert_spin_locked(>urbs.lock);
if (!udl->urbs.count)
return NULL;
/* Wait for an in-flight buffer to complete and get re-queued */
- spin_lock_irq(>urbs.lock);
if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
!list_empty(>urbs.list),
udl->urbs.lock, timeout)) {
DRM_INFO("wait for urb interrupted: available: %d\n",
udl->urbs.available);
- goto unlock;
+ return NULL;
}
unode = list_first_entry(>urbs.list, struct urb_node, entry);
list_del_init(>entry);
udl->urbs.available--;
-unlock:
- spin_unlock_irq(>urbs.lock);
return unode ? unode->urb : NULL;
}
+#define GET_URB_TIMEOUTHZ
+struct urb *udl_get_urb(struct drm_device *dev)
+{
+ struct udl_device *udl = to_udl(dev);
+ struct urb *urb;
+
+ spin_lock_irq(>urbs.lock);
+ urb = __udl_get_urb(udl, GET_URB_TIMEOUT);
+ spin_unlock_irq(>urbs.lock);
+ return urb;
+}
+
int udl_submit_urb(struct drm_device *dev, struct urb *urb, size_t len)
{
struct udl_device *udl = to_udl(dev);
--
2.35.3
[PATCH 11/12] drm/udl: Don't re-initialize stuff at retrying the URB list allocation
udl_alloc_urb_list() retires the allocation if there is no enough room
left, and it reinitializes the stuff unnecessarily such as the linked
list head and the waitqueue, which could be harmful. Those should be
outside the retry loop.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_main.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 19dc8317e843..c1f4b6199949 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -187,15 +187,14 @@ static int udl_alloc_urb_list(struct drm_device *dev, int
count, size_t size)
struct usb_device *udev = udl_to_usb_device(udl);
spin_lock_init(>urbs.lock);
-
-retry:
- udl->urbs.size = size;
INIT_LIST_HEAD(>urbs.list);
-
init_waitqueue_head(>urbs.sleep);
udl->urbs.count = 0;
udl->urbs.available = 0;
+retry:
+ udl->urbs.size = size;
+
while (udl->urbs.count * size < wanted_size) {
unode = kzalloc(sizeof(struct urb_node), GFP_KERNEL);
if (!unode)
--
2.35.3
[PATCH 01/12] drm/udl: Restore display mode on resume
From: Thomas Zimmermann Restore the display mode whne resuming from suspend. Currently, the display remains dark. On resume, the CRTC's mode does not change, but the 'active' flag changes to 'true'. Taking this into account when considering a mode switch restores the display mode. The bug is reproducable by using Gnome with udl and observing the adapter's suspend/resume behavior. Signed-off-by: Thomas Zimmermann Signed-off-by: Takashi Iwai --- drivers/gpu/drm/udl/udl_modeset.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/udl/udl_modeset.c b/drivers/gpu/drm/udl/udl_modeset.c index 169110d8fc2e..df987644fb5d 100644 --- a/drivers/gpu/drm/udl/udl_modeset.c +++ b/drivers/gpu/drm/udl/udl_modeset.c @@ -8,6 +8,7 @@ * Copyright (C) 2009 Bernie Thompson */ +#include #include #include #include @@ -382,7 +383,7 @@ udl_simple_display_pipe_enable(struct drm_simple_display_pipe *pipe, udl_handle_damage(fb, _plane_state->data[0], 0, 0, fb->width, fb->height); - if (!crtc_state->mode_changed) + if (!drm_atomic_crtc_needs_modeset(crtc_state)) return; /* enable display */ -- 2.35.3
[PATCH 03/12] drm/udl: Enable damage clipping
From: Thomas Zimmermann Call drm_plane_enable_fb_damage_clips() and give userspace a chance of minimizing the updated display area. Signed-off-by: Thomas Zimmermann Signed-off-by: Takashi Iwai --- drivers/gpu/drm/udl/udl_modeset.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/udl/udl_modeset.c b/drivers/gpu/drm/udl/udl_modeset.c index df987644fb5d..187aba2d7825 100644 --- a/drivers/gpu/drm/udl/udl_modeset.c +++ b/drivers/gpu/drm/udl/udl_modeset.c @@ -484,6 +484,7 @@ int udl_modeset_init(struct drm_device *dev) format_count, NULL, connector); if (ret) return ret; + drm_plane_enable_fb_damage_clips(>display_pipe.plane); drm_mode_config_reset(dev); -- 2.35.3
[PATCH 02/12] drm/udl: Add reset_resume
From: Thomas Zimmermann
Implement the reset_resume callback of struct usb_driver. Set the
standard channel when called.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.c | 11 +++
drivers/gpu/drm/udl/udl_drv.h | 1 +
drivers/gpu/drm/udl/udl_main.c | 2 +-
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 5703277c6f52..0ba88e5472a9 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -32,6 +32,16 @@ static int udl_usb_resume(struct usb_interface *interface)
return drm_mode_config_helper_resume(dev);
}
+static int udl_usb_reset_resume(struct usb_interface *interface)
+{
+ struct drm_device *dev = usb_get_intfdata(interface);
+ struct udl_device *udl = to_udl(dev);
+
+ udl_select_std_channel(udl);
+
+ return drm_mode_config_helper_resume(dev);
+}
+
/*
* FIXME: Dma-buf sharing requires DMA support by the importing device.
*This function is a workaround to make USB devices work as well.
@@ -140,6 +150,7 @@ static struct usb_driver udl_driver = {
.disconnect = udl_usb_disconnect,
.suspend = udl_usb_suspend,
.resume = udl_usb_resume,
+ .reset_resume = udl_usb_reset_resume,
.id_table = id_table,
};
module_usb_driver(udl_driver);
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 28aaf75d71cf..37c14b0ff1fc 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -95,6 +95,7 @@ int udl_render_hline(struct drm_device *dev, int log_bpp,
struct urb **urb_ptr,
u32 byte_offset, u32 device_byte_offset, u32 byte_width);
int udl_drop_usb(struct drm_device *dev);
+int udl_select_std_channel(struct udl_device *udl);
#define CMD_WRITE_RAW8 "\xAF\x60" /**< 8 bit raw write command. */
#define CMD_WRITE_RL8"\xAF\x61" /**< 8 bit run length command. */
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index fdafbf8f3c3c..7d1e6bbc165c 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -92,7 +92,7 @@ static int udl_parse_vendor_descriptor(struct udl_device *udl)
/*
* Need to ensure a channel is selected before submitting URBs
*/
-static int udl_select_std_channel(struct udl_device *udl)
+int udl_select_std_channel(struct udl_device *udl)
{
static const u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
0x1C, 0x88, 0x5E, 0x15,
--
2.35.3
[PATCH 00/12] drm/udl: More fixes
Hi, this patch set contains more fixes for UDL driver, to be applied on top of my previous patch set [*]. It covers the PM problems, regressions in the previous patch set, fixes for the stalls on some systems, as well as more hardening. Takashi [*] https://lore.kernel.org/r/20220804075826.27036-1-ti...@suse.de === Takashi Iwai (8): Revert "drm/udl: Kill pending URBs at suspend and disconnect" drm/udl: Suppress error print for -EPROTO at URB completion drm/udl: Increase the default URB list size to 20 drm/udl: Drop unneeded alignment drm/udl: Fix potential URB leaks drm/udl: Fix inconsistent urbs.count value during udl_free_urb_list() drm/udl: Don't re-initialize stuff at retrying the URB list allocation drm/udl: Sync pending URBs at the end of suspend Thomas Zimmermann (4): drm/udl: Restore display mode on resume drm/udl: Add reset_resume drm/udl: Enable damage clipping drm/udl: Add parameter to set number of URBs drivers/gpu/drm/udl/udl_drv.c | 19 +- drivers/gpu/drm/udl/udl_drv.h | 13 +--- drivers/gpu/drm/udl/udl_main.c | 97 +++--- drivers/gpu/drm/udl/udl_modeset.c | 42 - drivers/gpu/drm/udl/udl_transfer.c | 45 ++ 5 files changed, 86 insertions(+), 130 deletions(-) -- 2.35.3
Re: [EXT] Re: [PATCH 3/5] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi Nicolas,
Thanks for your comment, indeed these PR is linked to OPTEE OS.
This one is using the same bindings to define the Secure Data Path
reserved memory:
https://github.com/OP-TEE/optee_os/commit/eb108a04369fbfaf60c03c0e00bbe9489a761c69
However, I'm not aware of another shared heap that could match our
need.
For information. it was previously done using ION heap:
https://www.slideshare.net/linaroorg/bud17400-secure-data-path-with-optee
Best regards,
Olivier
On mar., 2022-08-16 at 09:31 -0400, Nicolas Dufresne wrote:
> Caution: EXT Email
>
> Hi,
>
> Le mardi 02 août 2022 à 11:58 +0200, Olivier Masse a écrit :
> > add Linaro secure heap bindings: linaro,secure-heap
>
> Just a curiosity, how is this specific to Linaro OPTEE OS ? Shouldn't
> it be "de-
> linaro-ified" somehow ?
>
> regards,
> Nicolas
>
> > use genalloc to allocate/free buffer from buffer pool.
> > buffer pool info is from dts.
> > use sg_table instore the allocated memory info, the length of
> > sg_table is 1.
> > implement secure_heap_buf_ops to implement buffer share in
> > difference device:
> > 1. Userspace passes this fd to all drivers it wants this buffer
> > to share with: First the filedescriptor is converted to a _buf
> > using
> > dma_buf_get(). Then the buffer is attached to the device using
> > dma_buf_attach().
> > 2. Once the buffer is attached to all devices userspace can
> > initiate DMA
> > access to the shared buffer. In the kernel this is done by calling
> > dma_buf_map_attachment()
> > 3. get sg_table with dma_buf_map_attachment in difference device.
> >
> > Signed-off-by: Olivier Masse
> > ---
> > drivers/dma-buf/heaps/Kconfig | 21 +-
> > drivers/dma-buf/heaps/Makefile | 1 +
> > drivers/dma-buf/heaps/secure_heap.c | 588
> >
> > 3 files changed, 606 insertions(+), 4 deletions(-)
> > create mode 100644 drivers/dma-buf/heaps/secure_heap.c
> >
> > diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-
> > buf/heaps/Kconfig
> > index 6a33193a7b3e..b2406932192e 100644
> > --- a/drivers/dma-buf/heaps/Kconfig
> > +++ b/drivers/dma-buf/heaps/Kconfig
> > @@ -1,8 +1,12 @@
> > -config DMABUF_HEAPS_DEFERRED_FREE
> > - tristate
> > +menuconfig DMABUF_HEAPS_DEFERRED_FREE
> > + bool "DMA-BUF heaps deferred-free library"
> > + help
> > + Choose this option to enable the DMA-BUF heaps deferred-
> > free library.
> >
> > -config DMABUF_HEAPS_PAGE_POOL
> > - tristate
> > +menuconfig DMABUF_HEAPS_PAGE_POOL
> > + bool "DMA-BUF heaps page-pool library"
> > + help
> > + Choose this option to enable the DMA-BUF heaps page-pool
> > library.
> >
> > config DMABUF_HEAPS_SYSTEM
> > bool "DMA-BUF System Heap"
> > @@ -26,3 +30,12 @@ config DMABUF_HEAPS_DSP
> >Choose this option to enable the dsp dmabuf heap. The
> > dsp heap
> >is allocated by gen allocater. it's allocated according
> > the dts.
> >If in doubt, say Y.
> > +
> > +config DMABUF_HEAPS_SECURE
> > + tristate "DMA-BUF Secure Heap"
> > + depends on DMABUF_HEAPS && DMABUF_HEAPS_DEFERRED_FREE
> > + help
> > + Choose this option to enable the secure dmabuf heap. The
> > secure heap
> > + pools are defined according to the DT. Heaps are allocated
> > + in the pools using gen allocater.
> > + If in doubt, say Y.
> > diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-
> > buf/heaps/Makefile
> > index e70722ea615e..08f6aa5919d1 100644
> > --- a/drivers/dma-buf/heaps/Makefile
> > +++ b/drivers/dma-buf/heaps/Makefile
> > @@ -4,3 +4,4 @@ obj-$(CONFIG_DMABUF_HEAPS_PAGE_POOL) +=
> > page_pool.o
> > obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> > obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> > obj-$(CONFIG_DMABUF_HEAPS_DSP) += dsp_heap.o
> > +obj-$(CONFIG_DMABUF_HEAPS_SECURE)+= secure_heap.o
> > diff --git a/drivers/dma-buf/heaps/secure_heap.c b/drivers/dma-
> > buf/heaps/secure_heap.c
> > new file mode 100644
> > index ..31aac5d050b4
> > --- /dev/null
> > +++ b/drivers/dma-buf/heaps/secure_heap.c
> > @@ -0,0 +1,588 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * DMABUF secure heap exporter
> > + *
> > + * Copyright 2021 NXP.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "deferred-free-helper.h"
> > +#include "page_pool.h"
> > +
> > +#define MAX_SECURE_HEAP 2
> > +#define MAX_HEAP_NAME_LEN 32
> > +
> > +struct secure_heap_buffer {
> > + struct dma_heap *heap;
> > + struct list_head attachments;
> > + struct mutex lock;
> > + unsigned long len;
> > + struct sg_table sg_table;
> > + int vmap_cnt;
> > + struct deferred_freelist_item deferred_free;
> > + void *vaddr;
> > + bool uncached;
> > +};
> > +
> > +struct
Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
Hi Maxime,
On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard wrote:
> On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard wrote:
> > > Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> > > modes in the drivers.
> >
> > Nit: strictly speaking these are not analog modes, but the digital
> > variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a
> > 13.5 MHz sampling frequency for pixels.
> >
> > In analog modes, the only discrete values are the number of lines, and
> > the frame/field rate (fixing the horizontal sync rate when combined).
> >
> > The number of (in)visible pixels per line depends on the available
> > bandwidth. In a digital variant (which is anything generated by a
> > digital computer system), the latter depends on the pixel clock, which
> > can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g.
> > Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)).
> >
> > So I think we probably need some way to generate a PAL/NTSC-compatible
> > mode based not only on resolution, but also on pixel clock.
>
> This would also fix the comments made by Jani and Thomas, so I quite
> like the idea of it.
>
> I'm struggling a bit to find how would could implement this though.
>
> From what you were saying, I guess the prototype would be something like
>
> struct drm_display_mode *drm_create_analog_mode(unsigned int pixel_clock,
> unsigned int lines,
> unsigned int frame_rate)
>
> But I have zero idea on what the implementation would be. Do you have
> some resources for this you could point me to?
Horizontally, I think you should calculate left/right margins and
hsync length to yield timings that match those for the BT.656 PAL/NTSC
modes. I.e. when a 640x512 mode with a pixel clock of 14 MHz is
requested, you want to calculate left', right', and hslen' for
| < left' ---> | <- 640 pixels -> | < right' ---> | <--- hslen' --> |
@ 14 MHz
so they match the timings for left, right, and hslen for
| <--- left ---> | <--- 720 pixels ---> | <--- right ---> | <--- hslen ---> |
@ 13.5 MHz
As 640 pixels @ 14 MHz are less wide than 720 pixels @ 13.5 MHz,
you want to make sure to align the center of the visible part.
Vertically, it's simpler, as the number of lines is discrete.
You do have to take into account interlace and doublescan, and
progressive modes with 262/312 lines.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
Hi Maxime,
On Tue, Aug 16, 2022 at 4:11 PM Maxime Ripard wrote:
> On Tue, Aug 16, 2022 at 03:29:07PM +0200, Geert Uytterhoeven wrote:
> > On Tue, Aug 16, 2022 at 3:20 PM Maxime Ripard wrote:
> > > On Fri, Aug 12, 2022 at 03:25:18PM +0200, Geert Uytterhoeven wrote:
> > > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > > @@ -1649,11 +1650,40 @@
> > > > > EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
> > > > > * 0 on success or a negative error code on failure.
> > > > > */
> > > > > int drm_mode_create_tv_properties(struct drm_device *dev,
> > > > > + unsigned int supported_tv_norms,
> > > > > unsigned int num_modes,
> > > > > const char * const modes[])
> > > > > {
> > > > > + static const struct drm_prop_enum_list tv_norm_values[] = {
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1,
> > > > > "NTSC-443" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1,
> > > > > "NTSC-J" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1,
> > > > > "NTSC-M" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1,
> > > > > "PAL-60" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B"
> > > > > },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D"
> > > > > },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G"
> > > > > },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H"
> > > > > },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I"
> > > > > },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M"
> > > > > },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N"
> > > > > },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1,
> > > > > "PAL-Nc" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1,
> > > > > "SECAM-60" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1,
> > > > > "SECAM-B" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1,
> > > > > "SECAM-D" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1,
> > > > > "SECAM-G" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1,
> > > > > "SECAM-K" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1,
> > > > > "SECAM-K1" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1,
> > > > > "SECAM-L" },
> > > >
> > > > The above are analog standards, with a variable horizontal resolution.
> > > >
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1,
> > > > > "hd480i" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1,
> > > > > "hd480p" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1,
> > > > > "hd576i" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1,
> > > > > "hd576p" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1,
> > > > > "hd720p" },
> > > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1,
> > > > > "hd1080i" },
> > > >
> > > > The above are digital standards, with a fixed resolution.
> > >
> > > Are they?
> > >
> > > It's not clear to me from looking at nouveau, but I was under the
> > > impression that they were modes for a component output, so CEA 770.3. I
> > > don't have the spec though, so I can't check.
> >
> > Oh right, I forgot about analog HD over component, where you can use
> > other pixel clocks than in the digital standard.
> >
> > > > You seem to have missed "hd1080p"?
> > >
> > > Nobody is using it. If we ever have a driver that uses it I think we can
> > > add it.
> >
> > The PS3 supports 1080p over component
> > https://manuals.playstation.net/document/en/ps3/current/settings/videooutput.html
>
> Yeah, and iirc the Xbox360 did too, but what I meant by nobody is using
> it is that there's no driver using it currently.
OK, it can be added later.
> > > > In addition, "hd720p", "hd080i", and "hd1080p" are available in both 50
> > > > and 60 (actually 59.94) Hz, while "hd1080p" can also use 24 or 25 Hz.
> > >
> > > It looks like nouveau only exposes modes for 480p at 59.94Hz, 576p at
> > > 50Hz, 720p at 60Hz, 1080i at 30Hz.
> >
> > PS3 supports both 50 and 60 Hz (same link above).
>
> I'm probably wary on this, but I'd rather stay at feature parity for
> this series. There's already plenty of occasion to screw up something
> that I'd rather not introduce new stuff I haven't been able to test :)
>
> Provided we can easily extend it to support these additional features of
> course :)
>
> > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > >
Re: [PATCH v1 09/35] drm/modes: Move named modes parsing to a separate function
Hi Maxime,
On Tue, Aug 16, 2022 at 3:46 PM Maxime Ripard wrote:
> On Fri, Aug 12, 2022 at 03:27:17PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Jul 29, 2022 at 6:36 PM Maxime Ripard wrote:
> > > The current construction of the named mode parsing doesn't allow to extend
> > > it easily. Let's move it to a separate function so we can add more
> > > parameters and modes.
> > >
> > > Signed-off-by: Maxime Ripard
> >
> > Thanks for your patch, which looks similar to my "[PATCH v2 2/5]
> > drm/modes: Extract drm_mode_parse_cmdline_named_mode()"
> > (https://lore.kernel.org/dri-devel/1371554419ae63cb54c2a377db0c1016fcf200bb.1657788997.git.ge...@linux-m68k.org
> > ;-)
>
> Indeed, I forgot about that one, sorry :/
>
> I think I'd still prefer to have the check for refresh + named mode
> outside of the function, since I see them as an "integration" issue, not
> a parsing one.
>
> It's not the named mode parsing that fails, but the fact that we both
> have a valid refresh and a valid named mode.
>
> >
> > > --- a/drivers/gpu/drm/drm_modes.c
> > > +++ b/drivers/gpu/drm/drm_modes.c
> > > @@ -1773,6 +1773,28 @@ static const char * const
> > > drm_named_modes_whitelist[] = {
> > > "PAL",
> > > };
> > >
> > > +static bool drm_mode_parse_cmdline_named_mode(const char *name,
> > > + unsigned int name_end,
> > > + struct drm_cmdline_mode
> > > *cmdline_mode)
> > > +{
> > > + unsigned int i;
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> > > + int ret;
> > > +
> > > + ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> > > + if (ret != name_end)
> > > + continue;
> > > +
> > > + strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
> > > + cmdline_mode->specified = true;
> > > +
> > > + return true;
> > > + }
> > > +
> > > + return false;
> >
> > What's the point in returning a value, if it is never checked?
> > Just make this function return void?
>
> Yeah, it's something I went back and forth to between the dev, and it's
> an artifact.
>
> I'll drop that patch, take your version and move the refresh check to
> drm_mode_parse_command_line_for_connector if that's alright for you?
Fine for me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/3] dma-buf: Add ioctl to query mmap coherency/cache info
On Tue, Aug 16, 2022 at 1:27 AM Christian König
wrote:
>
> Am 15.08.22 um 23:15 schrieb Rob Clark:
> > From: Rob Clark
> >
> > This is a fairly narrowly focused interface, providing a way for a VMM
> > in userspace to tell the guest kernel what pgprot settings to use when
> > mapping a buffer to guest userspace.
> >
> > For buffers that get mapped into guest userspace, virglrenderer returns
> > a dma-buf fd to the VMM (crosvm or qemu). In addition to mapping the
> > pages into the guest VM, it needs to report to drm/virtio in the guest
> > the cache settings to use for guest userspace. In particular, on some
> > architectures, creating aliased mappings with different cache attributes
> > is frowned upon, so it is important that the guest mappings have the
> > same cache attributes as any potential host mappings.
> >
> > Signed-off-by: Rob Clark
> > ---
> > v2: Combine with coherency, as that is a related concept.. and it is
> > relevant to the VMM whether coherent access without the SYNC ioctl
> > is possible; set map_info at export time to make it more clear
> > that it applies for the lifetime of the dma-buf (for any mmap
> > created via the dma-buf)
>
> Well, exactly that's a conceptual NAK from my side.
>
> The caching information can change at any time. For CPU mappings even
> without further notice from the exporter.
You should look before you criticize, as I left you a way out.. the
idea was that DMA_BUF_MAP_INCOHERENT should indicate that the buffer
cannot be mapped to the guest. We could ofc add more DMA_BUF_MAP_*
values if something else would suit you better. But the goal is to
give the VMM enough information to dtrt, or return an error if mapping
to guest is not possible. That seems better than assuming mapping to
guest will work and guessing about cache attrs
BR,
-R
> If the hardware can't use the caching information from the host CPU page
> tables directly then that pretty much completely breaks the concept that
> the exporter is responsible for setting up those page tables.
>
> Regards,
> Christian.
>
> >
> > drivers/dma-buf/dma-buf.c| 63 +++--
> > include/linux/dma-buf.h | 11 ++
> > include/uapi/linux/dma-buf.h | 68
> > 3 files changed, 132 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 32f55640890c..262c4706f721 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -125,6 +125,32 @@ static struct file_system_type dma_buf_fs_type = {
> > .kill_sb = kill_anon_super,
> > };
> >
> > +static int __dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct
> > *vma)
> > +{
> > + int ret;
> > +
> > + /* check if buffer supports mmap */
> > + if (!dmabuf->ops->mmap)
> > + return -EINVAL;
> > +
> > + ret = dmabuf->ops->mmap(dmabuf, vma);
> > +
> > + /*
> > + * If the exporter claims to support coherent access, ensure the
> > + * pgprot flags match the claim.
> > + */
> > + if ((dmabuf->map_info != DMA_BUF_MAP_INCOHERENT) && !ret) {
> > + pgprot_t wc_prot = pgprot_writecombine(vma->vm_page_prot);
> > + if (dmabuf->map_info == DMA_BUF_COHERENT_WC) {
> > + WARN_ON_ONCE(pgprot_val(vma->vm_page_prot) !=
> > pgprot_val(wc_prot));
> > + } else {
> > + WARN_ON_ONCE(pgprot_val(vma->vm_page_prot) ==
> > pgprot_val(wc_prot));
> > + }
> > + }
> > +
> > + return ret;
> > +}
> > +
> > static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct
> > *vma)
> > {
> > struct dma_buf *dmabuf;
> > @@ -134,16 +160,12 @@ static int dma_buf_mmap_internal(struct file *file,
> > struct vm_area_struct *vma)
> >
> > dmabuf = file->private_data;
> >
> > - /* check if buffer supports mmap */
> > - if (!dmabuf->ops->mmap)
> > - return -EINVAL;
> > -
> > /* check for overflowing the buffer's size */
> > if (vma->vm_pgoff + vma_pages(vma) >
> > dmabuf->size >> PAGE_SHIFT)
> > return -EINVAL;
> >
> > - return dmabuf->ops->mmap(dmabuf, vma);
> > + return __dma_buf_mmap(dmabuf, vma);
> > }
> >
> > static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
> > @@ -326,6 +348,27 @@ static long dma_buf_set_name(struct dma_buf *dmabuf,
> > const char __user *buf)
> > return 0;
> > }
> >
> > +static long dma_buf_info(struct dma_buf *dmabuf, void __user *uarg)
> > +{
> > + struct dma_buf_info arg;
> > +
> > + if (copy_from_user(, uarg, sizeof(arg)))
> > + return -EFAULT;
> > +
> > + switch (arg.param) {
> > + case DMA_BUF_INFO_MAP_INFO:
> > + arg.value = dmabuf->map_info;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + if (copy_to_user(uarg, ,
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
On Tue, Aug 16, 2022 at 03:29:07PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Tue, Aug 16, 2022 at 3:20 PM Maxime Ripard wrote:
> > On Fri, Aug 12, 2022 at 03:25:18PM +0200, Geert Uytterhoeven wrote:
> > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > @@ -1649,11 +1650,40 @@
> > > > EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
> > > > * 0 on success or a negative error code on failure.
> > > > */
> > > > int drm_mode_create_tv_properties(struct drm_device *dev,
> > > > + unsigned int supported_tv_norms,
> > > > unsigned int num_modes,
> > > > const char * const modes[])
> > > > {
> > > > + static const struct drm_prop_enum_list tv_norm_values[] = {
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1,
> > > > "NTSC-443" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J"
> > > > },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M"
> > > > },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60"
> > > > },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc"
> > > > },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1,
> > > > "SECAM-60" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1,
> > > > "SECAM-B" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1,
> > > > "SECAM-D" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1,
> > > > "SECAM-G" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1,
> > > > "SECAM-K" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1,
> > > > "SECAM-K1" },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1,
> > > > "SECAM-L" },
> > >
> > > The above are analog standards, with a variable horizontal resolution.
> > >
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i"
> > > > },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p"
> > > > },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i"
> > > > },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p"
> > > > },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p"
> > > > },
> > > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1,
> > > > "hd1080i" },
> > >
> > > The above are digital standards, with a fixed resolution.
> >
> > Are they?
> >
> > It's not clear to me from looking at nouveau, but I was under the
> > impression that they were modes for a component output, so CEA 770.3. I
> > don't have the spec though, so I can't check.
>
> Oh right, I forgot about analog HD over component, where you can use
> other pixel clocks than in the digital standard.
>
> > > You seem to have missed "hd1080p"?
> >
> > Nobody is using it. If we ever have a driver that uses it I think we can
> > add it.
>
> The PS3 supports 1080p over component
> https://manuals.playstation.net/document/en/ps3/current/settings/videooutput.html
Yeah, and iirc the Xbox360 did too, but what I meant by nobody is using
it is that there's no driver using it currently.
> > > In addition, "hd720p", "hd080i", and "hd1080p" are available in both 50
> > > and 60 (actually 59.94) Hz, while "hd1080p" can also use 24 or 25 Hz.
> >
> > It looks like nouveau only exposes modes for 480p at 59.94Hz, 576p at
> > 50Hz, 720p at 60Hz, 1080i at 30Hz.
>
> PS3 supports both 50 and 60 Hz (same link above).
I'm probably wary on this, but I'd rather stay at feature parity for
this series. There's already plenty of occasion to screw up something
that I'd rather not introduce new stuff I haven't been able to test :)
Provided we can easily extend it to support these additional features of
course :)
> > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > handle them through "@". The latter would impact "[PATCH v1
> > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > currently a named mode and a refresh rate can't be specified both.
> >
> > I think the former would make more sense. It simplifies a bit the
> > parser, and we're going to use a named mode anyway.
> >
Re: [PATCH 3/4] drm/udl: Kill pending URBs at suspend and disconnect
On Tue, 16 Aug 2022 16:01:34 +0200,
Thomas Zimmermann wrote:
>
> Hi Takashi
>
> Am 16.08.22 um 15:55 schrieb Takashi Iwai:
> > On Tue, 09 Aug 2022 11:19:30 +0200,
> > Takashi Iwai wrote:
> >>
> >> On Tue, 09 Aug 2022 11:13:46 +0200,
> >> Thomas Zimmermann wrote:
> >>>
> >>> Hi
> >>>
> >>> Am 09.08.22 um 11:03 schrieb Takashi Iwai:
> On Tue, 09 Aug 2022 09:41:19 +0200,
> Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 09.08.22 um 09:15 schrieb Takashi Iwai:
> >> On Tue, 09 Aug 2022 09:13:16 +0200,
> >> Thomas Zimmermann wrote:
> >>>
> >>> Hi
> >>>
> >>> Am 04.08.22 um 09:58 schrieb Takashi Iwai:
> At both suspend and disconnect, we should rather cancel the pending
> URBs immediately. For the suspend case, the display will be turned
> off, so it makes no sense to process the rendering. And for the
> disconnect case, the device may be no longer accessible, hence we
> shouldn't do any submission.
>
> Tested-by: Thomas Zimmermann
> Signed-off-by: Takashi Iwai
> ---
> drivers/gpu/drm/udl/udl_drv.h | 2 ++
> drivers/gpu/drm/udl/udl_main.c| 25 ++---
> drivers/gpu/drm/udl/udl_modeset.c | 2 ++
> 3 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.h
> b/drivers/gpu/drm/udl/udl_drv.h
> index f01e50c5b7b7..28aaf75d71cf 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -39,6 +39,7 @@ struct urb_node {
> struct urb_list {
> struct list_head list;
> +struct list_head in_flight;
> spinlock_t lock;
> wait_queue_head_t sleep;
> int available;
> @@ -84,6 +85,7 @@ static inline struct urb *udl_get_urb(struct
> drm_device *dev)
> int udl_submit_urb(struct drm_device *dev, struct urb *urb,
> size_t len);
> int udl_sync_pending_urbs(struct drm_device *dev);
> +void udl_kill_pending_urbs(struct drm_device *dev);
> void udl_urb_completion(struct urb *urb);
> int udl_init(struct udl_device *udl);
> diff --git a/drivers/gpu/drm/udl/udl_main.c
> b/drivers/gpu/drm/udl/udl_main.c
> index 93615648414b..47204b7eb10e 100644
> --- a/drivers/gpu/drm/udl/udl_main.c
> +++ b/drivers/gpu/drm/udl/udl_main.c
> @@ -135,7 +135,7 @@ void udl_urb_completion(struct urb *urb)
> urb->transfer_buffer_length = udl->urbs.size; /* reset
> to actual */
> spin_lock_irqsave(>urbs.lock, flags);
> -list_add_tail(>entry, >urbs.list);
> +list_move(>entry, >urbs.list);
> udl->urbs.available++;
> spin_unlock_irqrestore(>urbs.lock, flags);
> @@ -180,6 +180,7 @@ static int udl_alloc_urb_list(struct
> drm_device *dev, int count, size_t size)
> retry:
> udl->urbs.size = size;
> INIT_LIST_HEAD(>urbs.list);
> +INIT_LIST_HEAD(>urbs.in_flight);
> init_waitqueue_head(>urbs.sleep);
> udl->urbs.count = 0;
> @@ -246,7 +247,7 @@ struct urb *udl_get_urb_timeout(struct
> drm_device *dev, long timeout)
> }
> unode = list_first_entry(>urbs.list, struct
> urb_node,
> entry);
> -list_del_init(>entry);
> +list_move(>entry, >urbs.in_flight);
> udl->urbs.available--;
> unlock:
> @@ -279,7 +280,7 @@ int udl_sync_pending_urbs(struct drm_device *dev)
> spin_lock_irq(>urbs.lock);
> /* 2 seconds as a sane timeout */
> if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
> - udl->urbs.available ==
> udl->urbs.count,
> +
> list_empty(>urbs.in_flight),
> udl->urbs.lock,
>
> msecs_to_jiffies(2000)))
> ret = -ETIMEDOUT;
> @@ -287,6 +288,23 @@ int udl_sync_pending_urbs(struct drm_device
> *dev)
> return ret;
> }
> +/* kill pending URBs */
> +void udl_kill_pending_urbs(struct drm_device *dev)
> +{
> +struct udl_device *udl = to_udl(dev);
> +struct urb_node *unode;
> +
> +spin_lock_irq(>urbs.lock);
> +
Re: [PATCH 3/4] drm/udl: Kill pending URBs at suspend and disconnect
Hi Takashi
Am 16.08.22 um 15:55 schrieb Takashi Iwai:
On Tue, 09 Aug 2022 11:19:30 +0200,
Takashi Iwai wrote:
On Tue, 09 Aug 2022 11:13:46 +0200,
Thomas Zimmermann wrote:
Hi
Am 09.08.22 um 11:03 schrieb Takashi Iwai:
On Tue, 09 Aug 2022 09:41:19 +0200,
Thomas Zimmermann wrote:
Hi
Am 09.08.22 um 09:15 schrieb Takashi Iwai:
On Tue, 09 Aug 2022 09:13:16 +0200,
Thomas Zimmermann wrote:
Hi
Am 04.08.22 um 09:58 schrieb Takashi Iwai:
At both suspend and disconnect, we should rather cancel the pending
URBs immediately. For the suspend case, the display will be turned
off, so it makes no sense to process the rendering. And for the
disconnect case, the device may be no longer accessible, hence we
shouldn't do any submission.
Tested-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.h | 2 ++
drivers/gpu/drm/udl/udl_main.c| 25 ++---
drivers/gpu/drm/udl/udl_modeset.c | 2 ++
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index f01e50c5b7b7..28aaf75d71cf 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -39,6 +39,7 @@ struct urb_node {
struct urb_list {
struct list_head list;
+ struct list_head in_flight;
spinlock_t lock;
wait_queue_head_t sleep;
int available;
@@ -84,6 +85,7 @@ static inline struct urb *udl_get_urb(struct drm_device *dev)
int udl_submit_urb(struct drm_device *dev, struct urb *urb,
size_t len);
int udl_sync_pending_urbs(struct drm_device *dev);
+void udl_kill_pending_urbs(struct drm_device *dev);
void udl_urb_completion(struct urb *urb);
int udl_init(struct udl_device *udl);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 93615648414b..47204b7eb10e 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -135,7 +135,7 @@ void udl_urb_completion(struct urb *urb)
urb->transfer_buffer_length = udl->urbs.size; /* reset to actual */
spin_lock_irqsave(>urbs.lock, flags);
- list_add_tail(>entry, >urbs.list);
+ list_move(>entry, >urbs.list);
udl->urbs.available++;
spin_unlock_irqrestore(>urbs.lock, flags);
@@ -180,6 +180,7 @@ static int udl_alloc_urb_list(struct
drm_device *dev, int count, size_t size)
retry:
udl->urbs.size = size;
INIT_LIST_HEAD(>urbs.list);
+ INIT_LIST_HEAD(>urbs.in_flight);
init_waitqueue_head(>urbs.sleep);
udl->urbs.count = 0;
@@ -246,7 +247,7 @@ struct urb *udl_get_urb_timeout(struct drm_device *dev,
long timeout)
}
unode = list_first_entry(>urbs.list, struct urb_node,
entry);
- list_del_init(>entry);
+ list_move(>entry, >urbs.in_flight);
udl->urbs.available--;
unlock:
@@ -279,7 +280,7 @@ int udl_sync_pending_urbs(struct drm_device *dev)
spin_lock_irq(>urbs.lock);
/* 2 seconds as a sane timeout */
if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
-udl->urbs.available == udl->urbs.count,
+list_empty(>urbs.in_flight),
udl->urbs.lock,
msecs_to_jiffies(2000)))
ret = -ETIMEDOUT;
@@ -287,6 +288,23 @@ int udl_sync_pending_urbs(struct drm_device *dev)
return ret;
}
+/* kill pending URBs */
+void udl_kill_pending_urbs(struct drm_device *dev)
+{
+ struct udl_device *udl = to_udl(dev);
+ struct urb_node *unode;
+
+ spin_lock_irq(>urbs.lock);
+ while (!list_empty(>urbs.in_flight)) {
+ unode = list_first_entry(>urbs.in_flight,
+struct urb_node, entry);
+ spin_unlock_irq(>urbs.lock);
+ usb_kill_urb(unode->urb);
+ spin_lock_irq(>urbs.lock);
+ }
+ spin_unlock_irq(>urbs.lock);
+}
+
int udl_init(struct udl_device *udl)
{
struct drm_device *dev = >drm;
@@ -335,6 +353,7 @@ int udl_drop_usb(struct drm_device *dev)
{
struct udl_device *udl = to_udl(dev);
+ udl_kill_pending_urbs(dev);
udl_free_urb_list(dev);
put_device(udl->dmadev);
udl->dmadev = NULL;
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 50025606b6ad..169110d8fc2e 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -397,6 +397,8 @@ udl_simple_display_pipe_disable(struct
drm_simple_display_pipe *pipe)
struct urb *urb;
char *buf;
+ udl_kill_pending_urbs(dev);
+
I already reviewed the patchset, but I have another comment. I think
we should only kill urbs from within the suspend handler. Same for the
call to the URB-sync function in patch 2.
This disable function is part of
Re: [PATCH 3/4] drm/udl: Kill pending URBs at suspend and disconnect
On Tue, 09 Aug 2022 11:19:30 +0200,
Takashi Iwai wrote:
>
> On Tue, 09 Aug 2022 11:13:46 +0200,
> Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 09.08.22 um 11:03 schrieb Takashi Iwai:
> > > On Tue, 09 Aug 2022 09:41:19 +0200,
> > > Thomas Zimmermann wrote:
> > >>
> > >> Hi
> > >>
> > >> Am 09.08.22 um 09:15 schrieb Takashi Iwai:
> > >>> On Tue, 09 Aug 2022 09:13:16 +0200,
> > >>> Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 04.08.22 um 09:58 schrieb Takashi Iwai:
> > > At both suspend and disconnect, we should rather cancel the pending
> > > URBs immediately. For the suspend case, the display will be turned
> > > off, so it makes no sense to process the rendering. And for the
> > > disconnect case, the device may be no longer accessible, hence we
> > > shouldn't do any submission.
> > >
> > > Tested-by: Thomas Zimmermann
> > > Signed-off-by: Takashi Iwai
> > > ---
> > > drivers/gpu/drm/udl/udl_drv.h | 2 ++
> > > drivers/gpu/drm/udl/udl_main.c| 25 ++---
> > > drivers/gpu/drm/udl/udl_modeset.c | 2 ++
> > > 3 files changed, 26 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/udl/udl_drv.h
> > > b/drivers/gpu/drm/udl/udl_drv.h
> > > index f01e50c5b7b7..28aaf75d71cf 100644
> > > --- a/drivers/gpu/drm/udl/udl_drv.h
> > > +++ b/drivers/gpu/drm/udl/udl_drv.h
> > > @@ -39,6 +39,7 @@ struct urb_node {
> > > struct urb_list {
> > > struct list_head list;
> > > + struct list_head in_flight;
> > > spinlock_t lock;
> > > wait_queue_head_t sleep;
> > > int available;
> > > @@ -84,6 +85,7 @@ static inline struct urb *udl_get_urb(struct
> > > drm_device *dev)
> > > int udl_submit_urb(struct drm_device *dev, struct urb *urb,
> > > size_t len);
> > > int udl_sync_pending_urbs(struct drm_device *dev);
> > > +void udl_kill_pending_urbs(struct drm_device *dev);
> > > void udl_urb_completion(struct urb *urb);
> > > int udl_init(struct udl_device *udl);
> > > diff --git a/drivers/gpu/drm/udl/udl_main.c
> > > b/drivers/gpu/drm/udl/udl_main.c
> > > index 93615648414b..47204b7eb10e 100644
> > > --- a/drivers/gpu/drm/udl/udl_main.c
> > > +++ b/drivers/gpu/drm/udl/udl_main.c
> > > @@ -135,7 +135,7 @@ void udl_urb_completion(struct urb *urb)
> > > urb->transfer_buffer_length = udl->urbs.size; /* reset to
> > > actual */
> > > spin_lock_irqsave(>urbs.lock, flags);
> > > - list_add_tail(>entry, >urbs.list);
> > > + list_move(>entry, >urbs.list);
> > > udl->urbs.available++;
> > > spin_unlock_irqrestore(>urbs.lock, flags);
> > > @@ -180,6 +180,7 @@ static int udl_alloc_urb_list(struct
> > > drm_device *dev, int count, size_t size)
> > > retry:
> > > udl->urbs.size = size;
> > > INIT_LIST_HEAD(>urbs.list);
> > > + INIT_LIST_HEAD(>urbs.in_flight);
> > > init_waitqueue_head(>urbs.sleep);
> > > udl->urbs.count = 0;
> > > @@ -246,7 +247,7 @@ struct urb *udl_get_urb_timeout(struct drm_device
> > > *dev, long timeout)
> > > }
> > > unode = list_first_entry(>urbs.list, struct
> > > urb_node,
> > > entry);
> > > - list_del_init(>entry);
> > > + list_move(>entry, >urbs.in_flight);
> > > udl->urbs.available--;
> > > unlock:
> > > @@ -279,7 +280,7 @@ int udl_sync_pending_urbs(struct drm_device *dev)
> > > spin_lock_irq(>urbs.lock);
> > > /* 2 seconds as a sane timeout */
> > > if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
> > > - udl->urbs.available ==
> > > udl->urbs.count,
> > > +
> > > list_empty(>urbs.in_flight),
> > >udl->urbs.lock,
> > >msecs_to_jiffies(2000)))
> > > ret = -ETIMEDOUT;
> > > @@ -287,6 +288,23 @@ int udl_sync_pending_urbs(struct drm_device *dev)
> > > return ret;
> > > }
> > > +/* kill pending URBs */
> > > +void udl_kill_pending_urbs(struct drm_device *dev)
> > > +{
> > > + struct udl_device *udl = to_udl(dev);
> > > + struct urb_node *unode;
> > > +
> > > + spin_lock_irq(>urbs.lock);
> > > + while (!list_empty(>urbs.in_flight)) {
> > > + unode = list_first_entry(>urbs.in_flight,
> > > + struct urb_node, entry);
> > > + spin_unlock_irq(>urbs.lock);
> > > + usb_kill_urb(unode->urb);
> > > + spin_lock_irq(>urbs.lock);
> > > + }
> > > + spin_unlock_irq(>urbs.lock);
> >
Re: [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option
On Fri, Aug 12, 2022 at 03:31:19PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Fri, Jul 29, 2022 at 6:37 PM Maxime Ripard wrote:
> > Our new tv mode option allows to specify the TV mode from a property.
> > However, it can still be useful, for example to avoid any boot time
> > artifact, to set that property directly from the kernel command line.
> >
> > Let's add some code to allow it, and some unit tests to exercise that code.
> >
> > Signed-off-by: Maxime Ripard
>
> Thanks for your patch!
>
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1677,6 +1677,80 @@ static int drm_mode_parse_panel_orientation(const
> > char *delim,
> > return 0;
> > }
> >
> > +#define TV_OPTION_EQUAL(value, len, option) \
> > + ((strlen(option) == len) && !strncmp(value, option, len))
> > +
> > +static int drm_mode_parse_tv_mode(const char *delim,
> > + struct drm_cmdline_mode *mode)
> > +{
> > + const char *value;
> > + unsigned int len;
> > +
> > + if (*delim != '=')
> > + return -EINVAL;
> > +
> > + value = delim + 1;
> > + delim = strchr(value, ',');
> > + if (!delim)
> > + delim = value + strlen(value);
> > +
> > + len = delim - value;
> > + if (TV_OPTION_EQUAL(value, len, "NTSC-443"))
> > + mode->tv_mode = DRM_MODE_TV_NORM_NTSC_443;
> > + else if (TV_OPTION_EQUAL(value, len, "NTSC-J"))
> > + mode->tv_mode = DRM_MODE_TV_NORM_NTSC_J;
> > + else if (TV_OPTION_EQUAL(value, len, "NTSC-M"))
> > + mode->tv_mode = DRM_MODE_TV_NORM_NTSC_M;
>
> [...]
>
> You already have the array tv_norm_values[] from "[PATCH v1 05/35]
> drm/connector: Add TV standard property". Can't you export that, and
> loop over that array instead?
I'm not sure, the command line doesn't follow the same conventions than
the property names for a number of conventions, but at the same time we
should try to keep it as consistent as possible...
Then again, Jani and Thomas didn't seem too fond about exposing data as
part of the API, so I'm not sure how we could expose that properly.
> > + else if (TV_OPTION_EQUAL(value, len, "HD480I"))
> > + mode->tv_mode = DRM_MODE_TV_NORM_HD480I;
> > + else if (TV_OPTION_EQUAL(value, len, "HD480P"))
> > + mode->tv_mode = DRM_MODE_TV_NORM_HD480P;
> > + else if (TV_OPTION_EQUAL(value, len, "HD576I"))
> > + mode->tv_mode = DRM_MODE_TV_NORM_HD576I;
> > + else if (TV_OPTION_EQUAL(value, len, "HD576P"))
> > + mode->tv_mode = DRM_MODE_TV_NORM_HD576P;
> > + else if (TV_OPTION_EQUAL(value, len, "HD720P"))
> > + mode->tv_mode = DRM_MODE_TV_NORM_HD720P;
> > + else if (TV_OPTION_EQUAL(value, len, "HD1080I"))
> > + mode->tv_mode = DRM_MODE_TV_NORM_HD1080I;
>
> The names in tv_norm_values[] use lower-case, while you use upper-case
> here.
Indeed, I'll fix it, thanks!
Maxime
signature.asc
Description: PGP signature
[PATCH v2 1/4] drm/probe-helper: Add drm_connector_helper_get_modes_fixed()
Add drm_connector_helper_get_modes_fixed(), which duplicates a single
display mode for a connector. Convert drivers.
v2:
* rename 'static' and 'hw' to 'fixed' everywhere
* fix typo 'there' to 'their' (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_mipi_dbi.c | 20 +--
drivers/gpu/drm/drm_probe_helper.c | 40 ++
drivers/gpu/drm/tiny/repaper.c | 16 +---
drivers/gpu/drm/tiny/simpledrm.c | 18 +-
include/drm/drm_probe_helper.h | 3 +++
5 files changed, 46 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 84abc3920b57..de2a5be67415 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -415,26 +415,8 @@ EXPORT_SYMBOL(mipi_dbi_pipe_disable);
static int mipi_dbi_connector_get_modes(struct drm_connector *connector)
{
struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(connector->dev);
- struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, >mode);
- if (!mode) {
- DRM_ERROR("Failed to duplicate mode\n");
- return 0;
- }
-
- if (mode->name[0] == '\0')
- drm_mode_set_name(mode);
-
- mode->type |= DRM_MODE_TYPE_PREFERRED;
- drm_mode_probed_add(connector, mode);
-
- if (mode->width_mm) {
- connector->display_info.width_mm = mode->width_mm;
- connector->display_info.height_mm = mode->height_mm;
- }
-
- return 1;
+ return drm_connector_helper_get_modes_fixed(connector, >mode);
}
static const struct drm_connector_helper_funcs mipi_dbi_connector_hfuncs = {
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index bb427c5a4f1f..818150a1b3b0 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -1050,6 +1050,46 @@ int drm_connector_helper_get_modes_from_ddc(struct
drm_connector *connector)
}
EXPORT_SYMBOL(drm_connector_helper_get_modes_from_ddc);
+/**
+ * drm_connector_helper_get_modes_fixed - Duplicates a display mode for a
connector
+ * @connector: the connector
+ * @fixed_mode: the display hardware's mode
+ *
+ * This function duplicates a display modes for a connector. Drivers for
hardware
+ * that only supports a single fixed mode can use this function in their
connector's
+ * get_modes helper.
+ *
+ * Returns:
+ * The number of created modes.
+ */
+int drm_connector_helper_get_modes_fixed(struct drm_connector *connector,
+const struct drm_display_mode
*fixed_mode)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(dev, fixed_mode);
+ if (!mode) {
+ drm_err(dev, "Failed to duplicate mode " DRM_MODE_FMT "\n",
+ DRM_MODE_ARG(fixed_mode));
+ return 0;
+ }
+
+ if (mode->name[0] == '\0')
+ drm_mode_set_name(mode);
+
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
+ drm_mode_probed_add(connector, mode);
+
+ if (mode->width_mm)
+ connector->display_info.width_mm = mode->width_mm;
+ if (mode->height_mm)
+ connector->display_info.height_mm = mode->height_mm;
+
+ return 1;
+}
+EXPORT_SYMBOL(drm_connector_helper_get_modes_fixed);
+
/**
* drm_connector_helper_get_modes - Read EDID and update connector.
* @connector: The connector
diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c
index c4c1be3ac0b8..01fbd00411fc 100644
--- a/drivers/gpu/drm/tiny/repaper.c
+++ b/drivers/gpu/drm/tiny/repaper.c
@@ -839,22 +839,8 @@ static const struct drm_simple_display_pipe_funcs
repaper_pipe_funcs = {
static int repaper_connector_get_modes(struct drm_connector *connector)
{
struct repaper_epd *epd = drm_to_epd(connector->dev);
- struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, epd->mode);
- if (!mode) {
- DRM_ERROR("Failed to duplicate mode\n");
- return 0;
- }
-
- drm_mode_set_name(mode);
- mode->type |= DRM_MODE_TYPE_PREFERRED;
- drm_mode_probed_add(connector, mode);
-
- connector->display_info.width_mm = mode->width_mm;
- connector->display_info.height_mm = mode->height_mm;
-
- return 1;
+ return drm_connector_helper_get_modes_fixed(connector, epd->mode);
}
static const struct drm_connector_helper_funcs repaper_connector_hfuncs = {
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index a81f91814595..c79576844ec0 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -620,24 +620,8 @@ static const struct drm_encoder_funcs
simpledrm_encoder_funcs = {
static int
[PATCH v2 3/4] drm/modes: Add initializer macro DRM_MODE_INIT()
The macro DRM_MODE_INIT() initializes an instance of
struct drm_display_mode with typical parameters. Convert simpledrm
and also update the macro DRM_SIMPLE_MODE().
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/tiny/simpledrm.c | 23 -
include/drm/drm_modes.h | 35 +++-
2 files changed, 39 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 5bed4d564104..404290760c60 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -30,16 +30,6 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-/*
- * Assume a monitor resolution of 96 dpi to
- * get a somewhat reasonable screen size.
- */
-#define RES_MM(d) \
- (((d) * 254ul) / (96ul * 10ul))
-
-#define SIMPLEDRM_MODE(hd, vd) \
- DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
-
/*
* Helpers for simplefb
*/
@@ -641,10 +631,15 @@ static const struct drm_mode_config_funcs
simpledrm_mode_config_funcs = {
static struct drm_display_mode simpledrm_mode(unsigned int width,
unsigned int height)
{
- struct drm_display_mode mode = { SIMPLEDRM_MODE(width, height) };
-
- mode.clock = mode.hdisplay * mode.vdisplay * 60 / 1000 /* kHz */;
- drm_mode_set_name();
+ /*
+* Assume a monitor resolution of 96 dpi to
+* get a somewhat reasonable screen size.
+*/
+ const struct drm_display_mode mode = {
+ DRM_MODE_INIT(60, width, height,
+ DRM_MODE_RES_MM(width, 96ul),
+ DRM_MODE_RES_MM(height, 96ul))
+ };
return mode;
}
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index a80ae9639e96..bb932806f029 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -138,6 +138,35 @@ enum drm_mode_status {
.vsync_start = (vss), .vsync_end = (vse), .vtotal = (vt), \
.vscan = (vs), .flags = (f)
+/**
+ * DRM_MODE_RES_MM - Calculates the display size from resolution and DPI
+ * @res: The resolution in pixel
+ * @dpi: The number of dots per inch
+ */
+#define DRM_MODE_RES_MM(res, dpi) \
+ (((res) * 254ul) / ((dpi) * 10ul))
+
+#define __DRM_MODE_INIT(pix, hd, vd, hd_mm, vd_mm) \
+ .type = DRM_MODE_TYPE_DRIVER, .clock = (pix), \
+ .hdisplay = (hd), .hsync_start = (hd), .hsync_end = (hd), \
+ .htotal = (hd), .vdisplay = (vd), .vsync_start = (vd), \
+ .vsync_end = (vd), .vtotal = (vd), .width_mm = (hd_mm), \
+ .height_mm = (vd_mm)
+
+/**
+ * DRM_SIMPLE_MODE_INIT - Initialize display mode
+ * @hz: Vertical refresh rate in Hertz
+ * @hd: Horizontal resolution, width
+ * @vd: Vertical resolution, height
+ * @hd_mm: Display width in millimeters
+ * @vd_mm: Display height in millimeters
+ *
+ * This macro initializes a _display_mode that contains information about
+ * refresh rate, resolution and physical size.
+ */
+#define DRM_MODE_INIT(hz, hd, vd, hd_mm, vd_mm) \
+ __DRM_MODE_INIT((hd) * (vd) * (hz) / 1000 /* kHz */, hd, vd, hd_mm,
vd_mm)
+
/**
* DRM_SIMPLE_MODE - Simple display mode
* @hd: Horizontal resolution, width
@@ -149,11 +178,7 @@ enum drm_mode_status {
* resolution and physical size.
*/
#define DRM_SIMPLE_MODE(hd, vd, hd_mm, vd_mm) \
- .type = DRM_MODE_TYPE_DRIVER, .clock = 1 /* pass validation */, \
- .hdisplay = (hd), .hsync_start = (hd), .hsync_end = (hd), \
- .htotal = (hd), .vdisplay = (vd), .vsync_start = (vd), \
- .vsync_end = (vd), .vtotal = (vd), .width_mm = (hd_mm), \
- .height_mm = (vd_mm)
+ __DRM_MODE_INIT(1 /* pass validation */, hd, vd, hd_mm, vd_mm)
#define CRTC_INTERLACE_HALVE_V (1 << 0) /* halve V values for interlacing */
#define CRTC_STEREO_DOUBLE (1 << 1) /* adjust timings for stereo modes */
--
2.37.1
[PATCH v2 2/4] drm/probe-helper: Add drm_crtc_helper_mode_valid_fixed()
Add drm_crtc_helper_mode_valid_fixed(), which validates a given mode
against a display hardware's mode. Convert simpledrm and use it in a
few other drivers with static modes.
v2:
* rename 'static' and 'hw' to 'fixed' everywhere
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_mipi_dbi.c | 18 ++
drivers/gpu/drm/drm_probe_helper.c | 25
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1 +
drivers/gpu/drm/tiny/hx8357d.c | 1 +
drivers/gpu/drm/tiny/ili9163.c | 1 +
drivers/gpu/drm/tiny/ili9341.c | 1 +
drivers/gpu/drm/tiny/ili9486.c | 1 +
drivers/gpu/drm/tiny/mi0283qt.c | 1 +
drivers/gpu/drm/tiny/panel-mipi-dbi.c| 1 +
drivers/gpu/drm/tiny/repaper.c | 10
drivers/gpu/drm/tiny/simpledrm.c | 10 +---
drivers/gpu/drm/tiny/st7735r.c | 1 +
include/drm/drm_mipi_dbi.h | 2 ++
include/drm/drm_probe_helper.h | 8 +--
14 files changed, 70 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index de2a5be67415..a6ac56580876 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -309,6 +309,24 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
struct drm_rect *rect)
drm_dev_exit(idx);
}
+/**
+ * mipi_dbi_pipe_mode_valid - MIPI DBI mode-valid helper
+ * @pipe: Simple display pipe
+ * @mode: The mode to test
+ *
+ * This function validates a given display mode against the MIPI DBI's hardware
+ * display. Drivers can use this as their
_simple_display_pipe_funcs->mode_valid
+ * callback.
+ */
+enum drm_mode_status mipi_dbi_pipe_mode_valid(struct drm_simple_display_pipe
*pipe,
+ const struct drm_display_mode
*mode)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+
+ return drm_crtc_helper_mode_valid_fixed(>crtc, mode,
>mode);
+}
+EXPORT_SYMBOL(mipi_dbi_pipe_mode_valid);
+
/**
* mipi_dbi_pipe_update - Display pipe update helper
* @pipe: Simple display pipe
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 818150a1b3b0..8956b367e12f 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -1014,6 +1014,31 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_helper_hpd_irq_event);
+/**
+ * drm_crtc_helper_mode_valid_fixed - Validates a display mode
+ * @crtc: the crtc
+ * @mode: the mode to validate
+ * @fixed_mode: the display hardware's mode
+ *
+ * Returns:
+ * MODE_OK on success, or another mode-status code otherwise.
+ */
+enum drm_mode_status drm_crtc_helper_mode_valid_fixed(struct drm_crtc *crtc,
+ const struct
drm_display_mode *mode,
+ const struct
drm_display_mode *fixed_mode)
+{
+
+ if (mode->hdisplay != fixed_mode->hdisplay && mode->vdisplay !=
fixed_mode->vdisplay)
+ return MODE_ONE_SIZE;
+ else if (mode->hdisplay != fixed_mode->hdisplay)
+ return MODE_ONE_WIDTH;
+ else if (mode->vdisplay != fixed_mode->vdisplay)
+ return MODE_ONE_HEIGHT;
+
+ return MODE_OK;
+}
+EXPORT_SYMBOL(drm_crtc_helper_mode_valid_fixed);
+
/**
* drm_connector_helper_get_modes_from_ddc - Updates the connector's EDID
* property from the connector's
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 7da09e34385d..39dc40cf681f 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -576,6 +576,7 @@ static void ili9341_dbi_enable(struct
drm_simple_display_pipe *pipe,
}
static const struct drm_simple_display_pipe_funcs ili9341_dbi_funcs = {
+ .mode_valid = mipi_dbi_pipe_mode_valid,
.enable = ili9341_dbi_enable,
.disable = mipi_dbi_pipe_disable,
.update = mipi_dbi_pipe_update,
diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
index 57f229a785bf..48c24aa8c28a 100644
--- a/drivers/gpu/drm/tiny/hx8357d.c
+++ b/drivers/gpu/drm/tiny/hx8357d.c
@@ -181,6 +181,7 @@ static void yx240qv29_enable(struct drm_simple_display_pipe
*pipe,
}
static const struct drm_simple_display_pipe_funcs hx8357d_pipe_funcs = {
+ .mode_valid = mipi_dbi_pipe_mode_valid,
.enable = yx240qv29_enable,
.disable = mipi_dbi_pipe_disable,
.update = mipi_dbi_pipe_update,
diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c
index 86439e50e304..9a1a5943bee0 100644
--- a/drivers/gpu/drm/tiny/ili9163.c
+++ b/drivers/gpu/drm/tiny/ili9163.c
@@ -100,6 +100,7 @@ static void
[PATCH v2 4/4] drm/format-helper: Add drm_fb_build_fourcc_list() helper
Add drm_fb_build_fourcc_list() function that builds a list of supported
formats from native and emulated ones. Helpful for all drivers that do
format conversion as part of their plane updates. Update current caller.
v2:
* use u32 instead of uint32_t (Sam)
* print a warning if output array is too small (Sam)
* comment fixes (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_format_helper.c | 103
drivers/gpu/drm/tiny/simpledrm.c| 47 ++---
include/drm/drm_format_helper.h | 11 ++-
3 files changed, 118 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 56642816fdff..fe1db7dbda3f 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -793,3 +793,106 @@ void drm_fb_xrgb_to_mono(struct iosys_map *dst, const
unsigned int *dst_pitc
kfree(src32);
}
EXPORT_SYMBOL(drm_fb_xrgb_to_mono);
+
+static bool is_listed_fourcc(const uint32_t *fourccs, size_t nfourccs,
uint32_t fourcc)
+{
+ const uint32_t *fourccs_end = fourccs + nfourccs;
+
+ while (fourccs < fourccs_end) {
+ if (*fourccs == fourcc)
+ return true;
+ ++fourccs;
+ }
+ return false;
+}
+
+/**
+ * drm_fb_build_fourcc_list - Filters a list of supported color formats against
+ *the device's native formats
+ * @dev: DRM device
+ * @native_fourccs: 4CC codes of natively supported color formats
+ * @native_nfourccs: The number of entries in @native_fourccs
+ * @extra_fourccs: 4CC codes of additionally supported color formats
+ * @extra_nfourccs: The number of entries in @extra_fourccs
+ * @fourccs_out: Returns 4CC codes of supported color formats
+ * @nfourccs_out: The number of available entries in @fourccs_out
+ *
+ * This function create a list of supported color format from natively
+ * supported formats and the emulated formats.
+ * At a minimum, most userspace programs expect at least support for
+ * XRGB on the primary plane. Devices that have to emulate the
+ * format, and possibly others, can use drm_fb_build_fourcc_list() to
+ * create a list of supported color formats. The returned list can
+ * be handed over to drm_universal_plane_init() et al. Native formats
+ * will go before emulated formats. Other heuristics might be applied
+ * to optimize the order. Formats near the beginning of the list are
+ * usually preferred over formats near the end of the list.
+ *
+ * Returns:
+ * The number of color-formats 4CC codes returned in @fourccs_out.
+ */
+size_t drm_fb_build_fourcc_list(struct drm_device *dev,
+ const u32 *native_fourccs, size_t
native_nfourccs,
+ const u32 *extra_fourccs, size_t extra_nfourccs,
+ u32 *fourccs_out, size_t nfourccs_out)
+{
+ u32 *fourccs = fourccs_out;
+ const u32 *fourccs_end = fourccs_out + nfourccs_out;
+ bool found_native = false;
+ size_t nfourccs, i;
+
+ /*
+* The device's native formats go first.
+*/
+
+ nfourccs = min_t(size_t, native_nfourccs, nfourccs_out);
+
+ for (i = 0; i < nfourccs; ++i) {
+ u32 fourcc = native_fourccs[i];
+
+ drm_dbg_kms(dev, "adding native format %p4cc\n", );
+
+ if (!found_native)
+ found_native = is_listed_fourcc(extra_fourccs,
extra_nfourccs, fourcc);
+ *fourccs = fourcc;
+ ++fourccs;
+ }
+
+ /*
+* The plane's atomic_update helper converts the framebuffer's color
format
+* to a native format when copying to device memory.
+*
+* If there is not a single format supported by both, device and
+* driver, the native formats are likely not supported by the conversion
+* helpers. Therefore *only* support the native formats and add a
+* conversion helper ASAP.
+*/
+ if (!found_native) {
+ drm_warn(dev, "Format conversion helpers required to add extra
formats.\n");
+ goto out;
+ }
+
+ /*
+* The extra formats, emulated by the driver, go second.
+*/
+
+ nfourccs = min_t(size_t, extra_nfourccs, fourccs_end - fourccs);
+
+ for (i = 0; i < nfourccs; ++i) {
+ u32 fourcc = extra_fourccs[i];
+
+ if (is_listed_fourcc(native_fourccs, native_nfourccs, fourcc))
+ continue; /* native formats already went first */
+ *fourccs = fourcc;
+ ++fourccs;
+ }
+
+ if (nfourccs < extra_nfourccs) {
+ drm_warn(dev, "Format buffer too small. %zu trailing formats
dropped.\n",
+extra_nfourccs - nfourccs);
+ }
+
+out:
+ return fourccs - fourccs_out;
+}
[PATCH v2 0/4] drm/probe-helper, modes: Helpers for single-mode displays
This patchset moves code from simpledrm to probe and display-mode helpers. The new functions will be useful for the upcoming driver for PowerPC displays. [1] Where possible, existing drivers are being converted to use them. v2: * replace 'static' and 'hw' naming with 'fixed' * use u32 for 4CC codes (Sam) * print a warning if not all formats can be used (Sam) * comment fixes (Sam) [1] https://patchwork.freedesktop.org/series/106538/ Thomas Zimmermann (4): drm/probe-helper: Add drm_connector_helper_get_modes_fixed() drm/probe-helper: Add drm_crtc_helper_mode_valid_fixed() drm/modes: Add initializer macro DRM_MODE_INIT() drm/format-helper: Add drm_fb_build_fourcc_list() helper drivers/gpu/drm/drm_format_helper.c | 103 +++ drivers/gpu/drm/drm_mipi_dbi.c | 38 +++ drivers/gpu/drm/drm_probe_helper.c | 65 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1 + drivers/gpu/drm/tiny/hx8357d.c | 1 + drivers/gpu/drm/tiny/ili9163.c | 1 + drivers/gpu/drm/tiny/ili9341.c | 1 + drivers/gpu/drm/tiny/ili9486.c | 1 + drivers/gpu/drm/tiny/mi0283qt.c | 1 + drivers/gpu/drm/tiny/panel-mipi-dbi.c| 1 + drivers/gpu/drm/tiny/repaper.c | 26 ++--- drivers/gpu/drm/tiny/simpledrm.c | 96 +++-- drivers/gpu/drm/tiny/st7735r.c | 1 + include/drm/drm_format_helper.h | 11 +- include/drm/drm_mipi_dbi.h | 2 + include/drm/drm_modes.h | 35 ++- include/drm/drm_probe_helper.h | 9 +- 17 files changed, 271 insertions(+), 122 deletions(-) -- 2.37.1
[PATCH v4] drm/msm: Make .remove and .shutdown HW shutdown consistent
Drivers' .remove and .shutdown callbacks are executed on different code
paths. The former is called when a device is removed from the bus, while
the latter is called at system shutdown time to quiesce the device.
This means that some overlap exists between the two, because both have to
take care of properly shutting down the hardware. But currently the logic
used in these two callbacks isn't consistent in msm drivers, which could
lead to kernel panic.
For example, on .remove the component is deleted and its .unbind callback
leads to the hardware being shutdown but only if the DRM device has been
marked as registered.
That check doesn't exist in the .shutdown logic and this can lead to the
driver calling drm_atomic_helper_shutdown() for a DRM device that hasn't
been properly initialized.
A situation like this can happen if drivers for expected sub-devices fail
to probe, since the .bind callback will never be executed. If that is the
case, drm_atomic_helper_shutdown() will attempt to take mutexes that are
only initialized if drm_mode_config_init() is called during a device bind.
This bug was attempted to be fixed in commit 623f279c7781 ("drm/msm: fix
shutdown hook in case GPU components failed to bind"), but unfortunately
it still happens in some cases as the one mentioned above, i.e:
systemd-shutdown[1]: Powering off.
kvm: exiting hardware virtualization
platform wifi-firmware.0: Removing from iommu group 12
platform video-firmware.0: Removing from iommu group 10
[ cut here ]
WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317
drm_modeset_lock_all_ctx+0x3c4/0x3d0
...
Hardware name: Google CoachZ (rev3+) (DT)
pstate: a049 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0
lr : drm_modeset_lock_all_ctx+0x48/0x3d0
sp : 8805bb80
x29: 8805bb80 x28: 327c00128000 x27:
x26: x25: 0001 x24: c95d820ec030
x23: 327c00bbd090 x22: c95d8215eca0 x21: 327c039c5800
x20: 327c039c5988 x19: 8805bbe8 x18: 0034
x17: 00040044 x16: c95d80cac920 x15:
x14: 0315 x13: 0315 x12:
x11: x10: x9 :
x8 : 8805bc28 x7 : x6 :
x5 : x4 : x3 :
x2 : 327c00128000 x1 : x0 : 327c039c59b0
Call trace:
drm_modeset_lock_all_ctx+0x3c4/0x3d0
drm_atomic_helper_shutdown+0x70/0x134
msm_drv_shutdown+0x30/0x40
platform_shutdown+0x28/0x40
device_shutdown+0x148/0x350
kernel_power_off+0x38/0x80
__do_sys_reboot+0x288/0x2c0
__arm64_sys_reboot+0x28/0x34
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x44/0xec
do_el0_svc+0x2c/0xc0
el0_svc+0x2c/0x84
el0t_64_sync_handler+0x11c/0x150
el0t_64_sync+0x18c/0x190
---[ end trace ]---
Unable to handle kernel NULL pointer dereference at virtual address
0018
Mem abort info:
ESR = 0x9604
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x0004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=00010eab1000
[0018] pgd=, p4d=
Internal error: Oops: 9604 [#1] PREEMPT SMP
...
Hardware name: Google CoachZ (rev3+) (DT)
pstate: a049 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ww_mutex_lock+0x28/0x32c
lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0
sp : 8805bb50
x29: 8805bb50 x28: 327c00128000 x27:
x26: x25: 0001 x24: 0018
x23: 8805bc10 x22: 327c039c5ad8 x21: 327c039c5800
x20: 8805bbe8 x19: 0018 x18: 0034
x17: 00040044 x16: c95d80cac920 x15:
x14: 0315 x13: 0315 x12:
x11: x10: x9 :
x8 : 8805bc28 x7 : x6 :
x5 : x4 : x3 :
x2 : 327c00128000 x1 : x0 : 0018
Call trace:
ww_mutex_lock+0x28/0x32c
drm_modeset_lock_all_ctx+0x1b0/0x3d0
drm_atomic_helper_shutdown+0x70/0x134
msm_drv_shutdown+0x30/0x40
platform_shutdown+0x28/0x40
device_shutdown+0x148/0x350
kernel_power_off+0x38/0x80
__do_sys_reboot+0x288/0x2c0
__arm64_sys_reboot+0x28/0x34
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x44/0xec
do_el0_svc+0x2c/0xc0
el0_svc+0x2c/0x84
el0t_64_sync_handler+0x11c/0x150
el0t_64_sync+0x18c/0x190
Code: aa0103f4 d503201f d281 aa0103e3 (c8e37c02)
Re: [PATCH v1 09/35] drm/modes: Move named modes parsing to a separate function
On Fri, Aug 12, 2022 at 03:27:17PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Fri, Jul 29, 2022 at 6:36 PM Maxime Ripard wrote:
> > The current construction of the named mode parsing doesn't allow to extend
> > it easily. Let's move it to a separate function so we can add more
> > parameters and modes.
> >
> > Signed-off-by: Maxime Ripard
>
> Thanks for your patch, which looks similar to my "[PATCH v2 2/5]
> drm/modes: Extract drm_mode_parse_cmdline_named_mode()"
> (https://lore.kernel.org/dri-devel/1371554419ae63cb54c2a377db0c1016fcf200bb.1657788997.git.ge...@linux-m68k.org
> ;-)
Indeed, I forgot about that one, sorry :/
I think I'd still prefer to have the check for refresh + named mode
outside of the function, since I see them as an "integration" issue, not
a parsing one.
It's not the named mode parsing that fails, but the fact that we both
have a valid refresh and a valid named mode.
>
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1773,6 +1773,28 @@ static const char * const
> > drm_named_modes_whitelist[] = {
> > "PAL",
> > };
> >
> > +static bool drm_mode_parse_cmdline_named_mode(const char *name,
> > + unsigned int name_end,
> > + struct drm_cmdline_mode
> > *cmdline_mode)
> > +{
> > + unsigned int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> > + int ret;
> > +
> > + ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> > + if (ret != name_end)
> > + continue;
> > +
> > + strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
> > + cmdline_mode->specified = true;
> > +
> > + return true;
> > + }
> > +
> > + return false;
>
> What's the point in returning a value, if it is never checked?
> Just make this function return void?
Yeah, it's something I went back and forth to between the dev, and it's
an artifact.
I'll drop that patch, take your version and move the refresh check to
drm_mode_parse_command_line_for_connector if that's alright for you?
Maxime
signature.asc
Description: PGP signature
Re: [PATCH 4/4] drm/format-helper: Add drm_fb_build_fourcc_list() helper
Hi
Am 12.08.22 um 20:19 schrieb Sam Ravnborg:
Hi Thomas,
On Wed, Aug 10, 2022 at 01:20:53PM +0200, Thomas Zimmermann wrote:
Add drm_fb_build_fourcc_list() function that builds a list of supported
formats from native and emulated ones. Helpful for all drivers that do
format conversion as part of their plane updates. Update current caller.
Signed-off-by: Thomas Zimmermann
A few comments in the following. Consider to add the warning and with it
added or not:
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_format_helper.c | 94 +
drivers/gpu/drm/tiny/simpledrm.c| 47 ++-
include/drm/drm_format_helper.h | 11 +++-
3 files changed, 109 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 56642816fdff..dca5531615f3 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -793,3 +793,97 @@ void drm_fb_xrgb_to_mono(struct iosys_map *dst, const
unsigned int *dst_pitc
kfree(src32);
}
EXPORT_SYMBOL(drm_fb_xrgb_to_mono);
+
+static bool is_listed_fourcc(const uint32_t *fourccs, size_t nfourccs,
uint32_t fourcc)
+{
+ const uint32_t *fourccs_end = fourccs + nfourccs;
+
+ while (fourccs < fourccs_end) {
+ if (*fourccs == fourcc)
+ return true;
+ ++fourccs;
+ }
+ return false;
+}
+
+/**
+ * drm_fb_build_fourcc_list - Filters a list of supported color formats against
+ *the device's native formats
+ * @dev: DRM device
+ * @native_fourccs: 4CC codes of natively supported color formats
+ * @native_nfourccs: The number of entries in @native_fourccs
+ * @extra_fourccs: 4CC codes of additionally supported color formats
+ * @extra_nfourccs: The number of entries in @extra_fourccs
+ * @fourccs_out: Returns 4CC codes of supported color formats
+ * @nfourccs_out: The number of available entries in @fourccs_out
+ *
+ * This function create a list of supported color format from natively
+ * supported formats and the emulated formats. *
Stray '*' at the end of the line.
+ * At a minimum, most userspace programs expect at least support for
+ * XRGB on the primary plane. Devices that have to emulate the
+ * format, and possibly others, can use drm_fb_build_fourcc_list() to
+ * create a list of supported color formats. The returned list can
+ * be handed over to drm_universal_plane_init() et al. Native formats
+ * will go before emulated formats. Other heuristics might be applied
+ * to optimize the order. Formats near the beginning of the list are
+ * usually preferred over formats near the end of the list.
+ *
+ * Returns:
+ * The number of color-formats 4CC codes returned in @fourccs_out.
+ */
+size_t drm_fb_build_fourcc_list(struct drm_device *dev,
+ const uint32_t *native_fourccs, size_t
native_nfourccs,
+ const uint32_t *extra_fourccs, size_t
extra_nfourccs,
+ uint32_t *fourccs_out, size_t nfourccs_out)
drm_fourcc.c uses the type u32 for fourcc codes, why no go with the same
here?
I wish we had a better way to express that we have a list of fourcc
codes, for example using list_head. But it is a bad mismatch with
the current drm_universal_plane_init() implementation.
I've changed the code to u32. struct list_head is somewhat overhead-ish,
but I'd like to see a 'fourcc_t' typedef of the u32.
The format negotiation operation in the bridges could benefit too.
+{
+ uint32_t *fourccs = fourccs_out;
+ const uint32_t *fourccs_end = fourccs_out + nfourccs_out;
+ bool found_native = false;
+ size_t nfourccs, i;
+
+ /* native formats go first */
+
Drop extra line, capital start
+ nfourccs = min_t(size_t, native_nfourccs, nfourccs_out);
+
+ for (i = 0; i < nfourccs; ++i) {
+ uint32_t fourcc = native_fourccs[i];
+
+ drm_dbg_kms(dev, "adding native format %p4cc\n", );
+
+ if (!found_native)
+ found_native = is_listed_fourcc(extra_fourccs,
extra_nfourccs, fourcc);
+ *fourccs = fourcc;
+ ++fourccs;
+ }
+
+ /*
+* The plane's atomic_update helper converts the framebuffer's color
format
+* to the native format when copying them to device memory.
+*
+* If there is not a single format supported by both, device and
+* plane, the native formats are likely not supported by the conversion
+* helpers. Therefore *only* support the native formats and add a
+* conversion helper ASAP.
+*/
Despite the nice comment I had to think twice. In the end I agree with
this.
+ if (!found_native) {
+ drm_warn(dev, "format conversion helpers required to add extra
formats\n");
+ goto out;
+ }
+
+ /* extra
Re: [PATCH 0/3] KUnit tests for RGB888, XRGB2101010 and grayscale
Hi José, Tested the whole series on UML, x86, i386 and PPC. All looks fine! Tested-by: Maíra Canal Best Regards, - Maíra Canal On 8/16/22 07:29, José Expósito wrote: Hello everyone, This series is a follow up on my work adding KUnit test to the XRGB conversion functions. This time RGB888, XRGB2101010 and gray8 are added. Best wishes, Jose José Expósito (3): drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_rgb888() drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_xrgb2101010() drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_gray8() .../gpu/drm/tests/drm_format_helper_test.c| 190 ++ 1 file changed, 190 insertions(+)
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
Hi Maxime,
On Tue, Aug 16, 2022 at 3:20 PM Maxime Ripard wrote:
> On Fri, Aug 12, 2022 at 03:25:18PM +0200, Geert Uytterhoeven wrote:
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -1649,11 +1650,40 @@
> > > EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
> > > * 0 on success or a negative error code on failure.
> > > */
> > > int drm_mode_create_tv_properties(struct drm_device *dev,
> > > + unsigned int supported_tv_norms,
> > > unsigned int num_modes,
> > > const char * const modes[])
> > > {
> > > + static const struct drm_prop_enum_list tv_norm_values[] = {
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1,
> > > "NTSC-443" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1,
> > > "SECAM-60" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B"
> > > },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D"
> > > },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G"
> > > },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K"
> > > },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1,
> > > "SECAM-K1" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L"
> > > },
> >
> > The above are analog standards, with a variable horizontal resolution.
> >
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
> > > + { __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i"
> > > },
> >
> > The above are digital standards, with a fixed resolution.
>
> Are they?
>
> It's not clear to me from looking at nouveau, but I was under the
> impression that they were modes for a component output, so CEA 770.3. I
> don't have the spec though, so I can't check.
Oh right, I forgot about analog HD over component, where you can use
other pixel clocks than in the digital standard.
> > You seem to have missed "hd1080p"?
>
> Nobody is using it. If we ever have a driver that uses it I think we can
> add it.
The PS3 supports 1080p over component
https://manuals.playstation.net/document/en/ps3/current/settings/videooutput.html
> > In addition, "hd720p", "hd080i", and "hd1080p" are available in both 50
> > and 60 (actually 59.94) Hz, while "hd1080p" can also use 24 or 25 Hz.
>
> It looks like nouveau only exposes modes for 480p at 59.94Hz, 576p at
> 50Hz, 720p at 60Hz, 1080i at 30Hz.
PS3 supports both 50 and 60 Hz (same link above).
> > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > handle them through "@". The latter would impact "[PATCH v1
> > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > currently a named mode and a refresh rate can't be specified both.
>
> I think the former would make more sense. It simplifies a bit the
> parser, and we're going to use a named mode anyway.
>
> > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > command-line option" uses a separate "tv_mode" option, and not the main
> > mode name, I think you want to add them here.
>
> It's a separate story I think, we could have a named mode hd720p50,
> which would be equivalent to 1280x720,tv_mode=hd720p
So where's the field rate in "1280x720,tv_mode=hd720p"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/5] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi,
Le mardi 02 août 2022 à 11:58 +0200, Olivier Masse a écrit :
> add Linaro secure heap bindings: linaro,secure-heap
Just a curiosity, how is this specific to Linaro OPTEE OS ? Shouldn't it be "de-
linaro-ified" somehow ?
regards,
Nicolas
> use genalloc to allocate/free buffer from buffer pool.
> buffer pool info is from dts.
> use sg_table instore the allocated memory info, the length of sg_table is 1.
> implement secure_heap_buf_ops to implement buffer share in difference device:
> 1. Userspace passes this fd to all drivers it wants this buffer
> to share with: First the filedescriptor is converted to a _buf using
> dma_buf_get(). Then the buffer is attached to the device using
> dma_buf_attach().
> 2. Once the buffer is attached to all devices userspace can initiate DMA
> access to the shared buffer. In the kernel this is done by calling
> dma_buf_map_attachment()
> 3. get sg_table with dma_buf_map_attachment in difference device.
>
> Signed-off-by: Olivier Masse
> ---
> drivers/dma-buf/heaps/Kconfig | 21 +-
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/secure_heap.c | 588
> 3 files changed, 606 insertions(+), 4 deletions(-)
> create mode 100644 drivers/dma-buf/heaps/secure_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index 6a33193a7b3e..b2406932192e 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -1,8 +1,12 @@
> -config DMABUF_HEAPS_DEFERRED_FREE
> - tristate
> +menuconfig DMABUF_HEAPS_DEFERRED_FREE
> + bool "DMA-BUF heaps deferred-free library"
> + help
> + Choose this option to enable the DMA-BUF heaps deferred-free library.
>
> -config DMABUF_HEAPS_PAGE_POOL
> - tristate
> +menuconfig DMABUF_HEAPS_PAGE_POOL
> + bool "DMA-BUF heaps page-pool library"
> + help
> + Choose this option to enable the DMA-BUF heaps page-pool library.
>
> config DMABUF_HEAPS_SYSTEM
> bool "DMA-BUF System Heap"
> @@ -26,3 +30,12 @@ config DMABUF_HEAPS_DSP
>Choose this option to enable the dsp dmabuf heap. The dsp heap
>is allocated by gen allocater. it's allocated according the dts.
>If in doubt, say Y.
> +
> +config DMABUF_HEAPS_SECURE
> + tristate "DMA-BUF Secure Heap"
> + depends on DMABUF_HEAPS && DMABUF_HEAPS_DEFERRED_FREE
> + help
> + Choose this option to enable the secure dmabuf heap. The secure heap
> + pools are defined according to the DT. Heaps are allocated
> + in the pools using gen allocater.
> + If in doubt, say Y.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index e70722ea615e..08f6aa5919d1 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_DMABUF_HEAPS_PAGE_POOL) += page_pool.o
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_DSP) += dsp_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_SECURE)+= secure_heap.o
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> new file mode 100644
> index ..31aac5d050b4
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -0,0 +1,588 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF secure heap exporter
> + *
> + * Copyright 2021 NXP.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "deferred-free-helper.h"
> +#include "page_pool.h"
> +
> +#define MAX_SECURE_HEAP 2
> +#define MAX_HEAP_NAME_LEN 32
> +
> +struct secure_heap_buffer {
> + struct dma_heap *heap;
> + struct list_head attachments;
> + struct mutex lock;
> + unsigned long len;
> + struct sg_table sg_table;
> + int vmap_cnt;
> + struct deferred_freelist_item deferred_free;
> + void *vaddr;
> + bool uncached;
> +};
> +
> +struct dma_heap_attachment {
> + struct device *dev;
> + struct sg_table *table;
> + struct list_head list;
> + bool no_map;
> + bool mapped;
> + bool uncached;
> +};
> +
> +struct secure_heap_info {
> + struct gen_pool *pool;
> +
> + bool no_map;
> +};
> +
> +struct rmem_secure {
> + phys_addr_t base;
> + phys_addr_t size;
> +
> + char name[MAX_HEAP_NAME_LEN];
> +
> + bool no_map;
> +};
> +
> +static struct rmem_secure secure_data[MAX_SECURE_HEAP] = {0};
> +static unsigned int secure_data_count;
> +
> +static struct sg_table *dup_sg_table(struct sg_table *table)
> +{
> + struct sg_table *new_table;
> + int ret, i;
> + struct scatterlist *sg, *new_sg;
> +
> + new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
> + if (!new_table)
> + return ERR_PTR(-ENOMEM);
> +
> + ret =
Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
Hi Geert, On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote: > Hi Maxime, > > Thanks for your patch! > > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard wrote: > > Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines > > modes in the drivers. > > Nit: strictly speaking these are not analog modes, but the digital > variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a > 13.5 MHz sampling frequency for pixels. > > In analog modes, the only discrete values are the number of lines, and > the frame/field rate (fixing the horizontal sync rate when combined). > > The number of (in)visible pixels per line depends on the available > bandwidth. In a digital variant (which is anything generated by a > digital computer system), the latter depends on the pixel clock, which > can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g. > Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)). > > So I think we probably need some way to generate a PAL/NTSC-compatible > mode based not only on resolution, but also on pixel clock. This would also fix the comments made by Jani and Thomas, so I quite like the idea of it. I'm struggling a bit to find how would could implement this though. From what you were saying, I guess the prototype would be something like struct drm_display_mode *drm_create_analog_mode(unsigned int pixel_clock, unsigned int lines, unsigned int frame_rate) But I have zero idea on what the implementation would be. Do you have some resources for this you could point me to? Thanks Maxime signature.asc Description: PGP signature
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
Hi Geert,
On Fri, Aug 12, 2022 at 03:25:18PM +0200, Geert Uytterhoeven wrote:
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
> > * 0 on success or a negative error code on failure.
> > */
> > int drm_mode_create_tv_properties(struct drm_device *dev,
> > + unsigned int supported_tv_norms,
> > unsigned int num_modes,
> > const char * const modes[])
> > {
> > + static const struct drm_prop_enum_list tv_norm_values[] = {
> > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443"
> > },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60"
> > },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1"
> > },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },
>
> The above are analog standards, with a variable horizontal resolution.
>
> > + { __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
> > + { __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },
>
> The above are digital standards, with a fixed resolution.
Are they?
It's not clear to me from looking at nouveau, but I was under the
impression that they were modes for a component output, so CEA 770.3. I
don't have the spec though, so I can't check.
> You seem to have missed "hd1080p"?
Nobody is using it. If we ever have a driver that uses it I think we can
add it.
> In addition, "hd720p", "hd080i", and "hd1080p" are available in both 50
> and 60 (actually 59.94) Hz, while "hd1080p" can also use 24 or 25 Hz.
It looks like nouveau only exposes modes for 480p at 59.94Hz, 576p at
50Hz, 720p at 60Hz, 1080i at 30Hz.
> Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> handle them through "@". The latter would impact "[PATCH v1
> 09/35] drm/modes: Move named modes parsing to a separate function", as
> currently a named mode and a refresh rate can't be specified both.
I think the former would make more sense. It simplifies a bit the
parser, and we're going to use a named mode anyway.
> As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> command-line option" uses a separate "tv_mode" option, and not the main
> mode name, I think you want to add them here.
It's a separate story I think, we could have a named mode hd720p50,
which would be equivalent to 1280x720,tv_mode=hd720p
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v2 4/7] regulator: core: Allow specifying an initial load w/ the bulk API
HI, Douglas With this change, I get one kernel panic with my hikey960 android-mainline based Android build, if it's reverted, then the build could boot to the home screen successfully. >From the log information I shared here, not sure if you have any idea what I could do to have the hikey960 build work with this change, The kernel panic is something like this, for details, please check the log here: http://ix.io/47Lq [ 10.738042][ T193] adv7511 1-0039: error : Failed to get supply 'v1p2' [ 10.748457][ T194] apexd: Found pre-installed APEX /system/apex/com.android.os.statsd.apex [ 10.752908][ T67] Unable to handle kernel read from unreadable memory at virtual address 004c [ 10.753116][T8] Unable to handle kernel read from unreadable memory at virtual address 0078 [ 10.753130][T8] Mem abort info: [ 10.753135][T8] ESR = 0x9605 [ 10.753142][T8] EC = 0x25: DABT (current EL), IL = 32 bits [ 10.753152][T8] SET = 0, FnV = 0 [ 10.753159][T8] EA = 0, S1PTW = 0 [ 10.753166][T8] FSC = 0x05: level 1 translation fault [ 10.753174][T8] Data abort info: [ 10.753179][T8] ISV = 0, ISS = 0x0005 [ 10.753184][T8] CM = 0, WnR = 0 [ 10.753192][T8] user pgtable: 4k pages, 39-bit VAs, pgdp=03098000 [ 10.753204][T8] [0078] pgd=, p4d=, pud= [ 10.753232][T8] Internal error: Oops: 9605 [#1] PREEMPT SMP [ 10.753245][T8] Modules linked in: adv7511(E+) tcpci_rt1711h(E) hci_uart(E) btqca(E) btbcm(E) cpufreq_dt(E) hi3660_i2s(E) hisi_hikey_usb(E) hi6421_pmic_core(E) syscon_reboot_mode(E) reboot_mode(E) hi3660_mailbox(E) dw_mmc_k3(E) hisi_thermal(E) dw_mmc_pltfm(E) dw_mmc(E) kirin_drm(E) snd_soc_simple_card(E) snd_soc_simple_card_utils(E) spi_pl022(E) kirin_dsi(E) phy_hi3660_usb3(E) i2c_designware_platform(E) drm_cma_helper(E) i2c_designware_core(E) mali_kbase(OE) k3dma(E) cma_heap(E) system_heap(E) [ 10.753436][T8] CPU: 2 PID: 8 Comm: kworker/u16:0 Tainted: G OE 5.19.0-mainline-03487-g86d047950300-dirty #1 [ 10.753454][T8] Hardware name: HiKey960 (DT) [ 10.753463][T8] Workqueue: events_unbound async_run_entry_fn [ 10.753497][T8] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 10.753516][T8] pc : regulator_bulk_enable_async+0x3c/0x98 [ 10.753540][T8] lr : async_run_entry_fn+0x30/0xf8 [ 10.753559][T8] sp : ffc009ed3d20 [ 10.753567][T8] x29: ffc009ed3d40 x28: 0402 x27: ff801ad99828 [ 10.753592][T8] x26: ff803217b010 x25: 0002 x24: ff8003385da8 [ 10.753617][T8] x23: ff8003385da0 x22: ff801ad94805 x21: ff8003385da0 [ 10.753642][T8] x20: x19: ff8003143d20 x18: ffc008075028 [ 10.753667][T8] x17: 00040044 x16: 0001 x15: 0010 [ 10.753691][T8] x14: x13: 0f58 x12: 8235 [ 10.753715][T8] x11: 6acfbfa2f400 x10: 0016 x9 : 00ff [ 10.753740][T8] x8 : da9ecda1b63b0500 x7 : 8080 x6 : [ 10.753764][T8] x5 : 0001 x4 : 646e756f626e x3 : ff801ad99828 [ 10.753788][T8] x2 : ff8003385da8 x1 : ffc009ed3d20 x0 : ff8003143d20 [ 10.753812][T8] Call trace: [ 10.753818][T8] regulator_bulk_enable_async+0x3c/0x98 [ 10.753839][T8] async_run_entry_fn+0x30/0xf8 [ 10.753859][T8] process_one_work+0x1d0/0x404 [ 10.753879][T8] worker_thread+0x25c/0x43c [ 10.753897][T8] kthread+0xf0/0x2c0 [ 10.753912][T8] ret_from_fork+0x10/0x20 [ 10.753940][T8] Code: f81f83a8 f9400814 a900 f90003ff (f9403e95) [ 10.753950][T8] ---[ end trace ]--- [ 10.760621][ T194] apexd: Found pre-installed APEX /system/apex/com.android.permission.capex [ 10.767672][ T67] Mem abort info: [ 10.779658][ T194] apexd: Found pre-installed APEX /system/apex/com.android.art.capex [ 10.783690][ T67] ESR = 0x9605 [ 10.792424][ T194] apexd: Found pre-installed APEX /system/apex/com.android.scheduling.capex [ 10.794713][T8] Kernel panic - not syncing: Oops: Fatal exception [ 10.794723][T8] SMP: stopping secondary CPUs [ 10.798141][T8] Kernel Offset: 0x7 from 0xffc00800 [ 10.798150][T8] PHYS_OFFSET: 0x0 [ 10.798156][T8] CPU features: 0x,00649020,1086 [ 10.798167][T8] Memory Limit: none Thanks, Yongqin Liu On Wed, 27 Jul 2022 at 01:39, Douglas Anderson wrote: > > There are a number of drivers that follow a pattern that looks like > this: > 1. Use the regulator bulk API to get a bunch of regulators. > 2. Set the load on each of the regulators to use whenever the >regulators are enabled. > > Let's make this easier by just allowing the drivers to pass the
Re: [PATCH v1 07/35] drm/modes: Only consider bpp and refresh before options
Hi Geert, Thanks for your review On Fri, Aug 12, 2022 at 03:25:39PM +0200, Geert Uytterhoeven wrote: > Hi Maxime, > > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard wrote: > > Some video= options might have a value that contains a dash. However, the > > command line parsing mode considers all dashes as the separator between the > > mode and the bpp count. > > > > Let's rework the parsing code a bit to only consider a dash as the bpp > > separator if it before a comma, the options separator. > > > > A follow-up patch will add a unit-test for this once such an option is > > introduced. > > > > Signed-off-by: Maxime Ripard > > Thanks for your patch! > > Reviewed-by: Geert Uytterhoeven > > > --- a/drivers/gpu/drm/drm_modes.c > > +++ b/drivers/gpu/drm/drm_modes.c > > @@ -1819,20 +1819,22 @@ bool > > drm_mode_parse_command_line_for_connector(const char *mode_option, > > > > name = mode_option; > > > > + /* Locate the start of named options */ > > + options_ptr = strchr(name, ','); > > + if (options_ptr) > > + options_off = options_ptr - name; > > + else > > + options_off = strlen(name); > > + > > /* Try to locate the bpp and refresh specifiers, if any */ > > - bpp_ptr = strchr(name, '-'); > > + bpp_ptr = strnchr(name, options_off, '-'); > > Probably you still want to add a check that the next character > is actually a digit, cfr. my "[PATCH v2 5/5] drm/modes: > parse_cmdline: Add support for named modes containing dashes" > (https://lore.kernel.org/dri-devel/2eb205da88c3cb19ddf04d167ece4e16a330948b.1657788997.git.ge...@linux-m68k.org)? I think your patch is orthogonal, and we should merge it anyway. As a matter of fact, I initially wanted to do something similar but bailed out to deal with PAL-M and so on. If there's such modes already, then we should totally support it Maxime signature.asc Description: PGP signature
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
Am 16.08.22 um 13:44 schrieb Dmitry Osipenko: [SNIP] The other complication I noticed is that we don't seem to keep around the fd after importing to a GEM handle. And I could imagine that doing so could cause issues with too many fd's. So I guess the best thing is to keep the status quo and let drivers that cannot mmap imported buffers just fail mmap? That actually should be all the drivers excluding those that use DRM-SHMEM because only DRM-SHMEM uses dma_buf_mmap(), that's why it works for Panfrost. I'm pretty sure mmaping of imported GEMs doesn't work for the MSM driver, isn't it? Intel and AMD drivers don't allow to map the imported dma-bufs. Both refuse to do the mapping. Although, AMDGPU "succeeds" to do the mapping using AMDGPU_GEM_DOMAIN_GTT, but then touching the mapping causes bus fault, hence mapping actually fails. I think it might be the AMDGPU driver/libdrm bug, haven't checked yet. That's then certainly broken somehow. Amdgpu should nerve ever have allowed to mmap() imported DMA-bufs and the last time I check it didn't. Regards, Christian. So we're back to the point that neither of DRM drivers need to map imported dma-bufs and this was never tested. In this case this patch is valid, IMO.
Re: [PATCH] drm/rockchip: vop2: Fix eDP/HDMI sync polarities
Hi Sascha,
On 8/15/22 15:39, Sascha Hauer wrote:
> The hsync/vsync polarities were not honoured for the eDP and HDMI ports.
> Add the register settings to configure the polarities as requested by the
> DRM_MODE_FLAG_PHSYNC/DRM_MODE_FLAG_PVSYNC flags.
Amazingly enough it worked even without this fix in my setup (Radxa
ROCK3 Model A + HP 27f 4k monitor). Hence I can only say that this patch
does not break anything in my setup :-)
Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") ?
> Signed-off-by: Sascha Hauer
Tested-by: Michael Riesch
Thanks and best regards,
Michael
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index e4631f515ba42..f9aa8b96c6952 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -1439,11 +1439,15 @@ static void rk3568_set_intf_mux(struct
> vop2_video_port *vp, int id,
> die &= ~RK3568_SYS_DSP_INFACE_EN_HDMI_MUX;
> die |= RK3568_SYS_DSP_INFACE_EN_HDMI |
> FIELD_PREP(RK3568_SYS_DSP_INFACE_EN_HDMI_MUX,
> vp->id);
> + dip &= ~RK3568_DSP_IF_POL__HDMI_PIN_POL;
> + dip |= FIELD_PREP(RK3568_DSP_IF_POL__HDMI_PIN_POL, polflags);
> break;
> case ROCKCHIP_VOP2_EP_EDP0:
> die &= ~RK3568_SYS_DSP_INFACE_EN_EDP_MUX;
> die |= RK3568_SYS_DSP_INFACE_EN_EDP |
> FIELD_PREP(RK3568_SYS_DSP_INFACE_EN_EDP_MUX, vp->id);
> + dip &= ~RK3568_DSP_IF_POL__EDP_PIN_POL;
> + dip |= FIELD_PREP(RK3568_DSP_IF_POL__EDP_PIN_POL, polflags);
> break;
> case ROCKCHIP_VOP2_EP_MIPI0:
> die &= ~RK3568_SYS_DSP_INFACE_EN_MIPI0_MUX;
Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
On Tue, Aug 02, 2022 at 04:16:29PM +0200, Thomas Zimmermann wrote: > Hi > > Am 02.08.22 um 15:58 schrieb Jani Nikula: > > On Fri, 29 Jul 2022, Maxime Ripard wrote: > > > Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines > > > modes in the drivers. > > > > > > Since those modes are fairly standards, and that we'll need to use them in > > > more places in the future, let's move the meson definition into the > > > framework. > > > > I think you should always expose interfaces, not data. Data is not an > > interface, and I think this sets a bad example that will be cargo > > culted. > > Although I wrote the opposite wrt patch 8, I agree with Jani here when it > comes to 'official' interfaces. The cases I've seen of exported data > structures often lead to intransparent code. Ack. The improvement Geert suggested would involve that change anyway, so this should be fixed for the next iteration. Maxime signature.asc Description: PGP signature
Re: [PATCH v1 20/35] drm/vc4: vec: Switch for common modes
Hi, On Fri, Jul 29, 2022 at 08:12:07PM +0200, Mateusz Kwiatkowski wrote: > I'm just noting that the modelines you defined in drm_modes.c are different > to the ones you're removing here. > > The horizontal sync differences probably doesn't matter too much, VC4 uses > those only as a hint anyway and generates sync autonomously, so the slight > differences will only cause the image to slightly shift horizontally. > > But you're also changing the 480i vertical sync (vsync_start is now 488 > instead of 487, etc.). Are you sure that this won't break anything? This > will probably shift the image by 1 line (which for the 480i might actually > mean going out of spec), and I _think_ it might control the odd vs. even > field first modes on some drivers. I won't be able to test this before > Monday, but I'm just pointing out the potential issue. I didn't see any difference on both vc4 and sun4i, but you might be right about this. I didn't have much confidence in the vc4 modes since they were broken before your patches, but maybe I should have used yours still. > BTW, I've seen a similar thing in the sun4i driver changes (patch 32/35) and > the differences in vertical sync are even more dramatic. It's entirely > possible that the current timings in sun4i are broken and the new ones are > correct (the new ones certainly look saner to me), but I'd double-check if > that driver does not have any quirks that would _require_ such weird > settings. The only thing sun4i requires from the new mode is the line number anyway, which stays the same. Maxime signature.asc Description: PGP signature
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
On 8/16/22 14:44, Dmitry Osipenko wrote:
> On 8/12/22 18:01, Rob Clark wrote:
>> On Fri, Aug 12, 2022 at 7:57 AM Rob Clark wrote:
>>>
>>> On Fri, Aug 12, 2022 at 4:26 AM Dmitry Osipenko
>>> wrote:
On 8/11/22 02:19, Rob Clark wrote:
> On Wed, Aug 10, 2022 at 3:23 PM Dmitry Osipenko
> wrote:
>>
>> On 8/11/22 01:03, Rob Clark wrote:
>>> On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko
>>> wrote:
On 8/10/22 18:08, Rob Clark wrote:
> On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter wrote:
>>
>> On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote:
>>> On 7/6/22 00:48, Rob Clark wrote:
On Tue, Jul 5, 2022 at 4:51 AM Christian König
wrote:
>
> Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
>> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers
>> don't
>> handle imported dma-bufs properly, which results in mapping of
>> something
>> else than the imported dma-buf. On NVIDIA Tegra we get a hard
>> lockup when
>> userspace writes to the memory mapping of a dma-buf that was
>> imported into
>> Tegra's DRM GEM.
>>
>> Majority of DRM drivers prohibit mapping of the imported GEM
>> objects.
>> Mapping of imported GEMs require special care from userspace
>> since it
>> should sync dma-buf because mapping coherency of the exporter
>> device may
>> not match the DRM device. Let's prohibit the mapping for all DRM
>> drivers
>> for consistency.
>>
>> Suggested-by: Thomas Hellström
>> Signed-off-by: Dmitry Osipenko
>
> I'm pretty sure that this is the right approach, but it's
> certainly more
> than possible that somebody abused this already.
I suspect that this is abused if you run deqp cts on android.. ie.
all
winsys buffers are dma-buf imports from gralloc. And then when you
hit readpix...
You might only hit this in scenarios with separate gpu and display
(or
dGPU+iGPU) because self-imports are handled differently in
drm_gem_prime_import_dev().. and maybe not in cases where you end
up
with a blit from tiled/compressed to linear.. maybe that narrows
the
scope enough to just fix it in userspace?
>>>
>>> Given that that only drivers which use DRM-SHMEM potentially
>>> could've
>>> map imported dma-bufs (Panfrost, Lima) and they already don't allow
>>> to
>>> do that, I think we're good.
>>
>> So can I have an ack from Rob here or are there still questions that
>> this
>> might go boom?
>>
>> Dmitry, since you have a bunch of patches merged now I think would
>> also be
>> good to get commit rights so you can drive this more yourself. I've
>> asked
>> Daniel Stone to help you out with getting that.
>
> I *think* we'd be ok with this on msm, mostly just by dumb luck.
> Because the dma-buf's we import will be self-import. I'm less sure
> about panfrost (src/panfrost/lib/pan_bo.c doesn't seem to have a
> special path for imported dma-bufs either, and in that case they won't
> be self-imports.. but I guess no one has tried to run android cts on
> panfrost).
The last time I tried to mmap dma-buf imported to Panfrost didn't work
because Panfrost didn't implement something needed for that. I'll need
to take a look again because can't recall what it was.
Upd: I re-checked Panfrost using today's linux-next and mapping of
imported dma-buf works, I mapped imported buf from video decoder.
Apparently previously I had some local kernel change that broke the
mapping.
> What about something less drastic to start, like (apologies for
> hand-edited patch):
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 86d670c71286..fc9ec42fa0ab 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object
> *obj, unsigned long obj_size,
> {
> int ret;
>
> + WARN_ON_ONCE(obj->import_attach);
This will hang NVIDIA Tegra, which is what this patch fixed initially.
If neither of upstream DRM drivers need to map imported dma-bufs and
never needed, then why do we need this?
>>>
>>> oh, tegra
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
On 8/12/22 18:01, Rob Clark wrote:
> On Fri, Aug 12, 2022 at 7:57 AM Rob Clark wrote:
>>
>> On Fri, Aug 12, 2022 at 4:26 AM Dmitry Osipenko
>> wrote:
>>>
>>> On 8/11/22 02:19, Rob Clark wrote:
On Wed, Aug 10, 2022 at 3:23 PM Dmitry Osipenko
wrote:
>
> On 8/11/22 01:03, Rob Clark wrote:
>> On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko
>> wrote:
>>>
>>> On 8/10/22 18:08, Rob Clark wrote:
On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter wrote:
>
> On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote:
>> On 7/6/22 00:48, Rob Clark wrote:
>>> On Tue, Jul 5, 2022 at 4:51 AM Christian König
>>> wrote:
Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers
> don't
> handle imported dma-bufs properly, which results in mapping of
> something
> else than the imported dma-buf. On NVIDIA Tegra we get a hard
> lockup when
> userspace writes to the memory mapping of a dma-buf that was
> imported into
> Tegra's DRM GEM.
>
> Majority of DRM drivers prohibit mapping of the imported GEM
> objects.
> Mapping of imported GEMs require special care from userspace
> since it
> should sync dma-buf because mapping coherency of the exporter
> device may
> not match the DRM device. Let's prohibit the mapping for all DRM
> drivers
> for consistency.
>
> Suggested-by: Thomas Hellström
> Signed-off-by: Dmitry Osipenko
I'm pretty sure that this is the right approach, but it's
certainly more
than possible that somebody abused this already.
>>>
>>> I suspect that this is abused if you run deqp cts on android.. ie.
>>> all
>>> winsys buffers are dma-buf imports from gralloc. And then when you
>>> hit readpix...
>>>
>>> You might only hit this in scenarios with separate gpu and display
>>> (or
>>> dGPU+iGPU) because self-imports are handled differently in
>>> drm_gem_prime_import_dev().. and maybe not in cases where you end up
>>> with a blit from tiled/compressed to linear.. maybe that narrows the
>>> scope enough to just fix it in userspace?
>>
>> Given that that only drivers which use DRM-SHMEM potentially could've
>> map imported dma-bufs (Panfrost, Lima) and they already don't allow
>> to
>> do that, I think we're good.
>
> So can I have an ack from Rob here or are there still questions that
> this
> might go boom?
>
> Dmitry, since you have a bunch of patches merged now I think would
> also be
> good to get commit rights so you can drive this more yourself. I've
> asked
> Daniel Stone to help you out with getting that.
I *think* we'd be ok with this on msm, mostly just by dumb luck.
Because the dma-buf's we import will be self-import. I'm less sure
about panfrost (src/panfrost/lib/pan_bo.c doesn't seem to have a
special path for imported dma-bufs either, and in that case they won't
be self-imports.. but I guess no one has tried to run android cts on
panfrost).
>>>
>>> The last time I tried to mmap dma-buf imported to Panfrost didn't work
>>> because Panfrost didn't implement something needed for that. I'll need
>>> to take a look again because can't recall what it was.
>>> Upd: I re-checked Panfrost using today's linux-next and mapping of
>>> imported dma-buf works, I mapped imported buf from video decoder.
>>> Apparently previously I had some local kernel change that broke the mapping.
>>>
What about something less drastic to start, like (apologies for
hand-edited patch):
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 86d670c71286..fc9ec42fa0ab 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object
*obj, unsigned long obj_size,
{
int ret;
+ WARN_ON_ONCE(obj->import_attach);
>>>
>>> This will hang NVIDIA Tegra, which is what this patch fixed initially.
>>> If neither of upstream DRM drivers need to map imported dma-bufs and
>>> never needed, then why do we need this?
>>
>> oh, tegra isn't using shmem helpers? I assumed it was. Well my point
>> was to make a more targeted fail on tegra, and a WARN_ON for everyone
>> else to make it clear that what they are doing is
Re: (subset) [PATCH v2 0/7] Devm helpers for regulator get and enable
On Tue, Aug 16, 2022 at 11:06:21AM +, Vaittinen, Matti wrote: > I wonder if writing such 'release callbacks' is compulsory? I mean, if I > was writing a driver to some new (to me) subsystem and was required to > write an explicit release-callback for a resource - then it'd surely > rang a bell about potentially double freeing stuff with devm. Especially > if the doc stated the callback can be called after the driver has been > detached. Generally yes, thoguh people can and do leave them blank and it's easy enough to do some cleanup in there that assumes that the device is still present and not think the device might've gone away especially if the hardware isn't practically hotpluggable. signature.asc Description: PGP signature
Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi Brian,
On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote:
> Caution: EXT Email
>
> Hi,
>
> On Mon, Aug 08, 2022 at 02:39:53PM +, Olivier Masse wrote:
> > Hi Brian,
> >
> > On ven., 2022-08-05 at 16:41 +0100, Brian Starkey wrote:
> > > Caution: EXT Email
> > >
> > > Hi Olivier,
> > >
> > > Thanks, I think this is looking much better.
> > >
> > > I'd like to know how others feel about landing this heap; there's
> > > been
> > > push-back in the past about heaps in device-tree and discussions
> > > around how "custom" heaps should be treated (though IMO this is
> > > quite
> > > a generic one).
> > >
> > > On Fri, Aug 05, 2022 at 03:53:28PM +0200, Olivier Masse wrote:
> > > > add Linaro secure heap bindings: linaro,secure-heap
> > > > use genalloc to allocate/free buffer from buffer pool.
> > > > buffer pool info is from dts.
> > > > use sg_table instore the allocated memory info, the length of
> > > > sg_table is 1.
> > > > implement secure_heap_buf_ops to implement buffer share in
> > > > difference device:
> > > > 1. Userspace passes this fd to all drivers it wants this buffer
> > > > to share with: First the filedescriptor is converted to a
> > > > _buf
> > > > using
> > > > dma_buf_get(). Then the buffer is attached to the device using
> > > > dma_buf_attach().
> > > > 2. Once the buffer is attached to all devices userspace can
> > > > initiate DMA
> > > > access to the shared buffer. In the kernel this is done by
> > > > calling
> > > > dma_buf_map_attachment()
> > > > 3. get sg_table with dma_buf_map_attachment in difference
> > > > device.
> > > >
> > >
> > > I think this commit message could use a little rework. A few
> > > thoughts:
> > >
> > > * The bindings are in a separate commit, so seems strange to
> > > mention
> > > here.
> >
> > what about:
> > "add Linaro secure heap compatible reserved memory: linaro,secure-
> > heap"
> >
>
> I'd say something like:
>
> Add a dma-buf heap to allocate secure buffers from a reserved-memory
> region.
>
> ..snip
ok right.
>
> > > > +
> > > > +static struct sg_table *secure_heap_map_dma_buf(struct
> > > > dma_buf_attachment *attachment,
> > > > + enum
> > > > dma_data_direction direction)
> > > > +{
> > > > + struct secure_heap_attachment *a = attachment->priv;
> > > > +
> > > > + return a->table;
> > >
> > > I think you still need to implement mapping and unmapping using
> > > the
> > > DMA APIs. For example devices might be behind IOMMUs and the
> > > buffer
> > > will need mapping into the IOMMU.
> >
> > Devices that will need access to the buffer must be in secure.
> > The tee driver will only need the scatter-list table to get dma
> > address
> > and len. Mapping will be done in the TEE.
> > Please find tee_shm_register_fd in the following commit
> >
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flinaro-swg%2Flinux%2Fcommit%2F41e21e5c405530590dc2dd10b2a8dbe64589840fdata=05%7C01%7Colivier.masse%40nxp.com%7C6b3d47f1e15c41a8cf7108da7c813ef6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637959191795668899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=OKZhaNevD5dj7Wjm6zbZlij0mPA9XYyio1NAN3VjTVM%3Dreserved=0
> >
> > This patch need to be up-streamed as well.
> >
>
> Interesting, that's not how the devices I've worked on operated.
>
> Are you saying that you have to have a display controller driver
> running in the TEE to display one of these buffers?
In fact the display controller is managing 3 plans : UI, PiP and
video. The video plan is protected in secure as you can see on slide
11:
https://static.linaro.org/connect/san19/presentations/san19-107.pdf
The DCSS (display controller) is able to read from the protected secure
heap and composition result is send directly to the HDMI/HDCP port.
> If everything
> needs to be in the TEE, then why even have these buffers allocated
> by non-secure Linux at all?
The TEE is only doing decryption using the HW Crypto Accelerator
(CAAM).
The CAAM will read from a non protected encrypted buffer to write clear
content to a secure buffer allocated with DMABUF and mapped in secure
by OPTEE OS.
>
> I would have expected there to be HW enforcement of buffer access,
> but for the display driver to be in non-secure Linux. That's how
> TZMP1 works:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstatic.linaro.org%2Fconnect%2Fhkg18%2Fpresentations%2Fhkg18-408.pdfdata=05%7C01%7Colivier.masse%40nxp.com%7C6b3d47f1e15c41a8cf7108da7c813ef6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637959191795668899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=XVpI93dXYu%2BGswLE8dcYboq%2FAWzSJn9j9LMlngpr238%3Dreserved=0
>
> Looking at this SDP presentation, that also seems to be the case
> there:
>
Re: [RFC PATCH 02/14] drm/qaic: Add uapi and core driver file
On 15/08/2022 21:42, Jeffrey Hugo wrote:
> Add the QAIC driver uapi file and core driver file that binds to the PCIe
> device. The core driver file also creates the drm device and manages all
> the interconnections between the different parts of the driver.
Thank you for your patch. There is something to discuss/improve.
>
> Change-Id: I28854e8a5dacda217439be2f65a4ab67d4dccd1e
This has to go...
(...)
> +static int qaic_pci_probe(struct pci_dev *pdev,
> + const struct pci_device_id *id)
> +{
> + int ret;
> + int i;
> + int mhi_irq;
> + struct qaic_device *qdev;
> +
> + qdev = kzalloc(sizeof(*qdev), GFP_KERNEL);
> + if (!qdev) {
return -ENOMEM;
> + ret = -ENOMEM;
> + goto qdev_fail;
> + }
> +
> + if (id->device == PCI_DEV_AIC100) {
> + qdev->num_dbc = 16;
> + qdev->dbc = kcalloc(qdev->num_dbc, sizeof(*qdev->dbc),
> + GFP_KERNEL);
Why not devm?
> + if (!qdev->dbc) {
> + ret = -ENOMEM;
> + goto device_id_fail;
> + }
> + } else {
> + pci_dbg(pdev, "%s: No matching device found for device id %d\n",
> + __func__, id->device);
How this can happen?
> + ret = -EINVAL;
> + goto device_id_fail;
> + }
> +
> + qdev->cntl_wq = alloc_workqueue("qaic_cntl", WQ_UNBOUND, 0);
> + if (!qdev->cntl_wq) {
> + ret = -ENOMEM;
> + goto wq_fail;
> + }
> + qdev->tele_wq = alloc_workqueue("qaic_tele", WQ_UNBOUND, 0);
> + if (!qdev->tele_wq) {
> + ret = -ENOMEM;
> + goto tele_wq_fail;
> + }
> + qdev->ssr_wq = alloc_workqueue("qaic_ssr", WQ_UNBOUND, 0);
> + if (!qdev->ssr_wq) {
> + ret = -ENOMEM;
> + goto ssr_wq_fail;
> + }
> + pci_set_drvdata(pdev, qdev);
> + qdev->pdev = pdev;
> + mutex_init(>cntl_mutex);
> + INIT_LIST_HEAD(>cntl_xfer_list);
> + init_srcu_struct(>dev_lock);
> + mutex_init(>tele_mutex);
> + INIT_LIST_HEAD(>tele_xfer_list);
> + INIT_LIST_HEAD(>bootlog);
> + mutex_init(>bootlog_mutex);
> + INIT_LIST_HEAD(>qaic_drm_devices);
> + mutex_init(>qaic_drm_devices_mutex);
> + for (i = 0; i < qdev->num_dbc; ++i) {
> + mutex_init(>dbc[i].handle_lock);
> + spin_lock_init(>dbc[i].xfer_lock);
> + idr_init(>dbc[i].buf_handles);
> + qdev->dbc[i].qdev = qdev;
> + qdev->dbc[i].id = i;
> + INIT_LIST_HEAD(>dbc[i].xfer_list);
> + init_srcu_struct(>dbc[i].ch_lock);
> + init_waitqueue_head(>dbc[i].dbc_release);
> + INIT_LIST_HEAD(>dbc[i].bo_lists);
> + }
> +
> + qdev->bars = pci_select_bars(pdev, IORESOURCE_MEM);
> +
> + /* make sure the device has the expected BARs */
> + if (qdev->bars != (BIT(0) | BIT(2) | BIT(4))) {
> + pci_dbg(pdev, "%s: expected BARs 0, 2, and 4 not found in
> device. Found 0x%x\n",
> + __func__, qdev->bars);
> + ret = -EINVAL;
> + goto bar_fail;
> + }
> +
> + ret = pci_enable_device(pdev);
> + if (ret)
> + goto enable_fail;
> +
> + ret = pci_request_selected_regions(pdev, qdev->bars, "aic100");
> + if (ret)
> + goto request_regions_fail;
> +
> + pci_set_master(pdev);
> +
> + ret = dma_set_mask(>dev, DMA_BIT_MASK(64));
> + if (ret)
> + goto dma_mask_fail;
> + ret = dma_set_coherent_mask(>dev, DMA_BIT_MASK(64));
> + if (ret)
> + goto dma_mask_fail;
> + ret = dma_set_max_seg_size(>dev, UINT_MAX);
> + if (ret)
> + goto dma_mask_fail;
> +
> + qdev->bar_0 = pci_ioremap_bar(pdev, 0);
> + if (!qdev->bar_0) {
> + ret = -ENOMEM;
> + goto ioremap_0_fail;
> + }
> +
> + qdev->bar_2 = pci_ioremap_bar(pdev, 2);
> + if (!qdev->bar_2) {
> + ret = -ENOMEM;
> + goto ioremap_2_fail;
> + }
> +
> + for (i = 0; i < qdev->num_dbc; ++i)
> + qdev->dbc[i].dbc_base = qdev->bar_2 + QAIC_DBC_OFF(i);
> +
> + ret = pci_alloc_irq_vectors(pdev, 1, 32, PCI_IRQ_MSI);
> + if (ret < 0)
> + goto alloc_irq_fail;
> +
> + if (ret < 32) {
> + pci_err(pdev, "%s: Requested 32 MSIs. Obtained %d MSIs which
> is less than the 32 required.\n",
> + __func__, ret);
> + ret = -ENODEV;
> + goto invalid_msi_config;
> + }
> +
> + mhi_irq = pci_irq_vector(pdev, 0);
> + if (mhi_irq < 0) {
> + ret = mhi_irq;
> + goto get_mhi_irq_fail;
> + }
> +
> + for (i = 0; i < qdev->num_dbc; ++i) {
> + ret = devm_request_threaded_irq(>dev,
> + pci_irq_vector(pdev, i + 1),
> +
Re: [PATCH v2 0/6] i2c: Make remove callback return void
> As some conflicts are expected I sent this early after -rc1 such that it > can be included early into next and be put on an immutable branch for > subsystems to resolve merge conflicts. I pushed the series out now, so it should hit -next tomorrow. The immutable branch is here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/make_remove_callback_void-immutable Enjoy! signature.asc Description: PGP signature
Re: [PATCH v2 1/6] drm/i2c/sil164: Drop no-op remove function
On Mon, Aug 15, 2022 at 10:02:25AM +0200, Uwe Kleine-König wrote: > A remove callback that just returns 0 is equivalent to no callback at all > as can be seen in i2c_device_remove(). So simplify accordingly. > > Signed-off-by: Uwe Kleine-König Applied to an immutable branch, thanks! signature.asc Description: PGP signature
Re: (subset) [PATCH v2 0/7] Devm helpers for regulator get and enable
On Tue, Aug 16, 2022 at 07:56:06AM +0300, Matti Vaittinen wrote: > On 8/16/22 01:55, Mark Brown wrote: > > On Tue, Aug 16, 2022 at 12:17:17AM +0300, Laurent Pinchart wrote: > > > These devres helpers give > > > a false sense of security to driver authors and they will end up > > > introducing problems, the same way that devm_kzalloc() makes it > > > outrageously easy to crash the kernel by disconnecting a device that is > > > in use. > I think this is going a bit "off-topic" but I'd like to understand what is > behind this statement? From device-writer's perspective - I don't know much > better alternatives to free up the memory. I don't see how freeing stuff at > .remove would be any better? As far as I understand - if someone is using > driver's resources after the device has gone and the driver is detached, > then there is not much the driver could do to free-up the stuff be it devm > or not? This sounds like fundamentally different problem (to me). If a driver has done something like create a file that's accessible to userspace then that file may be held open by userspace even after the device goes away, the driver that created the file needs to ensure that any storage that's used by the file remains allocated until the file is also freed (typically this is data specific to the file rather than the full device data). Similar situations can exist elsewhere, that's just the common case. There'll be a deletion callback on whatever other object causes the problem, the allocation needs to be reference counted against both the the device and whatever other users there might be. > > That's a different conversation, and a totally > > valid one especially when you start looking at things like implementing > > userspace APIs which need to cope with hardware going away while still > > visible to userspace. > This is interesting. It's not easy for me to spot how devm changes things > here? If we consider some removable device - then I guess also the .remove() > is ran only after HW has already gone? Yes, devm might make the time window > when userspace can see hardware that has gone longer but does it bring any > new problem there? It seems to me devm can make hitting the spot more likely > - but I don't think it brings completely new issues? (Well, I may be wrong > here - wouldn't be the first time :]) See above, something can still know the device was there even after it's gone. signature.asc Description: PGP signature
[PATCH 2/3] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_xrgb2101010()
Extend the existing test cases to test the conversion from XRGB to
XRGB2101010.
Signed-off-by: José Expósito
---
.../gpu/drm/tests/drm_format_helper_test.c| 63 +++
1 file changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 08d08e7ab19a..d8536db4de1e 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -32,6 +32,11 @@ struct convert_to_rgb888_result {
const u8 expected[TEST_BUF_SIZE];
};
+struct convert_to_xrgb2101010_result {
+ unsigned int dst_pitch;
+ const u32 expected[TEST_BUF_SIZE];
+};
+
struct convert_xrgb_case {
const char *name;
unsigned int pitch;
@@ -40,6 +45,7 @@ struct convert_xrgb_case {
struct convert_to_rgb332_result rgb332_result;
struct convert_to_rgb565_result rgb565_result;
struct convert_to_rgb888_result rgb888_result;
+ struct convert_to_xrgb2101010_result xrgb2101010_result;
};
static struct convert_xrgb_case convert_xrgb_cases[] = {
@@ -61,6 +67,10 @@ static struct convert_xrgb_case convert_xrgb_cases[]
= {
.dst_pitch = 0,
.expected = { 0x00, 0x00, 0xFF },
},
+ .xrgb2101010_result = {
+ .dst_pitch = 0,
+ .expected = { 0x3FF0 },
+ },
},
{
.name = "single_pixel_clip_rectangle",
@@ -83,6 +93,10 @@ static struct convert_xrgb_case convert_xrgb_cases[]
= {
.dst_pitch = 0,
.expected = { 0x00, 0x00, 0xFF },
},
+ .xrgb2101010_result = {
+ .dst_pitch = 0,
+ .expected = { 0x3FF0 },
+ },
},
{
/* Well known colors: White, black, red, green, blue, magenta,
@@ -132,6 +146,15 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
},
},
+ .xrgb2101010_result = {
+ .dst_pitch = 0,
+ .expected = {
+ 0x3FFF, 0x,
+ 0x3FF0, 0x000FFC00,
+ 0x03FF, 0x3FF003FF,
+ 0x3C00, 0x000F,
+ },
+ },
},
{
/* Randomly picked colors. Full buffer within the clip area. */
@@ -175,6 +198,14 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
},
},
+ .xrgb2101010_result = {
+ .dst_pitch = 20,
+ .expected = {
+ 0x03844672, 0x0444D414, 0x2A20300C, 0x,
0x,
+ 0x1B1705CD, 0x03844672, 0x0444D414, 0x,
0x,
+ 0x2A20300C, 0x1B1705CD, 0x03844672, 0x,
0x,
+ },
+ },
},
};
@@ -319,10 +350,42 @@ static void xrgb_to_rgb888_test(struct kunit *test)
KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
}
+static void xrgb_to_xrgb2101010_test(struct kunit *test)
+{
+ const struct convert_xrgb_case *params = test->param_value;
+ const struct convert_to_xrgb2101010_result *result =
>xrgb2101010_result;
+ size_t dst_size;
+ __u32 *buf = NULL;
+ __u32 *xrgb = NULL;
+ struct iosys_map dst, src;
+
+ struct drm_framebuffer fb = {
+ .format = drm_format_info(DRM_FORMAT_XRGB),
+ .pitches = { params->pitch, 0, 0 },
+ };
+
+ dst_size = conversion_buf_size(DRM_FORMAT_XRGB2101010,
+ result->dst_pitch, >clip);
+ KUNIT_ASSERT_GT(test, dst_size, 0);
+
+ buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
+ iosys_map_set_vaddr(, buf);
+
+ xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
+ iosys_map_set_vaddr(, xrgb);
+
+ drm_fb_xrgb_to_xrgb2101010(, >dst_pitch, , ,
>clip);
+ buf = le32buf_to_cpu(test, buf, TEST_BUF_SIZE);
+ KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
+}
+
static struct kunit_case drm_format_helper_test_cases[] = {
KUNIT_CASE_PARAM(xrgb_to_rgb332_test, convert_xrgb_gen_params),
KUNIT_CASE_PARAM(xrgb_to_rgb565_test, convert_xrgb_gen_params),
[PATCH 1/3] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb888()
Extend the existing test cases to test the conversion from XRGB to
RGB888.
Signed-off-by: José Expósito
---
.../gpu/drm/tests/drm_format_helper_test.c| 65 +++
1 file changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 828487071796..08d08e7ab19a 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -27,6 +27,11 @@ struct convert_to_rgb565_result {
const u16 expected_swab[TEST_BUF_SIZE];
};
+struct convert_to_rgb888_result {
+ unsigned int dst_pitch;
+ const u8 expected[TEST_BUF_SIZE];
+};
+
struct convert_xrgb_case {
const char *name;
unsigned int pitch;
@@ -34,6 +39,7 @@ struct convert_xrgb_case {
const u32 xrgb[TEST_BUF_SIZE];
struct convert_to_rgb332_result rgb332_result;
struct convert_to_rgb565_result rgb565_result;
+ struct convert_to_rgb888_result rgb888_result;
};
static struct convert_xrgb_case convert_xrgb_cases[] = {
@@ -51,6 +57,10 @@ static struct convert_xrgb_case convert_xrgb_cases[]
= {
.expected = { 0xF800 },
.expected_swab = { 0x00F8 },
},
+ .rgb888_result = {
+ .dst_pitch = 0,
+ .expected = { 0x00, 0x00, 0xFF },
+ },
},
{
.name = "single_pixel_clip_rectangle",
@@ -69,6 +79,10 @@ static struct convert_xrgb_case convert_xrgb_cases[]
= {
.expected = { 0xF800 },
.expected_swab = { 0x00F8 },
},
+ .rgb888_result = {
+ .dst_pitch = 0,
+ .expected = { 0x00, 0x00, 0xFF },
+ },
},
{
/* Well known colors: White, black, red, green, blue, magenta,
@@ -109,6 +123,15 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0xE0FF, 0xFF07,
},
},
+ .rgb888_result = {
+ .dst_pitch = 0,
+ .expected = {
+ 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0xFF, 0x00, 0xFF, 0x00,
+ 0xFF, 0x00, 0x00, 0xFF, 0x00, 0xFF,
+ 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
+ },
+ },
},
{
/* Randomly picked colors. Full buffer within the clip area. */
@@ -141,6 +164,17 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0x00A8, 0x8E6B, 0x330A, 0x, 0x,
},
},
+ .rgb888_result = {
+ .dst_pitch = 15,
+ .expected = {
+ 0x9C, 0x44, 0x0E, 0x05, 0x4D, 0x11, 0x03, 0x03,
0xA8,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x73, 0x70, 0x6C, 0x9C, 0x44, 0x0E, 0x05, 0x4D,
0x11,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x03, 0x03, 0xA8, 0x73, 0x70, 0x6C, 0x9C, 0x44,
0x0E,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ },
+ },
},
};
@@ -255,9 +289,40 @@ static void xrgb_to_rgb565_test(struct kunit *test)
KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected_swab, dst_size), 0);
}
+static void xrgb_to_rgb888_test(struct kunit *test)
+{
+ const struct convert_xrgb_case *params = test->param_value;
+ const struct convert_to_rgb888_result *result = >rgb888_result;
+ size_t dst_size;
+ __u8 *buf = NULL;
+ __u32 *xrgb = NULL;
+ struct iosys_map dst, src;
+
+ struct drm_framebuffer fb = {
+ .format = drm_format_info(DRM_FORMAT_XRGB),
+ .pitches = { params->pitch, 0, 0 },
+ };
+
+ dst_size = conversion_buf_size(DRM_FORMAT_RGB888, result->dst_pitch,
+ >clip);
+ KUNIT_ASSERT_GT(test, dst_size, 0);
+
+ buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
+ iosys_map_set_vaddr(, buf);
+
+ xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
+ iosys_map_set_vaddr(, xrgb);
+
+ drm_fb_xrgb_to_rgb888(, >dst_pitch, , ,
>clip);
+ KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
+}
+
static struct kunit_case drm_format_helper_test_cases[] = {
KUNIT_CASE_PARAM(xrgb_to_rgb332_test, convert_xrgb_gen_params),
[PATCH 3/3] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_gray8()
Extend the existing test cases to test the conversion from XRGB to
grayscale.
Signed-off-by: José Expósito
---
.../gpu/drm/tests/drm_format_helper_test.c| 62 +++
1 file changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index d8536db4de1e..2f548aa51a30 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -37,6 +37,11 @@ struct convert_to_xrgb2101010_result {
const u32 expected[TEST_BUF_SIZE];
};
+struct convert_to_gray8_result {
+ unsigned int dst_pitch;
+ const u8 expected[TEST_BUF_SIZE];
+};
+
struct convert_xrgb_case {
const char *name;
unsigned int pitch;
@@ -46,6 +51,7 @@ struct convert_xrgb_case {
struct convert_to_rgb565_result rgb565_result;
struct convert_to_rgb888_result rgb888_result;
struct convert_to_xrgb2101010_result xrgb2101010_result;
+ struct convert_to_gray8_result gray8_result;
};
static struct convert_xrgb_case convert_xrgb_cases[] = {
@@ -71,6 +77,10 @@ static struct convert_xrgb_case convert_xrgb_cases[]
= {
.dst_pitch = 0,
.expected = { 0x3FF0 },
},
+ .gray8_result = {
+ .dst_pitch = 0,
+ .expected = { 0x4C },
+ },
},
{
.name = "single_pixel_clip_rectangle",
@@ -97,6 +107,10 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
.dst_pitch = 0,
.expected = { 0x3FF0 },
},
+ .gray8_result = {
+ .dst_pitch = 0,
+ .expected = { 0x4C },
+ },
},
{
/* Well known colors: White, black, red, green, blue, magenta,
@@ -155,6 +169,15 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0x3C00, 0x000F,
},
},
+ .gray8_result = {
+ .dst_pitch = 0,
+ .expected = {
+ 0xFF, 0x00,
+ 0x4C, 0x99,
+ 0x19, 0x66,
+ 0xE5, 0xB2,
+ },
+ },
},
{
/* Randomly picked colors. Full buffer within the clip area. */
@@ -206,6 +229,14 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0x2A20300C, 0x1B1705CD, 0x03844672, 0x,
0x,
},
},
+ .gray8_result = {
+ .dst_pitch = 5,
+ .expected = {
+ 0x3C, 0x33, 0x34, 0x00, 0x00,
+ 0x6F, 0x3C, 0x33, 0x00, 0x00,
+ 0x34, 0x6F, 0x3C, 0x00, 0x00,
+ },
+ },
},
};
@@ -381,11 +412,42 @@ static void xrgb_to_xrgb2101010_test(struct kunit
*test)
KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
}
+static void xrgb_to_gray8_test(struct kunit *test)
+{
+ const struct convert_xrgb_case *params = test->param_value;
+ const struct convert_to_gray8_result *result = >gray8_result;
+ size_t dst_size;
+ __u8 *buf = NULL;
+ __u32 *xrgb = NULL;
+ struct iosys_map dst, src;
+
+ struct drm_framebuffer fb = {
+ .format = drm_format_info(DRM_FORMAT_XRGB),
+ .pitches = { params->pitch, 0, 0 },
+ };
+
+ dst_size = conversion_buf_size(DRM_FORMAT_R8, result->dst_pitch,
+ >clip);
+ KUNIT_ASSERT_GT(test, dst_size, 0);
+
+ buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
+ iosys_map_set_vaddr(, buf);
+
+ xrgb = le32buf_to_cpu(test, params->xrgb, TEST_BUF_SIZE);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
+ iosys_map_set_vaddr(, xrgb);
+
+ drm_fb_xrgb_to_gray8(, >dst_pitch, , ,
>clip);
+ KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
+}
+
static struct kunit_case drm_format_helper_test_cases[] = {
KUNIT_CASE_PARAM(xrgb_to_rgb332_test, convert_xrgb_gen_params),
KUNIT_CASE_PARAM(xrgb_to_rgb565_test, convert_xrgb_gen_params),
KUNIT_CASE_PARAM(xrgb_to_rgb888_test, convert_xrgb_gen_params),
KUNIT_CASE_PARAM(xrgb_to_xrgb2101010_test,
convert_xrgb_gen_params),
+ KUNIT_CASE_PARAM(xrgb_to_gray8_test, convert_xrgb_gen_params),
{}
};
--
2.25.1
[PATCH 0/3] KUnit tests for RGB888, XRGB2101010 and grayscale
Hello everyone, This series is a follow up on my work adding KUnit test to the XRGB conversion functions. This time RGB888, XRGB2101010 and gray8 are added. Best wishes, Jose José Expósito (3): drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_rgb888() drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_xrgb2101010() drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_gray8() .../gpu/drm/tests/drm_format_helper_test.c| 190 ++ 1 file changed, 190 insertions(+) -- 2.25.1
Re: [PATCH 2/4] dt-bindings: display: sun6i-dsi: Add the A100 variant
On 13/08/2022 01:58, Samuel Holland wrote: > Hi Krzysztof, > > On 8/12/22 5:49 AM, Krzysztof Kozlowski wrote: >> On 12/08/2022 10:42, Samuel Holland wrote: >>> The "40nm" MIPI DSI controller found in the A100 and D1 SoCs has the >>> same register layout as previous SoC integrations. However, its module >>> clock now comes from the TCON, which means it no longer runs at a fixed >>> rate, so this needs to be distinguished in the driver. >>> >>> The controller also now uses pins on Port D instead of dedicated pins, >>> so it drops the separate power domain. >>> >>> Signed-off-by: Samuel Holland >>> --- >>> Removal of the vcc-dsi-supply is maybe a bit questionable. Since there >>> is no "VCC-DSI" pin anymore, it's not obvious which pin actually does >>> power the DSI controller/PHY. Possibly power comes from VCC-PD or VCC-IO >>> or VCC-LVDS. So far, all boards have all of these as always-on supplies, >>> so it is hard to test. >>> >>> .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 28 +++ >>> 1 file changed, 23 insertions(+), 5 deletions(-) >>> >>> diff --git >>> a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >>> >>> b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >>> index ae55ef3fb1fe..c53c25b87bd4 100644 >>> --- >>> a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >>> +++ >>> b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >>> @@ -12,9 +12,14 @@ maintainers: >>> >>> properties: >>>compatible: >>> -enum: >>> - - allwinner,sun6i-a31-mipi-dsi >>> - - allwinner,sun50i-a64-mipi-dsi >>> +oneOf: >>> + - enum: >>> + - allwinner,sun6i-a31-mipi-dsi >>> + - allwinner,sun50i-a64-mipi-dsi >>> + - allwinner,sun50i-a100-mipi-dsi >> >> While you are moving code, how about bringing alphabetical order? > > I have put the sun*i prefix in numeric order, which matches (almost) all of > our 5 is before 6, so strictly numerical order would be: allwinner,sun50i-a64-mipi-dsi allwinner,sun50i-a100-mipi-dsi allwinner,sun6i-a31-mipi-dsi > other bindings. It roughly corresponds to chronological order as well. It > doesn't make much sense to me to sort sun50i (ARM64 SoCs) between sun5i and > sun6i (early ARMv7 SoCs). However if you say you already implemented some order (obvious for Allwinner folks), then of course it is fine with me. I just hope other people will get figure out this order, so they can maintain it. So assuming there is some order: Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 3/3] i915-pmu: Add extra check NULL
On Tue, 16 Aug 2022, Denis Arefev wrote:
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
The subject prefix should be something along the lines of
"drm/i915/pmu".
The subject is misleading; there are no functional changes here, just
whitespace changes. I'm guessing you intended to send something else?
Finally, the commit message is primarily for describing why the change
is being made, not to advertize organizations or tools.
BR,
Jani.
>
> Signed-off-by: Denis Arefev
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 34a7f0ef1f67..33db49ffac3d 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -704,8 +704,7 @@ static void i915_pmu_disable(struct perf_event *event)
>* Decrement the reference count and clear the enabled
>* bitmask when the last listener on an event goes away.
>*/
> - if(engine != NULL)
> - {
> + if (engine != NULL) {
> if (--engine->pmu.enable_count[sample] == 0)
> engine->pmu.enable &= ~BIT(sample);
> }
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH] MAINTAINERS: Update email of Neil Armstrong
From: Neil Armstrong My professional e-mail will change and the BayLibre one will bounce after mid-september of 2022. This updates the MAINTAINERS file, the YAML bindings and adds an entry in the .mailmap file. Signed-off-by: Neil Armstrong --- .mailmap | 1 + .../amlogic/amlogic,meson-gx-ao-secure.yaml | 2 +- .../display/amlogic,meson-dw-hdmi.yaml| 2 +- .../bindings/display/amlogic,meson-vpu.yaml | 2 +- .../display/bridge/analogix,anx7814.yaml | 2 +- .../bindings/display/bridge/ite,it66121.yaml | 2 +- .../display/panel/sgd,gktw70sdae4se.yaml | 2 +- .../bindings/i2c/amlogic,meson6-i2c.yaml | 2 +- .../mailbox/amlogic,meson-gxbb-mhu.yaml | 2 +- .../bindings/media/amlogic,axg-ge2d.yaml | 2 +- .../bindings/media/amlogic,gx-vdec.yaml | 2 +- .../media/amlogic,meson-gx-ao-cec.yaml| 2 +- .../devicetree/bindings/mfd/khadas,mcu.yaml | 2 +- .../bindings/net/amlogic,meson-dwmac.yaml | 2 +- .../bindings/phy/amlogic,axg-mipi-dphy.yaml | 2 +- .../phy/amlogic,meson-g12a-usb2-phy.yaml | 2 +- .../phy/amlogic,meson-g12a-usb3-pcie-phy.yaml | 2 +- .../bindings/power/amlogic,meson-ee-pwrc.yaml | 2 +- .../bindings/reset/amlogic,meson-reset.yaml | 2 +- .../bindings/rng/amlogic,meson-rng.yaml | 2 +- .../bindings/serial/amlogic,meson-uart.yaml | 2 +- .../bindings/soc/amlogic/amlogic,canvas.yaml | 2 +- .../bindings/spi/amlogic,meson-gx-spicc.yaml | 2 +- .../bindings/spi/amlogic,meson6-spifc.yaml| 2 +- .../usb/amlogic,meson-g12a-usb-ctrl.yaml | 2 +- .../watchdog/amlogic,meson-gxbb-wdt.yaml | 2 +- MAINTAINERS | 20 +-- 27 files changed, 36 insertions(+), 35 deletions(-) diff --git a/.mailmap b/.mailmap index 2ed1cf869175..04fb67be9b0b 100644 --- a/.mailmap +++ b/.mailmap @@ -303,6 +303,7 @@ Morten Welinder Mythri P K Nadia Yvette Chambers William Lee Irwin III Nathan Chancellor +Neil Armstrong Nguyen Anh Quynh Nicholas Piggin Nicholas Piggin diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml index 6cc74523ebfd..1748f1605cc7 100644 --- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml @@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#; title: Amlogic Meson Firmware registers Interface maintainers: - - Neil Armstrong + - Neil Armstrong description: | The Meson SoCs have a register bank with status and data shared with the diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml index 2e208d2fc98f..7cdffdb131ac 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml @@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#; title: Amlogic specific extensions to the Synopsys Designware HDMI Controller maintainers: - - Neil Armstrong + - Neil Armstrong allOf: - $ref: /schemas/sound/name-prefix.yaml# diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml index 047fd69e0377..6655a93b1874 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml @@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#; title: Amlogic Meson Display Controller maintainers: - - Neil Armstrong + - Neil Armstrong description: | The Amlogic Meson Display controller is composed of several components diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml index bce96b5b0db0..4a5e5d9d6f90 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml @@ -8,7 +8,7 @@ title: Analogix ANX7814 SlimPort (Full-HD Transmitter) maintainers: - Andrzej Hajda - - Neil Armstrong + - Neil Armstrong - Robert Foss properties: diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml index c6e81f532215..1b2185be92cd 100644 --- a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml @@ -8,7 +8,7 @@ title: ITE it66121 HDMI bridge Device Tree Bindings maintainers: - Phong LE - - Neil Armstrong + - Neil Armstrong description: | The
