On 10/1/2010 3:28 PM, Nayak, Rajendra wrote:
-----Original Message-----
From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx]
Sent: Thursday, September 30, 2010 9:37 PM
To: Tony Lindgren; Nayak, Rajendra
Cc: linux-omap@xxxxxxxxxxxxxxx; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
Kevin Hilman<khilman@xxxxxxxxxxxxxxxxxxx> writes:
Kevin Hilman<khilman@xxxxxxxxxxxxxxxxxxx> writes:
Tony Lindgren<tony@xxxxxxxxxxx> writes:
* Kevin Hilman<khilman@xxxxxxxxxxxxxxxxxxx> [100929 15:15]:
Tony Lindgren<tony@xxxxxxxxxxx> writes:
* Kevin Hilman<khilman@xxxxxxxxxxxxxxxxxxx> [100928 11:25]:
Tony,
The following pull request will bring hwmod driver conversions for
watchdog, UART and i2c drivers. It is based on your omap-for-linus
branch.
The i2c driver is waiting for final signoff/ack from the upstream
subsystem maintainers, but are otherwise ready to go for broader
testing. After I get the final ack, I will update the branch for a
final pull.
In the meantime, I'd like to get them into l-o master (or omap-testing)
for broader testing.
Tried pulling it but I'm getting tons of these errors on omap2:
Tony,
Can you pull the latest version of my pm-hwmods branch from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-hwmods
This version has the updated patch from Rajendra for i2c as well as some
UART3 fixes for a problem he noticed on 2430 as well.
Getting closer.. Now 2430sdp boots OK. But on N800 (2420) I get the following
very early on:
...
[ 0.000000] Calibrating delay loop... 318.27 BogoMIPS (lpj=1245184)
[ 0.000000] pid_max: default: 32768 minimum: 301
[ 0.000000] Security Framework initialized
[ 0.000000] Mount-cache hash table entries: 512
[ 0.000000] CPU: Testing write buffer coherency: ok
[ 0.000000] Unhandled fault: imprecise external abort (0xc06) at 0x00000000
[ 0.000000] Internal error: : c06 [#1] SMP
[ 0.000000] last sysfs file:
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 Not tainted (2.6.36-rc6-08801-g332f930 #395)
[ 0.000000] PC is at kernel_thread_helper+0x0/0x14
[ 0.000000] LR is at kernel_thread_helper+0x0/0x14
[ 0.000000] pc : [<c004cc94>] lr : [<c004cc94>] psr: 00000093
[ 0.000000] sp : c7825ff8 ip : 00000000 fp : 00000000
[ 0.000000] r10: 00000000 r9 : 00000000 r8 : 00000000
[ 0.000000] r7 : 00000013 r6 : c004cca8 r5 : c00a4dc0 r4 : 00000000
[ 0.000000] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00000000
[ 0.000000] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 0.000000] Control: 00c5387f Table: 80004000 DAC: 00000017
[ 0.000000] Process swapper (pid: 2, stack limit = 0xc78242f8)
[ 0.000000] Stack: (0xc7825ff8 to 0xc7826000)
[ 0.000000] 5fe0: ffffffff ffffffff
[ 0.000000] [<c004cc94>] (kernel_thread_helper+0x0/0x14) from [<ffffffff>] (0xffffffff)
[ 0.000000] Code: c04d9ba8 c04de459 c05ca0a0 c04caf13 (eb01ac97)
[ 0.000000] ---[ end trace 1b75b31a2719ed1c ]---
Hmm, this fault is very early and long before any PM code has
initialzed. I suspect this happens with the master branch too ??
I've reproduced this now, and it doesn't happen on the master branch and
only happens after merge pm-hwmods.
Debugging now...
OK, so this failure is (somehow) related to the i2c hwmods, but I did
not figure out how. Rajendra, can you dig into this? It only seems to
happen on 2420/n800, and all other platforms seem OK.
Hi Kevin,
I was able to reproduce the crash on the n800 and have been debugging it for a while.
Like you said putting a HWMOD_INIT_NO_RESET did not seem to fix it for me, and the
only way I can get the n800 to completely bootup is by removing the sysc completely
for i2c.
That is quite surprising since the only thing that can be done using the sysconfig
on omap2420 is a softreset.
I verified that its not the sysc read itself that causes a crash (clocks seem to be enabled,
idlest seems fine) but somehow just these sysc reads (if I have HWMOD_INIT_NO_RESET set)
seem to be enough to cause the crash.
The issue is that 2420 idlest does not reflect the real status of the
OCP bus clock, but just the fact that the idle_req is asserted or not.
So potentially, the IP is still not accessible when you think it is.
This imprecise external abort always happen when you try to access an IP
that is not properly clock.
BTW, this is exactly the same kind of issue we have with FDIF and ISS on
OMAP4.
The easy quick and dirty fix is to comment out the sysconfig structure
in the hwmod definition. You will then prevent any access to the
sysconfig. Otherwise, I'm quite sure that a small udelay(1000) can help
fixing such issue as well.
Do not forget that 2420 is the very first implementation of the PRCM +
smartidle mechanism... It was broken for most IPs at that time :-)
Regards
Benoit
Nothing gets written back to the sysc register either.
I was suspecting the omap_readl's done in hmwod framework on the 16bit 2420 registers
to be an issue, but I am yet to figure out how.
I am debugging this further, but in the meantime since this is gating all other patches to get merged
in omap-testing, should I just remove the sysc for i2c on 2420? The only
thing it will prevent is a i2c softreset at boot, which anyway does not seem to be causing any
issues on n800.
Regards,
Rajendra
I tried
+ .flags = HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE,
for the i2c hwmods, and that didn't help either. The only thing that
made the system boot further was commenting out the i2c hwmods in the
omap2420_hwmod array.
Attached is the defconfig I used to get a kernel small enough for nolo
to load it on my n810.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
