On 10/31/2024 2:44 PM, Dmitry Baryshkov wrote:
The const MAX_BRIDGES is unused after the commit 4d1a1e4686bd ("drm/msm:
remove msm_drm_private::bridges field"), drop it now.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.h | 1 -
1 file changed, 1 deletion(-)
Reviewed-
On Tue, 29 Oct 2024 14:42:10 -0500, Gax-c wrote:
> There may be a potential integer overflow issue in
> _dpu_core_perf_calc_clk(). crtc_clk is defined as u64, while
> mode->vtotal, mode->hdisplay, and drm_mode_vrefresh(mode) are defined as
> a smaller data type. The result of the calculation will
On Tue, 29 Oct 2024 22:28:23 +0200, Dmitry Baryshkov wrote:
> The LKP reported [1] a symbol clash between the drm/msm/dp and the HIMBC
> driver being sumbitted, because both of them use a generic dp_ prefix
> for a lot of symbols. It's a hight time we made msm/dp driver use
> something less gener
On Thu, 31 Oct 2024 23:44:05 +0200, Dmitry Baryshkov wrote:
> As I stumbled upon msm_display_topology define, perform minor cleanup of
> msm_drv.h incldue file.
>
>
Applied, thanks!
[1/3] drm/msm: move msm_display_topology to the DPU driver
https://gitlab.freedesktop.org/lumag/msm/-/com
On 10/31/2024 2:44 PM, Dmitry Baryshkov wrote:
The MAX_H_TILES_PER_DISPLAY const is only used by the DPU driver, move
it to the corresponding header.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 ++
drivers/gpu/drm/msm/msm_drv.h | 1 -
On 10/31/2024 2:44 PM, Dmitry Baryshkov wrote:
The struct msm_display_topology is only used by the DPU driver. Remove
it from the global header and move it to DPU-specific header.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 16
drivers/gpu
The MAX_H_TILES_PER_DISPLAY const is only used by the DPU driver, move
it to the corresponding header.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 ++
drivers/gpu/drm/msm/msm_drv.h | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff
On Wed, Oct 16, 2024 at 06:21:09PM -0700, Jessica Zhang wrote:
> From: Dmitry Baryshkov
>
> The struct dpu_rm_requirements was used to wrap display topology and
> hw resources, which meant INTF indices. As of commit ef58e0ad3436
> ("drm/msm/dpu: get INTF blocks directly rather than through RM") t
The struct msm_display_topology is only used by the DPU driver. Remove
it from the global header and move it to DPU-specific header.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 16
drivers/gpu/drm/msm/msm_drv.h | 16
2 f
The const MAX_BRIDGES is unused after the commit 4d1a1e4686bd ("drm/msm:
remove msm_drm_private::bridges field"), drop it now.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/
: 4a6fd06643afa99989a0e6b848e125099674227b
change-id: 20241031-dpu-move-topology-f5c4489830bd
Best regards,
--
Dmitry Baryshkov
On Thu, Oct 31, 2024 at 05:12:47PM +0200, Abel Vesa wrote:
> LTTPRs operating modes are defined by the DisplayPort standard and the
> generic framework now provides a helper to switch between them.
> So use the drm generic helper instead as it makes the code a bit cleaner.
>
> Signed-off-by: Abel
On Thu, Oct 31, 2024 at 05:12:45PM +0200, Abel Vesa wrote:
> According to the DisplayPort standard, LTTPRs have two operating
> modes:
> - non-transparent - it replies to DPCD LTTPR field specific AUX
>requests, while passes through all other AUX requests
> - transparent - it passes through a
On Thu, Oct 31, 2024 at 01:06:34PM -0700, Abhinav Kumar wrote:
>
>
> On 10/31/2024 8:11 AM, Dmitry Baryshkov wrote:
> > Hi Abhinav,
> >
> > On Wed, 30 Oct 2024 at 21:26, Abhinav Kumar
> > wrote:
> > >
> > >
> > >
> > > On 10/30/2024 3:48 AM, Dmitry Baryshkov wrote:
> > > > On Tue, Oct 29, 2
On Wed, Oct 16, 2024 at 06:21:11PM -0700, Jessica Zhang wrote:
> From: Dmitry Baryshkov
>
> All resource allocation is centered around the LMs. Then other blocks
> (except DSCs) are allocated basing on the LMs that was selected, and LM
> powers up the CRTC rather than the encoder.
>
> Moreover i
On 10/31/2024 12:30 PM, Dmitry Baryshkov wrote:
On Thu, Oct 31, 2024 at 11:45:53AM -0700, Abhinav Kumar wrote:
On 10/31/2024 11:23 AM, Dmitry Baryshkov wrote:
On Wed, 30 Oct 2024 at 03:07, Abhinav Kumar wrote:
of_i2c_register_devices() adds all child nodes of a given i2c bus
however in
On 30.10.2024 8:02 AM, Akhil P Oommen wrote:
> From: Puranam V G Tejaswi
>
> Enable GPU for sa8775p-ride platform and provide path for zap
> shader.
>
> Signed-off-by: Puranam V G Tejaswi
> Signed-off-by: Akhil P Oommen
> Reviewed-by: Dmitry Baryshkov
> ---
Reviewed-by: Konrad Dybcio
Konra
On 30.10.2024 8:02 AM, Akhil P Oommen wrote:
> From: Puranam V G Tejaswi
>
> Add gpu and gmu nodes for sa8775p chipset. As of now all
> SKUs have the same GPU fmax, so there is no requirement of
> speed bin support.
>
> Signed-off-by: Puranam V G Tejaswi
> Signed-off-by: Akhil P Oommen
> Revie
On Thu, Oct 31, 2024 at 11:45:53AM -0700, Abhinav Kumar wrote:
>
>
> On 10/31/2024 11:23 AM, Dmitry Baryshkov wrote:
> > On Wed, 30 Oct 2024 at 03:07, Abhinav Kumar
> > wrote:
> > >
> > > of_i2c_register_devices() adds all child nodes of a given i2c bus
> > > however in certain device trees of
On 10/31/2024 8:11 AM, Dmitry Baryshkov wrote:
Hi Abhinav,
On Wed, 30 Oct 2024 at 21:26, Abhinav Kumar wrote:
On 10/30/2024 3:48 AM, Dmitry Baryshkov wrote:
On Tue, Oct 29, 2024 at 02:30:12PM -0700, Abhinav Kumar wrote:
On 10/24/2024 5:20 PM, Dmitry Baryshkov wrote:
Only several SSP
On Thu, Oct 31, 2024 at 12:37:03PM -0700, Abhinav Kumar wrote:
>
>
> On 10/16/2024 6:21 PM, Jessica Zhang wrote:
> > From: Dmitry Baryshkov
> >
> > All resource allocation is centered around the LMs. Then other blocks
> > (except DSCs) are allocated basing on the LMs that was selected, and LM
>
On 10/16/2024 6:21 PM, Jessica Zhang wrote:
From: Dmitry Baryshkov
Stop poking into CRTC state from dpu_encoder.c, fill CRTC HW resources
from dpu_crtc_assign_resources().
Signed-off-by: Dmitry Baryshkov
[quic_abhin...@quicinc.com: cleaned up formatting]
Signed-off-by: Abhinav Kumar
Signe
On 10/16/2024 6:21 PM, Jessica Zhang wrote:
From: Dmitry Baryshkov
All resource allocation is centered around the LMs. Then other blocks
(except DSCs) are allocated basing on the LMs that was selected, and LM
powers up the CRTC rather than the encoder.
Moreover if at some point the driver s
On 10/16/2024 6:21 PM, Jessica Zhang wrote:
From: Dmitry Baryshkov
Up to now the driver has been using encoder to allocate hardware
resources. Switch it to use CRTC id in preparation for the next step.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/
On 10/31/2024 11:23 AM, Dmitry Baryshkov wrote:
On Wed, 30 Oct 2024 at 03:07, Abhinav Kumar wrote:
of_i2c_register_devices() adds all child nodes of a given i2c bus
however in certain device trees of_alias_from_compatible() and
of_property_read_u32() can fail as the child nodes of the devic
On Wed, 30 Oct 2024 at 03:07, Abhinav Kumar wrote:
>
> of_i2c_register_devices() adds all child nodes of a given i2c bus
> however in certain device trees of_alias_from_compatible() and
> of_property_read_u32() can fail as the child nodes of the device
> might not be valid i2c client devices. One
On Thu, Oct 31, 2024 at 05:12:46PM +0200, Abel Vesa wrote:
> LTTPRs operating modes are defined by the DisplayPort standard and the
> generic framework now provides a helper to switch between them.
> So use the drm generic helper instead as it makes the code a bit cleaner.
>
> Signed-off-by: Abel
On Thu, Oct 31, 2024 at 05:12:48PM +0200, Abel Vesa wrote:
> Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPort
> 1.4a specification. As the name suggests, these PHY repeaters are
> capable of adjusting their output for link training purposes.
>
> The msm DP driver is currentl
| 9 +++-
include/drm/display/drm_dp_helper.h| 1 +
5 files changed, 47 insertions(+), 7 deletions(-)
---
base-commit: 6fb2fa9805c501d9ade047fc511961f3273cdcb5
change-id: 20241031-drm-dp-msm-add-lttpr-transparent-mode-set-136cd5bfde07
Best regards,
--
Abel Vesa
On Thu, 31 Oct 2024 at 17:11, Dmitry Baryshkov
wrote:
>
> Hi Abhinav,
>
> On Wed, 30 Oct 2024 at 21:26, Abhinav Kumar wrote:
> > On 10/30/2024 3:48 AM, Dmitry Baryshkov wrote:
> > > On Tue, Oct 29, 2024 at 02:30:12PM -0700, Abhinav Kumar wrote:
> > >> On 10/24/2024 5:20 PM, Dmitry Baryshkov wrote
Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPort
1.4a specification. As the name suggests, these PHY repeaters are
capable of adjusting their output for link training purposes.
The msm DP driver is currently lacking any handling of LTTPRs.
This means that if at least one LTT
LTTPRs operating modes are defined by the DisplayPort standard and the
generic framework now provides a helper to switch between them.
So use the drm generic helper instead as it makes the code a bit cleaner.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 9 +++--
1 file
According to the DisplayPort standard, LTTPRs have two operating
modes:
- non-transparent - it replies to DPCD LTTPR field specific AUX
requests, while passes through all other AUX requests
- transparent - it passes through all AUX requests.
Switching between this two modes is done by the DPT
LTTPRs operating modes are defined by the DisplayPort standard and the
generic framework now provides a helper to switch between them.
So use the drm generic helper instead as it makes the code a bit cleaner.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2
Hi Abhinav,
On Wed, 30 Oct 2024 at 21:26, Abhinav Kumar wrote:
>
>
>
> On 10/30/2024 3:48 AM, Dmitry Baryshkov wrote:
> > On Tue, Oct 29, 2024 at 02:30:12PM -0700, Abhinav Kumar wrote:
> >>
> >>
> >> On 10/24/2024 5:20 PM, Dmitry Baryshkov wrote:
> >>> Only several SSPP blocks support such featur
35 matches
Mail list logo
