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

[Hunyue Yau z <hy-gsoc@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel