On Fri, Jun 13, 2014 at 08:09:36AM -0400, [email protected] wrote: > 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"
While this would be true, you'd still have to change the sound codec compatible. And we're back to step 1. > 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? I'm really not fond of pushing everything in the bootloader. This justs moves the mess to some dark corner, is very hard to debug and you shouldn't have to update your bootloader in order to boot the kernel. So, no, it shouldn't. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature
