Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Julien Grall]

Hi Chris,

On 07/07/17 19:08, Chris Patterson wrote:

On Fri, Jul 7, 2017 at 12:25 PM, Julien Grall  wrote:

Hi Chris,


On 06/07/17 23:00, Chris Patterson wrote:


The purpose of tegra_interrupt_compat is to maintain a tegra-specific
whitelist of interrupt controllers we know how to route.  Presumably,
there may be custom boards out there that may have additional
interrupt routing capabilities that this patch set would not support
as-is.  I'm not sure of an appropriate way to maintain that logic and
merge them.  However, I am certainly open to suggestion, if you have
any ideas.




Those custom boards would likely have a different machine compatible
string
because the SOC would be different. So I think the tegra_interrupt_compat
is
not necessary.



Sorry about the delayed response...

This check effectively filters out GPIO controllers.  Any GPIO-sourced
interrupts route through the GPIO controller's interrupt, and need not
apply for map_irq_to_domain().  Devices requiring GPIO-based
interrupts would need to be passed through with the associated
controller (or maybe virtualize the GPIO routing?).



I am a bit confused. Could you give a concrete example based on tegra
platform?



I'm thinking of devices where interrupt-parent is  (as opposed to
 or ). Here is an example on tegra-smaug:

wifi: wifi_bcm4354 {
compatible = "bcm,bcm4354";
interrupt-parent = <>;
interrupts = ;
wl_reg_on = < TEGRA_GPIO(H, 1) GPIO_ACTIVE_HIGH>;
wl_host_wake = < TEGRA_GPIO(H, 2) IRQ_TYPE_LEVEL_HIGH>;
nvidia,pmc-wakeup = <
PMC_WAKE_TYPE_EVENT 8 PMC_TRIGGER_TYPE_HIGH>;
};



Hmmm, you are right here. What confuse me is the comment on the top of 
tegra_irq_is_routable:


/*
 * Returns true iff the given IRQ is routable -- that is, if it i descended
 * from the platform's primary GIC.
 */

In both GPIO and LIC, the final interrupt will be coming from the GIC.
However, the later seems to have a direct translation with the GIC, 
hence why they are routable. Right?


If so I would update the comment to make it clear.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Julien Grall]

Hi Chris,

Sorry for the late reply.

On 24/07/17 20:38, Chris Patterson wrote:

On Fri, Jul 7, 2017 at 2:53 PM, Chris Patterson  wrote:

On Fri, Jul 7, 2017 at 12:30 PM, Julien Grall  wrote:

Hi Chris,

On 07/07/17 00:12, Chris Patterson wrote:



So why do you want the hardware domain to interact with the ictlr? Could
not
you hide it completely?



snip


What would happen if you enable the interrupt here for the guest? Should
not
you do it when the guest is requesting to enable (see vgic_enable_irqs).


Also, how about EOI an interrupt?



We could possibly hide the legacy controller, but that has its own
challenges. Notably, the LIC allows configuration for forwarding FIQ
vs IRQ, and setting wake-up sources.



FIQ are not supported for domain. So I am not sure why you would want a
guest to configure that.



Fair point, I did not know that and didn't want to assume there was
not a case otherwise...


Furthermore, could you explain what is wake-up sources and why a guest would
need it?



I would expect any driver using irq_set_irq_wake()? A little more
background from the reference manual
(http://developer.nvidia.com/embedded/dlc/tegra-x1-technical-reference-manual):

"
The Legacy Interrupt Controller (LIC) is primarily used for BPMP
(ARM7). But it is also used for generating interrupts as wake
events for CPUs. This is an important use case when the core is in
retention. All of the device hardware interrupt signals are
sent to the LIC first, which routes them to the ARM7 BPMP-Lite as well
as forwards them to the GIC. The LIC also provides a
software set/clear mechanism for all of the interrupts."

...

3.3.1.5 Interrupt Blocking to Support Retention

The Tegra X1 device implements blocking of interrupts routed to the
GIC, which supports the CPU retention state. The block
implementing this feature is represented in Figure 4 as Blocking.

To support retention, the LIC contains a one shot disable for all the
interrupts. When the system goes into retention, BPMP
software sets this bit to disable the interrupts.

The Flow Controller watches all the interrupts triggered and triggers
the BPMP to bring the core out of retention when any
interrupt bit is asserted. Once the system is out of retention, the
BLOCK _CCPLEX_GIC_INTR bit is cleared, and the interrupt is
serviced by the GIC.
"

Anything using GPIO to wake (e.g. wifi?) is routed through the LIC. I
did not find anything obvious with a quick scan, but perhaps other
devices directly wired to the LIC may require it as well.

Thoughts?


I have the feeling it is a lot emulation for supporting only wake-up 
sources in the guest (or even Dom0). Have you thought about 
para-virtualizing it?


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Chris Patterson]

On Fri, Jul 7, 2017 at 2:53 PM, Chris Patterson  wrote:
> On Fri, Jul 7, 2017 at 12:30 PM, Julien Grall  wrote:
>> Hi Chris,
>>
>> On 07/07/17 00:12, Chris Patterson wrote:


 So why do you want the hardware domain to interact with the ictlr? Could
 not
 you hide it completely?

>>>
>>> snip
>>>
 What would happen if you enable the interrupt here for the guest? Should
 not
 you do it when the guest is requesting to enable (see vgic_enable_irqs).


 Also, how about EOI an interrupt?
>>>
>>>
>>> We could possibly hide the legacy controller, but that has its own
>>> challenges. Notably, the LIC allows configuration for forwarding FIQ
>>> vs IRQ, and setting wake-up sources.
>>
>>
>> FIQ are not supported for domain. So I am not sure why you would want a
>> guest to configure that.
>>
>
> Fair point, I did not know that and didn't want to assume there was
> not a case otherwise...
>
>> Furthermore, could you explain what is wake-up sources and why a guest would
>> need it?
>>
>
> I would expect any driver using irq_set_irq_wake()? A little more
> background from the reference manual
> (http://developer.nvidia.com/embedded/dlc/tegra-x1-technical-reference-manual):
>
> "
> The Legacy Interrupt Controller (LIC) is primarily used for BPMP
> (ARM7). But it is also used for generating interrupts as wake
> events for CPUs. This is an important use case when the core is in
> retention. All of the device hardware interrupt signals are
> sent to the LIC first, which routes them to the ARM7 BPMP-Lite as well
> as forwards them to the GIC. The LIC also provides a
> software set/clear mechanism for all of the interrupts."
>
> ...
>
> 3.3.1.5 Interrupt Blocking to Support Retention
>
> The Tegra X1 device implements blocking of interrupts routed to the
> GIC, which supports the CPU retention state. The block
> implementing this feature is represented in Figure 4 as Blocking.
>
> To support retention, the LIC contains a one shot disable for all the
> interrupts. When the system goes into retention, BPMP
> software sets this bit to disable the interrupts.
>
> The Flow Controller watches all the interrupts triggered and triggers
> the BPMP to bring the core out of retention when any
> interrupt bit is asserted. Once the system is out of retention, the
> BLOCK _CCPLEX_GIC_INTR bit is cleared, and the interrupt is
> serviced by the GIC.
> "
>
> Anything using GPIO to wake (e.g. wifi?) is routed through the LIC. I
> did not find anything obvious with a quick scan, but perhaps other
> devices directly wired to the LIC may require it as well.
>
> Thoughts?

Hey Julien. Just a quick ping. I was going to submit an updated patch
series, just wanted to see if you had any further thoughts or desired
changes with regards to the above. Thanks!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Chris Patterson]

