Hi Jagan,
On 30 June 2015 at 11:48, Jagan Teki jteki@openedev.com wrote:
Hi Simon,
On 27 June 2015 at 04:32, Simon Glass sjg@chromium.org wrote:
Hi Jagan,
On 26 June 2015 at 13:07, Jagan Teki jteki@openedev.com wrote:
Hi Simon,
On 26 June 2015 at 21:23, Simon Glass sjg@chromium.org wrote:
Hi Jagan,
On 23 June 2015 at 15:03, Jagan Teki jteki@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