Re: Device tree for c67x00

Re: Device tree for c67x00

[Grant Likely]

(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:
> 
> Below is an fdt patch for the cypress USB.  It generates fragments like:
> 
>                 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>;

This scheme would be an accurate representation of what the FPGA design
is actually doing.

>                         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
> FPGA.  This needs to be encoded in the EDK project somehow..  We have
> 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).

> 2) There is also an external interrupt line, but the interrupt line
> doesn't connect through the core.  Presumably, we need someway of
> representing this association in the EDK project as well..

Ditto for this.

> In both cases, this information could be neatly stored in a hierarchical
> design, that described what was inside the FPGA *AND* what was outside,
> but today, we'll just have to hack something in...  Any suggestions?

RE: Device tree for c67x00

[Stephen Neuendorffer]

> -----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:
> >
> > Below is an fdt patch for the cypress USB.  It generates fragments
like:
> >
> >                 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.
> 
> >                         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
> > FPGA.  This needs to be encoded in the EDK project somehow..  We
have
> > 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.

Re: Device tree for c67x00

[Peter Korsgaard]

>>>>> "Grant" == Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> writes:

Hi,

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

This is the first I see of this, but that weren't we supposed to use
the stock ticker (E.G. cy)? It would also be good to list the exact
cy67x00 variant:

usb@85000000 {
             compatible = "cy,c67300" "cy,c67x00";
             ...

-- 
Bye, Peter Korsgaard

Re: Device tree for c67x00

[Grant Likely]

On Mon, Oct 06, 2008 at 09:22:58AM +0200, Peter Korsgaard wrote:
> >>>>> "Grant" == Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> writes:
> 
> Hi,
> 
>  >>     usb@85000000 {
>  >>                  compatible = "cypress,c67x00";
>  >>                  reg = < 0x85000000 0x10000 >;
>  >>                  } ;
> 
> This is the first I see of this, but that weren't we supposed to use
> the stock ticker (E.G. cy)? It would also be good to list the exact
> cy67x00 variant:
> 
> usb@85000000 {
>              compatible = "cy,c67300" "cy,c67x00";
>              ...

Heh, I got caught up in the other discussion and I never thought to
review the binding.  Oops.

Yes, you're absolutely right.  The compatible property should be
specific and the binding needs to be documented and reviewed before
committing to it.  In particular, there needs to be some properties to
describe the mode of each SIE on the c67300.

g.