[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa686aa40805190857u317d3304ie75d11870e109fc5@mail.gmail.com>
Date: Mon, 19 May 2008 09:57:21 -0600
From: "Grant Likely" <grant.likely@...retlab.ca>
To: "Guennadi Liakhovetski" <g.liakhovetski@....de>
Cc: linuxppc-dev@...abs.org, spi-devel-general@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, dbrownell@...rs.sourceforge.net,
fabrizio.garetto@...il.com, jonsmirl@...il.com
Subject: Re: [PATCH 3/4] spi: Add OF binding support for SPI busses
On Mon, May 19, 2008 at 7:17 AM, Guennadi Liakhovetski
<g.liakhovetski@....de> wrote:
> On Fri, 16 May 2008, Grant Likely wrote:
>
>> + However, the binding does not attempt to define the specific method for
>> + assigning chip select numbers. Since SPI chip select configuration is
>> + flexible and non-standardized, it is left out of this binding with the
>> + assumption that board specific platform code will be used to manage
>> + chip selects. Individual drivers can define additional properties to
>> + support describing the chip select layout.
>
> Yes, this looks like a problem to me. This means, SPI devices will need
> two bindings - OF and platform?... Maybe define an spi_chipselect
> OF-binding?
Actually, spi devices have *neither*. :-) They bind to the SPI bus.
Not the platform bus or of_platform bus. But that is Linux internal
details; this discussion is about device tree bindings.
Note that I did say that drivers can define additional properties for
supporting chip select changes as needed. I'm just not attempting to
encode them into the formal binding. There is simply just too many
different ways to manipulate chip select signals and so I don't feel
confident trying to define a *common* binding at this moment in time.
At some point in the future when we have a number of examples to
choose from then we can extend this binding with chip select related
properties.
As for the Linux internals, the 5200 SPI bus driver that I posted
exports a function that allows another driver to call in and
manipulated the CS lines before the transfer. It isn't the prettiest
solution, but I'm not locked into the approach and that gives some
time to consider cleaner interfaces.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists