* DRM interaction problems on Ingenic CI20 / jz4780 with dw-hdmi and ingenic-drm @ 2020-04-11 14:14 H. Nikolaus Schaller 2020-04-13 11:25 ` Paul Cercueil 0 siblings, 1 reply; 7+ messages in thread From: H. Nikolaus Schaller @ 2020-04-11 14:14 UTC (permalink / raw) To: Paul Cercueil, Dave Airlie, Sascha Hauer, Andy Yan, Yakir Yang, Vladimir Zapolskiy Cc: Paul Boddie, linux-mips, Linux Kernel Mailing List, MIPS Creator CI20 Development 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DRM interaction problems on Ingenic CI20 / jz4780 with dw-hdmi and ingenic-drm 2020-04-11 14:14 DRM interaction problems on Ingenic CI20 / jz4780 with dw-hdmi and ingenic-drm H. Nikolaus Schaller @ 2020-04-13 11:25 ` Paul Cercueil 2020-04-13 11:46 ` H. Nikolaus Schaller 2020-05-04 1:05 ` Paul Cercueil 0 siblings, 2 replies; 7+ messages in thread From: Paul Cercueil @ 2020-04-13 11:25 UTC (permalink / raw) To: H. Nikolaus Schaller Cc: Dave Airlie, Sascha Hauer, Andy Yan, Yakir Yang, Vladimir Zapolskiy, Paul Boddie, linux-mips, Linux Kernel Mailing List, MIPS Creator CI20 Development Hi Nikolaus, Le sam. 11 avril 2020 à 16:14, H. Nikolaus Schaller <hns@goldelico.com> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DRM interaction problems on Ingenic CI20 / jz4780 with dw-hdmi and ingenic-drm 2020-04-13 11:25 ` Paul Cercueil @ 2020-04-13 11:46 ` H. Nikolaus Schaller 2020-05-04 1:05 ` Paul Cercueil 1 sibling, 0 replies; 7+ messages in thread From: H. Nikolaus Schaller @ 2020-04-13 11:46 UTC (permalink / raw) To: Paul Cercueil, open list:DRM PANEL DRIVERS Cc: Dave Airlie, Sascha Hauer, Andy Yan, Yakir Yang, Vladimir Zapolskiy, Paul Boddie, linux-mips, Linux Kernel Mailing List, MIPS Creator CI20 Development > Am 13.04.2020 um 13:25 schrieb Paul Cercueil <paul@crapouillou.net>: > > Hi Nikolaus, > > > Le sam. 11 avril 2020 à 16:14, H. Nikolaus Schaller <hns@goldelico.com> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DRM interaction problems on Ingenic CI20 / jz4780 with dw-hdmi and ingenic-drm @ 2020-04-13 11:46 ` H. Nikolaus Schaller 0 siblings, 0 replies; 7+ messages in thread From: H. Nikolaus Schaller @ 2020-04-13 11:46 UTC (permalink / raw) To: Paul Cercueil, open list:DRM PANEL DRIVERS Cc: Paul Boddie, Dave Airlie, Sascha Hauer, linux-mips, Linux Kernel Mailing List, MIPS Creator CI20 Development, Yakir Yang, Andy Yan, Vladimir Zapolskiy > Am 13.04.2020 um 13:25 schrieb Paul Cercueil <paul@crapouillou.net>: > > Hi Nikolaus, > > > Le sam. 11 avril 2020 à 16:14, H. Nikolaus Schaller <hns@goldelico.com> 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DRM interaction problems on Ingenic CI20 / jz4780 with dw-hdmi and ingenic-drm 2020-04-13 11:25 ` Paul Cercueil 2020-04-13 11:46 ` H. Nikolaus Schaller @ 2020-05-04 1:05 ` Paul Cercueil 2020-05-05 18:26 ` Paul Boddie 1 sibling, 1 reply; 7+ messages in thread From: Paul Cercueil @ 2020-05-04 1:05 UTC (permalink / raw) To: H. Nikolaus Schaller Cc: Dave Airlie, Sascha Hauer, Andy Yan, Yakir Yang, Vladimir Zapolskiy, Paul Boddie, linux-mips, Linux Kernel Mailing List, MIPS Creator CI20 Development 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 <paul@crapouillou.net> a écrit : > Hi Nikolaus, > > > Le sam. 11 avril 2020 à 16:14, H. Nikolaus Schaller > <hns@goldelico.com> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DRM interaction problems on Ingenic CI20 / jz4780 with dw-hdmi and ingenic-drm 2020-05-04 1:05 ` Paul Cercueil @ 2020-05-05 18:26 ` Paul Boddie 2020-05-09 13:43 ` Paul Cercueil 0 siblings, 1 reply; 7+ messages in thread From: Paul Boddie @ 2020-05-05 18:26 UTC (permalink / raw) To: Paul Cercueil Cc: H. Nikolaus Schaller, Dave Airlie, Sascha Hauer, Andy Yan, Yakir Yang, Vladimir Zapolskiy, linux-mips, Linux Kernel Mailing List, MIPS Creator CI20 Development 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. 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: DRM interaction problems on Ingenic CI20 / jz4780 with dw-hdmi and ingenic-drm 2020-05-05 18:26 ` Paul Boddie @ 2020-05-09 13:43 ` Paul Cercueil 0 siblings, 0 replies; 7+ messages in thread From: Paul Cercueil @ 2020-05-09 13:43 UTC (permalink / raw) To: Paul Boddie Cc: H. Nikolaus Schaller, Dave Airlie, Sascha Hauer, Andy Yan, Yakir Yang, Vladimir Zapolskiy, linux-mips, Linux Kernel Mailing List, MIPS Creator CI20 Development 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-05-09 13:43 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-11 14:14 DRM interaction problems on Ingenic CI20 / jz4780 with dw-hdmi and ingenic-drm H. Nikolaus Schaller 2020-04-13 11:25 ` Paul Cercueil 2020-04-13 11:46 ` H. Nikolaus Schaller 2020-04-13 11:46 ` H. Nikolaus Schaller 2020-05-04 1:05 ` Paul Cercueil 2020-05-05 18:26 ` Paul Boddie 2020-05-09 13:43 ` Paul Cercueil
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.