[U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Tom Rini <trini@konsulko.com>]

On Mon, May 15, 2017 at 04:38:14PM -0500, Rob Herring wrote:
> On Fri, May 12, 2017 at 7:35 AM, Tom Rini <trini@konsulko.com> wrote:
> > On Fri, May 12, 2017 at 10:16:52AM +0200, Jorge Ramirez wrote:
> >> On 05/12/2017 12:32 AM, Tom Rini wrote:
> >> >>ummmm I am a bit lost at this point, could we recap please?
> >> >Sure.
> >> >
> >> >>let's see: I need to use the pl01x uart on an aarch64 platform and I
> >> >>dont need to enable any clocks for uboot in my SoC. Not now,
> >> >>unlikely ever.
> >> >>
> >> >>Doing what other boards have done to this date is no longer
> >> >>acceptable (ie platform data for the pl01x or using uboots "clock"
> >> >>property embedded in the hacked device trees)
> >> >The only thing we all agree on right now is that "clock" is wrong and
> >> >must be replaced.  I've decided we need to discuss bringing in platform
> >> >data for pl01x.  Once we resolve this, then you can re-spin the series
> >> >(and hopefully have the USB nodes be submitted to Linux too, since
> >> >they're the standard ones and, uh, should just enable USB on your board
> >> >in the kernel too..)  Thanks!
> >>
> >> cool, that sounds great, thanks.
> >>
> >> yeah the usb nodes should be ready pretty soon, I have seen them
> >> circulating already.
> >>
> >> btw, what was it that triggered our discussion?  it is not like any
> >> of the dts files for armv8 boards are verbatim copies of what you
> >> find in the kernel.
> >
> > They've gotten out of sync? Sigh..  I suppose this starts to push me
> > from the "keep them in the kernel" camp to "push them to a separate
> > authoritative repository" camp.
> 
> What's wrong with the standalone DT tree[1] and importing that to
> u-boot periodically?
> 
> I know folks would like a completely separate tree that's not "the
> Linux DT tree", but I don't see that happening any time soon. Do we
> have some Linuxisms in bindings, yes, but in general I think they are
> more the exception than rule and were things that went in with little
> review. These days I'm reviewing pretty much all bindings (not all dts
> files though), so I think it's less of a problem. Logistically, we
> could probably work out how to move bindings and dts files to a
> standalone repository as I could apply bindings and most dts files go
> thru arm-soc maintainers. My biggest concern with a separate
> repository is review because we would quickly loose any review that
> Linux subsystem maintainers do, and no one is beating down my door to
> help be a DT maintainer.

Thinking about this, the key word is authoritative.  Right now we say
(every time I spot a new dts patch) "is this in the kernel yet?" and the
answers break down to:
- Yes, see v4.x
- Yes, see linux-next $tag (or Yes, see maintainer-tree-$X)
- No, we're working on it.

To me, the first is great, the second is OK only in that we're probably
not relying on anything bleeding edge and likely to change between
linux-next $tag and when it finally goes upstream.  The third is where
we're at with this board.  And a problem is that even with the short
kernel release cycle, there is a lot of not wanting to wait until things
get into the next upstream release.

Making a big and possibly wrong assumption, for something like this
board, that doesn't introduce any new bindings, shouldn't this dts be
able to go in quickly, once it of course is otherwise correct?  And
U-Boot (and barebox and the kernel and anyone else that cares) doesn't
want the tree until it was correct either.  And once a tree is in this
upstream, it's just a matter of saying import dts files for $X, taken
from $hash of the device tree repository (or even just included as I
might make myself get in the habit of syncing the tree in post release,
as it'd be on our release cycle, but honestly, I could / should just do
that, even if it's a -rc).

> [1] git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git

... also, so it rebases and isn't stable?  That makes life less fun for
tracing back when we synced $X last.


-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170517/f0e73622/attachment.sig>