cc Omar Hi Matt On Fri, 28 Sep 2012, Matt Porter wrote: > The AM33xx support requires some help in hwmod due to the following > comment in arch/arm/mach-omap2/omap_hwmod.c: > /* > * If an IP block contains HW reset lines and any of them are > * asserted, we let integration code associated with that > * block handle the enable. We've received very little > * information on what those driver authors need, and until > * detailed information is provided and the driver code is > * posted to the public lists, this is probably the best we > * can do. > */ > > The approach to deal with the hardware reset (for at least the pruss > hwmod) was to add a generic omap property to properly define this > hardware. The implementation simply deasserts any rst lines that > are called out in the property when the omap_device is > instantiated. This is not the ideal implementation as the sequence is > a bit wrong for pruss since the busy check during the hard reset > will fail, even though it fails in a benign manner. Ideally, we would > want the implementation to observe the ti,deassert-hard-reset property > and use that in omap_hwmod.c:_enable() *after* the module is unidled > and the clocks active. However, this is actually functional for purposes > of getting the uio_pruss driver up and running. Could you please sync with Omar on the hard reset handling? He posted some patches that change the hard reset code. Perhaps you can align on an approach with him? A few general comments: if some new per-IP block flag is needed to control this, the best place for it right now would be the hwmod data in arch/arm/mach-omap2/omap_hwmod_*_data.c, rather than DT. At some point soon, the hard reset handling will be split between a PRM driver and some hwmod bus driver, and it seems best to deal with the DT binding question at that time. That way we don't wind up with a legacy binding that has to be supported over the long term. - Paul -- 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