On Fri, Jul 7, 2017 at 12:30 PM, Julien Grall  wrote:
> Hi Chris,
>
> On 07/07/17 00:12, Chris Patterson wrote:
>>>
>>>
>>> So why do you want the hardware domain to interact with the ictlr? Could
>>> not
>>> you hide it completely?
>>>
>>
>> snip
>>
>>> What would happen if you enable the interrupt here for the guest? Should
>>> not
>>> you do it when the guest is requesting to enable (see vgic_enable_irqs).
>>>
>>>
>>> Also, how about EOI an interrupt?
>>
>>
>> We could possibly hide the legacy controller, but that has its own
>> challenges. Notably, the LIC allows configuration for forwarding FIQ
>> vs IRQ, and setting wake-up sources.
>
>
> FIQ are not supported for domain. So I am not sure why you would want a
> guest to configure that.
>

Fair point, I did not know that and didn't want to assume there was
not a case otherwise...

> Furthermore, could you explain what is wake-up sources and why a guest would
> need it?
>

I would expect any driver using irq_set_irq_wake()? A little more
background from the reference manual
(http://developer.nvidia.com/embedded/dlc/tegra-x1-technical-reference-manual):

"
The Legacy Interrupt Controller (LIC) is primarily used for BPMP
(ARM7). But it is also used for generating interrupts as wake
events for CPUs. This is an important use case when the core is in
retention. All of the device hardware interrupt signals are
sent to the LIC first, which routes them to the ARM7 BPMP-Lite as well
as forwards them to the GIC. The LIC also provides a
software set/clear mechanism for all of the interrupts."

...

3.3.1.5 Interrupt Blocking to Support Retention

The Tegra X1 device implements blocking of interrupts routed to the
GIC, which supports the CPU retention state. The block
implementing this feature is represented in Figure 4 as Blocking.

To support retention, the LIC contains a one shot disable for all the
interrupts. When the system goes into retention, BPMP
software sets this bit to disable the interrupts.

The Flow Controller watches all the interrupts triggered and triggers
the BPMP to bring the core out of retention when any
interrupt bit is asserted. Once the system is out of retention, the
BLOCK _CCPLEX_GIC_INTR bit is cleared, and the interrupt is
serviced by the GIC.
"

Anything using GPIO to wake (e.g. wifi?) is routed through the LIC. I
did not find anything obvious with a quick scan, but perhaps other
devices directly wired to the LIC may require it as well.

Thoughts?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Chris Patterson]

On Fri, Jul 7, 2017 at 12:25 PM, Julien Grall  wrote:
> Hi Chris,
>
>
> On 06/07/17 23:00, Chris Patterson wrote:

 The purpose of tegra_interrupt_compat is to maintain a tegra-specific
 whitelist of interrupt controllers we know how to route.  Presumably,
 there may be custom boards out there that may have additional
 interrupt routing capabilities that this patch set would not support
 as-is.  I'm not sure of an appropriate way to maintain that logic and
 merge them.  However, I am certainly open to suggestion, if you have
 any ideas.
>>>
>>>
>>>
>>> Those custom boards would likely have a different machine compatible
>>> string
>>> because the SOC would be different. So I think the tegra_interrupt_compat
>>> is
>>> not necessary.
>>>
>>
>> Sorry about the delayed response...
>>
>> This check effectively filters out GPIO controllers.  Any GPIO-sourced
>> interrupts route through the GPIO controller's interrupt, and need not
>> apply for map_irq_to_domain().  Devices requiring GPIO-based
>> interrupts would need to be passed through with the associated
>> controller (or maybe virtualize the GPIO routing?).
>
>
> I am a bit confused. Could you give a concrete example based on tegra
> platform?
>

I'm thinking of devices where interrupt-parent is  (as opposed to
 or ). Here is an example on tegra-smaug:

wifi: wifi_bcm4354 {
compatible = "bcm,bcm4354";
interrupt-parent = <>;
interrupts = ;
wl_reg_on = < TEGRA_GPIO(H, 1) GPIO_ACTIVE_HIGH>;
wl_host_wake = < TEGRA_GPIO(H, 2) IRQ_TYPE_LEVEL_HIGH>;
nvidia,pmc-wakeup = <
PMC_WAKE_TYPE_EVENT 8 PMC_TRIGGER_TYPE_HIGH>;
};

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Julien Grall]

