From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefan Roese <sr@denx.de>
Date: Wed, 29 Oct 2014 14:02:43 +0100
Subject: [U-Boot] [PATCH v4 05/29] dm: spi: Add a uclass for SPI
In-Reply-To: <1413265336-9571-6-git-send-email-sjg@chromium.org>
References: <1413265336-9571-1-git-send-email-sjg@chromium.org>
	<1413265336-9571-6-git-send-email-sjg@chromium.org>
Message-ID: <5450E573.50705@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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