date:20080715

Hi Jean,

 You probably want to use i2c_smbus_write_i2c_block_data instead. With
 i2c_smbus_write_block_data, the first data byte isn't real data,
 instead in indicates how many bytes follow until the end of the block.
 It should result in 5D W 11 33 44 in your case though, not sure why
 you get 5D W 11 03 33 instead.

i'm aware of the length field and i2c_smbus_write_i2c_block_data doesn't work, 
too. Now i get: 5D W 11 44

unsigned char values[3];
int reg = 0x11;
values[0] = 0x33;
values[1] = 0x44;
i2c_smbus_write_i2c_block_data(fd, reg, 2, values);

If i change the third parameter (length) to 1 I get the 0x33.

I've no idea! :-(

Regards,

Nick


  __
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com

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

[i2c] i2c_smbus_write_block_data does not send all bytes?!

 I don't remember any similar problem, so no idea either. I can only
 suspect that your bus driver is doing something wrong. So please give
 us the detail of your setup:
 
 * Which version of i2c-dev.h are you using?

libi2c-dev, 3.0.0-1 (debian)

 * What architecture are you working on?

i386

 * Which kernel version are you using?

2.6.24.2

 * What i2c bus driver are you using?

i2c_i8019008  0
i2c_dev 8164  0
smsc47m19700  0
smsc47m192 14656  0

 * How do you know for sure what actually goes on the bus?

Milksop GPL Reflasher - 0.20 - (c)2002 [EMAIL PROTECTED]
with CheapI2C


I hope this helps... writing words  bytes works fine.

Regards,

Nick


  __
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com

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

Re: [i2c] [patch 1/1] i2c_gpio: keep probe resident for hotplugged devices.

On Sat, Jul 12, 2008 at 09:06:00AM +0200, Jean Delvare wrote:
 Ben,
 
 On Thu, 10 Jul 2008 14:29:17 +0100, Ben Dooks wrote:
  On Wed, Jul 02, 2008 at 12:44:06PM +0200, Haavard Skinnemoen wrote:
   Ben Dooks [EMAIL PROTECTED] wrote:
Change the i2c_gpio driver to use platform_driver_register()
instead of platform_driver_probe() to ensure that is can
attach to any devices that may be loaded after it has initialised.
   
   Does anyone actually do that?
  
  At the moment our standard kernel configuration only
  builds in the SM501 which will work without this patch
  on.
  
  However, we have clients that do build module kernels
  and I would like to replace i2c-simtec.c with the gpio
  driver and if the relevant module instantiating the gpio
  support is loaded post kernel init, then we will need to
  do this.
 
 Should I take this patch in my i2c tree, or will you take it in yours?

I'll take it, I was just waiting to see if there
where any more objections from Haavard before applying
this.

If i've not received an objection by 0900GMT 2008-07-16
then I will add it to my rather small git tree and ask
linus to pull.

-- 
Ben ([EMAIL PROTECTED], http://www.fluff.org/)

  'a smiley only costs 4 bytes'

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

Re: [i2c] [PATCH 1/1] I2C pxa fast mode (400khz) support

2008-07-15 Thread Russell King - ARM Linux

On Tue, Jul 15, 2008 at 10:43:24AM +0100, Ben Dooks wrote:
 I think most of RMK's pxa tree has been merged, so a diff
 against a current -git release should give you a better
 starting point.

There's still around 300K of PXA stuff outstanding - but unfortunately
I can't update the 'nightly' snapshots with the outstanding commits
because I can't get a reasonable patch out of git:

$ git-diff -u master...pxa |less
diff --cc MAINTAINERS
index 1528e58,8f0ec46,c68a118..20aef95
--- a/MAINTAINERS
+++ b/MAINTAINERS
 -481,11 -475,11 -475,11 +475,28  M:[EMAIL PROTECTED]
   L:   [EMAIL PROTECTED] (subscribers-only)
   S:   Maintained

+++ARM/COMPULAB CM-X270/EM-X270 MACHINE SUPPORT
+++P:   Mike Rapoport
+++M:   [EMAIL PROTECTED]
+++L:   [EMAIL PROTECTED] (subscribers-only)
+++S:   Maintained
+++

This is basically because 'master...pxa' has multiple common ancestors.

You can get a diff from 'master..pxa' but that will be a patch which
removes changes in master but not pxa, and applies changes in pxa but
not master, which isn't useful.

Of course, those with git can get the full tree and there isn't a
problem moving through the history... those using the patches, however,
are going to be facing a problem for the time being.

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

Re: [i2c] [PATCH 1/1] I2C pxa fast mode (400khz) support

2008-07-15 Thread Russell King - ARM Linux

On Tue, Jul 15, 2008 at 12:37:25PM +0200, Uwe Kleine-König wrote:
 Hm, I don't see that with your current tree:
 
   [EMAIL PROTECTED]:~/gsrc/linux-2.6$ git merge-base --all rmk/pxa 
 rmk/master
   543cf4cb3fe6f6cae3651ba918b9c56200b257d0

That's because you're not looking at the right master.  My master branch
is now Linus' tip, but I'm not pushing that update out because my scripts
will also push out the patch and mbox files (which, because of this, for
PXA and devel will be empty.)

I fully understand why this happens, it's just annoying when it does that
we lose the ability to have a nice clean patch.

It'll all resolve itself in the fullness of time (iow, after the SPI tree
has been merged followed by the remainder of the PXA tree.)

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

Re: [i2c] i2c_smbus_write_block_data does not send all bytes?!

On Tue, 15 Jul 2008 08:29:27 + (GMT), Nick Teen wrote:
  I don't remember any similar problem, so no idea either. I can only
  suspect that your bus driver is doing something wrong. So please give
  us the detail of your setup:
  
  * Which version of i2c-dev.h are you using?
 
 libi2c-dev, 3.0.0-1 (debian)
 
  * What architecture are you working on?
 
 i386
 
  * Which kernel version are you using?
 
 2.6.24.2
 
  * What i2c bus driver are you using?
 
 i2c_i8019008  0
 i2c_dev 8164  0

Hmm, did you connect something to a SMBus header on your motherboard?
Or are you talking to an I2C chip on your motherboard?

 smsc47m19700  0

Not related to i2c at all...

 smsc47m192 14656  0

An i2c chip driver, unrelated to your problem.

 
  * How do you know for sure what actually goes on the bus?
 
 Milksop GPL Reflasher - 0.20 - (c)2002 [EMAIL PROTECTED]
 with CheapI2C

Err, what is this exactly? Hardware? Software? Please explain your
setup in details.

 I hope this helps... writing words  bytes works fine.


-- 
Jean Delvare

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

Re: [i2c] [PATCH V9] I2C driver for IMX

On Fri, 11 Jul 2008 09:29:29 +0300, Darius wrote:
 Changes from V8 version:
 
 - Error numbers replaced to standard numbers from errno.h
 - Enable/Start and Disable/Stop functions merged into two Start and Stop 
 functions
 - Removed all unused info about slave mode
 - Removed unused includes
 
 Can somebody review functional part of this I2C driver? Because all
 other part is already acked by ARM Linux kernel guys.
 
 Signed-off-by: Darius Augulis [EMAIL PROTECTED]
 ---

Ben, this is something for you as well.

-- 
Jean Delvare

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

Re: [i2c] i2c_smbus_write_block_data does not send all bytes?!

--- Jean Delvare [EMAIL PROTECTED] wrote:
 If that's all the details you can provide, then you're on your own,
 sorry. I won't spend the whole day extracting every bit of information
 from you.

Sorry for disturbing the peace...  my setup is very simple and I cannot gauge 
whats important and what is unimportant. My idea was to send an I2C command to 
the frontpanel pic to switch on an LED. I've captured the traffic (of the orig. 
OS) and trying to send these commands again under linux. But you see: without 
success.

Thanks for your endeavours! I dont want to steal your time.

Regards,

Nick


  __
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com

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

[i2c] i2c: cdev lock_kernel() pushdown

Hi Jonathan,

I am looking at this patch of yours:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3db633ee352bfe20d4a2b0c3c8a46ce31a6c7149

I believe that no locking is needed in i2cdev_open(). Do you have any
reason to think it does? If not, can I simply revert this patch?

Thanks,
-- 
Jean Delvare

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

[i2c] temperature monitor

2008-07-15 Thread Agile Aspect

Hi - I'm new to lm_sensors and I'm trying to monitor the temperature on
a 8 CPU (Intel Xeon CPU X5460  @ 3.16GHz) running CentOS 4.4
(2.6.9-42.ELsmp.)

The command

i2cdetect -l

returns

i2c-0   dummy   ISA main adapterISA 
bus algorithm

and the command

No sensors found!
   
Enclosed is the output of lspci.

