On 5/22/2024 3:51 AM, Dmitry Baryshkov wrote:
The HDMI driver already has msm_hdmi_hpd_enable() and
msm_hdmi_hpd_disable() functions. Wire them into the
msm_hdmi_bridge_funcs, so that HPD can be enabled and disabled
dynamically rather than always having HPD events generation enabled.
Signed-
On 5/22/2024 3:51 AM, Dmitry Baryshkov wrote:
The HDMI block needs to be enabled to properly generate HPD events. Make
sure it is not turned off in the disable paths if HPD delivery is enabled.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/hdmi/hdm
dpu_encoder_helper_phys_cleanup() calls the ctl ops without checking if
the ops are assigned causing discrepancy between its callers where the
checks are performed and the API itself which does not.
Two approaches can be taken: either drop the checks even in the caller
OR add the checks even in dp
On 6/13/2024 11:29 AM, Marijn Suijten wrote:
On 2024-06-13 20:05:11, Dmitry Baryshkov wrote:
Rename dpu_hw_setup_vsync_source functions to make the names match the
implementation: on DPU 5.x the TOP only contains timer setup, while 3.x
and 4.x used MDP_VSYNC_SEL register to select TE source.
On 6/13/2024 11:14 AM, Marijn Suijten wrote:
On 2024-06-13 20:05:10, Dmitry Baryshkov wrote:
Make the DPU driver use the TE source specified in the DT. If none is
specified, the driver defaults to the first GPIO (mdp_vsync0).
mdp_vsync_p?
Signed-off-by: Dmitry Baryshkov
---
drivers/gp
On 6/13/2024 10:05 AM, Dmitry Baryshkov wrote:
Make the DPU driver use the TE source specified in the DT. If none is
specified, the driver defaults to the first GPIO (mdp_vsync0).
as marijn noted,
mdp_vsync0 ---> mdp_vsyncp
Signed-off-by: Dmitry Baryshkov
With that addressed,
Reviewe
On 6/13/2024 10:05 AM, Dmitry Baryshkov wrote:
Command mode panels provide TE signal back to the DSI host to signal
that the frame display has completed and update of the image will not
cause tearing. Usually it is connected to the first GPIO with the
mdp_vsync function, which is the default.
On 5/22/2024 3:51 AM, Dmitry Baryshkov wrote:
Supporting simultaneous check of native HPD and the external GPIO proved
to be less stable than just native HPD. Drop the hpd-gpios support,
leaving just the native HPD support. In case the native HPD doesn't work
the user is urged to switch to spe
On 5/22/2024 3:51 AM, Dmitry Baryshkov wrote:
Expand the HDMI_CFG() macro in HDMI config description. It has no added
value other than hiding some boilerplate declarations.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 16
On 5/22/2024 3:51 AM, Dmitry Baryshkov wrote:
As these clocks are now used in the runtime PM callbacks, they have no
connection to 'HPD'. Rename corresponding fields to follow clocks
purpose, to power up the HDMI controller.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
On 5/22/2024 3:51 AM, Dmitry Baryshkov wrote:
It is completely not obvious, but the so-called 'hpd' clocks and
regulators are required for the HDMI host to function properly. Merge
pwr and hpd regulators. Use regulators, clocks and pinctrl to implement
proper runtime PM callbacks.
Signed-off-
On 6/18/2024 8:26 PM, Dmitry Baryshkov wrote:
On Wed, 19 Jun 2024 at 01:56, Abhinav Kumar wrote:
On 6/13/2024 4:20 PM, Abhinav Kumar wrote:
On 6/13/2024 3:36 PM, Dmitry Baryshkov wrote:
The dpu_crtc_atomic_check() already calls the function
_dpu_crtc_check_and_setup_lm_bounds(). There is
On 17/06/2024 19:14, Jeffrey Hugo wrote:
> On 6/15/2024 5:35 AM, Konrad Dybcio wrote:
>> On 14.06.2024 12:33 PM, Dmitry Baryshkov wrote:
>>> On Fri, Jun 14, 2024 at 01:55:46AM GMT, Konrad Dybcio wrote:
>>
>> [...]
>>
GCC_HDMI_CLKREF_CLK is a child of xo, so you can drop the latter.
>
13 matches
Mail list logo
