[linux-sunxi] [PATCH 2/5] arm: allwinner: a64: drop the dummy vcc3v3 regulator in Pine64 DT

From: icenowy@aosc.io (Icenowy Zheng)
Date: 2017-07-21 15:10:26
Also in: linux-devicetree


? 2017?7?21? GMT+08:00 ??11:08:42, Andre Przywara [off-list ref] ??:

Hi,

On 21/07/17 15:38, Maxime Ripard wrote:

quoted

On Fri, Jul 21, 2017 at 02:02:18PM +0100, Andre Przywara wrote:

quoted

Hi,

On 21/07/17 13:49, Icenowy Zheng wrote:

quoted


? 2017?7?21? GMT+08:00 ??8:45:39, Andre Przywara

[off-list ref] ??:

quoted

Hi,

On 19/07/17 17:10, Icenowy Zheng wrote:

quoted

The Pine64 DT used to contain a dummy vcc3v3 regulator, in order

to

quoted

satisfy some device nodes when proper AXP803 regulator support is
available. It's in fact the DCDC1 regulator of AXP803.

Drop the dummy regulator, and fix the reference of this regulator

to

quoted

DCDC1.

Do we really need to have this?
While I see that this is technically correct, it breaks older

kernels,

quoted

which miss the AXP driver. So we can't use this DT for syncing it

into

quoted

U-Boot anymore, while still expecting various kernels (for

instance

quoted

from
distribution installers) to work via UEFI (for which U-Boot

provides

quoted

the
DT). That would be a shame, because we start to see generic arm64
distribution installers to work out of the box.

I see these solutions:
1) We drop this patch, instead add a comment that technically it's
DCDC1. I believe we can't really turn off DCDC1 anyway.
2) We keep theses patches, but don't sync them to U-Boot to have a
universal DT in there which works with every kernel.
3) We keep these patches *and* sync them to U-Boot, but add the

fixed

quoted

regulator back in via a U-Boot specific .dtsi "overlay" snippet.

This

quoted

would take care of the parts that break compatibility. The end

result

quoted

would be similar to 2), then.

The easiest and most maintainable would be 1), but I am OK with 3)

as

quoted

well, though I am not sure this won't get messy in the future and

will

quoted

work for every change that we make.

What do you think?

4) Do nothing.

We only promise old DTs will run with newer kernel, but
we don't promise newer DTs to run with old kernel.And
U-Boot is intended to update less frequently than Linux.

When updateing U-Boot, please update kernel as well.

Which means you tie your firmware to a kernel. I know this is the

old

quoted

embedded approach, but we should really get rid of this, as I don't

see

quoted

how this will work nicely with the Pinebook, for instance (which is

not

quoted

really "embedded" anymore).

U-Boot sits on the SPI flash there, and you are expected to just run

any

quoted

(not only Linux) distribution from a USB pen drive, for instance,

with

quoted

that one firmware version, using UEFI. This already works today, but

is

quoted

only sustainable if we have forward DT compatibility as well.

We've been discussing this over and over and over again.

Don't tell me ;-)
But apart from "We don't care" I haven't got a real solution out of
this
discussion.

quoted

You're using the pinebook as an example, fine.

I believe the current approach for supporting Allwinner boards is
rooted
in some embedded world, where shipping firmware together with some
kernel is standard, especially if there is no on-board storage anyway.

But the Pinebook is clearly not embedded and comes with SPI flash to
boot from, so people might expect to install some Linux distribution on
it.

In fact current version of Pinebook has no SPI Flash.

And with the UEFI support in U-Boot we have a good solution for this
(check the debian-testing arm64 installer), and so far this works:
every
extension we did to the DT was still fine with older kernels - this
particular feature might not work (say Ethernet in kernels < 2.13-rc1),
but at least it doesn't hurt or introduces regressions.

quoted

Please give me the full documented,
reviewed and acked-by binding for all the features the pinebook has.

If you can't, this discussion is pointless, since you will expect
changes in the DT.

It's not about *changes* per se, it's about breaking compatibility,
which can be avoided.
As long as we just *add* features (DE2/HDMI, for instance) and don't
introduce regressions, touching the DT is fine.

And yes: I expect some hiccups with this, but also would hope for
finding some solutions (like the ones sketched in my original email).

Cheers,
Andre.

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help