fpga driver on custom PPC target platform (P4080) ...

fpga driver on custom PPC target platform (P4080) ...

[Robert Sciuk]

Dear Tree lovers,

I'm in the process of designing and implementing a Linux device driver
for a Xilinx V6 FPGA which can be loaded from  the CPU (P4080) on our
target board (and optionally 2 additional FPGA's on a riser card).  The
programming pins of the FPGAs are tied to a MUX (PCA9539) on an i2c bus,
and the port is located on the localbus (simplebus).  I'm thinking that
a uio type driver could in theory set the programming bits using the i2c
mux upon open(), and that an mmap() in userspace would perform the .bits
load, and the programming done bit would be returned in the close() of
the device from userland.

I would like to use the device tree to map both the i2c access and the
localbus mappings, and I've yet to start coding, though this may start
RSN.  My questions to the list, are:

	- am I barking up the wrong tree here?
	- is there anyone who has done something similar before which
can be shared?
	- Is there an impedance problem having the device accessed on
both I2c and localbus?
	- Is there a problem combining device tree and uio drivers?
	- How does one specify in the device tree an FPGA which uses
both I2c bus and localbus for programming?

This is kind of an interesting project, as I've never written a
device-tree driver before, and I've yet to use uio type drivers, but it
does seem a good match for the problem.  Any comments or pointers would
be well received.

Thanks in advance, and sorry for cross-posting, I'm sure that some of
you may well see this message twice, and for that I'm sorry.

Robert Sciuk
Senior Designer, R&D.
905.738.3741 xt 22621

Re: fpga driver on custom PPC target platform (P4080) ...

[Segher Boessenkool]

> 	- How does one specify in the device tree an FPGA which uses
> both I2c bus and localbus for programming?

You have two device nodes, one on the localbus and one on the IIC bus.
One of the nodes points to the other, or both do; you point to another
node by having a property containing the phandle of that other node.

It's probably easiest to make the IIC node point to the localbus node,
because you will most likely always have exactly one of those, and you
could have multiple IIC nodes on your FPGA, or none at all.  But this
is something you'll have to put in the device binding for your device,
and it doesn't really matter what you choose -- it will work either way,
some choices are more convenient than others though.


Segher

RE: fpga driver on custom PPC target platform (P4080) ...

[Robert Sciuk]

> -----Original Message-----
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]
> Sent: Thursday, November 03, 2011 5:22 PM
> To: Robert Sciuk
> Cc: devicetree-discuss@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: fpga driver on custom PPC target platform (P4080) ...
>=20
> > 	- How does one specify in the device tree an FPGA which uses
> > both I2c bus and localbus for programming?
>=20
> You have two device nodes, one on the localbus and one on the IIC bus.
> One of the nodes points to the other, or both do; you point to another
> node by having a property containing the phandle of that other node.
>=20
> It's probably easiest to make the IIC node point to the localbus node,
> because you will most likely always have exactly one of those, and you
> could have multiple IIC nodes on your FPGA, or none at all.  But this
> is something you'll have to put in the device binding for your device,
> and it doesn't really matter what you choose -- it will work either
> way,
> some choices are more convenient than others though.
>=20
>=20
> Segher

Segher,

Actually, I'm just now re-configuring my device-tree i2c nodes to =
accurately reflect reality.  As the open() will be doing the i2c bit =
banging, I agree completely with your assessment, and I will access the =
FPGA's via the I2c bus, and locate the localbus port via the phandle =
8-).

dmesg | grep pca

[    2.699342] pca953x 2-00e8: failed reading register
[    2.708444] pca953x: probe of 2-00e8 failed with error -5
[    2.719097] pca953x 2-00e9: failed reading register
[    2.728192] pca953x: probe of 2-00e9 failed with error -5	=09

	i2c@119000 {
			#address-cells =3D <1>;
			#size-cells =3D <0>;
			cell-index =3D <2>;
			compatible =3D "fsl-i2c";
			reg =3D <0x119000 0x100>;
			interrupts =3D <39 2 0 0>;
			interrupt-parent =3D <&mpic>;
			dfsrr;

                        lim_r: gpio@e8 {
                                compatible =3D "nxp,pca9539";
                                reg =3D <0xe8>;
                                #gpio-cells =3D <2>;
                                gpio-controller;
                                polarity =3D <0x00>;
                        };

                        lim_w: gpio@e9 {
                                compatible =3D "nxp,pca9539";
                                reg =3D <0xe9>;
                                #gpio-cells =3D <2>;
                                gpio-controller;
                                polarity =3D <0x00>;
                        };

		};

