On Sun, 25 Mar 2018 13:53:02 -0700 John Syne <john3909@xxxxxxxxx> wrote: > > On Mar 25, 2018, at 9:54 AM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > > > On Sun, 25 Mar 2018 01:29:41 -0700 > > John Syne <john3909@xxxxxxxxx> wrote: > > > >> Hi Jonathan, > > Hi John, > > > > Please wrap your normal emails (excepting tables) to 80 chars. > Yeah, I’m trying to do that, but I use a Mac and Apple Mail doesn’t > have a feature to wrap at 80 automatically so I have to do > this manually. > > > >> > >> I was speaking with Rodrigo and here is what I think must be done to move > >> ADE7878 out of staging > >> > >> Here are the steps as I see them: > >> > >> 1) Define the IIO Attributes so they are consistent with the IIO ABI. This > >> should be pretty simple given agreement on the naming convention. > > Please don't go just changing attribute names - the driver needs to > > use the standard approach of iio_chan_spec and create the vast > > majority of attributes automatically via that. There 'may' be > > a few corner cases wee don't want to make generic and they 'might' > > be exposed as attributes. > > > > I suspect this change is the 'big' job. The core support necessary > > for RMS and MAV (computedtype or whatever we call it) will need adding > > as well. That is a separate patch set with support for some examples > > in the dummy driver. > Great that you mentioned this, because I though we only needed to > modify the IIO_ATTR naming. I’ll take a look at iio_chan_spec and > the examples in the dummy driver. That is how it was originally done and this is an 'old' driver, but the chan spec stuff does three things : 1) Saves on lots of boiler plate code. 2) Makes it sane to access the device from other driver (hwmon now does something similar btw). 3) Avoids a lot of ABI typos and careful review. > > > >> 2) Map the ADE7854 interrupt status to IIO events. This requires an > >> interrupt processing section. > >> 3) Add DeviceTree support. > >> 4) Create DeviceTree overlay for the ADE7854. > > More a case of bindings for now. If those are used via an overlay > > fine but given we don't have any boards with one one in mainline, > > this is an implementation detail for the user rather than part > > of moving this driver out of staging. > I was thinking more along the lines of documentation to show a > developer what was needed to get the driver working. Do it as an example in the device tree bindings doc. > > > >> 5) Update ADE7854 probe to read in the DeviceTree register settings. > >> 6) Add support for power modes (PM1, PM2). > > This isn't necessary for a move out of staging (nice to have though). > > > >> 7) Not sure if we will support measurement streaming on the ADE7854. > >> The problem is ADE7854 is designed as an SPI master, which means > >> it controls the SPI clock, so the driver must support SPI slave > >> mode. However, the Linux Kernel does not currently support SPI > >> slave mode. We have three choices to make this work and they > >> are all a lot of work: 1) Add support for SPI Slave mode to the > >> kernel, 2) Use hardware to convert SPI signals to I2S signals > >> and with the use of a custom codec, use the ALSA framework to > >> stream the samples (this is an approach I used, but I don’t like > >> it), 3) Move the I2S driver out of the sound subsystem and use it > >> together with DMA to stream samples directly into the ADE7854 driver > >> (my preferred solutions). Perhaps Mark Brown has some ideas on how > >> to make this work. > > I'll be honest, this is an end of line part and frankly more than > > a little crazy. I would go with simply not supporting the measurement > > streaming at all for this part. If you really need it we can then > > move onto the how part, but from what you have said I'm guessing you > > don't care except in an abstract 'it would be nice' sort of a way? > Yeah, I’m moving to the ADE9000 so I’ll drop this. Agreed. We let someone else pick it up if they care. > > > >> > >> The ADE9000 will be much easier because it uses an SPI Slave interface. > >> > >> I hope I have captured everything, but let me know if I have missed anything. > >> > > > > That will do for now ;) I'm sure there will be details that need > > tidying up once we have the above done, but that's true for any new > > driver (and this will be nearly a new driver before things are done). > Thank you again for all the detailed feedback. > > > > Jonathan > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
