From: Laurent Pinchart <laurentp@cse-semaphore.com>
To: linuxppc-dev@ozlabs.org
Subject: Help needed to describe a custom bus in the device tree
Date: Tue, 11 Mar 2008 15:27:26 +0100 [thread overview]
Message-ID: <200803111527.32836.laurentp@cse-semaphore.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 4898 bytes --]
Hi everybody,
the migration process from ARCH=ppc to ARCH=powerpc is easier than I thought
in some parts, but a few devices are still giving me headaches. This should
hopefully be one of my last major requests for help (I'm sure most of you
will be happy to see traffic on this list going down when I'll be done :-))
I'm having trouble describing a custom bus named MS bus (completely unrelated
to a well-known software company) in the device tree. The hardware is
MPC8248-based and has the following hardware topology.
MPC8248 <-- localbus --> FPGA <-- ms bus --> Custom peripherals
The bus interrupt controller, serial access (SPI) controller and status
registers are accessed through memory-mapped registers in the FPGA. Parallel
access to the MS bus is handled transparently by the FPGA which handles
address mapping.
The FPGA is mapped on the locabus at address 0xf4000000. Bus control registers
are at 0xf4002000 - 0xf4003000. The parallel bus memory window on the
localbus is located at 0xf5000000.
My current dts draft describes that topology as follows (unrelated devices on
the local bus such as flash memory are removed for clarity).
localbus@f0010100 {
compatible = "fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <f0010100 40>;
ranges = <0 0 40000000 01000000
2 0 f2000000 00100000
3 0 f3000000 00100000
4 0 f4000000 00100000
5 0 f5000000 00100000>;
fpga@4,0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <4 0 0 00010000>;
msbus-arbitrer@2000 {
compatible = "tbox,cp11-msbus-arbitrer";
reg = <2000 4>;
};
msbus_pic: interrupt-controller@2100 {
compatible = "tbox,cp11-msbus-pic";
reg = <2100 8>;
interrupts = <17 2>;
interrupt-parent = <&cpm_pic>;
#interrupt-cells = <1>;
interrupt-controller;
};
msbus-spi@2200 {
compatible = "tbox,cp11-msbus-spi";
reg = <2200 100>;
interrupts = <18 8>;
interrupt-parent = <&cpm_pic>;
};
sdhc@5000 {
compatible = "tbox,sdhci";
reg = <5000 1000>;
interrupts = <16 8>;
interrupt-parent = <&cpm_pic>;
};
};
msbus@5,0 {
compatible = "tbox,cp11-msbus";
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <1>;
reg = <5 0 0 00000400>;
interrupt-parent = <&msbus_pic>;
};
};
The device tree reflects the physical topology but makes driver access to the
bus quite complex. An OF platform device driver matching on compatible
= "tbox,cp11-msbus" will not have the bus FPGA registers described in its
device node.
Having a look at the various device trees included in the kernel sources, it
seems platforms with a PCI bus experience a similar problem. To solve it the
PCI bus node address and registers describe the configuration registers, and
the memory window to access PCI devices is described by the ranges property.
Applying that to my custom bus would lead to the following tree.
localbus@f0010100 {
compatible = "fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <f0010100 40>;
ranges = <0 0 40000000 01000000
2 0 f2000000 00100000
3 0 f3000000 00100000
4 0 f4000000 00100000
4 1 f4002000 00000100
5 0 f5000000 00100000>;
fpga@4,0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <4 0 0 00010000>;
msbus_pic: interrupt-controller@2100 {
compatible = "tbox,cp11-msbus-pic";
reg = <2100 8>;
interrupts = <17 2>;
interrupt-parent = <&cpm_pic>;
#interrupt-cells = <1>;
interrupt-controller;
};
msbus-spi@2200 {
compatible = "tbox,cp11-msbus-spi";
reg = <2200 100>;
interrupts = <18 8>;
interrupt-parent = <&cpm_pic>;
};
sdhc@5000 {
compatible = "tbox,sdhci";
reg = <5000 1000>;
interrupts = <16 8>;
interrupt-parent = <&cpm_pic>;
};
};
msbus@4,1 {
compatible = "tbox,cp11-msbus";
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <1>;
reg = <4 1 4>;
interrupt-parent = <&msbus_pic>;
ranges = <5 0 0 00000400>;
};
};
Is this correct ? Is that the best way to describe my custom bus in the device
tree ? How would the relationships between the bus and its PIC and SPI
controller be handled in the drivers ? I also don't understand how interrupt
mappings are supposed to be handled. PCI busses have two CPM interrupt lines,
one for the PCI PIC and one for the PCI bus, with the PCI bus having the CPM
PIC as its interrupt controller. My bus PIC uses a single interrupt line. Is
there some documentation explaining how PICs and interrupt mappings should be
described ?
Thanks in advance for any help you can provide.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2008-03-11 14:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-11 14:27 Laurent Pinchart [this message]
2008-03-11 22:54 ` Help needed to describe a custom bus in the device tree David Gibson
2008-03-13 14:12 ` Laurent Pinchart
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=200803111527.32836.laurentp@cse-semaphore.com \
--to=laurentp@cse-semaphore.com \
--cc=linuxppc-dev@ozlabs.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).