Kevin Hilman had written, on 11/19/2010 01:41 PM, the following:
I believe the fix we are attempting here is for a specific scenario
which IMHO is different from the issue solved in the link above.
It will also solve the above issue indirectly.
Yes, it indirectly fixes the issue solved by $SUBJECT patch, but what
else does it fix?
Please see [1] - highlights:
a) I dont seem to understand how clock domain idle is being denied by
the patch
b) the mentioned patch[1] should have removed the pwr_domain control
around the secure ram operation - which is the only weakness in that
patch, for power domain control, I like the mentioned patch - but
pwrdomain control is not what is being introduced here.
This secure mode call is currently the only one I'm aware of that does a
WFI. If there are others, then $SUBJECT patch is not enough.
If TI cannot tell us definitively if other secure-mode calls may use
WFI, then we have to assume there are others, and $SUBJECT patch has to
be NAK'd in favor of a more generic fix like the one from Santosh.
Thanks on the unfair beating IMHO, but, I believe I confirmed this
here[2] - Quote: "After a long review, the impacted section is this
logic alone." if you do have other specific SMIs in doubt(the ones we
have verified to my knowledge are the ones around sleep34xx code),
please list them out and I can get confirmation on behalf of TI if WFI
is in use or not. AFAIK, SMIs can be supported by ROMcode and by PPA. is
WFI is being used by PPA - there is no guarantee on the custom
implementations.
For example:
CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE -> has a service ID which could
be implemented by PPA -> TI cannot guarentee that implementations will
never use WFI, from a kernel context, we'd say - dont use wfi - let the
kernel control it, though the actual implementation is upto the
developer of PPA.
Ref:
[1]http://marc.info/?l=linux-omap&m=129019267128364&w=2
[2] http://marc.info/?l=linux-omap&m=129018700620594&w=2
--
Regards,
Nishanth Menon
--
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
