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

Wed May 17 22:13:11 UTC 2017

On Wed, May 17, 2017 at 09:38:06AM -0500, Rob Herring wrote:
> On Wed, May 17, 2017 at 8:33 AM, Tom Rini <trini at konsulko.com> wrote:
> > 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 at 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.
> 
> Maybe it was the 3rd case at the start of this, but it is now in v4.12-rc1.
> 
> Generally, commits in -next are not rebased and should match what ends
> up in mainline. But that's not guaranteed and syncing with -next would
> probably not be the best policy.

Right.  I don't like to take the "it's in -next", but the judgement call
is that it's often going to be fine anyhow.

> > 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?
> 
> New SoC too, so probably a bit more than just a new assembly of
> existing bindings. Worst case is someone submits this just before the
> merge window, it's pulled in just after N-rc1, and doesn't get tagged
> until O-rc1. In this case, the dts was committed on Apr 6 and rc1 was
> tagged May 13. We could look at doing a filtered tree based off of
> -next perhaps. Perhaps we should wait to see if the latency is really
> a problem.
> 
> >  And
> > U-Boot (and barebox and the kernel and anyone else that cares) doesn't
> > want the tree until it was correct either.
> 
> Exactly.
> 
> >  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).
> 
> Usually an -rcX is safe to take, but sometimes bindings do get changed
> during -rc cycle.
> 
> >
> >> [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.
> 
> It is generated with git-filter-branch. So it may be regenerated if
> the generation scripts change. As long as you are tracking kernel tags
> as to what you've imported, then it should not matter. I'm not sure if
> we've rebased recently. It was named that somewhat as a CYA. Ian can
> better comment on this.

Well, I suppose the thing here now is that I'm the squeaky wheel, and
other projects seem to be fine.  I'll give things a harder try on my end
and see where we get from there, wrt problems.  Thanks!

-- 
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/f1dce583/attachment.sig>