Re: [PATCH 0/5] arm64: dts: qcom: qrb5165-rb5: enable DP support
On Tue, Jul 18, 2023 at 09:09:41AM +0300, Dmitry Baryshkov wrote: > On 18/07/2023 07:37, Bjorn Andersson wrote: > > On Sun, Jul 09, 2023 at 07:19:21AM +0300, Dmitry Baryshkov wrote: > > > Implement DisplayPort support for the Qualcomm RB5 platform. > > > > > > Note: while testing this, I had link training issues with several > > > dongles with DP connectors. Other DisplayPort-USB-C dongles (with HDMI > > > or VGA connectors) work perfectly. > > > > > > Dependencies: [1] > > > Soft-dependencies: [2], [3] > > > > > > [1] > > > https://lore.kernel.org/linux-arm-msm/20230515133643.3621656-1-bryan.odonog...@linaro.org/ > > > > I'm not able to find a version of this series ready to be merged, can > > you please help me find it? > > This = Bryan's? I have posted some (small) feedback regarding v8. You also > had issues with orientation switching bindings, etc. So there should be v9. > Right, Bryan's series. You linked to v8 which has requests for changes, and I can't find v9. Am I just bad at searching? Regards, Bjorn
Re: [PATCH v6 1/4] video: Add auxiliary display drivers to Graphics support menu
On Sat, Jul 22, 2023 at 2:50 AM Javier Martinez Canillas wrote: > > Got it. Then that's yet another argument for adding the auxdisplay > drivers under the same "Graphics support" menu. Just in case it matters for Helge/you: these may also register an input device, e.g. the ht16k33 has a matrix keypad. Cheers, Miguel
Re: [PATCH v6 1/4] video: Add auxiliary display drivers to Graphics support menu
Miguel Ojeda writes: > On Sat, Jul 22, 2023 at 2:13 AM Javier Martinez Canillas > wrote: >> >> Oh, interesting. I wonder why that couldn't had been a fbdev driver then >> using FB_VISUAL_MONO01? I'll reword then the commit message before apply >> to the following instead: > > It is :) > > .type = FB_TYPE_PACKED_PIXELS, > .visual = FB_VISUAL_MONO10, > Ah! Should had read the driver before commenting then :) > The original distinction was more about having a place where to put > small, simple displays that were not your usual "screen", where you > would typically draw a custom UI, probably controlled with a few > custom buttons, etc. > Got it. Then that's yet another argument for adding the auxdisplay drivers under the same "Graphics support" menu. >> Perfect, thanks! > > My pleasure! > > Cheers, > Miguel > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH v6 1/4] video: Add auxiliary display drivers to Graphics support menu
On Sat, Jul 22, 2023 at 2:13 AM Javier Martinez Canillas wrote: > > Oh, interesting. I wonder why that couldn't had been a fbdev driver then > using FB_VISUAL_MONO01? I'll reword then the commit message before apply > to the following instead: It is :) .type = FB_TYPE_PACKED_PIXELS, .visual = FB_VISUAL_MONO10, The original distinction was more about having a place where to put small, simple displays that were not your usual "screen", where you would typically draw a custom UI, probably controlled with a few custom buttons, etc. > Perfect, thanks! My pleasure! Cheers, Miguel
Re: [PATCH v6 1/4] video: Add auxiliary display drivers to Graphics support menu
Miguel Ojeda writes: Hello Miguel, > On Sat, Jul 22, 2023 at 12:46 AM Javier Martinez Canillas > wrote: >> >> Javier Martinez Canillas writes: >> >> [adding Miguel Ojeda who was not in the Cc list] >> >> Hello Miguel, could you please ack this patch so that I can take the whole >> patch-set through the drm-misc tree? > > A note below... > >> > The drivers in this subsystem are for character-based LCD displays, which >> > can fall into the same category of the DRM/KMS and fbdev drivers that are >> > located under the "Graphics support" menu. Add auxdisplay there as well. > > Nit: this is not exactly true, e.g. ks0108/cfag12864b (which were the > first in the subsystem) were not character-based but a very simple > black-or-white 128x64 grid, so we should probably reword slightly > this. > Oh, interesting. I wonder why that couldn't had been a fbdev driver then using FB_VISUAL_MONO01? I'll reword then the commit message before apply to the following instead: "The drivers in this subsystem are for either character-based or monochrome LCD controllers, which can fall into the same category of the DRM/KMS and fbdev drivers, that are located under the "Graphics support" menu. Add the auxdisplay drivers there as well to have all display drivers under the same menu." > In any case, if Helge thinks these may belong in the "Graphics > support" menu, then I am fine with it: > > Acked-by: Miguel Ojeda > Perfect, thanks! > Thanks! > > Cheers, > Miguel > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH v6 1/4] video: Add auxiliary display drivers to Graphics support menu
On Sat, Jul 22, 2023 at 12:46 AM Javier Martinez Canillas wrote: > > Javier Martinez Canillas writes: > > [adding Miguel Ojeda who was not in the Cc list] > > Hello Miguel, could you please ack this patch so that I can take the whole > patch-set through the drm-misc tree? A note below... > > The drivers in this subsystem are for character-based LCD displays, which > > can fall into the same category of the DRM/KMS and fbdev drivers that are > > located under the "Graphics support" menu. Add auxdisplay there as well. Nit: this is not exactly true, e.g. ks0108/cfag12864b (which were the first in the subsystem) were not character-based but a very simple black-or-white 128x64 grid, so we should probably reword slightly this. In any case, if Helge thinks these may belong in the "Graphics support" menu, then I am fine with it: Acked-by: Miguel Ojeda Thanks! Cheers, Miguel
Re: [PATCH drm-misc-next v8 03/12] drm/nouveau: new VM_BIND uapi interfaces
On Wed, Jul 19, 2023 at 7:15 PM Danilo Krummrich wrote:
> This commit provides the interfaces for the new UAPI motivated by the
> Vulkan API. It allows user mode drivers (UMDs) to:
>
> 1) Initialize a GPU virtual address (VA) space via the new
>DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved
>VA area.
>
> 2) Bind and unbind GPU VA space mappings via the new
>DRM_IOCTL_NOUVEAU_VM_BIND ioctl.
>
> 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl.
>
> Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support
> asynchronous processing with DRM syncobjs as synchronization mechanism.
>
> The default DRM_IOCTL_NOUVEAU_VM_BIND is synchronous processing,
> DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only.
>
> Co-authored-by: Dave Airlie
> Signed-off-by: Danilo Krummrich
> ---
> Documentation/gpu/driver-uapi.rst | 8 ++
> include/uapi/drm/nouveau_drm.h| 209 ++
> 2 files changed, 217 insertions(+)
>
> diff --git a/Documentation/gpu/driver-uapi.rst
> b/Documentation/gpu/driver-uapi.rst
> index 4411e6919a3d..9c7ca6e33a68 100644
> --- a/Documentation/gpu/driver-uapi.rst
> +++ b/Documentation/gpu/driver-uapi.rst
> @@ -6,3 +6,11 @@ drm/i915 uAPI
> =
>
> .. kernel-doc:: include/uapi/drm/i915_drm.h
> +
> +drm/nouveau uAPI
> +
> +
> +VM_BIND / EXEC uAPI
> +---
> +
> +.. kernel-doc:: include/uapi/drm/nouveau_drm.h
> diff --git a/include/uapi/drm/nouveau_drm.h
> b/include/uapi/drm/nouveau_drm.h
> index 853a327433d3..4d3a70529637 100644
> --- a/include/uapi/drm/nouveau_drm.h
> +++ b/include/uapi/drm/nouveau_drm.h
> @@ -126,6 +126,209 @@ struct drm_nouveau_gem_cpu_fini {
> __u32 handle;
> };
>
> +/**
> + * struct drm_nouveau_sync - sync object
> + *
> + * This structure serves as synchronization mechanism for (potentially)
> + * asynchronous operations such as EXEC or VM_BIND.
> + */
> +struct drm_nouveau_sync {
> + /**
> +* @flags: the flags for a sync object
> +*
> +* The first 8 bits are used to determine the type of the sync
> object.
> +*/
> + __u32 flags;
> +#define DRM_NOUVEAU_SYNC_SYNCOBJ 0x0
> +#define DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ 0x1
> +#define DRM_NOUVEAU_SYNC_TYPE_MASK 0xf
> + /**
> +* @handle: the handle of the sync object
> +*/
> + __u32 handle;
> + /**
> +* @timeline_value:
> +*
> +* The timeline point of the sync object in case the syncobj is of
> +* type DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ.
> +*/
> + __u64 timeline_value;
> +};
> +
> +/**
> + * struct drm_nouveau_vm_init - GPU VA space init structure
> + *
> + * Used to initialize the GPU's VA space for a user client, telling the
> kernel
> + * which portion of the VA space is managed by the UMD and kernel
> respectively.
>
I assume this has to be called quite early. Like maybe before any BOs or
channels are created? In any case, it'd be nice to have that documented.
> + */
> +struct drm_nouveau_vm_init {
> + /**
> +* @unmanaged_addr: start address of the kernel managed VA space
> region
> +*/
> + __u64 unmanaged_addr;
> + /**
> +* @unmanaged_size: size of the kernel managed VA space region in
> bytes
> +*/
> + __u64 unmanaged_size;
>
Over-all, I think this is the right API. My only concern is with the word
"unmanaged". None of the VA space is unmanaged. Some is userspace-managed
and some is kernel-managed. I guess "unmanaged" kinda makes sense because
this is coming from userspace and it's saying which bits it manages and
which bits it doesn't. Still seems clunky to me. Maybe kernel_managed?
IDK, that feels weird too. Since we're already using UMD in this file, we
could call it kmd_managed. IDK. 路♀️
Yeah, I know this is a total bikeshed color thing and I'm not going to
block anything based on it. Just wanted to see if we can come up with
anything better. It's documented and that's the important thing.
> +};
> +
> +/**
> + * struct drm_nouveau_vm_bind_op - VM_BIND operation
> + *
> + * This structure represents a single VM_BIND operation. UMDs should pass
> + * an array of this structure via struct drm_nouveau_vm_bind's _ptr
> field.
> + */
> +struct drm_nouveau_vm_bind_op {
> + /**
> +* @op: the operation type
> +*/
> + __u32 op;
> +/**
> + * @DRM_NOUVEAU_VM_BIND_OP_MAP:
> + *
> + * Map a GEM object to the GPU's VA space. Optionally, the
> + * _NOUVEAU_VM_BIND_SPARSE flag can be passed to instruct the kernel
> to
> + * create sparse mappings for the given range.
> + */
> +#define DRM_NOUVEAU_VM_BIND_OP_MAP 0x0
> +/**
> + * @DRM_NOUVEAU_VM_BIND_OP_UNMAP:
> + *
> + * Unmap an existing mapping in the GPU's VA space. If the region the
> mapping
> + * is located in is a sparse region, new sparse mappings are created
> where the
> + * unmapped (memory backed) mapping was mapped
Re: [PATCH v6 1/4] video: Add auxiliary display drivers to Graphics support menu
Javier Martinez Canillas writes: [adding Miguel Ojeda who was not in the Cc list] Hello Miguel, could you please ack this patch so that I can take the whole patch-set through the drm-misc tree? > The drivers in this subsystem are for character-based LCD displays, which > can fall into the same category of the DRM/KMS and fbdev drivers that are > located under the "Graphics support" menu. Add auxdisplay there as well. > > Suggested-by: Thomas Zimmermann > Signed-off-by: Javier Martinez Canillas > Reviewed-by: Arnd Bergmann > Tested-by: Arnd Bergmann > --- > > (no changes since v5) > > Changes in v5: > - Take the auxdisplay/Kconfig source out of "if HAS_IOMEM" (Geert > Uytterhoeven). > > drivers/Kconfig | 2 -- > drivers/video/Kconfig | 2 ++ > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/Kconfig b/drivers/Kconfig > index 514ae6b24cb2..496ca02ee18f 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -129,8 +129,6 @@ source "drivers/dma-buf/Kconfig" > > source "drivers/dca/Kconfig" > > -source "drivers/auxdisplay/Kconfig" > - > source "drivers/uio/Kconfig" > > source "drivers/vfio/Kconfig" > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > index 8b2b9ac37c3d..e5b1cc54cafa 100644 > --- a/drivers/video/Kconfig > +++ b/drivers/video/Kconfig > @@ -25,6 +25,8 @@ config VIDEO_NOMODESET > bool > default n > > +source "drivers/auxdisplay/Kconfig" > + > if HAS_IOMEM > > config HAVE_FB_ATMEL > -- > 2.41.0 > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 1/8] drm/ssd130x: Fix pitch calculation in ssd130x_fb_blit_rect()
Javier Martinez Canillas writes: Hello Geert, > Geert Uytterhoeven writes: > [...] >> >> My point is that the 8 as used here is related to the number of bits per >> pixel, >> not to the page height. The page height might also be impacted by the >> number of bits per pixel, but that is orthogonal. >> > > Ah, I see what you mean. Yes, you are right. We can later add a > different variable when adding support for controllers using R4. > > Reviewed-by: Javier Martinez Canillas > Pushed to drm-misc (drm-misc-next) since this fix is independent of the rest of the patches. Thanks! -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 16/17] cgroup/drm: Expose memory stats
On Wed, Jul 12, 2023 at 12:46:04PM +0100, Tvrtko Ursulin wrote: > $ cat drm.memory.stat > card0 region=system total=12898304 shared=0 active=0 resident=12111872 > purgeable=167936 > card0 region=stolen-system total=0 shared=0 active=0 resident=0 purgeable=0 > > Data is generated on demand for simplicty of implementation ie. no running > totals are kept or accounted during migrations and such. Various > optimisations such as cheaper collection of data are possible but > deliberately left out for now. > > Overall, the feature is deemed to be useful to container orchestration > software (and manual management). > > Limits, either soft or hard, are not envisaged to be implemented on top of > this approach due on demand nature of collecting the stats. So, yeah, if you want to add memory controls, we better think through how the fd ownership migration should work. Thanks. -- tejun
Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Restore efficient freq earlier
On 7/21/2023 3:08 PM, Belgaumkar, Vinay wrote:
On 7/21/2023 2:23 PM, Rodrigo Vivi wrote:
On Fri, Jul 21, 2023 at 01:44:34PM -0700, Belgaumkar, Vinay wrote:
On 7/21/2023 1:41 PM, Rodrigo Vivi wrote:
On Fri, Jul 21, 2023 at 11:03:49AM -0700, Vinay Belgaumkar wrote:
This should be done before the soft min/max frequencies are restored.
When we disable the "Ignore efficient frequency" flag, GuC does not
actually bring the requested freq down to RPn.
Specifically, this scenario-
- ignore efficient freq set to true
- reduce min to RPn (from efficient)
- suspend
- resume (includes GuC load, restore soft min/max, restore
efficient freq)
- validate min freq has been resored to RPn
This will fail if we didn't first restore(disable, in this case)
efficient
freq flag before setting the soft min frequency.
that's strange. so guc is returning the rpe when we request the min
freq
during the soft config?
we could alternatively change the soft config to actually get the min
and not be tricked by this.
But also the patch below doesn't hurt.
Reviewed-by: Rodrigo Vivi
(Although I'm still curious and want to understand exactly why
the soft min gets messed up when we don't tell guc to ignore the
efficient freq beforehand. Please help me to understand.)
The soft min does not get messed up, but GuC keeps requesting RPe
even after
disabling efficient freq. (unless we manually set min freq to RPn AFTER
disabling efficient).
so it looks to me that the right solution would be to ensure that
everytime
that we disable the efficient freq we make sure to also set the mim
freq to RPn,
no?!
Hmm, may not be applicable every time. What if someone disables
efficient frequency while running a workload or with frequency fixed
to 800, for example?
I'll take that back, it should not matter. GuC will not change it's
request just because we switched min lower. I will resend the patch with
the min setting as well.
Thanks,
Vinay.
Thanks,
Vinay.
Thanks,
Vinay.
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736
Fixes: 55f9720dbf23 ("drm/i915/guc/slpc: Provide sysfs for
efficient freq")
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index ee9f83af7cf6..f16dff7c3185 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -743,6 +743,9 @@ int intel_guc_slpc_enable(struct
intel_guc_slpc *slpc)
intel_guc_pm_intrmsk_enable(slpc_to_gt(slpc));
+ /* Set cached value of ignore efficient freq */
+ intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
+
slpc_get_rp_values(slpc);
/* Handle the case where min=max=RPmax */
@@ -765,9 +768,6 @@ int intel_guc_slpc_enable(struct
intel_guc_slpc *slpc)
/* Set cached media freq ratio mode */
intel_guc_slpc_set_media_ratio_mode(slpc,
slpc->media_ratio_mode);
- /* Set cached value of ignore efficient freq */
- intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
-
return 0;
}
--
2.38.1
Re: [PATCH 15/17] cgroup/drm: Expose GPU utilisation
On Fri, Jul 21, 2023 at 12:19:32PM -1000, Tejun Heo wrote: > On Wed, Jul 12, 2023 at 12:46:03PM +0100, Tvrtko Ursulin wrote: > > + drm.active_us > > + GPU time used by the group recursively including all child groups. > > Maybe instead add drm.stat and have "usage_usec" inside? That'd be more > consistent with cpu side. Also, shouldn't this be keyed by the drm device? -- tejun
Re: [PATCH 15/17] cgroup/drm: Expose GPU utilisation
On Wed, Jul 12, 2023 at 12:46:03PM +0100, Tvrtko Ursulin wrote: > + drm.active_us > + GPU time used by the group recursively including all child groups. Maybe instead add drm.stat and have "usage_usec" inside? That'd be more consistent with cpu side. Thanks. -- tejun
Re: [PATCH 12/17] cgroup/drm: Introduce weight based drm cgroup control
On Wed, Jul 12, 2023 at 12:46:00PM +0100, Tvrtko Ursulin wrote: > +DRM scheduling soft limits > +~~ Please don't say soft limits for this. It means something different for memcg, so it gets really confusing. Call it "weight based CPU time control" and maybe call the triggering points as thresholds. Thanks. -- tejun
Re: [PATCH 08/17] drm/cgroup: Track DRM clients per cgroup
Hello,
On Wed, Jul 12, 2023 at 12:45:56PM +0100, Tvrtko Ursulin wrote:
> +void drmcgroup_client_migrate(struct drm_file *file_priv)
> +{
> + struct drm_cgroup_state *src, *dst;
> + struct cgroup_subsys_state *old;
> +
> + mutex_lock(_mutex);
> +
> + old = file_priv->__css;
> + src = css_to_drmcs(old);
> + dst = css_to_drmcs(task_get_css(current, drm_cgrp_id));
> +
> + if (src != dst) {
> + file_priv->__css = >css; /* Keeps the reference. */
> + list_move_tail(_priv->clink, >clients);
> + }
> +
> + mutex_unlock(_mutex);
> +
> + css_put(old);
> +}
> +EXPORT_SYMBOL_GPL(drmcgroup_client_migrate);
So, you're implicitly migrating the fd to the latest ioctl user on the first
access. While this may work for state-less control like usage time. This
likely will cause problem if you later want to add stateful control for
memory consumption. e.g. What happens if the new destination doesn't have
enough budget to accommodate the fd's usage? Let's say we allow over-commit
with follow-up reclaim or oom kill actions, if so, can we guarantee that all
memory ownership for can always be updated? If not, what happens after
failure?
If DRM needs to transfer fd ownership with resources attached to it, it
likely would be a good idea to make that an explicit operation so that the
attempt can be verified and failed if necessary.
Thanks.
--
tejun
Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Restore efficient freq earlier
On 7/21/2023 2:23 PM, Rodrigo Vivi wrote:
On Fri, Jul 21, 2023 at 01:44:34PM -0700, Belgaumkar, Vinay wrote:
On 7/21/2023 1:41 PM, Rodrigo Vivi wrote:
On Fri, Jul 21, 2023 at 11:03:49AM -0700, Vinay Belgaumkar wrote:
This should be done before the soft min/max frequencies are restored.
When we disable the "Ignore efficient frequency" flag, GuC does not
actually bring the requested freq down to RPn.
Specifically, this scenario-
- ignore efficient freq set to true
- reduce min to RPn (from efficient)
- suspend
- resume (includes GuC load, restore soft min/max, restore efficient freq)
- validate min freq has been resored to RPn
This will fail if we didn't first restore(disable, in this case) efficient
freq flag before setting the soft min frequency.
that's strange. so guc is returning the rpe when we request the min freq
during the soft config?
we could alternatively change the soft config to actually get the min
and not be tricked by this.
But also the patch below doesn't hurt.
Reviewed-by: Rodrigo Vivi
(Although I'm still curious and want to understand exactly why
the soft min gets messed up when we don't tell guc to ignore the
efficient freq beforehand. Please help me to understand.)
The soft min does not get messed up, but GuC keeps requesting RPe even after
disabling efficient freq. (unless we manually set min freq to RPn AFTER
disabling efficient).
so it looks to me that the right solution would be to ensure that everytime
that we disable the efficient freq we make sure to also set the mim freq to RPn,
no?!
Hmm, may not be applicable every time. What if someone disables
efficient frequency while running a workload or with frequency fixed to
800, for example?
Thanks,
Vinay.
Thanks,
Vinay.
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736
Fixes: 55f9720dbf23 ("drm/i915/guc/slpc: Provide sysfs for efficient freq")
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index ee9f83af7cf6..f16dff7c3185 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -743,6 +743,9 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
intel_guc_pm_intrmsk_enable(slpc_to_gt(slpc));
+ /* Set cached value of ignore efficient freq */
+ intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
+
slpc_get_rp_values(slpc);
/* Handle the case where min=max=RPmax */
@@ -765,9 +768,6 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
/* Set cached media freq ratio mode */
intel_guc_slpc_set_media_ratio_mode(slpc, slpc->media_ratio_mode);
- /* Set cached value of ignore efficient freq */
- intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
-
return 0;
}
--
2.38.1
Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Restore efficient freq earlier
On Fri, Jul 21, 2023 at 01:44:34PM -0700, Belgaumkar, Vinay wrote:
>
> On 7/21/2023 1:41 PM, Rodrigo Vivi wrote:
> > On Fri, Jul 21, 2023 at 11:03:49AM -0700, Vinay Belgaumkar wrote:
> > > This should be done before the soft min/max frequencies are restored.
> > > When we disable the "Ignore efficient frequency" flag, GuC does not
> > > actually bring the requested freq down to RPn.
> > >
> > > Specifically, this scenario-
> > >
> > > - ignore efficient freq set to true
> > > - reduce min to RPn (from efficient)
> > > - suspend
> > > - resume (includes GuC load, restore soft min/max, restore efficient freq)
> > > - validate min freq has been resored to RPn
> > >
> > > This will fail if we didn't first restore(disable, in this case) efficient
> > > freq flag before setting the soft min frequency.
> > that's strange. so guc is returning the rpe when we request the min freq
> > during the soft config?
> >
> > we could alternatively change the soft config to actually get the min
> > and not be tricked by this.
> >
> > But also the patch below doesn't hurt.
> >
> > Reviewed-by: Rodrigo Vivi
> > (Although I'm still curious and want to understand exactly why
> > the soft min gets messed up when we don't tell guc to ignore the
> > efficient freq beforehand. Please help me to understand.)
>
> The soft min does not get messed up, but GuC keeps requesting RPe even after
> disabling efficient freq. (unless we manually set min freq to RPn AFTER
> disabling efficient).
so it looks to me that the right solution would be to ensure that everytime
that we disable the efficient freq we make sure to also set the mim freq to RPn,
no?!
>
> Thanks,
>
> Vinay.
>
> >
> >
> > > Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736
> > > Fixes: 55f9720dbf23 ("drm/i915/guc/slpc: Provide sysfs for efficient
> > > freq")
> > > Signed-off-by: Vinay Belgaumkar
> > > ---
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> > > index ee9f83af7cf6..f16dff7c3185 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> > > @@ -743,6 +743,9 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
> > > intel_guc_pm_intrmsk_enable(slpc_to_gt(slpc));
> > > + /* Set cached value of ignore efficient freq */
> > > + intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
> > > +
> > > slpc_get_rp_values(slpc);
> > > /* Handle the case where min=max=RPmax */
> > > @@ -765,9 +768,6 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
> > > /* Set cached media freq ratio mode */
> > > intel_guc_slpc_set_media_ratio_mode(slpc,
> > > slpc->media_ratio_mode);
> > > - /* Set cached value of ignore efficient freq */
> > > - intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
> > > -
> > > return 0;
> > > }
> > > --
> > > 2.38.1
> > >
[PATCH] drm/i915: Simplify expression _i915(dev)->drm
to_i915 is defined as
container_of(dev, struct drm_i915_private, drm);
So for a struct drm_device *dev, to_i915(dev)->drm is just dev. Simplify
accordingly.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 6 ++
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 6 +++---
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 165e2c7e3126..63c1fb9e479f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -819,8 +819,7 @@ static ssize_t i915_displayport_test_active_write(struct
file *file,
if (IS_ERR(input_buffer))
return PTR_ERR(input_buffer);
- drm_dbg(_i915(dev)->drm,
- "Copied %d bytes from user\n", (unsigned int)len);
+ drm_dbg(dev, "Copied %d bytes from user\n", (unsigned int)len);
drm_connector_list_iter_begin(dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
@@ -839,8 +838,7 @@ static ssize_t i915_displayport_test_active_write(struct
file *file,
status = kstrtoint(input_buffer, 10, );
if (status < 0)
break;
- drm_dbg(_i915(dev)->drm,
- "Got %d for test active\n", val);
+ drm_dbg(dev, "Got %d for test active\n", val);
/* To prevent erroneous activation of the compliance
* testing code, only accept an actual value of 1 here
*/
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 37d0b0fe791d..40371b8a9bbb 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -818,7 +818,7 @@ i915_gem_object_save_bit_17_swizzle(struct
drm_i915_gem_object *obj,
if (obj->bit_17 == NULL) {
obj->bit_17 = bitmap_zalloc(page_count, GFP_KERNEL);
if (obj->bit_17 == NULL) {
- drm_err(_i915(obj->base.dev)->drm,
+ drm_err(obj->base.dev,
"Failed to allocate memory for bit 17
record\n");
return;
}
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index ffb425ba591c..af2e49f90f2f 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -74,14 +74,14 @@ static void vma_print_allocator(struct i915_vma *vma, const
char *reason)
char buf[512];
if (!vma->node.stack) {
- drm_dbg(_i915(vma->obj->base.dev)->drm,
+ drm_dbg(vma->obj->base.dev,
"vma.node [%08llx + %08llx] %s: unknown owner\n",
vma->node.start, vma->node.size, reason);
return;
}
stack_depot_snprint(vma->node.stack, buf, sizeof(buf), 0);
- drm_dbg(_i915(vma->obj->base.dev)->drm,
+ drm_dbg(vma->obj->base.dev,
"vma.node [%08llx + %08llx] %s: inserted at %s\n",
vma->node.start, vma->node.size, reason, buf);
}
@@ -805,7 +805,7 @@ i915_vma_insert(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
* attempt to find space.
*/
if (size > end - 2 * guard) {
- drm_dbg(_i915(vma->obj->base.dev)->drm,
+ drm_dbg(vma->obj->base.dev,
"Attempting to bind an object larger than the aperture:
request=%llu > %s aperture=%llu\n",
size, flags & PIN_MAPPABLE ? "mappable" : "total", end);
return -ENOSPC;
base-commit: 85a241cb128ac449b301d5b7da16a7c11f5fc094
--
2.39.2
Re: [PATCH v2] drm: bridge: samsung-dsim: Fix waiting for empty cmd transfer FIFO on older Exynos
On Fri, Jul 21, 2023 at 8:28 AM Marek Szyprowski
wrote:
>
> Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
> doesn't report empty level of packer header FIFO. In case of those SoCs,
> use the old way of waiting for empty command tranfsfer FIFO, removed
> recently by commit 14806c641582 ("Drain command transfer FIFO before
> transfer").
>
> Fixes: 14806c641582 ("Drain command transfer FIFO before transfer")
Nitpick: the Subject of the commit log is not complete.
Fixes: 14806c641582 ("drm: bridge: samsung-dsim: Drain command
transfer FIFO before transfer")
> Signed-off-by: Marek Szyprowski
> ---
> v2:
> - added additional delay when workaround is used as suggested by Marek Vasut
>
> v1:
> https://lore.kernel.org/all/20230718131859.3114135-1-m.szyprow...@samsung.com/
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 18 --
> include/drm/bridge/samsung-dsim.h | 1 +
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 9b7a00bafeaa..d06401de637c 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -412,6 +412,7 @@ static const struct samsung_dsim_driver_data
> exynos3_dsi_driver_data = {
> .m_min = 41,
> .m_max = 125,
> .min_freq = 500,
> + .has_broken_fifoctrl_emptyhdr = 1,
> };
>
> static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
> @@ -428,6 +429,7 @@ static const struct samsung_dsim_driver_data
> exynos4_dsi_driver_data = {
> .m_min = 41,
> .m_max = 125,
> .min_freq = 500,
> + .has_broken_fifoctrl_emptyhdr = 1,
> };
>
> static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
> @@ -1009,8 +1011,20 @@ static int samsung_dsim_wait_for_hdr_fifo(struct
> samsung_dsim *dsi)
> do {
> u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
>
> - if (reg & DSIM_SFR_HEADER_EMPTY)
> - return 0;
> + if (!dsi->driver_data->has_broken_fifoctrl_emptyhdr) {
> + if (reg & DSIM_SFR_HEADER_EMPTY)
> + return 0;
> + } else {
> + if (!(reg & DSIM_SFR_HEADER_FULL)) {
> + /*
> +* Wait a little bit, so the pending data can
> +* actually leave the FIFO to avoid overflow.
> +*/
> + if (!cond_resched())
> + usleep_range(950, 1050);
> + return 0;
> + }
> + }
>
> if (!cond_resched())
> usleep_range(950, 1050);
> diff --git a/include/drm/bridge/samsung-dsim.h
> b/include/drm/bridge/samsung-dsim.h
> index 05100e91ecb9..18017b3e5d9e 100644
> --- a/include/drm/bridge/samsung-dsim.h
> +++ b/include/drm/bridge/samsung-dsim.h
> @@ -62,6 +62,7 @@ struct samsung_dsim_driver_data {
> const unsigned int *reg_values;
> u16 m_min;
> u16 m_max;
> + unsigned int has_broken_fifoctrl_emptyhdr;
> };
>
> struct samsung_dsim_host_ops {
> --
> 2.34.1
>
Re: [PATCH] drm/i915/guc/slpc: Restore efficient freq earlier
On 7/21/2023 1:41 PM, Rodrigo Vivi wrote:
On Fri, Jul 21, 2023 at 11:03:49AM -0700, Vinay Belgaumkar wrote:
This should be done before the soft min/max frequencies are restored.
When we disable the "Ignore efficient frequency" flag, GuC does not
actually bring the requested freq down to RPn.
Specifically, this scenario-
- ignore efficient freq set to true
- reduce min to RPn (from efficient)
- suspend
- resume (includes GuC load, restore soft min/max, restore efficient freq)
- validate min freq has been resored to RPn
This will fail if we didn't first restore(disable, in this case) efficient
freq flag before setting the soft min frequency.
that's strange. so guc is returning the rpe when we request the min freq
during the soft config?
we could alternatively change the soft config to actually get the min
and not be tricked by this.
But also the patch below doesn't hurt.
Reviewed-by: Rodrigo Vivi
(Although I'm still curious and want to understand exactly why
the soft min gets messed up when we don't tell guc to ignore the
efficient freq beforehand. Please help me to understand.)
The soft min does not get messed up, but GuC keeps requesting RPe even
after disabling efficient freq. (unless we manually set min freq to RPn
AFTER disabling efficient).
Thanks,
Vinay.
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736
Fixes: 55f9720dbf23 ("drm/i915/guc/slpc: Provide sysfs for efficient freq")
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index ee9f83af7cf6..f16dff7c3185 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -743,6 +743,9 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
intel_guc_pm_intrmsk_enable(slpc_to_gt(slpc));
+ /* Set cached value of ignore efficient freq */
+ intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
+
slpc_get_rp_values(slpc);
/* Handle the case where min=max=RPmax */
@@ -765,9 +768,6 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
/* Set cached media freq ratio mode */
intel_guc_slpc_set_media_ratio_mode(slpc, slpc->media_ratio_mode);
- /* Set cached value of ignore efficient freq */
- intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
-
return 0;
}
--
2.38.1
Re: [PATCH] drm/i915/guc/slpc: Restore efficient freq earlier
On Fri, Jul 21, 2023 at 11:03:49AM -0700, Vinay Belgaumkar wrote:
> This should be done before the soft min/max frequencies are restored.
> When we disable the "Ignore efficient frequency" flag, GuC does not
> actually bring the requested freq down to RPn.
>
> Specifically, this scenario-
>
> - ignore efficient freq set to true
> - reduce min to RPn (from efficient)
> - suspend
> - resume (includes GuC load, restore soft min/max, restore efficient freq)
> - validate min freq has been resored to RPn
>
> This will fail if we didn't first restore(disable, in this case) efficient
> freq flag before setting the soft min frequency.
that's strange. so guc is returning the rpe when we request the min freq
during the soft config?
we could alternatively change the soft config to actually get the min
and not be tricked by this.
But also the patch below doesn't hurt.
Reviewed-by: Rodrigo Vivi
(Although I'm still curious and want to understand exactly why
the soft min gets messed up when we don't tell guc to ignore the
efficient freq beforehand. Please help me to understand.)
>
> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736
> Fixes: 55f9720dbf23 ("drm/i915/guc/slpc: Provide sysfs for efficient freq")
> Signed-off-by: Vinay Belgaumkar
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> index ee9f83af7cf6..f16dff7c3185 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> @@ -743,6 +743,9 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
>
> intel_guc_pm_intrmsk_enable(slpc_to_gt(slpc));
>
> + /* Set cached value of ignore efficient freq */
> + intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
> +
> slpc_get_rp_values(slpc);
>
> /* Handle the case where min=max=RPmax */
> @@ -765,9 +768,6 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
> /* Set cached media freq ratio mode */
> intel_guc_slpc_set_media_ratio_mode(slpc, slpc->media_ratio_mode);
>
> - /* Set cached value of ignore efficient freq */
> - intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
> -
> return 0;
> }
>
> --
> 2.38.1
>
Re: [PATCH v2] drm: bridge: samsung-dsim: Fix waiting for empty cmd transfer FIFO on older Exynos
On 7/21/23 13:28, Marek Szyprowski wrote:
Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
doesn't report empty level of packer header FIFO. In case of those SoCs,
use the old way of waiting for empty command tranfsfer FIFO, removed
recently by commit 14806c641582 ("Drain command transfer FIFO before
transfer").
Fixes: 14806c641582 ("Drain command transfer FIFO before transfer")
Signed-off-by: Marek Szyprowski
Reviewed-by: Marek Vasut
Thanks !
Re: [PATCH v2 2/2] drm/bridge: tc358767: give VSDELAY some positive value
On 7/21/23 18:53, Lucas Stach wrote: From: David Jander The documentation is not clear about how this delay works. Empirical tests have shown that with a VSDELAY of 0, the first scanline is not properly formatted in the output stream when DSI->DP mode is used. The calculation spreadsheets from Toshiba seem to always make this value equal to the HFP + 10 for DSI->DP use-case. For DSI->DPI this value should be > 2 and for DPI->DP it seems to always be 0x64. Signed-off-by: David Jander Signed-off-by: Lucas Stach Tested-by: Marek Vasut # TC9595 Reviewed-by: Marek Vasut Applied both to drm-misc-next , thanks !
Re: [PATCH] accel/qaic: Fix slicing memory leak
> Slicing configuration data from user is stored in a temporary buffer > which should be freed unconditionally. Are imperative change descriptions still preferred? See also: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.5-rc2#n94 Regards, Markus
[PATCH 6.1 155/223] drm/ttm: Dont leak a resource on swapout move error
From: Thomas Hellström
commit a590f03d8de7c4cb7ce4916dc7f2fd10711faabe upstream.
If moving the bo to system for swapout failed, we were leaking
a resource. Fix.
Fixes: bfa3357ef9ab ("drm/ttm: allocate resource object instead of embedding it
v2")
Cc: Christian König
Cc: "Christian König"
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.14+
Signed-off-by: Thomas Hellström
Reviewed-by: Nirmoy Das
Reviewed-by: Andi Shyti
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20230626091450.14757-5-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1165,6 +1165,7 @@ int ttm_bo_swapout(struct ttm_buffer_obj
ret = ttm_bo_handle_move_mem(bo, evict_mem, true, , );
if (unlikely(ret != 0)) {
WARN(ret == -EMULTIHOP, "Unexpected multihop in swaput
- likely driver bug.\n");
+ ttm_resource_free(bo, _mem);
goto out;
}
}
[PATCH 6.1 069/223] drm/client: Send hotplug event after registering a client
From: Thomas Zimmermann
commit 27655b9bb9f0d9c32b8de8bec649b676898c52d5 upstream.
Generate a hotplug event after registering a client to allow the
client to configure its display. Remove the hotplug calls from the
existing clients for fbdev emulation. This change fixes a concurrency
bug between registering a client and receiving events from the DRM
core. The bug is present in the fbdev emulation of all drivers.
The fbdev emulation currently generates a hotplug event before
registering the client to the device. For each new output, the DRM
core sends an additional hotplug event to each registered client.
If the DRM core detects first output between sending the artificial
hotplug and registering the device, the output's hotplug event gets
lost. If this is the first output, the fbdev console display remains
dark. This has been observed with amdgpu and fbdev-generic.
Fix this by adding hotplug generation directly to the client's
register helper drm_client_register(). Registering the client and
receiving events are serialized by struct drm_device.clientlist_mutex.
So an output is either configured by the initial hotplug event, or
the client has already been registered.
The bug was originally added in commit 6e3f17ee73f7 ("drm/fb-helper:
generic: Call drm_client_add() after setup is done"), in which adding
a client and receiving a hotplug event switched order. It was hidden,
as most hardware and drivers have at least on static output configured.
Other drivers didn't use the internal DRM client or still had struct
drm_mode_config_funcs.output_poll_changed set. That callback handled
hotplug events as well. After not setting the callback in amdgpu in
commit 0e3172bac3f4 ("drm/amdgpu: Don't set struct
drm_driver.output_poll_changed"), amdgpu did not show a framebuffer
console if output events got lost. The bug got copy-pasted from
fbdev-generic into the other fbdev emulation.
Reported-by: Moritz Duge
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2649
Fixes: 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup
is done")
Fixes: 8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate
source file")
Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA
helpers")
Fixes: 63c381552f69 ("drm/armada: Implement fbdev emulation as in-kernel
client")
Fixes: 49953b70e7d3 ("drm/exynos: Implement fbdev emulation as in-kernel
client")
Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev emulation")
Fixes: 940b869c2f2f ("drm/msm: Implement fbdev emulation as in-kernel client")
Fixes: 9e69bcd88e45 ("drm/omapdrm: Implement fbdev emulation as in-kernel
client")
Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation")
Fixes: 71ec16f45ef8 ("drm/tegra: Implement fbdev emulation as in-kernel client")
Fixes: 0e3172bac3f4 ("drm/amdgpu: Don't set struct
drm_driver.output_poll_changed")
Signed-off-by: Thomas Zimmermann
Tested-by: Moritz Duge
Tested-by: Torsten Krah
Tested-by: Paul Schyska
Cc: Daniel Vetter
Cc: David Airlie
Cc: Noralf Trønnes
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Javier Martinez Canillas
Cc: Russell King
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Krzysztof Kozlowski
Cc: Patrik Jakobsson
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Tomi Valkeinen
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: Thierry Reding
Cc: Mikko Perttunen
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.2+
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Dmitry Baryshkov # msm
Link:
https://patchwork.freedesktop.org/patch/msgid/20230710091029.27503-1-tzimmerm...@suse.de
(cherry picked from commit 27655b9bb9f0d9c32b8de8bec649b676898c52d5)
[ Dropped changes to drivers/gpu/drm/armada/armada_fbdev.c as
174c3c38e3a2 drm/armada: Initialize fbdev DRM client
was introduced in 6.5-rc1.
Dropped changes to exynos, msm, omapdrm, radeon, tegra drivers
as missing code these commits introduced:
99286486d674 drm/exynos: Initialize fbdev DRM client
841ef552b141 drm/msm: Initialize fbdev DRM client
9e69bcd88e45 drm/omapdrm: Implement fbdev emulation as in-kernel client
e317a69fe891 drm/radeon: Implement client-based fbdev emulation
9b926bcf2636 drm/radeon: Only build fbdev if DRM_FBDEV_EMULATION is set
25dda38e0b07 drm/tegra: Initialize fbdev DRM client
8f1aaccb04b7 drm/gma500: Implement client-based fbdev emulation
b79fe9abd58b drm/fbdev-dma: Implement fbdev emulation for GEM DMA helpers
Move code for drm-fbdev-generic.c to matching file in 6.1.y because
these commits haven't happened in 6.1.y.
8ab59da26bc0 drm/fb-helper: Move generic fbdev emulation into separate source
file
Re: [PATCH v8 5/9] drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control
On Fri, Jul 21, 2023 at 06:15:10PM +0200, Andi Shyti wrote:
> Enable the CCS_FLUSH bit 13 in the control pipe for render and
> compute engines in platforms starting from Meteor Lake (BSPEC
> 43904 and 47112).
>
> Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all
> engines")
> Signed-off-by: Andi Shyti
> Cc: Jonathan Cavitt
> Cc: Nirmoy Das
> Cc: # v5.8+
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 7 +++
> drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 5d2175e918dd2..139a7e69f5c4d 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -230,6 +230,13 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> mode)
>
> bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
>
> + /*
> + * When required, in MTL and beyond platforms we
> + * need to set the CCS_FLUSH bit in the pipe control
> + */
> + if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
> + bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
> +
> bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
> bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
> bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> index 5d143e2a8db03..5df7cce23197c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> @@ -299,6 +299,7 @@
> #define PIPE_CONTROL_QW_WRITE (1<<14)
> #define PIPE_CONTROL_POST_SYNC_OP_MASK(3<<14)
> #define PIPE_CONTROL_DEPTH_STALL (1<<13)
> +#define PIPE_CONTROL_CCS_FLUSH (1<<13) /* MTL+ */
> #define PIPE_CONTROL_WRITE_FLUSH (1<<12)
> #define PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH (1<<12) /* gen6+ */
> #define PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE (1<<11) /* MBZ on ILK */
> --
> 2.40.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[PATCH 5.15 492/532] drm/ttm: Dont leak a resource on swapout move error
From: Thomas Hellström
commit a590f03d8de7c4cb7ce4916dc7f2fd10711faabe upstream.
If moving the bo to system for swapout failed, we were leaking
a resource. Fix.
Fixes: bfa3357ef9ab ("drm/ttm: allocate resource object instead of embedding it
v2")
Cc: Christian König
Cc: "Christian König"
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.14+
Signed-off-by: Thomas Hellström
Reviewed-by: Nirmoy Das
Reviewed-by: Andi Shyti
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20230626091450.14757-5-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1187,6 +1187,7 @@ int ttm_bo_swapout(struct ttm_buffer_obj
ret = ttm_bo_handle_move_mem(bo, evict_mem, true, , );
if (unlikely(ret != 0)) {
WARN(ret == -EMULTIHOP, "Unexpected multihop in swaput
- likely driver bug.\n");
+ ttm_resource_free(bo, _mem);
goto out;
}
}
Re: [PATCH v8 2/9] drm/i915: Add the gen12_needs_ccs_aux_inv helper
On Fri, Jul 21, 2023 at 06:15:07PM +0200, Andi Shyti wrote:
> We always assumed that a device might either have AUX or FLAT
> CCS, but this is an approximation that is not always true, e.g.
> PVC represents an exception.
>
> Set the basis for future finer selection by implementing a
> boolean gen12_needs_ccs_aux_inv() function that tells whether aux
> invalidation is needed or not.
>
> Currently PVC is the only exception to the above mentioned rule.
>
> Signed-off-by: Andi Shyti
> Cc: Matt Roper
> Cc: Jonathan Cavitt
> Cc: # v5.8+
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 563efee055602..460c9225a50fc 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -165,6 +165,18 @@ static u32 preparser_disable(bool state)
> return MI_ARB_CHECK | 1 << 8 | state;
> }
>
> +static bool gen12_needs_ccs_aux_inv(struct intel_engine_cs *engine)
> +{
> + if (IS_PONTEVECCHIO(engine->i915))
> + return false;
> +
> + /*
> + * so far platforms supported by i915 having
> + * flat ccs do not require AUX invalidation
> + */
> + return !HAS_FLAT_CCS(engine->i915);
> +}
> +
> 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;
> @@ -267,7 +279,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> mode)
> else if (engine->class == COMPUTE_CLASS)
> flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
>
> - if (!HAS_FLAT_CCS(rq->engine->i915))
> + if (gen12_needs_ccs_aux_inv(rq->engine))
> count = 8 + 4;
> else
> count = 8;
> @@ -285,7 +297,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> mode)
>
> cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
>
> - if (!HAS_FLAT_CCS(rq->engine->i915)) {
> + if (gen12_needs_ccs_aux_inv(rq->engine)) {
> /* hsdes: 1809175790 */
> cs = gen12_emit_aux_table_inv(rq->engine->gt, cs,
> GEN12_CCS_AUX_INV);
> @@ -307,7 +319,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32
> mode)
> if (mode & EMIT_INVALIDATE) {
> cmd += 2;
>
> - if (!HAS_FLAT_CCS(rq->engine->i915) &&
> + if (gen12_needs_ccs_aux_inv(rq->engine) &&
> (rq->engine->class == VIDEO_DECODE_CLASS ||
>rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
> aux_inv = rq->engine->mask &
> --
> 2.40.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[PATCH v3] drm/syncobj: add DRM_IOCTL_SYNCOBJ_IMPORT/EXPORT_SYNC_FILE
These new ioctls perform a task similar to
DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD/FD_TO_HANDLE with the
IMPORT/EXPORT_SYNC_FILE flag set, except that they allow specifying the
timeline point to import or export the fence to or from on a timeline
syncobj.
This eliminates the need to use a temporary binary syncobj along with
DRM_IOCTL_SYNCOBJ_TRANSFER to achieve such a thing, which is the
technique userspace has had to employ up to this point. While that does
work, it is rather awkward from the programmer's perspective. Since DRM
syncobjs have been proposed as the basis for display server explicit
synchronization protocols, e.g. [1] and [2], providing a more
streamlined interface now seems worthwhile.
[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90
[2] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967
Accompanying userspace patches...
IGT:
https://gitlab.freedesktop.org/ekurzinger/igt-gpu-tools/-/commit/e6f5c81bf893010411f1b471d68bb493ed36af67
libdrm:
https://gitlab.freedesktop.org/ekurzinger/drm/-/commit/22180768f85f1cce36ff34bbef34956b8803d6aa
V1 -> V2:
fixed conflict with DRM_IOCTL_MODE_GETFB2
re-ordered arguments of drm_syncobj_import_sync_file_fence
V2 -> V3:
add missing comma (whoops)
Signed-off-by: Erik Kurzinger
Reviewed-by: Simon Ser
---
drivers/gpu/drm/drm_internal.h | 4 +++
drivers/gpu/drm/drm_ioctl.c| 4 +++
drivers/gpu/drm/drm_syncobj.c | 62 ++
include/uapi/drm/drm.h | 8 +
4 files changed, 71 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index ba12acd55139..903731937595 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -255,6 +255,10 @@ int drm_syncobj_timeline_signal_ioctl(struct drm_device
*dev, void *data,
struct drm_file *file_private);
int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_import_sync_file_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
+int drm_syncobj_export_sync_file_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
/* drm_framebuffer.c */
void drm_framebuffer_print_info(struct drm_printer *p, unsigned int indent,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f03ffbacfe9b..92d6da811afd 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -711,6 +711,10 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_IMPORT_SYNC_FILE,
drm_syncobj_import_sync_file_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_EXPORT_SYNC_FILE,
drm_syncobj_export_sync_file_ioctl,
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl,
0),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE,
drm_crtc_queue_sequence_ioctl, 0),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl,
DRM_MASTER),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index be3e8787d207..ee87707e7587 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -185,6 +185,13 @@
* Note that if you want to transfer a struct _fence_chain from a given
* point on a timeline syncobj from/into a binary syncobj, you can use the
* point 0 to mean take/replace the fence in the syncobj.
+ *
+ * _IOCTL_SYNCOBJ_IMPORT_SYNC_FILE and _IOCTL_SYNCOBJ_EXPORT_SYNC_FILE
+ * let the client import or export the struct _fence_chain of a syncobj
+ * at a particular timeline point from or to a sync file.
+ * These behave similarly to _SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE
+ * and _SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_SYNC_FILE described above, except
+ * that they accommodate timeline syncobjs in addition to binary syncobjs.
*/
#include
@@ -736,10 +743,11 @@ static int drm_syncobj_fd_to_handle(struct drm_file
*file_private,
}
static int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
- int fd, int handle)
+ int fd, int handle, u64 point)
{
struct dma_fence *fence = sync_file_get_fence(fd);
struct drm_syncobj *syncobj;
+ int ret = 0;
if (!fence)
return -EINVAL;
@@ -750,14 +758,23 @@ static int drm_syncobj_import_sync_file_fence(struct
drm_file *file_private,
return -ENOENT;
}
- drm_syncobj_replace_fence(syncobj, fence);
+ if (point == 0) {
+
Re: [PATCH 1/2] drm/v3d: Avoid -Wconstant-logical-operand in nsecs_to_jiffies_timeout()
On Tue, Jul 18, 2023 at 2:44 PM Nathan Chancellor wrote:
>
> A proposed update to clang's -Wconstant-logical-operand to warn when the
> left hand side is a constant shows the following instance in
> nsecs_to_jiffies_timeout() when NSEC_PER_SEC is not a multiple of HZ,
> such as CONFIG_HZ=300:
>
> In file included from drivers/gpu/drm/v3d/v3d_debugfs.c:12:
> drivers/gpu/drm/v3d/v3d_drv.h:343:24: warning: use of logical '&&' with
> constant operand [-Wconstant-logical-operand]
> 343 | if (NSEC_PER_SEC % HZ &&
> | ~ ^
> drivers/gpu/drm/v3d/v3d_drv.h:343:24: note: use '&' for a bitwise operation
> 343 | if (NSEC_PER_SEC % HZ &&
> | ^~
> | &
> drivers/gpu/drm/v3d/v3d_drv.h:343:24: note: remove constant to silence this
> warning
> 1 warning generated.
>
> Turn this into an explicit comparison against zero to make the
> expression a boolean to make it clear this should be a logical check,
> not a bitwise one.
>
> Link: https://reviews.llvm.org/D142609
> Signed-off-by: Nathan Chancellor
Thanks for the patch!
Reviewed-by: Nick Desaulniers
> ---
> drivers/gpu/drm/v3d/v3d_drv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
> index b74b1351bfc8..7f664a4b2a75 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.h
> +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> @@ -340,7 +340,7 @@ struct v3d_submit_ext {
> static inline unsigned long nsecs_to_jiffies_timeout(const u64 n)
> {
> /* nsecs_to_jiffies64() does not guard against overflow */
> - if (NSEC_PER_SEC % HZ &&
> + if ((NSEC_PER_SEC % HZ) != 0 &&
> div_u64(n, NSEC_PER_SEC) >= MAX_JIFFY_OFFSET / HZ)
> return MAX_JIFFY_OFFSET;
>
>
> --
> 2.41.0
>
--
Thanks,
~Nick Desaulniers
[PATCH] accel/qaic: Fix slicing memory leak
From: Pranjal Ramajor Asha Kanojiya
Slicing configuration data from user is stored in a temporary buffer
which should be freed unconditionally.
Fixes: ff13be830333 ("accel/qaic: Add datapath")
Signed-off-by: Pranjal Ramajor Asha Kanojiya
Reviewed-by: Carl Vanderlip
Reviewed-by: Jeffrey Hugo
Signed-off-by: Jeffrey Hugo
---
drivers/accel/qaic/qaic_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/accel/qaic/qaic_data.c b/drivers/accel/qaic/qaic_data.c
index e9a1cb779b30..6b6d981a71be 100644
--- a/drivers/accel/qaic/qaic_data.c
+++ b/drivers/accel/qaic/qaic_data.c
@@ -1021,6 +1021,7 @@ int qaic_attach_slice_bo_ioctl(struct drm_device *dev,
void *data, struct drm_fi
bo->dbc = dbc;
srcu_read_unlock(>ch_lock, rcu_id);
drm_gem_object_put(obj);
+ kfree(slice_ent);
srcu_read_unlock(>dev_lock, qdev_rcu_id);
srcu_read_unlock(>qddev_lock, usr_rcu_id);
--
2.40.1
[PATCH 5/6] drm/format-helper-test: Add multi-plane support to conversion_buf_size()
The drm_fb_memcpy() supports multi-plane formats. To fully test it in
the future, add multi-plane support to the conversion_buf_size() helper.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/tests/drm_format_helper_test.c| 28 +--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index de4677868647..6ecd92898e8e 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -472,7 +472,7 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
* The size of the destination buffer or negative value on error.
*/
static size_t conversion_buf_size(u32 dst_format, unsigned int dst_pitch,
- const struct drm_rect *clip)
+ const struct drm_rect *clip, int plane)
{
const struct drm_format_info *dst_fi = drm_format_info(dst_format);
@@ -480,7 +480,7 @@ static size_t conversion_buf_size(u32 dst_format, unsigned
int dst_pitch,
return -EINVAL;
if (!dst_pitch)
- dst_pitch = drm_format_info_min_pitch(dst_fi, 0,
drm_rect_width(clip));
+ dst_pitch = drm_format_info_min_pitch(dst_fi, plane,
drm_rect_width(clip));
return dst_pitch * drm_rect_height(clip);
}
@@ -554,7 +554,7 @@ static void drm_test_fb_xrgb_to_gray8(struct kunit
*test)
};
dst_size = conversion_buf_size(DRM_FORMAT_R8, result->dst_pitch,
- >clip);
+ >clip, 0);
KUNIT_ASSERT_GT(test, dst_size, 0);
buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
@@ -587,7 +587,7 @@ static void drm_test_fb_xrgb_to_rgb332(struct kunit
*test)
};
dst_size = conversion_buf_size(DRM_FORMAT_RGB332, result->dst_pitch,
- >clip);
+ >clip, 0);
KUNIT_ASSERT_GT(test, dst_size, 0);
buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
@@ -620,7 +620,7 @@ static void drm_test_fb_xrgb_to_rgb565(struct kunit
*test)
};
dst_size = conversion_buf_size(DRM_FORMAT_RGB565, result->dst_pitch,
- >clip);
+ >clip, 0);
KUNIT_ASSERT_GT(test, dst_size, 0);
buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
@@ -663,7 +663,7 @@ static void drm_test_fb_xrgb_to_xrgb1555(struct kunit
*test)
};
dst_size = conversion_buf_size(DRM_FORMAT_XRGB1555, result->dst_pitch,
- >clip);
+ >clip, 0);
KUNIT_ASSERT_GT(test, dst_size, 0);
buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
@@ -697,7 +697,7 @@ static void drm_test_fb_xrgb_to_argb1555(struct kunit
*test)
};
dst_size = conversion_buf_size(DRM_FORMAT_ARGB1555, result->dst_pitch,
- >clip);
+ >clip, 0);
KUNIT_ASSERT_GT(test, dst_size, 0);
buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
@@ -731,7 +731,7 @@ static void drm_test_fb_xrgb_to_rgba5551(struct kunit
*test)
};
dst_size = conversion_buf_size(DRM_FORMAT_RGBA5551, result->dst_pitch,
- >clip);
+ >clip, 0);
KUNIT_ASSERT_GT(test, dst_size, 0);
buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
@@ -765,7 +765,7 @@ static void drm_test_fb_xrgb_to_rgb888(struct kunit
*test)
};
dst_size = conversion_buf_size(DRM_FORMAT_RGB888, result->dst_pitch,
- >clip);
+ >clip, 0);
KUNIT_ASSERT_GT(test, dst_size, 0);
buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
@@ -803,7 +803,7 @@ static void drm_test_fb_xrgb_to_argb(struct kunit
*test)
};
dst_size = conversion_buf_size(DRM_FORMAT_ARGB,
- result->dst_pitch, >clip);
+ result->dst_pitch, >clip, 0);
KUNIT_ASSERT_GT(test, dst_size, 0);
buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
@@ -838,7 +838,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
kunit *test)
};
dst_size = conversion_buf_size(DRM_FORMAT_XRGB2101010,
- result->dst_pitch, >clip);
+ result->dst_pitch, >clip, 0);
KUNIT_ASSERT_GT(test, dst_size, 0);
buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
@@ -872,7 +872,7 @@ static void drm_test_fb_xrgb_to_argb2101010(struct
kunit *test)
};
dst_size = conversion_buf_size(DRM_FORMAT_ARGB2101010,
-
[PATCH 6/6] drm/format-helper: Add KUnit tests for drm_fb_memcpy()
Insert parameterized test for the drm_fb_memcpy() to ensure correctness
and prevent future regressions. The test case can accept different
formats.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/tests/drm_format_helper_test.c| 391 ++
1 file changed, 391 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 6ecd92898e8e..3db4b95f3a98 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -1189,6 +1189,396 @@ static void drm_test_fb_build_fourcc_list(struct kunit
*test)
KUNIT_EXPECT_MEMEQ(test, fourccs_out, params->expected, TEST_BUF_SIZE);
}
+struct fb_memcpy_result {
+ unsigned int dst_pitches[DRM_FORMAT_MAX_PLANES];
+ const u32 expected[DRM_FORMAT_MAX_PLANES][TEST_BUF_SIZE];
+};
+
+struct multi_plane_op_case {
+ const char *name;
+ u32 format;
+ struct drm_rect clip;
+ unsigned int src_pitches[DRM_FORMAT_MAX_PLANES];
+ const u32 src[DRM_FORMAT_MAX_PLANES][TEST_BUF_SIZE];
+ struct fb_memcpy_result memcpy_result;
+};
+
+/* The `src` and `expected` buffers are u32 arrays. To deal with planes that
+ * have a cpp != 4 the values are stored together on the same u32 number in a
+ * way so the order in memory is correct in a little-endian machine.
+ *
+ * Because of that, on some occasions, parts of a u32 will not be part of the
+ * test, to make this explicit the 0xFF byte is used on those parts.
+ */
+
+static struct multi_plane_op_case multi_plane_op_cases[] = {
+ {
+ .name = "single_pixel_source_buffer",
+ .format = DRM_FORMAT_XRGB,
+ .clip = DRM_RECT_INIT(0, 0, 1, 1),
+ .src_pitches = { 1 * 4 },
+ .src = {{ 0x01020304 }},
+ .memcpy_result = {
+ .dst_pitches = { TEST_USE_DEFAULT_PITCH },
+ .expected = {{ 0x01020304 }},
+ }
+ },
+ {
+ .name = "single_pixel_source_buffer",
+ .format = DRM_FORMAT_XRGB_A8,
+ .clip = DRM_RECT_INIT(0, 0, 1, 1),
+ .src_pitches = { 1 * 4, 1 },
+ .src = {
+ { 0x01020304 },
+ { 0xFF01 },
+ },
+ .memcpy_result = {
+ .dst_pitches = { TEST_USE_DEFAULT_PITCH },
+ .expected = {
+ { 0x01020304 },
+ { 0x0001 },
+ },
+ },
+ },
+ {
+ .name = "single_pixel_source_buffer",
+ .format = DRM_FORMAT_YUV444,
+ .clip = DRM_RECT_INIT(0, 0, 1, 1),
+ .src_pitches = { 1, 1, 1 },
+ .src = {
+ { 0xFF01 },
+ { 0xFF01 },
+ { 0xFF01 },
+ },
+ .memcpy_result = {
+ .dst_pitches = { TEST_USE_DEFAULT_PITCH },
+ .expected = {
+ { 0x0001 },
+ { 0x0001 },
+ { 0x0001 },
+ },
+ },
+ },
+ {
+ .name = "single_pixel_clip_rectangle",
+ .format = DRM_FORMAT_XBGR,
+ .clip = DRM_RECT_INIT(1, 1, 1, 1),
+ .src_pitches = { 2 * 4 },
+ .src = {
+ {
+ 0x, 0x,
+ 0x, 0x01020304,
+ },
+ },
+ .memcpy_result = {
+ .dst_pitches = { TEST_USE_DEFAULT_PITCH },
+ .expected = {
+ { 0x01020304 },
+ },
+ },
+ },
+ {
+ .name = "single_pixel_clip_rectangle",
+ .format = DRM_FORMAT_XRGB_A8,
+ .clip = DRM_RECT_INIT(1, 1, 1, 1),
+ .src_pitches = { 2 * 4, 2 * 1 },
+ .src = {
+ {
+ 0x, 0x,
+ 0x, 0x01020304,
+ },
+ { 0x0100 },
+ },
+ .memcpy_result = {
+ .dst_pitches = { TEST_USE_DEFAULT_PITCH },
+ .expected = {
+ { 0x01020304 },
+ { 0x0001 },
+ },
+ },
+ },
+ {
+ .name = "single_pixel_clip_rectangle",
+ .format = DRM_FORMAT_YUV444,
+ .clip = DRM_RECT_INIT(1, 1, 1, 1),
+ .src_pitches = { 2 * 1, 2 * 1, 2 * 1
[PATCH 4/6] drm/format-helper: Add KUnit tests for drm_fb_build_fourcc_list()
Insert parameterized test for the drm_fb_build_fourcc_list() to ensure
correctness and prevent future regressions.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/tests/drm_format_helper_test.c| 143 ++
1 file changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 2e1c5463f063..de4677868647 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -3,6 +3,7 @@
#include
#include
+#include
#include
#include
#include
@@ -11,6 +12,7 @@
#include
#include
#include
+#include
#include "../drm_crtc_internal.h"
@@ -1047,6 +1049,146 @@ static void drm_test_fb_clip_offset(struct kunit *test)
KUNIT_EXPECT_EQ(test, offset, params->expected_offset);
}
+struct fb_build_fourcc_list_case {
+ const char *name;
+ u32 native_fourccs[TEST_BUF_SIZE];
+ u32 expected[TEST_BUF_SIZE];
+};
+
+struct fb_build_fourcc_list_case fb_build_fourcc_list_cases[] = {
+ {
+ .name = "no native formats",
+ .native_fourccs = { },
+ .expected = { DRM_FORMAT_XRGB },
+ },
+ {
+ .name = "XRGB as native format",
+ .native_fourccs = { DRM_FORMAT_XRGB },
+ .expected = { DRM_FORMAT_XRGB },
+ },
+ {
+ .name = "remove duplicates",
+ .native_fourccs = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ },
+ .expected = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_RGB565,
+ },
+ },
+ {
+ .name = "convert alpha formats",
+ .native_fourccs = {
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_ABGR1555,
+ DRM_FORMAT_RGBA5551,
+ DRM_FORMAT_BGRA5551,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_RGBA,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_ARGB2101010,
+ DRM_FORMAT_ABGR2101010,
+ DRM_FORMAT_RGBA1010102,
+ DRM_FORMAT_BGRA1010102,
+ },
+ .expected = {
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_XBGR1555,
+ DRM_FORMAT_RGBX5551,
+ DRM_FORMAT_BGRX5551,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_RGBX,
+ DRM_FORMAT_BGRX,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_RGBX1010102,
+ DRM_FORMAT_BGRX1010102,
+ },
+ },
+ {
+ .name = "random formats",
+ .native_fourccs = {
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_ABGR16161616F,
+ DRM_FORMAT_C8,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_RGBA5551,
+ DRM_FORMAT_BGR565_A8,
+ DRM_FORMAT_R10,
+ DRM_FORMAT_XYUV,
+ },
+ .expected = {
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_ABGR16161616F,
+ DRM_FORMAT_C8,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGBX5551,
+ DRM_FORMAT_BGR565_A8,
+ DRM_FORMAT_R10,
+ DRM_FORMAT_XYUV,
+ DRM_FORMAT_XRGB,
+ },
+ },
+};
+
+static void fb_build_fourcc_list_case_desc(struct fb_build_fourcc_list_case
*t, char *desc)
+{
+ strscpy(desc, t->name, KUNIT_PARAM_DESC_SIZE);
+}
+
+KUNIT_ARRAY_PARAM(fb_build_fourcc_list, fb_build_fourcc_list_cases,
fb_build_fourcc_list_case_desc);
+
+static size_t get_nfourccs(const u32 *fourccs)
+{
+ size_t i;
+
+ for (i = 0; i < TEST_BUF_SIZE && fourccs[i]; ++i)
+
[PATCH 3/6] drm/format-helper: Add KUnit tests for drm_fb_clip_offset()
Insert parameterized test for the drm_fb_clip_offset() to ensure
correctness and prevent future regressions.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/tests/drm_format_helper_test.c| 91 +++
1 file changed, 91 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index abeda642d84a..2e1c5463f063 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -957,6 +957,96 @@ static void drm_test_fb_swab(struct kunit *test)
KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
}
+struct clip_offset_case {
+ const char *name;
+ unsigned int pitch;
+ u32 format;
+ struct drm_rect clip;
+ unsigned int expected_offset;
+};
+
+static struct clip_offset_case clip_offset_cases[] = {
+ {
+ .name = "pass through",
+ .pitch = TEST_USE_DEFAULT_PITCH,
+ .format = DRM_FORMAT_XRGB,
+ .clip = DRM_RECT_INIT(0, 0, 3, 3),
+ .expected_offset = 0
+ },
+ {
+ .name = "horizontal offset",
+ .pitch = TEST_USE_DEFAULT_PITCH,
+ .format = DRM_FORMAT_XRGB,
+ .clip = DRM_RECT_INIT(1, 0, 3, 3),
+ .expected_offset = 4,
+ },
+ {
+ .name = "vertical offset",
+ .pitch = TEST_USE_DEFAULT_PITCH,
+ .format = DRM_FORMAT_XRGB,
+ .clip = DRM_RECT_INIT(0, 1, 3, 3),
+ .expected_offset = 12,
+ },
+ {
+ .name = "horizontal and vertical offset",
+ .pitch = TEST_USE_DEFAULT_PITCH,
+ .format = DRM_FORMAT_XRGB,
+ .clip = DRM_RECT_INIT(1, 1, 3, 3),
+ .expected_offset = 16,
+ },
+ {
+ .name = "horizontal offset (custom pitch)",
+ .pitch = 20,
+ .format = DRM_FORMAT_XRGB,
+ .clip = DRM_RECT_INIT(1, 0, 3, 3),
+ .expected_offset = 4,
+ },
+ {
+ .name = "vertical offset (custom pitch)",
+ .pitch = 20,
+ .format = DRM_FORMAT_XRGB,
+ .clip = DRM_RECT_INIT(0, 1, 3, 3),
+ .expected_offset = 20,
+ },
+ {
+ .name = "horizontal and vertical offset (custom pitch)",
+ .pitch = 20,
+ .format = DRM_FORMAT_XRGB,
+ .clip = DRM_RECT_INIT(1, 1, 3, 3),
+ .expected_offset = 24,
+ },
+};
+
+static void clip_offset_case_desc(struct clip_offset_case *t, char *desc)
+{
+ strscpy(desc, t->name, KUNIT_PARAM_DESC_SIZE);
+}
+
+KUNIT_ARRAY_PARAM(clip_offset, clip_offset_cases, clip_offset_case_desc);
+
+static void drm_test_fb_clip_offset(struct kunit *test)
+{
+ const struct clip_offset_case *params = test->param_value;
+ const struct drm_format_info *format_info =
drm_format_info(params->format);
+
+ unsigned int offset = -1;
+
+ unsigned int pitch = params->pitch;
+
+ if (pitch == TEST_USE_DEFAULT_PITCH)
+ pitch = drm_format_info_min_pitch(format_info, 0,
+
drm_rect_width(>clip));
+
+ /* Assure that the pitch is not zero, because this will inevitable
cause the
+* wrong expected result
+*/
+ KUNIT_ASSERT_NE(test, pitch, 0);
+
+ offset = drm_fb_clip_offset(pitch, format_info, >clip);
+
+ KUNIT_EXPECT_EQ(test, offset, params->expected_offset);
+}
+
static struct kunit_case drm_format_helper_test_cases[] = {
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_gray8,
convert_xrgb_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_rgb332,
convert_xrgb_gen_params),
@@ -970,6 +1060,7 @@ static struct kunit_case drm_format_helper_test_cases[] = {
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_argb2101010,
convert_xrgb_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_mono,
convert_xrgb_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_swab, convert_xrgb_gen_params),
+ KUNIT_CASE_PARAM(drm_test_fb_clip_offset, clip_offset_gen_params),
{}
};
--
2.41.0
[PATCH 2/6] drm/format-helper: Add KUnit tests for drm_fb_swab()
Insert parameterized test for the drm_fb_swab() to ensure correctness
and prevent future regressions.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/tests/drm_format_helper_test.c| 66 +++
1 file changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index bc6894f0a202..abeda642d84a 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -74,6 +74,11 @@ struct convert_to_mono_result {
const u8 expected[TEST_BUF_SIZE];
};
+struct fb_swab_result {
+ unsigned int dst_pitch;
+ const u32 expected[TEST_BUF_SIZE];
+};
+
struct convert_xrgb_case {
const char *name;
unsigned int pitch;
@@ -90,6 +95,7 @@ struct convert_xrgb_case {
struct convert_to_xrgb2101010_result xrgb2101010_result;
struct convert_to_argb2101010_result argb2101010_result;
struct convert_to_mono_result mono_result;
+ struct fb_swab_result swab_result;
};
static struct convert_xrgb_case convert_xrgb_cases[] = {
@@ -143,6 +149,10 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
.dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0b0 },
},
+ .swab_result = {
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
+ .expected = { 0xFF01 },
+ },
},
{
.name = "single_pixel_clip_rectangle",
@@ -197,6 +207,10 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
.dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0b0 },
},
+ .swab_result = {
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
+ .expected = { 0xFF10 },
+ },
},
{
/* Well known colors: White, black, red, green, blue, magenta,
@@ -318,6 +332,15 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0b11,
},
},
+ .swab_result = {
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
+ .expected = {
+ 0xFF11, 0x0022,
+ 0xFF33, 0x00FF0044,
+ 0xFF55, 0xFF00FF66,
+ 0x0077, 0x0088,
+ },
+ },
},
{
/* Randomly picked colors. Full buffer within the clip area. */
@@ -425,6 +448,14 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0b010, 0b000,
},
},
+ .swab_result = {
+ .dst_pitch = 20,
+ .expected = {
+ 0x9C440EA1, 0x054D11B1, 0x03F3A8C1, 0x,
0x,
+ 0x73F06CD1, 0x9C440EA2, 0x054D11B2, 0x,
0x,
+ 0x0303A8C2, 0x73F06CD2, 0x9C440EA3, 0x,
0x,
+ },
+ },
},
};
@@ -892,6 +923,40 @@ static void drm_test_fb_xrgb_to_mono(struct kunit
*test)
KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
}
+static void drm_test_fb_swab(struct kunit *test)
+{
+ const struct convert_xrgb_case *params = test->param_value;
+ const struct fb_swab_result *result = >swab_result;
+ size_t dst_size;
+ u32 *buf = NULL;
+ __le32 *xrgb = NULL;
+ struct iosys_map dst, src;
+
+ struct drm_framebuffer fb = {
+ .format = drm_format_info(DRM_FORMAT_XRGB),
+ .pitches = { params->pitch, 0, 0 },
+ };
+
+ dst_size = conversion_buf_size(DRM_FORMAT_XRGB, result->dst_pitch,
>clip);
+
+ KUNIT_ASSERT_GT(test, dst_size, 0);
+
+ buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
+ iosys_map_set_vaddr(, buf);
+
+ xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
+ iosys_map_set_vaddr(, xrgb);
+
+ if (result->dst_pitch == TEST_USE_DEFAULT_PITCH)
+ drm_fb_swab(, NULL, , , >clip, false);
+ else
+ drm_fb_swab(, >dst_pitch, , , >clip,
false);
+ buf = le32buf_to_cpu(test, (__force const __le32 *)buf, dst_size /
sizeof(u32));
+ KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
+}
+
static struct kunit_case drm_format_helper_test_cases[] = {
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_gray8,
convert_xrgb_gen_params),
[PATCH 1/6] drm/format-helper: Test default pitch fallback
Test the default pitch fallback when NULL is passed as the dst_pitch on
the conversion procedures.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/tests/drm_format_helper_test.c| 132 --
1 file changed, 87 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 474bb7a1c4ee..bc6894f0a202 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -16,6 +16,8 @@
#define TEST_BUF_SIZE 50
+#define TEST_USE_DEFAULT_PITCH 0
+
struct convert_to_gray8_result {
unsigned int dst_pitch;
const u8 expected[TEST_BUF_SIZE];
@@ -97,48 +99,48 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
.clip = DRM_RECT_INIT(0, 0, 1, 1),
.xrgb = { 0x01FF },
.gray8_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0x4C },
},
.rgb332_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0xE0 },
},
.rgb565_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0xF800 },
.expected_swab = { 0x00F8 },
},
.xrgb1555_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0x7C00 },
},
.argb1555_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0xFC00 },
},
.rgba5551_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0xF801 },
},
.rgb888_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0x00, 0x00, 0xFF },
},
.argb_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0x },
},
.xrgb2101010_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0x3FF0 },
},
.argb2101010_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0xFFF0 },
},
.mono_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0b0 },
},
},
@@ -151,48 +153,48 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0x, 0x10FF,
},
.gray8_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0x4C },
},
.rgb332_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0xE0 },
},
.rgb565_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0xF800 },
.expected_swab = { 0x00F8 },
},
.xrgb1555_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0x7C00 },
},
.argb1555_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0xFC00 },
},
.rgba5551_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0xF801 },
},
.rgb888_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
.expected = { 0x00, 0x00, 0xFF },
},
.argb_result = {
- .dst_pitch = 0,
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
[PATCH 0/6] Increase code coverage on drm_format_helper.c
The following series include improvements and new KUnit tests to some functions on drm_format_helper.c. The first patch improves existing conversion tests to assure that the default pitch is used when NULL is used on the `dst_pitch` argument. Patches 2, 3, 4, and 6 add the new parametrized tests to the following functions: - drm_fb_swab() - drm_fb_clip_offset() - drm_fb_build_fourcc_list() - drm_fb_memcpy() The 5th patch is a change to the conversion_buf_size() helper used on the tests, this change was needed to make the patch 6. a coverage report for the file can be found below: https://grillo-0.github.io/coverage-reports/gsoc-drm-format-test/drivers/gpu/drm/drm_format_helper.c.gcov.html Arthur Grillo (6): drm/format-helper: Test default pitch fallback drm/format-helper: Add KUnit tests for drm_fb_swab() drm/format-helper: Add KUnit tests for drm_fb_clip_offset() drm/format-helper: Add KUnit tests for drm_fb_build_fourcc_list() drm/format-helper-test: Add multi-plane support to conversion_buf_size() drm/format-helper: Add KUnit tests for drm_fb_memcpy() .../gpu/drm/tests/drm_format_helper_test.c| 849 -- 1 file changed, 791 insertions(+), 58 deletions(-) -- 2.41.0
Re: [PATCH v2] drm/syncobj: add DRM_IOCTL_SYNCOBJ_IMPORT/EXPORT_SYNC_FILE
Hi Erik,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-tip/drm-tip next-20230721]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes linus/master v6.5-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Erik-Kurzinger/drm-syncobj-add-DRM_IOCTL_SYNCOBJ_IMPORT-EXPORT_SYNC_FILE/20230722-003446
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/a09e38a6-5ac3-75c1-eadd-38a265e0ae33%40nvidia.com
patch subject: [PATCH v2] drm/syncobj: add
DRM_IOCTL_SYNCOBJ_IMPORT/EXPORT_SYNC_FILE
config: alpha-allyesconfig
(https://download.01.org/0day-ci/archive/20230722/202307220102.hq8n9hir-...@intel.com/config)
compiler: alpha-linux-gcc (GCC) 12.3.0
reproduce:
(https://download.01.org/0day-ci/archive/20230722/202307220102.hq8n9hir-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202307220102.hq8n9hir-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/drm_syncobj.c: In function 'drm_syncobj_fd_to_handle_ioctl':
>> drivers/gpu/drm/drm_syncobj.c:922:71: error: expected ')' before numeric
>> constant
922 |
args->handle
|
^
|
)
923 | 0 /*
binary */);
| ~
drivers/gpu/drm/drm_syncobj.c:920:58: note: to match this '('
920 | return
drm_syncobj_import_sync_file_fence(file_private,
| ^
>> drivers/gpu/drm/drm_syncobj.c:920:24: error: too few arguments to function
>> 'drm_syncobj_import_sync_file_fence'
920 | return
drm_syncobj_import_sync_file_fence(file_private,
|^~
drivers/gpu/drm/drm_syncobj.c:745:12: note: declared here
745 | static int drm_syncobj_import_sync_file_fence(struct drm_file
*file_private,
|^~
vim +922 drivers/gpu/drm/drm_syncobj.c
902
903 int
904 drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
905 struct drm_file *file_private)
906 {
907 struct drm_syncobj_handle *args = data;
908
909 if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
910 return -EOPNOTSUPP;
911
912 if (args->pad)
913 return -EINVAL;
914
915 if (args->flags != 0 &&
916 args->flags !=
DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE)
917 return -EINVAL;
918
919 if (args->flags &
DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE)
> 920 return drm_syncobj_import_sync_file_fence(file_private,
921args->fd,
> 922args->handle
9230 /* binary
*/);
924
925 return drm_syncobj_fd_to_handle(file_private, args->fd,
926 >handle);
927 }
928
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
[PATCH] drm/i915/guc/slpc: Restore efficient freq earlier
This should be done before the soft min/max frequencies are restored.
When we disable the "Ignore efficient frequency" flag, GuC does not
actually bring the requested freq down to RPn.
Specifically, this scenario-
- ignore efficient freq set to true
- reduce min to RPn (from efficient)
- suspend
- resume (includes GuC load, restore soft min/max, restore efficient freq)
- validate min freq has been resored to RPn
This will fail if we didn't first restore(disable, in this case) efficient
freq flag before setting the soft min frequency.
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736
Fixes: 55f9720dbf23 ("drm/i915/guc/slpc: Provide sysfs for efficient freq")
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index ee9f83af7cf6..f16dff7c3185 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -743,6 +743,9 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
intel_guc_pm_intrmsk_enable(slpc_to_gt(slpc));
+ /* Set cached value of ignore efficient freq */
+ intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
+
slpc_get_rp_values(slpc);
/* Handle the case where min=max=RPmax */
@@ -765,9 +768,6 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
/* Set cached media freq ratio mode */
intel_guc_slpc_set_media_ratio_mode(slpc, slpc->media_ratio_mode);
- /* Set cached value of ignore efficient freq */
- intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
-
return 0;
}
--
2.38.1
Re: [GIT PULL] fbdev fixes and cleanups for v6.5-rc3
The pull request you sent on Fri, 21 Jul 2023 16:12:51 +0200: > http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > tags/fbdev-for-6.5-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/55c225fbd8532a1bac6fd93c5085031650083a4a Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH v2 1/2] drm/bridge: tc358767: increase PLL lock time delay
From: David Jander The PLL often fails to lock with this delay. The new value was determined by trial and error increasing the delay bit by bit until the error did not occurr anymore even after several tries. Then double that value was taken as the minimum delay to be safe. Signed-off-by: David Jander Signed-off-by: Lucas Stach Reviewed-by: Marek Vasut Tested-by: Marek Vasut # TC9595 Reviewed-by: Marek Vasut --- v2: correct comment --- drivers/gpu/drm/bridge/tc358767.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 65dc842e31f0..29721e26de5d 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -500,8 +500,8 @@ static int tc_pllupdate(struct tc_data *tc, unsigned int pllctrl) if (ret) return ret; - /* Wait for PLL to lock: up to 2.09 ms, depending on refclk */ - usleep_range(3000, 6000); + /* Wait for PLL to lock: up to 7.5 ms, depending on refclk */ + usleep_range(15000, 2); return 0; } -- 2.41.0
[PATCH v2 2/2] drm/bridge: tc358767: give VSDELAY some positive value
From: David Jander The documentation is not clear about how this delay works. Empirical tests have shown that with a VSDELAY of 0, the first scanline is not properly formatted in the output stream when DSI->DP mode is used. The calculation spreadsheets from Toshiba seem to always make this value equal to the HFP + 10 for DSI->DP use-case. For DSI->DPI this value should be > 2 and for DPI->DP it seems to always be 0x64. Signed-off-by: David Jander Signed-off-by: Lucas Stach Tested-by: Marek Vasut # TC9595 Reviewed-by: Marek Vasut --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 29721e26de5d..5c33f13fdb39 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -817,7 +817,7 @@ static int tc_set_common_video_mode(struct tc_data *tc, * sync signals */ ret = regmap_write(tc->regmap, VPCTRL0, - FIELD_PREP(VSDELAY, 0) | + FIELD_PREP(VSDELAY, right_margin + 10) | OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED); if (ret) return ret; -- 2.41.0
Re: [PATCH] drm/syncobj: add DRM_IOCTL_SYNCOBJ_IMPORT/EXPORT_SYNC_FILE
That's a fair point. With my IGT patch I don't think we would have coverage of the old path any more. I'll try to fix that somehow, and I think your suggestion of including some "invalid" cases is also a good one. Anyway, apart from that I've posted a v2 of the kernel patch addressing your feedback from earlier. I've also rebased it on top of drm-misc-next. On 7/20/23 23:59, Simon Ser wrote: > I had a look at the IGT and I'm not sure about the approach. It seems > like the patch replaces occurrences of the old FLAGS_IMPORT_SYNC_FILE > and FLAGS_EXPORT_SYNC_FILE plus TRANSFER with the new IOCTLs. However > we still want to test the functionality of that old codepath: we need > to continue to test that the old IOCTLs work as expected. > > Are the old IOCTLs still sufficiently tested elsewhere? If not, we need > to either duplicate the tests, either add a flag to the test function > to select between old and new. > > Also, it would be good to have some basic tests for invalid cases, e.g. > for the invalid zero syncobj handle, for timeline points which haven't > materialized yet, etc. > > I wonder if we need to detect at runtime whether the IOCTL is available. > I'm not sure what the IGT requirements are, is it supposed to run on > any Linux version, or does it require drm-next? > > It would help to post the IGT patches on the mailing list so that we > can do a proper review there.
[Bug 217692] amdgpu crashes on resume from standby - amdgpu-reset-dev drm_sched_job_timedout
https://bugzilla.kernel.org/show_bug.cgi?id=217692 --- Comment #2 from Michal Turecki (ture...@gmail.com) --- Thanks, posted on https://gitlab.freedesktop.org/drm/amd/-/issues/2711. Apologies for confusing DRI and DRM. Please feel free to close/delete the issue. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2] drm/syncobj: add DRM_IOCTL_SYNCOBJ_IMPORT/EXPORT_SYNC_FILE
Reviewed-by: Simon Ser
[PATCH v2] drm/syncobj: add DRM_IOCTL_SYNCOBJ_IMPORT/EXPORT_SYNC_FILE
These new ioctls perform a task similar to
DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD/FD_TO_HANDLE with the
IMPORT/EXPORT_SYNC_FILE flag set, except that they allow specifying the
timeline point to import or export the fence to or from on a timeline
syncobj.
This eliminates the need to use a temporary binary syncobj along with
DRM_IOCTL_SYNCOBJ_TRANSFER to achieve such a thing, which is the
technique userspace has had to employ up to this point. While that does
work, it is rather awkward from the programmer's perspective. Since DRM
syncobjs have been proposed as the basis for display server explicit
synchronization protocols, e.g. [1] and [2], providing a more
streamlined interface now seems worthwhile.
[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90
[2] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967
Accompanying userspace patches...
IGT:
https://gitlab.freedesktop.org/ekurzinger/igt-gpu-tools/-/commit/e6f5c81bf893010411f1b471d68bb493ed36af67
libdrm:
https://gitlab.freedesktop.org/ekurzinger/drm/-/commit/22180768f85f1cce36ff34bbef34956b8803d6aa
V1 -> V2:
fixed conflict with DRM_IOCTL_MODE_GETFB2
re-ordered arguments of drm_syncobj_import_sync_file_fence
Signed-off-by: Erik Kurzinger
---
drivers/gpu/drm/drm_internal.h | 4 +++
drivers/gpu/drm/drm_ioctl.c| 4 +++
drivers/gpu/drm/drm_syncobj.c | 62 ++
include/uapi/drm/drm.h | 8 +
4 files changed, 71 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index ba12acd55139..903731937595 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -255,6 +255,10 @@ int drm_syncobj_timeline_signal_ioctl(struct drm_device
*dev, void *data,
struct drm_file *file_private);
int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_import_sync_file_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
+int drm_syncobj_export_sync_file_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
/* drm_framebuffer.c */
void drm_framebuffer_print_info(struct drm_printer *p, unsigned int indent,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f03ffbacfe9b..92d6da811afd 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -711,6 +711,10 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_IMPORT_SYNC_FILE,
drm_syncobj_import_sync_file_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_EXPORT_SYNC_FILE,
drm_syncobj_export_sync_file_ioctl,
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl,
0),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE,
drm_crtc_queue_sequence_ioctl, 0),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl,
DRM_MASTER),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index be3e8787d207..ca77a265a1ff 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -185,6 +185,13 @@
* Note that if you want to transfer a struct _fence_chain from a given
* point on a timeline syncobj from/into a binary syncobj, you can use the
* point 0 to mean take/replace the fence in the syncobj.
+ *
+ * _IOCTL_SYNCOBJ_IMPORT_SYNC_FILE and _IOCTL_SYNCOBJ_EXPORT_SYNC_FILE
+ * let the client import or export the struct _fence_chain of a syncobj
+ * at a particular timeline point from or to a sync file.
+ * These behave similarly to _SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE
+ * and _SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_SYNC_FILE described above, except
+ * that they accommodate timeline syncobjs in addition to binary syncobjs.
*/
#include
@@ -736,10 +743,11 @@ static int drm_syncobj_fd_to_handle(struct drm_file
*file_private,
}
static int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
- int fd, int handle)
+ int fd, int handle, u64 point)
{
struct dma_fence *fence = sync_file_get_fence(fd);
struct drm_syncobj *syncobj;
+ int ret = 0;
if (!fence)
return -EINVAL;
@@ -750,14 +758,23 @@ static int drm_syncobj_import_sync_file_fence(struct
drm_file *file_private,
return -ENOENT;
}
- drm_syncobj_replace_fence(syncobj, fence);
+ if (point == 0) {
+ drm_syncobj_replace_fence(syncobj, fence);
+ } else {
+
[PATCH 6.4 212/292] drm/ttm: Dont leak a resource on swapout move error
From: Thomas Hellström
commit a590f03d8de7c4cb7ce4916dc7f2fd10711faabe upstream.
If moving the bo to system for swapout failed, we were leaking
a resource. Fix.
Fixes: bfa3357ef9ab ("drm/ttm: allocate resource object instead of embedding it
v2")
Cc: Christian König
Cc: "Christian König"
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.14+
Signed-off-by: Thomas Hellström
Reviewed-by: Nirmoy Das
Reviewed-by: Andi Shyti
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20230626091450.14757-5-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1167,6 +1167,7 @@ int ttm_bo_swapout(struct ttm_buffer_obj
ret = ttm_bo_handle_move_mem(bo, evict_mem, true, , );
if (unlikely(ret != 0)) {
WARN(ret == -EMULTIHOP, "Unexpected multihop in swaput
- likely driver bug.\n");
+ ttm_resource_free(bo, _mem);
goto out;
}
}
[PATCH 6.4 211/292] drm/ttm: Dont leak a resource on eviction error
From: Thomas Hellström
commit e8188c461ee015ba0b9ab2fc82dbd5ebca5a5532 upstream.
On eviction errors other than -EMULTIHOP we were leaking a resource.
Fix.
v2:
- Avoid yet another goto (Andi Shyti)
Fixes: 403797925768 ("drm/ttm: Fix multihop assert on eviction.")
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.15+
Signed-off-by: Thomas Hellström
Reviewed-by: Nirmoy Das #v1
Reviewed-by: Andi Shyti
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20230626091450.14757-4-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_bo.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -458,18 +458,18 @@ static int ttm_bo_evict(struct ttm_buffe
goto out;
}
-bounce:
- ret = ttm_bo_handle_move_mem(bo, evict_mem, true, ctx, );
- if (ret == -EMULTIHOP) {
+ do {
+ ret = ttm_bo_handle_move_mem(bo, evict_mem, true, ctx, );
+ if (ret != -EMULTIHOP)
+ break;
+
ret = ttm_bo_bounce_temp_buffer(bo, _mem, ctx, );
- if (ret) {
- if (ret != -ERESTARTSYS && ret != -EINTR)
- pr_err("Buffer eviction failed\n");
- ttm_resource_free(bo, _mem);
- goto out;
- }
- /* try and move to final place now. */
- goto bounce;
+ } while (!ret);
+
+ if (ret) {
+ ttm_resource_free(bo, _mem);
+ if (ret != -ERESTARTSYS && ret != -EINTR)
+ pr_err("Buffer eviction failed\n");
}
out:
return ret;
[PATCH v8 8/9] drm/i915/gt: Poll aux invalidation register bit on invalidation
From: Jonathan Cavitt
For platforms that use Aux CCS, wait for aux invalidation to
complete by checking the aux invalidation register bit is
cleared.
Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Jonathan Cavitt
Signed-off-by: Andi Shyti
Cc: # v5.8+
Reviewed-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 17 -
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 646151e1b5deb..6daf7d99700e0 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -185,7 +185,15 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32
*cs, const i915_reg_t inv
*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
*cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
*cs++ = AUX_INV;
- *cs++ = MI_NOOP;
+
+ *cs++ = MI_SEMAPHORE_WAIT_TOKEN |
+ MI_SEMAPHORE_REGISTER_POLL |
+ MI_SEMAPHORE_POLL |
+ MI_SEMAPHORE_SAD_EQ_SDD;
+ *cs++ = 0;
+ *cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
+ *cs++ = 0;
+ *cs++ = 0;
return cs;
}
@@ -297,10 +305,9 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
+ count = 8;
if (gen12_needs_ccs_aux_inv(rq->engine))
- count = 8 + 4;
- else
- count = 8;
+ count += 8;
cs = intel_ring_begin(rq, count);
if (IS_ERR(cs))
@@ -347,7 +354,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
* table requires quiescing memory traffic beforehand
*/
if (aux_inv) {
- cmd += 4; /* for the AUX invalidation */
+ cmd += 8; /* for the AUX invalidation */
cmd += 2; /* for the engine quiescing */
cmd_flush = MI_FLUSH_DW;
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 5df7cce23197c..2bd8d98d21102 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -121,6 +121,7 @@
#define MI_SEMAPHORE_TARGET(engine) ((engine)<<15)
#define MI_SEMAPHORE_WAIT MI_INSTR(0x1c, 2) /* GEN8+ */
#define MI_SEMAPHORE_WAIT_TOKENMI_INSTR(0x1c, 3) /* GEN12+ */
+#define MI_SEMAPHORE_REGISTER_POLL (1 << 16)
#define MI_SEMAPHORE_POLL(1 << 15)
#define MI_SEMAPHORE_SAD_GT_SDD (0 << 12)
#define MI_SEMAPHORE_SAD_GTE_SDD (1 << 12)
--
2.40.1
[PATCH v8 9/9] drm/i915/gt: Support aux invalidation on all engines
Perform some refactoring with the purpose of keeping in one
single place all the operations around the aux table
invalidation.
With this refactoring add more engines where the invalidation
should be performed.
Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Andi Shyti
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: # v5.8+
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 53 ++--
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 3 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 17 +---
3 files changed, 36 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 6daf7d99700e0..d33462387d1c6 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -178,9 +178,36 @@ static bool gen12_needs_ccs_aux_inv(struct intel_engine_cs
*engine)
return !HAS_FLAT_CCS(engine->i915);
}
-u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t
inv_reg)
+static i915_reg_t gen12_get_aux_inv_reg(struct intel_engine_cs *engine)
+{
+ if (!gen12_needs_ccs_aux_inv(engine))
+ return INVALID_MMIO_REG;
+
+ switch (engine->id) {
+ case RCS0:
+ return GEN12_CCS_AUX_INV;
+ case BCS0:
+ return GEN12_BCS0_AUX_INV;
+ case VCS0:
+ return GEN12_VD0_AUX_INV;
+ case VCS2:
+ return GEN12_VD2_AUX_INV;
+ case VECS0:
+ return GEN12_VE0_AUX_INV;
+ case CCS0:
+ return GEN12_CCS0_AUX_INV;
+ default:
+ return INVALID_MMIO_REG;
+ }
+}
+
+u32 *gen12_emit_aux_table_inv(struct intel_engine_cs *engine, u32 *cs)
{
- u32 gsi_offset = gt->uncore->gsi_offset;
+ i915_reg_t inv_reg = gen12_get_aux_inv_reg(engine);
+ u32 gsi_offset = engine->gt->uncore->gsi_offset;
+
+ if (i915_mmio_reg_valid(inv_reg))
+ return cs;
*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
*cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
@@ -322,11 +349,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
- if (gen12_needs_ccs_aux_inv(rq->engine)) {
- /* hsdes: 1809175790 */
- cs = gen12_emit_aux_table_inv(rq->engine->gt, cs,
- GEN12_CCS_AUX_INV);
- }
+ cs = gen12_emit_aux_table_inv(engine, cs);
*cs++ = preparser_disable(false);
intel_ring_advance(rq, cs);
@@ -337,7 +360,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
{
- intel_engine_mask_t aux_inv = 0;
u32 cmd_flush = 0;
u32 cmd = 4;
u32 *cs;
@@ -345,15 +367,11 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32
mode)
if (mode & EMIT_INVALIDATE)
cmd += 2;
- if (gen12_needs_ccs_aux_inv(rq->engine))
- aux_inv = rq->engine->mask &
- ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
-
/*
* On Aux CCS platforms the invalidation of the Aux
* table requires quiescing memory traffic beforehand
*/
- if (aux_inv) {
+ if (gen12_needs_ccs_aux_inv(rq->engine)) {
cmd += 8; /* for the AUX invalidation */
cmd += 2; /* for the engine quiescing */
@@ -396,14 +414,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
*cs++ = 0; /* upper addr */
*cs++ = 0; /* value */
- if (aux_inv) { /* hsdes: 1809175790 */
- if (rq->engine->class == VIDEO_DECODE_CLASS)
- cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VD0_AUX_INV);
- else
- cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VE0_AUX_INV);
- }
+ cs = gen12_emit_aux_table_inv(rq->engine, cs);
if (mode & EMIT_INVALIDATE)
*cs++ = preparser_disable(false);
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index a44eda096557c..867ba697aceb8 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_engine_cs;
struct intel_gt;
struct i915_request;
@@ -46,7 +47,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
[PATCH v8 5/9] drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control
Enable the CCS_FLUSH bit 13 in the control pipe for render and
compute engines in platforms starting from Meteor Lake (BSPEC
43904 and 47112).
Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Andi Shyti
Cc: Jonathan Cavitt
Cc: Nirmoy Das
Cc: # v5.8+
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 7 +++
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 5d2175e918dd2..139a7e69f5c4d 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -230,6 +230,13 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
+ /*
+* When required, in MTL and beyond platforms we
+* need to set the CCS_FLUSH bit in the pipe control
+*/
+ if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+ bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
+
bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 5d143e2a8db03..5df7cce23197c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -299,6 +299,7 @@
#define PIPE_CONTROL_QW_WRITE(1<<14)
#define PIPE_CONTROL_POST_SYNC_OP_MASK(3<<14)
#define PIPE_CONTROL_DEPTH_STALL (1<<13)
+#define PIPE_CONTROL_CCS_FLUSH (1<<13) /* MTL+ */
#define PIPE_CONTROL_WRITE_FLUSH (1<<12)
#define PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH (1<<12) /* gen6+ */
#define PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE(1<<11) /* MBZ on ILK */
--
2.40.1
[PATCH v8 7/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines
Commit af9e423a8aae ("drm/i915/gt: Ensure memory quiesced before
invalidation") has made sure that the memory is quiesced before
invalidating the AUX CCS table. Do it for all the other engines
and not just RCS.
Signed-off-by: Andi Shyti
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: # v5.8+
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 36
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 5e19b45a5cabe..646151e1b5deb 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -331,26 +331,40 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
mode)
int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
{
intel_engine_mask_t aux_inv = 0;
- u32 cmd, *cs;
+ u32 cmd_flush = 0;
+ u32 cmd = 4;
+ u32 *cs;
- cmd = 4;
- if (mode & EMIT_INVALIDATE) {
+ if (mode & EMIT_INVALIDATE)
cmd += 2;
- if (gen12_needs_ccs_aux_inv(rq->engine) &&
- (rq->engine->class == VIDEO_DECODE_CLASS ||
-rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
- aux_inv = rq->engine->mask &
- ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
- if (aux_inv)
- cmd += 4;
- }
+ if (gen12_needs_ccs_aux_inv(rq->engine))
+ aux_inv = rq->engine->mask &
+ ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
+
+ /*
+* On Aux CCS platforms the invalidation of the Aux
+* table requires quiescing memory traffic beforehand
+*/
+ if (aux_inv) {
+ cmd += 4; /* for the AUX invalidation */
+ cmd += 2; /* for the engine quiescing */
+
+ cmd_flush = MI_FLUSH_DW;
+
+ if (rq->engine->class == COPY_ENGINE_CLASS)
+ cmd_flush |= MI_FLUSH_DW_CCS;
}
cs = intel_ring_begin(rq, cmd);
if (IS_ERR(cs))
return PTR_ERR(cs);
+ if (cmd_flush) {
+ *cs++ = cmd_flush;
+ *cs++ = 0;
+ }
+
if (mode & EMIT_INVALIDATE)
*cs++ = preparser_disable(true);
--
2.40.1
[PATCH v8 6/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function
Just a trivial refactoring for reducing the number of code
duplicate. This will come at handy in the next commits.
Meantime, propagate the error to the above layers if we fail to
emit the pipe control.
Signed-off-by: Andi Shyti
Cc: # v5.8+
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 47 +---
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 139a7e69f5c4d..5e19b45a5cabe 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -7,6 +7,7 @@
#include "i915_drv.h"
#include "intel_engine_regs.h"
#include "intel_gpu_commands.h"
+#include "intel_gt_print.h"
#include "intel_lrc.h"
#include "intel_ring.h"
@@ -189,23 +190,30 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32
*cs, const i915_reg_t inv
return cs;
}
+static int gen12_emit_pipe_control_cs(struct i915_request *rq, u32 bit_group_0,
+ u32 bit_group_1, u32 offset)
+{
+ u32 *cs;
+
+ cs = intel_ring_begin(rq, 6);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
+LRC_PPHWSP_SCRATCH_ADDR);
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
static int mtl_dummy_pipe_control(struct i915_request *rq)
{
/* Wa_14016712196 */
if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
- IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
- u32 *cs;
-
- /* dummy PIPE_CONTROL + depth flush */
- cs = intel_ring_begin(rq, 6);
- if (IS_ERR(cs))
- return PTR_ERR(cs);
- cs = gen12_emit_pipe_control(cs,
-0,
-PIPE_CONTROL_DEPTH_CACHE_FLUSH,
-LRC_PPHWSP_SCRATCH_ADDR);
- intel_ring_advance(rq, cs);
- }
+ IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0))
+ return gen12_emit_pipe_control_cs(rq, 0,
+ PIPE_CONTROL_DEPTH_CACHE_FLUSH,
+ LRC_PPHWSP_SCRATCH_ADDR);
return 0;
}
@@ -222,7 +230,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
u32 bit_group_0 = 0;
u32 bit_group_1 = 0;
int err;
- u32 *cs;
err = mtl_dummy_pipe_control(rq);
if (err)
@@ -256,13 +263,11 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
mode)
else if (engine->class == COMPUTE_CLASS)
bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
- cs = intel_ring_begin(rq, 6);
- if (IS_ERR(cs))
- return PTR_ERR(cs);
-
- cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
-LRC_PPHWSP_SCRATCH_ADDR);
- intel_ring_advance(rq, cs);
+ err = gen12_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
+LRC_PPHWSP_SCRATCH_ADDR);
+ if (err)
+ gt_warn(engine->gt,
+ "Failed to emit flush pipe control\n");
}
if (mode & EMIT_INVALIDATE) {
--
2.40.1
[PATCH v8 3/9] drm/i915/gt: Ensure memory quiesced before invalidation
From: Jonathan Cavitt
All memory traffic must be quiesced before requesting
an aux invalidation on platforms that use Aux CCS.
Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Jonathan Cavitt
Signed-off-by: Andi Shyti
Cc: # v5.8+
Reviewed-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 460c9225a50fc..6210b38a2d382 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -214,7 +214,11 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
{
struct intel_engine_cs *engine = rq->engine;
- if (mode & EMIT_FLUSH) {
+ /*
+* On Aux CCS platforms the invalidation of the Aux
+* table requires quiescing memory traffic beforehand
+*/
+ if (mode & EMIT_FLUSH || gen12_needs_ccs_aux_inv(engine)) {
u32 flags = 0;
int err;
u32 *cs;
--
2.40.1
[PATCH v8 4/9] drm/i915/gt: Rename flags with bit_group_X according to the datasheet
In preparation of the next patch align with the datasheet (BSPEC
47112) with the naming of the pipe control set of flag values.
The variable "flags" in gen12_emit_flush_rcs() is applied as a
set of flags called Bit Group 1.
Define also the Bit Group 0 as bit_group_0 where currently only
PIPE_CONTROL0_HDC_PIPELINE_FLUSH bit is set.
Signed-off-by: Andi Shyti
Cc: # v5.8+
Reviewed-by: Matt Roper
Reviewed-by: Andrzej Hajda
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 34 +---
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 18 -
2 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 6210b38a2d382..5d2175e918dd2 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -219,7 +219,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
* table requires quiescing memory traffic beforehand
*/
if (mode & EMIT_FLUSH || gen12_needs_ccs_aux_inv(engine)) {
- u32 flags = 0;
+ u32 bit_group_0 = 0;
+ u32 bit_group_1 = 0;
int err;
u32 *cs;
@@ -227,32 +228,33 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
mode)
if (err)
return err;
- flags |= PIPE_CONTROL_TILE_CACHE_FLUSH;
- flags |= PIPE_CONTROL_FLUSH_L3;
- flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
- flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+ bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
+
+ bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
+ bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
+ bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+ bit_group_1 |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
/* Wa_1409600907:tgl,adl-p */
- flags |= PIPE_CONTROL_DEPTH_STALL;
- flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
- flags |= PIPE_CONTROL_FLUSH_ENABLE;
+ bit_group_1 |= PIPE_CONTROL_DEPTH_STALL;
+ bit_group_1 |= PIPE_CONTROL_DC_FLUSH_ENABLE;
+ bit_group_1 |= PIPE_CONTROL_FLUSH_ENABLE;
- flags |= PIPE_CONTROL_STORE_DATA_INDEX;
- flags |= PIPE_CONTROL_QW_WRITE;
+ bit_group_1 |= PIPE_CONTROL_STORE_DATA_INDEX;
+ bit_group_1 |= PIPE_CONTROL_QW_WRITE;
- flags |= PIPE_CONTROL_CS_STALL;
+ bit_group_1 |= PIPE_CONTROL_CS_STALL;
if (!HAS_3D_PIPELINE(engine->i915))
- flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
+ bit_group_1 &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
else if (engine->class == COMPUTE_CLASS)
- flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
+ bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
cs = intel_ring_begin(rq, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
- cs = gen12_emit_pipe_control(cs,
-PIPE_CONTROL0_HDC_PIPELINE_FLUSH,
-flags, LRC_PPHWSP_SCRATCH_ADDR);
+ cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
+LRC_PPHWSP_SCRATCH_ADDR);
intel_ring_advance(rq, cs);
}
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index 655e5c00ddc27..a44eda096557c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -49,25 +49,29 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request
*rq, u32 *cs);
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)
+__gen8_emit_pipe_control(u32 *batch, u32 bit_group_0,
+u32 bit_group_1, u32 offset)
{
memset(batch, 0, 6 * sizeof(u32));
- batch[0] = GFX_OP_PIPE_CONTROL(6) | flags0;
- batch[1] = flags1;
+ batch[0] = GFX_OP_PIPE_CONTROL(6) | bit_group_0;
+ batch[1] = bit_group_1;
batch[2] = offset;
return batch + 6;
}
-static inline u32 *gen8_emit_pipe_control(u32 *batch, u32 flags, u32 offset)
+static inline u32 *gen8_emit_pipe_control(u32 *batch,
+ u32 bit_group_1, u32 offset)
{
- return __gen8_emit_pipe_control(batch, 0, flags, offset);
+ return __gen8_emit_pipe_control(batch, 0, bit_group_1, offset);
}
-static inline u32 *gen12_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1,
u32 offset)
+static inline u32 *gen12_emit_pipe_control(u32 *batch, u32 bit_group_0,
+
[PATCH v8 2/9] drm/i915: Add the gen12_needs_ccs_aux_inv helper
We always assumed that a device might either have AUX or FLAT
CCS, but this is an approximation that is not always true, e.g.
PVC represents an exception.
Set the basis for future finer selection by implementing a
boolean gen12_needs_ccs_aux_inv() function that tells whether aux
invalidation is needed or not.
Currently PVC is the only exception to the above mentioned rule.
Signed-off-by: Andi Shyti
Cc: Matt Roper
Cc: Jonathan Cavitt
Cc: # v5.8+
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 563efee055602..460c9225a50fc 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -165,6 +165,18 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
+static bool gen12_needs_ccs_aux_inv(struct intel_engine_cs *engine)
+{
+ if (IS_PONTEVECCHIO(engine->i915))
+ return false;
+
+ /*
+* so far platforms supported by i915 having
+* flat ccs do not require AUX invalidation
+*/
+ return !HAS_FLAT_CCS(engine->i915);
+}
+
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;
@@ -267,7 +279,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
- if (!HAS_FLAT_CCS(rq->engine->i915))
+ if (gen12_needs_ccs_aux_inv(rq->engine))
count = 8 + 4;
else
count = 8;
@@ -285,7 +297,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
- if (!HAS_FLAT_CCS(rq->engine->i915)) {
+ if (gen12_needs_ccs_aux_inv(rq->engine)) {
/* hsdes: 1809175790 */
cs = gen12_emit_aux_table_inv(rq->engine->gt, cs,
GEN12_CCS_AUX_INV);
@@ -307,7 +319,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (mode & EMIT_INVALIDATE) {
cmd += 2;
- if (!HAS_FLAT_CCS(rq->engine->i915) &&
+ if (gen12_needs_ccs_aux_inv(rq->engine) &&
(rq->engine->class == VIDEO_DECODE_CLASS ||
rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
aux_inv = rq->engine->mask &
--
2.40.1
[PATCH v8 1/9] drm/i915/gt: Cleanup aux invalidation registers
Fix the 'NV' definition postfix that is supposed to be INV.
Take the chance to also order properly the registers based on
their address and call the GEN12_GFX_CCS_AUX_INV address as
GEN12_CCS_AUX_INV like all the other similar registers.
Remove also VD1, VD3 and VE1 registers that don't exist and add
BCS0 and CCS0.
Signed-off-by: Andi Shyti
Cc: # v5.8+
Reviewed-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 8
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 16
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++---
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 23857cc08eca1..563efee055602 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -287,8 +287,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(rq->engine->gt,
- cs, GEN12_GFX_CCS_AUX_NV);
+ cs = gen12_emit_aux_table_inv(rq->engine->gt, cs,
+ GEN12_CCS_AUX_INV);
}
*cs++ = preparser_disable(false);
@@ -348,10 +348,10 @@ 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(rq->engine->gt,
- cs, GEN12_VD0_AUX_NV);
+ cs, GEN12_VD0_AUX_INV);
else
cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VE0_AUX_NV);
+ cs, GEN12_VE0_AUX_INV);
}
if (mode & EMIT_INVALIDATE)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 718cb2c80f79e..2cdfb2f713d02 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -332,9 +332,11 @@
#define GEN8_PRIVATE_PAT_HI_MMIO(0x40e0 + 4)
#define GEN10_PAT_INDEX(index) _MMIO(0x40e0 + (index) * 4)
#define BSD_HWS_PGA_GEN7 _MMIO(0x4180)
-#define GEN12_GFX_CCS_AUX_NV _MMIO(0x4208)
-#define GEN12_VD0_AUX_NV _MMIO(0x4218)
-#define GEN12_VD1_AUX_NV _MMIO(0x4228)
+
+#define GEN12_CCS_AUX_INV _MMIO(0x4208)
+#define GEN12_VD0_AUX_INV _MMIO(0x4218)
+#define GEN12_VE0_AUX_INV _MMIO(0x4238)
+#define GEN12_BCS0_AUX_INV _MMIO(0x4248)
#define GEN8_RTCR _MMIO(0x4260)
#define GEN8_M1TCR _MMIO(0x4264)
@@ -342,14 +344,12 @@
#define GEN8_BTCR _MMIO(0x426c)
#define GEN8_VTCR _MMIO(0x4270)
-#define GEN12_VD2_AUX_NV _MMIO(0x4298)
-#define GEN12_VD3_AUX_NV _MMIO(0x42a8)
-#define GEN12_VE0_AUX_NV _MMIO(0x4238)
-
#define BLT_HWS_PGA_GEN7 _MMIO(0x4280)
-#define GEN12_VE1_AUX_NV _MMIO(0x42b8)
+#define GEN12_VD2_AUX_INV _MMIO(0x4298)
+#define GEN12_CCS0_AUX_INV _MMIO(0x42c8)
#define AUX_INV REG_BIT(0)
+
#define VEBOX_HWS_PGA_GEN7 _MMIO(0x4380)
#define GEN12_AUX_ERR_DBG _MMIO(0x43f4)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 1b710102390bf..235f3fab60a98 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1374,7 +1374,7 @@ 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(ce->engine->gt,
- cs, GEN12_GFX_CCS_AUX_NV);
+ cs, GEN12_CCS_AUX_INV);
/* Wa_16014892111 */
if (IS_MTL_GRAPHICS_STEP(ce->engine->i915, M, STEP_A0, STEP_B0) ||
@@ -1403,10 +1403,10 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context
*ce, u32 *cs)
if (!HAS_FLAT_CCS(ce->engine->i915)) {
if (ce->engine->class == VIDEO_DECODE_CLASS)
cs = gen12_emit_aux_table_inv(ce->engine->gt,
- cs, GEN12_VD0_AUX_NV);
+
[PATCH v8 0/9] Update AUX invalidation sequence
Hi,
as there are new hardware directives, we need a little adaptation
for the AUX invalidation sequence.
In this version we support all the engines affected by this
change.
The stable backport has some challenges because the original
patch that this series fixes has had more changes in between.
This patch is slowly exploding with code refactorings and
features added and fixed.
Thanks a lot Nirmoy, Andrzej and Matt for your review and for the
fruitful discussions!
Thanks,
Andi
Changelog:
=
v7 -> v8
- Removed the aux invalidation from the device info and added a
helper function, instead (patch 2).
- Use "MTL and beyond" instead of "MTL+" in comments.
- Use the "gen12_" prefix instead of "intel_".
- In patch 6 return an int error instead of an error embedded in
the pointer in the intel_emit_pipe_control_cs() function and
propagate the error to the upper layers.
v6 -> v7
- Fix correct sequence applied to the correct engine. A little
confusion promptly cought by Nirmoy when applying to the VD
engine the sequence belonging to the compute engines. Thanks a
lot, Nirmoy!
v5 -> v6
- Fixed ccs flush in the engines VE and BCS. They are sent as a
separate command instead of added in the pipe control.
- Separated the CCS flusing in the pipe control patch with the
quiescing of the memory. They were meant to be on separate
patch already in the previous verision, but apparently I
squashed them by mistake.
v4 -> v5
- The AUX CCS is added as a device property instead of checking
against FLAT CCS. This adds the new HAS_AUX_CCS check
(Patch 2, new).
- little and trivial refactoring here and there.
- extended the flags{0,1}/bit_group_{0,1} renaming to other
functions.
- Created an intel_emit_pipe_control_cs() wrapper for submitting
the pipe control.
- Quiesce memory for all the engines, not just RCS (Patch 6,
new).
- The PIPE_CONTROL_CCS_FLUSH is added to all the engines.
- Remove redundant EMIT_FLUSH_CCS mode flag.
- Remove unnecessary NOOPs from the command streamer for
invalidating the CCS table.
- Use INVALID_MMIO_REG and gen12_get_aux_inv_reg() instad of
__MMIO(0) and reg.reg.
- Remove useless wrapper and just use gen12_get_aux_inv_reg().
v3 -> v4
- A trivial patch 3 is added to rename the flags with
bit_group_{0,1} to align with the datasheet naming.
- Patch 4 fixes a confusion I made where the CCS flag was
applied to the wrong bit group.
v2 -> v3
- added r-b from Nirmoy in patch 1 and 4.
- added patch 3 which enables the ccs_flush in the control pipe
for mtl+ compute and render engines.
- added redundant checks in patch 2 for enabling the EMIT_FLUSH
flag.
v1 -> v2
- add a clean up preliminary patch for the existing registers
- add support for more engines
- add the Fixes tag
Andi Shyti (7):
drm/i915/gt: Cleanup aux invalidation registers
drm/i915: Add the gen12_needs_ccs_aux_inv helper
drm/i915/gt: Rename flags with bit_group_X according to the datasheet
drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control
drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single
function
drm/i915/gt: Ensure memory quiesced before invalidation for all
engines
drm/i915/gt: Support aux invalidation on all engines
Jonathan Cavitt (2):
drm/i915/gt: Ensure memory quiesced before invalidation
drm/i915/gt: Poll aux invalidation register bit on invalidation
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 198 ---
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 21 +-
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 16 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 17 +-
5 files changed, 155 insertions(+), 99 deletions(-)
--
2.40.1
[PATCH] drm/crtc: Fix uninit-value bug in drm_mode_setcrtc
The connector_set contains uninitialized values when allocated with
kmalloc_array. However, in the "out" branch, the logic assumes that any
element in connector_set would be equal to NULL if failed to
initialize, which causes the bug reported by Syzbot. The fix is to use
an extra variable to keep track of how many connectors are initialized
indeed, and use that variable to decrease any refcounts in the "out"
branch.
Reported-by: syzbot+4fad2e57beb6397ab...@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao
---
drivers/gpu/drm/drm_crtc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index df9bf3c9206e..d718c17ab1e9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -715,8 +715,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_mode_set set;
uint32_t __user *set_connectors_ptr;
struct drm_modeset_acquire_ctx ctx;
- int ret;
- int i;
+ int ret, i, num_connectors;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -851,6 +850,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
goto out;
}
+ num_connectors = 0;
for (i = 0; i < crtc_req->count_connectors; i++) {
connector_set[i] = NULL;
set_connectors_ptr = (uint32_t __user *)(unsigned
long)crtc_req->set_connectors_ptr;
@@ -871,6 +871,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector->name);
connector_set[i] = connector;
+ num_connectors++;
}
}
@@ -879,7 +880,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.y = crtc_req->y;
set.mode = mode;
set.connectors = connector_set;
- set.num_connectors = crtc_req->count_connectors;
+ set.num_connectors = num_connectors;
set.fb = fb;
if (drm_drv_uses_atomic_modeset(dev))
@@ -892,7 +893,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
drm_framebuffer_put(fb);
if (connector_set) {
- for (i = 0; i < crtc_req->count_connectors; i++) {
+ for (i = 0; i < num_connectors; i++) {
if (connector_set[i])
drm_connector_put(connector_set[i]);
}
--
2.34.1
[PATCH 6.4 111/292] drm/client: Send hotplug event after registering a client
From: Thomas Zimmermann
commit 27655b9bb9f0d9c32b8de8bec649b676898c52d5 upstream.
Generate a hotplug event after registering a client to allow the
client to configure its display. Remove the hotplug calls from the
existing clients for fbdev emulation. This change fixes a concurrency
bug between registering a client and receiving events from the DRM
core. The bug is present in the fbdev emulation of all drivers.
The fbdev emulation currently generates a hotplug event before
registering the client to the device. For each new output, the DRM
core sends an additional hotplug event to each registered client.
If the DRM core detects first output between sending the artificial
hotplug and registering the device, the output's hotplug event gets
lost. If this is the first output, the fbdev console display remains
dark. This has been observed with amdgpu and fbdev-generic.
Fix this by adding hotplug generation directly to the client's
register helper drm_client_register(). Registering the client and
receiving events are serialized by struct drm_device.clientlist_mutex.
So an output is either configured by the initial hotplug event, or
the client has already been registered.
The bug was originally added in commit 6e3f17ee73f7 ("drm/fb-helper:
generic: Call drm_client_add() after setup is done"), in which adding
a client and receiving a hotplug event switched order. It was hidden,
as most hardware and drivers have at least on static output configured.
Other drivers didn't use the internal DRM client or still had struct
drm_mode_config_funcs.output_poll_changed set. That callback handled
hotplug events as well. After not setting the callback in amdgpu in
commit 0e3172bac3f4 ("drm/amdgpu: Don't set struct
drm_driver.output_poll_changed"), amdgpu did not show a framebuffer
console if output events got lost. The bug got copy-pasted from
fbdev-generic into the other fbdev emulation.
Reported-by: Moritz Duge
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2649
Fixes: 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup
is done")
Fixes: 8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate
source file")
Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA
helpers")
Fixes: 63c381552f69 ("drm/armada: Implement fbdev emulation as in-kernel
client")
Fixes: 49953b70e7d3 ("drm/exynos: Implement fbdev emulation as in-kernel
client")
Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev emulation")
Fixes: 940b869c2f2f ("drm/msm: Implement fbdev emulation as in-kernel client")
Fixes: 9e69bcd88e45 ("drm/omapdrm: Implement fbdev emulation as in-kernel
client")
Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation")
Fixes: 71ec16f45ef8 ("drm/tegra: Implement fbdev emulation as in-kernel client")
Fixes: 0e3172bac3f4 ("drm/amdgpu: Don't set struct
drm_driver.output_poll_changed")
Signed-off-by: Thomas Zimmermann
Tested-by: Moritz Duge
Tested-by: Torsten Krah
Tested-by: Paul Schyska
Cc: Daniel Vetter
Cc: David Airlie
Cc: Noralf Trønnes
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Javier Martinez Canillas
Cc: Russell King
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Krzysztof Kozlowski
Cc: Patrik Jakobsson
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Tomi Valkeinen
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: Thierry Reding
Cc: Mikko Perttunen
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.2+
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Dmitry Baryshkov # msm
Link:
https://patchwork.freedesktop.org/patch/msgid/20230710091029.27503-1-tzimmerm...@suse.de
[ Dropped changes to drivers/gpu/drm/armada/armada_fbdev.c as
174c3c38e3a2 drm/armada: Initialize fbdev DRM client
was introduced in 6.5-rc1 ]
Signed-off-by: Mario Limonciello
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_client.c | 21 +
drivers/gpu/drm/drm_fbdev_dma.c |4
drivers/gpu/drm/drm_fbdev_generic.c |4
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4
drivers/gpu/drm/gma500/fbdev.c|4
drivers/gpu/drm/msm/msm_fbdev.c |4
drivers/gpu/drm/omapdrm/omap_fbdev.c |4
drivers/gpu/drm/radeon/radeon_fbdev.c |4
drivers/gpu/drm/tegra/fbdev.c |4
9 files changed, 21 insertions(+), 32 deletions(-)
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -122,13 +122,34 @@ EXPORT_SYMBOL(drm_client_init);
* drm_client_register() it is no longer permissible to call
drm_client_release()
* directly (outside the unregister callback), instead
[PATCH] drm/modes: Fix division by zero error
In the bug reported by Syzbot, the variable `den == (1 << 22)` and
`mode->vscan == (1 << 10)`, causing the multiplication to overflow and
accidentally make `den == 0`. To prevent any chance of overflow, we
replace `num` and `den` with 64-bit unsigned integers, and explicitly
check if the divisor `den` will overflow. If so, we employ full 64-bit
division with rounding; otherwise we keep the 64-bit to 32-bit division
that could potentially be better optimized.
In order to minimize the performance overhead, the overflow check for
`den` is wrapped with an `unlikely` condition. Please let me know if
this usage is appropriate.
Reported-by: syzbot+622bba18029bcde67...@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao
---
drivers/gpu/drm/drm_modes.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ac9a406250c5..aa98bd7b8bc9 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1285,13 +1285,13 @@ EXPORT_SYMBOL(drm_mode_set_name);
*/
int drm_mode_vrefresh(const struct drm_display_mode *mode)
{
- unsigned int num, den;
+ unsigned long long num, den;
if (mode->htotal == 0 || mode->vtotal == 0)
return 0;
- num = mode->clock;
- den = mode->htotal * mode->vtotal;
+ num = mul_u32_u32(mode->clock, 1000);
+ den = mul_u32_u32(mode->htotal, mode->vtotal);
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
num *= 2;
@@ -1300,7 +1300,10 @@ int drm_mode_vrefresh(const struct drm_display_mode
*mode)
if (mode->vscan > 1)
den *= mode->vscan;
- return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(num, 1000), den);
+ if (unlikely(den >> 32))
+ return div64_u64(num + (den >> 1), den);
+ else
+ return DIV_ROUND_CLOSEST_ULL(num, (unsigned int) den);
}
EXPORT_SYMBOL(drm_mode_vrefresh);
--
2.34.1
Re: [PATCH] drm/radeon: ERROR: "foo * bar" should be "foo *bar"
Applied. Thanks!
On Fri, Jul 21, 2023 at 2:10 AM wrote:
>
> Fix nine occurrences of the checkpatch.pl error:
> ERROR: "foo * bar" should be "foo *bar"
>
> Signed-off-by: Ran Sun
> ---
> drivers/gpu/drm/radeon/atom.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atom.c
> b/drivers/gpu/drm/radeon/atom.c
> index 11a1940bb26d..93acb0e42bd6 100644
> --- a/drivers/gpu/drm/radeon/atom.c
> +++ b/drivers/gpu/drm/radeon/atom.c
> @@ -68,8 +68,8 @@ typedef struct {
> } atom_exec_context;
>
> int atom_debug = 0;
> -static int atom_execute_table_locked(struct atom_context *ctx, int
> index, uint32_t * params);
> -int atom_execute_table(struct atom_context *ctx, int index, uint32_t *
> params);
> +static int atom_execute_table_locked(struct atom_context *ctx, int
> index, uint32_t *params);
> +int atom_execute_table(struct atom_context *ctx, int index, uint32_t
> *params);
>
> static uint32_t atom_arg_mask[8] = {
> 0x, 0x, 0x0000, 0x,
Re: [PATCH] drm/amd/pm: open brace '{' following struct go on the same line
On Thu, Jul 20, 2023 at 11:53 PM wrote:
>
> ERROR: open brace '{' following struct go on the same line
>
The description doesn't match what the patch is doing.
Alex
> Signed-off-by: Ran Sun
> ---
> drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
> b/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
> index ddc488251313..0cf564ea1ed8 100644
> --- a/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
> +++ b/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
> @@ -429,10 +429,10 @@ int amdgpu_pm_load_smu_firmware(struct
> amdgpu_device *adev, uint32_t *smu_versio
> int amdgpu_dpm_handle_passthrough_sbr(struct amdgpu_device *adev, bool
> enable);
> int amdgpu_dpm_send_hbm_bad_pages_num(struct amdgpu_device *adev,
> uint32_t size);
> int amdgpu_dpm_send_hbm_bad_channel_flag(struct amdgpu_device *adev,
> uint32_t size);
> -int amdgpu_dpm_get_dpm_freq_range(struct amdgpu_device *adev,enum
> pp_clock_type type,
> - uint32_t *min,uint32_t *max);
> -int amdgpu_dpm_set_soft_freq_range(struct amdgpu_device *adev,enum
> pp_clock_type type,
> - uint32_t min,uint32_t max);
> +int amdgpu_dpm_get_dpm_freq_range(struct amdgpu_device *adev, enum
> pp_clock_type type,
> + uint32_t *min, uint32_t *max);
> +int amdgpu_dpm_set_soft_freq_range(struct amdgpu_device *adev, enum
> pp_clock_type type,
> + uint32_t min, uint32_t max);
> int amdgpu_dpm_write_watermarks_table(struct amdgpu_device *adev);
> int amdgpu_dpm_wait_for_event(struct amdgpu_device *adev, enum
> smu_event_type event,
> uint64_t event_arg);
Re: [PATCH] drm/amdgpu: open brace '{' following struct go on the same line
Applied. Thanks!
Alex
On Thu, Jul 20, 2023 at 11:32 PM wrote:
>
> ERROR: open brace '{' following struct go on the same line
>
> Signed-off-by: Ran Sun
> ---
> drivers/gpu/drm/amd/pm/inc/amdgpu_pm.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/inc/amdgpu_pm.h
> b/drivers/gpu/drm/amd/pm/inc/amdgpu_pm.h
> index 52045ad59bed..eec816f0cbf9 100644
> --- a/drivers/gpu/drm/amd/pm/inc/amdgpu_pm.h
> +++ b/drivers/gpu/drm/amd/pm/inc/amdgpu_pm.h
> @@ -24,8 +24,7 @@
> #ifndef __AMDGPU_PM_H__
> #define __AMDGPU_PM_H__
>
> -struct cg_flag_name
> -{
> +struct cg_flag_name {
> u64 flag;
> const char *name;
> };
Re: [PATCH] drm/amd/pm: open brace '{' following struct go on the same line
This applied properly. Applied. Thanks!
Alex
On Thu, Jul 20, 2023 at 11:27 PM wrote:
>
> ERROR: open brace '{' following struct go on the same line
>
> Signed-off-by: Ran Sun
> ---
> .../gpu/drm/amd/pm/inc/smu_v13_0_0_pptable.h | 21 +++
> 1 file changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/inc/smu_v13_0_0_pptable.h
> b/drivers/gpu/drm/amd/pm/inc/smu_v13_0_0_pptable.h
> index 1dc7a065a6d4..251ed011b3b0 100644
> --- a/drivers/gpu/drm/amd/pm/inc/smu_v13_0_0_pptable.h
> +++ b/drivers/gpu/drm/amd/pm/inc/smu_v13_0_0_pptable.h
> @@ -41,8 +41,7 @@
> #define SMU_13_0_0_PP_OVERDRIVE_VERSION 0x83// OverDrive 8
> Table Version 0.2
> #define SMU_13_0_0_PP_POWERSAVINGCLOCK_VERSION 0x01 // Power Saving
> Clock Table Version 1.00
>
> -enum SMU_13_0_0_ODFEATURE_CAP
> -{
> +enum SMU_13_0_0_ODFEATURE_CAP {
> SMU_13_0_0_ODCAP_GFXCLK_LIMITS = 0,
> SMU_13_0_0_ODCAP_UCLK_LIMITS,
> SMU_13_0_0_ODCAP_POWER_LIMIT,
> @@ -62,8 +61,7 @@ enum SMU_13_0_0_ODFEATURE_CAP
> SMU_13_0_0_ODCAP_COUNT,
> };
>
> -enum SMU_13_0_0_ODFEATURE_ID
> -{
> +enum SMU_13_0_0_ODFEATURE_ID {
> SMU_13_0_0_ODFEATURE_GFXCLK_LIMITS = 1 <<
> SMU_13_0_0_ODCAP_GFXCLK_LIMITS, //GFXCLK Limit feature
> SMU_13_0_0_ODFEATURE_UCLK_LIMITS = 1 <<
> SMU_13_0_0_ODCAP_UCLK_LIMITS, //UCLK Limit feature
> SMU_13_0_0_ODFEATURE_POWER_LIMIT = 1 <<
> SMU_13_0_0_ODCAP_POWER_LIMIT, //Power Limit feature
> @@ -85,8 +83,7 @@ enum SMU_13_0_0_ODFEATURE_ID
>
> #define SMU_13_0_0_MAX_ODFEATURE 32 //Maximum Number of OD Features
>
> -enum SMU_13_0_0_ODSETTING_ID
> -{
> +enum SMU_13_0_0_ODSETTING_ID {
> SMU_13_0_0_ODSETTING_GFXCLKFMAX = 0,
> SMU_13_0_0_ODSETTING_GFXCLKFMIN,
> SMU_13_0_0_ODSETTING_UCLKFMIN,
> @@ -123,8 +120,7 @@ enum SMU_13_0_0_ODSETTING_ID
> };
> #define SMU_13_0_0_MAX_ODSETTING 64 //Maximum Number of ODSettings
>
> -enum SMU_13_0_0_PWRMODE_SETTING
> -{
> +enum SMU_13_0_0_PWRMODE_SETTING {
> SMU_13_0_0_PMSETTING_POWER_LIMIT_QUIET = 0,
> SMU_13_0_0_PMSETTING_POWER_LIMIT_BALANCE,
> SMU_13_0_0_PMSETTING_POWER_LIMIT_TURBO,
> @@ -144,8 +140,7 @@ enum SMU_13_0_0_PWRMODE_SETTING
> };
> #define SMU_13_0_0_MAX_PMSETTING 32 //Maximum Number of PowerMode
> Settings
>
> -struct smu_13_0_0_overdrive_table
> -{
> +struct smu_13_0_0_overdrive_table {
> uint8_t revision; //Revision =
> SMU_13_0_0_PP_OVERDRIVE_VERSION
> uint8_t reserve[3]; //Zero filled field
> reserved for future use
> uint32_t feature_count; //Total number of
> supported features
> @@ -156,8 +151,7 @@ struct smu_13_0_0_overdrive_table
> int16_t pm_setting[SMU_13_0_0_MAX_PMSETTING]; //Optimized power
> mode feature settings
> };
>
> -enum SMU_13_0_0_PPCLOCK_ID
> -{
> +enum SMU_13_0_0_PPCLOCK_ID {
> SMU_13_0_0_PPCLOCK_GFXCLK = 0,
> SMU_13_0_0_PPCLOCK_SOCCLK,
> SMU_13_0_0_PPCLOCK_UCLK,
> @@ -175,8 +169,7 @@ enum SMU_13_0_0_PPCLOCK_ID
> };
> #define SMU_13_0_0_MAX_PPCLOCK 16 //Maximum Number of PP Clocks
>
> -struct smu_13_0_0_powerplay_table
> -{
> +struct smu_13_0_0_powerplay_table {
> struct atom_common_table_header header; //For SMU13,
> header.format_revision = 15, header.content_revision = 0
> uint8_t table_revision; //For SMU13, table_revision
> = 2
> uint8_t padding;
Re: [PATCH] drm/amd: open brace '{' following struct go on the same line
On Thu, Jul 20, 2023 at 9:31 PM wrote:
>
> Fix the checkpatch error as open brace '{' following struct should
> go on the same line.
>
> Signed-off-by: Ran Sun
git am didn't seem to like the patch, but I was able to apply it
cleanly manually with no fuzz. Not sure what's up, but I've applied
it.
Alex
> ---
> drivers/gpu/drm/amd/include/yellow_carp_offset.h | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/include/yellow_carp_offset.h
> b/drivers/gpu/drm/amd/include/yellow_carp_offset.h
> index 0fea6a746611..a2c8dca2425e 100644
> --- a/drivers/gpu/drm/amd/include/yellow_carp_offset.h
> +++ b/drivers/gpu/drm/amd/include/yellow_carp_offset.h
> @@ -7,13 +7,11 @@
> #define MAX_SEGMENT 6
>
>
> -struct IP_BASE_INSTANCE
> -{
> +struct IP_BASE_INSTANCE {
> unsigned int segment[MAX_SEGMENT];
> } __maybe_unused;
>
> -struct IP_BASE
> -{
> +struct IP_BASE {
> struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
> } __maybe_unused;
RE: [PATCH] drm/i915: Use the i915_vma_flush_writes helper
> -Original Message-
> From: dri-devel On Behalf Of Tvrtko
> Ursulin
> Sent: Friday, July 21, 2023 6:08 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Ursulin, Tvrtko
> Subject: [PATCH] drm/i915: Use the i915_vma_flush_writes helper
>
> From: Tvrtko Ursulin
>
> We can use the existing helper in flush_write_domain() and save some lines
> of code.
>
LGTM,
Radhakrishna Sripada
--Radhakrishna(RK) Sripada
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index dfaaa8b66ac3..ffddec1d2a76 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -68,10 +68,8 @@ flush_write_domain(struct drm_i915_gem_object *obj,
> unsigned int flush_domains)
> switch (obj->write_domain) {
> case I915_GEM_DOMAIN_GTT:
> spin_lock(>vma.lock);
> - for_each_ggtt_vma(vma, obj) {
> - if (i915_vma_unset_ggtt_write(vma))
> - intel_gt_flush_ggtt_writes(vma->vm->gt);
> - }
> + for_each_ggtt_vma(vma, obj)
> + i915_vma_flush_writes(vma);
> spin_unlock(>vma.lock);
>
> i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
> --
> 2.39.2
Re: [PATCH v3] drm/i915: Refactor PAT/object cache handling
On Thu, Jul 20, 2023 at 09:28:56PM -0700, Yang, Fei wrote:
> >>> [snip]
> > @@ -27,15 +28,8 @@ static bool gpu_write_needs_clflush(struct
> > drm_i915_gem_object *obj)
>
> The code change here looks accurate, but while we're here, I have a
> side question about this function in general...it was originally
> introduced in commit 48004881f693 ("drm/i915: Mark CPU cache as
> dirty when used for
> rendering") which states that GPU rendering ends up in the CPU cache
> (and thus needs a clflush later to make sure it lands in memory).
> That makes sense to me for LLC platforms, but is it really true for
> non-LLC snooping platforms (like MTL) as the commit states?
> >>>
> >>> For non-LLC platforms objects can be set to 1-way coherent which
> >>> means GPU rendering ending up in CPU cache as well, so for non-LLC
> >>> platform the logic here should be checking 1-way coherent flag.
> >>
> >> That's the part that I'm questioning (and not just for MTL, but for
> >> all of our other non-LLC platforms too). Just because there's
> >> coherency doesn't mean that device writes landed in the CPU cache.
> >> Coherency is also achieved if device writes invalidate the contents of the
> >> CPU cache.
> >> I thought our non-LLC snooping platforms were coherent due to
> >> write-invalidate rather than write-update, but I can't find it
> >> specifically documented anywhere at the moment. If write-invalidate
> >> was used, then there shouldn't be a need for a later clflush either.
> >
> > [Trying to consolidate by doing a combined reply to the discussion so far.]
> >
> > On the write-invalidate vs write-update I don't know. If you did not
> > find it in bspec then I doubt I would. I can have a browse still.
>
> Matt was correct. Quote Ron Silvas from SW ARCH, "MTL GPU doesn't write to
> CPU cache, it simply snoop CPU cache on its way to RAM."
That's good to know. We probably also want to find out if the same is
true for old snooping platforms (i.e., things like VLV/CHV/BXT) and/or
dgpu's (where I think the behavior is probably defined by the pcie spec,
but I'm not sure where to look for that).
>
> My understanding
> was that snooping platforms just invalidated the CPU cache to
> prevent future CPU reads from seeing stale data but didn't actually
> stick any new data in there? Am I off track or is the original
> logic of this function not quite right?
>
> Anyway, even if the logic of this function is wrong, it's a mistake
> that would only hurt performance
> >>>
> >>> Yes, this logic will introduce performance impact because it's
> >>> missing the checking for obj->pat_set_by_user. For objects with
> >>> pat_set_by_user==true, even if the object is snooping or 1-way
> >>> coherent, we don't want to enforce a clflush here since the
> >>> coherency is supposed to be handled by user space.
> >
> > What should I add you think to fix it?
>
> I think the simplest would be
>
> if (obj->pat_set_by_user)
> return false;
>
> because even checking for incoherent WB is unnecessary, simply no
> need for the KMD to initiate a flush if PAT is set by user.
I guess one thing we're missing today is a well-documented explanation
of the expectations for i915_gem_set_domain_ioctl behavior when we're
using a user-defined PAT?
Matt
>
> > Add a check for non-coherent WB in gpu_write_needs_clflush as an additional
> > condition for returning false?
> >
> > And then if Matt is correct write-invalidate is used also !HAS_LLC should
> > just return false?
> >
> (flushing more often than we truly need to) rather than
> functionality, so not something we really need to dig into right now
> as part of this patch.
>
> > if (IS_DGFX(i915))
> > return false;
> >
> > -/*
> > - * For objects created by userspace through GEM_CREATE with
> > pat_index
> > - * set by set_pat extension, i915_gem_object_has_cache_level() will
> > - * always return true, because the coherency of such object is
> > managed
> > - * by userspace. Othereise the call here would fall back to
> > checking
> > - * whether the object is un-cached or write-through.
> > - */
> > -return !(i915_gem_object_has_cache_level(obj, I915_CACHE_NONE) ||
> > - i915_gem_object_has_cache_level(obj, I915_CACHE_WT));
> > +return i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_UC) !=
> > 1 &&
> > + i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_WT) !=
> > 1;
> > }
> >>>
> >>> [snip]
> > @@ -640,15 +640,9 @@ static inline int use_cpu_reloc(const struct
> > reloc_cache *cache,
> > if (DBG_FORCE_RELOC == FORCE_GTT_RELOC)
> > return false;
> >
> > -/*
> > - * For objects created by userspace through GEM_CREATE with
> > pat_index
>
Re: [PATCH] MAINTAINERS: Update Alain Volmat's email address for drm/sti
On 4/19/23 08:33, Patrice CHOTARD wrote: Hi Alain On 4/16/23 22:27, Alain Volmat wrote: Update my email address for maintainer of the STi DRM driver. Signed-off-by: Alain Volmat --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0e64787aace8..3cec7ad72389 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6952,7 +6952,7 @@ F: Documentation/devicetree/bindings/display/rockchip/ F:drivers/gpu/drm/rockchip/ DRM DRIVERS FOR STI -M: Alain Volmat +M: Alain Volmat L:dri-devel@lists.freedesktop.org S:Maintained T:git git://anongit.freedesktop.org/drm/drm-misc Reviewed-by: Patrice Chotard Dear Arnd, May we ask you please to apply this patch (maybe on "soc/soc.git (arm/fixes)") as you did previously for a similar DRM/STI serie [1]? Many thanks Philippe :-) [1] https://lore.kernel.org/all/164431157889.18327.10086136061531044985.git-patchwork-not...@kernel.org/ Thanks Patrice
Re: (subset) [PATCH v2 0/4] video: backlight: lp855x: modernize bindings
From: Thierry Reding On Fri, 19 May 2023 20:07:24 +0200, Artur Weber wrote: > Convert TI LP855X backlight controller bindings from TXT to YAML and, > while we're at it, rework some of the code related to PWM handling. > Also correct existing DTS files to avoid introducing new dtb_check > errors. > > Signed-off-by: Artur Weber > > [...] Applied, thanks! [4/4] arm64: dts: adapt to LP855X bindings changes commit: faae0778fa10fa4e8909fe9164f06acab170f1e9 Best regards, -- Thierry Reding
[PATCH v2] drm/bridge: Add debugfs print for bridge chains
DRM bridges are not visible to the userspace and it may not be
immediately clear if the chain is somehow constructed incorrectly. I
have had two separate instances of a bridge driver failing to do a
drm_bridge_attach() call, resulting in the bridge connector not being
part of the chain. In some situations this doesn't seem to cause issues,
but it will if DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is used.
Add a debugfs file to print the bridge chains. For me, on this TI AM62
based platform, I get the following output:
encoder[39]
bridge[0] type: 0, ops: 0x0
bridge[1] type: 0, ops: 0x0, OF:
/bus@f/i2c@2000/dsi@e:toshiba,tc358778
bridge[2] type: 0, ops: 0x3, OF:
/bus@f/i2c@2001/hdmi@48:lontium,lt8912b
bridge[3] type: 11, ops: 0x7, OF: /hdmi-connector:hdmi-connector
Signed-off-by: Tomi Valkeinen
---
Changes in v2:
- Fixed compilation issue when !CONFIG_OF
- Link to v1:
https://lore.kernel.org/r/20230721-drm-bridge-chain-debugfs-v1-1-8614ff7e8...@ideasonboard.com
---
drivers/gpu/drm/drm_bridge.c | 50 +++
drivers/gpu/drm/drm_debugfs.c | 3 +++
include/drm/drm_bridge.h | 5 +
3 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index c3d69af02e79..d3eb62d5ef3b 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -27,8 +27,10 @@
#include
#include
+#include
#include
#include
+#include
#include
#include
@@ -1345,6 +1347,54 @@ struct drm_bridge *of_drm_find_bridge(struct device_node
*np)
EXPORT_SYMBOL(of_drm_find_bridge);
#endif
+#ifdef CONFIG_DEBUG_FS
+static int drm_bridge_chains_info(struct seq_file *m, void *data)
+{
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
+ struct drm_printer p = drm_seq_file_printer(m);
+ struct drm_mode_config *config = >mode_config;
+ struct drm_encoder *encoder;
+ unsigned int bridge_idx = 0;
+
+ list_for_each_entry(encoder, >encoder_list, head) {
+ struct drm_bridge *bridge;
+
+ drm_printf(, "encoder[%u]\n", encoder->base.id);
+
+ bridge = drm_bridge_chain_get_first_bridge(encoder);
+
+ while (bridge) {
+ drm_printf(, "\tbridge[%u] type: %u, ops: %#x",
+ bridge_idx, bridge->type, bridge->ops);
+
+#ifdef CONFIG_OF
+ if (bridge->of_node)
+ drm_printf(, ", OF: %pOFfc", bridge->of_node);
+#endif
+
+ drm_printf(, "\n");
+
+ bridge_idx++;
+ bridge = drm_bridge_get_next_bridge(bridge);
+ }
+ }
+
+ return 0;
+}
+
+/* any use in debugfs files to dump individual planes/crtc/etc? */
+static const struct drm_debugfs_info drm_bridge_debugfs_list[] = {
+ {"bridge_chains", drm_bridge_chains_info, 0},
+};
+
+void drm_bridge_debugfs_init(struct drm_minor *minor)
+{
+ drm_debugfs_add_files(minor->dev, drm_bridge_debugfs_list,
+ ARRAY_SIZE(drm_bridge_debugfs_list));
+}
+#endif
+
MODULE_AUTHOR("Ajay Kumar ");
MODULE_DESCRIPTION("DRM bridge infrastructure");
MODULE_LICENSE("GPL and additional rights");
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index c90dbcffa0dc..3e89559d68cd 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
#include
@@ -272,6 +273,8 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
drm_debugfs_add_files(minor->dev, drm_debugfs_list,
DRM_DEBUGFS_ENTRIES);
+ drm_bridge_debugfs_init(minor);
+
if (drm_drv_uses_atomic_modeset(dev)) {
drm_atomic_debugfs_init(minor);
}
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index bf964cdfb330..60dbee6bd1e6 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -949,4 +949,9 @@ static inline struct drm_bridge *drmm_of_get_bridge(struct
drm_device *drm,
}
#endif
+#ifdef CONFIG_DEBUG_FS
+struct drm_minor;
+void drm_bridge_debugfs_init(struct drm_minor *minor);
+#endif
+
#endif
---
base-commit: c7a472297169156252a50d76965eb36b081186e2
change-id: 20230721-drm-bridge-chain-debugfs-0bbc1522f57a
Best regards,
--
Tomi Valkeinen
[PATCH] drm/managed: Clean up GFP_ flag usage in drmm_kmalloc()
This code is not using the correct gfp flags which were passed in.
However, this does not affect runtime because kstrdup_const() is a
no-op in this context. (It just returns the "kmalloc" string literal
without doing an allocation.)
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/drm_managed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
index 5423ad883729..bcd111404b12 100644
--- a/drivers/gpu/drm/drm_managed.c
+++ b/drivers/gpu/drm/drm_managed.c
@@ -196,7 +196,7 @@ void *drmm_kmalloc(struct drm_device *dev, size_t size,
gfp_t gfp)
size, gfp);
return NULL;
}
- dr->node.name = kstrdup_const("kmalloc", GFP_KERNEL);
+ dr->node.name = kstrdup_const("kmalloc", gfp);
add_dr(dev, dr);
--
2.39.2
[PATCH] drm: bridge: samsung-dsim: Clean up a call to request_irq()
This is calling request_threaded_irq() but the thread parameter is NULL
so it's actually not a threaded irq. Which is a bit misleading. Call
request_irq() instead.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/bridge/samsung-dsim.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 9b7a00bafeaa..9d81dbbc6680 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1637,8 +1637,8 @@ static int samsung_dsim_register_te_irq(struct
samsung_dsim *dsi, struct device
te_gpio_irq = gpiod_to_irq(dsi->te_gpio);
- ret = request_threaded_irq(te_gpio_irq, samsung_dsim_te_irq_handler,
NULL,
- IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN, "TE",
dsi);
+ ret = request_irq(te_gpio_irq, samsung_dsim_te_irq_handler,
+ IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN, "TE", dsi);
if (ret) {
dev_err(dsi->dev, "request interrupt failed with %d\n", ret);
gpiod_put(dsi->te_gpio);
--
2.39.2
Re: [PATCH v5 05/11] drm/amdgpu: Use RMW accessors for changing LNKCTL
On Fri, Jul 21, 2023 at 4:18 AM Ilpo Järvinen
wrote:
>
> On Thu, 20 Jul 2023, Bjorn Helgaas wrote:
>
> > On Mon, Jul 17, 2023 at 03:04:57PM +0300, Ilpo Järvinen wrote:
> > > Don't assume that only the driver would be accessing LNKCTL. ASPM
> > > policy changes can trigger write to LNKCTL outside of driver's control.
> > > And in the case of upstream bridge, the driver does not even own the
> > > device it's changing the registers for.
> > >
> > > Use RMW capability accessors which do proper locking to avoid losing
> > > concurrent updates to the register value.
> > >
> > > Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts")
> > > Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10")
> > > Suggested-by: Lukas Wunner
> > > Signed-off-by: Ilpo Järvinen
> > > Cc: sta...@vger.kernel.org
> >
> > Do we have any reports of problems that are fixed by this patch (or by
> > others in the series)? If not, I'm not sure it really fits the usual
> > stable kernel criteria:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-kernel-rules.rst?id=v6.4
>
> I was on the edge with this. The answer to your direct question is no,
> there are no such reports so it would be okay to leave stable out I think.
> This applies to all patches in this series.
>
> Basically, this series came to be after Lukas noted the potential
> concurrency issues with how LNKCTL is unprotected when reviewing
> (internally) my bandwidth controller series. Then I went to look around
> all LNKCTL usage and realized existing things might alreary have similar
> issues.
>
> Do you want me to send another version w/o cc stable or you'll take care
> of that?
>
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/cik.c | 36 +---
> > > drivers/gpu/drm/amd/amdgpu/si.c | 36 +---
> > > 2 files changed, 20 insertions(+), 52 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c
> > > b/drivers/gpu/drm/amd/amdgpu/cik.c
> > > index 5641cf05d856..e63abdf52b6c 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/cik.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/cik.c
> > > @@ -1574,17 +1574,8 @@ static void cik_pcie_gen3_enable(struct
> > > amdgpu_device *adev)
> > > u16 bridge_cfg2, gpu_cfg2;
> > > u32 max_lw, current_lw, tmp;
> > >
> > > - pcie_capability_read_word(root, PCI_EXP_LNKCTL,
> > > - _cfg);
> > > - pcie_capability_read_word(adev->pdev, PCI_EXP_LNKCTL,
> > > - _cfg);
> > > -
> > > - tmp16 = bridge_cfg | PCI_EXP_LNKCTL_HAWD;
> > > - pcie_capability_write_word(root, PCI_EXP_LNKCTL,
> > > tmp16);
> > > -
> > > - tmp16 = gpu_cfg | PCI_EXP_LNKCTL_HAWD;
> > > - pcie_capability_write_word(adev->pdev, PCI_EXP_LNKCTL,
> > > - tmp16);
> > > + pcie_capability_set_word(root, PCI_EXP_LNKCTL,
> > > PCI_EXP_LNKCTL_HAWD);
> > > + pcie_capability_set_word(adev->pdev, PCI_EXP_LNKCTL,
> > > PCI_EXP_LNKCTL_HAWD);
> > >
> > > tmp = RREG32_PCIE(ixPCIE_LC_STATUS1);
> > > max_lw = (tmp &
> > > PCIE_LC_STATUS1__LC_DETECTED_LINK_WIDTH_MASK) >>
> > > @@ -1637,21 +1628,14 @@ static void cik_pcie_gen3_enable(struct
> > > amdgpu_device *adev)
> > > msleep(100);
> > >
> > > /* linkctl */
> > > - pcie_capability_read_word(root,
> > > PCI_EXP_LNKCTL,
> > > - );
> > > - tmp16 &= ~PCI_EXP_LNKCTL_HAWD;
> > > - tmp16 |= (bridge_cfg & PCI_EXP_LNKCTL_HAWD);
> > > - pcie_capability_write_word(root,
> > > PCI_EXP_LNKCTL,
> > > - tmp16);
> > > -
> > > - pcie_capability_read_word(adev->pdev,
> > > - PCI_EXP_LNKCTL,
> > > - );
> > > - tmp16 &= ~PCI_EXP_LNKCTL_HAWD;
> > > - tmp16 |= (gpu_cfg & PCI_EXP_LNKCTL_HAWD);
> > > - pcie_capability_write_word(adev->pdev,
> > > - PCI_EXP_LNKCTL,
> > > - tmp16);
> > > + pcie_capability_clear_and_set_word(root,
> > > PCI_EXP_LNKCTL,
> > > +
> > > PCI_EXP_LNKCTL_HAWD,
> > > + bridge_cfg
> > > &
> > > +
[Bug 217692] amdgpu crashes on resume from standby - amdgpu-reset-dev drm_sched_job_timedout
https://bugzilla.kernel.org/show_bug.cgi?id=217692 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED --- Comment #1 from Artem S. Tashkinov (a...@gmx.com) --- Please take it here instead: https://gitlab.freedesktop.org/drm/amd/-/issues -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PULL] drm-misc-next
Hi, Here's this week drm-misc-next PR Thanks! Maxime The following changes since commit 36672dda2eb715af99e9abbcdc400d46598b691c: drm/loongson: Remove a useless check in cursor_plane_atomic_async_check() (2023-07-13 01:24:42 +0800) are available in the Git repository at: ssh://git.freedesktop.org/git/drm/drm-misc tags/drm-misc-next-2023-07-21 for you to fetch changes up to d281eeaa4de2636ff0c8e6ae387bb07b50e5fcbb: drm: adv7511: Fix low refresh rate register for ADV7533/5 (2023-07-21 13:37:18 +0200) drm-misc-next for 6.6: UAPI Changes: - syncobj: New DRM_IOCTL_SYNCOBJ_EVENTFD ioctl Cross-subsystem Changes: - Converge to use of_device_uevent() Core Changes: - GPU VA Manager - improvements to make it clearer that drm_minor_type is uAPI Driver Changes: - ssd130x: Improve intermediate buffer size computation - bridges: - adv7511: Fix low refresh rate - anx7625: Switch to macros instead of hardcoded values - panel: - ld9040: Backlight support, magic improved Bogdan Togorean (1): drm: adv7511: Fix low refresh rate register for ADV7533/5 Chen-Yu Tsai (2): drm/bridge: anx7625: Use common macros for DP power sequencing commands drm/bridge: anx7625: Use common macros for HDCP capabilities Danilo Krummrich (2): drm: manager to keep track of GPUs VA mappings drm: debugfs: provide infrastructure to dump a DRM GPU VA space Javier Martinez Canillas (1): drm/ssd130x: Change pixel format used to compute the buffer size Marek Vasut (1): drm/panel: simple: Drop prepared_time Miquel Raynal (2): of: module: Export of_device_uevent() gpu: host1x: Stop open-coding of_device_uevent() Paul Cercueil (2): drm/panel: ld9040: Use better magic values drm/panel: ld9040: Register a backlight device Rob Herring (2): gpu/host1x: Explicitly include correct DT includes drm: Explicitly include correct DT includes Simon Ser (3): drm/drv: use enum drm_minor_type when appropriate drm/file: use explicit values for enum drm_minor_type drm/syncobj: add IOCTL to register an eventfd Steven Price (2): drm: manager: Fix printk format for size_t drm: debugfs: Silence warning from cast Documentation/gpu/drm-mm.rst | 36 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/arm/display/komeda/komeda_dev.c|2 +- drivers/gpu/drm/arm/malidp_drv.c |1 + drivers/gpu/drm/bridge/adv7511/adv7511_cec.c |1 - drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 11 +- drivers/gpu/drm/bridge/analogix/anx7625.c | 12 +- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c |3 +- .../gpu/drm/bridge/cadence/cdns-mhdp8546-core.c|1 - drivers/gpu/drm/bridge/chipone-icn6211.c |2 +- drivers/gpu/drm/bridge/display-connector.c |1 - drivers/gpu/drm/bridge/fsl-ldb.c |1 - drivers/gpu/drm/bridge/imx/imx8qm-ldb.c|2 +- drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c |1 + drivers/gpu/drm/bridge/lontium-lt9211.c|1 - drivers/gpu/drm/bridge/lvds-codec.c|1 - drivers/gpu/drm/bridge/nwl-dsi.c |2 +- drivers/gpu/drm/bridge/parade-ps8622.c |1 - drivers/gpu/drm/bridge/samsung-dsim.c |3 +- drivers/gpu/drm/bridge/simple-bridge.c |3 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |2 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c |2 +- drivers/gpu/drm/bridge/ti-sn65dsi83.c |2 +- drivers/gpu/drm/drm_debugfs.c | 40 + drivers/gpu/drm/drm_drv.c |8 +- drivers/gpu/drm/drm_gem.c |3 + drivers/gpu/drm/drm_gpuva_mgr.c| 1725 drivers/gpu/drm/drm_internal.h |2 + drivers/gpu/drm/drm_ioctl.c|2 + drivers/gpu/drm/drm_mipi_dsi.c |1 + drivers/gpu/drm/drm_syncobj.c | 148 +- drivers/gpu/drm/etnaviv/etnaviv_gpu.c |2 +- drivers/gpu/drm/exynos/exynos5433_drm_decon.c |2 +- drivers/gpu/drm/exynos/exynos7_drm_decon.c |1 - drivers/gpu/drm/exynos/exynos_drm_dsi.c|3 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c |1 - drivers/gpu/drm/exynos/exynos_drm_rotator.c|2 +- drivers/gpu/drm/exynos/exynos_drm_scaler.c |2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |2 +- drivers/gpu/drm/exynos/exynos_mixer.c |1 - drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|2 +- drivers/gpu/drm/imx/dcss/dcss-dev.c|5 +-
[GIT PULL] fbdev fixes and cleanups for v6.5-rc3
Hi Linus, please pull some fbdev fixes & cleanups for kernel 6.5-rc3. Just the usual bunch of code cleanups in various drivers, this time mostly in vgacon and imxfb. Thanks! Helge -- The following changes since commit 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5: Linux 6.5-rc1 (2023-07-09 13:53:13 -0700) are available in the Git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-6.5-rc3 for you to fetch changes up to e8812acb5bf724f2fc23a500e590c776ebda7b0a: fbdev: Explicitly include correct DT includes (2023-07-20 07:56:30 +0200) fbdev fixes and cleanups for 6.5-rc3: - Code cleanup in vgacon (Jiri Slaby) - Explicitly include correct DT includes (Rob Herring) - imxfb code cleanup (Yangtao Li, Martin Kaiser) - kyrofb: make arrays const and smaller (Colin Ian King) - ep93xx-fb: return value check fix (Yuanjun Gong) - au1200fb: add missing IRQ check (Zhang Shurong) Colin Ian King (1): fbdev: kyro: make some const read-only arrays static and reduce type size Jiri Slaby (SUSE) (7): vgacon: switch vgacon_scrolldelta() and vgacon_restore_screen() vgacon: remove unneeded forward declarations vgacon: remove unused xpos from vgacon_set_cursor_size() vgacon: let vgacon_doresize() return void vgacon: cache vc_cell_height in vgacon_cursor() sticon: make sticon_set_def_font() void and remove op parameter fbcon: remove unused display (p) from fbcon_redraw() Martin Kaiser (2): fbdev: imxfb: warn about invalid left/right margin fbdev: imxfb: switch to DEFINE_SIMPLE_DEV_PM_OPS Rob Herring (1): fbdev: Explicitly include correct DT includes Yangtao Li (4): fbdev: imxfb: Removed unneeded release_mem_region fbdev: imxfb: Convert to devm_kmalloc_array() fbdev: imxfb: Convert to devm_platform_ioremap_resource() fbdev: imxfb: remove unneeded labels Yuanjun Gong (1): fbdev: ep93xx-fb: fix return value check in ep93xxfb_probe Zhang Shurong (1): fbdev: au1200fb: Fix missing IRQ check in au1200fb_drv_probe drivers/video/console/sticon.c | 12 ++-- drivers/video/console/vgacon.c | 74 -- drivers/video/fbdev/au1200fb.c | 3 + drivers/video/fbdev/bw2.c | 3 +- drivers/video/fbdev/cg14.c | 3 +- drivers/video/fbdev/cg3.c | 3 +- drivers/video/fbdev/cg6.c | 3 +- drivers/video/fbdev/core/fbcon.c | 7 +- drivers/video/fbdev/ep93xx-fb.c| 4 +- drivers/video/fbdev/ffb.c | 3 +- drivers/video/fbdev/grvga.c| 3 +- drivers/video/fbdev/imxfb.c| 48 ++ drivers/video/fbdev/kyro/STG4000InitDevice.c | 10 +-- drivers/video/fbdev/leo.c | 3 +- drivers/video/fbdev/mb862xx/mb862xxfb_accel.c | 4 +- drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 6 +- .../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 2 +- drivers/video/fbdev/p9100.c| 3 +- drivers/video/fbdev/platinumfb.c | 4 +- drivers/video/fbdev/sbuslib.c | 2 +- drivers/video/fbdev/sunxvr1000.c | 3 +- drivers/video/fbdev/sunxvr2500.c | 2 +- drivers/video/fbdev/sunxvr500.c| 2 +- drivers/video/fbdev/tcx.c | 3 +- drivers/video/fbdev/xilinxfb.c | 5 +- 25 files changed, 97 insertions(+), 118 deletions(-)
Re: [v7,9/9] drm/i915/gt: Support aux invalidation on all engines
Hi Janusz,
> > diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > index 3ded597f002a2..30fb4e0af6134 100644
> > --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > @@ -165,9 +165,36 @@ static u32 preparser_disable(bool state)
> > return MI_ARB_CHECK | 1 << 8 | state;
> > }
> >
> > -u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const
> > i915_reg_t inv_reg)
> > +static i915_reg_t gen12_get_aux_inv_reg(struct intel_engine_cs *engine)
> > {
> > - u32 gsi_offset = gt->uncore->gsi_offset;
> > + if (!HAS_AUX_CCS(engine->i915))
> > + return INVALID_MMIO_REG;
> > +
> > + switch (engine->id) {
> > + case RCS0:
> > + return GEN12_CCS_AUX_INV;
> > + case BCS0:
> > + return GEN12_BCS0_AUX_INV;
> > + case VCS0:
> > + return GEN12_VD0_AUX_INV;
> > + case VCS2:
> > + return GEN12_VD2_AUX_INV;
> > + case VECS0:
> > + return GEN12_VE0_AUX_INV;
> > + case CCS0:
> > + return GEN12_CCS0_AUX_INV;
> > + default:
> > + return INVALID_MMIO_REG;
> > + }
> > +}
> > +
> > +u32 *gen12_emit_aux_table_inv(struct intel_engine_cs *engine, u32 *cs)
> > +{
> > + i915_reg_t inv_reg = gen12_get_aux_inv_reg(engine);
> > + u32 gsi_offset = engine->gt->uncore->gsi_offset;
> > +
> > + if (i915_mmio_reg_valid(inv_reg))
> > + return cs;
>
> Is that correct? Now the original body of gen12_emit_aux_table_inv() will be
> executed only if either (!HAS_AUX_CCS(engine->i915) or the engine is not one
> of (RCS0, BCS0, VCS0, VCS2 or CCS0), ...
>
> >
> > *cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
> > *cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
> > @@ -201,6 +228,11 @@ static u32 *intel_emit_pipe_control_cs(struct
> > i915_request *rq, u32 bit_group_0,
> > return cs;
> > }
> >
> > +static bool gen12_engine_has_aux_inv(struct intel_engine_cs *engine)
> > +{
> > + return i915_mmio_reg_valid(gen12_get_aux_inv_reg(engine));
> > +}
> > +
> > static int mtl_dummy_pipe_control(struct i915_request *rq)
> > {
> > /* Wa_14016712196 */
> > @@ -307,11 +339,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> > mode)
> >
> > cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
> >
> > - if (!HAS_FLAT_CCS(rq->engine->i915)) {
>
> ... while before it was executed only if (!HAS_FLAT_CCS(rq->engine->i915)),
> which, according to commit description of PATCH 2/9, rather had the opposite
> meaning. Am I missing something?
flat_ccs and aux_ccs are not mutually exclusive, so far the can
both miss like in PVC. So that the !HAS_FLAT_CCS() is an
approximation and that's why we need a better evaluation.
Aux invalidation is needed only on platforms from TGL and beyond
excluding PVC. The above engines are the only engines where AUX
invalidation happens, but there are no cases when we reach the
default condition, as the emit_flush_rcs is already called within
that set of engines. The default is there just for completeness.
Does this answer?
Thanks,
Andi
[PATCH v2 1/1] drm/i915: Move abs_diff() to math.h
abs_diff() belongs to math.h. Move it there.
This will allow others to use it.
Signed-off-by: Andy Shevchenko
---
v2: better header location on ipu-v3, converted omap-serial as well
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 7 ---
drivers/gpu/ipu-v3/ipu-image-convert.c| 15 +++
drivers/tty/serial/omap-serial.c | 7 +--
drivers/video/fbdev/core/svgalib.c| 7 +--
include/linux/math.h | 6 ++
6 files changed, 16 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 6b2d8a1e2aa9..290e856fe9e9 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -21,6 +21,7 @@
* DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include "i915_reg.h"
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
index ba62eb5d7c51..04e6810954b2 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
@@ -29,13 +29,6 @@
#include "intel_wakeref.h"
-/*FIXME: Move this to a more appropriate place. */
-#define abs_diff(a, b) ({ \
- typeof(a) __a = (a);\
- typeof(b) __b = (b);\
- (void) (&__a == &__b); \
- __a > __b ? (__a - __b) : (__b - __a); })
-
enum tc_port;
struct drm_i915_private;
struct intel_atomic_state;
diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c
b/drivers/gpu/ipu-v3/ipu-image-convert.c
index af1612044eef..841316582ea9 100644
--- a/drivers/gpu/ipu-v3/ipu-image-convert.c
+++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
@@ -7,7 +7,10 @@
#include
#include
+#include
+
#include
+
#include "ipu-prv.h"
/*
@@ -543,7 +546,7 @@ static void find_best_seam(struct ipu_image_convert_ctx
*ctx,
unsigned int in_pos;
unsigned int in_pos_aligned;
unsigned int in_pos_rounded;
- unsigned int abs_diff;
+ unsigned int diff;
/*
* Tiles in the right row / bottom column may not be allowed to
@@ -575,15 +578,11 @@ static void find_best_seam(struct ipu_image_convert_ctx
*ctx,
(in_edge - in_pos_rounded) % in_burst)
continue;
- if (in_pos < in_pos_aligned)
- abs_diff = in_pos_aligned - in_pos;
- else
- abs_diff = in_pos - in_pos_aligned;
-
- if (abs_diff < min_diff) {
+ diff = abs_diff(in_pos, in_pos_aligned);
+ if (diff < min_diff) {
in_seam = in_pos_rounded;
out_seam = out_pos;
- min_diff = abs_diff;
+ min_diff = diff;
}
}
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 82d35dbbfa6c..9be63a1f1f0c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -222,16 +222,11 @@ static inline int calculate_baud_abs_diff(struct
uart_port *port,
unsigned int baud, unsigned int mode)
{
unsigned int n = port->uartclk / (mode * baud);
- int abs_diff;
if (n == 0)
n = 1;
- abs_diff = baud - (port->uartclk / (mode * n));
- if (abs_diff < 0)
- abs_diff = -abs_diff;
-
- return abs_diff;
+ return abs_diff(baud, port->uartclk / (mode * n));
}
/*
diff --git a/drivers/video/fbdev/core/svgalib.c
b/drivers/video/fbdev/core/svgalib.c
index 9e01322fabe3..2cba15ea 100644
--- a/drivers/video/fbdev/core/svgalib.c
+++ b/drivers/video/fbdev/core/svgalib.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -372,12 +373,6 @@ EXPORT_SYMBOL(svga_get_caps);
* F_VCO = (F_BASE * M) / N
* F_OUT = F_VCO / (2^R)
*/
-
-static inline u32 abs_diff(u32 a, u32 b)
-{
- return (a > b) ? (a - b) : (b - a);
-}
-
int svga_compute_pll(const struct svga_pll *pll, u32 f_wanted, u16 *m, u16 *n,
u16 *r, int node)
{
u16 am, an, ar;
diff --git a/include/linux/math.h b/include/linux/math.h
index 449a29b73f6d..45a21b51f183 100644
--- a/include/linux/math.h
+++ b/include/linux/math.h
@@ -157,6 +157,12 @@ __STRUCT_FRACT(u32)
__builtin_types_compatible_p(typeof(x), unsigned type), \
({ signed type __x = (x); __x < 0 ? -__x : __x; }), other)
+#define abs_diff(a, b) ({ \
+ typeof(a) __a = (a);\
+ typeof(b) __b = (b);\
+ (void) (&__a == &__b); \
+ __a > __b ? (__a - __b) : (__b - __a); })
+
/**
*
Re: [PATCH v1 1/1] drm/i915: Move abs_diff() to math.h
On Fri, Jul 21, 2023 at 04:42:35PM +0300, Andy Shevchenko wrote: > abs_diff() belongs to math.h. Move it there. > This will allow others to use it. Sorry, forgot omap-serial case. Will be v2 soon. -- With Best Regards, Andy Shevchenko
[PATCH v1 1/1] drm/i915: Move abs_diff() to math.h
abs_diff() belongs to math.h. Move it there.
This will allow others to use it.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 7 ---
drivers/gpu/ipu-v3/ipu-image-convert.c| 14 ++
drivers/video/fbdev/core/svgalib.c| 7 +--
include/linux/math.h | 6 ++
5 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 6b2d8a1e2aa9..290e856fe9e9 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -21,6 +21,7 @@
* DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include "i915_reg.h"
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
index ba62eb5d7c51..04e6810954b2 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
@@ -29,13 +29,6 @@
#include "intel_wakeref.h"
-/*FIXME: Move this to a more appropriate place. */
-#define abs_diff(a, b) ({ \
- typeof(a) __a = (a);\
- typeof(b) __b = (b);\
- (void) (&__a == &__b); \
- __a > __b ? (__a - __b) : (__b - __a); })
-
enum tc_port;
struct drm_i915_private;
struct intel_atomic_state;
diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c
b/drivers/gpu/ipu-v3/ipu-image-convert.c
index af1612044eef..420992ac2ecd 100644
--- a/drivers/gpu/ipu-v3/ipu-image-convert.c
+++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+
#include "ipu-prv.h"
/*
@@ -543,7 +545,7 @@ static void find_best_seam(struct ipu_image_convert_ctx
*ctx,
unsigned int in_pos;
unsigned int in_pos_aligned;
unsigned int in_pos_rounded;
- unsigned int abs_diff;
+ unsigned int diff;
/*
* Tiles in the right row / bottom column may not be allowed to
@@ -575,15 +577,11 @@ static void find_best_seam(struct ipu_image_convert_ctx
*ctx,
(in_edge - in_pos_rounded) % in_burst)
continue;
- if (in_pos < in_pos_aligned)
- abs_diff = in_pos_aligned - in_pos;
- else
- abs_diff = in_pos - in_pos_aligned;
-
- if (abs_diff < min_diff) {
+ diff = abs_diff(in_pos, in_pos_aligned);
+ if (diff < min_diff) {
in_seam = in_pos_rounded;
out_seam = out_pos;
- min_diff = abs_diff;
+ min_diff = diff;
}
}
diff --git a/drivers/video/fbdev/core/svgalib.c
b/drivers/video/fbdev/core/svgalib.c
index 9e01322fabe3..2cba15ea 100644
--- a/drivers/video/fbdev/core/svgalib.c
+++ b/drivers/video/fbdev/core/svgalib.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -372,12 +373,6 @@ EXPORT_SYMBOL(svga_get_caps);
* F_VCO = (F_BASE * M) / N
* F_OUT = F_VCO / (2^R)
*/
-
-static inline u32 abs_diff(u32 a, u32 b)
-{
- return (a > b) ? (a - b) : (b - a);
-}
-
int svga_compute_pll(const struct svga_pll *pll, u32 f_wanted, u16 *m, u16 *n,
u16 *r, int node)
{
u16 am, an, ar;
diff --git a/include/linux/math.h b/include/linux/math.h
index 449a29b73f6d..45a21b51f183 100644
--- a/include/linux/math.h
+++ b/include/linux/math.h
@@ -157,6 +157,12 @@ __STRUCT_FRACT(u32)
__builtin_types_compatible_p(typeof(x), unsigned type), \
({ signed type __x = (x); __x < 0 ? -__x : __x; }), other)
+#define abs_diff(a, b) ({ \
+ typeof(a) __a = (a);\
+ typeof(b) __b = (b);\
+ (void) (&__a == &__b); \
+ __a > __b ? (__a - __b) : (__b - __a); })
+
/**
* reciprocal_scale - "scale" a value into range [0, ep_ro)
* @val: value
--
2.40.0.1.gaa8946217a0b
Re: [v7,9/9] drm/i915/gt: Support aux invalidation on all engines
Hi Andi,
On Thursday, 20 July 2023 23:07:37 CEST Andi Shyti wrote:
> Perform some refactoring with the purpose of keeping in one
> single place all the operations around the aux table
> invalidation.
>
> With this refactoring add more engines where the invalidation
> should be performed.
>
> Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all
> engines")
> Signed-off-by: Andi Shyti
> Cc: Jonathan Cavitt
> Cc: Matt Roper
> Cc: # v5.8+
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 58 +++-
> drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 3 +-
> drivers/gpu/drm/i915/gt/intel_lrc.c | 17 +--
> 3 files changed, 41 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 3ded597f002a2..30fb4e0af6134 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -165,9 +165,36 @@ static u32 preparser_disable(bool state)
> return MI_ARB_CHECK | 1 << 8 | state;
> }
>
> -u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t
> inv_reg)
> +static i915_reg_t gen12_get_aux_inv_reg(struct intel_engine_cs *engine)
> {
> - u32 gsi_offset = gt->uncore->gsi_offset;
> + if (!HAS_AUX_CCS(engine->i915))
> + return INVALID_MMIO_REG;
> +
> + switch (engine->id) {
> + case RCS0:
> + return GEN12_CCS_AUX_INV;
> + case BCS0:
> + return GEN12_BCS0_AUX_INV;
> + case VCS0:
> + return GEN12_VD0_AUX_INV;
> + case VCS2:
> + return GEN12_VD2_AUX_INV;
> + case VECS0:
> + return GEN12_VE0_AUX_INV;
> + case CCS0:
> + return GEN12_CCS0_AUX_INV;
> + default:
> + return INVALID_MMIO_REG;
> + }
> +}
> +
> +u32 *gen12_emit_aux_table_inv(struct intel_engine_cs *engine, u32 *cs)
> +{
> + i915_reg_t inv_reg = gen12_get_aux_inv_reg(engine);
> + u32 gsi_offset = engine->gt->uncore->gsi_offset;
> +
> + if (i915_mmio_reg_valid(inv_reg))
> + return cs;
Is that correct? Now the original body of gen12_emit_aux_table_inv() will be
executed only if either (!HAS_AUX_CCS(engine->i915) or the engine is not one
of (RCS0, BCS0, VCS0, VCS2 or CCS0), ...
>
> *cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
> *cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
> @@ -201,6 +228,11 @@ static u32 *intel_emit_pipe_control_cs(struct
> i915_request *rq, u32 bit_group_0,
> return cs;
> }
>
> +static bool gen12_engine_has_aux_inv(struct intel_engine_cs *engine)
> +{
> + return i915_mmio_reg_valid(gen12_get_aux_inv_reg(engine));
> +}
> +
> static int mtl_dummy_pipe_control(struct i915_request *rq)
> {
> /* Wa_14016712196 */
> @@ -307,11 +339,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> mode)
>
> cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
>
> - if (!HAS_FLAT_CCS(rq->engine->i915)) {
... while before it was executed only if (!HAS_FLAT_CCS(rq->engine->i915)),
which, according to commit description of PATCH 2/9, rather had the opposite
meaning. Am I missing something?
Thanks,
Janusz
> - /* hsdes: 1809175790 */
> - cs = gen12_emit_aux_table_inv(rq->engine->gt, cs,
> - GEN12_CCS_AUX_INV);
> - }
> + cs = gen12_emit_aux_table_inv(engine, cs);
>
> *cs++ = preparser_disable(false);
> intel_ring_advance(rq, cs);
> @@ -322,7 +350,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> mode)
>
> int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
> {
> - intel_engine_mask_t aux_inv = 0;
> u32 cmd_flush = 0;
> u32 cmd = 4;
> u32 *cs;
> @@ -330,15 +357,11 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32
> mode)
> if (mode & EMIT_INVALIDATE)
> cmd += 2;
>
> - if (HAS_AUX_CCS(rq->engine->i915))
> - aux_inv = rq->engine->mask &
> - ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
> -
> /*
>* On Aux CCS platforms the invalidation of the Aux
>* table requires quiescing memory traffic beforehand
>*/
> - if (aux_inv) {
> + if (gen12_engine_has_aux_inv(rq->engine)) {
> cmd += 8; /* for the AUX invalidation */
> cmd += 2; /* for the engine quiescing */
>
> @@ -381,14 +404,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32
> mode)
> *cs++ = 0; /* upper addr */
> *cs++ = 0; /* value */
>
> - if (aux_inv) { /* hsdes: 1809175790 */
> - if (rq->engine->class == VIDEO_DECODE_CLASS)
> - cs = gen12_emit_aux_table_inv(rq->engine->gt,
> - cs, GEN12_VD0_AUX_INV);
> - else
> -
Re: [PATCH] drm/bridge: Add debugfs print for bridge chains
Hi Tomi,
kernel test robot noticed the following build errors:
[auto build test ERROR on c7a472297169156252a50d76965eb36b081186e2]
url:
https://github.com/intel-lab-lkp/linux/commits/Tomi-Valkeinen/drm-bridge-Add-debugfs-print-for-bridge-chains/20230721-174615
base: c7a472297169156252a50d76965eb36b081186e2
patch link:
https://lore.kernel.org/r/20230721-drm-bridge-chain-debugfs-v1-1-8614ff7e890d%40ideasonboard.com
patch subject: [PATCH] drm/bridge: Add debugfs print for bridge chains
config: x86_64-randconfig-r032-20230720
(https://download.01.org/0day-ci/archive/20230721/202307212102.fxrv1ayx-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce:
(https://download.01.org/0day-ci/archive/20230721/202307212102.fxrv1ayx-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202307212102.fxrv1ayx-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/drm_bridge.c: In function 'drm_bridge_chains_info':
>> drivers/gpu/drm/drm_bridge.c:1371:35: error: 'struct drm_bridge' has no
>> member named 'of_node'
1371 | if (bridge->of_node)
| ^~
drivers/gpu/drm/drm_bridge.c:1372:70: error: 'struct drm_bridge' has no
member named 'of_node'
1372 | drm_printf(, ", OF: %pOFfc",
bridge->of_node);
|
^~
vim +1371 drivers/gpu/drm/drm_bridge.c
1349
1350 #ifdef CONFIG_DEBUG_FS
1351 static int drm_bridge_chains_info(struct seq_file *m, void *data)
1352 {
1353 struct drm_debugfs_entry *entry = m->private;
1354 struct drm_device *dev = entry->dev;
1355 struct drm_printer p = drm_seq_file_printer(m);
1356 struct drm_mode_config *config = >mode_config;
1357 struct drm_encoder *encoder;
1358 unsigned int bridge_idx = 0;
1359
1360 list_for_each_entry(encoder, >encoder_list, head) {
1361 struct drm_bridge *bridge;
1362
1363 drm_printf(, "encoder[%u]\n", encoder->base.id);
1364
1365 bridge = drm_bridge_chain_get_first_bridge(encoder);
1366
1367 while (bridge) {
1368 drm_printf(, "\tbridge[%u] type: %u, ops:
%#x",
1369 bridge_idx, bridge->type,
bridge->ops);
1370
> 1371 if (bridge->of_node)
1372 drm_printf(, ", OF: %pOFfc",
bridge->of_node);
1373
1374 drm_printf(, "\n");
1375
1376 bridge_idx++;
1377 bridge = drm_bridge_get_next_bridge(bridge);
1378 }
1379 }
1380
1381 return 0;
1382 }
1383
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
[PATCH] drm/amd/display: set stream gamut remap matrix to MPC for DCN3+
dc->caps.color.mpc.gamut_remap says there is a post-blending color block
for gamut remap matrix for DCN3 HW family and newer versions. However,
those drivers still follow DCN10 programming that remap stream
gamut_remap_matrix to DPP (pre-blending).
To enable pre-blending and post-blending gamut_remap matrix supports at
the same time, set stream gamut_remap to MPC and plane gamut_remap to
DPP for DCN families that support both.
It was tested using IGT KMS color tests for DRM CRTC CTM property and it
preserves test results.
Signed-off-by: Melissa Wen
---
Hi,
Two relevant things to consider for this change. One is that mapping DRM
CRTC CTM to MPC is a more consistent way since CRTC CTM is a
post-blending transformation. Second, programming stream
gamut_remap_matrix on MPC enables us to provide support for both plane
CTM and CRTC CTM color properties. If we don't make this separation, we
would need to reject an atomic commit that tries to set both properties
at the same time and userspace may also get unexpected results.
Thanks in advance for any feeback,
Melissa
.../drm/amd/display/dc/dcn30/dcn30_hwseq.c| 37 +++
.../drm/amd/display/dc/dcn30/dcn30_hwseq.h| 3 ++
.../gpu/drm/amd/display/dc/dcn30/dcn30_init.c | 2 +-
.../drm/amd/display/dc/dcn301/dcn301_init.c | 2 +-
.../gpu/drm/amd/display/dc/dcn31/dcn31_init.c | 2 +-
.../drm/amd/display/dc/dcn314/dcn314_init.c | 2 +-
.../gpu/drm/amd/display/dc/dcn32/dcn32_init.c | 2 +-
7 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
index 4cd4ae07d73d..4fb4e9ec03f1 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
@@ -186,6 +186,43 @@ bool dcn30_set_input_transfer_func(struct dc *dc,
return result;
}
+void dcn30_program_gamut_remap(struct pipe_ctx *pipe_ctx)
+{
+ int i = 0;
+ struct dpp_grph_csc_adjustment dpp_adjust;
+ struct mpc_grph_gamut_adjustment mpc_adjust;
+ int mpcc_id = pipe_ctx->plane_res.hubp->inst;
+ struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc;
+
+ memset(_adjust, 0, sizeof(dpp_adjust));
+ dpp_adjust.gamut_adjust_type = GRAPHICS_GAMUT_ADJUST_TYPE_BYPASS;
+
+ if (pipe_ctx->plane_state &&
+ pipe_ctx->plane_state->gamut_remap_matrix.enable_remap == true) {
+ dpp_adjust.gamut_adjust_type = GRAPHICS_GAMUT_ADJUST_TYPE_SW;
+ for (i = 0; i < CSC_TEMPERATURE_MATRIX_SIZE; i++)
+ dpp_adjust.temperature_matrix[i] =
+
pipe_ctx->plane_state->gamut_remap_matrix.matrix[i];
+ }
+
+
pipe_ctx->plane_res.dpp->funcs->dpp_set_gamut_remap(pipe_ctx->plane_res.dpp,
+ _adjust);
+
+ memset(_adjust, 0, sizeof(mpc_adjust));
+ mpc_adjust.gamut_adjust_type = GRAPHICS_GAMUT_ADJUST_TYPE_BYPASS;
+
+ if (pipe_ctx->top_pipe == NULL) {
+ if (pipe_ctx->stream->gamut_remap_matrix.enable_remap == true) {
+ mpc_adjust.gamut_adjust_type =
GRAPHICS_GAMUT_ADJUST_TYPE_SW;
+ for (i = 0; i < CSC_TEMPERATURE_MATRIX_SIZE; i++)
+ mpc_adjust.temperature_matrix[i] =
+
pipe_ctx->stream->gamut_remap_matrix.matrix[i];
+ }
+ }
+
+ mpc->funcs->set_gamut_remap(mpc, mpcc_id, _adjust);
+}
+
bool dcn30_set_output_transfer_func(struct dc *dc,
struct pipe_ctx *pipe_ctx,
const struct dc_stream_state *stream)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.h
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.h
index a24a8e33a3d2..cb34ca932a5f 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.h
@@ -58,6 +58,9 @@ bool dcn30_set_blend_lut(struct pipe_ctx *pipe_ctx,
bool dcn30_set_input_transfer_func(struct dc *dc,
struct pipe_ctx *pipe_ctx,
const struct dc_plane_state *plane_state);
+
+void dcn30_program_gamut_remap(struct pipe_ctx *pipe_ctx);
+
bool dcn30_set_output_transfer_func(struct dc *dc,
struct pipe_ctx *pipe_ctx,
const struct dc_stream_state *stream);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_init.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_init.c
index 3d19acaa12f3..5372eb76fcfc 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_init.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_init.c
@@ -32,7 +32,7 @@
#include "dcn30_init.h"
static const struct hw_sequencer_funcs dcn30_funcs = {
- .program_gamut_remap = dcn10_program_gamut_remap,
+ .program_gamut_remap =
[PATCH] drm/i915: Use the i915_vma_flush_writes helper
From: Tvrtko Ursulin
We can use the existing helper in flush_write_domain() and save some lines
of code.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index dfaaa8b66ac3..ffddec1d2a76 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -68,10 +68,8 @@ flush_write_domain(struct drm_i915_gem_object *obj, unsigned
int flush_domains)
switch (obj->write_domain) {
case I915_GEM_DOMAIN_GTT:
spin_lock(>vma.lock);
- for_each_ggtt_vma(vma, obj) {
- if (i915_vma_unset_ggtt_write(vma))
- intel_gt_flush_ggtt_writes(vma->vm->gt);
- }
+ for_each_ggtt_vma(vma, obj)
+ i915_vma_flush_writes(vma);
spin_unlock(>vma.lock);
i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
--
2.39.2
Re: [PATCH v3] drm/i915: Refactor PAT/object cache handling
On 21/07/2023 05:28, Yang, Fei wrote:
[snip]
@@ -27,15 +28,8 @@ static bool gpu_write_needs_clflush(struct
drm_i915_gem_object *obj)
The code change here looks accurate, but while we're here, I have a
side question about this function in general...it was originally
introduced in commit 48004881f693 ("drm/i915: Mark CPU cache as
dirty when used for
rendering") which states that GPU rendering ends up in the CPU cache
(and thus needs a clflush later to make sure it lands in memory).
That makes sense to me for LLC platforms, but is it really true for
non-LLC snooping platforms (like MTL) as the commit states?
For non-LLC platforms objects can be set to 1-way coherent which
means GPU rendering ending up in CPU cache as well, so for non-LLC
platform the logic here should be checking 1-way coherent flag.
That's the part that I'm questioning (and not just for MTL, but for
all of our other non-LLC platforms too). Just because there's
coherency doesn't mean that device writes landed in the CPU cache.
Coherency is also achieved if device writes invalidate the contents of the CPU
cache.
I thought our non-LLC snooping platforms were coherent due to
write-invalidate rather than write-update, but I can't find it
specifically documented anywhere at the moment. If write-invalidate
was used, then there shouldn't be a need for a later clflush either.
[Trying to consolidate by doing a combined reply to the discussion so far.]
On the write-invalidate vs write-update I don't know. If you did not
find it in bspec then I doubt I would. I can have a browse still.
Matt was correct. Quote Ron Silvas from SW ARCH, "MTL GPU doesn't write to
CPU cache, it simply snoop CPU cache on its way to RAM."
Does it apply to all snooping platforms?
And for the cache level/mode based condition, how about replacing it with this:
/*
* Fully coherent cached access may end up with data in the CPU cache
* which hasn't hit memory yet.
*/
return i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_WB) &&
i915_gem_object_has_cache_flag(obj, I915_CACHE_FLAG_COH2W);
?
Although that would mean old I915_CACHE_LLC on old platforms is actually 2-way
coherent.
I am struggling to find a comprehensive explanation in bspec, but for instance
605 makes it sounds like it is fully coherent. Perhaps it really is and I
should fix the legacy and Gen12 table..
And if the write-invalidate applies to all snooping platforms then we extend it
to:
/*
* Fully coherent cached access may end up with data in the CPU cache
* which hasn't hit memory yet.
*
* But not on snooping platforms, where it is impossible due
* write-invalidate.
*/
return !HAS_SNOOP(i915) &&
(i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_WB) &&
i915_gem_object_has_cache_flag(obj, I915_CACHE_FLAG_COH2W));
That would prevent any flushing on MTL and make you happy from that aspect.
In fact, the snooping check could be before the cache mode check.
For i915_gem_object_can_bypass_llc it would be ideal if a condition based on
the absence of I915_BO_CACHE_COHERENT_FOR_WRITE would work. At least according
to the kerneldoc for @cache_coherent:
* I915_BO_CACHE_COHERENT_FOR_WRITE:
*
* When writing through the CPU cache, the GPU is still coherent. Note
* that this also implies I915_BO_CACHE_COHERENT_FOR_READ.
So for objects without it set, we need to force a flush.
And make __i915_gem_object_update_coherency not set it for WB without 1-way
coherency set.
According to bspec that would seem correct, because with 1-way snooping on MTL,
GPU snoops the IA until first GPU access. So anything the CPU writes before the
first GPU access would be coherent and so no need to flush in set pages. But if
non-coherent WB is set then we need to flush.
I'll trybot it is and see what happens.
My understanding
was that snooping platforms just invalidated the CPU cache to
prevent future CPU reads from seeing stale data but didn't actually
stick any new data in there? Am I off track or is the original
logic of this function not quite right?
Anyway, even if the logic of this function is wrong, it's a mistake
that would only hurt performance
Yes, this logic will introduce performance impact because it's
missing the checking for obj->pat_set_by_user. For objects with
pat_set_by_user==true, even if the object is snooping or 1-way
coherent, we don't want to enforce a clflush here since the
coherency is supposed to be handled by user space.
What should I add you think to fix it?
I think the simplest would be
if (obj->pat_set_by_user)
return false;
because even checking for incoherent WB is unnecessary, simply no
need for the KMD to initiate a flush if PAT is set by user.
Add a check for non-coherent WB in gpu_write_needs_clflush as an additional
condition for returning
Re: [v7, 7/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines
Hi Janusz,
On Fri, Jul 21, 2023 at 12:10:22PM +, Krzysztofik, Janusz wrote:
> Hi Andi,
>
> On Thursday, 20 July 2023 23:07:35 CEST Andi Shyti wrote:
> > Commit af9e423a8aae
>
> You can't use this commit ID, it is invalid (the patch you are referring to
> belongs to your series, then is not available in any official repository,
> hence no stable commit ID yet).
yes, I need to update it, I know... this has changed at every
revision, but I was lazy and decided to do it at the end after
the whole review process was done. I didn't think that anyone
would go and check it :-D
It's good to know that there is a thorough review here! Thanks!
> > ("drm/i915/gt: Ensure memory quiesced before
> > invalidation") has made sure that the memory is quiesced before
> > invalidating the AUX CCS table. Do it for all the other engines
> > and not just RCS.
>
> Why do we need that now for other engines, while that former patch seemed to
> suggest we didn't?
This whole work started from a a couple of patches from Jonathan
and slowly exploded in this series of 9 patches. I tried to
preserve his work and just add things around them.
What Jonathan originally did was to add aux invalidation support
only for RCS and Compute engines, but then hardware guys updated
the docs asking to do it for basically all the engines.
Thank you,
Andi
[PATCH] drm: bridge: dw_hdmi: Add cec suspend/resume functions
CEC interrupt status/mask and logical address registers
will be reset when device enter suspend.
It will cause cec fail to work after device resume.
Add CEC suspend/resume functions, reinitialize logical address registers
and restore interrupt status/mask registers after resume.
Signed-off-by: Sandor Yu
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 37 +++
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
index 9389ce526eb13..be21c11de1f2a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
@@ -62,6 +62,10 @@ struct dw_hdmi_cec {
bool rx_done;
struct cec_notifier *notify;
int irq;
+
+ u8 regs_polarity;
+ u8 regs_mask;
+ u8 regs_mute_stat0;
};
static void dw_hdmi_write(struct dw_hdmi_cec *cec, u8 val, int offset)
@@ -304,11 +308,44 @@ static void dw_hdmi_cec_remove(struct platform_device
*pdev)
cec_unregister_adapter(cec->adap);
}
+static int __maybe_unused dw_hdmi_cec_resume(struct device *dev)
+{
+ struct dw_hdmi_cec *cec = dev_get_drvdata(dev);
+
+ /* Restore logical address */
+ dw_hdmi_write(cec, cec->addresses & 255, HDMI_CEC_ADDR_L);
+ dw_hdmi_write(cec, cec->addresses >> 8, HDMI_CEC_ADDR_H);
+
+ /* Restore interrupt status/mask registers */
+ dw_hdmi_write(cec, cec->regs_polarity, HDMI_CEC_POLARITY);
+ dw_hdmi_write(cec, cec->regs_mask, HDMI_CEC_MASK);
+ dw_hdmi_write(cec, cec->regs_mute_stat0, HDMI_IH_MUTE_CEC_STAT0);
+
+ return 0;
+}
+
+static int __maybe_unused dw_hdmi_cec_suspend(struct device *dev)
+{
+ struct dw_hdmi_cec *cec = dev_get_drvdata(dev);
+
+ /* store interrupt status/mask registers */
+cec->regs_polarity = dw_hdmi_read(cec, HDMI_CEC_POLARITY);
+cec->regs_mask = dw_hdmi_read(cec, HDMI_CEC_MASK);
+cec->regs_mute_stat0 = dw_hdmi_read(cec, HDMI_IH_MUTE_CEC_STAT0);
+
+ return 0;
+}
+
+static const struct dev_pm_ops dw_hdmi_cec_pm = {
+ SET_SYSTEM_SLEEP_PM_OPS(dw_hdmi_cec_suspend, dw_hdmi_cec_resume)
+};
+
static struct platform_driver dw_hdmi_cec_driver = {
.probe = dw_hdmi_cec_probe,
.remove_new = dw_hdmi_cec_remove,
.driver = {
.name = "dw-hdmi-cec",
+ .pm = _hdmi_cec_pm,
},
};
module_platform_driver(dw_hdmi_cec_driver);
--
2.34.1
Re: [PATCH 6/9] drm/verisilicon: Add drm crtc funcs
Hi Keith,
On Fri, Jul 21, 2023 at 07:57:24PM +0800, Keith Zhao wrote:
> >> +
> >> +struct vs_crtc_funcs {
> >> + void (*enable)(struct device *dev, struct drm_crtc *crtc);
> >> + void (*disable)(struct device *dev, struct drm_crtc *crtc);
> >> + bool (*mode_fixup)(struct device *dev,
> >> + const struct drm_display_mode *mode,
> >> + struct drm_display_mode *adjusted_mode);
> >> + void (*set_gamma)(struct device *dev, struct drm_crtc *crtc,
> >> + struct drm_color_lut *lut, unsigned int size);
> >> + void (*enable_gamma)(struct device *dev, struct drm_crtc *crtc,
> >> + bool enable);
> >> + void (*enable_vblank)(struct device *dev, bool enable);
> >> + void (*commit)(struct device *dev);
> >> +};
> >
> > Why is this here? You are reproducing our interface with an internal
> > interface. I know where this leads to: you have multiple chipset revisions
> > and each has its own implemenation of these internal interfaces.
> >
> > That will absolutely come back to haunt you in the long rung: the more chip
> > revisions you support, the more obscure these internal interfaces and
> > implentations become. And you won't be able to change these callbacks, as
> > that affects all revisions. We've seen this with a few drivers. It will
> > become unmaintainable.
> >
> > A better approach is to treat DRM's atomic callback funcs and atomic helper
> > funcs as your interface for each chip revision. So for each model, you
> > implement a separate modesetting pipeline. When you add a new chip
> > revision, you copy the previous chip's code into a new file and adopt it.
> > If you find comon code among individual revisions, you can put it into a
> > shared helper. With this design, each chip revision stands on its own.
> >
> > I suggest to study the mgag200 driver. It detects the chip revision very
> > early and builds a chip-specific modesetting pipline. Although each chip is
> > handled separately, a lot of shared code is in helpers. So the size of the
> > driver remains small.
> >
> hi Thomas:
> I'm trying to understand what you're thinking
I am not Thomas, but let me try to put a few words on this.
> 1. Different chip ids should have their own independent drm_dev, and should
> not be supported based on a same drm_dev.
Yes, this part is correct understood.
> 2. diff chip id , for example dc8200 , dc9000,
>
> struct vs_crtc_funcs {
> void (*enable)(struct device *dev, struct drm_crtc *crtc);
> void (*disable)(struct device *dev, struct drm_crtc *crtc);
> bool (*mode_fixup)(struct device *dev,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode);
> void (*set_gamma)(struct device *dev, struct drm_crtc *crtc,
> struct drm_color_lut *lut, unsigned int size);
> void (*enable_gamma)(struct device *dev, struct drm_crtc *crtc,
>bool enable);
> void (*enable_vblank)(struct device *dev, bool enable);
> void (*commit)(struct device *dev);
> };
No - the idea is that you populate crtc_funcs direct.
Drop struct vs_crtc_funcs - just fill out your own crtc_funcs structure.
If it turns out that most of the crtc operations are the same then share
them. Avoid the extra layer of indirection that you have with struct
vs_crtc_funcs
as this is not needed when you use the pattern described by Thomas.
> static const struct vs_crtc_funcs vs_dc8200_crtc_funcs = {...}
> static const struct vs_crtc_funcs vs_dc9200_crtc_funcs = {...}
>
> struct vs_drm_private {
> struct drm_device base;
> struct device *dma_dev;
> struct iommu_domain *domain;
> unsigned int pitch_alignment;
This parts looks fine.
>
> const struct vs_crtc_funcs *funcs;
No, here you need a pointer to struct crtc_funcs or a struct that embeds
crtc_funcs.
> };
If you, after reading this, thinks you need struct vs_crtc_funcs, then
try to take an extra look at mgag200. It is not needed.
I hope this helps.
Sam
Re: [PATCH v3 1/2] dt-bindings: display: add bindings for pcd8544 displays
On Fri, Jul 21, 2023 at 11:42 AM Krzysztof Kozlowski wrote: > > On 20/07/2023 14:40, Viktar Simanenka wrote: > > +allOf: > > + - $ref: panel/panel-common.yaml# > > This is not a panel, is it? I can't clearly tell the difference between LCD display and panel. I've added panel-common because of 'backlight' and 'reset-gpios' properties. I've looked at 'sitronix,st7735r.yaml', 'ilitek,ili9486.yaml' as examples. SPI controlled LCD displays, but in color. In fact 'reset-gpios' is already in my yaml. I might just add the 'backlight' property explicitly and remove this dependency. Should I?
[PATCH -next] drm/fb-helper: Remove unused inline function drm_fb_helper_defio_init()
Since commit 8e86dee02253 ("drm/fb-helper: Remove drm_fb_helper_defio_init()
and update docs")
this inline helper not used anymore.
Signed-off-by: YueHaibing
---
include/drm/drm_fb_helper.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 4863b0f8299e..375737fd6c36 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -368,11 +368,6 @@ static inline void drm_fb_helper_deferred_io(struct
fb_info *info,
{
}
-static inline int drm_fb_helper_defio_init(struct drm_fb_helper *fb_helper)
-{
- return -ENODEV;
-}
-
static inline void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper,
bool suspend)
{
--
2.34.1
[Bug 217692] New: amdgpu crashes on resume from standby - amdgpu-reset-dev drm_sched_job_timedout
https://bugzilla.kernel.org/show_bug.cgi?id=217692 Bug ID: 217692 Summary: amdgpu crashes on resume from standby - amdgpu-reset-dev drm_sched_job_timedout Product: Drivers Version: 2.5 Hardware: AMD OS: Linux Status: NEW Severity: normal Priority: P3 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: ture...@gmail.com Regression: No Created attachment 304679 --> https://bugzilla.kernel.org/attachment.cgi?id=304679=edit Single log with dmesg joined with suspend + resume log until crash Kernel version: 6.4.3-2-MANJARO #1 SMP PREEMPT_DYNAMIC Sun Jul 16 16:55:12 UTC 2023 x86_64 GNU/Linux Suspend took longer than usual and after resume by pressing a key on keyboard, screen did not turn on. A hopefully relevant part of trace (attached complete): Jul 20 21:44:50 too-pc kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=1605372, emitted seq=1605374 Jul 20 21:44:50 too-pc kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0 Jul 20 21:44:50 too-pc kernel: amdgpu :2f:00.0: amdgpu: GPU reset begin! Jul 20 21:44:51 too-pc systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully. Jul 20 21:44:54 too-pc kernel: amdgpu :2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x003A SMN_C2PMSG_82:0x Jul 20 21:44:54 too-pc kernel: amdgpu :2f:00.0: amdgpu: Failed to retrieve enabled ppfeatures! Jul 20 21:44:58 too-pc kernel: amdgpu :2f:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x003A SMN_C2PMSG_82:0x Jul 20 21:44:58 too-pc kernel: amdgpu :2f:00.0: amdgpu: Failed to retrieve enabled ppfeatures! Jul 20 21:45:02 too-pc kernel: amdgpu :2f:00.0: amdgpu: failed to suspend display audio Jul 20 21:45:02 too-pc kernel: amdgpu :2f:00.0: amdgpu: Failed to disallow df cstate Jul 20 21:45:02 too-pc kernel: [ cut here ] Jul 20 21:45:02 too-pc kernel: WARNING: CPU: 24 PID: 574073 at drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:599 amdgpu_irq_put+0x46/0x70 [amdgpu] Jul 20 21:45:02 too-pc kernel: Modules linked in: tls vhost_net vhost vhost_iotlb tap tun dm_crypt cbc encrypted_keys trusted asn1_encoder tee xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c x t_addrtype iptable_filter br_netfilter snd_seq_dummy snd_hrtimer snd_seq bridge stp llc rfkill qrtr overlay uvcvideo videobuf2_vmalloc uvc videobuf2_memops snd_usb_audio videobuf2_v4l2 snd_usbmidi_lib videodev uas snd_rawmidi videobuf2_common snd_seq_device mousedev mc joyd ev vfat fat intel_rapl_msr intel_rapl_common edac_mce_amd kvm_amd snd_hda_codec_realtek ccp snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel kvm snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec crct10dif_pclmul crc32_pclmul polyval_clmulni snd_hda_core polyval_generic gf128mul snd_hwdep r8169 ghash_clmulni_intel snd_pcm sha512_ssse3 aesni_intel snd_timer crypto_simd wmi_bmof sp5100_tco realtek cryptd snd rapl mdio_devres pcspkr soundcore k10temp i2c_piix4 libphy ryzen_smu(OE) Jul 20 21:45:02 too-pc kernel: mac_hid uinput i2c_dev dm_multipath fuse crypto_user dm_mod loop bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 usb_storage usbhid crc32c_intel nvme xhci_pci nvme_core xhci_pci_renesas nvme_common vfio_pci vfio_pci_core irqbypass vfio_iommu_type1 vfio iommufd amdgpu i2c_algo_bit drm_ttm_helper ttm video wmi drm_suballoc_helper drm_buddy gpu_sched drm_display_helper cec Jul 20 21:45:02 too-pc kernel: CPU: 24 PID: 574073 Comm: kworker/u64:25 Tainted: GW OE 6.4.3-2-MANJARO #1 00e85e278f33e769813ea7ae6ba8e625d37e2fac Jul 20 21:45:02 too-pc kernel: Hardware name: Micro-Star International Co., Ltd. MS-7C37/MPG X570 GAMING PLUS (MS-7C37), BIOS A.I0 08/10/2022 Jul 20 21:45:02 too-pc kernel: Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched] Jul 20 21:45:02 too-pc kernel: RIP: 0010:amdgpu_irq_put+0x46/0x70 [amdgpu] Jul 20 21:45:02 too-pc kernel: Code: c0 74 33 48 8b 4e 10 48 83 39 00 74 29 89 d1 48 8d 04 88 8b 08 85 c9 74 11 f0 ff 08 74 07 31 c0 e9 8f c5 ae f0 e9 5a fd ff ff <0f> 0b b8 ea ff ff ff e9 7e c5 ae f0 b8 ea ff ff ff e9 74 c5 ae f0 Jul 20 21:45:02 too-pc kernel: RSP: 0018:a87787687c98 EFLAGS: 00010246 Jul 20 21:45:02 too-pc kernel: RAX: 9c5f5233c980 RBX: 9c5f546c RCX: Jul 20 21:45:02 too-pc kernel: RDX: RSI: 9c5f546d9250 RDI: 9c5f546c Jul 20 21:45:02 too-pc kernel: RBP: 9c5f546c R08: 0003ac80 R09: 0006 Jul 20 21:45:02 too-pc kernel: R10: 0100 R11: R12: 1050 Jul 20 21:45:02 too-pc kernel: R13: 9c5f546e5d70 R14:
Re: [v7, 7/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines
Hi Andi,
On Thursday, 20 July 2023 23:07:35 CEST Andi Shyti wrote:
> Commit af9e423a8aae
You can't use this commit ID, it is invalid (the patch you are referring to
belongs to your series, then is not available in any official repository,
hence no stable commit ID yet).
> ("drm/i915/gt: Ensure memory quiesced before
> invalidation") has made sure that the memory is quiesced before
> invalidating the AUX CCS table. Do it for all the other engines
> and not just RCS.
Why do we need that now for other engines, while that former patch seemed to
suggest we didn't?
Thanks,
Janusz
>
> Signed-off-by: Andi Shyti
> Cc: Jonathan Cavitt
> Cc: Matt Roper
> Cc: # v5.8+
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 36
> 1 file changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 202d6ff8b5264..b6dd22eb2d9b2 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -316,26 +316,40 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> mode)
> int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
> {
> intel_engine_mask_t aux_inv = 0;
> - u32 cmd, *cs;
> + u32 cmd_flush = 0;
> + u32 cmd = 4;
> + u32 *cs;
>
> - cmd = 4;
> - if (mode & EMIT_INVALIDATE) {
> + if (mode & EMIT_INVALIDATE)
> cmd += 2;
>
> - if (HAS_AUX_CCS(rq->engine->i915) &&
> - (rq->engine->class == VIDEO_DECODE_CLASS ||
> - rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
> - aux_inv = rq->engine->mask &
> - ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
> - if (aux_inv)
> - cmd += 4;
> - }
> + if (HAS_AUX_CCS(rq->engine->i915))
> + aux_inv = rq->engine->mask &
> + ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
> +
> + /*
> + * On Aux CCS platforms the invalidation of the Aux
> + * table requires quiescing memory traffic beforehand
> + */
> + if (aux_inv) {
> + cmd += 4; /* for the AUX invalidation */
> + cmd += 2; /* for the engine quiescing */
> +
> + cmd_flush = MI_FLUSH_DW;
> +
> + if (rq->engine->class == COPY_ENGINE_CLASS)
> + cmd_flush |= MI_FLUSH_DW_CCS;
> }
>
> cs = intel_ring_begin(rq, cmd);
> if (IS_ERR(cs))
> return PTR_ERR(cs);
>
> + if (cmd_flush) {
> + *cs++ = cmd_flush;
> + *cs++ = 0;
> + }
> +
> if (mode & EMIT_INVALIDATE)
> *cs++ = preparser_disable(true);
>
>
-
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 |
Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z
dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach
handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie;
jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). If you are not the intended recipient, please
contact the sender and delete all copies; any review or distribution by others
is strictly prohibited.
Re: [v7,5/9] drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control
Hi Janusz,
> > Enable the CCS_FLUSH bit 13 in the control pipe for render and
> > compute engines in platforms starting from Meteor Lake (BSPEC
> > 43904 and 47112).
> >
> > Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all
> > engines")
>
> I'm not sure why you think that your change fixes that commit. Can you
> please
> explain?
Hardware folks have provided a new sequence for performing the
quiescing of the engines... that's how it is :)
Thanks,
Andi
Re: [PATCH 0/3] MediaTek DRM: Clean up CMDQ support and ifdefs
On 19/07/2023 09:41, AngeloGioacchino Del Regno wrote: Il 23/06/23 14:49, Alexandre Mergnat ha scritto: On 23/06/2023 11:49, AngeloGioacchino Del Regno wrote: This series changes MediaTek CMDQ support to use the mtk-cmdq-helper functions, removing duplicated cmdq setup code in mtk-drm and also removing all instances of `#if IS_REACHABLE(CONFIG_MTK_CMDQ)` while keeping compatibility with both CONFIG_MTK_CMDQ=n and =m/=y. This applies on top of [1] and [2]. [1]:https://lore.kernel.org/lkml/20230524093412.92211-1-angelogioacchino.delre...@collabora.com [2]:https://lore.kernel.org/lkml/20230608084727.74403-1-angelogioacchino.delre...@collabora.com Hi Angelo, Can you provide a public branch to test it please ? I tried to apply the dependencies but still have an issue with the 3rd one: https://lore.kernel.org/lkml/20230523104234.7849-1-angelogioacchino.delre...@collabora.com OK https://lore.kernel.org/lkml/20230524093412.92211-1-angelogioacchino.delre...@collabora.com OK https://lore.kernel.org/lkml/20230608084727.74403-1-angelogioacchino.delre...@collabora.com KO Thanks Sorry for the very late reply; I've somehow lost this email in the haystack... There you go: https://gitlab.collabora.com/google/chromeos-kernel/-/commits/for-kernelci/ Thanks Angelo, I build/boot your branch for the i350-evk board. I had to revert this commit from your branch: "15f12798e218 TODO: soc: mediatek: mtk-pm-domains: Support CPU Power Domains" Because it conflict with the "soc: mediatek: MT8365 power support" serie [3]. Also, I change back the defconfig to be aligned with the v6.5-rc1 After that, the board boot and drm/display seems working like a charm. [3]: https://lore.kernel.org/linux-arm-kernel/20230713150414.891893-1-...@baylibre.com/ -- Regards, Alexandre
[Bug 217690] consistent amdgpu failures on Lenovo ThinkPad Z16: "[drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* wait_for_completion_timeout timeout!"
https://bugzilla.kernel.org/show_bug.cgi?id=217690 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED --- Comment #1 from Artem S. Tashkinov (a...@gmx.com) --- Please take it here instead: https://gitlab.freedesktop.org/drm/amd/-/issues -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 6/9] drm/verisilicon: Add drm crtc funcs
On 2023/6/30 19:55, Thomas Zimmermann wrote:
> Hi
>
> Am 02.06.23 um 09:40 schrieb Keith Zhao:
>> Add crtc driver which implements crtc related operation functions.
>>
>> Signed-off-by: Keith Zhao
>> ---
>> drivers/gpu/drm/verisilicon/Makefile | 1 +
>> drivers/gpu/drm/verisilicon/vs_crtc.c | 388 ++
>> drivers/gpu/drm/verisilicon/vs_crtc.h | 74 +
>> drivers/gpu/drm/verisilicon/vs_type.h | 72 +
>> 4 files changed, 535 insertions(+)
>> create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c
>> create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h
>> create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h
>>
>> diff --git a/drivers/gpu/drm/verisilicon/Makefile
>> b/drivers/gpu/drm/verisilicon/Makefile
>> index 38254dc5d98d..bae5fbab9bbb 100644
>> --- a/drivers/gpu/drm/verisilicon/Makefile
>> +++ b/drivers/gpu/drm/verisilicon/Makefile
>> @@ -1,6 +1,7 @@
>> # SPDX-License-Identifier: GPL-2.0
>> vs_drm-objs := vs_drv.o \
>> + vs_crtc.o \
>> vs_fb.o \
>> vs_gem.o
>> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c
>> b/drivers/gpu/drm/verisilicon/vs_crtc.c
>> new file mode 100644
>> index ..a9e742d7bd1a
>> --- /dev/null
>> +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
>> @@ -0,0 +1,388 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "vs_crtc.h"
>> +
>> +void vs_crtc_destroy(struct drm_crtc *crtc)
>> +{
>> + struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
>> +
>> + drm_crtc_cleanup(crtc);
>> + kfree(vs_crtc);
>> +}
>> +
>> +static void vs_crtc_reset(struct drm_crtc *crtc)
>> +{
>> + struct vs_crtc_state *state;
>> +
>> + if (crtc->state) {
>> + __drm_atomic_helper_crtc_destroy_state(crtc->state);
>> +
>> + state = to_vs_crtc_state(crtc->state);
>> + kfree(state);
>> + crtc->state = NULL;
>> + }
>> +
>> + state = kzalloc(sizeof(*state), GFP_KERNEL);
>> + if (!state)
>> + return;
>> +
>> + __drm_atomic_helper_crtc_reset(crtc, >base);
>> +
>> + state->sync_mode = VS_SINGLE_DC;
>> + state->output_fmt = MEDIA_BUS_FMT_RBG888_1X24;
>> + state->encoder_type = DRM_MODE_ENCODER_NONE;
>> +}
>> +
>> +static struct drm_crtc_state *
>> +vs_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
>> +{
>> + struct vs_crtc_state *ori_state;
>> + struct vs_crtc_state *state;
>> +
>> + if (WARN_ON(!crtc->state))
>> + return NULL;
>
> I'd leave this check out. IIRC, crtc->state not supposed to be NULL here.
> Rather let it crash.
>
>> +
>> + ori_state = to_vs_crtc_state(crtc->state);
>> + state = kzalloc(sizeof(*state), GFP_KERNEL);
>> + if (!state)
>> + return NULL;
>> +
>> + __drm_atomic_helper_crtc_duplicate_state(crtc, >base);
>> +
>> + state->sync_mode = ori_state->sync_mode;
>> + state->output_fmt = ori_state->output_fmt;
>> + state->encoder_type = ori_state->encoder_type;
>> + state->bg_color = ori_state->bg_color;
>> + state->bpp = ori_state->bpp;
>> + state->sync_enable = ori_state->sync_enable;
>> + state->dither_enable = ori_state->dither_enable;
>> + state->underflow = ori_state->underflow;
>> +
>> + return >base;
>> +}
>> +
>> +static void vs_crtc_atomic_destroy_state(struct drm_crtc *crtc,
>> + struct drm_crtc_state *state)
>> +{
>> + __drm_atomic_helper_crtc_destroy_state(state);
>> + kfree(to_vs_crtc_state(state));
>> +}
>> +
>> +static int vs_crtc_atomic_set_property(struct drm_crtc *crtc,
>> + struct drm_crtc_state *state,
>> + struct drm_property *property,
>> + uint64_t val)
>> +{
>> + struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
>> + struct vs_crtc_state *vs_crtc_state = to_vs_crtc_state(state);
>> +
>> + if (property == vs_crtc->sync_mode)
>> + vs_crtc_state->sync_mode = val;
>> + else if (property == vs_crtc->mmu_prefetch)
>> + vs_crtc_state->mmu_prefetch = val;
>> + else if (property == vs_crtc->bg_color)
>> + vs_crtc_state->bg_color = val;
>> + else if (property == vs_crtc->panel_sync)
>> + vs_crtc_state->sync_enable = val;
>> + else if (property == vs_crtc->dither)
>> + vs_crtc_state->dither_enable = val;
>> + else
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +static int vs_crtc_atomic_get_property(struct drm_crtc *crtc,
>> + const struct drm_crtc_state *state,
>> + struct drm_property *property,
>> + uint64_t *val)
>> +{
>> + struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
>> + const struct vs_crtc_state *vs_crtc_state =
>> + container_of(state, const struct vs_crtc_state, base);
>> +
>> + if (property ==
Re: [v7, 6/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function
Hi Andi,
On Thursday, 20 July 2023 23:07:34 CEST Andi Shyti wrote:
> Just a trivial refactoring for reducing the number of code
> duplicate. This will come at handy in the next commits.
>
> Signed-off-by: Andi Shyti
> Cc: # v5.8+
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 44 +---
> 1 file changed, 23 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 9d050b9a19194..202d6ff8b5264 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -177,23 +177,31 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32
> *cs, const i915_reg_t inv
> return cs;
> }
>
> +static u32 *intel_emit_pipe_control_cs(struct i915_request *rq, u32
> bit_group_0,
> +u32 bit_group_1, u32 offset)
> +{
> + u32 *cs;
> +
> + cs = intel_ring_begin(rq, 6);
> + if (IS_ERR(cs))
> + return cs;
> +
> + cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
> + LRC_PPHWSP_SCRATCH_ADDR);
> + intel_ring_advance(rq, cs);
> +
> + return cs;
> +}
> +
> static int mtl_dummy_pipe_control(struct i915_request *rq)
> {
> /* Wa_14016712196 */
> if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
> - IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
> - u32 *cs;
> -
> - /* dummy PIPE_CONTROL + depth flush */
NIT: Maybe you could keep that comment, above intel_emit_pipe_control_cs(...).
Anyway, LGTM.
Reviewed-by: Janusz Krzysztofik
> - cs = intel_ring_begin(rq, 6);
> - if (IS_ERR(cs))
> - return PTR_ERR(cs);
> - cs = gen12_emit_pipe_control(cs,
> - 0,
> - PIPE_CONTROL_DEPTH_CACHE_FLUSH,
> - LRC_PPHWSP_SCRATCH_ADDR);
> - intel_ring_advance(rq, cs);
> - }
> + IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0))
> + intel_emit_pipe_control_cs(rq,
> +0,
> +PIPE_CONTROL_DEPTH_CACHE_FLUSH,
> +LRC_PPHWSP_SCRATCH_ADDR);
>
> return 0;
> }
> @@ -210,7 +218,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> mode)
> u32 bit_group_0 = 0;
> u32 bit_group_1 = 0;
> int err;
> - u32 *cs;
>
> err = mtl_dummy_pipe_control(rq);
> if (err)
> @@ -244,13 +251,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> mode)
> else if (engine->class == COMPUTE_CLASS)
> bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
>
> - cs = intel_ring_begin(rq, 6);
> - if (IS_ERR(cs))
> - return PTR_ERR(cs);
> -
> - cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
> - LRC_PPHWSP_SCRATCH_ADDR);
> - intel_ring_advance(rq, cs);
> + intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
> +LRC_PPHWSP_SCRATCH_ADDR);
> }
>
> if (mode & EMIT_INVALIDATE) {
>
-
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 |
Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z
dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach
handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie;
jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). If you are not the intended recipient, please
contact the sender and delete all copies; any review or distribution by others
is strictly prohibited.
