Hi Ian,
On Aug 13, 2015, at 22:04 , Ian Lepore ian@freebsd.org wrote:
On Thu, 2015-08-13 at 14:13 -0400, Tom Rini wrote:
On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote:
On 08/13/2015 09:59 AM, Simon Glass wrote:
Hi Linus,
On 11 August 2015 at 07:00, Linus Walleij linus.walleij@linaro.org wrote:
On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass sjg@chromium.org wrote:
This binding differs from that of Linux. Update it and change existing users.
Signed-off-by: Simon Glass sjg@chromium.org
(...)
doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---
So why does U-Boot have its own copy of any bindings at all?
This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)
Can't we just have the bindings in the Linux kernel tree please?
Is there any plan to move them out of Linux and put them in a separate place?
We should make an effort to sync the device tree files with Linux periodically.
I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.
However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?
DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)
This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.
As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.
The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.
As one that had to suffer under an alternative OS’s definition of what DT is, and how bindings work (VxWorks) I would like to have some concrete example about any cases like that.
In my experience the mismatch may come from exactly two things:
1) From the lack of involvement in the DT process that’s going on devicetree. True, there’s a very big Linux bias but the maintainers are reasonable and they are open on any kind of collaboration in that area.
2) From the completely half-assed way that internally DT has been implemented in other OSes besides Linux. I am still scared by the VxWorks stuff, but things are not much better in u-boot either. You just can’t slap in libfdt in there and expect all the modern bindings to work (like clock tree, pinmuxing, etc.) I would hope we’ll get things better in u-boot and I would certainly like to coordinate with FreeBSD or whoever to get something done with a reasonable API (and license) that anyone can use.
Due to this, DT bindings end up OS specific which is rather insane if you think about it.
A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.
So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.
I would like to point out that picking i2c eeproms as an example is rather disingenuous. i2c eeproms until recently were in the land of drivers/misc where all the oddballs are located.
I’m very happy to point out that Linux does now have (in -next) an EEPROM (nvmem) framework that _is_ sane.
http://www.gossamer-threads.com/lists/linux/kernel/2224053?page=last
I even have ported the ubiquitous at24 driver to it and I’m happy to report that it is painless port.
https://github.com/pantoniou/linux-beagle-track-mainline/commit/e02880fb6829...
All in all, it's not impossible for another OS to work with the DT information that begins its life in Linux, but it's not really easy.
Why not make it easier then?
-- Ian
Regards
— Pantelis