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 <[email protected]>
---
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 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/[email protected]/
- 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 <[email protected]>
> ---
> 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 <[email protected]>
> ---
> 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/[email protected]/
>
> - 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/[email protected]/
>
>>
>> - 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 <[email protected]>
>
> --
> Kind Regards,
> Caleb
>