Hi Chris,

On 07/07/17 00:12, Chris Patterson wrote:


So why do you want the hardware domain to interact with the ictlr? Could not
you hide it completely?



snip


What would happen if you enable the interrupt here for the guest? Should not
you do it when the guest is requesting to enable (see vgic_enable_irqs).


Also, how about EOI an interrupt?


We could possibly hide the legacy controller, but that has its own
challenges. Notably, the LIC allows configuration for forwarding FIQ
vs IRQ, and setting wake-up sources.


FIQ are not supported for domain. So I am not sure why you would want a 
guest to configure that.


Furthermore, could you explain what is wake-up sources and why a guest 
would need it?




If we accept limitations to those configurations, we could possibly
hide it entirely (or just for non-Dom0 guests with device
passthrough?), and then I think we would need platform hooks for
accomplishing the masking/unmasking/eoi alongside the vgic.  If we
don't want to limit the configuration options - we would need to
surface the mediated LIC in the device trees for guests with device
pass-through.





Will incorporate rest of review into next version, thanks!



Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Julien Grall]

Hi Chris,

On 06/07/17 23:00, Chris Patterson wrote:

The purpose of tegra_interrupt_compat is to maintain a tegra-specific
whitelist of interrupt controllers we know how to route.  Presumably,
there may be custom boards out there that may have additional
interrupt routing capabilities that this patch set would not support
as-is.  I'm not sure of an appropriate way to maintain that logic and
merge them.  However, I am certainly open to suggestion, if you have
any ideas.



Those custom boards would likely have a different machine compatible string
because the SOC would be different. So I think the tegra_interrupt_compat is
not necessary.



Sorry about the delayed response...

This check effectively filters out GPIO controllers.  Any GPIO-sourced
interrupts route through the GPIO controller's interrupt, and need not
apply for map_irq_to_domain().  Devices requiring GPIO-based
interrupts would need to be passed through with the associated
controller (or maybe virtualize the GPIO routing?).


I am a bit confused. Could you give a concrete example based on tegra 
platform?


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Chris Patterson]

>
> So why do you want the hardware domain to interact with the ictlr? Could not
> you hide it completely?
>

snip

> What would happen if you enable the interrupt here for the guest? Should not
> you do it when the guest is requesting to enable (see vgic_enable_irqs).
>
>
> Also, how about EOI an interrupt?

We could possibly hide the legacy controller, but that has its own
challenges. Notably, the LIC allows configuration for forwarding FIQ
vs IRQ, and setting wake-up sources.

If we accept limitations to those configurations, we could possibly
hide it entirely (or just for non-Dom0 guests with device
passthrough?), and then I think we would need platform hooks for
accomplishing the masking/unmasking/eoi alongside the vgic.  If we
don't want to limit the configuration options - we would need to
surface the mediated LIC in the device trees for guests with device
pass-through.

>

Will incorporate rest of review into next version, thanks!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Chris Patterson]

>> The purpose of tegra_interrupt_compat is to maintain a tegra-specific
>> whitelist of interrupt controllers we know how to route.  Presumably,
>> there may be custom boards out there that may have additional
>> interrupt routing capabilities that this patch set would not support
>> as-is.  I'm not sure of an appropriate way to maintain that logic and
>> merge them.  However, I am certainly open to suggestion, if you have
>> any ideas.
>
>
> Those custom boards would likely have a different machine compatible string
> because the SOC would be different. So I think the tegra_interrupt_compat is
> not necessary.
>

Sorry about the delayed response...

This check effectively filters out GPIO controllers.  Any GPIO-sourced
interrupts route through the GPIO controller's interrupt, and need not
apply for map_irq_to_domain().  Devices requiring GPIO-based
interrupts would need to be passed through with the associated
controller (or maybe virtualize the GPIO routing?).

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Julien Grall]

Hello,

On 06/04/2017 20:47, Chris Patterson wrote:

