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 On Fri, Jun 13, 2014 at 8:09 AM, jonsmirl@xxxxxxxxx <jonsmirl@xxxxxxxxx> wrote: > On Fri, Jun 13, 2014 at 6:15 AM, Maxime Ripard > <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote: >> On Fri, Jun 13, 2014 at 11:54:06AM +0200, Hans de Goede wrote: >>> Hi, >>> >>> On 06/13/2014 10:40 AM, Maxime Ripard wrote: >>> > On Fri, Jun 13, 2014 at 09:32:20AM +0200, Hans de Goede wrote: >>> >> Hi, >>> >> >>> >> On 06/13/2014 12:48 AM, jonsmirl@xxxxxxxxx wrote: >>> >>> On Thu, Jun 12, 2014 at 6:35 PM, Emilio López <emilio@xxxxxxxxxxxxx> wrote: >>> >>>> El 12/06/14 19:11, jonsmirl@xxxxxxxxx escribió: >>> >>>> >>> >>>>> What has replaced sw_get_ic_ver() on 3.15? >>> >>>>> >>> >>>>> Codec code varies on every chip revision A,B,C and A10/20. >>> >>>> >>> >>>> >>> >>>> A10/A20 can be determined by the compatible string. Chip revision is going >>> >>>> to be trickier though, there is no direct replacement of sw_get_ic_ver() >>> >>>> that I'm aware of. sw_get_ic_ver() seems to poke a timer register in the >>> >>>> sun4i case, and SID (for which we do have a driver[1]) on the sun5i case. >>> >>>> >>> >>>> [1] drivers/misc/eeprom/sunxi_sid.c >>> >>> >>> >>> We may have to reimplement it. Codec driver has stuff like this in it. >>> >> >>> >> I think adding some sort of SoC version detection makes sense, so go for it. >>> > >>> > It might, and we probably will come to it eventually, but I don't get >>> > what it would bring here. >>> > >>> > Have different compatible strings for the various revisions of the IP >>> > is much simpler and adds no code at all. >>> >>> That assumes that for a single board only a single revision of the SoC has >>> ever been used. I would not be so sure that that is the case, I'm pretty >>> sure that there were various rruns of the original mk802 A10 version, >>> likely with the first runs having A10 Revision A and later runs >>> revision B. I really don't want to have to do different dts files just >>> to deal with this, that is not helpful from a maintenance pov, and it >>> will also only serve to confuse our end users as they will have no idea >>> which revision of the SoC they have, so solving the differences between >>> the A10 revision A vs B/C with a compatible string seems counter productive. >> >> There's usually two patterns to deal with this: >> - Either have two different DT, depending on the revision of the >> board >> >> - If the board rev hasn't changed, have the machine code come and >> update the DT with the appropriate compatible (see >> http://lxr.free-electrons.com/source/arch/arm/mach-mvebu/board-v7.c#L71) > > This code fixes up the I2C compatible string based on SOC ID. That > doesn't seem right to me. Instead I would have put some code in early > boot that fixes up the root compatible string. The revision is a > property of the CPU. > > Change this: > compatible = "cubietech,cubietruck", "allwinner,sun7i-a20" > to: > compatible = "cubietech,cubietruck", "allwinner,sun7i-a20a", > "allwinner,sun7i-a20" > > Uboot can fix up device trees. Power PC uses it to add memory size and > CPU clock speed. Maybe uboot should fix the compatible string? > > >> >> The latter is much better, for the reasons you mentionned, but in any >> case, the driver itself shouldn't have to worry about that kind of >> things, and only deal with compatibles. >> >> Max >> >> -- >> Maxime Ripard, Free Electrons >> Embedded Linux, Kernel and Android engineering >> http://free-electrons.com > > > > -- > Jon Smirl > jonsmirl@xxxxxxxxx -- 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
