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

[Michal Simek]

On 06/12/2013 12:22 AM, Grant Likely wrote:
> On Tue, 11 Jun 2013 16:08:11 +0200, Michal Simek <monstr at monstr.eu> wrote:
>> Hi Grant,
>>
>> nice that you have found a time to look at this.
>>
>> On 06/11/2013 03:02 PM, Grant Likely wrote:
>>> On Mon, 27 May 2013 15:23:57 +0200, Michal Simek <monstr at monstr.eu> wrote:
>>>> 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.
>>>
>>> Mostly correct; it is also possible for an interrupt controller to
>>> cascade to two different parent controllers, and in that case there
>>> would need to be an interrupt-map somewhere. That case is rare however.
>>
>> Any dts in the kernel which uses this?
> 
> You can find lots of examples of the interrupt-map property by doing
> git grep. Most of them are PCI interrupt controllers which is similar to
> what you're asking, but not entirely the same. I have seen examples in
> the past, but I cannot remember off the top of my head.

ok.

I forget to mention one more thing related to buses.
As you mentioned bus-handle is fine.
Maybe worth for lmb and axi case to add them to one handler.

bus-handle = <&lmb &axi>

which also show priorities.



>>>> 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.
>>>
>>> Are you doing SMP in this case? I assume that you are not because we're
>>> talking about microblaze here. Separate OSes on each CPU?
>>
>> As you know on fpga we can do a lot of things. I am not talking about SMP
>> case here because it should also cover non SMP cases.
>> But yeah, Microblaze can also do SMP.
> 
> Nice! I didn't expect that. I assumed that cache coherency would have
> been too expensive to be worth it on an FPGA soft core.

Not sure about that.


>> btw: is there any problem if there is no interrupt controller in the system at all?
>> I think we can setup system just with one timer which should be possible
>> to describe and run Linux on it.
>> Is this any requirement from Linux point of view?
> 
> It would mean every device driver needs to be polled. As long as the
> polling frequency is high enough for the work load then it should be
> okay. I don't see a problem with there being no interrupt controller,
> unless there needs to be a dummy one just to keep the kernel happy.

Interesting. I have tried to compile the fragment below by dtc
and there is no warning. It also means that there is missing checking
in DTC for interrupt-cells.

What I am worried about is that request_irq in the driver will require
irq chip functions which there are not.
But if this is correct description for this type of system then I am ok with it.

/dts-v1/;
/ {
	#address-cells = <1>;
	#size-cells = <1>;
	compatible = "xlnx,microblaze";
	model = "Xilinx-SP605-AXI-full-14.5";
	cpus {
		#address-cells = <1>;
		#cpus = <0x1>;
		#size-cells = <0>;
		microblaze_0: cpu at 0 {
			clock-frequency = <75000000>;
			compatible = "xlnx,microblaze-8.50.a";
			device_type = "cpu";
			interrupt-handle = <>; /* empty or not available */
		} ;
	} ;
	mcb_ddr3: memory at 80000000 {
		device_type = "memory";
		reg = < 0x80000000 0x8000000 >;
	} ;
	axi4lite_0: axi at 1 {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "xlnx,axi-interconnect-1.06.a", "simple-bus";
		ranges ;
		system_timer: system-timer at 41c00000 {
			clock-frequency = <75000000>;
			compatible = "xlnx,axi-timer-1.03.a", "xlnx,xps-timer-1.00.a";
			interrupt-parent = <&microblaze_0>;
			interrupts = < 0 >;
			reg = < 0x41c00000 0x10000 >;
		} ;
	} ;
} ;


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/20130612/89fdf13e/attachment-0001.sig>