From: "Chris Patterson" 

Tegra devices have a legacy interrupt controller (lic, or ictlr) that
must be programmed in parallel with their primary GIC. For all intents
and purposes, we treat these devices attached to this controller as
connected to the primary GIC, as it will be handling their interrupts.

This commit adds support for exposing the ictlr to the hardware domain;
but a future commit will extend this to support exposing a virtualized
version of the ictlr to the hardware domain, and to ensure that
interrupts are unmasked properly when routed to a Xen, or to a domain
other than the hardware domain.


Can you please provide a link to the public documentation (if there is 
any) about the SOC?




Authored-by: Kyle Temkin 


See my question on patch #2.


Signed-off-by: Kyle Temkin 
Signed-off-by: Chris Patterson 
---

changes since rfc:
- use bool instead of bool_t
- formatting & code style cleanup
- fix dt compat label (nvidia,tegra120 -> nvidia,tegra124) for K1
- separate mediated legacy interrupt controller into its own module
- split tegra_ictlr_set_interrupt_enable() into
  tegra_lic_set_interrupt_type_normal() and
  tegra_lic_set_interrupt_enable()
- added a couple helper functions to reduce duplicated logic
- added wrapper tegra_lic_readl and writel functions for external use (mlic)
- re-order defines in tegra.h
- cleanup tegra_init() that was previously in patch 6

---

 xen/arch/arm/platforms/Makefile   |   2 +
 xen/arch/arm/platforms/tegra.c| 313 ++
 xen/include/asm-arm/platforms/tegra.h |  54 ++
 3 files changed, 369 insertions(+)
 create mode 100644 xen/arch/arm/platforms/tegra.c
 create mode 100644 xen/include/asm-arm/platforms/tegra.h

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 49fa683..d7033d2 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -6,5 +6,7 @@ obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += rcar2.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-$(CONFIG_ARM_32) += sunxi.o
+obj-$(CONFIG_ARM_32) += tegra.o
+obj-$(CONFIG_ARM_64) += tegra.o


Please use obj-y rather duplicating the code.


 obj-$(CONFIG_ARM_64) += xgene-storm.o
 obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
diff --git a/xen/arch/arm/platforms/tegra.c b/xen/arch/arm/platforms/tegra.c
new file mode 100644
index 000..bdd9966
--- /dev/null
+++ b/xen/arch/arm/platforms/tegra.c
@@ -0,0 +1,312 @@
+/*
+ * NVIDIA Tegra specific settings
+ *
+ * Ian Campbell; Copyright (c) 2014 Citrix Systems


Ian Campbell is not mentioned in the commit message. Is he the original 
author of the code? How much did you modify?



+ * Kyle Temkin; Copyright (c) 2016 Assured Information Security, Inc.
+ * Chris Patterson; Copyright (c) 2016 Assured Information Security, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Permanent mapping to the Tegra legacy interrupt controller. */
+static void __iomem *tegra_ictlr_base;
+
+/*
+ * List of legacy interrupt controllers that can be used to route
+ * Tegra interrupts.
+ */
+static const char * const tegra_interrupt_compat[] __initconst =
+{
+"nvidia,tegra124-ictlr",  /* Tegra K1 controllers */
+"nvidia,tegra210-ictlr"   /* Tegra X1 controllers */
+};
+
+/*
+ * Returns true iff the given IRQ belongs to a supported tegra interrupt
+ * controller.
+ */
+static bool tegra_irq_belongs_to_ictlr(const struct dt_raw_irq * rirq)  {


Coding style.


+int i;
+
+for ( i = 0; i < ARRAY_SIZE(tegra_interrupt_compat); i++ ) {


Coding style.


+if ( dt_device_is_compatible(rirq->controller, 
tegra_interrupt_compat[i]) )
+return true;
+}
+
+return false;
+}
+
+/*
+ * Returns true iff the given IRQ is routable -- that is, if it is descended
+ * from the platform's primary GIC.
+ */
+static bool tegra_irq_is_routable(const struct dt_raw_irq * rirq)
+{
+/* If the IRQ connects directly to our GIC, it's trivially routable. */
+if ( rirq->controller == dt_interrupt_controller )
+return true;
+
+/*
+ * If the IRQ belongs to a legacy interrupt controller, then it's
+ * effectively owned by the GIC, and is routable.
+ */
+if ( tegra_irq_belongs_to_ictlr(rirq) )
+return true;
+
+return false;
+}
+

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Julien Grall]

