Re: i.MX28 die temperature

Re: i.MX28 die temperature

[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

Re: i.MX28 die temperature

[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.  die temp and basic
adc are fine but no one has taken on a touchscreen controller via that
approach yet.  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.
> 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 ;)
>
> 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
>

Re: i.MX28 die temperature

[Marek Vasut]

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

Best regards,
Marek Vasut

Re: i.MX28 die temperature

[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.

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

>
>> 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
>

Re: i.MX28 die temperature

[Marek Vasut]

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

Re: i.MX28 die temperature

[Juergen Beisert]

Hi Jonathan,

Jonathan Cameron 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.

It requires a more or less complex state-machine to switch the used 4 or 5 
pins to different modes to measure the X/Y position and the pressure. And 
these pins interfere with the ADC input pins.

> [...]

Regards,
Juergen
-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |

Re: i.MX28 die temperature

[Marek Vasut]

Dear Juergen Beisert,

[...]
> 
> It requires a more or less complex state-machine to switch the used 4 or 5
> pins to different modes to measure the X/Y position and the pressure. And
> these pins interfere with the ADC input pins.
> 
> > [...]

I said I'll go through it, but it seems the IIO changed again, so I'll need to 
wrap my head around new stuff in there.

Besides, I have a feeling that the driver, as is, just simply doesn't fit in as 
it should. I'm discussing with Jonathan, since I can't really make heads or 
tails from the IIO api. It's way too complex and unless I really missed 
something, way underdocumented.

> Regards,
> Juergen

Best regards,
Marek Vasut

Re: i.MX28 die temperature

[Jonathan Cameron]

On 6/27/2012 11:58 PM, Marek Vasut wrote:
> Dear Juergen Beisert,
>
> [...]
>>
>> It requires a more or less complex state-machine to switch the used 4 or 5
>> pins to different modes to measure the X/Y position and the pressure. And
>> these pins interfere with the ADC input pins.
>>
>>> [...]
>
> I said I'll go through it, but it seems the IIO changed again, so I'll need to
> wrap my head around new stuff in there.
Yeah, sorry about that - people keep wanting new stuff ;)
>
> Besides, I have a feeling that the driver, as is, just simply doesn't fit in as
> it should. I'm discussing with Jonathan, since I can't really make heads or
> tails from the IIO api. It's way too complex and unless I really missed
> something, way underdocumented.
Any documentation writers welcome!
The real trick currently is to
a) figure out what is similar an already present
b) figure out if that driver is actually a good starting point. If it's
left staging then it's clean, but there may be a closer 'clean' driver
still in staging.

Having had documentation continually get left behind we did add
a 'dummy' driver that covers most stuff with lots of comments.
(still in staging at the mo staging/iio/iio_simple_dummy*)


>
>> Regards,
>> Juergen
>
> Best regards,
> Marek Vasut
>

Re: i.MX28 die temperature

[Marek Vasut]

Dear Juergen Beisert,

[...]

So, I've been thinking about mapping channels and delay slots at runtime. Is it 
really necessary? I know it's really cool and all, but it adds a lot of 
complexity. For starters, I was thinking we should try to do static mapping. And 
when that's all perfected, go further and try doing it dynamically. What do you 
think about the following DT binding:

lradc@80050000 {
        compatible = "fsl,imx28-lradc";
        reg = <0x80050000 2000>;
        interrupts = <10 14 15 16 17 18 19
                        20 21 22 23 24 25>;
        fsl,delay-freq = <10 100 50 60>;
        fsl,delay-repeat = <3 10 5 6>;
        fsl,delay-channels = <
                0 2 0 3 0 4 0 5
                1 8 1 9 2 12 3 13>;
        status = "disabled";
};

fsl,delay-freq would be an array (for all four delay channels) of their sampling 
frequencies.

fsl,delay-repeat would be an array (for all four delay channels) of the 
oversampling count.

fsl,delay-channels would be an array (for all four delay channels) of touples of 
delay channel, adc channel. In the above example, it's ADC channels 2,3,4,5 
mapped to delay channel 0, ADC channels 8,9 mapped to delay channel 1 etc.

Now, it might be dumb, advice is welcome!

> > [...]
> 
> Regards,
> Juergen

Best regards,
Marek Vasut

Re: i.MX28 die temperature

[Marek Vasut]

Dear Marek Vasut,

> Dear Juergen Beisert,
> 
> [...]
> 
> So, I've been thinking about mapping channels and delay slots at runtime.
> Is it really necessary? I know it's really cool and all, but it adds a lot
> of complexity. For starters, I was thinking we should try to do static
> mapping. And when that's all perfected, go further and try doing it
> dynamically. What do you think about the following DT binding:
> 
> lradc@80050000 {
>         compatible = "fsl,imx28-lradc";
>         reg = <0x80050000 2000>;
>         interrupts = <10 14 15 16 17 18 19
>                         20 21 22 23 24 25>;
>         fsl,delay-freq = <10 100 50 60>;
>         fsl,delay-repeat = <3 10 5 6>;
>         fsl,delay-channels = <
>                 0 2 0 3 0 4 0 5
>                 1 8 1 9 2 12 3 13>;


btw. I don't like the idea of those tuples here ... any hint how to do it 
better?

>         status = "disabled";
> };
> 
> fsl,delay-freq would be an array (for all four delay channels) of their
> sampling frequencies.
> 
> fsl,delay-repeat would be an array (for all four delay channels) of the
> oversampling count.
> 
> fsl,delay-channels would be an array (for all four delay channels) of
> touples of delay channel, adc channel. In the above example, it's ADC
> channels 2,3,4,5 mapped to delay channel 0, ADC channels 8,9 mapped to
> delay channel 1 etc.
> 
> Now, it might be dumb, advice is welcome!
> 
> > > [...]
> > 
> > Regards,
> > Juergen
> 
> Best regards,
> Marek Vasut

Best regards,
Marek Vasut

Re: i.MX28 die temperature

[Peter Turczak]

Hi Marek,
hi Jonathan,

while trying to implement a battery charger driver for the mx28 platform I came across your posts. Sorry to stir up an old thread but it was running the same way.

On Jun 27, 2012, at 2:00 PM, Marek Vasut wrote:
Dear Jonathan Cameron,
> 
>> On 6/26/2012 8:02 PM, Marek Vasut wrote:
>>> Dear Juergen Beisert,
>>>> 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 am currently trying to go this route, the idea is to use the consumer api to get the required battery management data to the battery driver. As a foundation I used the driver provided by Freescale which uses the lradc directly which I found rather bad in the system context.

Maybe one could map all the driver muxing and use specific parameters in explicitly named iio channels? But this could lead to permanent reconfiguring of the LRADC and maybe quite difficult handling of the measurements that arrive asynchronously.

Also I don't seem to quite get the usage of iio_map_array_register() which seems to enable the consumer api access to the device. I found only one use of it in an example in 
max1363.c which confused me even more. How do I correctly provide the iio_map struct? What is the consumer_dev_name used for and which "namespace" should used there, is it the name used in a platform_driver struct or the instances name (given there can only be one internal mxs battery charger at a time)?

Best regards,
  Peter

Re: i.MX28 die temperature

[Marek Vasut]

Dear Peter Turczak,

> Hi Marek,
> hi Jonathan,
> 
> while trying to implement a battery charger driver for the mx28 platform I
> came across your posts. Sorry to stir up an old thread but it was running
> the same way.
> 
> On Jun 27, 2012, at 2:00 PM, Marek Vasut wrote:
> Dear Jonathan Cameron,
> 
> >> On 6/26/2012 8:02 PM, Marek Vasut wrote:
> >>> Dear Juergen Beisert,
> >>> 
> >>>> 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 am currently trying to go this route, the idea is to use the consumer api
> to get the required battery management data to the battery driver. As a
> foundation I used the driver provided by Freescale which uses the lradc
> directly which I found rather bad in the system context.

We have some basic LRADC driver in upstream already, you should use that.

See drivers/staging/iio/adc/mxs-lradc.c

> Maybe one could map all the driver muxing and use specific parameters in
> explicitly named iio channels? But this could lead to permanent
> reconfiguring of the LRADC and maybe quite difficult handling of the
> measurements that arrive asynchronously.
> 
> Also I don't seem to quite get the usage of iio_map_array_register() which
> seems to enable the consumer api access to the device. I found only one
> use of it in an example in max1363.c which confused me even more. How do I
> correctly provide the iio_map struct? What is the consumer_dev_name used
> for and which "namespace" should used there, is it the name used in a
> platform_driver struct or the instances name (given there can only be one
> internal mxs battery charger at a time)?
> 
> Best regards,
>   Peter

Best regards,
Marek Vasut

Re: i.MX28 die temperature

[Peter Turczak]

Hi Marek,

On Oct 23, 2012, at 10:52 AM, Marek Vasut wrote:
> We have some basic LRADC driver in upstream already, you should use that.
> 
> See drivers/staging/iio/adc/mxs-lradc.c
Thanks for the heads-up.
I was referring to this driver (pulled from linus' 3.7rc), it does not currently seem to have a consumer api for use within other kernel modules. Maybe I'm just heading the wrong way now...

Best regards,
  Peter

Re: i.MX28 die temperature

[Marek Vasut]

Dear Peter Turczak,

> Hi Marek,
> 
> On Oct 23, 2012, at 10:52 AM, Marek Vasut wrote:
> > We have some basic LRADC driver in upstream already, you should use that.
> > 
> > See drivers/staging/iio/adc/mxs-lradc.c
> 
> Thanks for the heads-up.
> I was referring to this driver (pulled from linus' 3.7rc), it does not
> currently seem to have a consumer api for use within other kernel modules.
> Maybe I'm just heading the wrong way now...

Ah yes, it doesn't ... feel free to implement it. It can -- though -- read the 
CPU die temperature, just sample those two channels, substract one from another 
and multiply by the coeficient ... you'll find that in the datasheet.

Best regards,
Marek Vasut