Re: [Freedreno] [PATCH v3 06/10] drm/msm/dsi: Migrate to drm_dsc_compute_rc_parameters()
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=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.suij...@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 -- Kind Regards, Caleb
Re: [Freedreno] [PATCH v3 06/10] drm/msm/dsi: Migrate to drm_dsc_compute_rc_parameters()
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=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.suij...@somainline.org/ > > - Marijn -- Kind Regards, Caleb
Re: [Freedreno] [PATCH v3 06/10] drm/msm/dsi: Migrate to drm_dsc_compute_rc_parameters()
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=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
Re: [Freedreno] [PATCH v3 06/10] drm/msm/dsi: Migrate to drm_dsc_compute_rc_parameters()
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=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
Re: [Freedreno] [PATCH v3 06/10] drm/msm/dsi: Migrate to drm_dsc_compute_rc_parameters()
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=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
Re: [Freedreno] [PATCH v3 06/10] drm/msm/dsi: Migrate to drm_dsc_compute_rc_parameters()
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
---
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
+#include
#include
#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 -
