[PATCH v2] ARM: CSR: Adding CSR SiRFprimaII board support
Barry Song
21cnbao at gmail.com
Wed Jul 6 16:01:24 EST 2011
2011/7/6 Barry Song <21cnbao at gmail.com>:
> 2011/7/6 Grant Likely <grant.likely at secretlab.ca>:
>> On Tue, Jul 05, 2011 at 04:34:05PM +0800, Barry Song wrote:
>>> Hi Arnd,
>>>
>>> 2011/7/1 Barry Song <21cnbao at gmail.com>:
>>> > Hi Arnd,
>>> >
>>> > 2011/6/30 Arnd Bergmann <arnd at arndb.de>:
>>> >> On Thursday 30 June 2011, Barry Song wrote:
>>> >>
>>> >>> > Is this really just one bus with a huge address space, or rather some
>>> >>> > nested buses? I'd prefer to have the device tree representation as
>>> >>> > close as possible to the actual layout.
>>> >>>
>>> >>> there are two AXI buses in prima2. AXI-1 connect to memory, AXI-2 is
>>> >>> transferred to CSR self-defined IOBUS by CPUIF, then 1 intterupt
>>> >>> controller and 9 IO bridges are connected to the IOBUS .
>>> >>> The 9 IO bridges are SYSIOBG, PERIIOBG,CPURTCIOBG, UUSIOBG, GRAPHIOBG,
>>> >>> MEDIAIOBG, DSPIOBG, DISPIOBG, MEMIOBG. Every iobrg connect to a group
>>> >>> of controllers.
>>> >>> For example, DISPIOBG connect to VPP and LCD, SYSIOBG connect to CLKC,
>>> >>> RSTC, RSC and CPHIFBG, DSPIOBG connect to DSPIF, GPS and DSP.
>>> >>> PERIIOBG connect to TIMER, NAND, AUDIO, UART0, UART1, UART2, USP0,
>>> >>> USP1, USP2, SPI0, I2C0, I2C1, GPIO, *SYS2PCI* and so on. Then
>>> >>> *SYS2PCI* connect to SD.
>>> >>>
>>> >>> The indendation descible the device hierarchy
>>> >>> AXI-1
>>> >>> Memory
>>> >>> AXI-2
>>> >>> interrupt controller
>>> >>> IOBG...
>>> >>> xxxx
>>> >>> IOBG...
>>> >>> xxxx
>>> >>> IOBG...
>>> >>> xxxx
>>> >>> IOBG...
>>> >>> xxxx
>>> >>> IOBG...
>>> >>> xxxx
>>> >>> IOBG...
>>> >>> SYS2PCI
>>> >>> SD
>>> >>>
>>> >>> i have get the IC guy Weizeng involved, maybe he can explain better than me :-)
>>> >>
>>> >> I think it would be good to represent the IOBG devices in the device tree then.
>>> >> You don't need to represent AXI-1 because memory is special anyway, and I would
>>> >> not bother to list SYS2PCI if the intention of that block was to hide the fact
>>> >> that it's PCI behind it. Properly instantiating it as a PCI bridge would be
>>> >> a lot of work that is probably not worth it.
>>> >>
>>> >> My usual plea to hardware developers: Please make the registers
>>> >> autodiscoverable from software! On an AMBA bus, please use the PrimeCell
>>> >> register layout. If you always have an IOBG device behind, they should
>>> >> all have the same identifier for that kind of bus bridge.
>>> >>
>>> >> For the IOBG, it would be ideal to have a similar way of finding and
>>> >> configuring the connected hardware, including:
>>> >>
>>> >> * unique identifier for each distinct IP block
>>> >> * revision of that block
>>> >> * MMIO ranges and sizes, relative to the bus
>>> >> * interrupt numbers, relative to a local interrupt controller
>>> >> * location identifier (like PCI bus/device/fn number) that can be
>>> >> referred to by other devices
>>> >> * clock management for that device
>>> >> * power management for that device
>>> >>
>>> >> If your IODB infrastructure already has this, you should create a new
>>> >> bus-type for this in Linux, which will let you detect all devices
>>> >> in a consistent manner without having to list them in the device tree.
>>> >
>>> > IO bridges in prima2 don't have that. Configuration is hardcoded now.
>>> > but we have learned so much from you and hope to improve our future IC
>>> > design.
>>>
>>>
>>> i have tried to figure out the full DT:
>>>
>>> /dts-v1/;
>>> / {
>>> model = "SiRF Prima2 EVB";
>>> compatible = "sirf,prima2-cb", "sirf,prima2";
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> interrupt-parent = <&intc>;
>>>
>>> memory {
>>
>> memory at 0
>>
>>> reg = <0x00000000 0x20000000>;
>>> };
>>>
>>> chosen {
>>> bootargs = "mem=512M real_root=/dev/mmcblk0p2 console=ttyS0 panel=1
>>> bootsplash=true bpp=16 androidboot.console=ttyS1";
>>> linux,stdout-path = &uart1;
>>> };
>>>
>>> cpus {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> ARM-CortexA9,SiRFprimaII at 0 {
>>
>> cpu at 0 {
>>
>> Don't duplicate the crack that powerpc did for cpu node names. Use a
>> compatible property to identify the specific CPU model.
>>
>>> device_type = "cpu";
>>
>> Drop device_type here.
>>
>>> reg = <0x0>;
>>> d-cache-line-size = <32>;
>>> i-cache-line-size = <32>;
>>> d-cache-size = <32768>;
>>> i-cache-size = <32768>;
>>> /* from bootloader */
>>> timebase-frequency = <0>;
>>> bus-frequency = <0>;
>>> clock-frequency = <0>;
>>> };
>>> };
>>>
>>> axi {
>>> compatible = "simple-bus";
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> ranges = <0x40000000 0x40000000 0x80000000>;
>>>
>>> l2-cache-controller at 0x80040000 {
>>
>> l2-cache-controller at 80040000 (Drop the '0x' from node names; address
>> in the node name is always hex.
>>
>>> compatible = "arm,pl310-cache", "cache";
>>
>> Drop the "cache" compatible value here.
>>
>>> reg = <0x80040000 0x1000>;
>>> interrupts = <59>;
>>> };
>>>
>>> sirfsoc-iobus {
>>> compatible = "simple-bus";
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> ranges = <0x56000000 0x56000000 0x1b0000
>>> 0x80010000 0x80010000 0x30000
>>> 0x88000000 0x88000000 0x40040000>;
>>>
>>> intc: interrupt-controller at 0x80020000 {
>>> #interrupt-cells = <1>;
>>> interrupt-controller;
>>> compatible = "sirf,intc", "sirf,prima2-intc";
>>
>> This looks backwards. Most specific values should appear first.
>> "sirf,intc" looks to be generic when compared to "sirf,prima2-intc".
>> I'm also concerned that "sirf,intc" is trying to be too generic. As
>> much as possible compatible values should reflect a real
>> implementation of the interface, not a generic abstract name. Future
>> hardware can always claim compatibility with existing older hardware.
>> You're probably better off dropping "sirf,intc" entirely, and doing
>> the same for similar properties throughout the file.
>
> i have been confused by compatible in dts and drivers for some time.
> if an intc ip core is shared by two chips, for example, prima2 and
> atlas6. is the following right?
>
> in dts for prima2: compatible = "sirf,prima2-intc";
> in dts for atlas6: compatible = "sirf,prima2-atlas6";
sorry for typo. in dts for atlas6: compatible = "sirf,atlas6-intc";
> in intc drivers shared for both: compatible = "sirf,prima2-intc",
> "sirf,prima2-atlas6";
sorry for typo. compatible = "sirf,prima2-intc", "sirf,atlas6-intc";
>
> in my understanding, dts for special soc/board contains special
> compatible for the chip, drivers shared by multi-soc/board contain all
> compatible lists which can be supported by them?
>
> what's the generic way for this?
>
>>
>> Also, for every new compatible value make sure you add documentation
>> for it to Documentation/devicetree/bindings. (You may have already
>> done so, it's just something I remind people about a lot).
>>
>> These comments also apply through the rest of the file.
>>
>>
>
More information about the devicetree-discuss
mailing list