i.MX28 die temperature

[marek.vasut@gmail.com (Marek Vasut)]

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?

> 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?)
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.

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