Hi, On 06/13/2014 12:15 PM, Maxime Ripard 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) > > 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.
OK, then lets do something like the latter. jonsmirl while at it, can you also add a pr_info printing the exact SoC revision detected to the machine code, that is very likely going to be quite useful one of these days. Regards, Hans -- 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.
