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

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

[Michal Simek]

[-- Attachment #1.1: Type: text/plain, Size: 3985 bytes --]

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@0 {
		...
	}
}
lmb@0 {
	...
	iomodule@X {
		...
	}
}
axi@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@0 {
		...
	}
	cpu@1 {
		...
	}
}
lmb_cpu0@0 {
	...
	iomodule0@X {
		...
	}
}
lmb_cpu1@0 {
	...
	iomodule1@X {
		...
	}
}
axi@X {
	...
	shared nodes
	...
}


or use bus handles in cpu

cpus {
	...
	cpu@0 {
		...
		bus-lmb = <&lmb_cpu0> ;
		bus-handle = <&axi> ;
	}
	cpu@1 {
		...
		bus-lmb = <&lmb_cpu1> ;
		bus-handle = <&axi> ;
	}
}
lmb_cpu0@0 {
	...
	iomodule0@X {
		...
	}
}
lmb_cpu1@0 {
	...
	iomodule1@X {
		...
	}
}
axi@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@0 {
		...
	}
}
axi@X {
	...
	io_intc: intc@C {
		interrupt-controller ;
		interrupt-parent = <&cpu@0> ;
	}
	...
}

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

cpus {
	...
	cpu@0 {
		interrupt-handle = <&io_intc> ;
		...
	}
}
axi@X {
	...
	io_intc: intc@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



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

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

[Grant Likely]

On Mon, 27 May 2013 15:23:57 +0200, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> 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@0 {
> 		...
> 	}
> }
> lmb@0 {
> 	...
> 	iomodule@X {
> 		...
> 	}
> }
> axi@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@0 {
> 		...
> 	}
> 	cpu@1 {
> 		...
> 	}
> }
> lmb_cpu0@0 {
> 	...
> 	iomodule0@X {
> 		...
> 	}
> }
> lmb_cpu1@0 {
> 	...
> 	iomodule1@X {
> 		...
> 	}
> }
> axi@X {
> 	...
> 	shared nodes
> 	...
> }
> 
> 
> or use bus handles in cpu
> 
> cpus {
> 	...
> 	cpu@0 {
> 		...
> 		bus-lmb = <&lmb_cpu0> ;
> 		bus-handle = <&axi> ;
> 	}
> 	cpu@1 {
> 		...
> 		bus-lmb = <&lmb_cpu1> ;
> 		bus-handle = <&axi> ;
> 	}
> }
> lmb_cpu0@0 {
> 	...
> 	iomodule0@X {
> 		...
> 	}
> }
> lmb_cpu1@0 {
> 	...
> 	iomodule1@X {
> 		...
> 	}
> }
> axi@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@0 {
> 		...
> 	}
> }
> axi@X {
> 	...
> 	io_intc: intc@C {
> 		interrupt-controller ;
> 		interrupt-parent = <&cpu@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@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.

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

[Michal Simek]

[-- Attachment #1.1: Type: text/plain, Size: 7379 bytes --]

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-pSz03upnqPeHXe+LvDLADg@public.gmane.org> 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@0 {
>> 		...
>> 	}
>> }
>> lmb@0 {
>> 	...
>> 	iomodule@X {
>> 		...
>> 	}
>> }
>> axi@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?


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


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

We can do SMP on Microblaze. We can do also AMP as we are doing on arm zynq.
It means it is up to user what user wants to run.
That's why system must be fully described.

The second point here that we configure qemu based on DTS description
and if system is not fully described then we are not able to do it.

And yes, Parsing/filter devices should be up to system or communication mechanism
to decide which device is used by which core/OS.

>> LMB is private cpu bus and two options I have for description is to use
>> specific names for it
>> cpus {
>> 	...
>> 	cpu@0 {
>> 		...
>> 	}
>> 	cpu@1 {
>> 		...
>> 	}
>> }
>> lmb_cpu0@0 {
>> 	...
>> 	iomodule0@X {
>> 		...
>> 	}
>> }
>> lmb_cpu1@0 {
>> 	...
>> 	iomodule1@X {
>> 		...
>> 	}
>> }
>> axi@X {
>> 	...
>> 	shared nodes
>> 	...
>> }
>>
>>
>> or use bus handles in cpu
>>
>> cpus {
>> 	...
>> 	cpu@0 {
>> 		...
>> 		bus-lmb = <&lmb_cpu0> ;
>> 		bus-handle = <&axi> ;
>> 	}
>> 	cpu@1 {
>> 		...
>> 		bus-lmb = <&lmb_cpu1> ;
>> 		bus-handle = <&axi> ;
>> 	}
>> }
>> lmb_cpu0@0 {
>> 	...
>> 	iomodule0@X {
>> 		...
>> 	}
>> }
>> lmb_cpu1@0 {
>> 	...
>> 	iomodule1@X {
>> 		...
>> 	}
>> }
>> axi@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.

ok great.


>> 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@0 {
>> 		...
>> 	}
>> }
>> axi@X {
>> 	...
>> 	io_intc: intc@C {
>> 		interrupt-controller ;
>> 		interrupt-parent = <&cpu@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.

ok.


>> or better to use interrupt-handle property directly in cpu node.
>>
>> cpus {
>> 	...
>> 	cpu@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.

Not yet but description should be first.

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?

And in this configuration let's say Microblaze with standard axi timer, timer
node should use the same description as was before (because we don't want to change
the driver).
Which IMHO points to this description where interrupt-parent is CPU itself.

		system_timer: system-timer@41c00000 {
			compatible = "xlnx,axi-timer-1.03.a", "xlnx,xps-timer-1.00.a";
			interrupt-parent = <&microblaze>;
			interrupts = < 0 >;
			reg = < 0x41c00000 0x10000 >;
		} ;

But as you have written above cpu is not interrupt controller but in this
"single interrupt line in the system" cpu behaves like interrupt controller
where you don't need to look for which irq caused interrupts but drivers
should be the same.

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



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

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

[Grant Likely]

On Tue, 11 Jun 2013 16:08:11 +0200, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> 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-pSz03upnqPeHXe+LvDLADg@public.gmane.org> 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@0 {
> >> 		...
> >> 	}
> >> }
> >> lmb@0 {
> >> 	...
> >> 	iomodule@X {
> >> 		...
> >> 	}
> >> }
> >> axi@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.

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

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

g.

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

[Michal Simek]

[-- Attachment #1.1: Type: text/plain, Size: 5622 bytes --]

On 06/12/2013 12:22 AM, Grant Likely wrote:
> On Tue, 11 Jun 2013 16:08:11 +0200, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> 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-pSz03upnqPeHXe+LvDLADg@public.gmane.org> 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@0 {
>>>> 		...
>>>> 	}
>>>> }
>>>> lmb@0 {
>>>> 	...
>>>> 	iomodule@X {
>>>> 		...
>>>> 	}
>>>> }
>>>> axi@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@0 {
			clock-frequency = <75000000>;
			compatible = "xlnx,microblaze-8.50.a";
			device_type = "cpu";
			interrupt-handle = <>; /* empty or not available */
		} ;
	} ;
	mcb_ddr3: memory@80000000 {
		device_type = "memory";
		reg = < 0x80000000 0x8000000 >;
	} ;
	axi4lite_0: axi@1 {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "xlnx,axi-interconnect-1.06.a", "simple-bus";
		ranges ;
		system_timer: system-timer@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



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

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

[Grant Likely]

On Wed, Jun 12, 2013 at 7:30 AM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote:
> On 06/12/2013 12:22 AM, Grant Likely wrote:
>> On Tue, 11 Jun 2013 16:08:11 +0200, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote:
>> 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.

A driver cannot call request_irq if it doesn't have an irq number to
call it with, and it won't have an IRQ number if there is no irq
specifier in the DT, so you should be fine in that regard.

g.

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

[Michal Simek]

[-- Attachment #1.1: Type: text/plain, Size: 2185 bytes --]

On 06/12/2013 11:16 AM, Grant Likely wrote:
> On Wed, Jun 12, 2013 at 7:30 AM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote:
>> On 06/12/2013 12:22 AM, Grant Likely wrote:
>>> On Tue, 11 Jun 2013 16:08:11 +0200, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote:
>>> 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.
> 
> A driver cannot call request_irq if it doesn't have an irq number to
> call it with, and it won't have an IRQ number if there is no irq
> specifier in the DT, so you should be fine in that regard.

That's correct but in my example there was interrupt listed and connected
because it also says that interrupt is enabled directly on the IP.

I have also started to think how to properly describe clocksource
driver because it is also uniq in the system because all cpus
should have access to this IP.
It means that not every timer could be possible to use for this purpose.
What we have for single microblaze and multi cpu system is just extension
of this is that we are using special name for this clocksource timer
which is called system-timer.
Do you think that this rule is fine or any additional description should
be made?

Clockevent is easy because the first suitable timer can be used for it
or the most accurate one.

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



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss