re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
v2 - add the iestate 0 check back.
- Remove a stray change.
- Applies on
Hi,
On Thu, Oct 25, 2012 at 12:06:51PM +0530, Shubhrajyoti D wrote:
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Oct 25, 2012 at 12:06:51PM +0530, Shubhrajyoti D wrote:
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every
Hi,
On Thu, Oct 25, 2012 at 12:23:56PM +0530, Shubhrajyoti Datta wrote:
@@ -1268,23 +1276,8 @@ static int omap_i2c_runtime_resume(struct device
*dev)
{
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
- if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
-
On Thu, Oct 25, 2012 at 12:32:39PM +0800, 劉嘉駿 wrote:
Hi Dmitry,
Thanks for review.
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Thursday, October 25, 2012 2:13 AM
To: Scott Liu
Cc: linux-in...@vger.kernel.org;
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
(a simple for loop), when we got to transfer sizes
bigger than the
On Thu, Oct 25, 2012 at 2:30 PM, Felipe Balbi ba...@ti.com wrote:
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi ba...@ti.com wrote:
[...]
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (dev-iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+}
+
static int
Hi,
On Thu, Oct 25, 2012 at 03:04:29PM +0530, Shubhrajyoti Datta wrote:
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi ba...@ti.com wrote:
[...]
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (dev-iestate)
+
Hi,
On Wed, Oct 24, 2012 at 04:41:11PM +0200, Michael Trimarchi wrote:
Hi
On 10/22/2012 11:46 AM, Felipe Balbi wrote:
It's impossible to have Arbitration Lost,
Read Overflow, and Tranmist Underflow all
asserted at the same time.
Those error conditions are mutually exclusive
so
Applies on Felipe's series
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3630 beagle both idle and suspend.
Functional testing on omap4sdp.
Shubhrajyoti D (2):
i2c: omap: re-factor omap_i2c_init function
Implement reset as a seperate function.
This will enable us to make sure that we don't do the
calculation again on every transfer.
Also at probe the reset is not added as the hwmod is doing that
for us.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 28
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 71
Hi
On 10/25/2012 12:10 PM, Felipe Balbi wrote:
Hi,
On Wed, Oct 24, 2012 at 04:41:11PM +0200, Michael Trimarchi wrote:
Hi
On 10/22/2012 11:46 AM, Felipe Balbi wrote:
It's impossible to have Arbitration Lost,
Read Overflow, and Tranmist Underflow all
asserted at the same time.
Those
Hi,
On Thu, Oct 25, 2012 at 12:33:18PM +0200, Michael Trimarchi wrote:
@@ -587,9 +587,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
goto err_i2c_init;
}
- /* We have an error */
- if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
-
Hi,
(a small top-post here, don't forget to keep the patch version in the
subject, I think this is v3 already, so next patch should be v4)
On Thu, Oct 25, 2012 at 03:53:05PM +0530, Shubhrajyoti D wrote:
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the
Hi,
On Thu, Oct 25, 2012 at 03:53:06PM +0530, Shubhrajyoti D wrote:
Implement reset as a seperate function.
This will enable us to make sure that we don't do the
calculation again on every transfer.
Also at probe the reset is not added as the hwmod is doing that
for us.
since you're
On Mon, Oct 22, 2012 at 3:16 PM, Felipe Balbi ba...@ti.com wrote:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 26 +-
1 file changed, 17
Hi,
On Thu, Oct 25, 2012 at 05:10:10PM +0530, Shubhrajyoti Datta wrote:
On Mon, Oct 22, 2012 at 3:16 PM, Felipe Balbi ba...@ti.com wrote:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
In case we loop on IRQ handler until stat is
finally zero, we would end up in a situation
where all I2C transfers would misteriously
timeout because we were not calling complete()
in that situation.
Fix the issue by moving omap_i2c_complete_cmd()
call inside the 'out' label.
Signed-off-by:
Hi,
here's another series for OMAP I2C driver. There are a few cleanups
and one very nice new feature: we can now report how many bytes
we transferred until NACK.
Note that the implemementation for OMAP-I2C turned out to be a
little more complex then I expected, mainly because of the way
I2C_CNT
PM callbacks pass our device pointer as argument
and we don't need to access the platform_device
just to dereference that down to dev-drvdata.
instead, just use dev_get_drvdata() directly.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 6 ++
1 file changed, 2
this is important in cases where client driver
wants to know how many bytes were actually
transferred.
There is one trick here: if transfer is completed,
meaning I2C_CNT reaches zero, then ARDY will be
asserted to let SW know that it can program a
new transfer.
When ARDY is asserted, I2C_CNT is
From: Shubhrajyoti D shubhrajy...@ti.com
In case of a NACK, it's wise to tell our clients
drivers about how many bytes were actually transferred.
Support this by adding an extra field to the struct
i2c_msg which gets incremented the amount of bytes
actually transferred.
Signed-off-by:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is useful mostly in case of NACKs when
client driver wants to know exactly which
byte got NACKed so it doesn't have to resend
all bytes
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
will only contain the bits which were enabled on
IRQENABLE_SET and that will break when we need to
poll for a certain bit which wasn't enabled as an
IRQ source.
One such case is after we finish
Hi,
On Thu, Oct 25, 2012 at 03:25:13PM +0300, Felipe Balbi wrote:
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is useful mostly in case of NACKs when
client driver wants to know
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is useful mostly in case of NACKs when
client driver wants to know exactly which
byte got NACKed so it doesn't have to resend
all bytes
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
PM callbacks pass our device pointer as argument
and we don't need to access the platform_device
just to dereference that down to dev-drvdata.
instead, just use dev_get_drvdata() directly.
Signed-off-by: Felipe Balbi ba...@ti.com
---
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 26 +-
1 file changed, 17 insertions(+), 9
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
In case we loop on IRQ handler until stat is
finally zero, we would end up in a situation
where all I2C transfers would misteriously
timeout because we were not calling complete()
in that situation.
Fix the issue by moving
Hi,
On Thu, Oct 25, 2012 at 06:13:16PM +0530, Santosh Shilimkar wrote:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
In case we loop on IRQ handler until stat is
finally zero, we would end up in a situation
where all I2C transfers would misteriously
timeout because we were not
Hi,
On Thu, Oct 25, 2012 at 06:12:00PM +0530, Santosh Shilimkar wrote:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
will only contain the bits which were enabled on
IRQENABLE_SET and that will break when we need to
poll for a certain bit which wasn't
Hi Felipe, Shubhrajyoti,
On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
From: Shubhrajyoti D shubhrajy...@ti.com
In case of a NACK, it's wise to tell our clients
drivers about how many bytes were actually transferred.
Support this by adding an extra field to the struct
i2c_msg
Hi,
On Thu, Oct 25, 2012 at 06:23:57PM +0530, Santosh Shilimkar wrote:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
will only contain the bits which were enabled on
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is useful mostly in case of NACKs when
client driver wants to know exactly which
On Thursday 25 October 2012 06:22 PM, Felipe Balbi wrote:
Hi,
On Thu, Oct 25, 2012 at 06:23:57PM +0530, Santosh Shilimkar wrote:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
Hi,
Santosh Shilimkar writes:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 26
On Thu, Oct 25, 2012 at 02:57:48PM +0200, Jean Delvare wrote:
Hi Felipe, Shubhrajyoti,
On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
From: Shubhrajyoti D shubhrajy...@ti.com
In case of a NACK, it's wise to tell our clients
drivers about how many bytes were actually
On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
On Thu, Oct 25, 2012 at 02:57:48PM +0200, Jean Delvare wrote:
Hi Felipe, Shubhrajyoti,
On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
From: Shubhrajyoti D shubhrajy...@ti.com
In case of a NACK, it's wise
On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
On Thu, Oct 25, 2012 at 02:57:48PM +0200, Jean Delvare wrote:
Hi Felipe, Shubhrajyoti,
On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
From:
On Thursday 25 October 2012 04:25 PM, Felipe Balbi wrote:
overflow, underflow
these are data errors personally feel may be removed.
and arbitration lost)
will investigate.
and try to make sure if
actually need to reset the controller all the time. I find it really odd
that we're always
On Thu, 25 Oct 2012 14:46:09 +0100, Russell King - ARM Linux wrote:
On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
You also miss one very very very big point. This will break every I2C
using userspace
On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
On Thu, 25 Oct 2012 14:46:09 +0100, Russell King - ARM Linux wrote:
On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
You also miss one very very
HI,
On Thu, Oct 25, 2012 at 06:31:58PM +0530, Santosh Shilimkar wrote:
On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is
Implement reset as a separate function.
This will enable us to make sure that we don't do the
calculation again on every transfer.
Also at probe the reset is not added as the hwmod is doing that
for us.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
some of the errors may not need a reset.
Applies on Felipe's series
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3630 beagle both idle and suspend.
Functional testing on omap4sdp.
Todo: all the error cases may not need a reset.
Shubhrajyoti D (2):
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
v4: add spaces for readability
drivers/i2c/busses/i2c-omap.c | 74
Implement reset as a separate function.
This will enable us to make sure that we don't do the
calculation again on every transfer.
Also at probe the reset is not added as the hwmod is doing that
for us.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
some of the errors may not need a reset.
Applies on Felipe's series
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3630 beagle both idle and suspend.
Functional testing on omap4sdp.
Todo: all the error cases may not need a reset.
Shubhrajyoti D (2):
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
v4: add spaces for readability
drivers/i2c/busses/i2c-omap.c | 74
Hi everyone,
This patchset adds the device tree entry to the CFA-10049 board of its i2c
muxer. This muxer controls sub-buses that contains three Nuvoton NAU7802
ADCs and a NXP PCA955 GPIO expander. Support for these will be added
eventually.
Thanks,
Maxime
Changes from v6:
- Changed the
Allow the i2c-mux-gpio to be used by a device tree enabled device. The
bindings are inspired by the one found in the i2c-mux-pinctrl driver.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Stephen Warren swar...@nvidia.com
Acked-by: Peter Korsgaard
This will allow to add the 3 Nuvoton NAU7802 ADCs and the NXP PCA9555
GPIO expander eventually.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
arch/arm/boot/dts/imx28-cfa10049.dts | 24
1 file changed, 24 insertions(+)
diff --git
+Paul
Felipe Balbi ba...@ti.com writes:
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
Any chance this would help with the bug Paul found with I2C timeouts on
beagle userspace startup?
Kevin
This bug was found
Hi,
On Thu, Oct 25, 2012 at 09:38:06AM -0700, Kevin Hilman wrote:
+Paul
Felipe Balbi ba...@ti.com writes:
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
Any chance this would help with the bug Paul found
58 matches
Mail list logo
