On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> According to the documentation, drm_add_edid_modes
> "... Also fills out the &drm_display_info structure and ELD in @connector
> with any information which can be derived from the edid."
>
> drm_add_edid_modes accepts a struct edid
On Fri, Oct 15, 2021 at 01:37:13PM +0200, Claudio Suarez wrote:
> Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. Retriving the same information with
> drm_detect_hdmi_monitor() is less efficient. Change to
> drm_display_info.is_hdmi where
On Fri, 15 Oct 2021, Claudio Suarez wrote:
> Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. Retriving the same information with
> drm_detect_hdmi_monitor() is less efficient. Change to
> drm_display_info.is_hdmi where possible.
>
> This i
On Fri, Oct 15, 2021 at 03:44:48PM +0300, Jani Nikula wrote:
> On Fri, 15 Oct 2021, Claudio Suarez wrote:
> > Once EDID is parsed, the monitor HDMI support information is available
> > through drm_display_info.is_hdmi. Retriving the same information with
> > drm_detect_hdmi_monitor() is less effic
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/msm/hdmi/hdmi_connector.c
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi where possible.
This is a TODO task in Documentation/gpu/todo.rst
Signed-off
According to the documentation, drm_add_edid_modes
"... Also fills out the &drm_display_info structure and ELD in @connector
with any information which can be derived from the edid."
drm_add_edid_modes accepts a struct edid *edid parameter which may have a
value or may be null. When it is not null
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/zte/zx_hdmi.c | 4 ++--
1
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/sti/sti_hdmi.c | 10 +
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/rockchip/inno_hdmi.c |
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c |
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 6
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Use this value instead of calling
drm_detect_hdmi_monitor() to avoid a second parse.
This is a TODO task in Documentation/gpu/todo.rst
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/vc4/v
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/tegra/hdmi.c | 6 +-
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi where possible
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/bridge/adv
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/nouveau/dispnv50/disp.c
Copy&paste from the TODO document Documentation/gpu/todo.rst
===
Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
---
Once EDID is parsed, the monitor HDMI support information is available through
drm_display_info.is_hdmi
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/gma500/cdv_intel_hdmi.c |
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information is less
efficient. Change to drm_display_info.is_hdmi
This is a TODO task in Documentation/gpu/todo.rst
Also, correct an inacurracy or bug in
radeon_connector_ge
a) Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. The amdgpu driver still calls
drm_detect_hdmi_monitor() to retrieve the same information, which
is less efficient. Change to drm_display_info.is_hdmi
This is a TODO task in Documentation/gpu
On Fri, 15 Oct 2021, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 03:44:48PM +0300, Jani Nikula wrote:
>> On Fri, 15 Oct 2021, Claudio Suarez wrote:
>> > Once EDID is parsed, the monitor HDMI support information is available
>> > through drm_display_info.is_hdmi. Retriving the same information
On Mon, 20 Sep 2021 11:05:12 +0200, Wolfram Sang wrote:
> I got tired of fixing this in Renesas drivers manually, so I took the big
> hammer. Remove this cumbersome code pattern which got copy-pasted too much
> already:
>
> - struct platform_device *pdev = to_platform_device(dev);
> - stru
On Fri, Oct 15, 2021 at 03:30:49PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 01:37:13PM +0200, Claudio Suarez wrote:
> > Once EDID is parsed, the monitor HDMI support information is available
> > through drm_display_info.is_hdmi. Retriving the same information with
> > drm_detect_hdmi_m
On Fri, Oct 15, 2021 at 06:18:34PM +0300, Jani Nikula wrote:
> On Fri, 15 Oct 2021, Ville Syrjälä wrote:
> > On Fri, Oct 15, 2021 at 03:44:48PM +0300, Jani Nikula wrote:
> >> On Fri, 15 Oct 2021, Claudio Suarez wrote:
> >> > Once EDID is parsed, the monitor HDMI support information is available
>
On 2021-10-15 07:37, Claudio Suarez wrote:
> a) Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. The amdgpu driver still calls
> drm_detect_hdmi_monitor() to retrieve the same information, which
> is less efficient. Change to drm_display_
On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > According to the documentation, drm_add_edid_modes
> > "... Also fills out the &drm_display_info structure and ELD in @connector
> > with any information which can be
On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > > According to the documentation, drm_add_edid_modes
> > > "... Also fills out the &drm_display_in
Quoting Dmitry Baryshkov (2021-10-14 17:10:59)
> Switch to using bulk regulator API instead of hand coding loops.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > > > According to the document
Hi Dmitry
No concerns from our side to drop this.
Reviewed-by: Abhinav Kumar for the series.
Thanks
Abhinav
On 2021-10-01 09:50, Dmitry Baryshkov wrote:
MSM DRM driver has support for eDP block present on MSM 8x74/8x84 SoC
families. However since addition back in 2015 this driver received o
Quoting Dmitry Baryshkov (2021-10-14 14:42:21)
> Stop using legacy clock names (with _clk suffix) for HDMI and HDMI PHY
> device tree nodes.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
On 2021-10-14 17:10, Dmitry Baryshkov wrote:
Switch to using bulk regulator API instead of hand coding loops.
Nice cleanup!
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 34 +++
drivers/gpu/drm/msm/hdmi/hdm
Hi Dmitry
On 2021-10-14 17:11, Dmitry Baryshkov wrote:
Merge old hdmi_bridge and hdmi_connector implementations. Use
drm_bridge_connector instead.
Can you please comment on the validation done on this change?
Has basic bootup been verified on db820c as thats the only platform
which shall use
dpu_kms_debugfs_init() and hence dp_debug_get() gets invoked for each
minor being registered. But dp_debug_get() will allocate a new struct
dp_debug for each call and this will be associated as dp->debug.
As such dp_debug will create debugfs files in both the PRIMARY and the
RENDER minor's debugfs
In the cleanup path of the MSM DP driver the DP driver's debugfs files
are destroyed by invoking debugfs_remove_recursive() on debug->root,
which during initialization has been set to minor->debugfs_root.
To allow cleaning up the DP driver's debugfs files either each dentry
needs to be kept track
The debugfs code is provided an array of a single drm_connector. Then to
access the connector, the list of all connectors of the DRM device is
traversed and all non-DisplayPort connectors are skipped, to find the
one and only DisplayPort connector.
But as we move to support multiple DisplayPort co
On 2021-10-15 16:13, Bjorn Andersson wrote:
dpu_kms_debugfs_init() and hence dp_debug_get() gets invoked for each
minor being registered. But dp_debug_get() will allocate a new struct
dp_debug for each call and this will be associated as dp->debug.
As such dp_debug will create debugfs files in b
On 2021-10-15 16:17, Bjorn Andersson wrote:
In the cleanup path of the MSM DP driver the DP driver's debugfs files
are destroyed by invoking debugfs_remove_recursive() on debug->root,
which during initialization has been set to minor->debugfs_root.
To allow cleaning up the DP driver's debugfs fi
On Fri 15 Oct 18:44 CDT 2021, abhin...@codeaurora.org wrote:
> On 2021-10-15 16:13, Bjorn Andersson wrote:
> > dpu_kms_debugfs_init() and hence dp_debug_get() gets invoked for each
> > minor being registered. But dp_debug_get() will allocate a new struct
> > dp_debug for each call and this will be
39 matches
Mail list logo
