On Mon, Jul 28, 2014 at 10:40:31AM -0400, jonsmirl at gmail.com wrote:

On Mon, Jul 28, 2014 at 8:42 AM, Maxime Ripard
[off-list ref] wrote:

quoted

Hi Emilio,

On Mon, Jul 28, 2014 at 12:49:38AM -0300, Emilio L?pez wrote:

quoted

Hi everyone,

This series adds support for PLL2 on A10 rev B and higher, A10S, A13
and A20. It also includes support for the codec clock as well as
module 1 clocks, used in the audio blocks. There's also two patches
fixing sparse warnings on the driver.

And where is the SoC revision detection you were talking about ? :)

quoted

I'm sending this as RFC as this does not support the A10 rev A PLL2
clock. It seems from the Allwinner code that rev A has a different
register layout, and is programmed with different values. Unfortunately
there's no mention of this on the User Manual, so I'm left to guess
for the most part.

Do you have any reference pointing this out?

quoted

The clock code is not the only part in where rev A is special cased;
there's some register writes just for it on the analog audio driver
as well, so we probably need a way to support this in a generic way.

So, how should we proceed with this? Here are some ideas:
  * Make different device trees with different compatibles. Pros:
    not much extra code. Cons: we don't know the SoC revision on
    devices and/or they may change during the product lifecycle.

Which makes it a pretty poor solution :)

quoted

  * Use different compatibles and change them on U-Boot. Pros: it
    keeps Linux simple. Cons: dependency on a newer bootloader.

Which is a no-go.

quoted

  * Use different compatibles and change them on early boot.
    Pros: compatibility with existing bootloaders. Cons: Need
    code in Linux to fixup the DT

Plus, we don't need to care about having different DT, and let the
user indentify which revision it has. I'm very much in favor of this
solution. And it works for all the boards.

quoted

  * Have a function "int sunxi_soc_revision(void)" that drivers
    can use to check which SoC revision they're running on.
    Pros: no DT fixup. Cons: ugly and less portable if the driver
    ever needs to run on a non-sunxi platform.

Yep.

quoted

I'd like to hear everyone's thoughts on this. From what I've seen
around on LAKML, it seems the last option is the one in widest use, but
I'd appreciate a confirmation.

Mostly for historical reason I'd say. All the newer platforms seem to
handle this by fixing up the DT at the early stages.

I thought we were going to do it like this..
http://lxr.free-electrons.com/source/arch/arm/mach-mvebu/board-v7.c#L71

The machine driver for the A10 would check the CPU revision and then
alter the compatible strings as needed to create new ones that encode
the chip revision level.

In this case it would look for  "allwinner,sun4i-a10-codec" and then
add a compatible string like "allwinner,sun4i-a10a-codec" to the front
of the list so that it will be bound first.

This is what I meant by "fixing up the DT at the early stages", sorry
if it wasn't clear enough :)

Note that we don't add a new compatible, but replace it entirely.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140731/e1348d77/attachment.sig>