Hello Chris,

On 17/04/2017 16:03, Chris Patterson wrote:

+static const char * const tegra_dt_compat[] __initconst =
+{
+"nvidia,tegra120",  /* Tegra K1 */


This is still tegra120 (not tegra124), is that intended? If so, it is
still missing from arch/arm*/boot/dts. Do you have a pointer?


It was not intended; thank you for catching it. I must have lost that
fixup somewhere along the way...


Also, do we need both tegra_dt_compat and tegra_interrupt_compat? Can we
keep only one?


The purpose of tegra_interrupt_compat is to maintain a tegra-specific
whitelist of interrupt controllers we know how to route.  Presumably,
there may be custom boards out there that may have additional
interrupt routing capabilities that this patch set would not support
as-is.  I'm not sure of an appropriate way to maintain that logic and
merge them.  However, I am certainly open to suggestion, if you have
any ideas.


Those custom boards would likely have a different machine compatible 
string because the SOC would be different. So I think the 
tegra_interrupt_compat is not necessary.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Chris Patterson]

>> +static const char * const tegra_dt_compat[] __initconst =
>> +{
>> +"nvidia,tegra120",  /* Tegra K1 */
>
> This is still tegra120 (not tegra124), is that intended? If so, it is
> still missing from arch/arm*/boot/dts. Do you have a pointer?

It was not intended; thank you for catching it. I must have lost that
fixup somewhere along the way...

> Also, do we need both tegra_dt_compat and tegra_interrupt_compat? Can we
> keep only one?

The purpose of tegra_interrupt_compat is to maintain a tegra-specific
whitelist of interrupt controllers we know how to route.  Presumably,
there may be custom boards out there that may have additional
interrupt routing capabilities that this patch set would not support
as-is.  I'm not sure of an appropriate way to maintain that logic and
merge them.  However, I am certainly open to suggestion, if you have
any ideas.

Thanks for the review!
-Chris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Stefano Stabellini]

