From: Graeme Gregory <gg@slimlogic.co.uk>
To: "Kozaruk, Oleksandr" <oleksandr.kozaruk@ti.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
"tony@atomide.com" <tony@atomide.com>,
"benoit.cousson@linaro.org" <benoit.cousson@linaro.org>,
"Nayak, Rajendra" <rnayak@ti.com>,
"Ujfalusi, Peter" <peter.ujfalusi@ti.com>,
"ABRAHAM, KISHON VIJAY" <kishon@ti.com>,
"jic23@cam.ac.uk" <jic23@cam.ac.uk>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
"lars@metafoo.de" <lars@metafoo.de>,
"sameo@linux.intel.com" <sameo@linux.intel.com>,
"ch.naveen@samsung.com" <ch.naveen@samsung.com>,
"poeschel@lemonage.de" <poeschel@lemonage.de>,
"Kim, Milo" <Milo.Kim@ti.com>,
"Krishnamoorthy, Balaji T" <balajitk@ti.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
devicetree-discuss@lis
Subject: Re: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Date: Mon, 15 Jul 2013 15:05:05 +0100 [thread overview]
Message-ID: <51E40191.8010708@slimlogic.co.uk> (raw)
In-Reply-To: <2A7ABDFCE21540479A5AEB0244A684D5E3D0E3@DNCE04.ent.ti.com>
On 15/07/13 14:30, Kozaruk, Oleksandr wrote:
> Hello Jonathan,
> Thanks for the review.
>
>> Couple of things:
>>
>> 1) It looks from the driver that a lot of the channels are not measuring
>> voltages but rather temperature or currents etc. If so then their
>> types in the channel mask should be appropriately set. Also if some
>> of the channels are entirely internal test networks, what is the benefit
>> of exposing them to userspace as readable channels?
>> If channels are merely 'suggested' as being used for temperatures etc
>> then it is fine to keep them as voltages.
> There are two kinds of channel for measuring temperature: die temperature
> and those that measure temperature indirectly measuring voltage on resistive
> load(NTC sensor).
> die temperature is calculated by some formulas which convert ADC code to
> temperature. This is not implemented in the driver.
> Channels intended to measure temperature with NTC sensor have inbuilt current
> sources. Voltage measured by this channels and specific NTC could be converted
> to temperature.
> This is the reason they chosen to be voltage channels.
> As for test network I'll remove them from exposing to userspace.
> [...]
>
>>> +static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
>>> + int channel, int *res)
>>> +{
>>> + u8 reg = gpadc->pdata->channel_to_reg(channel);
>>> + u8 val[2];
>> le16 val;
>>> + int ret;
>>> +
>> ret = twl6030_gpadc_read(val, reg);
>> (note that (reg, val) ordering of parameters would be a more common choice)
>>
>>> + ret = twl6030_gpadc_read(val, reg);
>>> + if (ret) {
>>> + dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
>>> + return ret;
>>> + }
>>> +
>> res = le16_to_cpup(val);
>>
>>> + *res = (val[1] << 8) | val[0];
>>> +
>>> + return ret;
>>> +}
>>> +
> You mean something like this:
> static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
> int channel, int *res)
> {
> u8 reg = gpadc->pdata->channel_to_reg(channel);
> __le16 val;
> int ret;
>
> ret = twl6030_gpadc_read(reg, (u8 *)&val);
> if (ret) {
> dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
> return ret;
> }
>
> *res = le16_to_cpup(&val);
>
> return ret;
> }
> Note, that twl6030_gpadc_read() is just wrapper for twl_i2c_read() which takes
> "an array of num_bytes containing data to be read"
> I like the original implementation better then this(if I did it correctly)
> Do you insist on this change?
> [...]
>
>>> +static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
>>> + int channel, int *val)
>>> +{
>>> + int raw_code;
>>> + int corrected_code;
>>> + int channel_value;
>>> + int ret;
>>> +
>>> + ret = twl6030_gpadc_get_raw(gpadc, channel, &raw_code);
>>> + if (ret)
>>> + return ret;
>>> +
>> Might first thought on seeing this is that it would be better to return
>> raw for all channels and provide the scale and offset info_mask elements
>> where possible rather than doing the conversion in the kernel. Note we
> In our custom kernel branch battery driver needs battery voltage and
> temperature. Thus the conversion anyway is done in the kernel, either
> in ADC driver or battery driver.
>
>> allow really quite a bit of precision on those values so I doubt it
>> will be a problem.
>>
>> If nothing else it would make everything rather more consistent.
>>
> [...]
>
>>> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
>>> +{
>>> + int chn, d1 = 0, d2 = 0, temp;
>>> + u8 trim_regs[17];
>>> + int ret;
>>> +
>>> + ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
>>> + TWL6030_GPADC_TRIM1, 16);
>>> + if (ret < 0) {
>>> + dev_err(gpadc->dev, "calibration failed\n");
>>> + return ret;
>>> + }
>>> +
>> /*
>> * Loop
>> please for kernel code.
>>> + /* Loop to calculate the value needed for returning voltages from
>>> + * GPADC not values.
>>> + *
>>> + * gain is calculated to 3 decimal places fixed point.
>>> + */
>>> + for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
>>> +
>>> + switch (chn) {
>>> + case 0:
>>> + case 1:
>>> + case 2:
>>> + case 3:
>>> + case 4:
>>> + case 5:
>>> + case 6:
>>> + case 11:
>>> + case 12:
>>> + case 13:
>>> + case 14:
>>> + /* D1 */
>>> + d1 = (trim_regs[3] & 0x1F) << 2;
>>> + d1 |= (trim_regs[1] & 0x06) >> 1;
>>> + if (trim_regs[1] & 0x01)
>>> + d1 = -d1;
>>> +
>>> + /* D2 */
>>> + d2 = (trim_regs[4] & 0x3F) << 2;
>>> + d2 |= (trim_regs[2] & 0x06) >> 1;
>>> + if (trim_regs[2] & 0x01)
>>> + d2 = -d2;
>>> + break;
>>> + case 8:
>> No coment on your code, but this is an 'interesting' bit
>> of bit packing...
>> I did vaguely wonder if this could be mapped to a big lookup table,
>> but having tried it I think I end up with something almost as tricky
>> to read.. Oh well that was a fun 10 minute diversion ;)
> This is inherited code from Graeme - original author of implementation
> for twl6032.
> [...]
>
That bit is the bane of my life :-( I think the data sheet used to
changed weekly as the hardware guys did not understand the difference
between ones and twos complement!
The reason for the crazy packing is there was not enough space allocated
in hardware for the change from 10 to 12 bits for the error values
between 6030 and 6032.
Graeme
next prev parent reply other threads:[~2013-07-15 14:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-12 7:18 [PATCH v3 0/2] TWL6030, TWL6032 GPADC driver Oleksandr Kozaruk
2013-07-12 7:18 ` [PATCH v3 1/2] ARM: dts: twl: Add GPADC data to device tree Oleksandr Kozaruk
2013-07-12 7:18 ` [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver Oleksandr Kozaruk
[not found] ` <1373613482-28390-3-git-send-email-oleksandr.kozaruk-l0cyMroinI0@public.gmane.org>
2013-07-12 19:42 ` Jonathan Cameron
[not found] ` <51E05C0B.5050009-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2013-07-15 13:30 ` Kozaruk, Oleksandr
2013-07-15 14:05 ` Graeme Gregory [this message]
2013-07-12 19:56 ` Lars-Peter Clausen
2013-07-15 11:09 ` Kozaruk, Oleksandr
[not found] ` <2A7ABDFCE21540479A5AEB0244A684D5E3D067-bXo5r3zvlxeIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2013-07-15 11:33 ` Lars-Peter Clausen
[not found] ` <51E3DE21.9060105-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
2013-07-17 13:45 ` Oleksandr Kozaruk
2013-07-17 14:47 ` Lars-Peter Clausen
[not found] ` <51E05F6C.1060506-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
2013-07-15 11:56 ` Grygorii Strashko
[not found] ` <51E3E362.6090903-l0cyMroinI0@public.gmane.org>
2013-07-15 12:33 ` Lars-Peter Clausen
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=51E40191.8010708@slimlogic.co.uk \
--to=gg@slimlogic.co.uk \
--cc=Milo.Kim@ti.com \
--cc=balajitk@ti.com \
--cc=benoit.cousson@linaro.org \
--cc=ch.naveen@samsung.com \
--cc=devicetree-discuss@lis \
--cc=grant.likely@linaro.org \
--cc=jic23@cam.ac.uk \
--cc=jic23@kernel.org \
--cc=kishon@ti.com \
--cc=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleksandr.kozaruk@ti.com \
--cc=peter.ujfalusi@ti.com \
--cc=poeschel@lemonage.de \
--cc=rnayak@ti.com \
--cc=rob.herring@calxeda.com \
--cc=sameo@linux.intel.com \
--cc=tony@atomide.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).