Dear Jonathan Cameron, > On 6/26/2012 8:02 PM, Marek Vasut wrote: > > Dear Juergen Beisert, > > > >> Hi Marek, > >> > >> Marek Vasut wrote: > >>> [...] > >>> > >>>>> Take a look at: http://www.spinics.net/lists/linux-iio/msg04345.html > >>>> > >>>> Any progress here with inclusion in some git tree? > >>> > >>> Well ... I recently raised from the dead. It's on the schedule, > >>> obviously help is welcome. > >> > >> I tried a little bit with your driver. The disadvantage I see is, its > >> claims all the free AD channels. But a few of them can also act as a > >> touchscreen controller. Shouldn't be the driver handle the channel usage > >> dynamically? > > > > I wonder, I'd rather see this driver behave as a composite driver, what > > do you think? > > Alternative (though it's still in development) would be to use IIO > as the ADC layer and sit the other parts on top. I think you need to adjust a few bits there and there in the hardware to behave as a touchscreen. Will IIO be able to handle that somehow ? > die temp and basic > adc are fine but no one has taken on a touchscreen controller via that > approach yet. Is there any example of these basic things already? > They tend to have a nasty large number of extremely > special purpose bits. I've certainly not thought through how to handle > those yet. > > >> Also this AD module on the SoC can measure the die > >> temperature, battery voltage and some other power supplies. > >> I see more than one framework this driver should connect to: simple ADC > >> (IIO), touchscreen controller (INPUT), die temp (POWER?), various > >> voltages (POWER? REGULATOR?). Should it be a multi function device? > > > > Correct, making it a MFD device with common channel-management logic is > > the way to go. And it's gonna be a few resends of this driver, that's > > for certain. I'm not confident I'll be able to make it right at the > > first try ;-) > > > > INPUT -- touchscreen > > IIO -- die temp and LRADC (maybe random voltages?) > > Mapping the die temp onto hwmon as obviously thats where it ultimately > should appear. Ah correct. > > POWER -- battery > > > > But all this MFD goo is quite simple, the hard part is the channel > > management logic. From the top of my head, there're 16 channels, 8 can > > be sampled at the same time and there are 4 configuration triggers. > > Making it one hell of a complex hardware. > > It is indeed a nasty beast. Good luck ;) Mmm ... sounds more like "condolences" :-D > > I'll fix the remnants of SPI and start on this beast tonight or tomorrow. > > Since there was some progress in the IIO, I believe I'll have to rework > > it a bit. > > > >> Juergen > > > > Best regards, > > Marek Vasut > > -- > > 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 Best regards, Marek Vasut -- 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