It appears that I'm not correctly creating the pca9539 nodes as of yet =
(I'll be adding the phandles shortly).  Any pointers for pca9539 driver =
nodes would be appreciated, as I took these from a similar tree, but not =
the 95xx driver.  I'll match them up with the code in the morning ...


Thanks for your feedback, it was as timely as it was welcomed!

Cheers,
Rob

Re: fpga driver on custom PPC target platform (P4080) ...

[Tabi Timur-B04825]

On Thu, Nov 3, 2011 at 5:12 PM, Robert Sciuk <robert.sciuk@exfo.com> wrote:

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0lim_r: gpio@e8 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible=
 =3D "nxp,pca9539";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0=
xe8>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#gpio-cell=
s =3D <2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gpio-contr=
oller;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0polarity =
=3D <0x00>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0lim_w: gpio@e9 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible=
 =3D "nxp,pca9539";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0=
xe9>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#gpio-cell=
s =3D <2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gpio-contr=
oller;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0polarity =
=3D <0x00>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
> It appears that I'm not correctly creating the pca9539 nodes as of yet (I=
'll be adding the phandles shortly). =A0Any pointers for pca9539 driver nod=
es would be appreciated, as I took these from a similar tree, but not the 9=
5xx driver. =A0I'll match them up with the code in the morning ...

I *believe* you are not supposed to create separate nodes for reading
and writing.  I know that's how I2C works, but I think the I2C layer
takes care of that for you.

If you look at other device trees, you'll see they only have one node
for any particular I2C device.

--=20
Timur Tabi
Linux kernel developer at Freescale=

RE: fpga driver on custom PPC target platform (P4080) ...

[Robert Sciuk]

> > It appears that I'm not correctly creating the pca9539 nodes as of
> yet (I'll be adding the phandles shortly). =A0Any pointers for pca9539
> driver nodes would be appreciated, as I took these from a similar =
tree,
> but not the 95xx driver. =A0I'll match them up with the code in the
> morning ...
>=20
> I *believe* you are not supposed to create separate nodes for reading
> and writing.  I know that's how I2C works, but I think the I2C layer
> takes care of that for you.
>=20
> If you look at other device trees, you'll see they only have one node
> for any particular I2C device.
>=20
> --
> Timur Tabi
> Linux kernel developer at Freescale


Thanks, Timur ... I've fixed the tree, and I'm tracking down the =
problems with addressing the nodes ...

RE: fpga driver on custom PPC target platform (P4080) ...

[Robert Sciuk]

> >
> > I *believe* you are not supposed to create separate nodes for =
reading
> > and writing.  I know that's how I2C works, but I think the I2C layer
> > takes care of that for you.
> >
> > If you look at other device trees, you'll see they only have one =
node
> > for any particular I2C device.
> >
> > --
> > Timur Tabi
> > Linux kernel developer at Freescale
>=20
>=20
> Thanks, Timur ... I've fixed the tree, and I'm tracking down the
> problems with addressing the nodes ...

Ah,  my compatible attribute was wrong:

	Compatible =3D "nxp,pca9539";

	Should have been:

	Compatible =3D "nxp,pca953x";

The tree now seems to bind the i2c gpio drivers properly ... on to the =
localbus mappings!

Rob.

Re: fpga driver on custom PPC target platform (P4080) ...

[David Gibson]

On Fri, Nov 04, 2011 at 02:19:36PM -0400, Robert Sciuk wrote:
> > >
> > > I *believe* you are not supposed to create separate nodes for reading
> > > and writing.  I know that's how I2C works, but I think the I2C layer
> > > takes care of that for you.
> > >
> > > If you look at other device trees, you'll see they only have one node
> > > for any particular I2C device.
> > >
> > 
> > 
> > Thanks, Timur ... I've fixed the tree, and I'm tracking down the
> > problems with addressing the nodes ...
> 
> Ah,  my compatible attribute was wrong:
> 
> 	Compatible = "nxp,pca9539";
> 
> 	Should have been:
> 
> 	Compatible = "nxp,pca953x";
> 
> The tree now seems to bind the i2c gpio drivers properly ... on to
> the localbus mappings!

Ah.  In that case the drivers should probably be extended to recognize
the first compatible.  "wildcard" compatible strings are a bad idea,
unfortunately there are some already in the wild, as you've seen.  We
should try to phase them out though.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

RE: fpga driver on custom PPC target platform (P4080) ...

[Robert Sciuk]

> > Ah,  my compatible attribute was wrong:
> >
> > 	Compatible =3D "nxp,pca9539";
> >
> > 	Should have been:
> >
> > 	Compatible =3D "nxp,pca953x";
> >
> > The tree now seems to bind the i2c gpio drivers properly ... on to
> > the localbus mappings!
>=20
> Ah.  In that case the drivers should probably be extended to recognize
> the first compatible.  "wildcard" compatible strings are a bad idea,
> unfortunately there are some already in the wild, as you've seen.  We
> should try to phase them out though.
>=20
> --
> David Gibson			| I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_
> _other_
> 				| _way_ _around_!
> http://www.ozlabs.org/~dgibson

Thanks, David

It did occur that a specific binding should be preferred over a generic =
one=20

Rob.

RE: fpga driver on custom PPC target platform (P4080) ...

[Robert Sciuk]

In my continuing saga of dev/tree driver development, I have a problem =
which might be obvious to those who have more experience in such =
matters.

I'm a bit perplexed on the tree nodes for the localbus/simplebus nodes =
for my FPGA.  CS0 is reserved for booting (from NOR flash as required by =
our design), CS1 is tied to an FPGA which will always be present.  CS2 =
actually is tied to both of two (optional) fpga's, which have been =
previously mapped by U-Boot (BRn/ORn configuration).  Should I specify a =
ranges command as follows?  This seems somehow wrong, to me, and I'm =
wondering if there is an alternative representation which would work =
better in this case.  If you recall, the programming control lines are =
handled on the I2C bus, via a gpio controller.  In an ideal world, the =
optional FPE1 and FPE2 fpgas will have the identical .bts stream, and =
should support the option to program both simultaneously, or each =
individually, but I'm at a loss as how to best represent this in the =
tree.

	        localbus@ffe124000 {
                compatible =3D "fsl,p4080-elbc", "fsl,elbc", =
"simple-bus";
                reg =3D <0xf 0xfe124000 0 0x1000>;
                interrupts =3D <25 2 0 0>;
                interrupt-parent =3D <&mpic>;
                #address-cells =3D <2>;
                #size-cells =3D <1>;

                /* Local bus region mappings */
                ranges =3D <0 0 0xf 0xe8000000 0x08000000         /* =
CS0: Boot flash */
                          1 0 0xf 0xd0000000 0x7fff             /* CS1: =
FPGA0 -  LIM */
                          2 0 0xf 0xd1000000 0x7fff             /* CS2: =
FPGA1 -  FPE1 */
                          2 0 0xf 0xd2000000 0x7fff >;          /* CS2: =
FPGA2 -  FPE2 */

                flash@0,0 {
                        compatible =3D "cfi-flash";
                        reg =3D <0 0 0x08000000>;
                        bank-width =3D <2>;
                        device-width =3D <2>;
                        #size-cells =3D <1>;
                        #address-cells =3D <1>;

                        partition@0 {
                                label =3D "rcw";
                                reg =3D <0x0 0x20000>;
                                read-only;
                        };
                        partition@40000 {
                                label =3D "saveenv";
                                reg =3D <0x40000 0x20000>;
                        };
                        partition@7000000 {
                                label =3D "fman-firmware";
                                reg =3D <0x7000000 0x20000>;
                                read-only;
                        };
                        partition@7f80000 {
                                label =3D "u-boot";
                                reg =3D <0x7f80000 0x80000>;
                                read-only;
                        };
                };

                lim: fpga@1, {
                }

                fpe1: fpga@2, {
                }

                fpe2: fpga@2, {
	}

Again, any pointers here would be greatly appreciated ...

Cheers,
Rob Sciuk

Re: fpga driver on custom PPC target platform (P4080) ...

[Mitch Bradley]

On 11/7/2011 10:09 AM, Robert Sciuk wrote:
> In my continuing saga of dev/tree driver development, I have a problem which might be obvious to those who have more experience in such matters.
>
> I'm a bit perplexed on the tree nodes for the localbus/simplebus nodes for my FPGA.  CS0 is reserved for booting (from NOR flash as required by our design), CS1 is tied to an FPGA which will always be present.  CS2 actually is tied to both of two (optional) fpga's, which have been previously mapped by U-Boot (BRn/ORn configuration).  Should I specify a ranges command as follows?  This seems somehow wrong, to me, and I'm wondering if there is an alternative representation which would work better in this case.  If you recall, the programming control lines are handled on the I2C bus, via a gpio controller.  In an ideal world, the optional FPE1 and FPE2 fpgas will have the identical .bts stream, and should support the option to program both simultaneously, or each individually, but I'm at a loss as how to best represent this in the tree.

I would be tempted to add another level of hierarchy as a container for 
the two FPEs on CS2.

>
> 	        localbus@ffe124000 {
>                  compatible = "fsl,p4080-elbc", "fsl,elbc", "simple-bus";
>                  reg =<0xf 0xfe124000 0 0x1000>;
>                  interrupts =<25 2 0 0>;
>                  interrupt-parent =<&mpic>;
>                  #address-cells =<2>;
>                  #size-cells =<1>;
>
>                  /* Local bus region mappings */
>                  ranges =<0 0 0xf 0xe8000000 0x08000000         /* CS0: Boot flash */
>                            1 0 0xf 0xd0000000 0x7fff             /* CS1: FPGA0 -  LIM */
>                            2 0 0xf 0xd1000000 0x7fff             /* CS2: FPGA1 -  FPE1 */
>                            2 0 0xf 0xd2000000 0x7fff>;          /* CS2: FPGA2 -  FPE2 */
>
>                  flash@0,0 {
>                          compatible = "cfi-flash";
>                          reg =<0 0 0x08000000>;
>                          bank-width =<2>;
>                          device-width =<2>;
>                          #size-cells =<1>;
>                          #address-cells =<1>;
>
>                          partition@0 {
>                                  label = "rcw";
>                                  reg =<0x0 0x20000>;
>                                  read-only;
>                          };
>                          partition@40000 {
>                                  label = "saveenv";
>                                  reg =<0x40000 0x20000>;
>                          };
>                          partition@7000000 {
>                                  label = "fman-firmware";
>                                  reg =<0x7000000 0x20000>;
>                                  read-only;
>                          };
>                          partition@7f80000 {
>                                  label = "u-boot";
>                                  reg =<0x7f80000 0x80000>;
>                                  read-only;
>                          };
>                  };
>
>                  lim: fpga@1, {
>                  }
>
>                  fpe1: fpga@2, {
>                  }
>
>                  fpe2: fpga@2, {
> 	}
>
> Again, any pointers here would be greatly appreciated ...
>
> Cheers,
> Rob Sciuk
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>

RE: fpga driver on custom PPC target platform (P4080) ...

[Robert Sciuk]

> -----Original Message-----
> From: Mitch Bradley [mailto:wmb@firmworks.com]
>=20
> I would be tempted to add another level of hierarchy as a container =
for
> the two FPEs on CS2.
>=20

Hi, Mitch.

As a long time Forth(er), I'm somewhat honoured to have this exchange =
with you 8-)


Do you mean something like this????

        localbus@ffe124000 {
                compatible =3D "fsl,p4080-elbc", "fsl,elbc", =
"simple-bus";
                reg =3D <0xf 0xfe124000 0 0x1000>;
                interrupts =3D <25 2 0 0>;
                interrupt-parent =3D <&mpic>;
                #address-cells =3D <2>;
                #size-cells =3D <1>;

                /* Local bus region mappings */
                ranges =3D <0 0 0xf 0xe8000000 0x08000000         /* =
CS0: Boot flash */
                          1 0 0xf 0xd0000000 0x7fff             /* CS1: =
FPGA0 -  LIM */
                          2 0 0xf 0xd1000000 0x7fff             /* CS2: =
FPGA1 -  FPE1 */
                          2 1 0xf 0xd2000000 0x7fff >;          /* CS2: =
FPGA2 -  FPE2 */

                flash@0,0 {
                        compatible =3D "cfi-flash";
                        reg =3D <0 0 0x08000000>;
                        bank-width =3D <2>;
                        device-width =3D <2>;
                        #size-cells =3D <1>;
                        #address-cells =3D <1>;

                        partition@0 {
                                label =3D "rcw";
                                reg =3D <0x0 0x20000>;
                                read-only;
                        };
                        partition@40000 {
                                label =3D "saveenv";
                                reg =3D <0x40000 0x20000>;
                        };
                        partition@7000000 {
                                label =3D "fman-firmware";
                                reg =3D <0x7000000 0x20000>;
                                read-only;
                        };
                        partition@7f80000 {
                                label =3D "u-boot";
                                reg =3D <0x7f80000 0x80000>;
                                read-only;
                        };
                };

                lim: fpga@1, {
                }

			nitro: daughtercard@2 {
                	fpe1: fpga@2,0 {
                	}

                	fpe2: fpga@2,1 {
				}
			}
	}

Re: fpga driver on custom PPC target platform (P4080) ...

[Scott Wood]

On 11/07/2011 02:09 PM, Robert Sciuk wrote:
> In my continuing saga of dev/tree driver development, I have a problem which might be obvious to those who have more experience in such matters.
> 
> I'm a bit perplexed on the tree nodes for the localbus/simplebus
> nodes for my FPGA.  CS0 is reserved for booting (from NOR flash as
> required by our design), CS1 is tied to an FPGA which will always be
> present.  CS2 actually is tied to both of two (optional) fpga's,
> which have been previously mapped by U-Boot (BRn/ORn configuration).
> Should I specify a ranges command as follows?  This seems somehow
> wrong, to me, and I'm wondering if there is an alternative
> representation which would work better in this case.  If you recall,
> the programming control lines are handled on the I2C bus, via a gpio
> controller.  In an ideal world, the optional FPE1 and FPE2 fpgas will
> have the identical .bts stream, and should support the option to
> program both simultaneously, or each individually, but I'm at a loss
> as how to best represent this in the tree.

If you need to poke an i2c bus to switch access between certain localbus
children, you should remove "simple-bus" from the compatible -- or
perhaps do something like:

localbus@ffe124000 {
	compatible = "fsl,p4080-elbc", "fsl,elbc", "simple-bus";
	...

	flash@0,0 {
		...
	};

	switched-bank@2,0 {
		// no simple-bus here
		compatible = "something specific to your board's setup";
		ranges = <0 0 2 0 0x8000>;

		// reg is here just to make the unit-addres valid
		reg = <2 0 0>;

		#address-cells = <2>;
		#size-cells = <1>;

		// specify a phandle to the i2c device and any other
		// relevant details for identifying which knob of the
		// switch needs to be turned...

		// replace x/y with appropriate switch ID, and 0 0x8000
		// with appropriate portion of the window being used by
		// each device
		fpga@x,0 {
			compatible = ...
			reg = <x 0 0x8000>;			
			...
		};

		fpga@y,0 {
			compatible = ...
			reg = <y 0 0x8000>;
			...
		};
	};
};

> 
> 	        localbus@ffe124000 {
>                 compatible = "fsl,p4080-elbc", "fsl,elbc", "simple-bus";
>                 reg = <0xf 0xfe124000 0 0x1000>;
>                 interrupts = <25 2 0 0>;
>                 interrupt-parent = <&mpic>;
>                 #address-cells = <2>;
>                 #size-cells = <1>;
> 
>                 /* Local bus region mappings */
>                 ranges = <0 0 0xf 0xe8000000 0x08000000         /* CS0: Boot flash */
>                           1 0 0xf 0xd0000000 0x7fff             /* CS1: FPGA0 -  LIM */
>                           2 0 0xf 0xd1000000 0x7fff             /* CS2: FPGA1 -  FPE1 */
>                           2 0 0xf 0xd2000000 0x7fff >;          /* CS2: FPGA2 -  FPE2 */

The binding for FSL localbus nodes
(Documentation/devicetree/bindings/powerpc/fsl/lbc.txt) says that there
is a one-to-one correspondence between "ranges" entries and chipselects,
based on how the eLBC is actually programmed.  The details of what is
attached come in the subnodes.

I don't see how the above mapping is possible with eLBC -- you're
splitting CS2 among 0xd1000000..0xd1007fff and 0xd2000000..0xd2007fff.
Since you have CS1 at 0xd0000000, alignment restrictions prevent CS2
from covering both of those regions -- unless you've got overlapping
mappings, with CS2 being at least 0xd0000000..0xd3ffffff, and are
relying on CS1 taking priority due to being lower-numbered.

I hope you're not doing that, and that these aren't the real addresses
(or they can be changed) -- but if you must do this, that breaks the
one-to-one model, so you'd need both ranges entries.

Also note that the final cell in each ranges entry should be the size,
not the size minus one.

>                 fpe1: fpga@2, {
>                 }
> 
>                 fpe2: fpga@2, {

This would be fine for a case where the devices are not switched, but
rather decode different addresses within the chipselect.

E.g. CS3 of arch/powerpc/boot/dts/socrates.dts

-Scott

RE: fpga driver on custom PPC target platform (P4080) ...

[Robert Sciuk]

...
>=20
> 	switched-bank@2,0 {
> 		// no simple-bus here
> 		compatible =3D "something specific to your board's setup";
> 		ranges =3D <0 0 2 0 0x8000>;
>=20
> 		// reg is here just to make the unit-addres valid
> 		reg =3D <2 0 0>;
>=20
> 		#address-cells =3D <2>;
> 		#size-cells =3D <1>;
>=20
> 		// specify a phandle to the i2c device and any other
> 		// relevant details for identifying which knob of the
> 		// switch needs to be turned...
>=20
> 		// replace x/y with appropriate switch ID, and 0 0x8000
> 		// with appropriate portion of the window being used by
> 		// each device
> 		fpga@x,0 {
> 			compatible =3D ...
> 			reg =3D <x 0 0x8000>;
> 			...
> 		};
>=20
> 		fpga@y,0 {
> 			compatible =3D ...
> 			reg =3D <y 0 0x8000>;
> 			...
> 		};
> 	};
> };
>=20
> >
> > 	        localbus@ffe124000 {
> >                 compatible =3D "fsl,p4080-elbc", "fsl,elbc", =
"simple-
> bus";
> >                 reg =3D <0xf 0xfe124000 0 0x1000>;
> >                 interrupts =3D <25 2 0 0>;
> >                 interrupt-parent =3D <&mpic>;
> >                 #address-cells =3D <2>;
> >                 #size-cells =3D <1>;
> >
> >                 /* Local bus region mappings */
> >                 ranges =3D <0 0 0xf 0xe8000000 0x08000000         /*
> CS0: Boot flash */
> >                           1 0 0xf 0xd0000000 0x7fff             /*
> CS1: FPGA0 -  LIM */
> >                           2 0 0xf 0xd1000000 0x7fff             /*
> CS2: FPGA1 -  FPE1 */
> >                           2 0 0xf 0xd2000000 0x7fff >;          /*
> CS2: FPGA2 -  FPE2 */
>=20
> The binding for FSL localbus nodes
> (Documentation/devicetree/bindings/powerpc/fsl/lbc.txt) says that =
there
> is a one-to-one correspondence between "ranges" entries and
> chipselects,
> based on how the eLBC is actually programmed.  The details of what is
> attached come in the subnodes.
>=20
> I don't see how the above mapping is possible with eLBC -- you're
> splitting CS2 among 0xd1000000..0xd1007fff and 0xd2000000..0xd2007fff.
> Since you have CS1 at 0xd0000000, alignment restrictions prevent CS2
> from covering both of those regions -- unless you've got overlapping
> mappings, with CS2 being at least 0xd0000000..0xd3ffffff, and are
> relying on CS1 taking priority due to being lower-numbered.
>=20
> I hope you're not doing that, and that these aren't the real addresses
> (or they can be changed) -- but if you must do this, that breaks the
> one-to-one model, so you'd need both ranges entries.
>=20
> Also note that the final cell in each ranges entry should be the size,
> not the size minus one.
>=20
> >                 fpe1: fpga@2, {
> >                 }
> >
> >                 fpe2: fpga@2, {
>=20
> This would be fine for a case where the devices are not switched, but
> rather decode different addresses within the chipselect.
>=20
> E.g. CS3 of arch/powerpc/boot/dts/socrates.dts
>=20
> -Scott

Thanks, Scott ... I'm looking both at the localbus docs and the Socrates =
... I will stare at both for the requisite time, and re-emerge when I =
understand the issues.

Rob.

RE: fpga driver on custom PPC target platform (P4080) ...

[Robert Sciuk]

> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]
> Sent: Monday, November 07, 2011 5:14 PM
> To: Robert Sciuk
> Cc: linuxppc-dev@lists.ozlabs.org; devicetree-discuss@lists.ozlabs.org
> Subject: Re: fpga driver on custom PPC target platform (P4080) ...
>=20
...=20
> If you need to poke an i2c bus to switch access between certain
> localbus children, you should remove "simple-bus" from the compatible =
-- or
> perhaps do something like:
>=20

Actually, the gpio expander on the I2C bus don't select the localbus =
children, but the programming pins are driven by the i2c bus, and each =
FPGA has its own gpio expander (PCA9539).  ... Ultimately, I will link =
the i2c address and localbus (8 bit programming port) via phandles, but =
both of the optional fpga's have their databus tied to the same chip =
select on the localbus.  The intent was to perform simultaneous =
programming, but I would like the option to do both simultaneous and =
individual programming ... eg:  set either one or both of the FPGAs to =
programming mode, and then mmap the localbus port from user land (uio =
driver), and transmit the bit stream.  The DONE (success/fail) bit would =
be returned by the device close ... or at least that's how I dreamed it =
might work ... again, I will stare at the fsl elbc device tree doc, and =
I can certainly re-map the addressing (36bit ... it=92s a P4080 target).



> localbus@ffe124000 {
> 	compatible =3D "fsl,p4080-elbc", "fsl,elbc", "simple-bus";
> 	...
>=20
> 	flash@0,0 {
> 		...
> 	};
>=20
> 	switched-bank@2,0 {
> 		// no simple-bus here
> 		compatible =3D "something specific to your board's setup";
> 		ranges =3D <0 0 2 0 0x8000>;
>=20
> 		// reg is here just to make the unit-addres valid
> 		reg =3D <2 0 0>;
>=20
> 		#address-cells =3D <2>;
> 		#size-cells =3D <1>;
>=20
> 		// specify a phandle to the i2c device and any other
> 		// relevant details for identifying which knob of the
> 		// switch needs to be turned...
>=20
> 		// replace x/y with appropriate switch ID, and 0 0x8000
> 		// with appropriate portion of the window being used by
> 		// each device
> 		fpga@x,0 {
> 			compatible =3D ...
> 			reg =3D <x 0 0x8000>;
> 			...
> 		};
>=20
> 		fpga@y,0 {
> 			compatible =3D ...
> 			reg =3D <y 0 0x8000>;
> 			...
> 		};
> 	};
> };
>=20
> >
> > 	        localbus@ffe124000 {
> >                 compatible =3D "fsl,p4080-elbc", "fsl,elbc", =
"simple-
> bus";
> >                 reg =3D <0xf 0xfe124000 0 0x1000>;
> >                 interrupts =3D <25 2 0 0>;
> >                 interrupt-parent =3D <&mpic>;
> >                 #address-cells =3D <2>;
> >                 #size-cells =3D <1>;
> >
> >                 /* Local bus region mappings */
> >                 ranges =3D <0 0 0xf 0xe8000000 0x08000000         /*
> CS0: Boot flash */
> >                           1 0 0xf 0xd0000000 0x7fff             /*
> CS1: FPGA0 -  LIM */
> >                           2 0 0xf 0xd1000000 0x7fff             /*
> CS2: FPGA1 -  FPE1 */
> >                           2 0 0xf 0xd2000000 0x7fff >;          /*
> CS2: FPGA2 -  FPE2 */
>=20
> The binding for FSL localbus nodes
> (Documentation/devicetree/bindings/powerpc/fsl/lbc.txt) says that =
there
> is a one-to-one correspondence between "ranges" entries and
> chipselects,
> based on how the eLBC is actually programmed.  The details of what is
> attached come in the subnodes.
>=20
> I don't see how the above mapping is possible with eLBC -- you're
> splitting CS2 among 0xd1000000..0xd1007fff and 0xd2000000..0xd2007fff.
> Since you have CS1 at 0xd0000000, alignment restrictions prevent CS2
> from covering both of those regions -- unless you've got overlapping
> mappings, with CS2 being at least 0xd0000000..0xd3ffffff, and are
> relying on CS1 taking priority due to being lower-numbered.
>=20
> I hope you're not doing that, and that these aren't the real addresses
> (or they can be changed) -- but if you must do this, that breaks the
> one-to-one model, so you'd need both ranges entries.
>=20
> Also note that the final cell in each ranges entry should be the size,
> not the size minus one.
>=20
> >                 fpe1: fpga@2, {
> >                 }
> >
> >                 fpe2: fpga@2, {
>=20
> This would be fine for a case where the devices are not switched, but
> rather decode different addresses within the chipselect.
>=20
> E.g. CS3 of arch/powerpc/boot/dts/socrates.dts
>=20
> -Scott