Re: mgag200 broken on kernel-6.0-rc3 on DELL/T620
Hi, > Am 02.09.22 um 07:52 schrieb Wang Yugui: > > Hi, > > > > mgag200 broken on kernel-6.0-rc3 on DELL/T620. > > > > See the attachementment file for the graph output. > > Thanks for reporting the bug. We recently refactored some code of the driver. > Can you bisect to the change that introduced the problem? 5.19.3 works well on this DELL/T620. so this problem should be a regression of 6.0. other bisect seem difficult for me. Best Regards Wang Yugui (wangyu...@e16-tech.com) 2022/09/07 > > Best regards > Thomas > > > > > [root@T620 ~]# dmesg |grep -i 'vga\|mga' > > [0.588940] Console: colour VGA+ 80x25 > > [4.918214] pci :0a:00.0: vgaarb: setting as boot VGA device > > [4.919028] pci :0a:00.0: vgaarb: bridge control possible > > [4.919028] pci :0a:00.0: vgaarb: VGA device added: > > decodes=io+mem,owns=io+mem,locks=none > > [4.941058] vgaarb: loaded > > [9.385485] mgag200 :0a:00.0: vgaarb: deactivate vga console > > [9.510688] [drm] Initialized mgag200 1.0.0 20110418 for :0a:00.0 on > > minor 0 > > [9.523145] fbcon: mgag200drmfb (fb0) is primary device > > [9.641543] mgag200 :0a:00.0: [drm] fb0: mgag200drmfb frame buffer > > device > > > > > > more info: > > 1, This DELL/T620 works well with kernel 5.15.63, > > so this is not a hardware error. > > > > 2, DELL/T640 works well with kernel 6.0-rc and 5.15.63. > > both DELL/T620 and DELL/T640 use the driver 'mgag200'. > > > > [root@T640 ~]# dmesg |grep -i 'vga\|mga' > > [ 10.161500] pci :03:00.0: vgaarb: setting as boot VGA device > > [ 10.162463] pci :03:00.0: vgaarb: VGA device added: > > decodes=io+mem,owns=io+mem,locks=none > > [ 10.176527] pci :03:00.0: vgaarb: bridge control possible > > [ 10.182465] vgaarb: loaded > > [ 11.832839] fb0: EFI VGA frame buffer device > > [ 21.303826] mgag200 :03:00.0: vgaarb: deactivate vga console > > [ 21.319498] [drm] Initialized mgag200 1.0.0 20110418 for :03:00.0 on > > minor 0 > > [ 21.330223] fbcon: mgag200drmfb (fb0) is primary device > > [ 21.332140] mgag200 :03:00.0: [drm] > > drm_plane_enable_fb_damage_clips() not called > > [ 21.741629] mgag200 :03:00.0: [drm] fb0: mgag200drmfb frame buffer > > device > > > > Best Regards > > Wang Yugui (wangyu...@e16-tech.com) > > 2022/09/02 > > > -- Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Gesch?ftsführer: Ivo Totev
[PATCH] drm/ttm: Remove unnecessary '0' values from ret
The variable ret is assigned in the judgment branch statement, he does
not need to initialize the assignment.
Signed-off-by: Li zeming
---
include/drm/ttm/ttm_bo_driver.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 897b88f0bd59..1afa891f488a 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -106,7 +106,7 @@ static inline int ttm_bo_reserve(struct ttm_buffer_object
*bo,
bool interruptible, bool no_wait,
struct ww_acquire_ctx *ticket)
{
- int ret = 0;
+ int ret;
if (no_wait) {
bool success;
--
2.18.2
Re: [PATCH 01/12] drm/udl: Restore display mode on resume
On Tue, 06 Sep 2022 22:06:55 +0200,
Daniel Vetter wrote:
>
> On Tue, Aug 16, 2022 at 05:36:44PM +0200, Takashi Iwai wrote:
> > 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
>
> This patch isn't great and incomplete, see
>
> https://lore.kernel.org/dri-devel/YxegiQFAv+OWjjqE@phenom.ffwll.local/
>
> You need cc: stable and fixes: 997d33c35618 and actually just remove the
> entire check :-)
OK, then is something like below?
I already submitted v2 yesterday (as I overlooked your reply), so I'll
respin v3 with this (and your ack) if that's OK.
thanks,
Takashi
-- 8< --
From: Takashi Iwai
Subject: [PATCH] drm/udl: Restore display mode on resume
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.
Actually, the whole check added in udl_simple_display_pipe_enable()
about the crtc_state->mode_changed was bogus. We should drop the
whole check and always apply the mode change in this function.
[ tiwai -- Drop the mode_changed check entirely instead, per Daniel's
suggestion ]
Fixes: 997d33c35618 ("drm/udl: Inline DPMS code into CRTC enable and disable
functions")
Cc:
Signed-off-by: Thomas Zimmermann
Suggested-by: Daniel Vetter
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_modeset.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 169110d8fc2e..34ce5b43c5db 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -382,9 +382,6 @@ 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)
- return;
-
/* enable display */
udl_crtc_write_mode_to_hw(crtc);
}
--
2.35.3
Re: build failure of next-20220906 due to 396369d67549 ("drm: vkms: Add support to the RGB565 format")
On Wed, Sep 07, 2022 at 07:47:32AM +0200, Daniel Vetter wrote:
> On Tue, Sep 06, 2022 at 08:35:49PM -0300, Igor Matheus Andrade Torrente wrote:
> > On 9/6/22 18:26, Sudip Mukherjee wrote:
> > > On Tue, Sep 6, 2022 at 4:59 PM Sudip Mukherjee (Codethink)
> > > wrote:
> > > >
> > > > Hi All,
> > > >
> > > > The builds of next-20220906 fails for mips, xtensa and arm allmodconfig.
> > > >
> > > > The errors in mips and xtensa are:
> > > >
> > > > ERROR: modpost: "__divdi3" [drivers/gpu/drm/vkms/vkms.ko] undefined!
> > > > ERROR: modpost: "__udivdi3" [drivers/gpu/drm/vkms/vkms.ko] undefined!
> > > >
> > > > The error in arm is:
> > > >
> > > > ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/vkms/vkms.ko]
> > > > undefined!
> > > > ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/vkms/vkms.ko]
> > > > undefined!
> > > >
> > > >
> > > > Trying to do a git bisect to find out the offending commit.
> > >
> > > git bisect points to 396369d67549 ("drm: vkms: Add support to the
> > > RGB565 format")
> >
> > Are these architectures incapable of doing 64bits int division?
>
> Yeah 32bit archs in general can't do that, and you have to use the right
> macros because otherwise gcc falls back to its own built-ins, and those
> don't exist in the kernel since the kernel isn't (cannot!) linked against
> any userspace library.
>
> For pretty much this reasons it's really good to build test against 32bit
> x86, or probably more relevant these days, 32bit arm.
Forgot to add: include/math.h for all your division needs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: build failure of next-20220906 due to 396369d67549 ("drm: vkms: Add support to the RGB565 format")
On Tue, Sep 06, 2022 at 08:35:49PM -0300, Igor Matheus Andrade Torrente wrote:
> On 9/6/22 18:26, Sudip Mukherjee wrote:
> > On Tue, Sep 6, 2022 at 4:59 PM Sudip Mukherjee (Codethink)
> > wrote:
> > >
> > > Hi All,
> > >
> > > The builds of next-20220906 fails for mips, xtensa and arm allmodconfig.
> > >
> > > The errors in mips and xtensa are:
> > >
> > > ERROR: modpost: "__divdi3" [drivers/gpu/drm/vkms/vkms.ko] undefined!
> > > ERROR: modpost: "__udivdi3" [drivers/gpu/drm/vkms/vkms.ko] undefined!
> > >
> > > The error in arm is:
> > >
> > > ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/vkms/vkms.ko]
> > > undefined!
> > > ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/vkms/vkms.ko]
> > > undefined!
> > >
> > >
> > > Trying to do a git bisect to find out the offending commit.
> >
> > git bisect points to 396369d67549 ("drm: vkms: Add support to the
> > RGB565 format")
>
> Are these architectures incapable of doing 64bits int division?
Yeah 32bit archs in general can't do that, and you have to use the right
macros because otherwise gcc falls back to its own built-ins, and those
don't exist in the kernel since the kernel isn't (cannot!) linked against
any userspace library.
For pretty much this reasons it's really good to build test against 32bit
x86, or probably more relevant these days, 32bit arm.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On Tue, Sep 06, 2022 at 09:18:09PM +0200, Daniel Vetter wrote: > On Fri, Aug 12, 2022 at 08:03:47AM +0200, Greg KH wrote: > > On Thu, Aug 11, 2022 at 06:52:40PM +0200, Daniel Vetter wrote: > > > On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote: > > > > > > > > > > > > On 8/3/22 15:56, jim.cro...@gmail.com wrote: > > > > > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie > > > > > wrote: > > > > >> > > > > > > > > > >> Hi Jason, Greg, DRM-folk, > > > > >> > > > > >> This adds 'typed' "class FOO" support to dynamic-debug, where 'typed' > > > > >> means either DISJOINT (like drm debug categories), or VERBOSE (like > > > > >> nouveau debug-levels). Use it in DRM modules: core, helpers, and in > > > > >> drivers i915, amdgpu, nouveau. > > > > >> > > > > > > > > > > This revision fell over, on a conflict with something in drm-MUMBLE > > > > > > > > > > Error: patch > > > > > https://urldefense.com/v3/__https://patchwork.freedesktop.org/api/1.0/series/106427/revisions/2/mbox/__;!!GjvTz_vk!UCPl5Uf32cDVwwysMTfaLwoGLWomargFXuR8HjBA3xsUOjxXHXC5hneAkP4iWK91yc-LjjJxWW89-51Z$ > > > > > > > > > > not applied > > > > > Applying: dyndbg: fix static_branch manipulation > > > > > Applying: dyndbg: fix module.dyndbg handling > > > > > Applying: dyndbg: show both old and new in change-info > > > > > Applying: dyndbg: reverse module walk in cat control > > > > > Applying: dyndbg: reverse module.callsite walk in cat control > > > > > Applying: dyndbg: use ESCAPE_SPACE for cat control > > > > > Applying: dyndbg: let query-modname override actual module name > > > > > Applying: dyndbg: add test_dynamic_debug module > > > > > Applying: dyndbg: drop EXPORTed dynamic_debug_exec_queries > > > > > > > > > > Jason, > > > > > those above are decent maintenance patches, particularly the drop > > > > > export. > > > > > It would be nice to trim this unused api this cycle. > > > > > > > > Hi Jim, > > > > > > > > Agreed - I was thinking the same thing. Feel free to add > > > > Acked-by: Jason Baron to those first 9. > > > > > > Does Greg KH usually pick up dyndbg patches or someone else or do I need > > > to do something? Would be great to get some movement here since -rc1 goes > > > out and merging will restart next week. > > > > Yes, I can take these into my tree after -rc1 is out. > > [uncovering from an absolutely impressive cascade of holes :-(] > > Did this happen and I can stop worrying here? I'd like to make sure these > drm debug infra improvements keep moving. I didn't take these, and I think I saw a 6th series sent: https://lore.kernel.org/r/20220904214134.408619-1-jim.cro...@gmail.com If you ack them, I will pick them up. thanks, greg k-h
Re: [PATCH 0/8] Support for NVDEC on Tegra234
On 9/6/22 20:50, Krzysztof Kozlowski wrote: On 06/09/2022 15:28, Mikko Perttunen wrote: From: Mikko Perttunen Hi all, this series adds support for the HW video decoder, NVDEC, on Tegra234 (Orin). The main change is a switch from Falcon to RISC-V for the internal microcontroller, which brings along a change in how the engine is booted. Otherwise it is backwards compatible with earlier versions. You need to describe the dependencies, otherwise I would be free to go with applying memory controllers part. Hi Krzysztof, the memory controller patch can be applied independently. Thanks, Mikko Best regards, Krzysztof
[PATCH] drm/amd/display: fix repeated words in comments
Delete the redundant word 'in'. Signed-off-by: Jilin Yuan --- drivers/gpu/drm/amd/display/dc/dce/dce_audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c index bdb6bac8dd97..c94a966c6612 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c @@ -300,7 +300,7 @@ static void set_high_bit_rate_capable( AZ_REG_WRITE(AZALIA_F0_CODEC_PIN_CONTROL_RESPONSE_HBR, value); } -/* set video latency in in ms/2+1 */ +/* set video latency in ms/2+1 */ static void set_video_latency( struct audio *audio, int latency_in_ms) -- 2.36.1
Re: [PATCH v2 08/15] drm/i915/gvt: Use the new device life cycle helpers
On 2022.09.01 22:37:40 +0800, Kevin Tian wrote:
> Move vfio_device to the start of intel_vgpu as required by the new
> helpers.
>
> Change intel_gvt_create_vgpu() to use intel_vgpu as the first param
> as other vgpu helpers do.
>
> Signed-off-by: Kevin Tian
> Reviewed-by: Jason Gunthorpe
> ---
Looks good to me.
Reviewed-by: Zhenyu Wang
> drivers/gpu/drm/i915/gvt/gvt.h | 5 ++-
> drivers/gpu/drm/i915/gvt/kvmgt.c | 52 ++--
> drivers/gpu/drm/i915/gvt/vgpu.c | 33
> 3 files changed, 50 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
> index 705689e64011..89fab7896fc6 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.h
> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
> @@ -172,6 +172,7 @@ struct intel_vgpu_submission {
> #define KVMGT_DEBUGFS_FILENAME "kvmgt_nr_cache_entries"
>
> struct intel_vgpu {
> + struct vfio_device vfio_device;
> struct intel_gvt *gvt;
> struct mutex vgpu_lock;
> int id;
> @@ -211,7 +212,6 @@ struct intel_vgpu {
>
> u32 scan_nonprivbb;
>
> - struct vfio_device vfio_device;
> struct vfio_region *region;
> int num_regions;
> struct eventfd_ctx *intx_trigger;
> @@ -494,8 +494,7 @@ void intel_gvt_clean_vgpu_types(struct intel_gvt *gvt);
>
> struct intel_vgpu *intel_gvt_create_idle_vgpu(struct intel_gvt *gvt);
> void intel_gvt_destroy_idle_vgpu(struct intel_vgpu *vgpu);
> -struct intel_vgpu *intel_gvt_create_vgpu(struct intel_gvt *gvt,
> - struct intel_vgpu_type *type);
> +int intel_gvt_create_vgpu(struct intel_vgpu *vgpu, struct intel_vgpu_type
> *type);
> void intel_gvt_destroy_vgpu(struct intel_vgpu *vgpu);
> void intel_gvt_release_vgpu(struct intel_vgpu *vgpu);
> void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu, bool dmlr,
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index e3cd58946477..41bba40feef8 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1546,7 +1546,33 @@ static const struct attribute_group
> *intel_vgpu_groups[] = {
> NULL,
> };
>
> +static int intel_vgpu_init_dev(struct vfio_device *vfio_dev)
> +{
> + struct mdev_device *mdev = to_mdev_device(vfio_dev->dev);
> + struct device *pdev = mdev_parent_dev(mdev);
> + struct intel_gvt *gvt = kdev_to_i915(pdev)->gvt;
> + struct intel_vgpu_type *type;
> + struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
> +
> + type = >types[mdev_get_type_group_id(mdev)];
> + if (!type)
> + return -EINVAL;
> +
> + vgpu->gvt = gvt;
> + return intel_gvt_create_vgpu(vgpu, type);
> +}
> +
> +static void intel_vgpu_release_dev(struct vfio_device *vfio_dev)
> +{
> + struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
> +
> + intel_gvt_destroy_vgpu(vgpu);
> + vfio_free_device(vfio_dev);
> +}
> +
> static const struct vfio_device_ops intel_vgpu_dev_ops = {
> + .init = intel_vgpu_init_dev,
> + .release= intel_vgpu_release_dev,
> .open_device= intel_vgpu_open_device,
> .close_device = intel_vgpu_close_device,
> .read = intel_vgpu_read,
> @@ -1558,35 +1584,28 @@ static const struct vfio_device_ops
> intel_vgpu_dev_ops = {
>
> static int intel_vgpu_probe(struct mdev_device *mdev)
> {
> - struct device *pdev = mdev_parent_dev(mdev);
> - struct intel_gvt *gvt = kdev_to_i915(pdev)->gvt;
> - struct intel_vgpu_type *type;
> struct intel_vgpu *vgpu;
> int ret;
>
> - type = >types[mdev_get_type_group_id(mdev)];
> - if (!type)
> - return -EINVAL;
> -
> - vgpu = intel_gvt_create_vgpu(gvt, type);
> + vgpu = vfio_alloc_device(intel_vgpu, vfio_device, >dev,
> + _vgpu_dev_ops);
> if (IS_ERR(vgpu)) {
> gvt_err("failed to create intel vgpu: %ld\n", PTR_ERR(vgpu));
> return PTR_ERR(vgpu);
> }
>
> - vfio_init_group_dev(>vfio_device, >dev,
> - _vgpu_dev_ops);
> -
> dev_set_drvdata(>dev, vgpu);
> ret = vfio_register_emulated_iommu_dev(>vfio_device);
> - if (ret) {
> - intel_gvt_destroy_vgpu(vgpu);
> - return ret;
> - }
> + if (ret)
> + goto out_put_vdev;
>
> gvt_dbg_core("intel_vgpu_create succeeded for mdev: %s\n",
>dev_name(mdev_dev(mdev)));
> return 0;
> +
> +out_put_vdev:
> + vfio_put_device(>vfio_device);
> + return ret;
> }
>
> static void intel_vgpu_remove(struct mdev_device *mdev)
> @@ -1595,7 +1614,8 @@ static void intel_vgpu_remove(struct mdev_device *mdev)
>
> if (WARN_ON_ONCE(vgpu->attached))
> return;
> - intel_gvt_destroy_vgpu(vgpu);
> +
> + vfio_put_device(>vfio_device);
> }
>
> static struct mdev_driver
Re: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
On 2022.09.06 19:36:56 +0800, Zheng Hacker wrote:
> Hi Greg,
>
> Alex has explained how we figured out the patch. We did analyze the
> code and found it possible to reach the vulnerability code. But we
> have no physical device in hand to test the driver. So we'd like to
> discuss with developers to see if the issue exists or not.
>
> Best regards,
> Zheng Wang.
>
> Greg KH ???2022???9???5? 16:04?
> >
> > On Mon, Sep 05, 2022 at 03:46:09PM +0800, Zheng Hacker wrote:
> > > I rewrote the letter. Hope it works.
> > >
> > > There is a double-free security bug in split_2MB_gtt_entry.
> > >
> > > Here is a calling chain :
> > > ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry.
> > > If intel_gvt_dma_map_guest_page failed, it will call
> > > ppgtt_invalidate_spt, which will finally call ppgtt_free_spt and
> > > kfree(spt). But the caller does not notice that, and it will call
> > > ppgtt_free_spt again in error path.
> > >
It's a little mess in code so in theory it might be possible but
intel_gvt_dma_map_guest_page won't fail in practise...
> > > Fix this by returning the result of ppgtt_invalidate_spt to
> > > split_2MB_gtt_entry.
> > >
I don't see why changing ret value can fix this issue, as it doesn't change
any behavior e.g caller of ppgtt_populate_spt to handle possible different
error return.
As current code looks assuming that ppgtt_invalidate_spt would free spt in good
case,
I think the real cleanup should split that assumption and handle free in error
case properly.
> > > Signed-off-by: Zheng Wang
This misses proper email address.
thanks
> > >
> > > ---
> > > drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c
> > > b/drivers/gpu/drm/i915/gvt/gtt.c
> > > index ce0eb03709c3..9f14fded8c0c 100644
> > > --- a/drivers/gpu/drm/i915/gvt/gtt.c
> > > +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> > > @@ -1215,7 +1215,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu
> > > *vgpu,
> > > ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn +
> > > sub_index,
> > >PAGE_SIZE, _addr);
> > > if (ret) {
> > > - ppgtt_invalidate_spt(spt);
> > > + ret = ppgtt_invalidate_spt(spt);
> > > return ret;
> >
> > But now you just lost the original error, shouldn't this succeed even if
> > intel_gvt_dma_map_guest_page() failed?
> >
> > And how are you causing intel_gvt_dma_map_guest_page() to fail in a real
> > system?
> >
> > thanks,
> >
> > greg k-h
signature.asc
Description: PGP signature
Re: [PATCH v1 10/11] watchdog: bd9576_wdt: switch to using devm_fwnode_gpiod_get()
On Mon, Sep 05, 2022 at 03:09:05PM -0700, Guenter Roeck wrote:
> On 9/5/22 12:47, Dmitry Torokhov wrote:
> [ ... ]
> > > We know that count is either 1 or 2 here, so strictly speaking
> > > if (count == 1) {
> > > } else {
> > > }
> > > would be sufficient. On the other side, that depends on ARRAY_SIZE() being
> > > exactly 2, so
> > > if (count == 1) {
> > > } else if (count == 2) {
> > > }
> > > would also make sense. Either way is fine with me. I'll leave it up
> > > to Dmitry to decide what he wants to do.
> >
> > My goal is to drop usage of devm_gpiod_get_from_of_node(), beyond that I
> > do not have strong preferences either way really. It is probing code, so
> > performance is not critical, but I'm obviously satisfied with how the
> > code looks now, or I would not have sent it.
> >
>
> Good point.
>
> Reviewed-by: Guenter Roeck
Guenter, individual patches are going through maintainer's trees, will
you take this one?
Thanks.
--
Dmitry
RE: [PATCH v2 01/15] vfio: Add helpers for unifying vfio_device life cycle
> From: Christoph Hellwig > Sent: Tuesday, September 6, 2022 5:42 PM > > What is the point? This adds indirect calls, and actually creates > more boilerplate code in the drivers. i.g. when using this code there > is more, and harder to read code. The point is to align with struct device life cycle when it's introduced to vfio_device. The object is released via put_device() then what would be the alternative if the driver doesn't provide a @release callback? and with @release then naturally @init is also expected. Most added code is in patch1 for implementing new helpers and patch15 for introducing struct device. Remaining addition is relatively small when scattered in each driver and most is due to creating new functions hence new local variables. and IMHO the readability is improved as it clearly contains the init/release logic around the device object. Thanks Kevin
[linux-next:master] BUILD REGRESSION 840126e36e8ff272cb63158646433fa1324533d9
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 840126e36e8ff272cb63158646433fa1324533d9 Add linux-next specific files for 20220906 Error/Warning reports: https://lore.kernel.org/linux-mm/202209021204.dclzollr-...@intel.com https://lore.kernel.org/linux-mm/202209042337.fqi69rlv-...@intel.com https://lore.kernel.org/linux-mm/202209060229.dvuyxjbv-...@intel.com https://lore.kernel.org/linux-mm/202209070728.o3stvgvt-...@intel.com https://lore.kernel.org/llvm/202208312208.hjwleien-...@intel.com Error/Warning: (recently discovered and may have been fixed) ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/vkms/vkms.ko] undefined! ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/vkms/vkms.ko] undefined! ERROR: modpost: "__divdi3" [drivers/gpu/drm/vkms/vkms.ko] undefined! ERROR: modpost: "__udivdi3" [drivers/gpu/drm/vkms/vkms.ko] undefined! arm-linux-gnueabi-ld: vkms_formats.c:(.text+0x1e98): undefined reference to `__divdi3' drivers/base/regmap/regmap-mmio.c:221:17: error: implicit declaration of function 'writesb'; did you mean 'writeb'? [-Werror=implicit-function-declaration] drivers/base/regmap/regmap-mmio.c:224:17: error: implicit declaration of function 'writesw'; did you mean 'writew'? [-Werror=implicit-function-declaration] drivers/base/regmap/regmap-mmio.c:227:17: error: implicit declaration of function 'writesl'; did you mean 'writel'? [-Werror=implicit-function-declaration] drivers/base/regmap/regmap-mmio.c:231:17: error: implicit declaration of function 'writesq'; did you mean 'writeq'? [-Werror=implicit-function-declaration] drivers/base/regmap/regmap-mmio.c:231:17: error: implicit declaration of function 'writesq'; did you mean 'writesl'? [-Werror=implicit-function-declaration] drivers/base/regmap/regmap-mmio.c:358:17: error: implicit declaration of function 'readsb'; did you mean 'readb'? [-Werror=implicit-function-declaration] drivers/base/regmap/regmap-mmio.c:361:17: error: implicit declaration of function 'readsw'; did you mean 'readw'? [-Werror=implicit-function-declaration] drivers/base/regmap/regmap-mmio.c:364:17: error: implicit declaration of function 'readsl'; did you mean 'readl'? [-Werror=implicit-function-declaration] drivers/base/regmap/regmap-mmio.c:368:17: error: implicit declaration of function 'readsq'; did you mean 'readq'? [-Werror=implicit-function-declaration] drivers/base/regmap/regmap-mmio.c:368:17: error: implicit declaration of function 'readsq'; did you mean 'readsl'? [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/imu_v11_0_3.c:139:6: warning: no previous prototype for 'imu_v11_0_3_program_rlc_ram' [-Wmissing-prototypes] drivers/gpu/drm/drm_atomic_helper.c:802: warning: expecting prototype for drm_atomic_helper_check_wb_connector_state(). Prototype was for drm_atomic_helper_check_wb_encoder_state() instead drivers/gpu/drm/vkms/vkms_formats.c:(.text+0x4b0): undefined reference to `__divdi3' drivers/gpu/drm/vkms/vkms_formats.c:259: undefined reference to `__divdi3' drivers/gpu/drm/vkms/vkms_plane.c:105 vkms_plane_atomic_update() warn: variable dereferenced before check 'fb' (see line 103) drivers/scsi/qla2xxx/qla_os.c:2854:23: warning: assignment to 'struct trace_array *' from 'int' makes pointer from integer without a cast [-Wint-conversion] drivers/usb/host/ehci-platform.c:56:19: warning: 'hcd_name' defined but not used [-Wunused-const-variable=] drivers/usb/host/ohci-platform.c:44:19: warning: 'hcd_name' defined but not used [-Wunused-const-variable=] include/linux/string.h:303:42: warning: 'strnlen' specified bound 4 exceeds source size 3 [-Wstringop-overread] kernel/bpf/memalloc.c:344 bpf_mem_alloc_destroy() error: potentially dereferencing uninitialized 'c'. kismet: WARNING: unmet direct dependencies detected for PINCTRL_IMX when selected by PINCTRL_IMX8MM ld: drivers/gpu/drm/vkms/vkms_formats.c:260: undefined reference to `__divdi3' ld: vkms_formats.c:(.text+0x47f): undefined reference to `__divdi3' mips-linux-ld: vkms_formats.c:(.text+0x384): undefined reference to `__divdi3' mips-linux-ld: vkms_formats.c:(.text.argb_u16_to_RGB565+0xd0): undefined reference to `__divdi3' mipsel-linux-ld: drivers/gpu/drm/vkms/vkms_formats.c:(.text+0x4d8): undefined reference to `__divdi3' sound/soc/codecs/tas2562.c:442:13: warning: variable 'ret' set but not used [-Wunused-but-set-variable] vkms_formats.c:(.text+0x455): undefined reference to `__divdi3' vkms_formats.c:(.text.argb_u16_to_RGB565+0xb0): undefined reference to `__divdi3' Unverified Error/Warning (likely false positive, please contact us if interested): drivers/usb/host/ehci-atmel.c:28:19: warning: unused variable 'hcd_name' [-Wunused-const-variable] drivers/usb/host/ehci-exynos.c:35:19: warning: unused variable 'hcd_name' [-Wunused-const-variable] drivers/usb/host/ehci-npcm7xx.c:27:19: warning: unused variable 'hcd_name' [-Wunused-const-variable] drivers/usb/
Re: [PATCH v3 04/14] drm/i915: Drop intel_gt_tile_cleanup()
On Tue, Sep 06, 2022 at 04:49:24PM -0700, Matt Roper wrote: Unmapping of the MMIO range can be done as a DRM-managed action, which will take care of the unmapping on device teardown and error paths. This will also ensure proper ordering with respect to other DRM-managed actions that we'll be using to clean up non-primary GTs in upcoming patches. We have not yet enabled any non-root GTs in the driver yet, so the kfree() of the GT structure is effectively dead code. When we do start enabling non-root GTs in upcoming patches, those are going to be using DRM-managed allocations tied to the device lifetime, so we don't need to explicitly free them (and kfree would be incorrect anyway). Signed-off-by: Matt Roper Reviewed-by: Lucas De Marchi Lucas De Marchi
[PATCH v3 11/14] drm/i915/mtl: Add gsi_offset when emitting aux table invalidation
The aux table invalidation registers are a bit unique --- they're
engine-centric registers that reside in the GSI register space rather
than within the engines' regular MMIO ranges. That means that when
issuing invalidation on engines in the standalone media GT, the GSI
offset must be added to the regular MMIO offset for the invalidation
registers.
Cc: Aravind Iddamsetty
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 15 ++-
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 3 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 ++---
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 98645797962f..e49fa6fa6aee 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -165,10 +165,12 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
-u32 *gen12_emit_aux_table_inv(u32 *cs, const i915_reg_t inv_reg)
+u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t
inv_reg)
{
+ u32 gsi_offset = gt->uncore->gsi_offset;
+
*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
- *cs++ = i915_mmio_reg_offset(inv_reg);
+ *cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
*cs++ = AUX_INV;
*cs++ = MI_NOOP;
@@ -254,7 +256,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
if (!HAS_FLAT_CCS(rq->engine->i915)) {
/* hsdes: 1809175790 */
- cs = gen12_emit_aux_table_inv(cs, GEN12_GFX_CCS_AUX_NV);
+ cs = gen12_emit_aux_table_inv(rq->engine->gt,
+ cs, GEN12_GFX_CCS_AUX_NV);
}
*cs++ = preparser_disable(false);
@@ -313,9 +316,11 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (aux_inv) { /* hsdes: 1809175790 */
if (rq->engine->class == VIDEO_DECODE_CLASS)
- cs = gen12_emit_aux_table_inv(cs, GEN12_VD0_AUX_NV);
+ cs = gen12_emit_aux_table_inv(rq->engine->gt,
+ cs, GEN12_VD0_AUX_NV);
else
- cs = gen12_emit_aux_table_inv(cs, GEN12_VE0_AUX_NV);
+ cs = gen12_emit_aux_table_inv(rq->engine->gt,
+ cs, GEN12_VE0_AUX_NV);
}
if (mode & EMIT_INVALIDATE)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index 32e3d2b831bb..e4d24c811dd6 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -13,6 +13,7 @@
#include "intel_gt_regs.h"
#include "intel_gpu_commands.h"
+struct intel_gt;
struct i915_request;
int gen8_emit_flush_rcs(struct i915_request *rq, u32 mode);
@@ -45,7 +46,7 @@ u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *rq,
u32 *cs);
u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs);
u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs);
-u32 *gen12_emit_aux_table_inv(u32 *cs, const i915_reg_t inv_reg);
+u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t
inv_reg);
static inline u32 *
__gen8_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1, u32 offset)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 070cec4ff8a4..08214683e130 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1278,7 +1278,8 @@ gen12_emit_indirect_ctx_rcs(const struct intel_context
*ce, u32 *cs)
/* hsdes: 1809175790 */
if (!HAS_FLAT_CCS(ce->engine->i915))
- cs = gen12_emit_aux_table_inv(cs, GEN12_GFX_CCS_AUX_NV);
+ cs = gen12_emit_aux_table_inv(ce->engine->gt,
+ cs, GEN12_GFX_CCS_AUX_NV);
/* Wa_16014892111 */
if (IS_DG2(ce->engine->i915))
@@ -1304,9 +1305,11 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context
*ce, u32 *cs)
/* hsdes: 1809175790 */
if (!HAS_FLAT_CCS(ce->engine->i915)) {
if (ce->engine->class == VIDEO_DECODE_CLASS)
- cs = gen12_emit_aux_table_inv(cs, GEN12_VD0_AUX_NV);
+ cs = gen12_emit_aux_table_inv(ce->engine->gt,
+ cs, GEN12_VD0_AUX_NV);
else if (ce->engine->class == VIDEO_ENHANCEMENT_CLASS)
- cs = gen12_emit_aux_table_inv(cs, GEN12_VE0_AUX_NV);
+ cs = gen12_emit_aux_table_inv(ce->engine->gt,
+ cs, GEN12_VE0_AUX_NV);
}
return cs;
--
2.37.2
[PATCH v3 12/14] drm/i915/xelpmp: Expose media as another GT
Xe_LPM+ platforms have "standalone media." I.e., the media unit is
designed as an additional GT with its own engine list, GuC, forcewake,
etc. Let's allow platforms to include media GTs in their device info.
v2:
- Simplify GSI register handling and split it out to a separate patch
for ease of review. (Daniele)
Cc: Aravind Iddamsetty
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/intel_gt.c | 6
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_sa_media.c | 39
drivers/gpu/drm/i915/gt/intel_sa_media.h | 15 +
drivers/gpu/drm/i915/i915_pci.c | 14 +
7 files changed, 84 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..e83e4cd46968 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -123,6 +123,7 @@ gt-y += \
gt/intel_ring.o \
gt/intel_ring_submission.o \
gt/intel_rps.o \
+ gt/intel_sa_media.o \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index aa0e40987798..9b9c0ea73b7f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -31,6 +31,7 @@
#include "intel_rc6.h"
#include "intel_renderstate.h"
#include "intel_rps.h"
+#include "intel_sa_media.h"
#include "intel_gt_sysfs.h"
#include "intel_uncore.h"
#include "shmem_utils.h"
@@ -864,6 +865,11 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
ret = intel_gt_tile_setup(gt, phys_addr +
gtdef->mapping_base);
break;
+ case GT_MEDIA:
+ ret = intel_sa_mediagt_setup(gt, phys_addr +
gtdef->mapping_base,
+gtdef->gsi_offset);
+ break;
+
case GT_PRIMARY:
/* Primary GT should not appear in extra GT list */
default:
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index d414785003cc..fb2c56777480 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1578,4 +1578,12 @@
#define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
+/*
+ * Standalone Media's non-engine GT registers are located at their regular GT
+ * offsets plus 0x38. This extra offset is stored inside the intel_uncore
+ * structure so that the existing code can be used for both GTs without
+ * modification.
+ */
+#define MTL_MEDIA_GSI_BASE 0x38
+
#endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 82dc28643572..726695936a79 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -84,6 +84,7 @@ struct gt_defaults {
enum intel_gt_type {
GT_PRIMARY,
GT_TILE,
+ GT_MEDIA,
};
struct intel_gt {
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c
b/drivers/gpu/drm/i915/gt/intel_sa_media.c
new file mode 100644
index ..8c5c519457cc
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_sa_media.h"
+
+int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t phys_addr,
+ u32 gsi_offset)
+{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_uncore *uncore;
+
+ uncore = drmm_kzalloc(>drm, sizeof(*uncore), GFP_KERNEL);
+ if (!uncore)
+ return -ENOMEM;
+
+ uncore->gsi_offset = gsi_offset;
+
+ intel_gt_common_init_early(gt);
+ intel_uncore_init_early(uncore, gt);
+
+ /*
+* Standalone media shares the general MMIO space with the primary
+* GT. We'll re-use the primary GT's mapping.
+*/
+ uncore->regs = i915->uncore.regs;
+ if (drm_WARN_ON(>drm, uncore->regs == NULL))
+ return -EIO;
+
+ gt->uncore = uncore;
+ gt->phys_addr = phys_addr;
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.h
b/drivers/gpu/drm/i915/gt/intel_sa_media.h
new file mode 100644
index ..3afb310de932
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+#ifndef
[PATCH v3 14/14] drm/i915/mtl: Hook up interrupts for standalone media
Top-level handling of standalone media interrupts will be processed as
part of the primary GT's interrupt handler (since primary and media GTs
share an MMIO space, unlike remote tile setups). When we get down to
the point of handling engine interrupts, we need to take care to lookup
VCS and VECS engines in the media GT rather than the primary.
There are also a couple of additional "other" instance bits that
correspond to the media GT's GuC and media GT's power management
interrupts; we need to direct those to the media GT instance as well.
Bspec: 45605
Cc: Anusha Srivatsa
Signed-off-by: Matt Roper
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 19 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
drivers/gpu/drm/i915/gt/intel_sa_media.c | 7 +++
drivers/gpu/drm/i915/i915_drv.h | 3 +++
4 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 0dfd0c42d00d..f26882fdc24c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -59,11 +59,17 @@ static void
gen11_other_irq_handler(struct intel_gt *gt, const u8 instance,
const u16 iir)
{
+ struct intel_gt *media_gt = gt->i915->media_gt;
+
if (instance == OTHER_GUC_INSTANCE)
return guc_irq_handler(>uc.guc, iir);
+ if (instance == OTHER_MEDIA_GUC_INSTANCE && media_gt)
+ return guc_irq_handler(_gt->uc.guc, iir);
if (instance == OTHER_GTPM_INSTANCE)
return gen11_rps_irq_handler(>rps, iir);
+ if (instance == OTHER_MEDIA_GTPM_INSTANCE && media_gt)
+ return gen11_rps_irq_handler(_gt->rps, iir);
if (instance == OTHER_KCR_INSTANCE)
return intel_pxp_irq_handler(>pxp, iir);
@@ -81,6 +87,18 @@ gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
{
struct intel_engine_cs *engine;
+ /*
+* Platforms with standalone media have their media engines in another
+* GT.
+*/
+ if (MEDIA_VER(gt->i915) >= 13 &&
+ (class == VIDEO_DECODE_CLASS || class == VIDEO_ENHANCEMENT_CLASS)) {
+ if (!gt->i915->media_gt)
+ goto err;
+
+ gt = gt->i915->media_gt;
+ }
+
if (instance <= MAX_ENGINE_INSTANCE)
engine = gt->engine_class[class][instance];
else
@@ -89,6 +107,7 @@ gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
if (likely(engine))
return intel_engine_cs_irq(engine, iir);
+err:
WARN_ONCE(1, "unhandled engine interrupt class=0x%x, instance=0x%x\n",
class, instance);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index fb2c56777480..2275ee47da95 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1554,6 +1554,8 @@
#define OTHER_GTPM_INSTANCE 1
#define OTHER_KCR_INSTANCE 4
#define OTHER_GSC_INSTANCE 6
+#define OTHER_MEDIA_GUC_INSTANCE 16
+#define OTHER_MEDIA_GTPM_INSTANCE17
#define GEN11_IIR_REG_SELECTOR(x) _MMIO(0x190070 + ((x) * 4))
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c
b/drivers/gpu/drm/i915/gt/intel_sa_media.c
index 5516e9c363a4..e8f3d18c12b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_sa_media.c
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
@@ -36,5 +36,12 @@ int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t
phys_addr,
gt->uncore = uncore;
gt->phys_addr = phys_addr;
+ /*
+* For current platforms we can assume there's only a single
+* media GT and cache it for quick lookup.
+*/
+ drm_WARN_ON(>drm, i915->media_gt);
+ i915->media_gt = gt;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f010be8df851..5aff92e106ef 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -365,6 +365,9 @@ struct drm_i915_private {
struct kobject *sysfs_gt;
+ /* Quick lookup of media GT (current platforms only have one) */
+ struct intel_gt *media_gt;
+
struct {
struct i915_gem_contexts {
spinlock_t lock; /* locks list */
--
2.37.2
[PATCH v3 05/14] drm/i915: Prepare more multi-GT initialization
We're going to introduce an additional intel_gt for MTL's media unit
soon. Let's provide a bit more multi-GT initialization framework in
preparation for that. The initialization will pull the list of GTs for
a platform from the device info structure. Although necessary for the
immediate MTL media enabling, this same framework will also be used
farther down the road when we enable remote tiles on xehpsdv and pvc.
v2:
- Re-add missing test for !HAS_EXTRA_GT_LIST in intel_gt_probe_all().
v3:
- Move intel_gt_definition struct to intel_gt_types.h. (Jani)
- Drop gtdef->setup(). For now we'll just use a switch() based on GT
type since we don't have too many different handlers for the
forseeable future. (Jani)
Cc: Aravind Iddamsetty
Cc: Jani Nikula
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 59 ++-
drivers/gpu/drm/i915/gt/intel_gt.h| 1 -
drivers/gpu/drm/i915/gt/intel_gt_types.h | 15 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_device_info.h | 3 +
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
7 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 275ad72940c1..41acc285e8bf 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -736,7 +736,7 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt
*gt)
u16 vdbox_mask;
u16 vebox_mask;
- info->engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
+ GEM_BUG_ON(!info->engine_mask);
if (GRAPHICS_VER(i915) < 11)
return info->engine_mask;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 663a4798fb2e..85c75375391c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -807,8 +807,10 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
{
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct intel_gt *gt = >gt0;
+ const struct intel_gt_definition *gtdef;
phys_addr_t phys_addr;
unsigned int mmio_bar;
+ unsigned int i;
int ret;
mmio_bar = GRAPHICS_VER(i915) == 2 ? GEN2_GTTMMADR_BAR : GTTMMADR_BAR;
@@ -819,14 +821,69 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
* and it has been already initialized early during probe
* in i915_driver_probe()
*/
+ gt->i915 = i915;
+ gt->name = "Primary GT";
+ gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
+
+ drm_dbg(>drm, "Setting up %s\n", gt->name);
ret = intel_gt_tile_setup(gt, phys_addr);
if (ret)
return ret;
i915->gt[0] = gt;
- /* TODO: add more tiles */
+ if (!HAS_EXTRA_GT_LIST(i915))
+ return 0;
+
+ for (i = 1, gtdef = _INFO(i915)->extra_gt_list[i - 1];
+gtdef->name != NULL;
+i++, gtdef = _INFO(i915)->extra_gt_list[i - 1]) {
+ gt = drmm_kzalloc(>drm, sizeof(*gt), GFP_KERNEL);
+ if (!gt) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ gt->i915 = i915;
+ gt->name = gtdef->name;
+ gt->type = gtdef->type;
+ gt->info.engine_mask = gtdef->engine_mask;
+ gt->info.id = i;
+
+ drm_dbg(>drm, "Setting up %s\n", gt->name);
+ if (GEM_WARN_ON(range_overflows_t(resource_size_t,
+ gtdef->mapping_base,
+ SZ_16M,
+ pci_resource_len(pdev,
mmio_bar {
+ ret = -ENODEV;
+ goto err;
+ }
+
+ switch (gtdef->type) {
+ case GT_TILE:
+ ret = intel_gt_tile_setup(gt, phys_addr +
gtdef->mapping_base);
+ break;
+
+ case GT_PRIMARY:
+ /* Primary GT should not appear in extra GT list */
+ default:
+ MISSING_CASE(gtdef->type);
+ ret = -ENODEV;
+ }
+
+ if (ret)
+ goto err;
+
+ i915->gt[i] = gt;
+ }
+
return 0;
+
+err:
+ i915_probe_error(i915, "Failed to initialize %s! (%d)\n", gtdef->name,
ret);
+ intel_gt_release_all(i915);
+
+ return ret;
}
int intel_gt_tiles_init(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 40b06adf509a..4d8779529cc2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
[PATCH v3 02/14] drm/i915: Only hook up uncore->debug for primary uncore
The original intent of intel_uncore_mmio_debug as described in commit
0a9b26306d6a ("drm/i915: split out uncore_mmio_debug") was to be a
singleton structure that could be shared between multiple GTs' uncore
objects in a multi-tile system. Somehow we went off track and
started allocating separate instances of this structure for each GT,
which defeats that original goal.
But in reality, there isn't even a need to share the mmio_debug between
multiple GTs; on all modern platforms (i.e., everything after gen7)
unclaimed register accesses are something that can only be detected for
display registers. There's no point in grabbing the debug spinlock and
checking for unclaimed accesses on an uncore used by an xehpsdv or pvc
remote tile GT, or the uncore used by a mtl standalone media GT since
all of the display accesses go through the primary intel_uncore.
The simplest solution is to simply leave uncore->debug NULL on all
intel_uncore instances except for the primary one. This will allow us
to avoid the pointless debug spinlock acquisition we've been doing on
MMIO accesses coming in through these intel_uncores.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt.c | 9 -
drivers/gpu/drm/i915/i915_driver.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 23 ++-
drivers/gpu/drm/i915/intel_uncore.h | 3 +--
4 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index e4bac2431e41..a82b5e2e0d83 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -781,21 +781,13 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
int ret;
if (!gt_is_root(gt)) {
- struct intel_uncore_mmio_debug *mmio_debug;
struct intel_uncore *uncore;
uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
if (!uncore)
return -ENOMEM;
- mmio_debug = kzalloc(sizeof(*mmio_debug), GFP_KERNEL);
- if (!mmio_debug) {
- kfree(uncore);
- return -ENOMEM;
- }
-
gt->uncore = uncore;
- gt->uncore->debug = mmio_debug;
__intel_gt_init_early(gt);
}
@@ -817,7 +809,6 @@ intel_gt_tile_cleanup(struct intel_gt *gt)
intel_uncore_cleanup_mmio(gt->uncore);
if (!gt_is_root(gt)) {
- kfree(gt->uncore->debug);
kfree(gt->uncore);
kfree(gt);
}
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 56a2bcddb2af..18acba1bc3b0 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -326,7 +326,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
intel_device_info_subplatform_init(dev_priv);
intel_step_init(dev_priv);
- intel_uncore_mmio_debug_init_early(_priv->mmio_debug);
+ intel_uncore_mmio_debug_init_early(dev_priv);
spin_lock_init(_priv->irq_lock);
spin_lock_init(_priv->gpu_error.lock);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e717ea55484a..6841f76533f9 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -44,14 +44,19 @@ fw_domains_get(struct intel_uncore *uncore, enum
forcewake_domains fw_domains)
}
void
-intel_uncore_mmio_debug_init_early(struct intel_uncore_mmio_debug *mmio_debug)
+intel_uncore_mmio_debug_init_early(struct drm_i915_private *i915)
{
- spin_lock_init(_debug->lock);
- mmio_debug->unclaimed_mmio_check = 1;
+ spin_lock_init(>mmio_debug.lock);
+ i915->mmio_debug.unclaimed_mmio_check = 1;
+
+ i915->uncore.debug = >mmio_debug;
}
static void mmio_debug_suspend(struct intel_uncore *uncore)
{
+ if (!uncore->debug)
+ return;
+
spin_lock(>debug->lock);
/* Save and disable mmio debugging for the user bypass */
@@ -67,6 +72,9 @@ static bool check_for_unclaimed_mmio(struct intel_uncore
*uncore);
static void mmio_debug_resume(struct intel_uncore *uncore)
{
+ if (!uncore->debug)
+ return;
+
spin_lock(>debug->lock);
if (!--uncore->debug->suspend_count)
@@ -1705,7 +1713,7 @@ unclaimed_reg_debug(struct intel_uncore *uncore,
const bool read,
const bool before)
{
- if (likely(!uncore->i915->params.mmio_debug))
+ if (likely(!uncore->i915->params.mmio_debug) || !uncore->debug)
return;
/* interrupts are disabled and re-enabled around uncore->lock usage */
@@ -2267,7 +2275,6 @@ void intel_uncore_init_early(struct intel_uncore *uncore,
uncore->i915 = gt->i915;
uncore->gt = gt;
uncore->rpm =
[PATCH v3 08/14] drm/i915: Initialize MMIO access for each GT
In a multi-GT system we need to initialize MMIO access for each GT, not
just the primary GT.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 27 ++-
drivers/gpu/drm/i915/intel_uncore.c | 5 -
drivers/gpu/drm/i915/intel_uncore.h | 3 ++-
3 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 1f46dd1ffaf7..bb9ba1aed1bb 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -431,7 +431,8 @@ static void i915_driver_late_release(struct
drm_i915_private *dev_priv)
*/
static int i915_driver_mmio_probe(struct drm_i915_private *dev_priv)
{
- int ret;
+ struct intel_gt *gt;
+ int ret, i;
if (i915_inject_probe_failure(dev_priv))
return -ENODEV;
@@ -440,17 +441,27 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
if (ret < 0)
return ret;
- ret = intel_uncore_init_mmio(_priv->uncore);
- if (ret)
- return ret;
+ for_each_gt(gt, dev_priv, i) {
+ ret = intel_uncore_init_mmio(gt->uncore);
+ if (ret)
+ return ret;
+
+ ret = drmm_add_action_or_reset(_priv->drm,
+ intel_uncore_fini_mmio,
+ gt->uncore);
+ if (ret)
+ return ret;
+ }
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev_priv);
intel_device_info_runtime_init(dev_priv);
- ret = intel_gt_init_mmio(to_gt(dev_priv));
- if (ret)
- goto err_uncore;
+ for_each_gt(gt, dev_priv, i) {
+ ret = intel_gt_init_mmio(gt);
+ if (ret)
+ goto err_uncore;
+ }
/* As early as possible, scrub existing GPU state before clobbering */
sanitize_gpu(dev_priv);
@@ -459,7 +470,6 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
err_uncore:
intel_teardown_mchbar(dev_priv);
- intel_uncore_fini_mmio(_priv->uncore);
return ret;
}
@@ -471,7 +481,6 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
static void i915_driver_mmio_release(struct drm_i915_private *dev_priv)
{
intel_teardown_mchbar(dev_priv);
- intel_uncore_fini_mmio(_priv->uncore);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 2a32f8a65f34..452b3a31e965 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2455,8 +2455,11 @@ void intel_uncore_prune_engine_fw_domains(struct
intel_uncore *uncore,
}
}
-void intel_uncore_fini_mmio(struct intel_uncore *uncore)
+/* Called via drm-managed action */
+void intel_uncore_fini_mmio(struct drm_device *dev, void *data)
{
+ struct intel_uncore *uncore = data;
+
if (intel_uncore_has_forcewake(uncore)) {
iosf_mbi_punit_acquire();
iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
diff --git a/drivers/gpu/drm/i915/intel_uncore.h
b/drivers/gpu/drm/i915/intel_uncore.h
index 6100d0f4498a..4acb78a03233 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -33,6 +33,7 @@
#include "i915_reg_defs.h"
+struct drm_device;
struct drm_i915_private;
struct intel_runtime_pm;
struct intel_uncore;
@@ -220,7 +221,7 @@ void intel_uncore_prune_engine_fw_domains(struct
intel_uncore *uncore,
bool intel_uncore_unclaimed_mmio(struct intel_uncore *uncore);
bool intel_uncore_arm_unclaimed_mmio_detection(struct intel_uncore *uncore);
void intel_uncore_cleanup_mmio(struct intel_uncore *uncore);
-void intel_uncore_fini_mmio(struct intel_uncore *uncore);
+void intel_uncore_fini_mmio(struct drm_device *dev, void *data);
void intel_uncore_suspend(struct intel_uncore *uncore);
void intel_uncore_resume_early(struct intel_uncore *uncore);
void intel_uncore_runtime_resume(struct intel_uncore *uncore);
--
2.37.2
[PATCH v3 13/14] drm/i915/mtl: Use primary GT's irq lock for media GT
When we hook up interrupts (in the next patch), interrupts for the media
GT are still processed as part of the primary GT's interrupt flow. As
such, we should share the same IRQ lock with the primary GT. Let's
convert gt->irq_lock into a pointer and just point the media GT's
instance at the same lock the primary GT is using.
v2:
- Point media's gt->irq_lock at the primary GT lock properly. (Daniele)
- Fix jump target for intel_root_gt_init_early errors. (Daniele)
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +++---
drivers/gpu/drm/i915/gt/intel_gt.c| 15 +--
drivers/gpu/drm/i915/gt/intel_gt.h| 2 +-
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 16 ++--
drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 8 +++---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 26 +--
drivers/gpu/drm/i915/gt/intel_sa_media.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 24 -
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +--
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +--
drivers/gpu/drm/i915/i915_driver.c| 5 +++-
drivers/gpu/drm/i915/i915_irq.c | 4 +--
drivers/gpu/drm/i915/pxp/intel_pxp.c | 4 +--
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 4 +--
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 14 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 4 +--
17 files changed, 80 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 41acc285e8bf..6e0122b3dca2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1688,9 +1688,9 @@ bool intel_engine_irq_enable(struct intel_engine_cs
*engine)
return false;
/* Caller disables interrupts */
- spin_lock(>gt->irq_lock);
+ spin_lock(engine->gt->irq_lock);
engine->irq_enable(engine);
- spin_unlock(>gt->irq_lock);
+ spin_unlock(engine->gt->irq_lock);
return true;
}
@@ -1701,9 +1701,9 @@ void intel_engine_irq_disable(struct intel_engine_cs
*engine)
return;
/* Caller disables interrupts */
- spin_lock(>gt->irq_lock);
+ spin_lock(engine->gt->irq_lock);
engine->irq_disable(engine);
- spin_unlock(>gt->irq_lock);
+ spin_unlock(engine->gt->irq_lock);
}
void intel_engines_reset_default_submission(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 9b9c0ea73b7f..b59fb03ed274 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -38,7 +38,7 @@
void intel_gt_common_init_early(struct intel_gt *gt)
{
- spin_lock_init(>irq_lock);
+ spin_lock_init(gt->irq_lock);
INIT_LIST_HEAD(>closed_vma);
spin_lock_init(>closed_lock);
@@ -59,14 +59,19 @@ void intel_gt_common_init_early(struct intel_gt *gt)
}
/* Preliminary initialization of Tile 0 */
-void intel_root_gt_init_early(struct drm_i915_private *i915)
+int intel_root_gt_init_early(struct drm_i915_private *i915)
{
struct intel_gt *gt = to_gt(i915);
gt->i915 = i915;
gt->uncore = >uncore;
+ gt->irq_lock = drmm_kzalloc(>drm, sizeof(*gt->irq_lock),
GFP_KERNEL);
+ if (!gt->irq_lock)
+ return -ENOMEM;
intel_gt_common_init_early(gt);
+
+ return 0;
}
static int intel_gt_probe_lmem(struct intel_gt *gt)
@@ -783,12 +788,18 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
if (!gt_is_root(gt)) {
struct intel_uncore *uncore;
+ spinlock_t *irq_lock;
uncore = drmm_kzalloc(>i915->drm, sizeof(*uncore),
GFP_KERNEL);
if (!uncore)
return -ENOMEM;
+ irq_lock = drmm_kzalloc(>i915->drm, sizeof(*irq_lock),
GFP_KERNEL);
+ if (!irq_lock)
+ return -ENOMEM;
+
gt->uncore = uncore;
+ gt->irq_lock = irq_lock;
intel_gt_common_init_early(gt);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index c9a359f35d0f..2ee582e287c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -45,7 +45,7 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc
*gsc)
}
void intel_gt_common_init_early(struct intel_gt *gt);
-void intel_root_gt_init_early(struct drm_i915_private *i915);
+int intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
int intel_gt_init_mmio(struct intel_gt *gt);
int __must_check intel_gt_init_hw(struct intel_gt *gt);
diff --git
[PATCH v3 06/14] drm/i915: Rename and expose common GT early init routine
The common early GT init is needed for initialization of all GT types
(root/primary, remote tile, standalone media). Since standalone media
(coming in a future patch) will be implemented in a separate file,
rename and expose the function for use.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt.c | 6 +++---
drivers/gpu/drm/i915/gt/intel_gt.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 85c75375391c..aa0e40987798 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -35,7 +35,7 @@
#include "intel_uncore.h"
#include "shmem_utils.h"
-static void __intel_gt_init_early(struct intel_gt *gt)
+void intel_gt_common_init_early(struct intel_gt *gt)
{
spin_lock_init(>irq_lock);
@@ -65,7 +65,7 @@ void intel_root_gt_init_early(struct drm_i915_private *i915)
gt->i915 = i915;
gt->uncore = >uncore;
- __intel_gt_init_early(gt);
+ intel_gt_common_init_early(gt);
}
static int intel_gt_probe_lmem(struct intel_gt *gt)
@@ -789,7 +789,7 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
gt->uncore = uncore;
- __intel_gt_init_early(gt);
+ intel_gt_common_init_early(gt);
}
intel_uncore_init_early(gt->uncore, gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 4d8779529cc2..c9a359f35d0f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -44,6 +44,7 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc
*gsc)
return container_of(gsc, struct intel_gt, gsc);
}
+void intel_gt_common_init_early(struct intel_gt *gt);
void intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
int intel_gt_init_mmio(struct intel_gt *gt);
--
2.37.2
[PATCH v3 09/14] drm/i915: Handle each GT on init/release and suspend/resume
In preparation for enabling a second GT, there are a number of GT/uncore
operations that happen during initialization or suspend flows that need
to be performed on each GT, not just the primary,
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 59 +-
1 file changed, 42 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index bb9ba1aed1bb..e5c3cf5045d4 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -310,8 +310,13 @@ static void intel_detect_preproduction_hw(struct
drm_i915_private *dev_priv)
static void sanitize_gpu(struct drm_i915_private *i915)
{
- if (!INTEL_INFO(i915)->gpu_reset_clobbers_display)
- __intel_gt_reset(to_gt(i915), ALL_ENGINES);
+ if (!INTEL_INFO(i915)->gpu_reset_clobbers_display) {
+ struct intel_gt *gt;
+ unsigned int i;
+
+ for_each_gt(gt, i915, i)
+ __intel_gt_reset(gt, ALL_ENGINES);
+ }
}
/**
@@ -730,6 +735,8 @@ static void i915_driver_hw_remove(struct drm_i915_private
*dev_priv)
static void i915_driver_register(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = _priv->drm;
+ struct intel_gt *gt;
+ unsigned int i;
i915_gem_driver_register(dev_priv);
i915_pmu_register(dev_priv);
@@ -749,7 +756,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
- intel_gt_driver_register(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_driver_register(gt);
intel_display_driver_register(dev_priv);
@@ -768,6 +776,9 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
*/
static void i915_driver_unregister(struct drm_i915_private *dev_priv)
{
+ struct intel_gt *gt;
+ unsigned int i;
+
i915_switcheroo_unregister(dev_priv);
intel_unregister_dsm_handler();
@@ -777,7 +788,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
intel_display_driver_unregister(dev_priv);
- intel_gt_driver_unregister(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_driver_unregister(gt);
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
@@ -799,6 +811,8 @@ static void i915_welcome_messages(struct drm_i915_private
*dev_priv)
{
if (drm_debug_enabled(DRM_UT_DRIVER)) {
struct drm_printer p = drm_debug_printer("i915 device info:");
+ struct intel_gt *gt;
+ unsigned int i;
drm_printf(, "pciid=0x%04x rev=0x%02x platform=%s
(subplatform=0x%x) gen=%i\n",
INTEL_DEVID(dev_priv),
@@ -811,7 +825,8 @@ static void i915_welcome_messages(struct drm_i915_private
*dev_priv)
intel_device_info_print(INTEL_INFO(dev_priv),
RUNTIME_INFO(dev_priv), );
i915_print_iommu_status(dev_priv, );
- intel_gt_info_print(_gt(dev_priv)->info, );
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_info_print(>info, );
}
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
@@ -1230,13 +1245,15 @@ static int i915_drm_suspend_late(struct drm_device
*dev, bool hibernation)
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
struct intel_runtime_pm *rpm = _priv->runtime_pm;
- int ret;
+ struct intel_gt *gt;
+ int ret, i;
disable_rpm_wakeref_asserts(rpm);
i915_gem_suspend_late(dev_priv);
- intel_uncore_suspend(_priv->uncore);
+ for_each_gt(gt, dev_priv, i)
+ intel_uncore_suspend(gt->uncore);
intel_power_domains_suspend(dev_priv,
get_suspend_mode(dev_priv, hibernation));
@@ -1368,7 +1385,8 @@ static int i915_drm_resume_early(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
- int ret;
+ struct intel_gt *gt;
+ int ret, i;
/*
* We have a resume ordering issue with the snd-hda driver also
@@ -1422,9 +1440,10 @@ static int i915_drm_resume_early(struct drm_device *dev)
drm_err(_priv->drm,
"Resume prepare failed: %d, continuing anyway\n", ret);
- intel_uncore_resume_early(_priv->uncore);
-
- intel_gt_check_and_clear_faults(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i) {
+ intel_uncore_resume_early(gt->uncore);
+ intel_gt_check_and_clear_faults(gt);
+ }
[PATCH v3 04/14] drm/i915: Drop intel_gt_tile_cleanup()
Unmapping of the MMIO range can be done as a DRM-managed action, which
will take care of the unmapping on device teardown and error paths.
This will also ensure proper ordering with respect to other DRM-managed
actions that we'll be using to clean up non-primary GTs in upcoming
patches.
We have not yet enabled any non-root GTs in the driver yet, so the
kfree() of the GT structure is effectively dead code. When we do start
enabling non-root GTs in upcoming patches, those are going to be using
DRM-managed allocations tied to the device lifetime, so we don't need to
explicitly free them (and kfree would be incorrect anyway).
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 13 +
drivers/gpu/drm/i915/intel_uncore.c | 13 +++--
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index cf7aab7adb30..663a4798fb2e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -803,15 +803,6 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
return 0;
}
-static void
-intel_gt_tile_cleanup(struct intel_gt *gt)
-{
- intel_uncore_cleanup_mmio(gt->uncore);
-
- if (!gt_is_root(gt))
- kfree(gt);
-}
-
int intel_gt_probe_all(struct drm_i915_private *i915)
{
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
@@ -858,10 +849,8 @@ void intel_gt_release_all(struct drm_i915_private *i915)
struct intel_gt *gt;
unsigned int id;
- for_each_gt(gt, i915, id) {
- intel_gt_tile_cleanup(gt);
+ for_each_gt(gt, i915, id)
i915->gt[id] = NULL;
- }
}
void intel_gt_info_print(const struct intel_gt_info *info,
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 6841f76533f9..2a32f8a65f34 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -21,6 +21,7 @@
* IN THE SOFTWARE.
*/
+#include
#include
#include "gt/intel_engine_regs.h"
@@ -2232,6 +2233,11 @@ static int i915_pmic_bus_access_notifier(struct
notifier_block *nb,
return NOTIFY_OK;
}
+static void uncore_unmap_mmio(struct drm_device *drm, void *regs)
+{
+ iounmap(regs);
+}
+
int intel_uncore_setup_mmio(struct intel_uncore *uncore, phys_addr_t phys_addr)
{
struct drm_i915_private *i915 = uncore->i915;
@@ -2260,12 +2266,7 @@ int intel_uncore_setup_mmio(struct intel_uncore *uncore,
phys_addr_t phys_addr)
return -EIO;
}
- return 0;
-}
-
-void intel_uncore_cleanup_mmio(struct intel_uncore *uncore)
-{
- iounmap(uncore->regs);
+ return drmm_add_action_or_reset(>drm, uncore_unmap_mmio,
uncore->regs);
}
void intel_uncore_init_early(struct intel_uncore *uncore,
--
2.37.2
[PATCH v3 10/14] drm/i915/uncore: Add GSI offset to uncore
GT non-engine registers (referred to as "GSI" registers by the spec)
have the same relative offsets on standalone media as they do on the
primary GT, just with an additional "GSI offset" added to their MMIO
address. If we store this GSI offset in the standalone media's
intel_uncore structure, it can be automatically applied to all GSI reg
reads/writes that happen on that GT, allowing us to re-use our existing
GT code with minimal changes.
Forcewake and shadowed register tables for the media GT (which will be
added in a future patch) are listed as final addresses that already
include the GSI offset, so we also need to add the GSI offset before
doing lookups of registers in one of those tables.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c | 10 --
drivers/gpu/drm/i915/intel_uncore.h | 22 --
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 0e139f7d75ed..82dc28643572 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -274,6 +274,7 @@ struct intel_gt_definition {
enum intel_gt_type type;
char *name;
u32 mapping_base;
+ u32 gsi_offset;
intel_engine_mask_t engine_mask;
};
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 452b3a31e965..5cd423c7b646 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -928,6 +928,9 @@ find_fw_domain(struct intel_uncore *uncore, u32 offset)
{
const struct intel_forcewake_range *entry;
+ if (IS_GSI_REG(offset))
+ offset += uncore->gsi_offset;
+
entry = BSEARCH(offset,
uncore->fw_domains_table,
uncore->fw_domains_table_entries,
@@ -1143,6 +1146,9 @@ static bool is_shadowed(struct intel_uncore *uncore, u32
offset)
if (drm_WARN_ON(>i915->drm, !uncore->shadowed_reg_table))
return false;
+ if (IS_GSI_REG(offset))
+ offset += uncore->gsi_offset;
+
return BSEARCH(offset,
uncore->shadowed_reg_table,
uncore->shadowed_reg_table_entries,
@@ -1995,8 +2001,8 @@ static int __fw_domain_init(struct intel_uncore *uncore,
d->uncore = uncore;
d->wake_count = 0;
- d->reg_set = uncore->regs + i915_mmio_reg_offset(reg_set);
- d->reg_ack = uncore->regs + i915_mmio_reg_offset(reg_ack);
+ d->reg_set = uncore->regs + i915_mmio_reg_offset(reg_set) +
uncore->gsi_offset;
+ d->reg_ack = uncore->regs + i915_mmio_reg_offset(reg_ack) +
uncore->gsi_offset;
d->id = domain_id;
diff --git a/drivers/gpu/drm/i915/intel_uncore.h
b/drivers/gpu/drm/i915/intel_uncore.h
index 4acb78a03233..7f1d7903a8f3 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -136,6 +136,16 @@ struct intel_uncore {
spinlock_t lock; /** lock is also taken in irq contexts. */
+ /*
+* Do we need to apply an additional offset to reach the beginning
+* of the basic non-engine GT registers (referred to as "GSI" on
+* newer platforms, or "GT block" on older platforms)? If so, we'll
+* track that here and apply it transparently to registers in the
+* appropriate range to maintain compatibility with our existing
+* register definitions and GT code.
+*/
+ u32 gsi_offset;
+
unsigned int flags;
#define UNCORE_HAS_FORCEWAKE BIT(0)
#define UNCORE_HAS_FPGA_DBG_UNCLAIMED BIT(1)
@@ -294,19 +304,27 @@ intel_wait_for_register_fw(struct intel_uncore *uncore,
2, timeout_ms, NULL);
}
+#define IS_GSI_REG(reg) ((reg) < 0x4)
+
/* register access functions */
#define __raw_read(x__, s__) \
static inline u##x__ __raw_uncore_read##x__(const struct intel_uncore *uncore,
\
i915_reg_t reg) \
{ \
- return read##s__(uncore->regs + i915_mmio_reg_offset(reg)); \
+ u32 offset = i915_mmio_reg_offset(reg); \
+ if (IS_GSI_REG(offset)) \
+ offset += uncore->gsi_offset; \
+ return read##s__(uncore->regs + offset); \
}
#define __raw_write(x__, s__) \
static inline void __raw_uncore_write##x__(const struct intel_uncore *uncore, \
i915_reg_t reg, u##x__ val) \
{ \
- write##s__(val, uncore->regs + i915_mmio_reg_offset(reg)); \
+ u32 offset = i915_mmio_reg_offset(reg); \
+ if (IS_GSI_REG(offset)) \
+ offset += uncore->gsi_offset; \
+ write##s__(val, uncore->regs + offset); \
}
__raw_read(8, b)
__raw_read(16, w)
--
2.37.2
[PATCH v3 03/14] drm/i915: Use managed allocations for extra uncore objects
We're slowly transitioning the init-time kzalloc's of the driver over to
DRM-managed allocations; let's make sure the uncore objects allocated
for non-root GTs are thus allocated.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index a82b5e2e0d83..cf7aab7adb30 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -783,7 +783,7 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
if (!gt_is_root(gt)) {
struct intel_uncore *uncore;
- uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
+ uncore = drmm_kzalloc(>i915->drm, sizeof(*uncore),
GFP_KERNEL);
if (!uncore)
return -ENOMEM;
@@ -808,10 +808,8 @@ intel_gt_tile_cleanup(struct intel_gt *gt)
{
intel_uncore_cleanup_mmio(gt->uncore);
- if (!gt_is_root(gt)) {
- kfree(gt->uncore);
+ if (!gt_is_root(gt))
kfree(gt);
- }
}
int intel_gt_probe_all(struct drm_i915_private *i915)
--
2.37.2
[PATCH v3 01/14] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
Moving the locking for MMIO debug (and the final check for unclaimed
accesses when resuming debug after a userspace-initiated forcewake) will
make it simpler to completely skip MMIO debug handling on uncores that
don't support it in future patches.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 9b81b2543ce2..e717ea55484a 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
intel_uncore_mmio_debug *mmio_debug)
mmio_debug->unclaimed_mmio_check = 1;
}
-static void mmio_debug_suspend(struct intel_uncore_mmio_debug *mmio_debug)
+static void mmio_debug_suspend(struct intel_uncore *uncore)
{
- lockdep_assert_held(_debug->lock);
+ spin_lock(>debug->lock);
/* Save and disable mmio debugging for the user bypass */
- if (!mmio_debug->suspend_count++) {
- mmio_debug->saved_mmio_check = mmio_debug->unclaimed_mmio_check;
- mmio_debug->unclaimed_mmio_check = 0;
+ if (!uncore->debug->suspend_count++) {
+ uncore->debug->saved_mmio_check =
uncore->debug->unclaimed_mmio_check;
+ uncore->debug->unclaimed_mmio_check = 0;
}
+
+ spin_unlock(>debug->lock);
}
-static void mmio_debug_resume(struct intel_uncore_mmio_debug *mmio_debug)
+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
+
+static void mmio_debug_resume(struct intel_uncore *uncore)
{
- lockdep_assert_held(_debug->lock);
+ spin_lock(>debug->lock);
+
+ if (!--uncore->debug->suspend_count)
+ uncore->debug->unclaimed_mmio_check =
uncore->debug->saved_mmio_check;
- if (!--mmio_debug->suspend_count)
- mmio_debug->unclaimed_mmio_check = mmio_debug->saved_mmio_check;
+ if (check_for_unclaimed_mmio(uncore))
+ drm_info(>i915->drm,
+"Invalid mmio detected during user access\n");
+
+ spin_unlock(>debug->lock);
}
static const char * const forcewake_domain_names[] = {
@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct intel_uncore
*uncore)
spin_lock_irq(>lock);
if (!uncore->user_forcewake_count++) {
intel_uncore_forcewake_get__locked(uncore, FORCEWAKE_ALL);
- spin_lock(>debug->lock);
- mmio_debug_suspend(uncore->debug);
- spin_unlock(>debug->lock);
+ mmio_debug_suspend(uncore);
}
spin_unlock_irq(>lock);
}
@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct intel_uncore
*uncore)
{
spin_lock_irq(>lock);
if (!--uncore->user_forcewake_count) {
- spin_lock(>debug->lock);
- mmio_debug_resume(uncore->debug);
-
- if (check_for_unclaimed_mmio(uncore))
- drm_info(>i915->drm,
-"Invalid mmio detected during user access\n");
- spin_unlock(>debug->lock);
-
+ mmio_debug_resume(uncore);
intel_uncore_forcewake_put__locked(uncore, FORCEWAKE_ALL);
}
spin_unlock_irq(>lock);
--
2.37.2
[PATCH v3 07/14] drm/i915: Use a DRM-managed action to release the PCI bridge device
As we start supporting multiple uncore structures in future patches, the
MMIO cleanup (which make also get called mid-init if there's a failure)
will become more complicated. Moving to DRM-managed actions will help
keep things simple.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 18acba1bc3b0..1f46dd1ffaf7 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -105,6 +105,12 @@ static const char irst_name[] = "INT3392";
static const struct drm_driver i915_drm_driver;
+static void i915_release_bridge_dev(struct drm_device *dev,
+ void *bridge)
+{
+ pci_dev_put(bridge);
+}
+
static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
{
int domain = pci_domain_nr(to_pci_dev(dev_priv->drm.dev)->bus);
@@ -115,7 +121,9 @@ static int i915_get_bridge_dev(struct drm_i915_private
*dev_priv)
drm_err(_priv->drm, "bridge device not found\n");
return -EIO;
}
- return 0;
+
+ return drmm_add_action_or_reset(_priv->drm, i915_release_bridge_dev,
+ dev_priv->bridge_dev);
}
/* Allocate space for the MCH regs if needed, return nonzero on error */
@@ -452,7 +460,6 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
err_uncore:
intel_teardown_mchbar(dev_priv);
intel_uncore_fini_mmio(_priv->uncore);
- pci_dev_put(dev_priv->bridge_dev);
return ret;
}
@@ -465,7 +472,6 @@ static void i915_driver_mmio_release(struct
drm_i915_private *dev_priv)
{
intel_teardown_mchbar(dev_priv);
intel_uncore_fini_mmio(_priv->uncore);
- pci_dev_put(dev_priv->bridge_dev);
}
/**
--
2.37.2
[PATCH v3 00/14] i915: Add "standalone media" support for MTL
Starting with MTL, media functionality has moved into a new, second GT
at the hardware level. This new GT, referred to as "standalone media"
in the spec, has its own GuC, power management/forcewake, etc. The
general non-engine GT registers for standalone media start at 0x38,
but otherwise use the same MMIO offsets as the primary GT.
Standalone media has a lot of similarity to the remote tiles
present on platforms like xehpsdv and pvc, and our i915 implementation
can share much of the general "multi GT" infrastructure between the two
types of platforms. However there are a few notable differences
we must deal with:
- The 0x38 offset only applies to the non-engine GT registers
(which the specs refer to as "GSI" registers). The engine registers
remain at their usual locations (e.g., 0x1C for VCS0).
- Unlike platforms with remote tiles, all interrupt handling for
standalone media still happens via the primary GT.
v2:
- Added new patches to ensure each GT, not just the primary, is
handled properly during various init/suspend/resume/teardown flows.
(Daniele)
- Simplified GSI offset handling and split it into its own patch.
- Correct gt->irq_lock assignment for media GT. (Daniele)
- Fix jump target for intel_root_gt_init_early() errors. (Daniele)
v3:
- Move intel_gt_definition struct to intel_gt_types.h. (Jani)
- Drop gtdef->setup() and just switch() on type. (Jani)
- Honor GSI offset during AUX table invalidation. (Aravind)
- Drop intel_gt_tile_cleanup() through more intelligent use
of DRM-managed actions. This also fixes the fault-injection
failures reported by CI.
Cc: Radhakrishna Sripada
Cc: Daniele Ceraolo Spurio
Cc: Aravind Iddamsetty
Cc: Jani Nikula
Matt Roper (12):
drm/i915: Move locking and unclaimed check into
mmio_debug_{suspend,resume}
drm/i915: Only hook up uncore->debug for primary uncore
drm/i915: Use managed allocations for extra uncore objects
drm/i915: Drop intel_gt_tile_cleanup()
drm/i915: Prepare more multi-GT initialization
drm/i915: Rename and expose common GT early init routine
drm/i915: Use a DRM-managed action to release the PCI bridge device
drm/i915: Initialize MMIO access for each GT
drm/i915: Handle each GT on init/release and suspend/resume
drm/i915/uncore: Add GSI offset to uncore
drm/i915/mtl: Add gsi_offset when emitting aux table invalidation
drm/i915/xelpmp: Expose media as another GT
drm/i915/mtl: Use primary GT's irq lock for media GT
drm/i915/mtl: Hook up interrupts for standalone media
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 15 ++-
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 3 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 10 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 108 +-
drivers/gpu/drm/i915/gt/intel_gt.h| 4 +-
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 35 --
drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 8 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 10 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 19 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 26 ++---
drivers/gpu/drm/i915/gt/intel_sa_media.c | 47
drivers/gpu/drm/i915/gt/intel_sa_media.h | 15 +++
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 24 ++--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/i915_driver.c| 105 -
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_irq.c | 4 +-
drivers/gpu/drm/i915/i915_pci.c | 14 +++
drivers/gpu/drm/i915/intel_device_info.h | 3 +
drivers/gpu/drm/i915/intel_uncore.c | 92 +--
drivers/gpu/drm/i915/intel_uncore.h | 28 -
drivers/gpu/drm/i915/pxp/intel_pxp.c | 4 +-
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 4 +-
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 14 +--
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 4 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
29 files changed, 449 insertions(+), 171 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.h
--
2.37.2
Re: build failure of next-20220906 due to 396369d67549 ("drm: vkms: Add support to the RGB565 format")
On 9/6/22 18:26, Sudip Mukherjee wrote:
On Tue, Sep 6, 2022 at 4:59 PM Sudip Mukherjee (Codethink)
wrote:
Hi All,
The builds of next-20220906 fails for mips, xtensa and arm allmodconfig.
The errors in mips and xtensa are:
ERROR: modpost: "__divdi3" [drivers/gpu/drm/vkms/vkms.ko] undefined!
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/vkms/vkms.ko] undefined!
The error in arm is:
ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/vkms/vkms.ko] undefined!
ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/vkms/vkms.ko] undefined!
Trying to do a git bisect to find out the offending commit.
git bisect points to 396369d67549 ("drm: vkms: Add support to the
RGB565 format")
Are these architectures incapable of doing 64bits int division?
Re: [PATCH 2/2] drm: get lock before accessing vblank refcount
On Tue, Sep 06, 2022 at 08:18:30PM +, Li, Yunxiang (Teddy) wrote: > [Public] > > Hi Daniel, > > I added the check because I saw that the refcount was always > updated/read with lock held elsewhere, and the pattern looked very > similar to in the put e.g. drm_crtc_vblank_reset. This patchset is > outdated by now and I've sent a fix to amd-gfx for the specific issue in > amdgpu. > > However, I think the way drm_crtc_vblank_on/off functions increments the > refcount without enabling the vblank is still a bit risky given how many > unchecked calls to drm_vblank_get there is elsewhere. Maybe it's more > appropriate to simply add an WARN to drm_vblank_get when it's called > with inmodeset set? This way the WARN happens right at the problematic > point, instead of far into the future when the put is called. drm_crtc_vblank_get failing when the crtc is off is how this is supposed to work, calling WARN_ON or similar in there would upset everything. What might be an option is adding __must_check or similar annotations, but the problem is that in many cases the driver knows that it cannot fail, so this isn't great either. Another option would be to split this up into drm_crtc_vblank_get with void return value (and a WARN_ON when it fails), and drm_crtc_vblank_try_get, which can fail. And then go through _all_ the callers and audit them. Imo not really worth the work, but we could do that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 3/3] efi: earlycon: Add support for generic framebuffers and move to console subsystem
On Sat, Aug 06, 2022 at 07:32:24PM +0300, Markuss Broks wrote: > Add early console support for generic linear framebuffer devices. > This driver supports probing from cmdline early parameters > or from the device-tree using information in simple-framebuffer node. > The EFI functionality should be retained in whole. > The driver was disabled on ARM because of a bug in early_ioremap > implementation on ARM and on IA64 because of lack of early_memremap_prot. > > Signed-off-by: Markuss Broks > --- > .../admin-guide/kernel-parameters.txt | 12 +- > MAINTAINERS | 5 + > drivers/firmware/efi/Kconfig | 7 +- > drivers/firmware/efi/Makefile | 1 - > drivers/firmware/efi/earlycon.c | 246 -- > drivers/video/console/Kconfig | 11 + > drivers/video/console/Makefile| 1 + > drivers/video/console/earlycon.c | 305 ++ Ok I have a more fundamental issue with this than the lack of proper patch splitting I mentioned in the other thread. This is the wrong place. drivers/video/console is about the various vt console implementations, which supply a struct consw to con_register_driver. This otoh is an (early) kernel/printk console implemented using struct console. Totally different thing, and really shouldn't end up in drivers/video/console imo. Somewhere in drivers/firmware might still be the best place, the sysfb stuff is also there. Maybe drivers/firmware/sysfb_earlycon.c? Also patch split is still an issue here, like I and Greg already said. -Daniel > 8 files changed, 332 insertions(+), 256 deletions(-) > delete mode 100644 drivers/firmware/efi/earlycon.c > create mode 100644 drivers/video/console/earlycon.c > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index > 8090130b544b0701237a7b657a29c83c000a60f4..bccb1ac8978eb5cf7e2bb20834b1881b27040666 > 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -1281,12 +1281,9 @@ > specified address. The serial port must already be > setup and configured. Options are not yet supported. > > - efifb,[options] > + efifb > Start an early, unaccelerated console on the EFI > - memory mapped framebuffer (if available). On cache > - coherent non-x86 systems that use system memory for > - the framebuffer, pass the 'ram' option so that it is > - mapped with the correct attributes. > + memory mapped framebuffer (if available). > > linflex, > Use early console provided by Freescale LINFlexD UART > @@ -1294,6 +1291,11 @@ > address must be provided, and the serial port must > already be setup and configured. > > + simplefb,,xx > + Use early console with simple framebuffer that is > + pre-initialized by firmware. A valid base address, > + width, height and pixel size must be provided. > + > earlyprintk=[X86,SH,ARM,M68k,S390] > earlyprintk=vga > earlyprintk=sclp > diff --git a/MAINTAINERS b/MAINTAINERS > index > 1fc9ead83d2aa3e60ccc4cfa8ee16df09ef579bf..af8b8e289483b6a264d477145061bd0e0ba34a25 > 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7033,6 +7033,11 @@ Q: > http://patchwork.linuxtv.org/project/linux-media/list/ > T: git git://linuxtv.org/anttip/media_tree.git > F: drivers/media/tuners/e4000* > > +EARLY CONSOLE FRAMEBUFFER DRIVER > +M: Markuss Broks > +S: Maintained > +F: drivers/video/console/earlycon.c > + > EARTH_PT1 MEDIA DRIVER > M: Akihiro Tsukada > L: linux-me...@vger.kernel.org > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig > index > 7aa4717cdcac46f91dd202f868c463388eb02735..ea76ccfb9bcd8ba44ddca06052eaa442ed6c30f7 > 100644 > --- a/drivers/firmware/efi/Kconfig > +++ b/drivers/firmware/efi/Kconfig > @@ -259,10 +259,9 @@ config EFI_DISABLE_PCI_DMA > may be used to override this option. > > config EFI_EARLYCON > - def_bool y > - depends on SERIAL_EARLYCON && !ARM && !IA64 > - select FONT_SUPPORT > - select ARCH_USE_MEMREMAP_PROT > + bool "EFI early console support" > + select FB_EARLYCON > + default y > > config EFI_CUSTOM_SSDT_OVERLAYS > bool "Load custom ACPI SSDT overlay from an EFI variable" > diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile > index > c02ff25dd47707090a2ab86ee4f330e467f878f5..64eea61fbb43d76ec2d5416d467dfbb9aa21bda0 > 100644 > --- a/drivers/firmware/efi/Makefile > +++ b/drivers/firmware/efi/Makefile > @@ -44,6
Re: [PATCH 1/2] dt-bindings: display: panel: Add Samsung AMS495QA01 panel bindings
On Tue, 06 Sep 2022 13:36:41 -0500, Chris Morgan wrote: > From: Chris Morgan > > Add documentation for the Samsung AMS495QA01 panel. > > Signed-off-by: Chris Morgan > --- > .../display/panel/samsung,ams495qa01.yaml | 49 +++ > 1 file changed, 49 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.example.dtb: panel@0: 'backlight' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/ This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [PATCH v2 0/5] rockchip-dsi for rk3568
On Tue, Sep 06, 2022 at 07:57:28PM +0200, Maya Matuszczyk wrote: > Hello, > What other patches would I need to apply to test this series > on Anbernic RG503? In addition to these patches you'd need the devicetree series: https://lore.kernel.org/linux-rockchip/20220906210324.28986-1-macroalph...@gmail.com/ You'd need the panel driver: https://lore.kernel.org/dri-devel/20220906183642.12505-1-macroalph...@gmail.com/ And you'd need to update the binding for the panel in the devicetree (example here): https://gist.github.com/macromorgan/caff01bfe4df6995d5f74cef701ede6d If you apply these patches and roll back the clock driver changes the panel should start working for you as it does for me. I tested by nuking my build-tree and starting fresh with just these patches. https://cdn.discordapp.com/attachments/973914035890290718/1015350475152949248/IMG_2028.jpg Thank you. > > Best Regards, > Maya Matuszczyk > > > wt., 6 wrz 2022 o 19:52 Chris Morgan napisał(a): > > > > From: Chris Morgan > > > > This series adds support for the dsi and dphy controllers on the > > Rockchip RK3568. I can confirm that for the Rockchip RK3568 this > > current series DOES WORK now, but it requires rolling back clk changes > > made for the HDMI driver. If the clock changes are not rolled back, the > > image on the screen is shifted about 100 pixels to the right. > > > > Clk changes in question: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/rockchip/clk-rk3568.c?id=ff3187eabb5ce478d15b6ed62eb286756adefac3 > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/rockchip/clk-rk3568.c?id=6e69052f01d9131388cfcfaee929120118a267f4 > > > > Tested on an Anbernic RG503 and RG353P with clock changes rolled back, > > the hardware works correctly on both devices. > > > > Changes since RFCv1: > > - Identified cause of image shift (clock changes). > > - Noted that driver works now. > > - Added devicetree nodes for rk356x.dtsi. > > > > Chris Morgan (5): > > dt-bindings: display: rockchip-dsi: add rk3568 compatible > > dt-bindings: phy-rockchip-inno-dsidphy: add compatible for rk3568 > > drm/rockchip: dsi: add rk3568 support > > phy/rockchip: inno-dsidphy: Add support for rk3568 > > arm64: dts: rockchip: Add DSI and DSI-DPHY nodes to rk356x > > > > .../display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + > > .../bindings/phy/rockchip,px30-dsi-dphy.yaml | 1 + > > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 72 +++ > > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 51 - > > .../phy/rockchip/phy-rockchip-inno-dsidphy.c | 204 ++ > > 5 files changed, 281 insertions(+), 48 deletions(-) > > > > -- > > 2.25.1 > > > > > > ___ > > Linux-rockchip mailing list > > linux-rockc...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: build failure of next-20220906 due to 396369d67549 ("drm: vkms: Add support to the RGB565 format")
On Tue, Sep 6, 2022 at 4:59 PM Sudip Mukherjee (Codethink)
wrote:
>
> Hi All,
>
> The builds of next-20220906 fails for mips, xtensa and arm allmodconfig.
>
> The errors in mips and xtensa are:
>
> ERROR: modpost: "__divdi3" [drivers/gpu/drm/vkms/vkms.ko] undefined!
> ERROR: modpost: "__udivdi3" [drivers/gpu/drm/vkms/vkms.ko] undefined!
>
> The error in arm is:
>
> ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/vkms/vkms.ko] undefined!
> ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/vkms/vkms.ko] undefined!
>
>
> Trying to do a git bisect to find out the offending commit.
git bisect points to 396369d67549 ("drm: vkms: Add support to the
RGB565 format")
--
Regards
Sudip
Re: [PATCH v4 1/3] drm: Use XArray instead of IDR for minors
On Tue, Sep 06, 2022 at 10:16:27PM +0200, Michał Winiarski wrote:
> IDR is deprecated, and since XArray manages its own state with internal
> locking, it simplifies the locking on DRM side.
> Additionally, don't use the IRQ-safe variant, since operating on drm
> minor is not done in IRQ context.
>
> Signed-off-by: Michał Winiarski
> Suggested-by: Matthew Wilcox
I have a few questions, but I like where you're going.
> @@ -98,21 +98,18 @@ static struct drm_minor **drm_minor_get_slot(struct
> drm_device *dev,
> static void drm_minor_alloc_release(struct drm_device *dev, void *data)
> {
> struct drm_minor *minor = data;
> - unsigned long flags;
>
> WARN_ON(dev != minor->dev);
>
> put_device(minor->kdev);
>
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_remove(_minors_idr, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> + xa_release(_minors_xa, minor->index);
Has it definitely been unused at this point? I would think that
xa_erase() (an unconditional store) would be the correct function to
call.
> @@ -122,20 +119,12 @@ static int drm_minor_alloc(struct drm_device *dev,
> unsigned int type)
> minor->type = type;
> minor->dev = dev;
>
> - idr_preload(GFP_KERNEL);
> - spin_lock_irqsave(_minor_lock, flags);
> - r = idr_alloc(_minors_idr,
> - NULL,
> - 64 * type,
> - 64 * (type + 1),
> - GFP_NOWAIT);
> - spin_unlock_irqrestore(_minor_lock, flags);
> - idr_preload_end();
> -
> + r = xa_alloc(_minors_xa, , NULL,
> + XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL);
> if (r < 0)
> return r;
>
> - minor->index = r;
> + minor->index = id;
Wouldn't it be better to call:
r = xa_alloc(_minors_xa, >index, NULL,
XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL);
I might also prefer a little syntactic sugar like:
#define DRM_MINOR_LIMIT(type) XA_LIMIT(64 * (type), 64 * (type) + 63)
but that's definitely a matter of taste.
> @@ -172,9 +161,12 @@ static int drm_minor_register(struct drm_device *dev,
> unsigned int type)
> goto err_debugfs;
>
> /* replace NULL with @minor so lookups will succeed from now on */
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_replace(_minors_idr, minor, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> + entry = xa_store(_minors_xa, minor->index, , GFP_KERNEL);
> + if (xa_is_err(entry)) {
> + ret = xa_err(entry);
> + goto err_debugfs;
> + }
> + WARN_ON(entry);
Might be better as an xa_cmpxchg()?
> @@ -187,16 +179,13 @@ static int drm_minor_register(struct drm_device *dev,
> unsigned int type)
> static void drm_minor_unregister(struct drm_device *dev, unsigned int type)
> {
> struct drm_minor *minor;
> - unsigned long flags;
>
> minor = *drm_minor_get_slot(dev, type);
> if (!minor || !device_is_registered(minor->kdev))
> return;
>
> /* replace @minor with NULL so lookups will fail from now on */
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_replace(_minors_idr, NULL, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> + xa_erase(_minors_xa, minor->index);
This isn't an exact replacement, but I'm not sure whether that makes a
difference. xa_erase() allows allocation of this ID again while
idr_replace() means that lookups return NULL, but the ID remains in
use. The equivalent of idr_replace() is:
xa_store(_minors_xa, minor->index, NULL, GFP_KERNEL);
> @@ -215,13 +204,10 @@ static void drm_minor_unregister(struct drm_device
> *dev, unsigned int type)
> struct drm_minor *drm_minor_acquire(unsigned int minor_id)
> {
> struct drm_minor *minor;
> - unsigned long flags;
>
> - spin_lock_irqsave(_minor_lock, flags);
> - minor = idr_find(_minors_idr, minor_id);
> + minor = xa_load(_minors_xa, minor_id);
> if (minor)
> drm_dev_get(minor->dev);
> - spin_unlock_irqrestore(_minor_lock, flags);
This is also not an exact equivalent as the dev_drm_get() is now outside
the lock. Does that matter in this case? I don't know the code well
enough to say. If you want it to be equivalent, then:
xa_lock(_minors_xa);
minor = xa_load(_minors_xa, minor_id);
if (minor)
drm_dev_get(minor->dev);
xa_unlock(_minors_xa);
would be the code to use.
> @@ -1037,7 +1023,7 @@ static void drm_core_exit(void)
> unregister_chrdev(DRM_MAJOR, "drm");
> debugfs_remove(drm_debugfs_root);
> drm_sysfs_destroy();
> - idr_destroy(_minors_idr);
> + xa_destroy(_minors_xa);
I don't know if this is the right call. xa_destroy() is the exact
replacement, but if the xarray should already be empty (and it should,
right?) then asserting the xa_empty() is true may
Re: [PATCH v2] drm/scheduler: quieten kernel-doc warnings
Pushed to drm-misc-next
Andrey
On 2022-09-06 13:57, Alex Deucher wrote:
On Tue, Sep 6, 2022 at 1:38 PM Andrey Grodzovsky
wrote:
I RBed, see bellow.
Can you push the patch to drm-misc?
Alex
Andrey
On 2022-08-31 14:34, Randy Dunlap wrote:
ping?
On 4/4/22 14:58, Andrey Grodzovsky wrote:
Reviewed-by: Andrey Grodzovsky
Andrey
On 2022-04-04 17:30, Randy Dunlap wrote:
Fix kernel-doc warnings in gpu_scheduler.h and sched_main.c.
Quashes these warnings:
include/drm/gpu_scheduler.h:332: warning: missing initial short description on
line:
* struct drm_sched_backend_ops
include/drm/gpu_scheduler.h:412: warning: missing initial short description on
line:
* struct drm_gpu_scheduler
include/drm/gpu_scheduler.h:461: warning: Function parameter or member 'dev'
not described in 'drm_gpu_scheduler'
drivers/gpu/drm/scheduler/sched_main.c:201: warning: missing initial short
description on line:
* drm_sched_dependency_optimized
drivers/gpu/drm/scheduler/sched_main.c:995: warning: Function parameter or
member 'dev' not described in 'drm_sched_init'
Fixes: 2d33948e4e00 ("drm/scheduler: add documentation")
Fixes: 8ab62eda177b ("drm/sched: Add device pointer to drm_gpu_scheduler")
Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes")
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: Andrey Grodzovsky
Cc: Nayan Deshmukh
Cc: Alex Deucher
Cc: Christian König
Cc: Jiawei Gu
Cc: dri-devel@lists.freedesktop.org
Acked-by: Christian König
---
Feel free to make changes or suggest changes...
v2: drop @work description (already done by Andrey)
drivers/gpu/drm/scheduler/sched_main.c |3 ++-
include/drm/gpu_scheduler.h|9 +
2 files changed, 7 insertions(+), 5 deletions(-)
--- linux-next-20220404.orig/drivers/gpu/drm/scheduler/sched_main.c
+++ linux-next-20220404/drivers/gpu/drm/scheduler/sched_main.c
@@ -198,7 +198,7 @@ static void drm_sched_job_done_cb(struct
}
/**
- * drm_sched_dependency_optimized
+ * drm_sched_dependency_optimized - test if the dependency can be optimized
*
* @fence: the dependency fence
* @entity: the entity which depends on the above fence
@@ -984,6 +984,7 @@ static int drm_sched_main(void *param)
*used
* @score: optional score atomic shared with other schedulers
* @name: name used for debugging
+ * @dev: target device
*
* Return 0 on success, otherwise error code.
*/
--- linux-next-20220404.orig/include/drm/gpu_scheduler.h
+++ linux-next-20220404/include/drm/gpu_scheduler.h
@@ -328,10 +328,10 @@ enum drm_gpu_sched_stat {
};
/**
- * struct drm_sched_backend_ops
+ * struct drm_sched_backend_ops - Define the backend operations
+ *called by the scheduler
*
- * Define the backend operations called by the scheduler,
- * these functions should be implemented in driver side.
+ * These functions should be implemented in the driver side.
*/
struct drm_sched_backend_ops {
/**
@@ -408,7 +408,7 @@ struct drm_sched_backend_ops {
};
/**
- * struct drm_gpu_scheduler
+ * struct drm_gpu_scheduler - scheduler instance-specific data
*
* @ops: backend operations provided by the driver.
* @hw_submission_limit: the max size of the hardware queue.
@@ -434,6 +434,7 @@ struct drm_sched_backend_ops {
* @_score: score used when the driver doesn't provide one
* @ready: marks if the underlying HW is ready to work
* @free_guilty: A hit to time out handler to free the guilty job.
+ * @dev: system device
*
* One scheduler is implemented for each hardware ring.
*/
[PATCH v2 1/3] drm/gma500: Fix BUG: sleeping function called from invalid context errors
gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event
on mode_set_base() errors.
Instead unlock it after setting gma_crtc->page_flip_event and on
errors re-take the lock and clear gma_crtc->page_flip_event it
it is still set.
This fixes the following WARN/stacktrace:
[ 512.122953] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:870
[ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253,
name: gnome-shell
[ 512.123031] preempt_count: 1, expected: 0
[ 512.123048] RCU nest depth: 0, expected: 0
[ 512.123066] INFO: lockdep is turned off.
[ 512.123080] irq event stamp: 0
[ 512.123094] hardirqs last enabled at (0): [<>] 0x0
[ 512.123134] hardirqs last disabled at (0): []
copy_process+0x9fc/0x1de0
[ 512.123176] softirqs last enabled at (0): []
copy_process+0x9fc/0x1de0
[ 512.123207] softirqs last disabled at (0): [<>] 0x0
[ 512.123233] Preemption disabled at:
[ 512.123241] [<>] 0x0
[ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: GW
5.19.0+ #1
[ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[ 512.123323] Call Trace:
[ 512.123346]
[ 512.123370] dump_stack_lvl+0x5b/0x77
[ 512.123412] __might_resched.cold+0xff/0x13a
[ 512.123458] ww_mutex_lock+0x1e/0xa0
[ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx]
[ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx]
[ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx]
[ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0
[ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10
[ 512.123936] drm_ioctl_kernel+0xa1/0x150
[ 512.123984] drm_ioctl+0x21f/0x420
[ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10
[ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60
[ 512.124104] ? lock_release+0x1ef/0x2d0
[ 512.124161] __x64_sys_ioctl+0x8d/0xd0
[ 512.124203] do_syscall_64+0x58/0x80
[ 512.124239] ? do_syscall_64+0x67/0x80
[ 512.124267] ? trace_hardirqs_on_prepare+0x55/0xe0
[ 512.124300] ? do_syscall_64+0x67/0x80
[ 512.124340] ? rcu_read_lock_sched_held+0x10/0x80
[ 512.124377] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 512.124411] RIP: 0033:0x7fcc4a70740f
[ 512.124442] 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
[ 512.124470] RSP: 002b:7ffda73f5390 EFLAGS: 0246 ORIG_RAX:
0010
[ 512.124503] RAX: ffda RBX: 55cc9e474500 RCX: 7fcc4a70740f
[ 512.124524] RDX: 7ffda73f5420 RSI: c01864b0 RDI: 0009
[ 512.124544] RBP: 7ffda73f5420 R08: 55cc9c0b0cb0 R09: 0034
[ 512.124564] R10: R11: 0246 R12: c01864b0
[ 512.124584] R13: 0009 R14: 55cc9df484d0 R15: 55cc9af5d0c0
[ 512.124647]
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/gma500/gma_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index bd40c040a2c9..2f52eceda3a1 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -532,15 +532,18 @@ int gma_crtc_page_flip(struct drm_crtc *crtc,
WARN_ON(drm_crtc_vblank_get(crtc) != 0);
gma_crtc->page_flip_event = event;
+ spin_unlock_irqrestore(>event_lock, flags);
/* Call this locked if we want an event at vblank interrupt. */
ret = crtc_funcs->mode_set_base(crtc, crtc->x, crtc->y, old_fb);
if (ret) {
- gma_crtc->page_flip_event = NULL;
- drm_crtc_vblank_put(crtc);
+ spin_lock_irqsave(>event_lock, flags);
+ if (gma_crtc->page_flip_event) {
+ gma_crtc->page_flip_event = NULL;
+ drm_crtc_vblank_put(crtc);
+ }
+ spin_unlock_irqrestore(>event_lock, flags);
}
-
- spin_unlock_irqrestore(>event_lock, flags);
} else {
ret = crtc_funcs->mode_set_base(crtc, crtc->x, crtc->y, old_fb);
}
--
2.37.2
[PATCH v2 0/3] drm/gma500: Fix 2 locking related WARNs + IRQ handling
Hi All, I have been testing the gma500 code on a Packard Bell Dot SC (Intel Atom N2600, cedarview) laptop because I'm working on aligning the gma500 backlight code with the changes done to other drivers in the recent backlight refactoring. During the testing I noticed dmesg filling with a WARN_ON constantly triggering as well as gnome-shell hanging after a suspend-resume cycle. This series fixes 2 locking WARNs as well as vblank IRQs no longer getting processed after a suspend-resume. Changes in v2: - Drop "drm/gma500: Fix crtc_vblank reference leak when userspace queues multiple events" - Add "drm/gma500: Fix (vblank) IRQs not working after suspend/resume" Regards, Hans Hans de Goede (3): drm/gma500: Fix BUG: sleeping function called from invalid context errors drm/gma500: Fix WARN_ON(lock->magic != lock) error drm/gma500: Fix (vblank) IRQs not working after suspend/resume drivers/gpu/drm/gma500/cdv_device.c | 4 +--- drivers/gpu/drm/gma500/gem.c | 4 ++-- drivers/gpu/drm/gma500/gma_display.c | 11 +++ drivers/gpu/drm/gma500/oaktrail_device.c | 5 + drivers/gpu/drm/gma500/power.c | 8 +--- drivers/gpu/drm/gma500/psb_drv.c | 2 +- drivers/gpu/drm/gma500/psb_drv.h | 5 + drivers/gpu/drm/gma500/psb_irq.c | 15 --- drivers/gpu/drm/gma500/psb_irq.h | 2 +- 9 files changed, 27 insertions(+), 29 deletions(-) -- 2.37.2
[PATCH v2 2/3] drm/gma500: Fix WARN_ON(lock->magic != lock) error
psb_gem_unpin() calls dma_resv_lock() but the underlying ww_mutex gets destroyed by drm_gem_object_release() move the drm_gem_object_release() call in psb_gem_free_object() to after the unpin to fix the below warning: [ 79.693962] [ cut here ] [ 79.693992] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 79.694015] WARNING: CPU: 0 PID: 240 at kernel/locking/mutex.c:582 __ww_mutex_lock.constprop.0+0x569/0xfb0 [ 79.694052] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer qrtr bnep ath9k ath9k_common ath9k_hw snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel ath3k snd_intel_dspcfg mac80211 snd_intel_sdw_acpi btusb snd_hda_codec btrtl btbcm btintel btmtk bluetooth at24 snd_hda_core snd_hwdep uvcvideo snd_seq libarc4 videobuf2_vmalloc ath videobuf2_memops videobuf2_v4l2 videobuf2_common snd_seq_device videodev acer_wmi intel_powerclamp coretemp mc snd_pcm joydev sparse_keymap ecdh_generic pcspkr wmi_bmof cfg80211 i2c_i801 i2c_smbus snd_timer snd r8169 rfkill lpc_ich soundcore acpi_cpufreq zram rtsx_pci_sdmmc mmc_core serio_raw rtsx_pci gma500_gfx(E) video wmi ip6_tables ip_tables i2c_dev fuse [ 79.694436] CPU: 0 PID: 240 Comm: plymouthd Tainted: GW E 6.0.0-rc3+ #490 [ 79.694457] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 79.694469] RIP: 0010:__ww_mutex_lock.constprop.0+0x569/0xfb0 [ 79.694496] Code: ff 85 c0 0f 84 15 fb ff ff 8b 05 ca 3c 11 01 85 c0 0f 85 07 fb ff ff 48 c7 c6 30 cb 84 aa 48 c7 c7 a3 e1 82 aa e8 ac 29 f8 ff <0f> 0b e9 ed fa ff ff e8 5b 83 8a ff 85 c0 74 10 44 8b 0d 98 3c 11 [ 79.694513] RSP: 0018:ad1dc048bbe0 EFLAGS: 00010282 [ 79.694623] RAX: 0028 RBX: RCX: [ 79.694636] RDX: 0001 RSI: aa8b0ffc RDI: [ 79.694650] RBP: ad1dc048bc80 R08: R09: ad1dc048ba90 [ 79.694662] R10: 0003 R11: aad62fe8 R12: 9ff302103138 [ 79.694675] R13: 9ff306ec8000 R14: 9ff307779078 R15: 9ff3014c0270 [ 79.694690] FS: 7ff1cccf1740() GS:9ff3bc20() knlGS: [ 79.694705] CS: 0010 DS: ES: CR0: 80050033 [ 79.694719] CR2: 559ecbcb4420 CR3: 1321 CR4: 06f0 [ 79.694734] Call Trace: [ 79.694749] [ 79.694761] ? __schedule+0x47f/0x1670 [ 79.694796] ? psb_gem_unpin+0x27/0x1a0 [gma500_gfx] [ 79.694830] ? lock_is_held_type+0xe3/0x140 [ 79.694864] ? ww_mutex_lock+0x38/0xa0 [ 79.694885] ? __cond_resched+0x1c/0x30 [ 79.694902] ww_mutex_lock+0x38/0xa0 [ 79.694925] psb_gem_unpin+0x27/0x1a0 [gma500_gfx] [ 79.694964] psb_gem_unpin+0x199/0x1a0 [gma500_gfx] [ 79.694996] drm_gem_object_release_handle+0x50/0x60 [ 79.695020] ? drm_gem_object_handle_put_unlocked+0xf0/0xf0 [ 79.695042] idr_for_each+0x4b/0xb0 [ 79.695066] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 79.695095] drm_gem_release+0x1c/0x30 [ 79.695118] drm_file_free.part.0+0x1ea/0x260 [ 79.695150] drm_release+0x6a/0x120 [ 79.695175] __fput+0x9f/0x260 [ 79.695203] task_work_run+0x59/0xa0 [ 79.695227] do_exit+0x387/0xbe0 [ 79.695250] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 79.695275] ? lockdep_hardirqs_on+0x7d/0x100 [ 79.695304] do_group_exit+0x33/0xb0 [ 79.695331] __x64_sys_exit_group+0x14/0x20 [ 79.695353] do_syscall_64+0x58/0x80 [ 79.695376] ? up_read+0x17/0x20 [ 79.695401] ? lock_is_held_type+0xe3/0x140 [ 79.695429] ? asm_exc_page_fault+0x22/0x30 [ 79.695450] ? lockdep_hardirqs_on+0x7d/0x100 [ 79.695473] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 79.695493] RIP: 0033:0x7ff1ccefe3f1 [ 79.695516] Code: Unable to access opcode bytes at RIP 0x7ff1ccefe3c7. [ 79.695607] RSP: 002b:7ffed4413378 EFLAGS: 0246 ORIG_RAX: 00e7 [ 79.695629] RAX: ffda RBX: 7ff1cd0159e0 RCX: 7ff1ccefe3f1 [ 79.695644] RDX: 003c RSI: 00e7 RDI: [ 79.695656] RBP: R08: ff80 R09: 7ff1cd020b20 [ 79.695671] R10: R11: 0246 R12: 7ff1cd0159e0 [ 79.695684] R13: R14: 7ff1cd01aee8 R15: 7ff1cd01af00 [ 79.695733] [ 79.695746] irq event stamp: 725979 [ 79.695757] hardirqs last enabled at (725979): [] finish_task_switch.isra.0+0xe4/0x3f0 [ 79.695780] hardirqs last disabled at (725978): [] __schedule+0xdd3/0x1670 [ 79.695803] softirqs last enabled at (725974): [] __irq_exit_rcu+0xed/0x160 [ 79.695825] softirqs last disabled at (725969): [] __irq_exit_rcu+0xed/0x160 [ 79.695845] ---[ end trace ]--- Signed-off-by: Hans de Goede --- drivers/gpu/drm/gma500/gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c index dffe37490206..4b7627a72637 100644 ---
[PATCH v2 3/3] drm/gma500: Fix (vblank) IRQs not working after suspend/resume
Fix gnome-shell (and other page-flip users) hanging after suspend/resume
because of the gma500's IRQs not working.
This fixes 2 problems with the IRQ handling:
1. gma_power_off() calls gma_irq_uninstall() which does a free_irq(), but
gma_power_on() called gma_irq_preinstall() + gma_irq_postinstall() which
do not call request_irq. Replace the pre- + post-install calls with
gma_irq_install() which does prep + request + post.
2. After fixing 1. IRQs still do not work on a Packard Bell Dot SC (Intel
Atom N2600, cedarview) netbook.
Cederview uses MSI interrupts and it seems that the BIOS re-configures
things back to normal APIC based interrupts during S3 suspend. There is
some MSI PCI-config registers save/restore code which tries to deal with
this, but on the Packard Bell Dot SC this is not sufficient to restore
MSI IRQ functionality after a suspend/resume.
Replace the PCI-config registers save/restore with pci_disable_msi() on
suspend + pci_enable_msi() on resume. Fixing e.g. gnome-shell hanging.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/gma500/cdv_device.c | 4 +---
drivers/gpu/drm/gma500/oaktrail_device.c | 5 +
drivers/gpu/drm/gma500/power.c | 8 +---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
drivers/gpu/drm/gma500/psb_drv.h | 5 +
drivers/gpu/drm/gma500/psb_irq.c | 15 ---
drivers/gpu/drm/gma500/psb_irq.h | 2 +-
7 files changed, 18 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index dd32b484dd82..ce96234f3df2 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -581,11 +581,9 @@ static const struct psb_offset cdv_regmap[2] = {
static int cdv_chip_setup(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
- struct pci_dev *pdev = to_pci_dev(dev->dev);
INIT_WORK(_priv->hotplug_work, cdv_hotplug_work_func);
- if (pci_enable_msi(pdev))
- dev_warn(dev->dev, "Enabling MSI failed!\n");
+ dev_priv->use_msi = true;
dev_priv->regmap = cdv_regmap;
gma_get_core_freq(dev);
psb_intel_opregion_init(dev);
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 5923a9c89312..f90e628cb482 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -501,12 +501,9 @@ static const struct psb_offset oaktrail_regmap[2] = {
static int oaktrail_chip_setup(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
- struct pci_dev *pdev = to_pci_dev(dev->dev);
int ret;
- if (pci_enable_msi(pdev))
- dev_warn(dev->dev, "Enabling MSI failed!\n");
-
+ dev_priv->use_msi = true;
dev_priv->regmap = oaktrail_regmap;
ret = mid_chip_setup(dev);
diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
index b91de6d36e41..66873085d450 100644
--- a/drivers/gpu/drm/gma500/power.c
+++ b/drivers/gpu/drm/gma500/power.c
@@ -139,8 +139,6 @@ static void gma_suspend_pci(struct pci_dev *pdev)
dev_priv->regs.saveBSM = bsm;
pci_read_config_dword(pdev, 0xFC, );
dev_priv->regs.saveVBT = vbt;
- pci_read_config_dword(pdev, PSB_PCIx_MSI_ADDR_LOC, _priv->msi_addr);
- pci_read_config_dword(pdev, PSB_PCIx_MSI_DATA_LOC, _priv->msi_data);
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
@@ -168,9 +166,6 @@ static bool gma_resume_pci(struct pci_dev *pdev)
pci_restore_state(pdev);
pci_write_config_dword(pdev, 0x5c, dev_priv->regs.saveBSM);
pci_write_config_dword(pdev, 0xFC, dev_priv->regs.saveVBT);
- /* restoring MSI address and data in PCIx space */
- pci_write_config_dword(pdev, PSB_PCIx_MSI_ADDR_LOC, dev_priv->msi_addr);
- pci_write_config_dword(pdev, PSB_PCIx_MSI_DATA_LOC, dev_priv->msi_data);
ret = pci_enable_device(pdev);
if (ret != 0)
@@ -223,8 +218,7 @@ int gma_power_resume(struct device *_dev)
mutex_lock(_mutex);
gma_resume_pci(pdev);
gma_resume_display(pdev);
- gma_irq_preinstall(dev);
- gma_irq_postinstall(dev);
+ gma_irq_install(dev);
mutex_unlock(_mutex);
return 0;
}
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 1d8744f3e702..54e756b48606 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -383,7 +383,7 @@ static int psb_driver_load(struct drm_device *dev, unsigned
long flags)
PSB_WVDC32(0x, PSB_INT_MASK_R);
spin_unlock_irqrestore(_priv->irqmask_lock, irqflags);
- gma_irq_install(dev, pdev->irq);
+ gma_irq_install(dev);
dev->max_vblank_count = 0xff; /* only 24 bits of frame count */
diff
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/uc: Enable version reduced firmware files for newest platforms
On 8/26/2022 6:17 PM, john.c.harri...@intel.com wrote: 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 DG1/2 and ADL-P/S. Signed-off-by: John Harrison Reviewed-by: Daniele Ceraolo Spurio However, looks like a new GuC minor version might land in the next couple of days, so IMO better wait until that is confirmed before merging this so we can do a single pull request to linux-firmware. Daniele --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) 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 af425916cdf64..78b1198bcf39b 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -72,11 +72,14 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ - fw_def(DG2, 0, guc_mmp(dg2, 70, 4, 1)) \ + fw_def(DG2, 0, guc_maj(dg2, 70, 4)) \ + fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 1)) \ 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_maj(tgl, 70, 1)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 69, 0, 3)) \ + fw_def(DG1, 0, guc_maj(dg1, 70, 1)) \ fw_def(DG1, 0, guc_mmp(dg1, 70, 1, 1)) \ fw_def(ROCKETLAKE, 0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(TIGERLAKE,0, guc_mmp(tgl, 70, 1, 1)) \ @@ -92,8 +95,11 @@ 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_raw(dg1)) \ fw_def(DG1, 0, huc_mmp(dg1, 7, 9, 3)) \ fw_def(ROCKETLAKE, 0, huc_mmp(tgl, 7, 9, 3)) \ fw_def(TIGERLAKE,0, huc_mmp(tgl, 7, 9, 3)) \
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/uc: Add patch level version number support
On 8/26/2022 6:17 PM, john.c.harri...@intel.com wrote:
From: John Harrison
With the move to un-versioned filenames, it becomes more difficult to
know exactly what version of a given firmware is being used. So add
the patch level version number to the debugfs output.
Also, support matching by patch level when selecting code paths for
firmware compatibility. While a patch level change cannot be backwards
breaking, it is potentially possible that a new feature only works
from a given patch level onwards (even though it was theoretically
added in an earlier version that bumped the major or minor version).
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 36 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 6
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 8 +++--
5 files changed, 47 insertions(+), 19 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 04393932623c7..64c4e83153f47 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.file_selected.major_ver < 70) {
+ if (GET_UC_VER(guc) < MAKE_UC_VER(70, 0, 0)) {
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.file_selected.major_ver >= 70)
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))
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.file_selected.major_ver >= 70)
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))
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.file_selected.major_ver >= 70) {
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
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.file_selected.major_ver >= 70) {
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
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 d965ac4832d60..abf4e142596d0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -435,9 +435,11 @@ 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",
+ drm_info(>drm, "%s firmware %s version %u.%u.%u\n",
intel_uc_fw_type_repr(fw->type), fw->file_selected.path,
-fw->file_selected.major_ver, fw->file_selected.minor_ver);
+fw->file_selected.major_ver,
+fw->file_selected.minor_ver,
+fw->file_selected.patch_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 610f36f1b989a..af425916cdf64 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -447,10 +447,12 @@ static int check_gsc_manifest(const struct firmware *fw,
struct intel_uc_fw *uc_fw)
{
u32 *dw = (u32 *)fw->data;
- u32 version = dw[HUC_GSC_VERSION_DW];
+ u32 version_hi = dw[HUC_GSC_VERSION_HI_DW];
+ u32 version_lo = dw[HUC_GSC_VERSION_LO_DW];
- uc_fw->file_selected.major_ver = FIELD_GET(HUC_GSC_MAJOR_VER_MASK, version);
- uc_fw->file_selected.minor_ver = FIELD_GET(HUC_GSC_MINOR_VER_MASK,
version);
+ uc_fw->file_selected.major_ver = FIELD_GET(HUC_GSC_MAJOR_VER_HI_MASK,
version_hi);
+
RE: [PATCH 2/2] drm: get lock before accessing vblank refcount
[Public] Hi Daniel, I added the check because I saw that the refcount was always updated/read with lock held elsewhere, and the pattern looked very similar to in the put e.g. drm_crtc_vblank_reset. This patchset is outdated by now and I've sent a fix to amd-gfx for the specific issue in amdgpu. However, I think the way drm_crtc_vblank_on/off functions increments the refcount without enabling the vblank is still a bit risky given how many unchecked calls to drm_vblank_get there is elsewhere. Maybe it's more appropriate to simply add an WARN to drm_vblank_get when it's called with inmodeset set? This way the WARN happens right at the problematic point, instead of far into the future when the put is called. Yunxiang
[PATCH v4 3/3] drm: Introduce skip_legacy_minors modparam
While there is support for >64 DRM devices on kernel side, existing
userspace may still have some hardcoded assumptions and it's possible
that it will require changes to be able to use more than 64 devices.
Add a modparam to simplify testing and development of >64 devices
support on userspace side by allocating minors from the >=192 range
(without the need of having >64 physical devices connected).
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_drv.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 2c6e0b8d3b7a..11c691543fec 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -56,6 +56,11 @@ MODULE_LICENSE("GPL and additional rights");
static DEFINE_XARRAY_ALLOC(drm_minors_xa);
+static bool skip_legacy_minors;
+module_param_unsafe(skip_legacy_minors, bool, 0400);
+MODULE_PARM_DESC(skip_legacy_minors,
+"Don't allocate minors in 0-192 range. This can be used for
testing userspace support for >64 drm devices (default: false)");
+
/*
* If the drm core fails to init for whatever reason,
* we should prevent any drivers from registering with it.
@@ -110,7 +115,7 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned
int type)
{
struct drm_minor *minor;
u32 id;
- int r;
+ int r = -EBUSY;
minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
if (!minor)
@@ -125,8 +130,9 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned
int type)
* and 128-191 are render nodes.
* After reaching the limit, we're allocating minors dynamically -
first-come, first-serve.
*/
- r = xa_alloc(_minors_xa, , NULL,
-XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL);
+ if (!skip_legacy_minors)
+ r = xa_alloc(_minors_xa, , NULL,
+XA_LIMIT(64 * type, 64 * (type + 1) - 1),
GFP_KERNEL);
if (r == -EBUSY)
r = xa_alloc(_minors_xa, , NULL,
XA_LIMIT(192, (1 << MINORBITS) - 1), GFP_KERNEL);
--
2.37.3
[PATCH v4 1/3] drm: Use XArray instead of IDR for minors
IDR is deprecated, and since XArray manages its own state with internal
locking, it simplifies the locking on DRM side.
Additionally, don't use the IRQ-safe variant, since operating on drm
minor is not done in IRQ context.
Signed-off-by: Michał Winiarski
Suggested-by: Matthew Wilcox
---
drivers/gpu/drm/drm_drv.c | 49 ++-
1 file changed, 17 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 8214a0b1ab7f..41799e4d0432 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -53,8 +54,7 @@ MODULE_AUTHOR("Gareth Hughes, Leif Delgass, José Fonseca, Jon
Smirl");
MODULE_DESCRIPTION("DRM shared core routines");
MODULE_LICENSE("GPL and additional rights");
-static DEFINE_SPINLOCK(drm_minor_lock);
-static struct idr drm_minors_idr;
+static DEFINE_XARRAY_ALLOC(drm_minors_xa);
/*
* If the drm core fails to init for whatever reason,
@@ -98,21 +98,18 @@ static struct drm_minor **drm_minor_get_slot(struct
drm_device *dev,
static void drm_minor_alloc_release(struct drm_device *dev, void *data)
{
struct drm_minor *minor = data;
- unsigned long flags;
WARN_ON(dev != minor->dev);
put_device(minor->kdev);
- spin_lock_irqsave(_minor_lock, flags);
- idr_remove(_minors_idr, minor->index);
- spin_unlock_irqrestore(_minor_lock, flags);
+ xa_release(_minors_xa, minor->index);
}
static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
{
struct drm_minor *minor;
- unsigned long flags;
+ u32 id;
int r;
minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
@@ -122,20 +119,12 @@ static int drm_minor_alloc(struct drm_device *dev,
unsigned int type)
minor->type = type;
minor->dev = dev;
- idr_preload(GFP_KERNEL);
- spin_lock_irqsave(_minor_lock, flags);
- r = idr_alloc(_minors_idr,
- NULL,
- 64 * type,
- 64 * (type + 1),
- GFP_NOWAIT);
- spin_unlock_irqrestore(_minor_lock, flags);
- idr_preload_end();
-
+ r = xa_alloc(_minors_xa, , NULL,
+XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL);
if (r < 0)
return r;
- minor->index = r;
+ minor->index = id;
r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
if (r)
@@ -152,7 +141,7 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned
int type)
static int drm_minor_register(struct drm_device *dev, unsigned int type)
{
struct drm_minor *minor;
- unsigned long flags;
+ void *entry;
int ret;
DRM_DEBUG("\n");
@@ -172,9 +161,12 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
goto err_debugfs;
/* replace NULL with @minor so lookups will succeed from now on */
- spin_lock_irqsave(_minor_lock, flags);
- idr_replace(_minors_idr, minor, minor->index);
- spin_unlock_irqrestore(_minor_lock, flags);
+ entry = xa_store(_minors_xa, minor->index, , GFP_KERNEL);
+ if (xa_is_err(entry)) {
+ ret = xa_err(entry);
+ goto err_debugfs;
+ }
+ WARN_ON(entry);
DRM_DEBUG("new minor registered %d\n", minor->index);
return 0;
@@ -187,16 +179,13 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
static void drm_minor_unregister(struct drm_device *dev, unsigned int type)
{
struct drm_minor *minor;
- unsigned long flags;
minor = *drm_minor_get_slot(dev, type);
if (!minor || !device_is_registered(minor->kdev))
return;
/* replace @minor with NULL so lookups will fail from now on */
- spin_lock_irqsave(_minor_lock, flags);
- idr_replace(_minors_idr, NULL, minor->index);
- spin_unlock_irqrestore(_minor_lock, flags);
+ xa_erase(_minors_xa, minor->index);
device_del(minor->kdev);
dev_set_drvdata(minor->kdev, NULL); /* safety belt */
@@ -215,13 +204,10 @@ static void drm_minor_unregister(struct drm_device *dev,
unsigned int type)
struct drm_minor *drm_minor_acquire(unsigned int minor_id)
{
struct drm_minor *minor;
- unsigned long flags;
- spin_lock_irqsave(_minor_lock, flags);
- minor = idr_find(_minors_idr, minor_id);
+ minor = xa_load(_minors_xa, minor_id);
if (minor)
drm_dev_get(minor->dev);
- spin_unlock_irqrestore(_minor_lock, flags);
if (!minor) {
return ERR_PTR(-ENODEV);
@@ -1037,7 +1023,7 @@ static void drm_core_exit(void)
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
- idr_destroy(_minors_idr);
+
[PATCH v4 2/3] drm: Expand max DRM device number to full MINORBITS
Having a limit of 64 DRM devices is not good enough for modern world where we have multi-GPU servers, SR-IOV virtual functions and virtual devices used for testing. Let's utilize full minor range for DRM devices. To avoid regressing the existing userspace, we're still maintaining the numbering scheme where 0-63 is used for primary, 64-127 is reserved (formerly for control) and 128-191 is used for render. For minors >= 192, we're allocating minors dynamically on a first-come, first-served basis. Signed-off-by: Michał Winiarski --- drivers/gpu/drm/drm_drv.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 41799e4d0432..2c6e0b8d3b7a 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -119,8 +119,17 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned int type) minor->type = type; minor->dev = dev; + /* +* DRM used to support 64 devices, for backwards compatibility we need to maintain the +* minor allocation scheme where minors 0-63 are primary nodes, 64-127 are control nodes, +* and 128-191 are render nodes. +* After reaching the limit, we're allocating minors dynamically - first-come, first-serve. +*/ r = xa_alloc(_minors_xa, , NULL, XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL); + if (r == -EBUSY) + r = xa_alloc(_minors_xa, , NULL, +XA_LIMIT(192, (1 << MINORBITS) - 1), GFP_KERNEL); if (r < 0) return r; -- 2.37.3
[PATCH v4 0/3] drm: Use full allocated minor range for DRM
64 DRM device nodes is not enough for everyone. Upgrade it to ~512K (which definitely is more than enough). To allow testing userspace support for >64 devices, add additional DRM modparam (skip_legacy_minors) which causes DRM to skip allocating minors in 0-192 range. Additionally - convert minors to use XArray instead of IDR to simplify the locking. v1 -> v2: Don't touch DRM_MINOR_CONTROL and its range (Simon Ser) v2 -> v3: Don't use legacy scheme for >=192 minor range (Dave Airlie) Add modparam for testing (Dave Airlie) Add lockdep annotation for IDR (Daniel Vetter) v3 -> v4: Convert from IDR to XArray (Matthew Wilcox) Michał Winiarski (3): drm: Use XArray instead of IDR for minors drm: Expand max DRM device number to full MINORBITS drm: Introduce skip_legacy_minors modparam drivers/gpu/drm/drm_drv.c | 66 +++ 1 file changed, 33 insertions(+), 33 deletions(-) -- 2.37.3
Re: [PATCH 01/12] drm/udl: Restore display mode on resume
On Tue, Aug 16, 2022 at 05:36:44PM +0200, Takashi Iwai wrote: > 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 This patch isn't great and incomplete, see https://lore.kernel.org/dri-devel/YxegiQFAv+OWjjqE@phenom.ffwll.local/ You need cc: stable and fixes: 997d33c35618 and actually just remove the entire check :-) -Daniel > --- > 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 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 37/41] drm/sun4i: tv: Remove useless function
Dne ponedeljek, 29. avgust 2022 ob 15:11:51 CEST je Maxime Ripard napisal(a): > The drm_connector_to_sun4i_tv() function isn't used anywhere in the driver, > so let's remove it. > > Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH v1] drm/ttm: Refcount allocated tail pages
On Tue, Sep 06, 2022 at 10:01:47PM +0200, Daniel Vetter wrote:
> On Mon, Aug 15, 2022 at 12:05:19PM +0200, Christian König wrote:
> > Am 15.08.22 um 11:54 schrieb Dmitry Osipenko:
> > > Higher order pages allocated using alloc_pages() aren't refcounted and
> > > they
> > > need to be refcounted, otherwise it's impossible to map them by KVM. This
> > > patch sets the refcount of the tail pages and fixes the KVM memory mapping
> > > faults.
> > >
> > > Without this change guest virgl driver can't map host buffers into guest
> > > and can't provide OpenGL 4.5 profile support to the guest. The host
> > > mappings are also needed for enabling the Venus driver using host GPU
> > > drivers that are utilizing TTM.
> > >
> > > Based on a patch proposed by Trigger Huang.
> >
> > Well I can't count how often I have repeated this: This is an absolutely
> > clear NAK!
> >
> > TTM pages are not reference counted in the first place and because of this
> > giving them to virgl is illegal.
> >
> > Please immediately stop this completely broken approach. We have discussed
> > this multiple times now.
>
> Yeah we need to get this stuff closed for real by tagging them all with
> VM_IO or VM_PFNMAP asap.
For a bit more context: Anything mapping a bo should be VM_SPECIAL. And I
think we should add the checks to the gem and dma-buf mmap functions to
validate for that, and fix all the fallout.
Otherwise this dragon keeps resurrecting ...
VM_SPECIAL _will_ block get_user_pages, which will block everyone from
even trying to refcount this stuff.
Minimally we need to fix this for all ttm drivers, and it sounds like
that's still not yet the case :-( Iirc last time around some funky amdkfd
userspace was the hold-up because regressions?
-Daniel
>
> It seems ot be a recurring amount of fun that people try to mmap dma-buf
> and then call get_user_pages on them.
>
> Which just doesn't work. I guess this is also why Rob Clark send out that
> dma-buf patch to expos mapping information (i.e. wc vs wb vs uncached).
>
> There seems to be some serious bonghits going on :-/
> -Daniel
>
> >
> > Regards,
> > Christian.
> >
> > >
> > > Cc: sta...@vger.kernel.org
> > > Cc: Trigger Huang
> > > Link:
> > > https://www.collabora.com/news-and-blog/blog/2021/11/26/venus-on-qemu-enabling-new-virtual-vulkan-driver/#qcom1343
> > > Tested-by: Dmitry Osipenko # AMDGPU (Qemu
> > > and crosvm)
> > > Signed-off-by: Dmitry Osipenko
> > > ---
> > > drivers/gpu/drm/ttm/ttm_pool.c | 25 -
> > > 1 file changed, 24 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
> > > b/drivers/gpu/drm/ttm/ttm_pool.c
> > > index 21b61631f73a..11e92bb149c9 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > > @@ -81,6 +81,7 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool
> > > *pool, gfp_t gfp_flags,
> > > unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
> > > struct ttm_pool_dma *dma;
> > > struct page *p;
> > > + unsigned int i;
> > > void *vaddr;
> > > /* Don't set the __GFP_COMP flag for higher order allocations.
> > > @@ -93,8 +94,10 @@ static struct page *ttm_pool_alloc_page(struct
> > > ttm_pool *pool, gfp_t gfp_flags,
> > > if (!pool->use_dma_alloc) {
> > > p = alloc_pages(gfp_flags, order);
> > > - if (p)
> > > + if (p) {
> > > p->private = order;
> > > + goto ref_tail_pages;
> > > + }
> > > return p;
> > > }
> > > @@ -120,6 +123,23 @@ static struct page *ttm_pool_alloc_page(struct
> > > ttm_pool *pool, gfp_t gfp_flags,
> > > dma->vaddr = (unsigned long)vaddr | order;
> > > p->private = (unsigned long)dma;
> > > +
> > > +ref_tail_pages:
> > > + /*
> > > + * KVM requires mapped tail pages to be refcounted because put_page()
> > > + * is invoked on them in the end of the page fault handling, and thus,
> > > + * tail pages need to be protected from the premature releasing.
> > > + * In fact, KVM page fault handler refuses to map tail pages to guest
> > > + * if they aren't refcounted because hva_to_pfn_remapped() checks the
> > > + * refcount specifically for this case.
> > > + *
> > > + * In particular, unreferenced tail pages result in a KVM "Bad address"
> > > + * failure for VMMs that use VirtIO-GPU when guest's Mesa VirGL driver
> > > + * accesses mapped host TTM buffer that contains tail pages.
> > > + */
> > > + for (i = 1; i < 1 << order; i++)
> > > + page_ref_inc(p + i);
> > > +
> > > return p;
> > > error_free:
> > > @@ -133,6 +153,7 @@ static void ttm_pool_free_page(struct ttm_pool *pool,
> > > enum ttm_caching caching,
> > > {
> > > unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
> > > struct ttm_pool_dma *dma;
> > > + unsigned int i;
> > > void *vaddr;
> > > #ifdef
Re: [PATCH v2 36/41] drm/sun4i: tv: Merge mode_set into atomic_enable
Dne ponedeljek, 29. avgust 2022 ob 15:11:50 CEST je Maxime Ripard napisal(a):
> Our mode_set implementation can be merged into our atomic_enable
> implementation to simplify things, so let's do this.
Are you sure this is a good thing in long term? What if user wants to change
mode? Unlikely, but why not.
Best regards,
Jernej
>
> Signed-off-by: Maxime Ripard
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c
> b/drivers/gpu/drm/sun4i/sun4i_tv.c
> index f7aad995ab5b..3944da9a3c34 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -359,23 +359,13 @@ static void sun4i_tv_enable(struct drm_encoder
> *encoder,
{
> struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
> struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
> -
> - DRM_DEBUG_DRIVER("Enabling the TV Output\n");
> -
> - sunxi_engine_apply_color_correction(crtc->engine);
> -
> - regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
> -SUN4I_TVE_EN_ENABLE,
> -SUN4I_TVE_EN_ENABLE);
> -}
> -
> -static void sun4i_tv_mode_set(struct drm_encoder *encoder,
> - struct drm_display_mode *mode,
> - struct drm_display_mode
*adjusted_mode)
> -{
> - struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
> + struct drm_crtc_state *crtc_state =
> + drm_atomic_get_new_crtc_state(state, encoder->crtc);
> + struct drm_display_mode *mode = _state->mode;
> const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
>
> + DRM_DEBUG_DRIVER("Enabling the TV Output\n");
> +
> /* Enable and map the DAC to the output */
> regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
> SUN4I_TVE_EN_DAC_MAP_MASK,
> @@ -468,12 +458,17 @@ static void sun4i_tv_mode_set(struct drm_encoder
> *encoder,
> SUN4I_TVE_RESYNC_FIELD : 0));
>
> regmap_write(tv->regs, SUN4I_TVE_SLAVE_REG, 0);
> +
> + sunxi_engine_apply_color_correction(crtc->engine);
> +
> + regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
> +SUN4I_TVE_EN_ENABLE,
> +SUN4I_TVE_EN_ENABLE);
> }
>
> static const struct drm_encoder_helper_funcs sun4i_tv_helper_funcs = {
> .atomic_disable = sun4i_tv_disable,
> .atomic_enable = sun4i_tv_enable,
> - .mode_set = sun4i_tv_mode_set,
> };
>
> static int sun4i_tv_comp_get_modes(struct drm_connector *connector)
>
> --
> b4 0.10.0-dev-65ba7
Re: [PATCH v2 35/41] drm/sun4i: tv: Convert to atomic hooks
Dne ponedeljek, 29. avgust 2022 ob 15:11:49 CEST je Maxime Ripard napisal(a): > The sun4i TV driver still uses legacy enable and disable hook > implementation. Let's convert to the atomic variants. > > Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec BTW, I suggest you merge fixes/cleanups, no need to drag them in this super long series. Best regards, Jernej
Re: [PATCH v1] drm/ttm: Refcount allocated tail pages
On Mon, Aug 15, 2022 at 12:05:19PM +0200, Christian König wrote:
> Am 15.08.22 um 11:54 schrieb Dmitry Osipenko:
> > Higher order pages allocated using alloc_pages() aren't refcounted and they
> > need to be refcounted, otherwise it's impossible to map them by KVM. This
> > patch sets the refcount of the tail pages and fixes the KVM memory mapping
> > faults.
> >
> > Without this change guest virgl driver can't map host buffers into guest
> > and can't provide OpenGL 4.5 profile support to the guest. The host
> > mappings are also needed for enabling the Venus driver using host GPU
> > drivers that are utilizing TTM.
> >
> > Based on a patch proposed by Trigger Huang.
>
> Well I can't count how often I have repeated this: This is an absolutely
> clear NAK!
>
> TTM pages are not reference counted in the first place and because of this
> giving them to virgl is illegal.
>
> Please immediately stop this completely broken approach. We have discussed
> this multiple times now.
Yeah we need to get this stuff closed for real by tagging them all with
VM_IO or VM_PFNMAP asap.
It seems ot be a recurring amount of fun that people try to mmap dma-buf
and then call get_user_pages on them.
Which just doesn't work. I guess this is also why Rob Clark send out that
dma-buf patch to expos mapping information (i.e. wc vs wb vs uncached).
There seems to be some serious bonghits going on :-/
-Daniel
>
> Regards,
> Christian.
>
> >
> > Cc: sta...@vger.kernel.org
> > Cc: Trigger Huang
> > Link:
> > https://www.collabora.com/news-and-blog/blog/2021/11/26/venus-on-qemu-enabling-new-virtual-vulkan-driver/#qcom1343
> > Tested-by: Dmitry Osipenko # AMDGPU (Qemu
> > and crosvm)
> > Signed-off-by: Dmitry Osipenko
> > ---
> > drivers/gpu/drm/ttm/ttm_pool.c | 25 -
> > 1 file changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> > index 21b61631f73a..11e92bb149c9 100644
> > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > @@ -81,6 +81,7 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool
> > *pool, gfp_t gfp_flags,
> > unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
> > struct ttm_pool_dma *dma;
> > struct page *p;
> > + unsigned int i;
> > void *vaddr;
> > /* Don't set the __GFP_COMP flag for higher order allocations.
> > @@ -93,8 +94,10 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool
> > *pool, gfp_t gfp_flags,
> > if (!pool->use_dma_alloc) {
> > p = alloc_pages(gfp_flags, order);
> > - if (p)
> > + if (p) {
> > p->private = order;
> > + goto ref_tail_pages;
> > + }
> > return p;
> > }
> > @@ -120,6 +123,23 @@ static struct page *ttm_pool_alloc_page(struct
> > ttm_pool *pool, gfp_t gfp_flags,
> > dma->vaddr = (unsigned long)vaddr | order;
> > p->private = (unsigned long)dma;
> > +
> > +ref_tail_pages:
> > + /*
> > +* KVM requires mapped tail pages to be refcounted because put_page()
> > +* is invoked on them in the end of the page fault handling, and thus,
> > +* tail pages need to be protected from the premature releasing.
> > +* In fact, KVM page fault handler refuses to map tail pages to guest
> > +* if they aren't refcounted because hva_to_pfn_remapped() checks the
> > +* refcount specifically for this case.
> > +*
> > +* In particular, unreferenced tail pages result in a KVM "Bad address"
> > +* failure for VMMs that use VirtIO-GPU when guest's Mesa VirGL driver
> > +* accesses mapped host TTM buffer that contains tail pages.
> > +*/
> > + for (i = 1; i < 1 << order; i++)
> > + page_ref_inc(p + i);
> > +
> > return p;
> > error_free:
> > @@ -133,6 +153,7 @@ static void ttm_pool_free_page(struct ttm_pool *pool,
> > enum ttm_caching caching,
> > {
> > unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
> > struct ttm_pool_dma *dma;
> > + unsigned int i;
> > void *vaddr;
> > #ifdef CONFIG_X86
> > @@ -142,6 +163,8 @@ static void ttm_pool_free_page(struct ttm_pool *pool,
> > enum ttm_caching caching,
> > if (caching != ttm_cached && !PageHighMem(p))
> > set_pages_wb(p, 1 << order);
> > #endif
> > + for (i = 1; i < 1 << order; i++)
> > + page_ref_dec(p + i);
> > if (!pool || !pool->use_dma_alloc) {
> > __free_pages(p, order);
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 0/1] tee: Add tee_shm_register_fd
On Fri, Aug 19, 2022 at 01:54:31PM +0530, Sumit Garg wrote: > Hi Olivier, > > On Fri, 12 Aug 2022 at 20:01, Olivier Masse wrote: > > > > Add a new ioctl called TEE_IOC_SHM_REGISTER_FD to register a > > shared memory from a dmabuf file descriptor. > > This new ioctl will allow the Linux Kernel to register a buffer > > to be used by the Secure Data Path OPTEE OS feature. > > > > Please find more information here: > > https://static.linaro.org/connect/san19/presentations/san19-107.pdf > > > > Patch tested on Hikey 6220. > > > > AFAIU, for the OP-TEE SDP feature to work you need to have a DMA-BUF > heap driver for allocating secure buffers through exposed chardev: > "/dev/dma_heap/sdp". Have you tested it with some out-of-tree driver > as I can't find it upstream? Also, do you plan to push that upstream > as well? > > BTW, please add a changelog while sending newer patch-set versions. Also after the huge discussion last year dma-buf are agreed to be under the "you need an open source userspace for any new uapi using them" rule that all gpu drivers are under. Does this exist here? -Daniel > > -Sumit > > > Etienne Carriere (1): > > tee: new ioctl to a register tee_shm from a dmabuf file descriptor > > > > drivers/tee/tee_core.c | 38 +++ > > drivers/tee/tee_shm.c| 99 +++- > > include/linux/tee_drv.h | 11 + > > include/uapi/linux/tee.h | 29 > > 4 files changed, 175 insertions(+), 2 deletions(-) > > > > -- > > 2.25.0 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/amdgpu: use dirty framebuffer helper
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index c20922a5af9f..5b09c8f4fe95 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -496,6 +497,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector
*amdgpu_connector,
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
+ .dirty = drm_atomic_helper_dirtyfb,
};
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
--
2.37.2
Re: [PATCH v6 1/6] drm/ttm: Add new callbacks to ttm res mgr
On Tue, Aug 16, 2022 at 10:33:16AM +0530, Arunpravin Paneer Selvam wrote:
>
>
> On 8/15/2022 4:35 PM, Christian König wrote:
> > Am 12.08.22 um 15:30 schrieb Arunpravin Paneer Selvam:
> > > We are adding two new callbacks to ttm resource manager
> > > function to handle intersection and compatibility of
> > > placement and resources.
> > >
> > > v2: move the amdgpu and ttm_range_manager changes to
> > > separate patches (Christian)
> > > v3: rename "intersect" to "intersects" (Matthew)
> > > v4: move !place check to the !res if and return false
> > > in ttm_resource_compatible() function (Christian)
> > > v5: move bits of code from patch number 6 to avoid
> > > temporary driver breakup (Christian)
> > >
> > > Signed-off-by: Christian König
> > > Signed-off-by: Arunpravin Paneer Selvam
> > >
> >
> > Patch #6 could still be cleaned up more now that we have the workaround
> > code in patch #1, but that not really a must have.
> >
> > Reviewed-by: Christian König for the entire
> > series.
> >
> > Do you already have commit rights?
>
> Hi Christian,
> I applied for drm-misc commit rights, waiting for the project maintainers to
> approve my request.
Why do all drivers have to implement the current behaviour? Can we have a
default implementation, which gets called if nothing is set instead?
I'm a bit confused why the bloat here ...
Also please document new callbacks precisely with inline kerneldoc. I know
ttm docs aren't great yet, but they don't get better if we don't start
somewhere. I think the in-depth comments for modeset vfuncs (e.g. in
drm_modeset_helper_vtables.h) are a good standard here.
-Daniel
>
> Thanks,
> Arun
> >
> > Regards,
> > Christian.
> >
> > > ---
> > > drivers/gpu/drm/ttm/ttm_bo.c | 9 ++--
> > > drivers/gpu/drm/ttm/ttm_resource.c | 77 +-
> > > include/drm/ttm/ttm_resource.h | 40
> > > 3 files changed, 119 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > > index c1bd006a5525..f066e8124c50 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > > @@ -518,6 +518,9 @@ static int ttm_bo_evict(struct ttm_buffer_object
> > > *bo,
> > > bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
> > > const struct ttm_place *place)
> > > {
> > > + struct ttm_resource *res = bo->resource;
> > > + struct ttm_device *bdev = bo->bdev;
> > > +
> > > dma_resv_assert_held(bo->base.resv);
> > > if (bo->resource->mem_type == TTM_PL_SYSTEM)
> > > return true;
> > > @@ -525,11 +528,7 @@ bool ttm_bo_eviction_valuable(struct
> > > ttm_buffer_object *bo,
> > > /* Don't evict this BO if it's outside of the
> > > * requested placement range
> > > */
> > > - if (place->fpfn >= (bo->resource->start +
> > > bo->resource->num_pages) ||
> > > - (place->lpfn && place->lpfn <= bo->resource->start))
> > > - return false;
> > > -
> > > - return true;
> > > + return ttm_resource_intersects(bdev, res, place, bo->base.size);
> > > }
> > > EXPORT_SYMBOL(ttm_bo_eviction_valuable);
> > > diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
> > > b/drivers/gpu/drm/ttm/ttm_resource.c
> > > index 20f9adcc3235..0d1f862a582b 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_resource.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_resource.c
> > > @@ -253,10 +253,84 @@ void ttm_resource_free(struct
> > > ttm_buffer_object *bo, struct ttm_resource **res)
> > > }
> > > EXPORT_SYMBOL(ttm_resource_free);
> > > +/**
> > > + * ttm_resource_intersects - test for intersection
> > > + *
> > > + * @bdev: TTM device structure
> > > + * @res: The resource to test
> > > + * @place: The placement to test
> > > + * @size: How many bytes the new allocation needs.
> > > + *
> > > + * Test if @res intersects with @place and @size. Used for testing
> > > if evictions
> > > + * are valueable or not.
> > > + *
> > > + * Returns true if the res placement intersects with @place and @size.
> > > + */
> > > +bool ttm_resource_intersects(struct ttm_device *bdev,
> > > + struct ttm_resource *res,
> > > + const struct ttm_place *place,
> > > + size_t size)
> > > +{
> > > + struct ttm_resource_manager *man;
> > > +
> > > + if (!res)
> > > + return false;
> > > +
> > > + if (!place)
> > > + return true;
> > > +
> > > + man = ttm_manager_type(bdev, res->mem_type);
> > > + if (!man->func->intersects) {
> > > + if (place->fpfn >= (res->start + res->num_pages) ||
> > > + (place->lpfn && place->lpfn <= res->start))
> > > + return false;
> > > +
> > > + return true;
> > > + }
> > > +
> > > + return man->func->intersects(man, res, place, size);
> > > +}
> > > +
> > > +/**
> > > + * ttm_resource_compatible - test for compatibility
> > > + *
> > > + * @bdev: TTM device
Re: [PATCH v2 1/4] drm/sched: Enable signaling for finished fence
On 2022-09-06 02:34, Christian König wrote: Am 05.09.22 um 18:34 schrieb Arvind Yadav: Here's enabling software signaling for finished fence. Signed-off-by: Arvind Yadav --- Changes in v1 : 1- Addressing Christian's comment to remove CONFIG_DEBUG_FS check from this patch. 2- The version of this patch is also changed and previously it was [PATCH 2/4] --- drivers/gpu/drm/scheduler/sched_main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index e0ab14e0fb6b..fe72de0e2911 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -962,6 +962,8 @@ static int drm_sched_main(void *param) /* Drop for original kref_init of the fence */ dma_fence_put(fence); + dma_fence_enable_sw_signaling(_fence->finished); Ok, this makes it a lot clearer. Previously I though that we have some bug in dma_fence_add_callback(). This is essentially the wrong place to call this, the finished fence should be enabled by the caller and not here. There is also another problem in dma_fence_enable_sw_signaling(), it returns early when the fence is already signaled: if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) return; Please remove that one first. Why we even need this explicit call if dma_fence_add_callback calls __dma_fence_enable_signaling anyway ? Andrey Thanks, Christian. + r = dma_fence_add_callback(fence, _job->cb, drm_sched_job_done_cb); if (r == -ENOENT)
Re: [ldv-project] [PATCH v2] drm/fb-helper: add virtual screen size check to drm_fb_helper_check_var()
On Thu, Aug 11, 2022 at 11:59:00PM +0300, Alexey Khoroshilov wrote:
> For v2 I would suggest to update description to something like this:
>
> Make sure that virtual screen size is not less than physical screen one.
>
> and comment to:
> /* make sure that virtual resolution >= physical resolution */
Did this land somewhere? If not please resend with r-b tags and
everything.
Thanks, Daniel
>
> --
> Alexey
>
>
> On 11.08.2022 17:54, Geert Uytterhoeven wrote:
> > Hi Andrey,
> >
> > On Thu, Aug 11, 2022 at 4:49 PM Andrey Strachuk wrote:
> >> Add virtual screen size check to drm_fb_helper_check_var() in
> >> order to validate userspace input.
> >>
> >> Found by Linux Verification Center (linuxtesting.org) with syzkaller.
> >>
> >> Signed-off-by: Andrey Strachuk
> >
> > Thanks for the update!
> >
> >> Fixes: 785b93ef8c30 ("drm/kms: move driver specific fb common code to
> >> helper functions (v2)")
> >
> > I'd drop the Fixes tag completely, as the bug was present in the
> > intel and radeon drivers before. But probably it doesn't matter, as no one
> > is gonna backport this to v2.6.31 and earlier ;-)
> >
> > Reviewed-by: Geert Uytterhoeven
> >
> > 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
> >
> > ___
> > ldv-project mailing list
> > ldv-proj...@linuxtesting.org
> > http://linuxtesting.org/cgi-bin/mailman/listinfo/ldv-project
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v2 30/39] docs: gpu: i915.rst: gt: add more kernel-doc markups
On Tue, 9 Aug 2022 06:01:53 -0400 Rodrigo Vivi wrote: > On Wed, Jul 13, 2022 at 09:12:18AM +0100, Mauro Carvalho Chehab wrote: > > There are several documented GT kAPI that aren't currently part > > of the docs. Add them, as this allows identifying issues with > > badly-formatted tags. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > > > To avoid mailbombing on a large number of people, only mailing lists were > > C/C on the cover. > > See [PATCH v2 00/39] at: > > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > > > Documentation/gpu/i915.rst | 43 +- > > 1 file changed, 42 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > > index 2ad7941a79f2..afd8c0e3c689 100644 > > --- a/Documentation/gpu/i915.rst > > +++ b/Documentation/gpu/i915.rst > > @@ -149,7 +149,6 @@ Misc display functions > > > > .. kernel-doc:: drivers/gpu/drm/i915/display/skl_scaler.c > > > > - > > Plane Configuration > > --- > > > > @@ -308,6 +307,48 @@ Multicast/Replicated (MCR) Registers > > .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c > > :internal: > > > > +GT engine > > +- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_types.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_cs.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_pm.c > > + > > +GT context > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_context.h > > why does the context deserves a separated section and the > many others below no? Good question. The patches adding stuff to i915.rst are the hardest ones to produce, in the sense that it is not easy to have a common criteria about when creating or not a new section. I tried to follow the same as other things for the same type, but it is hard to classify. The main point is that they should be somewhere there, in order to start producing errors when building the docs. Reorganizing those markups should be easily done once all files with kernel-docs gets added there. Anyway, I'll keep this under: Other GT functionality Section. We can shift things later on as needed. > > + > > +Graphics Translation Tables > > +--- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_ggtt.c > > + > > +Other GT functionality > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gsc.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.h > > Why aren't these gtt ones in the above block? why only > having the global gtt there? Makes sense. I'll place GTT together with GGTT. > > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_migrate.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_mocs.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rc6.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_reset.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps_types.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_sseu.c > > + > > Memory Management and Command Submission > > > > > > -- > > 2.36.1 > >
Re: [Intel-gfx] [PATCH v2 35/39] docs: gpu: i915.rst: add the remaining kernel-doc markup files
On Tue, 9 Aug 2022 06:20:57 -0400 Rodrigo Vivi wrote: > On Wed, Jul 13, 2022 at 09:12:23AM +0100, Mauro Carvalho Chehab wrote: > > There are other files with kernel-doc markups: > > > > $ git grep -l "/\*\*" $(git ls-files|grep drivers/gpu/drm/i915/) > > >kernel-doc-files > > $ for i in $(cat kernel-doc-files); do if [ "$(git grep $i > > Documentation/)" == "" ]; then echo "$i"; fi; done >aaa > > > > Add them to i915.rst as well. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > > > To avoid mailbombing on a large number of people, only mailing lists were > > C/C on the cover. > > See [PATCH v2 00/39] at: > > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > > > Documentation/gpu/i915.rst | 87 ++ > > 1 file changed, 87 insertions(+) > > > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > > index 974754586be8..6bb50edc6d79 100644 > > --- a/Documentation/gpu/i915.rst > > +++ b/Documentation/gpu/i915.rst > > @@ -13,6 +13,11 @@ Core Driver Infrastructure > > This section covers core driver infrastructure used by both the display > > and the GEM parts of the driver. > > > > +Core driver > > +--- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_driver.c > > + > > Runtime Power Management > > > > > > @@ -29,6 +34,10 @@ Runtime Power Management > > > > .. kernel-doc:: drivers/gpu/drm/i915/intel_pm.c > > > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wakeref.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_active.h > > not sure if this belongs to this group... > > > + > > Interrupt Handling > > -- > > > > @@ -44,6 +53,28 @@ Interrupt Handling > > .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c > > :functions: intel_runtime_pm_enable_interrupts > > > > +Error handling > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_gpu_error.c > > not sure if this gt hang stuff deserves a separated section > alone and if the name is the best one > > > + > > +Memory Handling > > +--- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_mm.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_memory_region.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_memcpy.c > > + > > Intel GVT-g Guest Support(vGPU) > > ^ missing space > > > --- > > > > @@ -109,6 +140,54 @@ Workarounds > > .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c > > :doc: Hardware workarounds > > > > +32-bits compatible ioctl Logic > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ioc32.c > > + > > +Scatterlist handling > > + > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.c > > + > > +i915 request > > + > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.c > > + > > +Ancillary routines > > maybe simply have an "Others" section and put everything > that has only one item like the gpu hang one? OK! > > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_device_info.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_params.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_sw_fence_work.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_syncmap.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_pcode.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_reg_defs.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.h > > + > > + > > +PXP > > Protected Xe Path (PXP) > > > > +--- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_irq.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_tee.c > > + > > Display Hardware Handling > > = > > > > @@ -618,6 +697,12 @@ Protected Objects > > Table Manager (TTM) > > --- > > > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_region_ttm.c > > + > > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.h > > @@ -627,6 +712,8 @@ Table Manager (TTM) > > Graphics Execution Manager (GEM) > > > > > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_gem.c > >
Re: [Intel-gfx] [PATCH v2 18/39] drm/i915: intel_pm.c: fix some ascii artwork at kernel-doc
On Tue, 9 Aug 2022 05:55:10 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:06AM +0100, Mauro Carvalho Chehab wrote:
> > Preserving ascii artwork on kernel-docs is tricky, as it needs
> > to respect both the Sphinx rules and be properly parsed by
> > kernel-doc script.
> >
> > The Sphinx syntax require code-blocks, which is:
> >
> > ::
> >
> > followed by a blank line and indented lines.
> >
> > But kernel-doc only works fine if the first and the last line
> > are indented with the same amount of spaces.
> >
> > Also, a "\" at the end means that the next line should be merged
> > with the first one.
>
> my first reaction was: "do we really need those new empty ( ) blocks?"
>
> Then I read this ;)
Yeah, it is tricky to get it right, due to kernel-doc + Sphinx here.
Also, I bet that this would be needed even for ReST files with
C code on it, as it is likely the C domain encoding at Sphinx that
handles continuation lines with "\" at the end...
>
> Reviewed-by: Rodrigo Vivi
>
> >
> > Change the ascii artwork to be on code-blocks, starting all
> > lines at the same characters and not ending with a backslash.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> >
> > To avoid mailbombing on a large number of people, only mailing lists were
> > C/C on the cover.
> > See [PATCH v2 00/39] at:
> > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> >
> > drivers/gpu/drm/i915/intel_pm.c | 33 ++---
> > 1 file changed, 18 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index f06babdb3a8c..d3393752b04b 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -684,18 +684,20 @@ static const struct intel_watermark_params
> > i845_wm_info = {
> > * FIFO is relatively small compared to the amount of data
> > * fetched.
> > *
> > - * The FIFO level vs. time graph might look something like:
> > + * The FIFO level vs. time graph might look something like::
> > *
> > - * |\ |\
> > - * | \ | \
> > - * __---__---__ (- plane active, _ blanking)
> > - * -> time
> > + * ^
> > + * | |\ |\ ( )
> > + * | | \ | \ ( )
> > + * | __---__---__ (- plane active, _ blanking)
> > + * +---> time
> > *
> > - * or perhaps like this:
> > + * or perhaps like this::
> > *
> > - * |\|\ |\|\
> > - * ______ (- plane active, _ blanking)
> > - * -> time
> > + * ^
> > + * | |\|\ |\|\ ( )
> > + * | ______ (- plane active, _ blanking)
> > + * +---> time
> > *
> > * Returns:
> > * The watermark in bytes
> > @@ -731,13 +733,14 @@ static unsigned int intel_wm_method1(unsigned int
> > pixel_rate,
> > * FIFO is relatively large compared to the amount of data
> > * fetched.
> > *
> > - * The FIFO level vs. time graph might look something like:
> > + * The FIFO level vs. time graph might look something like::
> > *
> > - *|\___ |\___
> > - *|\___ |\___
> > - *|\ |\
> > - * __ --__--__--__--__--__--__ (- plane active, _ blanking)
> > - * -> time
> > + * ^
> > + * | |\___ |\___( )
> > + * | |\___ |\___( )
> > + * | |\ |\ ( )
> > + * | __ --__--__--__--__--__--__ (- plane active, _ blanking)
> > + * +-> time
> > *
> > * Returns:
> > * The watermark in bytes
> > --
> > 2.36.1
> >
Re: [Intel-gfx] [PATCH v2 16/39] drm/i915: intel_fb: fix a kernel-doc issue with Sphinx
On Fri, 15 Jul 2022 17:40:25 -0400 Rodrigo Vivi wrote: > On Wed, Jul 13, 2022 at 09:12:04AM +0100, Mauro Carvalho Chehab wrote: > > We can't use %foo[] as this produces a bad markup. > > Use instead, the emphasis markup directly. > > > > Fix this issue: > > Documentation/gpu/i915:136: > > ./drivers/gpu/drm/i915/display/intel_fb.c:280: WARNING: Inline strong > > start-string without end-string. > > > > Signed-off-by: Mauro Carvalho Chehab > > Just trying to understand as well on why in a few you had chosen ```foo``` > and here **foo**. why? > No particular reason. I'll use ``foo`` here too, keeping your reviewed-by. > anyway, not a blocker: > > Reviewed-by: Rodrigo Vivi > > > > > --- > > > > To avoid mailbombing on a large number of people, only mailing lists were > > C/C on the cover. > > See [PATCH v2 00/39] at: > > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > > > drivers/gpu/drm/i915/display/intel_fb.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c > > b/drivers/gpu/drm/i915/display/intel_fb.c > > index b191915ab351..fe72c75a9c79 100644 > > --- a/drivers/gpu/drm/i915/display/intel_fb.c > > +++ b/drivers/gpu/drm/i915/display/intel_fb.c > > @@ -276,7 +276,7 @@ lookup_format_info(const struct drm_format_info > > formats[], > > * @cmd: FB add command structure > > * > > * Returns: > > - * Returns the format information for @cmd->pixel_format specific to > > @cmd->modifier[0], > > + * Returns the format information for @cmd->pixel_format specific to > > **cmd->modifier[0]**, > > * or %NULL if the modifier doesn't override the format. > > */ > > const struct drm_format_info * > > -- > > 2.36.1 > >
Re: [Intel-gfx] [PATCH v2 15/39] drm/i915: intel_dp_link_training.c: fix kernel-doc markup
On Tue, 9 Aug 2022 05:51:39 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:03AM +0100, Mauro Carvalho Chehab wrote:
> > The return code table is not properly marked, causing warnings
> > and being badly parsed by Sphinx:
> >
> > Documentation/gpu/i915:130:
> > ./drivers/gpu/drm/i915/display/intel_dp_link_training.c:183: WARNING: Block
> > quote ends without a blank line; unexpected unindent.
> > Documentation/gpu/i915:130:
> > ./drivers/gpu/drm/i915/display/intel_dp_link_training.c:186: WARNING:
> > Definition list ends without a blank line; unexpected unindent.
> >
> > Use table markups to fix it.
>
> cool, I didn't know that
Yeah, you can use almost all Sphinx tags inside a kernel-doc markup,
taking some care with indents and not conflicting with the things
that kernel-doc itself parses.
The same is also valid for uAPI stuff inside Documentation/ABI.
Regards,
Mauro
>
> Reviewed-by: Rodrigo Vivi
>
>
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> >
> > To avoid mailbombing on a large number of people, only mailing lists were
> > C/C on the cover.
> > See [PATCH v2 00/39] at:
> > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> >
> > drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index 9feaf1a589f3..23a269fcf6ca 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -177,12 +177,14 @@ static int intel_dp_init_lttpr(struct intel_dp
> > *intel_dp, const u8 dpcd[DP_RECEI
> > * transparent mode link training mode.
> > *
> > * Returns:
> > + *
> > =
> > * >0 if LTTPRs were detected and the non-transparent LT mode was set.
> > The
> > * DPRX capabilities are read out.
> > *0 if no LTTPRs or more than 8 LTTPRs were detected or in case of a
> > * detection failure and the transparent LT mode was set. The DPRX
> > * capabilities are read out.
> > * <0 Reading out the DPRX capabilities failed.
> > + *
> > =
> > */
> > int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
> > {
> > --
> > 2.36.1
> >
Re: [Intel-gfx] [PATCH v2 38/39] drm/i915: add descriptions for some RPM macros at intel_gt_pm.h
On Tue, 9 Aug 2022 06:12:06 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:26AM +0100, Mauro Carvalho Chehab wrote:
> > The intel_gt_pm.h file contains some convenient macros to be used
> > in GT code in order to get/put runtime PM references and for
> > checking them.
> >
> > Add descriptions based on the ones at intel_wakeref.h and
> > intel_runtime_pm.c.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> >
> > To avoid mailbombing on a large number of people, only mailing lists were
> > C/C on the cover.
> > See [PATCH v2 00/39] at:
> > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> >
> > Documentation/gpu/i915.rst| 2 +
> > drivers/gpu/drm/i915/gt/intel_gt_pm.h | 62 +++
> > 2 files changed, 64 insertions(+)
> >
> > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> > index 6bb50edc6d79..9862d504df4d 100644
> > --- a/Documentation/gpu/i915.rst
> > +++ b/Documentation/gpu/i915.rst
> > @@ -709,6 +709,8 @@ Table Manager (TTM)
> >
> > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> >
> > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_pm.h
>
> I don't believe this is the right placement for this.
I'll add it then at:
Other GT functionality
Section.
Regards,
Mauro
>
> the rest lgtm
>
> > +
> > Graphics Execution Manager (GEM)
> >
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > index bc898df7a48c..a8ea6846980a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > @@ -11,21 +11,57 @@
> > #include "intel_gt_types.h"
> > #include "intel_wakeref.h"
> >
> > +/**
> > + * intel_gt_pm_is_awake: Query whether the runtime PM is awake held
> > + *
> > + * @gt: pointer to the graphics engine
> > + *
> > + * Returns: true if a runtime pm reference is currently held and the GT is
> > + * awake.
> > + */
> > static inline bool intel_gt_pm_is_awake(const struct intel_gt *gt)
> > {
> > return intel_wakeref_is_active(>wakeref);
> > }
> >
> > +/**
> > + * intel_gt_pm_get: grab a runtime PM reference ensuring that GT is
> > powered up
> > + * @gt: pointer to the graphics engine
> > + *
> > + * Any runtime pm reference obtained by this function must have a symmetric
> > + * call to intel_gt_pm_put() to release the reference again.
> > + *
> > + * Note that this is allowed to fail, in which case the runtime-pm wakeref
> > + * will be released and the acquisition unwound.
> > + */
> > static inline void intel_gt_pm_get(struct intel_gt *gt)
> > {
> > intel_wakeref_get(>wakeref);
> > }
> >
> > +/**
> > + * __intel_gt_pm_get: Acquire the runtime PM reference again
> > + * @gt: pointer to the graphics engine which contains the wakeref
> > + *
> > + * Increment the PM reference counter, only valid if it is already held by
> > + * the caller.
> > + *
> > + * See intel_gt_pm_get().
> > + */
> > static inline void __intel_gt_pm_get(struct intel_gt *gt)
> > {
> > __intel_wakeref_get(>wakeref);
> > }
> >
> > +/**
> > + * intel_gt_pm_get_if_awake: Acquire the runtime PM reference if active
> > + * @gt: pointer to the graphics engine which contains the PM reference
> > + *
> > + * Acquire a hold on the PM reference, but only if the GT is already
> > + * active.
> > + *
> > + * Returns: true if the wakeref was acquired, false otherwise.
> > + */
> > static inline bool intel_gt_pm_get_if_awake(struct intel_gt *gt)
> > {
> > return intel_wakeref_get_if_active(>wakeref);
> > @@ -36,6 +72,14 @@ static inline void intel_gt_pm_might_get(struct intel_gt
> > *gt)
> > intel_wakeref_might_get(>wakeref);
> > }
> >
> > +/**
> > + * intel_gt_pm_put: Release the runtime PM reference
> > + * @gt: pointer to the graphics engine which contains the PM reference
> > + *
> > + * Release our hold on the runtime PM for GT.
> > + *
> > + * It might power down the GT right away if this is the last reference.
> > + */
> > static inline void intel_gt_pm_put(struct intel_gt *gt)
> > {
> > intel_wakeref_put(>wakeref);
> > @@ -51,10 +95,28 @@ static inline void intel_gt_pm_might_put(struct
> > intel_gt *gt)
> > intel_wakeref_might_put(>wakeref);
> > }
> >
> > +/**
> > + * with_intel_gt_pm - get a GT reference ensuring that GT is powered up,
> > + * run some code and then put the reference away.
> > + *
> > + * @gt: pointer to the gt
> > + * @tmp: pointer to a temporary wakeref.
> > + */
> > #define with_intel_gt_pm(gt, tmp) \
> > for (tmp = 1, intel_gt_pm_get(gt); tmp; \
> > intel_gt_pm_put(gt), tmp = 0)
> >
> > +/**
> > + * intel_gt_pm_wait_for_idle: Wait until the runtime PM reference is idle
> > + * @gt: pointer to the graphics engine which contains the PM reference
> > + *
> > + * Wait for the earlier asynchronous release of the runtime PM reference.
> > Note
> > + * this will wait for any third
Re: [Linaro-mm-sig] [PATCH v2 1/3] dma-buf: Add ioctl to query mmap info
On Mon, Aug 01, 2022 at 10:04:55AM -0700, Rob Clark wrote:
> 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. fix compiler warning
I think I bikeshedded this on irc already, here for the record too.
- this wont work for buffers which do change the mapping when they move
(ttm can do that). And cros does make noises about discrete gpus I've
heard, this matters even for you :-)
- I'm pretty sure this will put is even more onto the nasty people list
that dma-api folks maintain, especially with passing this all to
userspace
- follow_pte() can figure this out internally in the kernel and kvm is
already using this, and I think doing this all internally with mmu
notifier and what not to make sure it all stays in sync is the right
approach. So your kvm/whatever combo should be able to figure out wth
it's supposed to be doing.
I think if you make this a virtio special case like we've done with the
magic uuid stuff, then that would make sense. Making it a full dma-buf
interface doesn't imo.
Cheers, Daniel
>
> drivers/dma-buf/dma-buf.c| 26 ++
> include/linux/dma-buf.h | 7 +++
> include/uapi/linux/dma-buf.h | 28
> 3 files changed, 61 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 32f55640890c..87c52f080274 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -326,6 +326,29 @@ 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_VM_PROT:
> + if (!dmabuf->ops->mmap_info)
> + return -ENOSYS;
> + arg.value = dmabuf->ops->mmap_info(dmabuf);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (copy_to_user(uarg, , sizeof(arg)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> static long dma_buf_ioctl(struct file *file,
> unsigned int cmd, unsigned long arg)
> {
> @@ -369,6 +392,9 @@ static long dma_buf_ioctl(struct file *file,
> case DMA_BUF_SET_NAME_B:
> return dma_buf_set_name(dmabuf, (const char __user *)arg);
>
> + case DMA_BUF_IOCTL_INFO:
> + return dma_buf_info(dmabuf, (void __user *)arg);
> +
> default:
> return -ENOTTY;
> }
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 71731796c8c3..6f4de64a5937 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -283,6 +283,13 @@ struct dma_buf_ops {
>*/
> int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
>
> + /**
> + * @mmap_info:
> + *
> + * Return mmapping info for the buffer. See DMA_BUF_INFO_VM_PROT.
> + */
> + int (*mmap_info)(struct dma_buf *);
> +
> int (*vmap)(struct dma_buf *dmabuf, struct iosys_map *map);
> void (*vunmap)(struct dma_buf *dmabuf, struct iosys_map *map);
> };
> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> index b1523cb8ab30..a41adac0f46a 100644
> --- a/include/uapi/linux/dma-buf.h
> +++ b/include/uapi/linux/dma-buf.h
> @@ -85,6 +85,32 @@ struct dma_buf_sync {
>
> #define DMA_BUF_NAME_LEN 32
>
> +
> +/**
> + * struct dma_buf_info - Query info about the buffer.
> + */
> +struct dma_buf_info {
> +
> +#define DMA_BUF_INFO_VM_PROT 1
> +# define DMA_BUF_VM_PROT_WC 0
> +# define DMA_BUF_VM_PROT_CACHED 1
> +
> + /**
> + * @param: Which param to query
> + *
> + * DMA_BUF_INFO_BM_PROT:
> + * Query the access permissions of userspace mmap's of this buffer.
> + * Returns one of DMA_BUF_VM_PROT_x
> + */
> + __u32 param;
> + __u32 pad;
> +
> + /**
> + * @value: Return value of the query.
> + */
> + __u64 value;
> +};
> +
> #define DMA_BUF_BASE 'b'
> #define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync)
>
> @@ -95,4 +121,6 @@ struct dma_buf_sync {
> #define
Re: [PATCH v2 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf
On Tue, Sep 6, 2022 at 8:59 PM Jason Gunthorpe wrote: > > On Tue, Sep 06, 2022 at 03:34:02PM +0300, Oded Gabbay wrote: > > > > > > > + /* > > > > > > + * Since the memory being mapped is a device memory it could > > > > > > never be in > > > > > > + * CPU caches. > > > > > > + */ > > > > > DMA_ATTR_SKIP_CPU_SYNC doesn't even apply to dma_map_resource, not > > > > > sure > > > > > where this wisdom comes from. > > > > > > Habana driver > > I hate to throw the ball at someone else, but I actually copied the > > code from the amdgpu driver, from amdgpu_vram_mgr_alloc_sgt() iirc. > > And if you remember Jason, you asked why we use this specific define > > in the original review you did and I replied the following (to which > > you agreed and that's why we added the comment): > > Yes, I remember, but Christophs remark is that DMA_ATTR_SKIP_CPU_SYNC > doesn't even do anything when passed to dma_map_resource(). > > The only attr that seems to be used is DMA_ATTR_PRIVILEGED from what I > can see. > > Jason Yes, it appears he is correct. Probably what happened is that either this was originally copied from a use of dma_map_page or something similar that does check this attribute, or maybe dma_map_resource used it in the past and the underlying code has changed. Regardless, it seems we can remove it from the calls to dma_map_resource. I went over the kernel code and it seems only habana and amdgpu (and amdkfd) are passing this property to dma_map_resource. All other callers just pass 0. Oded
Re: [PATCH 2/2] efi: earlycon: Add support for generic framebuffers and move to fbdev subsystem
On Sun, Aug 07, 2022 at 08:53:14AM +0200, Greg Kroah-Hartman wrote: > On Sat, Aug 06, 2022 at 07:26:07PM +0300, Markuss Broks wrote: > > Hi Greg, > > > > On 7/28/22 18:01, Greg Kroah-Hartman wrote: > > > On Thu, Jul 28, 2022 at 05:52:04PM +0300, Markuss Broks wrote: > > > > Hi Greg, > > > > > > > > On 7/28/22 17:39, Greg Kroah-Hartman wrote: > > > > > On Thu, Jul 28, 2022 at 05:28:19PM +0300, Markuss Broks wrote: > > > > > > Add early console support for generic linear framebuffer devices. > > > > > > This driver supports probing from cmdline early parameters > > > > > > or from the device-tree using information in simple-framebuffer > > > > > > node. > > > > > > The EFI functionality should be retained in whole. > > > > > > The driver was disabled on ARM because of a bug in early_ioremap > > > > > > implementation on ARM. > > > > > > > > > > > > Signed-off-by: Markuss Broks > > > > > > --- > > > > > >.../admin-guide/kernel-parameters.txt | 12 +- > > > > > >MAINTAINERS | 5 + > > > > > >drivers/firmware/efi/Kconfig | 6 +- > > > > > >drivers/firmware/efi/Makefile | 1 - > > > > > >drivers/firmware/efi/earlycon.c | 246 > > > > > > -- > > > > > >drivers/video/fbdev/Kconfig | 11 + > > > > > >drivers/video/fbdev/Makefile | 1 + > > > > > >drivers/video/fbdev/earlycon.c| 301 > > > > > > ++ > > > > > >8 files changed, 327 insertions(+), 256 deletions(-) > > > > > >delete mode 100644 drivers/firmware/efi/earlycon.c > > > > > >create mode 100644 drivers/video/fbdev/earlycon.c > > > > > > > > > > That should be a rename, not a delete/create, right? > > > > > > > > Should this change be split into two separate commits, > > > > one for moving the file and the second for making changes? > > > > > > Git will show a rename and modification properly, if you use -M to git > > > format-patch, so it should be fine. > > > > It appears that there are so many changes Git would refuse to make it a > > "move" no matter what I do. What should be done here: should it be two > > separate commits for move/change or should it just be kept as delete/create? > > One commit to move the file, and then add your changes on top of it > might be the easiest to review, right? +1 I think this should be a least - commit to move the file, as unchanged as possible - commit to auto-select the right mapping mode (or maybe that's only in v2) - actual change to add the simplefb support with a clearly readable diff But also video/console is for Greg to maintain, I'm trying hard to not go even more stupid :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/udl: Enable damage clipping
On Thu, Jul 28, 2022 at 09:47:56AM +0200, Thomas Zimmermann wrote: > Call drm_plane_enable_fb_damage_clips() and give userspace a chance > of minimizing the updated display area. > > Signed-off-by: Thomas Zimmermann > --- > 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 e67c40a48fb4..ce427128f034 100644 > --- a/drivers/gpu/drm/udl/udl_modeset.c > +++ b/drivers/gpu/drm/udl/udl_modeset.c > @@ -479,6 +479,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); I'm assuming this passes with all the igts we have (I hope those finally landed) and a damage-capable compositor doesn't go boom either? Either way patch lgtm. Reviewed-by: Daniel Vetter Also I wonder whether we should have a check in the damage helpers to make sure drivers don't forget to call this function to set up the uapi ... Cheers, Daniel > > drm_mode_config_reset(dev); > > -- > 2.37.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/udl: Restore display mode on resume
On Thu, Jul 28, 2022 at 09:31:09AM +0200, Thomas Zimmermann wrote:
> 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
> ---
> 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 e67c40a48fb4..bf17f38fdb54 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;
The helpers shouldn't even call you in this case. Which means you
should outright remove this check. I think this simple dates back to the
old legacy crtc helper implementation, where stuff like this was necessary
because the crtc helpers just loved to disable you multiple times.
Looking at git history this seems to have been a regression introduced by
997d33c35618 ("drm/udl: Inline DPMS code into CRTC enable and disable
functions")
So you need cc: stable here and all that. And before this change there was
no such check either, so we don't need to backport if further.
Since this seems to have been stuck for a while here's my upfront
Reviewed-by: Daniel Vetter
for v2 with all these changes applied.
-Daniel
>
> /* enable display */
> --
> 2.37.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v2 09/12] drm/i915/uncore: Add GSI offset to uncore
On Tue, Sep 06, 2022 at 04:14:21PM +0530, Iddamsetty, Aravind wrote:
>
>
> On 03-09-2022 05:02, Matt Roper wrote:
> > GT non-engine registers (referred to as "GSI" registers by the spec)
> > have the same relative offsets on standalone media as they do on the
> > primary GT, just with an additional "GSI offset" added to their MMIO
> > address. If we store this GSI offset in the standalone media's
> > intel_uncore structure, it can be automatically applied to all GSI reg
> > reads/writes that happen on that GT, allowing us to re-use our existing
> > GT code with minimal changes.
> >
> > Forcewake and shadowed register tables for the media GT (which will be
> > added in a future patch) are listed as final addresses that already
> > include the GSI offset, so we also need to add the GSI offset before
> > doing lookups of registers in one of those tables.
> >
> > Cc: Daniele Ceraolo Spurio
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt.c | 17 ++---
> > drivers/gpu/drm/i915/intel_device_info.h | 4 +++-
> > drivers/gpu/drm/i915/intel_uncore.c | 10 --
> > drivers/gpu/drm/i915/intel_uncore.h | 22 --
> > 4 files changed, 45 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > index fbb5e32979a4..a6ed11b933eb 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -776,10 +776,20 @@ void intel_gt_driver_late_release_all(struct
> > drm_i915_private *i915)
> > }
> > }
> >
> > -static int intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t phys_addr)
> > +/*
> > + * Note: the gsi_offset parameter here isn't used, but we want to keep the
> > + * function signature equivalent to gtdef->setup() so that it can be
> > plugged
> > + * in when we enabled remote tiles in the future.
> > + */
> > +static int intel_gt_tile_setup(struct intel_gt *gt,
> > + phys_addr_t phys_addr,
> > + u32 gsi_offset)
> > {
> > int ret;
> >
> > + /* GSI offset is only applicable for media GTs */
> > + drm_WARN_ON(>i915->drm, gsi_offset);
> > +
> > if (!gt_is_root(gt)) {
> > struct intel_uncore *uncore;
> >
> > @@ -832,7 +842,7 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
> > gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
> >
> > drm_dbg(>drm, "Setting up %s\n", gt->name);
> > - ret = intel_gt_tile_setup(gt, phys_addr);
> > + ret = intel_gt_tile_setup(gt, phys_addr, 0);
> > if (ret)
> > return ret;
> >
> > @@ -865,7 +875,8 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
> > goto err;
> > }
> >
> > - ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
> > + ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base,
> > + gtdef->gsi_offset);
> > if (ret)
> > goto err;
> >
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> > b/drivers/gpu/drm/i915/intel_device_info.h
> > index b408ce384cd7..85e0ef0e91b1 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -254,8 +254,10 @@ struct intel_gt_definition {
> > enum intel_gt_type type;
> > char *name;
> > int (*setup)(struct intel_gt *gt,
> > -phys_addr_t phys_addr);
> > +phys_addr_t phys_addr,
> > +u32 gsi_offset);
> > u32 mapping_base;
> > + u32 gsi_offset;
> > intel_engine_mask_t engine_mask;
> > };
> >
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index 33bdcbc77ab2..ecb02421502d 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -927,6 +927,9 @@ find_fw_domain(struct intel_uncore *uncore, u32 offset)
> > {
> > const struct intel_forcewake_range *entry;
> >
> > + if (IS_GSI_REG(offset))
> > + offset += uncore->gsi_offset;
> > +
> > entry = BSEARCH(offset,
> > uncore->fw_domains_table,
> > uncore->fw_domains_table_entries,
> > @@ -1142,6 +1145,9 @@ static bool is_shadowed(struct intel_uncore *uncore,
> > u32 offset)
> > if (drm_WARN_ON(>i915->drm, !uncore->shadowed_reg_table))
> > return false;
> >
> > + if (IS_GSI_REG(offset))
> > + offset += uncore->gsi_offset;
> > +
> > return BSEARCH(offset,
> >uncore->shadowed_reg_table,
> >uncore->shadowed_reg_table_entries,
> > @@ -1994,8 +2000,8 @@ static int __fw_domain_init(struct intel_uncore
> > *uncore,
> >
> > d->uncore = uncore;
> > d->wake_count = 0;
> > - d->reg_set = uncore->regs + i915_mmio_reg_offset(reg_set);
> > - d->reg_ack = uncore->regs +
Re: [PATCH v4 3/5] arm64: dts: allwinner: h6: Add GPU OPP table
Hi Jernej,
On Tue, 6 Sept 2022 at 21:10, Jernej Škrabec wrote:
>
> Dne torek, 06. september 2022 ob 17:30:32 CEST je Clément Péron napisal(a):
> > Add an Operating Performance Points table for the GPU to
> > enable Dynamic Voltage & Frequency Scaling on the H6.
> >
> > The voltage range is set with minimal voltage set to the target
> > and the maximal voltage set to 1.2V. This allow DVFS framework to
> > work properly on board with fixed regulator.
> >
> > Signed-off-by: Clément Péron
> > ---
> > .../boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi | 87 +++
> > 1 file changed, 87 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi new file mode 100644
> > index ..b48049c4fc85
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi
> > @@ -0,0 +1,87 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +// Copyright (C) 2022 Clément Péron
> > +
> > +/ {
> > + gpu_opp_table: opp-table-gpu {
> > + compatible = "operating-points-v2";
> > +
> > + opp-21600 {
> > + opp-hz = /bits/ 64 <21600>;
> > + opp-microvolt = <81 81 120>;
> > + };
> > +
> > + opp-26400 {
> > + opp-hz = /bits/ 64 <26400>;
> > + opp-microvolt = <81 81 120>;
> > + };
>
> As mentioned in clock patch review, rates below 288 MHz are deemed unstable on
> GPU PLL by vendor GPU kernel driver. At least in the BSP version that I have.
> Did you test these points? If not, better to drop them.
I changed the governor to userspace and set the freq to 216MHz / 264MHz
Run glmark2 and didn't observe any glitch nor issue.
I'm not sure if it's enough to say it's stable but I didn't observe
any strange behavior.
Regards,
Clement
>
> Best regards,
> Jernej
>
> > +
> > + opp-31200 {
> > + opp-hz = /bits/ 64 <31200>;
> > + opp-microvolt = <81 81 120>;
> > + };
> > +
> > + opp-33600 {
> > + opp-hz = /bits/ 64 <33600>;
> > + opp-microvolt = <81 81 120>;
> > + };
> > +
> > + opp-36000 {
> > + opp-hz = /bits/ 64 <36000>;
> > + opp-microvolt = <82 82 120>;
> > + };
> > +
> > + opp-38400 {
> > + opp-hz = /bits/ 64 <38400>;
> > + opp-microvolt = <83 83 120>;
> > + };
> > +
> > + opp-40800 {
> > + opp-hz = /bits/ 64 <40800>;
> > + opp-microvolt = <84 84 120>;
> > + };
> > +
> > + opp-42000 {
> > + opp-hz = /bits/ 64 <42000>;
> > + opp-microvolt = <85 85 120>;
> > + };
> > +
> > + opp-43200 {
> > + opp-hz = /bits/ 64 <43200>;
> > + opp-microvolt = <86 86 120>;
> > + };
> > +
> > + opp-45600 {
> > + opp-hz = /bits/ 64 <45600>;
> > + opp-microvolt = <87 87 120>;
> > + };
> > +
> > + opp-50400 {
> > + opp-hz = /bits/ 64 <50400>;
> > + opp-microvolt = <89 89 120>;
> > + };
> > +
> > + opp-54000 {
> > + opp-hz = /bits/ 64 <54000>;
> > + opp-microvolt = <91 91 120>;
> > + };
> > +
> > + opp-57600 {
> > + opp-hz = /bits/ 64 <57600>;
> > + opp-microvolt = <93 93 120>;
> > + };
> > +
> > + opp-62400 {
> > + opp-hz = /bits/ 64 <62400>;
> > + opp-microvolt = <95 95 120>;
> > + };
> > +
> > + opp-75600 {
> > + opp-hz = /bits/ 64 <75600>;
> > + opp-microvolt = <104 104 120>;
> > + };
> > + };
> > +};
> > +
> > + {
> > + operating-points-v2 = <_opp_table>;
> > +};
> > --
> > 2.34.1
>
>
Re: [PATCH] drm/via: Add new condition to via_dma_cleanup()
On Fri, Jul 29, 2022 at 12:06:43PM +0300, Alisa Khabibrakhmanova wrote:
> Pointer dev_priv->mmio, which was checked for NULL at via_do_init_map(),
> is passed to via_do_cleanup_map() and is dereferenced there without check.
>
> The patch adds the condition in via_dma_cleanup() which prevents potential
> NULL
> pointer dereference.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: 22f579c621e2 ("drm: Add via unichrome support")
> Signed-off-by: Alisa Khabibrakhmanova
This seems to have fallen through cracks, I applied it to drm-misc-next
now.
Thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/via/via_dri1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/via/via_dri1.c b/drivers/gpu/drm/via/via_dri1.c
> index d695d9291ece..691e3ceb0062 100644
> --- a/drivers/gpu/drm/via/via_dri1.c
> +++ b/drivers/gpu/drm/via/via_dri1.c
> @@ -2961,7 +2961,7 @@ int via_dma_cleanup(struct drm_device *dev)
> drm_via_private_t *dev_priv =
> (drm_via_private_t *) dev->dev_private;
>
> - if (dev_priv->ring.virtual_start) {
> + if (dev_priv->ring.virtual_start && dev_priv->mmio) {
> via_cmdbuf_reset(dev_priv);
>
> drm_legacy_ioremapfree(_priv->ring.map, dev);
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] drm: Prevent modeset helpers to access an uninitialized drm_mode_config
On Mon, Jul 25, 2022 at 10:28:21AM +0200, Javier Martinez Canillas wrote: > Hello Thomas, > > On 7/25/22 09:12, Thomas Zimmermann wrote: > > [...] > > > Let make the DRM core more robust and prevent this to happen, by marking > a > struct drm_mode_config as initialized during drmm_mode_config_init(). > that > way helpers can check for it and not attempt to grab uninitialized > mutexes. > >>> > >>> I disagree. This patch looks like cargo-cult programming and entirely > >>> arbitrary. The solution here is to fix drivers. The actual test to > >>> perform is to instrument the mutex implementation to detect > >>> uninitialized mutexes. > >>> > >> > >> While I do agree that drivers should be fixed, IMO we should try to make it > >> hard for the kernel to crash. We already have checks in other DRM helpers > >> to > >> avoid accessing uninitialized data, so I don't see why we couldn't do the > >> same here. > > > > Code should stand on its own merits, instead of doing something because > > something else does it. The latter is what is referred to as cargo-cult > > programming. > > > > Yes, I'm familiar with the concept but was thinking about a different paradigm > when writing this patch that is defensive programming. The question is whether > makes sense for the DRM core to defense from buggy drivers. My opinion is that > if possible it should and we should prevent kernel panics at all costs. > > Otherwise, let's say a reboot may crash and never finish unless you have a HW > watchdog or something to bring the system again into a functional state. > > But I agree that this particular patch is not nice and in fact I considered to > post it as a RFC at the beginning. Way late on this, but because it's a bit more fundamental discussions I figured maybe still useful when I chime in here ... Imo the fix for this is drmm_ and aggressively removing driver cleanup code everywhere by using drmm_ and devm_ for everything. Trying to make these functions robust against arbitrary driver bugs is a lost play imo, and the fundamental fix is making cleanup code fool proof by making it all unecessary. Ideally we'd be able to unexport all the explicit cleanup functions so that drivers just cannot get anything wrong here. We're a long way from that world though :-( -Daniel > > > Doing sanity checks on values is not a problem, but putting flag > > variables throughout the code to question other code's state is. That's > > not 'The Way of the C.' There's also the problem that a good part of > > struct drm_mode_config's initialization is open-coded in drivers. So the > > meaning of is_initialized is somewhat fuzzy. > > > > That is true. It is meant to signal that at least drm_mode_config_init() was > called by the driver. > > >> > >> I wrote this patch after fixing a bug in the drm/msm driver [0]. By looking > >> at how other drivers handled this case, I'm pretty sure that they have the > >> same problem. A warning is much better than a kernel crash during shutdown. > >> > >> [0]: > >> https://patchwork.kernel.org/project/dri-devel/patch/20220724111327.1195693-1-javi...@redhat.com/ > > > > I see. I wasn't aware that missing mode_config_init() is a problem. From > > the linked URL, I cannot really understand how it's related. msm appears > > to be calling drm_mode_config_init(), right? The idiomatic solution > > would be to convert msm to managed code. But that's an entirely > > different patchset, of course. (I only took a brief look at the link TBH.) > > > > The problem as mentioned is that drivers could call the modeset helpers even > when that init function was never called. In this case due the .bind callback > not being executed because a probe failed for a driver of a expected > sub-device > failed. > > The .shutdown callback is registered when the platform_driver is registered > and that happens at module_init(), so the shutdown would be executed > regardless > of the probe (or bind) doing a proper initialization. > > I think we need some way to signal drivers about that. Even better we could > use > it in the core helpers to not attempt to access struct drm_device data if the > DRM device was not properly initialized. > > Maybe the drm_device .registered field is enough and we could reuse that ? > > > Here's a suggestion on how to construct the mode-config code in order to > > make it hard to misuse: Driver currently open-code the initialization > > of many fields in drm_mode_config. Expand the arguments of > > drm_mode_config_init() to take the pointer to the drm_mode_config_funcs. > > These functions are essential to do anything, so it's a good candidate > > for an argument. Drivers are easily converted the the new interface > > AFAICT. After the conversion, add a test to drm_mode_config_reset() > > that tests for the funcs to be set. drm_mode_config_reset() is also > > essential during initialization or the driver will fail immediately
Re: [PATCH 2/2] drm: get lock before accessing vblank refcount
On Fri, Jul 22, 2022 at 05:52:34PM -0400, Yunxiang Li wrote:
> Acquire vbl_lock before accessing vblank refcount in drm_vblank_put,
> just like everywhere else that access the refcount.
>
> Signed-off-by: Yunxiang Li
The entire point of using atomic for the refcount is that we can check it
lockless, so I'm not sure what you're trying to fix here?
For the first patch I think it's clear that the bug needs to be fixed in
amdgpu dc code already.
-Daniel
> ---
> drivers/gpu/drm/drm_vblank.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 159d13b5d97b..77b8c40fc7ba 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -1203,15 +1203,22 @@ EXPORT_SYMBOL(drm_crtc_vblank_get);
> void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
> {
> struct drm_vblank_crtc *vblank = >vblank[pipe];
> + unsigned long irqflags;
> + int ret;
>
> if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
> return;
>
> - if (drm_WARN_ON(dev, atomic_read(>refcount) == 0))
> + spin_lock_irqsave(>vbl_lock, irqflags);
> + if (drm_WARN_ON(dev, atomic_read(>refcount) == 0)) {
> + spin_unlock_irqrestore(>vbl_lock, irqflags);
> return;
> + }
>
> /* Last user schedules interrupt disable */
> - if (atomic_dec_and_test(>refcount)) {
> + ret = atomic_dec_and_test(>refcount);
> + spin_unlock_irqrestore(>vbl_lock, irqflags);
> + if (ret) {
> if (drm_vblank_offdelay == 0)
> return;
> else if (drm_vblank_offdelay < 0)
> --
> 2.37.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On Fri, Aug 12, 2022 at 08:03:47AM +0200, Greg KH wrote: > On Thu, Aug 11, 2022 at 06:52:40PM +0200, Daniel Vetter wrote: > > On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote: > > > > > > > > > On 8/3/22 15:56, jim.cro...@gmail.com wrote: > > > > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie wrote: > > > >> > > > > > > > >> Hi Jason, Greg, DRM-folk, > > > >> > > > >> This adds 'typed' "class FOO" support to dynamic-debug, where 'typed' > > > >> means either DISJOINT (like drm debug categories), or VERBOSE (like > > > >> nouveau debug-levels). Use it in DRM modules: core, helpers, and in > > > >> drivers i915, amdgpu, nouveau. > > > >> > > > > > > > > This revision fell over, on a conflict with something in drm-MUMBLE > > > > > > > > Error: patch > > > > https://urldefense.com/v3/__https://patchwork.freedesktop.org/api/1.0/series/106427/revisions/2/mbox/__;!!GjvTz_vk!UCPl5Uf32cDVwwysMTfaLwoGLWomargFXuR8HjBA3xsUOjxXHXC5hneAkP4iWK91yc-LjjJxWW89-51Z$ > > > > > > > > not applied > > > > Applying: dyndbg: fix static_branch manipulation > > > > Applying: dyndbg: fix module.dyndbg handling > > > > Applying: dyndbg: show both old and new in change-info > > > > Applying: dyndbg: reverse module walk in cat control > > > > Applying: dyndbg: reverse module.callsite walk in cat control > > > > Applying: dyndbg: use ESCAPE_SPACE for cat control > > > > Applying: dyndbg: let query-modname override actual module name > > > > Applying: dyndbg: add test_dynamic_debug module > > > > Applying: dyndbg: drop EXPORTed dynamic_debug_exec_queries > > > > > > > > Jason, > > > > those above are decent maintenance patches, particularly the drop > > > > export. > > > > It would be nice to trim this unused api this cycle. > > > > > > Hi Jim, > > > > > > Agreed - I was thinking the same thing. Feel free to add > > > Acked-by: Jason Baron to those first 9. > > > > Does Greg KH usually pick up dyndbg patches or someone else or do I need > > to do something? Would be great to get some movement here since -rc1 goes > > out and merging will restart next week. > > Yes, I can take these into my tree after -rc1 is out. [uncovering from an absolutely impressive cascade of holes :-(] Did this happen and I can stop worrying here? I'd like to make sure these drm debug infra improvements keep moving. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 04/10] drm/simpledrm: Compute framebuffer stride if not set
On Thu, Aug 11, 2022 at 08:27:42PM +0200, Thomas Zimmermann wrote: > > > Am 11.08.22 um 20:26 schrieb Thomas Zimmermann: > > Hi Daniel > > > > Am 11.08.22 um 19:23 schrieb Daniel Vetter: > > > On Wed, 27 Jul 2022 at 09:53, Thomas Zimmermann > > > wrote: > > > > > > > > Hi > > > > > > > > Am 25.07.22 um 17:13 schrieb Javier Martinez Canillas: > > > > > Hello Geert, > > > > > > > > > > On 7/21/22 16:46, Geert Uytterhoeven wrote: > > > > > > Hi Thomas, > > > > > > > > > > > > On Wed, Jul 20, 2022 at 4:27 PM Thomas Zimmermann > > > > > > wrote: > > > > > > > Compute the framebuffer's scanline stride length if not given by > > > > > > > the simplefb data. > > > > > > > > > > > > > > Signed-off-by: Thomas Zimmermann > > > > > > > > > > > > Thanks for your patch! > > > > > > > > > > > > > --- a/drivers/gpu/drm/tiny/simpledrm.c > > > > > > > +++ b/drivers/gpu/drm/tiny/simpledrm.c > > > > > > > @@ -743,6 +743,9 @@ static struct simpledrm_device > > > > > > > *simpledrm_device_create(struct drm_driver *drv, > > > > > > > drm_err(dev, "no simplefb configuration > > > > > > > found\n"); > > > > > > > return ERR_PTR(-ENODEV); > > > > > > > } > > > > > > > + if (!stride) > > > > > > > + stride = format->cpp[0] * width; > > > > > > > > > > > > DIV_ROUND_UP(drm_format_info_bpp(format) * width, 8) > > > > > > > > > > > > > > > > I think you meant here: > > > > > > > > > > DIV_ROUND_UP(drm_format_info_bpp(format, 0) * width, 8) ? > > > > > > > > I guess, that's the right function. My original code is correct, but cpp > > > > is also deprecated. > > > > > > You all mean drm_format_info_min_pitch(). > > > > Thanks a lot. I wasn't even aware of this function, but I had almost > > written my own implementation of it. I'll update the patch accordingly. > > Arghh, too late. I merged that patch already. Reviewed-by: Daniel Vetter Preemptively, if you can do the fixup patch (and it's not yet merged)? -Daniel > > > > > Best regards > > Thomas > > > > > > > > I really don't want drivers to go grab any of the legacy format info > > > fields like bpp or depth. switch() statements on the fourcc code for > > > programming registers, or one of the real helper functions in > > > drm_fourcc.c (there might be some gaps), but not ever going through > > > legacy concepts. Anything else just leads to subtle bugs when new > > > formats get added and oops suddenly the assumptions don't hold. > > > > > > Those should be strictly limited to legacy (i.e. not drm_fourcc aware) > > > interfaces. Heck I think even fbdev emulation should completely switch > > > over to drm_fourcc/drm_format_info, but alas that's a pile of work and > > > not much payoff. > > > > > > I'm trying to volunteer Same to add a legacy_bpp tag to the above > > > helper and appropriately limit it, I think limiting to formats with > > > depth!=0 is probably the right thing. And then we should probably > > > remove a pile of the cargo-culted depth!=0 entries too. > > > -Daniel > > > > > > > > > > > Best regards > > > > Thomas > > > > > > > > > > > > > > With that change, > > > > > > > > > > Acked-by: Javier Martinez Canillas > > > > > > > > > > > > > -- > > > > Thomas Zimmermann > > > > Graphics Driver Developer > > > > SUSE Software Solutions Germany GmbH > > > > Maxfeldstr. 5, 90409 Nürnberg, Germany > > > > (HRB 36809, AG Nürnberg) > > > > Geschäftsführer: Ivo Totev > > > > > > > > > > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 5/7] drm/plane-helper: Export individual helpers
On Thu, Aug 11, 2022 at 08:32:19PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.08.22 um 18:41 schrieb Daniel Vetter:
> > On Wed, Jul 20, 2022 at 10:30:56AM +0200, Thomas Zimmermann wrote:
> > > Export the individual plane helpers that make up the plane functions and
> > > align the naming with other helpers. The plane helpers are for non-atomic
> > > modesetting and exporting them will simplify a later conversion of drivers
> > > to atomic modesetting.
> > >
> > > With struct drm_plane_funcs removed from drm_plane_helper.h, also remove
> > > the include statements. It only needs linux/types.h for uint32_t and a
> > > number of forward declarations.
> > >
> > > Signed-off-by: Thomas Zimmermann
> >
> > So my commit message was maybe not super motivated, but I intentionally
> > hid these because atomic drivers where using them, which is all bad no
> > good. Now they're more exposed again, which sucks a bit. Exporting the
> > complete function table for legacy helpers (and the one open-coded one in
> > nouveau, not sure we could not move that back to drm_crtc_init) feels much
> > safer against abuse to me.
> >
> > I'm not entirely clear why we're doing this, because the include untangle
> > could also have been achieved with a struct forward decl, which is what
> > we're usually doing. Can we walk this back please, or am I missing
> > something here?
>
> I don't think you miss anything. It's just ugly to export the complete funcs
> table. If we roll that change back, let's add a comment that states the
> rational you wrote here.
So I'm way behind on everything, but maybe another option is to just check
in these functions that it's not an atomic modeset driver (i.e.
drm_drv_uses_atomic_modeset()). Or we just hope driver authors are smarter
now and there wont be fallout.
I'm also not clear on why exporting the entire vfunc table is a bad idea?
Either way I'd say up to you.
-Daniel
>
> Best regards
> Thomas
>
> >
> > Cheers, Daniel
> >
> > > ---
> > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-
> > > drivers/gpu/drm/armada/armada_plane.c | 2 +-
> > > drivers/gpu/drm/drm_modeset_helper.c | 8 ++-
> > > drivers/gpu/drm/drm_plane_helper.c| 70 ++-
> > > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 8 ++-
> > > drivers/gpu/drm/qxl/qxl_display.c | 4 +-
> > > drivers/gpu/drm/vboxvideo/vbox_mode.c | 4 +-
> > > include/drm/drm_plane_helper.h| 22 --
> > > 8 files changed, 88 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > index 3e83fed540e8..1548f0a1b1c0 100644
> > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > @@ -86,6 +86,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
> > > @@ -7824,7 +7825,7 @@ static void dm_drm_plane_destroy_state(struct
> > > drm_plane *plane,
> > > static const struct drm_plane_funcs dm_plane_funcs = {
> > > .update_plane = drm_atomic_helper_update_plane,
> > > .disable_plane = drm_atomic_helper_disable_plane,
> > > - .destroy= drm_primary_helper_destroy,
> > > + .destroy= drm_plane_helper_destroy,
> > > .reset = dm_drm_plane_reset,
> > > .atomic_duplicate_state = dm_drm_plane_duplicate_state,
> > > .atomic_destroy_state = dm_drm_plane_destroy_state,
> > > diff --git a/drivers/gpu/drm/armada/armada_plane.c
> > > b/drivers/gpu/drm/armada/armada_plane.c
> > > index 959d7f0a5108..cc47c032dbc1 100644
> > > --- a/drivers/gpu/drm/armada/armada_plane.c
> > > +++ b/drivers/gpu/drm/armada/armada_plane.c
> > > @@ -288,7 +288,7 @@ struct drm_plane_state
> > > *armada_plane_duplicate_state(struct drm_plane *plane)
> > > static const struct drm_plane_funcs armada_primary_plane_funcs = {
> > > .update_plane = drm_atomic_helper_update_plane,
> > > .disable_plane = drm_atomic_helper_disable_plane,
> > > - .destroy= drm_primary_helper_destroy,
> > > + .destroy= drm_plane_helper_destroy,
> > > .reset = armada_plane_reset,
> > > .atomic_duplicate_state = armada_plane_duplicate_state,
> > > .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> > > diff --git a/drivers/gpu/drm/drm_modeset_helper.c
> > > b/drivers/gpu/drm/drm_modeset_helper.c
> > > index 0f08319453b2..bd609a978848 100644
> > > --- a/drivers/gpu/drm/drm_modeset_helper.c
> > > +++ b/drivers/gpu/drm/drm_modeset_helper.c
> > > @@ -108,6 +108,12 @@ static const uint32_t safe_modeset_formats[] = {
> > > DRM_FORMAT_ARGB,
> > > };
> > > +static const struct drm_plane_funcs primary_plane_funcs = {
> > > + .update_plane = drm_plane_helper_update_primary,
> > > +
Re: [PATCH v4 3/5] arm64: dts: allwinner: h6: Add GPU OPP table
Dne torek, 06. september 2022 ob 17:30:32 CEST je Clément Péron napisal(a):
> Add an Operating Performance Points table for the GPU to
> enable Dynamic Voltage & Frequency Scaling on the H6.
>
> The voltage range is set with minimal voltage set to the target
> and the maximal voltage set to 1.2V. This allow DVFS framework to
> work properly on board with fixed regulator.
>
> Signed-off-by: Clément Péron
> ---
> .../boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi | 87 +++
> 1 file changed, 87 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi new file mode 100644
> index ..b48049c4fc85
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi
> @@ -0,0 +1,87 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2022 Clément Péron
> +
> +/ {
> + gpu_opp_table: opp-table-gpu {
> + compatible = "operating-points-v2";
> +
> + opp-21600 {
> + opp-hz = /bits/ 64 <21600>;
> + opp-microvolt = <81 81 120>;
> + };
> +
> + opp-26400 {
> + opp-hz = /bits/ 64 <26400>;
> + opp-microvolt = <81 81 120>;
> + };
As mentioned in clock patch review, rates below 288 MHz are deemed unstable on
GPU PLL by vendor GPU kernel driver. At least in the BSP version that I have.
Did you test these points? If not, better to drop them.
Best regards,
Jernej
> +
> + opp-31200 {
> + opp-hz = /bits/ 64 <31200>;
> + opp-microvolt = <81 81 120>;
> + };
> +
> + opp-33600 {
> + opp-hz = /bits/ 64 <33600>;
> + opp-microvolt = <81 81 120>;
> + };
> +
> + opp-36000 {
> + opp-hz = /bits/ 64 <36000>;
> + opp-microvolt = <82 82 120>;
> + };
> +
> + opp-38400 {
> + opp-hz = /bits/ 64 <38400>;
> + opp-microvolt = <83 83 120>;
> + };
> +
> + opp-40800 {
> + opp-hz = /bits/ 64 <40800>;
> + opp-microvolt = <84 84 120>;
> + };
> +
> + opp-42000 {
> + opp-hz = /bits/ 64 <42000>;
> + opp-microvolt = <85 85 120>;
> + };
> +
> + opp-43200 {
> + opp-hz = /bits/ 64 <43200>;
> + opp-microvolt = <86 86 120>;
> + };
> +
> + opp-45600 {
> + opp-hz = /bits/ 64 <45600>;
> + opp-microvolt = <87 87 120>;
> + };
> +
> + opp-50400 {
> + opp-hz = /bits/ 64 <50400>;
> + opp-microvolt = <89 89 120>;
> + };
> +
> + opp-54000 {
> + opp-hz = /bits/ 64 <54000>;
> + opp-microvolt = <91 91 120>;
> + };
> +
> + opp-57600 {
> + opp-hz = /bits/ 64 <57600>;
> + opp-microvolt = <93 93 120>;
> + };
> +
> + opp-62400 {
> + opp-hz = /bits/ 64 <62400>;
> + opp-microvolt = <95 95 120>;
> + };
> +
> + opp-75600 {
> + opp-hz = /bits/ 64 <75600>;
> + opp-microvolt = <104 104 120>;
> + };
> + };
> +};
> +
> + {
> + operating-points-v2 = <_opp_table>;
> +};
> --
> 2.34.1
Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver
On Mon, Sep 5, 2022 at 4:54 PM Marek Szyprowski wrote: > > Hi All, > > On 02.09.2022 12:47, Marek Szyprowski wrote: > > On 29.08.2022 20:40, Jagan Teki wrote: > >> Samsung MIPI DSIM controller is common DSI IP that can be used in > >> various > >> SoCs like Exynos, i.MX8M Mini/Nano. > >> > >> In order to access this DSI controller between various platform SoCs, > >> the ideal way to incorporate this in the drm stack is via the drm bridge > >> driver. > >> > >> This patch is trying to differentiate platform-specific and bridge > >> driver > >> code and keep maintaining the exynos_drm_dsi.c code as platform-specific > >> glue code and samsung-dsim.c as a common bridge driver code. > >> > >> - Exynos specific glue code is exynos specific te_irq, host_attach, and > >>detach code along with conventional component_ops. > >> > >> - Samsung DSIM is a bridge driver which is common across all > >> platforms and > >>the respective platform-specific glue will initialize at the end > >> of the > >>probe. The platform-specific operations and other glue calls will > >> invoke > >>on associate code areas. > >> > >> v4: > >> * include Inki Dae in MAINTAINERS > >> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build > > > > This breaks Exynos DRM completely as the Exynos DRM driver is not able > > to wait until the DSI driver is probed and registered as component. > > > > I will show how to rework this the way it is done in > > drivers/gpu/drm/exynos/exynos_dp.c and > > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon... > > I've finally had some time to implement such approach, see > https://github.com/mszyprow/linux/tree/v6.0-dsi-v4-reworked > > If you want me to send the patches against your v4 patchset, let me > know, but imho my changes are much more readable after squashing to the > original patches. > > Now the driver is fully multi-arch safe and ready for further > extensions. I've removed the weak functions, reworked the way the > plat_data is used (dropped the patch related to it) and restored > exynos-dsi driver as a part of the Exynos DRM drivers/subsystem. Feel > free to resend the above as v5 after testing on your hardware. At least > it properly works now on all Exynos boards I have, both compiled into > the kernel or as modules. Thanks. I've seen the repo added on top of Dave patches - does it mean these depends on Dave changes as well? Jagan.
[PATCH 1/2] dt-bindings: display: panel: Add NewVision NV3051D panel bindings
From: Chris Morgan
Add documentation for the NewVision NV3051D panel bindings.
Note that for the two expected consumers of this panel binding
the underlying LCD model is unknown.
Signed-off-by: Chris Morgan
---
.../display/panel/newvision,nv3051d.yaml | 48 +++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml
b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml
new file mode 100644
index ..016168d8d7b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/newvision,nv3051d.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NewVision NV3051D based DSI panel driver
+
+maintainers:
+ - Chris Morgan
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - anbernic,rg353p-panel
+ - anbernic,rg353v-panel
+ reg: true
+ backlight: true
+ port: true
+ reset-gpios: true
+ vdd-supply:
+description: regulator that supplies the vdd voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "anbernic,rg353p-panel";
+reg = <0>;
+backlight = <>;
+vdd-supply = <_lcd>;
+};
+};
+
+...
--
2.25.1
[PATCH 2/2] drm/panel: Add NewVision NV3051D MIPI-DSI LCD panel
From: Chris Morgan
Support NewVision NV3051D panels as found on the Anbernic RG353P and
RG353V. The underlying panel part number for the RG353x devices is
unknown, so the device name is used instead.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-newvision-nv3051d.c | 478 ++
3 files changed, 488 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-newvision-nv3051d.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a9043eacce97..7258d28dda2f 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -296,6 +296,15 @@ config DRM_PANEL_NEC_NL8048HL11
panel (found on the Zoom2/3/3630 SDP boards). To compile this driver
as a module, choose M here.
+config DRM_PANEL_NEWVISION_NV3051D
+ tristate "NewVision NV3051D DSI panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ This driver supports the NV3051D based panel found on the Anbernic
+ RG353P and RG353V.
+
config DRM_PANEL_NEWVISION_NV3052C
tristate "NewVision NV3052C RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 34e717382dbb..cb03b3a82738 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) +=
panel-leadtek-ltk500hd1829.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
+obj-$(CONFIG_DRM_PANEL_NEWVISION_NV3051D) += panel-newvision-nv3051d.o
obj-$(CONFIG_DRM_PANEL_NEWVISION_NV3052C) += panel-newvision-nv3052c.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35560) += panel-novatek-nt35560.o
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
new file mode 100644
index ..c46edd4df765
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
@@ -0,0 +1,478 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NV3051D MIPI-DSI panel driver for Anbernic RG353x
+ * Copyright (C) 2022 Chris Morgan
+ *
+ * based on
+ *
+ * Elida kd35t133 3.5" MIPI-DSI panel driver
+ * Copyright (C) Theobroma Systems 2020
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+struct panel_nv3051d {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator *vdd;
+ bool prepared;
+};
+
+static inline struct panel_nv3051d *panel_to_panelnv3051d(struct drm_panel
*panel)
+{
+ return container_of(panel, struct panel_nv3051d, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
+ static const u8 b[] = { cmd, seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write_buffer(dsi, b, ARRAY_SIZE(b)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int panel_nv3051d_init_sequence(struct panel_nv3051d *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+
+ /*
+* Init sequence was supplied by device vendor with no
+* documentation.
+*/
+
+ dsi_dcs_write_seq(dsi, 0xFF, 0x30);
+ dsi_dcs_write_seq(dsi, 0xFF, 0x52);
+ dsi_dcs_write_seq(dsi, 0xFF, 0x01);
+ dsi_dcs_write_seq(dsi, 0xE3, 0x00);
+ dsi_dcs_write_seq(dsi, 0x03, 0x40);
+ dsi_dcs_write_seq(dsi, 0x04, 0x00);
+ dsi_dcs_write_seq(dsi, 0x05, 0x03);
+ dsi_dcs_write_seq(dsi, 0x24, 0x12);
+ dsi_dcs_write_seq(dsi, 0x25, 0x1E);
+ dsi_dcs_write_seq(dsi, 0x26, 0x28);
+ dsi_dcs_write_seq(dsi, 0x27, 0x52);
+ dsi_dcs_write_seq(dsi, 0x28, 0x57);
+ dsi_dcs_write_seq(dsi, 0x29, 0x01);
+ dsi_dcs_write_seq(dsi, 0x2A, 0xDF);
+ dsi_dcs_write_seq(dsi, 0x38, 0x9C);
+ dsi_dcs_write_seq(dsi, 0x39, 0xA7);
+ dsi_dcs_write_seq(dsi, 0x3A, 0x53);
+ dsi_dcs_write_seq(dsi, 0x44, 0x00);
+ dsi_dcs_write_seq(dsi, 0x49, 0x3C);
+ dsi_dcs_write_seq(dsi, 0x59, 0xFE);
+ dsi_dcs_write_seq(dsi, 0x5C, 0x00);
+ dsi_dcs_write_seq(dsi, 0x91, 0x77);
+ dsi_dcs_write_seq(dsi, 0x92, 0x77);
+ dsi_dcs_write_seq(dsi, 0xA0, 0x55);
+ dsi_dcs_write_seq(dsi, 0xA1, 0x50);
+ dsi_dcs_write_seq(dsi, 0xA4, 0x9C);
+ dsi_dcs_write_seq(dsi, 0xA7, 0x02);
+ dsi_dcs_write_seq(dsi, 0xA8, 0x01);
+ dsi_dcs_write_seq(dsi,
[PATCH 0/2] drm/panel: Add NewVision NV3051D Panels
From: Chris Morgan Add the NewVision NV3051D panel as found on the Anbernic RG353P and RG353V. The underlying LCD panel itself is unknown (the NV3051D is the controller), so the device name is used for the panel. Chris Morgan (2): dt-bindings: display: panel: Add NewVision NV3051D panel bindings drm/panel: Add NewVision NV3051D MIPI-DSI LCD panel .../display/panel/newvision,nv3051d.yaml | 48 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-newvision-nv3051d.c | 478 ++ 4 files changed, 536 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml create mode 100644 drivers/gpu/drm/panel/panel-newvision-nv3051d.c -- 2.25.1
Re: [PATCH] drm/amdgpu: cleanup coding style in amdgpu_amdkfd_gpuvm.c
[Public]
Yeah, seems to be a mix. I don't have a strong opinion as long as it has MIT.
Alex
From: Kuehling, Felix
Sent: Tuesday, September 6, 2022 9:46 AM
To: Jingyu Wang ; Deucher, Alexander
; Koenig, Christian ; Pan,
Xinhui ; airl...@linux.ie ;
dan...@ffwll.ch
Cc: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amdgpu: cleanup coding style in amdgpu_amdkfd_gpuvm.c
Am 2022-09-05 um 04:38 schrieb Jingyu Wang:
> Fix everything checkpatch.pl complained about in amdgpu_amdkfd_gpuvm.c
>
> Signed-off-by: Jingyu Wang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index cbd593f7d553..eff596c60c89 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: MIT
I'm not sure if this is correct. We've used "GPL-2.0 OR MIT" in KFD. In
amdgpu there is currently a mix of licenses. Alex, do you want to make a
call on a consistent one to use in amdgpu?
Other than that, this patch is
Reviewed-by: Felix Kuehling
> /*
>* Copyright 2014-2018 Advanced Micro Devices, Inc.
>*
> @@ -1612,6 +1613,7 @@ size_t amdgpu_amdkfd_get_available_memory(struct
> amdgpu_device *adev)
>uint64_t reserved_for_pt =
>ESTIMATE_PT_SIZE(amdgpu_amdkfd_total_mem_size);
>size_t available;
> +
>spin_lock(_mem_limit.mem_limit_lock);
>available = adev->gmc.real_vram_size
>- adev->kfd.vram_used_aligned
> @@ -2216,7 +2218,7 @@ int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct
> amdgpu_device *adev,
> {
>if (atomic_read(>gmc.vm_fault_info_updated) == 1) {
>*mem = *adev->gmc.vm_fault_info;
> - mb();
> + mb(); /* make sure read happened */
>atomic_set(>gmc.vm_fault_info_updated, 0);
>}
>return 0;
>
> base-commit: e47eb90a0a9ae20b82635b9b99a8d0979b757ad8
[PATCH 2/2] drm/panel: Add Samsung AMS495QA01 MIPI-DSI LCD panel
From: Chris Morgan
Support Samsung AMS495QA01 panel as found on the Anbernic RG503. Note
This panel receives video signals via DSI, however it receives
commands via 3-wire SPI.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-samsung-ams495qa01.c | 468 ++
3 files changed, 479 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-samsung-ams495qa01.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a9043eacce97..954b66a2adee 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -444,6 +444,16 @@ config DRM_PANEL_RONBO_RB070D30
Say Y here if you want to enable support for Ronbo Electronics
RB070D30 1024x600 DSI panel.
+config DRM_PANEL_SAMSUNG_AMS495QA01
+ tristate "Samsung AMS495QA01 DSI panel"
+ depends on OF && SPI
+ depends on DRM_MIPI_DSI
+ select DRM_MIPI_DBI
+ help
+ DRM panel driver for the Samsung AMS495QA01 panel. This panel
+ receives video data via DSI but commands via 3-Wire 9-bit
+ SPI.
+
config DRM_PANEL_SAMSUNG_ATNA33XC20
tristate "Samsung ATNA33XC20 eDP panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 34e717382dbb..de0b57baf851 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_AMS495QA01) += panel-samsung-ams495qa01.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20) += panel-samsung-atna33xc20.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_DB7430) += panel-samsung-db7430.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-ams495qa01.c
b/drivers/gpu/drm/panel/panel-samsung-ams495qa01.c
new file mode 100644
index ..60afea40a60e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-ams495qa01.c
@@ -0,0 +1,468 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Samsung ams495qa01 MIPI-DSI panel driver
+ * Copyright (C) 2022 Chris Morgan
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct ams495qa01 {
+ /** @dev: the container device */
+ struct device *dev;
+ /** @dbi: the DBI bus abstraction handle */
+ struct mipi_dbi dbi;
+ /** @panel: the DRM panel instance for this device */
+ struct drm_panel panel;
+ /** @reset: reset GPIO line */
+ struct gpio_desc *reset;
+ /** @enable: enable GPIO line */
+ struct gpio_desc *enable;
+ /** @regulators: VDD and ELVDD supply regulators */
+ struct regulator_bulk_data regulators[2];
+ /** @dsi_dev: DSI child device (panel) */
+ struct mipi_dsi_device *dsi_dev;
+ /** @bl_dev: pseudo-backlight device for oled panel */
+ struct backlight_device *bl_dev;
+};
+
+static const struct drm_display_mode ams495qa01_mode = {
+ .clock = 33500,
+ .hdisplay = 960,
+ .hsync_start = 960 + 10,
+ .hsync_end = 960 + 10 + 2,
+ .htotal = 960 + 10 + 2 + 10,
+ .vdisplay = 544,
+ .vsync_start = 544 + 10,
+ .vsync_end = 544 + 10 + 2,
+ .vtotal = 544 + 10 + 2 + 10,
+ .width_mm = 117,
+ .height_mm = 74,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+#define NUM_GAMMA_LEVELS 16
+#define GAMMA_TABLE_COUNT 23
+#define MAX_BRIGHTNESS (NUM_GAMMA_LEVELS - 1)
+
+/* Table of gamma values provided in datasheet */
+static u8 ams495qa01_gamma[NUM_GAMMA_LEVELS][GAMMA_TABLE_COUNT] = {
+ {0x01, 0x79, 0x78, 0x8d, 0xd9, 0xdf, 0xd5, 0xcb, 0xcf, 0xc5,
+0xe5, 0xe0, 0xe4, 0xdc, 0xb8, 0xd4, 0xfa, 0xed, 0xe6, 0x2f,
+0x00, 0x2f},
+ {0x01, 0x7d, 0x7c, 0x92, 0xd7, 0xdd, 0xd2, 0xcb, 0xd0, 0xc6,
+0xe5, 0xe1, 0xe3, 0xda, 0xbd, 0xd3, 0xfa, 0xed, 0xe6, 0x2f,
+0x00, 0x2f},
+ {0x01, 0x7f, 0x7e, 0x95, 0xd7, 0xde, 0xd2, 0xcb, 0xcf, 0xc5,
+0xe5, 0xe3, 0xe3, 0xda, 0xbf, 0xd3, 0xfa, 0xed, 0xe6, 0x2f,
+0x00, 0x2f},
+ {0x01, 0x82, 0x81, 0x99, 0xd6, 0xdd, 0xd1, 0xca, 0xcf, 0xc3,
+0xe4, 0xe3, 0xe3, 0xda, 0xc2, 0xd3, 0xfa, 0xed, 0xe6, 0x2f,
+0x00, 0x2f},
+ {0x01, 0x84, 0x83, 0x9b, 0xd7, 0xde, 0xd2, 0xc8, 0xce, 0xc2,
+0xe4, 0xe3, 0xe2, 0xd9, 0xc3, 0xd3, 0xfa, 0xed, 0xe6, 0x2f,
+0x00, 0x2f},
+ {0x01, 0x87, 0x86, 0x9f, 0xd6, 0xdd, 0xd1, 0xc7, 0xce, 0xc1,
+0xe4, 0xe3, 0xe2, 0xd9, 0xc6, 0xd3, 0xfa,
[PATCH 0/2] drm/panel: Add Samsung AMS495QA01 Panel
From: Chris Morgan Add the Samsung AMS495QA01 panel as found on the Anbernic RG503. This panel uses DSI to receive video signals, but 3-wire SPI to receive command signals. Chris Morgan (2): dt-bindings: display: panel: Add Samsung AMS495QA01 panel bindings drm/panel: Add Samsung AMS495QA01 MIPI-DSI LCD panel .../display/panel/samsung,ams495qa01.yaml | 49 ++ drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-samsung-ams495qa01.c | 468 ++ 4 files changed, 528 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml create mode 100644 drivers/gpu/drm/panel/panel-samsung-ams495qa01.c -- 2.25.1
[PATCH 1/2] dt-bindings: display: panel: Add Samsung AMS495QA01 panel bindings
From: Chris Morgan
Add documentation for the Samsung AMS495QA01 panel.
Signed-off-by: Chris Morgan
---
.../display/panel/samsung,ams495qa01.yaml | 49 +++
1 file changed, 49 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml
b/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml
new file mode 100644
index ..e7373846e7d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/samsung,ams495qa01.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung AMS495QA01 4.95in 960x544 DSI/SPI panel
+
+maintainers:
+ - Chris Morgan
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: samsung,ams495qa01
+ reg: true
+ reset-gpios: true
+ elvdd-supply:
+description: regulator that supplies voltage to the panel
+ enable-gpios: true
+ port: true
+ vdd-supply:
+description: regulator that supplies voltage to panel logic
+
+required:
+ - compatible
+ - reg
+ - elvdd-supply
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "samsung,ams495qa01";
+reg = <0>;
+backlight = <>;
+elvdd-supply = <_sys>;
+vdd-supply = <_lcd0_n>;
+};
+};
+
+...
--
2.25.1
Re: [PATCH v2 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf
On Tue, Sep 06, 2022 at 03:34:02PM +0300, Oded Gabbay wrote: > > > > > + /* > > > > > + * Since the memory being mapped is a device memory it could never > > > > > be in > > > > > + * CPU caches. > > > > > + */ > > > > DMA_ATTR_SKIP_CPU_SYNC doesn't even apply to dma_map_resource, not sure > > > > where this wisdom comes from. > > > > Habana driver > I hate to throw the ball at someone else, but I actually copied the > code from the amdgpu driver, from amdgpu_vram_mgr_alloc_sgt() iirc. > And if you remember Jason, you asked why we use this specific define > in the original review you did and I replied the following (to which > you agreed and that's why we added the comment): Yes, I remember, but Christophs remark is that DMA_ATTR_SKIP_CPU_SYNC doesn't even do anything when passed to dma_map_resource(). The only attr that seems to be used is DMA_ATTR_PRIVILEGED from what I can see. Jason
Re: [PATCH v2 0/5] rockchip-dsi for rk3568
Hello, What other patches would I need to apply to test this series on Anbernic RG503? Best Regards, Maya Matuszczyk wt., 6 wrz 2022 o 19:52 Chris Morgan napisał(a): > > From: Chris Morgan > > This series adds support for the dsi and dphy controllers on the > Rockchip RK3568. I can confirm that for the Rockchip RK3568 this > current series DOES WORK now, but it requires rolling back clk changes > made for the HDMI driver. If the clock changes are not rolled back, the > image on the screen is shifted about 100 pixels to the right. > > Clk changes in question: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/rockchip/clk-rk3568.c?id=ff3187eabb5ce478d15b6ed62eb286756adefac3 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/rockchip/clk-rk3568.c?id=6e69052f01d9131388cfcfaee929120118a267f4 > > Tested on an Anbernic RG503 and RG353P with clock changes rolled back, > the hardware works correctly on both devices. > > Changes since RFCv1: > - Identified cause of image shift (clock changes). > - Noted that driver works now. > - Added devicetree nodes for rk356x.dtsi. > > Chris Morgan (5): > dt-bindings: display: rockchip-dsi: add rk3568 compatible > dt-bindings: phy-rockchip-inno-dsidphy: add compatible for rk3568 > drm/rockchip: dsi: add rk3568 support > phy/rockchip: inno-dsidphy: Add support for rk3568 > arm64: dts: rockchip: Add DSI and DSI-DPHY nodes to rk356x > > .../display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + > .../bindings/phy/rockchip,px30-dsi-dphy.yaml | 1 + > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 72 +++ > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 51 - > .../phy/rockchip/phy-rockchip-inno-dsidphy.c | 204 ++ > 5 files changed, 281 insertions(+), 48 deletions(-) > > -- > 2.25.1 > > > ___ > Linux-rockchip mailing list > linux-rockc...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v2] drm/scheduler: quieten kernel-doc warnings
On Tue, Sep 6, 2022 at 1:38 PM Andrey Grodzovsky
wrote:
>
> I RBed, see bellow.
Can you push the patch to drm-misc?
Alex
>
> Andrey
>
> On 2022-08-31 14:34, Randy Dunlap wrote:
> > ping?
> >
> > On 4/4/22 14:58, Andrey Grodzovsky wrote:
> >> Reviewed-by: Andrey Grodzovsky
> >> Andrey
> >>
> >> On 2022-04-04 17:30, Randy Dunlap wrote:
> >>> Fix kernel-doc warnings in gpu_scheduler.h and sched_main.c.
> >>>
> >>> Quashes these warnings:
> >>>
> >>> include/drm/gpu_scheduler.h:332: warning: missing initial short
> >>> description on line:
> >>>* struct drm_sched_backend_ops
> >>> include/drm/gpu_scheduler.h:412: warning: missing initial short
> >>> description on line:
> >>>* struct drm_gpu_scheduler
> >>> include/drm/gpu_scheduler.h:461: warning: Function parameter or member
> >>> 'dev' not described in 'drm_gpu_scheduler'
> >>>
> >>> drivers/gpu/drm/scheduler/sched_main.c:201: warning: missing initial
> >>> short description on line:
> >>>* drm_sched_dependency_optimized
> >>> drivers/gpu/drm/scheduler/sched_main.c:995: warning: Function parameter
> >>> or member 'dev' not described in 'drm_sched_init'
> >>>
> >>> Fixes: 2d33948e4e00 ("drm/scheduler: add documentation")
> >>> Fixes: 8ab62eda177b ("drm/sched: Add device pointer to drm_gpu_scheduler")
> >>> Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a
> >>> processes")
> >>> Signed-off-by: Randy Dunlap
> >>> Cc: David Airlie
> >>> Cc: Daniel Vetter
> >>> Cc: Andrey Grodzovsky
> >>> Cc: Nayan Deshmukh
> >>> Cc: Alex Deucher
> >>> Cc: Christian König
> >>> Cc: Jiawei Gu
> >>> Cc: dri-devel@lists.freedesktop.org
> >>> Acked-by: Christian König
> >>> ---
> >>> Feel free to make changes or suggest changes...
> >>>
> >>> v2: drop @work description (already done by Andrey)
> >>>
> >>>drivers/gpu/drm/scheduler/sched_main.c |3 ++-
> >>>include/drm/gpu_scheduler.h|9 +
> >>>2 files changed, 7 insertions(+), 5 deletions(-)
> >>>
> >>> --- linux-next-20220404.orig/drivers/gpu/drm/scheduler/sched_main.c
> >>> +++ linux-next-20220404/drivers/gpu/drm/scheduler/sched_main.c
> >>> @@ -198,7 +198,7 @@ static void drm_sched_job_done_cb(struct
> >>>}
> >>> /**
> >>> - * drm_sched_dependency_optimized
> >>> + * drm_sched_dependency_optimized - test if the dependency can be
> >>> optimized
> >>> *
> >>> * @fence: the dependency fence
> >>> * @entity: the entity which depends on the above fence
> >>> @@ -984,6 +984,7 @@ static int drm_sched_main(void *param)
> >>> *used
> >>> * @score: optional score atomic shared with other schedulers
> >>> * @name: name used for debugging
> >>> + * @dev: target device
> >>> *
> >>> * Return 0 on success, otherwise error code.
> >>> */
> >>> --- linux-next-20220404.orig/include/drm/gpu_scheduler.h
> >>> +++ linux-next-20220404/include/drm/gpu_scheduler.h
> >>> @@ -328,10 +328,10 @@ enum drm_gpu_sched_stat {
> >>>};
> >>> /**
> >>> - * struct drm_sched_backend_ops
> >>> + * struct drm_sched_backend_ops - Define the backend operations
> >>> + *called by the scheduler
> >>> *
> >>> - * Define the backend operations called by the scheduler,
> >>> - * these functions should be implemented in driver side.
> >>> + * These functions should be implemented in the driver side.
> >>> */
> >>>struct drm_sched_backend_ops {
> >>>/**
> >>> @@ -408,7 +408,7 @@ struct drm_sched_backend_ops {
> >>>};
> >>> /**
> >>> - * struct drm_gpu_scheduler
> >>> + * struct drm_gpu_scheduler - scheduler instance-specific data
> >>> *
> >>> * @ops: backend operations provided by the driver.
> >>> * @hw_submission_limit: the max size of the hardware queue.
> >>> @@ -434,6 +434,7 @@ struct drm_sched_backend_ops {
> >>> * @_score: score used when the driver doesn't provide one
> >>> * @ready: marks if the underlying HW is ready to work
> >>> * @free_guilty: A hit to time out handler to free the guilty job.
> >>> + * @dev: system device
> >>> *
> >>> * One scheduler is implemented for each hardware ring.
> >>> */
Re: [PATCH v2 1/4] dma-buf: Add dma_buf_try_get()
Am 06.09.22 um 18:44 schrieb Jason Gunthorpe: On Thu, Sep 01, 2022 at 09:55:08AM +0200, Christian König wrote: Am 01.09.22 um 01:12 schrieb Jason Gunthorpe: Used to increment the refcount of the dma buf's struct file, only if the refcount is not zero. Useful to allow the struct file's lifetime to control the lifetime of the dmabuf while still letting the driver to keep track of created dmabufs. Signed-off-by: Jason Gunthorpe --- include/linux/dma-buf.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 71731796c8c3a8..a35f1554f2fb36 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -618,6 +618,19 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags); struct dma_buf *dma_buf_get(int fd); void dma_buf_put(struct dma_buf *dmabuf); +/** + * dma_buf_try_get - try to get a reference on a dmabuf + * @dmabuf - the dmabuf to get + * + * Returns true if a reference was successfully obtained. The caller must + * interlock with the dmabuf's release function in some way, such as RCU, to + * ensure that this is not called on freed memory. I still have a bad feeling about this, but I also see that we can only choose between evils here. Could you just call get_file_rcu() from the exporter with a comment explaining why this works instead? I guess, are you sure? It seems very hacky. Yes, it's still better than exposing a dma_buf_try_get() interface to everyone. Keep in mind that those functions here are mostly supposed to be used by the importer and not the exporter. Christian. Jason
Re: [PATCH 0/8] Support for NVDEC on Tegra234
On 06/09/2022 15:28, Mikko Perttunen wrote: > From: Mikko Perttunen > > Hi all, > > this series adds support for the HW video decoder, NVDEC, > on Tegra234 (Orin). The main change is a switch from Falcon > to RISC-V for the internal microcontroller, which brings along > a change in how the engine is booted. Otherwise it is backwards > compatible with earlier versions. You need to describe the dependencies, otherwise I would be free to go with applying memory controllers part. Best regards, Krzysztof
[PATCH v2 4/5] phy/rockchip: inno-dsidphy: Add support for rk3568
From: Chris Morgan
Add support for the Rockchip RK3568 DSI-DPHY. Registers were taken from
the BSP kernel driver and wherever possible cross referenced with the
TRM.
Signed-off-by: Chris Morgan
---
.../phy/rockchip/phy-rockchip-inno-dsidphy.c | 204 ++
1 file changed, 158 insertions(+), 46 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c
b/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c
index 630e01b5c19b..2c5847faff63 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c
@@ -84,9 +84,25 @@
#define DATA_LANE_0_SKEW_PHASE_MASKGENMASK(2, 0)
#define DATA_LANE_0_SKEW_PHASE(x) UPDATE(x, 2, 0)
/* Analog Register Part: reg08 */
+#define PLL_POST_DIV_ENABLE_MASK BIT(5)
+#define PLL_POST_DIV_ENABLEBIT(5)
#define SAMPLE_CLOCK_DIRECTION_MASKBIT(4)
#define SAMPLE_CLOCK_DIRECTION_REVERSE BIT(4)
#define SAMPLE_CLOCK_DIRECTION_FORWARD 0
+#define LOWFRE_EN_MASK BIT(5)
+#define PLL_OUTPUT_FREQUENCY_DIV_BY_1 0
+#define PLL_OUTPUT_FREQUENCY_DIV_BY_2 1
+/* Analog Register Part: reg0b */
+#define CLOCK_LANE_VOD_RANGE_SET_MASK GENMASK(3, 0)
+#define CLOCK_LANE_VOD_RANGE_SET(x)UPDATE(x, 3, 0)
+#define VOD_MIN_RANGE 0x1
+#define VOD_MID_RANGE 0x3
+#define VOD_BIG_RANGE 0x7
+#define VOD_MAX_RANGE 0xf
+/* Analog Register Part: reg1E */
+#define PLL_MODE_SEL_MASK GENMASK(6, 5)
+#define PLL_MODE_SEL_LVDS_MODE 0
+#define PLL_MODE_SEL_MIPI_MODE BIT(5)
/* Digital Register Part: reg00 */
#define REG_DIG_RSTN_MASK BIT(0)
#define REG_DIG_RSTN_NORMALBIT(0)
@@ -102,20 +118,22 @@
#define T_LPX_CNT_MASK GENMASK(5, 0)
#define T_LPX_CNT(x) UPDATE(x, 5, 0)
/* Clock/Data0/Data1/Data2/Data3 Lane Register Part: reg06 */
+#define T_HS_ZERO_CNT_HI_MASK BIT(7)
+#define T_HS_ZERO_CNT_HI(x)UPDATE(x, 7, 7)
#define T_HS_PREPARE_CNT_MASK GENMASK(6, 0)
#define T_HS_PREPARE_CNT(x)UPDATE(x, 6, 0)
/* Clock/Data0/Data1/Data2/Data3 Lane Register Part: reg07 */
-#define T_HS_ZERO_CNT_MASK GENMASK(5, 0)
-#define T_HS_ZERO_CNT(x) UPDATE(x, 5, 0)
+#define T_HS_ZERO_CNT_LO_MASK GENMASK(5, 0)
+#define T_HS_ZERO_CNT_LO(x)UPDATE(x, 5, 0)
/* Clock/Data0/Data1/Data2/Data3 Lane Register Part: reg08 */
#define T_HS_TRAIL_CNT_MASKGENMASK(6, 0)
#define T_HS_TRAIL_CNT(x) UPDATE(x, 6, 0)
/* Clock/Data0/Data1/Data2/Data3 Lane Register Part: reg09 */
-#define T_HS_EXIT_CNT_MASK GENMASK(4, 0)
-#define T_HS_EXIT_CNT(x) UPDATE(x, 4, 0)
+#define T_HS_EXIT_CNT_LO_MASK GENMASK(4, 0)
+#define T_HS_EXIT_CNT_LO(x)UPDATE(x, 4, 0)
/* Clock/Data0/Data1/Data2/Data3 Lane Register Part: reg0a */
-#define T_CLK_POST_CNT_MASKGENMASK(3, 0)
-#define T_CLK_POST_CNT(x) UPDATE(x, 3, 0)
+#define T_CLK_POST_CNT_LO_MASK GENMASK(3, 0)
+#define T_CLK_POST_CNT_LO(x) UPDATE(x, 3, 0)
/* Clock/Data0/Data1/Data2/Data3 Lane Register Part: reg0c */
#define LPDT_TX_PPI_SYNC_MASK BIT(2)
#define LPDT_TX_PPI_SYNC_ENABLEBIT(2)
@@ -129,9 +147,13 @@
#define T_CLK_PRE_CNT_MASK GENMASK(3, 0)
#define T_CLK_PRE_CNT(x) UPDATE(x, 3, 0)
/* Clock/Data0/Data1/Data2/Data3 Lane Register Part: reg10 */
+#define T_CLK_POST_CNT_HI_MASK GENMASK(7, 6)
+#define T_CLK_POST_CNT_HI(x) UPDATE(x, 7, 6)
#define T_TA_GO_CNT_MASK GENMASK(5, 0)
#define T_TA_GO_CNT(x) UPDATE(x, 5, 0)
/* Clock/Data0/Data1/Data2/Data3 Lane Register Part: reg11 */
+#define T_HS_EXIT_CNT_HI_MASK BIT(6)
+#define T_HS_EXIT_CNT_HI(x)UPDATE(x, 6, 6)
#define T_TA_SURE_CNT_MASK GENMASK(5, 0)
#define T_TA_SURE_CNT(x) UPDATE(x, 5, 0)
/* Clock/Data0/Data1/Data2/Data3 Lane Register Part: reg12 */
@@ -169,11 +191,23 @@
#define DSI_PHY_STATUS 0xb0
#define PHY_LOCK BIT(0)
+enum phy_max_rate {
+ MAX_1GHZ,
+ MAX_2_5GHZ,
+};
+
+struct inno_video_phy_plat_data {
+ const struct inno_mipi_dphy_timing *inno_mipi_dphy_timing_table;
+ const unsigned int num_timings;
+ enum phy_max_rate max_rate;
+};
+
struct inno_dsidphy {
struct device *dev;
struct clk *ref_clk;
struct clk *pclk_phy;
struct
[PATCH v2 5/5] arm64: dts: rockchip: Add DSI and DSI-DPHY nodes to rk356x
From: Chris Morgan
This adds the DSI controller nodes and DSI-DPHY controller nodes to the
rk356x device tree.
Signed-off-by: Chris Morgan
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 72
1 file changed, 72 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index 319981c3e9f7..d150568fde82 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -699,6 +699,54 @@ vop_mmu: iommu@fe043e00 {
status = "disabled";
};
+ dsi0: dsi@fe06 {
+ compatible = "rockchip,rk3568-mipi-dsi", "snps,dw-mipi-dsi";
+ reg = <0x00 0xfe06 0x00 0x1>;
+ interrupts = ;
+ clock-names = "pclk", "hclk";
+ clocks = < PCLK_DSITX_0>, < HCLK_VO>;
+ phy-names = "dphy";
+ phys = <_dphy0>;
+ power-domains = < RK3568_PD_VO>;
+ reset-names = "apb";
+ resets = < SRST_P_DSITX_0>;
+ rockchip,grf = <>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+ };
+ };
+
+ dsi1: dsi@fe07 {
+ compatible = "rockchip,rk3568-mipi-dsi", "snps,dw-mipi-dsi";
+ reg = <0x0 0xfe07 0x0 0x1>;
+ interrupts = ;
+ clock-names = "pclk", "hclk";
+ clocks = < PCLK_DSITX_1>, < HCLK_VO>;
+ phy-names = "dphy";
+ phys = <_dphy1>;
+ power-domains = < RK3568_PD_VO>;
+ reset-names = "apb";
+ resets = < SRST_P_DSITX_1>;
+ rockchip,grf = <>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+ };
+ };
+
hdmi: hdmi@fe0a {
compatible = "rockchip,rk3568-dw-hdmi";
reg = <0x0 0xfe0a 0x0 0x2>;
@@ -1594,6 +1642,30 @@ combphy2: phy@fe84 {
status = "disabled";
};
+ mipi_dphy0: mipi-dphy@fe85 {
+ compatible = "rockchip,rk3568-dsi-dphy";
+ reg = <0x0 0xfe85 0x0 0x1>;
+ clock-names = "ref", "pclk";
+ clocks = < CLK_MIPIDSIPHY0_REF>, < PCLK_MIPIDSIPHY0>;
+ #phy-cells = <0>;
+ power-domains = < RK3568_PD_VO>;
+ reset-names = "apb";
+ resets = < SRST_P_MIPIDSIPHY0>;
+ status = "disabled";
+ };
+
+ mipi_dphy1: mipi-dphy@fe86 {
+ compatible = "rockchip,rk3568-dsi-dphy";
+ reg = <0x0 0xfe86 0x0 0x1>;
+ clock-names = "ref", "pclk";
+ clocks = < CLK_MIPIDSIPHY1_REF>, < PCLK_MIPIDSIPHY1>;
+ #phy-cells = <0>;
+ power-domains = < RK3568_PD_VO>;
+ reset-names = "apb";
+ resets = < SRST_P_MIPIDSIPHY1>;
+ status = "disabled";
+ };
+
usb2phy0: usb2phy@fe8a {
compatible = "rockchip,rk3568-usb2phy";
reg = <0x0 0xfe8a 0x0 0x1>;
--
2.25.1
[PATCH v2 3/5] drm/rockchip: dsi: add rk3568 support
From: Chris Morgan
Add the compatible and GRF definitions for the RK3568 soc.
Signed-off-by: Chris Morgan
---
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 51 ++-
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 110e83aad9bb..bf6948125b84 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -179,6 +179,23 @@
#define RK3399_TXRX_SRC_SEL_ISP0 BIT(4)
#define RK3399_TXRX_TURNREQUESTGENMASK(3, 0)
+#define RK3568_GRF_VO_CON2 0x0368
+#define RK3568_DSI0_SKEWCALHS (0x1f << 11)
+#define RK3568_DSI0_FORCETXSTOPMODE(0xf << 4)
+#define RK3568_DSI0_TURNDISABLEBIT(2)
+#define RK3568_DSI0_FORCERXMODEBIT(0)
+
+/*
+ * Note these registers do not appear in the datasheet, they are
+ * however present in the BSP driver which is where these values
+ * come from. Name GRF_VO_CON3 is assumed.
+ */
+#define RK3568_GRF_VO_CON3 0x36c
+#define RK3568_DSI1_SKEWCALHS (0x1f << 11)
+#define RK3568_DSI1_FORCETXSTOPMODE(0xf << 4)
+#define RK3568_DSI1_TURNDISABLEBIT(2)
+#define RK3568_DSI1_FORCERXMODEBIT(0)
+
#define HIWORD_UPDATE(val, mask) (val | (mask) << 16)
enum {
@@ -735,8 +752,9 @@ static void dw_mipi_dsi_rockchip_config(struct
dw_mipi_dsi_rockchip *dsi)
static void dw_mipi_dsi_rockchip_set_lcdsel(struct dw_mipi_dsi_rockchip *dsi,
int mux)
{
- regmap_write(dsi->grf_regmap, dsi->cdata->lcdsel_grf_reg,
- mux ? dsi->cdata->lcdsel_lit : dsi->cdata->lcdsel_big);
+ if (dsi->cdata->lcdsel_grf_reg < 0)
+ regmap_write(dsi->grf_regmap, dsi->cdata->lcdsel_grf_reg,
+ mux ? dsi->cdata->lcdsel_lit : dsi->cdata->lcdsel_big);
}
static int
@@ -963,6 +981,8 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
goto out_pll_clk;
}
+ rockchip_drm_encoder_set_crtc_endpoint_id(>encoder,
+ dev->of_node, 0, 0);
ret = dw_mipi_dsi_bind(dsi->dmd, >encoder.encoder);
if (ret) {
@@ -1612,6 +1632,30 @@ static const struct rockchip_dw_dsi_chip_data
rk3399_chip_data[] = {
{ /* sentinel */ }
};
+static const struct rockchip_dw_dsi_chip_data rk3568_chip_data[] = {
+ {
+ .reg = 0xfe06,
+ .lcdsel_grf_reg = -1,
+ .lanecfg1_grf_reg = RK3568_GRF_VO_CON2,
+ .lanecfg1 = HIWORD_UPDATE(0, RK3568_DSI0_SKEWCALHS |
+ RK3568_DSI0_FORCETXSTOPMODE |
+ RK3568_DSI0_TURNDISABLE |
+ RK3568_DSI0_FORCERXMODE),
+ .max_data_lanes = 4,
+ },
+ {
+ .reg = 0xfe07,
+ .lcdsel_grf_reg = -1,
+ .lanecfg1_grf_reg = RK3568_GRF_VO_CON3,
+ .lanecfg1 = HIWORD_UPDATE(0, RK3568_DSI1_SKEWCALHS |
+ RK3568_DSI1_FORCETXSTOPMODE |
+ RK3568_DSI1_TURNDISABLE |
+ RK3568_DSI1_FORCERXMODE),
+ .max_data_lanes = 4,
+ },
+ { /* sentinel */ }
+};
+
static const struct of_device_id dw_mipi_dsi_rockchip_dt_ids[] = {
{
.compatible = "rockchip,px30-mipi-dsi",
@@ -1622,6 +1666,9 @@ static const struct of_device_id
dw_mipi_dsi_rockchip_dt_ids[] = {
}, {
.compatible = "rockchip,rk3399-mipi-dsi",
.data = _chip_data,
+ }, {
+.compatible = "rockchip,rk3568-mipi-dsi",
+.data = _chip_data,
},
{ /* sentinel */ }
};
--
2.25.1
[PATCH v2 2/5] dt-bindings: phy-rockchip-inno-dsidphy: add compatible for rk3568
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(+) diff --git a/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml index 8a3032a3bd73..5c35e5ceec0b 100644 --- a/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml +++ b/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml @@ -18,6 +18,7 @@ properties: - rockchip,px30-dsi-dphy - rockchip,rk3128-dsi-dphy - rockchip,rk3368-dsi-dphy + - rockchip,rk3568-dsi-dphy reg: maxItems: 1 -- 2.25.1
[PATCH v2 1/5] dt-bindings: display: rockchip-dsi: add rk3568 compatible
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(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 39792f051d2d..9a223df8530c 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -8,6 +8,7 @@ Required properties: "rockchip,px30-mipi-dsi", "snps,dw-mipi-dsi" "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi" "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi" + "rockchip,rk3568-mipi-dsi", "snps,dw-mipi-dsi" - reg: Represent the physical address range of the controller. - interrupts: Represent the controller's interrupt to the CPU(s). - clocks, clock-names: Phandles to the controller's pll reference -- 2.25.1
[PATCH v2 0/5] rockchip-dsi for rk3568
From: Chris Morgan This series adds support for the dsi and dphy controllers on the Rockchip RK3568. I can confirm that for the Rockchip RK3568 this current series DOES WORK now, but it requires rolling back clk changes made for the HDMI driver. If the clock changes are not rolled back, the image on the screen is shifted about 100 pixels to the right. Clk changes in question: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/rockchip/clk-rk3568.c?id=ff3187eabb5ce478d15b6ed62eb286756adefac3 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/rockchip/clk-rk3568.c?id=6e69052f01d9131388cfcfaee929120118a267f4 Tested on an Anbernic RG503 and RG353P with clock changes rolled back, the hardware works correctly on both devices. Changes since RFCv1: - Identified cause of image shift (clock changes). - Noted that driver works now. - Added devicetree nodes for rk356x.dtsi. Chris Morgan (5): dt-bindings: display: rockchip-dsi: add rk3568 compatible dt-bindings: phy-rockchip-inno-dsidphy: add compatible for rk3568 drm/rockchip: dsi: add rk3568 support phy/rockchip: inno-dsidphy: Add support for rk3568 arm64: dts: rockchip: Add DSI and DSI-DPHY nodes to rk356x .../display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + .../bindings/phy/rockchip,px30-dsi-dphy.yaml | 1 + arch/arm64/boot/dts/rockchip/rk356x.dtsi | 72 +++ .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 51 - .../phy/rockchip/phy-rockchip-inno-dsidphy.c | 204 ++ 5 files changed, 281 insertions(+), 48 deletions(-) -- 2.25.1
Re: [PATCH v2] drm/scheduler: quieten kernel-doc warnings
I RBed, see bellow.
Andrey
On 2022-08-31 14:34, Randy Dunlap wrote:
ping?
On 4/4/22 14:58, Andrey Grodzovsky wrote:
Reviewed-by: Andrey Grodzovsky
Andrey
On 2022-04-04 17:30, Randy Dunlap wrote:
Fix kernel-doc warnings in gpu_scheduler.h and sched_main.c.
Quashes these warnings:
include/drm/gpu_scheduler.h:332: warning: missing initial short description on
line:
* struct drm_sched_backend_ops
include/drm/gpu_scheduler.h:412: warning: missing initial short description on
line:
* struct drm_gpu_scheduler
include/drm/gpu_scheduler.h:461: warning: Function parameter or member 'dev'
not described in 'drm_gpu_scheduler'
drivers/gpu/drm/scheduler/sched_main.c:201: warning: missing initial short
description on line:
* drm_sched_dependency_optimized
drivers/gpu/drm/scheduler/sched_main.c:995: warning: Function parameter or
member 'dev' not described in 'drm_sched_init'
Fixes: 2d33948e4e00 ("drm/scheduler: add documentation")
Fixes: 8ab62eda177b ("drm/sched: Add device pointer to drm_gpu_scheduler")
Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes")
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: Andrey Grodzovsky
Cc: Nayan Deshmukh
Cc: Alex Deucher
Cc: Christian König
Cc: Jiawei Gu
Cc: dri-devel@lists.freedesktop.org
Acked-by: Christian König
---
Feel free to make changes or suggest changes...
v2: drop @work description (already done by Andrey)
drivers/gpu/drm/scheduler/sched_main.c | 3 ++-
include/drm/gpu_scheduler.h | 9 +
2 files changed, 7 insertions(+), 5 deletions(-)
--- linux-next-20220404.orig/drivers/gpu/drm/scheduler/sched_main.c
+++ linux-next-20220404/drivers/gpu/drm/scheduler/sched_main.c
@@ -198,7 +198,7 @@ static void drm_sched_job_done_cb(struct
}
/**
- * drm_sched_dependency_optimized
+ * drm_sched_dependency_optimized - test if the dependency can be optimized
*
* @fence: the dependency fence
* @entity: the entity which depends on the above fence
@@ -984,6 +984,7 @@ static int drm_sched_main(void *param)
* used
* @score: optional score atomic shared with other schedulers
* @name: name used for debugging
+ * @dev: target device
*
* Return 0 on success, otherwise error code.
*/
--- linux-next-20220404.orig/include/drm/gpu_scheduler.h
+++ linux-next-20220404/include/drm/gpu_scheduler.h
@@ -328,10 +328,10 @@ enum drm_gpu_sched_stat {
};
/**
- * struct drm_sched_backend_ops
+ * struct drm_sched_backend_ops - Define the backend operations
+ * called by the scheduler
*
- * Define the backend operations called by the scheduler,
- * these functions should be implemented in driver side.
+ * These functions should be implemented in the driver side.
*/
struct drm_sched_backend_ops {
/**
@@ -408,7 +408,7 @@ struct drm_sched_backend_ops {
};
/**
- * struct drm_gpu_scheduler
+ * struct drm_gpu_scheduler - scheduler instance-specific data
*
* @ops: backend operations provided by the driver.
* @hw_submission_limit: the max size of the hardware queue.
@@ -434,6 +434,7 @@ struct drm_sched_backend_ops {
* @_score: score used when the driver doesn't provide one
* @ready: marks if the underlying HW is ready to work
* @free_guilty: A hit to time out handler to free the guilty job.
+ * @dev: system device
*
* One scheduler is implemented for each hardware ring.
*/
Re: [PATCH 1/4] drm: Add missing DP DSC extended capability definitions.
On Tue, 06 Sep 2022, "Lisovskiy, Stanislav" wrote: > On Tue, Sep 06, 2022 at 06:43:22PM +0300, Jani Nikula wrote: >> On Tue, 06 Sep 2022, Jani Nikula wrote: >> > On Mon, 05 Sep 2022, Stanislav Lisovskiy >> > wrote: >> >> Adding DP DSC register definitions, we might need for further >> >> DSC implementation, supporting MST and DP branch pass-through mode. >> >> >> >> v2: - Fixed checkpatch comment warning >> >> v3: - Removed function which is not yet used(Jani Nikula) >> >> >> >> Reviewed-by: Vinod Govindapillai >> >> >> >> Signed-off-by: Stanislav Lisovskiy >> > >> > Maarten, Maxime, Thomas - >> > >> > So this got pushed to drm-intel-next without your acks. Apologies. Can >> > we live with it, or want a revert? >> >> I've reverted anyway for other reasons. But can we have an ack for the >> future? :) >> >> BR, >> Jani. > > I've resolved the conflict properly now(not the best way of learning about > drm-rerere) but I guess its too late now. Sorry for the hassle. Yeah, I'm sorry too. The conflict looked too involved for us to figure out right now, with the diverged baselines between drm-misc-next and drm-intel-next, so Rodrigo and I decided to go for the revert. We needed to get drm-tip building again. And really, the patches as applied on top of current drm-intel-next weren't tested, because they were changed on the fly. > But what am I supposed to do now? Should proceed with merge again or > wait for some acks? > Patches basically would be the same anyway. The patches will be the same, but we'll need to get the baseline resolved first. drm-misc-next and drm-intel-next have diverged on intel_dp_mst.c, due to Lyude's DP MST changes, and we'll need to get them in sync in drm-intel-next before applying the patches. It'll be the easiest for everyone. In practice this means a drm-misc-next pull request to drm-next, and then a backmerge from drm-next to drm-intel-next. There was a drm-misc-next pull request merged today, but only up to tag drm-misc-next-2022-08-20-1, and there's 88 commits in drm-misc-next since. Including Lyude's changes. BR, Jani. > > Stan > >> >> > >> > >> > BR, >> > Jani. >> > >> > >> >> --- >> >> include/drm/display/drm_dp.h | 10 +- >> >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h >> >> index 6c0871164771..02c4b6f20478 100644 >> >> --- a/include/drm/display/drm_dp.h >> >> +++ b/include/drm/display/drm_dp.h >> >> @@ -239,6 +239,9 @@ >> >> >> >> #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ >> >> # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) >> >> +# define DP_DSC_PASS_THROUGH_IS_SUPPORTED (1 << 1) >> >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP(1 << 2) >> >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP (1 << 3) >> >> >> >> #define DP_DSC_REV 0x061 >> >> # define DP_DSC_MAJOR_MASK (0xf << 0) >> >> @@ -277,12 +280,15 @@ >> >> >> >> #define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 >> >> # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) >> >> +# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1) >> >> >> >> #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ >> >> >> >> #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ >> >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) >> >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 >> >> +# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK 0x06 >> >> +# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY 0x08 >> >> >> >> #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 >> >> # define DP_DSC_RGB (1 << 0) >> >> @@ -344,11 +350,13 @@ >> >> # define DP_DSC_24_PER_DP_DSC_SINK (1 << 2) >> >> >> >> #define DP_DSC_BITS_PER_PIXEL_INC 0x06F >> >> +# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f >> >> +# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0 >> >> # define DP_DSC_BITS_PER_PIXEL_1_16 0x0 >> >> # define DP_DSC_BITS_PER_PIXEL_1_8 0x1 >> >> # define DP_DSC_BITS_PER_PIXEL_1_4 0x2 >> >> # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 >> >> -# define DP_DSC_BITS_PER_PIXEL_10x4 >> >> +# define DP_DSC_BITS_PER_PIXEL_1_1 0x4 >> >> >> >> #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ >> >> # define DP_PSR_IS_SUPPORTED1 >> >> -- >> Jani Nikula, Intel Open Source Graphics Center -- Jani Nikula, Intel Open Source Graphics Center
