Re: [PATCH/RFC] simple SPI controller on PXA2xx SSP port, refresh

[Stephen Street <stephen@streetfiresound.com>]

On Fri, 2005-11-04 at 12:16 -0800, David Brownell wrote:
> I'd be confused.  They're both slave-specific ... and owned by
> the master/controller driver.

I'm using the spi_board_info.platform_data to pass configuration
information to the spi_device (slave) driver and
spi_board_info.controller_data to pass SPI bus configuration for the
specific slave device.  This allows different bus configurations for
each attached SPI device.  The following is a concrete example: 

/* CS8415A configuration information and board interface setup */
static struct cs8415a_platform_data cs8415a_platform_info = {
	.enabled = 0,
	.muted = 1,
	.channel = 0,
	.pll_lock_delay = 100, 
	.irq_flags = SA_SHIRQ,
	.mask_interrupt = cs8415a_mask_interrupt,
	.unmask_interrupt = cs8415a_unmask_interrupt,
	.service_requested = cs8415a_service_requested,
};

/* PXA2XX SPI bus setup for CS8415A */
static struct pxa2xx_spi_chip cs8415a_chip_info = {
	.tx_threshold = 12,
	.rx_threshold = 4,
	.dma_burst_size = 8,
	.timeout_microsecs = 64,
	.cs_control = cs8415a_cs_control,
};

static struct spi_board_info streetracer_spi_board_info[] __initdata = {
	{
		.modalias = "cs8415a",
		.max_speed_hz = 3686400,
		.bus_num = 2,
		.chip_select = 0,
		.platform_data = &cs8415a_platform_info,
		.controller_data = &cs8415a_chip_info,
		.irq = STREETRACER_APCI_IRQ,
	},
};

IMHO the confusion is coming from the fact that struct spi_board_info is
being used to pass related, but implementation dependent, configuration
information to both the master and the slave simultaneously.  Maybe we
are asking spi_board_info to carry to much information?

> Instead, how about "controller_data" changing to match its role
> in board_info (static info, not dynamic), and "platform_data"
> becoming something like "controller_state"?  

If you mean spi_device.controller_data becomes
spi_device.controller_state, yes!

-Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/