05:40 <narmstrong> f_: it was but maintenance was too high, now it’s a git repo anyone could change but submitting patches

06:32 <f_> oh ok

06:46 <f_> narmstrong: https://gitlab.baylibre.com/uploads/-/system/group/avatar/178/devicetree.jpg?width=256 :P

07:10 <narmstrong> Ah ah I’m proud of this one

07:12 <narmstrong> Used it in https://fr.slideshare.net/superna/elce-2016-neil-armstrong-no-its-never-too-late-to-upstream-your-legacy-linux-based-platform

07:13 <narmstrong> I used plenty of memes, it was fun, I should make a new version of it

11:47 <f_> lol

12:02 <minute> narmstrong: i chuckled

13:30 <jbrunet> narmstrong: I've got something in the pipe for that CBVS/audio ADC as well, for the ASoC side of things. Seems both DRM and ASoC will need to access it but remains independent of each other in case the connector has only one of the two signals. I suppose this will require some sort of MFD.

13:34 <narmstrong> jbrunet: not necessarely, it could be a common node acting as a drm bridge and an ASoC jack driver

13:35 <jbrunet> Would that require to pull DRM in for devices that have audio only ?

13:36 <narmstrong> jbrunet: the driver could still exists if drm is not build, simply don't create a drm bridge

13:38 <narmstrong> creating an HPD only bridge is very simple, simply set the DRM_BRIDGE_OP_EDID flag with hpd_enable & hpd_disable and add the node between the VPU and the CVBS connector using the OF graph and it should work

13:39 <narmstrong> sorry HPD

13:40 <narmstrong> DRM_BRIDGE_OP_HPD, or even simpler implement only .detect and pass DRM_BRIDGE_OP_DETECT for DRM to schedule the ADC reads

13:44 <jbrunet> I'm sure there are simple solutions to this. My point is that one (DRM or ASoC) should not add a dependency on the other, runtime or build.

13:44 <jbrunet> DRM scheduling the read is not OK in that respect.

13:47 <jbrunet> unless both framework can read from the ADC concurrently, but I'm not sure that is possible

13:48 <narmstrong> as you wish, they share a physical connector so there's a link somewhere

13:51 <narmstrong> if the adc can be read concurrently, perhaps updating the CVBS connector to use ADC and the meson ASoC card to use ADC as jack even would be much simpler

13:57 <jbrunet> For boards which do both signal on the 3.5mm jack this is true. Not all boards are like that. Some only have audio on it.

13:57 <jbrunet> Some are even audio only devices on which DRM is not necessary. This is why I'd like to avoid a hard compile dependency on either frameworks.

13:57 <jbrunet> If the ADC can be claimed more than once an read concurrently, 2 separate drivers works. no worries.

13:57 <jbrunet> If that is not possible, compiling out each part should be possible in case one is not needed. Both are significant frameworks to pull in if not needed

20:53 <xdarklight> jbrunet: if sharing the ADC input doesn't work then there's potentially drivers/extcon/extcon-adc-jack.c (it doesn't support device-tree yet but already takes care of polling and there's already EXTCON_DISP_CVBS and EXTCON_JACK_VIDEO_OUT connector types)