[U-Boot] WIP for SPI

Simon Glass sjg at chromium.org
Sat Jul 19 06:34:49 CEST 2014


Hi Jon,

On 11 June 2014 08:33, Jon Loeliger <loeliger at gmail.com> wrote:
> On Tue, Jun 10, 2014 at 10:54 PM, Simon Glass <sjg at 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


More information about the U-Boot mailing list