lkml.org 
[lkml]   [2020]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DRM interaction problems on Ingenic CI20 / jz4780 with dw-hdmi and ingenic-drm
Hi Paul,

Le mar. 5 mai 2020 à 20:26, Paul Boddie <paul@boddie.org.uk> a écrit :
> On Monday 4. May 2020 03.05.22 Paul Cercueil wrote:
>>
>> > Le sam. 11 avril 2020 à 16:14, H. Nikolaus Schaller
>> <hns@goldelico.com> a
>> > écrit :
>> >>
>> >> So far we have identified two issues.
>> >>
>> >> The first is that HPD interrupts are not properly processed.
>> >>
>> >> drm_helper_hpd_irq_event() is called by HPD events but
>> >> dev->mode_config.poll_enabled is false.
>>
>> This is to be used when there's no hardware interrupt. I believe you
>> have one, right? Then call drm_kms_helper_hotplug_event() from the
>> interrupt handler instead.
>
> What we have in drivers/gpu/drm/bridge/synopsys/dw-hdmi.c is a
> function called
> dw_hdmi_irq which appears to be the thread_fn for HDMI interrupts
> (alongside
> the dw_hdmi_hardirq which is the handler), initialised by a call to
> devm_request_threaded_irq.
>
> In dw_hdmi_irq, a hotplug event seems to cause
> drm_helper_hpd_irq_event to be
> called. However...
>
> [...]
>
>> >> The jz4780 hdmi subsystem (drm/bridge/dw-hdmi.c) uses
>> >>
>> >> connector->polled = DRM_CONNECTOR_POLL_HPD;
>> >>
>> >> but shouldn't this enable polling? Note that there seems to be
>> >> no (direct) call to drm_kms_helper_poll_init().
>> >>
>> >> If we set dev->mode_config.poll_enabled = true in
>> >> drm_helper_hpd_irq_event() things start to work.
>> >>
>> >> Please can you clarify what would be best practise here to
>> >> get HPD event handling working.
>>
>> Remove that - this stuff is for hardware without interrupts, where
>> everything has to be polled.
>
> Yes, I think this must be a mistake in the driver. In
> drm_helper_hpd_irq_event, the connector is tested for the
> DRM_CONNECTOR_POLL_HPD flag and skips the connector. It isn't clear
> whether
> this actually matters for the other hardware using this technology,
> documentation being rather thin on the ground.
>
>> >> The other issue is in dw-hdmi.c:
>> >>
>> >> We found out that ingenic_drm_encoder_atomic_check() fails
>> because
>> >>
>> >> info->num_bus_formats == 0
>> >>
>> >> and not 1. This blocks further initialization.
>> >>
>> >> The reason seems to be that dw_hdmi_bridge_attach() does not call
>> >> drm_display_info_set_bus_formats() with a proper format like
>> >> other drivers (e.g. drm/bridge/ti-tfp410.c) are doing.
>> >>
>> >> We have patched to set a single bus format
>> MEDIA_BUS_FMT_RGB888_1X24
>> >> and then DRM setup seems to work (although we still have no valid
>> >> HDMI signal but that is likely something else).
>> >>
>> >> Please can you explain how setting the bus format should be fixed
>> >> in dw-hdmi.c.
>>
>> I'm not sure, but that information may come from EDID data. Are you
>> able to obtain video modes from the connected monitor?
>
> The modes are definitely received, or at least the list of modes
> given by
> /sys/devices/platform/13050000.lcd/drm/card0/card0-HDMI-A-1/modes is
> viable.
>
> However, it rather looked like the bus format information wasn't
> being set and
> that this inhibited the completion of the initialisation process
> which, if
> completed, would ultimately cause the format to be set. (This being
> the short
> version of the story as I remember it right now.) So, the problem
> presents
> itself as an initialisation order problem.

It's not an initialization order problem, the ingenic-drm expects the
bus_formats to be provided and the synopsis driver never calls
drm_display_info_set_bus_formats().

> I removed the flag from the connector to see if it makes any
> difference, but
> it doesn't look like it. Here is what /sys/kernel/debug/dri/0/state
> contains:
>
> plane[31]: plane-0
> crtc=(null)
> fb=0
> crtc-pos=0x0+0+0
> src-pos=0.000000x0.000000+0.000000+0.000000
> rotation=1
> normalized-zpos=0
> color-encoding=ITU-R BT.601 YCbCr
> color-range=YCbCr limited range
> crtc[32]: crtc-0
> enable=0
> active=0
> self_refresh_active=0
> planes_changed=0
> mode_changed=0
> active_changed=0
> connectors_changed=0
> color_mgmt_changed=0
> plane_mask=0
> connector_mask=0
> encoder_mask=0
> mode: "": 0 0 0 0 0 0 0 0 0 0 0x0 0x0
> connector[34]: HDMI-A-1
> crtc=(null)
> self_refresh_aware=0
>
> The crtc member values do not look encouraging. In fact, it just
> looks like
> most structure members are uninitialised.
>
> Thanks for the advice: I spent some time the other day reviewing
> various
> aspects of the Synopsys drivers of different vintages (Ingenic 3.0.8
> non-DRM
> driver for JZ4780, MIPS/Ingenic 3.18 DRM driver for JZ4780 based on
> Freescale
> driver code, the recent generic DRM bridge driver), and so this
> information is
> timely and valuable.

With a hardcoded bus_format of RGB888 in the ingenic-drm driver, and
jz4780_dw_hdmi_plat_data.input_bus_format initialized too:

modetest -D /dev/dri/card0 -M ingenic-drm -s 35@32:1280x720-60

My PC monitor sees a signal - unfortunately it says "input not
supported".


> Paul
>
> P.S. Sorry if this message goes to far too many people. I don't want
> to
> "personalise" it by taking people off the recipients list, but I
> realise that
> this is probably not interesting to most recipients, either. Feel
> free to trim
> recipients if replying.

Again, you shoul send this message to the DRI mailing list. The people
who did work with the Synopsis IP may be able to help.

-Paul


\
 
 \ /
  Last update: 2020-05-09 15:44    [W:0.252 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site