On 28.05.2013 18:30, Kevin Hilman wrote:
Aida Mynzhasova aida.mynzhas...@skitlab.ru writes:
This patch corrects the base address of IVA2 module on omap3430.
Signed-off-by: Aida Mynzhasova aida.mynzhas...@skitlab.ru
I know it looks a bit weird to have a negative offset like this, but
it's actually correct. These offsets are used relative to
prm_base (on 34xx, it's OMAP3430_PRM_BASE defined in omap34xx.h).
So I suggest you double check the values there, and cross reference to
the PRCM Register Manual section of the TRM (last section of the PRCM
chapter.)
Thanks,
Kevin
Ok, thanks for making it clear.
I thought that it can be a bug, because I made an attempt to run
Linux 3.10-rc3 kernel on Texas Instrument's DM816x evaluation module.
Without making any changes I faced with the kernel crush:
[0.00] Unhandled fault: external abort on non-linefetch (0x1028)
at 0xfa17f8e4
[0.00] Internal error: : 1028 [#1] SMP ARM
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
3.10.0-rc3-1-g0e5443c-dirty #12
[0.00] task: c076fc50 ti: c0764000 task.ti: c0764000
[0.00] PC is at omap2_pwrdm_wait_transition+0x1c/0xac
[0.00] LR is at pwrdm_register_pwrdms+0x15c/0x1ac
[0.00] pc : [c0031698]lr : [c0036010]psr: 6193
[0.00] sp : c0765f28 ip : c07bebe0 fp : 0001
[0.00] r10: c07e6a90 r9 : r8 : c07e6944
[0.00] r7 : c0754a50 r6 : c064f264 r5 : c0775298 r4 : c0773e9c
[0.00] r3 : f8e4 r2 : fa17f8e4 r1 : 0004 r0 : c0775298
[0.00] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[0.00] Control: 10c5387d Table: 80004019 DAC: 0017
[0.00] Process swapper (pid: 0, stack limit = 0xc0764240)
[0.00] Stack: (0xc0765f28 to 0xc0766000)
[0.00] 5f20: c0773e9c c0775298 c064f264
c0754a50 c0773ee4 c0036010
[0.00] 5f40: 35170034 81600134 c05125a8 fa18 8200
c0771348 c07b1b48 c07475ac
[0.00] 5f60: c0771348 c07191fc c0647c40 c0711598 16c0
c0d24fb4 c06450ac c070c148
[0.00] 5f80: c0765f98 c0765f90 c0771134 c0765fdc
[0.00] 5fa0: c0643878 0001 c0748774 c0771134
c076c880 413fc082
[0.00] 5fc0: c07086fc
c0748778
[0.00] 5fe0: 10c53c7d c076c910 c0748774 c0771134 80004059
80008074
[0.00] [c0031698] (omap2_pwrdm_wait_transition+0x1c/0xac) from
[c0036010] (pwrdm_register_pwrdms+0x15c/0x1ac)
[0.00] [c0036010] (pwrdm_register_pwrdms+0x15c/0x1ac) from
[c07191fc] (omap3xxx_powerdomains_init+0x50/0x144)
[0.00] [c07191fc] (omap3xxx_powerdomains_init+0x50/0x144) from
[c0711598] (ti81xx_init_early+0xcc/0x178)
[0.00] [c0711598] (ti81xx_init_early+0xcc/0x178) from
[c070c148] (setup_arch+0x5ac/0x800)
[0.00] [c070c148] (setup_arch+0x5ac/0x800) from [c07086fc]
(start_kernel+0x7c/0x330)
[0.00] [c07086fc] (start_kernel+0x7c/0x330) from [80008074]
(0x80008074)
[0.00] Code: e1d030f8 e5982000 e28330e4 e0822003 (e5921000)
[0.00] ---[ end trace 1b75b31a2719ed1c ]---
So, I tried to find out what's wrong and explored the code of
omap3xxx_powerdomains_init() call. It turned out that powerdomain
initialization for ti81xx platform uses *powerdomains_omap3430_common[]
structures, and when it tries to init iva2_pwrdm kernel crush occures.
After applying my code changes the situation becomes a little bit
better, and the kernel is able to continue it's loading (but still
unable to load completely).
Anyway, maybe it can be a good idea to add new powerdomain structures
for supporting ti81xx platform in mainline kernel. Actually I have
already done some code changes for making current kernel bootable on
DM816x EVM and I'm going to continue my work.
Thanks,
Aida
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
