* [Xen-devel] [GSoC-2019] About the crossbar and xen
@ 2019-07-10 18:54 Denis Obrezkov
2019-07-10 19:49 ` Stefano Stabellini
0 siblings, 1 reply; 14+ messages in thread
From: Denis Obrezkov @ 2019-07-10 18:54 UTC (permalink / raw)
To: xen-devel, Iain Hunter, Stefano Stabellini, Julien Grall, Hunyue Yau
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
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-10 18:54 [Xen-devel] [GSoC-2019] About the crossbar and xen Denis Obrezkov @ 2019-07-10 19:49 ` Stefano Stabellini 2019-07-10 19:54 ` Denis Obrezkov 0 siblings, 1 reply; 14+ messages in thread From: Stefano Stabellini @ 2019-07-10 19:49 UTC (permalink / raw) To: Denis Obrezkov Cc: xen-devel, Julien Grall, Stefano Stabellini, Hunyue Yau, Iain Hunter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-10 19:49 ` Stefano Stabellini @ 2019-07-10 19:54 ` Denis Obrezkov 2019-07-10 20:17 ` Stefano Stabellini 0 siblings, 1 reply; 14+ messages in thread From: Denis Obrezkov @ 2019-07-10 19:54 UTC (permalink / raw) To: Stefano Stabellini; +Cc: xen-devel, Julien Grall, Hunyue Yau, Iain Hunter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-10 19:54 ` Denis Obrezkov @ 2019-07-10 20:17 ` Stefano Stabellini 2019-07-10 20:43 ` Denis Obrezkov 0 siblings, 1 reply; 14+ messages in thread From: Stefano Stabellini @ 2019-07-10 20:17 UTC (permalink / raw) To: Denis Obrezkov Cc: xen-devel, Julien Grall, Stefano Stabellini, Hunyue Yau, Iain Hunter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-10 20:17 ` Stefano Stabellini @ 2019-07-10 20:43 ` Denis Obrezkov 2019-07-10 23:20 ` Hunyue Yau 0 siblings, 1 reply; 14+ messages in thread From: Denis Obrezkov @ 2019-07-10 20:43 UTC (permalink / raw) To: Stefano Stabellini; +Cc: xen-devel, Julien Grall, Hunyue Yau, Iain Hunter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-10 20:43 ` Denis Obrezkov @ 2019-07-10 23:20 ` Hunyue Yau 2019-07-11 12:50 ` Denis Obrezkov 0 siblings, 1 reply; 14+ messages in thread From: Hunyue Yau @ 2019-07-10 23:20 UTC (permalink / raw) To: Denis Obrezkov; +Cc: xen-devel, Julien Grall, Stefano Stabellini, Iain Hunter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-10 23:20 ` Hunyue Yau @ 2019-07-11 12:50 ` Denis Obrezkov 2019-07-11 17:32 ` Julien Grall 0 siblings, 1 reply; 14+ messages in thread From: Denis Obrezkov @ 2019-07-11 12:50 UTC (permalink / raw) To: Hunyue Yau; +Cc: xen-devel, Julien Grall, Stefano Stabellini, Iain Hunter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-11 12:50 ` Denis Obrezkov @ 2019-07-11 17:32 ` Julien Grall 2019-07-11 18:29 ` Hunyue Yau 2019-07-11 18:29 ` Denis Obrezkov 0 siblings, 2 replies; 14+ messages in thread From: Julien Grall @ 2019-07-11 17:32 UTC (permalink / raw) To: Denis Obrezkov, Hunyue Yau; +Cc: xen-devel, Stefano Stabellini, Iain Hunter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-11 17:32 ` Julien Grall @ 2019-07-11 18:29 ` Hunyue Yau 2019-07-12 15:13 ` Julien Grall 2019-07-11 18:29 ` Denis Obrezkov 1 sibling, 1 reply; 14+ messages in thread From: Hunyue Yau @ 2019-07-11 18:29 UTC (permalink / raw) To: Julien Grall, Stefano Stabellini; +Cc: xen-devel, Iain Hunter, Denis Obrezkov [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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-11 18:29 ` Hunyue Yau @ 2019-07-12 15:13 ` Julien Grall 2019-07-12 18:32 ` Hunyue Yau z 0 siblings, 1 reply; 14+ messages in thread From: Julien Grall @ 2019-07-12 15:13 UTC (permalink / raw) To: Hunyue Yau, Stefano Stabellini; +Cc: xen-devel, Denis Obrezkov, Iain Hunter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-12 15:13 ` Julien Grall @ 2019-07-12 18:32 ` Hunyue Yau z 2019-07-15 11:36 ` Julien Grall 0 siblings, 1 reply; 14+ messages in thread From: Hunyue Yau z @ 2019-07-12 18:32 UTC (permalink / raw) To: Julien Grall, Stefano Stabellini; +Cc: xen-devel, Denis Obrezkov, Iain Hunter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-12 18:32 ` Hunyue Yau z @ 2019-07-15 11:36 ` Julien Grall 0 siblings, 0 replies; 14+ messages in thread From: Julien Grall @ 2019-07-15 11:36 UTC (permalink / raw) To: Hunyue Yau z, Stefano Stabellini; +Cc: xen-devel, Iain Hunter, Denis Obrezkov 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-11 17:32 ` Julien Grall 2019-07-11 18:29 ` Hunyue Yau @ 2019-07-11 18:29 ` Denis Obrezkov 2019-07-12 15:00 ` Julien Grall 1 sibling, 1 reply; 14+ messages in thread From: Denis Obrezkov @ 2019-07-11 18:29 UTC (permalink / raw) To: Julien Grall, Hunyue Yau; +Cc: xen-devel, Stefano Stabellini, Iain Hunter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xen-devel] [GSoC-2019] About the crossbar and xen 2019-07-11 18:29 ` Denis Obrezkov @ 2019-07-12 15:00 ` Julien Grall 0 siblings, 0 replies; 14+ messages in thread From: Julien Grall @ 2019-07-12 15:00 UTC (permalink / raw) To: Denis Obrezkov, Hunyue Yau; +Cc: xen-devel, Stefano Stabellini, Iain Hunter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-07-15 11:36 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-10 18:54 [Xen-devel] [GSoC-2019] About the crossbar and xen Denis Obrezkov 2019-07-10 19:49 ` Stefano Stabellini 2019-07-10 19:54 ` Denis Obrezkov 2019-07-10 20:17 ` Stefano Stabellini 2019-07-10 20:43 ` Denis Obrezkov 2019-07-10 23:20 ` Hunyue Yau 2019-07-11 12:50 ` Denis Obrezkov 2019-07-11 17:32 ` Julien Grall 2019-07-11 18:29 ` Hunyue Yau 2019-07-12 15:13 ` Julien Grall 2019-07-12 18:32 ` Hunyue Yau z 2019-07-15 11:36 ` Julien Grall 2019-07-11 18:29 ` Denis Obrezkov 2019-07-12 15:00 ` Julien Grall
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.