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
next prev 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).