From: "Grant Likely" <grant.likely@secretlab.ca>
To: avorontsov@ru.mvista.com
Cc: linuxppc-dev@ozlabs.org, Gary Jennejohn <garyj@denx.de>,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Subject: Re: [PATCH 1/4] [SPI] spi_mpc83xx: convert to the OF platform driver
Date: Wed, 21 May 2008 11:17:49 -0600 [thread overview]
Message-ID: <fa686aa40805211017x493e69ecqbcf823333979a6e1@mail.gmail.com> (raw)
In-Reply-To: <20080521170506.GA22021@polina.dev.rtsoft.ru>
On Wed, May 21, 2008 at 11:05 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> On Wed, May 21, 2008 at 10:50:02AM -0600, Grant Likely wrote:
> [..]
>> > +
>> > + master->num_chipselect = of_num_children(np);
>>
>> This assumes that there are no gaps in the assigned CS numbers of
>> child nodes, or that the child nodes are an exhaustive list of
>> attached devices, neither of which may be true. num_chipselect should
>> be calculated from the number of GPIOs specified instead.
>
> [I'm not arguing just a thought.]
:-)
Here's some quick feedback off the top of my head...
> - every SPI device must have its own chip-select, otherwise SPI device
> node should not be a part of a SPI controller node;
How about this example: Board has SPI controller with 4 CS lines and
4 devices. Board vendor has 3 versions of board with different
devices populated (Ver1 has all 4; Ver2 has 1 and 3; Ver3 has 1, 3 and
4). Board firmware drops nodes from tree for non-present devices
before booting kernel (not arguing if this is the best way for
firmware to behave; but it is valid and legal). Therefore there may
be gaps in the CS assignments.
Or how about this one: the SPI devices are off board and are plugged
in after boot. They aren't available to be described in the device
tree, but are added at a later time in response to some hot plug
event. The SPI bus needs to be already set up with the correct number
of CS lines.
I don't think you can assume that the device tree data will be exhaustive.
> - or there is just once device on the SPI bus with chip-select always
> asserted, no gpios = <> is specified (this case is implemented);
> - or the SPI is bridged, gpios = <> should list behind-the-bridge devices'
> chip-selects, and driver should understand that there is a "special"
> (bridge) device somewhere on the bus (not implemented).
In this case, I think the gpios would be a property of the spi-bridge,
not the spi-master. The gpios of the spi-master would have to specify
how to address the bridge; not the downstream devices. The bridge;
when addressed correctly; would then proceed with addressing the
downstream. In other words; the 'reg' of spi-devices attached to a
bridge would be an address that the bridge understands, not an address
that the master understands.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next prev parent reply other threads:[~2008-05-21 17:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-21 15:41 [RFC/DRAFT] SPI OF bindings, MMC-over-SPI, chip-selects and so on Anton Vorontsov
2008-05-21 15:41 ` [PATCH 1/4] [SPI] spi_mpc83xx: convert to the OF platform driver Anton Vorontsov
2008-05-21 16:50 ` Grant Likely
2008-05-21 17:05 ` Anton Vorontsov
2008-05-21 17:17 ` Grant Likely [this message]
2008-05-21 15:41 ` [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors Anton Vorontsov
2008-05-21 15:56 ` Guennadi Liakhovetski
2008-05-21 16:10 ` Anton Vorontsov
2008-05-21 16:24 ` Guennadi Liakhovetski
2008-05-21 16:48 ` Anton Vorontsov
2008-05-21 17:05 ` Grant Likely
2008-05-21 17:51 ` Guennadi Liakhovetski
2008-05-21 19:06 ` Grant Likely
2008-05-21 19:20 ` Guennadi Liakhovetski
2008-05-21 19:53 ` Grant Likely
2008-05-21 20:00 ` Guennadi Liakhovetski
2008-05-21 20:07 ` Grant Likely
2008-05-21 17:30 ` Grant Likely
2008-05-21 15:41 ` [PATCH 3/4] [OF] MMC-over-SPI OF constructor Anton Vorontsov
2008-05-21 15:41 ` [PATCH 4/4] [POWERPC] 86xx: mpc8610_hpcd: support for MMC-over-SPI and PIXIS' GPIOs Anton Vorontsov
2008-05-21 15:54 ` [RFC/DRAFT] SPI OF bindings, MMC-over-SPI, chip-selects and so on Guennadi Liakhovetski
2008-05-21 16:01 ` Anton Vorontsov
2008-05-21 16:51 ` Grant Likely
2008-05-21 17:32 ` Grant Likely
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=fa686aa40805211017x493e69ecqbcf823333979a6e1@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=avorontsov@ru.mvista.com \
--cc=g.liakhovetski@gmx.de \
--cc=garyj@denx.de \
--cc=linuxppc-dev@ozlabs.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;
as well as URLs for NNTP newsgroup(s).