Hi Simon!
On 14.10.2014 07:41, Simon Glass wrote:
Add a uclass which provides access to SPI buses and includes operations required by SPI.
For a time driver model will need to co-exist with the legacy SPI interface so some parts of the header file are changed depending on which is in use. The exports are adjusted also since some functions are not available with driver model.
Boards must define CONFIG_DM_SPI to use driver model for SPI.
I'm starting to use DM now. Finally! ;)
In my case I'm implementing the Designware master SPI driver for the SoCFPGA. And since its a new driver it really makes sense to use DM directly. I'm starting to get an overview now. One thing though that I noticed is, that the SPI DM implementation seems to be a bit FDT centric. Please see below.
<snip>
diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
<snip>
+int spi_post_bind(struct udevice *dev) +{
- /* Scan the bus for devices */
- return dm_scan_fdt_node(dev, gd->fdt_blob, dev->of_offset, false);
+}
SoCFPGA currently does not support CONFIG_OF_CONTROL (no dtb supplied). So I'm planning to use platform_data to instantiate the device. Something like this in the board file:
static const struct dw_spi_platdata spi_platdata = { .base = SOCFPGA_SPIM0_ADDRESS, };
U_BOOT_DEVICE(dw_spi) = { .name = "dw_spi", .platdata = &spi_platdata, };
What would the non-fdt method have to be to bind the device in spi_post_bind() above?
Thanks, Stefan