[Xen-devel] [GSoC-2019] About the crossbar and xen

[Xen-devel] [GSoC-2019] About the crossbar and xen

[Denis Obrezkov]

Hello,

so, I think I understood why uart doesn't work, that's because all the
irqs are routed to the crossbar not to GIC, so, xen can't deal with them.

One thing I am concerned of is the:
	interrupt-controller@48281000 {
		compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
		interrupt-controller;
		#interrupt-cells = <0x00000003>;
		reg = <0x00000000 0x48281000 0x00000000 0x00001000>;
		interrupt-parent = <0x00000002>;
		phandle = <0x00000008>;
	};
And this is an interrupt-parent for the crossbar. So, it is not clear
for me how it participates in interrupt processing. Any thoughts?

Here is my device tree: https://pastebin.com/Xec57Jcr
-- 
Regards, Denis Obrezkov

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Stefano Stabellini]

On Wed, 10 Jul 2019, Denis Obrezkov wrote:
> Hello,
> 
> so, I think I understood why uart doesn't work, that's because all the
> irqs are routed to the crossbar not to GIC, so, xen can't deal with them.
> 
> One thing I am concerned of is the:
> 	interrupt-controller@48281000 {
> 		compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
> 		interrupt-controller;
> 		#interrupt-cells = <0x00000003>;
> 		reg = <0x00000000 0x48281000 0x00000000 0x00001000>;
> 		interrupt-parent = <0x00000002>;
> 		phandle = <0x00000008>;
> 	};
> And this is an interrupt-parent for the crossbar. So, it is not clear
> for me how it participates in interrupt processing. Any thoughts?
> 
> Here is my device tree: https://pastebin.com/Xec57Jcr
 
Hi Denis,

If you look at the GIC node (compatible = "arm,cortex-a15-gic";) the
phandle is:

  phandle = <0x00000002>;

I think that means that interrupts go to the GIC via Crossbar; i.e. the
parent interrupt controller of Crossbar is the GIC.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Denis Obrezkov]

Hi,

On 7/10/19 9:49 PM, Stefano Stabellini wrote:

> 
>   phandle = <0x00000002>;
> 
> I think that means that interrupts go to the GIC via Crossbar; i.e. the
> parent interrupt controller of Crossbar is the GIC.
> 
But the crossbar's interrupt-parent node is 0x00000008 and phandle value
0x00000008 belongs to
interrupt-controller@48281000 {
		compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";

For me it looks like interrupts from crossbar goes to wugen and the from
wugen to GIC. But I don't quite understand it.
-- 
Regards, Denis Obrezkov

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Stefano Stabellini]

On Wed, 10 Jul 2019, Denis Obrezkov wrote:
> Hi,
> 
> On 7/10/19 9:49 PM, Stefano Stabellini wrote:
> 
> > 
> >   phandle = <0x00000002>;
> > 
> > I think that means that interrupts go to the GIC via Crossbar; i.e. the
> > parent interrupt controller of Crossbar is the GIC.
> > 
> But the crossbar's interrupt-parent node is 0x00000008 and phandle value
> 0x00000008 belongs to
> interrupt-controller@48281000 {
> 		compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
> 
> For me it looks like interrupts from crossbar goes to wugen and the from
> wugen to GIC. But I don't quite understand it.

Hi Denis,

I only read your email and got a partial picture. I read the full device
tree now and the hierarchy is as follow:

- crossbar routes to phandle 8
- phandle 8 is omap5-wugen-mpu and routes to phandle 2
- phandle 2 is the GIC

So:

crossbar -> omap5-wugen-mpu -> GIC

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Denis Obrezkov]

Hi,

