-----Original Message-----
From: Grant Likely [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] On Behalf Of Grant

Likely

Sent: Saturday, October 04, 2008 10:58 PM
To: Stephen Neuendorffer
Cc: git-dev; Walter Tomkoski; Michal Simek; Jim Hwang;

devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org

Subject: Re: Device tree for c67x00

(added devicetree-discuss mailing list to cc: list since some of the
content is relevant to current discussions about device tree syntax.)

On Fri, Sep 26, 2008 at 04:09:01PM -0700, Stephen Neuendorffer wrote:

quoted

Below is an fdt patch for the cypress USB.  It generates fragments

like:

quoted

                ext_usb: xps-epc@85000000 {
                        #address-cells = <1>;
                        #size-cells = <1>;
                        compatible = "xlnx,compound";
                        ranges = < 0x85000000 0x85000000 0x10000 >;

Aside: Considering that this is a 1:1 mapping, you could just specify
"ranges;" here instead...  Of course, since the epc devices really are
bridges, it probably is appropriate for ranges to be explicit.

However, since the epc devices have multiple chip selects, it might be
better to use #address-cells = <2> and encode the chip select in the
first address cell.  Then ranges would look something like this:
	ranges = < 0 0 0x85000000 0x10000 >; (CS0, offset 0)

Additional chip selects would add additional tuples to the ranges
property:
	ranges = < 0 0 0x85000000 0x10000    (CS0, offset 0)
	           1 0 0x86000000 0x10000 >; (CS1, offset 0)

and the reg property for the c67x00 would be:
	reg = <0 0 0x10000>;

Hmm.. interesting idea.

This scheme would be an accurate representation of what the FPGA

design

is actually doing.

quoted

                        usb@85000000 {
                                compatible = "cypress,c67x00";
                                reg = < 0x85000000 0x10000 >;
                        } ;
                } ;

Assuming, of course, that we connect through the epc core.
There are two pieces of trickiness:

1) How do we know that the epc connects to a cypress chip outside of

the

quoted

FPGA.  This needs to be encoded in the EDK project somehow..  We

have

quoted

the same problem with FLASH.

This is a major use-case for the new syntax being discussed to add to

dtc.

Specifically being able to include one file into another.  It would be
desirable for EDK to generate a base layout that describes the FPGA
design, and then have a board file that includes the generated file

and

adds the nodes/properties that are board, not FPGA, specific.

I'll try to write up some specific use cases that would help in
evaluating new dts syntax.  (Jon, David; I can't help much with the

dtc

code, but I can at least provide my impressions from the user side of
the equation).

I completely agree..  At the moment I'm more concerned about how that
might be encoded in the EDK project...  Although maybe it's not as much
of an issue (although if the device tree information for the board is
completely disconnected from EDK, then it would force a board designer
to replicate information that might be in Base System Builder).

Steve

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.