public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Street <stephen@streetfiresound.com>
To: Mike Lee <eemike@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] simple SPI controller on PXA2xx SSP port, refresh
Date: Fri, 04 Nov 2005 10:11:38 -0800	[thread overview]
Message-ID: <1131127898.426.8.camel@localhost.localdomain> (raw)
In-Reply-To: <1ffb4b070511030137o345049d2o5ed5e020c96e022d@mail.gmail.com>

On Thu, 2005-11-03 at 17:37 +0800, Mike Lee wrote: 
> Actually, i am now available to use your loopback driver on my SPI
> controller driver. But only limited to PIO mode, and i get stuck on
> DMA mode because of trigger problem of SPI module, I am now trying
> very hard to solve that.

I had problems get the DMA buffers aligned correctly.

> 
> In my driver, there is a little bug that i could not rmmod the driver.
> it will stop at unregistering device. Below is a debug msg dump. it
> seem to stop at down_write(&device_subsys.rwsem) in device_del
> ------------------------------------------------------------
> /mnt/tmpfs/tmp # insmod imx_spi.ko
> bus platform: add driver imx-spi
> CLASS: registering class device: ID = 'spi1'
> imx-spi imx-spi.0: registered master spi1
>  spi1.1-loopback: setup finish
> DEV: registering device: ID = 'spi1.1-loopback'
> bus spi: add device spi1.1-loopback
> imx-spi imx-spi.0: registered child spi1.1-loopback
> bound device 'imx-spi.0' to driver 'imx-spi'
> CLASS: registering class device: ID = 'spi2'
> imx-spi imx-spi.1: registered master spi2
> bound device 'imx-spi.1' to driver 'imx-spi'
> /mnt/tmpfs/tmp # rmmod imx_spi.ko
> bus platform: remove driver imx-spi
> DEV: Unregistering device. ID = 'spi1.1-loopback'
> 
> ------------------------------------------------------------
> 
I'm not sure what the problem is.  What kernel version are you using?
Changes are continuing in the driver model which can affect module
unloading.

> 
> Some question on SPI subsystem:
> I really get confused on the structure on the whole system. e.g. the
> platform_data and controller_data in board_info.  What are thier
> purposes?

A little confusing I agree.  Keep in mind that in a typical SPI setup
there is one SPI master (i.MX) connected to one or more SPI slaves
(external chips).  You will have a device_driver for the master and a
device_driver for each SPI slave. So...

The platform_data contains configuration information for the SPI slave
device_driver and the controller data contain configuration information
for the SPI master device_driver which is specific to an individual SPI
Slave.  This allows the SPI master to configure itself differently on
the fly, for each chip connected to it.

Here is code snippet from my board init

static struct resource pxa_spi_resources[] = {
	[0] = {
		.start	= __PREG(SSCR0_P(2)),
		.end	= __PREG(SSCR0_P(2)) + 0x2c,
		.flags	= IORESOURCE_MEM,
	},
	[1] = {
		.start	= IRQ_NSSP,
		.end	= IRQ_NSSP,
		.flags	= IORESOURCE_IRQ,
	},
};

static struct pxa2xx_spi_master pxa_nssp_master_info = {
	.ssp_type = PXA25x_NSSP,
	.clock_enable = CKEN9_NSSP,
	.num_chipselect = 4,
	.enable_dma = 1,
};

static struct platform_device pxa_spi_ssp = {
	.name = "pxa2xx-spi-ssp",
	.id = 2,
	.resource = pxa_spi_resources,
	.num_resources = ARRAY_SIZE(pxa_spi_resources),
	.dev = {
		.platform_data = &pxa_nssp_master_info,
	},
};

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,
};

static struct pxa2xx_spi_chip cs8415a_chip_info = {
	.tx_threshold = 8,
	.rx_threshold = 8,
	.dma_burst_size = 8,
	.timeout_microsecs = 64,
	.cs_control = cs8415a_cs_control,
};

static struct pxa2xx_spi_chip cs8405a_chip_info = {
	.tx_threshold = 12,
	.rx_threshold = 4,
	.dma_burst_size = 8,
	.timeout_microsecs = 64,
};

static struct pxa2xx_spi_chip cs4341_chip_info = {
	.tx_threshold = 12,
	.rx_threshold = 4,
	.timeout_microsecs = 128,
};

static struct pxa2xx_spi_chip loopback_chip_info = {
	.tx_threshold = 12,
	.rx_threshold = 4,
	.dma_burst_size = 8,
	.timeout_microsecs = 64,
	.enable_loopback = 1,
};

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,
	},
	{
		.modalias = "cs8405a",
		.max_speed_hz = 3686400,
		.bus_num = 2,
		.chip_select = 1,
		.controller_data = &cs8405a_chip_info,
		.irq = STREETRACER_APCI_IRQ,
	},
	{
		.modalias = "cs4341",
		.max_speed_hz = 3686400,
		.bus_num = 2,
		.chip_select = 2,
		.controller_data = &cs4341_chip_info,
	},
	{
		.modalias = "loopback",
		.max_speed_hz = 3686400,
		.bus_num = 2,
		.chip_select = 3,
		.controller_data = &loopback_chip_info,
	},
};

> Also i found that spi_register_board_info is declared as __init, that
> mean i can not register board info as a module, is it because there is
> no 'real' probe on SPI bus? (this comsume me time to reflash my board
> to debug)

Correct no real probe, but.... see 

extern struct spi_device *spi_new_device(struct spi_master *, struct spi_board_info *);

in spi.h for creating new spi_device on the fly or in a module.


> I know that SDIO could have a SPI mode. Could SPI subsystem be used to
> control SDIO device?

No clue, sorry.

> Sorry for my annoying questions.

No problem! Happy to help out.  What external chip are you talking to?

-Stephen



  reply	other threads:[~2005-11-04 18:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-25 23:48 [PATCH/RFC] simple SPI controller on PXA2xx SSP port, refresh stephen
2005-10-27 11:33 ` Mike Lee
2005-10-27 16:41   ` Stephen Street
2005-10-29 18:25     ` Mike Lee
2005-11-01 18:35       ` Stephen Street
2005-11-03  9:37         ` Mike Lee
2005-11-04 18:11           ` Stephen Street [this message]
2005-11-04 20:36             ` Mark Underwood
2005-11-07 20:43               ` Mark Underwood
  -- strict thread matches above, loose matches on Subject: below --
2005-11-04  0:15 David Brownell
2005-11-04 18:52 ` Stephen Street
2005-11-04 20:16   ` David Brownell
2005-11-04 23:38     ` Stephen Street
2005-11-05  0:54       ` David Brownell
2005-11-05  2:28         ` Stephen Street
2005-11-05 20:58           ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1131127898.426.8.camel@localhost.localdomain \
    --to=stephen@streetfiresound.com \
    --cc=eemike@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox