This will ease our testing a bit with i2c-tools. Note that DW I2C core
doesn't support I2C_FUNC_SMBUS_QUICK, as it's not capable of slave-
addressing-only I2C transactions.
Signed-off-by: Shinya Kuribayashi
---
drivers/i2c/busses/i2c-designware.c |9 -
1 files changed, 8 insertions(+
As wait_for_completion_interruptible_timeout() will be invoked after
the first call to i2c_dw_xfer_msg() is made whether or not an error is
detected in it, we need to mark ->cmd_complete as completed to avoid a
needless HZ timeout.
Signed-off-by: Shinya Kuribayashi
---
Or we could change the i2
As the driver and hardware always process the given data in parallel,
it would be better to initialize those {tx,rx}_limit or rx_valid
variables just prior to be used.
This will help to send/receive data as much as possible.
Signed-off-by: Shinya Kuribayashi
---
drivers/i2c/busses/i2c-designwar
While we have "buf_len" local variable for dev->tx_buf_len, we don't
have such local variable for dev->tx_buf pointer. While "buf_len" is
restored at first then updated when we're going to process a new i2c_msg
(in WRITE_IN_PROGRESS case), ->tx_buf is never done so.
Such inconsistency makes the
We have some steps at the top of i2c_dw_xfer_msg() to set up the slave
address and enable the DW I2C core. It's executed only when we don't
have STATUS_WRITE_IN_PROGRESS.
Then we need to make sure that STATUS_WRITE_IN_PROGRESS only indicates
that we have a pending i2c_msg to process. In other w
Symptom:
When we're going to send/receive the data with bigger size than the
Tx FIFO length, the I2C transaction will be divided into several
separated transactions, limited by the Tx FIFO length.
Details:
As a hardware feature, DesignWare I2C core emits a STOP condition
wheneve
As a hardware feature, DesignWare I2C core emits a STOP condition
whenever Tx FIFO becomes empty (strictly speaking, whenever the last
byte in the Tx FIFO has been sent out), even if we have more bytes to
be written.
In other words, we must never make "Tx FIFO underrun" happen during
a transactio
In case an i2c_msg, which is currently work-in-progress, has more bytes
to be written, we need to set STATUS_WRITE_IN_PROGRESS _and_ exit from
the msg_write_idx-search loop. Otherwise, we'll overtake the current
index without waiting for transmission completed.
Signed-off-by: Shinya Kuribayashi
* Calculate with accurate conditional expressions from DW manuals.
* Round ic_clk by adding 0.5 as it's important at high ic_clk rate.
* Take into account "tHD;STA" issue for _HCNT calculation.
* Take into account "tf" for _LCNT calculation.
* Add "cond" and "offset" fot further correction require
We couldn't know the original intent for this variable, but at this
point it's useless.
Signed-off-by: Shinya Kuribayashi
---
drivers/i2c/busses/i2c-designware.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware.c
b/drivers/i2c/busses
This driver is originally prepared for the ARM kernel where rich and
well-maintained "clkdev" clock framework is available, and clock name
might not be strictly required. ARM's clkdev does slightly fuzzy
matching where it basically gives preference to "struct device" mathing
over "clock id". As
There's no need to interface using with "struct i2c_adapter" pointer.
Let's use a local "struct dw_i2c_dev" pointer, instead.
Signed-off-by: Shinya Kuribayashi
---
drivers/i2c/busses/i2c-designware.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses
There's no need to interface using with "struct i2c_adapter" pointer.
Let's use a local "struct dw_i2c_dev" pointer, instead.
Signed-off-by: Shinya Kuribayashi
---
drivers/i2c/busses/i2c-designware.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses
Signed-off-by: Shinya Kuribayashi
---
drivers/i2c/busses/i2c-designware.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware.c
b/drivers/i2c/busses/i2c-designware.c
index efddae1..0164092 100644
--- a/drivers/i2c/busses/i2c-design
We're strongly discouraged from using the IC_CLR_INTR register because
it clears all software-clearable interrupts asserted at the moment.
stat = read(IC_INTR_STAT);
:
: <=== Interrupts asserted during this period will be lost
:
read(IC_CLR_INTR);
Use the separately-prepared IC_CLR_* registe
This driver looks originally meant for armel machines where readw()/
writew() works perfectly fine. But that doens't work for big-endian
systems.
This patch converts all 8/16-bit-aware usages to 32-bit variants, so
that the driver works for MIPS big-endian machines, too.
Signed-off-by: Shinya K
Hi Baruch and lists,
Here're various improvements / bug-fixing patches for DW I2C driver.
I'm working with v2.6.27-based kernel, but they must work fine with the
latest mainline kernel.
It's stil in RFC, and I'm working with it for some time. Any comments
or suggestions are highly appreciated.
Hi Jean,
On Mon, Oct 12, 2009 at 12:51:51PM +0200, Jean Delvare wrote:
> Hi Crane,
>
> On Mon, 12 Oct 2009 10:05:18 +0800, Crane Cai wrote:
> > Hi Jean,
> > We have changed the name of SB900 chip, and the source needs change also.
> > Please apply.
> > Thanks,
> > - Crane
> >
> > ---
> > Change
Hi Kyungmin,
On Thu, Oct 8, 2009 at 3:14 PM, Trilok Soni wrote:
> Hi Kyungmin,
>
> Adding linux-i2c as it is i2c client driver and Ben Dooks for samsung
> pwm driver API usage.
>
> On Wed, Oct 7, 2009 at 11:48 AM, Kyungmin Park
> wrote:
>> I2C based ISA1200 haptic driver support.
>> This chip su
On Mon, 12 Oct 2009 18:02:12 +0100, Jonathan Cameron wrote:
> Jean Delvare wrote:
> > The name size really isn't an issue. You won't notice 16 bytes instead
> > of 9. And it's not like we'll have millions of these devices.
>
> I agree, it's merely a question of picking some suitable limit. IDR's
>
Jean Delvare wrote:
> Hi Jonathan,
>
> On Mon, 12 Oct 2009 15:19:07 +0100, Jonathan Cameron wrote:
@@ -60,9 +65,41 @@ static const u8 TSL2550_MODE_RANGE[2] = {
};
/*
+ * IDR to assign each registered device a unique id
+ */
+static DEFINE_IDR(tsl2550_idr);
>>
Hello Aaro!
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Aaro Koskinen
> Sent: Monday, October 12, 2009 5:21 AM
> To: ben-li...@fluff.org; linux-i2c@vger.kernel.org
> Cc: linux-o...@vger.kernel.org; j-pakarav...@ti.
Hello Aaro!
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Aaro Koskinen
> Sent: Monday, October 12, 2009 5:21 AM
> To: ben-li...@fluff.org; linux-i2c@vger.kernel.org
> Cc: linux-o...@vger.kernel.org; j-pakarav...@ti.
Hi Jonathan,
On Mon, 12 Oct 2009 15:19:07 +0100, Jonathan Cameron wrote:
> >> @@ -60,9 +65,41 @@ static const u8 TSL2550_MODE_RANGE[2] = {
> >> };
> >>
> >> /*
> >> + * IDR to assign each registered device a unique id
> >> + */
> >> +static DEFINE_IDR(tsl2550_idr);
> >> +static DEFINE_SPINLOCK
On Mon, 12 Oct 2009 16:13:01 +0100, Jonathan Cameron wrote:
> Hi Jean,
> >
> > On Fri, 09 Oct 2009 15:37:58 +0100, Jonathan Cameron wrote:
> >> Signed-off-by: Jonathan Cameron
> >>
> >> ---
> >> Minimal changes made. Untested due to lack of hardware.
> >> All comments welcome.
> >
> > Thanks for
Hi Jean,
>
> On Fri, 09 Oct 2009 15:37:58 +0100, Jonathan Cameron wrote:
>> Signed-off-by: Jonathan Cameron
>>
>> ---
>> Minimal changes made. Untested due to lack of hardware.
>> All comments welcome.
>
> Thanks for working on this. I can do any amount of testing you want, as
> I have received
For those not following this driver, Jean does raise the issue
of device naming again and I think we really need to settle
this one before progressing with ALS in general.
>
> "2.0"?
True, that would be consistent.
>
>>
>> /*
>> * Defines
>> @@ -44,8 +47,10 @@
>> */
>>
>> struct tsl255
Hi Crane,
On Mon, 12 Oct 2009 10:05:18 +0800, Crane Cai wrote:
> Hi Jean,
> We have changed the name of SB900 chip, and the source needs change also.
> Please apply.
> Thanks,
> - Crane
>
> ---
> Change SB900 to its formal code name Hudson-2.
>
> Signed-off-by: Crane Cai
> ---
> Documentation/
From: Jagadeesh Bhaskar Pakaravoor
Include wake up events for receiver overflow and transmitter
underflow in OMAP_I2C_WE_REG configuration. Also fix a small
typo.
Signed-off-by: Jagadeesh Bhaskar Pakaravoor
Signed-off-by: Aaro Koskinen
---
drivers/i2c/busses/i2c-omap.c |5 -
1 files c
29 matches
Mail list logo
