Hi,
we (Paul Boddie and me) are working to get HDMI functional on the
Ingenic CI20 board with jz4780 SoC which uses a specialization of
the dw-hdmi driver.
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.
Therefore the interrupt is ignored and nothing happens.
Now I wonder about the logic behind checking for poll_enabled.
I understand that a driver can do either polling or irq or both.
Therefore handling the irq_event shouldn't be disabled by poll_enabled
being false. Otherwise we can only do: nothing, polling, polling+irq
but not irq alone.
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.
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.
If these questions should be forwarded to other specialists, please
do so.
BR and thanks,
Nikolaus Schaller
Hi Nikolaus,
Le sam. 11 avril 2020 ? 16:14, H. Nikolaus Schaller
<[email protected]> a ?crit :
> Hi,
> we (Paul Boddie and me) are working to get HDMI functional on the
> Ingenic CI20 board with jz4780 SoC which uses a specialization of
> the dw-hdmi driver.
>
>
> 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.
>
> Therefore the interrupt is ignored and nothing happens.
>
> Now I wonder about the logic behind checking for poll_enabled.
> I understand that a driver can do either polling or irq or both.
>
> Therefore handling the irq_event shouldn't be disabled by poll_enabled
> being false. Otherwise we can only do: nothing, polling, polling+irq
> but not irq alone.
>
> 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.
>
>
> 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.
>
> If these questions should be forwarded to other specialists, please
> do so.
It should be sent to the DRI mailing list, you missed the most
important one.
-Paul
>
> BR and thanks,
> Nikolaus Schaller
> Am 13.04.2020 um 13:25 schrieb Paul Cercueil <[email protected]>:
>
> Hi Nikolaus,
>
>
> Le sam. 11 avril 2020 ? 16:14, H. Nikolaus Schaller <[email protected]> a ?crit :
>> Hi,
>> we (Paul Boddie and me) are working to get HDMI functional on the
>> Ingenic CI20 board with jz4780 SoC which uses a specialization of
>> the dw-hdmi driver.
>> 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.
>> Therefore the interrupt is ignored and nothing happens.
>> Now I wonder about the logic behind checking for poll_enabled.
>> I understand that a driver can do either polling or irq or both.
>> Therefore handling the irq_event shouldn't be disabled by poll_enabled
>> being false. Otherwise we can only do: nothing, polling, polling+irq
>> but not irq alone.
>> 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.
>> 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.
>> If these questions should be forwarded to other specialists, please
>> do so.
>
> It should be sent to the DRI mailing list, you missed the most important one.
Ah, ok.
>
> -Paul
>
>> BR and thanks,
>> Nikolaus Schaller
Hi Nikolaus,
So I just wrote a HDMI driver for a different chip, I guess I can
answer some of your questions now.
Le lun. 13 avril 2020 ? 13:25, Paul Cercueil <[email protected]> a
?crit :
> Hi Nikolaus,
>
>
> Le sam. 11 avril 2020 ? 16:14, H. Nikolaus Schaller
> <[email protected]> a ?crit :
>> Hi,
>> we (Paul Boddie and me) are working to get HDMI functional on the
>> Ingenic CI20 board with jz4780 SoC which uses a specialization of
>> the dw-hdmi driver.
>>
>>
>> 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.
>> Therefore the interrupt is ignored and nothing happens.
>>
>> Now I wonder about the logic behind checking for poll_enabled.
>> I understand that a driver can do either polling or irq or both.
>>
>> Therefore handling the irq_event shouldn't be disabled by
>> poll_enabled
>> being false. Otherwise we can only do: nothing, polling, polling+irq
>> but not irq alone.
>>
>> 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.
>> 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?
-Paul
>> If these questions should be forwarded to other specialists, please
>> do so.
>
> It should be sent to the DRI mailing list, you missed the most
> important one.
>
> -Paul
>
>>
>> BR and thanks,
>> Nikolaus Schaller
On Monday 4. May 2020 03.05.22 Paul Cercueil wrote:
>
> > Le sam. 11 avril 2020 ? 16:14, H. Nikolaus Schaller <[email protected]> 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.
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.
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.
Hi Paul,
Le mar. 5 mai 2020 ? 20:26, Paul Boddie <[email protected]> a ?crit :
> On Monday 4. May 2020 03.05.22 Paul Cercueil wrote:
>>
>> > Le sam. 11 avril 2020 ? 16:14, H. Nikolaus Schaller
>> <[email protected]> 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