RE: [PATCH 09/28] drm: Add Color ops capability property
> -Original Message-
> From: Sebastian Wick
> Sent: Tuesday, February 13, 2024 5:35 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> jad...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com;
> jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org;
> xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch;
> quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run
> Subject: Re: [PATCH 09/28] drm: Add Color ops capability property
>
> On Tue, Feb 13, 2024 at 12:18:16PM +0530, Uma Shankar wrote:
> > Add capability property which a colorop can expose it's hardware's
> > abilities. It's a blob property that can be filled with respective
> > data structures depending on the colorop. The user space is expected
> > to read this property and program the colorop accordingly.
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > include/drm/drm_colorop.h | 13 +
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 9f6a3a1c8020..95f1df73209c 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -770,6 +770,9 @@ drm_atomic_colorop_get_property(struct drm_colorop
> *colorop,
> > *val = state->curve_1d_type;
> > } else if (property == colorop->data_property) {
> > *val = (state->data) ? state->data->base.id : 0;
> > + } else if (property == colorop->hw_caps_property) {
> > + *val = state->hw_caps ?
> > + state->hw_caps->base.id : 0;
> > } else {
> > return -EINVAL;
> > }
> > diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> > index 5b8c36538491..f417e109c40a 100644
> > --- a/include/drm/drm_colorop.h
> > +++ b/include/drm/drm_colorop.h
> > @@ -59,6 +59,12 @@ struct drm_colorop_state {
> > */
> > enum drm_colorop_curve_1d_type curve_1d_type;
> >
> > + /**
> > +* @hw_caps:
> > +*
> > +*/
> > + struct drm_property_blob *hw_caps;
> > +
>
> Is this supposed to be generic for any colorop or specifically for
> DRM_COLOROP_1D_LUT?
We have intentionally kept it generic so that it can be used for any kind
of hardware color block (1D LUT, 3D LUT etc.). Differentiation can be done
by using the Color op type.
Regards,
Uma Shankar
> > /**
> > * @data:
> > *
> > @@ -167,6 +173,13 @@ struct drm_colorop {
> > */
> > struct drm_property *bypass_property;
> >
> > + /**
> > +* @hwlut_caps_property:
> > +*
> > +* Property to expose hardware lut capbilities.
> > +*/
> > + struct drm_property *hw_caps_property;
> > +
> > /**
> > * @curve_1d_type:
> > *
> > --
> > 2.42.0
> >
RE: [PATCH 08/28] drm: Add Color lut range attributes
> -Original Message-
> From: Sebastian Wick
> Sent: Tuesday, February 13, 2024 5:34 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> jad...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com;
> jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org;
> xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch;
> quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run
> Subject: Re: [PATCH 08/28] drm: Add Color lut range attributes
>
> On Tue, Feb 13, 2024 at 12:18:15PM +0530, Uma Shankar wrote:
> > This defines a new structure to define color lut ranges, along with
> > related macro definitions and enums. This will help describe segmented
> > lut ranges/PWL LUTs in the hardware.
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > include/uapi/drm/drm_mode.h | 58
> > +
> > 1 file changed, 58 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index af67f32e0087..376498715d0e 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -1014,6 +1014,64 @@ struct hdr_output_metadata {
> > DRM_MODE_PAGE_FLIP_ASYNC | \
> > DRM_MODE_PAGE_FLIP_TARGET)
> >
>
> All of this uses DRM_MODE_LUT namespace but it seems specifically for the drm
> colorop of type DRM_COLOROP_1D_LUT. Let's be consistent with the naming.
Yeah Sebastian, we will update this and get it aligned.
Thanks for pointing out.
Regards,
Uma Shankar
> > +/**
> > + * DRM_MODE_LUT_INTERPOLATE
> > + *
> > + * linearly interpolate between the points */ #define
> > +DRM_MODE_LUT_INTERPOLATE BIT(0)
> > +
> > +/**
> > + * DRM_MODE_LUT_REUSE_LAST
> > + *
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(1)
> > +
> > +/**
> > + * DRM_MODE_LUT_NON_DECREASING
> > + *
> > + * the curve must be non-decreasing
> > + */
> > +#define DRM_MODE_LUT_NON_DECREASING BIT(2)
> > +
> > +/**
> > + * DRM_MODE_LUT_REFLECT_NEGATIVE
> > + *
> > + * the curve is reflected across origin for negative inputs */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(3)
> > +
> > +/**
> > + * DRM_MODE_LUT_SINGLE_CHANNEL
> > + *
> > + * the same curve (red) is used for blue and green channels as well
> > +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(4)
> > +
> > +/**
> > + * struct drm_color_lut_range
> > + *
> > + * structure to advertise capability of a color hardware
> > + * block that accepts LUT values. It can represent LUTs with
> > + * varied number of entries and distributions
> > + * (Multi segmented, Logarithmic etc).
> > + */
> > +
> > +struct drm_color_lut_range {
> > + /* DRM_MODE_LUT_* */
> > + __u32 flags;
> > + /* number of points on the curve */
> > + __u16 count;
> > + /* input/output bits per component */
> > + __u8 input_bpc, output_bpc;
> > + /* input start/end values */
> > + __s32 start, end;
> > + /* output min/max values */
> > + __s32 min, max;
> > +};
> > +
> > /*
> > * Request a page flip on the specified crtc.
> > *
> > --
> > 2.42.0
> >
RE: [PATCH 00/28] Plane Color Pipeline support for Intel platforms
> -Original Message- > From: Pekka Paalanen > Sent: Tuesday, February 13, 2024 4:32 PM > To: Shankar, Uma > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com; > m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com; > shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es; > mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com; > victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com; > quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net; > mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com; > s...@poorly.run; Borah, Chaitanya Kumar > Subject: Re: [PATCH 00/28] Plane Color Pipeline support for Intel platforms > > On Tue, 13 Feb 2024 12:18:07 +0530 > Uma Shankar wrote: > > > This series intends to add support for Plane Color Management for > > Intel platforms. This is based on the design which has been agreed > > upon by the community. Series implementing the design for generic DRM > > core has been sent out by Harry Wentland and is under review > > below: > > https://patchwork.freedesktop.org/series/123446/ > > > > The base work of above series is squashed under 1 patch and support > > for Intel platform is added on top of it. > > Any reviews on the original core design is expected to be done in > > Harry's series to avoid any forking of the discussion. > > > > We have added some changes/fixes to the Harry's core DRM changes, > > being put up as separate patches on top of squashed patch. These are > > expected to get included in the main series from Harry once agreed upon. > > > > Changes added on core design: > > 1. Below patches implement some fixes on original series > > drm: Add missing function declarations > > drm: handle NULL next colorop in drm_colorop_set_next_property > > drm: Fix error logging in set Color Pipeline > > > > 2. Implemented a HW capability property to expose segmented luts. > > drm: Add Color lut range attributes > > drm: Add Color ops capability property > > drm: Define helper to create color ops capability property > > drm: Define helper for adding capability property for 1D LUT > > > > This helps in generically defining the hardware lut capabilities, lut > > distribution, precision, segmented or PWL LUTS. > > > > 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT: > > drm: Add Enhanced LUT precision structure > > drm: Add support for 3x3 CTM > > drm: Add 1D LUT color op > > > > On top of this base work for DRM core plane color pipeline design, > > implementation is done for Intel hardware platforms. Below patches > > include the same: > > > > drm/i915: Add identifiers for intel color blocks > > drm/i915: Add intel_color_op > > drm/i915/color: Add helper to allocate intel colorop > > drm/i915/color: Add helper to create intel colorop > > drm/i915/color: Create a transfer function color pipeline > > drm/i915/color: Add and attach COLORPIPELINE plane property > > drm/i915/color: Add framework to set colorop > > drm/i915/color: Add callbacks to set plane CTM > > drm/i915/color: Add framework to program PRE/POST CSC LUT > > FIXME: force disable legacy plane color properties for TGL and beyond > > drm/i915/color: Enable Plane Color Pipelines > > drm/i915: Define segmented Lut and add capabilities to colorop > > drm/i915/color: Add plane CTM callback for TGL and beyond > > drm/i915: Add register definitions for Plane Degamma > > drm/i915: Add register definitions for Plane Post CSC > > drm/i915/color: Program Pre-CSC registers > > drm/i915/xelpd: Program Plane Post CSC Registers > > > > Bhanu from Intel will be sending out the igt changes to help test the > > color pipeline implementation based on the current igt changes sent > > out by Harry. > > https://patchwork.freedesktop.org/series/123448/ > > > > Planned Next Steps: > > 1. Work with Harry and community and get DRM core changes for color > > pipeline merged. > > 2. Implement pipe color management (post blending) based on the > > current color pipeline design. > > 3. Work with compositor maintainers to get color processing > > implemented using display hardware, thereby avoid any GL or GPU shaders. > > > > Thanks to all the community maintainers and contributors who have > > helped to get this support in upstream Linux. Looking forward to > > collaborate, work together and get this merged. > > > > ... > > > Chaitanya Kumar Borah (16): > > drm: Add missing function declarations > > drm: handle NULL next colorop in drm_colorop_set_next_property > > drm: Fix error logging in set Color Pipeline > > drm: Add support for 3x3 CTM > > drm: Add 1D LUT color op > > drm/i915: Add identifiers for intel color blocks > > drm/i915: Add intel_color_op > > drm/i915/color: Add helper to allocate intel colorop > > drm/i915/color: Add helper to create intel colorop > > drm/i915/color: Create a transfer function color pipeline > >
RE: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities to colorop
> -Original Message-
> From: dri-devel On Behalf Of Pekka
> Paalanen
> Sent: Tuesday, February 13, 2024 3:07 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run
> Subject: Re: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities
> to colorop
>
> On Tue, 13 Feb 2024 12:18:24 +0530
> Uma Shankar wrote:
>
> > This defines the lut segments and create the color pipeline
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 109
> > +
> > 1 file changed, 109 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index e223edbe4c13..223cd1ff7291 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -3811,6 +3811,105 @@ static const struct intel_color_funcs
> ilk_color_funcs = {
> > .get_config = ilk_get_config,
> > };
> >
> > +static const struct drm_color_lut_range xelpd_degamma_hdr[] = {
> > + /* segment 1 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_NON_DECREASING),
>
> Hi Uma,
>
> is it a good idea to have these flags per-segment?
>
> I would find it very strange, unusable really, if REFLECT_NEGATIVE applied on
> some but not all segments, for example. Is such flexibility really necessary
> in the
> hardware description?
Hi Pekka,
Idea to have these flags is to just have some option in case there are some
differences
across segments. Most cases this should not be the case, just helps to future
proof
the implementation.
Based on how the community feels on the usability of it, we can take a call on
the flags
and the expected interpretation for the same. We are open for suggestions on
the same.
>
> > + .count = 128,
> > + .input_bpc = 24, .output_bpc = 16,
>
> The same question about input_bpc and output_bpc.
Same for these as well, userspace can just ignore these if no usage. However,
for some clients
it may help in Lut computations.
The original idea for the structure came from Ville (missed to mention that in
cover letter, will get that
updated in next version).
@ville.syrj...@linux.intel.com Please share your inputs on the usability of
these attributes.
> > + .start = 0, .end = (1 << 24) - 1,
> > + .min = 0, .max = (1 << 24) - 1,
> > + },
> > + /* segment 2 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = (1 << 24) - 1, .end = 1 << 24,
>
> What if there is a gap or overlap between the previous segment .end and the
> next
> segment .start? Is it forbidden? Will the kernel common code verify that
> drivers
> don't make mistakes? Or IGT?
This is just to help give some reference to userspace. As of now, driver
trusts the values
coming from userspace if it sends wrong values its on him and driver can't help
much.
However, we surely can have some sanity check like non decreasing luts etc. to
driver.
Ideally LUT values should not overlap, but we can indicate this explicitly with
flag to
hint the userspace (for overlap or otherwise) and also get a check in driver
for the same.
Regards,
Uma Shankar
>
> Thanks,
> pq
>
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 3 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 1 << 24, .end = 3 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 4 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > +
[PATCH] Revert "drm/panel-edp: Add auo_b116xa3_mode"
This reverts commit 70e0d5550f5cec301ad116703b840a539fe985dc.
The overridden mode fixes the panel glitching issue on mt8186 chromebook.
However, it causes the internal display not working on mt8173 chromebook.
Revert the overridden mode for now to let mt8173 have a functional display.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/panel/panel-edp.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 7d556b1bfa82..bd71d239272a 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1002,19 +1002,6 @@ static const struct panel_desc auo_b101ean01 = {
},
};
-static const struct drm_display_mode auo_b116xa3_mode = {
- .clock = 70589,
- .hdisplay = 1366,
- .hsync_start = 1366 + 40,
- .hsync_end = 1366 + 40 + 40,
- .htotal = 1366 + 40 + 40 + 32,
- .vdisplay = 768,
- .vsync_start = 768 + 10,
- .vsync_end = 768 + 10 + 12,
- .vtotal = 768 + 10 + 12 + 6,
- .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
-};
-
static const struct drm_display_mode auo_b116xak01_mode = {
.clock = 69300,
.hdisplay = 1366,
@@ -1963,12 +1950,10 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, _200_500_e50,
"B116XAN06.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, _200_500_e50,
"B116XTN02.5"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, _200_500_e50,
"B140HAN04.0"),
- EDP_PANEL_ENTRY2('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01.0",
-_b116xa3_mode),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x435c, _200_500_e50, "Unknown"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, _200_500_e50,
"B133UAN01.0"),
- EDP_PANEL_ENTRY2('A', 'U', 'O', 0x615c, _200_500_e50,
"B116XAN06.1",
-_b116xa3_mode),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, _200_500_e50,
"B116XAN06.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x635c, _200_500_e50,
"B116XAN06.3"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x639c, _200_500_e50,
"B140HAK02.7"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x723c, _200_500_e50,
"B140XTN07.2"),
--
2.43.0.687.g38aa6559b0-goog
RE: [PATCH 05/28] drm: Add support for 3x3 CTM
> -Original Message-
> From: Pekka Paalanen
> Sent: Tuesday, February 13, 2024 2:45 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run; Borah, Chaitanya Kumar
> Subject: Re: [PATCH 05/28] drm: Add support for 3x3 CTM
>
> On Tue, 13 Feb 2024 12:18:12 +0530
> Uma Shankar wrote:
>
> > From: Chaitanya Kumar Borah
> >
> > Add support for 3x3 Color Transformation Matrices in Color Pipeline.
> >
> > Signed-off-by: Chaitanya Kumar Borah
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > drivers/gpu/drm/drm_colorop.c | 2 +-
> > include/uapi/drm/drm_mode.h | 1 +
> > 3 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index e7bf1fb054af..c54b0d6c133e 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -716,6 +716,9 @@ static int drm_atomic_color_set_data_property(struct
> drm_colorop *colorop,
> > case DRM_COLOROP_CTM_3X4:
> > size = sizeof(struct drm_color_ctm_3x4);
> > break;
> > + case DRM_COLOROP_CTM_3X3:
> > + size = sizeof(struct drm_color_ctm);
> > + break;
> > default:
> > /* should never get here */
> > return -EINVAL;
> > diff --git a/drivers/gpu/drm/drm_colorop.c
> > b/drivers/gpu/drm/drm_colorop.c index 462ffec42cdf..6bae6dc8e54b
> > 100644
> > --- a/drivers/gpu/drm/drm_colorop.c
> > +++ b/drivers/gpu/drm/drm_colorop.c
> > @@ -107,7 +107,7 @@ int drm_colorop_init(struct drm_device *dev, struct
> drm_colorop *colorop,
> >0);
> >
> > /* data */
> > - if (type == DRM_COLOROP_CTM_3X4) {
> > + if (type == DRM_COLOROP_CTM_3X4 || type ==
> DRM_COLOROP_CTM_3X3) {
> > prop = drm_property_create(dev, DRM_MODE_PROP_ATOMIC |
> DRM_MODE_PROP_BLOB,
> >"DATA", 0);
> > if (!prop)
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index f16318f1785f..68696253867e 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -868,6 +868,7 @@ struct drm_color_lut {
> >
> > enum drm_colorop_type {
> > DRM_COLOROP_1D_CURVE,
> > + DRM_COLOROP_CTM_3X3,
> > DRM_COLOROP_CTM_3X4,
> > };
> >
>
> Hi,
>
> where are the docs for DRM_COLOROP_CTM_3X3?
Hi Pekka,
Sorry, we missed this in the current version. Will update the same in next
revision.
Regards,
Uma Shankar
>
> Thanks,
> pq
Re: [PATCH] drm/dp: Don't attempt AUX transfers when eDP panels are not powered
On Wed, Feb 14, 2024 at 2:23 PM Douglas Anderson wrote:
>
> If an eDP panel is not powered on then any attempts to talk to it over
> the DP AUX channel will timeout. Unfortunately these attempts may be
> quite slow. Userspace can initiate these attempts either via a
> /dev/drm_dp_auxN device or via the created i2c device.
>
> Making the DP AUX drivers timeout faster is a difficult proposition.
> In theory we could just poll the panel's HPD line in the AUX transfer
> function and immediately return an error there. However, this is
> easier said than done. For one thing, there's no hard requirement to
> hook the HPD line up for eDP panels and it's OK to just delay a fixed
> amount. For another thing, the HPD line may not be fast to probe. On
> parade-ps8640 we need to wait for the bridge chip's firmware to boot
> before we can get the HPD line and this is a slow process.
>
> The fact that the transfers are taking so long to timeout is causing
> real problems. The open source fwupd daemon sometimes scans DP busses
> looking for devices whose firmware need updating. If it happens to
> scan while a panel is turned off this scan can take a long time. The
> fwupd daemon could try to be smarter and only scan when eDP panels are
> turned on, but we can also improve the behavior in the kernel.
>
> Let's let eDP panels drivers specify that a panel is turned off and
> then modify the common AUX transfer code not to attempt a transfer in
> this case.
>
> Signed-off-by: Douglas Anderson
> ---
Reviewed-by: Hsin-Yi Wang
>
> drivers/gpu/drm/display/drm_dp_helper.c | 35 +++
> drivers/gpu/drm/panel/panel-edp.c | 3 ++
> .../gpu/drm/panel/panel-samsung-atna33xc20.c | 2 ++
> include/drm/display/drm_dp_helper.h | 6
> 4 files changed, 46 insertions(+)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index b1ca3a1100da..6fa705d82c8f 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -532,6 +532,15 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
>
> mutex_lock(>hw_mutex);
>
> + /*
> +* If the device attached to the aux bus is powered down then there's
> +* no reason to attempt a transfer. Error out immediately.
> +*/
> + if (aux->powered_down) {
> + ret = -EBUSY;
> + goto unlock;
> + }
> +
> /*
> * The specification doesn't give any recommendation on how often to
> * retry native transactions. We used to retry 7 times like for
> @@ -599,6 +608,29 @@ int drm_dp_dpcd_probe(struct drm_dp_aux *aux, unsigned
> int offset)
> }
> EXPORT_SYMBOL(drm_dp_dpcd_probe);
>
> +/**
> + * drm_dp_dpcd_set_powered() - Set whether the DP device is powered
> + * @aux: DisplayPort AUX channel; for convenience it's OK to pass NULL here
> + * and the function will be a no-op.
> + * @powered: true if powered; false if not
> + *
> + * If the endpoint device on the DP AUX bus is known to be powered down
> + * then this function can be called to make future transfers fail immediately
> + * instead of needing to time out.
> + *
> + * If this function is never called then a device defaults to being powered.
> + */
> +void drm_dp_dpcd_set_powered(struct drm_dp_aux *aux, bool powered)
> +{
> + if (!aux)
> + return;
> +
> + mutex_lock(>hw_mutex);
> + aux->powered_down = !powered;
> + mutex_unlock(>hw_mutex);
> +}
> +EXPORT_SYMBOL(drm_dp_dpcd_set_powered);
> +
> /**
> * drm_dp_dpcd_read() - read a series of bytes from the DPCD
> * @aux: DisplayPort AUX channel (SST or MST)
> @@ -1858,6 +1890,9 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter,
> struct i2c_msg *msgs,
> struct drm_dp_aux_msg msg;
> int err = 0;
>
> + if (aux->powered_down)
> + return -EBUSY;
> +
> dp_aux_i2c_transfer_size = clamp(dp_aux_i2c_transfer_size, 1,
> DP_AUX_MAX_PAYLOAD_BYTES);
>
> memset(, 0, sizeof(msg));
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 7d556b1bfa82..d2a4e514d8fd 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -413,6 +413,7 @@ static int panel_edp_suspend(struct device *dev)
> {
> struct panel_edp *p = dev_get_drvdata(dev);
>
> + drm_dp_dpcd_set_powered(p->aux, false);
> gpiod_set_value_cansleep(p->enable_gpio, 0);
> regulator_disable(p->supply);
> p->unprepared_time = ktime_get_boottime();
> @@ -469,6 +470,7 @@ static int panel_edp_prepare_once(struct panel_edp *p)
> }
>
> gpiod_set_value_cansleep(p->enable_gpio, 1);
> + drm_dp_dpcd_set_powered(p->aux, true);
>
> p->powered_on_time = ktime_get_boottime();
>
> @@ -507,6 +509,7 @@ static int panel_edp_prepare_once(struct panel_edp *p)
> return
[PATCH v3 2/2] fbcon: Defer console takeover for splash screens to first switch
Until now, deferred console takeover only meant defer until there is
output. But that risks stepping on the toes of userspace splash screens,
as console messages may appear before the splash screen. So check the
command line for the expectation of userspace splash and if present then
extend the deferral until the first switch.
v2: Added Kconfig option instead of hard coding "splash".
v3: Default to disabled, not "splash". If enabled then take over on
switch rather than on first output after switch.
Closes: https://bugs.launchpad.net/bugs/1970069
Cc: Mario Limonciello
Signed-off-by: Daniel van Vugt
---
drivers/video/console/Kconfig| 12 +
drivers/video/fbdev/core/fbcon.c | 44 +---
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index bc31db6ef7..2f9435335f 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -138,6 +138,18 @@ config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
by the firmware in place, rather then replacing the contents with a
black screen as soon as fbcon loads.
+config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION
+ string "Command line parameter to defer takeover to first switch"
+ depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
+ default ""
+ help
+ If enabled this defers further the framebuffer console taking over
+ until the first console switch has occurred. And even then only if
+ the specified parameter is found on the command line. This ensures
+ fbcon does not interrupt userspace splash screens such as Plymouth
+ which may be yet to start rendering at the time of the first console
+ output.
+
config STI_CONSOLE
bool "STI text console"
depends on PARISC && HAS_IOMEM
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 1183e7a871..e5d841ab03 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -76,6 +76,7 @@
#include /* For counting font checksums */
#include
#include
+#include
#include "fbcon.h"
#include "fb_internal.h"
@@ -3348,7 +3349,7 @@ static int fbcon_output_notifier(struct notifier_block
*nb,
{
WARN_CONSOLE_UNLOCKED();
- pr_info("fbcon: Taking over console\n");
+ pr_info("fbcon: Taking over console for output\n");
dummycon_unregister_output_notifier(_output_nb);
@@ -3357,6 +3358,27 @@ static int fbcon_output_notifier(struct notifier_block
*nb,
return NOTIFY_OK;
}
+
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION
+static int initial_console;
+static struct notifier_block fbcon_switch_nb;
+
+static int fbcon_switch_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+ struct vc_data *vc = data;
+
+ WARN_CONSOLE_UNLOCKED();
+
+ if (vc->vc_num != initial_console) {
+ pr_info("fbcon: Taking over console for switch\n");
+ dummycon_unregister_switch_notifier(_switch_nb);
+ schedule_work(_deferred_takeover_work);
+ }
+
+ return NOTIFY_OK;
+}
+#endif
#endif
static void fbcon_start(void)
@@ -3368,8 +3390,18 @@ static void fbcon_start(void)
deferred_takeover = false;
if (deferred_takeover) {
- fbcon_output_nb.notifier_call = fbcon_output_notifier;
- dummycon_register_output_notifier(_output_nb);
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION
+ if (cmdline_find_option_bool(boot_command_line,
+ CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION)) {
+ initial_console = fg_console;
+ fbcon_switch_nb.notifier_call = fbcon_switch_notifier;
+ dummycon_register_switch_notifier(_switch_nb);
+ } else
+#endif
+ {
+ fbcon_output_nb.notifier_call = fbcon_output_notifier;
+ dummycon_register_output_notifier(_output_nb);
+ }
return;
}
#endif
@@ -3416,8 +3448,12 @@ void __exit fb_console_exit(void)
{
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
console_lock();
- if (deferred_takeover)
+ if (deferred_takeover) {
dummycon_unregister_output_notifier(_output_nb);
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION
+ dummycon_unregister_switch_notifier(_switch_nb);
+#endif
+ }
console_unlock();
cancel_work_sync(_deferred_takeover_work);
--
2.43.0
[PATCH v3 1/2] dummycon: Add dummycon_(un)register_switch_notifier
To detect switch attempts before a real console exists. This will be
used for the same purpose as dummycon_(un)register_output_notifier,
for fbcon to detect a more polite time to take over.
Signed-off-by: Daniel van Vugt
---
drivers/video/console/dummycon.c | 35 +++-
include/linux/console.h | 2 ++
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 14af5d9e13..55e9b600ce 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -83,6 +83,32 @@ static int dummycon_blank(struct vc_data *vc, int blank, int
mode_switch)
/* Redraw, so that we get putc(s) for output done while blanked */
return 1;
}
+
+/* This is protected by the console_lock */
+static RAW_NOTIFIER_HEAD(dummycon_switch_nh);
+
+void dummycon_register_switch_notifier(struct notifier_block *nb)
+{
+ WARN_CONSOLE_UNLOCKED();
+
+ raw_notifier_chain_register(_switch_nh, nb);
+}
+
+void dummycon_unregister_switch_notifier(struct notifier_block *nb)
+{
+ WARN_CONSOLE_UNLOCKED();
+
+ raw_notifier_chain_unregister(_switch_nh, nb);
+}
+
+static int dummycon_switch(struct vc_data *vc)
+{
+ WARN_CONSOLE_UNLOCKED();
+
+ raw_notifier_call_chain(_switch_nh, 0, vc);
+
+ return 0;
+}
#else
static void dummycon_putc(struct vc_data *vc, int c, int ypos, int xpos) { }
static void dummycon_putcs(struct vc_data *vc, const unsigned short *s,
@@ -91,6 +117,10 @@ static int dummycon_blank(struct vc_data *vc, int blank,
int mode_switch)
{
return 0;
}
+static int dummycon_switch(struct vc_data *vc)
+{
+ return 0;
+}
#endif
static const char *dummycon_startup(void)
@@ -120,11 +150,6 @@ static bool dummycon_scroll(struct vc_data *vc, unsigned
int top,
return false;
}
-static int dummycon_switch(struct vc_data *vc)
-{
- return 0;
-}
-
/*
* The console `switch' structure for the dummy console
*
diff --git a/include/linux/console.h b/include/linux/console.h
index 779d388af8..8fd70ae623 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -531,5 +531,7 @@ extern void console_init(void);
/* For deferred console takeover */
void dummycon_register_output_notifier(struct notifier_block *nb);
void dummycon_unregister_output_notifier(struct notifier_block *nb);
+void dummycon_register_switch_notifier(struct notifier_block *nb);
+void dummycon_unregister_switch_notifier(struct notifier_block *nb);
#endif /* _LINUX_CONSOLE_H */
--
2.43.0
[PATCH 2/2] drm/tests/drm_buddy: add alloc_contiguous test
From: Matthew Auld
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Cc: Arunpravin Paneer Selvam
Cc: Limonciello
Cc: Christian König
Reviewed-by: Arunpravin Paneer Selvam
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/tests/drm_buddy_test.c | 89 ++
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index ea2af6bd9abe..4215d8b5fcf0 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
@@ -18,6 +19,93 @@ static inline u64 get_size(int order, u64 chunk_size)
return (1 << order) * chunk_size;
}
+static void drm_test_buddy_alloc_contiguous(struct kunit *test)
+{
+ u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ struct drm_buddy_block *block;
+ struct drm_buddy mm;
+ LIST_HEAD(left);
+ LIST_HEAD(middle);
+ LIST_HEAD(right);
+ LIST_HEAD(allocated);
+
+ mm_size = 16 * 3 * SZ_4K;
+
+ KUNIT_EXPECT_FALSE(test, drm_buddy_init(, mm_size, ps));
+
+ /*
+* Idea is to fragment the address space by alternating block
+* allocations between three different lists; one for left, middle and
+* right. We can then free a list to simulate fragmentation. In
+* particular we want to exercise the DRM_BUDDY_CONTIGUOUS_ALLOCATION,
+* including the try_harder path.
+*/
+
+ i = 0;
+ n_pages = mm_size / ps;
+ do {
+ struct list_head *list;
+ int slot = i % 3;
+
+ if (slot == 0)
+ list =
+ else if (slot == 1)
+ list =
+ else
+ list =
+ KUNIT_ASSERT_FALSE_MSG(test,
+ drm_buddy_alloc_blocks(, 0, mm_size,
+ ps, ps, list, 0),
+ "buddy_alloc hit an error size=%d\n",
+ ps);
+ } while (++i < n_pages);
+
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%d\n", 3 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ /*
+* At this point we should have enough contiguous space for 2 blocks,
+* however they are never buddies (since we freed middle and right) so
+* will require the try_harder logic to find them.
+*/
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 3 * ps);
+
+ total = 0;
+ list_for_each_entry(block, , link)
+ total += drm_buddy_block_size(, block);
+
+ KUNIT_ASSERT_EQ(test, total, ps * 2 + ps * 3);
+
+ drm_buddy_free_list(, );
+ drm_buddy_fini();
+}
+
static void drm_test_buddy_alloc_pathological(struct kunit *test)
{
u64 mm_size, size, start = 0;
@@ -280,6 +368,7 @@ static struct kunit_case drm_buddy_tests[] = {
[PATCH 1/2] drm/buddy: Fix alloc_range() error handling code
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if the total allocated size
is less than the required size, the function should
return -ENOSPC.
Cc: # 6.7+
Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Tested-by: Mario Limonciello
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
Acked-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..c1a99bf4dffd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm,
} while (1);
list_splice_tail(, blocks);
+
+ if (total_allocated < size) {
+ err = -ENOSPC;
+ goto err_free;
+ }
+
return 0;
err_undo:
base-commit: 2c80a2b715df75881359d07dbaacff8ad411f40e
--
2.25.1
Re: [etnaviv-next v13 7/7] drm/etnaviv: Add support for vivante GPU cores attached via PCI(e)
Hi, On 2024/2/9 19:02, Daniel Vetter wrote: On Thu, Feb 08, 2024 at 04:27:02PM +0100, Maxime Ripard wrote: On Wed, Feb 07, 2024 at 10:35:49AM +0100, Daniel Vetter wrote: On Wed, Feb 07, 2024 at 01:27:59AM +0800, Sui Jingfeng wrote: The component helper functions are the glue, which is used to bind multiple GPU cores to a virtual master platform device. Which is fine and works well for the SoCs who contains multiple GPU cores. The problem is that usperspace programs (such as X server and Mesa) will search the PCIe device to use if it is exist. In other words, usperspace programs open the PCIe device with higher priority. Creating a virtual master platform device for PCI(e) GPUs is unnecessary, as the PCI device has been created by the time drm/etnaviv is loaded. we create virtual platform devices as a representation for the vivante GPU ip core. As all of subcomponent are attached via the PCIe master device, we reflect this hardware layout by binding all of the virtual child to the the real master. Signed-off-by: Sui Jingfeng Uh so my understanding is that drivers really shouldn't create platform devices of their own. For this case here I think the aux-bus framework is the right thing to use. Alternatively would be some infrastructure where you feed a DT tree to driver core or pci subsystem and it instantiates it all for you correctly, and especially with hotunplug all done right since this is pci now, not actually part of the soc that cannot be hotunplugged. I don't think we need intermediate platform devices at all. We just need to register our GPU against the PCI device and that's it. We don't need a platform device, we don't need the component framework. Afaik that's what this series does. The component stuff is for the internal structure of the gpu ip, so that the same modular approach that works for arm-soc also works for pci chips. Otherwise we end up with each driver hand-rolling that stuff, which is defacto what both nouveau and amdgpu do (intel hw is too much a mess for that component-driver based approach to actually work reasonably well). Emmm, I spend years to achieve this, and only to find that you have fully understand my patch within two days. Cheers, Sima I think I've seen some other pci devices from arm soc designs that would benefit from this too, so lifting this logic into a pci function would make sense imo. Yes, as you said, we are trying to avoid the hand-rolling stuff. I guess, extremely advanced drivers(like i915, amdgpu, and nouveau) won't need this. So I'm not sure if lifting this logic into PCI core would benefit to other people. While investigating the aux-bus framework a few days, I find it is not as concise as this one. It introduce a lot of new structure, I fear that it may cause namespace pollution if adopt it. So, I thinks I should choose the alternative way. While taking a lot from contribution, we are really want to do some feedback(pay-back). We are happy if there are other users(or new drivers) would like to adopt this idea, I think, the idea itself has already been conveyed. Which probably can be seen as a trivial contribution. Other programmer are free to copy and modify. But as a initial commit, I minimized the mount of changes as required by Locus. meanwhile, I'm willing to following the expectation in the long term. If there are other users or other problem need to solve, I would like help to improve and to cooperate to testing in the future.
Re: [PATCH] nouveau/gsp: add kconfig option to enable GSP paths by default
(ignore this one, sent another just after) On Wed, 14 Feb 2024 at 13:40, Dave Airlie wrote: > > From: Dave Airlie > > Turing and Ampere will continue to use the old paths by default, > but we should allow distros to decide what the policy is. > > Signed-off-by: Dave Airlie > --- > drivers/gpu/drm/nouveau/Kconfig| 8 > drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 3 +++ > 2 files changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig > index 1e6aaf95ff7c..ceef470c9fbf 100644 > --- a/drivers/gpu/drm/nouveau/Kconfig > +++ b/drivers/gpu/drm/nouveau/Kconfig > @@ -100,3 +100,11 @@ config DRM_NOUVEAU_SVM > help > Say Y here if you want to enable experimental support for > Shared Virtual Memory (SVM). > + > +config DRM_NOUVEAU_GSP_DEFAULT > + bool "Use GSP firmware for Turing/Ampere (needs firmware installed)" > + depends on DRM_NOUVEAU > + default n > + help > + Say Y here if you want to use the GSP codepaths by default on > + Turing and Ampere GPUs. > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c > b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c > index a41735ab6068..fadbb892 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c > @@ -2313,6 +2313,9 @@ r535_gsp_load(struct nvkm_gsp *gsp, int ver, const > struct nvkm_gsp_fwif *fwif) > struct nvkm_subdev *subdev = >subdev; > int ret; > > +#if IS_ENABLED(CONFIG_DRM_NOUVEAU_GSP_DEFAULT) > + fwif->enable = true; > +#endif > if (!nvkm_boolopt(subdev->device->cfgopt, "NvGspRm", fwif->enable)) > return -EINVAL; > > -- > 2.43.0 >
[PATCH] nouveau/gsp: add kconfig option to enable GSP paths by default
From: Dave Airlie
Turing and Ampere will continue to use the old paths by default,
but we should allow distros to decide what the policy is.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/Kconfig| 8
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 6 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index 1e6aaf95ff7c..ceef470c9fbf 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -100,3 +100,11 @@ config DRM_NOUVEAU_SVM
help
Say Y here if you want to enable experimental support for
Shared Virtual Memory (SVM).
+
+config DRM_NOUVEAU_GSP_DEFAULT
+ bool "Use GSP firmware for Turing/Ampere (needs firmware installed)"
+ depends on DRM_NOUVEAU
+ default n
+ help
+ Say Y here if you want to use the GSP codepaths by default on
+ Turing and Ampere GPUs.
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index a41735ab6068..a64c81385682 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -2312,8 +2312,12 @@ r535_gsp_load(struct nvkm_gsp *gsp, int ver, const
struct nvkm_gsp_fwif *fwif)
{
struct nvkm_subdev *subdev = >subdev;
int ret;
+ bool enable_gsp = fwif->enable;
- if (!nvkm_boolopt(subdev->device->cfgopt, "NvGspRm", fwif->enable))
+#if IS_ENABLED(CONFIG_DRM_NOUVEAU_GSP_DEFAULT)
+ enable_gsp = true;
+#endif
+ if (!nvkm_boolopt(subdev->device->cfgopt, "NvGspRm", enable_gsp))
return -EINVAL;
if ((ret = r535_gsp_load_fw(gsp, "gsp", fwif->ver, >fws.rm)) ||
--
2.43.0
[PATCH] nouveau/gsp: add kconfig option to enable GSP paths by default
From: Dave Airlie Turing and Ampere will continue to use the old paths by default, but we should allow distros to decide what the policy is. Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/Kconfig| 8 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 3 +++ 2 files changed, 11 insertions(+) diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 1e6aaf95ff7c..ceef470c9fbf 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -100,3 +100,11 @@ config DRM_NOUVEAU_SVM help Say Y here if you want to enable experimental support for Shared Virtual Memory (SVM). + +config DRM_NOUVEAU_GSP_DEFAULT + bool "Use GSP firmware for Turing/Ampere (needs firmware installed)" + depends on DRM_NOUVEAU + default n + help + Say Y here if you want to use the GSP codepaths by default on + Turing and Ampere GPUs. diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c index a41735ab6068..fadbb892 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c @@ -2313,6 +2313,9 @@ r535_gsp_load(struct nvkm_gsp *gsp, int ver, const struct nvkm_gsp_fwif *fwif) struct nvkm_subdev *subdev = >subdev; int ret; +#if IS_ENABLED(CONFIG_DRM_NOUVEAU_GSP_DEFAULT) + fwif->enable = true; +#endif if (!nvkm_boolopt(subdev->device->cfgopt, "NvGspRm", fwif->enable)) return -EINVAL; -- 2.43.0
Re: [PATCH 1/2] [v3] nouveau: add command-line GSP-RM registry support
Hi Timur,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-intel/for-linux-next-fixes]
[also build test WARNING on drm-tip/drm-tip linus/master v6.8-rc4 next-20240213]
[cannot apply to drm-misc/drm-misc-next drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next]
[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/Timur-Tabi/nouveau-add-command-line-GSP-RM-registry-support/20240213-051852
base: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
patch link:
https://lore.kernel.org/r/20240212211548.1094496-2-ttabi%40nvidia.com
patch subject: [PATCH 1/2] [v3] nouveau: add command-line GSP-RM registry
support
config: parisc-defconfig
(https://download.01.org/0day-ci/archive/20240214/202402141030.x3uj4ydf-...@intel.com/config)
compiler: hppa-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240214/202402141030.x3uj4ydf-...@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/202402141030.x3uj4ydf-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c: In function
'r535_gsp_rpc_set_registry':
>> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1317:24: warning: variable
>> 'length' set but not used [-Wunused-but-set-variable]
1317 | size_t length;
|^~
--
>> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1246: warning: cannot
>> understand function prototype: 'const struct nv_gsp_registry_entries
>> r535_registry_entries[] = '
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1673: warning: Function
parameter or struct member 'priv' not described in
'r535_gsp_msg_run_cpu_sequencer'
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1673: warning: Function
parameter or struct member 'fn' not described in
'r535_gsp_msg_run_cpu_sequencer'
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1673: warning: Function
parameter or struct member 'repv' not described in
'r535_gsp_msg_run_cpu_sequencer'
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1673: warning: Function
parameter or struct member 'repc' not described in
'r535_gsp_msg_run_cpu_sequencer'
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:2046: warning: Function
parameter or struct member 'gsp' not described in 'r535_gsp_libos_init'
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:2186: warning: Function
parameter or struct member 'gsp' not described in 'nvkm_gsp_radix3_sg'
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:2186: warning: Function
parameter or struct member 'sgt' not described in 'nvkm_gsp_radix3_sg'
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:2186: warning: Function
parameter or struct member 'size' not described in 'nvkm_gsp_radix3_sg'
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:2186: warning: Function
parameter or struct member 'rx3' not described in 'nvkm_gsp_radix3_sg'
vim +/length +1317 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
1235
1236 /**
1237 * r535_registry_entries - required registry entries for GSP-RM
1238 *
1239 * This array lists registry entries that are required for GSP-RM to
1240 * function correctly.
1241 *
1242 * RMSecBusResetEnable - enables PCI secondary bus reset
1243 * RMForcePcieConfigSave - forces GSP-RM to preserve PCI configuration
1244 * registers on any PCI reset.
1245 */
> 1246 static const struct nv_gsp_registry_entries r535_registry_entries[] = {
1247 { "RMSecBusResetEnable", 1 },
1248 { "RMForcePcieConfigSave", 1 },
1249 };
1250 #define NV_GSP_REG_NUM_ENTRIES ARRAY_SIZE(r535_registry_entries)
1251
1252 /**
1253 * strip - strips all characters in 'reject' from 's'
1254 * @s: string to strip
1255 * @reject: string of characters to remove
1256 *
1257 * 's' is modified.
1258 *
1259 * Returns the length of the new string.
1260 */
1261 static size_t strip(char *s, const char *reject)
1262 {
1263 char *p = s, *p2 = s;
1264 size_t length = 0;
1265 char c;
1266
1267 do {
1268 while ((c = *p2) && strchr(reject, c))
1269 p2++;
1270
1271 *p++ = c = *p2++;
1272 length++;
1273 } while (c);
1274
1275 return length;
1276 }
1277
1278 /**
1279 * r535_gsp_rpc_set_registry - build registry RPC and call GSP-RM
1280 * @
Re: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
Hi Uma,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next next-20240213]
[cannot apply to drm-intel/for-linux-next drm-intel/for-linux-next-fixes
linus/master v6.8-rc4]
[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/Uma-Shankar/drm-color-pipeline-base-work/20240213-144544
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240213064835.139464-2-uma.shankar%40intel.com
patch subject: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
config: x86_64-allyesconfig
(https://download.01.org/0day-ci/archive/20240214/202402141056.lzcslaot-...@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project
6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240214/202402141056.lzcslaot-...@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/202402141056.lzcslaot-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/tests/drm_fixp_test.c:11:59: warning: overflow in
>> expression; result is 9223372036854775807 with type 'long long'
>> [-Winteger-overflow]
11 | KUNIT_EXPECT_EQ(test, 0x7fffll, ((1LL << 63) -
1));
| ^
1 warning generated.
--
>> drivers/gpu/drm/vkms/vkms_composer.c:95:5: warning: no previous prototype
>> for function 'lerp_u16' [-Wmissing-prototypes]
95 | u16 lerp_u16(u16 a, u16 b, s64 t)
| ^
drivers/gpu/drm/vkms/vkms_composer.c:95:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
95 | u16 lerp_u16(u16 a, u16 b, s64 t)
| ^
| static
>> drivers/gpu/drm/vkms/vkms_composer.c:105:5: warning: no previous prototype
>> for function 'get_lut_index' [-Wmissing-prototypes]
105 | s64 get_lut_index(const struct vkms_color_lut *lut, u16
channel_value)
| ^
drivers/gpu/drm/vkms/vkms_composer.c:105:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
105 | s64 get_lut_index(const struct vkms_color_lut *lut, u16
channel_value)
| ^
| static
>> drivers/gpu/drm/vkms/vkms_composer.c:167:6: warning: no previous prototype
>> for function 'apply_3x4_matrix' [-Wmissing-prototypes]
167 | void apply_3x4_matrix(struct pixel_argb_s32 *pixel, const struct
drm_color_ctm_3x4 *matrix)
| ^
drivers/gpu/drm/vkms/vkms_composer.c:167:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
167 | void apply_3x4_matrix(struct pixel_argb_s32 *pixel, const struct
drm_color_ctm_3x4 *matrix)
| ^
| static
3 warnings generated.
--
>> drivers/gpu/drm/vkms/vkms_colorop.c:11:1: warning: 'const' type qualifier on
>> return type has no effect [-Wignored-qualifiers]
11 | const int vkms_initialize_tf_pipeline(struct drm_plane *plane,
struct drm_prop_enum_list *list)
| ^
>> drivers/gpu/drm/vkms/vkms_colorop.c:11:11: warning: no previous prototype
>> for function 'vkms_initialize_tf_pipeline' [-Wmissing-prototypes]
11 | const int vkms_initialize_tf_pipeline(struct drm_plane *plane,
struct drm_prop_enum_list *list)
| ^
drivers/gpu/drm/vkms/vkms_colorop.c:11:7: note: declare 'static' if the
function is not intended to be used outside of this translation unit
11 | const int vkms_initialize_tf_pipeline(struct drm_plane *plane,
struct drm_prop_enum_list *list)
| ^
| static
>> drivers/gpu/drm/vkms/vkms_colorop.c:80:5: warning: no previous prototype for
>> function 'vkms_initialize_colorops' [-Wmissing-prototypes]
80 | int vkms_initialize_colorops(struct drm_plane *plane)
| ^
drivers/gpu/drm/vkms/vkms_colorop.c:80:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
80 | int vkms_initialize_colorops(struct drm_plane *plane)
| ^
| static
3 warnings generated.
vim +11 drivers/gpu/drm/tests/drm_fixp_test.c
8
9 static void drm_test_sm2fixp(struct kunit *test)
10 {
> 11 KUNIT_EXPECT_EQ(test, 0x7fffll, ((1LL << 63) - 1));
12
13 /* 1 */
14
Coverity: jpeg_v4_0_5_start(): Code maintainability issues
Hello!
This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20240213 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan
You're getting this email because you were associated with the identified
lines of code (noted below) that were touched by commits:
Mon Feb 12 16:09:32 2024 -0500
0a119d53f74a ("drm/amdgpu/jpeg: add support for jpeg DPG mode")
Coverity reported the following:
*** CID 1583635: Code maintainability issues (UNUSED_VALUE)
drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_5.c:461 in jpeg_v4_0_5_start()
455
456 WREG32_SOC15(VCN, i, regVCN_JPEG_DB_CTRL,
457 ring->doorbell_index <<
VCN_JPEG_DB_CTRL__OFFSET__SHIFT |
458 VCN_JPEG_DB_CTRL__EN_MASK);
459
460 if (adev->pg_flags & AMD_PG_SUPPORT_JPEG_DPG) {
vvv CID 1583635: Code maintainability issues (UNUSED_VALUE)
vvv Assigning value from "jpeg_v4_0_5_start_dpg_mode(adev, i,
adev->jpeg.indirect_sram)" to "r" here, but that stored value is overwritten
before it can be used.
461 r = jpeg_v4_0_5_start_dpg_mode(adev, i,
adev->jpeg.indirect_sram);
462 continue;
463 }
464
465 /* disable power gating */
466 r = jpeg_v4_0_5_disable_static_power_gating(adev, i);
If this is a false positive, please let us know so we can mark it as
such, or teach the Coverity rules to be smarter. If not, please make
sure fixes get into linux-next. :) For patches fixing this, please
include these lines (but double-check the "Fixes" first):
Reported-by: coverity-bot
Addresses-Coverity-ID: 1583635 ("Code maintainability issues")
Fixes: 0a119d53f74a ("drm/amdgpu/jpeg: add support for jpeg DPG mode")
Thanks for your attention!
--
Coverity-bot
[PATCH] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/display/drm_dp_helper.c | 78 +
drivers/gpu/drm/i915/display/intel_dp.c | 73 +--
include/drm/display/drm_dp_helper.h | 3 +
3 files changed, 84 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index b1ca3a1100da..066cfbbf7a91 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2916,6 +2916,84 @@ void drm_dp_vsc_sdp_log(const char *level, struct device
*dev,
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+/**
+ * drm_dp_vsc_sdp_pack() - pack a given vsc sdp into generic dp_sdp
+ * @vsc: vsc sdp initialized according to its purpose as defined in
+ * table 2-118 - table 2-120 in DP 1.4a specification
+ * @sdp: valid handle to the generic dp_sdp which will be packed
+ * @size: valid size of the passed sdp handle
+ *
+ * Returns length of sdp on success and error code on failure
+ */
+ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
+ struct dp_sdp *sdp, size_t size)
+{
+ size_t length = sizeof(struct dp_sdp);
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(sdp, 0, size);
+
+ /*
+* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
+* VSC SDP Header Bytes
+*/
+ sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
+ sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
+ sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
+ sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
+
+ if (vsc->revision == 0x6) {
+ sdp->db[0] = 1;
+ sdp->db[3] = 1;
+ }
+
+ /*
+* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
+* Format as per DP 1.4a spec and DP 2.0 respectively.
+*/
+ if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
+ goto out;
+
+ /* VSC SDP Payload for DB16 through DB18 */
+ /* Pixel Encoding and Colorimetry Formats */
+ sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
+ sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
+
+ switch (vsc->bpc) {
+ case 6:
+ /* 6bpc: 0x0 */
+ break;
+ case 8:
+ sdp->db[17] = 0x1; /* DB17[3:0] */
+ break;
+ case 10:
+ sdp->db[17] = 0x2;
+ break;
+ case 12:
+ sdp->db[17] = 0x3;
+ break;
+ case 16:
+ sdp->db[17] = 0x4;
+ break;
+ default:
+ WARN(1, "Missing case %d\n", vsc->bpc);
+ return -EINVAL;
+ }
+
+ /* Dynamic Range and Component Bit Depth */
+ if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
+ sdp->db[17] |= 0x80; /* DB17[7] */
+
+ /* Content Type */
+ sdp->db[18] = vsc->content_type & 0x7;
+
+out:
+ return length;
+}
+EXPORT_SYMBOL(drm_dp_vsc_sdp_pack);
+
/**
* drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
* @dpcd: DisplayPort configuration data
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f5ef95da5534..e94db51aeeb7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4110,73 +4110,6 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state
*crtc_state,
return false;
}
-static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
-struct dp_sdp *sdp, size_t size)
-{
- size_t length = sizeof(struct dp_sdp);
-
- if (size < length)
- return -ENOSPC;
-
- memset(sdp, 0, size);
-
- /*
-* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
-* VSC SDP Header Bytes
-*/
- sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
- sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
- sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
- sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
-
- if (vsc->revision == 0x6) {
- sdp->db[0] = 1;
- sdp->db[3] = 1;
- }
-
- /*
-* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
-* Format as per DP 1.4a spec and DP 2.0 respectively.
-*/
- if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
- goto out;
-
- /* VSC SDP Payload for DB16 through DB18 */
- /* Pixel Encoding and Colorimetry Formats */
- sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
- sdp->db[16] |=
[PATCH 2/2] drm/amd/display: clean else not following close brace
From: jppaulo Put else statement in the same line and after the close brace. Signed-off-by: Joao Paulo Pereira da Silva --- drivers/gpu/drm/amd/display/dc/core/dc_link_enc_cfg.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_enc_cfg.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_enc_cfg.c index be5a6d008b29..e750c853890e 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_enc_cfg.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_enc_cfg.c @@ -396,8 +396,7 @@ void link_enc_cfg_link_encs_assign( eng_id_req = stream->link->dpia_preferred_eng_id; eng_id = find_first_avail_link_enc(stream->ctx, state, eng_id_req); - } - else + } else eng_id = link_enc->preferred_engine; add_link_enc_assignment(state, stream, eng_id); -- 2.43.0
[PATCH 1/2] drm/amd/display: clean inconsistent indenting
From: jppaulo
Clean some wrong indenting that throw errors in checkpatch.
Signed-off-by: Joao Paulo Pereira da Silva
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index aa7c02ba948e..7832832b973d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -962,7 +962,7 @@ static bool dc_construct(struct dc *dc,
goto fail;
}
-dc_ctx = dc->ctx;
+ dc_ctx = dc->ctx;
/* Resource should construct all asic specific resources.
* This should be the only place where we need to parse the asic id
@@ -3155,10 +3155,10 @@ static void commit_planes_do_stream_update(struct dc
*dc,
if (stream_update->mst_bw_update->is_increase)
dc->link_srv->increase_mst_payload(pipe_ctx,
stream_update->mst_bw_update->mst_stream_bw);
- else
+ else
dc->link_srv->reduce_mst_payload(pipe_ctx,
stream_update->mst_bw_update->mst_stream_bw);
- }
+ }
if (stream_update->pending_test_pattern) {
dc_link_dp_set_test_pattern(stream->link,
--
2.43.0
[PATCH 0/2] drm/amd/display: clean codestyle errors
jppaulo (2): drm/amd/display: clean inconsistent indenting drm/amd/display: clean else not following close brace drivers/gpu/drm/amd/display/dc/core/dc.c | 6 +++--- drivers/gpu/drm/amd/display/dc/core/dc_link_enc_cfg.c | 3 +-- 2 files changed, 4 insertions(+), 5 deletions(-) -- 2.43.0
[PATCH v2] iosys-map: fix typo
Correct a spello/typo in comments. Signed-off-by: Randy Dunlap Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org --- v2: don't change "set up" to "setup" (Thomas) include/linux/iosys-map.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -- a/include/linux/iosys-map.h b/include/linux/iosys-map.h --- a/include/linux/iosys-map.h +++ b/include/linux/iosys-map.h @@ -34,7 +34,7 @@ * the same driver for allocation, read and write operations. * * Open-coding access to :c:type:`struct iosys_map ` is considered - * bad style. Rather then accessing its fields directly, use one of the provided + * bad style. Rather than accessing its fields directly, use one of the provided * helper functions, or implement your own. For example, instances of * :c:type:`struct iosys_map ` can be initialized statically with * IOSYS_MAP_INIT_VADDR(), or at runtime with iosys_map_set_vaddr(). These
Re: [PATCH v2 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
On 2/13/2024 1:16 PM, Dmitry Baryshkov wrote:
On Tue, 13 Feb 2024 at 23:10, Abhinav Kumar wrote:
On 2/13/2024 11:31 AM, Dmitry Baryshkov wrote:
On Tue, 13 Feb 2024 at 20:46, Abhinav Kumar wrote:
On 2/13/2024 10:23 AM, Dmitry Baryshkov wrote:
On Tue, 13 Feb 2024 at 19:32, Abhinav Kumar wrote:
On 2/13/2024 3:18 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:53, Paloma Arellano wrote:
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v2:
- Move timing engine programming to a separate patch from this
one
- Move update_pending_flush_periph() invocation completely to
this patch
- Change the logic of dpu_encoder_get_drm_fmt() so that it only
calls drm_mode_is_420_only() instead of doing additional
unnecessary checks
- Create new functions msm_dp_needs_periph_flush() and it's
supporting function dpu_encoder_needs_periph_flush() to check
if the mode is YUV420 and VSC SDP is enabled before doing a
peripheral flush
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35 +++
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 ++
drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
drivers/gpu/drm/msm/msm_drv.h | 17 -
5 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 7e7796561009a..6280c6be6dca9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -222,6 +222,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct drm_display_info *info;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ info = _enc->connector->display_info;
+ mode = _enc->cached_mode;
+
+ if (drm_mode_is_420_only(info, mode))
+ return DRM_FORMAT_YUV420;
+
+ return DRM_FORMAT_RGB888;
+}
+
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct msm_display_info *disp_info;
+ struct msm_drm_private *priv;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ disp_info = _enc->disp_info;
+ priv = drm_enc->dev->dev_private;
+ mode = _enc->cached_mode;
+
+ return phys_enc->hw_intf->cap->type == INTF_DP && phys_enc->hw_cdm &&
Do we really need to check for phys_enc->hw_cdm here?
hmmm I dont think so. If CDM was not there, then after the last patch,
YUV420 removes will not be present at all.
The only other case I could think of was, if for some reason CDM was
used by some other interface such as WB, then hw_cdm will not be assigned.
But, I think even for that msm_dp_needs_periph_flush() will take care of
it because we use the cached_mode which is assigned only in mode_set().
+
msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]], mode);
+}
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index f43d57d9c74e1..211a3d90eb690 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -341,6 +341,19 @@ static inline enum dpu_3d_blend_mode
dpu_encoder_helper_get_3d_blend_mode(
*/
unsigned int dpu_encoder_helper_get_dsc(struct dpu_encoder_phys *phys_enc);
+/**
+ * dpu_encoder_get_drm_fmt - return DRM fourcc format
+ * @phys_enc: Pointer to physical encoder structure
+ */
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc);
+
+/**
+ * dpu_encoder_needs_periph_flush - return true if physical encoder requires
+ * peripheral flush
+ * @phys_enc: Pointer to physical encoder structure
+ */
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc);
+
/**
* dpu_encoder_helper_split_config - split display configuration helper
function
* This helper function may be used by physical encoders to configure
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index f562beb6f7971..3f102b2813ca8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++
Re: [PATCH 04/10] hid/hid-picolcd: Remove struct backlight_ops.check_fb
Hi Thomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on lee-backlight/for-backlight-next]
[also build test ERROR on lee-backlight/for-backlight-fixes hid/for-next
lee-leds/for-leds-next linus/master v6.8-rc4 next-20240213]
[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/Thomas-Zimmermann/backlight-Match-backlight-device-against-struct-fb_info-bl_dev/20240213-002853
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git
for-backlight-next
patch link:
https://lore.kernel.org/r/20240212162645.5661-5-tzimmermann%40suse.de
patch subject: [PATCH 04/10] hid/hid-picolcd: Remove struct
backlight_ops.check_fb
config: x86_64-rhel-8.3
(https://download.01.org/0day-ci/archive/20240214/202402140514.sb1rerjx-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240214/202402140514.sb1rerjx-...@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/202402140514.sb1rerjx-...@intel.com/
All errors (new ones prefixed by >>):
drivers/hid/hid-picolcd_fb.c: In function 'picolcd_init_framebuffer':
>> drivers/hid/hid-picolcd_fb.c:497:13: error: 'struct fb_info' has no member
>> named 'bl_dev'
497 | info->bl_dev = data->backlight;
| ^~
vim +497 drivers/hid/hid-picolcd_fb.c
459
460 static DEVICE_ATTR(fb_update_rate, 0664, picolcd_fb_update_rate_show,
461 picolcd_fb_update_rate_store);
462
463 /* initialize Framebuffer device */
464 int picolcd_init_framebuffer(struct picolcd_data *data)
465 {
466 struct device *dev = >hdev->dev;
467 struct fb_info *info = NULL;
468 struct picolcd_fb_data *fbdata = NULL;
469 int i, error = -ENOMEM;
470 u32 *palette;
471
472 /* The extra memory is:
473 * - 256*u32 for pseudo_palette
474 * - struct fb_deferred_io
475 */
476 info = framebuffer_alloc(256 * sizeof(u32) +
477 sizeof(struct fb_deferred_io) +
478 sizeof(struct picolcd_fb_data) +
479 PICOLCDFB_SIZE, dev);
480 if (!info)
481 goto err_nomem;
482
483 info->fbdefio = info->par;
484 *info->fbdefio = picolcd_fb_defio;
485 info->par += sizeof(struct fb_deferred_io);
486 palette = info->par;
487 info->par += 256 * sizeof(u32);
488 for (i = 0; i < 256; i++)
489 palette[i] = i > 0 && i < 16 ? 0xff : 0;
490 info->pseudo_palette = palette;
491 info->fbops = _ops;
492 info->var = picolcdfb_var;
493 info->fix = picolcdfb_fix;
494 info->fix.smem_len = PICOLCDFB_SIZE*8;
495
496 #ifdef CONFIG_HID_PICOLCD_BACKLIGHT
> 497 info->bl_dev = data->backlight;
498 #endif
499
500 fbdata = info->par;
501 spin_lock_init(>lock);
502 fbdata->picolcd = data;
503 fbdata->update_rate = PICOLCDFB_UPDATE_RATE_DEFAULT;
504 fbdata->bpp = picolcdfb_var.bits_per_pixel;
505 fbdata->force = 1;
506 fbdata->vbitmap = info->par + sizeof(struct picolcd_fb_data);
507 fbdata->bitmap = vmalloc(PICOLCDFB_SIZE*8);
508 if (fbdata->bitmap == NULL) {
509 dev_err(dev, "can't get a free page for framebuffer\n");
510 goto err_nomem;
511 }
512 info->flags |= FBINFO_VIRTFB;
513 info->screen_buffer = fbdata->bitmap;
514 info->fix.smem_start = (unsigned long)fbdata->bitmap;
515 memset(fbdata->vbitmap, 0xff, PICOLCDFB_SIZE);
516 data->fb_info = info;
517
518 error = picolcd_fb_reset(data, 1);
519 if (error) {
520 dev_err(dev, "failed to configure display\n");
521 goto err_cleanup;
522 }
523
524 error = device_create_file(dev, _attr_fb_update_rate);
525 if (error) {
526 dev_err(dev, "failed to create sysfs attributes\n");
527 goto err_cleanup;
528 }
529
530 fb_deferred_io_ini
Re: [PATCH v2 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
On Tue, 13 Feb 2024 at 23:10, Abhinav Kumar wrote:
>
>
>
> On 2/13/2024 11:31 AM, Dmitry Baryshkov wrote:
> > On Tue, 13 Feb 2024 at 20:46, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/13/2024 10:23 AM, Dmitry Baryshkov wrote:
> >>> On Tue, 13 Feb 2024 at 19:32, Abhinav Kumar
> >>> wrote:
>
>
>
> On 2/13/2024 3:18 AM, Dmitry Baryshkov wrote:
> > On Sat, 10 Feb 2024 at 03:53, Paloma Arellano
> > wrote:
> >>
> >> Adjust the encoder format programming in the case of video mode for DP
> >> to accommodate CDM related changes.
> >>
> >> Changes in v2:
> >>- Move timing engine programming to a separate patch from
> >> this
> >> one
> >>- Move update_pending_flush_periph() invocation completely
> >> to
> >> this patch
> >>- Change the logic of dpu_encoder_get_drm_fmt() so that it
> >> only
> >> calls drm_mode_is_420_only() instead of doing additional
> >> unnecessary checks
> >>- Create new functions msm_dp_needs_periph_flush() and it's
> >> supporting function dpu_encoder_needs_periph_flush() to
> >> check
> >> if the mode is YUV420 and VSC SDP is enabled before doing
> >> a
> >> peripheral flush
> >>
> >> Signed-off-by: Paloma Arellano
> >> ---
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35
> >> +++
> >> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
> >> .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 ++
> >> drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
> >> drivers/gpu/drm/msm/msm_drv.h | 17 -
> >> 5 files changed, 101 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> index 7e7796561009a..6280c6be6dca9 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> @@ -222,6 +222,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
> >>15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
> >> };
> >>
> >> +u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
> >> +{
> >> + struct drm_encoder *drm_enc;
> >> + struct dpu_encoder_virt *dpu_enc;
> >> + struct drm_display_info *info;
> >> + struct drm_display_mode *mode;
> >> +
> >> + drm_enc = phys_enc->parent;
> >> + dpu_enc = to_dpu_encoder_virt(drm_enc);
> >> + info = _enc->connector->display_info;
> >> + mode = _enc->cached_mode;
> >> +
> >> + if (drm_mode_is_420_only(info, mode))
> >> + return DRM_FORMAT_YUV420;
> >> +
> >> + return DRM_FORMAT_RGB888;
> >> +}
> >> +
> >> +bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc)
> >> +{
> >> + struct drm_encoder *drm_enc;
> >> + struct dpu_encoder_virt *dpu_enc;
> >> + struct msm_display_info *disp_info;
> >> + struct msm_drm_private *priv;
> >> + struct drm_display_mode *mode;
> >> +
> >> + drm_enc = phys_enc->parent;
> >> + dpu_enc = to_dpu_encoder_virt(drm_enc);
> >> + disp_info = _enc->disp_info;
> >> + priv = drm_enc->dev->dev_private;
> >> + mode = _enc->cached_mode;
> >> +
> >> + return phys_enc->hw_intf->cap->type == INTF_DP &&
> >> phys_enc->hw_cdm &&
> >
> > Do we really need to check for phys_enc->hw_cdm here?
> >
>
> hmmm I dont think so. If CDM was not there, then after the last patch,
> YUV420 removes will not be present at all.
>
> The only other case I could think of was, if for some reason CDM was
> used by some other interface such as WB, then hw_cdm will not be
> assigned.
>
> But, I think even for that msm_dp_needs_periph_flush() will take care of
> it because we use the cached_mode which is assigned only in mode_set().
>
> >> +
> >> msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]],
> >> mode);
> >> +}
> >>
> >> bool dpu_encoder_is_widebus_enabled(const struct drm_encoder
> >> *drm_enc)
> >> {
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> >> index f43d57d9c74e1..211a3d90eb690 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> >> @@ -341,6 +341,19 @@ static inline enum dpu_3d_blend_mode
> >> dpu_encoder_helper_get_3d_blend_mode(
> >> */
Re: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
Hi Uma,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next next-20240213]
[cannot apply to drm-intel/for-linux-next drm-intel/for-linux-next-fixes
linus/master v6.8-rc4]
[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/Uma-Shankar/drm-color-pipeline-base-work/20240213-144544
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240213064835.139464-2-uma.shankar%40intel.com
patch subject: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
config: x86_64-defconfig
(https://download.01.org/0day-ci/archive/20240214/202402140432.nufiowye-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-12) 11.3.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240214/202402140432.nufiowye-...@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/202402140432.nufiowye-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_colorop.c:268: warning: Function parameter or struct
>> member 'type' not described in 'drm_get_colorop_curve_1d_type_name'
drivers/gpu/drm/drm_colorop.c:268: warning: Excess function parameter
'range' description in 'drm_get_colorop_curve_1d_type_name'
vim +268 drivers/gpu/drm/drm_colorop.c
259
260 /**
261 * drm_get_colorop_curve_1d_type_name - return a string for 1D curve
type
262 * @range: 1d curve type to compute name of
263 *
264 * In contrast to the other drm_get_*_name functions this one here
returns a
265 * const pointer and hence is threadsafe.
266 */
267 const char *drm_get_colorop_curve_1d_type_name(enum
drm_colorop_curve_1d_type type)
> 268 {
269 if (WARN_ON(type >= ARRAY_SIZE(colorop_curve_1d_type_name)))
270 return "unknown";
271
272 return colorop_curve_1d_type_name[type];
273 }
274
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [RFC PATCH net-next v5 07/14] page_pool: devmem support
On Tue, Feb 13, 2024 at 5:28 AM Pavel Begunkov wrote:
>
> On 12/18/23 02:40, Mina Almasry wrote:
> > Convert netmem to be a union of struct page and struct netmem. Overload
> > the LSB of struct netmem* to indicate that it's a net_iov, otherwise
> > it's a page.
> >
> > Currently these entries in struct page are rented by the page_pool and
> > used exclusively by the net stack:
> >
> > struct {
> > unsigned long pp_magic;
> > struct page_pool *pp;
> > unsigned long _pp_mapping_pad;
> > unsigned long dma_addr;
> > atomic_long_t pp_ref_count;
> > };
> >
> > Mirror these (and only these) entries into struct net_iov and implement
> > netmem helpers that can access these common fields regardless of
> > whether the underlying type is page or net_iov.
> > Implement checks for net_iov in netmem helpers which delegate to mm
> > APIs, to ensure net_iov are never passed to the mm stack.
> >
> > Signed-off-by: Mina Almasry
> >
> > ---
> >
> > RFCv5:
> > - Use netmem instead of page* with LSB set.
> > - Use pp_ref_count for refcounting net_iov.
> > - Removed many of the custom checks for netmem.
> >
> > v1:
> > - Disable fragmentation support for iov properly.
> > - fix napi_pp_put_page() path (Yunsheng).
> > - Use pp_frag_count for devmem refcounting.
> >
> > ---
> > include/net/netmem.h| 145 ++--
> > include/net/page_pool/helpers.h | 25 +++---
> > net/core/page_pool.c| 26 +++---
> > net/core/skbuff.c | 9 +-
> > 4 files changed, 164 insertions(+), 41 deletions(-)
> >
> > diff --git a/include/net/netmem.h b/include/net/netmem.h
> > index 31f338f19da0..7557aecc0f78 100644
> > --- a/include/net/netmem.h
> > +++ b/include/net/netmem.h
> > @@ -12,11 +12,47 @@
> >
> > /* net_iov */
> >
> > +DECLARE_STATIC_KEY_FALSE(page_pool_mem_providers);
> > +
> > +/* We overload the LSB of the struct page pointer to indicate whether it's
> > + * a page or net_iov.
> > + */
> > +#define NET_IOV 0x01UL
> > +
> > struct net_iov {
> > + unsigned long __unused_padding;
> > + unsigned long pp_magic;
> > + struct page_pool *pp;
> > struct dmabuf_genpool_chunk_owner *owner;
> > unsigned long dma_addr;
> > + atomic_long_t pp_ref_count;
> > };
>
> I wonder if it would be better to extract a common sub-struct
> used in struct page, struct_group_tagged can help to avoid
> touching old code:
>
> struct page {
> unsigned long flags;
> union {
> ...
> struct_group_tagged(, ...,
> /**
> * @pp_magic: magic value to avoid recycling non
> * page_pool allocated pages.
> */
> unsigned long pp_magic;
> struct page_pool *pp;
> unsigned long _pp_mapping_pad;
> unsigned long dma_addr;
> atomic_long_t pp_ref_count;
> );
> };
> }
>
> struct net_iov {
> unsigned long pad;
> struct p;
> };
>
>
> A bit of a churn with the padding and nesting net_iov but looks
> sturdier. No duplication, and you can just check positions of the
> structure instead of per-field NET_IOV_ASSERT_OFFSET, which you
> have to not forget to update e.g. when adding a new field. Also,
Yes, this is nicer. If possible I'll punt it to a minor cleanup as a
follow up change. Logistically I think if this series need-not touch
code outside of net/, that's better.
> with the change __netmem_clear_lsb can return a pointer to that
> structure, casting struct net_iov when it's a page is a bit iffy.
>
> And the next question would be whether it'd be a good idea to encode
> iov vs page not by setting a bit but via one of the fields in the
> structure, maybe pp_magic.
>
I will push back against this, for 2 reasons:
1. I think pp_magic's first 2 bits (and maybe more) are used by mm
code and thus I think extending usage of pp_magic in this series is a
bit iffy and I would like to avoid it. I just don't want to touch the
semantics of struct page if I don't have to.
2. I think this will be a measurable perf regression. Currently we can
tell if a pointer is a page or net_iov without dereferencing the
pointer and dirtying the cache-line. This will cause us to possibly
dereference the pointer in areas where we don't need to. I think I had
an earlier version of this code that required a dereference to tell if
a page was devmem and Eric pointed to me it was a perf regression.
I also don't see any upside of using pp_magic, other than making the
code slightly more readable, maybe.
> With that said I'm a bit concerned about the net_iov size. If each
> represents 4096 bytes and you're registering 10MB, then you need
> 30 pages worth of memory just for the iov array. Makes kvmalloc
> a must even for relatively small sizes.
>
This I think is an age-old challenge with
Re: [PATCH v2 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
On 2/13/2024 11:31 AM, Dmitry Baryshkov wrote:
On Tue, 13 Feb 2024 at 20:46, Abhinav Kumar wrote:
On 2/13/2024 10:23 AM, Dmitry Baryshkov wrote:
On Tue, 13 Feb 2024 at 19:32, Abhinav Kumar wrote:
On 2/13/2024 3:18 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:53, Paloma Arellano wrote:
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v2:
- Move timing engine programming to a separate patch from this
one
- Move update_pending_flush_periph() invocation completely to
this patch
- Change the logic of dpu_encoder_get_drm_fmt() so that it only
calls drm_mode_is_420_only() instead of doing additional
unnecessary checks
- Create new functions msm_dp_needs_periph_flush() and it's
supporting function dpu_encoder_needs_periph_flush() to check
if the mode is YUV420 and VSC SDP is enabled before doing a
peripheral flush
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35 +++
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 ++
drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
drivers/gpu/drm/msm/msm_drv.h | 17 -
5 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 7e7796561009a..6280c6be6dca9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -222,6 +222,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct drm_display_info *info;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ info = _enc->connector->display_info;
+ mode = _enc->cached_mode;
+
+ if (drm_mode_is_420_only(info, mode))
+ return DRM_FORMAT_YUV420;
+
+ return DRM_FORMAT_RGB888;
+}
+
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct msm_display_info *disp_info;
+ struct msm_drm_private *priv;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ disp_info = _enc->disp_info;
+ priv = drm_enc->dev->dev_private;
+ mode = _enc->cached_mode;
+
+ return phys_enc->hw_intf->cap->type == INTF_DP && phys_enc->hw_cdm &&
Do we really need to check for phys_enc->hw_cdm here?
hmmm I dont think so. If CDM was not there, then after the last patch,
YUV420 removes will not be present at all.
The only other case I could think of was, if for some reason CDM was
used by some other interface such as WB, then hw_cdm will not be assigned.
But, I think even for that msm_dp_needs_periph_flush() will take care of
it because we use the cached_mode which is assigned only in mode_set().
+
msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]], mode);
+}
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index f43d57d9c74e1..211a3d90eb690 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -341,6 +341,19 @@ static inline enum dpu_3d_blend_mode
dpu_encoder_helper_get_3d_blend_mode(
*/
unsigned int dpu_encoder_helper_get_dsc(struct dpu_encoder_phys *phys_enc);
+/**
+ * dpu_encoder_get_drm_fmt - return DRM fourcc format
+ * @phys_enc: Pointer to physical encoder structure
+ */
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc);
+
+/**
+ * dpu_encoder_needs_periph_flush - return true if physical encoder requires
+ * peripheral flush
+ * @phys_enc: Pointer to physical encoder structure
+ */
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc);
+
/**
* dpu_encoder_helper_split_config - split display configuration helper
function
* This helper function may be used by physical encoders to configure
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index f562beb6f7971..3f102b2813ca8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -413,8 +413,15 @@ static int dpu_encoder_phys_vid_control_vblank_irq(
static
Re: [PATCH] drm/rockchip: vop2: add a missing unlock in vop2_crtc_atomic_enable()
On Fri, 19 Jan 2024 11:08:40 -0800, Harshit Mogalapalli wrote: > Unlock before returning on the error path. > > Applied, thanks! [1/1] drm/rockchip: vop2: add a missing unlock in vop2_crtc_atomic_enable() commit: b6ddaa63f728d26c12048aed76be99c24f435c41 Best regards, -- Heiko Stuebner
Re: [RFC PATCH net-next v5 05/14] netdev: netdevice devmem allocator
On Tue, Feb 13, 2024 at 5:24 AM Pavel Begunkov wrote:
>
> On 12/18/23 02:40, Mina Almasry wrote:
> > Implement netdev devmem allocator. The allocator takes a given struct
> > netdev_dmabuf_binding as input and allocates net_iov from that
> > binding.
> >
> > The allocation simply delegates to the binding's genpool for the
> > allocation logic and wraps the returned memory region in a net_iov
> > struct.
> >
> > Signed-off-by: Willem de Bruijn
> > Signed-off-by: Kaiyuan Zhang
> > Signed-off-by: Mina Almasry
> >
> > ---
> >
> > v1:
> > - Rename devmem -> dmabuf (David).
> >
> > ---
> > include/net/devmem.h | 12
> > include/net/netmem.h | 26 ++
> > net/core/dev.c | 38 ++
> > 3 files changed, 76 insertions(+)
> >
> ...
> > diff --git a/include/net/netmem.h b/include/net/netmem.h
> > index 45eb42d9990b..7fce2efc8707 100644
> > --- a/include/net/netmem.h
> > +++ b/include/net/netmem.h
> > @@ -14,8 +14,34 @@
> >
> > struct net_iov {
> > struct dmabuf_genpool_chunk_owner *owner;
> > + unsigned long dma_addr;
> > };
> >
> > +static inline struct dmabuf_genpool_chunk_owner *
> > +net_iov_owner(const struct net_iov *niov)
> > +{
> > + return niov->owner;
> > +}
> > +
> > +static inline unsigned int net_iov_idx(const struct net_iov *niov)
> > +{
> > + return niov - net_iov_owner(niov)->niovs;
> > +}
> > +
> > +static inline dma_addr_t net_iov_dma_addr(const struct net_iov *niov)
> > +{
> > + struct dmabuf_genpool_chunk_owner *owner = net_iov_owner(niov);
> > +
> > + return owner->base_dma_addr +
> > +((dma_addr_t)net_iov_idx(niov) << PAGE_SHIFT);
>
> Looks like it should have been niov->dma_addr
>
Yes, indeed. Thanks for catching.
> > +}
> > +
> > +static inline struct netdev_dmabuf_binding *
> > +net_iov_binding(const struct net_iov *niov)
> > +{
> > + return net_iov_owner(niov)->binding;
> > +}
> > +
> > /* netmem */
> >
> > struct netmem {
> ...
>
> --
> Pavel Begunkov
--
Thanks,
Mina
Re: [PATCH i-g-t v3] benchmarks: Add VKMS benchmark
On 13/02/24 15:06, Kamil Konieczny wrote:
> Hi Arthur,
> On 2024-02-09 at 16:39:09 -0300, Arthur Grillo wrote:
>
> I will merge this with different description:
>
> [PATCH i-g-t v3] benchmarks: Add KMS frambuffer stress benchmark
>
> Is this ok?
Its ok
Best Regards,
~Arthur Grillo
>
> Regards,
> Kamil
>
>> Create a benchmark for the VKMS driver. Use a KMS layout with deliberate
>> odd sizes to try to avoid alignment accidents and run it for FRAME_COUNT
>> frames flipping framebuffers in each plane.
>>
>> This benchmark was suggested by Pekka Paalanen to better analyse
>> possible performance regression on the Virtual Kernel Modesetting(VKMS)
>> driver.
>>
>> With this benchmark I was able to determine two performance regression:
>>
>> - 322d716a3e8a ("drm/vkms: isolate pixel conversion functionality")
>> - cc4fd2934d41 ("drm/vkms: Isolate writeback pixel conversion functions")
>>
>> Link: https://lore.kernel.org/all/20240202214527.1d97c881@ferris.localdomain/
>> Suggested-by: Pekka Paalanen
>> Acked-by: Pekka Paalanen
>> Acked-by: Maíra Canal
>> Acked-by: Kamil Konieczny
>> Signed-off-by: Arthur Grillo
>> ---
>> Changes in v3:
>> - Change primary plane width to not extend outside the CRTC size
>> - Explicitly set a big CRTC size (Peeka Paalanen)
>> - Report time spent in the loop (Peeka Paalanen)
>> - Put file name in alphabetical order on meson script (Kamil Konieczny)
>> - Link to v2:
>> https://lore.kernel.org/r/20240208-bench-v2-1-1eccee105...@riseup.net
>>
>> Changes in v2:
>> - Zero initialize data
>> - Don't wrap igt_create_* functions (Juha-Pekka Heikkila)
>> - Add a `break;` when a pipe is found (Pekka Paalanen)
>> - Rename file to kms_fb_stress.c (Kamil Konieczny)
>> - Replace 2 by NUM_FBS (Juha-Pekka Heikkila)
>> - Replace license text by SPDX License (Kamil Konieczny)
>> - Move explanations to commit description (Kamil Konieczny)
>> - Require output after find_wb_output() (Pekka Paalanen & Juha-Pekka
>> Heikkila)
>> - Remove unnecessary commit (Pekka Paalanen)
>> - Link to v1:
>> https://lore.kernel.org/r/20240207-bench-v1-1-7135ad426...@riseup.net
>> ---
>> benchmarks/kms_fb_stress.c | 208
>> +
>> benchmarks/meson.build | 1 +
>> 2 files changed, 209 insertions(+)
>>
>> diff --git a/benchmarks/kms_fb_stress.c b/benchmarks/kms_fb_stress.c
>> new file mode 100644
>> index ..9a0e98bed8ad
>> --- /dev/null
>> +++ b/benchmarks/kms_fb_stress.c
>> @@ -0,0 +1,208 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright © 2024 Arthur Grillo
>> + */
>> +
>> +#include "igt.h"
>> +
>> +#define FRAME_COUNT 100
>> +#define NUM_FBS 2
>> +
>> +struct rect_t {
>> +int x, y;
>> +int width, height;
>> +};
>> +
>> +struct plane_t {
>> +igt_plane_t *base;
>> +struct rect_t rect;
>> +uint32_t format;
>> +struct igt_fb fbs[NUM_FBS];
>> +};
>> +
>> +struct kms_t {
>> +struct rect_t crtc;
>> +struct plane_t primary;
>> +struct plane_t overlay_a;
>> +struct plane_t overlay_b;
>> +struct plane_t writeback;
>> +};
>> +
>> +struct data_t {
>> +int fd;
>> +igt_display_t display;
>> +igt_output_t *wb_output;
>> +drmModeModeInfo *mode;
>> +struct kms_t kms;
>> +};
>> +
>> +static void plane_setup(struct plane_t *plane, int index)
>> +{
>> +igt_plane_set_size(plane->base, plane->rect.width, plane->rect.height);
>> +igt_plane_set_position(plane->base, plane->rect.x, plane->rect.y);
>> +igt_plane_set_fb(plane->base, >fbs[index]);
>> +}
>> +
>> +static void gen_fbs(struct data_t *data)
>> +{
>> +struct kms_t *kms = >kms;
>> +drmModeModeInfo *mode = igt_output_get_mode(data->wb_output);
>> +
>> +for (int i = 0; i < NUM_FBS; i++) {
>> +igt_create_color_fb(data->fd, kms->primary.rect.width,
>> kms->primary.rect.height,
>> +kms->primary.format, DRM_FORMAT_MOD_LINEAR,
>> +!i, i, i,
>> +>primary.fbs[i]);
>> +
>> +igt_create_color_fb(data->fd, kms->overlay_a.rect.width,
>> kms->overlay_a.rect.height,
>> +kms->overlay_a.format,
>> DRM_FORMAT_MOD_LINEAR,
>> +i, !i, i,
>> +>overlay_a.fbs[i]);
>> +
>> +igt_create_color_fb(data->fd, kms->overlay_b.rect.width,
>> kms->overlay_b.rect.height,
>> +kms->overlay_b.format,
>> DRM_FORMAT_MOD_LINEAR,
>> +i, i, !i,
>> +>overlay_b.fbs[i]);
>> +
>> +kms->writeback.rect.width = mode->hdisplay;
>> +kms->writeback.rect.height = mode->vdisplay;
>> +igt_create_fb(data->fd, kms->writeback.rect.width,
>> kms->writeback.rect.height,
>> + kms->writeback.format, DRM_FORMAT_MOD_LINEAR,
>> + >writeback.fbs[i]);
>> +}
>> +}
>>
[PATCH] drm: ci: use clk_ignore_unused for apq8016
If the ADV7511 bridge driver is compiled as a module, while DRM_MSM is
built-in, the clk_disable_unused congests with the runtime PM handling
of the DSI PHY for the clk_prepare_lock(). This causes apq8016 runner to
fail without completing any jobs ([1]). Drop the BM_CMDLINE which
duplicate the command line from the .baremetal-igt-arm64 clause and
enforce the clk_ignore_unused kernelarg instead to make apq8016 runner
work.
[1] https://gitlab.freedesktop.org/drm/msm/-/jobs/54990475
Fixes: 0119c894ab0d ("drm: Add initial ci/ subdirectory")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/ci/test.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 355b794ef2b1..b9f864e062df 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -119,7 +119,7 @@ msm:apq8016:
DRIVER_NAME: msm
BM_DTB: https://${PIPELINE_ARTIFACTS_BASE}/arm64/apq8016-sbc-usb-host.dtb
GPU_VERSION: apq8016
-BM_CMDLINE: "ip=dhcp console=ttyMSM0,115200n8 $BM_KERNEL_EXTRA_ARGS
root=/dev/nfs rw nfsrootdebug nfsroot=,tcp,nfsvers=4.2 init=/init
$BM_KERNELARGS"
+BM_KERNEL_EXTRA_ARGS: clk_ignore_unused
RUNNER_TAG: google-freedreno-db410c
script:
- ./install/bare-metal/fastboot.sh
--
2.39.2
Re: [PATCH v2] drm/i915: Add GuC submission interface version query
On Fri, 2024-02-09 at 09:06 +, Tvrtko Ursulin wrote:
> On 08/02/2024 17:55, Souza, Jose wrote:
> > On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
> > > On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> > > > On 08/02/2024 14:30, Souza, Jose wrote:
> > > > > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > > > > From: Tvrtko Ursulin
> > > > > >
> > > > > > Add a new query to the GuC submission interface version.
> > > > > >
> > > > > > Mesa intends to use this information to check for old firmware
> > > > > > versions
> > > > > > with a known bug where using the render and compute command
> > > > > > streamers
> > > > > > simultaneously can cause GPU hangs due issues in firmware
> > > > > > scheduling.
> > > > > >
> > > > > > Based on patches from Vivaik and Joonas.
> > > > > >
> > > > > > Compile tested only.
> > > > > >
> > > > > > v2:
> > > > > >* Added branch version.
> > > > >
> > > > > Reviewed-by: José Roberto de Souza
> > > > > Tested-by: José Roberto de Souza
> > > > > UMD: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233
> > > >
> > > > Thanks, but please we also need to close down on the branch number
> > > > situation. I.e. be sure what is the failure mode in shipping Mesa with
> > > > the change as it stands in the MR linked. What platforms could start
> > > > failing and when, depending on GuC FW release eventualities.
> > >
> > > yes, I have asked John Harrison for a documentation link about the
> > > firmware versioning.
> >
> > Got the documentation link, MR updated.
> > Will ask for reviews in Mesa side.
>
> Is it then understood and accepted that should GuC ever update the
> branch number on any given platform, that platform, for all deployed
> Mesa's in the field, will automatically revert to no async queues and so
> cause a silent performance regression?
yes, understood and accepted.
The Mesa MR is now reviewed, thank you Sagar.
>
> Regards,
>
> Tvrtko
>
> >
> > >
> > > >
> > > > Regards,
> > > >
> > > > Tvrtko
> > > >
> > > > > > Signed-off-by: Tvrtko Ursulin
> > > > > > Cc: Kenneth Graunke
> > > > > > Cc: Jose Souza
> > > > > > Cc: Sagar Ghuge
> > > > > > Cc: Paulo Zanoni
> > > > > > Cc: John Harrison
> > > > > > Cc: Rodrigo Vivi
> > > > > > Cc: Jani Nikula
> > > > > > Cc: Tvrtko Ursulin
> > > > > > Cc: Vivaik Balasubrawmanian
> > > > > > Cc: Joonas Lahtinen
> > > > > > ---
> > > > > >drivers/gpu/drm/i915/i915_query.c | 33
> > > > > > +++
> > > > > >include/uapi/drm/i915_drm.h | 12 +++
> > > > > >2 files changed, 45 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_query.c
> > > > > > b/drivers/gpu/drm/i915/i915_query.c
> > > > > > index 00871ef99792..d4dba1240b40 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_query.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_query.c
> > > > > > @@ -551,6 +551,38 @@ static int query_hwconfig_blob(struct
> > > > > > drm_i915_private *i915,
> > > > > > return hwconfig->size;
> > > > > >}
> > > > > >
> > > > > > +static int
> > > > > > +query_guc_submission_version(struct drm_i915_private *i915,
> > > > > > +struct drm_i915_query_item *query)
> > > > > > +{
> > > > > > + struct drm_i915_query_guc_submission_version __user *query_ptr =
> > > > > > +
> > > > > > u64_to_user_ptr(query->data_ptr);
> > > > > > + struct drm_i915_query_guc_submission_version ver;
> > > > > > + struct intel_guc *guc = _gt(i915)->uc.guc;
> > > > > > + const size_t size = sizeof(ver);
> > > > > > + int ret;
> > > > > > +
> > > > > > + if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> > > > > > + return -ENODEV;
> > > > > > +
> > > > > > + ret = copy_query_item(, size, size, query);
> > > > > > + if (ret != 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + if (ver.branch || ver.major || ver.minor || ver.patch)
> > > > > > + return -EINVAL;
> > > > > > +
> > > > > > + ver.branch = 0;
> > > > > > + ver.major = guc->submission_version.major;
> > > > > > + ver.minor = guc->submission_version.minor;
> > > > > > + ver.patch = guc->submission_version.patch;
> > > > > > +
> > > > > > + if (copy_to_user(query_ptr, , size))
> > > > > > + return -EFAULT;
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > >static int (* const i915_query_funcs[])(struct drm_i915_private
> > > > > > *dev_priv,
> > > > > > struct drm_i915_query_item
> > > > > > *query_item) = {
> > > > > > query_topology_info,
> > > > > > @@ -559,6 +591,7 @@ static int (* const i915_query_funcs[])(struct
> > > > > > drm_i915_private *dev_priv,
> > > > > > query_memregion_info,
> > > > > > query_hwconfig_blob,
> > > > > > query_geometry_subslices,
> > > > > > + query_guc_submission_version,
> > > > > >
Re: (subset) [PATCH v2 1/6] dt-bindings: display: rockchip: rockchip, dw-hdmi: remove port property
On Wed, 31 Jan 2024 22:14:29 +0100, Johan Jonker wrote: > The hdmi-connector nodes are now functional and the new way to model > hdmi ports nodes with both in and output port subnodes. Unfortunately > with the conversion to YAML the old method with only an input port node > was used. Later the new method was also added to the binding. > A binding must be unambiguously, so remove the old port property > entirely and make port@0 and port@1 a requirement as all > upstream dts files are updated as well and because checking > deprecated stuff is a bit pointless. > Update the example to avoid use of the removed property. > > [...] Applied, thanks! [3/6] ARM: dts: rockchip: fix rk3288 hdmi ports node commit: 585e4dc07100a6465b3da8d24e46188064c1c925 [4/6] ARM: dts: rockchip: fix rk322x hdmi ports node commit: 15a5ed03000cf61daf87d14628085cb1bc8ae72c [5/6] arm64: dts: rockchip: fix rk3328 hdmi ports node commit: 1d00ba4700d1e0f88ae70d028d2e17e39078fa1c [6/6] arm64: dts: rockchip: fix rk3399 hdmi ports node commit: f051b6ace7ffcc48d6d1017191f167c0a85799f6 Best regards, -- Heiko Stuebner
Re: [PATCH v2 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
On Tue, 13 Feb 2024 at 20:46, Abhinav Kumar wrote:
>
>
>
> On 2/13/2024 10:23 AM, Dmitry Baryshkov wrote:
> > On Tue, 13 Feb 2024 at 19:32, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/13/2024 3:18 AM, Dmitry Baryshkov wrote:
> >>> On Sat, 10 Feb 2024 at 03:53, Paloma Arellano
> >>> wrote:
>
> Adjust the encoder format programming in the case of video mode for DP
> to accommodate CDM related changes.
>
> Changes in v2:
> - Move timing engine programming to a separate patch from this
> one
> - Move update_pending_flush_periph() invocation completely to
> this patch
> - Change the logic of dpu_encoder_get_drm_fmt() so that it only
> calls drm_mode_is_420_only() instead of doing additional
> unnecessary checks
> - Create new functions msm_dp_needs_periph_flush() and it's
> supporting function dpu_encoder_needs_periph_flush() to check
> if the mode is YUV420 and VSC SDP is enabled before doing a
> peripheral flush
>
> Signed-off-by: Paloma Arellano
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35 +++
> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
> .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 ++
> drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
> drivers/gpu/drm/msm/msm_drv.h | 17 -
> 5 files changed, 101 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 7e7796561009a..6280c6be6dca9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -222,6 +222,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
> 15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
> };
>
> +u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
> +{
> + struct drm_encoder *drm_enc;
> + struct dpu_encoder_virt *dpu_enc;
> + struct drm_display_info *info;
> + struct drm_display_mode *mode;
> +
> + drm_enc = phys_enc->parent;
> + dpu_enc = to_dpu_encoder_virt(drm_enc);
> + info = _enc->connector->display_info;
> + mode = _enc->cached_mode;
> +
> + if (drm_mode_is_420_only(info, mode))
> + return DRM_FORMAT_YUV420;
> +
> + return DRM_FORMAT_RGB888;
> +}
> +
> +bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc)
> +{
> + struct drm_encoder *drm_enc;
> + struct dpu_encoder_virt *dpu_enc;
> + struct msm_display_info *disp_info;
> + struct msm_drm_private *priv;
> + struct drm_display_mode *mode;
> +
> + drm_enc = phys_enc->parent;
> + dpu_enc = to_dpu_encoder_virt(drm_enc);
> + disp_info = _enc->disp_info;
> + priv = drm_enc->dev->dev_private;
> + mode = _enc->cached_mode;
> +
> + return phys_enc->hw_intf->cap->type == INTF_DP &&
> phys_enc->hw_cdm &&
> >>>
> >>> Do we really need to check for phys_enc->hw_cdm here?
> >>>
> >>
> >> hmmm I dont think so. If CDM was not there, then after the last patch,
> >> YUV420 removes will not be present at all.
> >>
> >> The only other case I could think of was, if for some reason CDM was
> >> used by some other interface such as WB, then hw_cdm will not be assigned.
> >>
> >> But, I think even for that msm_dp_needs_periph_flush() will take care of
> >> it because we use the cached_mode which is assigned only in mode_set().
> >>
> +
> msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]], mode);
> +}
>
> bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
> {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> index f43d57d9c74e1..211a3d90eb690 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> @@ -341,6 +341,19 @@ static inline enum dpu_3d_blend_mode
> dpu_encoder_helper_get_3d_blend_mode(
> */
> unsigned int dpu_encoder_helper_get_dsc(struct dpu_encoder_phys
> *phys_enc);
>
> +/**
> + * dpu_encoder_get_drm_fmt - return DRM fourcc format
> + * @phys_enc: Pointer to physical encoder structure
> + */
> +u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc);
> +
> +/**
> + * dpu_encoder_needs_periph_flush - return true if physical encoder
> requires
> + *
Re: (subset) [PATCH v2 1/6] dt-bindings: display: rockchip: rockchip, dw-hdmi: remove port property
On Wed, 31 Jan 2024 22:14:29 +0100, Johan Jonker wrote: > The hdmi-connector nodes are now functional and the new way to model > hdmi ports nodes with both in and output port subnodes. Unfortunately > with the conversion to YAML the old method with only an input port node > was used. Later the new method was also added to the binding. > A binding must be unambiguously, so remove the old port property > entirely and make port@0 and port@1 a requirement as all > upstream dts files are updated as well and because checking > deprecated stuff is a bit pointless. > Update the example to avoid use of the removed property. > > [...] Applied, thanks! [1/6] dt-bindings: display: rockchip: rockchip,dw-hdmi: remove port property commit: 0d192c4c72ce00ab07a6b27f068607e21f754a46 [2/6] dt-bindings: display: rockchip,dw-hdmi: add power-domains property commit: 6b1f93ea345947c94bf3a7a6e668a2acfd310918 Best regards, -- Heiko Stuebner
Re: [PATCH 1/2] [v3] nouveau: add command-line GSP-RM registry support
On Tue, 2024-02-13 at 16:43 +0100, Danilo Krummrich wrote:
> > +struct registry_list_entry {
> > + struct list_head list;
>
> Nit: 'head' or 'entry' might be more suitable.
Will fix in v4.
>
> > + size_t name_len;
> > + u32 type;
>
> I prefer to represent type as enum or use a define for '1 = integer' instead.
> This also gets you rid of the need to explicitly explain it's meaning in the
> documentation of add_registry().
Will fix in v4.
>
> > + u32 data;
> > + u32 length;
> > + char name[];
> > +};
> > +
> > +/**
> > + * add_registry -- adds a registry entry
> > + * @gsp: gsp pointer
> > + * @name: name of the registry key
> > + * @type: type of data (1 = integer)
> > + * @data: value
> > + * @length: size of data, in bytes
> > + *
> > + * Adds a registry key/value pair to the registry database.
> > + *
> > + * Currently, only 32-bit integers (type == 1, length == 4) are supported.
>
> What if we pass something else? This function doesn't seem to ensure nothing
> else is accepted. Although I recognize that it's only used by
> add_registry_num()
> enforcing this limitation by it's function signature.
GSP-RM technically supports two other types: binary data and strings. For
example, apparently it's possible to override the VBIOS itself with a
registry key. However, I'm not familiar with any actual non-numeric
registry keys that the user would set.
I can add support for binary data and strings.
>
> > + *
> > + * This function collects the registry information in a linked list. After
> > + * all registry keys have been added, build_registry() is used to create
> > the
> > + * RPC data structure.
> > + *
> > + * registry_rpc_size is a running total of the size of all registry keys.
> > + * It's used to avoid an O(n) calculation of the size when the RPC is
> > built.
> > + *
> > + * Returns 0 on success, or negative error code on error.
> > + */
> > +static int add_registry(struct nvkm_gsp *gsp, const char *name, u32 type,
> > u32 data, u32 length)
> > +{
> > + struct registry_list_entry *reg;
> > + size_t nlen = strlen(name) + 1;
> > +
> > + /* Set an arbitrary limit to avoid problems with broken command lines */
> > + if (strlen(name) > 64)
>
> Could re-use nlen for this check.
Will fix in v4.
>
> > + return -EFBIG;
>
> This error code doesn't seem to apply here, prefer EINVAL.
You don't like creative usage of error codes?
> > + while ((start = strsep(, ";"))) {
> > + long value;
> > +
> > + equal = strchr(start, '=');
> > + if (!equal || (equal == start) || !isdigit(equal[1])) {
> > + nvkm_error(>subdev,
> > + "ignoring invalid registry string
> > '%s'\n", start);
> > + continue;
> > + }
> >
> > - rpc->numEntries = NV_GSP_REG_NUM_ENTRIES;
> > + ret = kstrtol(equal + 1, 0, );
> > + if (ret) {
> > + nvkm_error(>subdev,
> > + "ignoring invalid registry value in
> > '%s'\n", start);
> > + continue;
> > + }
>
> At a first glance, the string parsing looks correct to me. Did you test with
> invalid
> strings as well?
Yes. It would be nice if there were a regex parser in the kernel, but I
think I did a good job testing and rejecting strings.
> > - str_offset = offsetof(typeof(*rpc), entries[NV_GSP_REG_NUM_ENTRIES]);
> > - strings = (char *)>entries[NV_GSP_REG_NUM_ENTRIES];
> > - for (i = 0; i < NV_GSP_REG_NUM_ENTRIES; i++) {
> > - int name_len = strlen(r535_registry_entries[i].name) + 1;
> > -
> > - rpc->entries[i].nameOffset = str_offset;
> > - rpc->entries[i].type = 1;
> > - rpc->entries[i].data = r535_registry_entries[i].value;
> > - rpc->entries[i].length = 4;
> > - memcpy(strings, r535_registry_entries[i].name, name_len);
> > - strings += name_len;
> > - str_offset += name_len;
> > + /* Truncate the key=value string to just key */
> > + *equal = 0;
>
> What's the purpose for that?
Take for example, this parameter passed to Nouveau:
NVreg_RegistryDwords="RM1457588=1;TEST=53"
The strsep() call points 'next' to "RM1457588=1", replacing the ; with \0.
'equal' then points to the '='. kstrtol() converts the "1" to 1. So all
that's left is extracting the "RM1457588" into its own string. That's what
"*equal = 0" does.
Re: (subset) [PATCH 0/7] Add Support for RK3566 Powkiddy RGB10MAX3
On Mon, 12 Feb 2024 12:49:43 -0600, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RGB10MAX3 handheld gaming console. > > [1] > https://powkiddy.com/products/pre-sale-powkiddy-rgb10max3-handheld-game-console > > Chris Morgan (7): > dt-bindings: display: st7703: Add Powkiddy RGB10MAX3 panel > drm/panel: st7703: Add Powkiddy RGB10MAX3 Panel Support > dt-bindings: display: Document ST7703 panel rotation > drm/panel: st7703: Add Panel Rotation Support > arm64: dts: rockchip: Update powkiddy rk2023 dtsi for RGB10MAX3 > dt-bindings: arm: rockchip: Add Powkiddy RGB10MAX3 > arm64: dts: rockchip: Add Powkiddy RGB10MAX3 > > [...] Applied, thanks! [5/7] arm64: dts: rockchip: Update powkiddy rk2023 dtsi for RGB10MAX3 commit: 039a03c377d64ec832a8fb1b8f8b5badd404989f [6/7] dt-bindings: arm: rockchip: Add Powkiddy RGB10MAX3 commit: fbe7823623a8c02759afdfb521709f4fa216849a [7/7] arm64: dts: rockchip: Add Powkiddy RGB10MAX3 commit: 4b325c0d4f539b553a4529f16476f08757779293 Best regards, -- Heiko Stuebner
Re: [PATCH v6 31/36] drm/rockchip: inno_hdmi: Switch to HDMI connector
Am Montag, 12. Februar 2024, 14:13:14 CET schrieb Maxime Ripard:
> The new HDMI connector infrastructure allows to remove some boilerplate,
> especially to generate infoframes. Let's switch to it.
>
> Signed-off-by: Maxime Ripard
Acked-by: Heiko Stuebner
> ---
> drivers/gpu/drm/rockchip/inno_hdmi.c | 123
> ---
> 1 file changed, 42 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
> b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index 1d2261643743..d59947679042 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -67,9 +67,7 @@ struct inno_hdmi {
>
> struct inno_hdmi_connector_state {
> struct drm_connector_state base;
> - unsigned intenc_out_format;
> unsigned intcolorimetry;
> - boolrgb_limited_range;
> };
>
> static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
> @@ -257,26 +255,29 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
> inno_hdmi_standby(hdmi);
> }
>
> -static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
> - enum hdmi_infoframe_type type)
> +static int inno_hdmi_disable_frame(struct drm_connector *connector,
> +enum hdmi_infoframe_type type)
> {
> - struct drm_connector *connector = >connector;
> + struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
>
> if (type != HDMI_INFOFRAME_TYPE_AVI) {
> drm_err(connector->dev,
> "Unsupported infoframe type: %u\n", type);
> - return;
> + return 0;
> }
>
> hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, INFOFRAME_AVI);
> +
> + return 0;
> }
>
> -static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
> - union hdmi_infoframe *frame, enum
> hdmi_infoframe_type type)
> +static int inno_hdmi_upload_frame(struct drm_connector *connector,
> + enum hdmi_infoframe_type type,
> + const u8 *buffer, size_t len)
> {
> - struct drm_connector *connector = >connector;
> + struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
> u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
> - ssize_t rc, i;
> + ssize_t i;
>
> if (type != HDMI_INFOFRAME_TYPE_AVI) {
> drm_err(connector->dev,
> @@ -284,59 +285,19 @@ static int inno_hdmi_upload_frame(struct inno_hdmi
> *hdmi,
> return 0;
> }
>
> - inno_hdmi_disable_frame(hdmi, type);
> + inno_hdmi_disable_frame(connector, type);
>
> - rc = hdmi_infoframe_pack(frame, packed_frame,
> - sizeof(packed_frame));
> - if (rc < 0)
> - return rc;
> -
> - for (i = 0; i < rc; i++)
> + for (i = 0; i < len; i++)
> hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
> packed_frame[i]);
>
> return 0;
> }
>
> -static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
> - struct drm_display_mode *mode)
> -{
> - struct drm_connector *connector = >connector;
> - struct drm_connector_state *conn_state = connector->state;
> - struct inno_hdmi_connector_state *inno_conn_state =
> - to_inno_hdmi_conn_state(conn_state);
> - union hdmi_infoframe frame;
> - int rc;
> -
> - rc = drm_hdmi_avi_infoframe_from_display_mode(,
> - >connector,
> - mode);
> - if (rc) {
> - inno_hdmi_disable_frame(hdmi, HDMI_INFOFRAME_TYPE_AVI);
> - return rc;
> - }
> -
> - if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444)
> - frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
> - else if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV422)
> - frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
> - else
> - frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> -
> - if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
> - drm_hdmi_avi_infoframe_quant_range(,
> -connector, mode,
> -
> inno_conn_state->rgb_limited_range ?
> -
> HDMI_QUANTIZATION_RANGE_LIMITED :
> -
> HDMI_QUANTIZATION_RANGE_FULL);
> - } else {
> - frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> - frame.avi.ycc_quantization_range =
> - HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> - }
> -
> - return inno_hdmi_upload_frame(hdmi, , HDMI_INFOFRAME_TYPE_AVI);
> -}
>
Re: (subset) [PATCH 0/7] Add Support for RK3566 Powkiddy RGB10MAX3
On Mon, 12 Feb 2024 12:49:43 -0600, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RGB10MAX3 handheld gaming console. > > [1] > https://powkiddy.com/products/pre-sale-powkiddy-rgb10max3-handheld-game-console > > Chris Morgan (7): > dt-bindings: display: st7703: Add Powkiddy RGB10MAX3 panel > drm/panel: st7703: Add Powkiddy RGB10MAX3 Panel Support > dt-bindings: display: Document ST7703 panel rotation > drm/panel: st7703: Add Panel Rotation Support > arm64: dts: rockchip: Update powkiddy rk2023 dtsi for RGB10MAX3 > dt-bindings: arm: rockchip: Add Powkiddy RGB10MAX3 > arm64: dts: rockchip: Add Powkiddy RGB10MAX3 > > [...] Applied, thanks! [1/7] dt-bindings: display: st7703: Add Powkiddy RGB10MAX3 panel commit: 9913a60f318b6c88ea8385048952e3557464bb84 [2/7] drm/panel: st7703: Add Powkiddy RGB10MAX3 Panel Support commit: e0c732291250e205fb834881ad7ecf9ee3ffef45 [3/7] dt-bindings: display: Document ST7703 panel rotation commit: 20b18c2be4f3dcb5448ecc122484bef6c2852fdd [4/7] drm/panel: st7703: Add Panel Rotation Support commit: 762195e5c26936b891fb54ba0183aa3ef366b41e I've adapted the binding subjects to poin to the rocktech,jh057n00900 panel that gets changed and also dropped the one added newline as requested by Guido. Best regards, -- Heiko Stuebner
Re: [PATCH v2 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
On 2/13/2024 10:23 AM, Dmitry Baryshkov wrote:
On Tue, 13 Feb 2024 at 19:32, Abhinav Kumar wrote:
On 2/13/2024 3:18 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:53, Paloma Arellano wrote:
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v2:
- Move timing engine programming to a separate patch from this
one
- Move update_pending_flush_periph() invocation completely to
this patch
- Change the logic of dpu_encoder_get_drm_fmt() so that it only
calls drm_mode_is_420_only() instead of doing additional
unnecessary checks
- Create new functions msm_dp_needs_periph_flush() and it's
supporting function dpu_encoder_needs_periph_flush() to check
if the mode is YUV420 and VSC SDP is enabled before doing a
peripheral flush
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35 +++
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 ++
drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
drivers/gpu/drm/msm/msm_drv.h | 17 -
5 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 7e7796561009a..6280c6be6dca9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -222,6 +222,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct drm_display_info *info;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ info = _enc->connector->display_info;
+ mode = _enc->cached_mode;
+
+ if (drm_mode_is_420_only(info, mode))
+ return DRM_FORMAT_YUV420;
+
+ return DRM_FORMAT_RGB888;
+}
+
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct msm_display_info *disp_info;
+ struct msm_drm_private *priv;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ disp_info = _enc->disp_info;
+ priv = drm_enc->dev->dev_private;
+ mode = _enc->cached_mode;
+
+ return phys_enc->hw_intf->cap->type == INTF_DP && phys_enc->hw_cdm &&
Do we really need to check for phys_enc->hw_cdm here?
hmmm I dont think so. If CDM was not there, then after the last patch,
YUV420 removes will not be present at all.
The only other case I could think of was, if for some reason CDM was
used by some other interface such as WB, then hw_cdm will not be assigned.
But, I think even for that msm_dp_needs_periph_flush() will take care of
it because we use the cached_mode which is assigned only in mode_set().
+
msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]], mode);
+}
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index f43d57d9c74e1..211a3d90eb690 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -341,6 +341,19 @@ static inline enum dpu_3d_blend_mode
dpu_encoder_helper_get_3d_blend_mode(
*/
unsigned int dpu_encoder_helper_get_dsc(struct dpu_encoder_phys *phys_enc);
+/**
+ * dpu_encoder_get_drm_fmt - return DRM fourcc format
+ * @phys_enc: Pointer to physical encoder structure
+ */
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc);
+
+/**
+ * dpu_encoder_needs_periph_flush - return true if physical encoder requires
+ * peripheral flush
+ * @phys_enc: Pointer to physical encoder structure
+ */
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc);
+
/**
* dpu_encoder_helper_split_config - split display configuration helper
function
* This helper function may be used by physical encoders to configure
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index f562beb6f7971..3f102b2813ca8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -413,8 +413,15 @@ static int dpu_encoder_phys_vid_control_vblank_irq(
static void dpu_encoder_phys_vid_enable(struct dpu_encoder_phys *phys_enc)
{
struct dpu_hw_ctl *ctl;
+ struct dpu_hw_cdm
Re: [PATCH 2/2] [v3] drm/nouveau: expose GSP-RM logging buffers via debugfs
On 2/13/24 18:10, Timur Tabi wrote: On Tue, 2024-02-13 at 17:57 +0100, Danilo Krummrich wrote: + struct debugfs_blob_wrapper blob_init; + struct debugfs_blob_wrapper blob_intr; + struct debugfs_blob_wrapper blob_rm; + struct debugfs_blob_wrapper blob_pmu; + struct dentry *debugfs_logging_dir; I think we should not create those from within the nvkm layer, but rather pass them down through nvkm_device_pci_new(). Should they be created in nvkm_device_pci_new() also, even though we have no idea whether GSP is involved at that point? We can pass some structure to nvkm_device_pci_new() where GSP sets the pointers to the buffers and maybe a callback to clean them up. Once nvkm_device_pci_new() returns we'd see if something has been set or not. If so, we can go ahead and create the debugfs nodes. Lifecycle wise I think we should ensure that removing the Nouveau kernel module also cleans up those buffers. Even though keep-gsp-logging is considered unsafe, we shouldn't leak memory. I agree, but then there needs to be some way to keep these debugfs entries until the driver unloads. I don't know how to do that without creating some ugly global variables. I fear that might be the only option. However, I still prefer a global list over a memory leak. For instance, can we allocate corresponding buffers in the driver layer, copy things over and keep those buffers until nouveau_drm_exit()? This would also avoid exposing those DMA buffers via debugfs. The whole point behind this patch is to expose the buffers via debugfs. How else should they be exposed? I think I only thought about the fail case where we could just copy over the data from the DMA buffer to another buffer and expose that one instead. However, that doesn't work if GSP loads successfully. Hence, as mentioned above, we might just want to have some structure that we can add to the global list that contains the pointers to the DMA buffers and maybe a callback function to clean them up defined by the GSP code that we can simply call from nouveau_drm_exit().
Re: [PATCH v2 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
On Tue, 13 Feb 2024 at 19:32, Abhinav Kumar wrote:
>
>
>
> On 2/13/2024 3:18 AM, Dmitry Baryshkov wrote:
> > On Sat, 10 Feb 2024 at 03:53, Paloma Arellano
> > wrote:
> >>
> >> Adjust the encoder format programming in the case of video mode for DP
> >> to accommodate CDM related changes.
> >>
> >> Changes in v2:
> >> - Move timing engine programming to a separate patch from this
> >>one
> >> - Move update_pending_flush_periph() invocation completely to
> >>this patch
> >> - Change the logic of dpu_encoder_get_drm_fmt() so that it only
> >>calls drm_mode_is_420_only() instead of doing additional
> >>unnecessary checks
> >> - Create new functions msm_dp_needs_periph_flush() and it's
> >>supporting function dpu_encoder_needs_periph_flush() to check
> >>if the mode is YUV420 and VSC SDP is enabled before doing a
> >>peripheral flush
> >>
> >> Signed-off-by: Paloma Arellano
> >> ---
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35 +++
> >> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
> >> .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 ++
> >> drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
> >> drivers/gpu/drm/msm/msm_drv.h | 17 -
> >> 5 files changed, 101 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> index 7e7796561009a..6280c6be6dca9 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> @@ -222,6 +222,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
> >> 15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
> >> };
> >>
> >> +u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
> >> +{
> >> + struct drm_encoder *drm_enc;
> >> + struct dpu_encoder_virt *dpu_enc;
> >> + struct drm_display_info *info;
> >> + struct drm_display_mode *mode;
> >> +
> >> + drm_enc = phys_enc->parent;
> >> + dpu_enc = to_dpu_encoder_virt(drm_enc);
> >> + info = _enc->connector->display_info;
> >> + mode = _enc->cached_mode;
> >> +
> >> + if (drm_mode_is_420_only(info, mode))
> >> + return DRM_FORMAT_YUV420;
> >> +
> >> + return DRM_FORMAT_RGB888;
> >> +}
> >> +
> >> +bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc)
> >> +{
> >> + struct drm_encoder *drm_enc;
> >> + struct dpu_encoder_virt *dpu_enc;
> >> + struct msm_display_info *disp_info;
> >> + struct msm_drm_private *priv;
> >> + struct drm_display_mode *mode;
> >> +
> >> + drm_enc = phys_enc->parent;
> >> + dpu_enc = to_dpu_encoder_virt(drm_enc);
> >> + disp_info = _enc->disp_info;
> >> + priv = drm_enc->dev->dev_private;
> >> + mode = _enc->cached_mode;
> >> +
> >> + return phys_enc->hw_intf->cap->type == INTF_DP && phys_enc->hw_cdm
> >> &&
> >
> > Do we really need to check for phys_enc->hw_cdm here?
> >
>
> hmmm I dont think so. If CDM was not there, then after the last patch,
> YUV420 removes will not be present at all.
>
> The only other case I could think of was, if for some reason CDM was
> used by some other interface such as WB, then hw_cdm will not be assigned.
>
> But, I think even for that msm_dp_needs_periph_flush() will take care of
> it because we use the cached_mode which is assigned only in mode_set().
>
> >> +
> >> msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]], mode);
> >> +}
> >>
> >> bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
> >> {
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> >> index f43d57d9c74e1..211a3d90eb690 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> >> @@ -341,6 +341,19 @@ static inline enum dpu_3d_blend_mode
> >> dpu_encoder_helper_get_3d_blend_mode(
> >>*/
> >> unsigned int dpu_encoder_helper_get_dsc(struct dpu_encoder_phys
> >> *phys_enc);
> >>
> >> +/**
> >> + * dpu_encoder_get_drm_fmt - return DRM fourcc format
> >> + * @phys_enc: Pointer to physical encoder structure
> >> + */
> >> +u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc);
> >> +
> >> +/**
> >> + * dpu_encoder_needs_periph_flush - return true if physical encoder
> >> requires
> >> + * peripheral flush
> >> + * @phys_enc: Pointer to physical encoder structure
> >> + */
> >> +bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc);
> >> +
> >> /**
> >>* dpu_encoder_helper_split_config - split display configuration helper
> >> function
> >>* This helper function may be used by physical encoders to configure
> >> diff --git
[PATCH] backlight: ktd2801: depend on GPIOLIB
LEDS_EXPRESSWIRE depends on GPIOLIB, and so must anything selecting it:
WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=y] && GPIOLIB [=n]
Selected by [m]:
- BACKLIGHT_KTD2801 [=m] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=m]
Fixes: 66c76c1cd984 ("backlight: Add Kinetic KTD2801 backlight support")
Signed-off-by: Duje Mihanović
---
drivers/video/backlight/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 230bca07b09d..8bd88017d945 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -185,6 +185,7 @@ config BACKLIGHT_KTD253
config BACKLIGHT_KTD2801
tristate "Backlight Driver for Kinetic KTD2801"
+ depends on GPIOLIB
select LEDS_EXPRESSWIRE
help
Say Y to enable the backlight driver for the Kinetic KTD2801 1-wire
---
base-commit: 46d4e2eb58e14c8935fa0e27d16d4c62ef82849a
change-id: 20240213-ktd2801-deps-0f571c09b824
Best regards,
--
Duje Mihanović
[PATCH] drm/nouveau/mmu/r535: uninitialized variable in r535_bar_new_()
If gf100_bar_new_() fails then "bar" is not initialized.
Fixes: 5bf0257136a2 ("drm/nouveau/mmu/r535: initial support")
Signed-off-by: Dan Carpenter
---
It looks like this was intended to handle a failure from the "rm" func
but "rm" can't actually fail so it's easier to write the error handling
for the code as-is.
drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c
index 4135690326f4..3a30bea30e36 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c
@@ -168,12 +168,11 @@ r535_bar_new_(const struct nvkm_bar_func *hw, struct
nvkm_device *device,
rm->flush = r535_bar_flush;
ret = gf100_bar_new_(rm, device, type, inst, );
- *pbar = bar;
if (ret) {
- if (!bar)
- kfree(rm);
+ kfree(rm);
return ret;
}
+ *pbar = bar;
bar->flushBAR2PhysMode = ioremap(device->func->resource_addr(device,
3), PAGE_SIZE);
if (!bar->flushBAR2PhysMode)
--
2.43.0
Re: [PATCH i-g-t v3] benchmarks: Add VKMS benchmark
Hi Arthur,
On 2024-02-09 at 16:39:09 -0300, Arthur Grillo wrote:
I will merge this with different description:
[PATCH i-g-t v3] benchmarks: Add KMS frambuffer stress benchmark
Is this ok?
Regards,
Kamil
> Create a benchmark for the VKMS driver. Use a KMS layout with deliberate
> odd sizes to try to avoid alignment accidents and run it for FRAME_COUNT
> frames flipping framebuffers in each plane.
>
> This benchmark was suggested by Pekka Paalanen to better analyse
> possible performance regression on the Virtual Kernel Modesetting(VKMS)
> driver.
>
> With this benchmark I was able to determine two performance regression:
>
> - 322d716a3e8a ("drm/vkms: isolate pixel conversion functionality")
> - cc4fd2934d41 ("drm/vkms: Isolate writeback pixel conversion functions")
>
> Link: https://lore.kernel.org/all/20240202214527.1d97c881@ferris.localdomain/
> Suggested-by: Pekka Paalanen
> Acked-by: Pekka Paalanen
> Acked-by: Maíra Canal
> Acked-by: Kamil Konieczny
> Signed-off-by: Arthur Grillo
> ---
> Changes in v3:
> - Change primary plane width to not extend outside the CRTC size
> - Explicitly set a big CRTC size (Peeka Paalanen)
> - Report time spent in the loop (Peeka Paalanen)
> - Put file name in alphabetical order on meson script (Kamil Konieczny)
> - Link to v2:
> https://lore.kernel.org/r/20240208-bench-v2-1-1eccee105...@riseup.net
>
> Changes in v2:
> - Zero initialize data
> - Don't wrap igt_create_* functions (Juha-Pekka Heikkila)
> - Add a `break;` when a pipe is found (Pekka Paalanen)
> - Rename file to kms_fb_stress.c (Kamil Konieczny)
> - Replace 2 by NUM_FBS (Juha-Pekka Heikkila)
> - Replace license text by SPDX License (Kamil Konieczny)
> - Move explanations to commit description (Kamil Konieczny)
> - Require output after find_wb_output() (Pekka Paalanen & Juha-Pekka
> Heikkila)
> - Remove unnecessary commit (Pekka Paalanen)
> - Link to v1:
> https://lore.kernel.org/r/20240207-bench-v1-1-7135ad426...@riseup.net
> ---
> benchmarks/kms_fb_stress.c | 208
> +
> benchmarks/meson.build | 1 +
> 2 files changed, 209 insertions(+)
>
> diff --git a/benchmarks/kms_fb_stress.c b/benchmarks/kms_fb_stress.c
> new file mode 100644
> index ..9a0e98bed8ad
> --- /dev/null
> +++ b/benchmarks/kms_fb_stress.c
> @@ -0,0 +1,208 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2024 Arthur Grillo
> + */
> +
> +#include "igt.h"
> +
> +#define FRAME_COUNT 100
> +#define NUM_FBS 2
> +
> +struct rect_t {
> + int x, y;
> + int width, height;
> +};
> +
> +struct plane_t {
> + igt_plane_t *base;
> + struct rect_t rect;
> + uint32_t format;
> + struct igt_fb fbs[NUM_FBS];
> +};
> +
> +struct kms_t {
> + struct rect_t crtc;
> + struct plane_t primary;
> + struct plane_t overlay_a;
> + struct plane_t overlay_b;
> + struct plane_t writeback;
> +};
> +
> +struct data_t {
> + int fd;
> + igt_display_t display;
> + igt_output_t *wb_output;
> + drmModeModeInfo *mode;
> + struct kms_t kms;
> +};
> +
> +static void plane_setup(struct plane_t *plane, int index)
> +{
> + igt_plane_set_size(plane->base, plane->rect.width, plane->rect.height);
> + igt_plane_set_position(plane->base, plane->rect.x, plane->rect.y);
> + igt_plane_set_fb(plane->base, >fbs[index]);
> +}
> +
> +static void gen_fbs(struct data_t *data)
> +{
> + struct kms_t *kms = >kms;
> + drmModeModeInfo *mode = igt_output_get_mode(data->wb_output);
> +
> + for (int i = 0; i < NUM_FBS; i++) {
> + igt_create_color_fb(data->fd, kms->primary.rect.width,
> kms->primary.rect.height,
> + kms->primary.format, DRM_FORMAT_MOD_LINEAR,
> + !i, i, i,
> + >primary.fbs[i]);
> +
> + igt_create_color_fb(data->fd, kms->overlay_a.rect.width,
> kms->overlay_a.rect.height,
> + kms->overlay_a.format,
> DRM_FORMAT_MOD_LINEAR,
> + i, !i, i,
> + >overlay_a.fbs[i]);
> +
> + igt_create_color_fb(data->fd, kms->overlay_b.rect.width,
> kms->overlay_b.rect.height,
> + kms->overlay_b.format,
> DRM_FORMAT_MOD_LINEAR,
> + i, i, !i,
> + >overlay_b.fbs[i]);
> +
> + kms->writeback.rect.width = mode->hdisplay;
> + kms->writeback.rect.height = mode->vdisplay;
> + igt_create_fb(data->fd, kms->writeback.rect.width,
> kms->writeback.rect.height,
> + kms->writeback.format, DRM_FORMAT_MOD_LINEAR,
> + >writeback.fbs[i]);
> + }
> +}
> +
> +static igt_output_t *find_wb_output(struct data_t *data)
> +{
> + for (int i = 0; i < data->display.n_outputs; i++) {
> + igt_output_t *output = >display.outputs[i];
> +
> +
[PATCH] drm/imx/dcss: fix resource size calculation
The resource is inclusive of the ->start and ->end addresses so this
calculation is not correct. It should be "res->end - res->start + 1".
Use the resource_size() to do the calculation.
Fixes: 90393c9b5408 ("drm/imx/dcss: request memory region")
Signed-off-by: Dan Carpenter
---
>From static analysis. Not tested.
drivers/gpu/drm/imx/dcss/dcss-dev.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c
b/drivers/gpu/drm/imx/dcss/dcss-dev.c
index 597e9b7bd4bf..7fd0c4c14205 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.c
@@ -167,7 +167,6 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool
hdmi_output)
struct resource *res;
struct dcss_dev *dcss;
const struct dcss_type_data *devtype;
- resource_size_t res_len;
devtype = of_device_get_match_data(dev);
if (!devtype) {
@@ -181,8 +180,7 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool
hdmi_output)
return ERR_PTR(-EINVAL);
}
- res_len = res->end - res->start;
- if (!devm_request_mem_region(dev, res->start, res_len, "dcss")) {
+ if (!devm_request_mem_region(dev, res->start, resource_size(res),
"dcss")) {
dev_err(dev, "cannot request memory region\n");
return ERR_PTR(-EBUSY);
}
--
2.43.0
Re: drm/msm: DisplayPort regressions in 6.8-rc1
Hi Johan Thanks for the report. I do agree that pm runtime eDP driver got merged that time but I think the issue is either a combination of that along with DRM aux bridge https://patchwork.freedesktop.org/series/122584/ OR just the latter as even that went in around the same time. Thats why perhaps this issue was not seen with the chromebooks we tested on as they do not use pmic_glink (aux bridge). So we will need to debug this on sc8280xp specifically or an equivalent device which uses aux bridge. Thanks Abhinav On 2/13/2024 3:42 AM, Johan Hovold wrote: Hi, Since 6.8-rc1 the internal eDP display on the Lenovo ThinkPad X13s does not always show up on boot. The logs indicate problems with the runtime PM and eDP rework that went into 6.8-rc1: [6.006236] Console: switching to colour dummy device 80x25 [6.007542] [drm:dpu_kms_hw_init:1048] dpu hardware revision:0x8000 [6.007872] [drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16 [6.007934] [drm:dp_bridge_init [msm]] *ERROR* failed to attach panel bridge: -16 [6.007983] msm_dpu ae01000.display-controller: [drm:msm_dp_modeset_init [msm]] *ERROR* failed to create dp bridge: -16 [6.008030] [drm:_dpu_kms_initialize_displayport:588] [dpu error]modeset_init failed for DP, rc = -16 [6.008050] [drm:_dpu_kms_setup_displays:681] [dpu error]initialize_DP failed, rc = -16 [6.008068] [drm:dpu_kms_hw_init:1153] [dpu error]modeset init failed: -16 [6.008388] msm_dpu ae01000.display-controller: [drm:msm_drm_kms_init [msm]] *ERROR* kms hw init failed: -16 and this can also manifest itself as a NULL-pointer dereference: [7.339447] Unable to handle kernel NULL pointer dereference at virtual address [7.643705] pc : drm_bridge_attach+0x70/0x1a8 [drm] [7.686415] lr : drm_aux_bridge_attach+0x24/0x38 [aux_bridge] [7.769039] Call trace: [7.771564] drm_bridge_attach+0x70/0x1a8 [drm] [7.776234] drm_aux_bridge_attach+0x24/0x38 [aux_bridge] [7.781782] drm_bridge_attach+0x80/0x1a8 [drm] [7.786454] dp_bridge_init+0xa8/0x15c [msm] [7.790856] msm_dp_modeset_init+0x28/0xc4 [msm] [7.795617] _dpu_kms_drm_obj_init+0x19c/0x680 [msm] [7.800731] dpu_kms_hw_init+0x348/0x4c4 [msm] [7.805306] msm_drm_kms_init+0x84/0x324 [msm] [7.809891] msm_drm_bind+0x1d8/0x3a8 [msm] [7.814196] try_to_bring_up_aggregate_device+0x1f0/0x2f8 [7.819747] __component_add+0xa4/0x18c [7.823703] component_add+0x14/0x20 [7.827389] dp_display_probe+0x47c/0x568 [msm] [7.832052] platform_probe+0x68/0xd8 Users have also reported random crashes at boot since 6.8-rc1, and I've been able to trigger hard crashes twice when testing an external display (USB-C/DP), which may also be related to the DP regressions. I've opened an issue here: https://gitlab.freedesktop.org/drm/msm/-/issues/51 but I also want Thorsten's help to track this so that it gets fixed before 6.8 is released. #regzbot introduced: v6.7..v6.8-rc1 The following series is likely the culprit: https://lore.kernel.org/all/1701472789-25951-1-git-send-email-quic_khs...@quicinc.com/ Johan
Re: [PATCH] gpu: host1x: bus: make host1x_bus_type const
On Tue, Feb 13, 2024 at 11:44:40AM -0300, Ricardo B. Marliere wrote:
> Since commit d492cc2573a0 ("driver core: device.h: make struct
> bus_type a const *"), the driver core can properly handle constant
> struct bus_type, move the host1x_bus_type variable to be a constant
> structure as well, placing it into read-only memory which can not be
> modified at runtime.
>
> Cc: Greg Kroah-Hartman
> Suggested-by: Greg Kroah-Hartman
> Signed-off-by: Ricardo B. Marliere
Reviewed-by: Greg Kroah-Hartman
Re: [PATCH] nouveau: offload fence uevents work to workqueue
On 2/9/24 19:52, Daniel Vetter wrote: On Fri, Feb 09, 2024 at 06:41:32PM +0100, Danilo Krummrich wrote: On 2/6/24 15:03, Daniel Vetter wrote: On Mon, Feb 05, 2024 at 11:00:04PM +0100, Danilo Krummrich wrote: On 2/5/24 22:08, Dave Airlie wrote: On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich wrote: On 1/29/24 02:50, Dave Airlie wrote: From: Dave Airlie This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. Signed-off-by: Dave Airlie Nouveau's scheduler uses a dedicated wq, hence from this perspective it's safe deferring fence signalling to the kernel global wq. However, I wonder if we could create deadlocks by building dependency chains into other drivers / kernel code that, by chance, makes use of the kernel global wq as well. Admittedly, even if, it's gonna be extremely unlikely given that WQ_MAX_ACTIVE == 512. But maybe it'd be safer to use a dedicated wq. Also, do we need to CC stable? I pushed this to Linus at the end of last week, since the hangs in 6.7 take out the complete system and I wanted it in stable. It might be safer to use a dedicated wq, is the concern someone is waiting on a fence in a workqueue somewhere else so we will never signal it? Yes, if some other work is waiting for this fence (or something else in the same dependency chain) to signal it can prevent executing the work signaling this fence, in case both are scheduled on the same wq. As mentioned, with the kernel global wq this would be rather unlikely to lead to an actual stall with WQ_MAX_ACTIVE == 512, but formally the race condition exists. I guess a malicious attacker could try to intentionally push jobs directly or indirectly depending on this fence to a driver which queues them up on a scheduler using the kernel global wq. I think if you add dma_fence_signalling annotations (aside, there's some patch from iirc Thomas Hellstrom to improve them and cut down on some false positives, but I lost track) then I think you won't get any splats because the wq subsystem assumes that WC_MAX_ACTIVE is close enough to infinity to not matter. As mentioned, for the kernel global wq it's 512. (Intentionally) feeding the kernel with enough jobs to to provoke a deadlock doesn't seem impossible to me. I think it'd be safer to just establish not to use the kernel global wq for executing work in the fence signalling critical path. We could also run into similar problems with a dedicated wq, e.g. when drivers share a wq between drm_gpu_scheduler instances (see [1]), however, I'm not sure we can catch that with lockdep. I think if you want to fix it perfectly you'd need to set the max number of wq to the number of engines (or for dynamic/fw scheduled engines to the number of context) you have. Or whatever limit to the number of parallel timelines there is.> I guess this would need a new wq function to update? drm/sched code could be able to set that for drivers, so drivers cannot get this wrong. Not sure I can follow. The scheduler instance might be per context and bind queue. In this case it gets the shared wq passed, but doesn't know how many other scheduler instances share the same one. Additionally, there might be drivers not using the DRM scheduler for for bind queues at all (I think Xe does not). If we don't do something like that then I'm not sure there's really much benefit - instead of carefully timing 512 dma_fence on the global wq you just need to create a pile of context (at least on intel's guc that's absolutely no issue) and then careful time them. Well, that's true. I'd still argue that there is a slight difference. From a drivers isolated perspective using the global kernel wq might be entirely fine, as in this patch. However, in combination with another driver doing the same thing, things can blow up. For the case you illustrated it's at least possible to spot it from a driver's perspective. I still feel like we have bigger fish to fry ... But might be worth the effort to at least make the parallel timeline limit a lot more explicit? I agree, and it'd be great if we can find a solution such bugs can be detected systematically (e.g. through lockdep), but maybe we can start to at least document that we should never use the kernel global wq and where we need to be careful in sharing driver wqs. - Danilo Cheers, Sima [1] https://elixir.bootlin.com/linux/v6.8-rc3/source/drivers/gpu/drm/nouveau/nouveau_drm.c#L313 I'm not sure we should care differently, but I guess it'd be good to annotate it all in case the wq subsystem's idea of how much such deadlocks are real changes. Also Teo is on a mission to get rid of all the global wq flushes, so there should also be no source of deadlocks from that kind of cross-driver dependency. Or at least shouldn't be in the future, I'm not sure it all landed. -Sima
Re: [PATCH 1/2] drm/scheduler: improve GPU scheduler documentation v2
Hi Christian, What's the status of this effort? Was there ever a follow-up? - Danilo On 11/16/23 23:23, Danilo Krummrich wrote: Hi Christian, Thanks for sending an update of this patch! On Thu, Nov 16, 2023 at 03:15:46PM +0100, Christian König wrote: Start to improve the scheduler document. Especially document the lifetime of each of the objects as well as the restrictions around DMA-fence handling and userspace compatibility. v2: Some improvements suggested by Danilo, add section about error handling. Signed-off-by: Christian König --- Documentation/gpu/drm-mm.rst | 36 + drivers/gpu/drm/scheduler/sched_main.c | 174 + 2 files changed, 188 insertions(+), 22 deletions(-) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index acc5901ac840..112463fa9f3a 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -552,12 +552,48 @@ Overview .. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c :doc: Overview +Job Object +-- + +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c + :doc: Job Object + +Entity Object +- + +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c + :doc: Entity Object + +Hardware Fence Object +- + +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c + :doc: Hardware Fence Object + +Scheduler Fence Object +-- + +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c + :doc: Scheduler Fence Object + +Scheduler and Run Queue Objects +--- + +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c + :doc: Scheduler and Run Queue Objects + Flow Control .. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c :doc: Flow Control +Error and Timeout handling +-- + +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c + :doc: Error and Timeout handling + Scheduler Function References - diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index 044a8c4875ba..026123497b0e 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -24,28 +24,122 @@ /** * DOC: Overview * - * The GPU scheduler provides entities which allow userspace to push jobs - * into software queues which are then scheduled on a hardware run queue. - * The software queues have a priority among them. The scheduler selects the entities - * from the run queue using a FIFO. The scheduler provides dependency handling - * features among jobs. The driver is supposed to provide callback functions for - * backend operations to the scheduler like submitting a job to hardware run queue, - * returning the dependencies of a job etc. - * - * The organisation of the scheduler is the following: - * - * 1. Each hw run queue has one scheduler - * 2. Each scheduler has multiple run queues with different priorities - *(e.g., HIGH_HW,HIGH_SW, KERNEL, NORMAL) - * 3. Each scheduler run queue has a queue of entities to schedule - * 4. Entities themselves maintain a queue of jobs that will be scheduled on - *the hardware. - * - * The jobs in a entity are always scheduled in the order that they were pushed. - * - * Note that once a job was taken from the entities queue and pushed to the - * hardware, i.e. the pending queue, the entity must not be referenced anymore - * through the jobs entity pointer. + * The GPU scheduler implements some logic to decide which command submission + * to push next to the hardware. Another major use case of the GPU scheduler + * is to enforce correct driver behavior around those command submissions. + * Because of this it's also used by drivers which don't need the actual + * scheduling functionality. This reads a bit like we're already right in the middle of the documentation. I'd propose to start with something like "The DRM GPU scheduler serves as a common component intended to help drivers to manage command submissions." And then mention the different solutions the scheduler provides, e.g. ordering of command submissions, dma-fence handling in the context of command submissions, etc. Also, I think it would be good to give a rough overview of the topology of the scheduler's components. And since you already mention that the component is "also used by drivers which don't need the actual scheduling functionality", I'd also mention the special case of a single entity and a single run-queue per scheduler. + * + * All callbacks the driver needs to implement are restricted by DMA-fence + * signaling rules to guarantee deadlock free forward progress. This especially + * means that for normal operation no memory can be allocated in a callback. + * All memory which is needed for pushing the job to the hardware must be + * allocated before arming a job. It also means that no locks can be taken + * under which memory
Re: [PATCH v2 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
On 2/13/2024 3:18 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:53, Paloma Arellano wrote:
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v2:
- Move timing engine programming to a separate patch from this
one
- Move update_pending_flush_periph() invocation completely to
this patch
- Change the logic of dpu_encoder_get_drm_fmt() so that it only
calls drm_mode_is_420_only() instead of doing additional
unnecessary checks
- Create new functions msm_dp_needs_periph_flush() and it's
supporting function dpu_encoder_needs_periph_flush() to check
if the mode is YUV420 and VSC SDP is enabled before doing a
peripheral flush
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35 +++
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 ++
drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
drivers/gpu/drm/msm/msm_drv.h | 17 -
5 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 7e7796561009a..6280c6be6dca9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -222,6 +222,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct drm_display_info *info;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ info = _enc->connector->display_info;
+ mode = _enc->cached_mode;
+
+ if (drm_mode_is_420_only(info, mode))
+ return DRM_FORMAT_YUV420;
+
+ return DRM_FORMAT_RGB888;
+}
+
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct msm_display_info *disp_info;
+ struct msm_drm_private *priv;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ disp_info = _enc->disp_info;
+ priv = drm_enc->dev->dev_private;
+ mode = _enc->cached_mode;
+
+ return phys_enc->hw_intf->cap->type == INTF_DP && phys_enc->hw_cdm &&
Do we really need to check for phys_enc->hw_cdm here?
hmmm I dont think so. If CDM was not there, then after the last patch,
YUV420 removes will not be present at all.
The only other case I could think of was, if for some reason CDM was
used by some other interface such as WB, then hw_cdm will not be assigned.
But, I think even for that msm_dp_needs_periph_flush() will take care of
it because we use the cached_mode which is assigned only in mode_set().
+
msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]], mode);
+}
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index f43d57d9c74e1..211a3d90eb690 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -341,6 +341,19 @@ static inline enum dpu_3d_blend_mode
dpu_encoder_helper_get_3d_blend_mode(
*/
unsigned int dpu_encoder_helper_get_dsc(struct dpu_encoder_phys *phys_enc);
+/**
+ * dpu_encoder_get_drm_fmt - return DRM fourcc format
+ * @phys_enc: Pointer to physical encoder structure
+ */
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc);
+
+/**
+ * dpu_encoder_needs_periph_flush - return true if physical encoder requires
+ * peripheral flush
+ * @phys_enc: Pointer to physical encoder structure
+ */
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc);
+
/**
* dpu_encoder_helper_split_config - split display configuration helper
function
* This helper function may be used by physical encoders to configure
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index f562beb6f7971..3f102b2813ca8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -413,8 +413,15 @@ static int dpu_encoder_phys_vid_control_vblank_irq(
static void dpu_encoder_phys_vid_enable(struct dpu_encoder_phys *phys_enc)
{
struct dpu_hw_ctl *ctl;
+ struct dpu_hw_cdm *hw_cdm;
+ const struct dpu_format *fmt = NULL;
+ u32 fmt_fourcc = DRM_FORMAT_RGB888;
ctl =
[PATCH] drm/msm: Wire up tlb ops
From: Rob Clark
The brute force iommu_flush_iotlb_all() was good enough for unmap, but
in some cases a map operation could require removing a table pte entry
to replace with a block entry. This also requires tlb invalidation.
Missing this was resulting an obscure iova fault on what should be a
valid buffer address.
Thanks to Robin Murphy for helping me understand the cause of the fault.
Cc: Robin Murphy
Fixes: b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_iommu.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 5cc8d358cc97..d5512037c38b 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -21,6 +21,8 @@ struct msm_iommu_pagetable {
struct msm_mmu base;
struct msm_mmu *parent;
struct io_pgtable_ops *pgtbl_ops;
+ const struct iommu_flush_ops *tlb;
+ struct device *iommu_dev;
unsigned long pgsize_bitmap;/* Bitmap of page sizes in use */
phys_addr_t ttbr;
u32 asid;
@@ -201,11 +203,33 @@ static const struct msm_mmu_funcs pagetable_funcs = {
static void msm_iommu_tlb_flush_all(void *cookie)
{
+ struct msm_iommu_pagetable *pagetable = cookie;
+ struct adreno_smmu_priv *adreno_smmu;
+
+ if (!pm_runtime_get_if_in_use(pagetable->iommu_dev))
+ return;
+
+ adreno_smmu = dev_get_drvdata(pagetable->parent->dev);
+
+ pagetable->tlb->tlb_flush_all((void *)adreno_smmu->cookie);
+
+ pm_runtime_put_autosuspend(pagetable->iommu_dev);
}
static void msm_iommu_tlb_flush_walk(unsigned long iova, size_t size,
size_t granule, void *cookie)
{
+ struct msm_iommu_pagetable *pagetable = cookie;
+ struct adreno_smmu_priv *adreno_smmu;
+
+ if (!pm_runtime_get_if_in_use(pagetable->iommu_dev))
+ return;
+
+ adreno_smmu = dev_get_drvdata(pagetable->parent->dev);
+
+ pagetable->tlb->tlb_flush_walk(iova, size, granule, (void
*)adreno_smmu->cookie);
+
+ pm_runtime_put_autosuspend(pagetable->iommu_dev);
}
static void msm_iommu_tlb_add_page(struct iommu_iotlb_gather *gather,
@@ -213,7 +237,7 @@ static void msm_iommu_tlb_add_page(struct
iommu_iotlb_gather *gather,
{
}
-static const struct iommu_flush_ops null_tlb_ops = {
+static const struct iommu_flush_ops tlb_ops = {
.tlb_flush_all = msm_iommu_tlb_flush_all,
.tlb_flush_walk = msm_iommu_tlb_flush_walk,
.tlb_add_page = msm_iommu_tlb_add_page,
@@ -254,10 +278,10 @@ struct msm_mmu *msm_iommu_pagetable_create(struct msm_mmu
*parent)
/* The incoming cfg will have the TTBR1 quirk enabled */
ttbr0_cfg.quirks &= ~IO_PGTABLE_QUIRK_ARM_TTBR1;
- ttbr0_cfg.tlb = _tlb_ops;
+ ttbr0_cfg.tlb = _ops;
pagetable->pgtbl_ops = alloc_io_pgtable_ops(ARM_64_LPAE_S1,
- _cfg, iommu->domain);
+ _cfg, pagetable);
if (!pagetable->pgtbl_ops) {
kfree(pagetable);
@@ -279,6 +303,8 @@ struct msm_mmu *msm_iommu_pagetable_create(struct msm_mmu
*parent)
/* Needed later for TLB flush */
pagetable->parent = parent;
+ pagetable->tlb = ttbr1_cfg->tlb;
+ pagetable->iommu_dev = ttbr1_cfg->iommu_dev;
pagetable->pgsize_bitmap = ttbr0_cfg.pgsize_bitmap;
pagetable->ttbr = ttbr0_cfg.arm_lpae_s1_cfg.ttbr;
--
2.43.0
Re: [PATCH 2/2] [v3] drm/nouveau: expose GSP-RM logging buffers via debugfs
On Tue, 2024-02-13 at 17:57 +0100, Danilo Krummrich wrote: + struct debugfs_blob_wrapper blob_init; + struct debugfs_blob_wrapper blob_intr; + struct debugfs_blob_wrapper blob_rm; + struct debugfs_blob_wrapper blob_pmu; + struct dentry *debugfs_logging_dir; I think we should not create those from within the nvkm layer, but rather pass them down through nvkm_device_pci_new(). Should they be created in nvkm_device_pci_new() also, even though we have no idea whether GSP is involved at that point? Lifecycle wise I think we should ensure that removing the Nouveau kernel module also cleans up those buffers. Even though keep-gsp-logging is considered unsafe, we shouldn't leak memory. I agree, but then there needs to be some way to keep these debugfs entries until the driver unloads. I don't know how to do that without creating some ugly global variables. For instance, can we allocate corresponding buffers in the driver layer, copy things over and keep those buffers until nouveau_drm_exit()? This would also avoid exposing those DMA buffers via debugfs. The whole point behind this patch is to expose the buffers via debugfs. How else should they be exposed?
Re: [PATCH] backlight: ktd2801: fix LED dependency
On Mon, Feb 12, 2024 at 03:31:50PM +0100, Duje Mihanović wrote:
> On Monday, February 12, 2024 1:44:28 PM CET Daniel Thompson wrote:
> > On Mon, Feb 12, 2024 at 12:18:12PM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > The new backlight driver unconditionally selects LEDS_EXPRESSWIRE, which
> > > is in a different subsystem that may be disabled here:
> > >
> > > WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
> > >
> > > Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=y]
> > > Selected by [y]:
> > > - BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE
> [=y]
> > >
> > > Change the select to depends, to ensure the indirect dependency is
> > > met as well even when LED support is disabled.
> > >
> > > Fixes: 66c76c1cd984 ("backlight: Add Kinetic KTD2801 backlight support")
> > > Signed-off-by: Arnd Bergmann
> > > ---
> > >
> > > drivers/video/backlight/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/video/backlight/Kconfig
> > > b/drivers/video/backlight/Kconfig index 230bca07b09d..f83f9ef037fc 100644
> > > --- a/drivers/video/backlight/Kconfig
> > > +++ b/drivers/video/backlight/Kconfig
> > > @@ -185,7 +185,7 @@ config BACKLIGHT_KTD253
> > >
> > > config BACKLIGHT_KTD2801
> > >
> > > tristate "Backlight Driver for Kinetic KTD2801"
> > >
> > > - select LEDS_EXPRESSWIRE
> > > + depends on LEDS_EXPRESSWIRE
> >
> > As far as I can tell this resolves the warning by making it impossible
> > to enable BACKLIGHT_KTD2801 unless a largely unrelated driver
> > (LEDS_KTD2692) is also enabled!
> >
> > A better way to resolve this problem might be to eliminate the NEW_LEDS
> > dependency entirely:
>
> I believe this would be the best thing to do here. Making LEDS_EXPRESSWIRE
> user selectable doesn't make much sense to me as the library is rather low-
> level (a quick grep turns up BTREE as an example of something similar) and IMO
> the GPIOLIB dependency should be handled by LEDS_EXPRESSWIRE as it's the one
> actually using the GPIO interface (except maybe for KTD2692 as it has some
> extra GPIOs not present in the other one and thus handles them itself).
We can keep the GPIOLIB dependency in LEDS_EXPRESSWIRE but it also needs
to be included in the KTD2801 KConfig too... otherwise we'll get similar
problems to the ones Arnd addressed here:
https://lore.kernel.org/all/20240213165602.2230970-1-a...@kernel.org/
Daniel.
Re: [PATCH 2/2] [v3] drm/nouveau: expose GSP-RM logging buffers via debugfs
On 2/12/24 22:15, Timur Tabi wrote:
The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers
that have printf-like logs from GSP-RM and PMU encoded in them.
LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA
addresses are passed to GSP-RM during initialization. The buffers are
required for GSP-RM to initialize properly.
LOGPMU is also allocated by Nouveau, but its contents are updated
when Nouveau receives an NV_VGPU_MSG_EVENT_UCODE_LIBOS_PRINT RPC from
GSP-RM. Nouveau then copies the RPC to the buffer.
The messages are encoded as an array of variable-length structures that
contain the parameters to an NV_PRINTF call. The format string and
parameter count are stored in a special ELF image that contains only
logging strings. This image is not currently shipped with the Nvidia
driver.
There are two methods to extract the logs.
OpenRM tries to load the logging ELF, and if present, parses the log
buffers in real time and outputs the strings to the kernel console.
Alternatively, and this is the method used by this patch, the buffers
can be exposed to user space, and a user-space tool (along with the
logging ELF image) can parse the buffer and dump the logs.
This method has the advantage that it allows the buffers to be parsed
even when the logging ELF file is not available to the user. However,
it has the disadvantage the debubfs entries need to remain until the
driver is unloaded.
The buffers are exposed via debugfs. The debugfs entries must be
created before GSP-RM is started, to ensure that they are available
during GSP-RM initialization.
If GSP-RM fails to initialize, then Nouveau immediately shuts down
the GSP interface. This would normally also deallocate the logging
buffers, thereby preventing the user from capturing the debug logs.
To avoid this, the keep-gsp-logging command line parameter can be
specified. This parmater is marked as *unsafe* (thereby taining the
kernel) because the DMA buffer and debugfs entries are never
deallocated, even if the driver unloads. This gives the user the
time to capture the logs, but it also means that resources can only
be recovered by a reboot.
An end-user can capture the logs using the following commands:
cp /sys/kernel/debug/dri//loginit loginit
cp /sys/kernel/debug/dri//logrm logrm
cp /sys/kernel/debug/dri//logintr logintr
cp /sys/kernel/debug/dri//logpmu logpmu
where is the PCI ID of the GPU (e.g. :65:00.0). If
keep-gsp-logging is specified, then the is the same but with
-debug appended (e.g. :65:00.0-debug).
Since LOGPMU is not needed for normal GSP-RM operation, it is only
created if debugfs is available. Otherwise, the
NV_VGPU_MSG_EVENT_UCODE_LIBOS_PRINT RPCs are ignored.
Signed-off-by: Timur Tabi
---
v3: reworked r535_gsp_libos_debugfs_init, rebased for drm-next
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 12 +
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 215 +-
2 files changed, 223 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
index 3fbc57b16a05..2ee44bdf8be7 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
@@ -5,6 +5,8 @@
#include
#include
+#include
+
#define GSP_PAGE_SHIFT 12
#define GSP_PAGE_SIZE BIT(GSP_PAGE_SHIFT)
@@ -217,6 +219,16 @@ struct nvkm_gsp {
/* The size of the registry RPC */
size_t registry_rpc_size;
+
+ /*
+* Logging buffers in debugfs. The wrapper objects need to remain
+* in memory until the dentry is deleted.
+*/
+ struct debugfs_blob_wrapper blob_init;
+ struct debugfs_blob_wrapper blob_intr;
+ struct debugfs_blob_wrapper blob_rm;
+ struct debugfs_blob_wrapper blob_pmu;
+ struct dentry *debugfs_logging_dir;
I think we should not create those from within the nvkm layer, but rather pass
them down through nvkm_device_pci_new().
Lifecycle wise I think we should ensure that removing the Nouveau kernel module
also cleans up those buffers. Even though keep-gsp-logging is considered unsafe,
we shouldn't leak memory.
For instance, can we allocate corresponding buffers in the driver layer, copy
things over and keep those buffers until nouveau_drm_exit()? This would also
avoid exposing those DMA buffers via debugfs.
};
static inline bool
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 86b62c7e1229..56209bf81360 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
@@ -1979,6 +1980,196 @@ r535_gsp_rmargs_init(struct nvkm_gsp *gsp, bool resume)
return 0;
}
+#define NV_GSP_MSG_EVENT_UCODE_LIBOS_CLASS_PMU 0xf3d722
+
+/**
+ *
Re: [PATCH v2 6/6] drm: add drm_mode_atomic_commit event
On Tue, 13 Feb 2024 16:50:31 +0100
Pierre-Eric Pelloux-Prayer wrote:
> @@ -1503,6 +1504,24 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> drm_mode_object_put(obj);
> }
>
> + if (trace_drm_mode_atomic_commit_enabled()) {
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int *crtcs;
> + int i, num_crtcs;
> +
> + crtcs = kcalloc(dev->mode_config.num_crtc, sizeof(int),
> + GFP_KERNEL);
If the above allocation fails, this will cause a NULL kernel dereference.
-- Steve
> +
> + num_crtcs = 0;
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> + crtcs[num_crtcs++] = drm_crtc_index(crtc);
> +
> + trace_drm_mode_atomic_commit(file_priv, crtcs, num_crtcs,
> arg->flags);
> +
> + kfree(crtcs);
> + }
> +
> ret = prepare_signaling(dev, state, arg, file_priv, _state,
> _fences);
> if (ret)
Re: [PATCH] dt-bindings: use capital "OR" for multiple licenses in SPDX
On Thu, 08 Feb 2024 11:53:27 +0100, Krzysztof Kozlowski wrote: > Documentation/process/license-rules.rst and checkpatch expect the SPDX > identifier syntax for multiple licenses to use capital "OR". Correct it > to keep consistent format and avoid copy-paste issues. > > Signed-off-by: Krzysztof Kozlowski > --- > .../devicetree/bindings/display/panel/visionox,r66451.yaml | 2 +- > Documentation/devicetree/bindings/usb/cypress,hx3.yaml | 2 +- > include/dt-bindings/power/amlogic,c3-pwrc.h | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > Applied, thanks!
Re: [PATCH] drm/crtc: fix uninitialized variable use even harder
On Mon, 12 Feb 2024 13:55:34 -0800, Rob Clark wrote: > DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop), > which means we can't rely too much on variable initializers. > > Applied to drm-misc-fixes, thanks! [1/1] drm/crtc: fix uninitialized variable use even harder commit: b6802b61a9d0e99dcfa6fff7c50db7c48a9623d3 Best regards, -- Dmitry Baryshkov
Re: [PATCH] drm/crtc: fix uninitialized variable use even harder
On Tue, 13 Feb 2024 at 15:50, Dmitry Baryshkov
wrote:
>
> On Mon, 12 Feb 2024 at 23:55, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
> > which means we can't rely too much on variable initializers.
> >
> > Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable use")
> > Signed-off-by: Rob Clark
> > ---
> > I have mixed feelings about DRM_MODESET_LOCK_ALL_BEGIN() (and friends)
> > magic. On one hand it simplifies the deadlock/back dance. OTOH it
> > conceals a nasty sharp edge. Maybe it is better to have the complicated
> > restart path a bit more explicit, like it was originally.
> >
> > drivers/gpu/drm/drm_crtc.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index cb90e70d85e8..65f9f66933bb 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -904,6 +904,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> > connector_set = NULL;
> > fb = NULL;
> > mode = NULL;
> > + num_connectors = 0;
>
> Nit: I think we should move all this next to the
> DRM_MODESET_LOCK_ALL_BEGIN() and drop initialisation from the prologue
> of the function, but it's definitely a separate and more intrusive
> story.
>
> Reviewed-by: Dmitry Baryshkov
After running this through CI:
Tested-by: Dmitry Baryshkov #sc7180, sdm845
> > DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
>
>
> --
> With best wishes
> Dmitry
--
With best wishes
Dmitry
[PATCH v2 6/6] drm: add drm_mode_atomic_commit event
With this and the dma_fence_sync_to event, a tool can draw the
relationship between the compositing draw, the atomic commit, and vblank.
An example on a 2 monitors system look like this:
gnome-shell-1638[018] . 2571.905124: drm_mode_atomic_commit:
file=245c3f0c, pid=1165, flags=0201, crtcs={0x1}
gnome-shell-1638[018] . 2571.905147: dma_fence_sync_to:
driver=drm_sched timeline=gfx_0.0.0 context=270 seqno=73240
reason=dma_fence_chain_init
gnome-shell-1638[018] . 2571.913226: drm_mode_atomic_commit:
file=245c3f0c, pid=1165, flags=0201, crtcs={0x0}
gnome-shell-1638[018] . 2571.913250: dma_fence_sync_to:
driver=drm_sched timeline=gfx_0.0.0 context=270 seqno=73241
reason=dma_fence_chain_init
-0 [018] d.h3. 2571.915687: drm_vblank_event: crtc=1,
seq=155747, time=2571916093743, high-prec=true
-0 [018] d.h3. 2571.915968: drm_vblank_event: crtc=0,
seq=153862, time=2571916377180, high-prec=true
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/drm_atomic_uapi.c | 19 +++
drivers/gpu/drm/drm_trace.h | 28 ++--
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 29d4940188d4..0d3767cd155a 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -41,6 +41,7 @@
#include
#include "drm_crtc_internal.h"
+#include "drm_trace.h"
/**
* DOC: overview
@@ -1503,6 +1504,24 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
drm_mode_object_put(obj);
}
+ if (trace_drm_mode_atomic_commit_enabled()) {
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *crtc;
+ int *crtcs;
+ int i, num_crtcs;
+
+ crtcs = kcalloc(dev->mode_config.num_crtc, sizeof(int),
+ GFP_KERNEL);
+
+ num_crtcs = 0;
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+ crtcs[num_crtcs++] = drm_crtc_index(crtc);
+
+ trace_drm_mode_atomic_commit(file_priv, crtcs, num_crtcs,
arg->flags);
+
+ kfree(crtcs);
+ }
+
ret = prepare_signaling(dev, state, arg, file_priv, _state,
_fences);
if (ret)
diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
index 11c6dd577e8e..b62a44cb1270 100644
--- a/drivers/gpu/drm/drm_trace.h
+++ b/drivers/gpu/drm/drm_trace.h
@@ -62,8 +62,32 @@ TRACE_EVENT(drm_vblank_event_delivered,
__entry->crtc = crtc;
__entry->seq = seq;
),
- TP_printk("file=%p, crtc=%d, seq=%u", __entry->file, __entry->crtc,
\
- __entry->seq)
+ TP_printk("file=%p, crtc=%d, seq=%u, pid=%8d", \
+ __entry->file, __entry->crtc, __entry->seq, \
+ pid_nr(__entry->file->pid))
+);
+
+TRACE_EVENT(drm_mode_atomic_commit,
+ TP_PROTO(struct drm_file *file, int *crtcs, int ncrtcs, uint32_t
flags),
+ TP_ARGS(file, crtcs, ncrtcs, flags),
+ TP_STRUCT__entry(
+ __field(struct drm_file *, file)
+ __dynamic_array(u32, crtcs, ncrtcs)
+ __field(uint32_t, ncrtcs)
+ __field(uint32_t, flags)
+ ),
+ TP_fast_assign(
+ unsigned int i;
+
+ __entry->file = file;
+ for (i = 0; i < ncrtcs; i++)
+ ((u32 *)__get_dynamic_array(crtcs))[i] = crtcs[i];
+ __entry->ncrtcs = ncrtcs;
+ __entry->flags = flags;
+ ),
+ TP_printk("file=%p, pid=%8d, flags=%08x, crtcs=%s", __entry->file, \
+ pid_nr(__entry->file->pid), __entry->flags, \
+ __print_array(__get_dynamic_array(crtcs),
__entry->ncrtcs, 4))
);
#endif /* _DRM_TRACE_H_ */
--
2.40.1
[PATCH v2 5/6] drm/amdgpu: add a amdgpu_cs_ioctl2 event
amdgpu_cs_ioctl already exists but serves a different
purpose.
amdgpu_cs_ioctl2 marks the beginning of the kernel processing of
the ioctl which is useful for tools to map which events belong to
the same submission (without this, the first event would be the
amdgpu_bo_set_list ones).
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 12
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 6830892383c3..29e43a66d0d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1402,6 +1402,8 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
return r;
}
+ trace_amdgpu_cs_ioctl2(data);
+
r = amdgpu_cs_pass1(, data);
if (r)
goto error_fini;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index e8ea1cfe7027..24e95560ede5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -189,6 +189,18 @@ TRACE_EVENT(amdgpu_cs_ioctl,
__entry->seqno, __get_str(ring), __entry->num_ibs)
);
+TRACE_EVENT(amdgpu_cs_ioctl2,
+ TP_PROTO(union drm_amdgpu_cs *cs),
+ TP_ARGS(cs),
+ TP_STRUCT__entry(
+__field(uint32_t, ctx_id)
+ ),
+ TP_fast_assign(
+ __entry->ctx_id = cs->in.ctx_id;
+ ),
+ TP_printk("context=%u", __entry->ctx_id)
+);
+
TRACE_EVENT(amdgpu_sched_run_job,
TP_PROTO(struct amdgpu_job *job),
TP_ARGS(job),
--
2.40.1
[PATCH v2 4/6] drm/amdgpu: add BO clear event
Useful to identify why sdma jobs are submitted.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 16
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 425cebcc5cbf..7219f329d6f0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -631,6 +631,8 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
bo->tbo.resource->mem_type == TTM_PL_VRAM) {
struct dma_fence *fence;
+ trace_amdgpu_bo_clear(bo);
+
r = amdgpu_fill_buffer(bo, 0, bo->tbo.base.resv, , true);
if (unlikely(r))
goto fail_unreserve;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index f539b1d00234..e8ea1cfe7027 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -514,6 +514,22 @@ TRACE_EVENT(amdgpu_bo_move,
__entry->new_placement, __entry->bo_size)
);
+TRACE_EVENT(amdgpu_bo_clear,
+ TP_PROTO(struct amdgpu_bo *bo),
+ TP_ARGS(bo),
+ TP_STRUCT__entry(
+ __field(struct amdgpu_bo *, bo)
+ __field(u64, bo_size)
+ ),
+
+ TP_fast_assign(
+ __entry->bo = bo;
+ __entry->bo_size = amdgpu_bo_size(bo);
+ ),
+ TP_printk("bo=%p, size=%lld",
+ __entry->bo, __entry->bo_size)
+);
+
TRACE_EVENT(amdgpu_ib_pipe_sync,
TP_PROTO(struct amdgpu_job *sched_job, struct dma_fence *fence),
TP_ARGS(sched_job, fence),
--
2.40.1
[PATCH v2 3/6] amdgpu: use trace_dma_fence_sync_to in amdgpu_fence_sync
This makes it possible to understand the dependencies between jobs.
Possible usage of this trace:
* stuttering issues like Mesa !9189
* incorrect synchronization: I don't have a link for this one, but having
these events was very useful to debug a virtio-gpu / native-context /
radeonsi sync issue
I have prototype code using this in UMR, as can be see here:
https://gitlab.freedesktop.org/tomstdenis/umr/-/merge_requests/37
The 'reason' param currently uses __func__ but I didn't add a macro for
this because it'd be interesting to use more descriptive names for each
use of amdgpu_fence_sync.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 14 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 8 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 11 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c | 4 ++--
7 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index d17b2452cb1f..fde98e48c84b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -491,7 +491,7 @@ static int vm_update_pds(struct amdgpu_vm *vm, struct
amdgpu_sync *sync)
if (ret)
return ret;
- return amdgpu_sync_fence(sync, vm->last_update);
+ return amdgpu_sync_fence(sync, vm->last_update, __func__);
}
static uint64_t get_pte_flags(struct amdgpu_device *adev, struct kgd_mem *mem)
@@ -1251,7 +1251,7 @@ static void unmap_bo_from_gpuvm(struct kgd_mem *mem,
amdgpu_vm_clear_freed(adev, vm, _va->last_pt_update);
- amdgpu_sync_fence(sync, bo_va->last_pt_update);
+ amdgpu_sync_fence(sync, bo_va->last_pt_update, __func__);
}
static int update_gpuvm_pte(struct kgd_mem *mem,
@@ -1273,7 +1273,7 @@ static int update_gpuvm_pte(struct kgd_mem *mem,
return ret;
}
- return amdgpu_sync_fence(sync, bo_va->last_pt_update);
+ return amdgpu_sync_fence(sync, bo_va->last_pt_update, __func__);
}
static int map_bo_to_gpuvm(struct kgd_mem *mem,
@@ -2910,7 +2910,7 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
}
dma_resv_for_each_fence(, bo->tbo.base.resv,
DMA_RESV_USAGE_KERNEL, fence) {
- ret = amdgpu_sync_fence(_obj, fence);
+ ret = amdgpu_sync_fence(_obj, fence, __func__);
if (ret) {
pr_debug("Memory eviction: Sync BO fence
failed. Try again\n");
goto validate_map_fail;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 6adeddfb3d56..6830892383c3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -423,7 +423,7 @@ static int amdgpu_cs_p2_dependencies(struct
amdgpu_cs_parser *p,
dma_fence_put(old);
}
- r = amdgpu_sync_fence(>sync, fence);
+ r = amdgpu_sync_fence(>sync, fence, __func__);
dma_fence_put(fence);
if (r)
return r;
@@ -445,7 +445,7 @@ static int amdgpu_syncobj_lookup_and_add(struct
amdgpu_cs_parser *p,
return r;
}
- r = amdgpu_sync_fence(>sync, fence);
+ r = amdgpu_sync_fence(>sync, fence, __func__);
dma_fence_put(fence);
return r;
}
@@ -1101,7 +1101,7 @@ static int amdgpu_cs_vm_handling(struct amdgpu_cs_parser
*p)
if (r)
return r;
- r = amdgpu_sync_fence(>sync, fpriv->prt_va->last_pt_update);
+ r = amdgpu_sync_fence(>sync, fpriv->prt_va->last_pt_update,
__func__);
if (r)
return r;
@@ -1112,7 +1112,7 @@ static int amdgpu_cs_vm_handling(struct amdgpu_cs_parser
*p)
if (r)
return r;
- r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
+ r = amdgpu_sync_fence(>sync, bo_va->last_pt_update,
__func__);
if (r)
return r;
}
@@ -1131,7 +1131,7 @@ static int amdgpu_cs_vm_handling(struct amdgpu_cs_parser
*p)
if (r)
return r;
- r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
+ r = amdgpu_sync_fence(>sync, bo_va->last_pt_update,
__func__);
if (r)
return r;
}
@@ -1144,7 +1144,7 @@ static int amdgpu_cs_vm_handling(struct amdgpu_cs_parser
*p)
if (r)
return r;
- r =
[PATCH v2 2/6] dma-buf/fence-chain: use trace_dma_fence_sync_to
To inform tools about the relationship between the fences.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/dma-buf/dma-fence-chain.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
index 9663ba1bb6ac..a211b3d4156a 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -9,6 +9,8 @@
#include
+#include "trace/events/dma_fence.h"
+
static bool dma_fence_chain_enable_signaling(struct dma_fence *fence);
/**
@@ -251,6 +253,8 @@ void dma_fence_chain_init(struct dma_fence_chain *chain,
chain->fence = fence;
chain->prev_seqno = 0;
+ trace_dma_fence_sync_to(fence, __func__);
+
/* Try to reuse the context of the previous chain node. */
if (prev_chain && __dma_fence_is_later(seqno, prev->seqno, prev->ops)) {
context = prev->context;
--
2.40.1
[PATCH v2 1/6] tracing, dma-buf: add a trace_dma_fence_sync_to event
This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.
I plan to use it in amdgpu.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/dma-buf/dma-fence.c | 1 +
include/trace/events/dma_fence.h | 34
2 files changed, 35 insertions(+)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index e0fd99e61a2d..671a499a5ccd 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -23,6 +23,7 @@
EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
+EXPORT_TRACEPOINT_SYMBOL(dma_fence_sync_to);
static DEFINE_SPINLOCK(dma_fence_stub_lock);
static struct dma_fence dma_fence_stub;
diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h
index 3963e79ca7b4..9b3875f7aa79 100644
--- a/include/trace/events/dma_fence.h
+++ b/include/trace/events/dma_fence.h
@@ -83,6 +83,40 @@ DEFINE_EVENT(dma_fence, dma_fence_wait_end,
TP_ARGS(fence)
);
+DECLARE_EVENT_CLASS(dma_fence_from,
+
+ TP_PROTO(struct dma_fence *fence, const char *reason),
+
+ TP_ARGS(fence, reason),
+
+ TP_STRUCT__entry(
+ __string(driver, fence->ops->get_driver_name(fence))
+ __string(timeline, fence->ops->get_timeline_name(fence))
+ __field(unsigned int, context)
+ __field(unsigned int, seqno)
+ __string(reason, reason)
+ ),
+
+ TP_fast_assign(
+ __assign_str(driver, fence->ops->get_driver_name(fence));
+ __assign_str(timeline, fence->ops->get_timeline_name(fence));
+ __entry->context = fence->context;
+ __entry->seqno = fence->seqno;
+ __assign_str(reason, reason);
+ ),
+
+ TP_printk("driver=%s timeline=%s context=%u seqno=%u reason=%s",
+ __get_str(driver), __get_str(timeline), __entry->context,
+ __entry->seqno, __get_str(reason))
+);
+
+DEFINE_EVENT(dma_fence_from, dma_fence_sync_to,
+
+ TP_PROTO(struct dma_fence *fence, const char *reason),
+
+ TP_ARGS(fence, reason)
+);
+
#endif /* _TRACE_DMA_FENCE_H */
/* This part must be outside protection */
--
2.40.1
[PATCH v2 0/6] dma-fence, drm, amdgpu new trace events
This series adds new events to make it easier for tools like gpuvis or umr to graph the GPUs, kernel and applications activity. UMR patches using these events can be found here: https://gitlab.freedesktop.org/tomstdenis/umr/-/merge_requests/37 V1: https://patchwork.kernel.org/project/linux-media/patch/20240117184329.479554-1-pierre-eric.pelloux-pra...@amd.com/ Changes from V1: * uses trace_dma_fence_sync_to from dma-fence-chain.c * new amdgpu events * new drm plane commit event Pierre-Eric Pelloux-Prayer (6): tracing, dma-buf: add a trace_dma_fence_sync_to event dma-buf/fence-chain: use trace_dma_fence_sync_to amdgpu: use trace_dma_fence_sync_to in amdgpu_fence_sync drm/amdgpu: add BO clear event drm/amdgpu: add a amdgpu_cs_ioctl2 event drm: add drm_mode_atomic_commit event drivers/dma-buf/dma-fence-chain.c | 4 +++ drivers/dma-buf/dma-fence.c | 1 + .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 16 + drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 8 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 4 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 11 -- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 28 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c | 4 +-- drivers/gpu/drm/drm_atomic_uapi.c | 19 +++ drivers/gpu/drm/drm_trace.h | 28 +-- include/trace/events/dma_fence.h | 34 +++ 14 files changed, 144 insertions(+), 26 deletions(-) -- 2.40.1
Re: [etnaviv-next v13 7/7] drm/etnaviv: Add support for vivante GPU cores attached via PCI(e)
Hi, On 2024/2/13 22:38, Maxime Ripard wrote: On Sat, Feb 10, 2024 at 12:25:33AM +0800, Sui Jingfeng wrote: On 2024/2/9 23:15, Maxime Ripard wrote: On Fri, Feb 09, 2024 at 12:02:48PM +0100, Daniel Vetter wrote: On Thu, Feb 08, 2024 at 04:27:02PM +0100, Maxime Ripard wrote: On Wed, Feb 07, 2024 at 10:35:49AM +0100, Daniel Vetter wrote: On Wed, Feb 07, 2024 at 01:27:59AM +0800, Sui Jingfeng wrote: The component helper functions are the glue, which is used to bind multiple GPU cores to a virtual master platform device. Which is fine and works well for the SoCs who contains multiple GPU cores. The problem is that usperspace programs (such as X server and Mesa) will search the PCIe device to use if it is exist. In other words, usperspace programs open the PCIe device with higher priority. Creating a virtual master platform device for PCI(e) GPUs is unnecessary, as the PCI device has been created by the time drm/etnaviv is loaded. we create virtual platform devices as a representation for the vivante GPU ip core. As all of subcomponent are attached via the PCIe master device, we reflect this hardware layout by binding all of the virtual child to the the real master. Signed-off-by: Sui Jingfeng Uh so my understanding is that drivers really shouldn't create platform devices of their own. For this case here I think the aux-bus framework is the right thing to use. Alternatively would be some infrastructure where you feed a DT tree to driver core or pci subsystem and it instantiates it all for you correctly, and especially with hotunplug all done right since this is pci now, not actually part of the soc that cannot be hotunplugged. I don't think we need intermediate platform devices at all. We just need to register our GPU against the PCI device and that's it. We don't need a platform device, we don't need the component framework. Afaik that's what this series does. The component stuff is for the internal structure of the gpu ip, so that the same modular approach that works for arm-soc also works for pci chips. But there should be a single PCI device, while we have multiple "DT" devices, right? Or is there several PCI devices too on that PCI card? There is only a single PCI(e) device on that PCI(e) card, this single PCI(e) device is selected as the component master. All other Hardware IP blocks are shipped by the single PCI(e) master. It may includes Display controllers, GPUs, video decoders, HDMI display bridges hardware unit etc. But all of those Hardware IP share the same MMIO registers PCI BAR, this PCI BAR is a kind of PCI(e) MEM resource. It is a relative *big* chunk, as large as 32MB in address ranges for the JingJia Macro dGPU. Therefore, I break the whole registers memory(MMIO) resource into smaller pieces by creating platform device manually, manually created platform device is called as virtual child in this series. In short, we cut the whole into smaller piece, each smaller piece is a single hardware IP block, thus deserve a single device driver. We will have multiple platform devices if the dGPU contains multiple hardware IP block. On the driver side, we bind all of the scattered driver module with component. That's kind of my point then. If there's a single device, there's no need to create intermediate devices and use the component framework to tie them all together. You can have a simpler approach where you create a function that takes the memory area it operates on (and whatever additional resource it needs: interrupt, clocks, etc.) and call that directly from the PCIe device probe, and the MMIO device bind. Yes, you are right. I have implemented the method just as you told me at V12 of this series (see 0004 patch at [1]). But at V13, I suddenly realized that the component code path plus(+) non-component code path yield a "side-by-side" implement. The old non-component approach can not support binding multiple sub-core, it can only support one Vivante GPU IP core case. But there are dGPU which shipping two identical core. While, the component-based approach implemented at this version is the most universal and the most flexible and extensible. We could bind a virtual display driver and/or a real display driver to the real master (refer to the PCI(e) device). The PCI(e) device is responsible for present the DRM service to userspace, like a leader or agent. All other sub hardware and software are hiding behind of the master. Besides, Lucas asked me implement the driver like this way at V10 (see [2]) Lucas said: "My favorite option would be to just always use the component path even when the GPU is on a PCI device to keep both paths mostly aligned. One could easily image both a 3D and a 2D core being made available though the same PCI device." Lucas, are you watching? How about this version? Can you help to review please? [1] https://patchwork.freedesktop.org/series/127084/ [2]
Re: [PATCH 1/2] [v3] nouveau: add command-line GSP-RM registry support
On 2/12/24 22:15, Timur Tabi wrote:
Add the NVreg_RegistryDwords command line parameter, which allows
specifying additional registry keys to be sent to GSP-RM. This
allows additional configuration, debugging, and experimentation
with GSP-RM, which uses these keys to alter its behavior.
Note that these keys are passed as-is to GSP-RM, and Nouveau does
not parse them. This is in contrast to the Nvidia driver, which may
parse some of the keys to configure some functionality in concert with
GSP-RM. Therefore, any keys which also require action by the driver
may not function correctly when passed by Nouveau. Caveat emptor.
The name and format of NVreg_RegistryDwords is the same as used by
the Nvidia driver, to maintain compatibility.
Signed-off-by: Timur Tabi
---
v3: rebased to drm-next
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 6 +
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 279 --
2 files changed, 261 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
index 6f5d376d8fcc..3fbc57b16a05 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
@@ -211,6 +211,12 @@ struct nvkm_gsp {
struct mutex mutex;;
struct idr idr;
} client_id;
+
+ /* A linked list of registry items. The registry RPC will be built from
it. */
+ struct list_head registry_list;
+
+ /* The size of the registry RPC */
+ size_t registry_rpc_size;
};
static inline bool
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 1c46e3f919be..86b62c7e1229 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -54,6 +54,8 @@
#include
#include
+#include
+#include
#define GSP_MSG_MIN_SIZE GSP_PAGE_SIZE
#define GSP_MSG_MAX_SIZE GSP_PAGE_MIN_SIZE * 16
@@ -1082,51 +1084,280 @@ r535_gsp_rpc_unloading_guest_driver(struct nvkm_gsp
*gsp, bool suspend)
return nvkm_gsp_rpc_wr(gsp, rpc, true);
}
+struct registry_list_entry {
+ struct list_head list;
Nit: 'head' or 'entry' might be more suitable.
+ size_t name_len;
+ u32 type;
I prefer to represent type as enum or use a define for '1 = integer' instead.
This also gets you rid of the need to explicitly explain it's meaning in the
documentation of add_registry().
+ u32 data;
+ u32 length;
+ char name[];
+};
+
+/**
+ * add_registry -- adds a registry entry
+ * @gsp: gsp pointer
+ * @name: name of the registry key
+ * @type: type of data (1 = integer)
+ * @data: value
+ * @length: size of data, in bytes
+ *
+ * Adds a registry key/value pair to the registry database.
+ *
+ * Currently, only 32-bit integers (type == 1, length == 4) are supported.
What if we pass something else? This function doesn't seem to ensure nothing
else is accepted. Although I recognize that it's only used by add_registry_num()
enforcing this limitation by it's function signature.
+ *
+ * This function collects the registry information in a linked list. After
+ * all registry keys have been added, build_registry() is used to create the
+ * RPC data structure.
+ *
+ * registry_rpc_size is a running total of the size of all registry keys.
+ * It's used to avoid an O(n) calculation of the size when the RPC is built.
+ *
+ * Returns 0 on success, or negative error code on error.
+ */
+static int add_registry(struct nvkm_gsp *gsp, const char *name, u32 type, u32
data, u32 length)
+{
+ struct registry_list_entry *reg;
+ size_t nlen = strlen(name) + 1;
+
+ /* Set an arbitrary limit to avoid problems with broken command lines */
+ if (strlen(name) > 64)
Could re-use nlen for this check.
+ return -EFBIG;
This error code doesn't seem to apply here, prefer EINVAL.
+
+ reg = kmalloc(sizeof(struct registry_list_entry) + nlen, GFP_KERNEL);
+ if (!reg)
+ return -ENOMEM;
+
+ memcpy(reg->name, name, nlen);
+ reg->name_len = nlen;
+ reg->type = type;
+ reg->data = data;
+ reg->length = length;
+
+ nvkm_debug(>subdev, "adding GSP-RM registry '%s=%u'\n", name,
data);
+ list_add_tail(>list, >registry_list);
+ gsp->registry_rpc_size += sizeof(PACKED_REGISTRY_ENTRY) + nlen;
+
+ return 0;
+}
+
+static int add_registry_num(struct nvkm_gsp *gsp, const char *name, u32 value)
+{
+ return add_registry(gsp, name, 1, value, sizeof(u32));
+}
+
+/**
+ * build_registry -- create the registry RPC data
+ * @gsp: gsp pointer
+ * @registry: pointer to the RPC payload to fill
+ *
+ * After all registry key/value pairs have been added, call this function to
+ * build the RPC.
+ *
+ * The registry RPC looks like this:
+ *
+ * +-+
+ * |NvU32 size; |
+ * |NvU32
Re: [PATCH 2/2] drm/tests/drm_buddy: add alloc_contiguous test
Am 13.02.24 um 15:28 schrieb Matthew Auld:
On 13/02/2024 13:52, Arunpravin Paneer Selvam wrote:
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Reviewed-by: Arunpravin Paneer Selvam
It looks like you changed the patch authorship here.
Going to fix this if I get tasked with pushing this to drm-misc-fixes.
But I still have hope that Arun will figure out how to do this himself.
Christian.
Cc: Arunpravin Paneer Selvam
Cc: Limonciello
Cc: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/tests/drm_buddy_test.c | 89 ++
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index ea2af6bd9abe..fee6bec757d1 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
@@ -18,6 +19,93 @@ static inline u64 get_size(int order, u64
chunk_size)
return (1 << order) * chunk_size;
}
+static void drm_test_buddy_alloc_contiguous(struct kunit *test)
+{
+ u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ struct drm_buddy_block *block;
+ struct drm_buddy mm;
+ LIST_HEAD(left);
+ LIST_HEAD(middle);
+ LIST_HEAD(right);
+ LIST_HEAD(allocated);
+
+ mm_size = 16 * 3 * SZ_4K;
+
+ KUNIT_EXPECT_FALSE(test, drm_buddy_init(, mm_size, ps));
+
+ /*
+ * Idea is to fragment the address space by alternating block
+ * allocations between three different lists; one for left,
middle and
+ * right. We can then free a list to simulate fragmentation. In
+ * particular we want to exercise the
DRM_BUDDY_CONTIGUOUS_ALLOCATION,
+ * including the try_harder path.
+ */
+
+ i = 0;
+ n_pages = mm_size / ps;
+ do {
+ struct list_head *list;
+ int slot = i % 3;
+
+ if (slot == 0)
+ list =
+ else if (slot == 1)
+ list =
+ else
+ list =
+ KUNIT_ASSERT_FALSE_MSG(test,
+ drm_buddy_alloc_blocks(, 0, mm_size,
+ ps, ps, list, 0),
+ "buddy_alloc hit an error size=%d\n",
+ ps);
+ } while (++i < n_pages);
+
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%d\n", 3 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ /*
+ * At this point we should have enough contiguous space for 2
blocks,
+ * however they are never buddies (since we freed middle and
right) so
+ * will require the try_harder logic to find them.
+ */
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0,
mm_size,
+ 2 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0,
mm_size,
+ 3 * ps, ps, ,
+ DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 3 * ps);
+
+ total = 0;
+ list_for_each_entry(block, , link)
+ total += drm_buddy_block_size(, block);
+
+ KUNIT_ASSERT_EQ(test, total, ps * 2 + ps * 3);
+
+ drm_buddy_free_list(, );
+ drm_buddy_fini();
+}
+
static void drm_test_buddy_alloc_pathological(struct kunit *test)
{
u64 mm_size, size, start = 0;
@@ -280,6 +368,7 @@ static struct kunit_case drm_buddy_tests[] = {
KUNIT_CASE(drm_test_buddy_alloc_optimistic),
KUNIT_CASE(drm_test_buddy_alloc_pessimistic),
KUNIT_CASE(drm_test_buddy_alloc_pathological),
+ KUNIT_CASE(drm_test_buddy_alloc_contiguous),
{}
};
Re: [PATCH] drm/xe: skip building debugfs code for CONFIG_DEBUG_FS=n
On Tue, Feb 13, 2024, at 15:55, Jani Nikula wrote:
> On Tue, 13 Feb 2024, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> Some of the debugfs functions are stubbed out in these configurations,
>> so trying to build the .c file with the definition fails:
>>
>> In file included from include/uapi/linux/posix_types.h:5,
>> from drivers/gpu/drm/i915/display/intel_pipe_crc.c:27:
>> drivers/gpu/drm/i915/display/intel_pipe_crc.c: At top level:
>> include/linux/stddef.h:8:16: error: expected identifier or '(' before 'void'
>> 8 | #define NULL ((void *)0)
>> |^~~~
>> drivers/gpu/drm/i915/display/intel_pipe_crc.c:549:20: note: in expansion of
>> macro 'intel_crtc_get_crc_sources'
>> 549 | const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
>> |^~
>>
>> Stop trying to build them by making the Makefile entries conditional,
>> same as for the i915 driver.
>
> Already fixed by commit 439987f6f471 ("drm/xe: don't build debugfs files
> when CONFIG_DEBUG_FS=n") in drm-xe-next.
>
> Maybe that needs to be picked up for -fixes?
I made sure that this still happens in linux-next today, but
it does not seem to contain 439987f6f471.
Arnd
Re: [PATCH] drm/xe: skip building debugfs code for CONFIG_DEBUG_FS=n
On Tue, 13 Feb 2024, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Some of the debugfs functions are stubbed out in these configurations,
> so trying to build the .c file with the definition fails:
>
> In file included from include/uapi/linux/posix_types.h:5,
> from drivers/gpu/drm/i915/display/intel_pipe_crc.c:27:
> drivers/gpu/drm/i915/display/intel_pipe_crc.c: At top level:
> include/linux/stddef.h:8:16: error: expected identifier or '(' before 'void'
> 8 | #define NULL ((void *)0)
> |^~~~
> drivers/gpu/drm/i915/display/intel_pipe_crc.c:549:20: note: in expansion of
> macro 'intel_crtc_get_crc_sources'
> 549 | const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
> |^~
>
> Stop trying to build them by making the Makefile entries conditional,
> same as for the i915 driver.
Already fixed by commit 439987f6f471 ("drm/xe: don't build debugfs files
when CONFIG_DEBUG_FS=n") in drm-xe-next.
Maybe that needs to be picked up for -fixes?
BR,
Jani.
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/xe/Makefile | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
> index efcf0ab7a1a6..7c10ffdb7809 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -213,8 +213,6 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
> i915-display/intel_ddi.o \
> i915-display/intel_ddi_buf_trans.o \
> i915-display/intel_display.o \
> - i915-display/intel_display_debugfs.o \
> - i915-display/intel_display_debugfs_params.o \
> i915-display/intel_display_device.o \
> i915-display/intel_display_driver.o \
> i915-display/intel_display_irq.o \
> @@ -258,7 +256,6 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
> i915-display/intel_modeset_setup.o \
> i915-display/intel_modeset_verify.o \
> i915-display/intel_panel.o \
> - i915-display/intel_pipe_crc.o \
> i915-display/intel_pmdemand.o \
> i915-display/intel_pps.o \
> i915-display/intel_psr.o \
> @@ -275,6 +272,13 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
> i915-display/skl_universal_plane.o \
> i915-display/skl_watermark.o
>
> +ifdef CONFIG_DEBUG_FS
> +xe-$(CONFIG_DRM_XE_DISPLAY) += \
> + i915-display/intel_display_debugfs.o \
> + i915-display/intel_display_debugfs_params.o \
> + i915-display/intel_pipe_crc.o
> +endif
> +
> ifeq ($(CONFIG_ACPI),y)
> xe-$(CONFIG_DRM_XE_DISPLAY) += \
> i915-display/intel_acpi.o \
--
Jani Nikula, Intel
Re: Build regressions/improvements in v6.8-rc1
On 2024-01-23 15:21, Arnd Bergmann wrote:
>>> + /kisskb/src/arch/sparc/include/asm/floppy_64.h: error: no previous
>>> prototype for 'sparc_floppy_irq' [-Werror=missing-prototypes]: => 200:13
>>> + /kisskb/src/arch/sparc/include/asm/floppy_64.h: error: no previous
>>> prototype for 'sun_pci_fd_dma_callback' [-Werror=missing-prototypes]: =>
>>> 437:6
>>
>> sparc64-gcc{5,11,12,13}/sparc64-allmodconfig
>
> Andrew Morton did a patch for the sparc warnings, and Andreas Larsson
> is joining as a maintainer, so hopefully he can pick that up soon.
Which patch do you refer to here? I can not seem to find a patch fixing
these ones in particular on lore.kernel.org.
Thanks,
Andreas
Re: [PATCH 04/10] hid/hid-picolcd: Remove struct backlight_ops.check_fb
Hi Thomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on lee-backlight/for-backlight-next]
[also build test ERROR on lee-backlight/for-backlight-fixes hid/for-next
lee-leds/for-leds-next linus/master v6.8-rc4 next-20240213]
[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/Thomas-Zimmermann/backlight-Match-backlight-device-against-struct-fb_info-bl_dev/20240213-002853
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git
for-backlight-next
patch link:
https://lore.kernel.org/r/20240212162645.5661-5-tzimmermann%40suse.de
patch subject: [PATCH 04/10] hid/hid-picolcd: Remove struct
backlight_ops.check_fb
config: x86_64-rhel-8.3-rust
(https://download.01.org/0day-ci/archive/20240213/202402132248.a5ky78hx-...@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project
6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240213/202402132248.a5ky78hx-...@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/202402132248.a5ky78hx-...@intel.com/
All errors (new ones prefixed by >>):
>> drivers/hid/hid-picolcd_fb.c:497:8: error: no member named 'bl_dev' in
>> 'struct fb_info'
497 | info->bl_dev = data->backlight;
| ^
1 error generated.
vim +497 drivers/hid/hid-picolcd_fb.c
459
460 static DEVICE_ATTR(fb_update_rate, 0664, picolcd_fb_update_rate_show,
461 picolcd_fb_update_rate_store);
462
463 /* initialize Framebuffer device */
464 int picolcd_init_framebuffer(struct picolcd_data *data)
465 {
466 struct device *dev = >hdev->dev;
467 struct fb_info *info = NULL;
468 struct picolcd_fb_data *fbdata = NULL;
469 int i, error = -ENOMEM;
470 u32 *palette;
471
472 /* The extra memory is:
473 * - 256*u32 for pseudo_palette
474 * - struct fb_deferred_io
475 */
476 info = framebuffer_alloc(256 * sizeof(u32) +
477 sizeof(struct fb_deferred_io) +
478 sizeof(struct picolcd_fb_data) +
479 PICOLCDFB_SIZE, dev);
480 if (!info)
481 goto err_nomem;
482
483 info->fbdefio = info->par;
484 *info->fbdefio = picolcd_fb_defio;
485 info->par += sizeof(struct fb_deferred_io);
486 palette = info->par;
487 info->par += 256 * sizeof(u32);
488 for (i = 0; i < 256; i++)
489 palette[i] = i > 0 && i < 16 ? 0xff : 0;
490 info->pseudo_palette = palette;
491 info->fbops = _ops;
492 info->var = picolcdfb_var;
493 info->fix = picolcdfb_fix;
494 info->fix.smem_len = PICOLCDFB_SIZE*8;
495
496 #ifdef CONFIG_HID_PICOLCD_BACKLIGHT
> 497 info->bl_dev = data->backlight;
498 #endif
499
500 fbdata = info->par;
501 spin_lock_init(>lock);
502 fbdata->picolcd = data;
503 fbdata->update_rate = PICOLCDFB_UPDATE_RATE_DEFAULT;
504 fbdata->bpp = picolcdfb_var.bits_per_pixel;
505 fbdata->force = 1;
506 fbdata->vbitmap = info->par + sizeof(struct picolcd_fb_data);
507 fbdata->bitmap = vmalloc(PICOLCDFB_SIZE*8);
508 if (fbdata->bitmap == NULL) {
509 dev_err(dev, "can't get a free page for framebuffer\n");
510 goto err_nomem;
511 }
512 info->flags |= FBINFO_VIRTFB;
513 info->screen_buffer = fbdata->bitmap;
514 info->fix.smem_start = (unsigned long)fbdata->bitmap;
515 memset(fbdata->vbitmap, 0xff, PICOLCDFB_SIZE);
516 data->fb_info = info;
517
518 error = picolcd_fb_reset(data, 1);
519 if (error) {
520 dev_err(dev, "failed to configure display\n");
521 goto err_cleanup;
522 }
523
524 error = device_create_file(dev, _attr_fb_update_rate);
525 if (error) {
526 dev_err(dev, "failed to create sysfs attributes\n");
527 goto err_cleanup;
528 }
529
530 fb_defer
[PATCH] gpu: host1x: bus: make host1x_bus_type const
Since commit d492cc2573a0 ("driver core: device.h: make struct
bus_type a const *"), the driver core can properly handle constant
struct bus_type, move the host1x_bus_type variable to be a constant
structure as well, placing it into read-only memory which can not be
modified at runtime.
Cc: Greg Kroah-Hartman
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Ricardo B. Marliere
---
drivers/gpu/host1x/bus.c | 2 +-
drivers/gpu/host1x/bus.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 4d16a3396c4a..a20dad7f0333 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -382,7 +382,7 @@ static const struct dev_pm_ops host1x_device_pm_ops = {
.restore = pm_generic_restore,
};
-struct bus_type host1x_bus_type = {
+const struct bus_type host1x_bus_type = {
.name = "host1x",
.match = host1x_device_match,
.uevent = host1x_device_uevent,
diff --git a/drivers/gpu/host1x/bus.h b/drivers/gpu/host1x/bus.h
index a4adf9abc3b4..a80ceadfeb34 100644
--- a/drivers/gpu/host1x/bus.h
+++ b/drivers/gpu/host1x/bus.h
@@ -10,7 +10,7 @@
struct bus_type;
struct host1x;
-extern struct bus_type host1x_bus_type;
+extern const struct bus_type host1x_bus_type;
int host1x_register(struct host1x *host1x);
int host1x_unregister(struct host1x *host1x);
---
base-commit: 2429b3c529da29d4277d519bd66d034842dcd70c
change-id: 20240213-bus_cleanup-host1x-09f7f06652b9
Best regards,
--
Ricardo B. Marliere
Re: Re: [PATCH drm-misc-next] drm/xe: Fix a missing argument to drm_err_printer
On Tue, 13 Feb 2024, Maxime Ripard wrote: > On Mon, Feb 12, 2024 at 12:53:05PM +0200, Jani Nikula wrote: >> On Mon, 12 Feb 2024, Thomas Hellström >> wrote: >> > The indicated commit below added a device argument to the >> > function, but there was a call in the xe driver that was >> > not properly changed. >> >> Aww, crap. Looks like my drm-misc-next configs don't have xe enabled. > > FTR, there's defconfigs in the drm-rerere repo that are fairly well > maintained. None of them have CONFIG_DRM_XE enabled. What's the procedure for updating the defconfigs? Do we have it documented somewhere? BR, Jani. -- Jani Nikula, Intel
Re: Re: [etnaviv-next v13 7/7] drm/etnaviv: Add support for vivante GPU cores attached via PCI(e)
On Sat, Feb 10, 2024 at 12:25:33AM +0800, Sui Jingfeng wrote: > On 2024/2/9 23:15, Maxime Ripard wrote: > > On Fri, Feb 09, 2024 at 12:02:48PM +0100, Daniel Vetter wrote: > > > On Thu, Feb 08, 2024 at 04:27:02PM +0100, Maxime Ripard wrote: > > > > On Wed, Feb 07, 2024 at 10:35:49AM +0100, Daniel Vetter wrote: > > > > > On Wed, Feb 07, 2024 at 01:27:59AM +0800, Sui Jingfeng wrote: > > > > > > The component helper functions are the glue, which is used to bind > > > > > > multiple > > > > > > GPU cores to a virtual master platform device. Which is fine and > > > > > > works well > > > > > > for the SoCs who contains multiple GPU cores. > > > > > > > > > > > > The problem is that usperspace programs (such as X server and Mesa) > > > > > > will > > > > > > search the PCIe device to use if it is exist. In other words, > > > > > > usperspace > > > > > > programs open the PCIe device with higher priority. Creating a > > > > > > virtual > > > > > > master platform device for PCI(e) GPUs is unnecessary, as the PCI > > > > > > device > > > > > > has been created by the time drm/etnaviv is loaded. > > > > > > > > > > > > we create virtual platform devices as a representation for the > > > > > > vivante GPU > > > > > > ip core. As all of subcomponent are attached via the PCIe master > > > > > > device, > > > > > > we reflect this hardware layout by binding all of the virtual child > > > > > > to the > > > > > > the real master. > > > > > > > > > > > > Signed-off-by: Sui Jingfeng > > > > > Uh so my understanding is that drivers really shouldn't create > > > > > platform > > > > > devices of their own. For this case here I think the aux-bus > > > > > framework is > > > > > the right thing to use. Alternatively would be some infrastructure > > > > > where > > > > > you feed a DT tree to driver core or pci subsystem and it > > > > > instantiates it > > > > > all for you correctly, and especially with hotunplug all done right > > > > > since > > > > > this is pci now, not actually part of the soc that cannot be > > > > > hotunplugged. > > > > I don't think we need intermediate platform devices at all. We just need > > > > to register our GPU against the PCI device and that's it. We don't need > > > > a platform device, we don't need the component framework. > > > Afaik that's what this series does. The component stuff is for the > > > internal structure of the gpu ip, so that the same modular approach that > > > works for arm-soc also works for pci chips. > > But there should be a single PCI device, while we have multiple "DT" > > devices, right? Or is there several PCI devices too on that PCI card? > > > There is only a single PCI(e) device on that PCI(e) card, this single > PCI(e) device is selected as the component master. All other Hardware IP > blocks are shipped by the single PCI(e) master. It may includes Display > controllers, GPUs, video decoders, HDMI display bridges hardware unit etc. > > But all of those Hardware IP share the same MMIO registers PCI BAR, this > PCI BAR is a kind of PCI(e) MEM resource. It is a relative *big* chunk, > as large as 32MB in address ranges for the JingJia Macro dGPU. Therefore, > I break the whole registers memory(MMIO) resource into smaller pieces by > creating platform device manually, manually created platform device is > called as virtual child in this series. > > In short, we cut the whole into smaller piece, each smaller piece is a > single hardware IP block, thus deserve a single device driver. We will > have multiple platform devices if the dGPU contains multiple hardware > IP block. On the driver side, we bind all of the scattered driver module > with component. That's kind of my point then. If there's a single device, there's no need to create intermediate devices and use the component framework to tie them all together. You can have a simpler approach where you create a function that takes the memory area it operates on (and whatever additional resource it needs: interrupt, clocks, etc.) and call that directly from the PCIe device probe, and the MMIO device bind. Maxime signature.asc Description: PGP signature
Re: [PATCH 2/2] drm/tests/drm_buddy: add alloc_contiguous test
On 13/02/2024 13:52, Arunpravin Paneer Selvam wrote:
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Reviewed-by: Arunpravin Paneer Selvam
It looks like you changed the patch authorship here.
Cc: Arunpravin Paneer Selvam
Cc: Limonciello
Cc: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/tests/drm_buddy_test.c | 89 ++
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index ea2af6bd9abe..fee6bec757d1 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
@@ -18,6 +19,93 @@ static inline u64 get_size(int order, u64 chunk_size)
return (1 << order) * chunk_size;
}
+static void drm_test_buddy_alloc_contiguous(struct kunit *test)
+{
+ u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ struct drm_buddy_block *block;
+ struct drm_buddy mm;
+ LIST_HEAD(left);
+ LIST_HEAD(middle);
+ LIST_HEAD(right);
+ LIST_HEAD(allocated);
+
+ mm_size = 16 * 3 * SZ_4K;
+
+ KUNIT_EXPECT_FALSE(test, drm_buddy_init(, mm_size, ps));
+
+ /*
+* Idea is to fragment the address space by alternating block
+* allocations between three different lists; one for left, middle and
+* right. We can then free a list to simulate fragmentation. In
+* particular we want to exercise the DRM_BUDDY_CONTIGUOUS_ALLOCATION,
+* including the try_harder path.
+*/
+
+ i = 0;
+ n_pages = mm_size / ps;
+ do {
+ struct list_head *list;
+ int slot = i % 3;
+
+ if (slot == 0)
+ list =
+ else if (slot == 1)
+ list =
+ else
+ list =
+ KUNIT_ASSERT_FALSE_MSG(test,
+ drm_buddy_alloc_blocks(, 0, mm_size,
+ ps, ps, list, 0),
+ "buddy_alloc hit an error size=%d\n",
+ ps);
+ } while (++i < n_pages);
+
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%d\n", 3 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ /*
+* At this point we should have enough contiguous space for 2 blocks,
+* however they are never buddies (since we freed middle and right) so
+* will require the try_harder logic to find them.
+*/
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 3 * ps);
+
+ total = 0;
+ list_for_each_entry(block, , link)
+ total += drm_buddy_block_size(, block);
+
+ KUNIT_ASSERT_EQ(test, total, ps * 2 + ps * 3);
+
+ drm_buddy_free_list(, );
+ drm_buddy_fini();
+}
+
static void drm_test_buddy_alloc_pathological(struct kunit *test)
{
u64 mm_size, size, start
Re: Re: [PATCH drm-misc-next] drm/xe: Fix a missing argument to drm_err_printer
On Mon, Feb 12, 2024 at 12:53:05PM +0200, Jani Nikula wrote: > On Mon, 12 Feb 2024, Thomas Hellström > wrote: > > The indicated commit below added a device argument to the > > function, but there was a call in the xe driver that was > > not properly changed. > > Aww, crap. Looks like my drm-misc-next configs don't have xe enabled. FTR, there's defconfigs in the drm-rerere repo that are fairly well maintained. Maxime signature.asc Description: PGP signature
Re: [syzbot] [dri?] KASAN: slab-use-after-free Read in drm_atomic_helper_wait_for_vblanks (2)
syzbot has found a reproducer for the following issue on: HEAD commit:c664e16bb1ba Merge tag 'docs-6.8-fixes2' of git://git.lwn... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14f8d1e018 kernel config: https://syzkaller.appspot.com/x/.config?x=df82262440d95bc4 dashboard link: https://syzkaller.appspot.com/bug?extid=0f999d26a4fd79c3a23b compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1086cd4818 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11fcdba218 Downloadable assets: disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk-c664e16b.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/c838390fdb6c/vmlinux-c664e16b.xz kernel image: https://storage.googleapis.com/syzbot-assets/d25123cb1896/bzImage-c664e16b.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+0f999d26a4fd79c3a...@syzkaller.appspotmail.com == BUG: KASAN: slab-use-after-free in drm_atomic_helper_wait_for_vblanks.part.0+0x84f/0x930 drivers/gpu/drm/drm_atomic_helper.c:1661 Read of size 1 at addr 88802d6f0409 by task kworker/u16:1/13 CPU: 1 PID: 13 Comm: kworker/u16:1 Not tainted 6.8.0-rc4-syzkaller-5-gc664e16bb1ba #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Workqueue: events_unbound commit_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 drm_atomic_helper_wait_for_vblanks.part.0+0x84f/0x930 drivers/gpu/drm/drm_atomic_helper.c:1661 drm_atomic_helper_wait_for_vblanks drivers/gpu/drm/drm_atomic_helper.c:1657 [inline] drm_atomic_helper_commit_tail+0xcb/0xf0 drivers/gpu/drm/drm_atomic_helper.c:1757 commit_tail+0x356/0x410 drivers/gpu/drm/drm_atomic_helper.c:1834 process_one_work+0x889/0x15e0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x12a0 kernel/workqueue.c:2787 kthread+0x2c6/0x3b0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 Allocated by task 5401: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:372 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:389 kmalloc include/linux/slab.h:590 [inline] drm_atomic_helper_crtc_duplicate_state+0x70/0xd0 drivers/gpu/drm/drm_atomic_state_helper.c:177 drm_atomic_get_crtc_state+0x162/0x440 drivers/gpu/drm/drm_atomic.c:362 page_flip_common+0x57/0x320 drivers/gpu/drm/drm_atomic_helper.c:3629 drm_atomic_helper_page_flip+0xb6/0x190 drivers/gpu/drm/drm_atomic_helper.c:3690 drm_mode_page_flip_ioctl+0x103f/0x1470 drivers/gpu/drm/drm_plane.c:1489 drm_ioctl_kernel+0x1ec/0x3e0 drivers/gpu/drm/drm_ioctl.c:744 drm_ioctl+0x5d8/0xc00 drivers/gpu/drm/drm_ioctl.c:841 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl fs/ioctl.c:857 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd5/0x270 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77 Freed by task 5401: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1c0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kfree+0x124/0x370 mm/slub.c:4409 drm_atomic_state_default_clear+0x3aa/0xde0 drivers/gpu/drm/drm_atomic.c:225 drm_atomic_state_clear drivers/gpu/drm/drm_atomic.c:294 [inline] __drm_atomic_state_free+0x185/0x2b0 drivers/gpu/drm/drm_atomic.c:311 kref_put include/linux/kref.h:65 [inline] drm_atomic_state_put include/drm/drm_atomic.h:490 [inline] drm_client_modeset_commit_atomic+0x6db/0x810 drivers/gpu/drm/drm_client_modeset.c:1057 drm_client_modeset_commit_locked+0x14d/0x580 drivers/gpu/drm/drm_client_modeset.c:1154 drm_client_modeset_commit+0x4f/0x80 drivers/gpu/drm/drm_client_modeset.c:1180 __drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:251 [inline] __drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:230 [inline] drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:278 [inline] drm_fb_helper_lastclose+0xc7/0x160 drivers/gpu/drm/drm_fb_helper.c:2005 drm_fbdev_generic_client_restore+0x2c/0x40
Re: Re: [RFC PATCH 2/3] drm/tidss: Add support for display sharing
Hi Devarsh, On Thu, Feb 08, 2024 at 06:26:17PM +0530, Devarsh Thakkar wrote: > Hi Maxime, > > Thanks a lot for checking on this. > > On 26/01/24 17:45, Maxime Ripard wrote: > > Hi, > > > > Thanks a lot for working on that. > > > > On Tue, Jan 16, 2024 at 07:11:41PM +0530, Devarsh Thakkar wrote: > >> Display subsystem present in TI Keystone family of devices supports sharing > >> of display between multiple hosts as it provides separate register space > >> (common* region) for each host to programming display controller and also a > >> unique interrupt line for each host. > >> > >> This adds support for display sharing, by allowing partitioning of > >> resources either at video port level or at video plane level as > >> described below : > >> > >> 1) Linux can own (i.e have write access) completely one or more of video > >> ports along with corresponding resources (viz. overlay managers, > >> video planes) used by Linux in context of those video ports. > >> Even if Linux is owning > >> these video ports it can still share this video port with a remote core > >> which can own one or more video planes associated with this video port. > >> > >> 2) Linux owns one or more of the video planes with video port > >> (along with corresponding overlay manager) associated with these planes > >> being owned and controlled by a remote core. Linux still has read-only > >> access to the associated video port and overlay managers so that it can > >> parse the settings made by remote core. > > > > So, just to make sure we're on the same page. 1) means Linux drives the > > whole display engine, but can lend planes to the R5? How does that work, > > is Linux aware of the workload being there (plane size, format, etc) ? > > > > Well, there is no dynamic procedure being followed for lending. The > partitioning scheme is decided and known before hand, and the remote > core firmware updated and compiled accordingly, and similarly the > device-tree overlay for Linux is also updated with partitioning > information before bootup. > > What would happen here is that Linux will know before-hand this > partitioning information via device-tree properties and won't enumerate > the plane owned by RTOS, but it will enumerate the rest of the display > components and initialize the DSS, after which user can load the DSS > firmware on remote core and this firmware will only have control of > plane as it was compiled with that configuration. Right. If the RTOS is in control of a single plane, how it is expected to deal with Linux shutting the CRTC down, or enforcing a configuration that isn't compatible with what the RTOS expects (like a plane with a higher zpos masking its plane), what is the mechanism to reconcile it? > > And 2) would mean that the display engine is under the R5 control and > > Linux only gets to fill the plane and let the firmware know of what it > > wants? > > > > Here too the partitioning information is pre-decided and remote core > firmware and device-tree overlay for Linux updated accordingly. But in > this case as remote core firmware owns the display (minus the plane > owned by Linux) it is started and initialized during the bootloader > phase itself where it initializes the DSS and starts rendering using the > plane owned by it and Linux just latches to the DSS without > re-initializing it, with write access only to the plane that is owned by > Linux. You can refer [1] for more details on this. > > > If so, do we even need the tidss driver in the second case? We could > > just write a fwkms driver of some sorts that could be used by multiple > > implementations of the same "defer to firmware" logic. > > > > This feature of static partitioning of DSS resources is specific to DSS7 > hardware (which is controlled by tidss driver) which supports dedicated > register space and interrupt line for each of the hosts [0], so that > multiple hosts can drive the display controller simultaneously as per > the desired static partitioning of resources, and so I don't think a > separate driver is required here and tidss seems the right place to > support this, where using this device-tree approach different resource > partitioning schemas can be achieved as described here [1]. This was > also aligned with Tomi too where we discussed that tidss is the right > place to support this as we are simply leveraging the DSS hardware > capabilities of static partitioning here. If the only thing tidss does in the "owned by RTOS" is forwarding KMS atomic states to the RTOS, then I'm still not sure why we need to involve tidss at all. It's not just about interrupts, it's also about how your arbitrate between what Linux wants and what the RTOS wants. Like if the RTOS still wants to output something but Linux wants to disable it, how do you reconcile the two? You have to have something that reconciles both, and typically for firmware-based setup this will be the firmware's job. That's very similar to what the RaspberryPi did
Re: [PATCH] drm/crtc: fix uninitialized variable use even harder
On Mon, Feb 12, 2024 at 01:55:34PM -0800, Rob Clark wrote:
> From: Rob Clark
>
> DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
> which means we can't rely too much on variable initializers.
>
> Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable use")
> Signed-off-by: Rob Clark
Cc: sta...@vger.kernel.org
I guess at least ...
> ---
> I have mixed feelings about DRM_MODESET_LOCK_ALL_BEGIN() (and friends)
> magic. On one hand it simplifies the deadlock/back dance. OTOH it
> conceals a nasty sharp edge. Maybe it is better to have the complicated
> restart path a bit more explicit, like it was originally.
Alternative would be a very magic for {} macro, but those tend to get
easily defeated with goto/break and friends. Maybe it works now that
linux/cleanup.h has landed, but I'm not sure it's actually better and not
just trading one set of sharp edges for another. Worth a shot in a
prototype at least, if someone's bored.
>
> drivers/gpu/drm/drm_crtc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index cb90e70d85e8..65f9f66933bb 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -904,6 +904,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> connector_set = NULL;
> fb = NULL;
> mode = NULL;
> + num_connectors = 0;
I think it'd be neater to have all these right below the
DRM_MODESET_LOCK_A_BEGIN instead of duplicated here and at the beginning
of the function. But it's a bit a bikeshed and in some cases (when you use
it later on) gcc might get pissed too. So either way:
Reviewed-by: Daniel Vetter
Cheers, Sima
>
> DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
>
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 2/2] drm/tests/drm_buddy: add alloc_contiguous test
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Reviewed-by: Arunpravin Paneer Selvam
Cc: Arunpravin Paneer Selvam
Cc: Limonciello
Cc: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/tests/drm_buddy_test.c | 89 ++
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index ea2af6bd9abe..fee6bec757d1 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
@@ -18,6 +19,93 @@ static inline u64 get_size(int order, u64 chunk_size)
return (1 << order) * chunk_size;
}
+static void drm_test_buddy_alloc_contiguous(struct kunit *test)
+{
+ u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ struct drm_buddy_block *block;
+ struct drm_buddy mm;
+ LIST_HEAD(left);
+ LIST_HEAD(middle);
+ LIST_HEAD(right);
+ LIST_HEAD(allocated);
+
+ mm_size = 16 * 3 * SZ_4K;
+
+ KUNIT_EXPECT_FALSE(test, drm_buddy_init(, mm_size, ps));
+
+ /*
+* Idea is to fragment the address space by alternating block
+* allocations between three different lists; one for left, middle and
+* right. We can then free a list to simulate fragmentation. In
+* particular we want to exercise the DRM_BUDDY_CONTIGUOUS_ALLOCATION,
+* including the try_harder path.
+*/
+
+ i = 0;
+ n_pages = mm_size / ps;
+ do {
+ struct list_head *list;
+ int slot = i % 3;
+
+ if (slot == 0)
+ list =
+ else if (slot == 1)
+ list =
+ else
+ list =
+ KUNIT_ASSERT_FALSE_MSG(test,
+ drm_buddy_alloc_blocks(, 0, mm_size,
+ ps, ps, list, 0),
+ "buddy_alloc hit an error size=%d\n",
+ ps);
+ } while (++i < n_pages);
+
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%d\n", 3 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ /*
+* At this point we should have enough contiguous space for 2 blocks,
+* however they are never buddies (since we freed middle and right) so
+* will require the try_harder logic to find them.
+*/
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 2 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 2 * ps);
+
+ drm_buddy_free_list(, );
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
+ 3 * ps, ps,
,
+
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
+ "buddy_alloc hit an error size=%d\n", 3 * ps);
+
+ total = 0;
+ list_for_each_entry(block, , link)
+ total += drm_buddy_block_size(, block);
+
+ KUNIT_ASSERT_EQ(test, total, ps * 2 + ps * 3);
+
+ drm_buddy_free_list(, );
+ drm_buddy_fini();
+}
+
static void drm_test_buddy_alloc_pathological(struct kunit *test)
{
u64 mm_size, size, start = 0;
@@ -280,6 +368,7 @@ static struct kunit_case drm_buddy_tests[] = {
KUNIT_CASE(drm_test_buddy_alloc_optimistic),
[PATCH 1/2] drm/buddy: Fix alloc_range() error handling code
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if the total allocated size
is less than the required size, the function should
return -ENOSPC.
Cc: # 6.7+
Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Tested-by: Mario Limonciello
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
Acked-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..c1a99bf4dffd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm,
} while (1);
list_splice_tail(, blocks);
+
+ if (total_allocated < size) {
+ err = -ENOSPC;
+ goto err_free;
+ }
+
return 0;
err_undo:
base-commit: 2c80a2b715df75881359d07dbaacff8ad411f40e
--
2.25.1
Re: [PATCH] drm/crtc: fix uninitialized variable use even harder
On Mon, 12 Feb 2024 at 23:55, Rob Clark wrote:
>
> From: Rob Clark
>
> DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
> which means we can't rely too much on variable initializers.
>
> Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable use")
> Signed-off-by: Rob Clark
> ---
> I have mixed feelings about DRM_MODESET_LOCK_ALL_BEGIN() (and friends)
> magic. On one hand it simplifies the deadlock/back dance. OTOH it
> conceals a nasty sharp edge. Maybe it is better to have the complicated
> restart path a bit more explicit, like it was originally.
>
> drivers/gpu/drm/drm_crtc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index cb90e70d85e8..65f9f66933bb 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -904,6 +904,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> connector_set = NULL;
> fb = NULL;
> mode = NULL;
> + num_connectors = 0;
Nit: I think we should move all this next to the
DRM_MODESET_LOCK_ALL_BEGIN() and drop initialisation from the prologue
of the function, but it's definitely a separate and more intrusive
story.
Reviewed-by: Dmitry Baryshkov
> DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
--
With best wishes
Dmitry
[PATCH] drm/xe: skip building debugfs code for CONFIG_DEBUG_FS=n
From: Arnd Bergmann
Some of the debugfs functions are stubbed out in these configurations,
so trying to build the .c file with the definition fails:
In file included from include/uapi/linux/posix_types.h:5,
from drivers/gpu/drm/i915/display/intel_pipe_crc.c:27:
drivers/gpu/drm/i915/display/intel_pipe_crc.c: At top level:
include/linux/stddef.h:8:16: error: expected identifier or '(' before 'void'
8 | #define NULL ((void *)0)
|^~~~
drivers/gpu/drm/i915/display/intel_pipe_crc.c:549:20: note: in expansion of
macro 'intel_crtc_get_crc_sources'
549 | const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
|^~
Stop trying to build them by making the Makefile entries conditional,
same as for the i915 driver.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/xe/Makefile | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index efcf0ab7a1a6..7c10ffdb7809 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -213,8 +213,6 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
i915-display/intel_ddi.o \
i915-display/intel_ddi_buf_trans.o \
i915-display/intel_display.o \
- i915-display/intel_display_debugfs.o \
- i915-display/intel_display_debugfs_params.o \
i915-display/intel_display_device.o \
i915-display/intel_display_driver.o \
i915-display/intel_display_irq.o \
@@ -258,7 +256,6 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
i915-display/intel_modeset_setup.o \
i915-display/intel_modeset_verify.o \
i915-display/intel_panel.o \
- i915-display/intel_pipe_crc.o \
i915-display/intel_pmdemand.o \
i915-display/intel_pps.o \
i915-display/intel_psr.o \
@@ -275,6 +272,13 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
i915-display/skl_universal_plane.o \
i915-display/skl_watermark.o
+ifdef CONFIG_DEBUG_FS
+xe-$(CONFIG_DRM_XE_DISPLAY) += \
+ i915-display/intel_display_debugfs.o \
+ i915-display/intel_display_debugfs_params.o \
+ i915-display/intel_pipe_crc.o
+endif
+
ifeq ($(CONFIG_ACPI),y)
xe-$(CONFIG_DRM_XE_DISPLAY) += \
i915-display/intel_acpi.o \
--
2.39.2
RE: [PATCH v2 1/6] drm/mst: read sideband messaging cap
On Tue, 13 Feb 2024, "Murthy, Arun R" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Tuesday, February 13, 2024 5:01 PM
>> To: intel-...@lists.freedesktop.org
>> Cc: dri-devel@lists.freedesktop.org; intel...@lists.freedesktop.org; Nikula,
>> Jani
>> ; Murthy, Arun R ; Ville
>> Syrjälä
>> Subject: [PATCH v2 1/6] drm/mst: read sideband messaging cap
>>
>> Amend drm_dp_read_mst_cap() to return an enum, indicating "SST", "SST with
>> sideband messaging", or "MST". Modify all call sites to take the new return
>> value into account.
>>
>> v2:
>> - Rename enumerators (Ville)
>>
>> Cc: Arun R Murthy
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 ++--
>> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
>> drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +-
>> include/drm/display/drm_dp_mst_helper.h | 23 ++-
>> 4 files changed, 38 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> index 03d528209426..c193be3577f7 100644
>> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> @@ -3608,24 +3608,30 @@ fixed20_12 drm_dp_get_vc_payload_bw(const
>> struct drm_dp_mst_topology_mgr *mgr,
>> EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
>>
>> /**
>> - * drm_dp_read_mst_cap() - check whether or not a sink supports MST
>> + * drm_dp_read_mst_cap() - Read the sink's MST mode capability
>> * @aux: The DP AUX channel to use
>> * @dpcd: A cached copy of the DPCD capabilities for this sink
>> *
>> - * Returns: %True if the sink supports MST, %false otherwise
>> + * Returns: enum drm_dp_mst_mode to indicate MST mode capability
>> */
>> -bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
>> - const u8 dpcd[DP_RECEIVER_CAP_SIZE])
>> +enum drm_dp_mst_mode drm_dp_read_mst_cap(struct drm_dp_aux *aux,
>> + const u8
>> dpcd[DP_RECEIVER_CAP_SIZE])
>> {
>> u8 mstm_cap;
>>
>> if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
>> - return false;
>> + return DRM_DP_SST;
>>
>> if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, _cap) != 1)
>> - return false;
>> + return DRM_DP_SST;
>> +
>> + if (mstm_cap & DP_MST_CAP)
>> + return DRM_DP_MST;
>> +
>> + if (mstm_cap & DP_SINGLE_STREAM_SIDEBAND_MSG)
>> + return DRM_DP_SST_SIDEBAND_MSG;
> Bit[1] of MSTM_CAP indicates sideband messaging is supported or not
> and nothing to do with MST/SST. So would it make more sense to have it
> as DRM_DP_SIDEBAND_MSG?
Bit 1 is literally described as SINGLE_STREAM_SIDEBAND_MSG_SUPPORT in
the spec, "Supports Sideband MSG while not supporting multi-stream
transport".
Bit 1 is also only valid when bit 0 says, "Does not support MST mode".
BR,
Jani.
>
> Thanks and Regards,
> Arun R Murthy
>
>>
>> - return mstm_cap & DP_MST_CAP;
>> + return DRM_DP_SST;
>> }
>> EXPORT_SYMBOL(drm_dp_read_mst_cap);
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index 5045c34a16be..a1c304f451bd 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -4014,7 +4014,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
>>
>> return i915->display.params.enable_dp_mst &&
>> intel_dp_mst_source_support(intel_dp) &&
>> - drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
>> + drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
>> DRM_DP_MST;
>> }
>>
>> static void
>> @@ -4023,7 +4023,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
>> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> struct intel_encoder *encoder =
>> _to_dig_port(intel_dp)->base;
>> - bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp-
>> >dpcd);
>> + bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux,
>> +intel_dp->dpcd) == DRM_DP_MST;
>>
>> drm_dbg_kms(>drm,
>> "[ENCODER:%d:%s] MST support: port: %s, sink: %s,
>> modparam: %s\n", diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
>> b/drivers/gpu/drm/nouveau/nouveau_dp.c
>> index 7de7707ec6a8..fb06ee17d9e5 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
>> @@ -181,7 +181,7 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
>> *nv_connector,
>> if (nouveau_mst) {
>> mstm = outp->dp.mstm;
>> if (mstm)
>> - mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
>> + mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd)
>> == DRM_DP_MST;
>> }
>>
>> if (nouveau_dp_has_sink_count(connector, outp)) { diff --git
>> a/include/drm/display/drm_dp_mst_helper.h
>>
Re: [PATCH 02/10] auxdisplay/ht16k33: Remove struct backlight_ops.check_fb
On Mon, 12 Feb 2024 17:16:35 +0100
Thomas Zimmermann wrote:
> The driver sets struct fb_info.bl_dev to the correct backlight
> device. Thus rely on the backlight core code to match backlight
> and framebuffer devices, and remove the extra check_fb function
> from struct backlight_ops.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Robin van der Gracht
> ---
> drivers/auxdisplay/ht16k33.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
> index a90430b7d07ba..0a858db32486b 100644
> --- a/drivers/auxdisplay/ht16k33.c
> +++ b/drivers/auxdisplay/ht16k33.c
> @@ -325,16 +325,8 @@ static int ht16k33_bl_update_status(struct
> backlight_device *bl)
> return ht16k33_brightness_set(priv, brightness);
> }
>
> -static int ht16k33_bl_check_fb(struct backlight_device *bl, struct fb_info
> *fi)
> -{
> - struct ht16k33_priv *priv = bl_get_data(bl);
> -
> - return (fi == NULL) || (fi->par == priv);
> -}
> -
> static const struct backlight_ops ht16k33_bl_ops = {
> .update_status = ht16k33_bl_update_status,
> - .check_fb = ht16k33_bl_check_fb,
> };
When combined with the previous patch:
[01/10] backlight: Match backlight device against struct fb_info.bl_dev
(I wasn't in the CC)
Acked-By: Robin van der Gracht
Re: [RFC PATCH net-next v5 08/14] memory-provider: dmabuf devmem memory provider
On 12/18/23 02:40, Mina Almasry wrote:
Implement a memory provider that allocates dmabuf devmem in the form of
net_iov.
The provider receives a reference to the struct netdev_dmabuf_binding
via the pool->mp_priv pointer. The driver needs to set this pointer for
the provider in the net_iov.
The provider obtains a reference on the netdev_dmabuf_binding which
guarantees the binding and the underlying mapping remains alive until
the provider is destroyed.
Usage of PP_FLAG_DMA_MAP is required for this memory provide such that
the page_pool can provide the driver with the dma-addrs of the devmem.
Support for PP_FLAG_DMA_SYNC_DEV is omitted for simplicity & p.order !=
0.
Signed-off-by: Willem de Bruijn
Signed-off-by: Kaiyuan Zhang
Signed-off-by: Mina Almasry
---
...
+
+static bool mp_dmabuf_devmem_release_page(struct page_pool *pool,
+ struct netmem *netmem)
+{
+ WARN_ON_ONCE(!netmem_is_net_iov(netmem));
+
+ page_pool_clear_pp_info(netmem);
+
+ netdev_free_dmabuf(netmem_to_net_iov(netmem));
+
+ /* We don't want the page pool put_page()ing our net_iovs. */
+ return false;
+}
+
+const struct memory_provider_ops dmabuf_devmem_ops = {
+ .init = mp_dmabuf_devmem_init,
+ .destroy= mp_dmabuf_devmem_destroy,
+ .alloc_pages= mp_dmabuf_devmem_alloc_pages,
+ .release_page = mp_dmabuf_devmem_release_page,
+};
+EXPORT_SYMBOL(dmabuf_devmem_ops);
It might make sense to move all these functions together with
new code from core/dev.c into a new file
--
Pavel Begunkov
Re: [RFC PATCH net-next v5 07/14] page_pool: devmem support
On 12/18/23 02:40, Mina Almasry wrote:
Convert netmem to be a union of struct page and struct netmem. Overload
the LSB of struct netmem* to indicate that it's a net_iov, otherwise
it's a page.
Currently these entries in struct page are rented by the page_pool and
used exclusively by the net stack:
struct {
unsigned long pp_magic;
struct page_pool *pp;
unsigned long _pp_mapping_pad;
unsigned long dma_addr;
atomic_long_t pp_ref_count;
};
Mirror these (and only these) entries into struct net_iov and implement
netmem helpers that can access these common fields regardless of
whether the underlying type is page or net_iov.
Implement checks for net_iov in netmem helpers which delegate to mm
APIs, to ensure net_iov are never passed to the mm stack.
Signed-off-by: Mina Almasry
---
RFCv5:
- Use netmem instead of page* with LSB set.
- Use pp_ref_count for refcounting net_iov.
- Removed many of the custom checks for netmem.
v1:
- Disable fragmentation support for iov properly.
- fix napi_pp_put_page() path (Yunsheng).
- Use pp_frag_count for devmem refcounting.
---
include/net/netmem.h| 145 ++--
include/net/page_pool/helpers.h | 25 +++---
net/core/page_pool.c| 26 +++---
net/core/skbuff.c | 9 +-
4 files changed, 164 insertions(+), 41 deletions(-)
diff --git a/include/net/netmem.h b/include/net/netmem.h
index 31f338f19da0..7557aecc0f78 100644
--- a/include/net/netmem.h
+++ b/include/net/netmem.h
@@ -12,11 +12,47 @@
/* net_iov */
+DECLARE_STATIC_KEY_FALSE(page_pool_mem_providers);
+
+/* We overload the LSB of the struct page pointer to indicate whether it's
+ * a page or net_iov.
+ */
+#define NET_IOV 0x01UL
+
struct net_iov {
+ unsigned long __unused_padding;
+ unsigned long pp_magic;
+ struct page_pool *pp;
struct dmabuf_genpool_chunk_owner *owner;
unsigned long dma_addr;
+ atomic_long_t pp_ref_count;
};
I wonder if it would be better to extract a common sub-struct
used in struct page, struct_group_tagged can help to avoid
touching old code:
struct page {
unsigned long flags;
union {
...
struct_group_tagged(, ...,
/**
* @pp_magic: magic value to avoid recycling non
* page_pool allocated pages.
*/
unsigned long pp_magic;
struct page_pool *pp;
unsigned long _pp_mapping_pad;
unsigned long dma_addr;
atomic_long_t pp_ref_count;
);
};
}
struct net_iov {
unsigned long pad;
struct p;
};
A bit of a churn with the padding and nesting net_iov but looks
sturdier. No duplication, and you can just check positions of the
structure instead of per-field NET_IOV_ASSERT_OFFSET, which you
have to not forget to update e.g. when adding a new field. Also,
with the change __netmem_clear_lsb can return a pointer to that
structure, casting struct net_iov when it's a page is a bit iffy.
And the next question would be whether it'd be a good idea to encode
iov vs page not by setting a bit but via one of the fields in the
structure, maybe pp_magic.
With that said I'm a bit concerned about the net_iov size. If each
represents 4096 bytes and you're registering 10MB, then you need
30 pages worth of memory just for the iov array. Makes kvmalloc
a must even for relatively small sizes.
And the final bit, I don't believe the overlay is necessary in
this series. Optimisations are great, but this one is a bit more on
the controversial side. Unless I missed something and it does make
things easier, it might make sense to do it separately later.
+/* These fields in struct page are used by the page_pool and net stack:
+ *
+ * struct {
+ * unsigned long pp_magic;
+ * struct page_pool *pp;
+ * unsigned long _pp_mapping_pad;
+ * unsigned long dma_addr;
+ * atomic_long_t pp_ref_count;
+ * };
+ *
+ * We mirror the page_pool fields here so the page_pool can access these fields
+ * without worrying whether the underlying fields belong to a page or net_iov.
+ *
+ * The non-net stack fields of struct page are private to the mm stack and must
+ * never be mirrored to net_iov.
+ */
+#define NET_IOV_ASSERT_OFFSET(pg, iov) \
+ static_assert(offsetof(struct page, pg) == \
+ offsetof(struct net_iov, iov))
+NET_IOV_ASSERT_OFFSET(pp_magic, pp_magic);
+NET_IOV_ASSERT_OFFSET(pp, pp);
+NET_IOV_ASSERT_OFFSET(dma_addr, dma_addr);
+NET_IOV_ASSERT_OFFSET(pp_ref_count, pp_ref_count);
+#undef NET_IOV_ASSERT_OFFSET
+
static inline struct dmabuf_genpool_chunk_owner *
net_iov_owner(const struct net_iov *niov)
{
@@ -47,19 +83,25 @@ net_iov_binding(const struct net_iov *niov)
Re: [RFC PATCH net-next v5 05/14] netdev: netdevice devmem allocator
On 12/18/23 02:40, Mina Almasry wrote:
Implement netdev devmem allocator. The allocator takes a given struct
netdev_dmabuf_binding as input and allocates net_iov from that
binding.
The allocation simply delegates to the binding's genpool for the
allocation logic and wraps the returned memory region in a net_iov
struct.
Signed-off-by: Willem de Bruijn
Signed-off-by: Kaiyuan Zhang
Signed-off-by: Mina Almasry
---
v1:
- Rename devmem -> dmabuf (David).
---
include/net/devmem.h | 12
include/net/netmem.h | 26 ++
net/core/dev.c | 38 ++
3 files changed, 76 insertions(+)
...
diff --git a/include/net/netmem.h b/include/net/netmem.h
index 45eb42d9990b..7fce2efc8707 100644
--- a/include/net/netmem.h
+++ b/include/net/netmem.h
@@ -14,8 +14,34 @@
struct net_iov {
struct dmabuf_genpool_chunk_owner *owner;
+ unsigned long dma_addr;
};
+static inline struct dmabuf_genpool_chunk_owner *
+net_iov_owner(const struct net_iov *niov)
+{
+ return niov->owner;
+}
+
+static inline unsigned int net_iov_idx(const struct net_iov *niov)
+{
+ return niov - net_iov_owner(niov)->niovs;
+}
+
+static inline dma_addr_t net_iov_dma_addr(const struct net_iov *niov)
+{
+ struct dmabuf_genpool_chunk_owner *owner = net_iov_owner(niov);
+
+ return owner->base_dma_addr +
+ ((dma_addr_t)net_iov_idx(niov) << PAGE_SHIFT);
Looks like it should have been niov->dma_addr
+}
+
+static inline struct netdev_dmabuf_binding *
+net_iov_binding(const struct net_iov *niov)
+{
+ return net_iov_owner(niov)->binding;
+}
+
/* netmem */
struct netmem {
...
--
Pavel Begunkov
[RFC] drm/i915: Support replaying GPU hangs with captured context image
From: Tvrtko Ursulin
When debugging GPU hangs Mesa developers are finding it useful to replay
the captured error state against the simulator. But due various simulator
limitations which prevent replicating all hangs, one step further is being
able to replay against a real GPU.
This is almost doable today with the missing part being able to upload the
captured context image into the driver state prior to executing the
uploaded hanging batch and all the buffers.
To enable this last part we add a new context parameter called
I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU
configuration pattern of being able to select which context to apply
against, paired with the actual image and its size.
Since this is adding a new concept of debug only uapi, we hide it behind
a new kconfig option and also require activation with a module parameter.
Together with a warning banner printed at driver load, all those combined
should be sufficient to guard against inadvertently enabling the feature.
In terms of implementation the only trivial change is shadowing of the
default state from engine to context. We also allow the legacy context
set param to be used since that removes the need to record the per context
data in the proto context, while still allowing flexibility of specifying
context images for any context.
Mesa MR using the uapi can be seen at:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Cc: Carlos Santa
---
drivers/gpu/drm/i915/Kconfig.debug| 17 +++
drivers/gpu/drm/i915/gem/i915_gem_context.c | 106 ++
drivers/gpu/drm/i915/gt/intel_context.c | 2 +
drivers/gpu/drm/i915/gt/intel_context.h | 22
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 8 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 8 +-
drivers/gpu/drm/i915/i915_params.c| 5 +
drivers/gpu/drm/i915/i915_params.h| 3 +-
include/uapi/drm/i915_drm.h | 27 +
10 files changed, 194 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 5b7162076850..32e9f70e91ed 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -16,6 +16,23 @@ config DRM_I915_WERROR
If in doubt, say "N".
+config DRM_I915_REPLAY_GPU_HANGS_API
+ bool "Enable GPU hang replay userspace API"
+ depends on DRM_I915
+ depends on EXPERT
+ default n
+ help
+ Choose this option if you want to enable special and unstable
+ userspace API used for replaying GPU hangs on a running system.
+
+ This API is intended to be used by userspace graphics stack developers
+ and provides no stability guarantees.
+
+ The API needs to be activated at boot time using the
+ enable_debug_only_api module parameter.
+
+ If in doubt, say "N".
+
config DRM_I915_DEBUG
bool "Enable additional driver debugging"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dcbfe32fd30c..1cfd624bd978 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -78,6 +78,7 @@
#include "gt/intel_engine_user.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_ring.h"
+#include "gt/shmem_utils.h"
#include "pxp/intel_pxp.h"
@@ -949,6 +950,7 @@ static int set_proto_ctx_param(struct drm_i915_file_private
*fpriv,
case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
case I915_CONTEXT_PARAM_RINGSIZE:
+ case I915_CONTEXT_PARAM_CONTEXT_IMAGE:
default:
ret = -EINVAL;
break;
@@ -2092,6 +2094,88 @@ static int get_protected(struct i915_gem_context *ctx,
return 0;
}
+static int set_context_image(struct i915_gem_context *ctx,
+struct drm_i915_gem_context_param *args)
+{
+ struct i915_gem_context_param_context_image user;
+ struct intel_context *ce;
+ struct file *shmem_state;
+ unsigned long lookup;
+ void *state;
+ int ret = 0;
+
+ if (!IS_ENABLED(CONFIG_DRM_I915_REPLAY_GPU_HANGS_API))
+ return -EINVAL;
+
+ if (!ctx->i915->params.enable_debug_only_api)
+ return -EINVAL;
+
+ if (args->size < sizeof(user))
+ return -EINVAL;
+
+ if (copy_from_user(, u64_to_user_ptr(args->value), sizeof(user)))
+ return -EFAULT;
+
+ if (user.mbz)
+ return -EINVAL;
+
+ if (user.flags & ~(I915_CONTEXT_IMAGE_FLAG_ENGINE_INDEX))
+ return -EINVAL;
+
+ lookup = 0;
+ if (user.flags & I915_CONTEXT_IMAGE_FLAG_ENGINE_INDEX)
+ lookup |= LOOKUP_USER_INDEX;
+
+ ce
RE: [PATCH v2 1/6] drm/mst: read sideband messaging cap
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, February 13, 2024 5:01 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; intel...@lists.freedesktop.org; Nikula,
> Jani
> ; Murthy, Arun R ; Ville
> Syrjälä
> Subject: [PATCH v2 1/6] drm/mst: read sideband messaging cap
>
> Amend drm_dp_read_mst_cap() to return an enum, indicating "SST", "SST with
> sideband messaging", or "MST". Modify all call sites to take the new return
> value into account.
>
> v2:
> - Rename enumerators (Ville)
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 ++--
> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +-
> include/drm/display/drm_dp_mst_helper.h | 23 ++-
> 4 files changed, 38 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 03d528209426..c193be3577f7 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3608,24 +3608,30 @@ fixed20_12 drm_dp_get_vc_payload_bw(const
> struct drm_dp_mst_topology_mgr *mgr,
> EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
>
> /**
> - * drm_dp_read_mst_cap() - check whether or not a sink supports MST
> + * drm_dp_read_mst_cap() - Read the sink's MST mode capability
> * @aux: The DP AUX channel to use
> * @dpcd: A cached copy of the DPCD capabilities for this sink
> *
> - * Returns: %True if the sink supports MST, %false otherwise
> + * Returns: enum drm_dp_mst_mode to indicate MST mode capability
> */
> -bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> - const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +enum drm_dp_mst_mode drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> + const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> {
> u8 mstm_cap;
>
> if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> - return false;
> + return DRM_DP_SST;
>
> if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, _cap) != 1)
> - return false;
> + return DRM_DP_SST;
> +
> + if (mstm_cap & DP_MST_CAP)
> + return DRM_DP_MST;
> +
> + if (mstm_cap & DP_SINGLE_STREAM_SIDEBAND_MSG)
> + return DRM_DP_SST_SIDEBAND_MSG;
Bit[1] of MSTM_CAP indicates sideband messaging is supported or not and nothing
to do with MST/SST. So would it make more sense to have it as
DRM_DP_SIDEBAND_MSG?
Thanks and Regards,
Arun R Murthy
>
> - return mstm_cap & DP_MST_CAP;
> + return DRM_DP_SST;
> }
> EXPORT_SYMBOL(drm_dp_read_mst_cap);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 5045c34a16be..a1c304f451bd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4014,7 +4014,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
>
> return i915->display.params.enable_dp_mst &&
> intel_dp_mst_source_support(intel_dp) &&
> - drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
> + drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd) ==
> DRM_DP_MST;
> }
>
> static void
> @@ -4023,7 +4023,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_encoder *encoder =
> _to_dig_port(intel_dp)->base;
> - bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp-
> >dpcd);
> + bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux,
> +intel_dp->dpcd) == DRM_DP_MST;
>
> drm_dbg_kms(>drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s,
> modparam: %s\n", diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 7de7707ec6a8..fb06ee17d9e5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -181,7 +181,7 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
> *nv_connector,
> if (nouveau_mst) {
> mstm = outp->dp.mstm;
> if (mstm)
> - mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
> + mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd)
> == DRM_DP_MST;
> }
>
> if (nouveau_dp_has_sink_count(connector, outp)) { diff --git
> a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index 9b19d8bd520a..3c9e128c444a 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -818,7 +818,28 @@ int drm_dp_mst_topology_mgr_init(struct
> drm_dp_mst_topology_mgr *mgr,
>
> void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr
> *mgr);
>
> -bool drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
Re: [PATCH 09/28] drm: Add Color ops capability property
On Tue, Feb 13, 2024 at 12:18:16PM +0530, Uma Shankar wrote:
> Add capability property which a colorop can expose it's
> hardware's abilities. It's a blob property that can be
> filled with respective data structures depending on the
> colorop. The user space is expected to read this property
> and program the colorop accordingly.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Chaitanya Kumar Borah
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> include/drm/drm_colorop.h | 13 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 9f6a3a1c8020..95f1df73209c 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -770,6 +770,9 @@ drm_atomic_colorop_get_property(struct drm_colorop
> *colorop,
> *val = state->curve_1d_type;
> } else if (property == colorop->data_property) {
> *val = (state->data) ? state->data->base.id : 0;
> + } else if (property == colorop->hw_caps_property) {
> + *val = state->hw_caps ?
> + state->hw_caps->base.id : 0;
> } else {
> return -EINVAL;
> }
> diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> index 5b8c36538491..f417e109c40a 100644
> --- a/include/drm/drm_colorop.h
> +++ b/include/drm/drm_colorop.h
> @@ -59,6 +59,12 @@ struct drm_colorop_state {
>*/
> enum drm_colorop_curve_1d_type curve_1d_type;
>
> + /**
> + * @hw_caps:
> + *
> + */
> + struct drm_property_blob *hw_caps;
> +
Is this supposed to be generic for any colorop or specifically for
DRM_COLOROP_1D_LUT?
> /**
>* @data:
>*
> @@ -167,6 +173,13 @@ struct drm_colorop {
>*/
> struct drm_property *bypass_property;
>
> + /**
> + * @hwlut_caps_property:
> + *
> + * Property to expose hardware lut capbilities.
> + */
> + struct drm_property *hw_caps_property;
> +
> /**
>* @curve_1d_type:
>*
> --
> 2.42.0
>
Re: [PATCH 08/28] drm: Add Color lut range attributes
On Tue, Feb 13, 2024 at 12:18:15PM +0530, Uma Shankar wrote:
> This defines a new structure to define color lut ranges,
> along with related macro definitions and enums. This will help
> describe segmented lut ranges/PWL LUTs in the hardware.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Chaitanya Kumar Borah
> ---
> include/uapi/drm/drm_mode.h | 58 +
> 1 file changed, 58 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index af67f32e0087..376498715d0e 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -1014,6 +1014,64 @@ struct hdr_output_metadata {
> DRM_MODE_PAGE_FLIP_ASYNC | \
> DRM_MODE_PAGE_FLIP_TARGET)
>
All of this uses DRM_MODE_LUT namespace but it seems specifically for
the drm colorop of type DRM_COLOROP_1D_LUT. Let's be consistent with the
naming.
> +/**
> + * DRM_MODE_LUT_INTERPOLATE
> + *
> + * linearly interpolate between the points
> + */
> +#define DRM_MODE_LUT_INTERPOLATE BIT(0)
> +
> +/**
> + * DRM_MODE_LUT_REUSE_LAST
> + *
> + * the last value of the previous range is the
> + * first value of the current range.
> + */
> +#define DRM_MODE_LUT_REUSE_LAST BIT(1)
> +
> +/**
> + * DRM_MODE_LUT_NON_DECREASING
> + *
> + * the curve must be non-decreasing
> + */
> +#define DRM_MODE_LUT_NON_DECREASING BIT(2)
> +
> +/**
> + * DRM_MODE_LUT_REFLECT_NEGATIVE
> + *
> + * the curve is reflected across origin for negative inputs
> + */
> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(3)
> +
> +/**
> + * DRM_MODE_LUT_SINGLE_CHANNEL
> + *
> + * the same curve (red) is used for blue and green channels as well
> + */
> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(4)
> +
> +/**
> + * struct drm_color_lut_range
> + *
> + * structure to advertise capability of a color hardware
> + * block that accepts LUT values. It can represent LUTs with
> + * varied number of entries and distributions
> + * (Multi segmented, Logarithmic etc).
> + */
> +
> +struct drm_color_lut_range {
> + /* DRM_MODE_LUT_* */
> + __u32 flags;
> + /* number of points on the curve */
> + __u16 count;
> + /* input/output bits per component */
> + __u8 input_bpc, output_bpc;
> + /* input start/end values */
> + __s32 start, end;
> + /* output min/max values */
> + __s32 min, max;
> +};
> +
> /*
> * Request a page flip on the specified crtc.
> *
> --
> 2.42.0
>
Re: [PATCH 6/7] dt-bindings: arm: rockchip: Add Powkiddy RGB10MAX3
On 12/02/2024 19:49, Chris Morgan wrote: > From: Chris Morgan > > The Powkiddy RGB10MAX3 is a handheld gaming device made by Powkiddy and > powered by the Rockchip RK3566 SoC. > > Signed-off-by: Chris Morgan > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 3/7] dt-bindings: display: Document ST7703 panel rotation
On 12/02/2024 19:49, Chris Morgan wrote: > From: Chris Morgan > > Document the rotation property for ST7703 based panels. > > Signed-off-by: Chris Morgan > --- Acked-by: Krzysztof Kozlowski (with or without empty line removal) Best regards, Krzysztof
Re: [PATCH 1/7] dt-bindings: display: st7703: Add Powkiddy RGB10MAX3 panel
On 12/02/2024 19:49, Chris Morgan wrote: > From: Chris Morgan > > The RGB10MAX3 panel is a panel specific to the Powkiddy RGB10MAX3 > handheld device that measures 5 inches diagonally with a resolution > of 720x1280. > > Signed-off-by: Chris Morgan Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
drm/msm: DisplayPort regressions in 6.8-rc1
Hi, Since 6.8-rc1 the internal eDP display on the Lenovo ThinkPad X13s does not always show up on boot. The logs indicate problems with the runtime PM and eDP rework that went into 6.8-rc1: [6.006236] Console: switching to colour dummy device 80x25 [6.007542] [drm:dpu_kms_hw_init:1048] dpu hardware revision:0x8000 [6.007872] [drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16 [6.007934] [drm:dp_bridge_init [msm]] *ERROR* failed to attach panel bridge: -16 [6.007983] msm_dpu ae01000.display-controller: [drm:msm_dp_modeset_init [msm]] *ERROR* failed to create dp bridge: -16 [6.008030] [drm:_dpu_kms_initialize_displayport:588] [dpu error]modeset_init failed for DP, rc = -16 [6.008050] [drm:_dpu_kms_setup_displays:681] [dpu error]initialize_DP failed, rc = -16 [6.008068] [drm:dpu_kms_hw_init:1153] [dpu error]modeset init failed: -16 [6.008388] msm_dpu ae01000.display-controller: [drm:msm_drm_kms_init [msm]] *ERROR* kms hw init failed: -16 and this can also manifest itself as a NULL-pointer dereference: [7.339447] Unable to handle kernel NULL pointer dereference at virtual address [7.643705] pc : drm_bridge_attach+0x70/0x1a8 [drm] [7.686415] lr : drm_aux_bridge_attach+0x24/0x38 [aux_bridge] [7.769039] Call trace: [7.771564] drm_bridge_attach+0x70/0x1a8 [drm] [7.776234] drm_aux_bridge_attach+0x24/0x38 [aux_bridge] [7.781782] drm_bridge_attach+0x80/0x1a8 [drm] [7.786454] dp_bridge_init+0xa8/0x15c [msm] [7.790856] msm_dp_modeset_init+0x28/0xc4 [msm] [7.795617] _dpu_kms_drm_obj_init+0x19c/0x680 [msm] [7.800731] dpu_kms_hw_init+0x348/0x4c4 [msm] [7.805306] msm_drm_kms_init+0x84/0x324 [msm] [7.809891] msm_drm_bind+0x1d8/0x3a8 [msm] [7.814196] try_to_bring_up_aggregate_device+0x1f0/0x2f8 [7.819747] __component_add+0xa4/0x18c [7.823703] component_add+0x14/0x20 [7.827389] dp_display_probe+0x47c/0x568 [msm] [7.832052] platform_probe+0x68/0xd8 Users have also reported random crashes at boot since 6.8-rc1, and I've been able to trigger hard crashes twice when testing an external display (USB-C/DP), which may also be related to the DP regressions. I've opened an issue here: https://gitlab.freedesktop.org/drm/msm/-/issues/51 but I also want Thorsten's help to track this so that it gets fixed before 6.8 is released. #regzbot introduced: v6.7..v6.8-rc1 The following series is likely the culprit: https://lore.kernel.org/all/1701472789-25951-1-git-send-email-quic_khs...@quicinc.com/ Johan
