Hi Omar,
thank you for the comments on that.
On 19.10.2011 21:46, Ramirez Luna, Omar wrote:
Hi Vladimir,
On Wed, Oct 19, 2011 at 11:45 AM, Vladimir Zapolskiy<vz@xxxxxxxxx> wrote:
According to OMAP3 TRM access to MMU registers shall be strictly 32-bit
aligned. Sometimes non-linefetch aborts are observed while flushing
TLB, and this fix is intended to get them extincted.
Looks good to be included to avoid confusions about the accesses to
mmu registers, however...
Lately I have seen these aborts, but they don't seem to be related to
the wrong bit size accesses. The TRM indeed forbids other than 32-bit
accesses as it can cause register corruption but doesn't specify if
the corrupted register is the one being accessed, the whole module
registers or else.
Usually the behavior seen during this error, in my case, is that
previous transitions to hibernation fail, and this ultimately leads to
an L3 timeout, but the error has originated in the DSP, the unhandled
abort panic is just another error to the pile. The solution found, was
to move code from the DSP originating a circle path in the L3 (used to
calculate the warm boot address from a dsp va to a pa) causing the
Hibernate failed error. This fix requires a patched baseimage.
Worth to know, maybe I'll get the patched baseimage one day.
While accessing MMU_GFLUSH my sporadic error reports look like
<log>
Unhandled fault: external abort on non-linefetch (0x1008)
</log>
Regardless of potential problems on DSP core side, I'd like to spend
some time refuting my guts feeling that the register access might
coincide with disabled IVA2 clock period.
Signed-off-by: Vladimir Zapolskiy<vz@xxxxxxxxx>
Cc: Omar Ramirez Luna<omar.ramirez@xxxxxx>
For above mentioned reasons, it would be good to change the
description and removing this as a possible fix to the aborts. BTW,
I'm still able to see the aborts with your patch.
After the description change please feel free to add my ack.
To wipe out the confusing info from the commit message, I'll remove the
second sentence about relation to aborts and resend the patch. Thanks
for reviewing.
--
With best wishes,
Vladimir
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
