Hi Jon,
On 9 July 2014 07:53, Jon Loeliger loeliger@gmail.com wrote:
HI Simon,
On Tue, Jul 8, 2014 at 10:38 PM, Simon Glass sjg@chromium.org wrote:
In U-Boot it is pretty common to number devices from 0 and access them on the command line using this numbering. While it may come to pass that we will move away from this numbering, the possibility seems remote at present.
Given that devices within a uclass will have an implied numbering, it makes sense to build this into driver model as a core feature. The cost is fairly small in terms of code and data space.
Hmmm. I'm not entirely in agreement here. I think this is the wrong long-term approach, and this just reinforces the status quo rather than allowing a migration to a better approach.
If we don't add numbering to driver model, then it will be done badly (and ad-hoc) in support code. I can't even quite imagine how we might do it. Also while U-Boot's numbering may not be the right long-term approach, that would involve a large discussion and long change-over to an as-yet unknown method. So I think we need to have realistic expectations of driver mode's place in the world. It can enable new methods, but not mandate them.
With each uclass having numbered devices we can ask for SPI port 0 or serial port 1 and receive a single device.
That's nice, but we should allow them to be named by their actual names as found in the device tree too.
There's nothing in this patch that precludes that. It would require changes to U-Boot's command processing, probably best done as a separate series sometime in the future.
Devices typically request a sequence number using aliases in the device tree. These are resolved when the device is probed, to deal with conflicts. Sequence numbers need not be sequential and holes are permitted.
So they are unreliably unpredictable, unless you also happen to have the DTS decoder ring in hand too?
If you compare with how things are now, we only support a single driver for each class. For example, if you are using SPI, you can only have one SPI driver - perhaps with multiple ports. If you are not using DT, then the U_BOOT_DEVICE() macros will all appear in that driver or the board file (TBD at this stage), and will be parsed in order. I believe we can honour the numbering in that case, albeit I don't want to implement something before it is needed.
+This indicates that in the uclass called "serial", the named node +("/serial@22230000") will be given sequence number 2. Any command or driver +which requests serial device 2 will obtain this device.
+Some devices represent buses where the devices on the bus are numbered or +addressed. For example, SPI typically numbers its slaves from 0, and I2C +uses a 7-bit address. In these cases the 'reg' property of the subnode is +used, for example:
+{
aliases {spi2 = "/spi@22300000";};spi@22300000 {#address-cells = <1>;#size-cells = <1>;spi-flash@0 {reg = <0>;...}eeprom@1 {reg = <1>;};};And not everyone agrees that this is the best approach, even in Linux land. Specifically, we should be in agreement with Linux, and we should not have our DTS stray from the definitions that Linux will accept for the same devices. And this approach won't be bought by the Linux crowd. (Yes, there are some that use a "reg = <0>;" approach here, but there are many that do not too. It's not a universally accepted approach.)
This concept is crucial.
I've said it before, and I will say it again if needed.
So: Sure, put this approach in, but make it be the backward compatible approach. Also please put in a correct naming approach so that we can move forward with a better longer term solution too.
I think you are saying that something like:
sf probe spi1:flash
should be possible instead of
sf probe 1:0
It feels right to me too, but it doesn't belong in this patch, needs further discussion and the command parsing aspect needs more general thought. It would be great to figure this out and get it agreed, and driver model can certainly support it.
Regards, Simon