Re: Bitbanging i2c bus driver using the GPIO API
On Fri, 27 Apr 2007 14:53:31 -0400, Lennart Sorensen wrote: > scx200_i2c does depend on i2c-algo-bit so there is really very little > code inside scx200_i2c itself. Does the new driver replace > i2c-algo-bit as well or does it use it? It uses it. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Fri, 27 Apr 2007 14:53:31 -0400, Lennart Sorensen wrote: scx200_i2c does depend on i2c-algo-bit so there is really very little code inside scx200_i2c itself. Does the new driver replace i2c-algo-bit as well or does it use it? It uses it. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Fri, Apr 27, 2007 at 08:49:49AM -0600, Jordan Crouse wrote: > This is getting confusing... :) On the sc1200 and and GX1, the ACB > bus is accessed through ISA ports. There is no ISA on the cs5535/cs5536 > companion chips (accompanying the GX and LX processors), and the ACB > is accessed through PCI. All the platforms have LPC, but that really > doesn't matter for the purposes of this discussion. > > The silicon block that implements the ACB has been generally unchanged > over the last 6 or 7 years, so the same driver should support any of > the platforms, assuming one can invoke the magic spells to get at the > hardware. Jean and I have been concentrating most of our effort on > getting the GX and LX to work through PCI, and really haven't concentrated > our efforts on the older processors. Thats not to say it won't work, > but its probably not plug and play. Well the SC1200 has an ACB but it is disabled by default through one of the gpio multiplex selector bits. According to the data sheet only the bios knows where that is. So instead the gpio's (12 and 13) that are multiplexed with acb #2 are driven by scx200_i2c using the bit banged interface. Makes it work for those of us that don't have access to changing the bios. Unfortuantely I don't think the scx200 gpio's have been rewritten to use the new gpio interface. If it was I would try to see if the new i2c driver would work if told to use gpio 12 and 13. scx200_i2c does depend on i2c-algo-bit so there is really very little code inside scx200_i2c itself. Does the new driver replace i2c-algo-bit as well or does it use it? -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On 27/04/07 10:02 +0200, Jean Delvare wrote: > On Thu, 26 Apr 2007 10:03:23 -0400, Lennart Sorensen wrote: > > On Thu, Apr 26, 2007 at 07:39:20AM -0600, Jordan Crouse wrote: > > > There is no ISA on the LX. > > > > Isn't LPC a good equivalent? > > I suspect that Jordan meant that there is no LPC either. In which case, > of course, there's no way scx200_acb will ever work on that system, and > GPIO-based bitbanging is the way to go. Just using i2c-gpio rather than > scx200_i2c. This is getting confusing... :) On the sc1200 and and GX1, the ACB bus is accessed through ISA ports. There is no ISA on the cs5535/cs5536 companion chips (accompanying the GX and LX processors), and the ACB is accessed through PCI. All the platforms have LPC, but that really doesn't matter for the purposes of this discussion. The silicon block that implements the ACB has been generally unchanged over the last 6 or 7 years, so the same driver should support any of the platforms, assuming one can invoke the magic spells to get at the hardware. Jean and I have been concentrating most of our effort on getting the GX and LX to work through PCI, and really haven't concentrated our efforts on the older processors. Thats not to say it won't work, but its probably not plug and play. Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Fri, Apr 27, 2007 at 10:02:04AM +0200, Jean Delvare wrote: > I suspect that Jordan meant that there is no LPC either. In which case, > of course, there's no way scx200_acb will ever work on that system, and > GPIO-based bitbanging is the way to go. Just using i2c-gpio rather than > scx200_i2c. Ehm, there most certainly is LPC on a Geode LX800 + CS5536. I am currently using the LPC bus on it, and scx200_acb in 2.6.18 works perfectly with the I2C on it too. -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Thu, 26 Apr 2007 10:03:23 -0400, Lennart Sorensen wrote: > On Thu, Apr 26, 2007 at 07:39:20AM -0600, Jordan Crouse wrote: > > There is no ISA on the LX. > > Isn't LPC a good equivalant? I suspect that Jordan meant that there is no LPC either. In which case, of course, there's no way scx200_acb will ever work on that system, and GPIO-based bitbanging is the way to go. Just using i2c-gpio rather than scx200_i2c. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Thu, 26 Apr 2007 10:03:23 -0400, Lennart Sorensen wrote: On Thu, Apr 26, 2007 at 07:39:20AM -0600, Jordan Crouse wrote: There is no ISA on the LX. Isn't LPC a good equivalant? I suspect that Jordan meant that there is no LPC either. In which case, of course, there's no way scx200_acb will ever work on that system, and GPIO-based bitbanging is the way to go. Just using i2c-gpio rather than scx200_i2c. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Fri, Apr 27, 2007 at 10:02:04AM +0200, Jean Delvare wrote: I suspect that Jordan meant that there is no LPC either. In which case, of course, there's no way scx200_acb will ever work on that system, and GPIO-based bitbanging is the way to go. Just using i2c-gpio rather than scx200_i2c. Ehm, there most certainly is LPC on a Geode LX800 + CS5536. I am currently using the LPC bus on it, and scx200_acb in 2.6.18 works perfectly with the I2C on it too. -- Len Sorensen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On 27/04/07 10:02 +0200, Jean Delvare wrote: On Thu, 26 Apr 2007 10:03:23 -0400, Lennart Sorensen wrote: On Thu, Apr 26, 2007 at 07:39:20AM -0600, Jordan Crouse wrote: There is no ISA on the LX. Isn't LPC a good equivalent? I suspect that Jordan meant that there is no LPC either. In which case, of course, there's no way scx200_acb will ever work on that system, and GPIO-based bitbanging is the way to go. Just using i2c-gpio rather than scx200_i2c. This is getting confusing... :) On the sc1200 and and GX1, the ACB bus is accessed through ISA ports. There is no ISA on the cs5535/cs5536 companion chips (accompanying the GX and LX processors), and the ACB is accessed through PCI. All the platforms have LPC, but that really doesn't matter for the purposes of this discussion. The silicon block that implements the ACB has been generally unchanged over the last 6 or 7 years, so the same driver should support any of the platforms, assuming one can invoke the magic spells to get at the hardware. Jean and I have been concentrating most of our effort on getting the GX and LX to work through PCI, and really haven't concentrated our efforts on the older processors. Thats not to say it won't work, but its probably not plug and play. Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. www.amd.com/embeddedprocessors - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Fri, Apr 27, 2007 at 08:49:49AM -0600, Jordan Crouse wrote: This is getting confusing... :) On the sc1200 and and GX1, the ACB bus is accessed through ISA ports. There is no ISA on the cs5535/cs5536 companion chips (accompanying the GX and LX processors), and the ACB is accessed through PCI. All the platforms have LPC, but that really doesn't matter for the purposes of this discussion. The silicon block that implements the ACB has been generally unchanged over the last 6 or 7 years, so the same driver should support any of the platforms, assuming one can invoke the magic spells to get at the hardware. Jean and I have been concentrating most of our effort on getting the GX and LX to work through PCI, and really haven't concentrated our efforts on the older processors. Thats not to say it won't work, but its probably not plug and play. Well the SC1200 has an ACB but it is disabled by default through one of the gpio multiplex selector bits. According to the data sheet only the bios knows where that is. So instead the gpio's (12 and 13) that are multiplexed with acb #2 are driven by scx200_i2c using the bit banged interface. Makes it work for those of us that don't have access to changing the bios. Unfortuantely I don't think the scx200 gpio's have been rewritten to use the new gpio interface. If it was I would try to see if the new i2c driver would work if told to use gpio 12 and 13. scx200_i2c does depend on i2c-algo-bit so there is really very little code inside scx200_i2c itself. Does the new driver replace i2c-algo-bit as well or does it use it? -- Len Sorensen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Thu, Apr 26, 2007 at 07:39:20AM -0600, Jordan Crouse wrote: > There is no ISA on the LX. Isn't LPC a good equivalant? -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On 26/04/07 09:29 -0400, [EMAIL PROTECTED] wrote: > > These return all 0x00 > > On the Geode LX800 where scx200_acb does work all 4 commands return all > 0xff. There is no ISA on the LX. -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Thu, Apr 26, 2007 at 02:56:34PM +0200, Jean Delvare wrote: > After digging some more, I finally managed to get my hands back on it: > http://lists.lm-sensors.org/pipermail/lm-sensors/2006-April/016009.html > http://lists.lm-sensors.org/pipermail/lm-sensors/2006-May/016053.html > > This isn't "randomly hitting ISA ports", this is reading the base I/O > addresses from LPC configuration space. That's much better than letting > the user set the addresses using module parameters. > > Lennart, can you please provide the output of the following commands on > your system? > > isadump 0x2e 0x2f 5 > isadump 0x2e 0x2f 6 These return all 0xff. For example: router2:~# isadump 0x2e 0x2f 5 WARNING! Running this program can cause system crashes, data loss and worse! I will probe address register 0x2e and data register 0x2f. Probing bank 5 using bank register 0x07. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > isadump 0x4e 0x4f 5 > isadump 0x4e 0x4f 6 These return all 0x00 On the Geode LX800 where scx200_acb does work all 4 commands return all 0xff. -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Mon, 23 Apr 2007 08:47:10 -0600, Jordan Crouse wrote: > On 23/04/07 11:42 +0200, Jean Delvare wrote: > > I seem to remember there has been a patch floating around to > > auto-detect the right ports back in June 2006, but it seems to have > > been lost somehow. Jordan, do you remember? > > I don't remember that, and Google isn't helping, either. Regardless, > randomly hitting ISA ports seems scary to me. I know its a pain to use > the module params all the time, but thats really probably the cleanest way > to to it without carrying around a special patch for your system. After digging some more, I finally managed to get my hands back on it: http://lists.lm-sensors.org/pipermail/lm-sensors/2006-April/016009.html http://lists.lm-sensors.org/pipermail/lm-sensors/2006-May/016053.html This isn't "randomly hitting ISA ports", this is reading the base I/O addresses from LPC configuration space. That's much better than letting the user set the addresses using module parameters. Lennart, can you please provide the output of the following commands on your system? isadump 0x2e 0x2f 5 isadump 0x2e 0x2f 6 isadump 0x4e 0x4f 5 isadump 0x4e 0x4f 6 (isadump is part of the lm_sensors package.) -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Mon, 23 Apr 2007 08:47:10 -0600, Jordan Crouse wrote: On 23/04/07 11:42 +0200, Jean Delvare wrote: I seem to remember there has been a patch floating around to auto-detect the right ports back in June 2006, but it seems to have been lost somehow. Jordan, do you remember? I don't remember that, and Google isn't helping, either. Regardless, randomly hitting ISA ports seems scary to me. I know its a pain to use the module params all the time, but thats really probably the cleanest way to to it without carrying around a special patch for your system. After digging some more, I finally managed to get my hands back on it: http://lists.lm-sensors.org/pipermail/lm-sensors/2006-April/016009.html http://lists.lm-sensors.org/pipermail/lm-sensors/2006-May/016053.html This isn't randomly hitting ISA ports, this is reading the base I/O addresses from LPC configuration space. That's much better than letting the user set the addresses using module parameters. Lennart, can you please provide the output of the following commands on your system? isadump 0x2e 0x2f 5 isadump 0x2e 0x2f 6 isadump 0x4e 0x4f 5 isadump 0x4e 0x4f 6 (isadump is part of the lm_sensors package.) -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Thu, Apr 26, 2007 at 02:56:34PM +0200, Jean Delvare wrote: After digging some more, I finally managed to get my hands back on it: http://lists.lm-sensors.org/pipermail/lm-sensors/2006-April/016009.html http://lists.lm-sensors.org/pipermail/lm-sensors/2006-May/016053.html This isn't randomly hitting ISA ports, this is reading the base I/O addresses from LPC configuration space. That's much better than letting the user set the addresses using module parameters. Lennart, can you please provide the output of the following commands on your system? isadump 0x2e 0x2f 5 isadump 0x2e 0x2f 6 These return all 0xff. For example: router2:~# isadump 0x2e 0x2f 5 WARNING! Running this program can cause system crashes, data loss and worse! I will probe address register 0x2e and data register 0x2f. Probing bank 5 using bank register 0x07. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff isadump 0x4e 0x4f 5 isadump 0x4e 0x4f 6 These return all 0x00 On the Geode LX800 where scx200_acb does work all 4 commands return all 0xff. -- Len Sorensen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On 26/04/07 09:29 -0400, [EMAIL PROTECTED] wrote: These return all 0x00 On the Geode LX800 where scx200_acb does work all 4 commands return all 0xff. There is no ISA on the LX. -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. www.amd.com/embeddedprocessors - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On Thu, Apr 26, 2007 at 07:39:20AM -0600, Jordan Crouse wrote: There is no ISA on the LX. Isn't LPC a good equivalant? -- Len Sorensen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On 23/04/07 11:42 +0200, Jean Delvare wrote: > I seem to remember there has been a patch floating around to > auto-detect the right ports back in June 2006, but it seems to have > been lost somehow. Jordan, do you remember? I don't remember that, and Google isn't helping, either. Regardless, randomly hitting ISA ports seems scary to me. I know its a pain to use the module params all the time, but thats really probably the cleanest way to to it without carrying around a special patch for your system. Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
Lennart, On Sun, 22 Apr 2007 11:41:51 -0400, Lennart Sorensen wrote: > On Fri, Apr 20, 2007 at 07:49:33PM +0200, Jean Delvare wrote: > > The scx200_acb driver was heavily modified in 2.6.17 and 2.6.18, not > > much since then. I am not familiar with the hardware so I can't comment > > on which chips are supposed to work and which aren't. > > Well 2.6.18's scx200_acb works on the geode LX module I have, but no on > the geode sc1200 module (where scx200_i2c does work). > > scx200_acb doesn't detect any device that it can drive (nothing in dmesg > at all when loaded) on the sc1200. On the SCx200, the scx200_acb driver doesn't actually detect the device. It uses arbitrary I/O addresses and hopes for the best. By default, two buses are created, at 0x820 and 0x840. This might simply not be the right addresses for your board. See Documentation/i2c/busses/scx200_acb. You should enable CONFIG_I2C_DEBUG_BUS and see what the driver says when being loaded. I seem to remember there has been a patch floating around to auto-detect the right ports back in June 2006, but it seems to have been lost somehow. Jordan, do you remember? > I believe the main changes that > happened to scx200_acb was adding support for the newer CS chipsets, > such as the one used with the geode LX (which does work now). Not only. There was also a log of bug fixing. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
Lennart, On Sun, 22 Apr 2007 11:41:51 -0400, Lennart Sorensen wrote: On Fri, Apr 20, 2007 at 07:49:33PM +0200, Jean Delvare wrote: The scx200_acb driver was heavily modified in 2.6.17 and 2.6.18, not much since then. I am not familiar with the hardware so I can't comment on which chips are supposed to work and which aren't. Well 2.6.18's scx200_acb works on the geode LX module I have, but no on the geode sc1200 module (where scx200_i2c does work). scx200_acb doesn't detect any device that it can drive (nothing in dmesg at all when loaded) on the sc1200. On the SCx200, the scx200_acb driver doesn't actually detect the device. It uses arbitrary I/O addresses and hopes for the best. By default, two buses are created, at 0x820 and 0x840. This might simply not be the right addresses for your board. See Documentation/i2c/busses/scx200_acb. You should enable CONFIG_I2C_DEBUG_BUS and see what the driver says when being loaded. I seem to remember there has been a patch floating around to auto-detect the right ports back in June 2006, but it seems to have been lost somehow. Jordan, do you remember? I believe the main changes that happened to scx200_acb was adding support for the newer CS chipsets, such as the one used with the geode LX (which does work now). Not only. There was also a log of bug fixing. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On 23/04/07 11:42 +0200, Jean Delvare wrote: I seem to remember there has been a patch floating around to auto-detect the right ports back in June 2006, but it seems to have been lost somehow. Jordan, do you remember? I don't remember that, and Google isn't helping, either. Regardless, randomly hitting ISA ports seems scary to me. I know its a pain to use the module params all the time, but thats really probably the cleanest way to to it without carrying around a special patch for your system. Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. www.amd.com/embeddedprocessors - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On 22/04/07 11:41 -0400, [EMAIL PROTECTED] wrote: > scx200_acb doesn't detect any device that it can drive (nothing in dmesg > at all when loaded) on the sc1200. I believe the main changes that > happened to scx200_acb was adding support for the newer CS chipsets, > such as the one used with the geode LX (which does work now). That ISA detection is almost definately suffering from severe bit rot. Once you get past that though, you should be fine - the silicon behind the ACB hasn't changed since the MediaGX days. Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
On Fri, Apr 20, 2007 at 07:49:33PM +0200, Jean Delvare wrote: > The scx200_acb driver was heavily modified in 2.6.17 and 2.6.18, not > much since then. I am not familiar with the hardware so I can't comment > on which chips are supposed to work and which aren't. Well 2.6.18's scx200_acb works on the geode LX module I have, but no on the geode sc1200 module (where scx200_i2c does work). scx200_acb doesn't detect any device that it can drive (nothing in dmesg at all when loaded) on the sc1200. I believe the main changes that happened to scx200_acb was adding support for the newer CS chipsets, such as the one used with the geode LX (which does work now). -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
On Fri, Apr 20, 2007 at 07:49:33PM +0200, Jean Delvare wrote: The scx200_acb driver was heavily modified in 2.6.17 and 2.6.18, not much since then. I am not familiar with the hardware so I can't comment on which chips are supposed to work and which aren't. Well 2.6.18's scx200_acb works on the geode LX module I have, but no on the geode sc1200 module (where scx200_i2c does work). scx200_acb doesn't detect any device that it can drive (nothing in dmesg at all when loaded) on the sc1200. I believe the main changes that happened to scx200_acb was adding support for the newer CS chipsets, such as the one used with the geode LX (which does work now). -- Len Sorensen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On 22/04/07 11:41 -0400, [EMAIL PROTECTED] wrote: scx200_acb doesn't detect any device that it can drive (nothing in dmesg at all when loaded) on the sc1200. I believe the main changes that happened to scx200_acb was adding support for the newer CS chipsets, such as the one used with the geode LX (which does work now). That ISA detection is almost definately suffering from severe bit rot. Once you get past that though, you should be fine - the silicon behind the ACB hasn't changed since the MediaGX days. Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. www.amd.com/embeddedprocessors - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
Hi Lennart, On Thu, 19 Apr 2007 16:59:42 -0400, Lennart Sorensen wrote: > On Thu, Apr 19, 2007 at 08:54:13AM +0200, Jean Delvare wrote: > > The major difference is that the implementation in scx200_i2c is > > hardware-specific, while the i2c-gpio driver is a generic one, so it's > > a lot better. > > > > What this means is that i2c-gpio obsoletes scx200_i2c, so I am inclined > > to delete scx200_i2c right away. I'm not even sure anyone still uses it > > now that scx200_acb has been fixed and is reported to work very well. > > If anyone really needs to do I2C over GPIO pins on SCx200, this should > > be reimplemented on top of i2c-gpio. > > I use scx200_i2c. The SBC I am using doesn't work with the scx200_acb > (different pins on the cpu after all). I would love to see it > reimplemented using the generic interface, since there isn't that many > lines of code involved as far as I can tell. Well scx200_acb works fine > on a Geode LX board, but not on a Geode SC1200 board. Unless it has > been fixed since 2.6.18, then it still doesn't work, but scx200_i2c > works perfectly fine. The scx200_acb driver was heavily modified in 2.6.17 and 2.6.18, not much since then. I am not familiar with the hardware so I can't comment on which chips are supposed to work and which aren't. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
Hi Lennart, On Thu, 19 Apr 2007 16:59:42 -0400, Lennart Sorensen wrote: On Thu, Apr 19, 2007 at 08:54:13AM +0200, Jean Delvare wrote: The major difference is that the implementation in scx200_i2c is hardware-specific, while the i2c-gpio driver is a generic one, so it's a lot better. What this means is that i2c-gpio obsoletes scx200_i2c, so I am inclined to delete scx200_i2c right away. I'm not even sure anyone still uses it now that scx200_acb has been fixed and is reported to work very well. If anyone really needs to do I2C over GPIO pins on SCx200, this should be reimplemented on top of i2c-gpio. I use scx200_i2c. The SBC I am using doesn't work with the scx200_acb (different pins on the cpu after all). I would love to see it reimplemented using the generic interface, since there isn't that many lines of code involved as far as I can tell. Well scx200_acb works fine on a Geode LX board, but not on a Geode SC1200 board. Unless it has been fixed since 2.6.18, then it still doesn't work, but scx200_i2c works perfectly fine. The scx200_acb driver was heavily modified in 2.6.17 and 2.6.18, not much since then. I am not familiar with the hardware so I can't comment on which chips are supposed to work and which aren't. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
On Thu, Apr 19, 2007 at 08:54:13AM +0200, Jean Delvare wrote: > The major difference is that the implementation in scx200_i2c is > hardware-specific, while the i2c-gpio driver is a generic one, so it's > a lot better. > > What this means is that i2c-gpio obsoletes scx200_i2c, so I am inclined > to delete scx200_i2c right away. I'm not even sure anyone still uses it > now that scx200_acb has been fixed and is reported to work very well. > If anyone really needs to do I2C over GPIO pins on SCx200, this should > be reimplemented on top of i2c-gpio. I use scx200_i2c. The SBC I am using doesn't work with the scx200_acb (different pins on the cpu after all). I would love to see it reimplemented using the generic interface, since there isn't that many lines of code involved as far as I can tell. Well scx200_acb works fine on a Geode LX board, but not on a Geode SC1200 board. Unless it has been fixed since 2.6.18, then it still doesn't work, but scx200_i2c works perfectly fine. > It also looks to me like i2c-ixp2000 and i2c-ixp4xx are obsoleted by > i2c-gpio. Deepak, can you please try using i2c-gpio instead and confirm > that i2c-ixp2000 and i2c-ixp4xx can be deleted? -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On 19/04/07 08:54 +0200, Jean Delvare wrote: > Hi Len, > > On Wed, 18 Apr 2007 13:42:56 -0400, Lennart Sorensen wrote: > > On Sat, Apr 14, 2007 at 07:28:07PM +0200, Jean Delvare wrote: > > > Otherwise it looks OK to me, I take the patch. If others have comments > > > or objections, just speak up and submit incremental patches as needed. > > > > > > Now I would like to see platform code actually using this. > > > > Any idea how similar this new driver is to the scx200_i2c driver? As > > far as I can tell that driver is already a bit banged i2c over gpio > > lines. > > The major difference is that the implementation in scx200_i2c is > hardware-specific, while the i2c-gpio driver is a generic one, so it's > a lot better. > > What this means is that i2c-gpio obsoletes scx200_i2c, so I am inclined > to delete scx200_i2c right away. I'm not even sure anyone still uses it > now that scx200_acb has been fixed and is reported to work very well. > If anyone really needs to do I2C over GPIO pins on SCx200, this should > be reimplemented on top of i2c-gpio. It would also force us to move the Geode GPIO pins to the generic infrastructure, so that would be good. I say delete it - if anybody needs that functionality, then we'll do it the right way. Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
Hi Len, On Wed, 18 Apr 2007 13:42:56 -0400, Lennart Sorensen wrote: > On Sat, Apr 14, 2007 at 07:28:07PM +0200, Jean Delvare wrote: > > Otherwise it looks OK to me, I take the patch. If others have comments > > or objections, just speak up and submit incremental patches as needed. > > > > Now I would like to see platform code actually using this. > > Any idea how similar this new driver is to the scx200_i2c driver? As > far as I can tell that driver is already a bit banged i2c over gpio > lines. The major difference is that the implementation in scx200_i2c is hardware-specific, while the i2c-gpio driver is a generic one, so it's a lot better. What this means is that i2c-gpio obsoletes scx200_i2c, so I am inclined to delete scx200_i2c right away. I'm not even sure anyone still uses it now that scx200_acb has been fixed and is reported to work very well. If anyone really needs to do I2C over GPIO pins on SCx200, this should be reimplemented on top of i2c-gpio. It also looks to me like i2c-ixp2000 and i2c-ixp4xx are obsoleted by i2c-gpio. Deepak, can you please try using i2c-gpio instead and confirm that i2c-ixp2000 and i2c-ixp4xx can be deleted? Thanks, -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
Hi Len, On Wed, 18 Apr 2007 13:42:56 -0400, Lennart Sorensen wrote: On Sat, Apr 14, 2007 at 07:28:07PM +0200, Jean Delvare wrote: Otherwise it looks OK to me, I take the patch. If others have comments or objections, just speak up and submit incremental patches as needed. Now I would like to see platform code actually using this. Any idea how similar this new driver is to the scx200_i2c driver? As far as I can tell that driver is already a bit banged i2c over gpio lines. The major difference is that the implementation in scx200_i2c is hardware-specific, while the i2c-gpio driver is a generic one, so it's a lot better. What this means is that i2c-gpio obsoletes scx200_i2c, so I am inclined to delete scx200_i2c right away. I'm not even sure anyone still uses it now that scx200_acb has been fixed and is reported to work very well. If anyone really needs to do I2C over GPIO pins on SCx200, this should be reimplemented on top of i2c-gpio. It also looks to me like i2c-ixp2000 and i2c-ixp4xx are obsoleted by i2c-gpio. Deepak, can you please try using i2c-gpio instead and confirm that i2c-ixp2000 and i2c-ixp4xx can be deleted? Thanks, -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On 19/04/07 08:54 +0200, Jean Delvare wrote: Hi Len, On Wed, 18 Apr 2007 13:42:56 -0400, Lennart Sorensen wrote: On Sat, Apr 14, 2007 at 07:28:07PM +0200, Jean Delvare wrote: Otherwise it looks OK to me, I take the patch. If others have comments or objections, just speak up and submit incremental patches as needed. Now I would like to see platform code actually using this. Any idea how similar this new driver is to the scx200_i2c driver? As far as I can tell that driver is already a bit banged i2c over gpio lines. The major difference is that the implementation in scx200_i2c is hardware-specific, while the i2c-gpio driver is a generic one, so it's a lot better. What this means is that i2c-gpio obsoletes scx200_i2c, so I am inclined to delete scx200_i2c right away. I'm not even sure anyone still uses it now that scx200_acb has been fixed and is reported to work very well. If anyone really needs to do I2C over GPIO pins on SCx200, this should be reimplemented on top of i2c-gpio. It would also force us to move the Geode GPIO pins to the generic infrastructure, so that would be good. I say delete it - if anybody needs that functionality, then we'll do it the right way. Jordan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
On Thu, Apr 19, 2007 at 08:54:13AM +0200, Jean Delvare wrote: The major difference is that the implementation in scx200_i2c is hardware-specific, while the i2c-gpio driver is a generic one, so it's a lot better. What this means is that i2c-gpio obsoletes scx200_i2c, so I am inclined to delete scx200_i2c right away. I'm not even sure anyone still uses it now that scx200_acb has been fixed and is reported to work very well. If anyone really needs to do I2C over GPIO pins on SCx200, this should be reimplemented on top of i2c-gpio. I use scx200_i2c. The SBC I am using doesn't work with the scx200_acb (different pins on the cpu after all). I would love to see it reimplemented using the generic interface, since there isn't that many lines of code involved as far as I can tell. Well scx200_acb works fine on a Geode LX board, but not on a Geode SC1200 board. Unless it has been fixed since 2.6.18, then it still doesn't work, but scx200_i2c works perfectly fine. It also looks to me like i2c-ixp2000 and i2c-ixp4xx are obsoleted by i2c-gpio. Deepak, can you please try using i2c-gpio instead and confirm that i2c-ixp2000 and i2c-ixp4xx can be deleted? -- Len Sorensen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
On Sat, Apr 14, 2007 at 07:28:07PM +0200, Jean Delvare wrote: > Otherwise it looks OK to me, I take the patch. If others have comments > or objections, just speak up and submit incremental patches as needed. > > Now I would like to see platform code actually using this. Any idea how similar this new driver is to the scx200_i2c driver? As far as I can tell that driver is already a bit banged i2c over gpio lines. -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
On Sat, Apr 14, 2007 at 07:28:07PM +0200, Jean Delvare wrote: Otherwise it looks OK to me, I take the patch. If others have comments or objections, just speak up and submit incremental patches as needed. Now I would like to see platform code actually using this. Any idea how similar this new driver is to the scx200_i2c driver? As far as I can tell that driver is already a bit banged i2c over gpio lines. -- Len Sorensen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
Hi Haavard,
On Sat, 14 Apr 2007 16:34:18 +0200, Haavard Skinnemoen wrote:
> On Sat, 14 Apr 2007 14:56:47 +0200
> Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
>
> > o Default to a very low SCL frequency (6.6 kHz) if clock stretching
> > isn't supported
>
> This would have been true if I had remembered to save before generating
> the patch...
>
> Updated patch below. Sorry about the mess.
>
> Haavard
>
> ===[cut here]==
> From: Haavard Skinnemoen <[EMAIL PROTECTED]>
> Subject: [PATCH] Bitbanging i2c bus driver using the GPIO API
>
> This is a very simple bitbanging i2c bus driver utilizing the new
> arch-neutral GPIO API. Useful for chips that don't have a built-in
> i2c controller, additional i2c busses, or testing purposes.
>
> To use, include something similar to the following in the
> board-specific setup code:
>
> #include
>
> static struct i2c_gpio_platform_data i2c_gpio_data = {
> .sda_pin= GPIO_PIN_FOO,
> .scl_pin= GPIO_PIN_BAR,
> };
> static struct platform_device i2c_gpio_device = {
> .name = "i2c-gpio",
> .id = 0,
> .dev= {
> .platform_data = _gpio_data,
> },
> };
>
> Register this platform_device, set up the i2c pins as GPIO if
> required and you're ready to go. This will use default values for
> udelay and timeout, and will work with GPIO hardware that does not
> support open drain mode, but allows sensing of the SDA and SCL lines
> even when they are being driven.
>
> Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
> ---
> MAINTAINERS |5 +
> drivers/i2c/busses/Kconfig|8 ++
> drivers/i2c/busses/Makefile |1 +
> drivers/i2c/busses/i2c-gpio.c | 215
> +
> include/linux/i2c-gpio.h | 38 +++
> 5 files changed, 267 insertions(+), 0 deletions(-)
Random comments:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ef84419..fdecda4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1429,6 +1429,11 @@ L: [EMAIL PROTECTED]
> W: http://www.icp-vortex.com/
> S: Supported
>
> +GENERIC GPIO I2C DRIVER
> +P: Haavard Skinnemoen
> +M: [EMAIL PROTECTED]
> +S: Supported
> +
> GENERIC HDLC DRIVER, N2, C101, PCI200SYN and WANXL DRIVERS
> P: Krzysztof Halasa
> M: [EMAIL PROTECTED]
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index fb19dbb..52f79d1 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -102,6 +102,14 @@ config I2C_ELEKTOR
> This support is also available as a module. If so, the module
> will be called i2c-elektor.
>
> +config I2C_GPIO
> + tristate "GPIO-based bitbanging i2c driver"
I removed "driver" from the option name.
> + depends on I2C && GENERIC_GPIO
I removed I2C, in accordance with Jan Engelhardt's patch:
http://lkml.org/lkml/2007/4/11/153
> + select I2C_ALGOBIT
> + help
> + This is a very simple bitbanging i2c driver utilizing the
> + arch-neutral GPIO API to control the SCL and SDA lines.
> +
> config I2C_HYDRA
> tristate "CHRP Apple Hydra Mac I/O I2C interface"
> depends on I2C && PCI && PPC_CHRP && EXPERIMENTAL
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 290b540..68f2b05 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
> obj-$(CONFIG_I2C_AT91) += i2c-at91.o
> obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
> obj-$(CONFIG_I2C_ELEKTOR)+= i2c-elektor.o
> +obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
> obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o
> obj-$(CONFIG_I2C_I801) += i2c-i801.o
> obj-$(CONFIG_I2C_I810) += i2c-i810.o
> diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
> new file mode 100644
> index 000..e427bfb
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-gpio.c
> @@ -0,0 +1,215 @@
> +/*
> + * Bitbanging i2c bus driver using the GPIO API
> + *
> + * Copyright (C) 2007 Atmel Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/*
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
On Sat, 14 Apr 2007 14:56:47 +0200
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> o Default to a very low SCL frequency (6.6 kHz) if clock stretching
> isn't supported
This would have been true if I had remembered to save before generating
the patch...
Updated patch below. Sorry about the mess.
Haavard
===[cut here]==
From: Haavard Skinnemoen <[EMAIL PROTECTED]>
Subject: [PATCH] Bitbanging i2c bus driver using the GPIO API
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
To use, include something similar to the following in the
board-specific setup code:
#include
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
static struct platform_device i2c_gpio_device = {
.name = "i2c-gpio",
.id = 0,
.dev= {
.platform_data = _gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go. This will use default values for
udelay and timeout, and will work with GPIO hardware that does not
support open drain mode, but allows sensing of the SDA and SCL lines
even when they are being driven.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
MAINTAINERS |5 +
drivers/i2c/busses/Kconfig|8 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-gpio.c | 215 +
include/linux/i2c-gpio.h | 38 +++
5 files changed, 267 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ef84419..fdecda4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1429,6 +1429,11 @@ L: [EMAIL PROTECTED]
W: http://www.icp-vortex.com/
S: Supported
+GENERIC GPIO I2C DRIVER
+P: Haavard Skinnemoen
+M: [EMAIL PROTECTED]
+S: Supported
+
GENERIC HDLC DRIVER, N2, C101, PCI200SYN and WANXL DRIVERS
P: Krzysztof Halasa
M: [EMAIL PROTECTED]
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
This support is also available as a module. If so, the module
will be called i2c-elektor.
+config I2C_GPIO
+ tristate "GPIO-based bitbanging i2c driver"
+ depends on I2C && GENERIC_GPIO
+ select I2C_ALGOBIT
+ help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
config I2C_HYDRA
tristate "CHRP Apple Hydra Mac I/O I2C interface"
depends on I2C && PCI && PPC_CHRP && EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HYDRA)+= i2c-hydra.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..e427bfb
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,215 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2007 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* Toggle SDA by changing the direction of the pin */
+static void i2c_gpio_setsda_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata->sda_pin);
+ else
+ gpio_direction_output(pdata->sda_pin, 0);
+}
+
+/*
+ * Toggle SDA by changing the output value of the pin. This is only
+ * valid for pins configured as open drain (i.e. setting the value
+ * high effectively turns off the output driver.)
+ */
+static void i2c_gpio_setsda_val(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ gpio_set_value(pdata->sda_pin, state);
+}
+
+/* Toggle SCL by changing the direction of the pin. */
+static void i2c_gpio_setscl_dir(void *data, int state)
+{
+ struct i2c_gpio_platfo
[PATCH v3] Bitbanging i2c bus driver using the GPIO API
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
To use, include something similar to the following in the
board-specific setup code:
#include
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
static struct platform_device i2c_gpio_device = {
.name = "i2c-gpio",
.id = 0,
.dev= {
.platform_data = _gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go. This will use default values for
udelay and timeout, and will work with GPIO hardware that does not
support open drain mode, but allows changing the direction of the SDA
and SCL lines on the fly.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
Sorry for the long delay. I didn't want to send out a patch just
before taking off for two weeks. This patch contains the following
changes compared to v2:
o Make udelay and timeout parameterizable and fix comment
o Default to a very low SCL frequency (6.6 kHz) if clock stretching
isn't supported
o Document that GPIO hardware must report actual state of sda and
scl pins in open drain mode.
o Add myself to MAINTAINERS
o Add KERN_ERR to "probe failed" message
o Use new gpio_direction_output() API
MAINTAINERS |5 +
drivers/i2c/busses/Kconfig|8 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-gpio.c | 213 +
include/linux/i2c-gpio.h | 38 +++
5 files changed, 265 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ef84419..fdecda4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1429,6 +1429,11 @@ L: [EMAIL PROTECTED]
W: http://www.icp-vortex.com/
S: Supported
+GENERIC GPIO I2C DRIVER
+P: Haavard Skinnemoen
+M: [EMAIL PROTECTED]
+S: Supported
+
GENERIC HDLC DRIVER, N2, C101, PCI200SYN and WANXL DRIVERS
P: Krzysztof Halasa
M: [EMAIL PROTECTED]
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
This support is also available as a module. If so, the module
will be called i2c-elektor.
+config I2C_GPIO
+ tristate "GPIO-based bitbanging i2c driver"
+ depends on I2C && GENERIC_GPIO
+ select I2C_ALGOBIT
+ help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
config I2C_HYDRA
tristate "CHRP Apple Hydra Mac I/O I2C interface"
depends on I2C && PCI && PPC_CHRP && EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HYDRA)+= i2c-hydra.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..895d150
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,213 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2007 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* Toggle SDA by changing the direction of the pin */
+static void i2c_gpio_setsda_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata->sda_pin);
+ else
+ gpio_direction_output(pdata->sda_pin, 0);
+}
+
+/*
+ * Toggle SDA by changing the output value of the pin. This is only
+ * valid for pins configured as open drain (i.e. setting the value
+ * high effectively turns off the output driver.)
+ */
+static void i2c_gpio_setsda_val(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ gpio_set_value(pdata->sda_pin, state);
+}
+
+/* Toggle SCL by changing the direction of the pin. */
+static void i2c_gpio_setscl_dir(void *data,
[PATCH v3] Bitbanging i2c bus driver using the GPIO API
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
To use, include something similar to the following in the
board-specific setup code:
#include linux/i2c-gpio.h
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
static struct platform_device i2c_gpio_device = {
.name = i2c-gpio,
.id = 0,
.dev= {
.platform_data = i2c_gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go. This will use default values for
udelay and timeout, and will work with GPIO hardware that does not
support open drain mode, but allows changing the direction of the SDA
and SCL lines on the fly.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
Sorry for the long delay. I didn't want to send out a patch just
before taking off for two weeks. This patch contains the following
changes compared to v2:
o Make udelay and timeout parameterizable and fix comment
o Default to a very low SCL frequency (6.6 kHz) if clock stretching
isn't supported
o Document that GPIO hardware must report actual state of sda and
scl pins in open drain mode.
o Add myself to MAINTAINERS
o Add KERN_ERR to probe failed message
o Use new gpio_direction_output() API
MAINTAINERS |5 +
drivers/i2c/busses/Kconfig|8 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-gpio.c | 213 +
include/linux/i2c-gpio.h | 38 +++
5 files changed, 265 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ef84419..fdecda4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1429,6 +1429,11 @@ L: [EMAIL PROTECTED]
W: http://www.icp-vortex.com/
S: Supported
+GENERIC GPIO I2C DRIVER
+P: Haavard Skinnemoen
+M: [EMAIL PROTECTED]
+S: Supported
+
GENERIC HDLC DRIVER, N2, C101, PCI200SYN and WANXL DRIVERS
P: Krzysztof Halasa
M: [EMAIL PROTECTED]
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
This support is also available as a module. If so, the module
will be called i2c-elektor.
+config I2C_GPIO
+ tristate GPIO-based bitbanging i2c driver
+ depends on I2C GENERIC_GPIO
+ select I2C_ALGOBIT
+ help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
config I2C_HYDRA
tristate CHRP Apple Hydra Mac I/O I2C interface
depends on I2C PCI PPC_CHRP EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HYDRA)+= i2c-hydra.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..895d150
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,213 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2007 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/i2c.h
+#include linux/i2c-algo-bit.h
+#include linux/i2c-gpio.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+
+#include asm/gpio.h
+
+/* Toggle SDA by changing the direction of the pin */
+static void i2c_gpio_setsda_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata-sda_pin);
+ else
+ gpio_direction_output(pdata-sda_pin, 0);
+}
+
+/*
+ * Toggle SDA by changing the output value of the pin. This is only
+ * valid for pins configured as open drain (i.e. setting the value
+ * high effectively turns off the output driver.)
+ */
+static void i2c_gpio_setsda_val(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ gpio_set_value(pdata-sda_pin, state);
+}
+
+/* Toggle SCL by changing the direction of the pin. */
+static void i2c_gpio_setscl_dir(void *data, int
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
On Sat, 14 Apr 2007 14:56:47 +0200
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
o Default to a very low SCL frequency (6.6 kHz) if clock stretching
isn't supported
This would have been true if I had remembered to save before generating
the patch...
Updated patch below. Sorry about the mess.
Haavard
===[cut here]==
From: Haavard Skinnemoen [EMAIL PROTECTED]
Subject: [PATCH] Bitbanging i2c bus driver using the GPIO API
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
To use, include something similar to the following in the
board-specific setup code:
#include linux/i2c-gpio.h
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
static struct platform_device i2c_gpio_device = {
.name = i2c-gpio,
.id = 0,
.dev= {
.platform_data = i2c_gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go. This will use default values for
udelay and timeout, and will work with GPIO hardware that does not
support open drain mode, but allows sensing of the SDA and SCL lines
even when they are being driven.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
MAINTAINERS |5 +
drivers/i2c/busses/Kconfig|8 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-gpio.c | 215 +
include/linux/i2c-gpio.h | 38 +++
5 files changed, 267 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ef84419..fdecda4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1429,6 +1429,11 @@ L: [EMAIL PROTECTED]
W: http://www.icp-vortex.com/
S: Supported
+GENERIC GPIO I2C DRIVER
+P: Haavard Skinnemoen
+M: [EMAIL PROTECTED]
+S: Supported
+
GENERIC HDLC DRIVER, N2, C101, PCI200SYN and WANXL DRIVERS
P: Krzysztof Halasa
M: [EMAIL PROTECTED]
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
This support is also available as a module. If so, the module
will be called i2c-elektor.
+config I2C_GPIO
+ tristate GPIO-based bitbanging i2c driver
+ depends on I2C GENERIC_GPIO
+ select I2C_ALGOBIT
+ help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
config I2C_HYDRA
tristate CHRP Apple Hydra Mac I/O I2C interface
depends on I2C PCI PPC_CHRP EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HYDRA)+= i2c-hydra.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..e427bfb
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,215 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2007 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/i2c.h
+#include linux/i2c-algo-bit.h
+#include linux/i2c-gpio.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+
+#include asm/gpio.h
+
+/* Toggle SDA by changing the direction of the pin */
+static void i2c_gpio_setsda_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata-sda_pin);
+ else
+ gpio_direction_output(pdata-sda_pin, 0);
+}
+
+/*
+ * Toggle SDA by changing the output value of the pin. This is only
+ * valid for pins configured as open drain (i.e. setting the value
+ * high effectively turns off the output driver.)
+ */
+static void i2c_gpio_setsda_val(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ gpio_set_value(pdata-sda_pin, state);
+}
+
+/* Toggle SCL by changing the direction of the pin. */
+static void i2c_gpio_setscl_dir(void *data, int state)
+{
+ struct
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
Hi Haavard,
On Sat, 14 Apr 2007 16:34:18 +0200, Haavard Skinnemoen wrote:
On Sat, 14 Apr 2007 14:56:47 +0200
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
o Default to a very low SCL frequency (6.6 kHz) if clock stretching
isn't supported
This would have been true if I had remembered to save before generating
the patch...
Updated patch below. Sorry about the mess.
Haavard
===[cut here]==
From: Haavard Skinnemoen [EMAIL PROTECTED]
Subject: [PATCH] Bitbanging i2c bus driver using the GPIO API
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
To use, include something similar to the following in the
board-specific setup code:
#include linux/i2c-gpio.h
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
static struct platform_device i2c_gpio_device = {
.name = i2c-gpio,
.id = 0,
.dev= {
.platform_data = i2c_gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go. This will use default values for
udelay and timeout, and will work with GPIO hardware that does not
support open drain mode, but allows sensing of the SDA and SCL lines
even when they are being driven.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
MAINTAINERS |5 +
drivers/i2c/busses/Kconfig|8 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-gpio.c | 215
+
include/linux/i2c-gpio.h | 38 +++
5 files changed, 267 insertions(+), 0 deletions(-)
Random comments:
diff --git a/MAINTAINERS b/MAINTAINERS
index ef84419..fdecda4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1429,6 +1429,11 @@ L: [EMAIL PROTECTED]
W: http://www.icp-vortex.com/
S: Supported
+GENERIC GPIO I2C DRIVER
+P: Haavard Skinnemoen
+M: [EMAIL PROTECTED]
+S: Supported
+
GENERIC HDLC DRIVER, N2, C101, PCI200SYN and WANXL DRIVERS
P: Krzysztof Halasa
M: [EMAIL PROTECTED]
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
This support is also available as a module. If so, the module
will be called i2c-elektor.
+config I2C_GPIO
+ tristate GPIO-based bitbanging i2c driver
I removed driver from the option name.
+ depends on I2C GENERIC_GPIO
I removed I2C, in accordance with Jan Engelhardt's patch:
http://lkml.org/lkml/2007/4/11/153
+ select I2C_ALGOBIT
+ help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
config I2C_HYDRA
tristate CHRP Apple Hydra Mac I/O I2C interface
depends on I2C PCI PPC_CHRP EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_ELEKTOR)+= i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..e427bfb
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,215 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2007 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/i2c.h
+#include linux/i2c-algo-bit.h
+#include linux/i2c-gpio.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+
+#include asm/gpio.h
+
+/* Toggle SDA by changing the direction of the pin */
+static void i2c_gpio_setsda_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata-sda_pin);
+ else
+ gpio_direction_output(pdata-sda_pin, 0);
+}
+
+/*
+ * Toggle SDA by changing the output value of the pin. This is only
+ * valid for pins configured as open drain (i.e. setting the value
+ * high effectively turns off the output
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Mon, 12 Mar 2007 16:11:09 +0100 Jean Delvare <[EMAIL PROTECTED]> wrote: > > By the way, timeout seems to be hardcoded to 100 jiffies in the > > i2c-algo-bit driver, so there's probably not much point passing it from > > the board code when it's going to be overridden anyway. I'll add just a > > udelay parameter to the platform struct for now. > > No, it's not hardcoded. I know it looks confusing. struct i2c_adapter > has a timeout field, that's the one being set to 100 in i2c-algo-bit, > but i2c-algo-bit uses the i2c_algo_bit_data timeout field. The > i2c_adapter timeout field is unused. Ah, I see. Now that you mention it, I seem to recall I came to that conclusion last time I looked at the code, but I've apparently forgotten it since then ;) I'll add a timeout field to the platform struct as well, then. Haavard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
Hi Haavard, On Mon, 12 Mar 2007 15:53:59 +0100, Haavard Skinnemoen wrote: > On Mon, 12 Mar 2007 15:34:57 +0100 > Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > > > > > + bit_data->udelay= 5,/* 100 kHz */ > > > > + bit_data->timeout = HZ / 10, /* 100 ms */ > > > > > > Can we add these udelay/timeout to struct i2c_gpio_platform_data? And > > > let customer to choose these according their specific requirement. We > > > use Kconfig to do this, but Jean and David don't like the idea, -:( > > > > Yeah, they need to be a bit more configurable than they currently are. > > And I think it makes sense to pass them from the board setup code, since > > this is where things depending on board-specific details (signal quality > > issues, pullup resistor values, etc.) are supposed to go. > > By the way, timeout seems to be hardcoded to 100 jiffies in the > i2c-algo-bit driver, so there's probably not much point passing it from > the board code when it's going to be overridden anyway. I'll add just a > udelay parameter to the platform struct for now. No, it's not hardcoded. I know it looks confusing. struct i2c_adapter has a timeout field, that's the one being set to 100 in i2c-algo-bit, but i2c-algo-bit uses the i2c_algo_bit_data timeout field. The i2c_adapter timeout field is unused. This is clearly calling for a cleanup but I don't have time for this right now. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Mon, 12 Mar 2007 15:34:57 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > > > + bit_data->udelay= 5,/* 100 kHz */ > > > + bit_data->timeout = HZ / 10, /* 100 ms */ > > > > Can we add these udelay/timeout to struct i2c_gpio_platform_data? And > > let customer to choose these according their specific requirement. We > > use Kconfig to do this, but Jean and David don't like the idea, -:( > > Yeah, they need to be a bit more configurable than they currently are. > And I think it makes sense to pass them from the board setup code, since > this is where things depending on board-specific details (signal quality > issues, pullup resistor values, etc.) are supposed to go. By the way, timeout seems to be hardcoded to 100 jiffies in the i2c-algo-bit driver, so there's probably not much point passing it from the board code when it's going to be overridden anyway. I'll add just a udelay parameter to the platform struct for now. Haavard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Mon, 12 Mar 2007 18:07:59 +0800
"Wu, Bryan" <[EMAIL PROTECTED]> wrote:
> > static struct i2c_gpio_platform_data i2c_gpio_data = {
> > .sda_pin= GPIO_PIN_FOO,
> > .scl_pin= GPIO_PIN_BAR,
> > };
>
> Is this usage right, because 3 flags are added to this structure as
> below:
>
> struct i2c_gpio_platform_data {
> unsigned int sda_pin;
> unsigned int scl_pin;
> unsigned int sda_is_open_drain:1;
> unsigned int scl_is_open_drain:1;
> unsigned int scl_is_output_only:1;
> };
Well, it is the simplest possible example. The last 3 fields will be 0,
which is a valid configuration.
> Thanks a lot, I will drop our GPIO based I2C driver and try this one on
> our platform.
I hope it works for you.
> > + if (!pdata->scl_is_output_only)
> > + bit_data->getscl = i2c_gpio_getscl,
> > +
> > + bit_data->getsda= i2c_gpio_getsda,
> > + bit_data->udelay= 5,/* 100 kHz */
> > + bit_data->timeout = HZ / 10, /* 100 ms */
>
> Can we add these udelay/timeout to struct i2c_gpio_platform_data? And
> let customer to choose these according their specific requirement. We
> use Kconfig to do this, but Jean and David don't like the idea, -:(
Yeah, they need to be a bit more configurable than they currently are.
And I think it makes sense to pass them from the board setup code, since
this is where things depending on board-specific details (signal quality
issues, pullup resistor values, etc.) are supposed to go.
Haavard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Sat, 10 Mar 2007 21:15:50 +0100
Jean Delvare <[EMAIL PROTECTED]> wrote:
> I like the idea very much. Would this let us get rid of i2c-ixp2000?
> i2c-ixp4xx? scx200_i2c? Other drivers?
Any platform that implements the generic gpio api should be able to use
this driver. So yes, I hope we might be able to get rid of a few
existing bitbanging drivers.
> > +/*
> > + * Bitbanging i2c bus driver using the GPIO API
> > + *
> > + * Copyright (C) 2006 Atmel Corporation
>
> I'm told we're in year 2007 ;)
I'm also told that copyright protection lasts infinitely long in
practice ;)
I'll update it. I probably just copied it blindly from a different
driver.
> > +int i2c_gpio_getsda(void *data)
> > +{
> > + struct i2c_gpio_platform_data *pdata = data;
> > +
> > + return gpio_get_value(pdata->sda_pin);
> > +}
>
>
> What value will you get if the SDA pin is open-drain and currently in
> output mode? Are such GPIO pins actually able to detect that the pin is
> low while they are not themselves driving it low?
I guess that depends on the GPIO controller. But being able to read the
pin state even when the pin is configured as an output is a
prerequisite for using this driver with "open drain" pins, so if the
hardware doesn't support this, the board code should just set
{sda,scl}_is_opendrain to zero.
> > + bit_data->udelay= 5,/* 100 kHz */
>
> Actually, no, i2c-algo-bit has a 1/3-2/3 duty cycle, so a complete
> cycle is 3 times the udelay value. So udelay=5 gives you 66 kHz. If
> someone wants to fix that...
Ok. I guess we should move this parameter into the platform data struct
anyway.
> Also, I wouldn't recommend such a low value when SCL cannot be sensed,
> if a slave stretches the line even very briefly, you won't notice and
> havoc will ensue. udelay=50 sounds more reasonable for such half-baked
> busses.
Makes sense.
> > + ret = platform_driver_probe(_gpio_driver, i2c_gpio_probe);
> > + if (ret)
> > + printk("i2c-gpio: probe failed: %d\n", ret);
>
> Add KERN_ERR or similar.
Will do.
> Would you mind also adding yourself to MAINTAINERS for this driver? I
> would appreciate it.
Sure. I'm hoping this driver won't cause that much maintenance overhead
anyway since all the complicated stuff is in i2c-algo-bit. But I agree
it needs a maintainer.
Haavard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Sat, 10 Mar 2007 21:15:50 +0100
Jean Delvare [EMAIL PROTECTED] wrote:
I like the idea very much. Would this let us get rid of i2c-ixp2000?
i2c-ixp4xx? scx200_i2c? Other drivers?
Any platform that implements the generic gpio api should be able to use
this driver. So yes, I hope we might be able to get rid of a few
existing bitbanging drivers.
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2006 Atmel Corporation
I'm told we're in year 2007 ;)
I'm also told that copyright protection lasts infinitely long in
practice ;)
I'll update it. I probably just copied it blindly from a different
driver.
+int i2c_gpio_getsda(void *data)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ return gpio_get_value(pdata-sda_pin);
+}
What value will you get if the SDA pin is open-drain and currently in
output mode? Are such GPIO pins actually able to detect that the pin is
low while they are not themselves driving it low?
I guess that depends on the GPIO controller. But being able to read the
pin state even when the pin is configured as an output is a
prerequisite for using this driver with open drain pins, so if the
hardware doesn't support this, the board code should just set
{sda,scl}_is_opendrain to zero.
+ bit_data-udelay= 5,/* 100 kHz */
Actually, no, i2c-algo-bit has a 1/3-2/3 duty cycle, so a complete
cycle is 3 times the udelay value. So udelay=5 gives you 66 kHz. If
someone wants to fix that...
Ok. I guess we should move this parameter into the platform data struct
anyway.
Also, I wouldn't recommend such a low value when SCL cannot be sensed,
if a slave stretches the line even very briefly, you won't notice and
havoc will ensue. udelay=50 sounds more reasonable for such half-baked
busses.
Makes sense.
+ ret = platform_driver_probe(i2c_gpio_driver, i2c_gpio_probe);
+ if (ret)
+ printk(i2c-gpio: probe failed: %d\n, ret);
Add KERN_ERR or similar.
Will do.
Would you mind also adding yourself to MAINTAINERS for this driver? I
would appreciate it.
Sure. I'm hoping this driver won't cause that much maintenance overhead
anyway since all the complicated stuff is in i2c-algo-bit. But I agree
it needs a maintainer.
Haavard
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Mon, 12 Mar 2007 18:07:59 +0800
Wu, Bryan [EMAIL PROTECTED] wrote:
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
Is this usage right, because 3 flags are added to this structure as
below:
struct i2c_gpio_platform_data {
unsigned int sda_pin;
unsigned int scl_pin;
unsigned int sda_is_open_drain:1;
unsigned int scl_is_open_drain:1;
unsigned int scl_is_output_only:1;
};
Well, it is the simplest possible example. The last 3 fields will be 0,
which is a valid configuration.
Thanks a lot, I will drop our GPIO based I2C driver and try this one on
our platform.
I hope it works for you.
+ if (!pdata-scl_is_output_only)
+ bit_data-getscl = i2c_gpio_getscl,
+
+ bit_data-getsda= i2c_gpio_getsda,
+ bit_data-udelay= 5,/* 100 kHz */
+ bit_data-timeout = HZ / 10, /* 100 ms */
Can we add these udelay/timeout to struct i2c_gpio_platform_data? And
let customer to choose these according their specific requirement. We
use Kconfig to do this, but Jean and David don't like the idea, -:(
Yeah, they need to be a bit more configurable than they currently are.
And I think it makes sense to pass them from the board setup code, since
this is where things depending on board-specific details (signal quality
issues, pullup resistor values, etc.) are supposed to go.
Haavard
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Mon, 12 Mar 2007 15:34:57 +0100 Haavard Skinnemoen [EMAIL PROTECTED] wrote: + bit_data-udelay= 5,/* 100 kHz */ + bit_data-timeout = HZ / 10, /* 100 ms */ Can we add these udelay/timeout to struct i2c_gpio_platform_data? And let customer to choose these according their specific requirement. We use Kconfig to do this, but Jean and David don't like the idea, -:( Yeah, they need to be a bit more configurable than they currently are. And I think it makes sense to pass them from the board setup code, since this is where things depending on board-specific details (signal quality issues, pullup resistor values, etc.) are supposed to go. By the way, timeout seems to be hardcoded to 100 jiffies in the i2c-algo-bit driver, so there's probably not much point passing it from the board code when it's going to be overridden anyway. I'll add just a udelay parameter to the platform struct for now. Haavard - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
Hi Haavard, On Mon, 12 Mar 2007 15:53:59 +0100, Haavard Skinnemoen wrote: On Mon, 12 Mar 2007 15:34:57 +0100 Haavard Skinnemoen [EMAIL PROTECTED] wrote: + bit_data-udelay= 5,/* 100 kHz */ + bit_data-timeout = HZ / 10, /* 100 ms */ Can we add these udelay/timeout to struct i2c_gpio_platform_data? And let customer to choose these according their specific requirement. We use Kconfig to do this, but Jean and David don't like the idea, -:( Yeah, they need to be a bit more configurable than they currently are. And I think it makes sense to pass them from the board setup code, since this is where things depending on board-specific details (signal quality issues, pullup resistor values, etc.) are supposed to go. By the way, timeout seems to be hardcoded to 100 jiffies in the i2c-algo-bit driver, so there's probably not much point passing it from the board code when it's going to be overridden anyway. I'll add just a udelay parameter to the platform struct for now. No, it's not hardcoded. I know it looks confusing. struct i2c_adapter has a timeout field, that's the one being set to 100 in i2c-algo-bit, but i2c-algo-bit uses the i2c_algo_bit_data timeout field. The i2c_adapter timeout field is unused. This is clearly calling for a cleanup but I don't have time for this right now. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Mon, 12 Mar 2007 16:11:09 +0100 Jean Delvare [EMAIL PROTECTED] wrote: By the way, timeout seems to be hardcoded to 100 jiffies in the i2c-algo-bit driver, so there's probably not much point passing it from the board code when it's going to be overridden anyway. I'll add just a udelay parameter to the platform struct for now. No, it's not hardcoded. I know it looks confusing. struct i2c_adapter has a timeout field, that's the one being set to 100 in i2c-algo-bit, but i2c-algo-bit uses the i2c_algo_bit_data timeout field. The i2c_adapter timeout field is unused. Ah, I see. Now that you mention it, I seem to recall I came to that conclusion last time I looked at the code, but I've apparently forgotten it since then ;) I'll add a timeout field to the platform struct as well, then. Haavard - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Sat, 2007-03-10 at 14:13 +0100, Haavard Skinnemoen wrote:
> This is a very simple bitbanging i2c bus driver utilizing the new
> arch-neutral GPIO API. Useful for chips that don't have a built-in
> i2c controller, additional i2c busses, or testing purposes.
>
Sorry for missing this hot discussion. Your idea is exactly what I want.
So many arch specific GPIO based I2C adapter implementation will benefit
from this.
> To use, include something similar to the following in the
> board-specific setup code:
>
> #include
>
> static struct i2c_gpio_platform_data i2c_gpio_data = {
> .sda_pin= GPIO_PIN_FOO,
> .scl_pin= GPIO_PIN_BAR,
> };
Is this usage right, because 3 flags are added to this structure as
below:
struct i2c_gpio_platform_data {
unsigned int sda_pin;
unsigned int scl_pin;
unsigned int sda_is_open_drain:1;
unsigned int scl_is_open_drain:1;
unsigned int scl_is_output_only:1;
};
> static struct platform_device i2c_gpio_device = {
> .name = "i2c-gpio",
> .id = 0,
> .dev= {
> .platform_data = _gpio_data,
> },
> };
>
> Register this platform_device, set up the i2c pins as GPIO if
> required and you're ready to go.
>
> Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
> ---
> This patch is different from the first patch in the following ways:
> * Handles pins set up as open drain (aka multidrive) by toggling
> the output value instead of the direction
> * Handles output-only SCL pins the same way, and also does not
> install a getscl() callback for such pins
> * Does not add anything to include/linux/i2c-ids.h
> * Sets the output value explicitly after changing the direction to
> output.
> * Plugs a memory leak in remove() -- algo_data wasn't freed.
> * Prints out the pin IDs in decimal, with an extra note when clock
> stretching isn't supported
>
> This version has been compile-tested only. I'll give it a spin when I
> get back to work on monday.
>
> Dave, does this address your concerns?
>
> Haavard
Thanks a lot, I will drop our GPIO based I2C driver and try this one on
our platform.
> + if (!pdata->scl_is_output_only)
> + bit_data->getscl = i2c_gpio_getscl,
> +
> + bit_data->getsda= i2c_gpio_getsda,
> + bit_data->udelay= 5,/* 100 kHz */
> + bit_data->timeout = HZ / 10, /* 100 ms */
Can we add these udelay/timeout to struct i2c_gpio_platform_data? And
let customer to choose these according their specific requirement. We
use Kconfig to do this, but Jean and David don't like the idea, -:(
Regards,
-Bryan Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Sat, 2007-03-10 at 14:13 +0100, Haavard Skinnemoen wrote:
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
Sorry for missing this hot discussion. Your idea is exactly what I want.
So many arch specific GPIO based I2C adapter implementation will benefit
from this.
To use, include something similar to the following in the
board-specific setup code:
#include linux/i2c-gpio.h
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
Is this usage right, because 3 flags are added to this structure as
below:
struct i2c_gpio_platform_data {
unsigned int sda_pin;
unsigned int scl_pin;
unsigned int sda_is_open_drain:1;
unsigned int scl_is_open_drain:1;
unsigned int scl_is_output_only:1;
};
static struct platform_device i2c_gpio_device = {
.name = i2c-gpio,
.id = 0,
.dev= {
.platform_data = i2c_gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
This patch is different from the first patch in the following ways:
* Handles pins set up as open drain (aka multidrive) by toggling
the output value instead of the direction
* Handles output-only SCL pins the same way, and also does not
install a getscl() callback for such pins
* Does not add anything to include/linux/i2c-ids.h
* Sets the output value explicitly after changing the direction to
output.
* Plugs a memory leak in remove() -- algo_data wasn't freed.
* Prints out the pin IDs in decimal, with an extra note when clock
stretching isn't supported
This version has been compile-tested only. I'll give it a spin when I
get back to work on monday.
Dave, does this address your concerns?
Haavard
Thanks a lot, I will drop our GPIO based I2C driver and try this one on
our platform.
+ if (!pdata-scl_is_output_only)
+ bit_data-getscl = i2c_gpio_getscl,
+
+ bit_data-getsda= i2c_gpio_getsda,
+ bit_data-udelay= 5,/* 100 kHz */
+ bit_data-timeout = HZ / 10, /* 100 ms */
Can we add these udelay/timeout to struct i2c_gpio_platform_data? And
let customer to choose these according their specific requirement. We
use Kconfig to do this, but Jean and David don't like the idea, -:(
Regards,
-Bryan Wu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Saturday 10 March 2007 5:13 am, Haavard Skinnemoen wrote: > This is a very simple bitbanging i2c bus driver utilizing the new > arch-neutral GPIO API. ... > --- > This patch is different from the first patch in the following ways: > * Handles pins set up as open drain (aka multidrive) by toggling > the output value instead of the direction > * Handles output-only SCL pins the same way, and also does not > install a getscl() callback for such pins > * Does not add anything to include/linux/i2c-ids.h > * Sets the output value explicitly after changing the direction to > output. > * Plugs a memory leak in remove() -- algo_data wasn't freed. > * Prints out the pin IDs in decimal, with an extra note when clock > stretching isn't supported > > This version has been compile-tested only. I'll give it a spin when I > get back to work on monday. > > Dave, does this address your concerns? Yes, though see my followup to Jean's note. Unless I make time to test this out on some system, the issues seem to be: (a) will need to change once gpio_direction_output() gains that second argument; (b) i2c-gpio.h could stand one minor comment addition to highlight an assumption. Looking good! - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Saturday 10 March 2007 12:15 pm, Jean Delvare wrote: > Hi Haavard, > > On Sat, 10 Mar 2007 14:13:28 +0100, Haavard Skinnemoen wrote: > > This is a very simple bitbanging i2c bus driver utilizing the new > > arch-neutral GPIO API. Useful for chips that don't have a built-in > > i2c controller, additional i2c busses, or testing purposes. This updated version looks a lot better. However it doesn't address the API change -- gpio_direction_output(gpio, initial_value) -- which is understandable since that patch hasn't yet merged. > I like the idea very much. Would this let us get rid of i2c-ixp2000? > i2c-ixp4xx? scx200_i2c? Other drivers? There's CONFIG_GENERIC_GPIO support for ixp4xx (nyet upstream, ISTR it's waiting on the gpio_direction_output update), so that one should be particularly easy to replace. Presumably some other bitbang drivers could vanish before long too. > What value will you get if the SDA pin is open-drain and currently in > output mode? For output GPIOs, gpio_get_value() is specified to either return the actual value at the pin ... or zero, if the hardware can't do that. Most GPIO pins *can* do that. (Specifically, that's how AT91 GPIOs work, open drain or otherwise.) (However, there can be various latencies involved. On one chip when I wrote the output value, then immediately read it back, I got the old value. Reason: the GPIO controller clock needed to tick first in order to latch the new input value! It was only about 30 MHz, so the back-to-back instructions were too fast. You can also sometimes notice capacitance causing similar delays. Of course those latencies apply regardless of pin direction.) I think Haavard is assuming the GPIO actually returns that value, since otherwise there'd be no point in trying to use the open drain mode. It'd be worth capturing that in the i2c-gpio.h definition for that struct. > Are such GPIO pins actually able to detect that the pin is > low while they are not themselves driving it low? Given a "yes" to the above, then clearly "yes" here too. As I noted, if it can't actually sense the value at the pin, that function should always return zero. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
Hi Haavard,
On Sat, 10 Mar 2007 14:13:28 +0100, Haavard Skinnemoen wrote:
> This is a very simple bitbanging i2c bus driver utilizing the new
> arch-neutral GPIO API. Useful for chips that don't have a built-in
> i2c controller, additional i2c busses, or testing purposes.
>
> To use, include something similar to the following in the
> board-specific setup code:
>
> #include
>
> static struct i2c_gpio_platform_data i2c_gpio_data = {
> .sda_pin= GPIO_PIN_FOO,
> .scl_pin= GPIO_PIN_BAR,
> };
> static struct platform_device i2c_gpio_device = {
> .name = "i2c-gpio",
> .id = 0,
> .dev= {
> .platform_data = _gpio_data,
> },
> };
>
> Register this platform_device, set up the i2c pins as GPIO if
> required and you're ready to go.
I like the idea very much. Would this let us get rid of i2c-ixp2000?
i2c-ixp4xx? scx200_i2c? Other drivers?
> drivers/i2c/busses/Kconfig|8 ++
> drivers/i2c/busses/Makefile |1 +
> drivers/i2c/busses/i2c-gpio.c | 211
> +
> include/linux/i2c-gpio.h | 30 ++
> 4 files changed, 250 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index fb19dbb..52f79d1 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -102,6 +102,14 @@ config I2C_ELEKTOR
> This support is also available as a module. If so, the module
> will be called i2c-elektor.
>
> +config I2C_GPIO
> + tristate "GPIO-based bitbanging i2c driver"
> + depends on I2C && GENERIC_GPIO
> + select I2C_ALGOBIT
> + help
> + This is a very simple bitbanging i2c driver utilizing the
> + arch-neutral GPIO API to control the SCL and SDA lines.
> +
> config I2C_HYDRA
> tristate "CHRP Apple Hydra Mac I/O I2C interface"
> depends on I2C && PCI && PPC_CHRP && EXPERIMENTAL
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 290b540..68f2b05 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
> obj-$(CONFIG_I2C_AT91) += i2c-at91.o
> obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
> obj-$(CONFIG_I2C_ELEKTOR)+= i2c-elektor.o
> +obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
> obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o
> obj-$(CONFIG_I2C_I801) += i2c-i801.o
> obj-$(CONFIG_I2C_I810) += i2c-i810.o
> diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
> new file mode 100644
> index 000..423db0a
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-gpio.c
> @@ -0,0 +1,211 @@
> +/*
> + * Bitbanging i2c bus driver using the GPIO API
> + *
> + * Copyright (C) 2006 Atmel Corporation
I'm told we're in year 2007 ;)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/* Toggle SDA by changing the direction of the pin */
> +static void i2c_gpio_setsda_dir(void *data, int state)
> +{
> + struct i2c_gpio_platform_data *pdata = data;
> +
> + if (state)
> + gpio_direction_input(pdata->sda_pin);
> + else {
> + gpio_direction_output(pdata->sda_pin);
> + gpio_set_value(pdata->sda_pin, 0);
> + }
> +}
> +
> +/*
> + * Toggle SDA by changing the output value of the pin. This is only
> + * valid for pins configured as open drain (i.e. setting the value
> + * high effectively turns off the output driver.)
> + */
> +static void i2c_gpio_setsda_val(void *data, int state)
> +{
> + struct i2c_gpio_platform_data *pdata = data;
> +
> + gpio_set_value(pdata->sda_pin, state);
> +}
> +
> +/* Toggle SCL by changing the direction of the pin. */
> +static void i2c_gpio_setscl_dir(void *data, int state)
> +{
> + struct i2c_gpio_platform_data *pdata = data;
> +
> + if (state)
> + gpio_direction_input(pdata->scl_pin);
> + else {
> + gpio_direction_output(pdata->scl_pin);
> + gpio_set_value(pdata->scl_pin, 0);
> + }
> +}
> +
> +/*
> + * Toggle SCL by changing the output value of the pin. This is used
> + * for pins that are configured as open drain an
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Fri, 9 Mar 2007 11:30:12 -0800, David Brownell wrote: > > --- a/include/linux/i2c-id.h > > +++ b/include/linux/i2c-id.h > > @@ -194,6 +194,7 @@ > > #define I2C_HW_B_EM28XX0x01001f /* em28xx video capture cards > > */ > > #define I2C_HW_B_CX2341X 0x010020 /* Conexant CX2341X MPEG encoder cards > > */ > > #define I2C_HW_B_INTELFB 0x010021 /* intel framebuffer driver */ > > +#define I2C_HW_B_GPIO 0x010022 /* Generic GPIO-based driver */ > > It'd be nice to completely abolish those IDs, starting by not > adding new ones. Especially, not adding unused ones! I'm confident that we'll be able to get rid of the I2C device driver IDs pretty soon thanks to your new i2c-core model, but I'm not sure if we'll be able to get rid of I2C adapter drivers IDs that quickly. But I agree with you, please let's not add new unused IDs. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Bitbanging i2c bus driver using the GPIO API
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
To use, include something similar to the following in the
board-specific setup code:
#include
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
static struct platform_device i2c_gpio_device = {
.name = "i2c-gpio",
.id = 0,
.dev= {
.platform_data = _gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
This patch is different from the first patch in the following ways:
* Handles pins set up as open drain (aka multidrive) by toggling
the output value instead of the direction
* Handles output-only SCL pins the same way, and also does not
install a getscl() callback for such pins
* Does not add anything to include/linux/i2c-ids.h
* Sets the output value explicitly after changing the direction to
output.
* Plugs a memory leak in remove() -- algo_data wasn't freed.
* Prints out the pin IDs in decimal, with an extra note when clock
stretching isn't supported
This version has been compile-tested only. I'll give it a spin when I
get back to work on monday.
Dave, does this address your concerns?
Haavard
drivers/i2c/busses/Kconfig|8 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-gpio.c | 211 +
include/linux/i2c-gpio.h | 30 ++
4 files changed, 250 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
This support is also available as a module. If so, the module
will be called i2c-elektor.
+config I2C_GPIO
+ tristate "GPIO-based bitbanging i2c driver"
+ depends on I2C && GENERIC_GPIO
+ select I2C_ALGOBIT
+ help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
config I2C_HYDRA
tristate "CHRP Apple Hydra Mac I/O I2C interface"
depends on I2C && PCI && PPC_CHRP && EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HYDRA)+= i2c-hydra.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..423db0a
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,211 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* Toggle SDA by changing the direction of the pin */
+static void i2c_gpio_setsda_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata->sda_pin);
+ else {
+ gpio_direction_output(pdata->sda_pin);
+ gpio_set_value(pdata->sda_pin, 0);
+ }
+}
+
+/*
+ * Toggle SDA by changing the output value of the pin. This is only
+ * valid for pins configured as open drain (i.e. setting the value
+ * high effectively turns off the output driver.)
+ */
+static void i2c_gpio_setsda_val(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ gpio_set_value(pdata->sda_pin, state);
+}
+
+/* Toggle SCL by changing the direction of the pin. */
+static void i2c_gpio_setscl_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata->scl_pin);
+ else {
+ gpio_direction_output(pdata->scl_pin);
+ gpio_set_value(pdata->scl_pin, 0);
+ }
+}
+
+/*
+ * Toggle SCL by changing the output value of the pin. This is used
+ * for pins that are configure
[PATCH v2] Bitbanging i2c bus driver using the GPIO API
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
To use, include something similar to the following in the
board-specific setup code:
#include linux/i2c-gpio.h
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
static struct platform_device i2c_gpio_device = {
.name = i2c-gpio,
.id = 0,
.dev= {
.platform_data = i2c_gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
This patch is different from the first patch in the following ways:
* Handles pins set up as open drain (aka multidrive) by toggling
the output value instead of the direction
* Handles output-only SCL pins the same way, and also does not
install a getscl() callback for such pins
* Does not add anything to include/linux/i2c-ids.h
* Sets the output value explicitly after changing the direction to
output.
* Plugs a memory leak in remove() -- algo_data wasn't freed.
* Prints out the pin IDs in decimal, with an extra note when clock
stretching isn't supported
This version has been compile-tested only. I'll give it a spin when I
get back to work on monday.
Dave, does this address your concerns?
Haavard
drivers/i2c/busses/Kconfig|8 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-gpio.c | 211 +
include/linux/i2c-gpio.h | 30 ++
4 files changed, 250 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
This support is also available as a module. If so, the module
will be called i2c-elektor.
+config I2C_GPIO
+ tristate GPIO-based bitbanging i2c driver
+ depends on I2C GENERIC_GPIO
+ select I2C_ALGOBIT
+ help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
config I2C_HYDRA
tristate CHRP Apple Hydra Mac I/O I2C interface
depends on I2C PCI PPC_CHRP EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HYDRA)+= i2c-hydra.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..423db0a
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,211 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/i2c.h
+#include linux/i2c-algo-bit.h
+#include linux/i2c-gpio.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+
+#include asm/gpio.h
+
+/* Toggle SDA by changing the direction of the pin */
+static void i2c_gpio_setsda_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata-sda_pin);
+ else {
+ gpio_direction_output(pdata-sda_pin);
+ gpio_set_value(pdata-sda_pin, 0);
+ }
+}
+
+/*
+ * Toggle SDA by changing the output value of the pin. This is only
+ * valid for pins configured as open drain (i.e. setting the value
+ * high effectively turns off the output driver.)
+ */
+static void i2c_gpio_setsda_val(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ gpio_set_value(pdata-sda_pin, state);
+}
+
+/* Toggle SCL by changing the direction of the pin. */
+static void i2c_gpio_setscl_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata-scl_pin);
+ else {
+ gpio_direction_output(pdata-scl_pin);
+ gpio_set_value(pdata-scl_pin, 0);
+ }
+}
+
+/*
+ * Toggle SCL by changing the output value of the pin. This is used
+ * for pins that are configured
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Fri, 9 Mar 2007 11:30:12 -0800, David Brownell wrote: --- a/include/linux/i2c-id.h +++ b/include/linux/i2c-id.h @@ -194,6 +194,7 @@ #define I2C_HW_B_EM28XX0x01001f /* em28xx video capture cards */ #define I2C_HW_B_CX2341X 0x010020 /* Conexant CX2341X MPEG encoder cards */ #define I2C_HW_B_INTELFB 0x010021 /* intel framebuffer driver */ +#define I2C_HW_B_GPIO 0x010022 /* Generic GPIO-based driver */ It'd be nice to completely abolish those IDs, starting by not adding new ones. Especially, not adding unused ones! I'm confident that we'll be able to get rid of the I2C device driver IDs pretty soon thanks to your new i2c-core model, but I'm not sure if we'll be able to get rid of I2C adapter drivers IDs that quickly. But I agree with you, please let's not add new unused IDs. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
Hi Haavard,
On Sat, 10 Mar 2007 14:13:28 +0100, Haavard Skinnemoen wrote:
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
To use, include something similar to the following in the
board-specific setup code:
#include linux/i2c-gpio.h
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
static struct platform_device i2c_gpio_device = {
.name = i2c-gpio,
.id = 0,
.dev= {
.platform_data = i2c_gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go.
I like the idea very much. Would this let us get rid of i2c-ixp2000?
i2c-ixp4xx? scx200_i2c? Other drivers?
drivers/i2c/busses/Kconfig|8 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-gpio.c | 211
+
include/linux/i2c-gpio.h | 30 ++
4 files changed, 250 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
This support is also available as a module. If so, the module
will be called i2c-elektor.
+config I2C_GPIO
+ tristate GPIO-based bitbanging i2c driver
+ depends on I2C GENERIC_GPIO
+ select I2C_ALGOBIT
+ help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
config I2C_HYDRA
tristate CHRP Apple Hydra Mac I/O I2C interface
depends on I2C PCI PPC_CHRP EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_ELEKTOR)+= i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..423db0a
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,211 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2006 Atmel Corporation
I'm told we're in year 2007 ;)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/i2c.h
+#include linux/i2c-algo-bit.h
+#include linux/i2c-gpio.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+
+#include asm/gpio.h
+
+/* Toggle SDA by changing the direction of the pin */
+static void i2c_gpio_setsda_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata-sda_pin);
+ else {
+ gpio_direction_output(pdata-sda_pin);
+ gpio_set_value(pdata-sda_pin, 0);
+ }
+}
+
+/*
+ * Toggle SDA by changing the output value of the pin. This is only
+ * valid for pins configured as open drain (i.e. setting the value
+ * high effectively turns off the output driver.)
+ */
+static void i2c_gpio_setsda_val(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ gpio_set_value(pdata-sda_pin, state);
+}
+
+/* Toggle SCL by changing the direction of the pin. */
+static void i2c_gpio_setscl_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata-scl_pin);
+ else {
+ gpio_direction_output(pdata-scl_pin);
+ gpio_set_value(pdata-scl_pin, 0);
+ }
+}
+
+/*
+ * Toggle SCL by changing the output value of the pin. This is used
+ * for pins that are configured as open drain and for output-only
+ * pins. The latter case will break the i2c protocol, but it will
+ * often work in practice.
+ */
+static void i2c_gpio_setscl_val(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ gpio_set_value(pdata-scl_pin, state);
+}
+
+int i2c_gpio_getsda(void *data)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ return gpio_get_value(pdata-sda_pin);
+}
What value will you get if the SDA pin is open-drain
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Saturday 10 March 2007 5:13 am, Haavard Skinnemoen wrote: This is a very simple bitbanging i2c bus driver utilizing the new arch-neutral GPIO API. ... --- This patch is different from the first patch in the following ways: * Handles pins set up as open drain (aka multidrive) by toggling the output value instead of the direction * Handles output-only SCL pins the same way, and also does not install a getscl() callback for such pins * Does not add anything to include/linux/i2c-ids.h * Sets the output value explicitly after changing the direction to output. * Plugs a memory leak in remove() -- algo_data wasn't freed. * Prints out the pin IDs in decimal, with an extra note when clock stretching isn't supported This version has been compile-tested only. I'll give it a spin when I get back to work on monday. Dave, does this address your concerns? Yes, though see my followup to Jean's note. Unless I make time to test this out on some system, the issues seem to be: (a) will need to change once gpio_direction_output() gains that second argument; (b) i2c-gpio.h could stand one minor comment addition to highlight an assumption. Looking good! - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API
On Saturday 10 March 2007 12:15 pm, Jean Delvare wrote: Hi Haavard, On Sat, 10 Mar 2007 14:13:28 +0100, Haavard Skinnemoen wrote: This is a very simple bitbanging i2c bus driver utilizing the new arch-neutral GPIO API. Useful for chips that don't have a built-in i2c controller, additional i2c busses, or testing purposes. This updated version looks a lot better. However it doesn't address the API change -- gpio_direction_output(gpio, initial_value) -- which is understandable since that patch hasn't yet merged. I like the idea very much. Would this let us get rid of i2c-ixp2000? i2c-ixp4xx? scx200_i2c? Other drivers? There's CONFIG_GENERIC_GPIO support for ixp4xx (nyet upstream, ISTR it's waiting on the gpio_direction_output update), so that one should be particularly easy to replace. Presumably some other bitbang drivers could vanish before long too. What value will you get if the SDA pin is open-drain and currently in output mode? For output GPIOs, gpio_get_value() is specified to either return the actual value at the pin ... or zero, if the hardware can't do that. Most GPIO pins *can* do that. (Specifically, that's how AT91 GPIOs work, open drain or otherwise.) (However, there can be various latencies involved. On one chip when I wrote the output value, then immediately read it back, I got the old value. Reason: the GPIO controller clock needed to tick first in order to latch the new input value! It was only about 30 MHz, so the back-to-back instructions were too fast. You can also sometimes notice capacitance causing similar delays. Of course those latencies apply regardless of pin direction.) I think Haavard is assuming the GPIO actually returns that value, since otherwise there'd be no point in trying to use the open drain mode. It'd be worth capturing that in the i2c-gpio.h definition for that struct. Are such GPIO pins actually able to detect that the pin is low while they are not themselves driving it low? Given a yes to the above, then clearly yes here too. As I noted, if it can't actually sense the value at the pin, that function should always return zero. - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Friday 09 March 2007 12:43 pm, Håvard Skinnemoen wrote: > On Fri, March 9, 2007 20:30, David Brownell wrote: > > On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: > >> This is a very simple bitbanging i2c bus driver utilizing the new > >> arch-neutral GPIO API. Useful for chips that don't have a built-in > >> i2c controller, additional i2c busses, or testing purposes. > > > > That's the right idea! But remember that not all GPIOs support > > reading back the actual value on SCL ... > > The idea is to keep the output value at 0 and switch the output driver on > and off. I assumed that changing the direction was the easiest way to > achieve this. > > I never really thought about output-only pins. Is it actually possible to > implement i2c properly on such hardware? Not strictly; but folk do so, and the results are compatible-enough for many purposes. Certainly a quick glance at i2c-algo-bit tells me that it knows how to cope with output-only SCL. A generic GPIO driver "should" be able to at least act sanely given such a pin. > > I2C has another interesting special case. at91_set_multi_drive() > > would be appropriate (yes?) for ARCH_AT91 to use on SCL, to best > > support both clock stretching and multi-master configurations. > > Isn't it better to switch the direction to input since the driver needs to > watch the pin state in order to support clock stretching and multi-master? Not necessarily ... reading the GPIO pad state works regardless of what direction was configured on most chips (including AT91 and AVR32), but not all of them. Certainly multi-drive/open-drain outputs get the electical stuff right without that. Russell's explanation says the reason to switch direction is to disable the non-open-drain output drivers. There are several options lurking, that a generic I2C bitbanger "ought" to handle. Existence of open-drain outputs is one issue. Ability to change direction is another; as is ability to read the value on output pads. Your code assumed one set of answers; others are possible. > The gpio_set_value() calls should go away and the output value should be > explicitly set to 0 when turning on the output drivers. In its present > form, the driver happens to work on my hardware, which is all I really > cared about when writing it ;-) As I said in a different way above! If open drain outputs are available, and the actual values can be read on output pins, then I think both pins can be configured as outputs and left that way. > >> + printk(KERN_INFO "i2c-gpio: using pins 0x%x (sda) 0x%x (scl)\n", > >> + pdata->sda_pin, pdata->scl_pin); > > > > Please, no hex there. I think dev_info() would be better; and it > > might be nice to report whether clock stretching is supported. > > Ok, but how do I inform i2c-algo-bit about whether or not clock stretching > is supported? Reading the code, I see it's automatic if you don't provide getscl()... - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Friday 09 March 2007 12:08 pm, Russell King wrote: > On Fri, Mar 09, 2007 at 11:30:12AM -0800, David Brownell wrote: > > On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: > > > This is a very simple bitbanging i2c bus driver utilizing the new > > > arch-neutral GPIO API. Useful for chips that don't have a built-in > > > i2c controller, additional i2c busses, or testing purposes. > > > > That's the right idea! But remember that not all GPIOs support > > reading back the actual value on SCL (it's an OUT pin, so lacking > > multidrive capability the values "should" be what you wrote), so > > getscl() support should depend on a flag in platform data. In > > the same vein, if SCL is an output-only pin, you won't be able > > to change its direction ... but then, I'm not sure why you were > > changing its direction in setscl() rather than just its value. > > That's a more correct I2C implementation. If you read the specs, the > SDA and SCL signals are supposed to be driven by open-collector or > open-drain drivers, such that devices only pull the bus low. Pull-up > resistors pull the signals high when undriven. Exactly as I had mentioned: > > I2C has another interesting special case. at91_set_multi_drive() > > would be appropriate (yes?) for ARCH_AT91 to use on SCL, to best > > support both clock stretching and multi-master configurations. Where "multi-drive" == open-drain. You're saying it should also be used on SDA too ... OK, I was focussing on clock stretching but it applies there too. > This avoids the possibility of damage caused when one device drives > a signal low and another device tries to drive it high. > > Therefore, the correct I2C GPIO implementation is one where you drive > both SDA and SCL low by using a combination of the data direction > register and the output level register, but avoid driving the output > high. I see your point -- it does answer my question -- but you seem to have overlooked a highly relevant one of mine. :) Regardless, those nuances should be captured in comments in that driver: that for GPIOs that don't support open drain output (only push/pull drivers), that it's faked by otherwise-unnecessary tweaking of GPIO direction. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Fri, March 9, 2007 20:30, David Brownell wrote: > On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: >> This is a very simple bitbanging i2c bus driver utilizing the new >> arch-neutral GPIO API. Useful for chips that don't have a built-in >> i2c controller, additional i2c busses, or testing purposes. > > That's the right idea! But remember that not all GPIOs support > reading back the actual value on SCL (it's an OUT pin, so lacking > multidrive capability the values "should" be what you wrote), so > getscl() support should depend on a flag in platform data. In > the same vein, if SCL is an output-only pin, you won't be able > to change its direction ... but then, I'm not sure why you were > changing its direction in setscl() rather than just its value. The idea is to keep the output value at 0 and switch the output driver on and off. I assumed that changing the direction was the easiest way to achieve this. I never really thought about output-only pins. Is it actually possible to implement i2c properly on such hardware? > I2C has another interesting special case. at91_set_multi_drive() > would be appropriate (yes?) for ARCH_AT91 to use on SCL, to best > support both clock stretching and multi-master configurations. Isn't it better to switch the direction to input since the driver needs to watch the pin state in order to support clock stretching and multi-master? >> +gpio_direction_input(pdata->sda_pin); >> +gpio_direction_input(pdata->scl_pin); >> +gpio_set_value(pdata->sda_pin, 0); >> +gpio_set_value(pdata->scl_pin, 0); > > Surely you mean "output" in both cases. So you can set the > value. Setting the value on an input pin is undefined. ;) No I really do mean input, as I want to put the bus into an idle state initially, which means no output drivers and passive pullup on both lines. The gpio_set_value() calls should go away and the output value should be explicitly set to 0 when turning on the output drivers. In its present form, the driver happens to work on my hardware, which is all I really cared about when writing it ;-) >> +printk(KERN_INFO "i2c-gpio: using pins 0x%x (sda) 0x%x (scl)\n", >> + pdata->sda_pin, pdata->scl_pin); > > Please, no hex there. I think dev_info() would be better; and it > might be nice to report whether clock stretching is supported. Ok, but how do I inform i2c-algo-bit about whether or not clock stretching is supported? >> --- a/include/linux/i2c-id.h >> +++ b/include/linux/i2c-id.h >> @@ -194,6 +194,7 @@ >> #define I2C_HW_B_EM28XX 0x01001f /* em28xx video capture cards >> */ >> #define I2C_HW_B_CX2341X0x010020 /* Conexant CX2341X MPEG encoder >> cards */ >> #define I2C_HW_B_INTELFB0x010021 /* intel framebuffer driver */ >> +#define I2C_HW_B_GPIO 0x010022 /* Generic GPIO-based driver */ > > It'd be nice to completely abolish those IDs, starting by not > adding new ones. Especially, not adding unused ones! Sure. Haavard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Fri, Mar 09, 2007 at 11:30:12AM -0800, David Brownell wrote: > On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: > > This is a very simple bitbanging i2c bus driver utilizing the new > > arch-neutral GPIO API. Useful for chips that don't have a built-in > > i2c controller, additional i2c busses, or testing purposes. > > That's the right idea! But remember that not all GPIOs support > reading back the actual value on SCL (it's an OUT pin, so lacking > multidrive capability the values "should" be what you wrote), so > getscl() support should depend on a flag in platform data. In > the same vein, if SCL is an output-only pin, you won't be able > to change its direction ... but then, I'm not sure why you were > changing its direction in setscl() rather than just its value. That's a more correct I2C implementation. If you read the specs, the SDA and SCL signals are supposed to be driven by open-collector or open-drain drivers, such that devices only pull the bus low. Pull-up resistors pull the signals high when undriven. This avoids the possibility of damage caused when one device drives a signal low and another device tries to drive it high. Therefore, the correct I2C GPIO implementation is one where you drive both SDA and SCL low by using a combination of the data direction register and the output level register, but avoid driving the output high. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: > This is a very simple bitbanging i2c bus driver utilizing the new > arch-neutral GPIO API. Useful for chips that don't have a built-in > i2c controller, additional i2c busses, or testing purposes. That's the right idea! But remember that not all GPIOs support reading back the actual value on SCL (it's an OUT pin, so lacking multidrive capability the values "should" be what you wrote), so getscl() support should depend on a flag in platform data. In the same vein, if SCL is an output-only pin, you won't be able to change its direction ... but then, I'm not sure why you were changing its direction in setscl() rather than just its value. I2C has another interesting special case. at91_set_multi_drive() would be appropriate (yes?) for ARCH_AT91 to use on SCL, to best support both clock stretching and multi-master configurations. > + gpio_direction_input(pdata->sda_pin); > + gpio_direction_input(pdata->scl_pin); > + gpio_set_value(pdata->sda_pin, 0); > + gpio_set_value(pdata->scl_pin, 0); Surely you mean "output" in both cases. So you can set the value. Setting the value on an input pin is undefined. ;) > + printk(KERN_INFO "i2c-gpio: using pins 0x%x (sda) 0x%x (scl)\n", > +pdata->sda_pin, pdata->scl_pin); Please, no hex there. I think dev_info() would be better; and it might be nice to report whether clock stretching is supported. > --- a/include/linux/i2c-id.h > +++ b/include/linux/i2c-id.h > @@ -194,6 +194,7 @@ > #define I2C_HW_B_EM28XX 0x01001f /* em28xx video capture cards > */ > #define I2C_HW_B_CX2341X 0x010020 /* Conexant CX2341X MPEG encoder cards > */ > #define I2C_HW_B_INTELFB 0x010021 /* intel framebuffer driver */ > +#define I2C_HW_B_GPIO0x010022 /* Generic GPIO-based driver */ It'd be nice to completely abolish those IDs, starting by not adding new ones. Especially, not adding unused ones! - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Bitbanging i2c bus driver using the GPIO API
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
To use, include something similar to the following in the
board-specific setup code:
#include
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
static struct platform_device i2c_gpio_device = {
.name = "i2c-gpio",
.id = 0,
.dev= {
.platform_data = _gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
I wrote this driver for testing purposes a couple of weeks ago.
Figured I might as well post it since it looks like something like
this is needed.
This driver hasn't yet been updated for the latest change to the GPIO
API. I'll update the patch when the GPIO change makes it into
mainline.
Haavard
drivers/i2c/busses/Kconfig|8 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-gpio.c | 164 +
include/linux/i2c-gpio.h | 18 +
include/linux/i2c-id.h|1 +
5 files changed, 192 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
This support is also available as a module. If so, the module
will be called i2c-elektor.
+config I2C_GPIO
+ tristate "GPIO-based bitbanging i2c driver"
+ depends on I2C && GENERIC_GPIO
+ select I2C_ALGOBIT
+ help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
config I2C_HYDRA
tristate "CHRP Apple Hydra Mac I/O I2C interface"
depends on I2C && PCI && PPC_CHRP && EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HYDRA)+= i2c-hydra.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..f5ed64e
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,164 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+void i2c_gpio_setsda(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata->sda_pin);
+ else
+ gpio_direction_output(pdata->sda_pin);
+}
+
+void i2c_gpio_setscl(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata->scl_pin);
+ else
+ gpio_direction_output(pdata->scl_pin);
+}
+
+int i2c_gpio_getsda(void *data)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ return gpio_get_value(pdata->sda_pin);
+}
+
+int i2c_gpio_getscl(void *data)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ return gpio_get_value(pdata->scl_pin);
+}
+
+static int __init i2c_gpio_probe(struct platform_device *pdev)
+{
+ struct i2c_gpio_platform_data *pdata;
+ struct i2c_algo_bit_data *bit_data;
+ struct i2c_adapter *adap;
+ int ret;
+
+ pdata = pdev->dev.platform_data;
+ if (!pdata)
+ return -ENXIO;
+
+ ret = -ENOMEM;
+ adap = kzalloc(sizeof(struct i2c_adapter), GFP_KERNEL);
+ if (!adap)
+ goto err_alloc_adap;
+ bit_data = kzalloc(sizeof(struct i2c_algo_bit_data), GFP_KERNEL);
+ if (!bit_data)
+ goto err_alloc_bit_data;
+
+ ret = gpio_request(pdata->sda_pin, "sda");
+ if (ret)
+ goto err_request_sda;
+ ret = gpio_request(pdata->scl_pin, "scl");
+ if (ret)
+ goto err_request_scl;
+
+ gpio_dire
[PATCH] Bitbanging i2c bus driver using the GPIO API
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
To use, include something similar to the following in the
board-specific setup code:
#include linux/i2c-gpio.h
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
static struct platform_device i2c_gpio_device = {
.name = i2c-gpio,
.id = 0,
.dev= {
.platform_data = i2c_gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
I wrote this driver for testing purposes a couple of weeks ago.
Figured I might as well post it since it looks like something like
this is needed.
This driver hasn't yet been updated for the latest change to the GPIO
API. I'll update the patch when the GPIO change makes it into
mainline.
Haavard
drivers/i2c/busses/Kconfig|8 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-gpio.c | 164 +
include/linux/i2c-gpio.h | 18 +
include/linux/i2c-id.h|1 +
5 files changed, 192 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
This support is also available as a module. If so, the module
will be called i2c-elektor.
+config I2C_GPIO
+ tristate GPIO-based bitbanging i2c driver
+ depends on I2C GENERIC_GPIO
+ select I2C_ALGOBIT
+ help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
config I2C_HYDRA
tristate CHRP Apple Hydra Mac I/O I2C interface
depends on I2C PCI PPC_CHRP EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HYDRA)+= i2c-hydra.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..f5ed64e
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,164 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/i2c.h
+#include linux/i2c-algo-bit.h
+#include linux/i2c-gpio.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+
+#include asm/gpio.h
+
+void i2c_gpio_setsda(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata-sda_pin);
+ else
+ gpio_direction_output(pdata-sda_pin);
+}
+
+void i2c_gpio_setscl(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata-scl_pin);
+ else
+ gpio_direction_output(pdata-scl_pin);
+}
+
+int i2c_gpio_getsda(void *data)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ return gpio_get_value(pdata-sda_pin);
+}
+
+int i2c_gpio_getscl(void *data)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ return gpio_get_value(pdata-scl_pin);
+}
+
+static int __init i2c_gpio_probe(struct platform_device *pdev)
+{
+ struct i2c_gpio_platform_data *pdata;
+ struct i2c_algo_bit_data *bit_data;
+ struct i2c_adapter *adap;
+ int ret;
+
+ pdata = pdev-dev.platform_data;
+ if (!pdata)
+ return -ENXIO;
+
+ ret = -ENOMEM;
+ adap = kzalloc(sizeof(struct i2c_adapter), GFP_KERNEL);
+ if (!adap)
+ goto err_alloc_adap;
+ bit_data = kzalloc(sizeof(struct i2c_algo_bit_data), GFP_KERNEL);
+ if (!bit_data)
+ goto err_alloc_bit_data;
+
+ ret = gpio_request(pdata-sda_pin, sda);
+ if (ret)
+ goto err_request_sda;
+ ret = gpio_request(pdata-scl_pin, scl);
+ if (ret)
+ goto err_request_scl;
+
+ gpio_direction_input(pdata-sda_pin
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: This is a very simple bitbanging i2c bus driver utilizing the new arch-neutral GPIO API. Useful for chips that don't have a built-in i2c controller, additional i2c busses, or testing purposes. That's the right idea! But remember that not all GPIOs support reading back the actual value on SCL (it's an OUT pin, so lacking multidrive capability the values should be what you wrote), so getscl() support should depend on a flag in platform data. In the same vein, if SCL is an output-only pin, you won't be able to change its direction ... but then, I'm not sure why you were changing its direction in setscl() rather than just its value. I2C has another interesting special case. at91_set_multi_drive() would be appropriate (yes?) for ARCH_AT91 to use on SCL, to best support both clock stretching and multi-master configurations. + gpio_direction_input(pdata-sda_pin); + gpio_direction_input(pdata-scl_pin); + gpio_set_value(pdata-sda_pin, 0); + gpio_set_value(pdata-scl_pin, 0); Surely you mean output in both cases. So you can set the value. Setting the value on an input pin is undefined. ;) + printk(KERN_INFO i2c-gpio: using pins 0x%x (sda) 0x%x (scl)\n, +pdata-sda_pin, pdata-scl_pin); Please, no hex there. I think dev_info() would be better; and it might be nice to report whether clock stretching is supported. --- a/include/linux/i2c-id.h +++ b/include/linux/i2c-id.h @@ -194,6 +194,7 @@ #define I2C_HW_B_EM28XX 0x01001f /* em28xx video capture cards */ #define I2C_HW_B_CX2341X 0x010020 /* Conexant CX2341X MPEG encoder cards */ #define I2C_HW_B_INTELFB 0x010021 /* intel framebuffer driver */ +#define I2C_HW_B_GPIO0x010022 /* Generic GPIO-based driver */ It'd be nice to completely abolish those IDs, starting by not adding new ones. Especially, not adding unused ones! - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Fri, Mar 09, 2007 at 11:30:12AM -0800, David Brownell wrote: On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: This is a very simple bitbanging i2c bus driver utilizing the new arch-neutral GPIO API. Useful for chips that don't have a built-in i2c controller, additional i2c busses, or testing purposes. That's the right idea! But remember that not all GPIOs support reading back the actual value on SCL (it's an OUT pin, so lacking multidrive capability the values should be what you wrote), so getscl() support should depend on a flag in platform data. In the same vein, if SCL is an output-only pin, you won't be able to change its direction ... but then, I'm not sure why you were changing its direction in setscl() rather than just its value. That's a more correct I2C implementation. If you read the specs, the SDA and SCL signals are supposed to be driven by open-collector or open-drain drivers, such that devices only pull the bus low. Pull-up resistors pull the signals high when undriven. This avoids the possibility of damage caused when one device drives a signal low and another device tries to drive it high. Therefore, the correct I2C GPIO implementation is one where you drive both SDA and SCL low by using a combination of the data direction register and the output level register, but avoid driving the output high. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Fri, March 9, 2007 20:30, David Brownell wrote: On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: This is a very simple bitbanging i2c bus driver utilizing the new arch-neutral GPIO API. Useful for chips that don't have a built-in i2c controller, additional i2c busses, or testing purposes. That's the right idea! But remember that not all GPIOs support reading back the actual value on SCL (it's an OUT pin, so lacking multidrive capability the values should be what you wrote), so getscl() support should depend on a flag in platform data. In the same vein, if SCL is an output-only pin, you won't be able to change its direction ... but then, I'm not sure why you were changing its direction in setscl() rather than just its value. The idea is to keep the output value at 0 and switch the output driver on and off. I assumed that changing the direction was the easiest way to achieve this. I never really thought about output-only pins. Is it actually possible to implement i2c properly on such hardware? I2C has another interesting special case. at91_set_multi_drive() would be appropriate (yes?) for ARCH_AT91 to use on SCL, to best support both clock stretching and multi-master configurations. Isn't it better to switch the direction to input since the driver needs to watch the pin state in order to support clock stretching and multi-master? +gpio_direction_input(pdata-sda_pin); +gpio_direction_input(pdata-scl_pin); +gpio_set_value(pdata-sda_pin, 0); +gpio_set_value(pdata-scl_pin, 0); Surely you mean output in both cases. So you can set the value. Setting the value on an input pin is undefined. ;) No I really do mean input, as I want to put the bus into an idle state initially, which means no output drivers and passive pullup on both lines. The gpio_set_value() calls should go away and the output value should be explicitly set to 0 when turning on the output drivers. In its present form, the driver happens to work on my hardware, which is all I really cared about when writing it ;-) +printk(KERN_INFO i2c-gpio: using pins 0x%x (sda) 0x%x (scl)\n, + pdata-sda_pin, pdata-scl_pin); Please, no hex there. I think dev_info() would be better; and it might be nice to report whether clock stretching is supported. Ok, but how do I inform i2c-algo-bit about whether or not clock stretching is supported? --- a/include/linux/i2c-id.h +++ b/include/linux/i2c-id.h @@ -194,6 +194,7 @@ #define I2C_HW_B_EM28XX 0x01001f /* em28xx video capture cards */ #define I2C_HW_B_CX2341X0x010020 /* Conexant CX2341X MPEG encoder cards */ #define I2C_HW_B_INTELFB0x010021 /* intel framebuffer driver */ +#define I2C_HW_B_GPIO 0x010022 /* Generic GPIO-based driver */ It'd be nice to completely abolish those IDs, starting by not adding new ones. Especially, not adding unused ones! Sure. Haavard - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Friday 09 March 2007 12:08 pm, Russell King wrote: On Fri, Mar 09, 2007 at 11:30:12AM -0800, David Brownell wrote: On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: This is a very simple bitbanging i2c bus driver utilizing the new arch-neutral GPIO API. Useful for chips that don't have a built-in i2c controller, additional i2c busses, or testing purposes. That's the right idea! But remember that not all GPIOs support reading back the actual value on SCL (it's an OUT pin, so lacking multidrive capability the values should be what you wrote), so getscl() support should depend on a flag in platform data. In the same vein, if SCL is an output-only pin, you won't be able to change its direction ... but then, I'm not sure why you were changing its direction in setscl() rather than just its value. That's a more correct I2C implementation. If you read the specs, the SDA and SCL signals are supposed to be driven by open-collector or open-drain drivers, such that devices only pull the bus low. Pull-up resistors pull the signals high when undriven. Exactly as I had mentioned: I2C has another interesting special case. at91_set_multi_drive() would be appropriate (yes?) for ARCH_AT91 to use on SCL, to best support both clock stretching and multi-master configurations. Where multi-drive == open-drain. You're saying it should also be used on SDA too ... OK, I was focussing on clock stretching but it applies there too. This avoids the possibility of damage caused when one device drives a signal low and another device tries to drive it high. Therefore, the correct I2C GPIO implementation is one where you drive both SDA and SCL low by using a combination of the data direction register and the output level register, but avoid driving the output high. I see your point -- it does answer my question -- but you seem to have overlooked a highly relevant one of mine. :) Regardless, those nuances should be captured in comments in that driver: that for GPIOs that don't support open drain output (only push/pull drivers), that it's faked by otherwise-unnecessary tweaking of GPIO direction. - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Friday 09 March 2007 12:43 pm, Håvard Skinnemoen wrote: On Fri, March 9, 2007 20:30, David Brownell wrote: On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote: This is a very simple bitbanging i2c bus driver utilizing the new arch-neutral GPIO API. Useful for chips that don't have a built-in i2c controller, additional i2c busses, or testing purposes. That's the right idea! But remember that not all GPIOs support reading back the actual value on SCL ... The idea is to keep the output value at 0 and switch the output driver on and off. I assumed that changing the direction was the easiest way to achieve this. I never really thought about output-only pins. Is it actually possible to implement i2c properly on such hardware? Not strictly; but folk do so, and the results are compatible-enough for many purposes. Certainly a quick glance at i2c-algo-bit tells me that it knows how to cope with output-only SCL. A generic GPIO driver should be able to at least act sanely given such a pin. I2C has another interesting special case. at91_set_multi_drive() would be appropriate (yes?) for ARCH_AT91 to use on SCL, to best support both clock stretching and multi-master configurations. Isn't it better to switch the direction to input since the driver needs to watch the pin state in order to support clock stretching and multi-master? Not necessarily ... reading the GPIO pad state works regardless of what direction was configured on most chips (including AT91 and AVR32), but not all of them. Certainly multi-drive/open-drain outputs get the electical stuff right without that. Russell's explanation says the reason to switch direction is to disable the non-open-drain output drivers. There are several options lurking, that a generic I2C bitbanger ought to handle. Existence of open-drain outputs is one issue. Ability to change direction is another; as is ability to read the value on output pads. Your code assumed one set of answers; others are possible. The gpio_set_value() calls should go away and the output value should be explicitly set to 0 when turning on the output drivers. In its present form, the driver happens to work on my hardware, which is all I really cared about when writing it ;-) As I said in a different way above! If open drain outputs are available, and the actual values can be read on output pins, then I think both pins can be configured as outputs and left that way. + printk(KERN_INFO i2c-gpio: using pins 0x%x (sda) 0x%x (scl)\n, + pdata-sda_pin, pdata-scl_pin); Please, no hex there. I think dev_info() would be better; and it might be nice to report whether clock stretching is supported. Ok, but how do I inform i2c-algo-bit about whether or not clock stretching is supported? Reading the code, I see it's automatic if you don't provide getscl()... - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
