From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 17 May 2017 18:13:11 -0400 Subject: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards In-Reply-To: References: <20170511123547.GC5701@bill-the-cat> <20170511223259.GG5701@bill-the-cat> <20170512123507.GK5701@bill-the-cat> <20170517133319.GP5701@bill-the-cat> Message-ID: <20170517221311.GM4631@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, May 17, 2017 at 09:38:06AM -0500, Rob Herring wrote: > On Wed, May 17, 2017 at 8:33 AM, Tom Rini 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 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: