microblaze device-tree description - pair intc/buses and timers

[Michal Simek]

Hi guys,

we have got a new configurations with iomodule which can be connected to the microblaze
cpu and I would like to have proper description for this system
+ more advance configuration below.

Buses:
Microblaze systems have in standard configuration two buses LMB and AXI(in past PLB).
We didn't generate LMB even there is placed BRAM (block ram)
but Linux expects that there is any writeable memory at 0x0.
Currently because we can use iomodule which is connected to LMB and we need to generate
this bus. I don't expect that there is any problem to have this configuration.

cpus {
	...
	cpu at 0 {
		...
	}
}
lmb at 0 {
	...
	iomodule at X {
		...
	}
}
axi at X {
	...
	nodes
	...
}

Block ram:
When we generate lmb make sense to also add there this small bram memory
but I expect that is it ok just to added to bus and do not add it to the root.
Currently we have an option to use "mmio-sram" compatibility string for it.

Interrupt controller:
Till now Microblaze uses only one interrupt controller on main bus (AXI or PLB)
and we just find compatible string and we said that this is primary interrupt controller.

Based on DTS in the kernel I see that "interrupt-parent" property
reflects which interrupt controller is master and which one is in cascade.

Timer:
System timer was also detected in this way that the first suitable timer was
taken and used. Others were just ignored.


Extend system configuration
We have also got an option to add one more CPU and I would like to have
an option to describe it correctly.

LMB is private cpu bus and two options I have for description is to use
specific names for it
cpus {
	...
	cpu at 0 {
		...
	}
	cpu at 1 {
		...
	}
}
lmb_cpu0 at 0 {
	...
	iomodule0 at X {
		...
	}
}
lmb_cpu1 at 0 {
	...
	iomodule1 at X {
		...
	}
}
axi at X {
	...
	shared nodes
	...
}


or use bus handles in cpu

cpus {
	...
	cpu at 0 {
		...
		bus-lmb = <&lmb_cpu0> ;
		bus-handle = <&axi> ;
	}
	cpu at 1 {
		...
		bus-lmb = <&lmb_cpu1> ;
		bus-handle = <&axi> ;
	}
}
lmb_cpu0 at 0 {
	...
	iomodule0 at X {
		...
	}
}
lmb_cpu1 at 0 {
	...
	iomodule1 at X {
		...
	}
}
axi at X {
	...
	shared nodes
	...
}


which is from my point of view better because it supports
options where one cpu doesn't need to have main axi bus
or lmb or both.

It has also connection to interrupt controller description
where is not clear for system with two cpus which interrupt controller
is primary for every cpu.
It can be illustrated on simple example where there are two interrupt
controllers on axi and both are primary for specific cpu
and we can't exchange them.

It means that I would like to have proper description which interrupt
controller is primary one for specific CPU.
I am not sure if make sense to use interrupt-parent also from
this primary interrupt controller which will point to cpu.

cpus {
	...
	cpu at 0 {
		...
	}
}
axi at X {
	...
	io_intc: intc at C {
		interrupt-controller ;
		interrupt-parent = <&cpu at 0> ;
	}
	...
}

or better to use interrupt-handle property directly in cpu node.

cpus {
	...
	cpu at 0 {
		interrupt-handle = <&io_intc> ;
		...
	}
}
axi at X {
	...
	io_intc: intc at C {
		interrupt-controller ;
	}
	...
}

We don't have any ARM gic interrupt controller which will be always
primary controller.

Grant, Rob: Can you please comment my proposal for descriptions?

In general I want to have exact bus description + interrupt controller
which can be used by specific cpu. Primary timers can be handled
separately.
Is there any other platform description in the kernel which also requires this?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20130527/c381e7f6/attachment.sig>