On 7/10/19 10:17 PM, Stefano Stabellini wrote:
> On Wed, 10 Jul 2019, Denis Obrezkov wrote:
>> Hi,
>>
>> On 7/10/19 9:49 PM, Stefano Stabellini wrote:
>>
>>>
>>>   phandle = <0x00000002>;
>>>
>>> I think that means that interrupts go to the GIC via Crossbar; i.e. the
>>> parent interrupt controller of Crossbar is the GIC.
>>>
>> But the crossbar's interrupt-parent node is 0x00000008 and phandle value
>> 0x00000008 belongs to
>> interrupt-controller@48281000 {
>> 		compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
>>
>> For me it looks like interrupts from crossbar goes to wugen and the from
>> wugen to GIC. But I don't quite understand it.
> 
> Hi Denis,
> 
> I only read your email and got a partial picture. I read the full device
> tree now and the hierarchy is as follow:
> 
> - crossbar routes to phandle 8
> - phandle 8 is omap5-wugen-mpu and routes to phandle 2
> - phandle 2 is the GIC
> 
> So:
> 
> crossbar -> omap5-wugen-mpu -> GIC
> 
I am interested whether we should do something with omap5-wugen-mpu. I
found that crossbar is connected to GIC. And on some schemes in trm it
is connected via omap5-wugen-mpu. So, it is not clear for me whether it
should be handled in xen.
-- 
Regards, Denis Obrezkov

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Hunyue Yau]

Denis,

Not sure if you gone through this - the interrupt routing is described in the 
TRM chapter on interrupt controllers. In my edition (large file, don't want to 
redownload unless needed.), this is chapter 17. Table 17-2 (in my edition)  
should address a lot of what you are asking. It shows the IRQ Input line (aka 
GIC ID number), the IRQ cross bar instance along with the config register and 
some description. Figure 17-1 shows the the layout. 

From what I can tell, the cross bar is so the interrupt can be sent to the 
other processor on the die besides the cortex-a (aka MPU in the TRM). Mapping 
the TRM names to DT names might still be bit of work but this should give you 
an idea what to look for in the Linux kernel to backout the names used.


On Wednesday, July 10, 2019 22:43:37 Denis Obrezkov wrote:
> Hi,
> 
> On 7/10/19 10:17 PM, Stefano Stabellini wrote:
> > On Wed, 10 Jul 2019, Denis Obrezkov wrote:
> >> Hi,
> >> 
> >> On 7/10/19 9:49 PM, Stefano Stabellini wrote:
> >>>   phandle = <0x00000002>;
> >>> 
> >>> I think that means that interrupts go to the GIC via Crossbar; i.e. the
> >>> parent interrupt controller of Crossbar is the GIC.
> >> 
> >> But the crossbar's interrupt-parent node is 0x00000008 and phandle value
> >> 0x00000008 belongs to
> >> interrupt-controller@48281000 {
> >> 
> >> 		compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
> >> 
> >> For me it looks like interrupts from crossbar goes to wugen and the from
> >> wugen to GIC. But I don't quite understand it.
> > 
> > Hi Denis,
> > 
> > I only read your email and got a partial picture. I read the full device
> > tree now and the hierarchy is as follow:
> > 
> > - crossbar routes to phandle 8
> > - phandle 8 is omap5-wugen-mpu and routes to phandle 2
> > - phandle 2 is the GIC
> > 
> > So:
> > 
> > crossbar -> omap5-wugen-mpu -> GIC
> 
> I am interested whether we should do something with omap5-wugen-mpu. I
> found that crossbar is connected to GIC. And on some schemes in trm it
> is connected via omap5-wugen-mpu. So, it is not clear for me whether it
> should be handled in xen.

-- 
Hunyue Yau
http://www.hy-research.com/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Denis Obrezkov]

Hi,

>>
>> I am interested whether we should do something with omap5-wugen-mpu. I
>> found that crossbar is connected to GIC. And on some schemes in trm it
>> is connected via omap5-wugen-mpu. So, it is not clear for me whether it
>> should be handled in xen.
> 

Also, I am interested in how to add the crossbar. I can see two options
as we discussed earlier. The first option is to remove the crossbar but
for me it might cause some problems since a guest might want to use it.
The second option is to expose the crossbar and intercept all the calls
to it. But the problem is that now xen supports only one
interrupt-controller. And at the same time most of the SPI IRQs are
mapped to the crossbar. So, when xen checks whether the main
interrupt-controller is the same as the one to who external interrupts
are mapped it fails.
(xen/common/device_tree.c:dt_irq_translate()).
And I don't think that I should change interrupt-parent option of
devices to map them to the GIC because it is essentially the first
option mentioned above. So, it seems that probably interrupt-parent
finding decision logic should be changed a bit? Like to find a GIC node
not in a direct interrupt-parent but transitively in one of ancestors:

UART -> crossbar -> wugen -> GIC

What do you think?

-- 
Regards, Denis Obrezkov

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Julien Grall]

