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.
Max
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
