Re: [PATCH v10 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
On Thu, Mar 19, 2015 at 07:37:24PM +, Will Deacon wrote: > On Thu, Mar 19, 2015 at 10:12:05AM +, Lorenzo Pieralisi wrote: > > On Thu, Mar 19, 2015 at 03:45:35AM +, Hanjun Guo wrote: > > > >> + if (trigger == ACPI_EDGE_SENSITIVE && > > > >> + polarity == ACPI_ACTIVE_LOW) > > > >> + irq_type = IRQ_TYPE_EDGE_FALLING; > > > >> + else if (trigger == ACPI_EDGE_SENSITIVE && > > > >> + polarity == ACPI_ACTIVE_HIGH) > > > >> + irq_type = IRQ_TYPE_EDGE_RISING; > > > >> + else if (trigger == ACPI_LEVEL_SENSITIVE && > > > >> + polarity == ACPI_ACTIVE_LOW) > > > >> + irq_type = IRQ_TYPE_LEVEL_LOW; > > > >> + else if (trigger == ACPI_LEVEL_SENSITIVE && > > > >> + polarity == ACPI_ACTIVE_HIGH) > > > >> + irq_type = IRQ_TYPE_LEVEL_HIGH; > > > >> + else > > > >> + irq_type = IRQ_TYPE_NONE; > > > >> + > > > >> + /* > > > >> + * Since only one GIC is supported in ACPI 5.0, we can > > > >> + * create mapping refer to the default domain > > > >> + */ > > > >> + irq = irq_create_mapping(NULL, gsi); > > > >> + if (!irq) > > > >> + return irq; > > > >> + > > > >> + /* Set irq type if specified and different than the current one > > > >> */ > > > >> + if (irq_type != IRQ_TYPE_NONE && > > > >> + irq_type != irq_get_trigger_type(irq)) > > > >> + irq_set_irq_type(irq, irq_type); > > > >> + return irq; > > > >> +} > > > >> +EXPORT_SYMBOL_GPL(acpi_register_gsi); > > > > I see you've still got this buried in the arch code. Is there any plan > > > > to > > > > move it out, as I moaned about this in the last version of the series > > > > and > > > > nothing seems to have changed? > > > > > > Ah, sorry. Last time when I was in Hongkong for LCA this Feb, I > > > discussed with Lorenzo and he had a look into that too, he also met some > > > obstacles to do that, so Lorenzo said that he will talk to you about > > > this (Lorenzo, correct me if I'm wrong due to hearing problems of much > > > noise in that room where we were talking). > > > > > > Anyway, if we move those functions to core code, such as irqdomain code, > > > which will be compiled for x86 too, we can only set those functions as > > > _weak, or we guard with them as #ifdef CONFIG_ARM64 ... #endif, so for > > > me, it's really not a big deal to move those code out of arch/arm64, but > > > I'm still open for suggestions if you can do that in a proper way. > > > > You heard me clear and sound in HK, Will has a point and I looked into > > this. Code is generic but not enough to be useful on other arches at > > the moment, I need more time to look into this and see if we can move > > this code to acpi core in a way that makes sense, to have, as you say, > > a "default" implementation. > > Yeah, just something guarded by a CONFIG option (probably not ARM64 > though) would be enough, I think. Nothing too fancy. I had a decent look and on x86/ia64 ACPI gsi mappings (PIC/IOAPIC/IOSAPIC) are buried in arch code (not saying it is nice, it is what it is at present). We can try either to move this code to ACPI layer and make it depend on CONFIG_ARM_GIC somehow, or move it to the GIC driver altogether. I have to think about this, certainly it is not generic code at present (or better it looks generic but can only work on ARM64 with GIC IRQ model). Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
On Fri, Mar 20, 2015 at 01:07:12PM +, Hanjun Guo wrote: > On 2015/3/20 3:37, Will Deacon wrote: > > On Thu, Mar 19, 2015 at 10:12:05AM +, Lorenzo Pieralisi wrote: > >> On Thu, Mar 19, 2015 at 03:45:35AM +, Hanjun Guo wrote: > > + if (trigger == ACPI_EDGE_SENSITIVE && > > + polarity == ACPI_ACTIVE_LOW) > > + irq_type = IRQ_TYPE_EDGE_FALLING; > > + else if (trigger == ACPI_EDGE_SENSITIVE && > > + polarity == ACPI_ACTIVE_HIGH) > > + irq_type = IRQ_TYPE_EDGE_RISING; > > + else if (trigger == ACPI_LEVEL_SENSITIVE && > > + polarity == ACPI_ACTIVE_LOW) > > + irq_type = IRQ_TYPE_LEVEL_LOW; > > + else if (trigger == ACPI_LEVEL_SENSITIVE && > > + polarity == ACPI_ACTIVE_HIGH) > > + irq_type = IRQ_TYPE_LEVEL_HIGH; > > + else > > + irq_type = IRQ_TYPE_NONE; > > + > > + /* > > +* Since only one GIC is supported in ACPI 5.0, we can > > +* create mapping refer to the default domain > > +*/ > > + irq = irq_create_mapping(NULL, gsi); > > + if (!irq) > > + return irq; > > + > > + /* Set irq type if specified and different than the current one > > */ > > + if (irq_type != IRQ_TYPE_NONE && > > + irq_type != irq_get_trigger_type(irq)) > > + irq_set_irq_type(irq, irq_type); > > + return irq; > > +} > > +EXPORT_SYMBOL_GPL(acpi_register_gsi); > I see you've still got this buried in the arch code. Is there any plan to > move it out, as I moaned about this in the last version of the series and > nothing seems to have changed? > >>> Ah, sorry. Last time when I was in Hongkong for LCA this Feb, I > >>> discussed with Lorenzo and he had a look into that too, he also met some > >>> obstacles to do that, so Lorenzo said that he will talk to you about > >>> this (Lorenzo, correct me if I'm wrong due to hearing problems of much > >>> noise in that room where we were talking). > >>> > >>> Anyway, if we move those functions to core code, such as irqdomain code, > >>> which will be compiled for x86 too, we can only set those functions as > >>> _weak, or we guard with them as #ifdef CONFIG_ARM64 ... #endif, so for > >>> me, it's really not a big deal to move those code out of arch/arm64, but > >>> I'm still open for suggestions if you can do that in a proper way. > >> You heard me clear and sound in HK, Will has a point and I looked into > >> this. Code is generic but not enough to be useful on other arches at > >> the moment, I need more time to look into this and see if we can move > >> this code to acpi core in a way that makes sense, to have, as you say, > >> a "default" implementation. > > Yeah, just something guarded by a CONFIG option (probably not ARM64 > > though) would be enough, I think. Nothing too fancy. > Hi Will, > > It is ARM64 related code and ACPI specific, I can come up with following code: No. It is ACPI code that can be made generic (if it is not already, apart from GIC specific comments), so IMO it should live in drivers/acpi and we can introduce a config option for that as we did for S-states and select it on arm64. Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
On 2015/3/20 3:37, Will Deacon wrote:
> On Thu, Mar 19, 2015 at 10:12:05AM +, Lorenzo Pieralisi wrote:
>> On Thu, Mar 19, 2015 at 03:45:35AM +, Hanjun Guo wrote:
> + if (trigger == ACPI_EDGE_SENSITIVE &&
> + polarity == ACPI_ACTIVE_LOW)
> + irq_type = IRQ_TYPE_EDGE_FALLING;
> + else if (trigger == ACPI_EDGE_SENSITIVE &&
> + polarity == ACPI_ACTIVE_HIGH)
> + irq_type = IRQ_TYPE_EDGE_RISING;
> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> + polarity == ACPI_ACTIVE_LOW)
> + irq_type = IRQ_TYPE_LEVEL_LOW;
> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> + polarity == ACPI_ACTIVE_HIGH)
> + irq_type = IRQ_TYPE_LEVEL_HIGH;
> + else
> + irq_type = IRQ_TYPE_NONE;
> +
> + /*
> + * Since only one GIC is supported in ACPI 5.0, we can
> + * create mapping refer to the default domain
> + */
> + irq = irq_create_mapping(NULL, gsi);
> + if (!irq)
> + return irq;
> +
> + /* Set irq type if specified and different than the current one */
> + if (irq_type != IRQ_TYPE_NONE &&
> + irq_type != irq_get_trigger_type(irq))
> + irq_set_irq_type(irq, irq_type);
> + return irq;
> +}
> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
I see you've still got this buried in the arch code. Is there any plan to
move it out, as I moaned about this in the last version of the series and
nothing seems to have changed?
>>> Ah, sorry. Last time when I was in Hongkong for LCA this Feb, I
>>> discussed with Lorenzo and he had a look into that too, he also met some
>>> obstacles to do that, so Lorenzo said that he will talk to you about
>>> this (Lorenzo, correct me if I'm wrong due to hearing problems of much
>>> noise in that room where we were talking).
>>>
>>> Anyway, if we move those functions to core code, such as irqdomain code,
>>> which will be compiled for x86 too, we can only set those functions as
>>> _weak, or we guard with them as #ifdef CONFIG_ARM64 ... #endif, so for
>>> me, it's really not a big deal to move those code out of arch/arm64, but
>>> I'm still open for suggestions if you can do that in a proper way.
>> You heard me clear and sound in HK, Will has a point and I looked into
>> this. Code is generic but not enough to be useful on other arches at
>> the moment, I need more time to look into this and see if we can move
>> this code to acpi core in a way that makes sense, to have, as you say,
>> a "default" implementation.
> Yeah, just something guarded by a CONFIG option (probably not ARM64
> though) would be enough, I think. Nothing too fancy.
Hi Will,
It is ARM64 related code and ACPI specific, I can come up with following code:
arch/arm64/kernel/acpi.c | 67 -
kernel/irq/irqdomain.c | 70
2 files changed, 70 insertions(+), 67 deletions(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 5819ef7..d207544 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -224,73 +224,6 @@ void __init acpi_init_cpus(void)
pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
}
-int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
-{
-*irq = irq_find_mapping(NULL, gsi);
-
-return 0;
-}
-EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
-
-/*
- * success: return IRQ number (>0)
- * failure: return =< 0
- */
-int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
-{
-unsigned int irq;
-unsigned int irq_type;
-
-/*
- * ACPI have no bindings to indicate SPI or PPI, so we
- * use different mappings from DT in ACPI.
- *
- * For FDT
- * PPI interrupt: in the range [0, 15];
- * SPI interrupt: in the range [0, 987];
- *
- * For ACPI, GSI should be unique so using
- * the hwirq directly for the mapping:
- * PPI interrupt: in the range [16, 31];
- * SPI interrupt: in the range [32, 1019];
- */
-
-if (trigger == ACPI_EDGE_SENSITIVE &&
-polarity == ACPI_ACTIVE_LOW)
-irq_type = IRQ_TYPE_EDGE_FALLING;
-else if (trigger == ACPI_EDGE_SENSITIVE &&
-polarity == ACPI_ACTIVE_HIGH)
-irq_type = IRQ_TYPE_EDGE_RISING;
-else if (trigger == ACPI_LEVEL_SENSITIVE &&
-polarity == ACPI_ACTIVE_LOW)
-irq_type = IRQ_TYPE_LEVEL_LOW;
-else if (trigger == ACPI_LEVEL_SENSITIVE &&
-polarity == ACPI_ACTIVE_HIGH)
-irq_type = IRQ_TYPE_LEVEL_HIGH;
-else
-irq_type = IRQ_TYPE_NONE;
-
-/*
- * Since only one GIC is supported in ACPI 5.0, we can
- * create mapping refer to the default domain
- */
-irq = irq_create_mapping(NULL, gsi);
-if (!irq)
-return irq;
-
-/* Set irq type if specified and different t
Re: [PATCH v10 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
On Thu, Mar 19, 2015 at 10:12:05AM +, Lorenzo Pieralisi wrote: > On Thu, Mar 19, 2015 at 03:45:35AM +, Hanjun Guo wrote: > > >> +if (trigger == ACPI_EDGE_SENSITIVE && > > >> +polarity == ACPI_ACTIVE_LOW) > > >> +irq_type = IRQ_TYPE_EDGE_FALLING; > > >> +else if (trigger == ACPI_EDGE_SENSITIVE && > > >> +polarity == ACPI_ACTIVE_HIGH) > > >> +irq_type = IRQ_TYPE_EDGE_RISING; > > >> +else if (trigger == ACPI_LEVEL_SENSITIVE && > > >> +polarity == ACPI_ACTIVE_LOW) > > >> +irq_type = IRQ_TYPE_LEVEL_LOW; > > >> +else if (trigger == ACPI_LEVEL_SENSITIVE && > > >> +polarity == ACPI_ACTIVE_HIGH) > > >> +irq_type = IRQ_TYPE_LEVEL_HIGH; > > >> +else > > >> +irq_type = IRQ_TYPE_NONE; > > >> + > > >> +/* > > >> + * Since only one GIC is supported in ACPI 5.0, we can > > >> + * create mapping refer to the default domain > > >> + */ > > >> +irq = irq_create_mapping(NULL, gsi); > > >> +if (!irq) > > >> +return irq; > > >> + > > >> +/* Set irq type if specified and different than the current one > > >> */ > > >> +if (irq_type != IRQ_TYPE_NONE && > > >> +irq_type != irq_get_trigger_type(irq)) > > >> +irq_set_irq_type(irq, irq_type); > > >> +return irq; > > >> +} > > >> +EXPORT_SYMBOL_GPL(acpi_register_gsi); > > > I see you've still got this buried in the arch code. Is there any plan to > > > move it out, as I moaned about this in the last version of the series and > > > nothing seems to have changed? > > > > Ah, sorry. Last time when I was in Hongkong for LCA this Feb, I > > discussed with Lorenzo and he had a look into that too, he also met some > > obstacles to do that, so Lorenzo said that he will talk to you about > > this (Lorenzo, correct me if I'm wrong due to hearing problems of much > > noise in that room where we were talking). > > > > Anyway, if we move those functions to core code, such as irqdomain code, > > which will be compiled for x86 too, we can only set those functions as > > _weak, or we guard with them as #ifdef CONFIG_ARM64 ... #endif, so for > > me, it's really not a big deal to move those code out of arch/arm64, but > > I'm still open for suggestions if you can do that in a proper way. > > You heard me clear and sound in HK, Will has a point and I looked into > this. Code is generic but not enough to be useful on other arches at > the moment, I need more time to look into this and see if we can move > this code to acpi core in a way that makes sense, to have, as you say, > a "default" implementation. Yeah, just something guarded by a CONFIG option (probably not ARM64 though) would be enough, I think. Nothing too fancy. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
On Thu, Mar 19, 2015 at 03:45:35AM +, Hanjun Guo wrote:
[...]
> >> +/*
> >> + * success: return IRQ number (>0)
> >> + * failure: return =< 0
> >> + */
> >> +int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int
> >> polarity)
> >> +{
> >> + unsigned int irq;
> >> + unsigned int irq_type;
> >> +
> >> + /*
> >> + * ACPI have no bindings to indicate SPI or PPI, so we
> >> + * use different mappings from DT in ACPI.
> >> + *
> >> + * For FDT
> >> + * PPI interrupt: in the range [0, 15];
> >> + * SPI interrupt: in the range [0, 987];
> >> + *
> >> + * For ACPI, GSI should be unique so using
> >> + * the hwirq directly for the mapping:
> >> + * PPI interrupt: in the range [16, 31];
> >> + * SPI interrupt: in the range [32, 1019];
> >> + */
> >> +
> >> + if (trigger == ACPI_EDGE_SENSITIVE &&
> >> + polarity == ACPI_ACTIVE_LOW)
> >> + irq_type = IRQ_TYPE_EDGE_FALLING;
> >> + else if (trigger == ACPI_EDGE_SENSITIVE &&
> >> + polarity == ACPI_ACTIVE_HIGH)
> >> + irq_type = IRQ_TYPE_EDGE_RISING;
> >> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> >> + polarity == ACPI_ACTIVE_LOW)
> >> + irq_type = IRQ_TYPE_LEVEL_LOW;
> >> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> >> + polarity == ACPI_ACTIVE_HIGH)
> >> + irq_type = IRQ_TYPE_LEVEL_HIGH;
> >> + else
> >> + irq_type = IRQ_TYPE_NONE;
> >> +
> >> + /*
> >> + * Since only one GIC is supported in ACPI 5.0, we can
> >> + * create mapping refer to the default domain
> >> + */
> >> + irq = irq_create_mapping(NULL, gsi);
> >> + if (!irq)
> >> + return irq;
> >> +
> >> + /* Set irq type if specified and different than the current one */
> >> + if (irq_type != IRQ_TYPE_NONE &&
> >> + irq_type != irq_get_trigger_type(irq))
> >> + irq_set_irq_type(irq, irq_type);
> >> + return irq;
> >> +}
> >> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
> > I see you've still got this buried in the arch code. Is there any plan to
> > move it out, as I moaned about this in the last version of the series and
> > nothing seems to have changed?
>
> Ah, sorry. Last time when I was in Hongkong for LCA this Feb, I discussed
> with Lorenzo
> and he had a look into that too, he also met some obstacles to do that, so
> Lorenzo
> said that he will talk to you about this (Lorenzo, correct me if I'm wrong
> due to hearing
> problems of much noise in that room where we were talking).
>
> Anyway, if we move those functions to core code, such as irqdomain code,
> which will be
> compiled for x86 too, we can only set those functions as _weak, or we guard
> with them
> as #ifdef CONFIG_ARM64 ... #endif, so for me, it's really not a big deal to
> move those code
> out of arch/arm64, but I'm still open for suggestions if you can do that in a
> proper way.
You heard me clear and sound in HK, Will has a point and I looked into
this. Code is generic but not enough to be useful on other arches at
the moment, I need more time to look into this and see if we can move
this code to acpi core in a way that makes sense, to have, as you say,
a "default" implementation.
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
Hi Will,
On 2015/3/19 2:41, Will Deacon wrote:
> On Wed, Mar 11, 2015 at 12:39:41PM +, Hanjun Guo wrote:
>> Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
>> used, and then register device's gsi with the core IRQ subsystem.
>>
>> acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
>> since gsi is unique in the system, so use hwirq number directly
>> for the mapping.
>>
>> We are going to implement stacked domains when GICv2m, GICv3, ITS
>> support are added.
>>
>> CC: Marc Zyngier
>> Originally-by: Amit Daniel Kachhap
>> Tested-by: Suravee Suthikulpanit
>> Tested-by: Yijing Wang
>> Tested-by: Mark Langsdorf
>> Tested-by: Jon Masters
>> Tested-by: Timur Tabi
>> Tested-by: Robert Richter
>> Acked-by: Robert Richter
>> Acked-by: Rafael J. Wysocki
>> Reviewed-by: Grant Likely
>> Signed-off-by: Hanjun Guo
>> ---
>> arch/arm64/kernel/acpi.c | 73
>>
>> drivers/acpi/bus.c | 3 ++
>> include/linux/acpi.h | 1 +
>> 3 files changed, 77 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index c9203c0..dec6f8a 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -76,6 +76,12 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
>> }
>>
>> /*
>> + * Since we're on ARM, the default interrupt routing model
>> + * clearly has to be GIC.
>> + */
>> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
>> +
>> +/*
>> * __acpi_map_table() will be called before page_init(), so early_ioremap()
>> * or early_memremap() should be called here to for ACPI table mapping.
>> */
>> @@ -218,6 +224,73 @@ void __init acpi_init_cpus(void)
>> pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
>> }
>>
>> +int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
>> +{
>> +*irq = irq_find_mapping(NULL, gsi);
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
>> +
>> +/*
>> + * success: return IRQ number (>0)
>> + * failure: return =< 0
>> + */
>> +int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int
>> polarity)
>> +{
>> +unsigned int irq;
>> +unsigned int irq_type;
>> +
>> +/*
>> + * ACPI have no bindings to indicate SPI or PPI, so we
>> + * use different mappings from DT in ACPI.
>> + *
>> + * For FDT
>> + * PPI interrupt: in the range [0, 15];
>> + * SPI interrupt: in the range [0, 987];
>> + *
>> + * For ACPI, GSI should be unique so using
>> + * the hwirq directly for the mapping:
>> + * PPI interrupt: in the range [16, 31];
>> + * SPI interrupt: in the range [32, 1019];
>> + */
>> +
>> +if (trigger == ACPI_EDGE_SENSITIVE &&
>> +polarity == ACPI_ACTIVE_LOW)
>> +irq_type = IRQ_TYPE_EDGE_FALLING;
>> +else if (trigger == ACPI_EDGE_SENSITIVE &&
>> +polarity == ACPI_ACTIVE_HIGH)
>> +irq_type = IRQ_TYPE_EDGE_RISING;
>> +else if (trigger == ACPI_LEVEL_SENSITIVE &&
>> +polarity == ACPI_ACTIVE_LOW)
>> +irq_type = IRQ_TYPE_LEVEL_LOW;
>> +else if (trigger == ACPI_LEVEL_SENSITIVE &&
>> +polarity == ACPI_ACTIVE_HIGH)
>> +irq_type = IRQ_TYPE_LEVEL_HIGH;
>> +else
>> +irq_type = IRQ_TYPE_NONE;
>> +
>> +/*
>> + * Since only one GIC is supported in ACPI 5.0, we can
>> + * create mapping refer to the default domain
>> + */
>> +irq = irq_create_mapping(NULL, gsi);
>> +if (!irq)
>> +return irq;
>> +
>> +/* Set irq type if specified and different than the current one */
>> +if (irq_type != IRQ_TYPE_NONE &&
>> +irq_type != irq_get_trigger_type(irq))
>> +irq_set_irq_type(irq, irq_type);
>> +return irq;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
> I see you've still got this buried in the arch code. Is there any plan to
> move it out, as I moaned about this in the last version of the series and
> nothing seems to have changed?
Ah, sorry. Last time when I was in Hongkong for LCA this Feb, I discussed with
Lorenzo
and he had a look into that too, he also met some obstacles to do that, so
Lorenzo
said that he will talk to you about this (Lorenzo, correct me if I'm wrong due
to hearing
problems of much noise in that room where we were talking).
Anyway, if we move those functions to core code, such as irqdomain code, which
will be
compiled for x86 too, we can only set those functions as _weak, or we guard
with them
as #ifdef CONFIG_ARM64 ... #endif, so for me, it's really not a big deal to
move those code
out of arch/arm64, but I'm still open for suggestions if you can do that in a
proper way.
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.o
Re: [PATCH v10 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
On Wed, Mar 11, 2015 at 12:39:41PM +, Hanjun Guo wrote:
> Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
> used, and then register device's gsi with the core IRQ subsystem.
>
> acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
> since gsi is unique in the system, so use hwirq number directly
> for the mapping.
>
> We are going to implement stacked domains when GICv2m, GICv3, ITS
> support are added.
>
> CC: Marc Zyngier
> Originally-by: Amit Daniel Kachhap
> Tested-by: Suravee Suthikulpanit
> Tested-by: Yijing Wang
> Tested-by: Mark Langsdorf
> Tested-by: Jon Masters
> Tested-by: Timur Tabi
> Tested-by: Robert Richter
> Acked-by: Robert Richter
> Acked-by: Rafael J. Wysocki
> Reviewed-by: Grant Likely
> Signed-off-by: Hanjun Guo
> ---
> arch/arm64/kernel/acpi.c | 73
>
> drivers/acpi/bus.c | 3 ++
> include/linux/acpi.h | 1 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index c9203c0..dec6f8a 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -76,6 +76,12 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
> }
>
> /*
> + * Since we're on ARM, the default interrupt routing model
> + * clearly has to be GIC.
> + */
> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
> +
> +/*
> * __acpi_map_table() will be called before page_init(), so early_ioremap()
> * or early_memremap() should be called here to for ACPI table mapping.
> */
> @@ -218,6 +224,73 @@ void __init acpi_init_cpus(void)
> pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
> }
>
> +int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> +{
> + *irq = irq_find_mapping(NULL, gsi);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
> +
> +/*
> + * success: return IRQ number (>0)
> + * failure: return =< 0
> + */
> +int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
> +{
> + unsigned int irq;
> + unsigned int irq_type;
> +
> + /*
> + * ACPI have no bindings to indicate SPI or PPI, so we
> + * use different mappings from DT in ACPI.
> + *
> + * For FDT
> + * PPI interrupt: in the range [0, 15];
> + * SPI interrupt: in the range [0, 987];
> + *
> + * For ACPI, GSI should be unique so using
> + * the hwirq directly for the mapping:
> + * PPI interrupt: in the range [16, 31];
> + * SPI interrupt: in the range [32, 1019];
> + */
> +
> + if (trigger == ACPI_EDGE_SENSITIVE &&
> + polarity == ACPI_ACTIVE_LOW)
> + irq_type = IRQ_TYPE_EDGE_FALLING;
> + else if (trigger == ACPI_EDGE_SENSITIVE &&
> + polarity == ACPI_ACTIVE_HIGH)
> + irq_type = IRQ_TYPE_EDGE_RISING;
> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> + polarity == ACPI_ACTIVE_LOW)
> + irq_type = IRQ_TYPE_LEVEL_LOW;
> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> + polarity == ACPI_ACTIVE_HIGH)
> + irq_type = IRQ_TYPE_LEVEL_HIGH;
> + else
> + irq_type = IRQ_TYPE_NONE;
> +
> + /*
> + * Since only one GIC is supported in ACPI 5.0, we can
> + * create mapping refer to the default domain
> + */
> + irq = irq_create_mapping(NULL, gsi);
> + if (!irq)
> + return irq;
> +
> + /* Set irq type if specified and different than the current one */
> + if (irq_type != IRQ_TYPE_NONE &&
> + irq_type != irq_get_trigger_type(irq))
> + irq_set_irq_type(irq, irq_type);
> + return irq;
> +}
> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
I see you've still got this buried in the arch code. Is there any plan to
move it out, as I moaned about this in the last version of the series and
nothing seems to have changed?
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
used, and then register device's gsi with the core IRQ subsystem.
acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
since gsi is unique in the system, so use hwirq number directly
for the mapping.
We are going to implement stacked domains when GICv2m, GICv3, ITS
support are added.
CC: Marc Zyngier
Originally-by: Amit Daniel Kachhap
Tested-by: Suravee Suthikulpanit
Tested-by: Yijing Wang
Tested-by: Mark Langsdorf
Tested-by: Jon Masters
Tested-by: Timur Tabi
Tested-by: Robert Richter
Acked-by: Robert Richter
Acked-by: Rafael J. Wysocki
Reviewed-by: Grant Likely
Signed-off-by: Hanjun Guo
---
arch/arm64/kernel/acpi.c | 73
drivers/acpi/bus.c | 3 ++
include/linux/acpi.h | 1 +
3 files changed, 77 insertions(+)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index c9203c0..dec6f8a 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -76,6 +76,12 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
}
/*
+ * Since we're on ARM, the default interrupt routing model
+ * clearly has to be GIC.
+ */
+enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
+
+/*
* __acpi_map_table() will be called before page_init(), so early_ioremap()
* or early_memremap() should be called here to for ACPI table mapping.
*/
@@ -218,6 +224,73 @@ void __init acpi_init_cpus(void)
pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
}
+int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
+{
+ *irq = irq_find_mapping(NULL, gsi);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
+
+/*
+ * success: return IRQ number (>0)
+ * failure: return =< 0
+ */
+int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
+{
+ unsigned int irq;
+ unsigned int irq_type;
+
+ /*
+* ACPI have no bindings to indicate SPI or PPI, so we
+* use different mappings from DT in ACPI.
+*
+* For FDT
+* PPI interrupt: in the range [0, 15];
+* SPI interrupt: in the range [0, 987];
+*
+* For ACPI, GSI should be unique so using
+* the hwirq directly for the mapping:
+* PPI interrupt: in the range [16, 31];
+* SPI interrupt: in the range [32, 1019];
+*/
+
+ if (trigger == ACPI_EDGE_SENSITIVE &&
+ polarity == ACPI_ACTIVE_LOW)
+ irq_type = IRQ_TYPE_EDGE_FALLING;
+ else if (trigger == ACPI_EDGE_SENSITIVE &&
+ polarity == ACPI_ACTIVE_HIGH)
+ irq_type = IRQ_TYPE_EDGE_RISING;
+ else if (trigger == ACPI_LEVEL_SENSITIVE &&
+ polarity == ACPI_ACTIVE_LOW)
+ irq_type = IRQ_TYPE_LEVEL_LOW;
+ else if (trigger == ACPI_LEVEL_SENSITIVE &&
+ polarity == ACPI_ACTIVE_HIGH)
+ irq_type = IRQ_TYPE_LEVEL_HIGH;
+ else
+ irq_type = IRQ_TYPE_NONE;
+
+ /*
+* Since only one GIC is supported in ACPI 5.0, we can
+* create mapping refer to the default domain
+*/
+ irq = irq_create_mapping(NULL, gsi);
+ if (!irq)
+ return irq;
+
+ /* Set irq type if specified and different than the current one */
+ if (irq_type != IRQ_TYPE_NONE &&
+ irq_type != irq_get_trigger_type(irq))
+ irq_set_irq_type(irq, irq_type);
+ return irq;
+}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
+
+void acpi_unregister_gsi(u32 gsi)
+{
+}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
+
static int __init acpi_parse_fadt(struct acpi_table_header *table)
{
struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 8b67bd0..c412fdb 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -448,6 +448,9 @@ static int __init acpi_bus_init_irq(void)
case ACPI_IRQ_MODEL_IOSAPIC:
message = "IOSAPIC";
break;
+ case ACPI_IRQ_MODEL_GIC:
+ message = "GIC";
+ break;
case ACPI_IRQ_MODEL_PLATFORM:
message = "platform specific model";
break;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 6ec33c5..de4e86f 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -73,6 +73,7 @@ enum acpi_irq_model_id {
ACPI_IRQ_MODEL_IOAPIC,
ACPI_IRQ_MODEL_IOSAPIC,
ACPI_IRQ_MODEL_PLATFORM,
+ ACPI_IRQ_MODEL_GIC,
ACPI_IRQ_MODEL_COUNT
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
