| Message ID | 1444841757-28043-6-git-send-email-s.temerkhanov@gmail.com |
|---|---|
| State | Deferred |
| Delegated to: | Tom Rini |
| Headers | show |
On Wed, Oct 14, 2015 at 6:55 PM, Sergey Temerkhanov <s.temerkhanov@gmail.com> wrote: > On some systems, UART initialization is performed before running U-Boot. > This commit allows to skip UART re-initializaion on those systems > > Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> > Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> > > Reviewed-by: Simon Glass <sjg@chromium.org> (...) > diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt > index 61c27d1..0591497 100644 > --- a/doc/device-tree-bindings/serial/pl01x.txt > +++ b/doc/device-tree-bindings/serial/pl01x.txt > @@ -5,3 +5,6 @@ Required properties: > - reg: exactly one register range with length 0x1000 > - clock: input clock frequency for the UART (used to calculate the baud > rate divisor) > + > +Optional properties: > +- u-boot,skip-init: skip UART initialization at start. Again: get this merged in the Linux kernel FIRST. Is it? Yours, Linus Walleij
Hi Linus, On 16 October 2015 at 15:23, Linus Walleij <linus.walleij@linaro.org> wrote: > On Wed, Oct 14, 2015 at 6:55 PM, Sergey Temerkhanov > <s.temerkhanov@gmail.com> wrote: > >> On some systems, UART initialization is performed before running U-Boot. >> This commit allows to skip UART re-initializaion on those systems >> >> Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> >> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> >> >> Reviewed-by: Simon Glass <sjg@chromium.org> > (...) > >> diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt >> index 61c27d1..0591497 100644 >> --- a/doc/device-tree-bindings/serial/pl01x.txt >> +++ b/doc/device-tree-bindings/serial/pl01x.txt >> @@ -5,3 +5,6 @@ Required properties: >> - reg: exactly one register range with length 0x1000 >> - clock: input clock frequency for the UART (used to calculate the baud >> rate divisor) >> + >> +Optional properties: >> +- u-boot,skip-init: skip UART initialization at start. > > Again: get this merged in the Linux kernel FIRST. Is it? We had a little bit of a chat about this at ELCE. It would be great to get these changes merged with the kernel but the amount of push-back/energy it requires is still excessive IMO. Any thoughts? Regards, Simon
On Fri, Oct 16, 2015 at 04:27:31PM -0600, Simon Glass wrote: > Hi Linus, > > On 16 October 2015 at 15:23, Linus Walleij <linus.walleij@linaro.org> wrote: > > On Wed, Oct 14, 2015 at 6:55 PM, Sergey Temerkhanov > > <s.temerkhanov@gmail.com> wrote: > > > >> On some systems, UART initialization is performed before running U-Boot. > >> This commit allows to skip UART re-initializaion on those systems > >> > >> Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> > >> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> > >> > >> Reviewed-by: Simon Glass <sjg@chromium.org> > > (...) > > > >> diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt > >> index 61c27d1..0591497 100644 > >> --- a/doc/device-tree-bindings/serial/pl01x.txt > >> +++ b/doc/device-tree-bindings/serial/pl01x.txt > >> @@ -5,3 +5,6 @@ Required properties: > >> - reg: exactly one register range with length 0x1000 > >> - clock: input clock frequency for the UART (used to calculate the baud > >> rate divisor) > >> + > >> +Optional properties: > >> +- u-boot,skip-init: skip UART initialization at start. > > > > Again: get this merged in the Linux kernel FIRST. Is it? > > We had a little bit of a chat about this at ELCE. It would be great to > get these changes merged with the kernel but the amount of > push-back/energy it requires is still excessive IMO. Any thoughts? But it also requires that we try. Did we try here? My first thought is that there's a number of things it would be nice to say "don't re-init stuff" to the kernel as well.
Hi Tom, On 16 October 2015 at 18:23, Tom Rini <trini@konsulko.com> wrote: > On Fri, Oct 16, 2015 at 04:27:31PM -0600, Simon Glass wrote: >> Hi Linus, >> >> On 16 October 2015 at 15:23, Linus Walleij <linus.walleij@linaro.org> wrote: >> > On Wed, Oct 14, 2015 at 6:55 PM, Sergey Temerkhanov >> > <s.temerkhanov@gmail.com> wrote: >> > >> >> On some systems, UART initialization is performed before running U-Boot. >> >> This commit allows to skip UART re-initializaion on those systems >> >> >> >> Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> >> >> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> >> >> >> >> Reviewed-by: Simon Glass <sjg@chromium.org> >> > (...) >> > >> >> diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt >> >> index 61c27d1..0591497 100644 >> >> --- a/doc/device-tree-bindings/serial/pl01x.txt >> >> +++ b/doc/device-tree-bindings/serial/pl01x.txt >> >> @@ -5,3 +5,6 @@ Required properties: >> >> - reg: exactly one register range with length 0x1000 >> >> - clock: input clock frequency for the UART (used to calculate the baud >> >> rate divisor) >> >> + >> >> +Optional properties: >> >> +- u-boot,skip-init: skip UART initialization at start. >> > >> > Again: get this merged in the Linux kernel FIRST. Is it? >> >> We had a little bit of a chat about this at ELCE. It would be great to >> get these changes merged with the kernel but the amount of >> push-back/energy it requires is still excessive IMO. Any thoughts? > > But it also requires that we try. Did we try here? My first thought is > that there's a number of things it would be nice to say "don't re-init > stuff" to the kernel as well. See the thread that ends here: http://lists.denx.de/pipermail/u-boot/2015-July/219283.html Regards, Simon
On Sat, Oct 17, 2015 at 12:27 AM, Simon Glass <sjg@chromium.org> wrote: > On 16 October 2015 at 15:23, Linus Walleij <linus.walleij@linaro.org> wrote: >> Again: get this merged in the Linux kernel FIRST. Is it? > > We had a little bit of a chat about this at ELCE. It would be great to > get these changes merged with the kernel but the amount of > push-back/energy it requires is still excessive IMO. Any thoughts? I'm sorry but DT is standardization, and while I know how stinky it is to be first somewhere and having to pave the road for everyone else, in the long run it's worth it. I think when we switched the entire kernel to DT it was to get "more order", and this is the cost that comes with that order: more review. I will go in and answer the comment on the DT mailing list so there is some push atleast. Yours, Linus Walleij
Hi Linus, On 19 October 2015 at 01:15, Linus Walleij <linus.walleij@linaro.org> wrote: > On Sat, Oct 17, 2015 at 12:27 AM, Simon Glass <sjg@chromium.org> wrote: >> On 16 October 2015 at 15:23, Linus Walleij <linus.walleij@linaro.org> wrote: > >>> Again: get this merged in the Linux kernel FIRST. Is it? >> >> We had a little bit of a chat about this at ELCE. It would be great to >> get these changes merged with the kernel but the amount of >> push-back/energy it requires is still excessive IMO. Any thoughts? > > I'm sorry but DT is standardization, and while I know how stinky it is to > be first somewhere and having to pave the road for everyone else, > in the long run it's worth it. I think when we switched the entire kernel > to DT it was to get "more order", and this is the cost that comes with > that order: more review. > > I will go in and answer the comment on the DT mailing list so there is > some push atleast. Perhaps if we could see some movement then it would provide encouragement to continue. So far I cannot recall seeing a single U-Boot device tree change accepted in the 4 years I've been involved. That's not to say it hasn't happened, and I hope it is just a reflection on my memory rather than the difficulty level. Regards, Simon
Jon & Grant especially: On Mon, Oct 19, 2015 at 2:44 PM, Simon Glass <sjg@chromium.org> wrote: > Me >> I will go in and answer the comment on the DT mailing list so there is >> some push atleast. > > Perhaps if we could see some movement then it would provide > encouragement to continue. So far I cannot recall seeing a single > U-Boot device tree change accepted in the 4 years I've been involved. > That's not to say it hasn't happened, and I hope it is just a > reflection on my memory rather than the difficulty level. OK this isn't working. I think the problem is that DT bindings have traditionally been merged to the kernel by different subsystem maintainers. That means mailing them and their mailing lists and this is IMO too complex for U-Boot people (or other external people) to have to deal with. As subsystem maintainer I'm not very happy about being the one responsible either. The MAINTAINERS entry for device tree bindings does not state a git tree and I've never seen any of the maintainers send a pull request for DT binding files. (Beat me up properly if you have, guys.) I've seen Grant send some at times. I suggest sending U-Boot DT bindings to not only devicetree@vger.kernel.org but also, as indicated, to Jon Corbet and linux-doc. If noone cares to comment in two weeks, Jon can merge them, breaking the status quo on external DT bindings. The DT bindings maintainance has sadly been a very sad story and if the Linux kernel should be the canon repository for them, we need to find a simple way for external projects to contribute. Just mailing them to devicetree@vger obviously stands the risk of just ending up in the memory hole. Jon, are you OK with taking on this or do we need to find another way of funneling external DT bindings? Or do you want to do this Grant? Yours, Linus Walleij
On Mon, Oct 19, 2015 at 02:57:22PM +0200, Linus Walleij wrote: > Jon & Grant especially: > > On Mon, Oct 19, 2015 at 2:44 PM, Simon Glass <sjg@chromium.org> wrote: > > Me > >> I will go in and answer the comment on the DT mailing list so there is > >> some push atleast. > > > > Perhaps if we could see some movement then it would provide > > encouragement to continue. So far I cannot recall seeing a single > > U-Boot device tree change accepted in the 4 years I've been involved. > > That's not to say it hasn't happened, and I hope it is just a > > reflection on my memory rather than the difficulty level. > > OK this isn't working. > > I think the problem is that DT bindings have traditionally been merged to > the kernel by different subsystem maintainers. That means mailing them > and their mailing lists and this is IMO too complex for U-Boot people > (or other external people) to have to deal with. As subsystem > maintainer I'm not very happy about being the one responsible either. > > The MAINTAINERS entry for device tree bindings does not state a > git tree and I've never seen any of the maintainers send a pull request for > DT binding files. (Beat me up properly if you have, guys.) I've seen > Grant send some at times. From Rob Herring Date Tue, 1 Sep 2015 16:20:13 -0500 Subject [GIT PULL] DeviceTree for 4.3 https://lkml.org/lkml/2015/9/1/526 > I suggest sending U-Boot DT bindings to not only > devicetree@vger.kernel.org > but also, as indicated, to Jon Corbet and linux-doc. I have no problem with patches going to an extended set of lists. > If noone cares to comment in two weeks, Jon can merge them, > breaking the status quo on external DT bindings. > > The DT bindings maintainance has sadly been a very sad story and if > the Linux kernel should be the canon repository for them, we > need to find a simple way for external projects to contribute. Just > mailing them to devicetree@vger obviously stands the risk of just > ending up in the memory hole. Rob, we should organise rotating the reponsibility of picking things up. I'd been meaning to organise something official previously, and this is a good kick to do so. Thanks, Mark.
On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > Jon & Grant especially: > > On Mon, Oct 19, 2015 at 2:44 PM, Simon Glass <sjg@chromium.org> wrote: >> Me >>> I will go in and answer the comment on the DT mailing list so there is >>> some push atleast. >> >> Perhaps if we could see some movement then it would provide >> encouragement to continue. So far I cannot recall seeing a single >> U-Boot device tree change accepted in the 4 years I've been involved. >> That's not to say it hasn't happened, and I hope it is just a >> reflection on my memory rather than the difficulty level. Sorry, but anything is with "uboot,*" is going to be an uphill battle. The same is true for "linux,*" properties. There's only 2-3 linux ones that have gone in that timeframe and not without much discussion. > OK this isn't working. > > I think the problem is that DT bindings have traditionally been merged to > the kernel by different subsystem maintainers. That means mailing them > and their mailing lists and this is IMO too complex for U-Boot people > (or other external people) to have to deal with. As subsystem > maintainer I'm not very happy about being the one responsible either. > > The MAINTAINERS entry for device tree bindings does not state a > git tree and I've never seen any of the maintainers send a pull request for > DT binding files. (Beat me up properly if you have, guys.) I've seen > Grant send some at times. Err, what? $ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline Documentation/devicetree/ 4401555 Merge tag 'devicetree-fixes-for-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux f1a3c0b Merge tag 'devicetree-for-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux 4da3064 Merge tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux d56a669 Merge tag 'devicetree-for-4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux 7505256 Merge tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux 3d52c5b Merge tag 'devicetree-fixes-for-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux cdd3054 Merge tag 'devicetree-for-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux b8de08d Merge tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux 7ef58b3 Merge tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux 2e29a6d Merge tag 'devicetree-fixes-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux e98d6e7 Merge tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux 4d3afba Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux ae36e95 Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux d270506 Merge tag 'devicetree-for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux into next 345ef87 Merge tag 'dt-fixes-for-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux b9f2b21 Merge tag 'dt-for-linus' of git://git.secretlab.ca/git/linux bbb1955 Merge tag 'dt-fixes-for-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux 4d8880a Merge tag 'devicetree-for-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux 24cb412 Merge tag 'dt-fixes-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux 10d0c97 Merge tag 'devicetree-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux 31f7c3a Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux 74b9272 Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux ff9129b Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux 30c67e9 Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux b3cdda2 Merge tag 'dt-for-linus' of git://git.secretlab.ca/git/linux 3aad3f0 Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux e327955 Merge tags 'dt-for-linus', 'gpio-for-linus' and 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6 d3b43e1 Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6 b0885d0 Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6 b58ed04 Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6 a54dfb1 Merge tag 'dt-for-3.7' of git://sources.calxeda.com/kernel/linux 7fe0b14 Merge tag 'spi-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc f14121a Merge tag 'dt-for-3.6' of git://sources.calxeda.com/kernel/linux b1bf7d4 Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6 0708500 Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6 e152c38 Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6 7bf97e1 Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6 5f0e685 Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6 f8974cb Merge tag 'dt-for-linus' of git://git.secretlab.ca/git/linux-2.6 The DT core code and bindings (which don't go thru subsystem trees) go together. The maintainer issues with DT are on binding review bandwidth, not so much on there is no one applying them. I'm sure we've missed things though. > I suggest sending U-Boot DT bindings to not only > devicetree@vger.kernel.org > but also, as indicated, to Jon Corbet and linux-doc. I'd suggest devicetree-spec@vger for common things. Perhaps we need a better name, but the whole point of this was to separate the common issues from the firehose and have multiple OS participation. > If noone cares to comment in two weeks, Jon can merge them, > breaking the status quo on external DT bindings. Did someone tell Jon to drink from that firehose? > The DT bindings maintainance has sadly been a very sad story and if > the Linux kernel should be the canon repository for them, we > need to find a simple way for external projects to contribute. Just > mailing them to devicetree@vger obviously stands the risk of just > ending up in the memory hole. > > Jon, are you OK with taking on this or do we need to find another way > of funneling external DT bindings? Or do you want to do this Grant? Grant is stepping away from maintainer duties. In any case, I don't think the problem here is bindings not getting picked up. The instances I'm aware of the bindings were reviewed and commented on. Rob > > Yours, > Linus Walleij > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
On Wed, Oct 14, 2015 at 11:55 AM, Sergey Temerkhanov <s.temerkhanov@gmail.com> wrote: > On some systems, UART initialization is performed before running U-Boot. > This commit allows to skip UART re-initializaion on those systems > > Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> > Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> > > Reviewed-by: Simon Glass <sjg@chromium.org> I'll comment on this now that I'm here, but as the rest of the thread said, please send to DT list. > diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt > index 61c27d1..0591497 100644 > --- a/doc/device-tree-bindings/serial/pl01x.txt > +++ b/doc/device-tree-bindings/serial/pl01x.txt > @@ -5,3 +5,6 @@ Required properties: > - reg: exactly one register range with length 0x1000 > - clock: input clock frequency for the UART (used to calculate the baud > rate divisor) > + > +Optional properties: > +- u-boot,skip-init: skip UART initialization at start. What are you trying to accomplish by skipping? stdout-path can take options now, so what about making it an option there: stdout-path = &serial0:no-init I have similar concerns with this as I did with the early init flag. This requires the dtb and u-boot to be in sync. For example, you have this option in the dtb, but then you add clock initialization to your platform which changes the default clock frequency of the UART. Now if you boot with an older dtb and new u-boot, then it will break because the UART is at the wrong baudrate. Rob
On Mon, Oct 19, 2015 at 06:44:25AM -0600, Simon Glass wrote: > Hi Linus, > > On 19 October 2015 at 01:15, Linus Walleij <linus.walleij@linaro.org> wrote: > > On Sat, Oct 17, 2015 at 12:27 AM, Simon Glass <sjg@chromium.org> wrote: > >> On 16 October 2015 at 15:23, Linus Walleij <linus.walleij@linaro.org> wrote: > > > >>> Again: get this merged in the Linux kernel FIRST. Is it? > >> > >> We had a little bit of a chat about this at ELCE. It would be great to > >> get these changes merged with the kernel but the amount of > >> push-back/energy it requires is still excessive IMO. Any thoughts? > > > > I'm sorry but DT is standardization, and while I know how stinky it is to > > be first somewhere and having to pave the road for everyone else, > > in the long run it's worth it. I think when we switched the entire kernel > > to DT it was to get "more order", and this is the cost that comes with > > that order: more review. > > > > I will go in and answer the comment on the DT mailing list so there is > > some push atleast. > > Perhaps if we could see some movement then it would provide > encouragement to continue. So far I cannot recall seeing a single > U-Boot device tree change accepted in the 4 years I've been involved. > That's not to say it hasn't happened, and I hope it is just a > reflection on my memory rather than the difficulty level. I think there's a few things that need to be kept in mind. First, the DT world is changing compared to where it was a year ago, and even more so since August or so (LPC?). There should be less of a stuck in limbo problem. The second is that since we aren't using DT as free-form replacement for values shoved in a C header, it is a lot more work to get things agreed to and merged with our upstream here. And third (and maybe this is where devicetree-spec@vger.kernel.org comes in) is that if this is really going to be some useful and OS-agnostic description of the hardware then yes, we do need some way to say 'here is what the clock freq is once released from ROM'. All of that said, maybe "no re-init of console port" is not quite right for the UART node (maybe a property of the stdout-path to note this condition as Rob suggests).
On Sun, Oct 18, 2015 at 08:41:59PM -0600, Simon Glass wrote: > Hi Tom, > > On 16 October 2015 at 18:23, Tom Rini <trini@konsulko.com> wrote: > > On Fri, Oct 16, 2015 at 04:27:31PM -0600, Simon Glass wrote: > >> Hi Linus, > >> > >> On 16 October 2015 at 15:23, Linus Walleij <linus.walleij@linaro.org> wrote: > >> > On Wed, Oct 14, 2015 at 6:55 PM, Sergey Temerkhanov > >> > <s.temerkhanov@gmail.com> wrote: > >> > > >> >> On some systems, UART initialization is performed before running U-Boot. > >> >> This commit allows to skip UART re-initializaion on those systems > >> >> > >> >> Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> > >> >> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> > >> >> > >> >> Reviewed-by: Simon Glass <sjg@chromium.org> > >> > (...) > >> > > >> >> diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt > >> >> index 61c27d1..0591497 100644 > >> >> --- a/doc/device-tree-bindings/serial/pl01x.txt > >> >> +++ b/doc/device-tree-bindings/serial/pl01x.txt > >> >> @@ -5,3 +5,6 @@ Required properties: > >> >> - reg: exactly one register range with length 0x1000 > >> >> - clock: input clock frequency for the UART (used to calculate the baud > >> >> rate divisor) > >> >> + > >> >> +Optional properties: > >> >> +- u-boot,skip-init: skip UART initialization at start. > >> > > >> > Again: get this merged in the Linux kernel FIRST. Is it? > >> > >> We had a little bit of a chat about this at ELCE. It would be great to > >> get these changes merged with the kernel but the amount of > >> push-back/energy it requires is still excessive IMO. Any thoughts? > > > > But it also requires that we try. Did we try here? My first thought is > > that there's a number of things it would be nice to say "don't re-init > > stuff" to the kernel as well. > > See the thread that ends here: > > http://lists.denx.de/pipermail/u-boot/2015-July/219283.html Yes, I think maybe Geert was waiting for a reply or respin?
Hi Rob, On 19 October 2015 at 14:14, Rob Herring <robherring2@gmail.com> wrote: > On Wed, Oct 14, 2015 at 11:55 AM, Sergey Temerkhanov > <s.temerkhanov@gmail.com> wrote: >> On some systems, UART initialization is performed before running U-Boot. >> This commit allows to skip UART re-initializaion on those systems >> >> Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> >> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> >> >> Reviewed-by: Simon Glass <sjg@chromium.org> > > I'll comment on this now that I'm here, but as the rest of the thread > said, please send to DT list. > >> diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt >> index 61c27d1..0591497 100644 >> --- a/doc/device-tree-bindings/serial/pl01x.txt >> +++ b/doc/device-tree-bindings/serial/pl01x.txt >> @@ -5,3 +5,6 @@ Required properties: >> - reg: exactly one register range with length 0x1000 >> - clock: input clock frequency for the UART (used to calculate the baud >> rate divisor) >> + >> +Optional properties: >> +- u-boot,skip-init: skip UART initialization at start. > > What are you trying to accomplish by skipping? > > stdout-path can take options now, so what about making it an option there: > > stdout-path = &serial0:no-init > > I have similar concerns with this as I did with the early init flag. > This requires the dtb and u-boot to be in sync. For example, you have > this option in the dtb, but then you add clock initialization to your > platform which changes the default clock frequency of the UART. Now if > you boot with an older dtb and new u-boot, then it will break because > the UART is at the wrong baudrate. If you are saying what I think you are saying, U-Boot expects the device tree that IT uses for configuration to come from the same commit as the source code. It doesn't support anything else as the DTB is bundled with (and replaced at the same time as) U-Boot.. You would be on your own in that case. Regards, Simon
On Mon, Oct 19, 2015 at 9:21 PM, Rob Herring <robh@kernel.org> wrote: > On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij <linus.walleij@linaro.org> wrote: >> The MAINTAINERS entry for device tree bindings does not state a >> git tree and I've never seen any of the maintainers send a pull request for >> DT binding files. (Beat me up properly if you have, guys.) I've seen >> Grant send some at times. > > Err, what? > > $ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline > Documentation/devicetree/ OK nice, bad research from me. My sloppy statement was based on this: OPEN FIRMWARE AND FLATTENED DEVICE TREE M: Rob Herring <robh+dt@kernel.org> M: Frank Rowand <frowand.list@gmail.com> M: Grant Likely <grant.likely@linaro.org> L: devicetree@vger.kernel.org W: http://www.devicetree.org/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git S: Maintained F: drivers/of/ F: include/linux/of*.h F: scripts/dtc/ > The DT core code and bindings (which don't go thru subsystem trees) go > together. I guess I should just send a patch adding F: Documentation/devicetree/* ...and hope things get better from that. >> I suggest sending U-Boot DT bindings to not only >> devicetree@vger.kernel.org >> but also, as indicated, to Jon Corbet and linux-doc. > > I'd suggest devicetree-spec@vger for common things. Perhaps we need a > better name, but the whole point of this was to separate the common > issues from the firehose and have multiple OS participation. Hm, wasn't devicetree@vger.kernel.org supposed to be for that? >> If noone cares to comment in two weeks, Jon can merge them, >> breaking the status quo on external DT bindings. > > Did someone tell Jon to drink from that firehose? I'm sorry, I guess this whole mail was something I wrote in light panic over the increasing threat from the separatists. Yours, Linus Walleij
On Tue, Oct 20, 2015 at 10:10 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, Oct 19, 2015 at 9:21 PM, Rob Herring <robh@kernel.org> wrote: >> On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > >> Err, what? >> >> $ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline >> Documentation/devicetree/ > > OK nice, bad research from me. My sloppy statement was > based on this: > > OPEN FIRMWARE AND FLATTENED DEVICE TREE > M: Rob Herring <robh+dt@kernel.org> > M: Frank Rowand <frowand.list@gmail.com> > M: Grant Likely <grant.likely@linaro.org> > L: devicetree@vger.kernel.org > W: http://www.devicetree.org/ > T: git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git > S: Maintained > F: drivers/of/ > F: include/linux/of*.h > F: scripts/dtc/ > >> The DT core code and bindings (which don't go thru subsystem trees) go >> together. > > I guess I should just send a patch adding > > F: Documentation/devicetree/* > > ...and hope things get better from that. Ah yeah now I also woke up properly... so there is a special group of people listed under another heading for this, and I should know that, mea culpa. OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS M: Rob Herring <robh+dt@kernel.org> M: Pawel Moll <pawel.moll@arm.com> M: Mark Rutland <mark.rutland@arm.com> M: Ian Campbell <ijc+devicetree@hellion.org.uk> M: Kumar Gala <galak@codeaurora.org> L: devicetree@vger.kernel.org S: Maintained F: Documentation/devicetree/ F: arch/*/boot/dts/ F: include/dt-bindings/ So can we add your git tree as T: here and replace Grant's tree in the overall DT entry above it? Yours, Linus Walleij
On Tue, Oct 20, 2015 at 3:10 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, Oct 19, 2015 at 9:21 PM, Rob Herring <robh@kernel.org> wrote: >> On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > >>> The MAINTAINERS entry for device tree bindings does not state a >>> git tree and I've never seen any of the maintainers send a pull request for >>> DT binding files. (Beat me up properly if you have, guys.) I've seen >>> Grant send some at times. >> >> Err, what? >> >> $ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline >> Documentation/devicetree/ > > OK nice, bad research from me. My sloppy statement was > based on this: > > OPEN FIRMWARE AND FLATTENED DEVICE TREE > M: Rob Herring <robh+dt@kernel.org> > M: Frank Rowand <frowand.list@gmail.com> > M: Grant Likely <grant.likely@linaro.org> > L: devicetree@vger.kernel.org > W: http://www.devicetree.org/ > T: git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git > S: Maintained > F: drivers/of/ > F: include/linux/of*.h > F: scripts/dtc/ > >> The DT core code and bindings (which don't go thru subsystem trees) go >> together. > > I guess I should just send a patch adding > > F: Documentation/devicetree/* I see you found it is already there... > > ...and hope things get better from that. > >>> I suggest sending U-Boot DT bindings to not only >>> devicetree@vger.kernel.org >>> but also, as indicated, to Jon Corbet and linux-doc. >> >> I'd suggest devicetree-spec@vger for common things. Perhaps we need a >> better name, but the whole point of this was to separate the common >> issues from the firehose and have multiple OS participation. > > Hm, wasn't devicetree@vger.kernel.org supposed to be for that? Yes, but BSD developers complained about all the Linux driver patches, so devicetree-spec was created as was devicetree-compiler to try to separate out the lower volume stuff. We need to do more with MAINTAINERS so that common bindings go to devicetree-spec. Rob
On Tue, Oct 20, 2015 at 3:15 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Tue, Oct 20, 2015 at 10:10 AM, Linus Walleij > <linus.walleij@linaro.org> wrote: >> On Mon, Oct 19, 2015 at 9:21 PM, Rob Herring <robh@kernel.org> wrote: >>> On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij <linus.walleij@linaro.org> wrote: >> >>> Err, what? >>> >>> $ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline >>> Documentation/devicetree/ >> >> OK nice, bad research from me. My sloppy statement was >> based on this: >> >> OPEN FIRMWARE AND FLATTENED DEVICE TREE >> M: Rob Herring <robh+dt@kernel.org> >> M: Frank Rowand <frowand.list@gmail.com> >> M: Grant Likely <grant.likely@linaro.org> >> L: devicetree@vger.kernel.org >> W: http://www.devicetree.org/ >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git >> S: Maintained >> F: drivers/of/ >> F: include/linux/of*.h >> F: scripts/dtc/ >> >>> The DT core code and bindings (which don't go thru subsystem trees) go >>> together. >> >> I guess I should just send a patch adding >> >> F: Documentation/devicetree/* >> >> ...and hope things get better from that. > > Ah yeah now I also woke up properly... so there is a special group of people > listed under another heading for this, and I should know that, mea culpa. > > OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS > M: Rob Herring <robh+dt@kernel.org> > M: Pawel Moll <pawel.moll@arm.com> > M: Mark Rutland <mark.rutland@arm.com> > M: Ian Campbell <ijc+devicetree@hellion.org.uk> > M: Kumar Gala <galak@codeaurora.org> > L: devicetree@vger.kernel.org > S: Maintained > F: Documentation/devicetree/ > F: arch/*/boot/dts/ > F: include/dt-bindings/ > > So can we add your git tree as T: here and replace Grant's tree in > the overall DT entry above it? I would hold off. We've not sorted out our workflow yet and may move to a shared repo. Rob
Hi, On 20 October 2015 at 07:05, Rob Herring <robh@kernel.org> wrote: > On Tue, Oct 20, 2015 at 3:15 AM, Linus Walleij <linus.walleij@linaro.org> wrote: >> On Tue, Oct 20, 2015 at 10:10 AM, Linus Walleij >> <linus.walleij@linaro.org> wrote: >>> On Mon, Oct 19, 2015 at 9:21 PM, Rob Herring <robh@kernel.org> wrote: >>>> On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij <linus.walleij@linaro.org> wrote: >>> >>>> Err, what? >>>> >>>> $ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline >>>> Documentation/devicetree/ >>> >>> OK nice, bad research from me. My sloppy statement was >>> based on this: >>> >>> OPEN FIRMWARE AND FLATTENED DEVICE TREE >>> M: Rob Herring <robh+dt@kernel.org> >>> M: Frank Rowand <frowand.list@gmail.com> >>> M: Grant Likely <grant.likely@linaro.org> >>> L: devicetree@vger.kernel.org >>> W: http://www.devicetree.org/ >>> T: git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git >>> S: Maintained >>> F: drivers/of/ >>> F: include/linux/of*.h >>> F: scripts/dtc/ >>> >>>> The DT core code and bindings (which don't go thru subsystem trees) go >>>> together. >>> >>> I guess I should just send a patch adding >>> >>> F: Documentation/devicetree/* >>> >>> ...and hope things get better from that. >> >> Ah yeah now I also woke up properly... so there is a special group of people >> listed under another heading for this, and I should know that, mea culpa. >> >> OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS >> M: Rob Herring <robh+dt@kernel.org> >> M: Pawel Moll <pawel.moll@arm.com> >> M: Mark Rutland <mark.rutland@arm.com> >> M: Ian Campbell <ijc+devicetree@hellion.org.uk> >> M: Kumar Gala <galak@codeaurora.org> >> L: devicetree@vger.kernel.org >> S: Maintained >> F: Documentation/devicetree/ >> F: arch/*/boot/dts/ >> F: include/dt-bindings/ >> >> So can we add your git tree as T: here and replace Grant's tree in >> the overall DT entry above it? > > I would hold off. We've not sorted out our workflow yet and may move > to a shared repo. With respect to this patch, I wonder if someone in the 'circle of trust' might draw up a patch to handle skipping init and specifying the input the clock speed? A little bit of progress might go a long way. Regards, Simon
On Wed, Oct 21, 2015 at 02:49:20PM -0600, Simon Glass wrote: > Hi, > > On 20 October 2015 at 07:05, Rob Herring <robh@kernel.org> wrote: > > On Tue, Oct 20, 2015 at 3:15 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > >> On Tue, Oct 20, 2015 at 10:10 AM, Linus Walleij > >> <linus.walleij@linaro.org> wrote: > >>> On Mon, Oct 19, 2015 at 9:21 PM, Rob Herring <robh@kernel.org> wrote: > >>>> On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > >>> > >>>> Err, what? > >>>> > >>>> $ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline > >>>> Documentation/devicetree/ > >>> > >>> OK nice, bad research from me. My sloppy statement was > >>> based on this: > >>> > >>> OPEN FIRMWARE AND FLATTENED DEVICE TREE > >>> M: Rob Herring <robh+dt@kernel.org> > >>> M: Frank Rowand <frowand.list@gmail.com> > >>> M: Grant Likely <grant.likely@linaro.org> > >>> L: devicetree@vger.kernel.org > >>> W: http://www.devicetree.org/ > >>> T: git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git > >>> S: Maintained > >>> F: drivers/of/ > >>> F: include/linux/of*.h > >>> F: scripts/dtc/ > >>> > >>>> The DT core code and bindings (which don't go thru subsystem trees) go > >>>> together. > >>> > >>> I guess I should just send a patch adding > >>> > >>> F: Documentation/devicetree/* > >>> > >>> ...and hope things get better from that. > >> > >> Ah yeah now I also woke up properly... so there is a special group of people > >> listed under another heading for this, and I should know that, mea culpa. > >> > >> OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS > >> M: Rob Herring <robh+dt@kernel.org> > >> M: Pawel Moll <pawel.moll@arm.com> > >> M: Mark Rutland <mark.rutland@arm.com> > >> M: Ian Campbell <ijc+devicetree@hellion.org.uk> > >> M: Kumar Gala <galak@codeaurora.org> > >> L: devicetree@vger.kernel.org > >> S: Maintained > >> F: Documentation/devicetree/ > >> F: arch/*/boot/dts/ > >> F: include/dt-bindings/ > >> > >> So can we add your git tree as T: here and replace Grant's tree in > >> the overall DT entry above it? > > > > I would hold off. We've not sorted out our workflow yet and may move > > to a shared repo. > > With respect to this patch, I wonder if someone in the 'circle of > trust' might draw up a patch to handle skipping init and specifying > the input the clock speed? A little bit of progress might go a long > way. Or at least "yes, if you do it $this way, we'll take it".. ?
On Mon, Oct 19, 2015 at 5:09 PM, Simon Glass <sjg@chromium.org> wrote: > Hi Rob, > > On 19 October 2015 at 14:14, Rob Herring <robherring2@gmail.com> wrote: >> On Wed, Oct 14, 2015 at 11:55 AM, Sergey Temerkhanov >> <s.temerkhanov@gmail.com> wrote: >>> On some systems, UART initialization is performed before running U-Boot. >>> This commit allows to skip UART re-initializaion on those systems >>> >>> Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> >>> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> >>> >>> Reviewed-by: Simon Glass <sjg@chromium.org> >> >> I'll comment on this now that I'm here, but as the rest of the thread >> said, please send to DT list. >> >>> diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt >>> index 61c27d1..0591497 100644 >>> --- a/doc/device-tree-bindings/serial/pl01x.txt >>> +++ b/doc/device-tree-bindings/serial/pl01x.txt >>> @@ -5,3 +5,6 @@ Required properties: >>> - reg: exactly one register range with length 0x1000 >>> - clock: input clock frequency for the UART (used to calculate the baud >>> rate divisor) >>> + >>> +Optional properties: >>> +- u-boot,skip-init: skip UART initialization at start. >> >> What are you trying to accomplish by skipping? >> >> stdout-path can take options now, so what about making it an option there: >> >> stdout-path = &serial0:no-init >> >> I have similar concerns with this as I did with the early init flag. >> This requires the dtb and u-boot to be in sync. For example, you have >> this option in the dtb, but then you add clock initialization to your >> platform which changes the default clock frequency of the UART. Now if >> you boot with an older dtb and new u-boot, then it will break because >> the UART is at the wrong baudrate. > > If you are saying what I think you are saying, U-Boot expects the > device tree that IT uses for configuration to come from the same > commit as the source code. It doesn't support anything else as the DTB > is bundled with (and replaced at the same time as) U-Boot.. You would > be on your own in that case. You can have that expectation, but that is generally not how DT works. Bindings are an ABI. You may not care for some usecases or boards, but we generally can't assume a DTB and its user whether u-boot, kernel, BSD, etc. are linked together. The rule is new s/w version should work with old DTB. How is it going to work when/if we put dts files in a standalone repository? What I want to see WRT u-boot and DTB handling is that they are independently updateable. That is already the case on some platforms such as highbank. The way it works is the management processor put both u-boot and the DTB into memory and then boots the cores. u-boot does minor tweaks and then passes the DTB on to the OS. I was working some to add u-boot DT config support for highbank before Calxeda's demise. IIRC, the main problems I hit were telling u-boot where the dtb is and then having it pass the same DTB on to the kernel. I doubt I'm the only one that would like things to work that way. Rob
On Mon, Oct 19, 2015 at 1:14 PM, Rob Herring <robherring2@gmail.com> wrote: > On Wed, Oct 14, 2015 at 11:55 AM, Sergey Temerkhanov > <s.temerkhanov@gmail.com> wrote: >> On some systems, UART initialization is performed before running U-Boot. >> This commit allows to skip UART re-initializaion on those systems >> >> Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> >> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> >> >> Reviewed-by: Simon Glass <sjg@chromium.org> > > I'll comment on this now that I'm here, but as the rest of the thread > said, please send to DT list. > >> diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt >> index 61c27d1..0591497 100644 >> --- a/doc/device-tree-bindings/serial/pl01x.txt >> +++ b/doc/device-tree-bindings/serial/pl01x.txt >> @@ -5,3 +5,6 @@ Required properties: >> - reg: exactly one register range with length 0x1000 >> - clock: input clock frequency for the UART (used to calculate the baud >> rate divisor) >> + >> +Optional properties: >> +- u-boot,skip-init: skip UART initialization at start. > > What are you trying to accomplish by skipping? > > stdout-path can take options now, so what about making it an option there: > > stdout-path = &serial0:no-init It's not about a single UART but all UARTs present in the platform. Some of them might have different reference clocks/PLL settings/whatever which can be tricky to support with FDT editing/rebuilding/etc. Especially if those reference clocks can be reprogrammed between runs. > > I have similar concerns with this as I did with the early init flag. > This requires the dtb and u-boot to be in sync. For example, you have > this option in the dtb, but then you add clock initialization to your > platform which changes the default clock frequency of the UART. Now if > you boot with an older dtb and new u-boot, then it will break because > the UART is at the wrong baudrate. It's not a problem at all since the U-Boot image with an attached DTB is being used. And that DTB comes from the U-Boot source tree. > > Rob
Hi Rob, On 23 October 2015 at 12:35, Rob Herring <robherring2@gmail.com> wrote: > On Mon, Oct 19, 2015 at 5:09 PM, Simon Glass <sjg@chromium.org> wrote: >> Hi Rob, >> >> On 19 October 2015 at 14:14, Rob Herring <robherring2@gmail.com> wrote: >>> On Wed, Oct 14, 2015 at 11:55 AM, Sergey Temerkhanov >>> <s.temerkhanov@gmail.com> wrote: >>>> On some systems, UART initialization is performed before running U-Boot. >>>> This commit allows to skip UART re-initializaion on those systems >>>> >>>> Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> >>>> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> >>>> >>>> Reviewed-by: Simon Glass <sjg@chromium.org> >>> >>> I'll comment on this now that I'm here, but as the rest of the thread >>> said, please send to DT list. >>> >>>> diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt >>>> index 61c27d1..0591497 100644 >>>> --- a/doc/device-tree-bindings/serial/pl01x.txt >>>> +++ b/doc/device-tree-bindings/serial/pl01x.txt >>>> @@ -5,3 +5,6 @@ Required properties: >>>> - reg: exactly one register range with length 0x1000 >>>> - clock: input clock frequency for the UART (used to calculate the baud >>>> rate divisor) >>>> + >>>> +Optional properties: >>>> +- u-boot,skip-init: skip UART initialization at start. >>> >>> What are you trying to accomplish by skipping? >>> >>> stdout-path can take options now, so what about making it an option there: >>> >>> stdout-path = &serial0:no-init >>> >>> I have similar concerns with this as I did with the early init flag. >>> This requires the dtb and u-boot to be in sync. For example, you have >>> this option in the dtb, but then you add clock initialization to your >>> platform which changes the default clock frequency of the UART. Now if >>> you boot with an older dtb and new u-boot, then it will break because >>> the UART is at the wrong baudrate. >> >> If you are saying what I think you are saying, U-Boot expects the >> device tree that IT uses for configuration to come from the same >> commit as the source code. It doesn't support anything else as the DTB >> is bundled with (and replaced at the same time as) U-Boot.. You would >> be on your own in that case. > > You can have that expectation, but that is generally not how DT works. > Bindings are an ABI. You may not care for some usecases or boards, but > we generally can't assume a DTB and its user whether u-boot, kernel, > BSD, etc. are linked together. The rule is new s/w version should work > with old DTB. > > How is it going to work when/if we put dts files in a standalone repository? > > What I want to see WRT u-boot and DTB handling is that they are > independently updateable. That is already the case on some platforms > such as highbank. The way it works is the management processor put > both u-boot and the DTB into memory and then boots the cores. u-boot > does minor tweaks and then passes the DTB on to the OS. I was working > some to add u-boot DT config support for highbank before Calxeda's > demise. IIRC, the main problems I hit were telling u-boot where the > dtb is and then having it pass the same DTB on to the kernel. I doubt > I'm the only one that would like things to work that way. I don't see that this is a requirement. Also I don't think it makes sense. U-Boot and Linux have quite different field-upgrade cycles. It is quite common to update the kernel without updating U-Boot, and vice versa. Some platforms will never update U-Boot. Some platforms have U-Boot in one medium (sometimes even read-only) and Linux in another. When updating the kernel I would expect the kernel device tree to be updated also - e.g. a new FIT image containing the kernel and device tree files. This is because we may have new drivers or enhanced features there were not defined in the earlier device tre. When updating U-Boot I would expect U-Boot's device tree to update also, without affecting the one passed to the kernel. Similar to the above there may be new features or enhancements that require this. If there is ever a stand-alone repository then we can revisit this discussion, but I doubt it makes much different for U-Boot at least, which requires the device tree to complete its build. Maybe something has changed recently to suggest things will go that way, but as far as I recall it has been talked about for 4 years. It should be possible for the U-Boot project to decide how it uses device tree. Regards, Simon
On Wed, Oct 14, 2015 at 09:55:48AM -0700, Sergey Temerkhanov wrote: > On some systems, UART initialization is performed before running U-Boot. > This commit allows to skip UART re-initializaion on those systems > > Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> > Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> > Reviewed-by: Simon Glass <sjg@chromium.org> In the end, this appears to have become mired in a lack of getting a device tree binding for this functionality in particular to be accepted upstream from us. I'm deferring on this particular version until someone with the time and desire to resolve the binding does so.
diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt index 61c27d1..0591497 100644 --- a/doc/device-tree-bindings/serial/pl01x.txt +++ b/doc/device-tree-bindings/serial/pl01x.txt @@ -5,3 +5,6 @@ Required properties: - reg: exactly one register range with length 0x1000 - clock: input clock frequency for the UART (used to calculate the baud rate divisor) + +Optional properties: +- u-boot,skip-init: skip UART initialization at start. diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c index 18c02ab..ebfa4fb 100644 --- a/drivers/serial/serial_pl01x.c +++ b/drivers/serial/serial_pl01x.c @@ -103,7 +103,7 @@ static int pl011_set_line_control(struct pl01x_regs *regs) } static int pl01x_generic_setbrg(struct pl01x_regs *regs, enum pl01x_type type, - int clock, int baudrate) + int clock, int baudrate) { switch (type) { case TYPE_PL010: { @@ -273,7 +273,6 @@ __weak struct serial_device *default_serial_console(void) #endif /* nCONFIG_DM_SERIAL */ #ifdef CONFIG_DM_SERIAL - struct pl01x_priv { struct pl01x_regs *regs; enum pl01x_type type; @@ -284,9 +283,9 @@ static int pl01x_serial_setbrg(struct udevice *dev, int baudrate) struct pl01x_serial_platdata *plat = dev_get_platdata(dev); struct pl01x_priv *priv = dev_get_priv(dev); - pl01x_generic_setbrg(priv->regs, priv->type, plat->clock, baudrate); - - return 0; + return plat->skip_init ? 0 : + pl01x_generic_setbrg(priv->regs, priv->type, + plat->clock, baudrate); } static int pl01x_serial_probe(struct udevice *dev) @@ -296,7 +295,8 @@ static int pl01x_serial_probe(struct udevice *dev) priv->regs = (struct pl01x_regs *)plat->base; priv->type = plat->type; - return pl01x_generic_serial_init(priv->regs, priv->type); + return plat->skip_init ? 0 : + pl01x_generic_serial_init(priv->regs, priv->type); } static int pl01x_serial_getc(struct udevice *dev) @@ -350,6 +350,8 @@ static int pl01x_serial_ofdata_to_platdata(struct udevice *dev) plat->base = addr; plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset, "clock", 1); plat->type = dev_get_driver_data(dev); + plat->skip_init = fdtdec_get_bool(gd->fdt_blob, dev->of_offset, + "uboot,skip-init"); return 0; } #endif diff --git a/include/dm/platform_data/serial_pl01x.h b/include/dm/platform_data/serial_pl01x.h index 5e068f3..10e9572 100644 --- a/include/dm/platform_data/serial_pl01x.h +++ b/include/dm/platform_data/serial_pl01x.h @@ -17,11 +17,13 @@ enum pl01x_type { * @base: Register base address * @type: Port type * @clock: Input clock rate, used for calculating the baud rate divisor + * @flags: Port flags */ struct pl01x_serial_platdata { unsigned long base; enum pl01x_type type; unsigned int clock; + bool skip_init; }; #endif