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

[Rob Herring]

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.

> 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.

Rob