Re: [i2c] MAX1236 with smbus (CS5536 ACB0)
Hi Andreas, On Mon, 13 Oct 2008 03:20:48 +0200, Andreas Seidler wrote: I want to connect a MAX1236 (ADC) [1] to a I2C/SMBus in a PC-Engines/ALIX board to monitor some voltages. This board have a AMD geode CPU with an an I2C companion (scx200_acb.c). Installed I2C busses: i2c-0 smbus CS5536 ACB0 [EMAIL PROTECTED]:/# i2cdetect -F 0 Functionalities implemented by /dev/i2c-0: I2C no SMBus Quick Command yes SMBus Send Byte yes SMBus Receive Byte yes SMBus Write Byte yes SMBus Read Byte yes SMBus Write Word yes SMBus Read Word yes SMBus Process Call no SMBus Block Writeno SMBus Block Read no SMBus Block Process Call no SMBus PECno I2C Block Write yes I2C Block Read yes [EMAIL PROTECTED]:/# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- 4c -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- but i cant access the MAX1236 on slave address 0x34. (0x4c is the onbard LM90) Maybe it's not wired properly? If it is wired properly, then another possibility is that the MAX1236 is doing clock stretching beyond what the CS5536 supports... Does I2C no means the CS5536 is a plain smbus without i2c support? Yes and no. It means that the scx200_acb driver runs the CS5536 in SMBus mode without plain I2C support. But there is also the scx200_i2c driver (which I would love to see go away in favor of i2c-gpio but that's another story) which can use the same pins as GPIO to do plain I2C. If I read the MAX1236 datasheet properly, it uses transactions which aren't part of the SMBus set, so you may need to use the scx200_i2c driver, depending on what exactly you need to do with the MAX1236. There are still a few SMBus transactions which should work though, and that may be enough. -- Jean Delvare ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[SPAM:24.6] [i2c] 地元のオバサンを抱きたいですか？レベ ルは低いですが確実に抱けますよ!!
・・・‥‥……━━━……‥‥・・・ 肉体関係専門コミュニティー!今すぐ地元のホテルへ直行確実!! ・・・‥‥……━━━……‥‥・・・ ↓ ..__.. ／全国版40歳以上専用＼ ━─━─━─━─━─━─━─━─━─━─━─━─━─ 当サイトは40代〜50代の肉体関係を求めている人妻・熟女 が集まる日本最大の肉体関係コミュニティーサイトです。 ━─━─━─━─━─━─━─━─━─━─━─━─━─ 《ご利用に関してのご注意》 ① ご利用は男女共に40歳以上の方のみとさせて頂きます。 ② 男女共にお相手に要求する事は肉体関係のみです。 ③ ホテル代に関してはお互いで決めて下さい。 ━─━─━─━─━─━─━─━─━─━─━─━─━─ 《ご利用方法について》 ① ご希望の地域・メールアドレス・パスワードを 設定して頂きます。 ② 次に簡単な自己PRを設定して頂きます。 ③ 肉体関係を希望するお相手を検索して頂きます。 ④ ご利用されている人妻・熟女さんは全て自己PR内に 携帯番号又は直アドレスが表示されておりますので その時点で直接ご連絡をして頂いても結構ですし、 サイト内からメールにて連絡を取る事も可能ですの でお好きな連絡方法で交渉して下さい。 【注意】自己PR内に連絡先の表示が無い人妻・熟女さんは 交渉が成立し肉体関係中ですので連絡先の表示が 復活後、再度交渉をお願い致します。 ━─━─━─━─━─━─━─━─━─━─━─━─━─ ●本日、地元のオバサンと肉体関係を希望される男性は http://wewste.com/118/1447 ●本日、火照った体を満たして欲しいオバサンは http://wewste.com/118/1447 ━─━─━─━─━─━─━─━─━─━─━─━─━─ ★待合わせの場所をリアルタイムでやり取り確認されたい 方はモバイル（携帯電話）での設定をオススメ致します。 ━─━─━─━─━─━─━─━─━─━─━─━─━─ ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 2.6.26.5] rtc-ds1307 : SMBus compatibility
-Original Message- From: David Brownell [mailto:[EMAIL PROTECTED] ... At a quick glance, this looks like a sane conversion ... unlike the last one proposed, which I had to NAK since it broke driver functionality by trying to replace block transfers with non-equivalent byte-at-a-time ones. (Clock updates between bytes, boom!) Sorry, I don't understand what you talk about. The i2c_smbus_read_i2c_block_data function do block transfer not byte-at-a-time one. Doesn't it ? -- Sébastien Barré Bureau d'étude - Développement SDEL Contrôle Commande D2A - Rue Nungesser et Coli 44860 Saint Aignan de Grand Lieu FRANCE Tél : +33(0)2 40 84 50 88 Fax : +33(0)2 40 84 51 10 ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] MAX1236 with smbus (CS5536 ACB0)
[EMAIL PROTECTED]:/# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- 4c -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
but i cant access the MAX1236 on slave address 0x34.
(0x4c is the onbard LM90)
Maybe it's not wired properly?
If it is wired properly, then another possibility is that the MAX1236
is doing clock stretching beyond what the CS5536 supports...
Does I2C no means the CS5536 is a plain smbus without i2c support?
Yes and no. It means that the scx200_acb driver runs the CS5536 in
SMBus mode without plain I2C support. But there is also the scx200_i2c
driver (which I would love to see go away in favor of i2c-gpio but
that's another story) which can use the same pins as GPIO to do plain
I2C. If I read the MAX1236 datasheet properly, it uses transactions
which aren't part of the SMBus set, so you may need to use the
scx200_i2c driver, depending on what exactly you need to do with the
MAX1236. There are still a few SMBus transactions which should work
though, and that may be enough.
Hi,
A driver that should work with this chip is part of the
iio subsystem, so I have a fair bit of familiarity (though
only via 1238 rather than this exact model)
Done a bit of digging around and my original test code was
#include fcntl.h
#include i2c-dev.h
int main(int argc, char* argv[])
{
struct i2c_smbus_ioctl_data arg;
union i2c_smbus_data data;
int adaptor_nr=atoi(argv[1]); //check this
char filename[20];
sprintf(filename,/dev/i2c-%d,adaptor_nr);
int file;
if((file = open(filename, O_RDWR))0)
{
printf(could not open /dev/i2c-%u\n, adaptor_nr);
exit(-1);
}
if(ioctl(file,I2C_SLAVE, 0x34) 0)
{
printf(could not set slave address \n);
return -1;
}
arg.size = I2C_SMBUS_BYTE;
arg.read_write = I2C_SMBUS_WRITE;
arg.command = I2C_SMBUS_BYTE;
data.byte = 8;
arg.data = data;
char buf[2] = {0x79, 0x92};
write(file, buf,2);
int i;
for(i = 0; i 20; i++)
{
read(file,buf,2);
unsigned int a =0;
a = (buf[0] 0xF) 8 | buf[1] ;
printf(reading %u\n,a);
sleep(1);
}
}
No idea why I did it without using the smbus_write commands
though. The iio driver is i2c_transfers I'm afraid.
as for i2c detect, I've just blugeoned it into building for
the pxa271 board I'm using and it picks up a max1239 just fine.
Good luck!
Jonathan
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 2.6.26.5] rtc-ds1307 : SMBus compatibility
Hi Sebastien,
On Fri, 10 Oct 2008 15:46:11 +0200, BARRE Sebastien wrote:
Thanks for your advices.
Fixed patch is in attachement to avoid tabs replacement.
Other comments are welcome.
Note: you need to include a comment describing what your patch does, as
well as your Signed-off-by line. Here's a second review from me. After
that it will be up to Alessandro and the RTC folks.
--- a/drivers/rtc/rtc-ds1307.c2008-09-08 19:40:20.0 +0200
+++ b/drivers/rtc/rtc-ds1307.c2008-10-10 16:30:59.0 +0200
@@ -17,8 +17,6 @@
#include linux/rtc.h
#include linux/bcd.h
-
-
Unrelated white space change, please revert.
/* We can't determine type by probing, but if we expect pre-Linux code
* to have set the chip up as a clock (turning on the oscillator and
* setting the date and time), Linux can ignore the non-clock features.
@@ -38,7 +36,6 @@ enum ds_type {
// rs5c372 too? different address...
};
-
Unrelated white space change, please revert.
/* RTC registers don't differ much, except for the century flag */
#define DS1307_REG_SECS 0x00/* 00-59 */
#define DS1307_BIT_CH0x80
@@ -85,14 +82,11 @@ enum ds_type {
#define DS1337_BIT_A1I 0x01
#define DS1339_REG_TRICKLE 0x10
-
-
Unrelated white space change, please revert.
struct ds1307 {
u8 reg_addr;
reg_addr is unused after your changes, so you should remove it as well.
boolhas_nvram;
u8 regs[8];
enum ds_typetype;
- struct i2c_msg msg[2];
struct i2c_client *client;
struct i2c_client dev;
struct rtc_device *rtc;
@@ -138,12 +132,9 @@ static int ds1307_get_time(struct device
int tmp;
/* read the RTC date and time registers all at once */
- ds1307-msg[1].flags = I2C_M_RD;
- ds1307-msg[1].len = 7;
-
- tmp = i2c_transfer(to_i2c_adapter(ds1307-client-dev.parent),
- ds1307-msg, 2);
- if (tmp != 2) {
+ tmp = i2c_smbus_read_i2c_block_data(ds1307-client,
+ DS1307_REG_SECS, 7, ds1307-regs);
+ if (tmp != 7) {
dev_err(dev, %s error %d\n, read, tmp);
return -EIO;
}
@@ -181,8 +172,6 @@ static int ds1307_set_time(struct device
{
struct ds1307 *ds1307 = dev_get_drvdata(dev);
int result;
- int tmp;
- u8 *buf = ds1307-regs;
dev_dbg(dev, %s secs=%d, mins=%d,
hours=%d, mday=%d, mon=%d, year=%d, wday=%d\n,
@@ -190,44 +179,41 @@ static int ds1307_set_time(struct device
t-tm_hour, t-tm_mday,
t-tm_mon, t-tm_year, t-tm_wday);
- *buf++ = 0; /* first register addr */
- buf[DS1307_REG_SECS] = BIN2BCD(t-tm_sec);
- buf[DS1307_REG_MIN] = BIN2BCD(t-tm_min);
- buf[DS1307_REG_HOUR] = BIN2BCD(t-tm_hour);
- buf[DS1307_REG_WDAY] = BIN2BCD(t-tm_wday + 1);
- buf[DS1307_REG_MDAY] = BIN2BCD(t-tm_mday);
- buf[DS1307_REG_MONTH] = BIN2BCD(t-tm_mon + 1);
+ ds1307-regs[DS1307_REG_SECS] = BIN2BCD(t-tm_sec);
+ ds1307-regs[DS1307_REG_MIN] = BIN2BCD(t-tm_min);
+ ds1307-regs[DS1307_REG_HOUR] = BIN2BCD(t-tm_hour);
+ ds1307-regs[DS1307_REG_WDAY] = BIN2BCD(t-tm_wday + 1);
+ ds1307-regs[DS1307_REG_MDAY] = BIN2BCD(t-tm_mday);
+ ds1307-regs[DS1307_REG_MONTH] = BIN2BCD(t-tm_mon + 1);
This change makes the patch larger (and thus harder to review) with
almost no benefit. Same for many changes below... Why don't you keep
the buf pointer? Please keep in mind that your patch should do just one
thing and do it well.
/* assume 20YY not 19YY */
- tmp = t-tm_year - 100;
- buf[DS1307_REG_YEAR] = BIN2BCD(tmp);
+ ds1307-regs[DS1307_REG_YEAR] = BIN2BCD(t-tm_year - 100);
switch (ds1307-type) {
case ds_1337:
case ds_1339:
- buf[DS1307_REG_MONTH] |= DS1337_BIT_CENTURY;
+ ds1307-regs[DS1307_REG_MONTH] |= DS1337_BIT_CENTURY;
break;
case ds_1340:
- buf[DS1307_REG_HOUR] |= DS1340_BIT_CENTURY_EN
- | DS1340_BIT_CENTURY;
+ ds1307-regs[DS1307_REG_HOUR] |= DS1340_BIT_CENTURY_EN
+ | DS1340_BIT_CENTURY;
break;
default:
break;
}
- ds1307-msg[1].flags = 0;
- ds1307-msg[1].len = 8;
-
dev_dbg(dev, %s: %02x %02x %02x %02x %02x %02x %02x\n,
- write, buf[0], buf[1], buf[2], buf[3],
- buf[4], buf[5], buf[6]);
-
- result = i2c_transfer(to_i2c_adapter(ds1307-client-dev.parent),
- ds1307-msg[1], 1);
- if (result != 1) {
- dev_err(dev, %s error %d\n, write, tmp);
- return -EIO;
+ write,
