Re: [PATCH v2] i2c-eg20t: Rework pch_i2c_wait_for_bus_idle to reduce wait time
Hi Our team moved to ROHM Co., Ltd. So, previous email address already disappeared. Current my mail address is "tomoya.r...@gmail.com". thanks. ROHM Co., Ltd. tomoya -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: export bit-banging algo functions
i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
we need to be able to fall back to the bit-banging algo on gpio pins.
The current code sets up a 2nd i2c controller for the same i2c bus using
the bit-banging algo. This has a bunch of issues, the major one being
that userspace can directly access this fallback i2c adaptor behind
the drivers back.
But we need to frob a few registers before and after using fallback
gpio bit-banging, so this horribly fails.
The new plan is to only set up one i2c adaptor and transparently fall
back to bit-banging by directly calling the xfer function of the bit-
banging algo in the i2c core.
To make that possible, export the 2 i2c algo functions.
v2: As suggested by Jean Delvare, simply export the i2c_bit_algo
vtable instead of the individual functions.
Signed-off-by: Daniel Vetter
---
drivers/i2c/algos/i2c-algo-bit.c |3 ++-
include/linux/i2c-algo-bit.h |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c
index 525c734..ad0459c 100644
--- a/drivers/i2c/algos/i2c-algo-bit.c
+++ b/drivers/i2c/algos/i2c-algo-bit.c
@@ -610,10 +610,11 @@ static u32 bit_func(struct i2c_adapter *adap)
/* -exported algorithm data: - */
-static const struct i2c_algorithm i2c_bit_algo = {
+const struct i2c_algorithm i2c_bit_algo = {
.master_xfer= bit_xfer,
.functionality = bit_func,
};
+EXPORT_SYMBOL(i2c_bit_algo);
/*
* registering functions to load algorithms at runtime
diff --git a/include/linux/i2c-algo-bit.h b/include/linux/i2c-algo-bit.h
index 4f98148..584ffa0 100644
--- a/include/linux/i2c-algo-bit.h
+++ b/include/linux/i2c-algo-bit.h
@@ -49,5 +49,6 @@ struct i2c_algo_bit_data {
int i2c_bit_add_bus(struct i2c_adapter *);
int i2c_bit_add_numbered_bus(struct i2c_adapter *);
+extern const struct i2c_algorithm i2c_bit_algo;
#endif /* _LINUX_I2C_ALGO_BIT_H */
--
1.7.7.5
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] i2c: export bit-banging algo functions
On Mon, Feb 27, 2012 at 11:20:40PM +0100, Jean Delvare wrote:
> Hi Daniel,
>
> Sorry for the late reply.
>
> On Tue, 14 Feb 2012 22:37:21 +0100, Daniel Vetter wrote:
> > i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
> > we need to be able to fall back to the bit-banging algo on gpio pins.
> >
> > The current code sets up a 2nd i2c controller for the same i2c bus using
> > the bit-banging algo. This has a bunch of issues, the major one being
> > that userspace can directly access this fallback i2c adaptor behind
> > the drivers back.
> >
> > But we need to frob a few registers before and after using fallback
> > gpio bit-banging, so this horribly fails.
>
> You could use the pre_xfer and post_xfer hooks together with a shared
> mutex to solve the problem. But I agree its much cleaner to expose a
> single adapter in the first place.
Yeah, I've seen these and I think we could use them. Still it's cleaner to
only expose one algo for a single bus.
> If you need to hot-switch between hardware and bit-banged I2C, I suggest
> that you lock the bus while doing so, to avoid switching while a
> transaction is in progress. This can be achieved with
> i2c_lock_adapter() and i2c_unlock_adapter().
The drm/i915 xfer function is currently protected by a single mutex
(because the hw i2c controller can only be used on one bus at a time). So
I think we're covered. Also we do the fallback in our xfer function when
we notice that things don't quite work as they should, so we actually want
to switch while a transfer is in progress. Dunno whether that's the best
approach, but the current code is structured like this.
> > The new plan is to only set up one i2c adaptor and transparently fall
> > back to bit-banging by directly calling the xfer function of the bit-
> > banging algo in the i2c core.
> >
> > To make that possible, export the 2 i2c algo functions.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/i2c/algos/i2c-algo-bit.c | 12 +++-
> > include/linux/i2c-algo-bit.h |4
> > 2 files changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/i2c/algos/i2c-algo-bit.c
> > b/drivers/i2c/algos/i2c-algo-bit.c
> > index 525c734..ec1651a 100644
> > --- a/drivers/i2c/algos/i2c-algo-bit.c
> > +++ b/drivers/i2c/algos/i2c-algo-bit.c
> > @@ -531,8 +531,8 @@ static int bit_doAddress(struct i2c_adapter *i2c_adap,
> > struct i2c_msg *msg)
> > return 0;
> > }
> >
> > -static int bit_xfer(struct i2c_adapter *i2c_adap,
> > - struct i2c_msg msgs[], int num)
> > +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> > +struct i2c_msg msgs[], int num)
> > {
> > struct i2c_msg *pmsg;
> > struct i2c_algo_bit_data *adap = i2c_adap->algo_data;
> > @@ -598,21 +598,23 @@ bailout:
> > adap->post_xfer(i2c_adap);
> > return ret;
> > }
> > +EXPORT_SYMBOL(i2c_bit_xfer);
> >
> > -static u32 bit_func(struct i2c_adapter *adap)
> > +u32 i2c_bit_func(struct i2c_adapter *adap)
> > {
> > return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
> >I2C_FUNC_SMBUS_READ_BLOCK_DATA |
> >I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
> >I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
> > }
> > +EXPORT_SYMBOL(i2c_bit_func);
> >
> >
> > /* -exported algorithm data: -
> > */
> >
> > static const struct i2c_algorithm i2c_bit_algo = {
> > - .master_xfer= bit_xfer,
> > - .functionality = bit_func,
> > + .master_xfer= i2c_bit_xfer,
> > + .functionality = i2c_bit_func,
> > };
> >
> > /*
> > diff --git a/include/linux/i2c-algo-bit.h b/include/linux/i2c-algo-bit.h
> > index 4f98148..cdd6336 100644
> > --- a/include/linux/i2c-algo-bit.h
> > +++ b/include/linux/i2c-algo-bit.h
> > @@ -47,6 +47,10 @@ struct i2c_algo_bit_data {
> > int timeout;/* in jiffies */
> > };
> >
> > +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> > +struct i2c_msg msgs[], int num);
> > +u32 i2c_bit_func(struct i2c_adapter *adap);
> > +
> > int i2c_bit_add_bus(struct i2c_adapter *);
> > int i2c_bit_add_numbered_bus(struct i2c_adapter *);
>
> I have no problem with this in the principle. In the details, I don't
> understand why you don't simply export i2c_bit_algo? This is one fewer
> export and should serve the same purpose - even allowing faster
> initializations in some cases.
I've figured that hunting for magic functions in a struct is a bit to
intransparent and hence exported the 2 functions I needed instead of the
struct. But if you prefer me to export the vtable I'll gladly do so - that
way I can drop a patch to rename some functions in drm/nouveau that
conflict with these here.
> Looking a bit more to the i2c-algo-bit code, I also notice that
> bypassing i2c_bit_add_bus() means you'll miss some of its features,
> namely bus testing, default retries value and warning on non-compliant
> buses. While none of these are mandatory, it may mak
Re: [PATCH 3/7] i2c: export bit-banging algo functions
Hi Daniel,
Sorry for the late reply.
On Tue, 14 Feb 2012 22:37:21 +0100, Daniel Vetter wrote:
> i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
> we need to be able to fall back to the bit-banging algo on gpio pins.
>
> The current code sets up a 2nd i2c controller for the same i2c bus using
> the bit-banging algo. This has a bunch of issues, the major one being
> that userspace can directly access this fallback i2c adaptor behind
> the drivers back.
>
> But we need to frob a few registers before and after using fallback
> gpio bit-banging, so this horribly fails.
You could use the pre_xfer and post_xfer hooks together with a shared
mutex to solve the problem. But I agree its much cleaner to expose a
single adapter in the first place.
If you need to hot-switch between hardware and bit-banged I2C, I suggest
that you lock the bus while doing so, to avoid switching while a
transaction is in progress. This can be achieved with
i2c_lock_adapter() and i2c_unlock_adapter().
> The new plan is to only set up one i2c adaptor and transparently fall
> back to bit-banging by directly calling the xfer function of the bit-
> banging algo in the i2c core.
>
> To make that possible, export the 2 i2c algo functions.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/i2c/algos/i2c-algo-bit.c | 12 +++-
> include/linux/i2c-algo-bit.h |4
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/algos/i2c-algo-bit.c
> b/drivers/i2c/algos/i2c-algo-bit.c
> index 525c734..ec1651a 100644
> --- a/drivers/i2c/algos/i2c-algo-bit.c
> +++ b/drivers/i2c/algos/i2c-algo-bit.c
> @@ -531,8 +531,8 @@ static int bit_doAddress(struct i2c_adapter *i2c_adap,
> struct i2c_msg *msg)
> return 0;
> }
>
> -static int bit_xfer(struct i2c_adapter *i2c_adap,
> - struct i2c_msg msgs[], int num)
> +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> + struct i2c_msg msgs[], int num)
> {
> struct i2c_msg *pmsg;
> struct i2c_algo_bit_data *adap = i2c_adap->algo_data;
> @@ -598,21 +598,23 @@ bailout:
> adap->post_xfer(i2c_adap);
> return ret;
> }
> +EXPORT_SYMBOL(i2c_bit_xfer);
>
> -static u32 bit_func(struct i2c_adapter *adap)
> +u32 i2c_bit_func(struct i2c_adapter *adap)
> {
> return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
> I2C_FUNC_SMBUS_READ_BLOCK_DATA |
> I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
> I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
> }
> +EXPORT_SYMBOL(i2c_bit_func);
>
>
> /* -exported algorithm data: -
> */
>
> static const struct i2c_algorithm i2c_bit_algo = {
> - .master_xfer= bit_xfer,
> - .functionality = bit_func,
> + .master_xfer= i2c_bit_xfer,
> + .functionality = i2c_bit_func,
> };
>
> /*
> diff --git a/include/linux/i2c-algo-bit.h b/include/linux/i2c-algo-bit.h
> index 4f98148..cdd6336 100644
> --- a/include/linux/i2c-algo-bit.h
> +++ b/include/linux/i2c-algo-bit.h
> @@ -47,6 +47,10 @@ struct i2c_algo_bit_data {
> int timeout;/* in jiffies */
> };
>
> +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> + struct i2c_msg msgs[], int num);
> +u32 i2c_bit_func(struct i2c_adapter *adap);
> +
> int i2c_bit_add_bus(struct i2c_adapter *);
> int i2c_bit_add_numbered_bus(struct i2c_adapter *);
I have no problem with this in the principle. In the details, I don't
understand why you don't simply export i2c_bit_algo? This is one fewer
export and should serve the same purpose - even allowing faster
initializations in some cases.
Looking a bit more to the i2c-algo-bit code, I also notice that
bypassing i2c_bit_add_bus() means you'll miss some of its features,
namely bus testing, default retries value and warning on non-compliant
buses. While none of these are mandatory, it may make sense to export a
new function i2c_bit_add_numbered_bus() which would call
__i2c_bit_add_bus() with no callback function. If you do that, you may
not have to export anything else.
I leave it up to you which way you want to implement it, all are fine
with me, and we can always change later if more use cases show up which
would work better with a different implementation.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/i915: i2c: unconditionally set up gpio fallback
This way we can simplify the setup and teardown a bit.
Because we don't actually allocate anything anymore for the force_bit
case, we can now convert that into a boolean.
Also and the functionality supported by the bit-banging together with
what gmbus can do, so that this doesn't randomly change any more.
v2: Chris Wilson noticed that I've mixed up && and & ...
v3: Clarify an if block as suggested by Eugeni Dodonov.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |3 +-
drivers/gpu/drm/i915/intel_i2c.c | 51 +++---
2 files changed, 22 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 14b6e94..31affc0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -293,7 +293,8 @@ struct intel_fbc_work;
struct intel_gmbus {
struct i2c_adapter adapter;
- struct i2c_adapter *force_bit;
+ bool force_bit;
+ bool has_gpio;
u32 reg0;
u32 gpio_reg;
struct i2c_algo_bit_data bit_algo;
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 6eb68b7..44d1755 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -140,8 +140,8 @@ static void set_data(void *data, int state_high)
POSTING_READ(bus->gpio_reg);
}
-static struct i2c_adapter *
-intel_gpio_create(struct intel_gmbus *bus, u32 pin)
+static bool
+intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
{
struct drm_i915_private *dev_priv = bus->dev_priv;
static const int map_pin_to_reg[] = {
@@ -157,7 +157,7 @@ intel_gpio_create(struct intel_gmbus *bus, u32 pin)
struct i2c_algo_bit_data *algo;
if (pin >= ARRAY_SIZE(map_pin_to_reg) || !map_pin_to_reg[pin])
- return NULL;
+ return false;
algo = &bus->bit_algo;
@@ -174,12 +174,11 @@ intel_gpio_create(struct intel_gmbus *bus, u32 pin)
algo->timeout = usecs_to_jiffies(2200);
algo->data = bus;
- return &bus->adapter;
+ return true;
}
static int
intel_i2c_quirk_xfer(struct intel_gmbus *bus,
-struct i2c_adapter *adapter,
struct i2c_msg *msgs,
int num)
{
@@ -193,7 +192,7 @@ intel_i2c_quirk_xfer(struct intel_gmbus *bus,
set_clock(bus, 1);
udelay(I2C_RISEFALL_TIME);
- ret = i2c_bit_xfer(adapter, msgs, num);
+ ret = i2c_bit_xfer(&bus->adapter, msgs, num);
set_data(bus, 1);
set_clock(bus, 1);
@@ -216,7 +215,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
mutex_lock(&dev_priv->gmbus_mutex);
if (bus->force_bit) {
- ret = intel_i2c_quirk_xfer(bus, bus->force_bit, msgs, num);
+ ret = intel_i2c_quirk_xfer(bus, msgs, num);
goto out;
}
@@ -311,11 +310,12 @@ timeout:
I915_WRITE(GMBUS0 + reg_offset, 0);
/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging
instead. */
- bus->force_bit = intel_gpio_create(bus, bus->reg0 & 0xff);
- if (!bus->force_bit)
- ret = -ENOMEM;
- else
- ret = intel_i2c_quirk_xfer(bus, bus->force_bit, msgs, num);
+ if (!bus->has_gpio) {
+ ret = -EIO;
+ } else {
+ bus->force_bit = true;
+ ret = intel_i2c_quirk_xfer(bus, msgs, num);
+ }
out:
mutex_unlock(&dev_priv->gmbus_mutex);
return ret;
@@ -323,14 +323,8 @@ out:
static u32 gmbus_func(struct i2c_adapter *adapter)
{
- struct intel_gmbus *bus = container_of(adapter,
- struct intel_gmbus,
- adapter);
-
- if (bus->force_bit)
- i2c_bit_func(bus->force_bit);
-
- return (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
+ return i2c_bit_func(adapter) &
+ (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
/* I2C_FUNC_10BIT_ADDR | */
I2C_FUNC_SMBUS_READ_BLOCK_DATA |
I2C_FUNC_SMBUS_BLOCK_PROC_CALL);
@@ -388,8 +382,11 @@ int intel_setup_gmbus(struct drm_device *dev)
/* By default use a conservative clock rate */
bus->reg0 = i | GMBUS_RATE_100KHZ;
+ bus->has_gpio = intel_gpio_setup(bus, i);
+
/* XXX force bit banging until GMBUS is fully debugged */
- bus->force_bit = intel_gpio_create(bus, i);
+ if (bus->has_gpio)
+ bus->force_bit = true;
}
intel_i2c_reset(dev_priv->dev);
@@ -417,16 +414,8 @@ void intel_gmbus_force_bit(struct i2c_adapter *adapter,
bool force_bit)
{
struct intel_gmbus *bus = to_intel_gmbus(adapter);
- if (force_bit) {
- if (bus->force_bit == NULL) {
- bus->force_bit = intel_gpio_create(bus,
-
RE: [PATCH 2/2] i2c: tegra: Remove unnecessary write to INT_STATUS
Ben Dooks wrote at Monday, February 13, 2012 4:24 PM: > On Fri, Feb 03, 2012 at 05:10:17PM -0700, Stephen Warren wrote: > > From: Alok Chauhan > > > > The write is not necessary and may cause the I2C controller to misbehave. > > With this fix, I2C on Tegra30 works (at least, running i2cdump repeatedly > > on the WM8903 on Cardhu's I2C5/DVC bus). > > > > Originally by Alok Chauhan , but S-o-b missing in our > > internal repo. > > > > [swarren: Reworded commit description] > > Signed-off-by: Stephen Warren > > I'll apply this as it seems to have gone by without major comment. Ben, I haven't seen this show up in linux-next yet. I'm hoping the patch will make 3.4. Thanks -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] i2c: export bit-banging algo functions
Hi Jean,
Can you please review and if you don't have any objectsion, ack this patch
for merging through drm-intel-next? Imo that's the easiest way to merge
this series.
Thanks, Daniel
On Tue, Feb 14, 2012 at 10:37:21PM +0100, Daniel Vetter wrote:
> i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
> we need to be able to fall back to the bit-banging algo on gpio pins.
>
> The current code sets up a 2nd i2c controller for the same i2c bus using
> the bit-banging algo. This has a bunch of issues, the major one being
> that userspace can directly access this fallback i2c adaptor behind
> the drivers back.
>
> But we need to frob a few registers before and after using fallback
> gpio bit-banging, so this horribly fails.
>
> The new plan is to only set up one i2c adaptor and transparently fall
> back to bit-banging by directly calling the xfer function of the bit-
> banging algo in the i2c core.
>
> To make that possible, export the 2 i2c algo functions.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/i2c/algos/i2c-algo-bit.c | 12 +++-
> include/linux/i2c-algo-bit.h |4
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/algos/i2c-algo-bit.c
> b/drivers/i2c/algos/i2c-algo-bit.c
> index 525c734..ec1651a 100644
> --- a/drivers/i2c/algos/i2c-algo-bit.c
> +++ b/drivers/i2c/algos/i2c-algo-bit.c
> @@ -531,8 +531,8 @@ static int bit_doAddress(struct i2c_adapter *i2c_adap,
> struct i2c_msg *msg)
> return 0;
> }
>
> -static int bit_xfer(struct i2c_adapter *i2c_adap,
> - struct i2c_msg msgs[], int num)
> +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> + struct i2c_msg msgs[], int num)
> {
> struct i2c_msg *pmsg;
> struct i2c_algo_bit_data *adap = i2c_adap->algo_data;
> @@ -598,21 +598,23 @@ bailout:
> adap->post_xfer(i2c_adap);
> return ret;
> }
> +EXPORT_SYMBOL(i2c_bit_xfer);
>
> -static u32 bit_func(struct i2c_adapter *adap)
> +u32 i2c_bit_func(struct i2c_adapter *adap)
> {
> return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
> I2C_FUNC_SMBUS_READ_BLOCK_DATA |
> I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
> I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
> }
> +EXPORT_SYMBOL(i2c_bit_func);
>
>
> /* -exported algorithm data: -
> */
>
> static const struct i2c_algorithm i2c_bit_algo = {
> - .master_xfer= bit_xfer,
> - .functionality = bit_func,
> + .master_xfer= i2c_bit_xfer,
> + .functionality = i2c_bit_func,
> };
>
> /*
> diff --git a/include/linux/i2c-algo-bit.h b/include/linux/i2c-algo-bit.h
> index 4f98148..cdd6336 100644
> --- a/include/linux/i2c-algo-bit.h
> +++ b/include/linux/i2c-algo-bit.h
> @@ -47,6 +47,10 @@ struct i2c_algo_bit_data {
> int timeout;/* in jiffies */
> };
>
> +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> + struct i2c_msg msgs[], int num);
> +u32 i2c_bit_func(struct i2c_adapter *adap);
> +
> int i2c_bit_add_bus(struct i2c_adapter *);
> int i2c_bit_add_numbered_bus(struct i2c_adapter *);
>
> --
> 1.7.7.5
>
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] drm/nouveau: do a better job at hiding the NIH i2c bit-banging algo
Hi Ben,
Can you ack this patch for merging through drm-intel-next? Imo that's the
easiest way to get it in (assuming you don't have any objections).
Thanks, Daniel
On Tue, Feb 14, 2012 at 10:37:20PM +0100, Daniel Vetter wrote:
> I'd like to export the corresponding functions from the i2c core
> so that I can use them in fallback bit-banging in i915.ko
>
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_i2c.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_i2c.c
> b/drivers/gpu/drm/nouveau/nouveau_i2c.c
> index 820ae7f..7a7e751 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_i2c.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_i2c.c
> @@ -242,7 +242,7 @@ i2c_addr(struct nouveau_i2c_chan *port, struct i2c_msg
> *msg)
> }
>
> static int
> -i2c_bit_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> +nouveau_i2c_bit_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> {
> struct nouveau_i2c_chan *port = (struct nouveau_i2c_chan *)adap;
> struct i2c_msg *msg = msgs;
> @@ -272,14 +272,14 @@ i2c_bit_xfer(struct i2c_adapter *adap, struct i2c_msg
> *msgs, int num)
> }
>
> static u32
> -i2c_bit_func(struct i2c_adapter *adap)
> +nouveau_i2c_bit_func(struct i2c_adapter *adap)
> {
> return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
> }
>
> const struct i2c_algorithm i2c_bit_algo = {
> - .master_xfer = i2c_bit_xfer,
> - .functionality = i2c_bit_func
> + .master_xfer = nouveau_i2c_bit_xfer,
> + .functionality = nouveau_i2c_bit_func
> };
>
> static const uint32_t nv50_i2c_port[] = {
> --
> 1.7.7.5
>
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add basic support for the Congatec CGEB BIOS interface
On Mon, Feb 27, 2012 at 02:58:27PM +0100, Samuel Ortiz wrote: > Hi Sascha, > > > On Mon, Feb 20, 2012 at 07:07:52PM +0100, Sascha Hauer wrote: > > Hi Samuel, > > > > On Mon, Feb 20, 2012 at 05:39:27PM +0100, Samuel Ortiz wrote: > > > Hi Sascha, > > > > > > On Wed, Feb 01, 2012 at 02:26:31PM +0100, Sascha Hauer wrote: > > > > The Congatec CGEB is a BIOS interface found on some Congatec x86 > > > > modules. It provides access to on board peripherals like I2C busses > > > > and watchdogs. This driver contains the basic support for accessing > > > > the CGEB interface and registers the child devices. > > > After looking at the code, I'm not entirely sure this one belongs to > > > drivers/mfd/. Have you thought about putting it under arch/x86/platform/ ? > > > There are similar examples there, like uv or olpc. > > > > I don't mind putting it in arch/x86/platform instead. I'm an ARM guy and > > on ARM there currently is a rush to move everything looking remotely > > like a driver out of arch/arm/ to drivers/, so putting it under > > drivers/mfd/ seemed logical to me. > Yes, this seems to be the trend apparently. Could you try pushing that into > the x86/platform, please ? If they put you under fire, I guess I could take > this patchset. But they have several "BIOS interfaces" there already... Ok, I'll put on my asbestos suit and give it a try. Thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: Add basic support for the Congatec CGEB BIOS interface
Hi Sascha, On Mon, Feb 20, 2012 at 07:07:52PM +0100, Sascha Hauer wrote: > Hi Samuel, > > On Mon, Feb 20, 2012 at 05:39:27PM +0100, Samuel Ortiz wrote: > > Hi Sascha, > > > > On Wed, Feb 01, 2012 at 02:26:31PM +0100, Sascha Hauer wrote: > > > The Congatec CGEB is a BIOS interface found on some Congatec x86 > > > modules. It provides access to on board peripherals like I2C busses > > > and watchdogs. This driver contains the basic support for accessing > > > the CGEB interface and registers the child devices. > > After looking at the code, I'm not entirely sure this one belongs to > > drivers/mfd/. Have you thought about putting it under arch/x86/platform/ ? > > There are similar examples there, like uv or olpc. > > I don't mind putting it in arch/x86/platform instead. I'm an ARM guy and > on ARM there currently is a rush to move everything looking remotely > like a driver out of arch/arm/ to drivers/, so putting it under > drivers/mfd/ seemed logical to me. Yes, this seems to be the trend apparently. Could you try pushing that into the x86/platform, please ? If they put you under fire, I guess I could take this patchset. But they have several "BIOS interfaces" there already... Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c/designware: dw_i2c_init_driver as subsys initcall
> Can anyone of you apply this patch, if it looks fine. Please simply resend the patch. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function
On 2/27/2012 3:40 PM, Rajeev KUMAR wrote:
> In some i2c controller (like synopsys) you dont have control over i2c
> data and clock lines. So clock toggling, you need to use gpio lines
> which in turns maps on sda and scl line.
>
> For the controller in which you have control over sda and scl line there
> is not need for gpio lines. You can directly write on registers.
>
> So to make the function more generic its better to control i2c lines
> with gpio.
There would be many drivers where we need to convert i2c pins to gpio pins
and generate clock pulses:
gpio_request(gpio);
gpio_set_direction(gpio, out, 0);
for (i = 1; i < count; i++) {
gpio set val(gpio, 1);
gpio set val(gpio, 0);
}
gpio_free(gpio);
we can give generalized function inside i2c framework for this, so that multiple
drivers can use it.
Secondly there are drivers/devices where control of pins is available. For them
we can provide driver hooks.
I would try to provide a patch for this ASAP. Other suggestions are welcome.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function
Hello Shubhrajyoti On 2/27/2012 2:42 PM, Shubhrajyoti Datta wrote: On Mon, Feb 27, 2012 at 12:57 PM, Laxman Dewangan wrote: On Monday 27 February 2012 12:51 PM, Shubhrajyoti Datta wrote: On Fri, Feb 24, 2012 at 5:01 PM, Viresh Kumarwrote: From: Vincenzo Frascino Add optional i2c_recover_bus() function to the Synopsys DesignWare I2C adapter driver that performs i2c bus recovery after timeout. The scope of this routine is to define i2c bus recovery procedure as specified in the i2c protocol Rev. 03 section 3.16 titled "Bus clear". What do you do in the function ? Could we have it in the driver file itself? I think bus recovery mechanism is to send extra clock on SCL line by toggling the pin (using gpio apis) You mean the SCL I didnt understand the gpio part? Why is gpio needed? In some i2c controller (like synopsys) you dont have control over i2c data and clock lines. So clock toggling, you need to use gpio lines which in turns maps on sda and scl line. For the controller in which you have control over sda and scl line there is not need for gpio lines. You can directly write on registers. So to make the function more generic its better to control i2c lines with gpio. ~Rajeev and keep watching of sda line whether it becomes high or not. We can put this algorithms in the some common file (i2c/algos/) and so if any i2c bus driver want to use, they can use it. Little background: I am working on tegra i2c controller and we have similar logic in tegra-i2c driver which we want to upstream. If similar function is in common place, we can use this and need not to duplicating it on every bus driver. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html . -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function
On Monday 27 February 2012 02:42 PM, Shubhrajyoti Datta wrote: On Mon, Feb 27, 2012 at 12:57 PM, Laxman Dewangan wrote: On Monday 27 February 2012 12:51 PM, Shubhrajyoti Datta wrote: On Fri, Feb 24, 2012 at 5:01 PM, Viresh Kumarwrote: From: Vincenzo Frascino Add optional i2c_recover_bus() function to the Synopsys DesignWare I2C adapter driver that performs i2c bus recovery after timeout. The scope of this routine is to define i2c bus recovery procedure as specified in the i2c protocol Rev. 03 section 3.16 titled "Bus clear". What do you do in the function ? Could we have it in the driver file itself? I think bus recovery mechanism is to send extra clock on SCL line by toggling the pin (using gpio apis) You mean the SCL I didnt understand the gpio part? Why is gpio needed? How do you toggle the SCL pin? --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function
On Mon, Feb 27, 2012 at 12:57 PM, Laxman Dewangan wrote: > On Monday 27 February 2012 12:51 PM, Shubhrajyoti Datta wrote: >> >> On Fri, Feb 24, 2012 at 5:01 PM, Viresh Kumar wrote: >>> >>> From: Vincenzo Frascino >>> >>> Add optional i2c_recover_bus() function to the Synopsys DesignWare I2C >>> adapter >>> driver that performs i2c bus recovery after timeout. The scope of this >>> routine >>> is to define i2c bus recovery procedure as specified in the i2c protocol >>> Rev. 03 >>> section 3.16 titled "Bus clear". >> >> What do you do in the function ? >> >> Could we have it in the driver file itself? >> > I think bus recovery mechanism is to send extra clock on SCL line by > toggling the pin (using gpio apis) You mean the SCL I didnt understand the gpio part? Why is gpio needed? and keep watching of sda line whether it > becomes high or not. > We can put this algorithms in the some common file (i2c/algos/) and so if > any i2c bus driver want to use, they can use it. > Little background: I am working on tegra i2c controller and we have similar > logic in tegra-i2c driver which we want to upstream. > If similar function is in common place, we can use this and need not to > duplicating it on every bus driver. > > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function
Hi Shubhrajyoti,
Il 27/02/2012 08:21, Shubhrajyoti Datta ha scritto:
> On Fri, Feb 24, 2012 at 5:01 PM, Viresh Kumar wrote:
>> From: Vincenzo Frascino
>>
>> Add optional i2c_recover_bus() function to the Synopsys DesignWare I2C
>> adapter
>> driver that performs i2c bus recovery after timeout. The scope of this
>> routine
>> is to define i2c bus recovery procedure as specified in the i2c protocol
>> Rev. 03
>> section 3.16 titled "Bus clear".
> What do you do in the function ?
With this function we provide the bus clear procedure for i2c recovery as
described in the the i2c protocol Rev. 03 section 3.16 titled "Bus clear".
>
> Could we have it in the driver file itself?
As it is thought now, it's implementation depends a little bit from the platform
we are using, but, sure, it can be generalized and put into the driver.
>
>> Since the Designware I2C controller doesn't provide direct control over SDA
>> and
>> SCL lines hence the intent is to let platform try to recover the bus if they
>> have the capability to take control of I2C pads and follow the recovery
>> protocol.
> So the function is passed in the pdata.
Yes, it is.
>> Signed-off-by: Vincenzo Frascino
>> Signed-off-by: Shiraz Hashim
>> Signed-off-by: Viresh Kumar
>> ---
>> drivers/i2c/busses/i2c-designware-core.c|4 +++
>> drivers/i2c/busses/i2c-designware-core.h|3 +-
>> drivers/i2c/busses/i2c-designware-platdrv.c |8 ++
>> include/linux/i2c/i2c-designware.h | 33
>> +++
>> 4 files changed, 47 insertions(+), 1 deletions(-)
>> create mode 100644 include/linux/i2c/i2c-designware.h
>>
>> diff --git a/drivers/i2c/busses/i2c-designware-core.c
>> b/drivers/i2c/busses/i2c-designware-core.c
>> index df87992..91d9357 100644
>> --- a/drivers/i2c/busses/i2c-designware-core.c
>> +++ b/drivers/i2c/busses/i2c-designware-core.c
>> @@ -525,6 +525,10 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
>> msgs[], int num)
>>ret = wait_for_completion_interruptible_timeout(&dev->cmd_complete,
>> HZ);
>>if (ret == 0) {
>>dev_err(dev->dev, "controller timed out\n");
>> + if (dev->i2c_recover_bus) {
>> + dev_info(dev->dev, "try i2c bus recovery\n");
>> + dev->i2c_recover_bus(dev->recovery_data);
>> + }
>>i2c_dw_init(dev);
>>ret = -ETIMEDOUT;
>>goto done;
>> diff --git a/drivers/i2c/busses/i2c-designware-core.h
>> b/drivers/i2c/busses/i2c-designware-core.h
>> index 02d1a2d..e2f3119 100644
>> --- a/drivers/i2c/busses/i2c-designware-core.h
>> +++ b/drivers/i2c/busses/i2c-designware-core.h
>> @@ -34,7 +34,6 @@
>> #define DW_IC_CON_RESTART_EN 0x20
>> #define DW_IC_CON_SLAVE_DISABLE0x40
>>
>> -
>> /**
>> * struct dw_i2c_dev - private i2c-designware data
>> * @dev: driver model device node
>> @@ -88,6 +87,8 @@ struct dw_i2c_dev {
>>u32 master_cfg;
>>unsigned inttx_fifo_depth;
>>unsigned intrx_fifo_depth;
>> + void(*i2c_recover_bus)(void *);
>> + void*recovery_data;
>> };
>>
>> extern u32 dw_readl(struct dw_i2c_dev *dev, int offset);
>> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
>> b/drivers/i2c/busses/i2c-designware-platdrv.c
>> index c5ac2dc..2237398 100644
>> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
>> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -55,6 +56,7 @@ static int __devinit dw_i2c_probe(struct platform_device
>> *pdev)
>>struct dw_i2c_dev *dev;
>>struct i2c_adapter *adap;
>>struct resource *mem, *ioarea;
>> + struct i2c_dw_pdata *pdata;
>>int irq, r;
>>
>>/* NOTE: driver uses the static register mapping */
>> @@ -98,6 +100,12 @@ static int __devinit dw_i2c_probe(struct platform_device
>> *pdev)
>>}
>>clk_enable(dev->clk);
>>
>> + pdata = dev_get_platdata(&pdev->dev);
>> + if (pdata && pdata->i2c_recover_bus) {
>> + dev->i2c_recover_bus = pdata->i2c_recover_bus;
>> + dev->recovery_data = &pdev;
>> + }
>> +
>>dev->functionality =
>>I2C_FUNC_I2C |
>>I2C_FUNC_10BIT_ADDR |
>> diff --git a/include/linux/i2c/i2c-designware.h
>> b/include/linux/i2c/i2c-designware.h
>> new file mode 100644
>> index 000..e40ad85
>> --- /dev/null
>> +++ b/include/linux/i2c/i2c-designware.h
>> @@ -0,0 +1,33 @@
>> +/*
>> + * Synopsys DesignWare I2C adapter driver's platform data
>> + *
>> + * Copyright (C) 2012 ST Microelectronics.
>> + * Author: Vincenzo Frascino
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation,
Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function
On Monday 27 February 2012 02:11 PM, Rajeev kumar wrote: On 2/27/2012 1:52 PM, Laxman Dewangan wrote: is selected through select in kconfig The function should take the gpio number and gpio flags for scl and sda, bus freq and number of clock to be sent. Need to pass "number of clock to be sent" or not . I am not very much sure. I think number of clock to be sent is fixed. Yes, it is said 9 clock pulse. But we have observed that sometimes it requires more clock and that's why I wanted to give option to make more generic. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function
On 2/27/2012 1:52 PM, Laxman Dewangan wrote: On Monday 27 February 2012 01:40 PM, Rajeev kumar wrote: On 2/27/2012 12:57 PM, Laxman Dewangan wrote: On Monday 27 February 2012 12:51 PM, Shubhrajyoti Datta wrote: On Fri, Feb 24, 2012 at 5:01 PM, Viresh Kumar wrote: From: Vincenzo Frascino Add optional i2c_recover_bus() function to the Synopsys DesignWare I2C adapter driver that performs i2c bus recovery after timeout. The scope of this routine is to define i2c bus recovery procedure as specified in the i2c protocol Rev. 03 section 3.16 titled "Bus clear". What do you do in the function ? Could we have it in the driver file itself? I think bus recovery mechanism is to send extra clock on SCL line by toggling the pin (using gpio apis) and keep watching of sda line whether it becomes high or not. We can put this algorithms in the some common file (i2c/algos/) and so if any i2c bus driver want to use, they can use it. Little background: I am working on tegra i2c controller and we have similar logic in tegra-i2c driver which we want to upstream. If similar function is in common place, we can use this and need not to duplicating it on every bus driver. I agreed with Laxman, as this is the protocol issue and so it should not be in each individual driver. It should be the part of framework itself. We need to implement something like drivers/i2c/busses/i2c-gpio.c. We need to investigate more on it. I am thinking to put this in drivers/i2c/busses/bus_recovery_gpio.c. This will provide only one function and config variable for this code can be selected from different driver by select option. it will not be enabled as independent driver. Similar to regmap_i2c or regmap_spi which What is this regmap_i2c or regmap_spi, I am not able to locate it. is selected through select in kconfig The function should take the gpio number and gpio flags for scl and sda, bus freq and number of clock to be sent. Need to pass "number of clock to be sent" or not . I am not very much sure. I think number of clock to be sent is fixed. ~Rajeev All gpio related apis should be called on .c file which is implemented. How bus driver gets the corresponding gpio number is specific to bus driver but they need to pass all the information through arguments. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- . -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function
On Monday 27 February 2012 01:40 PM, Rajeev kumar wrote: On 2/27/2012 12:57 PM, Laxman Dewangan wrote: On Monday 27 February 2012 12:51 PM, Shubhrajyoti Datta wrote: On Fri, Feb 24, 2012 at 5:01 PM, Viresh Kumarwrote: From: Vincenzo Frascino Add optional i2c_recover_bus() function to the Synopsys DesignWare I2C adapter driver that performs i2c bus recovery after timeout. The scope of this routine is to define i2c bus recovery procedure as specified in the i2c protocol Rev. 03 section 3.16 titled "Bus clear". What do you do in the function ? Could we have it in the driver file itself? I think bus recovery mechanism is to send extra clock on SCL line by toggling the pin (using gpio apis) and keep watching of sda line whether it becomes high or not. We can put this algorithms in the some common file (i2c/algos/) and so if any i2c bus driver want to use, they can use it. Little background: I am working on tegra i2c controller and we have similar logic in tegra-i2c driver which we want to upstream. If similar function is in common place, we can use this and need not to duplicating it on every bus driver. I agreed with Laxman, as this is the protocol issue and so it should not be in each individual driver. It should be the part of framework itself. We need to implement something like drivers/i2c/busses/i2c-gpio.c. We need to investigate more on it. I am thinking to put this in drivers/i2c/busses/bus_recovery_gpio.c. This will provide only one function and config variable for this code can be selected from different driver by select option. it will not be enabled as independent driver. Similar to regmap_i2c or regmap_spi which is selected through select in kconfig The function should take the gpio number and gpio flags for scl and sda, bus freq and number of clock to be sent. All gpio related apis should be called on .c file which is implemented. How bus driver gets the corresponding gpio number is specific to bus driver but they need to pass all the information through arguments. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function
On 2/27/2012 12:57 PM, Laxman Dewangan wrote: On Monday 27 February 2012 12:51 PM, Shubhrajyoti Datta wrote: On Fri, Feb 24, 2012 at 5:01 PM, Viresh Kumar wrote: From: Vincenzo Frascino Add optional i2c_recover_bus() function to the Synopsys DesignWare I2C adapter driver that performs i2c bus recovery after timeout. The scope of this routine is to define i2c bus recovery procedure as specified in the i2c protocol Rev. 03 section 3.16 titled "Bus clear". What do you do in the function ? Could we have it in the driver file itself? I think bus recovery mechanism is to send extra clock on SCL line by toggling the pin (using gpio apis) and keep watching of sda line whether it becomes high or not. We can put this algorithms in the some common file (i2c/algos/) and so if any i2c bus driver want to use, they can use it. Little background: I am working on tegra i2c controller and we have similar logic in tegra-i2c driver which we want to upstream. If similar function is in common place, we can use this and need not to duplicating it on every bus driver. I agreed with Laxman, as this is the protocol issue and so it should not be in each individual driver. It should be the part of framework itself. We need to implement something like drivers/i2c/busses/i2c-gpio.c. We need to investigate more on it. Best Regards Rajeev --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- . -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
