Re: [Freedreno] [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
I'm facing similar issues with the tc358775 bridge. This bridge needs to release its reset while both clock and data lanes are in LP-11 mode. But then it needs to be configured (via I2C) while the clock lane is in enabled (HS mode), but the data lanes are still in LP-11 mode. This is quite an interesting requirement. For example, I'm not 100% sure whether we can get that done on our (msm) hosts. I need to double check that. What frequency is expected on the CLK lane? Can it be an arbitrary frequency or it should be the same freq as the one used later for the video transfer? I presume it has to be the same frequency as the video stream later. That's a least what I have successfully tested. The datasheet doesn't mention if a frequency switch is allowed on the clock lane (which would need a brief switch to LP mode, I presume). I'd say it's not allowed/supported as the bridge is very picky regarding the init sequence in general. I'm using the Mediatek DSI host, where that sequence is possible. I.e. you just enable the clock and data lanes in continuous clock mode, but don't enable the video stream, which should leave the data lanes in LP-11 mode. Sometimes you also have a command mode (instead of a video mode). And if you don't send any commands, the data lanes are in LP-11 mode, too. -michael Therefore, for the correct init sequence is: (1) dsi host enables lanes, that is clock and data are in lp-11 (2) dsi bridge driver releases reset of the bridge (3) dsi host enables clock lane, leaves data lanes in lp-11 (4) dsi bridge driver configures the bridge (5) dsi host enables the video stream (6) dsi bridge enables the output port of the bridge
Re: [Freedreno] [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
>> >> > DSI device lifetime has three different stages: >> >> > 1. before the DSI link being powered up and clocking, >> >> > 2. when the DSI link is in LP state (for the purpose of this question, >> >> > this is the time between the DSI link being powered up and the video >> >> > stream start) >> >> > 3. when the DSI link is in HS state (while streaming the video). >> >> >> >> It's not clear to me what (2) is. What is the state of the clock and >> >> data lanes? >> > >> > Clk an Data0 should be in the LP mode, ready for LP Data Transfer. >> >> Then this is somehow missing >> https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation >> >>A DSI host should keep the PHY powered down until the pre_enable >> operation >>is called. All lanes are in an undefined idle state up to this point, >> and >>it must not be assumed that it is LP-11. pre_enable should initialise >> the >>PHY, set the data lanes to LP-11, and the clock lane to either LP-11 >> or HS >>depending on the mode_flag MIPI_DSI_CLOCK_NON_CONTINUOUS. >> >> So I don't think these three states are sufficient, see below, that >> there >> should be at least four. > >Which one is #4? enabled clock lane (HS mode), data lanes in LP-11 What is the purpose of such a mode? To repeat my first mail: I'm facing similar issues with the tc358775 bridge. This bridge needs to release its reset while both clock and data lanes are in LP-11 mode. But then it needs to be configured (via I2C) while the clock lane is in enabled (HS mode), but the data lanes are still in LP-11 mode. Therefore, for the correct init sequence is: (1) dsi host enables lanes, that is clock and data are in lp-11 (2) dsi bridge driver releases reset of the bridge (3) dsi host enables clock lane, leaves data lanes in lp-11 (4) dsi bridge driver configures the bridge (5) dsi host enables the video stream (6) dsi bridge enables the output port of the bridge -michael >> > I don't think we support ULPS currently. >> > >> > >> >> >> >> I'm facing similar issues with the tc358775 bridge. This bridge needs >> >> to release its reset while both clock and data lanes are in LP-11 >> >> mode. >> >> But then it needs to be configured (via I2C) while the clock lane is >> >> in enabled (HS mode), but the data lanes are still in LP-11 mode. >> >> >> >> To me it looks like there is a fouth case then: >> >> 1. unpowered >> >> 2. DSI clock and data are in LP-11 >> >> 3. DSI clock is in HS and data are in LP-11 >> >> 4. DSI clock is in HS and data is in HS >> >> >> >> (And of course the bridge needs continuous clock mode). >> >> >> >> > Different DSI bridges have different requirements with respect to the >> >> > code being executed at stages 1 and 2. For example several DSI-to-eDP >> >> > bridges (ps8640, tc358767 require for the link to be quiet during >> >> > reset time. >> >> > The DSI-controlled bridges and DSI panels need to send some commands >> >> > in stage 2, before starting up video >> >> > >> >> > In the DRM subsystem stage 3 naturally maps to the >> >> > drm_bridge_funcs::enable, stage 1 also naturally maps to the >> >> > drm_bridge_funcs::pre_enable. Stage 2 doesn't have its own place in >> >> > the DRM call chain. >> >> > Earlier we attempted to solve that using the pre_enable_prev_first, >> >> > which remapped pre-enable callback execution order. However it has led >> >> > us to the two issues. First, at the DSI host driver we do not know >> >> > whether the panel / bridge were updated to use pre_enable_prev_first >> >> > or not. Second, if the bridge has to perform steps during both stages >> >> > 1 and 2, it can not do that. >> >> > >> >> > I'm trying to find a way to express the difference between stages 1 >> >> > and 2 in the generic code, so that we do not to worry about particular >> >> > DSI host and DSI bridge / panel peculiarities when implementing the >> >> > DSI host and/or DSI panel driver. >> >> >> >> For now, I have a rather hacky ".dsi_lp11_notify" callback in >> >> drm_bridge_funcs which is supposed to be called by the DSI host while >> >> the >> >> clock and data lanes are in LP-11 mode. But that is rather an RFC and >> >> me >> >> needing something to get the driver for this bridge working. Because >> >> it's >> >> badly broken. FWIW, you can find my work-in-progress patches at >> >> https://github.com/mwalle/linux/tree/feature-tc358775-fixes >> >> >> >> -michael >> >> >> > >> > >> > -- >> > With best wishes >> > Dmitry > > >
Re: [Freedreno] [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
On Wed, 29 Nov 2023 at 00:20, Michael Walle wrote: > > [sorry I fat fingered my former reply and converted all CCs to BCCs..] > > >> >> >> > DSI device lifetime has three different stages: > >> >> >> > 1. before the DSI link being powered up and clocking, > >> >> >> > 2. when the DSI link is in LP state (for the purpose of this > >> >> >> > question, > >> >> >> > this is the time between the DSI link being powered up and the > >> >> >> > video > >> >> >> > stream start) > >> >> >> > 3. when the DSI link is in HS state (while streaming the video). > >> >> >> > >> >> >> It's not clear to me what (2) is. What is the state of the clock and > >> >> >> data lanes? > >> >> > > >> >> > Clk an Data0 should be in the LP mode, ready for LP Data Transfer. > >> >> > >> >> Then this is somehow missing > >> >> https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation > >> >> > >> >>A DSI host should keep the PHY powered down until the pre_enable > >> >> operation > >> >>is called. All lanes are in an undefined idle state up to this point, > >> >> and > >> >>it must not be assumed that it is LP-11. pre_enable should initialise > >> >> the > >> >>PHY, set the data lanes to LP-11, and the clock lane to either LP-11 > >> >> or HS > >> >>depending on the mode_flag MIPI_DSI_CLOCK_NON_CONTINUOUS. > >> >> > >> >> So I don't think these three states are sufficient, see below, that > >> >> there > >> >> should be at least four. > >> > > >> >Which one is #4? > >> > >> enabled clock lane (HS mode), data lanes in LP-11 > > > > What is the purpose of such a mode? > > To repeat my first mail: Excuse me please, I either missed it, or forgot it. > > I'm facing similar issues with the tc358775 bridge. This bridge needs > to release its reset while both clock and data lanes are in LP-11 > mode. > But then it needs to be configured (via I2C) while the clock lane is > in enabled (HS mode), but the data lanes are still in LP-11 mode. This is quite an interesting requirement. For example, I'm not 100% sure whether we can get that done on our (msm) hosts. I need to double check that. What frequency is expected on the CLK lane? Can it be an arbitrary frequency or it should be the same freq as the one used later for the video transfer? > > Therefore, for the correct init sequence is: > (1) dsi host enables lanes, that is clock and data are in lp-11 > (2) dsi bridge driver releases reset of the bridge > (3) dsi host enables clock lane, leaves data lanes in lp-11 > (4) dsi bridge driver configures the bridge > (5) dsi host enables the video stream > (6) dsi bridge enables the output port of the bridge > > -michael > > >> >> > I don't think we support ULPS currently. > >> >> > > >> >> > > >> >> >> > >> >> >> I'm facing similar issues with the tc358775 bridge. This bridge needs > >> >> >> to release its reset while both clock and data lanes are in LP-11 > >> >> >> mode. > >> >> >> But then it needs to be configured (via I2C) while the clock lane is > >> >> >> in enabled (HS mode), but the data lanes are still in LP-11 mode. > >> >> >> > >> >> >> To me it looks like there is a fouth case then: > >> >> >> 1. unpowered > >> >> >> 2. DSI clock and data are in LP-11 > >> >> >> 3. DSI clock is in HS and data are in LP-11 > >> >> >> 4. DSI clock is in HS and data is in HS > >> >> >> > >> >> >> (And of course the bridge needs continuous clock mode). > >> >> >> > >> >> >> > Different DSI bridges have different requirements with respect to > >> >> >> > the > >> >> >> > code being executed at stages 1 and 2. For example several > >> >> >> > DSI-to-eDP > >> >> >> > bridges (ps8640, tc358767 require for the link to be quiet during > >> >> >> > reset time. > >> >> >> > The DSI-controlled bridges and DSI panels need to send some > >> >> >> > commands > >> >> >> > in stage 2, before starting up video > >> >> >> > > >> >> >> > In the DRM subsystem stage 3 naturally maps to the > >> >> >> > drm_bridge_funcs::enable, stage 1 also naturally maps to the > >> >> >> > drm_bridge_funcs::pre_enable. Stage 2 doesn't have its own place in > >> >> >> > the DRM call chain. > >> >> >> > Earlier we attempted to solve that using the pre_enable_prev_first, > >> >> >> > which remapped pre-enable callback execution order. However it has > >> >> >> > led > >> >> >> > us to the two issues. First, at the DSI host driver we do not know > >> >> >> > whether the panel / bridge were updated to use > >> >> >> > pre_enable_prev_first > >> >> >> > or not. Second, if the bridge has to perform steps during both > >> >> >> > stages > >> >> >> > 1 and 2, it can not do that. > >> >> >> > > >> >> >> > I'm trying to find a way to express the difference between stages 1 > >> >> >> > and 2 in the generic code, so that we do not to worry about > >> >> >> > particular > >> >> >> > DSI host and DSI bridge / panel peculiarities when implementing the > >> >> >> > DSI host and/or DSI panel driver. > >> >> >> > >> >> >> For now, I have a rather hacky
Re: [Freedreno] [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
[sorry I fat fingered my former reply and converted all CCs to BCCs..] >> >> > DSI device lifetime has three different stages: >> >> > 1. before the DSI link being powered up and clocking, >> >> > 2. when the DSI link is in LP state (for the purpose of this question, >> >> > this is the time between the DSI link being powered up and the video >> >> > stream start) >> >> > 3. when the DSI link is in HS state (while streaming the video). >> >> >> >> It's not clear to me what (2) is. What is the state of the clock and >> >> data lanes? >> > >> > Clk an Data0 should be in the LP mode, ready for LP Data Transfer. >> >> Then this is somehow missing >> https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation >> >>A DSI host should keep the PHY powered down until the pre_enable >> operation >>is called. All lanes are in an undefined idle state up to this point, >> and >>it must not be assumed that it is LP-11. pre_enable should initialise >> the >>PHY, set the data lanes to LP-11, and the clock lane to either LP-11 >> or HS >>depending on the mode_flag MIPI_DSI_CLOCK_NON_CONTINUOUS. >> >> So I don't think these three states are sufficient, see below, that >> there >> should be at least four. > >Which one is #4? enabled clock lane (HS mode), data lanes in LP-11 What is the purpose of such a mode? To repeat my first mail: I'm facing similar issues with the tc358775 bridge. This bridge needs to release its reset while both clock and data lanes are in LP-11 mode. But then it needs to be configured (via I2C) while the clock lane is in enabled (HS mode), but the data lanes are still in LP-11 mode. Therefore, for the correct init sequence is: (1) dsi host enables lanes, that is clock and data are in lp-11 (2) dsi bridge driver releases reset of the bridge (3) dsi host enables clock lane, leaves data lanes in lp-11 (4) dsi bridge driver configures the bridge (5) dsi host enables the video stream (6) dsi bridge enables the output port of the bridge -michael >> > I don't think we support ULPS currently. >> > >> > >> >> >> >> I'm facing similar issues with the tc358775 bridge. This bridge needs >> >> to release its reset while both clock and data lanes are in LP-11 >> >> mode. >> >> But then it needs to be configured (via I2C) while the clock lane is >> >> in enabled (HS mode), but the data lanes are still in LP-11 mode. >> >> >> >> To me it looks like there is a fouth case then: >> >> 1. unpowered >> >> 2. DSI clock and data are in LP-11 >> >> 3. DSI clock is in HS and data are in LP-11 >> >> 4. DSI clock is in HS and data is in HS >> >> >> >> (And of course the bridge needs continuous clock mode). >> >> >> >> > Different DSI bridges have different requirements with respect to the >> >> > code being executed at stages 1 and 2. For example several DSI-to-eDP >> >> > bridges (ps8640, tc358767 require for the link to be quiet during >> >> > reset time. >> >> > The DSI-controlled bridges and DSI panels need to send some commands >> >> > in stage 2, before starting up video >> >> > >> >> > In the DRM subsystem stage 3 naturally maps to the >> >> > drm_bridge_funcs::enable, stage 1 also naturally maps to the >> >> > drm_bridge_funcs::pre_enable. Stage 2 doesn't have its own place in >> >> > the DRM call chain. >> >> > Earlier we attempted to solve that using the pre_enable_prev_first, >> >> > which remapped pre-enable callback execution order. However it has led >> >> > us to the two issues. First, at the DSI host driver we do not know >> >> > whether the panel / bridge were updated to use pre_enable_prev_first >> >> > or not. Second, if the bridge has to perform steps during both stages >> >> > 1 and 2, it can not do that. >> >> > >> >> > I'm trying to find a way to express the difference between stages 1 >> >> > and 2 in the generic code, so that we do not to worry about particular >> >> > DSI host and DSI bridge / panel peculiarities when implementing the >> >> > DSI host and/or DSI panel driver. >> >> >> >> For now, I have a rather hacky ".dsi_lp11_notify" callback in >> >> drm_bridge_funcs which is supposed to be called by the DSI host while >> >> the >> >> clock and data lanes are in LP-11 mode. But that is rather an RFC and >> >> me >> >> needing something to get the driver for this bridge working. Because >> >> it's >> >> badly broken. FWIW, you can find my work-in-progress patches at >> >> https://github.com/mwalle/linux/tree/feature-tc358775-fixes >> >> >> >> -michael >> >> >> > >> > >> > -- >> > With best wishes >> > Dmitry > > >
Re: [Freedreno] [PATCH] drm/msm/dpu: Capture dpu snapshot when frame_done_timer timeouts
On Tue, 28 Nov 2023 at 19:43, Paloma Arellano wrote:
>
>
> On 11/27/2023 5:48 PM, Dmitry Baryshkov wrote:
> > On Tue, 28 Nov 2023 at 03:12, Paloma Arellano
> > wrote:
> >> Trigger a devcoredump to dump dpu registers and capture the drm atomic
> >> state when the frame_done_timer timeouts.
> >>
> >> Signed-off-by: Paloma Arellano
> >> ---
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 +++--
> >> 1 file changed, 11 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> index 1cf7ff6caff4..5cf7594feb5a 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >> @@ -191,6 +191,7 @@ struct dpu_encoder_virt {
> >> void *crtc_frame_event_cb_data;
> >>
> >> atomic_t frame_done_timeout_ms;
> >> + atomic_t frame_done_timeout_cnt;
> >> struct timer_list frame_done_timer;
> >>
> >> struct msm_display_info disp_info;
> >> @@ -1204,6 +1205,8 @@ static void dpu_encoder_virt_atomic_enable(struct
> >> drm_encoder *drm_enc,
> >>
> >> dpu_enc->dsc = dpu_encoder_get_dsc_config(drm_enc);
> >>
> >> + atomic_set(_enc->frame_done_timeout_cnt, 0);
> >> +
> >> if (disp_info->intf_type == INTF_DP)
> >> dpu_enc->wide_bus_en =
> >> msm_dp_wide_bus_available(priv->dp[index]);
> >> else if (disp_info->intf_type == INTF_DSI)
> >> @@ -2115,11 +2118,12 @@ static int _dpu_encoder_status_show(struct
> >> seq_file *s, void *data)
> >> for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> >> struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
> >>
> >> - seq_printf(s, "intf:%d wb:%d vsync:%8d underrun:%8d
> >> ",
> >> + seq_printf(s, "intf:%d wb:%d vsync:%8d underrun:%8d
> >> frame_done_cnt:%d",
> >> phys->hw_intf ? phys->hw_intf->idx -
> >> INTF_0 : -1,
> >> phys->hw_wb ? phys->hw_wb->idx - WB_0 :
> >> -1,
> >> atomic_read(>vsync_cnt),
> >> - atomic_read(>underrun_cnt));
> >> + atomic_read(>underrun_cnt),
> >> +
> >> atomic_read(_enc->frame_done_timeout_cnt));
> >>
> >> seq_printf(s, "mode: %s\n",
> >> dpu_encoder_helper_get_intf_type(phys->intf_mode));
> >> }
> >> @@ -2341,6 +2345,10 @@ static void dpu_encoder_frame_done_timeout(struct
> >> timer_list *t)
> >>
> >> DPU_ERROR_ENC(dpu_enc, "frame done timeout\n");
> >>
> >> + atomic_inc(_enc->frame_done_timeout_cnt);
> >> + if (atomic_read(_enc->frame_done_timeout_cnt) == 1)
> >> + msm_disp_snapshot_state(drm_enc->dev);
> > atomic_inc_and_test(), please
>
> Hi Dmitry,
>
> We only want to create a snapshot for the first instance in which the
> timer timeouts. atomic_int_and_test() increments the value and then
> returns whether it has a value of zero or not. FWIW I think I should
> change it to 'atomic_add_return(1, _enc->frame_done_timeout_cnt)' so
> that we can check only when this value equals one.
Works for me too.
I suggested atomic_inc_test() because then we can let devcoredump take
care of duplicate events.
>
> Thank you,
>
> Paloma
>
> >
> >> +
> >> event = DPU_ENCODER_FRAME_EVENT_ERROR;
> >> trace_dpu_enc_frame_done_timeout(DRMID(drm_enc), event);
> >> dpu_enc->crtc_frame_event_cb(dpu_enc->crtc_frame_event_cb_data,
> >> event);
> >> @@ -2392,6 +2400,7 @@ struct drm_encoder *dpu_encoder_init(struct
> >> drm_device *dev,
> >> goto fail;
> >>
> >> atomic_set(_enc->frame_done_timeout_ms, 0);
> >> + atomic_set(_enc->frame_done_timeout_cnt, 0);
> >> timer_setup(_enc->frame_done_timer,
> >> dpu_encoder_frame_done_timeout, 0);
> >>
> >> --
> >> 2.41.0
> >>
> >
--
With best wishes
Dmitry
Re: [Freedreno] [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
On Tue, 28 Nov 2023 at 21:50, Michael Walle wrote: > > >> >> > DSI device lifetime has three different stages: > >> >> > 1. before the DSI link being powered up and clocking, > >> >> > 2. when the DSI link is in LP state (for the purpose of this question, > >> >> > this is the time between the DSI link being powered up and the video > >> >> > stream start) > >> >> > 3. when the DSI link is in HS state (while streaming the video). > >> >> > >> >> It's not clear to me what (2) is. What is the state of the clock and > >> >> data lanes? > >> > > >> > Clk an Data0 should be in the LP mode, ready for LP Data Transfer. > >> > >> Then this is somehow missing > >> https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation > >> > >>A DSI host should keep the PHY powered down until the pre_enable > >> operation > >>is called. All lanes are in an undefined idle state up to this point, > >> and > >>it must not be assumed that it is LP-11. pre_enable should initialise > >> the > >>PHY, set the data lanes to LP-11, and the clock lane to either LP-11 > >> or HS > >>depending on the mode_flag MIPI_DSI_CLOCK_NON_CONTINUOUS. > >> > >> So I don't think these three states are sufficient, see below, that > >> there > >> should be at least four. > > > >Which one is #4? > > enabled clock lane (HS mode), data lanes in LP-11 What is the purpose of such a mode? > > -michael > > >> > >> > > >> > I don't think we support ULPS currently. > >> > > >> > > >> >> > >> >> I'm facing similar issues with the tc358775 bridge. This bridge needs > >> >> to release its reset while both clock and data lanes are in LP-11 > >> >> mode. > >> >> But then it needs to be configured (via I2C) while the clock lane is > >> >> in enabled (HS mode), but the data lanes are still in LP-11 mode. > >> >> > >> >> To me it looks like there is a fouth case then: > >> >> 1. unpowered > >> >> 2. DSI clock and data are in LP-11 > >> >> 3. DSI clock is in HS and data are in LP-11 > >> >> 4. DSI clock is in HS and data is in HS > >> >> > >> >> (And of course the bridge needs continuous clock mode). > >> >> > >> >> > Different DSI bridges have different requirements with respect to the > >> >> > code being executed at stages 1 and 2. For example several DSI-to-eDP > >> >> > bridges (ps8640, tc358767 require for the link to be quiet during > >> >> > reset time. > >> >> > The DSI-controlled bridges and DSI panels need to send some commands > >> >> > in stage 2, before starting up video > >> >> > > >> >> > In the DRM subsystem stage 3 naturally maps to the > >> >> > drm_bridge_funcs::enable, stage 1 also naturally maps to the > >> >> > drm_bridge_funcs::pre_enable. Stage 2 doesn't have its own place in > >> >> > the DRM call chain. > >> >> > Earlier we attempted to solve that using the pre_enable_prev_first, > >> >> > which remapped pre-enable callback execution order. However it has led > >> >> > us to the two issues. First, at the DSI host driver we do not know > >> >> > whether the panel / bridge were updated to use pre_enable_prev_first > >> >> > or not. Second, if the bridge has to perform steps during both stages > >> >> > 1 and 2, it can not do that. > >> >> > > >> >> > I'm trying to find a way to express the difference between stages 1 > >> >> > and 2 in the generic code, so that we do not to worry about particular > >> >> > DSI host and DSI bridge / panel peculiarities when implementing the > >> >> > DSI host and/or DSI panel driver. > >> >> > >> >> For now, I have a rather hacky ".dsi_lp11_notify" callback in > >> >> drm_bridge_funcs which is supposed to be called by the DSI host while > >> >> the > >> >> clock and data lanes are in LP-11 mode. But that is rather an RFC and > >> >> me > >> >> needing something to get the driver for this bridge working. Because > >> >> it's > >> >> badly broken. FWIW, you can find my work-in-progress patches at > >> >> https://github.com/mwalle/linux/tree/feature-tc358775-fixes > >> >> > >> >> -michael > >> >> > >> > > >> > > >> > -- > >> > With best wishes > >> > Dmitry > > > > > > > -- With best wishes Dmitry
Re: [Freedreno] [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
>> >> > DSI device lifetime has three different stages: >> >> > 1. before the DSI link being powered up and clocking, >> >> > 2. when the DSI link is in LP state (for the purpose of this question, >> >> > this is the time between the DSI link being powered up and the video >> >> > stream start) >> >> > 3. when the DSI link is in HS state (while streaming the video). >> >> >> >> It's not clear to me what (2) is. What is the state of the clock and >> >> data lanes? >> > >> > Clk an Data0 should be in the LP mode, ready for LP Data Transfer. >> >> Then this is somehow missing >> https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation >> >>A DSI host should keep the PHY powered down until the pre_enable >> operation >>is called. All lanes are in an undefined idle state up to this point, >> and >>it must not be assumed that it is LP-11. pre_enable should initialise >> the >>PHY, set the data lanes to LP-11, and the clock lane to either LP-11 >> or HS >>depending on the mode_flag MIPI_DSI_CLOCK_NON_CONTINUOUS. >> >> So I don't think these three states are sufficient, see below, that >> there >> should be at least four. > >Which one is #4? enabled clock lane (HS mode), data lanes in LP-11 -michael >> >> > >> > I don't think we support ULPS currently. >> > >> > >> >> >> >> I'm facing similar issues with the tc358775 bridge. This bridge needs >> >> to release its reset while both clock and data lanes are in LP-11 >> >> mode. >> >> But then it needs to be configured (via I2C) while the clock lane is >> >> in enabled (HS mode), but the data lanes are still in LP-11 mode. >> >> >> >> To me it looks like there is a fouth case then: >> >> 1. unpowered >> >> 2. DSI clock and data are in LP-11 >> >> 3. DSI clock is in HS and data are in LP-11 >> >> 4. DSI clock is in HS and data is in HS >> >> >> >> (And of course the bridge needs continuous clock mode). >> >> >> >> > Different DSI bridges have different requirements with respect to the >> >> > code being executed at stages 1 and 2. For example several DSI-to-eDP >> >> > bridges (ps8640, tc358767 require for the link to be quiet during >> >> > reset time. >> >> > The DSI-controlled bridges and DSI panels need to send some commands >> >> > in stage 2, before starting up video >> >> > >> >> > In the DRM subsystem stage 3 naturally maps to the >> >> > drm_bridge_funcs::enable, stage 1 also naturally maps to the >> >> > drm_bridge_funcs::pre_enable. Stage 2 doesn't have its own place in >> >> > the DRM call chain. >> >> > Earlier we attempted to solve that using the pre_enable_prev_first, >> >> > which remapped pre-enable callback execution order. However it has led >> >> > us to the two issues. First, at the DSI host driver we do not know >> >> > whether the panel / bridge were updated to use pre_enable_prev_first >> >> > or not. Second, if the bridge has to perform steps during both stages >> >> > 1 and 2, it can not do that. >> >> > >> >> > I'm trying to find a way to express the difference between stages 1 >> >> > and 2 in the generic code, so that we do not to worry about particular >> >> > DSI host and DSI bridge / panel peculiarities when implementing the >> >> > DSI host and/or DSI panel driver. >> >> >> >> For now, I have a rather hacky ".dsi_lp11_notify" callback in >> >> drm_bridge_funcs which is supposed to be called by the DSI host while >> >> the >> >> clock and data lanes are in LP-11 mode. But that is rather an RFC and >> >> me >> >> needing something to get the driver for this bridge working. Because >> >> it's >> >> badly broken. FWIW, you can find my work-in-progress patches at >> >> https://github.com/mwalle/linux/tree/feature-tc358775-fixes >> >> >> >> -michael >> >> >> > >> > >> > -- >> > With best wishes >> > Dmitry > > >
[Freedreno] [PATCH] drm/msm/gpu: Fix null-pointer dereference in zap_shader_load_mdt
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Fixes: a9e2559c931d ("drm/msm/gpu: Move zap shader loading to adreno")
Signed-off-by: Kunwu Chan
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 3fe9fd240cc7..0ebf86ffd57b 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -144,6 +144,10 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
char *fwname,
char *newname;
newname = kasprintf(GFP_KERNEL, "qcom/%s", fwname);
+ if (!newname) {
+ ret = -ENOMEM;
+ goto out;
+ }
ret = qcom_mdt_load(dev, fw, newname, pasid,
mem_region, mem_phys, mem_size, NULL);
--
2.34.1
Re: [Freedreno] [PATCH] drm/msm/dpu: Capture dpu snapshot when frame_done_timer timeouts
On 11/27/2023 5:48 PM, Dmitry Baryshkov wrote:
On Tue, 28 Nov 2023 at 03:12, Paloma Arellano wrote:
Trigger a devcoredump to dump dpu registers and capture the drm atomic
state when the frame_done_timer timeouts.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1cf7ff6caff4..5cf7594feb5a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -191,6 +191,7 @@ struct dpu_encoder_virt {
void *crtc_frame_event_cb_data;
atomic_t frame_done_timeout_ms;
+ atomic_t frame_done_timeout_cnt;
struct timer_list frame_done_timer;
struct msm_display_info disp_info;
@@ -1204,6 +1205,8 @@ static void dpu_encoder_virt_atomic_enable(struct
drm_encoder *drm_enc,
dpu_enc->dsc = dpu_encoder_get_dsc_config(drm_enc);
+ atomic_set(_enc->frame_done_timeout_cnt, 0);
+
if (disp_info->intf_type == INTF_DP)
dpu_enc->wide_bus_en =
msm_dp_wide_bus_available(priv->dp[index]);
else if (disp_info->intf_type == INTF_DSI)
@@ -2115,11 +2118,12 @@ static int _dpu_encoder_status_show(struct seq_file *s,
void *data)
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
- seq_printf(s, "intf:%d wb:%d vsync:%8d underrun:%8d",
+ seq_printf(s, "intf:%d wb:%d vsync:%8d underrun:%8d
frame_done_cnt:%d",
phys->hw_intf ? phys->hw_intf->idx - INTF_0 :
-1,
phys->hw_wb ? phys->hw_wb->idx - WB_0 : -1,
atomic_read(>vsync_cnt),
- atomic_read(>underrun_cnt));
+ atomic_read(>underrun_cnt),
+ atomic_read(_enc->frame_done_timeout_cnt));
seq_printf(s, "mode: %s\n",
dpu_encoder_helper_get_intf_type(phys->intf_mode));
}
@@ -2341,6 +2345,10 @@ static void dpu_encoder_frame_done_timeout(struct
timer_list *t)
DPU_ERROR_ENC(dpu_enc, "frame done timeout\n");
+ atomic_inc(_enc->frame_done_timeout_cnt);
+ if (atomic_read(_enc->frame_done_timeout_cnt) == 1)
+ msm_disp_snapshot_state(drm_enc->dev);
atomic_inc_and_test(), please
Hi Dmitry,
We only want to create a snapshot for the first instance in which the
timer timeouts. atomic_int_and_test() increments the value and then
returns whether it has a value of zero or not. FWIW I think I should
change it to 'atomic_add_return(1, _enc->frame_done_timeout_cnt)' so
that we can check only when this value equals one.
Thank you,
Paloma
+
event = DPU_ENCODER_FRAME_EVENT_ERROR;
trace_dpu_enc_frame_done_timeout(DRMID(drm_enc), event);
dpu_enc->crtc_frame_event_cb(dpu_enc->crtc_frame_event_cb_data, event);
@@ -2392,6 +2400,7 @@ struct drm_encoder *dpu_encoder_init(struct drm_device
*dev,
goto fail;
atomic_set(_enc->frame_done_timeout_ms, 0);
+ atomic_set(_enc->frame_done_timeout_cnt, 0);
timer_setup(_enc->frame_done_timer,
dpu_encoder_frame_done_timeout, 0);
--
2.41.0
Re: [Freedreno] [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
On Tue, 28 Nov 2023 at 18:56, Michael Walle wrote: > > >> > DSI device lifetime has three different stages: > >> > 1. before the DSI link being powered up and clocking, > >> > 2. when the DSI link is in LP state (for the purpose of this question, > >> > this is the time between the DSI link being powered up and the video > >> > stream start) > >> > 3. when the DSI link is in HS state (while streaming the video). > >> > >> It's not clear to me what (2) is. What is the state of the clock and > >> data lanes? > > > > Clk an Data0 should be in the LP mode, ready for LP Data Transfer. > > Then this is somehow missing > https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation > >A DSI host should keep the PHY powered down until the pre_enable > operation >is called. All lanes are in an undefined idle state up to this point, > and >it must not be assumed that it is LP-11. pre_enable should initialise > the >PHY, set the data lanes to LP-11, and the clock lane to either LP-11 > or HS >depending on the mode_flag MIPI_DSI_CLOCK_NON_CONTINUOUS. > > So I don't think these three states are sufficient, see below, that > there > should be at least four. Which one is #4? > > -michael > > > > > I don't think we support ULPS currently. > > > > > >> > >> I'm facing similar issues with the tc358775 bridge. This bridge needs > >> to release its reset while both clock and data lanes are in LP-11 > >> mode. > >> But then it needs to be configured (via I2C) while the clock lane is > >> in enabled (HS mode), but the data lanes are still in LP-11 mode. > >> > >> To me it looks like there is a fouth case then: > >> 1. unpowered > >> 2. DSI clock and data are in LP-11 > >> 3. DSI clock is in HS and data are in LP-11 > >> 4. DSI clock is in HS and data is in HS > >> > >> (And of course the bridge needs continuous clock mode). > >> > >> > Different DSI bridges have different requirements with respect to the > >> > code being executed at stages 1 and 2. For example several DSI-to-eDP > >> > bridges (ps8640, tc358767 require for the link to be quiet during > >> > reset time. > >> > The DSI-controlled bridges and DSI panels need to send some commands > >> > in stage 2, before starting up video > >> > > >> > In the DRM subsystem stage 3 naturally maps to the > >> > drm_bridge_funcs::enable, stage 1 also naturally maps to the > >> > drm_bridge_funcs::pre_enable. Stage 2 doesn't have its own place in > >> > the DRM call chain. > >> > Earlier we attempted to solve that using the pre_enable_prev_first, > >> > which remapped pre-enable callback execution order. However it has led > >> > us to the two issues. First, at the DSI host driver we do not know > >> > whether the panel / bridge were updated to use pre_enable_prev_first > >> > or not. Second, if the bridge has to perform steps during both stages > >> > 1 and 2, it can not do that. > >> > > >> > I'm trying to find a way to express the difference between stages 1 > >> > and 2 in the generic code, so that we do not to worry about particular > >> > DSI host and DSI bridge / panel peculiarities when implementing the > >> > DSI host and/or DSI panel driver. > >> > >> For now, I have a rather hacky ".dsi_lp11_notify" callback in > >> drm_bridge_funcs which is supposed to be called by the DSI host while > >> the > >> clock and data lanes are in LP-11 mode. But that is rather an RFC and > >> me > >> needing something to get the driver for this bridge working. Because > >> it's > >> badly broken. FWIW, you can find my work-in-progress patches at > >> https://github.com/mwalle/linux/tree/feature-tc358775-fixes > >> > >> -michael > >> > > > > > > -- > > With best wishes > > Dmitry -- With best wishes Dmitry
Re: [Freedreno] [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
> DSI device lifetime has three different stages: > 1. before the DSI link being powered up and clocking, > 2. when the DSI link is in LP state (for the purpose of this question, > this is the time between the DSI link being powered up and the video > stream start) > 3. when the DSI link is in HS state (while streaming the video). It's not clear to me what (2) is. What is the state of the clock and data lanes? Clk an Data0 should be in the LP mode, ready for LP Data Transfer. Then this is somehow missing https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation A DSI host should keep the PHY powered down until the pre_enable operation is called. All lanes are in an undefined idle state up to this point, and it must not be assumed that it is LP-11. pre_enable should initialise the PHY, set the data lanes to LP-11, and the clock lane to either LP-11 or HS depending on the mode_flag MIPI_DSI_CLOCK_NON_CONTINUOUS. So I don't think these three states are sufficient, see below, that there should be at least four. -michael I don't think we support ULPS currently. I'm facing similar issues with the tc358775 bridge. This bridge needs to release its reset while both clock and data lanes are in LP-11 mode. But then it needs to be configured (via I2C) while the clock lane is in enabled (HS mode), but the data lanes are still in LP-11 mode. To me it looks like there is a fouth case then: 1. unpowered 2. DSI clock and data are in LP-11 3. DSI clock is in HS and data are in LP-11 4. DSI clock is in HS and data is in HS (And of course the bridge needs continuous clock mode). > Different DSI bridges have different requirements with respect to the > code being executed at stages 1 and 2. For example several DSI-to-eDP > bridges (ps8640, tc358767 require for the link to be quiet during > reset time. > The DSI-controlled bridges and DSI panels need to send some commands > in stage 2, before starting up video > > In the DRM subsystem stage 3 naturally maps to the > drm_bridge_funcs::enable, stage 1 also naturally maps to the > drm_bridge_funcs::pre_enable. Stage 2 doesn't have its own place in > the DRM call chain. > Earlier we attempted to solve that using the pre_enable_prev_first, > which remapped pre-enable callback execution order. However it has led > us to the two issues. First, at the DSI host driver we do not know > whether the panel / bridge were updated to use pre_enable_prev_first > or not. Second, if the bridge has to perform steps during both stages > 1 and 2, it can not do that. > > I'm trying to find a way to express the difference between stages 1 > and 2 in the generic code, so that we do not to worry about particular > DSI host and DSI bridge / panel peculiarities when implementing the > DSI host and/or DSI panel driver. For now, I have a rather hacky ".dsi_lp11_notify" callback in drm_bridge_funcs which is supposed to be called by the DSI host while the clock and data lanes are in LP-11 mode. But that is rather an RFC and me needing something to get the driver for this bridge working. Because it's badly broken. FWIW, you can find my work-in-progress patches at https://github.com/mwalle/linux/tree/feature-tc358775-fixes -michael -- With best wishes Dmitry
Re: [Freedreno] [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
On Mon, 27 Nov 2023 at 18:07, Michael Walle wrote: > > Hi, > > > DSI device lifetime has three different stages: > > 1. before the DSI link being powered up and clocking, > > 2. when the DSI link is in LP state (for the purpose of this question, > > this is the time between the DSI link being powered up and the video > > stream start) > > 3. when the DSI link is in HS state (while streaming the video). > > It's not clear to me what (2) is. What is the state of the clock and > data lanes? Clk an Data0 should be in the LP mode, ready for LP Data Transfer. I don't think we support ULPS currently. > > I'm facing similar issues with the tc358775 bridge. This bridge needs > to release its reset while both clock and data lanes are in LP-11 mode. > But then it needs to be configured (via I2C) while the clock lane is > in enabled (HS mode), but the data lanes are still in LP-11 mode. > > To me it looks like there is a fouth case then: > 1. unpowered > 2. DSI clock and data are in LP-11 > 3. DSI clock is in HS and data are in LP-11 > 4. DSI clock is in HS and data is in HS > > (And of course the bridge needs continuous clock mode). > > > Different DSI bridges have different requirements with respect to the > > code being executed at stages 1 and 2. For example several DSI-to-eDP > > bridges (ps8640, tc358767 require for the link to be quiet during > > reset time. > > The DSI-controlled bridges and DSI panels need to send some commands > > in stage 2, before starting up video > > > > In the DRM subsystem stage 3 naturally maps to the > > drm_bridge_funcs::enable, stage 1 also naturally maps to the > > drm_bridge_funcs::pre_enable. Stage 2 doesn't have its own place in > > the DRM call chain. > > Earlier we attempted to solve that using the pre_enable_prev_first, > > which remapped pre-enable callback execution order. However it has led > > us to the two issues. First, at the DSI host driver we do not know > > whether the panel / bridge were updated to use pre_enable_prev_first > > or not. Second, if the bridge has to perform steps during both stages > > 1 and 2, it can not do that. > > > > I'm trying to find a way to express the difference between stages 1 > > and 2 in the generic code, so that we do not to worry about particular > > DSI host and DSI bridge / panel peculiarities when implementing the > > DSI host and/or DSI panel driver. > > For now, I have a rather hacky ".dsi_lp11_notify" callback in > drm_bridge_funcs which is supposed to be called by the DSI host while the > clock and data lanes are in LP-11 mode. But that is rather an RFC and me > needing something to get the driver for this bridge working. Because it's > badly broken. FWIW, you can find my work-in-progress patches at > https://github.com/mwalle/linux/tree/feature-tc358775-fixes > > -michael > -- With best wishes Dmitry
Re: [Freedreno] [PATCH v2 05/12] iommu/arm-smmu-qcom: Add QCM2290 DPU compatible
On 27/11/2023 17:28, Konrad Dybcio wrote:
Add the QCM2290 DPU compatible to clients compatible list, as it also
needs the workarounds.
Nit: MDSS, not DPU compatible
With that fixed:
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 549ae4dba3a6..aea5e85b20ff 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -245,6 +245,7 @@ static const struct of_device_id
qcom_smmu_client_of_match[] __maybe_unused = {
{ .compatible = "qcom,adreno" },
{ .compatible = "qcom,mdp4" },
{ .compatible = "qcom,mdss" },
+ { .compatible = "qcom,qcm2290-mdss" },
{ .compatible = "qcom,sc7180-mdss" },
{ .compatible = "qcom,sc7180-mss-pil" },
{ .compatible = "qcom,sc7280-mdss" },
--
With best wishes
Dmitry
Re: [Freedreno] [PATCH v2 08/12] arm64: dts: qcom: qcm2290: Add display nodes
On 27/11/2023 17:28, Konrad Dybcio wrote: Add the required nodes to support display on QCM2290. Signed-off-by: Konrad Dybcio --- arch/arm64/boot/dts/qcom/qcm2290.dtsi | 214 ++ 1 file changed, 214 insertions(+) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [Freedreno] [PATCH v2 09/12] arm64: dts: qcom: qcm2290: Hook up interconnects
On 27/11/2023 17:28, Konrad Dybcio wrote: Add interconnect provider nodes and hook up interconnects to consumer devices, including bwmon. Signed-off-by: Konrad Dybcio --- arch/arm64/boot/dts/qcom/qcm2290.dtsi | 248 ++ 1 file changed, 248 insertions(+) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [Freedreno] [PATCH v2 10/12] arm64: dts: qcom: qrb2210-rb1: Set up HDMI
On 27/11/2023 17:28, Konrad Dybcio wrote: Add the required nodes to support display output via the HDMI port. Signed-off-by: Konrad Dybcio --- arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 86 1 file changed, 86 insertions(+) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [Freedreno] [PATCH v2 12/12] arm64: dts: qcom: qrb2210-rb1: add wifi variant property
On 27/11/2023 17:28, Konrad Dybcio wrote:
From: Dmitry Baryshkov
The RB1 platform doesn't have board-specific board-id programmed, it uses
generic 0xff. Thus add the property with the 'variant' of the
calibration data.
Note: the driver will check for the calibration data for the following
IDs, so existing board-2.bin files will continue to work.
- 'bus=snoc,qmi-board-id=ff,qmi-chip-id=120,variant=Thundercomm_RB1'
- 'bus=snoc,qmi-board-id=ff,qmi-chip-id=120'
- 'bus=snoc,qmi-board-id=ff'
For the reference, the board is identified by the driver in the
following way:
ath10k_snoc c80.wifi: qmi chip_id 0x120 chip_family 0x4007 board_id 0xff
soc_id 0x4067
ath10k_snoc c80.wifi: qmi fw_version 0x337302d3 fw_build_timestamp
2023-01-06 01:50 fw_build_id
QC_IMAGE_VERSION_STRING=WLAN.HL.3.3.7.c2-00723-QCAHLSWMTPLZ-1
ath10k_snoc c80.wifi: wcn3990 hw1.0 target 0x0008 chip_id 0x
sub :
ath10k_snoc c80.wifi: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
ath10k_snoc c80.wifi: firmware ver api 5 features
wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790
ath10k_snoc c80.wifi: htt-ver 3.114 wmi-op 4 htt-op 3 cal file max-sta 32
raw 0 hwcrypto 1
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
As you are resending this patch, you should add your S-o-b.
---
arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
index ac597eb3fe9d..bd7bcf803654 100644
--- a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
+++ b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
@@ -535,6 +535,7 @@ {
vdd-1.8-xo-supply = <_l13>;
vdd-1.3-rfa-supply = <_l10>;
vdd-3.3-ch0-supply = <_l22>;
+ qcom,ath10k-calibration-variant = "Thundercomm_RB1";
status = "okay";
};
--
With best wishes
Dmitry
Re: [Freedreno] [PATCH v2 02/12] dt-bindings: display: msm: Add reg bus and rotator interconnects
On 27/11/2023 16:28, Konrad Dybcio wrote: > Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are > other connection paths: > - a path that connects rotator block to the DDR. > - a path that needs to be handled to ensure MDSS register access > functions properly, namely the "reg bus", a.k.a the CPU-MDSS CFG > interconnect. > > Describe these paths to allow using them in device trees and in the > driver. > > Signed-off-by: Dmitry Baryshkov > [Konrad: rework for one vs two MDP paths, update examples] > Signed-off-by: Konrad Dybcio > --- Thanks, looks good. Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Freedreno] [PATCH v2 01/12] dt-bindings: display: msm: qcm2290-mdss: Use the non-deprecated DSI compat
On 27/11/2023 16:28, Konrad Dybcio wrote:
> The "qcom,dsi-ctrl-6g-qcm2290" has been deprecated in commit 0c0f65c6dd44
> ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every
> current SoC"), but the example hasn't been updated to reflect that.
>
> Fix that.
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
