RFC Audio clocks for sun[457]i, SoC revision detection
Get series with b4
b4 am 20140728124208.GH3952@lukatherVersions newest first
- v1 RFC Latest6 of 8 patches 0 repliesNew
6 of 8 patches are in this archive. The cover letter announces 8.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 2/8 | clk: sunxi: codec clock support | +0 | 0 replies | |
| 4/8 | clk: sunxi: add __iomem markings to MMIO pointers | +0 | 1 reply | |
| 5/8 | clk: sunxi: staticize structures and arrays | +0 | 0 replies | |
| 6/8 | ARM: sunxi: Add PLL2 support | +0 | 0 replies | |
| 8/8 | ARM: sun7i: Add mod1 clock nodes | +0 | 1 reply | |
| 8/8 | ARM: sun7i: Add mod1 clock nodes | +0 | 0 replies |
Reviews trailers per patch
3 of 6 patches have a Reviewed-by or Acked-by.
| Patch | Maxime Ripard |
|---|---|
| 2/8 | A-b |
| 4/8 | A-b |
| 5/8 | A-b |
| 6/8 | |
| 8/8 | |
| 8/8 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [RFC 0/8] Audio clocks for sun[457]i, SoC revision detection
Hi Emilio,
Quoted 6 lines · Emilio L?pez
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 5 lines
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 8 lines
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 2 lines
* 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 3 lines
* 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 4 lines
* 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 3 lines
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.
Quoted 3 lines
If this is the way forward, where should the code live in? The SoC detection is done by reading a register on the timer block on sun4i, and SID on sun5i.
In mach-sunxi I'd say. I've started working on it a few weeks back, in order to use soc-device too, but it's pretty much wip for now.
Signature · 10 lines
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/20140728/1a7acfd7/attachment-0001.sig>