From: mgreer@mvista.com (Mark A. Greer)
To: Jean Delvare <khali@linux-fr.org>
Cc: LM@ozlabs.org, linuxppc-embedded@ozlabs.org,
Sensors <lm-sensors@lm-sensors.org>
Subject: [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374
Date: Thu, 09 Jun 2005 21:07:54 +0000 [thread overview]
Message-ID: <42A89338.209@mvista.com> (raw)
In-Reply-To: <20050609192551.76b103ea.khali@linux-fr.org>
Hi Jean,
Jean Delvare wrote:
>Hi Randy and all,
>
>Sorry for the delay.
>
>[Eugene Surovegin]
>
>
>>I wonder, why you chose to use those 1-byte SMBus transfers instead
>>of i2c transfer.
>>
>>
>
>[Randy Vinson]
>
>
>>I was simply following the guidelines in
>>Documentation/i2c/writing-clients as noted in the driver header. This
>>note was in the driver I used as my base, so I just followed along.
>>
>>
>
>The document file says:
>
>"If you can choose between plain i2c communication and SMBus level
>communication, please use the last. All adapters understand SMBus level
>commands, but only some of them understand plain i2c!"
>
>The "if you can choose" is important. It doesn't suggest that you should
>use a less efficient way, but that you use the SMBus API when the I2C
>transfer you want to use happens to exist in the SMBus API.
>
>Even when sticking to SMBus commands, it is quite frequent that there
>are different ways to retrieve the same information, of varying
>availability and speed. One good example of this are EEPROMs. EEPROMs
>are I2C devices which can be accessed using SMBus commands. You can read
>bytes one by one (SMBus Read Byte Data command), or continuously as
>different reads (first one SMBus Write Byte, then many SMBus Read Byte),
>or continuously as a single read (I2C Block Read, supported by some
>SMBus controllers). If you look at the eeprom.c drivers, you'll see that
>the second and the third method are both implemented. The advantage is
>that:
>
I interpreted the doc the same way Randy did when I did the m41t00 chip
code. Also, Mark Studebaker seemed to support that interpretation in
this email: http://archives.andrew.net.au/lm-sensors/msg29325.html
I suppose the best thing to do is check if the adapter is a true i2c
ctlr (something like: i2c_check_functionality(adapter, I2C_FUNC_I2C))
and base the cmds used on that.
We can do something similar with I2C_FUNC_SMBUS_READ_I2C_BLOCK &
I2C_FUNC_SMBUS_WRITE_BLOCK_DATA to check if we can use the smbus block
cmds too, correct?
Mark
WARNING: multiple messages have this Message-ID (diff)
From: "Mark A. Greer" <mgreer@mvista.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: LM@ozlabs.org, linuxppc-embedded@ozlabs.org,
Sensors <lm-sensors@lm-sensors.org>
Subject: Re: [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
Date: Thu, 09 Jun 2005 12:06:32 -0700 [thread overview]
Message-ID: <42A89338.209@mvista.com> (raw)
In-Reply-To: <20050609192551.76b103ea.khali@linux-fr.org>
Hi Jean,
Jean Delvare wrote:
>Hi Randy and all,
>
>Sorry for the delay.
>
>[Eugene Surovegin]
>
>
>>I wonder, why you chose to use those 1-byte SMBus transfers instead
>>of i2c transfer.
>>
>>
>
>[Randy Vinson]
>
>
>>I was simply following the guidelines in
>>Documentation/i2c/writing-clients as noted in the driver header. This
>>note was in the driver I used as my base, so I just followed along.
>>
>>
>
>The document file says:
>
>"If you can choose between plain i2c communication and SMBus level
>communication, please use the last. All adapters understand SMBus level
>commands, but only some of them understand plain i2c!"
>
>The "if you can choose" is important. It doesn't suggest that you should
>use a less efficient way, but that you use the SMBus API when the I2C
>transfer you want to use happens to exist in the SMBus API.
>
>Even when sticking to SMBus commands, it is quite frequent that there
>are different ways to retrieve the same information, of varying
>availability and speed. One good example of this are EEPROMs. EEPROMs
>are I2C devices which can be accessed using SMBus commands. You can read
>bytes one by one (SMBus Read Byte Data command), or continuously as
>different reads (first one SMBus Write Byte, then many SMBus Read Byte),
>or continuously as a single read (I2C Block Read, supported by some
>SMBus controllers). If you look at the eeprom.c drivers, you'll see that
>the second and the third method are both implemented. The advantage is
>that:
>
I interpreted the doc the same way Randy did when I did the m41t00 chip
code. Also, Mark Studebaker seemed to support that interpretation in
this email: http://archives.andrew.net.au/lm-sensors/msg29325.html
I suppose the best thing to do is check if the adapter is a true i2c
ctlr (something like: i2c_check_functionality(adapter, I2C_FUNC_I2C))
and base the cmds used on that.
We can do something similar with I2C_FUNC_SMBUS_READ_I2C_BLOCK &
I2C_FUNC_SMBUS_WRITE_BLOCK_DATA to check if we can use the smbus block
cmds too, correct?
Mark
next prev parent reply other threads:[~2005-06-09 21:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-03 21:36 [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip Randy Vinson
2005-06-04 7:59 ` [lm-sensors] [PATCH 1/2] Add support for Maxim/Dallas DS1374 Randy Vinson
2005-06-03 21:41 ` [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip Kumar Gala
2005-06-04 7:59 ` [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Kumar Gala
2005-06-03 22:05 ` [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip Randy Vinson
2005-06-04 7:59 ` [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Randy Vinson
2005-06-03 21:43 ` [PATCH 2/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip Randy Vinson
2005-06-04 7:59 ` [lm-sensors] [PATCH 2/2] Add support for Maxim/Dallas DS1374 Randy Vinson
2005-06-03 21:46 ` [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip Eugene Surovegin
2005-06-04 7:59 ` [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Eugene Surovegin
2005-06-03 22:17 ` [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip Randy Vinson
2005-06-04 7:59 ` [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Randy Vinson
2005-06-09 17:25 ` [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip Jean Delvare
2005-06-09 19:26 ` [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas Jean Delvare
2005-06-09 19:06 ` Mark A. Greer [this message]
2005-06-09 21:07 ` [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Mark A. Greer
2005-06-09 19:29 ` [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip Jean Delvare
2005-06-09 21:30 ` [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas Jean Delvare
2005-06-09 18:21 ` [lm-sensors] [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip Jean Delvare
2005-06-09 20:21 ` [lm-sensors] [PATCH 1/2] Add support for Maxim/Dallas DS1374 Jean Delvare
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=42A89338.209@mvista.com \
--to=mgreer@mvista.com \
--cc=LM@ozlabs.org \
--cc=khali@linux-fr.org \
--cc=linuxppc-embedded@ozlabs.org \
--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.