On 7/11/19 1:50 PM, Denis Obrezkov wrote:
> Hi,

Hi,

>>>
>>> I am interested whether we should do something with omap5-wugen-mpu. I
>>> found that crossbar is connected to GIC. And on some schemes in trm it
>>> is connected via omap5-wugen-mpu. So, it is not clear for me whether it
>>> should be handled in xen.

I don't know much about omap5-wugen-mpu, so I will leave Hunyue and Iain 
to provide feedback here.


>>
> 
> Also, I am interested in how to add the crossbar. I can see two options
> as we discussed earlier. The first option is to remove the crossbar but
> for me it might cause some problems since a guest might want to use it.
> The second option is to expose the crossbar and intercept all the calls
> to it. But the problem is that now xen supports only one
> interrupt-controller. And at the same time most of the SPI IRQs are
> mapped to the crossbar. So, when xen checks whether the main
> interrupt-controller is the same as the one to who external interrupts
> are mapped it fails.
> (xen/common/device_tree.c:dt_irq_translate()).
> And I don't think that I should change interrupt-parent option of
> devices to map them to the GIC because it is essentially the first
> option mentioned above. So, it seems that probably interrupt-parent
> finding decision logic should be changed a bit? Like to find a GIC node
> not in a direct interrupt-parent but transitively in one of ancestors:
> 
> UART -> crossbar -> wugen -> GIC
> 
> What do you think?

Have you looked at the series I pointed out earlier on? It extends Xen 
to support other interrupt controller parent.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Hunyue Yau]

[This mail incorporates comments raised on IRC. I have made some of this more 
verbose to provide context to people that haven't seen the IRC comments.]

This will be a bunch of facts on the am5. Someone else will have relate it 
back to Xen.

1 - The WUGen is a hardware block on the MPU block that can turn interrupts 
into wake up events if the MPU is in certain deeper sleep states. This applies 
only to certain interrupts. We can confirm this by looking at the DT's register 
address. Per the TRM, they are registers for the MPU's PRCM (Power/Reset/Clock 
Management). In short, this block makes interrupts a possible wake up source. 

2 - Earlier kernels did not expose that HW block. See this patch that 
introduced the WUGen - 
https://github.com/torvalds/linux/commit/7136d457f365ecc93ddffcdd42ab49a8473f260b
I suspect looking at the before part of the patch should provide clues on how 
to handle the WUGen.


3 - This may be redundant but more definitions (in the human sense) here: 
https://www.mjmwired.net/kernel/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu

4 - For the UART case, I suspect the flow Dennis pointed out is about right. 
However, that may be different depending on the interrupt source.

Unknowns from my point of view - 

a - Does Xen virtualize power management? If so, this may have have an impact. 
I would not recommend adding PM virtualization in GSoC. It is tugging on a 
very long string. 

b - If Xen does not virtualize that, someone needs to decide how much to leave 
to the guess. 

c - I wonder if we can do a half way hack where the kernel sets up the PM but 
Xen hooks to get the interrupt. The HW will do its PM thing and Xen can 
process the interrupt.

Guesses/possible hacks -
- For the interrupts we care about, the cross bar can route things to the MPU 
unconditionally. This would break the other HW blocks but most of them aren't 
needed for boot.