Any ideas on how I get a temperature monitor working?

For instance, is this the right mailing list?

Any help would be greatly appreciated!

;
00:00.0 Host bridge: Intel Corporation 5000X Chipset Memory Controller 
Hub (rev 12)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 
Port 2 (rev 12)
00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 
Port 3 (rev 12)
00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 
Port 4 (rev 12)
00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 
Port 5 (rev 12)
00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 
Port 6-7 (rev 12)
00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 
Port 7 (rev 12)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset Error 
Reporting Registers (rev 12)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset Error 
Reporting Registers (rev 12)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset Error 
Reporting Registers (rev 12)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved 
Registers (rev 12)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved 
Registers (rev 12)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers 
(rev 12)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers 
(rev 12)
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI 
Express Root Port 1 (rev 09)
00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
UHCI USB Controller #1 (rev 09)
00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
UHCI USB Controller #2 (rev 09)
00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
UHCI USB Controller #3 (rev 09)
00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
UHCI USB Controller #4 (rev 09)
00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC 
Interface Controller (rev 09)
00:1f.2 IDE interface: Intel Corporation 631xESB/632xESB/3100 Chipset 
SATA Storage Controller IDE (rev 09)
01:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E 
PCI-Express Fusion-MPT SAS (rev 08)
02:00.0 PCI bridge: Broadcom: Unknown device 0103 (rev c3)
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 
Gigabit Ethernet (rev 12)
04:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express 
Upstream Port (rev 01)
04:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to 
PCI-X Bridge (rev 01)
05:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express 
Downstream Port E1 (rev 01)
05:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express 
Downstream Port E2 (rev 01)
06:00.0 PCI bridge: Broadcom: Unknown device 0103 (rev c3)
07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 
Gigabit Ethernet (rev 12)
0e:0d.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
;

-- 
Article. VI. Clause 3 of the constitution of the United States states: 

The Senators and Representatives before mentioned, and the Members of 
the several State Legislatures, and all executive and judicial Officers, 
both of the United States and of the several States, shall be bound by 
Oath or Affirmation, to support this Constitution; but no religious Test 
shall ever be required as a Qualification to any Office or public Trust 
under the United States. 



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

[i2c] i2c: Documentation: upgrading clients HOWTO

Add a document describing how i2c clients on Linux 2.6 can be
moved from the old to the new driver model.

Signed-off-by: Ben Dooks [EMAIL PROTECTED]

Index: linux-2.6.26-quilt2/Documentation/i2c/upgrading-clients
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux-2.6.26-quilt2/Documentation/i2c/upgrading-clients 2008-07-15 
16:51:11.0 +0100
@@ -0,0 +1,280 @@
+Upgrading I2C Drivers to the new 2.6 Driver Model
+=
+
+Ben Dooks [EMAIL PROTECTED]
+
+Introduction
+
+
+This guide outlines how to alter existing Linux 2.6 client drivers from
+the old to the new new binding methods.
+
+
+Example old-style driver
+
+
+
+struct example_state {
+   struct i2c_client   client;
+   
+};
+
+static struct i2c_driver example_driver;
+
+static unsigned short ignore[] = { I2C_CLIENT_END };
+static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
+
+I2C_CLIENT_INSMOD;
+
+static int example_attach(struct i2c_adapter *adap, int addr, int kind)
+{
+   struct example_state *state;
+   struct device *dev = adap-dev;  /* to use for dev_ reports */
+   int ret;
+
+   state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
+   if (state == NULL) {
+   dev_err(dev, failed to create our state\n);
+   return -ENOMEM;
+   }
+
+   example-client.addr= addr;
+   example-client.flags   = 0;
+   example-client.adapter = adap;
+
+   i2c_set_clientdata(state-i2c_client, state);
+   strlcpy(client-i2c_client.name, example, I2C_NAME_SIZE);
+
+   ret = i2c_attach_client(state-i2c_client);
+   if (ret  0) {
+   dev_err(dev, failed to attach client\n);
+   kfree(state);
+   return ret;
+   }
+
+   dev = state-i2c_client.dev;
+
+   /* rest of the initialisation goes here. */
+
+   dev_info(dev, example client created\n);
+
+   return 0;
+}
+
+static int example_detach(struct i2c_client *client)
+{
+   struct example_state *state = i2c_get_clientdata(client);
+
+   i2c_detach_client(client);
+   kfree(state);
+   return 0;
+}
+
+static int example_attach_adapter(struct i2c_adapter *adap)
+{
+   return i2c_probe(adap, addr_data, example_attach);
+}
+
+static struct i2c_driver example_driver = {
+   .driver = {
+   .owner  = THIS_MODULE,
+   .name   = example,
+   },
+   .attach_adapter = example_attach_adapter,
+   .detach_client  = example_detach,
+   .suspend= example_suspend,
+   .resume = example_resume,
+};
+
+
+Updating the client
+---
+
+The new style binding model will check against a list of supported
+devices and their associated address supplied by the code registering
+the busses. This means that the driver .attach_adapter and
+.detach_adapter methods can be removed, along with the addr_data,
+as follows:
+
+- static struct i2c_driver example_driver;
+
+- static unsigned short ignore[] = { I2C_CLIENT_END };
+- static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
+
+- I2C_CLIENT_INSMOD;
+
+- static int example_attach_adapter(struct i2c_adapter *adap)
+- {
+-  return i2c_probe(adap, addr_data, example_attach);
+- }
+
+ static struct i2c_driver example_driver = {
+-  .attach_adapter = example_attach_adapter,
+-  .detach_client  = example_detach,
+ }
+
+Add the probe and remove methods to the i2c_driver, as so:
+
+ static struct i2c_driver example_driver = {
++  .probe  = example_probe,
++  .remove = example_remove,
+ }
+
+Change the example_attach method to accept the new parameters
+which include the i2c_client that it will be working with:
+
+- static int example_attach(struct i2c_adapter *adap, int addr, int kind)
++ static int example_probe(struct i2c_client *client,
++ const struct i2c_device_id *id)
+
+Change the name of example_attach to example_probe to align it with the
+i2c_driver entry names. The rest of the probe routine will now need to be
+changed as the i2c_client has already been setup for use.
+
+The necessary client fields have already been setup before
+the probe function is called, so the following client setup
+can be removed:
+
+-  example-client.addr= addr;
+-  example-client.flags   = 0;
+-  example-client.adapter = adap;
+-
+-  strlcpy(client-i2c_client.name, example, I2C_NAME_SIZE);
+
+The i2c_set_clientdata is now:
+
+-  i2c_set_clientdata(state-client, state);
++  i2c_set_clientdata(client, state);
+
+The call to i2c_attach_client is no longer needed, if the probe
+routine exits successfully, then the driver will be automatically
+attached by the core. Change the probe routine as so:
+
+-  ret = i2c_attach_client(state-i2c_client);
+-  if (ret  0)

Re: [i2c] temperature monitor

On Tue, 15 Jul 2008 08:43:18 -0700, Agile Aspect wrote:
 Hi - I'm new to lm_sensors and I'm trying to monitor the temperature on
 a 8 CPU (Intel Xeon CPU X5460  @ 3.16GHz) running CentOS 4.4
 (2.6.9-42.ELsmp.)
 
 The command
 
 i2cdetect -l
 
 returns
 
 i2c-0   dummy   ISA main adapterISA 
 bus algorithm
 
 and the command
 
 No sensors found!

 Enclosed is the output of lspci.
 
 Any ideas on how I get a temperature monitor working?
 
 For instance, is this the right mailing list?

No, it's not. Please use instead:
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Thanks,
-- 
Jean Delvare

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

Re: [i2c] i2c: cdev lock_kernel() pushdown

2008-07-15 Thread Jonathan Corbet

Hi, Jean,

 I am looking at this patch of yours:
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3db633ee352bfe20d4a2b0c3c8a46ce31a6c7149
 
 I believe that no locking is needed in i2cdev_open(). Do you have any
 reason to think it does? If not, can I simply revert this patch?

Before now, i2cdev_open() has always had the protection of the BKL.
When I pushed that locking down into the individual open() functions, I
really had to take a pretty conservative approach and assume that the
BKL was needed unless that was really obviously not the case.  In
i2cdev_open(), for example, there's:

i2c_dev = i2c_dev_get_by_minor(minor);

and I really don't know what keeps *i2c_dev from going away during the
rest of the call.  I'm *not* saying there is a problem here; I just
don't know.  So the only thing I could really do is to push the BKL
down and let the maintainers sort it out.

...all of which is my long-winded way of saying that, if you're
convinced that i2cdev_open() is safe in the absence of the BKL, feel
free to take it out.

Thanks,

jon

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

Re: [i2c] i2c: cdev lock_kernel() pushdown

