devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	John Williams
	<john.williams-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org>
Subject: Re: Device tree FSL description for Microblaze
Date: Tue, 12 Jul 2011 08:30:47 +0200	[thread overview]
Message-ID: <4E1BEA17.6020004@monstr.eu> (raw)
In-Reply-To: <4DDCE793.9080709-pSz03upnqPeHXe+LvDLADg@public.gmane.org>

Any comments on this?

Michal

Michal Simek wrote:
> Hi,
> 
> I would like to check with you proper device tree FSL description for 
> Microblaze (PPC can use FSL through IP connected to the bus).
> 
> Microblaze supports FSL buses to connect coprocessors or hw accelerators 
> directly to the cpu. Cpu has up to 16 fsl bus connections - master and 
> slave side. (BTW: in the latest Microblaze with AXI is possible to use 
> AXI stream instead of FSL but description should be the same),
> FSL bus has one master and in most cases one slave (more point-to-point 
> connection than bus) but I think there could be an option to have 
> multiple slaves for cases where the same input data goes to n-slaves.
> There is also an option to generate interrupt if there is any data on 
> the bus.
> 
> FSL devices can have multiple FSL inputs and outputs and they also can 
> generate interrupts.
> 
> There is also one option to have only loopback which means connect CPU 
> FSL master to CPU FSL slave with optional interrupt enabling.
> 
> I am also aware of one more option which is possibility to use a bridge 
> instead of CPU (this option is not shown below).
> 
> Currently I have changed our generator to have the first description 
> which I would like to use for our discussion.
> 
> Below is the important part which I would like to discuss - it is fake 
> hw design but illustrate some important cases.
> 
> Here are some my notes:
> 1. I can't add FSL device directly to the CPU node because connection 
> could be from axi IP. And I need to separate interrupt generation if 
> there is any activity on a bus. That's why I separate fsl bus and 
> devices out of CPU.
> 2. I think that shouldn't be a problem to have fsl buses in the root node
> 3. I think fsl devices should be moved out of root node but the point is 
> where.
> It is not bus sub/node because device can be connected to several buses. 
> There could be a lot of connections. Any suggestions?
> 4. Please let me know if there should be any cells properties or similar.
> 5. There is not any address on the bus. FSL devices has some registers.
> 6. Should I use different address than 0 for connection from cpu? mfsl@5 
> instead of mfsl5@0?
> 
> Thanks,
> Michal
> 
> 
> 
> /dts-v1/;
> / {
>     #address-cells = <1>;
>     #size-cells = <1>;
>     compatible = "xlnx,microblaze";
>     model = "axi-loopback";
> 
> /* cpu node */
>     cpus {
>         #address-cells = <1>;
>         #cpus = <0x1>;
>         #size-cells = <0>;
>         microblaze_0: cpu@0 {
> ... /* some cpu parameters */
>             xlnx,use-stack-protection = <0x0>;
> 
>         /* fsl_m -> master side, fsl_s -> slave side */
>             fsl_m_0: mfsl0@0 {
>                 link = <&fsl_v20_2>; /* bus connection */
>             } ;
> ...
>             fsl_m_5: mfsl5@0 {
>                 link = <&fsl_v20_9>;
>             } ;
>             fsl_s_0: sfsl0@0 {
>                 link = <&fsl_v20_1>;
>             } ;
> ...
>             fsl_s_5: sfsl5@0 {
>                 link = <&fsl_v20_10>;
>             } ;
>         } ;
>     } ;
> 
> /* FSL buses - all look the same that's why I keep here only two - I 
> expect you will beat me for simple-bus compatible property.  */
> /* The first where all interrupts are connected */
>     fsl_v20_0: fsl-v20-0@0 {
>         compatible = "xlnx,fsl-v1.00.a", "simple-bus";
>         interrupt-parent = <&microblaze_0_intc>;
>         interrupts = < 11 2 4 2 10 2 >;
>         xlnx,async-clks = <0x0>;
>         xlnx,ext-reset-high = <0x1>;
>         xlnx,fsl-depth = <0x10>;
>         xlnx,fsl-dwidth = <0x20>;
>         xlnx,impl-style = <0x0>;
>         xlnx,read-clock-period = <0x0>;
>         xlnx,use-control = <0x1>;
>     } ;
> /* bus without interrupts */
>     fsl_v20_10: fsl-v20-10@0 {
>         compatible = "xlnx,fsl-v1.00.a", "simple-bus";
>         xlnx,async-clks = <0x0>;
>         xlnx,ext-reset-high = <0x1>;
>         xlnx,fsl-depth = <0x10>;
>         xlnx,fsl-dwidth = <0x20>;
>         xlnx,impl-style = <0x0>;
>         xlnx,read-clock-period = <0x0>;
>         xlnx,use-control = <0x1>;
>     } ;
> 
> ....
> 
> /* simple ip - one input and one output + parameters and interrupt */
>     axi_stream_test_0: axi-stream-test-0@0 {
>         MFSL = <&fsl_v20_3>;
>         SFSL = <&fsl_v20_2>;
>         interrupt-parent = <&microblaze_0_intc>;
>         interrupts = < 3 2 >;
>         xlnx,use-rexa = <0x0>;
>         xlnx,use-rexam = <0x2>;
>         xlnx,use-rexample = <0x4>;
>     } ;
> ...
> /* IP with two inputs and one output */
>     multiinput_dev_0: multiinput-dev-0@0 {
>         MFSL0 = <&fsl_v20_11>;
>         SFSL0 = <&fsl_v20_12>;
>         SFSL1 = <&fsl_v20_13>;
>         xlnx,use-exa = <0x0>;
>         xlnx,use-exam = <0x2>;
>         xlnx,use-example = <0x4>;
>     } ;
> 
> /* IP with two inputs and two outputs */
>     multiport_fsl_0: multiport-fsl-0@0 {
>         MFSL0 = <&fsl_v20_8>;
>         MFSL1 = <&fsl_v20_5>;
>         SFSL0 = <&fsl_v20_7>;
>         SFSL1 = <&fsl_v20_6>;
>         xlnx,use-test = <0x3>;
>     } ;
> 
> 
> /* the rest of IP connected to axi */
>     axi4lite_0: axi@0 {
>         #address-cells = <1>;
>         #size-cells = <1>;
>         compatible = "xlnx,axi-interconnect-1.03.a", "simple-bus";
>         ranges ;
> ...
>         microblaze_0_intc: interrupt-controller@41200000 {
>             #interrupt-cells = <0x2>;
>             compatible = "xlnx,axi-intc-1.01.a";
>             interrupt-controller ;
>             reg = < 0x41200000 0x10000 >;
>             xlnx,kind-of-intr = <0x144>;
>             xlnx,num-intr-inputs = <0xc>;
>         } ;
>     } ;
> } ;
> 
> 
> 
> 
> 


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

  parent reply	other threads:[~2011-07-12  6:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-25 11:27 Device tree FSL description for Microblaze Michal Simek
     [not found] ` <4DDCE793.9080709-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
2011-07-12  6:30   ` Michal Simek [this message]
     [not found]     ` <4E1BEA17.6020004-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
2011-07-12 15:12       ` Grant Likely
     [not found]         ` <CACxGe6tVGa4H8-Bep89-wNQzR11bFeJ6dS3S18sYN=g0_1r+tw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-07-12 15:48           ` John Williams
2011-07-15  2:53   ` Grant Likely

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=4E1BEA17.6020004@monstr.eu \
    --to=monstr-psz03upnqpehxe+lvdladg@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=john.williams-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org \
    /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).