remoteproc: Resource table for IRQs

remoteproc: Resource table for IRQs

[Michal Simek]

Hi Ohad and others,

I would like to open new topic about remoteproc and IRQ.
As you know we run AMP on dual core arm cortex A9. The first
cpu runs Linux and the second rtos.

Both cpus use the same GIC and Linux is able to forward IRQ
to specific CPU. Currently this functionality is hardcoded
and the kernel always forward specific IRQs to firmware.

I think that will be good to move IRQ description to resource table
and kernel could check if this IRQ is used or not and if not then
setup GIC to forward this IRQ to the second CPU.

I think that reasonable solution is to extend fw_resource_type for RSC_IRQ.

What do you think?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

Re: remoteproc: Resource table for IRQs

[Ohad Ben-Cohen]

Hi Michal,

On Tue, Mar 13, 2012 at 11:41 AM, Michal Simek <monstr@monstr.eu> wrote:
> What do you think?

I'd really prefer to see some code to make sure I understand exactly
what you mean.

Any change you can post something ?

Maybe even just the hard coded forwarding implementation you have today.

Thanks,
Ohad.

Re: remoteproc: Resource table for IRQs

[Michal Simek]

Hi Ohad,

Ohad Ben-Cohen wrote:
> Hi Michal,
> 
> On Tue, Mar 13, 2012 at 11:41 AM, Michal Simek <monstr@monstr.eu> wrote:
>> What do you think?
> 
> I'd really prefer to see some code to make sure I understand exactly
> what you mean.
> 
> Any change you can post something ?
> 
> Maybe even just the hard coded forwarding implementation you have today.

In system I run, cpu0 runs Linux and the second cpu runs any RTOS(let's call it firmware)
 From Linux point of view in ideal case all information which Linux work with
comes from resource table.
An expectation is that firmware will want to use IRQs. For default case all IRQs are forwarded
to cpu0 which runs Linux. That's why currently I have to forward IRQs requested by firmware to cpu1.
(It is done through new private gic function called gic_set_cpu). It is hardcoded in Linux code
that's why I am losing flezibility and I will have to explicitly say before firmware is loaded
which IRQs will be used.

For example:
Linux starts at cpu0
I know that firmware 1 requires IRQs 23.25
that's why I call git_set_cpu(1,23) and git_set_cpu(1,25) to forward IRQs to cpu1.
Then remoteproc is loaded/probed.
Firmware announces services
any work
Remove module and load firmware 2 which requires IRQs (26.28)
then I am stuck because they are not forwarded yet.


There are several solutions which can solve it:
0. Hardcoded all IRQs for all firmware which could run on zynq
con: loosing flezibility

1. Firmware can change gic and forward IRQ to itself
con: Completely out of Linux control - any linux driver can use that IRQ

2. Forward IRQs in module which will target firmware file.
con: Firmware file name could be the same and maybe make sense to be the same because that differences
can be done based on announcement services
con: less error prone because of different firmware versions

3. Do it explicitly based on resource_table which exactly describe what firmware needs
con: Maybe can be useful just for my case

Option 2 is possible to use but seems to me that using resource_table would be better.


We have played with idea that it could be also possible to run Linux in SMP mode
and then when it is request to use firmware switch cpu1 to run firmware and after
that move back SMP mode.

Maybe I am trying to do things more complicated than they are but
I still see that make sense to do it.
What do you think?

Thanks,
Michal




-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

Re: remoteproc: Resource table for IRQs

[Ohad Ben-Cohen]

Hi Michal,

On Mon, Mar 19, 2012 at 3:38 PM, Michal Simek <monstr@monstr.eu> wrote:
> Maybe I am trying to do things more complicated than they are but
> I still see that make sense to do it.

I agree, it definitely does.

OMAP4 is using this kind of resource allocation for a plethora of resources.

In general there are two options to do this:

- static, via remoteproc (firmware tells us about its resources
requirements via the resource table, Linux allocates them before
booting firmware)
- dynamic, via rpmsg (firmware tells us about its resources
requirements by sending a message just before the relevant use case
kicks in, Linux allocates it only at that point)

The former consumes the resource as long as the remote processor is
powered on, but it's super simple: just add a new resource type.

The latter consumes the resource on when really needed, but it
requires a "resource manager": an rpmsg driver which does this kind of
resource allocation and tracking. Fernando (cc'ed) implemented it
already, and will be posting sometimes in the near future (it's
already available in Fernando's github tree if you're interested).

> What do you think?

Go for it :)

Thanks,
Ohad.