On Tue, 15 Jul 2008 10:14:06 -0600, Jonathan Corbet wrote:
 Hi, Jean,
 
  I am looking at this patch of yours:
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3db633ee352bfe20d4a2b0c3c8a46ce31a6c7149
  
  I believe that no locking is needed in i2cdev_open(). Do you have any
  reason to think it does? If not, can I simply revert this patch?
 
 Before now, i2cdev_open() has always had the protection of the BKL.
 When I pushed that locking down into the individual open() functions, I
 really had to take a pretty conservative approach and assume that the
 BKL was needed unless that was really obviously not the case.  In
 i2cdev_open(), for example, there's:
 
   i2c_dev = i2c_dev_get_by_minor(minor);
 
 and I really don't know what keeps *i2c_dev from going away during the
 rest of the call.  I'm *not* saying there is a problem here; I just
 don't know.  So the only thing I could really do is to push the BKL
 down and let the maintainers sort it out.
 
 ...all of which is my long-winded way of saying that, if you're
 convinced that i2cdev_open() is safe in the absence of the BKL, feel
 free to take it out.

Good point. i2c_dev is guaranteed to stay thanks to the call to
i2c_get_adapter(), however it happens _after_ the call to
i2c_dev_get_by_minor(), so without additional locking, this is racy.
That being said, I'm not sure how lock_kernel() is supposed to help. Is
the BKL held when i2cdev_detach_adapter() is called? If not, then I
suspect that the current code is already racy.

I'll look into this, thanks for the hint.

-- 
Jean Delvare

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

Re: [i2c] [PATCH V9] I2C driver for IMX

On Fri, Jul 11, 2008 at 09:29:29AM +0300, Darius wrote:
 Changes from V8 version:

 - Error numbers replaced to standard numbers from errno.h
 - Enable/Start and Disable/Stop functions merged into two Start and Stop 
 functions
 - Removed all unused info about slave mode
 - Removed unused includes

 Can somebody review functional part of this I2C driver? Because all other 
 part is already acked by ARM Linux kernel guys.

 Signed-off-by: Darius Augulis [EMAIL PROTECTED]
 ---

I'll need a reasonable header/description in place of the
changelog before this can be merged.

 Index: linux-2.6.26-rc9/arch/arm/mach-imx/mx1ads.c
 ===
 --- linux-2.6.26-rc9.orig/arch/arm/mach-imx/mx1ads.c
 +++ linux-2.6.26-rc9/arch/arm/mach-imx/mx1ads.c
 @@ -109,10 +109,31 @@ static struct platform_device imx_uart2_
   }
  };
  
 +static struct resource imx_i2c_resources[] = {
 + [0] = {
 + .start  = 0x00217000,
 + .end= 0x00217010,
 + .flags  = IORESOURCE_MEM,
 + },
 + [1] = {
 + .start  = I2C_INT,
 + .end= I2C_INT,
 + .flags  = IORESOURCE_IRQ,
 + },
 +};
 +
 +static struct platform_device imx_i2c_device = {
 + .name   = imx-i2c,
 + .id = 0,
 + .resource   = imx_i2c_resources,
 + .num_resources  = ARRAY_SIZE(imx_i2c_resources),
 +};
 +
  static struct platform_device *devices[] __initdata = {
   cs89x0_device,
   imx_uart1_device,
   imx_uart2_device,
 + imx_i2c_device,
  };
  
  #ifdef CONFIG_MMC_IMX

