Hello, Tony!
> The issue I'm seeing on 2430sdp is some earlier regression that
> has started happening over the past year or so.
I don't have 2430sdp. And I couldn't find 2430sdp schematics.
Looks, like this is NDA stuff.
> Of course the issue I'm seeing could be caused by hung twl4030
> PMIC
03 дек. 2014 г., в 22:38, Felipe Balbi написал(а):
> then handle slave interrupts :-) But handle them so that it won't race
> with a master transfer request. Moving omap_i2c_xfer() inside the IRQ
> handler isn't the best way to do it, however.
I do that with care :)
Currently, only 'resize fif
03 дек. 2014 г., в 20:49, Felipe Balbi написал(а):
> It can also be a master receiver and a
> slave transmitter.
Agree, but this unrelated to races.
> Note also that MST bit does *not* auto clear.
Yes, it *does* auto clear!
MST bit automatically clear when IP receive AL.
See TRM [1]. All o
03 дек. 2014 г., в 18:49, Felipe Balbi написал(а):
>
>> 2. I want to avoid changing fifos before message submission, because
>> IP can start receiving message in a slave mode (race).
>
> I2C is not full-duplex. There's no way it will receive any data while
> you're transmitting, right ?
>
I2
Felipe,
Question about the patch[1].
I want to change the code in a way to not touch fifo thresholds for each
message.
Because:
1. dev->threshold is valid only with checking of transfer direction.
So, if last transfer was transmission and ISR get RRDY interrupt from slave
receiver,
then d
03 дек. 2014 г., в 17:49, Felipe Balbi написал(а):
> NAK, if you want to add traces, use, well, tracepoints :-) It makes no
> sense to hack stuff like this.
It's for testing only the problem reported not for upstream :)
The hack stuff like this is to allow for me to see what happens on the Tony
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4563200..53b4234 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c
Carry out NACK and AL handling to main event loop as it should be.
The change affects omap3530 and early boards.
Tested and simulated on omap3730 (Beagleboard XM C).
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c | 39 ++-
1 file
The main reason is to avoid CON register access by omap_i2c_xfer_msg()
function, after transfer was submitted to IP.
Also changed NACK logic to wait ARDY so we can be sure what STP has
been sent on back to back transfers.
Tested on dm3730 (Beagleboard XM C).
Signed-off-by: Alexander Kochetkov
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c | 45 ++---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 66506db..d2dfabe 100644
--- a/drivers/i2c
with
0 and 1.
The change affects omap3530 and early boards.
Tested and simulated on omap3730 (Beagleboard XM C).
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c | 46 -
1 file changed, 23 insertions(+), 23 deletions(-)
diff --
t the patches
from series).
If no, could you check does i2c-omap.c from commit
ca1f8da9ac5ce6e63d8f6933f83fabc1f3f961f4.
(the commit before my changes to kernel) work for you?
Thank you.
Regards,
Alexander.
[1] http://www.spinics.net/lists/linux-i2c/msg17811.html
Alexander Kochetkov (5):
01 дек. 2014 г., в 23:04, Kevin Hilman написал(а):
> Done. Built v3.18-rc7 + these 2 patches using omap2plus_defconfig. Boot
> logs here for your amusement:
Hello, Kevin!
Thank you so much for doing tests.
What a pity you don't have omap2430sdp board in the tests.
Alexander.
--
To unsubscr
01 дек. 2014 г., в 22:58, Tony Lindgren написал(а):
> I think this is a different issue than what I'm seeing.
Hello, Tony!
Thank you for testing!
Could check i2c-omap.c from commit ca1f8da9ac5ce6e63d8f6933f83fabc1f3f961f4.
As all my changes comes after it[1]. So I can understand was the probl
us. As after
every master transfer IP enter into slave receiver mode. ISR must be
ready for events from slave receiver or slave receiver must be
disabled after master transfer to avoid lockups.
Signed-off-by: Alexander Kochetkov
Fixes 079d8af24b948261e1dae5d7df6b31b7bf205cb4 "i2c: o
ta processing loops do disallow accesses to the buffer,
when dev->buf_len is zero. Also added warnings to unhide the bug.
Found by code review.
Signed-off-by: Alexander Kochetkov
Fixes: dd74548ddece4b9d68e5528287a272fa552c81d0 "i2c: omap: resize fifos before
each message"
Reported-
/wsa/linux
(6e79807443cba7397cd855ed29d6faba51d4c893)
Tony, could you check, what the patches fix the problem reported[1]?
Kevin, could you run tests for patches on all omap boards?
Regards,
Alexander.
[1] http://www.spinics.net/lists/linux-i2c/msg17811.html
Alexander Kochetkov (2):
i2c: omap:
29 нояб. 2014 г., в 1:13, Tony Lindgren написал(а):
> Looks like for some time 2430 i2c has not been behaving
> reliably
commit dd74548ddece4b9d68e5528287a272fa552c81d0 ("i2c: omap:
resize fifos before each message") dropped check for dev->buf_len.
As result, data processing loop ca
Hello, Tony!
I just want to know, is multimaster i2c feature is interesting for TI SOC,
so I could send another patches?
Or it's better to leave the thing without changes, as current single master
version
well tested and work?
Also I have a draft version of mixed multimaster/slave version. But
Hello, Tony!
24.11.2014 22:47, Tony Lindgren *:
> If you post a patch, I can test boot with it. Looks like the failing
> ones have i2c rev3.3 on 34xx vs rev4.4 on 36xx.
> So I doubt we just want to change the test for for a higher rev number
> for OMAP_I2C_REV_ON_3430_3530.
You 100% right her
25 нояб. 2014 г., в 22:13, Kevin Hilman написал(а):
> I'll test your patch on all my OMAP boards. Put whatever debug output
> you want, and I'll send you links to all the boot output.
Hello, Kevin!
I've sent the patch[1]. Could you be so kind to run it on all your OMAP boards?
Thank you very
/git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
(6e79807443cba7397cd855ed29d6faba51d4c893)
Signed-off-by: Alexander Kochetkov
Reported-by: Kevin Hilman
Tested-by: Kevin Hilman
---
drivers/i2c/busses/i2c-omap.c | 41 +++--
1 file changed, 39 insertions(
22 нояб. 2014 г., в 21:12, Wolfram Sang написал(а):
> IMO a repeated start is to ensure that two messages arrive at the slave
> without interruption from another master. I can't think why a slave
> should know which type of start that was. In fact, if it does that would
> raise an eyebrow for me
25 нояб. 2014 г., в 17:19, Wolfram Sang написал(а):
> I'll push out this evening to make the boot tests work again. If there
> is more to be investigated, either hurry up and post v3 ;) or let me
> know that you need more time.
Ok, thank you. Let the fix go to the kernel-next.
Maybe small fix t
24 нояб. 2014 г., в 23:05, Alexander Kochetkov написал(а):
> Something (u-boot, may be) leave the bus in the wrong state.
> Really strange.
Actually something wrong with i2c-pullups on i2c.1 bus on fault boards.
May be these are boards without pull-ups?
All beagles doesn't have in
Commit 903c3859f77f9b0aace551da03267ef7a211dbc4 ("i2c: omap: implement
workaround for handling invalid BB-bit values") introduce the error result
in boot test fault on OMAP3530 boards
The patch fix the error (disable i2c bus test for OMAP3530).
Signed-off-by: Alexander Kochet
24 нояб. 2014 г., в 22:47, Tony Lindgren написал(а):
> I'd say by Tuesday as we have multiple automated test systems failing
> as soon as people update their trees. And when they are failing, we
> may miss other breakage happening in linux next.
Fix:
http://marc.info/?l=linux-i2c&m=141686120720
Commit 903c3859f77f9b0aace551da03267ef7a211dbc4 ("i2c: omap: implement
workaround for handling invalid BB-bit values") introduce the error result
in boot test fault on OMAP3530 boards
The patch fix the error (disable i2c bus test for OMAP3530).
Signed-off-by: Alexander Kochet
Guys, I really sorry for that :(
> Just try to boot it with your patch? :)
Yes, may be two-three times (max).
Something (u-boot, may be) leave the bus in the wrong state.
Really strange.
> But the test function should not loop forever in any case I take?
It doesn't loop forever. It finish with
24 нояб. 2014 г., в 22:08, Kevin Hilman написал(а):
> This patch recently hit linux-next (as commit 903c3859f77f) and boot
> breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards
> was bisected down to this commit.
>
> Kevin
>
> [1] http://status.armcloud.us/boot/?next-20141124
23 нояб. 2014 г., в 7:43, Felipe Balbi написал(а):
> maybe there was a typo? I tested on v3.18-rc3 :-)
I do my tests on kernel from angstrom with almost all i2c-omap patches
backported from linux/master.
Then I rebased them to wrong (old) kernel version and posted to the list.
Angstrom kernel
No functional changes.
Signed-off-by: Alexander Kochetkov
Reviewed-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e67b7d0..f276c0c 100644
Delete STAT_AD0 mask as unrelated to current IP (omap1?).
Delete DEBUG conditional around SYSTEST masks group.
Add SYSTEST functional mode masks for SCL and SDA.
Add STAT_BF mask.
Signed-off-by: Alexander Kochetkov
Tested-by: Felipe Balbi
Reviewed-by: Felipe Balbi
---
drivers/i2c/busses/i2c
he reset
is not necessary.
Also corrected return value for AL to -EAGAIN.
Tested on Beagleboard XM C.
Tested on BBB and AM437x Starter Kit by Felipe Balbi.
Signed-off-by: Alexander Kochetkov
Tested-by: Felipe Balbi
Reviewed-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c |6 --
1 f
awback is the need to wait for 10ms before the first transfer.
Tested on Beagleboard XM C.
Tested on BBB and AM437x Starter Kit by Felipe Balbi.
Signed-off-by: Alexander Kochetkov
Tested-by: Felipe Balbi
Reviewed-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 103 +++
ribution/meta-ti.git; branch
angstrom-staging-yocto1.4
With all i2-omap.c patches backported from upstream linux/master
Signed-off-by: Alexander Kochetkov
Alexander Kochetkov (4):
i2c: omap: cleanup register definitions
i2c: omap: implement workaround for handling invalid BB-bit values
i2
22 нояб. 2014 г., в 16:23, Wolfram Sang написал(а):
> Huh, I can't apply this one? Which kernel version is this based on?
v.3.13-rc8
It depends on PATCH 1/4
alexander@ubuntu:git.kernel.org.pub.scm.linux.kernel.git.stable.linux-stable$
git log --pretty=oneline --abbrev-commit -6
204c058 i2c: o
21 нояб. 2014 г., в 3:29, Alexander Kochetkov написал(а):
>>
>> Found by code review. Real impact haven't seen.
>> Tested on Beagleboard XM C.
>
> Does anybody know the "certain rare conditions" when RDR errata appears?
> I tested without luck (Beag
21 нояб. 2014 г., в 19:08, Felipe Balbi написал(а):
> Tested on BBB and AM437x Starter Kit
>
> Tested-by: Felipe Balbi
> Reviewed-by: Felipe Balbi
21 нояб. 2014 г., в 0:10, Aaro Koskinen написал(а):
> I could not see any breakage or anything wrong on OMAP2 & OMAP3.
> On OMAP1 I don't have
he reset
is not necessary.
Also corrected return value for AL to -EAGAIN.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov
---
On 21.10.2014 21:11, Wolfram Sang wrote:
> The errno for AL is -EAGAIN. Curly braces are not needed.
Thank you, Wolfram, fixed.
drivers/i2c/busses
21 нояб. 2014 г., в 3:16, Alexander Kochetkov написал(а):
> commit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR
> and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
> Set) get handled.
It's is seen if open 6d9939f651
C.
Signed-off-by: Alexander Kochetkov
Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 90dcc2
ested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3ffb9c0..47103e7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++
awback is the need to wait for 10ms before the first transfer.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c | 103 +
1 file changed, 103 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/
Delete STAT_AD0 mask as unrelated to current IP (omap1?).
Delete DEBUG conditional around SYSTEST masks group.
Add SYSTEST functional mode masks for SCL and SDA.
Add STAT_BF mask.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c | 10 +++---
1 file changed, 7
No functional changes.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 47103e7..4e3642c 100644
--- a/drivers/i2c/busses/i2c
message "controller timeout" blaming IP,
you get "timeout waiting for bus ready".
What do think about it?
Signed-off-by: Alexander Kochetkov
---
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.ker
Hello,
18 нояб. 2014 г., в 19:12, Wolfram Sang написал(а):
> I got confused with all the patches sent out for his issues. Can you ack
> them once you are fine and mention if you consider them important for
> this or the next release? That would be really helpful!
Duplicate/Obsolete (v1):
https
ACK and AL cases,
I sent them to mailing list.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov
Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
Cc: # v3.7+
---
drivers/i2c/busses/i2c-omap.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/driver
> Still, as of now we can't consider what Alexander mentions a bug. Good
> to get it sorted out, but not -rc material.
>
Actually, I focused on fixing issues then i2c-omap acts as master in a multi
master environment.
And must say, that current linux/mainline driver work perfectly with minor
f
Grygorii Strashko earlier reported solution for the issue.
17 нояб. 2014 г., в 17:41, Grygorii Strashko
написал(а):
> Seems you've got the same issue as I :) long time ago
> https://lkml.org/lkml/2013/6/7/530
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body
42eae0b4fd9c1e8dc10665c55d04bad53 Mon Sep 17 00:00:00 2001
From: Alexander Kochetkov
Date: Mon, 17 Nov 2014 18:35:00 +0400
Subject: i2c: omap: enable traces for debug NACK and AL transfers
Just for testing. Not for Upstream.
Signed-off-by: Alexander Kochetkov
---
dri
ACK and AL cases,
I sent them to mailing list.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov
Cc: # v3.7+
---
drivers/i2c/busses/i2c-omap.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 90dcc2e..9af
Hello again.
> (please, never top-post)
Sorry.
Sorry for the inaccurate presentation of ideas. I am not a native English
speaker.
First about patches:
[PATCH 1/2] and [PATCH 2/2] - intended to solve two independent problems.
They were sent as series, In the future, try not to do so, In order no
> Assuming this is really correct (I haven't tested), you need to add:
To help understanding logic, I'd like to provide event traces (with the patch
applied):
See i2c-omap.c dc418f6e6a8f5021ccf9e9c0957eefae3737168d as a reference.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
Hi Felipe,
Initially you made the change (66b9298878742f08cb6e79b7c7d5632d782fd1e1):
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/i2c/busses/i2c-omap.c?id=66b9298878742f08cb6e79b7c7d5632d782fd1e1
dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
rt status 0 (no error) on aborted transfers.
The patch restore original logic. In case interrupt serviced 100 times just
quit interrupt handler and don't abort active transfer.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 file changed, 1 insertion(+),
).
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 90dcc2e..9af7095 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/d
rt status 0 (no error) on aborted transfers.
The patch restore original logic. In case interrupt serviced 100 times just
quit interrupt handler and don't abort active transfer.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 file changed, 1 insertion(+),
).
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/busses/i2c-omap.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 90dcc2e..9af7095 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/d
60 matches
Mail list logo
