On 06/04/2023 02:34, Abhinav Kumar wrote:
On 4/5/2023 12:26 PM, Dmitry Baryshkov wrote:
On 05/04/2023 03:41, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
- Moved files up to msm/ directory
- Dropped
On 4/5/2023 12:26 PM, Dmitry Baryshkov wrote:
On 05/04/2023 03:41, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
- Moved files up to msm/ directory
- Dropped get_comp_ratio() helper
- Used drm_int2fixp() to
On 06/04/2023 01:02, Jessica Zhang wrote:
On 4/5/2023 12:26 PM, Dmitry Baryshkov wrote:
On 05/04/2023 03:41, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
- Moved files up to msm/ directory
- Dropped
On 4/5/2023 12:26 PM, Dmitry Baryshkov wrote:
On 05/04/2023 03:41, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
- Moved files up to msm/ directory
- Dropped get_comp_ratio() helper
- Used drm_int2fixp() to
On 4/5/2023 12:27 PM, Dmitry Baryshkov wrote:
On 05/04/2023 03:41, Jessica Zhang wrote:
Use MSM and DRM DSC helper methods to configure DSC for DSI.
Changes in V2:
- *_calculate_initial_scale_value --> *_set_initial_scale_value
- Split pkt_per_line and eol_byte_num changes to a separate
On 05/04/2023 03:41, Jessica Zhang wrote:
Currently, pkt_per_line is calculated by dividing slice_per_intf by
slice_count. This is incorrect, as slice_per_intf should be divided by
slice_per_pkt, which is not always equivalent to slice_count as it is
possible for there to be multiple soft slices
On 05/04/2023 03:41, Jessica Zhang wrote:
hdisplay for compressed images should be calculated as bytes_per_slice *
slice_count. Thus, use MSM DSC helper to calculate hdisplay for
dsi_timing_setup instead of directly using mode->hdisplay.
Changes in v3:
- Split from previous patch
- Initialized
On 05/04/2023 03:41, Jessica Zhang wrote:
Use MSM and DRM DSC helper methods to configure DSC for DSI.
Changes in V2:
- *_calculate_initial_scale_value --> *_set_initial_scale_value
- Split pkt_per_line and eol_byte_num changes to a separate patch
- Moved pclk_per_line calculation to hdisplay
On 05/04/2023 03:41, Jessica Zhang wrote:
Correct the math for slice_last_group_size so that it matches the
calculations downstream.
Changes in v3:
- Reworded slice_last_group_size calculation to
`(dsc->slice_width + 2) % 3`
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
On 05/04/2023 03:41, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
- Moved files up to msm/ directory
- Dropped get_comp_ratio() helper
- Used drm_int2fixp() to convert to integers to fp
- Style changes to
On Fri, Mar 10, 2023 at 01:05:36AM +0200, Dmitry Baryshkov wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 10/03/2023 00:20, Jordan Crouse wrote:
> >
On Fri, 31 Mar 2023 19:28:31 +0530, Vinod Polimera wrote:
> while in virtual terminal with PSR enabled, there will be
> no atomic commits triggered resulting in no screen update.
> Update the dirtyfb flag into plane state during atomic check
> to flush the pixel data explicitly.
>
> Avoid
On Wed, Apr 05, 2023 at 12:53:29AM +0300, Dmitry Baryshkov wrote:
> On 04/04/2023 22:16, Daniel Vetter wrote:
> > On Tue, Apr 04, 2023 at 08:22:05PM +0300, Dmitry Baryshkov wrote:
> > > On 08/03/2023 17:53, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > For an atomic commit updating a
Am 05.04.23 um 03:35 schrieb Dmitry Baryshkov:
On Mon, 03 Apr 2023 14:45:30 +0200, Thomas Zimmermann wrote:
Convert msm' fbdev code to struct drm_client. Replaces the current
ad-hoc integration. The conversion includes a number of cleanups. As
with most other drivers' fbdev emulation, fbdev
On 01/04/2023 13:54, Konrad Dybcio wrote:
> The "GMU Wrapper" is Qualcomm's name for "let's treat the GPU blocks
> we'd normally assign to the GMU as if they were a part of the GMU, even
> though they are not". It's a (good) software representation of the GMU_CX
> and GMU_GX register spaces within
15 matches
Mail list logo
