On Sat, Sep 10, 2016 at 03:11:17AM +0200, Matthijs van Duin wrote: [snip] > On 8 September 2016 at 16:20, Nishanth Menon <nm@xxxxxx> wrote: > > Minor point here > > It's not minor, it's quite crucial. > > > maintaining dts per paper spin is just too impossible to maintain > > Even if the per-spin dtsi just consists of including the common dtsi > and then applying /delete-node/ per peripheral that is disabled in > efuse? (or through firewalling, e.g. on HS devices) > > > the variations if maintained as seperate dts might infact end up being > > larger in number than all the dts we have in arch/arm/boot/dts > > There are 813 dts files there. Even if there were a dra7xx and am57xx > for every value of x (and there really isn't) you wouldn't get > anywhere near there. > > But, fair enough, efuse bits are definitely an excellent way to get > combinatorial explosion. > > Afaik those feature bits are readable through the control module on TI > SoCs though. Assuming such a thing is the norm in SoC world maybe a > "delete-if" property referencing some sort of test on register bits of > a referenced syscon node might do the trick? > > On the cortex-A8 doing auto-detection would be a feasible alternative, > by reusing the existing exception mechanism to trap synchronous > aborts, but e.g. the Cortex-A15 seems to use async aborts for *every* > bus error, which makes things just very awful. I think this still misses one of the keys which is that for the IP block that has been efused (or whatever) into being unusable it's also still true that the IP block needs to be properly turned off. The IP in question wasn't removed from the SoC but rather an ice pick was jammed into a critical path meaning you can't use it and now it's in zombie state. The kernel needs to know about it so that it can finish the job. -- Tom -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
