[U-Boot] dm-spi: spi_chip_select value

[Simon Glass]

Hi Jagan,

On 30 June 2015 at 11:48, Jagan Teki <jteki at openedev.com> wrote:
> Hi Simon,
>
> On 27 June 2015 at 04:32, Simon Glass <sjg at chromium.org> wrote:
>> Hi Jagan,
>>
>> On 26 June 2015 at 13:07, Jagan Teki <jteki at openedev.com> wrote:
>>> Hi Simon,
>>>
>>> On 26 June 2015 at 21:23, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi Jagan,
>>>>
>>>> On 23 June 2015 at 15:03, Jagan Teki <jteki at openedev.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> I'm calling spi_chip_select(bus) from set_speed or claim_bus
>>>>> to get the cs value from sf probe.
>>>>>
>>>>> Seems like it returns the maximum number as 254, when I debug
>>>>> further seems like slave_platdata returns NULL
>>>>>
>>>>> int spi_chip_select(struct udevice *dev)
>>>>> {
>>>>>         struct dm_spi_slave_platdata *plat = dev_get_parent_platdata(dev);
>>>>>         / * this plat data returns NULL */
>>>>>
>>>>>         return plat ? plat->cs : -ENOENT;
>>>>> }
>>>>>
>>>>
>>>> /**
>>>>  * spi_chip_select() - Get the chip select for a slave
>>>>  *
>>>>  * @return the chip select this slave is attached to
>>>>  */
>>>> int spi_chip_select(struct udevice *slave);
>>>>
>>>> This function takes a slave device as a parameter, not a bus. Are you
>>>> passing it a bus?
>>>
>>> So as it's a struct udevice - I have passed it from probe and store my cs.
>>> Seems like if you get the cs only if we call it from spi_xfer as it's slave
>>> is it right?
>>
>> Both the bus and the slave device are devices, and thus use struct udevice.
>>
>> I really don't understand what you are asking/saying. Please can you
>> try to be more descriptive?
>
> To finding out the cs number in spi driver, I'm trying to use spi_chip_select
> from probe, but I couldn't find the valid cs number .
>
> I got the valid cs number only when I call spi_chip_select from xfer(), is that
> something like binding is properly done only when xfer() reaches?

To get the chip select, you can use:

struct dm_spi_slave_platdata *plat = dev_get_parent_platdata(dev);

plat->cs

See the README also:

20. A little note about SPI uclass features:

The SPI uclass keeps some information about each device 'dev' on the bus:

   struct dm_spi_slave_platdata - this is device_get_parent_platdata(dev)
This is where the chip select number is stored, along with
the default bus speed and mode. It is automatically read
from the device tree in spi_child_post_bind(). It must not
be changed at run-time after being set up because platform
data is supposed to be immutable at run-time.
   struct spi_slave - this is device_get_parentdata(dev)
Already mentioned above. It holds run-time information about
the device.

There are also some SPI uclass methods that get called behind the scenes:

   spi_post_bind() - called when a new bus is bound
This scans the device tree for devices on the bus, and binds
each one. This in turn causes spi_child_post_bind() to be
called for each, which reads the device tree information
into the parent (per-child) platform data.
   spi_child_post_bind() - called when a new child is bound
As mentioned above this reads the device tree information
into the per-child platform data
   spi_child_pre_probe() - called before a new child is probed
This sets up the mode and speed in struct spi_slave by
copying it from the parent's platform data for this child.
It also sets the 'dev' pointer, needed to permit passing
'struct spi_slave' around the place without needing a
separate 'struct udevice' pointer.

The above housekeeping makes it easier to write your SPI driver.



>
>>>>> log:
>>>>> zynq-uboot> sf probe 1:0
>>>>> zynq_spi_ofdata_to_platdata: regs=e0007000 max-frequency=166666700
>>>>> zynq_spi_set_speed: cs 254
>>>>> zynq_spi_set_speed: regs=e0007000, mode=1000000
>>>>> zynq_spi_set_mode: regs=e0007000, mode=3
>>>>> zynq_spi_claim_bus: cs 254
>>>>> spi_xfer: bus:1 cs:254 bitlen:8 len:1 flags:1
>>>>> spi_xfer: Timeout! TX FIFO not full
>>>>> SF: Failed to get idcodes
>>>>> Failed to initialize SPI flash at 1:0 (error -1)
>
> thanks!
> --
> Jagan | openedev.

Regards,
Simon