[RFC]Question regrading TODO list for bcm2835 camera and bcm2835-audio

[Michael Zoran]

On Sun, 2017-02-26 at 22:16 +0100, Stefan Wahren wrote:
> Hi Michael,
> 
> > Michael Zoran <mzoran at crowfest.net> hat am 26. Februar 2017 um
> > 20:56 geschrieben:
> > 
> > 
> > I noticed that the TODO list for the RPI camera and the audio
> > driver
> > have fixing the issue of the runtime load order dependency between
> > vchiq and the function driver(camera/audio). The TODO list mentions
> > making the camera driver a platform driver.
> > 
> > I've been toying for awhile with the concept of making vchiq a bus
> > driver that function drivers register with rather the making the
> > camera
> > a platform driver.  Meaning when vchiq loads, it walks the
> > registered
> > functions drivers and using the standard driver methods and bus
> > matching methods it calls the probe function on the function
> > drivers.
> > 
> > Taking this farther, one could also change vchiq to be a non-
> > platform
> > driver with the raspberrypi firmware driver also being a bus
> > driver.  I
> > have prototyped converting the firmware driver to be a bus driver,
> > but
> > perhaps it would be better to start from the other direction and
> > convert the camera and audio drivers first.
> > 
> 
> i don't have a clear vision for the vchiq driver. But couldn't we fix
> the kernel module support before such fundamental changes?

I'm not sure about that.  vchiq does have some mechanisms for calling
back into drivers once its loaded, but like many things about vchiq it
wasn't finished.

The TODO mentions converting the camera to a platform driver which to
me means YET ANOTHER platform driver in the tree with an undocumented
DT binding.

I'm also don't like the total top down approach to driver dependencies
that the platform drivers use.  The whole deferred probing seems broken
since circular driver dependencies are rare.  Taking a bottom up
approach to driver loading seems better to me.