On Thursday, July 11, 2019 18:32:22 Julien Grall wrote:
> On 7/11/19 1:50 PM, Denis Obrezkov wrote:
> > Hi,
> 
> Hi,
> 
> >>> I am interested whether we should do something with omap5-wugen-mpu. I
> >>> found that crossbar is connected to GIC. And on some schemes in trm it
> >>> is connected via omap5-wugen-mpu. So, it is not clear for me whether it
> >>> should be handled in xen.
> 
> I don't know much about omap5-wugen-mpu, so I will leave Hunyue and Iain
> to provide feedback here.
> 
> > Also, I am interested in how to add the crossbar. I can see two options
> > as we discussed earlier. The first option is to remove the crossbar but
> > for me it might cause some problems since a guest might want to use it.
> > The second option is to expose the crossbar and intercept all the calls
> > to it. But the problem is that now xen supports only one
> > interrupt-controller. And at the same time most of the SPI IRQs are
> > mapped to the crossbar. So, when xen checks whether the main
> > interrupt-controller is the same as the one to who external interrupts
> > are mapped it fails.
> > (xen/common/device_tree.c:dt_irq_translate()).
> > And I don't think that I should change interrupt-parent option of
> > devices to map them to the GIC because it is essentially the first
> > option mentioned above. So, it seems that probably interrupt-parent
> > finding decision logic should be changed a bit? Like to find a GIC node
> > not in a direct interrupt-parent but transitively in one of ancestors:
> > 
> > UART -> crossbar -> wugen -> GIC
> > 
> > What do you think?
> 
> Have you looked at the series I pointed out earlier on? It extends Xen
> to support other interrupt controller parent.
> 
> Cheers,

-- 
Hunyue Yau
http://www.hy-research.com/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Denis Obrezkov]

Hi,

On 7/11/19 7:32 PM, Julien Grall wrote:

>>
>> What do you think?
> 
> Have you looked at the series I pointed out earlier on? It extends Xen
> to support other interrupt controller parent.
> 
Yes, but you said once that these patch series wasn't accepted because
maintainers didn't like something. So, I wanted to understand whether
this approach is acceptable.

-- 
Regards, Denis Obrezkov

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Julien Grall]

On 7/11/19 7:29 PM, Denis Obrezkov wrote:
> Hi,

Hi,

> On 7/11/19 7:32 PM, Julien Grall wrote:
> 
>>>
>>> What do you think?
>>
>> Have you looked at the series I pointed out earlier on? It extends Xen
>> to support other interrupt controller parent.
>>
> Yes, but you said once that these patch series wasn't accepted because
> maintainers didn't like something. So, I wanted to understand whether
> this approach is acceptable.

The series was reviewed publicly. Looking through the series, I don't 
think major concern on the approach suggested.

How about you have a try at the series and see how far you can go? We 
can discuss about improvement once you have the crossbar up and running.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Julien Grall]

Hi,

On 7/11/19 7:29 PM, Hunyue Yau wrote:
> [This mail incorporates comments raised on IRC. I have made some of this mHi,ore
> verbose to provide context to people that haven't seen the IRC comments.]

Thank you for the summary!

> 
> This will be a bunch of facts on the am5. Someone else will have relate it
> back to Xen.
> 
> 1 - The WUGen is a hardware block on the MPU block that can turn interrupts
> into wake up events if the MPU is in certain deeper sleep states. This applies
> only to certain interrupts. We can confirm this by looking at the DT's register
> address. Per the TRM, they are registers for the MPU's PRCM (Power/Reset/Clock
> Management). In short, this block makes interrupts a possible wake up source.
> 
> 2 - Earlier kernels did not expose that HW block. See this patch that
> introduced the WUGen -
> https://github.com/torvalds/linux/commit/7136d457f365ecc93ddffcdd42ab49a8473f260b
> I suspect looking at the before part of the patch should provide clues on how
> to handle the WUGen.
> 
> 
> 3 - This may be redundant but more definitions (in the human sense) here:
> https://www.mjmwired.net/kernel/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
> 
> 4 - For the UART case, I suspect the flow Dennis pointed out is about right.
> However, that may be different depending on the interrupt source.
> 
> Unknowns from my point of view -
> 
> a - Does Xen virtualize power management? If so, this may have have an impact.
> I would not recommend adding PM virtualization in GSoC. It is tugging on a
> very long string.

