Tony Lindgren <tony@xxxxxxxxxxx> writes: [...] >> This "feature" selection mechanism is clearly not scaling to newer SoCs. >> While this patch works around the problem, IMO, we need a more scalable >> solution. > > Agreed. > >> For features like IVA and ISP (and SGX) which are acutally IP blocks on >> the SoC, not "features" per-se, what we really need to be doing is >> checking for the presence of the IP block, not checking a bit in a >> register that's not consistent across various SoCs. >> >> We already have all the knowledge about whether the IP blocks are >> present in the SoC-specific hwmod data. So checking for the "feature" >> of a specific IP block should instead be done using an >> omap_hwmod_lookup(). >> >> However, there's a bit of a snag because this "feature" detection is >> currently done before the hwmods are registered. >> >> As a quick-and-dirty proof of concept, the patch/hack below moves the >> feature checking after the hwmod init (omap3 only currently) and uses >> omap_hwmod_lookup() to check whether a given IP block exists. >> >> I only did a quick test on one OMAP3 platform (3430/n900) and it seems >> to work. The init order changes need some more thought, as I didn't >> fully validate whether the feature detection can be safely moved later >> for all platforms. >> >> This is just to show the direction we should be taking this SoC >> detection for newer SoCs. > > This should be coordinated with the splitting of feature detection > as posted by Vaibhave in thread "[RFC PATCH] arm:omap: cleanup & split > omap2/3/4_check_revision function" thread. Vaibhav, Feel free to take my proposed patch and develop it further and include it in your rework of the SoC/feature detection. Kevin -- 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
