Re: CPU revision IDs

[Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>]

On Friday 13 June 2014 14:43:55 Thomas Petazzoni wrote:
> On Fri, 13 Jun 2014 08:29:41 -0400, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 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.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html