On Fri, Jun 13, 2014 at 8:56 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Friday 13 June 2014 14:43:55 Thomas Petazzoni wrote: >> 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. > > I think the best approach always depends on the specific situation, in > particular what the differences are between revisions and how easy to > detect the revision is. > > Ideally all knowledge about different versions of an on-chip device > are kept inside of the driver for that device. E.g. if they fixed a > bug in the audio component, the audio driver should first try to find > out the revision by looking at its own registers. If that doesn't work, > the compatible strings for that device should be different for each > revision and hardcoded in dts sources per board. This was problematic > for the mvebu i2c controller as well, because one board was known to > come in multiple revisions, so a hack was added in the platform code. > > Hanging driver specifics off the top-level compatible string however > doesn't feel right. If the boot loader is going to fix it up, it should > patch both the top-level strings and the devices that are actually > different. I was adding the CPU revision ID to the top level compatible string, nothing specific to the device. By knowing the CPU revision I know which errata to apply. If you patch the device strings, then you have to maintain knowledge of which devices are broken in two places -- the device driver and the machine file where you are patching the strings. > > Arnd -- Jon Smirl jonsmirl@xxxxxxxxx -- 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
