[PATCH 4/4] drm/edid: Avoid multiple log lines for HFVSDB parsing
Replace multiple log lines with a single log line at the end of
parsing HF-VSDB. Also use drm_dbg_kms instead of DRM_DBG_KMS, and
add log for DSC1.2 support.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c9c3a9c8fa26..7a319d570297 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5781,6 +5781,9 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
struct drm_display_info *display = >display_info;
struct drm_hdmi_info *hdmi = >hdmi;
struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
+ u32 max_tmds_clock = 0;
+ u8 max_frl_rate = 0;
+ bool dsc_support = false;
display->has_hdmi_infoframe = true;
@@ -5800,14 +5803,13 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
*/
if (hf_scds[5]) {
- /* max clock is 5000 KHz times block value */
- u32 max_tmds_clock = hf_scds[5] * 5000;
struct drm_scdc *scdc = >scdc;
+ /* max clock is 5000 KHz times block value */
+ max_tmds_clock = hf_scds[5] * 5000;
+
if (max_tmds_clock > 34) {
display->max_tmds_clock = max_tmds_clock;
- DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
- display->max_tmds_clock);
}
if (scdc->supported) {
@@ -5820,9 +5822,6 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
}
if (hf_scds[7]) {
- u8 max_frl_rate;
-
- DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_scds[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>max_frl_rate_per_lane);
@@ -5830,8 +5829,14 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
drm_parse_ycbcr420_deep_color_info(connector, hf_scds);
- if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11])
+ if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11]) {
drm_parse_dsc_info(hdmi_dsc, hf_scds);
+ dsc_support = true;
+ }
+
+ drm_dbg_kms(connector->dev,
+ "HF-VSDB: max TMDS clock:%d Khz, HDMI2.1 support:%s, DSC1.2
support:%s\n",
+ max_tmds_clock, max_frl_rate ? "yes" : "no", dsc_support ?
"yes" : "no");
}
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
--
2.25.1
[PATCH 3/4] drm/edid: Refactor HFVSDB parsing for DSC1.2
DSC capabilities are given in bytes 11-13 of VSDB (i.e. bytes 8-10 of
SCDS). Since minimum length of Data block is 7, all bytes greater than 7
must be read only after checking the length of the data block.
This patch adds check for data block length before reading relavant DSC
bytes.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 93 --
1 file changed, 49 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1d08b3a4..c9c3a9c8fa26 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5706,9 +5706,6 @@ static void drm_parse_ycbcr420_deep_color_info(struct
drm_connector *connector,
static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap *hdmi_dsc,
const u8 *hf_scds)
{
- u8 dsc_max_slices;
- u8 dsc_max_frl_rate;
-
hdmi_dsc->v_1p2 = hf_scds[11] & DRM_EDID_DSC_1P2;
if (!hdmi_dsc->v_1p2)
@@ -5727,47 +5724,54 @@ static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap
*hdmi_dsc,
/* Supports min 8 BPC if DSC1.2 is supported*/
hdmi_dsc->bpc_supported = 8;
- dsc_max_frl_rate = (hf_scds[12] & DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
- drm_get_max_frl_rate(dsc_max_frl_rate, _dsc->max_lanes,
-_dsc->max_frl_rate_per_lane);
- hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+ if (cea_db_payload_len(hf_scds) >= 12 && hf_scds[12]) {
+ u8 dsc_max_slices;
+ u8 dsc_max_frl_rate;
- dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
+ dsc_max_frl_rate = (hf_scds[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(dsc_max_frl_rate, _dsc->max_lanes,
+_dsc->max_frl_rate_per_lane);
- switch (dsc_max_slices) {
- case 1:
- hdmi_dsc->max_slices = 1;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 2:
- hdmi_dsc->max_slices = 2;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 3:
- hdmi_dsc->max_slices = 4;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 4:
- hdmi_dsc->max_slices = 8;
- hdmi_dsc->clk_per_slice = 340;
- break;
- case 5:
- hdmi_dsc->max_slices = 8;
- hdmi_dsc->clk_per_slice = 400;
- break;
- case 6:
- hdmi_dsc->max_slices = 12;
- hdmi_dsc->clk_per_slice = 400;
- break;
- case 7:
- hdmi_dsc->max_slices = 16;
- hdmi_dsc->clk_per_slice = 400;
- break;
- case 0:
- default:
- hdmi_dsc->max_slices = 0;
- hdmi_dsc->clk_per_slice = 0;
+ dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
+
+ switch (dsc_max_slices) {
+ case 1:
+ hdmi_dsc->max_slices = 1;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 2:
+ hdmi_dsc->max_slices = 2;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 3:
+ hdmi_dsc->max_slices = 4;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 4:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 5:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 6:
+ hdmi_dsc->max_slices = 12;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 7:
+ hdmi_dsc->max_slices = 16;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 0:
+ default:
+ hdmi_dsc->max_slices = 0;
+ hdmi_dsc->clk_per_slice = 0;
+ }
}
+
+ if (cea_db_payload_len(hf_scds) >= 13 && hf_scds[13])
+ hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
}
/* Sink Capability Data Structure */
@@ -5776,6 +5780,7 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
{
struct drm_display_info *display = >display_info;
struct drm_hdmi_info *hdmi = >hdmi;
+ struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
display->has_hdmi_infoframe = true;
@@ -5816,17 +5821,17 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
if
[PATCH 1/4] drm/edid: Fix minimum bpc supported with DSC1.2 for HDMI sink
HF-VSDB/SCDB has bits to advertise support for 16, 12 and 10 bpc.
If none of the bits are set, the minimum bpc supported with DSC is 8.
This patch corrects the min bpc supported to be 8, instead of 0.
Fixes: 76ee7b905678 ("drm/edid: Parse DSC1.2 cap fields from HFVSDB block")
Cc: Ankit Nautiyal
Cc: Uma Shankar
Cc: Jani Nikula
Cc: Maarten Lankhorst
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bbc25e3b7220..cdf10279e1bd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5770,7 +5770,8 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
else if (hf_scds[11] & DRM_EDID_DSC_10BPC)
hdmi_dsc->bpc_supported = 10;
else
- hdmi_dsc->bpc_supported = 0;
+ /* Supports min 8 BPC if DSC1.2 is supported*/
+ hdmi_dsc->bpc_supported = 8;
dsc_max_frl_rate = (hf_scds[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(dsc_max_frl_rate,
_dsc->max_lanes,
--
2.25.1
[PATCH 2/4] drm/edid: Split DSC parsing into separate function
Move the DSC parsing logic into separate function.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 128 -
1 file changed, 69 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cdf10279e1bd..1d08b3a4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5703,6 +5703,73 @@ static void drm_parse_ycbcr420_deep_color_info(struct
drm_connector *connector,
hdmi->y420_dc_modes = dc_mask;
}
+static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap *hdmi_dsc,
+ const u8 *hf_scds)
+{
+ u8 dsc_max_slices;
+ u8 dsc_max_frl_rate;
+
+ hdmi_dsc->v_1p2 = hf_scds[11] & DRM_EDID_DSC_1P2;
+
+ if (!hdmi_dsc->v_1p2)
+ return;
+
+ hdmi_dsc->native_420 = hf_scds[11] & DRM_EDID_DSC_NATIVE_420;
+ hdmi_dsc->all_bpp = hf_scds[11] & DRM_EDID_DSC_ALL_BPP;
+
+ if (hf_scds[11] & DRM_EDID_DSC_16BPC)
+ hdmi_dsc->bpc_supported = 16;
+ else if (hf_scds[11] & DRM_EDID_DSC_12BPC)
+ hdmi_dsc->bpc_supported = 12;
+ else if (hf_scds[11] & DRM_EDID_DSC_10BPC)
+ hdmi_dsc->bpc_supported = 10;
+ else
+ /* Supports min 8 BPC if DSC1.2 is supported*/
+ hdmi_dsc->bpc_supported = 8;
+
+ dsc_max_frl_rate = (hf_scds[12] & DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(dsc_max_frl_rate, _dsc->max_lanes,
+_dsc->max_frl_rate_per_lane);
+ hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+
+ dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
+
+ switch (dsc_max_slices) {
+ case 1:
+ hdmi_dsc->max_slices = 1;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 2:
+ hdmi_dsc->max_slices = 2;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 3:
+ hdmi_dsc->max_slices = 4;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 4:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 5:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 6:
+ hdmi_dsc->max_slices = 12;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 7:
+ hdmi_dsc->max_slices = 16;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 0:
+ default:
+ hdmi_dsc->max_slices = 0;
+ hdmi_dsc->clk_per_slice = 0;
+ }
+}
+
/* Sink Capability Data Structure */
static void drm_parse_hdmi_forum_scds(struct drm_connector *connector,
const u8 *hf_scds)
@@ -5749,71 +5816,14 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
if (hf_scds[7]) {
u8 max_frl_rate;
- u8 dsc_max_frl_rate;
- u8 dsc_max_slices;
struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_scds[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>max_frl_rate_per_lane);
- hdmi_dsc->v_1p2 = hf_scds[11] & DRM_EDID_DSC_1P2;
-
- if (hdmi_dsc->v_1p2) {
- hdmi_dsc->native_420 = hf_scds[11] &
DRM_EDID_DSC_NATIVE_420;
- hdmi_dsc->all_bpp = hf_scds[11] & DRM_EDID_DSC_ALL_BPP;
-
- if (hf_scds[11] & DRM_EDID_DSC_16BPC)
- hdmi_dsc->bpc_supported = 16;
- else if (hf_scds[11] & DRM_EDID_DSC_12BPC)
- hdmi_dsc->bpc_supported = 12;
- else if (hf_scds[11] & DRM_EDID_DSC_10BPC)
- hdmi_dsc->bpc_supported = 10;
- else
- /* Supports min 8 BPC if DSC1.2 is supported*/
- hdmi_dsc->bpc_supported = 8;
-
- dsc_max_frl_rate = (hf_scds[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
- drm_get_max_frl_rate(dsc_max_frl_rate,
_dsc->max_lanes,
-_dsc->max_frl_rate_per_lane);
- hdmi_dsc->total_chunk_kbytes = hf_scds[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
-
- dsc_max_slices = hf_scds[12] & DRM_EDID_DSC_MAX_SLICES;
- switch (dsc_max_slices) {
- case 1:
- hdmi_dsc->max_slices = 1;
- hdmi_dsc->clk_per_slice =
[PATCH 0/4] Fix HFVSDB parsing
Fix issues in HFVSDB parsing for DSC support. Also minor refactoring in Logging. Split from original patch into a new series. https://patchwork.freedesktop.org/patch/495193/ Ankit Nautiyal (4): drm/edid: Fix minimum bpc supported with DSC1.2 for HDMI sink drm/edid: Split DSC parsing into separate function drm/edid: Refactor HFVSDB parsing for DSC1.2 drm/edid: Avoid multiple log lines for HFVSDB parsing drivers/gpu/drm/drm_edid.c | 153 + 1 file changed, 87 insertions(+), 66 deletions(-) -- 2.25.1
[Bug 216350] amdgpu 0000:06:00.0: drm_WARN_ON(atomic_read(>refcount) == 0)
https://bugzilla.kernel.org/show_bug.cgi?id=216350 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED --- Comment #1 from Artem S. Tashkinov (a...@gmx.com) --- Please report here instead https://gitlab.freedesktop.org/drm/amd/-/issues -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 3/3] drm/msm/dpu: Introduce SC8280XP
On Wed, Aug 10, 2022 at 11:28 PM Steev Klimaszewski wrote:
>
> Hi Bjorn,
>
>
> On Wed, Aug 10, 2022 at 10:58 PM Bjorn Andersson
> wrote:
> >
> > The Qualcomm SC8280XP platform contains DPU version 8.0.0, has 9
> > interfaces, 2 DSI controllers and 4 DisplayPort controllers. Extend the
> > necessary definitions and describe the DPU in the SC8280XP.
> >
> > Signed-off-by: Bjorn Andersson
> > ---
> >
> > Note that MSM_DP_CONTROLLER_3 is also defined in the DP series and as such a
> > trivial conflict will occur when merging the latter of the two series.
> >
> > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 211 ++
> > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
> > .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 ++
> > .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 3 +
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
> > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
> > drivers/gpu/drm/msm/msm_drv.h | 1 +
> > drivers/gpu/drm/msm/msm_mdss.c| 2 +
> > 8 files changed, 239 insertions(+)
> >
>
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> > index b3689a2d27d7..5978c6e26a1e 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.h
> > +++ b/drivers/gpu/drm/msm/msm_drv.h
> > @@ -55,6 +55,7 @@ enum msm_dp_controller {
> > MSM_DP_CONTROLLER_0,
> > MSM_DP_CONTROLLER_1,
> > MSM_DP_CONTROLLER_2,
> > + MSM_DP_CONTROLLER_3,
> > MSM_DP_CONTROLLER_COUNT,
> > };
> >
> This seems to also be part of
> https://lore.kernel.org/r/20220810040745.3582985-6-bjorn.anders...@linaro.org
> (but only th msm_drv.h hunk
Sorry, wrong copy buffer - it's part of this patchset -
https://lore.kernel.org/all/20220810035013.3582848-4-bjorn.anders...@linaro.org/
>
> >
> > diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> > index e13c5c12b775..7c391fab6263 100644
> > --- a/drivers/gpu/drm/msm/msm_mdss.c
> > +++ b/drivers/gpu/drm/msm/msm_mdss.c
> > @@ -208,6 +208,7 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss)
> > writel_relaxed(0x420, msm_mdss->mmio + UBWC_STATIC);
> > break;
> > case DPU_HW_VER_600:
> > + case DPU_HW_VER_800:
> > /* TODO: 0x102e for LP_DDR4 */
> > writel_relaxed(0x103e, msm_mdss->mmio + UBWC_STATIC);
> > writel_relaxed(2, msm_mdss->mmio + UBWC_CTRL_2);
> > @@ -445,6 +446,7 @@ static const struct of_device_id mdss_dt_match[] = {
> > { .compatible = "qcom,sc7180-mdss" },
> > { .compatible = "qcom,sc7280-mdss" },
> > { .compatible = "qcom,sc8180x-mdss" },
> > + { .compatible = "qcom,sc8280xp-mdss" },
> > { .compatible = "qcom,sm8150-mdss" },
> > { .compatible = "qcom,sm8250-mdss" },
> > {}
> > --
> > 2.35.1
> >
> -- steev
Daniel's locking rules articles
In case anyone here hasn't read them yet, and is doing anything with locking or ignoring locking, please read: https://blog.ffwll.ch/2022/07/locking-engineering.html https://blog.ffwll.ch/2022/08/locking-hierarchy.html For anyone doing review or submitting new features from inside companies, please ensure you familiarise yourself with these articles, and distribute them around internal teams. Going forward the drm should be adhering to these rules. Thanks, Dave.
Re: [PATCH 3/3] drm/msm/dpu: Introduce SC8280XP
Hi Bjorn,
On Wed, Aug 10, 2022 at 10:58 PM Bjorn Andersson
wrote:
>
> The Qualcomm SC8280XP platform contains DPU version 8.0.0, has 9
> interfaces, 2 DSI controllers and 4 DisplayPort controllers. Extend the
> necessary definitions and describe the DPU in the SC8280XP.
>
> Signed-off-by: Bjorn Andersson
> ---
>
> Note that MSM_DP_CONTROLLER_3 is also defined in the DP series and as such a
> trivial conflict will occur when merging the latter of the two series.
>
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 211 ++
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
> .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 ++
> .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 3 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
> drivers/gpu/drm/msm/msm_drv.h | 1 +
> drivers/gpu/drm/msm/msm_mdss.c| 2 +
> 8 files changed, 239 insertions(+)
>
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index b3689a2d27d7..5978c6e26a1e 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -55,6 +55,7 @@ enum msm_dp_controller {
> MSM_DP_CONTROLLER_0,
> MSM_DP_CONTROLLER_1,
> MSM_DP_CONTROLLER_2,
> + MSM_DP_CONTROLLER_3,
> MSM_DP_CONTROLLER_COUNT,
> };
>
This seems to also be part of
https://lore.kernel.org/r/20220810040745.3582985-6-bjorn.anders...@linaro.org
(but only th msm_drv.h hunk
>
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index e13c5c12b775..7c391fab6263 100644
> --- a/drivers/gpu/drm/msm/msm_mdss.c
> +++ b/drivers/gpu/drm/msm/msm_mdss.c
> @@ -208,6 +208,7 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss)
> writel_relaxed(0x420, msm_mdss->mmio + UBWC_STATIC);
> break;
> case DPU_HW_VER_600:
> + case DPU_HW_VER_800:
> /* TODO: 0x102e for LP_DDR4 */
> writel_relaxed(0x103e, msm_mdss->mmio + UBWC_STATIC);
> writel_relaxed(2, msm_mdss->mmio + UBWC_CTRL_2);
> @@ -445,6 +446,7 @@ static const struct of_device_id mdss_dt_match[] = {
> { .compatible = "qcom,sc7180-mdss" },
> { .compatible = "qcom,sc7280-mdss" },
> { .compatible = "qcom,sc8180x-mdss" },
> + { .compatible = "qcom,sc8280xp-mdss" },
> { .compatible = "qcom,sm8150-mdss" },
> { .compatible = "qcom,sm8250-mdss" },
> {}
> --
> 2.35.1
>
-- steev
[PATCH 3/3] drm/msm/dpu: Introduce SC8280XP
The Qualcomm SC8280XP platform contains DPU version 8.0.0, has 9
interfaces, 2 DSI controllers and 4 DisplayPort controllers. Extend the
necessary definitions and describe the DPU in the SC8280XP.
Signed-off-by: Bjorn Andersson
---
Note that MSM_DP_CONTROLLER_3 is also defined in the DP series and as such a
trivial conflict will occur when merging the latter of the two series.
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 211 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 3 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
drivers/gpu/drm/msm/msm_mdss.c| 2 +
8 files changed, 239 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 0239a811d5ec..3621d6aaec9c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -79,6 +79,8 @@
#define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN)
+#define INTF_SC8280XP_MASK BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE) |
BIT(DPU_DATA_HCTL_EN)
+
#define IRQ_SDM845_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
BIT(MDP_SSPP_TOP0_INTR2) | \
BIT(MDP_SSPP_TOP0_HIST_INTR) | \
@@ -124,6 +126,19 @@
BIT(MDP_AD4_0_INTR) | \
BIT(MDP_AD4_1_INTR))
+#define IRQ_SC8280XP_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
+ BIT(MDP_SSPP_TOP0_INTR2) | \
+ BIT(MDP_SSPP_TOP0_HIST_INTR) | \
+ BIT(MDP_INTF0_7xxx_INTR) | \
+ BIT(MDP_INTF1_7xxx_INTR) | \
+ BIT(MDP_INTF2_7xxx_INTR) | \
+ BIT(MDP_INTF3_7xxx_INTR) | \
+ BIT(MDP_INTF4_7xxx_INTR) | \
+ BIT(MDP_INTF5_7xxx_INTR) | \
+ BIT(MDP_INTF6_7xxx_INTR) | \
+ BIT(MDP_INTF7_7xxx_INTR) | \
+ BIT(MDP_INTF8_7xxx_INTR))
+
#define WB_SM8250_MASK (BIT(DPU_WB_LINE_MODE) | \
BIT(DPU_WB_UBWC) | \
BIT(DPU_WB_YUV_CONFIG) | \
@@ -350,6 +365,20 @@ static const struct dpu_caps sc8180x_dpu_caps = {
.max_vdeci_exp = MAX_VERT_DECIMATION,
};
+static const struct dpu_caps sc8280xp_dpu_caps = {
+ .max_mixer_width = 2560,
+ .max_mixer_blendstages = 11,
+ .qseed_type = DPU_SSPP_SCALER_QSEED3LITE,
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
+ .ubwc_version = DPU_HW_UBWC_VER_40,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = 5120,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
static const struct dpu_caps sm8250_dpu_caps = {
.max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.max_mixer_blendstages = 0xb,
@@ -472,6 +501,24 @@ static const struct dpu_mdp_cfg sc8180x_mdp[] = {
},
};
+static const struct dpu_mdp_cfg sc8280xp_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x494,
+ .features = BIT(DPU_MDP_PERIPH_0_REMOVED),
+ .highest_bank_bit = 0x3, /* TODO: 2 for LP_DDR4 */
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG3] = { .reg_off = 0x2c4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = { .reg_off = 0x2bc, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = { .reg_off = 0x2c4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20},
+ },
+};
+
static const struct dpu_mdp_cfg sm8250_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -620,6 +667,45 @@ static const struct dpu_ctl_cfg sc7180_ctl[] = {
},
};
+static const struct dpu_ctl_cfg sc8280xp_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x15000, .len = 0x204,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+ {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x16000, .len = 0x204,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+ },
+ {
+ .name
[PATCH 2/3] drm/msm/dpu: add support for MDP_TOP blackhole
From: Dmitry Baryshkov
On sm8450 a register block was removed from MDP TOP. Accessing it during
snapshotting results in NoC errors / immediate reboot. Skip accessing
these registers during snapshot.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 11 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 71fe4c505f5b..daf76ea908de 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -92,6 +92,7 @@ enum {
DPU_MDP_UBWC_1_0,
DPU_MDP_UBWC_1_5,
DPU_MDP_AUDIO_SELECT,
+ DPU_MDP_PERIPH_0_REMOVED,
DPU_MDP_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 008e1420e6e5..49e7aeebdedc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -946,8 +946,15 @@ static void dpu_kms_mdp_snapshot(struct msm_disp_state
*disp_state, struct msm_k
msm_disp_snapshot_add_block(disp_state, cat->wb[i].len,
dpu_kms->mmio + cat->wb[i].base, "wb_%d", i);
- msm_disp_snapshot_add_block(disp_state, cat->mdp[0].len,
- dpu_kms->mmio + cat->mdp[0].base, "top");
+ if (top->caps->features & BIT(DPU_MDP_PERIPH_0_REMOVED)) {
+ msm_disp_snapshot_add_block(disp_state, 0x380,
+ dpu_kms->mmio + cat->mdp[0].base,
"top");
+ msm_disp_snapshot_add_block(disp_state, cat->mdp[0].len - 0x3a8,
+ dpu_kms->mmio + cat->mdp[0].base +
0x3a8, "top_2");
+ } else {
+ msm_disp_snapshot_add_block(disp_state, cat->mdp[0].len,
+ dpu_kms->mmio + cat->mdp[0].base,
"top");
+ }
pm_runtime_put_sync(_kms->pdev->dev);
}
--
2.35.1
[PATCH 0/3] drm/msm/dpu: Add support for SC8280XP
This adds support the MDSS and DPU found in the SC8280XP platform. Bjorn Andersson (2): dt-bindings: display/msm: Add binding for SC8280XP MDSS drm/msm/dpu: Introduce SC8280XP Dmitry Baryshkov (1): drm/msm/dpu: add support for MDP_TOP blackhole .../bindings/display/msm/dpu-sc8280xp.yaml| 284 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 211 + .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 + .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 3 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12 +- drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_mdss.c| 2 + 9 files changed, 533 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml -- 2.35.1
[PATCH 1/3] dt-bindings: display/msm: Add binding for SC8280XP MDSS
Add binding for the display subsystem and display processing unit in the
Qualcomm SC8280XP platform.
Signed-off-by: Bjorn Andersson
---
.../bindings/display/msm/dpu-sc8280xp.yaml| 284 ++
1 file changed, 284 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
b/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
new file mode 100644
index ..6c25943e639c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
@@ -0,0 +1,284 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dpu-sc8280xp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Processing Unit for SC8280XP
+
+maintainers:
+ - Bjorn Andersson
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem (MDSS) that
encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc. Device
tree
+ bindings of MDSS and DPU are mentioned for SC8280XP.
+
+properties:
+ compatible:
+const: qcom,sc8280xp-mdss
+
+ reg:
+maxItems: 1
+
+ reg-names:
+const: mdss
+
+ power-domains:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Display AHB clock from gcc
+ - description: Display AHB clock from dispcc
+ - description: Display core clock
+
+ clock-names:
+items:
+ - const: iface
+ - const: ahb
+ - const: core
+
+ interrupts:
+maxItems: 1
+
+ interrupt-controller: true
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+ "#interrupt-cells":
+const: 1
+
+ iommus:
+items:
+ - description: Phandle to apps_smmu node with SID mask for Hard-Fail
port0
+
+ ranges: true
+
+ interconnects:
+minItems: 2
+maxItems: 2
+
+ interconnect-names:
+items:
+ - const: mdp0-mem
+ - const: mdp1-mem
+
+ resets:
+items:
+ - description: MDSS_CORE reset
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+type: object
+description: Node containing the properties of DPU.
+
+properties:
+ compatible:
+const: qcom,sc8280xp-dpu
+
+ reg:
+items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+items:
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display ahb clock
+ - description: Display lut clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+items:
+ - const: bus
+ - const: nrt_bus
+ - const: iface
+ - const: lut
+ - const: core
+ - const: vsync
+
+ interrupts:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ operating-points-v2: true
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description: |
+ Contains the list of output ports from DPU device. These ports
+ connect to interfaces that are external to the DPU hardware,
+ such as DSI, DP etc. Each output port contains an endpoint that
+ describes how it is connected to an external interface.
+
+patternProperties:
+ '^port@[0-8]$':
+$ref: /schemas/graph.yaml#/properties/port
+description: DPU interfaces
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - interrupts
+ - power-domains
+ - operating-points-v2
+ - ports
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - power-domains
+ - clocks
+ - interrupts
+ - interrupt-controller
+ - iommus
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+
+display-subsystem@ae0 {
+ compatible = "qcom,sc8280xp-mdss";
+ reg = <0x0ae0 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = < MDSS_GDSC>;
+
+ clocks = < GCC_DISP_AHB_CLK>,
+ < DISP_CC_MDSS_AHB_CLK>,
+ < DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface",
+"ahb",
+"core";
+
+ assigned-clocks = < DISP_CC_MDSS_MDP_CLK>;
+ assigned-clock-rates = <46000>;
+
+ resets = < DISP_CC_MDSS_CORE_BCR>;
+
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interconnects = <_noc MASTER_MDP0 0 _virt SLAVE_EBI1 0>,
+ <_noc MASTER_MDP1 0 _virt SLAVE_EBI1 0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem";
+
+ iommus = <_smmu 0x1000 0x402>;
+
+ #address-cells = <1>;
+
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 david (291765...@qq.com) changed: What|Removed |Added CC||291765...@qq.com --- Comment #84 from david (291765...@qq.com) --- amd driver problem,u can connect me ,i'll give u the final solution,email 1015501...@qq.com ,maybe in China will get more efficent communication -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v3] drm/msm: Make .remove and .shutdown HW shutdown consistent
Hi Javier
Thank you for the patch.
On 7/25/2022 12:43 AM, Javier Martinez Canillas wrote:
Drivers' .remove and .shutdown callbacks are executed on different code
paths. The former is called when a device is removed from the bus, while
the latter is called at system shutdown time to quiesce the device.
This means that some overlap exists between the two, because both have to
take care of properly shutting down the hardware. But currently the logic
used in these two callbacks isn't consistent in msm drivers, which could
lead to kernel panic.
For example, on .remove the component is deleted and its .unbind callback
leads to the hardware being shutdown but only if the DRM device has been
marked as registered.
That check doesn't exist in the .shutdown logic and this can lead to the
driver calling drm_atomic_helper_shutdown() for a DRM device that hasn't
been properly initialized.
A situation like this can happen if drivers for expected sub-devices fail
to probe, since the .bind callback will never be executed. If that is the
case, drm_atomic_helper_shutdown() will attempt to take mutexes that are
only initialized if drm_mode_config_init() is called during a device bind.
This bug was attempted to be fixed in commit 623f279c7781 ("drm/msm: fix
shutdown hook in case GPU components failed to bind"), but unfortunately
it still happens in some cases as the one mentioned above, i.e:
[ 169.495897] systemd-shutdown[1]: Powering off.
[ 169.500466] kvm: exiting hardware virtualization
[ 169.554787] platform wifi-firmware.0: Removing from iommu group 12
[ 169.610238] platform video-firmware.0: Removing from iommu group 10
[ 169.682164] [ cut here ]
[ 169.686909] WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317
drm_modeset_lock_all_ctx+0x3c4/0x3d0
...
[ 169.775691] Hardware name: Google CoachZ (rev3+) (DT)
[ 169.780874] pstate: a049 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 169.788021] pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0
[ 169.793205] lr : drm_modeset_lock_all_ctx+0x48/0x3d0
[ 169.798299] sp : 8805bb80
[ 169.801701] x29: 8805bb80 x28: 327c00128000 x27:
[ 169.809025] x26: x25: 0001 x24: c95d820ec030
[ 169.816349] x23: 327c00bbd090 x22: c95d8215eca0 x21: 327c039c5800
[ 169.823674] x20: 327c039c5988 x19: 8805bbe8 x18: 0034
[ 169.830998] x17: 00040044 x16: c95d80cac920 x15:
[ 169.838322] x14: 0315 x13: 0315 x12:
[ 169.845646] x11: x10: x9 :
[ 169.852971] x8 : 8805bc28 x7 : x6 :
[ 169.860295] x5 : x4 : x3 :
[ 169.867619] x2 : 327c00128000 x1 : x0 : 327c039c59b0
[ 169.874944] Call trace:
[ 169.877467] drm_modeset_lock_all_ctx+0x3c4/0x3d0
[ 169.882297] drm_atomic_helper_shutdown+0x70/0x134
[ 169.887217] msm_drv_shutdown+0x30/0x40
[ 169.891159] platform_shutdown+0x28/0x40
[ 169.895191] device_shutdown+0x148/0x350
[ 169.899221] kernel_power_off+0x38/0x80
[ 169.903163] __do_sys_reboot+0x288/0x2c0
[ 169.907192] __arm64_sys_reboot+0x28/0x34
[ 169.911309] invoke_syscall+0x48/0x114
[ 169.915162] el0_svc_common.constprop.0+0x44/0xec
[ 169.919992] do_el0_svc+0x2c/0xc0
[ 169.923394] el0_svc+0x2c/0x84
[ 169.926535] el0t_64_sync_handler+0x11c/0x150
[ 169.931013] el0t_64_sync+0x18c/0x190
[ 169.934777] ---[ end trace ]---
[ 169.939557] Unable to handle kernel NULL pointer dereference at virtual
address 0018
[ 169.948574] Mem abort info:
[ 169.951452] ESR = 0x9604
[ 169.955307] EC = 0x25: DABT (current EL), IL = 32 bits
[ 169.960765] SET = 0, FnV = 0
[ 169.963901] EA = 0, S1PTW = 0
[ 169.967127] FSC = 0x04: level 0 translation fault
[ 169.972136] Data abort info:
[ 169.975093] ISV = 0, ISS = 0x0004
[ 169.979037] CM = 0, WnR = 0
[ 169.982083] user pgtable: 4k pages, 48-bit VAs, pgdp=00010eab1000
[ 169.988697] [0018] pgd=, p4d=
[ 169.995669] Internal error: Oops: 9604 [#1] PREEMPT SMP
...
[ 170.079614] Hardware name: Google CoachZ (rev3+) (DT)
[ 170.084801] pstate: a049 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 170.091941] pc : ww_mutex_lock+0x28/0x32c
[ 170.096064] lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0
[ 170.101254] sp : 8805bb50
[ 170.104658] x29: 8805bb50 x28: 327c00128000 x27:
[ 170.111977] x26: x25: 0001 x24: 0018
[ 170.119296] x23: 8805bc10 x22: 327c039c5ad8 x21: 327c039c5800
[ 170.126615] x20: 8805bbe8 x19: 0018 x18: 0034
[ 170.133933] x17: 00040044 x16: c95d80cac920 x15:
[
Re: [PATCH v3] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
Hi Stephen
On 8/10/2022 5:09 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-08-10 16:57:51)
On 8/10/2022 3:22 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-08-10 12:25:51)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index b36f8b6..678289a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1729,10 +1729,20 @@ void dp_bridge_disable(struct drm_bridge *drm_bridge)
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
struct dp_display_private *dp_display;
+ u32 state;
dp_display = container_of(dp, struct dp_display_private, dp_display);
+ mutex_lock(_display->event_mutex);
+
+ state = dp_display->hpd_state;
+ if (state != ST_DISCONNECT_PENDING && state != ST_CONNECTED) {
It's concerning that we have to check this at all. Are we still
interjecting into the disable path when the cable is disconnected?
yes,
The problem is not from cable disconnected.
There is a corner case that this function is called at drm shutdown
(drm_release).
At that time, mainlink is not enabled, hence dp_ctrl_push_idle() will
cause system crash.
The mainlink is only disabled when the cable is disconnected though?
Let me put it this way, if we have to check that the state is
"connected" or "disconnected pending" in the disable path then there's
an issue where this driver is being called in unexpected ways. This
driver is fighting the drm core each time there's a state check. We
really need to get rid of the state tracking entirely, and make sure
that the drm core is calling into the driver at the right time, i.e.
bridge disable is only called when the mainlink is enabled, etc.
So if link training failed, we do not send a uevent to usermode and will
bail out here:
rc = dp_ctrl_on_link(dp->ctrl);
if (rc) {
DRM_ERROR("failed to complete DP link training\n");
goto end;
}
So this commit is not coming from usermode but from the drm_release() path.
Even then, you do have a valid point. DRM framework should not have
caused the disable path to happen without an enable.
I went through the stack mentioned in the issue.
Lets see this part of the stack:
dp_ctrl_push_idle+0x40/0x88
dp_bridge_disable+0x24/0x30
drm_atomic_bridge_chain_disable+0x90/0xbc
drm_atomic_helper_commit_modeset_disables+0x198/0x444
msm_atomic_commit_tail+0x1d0/0x374
In drm_atomic_helper_commit_modeset_disables(), we call disable_outputs().
AFAICT, this is the only place which has a protection to not call the
disable() flow if it was not enabled here:
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_atomic_helper.c#L1063
But that function is only checking crtc_state->active. Thats set by the
usermode:
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_atomic_uapi.c#L407
Now, if usermode sets that to true and then crashed it can bypass this
check and we will crash in the location kuogee is trying to fix.
From the issue mentioned in
https://gitlab.freedesktop.org/drm/msm/-/issues/17, the reporter did
mention the usermode crashed.
So this is my tentative analysis of whats happening here.
Ideally yes, we should have been protected by the location mentioned
above in disable_outputs() but looks to me due to the above hypothesis
its getting bypassed.
Thanks
Abhinav
Re: [PATCH libdrm v1 2/2] tests/modetest: Add support for writeback connector
Hi Andy,
On 7/25/2022 6:57 PM, Andy Yan wrote:
Hi Rohith:
At 2022-07-26 03:26:39, "Rohith Iyer" wrote:
Add writeback support to modetest with the below options:
+ case 'o':
+ pipe_args->dump = true;
+ dump_path = optarg;
+ break;
case 'P':
plane_args = realloc(plane_args,
(plane_count + 1) * sizeof
*plane_args);
@@ -2098,6 +2173,7 @@ int main(int argc, char **argv)
crtcs = 1;
planes = 1;
break;
+ case 'x':
case 's':
pipe_args = realloc(pipe_args,
(count + 1) * sizeof *pipe_args);
@@ -2109,7 +2185,7 @@ int main(int argc, char **argv)
if (parse_connector(_args[count], optarg) < 0)
usage(argv[0]);
-
+ pipe_args->custom = (c == 'x');
count++;
break;
case 'C':
@@ -2165,6 +2241,7 @@ int main(int argc, char **argv)
if (use_atomic) {
ret = drmSetClientCap(dev.fd, DRM_CLIENT_CAP_ATOMIC, 1);
+ drmSetClientCap(dev.fd, DRM_CLIENT_CAP_WRITEBACK_CONNECTORS, 1);
if (ret) {
fprintf(stderr, "no atomic modesetting support: %s\n",
strerror(errno));
drmClose(dev.fd);
@@ -2208,6 +2285,8 @@ int main(int argc, char **argv)
if (set_preferred || count)
set_mode(, pipe_args, count);
+ writeback_config(, pipe_args, count);
+
if (plane_count)
atomic_set_planes(, plane_args,
plane_count, false);
@@ -2217,6 +2296,13 @@ int main(int argc, char **argv)
return 1;
}
How do we make sure the writeback is finished? Do we need a writeback fence
here?
Thanks for pointing this out. We plan to have a function that polls on
the writeback fence fd, until the writeback is finished. Let me know if
you have something else in mind.
+ /*
+* Since only writeback connectors have an output fb,
this should only be
+* called for writeback.
+*/
+ if (pipe_args->dump)
+ dump_output_fb(, pipe_args, dump_path,
count);
+
if (test_vsync)
atomic_test_page_flip(, pipe_args,
plane_args, plane_count);
--
2.31.0
Thanks,
Rohith
Re: [PATCH v3] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
Quoting Kuogee Hsieh (2022-08-10 16:57:51)
>
> On 8/10/2022 3:22 PM, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2022-08-10 12:25:51)
> >> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> >> b/drivers/gpu/drm/msm/dp/dp_display.c
> >> index b36f8b6..678289a 100644
> >> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> >> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> >> @@ -1729,10 +1729,20 @@ void dp_bridge_disable(struct drm_bridge
> >> *drm_bridge)
> >> struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
> >> struct msm_dp *dp = dp_bridge->dp_display;
> >> struct dp_display_private *dp_display;
> >> + u32 state;
> >>
> >> dp_display = container_of(dp, struct dp_display_private,
> >> dp_display);
> >>
> >> + mutex_lock(_display->event_mutex);
> >> +
> >> + state = dp_display->hpd_state;
> >> + if (state != ST_DISCONNECT_PENDING && state != ST_CONNECTED) {
> > It's concerning that we have to check this at all. Are we still
> > interjecting into the disable path when the cable is disconnected?
>
> yes,
>
> The problem is not from cable disconnected.
>
> There is a corner case that this function is called at drm shutdown
> (drm_release).
>
> At that time, mainlink is not enabled, hence dp_ctrl_push_idle() will
> cause system crash.
The mainlink is only disabled when the cable is disconnected though?
Let me put it this way, if we have to check that the state is
"connected" or "disconnected pending" in the disable path then there's
an issue where this driver is being called in unexpected ways. This
driver is fighting the drm core each time there's a state check. We
really need to get rid of the state tracking entirely, and make sure
that the drm core is calling into the driver at the right time, i.e.
bridge disable is only called when the mainlink is enabled, etc.
Re: [PATCH v3] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
On 8/10/2022 3:22 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-08-10 12:25:51)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index b36f8b6..678289a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1729,10 +1729,20 @@ void dp_bridge_disable(struct drm_bridge *drm_bridge)
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
struct dp_display_private *dp_display;
+ u32 state;
dp_display = container_of(dp, struct dp_display_private, dp_display);
+ mutex_lock(_display->event_mutex);
+
+ state = dp_display->hpd_state;
+ if (state != ST_DISCONNECT_PENDING && state != ST_CONNECTED) {
It's concerning that we have to check this at all. Are we still
interjecting into the disable path when the cable is disconnected?
yes,
The problem is not from cable disconnected.
There is a corner case that this function is called at drm shutdown
(drm_release).
At that time, mainlink is not enabled, hence dp_ctrl_push_idle() will
cause system crash.
+ mutex_unlock(_display->event_mutex);
+ return;
+ }
+
dp_ctrl_push_idle(dp_display->ctrl);
+ mutex_unlock(_display->event_mutex);
[PATCH v3 4/4] drm/amdgpu: Document gfx_off members of struct amdgpu_gfx
Add comments to document gfx_off related members of struct amdgpu_gfx.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
index 1b8b4a5270c9..8abdf41d0f83 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
@@ -332,12 +332,12 @@ struct amdgpu_gfx {
uint32_tsrbm_soft_reset;
/* gfx off */
- boolgfx_off_state; /* true: enabled, false:
disabled */
- struct mutexgfx_off_mutex;
- uint32_tgfx_off_req_count; /* default 1, enable
gfx off: dec 1, disable gfx off: add 1 */
- struct delayed_work gfx_off_delay_work;
- uint32_tgfx_off_residency;
- uint64_tgfx_off_entrycount;
+ boolgfx_off_state; /* true: enabled,
false: disabled */
+ struct mutexgfx_off_mutex; /* mutex to change
gfxoff state */
+ uint32_tgfx_off_req_count; /* default 1,
enable gfx off: dec 1, disable gfx off: add 1 */
+ struct delayed_work gfx_off_delay_work; /* async work to
set gfx block off */
+ uint32_tgfx_off_residency; /* last logged
residency */
+ uint64_tgfx_off_entrycount; /* count of times
GPU has get into GFXOFF state */
/* pipe reservation */
struct mutexpipe_reserve_mutex;
--
2.37.1
[PATCH v3 3/4] Documentation/gpu: Document GFXOFF's count and residency
Add documentation explaining those two new files. While here, add a note about the value type. Signed-off-by: André Almeida --- Documentation/gpu/amdgpu/thermal.rst | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/Documentation/gpu/amdgpu/thermal.rst b/Documentation/gpu/amdgpu/thermal.rst index 997231b6adcf..5e27e4eb3959 100644 --- a/Documentation/gpu/amdgpu/thermal.rst +++ b/Documentation/gpu/amdgpu/thermal.rst @@ -72,7 +72,8 @@ card's RLC (RunList Controller) firmware powers off the gfx engine dynamically when there is no workload on gfx or compute pipes. GFXOFF is on by default on supported GPUs. -Userspace can interact with GFXOFF through a debugfs interface: +Userspace can interact with GFXOFF through a debugfs interface (all values in +`uint32_t`, unless otherwise noted): ``amdgpu_gfxoff`` - @@ -104,3 +105,18 @@ Read it to check current GFXOFF's status of a GPU:: If GFXOFF is enabled, the value will be transitioning around [0, 3], always getting into 0 when possible. When it's disabled, it's always at 2. Returns ``-EINVAL`` if it's not supported. + +``amdgpu_gfxoff_count`` +--- + +Read it to get the total GFXOFF entry count at the time of query since system +power-up. The value is an `uint64_t` type, however, due to firmware limitations, +it can currently overflow as an `uint32_t`. *Only supported in vangogh* + +``amdgpu_gfxoff_residency`` +--- + +Write 1 to amdgpu_gfxoff_residency to start logging, and 0 to stop. Read it to +get average GFXOFF residency % multiplied by 100 during the last logging +interval. E.g. a value of 7854 means 78.54% of the time in the last logging +interval the GPU was in GFXOFF mode. *Only supported in vangogh* -- 2.37.1
[PATCH v3 2/4] drm/amd/pm: Implement GFXOFF's entry count and residency for vangogh
Implement functions to get and set GFXOFF's entry count and residency
for vangogh.
Signed-off-by: André Almeida
---
.../pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h| 5 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 5 +-
.../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 76 +++
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
index fe130a497d6c..7471e2df2828 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
@@ -108,7 +108,10 @@
#define PPSMC_MSG_SetSlowPPTLimit 0x4A
#define PPSMC_MSG_GetFastPPTLimit 0x4B
#define PPSMC_MSG_GetSlowPPTLimit 0x4C
-#define PPSMC_Message_Count0x4D
+#define PPSMC_MSG_GetGfxOffStatus 0x50
+#define PPSMC_MSG_GetGfxOffEntryCount 0x51
+#define PPSMC_MSG_LogGfxOffResidency 0x52
+#define PPSMC_Message_Count0x53
//Argument for PPSMC_MSG_GfxDeviceDriverReset
enum {
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
index 19084a4fcb2b..76fb6cbbc09c 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
@@ -235,7 +235,10 @@
__SMU_DUMMY_MAP(UnforceGfxVid), \
__SMU_DUMMY_MAP(HeavySBR), \
__SMU_DUMMY_MAP(SetBadHBMPagesRetiredFlagsPerChannel), \
- __SMU_DUMMY_MAP(EnableGfxImu),
+ __SMU_DUMMY_MAP(EnableGfxImu), \
+ __SMU_DUMMY_MAP(GetGfxOffStatus),\
+ __SMU_DUMMY_MAP(GetGfxOffEntryCount),\
+ __SMU_DUMMY_MAP(LogGfxOffResidency),
#undef __SMU_DUMMY_MAP
#define __SMU_DUMMY_MAP(type) SMU_MSG_##type
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
index 89504ff8e9ed..847990145dcd 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
@@ -138,6 +138,9 @@ static struct cmn2asic_msg_mapping
vangogh_message_map[SMU_MSG_MAX_COUNT] = {
MSG_MAP(SetSlowPPTLimit,PPSMC_MSG_SetSlowPPTLimit,
0),
MSG_MAP(GetFastPPTLimit,PPSMC_MSG_GetFastPPTLimit,
0),
MSG_MAP(GetSlowPPTLimit,PPSMC_MSG_GetSlowPPTLimit,
0),
+ MSG_MAP(GetGfxOffStatus,PPSMC_MSG_GetGfxOffStatus,
0),
+ MSG_MAP(GetGfxOffEntryCount,
PPSMC_MSG_GetGfxOffEntryCount, 0),
+ MSG_MAP(LogGfxOffResidency,
PPSMC_MSG_LogGfxOffResidency, 0),
};
static struct cmn2asic_mapping vangogh_feature_mask_map[SMU_FEATURE_COUNT] = {
@@ -2200,6 +2203,76 @@ static int vangogh_set_power_limit(struct smu_context
*smu,
return ret;
}
+/**
+ * vangogh_set_gfxoff_residency
+ *
+ * @smu: amdgpu_device pointer
+ * @start: start/stop residency log
+ *
+ * This function will be used to log gfxoff residency
+ *
+ *
+ * Returns standard response codes.
+ */
+static u32 vangogh_set_gfxoff_residency(struct smu_context *smu, bool start)
+{
+ int ret = 0;
+ u32 residency;
+ struct amdgpu_device *adev = smu->adev;
+
+ if (!(adev->pm.pp_feature & PP_GFXOFF_MASK))
+ return 0;
+
+ ret = smu_cmn_send_smc_msg_with_param(smu, SMU_MSG_LogGfxOffResidency,
+ start, );
+
+ if (!start)
+ adev->gfx.gfx_off_residency = residency;
+
+ return ret;
+}
+
+/**
+ * vangogh_get_gfxoff_residency
+ *
+ * @smu: amdgpu_device pointer
+ *
+ * This function will be used to get gfxoff residency.
+ *
+ * Returns standard response codes.
+ */
+static u32 vangogh_get_gfxoff_residency(struct smu_context *smu, uint32_t
*residency)
+{
+ struct amdgpu_device *adev = smu->adev;
+
+ *residency = adev->gfx.gfx_off_residency;
+
+ return 0;
+}
+
+/**
+ * vangogh_get_gfxoff_entrycount - get gfxoff entry count
+ *
+ * @smu: amdgpu_device pointer
+ *
+ * This function will be used to get gfxoff entry count
+ *
+ * Returns standard response codes.
+ */
+static u32 vangogh_get_gfxoff_entrycount(struct smu_context *smu, uint64_t
*entrycount)
+{
+ int ret = 0, value = 0;
+ struct amdgpu_device *adev = smu->adev;
+
+ if (!(adev->pm.pp_feature & PP_GFXOFF_MASK))
+ return 0;
+
+ ret = smu_cmn_send_smc_msg(smu, SMU_MSG_GetGfxOffEntryCount, );
+ *entrycount = value +
[PATCH v3 1/4] drm/amd: Add detailed GFXOFF stats to debugfs
Add debugfs interface to log GFXOFF statistics:
- Read amdgpu_gfxoff_count to get the total GFXOFF entry count at the
time of query since system power-up
- Write 1 to amdgpu_gfxoff_residency to start logging, and 0 to stop.
Read it to get average GFXOFF residency % multiplied by 100
during the last logging interval.
Both features are designed to be keep the values persistent between
suspends.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 168 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 39
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 6 +
drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 45 +
drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 3 +
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 33
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 22 +++
drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 +
9 files changed, 321 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index e2eec985adb3..e0eed087dba4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1042,6 +1042,157 @@ static ssize_t amdgpu_debugfs_gpr_read(struct file *f,
char __user *buf,
return r;
}
+/**
+ * amdgpu_debugfs_gfxoff_residency_read - Read GFXOFF residency
+ *
+ * @f: open file handle
+ * @buf: User buffer to store read data in
+ * @size: Number of bytes to read
+ * @pos: Offset to seek to
+ *
+ * Read the last residency value logged. It doesn't auto update, one needs to
+ * stop logging before getting the current value.
+ */
+static ssize_t amdgpu_debugfs_gfxoff_residency_read(struct file *f, char
__user *buf,
+ size_t size, loff_t *pos)
+{
+ struct amdgpu_device *adev = file_inode(f)->i_private;
+ ssize_t result = 0;
+ int r;
+
+ if (size & 0x3 || *pos & 0x3)
+ return -EINVAL;
+
+ r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
+ if (r < 0) {
+ pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
+ return r;
+ }
+
+ while (size) {
+ uint32_t value;
+
+ r = amdgpu_get_gfx_off_residency(adev, );
+ if (r)
+ goto out;
+
+ r = put_user(value, (uint32_t *)buf);
+ if (r)
+ goto out;
+
+ result += 4;
+ buf += 4;
+ *pos += 4;
+ size -= 4;
+ }
+
+ r = result;
+out:
+ pm_runtime_mark_last_busy(adev_to_drm(adev)->dev);
+ pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
+
+ return r;
+}
+
+/**
+ * amdgpu_debugfs_gfxoff_residency_write - Log GFXOFF Residency
+ *
+ * @f: open file handle
+ * @buf: User buffer to write data from
+ * @size: Number of bytes to write
+ * @pos: Offset to seek to
+ *
+ * Write a 32-bit non-zero to start logging; write a 32-bit zero to stop
+ */
+static ssize_t amdgpu_debugfs_gfxoff_residency_write(struct file *f, const
char __user *buf,
+size_t size, loff_t *pos)
+{
+ struct amdgpu_device *adev = file_inode(f)->i_private;
+ ssize_t result = 0;
+ int r;
+
+ if (size & 0x3 || *pos & 0x3)
+ return -EINVAL;
+
+ r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
+ if (r < 0) {
+ pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
+ return r;
+ }
+
+ while (size) {
+ u32 value;
+
+ r = get_user(value, (uint32_t *)buf);
+ if (r)
+ goto out;
+
+ amdgpu_set_gfx_off_residency(adev, value ? true : false);
+
+ result += 4;
+ buf += 4;
+ *pos += 4;
+ size -= 4;
+ }
+
+ r = result;
+out:
+ pm_runtime_mark_last_busy(adev_to_drm(adev)->dev);
+ pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
+
+ return r;
+}
+
+
+/**
+ * amdgpu_debugfs_gfxoff_count_read - Read GFXOFF entry count
+ *
+ * @f: open file handle
+ * @buf: User buffer to store read data in
+ * @size: Number of bytes to read
+ * @pos: Offset to seek to
+ */
+static ssize_t amdgpu_debugfs_gfxoff_count_read(struct file *f, char __user
*buf,
+ size_t size, loff_t *pos)
+{
+ struct amdgpu_device *adev = file_inode(f)->i_private;
+ ssize_t result = 0;
+ int r;
+
+ if (size & 0x3 || *pos & 0x3)
+ return -EINVAL;
+
+ r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
+ if (r < 0) {
+ pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
+ return r;
+ }
+
+ while (size) {
+ u64 value = 0;
+
+ r =
[PATCH v3 0/4] drm/amd: Add more GFXOFF stats for vangogh
This series adds new logging features for GFXOFF available for vangogh and documentation for it. I've created a small userspace program to interact with this new debugfs interface and it can be found at: https://gitlab.freedesktop.org/andrealmeid/gfxoff_tool Changelog: v3: - drop IP version check v2: - Make entrycount uint64_t - Add a note in docs about data types and overflow André Almeida (4): drm/amd: Add detailed GFXOFF stats to debugfs drm/amd/pm: Implement GFXOFF's entry count and residency for vangogh Documentation/gpu: Document GFXOFF's count and residency drm/amdgpu: Document gfx_off members of struct amdgpu_gfx Documentation/gpu/amdgpu/thermal.rst | 18 +- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 168 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 39 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 14 +- drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 45 + drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 3 + drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 33 drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 22 +++ .../pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h| 5 +- drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 5 +- .../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 77 drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 + 13 files changed, 427 insertions(+), 7 deletions(-) -- 2.37.1
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
On Wed, Aug 10, 2022 at 3:23 PM Dmitry Osipenko
wrote:
>
> On 8/11/22 01:03, Rob Clark wrote:
> > On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko
> > wrote:
> >>
> >> On 8/10/22 18:08, Rob Clark wrote:
> >>> On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter wrote:
>
> On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote:
> > On 7/6/22 00:48, Rob Clark wrote:
> >> On Tue, Jul 5, 2022 at 4:51 AM Christian König
> >> wrote:
> >>>
> >>> Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
> handle imported dma-bufs properly, which results in mapping of
> something
> else than the imported dma-buf. On NVIDIA Tegra we get a hard lockup
> when
> userspace writes to the memory mapping of a dma-buf that was
> imported into
> Tegra's DRM GEM.
>
> Majority of DRM drivers prohibit mapping of the imported GEM objects.
> Mapping of imported GEMs require special care from userspace since it
> should sync dma-buf because mapping coherency of the exporter device
> may
> not match the DRM device. Let's prohibit the mapping for all DRM
> drivers
> for consistency.
>
> Suggested-by: Thomas Hellström
> Signed-off-by: Dmitry Osipenko
> >>>
> >>> I'm pretty sure that this is the right approach, but it's certainly
> >>> more
> >>> than possible that somebody abused this already.
> >>
> >> I suspect that this is abused if you run deqp cts on android.. ie. all
> >> winsys buffers are dma-buf imports from gralloc. And then when you
> >> hit readpix...
> >>
> >> You might only hit this in scenarios with separate gpu and display (or
> >> dGPU+iGPU) because self-imports are handled differently in
> >> drm_gem_prime_import_dev().. and maybe not in cases where you end up
> >> with a blit from tiled/compressed to linear.. maybe that narrows the
> >> scope enough to just fix it in userspace?
> >
> > Given that that only drivers which use DRM-SHMEM potentially could've
> > map imported dma-bufs (Panfrost, Lima) and they already don't allow to
> > do that, I think we're good.
>
> So can I have an ack from Rob here or are there still questions that this
> might go boom?
>
> Dmitry, since you have a bunch of patches merged now I think would also
> be
> good to get commit rights so you can drive this more yourself. I've asked
> Daniel Stone to help you out with getting that.
> >>>
> >>> I *think* we'd be ok with this on msm, mostly just by dumb luck.
> >>> Because the dma-buf's we import will be self-import. I'm less sure
> >>> about panfrost (src/panfrost/lib/pan_bo.c doesn't seem to have a
> >>> special path for imported dma-bufs either, and in that case they won't
> >>> be self-imports.. but I guess no one has tried to run android cts on
> >>> panfrost).
> >>
> >> The last time I tried to mmap dma-buf imported to Panfrost didn't work
> >> because Panfrost didn't implement something needed for that. I'll need
> >> to take a look again because can't recall what it was.
> >>
> >>> What about something less drastic to start, like (apologies for
> >>> hand-edited patch):
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> >>> index 86d670c71286..fc9ec42fa0ab 100644
> >>> --- a/drivers/gpu/drm/drm_gem.c
> >>> +++ b/drivers/gpu/drm/drm_gem.c
> >>> @@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object
> >>> *obj, unsigned long obj_size,
> >>> {
> >>> int ret;
> >>>
> >>> + WARN_ON_ONCE(obj->import_attach);
> >>
> >> This will hang NVIDIA Tegra, which is what this patch fixed initially.
> >> If neither of upstream DRM drivers need to map imported dma-bufs and
> >> never needed, then why do we need this?
> >
> > oh, tegra isn't using shmem helpers? I assumed it was. Well my point
> > was to make a more targeted fail on tegra, and a WARN_ON for everyone
> > else to make it clear that what they are doing is undefined behavior.
> > Because so far existing userspace (or well, panfrost and freedreno at
> > least, those are the two I know or checked) don't make special cases
> > for mmap'ing against the dmabuf fd against the dmabuf fd instead of
> > the drm device fd.
>
> It's not clear to me what bad Android does form yours comments. Does it
> export dma-buf from GPU and then import it to GPU? If yes, then DRM core
> has a check for the self-importing [1].
>
> [1]
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_prime.c#L918
>
> If you're meaning something else, then please explain in a more details.
So, android/gralloc allocates buffers externally to the driver and
imports them into driver. (And that seems to not just be window
surfaces, but in cases random textures, etc)
In the
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
On 8/11/22 01:03, Rob Clark wrote:
> On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko
> wrote:
>>
>> On 8/10/22 18:08, Rob Clark wrote:
>>> On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter wrote:
On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote:
> On 7/6/22 00:48, Rob Clark wrote:
>> On Tue, Jul 5, 2022 at 4:51 AM Christian König
>> wrote:
>>>
>>> Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of
something
else than the imported dma-buf. On NVIDIA Tegra we get a hard lockup
when
userspace writes to the memory mapping of a dma-buf that was imported
into
Tegra's DRM GEM.
Majority of DRM drivers prohibit mapping of the imported GEM objects.
Mapping of imported GEMs require special care from userspace since it
should sync dma-buf because mapping coherency of the exporter device
may
not match the DRM device. Let's prohibit the mapping for all DRM
drivers
for consistency.
Suggested-by: Thomas Hellström
Signed-off-by: Dmitry Osipenko
>>>
>>> I'm pretty sure that this is the right approach, but it's certainly more
>>> than possible that somebody abused this already.
>>
>> I suspect that this is abused if you run deqp cts on android.. ie. all
>> winsys buffers are dma-buf imports from gralloc. And then when you
>> hit readpix...
>>
>> You might only hit this in scenarios with separate gpu and display (or
>> dGPU+iGPU) because self-imports are handled differently in
>> drm_gem_prime_import_dev().. and maybe not in cases where you end up
>> with a blit from tiled/compressed to linear.. maybe that narrows the
>> scope enough to just fix it in userspace?
>
> Given that that only drivers which use DRM-SHMEM potentially could've
> map imported dma-bufs (Panfrost, Lima) and they already don't allow to
> do that, I think we're good.
So can I have an ack from Rob here or are there still questions that this
might go boom?
Dmitry, since you have a bunch of patches merged now I think would also be
good to get commit rights so you can drive this more yourself. I've asked
Daniel Stone to help you out with getting that.
>>>
>>> I *think* we'd be ok with this on msm, mostly just by dumb luck.
>>> Because the dma-buf's we import will be self-import. I'm less sure
>>> about panfrost (src/panfrost/lib/pan_bo.c doesn't seem to have a
>>> special path for imported dma-bufs either, and in that case they won't
>>> be self-imports.. but I guess no one has tried to run android cts on
>>> panfrost).
>>
>> The last time I tried to mmap dma-buf imported to Panfrost didn't work
>> because Panfrost didn't implement something needed for that. I'll need
>> to take a look again because can't recall what it was.
>>
>>> What about something less drastic to start, like (apologies for
>>> hand-edited patch):
>>>
>>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>>> index 86d670c71286..fc9ec42fa0ab 100644
>>> --- a/drivers/gpu/drm/drm_gem.c
>>> +++ b/drivers/gpu/drm/drm_gem.c
>>> @@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object
>>> *obj, unsigned long obj_size,
>>> {
>>> int ret;
>>>
>>> + WARN_ON_ONCE(obj->import_attach);
>>
>> This will hang NVIDIA Tegra, which is what this patch fixed initially.
>> If neither of upstream DRM drivers need to map imported dma-bufs and
>> never needed, then why do we need this?
>
> oh, tegra isn't using shmem helpers? I assumed it was. Well my point
> was to make a more targeted fail on tegra, and a WARN_ON for everyone
> else to make it clear that what they are doing is undefined behavior.
> Because so far existing userspace (or well, panfrost and freedreno at
> least, those are the two I know or checked) don't make special cases
> for mmap'ing against the dmabuf fd against the dmabuf fd instead of
> the drm device fd.
It's not clear to me what bad Android does form yours comments. Does it
export dma-buf from GPU and then import it to GPU? If yes, then DRM core
has a check for the self-importing [1].
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_prime.c#L918
If you're meaning something else, then please explain in a more details.
> I *think* it should work out that we don't hit this path with
> freedreno but on android I can't really guarantee or prove it. So
> your patch would potentially break existing working userspace. Maybe
> it is userspace that isn't portable (but OTOH it isn't like you are
> going to be using freedreno on tegra). So why don't you go for a more
> targeted fix that only returns an error on hw where this is
> problematic?
That's what the first versions of the
Re: [PATCH v3] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
Quoting Kuogee Hsieh (2022-08-10 12:25:51)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index b36f8b6..678289a 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -1729,10 +1729,20 @@ void dp_bridge_disable(struct drm_bridge *drm_bridge)
> struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
> struct msm_dp *dp = dp_bridge->dp_display;
> struct dp_display_private *dp_display;
> + u32 state;
>
> dp_display = container_of(dp, struct dp_display_private, dp_display);
>
> + mutex_lock(_display->event_mutex);
> +
> + state = dp_display->hpd_state;
> + if (state != ST_DISCONNECT_PENDING && state != ST_CONNECTED) {
It's concerning that we have to check this at all. Are we still
interjecting into the disable path when the cable is disconnected?
> + mutex_unlock(_display->event_mutex);
> + return;
> + }
> +
> dp_ctrl_push_idle(dp_display->ctrl);
> + mutex_unlock(_display->event_mutex);
Re: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing payloads if last connected port isn't connected
On Wed, 2022-08-10 at 03:28 +, Lin, Wayne wrote:
> Hi Lyude,
> Thanks for your time and sorry for late response!
>
> It's described in 5.6.1.3 of DP spec 2.0:
> "MST branch device, in addition to waiting for the ACK from its immediate
> Upstream device, should either wait for the ALLOCATE_PAYLOAD message
> transaction with a PBN value equal to 0 from the MST Source device for
> de-allocating the time slot assigned to the VC Payload that is routed to the
> unplugged DFP or for 2 seconds, whichever occurs first."
oooh! Thank you for posting this, I totally missed the bit that says "or for 2
seconds, whichever occurs first." That certainly explains a lot.
>
> > > commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> > > ports in stale topology") was trying to skip updating payload for a
> > > target which is no longer existing in the current topology rooted at
> > > mgr->mst_primary. I passed "mgr->mst_primary" to
> > > drm_dp_mst_port_downstream_of_branch() previously.
> > > Sorry, I might not fully understand the issue you've seen. Could you
> > > elaborate on this more please?
> > >
> > > Thanks!
> >
> > I will have to double check this since it's been a month, but basically -
> > the idea
> > of having the topology references in the first place was to be the one check
> > for figuring out whether something's in a topology or not. I've been
> > thinking
> > of maybe trying to replace it at some point, but I think we'd want to do it
> > all
> > over the helpers instead of just in certain spots.
> >
> > The other thing I noticed was that when I was rewriting this code, I
> > noticed it
> > seemed a lot like we had misunderstood the issue that was causing leaks in
> > the first place. The BAD_PARAM we noticed indicates the payload we're
> > trying to remove on the other end doesn't exist anymore, meaning the
> > branch device in question got rid of any payloads it had active in response
> > to
> > the CSN. In testing though I found that payloads would be automatically
> > released in situations where the last reachable port was marked as
> > disconnected via a previous CSN, but was still reachable otherwise, and not
> > in
> > any other situation. This also seemed to match up with the excerpts in the
> > DP
> > spec that I found, so I assumed it was probably correct.
>
> IMHO, the main root cause with the commit 3769e4c0af5b ("drm/dp_mst: Avoid
> to mess up payload table by ports in stale topology") is like what described
> in the
> commit message. The problem I encountered was when I unplugged the primary
> mst branch device from the system, upper layer didn't try to release stale
> streams
> immediately. Instead, it started to gradually release stale streams when I
> plugged the
> mst hub back to the system. In that case, if we didn't do the check to see
> whether
> the current request for deallocating payload is for this time topology
> instance,
> i.e. might be for the stale topology before I unplug, this deallocation will
> mess up
> payload allocation for new topology instance.
>
> As for the CSN, it's a node broadcast request message and not a path message.
> Referring to 2.14.6.1 of DP 2.0 spec:
> "If the broadcast message is a node request, only the end devices, DP MST
> Source or Sink devices (or DP MST Branch device if Source/Sink are not
> plugged),
> process the request."
> IMHO, payload should be controlled by source only, by ALLOCATE_PAYLOAD or
> CLEAR_PAYLAOD_ID_TABLE message.
>
> >
> > Also, I think using the DDPS field instead of trying to traverse the
> > topology
> > state (which might not have been fully updated yet in response to CSNs)
> > might be a slightly better idea since DDPS may end up being updated before
> > the port has been removed from our in-memory topology, which is kind of
>
> Thank you Lyude! Just want to confirm with you the below idea to see if I
> understand it correctly.
> The flow I thought would be (from Source perspective):
> Receive CSN for notifying disconnection event => update physical topology
> connection status (e.g. DDPS, put topology krefcount..) => send hotplug event
> to
> userspace => userspace asks deallocating payloads for disconnected stream
> sinks => put malloc krefcount of disconnected ports/mstbs => remove
> ports/mstb
> from in-memory topology.
> I suppose physical topology connection status is updated before sending
> hotplug
> event to userspace and the in-memory topology still can be referred for stale
> connection status before payload deallocation completes, i.e. which will put
> malloc krefcount to eventually destroy disconnected devices in topology
> in-memory.
> I mean, ideally, sounds like the topology in-memory should be reliable when
> we send ALLOCATE_PAYLOAD as PBN=0. But I understand it definitely is not the
> case if we have krefcount leak.
mhm, I think you made me realize I'm overthinking this a bit now that I've
seen the excerpt you mentioned above, along with the
Re: [PATCH v5] drm: Add initial ci/ subdirectory
On Wed, Aug 10, 2022 at 11:25 AM Rodrigo Siqueira Jordao
wrote:
>
> Hi Tomeu,
>
> First of all, nice patch! I just saw it, and I have some basic questions
> (I don't understand many of these CI details). I also CC some CI folks
> from the display team at AMD.
>
> On 2022-07-26 14:16, Tomeu Vizoso wrote:
> > And use it to store expectations about what the DRM drivers are
> > supposed to pass in the IGT test suite.
> >
> > Also include a configuration file that points to the out-of-tree CI
> > scripts.
> >
> > By storing the test expectations along the code we can make sure both
> > stay in sync with each other, and so we can know when a code change
> > breaks those expectations.
> >
> > This will allow all contributors to drm to reuse the infrastructure
> > already in gitlab.freedesktop.org to test the driver on several
> > generations of the hardware.
> >
> > v2:
> >- Fix names of result expectation files to match SoC
> >- Don't execute tests that are going to skip on all boards
> >
> > v3:
> >- Remove tracking of dmesg output during test execution
> >
> > v4:
> >- Move up to drivers/gpu/drm
> >- Add support for a bunch of other drivers
> >- Explain how to incorporate fixes for CI from a
> > ${TARGET_BRANCH}-external-fixes branch
> >- Remove tests that pass from expected results file, to reduce the
> > size of in-tree files
> >- Add docs about how to deal with outages in automated testing labs
> >- Specify the exact SHA of the CI scripts to be used
> >
> > v5:
> >- Remove unneeded skips from Meson expectations file
> >- Use a more advanced runner that detects flakes automatically
> >- Use a more succint format for the expectations
> >- Run many more tests (and use sharding to finish in time)
> >- Use skip lists to avoid hanging machines
> >- Add some build testing
> >- Build IGT in each pipeline for faster uprevs
> >- List failures in the GitLab UI
> >
> > Signed-off-by: Tomeu Vizoso
> > Reviewed-by: Neil Armstrong
> > ---
> > Documentation/gpu/automated_testing.rst | 84 ++
> > drivers/gpu/drm/ci/amdgpu-stoney-fails.txt| 13 +++
> > drivers/gpu/drm/ci/amdgpu-stoney-flakes.txt | 20 +
> > drivers/gpu/drm/ci/amdgpu-stoney-skips.txt| 2 +
> > drivers/gpu/drm/ci/gitlab-ci.yml | 13 +++
> > drivers/gpu/drm/ci/i915-amly-flakes.txt | 32 +++
> > drivers/gpu/drm/ci/i915-amly-skips.txt| 2 +
> > drivers/gpu/drm/ci/i915-apl-fails.txt | 29 +++
> > drivers/gpu/drm/ci/i915-apl-flakes.txt| 1 +
> > drivers/gpu/drm/ci/i915-apl-skips.txt | 2 +
> > drivers/gpu/drm/ci/i915-cml-flakes.txt| 36
> > drivers/gpu/drm/ci/i915-glk-flakes.txt| 40 +
> > drivers/gpu/drm/ci/i915-glk-skips.txt | 2 +
> > drivers/gpu/drm/ci/i915-kbl-fails.txt | 8 ++
> > drivers/gpu/drm/ci/i915-kbl-flakes.txt| 24 ++
> > drivers/gpu/drm/ci/i915-kbl-skips.txt | 2 +
> > drivers/gpu/drm/ci/i915-tgl-fails.txt | 19
> > drivers/gpu/drm/ci/i915-tgl-flakes.txt| 6 ++
> > drivers/gpu/drm/ci/i915-tgl-skips.txt | 8 ++
> > drivers/gpu/drm/ci/i915-whl-fails.txt | 30 +++
> > drivers/gpu/drm/ci/i915-whl-flakes.txt| 1 +
> > drivers/gpu/drm/ci/mediatek-mt8173-fails.txt | 29 +++
> > drivers/gpu/drm/ci/mediatek-mt8183-fails.txt | 10 +++
> > drivers/gpu/drm/ci/mediatek-mt8183-flakes.txt | 14 +++
> > drivers/gpu/drm/ci/meson-g12b-fails.txt | 5 ++
> > drivers/gpu/drm/ci/meson-g12b-flakes.txt | 4 +
> > drivers/gpu/drm/ci/msm-apq8016-fails.txt | 15
> > drivers/gpu/drm/ci/msm-apq8016-flakes.txt | 4 +
> > drivers/gpu/drm/ci/msm-apq8096-fails.txt | 2 +
> > drivers/gpu/drm/ci/msm-apq8096-flakes.txt | 4 +
> > drivers/gpu/drm/ci/msm-apq8096-skips.txt | 2 +
> > drivers/gpu/drm/ci/msm-sc7180-fails.txt | 22 +
> > drivers/gpu/drm/ci/msm-sc7180-flakes.txt | 14 +++
> > drivers/gpu/drm/ci/msm-sc7180-skips.txt | 18
> > drivers/gpu/drm/ci/msm-sdm845-fails.txt | 44 ++
> > drivers/gpu/drm/ci/msm-sdm845-flakes.txt | 33 +++
> > drivers/gpu/drm/ci/msm-sdm845-skips.txt | 2 +
> > drivers/gpu/drm/ci/rockchip-rk3288-fails.txt | 75
> > drivers/gpu/drm/ci/rockchip-rk3288-flakes.txt | 5 ++
> > drivers/gpu/drm/ci/rockchip-rk3288-skips.txt | 46 ++
> > drivers/gpu/drm/ci/rockchip-rk3399-fails.txt | 86 +++
> > drivers/gpu/drm/ci/rockchip-rk3399-flakes.txt | 25 ++
> > drivers/gpu/drm/ci/rockchip-rk3399-skips.txt | 5 ++
> > drivers/gpu/drm/ci/virtio_gpu-none-fails.txt | 38
> > drivers/gpu/drm/ci/virtio_gpu-none-flakes.txt | 0
> > drivers/gpu/drm/ci/virtio_gpu-none-skips.txt | 6 ++
> > 46 files changed, 882 insertions(+)
> > create mode 100644
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko
wrote:
>
> On 8/10/22 18:08, Rob Clark wrote:
> > On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter wrote:
> >>
> >> On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote:
> >>> On 7/6/22 00:48, Rob Clark wrote:
> On Tue, Jul 5, 2022 at 4:51 AM Christian König
> wrote:
> >
> > Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
> >> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
> >> handle imported dma-bufs properly, which results in mapping of
> >> something
> >> else than the imported dma-buf. On NVIDIA Tegra we get a hard lockup
> >> when
> >> userspace writes to the memory mapping of a dma-buf that was imported
> >> into
> >> Tegra's DRM GEM.
> >>
> >> Majority of DRM drivers prohibit mapping of the imported GEM objects.
> >> Mapping of imported GEMs require special care from userspace since it
> >> should sync dma-buf because mapping coherency of the exporter device
> >> may
> >> not match the DRM device. Let's prohibit the mapping for all DRM
> >> drivers
> >> for consistency.
> >>
> >> Suggested-by: Thomas Hellström
> >> Signed-off-by: Dmitry Osipenko
> >
> > I'm pretty sure that this is the right approach, but it's certainly more
> > than possible that somebody abused this already.
>
> I suspect that this is abused if you run deqp cts on android.. ie. all
> winsys buffers are dma-buf imports from gralloc. And then when you
> hit readpix...
>
> You might only hit this in scenarios with separate gpu and display (or
> dGPU+iGPU) because self-imports are handled differently in
> drm_gem_prime_import_dev().. and maybe not in cases where you end up
> with a blit from tiled/compressed to linear.. maybe that narrows the
> scope enough to just fix it in userspace?
> >>>
> >>> Given that that only drivers which use DRM-SHMEM potentially could've
> >>> map imported dma-bufs (Panfrost, Lima) and they already don't allow to
> >>> do that, I think we're good.
> >>
> >> So can I have an ack from Rob here or are there still questions that this
> >> might go boom?
> >>
> >> Dmitry, since you have a bunch of patches merged now I think would also be
> >> good to get commit rights so you can drive this more yourself. I've asked
> >> Daniel Stone to help you out with getting that.
> >
> > I *think* we'd be ok with this on msm, mostly just by dumb luck.
> > Because the dma-buf's we import will be self-import. I'm less sure
> > about panfrost (src/panfrost/lib/pan_bo.c doesn't seem to have a
> > special path for imported dma-bufs either, and in that case they won't
> > be self-imports.. but I guess no one has tried to run android cts on
> > panfrost).
>
> The last time I tried to mmap dma-buf imported to Panfrost didn't work
> because Panfrost didn't implement something needed for that. I'll need
> to take a look again because can't recall what it was.
>
> > What about something less drastic to start, like (apologies for
> > hand-edited patch):
> >
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index 86d670c71286..fc9ec42fa0ab 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object
> > *obj, unsigned long obj_size,
> > {
> > int ret;
> >
> > + WARN_ON_ONCE(obj->import_attach);
>
> This will hang NVIDIA Tegra, which is what this patch fixed initially.
> If neither of upstream DRM drivers need to map imported dma-bufs and
> never needed, then why do we need this?
oh, tegra isn't using shmem helpers? I assumed it was. Well my point
was to make a more targeted fail on tegra, and a WARN_ON for everyone
else to make it clear that what they are doing is undefined behavior.
Because so far existing userspace (or well, panfrost and freedreno at
least, those are the two I know or checked) don't make special cases
for mmap'ing against the dmabuf fd against the dmabuf fd instead of
the drm device fd.
I *think* it should work out that we don't hit this path with
freedreno but on android I can't really guarantee or prove it. So
your patch would potentially break existing working userspace. Maybe
it is userspace that isn't portable (but OTOH it isn't like you are
going to be using freedreno on tegra). So why don't you go for a more
targeted fix that only returns an error on hw where this is
problematic?
BR,
-R
Re: [PATCH v5 00/13] Canaan devicetree fixes
On Fri, 05 Aug 2022 10:51:00 PDT (-0700), conor.doo...@microchip.com wrote: On 14/07/2022 23:11, Conor Dooley - M52691 wrote: On 14/07/2022 23:04, Palmer Dabbelt wrote: I'm trying to sort out how to merge this one. I'm not opposed to taking it through the RISC-V tree as Rob's reviewed/acked the bindings, but just figured I'd say something before putting anything on for-next to try and minimize confusion. Unless I'm missing something it's just patch 3 that's been taken so far, via Vinod's tree. I've dropped that one and put the rest on palmer/riscv-canaan_dt_schema, if that looks good then I'll take it into riscv/for-next when this loops back to the top of my queue. Thanks! Patches 1 & 2 never got review from the DRM side and patch 12 depends on those. If it comes to it, you could drop those three (and patch 3 that Vinod took). The only other one is patch 4, which has Krzysztof's ack as memory-controller maintainer, so that one should be okay. Hey Palmer, These fixes have been sitting on palmer/riscv-canaan_dt_schema for a few weeks now, without an autobuilder complaint etc. Could you move it onto for-next? These are on for-next.
Re: [PATCH v2 1/3] drm/dp_mst: add passthrough_aux to struct drm_dp_mst_port
On Wed, 2022-08-10 at 09:23 -0400, Hamza Mahfooz wrote:
> On 2022-08-09 18:01, Lyude Paul wrote:
> > Ah yes of course! Probably should have asked when I gave the r-b :). Also,
> > just so patchwork actually catches it I will say the magic incantation:
> >
> > Reviewed-by: Lyude Paul
> >
> > Do we want to merge just this patch to drm-misc-next, or do you want to
> > merge
> > the whole series through there? If you'd rather just merge this through
> > amd's
> > branch I'm fine with that as well
>
> In that case, it is preferable to have all of the patches in this series
> to get merged through amd's branch.\
Sounds totally fine to me! Just make sure to run it by Harry or another amdgpu
maintainer first, and then you should be good to go.
>
> >
> > On Tue, 2022-08-09 at 11:15 -0400, Hamza Mahfooz wrote:
> > > Hey Lyude,
> > >
> > > On 2022-08-05 17:17, Lyude Paul wrote:
> > > > lgtm!
> > > >
> > >
> > > Any chance you can apply this to drm-misc-next?
> > >
> > > > Reviewed-by: Lyude Paul
> > > >
> > > > On Fri, 2022-08-05 at 17:13 -0400, Hamza Mahfooz wrote:
> > > > > Currently, there is no way to identify if DSC pass-through can be
> > > > > enabled and what aux DSC pass-through requests ought to be sent to.
> > > > > So,
> > > > > add a variable to struct drm_dp_mst_port that keeps track of the
> > > > > aforementioned information.
> > > > >
> > > > > Signed-off-by: Hamza Mahfooz
> > > > > ---
> > > > > v2: define DP_DSC_PASSTHROUGH_IS_SUPPORTED
> > > > > ---
> > > > >drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +++-
> > > > >include/drm/display/drm_dp.h | 1 +
> > > > >include/drm/display/drm_dp_mst_helper.h | 3 +++
> > > > >3 files changed, 7 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 67b3b9697da7..71915afd9892 100644
> > > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > @@ -5921,8 +5921,10 @@ struct drm_dp_aux
> > > > > *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port)
> > > > > /* Enpoint decompression with DP-to-DP peer device */
> > > > > if ((endpoint_dsc & DP_DSC_DECOMPRESSION_IS_SUPPORTED)
> > > > > &&
> > > > > (endpoint_fec & DP_FEC_CAPABLE) &&
> > > > > - (upstream_dsc & 0x2) /* DSC passthrough */)
> > > > > + (upstream_dsc & DP_DSC_PASSTHROUGH_IS_SUPPORTED)) {
> > > > > + port->passthrough_aux =
> > > > > _upstream_port->aux;
> > > > > return >aux;
> > > > > + }
> > > > >
> > > > > /* Virtual DPCD decompression with DP-to-DP peer device
> > > > > */
> > > > > return _upstream_port->aux;
> > > > > diff --git a/include/drm/display/drm_dp.h
> > > > > b/include/drm/display/drm_dp.h
> > > > > index 9e3aff7e68bb..4d0abe4c7ea9 100644
> > > > > --- a/include/drm/display/drm_dp.h
> > > > > +++ b/include/drm/display/drm_dp.h
> > > > > @@ -239,6 +239,7 @@
> > > > >
> > > > >#define DP_DSC_SUPPORT 0x060 /* DP 1.4 */
> > > > ># define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0)
> > > > > +# define DP_DSC_PASSTHROUGH_IS_SUPPORTED(1 << 1)
> > > > >
> > > > >#define DP_DSC_REV 0x061
> > > > ># define DP_DSC_MAJOR_MASK (0xf << 0)
> > > > > diff --git a/include/drm/display/drm_dp_mst_helper.h
> > > > > b/include/drm/display/drm_dp_mst_helper.h
> > > > > index 10adec068b7f..4a39c95f8afd 100644
> > > > > --- a/include/drm/display/drm_dp_mst_helper.h
> > > > > +++ b/include/drm/display/drm_dp_mst_helper.h
> > > > > @@ -86,6 +86,8 @@ struct drm_dp_vcpi {
> > > > > * @next: link to next port on this branch device
> > > > > * @aux: i2c aux transport to talk to device connected to this
> > > > > port, protected
> > > > > * by _dp_mst_topology_mgr.base.lock.
> > > > > + * @passthrough_aux: parent aux to which DSC pass-through requests
> > > > > should be
> > > > > + * sent, only set if DSC pass-through is possible.
> > > > > * @parent: branch device parent of this port
> > > > > * @vcpi: Virtual Channel Payload info for this port.
> > > > > * @connector: DRM connector this port is connected to. Protected
> > > > > by
> > > > > @@ -140,6 +142,7 @@ struct drm_dp_mst_port {
> > > > >*/
> > > > > struct drm_dp_mst_branch *mstb;
> > > > > struct drm_dp_aux aux; /* i2c bus for this port? */
> > > > > + struct drm_dp_aux *passthrough_aux;
> > > > > struct drm_dp_mst_branch *parent;
> > > > >
> > > > > struct drm_dp_vcpi vcpi;
> > > >
> > >
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH] drm/mediatek: dsi: Add atomic {destroy, duplicate}_state, reset callbacks
On Thu, Jul 21, 2022 at 07:27:27PM +0200, AngeloGioacchino Del Regno wrote:
> Add callbacks for atomic_destroy_state, atomic_duplicate_state and
> atomic_reset to restore functionality of the DSI driver: this solves
> vblank timeouts when another bridge is present in the chain.
>
> Tested bridge chain: DSI <=> ANX7625 => aux-bus panel
>
> Fixes: 7f6335c6a258 ("drm/mediatek: Modify dsi funcs to atomic operations")
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Nícolas F. R. A. Prado
Tested-by: Nícolas F. R. A. Prado
Tested on mt8183-jacuzzi-juniper. As part of enabling IGT tests on that machine
in KernelCI, this regression needs to be fixed. [1]
Thanks,
Nícolas
[1] https://github.com/kernelci/kernelci-core/pull/1059
> ---
>
> Note: The commit that has been mentioned in the Fixes tag should
> *not* have my Reviewed-by tag, as the author changed it but
> erroneously retained the tag that I had released for an
> earlier version of that commit (which was fine, but the new
> version broke mtk_dsi!).
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 9cc406e1eee1..5b624e0f5b0a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -808,10 +808,13 @@ static void mtk_dsi_bridge_atomic_post_disable(struct
> drm_bridge *bridge,
>
> static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
> .attach = mtk_dsi_bridge_attach,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> .atomic_disable = mtk_dsi_bridge_atomic_disable,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_enable = mtk_dsi_bridge_atomic_enable,
> .atomic_pre_enable = mtk_dsi_bridge_atomic_pre_enable,
> .atomic_post_disable = mtk_dsi_bridge_atomic_post_disable,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> .mode_set = mtk_dsi_bridge_mode_set,
> };
>
> --
> 2.35.1
>
>
Re: [PATCH 23/33] drm/vc4: hdmi: Move HDMI reset to pm_resume
Hi Florian,
Am 09.08.22 um 21:02 schrieb Florian Fainelli:
On 8/4/22 16:11, Florian Fainelli wrote:
On 6/13/22 07:47, Maxime Ripard wrote:
From: Dave Stevenson
The BCM2835-37 found in the RaspberryPi 0 to 3 have a power domain
attached to the HDMI block, handled in Linux through runtime_pm.
That power domain is shared with the VEC block, so even if we put our
runtime_pm reference in the HDMI driver it would keep being on. If the
VEC is disabled though, the power domain would be disabled and we would
lose any initialization done in our bind implementation.
That initialization involves calling the reset function and
initializing
the CEC registers.
Let's move the initialization to our runtime_resume implementation so
that we initialize everything properly if we ever need to.
Fixes: c86b41214362 ("drm/vc4: hdmi: Move the HSM clock enable to
runtime_pm")
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
After seeing the same warning as Stefan reported in the link below,
but on the Raspberry Pi 4B:
https://www.spinics.net/lists/dri-devel/msg354170.html
a separate bisection effort led me to this commit, before is fine,
after produces 4 warnings during boot, see attached log.
Is there a fix that we can try that would also cover the Raspberry Pi
4B? Is it possible that this series precipitates the problem:
https://www.spinics.net/lists/arm-kernel/msg984638.html
Maxime, Dave, anything you would want me to try? Still seeing these
warnings with net-next-6.0-11220-g15205c2829ca
At first this issue doesn't occur in Linux 5.19. So it's something new.
I was able to reproduce with todays linux-next, but interestingly it
doesn't occur in drm-misc-next.
Would be nice to see those fixes before 6.0 final, thanks!
Re: [PATCH 0/2] Add DP MST DSC support to i915
Btw, what's the plan for this? Figured I'd ask since I noticed this on the ML, nd I'm now finishing up getting the atomic only MST patches I've been working on merged :) On Wed, 2022-08-10 at 11:17 +0300, Stanislav Lisovskiy wrote: > Currently we have only DSC support for DP SST. > > Stanislav Lisovskiy (2): > drm: Add missing DP DSC extended capability definitions. > drm/i915: Add DSC support to MST path > > drivers/gpu/drm/i915/display/intel_dp.c | 76 +- > drivers/gpu/drm/i915/display/intel_dp.h | 17 +++ > drivers/gpu/drm/i915/display/intel_dp_mst.c | 145 > include/drm/display/drm_dp.h| 10 +- > 4 files changed, 203 insertions(+), 45 deletions(-) > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH] drm:pl111: Add of_node_put() when breaking out of for_each_available_child_of_node()
On Wed, Aug 10, 2022 at 10:37 AM Daniel Vetter wrote:
>
> On Mon, Jul 11, 2022 at 09:15:50PM +0800, Liang He wrote:
> > The reference 'child' in the iteration of for_each_available_child_of_node()
> > is only escaped out into a local variable which is only used to check
> > its value. So we still need to the of_node_put() when breaking of the
> > for_each_available_child_of_node() which will automatically increase
> > and decrease the refcount.
> >
> > Fixes: ca454bd42dc2 ("drm/pl111: Support the Versatile Express")
> > Signed-off-by: Liang He
> > ---
> >
> > As 'Check-after-Put' has been widely accepted in kernel source, we just
> > use it. If the maintainer thinks it is harmful, I'd like also to use
> > 'Check-and-Put' coding style but with a bit more work.
> >
> > drivers/gpu/drm/pl111/pl111_versatile.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
> > b/drivers/gpu/drm/pl111/pl111_versatile.c
> > index bdd883f4f0da..963a5d5e6987 100644
> > --- a/drivers/gpu/drm/pl111/pl111_versatile.c
> > +++ b/drivers/gpu/drm/pl111/pl111_versatile.c
> > @@ -402,6 +402,7 @@ static int pl111_vexpress_clcd_init(struct device *dev,
> > struct device_node *np,
> > if (of_device_is_compatible(child, "arm,pl111")) {
> > has_coretile_clcd = true;
> > ct_clcd = child;
> > + of_node_put(child);
>
> The same issue seems to exist right below in the next break? Can you pls
> respin with that included?
It has a put already.
Reviewed-by: Rob Herring
Re: [PATCH 3/4] drm/modes: Add initializer macro DRM_MODE_INIT()
On Wed, Aug 10, 2022 at 01:20:52PM +0200, Thomas Zimmermann wrote:
> The macro DRM_MODE_INIT() initializes an instance of
> struct drm_display_mode with typical parameters. Convert simpledrm
> and also update the macro DRM_SIMPLE_MODE().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
It is nice that the macros are now documented.
Sam
> ---
> drivers/gpu/drm/tiny/simpledrm.c | 23 -
> include/drm/drm_modes.h | 35 +++-
> 2 files changed, 39 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/tiny/simpledrm.c
> b/drivers/gpu/drm/tiny/simpledrm.c
> index 31d3bc6c5acf..cc509154b296 100644
> --- a/drivers/gpu/drm/tiny/simpledrm.c
> +++ b/drivers/gpu/drm/tiny/simpledrm.c
> @@ -30,16 +30,6 @@
> #define DRIVER_MAJOR 1
> #define DRIVER_MINOR 0
>
> -/*
> - * Assume a monitor resolution of 96 dpi to
> - * get a somewhat reasonable screen size.
> - */
> -#define RES_MM(d)\
> - (((d) * 254ul) / (96ul * 10ul))
> -
> -#define SIMPLEDRM_MODE(hd, vd) \
> - DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
> -
> /*
> * Helpers for simplefb
> */
> @@ -641,10 +631,15 @@ static const struct drm_mode_config_funcs
> simpledrm_mode_config_funcs = {
> static struct drm_display_mode simpledrm_mode(unsigned int width,
> unsigned int height)
> {
> - struct drm_display_mode mode = { SIMPLEDRM_MODE(width, height) };
> -
> - mode.clock = mode.hdisplay * mode.vdisplay * 60 / 1000 /* kHz */;
> - drm_mode_set_name();
> + /*
> + * Assume a monitor resolution of 96 dpi to
> + * get a somewhat reasonable screen size.
> + */
> + const struct drm_display_mode mode = {
> + DRM_MODE_INIT(60, width, height,
> + DRM_MODE_RES_MM(width, 96ul),
> + DRM_MODE_RES_MM(height, 96ul))
> + };
>
> return mode;
> }
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index a80ae9639e96..bb932806f029 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -138,6 +138,35 @@ enum drm_mode_status {
> .vsync_start = (vss), .vsync_end = (vse), .vtotal = (vt), \
> .vscan = (vs), .flags = (f)
>
> +/**
> + * DRM_MODE_RES_MM - Calculates the display size from resolution and DPI
> + * @res: The resolution in pixel
> + * @dpi: The number of dots per inch
> + */
> +#define DRM_MODE_RES_MM(res, dpi)\
> + (((res) * 254ul) / ((dpi) * 10ul))
> +
> +#define __DRM_MODE_INIT(pix, hd, vd, hd_mm, vd_mm) \
> + .type = DRM_MODE_TYPE_DRIVER, .clock = (pix), \
> + .hdisplay = (hd), .hsync_start = (hd), .hsync_end = (hd), \
> + .htotal = (hd), .vdisplay = (vd), .vsync_start = (vd), \
> + .vsync_end = (vd), .vtotal = (vd), .width_mm = (hd_mm), \
> + .height_mm = (vd_mm)
> +
> +/**
> + * DRM_SIMPLE_MODE_INIT - Initialize display mode
> + * @hz: Vertical refresh rate in Hertz
> + * @hd: Horizontal resolution, width
> + * @vd: Vertical resolution, height
> + * @hd_mm: Display width in millimeters
> + * @vd_mm: Display height in millimeters
> + *
> + * This macro initializes a _display_mode that contains information about
> + * refresh rate, resolution and physical size.
> + */
> +#define DRM_MODE_INIT(hz, hd, vd, hd_mm, vd_mm) \
> + __DRM_MODE_INIT((hd) * (vd) * (hz) / 1000 /* kHz */, hd, vd, hd_mm,
> vd_mm)
> +
> /**
> * DRM_SIMPLE_MODE - Simple display mode
> * @hd: Horizontal resolution, width
> @@ -149,11 +178,7 @@ enum drm_mode_status {
> * resolution and physical size.
> */
> #define DRM_SIMPLE_MODE(hd, vd, hd_mm, vd_mm) \
> - .type = DRM_MODE_TYPE_DRIVER, .clock = 1 /* pass validation */, \
> - .hdisplay = (hd), .hsync_start = (hd), .hsync_end = (hd), \
> - .htotal = (hd), .vdisplay = (vd), .vsync_start = (vd), \
> - .vsync_end = (vd), .vtotal = (vd), .width_mm = (hd_mm), \
> - .height_mm = (vd_mm)
> + __DRM_MODE_INIT(1 /* pass validation */, hd, vd, hd_mm, vd_mm)
>
> #define CRTC_INTERLACE_HALVE_V (1 << 0) /* halve V values for
> interlacing */
> #define CRTC_STEREO_DOUBLE (1 << 1) /* adjust timings for stereo modes */
> --
> 2.37.1
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
On 8/10/22 14:47, Daniel Vetter wrote: > Dmitry, since you have a bunch of patches merged now I think would also be > good to get commit rights so you can drive this more yourself. I've asked > Daniel Stone to help you out with getting that. > -Daniel Thank you! -- Best regards, Dmitry
Re: [PATCH 2/4] drm/probe-helper: Add drm_crtc_helper_mode_valid_static()
Hi Thomas,
On Wed, Aug 10, 2022 at 01:20:51PM +0200, Thomas Zimmermann wrote:
> Add drm_crtc_helper_mode_valid_static(), which validates a given mode
> against a display hardware's mode. Convert simpledrm and use it in a
> few other drivers with static modes.
>
> Signed-off-by: Thomas Zimmermann
With the header file fixed,
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 18 ++
> drivers/gpu/drm/drm_probe_helper.c | 25
> drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1 +
> drivers/gpu/drm/tiny/hx8357d.c | 1 +
> drivers/gpu/drm/tiny/ili9163.c | 1 +
> drivers/gpu/drm/tiny/ili9341.c | 1 +
> drivers/gpu/drm/tiny/ili9486.c | 1 +
> drivers/gpu/drm/tiny/mi0283qt.c | 1 +
> drivers/gpu/drm/tiny/panel-mipi-dbi.c| 1 +
> drivers/gpu/drm/tiny/repaper.c | 10
> drivers/gpu/drm/tiny/simpledrm.c | 10 +---
> drivers/gpu/drm/tiny/st7735r.c | 1 +
> include/drm/drm_mipi_dbi.h | 2 ++
> include/drm/drm_probe_helper.h | 8 +--
> 14 files changed, 70 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index b67ec9a5cda9..d544a99df9df 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -309,6 +309,24 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer
> *fb, struct drm_rect *rect)
> drm_dev_exit(idx);
> }
>
> +/**
> + * mipi_dbi_pipe_mode_valid - MIPI DBI mode-valid helper
> + * @pipe: Simple display pipe
> + * @mode: The mode to test
> + *
> + * This function validates a given display mode against the MIPI DBI's
> hardware
> + * display. Drivers can use this as their
> _simple_display_pipe_funcs->mode_valid
> + * callback.
> + */
> +enum drm_mode_status mipi_dbi_pipe_mode_valid(struct drm_simple_display_pipe
> *pipe,
> + const struct drm_display_mode
> *mode)
> +{
> + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
> +
> + return drm_crtc_helper_mode_valid_static(>crtc, mode,
> >mode);
> +}
> +EXPORT_SYMBOL(mipi_dbi_pipe_mode_valid);
> +
> /**
> * mipi_dbi_pipe_update - Display pipe update helper
> * @pipe: Simple display pipe
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 809187377e4e..bc3876853fca 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -1014,6 +1014,31 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
> }
> EXPORT_SYMBOL(drm_helper_hpd_irq_event);
>
> +/**
> + * drm_crtc_helper_mode_valid_static - Validates a display mode
> + * @crtc: the crtc
> + * @mode: the mode to validate
> + * @hw_mode: the display hardware's mode
> + *
> + * Returns:
> + * MODE_OK on success, or another mode-status code otherwise.
> + */
> +enum drm_mode_status drm_crtc_helper_mode_valid_static(struct drm_crtc *crtc,
> +const struct
> drm_display_mode *mode,
> +const struct
> drm_display_mode *hw_mode)
> +{
> +
> + if (mode->hdisplay != hw_mode->hdisplay && mode->vdisplay !=
> hw_mode->vdisplay)
> + return MODE_ONE_SIZE;
> + else if (mode->hdisplay != hw_mode->hdisplay)
> + return MODE_ONE_WIDTH;
> + else if (mode->vdisplay != hw_mode->vdisplay)
> + return MODE_ONE_HEIGHT;
> +
> + return MODE_OK;
> +}
> +EXPORT_SYMBOL(drm_crtc_helper_mode_valid_static);
> +
> /**
> * drm_connector_helper_get_modes_from_ddc - Updates the connector's EDID
> * property from the connector's
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> index 7da09e34385d..39dc40cf681f 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> @@ -576,6 +576,7 @@ static void ili9341_dbi_enable(struct
> drm_simple_display_pipe *pipe,
> }
>
> static const struct drm_simple_display_pipe_funcs ili9341_dbi_funcs = {
> + .mode_valid = mipi_dbi_pipe_mode_valid,
> .enable = ili9341_dbi_enable,
> .disable = mipi_dbi_pipe_disable,
> .update = mipi_dbi_pipe_update,
> diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
> index 57f229a785bf..48c24aa8c28a 100644
> --- a/drivers/gpu/drm/tiny/hx8357d.c
> +++ b/drivers/gpu/drm/tiny/hx8357d.c
> @@ -181,6 +181,7 @@ static void yx240qv29_enable(struct
> drm_simple_display_pipe *pipe,
> }
>
> static const struct drm_simple_display_pipe_funcs hx8357d_pipe_funcs = {
> + .mode_valid = mipi_dbi_pipe_mode_valid,
> .enable = yx240qv29_enable,
> .disable = mipi_dbi_pipe_disable,
> .update =
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
On 8/10/22 18:08, Rob Clark wrote:
> On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter wrote:
>>
>> On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote:
>>> On 7/6/22 00:48, Rob Clark wrote:
On Tue, Jul 5, 2022 at 4:51 AM Christian König
wrote:
>
> Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
>> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
>> handle imported dma-bufs properly, which results in mapping of something
>> else than the imported dma-buf. On NVIDIA Tegra we get a hard lockup when
>> userspace writes to the memory mapping of a dma-buf that was imported
>> into
>> Tegra's DRM GEM.
>>
>> Majority of DRM drivers prohibit mapping of the imported GEM objects.
>> Mapping of imported GEMs require special care from userspace since it
>> should sync dma-buf because mapping coherency of the exporter device may
>> not match the DRM device. Let's prohibit the mapping for all DRM drivers
>> for consistency.
>>
>> Suggested-by: Thomas Hellström
>> Signed-off-by: Dmitry Osipenko
>
> I'm pretty sure that this is the right approach, but it's certainly more
> than possible that somebody abused this already.
I suspect that this is abused if you run deqp cts on android.. ie. all
winsys buffers are dma-buf imports from gralloc. And then when you
hit readpix...
You might only hit this in scenarios with separate gpu and display (or
dGPU+iGPU) because self-imports are handled differently in
drm_gem_prime_import_dev().. and maybe not in cases where you end up
with a blit from tiled/compressed to linear.. maybe that narrows the
scope enough to just fix it in userspace?
>>>
>>> Given that that only drivers which use DRM-SHMEM potentially could've
>>> map imported dma-bufs (Panfrost, Lima) and they already don't allow to
>>> do that, I think we're good.
>>
>> So can I have an ack from Rob here or are there still questions that this
>> might go boom?
>>
>> Dmitry, since you have a bunch of patches merged now I think would also be
>> good to get commit rights so you can drive this more yourself. I've asked
>> Daniel Stone to help you out with getting that.
>
> I *think* we'd be ok with this on msm, mostly just by dumb luck.
> Because the dma-buf's we import will be self-import. I'm less sure
> about panfrost (src/panfrost/lib/pan_bo.c doesn't seem to have a
> special path for imported dma-bufs either, and in that case they won't
> be self-imports.. but I guess no one has tried to run android cts on
> panfrost).
The last time I tried to mmap dma-buf imported to Panfrost didn't work
because Panfrost didn't implement something needed for that. I'll need
to take a look again because can't recall what it was.
> What about something less drastic to start, like (apologies for
> hand-edited patch):
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 86d670c71286..fc9ec42fa0ab 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object
> *obj, unsigned long obj_size,
> {
> int ret;
>
> + WARN_ON_ONCE(obj->import_attach);
This will hang NVIDIA Tegra, which is what this patch fixed initially.
If neither of upstream DRM drivers need to map imported dma-bufs and
never needed, then why do we need this?
--
Best regards,
Dmitry
[PATCH v3] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
dp_bridge_disable() is the first step toward tearing down main link.
Its major function is to start transmitting idle pattern to replace
video stream. This patch will check hpd_state to make sure main link
is enabled before commit changes of main link's configuration to
push idle pattern out to avoid system crashing due to main link clock
is disabled while access main link registers.
SError Interrupt on CPU7, code 0xbe000411 -- SError
CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19
Hardware name: Google Lazor (rev3 - 8) (DT)
pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __cmpxchg_case_acq_32+0x14/0x2c
lr : do_raw_spin_lock+0xa4/0xdc
sp : ffc01092b6a0
x29: ffc01092b6a0 x28: 0028 x27: 0038
x26: 0004 x25: ffd2973dce48 x24:
x23: x22: x21: ffd2978d0008
x20: ffd2978d0008 x19: ff80ff759fc0 x18:
x17: 004800a501260460 x16: 0441043b04600438 x15: 0438089807d0
x14: 07b0089807800780 x13: x12:
x11: 0438 x10: 07d0 x9 : ffd2973e09e4
x8 : ff8092d53300 x7 : ff808902e8b8 x6 : 0001
x5 : ff808902e880 x4 : x3 : ff80ff759fc0
x2 : 0001 x1 : x0 : ff80ff759fc0
Kernel panic - not syncing: Asynchronous SError Interrupt
CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19
Hardware name: Google Lazor (rev3 - 8) (DT)
Call trace:
dump_backtrace.part.0+0xbc/0xe4
show_stack+0x24/0x70
dump_stack_lvl+0x68/0x84
dump_stack+0x18/0x34
panic+0x14c/0x32c
nmi_panic+0x58/0x7c
arm64_serror_panic+0x78/0x84
do_serror+0x40/0x64
el1h_64_error_handler+0x30/0x48
el1h_64_error+0x68/0x6c
__cmpxchg_case_acq_32+0x14/0x2c
_raw_spin_lock_irqsave+0x38/0x4c
lock_timer_base+0x40/0x78
__mod_timer+0xf4/0x25c
schedule_timeout+0xd4/0xfc
__wait_for_common+0xac/0x140
wait_for_completion_timeout+0x2c/0x54
dp_ctrl_push_idle+0x40/0x88
dp_bridge_disable+0x24/0x30
drm_atomic_bridge_chain_disable+0x90/0xbc
drm_atomic_helper_commit_modeset_disables+0x198/0x444
msm_atomic_commit_tail+0x1d0/0x374
commit_tail+0x80/0x108
drm_atomic_helper_commit+0x118/0x11c
drm_atomic_commit+0xb4/0xe0
drm_client_modeset_commit_atomic+0x184/0x224
drm_client_modeset_commit_locked+0x58/0x160
drm_client_modeset_commit+0x3c/0x64
__drm_fb_helper_restore_fbdev_mode_unlocked+0x98/0xac
drm_fb_helper_set_par+0x74/0x80
drm_fb_helper_hotplug_event+0xdc/0xe0
__drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xac
drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x2c
drm_fb_helper_lastclose+0x20/0x2c
drm_lastclose+0x44/0x6c
drm_release+0x88/0xd4
__fput+0x104/0x220
fput+0x1c/0x28
task_work_run+0x8c/0x100
do_exit+0x450/0x8d0
do_group_exit+0x40/0xac
__wake_up_parent+0x0/0x38
invoke_syscall+0x84/0x11c
el0_svc_common.constprop.0+0xb8/0xe4
do_el0_svc+0x8c/0xb8
el0_svc+0x2c/0x54
el0t_64_sync_handler+0x120/0x1c0
el0t_64_sync+0x190/0x194
SMP: stopping secondary CPUs
Kernel Offset: 0x128e80 from 0xffc00800
PHYS_OFFSET: 0x8000
CPU features: 0x800,00c2a015,19801c82
Memory Limit: none
Changes in v3:
-- correct Reported-by
-- add call stack trace
Changes in v2:
-- changes Fixes patch
-- fix eported-by
-- add Closes tag
Fixes: 375a126090b9 ("drm/msm/dp: tear down main link at unplug handle
immediately")
Reported-by: Leonard Lausen
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/17
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index b36f8b6..678289a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1729,10 +1729,20 @@ void dp_bridge_disable(struct drm_bridge *drm_bridge)
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
struct dp_display_private *dp_display;
+ u32 state;
dp_display = container_of(dp, struct dp_display_private, dp_display);
+ mutex_lock(_display->event_mutex);
+
+ state = dp_display->hpd_state;
+ if (state != ST_DISCONNECT_PENDING && state != ST_CONNECTED) {
+ mutex_unlock(_display->event_mutex);
+ return;
+ }
+
dp_ctrl_push_idle(dp_display->ctrl);
+ mutex_unlock(_display->event_mutex);
}
void dp_bridge_post_disable(struct drm_bridge *drm_bridge)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 1/4] drm/probe-helper: Add drm_connector_helper_get_modes_static()
Hi Thomas,
On Wed, Aug 10, 2022 at 01:20:50PM +0200, Thomas Zimmermann wrote:
> Add drm_connector_helper_get_modes_static(), which duplicates a single
> display mode for a connector. Convert drivers.
I like this helper!
There are a lot of panels that can benefit from the same helper.
The current users that are replaced do not do so, but some panels also
set:
connector->display_info.bpc = 8;
connector->display_info.bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE;
drm_display_info_set_bus_formats(>display_info, _format,
1);
I looked at a similar helper for panels once, but for panels I stopped
there as we then had to pass bpc, bus_format and bus_mode as arguments.
Maybe that is over-engineering things.
Someone that knows when we must pass bpc, bus_mode, bus_flags and when
not can maybe help here.
The current helper is fine as is, but I wonder if we can cover more
use cases with an extra helper.
It would also be nice to convert the panels that can use the new helper,
but that should be in a new patch and can be done later.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
but I have a few comments in the following.
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 20 +--
> drivers/gpu/drm/drm_probe_helper.c | 40 ++
> drivers/gpu/drm/tiny/repaper.c | 16 +---
> drivers/gpu/drm/tiny/simpledrm.c | 18 +-
> include/drm/drm_probe_helper.h | 3 +++
> 5 files changed, 46 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 84abc3920b57..b67ec9a5cda9 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -415,26 +415,8 @@ EXPORT_SYMBOL(mipi_dbi_pipe_disable);
> static int mipi_dbi_connector_get_modes(struct drm_connector *connector)
> {
> struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(connector->dev);
> - struct drm_display_mode *mode;
>
> - mode = drm_mode_duplicate(connector->dev, >mode);
> - if (!mode) {
> - DRM_ERROR("Failed to duplicate mode\n");
> - return 0;
> - }
> -
> - if (mode->name[0] == '\0')
> - drm_mode_set_name(mode);
> -
> - mode->type |= DRM_MODE_TYPE_PREFERRED;
> - drm_mode_probed_add(connector, mode);
> -
> - if (mode->width_mm) {
> - connector->display_info.width_mm = mode->width_mm;
> - connector->display_info.height_mm = mode->height_mm;
> - }
> -
> - return 1;
> + return drm_connector_helper_get_modes_static(connector, >mode);
> }
>
> static const struct drm_connector_helper_funcs mipi_dbi_connector_hfuncs = {
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index bb427c5a4f1f..809187377e4e 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -1050,6 +1050,46 @@ int drm_connector_helper_get_modes_from_ddc(struct
> drm_connector *connector)
> }
> EXPORT_SYMBOL(drm_connector_helper_get_modes_from_ddc);
>
> +/**
> + * drm_connector_helper_get_modes_static - Duplicates a display mode for a
> connector
The hw mode is duplicated so maybe name it ..._modes_hw()?
But I dunno.. Naming is hard.
> + * @connector: the connector
> + * @hw_mode: the display hardware's mode
> + *
> + * This function duplicates a display modes for a connector. Drivers for
> hardware
> + * that only supports a single mode can use this function in there
> connector's
their?
> + * get_modes helper.
> + *
> + * Returns:
> + * The number of created modes.
> + */
> +int drm_connector_helper_get_modes_static(struct drm_connector *connector,
> + const struct drm_display_mode
> *hw_mode)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(dev, hw_mode);
> + if (!mode) {
> + drm_err(dev, "Failed to duplicate mode " DRM_MODE_FMT "\n",
> + DRM_MODE_ARG(hw_mode));
> + return 0;
> + }
> +
> + if (mode->name[0] == '\0')
> + drm_mode_set_name(mode);
Hmm, so we rely that it was set to something relevant before. I guess
that's OK.
> +
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> + drm_mode_probed_add(connector, mode);
> +
> + if (mode->width_mm)
> + connector->display_info.width_mm = mode->width_mm;
> + if (mode->height_mm)
> + connector->display_info.height_mm = mode->height_mm;
> +
> + return 1;
> +}
> +EXPORT_SYMBOL(drm_connector_helper_get_modes_static);
> +
> /**
> * drm_connector_helper_get_modes - Read EDID and update connector.
> * @connector: The connector
> diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c
> index c4c1be3ac0b8..855968fd46af 100644
> ---
Re: [PATCH 1/7] dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles
On Wed, Aug 10, 2022 at 05:47:52PM +0300, Krzysztof Kozlowski wrote: > On 10/08/2022 06:50, Bjorn Andersson wrote: > > Add compatibles for the DisplayPort and Embedded DisplayPort blocks in > > Qualcomm SDM845 and SC8280XP platforms. > > > > Signed-off-by: Bjorn Andersson > > --- > > .../devicetree/bindings/display/msm/dp-controller.yaml | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > index 94bc6e1b6451..90f9302d1731 100644 > > --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > @@ -16,11 +16,14 @@ description: | > > properties: > >compatible: > > enum: > > + - qcom,sdm845-dp > >- qcom,sc7180-dp > > Alphabetical order, please. > > The DTS warnings from the bot look unrelated to this patch. Yes, but there are a ton of them and I thought Bjorn might care. Looks like the schema is pretty out of sync with reality and they don't really look like dts side fixes. Rob
Re: [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification
On 8/10/22 21:25, Christian König wrote: > Am 10.08.22 um 19:49 schrieb Dmitry Osipenko: >> On 8/10/22 14:30, Christian König wrote: >>> Am 25.07.22 um 17:18 schrieb Dmitry Osipenko: This patch moves the non-dynamic dma-buf users over to the dynamic locking specification. The strict locking convention prevents deadlock situation for dma-buf importers and exporters. Previously the "unlocked" versions of the dma-buf API functions weren't taking the reservation lock and this patch makes them to take the lock. Intel and AMD GPU drivers already were mapping imported dma-bufs under the held lock, hence the "locked" variant of the functions are added for them and the drivers are updated to use the "locked" versions. >>> In general "Yes, please", but that won't be that easy. >>> >>> You not only need to change amdgpu and i915, but all drivers >>> implementing the map_dma_buf(), unmap_dma_buf() callbacks. >>> >>> Auditing all that code is a huge bunch of work. >> Hm, neither of drivers take the resv lock in map_dma_buf/unmap_dma_buf. >> It's easy to audit them all and I did it. So either I'm missing >> something or it doesn't take much time to check them all. Am I really >> missing something? > > Ok, so this is only changing map/unmap now? It also vmap/vunmap and attach/detach: In the previous patch I added the _unlocked postfix to the func names and in this patch I made them all to actually take the lock. > In this case please separate this from the documentation change. I'll factor out the doc in the v3. > I would also drop the _locked postfix from the function name, just > having _unlocked on all functions which are supposed to be called with > the lock held should be sufficient. Noted for the v3. > Thanks for looking into this, > Christian. Thank you for the review. -- Best regards, Dmitry
[Bug 215618] vblank related lockup during start of SteamVR using Valve Index HMD
https://bugzilla.kernel.org/show_bug.cgi?id=215618 --- Comment #4 from farmb...@googlemail.com --- The issue still happens with 5.18.9. The issue has also been reported to mesa and someone bisected it to the following commit: https://gitlab.freedesktop.org/drm/amd/-/issues/1980#note_1400657 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification
Am 10.08.22 um 19:49 schrieb Dmitry Osipenko: On 8/10/22 14:30, Christian König wrote: Am 25.07.22 um 17:18 schrieb Dmitry Osipenko: This patch moves the non-dynamic dma-buf users over to the dynamic locking specification. The strict locking convention prevents deadlock situation for dma-buf importers and exporters. Previously the "unlocked" versions of the dma-buf API functions weren't taking the reservation lock and this patch makes them to take the lock. Intel and AMD GPU drivers already were mapping imported dma-bufs under the held lock, hence the "locked" variant of the functions are added for them and the drivers are updated to use the "locked" versions. In general "Yes, please", but that won't be that easy. You not only need to change amdgpu and i915, but all drivers implementing the map_dma_buf(), unmap_dma_buf() callbacks. Auditing all that code is a huge bunch of work. Hm, neither of drivers take the resv lock in map_dma_buf/unmap_dma_buf. It's easy to audit them all and I did it. So either I'm missing something or it doesn't take much time to check them all. Am I really missing something? Ok, so this is only changing map/unmap now? In this case please separate this from the documentation change. I would also drop the _locked postfix from the function name, just having _unlocked on all functions which are supposed to be called with the lock held should be sufficient. Thanks for looking into this, Christian. https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2FA%2Fident%2Fmap_dma_bufdata=05%7C01%7Cchristian.koenig%40amd.com%7C70fd52d0a82a477bfbfe08da7af8bec7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637957506041914442%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=K47uCULsoiURjze0H0ksUa4vzJ%2BxqgoShH9106FvyyA%3Dreserved=0
Re: [PATCH v5] drm: Add initial ci/ subdirectory
Hi Tomeu,
First of all, nice patch! I just saw it, and I have some basic questions
(I don't understand many of these CI details). I also CC some CI folks
from the display team at AMD.
On 2022-07-26 14:16, Tomeu Vizoso wrote:
And use it to store expectations about what the DRM drivers are
supposed to pass in the IGT test suite.
Also include a configuration file that points to the out-of-tree CI
scripts.
By storing the test expectations along the code we can make sure both
stay in sync with each other, and so we can know when a code change
breaks those expectations.
This will allow all contributors to drm to reuse the infrastructure
already in gitlab.freedesktop.org to test the driver on several
generations of the hardware.
v2:
- Fix names of result expectation files to match SoC
- Don't execute tests that are going to skip on all boards
v3:
- Remove tracking of dmesg output during test execution
v4:
- Move up to drivers/gpu/drm
- Add support for a bunch of other drivers
- Explain how to incorporate fixes for CI from a
${TARGET_BRANCH}-external-fixes branch
- Remove tests that pass from expected results file, to reduce the
size of in-tree files
- Add docs about how to deal with outages in automated testing labs
- Specify the exact SHA of the CI scripts to be used
v5:
- Remove unneeded skips from Meson expectations file
- Use a more advanced runner that detects flakes automatically
- Use a more succint format for the expectations
- Run many more tests (and use sharding to finish in time)
- Use skip lists to avoid hanging machines
- Add some build testing
- Build IGT in each pipeline for faster uprevs
- List failures in the GitLab UI
Signed-off-by: Tomeu Vizoso
Reviewed-by: Neil Armstrong
---
Documentation/gpu/automated_testing.rst | 84 ++
drivers/gpu/drm/ci/amdgpu-stoney-fails.txt| 13 +++
drivers/gpu/drm/ci/amdgpu-stoney-flakes.txt | 20 +
drivers/gpu/drm/ci/amdgpu-stoney-skips.txt| 2 +
drivers/gpu/drm/ci/gitlab-ci.yml | 13 +++
drivers/gpu/drm/ci/i915-amly-flakes.txt | 32 +++
drivers/gpu/drm/ci/i915-amly-skips.txt| 2 +
drivers/gpu/drm/ci/i915-apl-fails.txt | 29 +++
drivers/gpu/drm/ci/i915-apl-flakes.txt| 1 +
drivers/gpu/drm/ci/i915-apl-skips.txt | 2 +
drivers/gpu/drm/ci/i915-cml-flakes.txt| 36
drivers/gpu/drm/ci/i915-glk-flakes.txt| 40 +
drivers/gpu/drm/ci/i915-glk-skips.txt | 2 +
drivers/gpu/drm/ci/i915-kbl-fails.txt | 8 ++
drivers/gpu/drm/ci/i915-kbl-flakes.txt| 24 ++
drivers/gpu/drm/ci/i915-kbl-skips.txt | 2 +
drivers/gpu/drm/ci/i915-tgl-fails.txt | 19
drivers/gpu/drm/ci/i915-tgl-flakes.txt| 6 ++
drivers/gpu/drm/ci/i915-tgl-skips.txt | 8 ++
drivers/gpu/drm/ci/i915-whl-fails.txt | 30 +++
drivers/gpu/drm/ci/i915-whl-flakes.txt| 1 +
drivers/gpu/drm/ci/mediatek-mt8173-fails.txt | 29 +++
drivers/gpu/drm/ci/mediatek-mt8183-fails.txt | 10 +++
drivers/gpu/drm/ci/mediatek-mt8183-flakes.txt | 14 +++
drivers/gpu/drm/ci/meson-g12b-fails.txt | 5 ++
drivers/gpu/drm/ci/meson-g12b-flakes.txt | 4 +
drivers/gpu/drm/ci/msm-apq8016-fails.txt | 15
drivers/gpu/drm/ci/msm-apq8016-flakes.txt | 4 +
drivers/gpu/drm/ci/msm-apq8096-fails.txt | 2 +
drivers/gpu/drm/ci/msm-apq8096-flakes.txt | 4 +
drivers/gpu/drm/ci/msm-apq8096-skips.txt | 2 +
drivers/gpu/drm/ci/msm-sc7180-fails.txt | 22 +
drivers/gpu/drm/ci/msm-sc7180-flakes.txt | 14 +++
drivers/gpu/drm/ci/msm-sc7180-skips.txt | 18
drivers/gpu/drm/ci/msm-sdm845-fails.txt | 44 ++
drivers/gpu/drm/ci/msm-sdm845-flakes.txt | 33 +++
drivers/gpu/drm/ci/msm-sdm845-skips.txt | 2 +
drivers/gpu/drm/ci/rockchip-rk3288-fails.txt | 75
drivers/gpu/drm/ci/rockchip-rk3288-flakes.txt | 5 ++
drivers/gpu/drm/ci/rockchip-rk3288-skips.txt | 46 ++
drivers/gpu/drm/ci/rockchip-rk3399-fails.txt | 86 +++
drivers/gpu/drm/ci/rockchip-rk3399-flakes.txt | 25 ++
drivers/gpu/drm/ci/rockchip-rk3399-skips.txt | 5 ++
drivers/gpu/drm/ci/virtio_gpu-none-fails.txt | 38
drivers/gpu/drm/ci/virtio_gpu-none-flakes.txt | 0
drivers/gpu/drm/ci/virtio_gpu-none-skips.txt | 6 ++
46 files changed, 882 insertions(+)
create mode 100644 Documentation/gpu/automated_testing.rst
create mode 100644 drivers/gpu/drm/ci/amdgpu-stoney-fails.txt
create mode 100644 drivers/gpu/drm/ci/amdgpu-stoney-flakes.txt
create mode 100644 drivers/gpu/drm/ci/amdgpu-stoney-skips.txt
create mode 100644 drivers/gpu/drm/ci/gitlab-ci.yml
create mode 100644 drivers/gpu/drm/ci/i915-amly-flakes.txt
create mode 100644 drivers/gpu/drm/ci/i915-amly-skips.txt
create mode 100644
Re: [PATCH v2] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
On 8/10/2022 10:22 AM, Kuogee Hsieh wrote:
dp_bridge_disable() is the first step toward tearing down main link.
Its major function is to start transmitting idle pattern to replace
video stream. This patch will check hpd_state to make sure main link
is enabled before commit changes of main link's configuration to
push idle pattern out to avoid system crashing due to main link clock
is disabled while access main link registers.
Do you also want to give the full stack of unclocked access here?
Changes in v2:
-- changes Fixes patch
-- fix eported-by
-- add Closes tag
Fixes: 375a126090b9 ("drm/msm/dp: tear down main link at unplug handle
immediately")
Reported-by: leon...@lausen.nl
This is still incorrect. Should be:
Reported-by: Leonard Lausen
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/17
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index b36f8b6..678289a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1729,10 +1729,20 @@ void dp_bridge_disable(struct drm_bridge *drm_bridge)
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
struct dp_display_private *dp_display;
+ u32 state;
dp_display = container_of(dp, struct dp_display_private, dp_display);
+ mutex_lock(_display->event_mutex);
+
+ state = dp_display->hpd_state;
+ if (state != ST_DISCONNECT_PENDING && state != ST_CONNECTED) {
+ mutex_unlock(_display->event_mutex);
+ return;
+ }
+
dp_ctrl_push_idle(dp_display->ctrl);
+ mutex_unlock(_display->event_mutex);
}
void dp_bridge_post_disable(struct drm_bridge *drm_bridge)
Re: [PATCH v2 1/3] media: vsp1: add premultiplied alpha support
Hello! On 8/10/22 11:37 AM, Takanari Hayama wrote: > To support DRM blend mode in R-Car DU driver, we must be able to pass > a plane with the premultiplied alpha. Adding a new property to > vsp1_du_atomic_config allows the R-Car DU driver to pass the > premultiplied alpha plane. > > Signed-off-by: Takanari Hayama > --- > drivers/media/platform/renesas/vsp1/vsp1_drm.c | 2 ++ > include/media/vsp1.h | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drm.c > b/drivers/media/platform/renesas/vsp1/vsp1_drm.c > index 0c2507dc03d6..019e18976bd8 100644 > --- a/drivers/media/platform/renesas/vsp1/vsp1_drm.c > +++ b/drivers/media/platform/renesas/vsp1/vsp1_drm.c > @@ -856,6 +856,8 @@ int vsp1_du_atomic_update(struct device *dev, unsigned > int pipe_index, > rpf->mem.addr[1] = cfg->mem[1]; > rpf->mem.addr[2] = cfg->mem[2]; > > + rpf->format.flags = (cfg->premult) ? V4L2_PIX_FMT_FLAG_PREMUL_ALPHA : 0; > + Parens are hardly needed here... :-) [...] MBR, Sergey
Re: [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification
On 8/10/22 14:30, Christian König wrote: >> + * - dma_buf_move_notify() > > This one is called by the exporter, not the importer. Good catch, thank you! -- Best regards, Dmitry
Re: [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification
On 8/10/22 14:30, Christian König wrote: > Am 25.07.22 um 17:18 schrieb Dmitry Osipenko: >> This patch moves the non-dynamic dma-buf users over to the dynamic >> locking specification. The strict locking convention prevents deadlock >> situation for dma-buf importers and exporters. >> >> Previously the "unlocked" versions of the dma-buf API functions weren't >> taking the reservation lock and this patch makes them to take the lock. >> >> Intel and AMD GPU drivers already were mapping imported dma-bufs under >> the held lock, hence the "locked" variant of the functions are added >> for them and the drivers are updated to use the "locked" versions. > > In general "Yes, please", but that won't be that easy. > > You not only need to change amdgpu and i915, but all drivers > implementing the map_dma_buf(), unmap_dma_buf() callbacks. > > Auditing all that code is a huge bunch of work. Hm, neither of drivers take the resv lock in map_dma_buf/unmap_dma_buf. It's easy to audit them all and I did it. So either I'm missing something or it doesn't take much time to check them all. Am I really missing something? https://elixir.bootlin.com/linux/latest/A/ident/map_dma_buf -- Best regards, Dmitry
Re: [PATCH 1/8] dt-bindings: display: ti,am65x-dss: Add port properties for DSS
On Mon, Jul 25, 2022 at 04:56:15PM +0530, Aradhya Bhatia wrote: > > > On 21-Jul-22 04:58, Rob Herring wrote: > > On Tue, Jul 19, 2022 at 01:38:38PM +0530, Aradhya Bhatia wrote: > > > Add "ti,oldi-mode" property to indicate the tidss driver the OLDI output > > > mode. The 2 OLDI TXes on am625-dss allow a 3 different types of panel > > > connections with the board. > > > > > > 1. Single Link / Single Mode on OLDI TX 0 OR 1. > > > 2. Single Link / Duplicate Mode on OLDI TX 0 and 1. > > > 3. Dual Link / Single Mode on OLDI TX 0 and 1. > > > > > > Add "ti,rgb565-to-888" property to override 16bit output from a videoport > > > for a bridge that only accepts 24bit RGB888 DPI input. > > > > > > On some boards the HDMI bridge takes a 24bit DPI input, but only 16 data > > > pins are actually enabled from the SoC. This new property forces the > > > output to be RGB565 on a specific video port if the bridge requests a > > > 24bit RGB color space. > > > > > > This assumes that the video port is connected like so: > > > > > > SoC : Bridge > > > R0 -> R3 > > > R1 -> R4 > > > R2 -> R5 > > > R3 -> R6 > > > R4 -> R7 > > > G0 -> G2 > > > G1 -> G3 > > > G2 -> G4 > > > G3 -> G5 > > > G4 -> G6 > > > G5 -> G7 > > > B0 -> B3 > > > B1 -> B4 > > > B2 -> B5 > > > B3 -> B6 > > > B4 -> B7 > > > > > > On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground. > > > The bridge sees 24bits of data, but the lsb's are always zero. > > > > Unless the bridge ignores the LSBs, that's not the right way to do 16 to > > 24 bit. The LSBs should be connected to the MSB of the color component > > to get full color range. > > > > > > > > Signed-off-by: Aradhya Bhatia > > > --- > > > .../bindings/display/ti/ti,am65x-dss.yaml | 25 +-- > > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > > > b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > > > index 6bbce921479d..11d9b3821409 100644 > > > --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > > > +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > > > @@ -80,15 +80,35 @@ properties: > > > properties: > > > port@0: > > > -$ref: /schemas/graph.yaml#/properties/port > > > +$ref: /schemas/graph.yaml#/$defs/port-base > > > +unevaluatedProperties: false > > > description: > > > The DSS OLDI output port node form video port 1 > > > +properties: > > > + ti,oldi-mode: > > > +description: TI specific property to indicate the mode the > > > OLDI TXes > > > + and the display panel are connected in. > > > + 0 -> OLDI TXes OFF (driver default for am625-dss) > > > + 1 -> Single link, Single Mode (OLDI0) (driver default for > > > am65x-dss) > > > + 2 -> Single link, Single Mode (OLDI1) > > > + 3 -> Single link, Duplicate Mode > > > + 4 -> Dual link (Only Single Mode) > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > +enum: [0, 1, 2, 3, 4] > > > > Wouldn't 'data-lanes' property work for this purpose. > > > > Generally, we don't put properties in port nodes. > > > Thank you for the suggestions Rob! > > I looked into the "data-lanes" property and it seems that the property > alone would not be able to help distinguish between the "Single link, > Duplicate mode" (Mode 3) and "Dual link, Single mode" (Mode 4). For both > the cases, the property will look like "data-lanes = <0 1>;" in the DT > node. > > I have an idea on what the driver could use along with the data-lanes > property to ascertain the OLDI mode. > > By means of number of remote-endpoints in DTS. > The OLDI output port of DSS can be made to have 2 remote endpoints when > 2 panels are connected as "Single link, Duplicate Mode" vs only 1 remote > endpoint for "Dual Link, Single Mode". Based on the count, the driver > can distinguish between the two when both the data-lanes are activated > in DT node. You can only have 1 'remote-endpoint'. However, you can have multiple endpoint nodes which is generally used for fanout (output) or muxed (input) cases. Your case is fanout as it is the same data sent to multiple connections. data-lanes would be kind of redundant in that case since it would be 1 lane per endpoint. > > Let me know if you think this method would be appropriate. > > > + > > > port@1: > > > -$ref: /schemas/graph.yaml#/properties/port > > > +$ref: /schemas/graph.yaml#/$defs/port-base > > > +unevaluatedProperties: false > > > description: > > > The DSS DPI output port node from video port 2 > > > +properties: > > > + ti,rgb565-to-888: > > > +description: > > > + property to override DPI output to 16bit for 24bit bridge >
[Bug 216350] New: amdgpu 0000:06:00.0: drm_WARN_ON(atomic_read(>refcount) == 0)
https://bugzilla.kernel.org/show_bug.cgi?id=216350 Bug ID: 216350 Summary: amdgpu :06:00.0: drm_WARN_ON(atomic_read(>refcount) == 0) Product: Drivers Version: 2.5 Kernel Version: 5.19 and older Hardware: AMD OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: icedragon...@web.de Regression: No Every times I put my monitor OFF and after some seconds ON I get the following kernel error message (no other issues observed): [50119.305713] [ cut here ] [50119.305717] amdgpu :06:00.0: drm_WARN_ON(atomic_read(>refcount) == 0) [50119.305728] WARNING: CPU: 7 PID: 75006 at drm_vblank_put+0x121/0x140 [50119.305736] Modules linked in: ufs snd_usb_audio snd_usbmidi_lib uvcvideo vhost_net vhost vhost_iotlb vmnet(OE) vmw_vsock_vmci_transport vsock vmw_vmci vmmon(OE) ipt_REJECT nf_reject_ipv4 bridge stp llc razerkbd(OE) razermouse(OE) xt_hl ip6_tables ip6t_rt xt_LOG nf_log_syslog nft_limit xt_limit xt_addrtype nft_chain_nat xt_MASQUERADE nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat binfmt_misc nls_iso8859_1 hid_generic usbhid hid si2157 si2168 m88rs6000t a8293 cx25840 snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg cx23885 snd_hda_codec tveeprom snd_hwdep altera_ci cx2341x snd_hda_core tda18271 snd_pcm snd_seq_midi altera_stapl snd_seq_midi_event videobuf2_dvb videobuf2_dma_sg snd_rawmidi m88ds3103 i2c_mux intel_rapl_common dvb_core iosf_mbi snd_seq videobuf2_vmalloc amd64_edac videobuf2_memops edac_mce_amd snd_seq_device videobuf2_v4l2 snd_timer videobuf2_common rc_core snd videodev soundcore mc wmi_bmof sch_fq_codel nct6775 wmi nct6775_core hwmon_vid lm92 [50119.305806] lm83 autofs4 raid10 raid1 raid0 multipath linear i2c_piix4 r8169 e1000e realtek xhci_pci xhci_pci_renesas [50119.305817] CPU: 7 PID: 75006 Comm: Isolated Web Co Tainted: GW OE 5.19.0-aw #1 [50119.305820] Hardware name: To Be Filled By O.E.M. B550M Pro4/B550M Pro4, BIOS L2.32 05/17/2022 [50119.305822] RIP: 0010:drm_vblank_put+0x121/0x140 [50119.305826] Code: 8b 7f 08 4c 8b 67 50 4d 85 e4 74 25 e8 78 32 61 00 48 c7 c1 20 ee 5e 85 4c 89 e2 48 c7 c7 df 8b 5e 85 48 89 c6 e8 64 53 bc 00 <0f> 0b e9 6d ff ff ff 4c 8b 27 eb d6 66 66 2e 0f 1f 84 00 00 00 00 [50119.305828] RSP: :9eccc264fc98 EFLAGS: 00010046 [50119.305831] RAX: RBX: 9058cb2ad028 RCX: [50119.305832] RDX: RSI: RDI: [50119.305834] RBP: 9eccc264fca8 R08: R09: [50119.305835] R10: R11: R12: 9058c177d210 [50119.305836] R13: 0086 R14: 9058caac0170 R15: 905993b52e80 [50119.305838] FS: 7fee4742e480() GS:90679e3c() knlGS: [50119.305840] CS: 0010 DS: ES: CR0: 80050033 [50119.305842] CR2: 10fb7e33c000 CR3: 0003d4474000 CR4: 00350ee0 [50119.305843] Call Trace: [50119.305845] [50119.305850] drm_crtc_vblank_put+0x17/0x40 [50119.305853] dm_pflip_high_irq+0xeb/0x2c0 [50119.305857] amdgpu_dm_irq_handler+0xaa/0x280 [50119.305860] amdgpu_irq_dispatch+0xde/0x2c0 [50119.305864] amdgpu_ih_process+0xa3/0x140 [50119.305867] amdgpu_irq_handler+0x24/0x80 [50119.305869] __handle_irq_event_percpu+0x4f/0x1c0 [50119.305873] handle_irq_event+0x39/0x80 [50119.305876] handle_edge_irq+0x8c/0x280 [50119.305879] __common_interrupt+0x52/0x100 [50119.305883] common_interrupt+0x3d/0xc0 [50119.305888] asm_common_interrupt+0x27/0x40 [50119.305890] RIP: 0033:0x2b359729d460 [50119.305893] Code: 40 b1 bb 2e ee 7f 00 00 ff 21 0f 0b 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 75 42 9f 46 0f 00 00 <33> c9 49 bb 40 5f 5e 6c dc 1a 00 00 4c 39 18 0f 85 50 00 00 00 48 [50119.305894] RSP: 002b:7ffdfe7c3780 EFLAGS: 0246 [50119.305896] RAX: 13e886654550 RBX: 240dc88f0670 RCX: 7fee2ebc8260 [50119.305898] RDX: 13e8866f RSI: RDI: 7ffdfe7c3610 [50119.305899] RBP: 7ffdfe7c3850 R08: 7fee3ffb5410 R09: [50119.305900] R10: 7ffdfe7c33d0 R11: fff90001 R12: 0f469f40de40 [50119.305902] R13: 7ffdfe7c4120 R14: 7fee32ff2b35 R15: 7fee3b21d100 [50119.305905] [50119.305906] ---[ end trace ]--- This always reproducible - can also be reproduced on 5.18.x mainline kernel. Kernel: mainline kernel 5.18.x and 5.19 from kernel.org CPU: AMD Ryzen 7 PRO 4750G with Radeon Graphics Monitor: DELL S3422DWG Linux: Kubuntu 22.04.1 LTS - with latest patches Not other issues observed - system is still usable. -- You may reply to this email to add a comment. You are receiving this mail because: You are
[PATCH] dma-buf/dma-resv: check if the new fence is really later
Previously when we added a fence to a dma_resv object we always
assumed the the newer than all the existing fences.
With Jason's work to add an UAPI to explicit export/import that's not
necessary the case any more. So without this check we would allow
userspace to force the kernel into an use after free error.
Since the change is very small and defensive it's probably a good
idea to backport this to stable kernels as well just in case others
are using the dma_resv object in the same way.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 205acb2c744d..e3885c90a3ac 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -295,7 +295,8 @@ void dma_resv_add_fence(struct dma_resv *obj, struct
dma_fence *fence,
enum dma_resv_usage old_usage;
dma_resv_list_entry(fobj, i, obj, , _usage);
- if ((old->context == fence->context && old_usage >= usage) ||
+ if ((old->context == fence->context && old_usage >= usage &&
+dma_fence_is_later(fence, old)) ||
dma_fence_is_signaled(old)) {
dma_resv_list_set(fobj, i, fence, usage);
dma_fence_put(old);
--
2.25.1
[PATCH v2] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
dp_bridge_disable() is the first step toward tearing down main link.
Its major function is to start transmitting idle pattern to replace
video stream. This patch will check hpd_state to make sure main link
is enabled before commit changes of main link's configuration to
push idle pattern out to avoid system crashing due to main link clock
is disabled while access main link registers.
Changes in v2:
-- changes Fixes patch
-- fix eported-by
-- add Closes tag
Fixes: 375a126090b9 ("drm/msm/dp: tear down main link at unplug handle
immediately")
Reported-by: leon...@lausen.nl
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/17
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index b36f8b6..678289a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1729,10 +1729,20 @@ void dp_bridge_disable(struct drm_bridge *drm_bridge)
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
struct dp_display_private *dp_display;
+ u32 state;
dp_display = container_of(dp, struct dp_display_private, dp_display);
+ mutex_lock(_display->event_mutex);
+
+ state = dp_display->hpd_state;
+ if (state != ST_DISCONNECT_PENDING && state != ST_CONNECTED) {
+ mutex_unlock(_display->event_mutex);
+ return;
+ }
+
dp_ctrl_push_idle(dp_display->ctrl);
+ mutex_unlock(_display->event_mutex);
}
void dp_bridge_post_disable(struct drm_bridge *drm_bridge)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [Intel-gfx] [PATCH] dma-buf: revert "return only unsignaled fences in dma_fence_unwrap_for_each v3"
On Wed, Aug 10, 2022 at 07:01:55PM +0200, Christian König wrote:
> Am 10.08.22 um 18:54 schrieb Daniel Vetter:
> > On Tue, 12 Jul 2022 at 12:28, Christian König
> > wrote:
> > > This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83.
> > >
> > > It turned out that this is not correct. Especially the sync_file info
> > > IOCTL needs to see even signaled fences to correctly report back their
> > > status to userspace.
> > >
> > > Instead add the filter in the merge function again where it makes sense.
> > >
> > > Signed-off-by: Christian König
> > > ---
> > > drivers/dma-buf/dma-fence-unwrap.c | 3 ++-
> > > include/linux/dma-fence-unwrap.h | 6 +-
> > > 2 files changed, 3 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/dma-buf/dma-fence-unwrap.c
> > > b/drivers/dma-buf/dma-fence-unwrap.c
> > > index 502a65ea6d44..7002bca792ff 100644
> > > --- a/drivers/dma-buf/dma-fence-unwrap.c
> > > +++ b/drivers/dma-buf/dma-fence-unwrap.c
> > > @@ -72,7 +72,8 @@ struct dma_fence *__dma_fence_unwrap_merge(unsigned int
> > > num_fences,
> > > count = 0;
> > > for (i = 0; i < num_fences; ++i) {
> > > dma_fence_unwrap_for_each(tmp, [i], fences[i])
> > > - ++count;
> > > + if (!dma_fence_is_signaled(tmp))
> > > + ++count;
> > > }
> > >
> > > if (count == 0)
> > > diff --git a/include/linux/dma-fence-unwrap.h
> > > b/include/linux/dma-fence-unwrap.h
> > > index 390de1ee9d35..66b1e56fbb81 100644
> > > --- a/include/linux/dma-fence-unwrap.h
> > > +++ b/include/linux/dma-fence-unwrap.h
> > > @@ -43,14 +43,10 @@ struct dma_fence *dma_fence_unwrap_next(struct
> > > dma_fence_unwrap *cursor);
> > >* Unwrap dma_fence_chain and dma_fence_array containers and deep dive
> > > into all
> > >* potential fences in them. If @head is just a normal fence only that
> > > one is
> > >* returned.
> > > - *
> > > - * Note that signalled fences are opportunistically filtered out, which
> > > - * means the iteration is potentially over no fence at all.
> > >*/
> > > #define dma_fence_unwrap_for_each(fence, cursor, head) \
> > > for (fence = dma_fence_unwrap_first(head, cursor); fence; \
> > > -fence = dma_fence_unwrap_next(cursor)) \
> > > - if (!dma_fence_is_signaled(fence))
> > > +fence = dma_fence_unwrap_next(cursor))
> > Not sure it's worth it, but could we still filter but keep the fence
> > if there's an error?
> >
> > I'm honestly also not entirely sure whether error propagation is a
> > terrific idea, since every single use-case I've seen in i915 was a
> > mis-design and not good at all. So burning it all down and declaring
> > the testcases invalid might be the right thing to do here.
>
> This is not about error propagation.
>
> The sync_file has an IOCTL which asks how many of the merged fences are
> already signaled. When we filter signaled fences here the result of this is
> always 0.
>
> We have an igt test exercising this which reported that the IOCTL doesn't
> work any more.
Ah ok. I guess we add that to the list of reasons why sync_file is a bit a
funny interface, and people should just use drm_syncobj instead :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH] dma-buf: revert "return only unsignaled fences in dma_fence_unwrap_for_each v3"
Am 10.08.22 um 18:54 schrieb Daniel Vetter:
On Tue, 12 Jul 2022 at 12:28, Christian König
wrote:
This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83.
It turned out that this is not correct. Especially the sync_file info
IOCTL needs to see even signaled fences to correctly report back their
status to userspace.
Instead add the filter in the merge function again where it makes sense.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-unwrap.c | 3 ++-
include/linux/dma-fence-unwrap.h | 6 +-
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-fence-unwrap.c
b/drivers/dma-buf/dma-fence-unwrap.c
index 502a65ea6d44..7002bca792ff 100644
--- a/drivers/dma-buf/dma-fence-unwrap.c
+++ b/drivers/dma-buf/dma-fence-unwrap.c
@@ -72,7 +72,8 @@ struct dma_fence *__dma_fence_unwrap_merge(unsigned int
num_fences,
count = 0;
for (i = 0; i < num_fences; ++i) {
dma_fence_unwrap_for_each(tmp, [i], fences[i])
- ++count;
+ if (!dma_fence_is_signaled(tmp))
+ ++count;
}
if (count == 0)
diff --git a/include/linux/dma-fence-unwrap.h b/include/linux/dma-fence-unwrap.h
index 390de1ee9d35..66b1e56fbb81 100644
--- a/include/linux/dma-fence-unwrap.h
+++ b/include/linux/dma-fence-unwrap.h
@@ -43,14 +43,10 @@ struct dma_fence *dma_fence_unwrap_next(struct
dma_fence_unwrap *cursor);
* Unwrap dma_fence_chain and dma_fence_array containers and deep dive into
all
* potential fences in them. If @head is just a normal fence only that one is
* returned.
- *
- * Note that signalled fences are opportunistically filtered out, which
- * means the iteration is potentially over no fence at all.
*/
#define dma_fence_unwrap_for_each(fence, cursor, head) \
for (fence = dma_fence_unwrap_first(head, cursor); fence; \
-fence = dma_fence_unwrap_next(cursor)) \
- if (!dma_fence_is_signaled(fence))
+fence = dma_fence_unwrap_next(cursor))
Not sure it's worth it, but could we still filter but keep the fence
if there's an error?
I'm honestly also not entirely sure whether error propagation is a
terrific idea, since every single use-case I've seen in i915 was a
mis-design and not good at all. So burning it all down and declaring
the testcases invalid might be the right thing to do here.
This is not about error propagation.
The sync_file has an IOCTL which asks how many of the merged fences are
already signaled. When we filter signaled fences here the result of this
is always 0.
We have an igt test exercising this which reported that the IOCTL
doesn't work any more.
Christian.
-Daniel
struct dma_fence *__dma_fence_unwrap_merge(unsigned int num_fences,
struct dma_fence **fences,
--
2.25.1
Re: [Intel-gfx] [PATCH] dma-buf: revert "return only unsignaled fences in dma_fence_unwrap_for_each v3"
On Tue, 12 Jul 2022 at 12:28, Christian König
wrote:
>
> This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83.
>
> It turned out that this is not correct. Especially the sync_file info
> IOCTL needs to see even signaled fences to correctly report back their
> status to userspace.
>
> Instead add the filter in the merge function again where it makes sense.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-fence-unwrap.c | 3 ++-
> include/linux/dma-fence-unwrap.h | 6 +-
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence-unwrap.c
> b/drivers/dma-buf/dma-fence-unwrap.c
> index 502a65ea6d44..7002bca792ff 100644
> --- a/drivers/dma-buf/dma-fence-unwrap.c
> +++ b/drivers/dma-buf/dma-fence-unwrap.c
> @@ -72,7 +72,8 @@ struct dma_fence *__dma_fence_unwrap_merge(unsigned int
> num_fences,
> count = 0;
> for (i = 0; i < num_fences; ++i) {
> dma_fence_unwrap_for_each(tmp, [i], fences[i])
> - ++count;
> + if (!dma_fence_is_signaled(tmp))
> + ++count;
> }
>
> if (count == 0)
> diff --git a/include/linux/dma-fence-unwrap.h
> b/include/linux/dma-fence-unwrap.h
> index 390de1ee9d35..66b1e56fbb81 100644
> --- a/include/linux/dma-fence-unwrap.h
> +++ b/include/linux/dma-fence-unwrap.h
> @@ -43,14 +43,10 @@ struct dma_fence *dma_fence_unwrap_next(struct
> dma_fence_unwrap *cursor);
> * Unwrap dma_fence_chain and dma_fence_array containers and deep dive into
> all
> * potential fences in them. If @head is just a normal fence only that one is
> * returned.
> - *
> - * Note that signalled fences are opportunistically filtered out, which
> - * means the iteration is potentially over no fence at all.
> */
> #define dma_fence_unwrap_for_each(fence, cursor, head) \
> for (fence = dma_fence_unwrap_first(head, cursor); fence; \
> -fence = dma_fence_unwrap_next(cursor)) \
> - if (!dma_fence_is_signaled(fence))
> +fence = dma_fence_unwrap_next(cursor))
Not sure it's worth it, but could we still filter but keep the fence
if there's an error?
I'm honestly also not entirely sure whether error propagation is a
terrific idea, since every single use-case I've seen in i915 was a
mis-design and not good at all. So burning it all down and declaring
the testcases invalid might be the right thing to do here.
-Daniel
>
> struct dma_fence *__dma_fence_unwrap_merge(unsigned int num_fences,
>struct dma_fence **fences,
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Linaro-mm-sig] [PATCH] dma-buf/dma_resv_usage: update explicit sync documentation
On Wed, Jul 13, 2022 at 01:27:13PM +0200, Bas Nieuwenhuizen wrote:
> With that changed
>
> Reviewed-by: Bas Nieuwenhuizen
Yeah this is a nice clarification.
Reviewed-by: Daniel Vetter
In case it hasn't landed yet or so.
-Daniel
>
> Thanks!
>
> On Tue, Jul 12, 2022 at 3:23 PM Christian König
> wrote:
> >
> > Am 12.07.22 um 15:20 schrieb Alex Deucher:
> > > On Tue, Jul 12, 2022 at 9:12 AM Christian König
> > > wrote:
> > >> Make it clear that DMA_RESV_USAGE_BOOKMARK can be used for explicit
> > >> synced
> > > DMA_RESV_USAGE_BOOKKEEP?
> >
> > Crappy autocorrect and copy Thanks for pointing that out.
> >
> > Christian.
> >
> > >
> > >> user space submissions as well and document the rules around adding the
> > >> same fence with different usages.
> > >>
> > >> Signed-off-by: Christian König
> > >> ---
> > >> include/linux/dma-resv.h | 16 +---
> > >> 1 file changed, 13 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
> > >> index c8ccbc94d5d2..264e27e56dff 100644
> > >> --- a/include/linux/dma-resv.h
> > >> +++ b/include/linux/dma-resv.h
> > >> @@ -62,6 +62,11 @@ struct dma_resv_list;
> > >>* For example when asking for WRITE fences then the KERNEL fences are
> > >> returned
> > >>* as well. Similar when asked for READ fences then both WRITE and
> > >> KERNEL
> > >>* fences are returned as well.
> > >> + *
> > >> + * Already used fences can be promoted in the sense that a fence with
> > >> + * DMA_RESV_USAGE_BOOKMARK could become DMA_RESV_USAGE_READ by adding
> > >> it again
> > > Same here.
> > >
> > > With that fixed,
> > > Acked-by: Alex Deucher
> > >
> > > Alex
> > >
> > >> + * with this usage. But fences can never be degraded in the sense that
> > >> a fence
> > >> + * with DMA_RESV_USAGE_WRITE could become DMA_RESV_USAGE_READ.
> > >>*/
> > >> enum dma_resv_usage {
> > >> /**
> > >> @@ -98,10 +103,15 @@ enum dma_resv_usage {
> > >> * @DMA_RESV_USAGE_BOOKKEEP: No implicit sync.
> > >> *
> > >> * This should be used by submissions which don't want to
> > >> participate in
> > >> -* implicit synchronization.
> > >> +* any implicit synchronization.
> > >> +*
> > >> +* The most common case are preemption fences, page table
> > >> updates, TLB
> > >> +* flushes as well as explicit synced user submissions.
> > >> *
> > >> -* The most common case are preemption fences as well as page
> > >> table
> > >> -* updates and their TLB flushes.
> > >> +* Explicit synced user user submissions can be promoted to
> > >> +* DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE as needed using
> > >> +* dma_buf_import_sync_file() when implicit synchronization
> > >> should
> > >> +* become necessary after initial adding of the fence.
> > >> */
> > >> DMA_RESV_USAGE_BOOKKEEP
> > >> };
> > >> --
> > >> 2.25.1
> > >>
> > >> ___
> > >> Linaro-mm-sig mailing list -- linaro-mm-...@lists.linaro.org
> > >> To unsubscribe send an email to linaro-mm-sig-le...@lists.linaro.org
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/3] drm/amd/display: Fix merge conflict resolution in amdgpu_dm_plane.c
Acked-by: Alex Deucher
On Mon, Aug 1, 2022 at 10:08 AM Simon Ser wrote:
>
> Acked-by: Simon Ser
>
> CC amd-gfx
>
> On Monday, August 1st, 2022 at 15:52, Imre Deak wrote:
>
> > The API change introduced in
> >
> > commit 30c637151cfa ("drm/plane-helper: Export individual helpers")
> >
> > was missed in the conflict resolution of
> >
> > commit d93a13bd75b9 ("Merge remote-tracking branch 'drm-misc/drm-misc-next'
> > into drm-tip")
> >
> > fix this up.
> >
> > Fixes: d93a13bd75b9 ("Merge remote-tracking branch 'drm-misc/drm-misc-next'
> > into drm-tip")
> > Cc: Simon Ser cont...@emersion.fr
> >
> > Cc: Thomas Zimmermann tzimmerm...@suse.de
> >
> > Acked-by: Thomas Zimmermann tzimmerm...@suse.de
> >
> > Signed-off-by: Imre Deak imre.d...@intel.com
> >
> > ---
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> > index 8cd25b2ea0dca..5eb5d31e591de 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> > @@ -1562,7 +1562,7 @@ int dm_drm_plane_get_property(struct drm_plane *plane,
> > static const struct drm_plane_funcs dm_plane_funcs = {
> > .update_plane = drm_atomic_helper_update_plane,
> > .disable_plane = drm_atomic_helper_disable_plane,
> > - .destroy = drm_primary_helper_destroy,
> > + .destroy = drm_plane_helper_destroy,
> > .reset = dm_drm_plane_reset,
> > .atomic_duplicate_state = dm_drm_plane_duplicate_state,
> > .atomic_destroy_state = dm_drm_plane_destroy_state,
> > --
> > 2.37.1
Re: [PATCH] spi/panel: dt-bindings: drop 3-wire from common properties
On 10/08/2022 19:18, Mark Brown wrote: > On Wed, Aug 10, 2022 at 04:13:11PM +0300, Krzysztof Kozlowski wrote: >> The spi-3wire property is device specific and should be accepted only if >> device really needs them. Drop it from common spi-peripheral-props.yaml >> schema, mention in few panel drivers which use it and include instead in >> the SPI controller bindings. The controller bindings will provide >> spi-3wire type validation and one place for description. Each device >> schema must list the property if it is applicable. > > What's the plan for getting this merged? I can just apply it at -rc1 if > that works for people? Ah, I should mention it before, my bad. There are no dependencies, no stoppers. I hope this will go via your SPI tree. Best regards, Krzysztof
Re: [RFC][PATCH 3/3] kselftest: Add drm_syncobj API test tool
On Tue, Jul 12, 2022 at 08:52:53AM -0700, John Stultz wrote: > On Tue, Jul 12, 2022 at 12:43 AM Christian König > wrote: > > Am 12.07.22 um 06:22 schrieb John Stultz: > > > An initial pass at a drm_syncobj API test. > > > > > > Currently covers trivial use of: > > >DRM_IOCTL_SYNCOBJ_CREATE > > >DRM_IOCTL_SYNCOBJ_DESTROY > > >DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD > > >DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE > > >DRM_IOCTL_SYNCOBJ_WAIT > > >DRM_IOCTL_SYNCOBJ_RESET > > >DRM_IOCTL_SYNCOBJ_SIGNAL > > >DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT > > >DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL > > > > > > And demonstrates how the userspace API can be used, along with > > > some fairly simple bad parameter checking. > > > > > > The patch includes a few helpers taken from libdrm, as at least > > > on the VM I was testing with, I didn't have a new enough libdrm > > > to support the *_TIMELINE_* ioctls. Ideally the ioctl-helper bits > > > can be dropped at a later time. > > > > > > Feedback would be appreciated! > > > > DRM userspace selftests usually go either into libdrm or igt and not > > into the kernel source. > > Appreciate the pointer, I'll rework and submit to one of those projects. https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation There should be already a ton of syncobj tests, so probably more just work needed to make them work on vgem so we can test them all without a suitable hw driver loaded. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCHv2 -next] drm/amdgpu: double free error and freeing uninitialized null pointer
Applied. Thanks! Alex On Mon, Aug 1, 2022 at 1:08 PM André Almeida wrote: > > Às 00:46 de 30/07/22, Sebin Sebastian escreveu: > > Fix a double free and an uninitialized pointer read error. Both tmp and > > new are pointing at same address and both are freed which leads to > > double free. Adding a check to verify if new and tmp are free in the > > error_free label fixes the double free issue. new is not initialized to > > null which also leads to a free on an uninitialized pointer. > > > > Suggested by: S. Amaranath > > Signed-off-by: Sebin Sebastian > > Reviewed-by: André Almeida
Re: [PATCH v2 1/8] drm: Disable the cursor plane on atomic contexts with virtualized drivers
On Mon, Jul 11, 2022 at 11:32:39PM -0400, Zack Rusin wrote:
> From: Zack Rusin
>
> Cursor planes on virtualized drivers have special meaning and require
> that the clients handle them in specific ways, e.g. the cursor plane
> should react to the mouse movement the way a mouse cursor would be
> expected to and the client is required to set hotspot properties on it
> in order for the mouse events to be routed correctly.
>
> This breaks the contract as specified by the "universal planes". Fix it
> by disabling the cursor planes on virtualized drivers while adding
> a foundation on top of which it's possible to special case mouse cursor
> planes for clients that want it.
>
> Disabling the cursor planes makes some kms compositors which were broken,
> e.g. Weston, fallback to software cursor which works fine or at least
> better than currently while having no effect on others, e.g. gnome-shell
> or kwin, which put virtualized drivers on a deny-list when running in
> atomic context to make them fallback to legacy kms and avoid this issue.
>
> Signed-off-by: Zack Rusin
> Fixes: 681e7ec73044 ("drm: Allow userspace to ask for universal plane list
> (v2)")
> Cc: # v5.4+
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Hans de Goede
> Cc: Gurchetan Singh
> Cc: Chia-I Wu
> Cc: dri-devel@lists.freedesktop.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_plane.c | 11 +++
> drivers/gpu/drm/qxl/qxl_drv.c| 2 +-
> drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> include/drm/drm_drv.h| 10 ++
> include/drm/drm_file.h | 12
> 7 files changed, 38 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 726f2f163c26..e1e2a65c7119 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -667,6 +667,17 @@ int drm_mode_getplane_res(struct drm_device *dev, void
> *data,
> !file_priv->universal_planes)
> continue;
>
> + /*
> + * Unless userspace supports virtual cursor plane
> + * then if we're running on virtual driver do not
> + * advertise cursor planes because they'll be broken
> + */
> + if (plane->type == DRM_PLANE_TYPE_CURSOR &&
> + drm_core_check_feature(dev, DRIVER_VIRTUAL) &&
> + file_priv->atomic &&
> + !file_priv->supports_virtual_cursor_plane)
> + continue;
> +
> if (drm_lease_held(file_priv, plane->base.id)) {
> if (count < plane_resp->count_planes &&
> put_user(plane->base.id, plane_ptr + count))
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 1cb6f0c224bb..0e4212e05caa 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -281,7 +281,7 @@ static const struct drm_ioctl_desc qxl_ioctls[] = {
> };
>
> static struct drm_driver qxl_driver = {
> - .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> + .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
> DRIVER_VIRTUAL,
>
> .dumb_create = qxl_mode_dumb_create,
> .dumb_map_offset = drm_gem_ttm_dumb_map_offset,
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> index f4f2bd79a7cb..84e75bcc3384 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> @@ -176,7 +176,7 @@ DEFINE_DRM_GEM_FOPS(vbox_fops);
>
> static const struct drm_driver driver = {
> .driver_features =
> - DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
> + DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC | DRIVER_VIRTUAL,
>
> .lastclose = drm_fb_helper_lastclose,
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> b/drivers/gpu/drm/virtio/virtgpu_drv.c
> index 5f25a8d15464..3c5bb006159a 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> @@ -198,7 +198,8 @@ MODULE_AUTHOR("Alon Levy");
> DEFINE_DRM_GEM_FOPS(virtio_gpu_driver_fops);
>
> static const struct drm_driver driver = {
> - .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_RENDER |
> DRIVER_ATOMIC,
> + .driver_features =
> + DRIVER_MODESET | DRIVER_GEM | DRIVER_RENDER | DRIVER_ATOMIC |
> DRIVER_VIRTUAL,
> .open = virtio_gpu_driver_open,
> .postclose = virtio_gpu_driver_postclose,
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 01a5b47e95f9..712f6ad0b014 100644
> ---
Re: [PATCH] drm:pl111: Add of_node_put() when breaking out of for_each_available_child_of_node()
On Mon, Jul 11, 2022 at 09:15:50PM +0800, Liang He wrote:
> The reference 'child' in the iteration of for_each_available_child_of_node()
> is only escaped out into a local variable which is only used to check
> its value. So we still need to the of_node_put() when breaking of the
> for_each_available_child_of_node() which will automatically increase
> and decrease the refcount.
>
> Fixes: ca454bd42dc2 ("drm/pl111: Support the Versatile Express")
> Signed-off-by: Liang He
> ---
>
> As 'Check-after-Put' has been widely accepted in kernel source, we just
> use it. If the maintainer thinks it is harmful, I'd like also to use
> 'Check-and-Put' coding style but with a bit more work.
>
> drivers/gpu/drm/pl111/pl111_versatile.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
> b/drivers/gpu/drm/pl111/pl111_versatile.c
> index bdd883f4f0da..963a5d5e6987 100644
> --- a/drivers/gpu/drm/pl111/pl111_versatile.c
> +++ b/drivers/gpu/drm/pl111/pl111_versatile.c
> @@ -402,6 +402,7 @@ static int pl111_vexpress_clcd_init(struct device *dev,
> struct device_node *np,
> if (of_device_is_compatible(child, "arm,pl111")) {
> has_coretile_clcd = true;
> ct_clcd = child;
> + of_node_put(child);
The same issue seems to exist right below in the next break? Can you pls
respin with that included?
Thanks, Daniel
> break;
> }
> if (of_device_is_compatible(child, "arm,hdlcd")) {
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 4/4] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb565()
On Sun, Jul 17, 2022 at 07:00:54PM +0200, José Expósito wrote: > José Expósito wrote: > > I already fixed the warning and added the reviewed by tags, however, I > > noticed that rebasing the series on the latest drm-misc-next show this > > error: > > [...] > > Sorry for the extra email. I forgot to mention that the error is only > present in UML. Running in other architectures works as expected. > Tested on x86_64 and PowerPC. Maybe a regression in the kunit infrastructure? Just guessing here ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] spi/panel: dt-bindings: drop 3-wire from common properties
On Wed, Aug 10, 2022 at 04:13:11PM +0300, Krzysztof Kozlowski wrote: > The spi-3wire property is device specific and should be accepted only if > device really needs them. Drop it from common spi-peripheral-props.yaml > schema, mention in few panel drivers which use it and include instead in > the SPI controller bindings. The controller bindings will provide > spi-3wire type validation and one place for description. Each device > schema must list the property if it is applicable. What's the plan for getting this merged? I can just apply it at -rc1 if that works for people? signature.asc Description: PGP signature
[PATCH 1/2] dt-bindings: display: arm, versatile-tft-panel: Drop erroneous properties in example
The 'arm,versatile-sysreg' node in the example should not have
'#address-cells' and '#size-cells' properties as the child node doesn't
have 'reg'.
Signed-off-by: Rob Herring
---
.../bindings/display/panel/arm,versatile-tft-panel.yaml| 3 ---
1 file changed, 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
index be69e0cc50fc..c9958f824d9a 100644
---
a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
+++
b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
@@ -37,9 +37,6 @@ examples:
compatible = "arm,versatile-sysreg", "syscon", "simple-mfd";
reg = <0x0 0x1000>;
-#address-cells = <1>;
-#size-cells = <0>;
-
panel {
compatible = "arm,versatile-tft-panel";
--
2.34.1
[PATCH 2/2] dt-bindings: arm, versatile-sysreg: Convert to DT schema format
Convert the arm,versatile-sysreg binding to DT schema format. The original binding was missing 'simple-mfd' and a 'panel' sub node which the only user (versatile-ab.dts) of this binding has. Signed-off-by: Rob Herring --- .../bindings/arm/arm,versatile-sysreg.yaml| 35 +++ .../bindings/arm/versatile-sysreg.txt | 10 -- 2 files changed, 35 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml delete mode 100644 Documentation/devicetree/bindings/arm/versatile-sysreg.txt diff --git a/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml b/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml new file mode 100644 index ..491eef1e1b10 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,versatile-sysreg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm Versatile system registers + +maintainers: + - Linus Walleij + +description: + This is a system control registers block, providing multiple low level + platform functions like board detection and identification, software + interrupt generation, MMC and NOR Flash control, etc. + +properties: + compatible: +items: + - const: arm,versatile-sysreg + - const: syscon + - const: simple-mfd + + reg: +maxItems: 1 + + panel: +type: object + +required: + - compatible + - reg + +additionalProperties: false +... diff --git a/Documentation/devicetree/bindings/arm/versatile-sysreg.txt b/Documentation/devicetree/bindings/arm/versatile-sysreg.txt deleted file mode 100644 index a4f15262d717.. --- a/Documentation/devicetree/bindings/arm/versatile-sysreg.txt +++ /dev/null @@ -1,10 +0,0 @@ -ARM Versatile system registers --- - -This is a system control registers block, providing multiple low level -platform functions like board detection and identification, software -interrupt generation, MMC and NOR Flash control etc. - -Required node properties: -- compatible value : = "arm,versatile-sysreg", "syscon" -- reg : physical base address and the size of the registers window -- 2.34.1
[PATCH 0/2] Convert arm,versatile-sysreg to DT schema
This short series converts the arm,versatile-sysreg binding to DT schema. The binding is already in use in examples which unsurprisingly needs a fix with the schema added. This is part of getting rid of the remaining ~40 cases of compatibles without a schema in the examples. Rob Rob Herring (2): dt-bindings: display: arm,versatile-tft-panel: Drop erroneous properties in example dt-bindings: arm,versatile-sysreg: Convert to DT schema format .../bindings/arm/arm,versatile-sysreg.yaml| 35 +++ .../bindings/arm/versatile-sysreg.txt | 10 -- .../panel/arm,versatile-tft-panel.yaml| 3 -- 3 files changed, 35 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml delete mode 100644 Documentation/devicetree/bindings/arm/versatile-sysreg.txt -- 2.34.1
Re: [PATCH v3 00/10] drm: Add support for low-color frame buffer formats
On Mon, Jul 11, 2022 at 11:12:51AM +0200, Sam Ravnborg wrote: > Hi Thomas, > > On Mon, Jul 11, 2022 at 10:50:00AM +0200, Thomas Zimmermann wrote: > > Hi > > > > Am 09.07.22 um 15:38 schrieb Sam Ravnborg: > > > Hi Geert, > > > > > > On Fri, Jul 08, 2022 at 08:20:45PM +0200, Geert Uytterhoeven wrote: > > > > Hi all, > > > > > > > > A long outstanding issue with the DRM subsystem has been the lack of > > > > support for low-color displays, as used typically on older desktop > > > > systems, and on small embedded displays. > > > > For the patchset > > > > Acked-by: Thomas Zimemrmann > > > > > > > > IT is super to have this addressed - thanks! > > > > > > > > > > > This patch series adds support for color-indexed frame buffer formats > > > > with 2, 4, and 16 colors. It has been tested on ARAnyM using a > > > > work-in-progress Atari DRM driver supporting 2, 4, 16, 256, and 65536 > > > > colors, with text console operation, fbtest, and modetest. > > > > > > > > Overview: > > > >- Patch 1 introduces a helper, to be used by later patches in the > > > > series, > > > >- Patch 2 introduces a flag to indicate color-indexed formats, > > > >- Patches 3 and 4 correct calculations of bits per pixel for sub-byte > > > > pixel formats, > > > >- Patches 5 and 6 introduce the new C[124] formats, > > > >- Patch 7 fixes an untested code path, > > > >- Patch 8 documents the use of "red" for light-on-dark displays, > > > >- Patches 9 and 10 add more fourcc codes for light-on-dark and > > > > dark-on-light frame buffer formats, which may be useful for e.g. > > > > the > > > > ssd130x and repaper drivers. > > > > > > Applied all patches to drm-misc (drm-misc-next), including the last two > > > RFC patches as we then have the formats ready when a user pops up. > > > > I know it's v3 already, but give people at least a workday for reviewing > > before merging patches of this size and impact. Friday-evening patches are > > not supposed to be merged on Saturday afternoons. > > Sorry for being too enthusiastic on this one. > Will wait a bit more in the future for these kind of patches. Took me a bit longer to unburry and get to this, and lgtm except patch 1 where I have a semantic concern. Can you pls do the quick patch to adjust that? Since this is all about the Cx/Rx/Dx formats I don't think it'll matter really. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 0/4] drm/amd: Add more GFXOFF stats for vangogh
Às 12:57 de 10/08/22, Alex Deucher escreveu: > On Tue, Jul 26, 2022 at 2:23 PM André Almeida wrote: >> >> This series adds new logging features for GFXOFF available for vangogh >> and documentation for it. >> >> I've created a small userspace program to interact with this new debugfs >> interface and it can be found at: >> >> https://gitlab.freedesktop.org/andrealmeid/gfxoff_tool >> >> Changelog: >> v2: >> - Make entrycount uint64_t >> - Add a note in docs about data types and overflow > > A minor comment on patch 2, the rest looks good to me. > ok, let me send a v3 > Thanks, > > Alex > > >> >> André Almeida (4): >> drm/amd: Add detailed GFXOFF stats to debugfs >> drm/amd/pm: Implement GFXOFF's entry count and residency for vangogh >> Documentation/gpu: Document GFXOFF's count and residency >> drm/amdgpu: Document gfx_off members of struct amdgpu_gfx >> >> Documentation/gpu/amdgpu/thermal.rst | 18 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 168 ++ >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 + >> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 39 >> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 14 +- >> drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 45 + >> drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 3 + >> drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 35 +++- >> drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 22 +++ >> .../pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h| 5 +- >> drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 5 +- >> .../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 92 ++ >> drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 + >> 13 files changed, 443 insertions(+), 8 deletions(-) >> >> -- >> 2.37.1 >>
Re: [PATCH v3 01/10] drm/fourcc: Add drm_format_info_bpp() helper
On Fri, Jul 08, 2022 at 08:20:46PM +0200, Geert Uytterhoeven wrote:
> Add a helper to retrieve the actual number of bits per pixel for a
> plane, taking into account the number of characters and pixels per
> block for tiled formats.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Javier Martinez Canillas
> ---
> v3:
> - Add Reviewed-by,
>
> v2:
> - Move up.
> ---
> drivers/gpu/drm/drm_fourcc.c | 19 +++
> include/drm/drm_fourcc.h | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 07741b678798b0f1..cf48ea0b2cb70ba8 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -370,6 +370,25 @@ unsigned int drm_format_info_block_height(const struct
> drm_format_info *info,
> }
> EXPORT_SYMBOL(drm_format_info_block_height);
>
> +/**
> + * drm_format_info_bpp - number of bits per pixel
> + * @info: pixel format info
> + * @plane: plane index
> + *
> + * Returns:
> + * The actual number of bits per pixel, depending on the plane index.
> + */
> +unsigned int drm_format_info_bpp(const struct drm_format_info *info, int
> plane)
> +{
> + if (!info || plane < 0 || plane >= info->num_planes)
> + return 0;
> +
> + return info->char_per_block[plane] * 8 /
> +(drm_format_info_block_width(info, plane) *
> + drm_format_info_block_height(info, plane));
Do we really needs this for blocky formats where this is potentially
ill-defined? I think if there's no need then this should also return 0
when block_width/height != 1, it doesn't make much sense to compute bpp
when it's not really bits per _pixel_.
Minimally this needs to check whether the division actually makes sense or
whether there's a reminder, and if there's reminder, then fail. But that
feels like a bad hack and I think we should avoid it if it's not
absolutely necessary.
Otherwise lgtm.
-Daniel
> +}
> +EXPORT_SYMBOL(drm_format_info_bpp);
> +
> /**
> * drm_format_info_min_pitch - computes the minimum required pitch in bytes
> * @info: pixel format info
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 22aa64d07c7905e2..3800a7ad7f0cda7a 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -313,6 +313,7 @@ unsigned int drm_format_info_block_width(const struct
> drm_format_info *info,
>int plane);
> unsigned int drm_format_info_block_height(const struct drm_format_info *info,
> int plane);
> +unsigned int drm_format_info_bpp(const struct drm_format_info *info, int
> plane);
> uint64_t drm_format_info_min_pitch(const struct drm_format_info *info,
> int plane, unsigned int buffer_width);
>
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 0/4] drm/amd: Add more GFXOFF stats for vangogh
On Tue, Jul 26, 2022 at 2:23 PM André Almeida wrote: > > This series adds new logging features for GFXOFF available for vangogh > and documentation for it. > > I've created a small userspace program to interact with this new debugfs > interface and it can be found at: > > https://gitlab.freedesktop.org/andrealmeid/gfxoff_tool > > Changelog: > v2: > - Make entrycount uint64_t > - Add a note in docs about data types and overflow A minor comment on patch 2, the rest looks good to me. Thanks, Alex > > André Almeida (4): > drm/amd: Add detailed GFXOFF stats to debugfs > drm/amd/pm: Implement GFXOFF's entry count and residency for vangogh > Documentation/gpu: Document GFXOFF's count and residency > drm/amdgpu: Document gfx_off members of struct amdgpu_gfx > > Documentation/gpu/amdgpu/thermal.rst | 18 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 168 ++ > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 + > drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 39 > drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 14 +- > drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 45 + > drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 3 + > drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 35 +++- > drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 22 +++ > .../pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h| 5 +- > drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 5 +- > .../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 92 ++ > drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 + > 13 files changed, 443 insertions(+), 8 deletions(-) > > -- > 2.37.1 >
Re: [PATCH v2 2/4] drm/amd/pm: Implement GFXOFF's entry count and residency for vangogh
On Tue, Jul 26, 2022 at 2:23 PM André Almeida wrote:
>
> Implement functions to get and set GFXOFF's entry count and residency
> for vangogh.
>
> Signed-off-by: André Almeida
> ---
> .../pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h| 5 +-
> drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 5 +-
> .../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 92 +++
> 3 files changed, 100 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
> b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
> index fe130a497d6c..7471e2df2828 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
> +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
> @@ -108,7 +108,10 @@
> #define PPSMC_MSG_SetSlowPPTLimit 0x4A
> #define PPSMC_MSG_GetFastPPTLimit 0x4B
> #define PPSMC_MSG_GetSlowPPTLimit 0x4C
> -#define PPSMC_Message_Count0x4D
> +#define PPSMC_MSG_GetGfxOffStatus 0x50
> +#define PPSMC_MSG_GetGfxOffEntryCount 0x51
> +#define PPSMC_MSG_LogGfxOffResidency 0x52
> +#define PPSMC_Message_Count0x53
>
> //Argument for PPSMC_MSG_GfxDeviceDriverReset
> enum {
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> index 19084a4fcb2b..76fb6cbbc09c 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> @@ -235,7 +235,10 @@
> __SMU_DUMMY_MAP(UnforceGfxVid), \
> __SMU_DUMMY_MAP(HeavySBR), \
> __SMU_DUMMY_MAP(SetBadHBMPagesRetiredFlagsPerChannel), \
> - __SMU_DUMMY_MAP(EnableGfxImu),
> + __SMU_DUMMY_MAP(EnableGfxImu), \
> + __SMU_DUMMY_MAP(GetGfxOffStatus),\
> + __SMU_DUMMY_MAP(GetGfxOffEntryCount),\
> + __SMU_DUMMY_MAP(LogGfxOffResidency),
>
> #undef __SMU_DUMMY_MAP
> #define __SMU_DUMMY_MAP(type) SMU_MSG_##type
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> index 89504ff8e9ed..4e547573698b 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> @@ -138,6 +138,9 @@ static struct cmn2asic_msg_mapping
> vangogh_message_map[SMU_MSG_MAX_COUNT] = {
> MSG_MAP(SetSlowPPTLimit,
> PPSMC_MSG_SetSlowPPTLimit, 0),
> MSG_MAP(GetFastPPTLimit,
> PPSMC_MSG_GetFastPPTLimit, 0),
> MSG_MAP(GetSlowPPTLimit,
> PPSMC_MSG_GetSlowPPTLimit, 0),
> + MSG_MAP(GetGfxOffStatus,
> PPSMC_MSG_GetGfxOffStatus, 0),
> + MSG_MAP(GetGfxOffEntryCount,
> PPSMC_MSG_GetGfxOffEntryCount, 0),
> + MSG_MAP(LogGfxOffResidency,
> PPSMC_MSG_LogGfxOffResidency, 0),
> };
>
> static struct cmn2asic_mapping vangogh_feature_mask_map[SMU_FEATURE_COUNT] =
> {
> @@ -2200,6 +2203,92 @@ static int vangogh_set_power_limit(struct smu_context
> *smu,
> return ret;
> }
>
> +/**
> + * vangogh_set_gfxoff_residency
> + *
> + * @smu: amdgpu_device pointer
> + * @start: start/stop residency log
> + *
> + * This function will be used to log gfxoff residency
> + *
> + *
> + * Returns standard response codes.
> + */
> +static u32 vangogh_set_gfxoff_residency(struct smu_context *smu, bool start)
> +{
> + int ret = 0;
> + u32 residency;
> + struct amdgpu_device *adev = smu->adev;
> +
> + switch (adev->ip_versions[MP1_HWIP][0]) {
> + case IP_VERSION(11, 5, 0):
Minor nit, but you can drip the IP version checks here. This whole
file is specific to 11.5.
> + if (!(adev->pm.pp_feature & PP_GFXOFF_MASK))
> + return 0;
> + ret = smu_cmn_send_smc_msg_with_param(smu,
> SMU_MSG_LogGfxOffResidency,
> + start, );
> + if (!start)
> + adev->gfx.gfx_off_residency = residency;
> + break;
> + default:
> + break;
> + }
> +
> + return ret;
> +}
> +
> +/**
> + * vangogh_get_gfxoff_residency
> + *
> + * @smu: amdgpu_device pointer
> + *
> + * This function will be used to get gfxoff residency.
> + *
> + * Returns standard response codes.
> + */
> +static u32 vangogh_get_gfxoff_residency(struct smu_context *smu, uint32_t
> *residency)
> +{
> + int ret = 0;
> + struct amdgpu_device *adev = smu->adev;
> +
> + switch
Re: [PATCH v4 1/2] dt-bindings: panel-simple-dsi: add Tianma TL057FVXP01
On Wed, 10 Aug 2022 00:13:53 -0400, Julian Braha wrote: > Adds the bindings for the Tianma TL057FVXP01 DSI panel, > found on the Motorola Moto G6. > > Signed-off-by: Julian Braha > --- > v4: > Fixed makefile entry. > > v3: > Fixed kconfig dependencies. > > v2: > Fixed accidental whitespace deletion. > --- > .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed.
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter wrote:
>
> On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote:
> > On 7/6/22 00:48, Rob Clark wrote:
> > > On Tue, Jul 5, 2022 at 4:51 AM Christian König
> > > wrote:
> > >>
> > >> Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
> > >>> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
> > >>> handle imported dma-bufs properly, which results in mapping of something
> > >>> else than the imported dma-buf. On NVIDIA Tegra we get a hard lockup
> > >>> when
> > >>> userspace writes to the memory mapping of a dma-buf that was imported
> > >>> into
> > >>> Tegra's DRM GEM.
> > >>>
> > >>> Majority of DRM drivers prohibit mapping of the imported GEM objects.
> > >>> Mapping of imported GEMs require special care from userspace since it
> > >>> should sync dma-buf because mapping coherency of the exporter device may
> > >>> not match the DRM device. Let's prohibit the mapping for all DRM drivers
> > >>> for consistency.
> > >>>
> > >>> Suggested-by: Thomas Hellström
> > >>> Signed-off-by: Dmitry Osipenko
> > >>
> > >> I'm pretty sure that this is the right approach, but it's certainly more
> > >> than possible that somebody abused this already.
> > >
> > > I suspect that this is abused if you run deqp cts on android.. ie. all
> > > winsys buffers are dma-buf imports from gralloc. And then when you
> > > hit readpix...
> > >
> > > You might only hit this in scenarios with separate gpu and display (or
> > > dGPU+iGPU) because self-imports are handled differently in
> > > drm_gem_prime_import_dev().. and maybe not in cases where you end up
> > > with a blit from tiled/compressed to linear.. maybe that narrows the
> > > scope enough to just fix it in userspace?
> >
> > Given that that only drivers which use DRM-SHMEM potentially could've
> > map imported dma-bufs (Panfrost, Lima) and they already don't allow to
> > do that, I think we're good.
>
> So can I have an ack from Rob here or are there still questions that this
> might go boom?
>
> Dmitry, since you have a bunch of patches merged now I think would also be
> good to get commit rights so you can drive this more yourself. I've asked
> Daniel Stone to help you out with getting that.
I *think* we'd be ok with this on msm, mostly just by dumb luck.
Because the dma-buf's we import will be self-import. I'm less sure
about panfrost (src/panfrost/lib/pan_bo.c doesn't seem to have a
special path for imported dma-bufs either, and in that case they won't
be self-imports.. but I guess no one has tried to run android cts on
panfrost).
What about something less drastic to start, like (apologies for
hand-edited patch):
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 86d670c71286..fc9ec42fa0ab 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object
*obj, unsigned long obj_size,
{
int ret;
+ WARN_ON_ONCE(obj->import_attach);
+
/* Check for valid size. */
if (obj_size < vma->vm_end - vma->vm_start)
return -EINVAL;
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 8ad0e02991ca..6190f5018986 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -609,17 +609,8 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
*/
int drm_gem_shmem_mmap(struct drm_gem_shmem_object *shmem, struct
vm_area_struct *vma)
{
- struct drm_gem_object *obj = >base;
int ret;
if (obj->import_attach) {
- /* Drop the reference drm_gem_mmap_obj() acquired.*/
- drm_gem_object_put(obj);
- vma->vm_private_data = NULL;
-
- return dma_buf_mmap(obj->dma_buf, vma, 0);
+ return -EINVAL;
}
ret = drm_gem_shmem_get_pages(shmem);
if (ret) {
drm_gem_vm_close(vma);
--
2.36.1
Re: [PATCH] drm/ast: radeon amdgpu for ast add prime
Hi oushixiong,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-intel/for-linux-next linus/master v5.19
next-20220810]
[cannot apply to drm-misc/drm-misc-next drm-tip/drm-tip]
[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/oushixiong/drm-ast-radeon-amdgpu-for-ast-add-prime/20220810-100424
base: git://anongit.freedesktop.org/drm/drm drm-next
config: i386-allyesconfig
(https://download.01.org/0day-ci/archive/20220810/202208102237.mz7bao9a-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-3) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/a2b719dc6ac02cee10916696a4ba1caf7b24b20f
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
oushixiong/drm-ast-radeon-amdgpu-for-ast-add-prime/20220810-100424
git checkout a2b719dc6ac02cee10916696a4ba1caf7b24b20f
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/ast/
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/ast/ast_drv.c:54:24: warning: no previous prototype for
>> 'ast_gem_prime_import_sg_table' [-Wmissing-prototypes]
54 | struct drm_gem_object *ast_gem_prime_import_sg_table(struct
drm_device *dev,
|^
--
>> drivers/gpu/drm/ast/ast_mode.c:1713:5: warning: no previous prototype for
>> 'ast_handle_damage' [-Wmissing-prototypes]
1713 | int ast_handle_damage(struct drm_framebuffer *fb, int x, int y,
| ^
>> drivers/gpu/drm/ast/ast_mode.c:1772:5: warning: no previous prototype for
>> 'ast_user_framebuffer_dirty' [-Wmissing-prototypes]
1772 | int ast_user_framebuffer_dirty(struct drm_framebuffer *fb,
| ^~
>> drivers/gpu/drm/ast/ast_mode.c:1815:1: warning: no previous prototype for
>> 'ast_gem_fb_create_with_dirty' [-Wmissing-prototypes]
1815 | ast_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file
*file,
| ^~~~
vim +/ast_gem_prime_import_sg_table +54 drivers/gpu/drm/ast/ast_drv.c
53
> 54 struct drm_gem_object *ast_gem_prime_import_sg_table(struct drm_device
*dev,
55 struct dma_buf_attachment
*attach,
56 struct sg_table *sg)
57 {
58 struct drm_gem_vram_object *gbo;
59 struct dma_resv *resv = attach->dmabuf->resv;
60
61 ww_mutex_lock(>lock, NULL);
62 gbo = drm_gem_vram_create(dev, attach->dmabuf->size, 0, sg,
resv);
63 ww_mutex_unlock(>lock);
64
65 if (IS_ERR(gbo))
66 return NULL;
67
68 return >bo.base;
69 }
70
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Re: [PATCH 1/7] dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles
On 10/08/2022 06:50, Bjorn Andersson wrote: > Add compatibles for the DisplayPort and Embedded DisplayPort blocks in > Qualcomm SDM845 and SC8280XP platforms. > > Signed-off-by: Bjorn Andersson > --- > .../devicetree/bindings/display/msm/dp-controller.yaml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > index 94bc6e1b6451..90f9302d1731 100644 > --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > @@ -16,11 +16,14 @@ description: | > properties: >compatible: > enum: > + - qcom,sdm845-dp >- qcom,sc7180-dp Alphabetical order, please. The DTS warnings from the bot look unrelated to this patch. Best regards, Krzysztof
Re: [PATCH] drm/drm_edid: Refactor HFVSDB parsing for DSC1.2
On 8/2/2022 8:19 PM, Jani Nikula wrote:
On Fri, 22 Jul 2022, Ankit Nautiyal wrote:
DSC capabilities are given in bytes 11-13 of VSDB (i.e. bytes 8-10 of
SCDS). Since minimum length of Data block is 7, all bytes greater than 7
must be read only after checking the length of the data block.
This patch adds check for data block length before reading relavant DSC
bytes. It also corrects min DSC BPC to 8, and minor refactoring for
better readability, and proper log messages.
I think this patch tries to do too much at once. Please split it up. One
thing per patch.
I think the logging is excessive, and what logging remains should use
drm_dbg_kms() instead of DRM_DEBUG_KMS().
Further comments inline.
Hi Jani,
Thanks for the comments. I do agree, it makes more sense to have a
separate patches with incremental changes.
Will send another series with the comments addressed.
Please find the response inline:
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 124 +++--
1 file changed, 77 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bbc25e3b7220..f683a8d5fd31 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5703,12 +5703,58 @@ static void drm_parse_ycbcr420_deep_color_info(struct
drm_connector *connector,
hdmi->y420_dc_modes = dc_mask;
}
+static void drm_parse_dsc_slice_info(u8 dsc_max_slices,
+struct drm_hdmi_dsc_cap *hdmi_dsc)
Arguments should always be in the order: context, destination, source.
Noted. Will take care in the next patch.
+{
+ switch (dsc_max_slices) {
+ case 1:
+ hdmi_dsc->max_slices = 1;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 2:
+ hdmi_dsc->max_slices = 2;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 3:
+ hdmi_dsc->max_slices = 4;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 4:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 5:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 6:
+ hdmi_dsc->max_slices = 12;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 7:
+ hdmi_dsc->max_slices = 16;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 0:
+ default:
+ hdmi_dsc->max_slices = 0;
+ hdmi_dsc->clk_per_slice = 0;
+ }
+}
+
/* Sink Capability Data Structure */
static void drm_parse_hdmi_forum_scds(struct drm_connector *connector,
const u8 *hf_scds)
{
struct drm_display_info *display = >display_info;
struct drm_hdmi_info *hdmi = >hdmi;
+ u8 db_length = hf_scds[0] & 0x1F;
There's cea_db_payload_len() for this, and you can use that directly
instead of caching the value to a local variable.
Right, will use the function here.
+ u8 dsc_max_frl_rate;
+ u8 dsc_max_slices;
These two are local to a tiny if block and should be declared there.
Agreed. Will fix in the next patchset.
+ struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
+
+ if (db_length < 7 || db_length > 31)
+ return;
Both cea_db_is_hdmi_forum_vsdb() and cea_db_is_hdmi_forum_scdb() check
the payload is >= 7 bytes before this one even gets called.
There's no reason to not parse the first 31 bytes if the length is > 31
bytes. That condition just breaks future compatibility for no reason.
Makes sense, will drop these checks.
display->has_hdmi_infoframe = true;
@@ -5749,17 +5795,25 @@ static void drm_parse_hdmi_forum_scds(struct drm_connector *connector,
if (hf_scds[7]) {
u8 max_frl_rate;
- u8 dsc_max_frl_rate;
- u8 dsc_max_slices;
- struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
- DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_scds[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
+ if (max_frl_rate)
+ DRM_DEBUG_KMS("HDMI2.1 FRL support detected\n");
+
drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>max_frl_rate_per_lane);
+
+ drm_parse_ycbcr420_deep_color_info(connector, hf_scds);
+ }
+
+ if (db_length < 11)
+ return;
+
+ if (hf_scds[11]) {
Matter of taste, but I'd probably make these
if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11])
and drop the early returns, and add a single (or very few) debug logging
call at the end.
Hmm. We can get rid of early return.
Will have a separate patch to have logging call at the
Re: New subsystem for acceleration devices
On Wed, Aug 10, 2022 at 5:10 PM wrote: > > > -Original Message- > > From: Oded Gabbay > > Sent: Wednesday, August 10, 2022 6:42 AM > > To: Dave Airlie ; Greg Kroah-Hartman > > ; ishikawa yuji(石川 悠司 ○ＲＤＣ□ＡＩＴＣ○ > > ＥＡ開) ; Jiho Chu > > Cc: dri-devel ; Arnd Bergmann > > ; Linux-Kernel@Vger. Kernel. Org > > ; Jason Gunthorpe > > Subject: Re: New subsystem for acceleration devices > > > > Hi Jiho, Yuji. > > > > I want to update that I'm currently in discussions with Dave to figure out > > what's > > the best way to move forward. We are writing it down to do a proper > > comparison > > between the two paths (new accel subsystem or using drm). I guess it will > > take > > a week or so. > > > > In the meantime, I'm putting the accel code on hold. I have only managed to > > do > > the very basic infra and add a demo driver that shows how to register and > > unregister from it. > > You can check the code at: > > https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux.git/log/?h=ac > > cel > > > > It has two commits. The first adds the subsystem code and the second adds > > the > > demo driver. > > The subsystem code is basically drm code copied and renamed and slightly > > modified, but I really only worked on it for a couple of hours so take that > > into > > consideration. > > > > The important thing is that the demo driver shows the basic steps are really > > simple. You need to add two function calls in your probe and one function > > call in > > your release. Of course you will need to supply some function callbacks, > > but I > > haven't got to fill that in the demo driver. Once you register, you get > > /dev/accel/ac0 and > > /dev/accel/ac_controlD64 (if you want a control device). If I were to > > continue > > this, the next step is to do the open and close part. > > > > I will update once we know where things are heading. As I said, I imagine > > it can > > take a few weeks. > > > > Thanks, > > Oded > > Hi Odded, > Thank you for uploading the framework as well as a sample. > It's exciting to see new software is growing up. > > Since Visconti DNN is a platform device, I'll write some test code to > initialize driver and see if it works. > > Regards, > Yuji Platform or PCI, it doesn't matter. You just call it from the probe. But really, this is something I did in a few hours and I stopped because there were some objections and I wanted to first talk about it with Dave. I don't know if it's worth it for you to waste time on it at this point. Thanks, Oded
RE: New subsystem for acceleration devices
> -Original Message- > From: Oded Gabbay > Sent: Wednesday, August 10, 2022 6:42 AM > To: Dave Airlie ; Greg Kroah-Hartman > ; ishikawa yuji(石川 悠司 ○ＲＤＣ□ＡＩＴＣ○ > ＥＡ開) ; Jiho Chu > Cc: dri-devel ; Arnd Bergmann > ; Linux-Kernel@Vger. Kernel. Org > ; Jason Gunthorpe > Subject: Re: New subsystem for acceleration devices > > Hi Jiho, Yuji. > > I want to update that I'm currently in discussions with Dave to figure out > what's > the best way to move forward. We are writing it down to do a proper comparison > between the two paths (new accel subsystem or using drm). I guess it will take > a week or so. > > In the meantime, I'm putting the accel code on hold. I have only managed to do > the very basic infra and add a demo driver that shows how to register and > unregister from it. > You can check the code at: > https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux.git/log/?h=ac > cel > > It has two commits. The first adds the subsystem code and the second adds the > demo driver. > The subsystem code is basically drm code copied and renamed and slightly > modified, but I really only worked on it for a couple of hours so take that > into > consideration. > > The important thing is that the demo driver shows the basic steps are really > simple. You need to add two function calls in your probe and one function > call in > your release. Of course you will need to supply some function callbacks, but I > haven't got to fill that in the demo driver. Once you register, you get > /dev/accel/ac0 and > /dev/accel/ac_controlD64 (if you want a control device). If I were to continue > this, the next step is to do the open and close part. > > I will update once we know where things are heading. As I said, I imagine it > can > take a few weeks. > > Thanks, > Oded Hi Odded, Thank you for uploading the framework as well as a sample. It's exciting to see new software is growing up. Since Visconti DNN is a platform device, I'll write some test code to initialize driver and see if it works. Regards, Yuji
Re: [PATCH 1/2] drm/cmdline-parser: Merge negative tests
On 8/4/22 10:17, Michał Winiarski wrote:
> Negative tests can be expressed as a single parameterized test case,
> which highlights that we're following the same test logic (passing
> negative cmdline and expecting drm_mode_parse_command_line_for_connector
> to fail), which improves readability.
>
> Signed-off-by: Michał Winiarski
Tested-by: Maíra Canal
Best Regards,
- Maíra Canal
> ---
> .../gpu/drm/tests/drm_cmdline_parser_test.c | 293 ++
> 1 file changed, 103 insertions(+), 190 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> index 59b29cdfdd35..058808faaf4a 100644
> --- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> +++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> @@ -109,24 +109,6 @@ static void drm_cmdline_test_force_d_only(struct kunit
> *test)
> KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_OFF);
> }
>
> -static void drm_cmdline_test_margin_only(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "m";
> -
> - KUNIT_EXPECT_FALSE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> -static void drm_cmdline_test_interlace_only(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "i";
> -
> - KUNIT_EXPECT_FALSE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> static void drm_cmdline_test_res(struct kunit *test)
> {
> struct drm_cmdline_mode mode = { };
> @@ -149,42 +131,6 @@ static void drm_cmdline_test_res(struct kunit *test)
> KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
> }
>
> -static void drm_cmdline_test_res_missing_x(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "x480";
> -
> - KUNIT_EXPECT_FALSE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> -static void drm_cmdline_test_res_missing_y(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "1024x";
> -
> - KUNIT_EXPECT_FALSE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> -static void drm_cmdline_test_res_bad_y(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "1024xtest";
> -
> - KUNIT_EXPECT_FALSE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> -static void drm_cmdline_test_res_missing_y_bpp(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "1024x-24";
> -
> - KUNIT_EXPECT_FALSE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> static void drm_cmdline_test_res_vesa(struct kunit *test)
> {
> struct drm_cmdline_mode mode = { };
> @@ -274,15 +220,6 @@ static void drm_cmdline_test_res_bpp(struct kunit *test)
> KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
> }
>
> -static void drm_cmdline_test_res_bad_bpp(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "720x480-test";
> -
> - KUNIT_EXPECT_FALSE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> static void drm_cmdline_test_res_refresh(struct kunit *test)
> {
> struct drm_cmdline_mode mode = { };
> @@ -306,15 +243,6 @@ static void drm_cmdline_test_res_refresh(struct kunit
> *test)
> KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
> }
>
> -static void drm_cmdline_test_res_bad_refresh(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "720x480@refresh";
> -
> - KUNIT_EXPECT_FALSE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> static void drm_cmdline_test_res_bpp_refresh(struct kunit *test)
> {
> struct drm_cmdline_mode mode = { };
> @@ -411,15 +339,6 @@ static void
> drm_cmdline_test_res_bpp_refresh_force_off(struct kunit *test)
> KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_OFF);
> }
>
> -static void drm_cmdline_test_res_bpp_refresh_force_on_off(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline =
Re: [PATCH 2/2] drm/cmdline-parser: Use assert when needed
Hi Michał
On 8/4/22 10:17, Michał Winiarski wrote:
> Expecting to observe a specific value, when the function responsible for
> setting the value has failed will lead to extra noise in test output.
> Use assert when the situation calls for it.
> Also - very small tidying up around the changed areas (whitespace /
> variable locality).
>
> Signed-off-by: Michał Winiarski
> ---
> .../gpu/drm/tests/drm_cmdline_parser_test.c | 93 +--
> 1 file changed, 46 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> index 058808faaf4a..7a313e2fd52a 100644
> --- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> +++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> @@ -16,7 +16,7 @@ static void drm_cmdline_test_force_e_only(struct kunit
> *test)
> struct drm_cmdline_mode mode = { };
> const char *cmdline = "e";
>
> - KUNIT_EXPECT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> + KUNIT_ASSERT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
>
> _connector, ));
> KUNIT_EXPECT_FALSE(test, mode.specified);
> KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
> @@ -34,7 +34,7 @@ static void
> drm_cmdline_test_force_D_only_not_digital(struct kunit *test)
> struct drm_cmdline_mode mode = { };
> const char *cmdline = "D";
>
> - KUNIT_EXPECT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> + KUNIT_ASSERT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
>
> _connector, ));
> KUNIT_EXPECT_FALSE(test, mode.specified);
> KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
> @@ -47,16 +47,16 @@ static void
> drm_cmdline_test_force_D_only_not_digital(struct kunit *test)
> KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_ON);
> }
>
> -static const struct drm_connector connector_hdmi = {
> - .connector_type = DRM_MODE_CONNECTOR_HDMIB,
> -};
Minor nit: I guess you miss to delete a line.
>
> static void drm_cmdline_test_force_D_only_hdmi(struct kunit *test)
> {
> struct drm_cmdline_mode mode = { };
> + const struct drm_connector connector_hdmi = {
> + .connector_type = DRM_MODE_CONNECTOR_HDMIB,
> + };
As the kernel test robot pointed out, this leads to stack issues (also
with PowerPC). You might want to leave it as it was or allocate it with
kunit_kzalloc.
Best Regards,
- Maíra Canal
> const char *cmdline = "D";
>
> - KUNIT_EXPECT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> + KUNIT_ASSERT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
>
> _hdmi, ));
> KUNIT_EXPECT_FALSE(test, mode.specified);
> KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
> @@ -69,16 +69,15 @@ static void drm_cmdline_test_force_D_only_hdmi(struct
> kunit *test)
> KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_ON_DIGITAL);
> }
>
> -static const struct drm_connector connector_dvi = {
> - .connector_type = DRM_MODE_CONNECTOR_DVII,
> -};
> -
> static void drm_cmdline_test_force_D_only_dvi(struct kunit *test)
> {
> struct drm_cmdline_mode mode = { };
> + const struct drm_connector connector_dvi = {
> + .connector_type = DRM_MODE_CONNECTOR_DVII,
> + };> const char *cmdline = "D";
>
> - KUNIT_EXPECT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> + KUNIT_ASSERT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
>
> _dvi, ));
> KUNIT_EXPECT_FALSE(test, mode.specified);
> KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
> @@ -96,7 +95,7 @@ static void drm_cmdline_test_force_d_only(struct kunit
> *test)
> struct drm_cmdline_mode mode = { };
> const char *cmdline = "d";
>
> - KUNIT_EXPECT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> + KUNIT_ASSERT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
>
> _connector, ));
> KUNIT_EXPECT_FALSE(test, mode.specified);
> KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
> @@ -114,7 +113,7 @@ static void drm_cmdline_test_res(struct kunit *test)
> struct drm_cmdline_mode mode = { };
> const char *cmdline = "720x480";
>
> - KUNIT_EXPECT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
> + KUNIT_ASSERT_TRUE(test,
> drm_mode_parse_command_line_for_connector(cmdline,
>
> _connector, ));
> KUNIT_EXPECT_TRUE(test, mode.specified);
>
Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi Christian,
Thanks for your comments, please find my answer below.
On mer., 2022-08-10 at 11:43 +0200, Christian König wrote:
> Caution: EXT Email
>
> Hi guys,
>
> Am 05.08.22 um 15:53 schrieb Olivier Masse:
> > add Linaro secure heap bindings: linaro,secure-heap
> > use genalloc to allocate/free buffer from buffer pool.
> > buffer pool info is from dts.
> > use sg_table instore the allocated memory info, the length of
> > sg_table is 1.
> > implement secure_heap_buf_ops to implement buffer share in
> > difference device:
> > 1. Userspace passes this fd to all drivers it wants this buffer
> > to share with: First the filedescriptor is converted to a _buf
> > using
> > dma_buf_get(). Then the buffer is attached to the device using
> > dma_buf_attach().
> > 2. Once the buffer is attached to all devices userspace can
> > initiate DMA
> > access to the shared buffer. In the kernel this is done by calling
> > dma_buf_map_attachment()
> > 3. get sg_table with dma_buf_map_attachment in difference device.
>
> I'm not sure Christoph will approve that you are messing with the sg
> table internals so much here.
>
> Why are you not using the DMA API directly for this?
Do you mean for secure_heap_map_dma_buf and secure_heap_unmap_dma_buf ?
If yes, maybe something like the following could be more appropriate:
static struct sg_table *secure_heap_map_dma_buf(struct dma_buf_attachment
*attachment,
enum dma_data_direction
direction)
{
struct secure_heap_attachment *a = attachment->priv;
struct sg_table *sgt;
sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
if (!sgt) {
dev_err(a->dev, "failed to alloc sg table\n");
return NULL;
}
ret = dma_get_sgtable(a->dev, sgt, NULL, sg_dma_address(a->table->sgl),
sg_dma_len(a->table->sgl));
if (ret < 0) {
dev_err(a->dev, "failed to get scatterlist from DMA API\n");
kfree(sgt);
return NULL;
}
return sgt;
}
Regards,
Olivier
>
> Regards,
> Christian.
>
> >
> > Signed-off-by: Olivier Masse
> > ---
> > drivers/dma-buf/heaps/Kconfig | 9 +
> > drivers/dma-buf/heaps/Makefile | 1 +
> > drivers/dma-buf/heaps/secure_heap.c | 357
> >
> > 3 files changed, 367 insertions(+)
> > create mode 100644 drivers/dma-buf/heaps/secure_heap.c
> >
> > diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-
> > buf/heaps/Kconfig
> > index 3782eeeb91c0..c9070c728b9a 100644
> > --- a/drivers/dma-buf/heaps/Kconfig
> > +++ b/drivers/dma-buf/heaps/Kconfig
> > @@ -20,3 +20,12 @@ config DMABUF_HEAPS_DSP
> > Choose this option to enable the dsp dmabuf heap. The
> > dsp heap
> > is allocated by gen allocater. it's allocated according
> > the dts.
> > If in doubt, say Y.
> > +
> > +config DMABUF_HEAPS_SECURE
> > + tristate "DMA-BUF Secure Heap"
> > + depends on DMABUF_HEAPS
> > + help
> > + Choose this option to enable the secure dmabuf heap. The
> > secure heap
> > + pools are defined according to the DT. Heaps are allocated
> > + in the pools using gen allocater.
> > + If in doubt, say Y.
> > diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-
> > buf/heaps/Makefile
> > index 29733f84c354..863ef10056a3 100644
> > --- a/drivers/dma-buf/heaps/Makefile
> > +++ b/drivers/dma-buf/heaps/Makefile
> > @@ -2,3 +2,4 @@
> > obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
> > obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> > obj-$(CONFIG_DMABUF_HEAPS_DSP) += dsp_heap.o
> > +obj-$(CONFIG_DMABUF_HEAPS_SECURE)+= secure_heap.o
> > diff --git a/drivers/dma-buf/heaps/secure_heap.c b/drivers/dma-
> > buf/heaps/secure_heap.c
> > new file mode 100644
> > index ..25b3629613f3
> > --- /dev/null
> > +++ b/drivers/dma-buf/heaps/secure_heap.c
> > @@ -0,0 +1,357 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * DMABUF secure heap exporter
> > + *
> > + * Copyright 2021 NXP.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MAX_SECURE_HEAP 2
> > +#define MAX_HEAP_NAME_LEN 32
> > +
> > +struct secure_heap_buffer {
> > + struct dma_heap *heap;
> > + struct list_head attachments;
> > + struct mutex lock;
> > + unsigned long len;
> > + struct sg_table sg_table;
> > + int vmap_cnt;
> > + void *vaddr;
> > +};
> > +
> > +struct secure_heap_attachment {
> > + struct device *dev;
> > + struct sg_table *table;
> > + struct list_head list;
> > +};
> > +
> > +struct secure_heap_info {
> > + struct gen_pool *pool;
> > +};
> > +
> > +struct rmem_secure {
> > + phys_addr_t base;
> > + phys_addr_t size;
> >
Re: [PATCH 1/7] dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles
On Tue, 09 Aug 2022 20:50:07 -0700, Bjorn Andersson wrote: > Add compatibles for the DisplayPort and Embedded DisplayPort blocks in > Qualcomm SDM845 and SC8280XP platforms. > > Signed-off-by: Bjorn Andersson > --- > .../devicetree/bindings/display/msm/dp-controller.yaml | 3 +++ > 1 file changed, 3 insertions(+) > Running 'make dtbs_check' with the schema in this patch gives the following warnings. Consider if they are expected or the schema is incorrect. These may not be new warnings. Note that it is not yet a requirement to have 0 warnings for dtbs_check. This will change in the future. Full log is available here: https://patchwork.ozlabs.org/patch/ displayport-controller@ae9: '#clock-cells', 'data-lanes', 'opp-table', 'vdda-0p9-supply', 'vdda-1p2-supply' do not match any of the regexes: 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r1.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r1-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r3.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r3-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar-r2.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar-r3.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar-r4.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots-r4.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots-r5.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots-r9.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-r4.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-r9.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1-kb.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-kb.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r9.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r9-kb.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r9-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r1.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r1-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r2.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r2-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r3.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r3-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-r1-lte.dtb displayport-controller@ae9: '#clock-cells', 'opp-table' do not match any of the regexes: 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/sc7180-idp.dtb arch/arm64/boot/dts/qcom/sc7280-crd-r3.dtb arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dtb arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dtb arch/arm64/boot/dts/qcom/sc7280-herobrine-villager-r0.dtb arch/arm64/boot/dts/qcom/sc7280-idp2.dtb arch/arm64/boot/dts/qcom/sc7280-idp.dtb displayport-controller@ae9: reg: [[0, 183042048, 0, 5120]] is too short arch/arm64/boot/dts/qcom/sc7180-idp.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r1.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r1-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r3.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r3-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar-r2.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar-r3.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar-r4.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots-r4.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots-r5.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots-r9.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-r4.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-r9.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1-kb.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-kb.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r9.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r9-kb.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r9-lte.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r1.dtb arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r1-lte.dtb
Re: [PATCH v2 1/3] drm/dp_mst: add passthrough_aux to struct drm_dp_mst_port
On 2022-08-09 18:01, Lyude Paul wrote:
Ah yes of course! Probably should have asked when I gave the r-b :). Also,
just so patchwork actually catches it I will say the magic incantation:
Reviewed-by: Lyude Paul
Do we want to merge just this patch to drm-misc-next, or do you want to merge
the whole series through there? If you'd rather just merge this through amd's
branch I'm fine with that as well
In that case, it is preferable to have all of the patches in this series
to get merged through amd's branch.
On Tue, 2022-08-09 at 11:15 -0400, Hamza Mahfooz wrote:
Hey Lyude,
On 2022-08-05 17:17, Lyude Paul wrote:
lgtm!
Any chance you can apply this to drm-misc-next?
Reviewed-by: Lyude Paul
On Fri, 2022-08-05 at 17:13 -0400, Hamza Mahfooz wrote:
Currently, there is no way to identify if DSC pass-through can be
enabled and what aux DSC pass-through requests ought to be sent to. So,
add a variable to struct drm_dp_mst_port that keeps track of the
aforementioned information.
Signed-off-by: Hamza Mahfooz
---
v2: define DP_DSC_PASSTHROUGH_IS_SUPPORTED
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +++-
include/drm/display/drm_dp.h | 1 +
include/drm/display/drm_dp_mst_helper.h | 3 +++
3 files changed, 7 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 67b3b9697da7..71915afd9892 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -5921,8 +5921,10 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
drm_dp_mst_port *port)
/* Enpoint decompression with DP-to-DP peer device */
if ((endpoint_dsc & DP_DSC_DECOMPRESSION_IS_SUPPORTED) &&
(endpoint_fec & DP_FEC_CAPABLE) &&
- (upstream_dsc & 0x2) /* DSC passthrough */)
+ (upstream_dsc & DP_DSC_PASSTHROUGH_IS_SUPPORTED)) {
+ port->passthrough_aux = _upstream_port->aux;
return >aux;
+ }
/* Virtual DPCD decompression with DP-to-DP peer device */
return _upstream_port->aux;
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 9e3aff7e68bb..4d0abe4c7ea9 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -239,6 +239,7 @@
#define DP_DSC_SUPPORT 0x060 /* DP 1.4 */
# define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0)
+# define DP_DSC_PASSTHROUGH_IS_SUPPORTED(1 << 1)
#define DP_DSC_REV 0x061
# define DP_DSC_MAJOR_MASK (0xf << 0)
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index 10adec068b7f..4a39c95f8afd 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -86,6 +86,8 @@ struct drm_dp_vcpi {
* @next: link to next port on this branch device
* @aux: i2c aux transport to talk to device connected to this port,
protected
* by _dp_mst_topology_mgr.base.lock.
+ * @passthrough_aux: parent aux to which DSC pass-through requests should be
+ * sent, only set if DSC pass-through is possible.
* @parent: branch device parent of this port
* @vcpi: Virtual Channel Payload info for this port.
* @connector: DRM connector this port is connected to. Protected by
@@ -140,6 +142,7 @@ struct drm_dp_mst_port {
*/
struct drm_dp_mst_branch *mstb;
struct drm_dp_aux aux; /* i2c bus for this port? */
+ struct drm_dp_aux *passthrough_aux;
struct drm_dp_mst_branch *parent;
struct drm_dp_vcpi vcpi;
--
Hamza
[PATCH] spi/panel: dt-bindings: drop 3-wire from common properties
The spi-3wire property is device specific and should be accepted only if device really needs them. Drop it from common spi-peripheral-props.yaml schema, mention in few panel drivers which use it and include instead in the SPI controller bindings. The controller bindings will provide spi-3wire type validation and one place for description. Each device schema must list the property if it is applicable. The Samsung S6E63M0 panel uses also spi-cpha/cpol properties on at least one board (ste-ux500-samsung-janice/dts), so add also these to the panel's bindings. Signed-off-by: Krzysztof Kozlowski --- .../bindings/display/panel/kingdisplay,kd035g6-54nt.yaml | 2 ++ .../bindings/display/panel/leadtek,ltk035c5444t.yaml | 2 ++ .../devicetree/bindings/display/panel/samsung,s6e63m0.yaml | 4 Documentation/devicetree/bindings/spi/spi-controller.yaml| 5 + .../devicetree/bindings/spi/spi-peripheral-props.yaml| 5 - 5 files changed, 13 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml index 2a2756d19681..b4be9bd8ddde 100644 --- a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml +++ b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml @@ -23,6 +23,8 @@ properties: reg: true reset-gpios: true + spi-3wire: true + required: - compatible - power-supply diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml index 817a9bed7d5a..ebdca5f5a001 100644 --- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml @@ -24,6 +24,8 @@ properties: reg: true reset-gpios: true + spi-3wire: true + required: - compatible - power-supply diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml index 940f7f88526f..6f1fc7469f07 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml @@ -24,6 +24,10 @@ properties: default-brightness: true max-brightness: true + spi-3wire: true + spi-cpha: true + spi-cpol: true + vdd3-supply: description: VDD regulator diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 655713fba7e2..01042a7f382e 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -96,6 +96,11 @@ patternProperties: $ref: spi-peripheral-props.yaml properties: + spi-3wire: +$ref: /schemas/types.yaml#/definitions/flag +description: + The device requires 3-wire mode. + spi-cpha: $ref: /schemas/types.yaml#/definitions/flag description: diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml index ce048e782e80..4beeb9e17694 100644 --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml @@ -29,11 +29,6 @@ properties: description: Chip select used by the device. - spi-3wire: -$ref: /schemas/types.yaml#/definitions/flag -description: - The device requires 3-wire mode. - spi-cs-high: $ref: /schemas/types.yaml#/definitions/flag description: -- 2.34.1
Re: [PATCH] virt: acrn: obtain pa from VMA with PFNMAP flag
On Mon, Feb 28, 2022 at 05:22:12AM +0300, Yonghua Huang wrote:
> acrn_vm_ram_map can't pin the user pages with VM_PFNMAP flag
> by calling get_user_pages_fast(), the PA(physical pages)
> may be mapped by kernel driver and set PFNMAP flag.
>
> This patch fixes logic to setup EPT mapping for PFN mapped RAM region
> by checking the memory attribute before adding EPT mapping for them.
>
> Fixes: 88f537d5e8dd ("virt: acrn: Introduce EPT mapping management")
> Signed-off-by: Yonghua Huang
> Signed-off-by: Fei Li
> ---
> drivers/virt/acrn/mm.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/virt/acrn/mm.c b/drivers/virt/acrn/mm.c
> index c4f2e15c8a2b..3b1b1e7a844b 100644
> --- a/drivers/virt/acrn/mm.c
> +++ b/drivers/virt/acrn/mm.c
> @@ -162,10 +162,34 @@ int acrn_vm_ram_map(struct acrn_vm *vm, struct
> acrn_vm_memmap *memmap)
> void *remap_vaddr;
> int ret, pinned;
> u64 user_vm_pa;
> + unsigned long pfn;
> + struct vm_area_struct *vma;
>
> if (!vm || !memmap)
> return -EINVAL;
>
> + mmap_read_lock(current->mm);
> + vma = vma_lookup(current->mm, memmap->vma_base);
> + if (vma && ((vma->vm_flags & VM_PFNMAP) != 0)) {
> + if ((memmap->vma_base + memmap->len) > vma->vm_end) {
> + mmap_read_unlock(current->mm);
> + return -EINVAL;
> + }
> +
> + ret = follow_pfn(vma, memmap->vma_base, );
This races, don't use follow_pfn() and most definitely don't add new
users. In some cases follow_pte, but the pte/pfn is still only valid for
as long as you hold the pte spinlock.
> + mmap_read_unlock(current->mm);
Definitely after here there's zero guarantees about this pfn and it could
point at anything.
Please fix, I tried pretty hard to get rid of follow_pfn(), but some of
them are just too hard to fix (e.g. kvm needs a pretty hug rewrite to get
it all sorted).
Cheers, Daniel
> + if (ret < 0) {
> + dev_dbg(acrn_dev.this_device,
> + "Failed to lookup PFN at VMA:%pK.\n", (void
> *)memmap->vma_base);
> + return ret;
> + }
> +
> + return acrn_mm_region_add(vm, memmap->user_vm_pa,
> + PFN_PHYS(pfn), memmap->len,
> + ACRN_MEM_TYPE_WB, memmap->attr);
> + }
> + mmap_read_unlock(current->mm);
> +
> /* Get the page number of the map region */
> nr_pages = memmap->len >> PAGE_SHIFT;
> pages = vzalloc(nr_pages * sizeof(struct page *));
>
> base-commit: 73878e5eb1bd3c9656685ca60bc3a49d17311e0c
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Linaro-mm-sig] [PATCH] dma-buf/sync_file: use strscpy to replace strlcpy
On Fri, Jul 01, 2022 at 07:26:07PM +0800, XueBing Chen wrote:
>
> The strlcpy should not be used because it doesn't limit the source
> length. Preferred is strscpy.
>
> Signed-off-by: XueBing Chen
I don't think there's an impact here since we don't check the error return
value, but also doesn't hurt.
Thanks for your patch, applied to drm-misc-next.
-Daniel
> ---
> drivers/dma-buf/sync_file.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index 3ebec19a8e02..af57799c86ce 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -132,7 +132,7 @@ EXPORT_SYMBOL(sync_file_get_fence);
> char *sync_file_get_name(struct sync_file *sync_file, char *buf, int len)
> {
> if (sync_file->user_name[0]) {
> - strlcpy(buf, sync_file->user_name, len);
> + strscpy(buf, sync_file->user_name, len);
> } else {
> struct dma_fence *fence = sync_file->fence;
>
> @@ -172,7 +172,7 @@ static struct sync_file *sync_file_merge(const char
> *name, struct sync_file *a,
> return NULL;
> }
> sync_file->fence = fence;
> - strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
> + strscpy(sync_file->user_name, name, sizeof(sync_file->user_name));
> return sync_file;
> }
>
> @@ -262,9 +262,9 @@ static long sync_file_ioctl_merge(struct sync_file
> *sync_file,
> static int sync_fill_fence_info(struct dma_fence *fence,
>struct sync_fence_info *info)
> {
> - strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
> + strscpy(info->obj_name, fence->ops->get_timeline_name(fence),
> sizeof(info->obj_name));
> - strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
> + strscpy(info->driver_name, fence->ops->get_driver_name(fence),
> sizeof(info->driver_name));
>
> info->status = dma_fence_get_status(fence);
> --
> 2.25.1
> ___
> Linaro-mm-sig mailing list -- linaro-mm-...@lists.linaro.org
> To unsubscribe send an email to linaro-mm-sig-le...@lists.linaro.org
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs
On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote: > On 7/6/22 00:48, Rob Clark wrote: > > On Tue, Jul 5, 2022 at 4:51 AM Christian König > > wrote: > >> > >> Am 01.07.22 um 11:02 schrieb Dmitry Osipenko: > >>> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't > >>> handle imported dma-bufs properly, which results in mapping of something > >>> else than the imported dma-buf. On NVIDIA Tegra we get a hard lockup when > >>> userspace writes to the memory mapping of a dma-buf that was imported into > >>> Tegra's DRM GEM. > >>> > >>> Majority of DRM drivers prohibit mapping of the imported GEM objects. > >>> Mapping of imported GEMs require special care from userspace since it > >>> should sync dma-buf because mapping coherency of the exporter device may > >>> not match the DRM device. Let's prohibit the mapping for all DRM drivers > >>> for consistency. > >>> > >>> Suggested-by: Thomas Hellström > >>> Signed-off-by: Dmitry Osipenko > >> > >> I'm pretty sure that this is the right approach, but it's certainly more > >> than possible that somebody abused this already. > > > > I suspect that this is abused if you run deqp cts on android.. ie. all > > winsys buffers are dma-buf imports from gralloc. And then when you > > hit readpix... > > > > You might only hit this in scenarios with separate gpu and display (or > > dGPU+iGPU) because self-imports are handled differently in > > drm_gem_prime_import_dev().. and maybe not in cases where you end up > > with a blit from tiled/compressed to linear.. maybe that narrows the > > scope enough to just fix it in userspace? > > Given that that only drivers which use DRM-SHMEM potentially could've > map imported dma-bufs (Panfrost, Lima) and they already don't allow to > do that, I think we're good. So can I have an ack from Rob here or are there still questions that this might go boom? Dmitry, since you have a bunch of patches merged now I think would also be good to get commit rights so you can drive this more yourself. I've asked Daniel Stone to help you out with getting that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Use of BARs names instead of numbers
On Wed, 10 Aug 2022, Andrzej Hajda wrote: > On 05.08.2022 17:59, Piorkowski, Piotr wrote: >> +/* PCI BARs */ >> +#define GTTMMADR_BAR0 >> +#define GEN2_GTTMMADR_BAR 1 >> +#define GFXMEM_BAR 2 >> +#define GTT_APERTURE_BARGFXMEM_BAR >> +#define GEN12_LMEM_BAR GFXMEM_BAR > > In INTEL_GVT_PCI_BAR_GTTMMIO we have BAR in prefix, here in suffix. > I am not sure which onel is better, just pointing out slight incosistency. Thought about it too, but decided this one's trivial to change if needed. The main change is switching to macros. > Anyway: > Reviewed-by: Andrzej Hajda Thanks, though I already pushed this. :) BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification
Am 25.07.22 um 17:18 schrieb Dmitry Osipenko: This patch moves the non-dynamic dma-buf users over to the dynamic locking specification. The strict locking convention prevents deadlock situation for dma-buf importers and exporters. Previously the "unlocked" versions of the dma-buf API functions weren't taking the reservation lock and this patch makes them to take the lock. Intel and AMD GPU drivers already were mapping imported dma-bufs under the held lock, hence the "locked" variant of the functions are added for them and the drivers are updated to use the "locked" versions. In general "Yes, please", but that won't be that easy. You not only need to change amdgpu and i915, but all drivers implementing the map_dma_buf(), unmap_dma_buf() callbacks. Auditing all that code is a huge bunch of work. Signed-off-by: Dmitry Osipenko --- Documentation/driver-api/dma-buf.rst | 6 + drivers/dma-buf/dma-buf.c | 186 - drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +- drivers/gpu/drm/drm_prime.c| 4 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 8 +- include/linux/dma-buf.h| 28 ++-- 6 files changed, 179 insertions(+), 57 deletions(-) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 36a76cbe9095..622b8156d212 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -119,6 +119,12 @@ DMA Buffer ioctls .. kernel-doc:: include/uapi/linux/dma-buf.h +DMA-BUF locking convention +~ + +.. kernel-doc:: drivers/dma-buf/dma-buf.c + :doc: locking convention + Kernel Functions and Structures Reference ~ diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d16237a6ffaa..bfdd551c7571 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -559,7 +559,7 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags) * 2. Userspace passes this file-descriptors to all drivers it wants this buffer *to share with: First the file descriptor is converted to a _buf using *dma_buf_get(). Then the buffer is attached to the device using - *dma_buf_attach(). + *dma_buf_attach_unlocked(). * *Up to this stage the exporter is still free to migrate or reallocate the *backing storage. @@ -569,8 +569,8 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags) *dma_buf_map_attachment() and dma_buf_unmap_attachment(). * * 4. Once a driver is done with a shared buffer it needs to call - *dma_buf_detach() (after cleaning up any mappings) and then release the - *reference acquired with dma_buf_get() by calling dma_buf_put(). + *dma_buf_detach_unlocked() (after cleaning up any mappings) and then + *release the reference acquired with dma_buf_get() by calling dma_buf_put(). * * For the detailed semantics exporters are expected to implement see * _buf_ops. @@ -794,6 +794,63 @@ static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach, return sg_table; } +/** + * DOC: locking convention + * + * In order to avoid deadlock situations between dma-buf exports and importers, + * all dma-buf API users must follow the common dma-buf locking convention. + * + * Convention for importers + * + * 1. Importers must hold the dma-buf reservation lock when calling these + *functions: + * + * - dma_buf_pin() + * - dma_buf_unpin() + * - dma_buf_move_notify() This one is called by the exporter, not the importer. Regards, Christian. + * - dma_buf_map_attachment_locked() + * - dma_buf_unmap_attachment_locked() + * + * 2. Importers must not hold the dma-buf reservation lock when calling these + *functions: + * + * - dma_buf_attach_unlocked() + * - dma_buf_dynamic_attach_unlocked() + * - dma_buf_detach_unlocked() + * - dma_buf_export( + * - dma_buf_fd() + * - dma_buf_get() + * - dma_buf_put() + * - dma_buf_begin_cpu_access() + * - dma_buf_end_cpu_access() + * - dma_buf_map_attachment_unlocked() + * - dma_buf_unmap_attachment_unlocked() + * - dma_buf_vmap_unlocked() + * - dma_buf_vunmap_unlocked() + * + * Convention for exporters + * + * 1. These _buf_ops callbacks are invoked with unlocked dma-buf + *reservation and exporter can take the lock: + * + * - _buf_ops.attach() + * - _buf_ops.detach() + * - _buf_ops.release() + * - _buf_ops.begin_cpu_access() + * - _buf_ops.end_cpu_access() + * + * 2. These _buf_ops callbacks are invoked with locked dma-buf + *reservation and exporter can't take the lock: + * + * - _buf_ops.pin() + * - _buf_ops.unpin() + * - _buf_ops.map_dma_buf() + * - _buf_ops.unmap_dma_buf() + * - _buf_ops.mmap() + * - _buf_ops.vmap() + * - _buf_ops.vunmap() + */
[PATCH 1/4] drm/probe-helper: Add drm_connector_helper_get_modes_static()
Add drm_connector_helper_get_modes_static(), which duplicates a single
display mode for a connector. Convert drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_mipi_dbi.c | 20 +--
drivers/gpu/drm/drm_probe_helper.c | 40 ++
drivers/gpu/drm/tiny/repaper.c | 16 +---
drivers/gpu/drm/tiny/simpledrm.c | 18 +-
include/drm/drm_probe_helper.h | 3 +++
5 files changed, 46 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 84abc3920b57..b67ec9a5cda9 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -415,26 +415,8 @@ EXPORT_SYMBOL(mipi_dbi_pipe_disable);
static int mipi_dbi_connector_get_modes(struct drm_connector *connector)
{
struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(connector->dev);
- struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, >mode);
- if (!mode) {
- DRM_ERROR("Failed to duplicate mode\n");
- return 0;
- }
-
- if (mode->name[0] == '\0')
- drm_mode_set_name(mode);
-
- mode->type |= DRM_MODE_TYPE_PREFERRED;
- drm_mode_probed_add(connector, mode);
-
- if (mode->width_mm) {
- connector->display_info.width_mm = mode->width_mm;
- connector->display_info.height_mm = mode->height_mm;
- }
-
- return 1;
+ return drm_connector_helper_get_modes_static(connector, >mode);
}
static const struct drm_connector_helper_funcs mipi_dbi_connector_hfuncs = {
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index bb427c5a4f1f..809187377e4e 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -1050,6 +1050,46 @@ int drm_connector_helper_get_modes_from_ddc(struct
drm_connector *connector)
}
EXPORT_SYMBOL(drm_connector_helper_get_modes_from_ddc);
+/**
+ * drm_connector_helper_get_modes_static - Duplicates a display mode for a
connector
+ * @connector: the connector
+ * @hw_mode: the display hardware's mode
+ *
+ * This function duplicates a display modes for a connector. Drivers for
hardware
+ * that only supports a single mode can use this function in there connector's
+ * get_modes helper.
+ *
+ * Returns:
+ * The number of created modes.
+ */
+int drm_connector_helper_get_modes_static(struct drm_connector *connector,
+ const struct drm_display_mode
*hw_mode)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(dev, hw_mode);
+ if (!mode) {
+ drm_err(dev, "Failed to duplicate mode " DRM_MODE_FMT "\n",
+ DRM_MODE_ARG(hw_mode));
+ return 0;
+ }
+
+ if (mode->name[0] == '\0')
+ drm_mode_set_name(mode);
+
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
+ drm_mode_probed_add(connector, mode);
+
+ if (mode->width_mm)
+ connector->display_info.width_mm = mode->width_mm;
+ if (mode->height_mm)
+ connector->display_info.height_mm = mode->height_mm;
+
+ return 1;
+}
+EXPORT_SYMBOL(drm_connector_helper_get_modes_static);
+
/**
* drm_connector_helper_get_modes - Read EDID and update connector.
* @connector: The connector
diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c
index c4c1be3ac0b8..855968fd46af 100644
--- a/drivers/gpu/drm/tiny/repaper.c
+++ b/drivers/gpu/drm/tiny/repaper.c
@@ -839,22 +839,8 @@ static const struct drm_simple_display_pipe_funcs
repaper_pipe_funcs = {
static int repaper_connector_get_modes(struct drm_connector *connector)
{
struct repaper_epd *epd = drm_to_epd(connector->dev);
- struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, epd->mode);
- if (!mode) {
- DRM_ERROR("Failed to duplicate mode\n");
- return 0;
- }
-
- drm_mode_set_name(mode);
- mode->type |= DRM_MODE_TYPE_PREFERRED;
- drm_mode_probed_add(connector, mode);
-
- connector->display_info.width_mm = mode->width_mm;
- connector->display_info.height_mm = mode->height_mm;
-
- return 1;
+ return drm_connector_helper_get_modes_static(connector, epd->mode);
}
static const struct drm_connector_helper_funcs repaper_connector_hfuncs = {
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index a81f91814595..2d5b56c4a77d 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -620,24 +620,8 @@ static const struct drm_encoder_funcs
simpledrm_encoder_funcs = {
static int simpledrm_connector_helper_get_modes(struct drm_connector
*connector)
{
struct simpledrm_device *sdev = simpledrm_device_of_dev(connector->dev);
- struct
[PATCH 3/4] drm/modes: Add initializer macro DRM_MODE_INIT()
The macro DRM_MODE_INIT() initializes an instance of
struct drm_display_mode with typical parameters. Convert simpledrm
and also update the macro DRM_SIMPLE_MODE().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 23 -
include/drm/drm_modes.h | 35 +++-
2 files changed, 39 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 31d3bc6c5acf..cc509154b296 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -30,16 +30,6 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-/*
- * Assume a monitor resolution of 96 dpi to
- * get a somewhat reasonable screen size.
- */
-#define RES_MM(d) \
- (((d) * 254ul) / (96ul * 10ul))
-
-#define SIMPLEDRM_MODE(hd, vd) \
- DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
-
/*
* Helpers for simplefb
*/
@@ -641,10 +631,15 @@ static const struct drm_mode_config_funcs
simpledrm_mode_config_funcs = {
static struct drm_display_mode simpledrm_mode(unsigned int width,
unsigned int height)
{
- struct drm_display_mode mode = { SIMPLEDRM_MODE(width, height) };
-
- mode.clock = mode.hdisplay * mode.vdisplay * 60 / 1000 /* kHz */;
- drm_mode_set_name();
+ /*
+* Assume a monitor resolution of 96 dpi to
+* get a somewhat reasonable screen size.
+*/
+ const struct drm_display_mode mode = {
+ DRM_MODE_INIT(60, width, height,
+ DRM_MODE_RES_MM(width, 96ul),
+ DRM_MODE_RES_MM(height, 96ul))
+ };
return mode;
}
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index a80ae9639e96..bb932806f029 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -138,6 +138,35 @@ enum drm_mode_status {
.vsync_start = (vss), .vsync_end = (vse), .vtotal = (vt), \
.vscan = (vs), .flags = (f)
+/**
+ * DRM_MODE_RES_MM - Calculates the display size from resolution and DPI
+ * @res: The resolution in pixel
+ * @dpi: The number of dots per inch
+ */
+#define DRM_MODE_RES_MM(res, dpi) \
+ (((res) * 254ul) / ((dpi) * 10ul))
+
+#define __DRM_MODE_INIT(pix, hd, vd, hd_mm, vd_mm) \
+ .type = DRM_MODE_TYPE_DRIVER, .clock = (pix), \
+ .hdisplay = (hd), .hsync_start = (hd), .hsync_end = (hd), \
+ .htotal = (hd), .vdisplay = (vd), .vsync_start = (vd), \
+ .vsync_end = (vd), .vtotal = (vd), .width_mm = (hd_mm), \
+ .height_mm = (vd_mm)
+
+/**
+ * DRM_SIMPLE_MODE_INIT - Initialize display mode
+ * @hz: Vertical refresh rate in Hertz
+ * @hd: Horizontal resolution, width
+ * @vd: Vertical resolution, height
+ * @hd_mm: Display width in millimeters
+ * @vd_mm: Display height in millimeters
+ *
+ * This macro initializes a _display_mode that contains information about
+ * refresh rate, resolution and physical size.
+ */
+#define DRM_MODE_INIT(hz, hd, vd, hd_mm, vd_mm) \
+ __DRM_MODE_INIT((hd) * (vd) * (hz) / 1000 /* kHz */, hd, vd, hd_mm,
vd_mm)
+
/**
* DRM_SIMPLE_MODE - Simple display mode
* @hd: Horizontal resolution, width
@@ -149,11 +178,7 @@ enum drm_mode_status {
* resolution and physical size.
*/
#define DRM_SIMPLE_MODE(hd, vd, hd_mm, vd_mm) \
- .type = DRM_MODE_TYPE_DRIVER, .clock = 1 /* pass validation */, \
- .hdisplay = (hd), .hsync_start = (hd), .hsync_end = (hd), \
- .htotal = (hd), .vdisplay = (vd), .vsync_start = (vd), \
- .vsync_end = (vd), .vtotal = (vd), .width_mm = (hd_mm), \
- .height_mm = (vd_mm)
+ __DRM_MODE_INIT(1 /* pass validation */, hd, vd, hd_mm, vd_mm)
#define CRTC_INTERLACE_HALVE_V (1 << 0) /* halve V values for interlacing */
#define CRTC_STEREO_DOUBLE (1 << 1) /* adjust timings for stereo modes */
--
2.37.1
[PATCH 4/4] drm/format-helper: Add drm_fb_build_fourcc_list() helper
Add drm_fb_build_fourcc_list() function that builds a list of supported
formats from native and emulated ones. Helpful for all drivers that do
format conversion as part of their plane updates. Update current caller.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 94 +
drivers/gpu/drm/tiny/simpledrm.c| 47 ++-
include/drm/drm_format_helper.h | 11 +++-
3 files changed, 109 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 56642816fdff..dca5531615f3 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -793,3 +793,97 @@ void drm_fb_xrgb_to_mono(struct iosys_map *dst, const
unsigned int *dst_pitc
kfree(src32);
}
EXPORT_SYMBOL(drm_fb_xrgb_to_mono);
+
+static bool is_listed_fourcc(const uint32_t *fourccs, size_t nfourccs,
uint32_t fourcc)
+{
+ const uint32_t *fourccs_end = fourccs + nfourccs;
+
+ while (fourccs < fourccs_end) {
+ if (*fourccs == fourcc)
+ return true;
+ ++fourccs;
+ }
+ return false;
+}
+
+/**
+ * drm_fb_build_fourcc_list - Filters a list of supported color formats against
+ *the device's native formats
+ * @dev: DRM device
+ * @native_fourccs: 4CC codes of natively supported color formats
+ * @native_nfourccs: The number of entries in @native_fourccs
+ * @extra_fourccs: 4CC codes of additionally supported color formats
+ * @extra_nfourccs: The number of entries in @extra_fourccs
+ * @fourccs_out: Returns 4CC codes of supported color formats
+ * @nfourccs_out: The number of available entries in @fourccs_out
+ *
+ * This function create a list of supported color format from natively
+ * supported formats and the emulated formats. *
+ * At a minimum, most userspace programs expect at least support for
+ * XRGB on the primary plane. Devices that have to emulate the
+ * format, and possibly others, can use drm_fb_build_fourcc_list() to
+ * create a list of supported color formats. The returned list can
+ * be handed over to drm_universal_plane_init() et al. Native formats
+ * will go before emulated formats. Other heuristics might be applied
+ * to optimize the order. Formats near the beginning of the list are
+ * usually preferred over formats near the end of the list.
+ *
+ * Returns:
+ * The number of color-formats 4CC codes returned in @fourccs_out.
+ */
+size_t drm_fb_build_fourcc_list(struct drm_device *dev,
+ const uint32_t *native_fourccs, size_t
native_nfourccs,
+ const uint32_t *extra_fourccs, size_t
extra_nfourccs,
+ uint32_t *fourccs_out, size_t nfourccs_out)
+{
+ uint32_t *fourccs = fourccs_out;
+ const uint32_t *fourccs_end = fourccs_out + nfourccs_out;
+ bool found_native = false;
+ size_t nfourccs, i;
+
+ /* native formats go first */
+
+ nfourccs = min_t(size_t, native_nfourccs, nfourccs_out);
+
+ for (i = 0; i < nfourccs; ++i) {
+ uint32_t fourcc = native_fourccs[i];
+
+ drm_dbg_kms(dev, "adding native format %p4cc\n", );
+
+ if (!found_native)
+ found_native = is_listed_fourcc(extra_fourccs,
extra_nfourccs, fourcc);
+ *fourccs = fourcc;
+ ++fourccs;
+ }
+
+ /*
+* The plane's atomic_update helper converts the framebuffer's color
format
+* to the native format when copying them to device memory.
+*
+* If there is not a single format supported by both, device and
+* plane, the native formats are likely not supported by the conversion
+* helpers. Therefore *only* support the native formats and add a
+* conversion helper ASAP.
+*/
+ if (!found_native) {
+ drm_warn(dev, "format conversion helpers required to add extra
formats\n");
+ goto out;
+ }
+
+ /* extra formats go second */
+
+ nfourccs = min_t(size_t, extra_nfourccs, fourccs_end - fourccs);
+
+ for (i = 0; i < nfourccs; ++i) {
+ uint32_t fourcc = extra_fourccs[i];
+
+ if (is_listed_fourcc(native_fourccs, native_nfourccs, fourcc))
+ continue; /* native formats already went first */
+ *fourccs = fourcc;
+ ++fourccs;
+ }
+
+out:
+ return fourccs - fourccs_out;
+}
+EXPORT_SYMBOL(drm_fb_build_fourcc_list);
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index cc509154b296..79c9fd6bedf0 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -644,45 +644,6 @@ static struct drm_display_mode simpledrm_mode(unsigned int
width,
return mode;
}
-static const uint32_t *simpledrm_device_formats(struct
[PATCH 0/4] drm/probe-helper, modes: Helpers for single-mode displays
This patchset moves code from simpledrm to probe and display-mode helpers. The new functions will be useful for the upcomming driver for PowerPC displays. [1] Where possible, existing drivers are being converted to use them. [1] https://patchwork.freedesktop.org/series/106538/ Thomas Zimmermann (4): drm/probe-helper: Add drm_connector_helper_get_modes_static() drm/probe-helper: Add drm_crtc_helper_mode_valid_static() drm/modes: Add initializer macro DRM_MODE_INIT() drm/format-helper: Add drm_fb_build_fourcc_list() helper drivers/gpu/drm/drm_format_helper.c | 94 +++ drivers/gpu/drm/drm_mipi_dbi.c | 38 drivers/gpu/drm/drm_probe_helper.c | 65 + drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1 + drivers/gpu/drm/tiny/hx8357d.c | 1 + drivers/gpu/drm/tiny/ili9163.c | 1 + drivers/gpu/drm/tiny/ili9341.c | 1 + drivers/gpu/drm/tiny/ili9486.c | 1 + drivers/gpu/drm/tiny/mi0283qt.c | 1 + drivers/gpu/drm/tiny/panel-mipi-dbi.c| 1 + drivers/gpu/drm/tiny/repaper.c | 26 +++--- drivers/gpu/drm/tiny/simpledrm.c | 96 +++- drivers/gpu/drm/tiny/st7735r.c | 1 + include/drm/drm_format_helper.h | 11 ++- include/drm/drm_mipi_dbi.h | 2 + include/drm/drm_modes.h | 35 ++- include/drm/drm_probe_helper.h | 9 +- 17 files changed, 262 insertions(+), 122 deletions(-) -- 2.37.1
[PATCH 2/4] drm/probe-helper: Add drm_crtc_helper_mode_valid_static()
Add drm_crtc_helper_mode_valid_static(), which validates a given mode
against a display hardware's mode. Convert simpledrm and use it in a
few other drivers with static modes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_mipi_dbi.c | 18 ++
drivers/gpu/drm/drm_probe_helper.c | 25
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1 +
drivers/gpu/drm/tiny/hx8357d.c | 1 +
drivers/gpu/drm/tiny/ili9163.c | 1 +
drivers/gpu/drm/tiny/ili9341.c | 1 +
drivers/gpu/drm/tiny/ili9486.c | 1 +
drivers/gpu/drm/tiny/mi0283qt.c | 1 +
drivers/gpu/drm/tiny/panel-mipi-dbi.c| 1 +
drivers/gpu/drm/tiny/repaper.c | 10
drivers/gpu/drm/tiny/simpledrm.c | 10 +---
drivers/gpu/drm/tiny/st7735r.c | 1 +
include/drm/drm_mipi_dbi.h | 2 ++
include/drm/drm_probe_helper.h | 8 +--
14 files changed, 70 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index b67ec9a5cda9..d544a99df9df 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -309,6 +309,24 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
struct drm_rect *rect)
drm_dev_exit(idx);
}
+/**
+ * mipi_dbi_pipe_mode_valid - MIPI DBI mode-valid helper
+ * @pipe: Simple display pipe
+ * @mode: The mode to test
+ *
+ * This function validates a given display mode against the MIPI DBI's hardware
+ * display. Drivers can use this as their
_simple_display_pipe_funcs->mode_valid
+ * callback.
+ */
+enum drm_mode_status mipi_dbi_pipe_mode_valid(struct drm_simple_display_pipe
*pipe,
+ const struct drm_display_mode
*mode)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+
+ return drm_crtc_helper_mode_valid_static(>crtc, mode,
>mode);
+}
+EXPORT_SYMBOL(mipi_dbi_pipe_mode_valid);
+
/**
* mipi_dbi_pipe_update - Display pipe update helper
* @pipe: Simple display pipe
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 809187377e4e..bc3876853fca 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -1014,6 +1014,31 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_helper_hpd_irq_event);
+/**
+ * drm_crtc_helper_mode_valid_static - Validates a display mode
+ * @crtc: the crtc
+ * @mode: the mode to validate
+ * @hw_mode: the display hardware's mode
+ *
+ * Returns:
+ * MODE_OK on success, or another mode-status code otherwise.
+ */
+enum drm_mode_status drm_crtc_helper_mode_valid_static(struct drm_crtc *crtc,
+ const struct
drm_display_mode *mode,
+ const struct
drm_display_mode *hw_mode)
+{
+
+ if (mode->hdisplay != hw_mode->hdisplay && mode->vdisplay !=
hw_mode->vdisplay)
+ return MODE_ONE_SIZE;
+ else if (mode->hdisplay != hw_mode->hdisplay)
+ return MODE_ONE_WIDTH;
+ else if (mode->vdisplay != hw_mode->vdisplay)
+ return MODE_ONE_HEIGHT;
+
+ return MODE_OK;
+}
+EXPORT_SYMBOL(drm_crtc_helper_mode_valid_static);
+
/**
* drm_connector_helper_get_modes_from_ddc - Updates the connector's EDID
* property from the connector's
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 7da09e34385d..39dc40cf681f 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -576,6 +576,7 @@ static void ili9341_dbi_enable(struct
drm_simple_display_pipe *pipe,
}
static const struct drm_simple_display_pipe_funcs ili9341_dbi_funcs = {
+ .mode_valid = mipi_dbi_pipe_mode_valid,
.enable = ili9341_dbi_enable,
.disable = mipi_dbi_pipe_disable,
.update = mipi_dbi_pipe_update,
diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
index 57f229a785bf..48c24aa8c28a 100644
--- a/drivers/gpu/drm/tiny/hx8357d.c
+++ b/drivers/gpu/drm/tiny/hx8357d.c
@@ -181,6 +181,7 @@ static void yx240qv29_enable(struct drm_simple_display_pipe
*pipe,
}
static const struct drm_simple_display_pipe_funcs hx8357d_pipe_funcs = {
+ .mode_valid = mipi_dbi_pipe_mode_valid,
.enable = yx240qv29_enable,
.disable = mipi_dbi_pipe_disable,
.update = mipi_dbi_pipe_update,
diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c
index 86439e50e304..9a1a5943bee0 100644
--- a/drivers/gpu/drm/tiny/ili9163.c
+++ b/drivers/gpu/drm/tiny/ili9163.c
@@ -100,6 +100,7 @@ static void yx240qv29_enable(struct drm_simple_display_pipe
*pipe,
}
static const struct
Re: [PATCH 23/33] drm/vc4: hdmi: Move HDMI reset to pm_resume
Hi Florian
On Tue, 9 Aug 2022 at 20:02, Florian Fainelli wrote:
>
> On 8/4/22 16:11, Florian Fainelli wrote:
> > On 6/13/22 07:47, Maxime Ripard wrote:
> >> From: Dave Stevenson
> >>
> >> The BCM2835-37 found in the RaspberryPi 0 to 3 have a power domain
> >> attached to the HDMI block, handled in Linux through runtime_pm.
> >>
> >> That power domain is shared with the VEC block, so even if we put our
> >> runtime_pm reference in the HDMI driver it would keep being on. If the
> >> VEC is disabled though, the power domain would be disabled and we would
> >> lose any initialization done in our bind implementation.
> >>
> >> That initialization involves calling the reset function and initializing
> >> the CEC registers.
> >>
> >> Let's move the initialization to our runtime_resume implementation so
> >> that we initialize everything properly if we ever need to.
> >>
> >> Fixes: c86b41214362 ("drm/vc4: hdmi: Move the HSM clock enable to
> >> runtime_pm")
> >> Signed-off-by: Dave Stevenson
> >> Signed-off-by: Maxime Ripard
> >
> > After seeing the same warning as Stefan reported in the link below, but
> > on the Raspberry Pi 4B:
> >
> > https://www.spinics.net/lists/dri-devel/msg354170.html
> >
> > a separate bisection effort led me to this commit, before is fine, after
> > produces 4 warnings during boot, see attached log.
> >
> > Is there a fix that we can try that would also cover the Raspberry Pi
> > 4B? Is it possible that this series precipitates the problem:
> >
> > https://www.spinics.net/lists/arm-kernel/msg984638.html
>
> Maxime, Dave, anything you would want me to try? Still seeing these
> warnings with net-next-6.0-11220-g15205c2829ca
Strange as we don't see this warning on the vendor kernel which is
doing exactly the same. We are largely still on 5.15 as LTS though, so
5.19 hasn't had much bashing in that regard.
Your callstack implies it's only sequencing.
vc4_hdmi_bind is manually calling vc4_hdmi_runtime_resume (and hence
initialising registers) before the call to pm_runtime_set_active and
pm_runtime_enable, hence the pm accounting check in vc4_hdmi_write
fails.
pm_runtime always seems like black magic to me :-/
Do we need to manually power up here, or can we call pm_runtime_enable
without touching the state, and then resume in the normal manner?
ie something simple like
pm_runtime_enable(dev);
pm_runtime_resume_and_get(dev);
The resume_and_get will call vc4_hdmi_runtime_resume and hence
initialise the block, but it will have sorted the pm accounting first.
Otherwise we mess with the order to be:
pm_runtime_get_noresume(dev);
pm_runtime_set_active(dev);
ret = vc4_hdmi_runtime_resume(dev);
if (ret)
goto err_put_ddc; //This error handling needs to be checked
pm_runtime_enable(dev);
I have no feel for which is the "correct" approach in terms of
pm_runtime, so will defer to others in that regard.
Dave
> Would be nice to see those fixes before 6.0 final, thanks!
> --
> Florian
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Use of BARs names instead of numbers
On 05.08.2022 17:59, Piorkowski, Piotr wrote:
From: Piotr Piórkowski
At the moment, when we refer to some PCI BAR we use the number of
this BAR in the code. The meaning of BARs between different platforms
may be different. Therefore, in order to organize the code,
let's start using defined names instead of numbers.
v2: Add lost header in cfg_space.c
Signed-off-by: Piotr Piórkowski
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Matt Roper
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_lpe_audio.c | 5 +++--
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 7 ---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 9 +
drivers/gpu/drm/i915/gt/intel_gt.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_region_lmem.c| 13 ++---
drivers/gpu/drm/i915/gvt/cfg_space.c | 5 +++--
drivers/gpu/drm/i915/intel_pci_config.h| 7 +++
7 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_lpe_audio.c
b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
index 4970bf146c4a..1e18696aaecf 100644
--- a/drivers/gpu/drm/i915/display/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
@@ -73,6 +73,7 @@
#include "i915_drv.h"
#include "intel_de.h"
#include "intel_lpe_audio.h"
+#include "intel_pci_config.h"
#define HAS_LPE_AUDIO(dev_priv) ((dev_priv)->audio.lpe.platdev != NULL)
@@ -100,9 +101,9 @@ lpe_audio_platdev_create(struct drm_i915_private *dev_priv)
rsc[0].flags= IORESOURCE_IRQ;
rsc[0].name = "hdmi-lpe-audio-irq";
- rsc[1].start= pci_resource_start(pdev, 0) +
+ rsc[1].start= pci_resource_start(pdev, GTTMMADR_BAR) +
I915_HDMI_LPE_AUDIO_BASE;
- rsc[1].end = pci_resource_start(pdev, 0) +
+ rsc[1].end = pci_resource_start(pdev, GTTMMADR_BAR) +
I915_HDMI_LPE_AUDIO_BASE + I915_HDMI_LPE_AUDIO_SIZE - 1;
rsc[1].flags= IORESOURCE_MEM;
rsc[1].name = "hdmi-lpe-audio-mmio";
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 166d0a4b9e8c..c369cfd185bc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -22,6 +22,7 @@
#include "i915_utils.h"
#include "i915_vgpu.h"
#include "intel_mchbar_regs.h"
+#include "intel_pci_config.h"
/*
* The BIOS typically reserves some of the system's memory for the exclusive
@@ -830,7 +831,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
/* Use DSM base address instead for stolen memory */
dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
if (IS_DG1(uncore->i915)) {
- lmem_size = pci_resource_len(pdev, 2);
+ lmem_size = pci_resource_len(pdev, GEN12_LMEM_BAR);
if (WARN_ON(lmem_size < dsm_base))
return ERR_PTR(-ENODEV);
} else {
@@ -842,11 +843,11 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
}
dsm_size = lmem_size - dsm_base;
- if (pci_resource_len(pdev, 2) < lmem_size) {
+ if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
io_start = 0;
io_size = 0;
} else {
- io_start = pci_resource_start(pdev, 2) + dsm_base;
+ io_start = pci_resource_start(pdev, GEN12_LMEM_BAR) + dsm_base;
io_size = dsm_size;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 15a915bb4088..8214e07a0f5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -16,6 +16,7 @@
#include "intel_ggtt_gmch.h"
#include "intel_gt.h"
#include "intel_gt_regs.h"
+#include "intel_pci_config.h"
#include "i915_drv.h"
#include "i915_scatterlist.h"
#include "i915_utils.h"
@@ -869,8 +870,8 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64
size)
u32 pte_flags;
int ret;
- GEM_WARN_ON(pci_resource_len(pdev, 0) != gen6_gttmmadr_size(i915));
- phys_addr = pci_resource_start(pdev, 0) + gen6_gttadr_offset(i915);
+ GEM_WARN_ON(pci_resource_len(pdev, GTTMMADR_BAR) !=
gen6_gttmmadr_size(i915));
+ phys_addr = pci_resource_start(pdev, GTTMMADR_BAR) +
gen6_gttadr_offset(i915);
/*
* On BXT+/ICL+ writes larger than 64 bit to the GTT pagetable range
@@ -930,7 +931,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
u16 snb_gmch_ctl;
if (!HAS_LMEM(i915)) {
- ggtt->gmadr = pci_resource(pdev, 2);
+ ggtt->gmadr = pci_resource(pdev, GTT_APERTURE_BAR);
ggtt->mappable_end = resource_size(>gmadr);
}
@@ -1084,7 +1085,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
unsigned int size;
u16 snb_gmch_ctl;
- ggtt->gmadr = pci_resource(pdev, 2);
+
