On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote:
This function does nothing, just clears several data pointers. Drop it
now.
This will undo what dpu_core_perf_init() did when an error happens.
Why can we drop that?
Signed-off-by: Dmitry Baryshkov
---
On 7/3/2023 3:53 PM, Dmitry Baryshkov wrote:
On Tue, 4 Jul 2023 at 01:37, Abhinav Kumar wrote:
On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote:
The stop_req is true only in the dpu_crtc_disable() case, when
crtc->enable has already been set to false. This renders the stop_req
argum
On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote:
The stop_req is true only in the dpu_crtc_disable() case, when
crtc->enable has already been set to false. This renders the stop_req
argument useless. Remove it completely.
What about the enable case?
That time dpu_crtc->enabled will be false
On 7/3/2023 3:20 PM, Dmitry Baryshkov wrote:
On Tue, 4 Jul 2023 at 00:40, Abhinav Kumar wrote:
On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote:
DPU performance module contains code to change performance state
calculations. In addition to normal (sum plane and CRTC requirements),
it can
of the checks were like this due to checkpatch's earlier
limit being 80 chars.
With that relaxed, this should be fine. Hence,
Reviewed-by: Abhinav Kumar
I am unable to apply this in my branch for some reason but, hope this
doesnt break checkpatch now :)
On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote:
The max_per_pipe_ib is a constant across all CRTCs and is read from the
catalog. Drop corresponding calculations and read the value directly at
icc_set_bw() time.
Suggested-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
This will need
On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote:
DPU performance module contains code to change performance state
calculations. In addition to normal (sum plane and CRTC requirements),
it can work in 'minimal' or 'fixed' modes. Both modes are impractical,
since they can easily end up with the
unused, hence
Reviewed-by: Abhinav Kumar
Since its just dropping unused enum, will see if I can combine with some
other more critical fixes into a MR but not one on its own.
/disp/dpu1/catalog/dpu_4_0_sdm845.h | 4
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 --
3 files changed, 10 deletions(-)
Reviewed-by: Abhinav Kumar
On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:
The MERGE_3D_SM8150_MASK features mask is zero. Drop it completely.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Abhinav Kumar
---
Reviewed-by: Abhinav Kumar
---
Reviewed-by: Abhinav Kumar
---
Reviewed-by: Abhinav Kumar
On 7/3/2023 1:58 PM, Dmitry Baryshkov wrote:
On Mon, 3 Jul 2023 at 23:29, Abhinav Kumar wrote:
On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
the
On 6/27/2023 1:29 AM, Marijn Suijten wrote:
On 2023-06-20 00:25:13, Dmitry Baryshkov wrote:
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Tested-by: Marijn Suijten
comment as the other change, I have cross-checked most of the
entries to make sure they match the pre-inlining values.
For the rest, I am going to rely on Marijn's checksum method.
Hence,
Reviewed-by: Abhinav Kumar
---
Reviewed-by: Abhinav Kumar
checked a few of the entries to make sure there are no copy-paste
errors but not all of them.
I am going to rely on Marijn's checksum method results that there were
no differences in the checksum and go ahead with my,
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Abhinav Kumar
On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:
Drop useless zero assignments to the dpu_ctl_cfg::features field.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Abhinav Kumar
On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:
Drop useless zero assignments to the dpu_mdp_cfg::features field.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Abhinav Kumar
On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:
Use more standard initialisation for .clk_ctrls definitions. Define a
single .clk_ctrls field and use array init inside.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Abhinav Kumar
On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:
Since there is always just a single MDP_TOP instance, drop the enum
dpu_mdp and corresponding index value.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Abhinav Kumar
On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:
There is always a single MDP TOP block. Drop the mdp_count field and
stop declaring dpu_mdp_cfg instances as arrays.
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
The change drops mdp_count and stops using the array which is
On 7/2/2023 6:36 PM, Dmitry Baryshkov wrote:
On Mon, 3 Jul 2023 at 04:34, Abhinav Kumar wrote:
On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:
For each LM there is at max 1 peer LM which can be driven by the same
CTL, so there no need to have a mask instead of just an ID of the peer
LM
On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:
For each LM there is at max 1 peer LM which can be driven by the same
CTL, so there no need to have a mask instead of just an ID of the peer
LM.
The change is ok but the wording seems incorrect. Are you implying that
only LM0 and LM1 can be
Baryshkov
---
Reviewed-by: Abhinav Kumar
On 6/29/2023 8:22 PM, Dmitry Baryshkov wrote:
On 30/06/2023 06:07, Abhinav Kumar wrote:
On 6/29/2023 5:20 PM, Dmitry Baryshkov wrote:
On 29/06/2023 22:29, Abhinav Kumar wrote:
Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu
On 6/29/2023 5:24 PM, Dmitry Baryshkov wrote:
On 29/06/2023 22:29, Abhinav Kumar wrote:
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however also necessitates
On 6/29/2023 5:13 PM, Dmitry Baryshkov wrote:
On 29/06/2023 22:29, Abhinav Kumar wrote:
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however also necessitates
On 6/29/2023 5:20 PM, Dmitry Baryshkov wrote:
On 29/06/2023 22:29, Abhinav Kumar wrote:
Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version instead.
This will avoid defining feature bits for every bit level details
On 6/24/2023 7:44 PM, Abhinav Kumar wrote:
On 6/24/2023 8:03 AM, Dmitry Baryshkov wrote:
On 24/06/2023 17:17, Abhinav Kumar wrote:
On 6/24/2023 5:07 AM, Dmitry Baryshkov wrote:
On 24/06/2023 03:09, Abhinav Kumar wrote:
On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:
On 23/06/2023 02
Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced
with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS
from the catalog completely.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1
reedesktop.org/patch/530891/?series=113910=4
changes in v3:
- drop DPU step version as features are not changing across steps
- add core_major_version / core_minor_version to avoid conflicts
- update the commit text to drop references to the dpu macros
Signed-off-by:
it to accept a struct intf_dpu_datapath_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.
Signed-off-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 9 +++--
drivers/gpu/drm/msm/disp/dpu1
ktop.org/patch/530891/?series=113910=4
changes in v2:
- drop DPU step version as features are not changing across steps
- add core_major_version / core_minor_version to avoid conflicts
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 2 +
Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced
with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS
from the catalog completely.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1
it to accept a struct intf_dpu_datapath_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.
Signed-off-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 9 +++--
drivers/gpu/drm/msm/disp/dpu1
On 6/22/2023 4:37 PM, Abhinav Kumar wrote:
On 6/22/2023 4:14 PM, Dmitry Baryshkov wrote:
On 23/06/2023 01:37, Abhinav Kumar wrote:
On 6/21/2023 4:46 PM, Dmitry Baryshkov wrote:
On 22/06/2023 02:01, Abhinav Kumar wrote:
On 6/21/2023 9:36 AM, Dmitry Baryshkov wrote:
On 21/06/2023 18
On 6/26/2023 7:04 AM, Dmitry Baryshkov wrote:
On 24/06/2023 03:41, Marijn Suijten wrote:
SM6125 is identical to SM6375 except that while downstream also defines
a throttle clock, its presence results in timeouts whereas SM6375
requires it to not observe any timeouts.
I see that the vendor
On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:
On 28/06/2023 00:27, Jessica Zhang wrote:
On 6/27/2023 12:58 AM, Pekka Paalanen wrote:
On Mon, 26 Jun 2023 16:02:50 -0700
Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica
On 6/24/2023 8:03 AM, Dmitry Baryshkov wrote:
On 24/06/2023 17:17, Abhinav Kumar wrote:
On 6/24/2023 5:07 AM, Dmitry Baryshkov wrote:
On 24/06/2023 03:09, Abhinav Kumar wrote:
On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:
On 23/06/2023 02:48, Ryan McCann wrote:
Currently, the device
On 6/24/2023 5:07 AM, Dmitry Baryshkov wrote:
On 24/06/2023 03:09, Abhinav Kumar wrote:
On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:
On 23/06/2023 02:48, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of
sub
blocks within the DSPP, SSPP, DSC
On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:
On 23/06/2023 02:48, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of sub
blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Add wrapper
function to dump hardware blocks that contain sub blocks.
On 6/23/2023 1:18 PM, Marijn Suijten wrote:
On 2023-06-23 23:10:56, Dmitry Baryshkov wrote:
There is no confusion between what was said earlier and now.
This line is calculating the number of pclks needed to transmit one line
of the compressed data:
hdisplay =
On 6/23/2023 1:28 PM, Marijn Suijten wrote:
On 2023-06-23 14:37:12, Dmitry Baryshkov wrote:
In fact I asked to make it 0xf00 + 0x10 or 0xf80 + 0x10 to also cover
the CTL registers, but that change didn't make it through. 0x29c is an
arbitrary number that I have no clue what it was based
On 6/23/2023 2:33 PM, Marijn Suijten wrote:
On 2023-06-23 13:34:06, Abhinav Kumar wrote:
On 6/23/2023 1:14 PM, Marijn Suijten wrote:
On 2023-06-23 10:29:51, Abhinav Kumar wrote:
The concept is quite simple
one pixel per clock for uncompresssed without widebubus
2 pixels per clock
On 6/23/2023 1:14 PM, Marijn Suijten wrote:
On 2023-06-23 10:29:51, Abhinav Kumar wrote:
The concept is quite simple
one pixel per clock for uncompresssed without widebubus
2 pixels per clock for uncompressed with widebus (only enabled for DP
not DSI)
3 bytes worth of data for compressed
On 6/23/2023 12:26 AM, Marijn Suijten wrote:
On 2023-06-22 17:32:17, Abhinav Kumar wrote:
On 6/22/2023 5:17 PM, Dmitry Baryshkov wrote:
On 23/06/2023 03:14, Abhinav Kumar wrote:
On 6/19/2023 2:06 PM, Dmitry Baryshkov wrote:
Provide actual documentation for the pclk and hdisplay
On 6/23/2023 12:40 PM, Dmitry Baryshkov wrote:
On 23/06/2023 22:37, Abhinav Kumar wrote:
On 6/23/2023 4:37 AM, Dmitry Baryshkov wrote:
On 23/06/2023 09:54, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2
On 6/23/2023 4:37 AM, Dmitry Baryshkov wrote:
On 23/06/2023 09:54, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block
length.
This includes the common block
On 6/22/2023 11:57 PM, Marijn Suijten wrote:
On 2023-06-23 08:54:39, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block
On 6/23/2023 6:58 AM, Dmitry Baryshkov wrote:
Ryan pointed out [1] that some (most) of of sub-blocks do not fill the
field `name'. Further research showed that we can drop the fields `name'
and `id' and further simplify the catalog. The handling code also
usually knows, which sub-block it is
On 6/23/2023 4:25 AM, Dmitry Baryshkov wrote:
On 23/06/2023 08:47, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block itself, enc subblocks and some empty
space around
On 6/23/2023 12:19 AM, Marijn Suijten wrote:
On 2023-06-22 17:01:34, Abhinav Kumar wrote:
More interesting would be a link to the Mesa MR upstreaming this
bitfield to dsi.xml [2] (which I have not found on my own yet).
[2]:
https://gitlab.freedesktop.org/mesa/mesa/-/blame/main/src
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block itself, enc subblocks and some empty
space around. Change that to pass 0x4 instead, the length of common
register block itself.
Fixes:
On 6/22/2023 5:17 PM, Dmitry Baryshkov wrote:
On 23/06/2023 03:14, Abhinav Kumar wrote:
On 6/19/2023 2:06 PM, Dmitry Baryshkov wrote:
Provide actual documentation for the pclk and hdisplay calculations in
the case of DSC compression being used.
Signed-off-by: Dmitry Baryshkov
On 6/19/2023 2:06 PM, Dmitry Baryshkov wrote:
Provide actual documentation for the pclk and hdisplay calculations in
the case of DSC compression being used.
Signed-off-by: Dmitry Baryshkov
---
Changes since v1:
- Converted dsi_adjust_pclk_for_compression() into kerneldoc (Marijn)
- Added a
On 6/14/2023 2:56 AM, Marijn Suijten wrote:
On 2023-06-13 18:57:13, Jessica Zhang wrote:
DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
48 bits of compressed data per pclk instead of 24.
For all chipsets that support this mode, enable it whenever DSC is
enabled as
On 6/22/2023 4:14 PM, Dmitry Baryshkov wrote:
On 23/06/2023 01:37, Abhinav Kumar wrote:
On 6/21/2023 4:46 PM, Dmitry Baryshkov wrote:
On 22/06/2023 02:01, Abhinav Kumar wrote:
On 6/21/2023 9:36 AM, Dmitry Baryshkov wrote:
On 21/06/2023 18:17, Marijn Suijten wrote:
On 2023-06-20 14:38
On 6/14/2023 3:03 AM, Marijn Suijten wrote:
On 2023-06-14 10:49:31, Dmitry Baryshkov wrote:
On 14/06/2023 04:57, Jessica Zhang wrote:
DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
48 bits of compressed data per pclk instead of 24.
For all chipsets that support this
On 6/21/2023 4:46 PM, Dmitry Baryshkov wrote:
On 22/06/2023 02:01, Abhinav Kumar wrote:
On 6/21/2023 9:36 AM, Dmitry Baryshkov wrote:
On 21/06/2023 18:17, Marijn Suijten wrote:
On 2023-06-20 14:38:34, Jessica Zhang wrote:
+ if (phys_enc->hw_intf->ops.enable_w
On 6/22/2023 7:00 AM, Dmitry Baryshkov wrote:
On 21/06/2023 19:18, Kuogee Hsieh wrote:
Currently DSI DSC struct is populated at display setup during
system bootup. This mechanism works fine with embedded display
but not for pluggable displays as the DSC struct will become
stale once external
On 6/21/2023 9:36 AM, Dmitry Baryshkov wrote:
On 21/06/2023 18:17, Marijn Suijten wrote:
On 2023-06-20 14:38:34, Jessica Zhang wrote:
+ if (phys_enc->hw_intf->ops.enable_widebus)
+ phys_enc->hw_intf->ops.enable_widebus(phys_enc->hw_intf);
No. Please provide a single function
On 6/14/2023 12:49 AM, Dmitry Baryshkov wrote:
On 14/06/2023 04:57, Jessica Zhang wrote:
DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
48 bits of compressed data per pclk instead of 24.
For all chipsets that support this mode, enable it whenever DSC is
enabled as
On 6/14/2023 12:56 AM, Dmitry Baryshkov wrote:
On 14/06/2023 04:57, Jessica Zhang wrote:
Add a DPU INTF op to set the DATABUS_WIDEN register to enable the
databus-widen mode datapath.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++
On 6/14/2023 2:41 PM, Marijn Suijten wrote:
On 2023-06-14 13:39:57, Abhinav Kumar wrote:
On 6/14/2023 12:54 PM, Abhinav Kumar wrote:
On 6/14/2023 12:35 PM, Abhinav Kumar wrote:
On 6/14/2023 5:23 AM, Marijn Suijten wrote:
On 2023-06-14 15:01:59, Dmitry Baryshkov wrote:
On 14/06/2023 14:42
On 6/14/2023 1:43 PM, Dmitry Baryshkov wrote:
On 14/06/2023 23:39, Abhinav Kumar wrote:
On 6/14/2023 12:54 PM, Abhinav Kumar wrote:
On 6/14/2023 12:35 PM, Abhinav Kumar wrote:
On 6/14/2023 5:23 AM, Marijn Suijten wrote:
On 2023-06-14 15:01:59, Dmitry Baryshkov wrote:
On 14/06/2023
On 6/14/2023 3:49 PM, Marijn Suijten wrote:
On 2023-06-14 14:23:38, Marijn Suijten wrote:
Tested this on SM8350 which actually has DSI 2.5, and it is also
corrupted with this series so something else on this series might be
broken.
Never mind, this was a bad conflict-resolve. Jessica's
On 6/14/2023 12:54 PM, Abhinav Kumar wrote:
On 6/14/2023 12:35 PM, Abhinav Kumar wrote:
On 6/14/2023 5:23 AM, Marijn Suijten wrote:
On 2023-06-14 15:01:59, Dmitry Baryshkov wrote:
On 14/06/2023 14:42, Marijn Suijten wrote:
On 2023-06-13 18:57:11, Jessica Zhang wrote:
DPU 5.x+ supports
On 6/14/2023 12:35 PM, Abhinav Kumar wrote:
On 6/14/2023 5:23 AM, Marijn Suijten wrote:
On 2023-06-14 15:01:59, Dmitry Baryshkov wrote:
On 14/06/2023 14:42, Marijn Suijten wrote:
On 2023-06-13 18:57:11, Jessica Zhang wrote:
DPU 5.x+ supports a databus widen mode that allows more data
On 6/14/2023 5:23 AM, Marijn Suijten wrote:
On 2023-06-14 15:01:59, Dmitry Baryshkov wrote:
On 14/06/2023 14:42, Marijn Suijten wrote:
On 2023-06-13 18:57:11, Jessica Zhang wrote:
DPU 5.x+ supports a databus widen mode that allows more data to be sent
per pclk. Enable this feature flag on
On 6/12/2023 5:09 PM, Dmitry Baryshkov wrote:
In several catalog entries we did not use existing MSM_DP_CONTROLLER_n
constants. Fill them in. Also use freshly defined MSM_DSI_CONTROLLER_n
for DSI interfaces.
Signed-off-by: Dmitry Baryshkov
---
On 6/13/2023 3:19 PM, Kuogee Hsieh wrote:
ince struct drm_dsc_config is stored at atomic_enable() instead
S got cut off in since
of display setup time during boot up, saving struct drm_dsc_config
at struct msm_display_info is not necessary. Lets drop the dsc member
from struct
On 6/13/2023 3:19 PM, Kuogee Hsieh wrote:
moving retrieving struct drm_dsc_cofnig from setup_display to
atomic_enable() and delete struct drm_dsc_config from
struct msm_display_info.
This needs re-wording.
Currently, struct drm_dsc_config is retrieved from DSI driver in
On 6/12/2023 5:09 PM, Dmitry Baryshkov wrote:
Follow the DP example and define MSM_DSI_CONTROLLER_n enumeration.
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Abhinav Kumar
On 6/12/2023 5:09 PM, Dmitry Baryshkov wrote:
sm6115 and qcm2290 do not have INTF_0. Drop corresponding interface
definitions.
And sm6375 as you are touching that too
Signed-off-by: Dmitry Baryshkov
---
You can fix that while applying.
Reviewed-by: Abhinav Kumar
On 6/12/2023 5:09 PM, Dmitry Baryshkov wrote:
Each MERGE_3D block has just two registers. Correct the block length
accordingly.
Fixes: 4369c93cf36b ("drm/msm/dpu: initial support for merge3D hardware block")
Signed-off-by: Dmitry Baryshkov
---
LGTM,
Reviewed-by: Abhinav Kumar
m/dpu: replace IRQ lookup with the data in hw
catalog")
Signed-off-by: Dmitry Baryshkov
---
Yes, was indeed a mistake
Reviewed-by: Abhinav Kumar
Hi Doug
On 6/13/2023 12:33 PM, Doug Anderson wrote:
Hi,
On Mon, Jun 12, 2023 at 3:40 PM Dmitry Baryshkov
wrote:
On 13/06/2023 01:01, Bjorn Andersson wrote:
Using devres to depopulate the aux bus made sure that upon a probe
deferral the EDP panel device would be destroyed and recreated upon
changed, 17 insertions(+), 4 deletions(-)
This change itself is fine, hence
Reviewed-by: Abhinav Kumar
one note below for a future cleanup:
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index 36ea1af10894
)
Reported-by: Yongqin Liu
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
LGTM,
Reviewed-by: Abhinav Kumar
On 6/11/2023 3:03 PM, Marijn Suijten wrote:
On 2023-06-09 15:57:18, Jessica Zhang wrote:
Add documentation comments explaining the pclk_rate and hdisplay math
related to DSC.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 10 ++
1 file changed, 10
On 6/8/2023 12:51 PM, Abhinav Kumar wrote:
On 6/7/2023 2:56 PM, Dmitry Baryshkov wrote:
On 08/06/2023 00:05, Abhinav Kumar wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
Only several SSPP blocks support such features as YUV output or
scaling,
thus different DRM planes have
On 6/9/2023 3:57 PM, Jessica Zhang wrote:
Adjust the pclk rate to divide hdisplay by the compression ratio when DSC
is enabled.
Signed-off-by: Jessica Zhang
---
Reviewed-by: Abhinav Kumar
for DP.
Signed-off-by: Jessica Zhang
---
Reviewed-by: Abhinav Kumar
On 6/8/2023 5:56 PM, Jessica Zhang wrote:
On 6/8/2023 1:36 PM, Marijn Suijten wrote:
Same title suggestion as earlier: s/adjust/reduce
Hi Marijn,
Acked.
On 2023-05-22 18:08:56, Jessica Zhang wrote:
Adjust the pclk rate to divide hdisplay by the compression ratio when
DSC
is
On 6/7/2023 2:56 PM, Dmitry Baryshkov wrote:
On 08/06/2023 00:05, Abhinav Kumar wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting
On 6/6/2023 4:21 PM, Dmitry Baryshkov wrote:
On 07/06/2023 02:14, Abhinav Kumar wrote:
On 6/6/2023 3:59 PM, Dmitry Baryshkov wrote:
On 07/06/2023 01:57, Abhinav Kumar wrote:
On 6/6/2023 3:50 PM, Dmitry Baryshkov wrote:
On 07/06/2023 01:47, Abhinav Kumar wrote:
On 6/6/2023 2:52 PM
On 6/6/2023 3:59 PM, Dmitry Baryshkov wrote:
On 07/06/2023 01:57, Abhinav Kumar wrote:
On 6/6/2023 3:50 PM, Dmitry Baryshkov wrote:
On 07/06/2023 01:47, Abhinav Kumar wrote:
On 6/6/2023 2:52 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:47, Abhinav Kumar wrote:
On 6/6/2023 2:29 PM
On 6/6/2023 3:50 PM, Dmitry Baryshkov wrote:
On 07/06/2023 01:47, Abhinav Kumar wrote:
On 6/6/2023 2:52 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:47, Abhinav Kumar wrote:
On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM
On 6/6/2023 2:52 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:47, Abhinav Kumar wrote:
On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar
wrote:
On 3/20
Hi Dmitry
On 6/6/2023 1:21 PM, Dmitry Baryshkov wrote:
On 06/06/2023 23:11, Kuogee Hsieh wrote:
From: Abhinav Kumar
Some platforms have DSC blocks which have not been declared in the
catalog.
Complete DSC 1.1 support for all platforms by adding the missing
blocks to
MSM8998.
'Some
On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar
wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list
On 6/6/2023 2:08 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:01, Dmitry Baryshkov wrote:
On 06/06/2023 22:28, Abhinav Kumar wrote:
On 6/6/2023 12:09 PM, Dmitry Baryshkov wrote:
On 06/06/2023 20:51, Abhinav Kumar wrote:
On 6/6/2023 4:14 AM, Dmitry Baryshkov wrote:
On Tue, 6 Jun 2023
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of supported formats
to the hw catalog entry. It will be used to setup universal planes
On 6/6/2023 1:29 PM, Dmitry Baryshkov wrote:
On 06/06/2023 23:25, Abhinav Kumar wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
Remove historical fields intfs_swapped and topology fields from struct
dpu_encoder_virt and also remove even more historical docs.
Signed-off-by: Dmitry
On 5/24/2023 6:40 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:04, Abhinav Kumar wrote:
On 5/24/2023 3:46 PM, Abhinav Kumar wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
In preparation to virtualized planes support, move pstate->pipe
initialization f
601 - 700 of 2007 matches
Mail list logo