On Thu, 6 Apr 2017, Chris Patterson wrote:
> From: "Chris Patterson" 
> 
> Tegra devices have a legacy interrupt controller (lic, or ictlr) that
> must be programmed in parallel with their primary GIC. For all intents
> and purposes, we treat these devices attached to this controller as
> connected to the primary GIC, as it will be handling their interrupts.
> 
> This commit adds support for exposing the ictlr to the hardware domain;
> but a future commit will extend this to support exposing a virtualized
> version of the ictlr to the hardware domain, and to ensure that
> interrupts are unmasked properly when routed to a Xen, or to a domain
> other than the hardware domain.
> 
> Authored-by: Kyle Temkin 
> Signed-off-by: Kyle Temkin 
> Signed-off-by: Chris Patterson 
> ---
> 
> changes since rfc:
> - use bool instead of bool_t
> - formatting & code style cleanup
> - fix dt compat label (nvidia,tegra120 -> nvidia,tegra124) for K1
> - separate mediated legacy interrupt controller into its own module
> - split tegra_ictlr_set_interrupt_enable() into
>   tegra_lic_set_interrupt_type_normal() and
>   tegra_lic_set_interrupt_enable()
> - added a couple helper functions to reduce duplicated logic
> - added wrapper tegra_lic_readl and writel functions for external use (mlic)
> - re-order defines in tegra.h
> - cleanup tegra_init() that was previously in patch 6
> 
> ---
> 
>  xen/arch/arm/platforms/Makefile   |   2 +
>  xen/arch/arm/platforms/tegra.c| 313 
> ++
>  xen/include/asm-arm/platforms/tegra.h |  54 ++
>  3 files changed, 369 insertions(+)
>  create mode 100644 xen/arch/arm/platforms/tegra.c
>  create mode 100644 xen/include/asm-arm/platforms/tegra.h
> 
> diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
> index 49fa683..d7033d2 100644
> --- a/xen/arch/arm/platforms/Makefile
> +++ b/xen/arch/arm/platforms/Makefile
> @@ -6,5 +6,7 @@ obj-$(CONFIG_ARM_32) += omap5.o
>  obj-$(CONFIG_ARM_32) += rcar2.o
>  obj-$(CONFIG_ARM_64) += seattle.o
>  obj-$(CONFIG_ARM_32) += sunxi.o
> +obj-$(CONFIG_ARM_32) += tegra.o
> +obj-$(CONFIG_ARM_64) += tegra.o
>  obj-$(CONFIG_ARM_64) += xgene-storm.o
>  obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
> diff --git a/xen/arch/arm/platforms/tegra.c b/xen/arch/arm/platforms/tegra.c
> new file mode 100644
> index 000..bdd9966
> --- /dev/null
> +++ b/xen/arch/arm/platforms/tegra.c
> @@ -0,0 +1,312 @@
> +/*
> + * NVIDIA Tegra specific settings
> + *
> + * Ian Campbell; Copyright (c) 2014 Citrix Systems
> + * Kyle Temkin; Copyright (c) 2016 Assured Information Security, Inc.
> + * Chris Patterson; Copyright (c) 2016 Assured Information Security, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Permanent mapping to the Tegra legacy interrupt controller. */
> +static void __iomem *tegra_ictlr_base;
> +
> +/*
> + * List of legacy interrupt controllers that can be used to route
> + * Tegra interrupts.
> + */
> +static const char * const tegra_interrupt_compat[] __initconst =
> +{
> +"nvidia,tegra124-ictlr",  /* Tegra K1 controllers */
> +"nvidia,tegra210-ictlr"   /* Tegra X1 controllers */
> +};
> +
> +/*
> + * Returns true iff the given IRQ belongs to a supported tegra interrupt
> + * controller.
> + */
> +static bool tegra_irq_belongs_to_ictlr(const struct dt_raw_irq * rirq)  {
> +int i;
> +
> +for ( i = 0; i < ARRAY_SIZE(tegra_interrupt_compat); i++ ) {
> +if ( dt_device_is_compatible(rirq->controller, 
> tegra_interrupt_compat[i]) )
> +return true;
> +}
> +
> +return false;
> +}
> +
> +/*
> + * Returns true iff the given IRQ is routable -- that is, if it is descended
> + * from the platform's primary GIC.
> + */
> +static bool tegra_irq_is_routable(const struct dt_raw_irq * rirq)
> +{
> +/* If the IRQ connects directly to our GIC, it's trivially routable. */
> +if ( rirq->controller == dt_interrupt_controller )
> +return true;
> +
> +/*
> + * If the IRQ belongs to a legacy interrupt controller, then it's
> + * effectively owned by the GIC, and is routable.
> + */
> +if ( tegra_irq_belongs_to_ictlr(rirq) )
> +return true;
> +
> +return false;
> +}
> +
> +/*
> + * Platform-specific reset code for the Tegra devices.
> + * Should 

[Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Chris Patterson]

From: "Chris Patterson" 

Tegra devices have a legacy interrupt controller (lic, or ictlr) that
must be programmed in parallel with their primary GIC. For all intents
and purposes, we treat these devices attached to this controller as
connected to the primary GIC, as it will be handling their interrupts.

This commit adds support for exposing the ictlr to the hardware domain;
but a future commit will extend this to support exposing a virtualized
version of the ictlr to the hardware domain, and to ensure that
interrupts are unmasked properly when routed to a Xen, or to a domain
other than the hardware domain.

Authored-by: Kyle Temkin 
Signed-off-by: Kyle Temkin 
Signed-off-by: Chris Patterson 
---

changes since rfc:
- use bool instead of bool_t
- formatting & code style cleanup
- fix dt compat label (nvidia,tegra120 -> nvidia,tegra124) for K1
- separate mediated legacy interrupt controller into its own module
- split tegra_ictlr_set_interrupt_enable() into
  tegra_lic_set_interrupt_type_normal() and
  tegra_lic_set_interrupt_enable()
- added a couple helper functions to reduce duplicated logic
- added wrapper tegra_lic_readl and writel functions for external use (mlic)
- re-order defines in tegra.h
- cleanup tegra_init() that was previously in patch 6

---

 xen/arch/arm/platforms/Makefile   |   2 +
 xen/arch/arm/platforms/tegra.c| 313 ++
 xen/include/asm-arm/platforms/tegra.h |  54 ++
 3 files changed, 369 insertions(+)
 create mode 100644 xen/arch/arm/platforms/tegra.c
 create mode 100644 xen/include/asm-arm/platforms/tegra.h

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 49fa683..d7033d2 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -6,5 +6,7 @@ obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += rcar2.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-$(CONFIG_ARM_32) += sunxi.o
+obj-$(CONFIG_ARM_32) += tegra.o
+obj-$(CONFIG_ARM_64) += tegra.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
 obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
diff --git a/xen/arch/arm/platforms/tegra.c b/xen/arch/arm/platforms/tegra.c
new file mode 100644
index 000..bdd9966
--- /dev/null
+++ b/xen/arch/arm/platforms/tegra.c
@@ -0,0 +1,312 @@
+/*
+ * NVIDIA Tegra specific settings
+ *
+ * Ian Campbell; Copyright (c) 2014 Citrix Systems
+ * Kyle Temkin; Copyright (c) 2016 Assured Information Security, Inc.
+ * Chris Patterson; Copyright (c) 2016 Assured Information Security, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Permanent mapping to the Tegra legacy interrupt controller. */
+static void __iomem *tegra_ictlr_base;
+
+/*
+ * List of legacy interrupt controllers that can be used to route
+ * Tegra interrupts.
+ */
+static const char * const tegra_interrupt_compat[] __initconst =
+{
+"nvidia,tegra124-ictlr",  /* Tegra K1 controllers */
+"nvidia,tegra210-ictlr"   /* Tegra X1 controllers */
+};
+
+/*
+ * Returns true iff the given IRQ belongs to a supported tegra interrupt
+ * controller.
+ */
+static bool tegra_irq_belongs_to_ictlr(const struct dt_raw_irq * rirq)  {
+int i;
+
+for ( i = 0; i < ARRAY_SIZE(tegra_interrupt_compat); i++ ) {
+if ( dt_device_is_compatible(rirq->controller, 
tegra_interrupt_compat[i]) )
+return true;
+}
+
+return false;
+}
+
+/*
+ * Returns true iff the given IRQ is routable -- that is, if it is descended
+ * from the platform's primary GIC.
+ */
+static bool tegra_irq_is_routable(const struct dt_raw_irq * rirq)
+{
+/* If the IRQ connects directly to our GIC, it's trivially routable. */
+if ( rirq->controller == dt_interrupt_controller )
+return true;
+
+/*
+ * If the IRQ belongs to a legacy interrupt controller, then it's
+ * effectively owned by the GIC, and is routable.
+ */
+if ( tegra_irq_belongs_to_ictlr(rirq) )
+return true;
+
+return false;
+}
+
+/*
+ * Platform-specific reset code for the Tegra devices.
+ * Should not return.
+ */
+static void tegra_reset(void)
+{
+void __iomem *addr;
+u32 val;
+
+addr = ioremap_nocache(TEGRA_RESET_BASE, TEGRA_RESET_SIZE);
+if ( !addr )
+{
+printk(XENLOG_ERR "Tegra: Unable to map tegra reset address. Reset 
failed!\n");
+return;
+}
+
+/* Write into the