Hi Tero,
On Monday 12 March 2012 02:49 PM, Tero Kristo wrote:
I see that you removed the second timeout test from this code, but not
> > from the OMAP4 version. Any reason why? Seems like if the second timeout
> > can be removed from one, then it can also be removed from the other?
>
> Actually FWIK, its nteeded in both OMAP3 and OMAP4. The OMAP3
> documentation does no mention about it. but that is just bad
> documentation.
Both documentation and actual functionality appears to be different for
OMAP3 / OMAP4. The status bit on OMAP3 is read / write, and writing 1 to
it clears it. On OMAP4, it is read only and both values 0 / 1 indicate
something has happened. On OMAP3 the bit must be cleared by writing 1 to
it, otherwise it remains high indefinitely and will break all the
subsequent trigger calls. Also, clearing EN_IO_CHAIN on OMAP3 does not
appear to trigger any activity that would change the status of
ST_IO_CHAIN, so there is nothing to poll at the end.
Here is a sample trace I just generated for the trigger on OMAP3:
[ 7.707824] omap3_trigger_io_chain(1): PM_WKST=00000000
[ 7.707855] omap3_trigger_io_chain(2): PM_WKST=00000000
[ 7.707855] omap3_trigger_io_chain(3): PM_WKST=00010000
[ 7.707885] omap3_trigger_io_chain(4): PM_WKST=00000000
[ 7.707977] omap3_trigger_io_chain(5): PM_WKST=00000000
1 = enter trigger function
2 = just after enabling io chain
3 = just after first poll loop
4 = just after clear of io status and disabling of io chain
5 = after udelay(100) from last event (you can see the status bit never
raises)
Ok, I guess then the omap3 and omap4 implementations are indeed
different and should be handled differently. Thanks for the explanation.
regards,
Rajendra
So, you can see that there is no change in the status bit between 4...5,
so there is no point for polling anything there. I even tried changing
the clear of IO status and disabling of IO chain to see if it had any
impact on this result but no. The main point is that we must clear the
status bit at #4, and thus polling for it to change at #5 makes no
sense. We just need to force the register writes to PRCM by doing some
access to the IP block.
Looking at similar trace on omap4:
[ 8.097503] omap4_trigger_io_chain(1): IO=00010020
[ 8.097503] omap4_trigger_io_chain(2): IO=00010320
[ 8.097534] omap4_trigger_io_chain(3): IO=00010320
[ 8.097534] omap4_trigger_io_chain(4): IO=00010020
[ 8.097534] omap4_trigger_io_chain(5): IO=00010020
1 = enter function
2 = just after enabling WUCLK_CTRL
3 = just after poll
4 = just after disabling WUCLK_CTRL
5 = just after poll
Well, the status bit follows the state of the WUCLK_CTRL, but there is
no time to actually poll the registers it seems, their state has already
changed when the value from first read arrives back as the register
access itself is so slow. But... we are not manually clearing the status
bit, thus polling kind of makes sense (and it might make more sense if
some future version of PRCM would allow faster register access.)
I also did both of these tests by caching the register values to memory
(no immediate printks to avoid delays) but the results are still the
same.
--
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
