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

[Julien Grall <julien.grall@arm.com>]

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