All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Rosengren <robert.rosengren@axis.com>
To: Guenter Roeck <linux@roeck-us.net>, Jean Delvare <jdelvare@suse.de>
Cc: "lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	Johan Adolfsson <johana@axis.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] [PATCH] hwmon: (ads7828) Make sample interval configurable
Date: Wed, 28 Jan 2015 07:28:06 +0100	[thread overview]
Message-ID: <54C88176.8070107@axis.com> (raw)
In-Reply-To: <54C87F3C.2020105@axis.com>

My previous mail got blocked by mailing lists for some reasons, so 
trying once more. I apologize if spamming.

On 01/28/2015 07:18 AM, Robert Rosengren wrote:
> On 01/28/2015 05:06 AM, Guenter Roeck wrote:
>> On 01/27/2015 02:34 PM, Jean Delvare wrote:
>>> >On Tue, 27 Jan 2015 12:05:53 -0800, Guenter Roeck wrote:
>>>> >>On Tue, Jan 27, 2015 at 08:54:34PM +0100, Robert Rosengren wrote:
>>>>> >>>Guenter and Jean,
>>>>> >>>
>>>>> >>>To sum up, my problems was related my kernel and hardware configuration, and it now works. Many thanks for your input!
>>>>> >>>
>>>>> >>>However, the values retrieved from hwmon sysfs is not the same as before the regmap patch. Guenter, the byte swap for the regval retrieved by regmap_read. In what order is the bits returned from that function, because it seems as if I disabled that code I get values as I expect (i.e. before the regmap patch).
>>>>> >>>
>>>> >>Trying to understand. Are you saying everything works as expected
>>>> >>if you keep byte_swap set to false ?
> Yes it works as expected, i.e. I can get values from sysfs. The 
> problems I experienced was actually due to moving from an old 
> ads7828-implementation where specific i2c addresses where scanned from 
> the driver, and I first missed to set the correct i2c address for the 
> new driver in the board info.
>
>>>> >>
>>>> >>That might well be, though it might mean that regmap has a bug
>>>> >>in how it treats i2c word read operations. I'll have to look into it
>>>> >>some more.
>>> >
>>> >Remember that SMBus specifies that the LSB comes first (and i2c-core
>>> >implement things that way) while real I2C devices typically send the MSB
>>> >first. This has always caused confusion. This is why a lot of drivers
>>> >need byte-swapping.
>>> >
>> regmap specifies "normal" i2c accesses as MSB first. When SMBus accesses
>> are used, it specifies LSB first. I guess that means that regmap assumes
>> the more common case of MSB first, meaning the driver would not need a byte
>> swap since the chip reports data with MSB first.
>>
>> I just hope I interpret it correctly this time.
>>
>> There is also a configuration flag "val_format_endian" which can be set to
>> REGMAP_ENDIAN_BIG or REGMAP_ENDIAN_LITTLE. Maybe that can be used as well
>> if needed. Either case I'll wait for the samples before I send an updated
>> version of the patch.
>>
>> Guenter
>>
> I tested the driver on 3.15 version of the kernel. Having looked in 
> the git log of regmap.c and regmap-i2c.c, there has been some 
> endianess-related patches going into the kernel in newer versions. 
> Maybe that is the reason for me seeing this problem? I will try to 
> look into that further.
>
> I my test I only disabled following two lines of code
> +	if (data->byte_swap)
> +		regval = swab16(regval);
>
> BR, Robert
>


WARNING: multiple messages have this Message-ID (diff)
From: Robert Rosengren <robert.rosengren@axis.com>
To: Guenter Roeck <linux@roeck-us.net>, Jean Delvare <jdelvare@suse.de>
Cc: "lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	Johan Adolfsson <johana@axis.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] [PATCH] hwmon: (ads7828) Make sample interval configurable
Date: Wed, 28 Jan 2015 06:28:06 +0000	[thread overview]
Message-ID: <54C88176.8070107@axis.com> (raw)
In-Reply-To: <54C87F3C.2020105@axis.com>

My previous mail got blocked by mailing lists for some reasons, so 
trying once more. I apologize if spamming.

On 01/28/2015 07:18 AM, Robert Rosengren wrote:
> On 01/28/2015 05:06 AM, Guenter Roeck wrote:
>> On 01/27/2015 02:34 PM, Jean Delvare wrote:
>>> >On Tue, 27 Jan 2015 12:05:53 -0800, Guenter Roeck wrote:
>>>> >>On Tue, Jan 27, 2015 at 08:54:34PM +0100, Robert Rosengren wrote:
>>>>> >>>Guenter and Jean,
>>>>> >>>
>>>>> >>>To sum up, my problems was related my kernel and hardware configuration, and it now works. Many thanks for your input!
>>>>> >>>
>>>>> >>>However, the values retrieved from hwmon sysfs is not the same as before the regmap patch. Guenter, the byte swap for the regval retrieved by regmap_read. In what order is the bits returned from that function, because it seems as if I disabled that code I get values as I expect (i.e. before the regmap patch).
>>>>> >>>
>>>> >>Trying to understand. Are you saying everything works as expected
>>>> >>if you keep byte_swap set to false ?
> Yes it works as expected, i.e. I can get values from sysfs. The 
> problems I experienced was actually due to moving from an old 
> ads7828-implementation where specific i2c addresses where scanned from 
> the driver, and I first missed to set the correct i2c address for the 
> new driver in the board info.
>
>>>> >>
>>>> >>That might well be, though it might mean that regmap has a bug
>>>> >>in how it treats i2c word read operations. I'll have to look into it
>>>> >>some more.
>>> >
>>> >Remember that SMBus specifies that the LSB comes first (and i2c-core
>>> >implement things that way) while real I2C devices typically send the MSB
>>> >first. This has always caused confusion. This is why a lot of drivers
>>> >need byte-swapping.
>>> >
>> regmap specifies "normal" i2c accesses as MSB first. When SMBus accesses
>> are used, it specifies LSB first. I guess that means that regmap assumes
>> the more common case of MSB first, meaning the driver would not need a byte
>> swap since the chip reports data with MSB first.
>>
>> I just hope I interpret it correctly this time.
>>
>> There is also a configuration flag "val_format_endian" which can be set to
>> REGMAP_ENDIAN_BIG or REGMAP_ENDIAN_LITTLE. Maybe that can be used as well
>> if needed. Either case I'll wait for the samples before I send an updated
>> version of the patch.
>>
>> Guenter
>>
> I tested the driver on 3.15 version of the kernel. Having looked in 
> the git log of regmap.c and regmap-i2c.c, there has been some 
> endianess-related patches going into the kernel in newer versions. 
> Maybe that is the reason for me seeing this problem? I will try to 
> look into that further.
>
> I my test I only disabled following two lines of code
> +	if (data->byte_swap)
> +		regval = swab16(regval);
>
> BR, Robert
>


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  reply	other threads:[~2015-01-28  6:28 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16 12:05 [PATCH] hwmon: (ads7828) Make sample interval configurable Robert Rosengren
2015-01-16 12:05 ` [lm-sensors] " Robert Rosengren
2015-01-16 14:52 ` Guenter Roeck
2015-01-16 14:52   ` [lm-sensors] " Guenter Roeck
2015-01-16 18:30   ` Guenter Roeck
2015-01-16 18:30     ` Guenter Roeck
2015-01-19 11:14     ` SV: " Robert Rosengren
2015-01-19 11:14       ` Robert Rosengren
2015-01-27  7:59     ` Robert Rosengren
2015-01-27  7:59       ` Robert Rosengren
2015-01-27 10:37       ` Jean Delvare
2015-01-27 10:37         ` Jean Delvare
2015-01-27 14:23         ` Guenter Roeck
2015-01-27 14:23           ` Guenter Roeck
2015-01-27 14:07       ` Guenter Roeck
2015-01-27 14:07         ` Guenter Roeck
2015-01-27 19:54         ` Robert Rosengren
2015-01-27 19:54           ` Robert Rosengren
2015-01-27 20:05           ` Guenter Roeck
2015-01-27 20:05             ` Guenter Roeck
2015-01-27 22:34             ` Jean Delvare
2015-01-27 22:34               ` Jean Delvare
2015-01-28  4:06               ` Guenter Roeck
2015-01-28  4:06                 ` Guenter Roeck
2015-01-27 14:26       ` Guenter Roeck
2015-01-27 14:26         ` Guenter Roeck
2015-01-27 16:37       ` Guenter Roeck
2015-01-27 16:37         ` Guenter Roeck
2015-01-16 20:30 ` Guenter Roeck
2015-01-16 20:30   ` [lm-sensors] " Guenter Roeck
2015-01-28  6:18 ` Robert Rosengren
2015-01-28  6:28   ` Robert Rosengren [this message]
2015-01-28  6:28     ` Robert Rosengren
2015-01-28 14:50   ` Guenter Roeck
2015-01-28 14:50     ` Guenter Roeck
2015-01-29  7:00     ` Robert Rosengren
2015-01-29  7:00       ` Robert Rosengren
2015-01-29  7:05       ` Guenter Roeck
2015-01-29  7:05         ` Guenter Roeck
2015-01-29 12:07         ` Robert Rosengren
2015-01-29 12:07           ` Robert Rosengren
2015-01-29 14:10           ` Guenter Roeck
2015-01-29 14:10             ` Guenter Roeck
2015-01-29 19:30           ` Guenter Roeck
2015-01-29 19:30             ` Guenter Roeck
2015-01-31 20:11             ` Guenter Roeck
2015-01-31 20:11               ` Guenter Roeck
2015-02-02  8:12               ` Robert Rosengren
2015-02-02  8:12                 ` Robert Rosengren
2015-02-02 16:21                 ` Guenter Roeck
2015-02-02 16:21                   ` Guenter Roeck

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=54C88176.8070107@axis.com \
    --to=robert.rosengren@axis.com \
    --cc=jdelvare@suse.de \
    --cc=johana@axis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lm-sensors@lm-sensors.org \
    /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 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.