Dear Jonathan Cameron, > On 6/27/2012 1:00 PM, Marek Vasut wrote: > > 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 ? > > No means of doing it yet. I'm not entirely sure this can be done > generically. I'm not really familiar enough with touchscreen adcs as > none of my boards have one. At worst I'm sure we can put some > hooks in to get hold of the underlying device if necessary. I'll think about this. Would mx233 board be enough for you? > >> 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? > > Saddly only patches posted on the list for the interrupt driven side of > things. I have an updated version (that acutally works reasonably well) > but haven't posted as yet as want to take another look at some of the > error cases when switching buffers in and out (all about rolling back > sucessfully to a valid configuration when an invalid one has failed). > > The hwmon stuff is in tree though as drivers/staging/iio/iio_hwmon.c I > really ought to get round to posting that one for inclusion under > drivers/hmwon. Guenter was reasonably happy with the version that is > there so shouldn't be too much trouble. Oh, will check it. > >> 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 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
