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

[Jagan Teki]

+ Vasily

On Tue, May 8, 2018 at 6:45 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi,
>
> On 08/05/18 11:34, Jagan Teki wrote:
>> On Sun, Apr 1, 2018 at 8:11 AM, Chen-Yu Tsai <wens at csie.org> wrote:
>>> On Sun, Apr 1, 2018 at 9:28 AM, André Przywara <andre.przywara at arm.com> wrote:
>>>> 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.
>>>
>>> We could look at how the DM gpio driver currently does it: The compatible
>>> matches the driver directly, and the DM bind function creates many child
>>> devices using platform data and binds it to the same driver. The device
>>> node is also assigned to the same one. AFAIK you have to figure out how
>>> to lookup a different driver by name for the child device, e.g. a reset
>>> driver to bind to the child device of the clk device.
>>>
>>> In addition, Philipp from Theobroma Systems posted a series some time ago
>>> for sunxi DM conversion, which included some patches that involved creating
>>> multiple uclass devices for the same device node.
>>>
>>>>
>>>> - 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.
>>>
>>> Same as the above I guess? And having the pinctrl driver as the base device
>>> might work out better. It looks like we won't have gpio/pinctrl exclusivity
>>> like we do in Linux, so people should try to avoid shooting themselves in
>>> the foot. We could try denying requests based on whether the pinmux value
>>> in the register is not the default GPIO / disconnected value.
>>>
>>>>
>>>> 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].
>>>
>>> IIRC this didn't go well? We could have a simplified table to cover the
>>> use cases we need (again it's probably just UART + MMC). We don't need
>>> to declare every single pin. Since a function tends to have the same
>>> pinmux value for each used pin within the same pingroup, we could just
>>> have a table that maps [SoC, pingroup, function] to pinmux value. And
>>> you could just ignore the gpio_{in,out} pinmux nodes.
>>>
>>>> - 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.
>>>
>>> My thoughts exactly. We end up with either two drivers, one DM and one not,
>>> or we have a whole bunch of #ifdefs in the DM driver to trim it down for
>>> SPL.
>>
>> what about writing glue mmc spl code? like what we did for spi_flash
>> or drivers/mmc/fsl_esdhc_spl.c
>
> So what is your idea here? To make a small SPL driver which directly
> calls some internal, but exported function from the DM driver, which
> does the actual work? So that the DM driver has all the DM boilerplate
> around that function, and the SPL driver does not? But it sounds hairy
> when it comes to the details ...
> We could get away with just read support, I guess?
>
> Do you feel like giving this a try and see how it looks like?

May be an another option to try, because trying for another stage like
TPL seems doesn't suit for A64.