Re: [U-Boot] WIP for SPI
Hi Jon, On 21 July 2014 07:11, Jon Loeliger loeli...@gmail.com wrote: And I think I am saying that we already *have* it generalized for the GPIOs but only if we remove that renumbering function! Consider again that the U_CLASS lookup of a GPIO simply matches versus the range in each uclass data (gpio base and count). That search doesn't care about their order within the UCLASS_GPIO list. (Never mind that the renumbering breaks the association of the device base register and pin ranges as set up by the bind/probe code!) I wonder if we could do something similar then, where there is a default numbering if none is provided, but the GPIO devices are able to 'request' particular number ranges? I think we are talking past each other now. Isn't that already in place? One can already register a device with a range in the UCLASS so that the lookup happens and matches to a particular device instance. (But only assuming they are NOT renumbered.) What am I missing here? For GPIOs at present, we don't use the sequence numbering side - the GPIO uclass numbers everything itself and does not permit boards to specify numbering (other than by ordering in the device tree / platform data). For sequences we support specifying number by alias as well. I'm just saying that for GPIOs we could (in future) enhance it to make the numbering more flexible. If we can do this in a way that is general to all devices (e.g. using sequenced) then that might be nice. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WIP for SPI
And I think I am saying that we already *have* it generalized for the GPIOs but only if we remove that renumbering function! Consider again that the U_CLASS lookup of a GPIO simply matches versus the range in each uclass data (gpio base and count). That search doesn't care about their order within the UCLASS_GPIO list. (Never mind that the renumbering breaks the association of the device base register and pin ranges as set up by the bind/probe code!) I wonder if we could do something similar then, where there is a default numbering if none is provided, but the GPIO devices are able to 'request' particular number ranges? I think we are talking past each other now. Isn't that already in place? One can already register a device with a range in the UCLASS so that the lookup happens and matches to a particular device instance. (But only assuming they are NOT renumbered.) What am I missing here? Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WIP for SPI
Hi Jon, On 11 June 2014 08:33, Jon Loeliger loeli...@gmail.com wrote: On Tue, Jun 10, 2014 at 10:54 PM, Simon Glass s...@chromium.org wrote: Hi Jon, I thought I should mention that I spent time on a flight to look at SPI with driver model. I have put the WIP code in branch 'working' in u-boot-dm.git. Note it doesn't work, and is very early. Also note that many of the patches have not been posted - I just want to make it clear what I am up to. Awesome! In doing this I had to sort out the numbering of devices. U-Boot has the concept of SPI bus 2 on its command line, and for now at lest we need to keep that working. So I have added sequence numbers to devices - so a device can be considered 'child number 3' of its parent, for example. The numbers don't need to be sequential. I suppose we could generalise this to GPIOs if it works out. And I think I am saying that we already *have* it generalized for the GPIOs but only if we remove that renumbering function! Consider again that the U_CLASS lookup of a GPIO simply matches versus the range in each uclass data (gpio base and count). That search doesn't care about their order within the UCLASS_GPIO list. (Never mind that the renumbering breaks the association of the device base register and pin ranges as set up by the bind/probe code!) I wonder if we could do something similar then, where there is a default numbering if none is provided, but the GPIO devices are able to 'request' particular number ranges? My approach for scanning the SPI bus in the device tree is similar to what I suggested a week or so ago - I took the code from dm_scan_fdt() and put it in a function with a udevice parent and node parameters. It seems to work OK for this simple case. Nice! Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WIP for SPI
On Tue, Jun 10, 2014 at 10:54 PM, Simon Glass s...@chromium.org wrote: Hi Jon, I thought I should mention that I spent time on a flight to look at SPI with driver model. I have put the WIP code in branch 'working' in u-boot-dm.git. Note it doesn't work, and is very early. Also note that many of the patches have not been posted - I just want to make it clear what I am up to. Awesome! In doing this I had to sort out the numbering of devices. U-Boot has the concept of SPI bus 2 on its command line, and for now at lest we need to keep that working. So I have added sequence numbers to devices - so a device can be considered 'child number 3' of its parent, for example. The numbers don't need to be sequential. I suppose we could generalise this to GPIOs if it works out. And I think I am saying that we already *have* it generalized for the GPIOs but only if we remove that renumbering function! Consider again that the U_CLASS lookup of a GPIO simply matches versus the range in each uclass data (gpio base and count). That search doesn't care about their order within the UCLASS_GPIO list. (Never mind that the renumbering breaks the association of the device base register and pin ranges as set up by the bind/probe code!) My approach for scanning the SPI bus in the device tree is similar to what I suggested a week or so ago - I took the code from dm_scan_fdt() and put it in a function with a udevice parent and node parameters. It seems to work OK for this simple case. Nice! Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] WIP for SPI
Hi Jon, I thought I should mention that I spent time on a flight to look at SPI with driver model. I have put the WIP code in branch 'working' in u-boot-dm.git. Note it doesn't work, and is very early. Also note that many of the patches have not been posted - I just want to make it clear what I am up to. In doing this I had to sort out the numbering of devices. U-Boot has the concept of SPI bus 2 on its command line, and for now at lest we need to keep that working. So I have added sequence numbers to devices - so a device can be considered 'child number 3' of its parent, for example. The numbers don't need to be sequential. I suppose we could generalise this to GPIOs if it works out. My approach for scanning the SPI bus in the device tree is similar to what I suggested a week or so ago - I took the code from dm_scan_fdt() and put it in a function with a udevice parent and node parameters. It seems to work OK for this simple case. I'll continue to update 'working' as I get closer to making this run. So far you can do this: ./b/sandbox/u-boot -d b/sandbox/u-boot.dtb -c sspi 0:0 48 9f00 U-Boot 2014.07-rc3-00064-ga8af843-dirty (Jun 10 2014 - 21:43:51) DRAM: 128 MiB No match for node 'host@0' No match for node 'lcd' No match for node 'cros-ec-keyb' Using default environment In:cros-ec-keyb Out: lcd Err: lcd sandbox_sf: state:0(CMD) bytes:6 sandbox_sf: CS activated; state is fresh! cmd: transition to ID state id: off:0 tx:0 20 id: off:1 tx:1 20 id: off:2 tx:2 15 id: off:3 tx:3 00 id: off:4 tx:4 00 sandbox_sf: CS deactivated; cmd done processing! FF202015 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
