Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.
Representation: master_flush && (PCC_flush | IGC_flush .. etc )
This change adds necessary support for the above design.
Changes in v1:
- Few nit
Doing some self-review as these patches accrued some bit-rot while
waiting to be sent.
On 2022-10-01 21:08:05, Marijn Suijten wrote:
> drm_dsc_config's bits_per_pixel field holds a fractional value with 4
> bits, which all panel drivers should adhere to for
> drm_dsc_pps_payload_pack() to generate
On 1.10.2022 21:08, Marijn Suijten wrote:
> drm_dsc_config's bits_per_pixel field holds a fractional value with 4
> bits, which all panel drivers should adhere to for
> drm_dsc_pps_payload_pack() to generate a valid payload. All code in the
> DSI driver here seems to assume that this field does
On 2022-10-01 21:08:07, Marijn Suijten wrote:
> msm's dsi_host specifies negative BPG offsets which fill the full 8 bits
> of a char thanks to two's complement: this however results in those bits
> bleeding into the next parameter when the field is only expected to
> contain 6-bit wide values.
> As
On 1.10.2022 21:08, Marijn Suijten wrote:
> slice_per_intf is already computed for intf_width, which holds the same
> value as hdisplay.
>
> Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
> Signed-off-by: Marijn Suijten
> ---
Reviewed-by: Konrad Dybcio
Konrad
> drive
On 1.10.2022 21:08, Marijn Suijten wrote:
> Multiplying a value by 2 and adding 1 to it always results in a value
> that is uneven, and that 1 gets truncated immediately when performing
> integer division by 2 again. There is no "rounding" possible here.
>
> Fixes: b9080324d6ca ("drm/msm/dsi:
msm's dsi_host specifies negative BPG offsets which fill the full 8 bits
of a char thanks to two's complement: this however results in those bits
bleeding into the next parameter when the field is only expected to
contain 6-bit wide values.
As a consequence random slices appear corrupted on-screen
According to the comment this DPU register contains the bits per pixel
as a 6.4 fractional value, conveniently matching the contents of
bits_per_pixel in struct drm_dsc_config which also uses 4 fractional
bits. However, the downstream source this implementation was
copy-pasted from has its bpp fie
drm_dsc_config's bits_per_pixel field holds a fractional value with 4
bits, which all panel drivers should adhere to for
drm_dsc_pps_payload_pack() to generate a valid payload. All code in the
DSI driver here seems to assume that this field doesn't contain any
fractional bits, hence resulting in t
slice_per_intf is already computed for intf_width, which holds the same
value as hdisplay.
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff
Multiplying a value by 2 and adding 1 to it always results in a value
that is uneven, and that 1 gets truncated immediately when performing
integer division by 2 again. There is no "rounding" possible here.
Fixes: b9080324d6ca ("drm/msm/dsi: add support for dsc data")
Signed-off-by: Marijn Suijte
Various removals of complex yet unnecessary math, fixing all uses of
drm_dsc_config::bits_per_pixel to deal with the fact that this field
includes four fractional bits, and finally an approach for dealing with
dsi_host setting negative values in range_bpg_offset, resulting in
overflow inside drm_ds
On Sat, 1 Oct 2022 at 17:25, Kalyan Thota wrote:
>
>
> >-Original Message-
> >From: Dmitry Baryshkov
> >Sent: Friday, September 30, 2022 1:59 PM
> >To: Doug Anderson ; Kalyan Thota (QUIC)
> >
> >Cc: y...@qualcomm.com; dri-devel ;
> >linux-arm-
> >msm ; freedreno
> >; open list:OPEN FIRMW
On 2022-09-24 15:19:00, Dmitry Baryshkov wrote:
> From: Loic Poulain
>
> The QCM2290 SoC a the 14nm (V2.0) single DSI phy. The platform is not
> fully compatible with the standard 14nm PHY, so it requires a separate
> compatible and config entry.
>
> Signed-off-by: Loic Poulain
> [DB: rebased a
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Friday, September 30, 2022 1:59 PM
>To: Doug Anderson ; Kalyan Thota (QUIC)
>
>Cc: y...@qualcomm.com; dri-devel ; linux-arm-
>msm ; freedreno
>; open list:OPEN FIRMWARE AND FLATTENED
>DEVICE TREE BINDINGS ; LKML ker...@vger.kernel.org>; R
On 29 September 2022 19:13:20 GMT+03:00, Doug Anderson
wrote:
>Hi,
>
>On Wed, Sep 14, 2022 at 5:16 AM Kalyan Thota wrote:
>>
>> Flush mechanism for DSPP blocks has changed in sc7280 family, it
>> allows individual sub blocks to be flushed in coordination with
>> master flush control.
>>
>> Re
On 29 September 2022 19:13:20 GMT+03:00, Doug Anderson
wrote:
>Hi,
>
>On Wed, Sep 14, 2022 at 5:16 AM Kalyan Thota wrote:
>>
>> Flush mechanism for DSPP blocks has changed in sc7280 family, it
>> allows individual sub blocks to be flushed in coordination with
>> master flush control.
>>
>> Re
17 matches
Mail list logo
