[U-Boot] [PATCH v3 13/20] Revert: arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0

[Maxime Ripard]

Hi,

On Fri, Mar 02, 2018 at 04:24:22PM +0000, Andre Przywara wrote:
> On 02/03/18 15:58, Maxime Ripard wrote:
> > On Fri, Mar 02, 2018 at 12:56:52AM +0000, Andre Przywara wrote:
> >> Linux kernels before 4.12-rc1 don't know about the AXP803 PMIC, so can't
> >> enable the MMC driver with the current DT anymore, because that now
> >> depends on this regulator.
> > 
> > Given that only I2C, USB and MMC were supported at the time, is it
> > really worth it? There's a lot of incentive to move to a newer kernel
> > given the minimal support it had at the time.
> 
> Yeah, this is somewhat true, although serial, USB and MMC are somewhat
> enough if one uses a USB Ethernet or WiFi adapter. And the kernel choice
> might not always a decision of the user (thinking of distributions here).
> But I was actually unsure about this as well, and wanted to hear some
> opinions.
> 
> One thing that comes to mind is other OSes. Does anyone know how if for
> instance FreeBSD supports the AXP and its Linux bindings? The whole goal
> of this series is to allow booting OSes with U-Boot's DT copy
> ($fdtcontroladdr), so if this patch would make their life easier, it
> might be worth it.

I thought the DT was only about the hardware (and the firmware to some
extent) and not about a particular implementation?

> Regarding the whole forward/backward compatibility:
> I clearly see the difficulty in coming up with a "perfect" DT from day
> one, especially for badly documented SoCs, where mainlining is driven by
> hobbyists. So I was wondering if we introduce a grace period, where we
> declare the DT "unstable" or "subject to incompatible changes" for some
> releases (not too many). In hindsight we might declare 4.12 the stable
> DT base for the A64, for instance.
> This would allow us to start upstreaming early, with a small feature set
> only (just serial + clocks + pinctrl, as for the H6). Additional
> features (PMIC) might then add small incompatibilities (like this one
> here), until we are reasonably confident about the DT.
> Does that sound useful?

Well, yeah. It's one of reasons I listed when the DT stability was
discussed. I'm glad we reached an agreement on this :)

On a more serious basis, while that would sound reasonable, there's
also the issue that you're basically never done, so that period might
extend indefinitely.

Even on the older SoCs that we first introduce 5 years ago we have to
deal with remodelling the bindings, for mostly three reasons:
  - We have some bindings that we were aware were suboptimal, and the
    stability lockdown took us by surprise, and we got stuck with
    bindings no one really liked.

  - We have been ignoring some issues for quite some time that will
    need to get fixed eventually. For example, the power domains in
    the A31 are in this situation: since we didn't have any device
    that would allow us to test it, and since we couldn't use the
    genpd code for the CPUs in Linux at the time, we don't have any
    power domains described. However, there will probably be a time
    where we will actually need it for example to deal with the GPU.

  - We are still discovering some quirks that need to remodel the
    DT. The DMA bus offset is a good example of that.

For the first one, I guess you could say that it's a bullet we have to
bite. No binding will ever be perfect, and we'll always have to
remodel things as we discover new usecases.

However, the two others are really the one that prevent you from
saying "that's it, we're done" at a particular moment in time.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180309/b0c1d567/attachment-0001.sig>