Re: [PATCH v6 1/4] drm: Introduce device wedged event
On Tue, Sep 24, 2024 at 01:23:13PM +0200, Simona Vetter wrote: > On Mon, Sep 23, 2024 at 09:28:23AM +0530, Raag Jadav wrote: > > Introduce device wedged event, which will notify userspace of wedged > > (hanged/unusable) state of the DRM device through a uevent. This is > > useful especially in cases where the device is no longer operating as > > expected and has become unrecoverable from driver context. > > > > Purpose of this implementation is to provide drivers a way to recover > > through userspace intervention. Different drivers may have different > > ideas of a "wedged device" depending on their hardware implementation, > > and hence the vendor agnostic nature of the event. It is up to the drivers > > to decide when they see the need for recovery and how they want to recover > > from the available methods. > > > > Current implementation defines three recovery methods, out of which, > > drivers can choose to support any one or multiple of them. Preferred > > recovery method will be sent in the uevent environment as WEDGED=. > > Userspace consumers (sysadmin) can define udev rules to parse this event > > and take respective action to recover the device. > > > > Method| Consumer expectations > > ---|--- > > rebind| unbind + rebind driver > > bus-reset | unbind + reset bus device + rebind > > reboot| reboot system > > > > v4: s/drm_dev_wedged/drm_dev_wedged_event > > Use drm_info() (Jani) > > Kernel doc adjustment (Aravind) > > v5: Send recovery method with uevent (Lina) > > v6: Access wedge_recovery_opts[] using helper function (Jani) > > Use snprintf() (Jani) > > > > Signed-off-by: Raag Jadav > > Finally caught up on mail, so dropping this here again: Please also add a > small section to drm-uapi.rst, pointing at these functions. Just the > kerneldoc for developers is kinda not enough I think. Would you prefer a new section or have the existing one (Device reset which looks somewhat similar but not entirely) modified? Raag
Re: [PATCH v17 0/8] Initial support Cadence MHDP8501(HDMI/DP) for i.MX8MQ
On Tue, 24 Sep 2024 15:36:45 +0800, Sandor Yu wrote:
> The patch set initial support Cadence MHDP8501(HDMI/DP) DRM bridge
> driver and Cadence HDP-TX PHY(HDMI/DP) driver for Freescale i.MX8MQ.
>
> The patch set compose of DRM bridge drivers and PHY driver.
>
> Both of them need by patch #1 and #2 to pass build.
>
> DRM bridges driver patches:
> #1: drm: bridge: Cadence: Creat mhdp helper driver
> #2: phy: Add HDMI configuration options
> #3: dt-bindings: display: bridge: Add Cadence MHDP8501
> #4: drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver
>
> PHY driver patches:
> #1: drm: bridge: Cadence: Creat mhdp helper driver
> #2: phy: Add HDMI configuration options
> #5: dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
> #6: phy: freescale: Add DisplayPort/HDMI Combo-PHY driver for i.MX8MQ
>
> i.MX8M/TQMa8Mx DT patches:
> #7: Add DT nodes for DCSS/HDMI pipeline
> #8: Enable HDMI for TQMa8Mx/MBa8Mx
>
> v16->v17:
> Patch #1:
> - Replaces the local mutex mbox_mutex with a global mutex mhdp_mailbox_mutex
> Patch #2:
> - remove hdmi.h
> - add 2024 year to copyright
> - Add r-b tag.
> Patch #3:
> - Add lane-mapping property.
> Patch #4:
> - Reset the HDMI/DP link when an HPD (Hot Plug Detect) event is detected
> - Move the HDMI protocol settings from hdmi_ctrl_init() to a new function
> cdns_hdmi_set_hdmi_mode_type(), to align with the introduced link reset
> functionality.
> - Implement logic to check the type of HDMI sink.
> If the sink is not a hdmi display, set the default mode to DVI.
> - Implement hdmi_reset_infoframe function
> - Reorder certain bit definitions in the header file to follow a descending
> order.
> - Add "lane-mapping" property for both HDMI and DP, remove platform data from
> driver.
> lane-mapping should be setting in dts according different board layout.
> - Remove variable mode in struct cdns_mhdp8501_device, video mode could get
> from struct drm_crtc_state
> - Remove variable char_rate in struct cdns_mhdp8501_device, it could get
> from struct struct drm_connector_state.hdmi
> - Replaces the local mutex mbox_mutex with a global mutex mhdp_mailbox_mutex
> - Remove mutext protect for phy_api access functions.
> Patch #6:
> - Remove mbox_mutex
>
> v15->v16:
> Patch #2:
> - Remove pixel_clk_rate, bpc and color_space fields from struct
> phy_configure_opts_hdmi, they were replaced by
> unsigned long long tmds_char_rate.
> - Remove r-b and a-c tags because this patch have important change.
> Patch #4:
> - Add DRM_BRIDGE_OP_HDMI flags for HDMI driver,
> - Introduce the hdmi info frame helper functions,
> added hdmi_clear_infoframe(), hdmi_write_infoframe() and
> hdmi_tmds_char_rate_valid() according Dmitry's patch
> 'make use of the HDMI connector infrastructure' patchset ([2]).
> - mode_fixup() is replaced by atomic_check().
> - Fix video mode 4Kp30 did not work on some displays that support
> LTE_340Mcsc_scramble.
> - updated for tmds_char_rate added in patch #2.
> Patch #6:
> - updated for tmds_char_rate added in patch #2.
>
> v14->v15:
> Patch #6 + #7:
> - Merged PHY driver into a single combo PHY driver
> Patch #7 + #8:
> - Add DT patches for a running HDMI setup
>
> v13->v14:
> Patch #4:
> - Rebase to next-20240219, replace get_edid function by edid_read
> function as commits d807ad80d811b ("drm/bridge: add ->edid_read
> hook and drm_bridge_edid_read()") and 27b8f91c08d99 ("drm/bridge:
> remove ->get_edid callback") had change the API.
>
> v12->v13:
> Patch #4:
> - Explicitly include linux/platform_device.h for cdns-mhdp8501-core.c
> - Fix build warning
> - Order bit bpc and color_space in descending shit.
> Patch #7:
> - Fix build warning
>
> v11->v12:
> Patch #1:
> - Move status initialize out of mbox_mutex.
> - Reorder API functions in alphabetical.
> - Add notes for malibox access functions.
> - Add year 2024 to copyright.
> Patch #4:
> - Replace DRM_INFO with dev_info or dev_warn.
> - Replace DRM_ERROR with dev_err.
> - Return ret when cdns_mhdp_dpcd_read failed in function
> cdns_dp_aux_transferi().
> - Remove unused parmeter in function cdns_dp_get_msa_misc
> and use two separate variables for color space and bpc.
> - Add year 2024 to copyright.
> Patch #6:
> - Return error code to replace -1 for function wait_for_ack().
> - Set cdns_phy->power_up = false in phy_power_down function.
> - Remove "RATE_8_1 = 81", it is not used in driver.
> - Add year 2024 to copyright.
> Patch #7:
> - Adjust clk disable order.
> - Return error code to replace -1 for function wait_for_ack().
> - Use bool for variable pclk_in.
> - Add year 2024 to copyright.
>
> v10->v11:
> - rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver,
> use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write()
> same as the other mailbox access functions.
> - use static for cdns_mhdp_mailbox_write() and cdns_mhdp_mailbox_read()
> and remove them from EXPORT_SYMBOL_GPL().
> - remove MODULE_ALIAS() from mhdp8501 driver.
>
> v9->v
Re: [PATCH v2 1/2] drm/panel: jd9365da: Modify Kingdisplay and Melfas panel timing
On Wed, Sep 25, 2024 at 12:11 AM Jessica Zhang
wrote:
>
>
>
> On 9/23/2024 7:13 PM, zhaoxiong lv wrote:
> > On Tue, Sep 24, 2024 at 5:14 AM Jessica Zhang
> > wrote:
> >>
> >>
> >>
> >> On 9/23/2024 6:42 AM, Zhaoxiong Lv wrote:
> >>> In MTK chips, if the system starts suspending before the DRM runtime
> >>> resume has not completed, there is a possibility of a black screen
> >>> after waking the machine. Reduce the disable delay resolves this issue,
> >>
> >> Hi Zhaoxiong,
> >>
> >> Do you mean "if the system starts suspending before the DRM runtime
> >> resume *has* completed" here?
> >
> > Hi Jessica
> >
> > Sorry, my description may not be clear enough. It should be when the
> > DRM runtime resume has not yet completed and the system enters sleep
> > mode at the same time.
>
> Got it, yes I think the reworded explanation in your reply is much clearer.
>
> >
> >
> >>
> >>>
> >>> The "backlight_off_to_display_off_delay_ms" was added between
> >>> "backlight off" and "display off" to prevent "display off" from being
> >>> executed when the backlight is not fully powered off, which may cause
> >>> a white screen. However, we removed this
> >>> "backlight_off_to_display_off_delay_ms" and found that this situation
> >>> did not occur. Therefore, in order to solve the problem mentioned
> >>> above, we We reduced it from 100ms to 3ms (tCMD_OFF >= 1ms).
> >>
> >> So from my understanding of this paragraph,
> >> `backlight_off_to_display_off_delay_ms` was added to prevent the display
> >> powering off before backlight is fully powered off. You recently tested
> >> dropping this completely and saw no issue with this.
> >>
> >> If that's the case, why not drop this delay completely?
> >>
> >> Thanks,
> >>
> >> Jessica Zhang
> >
> > Yes, there are currently no other issue after removing this delay.
> > The reason why I didn't completely remove this delay is because the
> > panel spec states that a delay of more than 1ms (tCMD_OFF >= 1ms) is
> > required when entering diaplay_off (0x28H), so I reserved 3ms.
>
> Thanks for the clarification -- I see why you included the "(tCMD_OFF >=
> 1ms)" part now. Can you please specify in the commit message that the
> tCMD_OFF delay requirement is from the spec?
>
> Also can you remove the extra "We" in "we We reduced it from 100ms to 3ms"?
>
> Thanks,
>
> Jessica Zhang
OK, thanks for your correction, we will modify the commit message in
the next patch.
>
> >
> >>
> >>>
> >>> This is the timing specification for the two panels:
> >>> 1. Kingdisplay panel timing spec:
> >>> https://github.com/KD54183/-JD9365DA_Power-On-Off-Sequence_V0120240923
> >>> 2. LMFBX101117480 timing spec: https://github.com/chiohsin-lo/TDY-JD_LIB
> >>>
> >>>
> >>> Fixes: 2b976ad760dc ("drm/panel: jd9365da: Support for kd101ne3-40ti
> >>> MIPI-DSI panel")
> >>> Fixes: c4ce398cf18a ("drm/panel: jd9365da: Support for Melfas
> >>> lmfbx101117480 MIPI-DSI panel")
> >>>
> >>> Signed-off-by: Zhaoxiong Lv
> >>> ---
> >>> Changes between V2 and V1:
> >>> - 1. Modify the commit message
> >>> - 2. Modify the value of backlight_off_to_display_off_delay_ms.
> >>> v1:
> >>> https://lore.kernel.org/all/20240915080830.11318-2-lvzhaoxi...@huaqin.corp-partner.google.com/
> >>> ---
> >>>drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c | 4 ++--
> >>>1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> >>> b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> >>> index 44897e5218a6..486aa20e5518 100644
> >>> --- a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> >>> +++ b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> >>> @@ -858,7 +858,7 @@ static const struct jadard_panel_desc
> >>> kingdisplay_kd101ne3_40ti_desc = {
> >>>.reset_before_power_off_vcioo = true,
> >>>.vcioo_to_lp11_delay_ms = 5,
> >>>.lp11_to_reset_delay_ms = 10,
> >>> - .backlight_off_to_display_off_delay_ms = 100,
> >>> + .backlight_off_to_display_off_delay_ms = 3,
> >>>.display_off_to_enter_sleep_delay_ms = 50,
> >>>.enter_sleep_to_reset_down_delay_ms = 100,
> >>>};
> >>> @@ -1109,7 +1109,7 @@ static const struct jadard_panel_desc
> >>> melfas_lmfbx101117480_desc = {
> >>>.reset_before_power_off_vcioo = true,
> >>>.vcioo_to_lp11_delay_ms = 5,
> >>>.lp11_to_reset_delay_ms = 10,
> >>> - .backlight_off_to_display_off_delay_ms = 100,
> >>> + .backlight_off_to_display_off_delay_ms = 3,
> >>>.display_off_to_enter_sleep_delay_ms = 50,
> >>>.enter_sleep_to_reset_down_delay_ms = 100,
> >>>};
> >>> --
> >>> 2.17.1
> >>>
> >>
>
Re: [PATCH v2 06/22] drm/msm/dpu: fill CRTC resources in dpu_crtc.c
On 9/24/2024 4:16 PM, Dmitry Baryshkov wrote:
On Tue, Sep 24, 2024 at 03:59:22PM GMT, Jessica Zhang wrote:
From: Dmitry Baryshkov
Stop poking into CRTC state from dpu_encoder.c, fill CRTC HW resources
from dpu_crtc_assign_resources().
Signed-off-by: Dmitry Baryshkov
[quic_abhin...@quicinc.com: cleaned up formatting]
Signed-off-by: Abhinav Kumar
[quic_jessz...@quicinc.com: dropped clearing num_mixers in CRTC disable
path]
Same comment as before: the code is still there.
Hi Dmitry,
I thought the original comment was to move the dropping `num_mixers = 0`
chunk from the previous patch to this one?
Sorry if I misunderstood.
Thanks,
Jessica Zhang
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 32 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 24 ++
2 files changed, 31 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index b918c80d30b3..d53e986eee54 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1091,9 +1091,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
dpu_core_perf_crtc_update(crtc, 0);
- memset(cstate->mixers, 0, sizeof(cstate->mixers));
- cstate->num_mixers = 0;
-
/* disable clk & bw control until clk & bw properties are set */
cstate->bw_control = false;
cstate->bw_split_vote = false;
@@ -1164,6 +1161,7 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state
*cstate)
}
#define MAX_HDISPLAY_SPLIT 1080
+#define MAX_CHANNELS_PER_CRTC 2
static struct msm_display_topology dpu_crtc_get_topology(
struct drm_crtc *crtc,
@@ -1208,9 +1206,14 @@ static struct msm_display_topology dpu_crtc_get_topology(
static int dpu_crtc_assign_resources(struct drm_crtc *crtc, struct drm_crtc_state *crtc_state)
{
+ struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_CRTC];
+ struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_CRTC];
+ struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_CRTC];
+ int i, num_lm, num_ctl, num_dspp;
struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
struct dpu_global_state *global_state;
struct msm_display_topology topology;
+ struct dpu_crtc_state *cstate;
int ret;
/*
@@ -1232,6 +1235,29 @@ static int dpu_crtc_assign_resources(struct drm_crtc
*crtc, struct drm_crtc_stat
if (ret)
return ret;
+ cstate = to_dpu_crtc_state(crtc_state);
+
+ num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+ crtc, DPU_HW_BLK_CTL, hw_ctl,
+ ARRAY_SIZE(hw_ctl));
+ num_lm = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+ crtc, DPU_HW_BLK_LM, hw_lm,
+ ARRAY_SIZE(hw_lm));
+ num_dspp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+crtc, DPU_HW_BLK_DSPP, hw_dspp,
+ARRAY_SIZE(hw_dspp));
+
+ for (i = 0; i < num_lm; i++) {
+ int ctl_idx = (i < num_ctl) ? i : (num_ctl-1);
+
+ cstate->mixers[i].hw_lm = to_dpu_hw_mixer(hw_lm[i]);
+ cstate->mixers[i].lm_ctl = to_dpu_hw_ctl(hw_ctl[ctl_idx]);
+ if (i < num_dspp)
+ cstate->mixers[i].hw_dspp = to_dpu_hw_dspp(hw_dspp[i]);
+ }
+
+ cstate->num_mixers = num_lm;
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index ada9119326ca..36b677cf9c7a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1049,14 +1049,11 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
struct dpu_encoder_virt *dpu_enc;
struct msm_drm_private *priv;
struct dpu_kms *dpu_kms;
- struct dpu_crtc_state *cstate;
struct dpu_global_state *global_state;
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
- struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
- struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
- int num_lm, num_ctl, num_pp, num_dsc;
+ int num_pp, num_dsc;
unsigned int dsc_mask = 0;
int i;
@@ -1083,13 +1080,8 @@ static void dpu_encoder_virt_atomic_mode_set(struct drm_encoder *drm_enc,
num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
drm_enc->crtc, DPU_HW_BLK_PINGPONG, hw_pp,
ARRAY_SIZE(hw_pp));
- num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global
Re: [PATCH v2 16/22] drm/msm/dpu: Configure CWB in writeback encoder
On 9/24/2024 4:41 PM, Dmitry Baryshkov wrote:
On Tue, Sep 24, 2024 at 03:59:32PM GMT, Jessica Zhang wrote:
Cache the CWB block mask in the DPU virtual encoder and configure CWB
according to the CWB block mask within the writeback phys encoder
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 83 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 16 -
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 4 +-
3 files changed, 100 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index b2f0bf412451..2628f2d55cb3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -24,6 +24,7 @@
#include "dpu_hw_catalog.h"
#include "dpu_hw_intf.h"
#include "dpu_hw_ctl.h"
+#include "dpu_hw_cwb.h"
#include "dpu_hw_dspp.h"
#include "dpu_hw_dsc.h"
#include "dpu_hw_merge3d.h"
@@ -139,6 +140,7 @@ enum dpu_enc_rc_states {
*num_phys_encs.
* @hw_dsc: Handle to the DSC blocks used for the display.
* @dsc_mask: Bitmask of used DSC blocks.
+ * @cwb_mask Bitmask of used CWB muxes
* @intfs_swapped:Whether or not the phys_enc interfaces have been swapped
*for partial update right-only cases, such as pingpong
*split where virtual pingpong does not generate IRQs
@@ -185,6 +187,7 @@ struct dpu_encoder_virt {
struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
unsigned int dsc_mask;
+ unsigned int cwb_mask;
bool intfs_swapped;
@@ -1063,6 +1066,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct drm_encoder *drm_enc,
int num_cwb = 0;
bool is_cwb_encoder;
unsigned int dsc_mask = 0;
+ unsigned int cwb_mask = 0;
int i;
if (!drm_enc) {
@@ -1103,8 +1107,12 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
ARRAY_SIZE(hw_pp));
}
- for (i = 0; i < num_cwb; i++)
+ for (i = 0; i < num_cwb; i++) {
dpu_enc->hw_cwb[i] = to_dpu_hw_cwb(hw_cwb[i]);
+ cwb_mask |= BIT(dpu_enc->hw_cwb[i]->idx - CWB_0);
+ }
+
+ dpu_enc->cwb_mask = cwb_mask;
dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
drm_enc->crtc, DPU_HW_BLK_CTL, hw_ctl,
ARRAY_SIZE(hw_ctl));
@@ -2071,6 +2079,9 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
}
}
+ if (dpu_enc->cwb_mask)
+ dpu_encoder_helper_phys_setup_cwb(phys_enc, false);
+
/* reset the merge 3D HW block */
if (phys_enc->hw_pp && phys_enc->hw_pp->merge_3d) {
phys_enc->hw_pp->merge_3d->ops.setup_3d_mode(phys_enc->hw_pp->merge_3d,
@@ -2114,6 +2125,68 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
ctl->ops.clear_pending_flush(ctl);
}
+void dpu_encoder_helper_phys_setup_cwb(struct dpu_encoder_phys *phys_enc,
+ bool enable)
+{
+ struct dpu_encoder_virt *dpu_enc =
to_dpu_encoder_virt(phys_enc->parent);
+ struct dpu_hw_cwb *hw_cwb;
+ struct dpu_hw_cwb_setup_cfg cwb_cfg;
+
+ struct dpu_kms *dpu_kms;
+ struct dpu_global_state *global_state;
+ struct dpu_hw_blk *rt_pp_list[MAX_CHANNELS_PER_ENC];
+ int num_pp, rt_pp_idx[MAX_CHANNELS_PER_ENC];
+
+ if (!phys_enc || !phys_enc->hw_wb || !dpu_enc->cwb_mask)
+ return;
We have already dereferened phys_enc, so checking that it's not NULL is
futile. Also we know that the function is only called if cwb_mask is not
zero, so the last check is also useless.
Hi Dmitry,
Ack.
+
+ dpu_kms = phys_enc->dpu_kms;
+ global_state = dpu_kms_get_existing_global_state(dpu_kms);
+ num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
+ phys_enc->parent->crtc,
+ DPU_HW_BLK_PINGPONG, rt_pp_list,
+ ARRAY_SIZE(rt_pp_list));
+
+ if (num_pp == 0 || num_pp > MAX_CHANNELS_PER_ENC) {
+ DPU_DEBUG_ENC(dpu_enc, "invalid num_pp %d\n", num_pp);
+ return;
+ }
+
+ for (int i = 0; i < num_pp; i++) {
+ struct dpu_hw_pingpong *hw_pp =
to_dpu_hw_pingpong(rt_pp_list[i]);
+
+ for (int j = 0; j < ARRAY_SIZE(dpu_enc->hw_cwb); j++) {
+ hw_cwb = dpu_enc->hw_cwb[i];
+
+ /*
+* Even CWB muxes must take input from even real-time
+* pingpongs and odd CWB muxes must take input from odd
+* pingpongs
+*/
+ if (hw_pp->idx %
Re: [PATCH v2 14/22] drm/msm/dpu: Require modeset if clone mode status changes
On 9/24/2024 4:25 PM, Dmitry Baryshkov wrote:
On Tue, Sep 24, 2024 at 03:59:30PM GMT, Jessica Zhang wrote:
If the clone mode enabled status is changing, a modeset needs to happen
so that the resources can be reassigned
Sima's comment regarding crtc_state->mode_changed seems to be ignored...
Not ignored. One of us has to take that up. There is a broader cleanup
required for that.
We can sync up on how to tackle this : whether it needs to be in this
series or push another one cleaning up all the instances.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index a7850bf844db..f20e44e9fc05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1268,6 +1268,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
{
struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
crtc);
+ struct drm_crtc_state *old_crtc_state =
drm_atomic_get_old_crtc_state(state,
+
crtc);
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
@@ -1279,6 +1281,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
int rc = 0;
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
+ bool clone_mode_requested = drm_crtc_in_clone_mode(old_crtc_state);
+ bool clone_mode_enabled = drm_crtc_in_clone_mode(crtc_state);
/* there might be cases where encoder needs a modeset too */
drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc_state->encoder_mask)
{
@@ -1286,6 +1290,10 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
crtc_state->mode_changed = true;
}
+ if ((clone_mode_requested && !clone_mode_enabled) ||
+ (!clone_mode_requested && clone_mode_enabled))
+ crtc_state->mode_changed = true;
+
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
rc = dpu_crtc_assign_resources(crtc, crtc_state);
if (rc < 0)
--
2.34.1
Re: [PATCH] drm/vkms: Add missing check for CRTC initialization
Hi Louis,
On 9/6/24 13:15, Louis Chauvet wrote:
CRTC initialization call drm_mode_crtc_set_gamma_size without the proper
checks, introduce this check to avoid issues.
Signed-off-by: Louis Chauvet
Applied to misc/kernel.git (drm-misc-next).
Best Regards,
- Maíra
---
drivers/gpu/drm/vkms/vkms_crtc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 40b4d084e3ce..e4f93dfbd071 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -287,7 +287,12 @@ int vkms_crtc_init(struct drm_device *dev, struct drm_crtc
*crtc,
drm_crtc_helper_add(crtc, &vkms_crtc_helper_funcs);
- drm_mode_crtc_set_gamma_size(crtc, VKMS_LUT_SIZE);
+ ret = drm_mode_crtc_set_gamma_size(crtc, VKMS_LUT_SIZE);
+ if (ret) {
+ DRM_ERROR("Failed to set gamma size\n");
+ return ret;
+ }
+
drm_crtc_enable_color_mgmt(crtc, 0, false, VKMS_LUT_SIZE);
spin_lock_init(&vkms_out->lock);
---
base-commit: a6bb1f77a94335de67dba12e7f52651c115b82d2
change-id: 20240906-vkms-add-missing-check-e1b6ee8d1b39
Best regards,
Re: [PATCH] drm/vkms: Suppress context imbalance sparse warning
Hi Louis,
On 9/12/24 12:25, Louis Chauvet wrote:
The functions `vkms_crtc_atomic_begin` and `vkms_crtc_atomic_flush` are
responsible for locking and unlocking a mutex, respectively. Add the
`__acquires` and `__releases` annotations to these functions to prevent
the associated sparse warning about context imbalance.
Signed-off-by: Louis Chauvet
When I was applying this patch, I got the following warning:
137f51649b04 (HEAD -> drm-misc-next) drm/vkms: Suppress context
imbalance sparse warning
-:4: WARNING:EMAIL_SUBJECT: A patch subject line should describe the
change not the tool that found it
#4:
Subject: [PATCH] drm/vkms: Suppress context imbalance sparse warning
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
Therefore, before pushing the patch, I changed the commit title to
"drm/vkms: Suppress context imbalance detected by sparse warning". Hope
you don't mind.
Applied to misc/kernel.git (drm-misc-next).
Best Regards,
- Maíra
---
drivers/gpu/drm/vkms/vkms_crtc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index
40b4d084e3ceef9e1e24b7338efdd9253afee8d6..2ad164b518fb93f5b6b86948116ff7ed97770b60
100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -232,6 +232,7 @@ static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
static void vkms_crtc_atomic_begin(struct drm_crtc *crtc,
struct drm_atomic_state *state)
+ __acquires(&vkms_output->lock)
{
struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc);
@@ -243,6 +244,7 @@ static void vkms_crtc_atomic_begin(struct drm_crtc *crtc,
static void vkms_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_atomic_state *state)
+ __releases(&vkms_output->lock)
{
struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc);
---
base-commit: d2194256049910d286cd6c308c2689df521d8842
change-id: 20240912-vkms-warnings-e0e331bc5e6d
Best regards,
Re: [PATCH] MAINTAINERS: remove myself as a VKMS maintainer
Hi Siqueira, On 9/11/24 10:50, Rodrigo Siqueira wrote: I haven't been able to follow or review the work on the driver for a long time and I don't see the situation improving anytime soon. Hence, this commit removes me from the maintainers list. Signed-off-by: Rodrigo Siqueira Applied to misc/kernel.git (drm-misc-next). Best Regards, - Maíra --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 333ed0718175..1e6356a1b6c7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7346,7 +7346,6 @@ T:git https://gitlab.freedesktop.org/drm/misc/kernel.git F:drivers/gpu/drm/udl/ DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS) -M: Rodrigo Siqueira M:Maíra Canal R:Haneen Mohammed R:Simona Vetter
Re: [PATCH] MAINTAINERS: Add myself as VKMS Maintainer
Hi Louis, On 9/10/24 12:10, Louis Chauvet wrote: I've been actively working on VKMS to provide new features and participated in reviews and testing. To help Maìra with her work, add myself as co-maintainer of VKMS. Signed-off-by: Louis Chauvet I see that you're now a developer in the drm/misc repo. Therefore, I applied this patch to misc/kernel.git (drm-misc-next). Thanks for volunteering! Best Regards, - Maíra --- Hi everyone, This series [1] has been waiting for a while now, it was proposed first in February. The first iterations had few reactions (thanks to Arthur, Pekka, Maìra, ...), but since v8 (in May) no major issues were reported, Maìra seemed satisfied, and only minor cosmetic changes were reported. Two other series ([2] and [3]), that I submitted first in May, did not have receive any reactions. In addition, there is also some significant addition to VKMS being proposed, such as ConfigFS support, and without a clear maintainer having the time to review and approve these changes, these changes have very little changes to get in. VKMS is not a fundamental driver for "normal" Linux users, but I had some feedback from userspace developpers that VKMS could be a very good testing tool if only it had more features (I think P0xx formats were asked to test HDR for example). This could also help to detect issues in DRM core by emulating a wide range of configurations. I believe the only active maintainer is Maìra, but as she's mentioned before, she doesn't have much time to work on VKMS. So, I'd like to volunteer as a maintainer. I have plenty of time to dedicate to VKMS. I hope I've gained enough understanding of VKMS to be helful with this role. I am eager to move forward and improve this subsystem. I've also talked to Sean about this, and he agrees that it would be good if I could commit code to drm-misc. [1]: https://lore.kernel.org/all/20240809-yuv-v10-0-1a7c76416...@bootlin.com/ [2]: https://lore.kernel.org/all/20240814-b4-new-color-formats-v2-0-8b3499cfe...@bootlin.com/ [3]: https://lore.kernel.org/all/20240814-writeback_line_by_line-v2-0-36541c717...@bootlin.com/ --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 10430778c998b57944c1a6c5f07d676127e47faa..62f10356e11ab7fa9c8f79ba63b335eb6580d0a8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7340,6 +7340,7 @@ DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS) M:Rodrigo Siqueira M:Melissa Wen M:Maíra Canal +M: Louis Chauvet R:Haneen Mohammed R:Daniel Vetter L:dri-devel@lists.freedesktop.org --- base-commit: da3ea35007d0af457a0afc87e84fddaebc4e0b63 change-id: 20240910-vkms-maintainer-7b3d2210cc1b Best regards,
Re: [PATCH v4] drm/vkms: Add documentation
Hi Louis,
On 9/5/24 10:27, Louis Chauvet wrote:
Add documentation around vkms_output and its initialization.
Add some documentation on pixel conversion functions.
Update of outdated comments for pixel_write functions.
Reviewed-by: José Expósito
Signed-off-by: Louis Chauvet
Applied to misc/kernel.git (drm-misc-next).
Best Regards,
- Maíra
---
This series does not introduce functionnal changes, only some
documentation and renaming to clarify the code.
---
Changes in v4:
- Applied comments from José
- Link to v3:
https://lore.kernel.org/r/20240829-google-clarifications-v3-1-f6604e2f6...@bootlin.com
Changes in v3:
- Merged https://lore.kernel.org/all/20240802-yuv-v9-3-08a706669...@bootlin.com/
as it also add documentation
- Apply José's comments, sorry
- Replace =1 by =BIT(0) for possible_crtc value
- Link to v2:
https://lore.kernel.org/r/20240826-google-clarifications-v2-1-2574655b0...@bootlin.com
Changes in v2:
- Dropped already applied patches
- Dropped useless patch as its content is deleted later
- Remove dependency on previous series
- Apply Maíra's comments
- Link to v1:
https://lore.kernel.org/r/20240814-google-clarifications-v1-0-3ee76d7d0...@bootlin.com
---
drivers/gpu/drm/vkms/vkms_composer.c | 7 +++
drivers/gpu/drm/vkms/vkms_drv.h | 101 ++-
drivers/gpu/drm/vkms/vkms_formats.c | 62 +
drivers/gpu/drm/vkms/vkms_output.c | 14 -
4 files changed, 161 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index e7441b227b3c..57a5769fc994 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -189,6 +189,13 @@ static void blend(struct vkms_writeback_job *wb,
size_t crtc_y_limit = crtc_state->base.crtc->mode.vdisplay;
+ /*
+* The planes are composed line-by-line to avoid heavy memory usage. It
is a necessary
+* complexity to avoid poor blending performance.
+*
+* The function vkms_compose_row() is used to read a line,
pixel-by-pixel, into the staging
+* buffer.
+*/
for (size_t y = 0; y < crtc_y_limit; y++) {
fill_background(&background_color, output_buffer);
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 5e46ea5b96dc..672fe191e239 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -25,6 +25,17 @@
#define VKMS_LUT_SIZE 256
+/**
+ * struct vkms_frame_info - Structure to store the state of a frame
+ *
+ * @fb: backing drm framebuffer
+ * @src: source rectangle of this frame in the source framebuffer, stored in
16.16 fixed-point form
+ * @dst: destination rectangle in the crtc buffer, stored in whole pixel units
+ * @map: see @drm_shadow_plane_state.data
+ * @rotation: rotation applied to the source.
+ *
+ * @src and @dst should have the same size modulo the rotation.
+ */
struct vkms_frame_info {
struct drm_framebuffer *fb;
struct drm_rect src, dst;
@@ -52,9 +63,11 @@ struct vkms_writeback_job {
};
/**
- * vkms_plane_state - Driver specific plane state
+ * struct vkms_plane_state - Driver specific plane state
* @base: base plane state
* @frame_info: data required for composing computation
+ * @pixel_read: function to read a pixel in this plane. The creator of a
struct vkms_plane_state
+ * must ensure that this pointer is valid
*/
struct vkms_plane_state {
struct drm_shadow_plane_state base;
@@ -73,29 +86,56 @@ struct vkms_color_lut {
};
/**
- * vkms_crtc_state - Driver specific CRTC state
+ * struct vkms_crtc_state - Driver specific CRTC state
+ *
* @base: base CRTC state
* @composer_work: work struct to compose and add CRC entries
- * @n_frame_start: start frame number for computed CRC
- * @n_frame_end: end frame number for computed CRC
+ *
+ * @num_active_planes: Number of active planes
+ * @active_planes: List containing all the active planes (counted by
+ *@num_active_planes). They should be stored in z-order.
+ * @active_writeback: Current active writeback job
+ * @gamma_lut: Look up table for gamma used in this CRTC
+ * @crc_pending: Protected by @vkms_output.composer_lock, true when the frame
CRC is not computed
+ * yet. Used by vblank to detect if the composer is too slow.
+ * @wb_pending: Protected by @vkms_output.composer_lock, true when a writeback
frame is requested.
+ * @frame_start: Protected by @vkms_output.composer_lock, saves the frame
number before the start
+ * of the composition process.
+ * @frame_end: Protected by @vkms_output.composer_lock, saves the last
requested frame number.
+ *This is used to generate enough CRC entries when the composition
worker is too slow.
*/
struct vkms_crtc_state {
struct drm_crtc_state base;
struct work_struct composer_work;
int num_acti
Re: [PATCH v2 22/22] drm/msm/dpu: Set possible clones for all encoders
On Tue, Sep 24, 2024 at 03:59:38PM GMT, Jessica Zhang wrote: > Set writeback encoders as possible clones for non-writeback encoders and > vice versa. > > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 32 > + > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 ++ > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 +-- > 3 files changed, 39 insertions(+), 2 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH] dt-bindings: lcdif: Add support for specifying display with timings
On 9/25/24 12:57 AM, Rob Herring wrote: On Mon, Sep 23, 2024 at 07:53:57PM +0200, Marek Vasut wrote: On 9/23/24 3:57 PM, Lukasz Majewski wrote: Up till now the fsl,lcdif.yaml was requiring the "port" property as a must have to specify the display interface on iMX devices. However, it shall also be possible to specify the display only with passing its timing parameters (h* and v* ones) via "display" property: (as in Documentation/devicetree/bindings/display/panel/display-timings.yaml). Timings should go into panel node, not into scanout engine node. See e.g. panel-timings in arch/arm64/boot/dts/freescale/imx8mm-phg.dts , in your case the compatible might be "panel-dpi" . I agree, but if this is already in use, we should allow it. We can mark it deprecated though. I don't think it is in use yet, at least not in upstream, so let's not allow this.
Re: [PATCH v2 20/22] drm/msm/dpu: Skip trigger flush and start for CWB
On Tue, Sep 24, 2024 at 03:59:36PM GMT, Jessica Zhang wrote: > For concurrent writeback, the real time encoder is responsible for > trigger flush and trigger start. Return early for trigger start and > trigger flush for the concurrent writeback encoders. > > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 ++ > 1 file changed, 18 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 16/22] drm/msm/dpu: Configure CWB in writeback encoder
On Tue, Sep 24, 2024 at 03:59:32PM GMT, Jessica Zhang wrote:
> Cache the CWB block mask in the DPU virtual encoder and configure CWB
> according to the CWB block mask within the writeback phys encoder
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 83
> +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 16 -
> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 4 +-
> 3 files changed, 100 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index b2f0bf412451..2628f2d55cb3 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -24,6 +24,7 @@
> #include "dpu_hw_catalog.h"
> #include "dpu_hw_intf.h"
> #include "dpu_hw_ctl.h"
> +#include "dpu_hw_cwb.h"
> #include "dpu_hw_dspp.h"
> #include "dpu_hw_dsc.h"
> #include "dpu_hw_merge3d.h"
> @@ -139,6 +140,7 @@ enum dpu_enc_rc_states {
> * num_phys_encs.
> * @hw_dsc: Handle to the DSC blocks used for the display.
> * @dsc_mask:Bitmask of used DSC blocks.
> + * @cwb_mask Bitmask of used CWB muxes
> * @intfs_swapped: Whether or not the phys_enc interfaces have been swapped
> * for partial update right-only cases, such as pingpong
> * split where virtual pingpong does not generate IRQs
> @@ -185,6 +187,7 @@ struct dpu_encoder_virt {
> struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
>
> unsigned int dsc_mask;
> + unsigned int cwb_mask;
>
> bool intfs_swapped;
>
> @@ -1063,6 +1066,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> int num_cwb = 0;
> bool is_cwb_encoder;
> unsigned int dsc_mask = 0;
> + unsigned int cwb_mask = 0;
> int i;
>
> if (!drm_enc) {
> @@ -1103,8 +1107,12 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> ARRAY_SIZE(hw_pp));
> }
>
> - for (i = 0; i < num_cwb; i++)
> + for (i = 0; i < num_cwb; i++) {
> dpu_enc->hw_cwb[i] = to_dpu_hw_cwb(hw_cwb[i]);
> + cwb_mask |= BIT(dpu_enc->hw_cwb[i]->idx - CWB_0);
> + }
> +
> + dpu_enc->cwb_mask = cwb_mask;
>
> dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> drm_enc->crtc, DPU_HW_BLK_CTL, hw_ctl,
> ARRAY_SIZE(hw_ctl));
> @@ -2071,6 +2079,9 @@ void dpu_encoder_helper_phys_cleanup(struct
> dpu_encoder_phys *phys_enc)
> }
> }
>
> + if (dpu_enc->cwb_mask)
> + dpu_encoder_helper_phys_setup_cwb(phys_enc, false);
> +
> /* reset the merge 3D HW block */
> if (phys_enc->hw_pp && phys_enc->hw_pp->merge_3d) {
>
> phys_enc->hw_pp->merge_3d->ops.setup_3d_mode(phys_enc->hw_pp->merge_3d,
> @@ -2114,6 +2125,68 @@ void dpu_encoder_helper_phys_cleanup(struct
> dpu_encoder_phys *phys_enc)
> ctl->ops.clear_pending_flush(ctl);
> }
>
> +void dpu_encoder_helper_phys_setup_cwb(struct dpu_encoder_phys *phys_enc,
> +bool enable)
> +{
> + struct dpu_encoder_virt *dpu_enc =
> to_dpu_encoder_virt(phys_enc->parent);
> + struct dpu_hw_cwb *hw_cwb;
> + struct dpu_hw_cwb_setup_cfg cwb_cfg;
> +
> + struct dpu_kms *dpu_kms;
> + struct dpu_global_state *global_state;
> + struct dpu_hw_blk *rt_pp_list[MAX_CHANNELS_PER_ENC];
> + int num_pp, rt_pp_idx[MAX_CHANNELS_PER_ENC];
> +
> + if (!phys_enc || !phys_enc->hw_wb || !dpu_enc->cwb_mask)
> + return;
We have already dereferened phys_enc, so checking that it's not NULL is
futile. Also we know that the function is only called if cwb_mask is not
zero, so the last check is also useless.
> +
> + dpu_kms = phys_enc->dpu_kms;
> + global_state = dpu_kms_get_existing_global_state(dpu_kms);
> + num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> +phys_enc->parent->crtc,
> +DPU_HW_BLK_PINGPONG, rt_pp_list,
> +ARRAY_SIZE(rt_pp_list));
> +
> + if (num_pp == 0 || num_pp > MAX_CHANNELS_PER_ENC) {
> + DPU_DEBUG_ENC(dpu_enc, "invalid num_pp %d\n", num_pp);
> + return;
> + }
> +
> + for (int i = 0; i < num_pp; i++) {
> + struct dpu_hw_pingpong *hw_pp =
> to_dpu_hw_pingpong(rt_pp_list[i]);
> +
> + for (int j = 0; j < ARRAY_SIZE(dpu_enc->hw_cwb); j++) {
> + hw_cwb = dpu_enc->hw_cwb[i];
> +
> + /*
> + * Even CWB muxes must take input from even real-time
> + * pingpongs and odd CWB muxes must take input from odd
> + * pingpongs
> +
Re: [PATCH v2 15/22] drm/msm/dpu: Reserve resources for CWB
On Tue, Sep 24, 2024 at 03:59:31PM GMT, Jessica Zhang wrote:
> Add support for RM to reserve dedicated CWB pingpongs and CWB muxes
>
> For concurrent writeback, even-indexed CWB muxes must be assigned to
> even-indexed LMs and odd-indexed CWB muxes for odd-indexed LMs. The same
> even/odd rule applies for dedicated CWB pingpongs.
>
> Track the CWB muxes in the global state and add a CWB-specific helper to
> reserve the correct CWB muxes and dedicated pingpongs following the
> even/odd rule.
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 34 ++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 84
> +
> 4 files changed, 117 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 36b677cf9c7a..b2f0bf412451 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -2,7 +2,7 @@
> /*
> * Copyright (C) 2013 Red Hat
> * Copyright (c) 2014-2018, 2020-2021 The Linux Foundation. All rights
> reserved.
> - * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights
> reserved.
> + * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights
> reserved.
> *
> * Author: Rob Clark
> */
> @@ -28,6 +28,7 @@
> #include "dpu_hw_dsc.h"
> #include "dpu_hw_merge3d.h"
> #include "dpu_hw_cdm.h"
> +#include "dpu_hw_cwb.h"
> #include "dpu_formats.h"
> #include "dpu_encoder_phys.h"
> #include "dpu_crtc.h"
> @@ -133,6 +134,9 @@ enum dpu_enc_rc_states {
> * @cur_slave: As above but for the slave encoder.
> * @hw_pp: Handle to the pingpong blocks used for the display. No.
> * pingpong blocks can be different than num_phys_encs.
> + * @hw_cwb: Handle to the CWB muxes used for concurrent writeback
> + * display. Number of CWB muxes can be different than
> + * num_phys_encs.
> * @hw_dsc: Handle to the DSC blocks used for the display.
> * @dsc_mask:Bitmask of used DSC blocks.
> * @intfs_swapped: Whether or not the phys_enc interfaces have been swapped
> @@ -177,6 +181,7 @@ struct dpu_encoder_virt {
> struct dpu_encoder_phys *cur_master;
> struct dpu_encoder_phys *cur_slave;
> struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
> + struct dpu_hw_cwb *hw_cwb[MAX_CHANNELS_PER_ENC];
> struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
>
> unsigned int dsc_mask;
> @@ -1053,7 +1058,10 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
> struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
> struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
> + struct dpu_hw_blk *hw_cwb[MAX_CHANNELS_PER_ENC];
> int num_pp, num_dsc;
> + int num_cwb = 0;
> + bool is_cwb_encoder;
> unsigned int dsc_mask = 0;
> int i;
>
> @@ -1067,6 +1075,8 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
>
> priv = drm_enc->dev->dev_private;
> dpu_kms = to_dpu_kms(priv->kms);
> + is_cwb_encoder = drm_crtc_in_clone_mode(crtc_state) &&
> + dpu_enc->disp_info.intf_type == INTF_WB;
>
> global_state = dpu_kms_get_existing_global_state(dpu_kms);
> if (IS_ERR_OR_NULL(global_state)) {
> @@ -1077,9 +1087,25 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> trace_dpu_enc_mode_set(DRMID(drm_enc));
>
> /* Query resource that have been reserved in atomic check step. */
> - num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> - drm_enc->crtc, DPU_HW_BLK_PINGPONG, hw_pp,
> - ARRAY_SIZE(hw_pp));
> + if (is_cwb_encoder) {
> + num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm,
> global_state,
> +drm_enc->crtc,
> +DPU_HW_BLK_DCWB_PINGPONG,
> +hw_pp,
> ARRAY_SIZE(hw_pp));
> + num_cwb = dpu_rm_get_assigned_resources(&dpu_kms->rm,
> global_state,
> +drm_enc->crtc,
> +DPU_HW_BLK_CWB,
> +hw_cwb,
> ARRAY_SIZE(hw_cwb));
> + } else {
> + num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm,
> global_state,
> +drm_enc->crtc,
> +DPU_HW_BLK_PINGPONG,
> hw_pp,
> +ARRAY_SIZE(hw_pp)
Re: [PATCH v3 1/6] drm: add DRM_SET_NAME ioctl
On 9/23/24 21:18, Dmitry Osipenko wrote: > On 9/23/24 21:09, Dmitry Osipenko wrote: >>> Sure, I can do that if others prefer this way too. >> Note that in the other email I suggested to use strndup_user(), that >> will remove the name-length limitation, but then the name var will >> remain to be a string pointer. To me best option would be to replicate >> how dma_buf_set_name works. > > My bad, strndup_user() is also size-limited. Then the point about static > string remains. To clarify a bit further, I'm fine with both variants. Having a consistent solution across kernel is also good if it's good enough. I.e. replicating the whole dma_buf_set_name using the name pointer is okay to me, though not having string pointers is more robust in general. Choose what you like more. -- Best regards, Dmitry
Re: [PATCH] drm/v3d: Use v3d_perfmon_find(..)
Hi Christian, On 9/23/24 12:19, Christian Gmeiner wrote: From: Christian Gmeiner Replace the open coded v3d_perfmon_find(..) with the real thing. Signed-off-by: Christian Gmeiner Thanks for your patch! Reviewed-by: Maíra Canal Applied to misc/kernel.git (drm-misc-next). Best Regards, - Maíra --- drivers/gpu/drm/v3d/v3d_perfmon.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/v3d/v3d_perfmon.c b/drivers/gpu/drm/v3d/v3d_perfmon.c index cd7f1eedf17f..54a486a9b74c 100644 --- a/drivers/gpu/drm/v3d/v3d_perfmon.c +++ b/drivers/gpu/drm/v3d/v3d_perfmon.c @@ -402,11 +402,7 @@ int v3d_perfmon_get_values_ioctl(struct drm_device *dev, void *data, if (req->pad != 0) return -EINVAL; - mutex_lock(&v3d_priv->perfmon.lock); - perfmon = idr_find(&v3d_priv->perfmon.idr, req->id); - v3d_perfmon_get(perfmon); - mutex_unlock(&v3d_priv->perfmon.lock); - + perfmon = v3d_perfmon_find(v3d_priv, req->id); if (!perfmon) return -EINVAL;
Re: [PATCH v2 14/22] drm/msm/dpu: Require modeset if clone mode status changes
On Tue, Sep 24, 2024 at 03:59:30PM GMT, Jessica Zhang wrote:
> If the clone mode enabled status is changing, a modeset needs to happen
> so that the resources can be reassigned
Sima's comment regarding crtc_state->mode_changed seems to be ignored...
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index a7850bf844db..f20e44e9fc05 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1268,6 +1268,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
> {
> struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
> crtc);
> + struct drm_crtc_state *old_crtc_state =
> drm_atomic_get_old_crtc_state(state,
> +
> crtc);
> struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
> struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
>
> @@ -1279,6 +1281,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
> int rc = 0;
>
> bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
> + bool clone_mode_requested = drm_crtc_in_clone_mode(old_crtc_state);
> + bool clone_mode_enabled = drm_crtc_in_clone_mode(crtc_state);
>
> /* there might be cases where encoder needs a modeset too */
> drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc_state->encoder_mask)
> {
> @@ -1286,6 +1290,10 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
> crtc_state->mode_changed = true;
> }
>
> + if ((clone_mode_requested && !clone_mode_enabled) ||
> + (!clone_mode_requested && clone_mode_enabled))
> + crtc_state->mode_changed = true;
> +
> if (drm_atomic_crtc_needs_modeset(crtc_state)) {
> rc = dpu_crtc_assign_resources(crtc, crtc_state);
> if (rc < 0)
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
Re: [PATCH v2 13/22] drm/msm/dpu: Add CWB to msm_display_topology
On Tue, Sep 24, 2024 at 03:59:29PM GMT, Jessica Zhang wrote:
> Add the cwb_enabled flag to msm_display topology and adjust the toplogy
> to account for concurrent writeback
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 --
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 --
> drivers/gpu/drm/msm/msm_drv.h| 2 ++
> 3 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index d53e986eee54..a7850bf844db 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1176,6 +1176,8 @@ static struct msm_display_topology
> dpu_crtc_get_topology(
> dpu_encoder_update_topology(drm_enc, &topology,
> crtc_state->state,
> &crtc_state->adjusted_mode);
>
> + topology.cwb_enabled = drm_crtc_in_clone_mode(crtc_state);
> +
> /*
>* Datapath topology selection
>*
> @@ -1189,9 +1191,9 @@ static struct msm_display_topology
> dpu_crtc_get_topology(
>* Add dspps to the reservation requirements if ctm is requested
>*/
>
> - if (topology.num_intf == 2)
> + if (topology.num_intf == 2 && !topology.cwb_enabled)
> topology.num_lm = 2;
> - else if (topology.num_dsc == 2)
> + else if (topology.num_dsc == 2 && !topology.cwb_enabled)
Is it a temporal restriction or is it a hardware limitation? Can we use
two LMs with a single WB?
> topology.num_lm = 2;
> else if (dpu_kms->catalog->caps->has_3d_merge)
> topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> index 96c80cf9f6ad..04df3056d75a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> @@ -371,8 +371,14 @@ static int _dpu_rm_reserve_ctls(
> int i = 0, j, num_ctls;
> bool needs_split_display;
>
> - /* each hw_intf needs its own hw_ctrl to program its control path */
> - num_ctls = top->num_intf;
> + /*
> + * For non-CWB mode, each hw_intf needs its own hw_ctl to program its
> + * control path. Hardcode num_ctls to 1 if CWB is enabled
> + */
> + if (top->cwb_enabled)
> + num_ctls = 1;
> + else
> + num_ctls = top->num_intf;
>
> needs_split_display = _dpu_rm_needs_split_display(top);
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 0d3adf398bc1..8a2a3705f117 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -1,5 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
> /*
> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
> * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
> * Copyright (C) 2013 Red Hat
> * Author: Rob Clark
> @@ -88,6 +89,7 @@ struct msm_display_topology {
> u32 num_dspp;
> u32 num_dsc;
> bool needs_cdm;
> + bool cwb_enabled;
> };
>
> /* Commit/Event thread specific structure */
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
Re: [PATCH v2 12/22] drm/msm/dpu: Add RM support for allocating CWB
On Tue, Sep 24, 2024 at 03:59:28PM GMT, Jessica Zhang wrote: > Add support for allocating the concurrent writeback mux as part of the > WB allocation > > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 17 +++-- > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 ++ > 2 files changed, 17 insertions(+), 2 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 11/22] drm/msm/dpu: add CWB support to dpu_hw_wb
On Tue, Sep 24, 2024 at 03:59:27PM GMT, Jessica Zhang wrote: > From: Esha Bharadwaj > > Adjust the WB_MUX configuration to account for using dedicated CWB > pingpong blocks. > > Signed-off-by: Esha Bharadwaj > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 10/22] drm/msm/dpu: Add dpu_hw_cwb abstraction for CWB block
On Tue, Sep 24, 2024 at 03:59:26PM GMT, Jessica Zhang wrote: > The CWB mux has its own registers and set of operations. Add dpu_hw_cwb > abstraction to allow driver to configure the CWB mux. > > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/Makefile| 1 + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.c | 73 > + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.h | 70 +++ > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 +- > 4 files changed, 148 insertions(+), 1 deletion(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 08/22] drm/msm/dpu: Specify dedicated CWB pingpong blocks
On Tue, Sep 24, 2024 at 03:59:24PM GMT, Jessica Zhang wrote: > Change pingpong index and names to distinguish between general use > pingpong blocks and pingpong blocks dedicated for concurrent writeback > > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 8 > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 4 ++-- > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 4 ++-- > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 4 ++-- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 8 > 5 files changed, 14 insertions(+), 14 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 07/22] drm/msm/dpu: Add CWB entry to catalog for SM8650
On Tue, Sep 24, 2024 at 03:59:23PM GMT, Jessica Zhang wrote: > From: Esha Bharadwaj > > Add a new block for concurrent writeback mux to the SM8650 HW catalog > > Signed-off-by: Esha Bharadwaj > Signed-off-by: Jessica Zhang > --- > .../gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 21 > + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 + > 2 files changed, 34 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 06/22] drm/msm/dpu: fill CRTC resources in dpu_crtc.c
On Tue, Sep 24, 2024 at 03:59:22PM GMT, Jessica Zhang wrote:
> From: Dmitry Baryshkov
>
> Stop poking into CRTC state from dpu_encoder.c, fill CRTC HW resources
> from dpu_crtc_assign_resources().
>
> Signed-off-by: Dmitry Baryshkov
> [quic_abhin...@quicinc.com: cleaned up formatting]
> Signed-off-by: Abhinav Kumar
> [quic_jessz...@quicinc.com: dropped clearing num_mixers in CRTC disable
> path]
Same comment as before: the code is still there.
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 32
> ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 24 ++
> 2 files changed, 31 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index b918c80d30b3..d53e986eee54 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1091,9 +1091,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
>
> dpu_core_perf_crtc_update(crtc, 0);
>
> - memset(cstate->mixers, 0, sizeof(cstate->mixers));
> - cstate->num_mixers = 0;
> -
> /* disable clk & bw control until clk & bw properties are set */
> cstate->bw_control = false;
> cstate->bw_split_vote = false;
> @@ -1164,6 +1161,7 @@ static bool dpu_crtc_needs_dirtyfb(struct
> drm_crtc_state *cstate)
> }
>
> #define MAX_HDISPLAY_SPLIT 1080
> +#define MAX_CHANNELS_PER_CRTC 2
>
> static struct msm_display_topology dpu_crtc_get_topology(
> struct drm_crtc *crtc,
> @@ -1208,9 +1206,14 @@ static struct msm_display_topology
> dpu_crtc_get_topology(
>
> static int dpu_crtc_assign_resources(struct drm_crtc *crtc, struct
> drm_crtc_state *crtc_state)
> {
> + struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_CRTC];
> + struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_CRTC];
> + struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_CRTC];
> + int i, num_lm, num_ctl, num_dspp;
> struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
> struct dpu_global_state *global_state;
> struct msm_display_topology topology;
> + struct dpu_crtc_state *cstate;
> int ret;
>
> /*
> @@ -1232,6 +1235,29 @@ static int dpu_crtc_assign_resources(struct drm_crtc
> *crtc, struct drm_crtc_stat
> if (ret)
> return ret;
>
> + cstate = to_dpu_crtc_state(crtc_state);
> +
> + num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> + crtc, DPU_HW_BLK_CTL, hw_ctl,
> + ARRAY_SIZE(hw_ctl));
> + num_lm = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> +crtc, DPU_HW_BLK_LM, hw_lm,
> +ARRAY_SIZE(hw_lm));
> + num_dspp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> + crtc, DPU_HW_BLK_DSPP, hw_dspp,
> + ARRAY_SIZE(hw_dspp));
> +
> + for (i = 0; i < num_lm; i++) {
> + int ctl_idx = (i < num_ctl) ? i : (num_ctl-1);
> +
> + cstate->mixers[i].hw_lm = to_dpu_hw_mixer(hw_lm[i]);
> + cstate->mixers[i].lm_ctl = to_dpu_hw_ctl(hw_ctl[ctl_idx]);
> + if (i < num_dspp)
> + cstate->mixers[i].hw_dspp = to_dpu_hw_dspp(hw_dspp[i]);
> + }
> +
> + cstate->num_mixers = num_lm;
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index ada9119326ca..36b677cf9c7a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -1049,14 +1049,11 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> struct dpu_encoder_virt *dpu_enc;
> struct msm_drm_private *priv;
> struct dpu_kms *dpu_kms;
> - struct dpu_crtc_state *cstate;
> struct dpu_global_state *global_state;
> struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
> struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
> - struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
> - struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
> struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
> - int num_lm, num_ctl, num_pp, num_dsc;
> + int num_pp, num_dsc;
> unsigned int dsc_mask = 0;
> int i;
>
> @@ -1083,13 +1080,8 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
> num_pp = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> drm_enc->crtc, DPU_HW_BLK_PINGPONG, hw_pp,
> ARRAY_SIZE(hw_pp));
> - num_ctl = dpu_rm_get_assigned_resources(&dpu_kms->rm, global_state,
> - drm_enc->crtc, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
> - num_lm = dpu_rm_get_assi
Re: [PATCH v2 05/22] drm/msm/dpu: move resource allocation to CRTC
On Tue, Sep 24, 2024 at 03:59:21PM GMT, Jessica Zhang wrote:
> From: Dmitry Baryshkov
>
> All resource allocation is centered around the LMs. Then other blocks
> (except DSCs) are allocated basing on the LMs that was selected, and LM
> powers up the CRTC rather than the encoder.
>
> Moreover if at some point the driver supports encoder cloning,
> allocating resources from the encoder will be incorrect, as all clones
> will have different encoder IDs, while LMs are to be shared by these
> encoders.
>
> Signed-off-by: Dmitry Baryshkov
> [quic_abhin...@quicinc.com: Refactored resource allocation for CDM]
> Signed-off-by: Abhinav Kumar
> [quic_jessz...@quicinc.com: Changed to grabbing exising global state]
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 86
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 201
> +++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 19 +++
> 3 files changed, 183 insertions(+), 123 deletions(-)
>
> @@ -544,159 +542,117 @@ void dpu_encoder_helper_split_config(
> }
> }
>
> -bool dpu_encoder_use_dsc_merge(struct drm_encoder *drm_enc)
> +void dpu_encoder_update_topology(struct drm_encoder *drm_enc,
> + struct msm_display_topology *topology,
> + struct drm_atomic_state *state,
> + const struct drm_display_mode *adj_mode)
> {
> struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
> - int i, intf_count = 0, num_dsc = 0;
> + struct drm_connector *connector;
> + struct drm_connector_state *conn_state;
> + struct msm_display_info *disp_info;
> + struct drm_framebuffer *fb;
> + struct msm_drm_private *priv;
> + int i;
>
> for (i = 0; i < MAX_PHYS_ENCODERS_PER_VIRTUAL; i++)
> if (dpu_enc->phys_encs[i])
> - intf_count++;
> + topology->num_intf++;
>
> - /* See dpu_encoder_get_topology, we only support 2:2:1 topology */
> + /* We only support 2 DSC mode (with 2 LM and 1 INTF) */
> if (dpu_enc->dsc)
> - num_dsc = 2;
> + topology->num_dsc += 2;
>
> - return (num_dsc > 0) && (num_dsc > intf_count);
> -}
> + connector = drm_atomic_get_new_connector_for_encoder(state, drm_enc);
> + if (!connector)
> + return;
> + conn_state = drm_atomic_get_new_connector_state(state, connector);
> + if (!conn_state)
> + return;
>
> -struct drm_dsc_config *dpu_encoder_get_dsc_config(struct drm_encoder
> *drm_enc)
> -{
> - struct msm_drm_private *priv = drm_enc->dev->dev_private;
> - struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
> - int index = dpu_enc->disp_info.h_tile_instance[0];
> + disp_info = &dpu_enc->disp_info;
>
> - if (dpu_enc->disp_info.intf_type == INTF_DSI)
> - return msm_dsi_get_dsc_config(priv->dsi[index]);
> + priv = drm_enc->dev->dev_private;
>
> - return NULL;
> + /*
> + * Use CDM only for writeback or DP at the moment as other interfaces
> cannot handle it.
> + * If writeback itself cannot handle cdm for some reason it will fail
> in its atomic_check()
> + * earlier.
> + */
> + if (disp_info->intf_type == INTF_WB && conn_state->writeback_job) {
> + fb = conn_state->writeback_job->fb;
> +
> + if (fb && MSM_FORMAT_IS_YUV(msm_framebuffer_format(fb)))
> + topology->needs_cdm = true;
> + } else if (disp_info->intf_type == INTF_DP) {
> + if
> (msm_dp_is_yuv_420_enabled(priv->dp[disp_info->h_tile_instance[0]], adj_mode))
> + topology->needs_cdm = true;
> + }
Just to note, the needs_cdm is not enough once you introduce CWB
support. E.g. DP/YUV420 + WB/YUV case requires two CDM blocks (which we
don't have), but this doesn't get reflected in the topology.
> }
>
--
With best wishes
Dmitry
Re: [PATCH v2 01/22] drm: add clone mode check for CRTC
On Tue, Sep 24, 2024 at 03:59:17PM GMT, Jessica Zhang wrote:
> Add helper to check if the given CRTC state is in clone mode
>
> Signed-off-by: Jessica Zhang
> ---
> include/drm/drm_crtc.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8b48a1974da3..ecb93e2c4afc 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1323,5 +1323,12 @@ static inline struct drm_crtc *drm_crtc_find(struct
> drm_device *dev,
>
> int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
> unsigned int supported_filters);
Missing kerneldoc
> +static inline bool drm_crtc_in_clone_mode(struct drm_crtc_state *crtc_state)
> +{
> + if (!crtc_state)
> + return false;
> +
> + return hweight32(crtc_state->encoder_mask) > 1;
> +}
>
> #endif /* __DRM_CRTC_H__ */
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
Re: [RFC PATCH 0/4] Linaro restricted heap
On Tue, Sep 24, 2024 at 01:13:18PM GMT, Andrew Davis wrote: > On 9/23/24 1:33 AM, Dmitry Baryshkov wrote: > > Hi, > > > > On Fri, Aug 30, 2024 at 09:03:47AM GMT, Jens Wiklander wrote: > > > Hi, > > > > > > This patch set is based on top of Yong Wu's restricted heap patch set [1]. > > > It's also a continuation on Olivier's Add dma-buf secure-heap patch set > > > [2]. > > > > > > The Linaro restricted heap uses genalloc in the kernel to manage the heap > > > carvout. This is a difference from the Mediatek restricted heap which > > > relies on the secure world to manage the carveout. > > > > > > I've tried to adress the comments on [2], but [1] introduces changes so > > > I'm > > > afraid I've had to skip some comments. > > > > I know I have raised the same question during LPC (in connection to > > Qualcomm's dma-heap implementation). Is there any reason why we are > > using generic heaps instead of allocating the dma-bufs on the device > > side? > > > > In your case you already have TEE device, you can use it to allocate and > > export dma-bufs, which then get imported by the V4L and DRM drivers. > > > > This goes to the heart of why we have dma-heaps in the first place. > We don't want to burden userspace with having to figure out the right > place to get a dma-buf for a given use-case on a given hardware. > That would be very non-portable, and fail at the core purpose of > a kernel: to abstract hardware specifics away. Unfortunately all proposals to use dma-buf heaps were moving in the described direction: let app select (somehow) from a platform- and vendor- specific list of dma-buf heaps. In the kernel we at least know the platform on which the system is running. Userspace generally doesn't (and shouldn't). As such, it seems better to me to keep the knowledge in the kernel and allow userspace do its job by calling into existing device drivers. > > Worse, the actual interface for dma-buf exporting changes from > framework to framework (getting a dma-buf from DRM is different > than V4L, and there would be yet another API for TEE, etc..) But if the app is working with the particular subsystem, then it already talks its language. Allocating a dma-buf is just another part of the interface, which the app already has to support. > Most subsystem don't need an allocator, they work just fine > simply being only dma-bufs importers. Recent example being the > IIO subsystem[0], for which some early posting included an > allocator, but in the end, all that was needed was to consume > buffers. > > For devices that don't actually contain memory there is no > reason to be an exporter. What most want is just to consume > normal system memory. Or system memory with some constraints > (e.g. contiguous, coherent, restricted, etc..). ... secure, accessible only to the camera and video encoder, ... or accessible only to the video decoder and the display unit. Who specifies those restrictions? Can we express them in a platform-neutral way? > > > I have a feeling (I might be completely wrong here) that by using > > generic dma-buf heaps we can easily end up in a situation when the > > userspace depends heavily on the actual platform being used (to map the > > platform to heap names). I think we should instead depend on the > > existing devices (e.g. if there is a TEE device, use an IOCTL to > > allocate secured DMA BUF from it, otherwise check for QTEE device, > > otherwise check for some other vendor device). > > > > The mental experiment to check if the API is correct is really simple: > > Can you use exactly the same rootfs on several devices without > > any additional tuning (e.g. your QEMU, HiKey, a Mediatek board, Qualcomm > > laptop, etc)? > > > > This is a great north star to follow. And exactly the reason we should > *not* be exposing device specific constraints to userspace. The constrains > change based on the platform. So a userspace would have to also pick > a different set of constraints based on each platform. Great, I totally agree here. > Userspace knows which subsystems it will attach a buffer, and the > kernel knows what constraints those devices have on a given platform. > Ideal case is then allocate from the one exporter, attach to various > devices, and have the constraints solved at map time by the exporter > based on the set of attached devices. > > For example, on one platform the display needs contiguous buffers, > but on a different platform the display can scatter-gather. So > what heap should our generic application allocate from when it > wants a buffer consumable by the display, CMA or System? > Answer *should* be always use the generic exporter, and that > exporter then picks the right backing type based on the platform. The display can support scather-gather, the GPU needs bigger stride for this particular format and the video encoder decoder can not support SG. Which set of constraints and which buffer size should generic exporter select? > Userspace shouldn't be de
Re: [PATCH] dt-bindings: lcdif: Add support for specifying display with timings
On Mon, Sep 23, 2024 at 03:57:44PM +0200, Lukasz Majewski wrote:
> Up till now the fsl,lcdif.yaml was requiring the "port" property as a
> must have to specify the display interface on iMX devices.
>
> However, it shall also be possible to specify the display only with
> passing its timing parameters (h* and v* ones) via "display" property:
> (as in
> Documentation/devicetree/bindings/display/panel/display-timings.yaml).
>
> Such approach has already been used (also in the mainline) with several
> imx28, imx5x and imx6q devices.
>
> This change allows them to pass the DT_SCHEMA check without issues.
>
> Signed-off-by: Lukasz Majewski
> ---
> .../bindings/display/fsl,lcdif.yaml | 51 ++-
> 1 file changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> index 8e3a98aeec32..14bb64b5b72d 100644
> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> @@ -50,6 +50,10 @@ properties:
>- const: disp_axi
> minItems: 1
>
> + display:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description: The phandle for display timing information
> +
>dmas:
> items:
>- description: DMA specifier for the RX DMA channel.
> @@ -64,6 +68,9 @@ properties:
>- description: LCDIF Error interrupt
> minItems: 1
>
> + lcd-supply:
> +description: Regulator for LCD supply voltage.
> +
>power-domains:
> maxItems: 1
>
> @@ -76,7 +83,10 @@ required:
>- reg
>- clocks
>- interrupts
> - - port
> +
> +patternProperties:
> + 'display([0-9])':
This allows for 'foodisplay0bar'. You need start and end anchors.
And it doesn't even have to be a node because there are no contraints
here. You need 'type: object' and then to define what's in the node.
> +description: Node with display timing parameters
>
> additionalProperties: false
>
> @@ -197,5 +207,42 @@ examples:
> };
> };
> };
> -
> + - |
> +lcdif: lcdif@8003 {
> +compatible = "fsl,imx28-lcdif";
> +reg = <0x8003 0x2000>;
> +interrupts = <38>;
> +clocks = <&clks 55>;
> +dmas = <&dma_apbh 13>;
> +dma-names = "rx";
> +pinctrl-names = "default";
> +pinctrl-0 = <&lcdif_24bit_pins_a>, <&lcdif_sync_pins_bttc>,
> + <&lcdif_reset_pins_bttc>;
> +lcd-supply = <®_3v3>;
> +display = <&display0>;
> +status = "okay";
Don't need status in the examples.
> +
> +bits-per-pixel = <32>;
> +bus-width = <24>;
> +display-timings {
> +native-mode = <&timing0>;
> +timing0: timing0 {
> +clock-frequency = <650>;
> +hactive = <320>;
> +vactive = <240>;
> +hfront-porch = <20>;
> +hback-porch = <38>;
> +hsync-len = <30>;
> +vfront-porch = <4>;
> +vback-porch = <14>;
> +vsync-len = <4>;
> +hsync-active = <0>;
> +vsync-active = <0>;
> +de-active = <0>;
> +pixelclk-active = <1>;
> +};
> +};
> +};
> +};
> ...
> --
> 2.39.2
>
Re: [PATCH] dt-bindings: lcdif: Add support for specifying display with timings
On Mon, Sep 23, 2024 at 07:53:57PM +0200, Marek Vasut wrote: > On 9/23/24 3:57 PM, Lukasz Majewski wrote: > > Up till now the fsl,lcdif.yaml was requiring the "port" property as a > > must have to specify the display interface on iMX devices. > > > > However, it shall also be possible to specify the display only with > > passing its timing parameters (h* and v* ones) via "display" property: > > (as in > > Documentation/devicetree/bindings/display/panel/display-timings.yaml). > > Timings should go into panel node, not into scanout engine node. > > See e.g. panel-timings in arch/arm64/boot/dts/freescale/imx8mm-phg.dts , in > your case the compatible might be "panel-dpi" . I agree, but if this is already in use, we should allow it. We can mark it deprecated though. Rob
Re: [RFC PATCH 0/4] Linaro restricted heap
Hi Jens, On Fri, 30 Aug 2024 at 08:04, Jens Wiklander wrote: > This patch set is based on top of Yong Wu's restricted heap patch set [1]. > It's also a continuation on Olivier's Add dma-buf secure-heap patch set [2]. > > The Linaro restricted heap uses genalloc in the kernel to manage the heap > carvout. This is a difference from the Mediatek restricted heap which > relies on the secure world to manage the carveout. Calling this the 'genalloc heap' would be much more clear. Cheers, Daniel
Re: [RFC PATCH 0/4] Linaro restricted heap
On 9/23/24 1:33 AM, Dmitry Baryshkov wrote: Hi, On Fri, Aug 30, 2024 at 09:03:47AM GMT, Jens Wiklander wrote: Hi, This patch set is based on top of Yong Wu's restricted heap patch set [1]. It's also a continuation on Olivier's Add dma-buf secure-heap patch set [2]. The Linaro restricted heap uses genalloc in the kernel to manage the heap carvout. This is a difference from the Mediatek restricted heap which relies on the secure world to manage the carveout. I've tried to adress the comments on [2], but [1] introduces changes so I'm afraid I've had to skip some comments. I know I have raised the same question during LPC (in connection to Qualcomm's dma-heap implementation). Is there any reason why we are using generic heaps instead of allocating the dma-bufs on the device side? In your case you already have TEE device, you can use it to allocate and export dma-bufs, which then get imported by the V4L and DRM drivers. This goes to the heart of why we have dma-heaps in the first place. We don't want to burden userspace with having to figure out the right place to get a dma-buf for a given use-case on a given hardware. That would be very non-portable, and fail at the core purpose of a kernel: to abstract hardware specifics away. Worse, the actual interface for dma-buf exporting changes from framework to framework (getting a dma-buf from DRM is different than V4L, and there would be yet another API for TEE, etc..) Most subsystem don't need an allocator, they work just fine simply being only dma-bufs importers. Recent example being the IIO subsystem[0], for which some early posting included an allocator, but in the end, all that was needed was to consume buffers. For devices that don't actually contain memory there is no reason to be an exporter. What most want is just to consume normal system memory. Or system memory with some constraints (e.g. contiguous, coherent, restricted, etc..). I have a feeling (I might be completely wrong here) that by using generic dma-buf heaps we can easily end up in a situation when the userspace depends heavily on the actual platform being used (to map the platform to heap names). I think we should instead depend on the existing devices (e.g. if there is a TEE device, use an IOCTL to allocate secured DMA BUF from it, otherwise check for QTEE device, otherwise check for some other vendor device). The mental experiment to check if the API is correct is really simple: Can you use exactly the same rootfs on several devices without any additional tuning (e.g. your QEMU, HiKey, a Mediatek board, Qualcomm laptop, etc)? This is a great north star to follow. And exactly the reason we should *not* be exposing device specific constraints to userspace. The constrains change based on the platform. So a userspace would have to also pick a different set of constraints based on each platform. Userspace knows which subsystems it will attach a buffer, and the kernel knows what constraints those devices have on a given platform. Ideal case is then allocate from the one exporter, attach to various devices, and have the constraints solved at map time by the exporter based on the set of attached devices. For example, on one platform the display needs contiguous buffers, but on a different platform the display can scatter-gather. So what heap should our generic application allocate from when it wants a buffer consumable by the display, CMA or System? Answer *should* be always use the generic exporter, and that exporter then picks the right backing type based on the platform. Userspace shouldn't be dealing with any of these constraints (looking back, adding the CMA heap was probably incorrect, and the System heap should have been the only one. Idea back then was a userspace helper would show up to do the constraint solving and pick the right heap. That has yet to materialize and folks are still just hardcoding which heap to use..). Same for this restricted heap, I'd like to explore if we can enhance the System heap such that when attached to the TEE framework, the backing memory is either made restricted by fire-walling, or allocating from a TEE carveout (based on platform). This will mean more inter-subsystem coordination, but we can iterate on these in kernel interfaces. We cannot iterate on userspace interfaces, those have to be correct the first time. Andrew [0] https://www.kernel.org/doc/html/next/iio/iio_dmabuf_api.html This can be tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v1 repo sync -j8 cd build make toolchains -j4 make all -j$(nproc) make run-only # login and at the prompt: xtest --sdp-basic https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. - Can we test that the system doe
Re: [PATCH v2] drm/panel: elida-kd35t133: transition to mipi_dsi wrapped functions
Hi,
On Mon, Sep 23, 2024 at 5:33 AM Tejas Vipin wrote:
>
> -static int kd35t133_init_sequence(struct kd35t133 *ctx)
> +static void kd35t133_init_sequence(struct mipi_dsi_multi_context *dsi_ctx)
> {
> - struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> - struct device *dev = ctx->dev;
> -
> /*
> * Init sequence was supplied by the panel vendor with minimal
> * documentation.
> */
> - mipi_dsi_dcs_write_seq(dsi, KD35T133_CMD_POSITIVEGAMMA,
> - 0x00, 0x13, 0x18, 0x04, 0x0f, 0x06, 0x3a, 0x56,
> - 0x4d, 0x03, 0x0a, 0x06, 0x30, 0x3e, 0x0f);
> - mipi_dsi_dcs_write_seq(dsi, KD35T133_CMD_NEGATIVEGAMMA,
> - 0x00, 0x13, 0x18, 0x01, 0x11, 0x06, 0x38, 0x34,
> - 0x4d, 0x06, 0x0d, 0x0b, 0x31, 0x37, 0x0f);
> - mipi_dsi_dcs_write_seq(dsi, KD35T133_CMD_POWERCONTROL1, 0x18, 0x17);
> - mipi_dsi_dcs_write_seq(dsi, KD35T133_CMD_POWERCONTROL2, 0x41);
> - mipi_dsi_dcs_write_seq(dsi, KD35T133_CMD_VCOMCONTROL, 0x00, 0x1a,
> 0x80);
> - mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_SET_ADDRESS_MODE, 0x48);
> - mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
> - mipi_dsi_dcs_write_seq(dsi, KD35T133_CMD_INTERFACEMODECTRL, 0x00);
> - mipi_dsi_dcs_write_seq(dsi, KD35T133_CMD_FRAMERATECTRL, 0xa0);
> - mipi_dsi_dcs_write_seq(dsi, KD35T133_CMD_DISPLAYINVERSIONCTRL, 0x02);
> - mipi_dsi_dcs_write_seq(dsi, KD35T133_CMD_DISPLAYFUNCTIONCTRL,
> - 0x20, 0x02);
> - mipi_dsi_dcs_write_seq(dsi, KD35T133_CMD_SETIMAGEFUNCTION, 0x00);
> - mipi_dsi_dcs_write_seq(dsi, KD35T133_CMD_ADJUSTCONTROL3,
> - 0xa9, 0x51, 0x2c, 0x82);
> - mipi_dsi_dcs_write(dsi, MIPI_DCS_ENTER_INVERT_MODE, NULL, 0);
> -
> - dev_dbg(dev, "Panel init sequence done\n");
> - return 0;
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, KD35T133_CMD_POSITIVEGAMMA,
> +0x00, 0x13, 0x18, 0x04, 0x0f, 0x06,
> 0x3a, 0x56,
> +0x4d, 0x03, 0x0a, 0x06, 0x30, 0x3e,
> 0x0f);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, KD35T133_CMD_NEGATIVEGAMMA,
> +0x13, 0x18, 0x01, 0x11, 0x06, 0x38, 0x34,
> +0x06, 0x0d, 0x0b, 0x31, 0x37, 0x0f);
It seems like you dropped a few bytes in the above. Was this
intentional? You seem to have dropped the first byte from both of the
continuation lines (0x00 from the first, 0x4d from the second).
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, KD35T133_CMD_POWERCONTROL1,
> 0x18, 0x17);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, KD35T133_CMD_POWERCONTROL2,
> 0x41);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, KD35T133_CMD_VCOMCONTROL, 0x00,
> 0x1a, 0x80);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, MIPI_DCS_SET_ADDRESS_MODE,
> 0x48);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, MIPI_DCS_SET_PIXEL_FORMAT,
> 0x55);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, KD35T133_CMD_INTERFACEMODECTRL,
> 0x00);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, KD35T133_CMD_FRAMERATECTRL,
> 0xa0);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx,
> KD35T133_CMD_DISPLAYINVERSIONCTRL, 0x02);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx,
> KD35T133_CMD_DISPLAYFUNCTIONCTRL,
> +0x02);
This used to be the bytes 0x20, 0x02. Now it's just 0x02?
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, KD35T133_CMD_SETIMAGEFUNCTION,
> 0x00);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, KD35T133_CMD_ADJUSTCONTROL3,
> +0x51, 0x2c, 0x82);
This used to be the bytes 0xa9, 0x51, 0x2c, 0x82. Now it's just 0x51,
0x2c, 0x82?
> + mipi_dsi_dcs_write_buffer_multi(dsi_ctx, NULL, 0);
Are you certain that the above is equivalent to the old
"mipi_dsi_dcs_write(dsi, MIPI_DCS_ENTER_INVERT_MODE, NULL, 0);" ?
Where is the "MIPI_DCS_ENTER_INVERT_MODE" constant?
I think the above needs to be:
mipi_dsi_dcs_write_seq_multi(dsi_ctx, MIPI_DCS_ENTER_INVERT_MODE);
I've confirmed that this compiles OK and that there's no need to
actually have any bytes in the sequence.
-Doug
Re: [RFC PATCH 00/28] Introduce GPU SVM and Xe SVM implementation
as I want to keep this as simple as possible and also don't want to throw more code at the list until a working baseline is in. > Short term enough (driver-side) locking to make sure this doesn't go > boom is enough, I think just some design goal documentation here on how > to achieve that is all we need. > > 4. physical memory to virtual backpointer > > No. Doesn't work :-) Also it's only used in in the eviction/migrate_to_ram > path and I think Matt already fixed this all anyway. > > 5. gpu pagetable locking > > Or mmu notifier range locking or whatever you want to call it. Like on the > cpu side this should _only_ protect the pagetable entries and additional > for us mmu notifier seqno tracking, nothing else. > > Any races due to concurrent eviction/migrate_to_ram/gpu fault/prefault > need to be handled by retrying outside of holding the pagetable locks. If > we try to impose additional consistency guarantees we'll fall over and > have a livelock/deadlock fight with core mm in migrate_to_ram. This part > is required I think for the first version, but we already need that anyway > to make migrate_to_ram work properly. > > For the actual data structure/locking design I think anything on the > design line between a single global lock and the radix tree over-the-top > scalable per-pagetable (spin)lock design of the core mm is fine. > I've seen the bind step in servicing GPU faults take barely any amount of time so having the GPU page tables protected by the VM's dma-resv lock seems fine in Xe. This really is up to each driver how it wants to handle this too. > The design here with 3 levels (mmu notifer, range, struct page) wouldn't > be my first choice, but clearly fits on that line so imo is fine for > initial merging. We might want to make sure that the range locking (I > guess mostly relevant for the invalidate side, drivers don't see much > else) is somewhat abstracted so we can easily change that post-merge, but > not required imo at all. > > For consensus documentation I'd recommend a todo or design documentation > patch, where we put down both the current design and why it's like that, > and some of the longer term goals. Then get that acked (imo needs at least > one other driver that's seriously interested in this, plus I think an ack > from Danilo for gpuvm interactions), then merge that. SVM is tricky enough > that I think this would be really useful to make sure we're not > unecessarily stuck in limbo. > I'll include a TODO or design documentation in the next rev. > From my side again I think the only part we really have to get right from > the start is migrate_to_ram. And I'm confident we've got that now really > solid. > I think most of all 5 points will be addressed in my next rev. Anything that isn't falls into an 'optimization we can do later' category which the design should be coded in a way these optimizations can easily be added. Matt > Oh also you need userspace ofc :-) > > Cheers, Sima > > > Matthew Brost (28): > > dma-buf: Split out dma fence array create into alloc and arm functions > > drm/xe: Invalidate media_gt TLBs in PT code > > drm/xe: Retry BO allocation > > mm/migrate: Add migrate_device_vma_range > > drm/gpusvm: Add support for GPU Shared Virtual Memory > > drm/xe/uapi: Add DRM_XE_VM_BIND_FLAG_SYSTEM_ALLOCATON flag > > drm/xe: Add SVM init / fini to faulting VMs > > drm/xe: Add dma_addr res cursor > > drm/xe: Add SVM range invalidation > > drm/gpuvm: Add DRM_GPUVA_OP_USER > > drm/xe: Add (re)bind to SVM page fault handler > > drm/xe: Add SVM garbage collector > > drm/xe: Add unbind to SVM garbage collector > > drm/xe: Do not allow system allocator VMA unbind if the GPU has > > bindings > > drm/xe: Enable system allocator uAPI > > drm/xe: Add migrate layer functions for SVM support > > drm/xe: Add SVM device memory mirroring > > drm/xe: Add GPUSVM copy SRAM / VRAM vfunc functions > > drm/xe: Update PT layer to understand ranges in VRAM > > drm/xe: Add Xe SVM populate_vram_pfn vfunc > > drm/xe: Add Xe SVM vram_release vfunc > > drm/xe: Add BO flags required for SVM > > drm/xe: Add SVM VRAM migration > > drm/xe: Basic SVM BO eviction > > drm/xe: Add SVM debug > > drm/xe: Add modparam for SVM notifier size > > drm/xe: Add modparam for SVM prefault > > drm/gpusvm: Ensure all pages migrated upon eviction > > > > drivers/dma-buf/dma-fence-array.c| 78 +- > > drivers/gpu/drm/xe/Makefile |4 +- > > drivers/gpu/drm/xe/drm_gpusvm.c | 2213
Re: radeon ARUBA NULL pointer dereference
I think we are seeing a similar problem w/qla2xxx panicing at boot: commit 1868f9d0260e9afaf7c6436d14923ae12eaea465 (HEAD -> master, origin/master, origin/HEAD) Merge: 056f8c437dc3 96319dacaf15 Author: Linus Torvalds Date: Fri Sep 20 19:34:00 2024 -0700 Merge tag 'for-linux-6.12-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux [3.376687] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 10.02.09.300-k. [3.385285] qla2xxx [:c4:00.0]-011c: : MSI-X vector count: 16. [3.391502] qla2xxx [:c4:00.0]-001d: : Found an ISP2261 irq 121 iobase 0x3b0c542c. [3.400118] BUG: kernel NULL pointer dereference, address: 00a0 [3.407075] #PF: supervisor read access in kernel mode [3.412215] #PF: error_code(0x) - not-present page [3.417356] PGD 0 P4D 0 [3.419896] Oops: Oops: [#1] PREEMPT SMP NOPTI [3.424776] CPU: 0 UID: 0 PID: 413 Comm: kworker/0:2 Not tainted 6.11.0+ #1 [3.431731] Hardware name: Dell Inc. PowerEdge R6515/04F3CJ, BIOS 2.13.3 09/12/2023 [3.439386] Workqueue: events work_for_cpu_fn [3.443744] RIP: 0010:dma_get_required_mask+0x11/0x50 [3.448796] Code: 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 8b 87 38 02 00 00 48 85 c0 74 12 <48> 8b 80 a0 00 00 00 48 85 c0 74 20 e9 fe f1 b7 00 cc 48 8b 05 9e [3.467542] RSP: 0018:b05741007d80 EFLAGS: 00010202 [3.472769] RAX: RBX: 0055 RCX: 9f8601f92088 [3.479901] RDX: b05740e07000 RSI: RDI: 9f8601f920c8 [3.487032] RBP: 9f861b3ec000 R08: R09: b05741007b10 [3.494165] R10: b05741007b08 R11: 831e15c8 R12: 9f8601f92000 [3.501299] R13: 9f861b3ec4a8 R14: 1000 R15: 2000 [3.508432] FS: () GS:9f896f20() knlGS: [3.516517] CS: 0010 DS: ES: CR0: 80050033 [3.522261] CR2: 00a0 CR3: 00011d93 CR4: 00350ef0 [3.529394] Call Trace: [3.531848] [3.533954] ? __die+0x20/0x70 [3.537012] ? page_fault_oops+0x75/0x170 [3.541028] ? exc_page_fault+0x64/0x140 [3.544951] ? asm_exc_page_fault+0x22/0x30 [3.549141] ? dma_get_required_mask+0x11/0x50 [3.553584] qla2x00_probe_one+0x12a1/0x1cb0 [qla2xxx] [3.558758] ? srso_return_thunk+0x5/0x5f [3.562770] ? __update_idle_core+0x5b/0xb0 [3.566958] local_pci_probe+0x46/0xa0 [3.570711] work_for_cpu_fn+0x16/0x20 [3.574459] process_one_work+0x17c/0x390 [3.578474] worker_thread+0x239/0x340 [3.582227] ? __pfx_worker_thread+0x10/0x10 [3.586497] kthread+0xcf/0x100 [3.589643] ? __pfx_kthread+0x10/0x10 [3.593398] ret_from_fork+0x30/0x50 [3.596975] ? __pfx_kthread+0x10/0x10 [3.600728] ret_from_fork_asm+0x1a/0x30 [3.604660] [3.606846] Modules linked in: qla2xxx(+) sd_mod sg nvme_fc nvme_fabrics ahci(+) nvme_keyring libahci crct10dif_pclmul crc32_pclmul ccp nvme_core crc32c_intel libata nvme_auth ghash_clmulni_intel megaraid_sas tg3 scsi_transport_fc sp5100_tco wmi dm_mirror dm_region_hash dm_log dm_mod [3.631945] CR2: 00a0 [3.635265] ---[ end trace ]--- [3.728765] RIP: 0010:dma_get_required_mask+0x11/0x50 [3.733828] Code: 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 8b 87 38 02 00 00 48 85 c0 74 12 <48> 8b 80 a0 00 00 00 48 85 c0 74 20 e9 fe f1 b7 00 cc 48 8b 05 9e [3.752572] RSP: 0018:b05741007d80 EFLAGS: 00010202 [3.757798] RAX: RBX: 0055 RCX: 9f8601f92088 [3.764930] RDX: b05740e07000 RSI: RDI: 9f8601f920c8 [3.772062] RBP: 9f861b3ec000 R08: R09: b05741007b10 [3.779197] R10: b05741007b08 R11: 831e15c8 R12: 9f8601f92000 [3.786328] R13: 9f861b3ec4a8 R14: 1000 R15: 2000 [3.793460] FS: () GS:9f896f20() knlGS: [3.801548] CS: 0010 DS: ES: CR0: 80050033 [3.807292] CR2: 00a0 CR3: 00011d93 CR4: 00350ef0 [3.814425] Kernel panic - not syncing: Fatal exception [3.821267] Kernel Offset: 0x60 from 0x8100 (relocation range: 0x8000-0xbfff) [3.890453] pstore: backend (erst) writing error (-28) [3.895598] ---[ end Kernel panic - not syncing: Fatal exception ]--- On Tue, Sep 24, 2024 at 10:23 AM Alex Deucher wrote: > > On Tue, Sep 24, 2024 at 8:43 AM Thomas Zimmermann wrote: > > > > > > > > Am 24.09.24 um 14:20 schrieb Thomas Zimmermann: > > > (cc: DMA and x86 folks) > > > > > > Hi > > > > > > Am 24.09.24 um 04:08 schrieb Arthur Marsh: > > >> Using current Linus git head kernel, I was able to save the dmesg > > >> output: > > >> > > >> [ 17.218724]
Re: [PATCH 1/1] mm/migrate: Trylock device page in do_swap_page
On 2024-09-24 12:42, Matthew Brost wrote:
> On Tue, Sep 24, 2024 at 01:48:29PM +0200, Simona Vetter wrote:
>> On Fri, Sep 20, 2024 at 09:59:51PM +, Matthew Brost wrote:
>>> On Fri, Sep 20, 2024 at 05:50:10PM -0400, Felix Kuehling wrote:
On 2024-09-20 17:23, Matthew Brost wrote:
> On Fri, Sep 20, 2024 at 04:26:50PM -0400, Felix Kuehling wrote:
>> On 2024-09-18 11:10, Alistair Popple wrote:
>>> Matthew Brost writes:
>>>
On Wed, Sep 11, 2024 at 02:53:31PM +1000, Alistair Popple wrote:
> Matthew Brost writes:
>
> I haven't seen the same in the NVIDIA UVM driver (out-of-tree, I know)
Still a driver.
>>> Indeed, and I'm happy to answer any questions about our implementation.
>>>
> but theoretically it seems like it should be possible. However we
> serialize migrations of the same virtual address range to avoid these
> kind of issues as they can happen the other way too (ie. multiple
> threads trying to migrate to GPU).
>
> So I suspect what happens in UVM is that one thread wins and installs
> the migration entry while the others fail to get the driver migration
> lock and bail out sufficiently early in the fault path to avoid the
> live-lock.
>
I had to try hard to show this, doubt an actual user could trigger
this.
I wrote a test which kicked 8 threads, each thread did a pthread join,
and then tried to read the same page. This repeats in loop for like 512
pages or something. I needed an exclusive lock in migrate_to_ram vfunc
for it to livelock. Without an exclusive lock I think on average I saw
about 32k retries (i.e. migrate_to_ram calls on the same page) before a
thread won this race.
From reading UVM, pretty sure if you tried hard enough you could
trigger
a livelock given it appears you take excluvise locks in migrate_to_ram.
>>> Yes, I suspect you're correct here and that we just haven't tried hard
>>> enough to trigger it.
>>>
>> Cc: Philip Yang
>> Cc: Felix Kuehling
>> Cc: Christian König
>> Cc: Andrew Morton
>> Suggessted-by: Simona Vetter
>> Signed-off-by: Matthew Brost
>> ---
>>mm/memory.c | 13 +++---
>>mm/migrate_device.c | 60
>> +++--
>>2 files changed, 50 insertions(+), 23 deletions(-)
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 3c01d68065be..bbd97d16a96a 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -4046,10 +4046,15 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>> * Get a page reference while we know the page
>> can't be
>> * freed.
>> */
>> -get_page(vmf->page);
>> -pte_unmap_unlock(vmf->pte, vmf->ptl);
>> -ret =
>> vmf->page->pgmap->ops->migrate_to_ram(vmf);
>> -put_page(vmf->page);
>> +if (trylock_page(vmf->page)) {
>> +get_page(vmf->page);
>> +pte_unmap_unlock(vmf->pte, vmf->ptl);
> This is all beginning to look a lot like migrate_vma_collect_pmd(). So
> rather than do this and then have to pass all this context
> (ie. fault_page) down to the migrate_vma_* functions could we instead
> just do what migrate_vma_collect_pmd() does here? Ie. we already have
> the PTL and the page lock so there's no reason we couldn't just setup
> the migration entry prior to calling migrate_to_ram().
>
> Obviously calling migrate_vma_setup() would show the page as not
> migrating, but drivers could easily just fill in the src_pfn info
> after
> calling migrate_vma_setup().
>
> This would eliminate the whole fault_page ugliness.
>
This seems like it would work and agree it likely be cleaner. Let me
play around with this and see what I come up with. Multi-tasking a bit
so expect a bit of delay here.
Thanks for the input,
Matt
>> Thanks! Sorry, I'm late catching up after a vacation. Please keep Philip,
>> Christian and myself in the loop with future patches in this area.
>>
> Will do. Already have another local patch set which helps drivers dma
> map 2M pages for migrations if SRAM is physically contiguous. Seems
> helpful for performance on Intel hardware. Probably post that soon for
> early feedack.
OK.
>
> Longer term I thinking 2M migration entries, 2M device page
Re: [PATCH] drm: xlnx: zynqmp_dpsub: also call drm_helper_hpd_irq_event
Hi Steffen,
Thank you for the patch.
On Mon, Sep 23, 2024 at 09:48:03AM +0200, li...@steffen.cc wrote:
> From: Steffen Dirkwinkel
>
> With hpd going through the bridge as of commit eb2d64bfcc17
> ("drm: xlnx: zynqmp_dpsub: Report HPD through the bridge")
> we don't get hotplug events in userspace on zynqmp hardware.
> Also sending hotplug events with drm_helper_hpd_irq_event works.
Why does the driver need to call both drm_helper_hpd_irq_event() and
drm_bridge_hpd_notify() ? The latter should end up calling
drm_kms_helper_connector_hotplug_event(), which is the same function
that drm_helper_hpd_irq_event() calls.
> Fixes: eb2d64bfcc17 ("drm: xlnx: zynqmp_dpsub: Report HPD through the bridge")
> Signed-off-by: Steffen Dirkwinkel
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 1846c4971fd8..cb823540a412 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1614,6 +1615,9 @@ static void zynqmp_dp_hpd_work_func(struct work_struct
> *work)
> hpd_work.work);
> enum drm_connector_status status;
>
> + if (dp->bridge.dev)
> + drm_helper_hpd_irq_event(dp->bridge.dev);
> +
> status = zynqmp_dp_bridge_detect(&dp->bridge);
> drm_bridge_hpd_notify(&dp->bridge, status);
> }
--
Regards,
Laurent Pinchart
Re: [PATCH] gpu: host1x: Request syncpoint IRQs only during probe
On 24/09/2024 19:33, Jon Hunter wrote:
On 06/09/2024 09:38, Jon Hunter wrote:
Hi Mikko,
On 31/05/2024 08:07, Mikko Perttunen wrote:
From: Mikko Perttunen
Syncpoint IRQs are currently requested in a code path that runs
during resume. Due to this, we get multiple overlapping registered
interrupt handlers as host1x is suspended and resumed.
Rearrange interrupt code to only request IRQs during initialization.
Signed-off-by: Mikko Perttunen
...
This change is causing a boot regression on Tegra186 with the latest
-next. I have reverted this to confirm that this fixes the problem. I
don't see any crash log but the board appears to just hang.
I had a look at this and I was able to fix this by moving where
we initialise the interrupts to after the PM runtime enable ...
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index b62e4f0e8130..ff98d4903cac 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -625,12 +625,6 @@ static int host1x_probe(struct platform_device *pdev)
goto free_contexts;
}
- err = host1x_intr_init(host);
- if (err) {
- dev_err(&pdev->dev, "failed to initialize interrupts\n");
- goto deinit_syncpt;
- }
-
pm_runtime_enable(&pdev->dev);
err = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
@@ -642,6 +636,12 @@ static int host1x_probe(struct platform_device *pdev)
if (err)
goto pm_disable;
+ err = host1x_intr_init(host);
+ if (err) {
+ dev_err(&pdev->dev, "failed to initialize interrupts\n");
+ goto pm_put;
+ }
+
host1x_debug_init(host);
err = host1x_register(host);
@@ -658,14 +658,11 @@ static int host1x_probe(struct platform_device *pdev)
host1x_unregister(host);
deinit_debugfs:
host1x_debug_deinit(host);
-
+ host1x_intr_deinit(host);
+pm_put:
pm_runtime_put_sync_suspend(&pdev->dev);
pm_disable:
pm_runtime_disable(&pdev->dev);
-
- host1x_intr_deinit(host);
-deinit_syncpt:
- host1x_syncpt_deinit(host);
free_contexts:
host1x_memory_context_list_free(&host->context_list);
free_channels:
Thierry, do you want to me to send a fix for the above or do you
want to squash with the original (assuming that OK with Mikko)?
Or can we drop from -next and have Mikko send a V2?
Jon
--
nvpublic
Re: [PATCH] gpu: host1x: Request syncpoint IRQs only during probe
On 06/09/2024 09:38, Jon Hunter wrote:
Hi Mikko,
On 31/05/2024 08:07, Mikko Perttunen wrote:
From: Mikko Perttunen
Syncpoint IRQs are currently requested in a code path that runs
during resume. Due to this, we get multiple overlapping registered
interrupt handlers as host1x is suspended and resumed.
Rearrange interrupt code to only request IRQs during initialization.
Signed-off-by: Mikko Perttunen
...
This change is causing a boot regression on Tegra186 with the latest
-next. I have reverted this to confirm that this fixes the problem. I
don't see any crash log but the board appears to just hang.
I had a look at this and I was able to fix this by moving where
we initialise the interrupts to after the PM runtime enable ...
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index b62e4f0e8130..ff98d4903cac 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -625,12 +625,6 @@ static int host1x_probe(struct platform_device *pdev)
goto free_contexts;
}
- err = host1x_intr_init(host);
- if (err) {
- dev_err(&pdev->dev, "failed to initialize interrupts\n");
- goto deinit_syncpt;
- }
-
pm_runtime_enable(&pdev->dev);
err = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
@@ -642,6 +636,12 @@ static int host1x_probe(struct platform_device *pdev)
if (err)
goto pm_disable;
+ err = host1x_intr_init(host);
+ if (err) {
+ dev_err(&pdev->dev, "failed to initialize interrupts\n");
+ goto pm_put;
+ }
+
host1x_debug_init(host);
err = host1x_register(host);
@@ -658,14 +658,11 @@ static int host1x_probe(struct platform_device *pdev)
host1x_unregister(host);
deinit_debugfs:
host1x_debug_deinit(host);
-
+ host1x_intr_deinit(host);
+pm_put:
pm_runtime_put_sync_suspend(&pdev->dev);
pm_disable:
pm_runtime_disable(&pdev->dev);
-
- host1x_intr_deinit(host);
-deinit_syncpt:
- host1x_syncpt_deinit(host);
free_contexts:
host1x_memory_context_list_free(&host->context_list);
free_channels:
Thierry, do you want to me to send a fix for the above or do you
want to squash with the original (assuming that OK with Mikko)?
Jon
--
nvpublic
Re: [PATCH 0/5] AMDGPU deadcode
* Alex Deucher (alexdeuc...@gmail.com) wrote: > On Sun, Sep 22, 2024 at 9:43 PM wrote: > > > > From: "Dr. David Alan Gilbert" > > > > Hi, > > This is a bunch of deadcode removal in amdgpu; > > some of the functions are ones which were previously > > used but haven't been for a while, others are functions > > that were added a few years ago and haven't ever been used. > > > > There are some others that I've not removed, which have > > been added in the last few years but not been used, > > I was worried maybe there are patches in someones tree > > about to use them (e.g. amdgpu_lsdma_copy_mem, amdgpu_mes_reg_wait, > > amdgpu_ras_unbind_aca, amdgpu_seq64_alloc, and > > amdgpu_xcp_prepare_resume) - I'd be happy to take those as > > well. Hi Alex, Thanks for taking the series, and the reply. > There are patches in flight that make use of at least some of these. > For example, the seq64 functions are used by the user queues patches > which are being reviewed now. Feel free to send out patches though if > you are inclined. If someone has plans to use something, they can > bring that up in the patch review. OK, I've made myself a note and will swing back at some point. > > One other thing I wasn't sure of; I removed > > amdgpu_device_ip_is_idle > > which has been unused since about 2016, but does that make > > the 'is_idle' methods unused or is there something else that calls > > them? > > They've been used on and off in proposed patches over the years. Some > of the IP specific code may call the IP specific is idle functions > directly rather than using the callbacks. Do you think the 'is_idle' member itself should go? Dave > Alex > > > > > (Sent from this kernel booted on my RX550 GPU) > > > > Dave > > > > Dr. David Alan Gilbert (5): > > drm/amdgpu: Remove unused amdgpu_device_ip_is_idle > > drm/amdgpu: Remove unused amdgpu_atpx functions > > drm/amdgpu: Remove unused amdgpu_gmc_vram_cpu_pa > > drm/amdgpu: Remove unused amdgpu_gfx_bit_to_me_queue > > drm/amdgpu: Remove unused amdgpu_i2c functions > > > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 10 > > .../gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 12 - > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 24 -- > > drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 10 > > drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 -- > > drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 12 - > > drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 1 - > > drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 25 --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h | 4 --- > > 9 files changed, 100 deletions(-) > > > > -- > > 2.46.1 > > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [PATCH v17 3/8] dt-bindings: display: bridge: Add Cadence MHDP8501
On Tue, 24 Sep 2024 15:36:48 +0800, Sandor Yu wrote: > Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge. > > Signed-off-by: Sandor Yu > Reviewed-by: Krzysztof Kozlowski > --- > v16->v17: > - Add lane-mapping property > > v9->v16: > *No change > > .../display/bridge/cdns,mhdp8501.yaml | 109 ++ > 1 file changed, 109 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml: lane-mapping: missing type definition doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/b2e1d26f964a03163ec7a1ba6ac8d7c88d6cb111.1727159906.git.sandor...@nxp.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 2/2] drm/bridge: it6505: Drop EDID cache on bridge power off
Hi,
On Mon, Sep 23, 2024 at 8:53 PM Pin-yen Lin wrote:
>
> The bridge might miss the display change events when it's powered off.
> This happens when a user changes the external monitor when the system
> is suspended and the embedded controller doesn't not wake AP up.
>
> It's also observed that one DP-to-HDMI bridge doesn't work correctly
> when there is no EDID read after it is powered on.
>
> Drop the cache to force an EDID read after system resume to fix this.
>
> Fixes: 11feaef69d0c ("drm/bridge: it6505: Add caching for EDID")
> Signed-off-by: Pin-yen Lin
Ah, I guess this answers my question in the previous patch about
whether caching was important even for external displays since this
driver only supports external DP and the commit you mention in "Fixes"
says that caching was important.
So this looks reasonable. One thing I wonder is if you're totally
guaranteed to get a PM Runtime suspend whenever you get an unplug /
replug of a display. I tried to dig a little bit but I'm not super
familiar with this bridge and it looks complicated enough that I guess
I'll have to trust that it's fine. So...
Reviewed-by: Douglas Anderson
Re: [PATCH v4 00/11] Preemption support for A7XX
On 9/24/24 5:22 PM, Akhil P Oommen wrote: On Tue, Sep 24, 2024 at 07:47:12AM -0700, Rob Clark wrote: On Tue, Sep 24, 2024 at 4:54 AM Antonino Maniscalco wrote: On 9/20/24 7:09 PM, Akhil P Oommen wrote: On Wed, Sep 18, 2024 at 09:46:33AM +0200, Neil Armstrong wrote: Hi, On 17/09/2024 13:14, Antonino Maniscalco wrote: This series implements preemption for A7XX targets, which allows the GPU to switch to an higher priority ring when work is pushed to it, reducing latency for high priority submissions. This series enables L1 preemption with skip_save_restore which requires the following userspace patches to function: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30544 A flag is added to `msm_submitqueue_create` to only allow submissions from compatible userspace to be preempted, therefore maintaining compatibility. Preemption is currently only enabled by default on A750, it can be enabled on other targets through the `enable_preemption` module parameter. This is because more testing is required on other targets. For testing on other HW it is sufficient to set that parameter to a value of 1, then using the branch of mesa linked above, `TU_DEBUG=hiprio` allows to run any application as high priority therefore preempting submissions from other applications. The `msm_gpu_preemption_trigger` and `msm_gpu_preemption_irq` traces added in this series can be used to observe preemption's behavior as well as measuring preemption latency. Some commits from this series are based on a previous series to enable preemption on A6XX targets: https://lkml.kernel.org/1520489185-21828-1-git-send-email-smase...@codeaurora.org Signed-off-by: Antonino Maniscalco --- Changes in v4: - Added missing register in pwrup list - Removed and rearrange barriers - Renamed `skip_inline_wptr` to `restore_wptr` - Track ctx seqno per ring - Removed secure preempt context - NOP out postamble to disable it instantly - Only emit pwrup reglist once - Document bv_rptr_addr - Removed unused A6XX_PREEMPT_USER_RECORD_SIZE - Set name on preempt record buffer - Link to v3: https://lore.kernel.org/r/20240905-preemption-a750-t-v3-0-fd947699f...@gmail.com Changes in v3: - Added documentation about preemption - Use quirks to determine which target supports preemption - Add a module parameter to force disabling or enabling preemption - Clear postamble when profiling - Define A6XX_CP_CONTEXT_SWITCH_CNTL_LEVEL fields in a6xx.xml - Make preemption records MAP_PRIV - Removed user ctx record (NON_PRIV) and patch 2/9 as it's not needed anymore - Link to v2: https://lore.kernel.org/r/20240830-preemption-a750-t-v2-0-86aeead2c...@gmail.com Changes in v2: - Added preept_record_size for X185 in PATCH 3/7 - Added patches to reset perf counters - Dropped unused defines - Dropped unused variable (fixes warning) - Only enable preemption on a750 - Reject MSM_SUBMITQUEUE_ALLOW_PREEMPT for unsupported targets - Added Akhil's Reviewed-By tags to patches 1/9,2/9,3/9 - Added Neil's Tested-By tags - Added explanation for UAPI changes in commit message - Link to v1: https://lore.kernel.org/r/20240815-preemption-a750-t-v1-0-7bda26c34...@gmail.com --- Antonino Maniscalco (11): drm/msm: Fix bv_fence being used as bv_rptr drm/msm/A6XX: Track current_ctx_seqno per ring drm/msm: Add a `preempt_record_size` field drm/msm: Add CONTEXT_SWITCH_CNTL bitfields drm/msm/A6xx: Implement preemption for A7XX targets drm/msm/A6xx: Sync relevant adreno_pm4.xml changes drm/msm/A6xx: Use posamble to reset counters on preemption drm/msm/A6xx: Add traces for preemption drm/msm/A6XX: Add a flag to allow preemption to submitqueue_create drm/msm/A6xx: Enable preemption for A750 Documentation: document adreno preemption Documentation/gpu/msm-preemption.rst | 98 + drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +- drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 7 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 325 ++- drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 174 drivers/gpu/drm/msm/adreno/a6xx_preempt.c | 440 + drivers/gpu/drm/msm/adreno/adreno_gpu.h| 9 +- drivers/gpu/drm/msm/msm_drv.c | 4 + drivers/gpu/drm/msm/msm_gpu.c | 2 +- drivers/gpu/drm/msm/msm_gpu.h | 11 - drivers/gpu/drm/msm/msm_gpu_trace.h| 28 ++ drivers/gpu/drm/msm/msm_ringbuffer.h | 18 + drivers/gpu/drm/msm/msm_submitqueue.c | 3 + drivers/gpu/drm/msm/registers/adreno/a6xx.xml
Re: [PATCH v4 00/11] Preemption support for A7XX
On 9/24/24 4:47 PM, Rob Clark wrote: On Tue, Sep 24, 2024 at 4:54 AM Antonino Maniscalco wrote: On 9/20/24 7:09 PM, Akhil P Oommen wrote: On Wed, Sep 18, 2024 at 09:46:33AM +0200, Neil Armstrong wrote: Hi, On 17/09/2024 13:14, Antonino Maniscalco wrote: This series implements preemption for A7XX targets, which allows the GPU to switch to an higher priority ring when work is pushed to it, reducing latency for high priority submissions. This series enables L1 preemption with skip_save_restore which requires the following userspace patches to function: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30544 A flag is added to `msm_submitqueue_create` to only allow submissions from compatible userspace to be preempted, therefore maintaining compatibility. Preemption is currently only enabled by default on A750, it can be enabled on other targets through the `enable_preemption` module parameter. This is because more testing is required on other targets. For testing on other HW it is sufficient to set that parameter to a value of 1, then using the branch of mesa linked above, `TU_DEBUG=hiprio` allows to run any application as high priority therefore preempting submissions from other applications. The `msm_gpu_preemption_trigger` and `msm_gpu_preemption_irq` traces added in this series can be used to observe preemption's behavior as well as measuring preemption latency. Some commits from this series are based on a previous series to enable preemption on A6XX targets: https://lkml.kernel.org/1520489185-21828-1-git-send-email-smase...@codeaurora.org Signed-off-by: Antonino Maniscalco --- Changes in v4: - Added missing register in pwrup list - Removed and rearrange barriers - Renamed `skip_inline_wptr` to `restore_wptr` - Track ctx seqno per ring - Removed secure preempt context - NOP out postamble to disable it instantly - Only emit pwrup reglist once - Document bv_rptr_addr - Removed unused A6XX_PREEMPT_USER_RECORD_SIZE - Set name on preempt record buffer - Link to v3: https://lore.kernel.org/r/20240905-preemption-a750-t-v3-0-fd947699f...@gmail.com Changes in v3: - Added documentation about preemption - Use quirks to determine which target supports preemption - Add a module parameter to force disabling or enabling preemption - Clear postamble when profiling - Define A6XX_CP_CONTEXT_SWITCH_CNTL_LEVEL fields in a6xx.xml - Make preemption records MAP_PRIV - Removed user ctx record (NON_PRIV) and patch 2/9 as it's not needed anymore - Link to v2: https://lore.kernel.org/r/20240830-preemption-a750-t-v2-0-86aeead2c...@gmail.com Changes in v2: - Added preept_record_size for X185 in PATCH 3/7 - Added patches to reset perf counters - Dropped unused defines - Dropped unused variable (fixes warning) - Only enable preemption on a750 - Reject MSM_SUBMITQUEUE_ALLOW_PREEMPT for unsupported targets - Added Akhil's Reviewed-By tags to patches 1/9,2/9,3/9 - Added Neil's Tested-By tags - Added explanation for UAPI changes in commit message - Link to v1: https://lore.kernel.org/r/20240815-preemption-a750-t-v1-0-7bda26c34...@gmail.com --- Antonino Maniscalco (11): drm/msm: Fix bv_fence being used as bv_rptr drm/msm/A6XX: Track current_ctx_seqno per ring drm/msm: Add a `preempt_record_size` field drm/msm: Add CONTEXT_SWITCH_CNTL bitfields drm/msm/A6xx: Implement preemption for A7XX targets drm/msm/A6xx: Sync relevant adreno_pm4.xml changes drm/msm/A6xx: Use posamble to reset counters on preemption drm/msm/A6xx: Add traces for preemption drm/msm/A6XX: Add a flag to allow preemption to submitqueue_create drm/msm/A6xx: Enable preemption for A750 Documentation: document adreno preemption Documentation/gpu/msm-preemption.rst | 98 + drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +- drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 7 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 325 ++- drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 174 drivers/gpu/drm/msm/adreno/a6xx_preempt.c | 440 + drivers/gpu/drm/msm/adreno/adreno_gpu.h| 9 +- drivers/gpu/drm/msm/msm_drv.c | 4 + drivers/gpu/drm/msm/msm_gpu.c | 2 +- drivers/gpu/drm/msm/msm_gpu.h | 11 - drivers/gpu/drm/msm/msm_gpu_trace.h| 28 ++ drivers/gpu/drm/msm/msm_ringbuffer.h | 18 + drivers/gpu/drm/msm/msm_submitqueue.c | 3 + drivers/gpu/drm/msm/registers/adreno/a6xx.xml | 7 +- .../gpu/drm/msm/registers/adreno/adreno_pm4.xml
Re: [PATCH 0/2] drm: revert some framebuffer API tests
On 9/24/24 09:57, Maxime Ripard wrote: On Tue, Sep 24, 2024 at 06:56:26PM GMT, Jani Nikula wrote: On Tue, 24 Sep 2024, Guenter Roeck wrote: On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: Yeah I think long-term we might want a kunit framework so that we can catch dmesg warnings we expect and test for those, without those warnings actually going to dmesg. Similar to how the lockdep tests also reroute locking validation, so that the expected positive tests don't wreak lockdep for real. But until that exists, we can't have tests that splat in dmesg when they work as intended. FWIW, that is arguable. More and more tests are added which do add such splats, and I don't see any hesitance by developers to adding more. So far I counted two alone in this commit window, and that does not include new splats from tests which I had already disabled. I simply disable those tests or don't enable them in the first place if they are new. I did the same with the drm unit tests due to the splats generated by the scaling unit tests, so any additional drm unit test splats don't make a difference for me since the tests are already disabled. What's the point of having unit tests that CI systems routinely have to filter out of test runs? Or filter warnings generated by the tests, potentially missing new warnings. Who is going to run the tests if the existing CI systems choose to ignore them? If we turn this argument around, that means we can't write unit test for code that will create a warning. IMO, this creates a bad incentive, and saying that any capable CI system should reject them is certainly opiniated. Agreed. All I am saying is that _I_ am rejecting them, but it is up to each individual testbed (or, rather, testbed maintainer) to decide how to handle the situation. Guenter
Re: [PATCH 0/5] AMDGPU deadcode
On Sun, Sep 22, 2024 at 9:43 PM wrote: > > From: "Dr. David Alan Gilbert" > > Hi, > This is a bunch of deadcode removal in amdgpu; > some of the functions are ones which were previously > used but haven't been for a while, others are functions > that were added a few years ago and haven't ever been used. > > There are some others that I've not removed, which have > been added in the last few years but not been used, > I was worried maybe there are patches in someones tree > about to use them (e.g. amdgpu_lsdma_copy_mem, amdgpu_mes_reg_wait, > amdgpu_ras_unbind_aca, amdgpu_seq64_alloc, and > amdgpu_xcp_prepare_resume) - I'd be happy to take those as > well. There are patches in flight that make use of at least some of these. For example, the seq64 functions are used by the user queues patches which are being reviewed now. Feel free to send out patches though if you are inclined. If someone has plans to use something, they can bring that up in the patch review. > > One other thing I wasn't sure of; I removed > amdgpu_device_ip_is_idle > which has been unused since about 2016, but does that make > the 'is_idle' methods unused or is there something else that calls > them? They've been used on and off in proposed patches over the years. Some of the IP specific code may call the IP specific is idle functions directly rather than using the callbacks. Alex > > (Sent from this kernel booted on my RX550 GPU) > > Dave > > Dr. David Alan Gilbert (5): > drm/amdgpu: Remove unused amdgpu_device_ip_is_idle > drm/amdgpu: Remove unused amdgpu_atpx functions > drm/amdgpu: Remove unused amdgpu_gmc_vram_cpu_pa > drm/amdgpu: Remove unused amdgpu_gfx_bit_to_me_queue > drm/amdgpu: Remove unused amdgpu_i2c functions > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 10 > .../gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 12 - > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 24 -- > drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 10 > drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 -- > drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 12 - > drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 1 - > drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 25 --- > drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h | 4 --- > 9 files changed, 100 deletions(-) > > -- > 2.46.1 >
Re: [PATCH 5/5] drm/amdgpu: Remove unused amdgpu_i2c functions
Applied the series. Thanks!
Alex
On Sun, Sep 22, 2024 at 9:43 PM wrote:
>
> From: "Dr. David Alan Gilbert"
>
> amdgpu_i2c_add and amdgpu_i2c_init were added in 2015's commit
> d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> but never used.
>
> Remove them.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 25 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h | 4
> 2 files changed, 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> index 00d6211e0fbf..f0765ccde668 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> @@ -225,15 +225,6 @@ void amdgpu_i2c_destroy(struct amdgpu_i2c_chan *i2c)
> kfree(i2c);
> }
>
> -/* Add the default buses */
> -void amdgpu_i2c_init(struct amdgpu_device *adev)
> -{
> - if (amdgpu_hw_i2c)
> - DRM_INFO("hw_i2c forced on, you may experience display
> detection problems!\n");
> -
> - amdgpu_atombios_i2c_init(adev);
> -}
> -
> /* remove all the buses */
> void amdgpu_i2c_fini(struct amdgpu_device *adev)
> {
> @@ -247,22 +238,6 @@ void amdgpu_i2c_fini(struct amdgpu_device *adev)
> }
> }
>
> -/* Add additional buses */
> -void amdgpu_i2c_add(struct amdgpu_device *adev,
> - const struct amdgpu_i2c_bus_rec *rec,
> - const char *name)
> -{
> - struct drm_device *dev = adev_to_drm(adev);
> - int i;
> -
> - for (i = 0; i < AMDGPU_MAX_I2C_BUS; i++) {
> - if (!adev->i2c_bus[i]) {
> - adev->i2c_bus[i] = amdgpu_i2c_create(dev, rec, name);
> - return;
> - }
> - }
> -}
> -
> /* looks up bus based on id */
> struct amdgpu_i2c_chan *
> amdgpu_i2c_lookup(struct amdgpu_device *adev,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h
> index 63c2ff7499e1..21e3d1dad0a1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h
> @@ -28,11 +28,7 @@ struct amdgpu_i2c_chan *amdgpu_i2c_create(struct
> drm_device *dev,
> const struct amdgpu_i2c_bus_rec
> *rec,
> const char *name);
> void amdgpu_i2c_destroy(struct amdgpu_i2c_chan *i2c);
> -void amdgpu_i2c_init(struct amdgpu_device *adev);
> void amdgpu_i2c_fini(struct amdgpu_device *adev);
> -void amdgpu_i2c_add(struct amdgpu_device *adev,
> - const struct amdgpu_i2c_bus_rec *rec,
> - const char *name);
> struct amdgpu_i2c_chan *
> amdgpu_i2c_lookup(struct amdgpu_device *adev,
> const struct amdgpu_i2c_bus_rec *i2c_bus);
> --
> 2.46.1
>
Re: [PATCH v2] fbcon: Fix a NULL pointer dereference issue in fbcon_putcs
Hi Qianqiang,
On 9/24/24 18:13, Qianqiang Liu wrote:
syzbot has found a NULL pointer dereference bug in fbcon.
This issue is caused by ops->putcs being a NULL pointer.
We need to ensure it is initialized properly.
Reported-by: syzbot+3d613ae53c0315026...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3d613ae53c031502687a
Tested-by: syzbot+3d613ae53c0315026...@syzkaller.appspotmail.com
Signed-off-by: Qianqiang Liu
---
Changes since v1:
- Initialize ops->putcs by calling set_blitting_type()
Thanks a lot tracking this issue down!
At first sight your patch seems correct.
But could you please document in the patch description what exactly (and why)
something goes wrong and how your patch fixes it?
E.g. why was opt->putcs missed to be initialized even earlier and why does
it need initialization now?
You did a good work in producing a reduced testcase.
If it's quite small, it's a good idea to even include it in the
commit message?
Helge
---
drivers/video/fbdev/core/fbcon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2e093535884b..d9abae2516d8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -861,6 +861,8 @@ static int set_con2fb_map(int unit, int newidx, int user)
return err;
fbcon_add_cursor_work(info);
+ } else if (vc) {
+ set_blitting_type(vc, info);
}
con2fb_map[unit] = newidx;
Re: [PATCH 0/2] drm: revert some framebuffer API tests
On Tue, Sep 24, 2024 at 06:56:26PM GMT, Jani Nikula wrote: > On Tue, 24 Sep 2024, Guenter Roeck wrote: > On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: > > Yeah I think long-term we might want a kunit framework so that we can > > catch dmesg warnings we expect and test for those, without those > > warnings > > actually going to dmesg. Similar to how the lockdep tests also reroute > > locking validation, so that the expected positive tests don't wreak > > lockdep for real. > > > > But until that exists, we can't have tests that splat in dmesg when they > > work as intended. > > > > FWIW, that is arguable. More and more tests are added which do add such > > splats, > > and I don't see any hesitance by developers to adding more. So far I counted > > two alone in this commit window, and that does not include new splats from > > tests which I had already disabled. I simply disable those tests or don't > > enable them in the first place if they are new. I did the same with the drm > > unit tests due to the splats generated by the scaling unit tests, so any > > additional drm unit test splats don't make a difference for me since the > > tests are already disabled. > > What's the point of having unit tests that CI systems routinely have to > filter out of test runs? Or filter warnings generated by the tests, > potentially missing new warnings. Who is going to run the tests if the > existing CI systems choose to ignore them? If we turn this argument around, that means we can't write unit test for code that will create a warning. IMO, this creates a bad incentive, and saying that any capable CI system should reject them is certainly opiniated. Maxime signature.asc Description: PGP signature
Re: [PATCH v2 2/2] media: imx: vdic: Introduce mem2mem VDI deinterlacer driver
On 9/6/24 11:01 AM, Philipp Zabel wrote:
Hi,
diff --git a/drivers/staging/media/imx/imx-media-dev.c
b/drivers/staging/media/imx/imx-media-dev.c
index be54dca11465d..a841fdb4c2394 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -57,7 +57,52 @@ static int imx6_media_probe_complete(struct
v4l2_async_notifier *notifier)
goto unlock;
}
+ imxmd->m2m_vdic[0] = imx_media_mem2mem_vdic_init(imxmd, 0);
+ if (IS_ERR(imxmd->m2m_vdic[0])) {
+ ret = PTR_ERR(imxmd->m2m_vdic[0]);
+ imxmd->m2m_vdic[0] = NULL;
+ goto unlock;
+ }
+
+ /* MX6S/DL has one IPUv3, init second VDI only on MX6Q/QP */
+ if (imxmd->ipu[1]) {
+ imxmd->m2m_vdic[1] = imx_media_mem2mem_vdic_init(imxmd, 1);
+ if (IS_ERR(imxmd->m2m_vdic[1])) {
+ ret = PTR_ERR(imxmd->m2m_vdic[1]);
+ imxmd->m2m_vdic[1] = NULL;
+ goto uninit_vdi0;
+ }
+ }
Instead of presenting two devices to userspace, it would be better to
have a single video device that can distribute work to both IPUs.
Why do you think so ?
I think it is better to keep the kernel code as simple as possible, i.e.
provide the device node for each m2m device to userspace and handle the
m2m device hardware interaction in the kernel driver, but let userspace
take care of policy like job scheduling, access permissions assignment
to each device (e.g. if different user accounts should have access to
different VDICs), or other such topics.
To be fair, we never implemented that for the CSC/scaler mem2mem device
either.
I don't think that is actually a good idea. Instead, it would be better
to have two scaler nodes in userspace.
[...]
+++ b/drivers/staging/media/imx/imx-media-mem2mem-vdic.c
@@ -0,0 +1,997 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * i.MX VDIC mem2mem de-interlace driver
+ *
+ * Copyright (c) 2024 Marek Vasut
+ *
+ * Based on previous VDIC mem2mem work by Steve Longerbeam that is:
+ * Copyright (c) 2018 Mentor Graphics Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "imx-media.h"
+
+#define fh_to_ctx(__fh)container_of(__fh, struct ipu_mem2mem_vdic_ctx,
fh)
+
+#define to_mem2mem_priv(v) container_of(v, struct ipu_mem2mem_vdic_priv, vdev)
These could be inline functions for added type safety.
Fixed in v3
[...]
+static void ipu_mem2mem_vdic_device_run(void *_ctx)
+{
+ struct ipu_mem2mem_vdic_ctx *ctx = _ctx;
+ struct ipu_mem2mem_vdic_priv *priv = ctx->priv;
+ struct vb2_v4l2_buffer *curr_buf, *dst_buf;
+ dma_addr_t prev_phys, curr_phys, out_phys;
+ struct v4l2_pix_format *infmt;
+ u32 phys_offset = 0;
+ unsigned long flags;
+
+ infmt = ipu_mem2mem_vdic_get_format(priv, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+ if (V4L2_FIELD_IS_SEQUENTIAL(infmt->field))
+ phys_offset = infmt->sizeimage / 2;
+ else if (V4L2_FIELD_IS_INTERLACED(infmt->field))
+ phys_offset = infmt->bytesperline;
+ else
+ dev_err(priv->dev, "Invalid field %d\n", infmt->field);
+
+ dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
+ out_phys = vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0);
+
+ curr_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
+ if (!curr_buf) {
+ dev_err(priv->dev, "Not enough buffers\n");
+ return;
+ }
+
+ spin_lock_irqsave(&priv->irqlock, flags);
+
+ if (ctx->curr_buf) {
+ ctx->prev_buf = ctx->curr_buf;
+ ctx->curr_buf = curr_buf;
+ } else {
+ ctx->prev_buf = curr_buf;
+ ctx->curr_buf = curr_buf;
+ dev_warn(priv->dev, "Single-buffer mode, fix your userspace\n");
+ }
+
+ prev_phys = vb2_dma_contig_plane_dma_addr(&ctx->prev_buf->vb2_buf, 0);
+ curr_phys = vb2_dma_contig_plane_dma_addr(&ctx->curr_buf->vb2_buf, 0);
+
+ priv->curr_ctx = ctx;
+ spin_unlock_irqrestore(&priv->irqlock, flags);
+
+ ipu_cpmem_set_buffer(priv->vdi_out_ch, 0, out_phys);
+ ipu_cpmem_set_buffer(priv->vdi_in_ch_p, 0, prev_phys + phys_offset);
+ ipu_cpmem_set_buffer(priv->vdi_in_ch, 0, curr_phys);
+ ipu_cpmem_set_buffer(priv->vdi_in_ch_n, 0, curr_phys + phys_offset);
This always outputs at a frame rate of half the field rate, and only
top fields are ever used as current field, and bottom fields as
previous/next fields, right?
Yes, currently the driver extracts 1 frame from two consecutive incoming
fields (previous Bottom, and current Top and Bottom):
(frame 1 and 3 below is omitted)
1 2 3 4
...|T |T |T |T |...
...| B| B| B| B|...
| || | ||
'-'' '-''
||||
||\/
\/ Frame#4
Re: [PATCH v2 2/2] media: imx: vdic: Introduce mem2mem VDI deinterlacer driver
On 7/30/24 6:05 PM, Nicolas Dufresne wrote: Hi, sorry for the abysmal delay. Le mercredi 24 juillet 2024 à 02:19 +0200, Marek Vasut a écrit : Introduce dedicated memory-to-memory IPUv3 VDI deinterlacer driver. Currently the IPUv3 can operate VDI in DIRECT mode, from sensor to memory. This only works for single stream, that is, one input from one camera is deinterlaced on the fly with a helper buffer in DRAM and the result is written into memory. The i.MX6Q/QP does support up to four analog cameras via two IPUv3 instances, each containing one VDI deinterlacer block. In order to deinterlace all four streams from all four analog cameras live, it is necessary to operate VDI in INDIRECT mode, where the interlaced streams are written to buffers in memory, and then deinterlaced in memory using VDI in INDIRECT memory-to-memory mode. Just a quick design question. Is it possible to chain the deinterlacer and the csc-scaler ? I think you could do that. If so, it would be much more efficient if all this could be combined into the existing m2m driver, since you could save a memory rountrip when needing to deinterlace, change the colorspace and possibly scale too. The existing PRP/IC driver is similar to what this driver does, yes, but it uses a different DMA path , I believe it is IDMAC->PRP->IC->IDMAC . This driver uses IDMAC->VDI->IC->IDMAC . I am not convinced mixing the two paths into a single driver would be beneficial, but I am reasonably sure it would be very convoluted. Instead, this driver could be extended to do deinterlacing and scaling using the IC if that was needed. I think that would be the cleaner approach. Not that I only meant to ask if there was a path to combine CSC/Scaling/Deinterlacing without a memory rountrip. If a rountrip is needed anyway, I would rather make separate video nodes, and leave it to userspace to deal with. Though, if we can avoid it, a combined driver should be highly beneficial. The VDI mem2mem driver already uses the IC as an output path from the deinterlacer, IC is capable of scaling and it could be configured to do scaling. The IC configuration in the VDI mem2mem driver is some 10 lines of code (select input and output colorspace, and input and output image resolution), the rest of the VDI mem2mem driver is interaction with the VDI itself. Since the IC configuration (i.e. color space conversion and scaling) is already well factored out, I think mixing the VDI and CSC drivers wouldn't bring any real benefit, it would only make the code more complicated. [...]
Re: [PATCH 1/1] mm/migrate: Trylock device page in do_swap_page
On Tue, Sep 24, 2024 at 01:48:29PM +0200, Simona Vetter wrote:
> On Fri, Sep 20, 2024 at 09:59:51PM +, Matthew Brost wrote:
> > On Fri, Sep 20, 2024 at 05:50:10PM -0400, Felix Kuehling wrote:
> > >
> > > On 2024-09-20 17:23, Matthew Brost wrote:
> > > > On Fri, Sep 20, 2024 at 04:26:50PM -0400, Felix Kuehling wrote:
> > > > > On 2024-09-18 11:10, Alistair Popple wrote:
> > > > > > Matthew Brost writes:
> > > > > >
> > > > > > > On Wed, Sep 11, 2024 at 02:53:31PM +1000, Alistair Popple wrote:
> > > > > > > > Matthew Brost writes:
> > > > > > > >
> > > > > > > > I haven't seen the same in the NVIDIA UVM driver (out-of-tree,
> > > > > > > > I know)
> > > > > > > Still a driver.
> > > > > > Indeed, and I'm happy to answer any questions about our
> > > > > > implementation.
> > > > > >
> > > > > > > > but theoretically it seems like it should be possible. However
> > > > > > > > we
> > > > > > > > serialize migrations of the same virtual address range to avoid
> > > > > > > > these
> > > > > > > > kind of issues as they can happen the other way too (ie.
> > > > > > > > multiple
> > > > > > > > threads trying to migrate to GPU).
> > > > > > > >
> > > > > > > > So I suspect what happens in UVM is that one thread wins and
> > > > > > > > installs
> > > > > > > > the migration entry while the others fail to get the driver
> > > > > > > > migration
> > > > > > > > lock and bail out sufficiently early in the fault path to avoid
> > > > > > > > the
> > > > > > > > live-lock.
> > > > > > > >
> > > > > > > I had to try hard to show this, doubt an actual user could
> > > > > > > trigger this.
> > > > > > >
> > > > > > > I wrote a test which kicked 8 threads, each thread did a pthread
> > > > > > > join,
> > > > > > > and then tried to read the same page. This repeats in loop for
> > > > > > > like 512
> > > > > > > pages or something. I needed an exclusive lock in migrate_to_ram
> > > > > > > vfunc
> > > > > > > for it to livelock. Without an exclusive lock I think on average
> > > > > > > I saw
> > > > > > > about 32k retries (i.e. migrate_to_ram calls on the same page)
> > > > > > > before a
> > > > > > > thread won this race.
> > > > > > >
> > > > > > > From reading UVM, pretty sure if you tried hard enough you
> > > > > > > could trigger
> > > > > > > a livelock given it appears you take excluvise locks in
> > > > > > > migrate_to_ram.
> > > > > > Yes, I suspect you're correct here and that we just haven't tried
> > > > > > hard
> > > > > > enough to trigger it.
> > > > > >
> > > > > > > > > Cc: Philip Yang
> > > > > > > > > Cc: Felix Kuehling
> > > > > > > > > Cc: Christian König
> > > > > > > > > Cc: Andrew Morton
> > > > > > > > > Suggessted-by: Simona Vetter
> > > > > > > > > Signed-off-by: Matthew Brost
> > > > > > > > > ---
> > > > > > > > >mm/memory.c | 13 +++---
> > > > > > > > >mm/migrate_device.c | 60
> > > > > > > > > +++--
> > > > > > > > >2 files changed, 50 insertions(+), 23 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/mm/memory.c b/mm/memory.c
> > > > > > > > > index 3c01d68065be..bbd97d16a96a 100644
> > > > > > > > > --- a/mm/memory.c
> > > > > > > > > +++ b/mm/memory.c
> > > > > > > > > @@ -4046,10 +4046,15 @@ vm_fault_t do_swap_page(struct
> > > > > > > > > vm_fault *vmf)
> > > > > > > > >* Get a page reference while we know
> > > > > > > > > the page can't be
> > > > > > > > >* freed.
> > > > > > > > >*/
> > > > > > > > > - get_page(vmf->page);
> > > > > > > > > - pte_unmap_unlock(vmf->pte, vmf->ptl);
> > > > > > > > > - ret =
> > > > > > > > > vmf->page->pgmap->ops->migrate_to_ram(vmf);
> > > > > > > > > - put_page(vmf->page);
> > > > > > > > > + if (trylock_page(vmf->page)) {
> > > > > > > > > + get_page(vmf->page);
> > > > > > > > > + pte_unmap_unlock(vmf->pte,
> > > > > > > > > vmf->ptl);
> > > > > > > > This is all beginning to look a lot like
> > > > > > > > migrate_vma_collect_pmd(). So
> > > > > > > > rather than do this and then have to pass all this context
> > > > > > > > (ie. fault_page) down to the migrate_vma_* functions could we
> > > > > > > > instead
> > > > > > > > just do what migrate_vma_collect_pmd() does here? Ie. we
> > > > > > > > already have
> > > > > > > > the PTL and the page lock so there's no reason we couldn't just
> > > > > > > > setup
> > > > > > > > the migration entry prior to calling migrate_to_ram().
> > > > > > > >
> > > > > > > > Obviously calling migrate_vma_setup() would show the page as not
> > > > > > > > migrating, but drivers could easily just fill in the src_pfn
> > > > > > > > info after
> > > > > > > > calling migrate_vma_setup().
> > > > > > > >
> > > > > > > > This would eliminate the whole fau
Re: [PATCH 1/2] drm/bridge: anx7625: Drop EDID cache on bridge power off
Hi,
On Mon, Sep 23, 2024 at 8:53 PM Pin-yen Lin wrote:
>
> The bridge might miss the display change events when it's powered off.
> This happens when a user changes the external monitor when the system
> is suspended and the embedded controller doesn't not wake AP up.
>
> It's also observed that one DP-to-HDMI bridge doesn't work correctly
> when there is no EDID read after it is powered on.
>
> Drop the cache to force an EDID read after system resume to fix this.
>
> Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
> Signed-off-by: Pin-yen Lin
> ---
>
> drivers/gpu/drm/bridge/analogix/anx7625.c | 1 +
> 1 file changed, 1 insertion(+)
I'm not totally sure if it matters, but I wonder if you should change
this to only delete the EDID cache if you're in DP mode and not eDP
mode? For eDP mode the panel is not allowed to change and re-reading
it needlessly seems like it would slow down things like
suspend/resume. I think this would only matter if someone were using
eDP panels in the "old" way (not under the aux-bus) because we don't
set the "DRM_BRIDGE_OP_EDID" when we see "aux-bus", so maybe we don't
care that much but still...
Other than that, I know that there have been discussions in the past
about EDID caches but I can't quite remember all the details. I know
that panel-edp.c still caches it, so we must have concluded that it's
at least fine/reasonable for panels. I don't remember whether caching
is encouraged / suggested for external displays, though. Do you happen
to know if it even makes a difference there (in other words, do you
actually see multiple calls to read the EDID when you plug in a DP
display)?
-Doug
Re: [PATCH 0/2] drm: revert some framebuffer API tests
On 9/24/24 08:56, Jani Nikula wrote: On Tue, 24 Sep 2024, Guenter Roeck wrote: On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: Yeah I think long-term we might want a kunit framework so that we can catch dmesg warnings we expect and test for those, without those warnings actually going to dmesg. Similar to how the lockdep tests also reroute locking validation, so that the expected positive tests don't wreak lockdep for real. But until that exists, we can't have tests that splat in dmesg when they work as intended. FWIW, that is arguable. More and more tests are added which do add such splats, and I don't see any hesitance by developers to adding more. So far I counted two alone in this commit window, and that does not include new splats from tests which I had already disabled. I simply disable those tests or don't enable them in the first place if they are new. I did the same with the drm unit tests due to the splats generated by the scaling unit tests, so any additional drm unit test splats don't make a difference for me since the tests are already disabled. What's the point of having unit tests that CI systems routinely have to filter out of test runs? Or filter warnings generated by the tests, potentially missing new warnings. Who is going to run the tests if the existing CI systems choose to ignore them? Automation on a massive scale is key here, and making that harder is counter-productive. As I have said elsewhere, not being able to handle backtraces generated on purpose is a limitation of my testbed. Other testbeds with active (and paid) maintainers may not have that limitation. I deal with it by disabling affected tests. Others may deal with it by maintaining exception lists. Ultimately it is up to developers and testbed maintainers to decide the level of test coverage they are looking for or able to support. Thanks, Guenter
Re: [RFC PATCH 05/28] drm/gpusvm: Add support for GPU Shared Virtual Memory
On Tue, Sep 24, 2024 at 12:42:56PM +0200, Thomas Hellström wrote: > Hi, Matt, > > Some random review comments on this patch I came across while looking > at multi-device. > > Thanks, > Thomas > > > On Tue, 2024-08-27 at 19:48 -0700, Matthew Brost wrote: > > This patch introduces support for GPU Shared Virtual Memory (SVM) in > > the > > Direct Rendering Manager (DRM) subsystem. SVM allows for seamless > > sharing of memory between the CPU and GPU, enhancing performance and > > flexibility in GPU computing tasks. > > > > The patch adds the necessary infrastructure for SVM, including data > > structures and functions for managing SVM ranges and notifiers. It > > also > > provides mechanisms for allocating, deallocating, and migrating > > memory > > regions between system RAM and GPU VRAM. > > > > This mid-layer is largely inspired by GPUVM. > > NIT: Naming, Should it be drm_svm rather than drm_gpusvm? For the > drm_gpuvm component, gpuvm clearly distinguished a gpu_vm from a > mm_struct but here we don't have the same need. > Can rename. > > > > Cc: Dave Airlie > > Cc: Thomas Hellström > > Cc: Christian König > > Cc: > > Signed-off-by: Matthew Brost > > --- > > drivers/gpu/drm/xe/Makefile | 3 +- > > drivers/gpu/drm/xe/drm_gpusvm.c | 2174 > > +++ > > drivers/gpu/drm/xe/drm_gpusvm.h | 415 ++ > > 3 files changed, 2591 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/xe/drm_gpusvm.c > > create mode 100644 drivers/gpu/drm/xe/drm_gpusvm.h > > > > diff --git a/drivers/gpu/drm/xe/Makefile > > b/drivers/gpu/drm/xe/Makefile > > index b9670ae09a9e..b8fc2ee58f1a 100644 > > --- a/drivers/gpu/drm/xe/Makefile > > +++ b/drivers/gpu/drm/xe/Makefile > > @@ -25,7 +25,8 @@ $(obj)/generated/%_wa_oob.c > > $(obj)/generated/%_wa_oob.h: $(obj)/xe_gen_wa_oob \ > > > > # core driver code > > > > -xe-y += xe_bb.o \ > > +xe-y += drm_gpusvm.o \ > > + xe_bb.o \ > > xe_bo.o \ > > xe_bo_evict.o \ > > xe_devcoredump.o \ > > diff --git a/drivers/gpu/drm/xe/drm_gpusvm.c > > b/drivers/gpu/drm/xe/drm_gpusvm.c > > new file mode 100644 > > index ..fc1e44e6ae72 > > --- /dev/null > > +++ b/drivers/gpu/drm/xe/drm_gpusvm.c > > @@ -0,0 +1,2174 @@ > > +// SPDX-License-Identifier: MIT > > +/* > > + * Copyright © 2024 Intel Corporation > > + * > > + * Authors: > > + * Matthew Brost > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include "drm_gpusvm.h" > > + > > +/** > > + * DOC: Overview > > + * > > + * GPU Shared Virtual Memory (GPU SVM) layer for the Direct > > Rendering Manager (DRM) > > + * > > + * The GPU SVM layer is a component of the DRM framework designed to > > manage shared > > + * virtual memory between the CPU and GPU. It enables efficient data > > exchange and > > + * processing for GPU-accelerated applications by allowing memory > > sharing and > > + * synchronization between the CPU's and GPU's virtual address > > spaces. > > + * > > + * Key GPU SVM Components: > > + * - Notifiers: Notifiers: Used for tracking memory intervals and > > notifying the > > + * GPU of changes, notifiers are sized based on a GPU > > SVM > > + * initialization parameter, with a recommendation of > > 512M or > > + * larger. They maintain a Red-BlacK tree and a list of > > ranges that > > + * fall within the notifier interval. Notifiers are > > tracked within > > + * a GPU SVM Red-BlacK tree and list and are > > dynamically inserted > > + * or removed as ranges within the interval are created > > or > > + * destroyed. > > + * - Ranges: Represent memory ranges mapped in a DRM device and > > managed > > + * by GPU SVM. They are sized based on an array of chunk > > sizes, which > > + * is a GPU SVM initialization parameter, and the CPU > > address space. > > + * Upon GPU fault, the largest aligned chunk that fits > > within the > > + * faulting CPU address space is chosen for the range > > size. Ranges are > > + * expected to be dynamically allocated on GPU fault and > > removed on an > > + * MMU notifier UNMAP event. As mentioned above, ranges > > are tracked in > > + * a notifier's Red-Black tree. > > + * - Operations: Define the interface for driver-specific SVM > > operations such as > > + * allocation, page collection, migration, > > invalidations, and VRAM > > + * release. > > + * > > + * This layer provides interfaces for allocating, mapping, > > migrating, and > > + * releasing memory ranges between the CPU and GPU. It handles all > > core memory > > + * management interactions (DMA mapping, HMM, and migration) and > > provides > > + * driver-specific virtual functions (vfuncs). This infrastructure > > is sufficient > > + * to build the expected driver components for an SVM implementation > > as detailed > > + * below. > > +
Re: [PATCH v5 10/11] drm/msm/A6xx: Enable preemption for A750
nit, lowercase "a6xx" in subject prefix
(no need to resend just for this, I can fix it up when applying
patches if needed.. but if you do resend pls fix that)
BR
-R
On Tue, Sep 24, 2024 at 4:30 AM Antonino Maniscalco
wrote:
>
> Initialize with 4 rings to enable preemption.
>
> For now only on A750 as other targets require testing.
>
> Add the "preemption_enabled" module parameter to override this for other
> A7xx targets.
>
> Tested-by: Neil Armstrong # on SM8650-QRD
> Tested-by: Neil Armstrong # on SM8550-QRD
> Tested-by: Neil Armstrong # on SM8450-HDK
> Signed-off-by: Antonino Maniscalco
> ---
> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 3 ++-
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
> drivers/gpu/drm/msm/adreno/adreno_device.c | 4
> drivers/gpu/drm/msm/adreno/adreno_gpu.h| 1 +
> 4 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> index
> 316f23ca91671d973797f2a5b69344f376707325..0e3041b2941905f1acdc9e571e0549a960a7edfa
> 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> @@ -1240,7 +1240,8 @@ static const struct adreno_info a7xx_gpus[] = {
> .gmem = 3 * SZ_1M,
> .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> .quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT |
> - ADRENO_QUIRK_HAS_HW_APRIV,
> + ADRENO_QUIRK_HAS_HW_APRIV |
> + ADRENO_QUIRK_PREEMPTION,
> .init = a6xx_gpu_init,
> .zapfw = "gen70900_zap.mbn",
> .a6xx = &(const struct a6xx_info) {
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index
> edbcb6d229ba614be910ee70e75731538116e4a4..4760f9469613c0bf208f56be9608747b5aa75606
> 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -2529,6 +2529,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
> struct a6xx_gpu *a6xx_gpu;
> struct adreno_gpu *adreno_gpu;
> struct msm_gpu *gpu;
> + extern int enable_preemption;
> bool is_a7xx;
> int ret;
>
> @@ -2567,7 +2568,10 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
> return ERR_PTR(ret);
> }
>
> - if (is_a7xx)
> + if ((enable_preemption == 1) || (enable_preemption == -1 &&
> + (config->info->quirks & ADRENO_QUIRK_PREEMPTION)))
> + ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs_a7xx, 4);
> + else if (is_a7xx)
> ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs_a7xx, 1);
> else if (adreno_has_gmu_wrapper(adreno_gpu))
> ret = adreno_gpu_init(dev, pdev, adreno_gpu,
> &funcs_gmuwrapper, 1);
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index
> cfc74a9e2646d3de76a06bd67457d69afa49e309..9ffe91920fbfb4841b28aabec9fbde94539fdd83
> 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -20,6 +20,10 @@ bool allow_vram_carveout = false;
> MODULE_PARM_DESC(allow_vram_carveout, "Allow using VRAM Carveout, in place
> of IOMMU");
> module_param_named(allow_vram_carveout, allow_vram_carveout, bool, 0600);
>
> +int enable_preemption = -1;
> +MODULE_PARM_DESC(enable_preemption, "Enable preemption (A7xx only) (1=on ,
> 0=disable, -1=auto (default))");
> +module_param(enable_preemption, int, 0600);
> +
> extern const struct adreno_gpulist a2xx_gpulist;
> extern const struct adreno_gpulist a3xx_gpulist;
> extern const struct adreno_gpulist a4xx_gpulist;
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index
> 87098567483b69c21025b80f356e0a68f0e7f172..d1cd53f05de68b3873f35520655e09e82fc40449
> 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -56,6 +56,7 @@ enum adreno_family {
> #define ADRENO_QUIRK_LMLOADKILL_DISABLEBIT(2)
> #define ADRENO_QUIRK_HAS_HW_APRIV BIT(3)
> #define ADRENO_QUIRK_HAS_CACHED_COHERENT BIT(4)
> +#define ADRENO_QUIRK_PREEMPTIONBIT(5)
>
> /* Helper for formating the chip_id in the way that userspace tools like
> * crashdec expect.
>
> --
> 2.46.1
>
Re: [PATCH] drm/amd/display: fix typos in several function pointer checks
Applied. Thanks! On Sat, Sep 21, 2024 at 3:48 AM Vitaliy Shevtsov wrote: > > Fix several copypaste mistakes in *_disable_link_output() functions where > an improper function pointer is checked before dereference. > > Found by Linux Verification Center (linuxtesting.org) with Svace. > > Signed-off-by: Vitaliy Shevtsov > --- > drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c | 2 +- > drivers/gpu/drm/amd/display/dc/hwss/dcn314/dcn314_hwseq.c | 2 +- > drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c | 4 ++-- > 3 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c > b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c > index d52ce58c6a98..c2364cb66d0b 100644 > --- a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c > +++ b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c > @@ -3258,7 +3258,7 @@ void dce110_disable_link_output(struct dc_link *link, > * from enable/disable link output and only call edp panel control > * in enable_link_dp and disable_link_dp once. > */ > - if (dmcu != NULL && dmcu->funcs->lock_phy) > + if (dmcu != NULL && dmcu->funcs->unlock_phy) > dmcu->funcs->unlock_phy(dmcu); > dc->link_srv->dp_trace_source_sequence(link, > DPCD_SOURCE_SEQ_AFTER_DISABLE_LINK_PHY); > } > diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn314/dcn314_hwseq.c > b/drivers/gpu/drm/amd/display/dc/hwss/dcn314/dcn314_hwseq.c > index 4e93eeedfc1b..5b6cf2a8e38d 100644 > --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn314/dcn314_hwseq.c > +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn314/dcn314_hwseq.c > @@ -478,7 +478,7 @@ void dcn314_disable_link_output(struct dc_link *link, > * from enable/disable link output and only call edp panel control > * in enable_link_dp and disable_link_dp once. > */ > - if (dmcu != NULL && dmcu->funcs->lock_phy) > + if (dmcu != NULL && dmcu->funcs->unlock_phy) > dmcu->funcs->unlock_phy(dmcu); > dc->link_srv->dp_trace_source_sequence(link, > DPCD_SOURCE_SEQ_AFTER_DISABLE_LINK_PHY); > > diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c > b/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c > index a36e11606f90..84153682af1a 100644 > --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c > +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c > @@ -1384,10 +1384,10 @@ void dcn32_disable_link_output(struct dc_link *link, > link->phy_state.symclk_state = SYMCLK_OFF_TX_OFF; > > if (signal == SIGNAL_TYPE_EDP && > - link->dc->hwss.edp_backlight_control && > + link->dc->hwss.edp_power_control && > !link->skip_implict_edp_power_control) > link->dc->hwss.edp_power_control(link, false); > - else if (dmcu != NULL && dmcu->funcs->lock_phy) > + else if (dmcu != NULL && dmcu->funcs->unlock_phy) > dmcu->funcs->unlock_phy(dmcu); > > dc->link_srv->dp_trace_source_sequence(link, > DPCD_SOURCE_SEQ_AFTER_DISABLE_LINK_PHY); > -- > 2.46.1 >
Re: [PATCH v2 1/2] drm/panel: jd9365da: Modify Kingdisplay and Melfas panel timing
On 9/23/2024 7:13 PM, zhaoxiong lv wrote:
On Tue, Sep 24, 2024 at 5:14 AM Jessica Zhang wrote:
On 9/23/2024 6:42 AM, Zhaoxiong Lv wrote:
In MTK chips, if the system starts suspending before the DRM runtime
resume has not completed, there is a possibility of a black screen
after waking the machine. Reduce the disable delay resolves this issue,
Hi Zhaoxiong,
Do you mean "if the system starts suspending before the DRM runtime
resume *has* completed" here?
Hi Jessica
Sorry, my description may not be clear enough. It should be when the
DRM runtime resume has not yet completed and the system enters sleep
mode at the same time.
Got it, yes I think the reworded explanation in your reply is much clearer.
The "backlight_off_to_display_off_delay_ms" was added between
"backlight off" and "display off" to prevent "display off" from being
executed when the backlight is not fully powered off, which may cause
a white screen. However, we removed this
"backlight_off_to_display_off_delay_ms" and found that this situation
did not occur. Therefore, in order to solve the problem mentioned
above, we We reduced it from 100ms to 3ms (tCMD_OFF >= 1ms).
So from my understanding of this paragraph,
`backlight_off_to_display_off_delay_ms` was added to prevent the display
powering off before backlight is fully powered off. You recently tested
dropping this completely and saw no issue with this.
If that's the case, why not drop this delay completely?
Thanks,
Jessica Zhang
Yes, there are currently no other issue after removing this delay.
The reason why I didn't completely remove this delay is because the
panel spec states that a delay of more than 1ms (tCMD_OFF >= 1ms) is
required when entering diaplay_off (0x28H), so I reserved 3ms.
Thanks for the clarification -- I see why you included the "(tCMD_OFF >=
1ms)" part now. Can you please specify in the commit message that the
tCMD_OFF delay requirement is from the spec?
Also can you remove the extra "We" in "we We reduced it from 100ms to 3ms"?
Thanks,
Jessica Zhang
This is the timing specification for the two panels:
1. Kingdisplay panel timing spec:
https://github.com/KD54183/-JD9365DA_Power-On-Off-Sequence_V0120240923
2. LMFBX101117480 timing spec: https://github.com/chiohsin-lo/TDY-JD_LIB
Fixes: 2b976ad760dc ("drm/panel: jd9365da: Support for kd101ne3-40ti MIPI-DSI
panel")
Fixes: c4ce398cf18a ("drm/panel: jd9365da: Support for Melfas lmfbx101117480
MIPI-DSI panel")
Signed-off-by: Zhaoxiong Lv
---
Changes between V2 and V1:
- 1. Modify the commit message
- 2. Modify the value of backlight_off_to_display_off_delay_ms.
v1:
https://lore.kernel.org/all/20240915080830.11318-2-lvzhaoxi...@huaqin.corp-partner.google.com/
---
drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
index 44897e5218a6..486aa20e5518 100644
--- a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
+++ b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
@@ -858,7 +858,7 @@ static const struct jadard_panel_desc
kingdisplay_kd101ne3_40ti_desc = {
.reset_before_power_off_vcioo = true,
.vcioo_to_lp11_delay_ms = 5,
.lp11_to_reset_delay_ms = 10,
- .backlight_off_to_display_off_delay_ms = 100,
+ .backlight_off_to_display_off_delay_ms = 3,
.display_off_to_enter_sleep_delay_ms = 50,
.enter_sleep_to_reset_down_delay_ms = 100,
};
@@ -1109,7 +1109,7 @@ static const struct jadard_panel_desc
melfas_lmfbx101117480_desc = {
.reset_before_power_off_vcioo = true,
.vcioo_to_lp11_delay_ms = 5,
.lp11_to_reset_delay_ms = 10,
- .backlight_off_to_display_off_delay_ms = 100,
+ .backlight_off_to_display_off_delay_ms = 3,
.display_off_to_enter_sleep_delay_ms = 50,
.enter_sleep_to_reset_down_delay_ms = 100,
};
--
2.17.1
Re: [PATCH] drm/msm/a6xx+: Insert a fence wait before SMMU table update
On Wed, Sep 18, 2024 at 9:51 AM Connor Abbott wrote:
>
> On Fri, Sep 13, 2024 at 8:51 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > The CP_SMMU_TABLE_UPDATE _should_ be waiting for idle, but on some
> > devices (x1-85, possibly others), it seems to pass that barrier while
> > there are still things in the event completion FIFO waiting to be
> > written back to memory.
> >
> > Work around that by adding a fence wait before context switch. The
> > CP_EVENT_WRITE that writes the fence is the last write from a submit,
> > so seeing this value hit memory is a reliable indication that it is
> > safe to proceed with the context switch.
> >
> > Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/63
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 +++---
> > 1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > index bcaec86ac67a..ba5b35502e6d 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > @@ -101,9 +101,10 @@ static void get_stats_counter(struct msm_ringbuffer
> > *ring, u32 counter,
> > }
> >
> > static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
> > - struct msm_ringbuffer *ring, struct msm_file_private *ctx)
> > + struct msm_ringbuffer *ring, struct msm_gem_submit *submit)
> > {
> > bool sysprof = refcount_read(&a6xx_gpu->base.base.sysprof_active) >
> > 1;
> > + struct msm_file_private *ctx = submit->queue->ctx;
> > struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
> > phys_addr_t ttbr;
> > u32 asid;
> > @@ -115,6 +116,13 @@ static void a6xx_set_pagetable(struct a6xx_gpu
> > *a6xx_gpu,
> > if (msm_iommu_pagetable_params(ctx->aspace->mmu, &ttbr, &asid))
> > return;
> >
> > + /* Wait for previous submit to complete before continuing: */
> > + OUT_PKT7(ring, CP_WAIT_TIMESTAMP, 4);
>
> CP_WAIT_TIMESTAMP doesn't exist on a6xx, so this won't work there. I
> don't know if the bug exists on a6xx, but I'd be inclined to say it
> has always existed and we just never hit it because it requires some
> very specific timing conditions. We can make it work on a6xx by using
> CP_WAIT_REG_MEM and waiting for it to equal the exact value.
I've been unable to reproduce this on a690, despite running at a
similar fps (so similar rate of CP_SMMU_TABLE_UPDATEs). I guess I
can't rule out that this is just _harder_ to hit on a6xx due to the
shallower pipeline. It would be nice to get some data points on other
a7xx, but I only have the one.
I did attempt to come up with an igt stand-alone reproducer by just
ping-ponging between contexts (with fences to force context switches)
with 1000's of CP_EVENT_WRITE's, to no avail. I guess I'd need to
actually setup a blit or draw to make the event-write asynchronous,
but that would be a lot harder to do in igt.
I guess for now I'll re-work this patch to only do the workaround on
a7xx. And wire up the gallium preemption support so we can confirm
whether this is also an issue for preemption.
BR,
-R
> Connor
>
> > + OUT_RING(ring, 0);
> > + OUT_RING(ring, lower_32_bits(rbmemptr(ring, fence)));
> > + OUT_RING(ring, upper_32_bits(rbmemptr(ring, fence)));
> > + OUT_RING(ring, submit->seqno - 1);
> > +
> > if (!sysprof) {
> > if (!adreno_is_a7xx(adreno_gpu)) {
> > /* Turn off protected mode to write to special
> > registers */
> > @@ -193,7 +201,7 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
> > msm_gem_submit *submit)
> > struct msm_ringbuffer *ring = submit->ring;
> > unsigned int i, ibs = 0;
> >
> > - a6xx_set_pagetable(a6xx_gpu, ring, submit->queue->ctx);
> > + a6xx_set_pagetable(a6xx_gpu, ring, submit);
> >
> > get_stats_counter(ring, REG_A6XX_RBBM_PERFCTR_CP(0),
> > rbmemptr_stats(ring, index, cpcycles_start));
> > @@ -283,7 +291,7 @@ static void a7xx_submit(struct msm_gpu *gpu, struct
> > msm_gem_submit *submit)
> > OUT_PKT7(ring, CP_THREAD_CONTROL, 1);
> > OUT_RING(ring, CP_THREAD_CONTROL_0_SYNC_THREADS | CP_SET_THREAD_BR);
> >
> > - a6xx_set_pagetable(a6xx_gpu, ring, submit->queue->ctx);
> > + a6xx_set_pagetable(a6xx_gpu, ring, submit);
> >
> > get_stats_counter(ring, REG_A7XX_RBBM_PERFCTR_CP(0),
> > rbmemptr_stats(ring, index, cpcycles_start));
> > --
> > 2.46.0
> >
Re: [PATCH] drm/amdgpu: Fix typo "acccess" and improve the comment style here
Applied. Thanks!
Alex
On Fri, Sep 20, 2024 at 2:29 AM Christian König
wrote:
>
> Am 20.09.24 um 04:27 schrieb WangYuli:
> > There are some spelling mistakes of 'acccess' in comments which
> > should be instead of 'access'.
> >
> > And the comment style should be like this:
> > /*
> >* Text
> >* Text
> >*/
> >
> > Suggested-by: Christian König
> > Link:
> > https://lore.kernel.org/all/f75fbe30-528e-404f-97e4-854d27d7a...@amd.com/
> > Acked-by: Thomas Zimmermann
> > Link:
> > https://lore.kernel.org/all/0c768bf6-bc19-43de-a30b-ff5e3ddfd...@suse.de/
> > Signed-off-by: WangYuli
>
> Reviewed-by: Christian König
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 6 --
> > drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 6 --
> > 2 files changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> > index d3e8be82a172..33fd2da49a2a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> > @@ -1893,8 +1893,10 @@ static void gfx_v11_0_init_compute_vmid(struct
> > amdgpu_device *adev)
> > soc21_grbm_select(adev, 0, 0, 0, 0);
> > mutex_unlock(&adev->srbm_mutex);
> >
> > - /* Initialize all compute VMIDs to have no GDS, GWS, or OA
> > -acccess. These should be enabled by FW for target VMIDs. */
> > + /*
> > + * Initialize all compute VMIDs to have no GDS, GWS, or OA
> > + * access. These should be enabled by FW for target VMIDs.
> > + */
> > for (i = adev->vm_manager.first_kfd_vmid; i < AMDGPU_NUM_VMID; i++) {
> > WREG32_SOC15_OFFSET(GC, 0, regGDS_VMID0_BASE, 2 * i, 0);
> > WREG32_SOC15_OFFSET(GC, 0, regGDS_VMID0_SIZE, 2 * i, 0);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
> > index 408e5600bb61..57b55b6d797d 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
> > @@ -1247,8 +1247,10 @@ static void gfx_v9_4_3_xcc_init_compute_vmid(struct
> > amdgpu_device *adev,
> > soc15_grbm_select(adev, 0, 0, 0, 0, GET_INST(GC, xcc_id));
> > mutex_unlock(&adev->srbm_mutex);
> >
> > - /* Initialize all compute VMIDs to have no GDS, GWS, or OA
> > -acccess. These should be enabled by FW for target VMIDs. */
> > + /*
> > + * Initialize all compute VMIDs to have no GDS, GWS, or OA
> > + * access. These should be enabled by FW for target VMIDs.
> > + */
> > for (i = adev->vm_manager.first_kfd_vmid; i < AMDGPU_NUM_VMID; i++) {
> > WREG32_SOC15_OFFSET(GC, GET_INST(GC, xcc_id),
> > regGDS_VMID0_BASE, 2 * i, 0);
> > WREG32_SOC15_OFFSET(GC, GET_INST(GC, xcc_id),
> > regGDS_VMID0_SIZE, 2 * i, 0);
>
Re: [PATCH 2/6] dt-bindings: iommu: mediatek: Fix interrupt count constraint for new SoCs
On Tue, Sep 24, 2024 at 06:31:52PM +0800, Macpaul Lin wrote:
> The infra-iommu node in mt8195.dtsi was triggering a CHECK_DTBS error due
> to an excessively long 'interrupts' property. The error message was:
>
> infra-iommu@10315000: interrupts: [[0, 795, 4, 0], [0, 796, 4, 0],
> [0, 797, 4, 0], [0, 798, 4, 0], [0, 799, 4, 0]]
> is too long
>
> To address this issue, add "minItems: 1" and "maxItems: 5" constraints to
> the 'interrupts' property in the DT binding schema. This change allows for
> flexibility in the number of interrupts for new SoCs
>
> Fixes: bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT
> schema")
>
This space should be removed.
> Signed-off-by: Macpaul Lin
> ---
> Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> index ea6b0f5f24de..a00f1f0045b1 100644
> --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> @@ -96,7 +96,8 @@ properties:
> maxItems: 1
>
>interrupts:
> -maxItems: 1
> +minItems: 1
> +maxItems: 5
You need to add an items list here, and probably some per compatible
constraints. What are each of the itnerrupts for?
>
>clocks:
> items:
> --
> 2.45.2
>
signature.asc
Description: PGP signature
Re: [PATCH 3/6] dt-bindings: display: mediatek: Fix clocks count constraint for new SoCs
On Tue, Sep 24, 2024 at 01:42:01PM +0200, AngeloGioacchino Del Regno wrote:
> Il 24/09/24 12:31, Macpaul Lin ha scritto:
> > The display node in mt8195.dtsi was triggering a CHECK_DTBS error due
> > to an excessively long 'clocks' property:
> >display@14f06000: clocks: [[31, 14], [31, 43], [31, 44]] is too long
> >
> > To resolve this issue, add "maxItems: 3" to the 'clocks' property in
> > the DT schema.
> >
> > Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each
> > block to individual yaml")
> > Signed-off-by: Macpaul Lin
> > ---
> > .../devicetree/bindings/display/mediatek/mediatek,split.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
> > index e4affc854f3d..42d2d483cc29 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
> > @@ -57,6 +57,7 @@ properties:
> > clocks:
> > items:
> > - description: SPLIT Clock
>
> That's at least confusing (granted that it works) - either add a description
> for
> each clock and then set `minItems: 1` (preferred), or remove this "SPLIT
> Clock"
> description and allow a maximum of 3 clocks.
>
> Removing the description can be done - IMO - because "SPLIT Clock" is, well,
> saying that the SPLIT block gets a SPLIT clock ... stating the obvious,
> anyway.
Right, but what are the other two new clocks? Are they as obvious?
There's no clock-names here to give any more information as to what the
other clocks are supposed to be.
Kinda unrelated, but I think that "SPLIT Clock" probably isn't what the
name of the clock in the IP block is anyway, sounds more like the name
for it on the provider end..
signature.asc
Description: PGP signature
Re: [PATCH 0/2] drm: revert some framebuffer API tests
On Tue, 24 Sep 2024, Guenter Roeck wrote: On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: > Yeah I think long-term we might want a kunit framework so that we can > catch dmesg warnings we expect and test for those, without those warnings > actually going to dmesg. Similar to how the lockdep tests also reroute > locking validation, so that the expected positive tests don't wreak > lockdep for real. > > But until that exists, we can't have tests that splat in dmesg when they > work as intended. > > FWIW, that is arguable. More and more tests are added which do add such > splats, > and I don't see any hesitance by developers to adding more. So far I counted > two alone in this commit window, and that does not include new splats from > tests which I had already disabled. I simply disable those tests or don't > enable them in the first place if they are new. I did the same with the drm > unit tests due to the splats generated by the scaling unit tests, so any > additional drm unit test splats don't make a difference for me since the > tests are already disabled. What's the point of having unit tests that CI systems routinely have to filter out of test runs? Or filter warnings generated by the tests, potentially missing new warnings. Who is going to run the tests if the existing CI systems choose to ignore them? Automation on a massive scale is key here, and making that harder is counter-productive. BR, Jani. -- Jani Nikula, Intel
Re: [PATCH v4 4/8] drm/bridge: hotplug-bridge: add driver to support hot-pluggable DSI bridges
Hello Simona, Maxime, Dmitry, On Tue, 17 Sep 2024 10:53:08 +0200 Luca Ceresoli wrote: > This driver implements the point of a DRM pipeline where a connector allows > removal of all the following bridges up to the panel. This is a quick feedback of the discussions about hotpluggable DRM bridges I had with Maxime and Dmitry during the Linux Plumbers Conference last week, which happened during the discussion I led on Wednesday afternoon and even more in the hallway. It was clear that adding refcounting to DRM bridges and handling gracefully atomic modeset operations during device removal are prerequisites for a hotpluggable bridge in DRM. DSI host drivers that keep a pointer to their device also need to be fixed, but this is well known and was not discussed. Simona's proposal of letting removable bridges be owned by the hotplug connector was not seen as necessarily needed, especially after adding bridge refcounting. Also Maxime mentioned this idea might conflict with a use case that had been brought to his attention, involving bridges and DP MST. So I'm removing this idea from my roadmap -- it can be re-discussed and brought back if needed. There was no clear outcome about the question of whether the hotplug-bridge should still exist as a drm_bridge or rather the DRM core and the bridge drivers should be extended to handle everything. Dmitry seemed to think no hotplug bridge should exist at all, and all bridge drivers should be extended to cope with insertion and removal of the follofing bridge. Ripard's opinion was "I don't care". In her e-mail sent a few hours ago (in the v2 thread) Simona also appears as not having a strong position about this. There will be some time to clarify this as I'm addressing the previously mentioned issues. So by now the roadmap involves the following main steps: 1. add refcounting to DRM bridges (struct drm_bridge) 2. handle gracefully atomic updates during bridge removal 3. avoid DSI host drivers to have dangling pointers to DSI devices 4. finish the hotplug bridge work, moving code to the core and potentially removing the hotplug-bridge itself If you think any other major item is required to support hot-pluggable DRM bridges, don't hesitate to speak out. Best regards, Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v4 00/11] Preemption support for A7XX
On Tue, Sep 24, 2024 at 07:47:12AM -0700, Rob Clark wrote: > On Tue, Sep 24, 2024 at 4:54 AM Antonino Maniscalco > wrote: > > > > On 9/20/24 7:09 PM, Akhil P Oommen wrote: > > > On Wed, Sep 18, 2024 at 09:46:33AM +0200, Neil Armstrong wrote: > > >> Hi, > > >> > > >> On 17/09/2024 13:14, Antonino Maniscalco wrote: > > >>> This series implements preemption for A7XX targets, which allows the > > >>> GPU to > > >>> switch to an higher priority ring when work is pushed to it, reducing > > >>> latency > > >>> for high priority submissions. > > >>> > > >>> This series enables L1 preemption with skip_save_restore which requires > > >>> the following userspace patches to function: > > >>> > > >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30544 > > >>> > > >>> A flag is added to `msm_submitqueue_create` to only allow submissions > > >>> from compatible userspace to be preempted, therefore maintaining > > >>> compatibility. > > >>> > > >>> Preemption is currently only enabled by default on A750, it can be > > >>> enabled on other targets through the `enable_preemption` module > > >>> parameter. This is because more testing is required on other targets. > > >>> > > >>> For testing on other HW it is sufficient to set that parameter to a > > >>> value of 1, then using the branch of mesa linked above, > > >>> `TU_DEBUG=hiprio` > > >>> allows to run any application as high priority therefore preempting > > >>> submissions from other applications. > > >>> > > >>> The `msm_gpu_preemption_trigger` and `msm_gpu_preemption_irq` traces > > >>> added in this series can be used to observe preemption's behavior as > > >>> well as measuring preemption latency. > > >>> > > >>> Some commits from this series are based on a previous series to enable > > >>> preemption on A6XX targets: > > >>> > > >>> https://lkml.kernel.org/1520489185-21828-1-git-send-email-smase...@codeaurora.org > > >>> > > >>> Signed-off-by: Antonino Maniscalco > > >>> --- > > >>> Changes in v4: > > >>> - Added missing register in pwrup list > > >>> - Removed and rearrange barriers > > >>> - Renamed `skip_inline_wptr` to `restore_wptr` > > >>> - Track ctx seqno per ring > > >>> - Removed secure preempt context > > >>> - NOP out postamble to disable it instantly > > >>> - Only emit pwrup reglist once > > >>> - Document bv_rptr_addr > > >>> - Removed unused A6XX_PREEMPT_USER_RECORD_SIZE > > >>> - Set name on preempt record buffer > > >>> - Link to v3: > > >>> https://lore.kernel.org/r/20240905-preemption-a750-t-v3-0-fd947699f...@gmail.com > > >>> > > >>> Changes in v3: > > >>> - Added documentation about preemption > > >>> - Use quirks to determine which target supports preemption > > >>> - Add a module parameter to force disabling or enabling preemption > > >>> - Clear postamble when profiling > > >>> - Define A6XX_CP_CONTEXT_SWITCH_CNTL_LEVEL fields in a6xx.xml > > >>> - Make preemption records MAP_PRIV > > >>> - Removed user ctx record (NON_PRIV) and patch 2/9 as it's not needed > > >>> anymore > > >>> - Link to v2: > > >>> https://lore.kernel.org/r/20240830-preemption-a750-t-v2-0-86aeead2c...@gmail.com > > >>> > > >>> Changes in v2: > > >>> - Added preept_record_size for X185 in PATCH 3/7 > > >>> - Added patches to reset perf counters > > >>> - Dropped unused defines > > >>> - Dropped unused variable (fixes warning) > > >>> - Only enable preemption on a750 > > >>> - Reject MSM_SUBMITQUEUE_ALLOW_PREEMPT for unsupported targets > > >>> - Added Akhil's Reviewed-By tags to patches 1/9,2/9,3/9 > > >>> - Added Neil's Tested-By tags > > >>> - Added explanation for UAPI changes in commit message > > >>> - Link to v1: > > >>> https://lore.kernel.org/r/20240815-preemption-a750-t-v1-0-7bda26c34...@gmail.com > > >>> > > >>> --- > > >>> Antonino Maniscalco (11): > > >>> drm/msm: Fix bv_fence being used as bv_rptr > > >>> drm/msm/A6XX: Track current_ctx_seqno per ring > > >>> drm/msm: Add a `preempt_record_size` field > > >>> drm/msm: Add CONTEXT_SWITCH_CNTL bitfields > > >>> drm/msm/A6xx: Implement preemption for A7XX targets > > >>> drm/msm/A6xx: Sync relevant adreno_pm4.xml changes > > >>> drm/msm/A6xx: Use posamble to reset counters on preemption > > >>> drm/msm/A6xx: Add traces for preemption > > >>> drm/msm/A6XX: Add a flag to allow preemption to > > >>> submitqueue_create > > >>> drm/msm/A6xx: Enable preemption for A750 > > >>> Documentation: document adreno preemption > > >>> > > >>>Documentation/gpu/msm-preemption.rst | 98 + > > >>>drivers/gpu/drm/msm/Makefile | 1 + > > >>>drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +- > > >>>drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +- > > >>>drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +- > > >>>drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +- > > >>>drivers/gpu/drm/msm/adreno/a6xx_catalog.c
Re: [PATCH 0/2] drm: revert some framebuffer API tests
On 9/24/24 06:56, Maxime Ripard wrote: On Tue, Sep 24, 2024 at 06:37:59AM GMT, Guenter Roeck wrote: On 9/24/24 04:54, Maxime Ripard wrote: +Guenter On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: On Tue, Sep 17, 2024 at 08:43:50PM +0300, Jani Nikula wrote: The tests consistently trigger WARNs in drm_framebuffer code. I'm not sure what the point is with type of belts and suspenders tests. The warnings *are* the way to flag erroneous API usage. Warnings in turn trigger failures in CI. Filtering the warnings are error prone, and, crucially, would also filter actual errors in case the kunit tests are not run. I acknowledge there may be complex test cases where you'd end up triggering warnings somewhere deep, but these are not it. These are simple. Revert the tests, back to the drawing board. Yeah I think long-term we might want a kunit framework so that we can catch dmesg warnings we expect and test for those, without those warnings actually going to dmesg. Similar to how the lockdep tests also reroute locking validation, so that the expected positive tests don't wreak lockdep for real. But until that exists, we can't have tests that splat in dmesg when they work as intended. FWIW, that is arguable. More and more tests are added which do add such splats, and I don't see any hesitance by developers to adding more. So far I counted two alone in this commit window, and that does not include new splats from tests which I had already disabled. I simply disable those tests or don't enable them in the first place if they are new. I did the same with the drm unit tests due to the splats generated by the scaling unit tests, so any additional drm unit test splats don't make a difference for me since the tests are already disabled. It should be pretty soon: https://lore.kernel.org/dri-devel/20240403131936.787234-1-li...@roeck-us.net/ I'm not sure what happened to that series, but it looks like everybody was mostly happy with it? Major subsystem maintainers did not provide any feedback at all, and then there came the "it is not perfect enough" feedback, so I gave up on it. Well, if that means anything, we're interested even in something imperfect if it solves the above case :) Maybe someone else is interested picking it up (and no need for credits). I am buried in work and don't have the time (nor, frankly, much interest) to revive it. Also, just for reference: The patch series touches a total of 8 architectures, and unless I missed some I only got feedback from two architecture maintainers. That doesn't include arm - I don't recall if it doesn't need changes or if I never got there. Guenter
Re: [PATCH 2/8] drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job
On 24/09/2024 15:20, Christian König wrote:
Am 24.09.24 um 16:12 schrieb Tvrtko Ursulin:
On 24/09/2024 14:55, Christian König wrote:
I've pushed the first to drm-misc-next, but that one here fails to
apply cleanly.
This appears due 440d52b370b0 ("drm/sched: Fix dynamic job-flow
control race") in drm-misc-fixes.
In theory 1-3 from my series are fixes. Should they also go to
drm-misc-fixes? I am not too familiar with the drm-misc flow.
Ah shit, in that case you should have spitted the patches up into fixes
and next. Going to push the first 3 to fixes.
Sorry my drm-intel ways of thinking (cherry picked fixes) are hard to
get rid of. Hence the series was structured as 1-3 fixes, 4-8 refactors etc.
Now appears it is too late to pull out the first one from drm-misc-next.
Or the series now needs to wait for some backmerge?
Are the remaining 3 patches independent? If not then we need to wait for
a backmerge.
These are independent:
Fixes:
1/8 "drm/sched: Add locking to drm_sched_entity_modify_sched"
Not fixes:
5/8 "drm/sched: Stop setting current entity in FIFO mode"
6/8 "drm/sched: Re-order struct drm_sched_rq members for clarity"
While the rest touch at least some common areas.
2/8 and 3/8 are also fixes.
4/8, 7/8 and 8/8 not fixes but depend on 2/8 and 3/8.
Regards,
Tvrtko
Am 24.09.24 um 12:19 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Since drm_sched_entity_modify_sched() can modify the entities run
queue,
lets make sure to only dereference the pointer once so both adding and
waking up are guaranteed to be consistent.
Alternative of moving the spin_unlock to after the wake up would for
now
be more problematic since the same lock is taken inside
drm_sched_rq_update_fifo().
v2:
* Improve commit message. (Philipp)
* Cache the scheduler pointer directly. (Christian)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify
sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: Philipp Stanner
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 0e002c17fcb6..a75eede8bf8d 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -599,6 +599,9 @@ void drm_sched_entity_push_job(struct
drm_sched_job *sched_job)
/* first job wakes up scheduler */
if (first) {
+ struct drm_gpu_scheduler *sched;
+ struct drm_sched_rq *rq;
+
/* Add the entity to the run queue */
spin_lock(&entity->rq_lock);
if (entity->stopped) {
@@ -608,13 +611,16 @@ void drm_sched_entity_push_job(struct
drm_sched_job *sched_job)
return;
}
- drm_sched_rq_add_entity(entity->rq, entity);
+ rq = entity->rq;
+ sched = rq->sched;
+
+ drm_sched_rq_add_entity(rq, entity);
spin_unlock(&entity->rq_lock);
if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
drm_sched_rq_update_fifo(entity, submit_ts);
- drm_sched_wakeup(entity->rq->sched);
+ drm_sched_wakeup(sched);
}
}
EXPORT_SYMBOL(drm_sched_entity_push_job);
Re: [PATCH v4 00/11] Preemption support for A7XX
On Tue, Sep 24, 2024 at 4:54 AM Antonino Maniscalco wrote: > > On 9/20/24 7:09 PM, Akhil P Oommen wrote: > > On Wed, Sep 18, 2024 at 09:46:33AM +0200, Neil Armstrong wrote: > >> Hi, > >> > >> On 17/09/2024 13:14, Antonino Maniscalco wrote: > >>> This series implements preemption for A7XX targets, which allows the GPU > >>> to > >>> switch to an higher priority ring when work is pushed to it, reducing > >>> latency > >>> for high priority submissions. > >>> > >>> This series enables L1 preemption with skip_save_restore which requires > >>> the following userspace patches to function: > >>> > >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30544 > >>> > >>> A flag is added to `msm_submitqueue_create` to only allow submissions > >>> from compatible userspace to be preempted, therefore maintaining > >>> compatibility. > >>> > >>> Preemption is currently only enabled by default on A750, it can be > >>> enabled on other targets through the `enable_preemption` module > >>> parameter. This is because more testing is required on other targets. > >>> > >>> For testing on other HW it is sufficient to set that parameter to a > >>> value of 1, then using the branch of mesa linked above, `TU_DEBUG=hiprio` > >>> allows to run any application as high priority therefore preempting > >>> submissions from other applications. > >>> > >>> The `msm_gpu_preemption_trigger` and `msm_gpu_preemption_irq` traces > >>> added in this series can be used to observe preemption's behavior as > >>> well as measuring preemption latency. > >>> > >>> Some commits from this series are based on a previous series to enable > >>> preemption on A6XX targets: > >>> > >>> https://lkml.kernel.org/1520489185-21828-1-git-send-email-smase...@codeaurora.org > >>> > >>> Signed-off-by: Antonino Maniscalco > >>> --- > >>> Changes in v4: > >>> - Added missing register in pwrup list > >>> - Removed and rearrange barriers > >>> - Renamed `skip_inline_wptr` to `restore_wptr` > >>> - Track ctx seqno per ring > >>> - Removed secure preempt context > >>> - NOP out postamble to disable it instantly > >>> - Only emit pwrup reglist once > >>> - Document bv_rptr_addr > >>> - Removed unused A6XX_PREEMPT_USER_RECORD_SIZE > >>> - Set name on preempt record buffer > >>> - Link to v3: > >>> https://lore.kernel.org/r/20240905-preemption-a750-t-v3-0-fd947699f...@gmail.com > >>> > >>> Changes in v3: > >>> - Added documentation about preemption > >>> - Use quirks to determine which target supports preemption > >>> - Add a module parameter to force disabling or enabling preemption > >>> - Clear postamble when profiling > >>> - Define A6XX_CP_CONTEXT_SWITCH_CNTL_LEVEL fields in a6xx.xml > >>> - Make preemption records MAP_PRIV > >>> - Removed user ctx record (NON_PRIV) and patch 2/9 as it's not needed > >>> anymore > >>> - Link to v2: > >>> https://lore.kernel.org/r/20240830-preemption-a750-t-v2-0-86aeead2c...@gmail.com > >>> > >>> Changes in v2: > >>> - Added preept_record_size for X185 in PATCH 3/7 > >>> - Added patches to reset perf counters > >>> - Dropped unused defines > >>> - Dropped unused variable (fixes warning) > >>> - Only enable preemption on a750 > >>> - Reject MSM_SUBMITQUEUE_ALLOW_PREEMPT for unsupported targets > >>> - Added Akhil's Reviewed-By tags to patches 1/9,2/9,3/9 > >>> - Added Neil's Tested-By tags > >>> - Added explanation for UAPI changes in commit message > >>> - Link to v1: > >>> https://lore.kernel.org/r/20240815-preemption-a750-t-v1-0-7bda26c34...@gmail.com > >>> > >>> --- > >>> Antonino Maniscalco (11): > >>> drm/msm: Fix bv_fence being used as bv_rptr > >>> drm/msm/A6XX: Track current_ctx_seqno per ring > >>> drm/msm: Add a `preempt_record_size` field > >>> drm/msm: Add CONTEXT_SWITCH_CNTL bitfields > >>> drm/msm/A6xx: Implement preemption for A7XX targets > >>> drm/msm/A6xx: Sync relevant adreno_pm4.xml changes > >>> drm/msm/A6xx: Use posamble to reset counters on preemption > >>> drm/msm/A6xx: Add traces for preemption > >>> drm/msm/A6XX: Add a flag to allow preemption to submitqueue_create > >>> drm/msm/A6xx: Enable preemption for A750 > >>> Documentation: document adreno preemption > >>> > >>>Documentation/gpu/msm-preemption.rst | 98 + > >>>drivers/gpu/drm/msm/Makefile | 1 + > >>>drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +- > >>>drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +- > >>>drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +- > >>>drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +- > >>>drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 7 +- > >>>drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 325 > >>> ++- > >>>drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 174 > >>>drivers/gpu/drm/msm/adreno/a6xx_preempt.c | 440 > >>> + > >>>driv
Re: radeon ARUBA NULL pointer dereference
On Tue, Sep 24, 2024 at 8:43 AM Thomas Zimmermann wrote:
>
>
>
> Am 24.09.24 um 14:20 schrieb Thomas Zimmermann:
> > (cc: DMA and x86 folks)
> >
> > Hi
> >
> > Am 24.09.24 um 04:08 schrieb Arthur Marsh:
> >> Using current Linus git head kernel, I was able to save the dmesg
> >> output:
> >>
> >> [ 17.218724] [drm] radeon kernel modesetting enabled.
> >> [ 17.218778] radeon :00:01.0: vgaarb: deactivate vga console
> >> [ 17.219509] Console: switching to colour dummy device 80x25
> >> [ 17.219700] [drm] initializing kernel modesetting (ARUBA
> >> 0x1002:0x990C 0x1002:0x0123 0x00).
> >> [ 17.219773] ATOM BIOS: 113
> >> [ 17.219838] radeon :00:01.0: VRAM: 768M 0x -
> >> 0x2FFF (768M used)
> >> [ 17.219841] radeon :00:01.0: GTT: 1024M 0x3000 -
> >> 0x6FFF
> >> [ 17.219844] [drm] Detected VRAM RAM=768M, BAR=256M
> >> [ 17.219845] [drm] RAM width 64bits DDR
> >> [ 17.219851] BUG: kernel NULL pointer dereference, address:
> >> 00a0
> >
> > This is 160 bytes behind NULL, which indicates a field within a struct.
> >
> >> [ 17.219852] #PF: supervisor read access in kernel mode
> >> [ 17.219853] #PF: error_code(0x) - not-present page
> >> [ 17.219854] PGD 0 P4D 0
> >> [ 17.219856] Oops: Oops: [#1] PREEMPT_RT SMP NOPTI
> >> [ 17.219858] CPU: 0 UID: 0 PID: 451 Comm: udevd Not tainted 6.11.0+
> >> #6121
> >> [ 17.219860] Hardware name: Gigabyte Technology Co., Ltd. To be
> >> filled by O.E.M./F2A78M-HD2, BIOS F2 05/28/2014
> >> [ 17.219862] RIP: 0010:dma_get_required_mask+0x11/0x50
> >> [ 17.219868] Code: 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
> >> 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 8b 87 68 02 00 00 48 85
> >> c0 74 11 <48> 8b 80 a0 00 00 00 48 85 c0 74 1f e9 ee ed 94 00 f6 87
> >> 2c 03 00
> >> [ 17.219870] RSP: 0018:a54bc13a7b00 EFLAGS: 00010202
> >> [ 17.219871] RAX: RBX: 00ff RCX:
> >>
> >> [ 17.219872] RDX: RSI: 0027 RDI:
> >> 976f44e720c8
> >> [ 17.219873] RBP: 976f44e720c8 R08: efff R09:
> >> ab2aab08
> >> [ 17.219874] R10: f000 R11: 0002 R12:
> >>
> >> [ 17.219875] R13: 976f48a4aa30 R14: R15:
> >> 0028
> >> [ 17.219876] FS: 7f59a070d840() GS:97726f80()
> >> knlGS:
> >> [ 17.219878] CS: 0010 DS: ES: CR0: 80050033
> >> [ 17.219879] CR2: 00a0 CR3: 0001053b4000 CR4:
> >> 000406f0
> >> [ 17.219880] Call Trace:
> >> [ 17.219881]
> >> [ 17.219882] ? __die_body.cold+0x19/0x1e
> >> [ 17.219885] ? page_fault_oops+0xa8/0x230
> >> [ 17.219889] ? search_module_extables+0x4f/0x90
> >> [ 17.219891] ? fixup_exception+0x36/0x2f0
> >> [ 17.219894] ? exc_page_fault+0x88/0x1b0
> >> [ 17.219897] ? asm_exc_page_fault+0x22/0x30
> >> [ 17.219900] ? dma_get_required_mask+0x11/0x50
Also reported here:
https://gitlab.freedesktop.org/drm/amd/-/issues/3648
Alex
> >
> > This is not in the radeon driver but the DMA code. I'd say it's at
> > [1], as get_required_mask is 160 bytes within struct drm_map_ops. The
> > call to get_arch_dma_ops() probably returns NULL.
>
> And indeed, when I added
>
> pr_warn("dev dma ops: 0x%p\n", pdev->dev.dma_ops);
> pr_warn("arch dma ops: 0x%p\n", get_arch_dma_ops());
>
> to radeon_pci_probe(), I got
>
> [ 22.325657] dev dma ops: 0x
> [ 22.342921] arch dma ops: 0x
>
> as a result.
>
> Best regards
> Thomas
>
> >
> > Best regards
> > Thomas
> >
> > [1]
> > https://elixir.bootlin.com/linux/v6.11/source/kernel/dma/mapping.c#L523
> > [2]
> > https://elixir.bootlin.com/linux/v6.11/source/include/linux/dma-map-ops.h#L98
> >
> >> [ 17.219902] dma_addressing_limited+0x6c/0xb0
> >> [ 17.219905] radeon_ttm_init+0x3f/0x210 [radeon]
> >> [ 17.219977] cayman_init+0x97/0x290 [radeon]
> >> [ 17.220057] radeon_device_init+0x5e9/0xb40 [radeon]
> >> [ 17.220115] radeon_driver_load_kms+0xb0/0x260 [radeon]
> >> [ 17.220174] radeon_pci_probe+0xff/0x170 [radeon]
> >> [ 17.220231] pci_device_probe+0xbe/0x1a0
> >> [ 17.220234] really_probe+0xde/0x350
> >> [ 17.220237] ? pm_runtime_barrier+0x61/0xb0
> >> [ 17.220240] ? __pfx___driver_attach+0x10/0x10
> >> [ 17.220242] __driver_probe_device+0x78/0x110
> >> [ 17.220245] driver_probe_device+0x2d/0xc0
> >> [ 17.220247] __driver_attach+0xc9/0x1c0
> >> [ 17.220249] bus_for_each_dev+0x6a/0xb0
> >> [ 17.220251] ? migrate_enable+0xbf/0xf0
> >> [ 17.220254] bus_add_driver+0x139/0x220
> >> [ 17.220256] driver_register+0x6e/0xc0
> >> [ 17.220258] ? __pfx_radeon_module_init+0x10/0x10 [radeon]
> >> [ 17.220315] do_one_initcall+0x42/0x210
> >> [ 17.220318] ? __kmalloc_cache_noprof+0x89/0x230
> >> [ 17.220321] do_init_module+0x60/0x210
> >> [ 17.220324]
Re: [PATCH v4] drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframes
On Tue, Sep 24, 2024 at 04:13:08PM GMT, Maxime Ripard wrote: > On Tue, 27 Aug 2024 11:39:04 -0500, Derek Foreman wrote: > > The largest infoframe we create is the DRM (Dynamic Range Mastering) > > infoframe which is 26 bytes + a 4 byte header, for a total of 30 > > bytes. > > > > With HDMI_MAX_INFOFRAME_SIZE set to 29 bytes, as it is now, we > > allocate too little space to pack a DRM infoframe in > > write_device_infoframe(), leading to an ENOSPC return from > > hdmi_infoframe_pack(), and never calling the connector's > > write_infoframe() vfunc. > > > > [...] > > Applied to misc/kernel.git (drm-misc-fixes). With an empty line between Fixes and the rest of the tags :-( > > Thanks! > Maxime > -- With best wishes Dmitry
Re: [PATCH 2/8] drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job
Am 24.09.24 um 16:12 schrieb Tvrtko Ursulin:
On 24/09/2024 14:55, Christian König wrote:
I've pushed the first to drm-misc-next, but that one here fails to
apply cleanly.
This appears due 440d52b370b0 ("drm/sched: Fix dynamic job-flow
control race") in drm-misc-fixes.
In theory 1-3 from my series are fixes. Should they also go to
drm-misc-fixes? I am not too familiar with the drm-misc flow.
Ah shit, in that case you should have spitted the patches up into fixes
and next. Going to push the first 3 to fixes.
Or the series now needs to wait for some backmerge?
Are the remaining 3 patches independent? If not then we need to wait for
a backmerge.
Regards,
Christian.
Regards,
Tvrtko
Am 24.09.24 um 12:19 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Since drm_sched_entity_modify_sched() can modify the entities run
queue,
lets make sure to only dereference the pointer once so both adding and
waking up are guaranteed to be consistent.
Alternative of moving the spin_unlock to after the wake up would for
now
be more problematic since the same lock is taken inside
drm_sched_rq_update_fifo().
v2:
* Improve commit message. (Philipp)
* Cache the scheduler pointer directly. (Christian)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify
sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: Philipp Stanner
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 0e002c17fcb6..a75eede8bf8d 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -599,6 +599,9 @@ void drm_sched_entity_push_job(struct
drm_sched_job *sched_job)
/* first job wakes up scheduler */
if (first) {
+ struct drm_gpu_scheduler *sched;
+ struct drm_sched_rq *rq;
+
/* Add the entity to the run queue */
spin_lock(&entity->rq_lock);
if (entity->stopped) {
@@ -608,13 +611,16 @@ void drm_sched_entity_push_job(struct
drm_sched_job *sched_job)
return;
}
- drm_sched_rq_add_entity(entity->rq, entity);
+ rq = entity->rq;
+ sched = rq->sched;
+
+ drm_sched_rq_add_entity(rq, entity);
spin_unlock(&entity->rq_lock);
if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
drm_sched_rq_update_fifo(entity, submit_ts);
- drm_sched_wakeup(entity->rq->sched);
+ drm_sched_wakeup(sched);
}
}
EXPORT_SYMBOL(drm_sched_entity_push_job);
Re: [PATCH] drm: renesas: rcar-du: Add drm_panic support for non-vsp
On Mon, 27 May 2024 15:35:49 +0200, Geert Uytterhoeven wrote: > Add support for the drm_panic module for DU variants not using the > VSP-compositor, to display a message on the screen when a kernel panic > occurs. > > Applied to misc/kernel.git (drm-misc-next). Thanks! Maxime
Re: [PATCH] drm: renesas: shmobile: Add drm_panic support
On Mon, 27 May 2024 15:34:48 +0200, Geert Uytterhoeven wrote: > Add support for the drm_panic module, which displays a message on > the screen when a kernel panic occurs. > > Applied to misc/kernel.git (drm-misc-next). Thanks! Maxime
Re: [PATCH v4] drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframes
On Tue, 27 Aug 2024 11:39:04 -0500, Derek Foreman wrote: > The largest infoframe we create is the DRM (Dynamic Range Mastering) > infoframe which is 26 bytes + a 4 byte header, for a total of 30 > bytes. > > With HDMI_MAX_INFOFRAME_SIZE set to 29 bytes, as it is now, we > allocate too little space to pack a DRM infoframe in > write_device_infoframe(), leading to an ENOSPC return from > hdmi_infoframe_pack(), and never calling the connector's > write_infoframe() vfunc. > > [...] Applied to misc/kernel.git (drm-misc-fixes). Thanks! Maxime
Re: [PATCH 2/8] drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job
On 24/09/2024 14:55, Christian König wrote:
I've pushed the first to drm-misc-next, but that one here fails to apply
cleanly.
This appears due 440d52b370b0 ("drm/sched: Fix dynamic job-flow control
race") in drm-misc-fixes.
In theory 1-3 from my series are fixes. Should they also go to
drm-misc-fixes? I am not too familiar with the drm-misc flow.
Or the series now needs to wait for some backmerge?
Regards,
Tvrtko
Am 24.09.24 um 12:19 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Since drm_sched_entity_modify_sched() can modify the entities run queue,
lets make sure to only dereference the pointer once so both adding and
waking up are guaranteed to be consistent.
Alternative of moving the spin_unlock to after the wake up would for now
be more problematic since the same lock is taken inside
drm_sched_rq_update_fifo().
v2:
* Improve commit message. (Philipp)
* Cache the scheduler pointer directly. (Christian)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify
sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: Philipp Stanner
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 0e002c17fcb6..a75eede8bf8d 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -599,6 +599,9 @@ void drm_sched_entity_push_job(struct
drm_sched_job *sched_job)
/* first job wakes up scheduler */
if (first) {
+ struct drm_gpu_scheduler *sched;
+ struct drm_sched_rq *rq;
+
/* Add the entity to the run queue */
spin_lock(&entity->rq_lock);
if (entity->stopped) {
@@ -608,13 +611,16 @@ void drm_sched_entity_push_job(struct
drm_sched_job *sched_job)
return;
}
- drm_sched_rq_add_entity(entity->rq, entity);
+ rq = entity->rq;
+ sched = rq->sched;
+
+ drm_sched_rq_add_entity(rq, entity);
spin_unlock(&entity->rq_lock);
if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
drm_sched_rq_update_fifo(entity, submit_ts);
- drm_sched_wakeup(entity->rq->sched);
+ drm_sched_wakeup(sched);
}
}
EXPORT_SYMBOL(drm_sched_entity_push_job);
Re: [PATCH v2] drm/amdgpu: add dce6 drm_panic support
On Fri, Sep 20, 2024 at 11:36 AM Jocelyn Falempe wrote:
>
> On 17/09/2024 15:21, Alex Deucher wrote:
> > On Mon, Aug 12, 2024 at 2:10 AM Lu Yao wrote:
> >>
> >> Add support for the drm_panic module, which displays a pretty user
> >> friendly message on the screen when a Linux kernel panic occurs.
> >>
> >> Signed-off-by: Lu Yao
> >
> > Patch looks good to me. Any chance you want to convert the other
> > non-DC dce files (dce_v8_0.c, dce_v10_0.c, dce_v11_0.c) while you are
> > at it?
>
> I've made a similar patch in amdgpu_dm_plane.c, and it works on a Radeon
> pro w6400.
> But it only works when I'm in a VT terminal (so the framebuffer is
> linear and CPU accessible).
> When under Gnome/Wayland, the flag AMDGPU_GEM_CREATE_NO_CPU_ACCESS is
> set, so that means I can't vmap it ?
It just means that the application does not need CPU access. Whether
or not the CPU can access the buffer or not depends on the size of the
PCI BAR. E.g., if the driver or bios has resized the PCI BAR, then
the CPU can access the entire BAR, but if not you are generally
limited to the first 256M of framebuffer.
>
> Also I don't know if there is a similar way to disable
> tiling/compression on this hardware.
UNP_GRPH_CONTROL on chips with DCE display hardware and
DCSURF_ADDR_CONFIG and DCSURF_TILING_CONFIG on DCN display hardware.
Alex
>
> Best regards,
>
> --
>
> Jocelyn
>
>
> >
> > Alex
> >
> >
> >> ---
> >> Changes in v2:
> >> 1. Drop include "drm_internal.h"
> >> 2. Add disabling DC tiling ops.
> >> Per suggestion from previous thread:
> >> https://patchwork.freedesktop.org/patch/606879/?series=136832&rev=1
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 48 +++
> >> 1 file changed, 48 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> >> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> >> index 05c0df97f01d..ba1b7a36caa3 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> >> @@ -28,6 +28,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include "amdgpu.h"
> >> #include "amdgpu_pm.h"
> >> @@ -2600,6 +2601,52 @@ static const struct drm_crtc_helper_funcs
> >> dce_v6_0_crtc_helper_funcs = {
> >> .get_scanout_position = amdgpu_crtc_get_scanout_position,
> >> };
> >>
> >> +static int dce_v6_0_drm_primary_plane_get_scanout_buffer(struct drm_plane
> >> *plane,
> >> +struct
> >> drm_scanout_buffer *sb)
> >> +{
> >> + struct drm_framebuffer *fb;
> >> + struct amdgpu_bo *abo;
> >> + struct amdgpu_crtc *amdgpu_crtc;
> >> + struct amdgpu_device *adev;
> >> + uint32_t fb_format;
> >> +
> >> + if (!plane->fb)
> >> + return -EINVAL;
> >> +
> >> + fb = plane->fb;
> >> +
> >> + abo = gem_to_amdgpu_bo(fb->obj[0]);
> >> + amdgpu_crtc = to_amdgpu_crtc(plane->crtc);
> >> + adev = drm_to_adev(fb->dev);
> >> +
> >> + if (!abo->kmap.virtual &&
> >> + ttm_bo_kmap(&abo->tbo, 0, PFN_UP(abo->tbo.base.size),
> >> &abo->kmap)) {
> >> + DRM_WARN("amdgpu bo map failed, panic won't be
> >> displayed\n");
> >> + return -ENOMEM;
> >> + }
> >> +
> >> + if (abo->kmap.bo_kmap_type & TTM_BO_MAP_IOMEM_MASK)
> >> + iosys_map_set_vaddr_iomem(&sb->map[0], abo->kmap.virtual);
> >> + else
> >> + iosys_map_set_vaddr(&sb->map[0], abo->kmap.virtual);
> >> +
> >> + sb->width = fb->width;
> >> + sb->height = fb->height;
> >> + sb->format = fb->format;
> >> + sb->pitch[0] = fb->pitches[0];
> >> +
> >> + /* Disable DC tiling */
> >> + fb_format = RREG32(mmGRPH_CONTROL + amdgpu_crtc->crtc_offset);
> >> + fb_format &= ~GRPH_ARRAY_MODE(0x7);
> >> + WREG32(mmGRPH_CONTROL + amdgpu_crtc->crtc_offset, fb_format);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static const struct drm_plane_helper_funcs
> >> dce_v6_0_drm_primary_plane_helper_funcs = {
> >> + .get_scanout_buffer = dce_v6_0_drm_primary_plane_get_scanout_buffer
> >> +};
> >> +
> >> static int dce_v6_0_crtc_init(struct amdgpu_device *adev, int index)
> >> {
> >> struct amdgpu_crtc *amdgpu_crtc;
> >> @@ -2627,6 +2674,7 @@ static int dce_v6_0_crtc_init(struct amdgpu_device
> >> *adev, int index)
> >> amdgpu_crtc->encoder = NULL;
> >> amdgpu_crtc->connector = NULL;
> >> drm_crtc_helper_add(&amdgpu_crtc->base,
> >> &dce_v6_0_crtc_helper_funcs);
> >> + drm_plane_helper_add(amdgpu_crtc->base.primary,
> >> &dce_v6_0_drm_primary_plane_helper_funcs);
> >>
> >> return 0;
> >> }
> >> --
> >> 2.25.1
> >>
> >
>
Re: [PATCH v7 3/3] drm/rockchip: Add basic RK3588 HDMI output support
Hi,
On Sat, Sep 14, 2024 at 09:56:53PM GMT, Cristian Ciocaltea wrote:
> The RK3588 SoC family integrates the newer Synopsys DesignWare HDMI 2.1
> Quad-Pixel (QP) TX controller IP and a HDMI/eDP TX Combo PHY based on a
> Samsung IP block.
>
> Add just the basic support for now, i.e. RGB output up to 4K@60Hz,
> without audio, CEC or any of the HDMI 2.1 specific features.
>
> Co-developed-by: Algea Cao
> Signed-off-by: Algea Cao
> Tested-by: Heiko Stuebner
> Signed-off-by: Cristian Ciocaltea
> ---
> drivers/gpu/drm/rockchip/Kconfig | 9 +
> drivers/gpu/drm/rockchip/Makefile | 1 +
> drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 436
> +
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 2 +
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 1 +
> 5 files changed, 449 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/Kconfig
> b/drivers/gpu/drm/rockchip/Kconfig
> index 23c49e91f1cc..448fadd4ba15 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -8,6 +8,7 @@ config DRM_ROCKCHIP
> select VIDEOMODE_HELPERS
> select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
> select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
> + select DRM_DW_HDMI_QP if ROCKCHIP_DW_HDMI_QP
> select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
> select GENERIC_PHY if ROCKCHIP_DW_MIPI_DSI
> select GENERIC_PHY_MIPI_DPHY if ROCKCHIP_DW_MIPI_DSI
> @@ -63,6 +64,14 @@ config ROCKCHIP_DW_HDMI
> enable HDMI on RK3288 or RK3399 based SoC, you should select
> this option.
>
> +config ROCKCHIP_DW_HDMI_QP
> + bool "Rockchip specific extensions for Synopsys DW HDMI QP"
> + select DRM_BRIDGE_CONNECTOR
> + help
> + This selects support for Rockchip SoC specific extensions
> + for the Synopsys DesignWare HDMI QP driver. If you want to
> + enable HDMI on RK3588 based SoC, you should select this option.
> +
> config ROCKCHIP_DW_MIPI_DSI
> bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
> select GENERIC_PHY_MIPI_DPHY
> diff --git a/drivers/gpu/drm/rockchip/Makefile
> b/drivers/gpu/drm/rockchip/Makefile
> index 3ff7b21c0414..3eab662a5a1d 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -11,6 +11,7 @@ rockchipdrm-$(CONFIG_ROCKCHIP_VOP) += rockchip_drm_vop.o
> rockchip_vop_reg.o
> rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI_QP) += dw_hdmi_qp-rockchip.o
> rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi-rockchip.o
> rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> new file mode 100644
> index ..19d407c926bd
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> @@ -0,0 +1,436 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2021-2022 Rockchip Electronics Co., Ltd.
> + * Copyright (c) 2024 Collabora Ltd.
> + *
> + * Author: Algea Cao
> + * Author: Cristian Ciocaltea
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "rockchip_drm_drv.h"
> +
> +#define RK3588_GRF_SOC_CON2 0x0308
> +#define RK3588_HDMI0_HPD_INT_MSK BIT(13)
> +#define RK3588_HDMI0_HPD_INT_CLR BIT(12)
> +#define RK3588_GRF_SOC_CON7 0x031c
> +#define RK3588_SET_HPD_PATH_MASK GENMASK(13, 12)
> +#define RK3588_GRF_SOC_STATUS1 0x0384
> +#define RK3588_HDMI0_LEVEL_INT BIT(16)
> +#define RK3588_GRF_VO1_CON3 0x000c
> +#define RK3588_SCLIN_MASKBIT(9)
> +#define RK3588_SDAIN_MASKBIT(10)
> +#define RK3588_MODE_MASK BIT(11)
> +#define RK3588_I2S_SEL_MASK BIT(13)
> +#define RK3588_GRF_VO1_CON9 0x0024
> +#define RK3588_HDMI0_GRANT_SEL BIT(10)
> +
> +#define HIWORD_UPDATE(val, mask) ((val) | (mask) << 16)
> +
> +struct rockchip_hdmi_qp {
> + struct device *dev;
> + struct regmap *regmap;
> + struct regmap *vo_regmap;
> + struct rockchip_encoder encoder;
> + struct clk *ref_clk;
> + struct dw_hdmi_qp *hdmi;
> + struct phy *phy;
> + struct gpio_desc *enable_gpio;
> + struct delayed_work hpd_work;
> +};
> +
> +static struct rockchip_hdmi_qp *to_rockchip_hdmi_qp(struct drm_encoder
> *encoder)
> +{
> + struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
> +
> + return container_of(rkencoder, struct rockchip_hdmi_qp, encoder);
> +}
> +
> +static void
> +dw_hdmi_qp_rockchip_enco
Re: [PATCH v7 1/3] drm/bridge: synopsys: Add DW HDMI QP TX Controller support library
On Sat, 14 Sep 2024 21:56:51 +0300, Cristian Ciocaltea wrote: > The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX Controller IP > supports the following features, among others: > > * Fixed Rate Link (FRL) > * Display Stream Compression (DSC) > > [ ... ] Reviewed-by: Maxime Ripard Thanks! Maxime
Re: [PATCH 0/2] drm: revert some framebuffer API tests
On Tue, Sep 24, 2024 at 06:37:59AM GMT, Guenter Roeck wrote: > On 9/24/24 04:54, Maxime Ripard wrote: > > +Guenter > > > > On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: > > > On Tue, Sep 17, 2024 at 08:43:50PM +0300, Jani Nikula wrote: > > > > The tests consistently trigger WARNs in drm_framebuffer code. I'm not > > > > sure what the point is with type of belts and suspenders tests. The > > > > warnings *are* the way to flag erroneous API usage. > > > > > > > > Warnings in turn trigger failures in CI. Filtering the warnings are > > > > error prone, and, crucially, would also filter actual errors in case the > > > > kunit tests are not run. > > > > > > > > I acknowledge there may be complex test cases where you'd end up > > > > triggering warnings somewhere deep, but these are not it. These are > > > > simple. > > > > > > > > Revert the tests, back to the drawing board. > > > > > > Yeah I think long-term we might want a kunit framework so that we can > > > catch dmesg warnings we expect and test for those, without those warnings > > > actually going to dmesg. Similar to how the lockdep tests also reroute > > > locking validation, so that the expected positive tests don't wreak > > > lockdep for real. > > > > > > But until that exists, we can't have tests that splat in dmesg when they > > > work as intended. > > > > It should be pretty soon: > > https://lore.kernel.org/dri-devel/20240403131936.787234-1-li...@roeck-us.net/ > > > > I'm not sure what happened to that series, but it looks like everybody > > was mostly happy with it? > > > > Major subsystem maintainers did not provide any feedback at all, and then > there came the "it is not perfect enough" feedback, so I gave up on it. Well, if that means anything, we're interested even in something imperfect if it solves the above case :) Maxime signature.asc Description: PGP signature
Re: [PATCH 2/8] drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job
I've pushed the first to drm-misc-next, but that one here fails to apply
cleanly.
Christian.
Am 24.09.24 um 12:19 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Since drm_sched_entity_modify_sched() can modify the entities run queue,
lets make sure to only dereference the pointer once so both adding and
waking up are guaranteed to be consistent.
Alternative of moving the spin_unlock to after the wake up would for now
be more problematic since the same lock is taken inside
drm_sched_rq_update_fifo().
v2:
* Improve commit message. (Philipp)
* Cache the scheduler pointer directly. (Christian)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: Philipp Stanner
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 0e002c17fcb6..a75eede8bf8d 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -599,6 +599,9 @@ void drm_sched_entity_push_job(struct drm_sched_job
*sched_job)
/* first job wakes up scheduler */
if (first) {
+ struct drm_gpu_scheduler *sched;
+ struct drm_sched_rq *rq;
+
/* Add the entity to the run queue */
spin_lock(&entity->rq_lock);
if (entity->stopped) {
@@ -608,13 +611,16 @@ void drm_sched_entity_push_job(struct drm_sched_job
*sched_job)
return;
}
- drm_sched_rq_add_entity(entity->rq, entity);
+ rq = entity->rq;
+ sched = rq->sched;
+
+ drm_sched_rq_add_entity(rq, entity);
spin_unlock(&entity->rq_lock);
if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
drm_sched_rq_update_fifo(entity, submit_ts);
- drm_sched_wakeup(entity->rq->sched);
+ drm_sched_wakeup(sched);
}
}
EXPORT_SYMBOL(drm_sched_entity_push_job);
Re: [PATCH v17 4/8] drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver
On Tue, Sep 24, 2024 at 12:16:27PM GMT, Maxime Ripard wrote:
> On Tue, Sep 24, 2024 at 03:36:49PM GMT, Sandor Yu wrote:
> > +static int cdns_mhdp8501_read_hpd(struct cdns_mhdp8501_device *mhdp)
> > +{
> > + u8 status;
> > + int ret;
> > +
> > + mutex_lock(&mhdp_mailbox_mutex);
> > +
> > + ret = cdns_mhdp_mailbox_send(&mhdp->base, MB_MODULE_ID_GENERAL,
> > +GENERAL_GET_HPD_STATE, 0, NULL);
> > + if (ret)
> > + goto err_get_hpd;
> > +
> > + ret = cdns_mhdp_mailbox_recv_header(&mhdp->base, MB_MODULE_ID_GENERAL,
> > + GENERAL_GET_HPD_STATE,
> > + sizeof(status));
> > + if (ret)
> > + goto err_get_hpd;
> > +
> > + ret = cdns_mhdp_mailbox_recv_data(&mhdp->base, &status, sizeof(status));
> > + if (ret)
> > + goto err_get_hpd;
> > +
> > + mutex_unlock(&mhdp_mailbox_mutex);
>
> That's better I guess, but it's still not a good API design. If you
> can't have concurrent accesses, then cdns_mhdp_mailbox_send et al.
> should take the mutex themselves.
I think that a proper API might be:
int cdns_mhdp_mailbox_send_recv(struct cdns_mhdp_device *mhdp,
u8 module_id, u8 opcode,
u16 size, const u8 *message,
u16 buf_size, u8 *buf);
Internally it should take the lock, exchange the data, then return.
--
With best wishes
Dmitry
Re: [PATCH 0/2] drm: revert some framebuffer API tests
On 9/24/24 04:54, Maxime Ripard wrote: +Guenter On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: On Tue, Sep 17, 2024 at 08:43:50PM +0300, Jani Nikula wrote: The tests consistently trigger WARNs in drm_framebuffer code. I'm not sure what the point is with type of belts and suspenders tests. The warnings *are* the way to flag erroneous API usage. Warnings in turn trigger failures in CI. Filtering the warnings are error prone, and, crucially, would also filter actual errors in case the kunit tests are not run. I acknowledge there may be complex test cases where you'd end up triggering warnings somewhere deep, but these are not it. These are simple. Revert the tests, back to the drawing board. Yeah I think long-term we might want a kunit framework so that we can catch dmesg warnings we expect and test for those, without those warnings actually going to dmesg. Similar to how the lockdep tests also reroute locking validation, so that the expected positive tests don't wreak lockdep for real. But until that exists, we can't have tests that splat in dmesg when they work as intended. It should be pretty soon: https://lore.kernel.org/dri-devel/20240403131936.787234-1-li...@roeck-us.net/ I'm not sure what happened to that series, but it looks like everybody was mostly happy with it? Major subsystem maintainers did not provide any feedback at all, and then there came the "it is not perfect enough" feedback, so I gave up on it. Guenter
Re: [PATCH] firmware/sysfb: Disable sysfb for firmware buffers with unknown parent
Thomas Zimmermann writes:
Hello Thomas,
> The sysfb framebuffer handling only operates on graphics devices
> that provide the system's firmware framebuffer. If that device is
> not known, assume that any graphics device has been initialized by
> firmware.
>
> Fixes a problem on i915 where sysfb does not release the firmware
> framebuffer after the native graphics driver loaded.
>
> Reported-by: Borah, Chaitanya Kumar
> Closes:
> https://lore.kernel.org/dri-devel/sj1pr11mb6129efb8ce63d1ef6d932f94b9...@sj1pr11mb6129.namprd11.prod.outlook.com/
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12160
> Signed-off-by: Thomas Zimmermann
> Fixes: b49420d6a1ae ("video/aperture: optionally match the device in
> sysfb_disable()")
> Cc: Javier Martinez Canillas
> Cc: Thomas Zimmermann
> Cc: Helge Deller
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Alex Deucher
> Cc: dri-devel@lists.freedesktop.org
> Cc: Linux regression tracking (Thorsten Leemhuis)
> Cc: # v6.11+
> ---
> drivers/firmware/sysfb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
> index 02a07d3d0d40..a3df782fa687 100644
> --- a/drivers/firmware/sysfb.c
> +++ b/drivers/firmware/sysfb.c
> @@ -67,9 +67,11 @@ static bool sysfb_unregister(void)
> void sysfb_disable(struct device *dev)
> {
> struct screen_info *si = &screen_info;
> + struct device *parent;
>
> mutex_lock(&disable_lock);
> - if (!dev || dev == sysfb_parent_dev(si)) {
> + parent = sysfb_parent_dev(si);
> + if (!dev || !parent || dev == parent) {
> sysfb_unregister();
> disabled = true;
> }
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH] firmware/sysfb: Disable sysfb for firmware buffers with unknown parent
On Tue, Sep 24, 2024 at 4:58 AM Thomas Zimmermann wrote:
>
> The sysfb framebuffer handling only operates on graphics devices
> that provide the system's firmware framebuffer. If that device is
> not known, assume that any graphics device has been initialized by
> firmware.
>
> Fixes a problem on i915 where sysfb does not release the firmware
> framebuffer after the native graphics driver loaded.
>
> Reported-by: Borah, Chaitanya Kumar
> Closes:
> https://lore.kernel.org/dri-devel/sj1pr11mb6129efb8ce63d1ef6d932f94b9...@sj1pr11mb6129.namprd11.prod.outlook.com/
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12160
> Signed-off-by: Thomas Zimmermann
> Fixes: b49420d6a1ae ("video/aperture: optionally match the device in
> sysfb_disable()")
> Cc: Javier Martinez Canillas
> Cc: Thomas Zimmermann
> Cc: Helge Deller
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Alex Deucher
> Cc: dri-devel@lists.freedesktop.org
> Cc: Linux regression tracking (Thorsten Leemhuis)
> Cc: # v6.11+
Thanks for fixing this.
Acked-by: Alex Deucher
> ---
> drivers/firmware/sysfb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
> index 02a07d3d0d40..a3df782fa687 100644
> --- a/drivers/firmware/sysfb.c
> +++ b/drivers/firmware/sysfb.c
> @@ -67,9 +67,11 @@ static bool sysfb_unregister(void)
> void sysfb_disable(struct device *dev)
> {
> struct screen_info *si = &screen_info;
> + struct device *parent;
>
> mutex_lock(&disable_lock);
> - if (!dev || dev == sysfb_parent_dev(si)) {
> + parent = sysfb_parent_dev(si);
> + if (!dev || !parent || dev == parent) {
> sysfb_unregister();
> disabled = true;
> }
> --
> 2.46.0
>
Re: [PATCH v2 1/2] gpu: ipu-v3: vdic: Simplify ipu_vdi_setup()
On 9/4/24 11:05 AM, Philipp Zabel wrote: On Mi, 2024-07-24 at 02:19 +0200, Marek Vasut wrote: The 'code' parameter only ever selects between YUV 4:2:0 and 4:2:2 subsampling, turn it into boolean to select exactly that and update related code accordingly. Signed-off-by: Marek Vasut I'd prefer this to be an enum ipu_chroma_subsampling or similar, instead of a boolean. Otherwise, I'm afraid this introduces unnecessary back and forth conversions between the boolean and either of the two enum ipu_chroma_subsampling values in the code.
Re: radeon ARUBA NULL pointer dereference
Am 24.09.24 um 14:20 schrieb Thomas Zimmermann:
(cc: DMA and x86 folks)
Hi
Am 24.09.24 um 04:08 schrieb Arthur Marsh:
Using current Linus git head kernel, I was able to save the dmesg
output:
[ 17.218724] [drm] radeon kernel modesetting enabled.
[ 17.218778] radeon :00:01.0: vgaarb: deactivate vga console
[ 17.219509] Console: switching to colour dummy device 80x25
[ 17.219700] [drm] initializing kernel modesetting (ARUBA
0x1002:0x990C 0x1002:0x0123 0x00).
[ 17.219773] ATOM BIOS: 113
[ 17.219838] radeon :00:01.0: VRAM: 768M 0x -
0x2FFF (768M used)
[ 17.219841] radeon :00:01.0: GTT: 1024M 0x3000 -
0x6FFF
[ 17.219844] [drm] Detected VRAM RAM=768M, BAR=256M
[ 17.219845] [drm] RAM width 64bits DDR
[ 17.219851] BUG: kernel NULL pointer dereference, address:
00a0
This is 160 bytes behind NULL, which indicates a field within a struct.
[ 17.219852] #PF: supervisor read access in kernel mode
[ 17.219853] #PF: error_code(0x) - not-present page
[ 17.219854] PGD 0 P4D 0
[ 17.219856] Oops: Oops: [#1] PREEMPT_RT SMP NOPTI
[ 17.219858] CPU: 0 UID: 0 PID: 451 Comm: udevd Not tainted 6.11.0+
#6121
[ 17.219860] Hardware name: Gigabyte Technology Co., Ltd. To be
filled by O.E.M./F2A78M-HD2, BIOS F2 05/28/2014
[ 17.219862] RIP: 0010:dma_get_required_mask+0x11/0x50
[ 17.219868] Code: 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 8b 87 68 02 00 00 48 85
c0 74 11 <48> 8b 80 a0 00 00 00 48 85 c0 74 1f e9 ee ed 94 00 f6 87
2c 03 00
[ 17.219870] RSP: 0018:a54bc13a7b00 EFLAGS: 00010202
[ 17.219871] RAX: RBX: 00ff RCX:
[ 17.219872] RDX: RSI: 0027 RDI:
976f44e720c8
[ 17.219873] RBP: 976f44e720c8 R08: efff R09:
ab2aab08
[ 17.219874] R10: f000 R11: 0002 R12:
[ 17.219875] R13: 976f48a4aa30 R14: R15:
0028
[ 17.219876] FS: 7f59a070d840() GS:97726f80()
knlGS:
[ 17.219878] CS: 0010 DS: ES: CR0: 80050033
[ 17.219879] CR2: 00a0 CR3: 0001053b4000 CR4:
000406f0
[ 17.219880] Call Trace:
[ 17.219881]
[ 17.219882] ? __die_body.cold+0x19/0x1e
[ 17.219885] ? page_fault_oops+0xa8/0x230
[ 17.219889] ? search_module_extables+0x4f/0x90
[ 17.219891] ? fixup_exception+0x36/0x2f0
[ 17.219894] ? exc_page_fault+0x88/0x1b0
[ 17.219897] ? asm_exc_page_fault+0x22/0x30
[ 17.219900] ? dma_get_required_mask+0x11/0x50
This is not in the radeon driver but the DMA code. I'd say it's at
[1], as get_required_mask is 160 bytes within struct drm_map_ops. The
call to get_arch_dma_ops() probably returns NULL.
And indeed, when I added
pr_warn("dev dma ops: 0x%p\n", pdev->dev.dma_ops);
pr_warn("arch dma ops: 0x%p\n", get_arch_dma_ops());
to radeon_pci_probe(), I got
[ 22.325657] dev dma ops: 0x
[ 22.342921] arch dma ops: 0x
as a result.
Best regards
Thomas
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v6.11/source/kernel/dma/mapping.c#L523
[2]
https://elixir.bootlin.com/linux/v6.11/source/include/linux/dma-map-ops.h#L98
[ 17.219902] dma_addressing_limited+0x6c/0xb0
[ 17.219905] radeon_ttm_init+0x3f/0x210 [radeon]
[ 17.219977] cayman_init+0x97/0x290 [radeon]
[ 17.220057] radeon_device_init+0x5e9/0xb40 [radeon]
[ 17.220115] radeon_driver_load_kms+0xb0/0x260 [radeon]
[ 17.220174] radeon_pci_probe+0xff/0x170 [radeon]
[ 17.220231] pci_device_probe+0xbe/0x1a0
[ 17.220234] really_probe+0xde/0x350
[ 17.220237] ? pm_runtime_barrier+0x61/0xb0
[ 17.220240] ? __pfx___driver_attach+0x10/0x10
[ 17.220242] __driver_probe_device+0x78/0x110
[ 17.220245] driver_probe_device+0x2d/0xc0
[ 17.220247] __driver_attach+0xc9/0x1c0
[ 17.220249] bus_for_each_dev+0x6a/0xb0
[ 17.220251] ? migrate_enable+0xbf/0xf0
[ 17.220254] bus_add_driver+0x139/0x220
[ 17.220256] driver_register+0x6e/0xc0
[ 17.220258] ? __pfx_radeon_module_init+0x10/0x10 [radeon]
[ 17.220315] do_one_initcall+0x42/0x210
[ 17.220318] ? __kmalloc_cache_noprof+0x89/0x230
[ 17.220321] do_init_module+0x60/0x210
[ 17.220324] init_module_from_file+0x89/0xc0
[ 17.220326] __x64_sys_finit_module+0x142/0x390
[ 17.220329] do_syscall_64+0x47/0x110
[ 17.220331] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 17.220334] RIP: 0033:0x7f59a0625279
[ 17.220336] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 77 6b 0d 00 f7 d8 64
89 01 48
[ 17.220337] RSP: 002b:7ffd15ee7df8 EFLAGS: 0246 ORIG_RAX:
0139
[ 17.220339] RAX: ffda RBX: 5578ae660840 RCX:
0
Re: [PATCH v3 0/2] drm/nouveau: Add drm_panic support for nv50+
On 13/09/2024 09:03, Jocelyn Falempe wrote: This series adds basic drm_panic support for nouveau. Patches 1 Add ABGR2101010 support in drm_panic. Patch 2 registers nouveau to drm_panic, and handle tiling. I've tested on a GTX1650 (Turing) and GF 8800 GT (Tesla), while running Gnome/Wayland desktop, and in VT. I got a test report, that it also works correctly on a GT1030 (Pascal). So I'm confident it works also on earlier GPUs. Best regards, -- Jocelyn It should work on other nv50+ cards, but I didn't test them. To test it, you need to build your kernel with CONFIG_DRM_PANIC=y, and run: echo c > /proc/sysrq-trigger or you can enable CONFIG_DRM_PANIC_DEBUG and run: echo 1 > /sys/kernel/debug/dri/0/drm_panic_plane_0 v2: * Rebase and drop already merged patches. * Rework the tiling algorithm, using "swizzle" to compute the offset inside the block. v3: * Fix support for Tesla GPU, which have simpler tiling. * Drop "add a private pointer to struct drm_scanout_buffer". * Use nouveau_framebuffer_get_layout() to get the tiling parameters. * Have 2 set_pixel() functions, depending on GPU family. Jocelyn Falempe (2): drm/panic: Add ABGR2101010 support drm/nouveau: Add drm_panic support for nv50+ drivers/gpu/drm/drm_panic.c | 10 ++ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 139 +++- 2 files changed, 147 insertions(+), 2 deletions(-) base-commit: 9d443deb0441b9dbb22a9aac3b471da05220df1b
Re: [PATCH 4/5] drm/msm/dpu: Add SA8775P support
On Tue, 24 Sept 2024 at 14:31, Mahadevan P wrote:
>
>
> On 9/24/2024 5:46 PM, Dmitry Baryshkov wrote:
> > On Tue, Sep 24, 2024 at 04:42:02PM GMT, Mahadevan P wrote:
> >> On 9/12/2024 1:34 PM, Dmitry Baryshkov wrote:
> >>> On Thu, Sep 12, 2024 at 12:44:36PM GMT, Mahadevan wrote:
> Add definitions for the display hardware used on the
> Qualcomm SA8775P platform.
>
> Signed-off-by: Mahadevan
> ---
> .../msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h | 485 ++
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 3 +-
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 3 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +-
> 4 files changed, 491 insertions(+), 3 deletions(-)
> create mode 100644
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h
>
> > [...]
> >
> +static const struct dpu_intf_cfg sa8775p_intf[] = {
> + {
> + .name = "intf_0", .id = INTF_0,
> + .base = 0x34000, .len = 0x280,
> + .features = INTF_SC7280_MASK,
> + .type = INTF_DP,
> + .controller_id = MSM_DP_CONTROLLER_0,
> + .prog_fetch_lines_worst_case = 24,
> + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
> + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25),
> + }, {
> + .name = "intf_1", .id = INTF_1,
> + .base = 0x35000, .len = 0x300,
> + .features = INTF_SC7280_MASK,
> + .type = INTF_DSI,
> + .controller_id = MSM_DSI_CONTROLLER_0,
> + .prog_fetch_lines_worst_case = 24,
> + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
> + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
> + .intr_tear_rd_ptr = DPU_IRQ_IDX(MDP_INTF1_TEAR_INTR, 2),
> + }, {
> + .name = "intf_2", .id = INTF_2,
> + .base = 0x36000, .len = 0x300,
> + .features = INTF_SC7280_MASK,
> + .type = INTF_DSI,
> + .controller_id = MSM_DSI_CONTROLLER_1,
> + .prog_fetch_lines_worst_case = 24,
> + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
> + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29),
> + .intr_tear_rd_ptr = DPU_IRQ_IDX(MDP_INTF2_TEAR_INTR, 2),
> + }, {
> + .name = "intf_3", .id = INTF_3,
> + .base = 0x37000, .len = 0x280,
> + .features = INTF_SC7280_MASK,
> + .type = INTF_NONE,
> + .controller_id = MSM_DP_CONTROLLER_0, /* pair with intf_0
> for DP MST */
> + .prog_fetch_lines_worst_case = 24,
> + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 30),
> + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 31),
> + }, {
> + .name = "intf_4", .id = INTF_4,
> + .base = 0x38000, .len = 0x280,
> + .features = INTF_SC7280_MASK,
> + .type = INTF_DP,
> + .controller_id = MSM_DP_CONTROLLER_1,
> + .prog_fetch_lines_worst_case = 24,
> + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 20),
> + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 21),
> + }, {
> >>> Where is intf_5 ?
> >>
> >> intf_5 of base address 0x39000 is not supported on this target.
> > Not supported by whom?
>
>
> In sa8775p mdss architecture intf_5 is not present. So we are not adding
> in SW too.
ack, thanks for the explanation. It's better now.
--
With best wishes
Dmitry
Re: [PATCH v4 2/4] drm/bridge: add Microchip DSI controller support for sam9x7 SoC series
On Tue, 24 Sept 2024 at 12:17, wrote:
>
> Hi Dmitry,
>
> On 20/09/24 9:45 pm, Dmitry Baryshkov wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Wed, Sep 18, 2024 at 04:01:17PM GMT, Manikandan Muralidharan wrote:
> >> Add the Microchip's DSI controller wrapper driver that uses
> >> the Synopsys DesignWare MIPI DSI host controller bridge.
> >>
> >> Signed-off-by: Manikandan Muralidharan
> >> ---
> >> changes in v4:
> >> - Fixed issues reported by kernel test robot
> >> - replaced syscon_regmap_lookup_by_phandle with
> >> syscon_regmap_lookup_by_compatible
> >>
> >> changes in v3:
> >> - make remove callback return void
> >>
> >> changes in v2:
> >> - use static const with global variables
> >> - replace dev_err with dev_err_probe
> >> - move clk_prepare_enable to simplify the error path
> >> - use FIELD_PREP calls
> >> - remove unused macros and unused functions
> >> - rename function name with mchp_ suffix
> >> - add suspend and resume pm calls to handle pllref_clk
> >> ---
> >> drivers/gpu/drm/bridge/Kconfig| 8 +
> >> drivers/gpu/drm/bridge/Makefile | 1 +
> >> drivers/gpu/drm/bridge/dw-mipi-dsi-mchp.c | 545 ++
> >> 3 files changed, 554 insertions(+)
> >> create mode 100644 drivers/gpu/drm/bridge/dw-mipi-dsi-mchp.c
> >>
> >> diff --git a/drivers/gpu/drm/bridge/Kconfig
> >> b/drivers/gpu/drm/bridge/Kconfig
> >> index 683cb33805b2..317246509601 100644
> >> --- a/drivers/gpu/drm/bridge/Kconfig
> >> +++ b/drivers/gpu/drm/bridge/Kconfig
> >> @@ -196,6 +196,14 @@ config DRM_MICROCHIP_LVDS_SERIALIZER
> >>help
> >> Support for Microchip's LVDS serializer.
> >>
> >> +config DRM_MICROCHIP_DW_MIPI_DSI
> >> + tristate "Microchip specific extensions for Synopsys DW MIPI DSI"
> >> + depends on DRM_ATMEL_HLCDC
> >> + select DRM_DW_MIPI_DSI
> >> + help
> >> + This selects support for Microchip's SoC specific extensions
> >> + for the Synopsys DesignWare dsi driver.
> >> +
> >> config DRM_NWL_MIPI_DSI
> >>tristate "Northwest Logic MIPI DSI Host controller"
> >>depends on DRM
> >> diff --git a/drivers/gpu/drm/bridge/Makefile
> >> b/drivers/gpu/drm/bridge/Makefile
> >> index 3daf803ce80b..32e4233e6b5e 100644
> >> --- a/drivers/gpu/drm/bridge/Makefile
> >> +++ b/drivers/gpu/drm/bridge/Makefile
> >> @@ -14,6 +14,7 @@ obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) +=
> >> lontium-lt9611uxc.o
> >> obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> >> obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> >> megachips-stdp-ge-b850v3-fw.o
> >> obj-$(CONFIG_DRM_MICROCHIP_LVDS_SERIALIZER) += microchip-lvds.o
> >> +obj-$(CONFIG_DRM_MICROCHIP_DW_MIPI_DSI) += dw-mipi-dsi-mchp.o
> >> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> >> obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> >> obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
> >> diff --git a/drivers/gpu/drm/bridge/dw-mipi-dsi-mchp.c
> >> b/drivers/gpu/drm/bridge/dw-mipi-dsi-mchp.c
> >> new file mode 100644
> >> index ..35cfca1ff000
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/bridge/dw-mipi-dsi-mchp.c
> >> @@ -0,0 +1,545 @@
> >> +// SPDX-License-Identifier: GPL-2.0-only
> >> +/*
> >> + * Copyright (C) 2024 Microchip Technology Inc. and its subsidiaries
> >> + *
> >> + * Author: Manikandan Muralidharan
> >> + *
> >> + */
> >> +
> >
> > [...]
> >
> >> +
> >> +static int dw_mipi_dsi_mchp_get_lane_mbps(void *priv_data,
> >> + const struct drm_display_mode
> >> *mode,
> >> + unsigned long mode_flags, u32
> >> lanes,
> >> + u32 format, unsigned int
> >> *lane_mbps)
> >> +{
> >> + struct dw_mipi_dsi_mchp *dsi = priv_data;
> >> + unsigned long best_freq, fvco_min, fvco_max, fin, fout;
> >> + unsigned long min_delta = ULONG_MAX, delta;
> >> + unsigned int target_mbps = 0, mpclk, desired_mbps;
> >> + unsigned int max_mbps = dppa_map[ARRAY_SIZE(dppa_map) - 1].max_mbps;
> >> + unsigned int min_prediv, max_prediv;
> >> + unsigned int _fbdiv, best_fbdiv, _prediv, best_prediv;
> >> + int bpp;
> >> + u64 freq_factor;
> >
> > This function is significantly overlapping with dw_mipi_dsi_get_lane_mbps().
> > Please extract a common helper and add it to dw-mipi-dsi.c. Other than
> > that, LGTM.
> >
> I find it difficult to understand your concern.
> The dw_mipi_dsi_mchp_get_lane_mbps() is the .get_lane_mbps phy_op
> specific to Microchip DSI wrapper. The dw_mipi_dsi_get_lane_mbps
> functionalities across different SoC wrapper is not the same to extract
> a common helper.
Ok, somebody didn't do a proper prefix naming. I was looking at
dw_mipi_dsi_get_lane_mbps() from dw-mipi-dsi-rockchip.c. It looks
pretty close to your code.
> >> +
> >> + dsi->format = format;
> >> + bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> >> +
Re: [PATCH 4/5] drm/msm/dpu: Add SA8775P support
On 9/24/2024 5:46 PM, Dmitry Baryshkov wrote:
On Tue, Sep 24, 2024 at 04:42:02PM GMT, Mahadevan P wrote:
On 9/12/2024 1:34 PM, Dmitry Baryshkov wrote:
On Thu, Sep 12, 2024 at 12:44:36PM GMT, Mahadevan wrote:
Add definitions for the display hardware used on the
Qualcomm SA8775P platform.
Signed-off-by: Mahadevan
---
.../msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h | 485 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 3 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 3 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +-
4 files changed, 491 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h
[...]
+static const struct dpu_intf_cfg sa8775p_intf[] = {
+ {
+ .name = "intf_0", .id = INTF_0,
+ .base = 0x34000, .len = 0x280,
+ .features = INTF_SC7280_MASK,
+ .type = INTF_DP,
+ .controller_id = MSM_DP_CONTROLLER_0,
+ .prog_fetch_lines_worst_case = 24,
+ .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
+ .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25),
+ }, {
+ .name = "intf_1", .id = INTF_1,
+ .base = 0x35000, .len = 0x300,
+ .features = INTF_SC7280_MASK,
+ .type = INTF_DSI,
+ .controller_id = MSM_DSI_CONTROLLER_0,
+ .prog_fetch_lines_worst_case = 24,
+ .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
+ .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
+ .intr_tear_rd_ptr = DPU_IRQ_IDX(MDP_INTF1_TEAR_INTR, 2),
+ }, {
+ .name = "intf_2", .id = INTF_2,
+ .base = 0x36000, .len = 0x300,
+ .features = INTF_SC7280_MASK,
+ .type = INTF_DSI,
+ .controller_id = MSM_DSI_CONTROLLER_1,
+ .prog_fetch_lines_worst_case = 24,
+ .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
+ .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29),
+ .intr_tear_rd_ptr = DPU_IRQ_IDX(MDP_INTF2_TEAR_INTR, 2),
+ }, {
+ .name = "intf_3", .id = INTF_3,
+ .base = 0x37000, .len = 0x280,
+ .features = INTF_SC7280_MASK,
+ .type = INTF_NONE,
+ .controller_id = MSM_DP_CONTROLLER_0, /* pair with intf_0 for
DP MST */
+ .prog_fetch_lines_worst_case = 24,
+ .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 30),
+ .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 31),
+ }, {
+ .name = "intf_4", .id = INTF_4,
+ .base = 0x38000, .len = 0x280,
+ .features = INTF_SC7280_MASK,
+ .type = INTF_DP,
+ .controller_id = MSM_DP_CONTROLLER_1,
+ .prog_fetch_lines_worst_case = 24,
+ .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 20),
+ .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 21),
+ }, {
Where is intf_5 ?
intf_5 of base address 0x39000 is not supported on this target.
Not supported by whom?
In sa8775p mdss architecture intf_5 is not present. So we are not adding
in SW too.
+ .name = "intf_6", .id = INTF_6,
+ .base = 0x3A000, .len = 0x280,
+ .features = INTF_SC7280_MASK,
+ .type = INTF_NONE,
+ .controller_id = MSM_DP_CONTROLLER_0, /* pair with intf_0 for
DP MST */
+ .prog_fetch_lines_worst_case = 24,
+ .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 17),
+ .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 16),
+ }, {
[skipped]
@@ -1464,6 +1464,7 @@ static const struct of_device_id dpu_dt_match[] = {
{ .compatible = "qcom,sm8250-dpu", .data = &dpu_sm8250_cfg, },
{ .compatible = "qcom,sm8350-dpu", .data = &dpu_sm8350_cfg, },
{ .compatible = "qcom,sm8450-dpu", .data = &dpu_sm8450_cfg, },
+ { .compatible = "qcom,sa8775p-dpu", .data = &dpu_sa8775p_cfg, },
Wrong sorting order
Sure will move below sm8650-dpu.
What makes you think that in a dictionary sa8775p comes after sm8650?
Will update according to alphabetical order in next patch.
{ .compatible = "qcom,sm8550-dpu", .data = &dpu_sm8550_cfg, },
{ .compatible = "qcom,sm8650-dpu", .data = &dpu_sm8650_cfg, },
{ .compatible = "qcom,x1e80100-dpu", .data = &dpu_x1e80100_cfg, },
--
2.34.1
Re: Time for drm-ci-next?
Hi,
On 12/09/24 11:18, Dmitry Baryshkov wrote:
On Mon, Sep 09, 2024 at 07:34:04AM GMT, Rob Clark wrote:
On Mon, Sep 9, 2024 at 2:54 AM Dmitry Baryshkov
wrote:
On Mon, 9 Sept 2024 at 10:50, Maxime Ripard wrote:
Hi,
On Tue, Jul 09, 2024 at 01:27:51AM GMT, Dmitry Baryshkov wrote:
On Mon, 8 Jul 2024 at 21:38, Rob Clark wrote:
On Mon, Jul 8, 2024 at 1:52 AM Daniel Vetter wrote:
On Fri, Jul 05, 2024 at 12:31:36PM -0700, Rob Clark wrote:
On Fri, Jul 5, 2024 at 3:36 AM Daniel Vetter wrote:
On Thu, Jul 04, 2024 at 08:40:26AM -0700, Rob Clark wrote:
On Thu, Jul 4, 2024 at 7:08 AM Daniel Vetter wrote:
On Tue, Jul 02, 2024 at 05:32:39AM -0700, Rob Clark wrote:
On Fri, Jun 28, 2024 at 10:44 AM Daniel Vetter wrote:
On Thu, Jun 27, 2024 at 11:51:37AM -0700, Rob Clark wrote:
On Wed, Jun 26, 2024 at 10:47 AM Daniel Vetter wrote:
On Wed, Jun 26, 2024 at 11:38:30AM +0300, Dmitry Baryshkov wrote:
On Wed, Jun 26, 2024 at 09:32:44AM GMT, Daniel Vetter wrote:
On Mon, Jun 24, 2024 at 10:25:25AM -0300, Helen Koike wrote:
On 24/06/2024 02:34, Vignesh Raman wrote:
Hi,
On 15/03/24 22:50, Rob Clark wrote:
Basically, I often find myself needing to merge CI patches on top of
msm-next in order to run CI, and then after a clean CI run, reset HEAD
back before the merge and force-push. Which isn't really how things
should work.
This sounds more like you want an integration tree like drm-tip. Get msm
branches integrated there, done. Backmerges just for integration testing
are not a good idea indeed.
But AFAIU this doesn't help for pre-merge testing, ie. prior to a
patch landing in msm-next
My idea was to have a drm-ci-next managed similar to drm-misc-next, if
we have needed drm/ci patches we could push them to drm-ci-next, and
then merge that into the driver tree (along with a PR from drm-ci-next
to Dave).
I guess I'm confused about what kind of pre-merge testing we're talking
about then ... Or maybe this just doesn't work too well with the linux
kernel. The model is that you have some pile of trees, they're split up,
and testing of all the trees together is done in integration trees like
linux-next or drm-tip.
pre-merge: for msm we've been collecting up patches from list into a
fast-forward MR which triggers CI before merging to msm-next/msm-fixes
Ideally drm-misc and other trees would do similar, we'd catch more
regressions that way. For example, in msm-next the nodebugfs build is
currently broken, because we merged drm-misc-next at a time when
komeda was broken:
https://gitlab.freedesktop.org/drm/msm/-/jobs/60575681#L9520
If drm-misc was using pre-merge CI this would have been caught and the
offending patch dropped.
That sounds more like we should push on the drm-misc pre-merge CI boulder
to move it uphill, than add even more trees to make it even harder to get
there long term ...
Short term it helps locally to have finer trees, but only short term and
only very locally.
The path to have fewer trees (ideally only one for all of drm) is to
use gitlab MRs to land everything :-)
drm-ci-next is only a stop-gap.. but one that we need. The
${branchname}-external-fixes trick covers _most_ cases where we need
unrelated patches (ie. to fix random ToT breakage outside of drm or in
core drm), but it doesn't help when the needed changes are yml
(because gitlab processes all the yml before merging the
-external-fixes branch). This is where we need drm-ci-next, otherwise
we are having to create a separate MR which cherry-picks drm/ci
patches for doing the CI. This is a rather broken process.
So what I don't get is ... if we CI drm-misc, how does that not help
improve the situation here? Step one would be post-merge (i.e. just enable
CI in the repo), then get MRs going.
I guess post-merge is better than nothing.. but pre-merge is better.
post-merge can work if you have a "sheriff" system where someone
(perhaps on a rotation) is actively monitoring results and "revert and
ask questions later" when something breaks. Pre-merge ensures the
interested party is involved in the process ;-)
So ... make that happen? And it doesn't have to be for all of drm-misc,
mesa after all switched over to MR also on a bit a driver/area basis. So
agreeing among all drm-ci folks to use gitlab MR in drm-misc for pre-merge
testing shouldn't be that hard to make happen. And unlike a separate
branch it's not some kind of detour with a good chance to get stuck in a
local optimum.
Tree vs branch doesn't really have much in the way of distinction,
modulo gitlab permissions. In that it doesn't do much good if drm/ci
patches are landing on a different branch.
I guess what you are suggesting is that we have a single tree/branch
that drm/ci + drm/msm + (plus whoever else wants to get in on the
drm/ci, so probably at least vkms) lands patches into via gitlab MRs?
This again brings a separate CI-enabled tree. I think it has been
suggested to start with enabling DRM CI for drm-misc branches. Then we
can possibly
Re: radeon ARUBA NULL pointer dereference
(cc: DMA and x86 folks) Hi Am 24.09.24 um 04:08 schrieb Arthur Marsh: Using current Linus git head kernel, I was able to save the dmesg output: [ 17.218724] [drm] radeon kernel modesetting enabled. [ 17.218778] radeon :00:01.0: vgaarb: deactivate vga console [ 17.219509] Console: switching to colour dummy device 80x25 [ 17.219700] [drm] initializing kernel modesetting (ARUBA 0x1002:0x990C 0x1002:0x0123 0x00). [ 17.219773] ATOM BIOS: 113 [ 17.219838] radeon :00:01.0: VRAM: 768M 0x - 0x2FFF (768M used) [ 17.219841] radeon :00:01.0: GTT: 1024M 0x3000 - 0x6FFF [ 17.219844] [drm] Detected VRAM RAM=768M, BAR=256M [ 17.219845] [drm] RAM width 64bits DDR [ 17.219851] BUG: kernel NULL pointer dereference, address: 00a0 This is 160 bytes behind NULL, which indicates a field within a struct. [ 17.219852] #PF: supervisor read access in kernel mode [ 17.219853] #PF: error_code(0x) - not-present page [ 17.219854] PGD 0 P4D 0 [ 17.219856] Oops: Oops: [#1] PREEMPT_RT SMP NOPTI [ 17.219858] CPU: 0 UID: 0 PID: 451 Comm: udevd Not tainted 6.11.0+ #6121 [ 17.219860] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./F2A78M-HD2, BIOS F2 05/28/2014 [ 17.219862] RIP: 0010:dma_get_required_mask+0x11/0x50 [ 17.219868] Code: 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 8b 87 68 02 00 00 48 85 c0 74 11 <48> 8b 80 a0 00 00 00 48 85 c0 74 1f e9 ee ed 94 00 f6 87 2c 03 00 [ 17.219870] RSP: 0018:a54bc13a7b00 EFLAGS: 00010202 [ 17.219871] RAX: RBX: 00ff RCX: [ 17.219872] RDX: RSI: 0027 RDI: 976f44e720c8 [ 17.219873] RBP: 976f44e720c8 R08: efff R09: ab2aab08 [ 17.219874] R10: f000 R11: 0002 R12: [ 17.219875] R13: 976f48a4aa30 R14: R15: 0028 [ 17.219876] FS: 7f59a070d840() GS:97726f80() knlGS: [ 17.219878] CS: 0010 DS: ES: CR0: 80050033 [ 17.219879] CR2: 00a0 CR3: 0001053b4000 CR4: 000406f0 [ 17.219880] Call Trace: [ 17.219881] [ 17.219882] ? __die_body.cold+0x19/0x1e [ 17.219885] ? page_fault_oops+0xa8/0x230 [ 17.219889] ? search_module_extables+0x4f/0x90 [ 17.219891] ? fixup_exception+0x36/0x2f0 [ 17.219894] ? exc_page_fault+0x88/0x1b0 [ 17.219897] ? asm_exc_page_fault+0x22/0x30 [ 17.219900] ? dma_get_required_mask+0x11/0x50 This is not in the radeon driver but the DMA code. I'd say it's at [1], as get_required_mask is 160 bytes within struct drm_map_ops. The call to get_arch_dma_ops() probably returns NULL. Best regards Thomas [1] https://elixir.bootlin.com/linux/v6.11/source/kernel/dma/mapping.c#L523 [2] https://elixir.bootlin.com/linux/v6.11/source/include/linux/dma-map-ops.h#L98 [ 17.219902] dma_addressing_limited+0x6c/0xb0 [ 17.219905] radeon_ttm_init+0x3f/0x210 [radeon] [ 17.219977] cayman_init+0x97/0x290 [radeon] [ 17.220057] radeon_device_init+0x5e9/0xb40 [radeon] [ 17.220115] radeon_driver_load_kms+0xb0/0x260 [radeon] [ 17.220174] radeon_pci_probe+0xff/0x170 [radeon] [ 17.220231] pci_device_probe+0xbe/0x1a0 [ 17.220234] really_probe+0xde/0x350 [ 17.220237] ? pm_runtime_barrier+0x61/0xb0 [ 17.220240] ? __pfx___driver_attach+0x10/0x10 [ 17.220242] __driver_probe_device+0x78/0x110 [ 17.220245] driver_probe_device+0x2d/0xc0 [ 17.220247] __driver_attach+0xc9/0x1c0 [ 17.220249] bus_for_each_dev+0x6a/0xb0 [ 17.220251] ? migrate_enable+0xbf/0xf0 [ 17.220254] bus_add_driver+0x139/0x220 [ 17.220256] driver_register+0x6e/0xc0 [ 17.220258] ? __pfx_radeon_module_init+0x10/0x10 [radeon] [ 17.220315] do_one_initcall+0x42/0x210 [ 17.220318] ? __kmalloc_cache_noprof+0x89/0x230 [ 17.220321] do_init_module+0x60/0x210 [ 17.220324] init_module_from_file+0x89/0xc0 [ 17.220326] __x64_sys_finit_module+0x142/0x390 [ 17.220329] do_syscall_64+0x47/0x110 [ 17.220331] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 17.220334] RIP: 0033:0x7f59a0625279 [ 17.220336] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 77 6b 0d 00 f7 d8 64 89 01 48 [ 17.220337] RSP: 002b:7ffd15ee7df8 EFLAGS: 0246 ORIG_RAX: 0139 [ 17.220339] RAX: ffda RBX: 5578ae660840 RCX: 7f59a0625279 [ 17.220340] RDX: RSI: 5578ae677fc0 RDI: 0011 [ 17.220341] RBP: R08: 7f59a06fcb20 R09: 5578ae640550 [ 17.220342] R10: 0040 R11: 0246 R12: 5578ae677fc0 [ 17.220342] R13: 0002 R14: 5578ae651750 R15: [ 17.220344] [ 17.220345]
Re: [PATCH 4/5] drm/msm/dpu: Add SA8775P support
On Tue, Sep 24, 2024 at 04:42:02PM GMT, Mahadevan P wrote:
>
> On 9/12/2024 1:34 PM, Dmitry Baryshkov wrote:
> > On Thu, Sep 12, 2024 at 12:44:36PM GMT, Mahadevan wrote:
> > > Add definitions for the display hardware used on the
> > > Qualcomm SA8775P platform.
> > >
> > > Signed-off-by: Mahadevan
> > > ---
> > > .../msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h | 485 ++
> > > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 3 +-
> > > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 3 +-
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +-
> > > 4 files changed, 491 insertions(+), 3 deletions(-)
> > > create mode 100644
> > > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h
> > >
[...]
> > > +static const struct dpu_intf_cfg sa8775p_intf[] = {
> > > + {
> > > + .name = "intf_0", .id = INTF_0,
> > > + .base = 0x34000, .len = 0x280,
> > > + .features = INTF_SC7280_MASK,
> > > + .type = INTF_DP,
> > > + .controller_id = MSM_DP_CONTROLLER_0,
> > > + .prog_fetch_lines_worst_case = 24,
> > > + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
> > > + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25),
> > > + }, {
> > > + .name = "intf_1", .id = INTF_1,
> > > + .base = 0x35000, .len = 0x300,
> > > + .features = INTF_SC7280_MASK,
> > > + .type = INTF_DSI,
> > > + .controller_id = MSM_DSI_CONTROLLER_0,
> > > + .prog_fetch_lines_worst_case = 24,
> > > + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
> > > + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
> > > + .intr_tear_rd_ptr = DPU_IRQ_IDX(MDP_INTF1_TEAR_INTR, 2),
> > > + }, {
> > > + .name = "intf_2", .id = INTF_2,
> > > + .base = 0x36000, .len = 0x300,
> > > + .features = INTF_SC7280_MASK,
> > > + .type = INTF_DSI,
> > > + .controller_id = MSM_DSI_CONTROLLER_1,
> > > + .prog_fetch_lines_worst_case = 24,
> > > + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
> > > + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29),
> > > + .intr_tear_rd_ptr = DPU_IRQ_IDX(MDP_INTF2_TEAR_INTR, 2),
> > > + }, {
> > > + .name = "intf_3", .id = INTF_3,
> > > + .base = 0x37000, .len = 0x280,
> > > + .features = INTF_SC7280_MASK,
> > > + .type = INTF_NONE,
> > > + .controller_id = MSM_DP_CONTROLLER_0, /* pair with intf_0 for
> > > DP MST */
> > > + .prog_fetch_lines_worst_case = 24,
> > > + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 30),
> > > + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 31),
> > > + }, {
> > > + .name = "intf_4", .id = INTF_4,
> > > + .base = 0x38000, .len = 0x280,
> > > + .features = INTF_SC7280_MASK,
> > > + .type = INTF_DP,
> > > + .controller_id = MSM_DP_CONTROLLER_1,
> > > + .prog_fetch_lines_worst_case = 24,
> > > + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 20),
> > > + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 21),
> > > + }, {
> > Where is intf_5 ?
>
>
> intf_5 of base address 0x39000 is not supported on this target.
Not supported by whom?
>
>
> >
> > > + .name = "intf_6", .id = INTF_6,
> > > + .base = 0x3A000, .len = 0x280,
> > > + .features = INTF_SC7280_MASK,
> > > + .type = INTF_NONE,
> > > + .controller_id = MSM_DP_CONTROLLER_0, /* pair with intf_0 for
> > > DP MST */
> > > + .prog_fetch_lines_worst_case = 24,
> > > + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 17),
> > > + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 16),
> > > + }, {
[skipped]
> > > @@ -1464,6 +1464,7 @@ static const struct of_device_id dpu_dt_match[] = {
> > > { .compatible = "qcom,sm8250-dpu", .data = &dpu_sm8250_cfg, },
> > > { .compatible = "qcom,sm8350-dpu", .data = &dpu_sm8350_cfg, },
> > > { .compatible = "qcom,sm8450-dpu", .data = &dpu_sm8450_cfg, },
> > > + { .compatible = "qcom,sa8775p-dpu", .data = &dpu_sa8775p_cfg, },
> > Wrong sorting order
>
>
> Sure will move below sm8650-dpu.
What makes you think that in a dictionary sa8775p comes after sm8650?
>
>
> >
> > > { .compatible = "qcom,sm8550-dpu", .data = &dpu_sm8550_cfg, },
> > > { .compatible = "qcom,sm8650-dpu", .data = &dpu_sm8650_cfg, },
> > > { .compatible = "qcom,x1e80100-dpu", .data = &dpu_x1e80100_cfg,
> > > },
> > > --
> > > 2.34.1
> > >
--
With best wishes
Dmitry
Re: [PATCH 4/5] drm/msm/dpu: Add SA8775P support
On 9/24/2024 4:42 PM, Mahadevan P wrote:
On 9/12/2024 1:34 PM, Dmitry Baryshkov wrote:
On Thu, Sep 12, 2024 at 12:44:36PM GMT, Mahadevan wrote:
Add definitions for the display hardware used on the
Qualcomm SA8775P platform.
Signed-off-by: Mahadevan
---
.../msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h | 485
++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 3 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +-
4 files changed, 491 insertions(+), 3 deletions(-)
create mode 100644
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h
new file mode 100644
index ..14d65b5d4093
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h
@@ -0,0 +1,485 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights
reserved.
+ * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights
reserved.
+ */
+
+#ifndef _DPU_8_4_SA8775P_H
+#define _DPU_8_4_SA8775P_H
+
+static const struct dpu_caps sa8775p_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0xb,
+ .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_mdp_cfg sa8775p_mdp = {
+ .name = "top_0",
+ .base = 0x0, .len = 0x494,
+ .features = BIT(DPU_MDP_PERIPH_0_REMOVED),
+ .clk_ctrls = {
+ [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
+ [DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0 },
+ [DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0 },
+ [DPU_CLK_CTRL_VIG3] = { .reg_off = 0x2c4, .bit_off = 0 },
+ [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
+ [DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
+ [DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2bc, .bit_off = 8 },
+ [DPU_CLK_CTRL_DMA3] = { .reg_off = 0x2c4, .bit_off = 8 },
+ [DPU_CLK_CTRL_WB2] = { .reg_off = 0x2bc, .bit_off = 16 },
+ [DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
+ },
+};
+
+/* FIXME: get rid of DPU_CTL_SPLIT_DISPLAY in favour of proper
ACTIVE_CTL support */
+static const struct dpu_ctl_cfg sa8775p_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x15000, .len = 0x204,
+ .features = BIT(DPU_CTL_SPLIT_DISPLAY) | CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ }, {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x16000, .len = 0x204,
+ .features = BIT(DPU_CTL_SPLIT_DISPLAY) | CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+ }, {
+ .name = "ctl_2", .id = CTL_2,
+ .base = 0x17000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
+ }, {
+ .name = "ctl_3", .id = CTL_3,
+ .base = 0x18000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
+ }, {
+ .name = "ctl_4", .id = CTL_4,
+ .base = 0x19000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
+ }, {
+ .name = "ctl_5", .id = CTL_5,
+ .base = 0x1a000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 23),
+ },
+};
+
+static const struct dpu_sspp_cfg sa8775p_sspp[] = {
+ {
+ .name = "sspp_0", .id = SSPP_VIG0,
+ .base = 0x4000, .len = 0x32c,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = &dpu_vig_sblk_qseed3_3_1,
+ .xin_id = 0,
+ .type = SSPP_TYPE_VIG,
+ .clk_ctrl = DPU_CLK_CTRL_VIG0,
+ }, {
+ .name = "sspp_1", .id = SSPP_VIG1,
+ .base = 0x6000, .len = 0x32c,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = &dpu_vig_sblk_qseed3_3_1,
+ .xin_id = 4,
+ .type = SSPP_TYPE_VIG,
+ .clk_ctrl = DPU_CLK_CTRL_VIG1,
+ }, {
+ .name = "sspp_2", .id = SSPP_VIG2,
+ .base = 0x8000, .len = 0x32c,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = &dpu_vig_sblk_qseed3_3_1,
+ .xin_id = 8,
+ .type = SSPP_TYPE_VIG,
+ .clk_ctrl = DPU_CLK_CTRL_VIG2,
+ }, {
+ .name = "sspp_3", .id = SSPP_VIG3,
+ .base = 0xa000, .len = 0x32c,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = &dpu_vig_sblk_qseed3_3_1,
+ .xin_id = 12,
+ .type = SSPP_TYPE_VIG,
+ .clk_ctrl = DPU_CLK_CTRL_VIG3,
+ }, {
+ .name = "sspp_8", .id = SSPP_DMA0,
+ .base = 0x24000, .len = 0x32c,
+ .features = DMA_SDM845_MASK_SDMA,
+
Re: [PATCH] drm: Add check for encoder in intel_get_crtc_new_encoder()
On Tue, 24 Sep 2024, Jani Nikula wrote:
> On Tue, 24 Sep 2024, George Rurikov wrote:
>> If the video card driver could not find the connector assigned to the
>> current video controller, or if the hardware status has changed so that
>> a pre-existing connector is no longer active, none of the state
>> connectors will meet the assignment criteria for the current crtc video
>> controller.
>>
>> In the drm_WARN function, encoder->base.dev is called, so
>> '&encoder->base.dev' will be dereferenced since encoder will still be
>> initialized NULL.
>
> encoder is not dereferenced there.
Looks like the issue was there ages ago, and was fixed in v6.5 by commit
3b6692357f70 ("drm/i915: Make intel_get_crtc_new_encoder() less oopsy").
Please run your analysis on recent kernels.
BR,
Jani.
>
>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>
>> Fixes: e12d6218fda2 ("drm/i915: Reduce bigjoiner special casing")
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: George Rurikov
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index b4ef4d59da1a..1f25b12e5f67 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -819,9 +819,11 @@ intel_get_crtc_new_encoder(const struct
>> intel_atomic_state *state,
>> num_encoders++;
>> }
>>
>> - drm_WARN(state->base.dev, num_encoders != 1,
>> + if (encoder) {
>> + drm_WARN(state->base.dev, num_encoders != 1,
>> "%d encoders for pipe %c\n",
>> num_encoders, pipe_name(primary_crtc->pipe));
>> + }
>>
>> return encoder;
>> }
>> --
>> 2.34.1
>>
>> Заявление о конфиденциальности
>>
>> Данное электронное письмо и любые приложения к нему являются
>> конфиденциальными и предназначены исключительно для адресата. Если Вы не
>> являетесь адресатом данного письма, пожалуйста, уведомите немедленно
>> отправителя, не раскрывайте содержание другим лицам, не используйте его в
>> каких-либо целях, не храните и не копируйте информацию любым способом.
>
> Sorry, we can't accept patches with that boilerplate anyway.
>
> BR,
> Jani.
--
Jani Nikula, Intel
Re: [PATCH] drm: Add check for encoder in intel_get_crtc_new_encoder()
On Tue, 24 Sep 2024, George Rurikov wrote:
> If the video card driver could not find the connector assigned to the
> current video controller, or if the hardware status has changed so that
> a pre-existing connector is no longer active, none of the state
> connectors will meet the assignment criteria for the current crtc video
> controller.
>
> In the drm_WARN function, encoder->base.dev is called, so
> '&encoder->base.dev' will be dereferenced since encoder will still be
> initialized NULL.
encoder is not dereferenced there.
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: e12d6218fda2 ("drm/i915: Reduce bigjoiner special casing")
> Cc: sta...@vger.kernel.org
> Signed-off-by: George Rurikov
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b4ef4d59da1a..1f25b12e5f67 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -819,9 +819,11 @@ intel_get_crtc_new_encoder(const struct
> intel_atomic_state *state,
> num_encoders++;
> }
>
> - drm_WARN(state->base.dev, num_encoders != 1,
> + if (encoder) {
> + drm_WARN(state->base.dev, num_encoders != 1,
> "%d encoders for pipe %c\n",
> num_encoders, pipe_name(primary_crtc->pipe));
> + }
>
> return encoder;
> }
> --
> 2.34.1
>
> Заявление о конфиденциальности
>
> Данное электронное письмо и любые приложения к нему являются
> конфиденциальными и предназначены исключительно для адресата. Если Вы не
> являетесь адресатом данного письма, пожалуйста, уведомите немедленно
> отправителя, не раскрывайте содержание другим лицам, не используйте его в
> каких-либо целях, не храните и не копируйте информацию любым способом.
Sorry, we can't accept patches with that boilerplate anyway.
BR,
Jani.
--
Jani Nikula, Intel
Re: [PATCH v2] drm/sched: Further optimise drm_sched_entity_push_job
Am 24.09.24 um 11:58 schrieb Tvrtko Ursulin:
On 24/09/2024 10:45, Tvrtko Ursulin wrote:
On 24/09/2024 09:20, Christian König wrote:
Am 16.09.24 um 19:30 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Having removed one re-lock cycle on the entity->lock in a patch titled
"drm/sched: Optimise drm_sched_entity_push_job", with only a tiny bit
larger refactoring we can do the same optimisation on the rq->lock.
(Currently both drm_sched_rq_add_entity() and
drm_sched_rq_update_fifo_locked() take and release the same lock.)
To achieve this we make drm_sched_rq_update_fifo_locked() and
drm_sched_rq_add_entity() expect the rq->lock to be held.
We also align drm_sched_rq_update_fifo_locked(),
drm_sched_rq_add_entity() and
drm_sched_rq_remove_fifo_locked() function signatures, by adding rq
as a
parameter to the latter.
v2:
* Fix after rebase of the series.
* Avoid naming incosistency between drm_sched_rq_add/remove.
(Christian)
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: Philipp Stanner
Reviewed-by: Christian König
Thanks!
Are you okay to pull into drm-misc-next or we should do some more
testing on this?
And/or should I resend the series once more in it's entirety so this
v2 is not a reply-to to the original?
I have to respin for the drm_sched_wakeup fix that landed.
When I should push the series to drm-misc-next then please send it to me
once more.
On the other hand we should now have to maintainers for that.
Regards,
Christian.
Regards,
Tvrtko
Regards,
Tvrtko
---
drivers/gpu/drm/scheduler/sched_entity.c | 12 --
drivers/gpu/drm/scheduler/sched_main.c | 29
include/drm/gpu_scheduler.h | 3 ++-
3 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index d982cebc6bee..8ace1f1ea66b 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -515,9 +515,14 @@ struct drm_sched_job
*drm_sched_entity_pop_job(struct drm_sched_entity *entity)
next =
to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
if (next) {
+ struct drm_sched_rq *rq;
+
spin_lock(&entity->lock);
- drm_sched_rq_update_fifo_locked(entity,
+ rq = entity->rq;
+ spin_lock(&rq->lock);
+ drm_sched_rq_update_fifo_locked(entity, rq,
next->submit_ts);
+ spin_unlock(&rq->lock);
spin_unlock(&entity->lock);
}
}
@@ -618,11 +623,14 @@ void drm_sched_entity_push_job(struct
drm_sched_job *sched_job)
sched = rq->sched;
atomic_inc(sched->score);
+
+ spin_lock(&rq->lock);
drm_sched_rq_add_entity(rq, entity);
if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
- drm_sched_rq_update_fifo_locked(entity, submit_ts);
+ drm_sched_rq_update_fifo_locked(entity, rq, submit_ts);
+ spin_unlock(&rq->lock);
spin_unlock(&entity->lock);
drm_sched_wakeup(sched, entity);
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 18a952f73ecb..5c83fb92bb89 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -153,17 +153,18 @@ static __always_inline bool
drm_sched_entity_compare_before(struct rb_node *a,
return ktime_before(ent_a->oldest_job_waiting,
ent_b->oldest_job_waiting);
}
-static inline void drm_sched_rq_remove_fifo_locked(struct
drm_sched_entity *entity)
+static void drm_sched_rq_remove_fifo_locked(struct
drm_sched_entity *entity,
+ struct drm_sched_rq *rq)
{
- struct drm_sched_rq *rq = entity->rq;
-
if (!RB_EMPTY_NODE(&entity->rb_tree_node)) {
rb_erase_cached(&entity->rb_tree_node, &rq->rb_tree_root);
RB_CLEAR_NODE(&entity->rb_tree_node);
}
}
-void drm_sched_rq_update_fifo_locked(struct drm_sched_entity
*entity, ktime_t ts)
+void drm_sched_rq_update_fifo_locked(struct drm_sched_entity *entity,
+ struct drm_sched_rq *rq,
+ ktime_t ts)
{
/*
* Both locks need to be grabbed, one to protect from
entity->rq change
@@ -171,17 +172,14 @@ void drm_sched_rq_update_fifo_locked(struct
drm_sched_entity *entity, ktime_t ts
* other to update the rb tree structure.
*/
lockdep_assert_held(&entity->lock);
+ lockdep_assert_held(&rq->lock);
- spin_lock(&entity->rq->lock);
-
- drm_sched_rq_remove_fifo_locked(entity);
+ drm_sched_rq_remove_fifo_locked(entity, rq);
entity->oldest_job_waiting = ts;
- rb_add_cached
Re: [PATCH] drm/vc4: Fix atomicity violation in vc4_crtc_send_vblank()
Hi, In the drm_device structure, it is mentioned: "@event_lock: Protects @vblank_event_list and event delivery in general." I believe that the validity check and the subsequent null assignment operation are part of the event delivery process, and all of these should be protected by the event_lock. If there is no lock protection before the validity check, it is possible for a null crtc->state->event to be passed into the drm_crtc_send_vblank_event() function, leading to a null pointer dereference error. We have observed its callers and found that they are from the drm_crtc_helper_funcs driver interface. We believe that functions within driver interfaces can be concurrent, potentially causing a data race on crtc->state->event. Qiu-ji Chen
Re: [PATCH 0/2] drm: revert some framebuffer API tests
+Guenter On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote: > On Tue, Sep 17, 2024 at 08:43:50PM +0300, Jani Nikula wrote: > > The tests consistently trigger WARNs in drm_framebuffer code. I'm not > > sure what the point is with type of belts and suspenders tests. The > > warnings *are* the way to flag erroneous API usage. > > > > Warnings in turn trigger failures in CI. Filtering the warnings are > > error prone, and, crucially, would also filter actual errors in case the > > kunit tests are not run. > > > > I acknowledge there may be complex test cases where you'd end up > > triggering warnings somewhere deep, but these are not it. These are > > simple. > > > > Revert the tests, back to the drawing board. > > Yeah I think long-term we might want a kunit framework so that we can > catch dmesg warnings we expect and test for those, without those warnings > actually going to dmesg. Similar to how the lockdep tests also reroute > locking validation, so that the expected positive tests don't wreak > lockdep for real. > > But until that exists, we can't have tests that splat in dmesg when they > work as intended. It should be pretty soon: https://lore.kernel.org/dri-devel/20240403131936.787234-1-li...@roeck-us.net/ I'm not sure what happened to that series, but it looks like everybody was mostly happy with it? Maxime signature.asc Description: PGP signature
