Re: i.MX28 die temperature

[Marek Vasut <marex@denx.de>]

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@vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > Best regards,
> > Marek Vasut

Best regards,
Marek Vasut