I'm not going to step on RMK's toes unless he gives me explicit
acknowledgement to merge arch/arm/mach-imx/mx1ads.c 

 Index: linux-2.6.26-rc9/drivers/i2c/busses/i2c-imx.c
 ===
 --- /dev/null
 +++ linux-2.6.26-rc9/drivers/i2c/busses/i2c-imx.c
 @@ -0,0 +1,602 @@
 +/*
 + *   Copyright (C) 2002 Motorola GSG-China
 + *
 + *   This program is free software; you can redistribute it and/or
 + *   modify it under the terms of the GNU General Public License
 + *   as published by the Free Software Foundation; either version 2
 + *   of the License, or (at your option) any later version.
 + *
 + *   This program is distributed in the hope that it will be useful,
 + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
 + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + *   GNU General Public License for more details.
 + *
 + *   You should have received a copy of the GNU General Public License
 + *   along with this program; if not, write to the Free Software
 + *   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307,
 + *   USA.
 + *
 + * Author:
 + *   Darius Augulis, Teltonika Inc.
 + *
 + * Desc.:
 + *   Implementation of I2C Adapter/Algorithm Driver
 + *   Driver for I2C Bus integrated in i.MXL, i.MX1
 + *
 + *   module parameters:
 + *   - clkfreq:
 + *   Sets the desired clock rate
 + *   The default value is 10
 + *   Max value is 40
 + *
 + *   Derived from Motorola GSG China I2C example driver
 + *
 + *   Copyright (C) 2005 Torsten Koschorrek koschorrek at synertronixx.de
 + *   Portions:
 + *   Copyright (C) 2005 Matthias Blaschke blaschke at synertronixx.de
 + *   Copyright (C) 2007 RightHand Technologies, Inc. 
 adyeratrighthandtech.com
 + *   Copyright (C) 2008 Darius Augulis darius.augulis at teltonika.lt
 + *
 + */
 +
 +/** Includes 
 ***
 +***/
 +
 +#include linux/init.h
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/errno.h
 +#include linux/interrupt.h
 +#include linux/delay.h
 +#include linux/i2c.h
 +#include linux/io.h
 +#include linux/platform_device.h
 +#include asm/arch/irqs.h
 +#include asm/arch/hardware.h
 +#include asm/arch/imx-regs.h
 +
 +/** Defines 
 
 +***/
 +
 +/* This will be the driver name the kernel reports */
 +#define DRIVER_NAME imx-i2c
 +
 +/* Default values of module parameters */
 +#define IMX_I2C_BIT_RATE 10  /* 100kHz */
 +
 +/* Timeouts */
 +#define I2C_IMX_TIME_BUSY2000/* loop count */
 +#define I2C_IMX_TIME_ACK 2000/* loop count */
 +#define I2C_IMX_TIME_TRX 5   /* seconds */
 +
 +/* IMX I2C registers */
 +#define IMX_I2C_IADR 0x00/* i2c slave address */
 +#define IMX_I2C_IFDR 0x04/* i2c frequency divider */
 +#define IMX_I2C_I2CR 0x08/* i2c control */
 +#define IMX_I2C_I2SR 0x0C/* i2c status */
 +#define IMX_I2C_I2DR 0x10/* i2c transfer data */
 +
 +/* Bits of IMX I2C registers */
 +#define I2SR_RXAK0x01
 +#define I2SR_IIF 0x02
 +#define I2SR_SRW

Re: [i2c] [PATCH V9] I2C driver for IMX

On Tue, Jul 15, 2008 at 01:52:31PM +0200, Jean Delvare wrote:
 On Fri, 11 Jul 2008 09:29:29 +0300, Darius wrote:
  Changes from V8 version:
  
  - Error numbers replaced to standard numbers from errno.h
  - Enable/Start and Disable/Stop functions merged into two Start and Stop 
  functions
  - Removed all unused info about slave mode
  - Removed unused includes
  
  Can somebody review functional part of this I2C driver? Because all
  other part is already acked by ARM Linux kernel guys.
  
  Signed-off-by: Darius Augulis [EMAIL PROTECTED]
  ---
 
 Ben, this is something for you as well.

sorry, was away for long-weekend, just sorted out a quick
review.

-- 
Ben ([EMAIL PROTECTED], http://www.fluff.org/)

  'a smiley only costs 4 bytes'

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

Re: [i2c] i2c_smbus_write_block_data does not send all bytes?!

Hi Nick,

Please keep the i2c list in Cc.

On Tue, 15 Jul 2008 16:24:21 + (GMT), Nick Teen wrote:
 --- Jean Delvare [EMAIL PROTECTED] wrote:
 
  I2C bus, but you never clearly said what I2C bus it was! I
  suspect a bus driver bug, but at this point I simply have no idea
  which driver that would be. You mentioned the i2c-i801 driver, but I
  would be very surprised to see a PIC connected on that bus, unless you
  soldered it yourself.
 
 Okay, I will try to tell about the iptv box. The name is ip1101 and 
 manufactured by thomson. It is a common set-top box for internet television 
 and comes with WinCE. If you open the box you can see a intel854 mainboard 
 and a celeron-m 600mhz. In other words it is a personal computer... but it 
 has a frontpanel. You can see it in the picture:
 
 http://blog.pregos.info/wp-content/uploads/2008/03/thomsonip1101.jpg
 
 Under WinCE i can sniff (via milk) on the I2C bus every button
 press and the commands to switch on/off the leds (i think so). The
 frontpanel has a PIC which talks I2C and is connected to one of
 the SMSC-chips. If I disconnect the frontpanel-cable the address
 0x5d disappear (i2cdetect).

Which bus do you see the device on in i2cdetect? You said earlier that
you were using the i2c-i801 driver, which is expected for an Intel
motherboard. However you say that the PIC is connected to an SMSC chip,
and not the Intel south bridge? Are you sure? If you are, what is the
name of the SMSC chip in question?

Which i2c bus are you running your program on? The SMBus I801 one?

Note that it is not entirely impossible that the block write support in
the i2c-i801 driver is broken. This is a driver which is mostly used to
access SPD EEPROMs and hardware monitoring chips, to which you never
write blocks.

 I can provide shell-access to the box if it helps.

Thanks, but no thanks. I may try to help you but I'm not going to do
all the work for you ;)

-- 
Jean Delvare

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

Re: [i2c] i2c: cdev lock_kernel() pushdown

2008-07-15 Thread Jonathan Corbet

On Tue, 15 Jul 2008 18:35:52 +0200
Jean Delvare [EMAIL PROTECTED] wrote:

 Good point. i2c_dev is guaranteed to stay thanks to the call to
 i2c_get_adapter(), however it happens _after_ the call to
 i2c_dev_get_by_minor(), so without additional locking, this is racy.
 That being said, I'm not sure how lock_kernel() is supposed to help.
 Is the BKL held when i2cdev_detach_adapter() is called? If not, then I
 suspect that the current code is already racy.

A quick look suggests that there will be no BKL protection for
i2cdev_detach_adapter().  So, yes, I think it doesn't help here.  

jon

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

Re: [i2c] i2c: cdev lock_kernel() pushdown

2008-07-15 Thread Jon Smirl

On 7/15/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Tue, 15 Jul 2008 10:14:06 -0600, Jonathan Corbet wrote:
Hi, Jean,

I am looking at this patch of yours:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3db633ee352bfe20d4a2b0c3c8a46ce31a6c7149

I believe that no locking is needed in i2cdev_open(). Do you have any
reason to think it does? If not, can I simply revert this patch?

Before now, i2cdev_open() has always had the protection of the BKL.
When I pushed that locking down into the individual open() functions, I
really had to take a pretty conservative approach and assume that the
BKL was needed unless that was really obviously not the case. In
i2cdev_open(), for example, there's:

i2c_dev = i2c_dev_get_by_minor(minor);

and I really don't know what keeps *i2c_dev from going away during the
rest of the call. I'm *not* saying there is a problem here; I just
don't know. So the only thing I could really do is to push the BKL
down and let the maintainers sort it out.

...all of which is my long-winded way of saying that, if you're
convinced that i2cdev_open() is safe in the absence of the BKL, feel
free to take it out.

Good point. i2c_dev is guaranteed to stay thanks to the call to
i2c_get_adapter(), however it happens _after_ the call to
i2c_dev_get_by_minor(), so without additional locking, this is racy.
That being said, I'm not sure how lock_kernel() is supposed to help. Is
the BKL held when i2cdev_detach_adapter() is called? If not, then I
suspect that the current code is already racy.

I'll look into this, thanks for the hint.

Is i2c-dev vulnerable to the i2c device disappearing, for example
rmmod it? Would combining i2c-dev into i2c core and integrating it
with the core's lock protection make things easier to lock? You could
make a compile time option to remove it for small systems. If it's in
the core is attach/detach adapter still needed? I haven't looked at
any of this in detail, but i2c-dev is only 6K of code. Half of the 6K
might disappear if integrated into the core.

What happens if user space and an in-kernel user both try using the
device? I've never tried doing that. Should the presence of an
in-kernel user make the user space device disappear?

--
Jon Smirl
[EMAIL PROTECTED]

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

Re: [i2c] i2c_smbus_write_block_data does not send all bytes?!

--- Jean Delvare [EMAIL PROTECTED] wrote: 
 Which bus do you see the device on in i2cdetect? You said
 earlier that you were using the i2c-i801 driver, which is expected for
 an Intel motherboard. However you say that the PIC is connected to
 an SMSC chip, and not the Intel south bridge? Are you sure? If you are,
 what is the name of the SMSC chip in question?

Okay, i was wrong. The smsc47m192 _and_ the PIC is connected to the SMBus I801 
(at a040). If i type sensors, i get sensor data from 0x2d. 

 Which i2c bus are you running your program on? The
 SMBus I801 one?

I'm afraid so.
 
 Note that it is not entirely impossible that the block
 write support in the i2c-i801 driver is broken. This is a driver which is
 mostly used to access SPD EEPROMs and hardware monitoring chips, to which
 you never write blocks.

Okay... so i've no chance to send the PIC block data. :'-(

Thanks a lot! I give up. ;-)

Nick


  __
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com

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

Re: [i2c] i2c: cdev lock_kernel() pushdown

On Tue, Jul 15, 2008 at 01:01:07PM -0400, Jon Smirl wrote:
On 7/15/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Tue, 15 Jul 2008 10:14:06 -0600, Jonathan Corbet wrote:
Hi, Jean,

I am looking at this patch of yours:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3db633ee352bfe20d4a2b0c3c8a46ce31a6c7149

I believe that no locking is needed in i2cdev_open(). Do you have any
reason to think it does? If not, can I simply revert this patch?

i2c_dev = i2c_dev_get_by_minor(minor);

...all of which is my long-winded way of saying that, if you're
convinced that i2cdev_open() is safe in the absence of the BKL, feel
free to take it out.

I'll look into this, thanks for the hint.

The i2c-dev code calls i2c_get_adapter() op open, so as long as the
device stays open the adapter should not be able to go away as
i2c_get_adater() calls try_module_get() on the adapter's module.

The i2c-dev has it's own THIS_MODULE in the fops field, so should
be kept as long as there is a file open.

What happens if user space and an in-kernel user both try using the
device? I've never tried doing that. Should the presence of an
in-kernel user make the user space device disappear?

--
Jon Smirl
[EMAIL PROTECTED]

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

--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)

'a smiley only costs 4 bytes'

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

Re: [i2c] i2c: cdev lock_kernel() pushdown

Hi Jon,

On Tue, 15 Jul 2008 13:01:07 -0400, Jon Smirl wrote:
On 7/15/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Tue, 15 Jul 2008 10:14:06 -0600, Jonathan Corbet wrote:
Hi, Jean,

I am looking at this patch of yours:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3db633ee352bfe20d4a2b0c3c8a46ce31a6c7149

I believe that no locking is needed in i2cdev_open(). Do you have any
reason to think it does? If not, can I simply revert this patch?

i2c_dev = i2c_dev_get_by_minor(minor);

...all of which is my long-winded way of saying that, if you're
convinced that i2cdev_open() is safe in the absence of the BKL, feel
free to take it out.

I'll look into this, thanks for the hint.

Is i2c-dev vulnerable to the i2c device disappearing, for example
rmmod it?

In general no, but there is a race where this can actually happen.

Would combining i2c-dev into i2c core and integrating it
with the core's lock protection make things easier to lock?

Definitely. That's something I want to do for other reasons anyway.

You could
make a compile time option to remove it for small systems. If it's in
the core is attach/detach adapter still needed?

i2c-dev will probably soon be the last user of
i2c_adapter.attach_adapter and i2c_adapter.detach_adapter, and this is
indeed one of my incentives to look into how things could be rearranged.

I haven't looked at
any of this in detail, but i2c-dev is only 6K of code. Half of the 6K
might disappear if integrated into the core.

I doubt we can remove 3 kB just by moving things around. The
book-keeping is relatively small. But this isn't my goal anyway. My
goal is to make things cleaner and possibly safer.

One thing we may do if size is a concern, is keep the functional part
of i2c-dev in its separate module, and only merge the book-keeping and
char device creation into i2c-core.

What happens if user space and an in-kernel user both try using the
device? I've never tried doing that. Should the presence of an
in-kernel user make the user space device disappear?

What do you mean by device? The i2c bus, or a specific i2c device
(client)? The i2c bus can be used by any amount of users, in-kernel or
user-space. For i2c devices, it's more complex, depending on whether an
i2c_client is registered or not. Only one i2c_client can be registered
at a given address, but nothing prevents raw accesses to the devices.
i2c-dev makes such raw accesses, even though it has an initial check
whether the i2c address is in used by a registered client or not. This
needs to be cleaned up from the ground up, the current approach is not
satisfactory at all and things are getting worse with the advent of
new-style i2c devices, because the have a different notion of business.

--
Jean Delvare

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

Re: [i2c] i2c_smbus_write_block_data does not send all bytes?!