Hello, On Fri, 13 Jun 2014 08:29:41 -0400, jonsmirl@xxxxxxxxx wrote: > How are CPU revision IDs encoded into the device tree? It is not > reasonable to ask people to manually identify their revision and then > use the right device tree. For example a heat sink may obscure the > markings. The CPU ID is needed for device driver quirks. > > I was thinking of doing something like adding code at early boot that > fixes up the root compatible string. The revision is a > property of the CPU. > > Code changes this: > compatible = "cubietech,cubietruck", "allwinner,sun7i-a20" > to: > compatible = "cubietech,cubietruck", "allwinner,sun7i-a20a", > "allwinner,sun7i-a20" > > Alternatively this could be done in uboot. > > Browsing around the kernel code there seems to be multiple solutions > to this problem. For example this Marvell code modifies the device > driver compatible string. > > http://lxr.free-electrons.com/source/arch/arm/mach-mvebu/board-v7.c#L71 Yes, the way we handle that on Marvell EBU platforms is that we runtime detect the revision of the SoC, and use this information to adjust the Device Tree information for this or that device that is known to have issues/differences. For example, early revisions of Armada XP processors have an issue in the I2C controller which prevents an optimization feature from being used, so the code in board-v7.c detects this early revision, and changes the Device Tree compatible string used to probe the I2C controller, to a different compatible string that lets the driver know that the feature shouldn't be used. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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
