diff mbox series

[v3,06/10] drm/msm/dsi: Migrate to drm_dsc_compute_rc_parameters()

Message ID 20221009185058.460688-1-marijn.suijten@somainline.org
State Superseded
Headers show
Series None | expand

Commit Message

Marijn Suijten Oct. 9, 2022, 6:50 p.m. UTC
As per the FIXME this code is entirely duplicate with what is already
provided inside drm_dsc_compute_rc_parameters(), and it is yet unknown
why this comment was put in place instead of resolved from the get-go.
Not only does it save on duplication, it would have also spared certain
issues.

For example, this code from downstream assumed dsc->bits_per_pixel to
contain an integer value, whereas the upstream drm_dsc_config struct has
it with 4 fractional bits.  drm_dsc_compute_rc_parameters() already
accounts for this feat, and the sole remaining use of
dsc->bits_per_pixel inside dsi_populate_dsc_params() will be addressed
in a separate patch.

Fixes: b9080324d6ca ("drm/msm/dsi: add support for dsc data")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 64 +++---------------------------
 1 file changed, 6 insertions(+), 58 deletions(-)

Comments

Abhinav Kumar Oct. 12, 2022, 11:03 p.m. UTC | #1
On 10/9/2022 11:50 AM, Marijn Suijten wrote:
> As per the FIXME this code is entirely duplicate with what is already
> provided inside drm_dsc_compute_rc_parameters(), and it is yet unknown
> why this comment was put in place instead of resolved from the get-go.
> Not only does it save on duplication, it would have also spared certain
> issues.
> 
> For example, this code from downstream assumed dsc->bits_per_pixel to
> contain an integer value, whereas the upstream drm_dsc_config struct has
> it with 4 fractional bits.  drm_dsc_compute_rc_parameters() already
> accounts for this feat, and the sole remaining use of
> dsc->bits_per_pixel inside dsi_populate_dsc_params() will be addressed
> in a separate patch.
> 

This is a nice cleanup! Thanks for doing this. I would actually like to 
move towards the drm_dsc_compute_rc_parameters() API.

But I would like to hold back this change till Vinod clarifies because 
Vinod had mentioned that with drm_dsc_compute_rc_parameters() he was 
seeing a mismatch in the computation of two values.

slice_bpg_offset and the final_offset.

The difference between the upstream drm_dsc_compute_rc_parameters() and 
dsi_populate_dsc_params() causing this was not clear to me from his 
explanation earlier.

So this was left as a to-do item.

I would like this to be re-tested on pixel3 and check if this works for 
vinod. If not, i think its the right time to debug why and not delay 
this more.

Thanks

