On Mon, Jul 22, 2019 at 12:43 PM Jason Kridner <jkridner@beagleboard.org> wrote:
> On Wed, Jul 17, 2019 at 11:28 AM Jason Kridner <jkridner@beagleboard.org> wrote:
> > On Tue, Jul 16, 2019 at 3:25 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > On Sun, Jul 14, 2019 at 01:13:37AM +0530, Vaishnav MA wrote:
> > > > > On Sat, Jul 13, 2019 at 06:03:02PM +0530, Vaishnav MA wrote:
> >
> > I believe there are two problems here to solve:
Let's just focus on #1.
> >
> > 1. How do we specify the extra data?
The *extra* data here is whatever else a driver needs to load. Manifests have the buses needed and name to find the driver, but are missing any association between extra signals, like IRQ or other named GPIOs. We'd like a common way to specify those.
Chris has suggested adding some additional data to the manifests, like
[string-descriptor 2]string = driver-specific-gpio-name=manifest-specific-gpio-name
I've proposed trying to define mikroBus as an extra bundle type and add another driver to try to plug in any missing platform data.
Vaishnav has suggested to me this:
> consider an example for an mpu9dof click , this click requires a greybus i2c bus and a greybus gpio interrupt ,
> so the manifest will have a i2c protocol on cport1 and gpio protocol on cport2 , loading the manifest will set up
> the corresponding peripherals (greybus gpio, greybus i2c bus) , also the manifest will have the click name and
> port , which will be passed to the Mikrobus driver for device instantiation
So, again, putting a bit of extra metadata into the manifest, but here, specifically at the bundle level, but, I feel he's saying something very similar to me regarding having a mikroBus driver pull that data out and call the appropriate driver registration.
Is there something just off in our terminology or understanding of the architecture that is preventing us from finding the obvious answer?
--
https://beagleboard.org/about - a 501c3 non-profit educating around open hardware computing