[U-Boot] [linux-sunxi] Re: [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[André Przywara]

On 30/03/18 05:25, Chen-Yu Tsai wrote:

....
>> OK. So meanwhile I have something almost(TM) working:
>> - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of
>> the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx,
>> CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually
>> (I did it the U-Boot way, not pulling in any super-fancy Linux code).
>> Porting this over to H3/H5 and other SoCs should be trivial: copy/paste
>> for now. We can look at how to unify this later.
>> - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is
>> also not too bad, but I seem to miss a bit in here, as it times out.
>> Will debug this tonight.
>> - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking
>> the single bit in :-(
>>
>> That looks tight to still get into this merge window, though, at least
>> if we follow the usual process.
> 
> You could post an initial version during the merge window, and refine it
> in the following two weeks? AFAIK the rules allow for it to be merged for
> the coming release, instead of the next.

Is that so? I had the impression that this was tightened in the last few
releases, so no features would be allowed beyond the merge window
anymore. I will try to send something ASAP, but ...

> Curiously, U-boot repositories don't have -next branches. Is that a
> maintainer preference? Having one would help developers in a way as
> to not have to hunt down prerequisites and try to figure out whether
> they have passed review and will be merged or not, and also avoid
> conflicts with other to-be-queued patches. I know this takes extra
> effort from the maintainer to possibly rebase or manage conflicts
> after a new merge window has opened, as I personally manage sunxi-next
> for the Linux kernel to serve as sort of an integration branch for
> others. I'm asking is it possible to have -next, even just for sunxi.
> 
>>
>> Keep you posted.
> 
> I'm interested. IMHO we don't need full blown drivers like in Linux.
> We should be able to get away with selectively supporting only the
> resources needed for the peripherals supported / actively used in U-boot.
> This goes for clocks, resets, pinctrl, regulators, etc..

So I have something(TM) working now. This is a bit like a can of worms:
- As mentioned above, we need a UCLASS_CLK driver. This is pretty
straightforward, one driver per SoC, then something like:
int sunxi_clk_enable(clk)
{
	switch (clk->id) {
	case CLK_MMC0:
		addr = priv->base + 0x88;
		setbits_le32(clk_base, BIT(31));
(plus get_rate/set_rate)
As you guessed, we just list the clocks we need, in the moment this is
UART and MMC. Adding new clocks is easy, other SoCs can be copy&pasted
for now, we might find a clever way of code sharing later.
One nasty property is the marriage of RESET and CLK in the sunxi-ng
clock binding. So we also need a DM reset driver. I need to wrap my head
around how to instantiate those at the same time from only one compatible.

- Also I realised two days ago that we need a DM pinctrl driver. As this
was on my list anyway, I just bit the bullet. Eventually this isn't as
bad as it sounds, as I resorted to the "pinmux" property to give me the
mux value, so don't need the huge table Linux uses.
But: a similar problem as above, as we need to marry this to the already
existing DM_GPIO driver, because they share a DT node.

So the current status is:
- UCLASS_CLK works and looks fairly reasonable.
- UCLASS_PINCTRL works, just requires adding a pinmux property to each
pinctrl pin group node (just a few), as I proposed last year for Linux[1].
- no UCLASS_RESET for the sunxi-ng resets yet. Hacked badly atm.
- The existing UCLASS_GPIO driver clashes with UCLASS_PINCTRL, so I
disabled the former for now.
- The existing UCLASS_MMC driver got amended to use all of those.

This boots on the Pine64, at least via FEL, with USB, MMC and Ethernet
working in U-Boot proper.

Just in case someone gets impatient:
https://github.com/apritzel/u-boot/commits/sunxi-dm-WIP

I will try to get rid of the hacks and post an RFC.

But, as Jagan mentioned already: eventually the outcome is quite
questionable. For the near future we need the non-DM bits (UART + MMC)
for the SPL still, so we can't get rid of this code. So technically we
support DM_MMC/DM_BLK, but it's not clear what the actual benefit is.

Cheers,
Andre.

[1]
http://archive.armlinux.org.uk/lurker/message/20171113.012520.b50dc300.en.html