RE: [PATCH v8 06/10] drm/i915/hdcp: Retain hdcp_capable return codes
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, April 3, 2023 12:12 PM
> To: Mark Yacoub ; Jani Nikula
> ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> Tvrtko Ursulin ; David Airlie
> ; Daniel Vetter
> Cc: seanp...@chromium.org; diand...@chromium.org; dri-
> de...@lists.freedesktop.org; freedr...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; Nikula, Jani ; linux-
> ker...@vger.kernel.org
> Subject: RE: [PATCH v8 06/10] drm/i915/hdcp: Retain hdcp_capable return
> codes
>
>
>
> > -Original Message-
> > From: Mark Yacoub
> > Sent: Saturday, April 1, 2023 3:42 AM
> > To: Jani Nikula ; Joonas Lahtinen
> > ; Vivi, Rodrigo
> > ; Tvrtko Ursulin
> > ; David Airlie ;
> > Daniel Vetter
> > Cc: seanp...@chromium.org; Kandpal, Suraj ;
> > diand...@chromium.org; dri-devel@lists.freedesktop.org;
> > freedr...@lists.freedesktop.org; intel-...@lists.freedesktop.org;
> > Nikula, Jani ; Mark Yacoub
> > ; linux- ker...@vger.kernel.org
> > Subject: [PATCH v8 06/10] drm/i915/hdcp: Retain hdcp_capable return
> > codes
> >
> > From: Sean Paul
> >
> > The shim functions return error codes, but they are discarded in
> > intel_hdcp.c. This patch plumbs the return codes through so they are
> > properly handled.
> >
> > Acked-by: Jani Nikula
> > Reviewed-by: Rodrigo Vivi
> > Signed-off-by: Sean Paul
> > Signed-off-by: Mark Yacoub
> >
> > ---
> > Changes in v2:
> > -None
> > Changes in v3:
> > -None
> > Changes in v4:
> > -None
> > Changes in v5:
> > -None
> > Changes in v6:
> > -Rebased
> > Changes in v7:
> > -None
> > Changes in v8:
> > -None
> >
> > .../drm/i915/display/intel_display_debugfs.c | 9 +++-
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 51 ++-
> > drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
> > 3 files changed, 37 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index 7bcd90384a46d..a14b86a07e545 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -494,6 +494,7 @@ static void intel_panel_info(struct seq_file *m,
> > static void intel_hdcp_info(struct seq_file *m,
> > struct intel_connector *intel_connector) {
> > + int ret;
> > bool hdcp_cap, hdcp2_cap;
> >
> > if (!intel_connector->hdcp.shim) {
> > @@ -501,8 +502,12 @@ static void intel_hdcp_info(struct seq_file *m,
> > goto out;
> > }
> >
> > - hdcp_cap = intel_hdcp_capable(intel_connector);
> > - hdcp2_cap = intel_hdcp2_capable(intel_connector);
> > + ret = intel_hdcp_capable(intel_connector, &hdcp_cap);
> > + if (ret)
> > + hdcp_cap = false;
> > + ret = intel_hdcp2_capable(intel_connector, &hdcp2_cap);
> > + if (ret)
> > + hdcp2_cap = false;
> >
> > if (hdcp_cap)
> > seq_puts(m, "HDCP1.4 ");
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 0a20bc41be55d..61a862ae1f286 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -177,50 +177,49 @@ int intel_hdcp_read_valid_bksv(struct
> > intel_digital_port *dig_port, }
> >
> > /* Is HDCP1.4 capable on Platform and Sink */ -bool
> > intel_hdcp_capable(struct intel_connector *connector)
> > +int intel_hdcp_capable(struct intel_connector *connector, bool
> > +*capable)
> > {
> > struct intel_digital_port *dig_port =
> > intel_attached_dig_port(connector);
> > const struct intel_hdcp_shim *shim = connector->hdcp.shim;
> > - bool capable = false;
> > u8 bksv[5];
> >
> > + *capable = false;
> > +
> > if (!shim)
> > - return capable;
> > + return 0;
> >
> > - if (shim->hdcp_capable) {
> > - shim->hdcp_capable(dig_port, &capable);
> > - } else {
> > - if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
> > - capable = true;
> > - }
> > + if (shim->hdcp_capable)
> > + return shim->hdcp_capable(dig_port, capable);
> > +
> > + if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
> > + *capable = true;
> >
> > - return capable;
> > + return 0;
> > }
> >
> > /* Is HDCP2.2 capable on Platform and Sink */ -bool
> > intel_hdcp2_capable(struct intel_connector *connector)
> > +int intel_hdcp2_capable(struct intel_connector *connector, bool
> > +*capable)
> > {
> > struct intel_digital_port *dig_port =
> > intel_attached_dig_port(connector);
> > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > struct intel_hdcp *hdcp = &connector->hdcp;
> > - bool capable = false;
> > +
> > + *capable = false;
> >
> > /* I915 support for HDCP2.2 */
> > if (!hdcp->hdcp2_supported)
> > - return false;
> > + return 0;
> >
> > /* MEI interface is solid */
> >
RE: [PATCH v8 06/10] drm/i915/hdcp: Retain hdcp_capable return codes
> -Original Message-
> From: Mark Yacoub
> Sent: Saturday, April 1, 2023 3:42 AM
> To: Jani Nikula ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> Tvrtko Ursulin ; David Airlie
> ; Daniel Vetter
> Cc: seanp...@chromium.org; Kandpal, Suraj ;
> diand...@chromium.org; dri-devel@lists.freedesktop.org;
> freedr...@lists.freedesktop.org; intel-...@lists.freedesktop.org; Nikula, Jani
> ; Mark Yacoub ; linux-
> ker...@vger.kernel.org
> Subject: [PATCH v8 06/10] drm/i915/hdcp: Retain hdcp_capable return codes
>
> From: Sean Paul
>
> The shim functions return error codes, but they are discarded in
> intel_hdcp.c. This patch plumbs the return codes through so they are
> properly handled.
>
> Acked-by: Jani Nikula
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: Sean Paul
> Signed-off-by: Mark Yacoub
>
> ---
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -Rebased
> Changes in v7:
> -None
> Changes in v8:
> -None
>
> .../drm/i915/display/intel_display_debugfs.c | 9 +++-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 51 ++-
> drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
> 3 files changed, 37 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 7bcd90384a46d..a14b86a07e545 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -494,6 +494,7 @@ static void intel_panel_info(struct seq_file *m, static
> void intel_hdcp_info(struct seq_file *m,
> struct intel_connector *intel_connector) {
> + int ret;
> bool hdcp_cap, hdcp2_cap;
>
> if (!intel_connector->hdcp.shim) {
> @@ -501,8 +502,12 @@ static void intel_hdcp_info(struct seq_file *m,
> goto out;
> }
>
> - hdcp_cap = intel_hdcp_capable(intel_connector);
> - hdcp2_cap = intel_hdcp2_capable(intel_connector);
> + ret = intel_hdcp_capable(intel_connector, &hdcp_cap);
> + if (ret)
> + hdcp_cap = false;
> + ret = intel_hdcp2_capable(intel_connector, &hdcp2_cap);
> + if (ret)
> + hdcp2_cap = false;
>
> if (hdcp_cap)
> seq_puts(m, "HDCP1.4 ");
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 0a20bc41be55d..61a862ae1f286 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -177,50 +177,49 @@ int intel_hdcp_read_valid_bksv(struct
> intel_digital_port *dig_port, }
>
> /* Is HDCP1.4 capable on Platform and Sink */ -bool
> intel_hdcp_capable(struct intel_connector *connector)
> +int intel_hdcp_capable(struct intel_connector *connector, bool
> +*capable)
> {
> struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> const struct intel_hdcp_shim *shim = connector->hdcp.shim;
> - bool capable = false;
> u8 bksv[5];
>
> + *capable = false;
> +
> if (!shim)
> - return capable;
> + return 0;
>
> - if (shim->hdcp_capable) {
> - shim->hdcp_capable(dig_port, &capable);
> - } else {
> - if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
> - capable = true;
> - }
> + if (shim->hdcp_capable)
> + return shim->hdcp_capable(dig_port, capable);
> +
> + if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
> + *capable = true;
>
> - return capable;
> + return 0;
> }
>
> /* Is HDCP2.2 capable on Platform and Sink */ -bool
> intel_hdcp2_capable(struct intel_connector *connector)
> +int intel_hdcp2_capable(struct intel_connector *connector, bool
> +*capable)
> {
> struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_hdcp *hdcp = &connector->hdcp;
> - bool capable = false;
> +
> + *capable = false;
>
> /* I915 support for HDCP2.2 */
> if (!hdcp->hdcp2_supported)
> - return false;
> + return 0;
>
> /* MEI interface is solid */
> mutex_lock(&dev_priv->display.hdcp.comp_mutex);
> if (!dev_priv->display.hdcp.comp_added || !dev_priv-
> >display.hdcp.master) {
> mutex_unlock(&dev_priv->display.hdcp.comp_mutex);
> - return false;
> + return 0;
> }
> mutex_unlock(&dev_priv->display.hdcp.comp_mutex);
>
> /* Sink's capability for HDCP2.2 */
> - hdcp->shim->hdcp_2_2_capable(dig_port, &capable);
> -
> - return capable;
> + return hdcp->shim->hdcp_2_2_capable(dig_port, capable);
> }
>
> static bool intel_hdcp_in_use(struct drm_i915_private *dev_priv, @@ -
> 2355,6 +2354,7 @@ int intel_hdcp_enable(struct intel_connector
> *
RE: [PATCH v8 04/10] drm/hdcp: Expand HDCP helper library for enable/disable/check
> -Original Message-
> From: Mark Yacoub
> Sent: Saturday, April 1, 2023 3:42 AM
> To: David Airlie ; Daniel Vetter
> Cc: seanp...@chromium.org; Kandpal, Suraj ;
> diand...@chromium.org; dri-devel@lists.freedesktop.org;
> freedr...@lists.freedesktop.org; intel-...@lists.freedesktop.org; Nikula, Jani
> ; Mark Yacoub ; linux-
> ker...@vger.kernel.org
> Subject: [PATCH v8 04/10] drm/hdcp: Expand HDCP helper library for
> enable/disable/check
>
> From: Sean Paul
>
> Expand upon the HDCP helper library to manage HDCP enable, disable, and
> check.
>
> Previous to this patch, the majority of the state management and sink
> interaction is tucked inside the Intel driver with the understanding
> that once a new platform supported HDCP we could make good decisions
> about what should be centralized. With the addition of HDCP support
> for Qualcomm, it's time to migrate the protocol-specific bits of HDCP
> authentication, key exchange, and link checks to the HDCP helper.
>
> In terms of functionality, this migration is 1:1 with the Intel driver,
> however things are laid out a bit differently than with intel_hdcp.c,
> which is why this is a separate patch from the i915 transition to the
> helper. On i915, the shim vtable is used to account for HDMI vs. DP
> vs. DP-MST differences whereas the helper library uses a LUT to
> account for the register offsets and a remote read function to route
> the messages. On i915, storing the sink information in the source is
> done inline whereas now we use the new drm_hdcp_helper_funcs vtable
> to store and fetch information to/from source hw. Finally, instead of
> calling enable/disable directly from the driver, we'll leave that
> decision to the helper and by calling drm_hdcp_helper_atomic_commit()
> from the driver. All told, this will centralize the protocol and state
> handling in the helper, ensuring we collect all of our bugs^Wlogic
> in one place.
>
> Acked-by: Jani Nikula
> Signed-off-by: Sean Paul
> Signed-off-by: Mark Yacoub
>
> ---
> Changes in v2:
> -Fixed set-but-unused variable identified by 0-day
> Changes in v3:
> -Fixed uninitialized variable warning identified by 0-day
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -Fixed typo in function descriptions
> -Rebased: Moved the new code between drm_hdcp.h and
> drm_hdcp_helper.c/h
> -Add missing headers. Reported-by: kernel test robot
> Changes in v7:
> - Add a |driver_data| field to some functions in drm_hdcp_helper_funcs
> that are called by the driver so drivers can pass anything they such
> as bridges
> - Isolate all non-common code between HDMI and DP into separate
> functions instead of manually checking for datra->aux
> Changes in v8 (suraj):
> -Try hdcp 1.x if hdcp2_capable returns an error instead of goto out.
> -set the enabled type to either 1 or 0 depending on the prop as hdcp2
> can support either.
>
> drivers/gpu/drm/display/drm_hdcp_helper.c | 1215
> +
> include/drm/display/drm_hdcp.h| 287 +
> include/drm/display/drm_hdcp_helper.h | 51 +-
> 3 files changed, 1552 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
> b/drivers/gpu/drm/display/drm_hdcp_helper.c
> index 3ee1a6ae26c53..3bc0308cc95d8 100644
> --- a/drivers/gpu/drm/display/drm_hdcp_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
> @@ -6,13 +6,18 @@
> * Ramalingam C
> */
>
> +#include
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> +#include
>
> +#include
> #include
> #include
> #include
> @@ -507,3 +512,1213 @@ bool drm_hdcp_has_changed(struct
> drm_connector *connector,
> return old_hdcp != new_hdcp;
> }
> EXPORT_SYMBOL(drm_hdcp_has_changed);
> +
> +struct drm_hdcp_hdcp1_receiver_reg_lut {
> + unsigned int bksv;
> + unsigned int ri;
> + unsigned int aksv;
> + unsigned int an;
> + unsigned int ainfo;
> + unsigned int v[5];
> + unsigned int bcaps;
> + unsigned int bcaps_mask_repeater_present;
> + unsigned int bstatus;
> +};
> +
> +static const struct drm_hdcp_hdcp1_receiver_reg_lut
> drm_hdcp_hdcp1_ddc_lut = {
> + .bksv = DRM_HDCP_DDC_BKSV,
> + .ri = DRM_HDCP_DDC_RI_PRIME,
> + .aksv = DRM_HDCP_DDC_AKSV,
> + .an = DRM_HDCP_DDC_AN,
> + .ainfo = DRM_HDCP_DDC_AINFO,
> + .v = { DRM_HDCP_DDC_V_PRIME(0), DRM_HDCP_DDC_V_PRIME(1),
> +DRM_HDCP_DDC_V_PRIME(2), DRM_HDCP_DDC_V_PRIME(3),
> +DRM_HDCP_DDC_V_PRIME(4) },
> + .bcaps = DRM_HDCP_DDC_BCAPS,
> + .bcaps_mask_repeater_present =
> DRM_HDCP_DDC_BCAPS_REPEATER_PRESENT,
> + .bstatus = DRM_HDCP_DDC_BSTATUS,
> +};
> +
> +static const struct drm_hdcp_hdcp1_receiver_reg_lut
> drm_hdcp_hdcp1_dpcd_lut = {
> + .bksv = DP_AUX_HDCP_BKSV,
> + .ri = DP_AUX_HDCP_RI_PRIME,
> + .aksv = DP_AUX_HDCP_AKSV,
> + .an = DP_AUX_HDCP_AN,
> + .ainfo = DP_AUX_HDCP_AINFO,
> + .v = { DP_AUX
Re: [PATCH] drm/panfrost: Fix the panfrost_mmu_map_fault_addr() error path
+David
On Fri, 21 May 2021 11:42:04 +0100
Steven Price wrote:
> On 21/05/2021 10:38, Boris Brezillon wrote:
> > Make sure all bo->base.pages entries are either NULL or pointing to a
> > valid page before calling drm_gem_shmem_put_pages().
> >
> > Reported-by: Tomeu Vizoso
> > Cc:
> > Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
> > Signed-off-by: Boris Brezillon
>
> Reviewed-by: Steven Price
Queued to drm-misc-fixes.
>
> > ---
> > drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > index 569509c2ba27..d76dff201ea6 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > @@ -460,6 +460,7 @@ static int panfrost_mmu_map_fault_addr(struct
> > panfrost_device *pfdev, int as,
> > if (IS_ERR(pages[i])) {
> > mutex_unlock(&bo->base.pages_lock);
> > ret = PTR_ERR(pages[i]);
> > + pages[i] = NULL;
> > goto err_pages;
> > }
> > }
> >
>
Re: [PATCH] accel/habanalabs/uapi: new Gaudi2 server type
On Thu, Mar 30, 2023 at 12:32:34PM +0300, Oded Gabbay wrote:
> Add definition of a new Gaudi2 server type. This represents
> the connectivity between the cards in that server type.
>
> Signed-off-by: Oded Gabbay
Reviewed-by: Stanislaw Gruszka
> ---
> include/uapi/drm/habanalabs_accel.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/habanalabs_accel.h
> b/include/uapi/drm/habanalabs_accel.h
> index c139aab17c8a..d9ef1b151d04 100644
> --- a/include/uapi/drm/habanalabs_accel.h
> +++ b/include/uapi/drm/habanalabs_accel.h
> @@ -708,7 +708,8 @@ enum hl_server_type {
> HL_SERVER_GAUDI_HLS1H = 2,
> HL_SERVER_GAUDI_TYPE1 = 3,
> HL_SERVER_GAUDI_TYPE2 = 4,
> - HL_SERVER_GAUDI2_HLS2 = 5
> + HL_SERVER_GAUDI2_HLS2 = 5,
> + HL_SERVER_GAUDI2_TYPE1 = 7
> };
>
> /*
> --
> 2.40.0
>
RE: [PATCH 0/7] Enable YCbCr420 format for VDSC
> -Original Message-
> From: Dmitry Baryshkov
> Sent: Tuesday, March 28, 2023 6:58 PM
> To: Kandpal, Suraj
> Cc: Jani Nikula ;
> dri-devel@lists.freedesktop.org;
> intel-...@lists.freedesktop.org; Nautiyal, Ankit K
> ;
> Shankar, Uma ; Maarten Lankhorst
>
> Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC
>
> On Tue, 28 Mar 2023 at 16:20, Kandpal, Suraj wrote:
> > > -Original Message-
> > > From: dri-devel On Behalf
> > > Of Jani Nikula
> > > Sent: Wednesday, March 8, 2023 5:00 PM
> > > To: Kandpal, Suraj ; dri-
> > > de...@lists.freedesktop.org; intel-...@lists.freedesktop.org
> > > Cc: Dmitry Baryshkov ; Nautiyal, Ankit
> > > K ; Shankar, Uma
> > > ; Kandpal, Suraj
> > > Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC
> > >
> > > On Wed, 22 Feb 2023, Suraj Kandpal wrote:
> > > > This patch series aims to enable the YCbCr420 format for DSC.
> > > > Changes are mostly compute params related for hdmi,dp and dsi
> > > > along with the addition of new rc_tables for native_420 and
> > > > corresponding changes to macros used to fetch them.
> > > > There have been discussions prior to this series in which some
> > > > patches have gotten rb and can be found in the below link
> > > > https://patchwork.freedesktop.org/series/113729
> > >
> > > I think it would be useful to get [1] from Dmitry merged to
> > > drm-misc-next first, have that in drm-next, and again backmerged to
> > > drm-intel-next before this. At least patches 1-5.
> > >
> > > There's not much point in all drivers duplicating the parameters,
> > > and we need to move towards common code. Dmitry has been helpful in
> > > contributing this to us.
> > >
> > > BR,
> > > Jani.
> > >
> > >
> >
> > Hi Jani,
> > Maarten has acked the patch series to be merged through drm-intel and
> > in the meantime I will work with Dmitry to pull the common code to
> > avoid duplication
>
> Thank you! If necessary feel free to ping me on IRC ('lumag').
Thanks guys, will help merge the change.
Regards,
Uma Shankar
> >
> > Regards,
> > Suraj Kandpal
> >
> > > [1] https://patchwork.freedesktop.org/series/114473/
> > >
> > > >
> > > > Ankit Nautiyal (2):
> > > > drm/dp_helper: Add helper to check DSC support with given o/p format
> > > > drm/i915/dp: Check if DSC supports the given output_format
> > > >
> > > > Suraj Kandpal (4):
> > > > drm/i915: Adding the new registers for DSC
> > > > drm/i915: Enable YCbCr420 for VDSC
> > > > drm/i915/display: Fill in native_420 field
> > > > drm/i915/vdsc: Check slice design requirement
> > > >
> > > > Swati Sharma (1):
> > > > drm/i915/dsc: Add debugfs entry to validate DSC output formats
> > > >
> > > > drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
> > > > .../drm/i915/display/intel_crtc_state_dump.c | 4 +-
> > > > .../drm/i915/display/intel_crtc_state_dump.h | 2 +
> > > > .../drm/i915/display/intel_display_debugfs.c | 78
> > > > .../drm/i915/display/intel_display_types.h| 1 +
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 39 +++-
> > > > .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
> > > > .../gpu/drm/i915/display/intel_qp_tables.h| 4 +-
> > > > drivers/gpu/drm/i915/display/intel_vdsc.c | 108 +-
> > > > drivers/gpu/drm/i915/i915_reg.h | 28 +++
> > > > include/drm/display/drm_dp_helper.h | 13 ++
> > > > 11 files changed, 442 insertions(+), 24 deletions(-)
> > >
> > > --
> > > Jani Nikula, Intel Open Source Graphics Center
>
>
>
> --
> With best wishes
> Dmitry
Re: [PATCH] drm/mediatek: dp: change the aux retries times when receiving AUX_DEFER
Hi, Xinlei:
於 2023年3月29日 週三 下午2:43寫道：
>
> From: Xinlei Lee
>
> DP 1.4a Section 2.8.7.1.5.6.1:
> A DP Source device shall retry at least seven times upon receiving
> AUX_DEFER before giving up the AUX transaction.
>
> The drm_dp_i2c_do_msg() function in the drm_dp_helper.c file will
> judge the status of the msg->reply parameter passed to aux_transfer
> ange-the-aux-retries-times-when-re.patchfor different processing.
>
> Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
> Signed-off-by: Xinlei Lee
> ---
> drivers/gpu/drm/mediatek/mtk_dp.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
> b/drivers/gpu/drm/mediatek/mtk_dp.c
> index 1f94fcc144d3..767b71da31a4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -806,10 +806,9 @@ static int mtk_dp_aux_wait_for_completion(struct mtk_dp
> *mtk_dp, bool is_read)
> }
>
> static int mtk_dp_aux_do_transfer(struct mtk_dp *mtk_dp, bool is_read, u8
> cmd,
> - u32 addr, u8 *buf, size_t length)
> + u32 addr, u8 *buf, size_t length, u8
> *reply_cmd)
> {
> int ret;
> - u32 reply_cmd;
>
> if (is_read && (length > DP_AUX_MAX_PAYLOAD_BYTES ||
> (cmd == DP_AUX_NATIVE_READ && !length)))
> @@ -841,10 +840,10 @@ static int mtk_dp_aux_do_transfer(struct mtk_dp
> *mtk_dp, bool is_read, u8 cmd,
> /* Wait for feedback from sink device. */
> ret = mtk_dp_aux_wait_for_completion(mtk_dp, is_read);
>
> - reply_cmd = mtk_dp_read(mtk_dp, MTK_DP_AUX_P0_3624) &
> - AUX_RX_REPLY_COMMAND_AUX_TX_P0_MASK;
> + *reply_cmd = mtk_dp_read(mtk_dp, MTK_DP_AUX_P0_3624) &
> +AUX_RX_REPLY_COMMAND_AUX_TX_P0_MASK;
>
> - if (ret || reply_cmd) {
> + if (ret) {
> u32 phy_status = mtk_dp_read(mtk_dp, MTK_DP_AUX_P0_3628) &
> AUX_RX_PHY_STATE_AUX_TX_P0_MASK;
> if (phy_status != AUX_RX_PHY_STATE_AUX_TX_P0_RX_IDLE) {
> @@ -2070,7 +2069,7 @@ static ssize_t mtk_dp_aux_transfer(struct drm_dp_aux
> *mtk_aux,
> ret = mtk_dp_aux_do_transfer(mtk_dp, is_read, request,
> msg->address + accessed_bytes,
> msg->buffer + accessed_bytes,
> -to_access);
> +to_access, &msg->reply);
>
> if (ret) {
> drm_info(mtk_dp->drm_dev,
> @@ -2080,7 +2079,6 @@ static ssize_t mtk_dp_aux_transfer(struct drm_dp_aux
> *mtk_aux,
> accessed_bytes += to_access;
> } while (accessed_bytes < msg->size);
>
> - msg->reply = DP_AUX_NATIVE_REPLY_ACK | DP_AUX_I2C_REPLY_ACK;
In your description, you just mention the retry count is 7 times, but
you does not mention you should change the reply. Why you modify this?
And where is the 7 times retry?
Regards,
Chun-Kuang.
> return msg->size;
> err:
> msg->reply = DP_AUX_NATIVE_REPLY_NACK | DP_AUX_I2C_REPLY_NACK;
> --
> 2.18.0
>
Re: [PATCH v30 0/7] Add MediaTek SoC DRM (vdosys1) support for mt8195
Hi, Chen-yu: Chen-Yu Tsai 於 2023年3月30日 週四 下午7:05寫道： > > On Mon, Mar 27, 2023 at 11:17 PM Chun-Kuang Hu > wrote: > > > > Hi, Angelo: > > > > AngeloGioacchino Del Regno 於 > > 2023年3月24日 週五 下午4:38寫道： > > > > > > Il 24/03/23 00:25, Chun-Kuang Hu ha scritto: > > > > Hi, Angelo: > > > > > > > > AngeloGioacchino Del Regno 於 > > > > 2023年3月23日 週四 下午4:58寫道： > > > >> > > > >> Il 21/03/23 13:18, Nancy.Lin ha scritto: > > > >>> The hardware path of vdosys1 with DPTx output need to go through by > > > >>> several modules, such as, OVL_ADAPTOR and MERGE. > > > >>> > > > >>> Add DRM and these modules support by the patches below: > > > >>> > > > >> > > > >> I've tested v30 again on MT8173, MT8192 and MT8195 based Chromebooks. > > > >> Green light from me. > > > > > > > > I'm curious about how you build code and test on Chromebooks. Do you > > > > build in cros environment or pure linux > > > > (https://archlinuxarm.org/platforms/armv8/mediatek/acer-chromebook-r13). > > > > I've a MT8183 based Chromebook (HP 11a) and I've tried to run a > > > > upstream kernel on it. cros is too heavy for me and I doubt I could > > > > use it. I've tried the pure linux and could boot up with console, but > > > > display does not work. If you use the pure linux environment, could > > > > you share how it works? > > > > > > > > > > I haven't tested MT8183 (I don't actually have any 8183 machine in my > > > hands)... but > > > yes, I can share my test environment. > > > > > > I have one MicroSD that I use either in the MicroSD slot of the target > > > machine, or > > > in a USB reader; this *single* system is what I boot on *all* Chromebooks > > > that I > > > have: one kernel, multiple devicetrees, same Debian-based userspace. > > > > > > What we have to prepare this bootable media can be found at [1], but > > > beware that > > > it currently uses an outdated kernel, so, what I have locally is a > > > symlink to my > > > kernel tree. > > > You can change/add/remove the devicetree blobs that will get added to the > > > image > > > by modifying `chromebook-setup.sh`; before tampering with kernel tree > > > symlink, > > > please run that script for the first time, as it will download a > > > cross-compiler, > > > a kernel tree (that you will replace for sure) and the (very old) Debian > > > rootfs > > > that you can update with `apt-get dist-upgrade` after booting the > > > Chromebook. > > > > > > If you want to check about possible kernel configuration differences, > > > what I use > > > is at [2], so that you can compare. > > > > Thanks for the information, I would try to compare the kernel config first. > > Hi CK, > > Would you consider adding your repo to linux-next? That would let everyone > do integration testing, especially automated ones, earlier, before you send > your PRs to drm maintainers. > > You can do so by sending an email to Stephen Rothwell to do so. I don't understand what this process is. Does it means that I directly upstream patches into linux-next? I prefer that my patches go through drm maintainers' tree. Does any document introduce this process? Regards, Chun-Kuang. > > > ChenYu > > > > > > > [1]: https://gitlab.collabora.com/google/chromebooks/-/tree/mtk-av1 > > > [2]: > > > https://gitlab.collabora.com/google/chromeos-kernel/-/blob/mt8195-tracking-master-rolling/arch/arm64/configs/defconfig > > > > > > Regards, > > > Angelo
Re: [PATCH 01/21] dt-bindings: display: mediatek: aal: add binding for MT8365 SoC
Hi, Matthias: Matthias Brugger 於 2023年3月31日 週五 下午10:55寫道： > > Hi Chun-Kuang Hu, > > On 13/03/2023 16:02, Chun-Kuang Hu wrote: > > Hi, Alexandre: > > > > Alexandre Mergnat 於 2023年3月9日 週四 下午10:23寫道： > >> > >> Display Adaptive Ambient Light for MT8365 is compatible with another SoC. > >> Then, add MT8365 binding along with MT8183 SoC. > > > > Reviewed-by: Chun-Kuang Hu > > > > I'm a bit puzzled that you give your reviewed by while I would have expected > that you will take the display binding patches. Will you take these or do you > want someone else to take them? I usually apply whole series together, and I've question about "[07/21] dt-bindings: display: mediatek: dpi: add binding for MT8365" in this series. This is just the first version, so maybe I would apply partial patches in later version. Regards, Chun-Kuang. > > Regards, > Matthias > > >> > >> Signed-off-by: Alexandre Mergnat > >> --- > >> Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 > >> + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > >> b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > >> index d4d585485e7b..d47bc72f09c0 100644 > >> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > >> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > >> @@ -33,6 +33,7 @@ properties: > >> - mediatek,mt8186-disp-aal > >> - mediatek,mt8192-disp-aal > >> - mediatek,mt8195-disp-aal > >> + - mediatek,mt8365-disp-aal > >> - const: mediatek,mt8183-disp-aal > >> > >> reg: > >> > >> -- > >> b4 0.10.1
Re: [PATCH v3 1/2] drm/mediatek: Add mdp_rdma get format function
Hi, Nancy:
Nancy.Lin 於 2023年3月30日 週四 上午11:26寫道：
>
> Add mdp_rdma get_format and get_num_formats function.
For the series, applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Signed-off-by: Nancy.Lin
> ---
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 +++
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 24
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 0d28b2e2069c..17b169530beb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -152,4 +152,7 @@ void mtk_mdp_rdma_start(struct device *dev, struct
> cmdq_pkt *cmdq_pkt);
> void mtk_mdp_rdma_stop(struct device *dev, struct cmdq_pkt *cmdq_pkt);
> void mtk_mdp_rdma_config(struct device *dev, struct mtk_mdp_rdma_cfg *cfg,
> struct cmdq_pkt *cmdq_pkt);
> +const u32 *mtk_mdp_rdma_get_formats(struct device *dev);
> +size_t mtk_mdp_rdma_get_num_formats(struct device *dev);
> +
> #endif
> diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> index eecfa98ff52e..e06db6e56b5f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> @@ -62,6 +62,20 @@
> #define RDMA_CSC_FULL709_TO_RGB5
> #define RDMA_CSC_BT601_TO_RGB 6
>
> +static const u32 formats[] = {
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_BGRX,
> + DRM_FORMAT_BGRA,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_BGR888,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_YUYV,
> +};
> +
> enum rdma_format {
> RDMA_INPUT_FORMAT_RGB565 = 0,
> RDMA_INPUT_FORMAT_RGB888 = 1,
> @@ -219,6 +233,16 @@ void mtk_mdp_rdma_config(struct device *dev, struct
> mtk_mdp_rdma_cfg *cfg,
>MDP_RDMA_MF_CLIP_SIZE, FLD_MF_CLIP_H);
> }
>
> +const u32 *mtk_mdp_rdma_get_formats(struct device *dev)
> +{
> + return formats;
> +}
> +
> +size_t mtk_mdp_rdma_get_num_formats(struct device *dev)
> +{
> + return ARRAY_SIZE(formats);
> +}
> +
> int mtk_mdp_rdma_clk_enable(struct device *dev)
> {
> struct mtk_mdp_rdma *rdma = dev_get_drvdata(dev);
> --
> 2.18.0
>
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/lima/lima_ctx.c: In function 'lima_ctx_do_release':
drivers/gpu/drm/lima/lima_ctx.c:53:45: error: 'struct drm_sched_entity' has no
member named 'elapsed_ns'
53 | mgr->elapsed_ns[i] += entity->elapsed_ns;
| ^~
drivers/gpu/drm/lima/lima_ctx.c: In function 'lima_ctx_mgr_usage':
drivers/gpu/drm/lima/lima_ctx.c:125:43: error: 'struct drm_sched_entity' has no
member named 'elapsed_ns'
125 | usage[i] += entity->elapsed_ns;
| ^~
Caused by commit
bccafec957a5 ("drm/lima: add usage counting method to ctx_mgr")
interacting with commit
baad10973fdb ("Revert "drm/scheduler: track GPU active time per entity"")
from Linus' tree.
I can't see any obvious way to fix this up, so I have used teh drm-misc
tree from next-20230331 for today.
--
Cheers,
Stephen Rothwell
pgp2cmHelCmZS.pgp
Description: OpenPGP digital signature
Re: [PATCH] drm/vblank: Fix for drivers that do not drm_vblank_init()
On Sat, Apr 01, 2023 at 08:38:02AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> This should fix a crash that was reported on ast (and possibly other
> drivers which do not initialize vblank).
>
>fbcon: Taking over console
>Unable to handle kernel NULL pointer dereference at virtual address
> 0074
>Mem abort info:
> ESR = 0x9604
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x04: level 0 translation fault
>Data abort info:
> ISV = 0, ISS = 0x0004
> CM = 0, WnR = 0
>user pgtable: 4k pages, 48-bit VAs, pgdp=080009d16000
>[0074] pgd=, p4d=
>Internal error: Oops: 9604 [#1] SMP
>Modules linked in: ip6table_nat tun nft_fib_inet nft_fib_ipv4 nft_fib_ipv6
> nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct
> nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set
> nf_tables nfnetlink qrtr sunrpc binfmt_misc vfat fat xfs snd_usb_audio
> snd_hwdep snd_usbmidi_lib snd_seq snd_pcm snd_rawmidi snd_timer
> snd_seq_device snd soundcore joydev mc ipmi_ssif ipmi_devintf ipmi_msghandler
> arm_spe_pmu arm_cmn arm_dsu_pmu arm_dmc620_pmu cppc_cpufreq loop zram
> crct10dif_ce polyval_ce nvme polyval_generic ghash_ce sbsa_gwdt igb nvme_core
> ast nvme_common i2c_algo_bit xgene_hwmon gpio_dwapb scsi_dh_rdac scsi_dh_emc
> scsi_dh_alua ip6_tables ip_tables dm_multipath fuse
>CPU: 12 PID: 469 Comm: kworker/12:1 Not tainted
> 6.3.0-rc2-8-gd39e48ca80c0 #1
>Hardware name: ADLINK AVA Developer Platform/AVA Developer Platform, BIOS
> TianoCore 2.04.100.07 (SYS: 2.06.20220308) 09/08/2022
>Workqueue: events fbcon_register_existing_fbs
>pstate: 2049 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>pc : drm_crtc_next_vblank_start+0x2c/0x98
>lr : drm_atomic_helper_wait_for_fences+0x90/0x240
>sp : 8d583960
>x29: 8d583960 x28: 07ff8fc187b0 x27:
>x26: 07ff99c08c00 x25: 0038 x24: 07ff99c0c000
>x23: 0001 x22: 0038 x21:
>x20: 07ff9640a280 x19: x18:
>x17: x16: b24d2eece1c0 x15: 003038303178
>x14: 303239310048 x13: x12:
>x11: x10: x9 : b24d2eeeaca0
>x8 : 8d583628 x7 : 080077783000 x6 :
>x5 : 8d584000 x4 : 07ff99c0c000 x3 : 0130
>x2 : x1 : 8d5839c0 x0 : 07ff99c0cc08
>Call trace:
> drm_crtc_next_vblank_start+0x2c/0x98
> drm_atomic_helper_wait_for_fences+0x90/0x240
> drm_atomic_helper_commit+0xb0/0x188
> drm_atomic_commit+0xb0/0xf0
> drm_client_modeset_commit_atomic+0x218/0x280
> drm_client_modeset_commit_locked+0x64/0x1a0
> drm_client_modeset_commit+0x38/0x68
> __drm_fb_helper_restore_fbdev_mode_unlocked+0xb0/0xf8
> drm_fb_helper_set_par+0x44/0x88
> fbcon_init+0x1e0/0x4a8
> visual_init+0xbc/0x118
> do_bind_con_driver.isra.0+0x194/0x3a0
> do_take_over_console+0x50/0x70
> do_fbcon_takeover+0x74/0xf8
> do_fb_registered+0x13c/0x158
> fbcon_register_existing_fbs+0x78/0xc0
> process_one_work+0x1ec/0x478
> worker_thread+0x74/0x418
> kthread+0xec/0x100
> ret_from_fork+0x10/0x20
>Code: f944 b9409013 f940a082 9ba30a73 (b9407662)
>---[ end trace ]---
>
> Reported-by: Nathan Chancellor
> Fixes: d39e48ca80c0 ("drm/atomic-helper: Set fence deadline for vblank")
> Signed-off-by: Rob Clark
Seems to work for me, I no longer see the above crash.
Tested-by: Nathan Chancellor
> ---
> drivers/gpu/drm/drm_vblank.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 299fa2a19a90..e98e3cefba3a 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -996,10 +996,16 @@ EXPORT_SYMBOL(drm_crtc_vblank_count_and_time);
> int drm_crtc_next_vblank_start(struct drm_crtc *crtc, ktime_t *vblanktime)
> {
> unsigned int pipe = drm_crtc_index(crtc);
> - struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe];
> - struct drm_display_mode *mode = &vblank->hwmode;
> + struct drm_vblank_crtc *vblank;
> + struct drm_display_mode *mode;
> u64 vblank_start;
>
> + if (!crtc->dev->vblank)
> + return -EINVAL;
> +
> + vblank = &crtc->dev->vblank[pipe];
> + mode = &vblank->hwmode;
> +
> if (!vblank->framedur_ns || !vblank->linedur_ns)
> return -EINVAL;
>
> --
> 2.39.2
>
Re: [PATCH] dt-bindings: bridge: Convert Samsung MIPI DSIM bridge to yaml
On 3/31/23 21:57, Fabio Estevam wrote: From: Jagan Teki Samsung MIPI DSIM bridge can be found on Exynos and NXP's i.MX8M Mini and Nano SoC's. MX8M Plus too . Convert exynos_dsim.txt to yaml. Used the example node from latest Exynos SoC instead of the one used in legacy exynos_dsim.txt. Signed-off-by: Jagan Teki Signed-off-by: Fabio Estevam --- .../display/bridge/samsung,mipi-dsim.yaml | 275 ++ .../bindings/display/exynos/exynos_dsim.txt | 92 -- 2 files changed, 275 insertions(+), 92 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml new file mode 100644 index ..c131bd879caf --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -0,0 +1,275 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/samsung,mipi-dsim.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung MIPI DSIM bridge controller + +maintainers: + - Inki Dae + - Jagan Teki + +description: | + Samsung MIPI DSIM bridge controller can be found it on Exynos + and i.MX8M Mini and Nano SoC's. Plus too. +properties: + compatible: +enum: + - samsung,exynos3250-mipi-dsi + - samsung,exynos4210-mipi-dsi + - samsung,exynos5410-mipi-dsi + - samsung,exynos5422-mipi-dsi + - samsung,exynos5433-mipi-dsi + - fsl,imx8mm-mipi-dsim + - fsl,imx8mp-mipi-dsim You have plus here already, so just update the description. + reg: +maxItems: 1 + + interrupts: +maxItems: 1 + + '#address-cells': +const: 1 + + '#size-cells': +const: 0 + + clocks: +minItems: 2 +maxItems: 5 + + clock-names: +minItems: 2 +maxItems: 5 + + phys: +maxItems: 1 +description: phandle to the phy module representing the DPHY + + phy-names: +items: + - const: dsim + + samsung,phy-type: +$ref: /schemas/types.yaml#/definitions/uint32 +description: phandle to the samsung phy-type + + power-domains: +description: phandle to the associated power domain +maxItems: 1 + + samsung,power-domain: +$ref: /schemas/types.yaml#/definitions/phandle +description: phandle to the associated samsung power domain + + vddcore-supply: +description: MIPI DSIM Core voltage supply (e.g. 1.1V) + + vddio-supply: +description: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) + + samsung,burst-clock-frequency: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + DSIM high speed burst mode frequency. + + samsung,esc-clock-frequency: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + DSIM escape mode frequency. + + samsung,pll-clock-frequency: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + DSIM oscillator clock frequency. + + ports: +$ref: /schemas/graph.yaml#/properties/ports + +properties: + port@0: +$ref: /schemas/graph.yaml#/$defs/port-base +description: + Input port node to receive pixel data from the + display controller. Exactly one endpoint must be + specified. +properties: + endpoint@0: Why endpoint@0 if this only has one endpoint ? +$ref: /schemas/graph.yaml#/properties/endpoint +description: sub-node describing the input from MIC + +unevaluatedProperties: false + + port@1: +$ref: /schemas/graph.yaml#/properties/port +description: + DSI output port node to the panel or the next bridge + in the chain [...]
Re: [PATCH v4 2/2] drm/virtio: Support sync objects
On 3/30/23 20:24, Emil Velikov wrote:
> Hi Dmitry,
>
> Have you considered creating a few DRM helpers for this functionality?
>
> AFAICT this is the third driver which supports syncobj timelines and
> looking at one of the implementations ... it is not great. Note that
> this suggestion is _not_ a blocker.
Would like to see a third driver starting to use the exactly same
drm_execbuffer_syncobj struct because UABI part isn't generic, though
it's a replica of the MSM driver for now.
The virtio-gpu is only at the beginning of starting to use sync objects,
compared to MSM driver. Will be better to defer the generalization until
virtio-gpu will become more mature, like maybe after a year since the
time virtio userspace will start using sync objects, IMO.
...
>> +static void virtio_gpu_reset_syncobjs(struct drm_syncobj **syncobjs,
>> + uint32_t nr_syncobjs)
>> +{
>> +uint32_t i;
>> +
>> +for (i = 0; i < nr_syncobjs; i++) {
>> +if (syncobjs[i])
>> +drm_syncobj_replace_fence(syncobjs[i], NULL);
>
> Side note: the drm_syncobj_put() called immediately after also calls
> replace/reset fence internally. Although reading from the docs, I'm not
> sure if relying on that is a wise move.
>
> Just thought I'd point it out.
The drm_syncobj_put() doesn't call replace/reset fence until syncobj is
freed. We drop the old fence for active/alive in-syncobj here after
handling the fence-wait, this makes syncobj reusable, otherwise
userpsace would have to re-create syncobjs after each submission.
>>
>> +ret = virtio_gpu_parse_deps(&submit);
>> +if (ret)
>> +goto cleanup;
>> +
>> +ret = virtio_gpu_parse_post_deps(&submit);
>> +if (ret)
>> +goto cleanup;
>> +
>
> I think we should zero num_(in|out)_syncobjs when the respective parse
> fails. Otherwise we get one "cleanup" within the parse function itself
> and a second during the cleanup_submit. Haven't looked at it too closely
> but I suspect that will trigger an UAF or two.
There are checks for NULL pointers in the code that will prevent the
UAF. I'll add zeroing of the nums for more consistency.
>> ret = virtio_gpu_install_out_fence_fd(&submit);
>> if (ret)
>> goto cleanup;
>> @@ -294,6 +512,7 @@ int virtio_gpu_execbuffer_ioctl(struct drm_device *dev,
>> void *data,
>> goto cleanup;
>>
>> virtio_gpu_submit(&submit);
>> +virtio_gpu_process_post_deps(&submit);
>
> Any particular reason why the virtio_gpu_reset_syncobjs is deferred to
> virtio_gpu_cleanup_submit(). Having it just above the process_post_deps
> (similar to msm) allows the reader to get closure about the in syncobjs.
>
> This is just personal preference, so don't read too much into it.
The job submission path should be short as possible in general.
Technically, virtio_gpu_process_post_deps() should be fast, but since
I'm not 100% sure about all the corner cases, it's better to hold until
job is sent out.
Thank you very much for the review! I'll address the rest of comments in v5.
--
Best regards,
Dmitry
[PATCH v1 7/7] drm/shmem-helper: Switch to reservation lock
Replace all drm-shmem locks with a GEM reservation lock. This makes locks
consistent with dma-buf locking convention where importers are responsible
for holding reservation lock for all operations performed over dma-bufs,
preventing deadlock between dma-buf importers and exporters.
Suggested-by: Daniel Vetter
Acked-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 217 --
drivers/gpu/drm/lima/lima_gem.c | 8 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +-
.../gpu/drm/panfrost/panfrost_gem_shrinker.c | 6 +-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 19 +-
include/drm/drm_gem_shmem_helper.h| 14 +-
6 files changed, 120 insertions(+), 151 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 4ea6507a77e5..8fc2a3277486 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -88,8 +88,6 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size,
bool private)
if (ret)
goto err_release;
- mutex_init(&shmem->pages_lock);
- mutex_init(&shmem->vmap_lock);
INIT_LIST_HEAD(&shmem->madv_list);
if (!private) {
@@ -141,11 +139,13 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
*shmem)
{
struct drm_gem_object *obj = &shmem->base;
- drm_WARN_ON(obj->dev, shmem->vmap_use_count);
-
if (obj->import_attach) {
drm_prime_gem_destroy(obj, shmem->sgt);
} else {
+ dma_resv_lock(shmem->base.resv, NULL);
+
+ drm_WARN_ON(obj->dev, shmem->vmap_use_count);
+
if (shmem->sgt) {
dma_unmap_sgtable(obj->dev->dev, shmem->sgt,
DMA_BIDIRECTIONAL, 0);
@@ -154,18 +154,18 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
*shmem)
}
if (shmem->pages)
drm_gem_shmem_put_pages(shmem);
- }
- drm_WARN_ON(obj->dev, shmem->pages_use_count);
+ drm_WARN_ON(obj->dev, shmem->pages_use_count);
+
+ dma_resv_unlock(shmem->base.resv);
+ }
drm_gem_object_release(obj);
- mutex_destroy(&shmem->pages_lock);
- mutex_destroy(&shmem->vmap_lock);
kfree(shmem);
}
EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
-static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
+static int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
{
struct drm_gem_object *obj = &shmem->base;
struct page **pages;
@@ -197,35 +197,16 @@ static int drm_gem_shmem_get_pages_locked(struct
drm_gem_shmem_object *shmem)
}
/*
- * drm_gem_shmem_get_pages - Allocate backing pages for a shmem GEM object
+ * drm_gem_shmem_put_pages - Decrease use count on the backing pages for a
shmem GEM object
* @shmem: shmem GEM object
*
- * This function makes sure that backing pages exists for the shmem GEM object
- * and increases the use count.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
+ * This function decreases the use count and puts the backing pages when use
drops to zero.
*/
-int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
+void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
{
struct drm_gem_object *obj = &shmem->base;
- int ret;
- drm_WARN_ON(obj->dev, obj->import_attach);
-
- ret = mutex_lock_interruptible(&shmem->pages_lock);
- if (ret)
- return ret;
- ret = drm_gem_shmem_get_pages_locked(shmem);
- mutex_unlock(&shmem->pages_lock);
-
- return ret;
-}
-EXPORT_SYMBOL(drm_gem_shmem_get_pages);
-
-static void drm_gem_shmem_put_pages_locked(struct drm_gem_shmem_object *shmem)
-{
- struct drm_gem_object *obj = &shmem->base;
+ dma_resv_assert_held(shmem->base.resv);
if (drm_WARN_ON_ONCE(obj->dev, !shmem->pages_use_count))
return;
@@ -243,20 +224,32 @@ static void drm_gem_shmem_put_pages_locked(struct
drm_gem_shmem_object *shmem)
shmem->pages_mark_accessed_on_put);
shmem->pages = NULL;
}
+EXPORT_SYMBOL(drm_gem_shmem_put_pages);
-/*
- * drm_gem_shmem_put_pages - Decrease use count on the backing pages for a
shmem GEM object
- * @shmem: shmem GEM object
- *
- * This function decreases the use count and puts the backing pages when use
drops to zero.
- */
-void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
+static int drm_gem_shmem_pin_locked(struct drm_gem_shmem_object *shmem)
{
- mutex_lock(&shmem->pages_lock);
- drm_gem_shmem_put_pages_locked(shmem);
- mutex_unlock(&shmem->pages_lock);
+ struct drm_gem_object *obj = &shmem->base;
+ int ret;
+
+ dma_resv_assert_held(shmem->base.resv);
+
+ drm_WARN_ON(obj->dev, obj->import_
[PATCH v1 6/7] dma-buf: Change locking policy for mmap()
Change locking policy of mmap() callback, making exporters responsible
for handling dma-buf reservation locking. Previous locking policy stated
that dma-buf is locked for both importers and exporters by the dma-buf
core, which caused a deadlock problem for DRM drivers in a case of
self-imported dma-bufs which required to take the lock from the DRM
exporter side.
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index aa4ea8530cb3..21916bba77d5 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -131,7 +131,6 @@ static struct file_system_type dma_buf_fs_type = {
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
{
struct dma_buf *dmabuf;
- int ret;
if (!is_dma_buf_file(file))
return -EINVAL;
@@ -147,11 +146,7 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
- dma_resv_lock(dmabuf->resv, NULL);
- ret = dmabuf->ops->mmap(dmabuf, vma);
- dma_resv_unlock(dmabuf->resv);
-
- return ret;
+ return dmabuf->ops->mmap(dmabuf, vma);
}
static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
@@ -850,6 +845,7 @@ static struct sg_table * __map_dma_buf(struct
dma_buf_attachment *attach,
* - &dma_buf_ops.release()
* - &dma_buf_ops.begin_cpu_access()
* - &dma_buf_ops.end_cpu_access()
+ * - &dma_buf_ops.mmap()
*
* 2. These &dma_buf_ops callbacks are invoked with locked dma-buf
*reservation and exporter can't take the lock:
@@ -858,7 +854,6 @@ static struct sg_table * __map_dma_buf(struct
dma_buf_attachment *attach,
* - &dma_buf_ops.unpin()
* - &dma_buf_ops.map_dma_buf()
* - &dma_buf_ops.unmap_dma_buf()
- * - &dma_buf_ops.mmap()
* - &dma_buf_ops.vmap()
* - &dma_buf_ops.vunmap()
*
@@ -1463,8 +1458,6 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_end_cpu_access, DMA_BUF);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
- int ret;
-
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -1485,11 +1478,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
- dma_resv_lock(dmabuf->resv, NULL);
- ret = dmabuf->ops->mmap(dmabuf, vma);
- dma_resv_unlock(dmabuf->resv);
-
- return ret;
+ return dmabuf->ops->mmap(dmabuf, vma);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
--
2.39.2
[PATCH v1 3/7] Revert "udmabuf: Assert held reservation lock for dma-buf mmapping"
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs, it's solved
by moving the lock down to exporters.
Fixes: aa3f99896443 ("udmabuf: Assert held reservation lock for dma-buf
mmapping")
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/udmabuf.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 740d6e426ee9..277f1afa9552 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -52,8 +52,6 @@ static int mmap_udmabuf(struct dma_buf *buf, struct
vm_area_struct *vma)
{
struct udmabuf *ubuf = buf->priv;
- dma_resv_assert_held(buf->resv);
-
if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
return -EINVAL;
--
2.39.2
[PATCH v1 5/7] Revert "drm: Assert held reservation lock for dma-buf mmapping"
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs, it's solved
by moving the lock down to exporters.
Fixes: 39ce25291871 ("drm: Assert held reservation lock for dma-buf mmapping")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_prime.c| 2 --
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 --
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 --
drivers/gpu/drm/tegra/gem.c| 2 --
4 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 149cd4ff6a3b..cea85e84666f 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -781,8 +781,6 @@ int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct
vm_area_struct *vma)
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
- dma_resv_assert_held(dma_buf->resv);
-
if (!dev->driver->gem_prime_mmap)
return -ENOSYS;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index fd556a076d05..1df74f7aa3dc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -97,8 +97,6 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
struct vm_area_struct *
struct drm_i915_private *i915 = to_i915(obj->base.dev);
int ret;
- dma_resv_assert_held(dma_buf->resv);
-
if (obj->base.size < vma->vm_end - vma->vm_start)
return -EINVAL;
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 3abc47521b2c..8e194dbc9506 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -66,8 +66,6 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
struct drm_gem_object *obj = buffer->priv;
int ret = 0;
- dma_resv_assert_held(buffer->resv);
-
ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma);
if (ret < 0)
return ret;
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index bce991a2ccc0..871ef5d26523 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -693,8 +693,6 @@ static int tegra_gem_prime_mmap(struct dma_buf *buf, struct
vm_area_struct *vma)
struct drm_gem_object *gem = buf->priv;
int err;
- dma_resv_assert_held(buf->resv);
-
err = drm_gem_mmap_obj(gem, gem->size, vma);
if (err < 0)
return err;
--
2.39.2
[PATCH v1 4/7] Revert "fastrpc: Assert held reservation lock for dma-buf mmapping"
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs, it's solved
by moving the lock down to exporters.
Fixes: 265751a513ad ("fastrpc: Assert held reservation lock for dma-buf
mmapping")
Signed-off-by: Dmitry Osipenko
---
drivers/misc/fastrpc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index a701132638cf..7e9c9ad37fd9 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -6,7 +6,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -733,8 +732,6 @@ static int fastrpc_mmap(struct dma_buf *dmabuf,
struct fastrpc_buf *buf = dmabuf->priv;
size_t size = vma->vm_end - vma->vm_start;
- dma_resv_assert_held(dmabuf->resv);
-
return dma_mmap_coherent(buf->dev, vma, buf->virt,
FASTRPC_PHYS(buf->phys), size);
}
--
2.39.2
[PATCH v1 2/7] Revert "dma-buf/heaps: Assert held reservation lock for dma-buf mmapping"
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs, it's solved
by moving the lock down to exporters.
Fixes: 27f3733a1049 ("dma-buf/heaps: Assert held reservation lock for dma-buf
mmapping")
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/heaps/cma_heap.c| 3 ---
drivers/dma-buf/heaps/system_heap.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 1131fb943992..28fb04eccdd0 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -183,8 +182,6 @@ static int cma_heap_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma)
{
struct cma_heap_buffer *buffer = dmabuf->priv;
- dma_resv_assert_held(dmabuf->resv);
-
if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
return -EINVAL;
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index e8bd10e60998..fcf836ba9c1f 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -202,8 +201,6 @@ static int system_heap_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma)
struct sg_page_iter piter;
int ret;
- dma_resv_assert_held(dmabuf->resv);
-
for_each_sgtable_page(table, &piter, vma->vm_pgoff) {
struct page *page = sg_page_iter_page(&piter);
--
2.39.2
[PATCH v1 1/7] Revert "media: videobuf2: Assert held reservation lock for dma-buf mmapping"
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs, it's solved
by moving the lock down to exporters.
Fixes: 3a6ca1810f77 ("media: videobuf2: Assert held reservation lock for
dma-buf mmapping")
Signed-off-by: Dmitry Osipenko
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 3 ---
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 3 ---
drivers/media/common/videobuf2/videobuf2-vmalloc.c| 3 ---
3 files changed, 9 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 205d3cac425c..2fa455d4a048 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -11,7 +11,6 @@
*/
#include
-#include
#include
#include
#include
@@ -456,8 +455,6 @@ static int vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf,
struct iosys_map *map)
static int vb2_dc_dmabuf_ops_mmap(struct dma_buf *dbuf,
struct vm_area_struct *vma)
{
- dma_resv_assert_held(dbuf->resv);
-
return vb2_dc_mmap(dbuf->priv, vma);
}
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index 183037fb1273..28f3fdfe23a2 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -10,7 +10,6 @@
* the Free Software Foundation.
*/
-#include
#include
#include
#include
@@ -498,8 +497,6 @@ static int vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf,
static int vb2_dma_sg_dmabuf_ops_mmap(struct dma_buf *dbuf,
struct vm_area_struct *vma)
{
- dma_resv_assert_held(dbuf->resv);
-
return vb2_dma_sg_mmap(dbuf->priv, vma);
}
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index a6c6d2fcaaa4..7c635e292106 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -10,7 +10,6 @@
* the Free Software Foundation.
*/
-#include
#include
#include
#include
@@ -319,8 +318,6 @@ static int vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf,
static int vb2_vmalloc_dmabuf_ops_mmap(struct dma_buf *dbuf,
struct vm_area_struct *vma)
{
- dma_resv_assert_held(dbuf->resv);
-
return vb2_vmalloc_mmap(dbuf->priv, vma);
}
--
2.39.2
[PATCH v1 0/7] Move dma-buf mmap() reservation locking down to exporters
This patchset makes dma-buf exporters responisble for taking care of the reservation lock. I also included patch that moves drm-shmem to use reservation lock, to let CI test the whole set. I'm going to take all the patches via the drm-misc tree, please give an ack. Previous policy stated that dma-buf core takes the lock around mmap() callback. Which meant that both importers and exporters shouldn't touch the reservation lock in the mmap() code path. This worked well until Intel-CI found a deadlock problem in a case of self-imported dma-buf [1]. The problem happens when userpace mmaps a self-imported dma-buf, i.e. mmaps the dma-buf FD. DRM core treats self-imported dma-bufs as own GEMs [2]. There is no way to differentiate a prime GEM from a normal GEM for drm-shmem in drm_gem_shmem_mmap(), which resulted in a deadlock problem for drm-shmem mmap() code path once it's switched to use reservation lock. It was difficult to fix the drm-shmem problem without adjusting dma-buf locking policy. In parctice not much changed from importers perspective because previosly dma-buf was taking the lock in between of importers and exporters. Now this lock is shifted down to exporters. [1] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114671v2/shard-snb5/igt@prime_vgem@s...@rcs0.html [2] https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/drm_prime.c#L924 Dmitry Osipenko (7): Revert "media: videobuf2: Assert held reservation lock for dma-buf mmapping" Revert "dma-buf/heaps: Assert held reservation lock for dma-buf mmapping" Revert "udmabuf: Assert held reservation lock for dma-buf mmapping" Revert "fastrpc: Assert held reservation lock for dma-buf mmapping" Revert "drm: Assert held reservation lock for dma-buf mmapping" dma-buf: Change locking policy for mmap() drm/shmem-helper: Switch to reservation lock drivers/dma-buf/dma-buf.c | 17 +- drivers/dma-buf/heaps/cma_heap.c | 3 - drivers/dma-buf/heaps/system_heap.c | 3 - drivers/dma-buf/udmabuf.c | 2 - drivers/gpu/drm/drm_gem_shmem_helper.c| 217 -- drivers/gpu/drm/drm_prime.c | 2 - drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 - drivers/gpu/drm/lima/lima_gem.c | 8 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 - drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +- .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 6 +- drivers/gpu/drm/panfrost/panfrost_mmu.c | 19 +- drivers/gpu/drm/tegra/gem.c | 2 - .../common/videobuf2/videobuf2-dma-contig.c | 3 - .../media/common/videobuf2/videobuf2-dma-sg.c | 3 - .../common/videobuf2/videobuf2-vmalloc.c | 3 - drivers/misc/fastrpc.c| 3 - include/drm/drm_gem_shmem_helper.h| 14 +- 18 files changed, 123 insertions(+), 193 deletions(-) -- 2.39.2
Re: [PATCH v6 01/15] drm/msm/adreno: adreno_gpu: Don't set OPP scaling clock w/ GMU
On 01/04/2023 14:54, Konrad Dybcio wrote:
Recently I contributed the switch to OPP API for all Adreno generations.
I did however also skip over the fact that GPUs with a GMU don't specify
a core clock of any kind in the GPU node. While that didn't break
anything, it did introduce unwanted spam in the dmesg:
adreno 500.gpu: error -ENOENT: _opp_set_clknames: Couldn't find clock with
name: core_clk
Guard the entire logic so that it's not used with GMU-equipped GPUs.
Fixes: 9f251f934012 ("drm/msm/adreno: Use OPP for every GPU generation")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
[PATCH v7 1/2] drm/fourcc: Add Synaptics VideoSmart tiled modifiers
From: "Hsia-Jun(Randy) Li"
Those modifiers only record the parameters would effort pixel
layout or memory layout. Whether physical memory page mapping
is used is not a part of format.
Signed-off-by: Hsia-Jun(Randy) Li
---
include/uapi/drm/drm_fourcc.h | 75 +++
1 file changed, 75 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index de703c6be969..ee13250f06f4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -419,6 +419,7 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
+#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b
/* add more to the end as needed */
@@ -1519,6 +1520,80 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
#define AMD_FMT_MOD_CLEAR(field) \
(~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
+/*
+ * Synaptics VideoSmart modifiers
+ *
+ * Tiles could be arranged in Groups of Tiles (GOTs), it is a small tile
+ * within a tile. GOT size and layout varies based on platform and
+ * performance concern. When the compression is applied, it is possible
+ * that we would have two tile type in the GOT, these parameters can't
+ * tell the secondary tile type.
+ *
+ * Besides, an 8 size 4 bytes arrary (32 bytes) would be need to store
+ * some compression parameters for a compression meta data plane.
+ *
+ * Macro
+ * Bits Param Description
+ * -
-
+ *
+ * 7:0 f Scan direction description.
+ *
+ * 0 = Invalid
+ * 1 = V4, the scan would always start from vertical for 4 pixel
+ * then move back to the start pixel of the next horizontal
+ * direction.
+ * 2 = Reserved for future use.
+ *
+ * 15:8 m The times of pattern repeat in the right angle direction from
+ * the first scan direction.
+ *
+ * 19:16 p The padding bits after the whole scan, could be zero.
+ *
+ * 20:20 g GOT packing flag.
+ *
+ * 23:21 - Reserved for future use. Must be zero.
+ *
+ * 27:24 h log2(horizontal) of bytes, in GOTs.
+ *
+ * 31:28 v log2(vertical) of bytes, in GOTs.
+ *
+ * 35:32 - Reserved for future use. Must be zero.
+ *
+ * 36:36 c Compression flag.
+ *
+ * 55:37 - Reserved for future use. Must be zero.
+ *
+ */
+
+#define DRM_FORMAT_MOD_SYNA_V4_TILED fourcc_mod_code(SYNAPTICS, 1)
+
+#define DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(f, m, p, g, h, v, c) \
+ fourcc_mod_code(SYNAPTICS, ((__u64)((f) & 0xff) | \
+((__u64)((m) & 0xff) << 8) | \
+((__u64)((p) & 0xf) << 16) | \
+((__u64)((g) & 0x1) << 20) | \
+((__u64)((h) & 0xf) << 24) | \
+((__u64)((v) & 0xf) << 28) | \
+((__u64)((c) & 0x1) << 36)))
+
+#define DRM_FORMAT_MOD_SYNA_V4H1 \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 0, 0, 0, 0)
+
+#define DRM_FORMAT_MOD_SYNA_V4H3P8 \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 0, 0, 0, 0)
+
+#define DRM_FORMAT_MOD_SYNA_V4H1_64L4_COMPRESSED \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1, 6, 2, 1)
+
+#define DRM_FORMAT_MOD_SYNA_V4H3P8_64L4_COMPRESSED \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1, 6, 2, 1)
+
+#define DRM_FORMAT_MOD_SYNA_V4H1_128L128_COMPRESSED \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1, 7, 7, 1)
+
+#define DRM_FORMAT_MOD_SYNA_V4H3P8_128L128_COMPRESSED \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1, 7, 7, 1)
+
#if defined(__cplusplus)
}
#endif
--
2.39.2
[PATCH v7 0/2] Add pixel formats used in Synatpics SoC
Those pixel formats are used in Synaptics's VideoSmart series SoCs, likes VS640, VS680. I just disclose the pixel formats used in the video codecs and display pipeline this time. Actually any device connected to the MTR module could support those tiling and compressed pixel formats. https://synaptics.com/products/multimedia-solutions Changelog: v7: Fixed all warnings and errors for its document. Add its document to GPU tree. v6: Refresh and fix warnings in its document. v5: Moving back the document and rewriting the description. v4: Removed the patches for V4L2, V4L2 would use the drm_fourcc.h . Moving the documents to the mesa project. v3: There was a mistake in format macro. Correcting the description of 64L4 variant modifiers. v2: The DRM modifiers in the first draft is too simple, it can't tell the tiles in group attribute in memory layout. Removing the v4l2 fourcc. Adding a document for the future v4l2 extended fmt. v1: first draft of DRM modifiers Try to put basic tile formats into v4l2 fourcc Hsia-Jun(Randy) Li (1): drm/fourcc: Add Synaptics VideoSmart tiled modifiers Randy Li (1): Documentation/gpu: Add Synaptics tiling formats documentation Documentation/gpu/drivers.rst | 1 + Documentation/gpu/synaptics.rst | 81 + include/uapi/drm/drm_fourcc.h | 75 ++ 3 files changed, 157 insertions(+) create mode 100644 Documentation/gpu/synaptics.rst -- 2.39.2
[PATCH v7 2/2] Documentation/gpu: Add Synaptics tiling formats documentation
Signed-off-by: Randy Li Signed-off-by: Hsia-Jun(Randy) Li --- Documentation/gpu/drivers.rst | 1 + Documentation/gpu/synaptics.rst | 81 + 2 files changed, 82 insertions(+) create mode 100644 Documentation/gpu/synaptics.rst diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index 3a52f48215a3..7e820c93d994 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -18,6 +18,7 @@ GPU Driver Documentation xen-front afbc komeda-kms + synaptics .. only:: subproject and html diff --git a/Documentation/gpu/synaptics.rst b/Documentation/gpu/synaptics.rst new file mode 100644 index ..a3b24c297186 --- /dev/null +++ b/Documentation/gpu/synaptics.rst @@ -0,0 +1,81 @@ +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later + + +Synaptics Tiling + + +The tiling pixel formats in Synpatics Video Smart platform have +many variants. Tiles could form the group of tiles, pixels within +the group (nearest) width and height are stored into tile. +Meanwhile, the tile in a group may not follow dimension layout, +tile could form a small group of tiles, then that (sub)group +of tiles would form a bigger group. We won't describe the dimension +layout inside the group of tiles here. The layout of the group +of tiles is fixed with the group width and height parameters +in the same generation of the platform. + +Compression +=== +The proprietary lossless image compression protocol in Synaptics +could minimizes the amount of data transferred (less memory bandwidth +consumption) between devices. It would usually apply to the tiling +pixel format. + +Each component would request an extra page aligned length buffer +for storing the compression meta data. Also a 32 bytes parameters +set would come with a compression meta data buffer. + +The component here corresponds to a signal type (i.e. Luma, chroma). +They could be encoded into one or multiple metadata planes, but +their compression parameters still would be individual. + +Pixel format modifiers +== +Addition alignment requirement for stride and size of a memory plane +could apply beyond what has been mentioned below. Remember always +negotiating with all the devices in pipeline before allocation. + +.. flat-table:: Synpatics Image Format Modifiers + + * - Identifier +- Fourcc +- Details + + * - DRM_FORMAT_MOD_SYNA_V4H1 +- DRM_FORMAT_NV12 +- The plain uncompressed 8 bits tile format. It sounds similar to + Intel's Y-tile. but it won't take any pixel from the next X direction + in a tile group. The line stride and image height must be aligned to + a multiple of 16. The height of chrominance plane would plus 8. + + * - DRM_FORMAT_MOD_SYNA_V4H3P8 +- DRM_FORMAT_NV15 +- The plain uncompressed 10 bits tile format. It stores pixel in 2D + 3x4 tiles with a 8bits padding to each of tile. Then a tile is in a + 128 bits cache line. + + * - DRM_FORMAT_MOD_SYNA_V4H1_64L4_COMPRESSED +- DRM_FORMAT_NV12 +- Group of tiles and compressed variant of ``DRM_FORMAT_MOD_SYNA_V4H1``. + A group of tiles would contain 64x4 pixels, where a tile has 1x4 + pixel. + + * - DRM_FORMAT_MOD_SYNA_V4H3P8_64L4_COMPRESSED +- DRM_FORMAT_NV15 +- Group of tiles and compressed variant of ``DRM_FORMAT_MOD_SYNA_V4H3P8``. + A group of tiles would contains 48x4 pixels, where a tile has 3x4 pixels + and a 8 bits padding in the end of a tile. A group of tiles would + be 256 bytes. + + * - ``DRM_FORMAT_MOD_SYNA_V4H1_128L128_COMPRESSED`` +- DRM_FORMAT_NV12 +- Group of tiles and compressed variant of ``DRM_FORMAT_MOD_SYNA_V4H1``. + A group of tiles would contain 128x32 pixels, where a tile has 1x4 + pixel. + + * - ``DRM_FORMAT_MOD_SYNA_V4H3P8_128L128_COMPRESSED`` +- DRM_FORMAT_NV15 +- Group of tiles and compressed variant of ``DRM_FORMAT_MOD_SYNA_V4H3P8``. + A group of tiles would contains 96x128 pixels, where a tile has 3x4 pixels + and a 8 bits padding in the end of a tile. A group of tiles would + be 16 KiB. -- 2.39.2
Re: [PATCH v13 01/10] drm/shmem-helper: Switch to reservation lock
On 3/26/23 12:19, Christian König wrote: > Am 25.03.23 um 15:58 schrieb Dmitry Osipenko: >> On 3/15/23 16:46, Dmitry Osipenko wrote: >>> On 3/14/23 05:26, Dmitry Osipenko wrote: @@ -633,7 +605,10 @@ int drm_gem_shmem_mmap(struct drm_gem_shmem_object *shmem, struct vm_area_struct return ret; } + dma_resv_lock(shmem->base.resv, NULL); ret = drm_gem_shmem_get_pages(shmem); + dma_resv_unlock(shmem->base.resv); >>> Intel CI reported locking problem [1] here. It actually was also >>> reported for v12, but I missed that report because of the other noisy >>> reports. >>> >>> [1] >>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114671v2/shard-snb5/igt@prime_vgem@s...@rcs0.html >>> >>> The test does the following: >>> >>> 1. creates vgem >>> 2. export it do dmabuf >>> 3. mmaps dmabuf >>> >>> There is an obvious deadlock there. The DRM code assumes that mmap() is >>> unlocked, while for dma-buf it's locked. I'll see how to fix it for v14. >>> >> Christian, there is a deadlock problem in drm_gem_shmem_mmap() once we >> move drm-shmem to use resv lock. The current dma-buf locking policy >> claims that importer holds the lock for mmap(), but DRM code assumes >> that obj->mmap() handles the locking itself and then the same >> obj->mmap() code path is used by both dma-buf DRM and a usual DRM object >> paths. Hence importer -> dma_buf_mmap_internal()[takes the lock] -> >> exporter -> drm_gem_shmem_mmap()[takes the lock] deadlocks. >> >> I was looking at how to fix it and to me the best option is to change >> the dma-buf locking policy, making exporter responsible for handling the >> resv lock. Changing DRM code mmap lockings might be possible too [moving >> locking to drm_gem_mmap_obj()], but will be very messy and doesn't feel >> intuitive. >> >> Want to get yours thoughts on this before sending out the dma-buf mmap() >> policy-change patch. Does the new mmap() locking policy sound good to >> you? Thanks! > > > IIRC we tried that before and ran into problems. > > dma_buf_mmap() needs to swap the backing file of the VMA and for this > calls fput() on the old file. > > This fput() in turn could (in theory) grab the resv lock as well and > there isn't anything we could do about that. > > Just information from the back of my memory, probably best if you double > check that. Thanks, Christian! The fput() code path will be unlocked with updated locking policy, like it was before. The new locking policy looks goods on my side, don't see anything that needs locking protection from the importer side for mmap(). I'll send the patches, letting intel-ci test them. Will be also easier to discuss it there with the code. -- Best regards, Dmitry
Re: [PATCH 0/3] drm/lima: expose usage statistics via fdinfo
> "df622729ddbf drm/scheduler: track GPU active time per entity" had to > be reverted due to it introducing a use after free. I guess this > patchset now conflicts with the revert. > I do get some build fail message on other branch. Do I need to revert this patchset on drm-misc-next or left to branch maintainer to decide whether to pick this patchset upstream? Regards, Qiang > > > On Mon, Mar 13, 2023 at 11:09 AM Qiang Yu wrote: > > > > > > Patch set is: > > > Reviewed-by: Qiang Yu > > > > > > Looks like drm-misc-next does not contain "df622729ddbf drm/scheduler: > > > track GPU active time per entity" yet. > > > Will apply later. > > > > > > Regards, > > > Qiang > > > > > > On Mon, Mar 13, 2023 at 7:31 AM Erico Nunes wrote: > > > > > > > > Expose lima gp and pp usage stats through fdinfo, following > > > > Documentation/gpu/drm-usage-stats.rst. > > > > Borrowed from these previous implementations: > > > > > > > > "df622729ddbf drm/scheduler: track GPU active time per entity" added > > > > usage time accounting to drm scheduler, which is where the data used > > > > here comes from. > > > > > > > > Then the main implementation is based on these etnaviv commits: > > > > "d306788b6e1b drm/etnaviv: allocate unique ID per drm_file" and > > > > "97804a133c68 drm/etnaviv: export client GPU usage statistics via > > > > fdinfo" > > > > > > > > Also "874442541133 drm/amdgpu: Add show_fdinfo() interface" since lima > > > > has a context manager very similar to amdgpu and all contexts created > > > > (and released) at the ctx_mgr level need to be accounted for. > > > > > > > > Tested with the generic "gputop" tool currently available as patches to > > > > igt, a sample run with this patchset looks like this: > > > > > > > > DRM minor 128 > > > > PID NAME gppp > > > > 4322 glmark2-es2-way |█▊ > > > > ||██ | > > > > 3561weston |▎ ||███▌ > > > > | > > > > 4159 Xwayland |▏ ||▉ > > > > | > > > > 4154 glxgears |▏ ||▎ > > > > | > > > > 3661 firefox |▏ ||▏ > > > > | > > > > > > > > > > > > Erico Nunes (3): > > > > drm/lima: add usage counting method to ctx_mgr > > > > drm/lima: allocate unique id per drm_file > > > > drm/lima: add show_fdinfo for drm usage stats > > > > > > > > drivers/gpu/drm/lima/lima_ctx.c| 30 - > > > > drivers/gpu/drm/lima/lima_ctx.h| 3 +++ > > > > drivers/gpu/drm/lima/lima_device.h | 3 +++ > > > > drivers/gpu/drm/lima/lima_drv.c| 43 +- > > > > drivers/gpu/drm/lima/lima_drv.h| 1 + > > > > 5 files changed, 78 insertions(+), 2 deletions(-) > > > > > > > > -- > > > > 2.39.2 > > > > >
[drm-tip:drm-tip 3/7] drivers/gpu/drm/lima/lima_ctx.c:53:45: error: 'struct drm_sched_entity' has no member named 'elapsed_ns'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 25abf2df726cac2701780b068df74a9c36d60655
commit: 6e744f4032e55f6ea113d5b10906aebbd626e5b7 [3/7] Merge remote-tracking
branch 'drm-misc/drm-misc-next' into drm-tip
config: arm64-buildonly-randconfig-r001-20230402
(https://download.01.org/0day-ci/archive/20230402/202304022108.kfqa3pui-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git remote add drm-tip git://anongit.freedesktop.org/drm/drm-tip
git fetch --no-tags drm-tip drm-tip
git checkout 6e744f4032e55f6ea113d5b10906aebbd626e5b7
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arm64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/gpu/drm/lima/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202304022108.kfqa3pui-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/lima/lima_ctx.c: In function 'lima_ctx_do_release':
>> drivers/gpu/drm/lima/lima_ctx.c:53:45: error: 'struct drm_sched_entity' has
>> no member named 'elapsed_ns'
53 | mgr->elapsed_ns[i] += entity->elapsed_ns;
| ^~
drivers/gpu/drm/lima/lima_ctx.c: In function 'lima_ctx_mgr_usage':
drivers/gpu/drm/lima/lima_ctx.c:125:43: error: 'struct drm_sched_entity' has
no member named 'elapsed_ns'
125 | usage[i] += entity->elapsed_ns;
| ^~
vim +53 drivers/gpu/drm/lima/lima_ctx.c
a1d2a6339961ef Qiang Yu2019-03-09 42
a1d2a6339961ef Qiang Yu2019-03-09 43 static void
lima_ctx_do_release(struct kref *ref)
a1d2a6339961ef Qiang Yu2019-03-09 44 {
a1d2a6339961ef Qiang Yu2019-03-09 45 struct lima_ctx *ctx =
container_of(ref, struct lima_ctx, refcnt);
bccafec957a5c4 Erico Nunes 2023-03-13 46 struct lima_ctx_mgr *mgr =
ctx->mgr;
a1d2a6339961ef Qiang Yu2019-03-09 47 int i;
a1d2a6339961ef Qiang Yu2019-03-09 48
bccafec957a5c4 Erico Nunes 2023-03-13 49 for (i = 0; i < lima_pipe_num;
i++) {
bccafec957a5c4 Erico Nunes 2023-03-13 50 struct
lima_sched_context *context = &ctx->context[i];
bccafec957a5c4 Erico Nunes 2023-03-13 51 struct drm_sched_entity
*entity = &context->base;
bccafec957a5c4 Erico Nunes 2023-03-13 52
bccafec957a5c4 Erico Nunes 2023-03-13 @53 mgr->elapsed_ns[i] +=
entity->elapsed_ns;
bccafec957a5c4 Erico Nunes 2023-03-13 54
a1d2a6339961ef Qiang Yu2019-03-09 55
lima_sched_context_fini(ctx->dev->pipe + i, ctx->context + i);
bccafec957a5c4 Erico Nunes 2023-03-13 56 }
a1d2a6339961ef Qiang Yu2019-03-09 57 kfree(ctx);
a1d2a6339961ef Qiang Yu2019-03-09 58 }
a1d2a6339961ef Qiang Yu2019-03-09 59
:: The code at line 53 was first introduced by commit
:: bccafec957a5c4b22ac29e53a39e82d0a0008348 drm/lima: add usage counting
method to ctx_mgr
:: TO: Erico Nunes
:: CC: Qiang Yu
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH RFC v2 6/6] drm/msm/dsi: Fix calculations for eol_byte_num and pkt_per_line
On 31/03/2023 21:49, Jessica Zhang wrote:
Use the correct calculations for eol_byte_num and pkt_per_line.
Nit: this line duplicates commit subject and thus is mostly useless.
Currently, pkt_per_line is calculated by dividing slice_per_intf by
slice_count. This is incorrect, as slice_per_intf should be divided by
slice_per_pkt, which is not always equivalent to slice_count as it is
possible for there to be multiple soft slices per interface even though
a panel only specifies one slice per packet.
For eol_byte_num, the current calculation describes the size of the
trailing bytes in the line. Change the calculation so that it describes
the number of padding bytes instead.
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH RFC v2 5/6] drm/msm/dsi: Use MSM and DRM DSC helper methods
On 31/03/2023 21:49, Jessica Zhang wrote: Use MSM and DRM DSC helper methods to configure DSC for DSI. Changes in V2: - *_calculate_initial_scale_value --> *_set_initial_scale_value - Split pkt_per_line and eol_byte_num changes to a separate patch - Moved pclk_per_line calculation to hdisplay adjustment in `if (dsc)` block of dsi_update_dsc_timing() Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/dsi/dsi_host.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index 74d38f90398a..b7ab81737473 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -28,6 +28,7 @@ #include "dsi.xml.h" #include "sfpb.xml.h" #include "dsi_cfg.h" +#include "msm_dsc_helper.h" #include "msm_kms.h" #include "msm_gem.h" #include "phy/dsi_phy.h" @@ -848,7 +849,7 @@ static void dsi_update_dsc_timing(struct msm_dsi_host *msm_host, bool is_cmd_mod /* first calculate dsc parameters and then program * compress mode registers */ - slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->slice_width); + slice_per_intf = msm_dsc_get_slice_per_intf(dsc, hdisplay); /* * If slice_count is greater than slice_per_intf @@ -951,7 +952,11 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool is_bonded_dsi) * pulse width same */ h_total -= hdisplay; - hdisplay /= 3; + if (msm_host->mode_flags & MIPI_DSI_MODE_VIDEO) + hdisplay = msm_dsc_get_uncompressed_pclk_per_line(dsc, hdisplay, + dsi_get_bpp(msm_host->format)) / 3; + else + hdisplay /= 3; h_total += hdisplay; ha_end = ha_start + hdisplay; This chunk changes the calculated value (two other are mere updates to use new functions). Please move it to a separate patch, add proper description/justification and possibly a Fixes tag, if the original code was incorrect. } @@ -1759,7 +1764,7 @@ static int dsi_populate_dsc_params(struct msm_dsi_host *msm_host, struct drm_dsc return ret; } - dsc->initial_scale_value = 32; + drm_dsc_set_initial_scale_value(dsc); dsc->line_buf_depth = dsc->bits_per_component + 1; return drm_dsc_compute_rc_parameters(dsc); -- With best wishes Dmitry
Re: [PATCH RFC v2 4/6] drm/msm/dpu: Fix slice_last_group_size calculation
On 31/03/2023 21:49, Jessica Zhang wrote:
Correct the math for slice_last_group_size so that it matches the
calculations downstream.
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Signed-off-by: Jessica Zhang
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index b952f7d2b7f5..9312a8d7fbd9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -56,7 +56,11 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
if (is_cmd_mode)
initial_lines += 1;
- slice_last_group_size = 3 - (dsc->slice_width % 3);
+ slice_last_group_size = dsc->slice_width % 3;
+
+ if (slice_last_group_size == 0)
+ slice_last_group_size = 3;
Hmm. As I went on checking this against techpack:
mod = dsc->slice_width % 3
mod | techpack | old | your_patch
0 | 2| 3 | 3
1 | 0| 2 | 1
2 | 1| 1 | 2
So, obviously neither old nor new code match the calculations of the
techpack. If we assume that sde_dsc_helper code is correct (which I have
no reasons to doubt), then the proper code should be:
slice_last_group_size = (dsc->slice_width + 2) % 3;
Could you please doublecheck and adjust.
+
data = (initial_lines << 20);
data |= ((slice_last_group_size - 1) << 18);
/* bpp is 6.4 format, 4 LSBs bits are for fractional part */
--
With best wishes
Dmitry
Re: [PATCH RFC v2 3/6] drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness
On 31/03/2023 21:49, Jessica Zhang wrote:
Use the DRM DSC helper for det_thresh_flatness to match downstream
implementation and the DSC spec.
Changes in V2:
- Added a Fixes tag
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH RFC v2 2/6] drm/msm: Add MSM-specific DSC helper methods
On 31/03/2023 21:49, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
- Moved files up to msm/ directory
- Dropped get_comp_ratio() helper
- Used drm_int2fixp() to convert to integers to fp
- Style changes to improve readability
- Dropped unused bpp variable in msm_dsc_get_dce_bytes_per_line()
- Changed msm_dsc_get_slice_per_intf() to a static inline method
- Dropped last division step of msm_dsc_get_pclk_per_line() and changed
method name accordingly
- Changed DSC_BPP macro to drm_dsc_get_bpp_int() helper method
- Fixed some math issues caused by passing in incorrect types to
drm_fixed methods in get_bytes_per_soft_slice()
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/msm_dsc_helper.c | 53
drivers/gpu/drm/msm/msm_dsc_helper.h | 42
3 files changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7274c41228ed..b814fc80e2d5 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -94,6 +94,7 @@ msm-y += \
msm_atomic_tracepoints.o \
msm_debugfs.o \
msm_drv.o \
+ msm_dsc_helper.o \
msm_fb.o \
msm_fence.o \
msm_gem.o \
diff --git a/drivers/gpu/drm/msm/msm_dsc_helper.c
b/drivers/gpu/drm/msm/msm_dsc_helper.c
new file mode 100644
index ..60b73e17e6eb
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_dsc_helper.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#include
+#include
+#include
+
+#include "msm_drv.h"
+#include "msm_dsc_helper.h"
+
+static s64 get_bytes_per_soft_slice(struct drm_dsc_config *dsc, int
intf_width, u32 src_bpp)
intf_width is unused
+{
+ int bpp = msm_dsc_get_bpp_int(dsc);
+ s64 numerator_fp, denominator_fp;
+ s64 comp_ratio_fp = drm_fixp_from_fraction(src_bpp, bpp);
+
+ numerator_fp = drm_int2fixp(dsc->slice_width * 3);
You have lost dsc->bits_per_component here.
+ denominator_fp = drm_fixp_from_fraction(comp_ratio_fp * 8,
drm_int2fixp(bpp));
denominator_fp = drm_fixp_from_fraction(src_bpp * 8, bpp);
+
+ return drm_fixp_div(numerator_fp, denominator_fp);
+}
+
+u32 msm_dsc_get_eol_byte_num(struct drm_dsc_config *dsc, int intf_width, u32
src_bpp)
+{
+ u32 bytes_per_soft_slice, extra_eol_bytes, bytes_per_intf;
+ s64 bytes_per_soft_slice_fp;
+ int slice_per_intf = msm_dsc_get_slice_per_intf(dsc, intf_width);
+
+ bytes_per_soft_slice_fp = get_bytes_per_soft_slice(dsc, intf_width,
src_bpp);
+ bytes_per_soft_slice = drm_fixp2int_ceil(bytes_per_soft_slice_fp);
+
+ bytes_per_intf = bytes_per_soft_slice * slice_per_intf;
+ extra_eol_bytes = bytes_per_intf % 3;
+ if (extra_eol_bytes != 0)
+ extra_eol_bytes = 3 - extra_eol_bytes;
I become confused here when I checked eol_bytes in the display techpack.
I see that for DP the dp_panel_dsc_pclk_param_calc() calculates
dsc->eol_bytes_num in this way, the size to pad dsc_byte_count *
slice_per_intf to 3 bytes.
However, for DSI this is a simple as total_bytes_per_intf % 3 , so it is
not a padding, but a length of the last chunk.
Could you please clarify? If the techpack code is correct, I'd prefer if
we return last chunk size here and calculate the padding length in the
DP driver.
+
+ return extra_eol_bytes;
+}
+
+int msm_dsc_get_uncompressed_pclk_per_line(struct drm_dsc_config *dsc, int
intf_width, u32 src_bpp)
Basing on Abhinav's description ("pclk_per_line can be only per
interface") would it better be named as
msm_dsc_get_uncompressed_pclk_per_intf() ? or
msm_dsc_get_uncompressed_pclk_for_intf() ?
BTW: if get_bytes_per_soft_slice() doesn't use intf_width, we can
probably drop it here too.
+{
+ s64 data_width;
+
+ if (!dsc->slice_width || (intf_width < dsc->slice_width))
+ return -EINVAL;
Error code is not validated at dsi_timing_setup. I'd suggest moving
error checks there and dropping the error handling here. If
dsc->slice_width is not set, we should stop much earlier than
drm_bridge's pre_enable() callback.
+
+ data_width = drm_fixp_mul(dsc->slice_count,
+ get_bytes_per_soft_slice(dsc, intf_width, src_bpp));
+
+ return drm_fixp2int_ceil(data_width);
+}
diff --git a/drivers/gpu/drm/msm/msm_dsc_helper.h
b/drivers/gpu/drm/msm/msm_dsc_helper.h
new file mode 100644
index ..743cd324b7d9
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_dsc_helper.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#ifndef MSM_DSC_HELPER_H_
+#define MSM_DSC_HELPER_H_
+
+#include
+#include
+
+/*
+ * Helper methods fo
Re: [PATCH 0/3] drm/lima: expose usage statistics via fdinfo
Am Sonntag, dem 02.04.2023 um 18:22 +0800 schrieb Qiang Yu: > Applied to drm-misc-next. > "df622729ddbf drm/scheduler: track GPU active time per entity" had to be reverted due to it introducing a use after free. I guess this patchset now conflicts with the revert. Regards, Lucas > On Mon, Mar 13, 2023 at 11:09 AM Qiang Yu wrote: > > > > Patch set is: > > Reviewed-by: Qiang Yu > > > > Looks like drm-misc-next does not contain "df622729ddbf drm/scheduler: > > track GPU active time per entity" yet. > > Will apply later. > > > > Regards, > > Qiang > > > > On Mon, Mar 13, 2023 at 7:31 AM Erico Nunes wrote: > > > > > > Expose lima gp and pp usage stats through fdinfo, following > > > Documentation/gpu/drm-usage-stats.rst. > > > Borrowed from these previous implementations: > > > > > > "df622729ddbf drm/scheduler: track GPU active time per entity" added > > > usage time accounting to drm scheduler, which is where the data used > > > here comes from. > > > > > > Then the main implementation is based on these etnaviv commits: > > > "d306788b6e1b drm/etnaviv: allocate unique ID per drm_file" and > > > "97804a133c68 drm/etnaviv: export client GPU usage statistics via > > > fdinfo" > > > > > > Also "874442541133 drm/amdgpu: Add show_fdinfo() interface" since lima > > > has a context manager very similar to amdgpu and all contexts created > > > (and released) at the ctx_mgr level need to be accounted for. > > > > > > Tested with the generic "gputop" tool currently available as patches to > > > igt, a sample run with this patchset looks like this: > > > > > > DRM minor 128 > > > PID NAME gppp > > > 4322 glmark2-es2-way |█▊ ||██ > > > | > > > 3561weston |▎ ||███▌ > > > | > > > 4159 Xwayland |▏ ||▉ > > > | > > > 4154 glxgears |▏ ||▎ > > > | > > > 3661 firefox |▏ ||▏ > > > | > > > > > > > > > Erico Nunes (3): > > > drm/lima: add usage counting method to ctx_mgr > > > drm/lima: allocate unique id per drm_file > > > drm/lima: add show_fdinfo for drm usage stats > > > > > > drivers/gpu/drm/lima/lima_ctx.c| 30 - > > > drivers/gpu/drm/lima/lima_ctx.h| 3 +++ > > > drivers/gpu/drm/lima/lima_device.h | 3 +++ > > > drivers/gpu/drm/lima/lima_drv.c| 43 +- > > > drivers/gpu/drm/lima/lima_drv.h| 1 + > > > 5 files changed, 78 insertions(+), 2 deletions(-) > > > > > > -- > > > 2.39.2 > > >
Re: [PATCH 3/3] drm: sun4i: calculate proper DCLK rate for DSI
Hi Roman,
On 2023-03-31 at 13:02:45 +0200, Roman Beranek wrote:
> In DSI mode, TCON0's data clock is required to run at 1/4 the per-lane
> bit rate.
>
> Signed-off-by: Roman Beranek
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 36 +-
> 1 file changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index eec26b1faa4b..b263de7a8237 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -291,18 +291,6 @@ static int sun4i_tcon_get_clk_delay(const struct
> drm_display_mode *mode,
> return delay;
> }
>
> -static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> - const struct drm_display_mode *mode)
> -{
> - /* Configure the dot clock */
> - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> -
> - /* Set the resolution */
> - regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> - SUN4I_TCON0_BASIC0_X(mode->crtc_hdisplay) |
> - SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
> -}
> -
> static void sun4i_tcon0_mode_set_dithering(struct sun4i_tcon *tcon,
> const struct drm_connector
> *connector)
> {
> @@ -367,10 +355,18 @@ static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon
> *tcon,
> u32 block_space, start_delay;
> u32 tcon_div;
>
> + /*
> + * dclk is required to run at 1/4 the DSI per-lane bit rate.
> + */
> tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> + clk_set_rate(tcon->dclk, mode->crtc_clock * 1000 * (bpp / lanes)
> + / SUN6I_DSI_TCON_DIV);
When apply this to drm-next my panel stays dark. I haven't figured out
yet why, though. The other two patches in this series work fine, i.e.
they have no effect as they are just a refactoring.
I'm testing this on my pinephone. It's the same with the patch I
submitted. For whatever reason, it no longer works on drm-next.
At the time I'm writing this, drm-next is at 82bbec189ab3 "Merge
v6.3-rc4 into drm-next".
Does it work for you? And if so, on which commit are you basing this
series?
Thanks,
Frank
>
> - sun4i_tcon0_mode_set_common(tcon, mode);
> + /* Set the resolution */
> + regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> + SUN4I_TCON0_BASIC0_X(mode->crtc_hdisplay) |
> + SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
>
> /* Set dithering if needed */
> sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
> @@ -438,7 +434,12 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
> *tcon,
>
> tcon->dclk_min_div = 7;
> tcon->dclk_max_div = 7;
> - sun4i_tcon0_mode_set_common(tcon, mode);
> + clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> +
> + /* Set the resolution */
> + regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> + SUN4I_TCON0_BASIC0_X(mode->crtc_hdisplay) |
> + SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
>
> /* Set dithering if needed */
> sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
> @@ -515,7 +516,12 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
> *tcon,
>
> tcon->dclk_min_div = tcon->quirks->dclk_min_div;
> tcon->dclk_max_div = 127;
> - sun4i_tcon0_mode_set_common(tcon, mode);
> + clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> +
> + /* Set the resolution */
> + regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> + SUN4I_TCON0_BASIC0_X(mode->crtc_hdisplay) |
> + SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
>
> /* Set dithering if needed */
> sun4i_tcon0_mode_set_dithering(tcon, connector);
--
--
Frank Oltmanns
Re: [PATCH 0/3] drm/lima: expose usage statistics via fdinfo
Applied to drm-misc-next. On Mon, Mar 13, 2023 at 11:09 AM Qiang Yu wrote: > > Patch set is: > Reviewed-by: Qiang Yu > > Looks like drm-misc-next does not contain "df622729ddbf drm/scheduler: > track GPU active time per entity" yet. > Will apply later. > > Regards, > Qiang > > On Mon, Mar 13, 2023 at 7:31 AM Erico Nunes wrote: > > > > Expose lima gp and pp usage stats through fdinfo, following > > Documentation/gpu/drm-usage-stats.rst. > > Borrowed from these previous implementations: > > > > "df622729ddbf drm/scheduler: track GPU active time per entity" added > > usage time accounting to drm scheduler, which is where the data used > > here comes from. > > > > Then the main implementation is based on these etnaviv commits: > > "d306788b6e1b drm/etnaviv: allocate unique ID per drm_file" and > > "97804a133c68 drm/etnaviv: export client GPU usage statistics via > > fdinfo" > > > > Also "874442541133 drm/amdgpu: Add show_fdinfo() interface" since lima > > has a context manager very similar to amdgpu and all contexts created > > (and released) at the ctx_mgr level need to be accounted for. > > > > Tested with the generic "gputop" tool currently available as patches to > > igt, a sample run with this patchset looks like this: > > > > DRM minor 128 > > PID NAME gppp > > 4322 glmark2-es2-way |█▊ ||██ > > | > > 3561weston |▎ ||███▌ > > | > > 4159 Xwayland |▏ ||▉ > > | > > 4154 glxgears |▏ ||▎ > > | > > 3661 firefox |▏ ||▏ > > | > > > > > > Erico Nunes (3): > > drm/lima: add usage counting method to ctx_mgr > > drm/lima: allocate unique id per drm_file > > drm/lima: add show_fdinfo for drm usage stats > > > > drivers/gpu/drm/lima/lima_ctx.c| 30 - > > drivers/gpu/drm/lima/lima_ctx.h| 3 +++ > > drivers/gpu/drm/lima/lima_device.h | 3 +++ > > drivers/gpu/drm/lima/lima_drv.c| 43 +- > > drivers/gpu/drm/lima/lima_drv.h| 1 + > > 5 files changed, 78 insertions(+), 2 deletions(-) > > > > -- > > 2.39.2 > >
Re: [PATCH] drm/lima/lima_drv: Add missing unwind goto in lima_pdev_probe()
Applied to drm-misc-next.
On Tue, Mar 14, 2023 at 2:22 PM Qiang Yu wrote:
>
> Reviewed-by: Qiang Yu
>
> On Tue, Mar 14, 2023 at 1:27 PM Harshit Mogalapalli
> wrote:
> >
> > Smatch reports:
> > drivers/gpu/drm/lima/lima_drv.c:396 lima_pdev_probe() warn:
> > missing unwind goto?
> >
> > Store return value in err and goto 'err_out0' which has
> > lima_sched_slab_fini() before returning.
> >
> > Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
> > Signed-off-by: Harshit Mogalapalli
> > ---
> > Only compile tested.
> > ---
> > drivers/gpu/drm/lima/lima_drv.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/lima/lima_drv.c
> > b/drivers/gpu/drm/lima/lima_drv.c
> > index 7b8d7178d09a..39cab4a55f57 100644
> > --- a/drivers/gpu/drm/lima/lima_drv.c
> > +++ b/drivers/gpu/drm/lima/lima_drv.c
> > @@ -392,8 +392,10 @@ static int lima_pdev_probe(struct platform_device
> > *pdev)
> >
> > /* Allocate and initialize the DRM device. */
> > ddev = drm_dev_alloc(&lima_drm_driver, &pdev->dev);
> > - if (IS_ERR(ddev))
> > - return PTR_ERR(ddev);
> > + if (IS_ERR(ddev)) {
> > + err = PTR_ERR(ddev);
> > + goto err_out0;
> > + }
> >
> > ddev->dev_private = ldev;
> > ldev->ddev = ddev;
> > --
> > 2.38.1
> >
[Bug 217278] ast 0000:03:00.0: PM: **** DPM device timeout **** during S4 resuming
https://bugzilla.kernel.org/show_bug.cgi?id=217278 The Linux kernel's regression tracker (Thorsten Leemhuis) (regressi...@leemhuis.info) changed: What|Removed |Added CC|regressi...@leemhuis.info | --- Comment #7 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressi...@leemhuis.info) --- Then it sounds like this is not a regression and thus nothing for me. But FWIW, I doubt your report here will reach the maintainers of the driver. You might want to contact them by mail to Joel Stanley , CCed to linux-asp...@lists.ozlabs.org -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
