linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Robert Sciuk <robert.sciuk@exfo.com>
Cc: devicetree-discuss@lists.ozlabs.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: fpga driver on custom PPC target platform (P4080) ...
Date: Mon, 7 Nov 2011 16:14:02 -0600	[thread overview]
Message-ID: <4EB8582A.3070303@freescale.com> (raw)
In-Reply-To: <2DD52030B5146141BEB762A11AE97C4C0100CB3D@SPQCEXC05.exfo.com>

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

  parent reply	other threads:[~2011-11-07 22:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-03 22:12 fpga driver on custom PPC target platform (P4080) Robert Sciuk
2011-11-04 16:36 ` Tabi Timur-B04825
2011-11-04 16:42   ` Robert Sciuk
2011-11-04 18:19   ` Robert Sciuk
2011-11-05  0:40     ` David Gibson
2011-11-07 18:48       ` Robert Sciuk
2011-11-07 20:09       ` Robert Sciuk
2011-11-07 21:31         ` Mitch Bradley
2011-11-07 21:50           ` Robert Sciuk
2011-11-07 22:14         ` Scott Wood [this message]
2011-11-07 23:07           ` Robert Sciuk
2011-11-07 23:29           ` Robert Sciuk
  -- strict thread matches above, loose matches on Subject: below --
2011-11-02 22:43 Robert Sciuk
2011-11-03 21:22 ` Segher Boessenkool

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=4EB8582A.3070303@freescale.com \
    --to=scottwood@freescale.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=robert.sciuk@exfo.com \
    /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).