On Fri, Dec 20, 2024 at 03:00:47PM +0000, Dave Stevenson wrote: > On Fri, 20 Dec 2024 at 00:45, Dmitry Baryshkov > <dmitry.baryshkov@xxxxxxxxxx> wrote: > > > > On Thu, Dec 19, 2024 at 04:16:37PM +0000, Dave Stevenson wrote: > > > On Wed, 18 Dec 2024 at 14:52, Dave Stevenson > > > <dave.stevenson@xxxxxxxxxxxxxxx> wrote: > > > > > > > > Hi Maxime & Dmitry > > > > > > > > On Wed, 18 Dec 2024 at 07:59, Maxime Ripard <mripard@xxxxxxxxxx> wrote: > > > > > > > > > > On Wed, Dec 18, 2024 at 07:24:23AM +0200, Dmitry Baryshkov wrote: > > > > > > On Tue, 17 Dec 2024 at 19:21, Maxime Ripard <mripard@xxxxxxxxxx> wrote: > > > > > > > On Tue, Dec 17, 2024 at 02:40:22AM +0200, Dmitry Baryshkov wrote: > > > > > > > > While porting lt9611 DSI-to-HDMI bridge driver to use HDMI Connector > > > > > > > > framework, I stumbled upon an issue while handling the Audio InfoFrames. > > > > > > > > The HDMI codec callbacks weren't receiving the drm_atomic_state, so > > > > > > > > there was no simple way to get the drm_connector that stayed at the end > > > > > > > > of the bridge chain. At the same point the drm_hdmi_connector functions > > > > > > > > expected to get drm_connector instance. > > > > > > > > > > > > > > > > While looking for a way to solve the issue, I stumbled upon several > > > > > > > > deficiencies in existing hdmi_codec_ops implementations. Only few of the > > > > > > > > implementations were able to handle codec's 'plugged' callback. One > > > > > > > > third of the drivers didn't implement the get_eld() callback. > > > > > > > > > > > > > > > > Most of the issues can be solved if drm_connector handles > > > > > > > > hdmi-audio-codec on its own, delegating functionality to the actual > > > > > > > > implementation, be it a driver that implements drm_connector or > > > > > > > > drm_bridge. > > > > > > > > > > > > > > > > Implement such high-level framework, adding proper support for Audio > > > > > > > > InfoFrame generation to the LT9611 driver. > > > > > > > > > > > > > > > > Several design decisions to be kept in mind: > > > > > > > > > > > > > > > > - drm_connector_hdmi_codec is kept as simple as possible. It implements > > > > > > > > generic functionality (ELD, hotplug, registration). > > > > > > > > > > > > > > > > - drm_hdmi_connector sets up HDMI codec device if the connector > > > > > > > > is setup correspondingly (either I2S or S/PDIF is marked as > > > > > > > > supported). > > > > > > > > > > > > > > > > - drm_bridge_connector provides a way to link HDMI audio codec > > > > > > > > funcionality in the drm_bridge with the drm_connector_hdmi_codec > > > > > > > > framework. > > > > > > > > > > > > > > > > - It might be worth reverting the no_i2s_capture / no_spdif_capture > > > > > > > > bits. Only TDA889x driver sets them, while it's safe to assume that > > > > > > > > most of HDMI / DP devices do not support ARC / capture. I think the > > > > > > > > drivers should opt-in capture support rather than having to opt-out of > > > > > > > > it. > > > > > > > > > > > > > > Sorry if this isn't clear to me and I'm quite late to the party, but did > > > > > > > you test this on vc4 with both a pi3 and pi4, or was it just compile > > > > > > > tested? > > > > > > > > > > > > LT9611 is actually tested, VC4 is only compile-tested. Should I put an RFT tag? > > > > > > > > > > Yeah, we definitely need to test it on the pi3 (polling-based) and the > > > > > pi4 (irq-based) at least. > > > > > > > > > > Dave, Maira, could you give it a try? > > > > > > > > I'm on it. > > > > > > Basic checks look OK. > > > Pi3 and Pi4 tested, including 4k60 on Pi4 (enables scrambling). Audio > > > works, and all the EDID parsing seems to be correct. > > > > > > Ideally I would like to do a couple more tests though as I had a > > > couple of spontaneous reboots on Pi4 whilst hotplugging. > > > Most likely it was just grounding issues, as I can't think of an > > > obvious way for the kernel to be triggering an automatic reboot. They > > > seemed to go away when I had enabled drm.debug=0x14, but more likely > > > I'd connected the serial port and therefore provided another ground. > > > Please don't hold the patches waiting on me though - I don't know when > > > I'll have time to do them. > > > > Tested-by? > > I'd held off hoping to get the extra testing done today, but that > hasn't happened, and today is my last day before the Christmas break. > So based on what I've done so far: > > Tested-by: Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx> Thank you! > > > > > > > > > > Also unrelated to this patch set, I have noted I'm getting > > > [ 60.780897] WARNING: CPU: 3 PID: 501 at > > > drivers/gpu/drm/vc4/vc4_hvs.c:743 __vc4_hvs_stop_channel+0x148/0x164 > > > [vc4] > > > ... > > > [ 60.781192] __vc4_hvs_stop_channel+0x148/0x164 [vc4] (P) > > > [ 60.781212] __vc4_hvs_stop_channel+0x40/0x164 [vc4] (L) > > > [ 60.781230] vc4_hvs_stop_channel+0x30/0x3c [vc4] > > > [ 60.781248] vc4_crtc_disable+0x140/0x1e8 [vc4] > > > [ 60.781266] vc4_crtc_atomic_disable+0x98/0xb8 [vc4] > > > [ 60.781284] disable_outputs+0x22c/0x33c [drm_kms_helper] > > > [ 60.781326] drm_atomic_helper_commit_modeset_disables+0x1c/0x4c > > > [drm_kms_helper] > > > [ 60.781347] vc4_atomic_commit_tail+0x10c/0x8e4 [vc4] > > > [ 60.781364] commit_tail+0xa0/0x188 [drm_kms_helper] > > > [ 60.781385] drm_atomic_helper_commit+0x16c/0x180 [drm_kms_helper] > > > [ 60.781406] drm_atomic_commit+0x88/0xc4 [drm] > > > [ 60.781500] drm_client_modeset_commit_atomic+0x204/0x264 [drm] > > > [ 60.781553] drm_client_modeset_commit_locked+0x5c/0x198 [drm] > > > [ 60.781603] drm_client_modeset_commit+0x30/0x58 [drm] > > > [ 60.781652] __drm_fb_helper_restore_fbdev_mode_unlocked+0xb4/0xe8 > > > [drm_kms_helper] > > > [ 60.781674] drm_fb_helper_hotplug_event+0x108/0x12c [drm_kms_helper] > > > [ 60.781695] drm_fbdev_client_hotplug+0x28/0xd4 [drm_client_lib] > > > [ 60.781700] drm_client_dev_hotplug+0xc8/0x12c [drm] > > > [ 60.781750] drm_connector_helper_hpd_irq_event+0x70/0xb0 [drm_kms_helper] > > > [ 60.781771] vc4_hdmi_hpd_irq_thread+0x2c/0x3c [vc4] > > > [ 60.781790] irq_thread_fn+0x2c/0xa8 > > > [ 60.781799] irq_thread+0x16c/0x2f4 > > > [ 60.781805] kthread+0x118/0x11c > > > [ 60.781813] ret_from_fork+0x10/0x20 > > > On first plugging or unplugging a second monitor. I suspect that is > > > spurious though and I'll look into it, but probably not this side of > > > the Christmas break. > > > > > > Dave > > > > -- > > With best wishes > > Dmitry -- With best wishes Dmitry