Abhinav
> Fixes: b9080324d6ca ("drm/msm/dsi: add support for dsc data")
> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> ---
>   drivers/gpu/drm/msm/dsi/dsi_host.c | 64 +++---------------------------
>   1 file changed, 6 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 83cde4d62b68..68c39debc22f 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -21,6 +21,7 @@
>   
>   #include <video/mipi_display.h>
>   
> +#include <drm/display/drm_dsc_helper.h>
>   #include <drm/drm_of.h>
>   
>   #include "dsi.h"
> @@ -1771,14 +1772,6 @@ static char bpg_offset[DSC_NUM_BUF_RANGES] = {
>   
>   static int dsi_populate_dsc_params(struct drm_dsc_config *dsc)
>   {
> -	int mux_words_size;
> -	int groups_per_line, groups_total;
> -	int min_rate_buffer_size;
> -	int hrd_delay;
> -	int pre_num_extra_mux_bits, num_extra_mux_bits;
> -	int slice_bits;
> -	int data;
> -	int final_value, final_scale;
>   	int i;
>   
>   	dsc->rc_model_size = 8192;
> @@ -1804,11 +1797,11 @@ static int dsi_populate_dsc_params(struct drm_dsc_config *dsc)
>   	if (dsc->bits_per_pixel != 8)
>   		dsc->initial_offset = 2048;	/* bpp = 12 */
>   
> -	mux_words_size = 48;		/* bpc == 8/10 */
> -	if (dsc->bits_per_component == 12)
> -		mux_words_size = 64;
> +	if (dsc->bits_per_component <= 10)
> +		dsc->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
> +	else
> +		dsc->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
>   
> -	dsc->mux_word_size = mux_words_size;
>   	dsc->initial_xmit_delay = 512;
>   	dsc->initial_scale_value = 32;
>   	dsc->first_line_bpg_offset = 12;
> @@ -1820,52 +1813,7 @@ static int dsi_populate_dsc_params(struct drm_dsc_config *dsc)
>   	dsc->rc_quant_incr_limit0 = 11;
>   	dsc->rc_quant_incr_limit1 = 11;
>   
> -	/* FIXME: need to call drm_dsc_compute_rc_parameters() so that rest of
> -	 * params are calculated
> -	 */
> -	groups_per_line = DIV_ROUND_UP(dsc->slice_width, 3);
> -	dsc->slice_chunk_size = DIV_ROUND_UP(dsc->slice_width * dsc->bits_per_pixel, 8);
> -
> -	/* rbs-min */
> -	min_rate_buffer_size =  dsc->rc_model_size - dsc->initial_offset +
> -				dsc->initial_xmit_delay * dsc->bits_per_pixel +
> -				groups_per_line * dsc->first_line_bpg_offset;
> -
> -	hrd_delay = DIV_ROUND_UP(min_rate_buffer_size, dsc->bits_per_pixel);
> -
> -	dsc->initial_dec_delay = hrd_delay - dsc->initial_xmit_delay;
> -
> -	dsc->initial_scale_value = 8 * dsc->rc_model_size /
> -				       (dsc->rc_model_size - dsc->initial_offset);
> -
> -	slice_bits = 8 * dsc->slice_chunk_size * dsc->slice_height;
> -
> -	groups_total = groups_per_line * dsc->slice_height;
> -
> -	data = dsc->first_line_bpg_offset * 2048;
> -
> -	dsc->nfl_bpg_offset = DIV_ROUND_UP(data, (dsc->slice_height - 1));
> -
> -	pre_num_extra_mux_bits = 3 * (mux_words_size + (4 * dsc->bits_per_component + 4) - 2);
> -
> -	num_extra_mux_bits = pre_num_extra_mux_bits - (mux_words_size -
> -			     ((slice_bits - pre_num_extra_mux_bits) % mux_words_size));
> -
> -	data = 2048 * (dsc->rc_model_size - dsc->initial_offset + num_extra_mux_bits);
> -	dsc->slice_bpg_offset = DIV_ROUND_UP(data, groups_total);
> -
> -	data = dsc->initial_xmit_delay * dsc->bits_per_pixel;
> -	final_value =  dsc->rc_model_size - data + num_extra_mux_bits;
> -	dsc->final_offset = final_value;
> -
> -	final_scale = 8 * dsc->rc_model_size / (dsc->rc_model_size - final_value);
> -
> -	data = (final_scale - 9) * (dsc->nfl_bpg_offset + dsc->slice_bpg_offset);
> -	dsc->scale_increment_interval = (2048 * dsc->final_offset) / data;
> -
> -	dsc->scale_decrement_interval = groups_per_line / (dsc->initial_scale_value - 8);
> -
> -	return 0;
> +	return drm_dsc_compute_rc_parameters(dsc);
>   }
>   
>   static int dsi_host_parse_dt(struct msm_dsi_host *msm_host)
Marijn Suijten Oct. 13, 2022, 9:36 a.m. UTC | #2
On 2022-10-12 16:03:06, Abhinav Kumar wrote:
> 
> 
> On 10/9/2022 11:50 AM, Marijn Suijten wrote:
> > As per the FIXME this code is entirely duplicate with what is already
> > provided inside drm_dsc_compute_rc_parameters(), and it is yet unknown
> > why this comment was put in place instead of resolved from the get-go.
> > Not only does it save on duplication, it would have also spared certain
> > issues.
> > 
> > For example, this code from downstream assumed dsc->bits_per_pixel to
> > contain an integer value, whereas the upstream drm_dsc_config struct has
> > it with 4 fractional bits.  drm_dsc_compute_rc_parameters() already
> > accounts for this feat, and the sole remaining use of
> > dsc->bits_per_pixel inside dsi_populate_dsc_params() will be addressed
> > in a separate patch.
> > 
> 
> This is a nice cleanup! Thanks for doing this. I would actually like to 
> move towards the drm_dsc_compute_rc_parameters() API.
> 
> But I would like to hold back this change till Vinod clarifies because 
> Vinod had mentioned that with drm_dsc_compute_rc_parameters() he was 
> seeing a mismatch in the computation of two values.
> 
> slice_bpg_offset and the final_offset.

Unsurprisingly so because final_offset, and slice_bpg_offset through
initial_offset depend directly on bits_per_pixel.  The main takeaway of
this series is that Vinod was interpreting this field as integer instead
of containing 4 fractional bits.  If he updates his the panel driver [1]
to set bits_per_pixel = 8 << 4 instead of just 8 to account for this,
the values should check out once again.

[1]: https://git.linaro.org/people/vinod.koul/kernel.git/commit/?h=topic/pixel3_5.18-rc1&id=1d7d98ad564f1ec69e7525e07418918d90f247a1

Once Vinod (or someone else in the posession of a Pixel 3) confirms
this, I can respin this series and more explicitly explain why the FIXME
was put in place, instead of being resolved outright?

- Marijn

> 
> The difference between the upstream drm_dsc_compute_rc_parameters() and 
> dsi_populate_dsc_params() causing this was not clear to me from his 
> explanation earlier.
> 
> So this was left as a to-do item.
> 
> I would like this to be re-tested on pixel3 and check if this works for 
> vinod. If not, i think its the right time to debug why and not delay 
> this more.
> 
> Thanks
> 
> Abhinav
Abhinav Kumar Oct. 13, 2022, 4:02 p.m. UTC | #3
On 10/13/2022 2:36 AM, Marijn Suijten wrote:
> On 2022-10-12 16:03:06, Abhinav Kumar wrote:
>>
>>
>> On 10/9/2022 11:50 AM, Marijn Suijten wrote:
>>> As per the FIXME this code is entirely duplicate with what is already
>>> provided inside drm_dsc_compute_rc_parameters(), and it is yet unknown
>>> why this comment was put in place instead of resolved from the get-go.
>>> Not only does it save on duplication, it would have also spared certain
>>> issues.
>>>
>>> For example, this code from downstream assumed dsc->bits_per_pixel to
>>> contain an integer value, whereas the upstream drm_dsc_config struct has
>>> it with 4 fractional bits.  drm_dsc_compute_rc_parameters() already
>>> accounts for this feat, and the sole remaining use of
>>> dsc->bits_per_pixel inside dsi_populate_dsc_params() will be addressed
>>> in a separate patch.
>>>
>>
>> This is a nice cleanup! Thanks for doing this. I would actually like to
>> move towards the drm_dsc_compute_rc_parameters() API.
>>
>> But I would like to hold back this change till Vinod clarifies because
>> Vinod had mentioned that with drm_dsc_compute_rc_parameters() he was
>> seeing a mismatch in the computation of two values.
>>
>> slice_bpg_offset and the final_offset.
> 
> Unsurprisingly so because final_offset, and slice_bpg_offset through
> initial_offset depend directly on bits_per_pixel.  The main takeaway of
> this series is that Vinod was interpreting this field as integer instead
> of containing 4 fractional bits.  If he updates his the panel driver [1]
> to set bits_per_pixel = 8 << 4 instead of just 8 to account for this,
> the values should check out once again.
> 
> [1]: https://git.linaro.org/people/vinod.koul/kernel.git/commit/?h=topic/pixel3_5.18-rc1&id=1d7d98ad564f1ec69e7525e07418918d90f247a1
> 
> Once Vinod (or someone else in the posession of a Pixel 3) confirms
> this, I can respin this series and more explicitly explain why the FIXME
> was put in place, instead of being resolved outright?
> 
> - Marijn

Makes perfect sense to me.

Will just wait for Vinod's tested-by.

> 
>>
>> The difference between the upstream drm_dsc_compute_rc_parameters() and
>> dsi_populate_dsc_params() causing this was not clear to me from his
>> explanation earlier.
>>
>> So this was left as a to-do item.
>>
>> I would like this to be re-tested on pixel3 and check if this works for
>> vinod. If not, i think its the right time to debug why and not delay
>> this more.
>>
>> Thanks
>>
>> Abhinav
Marijn Suijten Oct. 17, 2022, 8:59 a.m. UTC | #4
On 2022-10-13 09:02:44, Abhinav Kumar wrote:
> On 10/13/2022 2:36 AM, Marijn Suijten wrote:
> > On 2022-10-12 16:03:06, Abhinav Kumar wrote:
> >> [..]
> >> But I would like to hold back this change till Vinod clarifies because
> >> Vinod had mentioned that with drm_dsc_compute_rc_parameters() he was
> >> seeing a mismatch in the computation of two values.
> >>
> >> slice_bpg_offset and the final_offset.
> > 
> > Unsurprisingly so because final_offset, and slice_bpg_offset through
> > initial_offset depend directly on bits_per_pixel.  The main takeaway of
> > this series is that Vinod was interpreting this field as integer instead
> > of containing 4 fractional bits.  If he updates his the panel driver [1]
> > to set bits_per_pixel = 8 << 4 instead of just 8 to account for this,
> > the values should check out once again.
> > 
> > [1]: https://git.linaro.org/people/vinod.koul/kernel.git/commit/?h=topic/pixel3_5.18-rc1&id=1d7d98ad564f1ec69e7525e07418918d90f247a1
> > 
> > Once Vinod (or someone else in the posession of a Pixel 3) confirms
> > this, I can respin this series and more explicitly explain why the FIXME
> > was put in place, instead of being resolved outright?
> > 
> > - Marijn
> 
> Makes perfect sense to me.
> 
> Will just wait for Vinod's tested-by.

Unfortunately Vinod doesn't have access to this device anymore, but
Caleb recently sent the support series including display driver for
Pixel 3 and is picking up the testing.  User "Newbyte" from #linux-msm
promised to test on the LG G7 to have even more input samples.

- Marijn
Caleb Connolly Oct. 17, 2022, 1:37 p.m. UTC | #5
On 17/10/2022 09:59, Marijn Suijten wrote:
> On 2022-10-13 09:02:44, Abhinav Kumar wrote:
>> On 10/13/2022 2:36 AM, Marijn Suijten wrote:
>>> On 2022-10-12 16:03:06, Abhinav Kumar wrote:
>>>> [..]
>>>> But I would like to hold back this change till Vinod clarifies because
>>>> Vinod had mentioned that with drm_dsc_compute_rc_parameters() he was
>>>> seeing a mismatch in the computation of two values.
>>>>
>>>> slice_bpg_offset and the final_offset.
>>>
>>> Unsurprisingly so because final_offset, and slice_bpg_offset through
>>> initial_offset depend directly on bits_per_pixel.  The main takeaway of
>>> this series is that Vinod was interpreting this field as integer instead
>>> of containing 4 fractional bits.  If he updates his the panel driver [1]
>>> to set bits_per_pixel = 8 << 4 instead of just 8 to account for this,
>>> the values should check out once again.
>>>
>>> [1]: https://git.linaro.org/people/vinod.koul/kernel.git/commit/?h=topic/pixel3_5.18-rc1&id=1d7d98ad564f1ec69e7525e07418918d90f247a1
>>>
>>> Once Vinod (or someone else in the posession of a Pixel 3) confirms
>>> this, I can respin this series and more explicitly explain why the FIXME
>>> was put in place, instead of being resolved outright?
>>>
>>> - Marijn
>>
>> Makes perfect sense to me.
>>
>> Will just wait for Vinod's tested-by.
>
> Unfortunately Vinod doesn't have access to this device anymore, but
> Caleb recently sent the support series including display driver for
> Pixel 3 and is picking up the testing.  User "Newbyte" from #linux-msm
> promised to test on the LG G7 to have even more input samples.

Hi,

I'm hoping to pick the Pixel 3 stuff back up at some point, but right now there
seem to be quite a few issues outside of DSC which make testing it a bit of a pain.

I gave Marijn's series [1] a go but wasn't able to get anything usable out of the
panel, however I doubt this is a DSC issue as I've always needed some hacks to
get the panel working - I've never had any success with it without skipping both
the initial panel reset and sending the PPS payload.

I think if Marijn has managed to initialise a panel properly then the lack of
Pixel 3 for validation shouldn't be a blocker to merge these fixes.

[1]:
https://lore.kernel.org/linux-arm-msm/20221009184824.457416-1-marijn.suijten@somainline.org/

>
> - Marijn

--
Kind Regards,
Caleb
Abhinav Kumar Oct. 17, 2022, 4:28 p.m. UTC | #6
On 10/17/2022 6:37 AM, Caleb Connolly wrote:
> 
> 
> On 17/10/2022 09:59, Marijn Suijten wrote:
>> On 2022-10-13 09:02:44, Abhinav Kumar wrote:
>>> On 10/13/2022 2:36 AM, Marijn Suijten wrote:
>>>> On 2022-10-12 16:03:06, Abhinav Kumar wrote:
>>>>> [..]
>>>>> But I would like to hold back this change till Vinod clarifies because
>>>>> Vinod had mentioned that with drm_dsc_compute_rc_parameters() he was
>>>>> seeing a mismatch in the computation of two values.
>>>>>
>>>>> slice_bpg_offset and the final_offset.
>>>>
>>>> Unsurprisingly so because final_offset, and slice_bpg_offset through
>>>> initial_offset depend directly on bits_per_pixel.  The main takeaway of
>>>> this series is that Vinod was interpreting this field as integer instead
>>>> of containing 4 fractional bits.  If he updates his the panel driver [1]
>>>> to set bits_per_pixel = 8 << 4 instead of just 8 to account for this,
>>>> the values should check out once again.
>>>>
>>>> [1]: https://git.linaro.org/people/vinod.koul/kernel.git/commit/?h=topic/pixel3_5.18-rc1&id=1d7d98ad564f1ec69e7525e07418918d90f247a1
>>>>
>>>> Once Vinod (or someone else in the posession of a Pixel 3) confirms
>>>> this, I can respin this series and more explicitly explain why the FIXME
>>>> was put in place, instead of being resolved outright?
>>>>
>>>> - Marijn
>>>
>>> Makes perfect sense to me.
>>>
>>> Will just wait for Vinod's tested-by.
>>
>> Unfortunately Vinod doesn't have access to this device anymore, but
>> Caleb recently sent the support series including display driver for
>> Pixel 3 and is picking up the testing.  User "Newbyte" from #linux-msm
>> promised to test on the LG G7 to have even more input samples.
> 
> Hi,
> 
> I'm hoping to pick the Pixel 3 stuff back up at some point, but right now there
> seem to be quite a few issues outside of DSC which make testing it a bit of a pain.
> 
> I gave Marijn's series [1] a go but wasn't able to get anything usable out of the
> panel, however I doubt this is a DSC issue as I've always needed some hacks to
> get the panel working - I've never had any success with it without skipping both
> the initial panel reset and sending the PPS payload.
> 
> I think if Marijn has managed to initialise a panel properly then the lack of
> Pixel 3 for validation shouldn't be a blocker to merge these fixes.
> 
> [1]:
> https://lore.kernel.org/linux-arm-msm/20221009184824.457416-1-marijn.suijten@somainline.org/
> 
>>
>> - Marijn

Alright, the onus is then on Vinod/ users of pixel3 to report/debug 
whatever issues arise out of this computation.

Patch itself LGTM, hence

Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>

> 
> --
> Kind Regards,
> Caleb
>
diff mbox series

Patch

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 83cde4d62b68..68c39debc22f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -21,6 +21,7 @@ 
 
 #include <video/mipi_display.h>
 
+#include <drm/display/drm_dsc_helper.h>
 #include <drm/drm_of.h>
 
 #include "dsi.h"
@@ -1771,14 +1772,6 @@  static char bpg_offset[DSC_NUM_BUF_RANGES] = {
 
 static int dsi_populate_dsc_params(struct drm_dsc_config *dsc)
 {
-	int mux_words_size;
-	int groups_per_line, groups_total;
-	int min_rate_buffer_size;
-	int hrd_delay;
-	int pre_num_extra_mux_bits, num_extra_mux_bits;
-	int slice_bits;
-	int data;
-	int final_value, final_scale;
 	int i;
 
 	dsc->rc_model_size = 8192;
@@ -1804,11 +1797,11 @@  static int dsi_populate_dsc_params(struct drm_dsc_config *dsc)
 	if (dsc->bits_per_pixel != 8)
 		dsc->initial_offset = 2048;	/* bpp = 12 */
 
-	mux_words_size = 48;		/* bpc == 8/10 */
-	if (dsc->bits_per_component == 12)
-		mux_words_size = 64;
+	if (dsc->bits_per_component <= 10)
+		dsc->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
+	else
+		dsc->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
 
-	dsc->mux_word_size = mux_words_size;
 	dsc->initial_xmit_delay = 512;
 	dsc->initial_scale_value = 32;
 	dsc->first_line_bpg_offset = 12;
@@ -1820,52 +1813,7 @@  static int dsi_populate_dsc_params(struct drm_dsc_config *dsc)
 	dsc->rc_quant_incr_limit0 = 11;
 	dsc->rc_quant_incr_limit1 = 11;
 
-	/* FIXME: need to call drm_dsc_compute_rc_parameters() so that rest of
-	 * params are calculated
-	 */
-	groups_per_line = DIV_ROUND_UP(dsc->slice_width, 3);
-	dsc->slice_chunk_size = DIV_ROUND_UP(dsc->slice_width * dsc->bits_per_pixel, 8);
-
-	/* rbs-min */
-	min_rate_buffer_size =  dsc->rc_model_size - dsc->initial_offset +
-				dsc->initial_xmit_delay * dsc->bits_per_pixel +
-				groups_per_line * dsc->first_line_bpg_offset;
-
-	hrd_delay = DIV_ROUND_UP(min_rate_buffer_size, dsc->bits_per_pixel);
-
-	dsc->initial_dec_delay = hrd_delay - dsc->initial_xmit_delay;
-
-	dsc->initial_scale_value = 8 * dsc->rc_model_size /
-				       (dsc->rc_model_size - dsc->initial_offset);
-
-	slice_bits = 8 * dsc->slice_chunk_size * dsc->slice_height;
-
-	groups_total = groups_per_line * dsc->slice_height;
-
-	data = dsc->first_line_bpg_offset * 2048;
-
-	dsc->nfl_bpg_offset = DIV_ROUND_UP(data, (dsc->slice_height - 1));
-
-	pre_num_extra_mux_bits = 3 * (mux_words_size + (4 * dsc->bits_per_component + 4) - 2);
-
-	num_extra_mux_bits = pre_num_extra_mux_bits - (mux_words_size -
-			     ((slice_bits - pre_num_extra_mux_bits) % mux_words_size));
-
-	data = 2048 * (dsc->rc_model_size - dsc->initial_offset + num_extra_mux_bits);
-	dsc->slice_bpg_offset = DIV_ROUND_UP(data, groups_total);
-
-	data = dsc->initial_xmit_delay * dsc->bits_per_pixel;
-	final_value =  dsc->rc_model_size - data + num_extra_mux_bits;
-	dsc->final_offset = final_value;
-
-	final_scale = 8 * dsc->rc_model_size / (dsc->rc_model_size - final_value);
-
-	data = (final_scale - 9) * (dsc->nfl_bpg_offset + dsc->slice_bpg_offset);
-	dsc->scale_increment_interval = (2048 * dsc->final_offset) / data;
-
-	dsc->scale_decrement_interval = groups_per_line / (dsc->initial_scale_value - 8);
-
-	return 0;
+	return drm_dsc_compute_rc_parameters(dsc);
 }
 
 static int dsi_host_parse_dt(struct msm_dsi_host *msm_host)