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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
