All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.