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

[Julien Grall <julien.grall@xxxxxxx>]

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