On Wed, Jul 17, 2019 at 11:28 AM Jason Kridner <
jkridner@xxxxxxxxxxxxxxx> wrote:
> On Tue, Jul 16, 2019 at 3:25 PM Greg KH <
gregkh@xxxxxxxxxxxxxxxxxxx> 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:
>
> 1. How do we specify the extra data?
I get that greybus itself shouldn't embed platform data for all the devices, but I think it only encapsulates the bus transports. Is there a generic place for the IRQ/RESET/etc. interfaces most all sensors need?
Let's take a random SPI-based IIO sensor as an example, bmg160[1].
I think an approach could be to come up with a generic IIO protocol class for greybus, rather than an actual protocol class for each sensor we'd like to use. In this generic IIO protocol class implementation, the extra platform data could be included using commonly named greybus gpio resources.
Alternatively, a generic mikroBus protocol class for greybus could be created, assuming all the resources that bus assumes (GPIO/PWM/SPI/I2C/etc.). Not sure if this is better.
Since Click boards will use a common GPIO for IRQ and the SPI device structure includes the irq entry[2], it would seem this could be done in at least a Click-generic way if not an IIO-generic way over greybus.
Of course, drivers that aren't direct usage of SPI (or other provided buses) interfaces like fbtft_device[3] would still require an additional driver to provide their platform data, so we'd either need to figure out how to bury that under a display class or create another driver to provide platform data for that group of drivers.
Would that be the right track?
>
> 2. For a gbsim implementation, how do we add the translation layer and build the platform data needed by the drivers?
>
If there's no preference here, would defining a JSON format and dataset to provide the information to either the gbsim or microcontroller implementations be something acceptable? YAML? other?
Regards,
Jason
--
https://beagleboard.org/about - a 501c3 non-profit educating around open hardware computing
