Re: [PATCH RFC v2 00/37] drm/connector: Create HDMI Connector infrastructure

[Maxime Ripard]

Hi Hans,

On Thu, Sep 21, 2023 at 06:29:29PM +0200, Hans Verkuil wrote:
> On 20/09/2023 16:35, Maxime Ripard wrote:
> > Hi,
> > 
> > Here's a series that creates a subclass of drm_connector specifically
> > targeted at HDMI controllers.
> > 
> > The idea behind this series came from a recent discussion on IRC during
> > which we discussed infoframes generation of i915 vs everything else. 
> > 
> > Infoframes generation code still requires some decent boilerplate, with
> > each driver doing some variation of it.
> > 
> > In parallel, while working on vc4, we ended up converting a lot of i915
> > logic (mostly around format / bpc selection, and scrambler setup) to
> > apply on top of a driver that relies only on helpers.
> > 
> > While currently sitting in the vc4 driver, none of that logic actually
> > relies on any driver or hardware-specific behaviour.
> > 
> > The only missing piece to make it shareable are a bunch of extra
> > variables stored in a state (current bpc, format, RGB range selection,
> > etc.).
> > 
> > The initial implementation was relying on some generic subclass of
> > drm_connector to address HDMI connectors, with a bunch of helpers that
> > will take care of all the "HDMI Spec" related code. Scrambler setup is
> > missing at the moment but can easily be plugged in.
> > 
> > The feedback was that creating a connector subclass like was done for
> > writeback would prevent the adoption of those helpers since it couldn't
> > be used in all situations (like when the connector driver can implement
> > multiple output) and required more churn to cast between the
> > drm_connector and its subclass. The decision was thus to provide a set
> > of helper and to store the required variables in drm_connector and
> > drm_connector_state. This what has been implemented now.
> > 
> > Hans Verkuil also expressed interest in implementing a mechanism in v4l2
> > to retrieve infoframes from HDMI receiver and implementing an
> > infoframe-decode tool.
> 
> I'd love to get started on that, but...
> 
> > 
> > This series thus leverages the infoframe generation code to expose it
> > through debugfs.
> > 
> > This entire series is only build-tested at the moment. Let me know what
> > you think,
> 
> ...trying this series on my RPi4 gives me this during boot:
> 
> [    2.361239] vc4-drm gpu: bound fe400000.hvs (ops 0xffff800080cac6f8)
> [    2.367834] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000090
> [    2.376748] Mem abort info:
> [    2.379570]   ESR = 0x0000000096000044
> [    2.383367]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    2.388748]   SET = 0, FnV = 0
> [    2.391835]   EA = 0, S1PTW = 0
> [    2.395011]   FSC = 0x04: level 0 translation fault
> [    2.399951] Data abort info:
> [    2.402864]   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
> [    2.408420]   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
> [    2.413536]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [    2.418916] [0000000000000090] user address but active_mm is swapper
> [    2.425353] Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP
> [    2.431700] Modules linked in:
> [    2.434791] CPU: 2 PID: 55 Comm: kworker/u8:3 Not tainted 6.6.0-rc1-hdmi-dbg #245
> [    2.442372] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
> [    2.448278] Workqueue: events_unbound deferred_probe_work_func
> [    2.454193] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [    2.461245] pc : drm_connector_attach_max_bpc_property+0x48/0x90
> [    2.467332] lr : drm_connector_attach_max_bpc_property+0x3c/0x90
> [    2.473415] sp : ffff800081d038b0
> [    2.476766] x29: ffff800081d038b0 x28: 0000000000000000 x27: ffff0001041968c0
> [    2.483999] x26: 0000000000000000 x25: ffff00010339d558 x24: ffff000103399000
> [    2.491231] x23: ffff800080caa3e8 x22: ffff800080e96a20 x21: 000000000000000c
> [    2.498463] x20: 000000000000000c x19: ffff00010339d558 x18: ffffffffffffffff
> [    2.505694] x17: ffff0001008e7650 x16: ffff800080d55500 x15: ffffffffffffffff
> [    2.512926] x14: ffff000105dda209 x13: 0000000000000006 x12: 0000000000000001
> [    2.520158] x11: 0101010101010101 x10: ffff00027effe219 x9 : 0000000000000001
> [    2.527389] x8 : ffff000105db8ad4 x7 : 00000000c0c0c0c0 x6 : 00000000c0c0c0c0
> [    2.534620] x5 : 0000000000000000 x4 : ffff00010339d728 x3 : ffff00010339d728
> [    2.541852] x2 : 000000000000000c x1 : 0000000000000000 x0 : 0000000000000000
> [    2.549083] Call trace:
> [    2.551554]  drm_connector_attach_max_bpc_property+0x48/0x90
> [    2.557285]  drmm_connector_hdmi_init+0x114/0x14c
> [    2.562048]  vc4_hdmi_bind+0x320/0xa40
> [    2.565842]  component_bind_all+0x114/0x23c
> [    2.570077]  vc4_drm_bind+0x148/0x2c0
> [    2.573784]  try_to_bring_up_aggregate_device+0x168/0x1d4
> [    2.579253]  __component_add+0xa4/0x16c
> [    2.583136]  component_add+0x14/0x20
> [    2.586754]  vc4_hdmi_dev_probe+0x1c/0x28
> [    2.590815]  platform_probe+0x68/0xc4
> [    2.594522]  really_probe+0x148/0x2b0
> [    2.598228]  __driver_probe_device+0x78/0x12c
> [    2.602638]  driver_probe_device+0xd8/0x15c
> [    2.606873]  __device_attach_driver+0xb8/0x134
> [    2.611372]  bus_for_each_drv+0x80/0xdc
> [    2.615254]  __device_attach+0x9c/0x188
> [    2.619136]  device_initial_probe+0x14/0x20
> [    2.623371]  bus_probe_device+0xac/0xb0
> [    2.627253]  deferred_probe_work_func+0x88/0xc0
> [    2.631839]  process_one_work+0x138/0x244
> [    2.635899]  worker_thread+0x320/0x438
> [    2.639692]  kthread+0x10c/0x110
> [    2.642957]  ret_from_fork+0x10/0x20
> [    2.646576] Code: 94005f8d 12001e94 f9427e61 52800000 (39024034)
> [    2.652745] ---[ end trace 0000000000000000 ]---

Well, I guess I'll have to start testing what I'm doing then :)

Maxime

Attachment: signature.asc
Description: PGP signature