On Fri, Jan 24, 2025 at 04:08:17PM -0800, Abhinav Kumar wrote:
>
>
> On 1/23/2025 9:19 PM, Dmitry Baryshkov wrote:
> > On Thu, Jan 23, 2025 at 01:41:14PM -0800, Abhinav Kumar wrote:
> > >
> > >
> > > On 1/23/2025 1:32 PM, Abhinav Kumar wrote:
> > > >
> > > >
> > > > On 12/13/2024 2:14 PM, Dmi
On 1/23/2025 9:19 PM, Dmitry Baryshkov wrote:
On Thu, Jan 23, 2025 at 01:41:14PM -0800, Abhinav Kumar wrote:
On 1/23/2025 1:32 PM, Abhinav Kumar wrote:
On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
Continue migration to the MDSS-revision based checks and replace
DPU_PINGPONG_DSC featur
The GENERIC0_UPDATE field is a single bit. Redefine it as boolean to
simplify its usage in the driver.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/registers/display/hdmi.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
Change MSM HDMI bridge to use atomic_* callbacks in preparation to
enablign the HDMI connector support.
Acked-by: Maxime Ripard
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 13 +
1 file changed, 9 insertions(+), 4 deletions
Use connector->display_info.is_hdmi instead of manually using
drm_detect_hdmi_monitor().
Acked-by: Maxime Ripard
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 2 +-
drivers/gpu/drm/msm/hdmi/hdmi.h| 2 --
drivers/gpu/drm/msm/hd
Extend the driver to send SPD and HDMI Vendor Specific InfoFrames.
While the HDMI block has special block to send HVS InfoFrame, use
GENERIC0 block instead. VENSPEC_INFO registers pack frame data in a way
that requires manual repacking in the driver, while GENERIC0 doesn't
have such format require
The mode_set callback is deprecated, it doesn't get the
drm_bridge_state, just mode-related argumetns. Also Abhinav pointed out
that HDMI timings should be programmed after setting up HDMI PHY and
PLL. Rework the code to program HDMI timings at the end of
atomic_pre_enable().
Signed-off-by: Dmitry
Setup the HDMI connector on the MSM HDMI outputs. Make use of
atomic_check hook and of the provided Infoframe infrastructure.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig| 2 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 45 ++---
drive
In order to simplify the driver even further and to remove the
boilerplate code, rewrite the audio interface to use the DRM HDMI Audio
framework.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 91 --
drivers/gpu/drm/msm/hdmi/hdmi.h
This patchset sits on top Maxime's HDMI connector patchset ([1]).
Currently this is an RFC exploring the interface between HDMI bridges
and HDMI connector code. This has been lightly verified on the Qualcomm
DB820c, which has native HDMI output. If this approach is considered to
be acceptable, I'l
Jessica Zhang 于2025年1月23日周四 15:32写道：
>
>
>
> On 1/17/2025 8:00 AM, Jun Nie wrote:
> > 2 or more SSPPs and dual-DSI interface are need for super wide panel.
> > And 4 DSC are preferred for power optimal in this case due to width
> > limitation of SSPP and MDP clock rate constrain. This patch set
>
On Fri, Jan 24, 2025 at 03:12:41PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 24, 2025 at 01:59:15PM +0100, Simona Vetter wrote:
> > On Fri, Jan 24, 2025 at 02:10:54PM +0200, Ville Syrjälä wrote:
> > > On Fri, Jan 24, 2025 at 01:14:18PM +0200, Dmitry Baryshkov wrote:
> > > > There are several driver
On Fri, Jan 24, 2025 at 04:37:39PM +0100, Simona Vetter wrote:
> On Fri, Jan 24, 2025 at 03:12:41PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 24, 2025 at 01:59:15PM +0100, Simona Vetter wrote:
> > > On Fri, Jan 24, 2025 at 02:10:54PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Jan 24, 2025 at 01:
On Fri, Jan 24, 2025 at 03:12:41PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 24, 2025 at 01:59:15PM +0100, Simona Vetter wrote:
> > On Fri, Jan 24, 2025 at 02:10:54PM +0200, Ville Syrjälä wrote:
> > > On Fri, Jan 24, 2025 at 01:14:18PM +0200, Dmitry Baryshkov wrote:
> > > > There are several driver
On Fri, Jan 24, 2025 at 01:59:15PM +0100, Simona Vetter wrote:
> On Fri, Jan 24, 2025 at 02:10:54PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 24, 2025 at 01:14:18PM +0200, Dmitry Baryshkov wrote:
> > > There are several drivers which attempt to upgrading the commit to the
> > > full mode set from
On Fri, Jan 24, 2025 at 02:10:54PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 24, 2025 at 01:14:18PM +0200, Dmitry Baryshkov wrote:
> > There are several drivers which attempt to upgrading the commit to the
> > full mode set from their per-object atomic_check() callbacks without
> > calling the drm_
On Fri, Jan 24, 2025 at 01:14:18PM +0200, Dmitry Baryshkov wrote:
> There are several drivers which attempt to upgrading the commit to the
> full mode set from their per-object atomic_check() callbacks without
> calling the drm_atomic_helper_check_modeset() or
> drm_atomic_helper_check() again (as
For the mgag200 driver if the format of the plane changes, then the PLL
rate needs to be changed. This requires performing a full CRTC modeset.
Current code sets drm_crtc_state.mode_changed from the plane's
atomic_check() callback and then doesn't call drm_atomic_helper_check()
again. It works for
For the msm/dpu driver if the CTM gets enabled or disabled, the CRTC
should perform resource reallocation (to get or to free the DSPP). This
requires performing a full CRTC modeset. Current code sets
drm_crtc_state.mode_changed from the msm_atomic_check(), from the
generic code path.
Move the che
Rework the CDM check into using the new atomic_needs_modeset()
callbacks. This removes a need for the dpu-specific check_mode_changed()
callback in the msm_kms_funcs structure.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35 +
dri
With the CTM and CDM checks now being handled by the component
callbacks there is no need for additional wrappers around
drm_atomic_helper_check() wrapper. Drop the msm_atomic_check() function
and use the helper directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_atomic.c | 14
There are several drivers which attempt to upgrading the commit to the
full mode set from their per-object atomic_check() callbacks without
calling the drm_atomic_helper_check_modeset() or
drm_atomic_helper_check() again (as requested by those functions).
As discussed on IRC, add separate atomic_n
As pointed out by the commit c5e3306a424b ("drm/atomic: clarify the
rules around drm_atomic_state->allow_modeset"), the drivers are now
allowed to set the drm_atomic_state.allow_modeset flag, as it might
break userspace API. Stop upgrading the commit to full modeset. Instead
set the drm_crtc_state.
Despite drm_atomic_helper_check_modeset() and drm_atomic_helper_check()
documenting that the function should be run again if atomic_check()
callback changes drm_crtc_state.mode_changed some drivers ignore it and
don't rerun the helpers. To simplify such drivers and remove the need to
rerun the help
24 matches
Mail list logo
