From: David Brownell <david-b@pacbell.net>
To: eemike@gmail.com
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH/RFC] simple SPI controller on PXA2xx SSP port, refresh
Date: Thu, 3 Nov 2005 16:15:22 -0800 [thread overview]
Message-ID: <200511031615.22630.david-b@pacbell.net> (raw)
> 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?
Normally you'd just use platform_data ... which might hold things like
resistance and capacitance settings for that particular board; or details
about which SPI chip variant was present. It gets stored in the struct
device (spi_device->dev) as "platform_data".
Stephen persuaded me to add controller_data too, which is stored in
"struct spi_device". His PXA SPI controller driver uses that for a
structure holding what I'd call DMA tuning information, plus a function
that tweaks the GPIO used for a chipselect. Treat it as readonly.
Controller drivers can have two different kinds of state in each
spi_device: static, and dynamic/runtime. The names used for them
are IMO very confusing (platform_data and controller_data) since
they don't mean the same as those names do in board_info. I'd take
a patch to provide better names for those two. :)
> 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?
Combine that lack of probe with the fact that SPI isn't hotpluggable,
and that's pretty much why. You need a table of SPI devices present
on a given board; that boardinfo should be defined just once, in the
relevant arch/arm/mach-imx/board-*.c file. The table never changes,
so there'd be no point in code to change it after board init is done.
(Other than wasting some memory!)
You could also use spi_new_device()/spi_unregister_device() if for some
reason you want to define new boardinfo in a module. You'd need some
out-of-band data to determine what devices are present.
- Dave
p.s. There's a minor refresh to the SPI code coming up soonish; just
fine tuning, and catching up to 2.6.14-git which has removed a
pointless parameter from device_driver.{suspend,resume}() calls.
next reply other threads:[~2005-11-04 0:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-04 0:15 David Brownell [this message]
2005-11-04 18:52 ` [PATCH/RFC] simple SPI controller on PXA2xx SSP port, refresh 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
-- strict thread matches above, loose matches on Subject: below --
2005-10-25 23:48 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
2005-11-04 20:36 ` Mark Underwood
2005-11-07 20:43 ` Mark Underwood
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=200511031615.22630.david-b@pacbell.net \
--to=david-b@pacbell.net \
--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