From: Jonathan Cameron <jic23@cam.ac.uk> To: Marek Vasut <marek.vasut@gmail.com> Cc: Juergen Beisert <jbe@pengutronix.de>, linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: i.MX28 die temperature Date: Wed, 27 Jun 2012 08:21:47 +0100 [thread overview] Message-ID: <4FEAB48B.4010108@cam.ac.uk> (raw) In-Reply-To: <201206262102.15698.marek.vasut@gmail.com> 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 >
WARNING: multiple messages have this Message-ID (diff)
From: jic23@cam.ac.uk (Jonathan Cameron) To: linux-arm-kernel@lists.infradead.org Subject: i.MX28 die temperature Date: Wed, 27 Jun 2012 08:21:47 +0100 [thread overview] Message-ID: <4FEAB48B.4010108@cam.ac.uk> (raw) In-Reply-To: <201206262102.15698.marek.vasut@gmail.com> 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 at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
next prev parent reply other threads:[~2012-06-27 7:21 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-03-28 15:13 i.MX28 die temperature Randle, Bill 2012-03-29 2:37 ` Shawn Guo 2012-03-29 15:52 ` Randle, Bill 2012-04-04 23:51 ` Marek Vasut 2012-04-05 0:07 ` Randle, Bill 2012-04-05 0:36 ` Fabio Estevam 2012-06-22 11:49 ` Juergen Beisert 2012-06-22 17:19 ` Marek Vasut 2012-06-26 8:12 ` Juergen Beisert 2012-06-26 19:02 ` Marek Vasut 2012-06-26 19:02 ` Marek Vasut 2012-06-27 7:21 ` Jonathan Cameron [this message] 2012-06-27 7:21 ` Jonathan Cameron 2012-06-27 12:00 ` Marek Vasut 2012-06-27 12:00 ` Marek Vasut 2012-06-27 12:06 ` Jonathan Cameron 2012-06-27 12:06 ` Jonathan Cameron 2012-06-27 12:25 ` Marek Vasut 2012-06-27 12:25 ` Marek Vasut 2012-06-27 12:33 ` Juergen Beisert 2012-06-27 12:33 ` Juergen Beisert 2012-06-27 22:58 ` Marek Vasut 2012-06-27 22:58 ` Marek Vasut 2012-06-28 8:00 ` Jonathan Cameron 2012-06-28 8:00 ` Jonathan Cameron 2012-06-28 3:05 ` Marek Vasut 2012-06-28 3:05 ` Marek Vasut 2012-06-28 15:42 ` Marek Vasut 2012-06-28 15:42 ` Marek Vasut 2012-10-23 8:48 ` Peter Turczak 2012-10-23 8:48 ` Peter Turczak 2012-10-23 8:52 ` Marek Vasut 2012-10-23 8:52 ` Marek Vasut 2012-10-23 10:22 ` Peter Turczak 2012-10-23 10:22 ` Peter Turczak 2012-10-23 10:32 ` Marek Vasut 2012-10-23 10:32 ` Marek Vasut
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4FEAB48B.4010108@cam.ac.uk \ --to=jic23@cam.ac.uk \ --cc=jbe@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-iio@vger.kernel.org \ --cc=marek.vasut@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.