[PATCH 1/4] [SPI] spi_mpc83xx: convert to the OF platform driver
Grant Likely
grant.likely at secretlab.ca
Thu May 22 03:17:49 EST 2008
On Wed, May 21, 2008 at 11:05 AM, Anton Vorontsov
<avorontsov at 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.
More information about the Linuxppc-dev
mailing list