Re: [PATCH v3] drm/msm/dpu: Reapply CTM if modeset is needed
On 19/01/2023 01:38, Jessica Zhang wrote: Add a !drm_atomic_crtc_needs_modeset() check to _dpu_crtc_setup_cp_blocks() so that CTM is reapplied if the LM/DSPP blocks were reallocated during modeset or after a suspend/resume. Changes in V2: - Fixed commit message Changes in V3: - Added mention of suspend/resume case back to commit message Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/23 Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: pr-tracker-bot for drm subsystem?
Konstantin? On Thu, 15 Sep 2022, Jani Nikula wrote: > Hey all, I'd be interested in having the pr-tracker-bot [1] set up for > the drm subsystem, following the dri-devel mailing list [2] and > notifying when the pull requests have been merged to either the drm-next > or drm-fixes branches of the main drm repository [3]. > > What would this require in terms of the tracker bot code? > > Is the idea that the service could be expanded to cover subsystems > instead of just LKML and mainline, or would all subsystems have to set > it up for themselves with their own cron jobs on their own servers? > > Other considerations? > > > BR, > Jani. > > > [1] https://korg.docs.kernel.org/prtracker.html > [2] https://lists.freedesktop.org/mailman/listinfo/dri-devel > [3] https://cgit.freedesktop.org/drm/drm/ -- Jani Nikula, Intel Open Source Graphics Center
[RESEND PATCHv2 2/2] i915/display/dp: SDP CRC16 for 128b132b link layer
Enable SDP error detection configuration, this will set CRC16 in 128b/132b link layer. For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is added to enable/disable SDP CRC applicable for DP2.0 only, but the default value of this bit will enable CRC16 in 128b/132b hence skipping this write. Corrective actions on SDP corruption is yet to be defined. v2: Moved the CRC enable to link training init(Jani N) Signed-off-by: Arun R Murthy --- .../gpu/drm/i915/display/intel_dp_link_training.c| 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 3d3efcf02011..7064e465423b 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -1453,4 +1453,16 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp, if (!passed) intel_dp_schedule_fallback_link_training(intel_dp, crtc_state); + + /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */ + if (intel_dp_is_uhbr(crtc_state) && passed) + drm_dp_dpcd_writeb(&intel_dp->aux, + DP_SDP_ERROR_DETECTION_CONFIGURATION, + DP_SDP_CRC16_128B132B_EN); + /* +* VIDEO_DIP_CTL register bit 31 should be set to '0' to not +* disable SDP CRC. This is applicable for Display version 13. +* Default value of bit 31 is '0' hence discarding the write +*/ + /* TODO: Corrective actions on SDP corruption yet to be defined */ } -- 2.25.1
[PATCHv2 0/2] DP2.0 SDP CRC16 for 128/132b link layer
*** BLURB HERE *** Arun R Murthy (2): drm: Add SDP Error Detection Configuration Register i915/display/dp: SDP CRC16 for 128b132b link layer .../gpu/drm/i915/display/intel_dp_link_training.c| 12 include/drm/display/drm_dp.h | 3 +++ 2 files changed, 15 insertions(+) -- 2.25.1
[RESEND PATCHv2 1/2] drm: Add SDP Error Detection Configuration Register
DP2.0 E11 defines a new register to facilitate SDP error detection by a 128B/132B capable DPRX device. v2: Update the macro name to reflect the DP spec(Harry) Signed-off-by: Arun R Murthy Reviewed-by: Harry Wentland --- include/drm/display/drm_dp.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h index 632376c291db..358db4a9f167 100644 --- a/include/drm/display/drm_dp.h +++ b/include/drm/display/drm_dp.h @@ -692,6 +692,9 @@ # define DP_FEC_LANE_2_SELECT (2 << 4) # define DP_FEC_LANE_3_SELECT (3 << 4) +#define DP_SDP_ERROR_DETECTION_CONFIGURATION 0x121 /* DP 2.0 E11 */ +#define DP_SDP_CRC16_128B132B_EN BIT(0) + #define DP_AUX_FRAME_SYNC_VALUE0x15c /* eDP 1.4 */ # define DP_AUX_FRAME_SYNC_VALID (1 << 0) -- 2.25.1
[RESEND][PATCH] MAINTAINERS: Add Sumit Semwal and Yongqin Liu as reviwers for kirin DRM driver
I no longer have access to the HiKey boards, so while I'm happy to review code, I wanted to add Sumit and Yongqin to the reviewers list so they would get CC'ed on future changes and would be able to have a chance to validate and provide Tested-by: tags Cc: Xinliang Liu Cc: Tian Tao Cc: Yongqin Liu Cc: Sumit Semwal Cc: kernel-t...@android.com Cc: dri-devel@lists.freedesktop.org Signed-off-by: John Stultz --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 42fc47c6edfd..82df566e6925 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7007,9 +7007,11 @@ F: drivers/gpu/drm/gma500/ DRM DRIVERS FOR HISILICON M: Xinliang Liu M: Tian Tao -R: John Stultz R: Xinwei Kong R: Chen Feng +R: Sumit Semwal +R: Yongqin Liu +R: John Stultz L: dri-devel@lists.freedesktop.org S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc -- 2.39.1.405.gd4c25cc71f-goog
Re: [PATCH v3] drm: kirin: Enable COMPILE_TEST
On Thu, Jan 19, 2023 at 11:01 AM Sean Anderson wrote:
>
> Make various small changes to allow compile-testing on other arches.
> This is helpful to allow testing changes to 32-bit arm drivers in the
> same build.
>
> The primary changes is to use macros for 64-bit divisions and shifts,
> but we also need some other fixes to deal with larger constants and
> differences in includes.
>
> Signed-off-by: Sean Anderson
No objection from me (though I'm not sure I really see the benefit of
test building this driver on 32bit).
I no longer have hardware to test with, so adding YongQin and Amit.
So maybe a tentative Acked-by: John Stultz
thanks
-john
> ---
>
> Changes in v3:
> - Include io.h for readl/writel
>
> Changes in v2:
> - Use BIT_ULL
>
> drivers/gpu/drm/hisilicon/kirin/Kconfig | 2 +-
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 10 +-
> drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h| 2 ++
> drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 2 +-
> 4 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig
> b/drivers/gpu/drm/hisilicon/kirin/Kconfig
> index c5265675bf0c..0772f79567ef 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/Kconfig
> +++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config DRM_HISI_KIRIN
> tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
> - depends on DRM && OF && ARM64
> + depends on DRM && OF && (ARM64 || COMPILE_TEST)
> select DRM_KMS_HELPER
> select DRM_GEM_DMA_HELPER
> select DRM_MIPI_DSI
> diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> index d9978b79828c..1cfeffefd4b4 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> @@ -157,8 +157,8 @@ static u32 dsi_calc_phy_rate(u32 req_kHz, struct
> mipi_phy_params *phy)
> q_pll = 0x10 >> (7 - phy->hstx_ckg_sel);
>
> temp = f_kHz * (u64)q_pll * (u64)ref_clk_ps;
> - m_n_int = temp / (u64)10;
> - m_n = (temp % (u64)10) / (u64)1;
> + m_n_int = div_u64_rem(temp, 10, &m_n);
> + m_n /= 1;
>
> if (m_n_int % 2 == 0) {
> if (m_n * 6 >= 50) {
> @@ -229,8 +229,8 @@ static u32 dsi_calc_phy_rate(u32 req_kHz, struct
> mipi_phy_params *phy)
> phy->pll_fbd_div5f = 1;
> }
>
> - f_kHz = (u64)10 * (u64)m_pll /
> - ((u64)ref_clk_ps * (u64)n_pll * (u64)q_pll);
> + f_kHz = div64_u64((u64)10 * (u64)m_pll,
> + (u64)ref_clk_ps * (u64)n_pll * (u64)q_pll);
>
> if (f_kHz >= req_kHz)
> break;
> @@ -490,7 +490,7 @@ static void dsi_set_mode_timing(void __iomem *base,
> hsa_time = (hsw * lane_byte_clk_kHz) / pixel_clk_kHz;
> hbp_time = (hbp * lane_byte_clk_kHz) / pixel_clk_kHz;
> tmp = (u64)htot * (u64)lane_byte_clk_kHz;
> - hline_time = DIV_ROUND_UP(tmp, pixel_clk_kHz);
> + hline_time = DIV64_U64_ROUND_UP(tmp, pixel_clk_kHz);
>
> /* all specified in byte-lane clocks */
> writel(hsa_time, base + VID_HSA_TIME);
> diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
> b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
> index d79fc031e53d..a87d1135856f 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
> +++ b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
> @@ -7,6 +7,8 @@
> #ifndef __DW_DSI_REG_H__
> #define __DW_DSI_REG_H__
>
> +#include
> +
> #define MASK(x)(BIT(x) - 1)
>
> /*
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
> b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
> index be9e789c2d04..36f923cc7594 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
> @@ -10,7 +10,7 @@
> /*
> * ADE Registers
> */
> -#define MASK(x)(BIT(x) - 1)
> +#define MASK(x)(BIT_ULL(x) - 1)
>
> #define ADE_CTRL 0x0004
> #define FRM_END_START_OFST 0
> --
> 2.35.1.1320.gc452695387.dirty
>
[RESEND PATCHv2 2/2] i915/display/dp: SDP CRC16 for 128b132b link layer
Enable SDP error detection configuration, this will set CRC16 in 128b/132b link layer. For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is added to enable/disable SDP CRC applicable for DP2.0 only, but the default value of this bit will enable CRC16 in 128b/132b hence skipping this write. Corrective actions on SDP corruption is yet to be defined. v2: Moved the CRC enable to link training init(Jani N) Signed-off-by: Arun R Murthy --- .../gpu/drm/i915/display/intel_dp_link_training.c| 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 3d3efcf02011..7064e465423b 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -1453,4 +1453,16 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp, if (!passed) intel_dp_schedule_fallback_link_training(intel_dp, crtc_state); + + /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */ + if (intel_dp_is_uhbr(crtc_state) && passed) + drm_dp_dpcd_writeb(&intel_dp->aux, + DP_SDP_ERROR_DETECTION_CONFIGURATION, + DP_SDP_CRC16_128B132B_EN); + /* +* VIDEO_DIP_CTL register bit 31 should be set to '0' to not +* disable SDP CRC. This is applicable for Display version 13. +* Default value of bit 31 is '0' hence discarding the write +*/ + /* TODO: Corrective actions on SDP corruption yet to be defined */ } -- 2.25.1
[PATCHv2 1/2] drm: Add SDP Error Detection Configuration Register
DP2.0 E11 defines a new register to facilitate SDP error detection by a 128B/132B capable DPRX device. v2: Update the macro name to reflect the DP spec(Harry) Signed-off-by: Arun R Murthy Reviewed-by: Harry Wentland --- include/drm/display/drm_dp.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h index 632376c291db..358db4a9f167 100644 --- a/include/drm/display/drm_dp.h +++ b/include/drm/display/drm_dp.h @@ -692,6 +692,9 @@ # define DP_FEC_LANE_2_SELECT (2 << 4) # define DP_FEC_LANE_3_SELECT (3 << 4) +#define DP_SDP_ERROR_DETECTION_CONFIGURATION 0x121 /* DP 2.0 E11 */ +#define DP_SDP_CRC16_128B132B_EN BIT(0) + #define DP_AUX_FRAME_SYNC_VALUE0x15c /* eDP 1.4 */ # define DP_AUX_FRAME_SYNC_VALID (1 << 0) -- 2.25.1
Re: [PATCH v2 1/3] drm/msm/mdss: convert UBWC setup to use match data
On Fri, 20 Jan 2023 at 00:54, Abhinav Kumar wrote:
>
>
>
> On 1/17/2023 5:04 PM, Dmitry Baryshkov wrote:
> > To simplify adding new platforms and to make settings more obvious,
> > rewrite the UBWC setup to use the data structure to pass platform config
> > rather than just calling the functions direcly.
> >
> > Signed-off-by: Dmitry Baryshkov
>
> I was reviewing this series and
> https://patchwork.freedesktop.org/series/111732/ together.
>
> More I think about it, it seems like we are duplicating the same values
> here and in the catalog.
>
> Yes, these two are different drivers.
>
> But now that you are adding the UBWC entries here using the compatible
> string so you are creating something like a "catalog" here.
>
> In that case, why dont we remove the entries from dpu catalog and in the
> DPU driver get the parent's match data as we know that the msm_mdss is
> the parent of DPU driver
I should give it a thought, especially since we are trying to clean up
the DPU catalog.
>
> Let me know your thoughts.
>
> > ---
> > drivers/gpu/drm/msm/msm_mdss.c | 181 +++--
> > 1 file changed, 105 insertions(+), 76 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> > index 02646e4bb4cd..799672b88716 100644
> > --- a/drivers/gpu/drm/msm/msm_mdss.c
> > +++ b/drivers/gpu/drm/msm/msm_mdss.c
> > @@ -16,9 +16,6 @@
> > #include "msm_drv.h"
> > #include "msm_kms.h"
> >
> > -/* for DPU_HW_* defines */
> > -#include "disp/dpu1/dpu_hw_catalog.h"
> > -
> > #define HW_REV 0x0
> > #define HW_INTR_STATUS 0x0010
> >
> > @@ -29,6 +26,16 @@
> >
> > #define MIN_IB_BW 4UL /* Min ib vote 400MB */
> >
> > +struct msm_mdss_data {
> > + u32 ubwc_version;
> > + /* can be read from register 0x58 */
> > + u32 ubwc_dec_version;
> > + u32 ubwc_swizzle;
> > + u32 ubwc_static;
> > + u32 highest_bank_bit;
> > + u32 macrotile_mode;
> > +};
> > +
> > struct msm_mdss {
> > struct device *dev;
> >
> > @@ -40,6 +47,7 @@ struct msm_mdss {
> > unsigned long enabled_mask;
> > struct irq_domain *domain;
> > } irq_controller;
> > + const struct msm_mdss_data *mdss_data;
> > struct icc_path *path[2];
> > u32 num_paths;
> > };
> > @@ -182,46 +190,40 @@ static int _msm_mdss_irq_domain_add(struct msm_mdss
> > *msm_mdss)
> > #define UBWC_3_0 0x3000
> > #define UBWC_4_0 0x4000
> >
> > -static void msm_mdss_setup_ubwc_dec_20(struct msm_mdss *msm_mdss,
> > -u32 ubwc_static)
> > +static void msm_mdss_setup_ubwc_dec_20(struct msm_mdss *msm_mdss)
> > {
> > - writel_relaxed(ubwc_static, msm_mdss->mmio + UBWC_STATIC);
> > + const struct msm_mdss_data *data = msm_mdss->mdss_data;
> > +
> > + writel_relaxed(data->ubwc_static, msm_mdss->mmio + UBWC_STATIC);
> > }
> >
> > -static void msm_mdss_setup_ubwc_dec_30(struct msm_mdss *msm_mdss,
> > -unsigned int ubwc_version,
> > -u32 ubwc_swizzle,
> > -u32 highest_bank_bit,
> > -u32 macrotile_mode)
> > +static void msm_mdss_setup_ubwc_dec_30(struct msm_mdss *msm_mdss)
> > {
> > - u32 value = (ubwc_swizzle & 0x1) |
> > - (highest_bank_bit & 0x3) << 4 |
> > - (macrotile_mode & 0x1) << 12;
> > + const struct msm_mdss_data *data = msm_mdss->mdss_data;
> > + u32 value = (data->ubwc_swizzle & 0x1) |
> > + (data->highest_bank_bit & 0x3) << 4 |
> > + (data->macrotile_mode & 0x1) << 12;
> >
> > - if (ubwc_version == UBWC_3_0)
> > + if (data->ubwc_version == UBWC_3_0)
> > value |= BIT(10);
> >
> > - if (ubwc_version == UBWC_1_0)
> > + if (data->ubwc_version == UBWC_1_0)
> > value |= BIT(8);
> >
> > writel_relaxed(value, msm_mdss->mmio + UBWC_STATIC);
> > }
> >
> > -static void msm_mdss_setup_ubwc_dec_40(struct msm_mdss *msm_mdss,
> > -unsigned int ubwc_version,
> > -u32 ubwc_swizzle,
> > -u32 ubwc_static,
> > -u32 highest_bank_bit,
> > -u32 macrotile_mode)
> > +static void msm_mdss_setup_ubwc_dec_40(struct msm_mdss *msm_mdss)
> > {
> > - u32 value = (ubwc_swizzle & 0x7) |
> > - (ubwc_static & 0x1) << 3 |
> > - (highest_bank_bit & 0x7) << 4 |
> > - (macrotile_mode & 0x1) << 12;
> > + const struct msm_mdss_data *data = msm_mdss->mdss_data;
> > + u32 value = (data->ubwc_swizzle & 0x7) |
> > + (data->ubwc_static & 0x1) << 3 |
> > + (data->highest_bank_bit & 0x7) << 4 |
> > + (data->macrotile
Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel
Hi Tomi,
Thank you for taking a look at the patches!
On 17-Jan-23 18:08, Tomi Valkeinen wrote:
On 09/01/2023 18:21, Aradhya Bhatia wrote:
Hi Angelo,
Thanks for taking a look at the patches!
On 03-Jan-23 17:21, AngeloGioacchino Del Regno wrote:
Il 03/01/23 07:46, Aradhya Bhatia ha scritto:
Dual-link LVDS interfaces have 2 links, with even pixels traveling on
one link, and odd pixels on the other. These panels are also generic in
nature, with no documented constraints, much like their single-link
counterparts, "panel-lvds".
Add a new compatible, "panel-dual-lvds", and a dt-binding document for
these panels.
Signed-off-by: Aradhya Bhatia
---
.../display/panel/panel-dual-lvds.yaml | 157
++
MAINTAINERS | 1 +
2 files changed, 158 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
new file mode 100644
index ..88a7aa2410be
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
@@ -0,0 +1,157 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Dual-Link LVDS Display Panel
+
+maintainers:
+ - Aradhya Bhatia
+ - Thierry Reding
+
+description: |
+ A dual-LVDS interface is a dual-link connection with the even pixels
+ traveling on one link, and the odd pixels traveling on the other.
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/display/lvds.yaml/#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - lincolntech,lcd185-101ct
+ - microtips,13-101hieb0hf0-s
+ - const: panel-dual-lvds
+ - const: panel-dual-lvds
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: The sink for first set of LVDS pixels.
+
+ properties:
+ dual-lvds-odd-pixels:
+ type: boolean
+
+ dual-lvds-even-pixels:
+ type: boolean
+
+ oneOf:
+ - required: [dual-lvds-odd-pixels]
One question: why do we need a "panel-dual-lvds" compatible?
A Dual-LVDS panel is a LVDS panel using two ports, hence still a
panel-lvds.
If you're doing this to clearly distinguish, for human readability purposes,
single-link vs dual-link panels, I think that this would still be clear even
if we use panel-lvds alone because dual-link panels, as you wrote in this
binding, does *require* two ports, with "dual-lvds-{odd,even}-pixels"
properties.
Yes, while they are both LVDS based panels the extra LVDS sink in these
panels, and the capability to decode and display the 2 sets of signals
are enough hardware differences that warrant for an addition of a new
compatible.
So... the devicetree node would look like this:
panel {
compatible = "vendor,panel", "panel-lvds";
ports {
port@0 {
.
-> dual-lvds-odd-pixels <-
}
port@1 {
.
-> dual-lvds-even-pixels <-
};
};
};
+ - required: [dual-lvds-even-pixels]
...Though, if you expect dual-lvds panels to get other quirks in the future,
that's a whole different story and you may actually need the panel-dual-lvds
compatible.
Yes, exactly. Even while being non-smart, there are going to be more
quirks in future. And it would be better if they have their own
compatible/binding, and are not getting appended in an ever-growing
if-else ladder. :)
I can imagine a panel which you can use with a single LVDS link if the
clock is high enough, or two LVDS links if the clock has to be lower. Is
that a dual-lvds panel? =)
Hmm, I can see what you are saying here.
If one wants to run a dual-link panel, with 1 link (given enough clock
frequency), then the bindings here will *not* allow for a single port
with the odd/even properties absent.
In such a case, the compatible will indeed need to be changed to
"panel-lvds".
While it does feel a tad bit odd, I believe it is still worth
maintaining the clarity and HW differences between the single and dual
link panels. :)
But probably that situation is no different than a panel that can work
with DSI or DPI input.
Still, I'm agree with Angelo in that a new compatible string for dual
link lvds feels a bit odd. That said, it's possible the panel-lvds > bindings might get rather confusing. So I don't have a strong feeling
here.
Regards
Aradhya
[PATCH 14/16] drm/i915/dp: Iterate over output bpp with fractional step size
This patch adds support to iterate over compressed output bpp as per the
fractional step, supported by DP sink.
v2:
-Avoid ending up with compressed bpp, same as pipe bpp. (Stan)
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 47 +++--
1 file changed, 28 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3d08acb4505a..8dede5969af5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1476,10 +1476,11 @@ static int intel_dp_dsc_compute_params(struct
intel_encoder *encoder,
return drm_dsc_compute_rc_parameters(vdsc_cfg);
}
-static bool is_dsc_bw_sufficient(int link_rate, int lane_count, int
compressed_bpp,
+static bool is_dsc_bw_sufficient(int link_rate, int lane_count, int
compressed_bppx16,
const struct drm_display_mode *adjusted_mode)
{
- int mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
compressed_bpp);
+ int mode_rate =
DIV_ROUND_UP(intel_dp_link_required(adjusted_mode->crtc_clock,
+ compressed_bppx16),
16);
int link_avail = intel_dp_max_data_rate(link_rate, lane_count);
return mode_rate <= link_avail;
@@ -1489,7 +1490,7 @@ static int dsc_compute_link_config(struct intel_dp
*intel_dp,
struct intel_crtc_state *pipe_config,
struct link_config_limits *limits,
int pipe_bpp,
- u16 compressed_bpp)
+ u16 compressed_bppx16)
{
const struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
@@ -1513,11 +1514,11 @@ static int dsc_compute_link_config(struct intel_dp
*intel_dp,
adjusted_mode->crtc_hdisplay,
pipe_config->bigjoiner_pipes,
pipe_bpp,
64);
- if (compressed_bpp > dsc_max_bpp)
+ if (compressed_bppx16 > dsc_max_bpp << 16)
continue;
if (!is_dsc_bw_sufficient(link_rate, lane_count,
- compressed_bpp,
adjusted_mode))
+ compressed_bppx16,
adjusted_mode))
continue;
pipe_config->lane_count = lane_count;
@@ -1580,33 +1581,41 @@ static int dsc_compute_compressed_bpp(struct intel_dp
*intel_dp,
int pipe_bpp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- u16 compressed_bpp;
- int dsc_min_bpp, dsc_src_max_bpp, dsc_sink_max_bpp, dsc_max_bpp;
+ u16 compressed_bppx16;
+ int dsc_min_bppx16, dsc_src_max_bppx16, dsc_sink_max_bppx16,
dsc_max_bppx16;
+ u8 bppx16_incr = drm_dp_dsc_sink_bpp_incr(intel_dp->dsc_dpcd);
+ u8 bppx16_step;
int ret;
- dsc_min_bpp = max(dsc_min_compressed_bppx16(pipe_config) >> 4, 8);
+ if (DISPLAY_VER(dev_priv) < 14 || bppx16_incr <= 1)
+ bppx16_step = 16;
+ else
+ bppx16_step = 16 / bppx16_incr;
+
+ dsc_min_bppx16 = max((int)dsc_min_compressed_bppx16(pipe_config), 8 <<
4);
if (DISPLAY_VER(dev_priv) <= 12)
- dsc_src_max_bpp = 23;
+ dsc_src_max_bppx16 = 23 << 4;
else
- dsc_src_max_bpp = 27;
- dsc_sink_max_bpp = dsc_max_sink_compressed_bppx16(intel_dp->dsc_dpcd,
- pipe_config, pipe_bpp
/ 3) >> 4;
+ dsc_src_max_bppx16 = 27 << 4;
+ dsc_sink_max_bppx16 = dsc_max_sink_compressed_bppx16(intel_dp->dsc_dpcd,
+pipe_config,
pipe_bpp / 3);
- dsc_max_bpp = dsc_sink_max_bpp ? min(dsc_sink_max_bpp, dsc_src_max_bpp)
: dsc_src_max_bpp;
+ dsc_max_bppx16 = dsc_sink_max_bppx16 ?
+ min(dsc_sink_max_bppx16, dsc_src_max_bppx16) :
dsc_src_max_bppx16;
/* Compressed BPP should be less than the Input DSC bpp */
- dsc_max_bpp = min(dsc_max_bpp, pipe_bpp - 1);
+ dsc_max_bppx16 = min(dsc_max_bppx16, (pipe_bpp << 4) - bppx16_step);
- for (compressed_bpp = dsc_max_bpp;
-compressed_bpp >= dsc_min_bpp;
-compressed_bpp--) {
+ for (compressed_bppx16 = dsc_max_bppx16;
+compressed_bppx16 >= dsc_min_bppx16;
+compressed_bppx16 -= bppx16_step) {
ret = dsc_compute_link_config(intel_dp,
pipe_config,
[PATCH 12/16] drm/display/dp: Add helper function to get DSC bpp prescision
Add helper to get the DSC bits_per_pixel precision for the DP sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/display/drm_dp_helper.c | 27 +
include/drm/display/drm_dp_helper.h | 1 +
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6..db3288af4032 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2323,6 +2323,33 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct
drm_dp_desc *desc,
}
EXPORT_SYMBOL(drm_dp_read_desc);
+/**
+ * drm_dp_dsc_sink_bpp_incr() - Get bits per pixel increment
+ * @dsc_dpcd: DSC capabilities from DPCD
+ *
+ * Returns the bpp precision supported by the DP sink.
+ */
+u8 drm_dp_dsc_sink_bpp_incr(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
+{
+ u8 bpp_increment_dpcd = dsc_dpcd[DP_DSC_BITS_PER_PIXEL_INC -
DP_DSC_SUPPORT];
+
+ switch (bpp_increment_dpcd) {
+ case DP_DSC_BITS_PER_PIXEL_1_16:
+ return 16;
+ case DP_DSC_BITS_PER_PIXEL_1_8:
+ return 8;
+ case DP_DSC_BITS_PER_PIXEL_1_4:
+ return 4;
+ case DP_DSC_BITS_PER_PIXEL_1_2:
+ return 2;
+ case DP_DSC_BITS_PER_PIXEL_1_1:
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_dsc_sink_bpp_incr);
+
/**
* drm_dp_dsc_sink_max_slice_count() - Get the max slice count
* supported by the DSC sink.
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index ab55453f2d2c..0a0306b2e829 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -164,6 +164,7 @@ drm_dp_is_branch(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
}
/* DP/eDP DSC support */
+u8 drm_dp_dsc_sink_bpp_incr(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
u8 drm_dp_dsc_sink_max_slice_count(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
bool is_edp);
u8 drm_dp_dsc_sink_line_buf_depth(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
--
2.25.1
[PATCH 13/16] drm/i915/dsc/mtl: Add support for fractional bpp
From: Vandita Kulkarni
Consider the fractional bpp while reading the qp values.
Signed-off-by: Vandita Kulkarni
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_qp_tables.c | 3 ---
drivers/gpu/drm/i915/display/intel_vdsc.c | 12 +---
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_qp_tables.c
b/drivers/gpu/drm/i915/display/intel_qp_tables.c
index 6f8e4ec5c0fb..a0094287dc81 100644
--- a/drivers/gpu/drm/i915/display/intel_qp_tables.c
+++ b/drivers/gpu/drm/i915/display/intel_qp_tables.c
@@ -21,9 +21,6 @@
* These qp tables are as per the C model
* and it has the rows pointing to bpps which increment
* in steps of 0.5
- * We do not support fractional bpps as of today,
- * hence we would skip the fractional bpps during
- * our references for qp calclulations.
*/
static const u8
rc_range_minqp444_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP444_8BPC_MAX_NUM_BPP] = {
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index ed5c85229414..3e39f682b19f 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -378,6 +378,7 @@ calculate_rc_params(struct rc_parameters *rc,
{
int bpc = vdsc_cfg->bits_per_component;
int bpp = vdsc_cfg->bits_per_pixel >> 4;
+ int fractional_bits = vdsc_cfg->bits_per_pixel & 0xf;
static const s8 ofs_und6[] = {
0, -2, -2, -4, -6, -6, -8, -8, -8, -10, -10, -12, -12, -12, -12
};
@@ -418,7 +419,13 @@ calculate_rc_params(struct rc_parameters *rc,
rc->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
rc->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
- bpp_i = (2 * (bpp - 6));
+ /*
+* QP table rows have values in increment of 0.5.
+* So 6.0 bpp to 6.4375 will have index 0, 6.5 to 6.9375 will have
index 1,
+* and so on.
+* 0.5 represented as 0x8 in U6.4 format.
+*/
+ bpp_i = ((bpp - 6) + (fractional_bits < 0x8 ? 0 : 1));
for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
/* Read range_minqp and range_max_qp from qp tables */
rc->rc_range_params[buf_i].range_min_qp =
@@ -466,8 +473,7 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
/* Gen 11 does not support VBR */
vdsc_cfg->vbr_enable = false;
- /* Gen 11 only supports integral values of bpp */
- vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
+ vdsc_cfg->bits_per_pixel = pipe_config->dsc.compressed_bpp;
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
--
2.25.1
[PATCH 15/16] drm/i915/dsc: Add debugfs entry to validate DSC fractional bpp
From: Swati Sharma
DSC_Sink_BPP_Precision entry is added to i915_dsc_fec_support_show
to depict sink's precision.
Also, new debugfs entry is created to enforce fractional bpp.
If Force_DSC_Fractional_BPP_en is set then while iterating over
output bpp with fractional step size we will continue if output_bpp is
computed as integer. With this approach, we will be able to validate
DSC with fractional bpp.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_debugfs.c | 84 +++
.../drm/i915/display/intel_display_types.h| 1 +
2 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 7bcd90384a46..2b36ec812293 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1772,6 +1772,8 @@ static int i915_dsc_fec_support_show(struct seq_file *m,
void *data)
str_yes_no(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
seq_printf(m, "Force_DSC_Enable: %s\n",
str_yes_no(intel_dp->force_dsc_en));
+ seq_printf(m, "DSC_Sink_BPP_Precision: %d\n",
+ drm_dp_dsc_sink_bpp_incr(intel_dp->dsc_dpcd));
if (!intel_dp_is_edp(intel_dp))
seq_printf(m, "FEC_Sink_Support: %s\n",
str_yes_no(drm_dp_sink_supports_fec(intel_dp->fec_capable)));
@@ -1895,6 +1897,85 @@ static const struct file_operations i915_dsc_bpc_fops = {
.write = i915_dsc_bpc_write
};
+static int i915_dsc_fractional_bpp_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct drm_device *dev = connector->dev;
+ struct drm_crtc *crtc;
+ struct intel_dp *intel_dp;
+ struct intel_crtc_state *crtc_state;
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
+ int ret;
+
+ if (!encoder)
+ return -ENODEV;
+
+ ret =
drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex);
+ if (ret)
+ return ret;
+
+ crtc = connector->state->crtc;
+ if (connector->status != connector_status_connected || !crtc) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ intel_dp = intel_attached_dp(to_intel_connector(connector));
+ crtc_state = to_intel_crtc_state(crtc->state);
+ seq_printf(m, "Force_DSC_Fractional_BPP_Enable: %s\n",
+ str_yes_no(intel_dp->force_dsc_fractional_bpp_en));
+
+out: drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ return ret;
+}
+
+static ssize_t i915_dsc_fractional_bpp_write(struct file *file,
+const char __user *ubuf,
+size_t len, loff_t *offp)
+{
+ struct drm_connector *connector =
+ ((struct seq_file *)file->private_data)->private;
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ bool dsc_fractional_bpp_enable = false;
+ int ret;
+
+ if (len == 0)
+ return 0;
+
+ drm_dbg(&i915->drm,
+ "Copied %zu bytes from user to force fractional bpp for DSC\n",
len);
+
+ ret = kstrtobool_from_user(ubuf, len, &dsc_fractional_bpp_enable);
+ if (ret < 0)
+ return ret;
+
+ drm_dbg(&i915->drm, "Got %s for DSC Fractional BPP Enable\n",
+ (dsc_fractional_bpp_enable) ? "true" : "false");
+ intel_dp->force_dsc_fractional_bpp_en = dsc_fractional_bpp_enable;
+
+ *offp += len;
+
+ return len;
+}
+
+static int i915_dsc_fractional_bpp_open(struct inode *inode,
+ struct file *file)
+{
+ return single_open(file, i915_dsc_fractional_bpp_show,
inode->i_private);
+}
+
+static const struct file_operations i915_dsc_fractional_bpp_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_dsc_fractional_bpp_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = i915_dsc_fractional_bpp_write
+};
+
/*
* Returns the Current CRTC's bpc.
* Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
@@ -1966,6 +2047,9 @@ void intel_connector_debugfs_add(struct intel_connector
*intel_connector)
debugfs_create_file("i915_dsc_bpc", 0644, root,
connector, &i915_dsc_bpc_fops);
+
+ debugfs_create_file("i915_dsc_fractional_bpp", 0644, root,
+ connector, &i915_dsc_fractional_bpp_fops);
}
if (c
[PATCH 16/16] drm/i915/dsc: Allow DSC only with fractional bpp when forced from debugfs
From: Swati Sharma
If force_dsc_fractional_bpp_en is set through debugfs allow DSC iff
compressed bpp is fractional. Continue if we computed compressed bpp is
computed as integer.
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_dp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8dede5969af5..48ade9077352 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1609,6 +1609,9 @@ static int dsc_compute_compressed_bpp(struct intel_dp
*intel_dp,
for (compressed_bppx16 = dsc_max_bppx16;
compressed_bppx16 >= dsc_min_bppx16;
compressed_bppx16 -= bppx16_step) {
+ if (intel_dp->force_dsc_fractional_bpp_en &&
+ (compressed_bppx16 % 16 == 0))
+ continue;
ret = dsc_compute_link_config(intel_dp,
pipe_config,
limits,
@@ -1705,6 +1708,9 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
int forced_bpc = intel_dp->force_dsc_bpc;
int forced_bpp = forced_bpc * 3;
+ if (intel_dp->force_dsc_fractional_bpp_en)
+ drm_dbg_kms(&dev_priv->drm,
+ "Forcing DSC fractional bpp\n");
if (forced_bpc < 8 || /* Min Input BPC for ICL+ is 8 */
forced_bpc > conn_state->max_requested_bpc ||
forced_bpp < limits->min_bpp ||
--
2.25.1
[PATCH 11/16] drm/display/dp: Fix the DP DSC Receiver cap size
DP DSC Receiver Capabilities are exposed via DPCD 60h-6Fh.
Fix the DSC RECEIVER CAP SIZE accordingly.
Fixes: ffddc4363c28 ("drm/dp: Add DP DSC DPCD receiver capability size define
and missing SHIFT")
Cc: Anusha Srivatsa
Cc: Manasi Navare
Cc: # v5.0+
Reported-by: kernel test robot
Signed-off-by: Ankit Nautiyal
---
include/drm/display/drm_dp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 632376c291db..bdc05593f462 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -1532,7 +1532,7 @@ enum drm_dp_phy {
#define DP_BRANCH_OUI_HEADER_SIZE 0xc
#define DP_RECEIVER_CAP_SIZE 0xf
-#define DP_DSC_RECEIVER_CAP_SIZE0xf
+#define DP_DSC_RECEIVER_CAP_SIZE0x10 /* DSC Capabilities 0x60 through
0x6F */
#define EDP_PSR_RECEIVER_CAP_SIZE 2
#define EDP_DISPLAY_CTL_CAP_SIZE 3
#define DP_LTTPR_COMMON_CAP_SIZE 8
--
2.25.1
[PATCH 09/16] drm/i915/display: Consider fractional vdsc bpp while computing m_n values
MTL+ supports fractional compressed bits_per_pixel, with precision of
1/16. This compressed bpp is stored in U6.4 format.
Accommodate this precision while computing m_n values.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +-
drivers/gpu/drm/i915/display/intel_display.h | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 7 ---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 --
drivers/gpu/drm/i915/display/intel_fdi.c | 2 +-
5 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 734e8e613f8e..9912930890d0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2748,10 +2748,14 @@ void
intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n,
- bool fec_enable)
+ bool fec_enable,
+ bool is_dsc_fractional_bpp)
{
u32 data_clock = bits_per_pixel * pixel_clock;
+ if (is_dsc_fractional_bpp)
+ data_clock = DIV_ROUND_UP(bits_per_pixel * pixel_clock, 16);
+
if (fec_enable)
data_clock = intel_dp_mode_to_fec_clock(data_clock);
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index ef73730f32b0..3c2016edad18 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -514,7 +514,7 @@ u8 intel_calc_active_pipes(struct intel_atomic_state *state,
void intel_link_compute_m_n(u16 bpp, int nlanes,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n,
- bool fec_enable);
+ bool fec_enable, bool is_dsc_fractional_bpp);
u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
u32 pixel_format, u64 modifier);
enum drm_mode_status
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index ce7bffbdad9e..3d08acb4505a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2178,7 +2178,7 @@ intel_dp_drrs_compute_config(struct intel_connector
*connector,
intel_link_compute_m_n(output_bpp, pipe_config->lane_count, pixel_clock,
pipe_config->port_clock, &pipe_config->dp_m2_n2,
- pipe_config->fec_enable);
+ pipe_config->fec_enable, false);
/* FIXME: abstract this better */
if (pipe_config->splitter.enable)
@@ -2318,7 +2318,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
intel_dp_limited_color_range(pipe_config, conn_state);
if (pipe_config->dsc.compression_enable)
- output_bpp =
dsc_integral_compressed_bpp(pipe_config->dsc.compressed_bpp);
+ output_bpp = pipe_config->dsc.compressed_bpp;
else
output_bpp = intel_dp_output_bpp(pipe_config->output_format,
pipe_config->pipe_bpp);
@@ -2350,7 +2350,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
adjusted_mode->crtc_clock,
pipe_config->port_clock,
&pipe_config->dp_m_n,
- pipe_config->fec_enable);
+ pipe_config->fec_enable,
+ pipe_config->dsc.compression_enable);
/* FIXME: abstract this better */
if (pipe_config->splitter.enable)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index df19691776ca..67d6e261eb68 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -143,7 +143,8 @@ static int intel_dp_mst_compute_link_config(struct
intel_encoder *encoder,
adjusted_mode->crtc_clock,
crtc_state->port_clock,
&crtc_state->dp_m_n,
- crtc_state->fec_enable);
+ crtc_state->fec_enable,
+ false);
crtc_state->dp_m_n.tu = slots;
return 0;
@@ -237,7 +238,8 @@ static int intel_dp_dsc_mst_compute_link_config(struct
intel_encoder *encoder,
adjusted_mode->crtc_clock,
crtc_state->port_clock,
&crtc_state->dp_m_n,
- crtc_state->fec_enable);
+ crtc_state->fec_enable,
+ crtc_state->dsc
[PATCH 10/16] drm/i915/audio : Consider fractional vdsc bpp while computing tu_data
MTL+ supports fractional compressed bits_per_pixel, with precision of 1/16. This compressed bpp is stored in U6.4 format. Accommodate the precision during calculation of transfer unit data for hblank_early calculation. v2: -Fixed tu_data calculation while dealing with U6.4 format. (Stan) Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_audio.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_audio.c b/drivers/gpu/drm/i915/display/intel_audio.c index a73cf477b5e6..30d75f637793 100644 --- a/drivers/gpu/drm/i915/display/intel_audio.c +++ b/drivers/gpu/drm/i915/display/intel_audio.c @@ -510,14 +510,14 @@ static unsigned int calc_hblank_early_prog(struct intel_encoder *encoder, unsigned int link_clks_available, link_clks_required; unsigned int tu_data, tu_line, link_clks_active; unsigned int h_active, h_total, hblank_delta, pixel_clk; - unsigned int fec_coeff, cdclk, vdsc_bpp; + unsigned int fec_coeff, cdclk, vdsc_bppx16; unsigned int link_clk, lanes; unsigned int hblank_rise; h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay; h_total = crtc_state->hw.adjusted_mode.crtc_htotal; pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock; - vdsc_bpp = dsc_integral_compressed_bpp(crtc_state->dsc.compressed_bpp); + vdsc_bppx16 = crtc_state->dsc.compressed_bpp; cdclk = i915->display.cdclk.hw.cdclk; /* fec= 0.972261, using rounding multiplier of 100 */ fec_coeff = 972261; @@ -525,10 +525,10 @@ static unsigned int calc_hblank_early_prog(struct intel_encoder *encoder, lanes = crtc_state->lane_count; drm_dbg_kms(&i915->drm, "h_active = %u link_clk = %u :" - "lanes = %u vdsc_bpp = %u cdclk = %u\n", - h_active, link_clk, lanes, vdsc_bpp, cdclk); + "lanes = %u vdsc_bppx16 = %u cdclk = %u\n", + h_active, link_clk, lanes, vdsc_bppx16, cdclk); - if (WARN_ON(!link_clk || !pixel_clk || !lanes || !vdsc_bpp || !cdclk)) + if (WARN_ON(!link_clk || !pixel_clk || !lanes || !vdsc_bppx16 || !cdclk)) return 0; link_clks_available = (h_total - h_active) * link_clk / pixel_clk - 28; @@ -540,8 +540,8 @@ static unsigned int calc_hblank_early_prog(struct intel_encoder *encoder, hblank_delta = DIV64_U64_ROUND_UP(mul_u32_u32(5 * (link_clk + cdclk), pixel_clk), mul_u32_u32(link_clk, cdclk)); - tu_data = div64_u64(mul_u32_u32(pixel_clk * vdsc_bpp * 8, 100), - mul_u32_u32(link_clk * lanes, fec_coeff)); + tu_data = div64_u64(mul_u32_u32(pixel_clk * vdsc_bppx16 * 8, 100), + mul_u32_u32(link_clk * lanes * 16, fec_coeff)); tu_line = div64_u64(h_active * mul_u32_u32(link_clk, fec_coeff), mul_u32_u32(64 * pixel_clk, 100)); link_clks_active = (tu_line - 1) * 64 + tu_data; -- 2.25.1
[PATCH 06/16] drm/i915/dp: Rename helpers to get DSC max pipe_bpp/output_bpp
Currently the required dsc output bpp is set to be the largest
compressed bpp supported for max, lane, rate, and bpp.
The helper intel_dp_dsc_get_output_bpp gets the maximum supported
compressed bpp taking into account link configuration, input bpp,
bigjoiner considerations etc.
Similarly, the helper intel_dp_dsc_compute_bpp gives the maximum
pipe bpp that is allowed with DSC.
Rename the functions to reflect that these return max DSC input and
output bpps.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 48 ++---
drivers/gpu/drm/i915/display/intel_dp.h | 14 +++---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +++
3 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c52e9979f0a4..c0b96cfb7528 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -702,12 +702,12 @@ u32 intel_dp_dsc_nearest_valid_bpp(struct
drm_i915_private *i915, u32 bpp, u32 p
return bits_per_pixel;
}
-u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
- u32 link_clock, u32 lane_count,
- u32 mode_clock, u32 mode_hdisplay,
- bool bigjoiner,
- u32 pipe_bpp,
- u32 timeslots)
+u16 intel_dp_dsc_get_output_bpp_max(struct drm_i915_private *i915,
+ u32 link_clock, u32 lane_count,
+ u32 mode_clock, u32 mode_hdisplay,
+ bool bigjoiner,
+ u32 pipe_bpp,
+ u32 timeslots)
{
u32 bits_per_pixel, max_bpp_small_joiner_ram;
@@ -1030,7 +1030,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
* TBD pass the connector BPC,
* for now U8_MAX so that max BPC on that platform would be
picked
*/
- int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, U8_MAX);
+ int pipe_bpp = intel_dp_dsc_get_bpp_max(intel_dp, U8_MAX);
if (intel_dp_is_edp(intel_dp)) {
dsc_max_output_bpp =
@@ -1040,13 +1040,13 @@ intel_dp_mode_valid(struct drm_connector *_connector,
true);
} else if (drm_dp_sink_supports_fec(intel_dp->fec_capable)) {
dsc_max_output_bpp =
- intel_dp_dsc_get_output_bpp(dev_priv,
- max_link_clock,
- max_lanes,
- target_clock,
- mode->hdisplay,
- bigjoiner,
- pipe_bpp, 64);
+ intel_dp_dsc_get_output_bpp_max(dev_priv,
+ max_link_clock,
+ max_lanes,
+ target_clock,
+ mode->hdisplay,
+ bigjoiner,
+ pipe_bpp, 64);
dsc_slice_count =
intel_dp_dsc_get_slice_count(intel_dp,
target_clock,
@@ -1375,7 +1375,7 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
return -EINVAL;
}
-int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 max_req_bpc)
+int intel_dp_dsc_get_bpp_max(struct intel_dp *intel_dp, u8 max_req_bpc)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
int i, num_bpc;
@@ -1518,7 +1518,7 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
pipe_config->pipe_bpp = forced_bpp;
drm_dbg_kms(&dev_priv->drm, "Input DSC BPP forced to %d\n",
pipe_config->pipe_bpp);
} else if (compute_pipe_bpp) {
- int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
conn_state->max_requested_bpc);
+ int pipe_bpp = intel_dp_dsc_get_bpp_max(intel_dp,
conn_state->max_requested_bpc);
if (!is_dsc_pipe_bpp_sufficient(dev_priv, pipe_bpp)) {
drm_dbg_kms(&dev_priv->drm,
@@ -1548,14 +1548,14 @@ int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
if (compute_pipe_bpp) {
dsc_max_output_bpp =
- int
[PATCH 07/16] drm/i915/dp: Get optimal link config to have best compressed bpp
Currently, we take the max lane, rate and pipe bpp, to get the maximum
compressed bpp possible. We then set the output bpp to this value.
This patch provides support to have max bpp, min rate and min lanes,
that can support the min compressed bpp.
v2:
-Avoid ending up with compressed bpp, same as pipe bpp. (Stan)
-Fix the checks for limits->max/min_bpp while iterating over list of
valid DSC bpcs. (Stan)
v3:
-Refactor the code to have pipe bpp/compressed bpp computation and slice
count calculation separately for different cases.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 278
1 file changed, 232 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c0b96cfb7528..885d2f75ddbf 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1476,6 +1476,195 @@ static int intel_dp_dsc_compute_params(struct
intel_encoder *encoder,
return drm_dsc_compute_rc_parameters(vdsc_cfg);
}
+static bool is_dsc_bw_sufficient(int link_rate, int lane_count, int
compressed_bpp,
+const struct drm_display_mode *adjusted_mode)
+{
+ int mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
compressed_bpp);
+ int link_avail = intel_dp_max_data_rate(link_rate, lane_count);
+
+ return mode_rate <= link_avail;
+}
+
+static int dsc_compute_link_config(struct intel_dp *intel_dp,
+ struct intel_crtc_state *pipe_config,
+ struct link_config_limits *limits,
+ int pipe_bpp,
+ u16 compressed_bpp)
+{
+ const struct drm_display_mode *adjusted_mode =
+ &pipe_config->hw.adjusted_mode;
+ int link_rate, lane_count;
+ int dsc_max_bpp;
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+ int i;
+
+ for (i = 0; i < intel_dp->num_common_rates; i++) {
+ link_rate = intel_dp_common_rate(intel_dp, i);
+ if (link_rate < limits->min_rate || link_rate >
limits->max_rate)
+ continue;
+
+ for (lane_count = limits->min_lane_count;
+lane_count <= limits->max_lane_count;
+lane_count <<= 1) {
+ dsc_max_bpp = intel_dp_dsc_get_output_bpp_max(dev_priv,
+ link_rate,
+
lane_count,
+
adjusted_mode->crtc_clock,
+
adjusted_mode->crtc_hdisplay,
+
pipe_config->bigjoiner_pipes,
+ pipe_bpp,
64);
+ if (compressed_bpp > dsc_max_bpp)
+ continue;
+
+ if (!is_dsc_bw_sufficient(link_rate, lane_count,
+ compressed_bpp,
adjusted_mode))
+ continue;
+
+ pipe_config->lane_count = lane_count;
+ pipe_config->port_clock = link_rate;
+
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static u16 dsc_max_sink_compressed_bppx16(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
+ struct intel_crtc_state *pipe_config,
+ int bpc)
+{
+ u16 max_bppx16 = dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW -
DP_DSC_SUPPORT] |
+(dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI -
DP_DSC_SUPPORT] &
+ DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK <<
DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
+
+ if (max_bppx16)
+ return max_bppx16;
+ /*
+* If support not given in DPCD 67h, 68h use the Maximum Allowed bit
rate
+* values as given in spec Table 2-157 DP v2.0
+*/
+ switch (pipe_config->output_format) {
+ case INTEL_OUTPUT_FORMAT_RGB:
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ return (3 * bpc) << 4;
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ return (3 * (bpc / 2)) << 4;
+ default:
+ MISSING_CASE(pipe_config->output_format);
+ break;
+ }
+
+ return 0;
+}
+
+static u16 dsc_min_compressed_bppx16(struct intel_crtc_state *pipe_config)
+{
+ switch (pipe_config->output_format) {
+ case INTEL_OUTPUT_FORMAT_RGB:
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ return 8 << 4;
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ return 6 << 4;
+ default:
[PATCH 04/16] drm/i915/dp: Check if dsc forced bpc is in allowed limits
Add a check to use force DSC bpc only if it, along with the
corresponding bpp are within allowed limits.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d061fc3fa402..354dbd1d3164 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1510,19 +1510,20 @@ int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
int forced_bpc = intel_dp->force_dsc_bpc;
int forced_bpp = forced_bpc * 3;
- /* Min Input BPC for ICL+ is 8 */
- if (forced_bpc < 8) {
+ if (forced_bpc < 8 || /* Min Input BPC for ICL+ is 8 */
+ forced_bpc > conn_state->max_requested_bpc ||
+ forced_bpp < limits->min_bpp ||
+ forced_bpp > limits->max_bpp) {
drm_dbg_kms(&dev_priv->drm,
- "Cannot force dsc bpc:%d, due to dsc bpc
limits\n",
+ "Cannot force dsc bpc:%d, due to bpc/bpp
limits\n",
intel_dp->force_dsc_bpc);
return -EINVAL;
}
pipe_config->pipe_bpp = forced_bpp;
- drm_dbg_kms(&dev_priv->drm, "Input DSC BPP forced to %d\n",
- pipe_config->pipe_bpp);
+ drm_dbg_kms(&dev_priv->drm, "Input DSC BPP forced to %d\n",
pipe_config->pipe_bpp);
} else if (compute_pipe_bpp) {
- int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
-
conn_state->max_requested_bpc);
+ int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
conn_state->max_requested_bpc);
+
if (!is_dsc_pipe_bpp_sufficient(dev_priv, pipe_bpp)) {
drm_dbg_kms(&dev_priv->drm,
"No DSC support for less than 8bpc\n");
@@ -1530,7 +1531,6 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
}
pipe_config->pipe_bpp = pipe_bpp;
}
-
/*
* For now enable DSC for max link rate, max lane count.
* Optimize this later for the minimum possible link rate/lane count
--
2.25.1
[PATCH 08/16] drm/i915/display: Store compressed bpp in U6.4 format
DSC parameter bits_per_pixel is stored in U6.4 format.
The 4 bits represent the fractional part of the bpp.
Currently we use compressed_bpp member of dsc structure to store
only the integral part of the bits_per_pixel.
To store the full bits_per_pixel along with the fractional part,
compressed_bpp is changed to store bpp in U6.4 formats. Intergral
part is retrieved by simply right shifting the member compressed_bpp by 4.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/icl_dsi.c| 10
drivers/gpu/drm/i915/display/intel_audio.c| 2 +-
drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
.../drm/i915/display/intel_display_types.h| 16 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 25 +++
drivers/gpu/drm/i915/display/intel_vdsc.c | 4 +--
6 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index ae14c794c4bc..f387450c4be2 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -343,7 +343,7 @@ static int afe_clk(struct intel_encoder *encoder,
int bpp;
if (crtc_state->dsc.compression_enable)
- bpp = crtc_state->dsc.compressed_bpp;
+ bpp =
dsc_integral_compressed_bpp(crtc_state->dsc.compressed_bpp);
else
bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
@@ -903,7 +903,7 @@ gen11_dsi_set_transcoder_timings(struct intel_encoder
*encoder,
* compressed and non-compressed bpp.
*/
if (crtc_state->dsc.compression_enable) {
- mul = crtc_state->dsc.compressed_bpp;
+ mul =
dsc_integral_compressed_bpp(crtc_state->dsc.compressed_bpp);
div = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
}
@@ -927,7 +927,7 @@ gen11_dsi_set_transcoder_timings(struct intel_encoder
*encoder,
int bpp, line_time_us, byte_clk_period_ns;
if (crtc_state->dsc.compression_enable)
- bpp = crtc_state->dsc.compressed_bpp;
+ bpp =
dsc_integral_compressed_bpp(crtc_state->dsc.compressed_bpp);
else
bpp =
mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
@@ -1500,8 +1500,8 @@ static void gen11_dsi_get_timings(struct intel_encoder
*encoder,
struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
- if (pipe_config->dsc.compressed_bpp) {
- int div = pipe_config->dsc.compressed_bpp;
+ if (dsc_integral_compressed_bpp(pipe_config->dsc.compressed_bpp)) {
+ int div =
dsc_integral_compressed_bpp(pipe_config->dsc.compressed_bpp);
int mul = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
adjusted_mode->crtc_htotal =
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
b/drivers/gpu/drm/i915/display/intel_audio.c
index 626c47e96a6d..a73cf477b5e6 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -517,7 +517,7 @@ static unsigned int calc_hblank_early_prog(struct
intel_encoder *encoder,
h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock;
- vdsc_bpp = crtc_state->dsc.compressed_bpp;
+ vdsc_bpp = dsc_integral_compressed_bpp(crtc_state->dsc.compressed_bpp);
cdclk = i915->display.cdclk.hw.cdclk;
/* fec= 0.972261, using rounding multiplier of 100 */
fec_coeff = 972261;
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 78abe34c7a42..75343bca8750 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -3482,7 +3482,7 @@ static void fill_dsc(struct intel_crtc_state *crtc_state,
crtc_state->pipe_bpp = bpc * 3;
crtc_state->dsc.compressed_bpp = min(crtc_state->pipe_bpp,
-VBT_DSC_MAX_BPP(dsc->max_bpp));
+VBT_DSC_MAX_BPP(dsc->max_bpp)) <<
4;
/*
* FIXME: This is ugly, and slice count should take DSC engine
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 32e8b2fc3cc6..e879a9483148 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1283,7 +1283,7 @@ struct intel_crtc_state {
struct {
bool compression_enable;
bool dsc_split;
- u16 compressed_bpp;
+ u16 compressed_bpp; /* U6.4 format (first 4 bits for fractional
part) */
u8 slice_count;
[PATCH 05/16] drm/i915/dp: Avoid left shift of DSC output bpp by 4
To make way for fractional bpp support, avoid left shifting the
output_bpp by 4 in helper intel_dp_dsc_get_output_bpp.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 +++---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 354dbd1d3164..c52e9979f0a4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -749,11 +749,7 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
*i915,
bits_per_pixel = intel_dp_dsc_nearest_valid_bpp(i915, bits_per_pixel,
pipe_bpp);
- /*
-* Compressed BPP in U6.4 format so multiply by 16, for Gen 11,
-* fractional part is 0
-*/
- return bits_per_pixel << 4;
+ return bits_per_pixel;
}
u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
@@ -1050,7 +1046,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
target_clock,
mode->hdisplay,
bigjoiner,
- pipe_bpp, 64) >> 4;
+ pipe_bpp, 64);
dsc_slice_count =
intel_dp_dsc_get_slice_count(intel_dp,
target_clock,
@@ -1585,7 +1581,7 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
*/
if (compute_pipe_bpp) {
pipe_config->dsc.compressed_bpp = min_t(u16,
-
dsc_max_output_bpp >> 4,
+
dsc_max_output_bpp,
pipe_config->pipe_bpp);
}
pipe_config->dsc.slice_count = dsc_dp_slice_count;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 9be04c60cced..5b65e4c2c78f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -921,7 +921,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector *connector,
target_clock,
mode->hdisplay,
bigjoiner,
- pipe_bpp, 64) >> 4;
+ pipe_bpp, 64);
dsc_slice_count =
intel_dp_dsc_get_slice_count(intel_dp,
target_clock,
--
2.25.1
[PATCH 03/16] drm/i915/dp: Do not check for min DSC BPC for MST case
For DSC the min BPC is 8 for ICL+ and so the min pipe_bpp is 24.
Check this condition for cases only where pipe_bpp is to be computed.
For MST case the pipe_bpp is already computed (hardcoded to be 24),
and this check is not required.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 46 -
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3d828ea0894d..d061fc3fa402 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1480,6 +1480,13 @@ static int intel_dp_dsc_compute_params(struct
intel_encoder *encoder,
return drm_dsc_compute_rc_parameters(vdsc_cfg);
}
+static
+bool is_dsc_pipe_bpp_sufficient(struct drm_i915_private *i915, int pipe_bpp)
+{
+ /* Min Input BPC for ICL+ is 8 */
+ return (pipe_bpp < 8 * 3);
+}
+
int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state,
@@ -1491,7 +1498,6 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
const struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
- int pipe_bpp;
int ret;
pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
@@ -1501,27 +1507,35 @@ int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
return -EINVAL;
if (intel_dp->force_dsc_bpc && compute_pipe_bpp) {
- pipe_bpp = intel_dp->force_dsc_bpc * 3;
- drm_dbg_kms(&dev_priv->drm, "Input DSC BPP forced to %d\n",
pipe_bpp);
- } else if (compute_pipe_bpp) {
- pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
conn_state->max_requested_bpc);
- } else {
- pipe_bpp = pipe_config->pipe_bpp;
- }
+ int forced_bpc = intel_dp->force_dsc_bpc;
+ int forced_bpp = forced_bpc * 3;
- /* Min Input BPC for ICL+ is 8 */
- if (pipe_bpp < 8 * 3) {
- drm_dbg_kms(&dev_priv->drm,
- "No DSC support for less than 8bpc\n");
- return -EINVAL;
+ /* Min Input BPC for ICL+ is 8 */
+ if (forced_bpc < 8) {
+ drm_dbg_kms(&dev_priv->drm,
+ "Cannot force dsc bpc:%d, due to dsc bpc
limits\n",
+ intel_dp->force_dsc_bpc);
+ return -EINVAL;
+ }
+ pipe_config->pipe_bpp = forced_bpp;
+ drm_dbg_kms(&dev_priv->drm, "Input DSC BPP forced to %d\n",
+ pipe_config->pipe_bpp);
+ } else if (compute_pipe_bpp) {
+ int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
+
conn_state->max_requested_bpc);
+ if (!is_dsc_pipe_bpp_sufficient(dev_priv, pipe_bpp)) {
+ drm_dbg_kms(&dev_priv->drm,
+ "No DSC support for less than 8bpc\n");
+ return -EINVAL;
+ }
+ pipe_config->pipe_bpp = pipe_bpp;
}
/*
-* For now enable DSC for max bpp, max link rate, max lane count.
+* For now enable DSC for max link rate, max lane count.
* Optimize this later for the minimum possible link rate/lane count
* with DSC enabled for the requested mode.
*/
- pipe_config->pipe_bpp = pipe_bpp;
pipe_config->port_clock = limits->max_rate;
pipe_config->lane_count = limits->max_lane_count;
@@ -1544,7 +1558,7 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
adjusted_mode->crtc_clock,
adjusted_mode->crtc_hdisplay,
pipe_config->bigjoiner_pipes,
- pipe_bpp,
+
pipe_config->pipe_bpp,
timeslots);
if (!dsc_max_output_bpp) {
drm_dbg_kms(&dev_priv->drm,
--
2.25.1
[PATCH 01/16] drm/i915/dp: Remove extra logs for printing DSC info
DSC compressed bpp and slice counts are already getting printed at the end of dsc compute config. Remove extra logs. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_dp.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 80d95cec8f9d..93aebd3683a4 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -1576,9 +1576,6 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp, pipe_config->pipe_bpp); } pipe_config->dsc.slice_count = dsc_dp_slice_count; - drm_dbg_kms(&dev_priv->drm, "DSC: compressed bpp %d slice count %d\n", - pipe_config->dsc.compressed_bpp, - pipe_config->dsc.slice_count); } /* * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate -- 2.25.1
[PATCH 02/16] drm/i915/dp: Avoid forcing DSC BPC for MST case
For MST the bpc is hardcoded to 8, and pipe bpp to 24.
So avoid forcing DSC bpc for MST case.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 8
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 93aebd3683a4..3d828ea0894d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1500,14 +1500,13 @@ int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return -EINVAL;
- if (compute_pipe_bpp)
+ if (intel_dp->force_dsc_bpc && compute_pipe_bpp) {
+ pipe_bpp = intel_dp->force_dsc_bpc * 3;
+ drm_dbg_kms(&dev_priv->drm, "Input DSC BPP forced to %d\n",
pipe_bpp);
+ } else if (compute_pipe_bpp) {
pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
conn_state->max_requested_bpc);
- else
+ } else {
pipe_bpp = pipe_config->pipe_bpp;
-
- if (intel_dp->force_dsc_bpc) {
- pipe_bpp = intel_dp->force_dsc_bpc * 3;
- drm_dbg_kms(&dev_priv->drm, "Input DSC BPP forced to %d",
pipe_bpp);
}
/* Min Input BPC for ICL+ is 8 */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 8b0e4defa3f1..9be04c60cced 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -325,6 +325,14 @@ static int intel_dp_mst_compute_config(struct
intel_encoder *encoder,
/* enable compression if the mode doesn't fit available BW */
drm_dbg_kms(&dev_priv->drm, "Force DSC en = %d\n",
intel_dp->force_dsc_en);
if (ret || intel_dp->force_dsc_en) {
+ if (intel_dp->force_dsc_bpc) {
+ /*
+* FIXME: As bpc is hardcoed to 8 bpc as mentioned
above,
+* Avoid force BPC for now.
+*/
+ drm_dbg_kms(&dev_priv->drm, "Cannot Force BPC for
MST\n");
+ return -EINVAL;
+ }
/*
* Try to get at least some timeslots and then see, if
* we can fit there with DSC.
--
2.25.1
[PATCH 00/16] Add DSC fractional bpp support
This patch series adds support for DSC fractional compressed bpp for MTL+. The series starts with some fixes, followed by patches that lay groundwork to iterate over valid compressed bpps to select the 'best' compressed bpp with optimal link configuration (taken from upstream series: https://patchwork.freedesktop.org/series/105200/). The later patches, add changes to accommodate compressed bpp with fractional part, including changes to QP calculations. To get the 'best' compressed bpp, we iterate over the valid compressed bpp values, but with fractional step size 1/16, 1/8, 1/4 or 1/2 as per sink support. The last 2 patches add support to depict DSC sink's fractional support, and debugfs to enforce use of fractional bpp, while choosing an appropriate compressed bpp. Ankit Nautiyal (13): drm/i915/dp: Remove extra logs for printing DSC info drm/i915/dp: Avoid forcing DSC BPC for MST case drm/i915/dp: Do not check for min DSC BPC for MST case drm/i915/dp: Check if dsc forced bpc is in allowed limits drm/i915/dp: Avoid left shift of DSC output bpp by 4 drm/i915/dp: Rename helpers to get DSC max pipe_bpp/output_bpp drm/i915/dp: Get optimal link config to have best compressed bpp drm/i915/display: Store compressed bpp in U6.4 format drm/i915/display: Consider fractional vdsc bpp while computing m_n values drm/i915/audio : Consider fractional vdsc bpp while computing tu_data drm/display/dp: Fix the DP DSC Receiver cap size drm/display/dp: Add helper function to get DSC bpp prescision drm/i915/dp: Iterate over output bpp with fractional step size Swati Sharma (2): drm/i915/dsc: Add debugfs entry to validate DSC fractional bpp drm/i915/dsc: Allow DSC only with fractional bpp when forced from debugfs Vandita Kulkarni (1): drm/i915/dsc/mtl: Add support for fractional bpp drivers/gpu/drm/display/drm_dp_helper.c | 27 ++ drivers/gpu/drm/i915/display/icl_dsi.c| 10 +- drivers/gpu/drm/i915/display/intel_audio.c| 14 +- drivers/gpu/drm/i915/display/intel_bios.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 6 +- drivers/gpu/drm/i915/display/intel_display.h | 2 +- .../drm/i915/display/intel_display_debugfs.c | 84 .../drm/i915/display/intel_display_types.h| 17 +- drivers/gpu/drm/i915/display/intel_dp.c | 389 ++ drivers/gpu/drm/i915/display/intel_dp.h | 14 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 30 +- drivers/gpu/drm/i915/display/intel_fdi.c | 2 +- .../gpu/drm/i915/display/intel_qp_tables.c| 3 - drivers/gpu/drm/i915/display/intel_vdsc.c | 16 +- include/drm/display/drm_dp.h | 2 +- include/drm/display/drm_dp_helper.h | 1 + 16 files changed, 487 insertions(+), 132 deletions(-) -- 2.25.1
Re: [PATCH] drm/radeon: Fix screen corruption (v2)
On 2023-01-19 11:56, Krylov Michael wrote: > On Thu, 15 Dec 2022 07:07:33 -0500 > Luben Tuikov wrote: > >> On 2022-12-15 06:53, Robin Murphy wrote: >>> On 2022-12-15 11:40, Luben Tuikov wrote: On 2022-12-15 06:27, Christian König wrote: > Am 15.12.22 um 11:19 schrieb Luben Tuikov: >> On 2022-12-15 04:46, Christian König wrote: >>> Am 15.12.22 um 10:08 schrieb Luben Tuikov: On 2022-12-15 03:07, Christian König wrote: > Am 15.12.22 um 00:08 schrieb Robin Murphy: >> On 2022-12-14 22:02, Alex Deucher wrote: >>> On Wed, Dec 14, 2022 at 4:54 PM Robin Murphy >>> wrote: On 2022-12-12 02:08, Luben Tuikov wrote: > Fix screen corruption on older 32-bit systems using AGP > chips. > > On older systems with little memory, for instance 1.5 > GiB, using an AGP chip, > the device's DMA mask is 0x, but the memory mask > is 0x7FF, and > subsequently dma_addressing_limited() returns 0x > < 0x7FFF, false. As such the result of this static > inline isn't suitable for the last > argument to ttm_device_init()--it simply needs to now > whether to use GFP_DMA32 > when allocating DMA buffers. This sounds wrong to me. If the issues happen on systems without PAE it clearly can't have anything to with the actual DMA address size. Not to mention that AFAICS 32-bit x86 doesn't even have ZONE_DMA32, so GFP_DMA32 would be functionally meaningless anyway. Although the reported symptoms initially sounded like they could be caused by DMA going to the wrong place, that is also equally consistent with a loss of cache coherency. My (limited) understanding of AGP is that the GART can effectively alias memory to a second physical address, so I could well believe that something somewhere in the driver stack needs to perform some cache maintenance to avoid coherency issues, and that in these particular setups whatever that is might be assuming the memory is direct-mapped and thus going wrong for highmem pages. So as I said before, I really think this is not about using GFP_DMA32 at all, but about *not* using GFP_HIGHUSER. >>> One of the wonderful features of AGP is that it has to be >>> used with uncached memory. The aperture basically just >>> provides a remapping of physical pages into a linear >>> aperture that you point the GPU at. TTM has to jump >>> through quite a few hoops to get uncached memory in the >>> first place, so it's likely that that somehow isn't >>> compatible with HIGHMEM. Can you get uncached HIGHMEM? >> I guess in principle yes, if you're careful not to use >> regular kmap()/kmap_atomic(), and always use >> pgprot_noncached() for userspace/vmalloc mappings, but >> clearly that leaves lots of scope for slipping up. > I theory we should do exactly that in TTM, but we have very > few users who actually still exercise that functionality. > >> Working backwards from primitives like set_memory_uc(), I >> see various paths in TTM where manipulating the caching >> state is skipped for highmem pages, but I wouldn't even know >> where to start looking for whether the right state is >> propagated to all the places where they might eventually be >> mapped somewhere. > The tt object has the caching state for the pages and > ttm_prot_from_caching() then uses pgprot_noncached() and co > for the userspace/vmalloc mappings. > The point of this patch is that dma_addressing_limited() is unsuitable as the last parameter to ttm_pool_init(), since if it is "false"--as it is in this particular case--then TTM ends up using HIGHUSER, and we get the screen corruption. (gfp_flags |= GFP_HIGHUSER in in ttm_pool_alloc()) >>> Well I would rather say that dma_addressing_limited() works, >>> but the default value from dma_get_required_mask() is broken. >>> >> dma_get_required_mask() for his setup of 1.5 GiB of memory >> returns 0x7FF. > > This 0x7FF mask looks fishy to me. That would only be 128MiB > addressable memory (27 bits set)? Or is there another F missing? Yeah, I'm missing an F--it is correctly described at the top of the thread above, i.e. in the commit of v2 patch. 0x7FFF_, which seems correct, no? >> While the dma mask is 0x, as set in radeon_device.c in >> radeon_device_init(). >> >>> 32 bits only
Re: [PATCH drm-next 13/14] drm/nouveau: implement new VM_BIND UAPI
On Thu, Jan 19, 2023 at 11:25:51PM +0100, Danilo Krummrich wrote:
> On 1/19/23 22:47, Matthew Brost wrote:
> > On Thu, Jan 19, 2023 at 06:46:30PM +0100, Danilo Krummrich wrote:
> > >
> > >
> > > On 1/19/23 17:38, Matthew Brost wrote:
> > > > On Thu, Jan 19, 2023 at 04:36:43PM +0100, Danilo Krummrich wrote:
> > > > > On 1/19/23 05:58, Matthew Brost wrote:
> > > > > > On Thu, Jan 19, 2023 at 04:44:23AM +0100, Danilo Krummrich wrote:
> > > > > > > On 1/18/23 21:37, Thomas Hellström (Intel) wrote:
> > > > > > > >
> > > > > > > > On 1/18/23 07:12, Danilo Krummrich wrote:
> > > > > > > > > This commit provides the implementation for the new uapi
> > > > > > > > > motivated by the
> > > > > > > > > Vulkan API. It allows user mode drivers (UMDs) to:
> > > > > > > > >
> > > > > > > > > 1) Initialize a GPU virtual address (VA) space via the new
> > > > > > > > > DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify
> > > > > > > > > the portion of VA
> > > > > > > > > space managed by the kernel and userspace,
> > > > > > > > > respectively.
> > > > > > > > >
> > > > > > > > > 2) Allocate and free a VA space region as well as bind and
> > > > > > > > > unbind memory
> > > > > > > > > to the GPUs VA space via the new
> > > > > > > > > DRM_IOCTL_NOUVEAU_VM_BIND ioctl.
> > > > > > > > > UMDs can request the named operations to be processed
> > > > > > > > > either
> > > > > > > > > synchronously or asynchronously. It supports DRM
> > > > > > > > > syncobjs
> > > > > > > > > (incl. timelines) as synchronization mechanism. The
> > > > > > > > > management of the
> > > > > > > > > GPU VA mappings is implemented with the DRM GPU VA
> > > > > > > > > manager.
> > > > > > > > >
> > > > > > > > > 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC
> > > > > > > > > ioctl. The
> > > > > > > > > execution happens asynchronously. It supports DRM
> > > > > > > > > syncobj (incl.
> > > > > > > > > timelines) as synchronization mechanism. DRM GEM
> > > > > > > > > object locking is
> > > > > > > > > handled with drm_exec.
> > > > > > > > >
> > > > > > > > > Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC,
> > > > > > > > > use the DRM
> > > > > > > > > GPU scheduler for the asynchronous paths.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Danilo Krummrich
> > > > > > > > > ---
> > > > > > > > > Documentation/gpu/driver-uapi.rst | 3 +
> > > > > > > > > drivers/gpu/drm/nouveau/Kbuild | 2 +
> > > > > > > > > drivers/gpu/drm/nouveau/Kconfig | 2 +
> > > > > > > > > drivers/gpu/drm/nouveau/nouveau_abi16.c | 16 +
> > > > > > > > > drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 +
> > > > > > > > > drivers/gpu/drm/nouveau/nouveau_drm.c | 23 +-
> > > > > > > > > drivers/gpu/drm/nouveau/nouveau_drv.h | 9 +-
> > > > > > > > > drivers/gpu/drm/nouveau/nouveau_exec.c | 310 ++
> > > > > > > > > drivers/gpu/drm/nouveau/nouveau_exec.h | 55 ++
> > > > > > > > > drivers/gpu/drm/nouveau/nouveau_sched.c | 780
> > > > > > > > >
> > > > > > > > > drivers/gpu/drm/nouveau/nouveau_sched.h | 98 +++
> > > > > > > > > 11 files changed, 1295 insertions(+), 4 deletions(-)
> > > > > > > > > create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.c
> > > > > > > > > create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.h
> > > > > > > > > create mode 100644
> > > > > > > > > drivers/gpu/drm/nouveau/nouveau_sched.c
> > > > > > > > > create mode 100644
> > > > > > > > > drivers/gpu/drm/nouveau/nouveau_sched.h
> > > > > > > > ...
> > > > > > > > >
> > > > > > > > > +static struct dma_fence *
> > > > > > > > > +nouveau_bind_job_run(struct nouveau_job *job)
> > > > > > > > > +{
> > > > > > > > > + struct nouveau_bind_job *bind_job =
> > > > > > > > > to_nouveau_bind_job(job);
> > > > > > > > > + struct nouveau_uvmm *uvmm = nouveau_cli_uvmm(job->cli);
> > > > > > > > > + struct bind_job_op *op;
> > > > > > > > > + int ret = 0;
> > > > > > > > > +
> > > > > > > >
> > > > > > > > I was looking at how nouveau does the async binding compared to
> > > > > > > > how xe
> > > > > > > > does it.
> > > > > > > > It looks to me that this function being a scheduler run_job
> > > > > > > > callback is
> > > > > > > > the main part of the VM_BIND dma-fence signalling critical
> > > > > > > > section for
> > > > > > > > the job's done_fence and if so, needs to be annotated as such?
> > > > > > >
> > > > > > > Yes, that's the case.
> > > > > > >
> > > > > > > >
> > > > > > > > For example nouveau_uvma_region_new allocates memory, which is
> > > > > > > > not
> > > > > > > > allowed if in a dma_fence signalling critical section and the
> > > > > > > > locking
> > > > > > > > also looks suspicious?
> > > > > > >
> > > > > > > Thanks for pointing this out, I missed that somehow.
> > > > > > >
> >
Re: [PATCH drm-next 11/14] drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm
Hi Danilo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on 0b45ac1170ea6416bc1d36798414c04870cd356d]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers/20230118-141552
base: 0b45ac1170ea6416bc1d36798414c04870cd356d
patch link:
https://lore.kernel.org/r/20230118061256.2689-12-dakr%40redhat.com
patch subject: [PATCH drm-next 11/14] drm/nouveau: nvkm/vmm: implement raw ops
to manage uvmm
config: arc-randconfig-s051-20230119
(https://download.01.org/0day-ci/archive/20230120/202301201115.thlpcsho-...@intel.com/config)
compiler: arc-elf-gcc (GCC) 12.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.4-39-gce1a6720-dirty
#
https://github.com/intel-lab-lkp/linux/commit/5fca471110e52d7c8db10f9ff483134a546174a1
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Danilo-Krummrich/drm-execution-context-for-GEM-buffers/20230118-141552
git checkout 5fca471110e52d7c8db10f9ff483134a546174a1
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=arc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=arc
SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c:413:34: sparse: sparse: non
>> size-preserving integer to pointer cast
vim +413 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
406
407 static int
408 nvkm_uvmm_mthd_raw_unmap(struct nvkm_uvmm *uvmm, struct nvif_vmm_raw_v0
*args)
409 {
410 struct nvkm_vmm *vmm = uvmm->vmm;
411 struct nvkm_vma *vma;
412
> 413 vma = (struct nvkm_vma *)args->handle;
414 if (!vma)
415 return -EINVAL;
416
417 mutex_lock(&vmm->mutex);
418 if (vma->busy) {
419 VMM_DEBUG(vmm, "denied %016llx: %d", vma->addr,
vma->busy);
420 mutex_unlock(&vmm->mutex);
421 return -ENOENT;
422 }
423 vma->sparse = args->sparse;
424 nvkm_vmm_raw_unmap_locked(vmm, vma);
425 mutex_unlock(&vmm->mutex);
426
427 args->handle = 0;
428 kfree(vma);
429 return 0;
430 }
431
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH RFC v7 00/23] DEPT(Dependency Tracker)
On Thu, Jan 19, 2023 at 07:07:59PM -0800, Boqun Feng wrote: > On Thu, Jan 19, 2023 at 06:23:49PM -0800, Boqun Feng wrote: > > On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote: > > > Boqun wrote: > > > > On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote: > > > > > On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote: > > > > > > Boqun wrote: > > > > > > > *Looks like the DEPT dependency graph doesn't handle the > > > > > > > fair/unfair readers as lockdep current does. Which bring the > > > > > > > next question. > > > > > > > > > > > > No. DEPT works better for unfair read. It works based on > > > > > > wait/event. So > > > > > > read_lock() is considered a potential wait waiting on write_unlock() > > > > > > while write_lock() is considered a potential wait waiting on either > > > > > > write_unlock() or read_unlock(). DEPT is working perfect for it. > > > > > > > > > > > > For fair read (maybe you meant queued read lock), I think the case > > > > > > should be handled in the same way as normal lock. I might get it > > > > > > wrong. > > > > > > Please let me know if I miss something. > > > > > > > > > > From the lockdep/DEPT point of view, the question is whether: > > > > > > > > > > read_lock(A) > > > > > read_lock(A) > > > > > > > > > > can deadlock if a writer comes in between the two acquisitions and > > > > > sleeps waiting on A to be released. A fair lock will block new > > > > > readers when a writer is waiting, while an unfair lock will allow > > > > > new readers even while a writer is waiting. > > > > > > > > > > > > > To be more accurate, a fair reader will wait if there is a writer > > > > waiting for other reader (fair or not) to unlock, and an unfair reader > > > > won't. > > > > > > What a kind guys, both of you! Thanks. > > > > > > I asked to check if there are other subtle things than this. Fortunately, > > > I already understand what you guys shared. > > > > > > > In kernel there are read/write locks that can have both fair and unfair > > > > readers (e.g. queued rwlock). Regarding deadlocks, > > > > > > > > T0 T1 T2 > > > > -- -- -- > > > > fair_read_lock(A); > > > > write_lock(B); > > > > write_lock(A); > > > > write_lock(B); > > > > unfair_read_lock(A); > > > > > > With the DEPT's point of view (let me re-write the scenario): > > > > > > T0 T1 T2 > > > -- -- -- > > > fair_read_lock(A); > > > write_lock(B); > > > write_lock(A); > > > write_lock(B); > > > unfair_read_lock(A); > > > write_unlock(B); > > > read_unlock(A); > > > read_unlock(A); > > > write_unlock(B); > > > write_unlock(A); > > > > > > T0: read_unlock(A) cannot happen if write_lock(B) is stuck by a B owner > > > not doing either write_unlock(B) or read_unlock(B). In other words: > > > > > > 1. read_unlock(A) happening depends on write_unlock(B) happening. > > > 2. read_unlock(A) happening depends on read_unlock(B) happening. > > > > > > T1: write_unlock(B) cannot happen if unfair_read_lock(A) is stuck by a A > > > owner not doing write_unlock(A). In other words: > > > > > > 3. write_unlock(B) happening depends on write_unlock(A) happening. > > > > > > 1, 2 and 3 give the following dependencies: > > > > > > 1. read_unlock(A) -> write_unlock(B) > > > 2. read_unlock(A) -> read_unlock(B) > > > 3. write_unlock(B) -> write_unlock(A) > > > > > > There's no circular dependency so it's safe. DEPT doesn't report this. > > > > > > > the above is not a deadlock, since T1's unfair reader can "steal" the > > > > lock. However the following is a deadlock: > > > > > > > > T0 T1 T2 > > > > -- -- -- > > > > unfair_read_lock(A); > > > > write_lock(B); > > > > write_lock(A); > > > > write_lock(B); > > > > fair_read_lock(A); > > > > > > > > , since T'1 fair reader will wait. > > > > > > With the DEPT's point of view (let me re-write the scenario): > > > > > > T0 T1 T2 > > > -- -- -- > > > unfair_read_lock(A); > > > write_lock(B); > > > write_lock(A); > > > write_lock(B); > > > fair_read_lock(A); > > > write_unlock(B); > > > read_unlock(A); > > > read_unlock(A); > > > write_unlock(B); > > > write_unlock(A); > > > > > > T0: read_unlock(A) cannot happen if write_lock(B) is stuck by a B owner > >
Re: [PATCH RFC v7 00/23] DEPT(Dependency Tracker)
On Thu, Jan 19, 2023 at 06:23:49PM -0800, Boqun Feng wrote: > On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote: > > Boqun wrote: > > > On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote: > > > > On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote: > > > > > Boqun wrote: > > > > > > *Looks like the DEPT dependency graph doesn't handle the > > > > > > fair/unfair readers as lockdep current does. Which bring the > > > > > > next question. > > > > > > > > > > No. DEPT works better for unfair read. It works based on wait/event. > > > > > So > > > > > read_lock() is considered a potential wait waiting on write_unlock() > > > > > while write_lock() is considered a potential wait waiting on either > > > > > write_unlock() or read_unlock(). DEPT is working perfect for it. > > > > > > > > > > For fair read (maybe you meant queued read lock), I think the case > > > > > should be handled in the same way as normal lock. I might get it > > > > > wrong. > > > > > Please let me know if I miss something. > > > > > > > > From the lockdep/DEPT point of view, the question is whether: > > > > > > > > read_lock(A) > > > > read_lock(A) > > > > > > > > can deadlock if a writer comes in between the two acquisitions and > > > > sleeps waiting on A to be released. A fair lock will block new > > > > readers when a writer is waiting, while an unfair lock will allow > > > > new readers even while a writer is waiting. > > > > > > > > > > To be more accurate, a fair reader will wait if there is a writer > > > waiting for other reader (fair or not) to unlock, and an unfair reader > > > won't. > > > > What a kind guys, both of you! Thanks. > > > > I asked to check if there are other subtle things than this. Fortunately, > > I already understand what you guys shared. > > > > > In kernel there are read/write locks that can have both fair and unfair > > > readers (e.g. queued rwlock). Regarding deadlocks, > > > > > > T0 T1 T2 > > > -- -- -- > > > fair_read_lock(A); > > > write_lock(B); > > > write_lock(A); > > > write_lock(B); > > > unfair_read_lock(A); > > > > With the DEPT's point of view (let me re-write the scenario): > > > > T0 T1 T2 > > -- -- -- > > fair_read_lock(A); > > write_lock(B); > > write_lock(A); > > write_lock(B); > > unfair_read_lock(A); > > write_unlock(B); > > read_unlock(A); > > read_unlock(A); > > write_unlock(B); > > write_unlock(A); > > > > T0: read_unlock(A) cannot happen if write_lock(B) is stuck by a B owner > > not doing either write_unlock(B) or read_unlock(B). In other words: > > > > 1. read_unlock(A) happening depends on write_unlock(B) happening. > > 2. read_unlock(A) happening depends on read_unlock(B) happening. > > > > T1: write_unlock(B) cannot happen if unfair_read_lock(A) is stuck by a A > > owner not doing write_unlock(A). In other words: > > > > 3. write_unlock(B) happening depends on write_unlock(A) happening. > > > > 1, 2 and 3 give the following dependencies: > > > > 1. read_unlock(A) -> write_unlock(B) > > 2. read_unlock(A) -> read_unlock(B) > > 3. write_unlock(B) -> write_unlock(A) > > > > There's no circular dependency so it's safe. DEPT doesn't report this. > > > > > the above is not a deadlock, since T1's unfair reader can "steal" the > > > lock. However the following is a deadlock: > > > > > > T0 T1 T2 > > > -- -- -- > > > unfair_read_lock(A); > > > write_lock(B); > > > write_lock(A); > > > write_lock(B); > > > fair_read_lock(A); > > > > > > , since T'1 fair reader will wait. > > > > With the DEPT's point of view (let me re-write the scenario): > > > > T0 T1 T2 > > -- -- -- > > unfair_read_lock(A); > > write_lock(B); > > write_lock(A); > > write_lock(B); > > fair_read_lock(A); > > write_unlock(B); > > read_unlock(A); > > read_unlock(A); > > write_unlock(B); > > write_unlock(A); > > > > T0: read_unlock(A) cannot happen if write_lock(B) is stuck by a B owner > > not doing either write_unlock(B) or read_unlock(B). In other words: > > > > 1. read_unlock(A) happening depends on write_unlock(B) happening. > > 2. read_unlock(A) happening depends on read_unlock(B) happening. > > > > T1: write_unlock(B) cannot happen if fair_read_lock(A) is stuck by a A > > owner not doing eithe
[git pull] drm fixes for 6.2-rc5
Hi Linus, Just a pretty regular week for this stage of things, amdgpu and i915, along with some msm and misc others. Dave. drm-fixes-2023-01-20: drm fixes for 6.2-rc5 fb-helper: - switcheroo fix msm: - kexec shutdown fix - fix potential double free i915: - Reject display plane with height == 0 - re-disable RC6p on Sandy Bridge - Fix hugepages' selftest - DG2 hw workarounds - switcheroo fix vc4: - fix a memory leak panfrost: - Kconfig fix amdgpu: - Fix display scaling - Fix RN/CZN power reporting on some firmware versions - Colorspace fixes - Fix resource freeing in error case in CS IOCTL - Fix warning on driver unload - GC11 fixes - DCN 3.1.4/5 S/G display workarounds The following changes since commit 5dc4c995db9eb45f6373a956eb1f69460e69e6d4: Linux 6.2-rc4 (2023-01-15 09:22:43 -0600) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-01-20 for you to fetch changes up to 3f30a6e67ce49c0068f8058893326db46b6db11f: Merge tag 'amd-drm-fixes-6.2-2023-01-19' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2023-01-20 11:21:20 +1000) drm fixes for 6.2-rc5 fb-helper: - switcheroo fix msm: - kexec shutdown fix - fix potential double free i915: - Reject display plane with height == 0 - re-disable RC6p on Sandy Bridge - Fix hugepages' selftest - DG2 hw workarounds - switcheroo fix vc4: - fix a memory leak panfrost: - Kconfig fix amdgpu: - Fix display scaling - Fix RN/CZN power reporting on some firmware versions - Colorspace fixes - Fix resource freeing in error case in CS IOCTL - Fix warning on driver unload - GC11 fixes - DCN 3.1.4/5 S/G display workarounds Alex Deucher (2): drm/amd/display: disable S/G display on DCN 3.1.5 drm/amd/display: disable S/G display on DCN 3.1.4 Arnd Bergmann (1): drm/panfrost: fix GENERIC_ATOMIC64 dependency Chris Wilson (1): drm/i915/selftests: Unwind hugepages to drop wakeref on error Christian König (2): drm/amdgpu: fix cleaning up reserved VMID on release drm/amdgpu: fix amdgpu_job_free_resources v2 Dave Airlie (4): Merge tag 'drm-msm-fixes-2023-01-16' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Merge tag 'drm-intel-fixes-2023-01-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-misc-fixes-2023-01-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'amd-drm-fixes-6.2-2023-01-19' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Drew Davenport (1): drm/i915/display: Check source height is > 0 Hamza Mahfooz (1): drm/amd/display: fix issues with driver unload Joel Fernandes (Google) (1): adreno: Shutdown the GPU properly Joshua Ashton (2): drm/amd/display: Calculate output_color_space after pixel encoding adjustment drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix Lang Yu (2): drm/amdgpu: correct MEC number for gfx11 APUs drm/amdgpu: allow multipipe policy on ASICs with one MEC Matt Atwood (2): drm/i915/dg2: Introduce Wa_18018764978 drm/i915/dg2: Introduce Wa_18019271663 Maxime Ripard (2): drm/vc4: bo: Fix drmm_mutex_init memory hog drm/vc4: bo: Fix unused variable warning Nirmoy Das (1): drm/i915: Remove unused variable Rob Clark (1): drm/msm/gpu: Fix potential double-free Sasa Dragic (1): drm/i915: re-disable RC6p on Sandy Bridge Thomas Zimmermann (2): drm/i915: Allow switching away via vga-switcheroo if uninitialized drm/fb-helper: Set framebuffer for vga-switcheroo clients hongao (1): drm/amd/display: Fix set scaling doesn's work jie1zhan (1): drm/amdgpu: Correct the power calcultion for Renior/Cezanne. drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c| 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 10 -- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 11 +-- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 -- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 1 - drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c | 4 ++-- drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c| 7 ++- drivers/gpu/drm/drm_fb_helper.c| 7 +++ drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +- drivers/gpu/drm/i915/gem/selftests/huge_pages.c| 8 drivers/gpu/drm/i915/gt/intel_gt_regs.h| 10 +++--- drivers/gpu/drm/i915/gt/intel_workarounds.c| 10 +- drivers/gpu/drm/i915/i915_driver.c | 5 + drivers/gpu/drm/i915/i915_pci.c| 3 ++- drivers/gpu/drm/i915/i915_switcher
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes
On 2023.01.19 17:05:56 -0500, Rodrigo Vivi wrote: > > It still doesn't apply in drm-intel-next. > Could you please take it through your branch? > sure, I'll pick it. signature.asc Description: PGP signature
Re: [PATCH RFC v7 00/23] DEPT(Dependency Tracker)
On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote: > Boqun wrote: > > On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote: > > > On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote: > > > > Boqun wrote: > > > > > *Looks like the DEPT dependency graph doesn't handle the > > > > > fair/unfair readers as lockdep current does. Which bring the > > > > > next question. > > > > > > > > No. DEPT works better for unfair read. It works based on wait/event. So > > > > read_lock() is considered a potential wait waiting on write_unlock() > > > > while write_lock() is considered a potential wait waiting on either > > > > write_unlock() or read_unlock(). DEPT is working perfect for it. > > > > > > > > For fair read (maybe you meant queued read lock), I think the case > > > > should be handled in the same way as normal lock. I might get it wrong. > > > > Please let me know if I miss something. > > > > > > From the lockdep/DEPT point of view, the question is whether: > > > > > > read_lock(A) > > > read_lock(A) > > > > > > can deadlock if a writer comes in between the two acquisitions and > > > sleeps waiting on A to be released. A fair lock will block new > > > readers when a writer is waiting, while an unfair lock will allow > > > new readers even while a writer is waiting. > > > > > > > To be more accurate, a fair reader will wait if there is a writer > > waiting for other reader (fair or not) to unlock, and an unfair reader > > won't. > > What a kind guys, both of you! Thanks. > > I asked to check if there are other subtle things than this. Fortunately, > I already understand what you guys shared. > > > In kernel there are read/write locks that can have both fair and unfair > > readers (e.g. queued rwlock). Regarding deadlocks, > > > > T0 T1 T2 > > -- -- -- > > fair_read_lock(A); > > write_lock(B); > > write_lock(A); > > write_lock(B); > > unfair_read_lock(A); > > With the DEPT's point of view (let me re-write the scenario): > > T0 T1 T2 > -- -- -- > fair_read_lock(A); > write_lock(B); > write_lock(A); > write_lock(B); > unfair_read_lock(A); > write_unlock(B); > read_unlock(A); > read_unlock(A); > write_unlock(B); > write_unlock(A); > > T0: read_unlock(A) cannot happen if write_lock(B) is stuck by a B owner > not doing either write_unlock(B) or read_unlock(B). In other words: > > 1. read_unlock(A) happening depends on write_unlock(B) happening. > 2. read_unlock(A) happening depends on read_unlock(B) happening. > > T1: write_unlock(B) cannot happen if unfair_read_lock(A) is stuck by a A > owner not doing write_unlock(A). In other words: > > 3. write_unlock(B) happening depends on write_unlock(A) happening. > > 1, 2 and 3 give the following dependencies: > > 1. read_unlock(A) -> write_unlock(B) > 2. read_unlock(A) -> read_unlock(B) > 3. write_unlock(B) -> write_unlock(A) > > There's no circular dependency so it's safe. DEPT doesn't report this. > > > the above is not a deadlock, since T1's unfair reader can "steal" the > > lock. However the following is a deadlock: > > > > T0 T1 T2 > > -- -- -- > > unfair_read_lock(A); > > write_lock(B); > > write_lock(A); > > write_lock(B); > > fair_read_lock(A); > > > > , since T'1 fair reader will wait. > > With the DEPT's point of view (let me re-write the scenario): > > T0 T1 T2 > -- -- -- > unfair_read_lock(A); > write_lock(B); > write_lock(A); > write_lock(B); > fair_read_lock(A); > write_unlock(B); > read_unlock(A); > read_unlock(A); > write_unlock(B); > write_unlock(A); > > T0: read_unlock(A) cannot happen if write_lock(B) is stuck by a B owner > not doing either write_unlock(B) or read_unlock(B). In other words: > > 1. read_unlock(A) happening depends on write_unlock(B) happening. > 2. read_unlock(A) happening depends on read_unlock(B) happening. > > T1: write_unlock(B) cannot happen if fair_read_lock(A) is stuck by a A > owner not doing either write_unlock(A) or read_unlock(A). In other > words: > > 3. write_unlock(B) happening depends on write_unlock(A) happening. > 4. write_unlock(B) happening depends on read_unlock(A) happening. > > 1, 2, 3 and 4 give the f
Re: [PATCH v3 5/6] drm/i915/guc: Look for a guilty context when an engine reset fails
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC intentionally dies on such a situation,
it is not possible to get a guilty context notification back. So do a
manual search instead. Given that GuC is dead, this is safe because
GuC won't be changing the engine state asynchronously.
v2: Change comment to be less alarming (Tvrtko)
Signed-off-by: John Harrison
Acked-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index d123cbd90a919..7c5ea66218443 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4756,11 +4756,24 @@ static void reset_fail_worker_func(struct work_struct
*w)
guc->submission_state.reset_fail_mask = 0;
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
- if (likely(reset_fail_mask))
+ if (likely(reset_fail_mask)) {
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ /*
+* GuC is toast at this point - it dead loops after sending the
failed
+* reset notification. So need to manually determine the guilty
context.
+* Note that it should be reliable to do this here because the
GuC is
+* toast and will not be scheduling behind the KMD's back.
+*/
+ for_each_engine_masked(engine, gt, reset_fail_mask, id)
+ intel_guc_find_hung_context(engine);
I double checked and AFAICS this behavior applies to all our supported
GuC versions, so:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
+
intel_gt_handle_error(gt, reset_fail_mask,
I915_ERROR_CAPTURE,
- "GuC failed to reset engine mask=0x%x\n",
+ "GuC failed to reset engine mask=0x%x",
reset_fail_mask);
+ }
}
int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
Re: [Intel-gfx] [PATCH v3 3/6] drm/i915: Allow error capture without a request
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active requests. For example, if the hang was in the context switch
itself then the breadcrumb write would have occurred and the KMD would
see an idle context.
In the interests of attempting to provide as much information as
possible about a hang, it seems wise to include the engine info
regardless of whether a request was found or not. As opposed to just
prentending there was no hang at all.
So update the error capture code to always record engine information
if a context is given. Which means updating record_context() to take a
context instead of a request (which it only ever used to find the
context anyway). And split the request agnostic parts of
intel_engine_coredump_add_request() out into a seaprate function.
v2: Remove a duplicate 'if' statement (Umesh) and fix a put of a null
pointer.
v3: Tidy up request locking code flow (Tvrtko)
Signed-off-by: John Harrison
Reviewed-by: Umesh Nerlige Ramappa
Acked-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gpu_error.c | 70 ++-
1 file changed, 48 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 78cf95e4dd230..743614fff5472 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1370,14 +1370,14 @@ static void engine_record_execlists(struct
intel_engine_coredump *ee)
}
static bool record_context(struct i915_gem_context_coredump *e,
- const struct i915_request *rq)
+ struct intel_context *ce)
{
struct i915_gem_context *ctx;
struct task_struct *task;
bool simulated;
rcu_read_lock();
- ctx = rcu_dereference(rq->context->gem_context);
+ ctx = rcu_dereference(ce->gem_context);
if (ctx && !kref_get_unless_zero(&ctx->ref))
ctx = NULL;
rcu_read_unlock();
@@ -1396,8 +1396,8 @@ static bool record_context(struct
i915_gem_context_coredump *e,
e->guilty = atomic_read(&ctx->guilty_count);
e->active = atomic_read(&ctx->active_count);
- e->total_runtime = intel_context_get_total_runtime_ns(rq->context);
- e->avg_runtime = intel_context_get_avg_runtime_ns(rq->context);
+ e->total_runtime = intel_context_get_total_runtime_ns(ce);
+ e->avg_runtime = intel_context_get_avg_runtime_ns(ce);
simulated = i915_gem_context_no_error_capture(ctx);
@@ -1532,15 +1532,37 @@ intel_engine_coredump_alloc(struct intel_engine_cs *engine, gfp_t gfp, u32 dump_
return ee;
}
+static struct intel_engine_capture_vma *
+engine_coredump_add_context(struct intel_engine_coredump *ee,
+ struct intel_context *ce,
+ gfp_t gfp)
+{
+ struct intel_engine_capture_vma *vma = NULL;
+
+ ee->simulated |= record_context(&ee->context, ce);
+ if (ee->simulated)
+ return NULL;
+
+ /*
+* We need to copy these to an anonymous buffer
+* as the simplest method to avoid being overwritten
+* by userspace.
+*/
+ vma = capture_vma(vma, ce->ring->vma, "ring", gfp);
+ vma = capture_vma(vma, ce->state, "HW context", gfp);
+
+ return vma;
+}
+
struct intel_engine_capture_vma *
intel_engine_coredump_add_request(struct intel_engine_coredump *ee,
struct i915_request *rq,
gfp_t gfp)
{
- struct intel_engine_capture_vma *vma = NULL;
+ struct intel_engine_capture_vma *vma;
- ee->simulated |= record_context(&ee->context, rq);
- if (ee->simulated)
+ vma = engine_coredump_add_context(ee, rq->context, gfp);
+ if (!vma)
return NULL;
/*
@@ -1550,8 +1572,6 @@ intel_engine_coredump_add_request(struct
intel_engine_coredump *ee,
*/
vma = capture_vma_snapshot(vma, rq->batch_res, gfp, "batch");
vma = capture_user(vma, rq, gfp);
- vma = capture_vma(vma, rq->ring->vma, "ring", gfp);
- vma = capture_vma(vma, rq->context->state, "HW context", gfp);
ee->rq_head = rq->head;
ee->rq_post = rq->postfix;
@@ -1604,25 +1624,31 @@ capture_engine(struct intel_engine_cs *engine,
return NULL;
intel_get_hung_entity(engine, &ce, &rq);
- if (!rq || !i915_request_started(rq))
- goto no_request_capture;
+ if (rq && !i915_request_started(rq)) {
+ drm_info(&engine->gt->i915->drm, "Got hung context on %s with no
active request!\n",
+engine->name);
Shouldn't this print be
Re: [PATCH RFC v7 00/23] DEPT(Dependency Tracker)
Boqun wrote: > On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote: > > On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote: > > > Boqun wrote: > > > > *Looks like the DEPT dependency graph doesn't handle the > > > > fair/unfair readers as lockdep current does. Which bring the > > > > next question. > > > > > > No. DEPT works better for unfair read. It works based on wait/event. So > > > read_lock() is considered a potential wait waiting on write_unlock() > > > while write_lock() is considered a potential wait waiting on either > > > write_unlock() or read_unlock(). DEPT is working perfect for it. > > > > > > For fair read (maybe you meant queued read lock), I think the case > > > should be handled in the same way as normal lock. I might get it wrong. > > > Please let me know if I miss something. > > > > From the lockdep/DEPT point of view, the question is whether: > > > > read_lock(A) > > read_lock(A) > > > > can deadlock if a writer comes in between the two acquisitions and > > sleeps waiting on A to be released. A fair lock will block new > > readers when a writer is waiting, while an unfair lock will allow > > new readers even while a writer is waiting. > > > > To be more accurate, a fair reader will wait if there is a writer > waiting for other reader (fair or not) to unlock, and an unfair reader > won't. What a kind guys, both of you! Thanks. I asked to check if there are other subtle things than this. Fortunately, I already understand what you guys shared. > In kernel there are read/write locks that can have both fair and unfair > readers (e.g. queued rwlock). Regarding deadlocks, > > T0 T1 T2 > -- -- -- > fair_read_lock(A); > write_lock(B); > write_lock(A); > write_lock(B); > unfair_read_lock(A); With the DEPT's point of view (let me re-write the scenario): T0 T1 T2 -- -- -- fair_read_lock(A); write_lock(B); write_lock(A); write_lock(B); unfair_read_lock(A); write_unlock(B); read_unlock(A); read_unlock(A); write_unlock(B); write_unlock(A); T0: read_unlock(A) cannot happen if write_lock(B) is stuck by a B owner not doing either write_unlock(B) or read_unlock(B). In other words: 1. read_unlock(A) happening depends on write_unlock(B) happening. 2. read_unlock(A) happening depends on read_unlock(B) happening. T1: write_unlock(B) cannot happen if unfair_read_lock(A) is stuck by a A owner not doing write_unlock(A). In other words: 3. write_unlock(B) happening depends on write_unlock(A) happening. 1, 2 and 3 give the following dependencies: 1. read_unlock(A) -> write_unlock(B) 2. read_unlock(A) -> read_unlock(B) 3. write_unlock(B) -> write_unlock(A) There's no circular dependency so it's safe. DEPT doesn't report this. > the above is not a deadlock, since T1's unfair reader can "steal" the > lock. However the following is a deadlock: > > T0 T1 T2 > -- -- -- > unfair_read_lock(A); > write_lock(B); > write_lock(A); > write_lock(B); > fair_read_lock(A); > > , since T'1 fair reader will wait. With the DEPT's point of view (let me re-write the scenario): T0 T1 T2 -- -- -- unfair_read_lock(A); write_lock(B); write_lock(A); write_lock(B); fair_read_lock(A); write_unlock(B); read_unlock(A); read_unlock(A); write_unlock(B); write_unlock(A); T0: read_unlock(A) cannot happen if write_lock(B) is stuck by a B owner not doing either write_unlock(B) or read_unlock(B). In other words: 1. read_unlock(A) happening depends on write_unlock(B) happening. 2. read_unlock(A) happening depends on read_unlock(B) happening. T1: write_unlock(B) cannot happen if fair_read_lock(A) is stuck by a A owner not doing either write_unlock(A) or read_unlock(A). In other words: 3. write_unlock(B) happening depends on write_unlock(A) happening. 4. write_unlock(B) happening depends on read_unlock(A) happening. 1, 2, 3 and 4 give the following dependencies: 1. read_unlock(A) -> write_unlock(B) 2. read_unlock(A) -> read_unlock(B) 3. write_unlock(B) -> write_unlock(A) 4. write_unlock(B) -> read_unlock(A) With 1 and 4, there's a circular dependency
Re: [Intel-gfx] [PATCH v3 2/6] drm/i915: Fix up locking around dumping requests lists
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the error capture code.
So refactor the hung request search into a re-usable function. And
reduce the span of the execlist state lock to only the execlist
specific code paths.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_context.c | 29 +
drivers/gpu/drm/i915/gt/intel_context.h | 3 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 51 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 27 ++--
4 files changed, 60 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index e7c5509c48ef1..a61f052092ed9 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -559,6 +559,35 @@ struct i915_request
*intel_context_find_active_request(struct intel_context *ce)
return active;
}
+void intel_get_hung_entity(struct intel_engine_cs *engine,
+ struct intel_context **ce, struct i915_request **rq)
IMO this belongs in the engine_cs.c file, given that the engine is the
input. Might also be worth renaming to intel_engine_*
+{
+ unsigned long flags;
+
+ *ce = intel_engine_get_hung_context(engine);
+ if (*ce) {
+ intel_engine_clear_hung_context(engine);
+
+ /* This will reference count the request (if found) */
+ *rq = intel_context_find_active_request(*ce);
+
+ return;
+ }
+
+ /*
+* Getting here with GuC enabled means it is a forced error capture
+* with no actual hang. So, no need to attempt the execlist search.
+*/
+ if (intel_uc_uses_guc_submission(&engine->gt->uc))
+ return;
+
+ spin_lock_irqsave(&engine->sched_engine->lock, flags);
+ *rq = intel_engine_execlist_find_hung_request(engine);
+ if (*rq)
+ *rq = i915_request_get_rcu(*rq);
+ spin_unlock_irqrestore(&engine->sched_engine->lock, flags);
+}
+
void intel_context_bind_parent_child(struct intel_context *parent,
struct intel_context *child)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index fb62b7b8cbcda..ca50f3312a941 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -271,6 +271,9 @@ struct i915_request *intel_context_create_request(struct
intel_context *ce);
struct i915_request *
intel_context_find_active_request(struct intel_context *ce);
+void intel_get_hung_entity(struct intel_engine_cs *engine,
+ struct intel_context **ce, struct i915_request **rq);
+
static inline bool intel_context_is_barrier(const struct intel_context *ce)
{
return test_bit(CONTEXT_BARRIER_BIT, &ce->flags);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 6a082658d0082..5e173dfc8849e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2216,11 +2216,27 @@ void intel_engine_dump_active_requests(struct list_head
*requests,
}
}
-static void engine_dump_active_requests(struct intel_engine_cs *engine, struct drm_printer *m)
+static void execlist_dump_active_requests(struct intel_engine_cs *engine,
Might be worth moving this to the execlists submission file, to be
symmetrical with the GuC submission one. Other execlists functions are
in this file though, so not a blocker.
+ struct i915_request *hung_rq,
+ struct drm_printer *m)
{
+ unsigned long flags;
+
+ spin_lock_irqsave(&engine->sched_engine->lock, flags);
+
+ intel_engine_dump_active_requests(&engine->sched_engine->requests,
hung_rq, m);
+
+ drm_printf(m, "\tOn hold?: %lu\n",
+ list_count(&engine->sched_engine->hold));
+
+ spin_unlock_irqrestore(&engine->sched_engine->lock, flags);
+}
+
+static void engine_dump_active_requests(struct intel_engine_cs *engine,
+ struct drm_printer *m)
+{
+ struct intel_context *hung_ce = NULL;
struct i915_request *hung_rq = NULL;
- struct intel_context *ce;
- bool guc;
/*
* No need for an engine->irq_seqno_barrier() before the seqno reads.
@@ -2229,31 +2245,20 @@ static void engine_dump_active_requests(struct
intel_engine_cs *engine, struct d
* But the intention here is just to report an instantaneous snapshot
* so that's fine.
*/
- lockdep_assert_held(&engine->sched_engine->lock);
+ intel_get_hung_entity(engi
Re: [PATCH v3 1/6] drm/i915: Fix request locking during error capture & debugfs dump
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking around the search
internally. So it needs to grab the reference count internally as
well. The execlist only request based search relies on external
locking, so it needs an external reference count but within the
spinlock not outside it.
The only other caller of the context based search is the code for
dumping engine state to debugfs. That code wasn't previously getting
an explicit reference at all as it does everything while holding the
execlist specific spinlock. So, that needs updaing as well as that
spinlock doesn't help when using GuC submission. Rather than trying to
conditionally get/put depending on submission model, just change it to
always do the get/put.
In addition, intel_guc_find_hung_context() was not acquiring the
correct spinlock before searching the request list. So fix that up
too. While at it, add some extra whitespace padding for readability.
v2: Explicitly document adding an extra blank line in some dense code
(Andy Shevchenko). Fix multiple potential null pointer derefs in case
of no request found (some spotted by Tvrtko, but there was more!).
Also fix a leaked request in case of !started and another in
__guc_reset_context now that intel_context_find_active_request is
actually reference counting the returned request.
Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset with
GuC")
Fixes: 573ba126aef3 ("drm/i915/guc: Capture error state on context reset")
Cc: Matthew Brost
Cc: John Harrison
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Cc: Andrzej Hajda
Cc: Matthew Auld
Cc: Matt Roper
Cc: Umesh Nerlige Ramappa
Cc: Michael Cheng
Cc: Lucas De Marchi
Cc: Tejas Upadhyay
Cc: Andy Shevchenko
Cc: Aravind Iddamsetty
Cc: Alan Previn
Cc: Bruce Chang
Cc: intel-...@lists.freedesktop.org
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 13 +
drivers/gpu/drm/i915/i915_gpu_error.c | 12 ++--
4 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index e94365b08f1ef..e7c5509c48ef1 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -552,6 +552,8 @@ struct i915_request
*intel_context_find_active_request(struct intel_context *ce)
Might be worth renaming this to intel_context_active_request_get(..), to
make it clear that it does take a reference. Not a blocker.
active = rq;
}
+ if (active)
+ active = i915_request_get_rcu(active);
spin_unlock_irqrestore(&parent->guc_state.lock, flags);
return active;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 922f1bb22dc68..6a082658d0082 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2236,10 +2236,14 @@ static void engine_dump_active_requests(struct
intel_engine_cs *engine, struct d
guc = intel_uc_uses_guc_submission(&engine->gt->uc);
if (guc) {
ce = intel_engine_get_hung_context(engine);
- if (ce)
+ if (ce) {
+ /* This will reference count the request (if found) */
hung_rq = intel_context_find_active_request(ce);
+ }
} else {
hung_rq = intel_engine_execlist_find_hung_request(engine);
+ if (hung_rq)
+ hung_rq = i915_request_get_rcu(hung_rq);
}
Not a fan of the behavior asymmetry, but given that the 2 flows are
completely different I can't think of anything cleaner, so:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
if (hung_rq)
@@ -2250,6 +2254,8 @@ static void engine_dump_active_requests(struct
intel_engine_cs *engine, struct d
else
intel_engine_dump_active_requests(&engine->sched_engine->requests,
hung_rq, m);
+ if (hung_rq)
+ i915_request_put(hung_rq);
}
void intel_engine_dump(struct intel_engine_cs *engine,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b436dd7f12e42..d123cbd90a919 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1702,6 +1702,7 @@ static void __guc_reset_context(struct intel_context *ce,
intel_engine_mask_t st
goto next_context;
gu
linux-next: manual merge of the accel tree with the drm-misc tree
Hi all,
Today's linux-next merge of the accel tree got conflicts in:
drivers/Makefile
drivers/accel/Kconfig
drivers/accel/Makefile
between commit:
35b137630f08 ("accel/ivpu: Introduce a new DRM driver for Intel VPU")
from the drm-misc tree and commit:
45886b6fa0f1 ("habanalabs: move driver to accel subsystem")
from the accel tree.
I fixed it up (I used the latter version of Makefile and see below) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/accel/Kconfig
index 4989376e5938,a5989b55178a..
--- a/drivers/accel/Kconfig
+++ b/drivers/accel/Kconfig
@@@ -23,4 -23,4 +23,5 @@@ menuconfig DRM_ACCE
different device files, called accel/accel* (in /dev, sysfs
and debugfs).
+ source "drivers/accel/habanalabs/Kconfig"
+source "drivers/accel/ivpu/Kconfig"
diff --cc drivers/accel/Makefile
index b1036dbc0ba4,4df38885d6c6..
--- a/drivers/accel/Makefile
+++ b/drivers/accel/Makefile
@@@ -1,3 -1,3 +1,4 @@@
# SPDX-License-Identifier: GPL-2.0-only
-obj-y += habanalabs/
++obj-y += habanalabs/
+obj-y += ivpu/
pgp_2r3NBNODb.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 1/9] drm/i915/pxp: Add MTL PXP GSC-CS back-end skeleton
Thanks for reviewing Daniele - will fix these on re-rev. And you're right - we dont need a variable "gsccs" (so HAS_ENGINE should work fine). On Wed, 2023-01-18 at 09:51 -0800, Ceraolo Spurio, Daniele wrote: > > Alan: [snip]
Re: [PATCH v6 2/2] drm/msm/dp: enhance dp controller isr
Hi,
On Wed, Jan 18, 2023 at 2:34 PM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2023-01-18 10:29:59)
> > Hi,
> >
> > On Tue, Dec 27, 2022 at 6:16 PM Kuogee Hsieh
> > wrote:
> > > +
> > > if (isr & DP_INTR_AUX_ERROR) {
> > > aux->aux_error_num = DP_AUX_ERR_PHY;
> > > dp_catalog_aux_clear_hw_interrupts(aux->catalog);
> > > + ret = IRQ_HANDLED;
> > > }
> >
> > The end result of the above is a weird mix of "if" and "else if" for
> > no apparent reason. All except one of them just updates the exact same
> > variable so doing more than one is mostly useless. If you made it
> > consistently with "else" then the whole thing could be much easier,
> > like this (untested):
>
> Totally agreed. I even asked that when I posted the RFC[1]!
>
> "Can we also simplify the aux handlers to be a big pile of
> if-else-if conditions that don't overwrite the 'aux_error_num'? That
> would simplify the patch below."
>
> > > @@ -425,17 +464,15 @@ void dp_aux_isr(struct drm_dp_aux *dp_aux)
> > >
> > > /* no interrupts pending, return immediately */
> > > if (!isr)
> > > - return;
> > > + return IRQ_NONE;
> > >
> > > if (!aux->cmd_busy)
> > > - return;
> > > + return IRQ_NONE;
> > >
> > > if (aux->native)
> > > - dp_aux_native_handler(aux, isr);
> > > + return dp_aux_native_handler(aux, isr);
> > > else
> > > - dp_aux_i2c_handler(aux, isr);
> > > -
> > > - complete(&aux->comp);
> > > + return dp_aux_i2c_handler(aux, isr);
> >
> > Personally, I wouldn't have done it this way. I guess that means I
> > disagree with Stephen. I'm not dead-set against this way and it's fine
> > if you want to continue with it. If I were doing it, though, then I
> > would always return IRQ_HANDLED IF dp_catalog_aux_get_irq() returned
> > anything non-zero. Why? Officially if dp_catalog_aux_get_irq() returns
> > something non-zero then you know for sure that there was an interrupt
> > for this device and officially you have "handled" it by acking it,
> > since dp_catalog_aux_get_irq() acks all the bits that it returns. That
> > means that even if dp_aux_native_handler() or dp_aux_i2c_handler()
> > didn't do anything with the interrupt you at least know that it was
> > for us (so if the IRQ is shared we properly report back to the IRQ
> > subsystem) and that it won't keep firing over and over (because we
> > acked it).
>
> I'm primarily concerned with irq storms taking down the system. Can that
> happen here? If not, then returning IRQ_NONE is not really useful. The
> overall IRQ for DP looks to be level, because the driver requests the
> IRQ that way. The aux interrupt status bits look to be edge style
> interrupts though, because the driver acks them in the handler. I guess
> that means the edges come in and latch into the interrupt status
> register so the driver has to ack all of them to drop the IRQ level for
> the overall DP interrupt? If the driver only acked the bits it looked at
> instead of all interrupt bits in the register, then the level would
> never go down for the IRQ if an unhandled interrupt bit was present like
> 'DP_INTR_PLL_UNLOCKED'. That would mean we would hit spurious IRQ
> handling very quickly if that interrupt bit was ever seen.
>
> But the driver is acking all interrupts, so probably trying to work
> IRQ_NONE into this code is not very useful? The only thing it would
> catch is DP_INTR_PLL_UNLOCKED being set over and over again, which seems
> unlikely. Of course, why is this driver unmasking interrupt bits it
> doesn't care about? That may be leading to useless interrupt handling in
> this driver if some interrupt bit is unmasked but never looked at. Can
> that be fixed in another patch?
>
> >
> > NOTE: I still like having the complete() call in
> > dp_aux_native_handler() and dp_aux_i2c_handler() and, to me, that part
> > of this patch is worthwhile. That makes it more obvious that the code
> > is truly expecting that complete to be called for all error cases as
> > well as transfer finished.
> >
>
> I think it may be required. We don't want to allow DP_INTR_PLL_UNLOCKED
> to complete() the transfer.
OK, I've tried to code up what I think is the right solution. I'd
appreciate review and testing.
https://lore.kernel.org/r/20230119145248.1.I90ffed3ddd21e818ae534f820cb4d6d8638859ab@changeid
-Doug
[PATCH 6/7] drm/amdgpu/display/mst: adjust the naming of mst_port and port of aconnector
From: Wayne Lin
[why & how]
The term (i.e. port & mst_port) that we used to use in amdgpu is a bit
confusing. Rename them to mst_output_port & mst_root respectively.
Signed-off-by: Wayne Lin
Signed-off-by: Harry Wentland
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 4 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4 +-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 2 +-
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 16 +++
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 19
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 48 +--
7 files changed, 59 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index bf009de59710..c1ece3d2ea36 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -551,8 +551,8 @@ struct amdgpu_mst_connector {
struct drm_dp_mst_topology_mgr mst_mgr;
struct amdgpu_dm_dp_aux dm_dp_aux;
- struct drm_dp_mst_port *port;
- struct amdgpu_connector *mst_port;
+ struct drm_dp_mst_port *mst_output_port;
+ struct amdgpu_connector *mst_root;
bool is_mst_connector;
struct amdgpu_encoder *mst_encoder;
};
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 4c5b8793b8af..291dea18c658 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2197,7 +2197,7 @@ static void s3_handle_mst(struct drm_device *dev, bool
suspend)
drm_for_each_connector_iter(connector, &iter) {
aconnector = to_amdgpu_dm_connector(connector);
if (aconnector->dc_link->type != dc_connection_mst_branch ||
- aconnector->mst_port)
+ aconnector->mst_root)
continue;
mgr = &aconnector->mst_mgr;
@@ -6582,11 +6582,11 @@ static int dm_encoder_helper_atomic_check(struct
drm_encoder *encoder,
int clock, bpp = 0;
bool is_y420 = false;
- if (!aconnector->port || !aconnector->dc_sink)
+ if (!aconnector->mst_output_port || !aconnector->dc_sink)
return 0;
- mst_port = aconnector->port;
- mst_mgr = &aconnector->mst_port->mst_mgr;
+ mst_port = aconnector->mst_output_port;
+ mst_mgr = &aconnector->mst_root->mst_mgr;
if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
return 0;
@@ -6596,7 +6596,7 @@ static int dm_encoder_helper_atomic_check(struct
drm_encoder *encoder,
return PTR_ERR(mst_state);
if (!mst_state->pbn_div)
- mst_state->pbn_div =
dm_mst_get_pbn_divider(aconnector->mst_port->dc_link);
+ mst_state->pbn_div =
dm_mst_get_pbn_divider(aconnector->mst_root->dc_link);
if (!state->duplicated) {
int max_bpc = conn_state->max_requested_bpc;
@@ -6642,7 +6642,7 @@ static int dm_update_mst_vcpi_slots_for_dsc(struct
drm_atomic_state *state,
aconnector = to_amdgpu_dm_connector(connector);
- if (!aconnector->port)
+ if (!aconnector->mst_output_port)
continue;
if (!new_con_state || !new_con_state->crtc)
@@ -6682,7 +6682,7 @@ static int dm_update_mst_vcpi_slots_for_dsc(struct
drm_atomic_state *state,
dm_conn_state->pbn = pbn;
dm_conn_state->vcpi_slots = slot_num;
- ret = drm_dp_mst_atomic_enable_dsc(state,
aconnector->port,
+ ret = drm_dp_mst_atomic_enable_dsc(state,
aconnector->mst_output_port,
dm_conn_state->pbn,
false);
if (ret < 0)
return ret;
@@ -6690,7 +6690,7 @@ static int dm_update_mst_vcpi_slots_for_dsc(struct
drm_atomic_state *state,
continue;
}
- vcpi = drm_dp_mst_atomic_enable_dsc(state, aconnector->port,
pbn, true);
+ vcpi = drm_dp_mst_atomic_enable_dsc(state,
aconnector->mst_output_port, pbn, true);
if (vcpi < 0)
return vcpi;
@@ -7104,7 +7104,7 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
adev->mode_info.underscan_vborder_property,
0);
- if (!aconnector->mst_port)
+ if (!aconnector->mst_root)
drm_connector_attach_max_bpc_property(&aconnector->base, 8, 16);
/* This defaults to the max in the range, but we want 8bpc for non-edp.
*/
@@ -7122,7 +7122,7 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
[PATCH 5/7] drm/display/dp_mst: Correct the kref of port.
From: Wayne Lin
[why & how]
We still need to refer to port while removing payload at commit_tail.
we should keep the kref till then to release.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Signed-off-by: Wayne Lin
Signed-off-by: Harry Wentland
Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic
state")
Cc: sta...@vger.kernel.org # 6.1
Acked-by: Harry Wentland
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 51a46689cda7..4ca37261584a 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3372,6 +3372,9 @@ void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr
*mgr,
mgr->payload_count--;
mgr->next_start_slot -= payload->time_slots;
+
+ if (payload->delete)
+ drm_dp_mst_put_port_malloc(payload->port);
}
EXPORT_SYMBOL(drm_dp_remove_payload);
@@ -4327,7 +4330,6 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
drm_dbg_atomic(mgr->dev, "[MST PORT:%p] TU %d -> 0\n", port,
payload->time_slots);
if (!payload->delete) {
- drm_dp_mst_put_port_malloc(port);
payload->pbn = 0;
payload->delete = true;
topology_state->payload_mask &= ~BIT(payload->vcpi - 1);
--
2.39.0
[PATCH 7/7] drm/amdgpu/display/mst: adjust the logic in 2nd phase of updating payload
From: Wayne Lin
[why & how]
adjust the coding in dm_helpers_dp_mst_send_payload_allocation()
for reading easily.
Signed-off-by: Wayne Lin
Signed-off-by: Harry Wentland
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 7aff7eb13ea2..fba6a57158cf 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -274,6 +274,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
struct drm_dp_mst_atomic_payload *payload;
enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
+ int ret = 0;
aconnector = (struct amdgpu_dm_connector *)stream->dm_stream_context;
@@ -290,7 +291,10 @@ bool dm_helpers_dp_mst_send_payload_allocation(
clr_flag = MST_ALLOCATE_NEW_PAYLOAD;
}
- if (enable && drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
payload)) {
+ if (enable)
+ ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
payload);
+
+ if (ret) {
amdgpu_dm_set_mst_status(&aconnector->mst_status,
set_flag, false);
} else {
--
2.39.0
[PATCH 3/7] drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD
From: Wayne Lin
[Why & How]
Now the vc_start_slot is controlled at drm side. When we
service a long HPD, we still need to run
dm_helpers_dp_mst_write_payload_allocation_table() to update
drm mst_mgr's relevant variable. Otherwise, on the next plug-in,
payload will get assigned with a wrong start slot.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Signed-off-by: Wayne Lin
Signed-off-by: Harry Wentland
Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic
state")
Cc: sta...@vger.kernel.org # 6.1
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index d9e490eca10f..bf5a31e2be8a 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3999,10 +3999,13 @@ static enum dc_status deallocate_mst_payload(struct
pipe_ctx *pipe_ctx)
struct fixed31_32 avg_time_slots_per_mtp = dc_fixpt_from_int(0);
int i;
bool mst_mode = (link->type == dc_connection_mst_branch);
+ /* adjust for drm changes*/
+ bool update_drm_mst_state = true;
const struct link_hwss *link_hwss = get_link_hwss(link,
&pipe_ctx->link_res);
const struct dc_link_settings empty_link_settings = {0};
DC_LOGGER_INIT(link->ctx->logger);
+
/* deallocate_mst_payload is called before disable link. When mode or
* disable/enable monitor, new stream is created which is not in link
* stream[] yet. For this, payload is not allocated yet, so de-alloc
@@ -4018,7 +4021,7 @@ static enum dc_status deallocate_mst_payload(struct
pipe_ctx *pipe_ctx)
&empty_link_settings,
avg_time_slots_per_mtp);
- if (mst_mode) {
+ if (mst_mode || update_drm_mst_state) {
/* when link is in mst mode, reply on mst manager to remove
* payload
*/
@@ -4081,11 +4084,18 @@ static enum dc_status deallocate_mst_payload(struct
pipe_ctx *pipe_ctx)
stream->ctx,
stream);
+ if (!update_drm_mst_state)
+ dm_helpers_dp_mst_send_payload_allocation(
+ stream->ctx,
+ stream,
+ false);
+ }
+
+ if (update_drm_mst_state)
dm_helpers_dp_mst_send_payload_allocation(
stream->ctx,
stream,
false);
- }
return DC_OK;
}
--
2.39.0
[PATCH 2/7] drm/amdgpu/display/mst: limit payload to be updated one by one
From: Wayne Lin
[Why]
amdgpu expects to update payload table for one stream one time
by calling dm_helpers_dp_mst_write_payload_allocation_table().
Currently, it get modified to try to update HW payload table
at once by referring mst_state.
[How]
This is just a quick workaround. Should find way to remove the
temporary struct dc_dp_mst_stream_allocation_table later if set
struct link_mst_stream_allocatio directly is possible.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Signed-off-by: Wayne Lin
Signed-off-by: Harry Wentland
Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic
state")
Cc: sta...@vger.kernel.org # 6.1
Acked-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 51 ++-
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 6994c9a1ed85..5cff56bb8f56 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -120,23 +120,50 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
}
static void
-fill_dc_mst_payload_table_from_drm(struct drm_dp_mst_topology_state *mst_state,
- struct amdgpu_dm_connector *aconnector,
+fill_dc_mst_payload_table_from_drm(struct dc_link *link,
+ bool enable,
+ struct drm_dp_mst_atomic_payload
*target_payload,
struct dc_dp_mst_stream_allocation_table
*table)
{
struct dc_dp_mst_stream_allocation_table new_table = { 0 };
struct dc_dp_mst_stream_allocation *sa;
- struct drm_dp_mst_atomic_payload *payload;
+ struct link_mst_stream_allocation_table copy_of_link_table =
+
link->mst_stream_alloc_table;
+
+ int i;
+ int current_hw_table_stream_cnt = copy_of_link_table.stream_count;
+ struct link_mst_stream_allocation *dc_alloc;
+
+ /* TODO: refactor to set link->mst_stream_alloc_table directly if
possible.*/
+ if (enable) {
+ dc_alloc =
+
©_of_link_table.stream_allocations[current_hw_table_stream_cnt];
+ dc_alloc->vcp_id = target_payload->vcpi;
+ dc_alloc->slot_count = target_payload->time_slots;
+ } else {
+ for (i = 0; i < copy_of_link_table.stream_count; i++) {
+ dc_alloc =
+ ©_of_link_table.stream_allocations[i];
+
+ if (dc_alloc->vcp_id == target_payload->vcpi) {
+ dc_alloc->vcp_id = 0;
+ dc_alloc->slot_count = 0;
+ break;
+ }
+ }
+ ASSERT(i != copy_of_link_table.stream_count);
+ }
/* Fill payload info*/
- list_for_each_entry(payload, &mst_state->payloads, next) {
- if (payload->delete)
- continue;
-
- sa = &new_table.stream_allocations[new_table.stream_count];
- sa->slot_count = payload->time_slots;
- sa->vcp_id = payload->vcpi;
- new_table.stream_count++;
+ for (i = 0; i < MAX_CONTROLLER_NUM; i++) {
+ dc_alloc =
+ ©_of_link_table.stream_allocations[i];
+ if (dc_alloc->vcp_id > 0 && dc_alloc->slot_count > 0) {
+ sa =
&new_table.stream_allocations[new_table.stream_count];
+ sa->slot_count = dc_alloc->slot_count;
+ sa->vcp_id = dc_alloc->vcp_id;
+ new_table.stream_count++;
+ }
}
/* Overwrite the old table */
@@ -185,7 +212,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
* AUX message. The sequence is slot 1-63 allocated sequence for each
* stream. AMD ASIC stream slot allocation should follow the same
* sequence. copy DRM MST allocation to dc */
- fill_dc_mst_payload_table_from_drm(mst_state, aconnector,
proposed_table);
+ fill_dc_mst_payload_table_from_drm(stream->link, enable, payload,
proposed_table);
return true;
}
--
2.39.0
[PATCH 4/7] drm/drm_print: correct format problem
From: Wayne Lin [why & how] __drm_dbg() parameter set format is wrong and not aligned with the format under CONFIG_DRM_USE_DYNAMIC_DEBUG is on. Fix it. Signed-off-by: Wayne Lin Signed-off-by: Harry Wentland Acked-by: Harry Wentland --- include/drm/drm_print.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index a44fb7ef257f..094ded23534c 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -521,7 +521,7 @@ __printf(1, 2) void __drm_err(const char *format, ...); #if !defined(CONFIG_DRM_USE_DYNAMIC_DEBUG) -#define __drm_dbg(fmt, ...)___drm_dbg(NULL, fmt, ##__VA_ARGS__) +#define __drm_dbg(cat, fmt, ...) ___drm_dbg(NULL, cat, fmt, ##__VA_ARGS__) #else #define __drm_dbg(cat, fmt, ...) \ _dynamic_func_call_cls(cat, fmt, ___drm_dbg,\ -- 2.39.0
[PATCH 1/7] drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignments
From: Lyude Paul
Looks like I made a pretty big mistake here without noticing: it seems when
I moved the assignments of mst_state->pbn_div I completely missed the fact
that the reason for us calling drm_dp_mst_update_slots() earlier was to
account for the fact that we need to call this function using info from the
root MST connector, instead of just trying to do this from each MST
encoder's atomic check function. Otherwise, we end up filling out all of
DC's link information with zeroes.
So, let's restore that and hopefully fix this DSC regression.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Signed-off-by: Lyude Paul
Signed-off-by: Harry Wentland
Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic
state")
Cc: sta...@vger.kernel.org # 6.1
Acked-by: Harry Wentland
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 5
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 22aadbad58d3..4c5b8793b8af 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9643,6 +9643,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
struct drm_connector_state *old_con_state, *new_con_state;
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct drm_dp_mst_topology_mgr *mgr;
+ struct drm_dp_mst_topology_state *mst_state;
struct drm_plane *plane;
struct drm_plane_state *old_plane_state, *new_plane_state;
enum dc_status status;
@@ -9898,6 +9900,28 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
lock_and_validation_needed = true;
}
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ /* set the slot info for each mst_state based on the link encoding
format */
+ for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
+ struct amdgpu_dm_connector *aconnector;
+ struct drm_connector *connector;
+ struct drm_connector_list_iter iter;
+ u8 link_coding_cap;
+
+ drm_connector_list_iter_begin(dev, &iter);
+ drm_for_each_connector_iter(connector, &iter) {
+ if (connector->index == mst_state->mgr->conn_base_id) {
+ aconnector = to_amdgpu_dm_connector(connector);
+ link_coding_cap =
dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+ drm_dp_mst_update_slots(mst_state,
link_coding_cap);
+
+ break;
+ }
+ }
+ drm_connector_list_iter_end(&iter);
+ }
+#endif
+
/**
* Streams and planes are reset when there are changes that affect
* bandwidth. Anything that affects bandwidth needs to go through
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 5fa9bab95038..e8d14ab0953a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -927,11 +927,6 @@ static int compute_mst_dsc_configs_for_link(struct
drm_atomic_state *state,
if (IS_ERR(mst_state))
return PTR_ERR(mst_state);
- mst_state->pbn_div = dm_mst_get_pbn_divider(dc_link);
-#if defined(CONFIG_DRM_AMD_DC_DCN)
- drm_dp_mst_update_slots(mst_state,
dc_link_dp_mst_decide_link_encoding_format(dc_link));
-#endif
-
/* Set up params */
for (i = 0; i < dc_state->stream_count; i++) {
struct dc_dsc_policy dsc_policy = {0};
--
2.39.0
[PATCH 0/7] Fix MST on amdgpu
MST has been broken on amdgpu after a refactor in drm_dp_mst code that was aligning drm_dp_mst more closely with the atomic model. The gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 This series fixes it. It can be found at https://gitlab.freedesktop.org/hwentland/linux/-/tree/mst_regression A stable-6.1.y rebase can be found at https://gitlab.freedesktop.org/hwentland/linux/-/tree/mst_regression_6.1 Lyude Paul (1): drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignments Wayne Lin (6): drm/amdgpu/display/mst: limit payload to be updated one by one drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD drm/drm_print: correct format problem drm/display/dp_mst: Correct the kref of port. drm/amdgpu/display/mst: adjust the naming of mst_port and port of aconnector drm/amdgpu/display/mst: adjust the logic in 2nd phase of updating payload drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 4 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 48 +--- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 16 ++-- .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 76 +-- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 53 ++--- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 14 +++- drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +- include/drm/drm_print.h | 2 +- 10 files changed, 143 insertions(+), 80 deletions(-) -- 2.39.0
Re: [PATCH drm-next 13/14] drm/nouveau: implement new VM_BIND UAPI
On 1/19/23 22:47, Matthew Brost wrote:
On Thu, Jan 19, 2023 at 06:46:30PM +0100, Danilo Krummrich wrote:
On 1/19/23 17:38, Matthew Brost wrote:
On Thu, Jan 19, 2023 at 04:36:43PM +0100, Danilo Krummrich wrote:
On 1/19/23 05:58, Matthew Brost wrote:
On Thu, Jan 19, 2023 at 04:44:23AM +0100, Danilo Krummrich wrote:
On 1/18/23 21:37, Thomas Hellström (Intel) wrote:
On 1/18/23 07:12, Danilo Krummrich wrote:
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA
space managed by the kernel and userspace, respectively.
2) Allocate and free a VA space region as well as bind and unbind memory
to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl.
UMDs can request the named operations to be processed either
synchronously or asynchronously. It supports DRM syncobjs
(incl. timelines) as synchronization mechanism. The management of the
GPU VA mappings is implemented with the DRM GPU VA manager.
3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. The
execution happens asynchronously. It supports DRM syncobj (incl.
timelines) as synchronization mechanism. DRM GEM object locking is
handled with drm_exec.
Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, use the DRM
GPU scheduler for the asynchronous paths.
Signed-off-by: Danilo Krummrich
---
Documentation/gpu/driver-uapi.rst | 3 +
drivers/gpu/drm/nouveau/Kbuild | 2 +
drivers/gpu/drm/nouveau/Kconfig | 2 +
drivers/gpu/drm/nouveau/nouveau_abi16.c | 16 +
drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 23 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 9 +-
drivers/gpu/drm/nouveau/nouveau_exec.c | 310 ++
drivers/gpu/drm/nouveau/nouveau_exec.h | 55 ++
drivers/gpu/drm/nouveau/nouveau_sched.c | 780
drivers/gpu/drm/nouveau/nouveau_sched.h | 98 +++
11 files changed, 1295 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.h
create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.h
...
+static struct dma_fence *
+nouveau_bind_job_run(struct nouveau_job *job)
+{
+ struct nouveau_bind_job *bind_job = to_nouveau_bind_job(job);
+ struct nouveau_uvmm *uvmm = nouveau_cli_uvmm(job->cli);
+ struct bind_job_op *op;
+ int ret = 0;
+
I was looking at how nouveau does the async binding compared to how xe
does it.
It looks to me that this function being a scheduler run_job callback is
the main part of the VM_BIND dma-fence signalling critical section for
the job's done_fence and if so, needs to be annotated as such?
Yes, that's the case.
For example nouveau_uvma_region_new allocates memory, which is not
allowed if in a dma_fence signalling critical section and the locking
also looks suspicious?
Thanks for pointing this out, I missed that somehow.
I will change it to pre-allocate new regions, mappings and page tables
within the job's submit() function.
Yea that what we basically do in Xe, in the IOCTL step allocate all the
backing store for new page tables, populate new page tables (these are
not yet visible in the page table structure), and in last step which is
executed after all the dependencies are satified program all the leaf
entires making the new binding visible.
We screwed have this up by defering most of the IOCTL to a worker but
will fix this fix this one way or another soon - get rid of worker or
introduce a type of sync that is signaled after the worker + publish the
dma-fence in the worker. I'd like to close on this one soon.
For the ops structures the drm_gpuva_manager allocates for reporting the
split/merge steps back to the driver I have ideas to entirely avoid
allocations, which also is a good thing in respect of Christians feedback
regarding the huge amount of mapping requests some applications seem to
generate.
It should be fine to have allocations to report the split/merge step as
this step should be before a dma-fence is published, but yea if possible
to avoid extra allocs as that is always better.
I think we can't really ask for the split/merge steps before actually
running the job, since it requires the particular VA space not to change
while performing those operations.
E.g. if we'd run the split/merge steps at job submit() time the underlying
VA space could be changed by other bind jobs executing before this one,
which would make the calculated split/merge steps obsolete and wrong.
Hmm, maybe I'm not understanding this implementation, admittedly I
haven't studied the gpuva manager
[PATCH] drm/exynos: Drop unbalanced obj unref
From: Rob Clark
In the error path, exynos_drm_gem_mmap() was dropping an obj reference
that it doesn't own.
Fixes: 832316c704fe ("drm/exynos: use drm generic mmap interface")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 3e493f48e0d4..65bca61e63a3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -363,7 +363,6 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
static int exynos_drm_gem_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
{
struct exynos_drm_gem *exynos_gem = to_exynos_gem(obj);
- int ret;
if (obj->import_attach)
return dma_buf_mmap(obj->dma_buf, vma, 0);
@@ -383,16 +382,7 @@ static int exynos_drm_gem_mmap(struct drm_gem_object *obj,
struct vm_area_struct
vma->vm_page_prot =
pgprot_noncached(vm_get_page_prot(vma->vm_flags));
- ret = exynos_drm_gem_mmap_buffer(exynos_gem, vma);
- if (ret)
- goto err_close_vm;
-
- return ret;
-
-err_close_vm:
- drm_gem_vm_close(vma);
-
- return ret;
+ return exynos_drm_gem_mmap_buffer(exynos_gem, vma);
}
/* low-level interface prime helpers */
--
2.38.1
[PATCH] drm/rockchip: Drop unbalanced obj unref
From: Rob Clark
In the error path, rockchip_drm_gem_object_mmap() is dropping an obj
reference that it doesn't own.
Fixes: 41315b793e13 ("drm/rockchip: use drm_gem_mmap helpers")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 6edb7c52cb3d..19b46c00dcbf 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -262,9 +262,6 @@ static int rockchip_drm_gem_object_mmap(struct
drm_gem_object *obj,
else
ret = rockchip_drm_gem_object_mmap_dma(obj, vma);
- if (ret)
- drm_gem_vm_close(vma);
-
return ret;
}
--
2.38.1
[PATCH] drm/mediatek: Drop unbalanced obj unref
From: Rob Clark
In the error path, mtk_drm_gem_object_mmap() is dropping an obj
reference that it doesn't own.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index 9b3d15d3a983..f961c7c7456b 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -169,8 +169,6 @@ static int mtk_drm_gem_object_mmap(struct drm_gem_object
*obj,
ret = dma_mmap_attrs(priv->dma_dev, vma, mtk_gem->cookie,
mtk_gem->dma_addr, obj->size, mtk_gem->dma_attrs);
- if (ret)
- drm_gem_vm_close(vma);
return ret;
}
--
2.38.1
[PATCH 2/2] drm/panel: st7703: Add support for Anbernic RG353V-V2 panel
From: Chris Morgan
The Anbernic RG353V-V2 is a 5 inch panel used in a new revision of the
Anbernic RG353V handheld gaming device. Add support for it.
Unfortunately it appears this controller is not able to support 120hz
or 100hz mode like the first revision panel.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 102 +-
1 file changed, 99 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index 86a472b01360..2ed0cdfa86de 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -28,6 +28,7 @@
/* Manufacturer specific Commands send via DSI */
#define ST7703_CMD_ALL_PIXEL_OFF 0x22
#define ST7703_CMD_ALL_PIXEL_ON 0x23
+#define ST7703_CMD_SETAPID 0xB1
#define ST7703_CMD_SETDISP 0xB2
#define ST7703_CMD_SETRGBIF 0xB3
#define ST7703_CMD_SETCYC 0xB4
@@ -41,12 +42,15 @@
#define ST7703_CMD_UNKNOWN_BF 0xBF
#define ST7703_CMD_SETSCR 0xC0
#define ST7703_CMD_SETPOWER 0xC1
+#define ST7703_CMD_SETECO 0xC6
+#define ST7703_CMD_SETIO0xC7
+#define ST7703_CMD_SETCABC 0xC8
#define ST7703_CMD_SETPANEL 0xCC
-#define ST7703_CMD_UNKNOWN_C6 0xC6
#define ST7703_CMD_SETGAMMA 0xE0
#define ST7703_CMD_SETEQ0xE3
#define ST7703_CMD_SETGIP1 0xE9
#define ST7703_CMD_SETGIP2 0xEA
+#define ST7703_CMD_UNKNOWN_EF 0xEF
struct st7703 {
struct device *dev;
@@ -266,8 +270,7 @@ static int xbd599_init_sequence(struct st7703 *ctx)
* ESD_DET_TIME_SEL = 0 frames
*/);
- /* Undocumented command. */
- dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_C6, 0x01, 0x00, 0xFF, 0xFF,
0x00);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETECO, 0x01, 0x00, 0xFF, 0xFF, 0x00);
dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER,
0x74, /* VBTHS, VBTLS: VGH = 17V, VBL = -11V */
@@ -355,6 +358,98 @@ static const struct st7703_panel_desc xbd599_desc = {
.init_sequence = xbd599_init_sequence,
};
+static int rg353v2_init_sequence(struct st7703 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC, 0xf1, 0x12, 0x83);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETAPID, 0x00, 0x00, 0x00,
+ 0xda, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETDISP, 0x00, 0x13, 0x70);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF, 0x10, 0x10, 0x28,
+ 0x28, 0x03, 0xff, 0x00, 0x00, 0x00, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETCYC, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, 0x0a, 0x0a);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x92, 0x92);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT, 0x25, 0x22,
+ 0xf0, 0x63);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI, 0x33, 0x81, 0x05,
+ 0xf9, 0x0e, 0x0e, 0x20, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x44, 0x25, 0x00, 0x90, 0x0a,
+ 0x00, 0x00, 0x01, 0x4f, 0x01, 0x00, 0x00, 0x37);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVDC, 0x47);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR, 0x73, 0x73, 0x50, 0x50,
+ 0x00, 0x00, 0x12, 0x50, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER, 0x53, 0xc0, 0x32,
+ 0x32, 0x77, 0xe1, 0xdd, 0xdd, 0x77, 0x77, 0x33,
+ 0x33);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETECO, 0x82, 0x00, 0xbf, 0xff,
+ 0x00, 0xff);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETIO, 0xb8, 0x00, 0x0a, 0x00,
+ 0x00, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETCABC, 0x10, 0x40, 0x1e,
+ 0x02);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0b);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA, 0x00, 0x07, 0x0d,
+ 0x37, 0x35, 0x3f, 0x41, 0x44, 0x06, 0x0c, 0x0d,
+ 0x0f, 0x11, 0x10, 0x12, 0x14, 0x1a, 0x00, 0x07,
+ 0x0d, 0x37, 0x35, 0x3f, 0x41, 0x44, 0x06, 0x0c,
+ 0x0d, 0x0f, 0x11, 0x10, 0x12, 0x14, 0x1a);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETEQ, 0x07, 0x07, 0x0b, 0x0b,
+ 0x0b, 0x0b, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00,
+ 0xc0, 0x10);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1, 0xc8, 0x10, 0x02, 0x00,
+
[PATCH 1/2] dt-bindings: panel: Add compatible for Anbernic RG353V-V2 panel
From: Chris Morgan The Anbernic RG353V-V2 panel is a 5 inch 640x480 MIPI-DSI LCD panel. It's based on the ST7703 LCD controller just like rocktech,jh057n00900. It's used in a 2nd revision of the Anbernic RG353V handheld gaming device. Like the first revision of the RG353V the control chip is known but the panel itself is unknown, so name it for the device. Signed-off-by: Chris Morgan --- .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml index 09b5eb7542f8..150e81090af2 100644 --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml @@ -20,6 +20,8 @@ allOf: properties: compatible: enum: + # Anberic RG353V-V2 5.0" 640x480 TFT LCD panel + - anbernic,rg353v-panel-v2 # Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel - rocktech,jh057n00900 # Xingbangda XBD599 5.99" 720x1440 TFT LCD panel -- 2.34.1
[PATCH 0/2] drm/panel: Add Anbernic RG353V-V2 Panel
From: Chris Morgan Add the NewVision NV3051D panel as found on the second revision of the RG353V. The underlying LCD panel itself is unknown (ST7703 is the controller IC). Chris Morgan (2): dt-bindings: panel: Add compatible for Anbernic RG353V-V2 panel drm/panel: st7703: Add support for Anbernic RG353V-V2 panel .../display/panel/rocktech,jh057n00900.yaml | 2 + drivers/gpu/drm/panel/panel-sitronix-st7703.c | 102 +- 2 files changed, 101 insertions(+), 3 deletions(-) -- 2.34.1
Re: [Intel-gfx] [PATCH v5 2/6] drm/i915/pxp: add device link between i915 and mei_pxp
Thanks for reviewing the patch. I will fix the code according to your recommendation. I assume we could probably go with -ENOLINK as the error (instead of -ENOMEM). However, i'll wait for Alexander to respond on whether he needs drm_WARN_ON and your question on RPM. ...alan On Thu, 2023-01-19 at 14:25 -0500, Vivi, Rodrigo wrote: > On Thu, Jan 12, 2023 at 05:18:46PM -0800, Alan Previn wrote: > > From: Alexander Usyskin > > > > Add device link with i915 as consumer and mei_pxp as supplier > > to ensure proper ordering of power flows. > > > > V2: condition on absence of heci_pxp to filter out DG > > > > Signed-off-by: Alexander Usyskin > > Signed-off-by: Alan Previn > > --- > > drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7 +++ > > 1 file changed, 7 insertions(+) Alan: [snip]
Re: [PATCH v2 1/3] drm/msm/mdss: convert UBWC setup to use match data
On 1/17/2023 5:04 PM, Dmitry Baryshkov wrote:
To simplify adding new platforms and to make settings more obvious,
rewrite the UBWC setup to use the data structure to pass platform config
rather than just calling the functions direcly.
Signed-off-by: Dmitry Baryshkov
I was reviewing this series and
https://patchwork.freedesktop.org/series/111732/ together.
More I think about it, it seems like we are duplicating the same values
here and in the catalog.
Yes, these two are different drivers.
But now that you are adding the UBWC entries here using the compatible
string so you are creating something like a "catalog" here.
In that case, why dont we remove the entries from dpu catalog and in the
DPU driver get the parent's match data as we know that the msm_mdss is
the parent of DPU driver
Let me know your thoughts.
---
drivers/gpu/drm/msm/msm_mdss.c | 181 +++--
1 file changed, 105 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 02646e4bb4cd..799672b88716 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -16,9 +16,6 @@
#include "msm_drv.h"
#include "msm_kms.h"
-/* for DPU_HW_* defines */
-#include "disp/dpu1/dpu_hw_catalog.h"
-
#define HW_REV0x0
#define HW_INTR_STATUS0x0010
@@ -29,6 +26,16 @@
#define MIN_IB_BW 4UL /* Min ib vote 400MB */
+struct msm_mdss_data {
+ u32 ubwc_version;
+ /* can be read from register 0x58 */
+ u32 ubwc_dec_version;
+ u32 ubwc_swizzle;
+ u32 ubwc_static;
+ u32 highest_bank_bit;
+ u32 macrotile_mode;
+};
+
struct msm_mdss {
struct device *dev;
@@ -40,6 +47,7 @@ struct msm_mdss {
unsigned long enabled_mask;
struct irq_domain *domain;
} irq_controller;
+ const struct msm_mdss_data *mdss_data;
struct icc_path *path[2];
u32 num_paths;
};
@@ -182,46 +190,40 @@ static int _msm_mdss_irq_domain_add(struct msm_mdss
*msm_mdss)
#define UBWC_3_0 0x3000
#define UBWC_4_0 0x4000
-static void msm_mdss_setup_ubwc_dec_20(struct msm_mdss *msm_mdss,
- u32 ubwc_static)
+static void msm_mdss_setup_ubwc_dec_20(struct msm_mdss *msm_mdss)
{
- writel_relaxed(ubwc_static, msm_mdss->mmio + UBWC_STATIC);
+ const struct msm_mdss_data *data = msm_mdss->mdss_data;
+
+ writel_relaxed(data->ubwc_static, msm_mdss->mmio + UBWC_STATIC);
}
-static void msm_mdss_setup_ubwc_dec_30(struct msm_mdss *msm_mdss,
- unsigned int ubwc_version,
- u32 ubwc_swizzle,
- u32 highest_bank_bit,
- u32 macrotile_mode)
+static void msm_mdss_setup_ubwc_dec_30(struct msm_mdss *msm_mdss)
{
- u32 value = (ubwc_swizzle & 0x1) |
- (highest_bank_bit & 0x3) << 4 |
- (macrotile_mode & 0x1) << 12;
+ const struct msm_mdss_data *data = msm_mdss->mdss_data;
+ u32 value = (data->ubwc_swizzle & 0x1) |
+ (data->highest_bank_bit & 0x3) << 4 |
+ (data->macrotile_mode & 0x1) << 12;
- if (ubwc_version == UBWC_3_0)
+ if (data->ubwc_version == UBWC_3_0)
value |= BIT(10);
- if (ubwc_version == UBWC_1_0)
+ if (data->ubwc_version == UBWC_1_0)
value |= BIT(8);
writel_relaxed(value, msm_mdss->mmio + UBWC_STATIC);
}
-static void msm_mdss_setup_ubwc_dec_40(struct msm_mdss *msm_mdss,
- unsigned int ubwc_version,
- u32 ubwc_swizzle,
- u32 ubwc_static,
- u32 highest_bank_bit,
- u32 macrotile_mode)
+static void msm_mdss_setup_ubwc_dec_40(struct msm_mdss *msm_mdss)
{
- u32 value = (ubwc_swizzle & 0x7) |
- (ubwc_static & 0x1) << 3 |
- (highest_bank_bit & 0x7) << 4 |
- (macrotile_mode & 0x1) << 12;
+ const struct msm_mdss_data *data = msm_mdss->mdss_data;
+ u32 value = (data->ubwc_swizzle & 0x7) |
+ (data->ubwc_static & 0x1) << 3 |
+ (data->highest_bank_bit & 0x7) << 4 |
+ (data->macrotile_mode & 0x1) << 12;
writel_relaxed(value, msm_mdss->mmio + UBWC_STATIC);
- if (ubwc_version == UBWC_3_0) {
+ if (data->ubwc_version == UBWC_3_0) {
writel_relaxed(1, msm_mdss->mmio + UBWC_CTRL_2);
writel_relaxed(0, msm_mdss->mmio + UBWC_PREDICTION_MODE);
} else {
@@ -233,7 +235,6 @@ static void msm_mdss_setup_ubwc_dec_40(struct msm_mdss
*msm_mdss,
static int msm_mdss_enable(struct msm_mdss *msm_md
[PATCH 2/2] drm/msm/dp: Return IRQ_NONE for unhandled interrupts
If our interrupt handler gets called and we don't really handle the
interrupt then we should return IRQ_NONE. The current interrupt
handler didn't do this, so let's fix it.
NOTE: for some of the cases it's clear that we should return IRQ_NONE
and some cases it's clear that we should return IRQ_HANDLED. However,
there are a few that fall somewhere in between. Specifically, the
documentation for when to return IRQ_NONE vs. IRQ_HANDLED is probably
best spelled out in the commit message of commit d9e4ad5badf4
("Document that IRQ_NONE should be returned when IRQ not actually
handled"). That commit makes it clear that we should return
IRQ_HANDLED if we've done something to make the interrupt stop
happening.
The case where it's unclear is, for instance, in dp_aux_isr() after
we've read the interrupt using dp_catalog_aux_get_irq() and confirmed
that "isr" is non-zero. The function dp_catalog_aux_get_irq() not only
reads the interrupts but it also "ack"s all the interrupts that are
returned. For an "unknown" interrupt this has a very good chance of
actually stopping the interrupt from happening. That would mean we've
identified that it's our device and done something to stop them from
happening and should return IRQ_HANDLED. Specifically, it should be
noted that most interrupts that need "ack"ing are ones that are
one-time events and doing an "ack" is enough to clear them. However,
since these interrupts are unknown then, by definition, it's unknown
if "ack"ing them is truly enough to clear them. It's possible that we
also need to remove the original source of the interrupt. In this
case, IRQ_NONE would be a better choice.
Given that returning an occasional IRQ_NONE isn't the absolute end of
the world, however, let's choose that course of action. The IRQ
framework will forgive a few IRQ_NONE returns now and again (and it
won't even log them, which is why we have to log them ourselves). This
means that if we _do_ end hitting an interrupt where "ack"ing isn't
enough the kernel will eventually detect the problem and shut our
device down.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/msm/dp/dp_aux.c | 12 +++-
drivers/gpu/drm/msm/dp/dp_aux.h | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 10 --
drivers/gpu/drm/msm/dp/dp_ctrl.h| 2 +-
drivers/gpu/drm/msm/dp/dp_display.c | 8 +---
5 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 34ad08ae6eb9..59e323b7499d 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -368,14 +368,14 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
return ret;
}
-void dp_aux_isr(struct drm_dp_aux *dp_aux)
+irqreturn_t dp_aux_isr(struct drm_dp_aux *dp_aux)
{
u32 isr;
struct dp_aux_private *aux;
if (!dp_aux) {
DRM_ERROR("invalid input\n");
- return;
+ return IRQ_NONE;
}
aux = container_of(dp_aux, struct dp_aux_private, dp_aux);
@@ -384,11 +384,11 @@ void dp_aux_isr(struct drm_dp_aux *dp_aux)
/* no interrupts pending, return immediately */
if (!isr)
- return;
+ return IRQ_NONE;
if (!aux->cmd_busy) {
DRM_ERROR("Unexpected DP AUX IRQ %#010x when not busy\n", isr);
- return;
+ return IRQ_NONE;
}
/*
@@ -420,10 +420,12 @@ void dp_aux_isr(struct drm_dp_aux *dp_aux)
aux->aux_error_num = DP_AUX_ERR_DEFER;
} else {
DRM_WARN("Unexpected interrupt: %#010x\n", isr);
- return;
+ return IRQ_NONE;
}
complete(&aux->comp);
+
+ return IRQ_HANDLED;
}
void dp_aux_reconfig(struct drm_dp_aux *dp_aux)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.h b/drivers/gpu/drm/msm/dp/dp_aux.h
index e930974bcb5b..511305da4f66 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.h
+++ b/drivers/gpu/drm/msm/dp/dp_aux.h
@@ -11,7 +11,7 @@
int dp_aux_register(struct drm_dp_aux *dp_aux);
void dp_aux_unregister(struct drm_dp_aux *dp_aux);
-void dp_aux_isr(struct drm_dp_aux *dp_aux);
+irqreturn_t dp_aux_isr(struct drm_dp_aux *dp_aux);
void dp_aux_init(struct drm_dp_aux *dp_aux);
void dp_aux_deinit(struct drm_dp_aux *dp_aux);
void dp_aux_reconfig(struct drm_dp_aux *dp_aux);
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index dd26ca651a05..1a5377ef1967 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1979,27 +1979,33 @@ int dp_ctrl_off(struct dp_ctrl *dp_ctrl)
return ret;
}
-void dp_ctrl_isr(struct dp_ctrl *dp_ctrl)
+irqreturn_t dp_ctrl_isr(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
u32 isr;
+ irqreturn_t ret = IRQ_NONE;
if (!dp_ctrl)
- return;
+ return IRQ_NONE;
ctrl = container_of(dp_ctrl,
[PATCH 1/2] drm/msm/dp: Clean up handling of DP AUX interrupts
The DP AUX interrupt handling was a bit of a mess.
* There were two functions (one for "native" transfers and one for
"i2c" transfers) that were quite similar. It was hard to say how
many of the differences between the two functions were on purpose
and how many of them were just an accident of how they were coded.
* Each function sometimes used "else if" to test for error bits and
sometimes didn't and again it was hard to say if this was on purpose
or just an accident.
* The two functions wouldn't notice whether "unknown" bits were
set. For instance, there seems to be a bit "DP_INTR_PLL_UNLOCKED"
and if it was set there would be no indication.
* The two functions wouldn't notice if more than one error was set.
Let's fix this by being more consistent / explicit about what we're
doing.
By design this could cause different handling for AUX transfers,
though I'm not actually aware of any bug fixed as a result of
this patch (this patch was created because we simply noticed how odd
the old code was by code inspection). Specific notes here:
1. In the old native transfer case if we got "done + wrong address"
we'd ignore the "wrong address" (because of the "else if"). Now we
won't.
2. In the old native transfer case if we got "done + timeout" we'd
ignore the "timeout" (because of the "else if"). Now we won't.
3. In the old native transfer case we'd see "nack_defer" and translate
it to the error number for "nack". This differed from the i2c
transfer case where "nack_defer" was given the error number for
"nack_defer". This 100% can't matter because the only user of this
error number treats "nack defer" the same as "nack", so it's clear
that the difference between the "native" and "i2c" was pointless
here.
4. In the old i2c transfer case if we got "done" plus any error
besides "nack" or "defer" then we'd ignore the error. Now we don't.
5. If there is more than one error signaled by the hardware it's
possible that we'll report a different one than we used to. I don't
know if this matters. If someone is aware of a case this matters we
should document it and change the code to make it explicit.
6. One quirk we keep (I don't know if this is important) is that in
the i2c transfer case if we see "done + defer" we report that as a
"nack". That seemed too intentional in the old code to just drop.
After this change we will add extra logging, including:
* A warning if we see more than one error bit set.
* A warning if we see an unexpected interrupt.
* A warning if we get an AUX transfer interrupt when shouldn't.
It actually turns out that as a result of this change then at boot we
sometimes see an error:
[drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x0100 when not busy
That means that, during init, we are seeing DP_INTR_PLL_UNLOCKED. For
now I'm going to say that leaving this error reported in the logs is
OK-ish and hopefully it will encourage someone to track down what's
going on at init time.
One last note here is that this change renames one of the interrupt
bits. The bit named "i2c done" clearly was used for native transfers
being done too, so I renamed it to indicate this.
Signed-off-by: Douglas Anderson
---
I don't have good test coverage for this change and it does have the
potential to change behavior. I confirmed that eDP and DP still
continue to work OK on one machine. Hopefully folks can test it more.
drivers/gpu/drm/msm/dp/dp_aux.c | 80 -
drivers/gpu/drm/msm/dp/dp_catalog.c | 2 +-
drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
3 files changed, 36 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index cc3efed593aa..34ad08ae6eb9 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -162,47 +162,6 @@ static ssize_t dp_aux_cmd_fifo_rx(struct dp_aux_private
*aux,
return i;
}
-static void dp_aux_native_handler(struct dp_aux_private *aux, u32 isr)
-{
- if (isr & DP_INTR_AUX_I2C_DONE)
- aux->aux_error_num = DP_AUX_ERR_NONE;
- else if (isr & DP_INTR_WRONG_ADDR)
- aux->aux_error_num = DP_AUX_ERR_ADDR;
- else if (isr & DP_INTR_TIMEOUT)
- aux->aux_error_num = DP_AUX_ERR_TOUT;
- if (isr & DP_INTR_NACK_DEFER)
- aux->aux_error_num = DP_AUX_ERR_NACK;
- if (isr & DP_INTR_AUX_ERROR) {
- aux->aux_error_num = DP_AUX_ERR_PHY;
- dp_catalog_aux_clear_hw_interrupts(aux->catalog);
- }
-}
-
-static void dp_aux_i2c_handler(struct dp_aux_private *aux, u32 isr)
-{
- if (isr & DP_INTR_AUX_I2C_DONE) {
- if (isr & (DP_INTR_I2C_NACK | DP_INTR_I2C_DEFER))
- aux->aux_error_num = DP_AUX_ERR_NACK;
- else
- aux->aux_error_num = DP_AUX_ERR_NONE;
- } else {
- if (isr & DP_INTR_WRONG_ADDR)
- aux->aux_error_num
[PATCH v2] drm/shmem: Cleanup drm_gem_shmem_create_with_handle()
From: Rob Clark Once we create the handle, the handle owns the reference. Currently nothing was doing anything with the shmem ptr after the handle was created, but let's change drm_gem_shmem_create_with_handle() to not return the pointer, so-as to not encourage problematic use of this function in the future. As a bonus, it makes the code a bit cleaner. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_gem_shmem_helper.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index f21f47737817..fa6281e43954 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -415,7 +415,7 @@ void drm_gem_shmem_vunmap(struct drm_gem_shmem_object *shmem, } EXPORT_SYMBOL(drm_gem_shmem_vunmap); -static struct drm_gem_shmem_object * +static int drm_gem_shmem_create_with_handle(struct drm_file *file_priv, struct drm_device *dev, size_t size, uint32_t *handle) @@ -425,7 +425,7 @@ drm_gem_shmem_create_with_handle(struct drm_file *file_priv, shmem = drm_gem_shmem_create(dev, size); if (IS_ERR(shmem)) - return shmem; + return PTR_ERR(shmem); /* * Allocate an id of idr table where the obj is registered @@ -434,10 +434,8 @@ drm_gem_shmem_create_with_handle(struct drm_file *file_priv, ret = drm_gem_handle_create(file_priv, &shmem->base, handle); /* drop reference from allocate - handle holds it now. */ drm_gem_object_put(&shmem->base); - if (ret) - return ERR_PTR(ret); - return shmem; + return ret; } /* Update madvise status, returns true if not purged, else @@ -533,9 +531,7 @@ int drm_gem_shmem_dumb_create(struct drm_file *file, struct drm_device *dev, args->size = PAGE_ALIGN(args->pitch * args->height); } - shmem = drm_gem_shmem_create_with_handle(file, dev, args->size, &args->handle); - - return PTR_ERR_OR_ZERO(shmem); + return drm_gem_shmem_create_with_handle(file, dev, args->size, &args->handle); } EXPORT_SYMBOL_GPL(drm_gem_shmem_dumb_create); -- 2.38.1
[PATCH] drm/mediatek: Remove dependency on GEM DMA helper
From: Rob Clark
It appears that the dependency on the DMA helpers was only for
drm_gem_dma_vm_ops.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/mediatek/Kconfig | 1 -
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 7 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index 369e495d0c3e..b451dee64d34 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -7,7 +7,6 @@ config DRM_MEDIATEK
depends on HAVE_ARM_SMCCC
depends on OF
depends on MTK_MMSYS
- select DRM_GEM_DMA_HELPER
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index 47e96b0289f9..9b3d15d3a983 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -16,13 +16,18 @@
static int mtk_drm_gem_object_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma);
+static const struct vm_operations_struct vm_ops = {
+ .open = drm_gem_vm_open,
+ .close = drm_gem_vm_close,
+};
+
static const struct drm_gem_object_funcs mtk_drm_gem_object_funcs = {
.free = mtk_drm_gem_free_object,
.get_sg_table = mtk_gem_prime_get_sg_table,
.vmap = mtk_drm_gem_prime_vmap,
.vunmap = mtk_drm_gem_prime_vunmap,
.mmap = mtk_drm_gem_object_mmap,
- .vm_ops = &drm_gem_dma_vm_ops,
+ .vm_ops = &vm_ops,
};
static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev,
--
2.38.1
Re: [PATCH v5 5/6] drm/i915/pxp: Trigger the global teardown for before suspending
Thanks for reviewing - responses below.
On Thu, 2023-01-19 at 14:35 -0500, Vivi, Rodrigo wrote:
> On Thu, Jan 12, 2023 at 05:18:49PM -0800, Alan Previn wrote:
> > A driver bug was recently discovered where the security firmware was
> > receiving internal HW signals indicating that session key expirations
> > had occurred. Architecturally, the firmware was expecting a response
> > from the GuC to acknowledge the event with the firmware side.
> > However the OS was in a suspended state and GuC had been reset.
> >
> > Internal specifications actually required the driver to ensure
> > that all active sessions be properly cleaned up in such cases where
> > the system is suspended and the GuC potentially unable to respond.
> >
> > This patch adds the global teardown code in i915's suspend_prepare
> > code path.
> >
> > Signed-off-by: Alan Previn
> > Reviewed-by: Juston Li
> >
Alan: [snip]
> >
> > +static int __pxp_global_teardown_locked(struct intel_pxp *pxp, bool
> > terminate_for_cleanup)
> > +{
> > + if (terminate_for_cleanup) {
> > + if (!pxp->arb_is_valid)
> > + return 0;
> > + /*
> > + * To ensure synchronous and coherent session teardown
> > completion
> > + * in response to suspend or shutdown triggers, don't use a
> > worker.
> > + */
> > + intel_pxp_mark_termination_in_progress(pxp);
> > + intel_pxp_terminate(pxp, false);
> > + } else {
> > + if (pxp->arb_is_valid)
> > + return 0;
> > + /*
> > + * If we are not in final termination, and the arb-session
> > is currently
> > + * inactive, we are doing a reset and restart due to some
> > runtime event.
> > + * Use the worker that was designed for this.
> > + */
> > + pxp_queue_termination(pxp);
> > + }
>
> I really don't see why you need 1 function for totally 2 different cases.
> Why not 2 functions then?
>
Alan: I don't see why not ;) My goal with above method was was to concentrate
the teardown steps in a single function so if future changes are required, we
can keep it in this single function entry point. For now i will assume that was
a nack so i shall split it on next rev.
> > +
> > + if (!wait_for_completion_timeout(&pxp->termination,
> > msecs_to_jiffies(250)))
> > + return -ETIMEDOUT;
> > +
> > + return 0;
> > +}
> > +
> >
Alan: [snip]
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > index 9658d3005222..3ded0890cd27 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > @@ -27,6 +27,7 @@ void intel_pxp_mark_termination_in_progress(struct
> > intel_pxp *pxp);
> > void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
> > arb_session_id);
> >
> > int intel_pxp_start(struct intel_pxp *pxp);
> > +void intel_pxp_end(struct intel_pxp *pxp);
> >
> > int intel_pxp_key_check(struct intel_pxp *pxp,
> > struct drm_i915_gem_object *obj,
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > index 892d39cc61c1..e427464aa131 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > @@ -16,7 +16,7 @@ void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
> > if (!intel_pxp_is_enabled(pxp))
> > return;
> >
> > - pxp->arb_is_valid = false;
> > + intel_pxp_end(pxp);
> >
> > intel_pxp_invalidate(pxp);
> > }
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> > index 74ed7e16e481..d8278c4002e3 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> > @@ -115,11 +115,14 @@ static int
> > pxp_terminate_arb_session_and_global(struct intel_pxp *pxp)
> > return ret;
> > }
> >
> > -static void pxp_terminate(struct intel_pxp *pxp)
> > +void intel_pxp_terminate(struct intel_pxp *pxp, bool restart_arb)
> > {
> > int ret;
> >
> > - pxp->hw_state_invalidated = true;
> > + if (restart_arb)
> > + pxp->hw_state_invalidated = true;
> > + else
> > + pxp->hw_state_invalidated = false;
>
> o.O
>
> pxp->hw_state_invalidate = restart_arb;
Alan: du... (my bad)
>
> ?
>
> or even a better name for the restart_arb to already indicate that is
> the hw_state_invalidate ?
>
Alan: hmmm... you something mean like:
hw_state_invalidated = post_invalidation_needs_restart;
Alan: actually i wish we couold redo "hw_state_invalidate" which is currently
defined
as a boolean that only means one thing -> teardown and restart. It would be
more scalable
if we can replace it with a bitmask of "
Re: [Intel-gfx] linux-next: build failure after merge of the drm tree
On Thu, Jan 19, 2023 at 01:12:22PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/gpu/drm/drm_fb_helper.c:33:
> drivers/gpu/drm/drm_fb_helper.c: In function 'drm_fb_helper_single_fb_probe':
> drivers/gpu/drm/drm_fb_helper.c:1968:24: error: 'dev' undeclared (first use
> in this function); did you mean 'cdev'?
It's a silent conflict of
cff84bac9922 ("drm/fh-helper: Split fbdev single-probe helper")
with
d1d5101452ab ("drm/fb-helper: Set framebuffer for vga-switcheroo clients")
The resolution is to reintroduce the dev declaration there in
drm_fb_helper_single_fb_probe()
+ struct drm_device *dev = fb_helper->dev;
I hope it helps.
Thanks,
Rodrigo.
> 1968 | if (dev_is_pci(dev->dev))
> |^~~
> include/linux/pci.h:1151:25: note: in definition of macro 'dev_is_pci'
> 1151 | #define dev_is_pci(d) ((d)->bus == &pci_bus_type)
> | ^
> drivers/gpu/drm/drm_fb_helper.c:1968:24: note: each undeclared identifier is
> reported only once for each function it appears in
> 1968 | if (dev_is_pci(dev->dev))
> |^~~
> include/linux/pci.h:1151:25: note: in definition of macro 'dev_is_pci'
> 1151 | #define dev_is_pci(d) ((d)->bus == &pci_bus_type)
> | ^
> In file included from include/linux/atomic/atomic-instrumented.h:20,
> from include/linux/atomic.h:82,
> from include/linux/console.h:17,
> from drivers/gpu/drm/drm_fb_helper.c:32:
> include/linux/compiler_types.h:299:27: error: expression in static assertion
> is not an integer
> 299 | #define __same_type(a, b) __builtin_types_compatible_p(typeof(a),
> typeof(b))
> | ^~~~
> include/linux/build_bug.h:78:56: note: in definition of macro
> '__static_assert'
>78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
> |^~~~
> include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
>20 | static_assert(__same_type(*(ptr), ((type *)0)->member) ||
> \
> | ^
> include/linux/container_of.h:20:23: note: in expansion of macro '__same_type'
>20 | static_assert(__same_type(*(ptr), ((type *)0)->member) ||
> \
> | ^~~
> include/linux/pci.h:541:23: note: in expansion of macro 'container_of'
> 541 | #define to_pci_dev(n) container_of(n, struct pci_dev, dev)
> | ^~~~
> drivers/gpu/drm/drm_fb_helper.c:1969:46: note: in expansion of macro
> 'to_pci_dev'
> 1969 | vga_switcheroo_client_fb_set(to_pci_dev(dev->dev),
> fb_helper->info);
> | ^~
>
> Caused by commit
>
> cff84bac9922 ("drm/fh-helper: Split fbdev single-probe helper")
>
> interacting with commit
>
> d1d5101452ab ("drm/fb-helper: Set framebuffer for vga-switcheroo clients")
>
> from the drm-misc-fixes tree.
>
> I have added the following merge fix patch.
>
> From: Stephen Rothwell
> Date: Thu, 19 Jan 2023 12:42:56 +1100
> Subject: [PATCH] fix up for "drm/fb-helper: Set framebuffer for
> vga-switcheroo clients"
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/drm_fb_helper.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 97049a26fca2..5e445c61252d 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1942,6 +1942,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
>int preferred_bpp)
> {
> struct drm_client_dev *client = &fb_helper->client;
> + struct drm_device *dev = fb_helper->dev;
> struct drm_fb_helper_surface_size sizes;
> int ret;
>
> --
> 2.35.1
>
> --
> Cheers,
> Stephen Rothwell
Re: [Intel-gfx] [PATCH v2 2/3] drm/fb-helper: Set framebuffer for vga-switcheroo clients
On Thu, Jan 19, 2023 at 09:06:54AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 18.01.23 um 20:21 schrieb Rodrigo Vivi:
> > On Thu, Jan 12, 2023 at 09:11:55PM +0100, Thomas Zimmermann wrote:
> > > Set the framebuffer info for drivers that support VGA switcheroo. Only
> > > affects the amdgpu and nouveau drivers, which use VGA switcheroo and
> > > generic fbdev emulation. For other drivers, this does nothing.
> > >
> > > This fixes a potential regression in the console code. Both, amdgpu and
> > > nouveau, invoked vga_switcheroo_client_fb_set() from their internal fbdev
> > > code. But the call got lost when the drivers switched to the generic
> > > emulation.
> > >
> > > Fixes: 087451f372bf ("drm/amdgpu: use generic fb helpers instead of
> > > setting up AMD own's.")
> > > Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> > > Signed-off-by: Thomas Zimmermann
> > > Reviewed-by: Daniel Vetter
> > > Reviewed-by: Alex Deucher
> > > Cc: Ben Skeggs
> > > Cc: Karol Herbst
> > > Cc: Lyude Paul
> > > Cc: Thomas Zimmermann
> > > Cc: Javier Martinez Canillas
> > > Cc: Laurent Pinchart
> > > Cc: Jani Nikula
> > > Cc: Dave Airlie
> > > Cc: Evan Quan
> > > Cc: Christian König
> > > Cc: Alex Deucher
> > > Cc: Hawking Zhang
> > > Cc: Likun Gao
> > > Cc: "Christian König"
> > > Cc: Stanley Yang
> > > Cc: "Tianci.Yin"
> > > Cc: Xiaojian Du
> > > Cc: Andrey Grodzovsky
> > > Cc: YiPeng Chai
> > > Cc: Somalapuram Amaranath
> > > Cc: Bokun Zhang
> > > Cc: Guchun Chen
> > > Cc: Hamza Mahfooz
> > > Cc: Aurabindo Pillai
> > > Cc: Mario Limonciello
> > > Cc: Solomon Chiu
> > > Cc: Kai-Heng Feng
> > > Cc: Felix Kuehling
> > > Cc: Daniel Vetter
> > > Cc: "Marek Olšák"
> > > Cc: Sam Ravnborg
> > > Cc: Hans de Goede
> > > Cc: "Ville Syrjälä"
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: nouv...@lists.freedesktop.org
> > > Cc: # v5.17+
> > > ---
> > > drivers/gpu/drm/drm_fb_helper.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 427631706128..5e445c61252d 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -30,7 +30,9 @@
> > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > #include
> > > +#include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > @@ -1940,6 +1942,7 @@ static int drm_fb_helper_single_fb_probe(struct
> > > drm_fb_helper *fb_helper,
> > >int preferred_bpp)
> > > {
> > > struct drm_client_dev *client = &fb_helper->client;
> > > + struct drm_device *dev = fb_helper->dev;
> >
> > On drm-tip, this commit has a silent conflict with
> > cff84bac9922 ("drm/fh-helper: Split fbdev single-probe helper")
> > that's already in drm-next.
> >
> > I had created a fix-up patch in drm-tip re-introducing this line.
>
> Thank you. Is it fixed for now?
Fixed in drm-tip, yes. But broke linux-next as well. This
resolution will need to go up with any merge...
>
> >
> > We probably need a backmerge from drm-next into drm-misc-fixes with
> > the resolution applied there. And probably propagated that resolution
> > later...
>
> Backmerging from -next into -fixes branches is a problem, as -fixes should
> be close to the latest release.
doh! Indeed I should've known this by heart... -ENOTEHOUGHCOFFEE
>
> Can we solve this by merging -fixes into upstream and backmerging this into
> our -next branches?
hmmm... probably better just wait and let folks know the resolution
when the patches are moving up...
>
> Best regards
> Thomas
>
> >
> > > struct drm_fb_helper_surface_size sizes;
> > > int ret;
> > > @@ -1961,6 +1964,11 @@ static int drm_fb_helper_single_fb_probe(struct
> > > drm_fb_helper *fb_helper,
> > > return ret;
> > > strcpy(fb_helper->fb->comm, "[fbcon]");
> > > +
> > > + /* Set the fb info for vgaswitcheroo clients. Does nothing otherwise. */
> > > + if (dev_is_pci(dev->dev))
> > > + vga_switcheroo_client_fb_set(to_pci_dev(dev->dev),
> > > fb_helper->info);
> > > +
> > > return 0;
> > > }
> > > --
> > > 2.39.0
> > >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes
On Thu, Jan 19, 2023 at 09:26:20AM +0800, Zhenyu Wang wrote:
> On 2023.01.18 11:44:55 -0500, Rodrigo Vivi wrote:
> > On Wed, Jan 18, 2023 at 10:18:11AM +0530, Deepak R Varma wrote:
> > > On Tue, Jan 17, 2023 at 02:29:37PM -0500, Rodrigo Vivi wrote:
> > > > On Mon, Jan 16, 2023 at 01:44:46PM +0800, Zhenyu Wang wrote:
> > > > > On 2023.01.10 13:49:57 -0500, Rodrigo Vivi wrote:
> > > > > > On Wed, Jan 11, 2023 at 12:00:12AM +0530, Deepak R Varma wrote:
> > > > > > > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > > > > > > function adds the overhead of introducing a proxy file operation
> > > > > > > functions to wrap the original read/write inside file removal
> > > > > > > protection
> > > > > > > functions. This adds significant overhead in terms of introducing
> > > > > > > and
> > > > > > > managing the proxy factory file operations structure and function
> > > > > > > wrapping at runtime.
> > > > > > > As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro
> > > > > > > paired
> > > > > > > with debugfs_create_file_unsafe() is suggested to be used
> > > > > > > instead. The
> > > > > > > DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> > > > > > > debugfs_file_put() wrappers to protect the original read and write
> > > > > > > function calls for the debug attributes. There is no need for any
> > > > > > > runtime proxy file operations to be managed by the debugfs core.
> > > > > > > Following coccicheck make command helped identify this change:
> > > > > > >
> > > > > > > make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
> > > > > > > COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> > > > > > >
> > > > > > > Signed-off-by: Deepak R Varma
> > > > > >
> > > > > > I believe these 2 gvt cases could be done in one patch.
> > > > > > But anyways,
> > > > > >
> > > > > > Reviewed-by: Rodrigo Vivi
> > > > > >
> > > > > > for both patches... and will leave these 2 patches for gvt folks
> > > > > > to apply. Unless they ack and I apply in the drm-intel along with
> > > > > > the other ones.
> > > > > >
> > > > >
> > > > > yeah, they're fine with me, feel free to apply them directly.
> > > > >
> > > > > Acked-by: Zhenyu Wang
> > > >
> > > > Unfortunately I got some conflicts when trying to apply on
> > > > drm-intel-next.
> > > >
> > > > We probably need a new version, and probably through gvt branches it
> > > > will be easier to handle conflicts if they appear.
> > >
> > > Hello Rodrigo,
> > > Sure. I will send in a new version. I am current using linux-next git
> > > repo as my
> > > remote origin [tag 20230113]. Are there any specific instruction/location
> > > from
> > > where I should access the gvt branch?
> >
> > https://github.com/intel/gvt-linux.git
> >
> > but with the linux-next your patch is probably right for them.
> >
>
> yeah, I think so as currently from last pull request I don't have
> other updates in gvt tree, maybe it's just d-i-n hasn't included
> recent gvt change.
>
> I saw Deepak sent a new one, feel free to apply. Let me know if
> there's still any issue.
It still doesn't apply in drm-intel-next.
Could you please take it through your branch?
>
> thanks!
>
> > > > >
> > > > > > > ---
> > > > > > > drivers/gpu/drm/i915/gvt/debugfs.c | 6 +++---
> > > > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c
> > > > > > > b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > > > > > index 03f081c3d9a4..baccbf1761b7 100644
> > > > > > > --- a/drivers/gpu/drm/i915/gvt/debugfs.c
> > > > > > > +++ b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > > > > > @@ -165,7 +165,7 @@ static int vgpu_status_get(void *data, u64
> > > > > > > *val)
> > > > > > > return 0;
> > > > > > > }
> > > > > > >
> > > > > > > -DEFINE_SIMPLE_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL,
> > > > > > > "0x%llx\n");
> > > > > > > +DEFINE_DEBUGFS_ATTRIBUTE(vgpu_status_fops, vgpu_status_get,
> > > > > > > NULL, "0x%llx\n");
> > > > > > >
> > > > > > > /**
> > > > > > > * intel_gvt_debugfs_add_vgpu - register debugfs entries for a
> > > > > > > vGPU
> > > > > > > @@ -182,8 +182,8 @@ void intel_gvt_debugfs_add_vgpu(struct
> > > > > > > intel_vgpu *vgpu)
> > > > > > > &vgpu_mmio_diff_fops);
> > > > > > > debugfs_create_file_unsafe("scan_nonprivbb", 0644,
> > > > > > > vgpu->debugfs, vgpu,
> > > > > > > &vgpu_scan_nonprivbb_fops);
> > > > > > > - debugfs_create_file("status", 0644, vgpu->debugfs, vgpu,
> > > > > > > - &vgpu_status_fops);
> > > > > > > + debugfs_create_file_unsafe("status", 0644, vgpu->debugfs, vgpu,
> > > > > > > +&vgpu_status_fops);
> > > > > > > }
> > > > > > >
> > > > > > > /**
> > > > > > > --
> > > > > > > 2.34.1
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> > > >
> > >
> > >
Re: [Intel-gfx] [PATCH v5 4/6] drm/i915/pxp: Invalidate all PXP fw sessions during teardown
Thanks Rodrigo for the ack.
On Thu, 2023-01-19 at 14:28 -0500, Vivi, Rodrigo wrote:
> On Thu, Jan 12, 2023 at 05:18:48PM -0800, Alan Previn wrote:
> > A gap was recently discovered where if an application did not
> > invalidate all of the stream keys (intentionally or not), and the
> > driver did a full PXP global teardown on the GT subsystem, we
> > find that future session creation would fail on the security
> > firmware's side of the equation. i915 is the entity that needs
> > ensure the sessions' state across both iGT and security firmware
> > are at a known clean point when performing a full global teardown.
> >
> > Architecturally speaking, i915 should inspect all active sessions
> > and submit the invalidate-stream-key PXP command to the security
> > firmware for each of them. However, for the upstream i915 driver
> > we only support the arbitration session that can be created
> > so that will be the only session we will cleanup.
> >
> > Signed-off-by: Alan Previn
> > Reviewed-by: Juston Li
>
> Acked-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
> > .../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 15
> > .../i915/pxp/intel_pxp_cmd_interface_cmn.h | 3 ++
> > drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 ++
> > drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 35 +++
> > 5 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > index 04440fada711..9658d3005222 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > @@ -24,6 +24,7 @@ void intel_pxp_init_hw(struct intel_pxp *pxp);
> > void intel_pxp_fini_hw(struct intel_pxp *pxp);
> >
> > void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
> > +void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
> > arb_session_id);
> >
> > int intel_pxp_start(struct intel_pxp *pxp);
> >
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> > index 739f9072fa5f..26f7d9f01bf3 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> > @@ -12,6 +12,9 @@
> > /* PXP-Opcode for Init Session */
> > #define PXP42_CMDID_INIT_SESSION 0x1e
> >
> > +/* PXP-Opcode for Invalidate Stream Key */
> > +#define PXP42_CMDID_INVALIDATE_STREAM_KEY 0x0007
> > +
> > /* PXP-Input-Packet: Init Session (Arb-Session) */
> > struct pxp42_create_arb_in {
> > struct pxp_cmd_header header;
> > @@ -25,4 +28,16 @@ struct pxp42_create_arb_out {
> > struct pxp_cmd_header header;
> > } __packed;
> >
> > +/* PXP-Input-Packet: Invalidate Stream Key */
> > +struct pxp42_inv_stream_key_in {
> > + struct pxp_cmd_header header;
> > + u32 rsvd[3];
> > +} __packed;
> > +
> > +/* PXP-Output-Packet: Invalidate Stream Key */
> > +struct pxp42_inv_stream_key_out {
> > + struct pxp_cmd_header header;
> > + u32 rsvd;
> > +} __packed;
> > +
> > #endif /* __INTEL_PXP_FW_INTERFACE_42_H__ */
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> > index c2f23394f9b8..69e34ec49e78 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> > @@ -27,6 +27,9 @@ struct pxp_cmd_header {
> > union {
> > u32 status; /* out */
> > u32 stream_id; /* in */
> > +#define PXP_CMDHDR_EXTDATA_SESSION_VALID GENMASK(0, 0)
> > +#define PXP_CMDHDR_EXTDATA_APP_TYPE GENMASK(1, 1)
> > +#define PXP_CMDHDR_EXTDATA_SESSION_ID GENMASK(17, 2)
> > };
> > /* Length of the message (excluding the header) */
> > u32 buffer_len;
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> > index ae413580b81a..74ed7e16e481 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> > @@ -110,6 +110,8 @@ static int pxp_terminate_arb_session_and_global(struct
> > intel_pxp *pxp)
> >
> > intel_uncore_write(gt->uncore, PXP_GLOBAL_TERMINATE, 1);
> >
> > + intel_pxp_tee_end_arb_fw_session(pxp, ARB_SESSION);
> > +
> > return ret;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > index bef6d7f8ac55..9e247f38f3bd 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > @@ -311,3 +311,38 @@ int intel_pxp_tee_cmd_create_arb_session(struct
> > intel_pxp *pxp,
> >
> > return ret;
> > }
> > +
> > +void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
> > session_id)
> > +{
> > + struct drm_i915_priva
Re: [PATCH v2 10/10] iommu/s390: Use GFP_KERNEL in sleepable contexts
On 1/18/23 1:00 PM, Jason Gunthorpe wrote: > These contexts are sleepable, so use the proper annotation. The GFP_ATOMIC > was added mechanically in the prior patches. > > Reviewed-by: Niklas Schnelle > Signed-off-by: Jason Gunthorpe > --- > arch/s390/pci/pci_dma.c| 2 +- > drivers/iommu/s390-iommu.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Matthew Rosato
Re: [PATCH v2 09/10] iommu/s390: Push the gfp parameter to the kmem_cache_alloc()'s
On 1/18/23 1:00 PM, Jason Gunthorpe wrote: > dma_alloc_cpu_table() and dma_alloc_page_table() are eventually called by > iommufd through s390_iommu_map_pages() and it should not be forced to > atomic. Thread the gfp parameter through the call chain starting from > s390_iommu_map_pages(). > > Reviewed-by: Niklas Schnelle > Signed-off-by: Jason Gunthorpe > --- > arch/s390/include/asm/pci_dma.h | 5 +++-- > arch/s390/pci/pci_dma.c | 31 +-- > drivers/iommu/s390-iommu.c | 15 +-- > 3 files changed, 29 insertions(+), 22 deletions(-) > Reviewed-by: Matthew Rosato
Re: [PATCH] drm/shmem: Cleanup drm_gem_shmem_create_with_handle()
Hi Rob,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.2-rc4 next-20230119]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Rob-Clark/drm-shmem-Cleanup-drm_gem_shmem_create_with_handle/20230120-021440
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230119181325.2834875-1-robdclark%40gmail.com
patch subject: [PATCH] drm/shmem: Cleanup drm_gem_shmem_create_with_handle()
config: ia64-allyesconfig
(https://download.01.org/0day-ci/archive/20230120/202301200511.h6af907u-...@intel.com/config)
compiler: ia64-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
#
https://github.com/intel-lab-lkp/linux/commit/0de4f64a7edc0dcbf8ac711d79e203698fcd95a7
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Rob-Clark/drm-shmem-Cleanup-drm_gem_shmem_create_with_handle/20230120-021440
git checkout 0de4f64a7edc0dcbf8ac711d79e203698fcd95a7
# 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=ia64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/gpu/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/drm_gem_shmem_helper.c: In function
'drm_gem_shmem_create_with_handle':
>> drivers/gpu/drm/drm_gem_shmem_helper.c:428:24: warning: returning 'struct
>> drm_gem_shmem_object *' from a function with return type 'int' makes integer
>> from pointer without a cast [-Wint-conversion]
428 | return shmem;
|^
drivers/gpu/drm/drm_gem_shmem_helper.c: In function
'drm_gem_shmem_dumb_create':
drivers/gpu/drm/drm_gem_shmem_helper.c:521:38: warning: unused variable
'shmem' [-Wunused-variable]
521 | struct drm_gem_shmem_object *shmem;
| ^
vim +428 drivers/gpu/drm/drm_gem_shmem_helper.c
2194a63a818db7 Noralf Trønnes 2019-03-12 417
0de4f64a7edc0d Rob Clark 2023-01-19 418 static int
2194a63a818db7 Noralf Trønnes 2019-03-12 419
drm_gem_shmem_create_with_handle(struct drm_file *file_priv,
2194a63a818db7 Noralf Trønnes 2019-03-12 420struct
drm_device *dev, size_t size,
2194a63a818db7 Noralf Trønnes 2019-03-12 421
uint32_t *handle)
2194a63a818db7 Noralf Trønnes 2019-03-12 422 {
2194a63a818db7 Noralf Trønnes 2019-03-12 423 struct drm_gem_shmem_object
*shmem;
2194a63a818db7 Noralf Trønnes 2019-03-12 424 int ret;
2194a63a818db7 Noralf Trønnes 2019-03-12 425
cfe28f909ddd6c Daniel Vetter 2020-06-16 426 shmem =
drm_gem_shmem_create(dev, size);
2194a63a818db7 Noralf Trønnes 2019-03-12 427 if (IS_ERR(shmem))
2194a63a818db7 Noralf Trønnes 2019-03-12 @428 return shmem;
2194a63a818db7 Noralf Trønnes 2019-03-12 429
2194a63a818db7 Noralf Trønnes 2019-03-12 430 /*
2194a63a818db7 Noralf Trønnes 2019-03-12 431* Allocate an id of idr table
where the obj is registered
2194a63a818db7 Noralf Trønnes 2019-03-12 432* and handle has the id what
user can see.
2194a63a818db7 Noralf Trønnes 2019-03-12 433*/
2194a63a818db7 Noralf Trønnes 2019-03-12 434 ret =
drm_gem_handle_create(file_priv, &shmem->base, handle);
2194a63a818db7 Noralf Trønnes 2019-03-12 435 /* drop reference from allocate
- handle holds it now. */
be6ee102341bc4 Emil Velikov 2020-05-15 436
drm_gem_object_put(&shmem->base);
2194a63a818db7 Noralf Trønnes 2019-03-12 437
0de4f64a7edc0d Rob Clark 2023-01-19 438 return ret;
2194a63a818db7 Noralf Trønnes 2019-03-12 439 }
2194a63a818db7 Noralf Trønnes 2019-03-12 440
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH drm-next 13/14] drm/nouveau: implement new VM_BIND UAPI
On Thu, Jan 19, 2023 at 06:46:30PM +0100, Danilo Krummrich wrote:
>
>
> On 1/19/23 17:38, Matthew Brost wrote:
> > On Thu, Jan 19, 2023 at 04:36:43PM +0100, Danilo Krummrich wrote:
> > > On 1/19/23 05:58, Matthew Brost wrote:
> > > > On Thu, Jan 19, 2023 at 04:44:23AM +0100, Danilo Krummrich wrote:
> > > > > On 1/18/23 21:37, Thomas Hellström (Intel) wrote:
> > > > > >
> > > > > > On 1/18/23 07:12, Danilo Krummrich wrote:
> > > > > > > This commit provides the implementation for the new uapi
> > > > > > > motivated by the
> > > > > > > Vulkan API. It allows user mode drivers (UMDs) to:
> > > > > > >
> > > > > > > 1) Initialize a GPU virtual address (VA) space via the new
> > > > > > > DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the
> > > > > > > portion of VA
> > > > > > > space managed by the kernel and userspace, respectively.
> > > > > > >
> > > > > > > 2) Allocate and free a VA space region as well as bind and unbind
> > > > > > > memory
> > > > > > > to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND
> > > > > > > ioctl.
> > > > > > > UMDs can request the named operations to be processed either
> > > > > > > synchronously or asynchronously. It supports DRM syncobjs
> > > > > > > (incl. timelines) as synchronization mechanism. The
> > > > > > > management of the
> > > > > > > GPU VA mappings is implemented with the DRM GPU VA manager.
> > > > > > >
> > > > > > > 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC
> > > > > > > ioctl. The
> > > > > > > execution happens asynchronously. It supports DRM syncobj
> > > > > > > (incl.
> > > > > > > timelines) as synchronization mechanism. DRM GEM object
> > > > > > > locking is
> > > > > > > handled with drm_exec.
> > > > > > >
> > > > > > > Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, use
> > > > > > > the DRM
> > > > > > > GPU scheduler for the asynchronous paths.
> > > > > > >
> > > > > > > Signed-off-by: Danilo Krummrich
> > > > > > > ---
> > > > > > > Documentation/gpu/driver-uapi.rst | 3 +
> > > > > > > drivers/gpu/drm/nouveau/Kbuild | 2 +
> > > > > > > drivers/gpu/drm/nouveau/Kconfig | 2 +
> > > > > > > drivers/gpu/drm/nouveau/nouveau_abi16.c | 16 +
> > > > > > > drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 +
> > > > > > > drivers/gpu/drm/nouveau/nouveau_drm.c | 23 +-
> > > > > > > drivers/gpu/drm/nouveau/nouveau_drv.h | 9 +-
> > > > > > > drivers/gpu/drm/nouveau/nouveau_exec.c | 310 ++
> > > > > > > drivers/gpu/drm/nouveau/nouveau_exec.h | 55 ++
> > > > > > > drivers/gpu/drm/nouveau/nouveau_sched.c | 780
> > > > > > >
> > > > > > > drivers/gpu/drm/nouveau/nouveau_sched.h | 98 +++
> > > > > > > 11 files changed, 1295 insertions(+), 4 deletions(-)
> > > > > > > create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.c
> > > > > > > create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.h
> > > > > > > create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.c
> > > > > > > create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.h
> > > > > > ...
> > > > > > >
> > > > > > > +static struct dma_fence *
> > > > > > > +nouveau_bind_job_run(struct nouveau_job *job)
> > > > > > > +{
> > > > > > > + struct nouveau_bind_job *bind_job = to_nouveau_bind_job(job);
> > > > > > > + struct nouveau_uvmm *uvmm = nouveau_cli_uvmm(job->cli);
> > > > > > > + struct bind_job_op *op;
> > > > > > > + int ret = 0;
> > > > > > > +
> > > > > >
> > > > > > I was looking at how nouveau does the async binding compared to how
> > > > > > xe
> > > > > > does it.
> > > > > > It looks to me that this function being a scheduler run_job
> > > > > > callback is
> > > > > > the main part of the VM_BIND dma-fence signalling critical section
> > > > > > for
> > > > > > the job's done_fence and if so, needs to be annotated as such?
> > > > >
> > > > > Yes, that's the case.
> > > > >
> > > > > >
> > > > > > For example nouveau_uvma_region_new allocates memory, which is not
> > > > > > allowed if in a dma_fence signalling critical section and the
> > > > > > locking
> > > > > > also looks suspicious?
> > > > >
> > > > > Thanks for pointing this out, I missed that somehow.
> > > > >
> > > > > I will change it to pre-allocate new regions, mappings and page tables
> > > > > within the job's submit() function.
> > > > >
> > > >
> > > > Yea that what we basically do in Xe, in the IOCTL step allocate all the
> > > > backing store for new page tables, populate new page tables (these are
> > > > not yet visible in the page table structure), and in last step which is
> > > > executed after all the dependencies are satified program all the leaf
> > > > entires making the new binding visible.
> > > >
> > > > We screwed have this up by defering most of the IOCTL to a worker but
> > > > will fix this fix this one way or anothe
Re: [PATCH RESEND 1/4] backlight: aat2870: Use backlight helper
On Fri, 06 Jan 2023, Stephen Kitt wrote: > Instead of retrieving the backlight brightness in struct > backlight_properties manually, and then checking whether the backlight > should be on at all, use backlight_get_brightness() which does all > this and insulates this from future changes. > > Signed-off-by: Stephen Kitt > --- > drivers/video/backlight/aat2870_bl.c | 7 +-- > 1 file changed, 1 insertion(+), 6 deletions(-) Applied, thanks -- Lee Jones [李琼斯]
Re: [PATCH RESEND 3/4] backlight: ipaq_micro: Use backlight helper
On Fri, 06 Jan 2023, Stephen Kitt wrote: > Instead of retrieving the backlight brightness in struct > backlight_properties manually, and then checking whether the backlight > should be on at all, use backlight_get_brightness() which does all > this and insulates this from future changes. > > Signed-off-by: Stephen Kitt > --- > drivers/video/backlight/ipaq_micro_bl.c | 7 +-- > 1 file changed, 1 insertion(+), 6 deletions(-) Applied, thanks -- Lee Jones [李琼斯]
Re: [PATCH RESEND 2/4] backlight: arcxcnn: Use backlight helper
On Fri, 06 Jan 2023, Stephen Kitt wrote: > Instead of retrieving the backlight brightness in struct > backlight_properties manually, and then checking whether the backlight > should be on at all, use backlight_get_brightness() which does all > this and insulates this from future changes. > > Signed-off-by: Stephen Kitt > --- > drivers/video/backlight/arcxcnn_bl.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) Applied, thanks -- Lee Jones [李琼斯]
Re: [PATCH 1/1] drm/i915/gsc: Fix the Driver-FLR completion
Forwarded offline. Let's hold off R-B or merging until I verify that hw spec
update is finalized to be exactly as what this patch is (probably a minor
delay).
On Thu, 2023-01-19 at 14:57 -0500, Vivi, Rodrigo wrote:
> On Thu, Jan 19, 2023 at 11:49:55AM -0800, Alan Previn wrote:
> > The Driver-FLR flow may inadvertently exit early before the full
> > completion of the re-init of the internal HW state if we only poll
> > GU_DEBUG Bit31 (polling for it to toggle from 0 -> 1). Instead
> > we need a two-step completion wait-for-completion flow that also
> > involves GU_CNTL. See the patch and new code comments for detail.
> > This is new direction from HW architecture folks.
>
> Do we have this documented anywhere?
>
> but the patch looks good to me...
>
> >
> > Signed-off-by: Alan Previn
> > Fixes: 5a44fcd73498 ("drm/i915/gsc: Do a driver-FLR on unload if GSC was
> > loaded")
> > ---
> > drivers/gpu/drm/i915/intel_uncore.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index 8dee9e62a73e..959869e2ff05 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -2748,6 +2748,12 @@ static void driver_initiated_flr(struct intel_uncore
> > *uncore)
> > /* Trigger the actual Driver-FLR */
> > intel_uncore_rmw_fw(uncore, GU_CNTL, 0, DRIVERFLR);
> >
> > + /* Completion Step 1 - poll for 'CNTL-BIT31 = 0' wait for hw
> > teardown to complete */
> > + ret = intel_wait_for_register_fw(uncore, GU_CNTL,
> > + DRIVERFLR_STATUS, 0,
> > + flr_timeout_ms);
> > +
> > + /* Completion: Step 2 - poll for 'DEBUG-BIT31 = 1' for hw/fw
> > re-init to complete */
> > ret = intel_wait_for_register_fw(uncore, GU_DEBUG,
> > DRIVERFLR_STATUS, DRIVERFLR_STATUS,
> > flr_timeout_ms);
> > @@ -2756,6 +2762,7 @@ static void driver_initiated_flr(struct intel_uncore
> > *uncore)
> > return;
> > }
> >
> > + /* Write 1 to clear GU_DEBUG's sticky completion status bit */
> > intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
> > }
> >
> >
> > base-commit: 0a0ee61784df01ac098a92bd43673ee30c629f13
> > --
> > 2.39.0
> >
[PATCH] drm/dma: Drop unbalanced obj unref
From: Rob Clark
In the error path, drm_gem_dma_mmap() is dropping an obj reference that
it doesn't own.
Fixes: f5ca8eb6f9bd ("drm/cma-helper: Implement mmap as GEM CMA object
functions")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem_dma_helper.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
b/drivers/gpu/drm/drm_gem_dma_helper.c
index 1e658c448366..784356d6f39d 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -544,8 +544,6 @@ int drm_gem_dma_mmap(struct drm_gem_dma_object *dma_obj,
struct vm_area_struct *
dma_obj->dma_addr,
vma->vm_end - vma->vm_start);
}
- if (ret)
- drm_gem_vm_close(vma);
return ret;
}
--
2.38.1
[pull] amdgpu drm-fixes-6.2
Hi Dave, Daniel, Fixes for 6.2. The following changes since commit e695bc7e542358978434c8489a5a164d2bbefae8: Merge tag 'drm-msm-fixes-2023-01-12' of https://gitlab.freedesktop.org/drm/msm into drm-fixes (2023-01-13 13:01:22 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.2-2023-01-19 for you to fetch changes up to a52287d66dfa1cca32e6273623b63ba39d87f126: drm/amd/display: disable S/G display on DCN 3.1.4 (2023-01-18 23:23:24 -0500) amd-drm-fixes-6.2-2023-01-19: amdgpu: - Fix display scaling - Fix RN/CZN power reporting on some firmware versions - Colorspace fixes - Fix resource freeing in error case in CS IOCTL - Fix warning on driver unload - GC11 fixes - DCN 3.1.4/5 S/G display workarounds Alex Deucher (2): drm/amd/display: disable S/G display on DCN 3.1.5 drm/amd/display: disable S/G display on DCN 3.1.4 Christian König (2): drm/amdgpu: fix cleaning up reserved VMID on release drm/amdgpu: fix amdgpu_job_free_resources v2 Hamza Mahfooz (1): drm/amd/display: fix issues with driver unload Joshua Ashton (2): drm/amd/display: Calculate output_color_space after pixel encoding adjustment drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix Lang Yu (2): drm/amdgpu: correct MEC number for gfx11 APUs drm/amdgpu: allow multipipe policy on ASICs with one MEC hongao (1): drm/amd/display: Fix set scaling doesn's work jie1zhan (1): drm/amdgpu: Correct the power calcultion for Renior/Cezanne. drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c| 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 10 -- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 11 +-- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 -- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 1 - drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c | 4 ++-- drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c| 7 ++- 8 files changed, 33 insertions(+), 18 deletions(-)
Re: [PATCH 1/1] drm/i915/gsc: Fix the Driver-FLR completion
On Thu, Jan 19, 2023 at 11:49:55AM -0800, Alan Previn wrote:
> The Driver-FLR flow may inadvertently exit early before the full
> completion of the re-init of the internal HW state if we only poll
> GU_DEBUG Bit31 (polling for it to toggle from 0 -> 1). Instead
> we need a two-step completion wait-for-completion flow that also
> involves GU_CNTL. See the patch and new code comments for detail.
> This is new direction from HW architecture folks.
Do we have this documented anywhere?
but the patch looks good to me...
>
> Signed-off-by: Alan Previn
> Fixes: 5a44fcd73498 ("drm/i915/gsc: Do a driver-FLR on unload if GSC was
> loaded")
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 8dee9e62a73e..959869e2ff05 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2748,6 +2748,12 @@ static void driver_initiated_flr(struct intel_uncore
> *uncore)
> /* Trigger the actual Driver-FLR */
> intel_uncore_rmw_fw(uncore, GU_CNTL, 0, DRIVERFLR);
>
> + /* Completion Step 1 - poll for 'CNTL-BIT31 = 0' wait for hw teardown
> to complete */
> + ret = intel_wait_for_register_fw(uncore, GU_CNTL,
> + DRIVERFLR_STATUS, 0,
> + flr_timeout_ms);
> +
> + /* Completion: Step 2 - poll for 'DEBUG-BIT31 = 1' for hw/fw re-init to
> complete */
> ret = intel_wait_for_register_fw(uncore, GU_DEBUG,
>DRIVERFLR_STATUS, DRIVERFLR_STATUS,
>flr_timeout_ms);
> @@ -2756,6 +2762,7 @@ static void driver_initiated_flr(struct intel_uncore
> *uncore)
> return;
> }
>
> + /* Write 1 to clear GU_DEBUG's sticky completion status bit */
> intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
> }
>
>
> base-commit: 0a0ee61784df01ac098a92bd43673ee30c629f13
> --
> 2.39.0
>
[PULL] drm-intel-fixes
Hi Dave and Daniel, Couple patches targeting stable, couple DG2 w/a, and a selftest fix. There was a drm-tip conflict but very trivial where keeping the new mtl function as in drm-intel-gt-next is the right resolution. Here goes drm-intel-fixes-2023-01-19: - Reject display plane with height == 0 (Drew) - re-disable RC6p on Sandy Bridge (Sasa) - Fix hugepages' selftest (Chris) - DG2 hw workarounds (Matt Atwood) Thanks, Rodrigo. The following changes since commit 5dc4c995db9eb45f6373a956eb1f69460e69e6d4: Linux 6.2-rc4 (2023-01-15 09:22:43 -0600) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-01-19 for you to fetch changes up to afdecb232740ae40b9384fa0ac8ed799d6546516: drm/i915/dg2: Introduce Wa_18019271663 (2023-01-18 11:56:54 -0500) - Reject display plane with height == 0 (Drew) - re-disable RC6p on Sandy Bridge (Sasa) - Fix hugepages' selftest (Chris) - DG2 hw workarounds (Matt Atwood) Chris Wilson (1): drm/i915/selftests: Unwind hugepages to drop wakeref on error Drew Davenport (1): drm/i915/display: Check source height is > 0 Matt Atwood (2): drm/i915/dg2: Introduce Wa_18018764978 drm/i915/dg2: Introduce Wa_18019271663 Sasa Dragic (1): drm/i915: re-disable RC6p on Sandy Bridge drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +- drivers/gpu/drm/i915/gem/selftests/huge_pages.c| 8 drivers/gpu/drm/i915/gt/intel_gt_regs.h| 10 +++--- drivers/gpu/drm/i915/gt/intel_workarounds.c| 10 +- drivers/gpu/drm/i915/i915_pci.c| 3 ++- 5 files changed, 23 insertions(+), 10 deletions(-)
[PATCH 1/1] drm/i915/gsc: Fix the Driver-FLR completion
The Driver-FLR flow may inadvertently exit early before the full
completion of the re-init of the internal HW state if we only poll
GU_DEBUG Bit31 (polling for it to toggle from 0 -> 1). Instead
we need a two-step completion wait-for-completion flow that also
involves GU_CNTL. See the patch and new code comments for detail.
This is new direction from HW architecture folks.
Signed-off-by: Alan Previn
Fixes: 5a44fcd73498 ("drm/i915/gsc: Do a driver-FLR on unload if GSC was
loaded")
---
drivers/gpu/drm/i915/intel_uncore.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 8dee9e62a73e..959869e2ff05 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2748,6 +2748,12 @@ static void driver_initiated_flr(struct intel_uncore
*uncore)
/* Trigger the actual Driver-FLR */
intel_uncore_rmw_fw(uncore, GU_CNTL, 0, DRIVERFLR);
+ /* Completion Step 1 - poll for 'CNTL-BIT31 = 0' wait for hw teardown
to complete */
+ ret = intel_wait_for_register_fw(uncore, GU_CNTL,
+DRIVERFLR_STATUS, 0,
+flr_timeout_ms);
+
+ /* Completion: Step 2 - poll for 'DEBUG-BIT31 = 1' for hw/fw re-init to
complete */
ret = intel_wait_for_register_fw(uncore, GU_DEBUG,
DRIVERFLR_STATUS, DRIVERFLR_STATUS,
flr_timeout_ms);
@@ -2756,6 +2762,7 @@ static void driver_initiated_flr(struct intel_uncore
*uncore)
return;
}
+ /* Write 1 to clear GU_DEBUG's sticky completion status bit */
intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
}
base-commit: 0a0ee61784df01ac098a92bd43673ee30c629f13
--
2.39.0
Re: [Intel-gfx] [PATCH v5 6/6] drm/i915/pxp: Pxp hw init should be in resume_complete
On Thu, Jan 19, 2023 at 11:10:21AM -0800, Ceraolo Spurio, Daniele wrote:
>
>
> On 1/12/2023 5:18 PM, Alan Previn wrote:
> > During suspend flow, i915 currently achors' on the pm_suspend_prepare
> > callback as the location where we quiesce the entire GPU and perform
> > all necessary cleanup in order to go into suspend. PXP is also called
> > during this time to perform the arbitration session teardown (with
> > the assurance no additional GEM IOCTLs will come after that could
> > restart the session).
> >
> > However, if other devices or drivers fail their suspend_prepare, the
> > system will not go into suspend and i915 will be expected to resume
> > operation. In this case, we need to re-initialize the PXP hardware
> > and this really should be done within the pm_resume_complete callback
> > which is the correct opposing function in the resume sequence to
> > match pm_suspend_prepare of the suspend sequence.
> >
> > Because this callback is the last thing at the end of resuming
> > we expect little to no impact to the rest of the i915 resume sequence
> > with this change.
> >
> > Signed-off-by: Alan Previn
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_pm.h | 1 +
> > drivers/gpu/drm/i915/i915_driver.c | 20 ++--
> > drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 2 +-
> > drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 6 +++---
> > 4 files changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > index 6c9a46452364..fd1a23621222 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > @@ -77,6 +77,7 @@ void intel_gt_pm_fini(struct intel_gt *gt);
> > void intel_gt_suspend_prepare(struct intel_gt *gt);
> > void intel_gt_suspend_late(struct intel_gt *gt);
> > +
>
> Stray newline. With this removed:
>
> Reviewed-by: Daniele Ceraolo Spurio
Acked-by: Rodrigo Vivi
>
> Daniele
>
> > int intel_gt_resume(struct intel_gt *gt);
> > void intel_gt_runtime_suspend(struct intel_gt *gt);
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index c1e427ba57ae..4c68a3f26e96 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -1170,6 +1170,13 @@ static bool suspend_to_idle(struct drm_i915_private
> > *dev_priv)
> > return false;
> > }
> > +static void i915_drm_complete(struct drm_device *dev)
> > +{
> > + struct drm_i915_private *i915 = to_i915(dev);
> > +
> > + intel_pxp_resume_complete(i915->pxp);
> > +}
> > +
> > static int i915_drm_prepare(struct drm_device *dev)
> > {
> > struct drm_i915_private *i915 = to_i915(dev);
> > @@ -1370,8 +1377,6 @@ static int i915_drm_resume(struct drm_device *dev)
> > i915_gem_resume(dev_priv);
> > - intel_pxp_resume(dev_priv->pxp);
> > -
> > intel_modeset_init_hw(dev_priv);
> > intel_init_clock_gating(dev_priv);
> > intel_hpd_init(dev_priv);
> > @@ -1563,6 +1568,16 @@ static int i915_pm_resume(struct device *kdev)
> > return i915_drm_resume(&i915->drm);
> > }
> > +static void i915_pm_complete(struct device *kdev)
> > +{
> > + struct drm_i915_private *i915 = kdev_to_i915(kdev);
> > +
> > + if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
> > + return;
> > +
> > + i915_drm_complete(&i915->drm);
> > +}
> > +
> > /* freeze: before creating the hibernation_image */
> > static int i915_pm_freeze(struct device *kdev)
> > {
> > @@ -1783,6 +1798,7 @@ const struct dev_pm_ops i915_pm_ops = {
> > .suspend_late = i915_pm_suspend_late,
> > .resume_early = i915_pm_resume_early,
> > .resume = i915_pm_resume,
> > + .complete = i915_pm_complete,
> > /*
> > * S4 event handlers
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > index e427464aa131..4f836b317424 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > @@ -34,7 +34,7 @@ void intel_pxp_suspend(struct intel_pxp *pxp)
> > }
> > }
> > -void intel_pxp_resume(struct intel_pxp *pxp)
> > +void intel_pxp_resume_complete(struct intel_pxp *pxp)
> > {
> > if (!intel_pxp_is_enabled(pxp))
> > return;
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
> > index 586be769104f..06b46f535b42 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
> > @@ -11,7 +11,7 @@ struct intel_pxp;
> > #ifdef CONFIG_DRM_I915_PXP
> > void intel_pxp_suspend_prepare(struct intel_pxp *pxp);
> > void intel_pxp_suspend(struct intel_pxp *pxp);
> > -void intel_pxp_resume(struct intel_pxp *pxp);
> > +void intel_pxp_resume_complete(struct intel_pxp *pxp);
> > void intel_pxp_runtime_suspend(struct intel_pxp *pxp);
> > #else
> > static inline void intel_pxp_suspend_pre
Re: [PATCH v5 5/6] drm/i915/pxp: Trigger the global teardown for before suspending
On Thu, Jan 12, 2023 at 05:18:49PM -0800, Alan Previn wrote:
> A driver bug was recently discovered where the security firmware was
> receiving internal HW signals indicating that session key expirations
> had occurred. Architecturally, the firmware was expecting a response
> from the GuC to acknowledge the event with the firmware side.
> However the OS was in a suspended state and GuC had been reset.
>
> Internal specifications actually required the driver to ensure
> that all active sessions be properly cleaned up in such cases where
> the system is suspended and the GuC potentially unable to respond.
>
> This patch adds the global teardown code in i915's suspend_prepare
> code path.
>
> Signed-off-by: Alan Previn
> Reviewed-by: Juston Li
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 60 +---
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
> drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 2 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 9 ++-
> drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 ++
> 5 files changed, 64 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index cfc9af8b3d21..f3d9e7989eb7 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -270,6 +270,55 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
> return bound;
> }
>
> +static int __pxp_global_teardown_locked(struct intel_pxp *pxp, bool
> terminate_for_cleanup)
> +{
> + if (terminate_for_cleanup) {
> + if (!pxp->arb_is_valid)
> + return 0;
> + /*
> + * To ensure synchronous and coherent session teardown
> completion
> + * in response to suspend or shutdown triggers, don't use a
> worker.
> + */
> + intel_pxp_mark_termination_in_progress(pxp);
> + intel_pxp_terminate(pxp, false);
> + } else {
> + if (pxp->arb_is_valid)
> + return 0;
> + /*
> + * If we are not in final termination, and the arb-session is
> currently
> + * inactive, we are doing a reset and restart due to some
> runtime event.
> + * Use the worker that was designed for this.
> + */
> + pxp_queue_termination(pxp);
> + }
I really don't see why you need 1 function for totally 2 different cases.
Why not 2 functions then?
> +
> + if (!wait_for_completion_timeout(&pxp->termination,
> msecs_to_jiffies(250)))
> + return -ETIMEDOUT;
> +
> + return 0;
> +}
> +
> +void intel_pxp_end(struct intel_pxp *pxp)
> +{
> + struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
> + intel_wakeref_t wakeref;
> +
> + if (!intel_pxp_is_enabled(pxp))
> + return;
> +
> + wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> +
> + mutex_lock(&pxp->arb_mutex);
> +
> + if (__pxp_global_teardown_locked(pxp, true))
> + drm_dbg(&i915->drm, "PXP end timed out\n");
> +
> + mutex_unlock(&pxp->arb_mutex);
> +
> + intel_pxp_fini_hw(pxp);
> + intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> +}
> +
> /*
> * the arb session is restarted from the irq work when we receive the
> * termination completion interrupt
> @@ -286,16 +335,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
>
> mutex_lock(&pxp->arb_mutex);
>
> - if (pxp->arb_is_valid)
> - goto unlock;
> -
> - pxp_queue_termination(pxp);
> -
> - if (!wait_for_completion_timeout(&pxp->termination,
> - msecs_to_jiffies(250))) {
> - ret = -ETIMEDOUT;
> + ret = __pxp_global_teardown_locked(pxp, false);
> + if (ret)
> goto unlock;
> - }
>
> /* make sure the compiler doesn't optimize the double access */
> barrier();
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index 9658d3005222..3ded0890cd27 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -27,6 +27,7 @@ void intel_pxp_mark_termination_in_progress(struct
> intel_pxp *pxp);
> void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
> arb_session_id);
>
> int intel_pxp_start(struct intel_pxp *pxp);
> +void intel_pxp_end(struct intel_pxp *pxp);
>
> int intel_pxp_key_check(struct intel_pxp *pxp,
> struct drm_i915_gem_object *obj,
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> index 892d39cc61c1..e427464aa131 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> @@ -16,7 +16,7 @@ void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
> if (!intel_pxp_is_enabled(pxp))
> return;
>
> - pxp->arb_is_valid = false;
> + intel_pxp_en
Re: [Intel-gfx] [PATCH v5 4/6] drm/i915/pxp: Invalidate all PXP fw sessions during teardown
On Thu, Jan 12, 2023 at 05:18:48PM -0800, Alan Previn wrote:
> A gap was recently discovered where if an application did not
> invalidate all of the stream keys (intentionally or not), and the
> driver did a full PXP global teardown on the GT subsystem, we
> find that future session creation would fail on the security
> firmware's side of the equation. i915 is the entity that needs
> ensure the sessions' state across both iGT and security firmware
> are at a known clean point when performing a full global teardown.
>
> Architecturally speaking, i915 should inspect all active sessions
> and submit the invalidate-stream-key PXP command to the security
> firmware for each of them. However, for the upstream i915 driver
> we only support the arbitration session that can be created
> so that will be the only session we will cleanup.
>
> Signed-off-by: Alan Previn
> Reviewed-by: Juston Li
Acked-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
> .../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 15
> .../i915/pxp/intel_pxp_cmd_interface_cmn.h| 3 ++
> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 ++
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 35 +++
> 5 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index 04440fada711..9658d3005222 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -24,6 +24,7 @@ void intel_pxp_init_hw(struct intel_pxp *pxp);
> void intel_pxp_fini_hw(struct intel_pxp *pxp);
>
> void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
> +void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
> arb_session_id);
>
> int intel_pxp_start(struct intel_pxp *pxp);
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> index 739f9072fa5f..26f7d9f01bf3 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
> @@ -12,6 +12,9 @@
> /* PXP-Opcode for Init Session */
> #define PXP42_CMDID_INIT_SESSION 0x1e
>
> +/* PXP-Opcode for Invalidate Stream Key */
> +#define PXP42_CMDID_INVALIDATE_STREAM_KEY 0x0007
> +
> /* PXP-Input-Packet: Init Session (Arb-Session) */
> struct pxp42_create_arb_in {
> struct pxp_cmd_header header;
> @@ -25,4 +28,16 @@ struct pxp42_create_arb_out {
> struct pxp_cmd_header header;
> } __packed;
>
> +/* PXP-Input-Packet: Invalidate Stream Key */
> +struct pxp42_inv_stream_key_in {
> + struct pxp_cmd_header header;
> + u32 rsvd[3];
> +} __packed;
> +
> +/* PXP-Output-Packet: Invalidate Stream Key */
> +struct pxp42_inv_stream_key_out {
> + struct pxp_cmd_header header;
> + u32 rsvd;
> +} __packed;
> +
> #endif /* __INTEL_PXP_FW_INTERFACE_42_H__ */
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> index c2f23394f9b8..69e34ec49e78 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
> @@ -27,6 +27,9 @@ struct pxp_cmd_header {
> union {
> u32 status; /* out */
> u32 stream_id; /* in */
> +#define PXP_CMDHDR_EXTDATA_SESSION_VALID GENMASK(0, 0)
> +#define PXP_CMDHDR_EXTDATA_APP_TYPE GENMASK(1, 1)
> +#define PXP_CMDHDR_EXTDATA_SESSION_ID GENMASK(17, 2)
> };
> /* Length of the message (excluding the header) */
> u32 buffer_len;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> index ae413580b81a..74ed7e16e481 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> @@ -110,6 +110,8 @@ static int pxp_terminate_arb_session_and_global(struct
> intel_pxp *pxp)
>
> intel_uncore_write(gt->uncore, PXP_GLOBAL_TERMINATE, 1);
>
> + intel_pxp_tee_end_arb_fw_session(pxp, ARB_SESSION);
> +
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> index bef6d7f8ac55..9e247f38f3bd 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -311,3 +311,38 @@ int intel_pxp_tee_cmd_create_arb_session(struct
> intel_pxp *pxp,
>
> return ret;
> }
> +
> +void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32 session_id)
> +{
> + struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
> + struct pxp42_inv_stream_key_in msg_in = {0};
> + struct pxp42_inv_stream_key_out msg_out = {0};
> + int ret, trials = 0;
> +
> +try_again:
> + memset(&msg_in, 0, sizeof(msg_in));
> + memset(&msg_out, 0, sizeof(msg_out));
> + msg_in.header.api_version = PXP_APIVER(4, 2);
> + msg_in.header.comman
Re: [PATCH RFC v7 00/23] DEPT(Dependency Tracker)
On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote: > On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote: > > Boqun wrote: > > > * Looks like the DEPT dependency graph doesn't handle the > > > fair/unfair readers as lockdep current does. Which bring the > > > next question. > > > > No. DEPT works better for unfair read. It works based on wait/event. So > > read_lock() is considered a potential wait waiting on write_unlock() > > while write_lock() is considered a potential wait waiting on either > > write_unlock() or read_unlock(). DEPT is working perfect for it. > > > > For fair read (maybe you meant queued read lock), I think the case > > should be handled in the same way as normal lock. I might get it wrong. > > Please let me know if I miss something. > > From the lockdep/DEPT point of view, the question is whether: > > read_lock(A) > read_lock(A) > > can deadlock if a writer comes in between the two acquisitions and > sleeps waiting on A to be released. A fair lock will block new > readers when a writer is waiting, while an unfair lock will allow > new readers even while a writer is waiting. > To be more accurate, a fair reader will wait if there is a writer waiting for other reader (fair or not) to unlock, and an unfair reader won't. In kernel there are read/write locks that can have both fair and unfair readers (e.g. queued rwlock). Regarding deadlocks, T0 T1 T2 -- -- -- fair_read_lock(A); write_lock(B); write_lock(A); write_lock(B); unfair_read_lock(A); the above is not a deadlock, since T1's unfair reader can "steal" the lock. However the following is a deadlock: T0 T1 T2 -- -- -- unfair_read_lock(A); write_lock(B); write_lock(A); write_lock(B); fair_read_lock(A); , since T'1 fair reader will wait. FWIW, lockdep is able to catch this (figuring out which is deadlock and which is not) since two years ago, plus other trivial deadlock detection for read/write locks. Needless to say, if lib/lock-selftests.c was given a try, one could find it out on one's own. Regards, Boqun
Re: [Intel-gfx] [PATCH v5 2/6] drm/i915/pxp: add device link between i915 and mei_pxp
On Thu, Jan 12, 2023 at 05:18:46PM -0800, Alan Previn wrote:
> From: Alexander Usyskin
>
> Add device link with i915 as consumer and mei_pxp as supplier
> to ensure proper ordering of power flows.
>
> V2: condition on absence of heci_pxp to filter out DG
>
> Signed-off-by: Alexander Usyskin
> Signed-off-by: Alan Previn
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> index d50354bfb993..bef6d7f8ac55 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -127,6 +127,10 @@ static int i915_pxp_tee_component_bind(struct device
> *i915_kdev,
> intel_wakeref_t wakeref;
> int ret = 0;
>
> + if (!HAS_HECI_PXP(i915) &&
> + drm_WARN_ON(&i915->drm, !device_link_add(i915_kdev, tee_kdev,
I don't like the action here hidden behind the drm_WARN_ON.
Please notice that almost every use of this and other helpers like
this expect the param as a failure. Not an actual action. So,
most of lazy readers like me might ignore that the main function
is actually a param inside this warn condition.
We should probably stash the link as well...
pxp->dev_link = device_link_add(i915_kdev, tee_kdev,...);
so in the end below, instead of checking the HAS_HECI_PXP again
and use the remove version you check the dev_link and use the del
function.
something like:
if (pxp->dev_link)
device_link_del(pxp->dev_link);
Also, do you really need the WARN to see the stack when this happens
or you already know the callers?
Why not a simple drm_error msg?
if (!HAS_HECI_PXP(i915) {
pxp->dev_link = device_link_add(i915_kdev, tee_kdev,...);
if (!pxp->dev_link) {
drm_error();
return -ESOMETHING;
> DL_FLAG_STATELESS)))
do we need the RPM in sync as well?
I mean:
DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME)))
?
> + return -ENOMEM;
why ENOMEM?
> +
> mutex_lock(&pxp->tee_mutex);
> pxp->pxp_component = data;
> pxp->pxp_component->tee_dev = tee_kdev;
> @@ -169,6 +173,9 @@ static void i915_pxp_tee_component_unbind(struct device
> *i915_kdev,
> mutex_lock(&pxp->tee_mutex);
> pxp->pxp_component = NULL;
> mutex_unlock(&pxp->tee_mutex);
> +
> + if (!HAS_HECI_PXP(i915))
> + device_link_remove(i915_kdev, tee_kdev);
> }
>
> static const struct component_ops i915_pxp_tee_component_ops = {
> --
> 2.39.0
>
Re: [PATCH v5 6/6] drm/i915/pxp: Pxp hw init should be in resume_complete
On 1/12/2023 5:18 PM, Alan Previn wrote:
During suspend flow, i915 currently achors' on the pm_suspend_prepare
callback as the location where we quiesce the entire GPU and perform
all necessary cleanup in order to go into suspend. PXP is also called
during this time to perform the arbitration session teardown (with
the assurance no additional GEM IOCTLs will come after that could
restart the session).
However, if other devices or drivers fail their suspend_prepare, the
system will not go into suspend and i915 will be expected to resume
operation. In this case, we need to re-initialize the PXP hardware
and this really should be done within the pm_resume_complete callback
which is the correct opposing function in the resume sequence to
match pm_suspend_prepare of the suspend sequence.
Because this callback is the last thing at the end of resuming
we expect little to no impact to the rest of the i915 resume sequence
with this change.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 1 +
drivers/gpu/drm/i915/i915_driver.c | 20 ++--
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 6 +++---
4 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 6c9a46452364..fd1a23621222 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -77,6 +77,7 @@ void intel_gt_pm_fini(struct intel_gt *gt);
void intel_gt_suspend_prepare(struct intel_gt *gt);
void intel_gt_suspend_late(struct intel_gt *gt);
+
Stray newline. With this removed:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
int intel_gt_resume(struct intel_gt *gt);
void intel_gt_runtime_suspend(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index c1e427ba57ae..4c68a3f26e96 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1170,6 +1170,13 @@ static bool suspend_to_idle(struct drm_i915_private
*dev_priv)
return false;
}
+static void i915_drm_complete(struct drm_device *dev)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+
+ intel_pxp_resume_complete(i915->pxp);
+}
+
static int i915_drm_prepare(struct drm_device *dev)
{
struct drm_i915_private *i915 = to_i915(dev);
@@ -1370,8 +1377,6 @@ static int i915_drm_resume(struct drm_device *dev)
i915_gem_resume(dev_priv);
- intel_pxp_resume(dev_priv->pxp);
-
intel_modeset_init_hw(dev_priv);
intel_init_clock_gating(dev_priv);
intel_hpd_init(dev_priv);
@@ -1563,6 +1568,16 @@ static int i915_pm_resume(struct device *kdev)
return i915_drm_resume(&i915->drm);
}
+static void i915_pm_complete(struct device *kdev)
+{
+ struct drm_i915_private *i915 = kdev_to_i915(kdev);
+
+ if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
+ return;
+
+ i915_drm_complete(&i915->drm);
+}
+
/* freeze: before creating the hibernation_image */
static int i915_pm_freeze(struct device *kdev)
{
@@ -1783,6 +1798,7 @@ const struct dev_pm_ops i915_pm_ops = {
.suspend_late = i915_pm_suspend_late,
.resume_early = i915_pm_resume_early,
.resume = i915_pm_resume,
+ .complete = i915_pm_complete,
/*
* S4 event handlers
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index e427464aa131..4f836b317424 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -34,7 +34,7 @@ void intel_pxp_suspend(struct intel_pxp *pxp)
}
}
-void intel_pxp_resume(struct intel_pxp *pxp)
+void intel_pxp_resume_complete(struct intel_pxp *pxp)
{
if (!intel_pxp_is_enabled(pxp))
return;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
index 586be769104f..06b46f535b42 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
@@ -11,7 +11,7 @@ struct intel_pxp;
#ifdef CONFIG_DRM_I915_PXP
void intel_pxp_suspend_prepare(struct intel_pxp *pxp);
void intel_pxp_suspend(struct intel_pxp *pxp);
-void intel_pxp_resume(struct intel_pxp *pxp);
+void intel_pxp_resume_complete(struct intel_pxp *pxp);
void intel_pxp_runtime_suspend(struct intel_pxp *pxp);
#else
static inline void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
@@ -22,7 +22,7 @@ static inline void intel_pxp_suspend(struct intel_pxp *pxp)
{
}
-static inline void intel_pxp_resume(struct intel_pxp *pxp)
+static inline void intel_pxp_resume_complete(struct intel_pxp *pxp)
{
}
@@ -32,6 +32,6 @@ static inline void intel_pxp_runtime_suspend(struct intel_pxp *pxp)
#endif
static inline void intel_pxp_runtime_resume(struct intel_pxp *pxp)
{
- intel_pxp_resume(pxp);
+
[PATCH v3 3/3] drm: Convert users of drm_of_component_match_add to component_match_add_of
Every user of this function either uses component_compare_of or
something equivalent. Most of them immediately put the device node as
well. Convert these users to component_match_add_of and remove
drm_of_component_match_add.
Signed-off-by: Sean Anderson
Acked-by: Jyri Sarha
Tested-by: Jyri Sarha
---
(no changes since v1)
.../gpu/drm/arm/display/komeda/komeda_drv.c | 6 ++--
drivers/gpu/drm/arm/hdlcd_drv.c | 9 +-
drivers/gpu/drm/arm/malidp_drv.c | 11 +--
drivers/gpu/drm/armada/armada_drv.c | 10 ---
drivers/gpu/drm/drm_of.c | 29 +++
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 +--
.../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +-
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 3 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c| 4 +--
drivers/gpu/drm/msm/msm_drv.c | 14 -
drivers/gpu/drm/sti/sti_drv.c | 3 +-
drivers/gpu/drm/sun4i/sun4i_drv.c | 3 +-
drivers/gpu/drm/tilcdc/tilcdc_external.c | 10 ++-
include/drm/drm_of.h | 12
14 files changed, 33 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
index 3f4e719eebd8..e3bfc72c378f 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
@@ -103,10 +103,8 @@ static void komeda_add_slave(struct device *master,
struct device_node *remote;
remote = of_graph_get_remote_node(np, port, endpoint);
- if (remote) {
- drm_of_component_match_add(master, match, component_compare_of,
remote);
- of_node_put(remote);
- }
+ if (remote)
+ component_match_add_of(master, match, remote);
}
static int komeda_platform_probe(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index e3507dd6f82a..5f760bb66af4 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -347,11 +347,6 @@ static const struct component_master_ops hdlcd_master_ops
= {
.unbind = hdlcd_drm_unbind,
};
-static int compare_dev(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
static int hdlcd_probe(struct platform_device *pdev)
{
struct device_node *port;
@@ -362,9 +357,7 @@ static int hdlcd_probe(struct platform_device *pdev)
if (!port)
return -ENODEV;
- drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
- of_node_put(port);
-
+ component_match_add_of(&pdev->dev, &match, port);
return component_master_add_with_match(&pdev->dev, &hdlcd_master_ops,
match);
}
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 589c1c66a6dc..3a49c29ba5b8 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -909,13 +909,6 @@ static const struct component_master_ops malidp_master_ops
= {
.unbind = malidp_unbind,
};
-static int malidp_compare_dev(struct device *dev, void *data)
-{
- struct device_node *np = data;
-
- return dev->of_node == np;
-}
-
static int malidp_platform_probe(struct platform_device *pdev)
{
struct device_node *port;
@@ -929,9 +922,7 @@ static int malidp_platform_probe(struct platform_device
*pdev)
if (!port)
return -ENODEV;
- drm_of_component_match_add(&pdev->dev, &match, malidp_compare_dev,
- port);
- of_node_put(port);
+ component_match_add_of(&pdev->dev, &match, port);
return component_master_add_with_match(&pdev->dev, &malidp_master_ops,
match);
}
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index 0643887800b4..c0211ad7a45d 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -184,10 +184,12 @@ static void armada_add_endpoints(struct device *dev,
for_each_endpoint_of_node(dev_node, ep) {
remote = of_graph_get_remote_port_parent(ep);
- if (remote && of_device_is_available(remote))
- drm_of_component_match_add(dev, match,
component_compare_of,
- remote);
- of_node_put(remote);
+ if (remote) {
+ if (of_device_is_available(remote))
+ component_match_add_of(dev, match, remote);
+ else
+ of_node_put(remote);
+ }
}
}
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 7bbcb999bb75..0a474729ddf6 100644
--- a/drivers/gpu/drm/dr
[PATCH v3 1/3] component: Add helper for device nodes
There is a common case where component_patch_add_release is called with
component_release_of/component_compare_of and a device node. Add a
helper.
Signed-off-by: Sean Anderson
---
(no changes since v2)
Changes in v2:
- Split off conversion from helper addition
include/linux/component.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/component.h b/include/linux/component.h
index df4aa75c9e7c..fb5d2dbc34d8 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -6,6 +6,7 @@
struct device;
+struct device_node;
/**
* struct component_ops - callbacks for component drivers
@@ -128,4 +129,12 @@ static inline void component_match_add(struct device
*parent,
compare_data);
}
+static inline void component_match_add_of(struct device *parent,
+ struct component_match **matchptr,
+ struct device_node *node)
+{
+ component_match_add_release(parent, matchptr, component_release_of,
+ component_compare_of, node);
+}
+
#endif
--
2.35.1.1320.gc452695387.dirty
[PATCH v3 2/3] iommu/sound: Use component_match_add_of helper
Convert users of component_match_add_release with component_release_of
and component_compare_of to component_match_add_of.
Signed-off-by: Sean Anderson
Acked-by: Mark Brown
---
Changes in v3:
- Rebase onto drm/drm-next
Changes in v2:
- Split off from helper addition
drivers/iommu/mtk_iommu_v1.c | 3 +--
sound/soc/codecs/wcd938x.c | 6 ++
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 69682ee068d2..14019ba1e41c 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -670,8 +670,7 @@ static int mtk_iommu_v1_probe(struct platform_device *pdev)
}
data->larb_imu[i].dev = &plarbdev->dev;
- component_match_add_release(dev, &match, component_release_of,
- component_compare_of, larbnode);
+ component_match_add_of(dev, &match, larbnode);
}
platform_set_drvdata(pdev, data);
diff --git a/sound/soc/codecs/wcd938x.c b/sound/soc/codecs/wcd938x.c
index fcac763b04d1..0663b15fa757 100644
--- a/sound/soc/codecs/wcd938x.c
+++ b/sound/soc/codecs/wcd938x.c
@@ -4474,8 +4474,7 @@ static int wcd938x_add_slave_components(struct
wcd938x_priv *wcd938x,
}
of_node_get(wcd938x->rxnode);
- component_match_add_release(dev, matchptr, component_release_of,
- component_compare_of, wcd938x->rxnode);
+ component_match_add_of(dev, matchptr, wcd938x->rxnode);
wcd938x->txnode = of_parse_phandle(np, "qcom,tx-device", 0);
if (!wcd938x->txnode) {
@@ -4483,8 +4482,7 @@ static int wcd938x_add_slave_components(struct
wcd938x_priv *wcd938x,
return -ENODEV;
}
of_node_get(wcd938x->txnode);
- component_match_add_release(dev, matchptr, component_release_of,
- component_compare_of, wcd938x->txnode);
+ component_match_add_of(dev, matchptr, wcd938x->txnode);
return 0;
}
--
2.35.1.1320.gc452695387.dirty
[PATCH v3 0/3] drm: Add component_match_add_of and convert users of drm_of_component_match_add
This series adds a new function component_match_add_of to simplify the common case of calling component_match_add_release with component_release_of and component_compare_of. There is already drm_of_component_match_add, which allows for a custom compare function. However, all existing users just use component_compare_of (or an equivalent). Changes in v3: - Rebase onto drm/drm-next Changes in v2: - Split off conversion from helper addition - Rebase onto drm/drm-next Sean Anderson (3): component: Add helper for device nodes iommu/sound: Use component_match_add_of helper drm: Convert users of drm_of_component_match_add to component_match_add_of .../gpu/drm/arm/display/komeda/komeda_drv.c | 6 ++-- drivers/gpu/drm/arm/hdlcd_drv.c | 9 +- drivers/gpu/drm/arm/malidp_drv.c | 11 +-- drivers/gpu/drm/armada/armada_drv.c | 10 --- drivers/gpu/drm/drm_of.c | 29 +++ drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 +-- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 3 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c| 4 +-- drivers/gpu/drm/msm/msm_drv.c | 14 - drivers/gpu/drm/sti/sti_drv.c | 3 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 3 +- drivers/gpu/drm/tilcdc/tilcdc_external.c | 10 ++- drivers/iommu/mtk_iommu_v1.c | 3 +- include/drm/drm_of.h | 12 include/linux/component.h | 9 ++ sound/soc/codecs/wcd938x.c| 6 ++-- 17 files changed, 45 insertions(+), 94 deletions(-) -- 2.35.1.1320.gc452695387.dirty
[PATCH v3] drm: kirin: Enable COMPILE_TEST
Make various small changes to allow compile-testing on other arches.
This is helpful to allow testing changes to 32-bit arm drivers in the
same build.
The primary changes is to use macros for 64-bit divisions and shifts,
but we also need some other fixes to deal with larger constants and
differences in includes.
Signed-off-by: Sean Anderson
---
Changes in v3:
- Include io.h for readl/writel
Changes in v2:
- Use BIT_ULL
drivers/gpu/drm/hisilicon/kirin/Kconfig | 2 +-
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 10 +-
drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h| 2 ++
drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 2 +-
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig
b/drivers/gpu/drm/hisilicon/kirin/Kconfig
index c5265675bf0c..0772f79567ef 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Kconfig
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_HISI_KIRIN
tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
- depends on DRM && OF && ARM64
+ depends on DRM && OF && (ARM64 || COMPILE_TEST)
select DRM_KMS_HELPER
select DRM_GEM_DMA_HELPER
select DRM_MIPI_DSI
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index d9978b79828c..1cfeffefd4b4 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -157,8 +157,8 @@ static u32 dsi_calc_phy_rate(u32 req_kHz, struct
mipi_phy_params *phy)
q_pll = 0x10 >> (7 - phy->hstx_ckg_sel);
temp = f_kHz * (u64)q_pll * (u64)ref_clk_ps;
- m_n_int = temp / (u64)10;
- m_n = (temp % (u64)10) / (u64)1;
+ m_n_int = div_u64_rem(temp, 10, &m_n);
+ m_n /= 1;
if (m_n_int % 2 == 0) {
if (m_n * 6 >= 50) {
@@ -229,8 +229,8 @@ static u32 dsi_calc_phy_rate(u32 req_kHz, struct
mipi_phy_params *phy)
phy->pll_fbd_div5f = 1;
}
- f_kHz = (u64)10 * (u64)m_pll /
- ((u64)ref_clk_ps * (u64)n_pll * (u64)q_pll);
+ f_kHz = div64_u64((u64)10 * (u64)m_pll,
+ (u64)ref_clk_ps * (u64)n_pll * (u64)q_pll);
if (f_kHz >= req_kHz)
break;
@@ -490,7 +490,7 @@ static void dsi_set_mode_timing(void __iomem *base,
hsa_time = (hsw * lane_byte_clk_kHz) / pixel_clk_kHz;
hbp_time = (hbp * lane_byte_clk_kHz) / pixel_clk_kHz;
tmp = (u64)htot * (u64)lane_byte_clk_kHz;
- hline_time = DIV_ROUND_UP(tmp, pixel_clk_kHz);
+ hline_time = DIV64_U64_ROUND_UP(tmp, pixel_clk_kHz);
/* all specified in byte-lane clocks */
writel(hsa_time, base + VID_HSA_TIME);
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
index d79fc031e53d..a87d1135856f 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
@@ -7,6 +7,8 @@
#ifndef __DW_DSI_REG_H__
#define __DW_DSI_REG_H__
+#include
+
#define MASK(x)(BIT(x) - 1)
/*
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
index be9e789c2d04..36f923cc7594 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
@@ -10,7 +10,7 @@
/*
* ADE Registers
*/
-#define MASK(x)(BIT(x) - 1)
+#define MASK(x)(BIT_ULL(x) - 1)
#define ADE_CTRL 0x0004
#define FRM_END_START_OFST 0
--
2.35.1.1320.gc452695387.dirty
Re: [PATCH v6 2/2] backlight: ktz8866: Add support for Kinetic KTZ8866 backlight
Hi Jianhua, I love your patch! Perhaps something to improve: [auto build test WARNING on lee-backlight/for-backlight-next] [also build test WARNING on lee-backlight/for-backlight-fixes lee-leds/for-leds-next pavel-leds/for-next linus/master v6.2-rc4 next-20230119] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Jianhua-Lu/backlight-ktz8866-Add-support-for-Kinetic-KTZ8866-backlight/20230118-214354 base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git for-backlight-next patch link: https://lore.kernel.org/r/20230118131002.15453-2-lujianhua000%40gmail.com patch subject: [PATCH v6 2/2] backlight: ktz8866: Add support for Kinetic KTZ8866 backlight config: parisc-randconfig-r031-20230119 (https://download.01.org/0day-ci/archive/20230120/202301200239.m4zdprwz-...@intel.com/config) compiler: hppa-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 # https://github.com/intel-lab-lkp/linux/commit/b862510e8bf9eb34db9d71a372b9de05682cb8ad git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Jianhua-Lu/backlight-ktz8866-Add-support-for-Kinetic-KTZ8866-backlight/20230118-214354 git checkout b862510e8bf9eb34db9d71a372b9de05682cb8ad # 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=parisc olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=parisc SHELL=/bin/bash drivers/video/backlight/ If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from include/linux/bits.h:6, from include/linux/ratelimit_types.h:5, from include/linux/ratelimit.h:5, from include/linux/dev_printk.h:16, from include/linux/device.h:15, from include/linux/backlight.h:12, from drivers/video/backlight/ktz8866.c:8: include/vdso/bits.h: In function 'ktz8866_init': >> include/vdso/bits.h:7:40: warning: 'val' is used uninitialized >> [-Wuninitialized] 7 | #define BIT(nr) (UL(1) << (nr)) |^~ drivers/video/backlight/ktz8866.c:98:22: note: 'val' was declared here 98 | unsigned int val; | ^~~ vim +/val +7 include/vdso/bits.h 3945ff37d2f48d Vincenzo Frascino 2020-03-20 6 3945ff37d2f48d Vincenzo Frascino 2020-03-20 @7 #define BIT(nr) (UL(1) << (nr)) 3945ff37d2f48d Vincenzo Frascino 2020-03-20 8 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
RE: [PATCH 2/3] drm/msm/disp/dpu1: allow dspp selection for all the interfaces
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Wednesday, January 18, 2023 9:06 AM
>To: Kalyan Thota ; Kalyan Thota (QUIC)
>; dri-devel@lists.freedesktop.org; linux-arm-
>m...@vger.kernel.org; freedr...@lists.freedesktop.org;
>devicet...@vger.kernel.org; Abhinav Kumar (QUIC)
>; Doug Anderson
>Cc: linux-ker...@vger.kernel.org; robdcl...@chromium.org;
>diand...@chromium.org; swb...@chromium.org; Vinod Polimera (QUIC)
>
>Subject: Re: [PATCH 2/3] drm/msm/disp/dpu1: allow dspp selection for all the
>interfaces
>
>WARNING: This email originated from outside of Qualcomm. Please be wary of
>any links or attachments, and do not enable macros.
>
>On 18/01/2023 05:30, Kalyan Thota wrote:
>>
>>
>>> -Original Message-
>>> From: Dmitry Baryshkov
>>> Sent: Tuesday, January 17, 2023 10:26 PM
>>> To: Kalyan Thota (QUIC) ; dri-
>>> de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>>> freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
>>> Cc: linux-ker...@vger.kernel.org; robdcl...@chromium.org;
>>> diand...@chromium.org; swb...@chromium.org; Vinod Polimera (QUIC)
>>> ; Abhinav Kumar (QUIC)
>>>
>>> Subject: Re: [PATCH 2/3] drm/msm/disp/dpu1: allow dspp selection for
>>> all the interfaces
>>>
>>> WARNING: This email originated from outside of Qualcomm. Please be
>>> wary of any links or attachments, and do not enable macros.
>>>
>>> On 17/01/2023 18:21, Kalyan Thota wrote:
Allow dspps to be populated as a requirement for all the encoder
types it need not be just DSI. If for any encoder the dspp
allocation doesn't go through then there can be an option to
fallback for color features.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 9c6817b..e39b345 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -545,7 +545,8 @@ bool dpu_encoder_use_dsc_merge(struct
drm_encoder
>>> *drm_enc)
static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode,
+ struct drm_crtc_state *crtc_state)
>>>
>>> Is this new argument used at all?
>>>
{
struct msm_display_topology topology = {0};
int i, intf_count = 0;
@@ -563,8 +564,9 @@ static struct msm_display_topology
>>> dpu_encoder_get_topology(
* 1 LM, 1 INTF
* 2 LM, 1 INTF (stream merge to support high resolution interfaces)
*
- * Adding color blocks only to primary interface if available in
- * sufficient number
+ * dspp blocks are made optional. If RM manager cannot allocate
+ * dspp blocks, then reservations will still go through with non
dspp LM's
+ * so as to allow color management support via composer
+ fallbacks
*/
>>>
>>> No, this is not the way to go.
>>>
>>> First, RM should prefer non-DSPP-enabled LMs if DSPP blocks are not
>>> required.
>>> Right now your patch makes it possible to allocate LMs, that have
>>> DSPP attached, for non-CTM-enabled encoder and later fail allocation
>>> of DSPP for the CRTC which has CTM blob attached.
>>>
>>> Second, the decision on using DSPPs should come from
>dpu_crtc_atomic_check().
>>> Pass 'bool need_dspp' to this function from dpu_atomic_check(). Fail
>>> if the need_dspp constraint can't be fulfilled.
>>>
>> We may not get color_mgmt_changed property set during modeset commit,
>where as our resource allocation happens during modeset.
>
>So, you have to fix the conditions to perform LM reallocation if CTM usage has
>changed (note, color_mgmt_changed is not a correct one here).
>
If I take the above approach, where should I update the new reservations as we
won't be getting atomic_mode_set callback as the change is only w.r.t color
management.
Sequence :
1) atomic_check on encoder
Received a request with no ctm enabled (1LM, 0dspp, 1 intf)
Rm will reserve 1LM and 1 intf
2) atomic_modeset on encoder
Update the state with reservations.
3) Commit with ctm enabled ( 1 LM, 1 dspp, 1 intf)
Here as the topology has changed, I need to re - reserve the resource
freeing the earlier ones.
But where should I update them to the state ? shall I do it as part of
atomic_check for this case ?
>> With this approach, dspps will get allocated on first come first serve
>> basis
>
>I don't think that this is what we have agreed upon.
>
>> @Rob, is it possible to send color management property during modeset, in
>that case, we
Re: [PATCH v11 0/3] drm: exynos: dsi: Restore the bridge chain
Hi Inki Dae, On Thu, Jan 12, 2023 at 7:56 AM 대인기/Tizen Platform Lab(SR)/삼성전자 wrote: > > Hi Jagan Teki, > > Sorry for late. > > > -Original Message- > > From: Jagan Teki > > Sent: Saturday, January 7, 2023 2:56 AM > > To: Marek Szyprowski ; Inki Dae > > ; Seung-Woo Kim ; Kyungmin > > Park > > ; Neil Armstrong ; Robert > > Foss ; Andrzej Hajda ; Sam > > Ravnborg > > Cc: Marek Vasut ; linux-samsung-...@vger.kernel.org; dri- > > de...@lists.freedesktop.org; linux-amarula > amar...@amarulasolutions.com> > > Subject: Re: [PATCH v11 0/3] drm: exynos: dsi: Restore the bridge chain > > > > On Mon, Dec 12, 2022 at 11:59 PM Jagan Teki > > wrote: > > > > > > Split the Exynos DSI bridge chain update patches from Samsung DSIM > > > bridge driver for easy to apply. > > > > > > Changes for v11: > > > - enable bridge.pre_enable_prev_first > > > Changes for v10: > > > - collect Marek.V Review tag > > > > Any update on this? > > > > Added Thierry Reding who is a maintainer of DRM panel drivers. > > I will pick this patch series - including panel and bride patches - up. > > Thierry and Andrzej, please let me know if any problem. Any further update on this? Thanks, Jagan.
[PATCH] drm/shmem: Cleanup drm_gem_shmem_create_with_handle()
From: Rob Clark Once we create the handle, the handle owns the reference. Currently nothing was doing anything with the shmem ptr after the handle was created, but let's change drm_gem_shmem_create_with_handle() to not return the pointer, so-as to not encourage problematic use of this function in the future. As a bonus, it makes the code a bit cleaner. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_gem_shmem_helper.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index f21f47737817..19406f4907df 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -415,7 +415,7 @@ void drm_gem_shmem_vunmap(struct drm_gem_shmem_object *shmem, } EXPORT_SYMBOL(drm_gem_shmem_vunmap); -static struct drm_gem_shmem_object * +static int drm_gem_shmem_create_with_handle(struct drm_file *file_priv, struct drm_device *dev, size_t size, uint32_t *handle) @@ -434,10 +434,8 @@ drm_gem_shmem_create_with_handle(struct drm_file *file_priv, ret = drm_gem_handle_create(file_priv, &shmem->base, handle); /* drop reference from allocate - handle holds it now. */ drm_gem_object_put(&shmem->base); - if (ret) - return ERR_PTR(ret); - return shmem; + return ret; } /* Update madvise status, returns true if not purged, else @@ -533,9 +531,7 @@ int drm_gem_shmem_dumb_create(struct drm_file *file, struct drm_device *dev, args->size = PAGE_ALIGN(args->pitch * args->height); } - shmem = drm_gem_shmem_create_with_handle(file, dev, args->size, &args->handle); - - return PTR_ERR_OR_ZERO(shmem); + return drm_gem_shmem_create_with_handle(file, dev, args->size, &args->handle); } EXPORT_SYMBOL_GPL(drm_gem_shmem_dumb_create); -- 2.38.1
Re: [PATCH v5 10/12] arm64: dts: qcom: sc8280xp: Define some of the display blocks
On Wed, Jan 18, 2023 at 04:58:26AM +0200, Dmitry Baryshkov wrote:
> On 08/12/2022 00:00, Bjorn Andersson wrote:
> > From: Bjorn Andersson
> >
> > Define the display clock controllers, the MDSS instances, the DP phys
> > and connect these together.
> >
> > Signed-off-by: Bjorn Andersson
> > Signed-off-by: Bjorn Andersson
> > ---
> >
> > Changes since v4:
> > - None
> >
> > arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 838 +
> > 1 file changed, 838 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > index 9f3132ac2857..c2f186495506 100644
> > --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > @@ -4,6 +4,7 @@
> >* Copyright (c) 2022, Linaro Limited
> >*/
> > +#include
> > #include
> > #include
> > #include
> > @@ -1698,6 +1699,44 @@ usb_1_qmpphy: phy@8903000 {
> > status = "disabled";
> > };
> > + mdss1_dp0_phy: phy@8909a00 {
> > + compatible = "qcom,sc8280xp-dp-phy";
> > + reg = <0 0x08909a00 0 0x19c>,
> > + <0 0x08909200 0 0xec>,
> > + <0 0x08909600 0 0xec>,
> > + <0 0x08909000 0 0x1c8>;
> > +
> > + clocks = <&dispcc1 DISP_CC_MDSS_DPTX0_AUX_CLK>,
> > +<&dispcc1 DISP_CC_MDSS_AHB_CLK>;
> > + clock-names = "aux", "cfg_ahb";
> > +
> > + power-domains = <&rpmhpd SC8280XP_MX>;
> > +
> > + #clock-cells = <1>;
> > + #phy-cells = <0>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + mdss1_dp1_phy: phy@890ca00 {
> > + compatible = "qcom,sc8280xp-dp-phy";
> > + reg = <0 0x0890ca00 0 0x19c>,
> > + <0 0x0890c200 0 0xec>,
> > + <0 0x0890c600 0 0xec>,
> > + <0 0x0890c000 0 0x1c8>;
> > +
> > + clocks = <&dispcc1 DISP_CC_MDSS_DPTX1_AUX_CLK>,
> > +<&dispcc1 DISP_CC_MDSS_AHB_CLK>;
> > + clock-names = "aux", "cfg_ahb";
> > +
> > + power-domains = <&rpmhpd SC8280XP_MX>;
> > +
> > + #clock-cells = <1>;
> > + #phy-cells = <0>;
> > +
> > + status = "disabled";
> > + };
> > +
> > system-cache-controller@920 {
> > compatible = "qcom,sc8280xp-llcc";
> > reg = <0 0x0920 0 0x58000>, <0 0x0960 0
> > 0x58000>;
> > @@ -1813,6 +1852,326 @@ usb_1_dwc3: usb@a80 {
> > };
> > };
> > + mdss0: display-subsystem@ae0 {
> > + compatible = "qcom,sc8280xp-mdss";
> > + reg = <0 0x0ae0 0 0x1000>;
> > + reg-names = "mdss";
> > +
> > + power-domains = <&dispcc0 MDSS_GDSC>;
> > +
> > + clocks = <&gcc GCC_DISP_AHB_CLK>,
> > +<&dispcc0 DISP_CC_MDSS_AHB_CLK>,
> > +<&dispcc0 DISP_CC_MDSS_MDP_CLK>;
> > + clock-names = "iface",
> > + "ahb",
> > + "core";
> > +
> > + resets = <&dispcc0 DISP_CC_MDSS_CORE_BCR>;
> > +
> > + interrupts = ;
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > +
> > + interconnects = <&mmss_noc MASTER_MDP0 0 &mc_virt
> > SLAVE_EBI1 0>,
> > + <&mmss_noc MASTER_MDP1 0 &mc_virt
> > SLAVE_EBI1 0>;
> > + interconnect-names = "mdp0-mem", "mdp1-mem";
> > +
> > + iommus = <&apps_smmu 0x1000 0x402>;
> > +
> > + status = "disabled";
> > +
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + mdss0_mdp: display-controller@ae01000 {
> > + compatible = "qcom,sc8280xp-dpu";
> > + reg = <0 0x0ae01000 0 0x8f000>,
> > + <0 0x0aeb 0 0x2008>;
> > + reg-names = "mdp", "vbif";
> > +
> > + clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
> > +<&gcc GCC_DISP_SF_AXI_CLK>,
> > +<&dispcc0 DISP_CC_MDSS_AHB_CLK>,
> > +<&dispcc0 DISP_CC_MDSS_MDP_LUT_CLK>,
> > +<&dispcc0 DISP_CC_MDSS_MDP_CLK>,
> > +<&dispcc0 DISP_CC_MDSS_VSYNC_CLK>;
> > + clock-names = "bus",
> > +
Re: [PATCH v10 00/18] drm: Add Samsung MIPI DSIM bridge
Hi Fabio, On Thu, Jan 19, 2023 at 10:57 PM Fabio Estevam wrote: > > Hi Jagan, > > On Thu, Jan 5, 2023 at 7:24 AM Jagan Teki wrote: > > > Does anyone have any other comments on this? I would like to send v11 > > with a few nits on v10. Please let me know. > > What is blocking this series to be applied? There are two patch series prior to this need to apply. https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-ja...@amarulasolutions.com/ https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-ja...@amarulasolutions.com/ Regarding this series, the patch 09/18 commit message has "FIXME" this need to remove. https://patchwork.kernel.org/project/dri-devel/patch/20221214125907.376148-10-ja...@amarulasolutions.com/ I think it is possible to remove it while applying otherwise I will resend this patch alone or in series again. Jagan.
