Ok, I'll call you soon. ---------- Sent from my Nokia phone ------Original message------ From: <lm-sensors-request@xxxxxxxxxxxxxx> To: <lm-sensors@xxxxxxxxxxxxxx> Date: Saturday, March 24, 2012 12:00:02 PM GMT+0100 Subject: lm-sensors Digest, Vol 83, Issue 59 Send lm-sensors mailing list submissions to lm-sensors@xxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://lists.lm-sensors.org/mailman/listinfo/lm-sensors or, via email, send a message with subject or body 'help' to lm-sensors-request@xxxxxxxxxxxxxx You can reach the person managing the list at lm-sensors-owner@xxxxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of lm-sensors digest..." Today's Topics: 1. Re: [PATCH] hwmon: (it87) Add support for IT8781F, IT8782F, IT8783E/F (Jean Delvare) 2. [SPAM:4.2] Billboard Advert (Talent Management UK) 3. Re: bus names and multiple adapters of the same kind (Jean Delvare) ---------------------------------------------------------------------- Message: 1 Date: Sat, 24 Mar 2012 09:37:44 +0100 From: Jean Delvare <khali@xxxxxxxxxxxx> To: Guenter Roeck <guenter.roeck@xxxxxxxxxxxx> Cc: lm-sensors@xxxxxxxxxxxxxx, Kevin Folz <kfolz@xxxxxxxxxx>, Guenter Roeck <linux@xxxxxxxxxxxx>, Jukka Hynninen <jukka.hynninen@xxxxxxxxxxx> Subject: Re: [PATCH] hwmon: (it87) Add support for IT8781F, IT8782F, IT8783E/F Message-ID: <20120324093744.49cb5983@endymion.delvare> Content-Type: text/plain; charset=US-ASCII On Fri, 23 Mar 2012 21:18:32 -0700, Guenter Roeck wrote: > On Fri, Mar 23, 2012 at 05:17:40PM -0400, Jean Delvare wrote: > > On Wed, 7 Mar 2012 20:25:39 -0800, Guenter Roeck wrote: > > > else > > > return val * 12; > > > - } else > > > - return val * 16; > > > + } else { > > > + if (data->in_scaled & (1 << nr)) > > > + return val * 32; > > > + else > > > + return val * 16; > > > + } > > > } > > > > I think both functions can then be rewritten more efficiently. I'll do > > some testing and send a patch later. > > I know, I was a bit lazy ;). > > How about the following ? > > static int adc_lsb(const struct it87_data *data) > { > int lsb = has_12mv_adc(data) ? 12 : 16; > if (data->in_scaled & (1 << nr)) > lsb <<= 1; > return lsb; > } > > and: > val = DIV_ROUND_CLOSEST(val, adc_lsb(data)); > > and: > return val * adc_lsb(data); Except that you have to pass nr around as a parameter, but otherwise yes, that's what I had in mind. > > > + /* Check if fan3 is there or not */ > > > + if ((reg27 & (1 << 0)) || !(reg2C & (1 << 2))) > > > + sio_data->skip_fan |= (1 << 2); > > > > I'm a bit skeptical how a single pin can be FAN_TAC3 and SIN6 at the > > same time... > > Issue here is that the pin is also multiplexed to VIN5 (see below), and it is > kind of difficult to determine how GP30, VIN5, FAN_TAC3, and SIN6 are selected > with only two configuration bits (one of which selects GP30). Maybe there is > another configuration bit somewhere, but I did not find it. Neither did I. I think the datasheet is incomplete. > > > (...) > > > @@ -1867,6 +1939,11 @@ static int __devinit it87_probe(struct platform_device *pdev) > > > data->in_scaled |= (1 << 7); /* in7 is VSB */ > > > if (sio_data->internal & (1 << 2)) > > > data->in_scaled |= (1 << 8); /* in8 is Vbat */ > > > + } else if (sio_data->type == it8783) { > > > + if (sio_data->internal & (1 << 0)) > > > + data->in_scaled |= (1 << 3); /* in3 is VCC5V */ > > > + if (sio_data->internal & (1 << 1)) > > > + data->in_scaled |= (1 << 7); /* in7 is VCCH5V */ > > > > The "Features" page says that Vbat is measured internally. If this > > true, then it is necessarily always scaled too. This should let you > > merge both blocks. > > The IT8783F has a 16mv ADV which measures up to 4V, so scaling VBAT is not necessary. > I think the sensors output confirms that it is not scaled, unless I am missing something. Oh, you're completely right, I had forgotten about the different LSB value, sorry. -- Jean Delvare ------------------------------ Message: 2 Date: Sat, 24 Mar 2012 09:42:16 +0100 From: Talent Management UK <info@xxxxxxxxxxxxxxxxxxxxxx> To: lm-sensors@xxxxxxxxxxxxxx Subject: [SPAM:4.2] Billboard Advert Message-ID: <93e22d519355e16c79a7100905dfdd51@xxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="iso-8859-1" Hello , Am Chris Emmanuel, I represent Talent Management here in London , your profile picture is needed for Commercial bill-board advertisement at 2012 London Olympics Games for a prize reward. For further information please reply us back Chris ------------------------------ Message: 3 Date: Sat, 24 Mar 2012 10:26:55 +0100 From: Jean Delvare <khali@xxxxxxxxxxxx> To: "Michael Walle" <michael@xxxxxxxx> Cc: lm-sensors@xxxxxxxxxxxxxx Subject: Re: bus names and multiple adapters of the same kind Message-ID: <20120324102655.20b062cd@endymion.delvare> Content-Type: text/plain; charset=US-ASCII Hi Michael, On Sat, 24 Mar 2012 01:03:34 +0100, Michael Walle wrote: > the busses for the chip statements seems to be compared by their names. Eg. i > do have two I2C busses, both uses the same driver. A sensors --bus-list give > me: > > bus "i2c-0" "IBM IIC" > bus "i2c-1" "IBM IIC" > > If i have two i2c sensors at the same i2c address on these two busses, the > chip statements always match the first one: > > > chip "adt7411-i2c-0-48" > > label in0 "Test" > > chip "adt7411-i2c-1-48" > > label in1 "Foobar" > > > sensors now only replaces the labels of adt7411-i2c-0-48, but for both in0 and > in1. Eg: > > # sensors > adt7411-i2c-0-48 > Adapter: IBM IIC > Test: +3.33 V > Foobar: +0.31 V > in2: +0.00 V > [..] > > adt7411-i2c-1-48 > Adapter: IBM IIC > in0: +3.33 V > in1: +1.92 V > in2: +2.13 V > [..] > > > The manpage states the following > A bus statement binds the description of an I2C or SMBus adapter to a bus > number. This makes it possible to refer to an adapter in the configuration > file, independent of the actual correspondence of bus numbers and actual > adapters (which may change from moment to moment). > > > Unfortunately, this doesn't work if there are two adapters with the same name > as on most SoCs :( This is an I2C bus driver bug, they shouldn't use the exact same name for two adapters. Usually good drivers include something specific in each bus name, either an address or an ID. For example I have: # i2cdetect -l i2c-0 i2c Radeon i2c bit bus 0x90 I2C adapter i2c-1 i2c Radeon i2c bit bus 0x91 I2C adapter i2c-2 i2c Radeon i2c bit bus 0x92 I2C adapter i2c-3 i2c Radeon i2c bit bus 0x93 I2C adapter i2c-4 i2c Radeon i2c bit bus 0x94 I2C adapter i2c-5 i2c Radeon i2c bit bus 0x95 I2C adapter i2c-6 i2c Radeon i2c bit bus 0x96 I2C adapter i2c-7 i2c Radeon i2c bit bus 0x97 I2C adapter i2c-8 smbus SMBus I801 adapter at 0400 SMBus adapter i2c-9 i2c Hauppauge Nova-T 500 Dual DVB-T I2C adapter i2c-10 i2c DiBX000 tuner I2C bus I2C adapter i2c-11 i2c DiBX000 master GPIO12 I2C bus I2C adapter i2c-12 i2c DiBX000 master GPIO34 I2C bus I2C adapter i2c-13 i2c DiBX000 master GPIO67 I2C bus I2C adapter i2c-14 i2c DiBX000 tuner I2C bus I2C adapter i2c-15 i2c DiBX000 master GPIO12 I2C bus I2C adapter i2c-16 i2c DiBX000 master GPIO34 I2C bus I2C adapter i2c-17 i2c DiBX000 master GPIO67 I2C bus I2C adapter As you can see the radeon and i2c-i801 drivers are good citizens. The dvb-usb-dib0700 driver is not - not that it matters to lm-sensors. So please report the problem to the upstream maintainer of your i2c bus driver (i2c-ibm_iic.) I'd help but this is an open-firmware-based driver and I am not familiar with these, sorry. -- Jean Delvare ------------------------------ _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors End of lm-sensors Digest, Vol 83, Issue 59 ****************************************** _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
