lkml.org 
[lkml]   [2008]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/4] spi: Add OF binding support for SPI busses
On Mon, 19 May 2008, Grant Likely wrote:

> On Mon, May 19, 2008 at 7:17 AM, Guennadi Liakhovetski
> <g.liakhovetski@gmx.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.

Right, sorry, your SPI bus driver scans the bus device bindings and
registers devices on it using spi_of_register_devices().

> 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.

Yes, I understand, that physically there can be many ways SPI chipselects
can be controlled. But I thought there could be a generic way to cover
them all by defining a separate entry on your SPI bus. Like

+ SPI example for an MPC5200 SPI bus:
+ spi@f00 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
+ reg = <0xf00 0x20>;
+ interrupts = <2 13 0 2 14 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ eth-switch-cs@0 {
+ compatible = "oem,cs-type";
+ };
+
+ ethernet-switch@0 {
+ compatible = "micrel,ks8995m";
+ linux,modalias = "ks8995";
+ max-speed = <1000000>;
+ reg = <0>;
+ cs-parent = <&/.../spi@f00/eth-switch-cs@0>;
+ };
...
+ };

Then whatever method is used to actually switch the CS, a driver should be
registered to handle eth-switch-cs@0, providing the required calls.
Without such a driver ethernet-switch@0 will not probe successfully.
Wouldn't this cover all possible cases? One could even consider actually
putting SPI devices on SPI chipselect busses, but that won't look very
elegant:-)

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer


\
 
 \ /
  Last update: 2008-05-19 18:33    [W:0.129 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site