On Mon, Dec 26, 2022 at 12:06:53PM +0200, Laurent Pinchart wrote: > On Fri, Dec 23, 2022 at 03:48:11PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Dec 23, 2022 at 12:24:22PM +0100, Stefan Wahren wrote: > > > i vaguely remember the discussion how to represent audio and camera > > > interface in the device tree. Representing as child nodes of the VC4 has > > > been rejected on the device tree mailing some years ago, because this > > > doesn't represent the physical (hardware) wiring. It's still possible to > > > access e.g. the camera interface from the ARM. > > > > > > The whole approach with using a separate binding for all the firmware stuff > > > lead to a lot of trouble on the Raspberry Pi platform (ugly dependencies > > > between firmware, DT and kernel). So i would like to avoid this here. In > > > case the current implementation is a no go, how about letting the ARM core > > > discover the available interfaces e.g. via mailbox interface? > > > > > > For more inspiration take a look at this old thread [1] > > > > Yes, that's the proper way to do this please! This should be a bus and > > dynamically add the devices when found, it is NOT a platform device > > anymore. > > I'm fine with making this a bus, but when it comes to dynamically adding > devices, that depends on the firmware exposing an interface to enumerate > those devices. If that's not possible, are you fine with a custom bus > and hardcoded children device instantiation in the VCHIQ driver ? Yes, that is at least a step forward and is not abusing the platform device/driver code. thanks, greg k-h
