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

[Grant Likely]

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.

> 
> 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?

The DT design currently assumes that then whole tree is from the view of
the CPU that the code is running on. CPUs that aren't part of the 'core'
system typically don't show up in the /cpus node. In your case however,
I can see the arguement for wanting a single tree that describes
everything and each CPU needs to know how to filter the tree for only
the devices that belong to it. Am I correct so far?

> 
> 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.

The bus handle approach makes perfect sense to me. It is local to the
CPU and it can use those properties to decide which nodes in the rest of
the tree are important.

> 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> ;
> 	}
> 	...
> }

This makes a bit of sense if you think of CPUs as a very simple
interrupt controller with only one input. However, it doesn't line up
well since there really isn't much you can do with that controller, and
you don't want to have to add "interrupt-controller" and
"#interrupt-cells" to the cpu node.

> 
> or better to use interrupt-handle property directly in cpu node.
> 
> cpus {
> 	...
> 	cpu at 0 {
> 		interrupt-handle = <&io_intc> ;
> 		...
> 	}
> }

This makes more sense. The CPU needs to know which intc it should look
at for its first level of interrupt handling. I assume you have a
mechanism for the OS to determine which cpu node is its 'home' node.

g.