On Fri, Jun 13, 2014 at 6:15 AM, Maxime Ripard <[email protected]> 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, [email protected] wrote: >> >>> On Thu, Jun 12, 2014 at 6:35 PM, Emilio López <[email protected]> >> >>> wrote: >> >>>> El 12/06/14 19:11, [email protected] 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 [email protected] -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
