| Message ID | 20221009185058.460688-1-marijn.suijten@somainline.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | None | expand |
On 2022-10-09 20:50:54, Marijn Suijten wrote: Apologies. After attempting to recover from an unexpected interruption _right as I was sending this series_, this patch got sent twice as it only later appeared to also have made its way through in the first round [1], together with the cover letter and first five patches. [1]: https://lore.kernel.org/linux-arm-msm/20221009184824.457416-7-marijn.suijten@somainline.org/ - Marijn > 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(-) > > 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) > -- > 2.38.0 >
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)
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
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
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
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
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 --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)
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(-)