Xen does not virtualize power management at the moment. I agree that 
this is too big for the scope of the GSoC.

> 
> b - If Xen does not virtualize that, someone needs to decide how much to leave
> to the guess.
> 
> c - I wonder if we can do a half way hack where the kernel sets up the PM but
> Xen hooks to get the interrupt. The HW will do its PM thing and Xen can
> process the interrupt.

Hmmm, the question here is whether the UART would be usuable before Dom0 
is setting up the PM? If not, then, we would need to deal with it in Xen.

> 
> Guesses/possible hacks -
> - For the interrupts we care about, the cross bar can route things to the MPU
> unconditionally. This would break the other HW blocks but most of them aren't
> needed for boot.

Sorry for my ignorance, which HW blocks are you talking about?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Hunyue Yau z]

On Friday, July 12, 2019 16:13:32 Julien Grall wrote:
> Hi,
> 
> On 7/11/19 7:29 PM, Hunyue Yau wrote:
> > [This mail incorporates comments raised on IRC. I have made some of this
> > mHi,ore verbose to provide context to people that haven't seen the IRC
> > comments.]
> Thank you for the summary!
> 
> > This will be a bunch of facts on the am5. Someone else will have relate it
> > back to Xen.
> > 
> > 1 - The WUGen is a hardware block on the MPU block that can turn
> > interrupts
> > into wake up events if the MPU is in certain deeper sleep states. This
> > applies only to certain interrupts. We can confirm this by looking at the
> > DT's register address. Per the TRM, they are registers for the MPU's PRCM
> > (Power/Reset/Clock Management). In short, this block makes interrupts a
> > possible wake up source.
> > 
> > 2 - Earlier kernels did not expose that HW block. See this patch that
> > introduced the WUGen -
> > https://github.com/torvalds/linux/commit/7136d457f365ecc93ddffcdd42ab49a84
> > 73f260b I suspect looking at the before part of the patch should provide
> > clues on how to handle the WUGen.
> > 
> > 
> > 3 - This may be redundant but more definitions (in the human sense) here:
> > https://www.mjmwired.net/kernel/Documentation/devicetree/bindings/interrup
> > t-controller/ti,omap4-wugen-mpu
> > 
> > 4 - For the UART case, I suspect the flow Dennis pointed out is about
> > right. However, that may be different depending on the interrupt source.
> > 
> > Unknowns from my point of view -
> > 
> > a - Does Xen virtualize power management? If so, this may have have an
> > impact. I would not recommend adding PM virtualization in GSoC. It is
> > tugging on a very long string.
> 
> Xen does not virtualize power management at the moment. I agree that
> this is too big for the scope of the GSoC.
> 
> > b - If Xen does not virtualize that, someone needs to decide how much to
> > leave to the guess.
> > 
> > c - I wonder if we can do a half way hack where the kernel sets up the PM
> > but Xen hooks to get the interrupt. The HW will do its PM thing and Xen
> > can process the interrupt.
> 
> Hmmm, the question here is whether the UART would be usuable before Dom0
> is setting up the PM? If not, then, we would need to deal with it in Xen.
> 
> > Guesses/possible hacks -
> > - For the interrupts we care about, the cross bar can route things to the
> > MPU unconditionally. This would break the other HW blocks but most of
> > them aren't needed for boot.
> 
> Sorry for my ignorance, which HW blocks are you talking about?

The HW blocks I am referring to are stuff like EVE, IPU, and DSP. Initially, we 
can even ignore the PRUSS. This should leave just sending interrupts to the 
MPU. As I understand it, there is no current support for those right now 
anyways. I think EVE/IPU/DSP require a working cmem driver which is not fully 
upstreamed. BBAI does use them but that requires a specific kernel.

PRUSS would be nice (aka the PRU stuff) eventually as the bits are upstream but 
not critical for now.

> 
> Cheers,

-- 
Hunyue Yau
http://www.hy-research.com/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Julien Grall]

Hi,

On 12/07/2019 19:32, Hunyue Yau z wrote:
> On Friday, July 12, 2019 16:13:32 Julien Grall wrote:
>> Hi,
>>
>> On 7/11/19 7:29 PM, Hunyue Yau wrote:
>>> [This mail incorporates comments raised on IRC. I have made some of this
>>> mHi,ore verbose to provide context to people that haven't seen the IRC
>>> comments.]
>> Thank you for the summary!
>>
>>> This will be a bunch of facts on the am5. Someone else will have relate it
>>> back to Xen.
>>>
>>> 1 - The WUGen is a hardware block on the MPU block that can turn
>>> interrupts
>>> into wake up events if the MPU is in certain deeper sleep states. This
>>> applies only to certain interrupts. We can confirm this by looking at the
>>> DT's register address. Per the TRM, they are registers for the MPU's PRCM
>>> (Power/Reset/Clock Management). In short, this block makes interrupts a
>>> possible wake up source.
>>>
>>> 2 - Earlier kernels did not expose that HW block. See this patch that
>>> introduced the WUGen -
>>> https://github.com/torvalds/linux/commit/7136d457f365ecc93ddffcdd42ab49a84
>>> 73f260b I suspect looking at the before part of the patch should provide
>>> clues on how to handle the WUGen.
>>>
>>>
>>> 3 - This may be redundant but more definitions (in the human sense) here:
>>> https://www.mjmwired.net/kernel/Documentation/devicetree/bindings/interrup
>>> t-controller/ti,omap4-wugen-mpu
>>>
>>> 4 - For the UART case, I suspect the flow Dennis pointed out is about
>>> right. However, that may be different depending on the interrupt source.
>>>
>>> Unknowns from my point of view -
>>>
>>> a - Does Xen virtualize power management? If so, this may have have an
>>> impact. I would not recommend adding PM virtualization in GSoC. It is
>>> tugging on a very long string.
>>
>> Xen does not virtualize power management at the moment. I agree that
>> this is too big for the scope of the GSoC.
>>
>>> b - If Xen does not virtualize that, someone needs to decide how much to
>>> leave to the guess.
>>>
>>> c - I wonder if we can do a half way hack where the kernel sets up the PM
>>> but Xen hooks to get the interrupt. The HW will do its PM thing and Xen
>>> can process the interrupt.
>>
>> Hmmm, the question here is whether the UART would be usuable before Dom0
>> is setting up the PM? If not, then, we would need to deal with it in Xen.
>>
>>> Guesses/possible hacks -
>>> - For the interrupts we care about, the cross bar can route things to the
>>> MPU unconditionally. This would break the other HW blocks but most of
>>> them aren't needed for boot.
>>
>> Sorry for my ignorance, which HW blocks are you talking about?
> 
> The HW blocks I am referring to are stuff like EVE, IPU, and DSP. Initially, we
> can even ignore the PRUSS. This should leave just sending interrupts to the
> MPU. As I understand it, there is no current support for those right now
> anyways. I think EVE/IPU/DSP require a working cmem driver which is not fully
> upstreamed. BBAI does use them but that requires a specific kernel.
> 
> PRUSS would be nice (aka the PRU stuff) eventually as the bits are upstream but
> not critical for now.

Thank you for the clarification. My knowledge on the board is limited, so I will 
take yours comments as granted :).

Cheers,

> 
>>
>> Cheers,
> 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel