[U-Boot] [PATCH 12/25] dm: spi: Add documentation on how to convert over SPI drivers

[Simon Glass]

Hi Jagan,


On 31 August 2014 23:45, Jagan Teki <jagannadh.teki at gmail.com> wrote:
> Hi Simon,
>
> On 1 September 2014 10:36, Simon Glass <sjg at chromium.org> wrote:
>> Hi Jagan,
>>
>> On 28 August 2014 04:32, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>> On 15 July 2014 06:26, Simon Glass <sjg at chromium.org> wrote:
>>>> This README is intended to help maintainers move their SPI drivers over to
>>>> driver model. It works through the required steps with an example.
>>>>
>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>> ---
>>>>
>>>>  doc/driver-model/spi-howto.txt | 570 +++++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 570 insertions(+)
>>>>  create mode 100644 doc/driver-model/spi-howto.txt
>>>>
>>>> diff --git a/doc/driver-model/spi-howto.txt b/doc/driver-model/spi-howto.txt
>>>> new file mode 100644
>>>> index 0000000..bb64735
>>>> --- /dev/null
>>>> +++ b/doc/driver-model/spi-howto.txt
>>>> @@ -0,0 +1,570 @@
>>>> +How to port a SPI driver to driver model
>>>> +========================================
>>>> +
>>>> +Here is a rough step-by-step guide. It is based around converting the
>>>> +exynos SPI driver to driver model (DM) and the example code is based
>>>> +around U-Boot v2014.04 (commit dda0dbf).
>>>> +
>>>> +It is quite long since it includes actual code examples.
>>>> +
>>>> +Before driver model, SPI drivers have their own private structure which
>>>> +contains 'struct spi_slave'. With driver model, 'struct spi_slave' still
>>>> +exists, but now it is 'per-child data' for the SPI bus. Each child of the
>>>> +SPI bus is a SPI slave. The information that was stored in the
>>>> +driver-specific slave structure can now be put in private data for the
>>>> +SPI bus.
>>>
>>> Do you think spi_slave still require, I guess It's needed as some slave members
>>> to cs, bus are used to control the driver.
>>
>> The CS and bus are purely command-line conveniences with DM. When it
>> gets down to the driver the bus is determined by the SPI peripheral it
>> is connected to, and the CS is the control that it adjusts to enable
>> the chip select. The numbering of buses and chip selects is not
>> relevant down at the driver level anymore.
>
> Yes - I understand but let me explain my comments.
>
> u-boot> sf probe bus:cs speed mode
>
> Unlike other buses/controllers on u-boot we're dynamically probing the
> slave on bus
> using bus and cs for example, we have a zynq_spi handling spi0, spi1
> (bus's) and each
> one has 3 chip-selects. So
>
> u-boot> sf probe 1:1
> for probing bus1 (spi1) and cs 1
>
> u-boot> sf probe 0:1
> for probing bus0 (spi0) and cs 1
>
> The respective reg base (based on bus) and register chip-select (based
> on cs) zynq_spi.c
> will handle these in driver it self.
>
> speed and mode settings, I'm fine with dm, where it will configure using
>
> int spi_get_bus_and_cs(int busnum, int cs, int speed, int mode,
>                        const char *drv_name, const char *dev_name,
>                        struct udevice **devp, struct spi_slave **slavep)
> {
> .....
> ret = spi_set_speed_mode(bus, speed, mode);
> ......
> }
>
> But how can spi-uclass.c will identifies how many bus's along with cs lines does
> specified controller driver support.

This is done with platform data or device tree. In other words we
explicitly list a driver for each chip select.

However I did anticipate problems with this approach, particularly
while so few drivers are converted. Also we need to support things
like the 'sspi' command and 'sf probe'. So I added spi_bind_device()
which is automatically called if no SPI device is found for a bus/chip
select.

>
> This what usually we're doing in driver as
> int spi_cs_is_valid(unsigned int bus, unsigned int cs)
> {
>         /* 2 bus with 3 chipselect */
>         return bus < 2 && cs < 3;
> }
>
> Please let me know if you have any questions, this is what usually
> doing most of drivers.

Yes, I don't really like that - it is a fine way of doing things
before driver model, but now it is not that useful. We are trying to
bind drivers to chip selects, not just figure out which ones are
valid.

One thing I have not figured out yet (mostly since I have no driver
that needs it) is how to activate multiple SPI chip selects using
GPIOs. It shouldn't be too hard, just need a board that supports it.

[snip]

Regards,
Simon