Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-22 Thread Jean Delvare
On Thu, 22 Mar 2007 04:12:37 -0400, Mike Frysinger wrote: > it isnt obvious to me how to leverage the normal platform_device and > resource structures to achieve moving the class out of the driver and > into a boards file ... i'm perfectly happy doing this knowing what the > correct direction to

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-22 Thread Mike Frysinger
On 3/22/07, Jean Delvare <[EMAIL PROTECTED]> wrote: On Thu, 22 Mar 2007 01:39:28 -0400, Mike Frysinger wrote: > On 3/21/07, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > + p_adap->class = I2C_CLASS_ALL; > > > > This pretty much voids the point of these probing classes. You should > > only

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-22 Thread Jean Delvare
Hi Mike, On Thu, 22 Mar 2007 01:39:28 -0400, Mike Frysinger wrote: > On 3/21/07, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > + p_adap->class = I2C_CLASS_ALL; > > > > This pretty much voids the point of these probing classes. You should > > only select the classes matching devices which may

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-22 Thread Mike Frysinger
On 3/22/07, Jean Delvare <[EMAIL PROTECTED]> wrote: On Wed, 21 Mar 2007 15:14:29 -0400, Mike Frysinger wrote: > On 3/21/07, Bob Copeland <[EMAIL PROTECTED]> wrote: > > > +config I2C_BLACKFIN_TWI > > > + tristate "Blackfin TWI I2C support" > > > + depends on I2C && (BF534 || BF536 ||

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-22 Thread Jean Delvare
On Wed, 21 Mar 2007 15:14:29 -0400, Mike Frysinger wrote: > On 3/21/07, Bob Copeland <[EMAIL PROTECTED]> wrote: > > > +config I2C_BLACKFIN_TWI > > > + tristate "Blackfin TWI I2C support" > > > + depends on I2C && (BF534 || BF536 || BF537) > > > + help > > > + This is the

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-22 Thread Jean Delvare
On Wed, 21 Mar 2007 15:14:29 -0400, Mike Frysinger wrote: On 3/21/07, Bob Copeland [EMAIL PROTECTED] wrote: +config I2C_BLACKFIN_TWI + tristate Blackfin TWI I2C support + depends on I2C (BF534 || BF536 || BF537) + help + This is the TWI I2C device driver

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-22 Thread Mike Frysinger
On 3/22/07, Jean Delvare [EMAIL PROTECTED] wrote: On Wed, 21 Mar 2007 15:14:29 -0400, Mike Frysinger wrote: On 3/21/07, Bob Copeland [EMAIL PROTECTED] wrote: +config I2C_BLACKFIN_TWI + tristate Blackfin TWI I2C support + depends on I2C (BF534 || BF536 || BF537) +

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-22 Thread Jean Delvare
Hi Mike, On Thu, 22 Mar 2007 01:39:28 -0400, Mike Frysinger wrote: On 3/21/07, Jean Delvare [EMAIL PROTECTED] wrote: + p_adap-class = I2C_CLASS_ALL; This pretty much voids the point of these probing classes. You should only select the classes matching devices which may actually be

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-22 Thread Mike Frysinger
On 3/22/07, Jean Delvare [EMAIL PROTECTED] wrote: On Thu, 22 Mar 2007 01:39:28 -0400, Mike Frysinger wrote: On 3/21/07, Jean Delvare [EMAIL PROTECTED] wrote: + p_adap-class = I2C_CLASS_ALL; This pretty much voids the point of these probing classes. You should only select the

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-22 Thread Jean Delvare
On Thu, 22 Mar 2007 04:12:37 -0400, Mike Frysinger wrote: it isnt obvious to me how to leverage the normal platform_device and resource structures to achieve moving the class out of the driver and into a boards file ... i'm perfectly happy doing this knowing what the correct direction to take

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Mike Frysinger
On 3/21/07, Jean Delvare <[EMAIL PROTECTED]> wrote: > + p_adap->class = I2C_CLASS_ALL; This pretty much voids the point of these probing classes. You should only select the classes matching devices which may actually be probed for on this bus. If different boards have different needs, get

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Jean Delvare
Bryan, On Wed, 21 Mar 2007 18:08:08 +0800, Wu, Bryan wrote: > As GPIO based blackfin driver will be replaced by I2C-GPIO generic > driver, we just update this latest version of blackfin on-chip TWI I2C > driver according to LKML review. > > [PATCH] Blackfin: on-chip Two Wire Interface I2C driver

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Mike Frysinger
On 3/21/07, Bob Copeland <[EMAIL PROTECTED]> wrote: > +config I2C_BLACKFIN_TWI > + tristate "Blackfin TWI I2C support" > + depends on I2C && (BF534 || BF536 || BF537) > + help > + This is the TWI I2C device driver for Blackfin 534/536/537. > + This driver can

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Bob Copeland
+config I2C_BLACKFIN_TWI + tristate "Blackfin TWI I2C support" + depends on I2C && (BF534 || BF536 || BF537) + help + This is the TWI I2C device driver for Blackfin 534/536/537. + This driver can also be built as a module. If so, the module + will be

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Jean Delvare
Hi Bryan, What's the point of setting the Reply-To header to your own address, other than forcing me to add your name manually each time I reply? On Wed, 21 Mar 2007 18:08:08 +0800, Wu, Bryan wrote: > As GPIO based blackfin driver will be replaced by I2C-GPIO generic > driver, we just update

[PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Wu, Bryan
Hi folks, As GPIO based blackfin driver will be replaced by I2C-GPIO generic driver, we just update this latest version of blackfin on-chip TWI I2C driver according to LKML review. [PATCH] Blackfin: on-chip Two Wire Interface I2C driver The i2c linux driver for blackfin architecture which

[PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Wu, Bryan
Hi folks, As GPIO based blackfin driver will be replaced by I2C-GPIO generic driver, we just update this latest version of blackfin on-chip TWI I2C driver according to LKML review. [PATCH] Blackfin: on-chip Two Wire Interface I2C driver The i2c linux driver for blackfin architecture which

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Jean Delvare
Hi Bryan, What's the point of setting the Reply-To header to your own address, other than forcing me to add your name manually each time I reply? On Wed, 21 Mar 2007 18:08:08 +0800, Wu, Bryan wrote: As GPIO based blackfin driver will be replaced by I2C-GPIO generic driver, we just update this

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Bob Copeland
+config I2C_BLACKFIN_TWI + tristate Blackfin TWI I2C support + depends on I2C (BF534 || BF536 || BF537) + help + This is the TWI I2C device driver for Blackfin 534/536/537. + This driver can also be built as a module. If so, the module + will be called

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Mike Frysinger
On 3/21/07, Bob Copeland [EMAIL PROTECTED] wrote: +config I2C_BLACKFIN_TWI + tristate Blackfin TWI I2C support + depends on I2C (BF534 || BF536 || BF537) + help + This is the TWI I2C device driver for Blackfin 534/536/537. + This driver can also be built

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Jean Delvare
Bryan, On Wed, 21 Mar 2007 18:08:08 +0800, Wu, Bryan wrote: As GPIO based blackfin driver will be replaced by I2C-GPIO generic driver, we just update this latest version of blackfin on-chip TWI I2C driver according to LKML review. [PATCH] Blackfin: on-chip Two Wire Interface I2C driver

Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

2007-03-21 Thread Mike Frysinger
On 3/21/07, Jean Delvare [EMAIL PROTECTED] wrote: + p_adap-class = I2C_CLASS_ALL; This pretty much voids the point of these probing classes. You should only select the classes matching devices which may actually be probed for on this bus. If different boards have different needs, get the