from:"agustinv"

Re: [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-11-11 Thread agustinv


Hey Lorenzo, Hanjun,

On 2016-11-11 08:33, Hanjun Guo wrote:

Hi Lorenzo,

On 11/11/2016 01:58 AM, Lorenzo Pieralisi wrote:
On Thu, Nov 10, 2016 at 10:02:35AM -0500, agust...@codeaurora.org 
wrote:

Hey Hanjun,

On 2016-11-09 21:36, Hanjun Guo wrote:

Hi Marc, Rafael, Lorenzo,

Since we agreed to add a probe deferral if we failed to get irq
resources which mirroring the DT does (patch 1 in this patch set),
I think the last blocker to make things work both for Agustin and
me [1] is this patch, which makes the interrupt producer and 
consumer
work in ACPI, we have two different solution for one thing, we'd 
happy

to work together for one solution, could you give some suggestions
please?

[1]: 
https://mail-archive.com/linux-kernel@vger.kernel.org/msg1257419.html


Agustin, I have some comments below.

On 2016/10/29 4:48, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
drivers/acpi/Makefile|   1 +
drivers/acpi/irqdomain.c | 119
+++


Could we just reuse the gsi.c and not introduce a new
file, probably we can change the gsi.c to irqdomain.c
or something similar, then reuse the code in gsi.c.


I was thinking just that after we chatted off-list.


Yes, that's a fair point.

I might revisit and see what I come up with given that we already 
have

a device argument and we could pass the IRQ source there.


I agree with the approach taken by this patch, I do not like much
passing around struct acpi_resource_source *source (in particular
the dummy struct) I do not think it is needed, I will comment on
the code.


thanks for your time to have a look:)



Hopefully there is not any buggy FW out there that does use the
resource source inappropriately otherwise we will notice on x86/ia64
(ie you can't blame FW if it breaks the kernel) but I suspect the
only way to find out is by trying, the patch has to go through 
Rafael's

review anyway before getting there so it is fine.


I think we can avoid that by not touching the logic that x86/ia64
already used, but only adding interrupt producer/consumer function.


I looked at this more today and implemented a new patch that I plan to
test over the weekend, but I wanted to let you know the approach I am
pursuing.

On the new patch use of ResourceSource when parsing ACPI Extended IRQ
Resources is conditional on CONFIG_ACPI_GENERIC_GSI. The reason for this
is two fold:

1. Since we wanted to reduce duplication and place the new APIs on the
   same source file as acpi_register_gsi, which is already under that
   config flag.
2. So the patch does not have effect on platforms not using the generic
   GSI support, including x86/ia64.

If support for this is needed outside platforms using the generic GSI
implementation, we can move these APIs out to their own source file
and eliminate the CONFIG_ACPI_GENERIC_GSI conditionality.

I'll send the new patch, hopefully some time tomorrow, but please let
me know if you have concerns with this approach.

Thanks,
Agustin

--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project.

Re: [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-11-11 Thread agustinv


Hey Lorenzo, Hanjun,

On 2016-11-11 08:33, Hanjun Guo wrote:

Hi Lorenzo,

On 11/11/2016 01:58 AM, Lorenzo Pieralisi wrote:
On Thu, Nov 10, 2016 at 10:02:35AM -0500, agust...@codeaurora.org 
wrote:

Hey Hanjun,

On 2016-11-09 21:36, Hanjun Guo wrote:

Hi Marc, Rafael, Lorenzo,

Since we agreed to add a probe deferral if we failed to get irq
resources which mirroring the DT does (patch 1 in this patch set),
I think the last blocker to make things work both for Agustin and
me [1] is this patch, which makes the interrupt producer and 
consumer
work in ACPI, we have two different solution for one thing, we'd 
happy

to work together for one solution, could you give some suggestions
please?

[1]: 
https://mail-archive.com/linux-kernel@vger.kernel.org/msg1257419.html


Agustin, I have some comments below.

On 2016/10/29 4:48, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
drivers/acpi/Makefile|   1 +
drivers/acpi/irqdomain.c | 119
+++


Could we just reuse the gsi.c and not introduce a new
file, probably we can change the gsi.c to irqdomain.c
or something similar, then reuse the code in gsi.c.


I was thinking just that after we chatted off-list.


Yes, that's a fair point.

I might revisit and see what I come up with given that we already 
have

a device argument and we could pass the IRQ source there.


I agree with the approach taken by this patch, I do not like much
passing around struct acpi_resource_source *source (in particular
the dummy struct) I do not think it is needed, I will comment on
the code.


thanks for your time to have a look:)



Hopefully there is not any buggy FW out there that does use the
resource source inappropriately otherwise we will notice on x86/ia64
(ie you can't blame FW if it breaks the kernel) but I suspect the
only way to find out is by trying, the patch has to go through 
Rafael's

review anyway before getting there so it is fine.


I think we can avoid that by not touching the logic that x86/ia64
already used, but only adding interrupt producer/consumer function.


I looked at this more today and implemented a new patch that I plan to
test over the weekend, but I wanted to let you know the approach I am
pursuing.

On the new patch use of ResourceSource when parsing ACPI Extended IRQ
Resources is conditional on CONFIG_ACPI_GENERIC_GSI. The reason for this
is two fold:

1. Since we wanted to reduce duplication and place the new APIs on the
   same source file as acpi_register_gsi, which is already under that
   config flag.
2. So the patch does not have effect on platforms not using the generic
   GSI support, including x86/ia64.

If support for this is needed outside platforms using the generic GSI
implementation, we can move these APIs out to their own source file
and eliminate the CONFIG_ACPI_GENERIC_GSI conditionality.

I'll send the new patch, hopefully some time tomorrow, but please let
me know if you have concerns with this approach.

Thanks,
Agustin

--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project.

Re: [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-11-10 Thread agustinv


Hey Hanjun,

On 2016-11-09 21:36, Hanjun Guo wrote:

Hi Marc, Rafael, Lorenzo,

Since we agreed to add a probe deferral if we failed to get irq
resources which mirroring the DT does (patch 1 in this patch set),
I think the last blocker to make things work both for Agustin and
me [1] is this patch, which makes the interrupt producer and consumer
work in ACPI, we have two different solution for one thing, we'd happy
to work together for one solution, could you give some suggestions
please?

[1]: 
https://mail-archive.com/linux-kernel@vger.kernel.org/msg1257419.html


Agustin, I have some comments below.

On 2016/10/29 4:48, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/irqdomain.c | 119 
+++


Could we just reuse the gsi.c and not introduce a new
file, probably we can change the gsi.c to irqdomain.c
or something similar, then reuse the code in gsi.c.


I was thinking just that after we chatted off-list.
I might revisit and see what I come up with given that we already have
a device argument and we could pass the IRQ source there.

Thanks



Thanks
Hanjun


 drivers/acpi/resource.c  |  21 +
 include/linux/acpi.h |  25 ++
 4 files changed, 157 insertions(+), 9 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9ed0878..880401b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
 acpi-$(CONFIG_ACPI_WATCHDOG)   += acpi_watchdog.o
+acpi-$(CONFIG_IRQ_DOMAIN)  += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..11d3658
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,119 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify

+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_register_irq() - Register the mapping for an IRQ 
produced
+ *  by the given acpi_resource_source 
to a

+ *  Linux IRQ number
+ * @source: IRQ source
+ * @hwirq: Hardware IRQ number
+ * @trigger: trigger type of the IRQ number to be mapped
+ * @polarity: polarity of the IRQ to be mapped
+ *
+ * Returns: a valid linux IRQ number on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EPROBE_DEFER if the IRQ domain has not been registered
+ *  -EINVAL for all other errors
+ */
+int acpi_irq_domain_register_irq(const struct acpi_resource_source 
*source,

+u32 hwirq, int trigger, int polarity)
+{
+   struct irq_fwspec fwspec;
+   struct acpi_device *device;
+   acpi_handle handle;
+   acpi_status status;
+   int ret;
+
+   /* An empty acpi_resource_source means it is a GSI */
+   if (!source->string_length)
+   return acpi_register_gsi(NULL, hwirq, trigger, polarity);
+
+   status = acpi_get_handle(NULL, source->string_ptr, );
+   if (ACPI_FAILURE(status))
+   return -ENODEV;
+
+   device = acpi_bus_get_acpi_device(handle);
+   if (!device)
+   return -ENODEV;
+
+	if (irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY) == 
NULL) {

+   ret = -EPROBE_DEFER;
+   goto out_put_device;
+   }
+
+   fwspec.fwnode = >fwnode;
+   fwspec.param[0] = hwirq;
+   fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
+   fwspec.param_count = 2;
+
+   ret = irq_create_fwspec_mapping();
+
+out_put_device:
+   acpi_bus_put_acpi_device(device);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
+
+/**
+ * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ 
produced
+ *by the given 
acpi_resource_source to a

+ *Linux IRQ number
+ * @source: IRQ source
+ * @hwirq: Hardware IRQ number
+ *
+ * Returns: 0 on success
+ *

Re: [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-11-10 Thread agustinv


Hey Hanjun,

On 2016-11-09 21:36, Hanjun Guo wrote:

Hi Marc, Rafael, Lorenzo,

Since we agreed to add a probe deferral if we failed to get irq
resources which mirroring the DT does (patch 1 in this patch set),
I think the last blocker to make things work both for Agustin and
me [1] is this patch, which makes the interrupt producer and consumer
work in ACPI, we have two different solution for one thing, we'd happy
to work together for one solution, could you give some suggestions
please?

[1]: 
https://mail-archive.com/linux-kernel@vger.kernel.org/msg1257419.html


Agustin, I have some comments below.

On 2016/10/29 4:48, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/irqdomain.c | 119 
+++


Could we just reuse the gsi.c and not introduce a new
file, probably we can change the gsi.c to irqdomain.c
or something similar, then reuse the code in gsi.c.


I was thinking just that after we chatted off-list.
I might revisit and see what I come up with given that we already have
a device argument and we could pass the IRQ source there.

Thanks



Thanks
Hanjun


 drivers/acpi/resource.c  |  21 +
 include/linux/acpi.h |  25 ++
 4 files changed, 157 insertions(+), 9 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9ed0878..880401b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
 acpi-$(CONFIG_ACPI_WATCHDOG)   += acpi_watchdog.o
+acpi-$(CONFIG_IRQ_DOMAIN)  += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..11d3658
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,119 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify

+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_register_irq() - Register the mapping for an IRQ 
produced
+ *  by the given acpi_resource_source 
to a

+ *  Linux IRQ number
+ * @source: IRQ source
+ * @hwirq: Hardware IRQ number
+ * @trigger: trigger type of the IRQ number to be mapped
+ * @polarity: polarity of the IRQ to be mapped
+ *
+ * Returns: a valid linux IRQ number on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EPROBE_DEFER if the IRQ domain has not been registered
+ *  -EINVAL for all other errors
+ */
+int acpi_irq_domain_register_irq(const struct acpi_resource_source 
*source,

+u32 hwirq, int trigger, int polarity)
+{
+   struct irq_fwspec fwspec;
+   struct acpi_device *device;
+   acpi_handle handle;
+   acpi_status status;
+   int ret;
+
+   /* An empty acpi_resource_source means it is a GSI */
+   if (!source->string_length)
+   return acpi_register_gsi(NULL, hwirq, trigger, polarity);
+
+   status = acpi_get_handle(NULL, source->string_ptr, );
+   if (ACPI_FAILURE(status))
+   return -ENODEV;
+
+   device = acpi_bus_get_acpi_device(handle);
+   if (!device)
+   return -ENODEV;
+
+	if (irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY) == 
NULL) {

+   ret = -EPROBE_DEFER;
+   goto out_put_device;
+   }
+
+   fwspec.fwnode = >fwnode;
+   fwspec.param[0] = hwirq;
+   fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
+   fwspec.param_count = 2;
+
+   ret = irq_create_fwspec_mapping();
+
+out_put_device:
+   acpi_bus_put_acpi_device(device);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
+
+/**
+ * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ 
produced
+ *by the given 
acpi_resource_source to a

+ *Linux IRQ number
+ * @source: IRQ source
+ * @hwirq: Hardware IRQ number
+ *
+ * Returns: 0 on success
+ *  -ENODEV if the

Re: [PATCH v3 11/14] ACPI: irq: introduce interrupt producer

2016-10-28 Thread agustinv


Hey Hanjun,

On 2016-10-25 11:09, Hanjun Guo wrote:

From: Hanjun Guo 

In ACPI 6.1 spec, section 19.6.62, Interrupt Resource Descriptor Macro,

Interrupt (ResourceUsage, EdgeLevel, ActiveLevel, Shared,
ResourceSourceIndex, ResourceSource, DescriptorName)
{ InterruptList } => Buffer

For the arguement ResourceUsage and DescriptorName, which means:

ResourceUsage describes whether the device consumes the specified
interrupt ( ResourceConsumer ) or produces it for use by a child
device ( ResourceProducer ).
If nothing is specified, then ResourceConsumer is assumed.

DescriptorName evaluates to a name string which refers to the
entire resource descriptor.

So it can be used for devices connecting to a specific interrupt
prodcucer instead of the main interrupt controller in MADT. In the
real world, we have irqchip such as mbi-gen which connecting to
a group of wired interrupts and then issue msi to the ITS, devices
connecting to such interrupt controller fit this scope.

For now the irq for ACPI only pointer to the main interrupt
controller's irqdomain, for devices not connecting to those
irqdomains, which need to present its irq parent, we can use
following ASL code to represent it:

Interrupt(ResourceConsumer,..., "\_SB.IRQP") {12,14,}

then we can parse the interrupt producer with the full
path name "\_SB.IRQP".

In order to do that, we introduce a pointer interrupt_producer
in struct acpi_device, and fill it when scanning irq resources
for acpi device if it specifies the interrupt producer.

But for now when parsing the resources for acpi devices, we don't
pass the acpi device for acpi_walk_resoures() in 
drivers/acpi/resource.c,

so introduce a adev in struct res_proc_context to pass it as a context
to scan the interrupt resources, then finally pass to 
acpi_register_gsi()

to find its interrupt producer to get the virq from diffrent domains.

With steps above ready, rework acpi_register_gsi() to get other
interrupt producer if devices not connecting to main interrupt
controller.

Since we often pass NULL to acpi_register_gsi() and there is no 
interrupt
producer for devices connect to gicd on ARM or io-apic on X86, so it 
will
use the default irqdomain for those deivces and no functional changes 
to

those devices.

Signed-off-by: Hanjun Guo 
Cc: Rafael J. Wysocki 
Cc: Marc Zyngier 
Cc: Agustin Vega-Frias 
Cc: Lorenzo Pieralisi 
---
 drivers/acpi/gsi.c  | 10 --
 drivers/acpi/resource.c | 85 
++---

 include/acpi/acpi_bus.h |  1 +
 3 files changed, 68 insertions(+), 28 deletions(-)

diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
index ee9e0f2..29ee547 100644
--- a/drivers/acpi/gsi.c
+++ b/drivers/acpi/gsi.c
@@ -55,13 +55,19 @@ int acpi_register_gsi(struct device *dev, u32 gsi,
int trigger,
  int polarity)
 {
struct irq_fwspec fwspec;
+   struct acpi_device *adev = dev ? to_acpi_device(dev) : NULL;

-   if (WARN_ON(!acpi_gsi_domain_id)) {
+   if (adev && >fwnode && adev->interrupt_producer)
+   /* devices in DSDT connecting to spefic interrupt producer */
+   fwspec.fwnode = adev->interrupt_producer;
+   else if (acpi_gsi_domain_id)
+   /* devices connecting to gicd in default */
+   fwspec.fwnode = acpi_gsi_domain_id;
+   else {
pr_warn("GSI: No registered irqchip, giving up\n");
return -EINVAL;
}

-   fwspec.fwnode = acpi_gsi_domain_id;
fwspec.param[0] = gsi;
fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
fwspec.param_count = 2;
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 56241eb..f1371cf 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -381,7 +381,7 @@ static void acpi_dev_irqresource_disabled(struct
resource *res, u32 gsi)
res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
 }

-static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
+static void acpi_dev_get_irqresource(struct acpi_device *adev, struct
resource *res, u32 gsi,
 u8 triggering, u8 polarity, u8 shareable,
 bool legacy)
 {
@@ -415,7 +415,7 @@ static void acpi_dev_get_irqresource(struct
resource *res, u32 gsi,
}

res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
-   irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
+   irq = acpi_register_gsi(>dev, gsi, triggering, polarity);
if (irq >= 0) {
res->start = irq;
res->end = irq;
@@ -424,27 +424,9 @@ static void acpi_dev_get_irqresource(struct
resource *res, u32 gsi,
}
 }

-/**
- * acpi_dev_resource_interrupt - Extract ACPI interrupt resource 
information.

- * @ares: Input

Re: [PATCH v3 11/14] ACPI: irq: introduce interrupt producer

2016-10-28 Thread agustinv


Hey Hanjun,

On 2016-10-25 11:09, Hanjun Guo wrote:

From: Hanjun Guo 

In ACPI 6.1 spec, section 19.6.62, Interrupt Resource Descriptor Macro,

Interrupt (ResourceUsage, EdgeLevel, ActiveLevel, Shared,
ResourceSourceIndex, ResourceSource, DescriptorName)
{ InterruptList } => Buffer

For the arguement ResourceUsage and DescriptorName, which means:

ResourceUsage describes whether the device consumes the specified
interrupt ( ResourceConsumer ) or produces it for use by a child
device ( ResourceProducer ).
If nothing is specified, then ResourceConsumer is assumed.

DescriptorName evaluates to a name string which refers to the
entire resource descriptor.

So it can be used for devices connecting to a specific interrupt
prodcucer instead of the main interrupt controller in MADT. In the
real world, we have irqchip such as mbi-gen which connecting to
a group of wired interrupts and then issue msi to the ITS, devices
connecting to such interrupt controller fit this scope.

For now the irq for ACPI only pointer to the main interrupt
controller's irqdomain, for devices not connecting to those
irqdomains, which need to present its irq parent, we can use
following ASL code to represent it:

Interrupt(ResourceConsumer,..., "\_SB.IRQP") {12,14,}

then we can parse the interrupt producer with the full
path name "\_SB.IRQP".

In order to do that, we introduce a pointer interrupt_producer
in struct acpi_device, and fill it when scanning irq resources
for acpi device if it specifies the interrupt producer.

But for now when parsing the resources for acpi devices, we don't
pass the acpi device for acpi_walk_resoures() in 
drivers/acpi/resource.c,

so introduce a adev in struct res_proc_context to pass it as a context
to scan the interrupt resources, then finally pass to 
acpi_register_gsi()

to find its interrupt producer to get the virq from diffrent domains.

With steps above ready, rework acpi_register_gsi() to get other
interrupt producer if devices not connecting to main interrupt
controller.

Since we often pass NULL to acpi_register_gsi() and there is no 
interrupt
producer for devices connect to gicd on ARM or io-apic on X86, so it 
will
use the default irqdomain for those deivces and no functional changes 
to

those devices.

Signed-off-by: Hanjun Guo 
Cc: Rafael J. Wysocki 
Cc: Marc Zyngier 
Cc: Agustin Vega-Frias 
Cc: Lorenzo Pieralisi 
---
 drivers/acpi/gsi.c  | 10 --
 drivers/acpi/resource.c | 85 
++---

 include/acpi/acpi_bus.h |  1 +
 3 files changed, 68 insertions(+), 28 deletions(-)

diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
index ee9e0f2..29ee547 100644
--- a/drivers/acpi/gsi.c
+++ b/drivers/acpi/gsi.c
@@ -55,13 +55,19 @@ int acpi_register_gsi(struct device *dev, u32 gsi,
int trigger,
  int polarity)
 {
struct irq_fwspec fwspec;
+   struct acpi_device *adev = dev ? to_acpi_device(dev) : NULL;

-   if (WARN_ON(!acpi_gsi_domain_id)) {
+   if (adev && >fwnode && adev->interrupt_producer)
+   /* devices in DSDT connecting to spefic interrupt producer */
+   fwspec.fwnode = adev->interrupt_producer;
+   else if (acpi_gsi_domain_id)
+   /* devices connecting to gicd in default */
+   fwspec.fwnode = acpi_gsi_domain_id;
+   else {
pr_warn("GSI: No registered irqchip, giving up\n");
return -EINVAL;
}

-   fwspec.fwnode = acpi_gsi_domain_id;
fwspec.param[0] = gsi;
fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
fwspec.param_count = 2;
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 56241eb..f1371cf 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -381,7 +381,7 @@ static void acpi_dev_irqresource_disabled(struct
resource *res, u32 gsi)
res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
 }

-static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
+static void acpi_dev_get_irqresource(struct acpi_device *adev, struct
resource *res, u32 gsi,
 u8 triggering, u8 polarity, u8 shareable,
 bool legacy)
 {
@@ -415,7 +415,7 @@ static void acpi_dev_get_irqresource(struct
resource *res, u32 gsi,
}

res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
-   irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
+   irq = acpi_register_gsi(>dev, gsi, triggering, polarity);
if (irq >= 0) {
res->start = irq;
res->end = irq;
@@ -424,27 +424,9 @@ static void acpi_dev_get_irqresource(struct
resource *res, u32 gsi,
}
 }

-/**
- * acpi_dev_resource_interrupt - Extract ACPI interrupt resource 
information.

- * @ares: Input ACPI resource object.
- * @index: Index into the array of GSIs represented by the resource.
- * @res: Output generic resource object.
- *
-

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-10-25 Thread agustinv


Hi Marc, Lorenzo,

On 2016-10-20 13:51, Marc Zyngier wrote:

On 20/10/16 17:48, Lorenzo Pieralisi wrote:

Hi Agustin,

On Tue, Oct 18, 2016 at 01:41:48PM -0400, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile |   1 +
 drivers/acpi/irqdomain.c  | 141 
++

 drivers/acpi/resource.c   |  21 +++---
 include/asm-generic/vmlinux.lds.h |   1 +
 include/linux/acpi.h  |  71 +++
 include/linux/irqchip.h   |  17 -
 6 files changed, 240 insertions(+), 12 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9ed0878..880401b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
 acpi-$(CONFIG_ACPI_WATCHDOG)   += acpi_watchdog.o
+acpi-$(CONFIG_IRQ_DOMAIN)  += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..c53b9f4
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,141 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify
+ * it under the terms of the GNU General Public License version 2 
and

+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_ensure_probed() - Check if the device has 
registered
+ *   an IRQ domain and probe as 
necessary

+ *
+ * @device: Device to check and probe
+ *
+ * Returns: 0 on success, -ENODEV otherwise


This is not correct (ie it depends on what

struct acpi_dsdt_probe_entry.probe

returns) and I would like to take this nit as an opportunity
to take a step back and ask you a question below.


+ */
+static int acpi_irq_domain_ensure_probed(struct acpi_device *device)
+{
+   struct acpi_dsdt_probe_entry *entry;
+
+   if (irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY) != 0)
+   return 0;
+
+   for (entry = &__dsdt_acpi_probe_table;
+entry < &__dsdt_acpi_probe_table_end; entry++)
+   if (strcmp(entry->_hid, acpi_device_hid(device)) == 0)
+   return entry->probe(device);


Through this approch we are forcing an irqchip (that by the way it
has a physical node ACPI companion by being a DSDT device object so it
could be managed by a platform driver) to be probed. The question is: 
is

there a reason (apart from the current ACPI resource parsing API) why
this can't be implemented through deferred probing and the device
dependencies framework Rafael is working on:

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1246897.html

The DT layer, through the of_irq_get() API, supports probe deferral
and what I am asking you is if there is any blocking point (again,
apart from the current ACPI API) to implement the same mechanism.

I have not reviewed the previous versions so I am certainly missing
some of the bits and pieces already discussed, apologies for that.


Also, this function scares me to no end: lack of locking and recursion
are the main things that worry me. My vote would be to implement
something based on Rafael's approach (which conveniently solves all 
kind

of other issues).



I have looked at the latest version of Rafael's patchset for device 
functional
dependency tracking and in its current form it does not address the 
issues

we see with dependencies on irqchips under ACPI boot.

The problem is that the conversion of ACPI IRQ resources to Linux IRQ 
resources
for most DSDT devices occurs before the device is even added and is not 
retried
when a device is re-probed after returning -EPROBE_DEFER. The call chain 
in most

cases is:

acpi_init()
acpi_scan_init()
acpi_bus_scan()
acpi_bus_attach()
acpi_default_enumeration()
acpi_create_platform_device()
acpi_dev_get_resources() /* Resources are 
converted here */

platform_device_register_full()
platform_device_add()

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-10-25 Thread agustinv


Hi Marc, Lorenzo,

On 2016-10-20 13:51, Marc Zyngier wrote:

On 20/10/16 17:48, Lorenzo Pieralisi wrote:

Hi Agustin,

On Tue, Oct 18, 2016 at 01:41:48PM -0400, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile |   1 +
 drivers/acpi/irqdomain.c  | 141 
++

 drivers/acpi/resource.c   |  21 +++---
 include/asm-generic/vmlinux.lds.h |   1 +
 include/linux/acpi.h  |  71 +++
 include/linux/irqchip.h   |  17 -
 6 files changed, 240 insertions(+), 12 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9ed0878..880401b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
 acpi-$(CONFIG_ACPI_WATCHDOG)   += acpi_watchdog.o
+acpi-$(CONFIG_IRQ_DOMAIN)  += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..c53b9f4
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,141 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify
+ * it under the terms of the GNU General Public License version 2 
and

+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_ensure_probed() - Check if the device has 
registered
+ *   an IRQ domain and probe as 
necessary

+ *
+ * @device: Device to check and probe
+ *
+ * Returns: 0 on success, -ENODEV otherwise


This is not correct (ie it depends on what

struct acpi_dsdt_probe_entry.probe

returns) and I would like to take this nit as an opportunity
to take a step back and ask you a question below.


+ */
+static int acpi_irq_domain_ensure_probed(struct acpi_device *device)
+{
+   struct acpi_dsdt_probe_entry *entry;
+
+   if (irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY) != 0)
+   return 0;
+
+   for (entry = &__dsdt_acpi_probe_table;
+entry < &__dsdt_acpi_probe_table_end; entry++)
+   if (strcmp(entry->_hid, acpi_device_hid(device)) == 0)
+   return entry->probe(device);


Through this approch we are forcing an irqchip (that by the way it
has a physical node ACPI companion by being a DSDT device object so it
could be managed by a platform driver) to be probed. The question is: 
is

there a reason (apart from the current ACPI resource parsing API) why
this can't be implemented through deferred probing and the device
dependencies framework Rafael is working on:

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1246897.html

The DT layer, through the of_irq_get() API, supports probe deferral
and what I am asking you is if there is any blocking point (again,
apart from the current ACPI API) to implement the same mechanism.

I have not reviewed the previous versions so I am certainly missing
some of the bits and pieces already discussed, apologies for that.


Also, this function scares me to no end: lack of locking and recursion
are the main things that worry me. My vote would be to implement
something based on Rafael's approach (which conveniently solves all 
kind

of other issues).



I have looked at the latest version of Rafael's patchset for device 
functional
dependency tracking and in its current form it does not address the 
issues

we see with dependencies on irqchips under ACPI boot.

The problem is that the conversion of ACPI IRQ resources to Linux IRQ 
resources
for most DSDT devices occurs before the device is even added and is not 
retried
when a device is re-probed after returning -EPROBE_DEFER. The call chain 
in most

cases is:

acpi_init()
acpi_scan_init()
acpi_bus_scan()
acpi_bus_attach()
acpi_default_enumeration()
acpi_create_platform_device()
acpi_dev_get_resources() /* Resources are 
converted here */

platform_device_register_full()
platform_device_add()
device_add()

What I would like

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-10-20 Thread agustinv


Hey Marc,

On 2016-10-20 13:51, Marc Zyngier wrote:

On 20/10/16 17:48, Lorenzo Pieralisi wrote:

Hi Agustin,

On Tue, Oct 18, 2016 at 01:41:48PM -0400, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile |   1 +
 drivers/acpi/irqdomain.c  | 141 
++

 drivers/acpi/resource.c   |  21 +++---
 include/asm-generic/vmlinux.lds.h |   1 +
 include/linux/acpi.h  |  71 +++
 include/linux/irqchip.h   |  17 -
 6 files changed, 240 insertions(+), 12 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9ed0878..880401b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
 acpi-$(CONFIG_ACPI_WATCHDOG)   += acpi_watchdog.o
+acpi-$(CONFIG_IRQ_DOMAIN)  += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..c53b9f4
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,141 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify
+ * it under the terms of the GNU General Public License version 2 
and

+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_ensure_probed() - Check if the device has 
registered
+ *   an IRQ domain and probe as 
necessary

+ *
+ * @device: Device to check and probe
+ *
+ * Returns: 0 on success, -ENODEV otherwise


This is not correct (ie it depends on what

struct acpi_dsdt_probe_entry.probe

returns) and I would like to take this nit as an opportunity
to take a step back and ask you a question below.


+ */
+static int acpi_irq_domain_ensure_probed(struct acpi_device *device)
+{
+   struct acpi_dsdt_probe_entry *entry;
+
+   if (irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY) != 0)
+   return 0;
+
+   for (entry = &__dsdt_acpi_probe_table;
+entry < &__dsdt_acpi_probe_table_end; entry++)
+   if (strcmp(entry->_hid, acpi_device_hid(device)) == 0)
+   return entry->probe(device);


Through this approch we are forcing an irqchip (that by the way it
has a physical node ACPI companion by being a DSDT device object so it
could be managed by a platform driver) to be probed. The question is: 
is

there a reason (apart from the current ACPI resource parsing API) why
this can't be implemented through deferred probing and the device
dependencies framework Rafael is working on:

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1246897.html

The DT layer, through the of_irq_get() API, supports probe deferral
and what I am asking you is if there is any blocking point (again,
apart from the current ACPI API) to implement the same mechanism.

I have not reviewed the previous versions so I am certainly missing
some of the bits and pieces already discussed, apologies for that.


Also, this function scares me to no end: lack of locking and recursion
are the main things that worry me. My vote would be to implement
something based on Rafael's approach (which conveniently solves all 
kind

of other issues).


I'll review Rafael's latest patchset and comment back on whether it 
suits

our needs or if we can build on that.

Thanks



I'll review this patch series in a more in-depth way soon, but I wanted
to chime in and add my own weight to Lorenzo's proposal.

Thanks,

M.
--
Jazz is not dead. It just smells funny...


--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project.

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-10-20 Thread agustinv


Hey Marc,

On 2016-10-20 13:51, Marc Zyngier wrote:

On 20/10/16 17:48, Lorenzo Pieralisi wrote:

Hi Agustin,

On Tue, Oct 18, 2016 at 01:41:48PM -0400, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile |   1 +
 drivers/acpi/irqdomain.c  | 141 
++

 drivers/acpi/resource.c   |  21 +++---
 include/asm-generic/vmlinux.lds.h |   1 +
 include/linux/acpi.h  |  71 +++
 include/linux/irqchip.h   |  17 -
 6 files changed, 240 insertions(+), 12 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9ed0878..880401b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
 acpi-$(CONFIG_ACPI_WATCHDOG)   += acpi_watchdog.o
+acpi-$(CONFIG_IRQ_DOMAIN)  += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..c53b9f4
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,141 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify
+ * it under the terms of the GNU General Public License version 2 
and

+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_ensure_probed() - Check if the device has 
registered
+ *   an IRQ domain and probe as 
necessary

+ *
+ * @device: Device to check and probe
+ *
+ * Returns: 0 on success, -ENODEV otherwise


This is not correct (ie it depends on what

struct acpi_dsdt_probe_entry.probe

returns) and I would like to take this nit as an opportunity
to take a step back and ask you a question below.


+ */
+static int acpi_irq_domain_ensure_probed(struct acpi_device *device)
+{
+   struct acpi_dsdt_probe_entry *entry;
+
+   if (irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY) != 0)
+   return 0;
+
+   for (entry = &__dsdt_acpi_probe_table;
+entry < &__dsdt_acpi_probe_table_end; entry++)
+   if (strcmp(entry->_hid, acpi_device_hid(device)) == 0)
+   return entry->probe(device);


Through this approch we are forcing an irqchip (that by the way it
has a physical node ACPI companion by being a DSDT device object so it
could be managed by a platform driver) to be probed. The question is: 
is

there a reason (apart from the current ACPI resource parsing API) why
this can't be implemented through deferred probing and the device
dependencies framework Rafael is working on:

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1246897.html

The DT layer, through the of_irq_get() API, supports probe deferral
and what I am asking you is if there is any blocking point (again,
apart from the current ACPI API) to implement the same mechanism.

I have not reviewed the previous versions so I am certainly missing
some of the bits and pieces already discussed, apologies for that.


Also, this function scares me to no end: lack of locking and recursion
are the main things that worry me. My vote would be to implement
something based on Rafael's approach (which conveniently solves all 
kind

of other issues).


I'll review Rafael's latest patchset and comment back on whether it 
suits

our needs or if we can build on that.

Thanks



I'll review this patch series in a more in-depth way soon, but I wanted
to chime in and add my own weight to Lorenzo's proposal.

Thanks,

M.
--
Jazz is not dead. It just smells funny...


--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project.

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-10-20 Thread agustinv


Hey Lorenzo,

On 2016-10-20 12:48, Lorenzo Pieralisi wrote:

Hi Agustin,

On Tue, Oct 18, 2016 at 01:41:48PM -0400, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile |   1 +
 drivers/acpi/irqdomain.c  | 141 
++

 drivers/acpi/resource.c   |  21 +++---
 include/asm-generic/vmlinux.lds.h |   1 +
 include/linux/acpi.h  |  71 +++
 include/linux/irqchip.h   |  17 -
 6 files changed, 240 insertions(+), 12 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9ed0878..880401b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
 acpi-$(CONFIG_ACPI_WATCHDOG)   += acpi_watchdog.o
+acpi-$(CONFIG_IRQ_DOMAIN)  += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..c53b9f4
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,141 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify

+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_ensure_probed() - Check if the device has 
registered
+ *   an IRQ domain and probe as 
necessary

+ *
+ * @device: Device to check and probe
+ *
+ * Returns: 0 on success, -ENODEV otherwise


This is not correct (ie it depends on what

struct acpi_dsdt_probe_entry.probe

returns) and I would like to take this nit as an opportunity
to take a step back and ask you a question below.



Will fix this as necessary if this approach is pursued.


+ */
+static int acpi_irq_domain_ensure_probed(struct acpi_device *device)
+{
+   struct acpi_dsdt_probe_entry *entry;
+
+   if (irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY) != 0)
+   return 0;
+
+   for (entry = &__dsdt_acpi_probe_table;
+entry < &__dsdt_acpi_probe_table_end; entry++)
+   if (strcmp(entry->_hid, acpi_device_hid(device)) == 0)
+   return entry->probe(device);


Through this approch we are forcing an irqchip (that by the way it
has a physical node ACPI companion by being a DSDT device object so it
could be managed by a platform driver) to be probed. The question is: 
is

there a reason (apart from the current ACPI resource parsing API) why
this can't be implemented through deferred probing and the device
dependencies framework Rafael is working on:

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1246897.html

The DT layer, through the of_irq_get() API, supports probe deferral
and what I am asking you is if there is any blocking point (again,
apart from the current ACPI API) to implement the same mechanism.

I have not reviewed the previous versions so I am certainly missing
some of the bits and pieces already discussed, apologies for that.



I need to review the latest version of Rafael's patchset to see if the 
issues

around ACPI IRQ resource conversion are addressed.

The problem we found before was that probe deferral didn't work because
the ACPI core converts all ACPI IRQ resources to Linux resources for 
devices

at the same init level at the same time and that causes the conversion
to fail unless the supplier driver is promoted to an earlier init level.

Thanks,
Agustin


Thanks,
Lorenzo


+
+   return -ENODEV;
+}
+
+/**
+ * acpi_irq_domain_register_irq() - Register the mapping for an IRQ 
produced
+ *  by the given acpi_resource_source 
to a

+ *  Linux IRQ number
+ * @source: IRQ source
+ * @hwirq: Hardware IRQ number
+ * @trigger: trigger type of the IRQ number to be mapped
+ * @polarity: polarity of the IRQ to be mapped
+ *
+ * Returns: a valid linux IRQ number on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EPROBE_DEFER if the IRQ domain has not been registered
+ *  -EINVAL for all other errors
+ */
+int

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-10-20 Thread agustinv


Hey Lorenzo,

On 2016-10-20 12:48, Lorenzo Pieralisi wrote:

Hi Agustin,

On Tue, Oct 18, 2016 at 01:41:48PM -0400, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile |   1 +
 drivers/acpi/irqdomain.c  | 141 
++

 drivers/acpi/resource.c   |  21 +++---
 include/asm-generic/vmlinux.lds.h |   1 +
 include/linux/acpi.h  |  71 +++
 include/linux/irqchip.h   |  17 -
 6 files changed, 240 insertions(+), 12 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9ed0878..880401b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
 acpi-$(CONFIG_ACPI_WATCHDOG)   += acpi_watchdog.o
+acpi-$(CONFIG_IRQ_DOMAIN)  += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..c53b9f4
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,141 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify

+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_ensure_probed() - Check if the device has 
registered
+ *   an IRQ domain and probe as 
necessary

+ *
+ * @device: Device to check and probe
+ *
+ * Returns: 0 on success, -ENODEV otherwise


This is not correct (ie it depends on what

struct acpi_dsdt_probe_entry.probe

returns) and I would like to take this nit as an opportunity
to take a step back and ask you a question below.



Will fix this as necessary if this approach is pursued.


+ */
+static int acpi_irq_domain_ensure_probed(struct acpi_device *device)
+{
+   struct acpi_dsdt_probe_entry *entry;
+
+   if (irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY) != 0)
+   return 0;
+
+   for (entry = &__dsdt_acpi_probe_table;
+entry < &__dsdt_acpi_probe_table_end; entry++)
+   if (strcmp(entry->_hid, acpi_device_hid(device)) == 0)
+   return entry->probe(device);


Through this approch we are forcing an irqchip (that by the way it
has a physical node ACPI companion by being a DSDT device object so it
could be managed by a platform driver) to be probed. The question is: 
is

there a reason (apart from the current ACPI resource parsing API) why
this can't be implemented through deferred probing and the device
dependencies framework Rafael is working on:

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1246897.html

The DT layer, through the of_irq_get() API, supports probe deferral
and what I am asking you is if there is any blocking point (again,
apart from the current ACPI API) to implement the same mechanism.

I have not reviewed the previous versions so I am certainly missing
some of the bits and pieces already discussed, apologies for that.



I need to review the latest version of Rafael's patchset to see if the 
issues

around ACPI IRQ resource conversion are addressed.

The problem we found before was that probe deferral didn't work because
the ACPI core converts all ACPI IRQ resources to Linux resources for 
devices

at the same init level at the same time and that causes the conversion
to fail unless the supplier driver is promoted to an earlier init level.

Thanks,
Agustin


Thanks,
Lorenzo


+
+   return -ENODEV;
+}
+
+/**
+ * acpi_irq_domain_register_irq() - Register the mapping for an IRQ 
produced
+ *  by the given acpi_resource_source 
to a

+ *  Linux IRQ number
+ * @source: IRQ source
+ * @hwirq: Hardware IRQ number
+ * @trigger: trigger type of the IRQ number to be mapped
+ * @polarity: polarity of the IRQ to be mapped
+ *
+ * Returns: a valid linux IRQ number on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EPROBE_DEFER if the IRQ domain has not been registered
+ *  -EINVAL for all other errors
+ */
+int acpi_irq_domain_register_irq(const struct

Re: [PATCH V3 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-06-06 Thread agustinv


On 2016-06-04 08:30, Marc Zyngier wrote:

On Fri, 13 May 2016 12:16:42 -0400
Agustin Vega-Frias  wrote:


This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/irqdomain.c | 108 
+++

 drivers/acpi/resource.c  |  23 ++
 include/linux/acpi.h |   6 +++
 4 files changed, 130 insertions(+), 8 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b12fa64..79db78f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -56,6 +56,7 @@ acpi-$(CONFIG_ACPI_NUMA)  += numa.o
 acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
+acpi-y += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..0fd10a9
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,108 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify

+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_register_irq() - Register the mapping for an IRQ 
produced
+ *  by the given acpi_resource_source 
to a

+ *  Linux IRQ number
+ * @source: IRQ source


I'm a bit uncertain if this describe the interrupt producer (the device
that shakes an interrupt line) or the interrupt collator (the device
that presents a bunch of interrupts to a downstream element). I'm
tempted to say that this is the latter, but that's far from being 
clear.


That is correct, acpi_resource_source is a device that produces IRQs for 
other devices.





+ * @rcirq: IRQ number
+ * @trigger: trigger type of the IRQ number to be mapped
+ * @polarity: polarity of the IRQ to be mapped


So if I'm right in my above understanding, you've reinvented an
existing abstraction (irq_fwspec).


+ *
+ * Returns: a valid linux IRQ number on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EPROBE_DEFER if the IRQ domain has not been registered
+ *  -EINVAL for all other errors
+ */
+int acpi_irq_domain_register_irq(struct acpi_resource_source *source, 
u32 rcirq,

+int trigger, int polarity)
+{
+   struct irq_domain *domain;
+   struct acpi_device *device;
+   acpi_handle handle;
+   acpi_status status;
+   unsigned int type;
+   int ret;
+
+   status = acpi_get_handle(NULL, source->string_ptr, );
+   if (ACPI_FAILURE(status))
+   return -ENODEV;
+
+   device = acpi_bus_get_acpi_device(handle);
+   if (!device)
+   return -ENODEV;
+


So at this point, you should be able to create a irq_fwspec, and call
into irq_create_fwspec_mapping(), without the need to open-code stuff
we already have. And as a bonus point, you'd end-up with code that'd be
similar to what is in gsi.c...



Got it.


+   domain = irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY);
+   if (!domain) {
+   ret = -EPROBE_DEFER;
+   goto out_put_device;
+   }
+
+   type = acpi_dev_get_irq_type(trigger, polarity);
+   ret = irq_create_mapping(domain, rcirq);
+   if (ret)
+   irq_set_irq_type(ret, type);
+
+out_put_device:
+   acpi_bus_put_acpi_device(device);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
+
+/**
+ * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ 
produced
+ *by the given 
acpi_resource_source to a

+ *Linux IRQ number
+ * @source: IRQ source
+ * @rcirq: IRQ number
+ *
+ * Returns: 0 on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EINVAL for all other errors
+ */
+int acpi_irq_domain_unregister_irq(struct acpi_resource_source 
*source,

+  u32 rcirq)
+{
+   struct irq_domain *domain;
+   struct acpi_device *device;
+   acpi_handle handle;
+   acpi_status status;
+

Re: [PATCH V3 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-06-06 Thread agustinv


On 2016-06-04 08:30, Marc Zyngier wrote:

On Fri, 13 May 2016 12:16:42 -0400
Agustin Vega-Frias  wrote:


This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/irqdomain.c | 108 
+++

 drivers/acpi/resource.c  |  23 ++
 include/linux/acpi.h |   6 +++
 4 files changed, 130 insertions(+), 8 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b12fa64..79db78f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -56,6 +56,7 @@ acpi-$(CONFIG_ACPI_NUMA)  += numa.o
 acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
+acpi-y += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..0fd10a9
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,108 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify

+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_register_irq() - Register the mapping for an IRQ 
produced
+ *  by the given acpi_resource_source 
to a

+ *  Linux IRQ number
+ * @source: IRQ source


I'm a bit uncertain if this describe the interrupt producer (the device
that shakes an interrupt line) or the interrupt collator (the device
that presents a bunch of interrupts to a downstream element). I'm
tempted to say that this is the latter, but that's far from being 
clear.


That is correct, acpi_resource_source is a device that produces IRQs for 
other devices.





+ * @rcirq: IRQ number
+ * @trigger: trigger type of the IRQ number to be mapped
+ * @polarity: polarity of the IRQ to be mapped


So if I'm right in my above understanding, you've reinvented an
existing abstraction (irq_fwspec).


+ *
+ * Returns: a valid linux IRQ number on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EPROBE_DEFER if the IRQ domain has not been registered
+ *  -EINVAL for all other errors
+ */
+int acpi_irq_domain_register_irq(struct acpi_resource_source *source, 
u32 rcirq,

+int trigger, int polarity)
+{
+   struct irq_domain *domain;
+   struct acpi_device *device;
+   acpi_handle handle;
+   acpi_status status;
+   unsigned int type;
+   int ret;
+
+   status = acpi_get_handle(NULL, source->string_ptr, );
+   if (ACPI_FAILURE(status))
+   return -ENODEV;
+
+   device = acpi_bus_get_acpi_device(handle);
+   if (!device)
+   return -ENODEV;
+


So at this point, you should be able to create a irq_fwspec, and call
into irq_create_fwspec_mapping(), without the need to open-code stuff
we already have. And as a bonus point, you'd end-up with code that'd be
similar to what is in gsi.c...



Got it.


+   domain = irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY);
+   if (!domain) {
+   ret = -EPROBE_DEFER;
+   goto out_put_device;
+   }
+
+   type = acpi_dev_get_irq_type(trigger, polarity);
+   ret = irq_create_mapping(domain, rcirq);
+   if (ret)
+   irq_set_irq_type(ret, type);
+
+out_put_device:
+   acpi_bus_put_acpi_device(device);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
+
+/**
+ * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ 
produced
+ *by the given 
acpi_resource_source to a

+ *Linux IRQ number
+ * @source: IRQ source
+ * @rcirq: IRQ number
+ *
+ * Returns: 0 on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EINVAL for all other errors
+ */
+int acpi_irq_domain_unregister_irq(struct acpi_resource_source 
*source,

+  u32 rcirq)
+{
+   struct irq_domain *domain;
+   struct acpi_device *device;
+   acpi_handle handle;
+   acpi_status status;
+   int ret = 0;
+
+   status =

Re: [PATCH V3 2/2] irqchip: qcom: Add IRQ combiner driver

2016-05-25 Thread agustinv


Adding linux-arm-kernel and linux-acpi

On 2016-05-13 12:16, Agustin Vega-Frias wrote:

Driver for interrupt combiners in the Top-level Control and Status
Registers (TCSR) hardware block in Qualcomm Technologies chips.

An interrupt combiner in this block combines a set of interrupts by
OR'ing the individual interrupt signals into a summary interrupt
signal routed to a parent interrupt controller, and provides read-
only, 32-bit registers to query the status of individual interrupts.
The status bit for IRQ n is bit (n % 32) within register (n / 32)
of the given combiner. Thus, each combiner can be described as a set
of register offsets and the number of IRQs managed.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/irqchip/Kconfig |   8 +
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/qcom-irq-combiner.c | 344 


 3 files changed, 353 insertions(+)
 create mode 100644 drivers/irqchip/qcom-irq-combiner.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index f582e0d..609ff28 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -245,3 +245,11 @@ config IRQ_MXS
 config MVEBU_ODMI
bool
select GENERIC_MSI_IRQ_DOMAIN
+
+config QCOM_IRQ_COMBINER
+   bool "QCOM IRQ combiner support"
+   depends on ARCH_QCOM
+   select IRQ_DOMAIN
+   help
+ Say yes here to add support for the IRQ combiner devices embedded
+ in Qualcomm Technologies chips.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index b03cfcb..05c688b 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -65,3 +65,4 @@ obj-$(CONFIG_INGENIC_IRQ) += irq-ingenic.o
 obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
 obj-$(CONFIG_PIC32_EVIC)   += irq-pic32-evic.o
 obj-$(CONFIG_MVEBU_ODMI)   += irq-mvebu-odmi.o
+obj-$(CONFIG_QCOM_IRQ_COMBINER)+= qcom-irq-combiner.o
diff --git a/drivers/irqchip/qcom-irq-combiner.c
b/drivers/irqchip/qcom-irq-combiner.c
new file mode 100644
index 000..b4f767c
--- /dev/null
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -0,0 +1,344 @@
+/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify

+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+/*
+ * Driver for interrupt combiners in the Top-level Control and Status
+ * Registers (TCSR) hardware block in Qualcomm Technologies chips.
+ * An interrupt combiner in this block combines a set of interrupts by
+ * OR'ing the individual interrupt signals into a summary interrupt
+ * signal routed to a parent interrupt controller, and provides read-
+ * only, 32-bit registers to query the status of individual 
interrupts.

+ * The status bit for IRQ n is bit (n % 32) within register (n / 32)
+ * of the given combiner. Thus, each combiner can be described as a 
set

+ * of register offsets and the number of IRQs managed.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_SIZE 32
+
+struct combiner_reg {
+   void __iomem *addr;
+   unsigned long mask;
+};
+
+struct combiner {
+   struct irq_chip irq_chip;
+   struct irq_domain   *domain;
+   int parent_irq;
+   u32 nirqs;
+   u32 nregs;
+   struct combiner_reg regs[0];
+};
+
+static inline u32 irq_register(int irq)
+{
+   return irq / REG_SIZE;
+}
+
+static inline u32 irq_bit(int irq)
+{
+   return irq % REG_SIZE;
+
+}
+
+static inline int irq_nr(u32 reg, u32 bit)
+{
+   return reg * REG_SIZE + bit;
+}
+
+/*
+ * Handler for the cascaded IRQ.
+ */
+static void combiner_handle_irq(struct irq_desc *desc)
+{
+   struct combiner *combiner = irq_desc_get_handler_data(desc);
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   u32 reg;
+
+   chained_irq_enter(chip, desc);
+
+   for (reg = 0; reg < combiner->nregs; reg++) {
+   int virq;
+   int hwirq;
+   u32 bit;
+   u32 status;
+
+   if (combiner->regs[reg].mask == 0)
+   continue;
+
+   status = readl_relaxed(combiner->regs[reg].addr);
+   status &= combiner->regs[reg].mask;
+
+   while (status) {
+   bit = __ffs(status);
+   status &= ~(1 << bit);
+   hwirq = irq_nr(reg, bit);
+

Re: [PATCH V3 2/2] irqchip: qcom: Add IRQ combiner driver

2016-05-25 Thread agustinv


Adding linux-arm-kernel and linux-acpi

On 2016-05-13 12:16, Agustin Vega-Frias wrote:

Driver for interrupt combiners in the Top-level Control and Status
Registers (TCSR) hardware block in Qualcomm Technologies chips.

An interrupt combiner in this block combines a set of interrupts by
OR'ing the individual interrupt signals into a summary interrupt
signal routed to a parent interrupt controller, and provides read-
only, 32-bit registers to query the status of individual interrupts.
The status bit for IRQ n is bit (n % 32) within register (n / 32)
of the given combiner. Thus, each combiner can be described as a set
of register offsets and the number of IRQs managed.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/irqchip/Kconfig |   8 +
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/qcom-irq-combiner.c | 344 


 3 files changed, 353 insertions(+)
 create mode 100644 drivers/irqchip/qcom-irq-combiner.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index f582e0d..609ff28 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -245,3 +245,11 @@ config IRQ_MXS
 config MVEBU_ODMI
bool
select GENERIC_MSI_IRQ_DOMAIN
+
+config QCOM_IRQ_COMBINER
+   bool "QCOM IRQ combiner support"
+   depends on ARCH_QCOM
+   select IRQ_DOMAIN
+   help
+ Say yes here to add support for the IRQ combiner devices embedded
+ in Qualcomm Technologies chips.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index b03cfcb..05c688b 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -65,3 +65,4 @@ obj-$(CONFIG_INGENIC_IRQ) += irq-ingenic.o
 obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
 obj-$(CONFIG_PIC32_EVIC)   += irq-pic32-evic.o
 obj-$(CONFIG_MVEBU_ODMI)   += irq-mvebu-odmi.o
+obj-$(CONFIG_QCOM_IRQ_COMBINER)+= qcom-irq-combiner.o
diff --git a/drivers/irqchip/qcom-irq-combiner.c
b/drivers/irqchip/qcom-irq-combiner.c
new file mode 100644
index 000..b4f767c
--- /dev/null
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -0,0 +1,344 @@
+/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify

+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+/*
+ * Driver for interrupt combiners in the Top-level Control and Status
+ * Registers (TCSR) hardware block in Qualcomm Technologies chips.
+ * An interrupt combiner in this block combines a set of interrupts by
+ * OR'ing the individual interrupt signals into a summary interrupt
+ * signal routed to a parent interrupt controller, and provides read-
+ * only, 32-bit registers to query the status of individual 
interrupts.

+ * The status bit for IRQ n is bit (n % 32) within register (n / 32)
+ * of the given combiner. Thus, each combiner can be described as a 
set

+ * of register offsets and the number of IRQs managed.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_SIZE 32
+
+struct combiner_reg {
+   void __iomem *addr;
+   unsigned long mask;
+};
+
+struct combiner {
+   struct irq_chip irq_chip;
+   struct irq_domain   *domain;
+   int parent_irq;
+   u32 nirqs;
+   u32 nregs;
+   struct combiner_reg regs[0];
+};
+
+static inline u32 irq_register(int irq)
+{
+   return irq / REG_SIZE;
+}
+
+static inline u32 irq_bit(int irq)
+{
+   return irq % REG_SIZE;
+
+}
+
+static inline int irq_nr(u32 reg, u32 bit)
+{
+   return reg * REG_SIZE + bit;
+}
+
+/*
+ * Handler for the cascaded IRQ.
+ */
+static void combiner_handle_irq(struct irq_desc *desc)
+{
+   struct combiner *combiner = irq_desc_get_handler_data(desc);
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   u32 reg;
+
+   chained_irq_enter(chip, desc);
+
+   for (reg = 0; reg < combiner->nregs; reg++) {
+   int virq;
+   int hwirq;
+   u32 bit;
+   u32 status;
+
+   if (combiner->regs[reg].mask == 0)
+   continue;
+
+   status = readl_relaxed(combiner->regs[reg].addr);
+   status &= combiner->regs[reg].mask;
+
+   while (status) {
+   bit = __ffs(status);
+   status &= ~(1 << bit);
+   hwirq = irq_nr(reg, bit);
+   virq =

Re: [PATCH V3 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-05-25 Thread agustinv


Adding linux-arm-kernel and linux-acpi

On 2016-05-13 12:16, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/irqdomain.c | 108 
+++

 drivers/acpi/resource.c  |  23 ++
 include/linux/acpi.h |   6 +++
 4 files changed, 130 insertions(+), 8 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b12fa64..79db78f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -56,6 +56,7 @@ acpi-$(CONFIG_ACPI_NUMA)  += numa.o
 acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
+acpi-y += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..0fd10a9
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,108 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify

+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_register_irq() - Register the mapping for an IRQ 
produced
+ *  by the given acpi_resource_source 
to a

+ *  Linux IRQ number
+ * @source: IRQ source
+ * @rcirq: IRQ number
+ * @trigger: trigger type of the IRQ number to be mapped
+ * @polarity: polarity of the IRQ to be mapped
+ *
+ * Returns: a valid linux IRQ number on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EPROBE_DEFER if the IRQ domain has not been registered
+ *  -EINVAL for all other errors
+ */
+int acpi_irq_domain_register_irq(struct acpi_resource_source *source,
u32 rcirq,
+int trigger, int polarity)
+{
+   struct irq_domain *domain;
+   struct acpi_device *device;
+   acpi_handle handle;
+   acpi_status status;
+   unsigned int type;
+   int ret;
+
+   status = acpi_get_handle(NULL, source->string_ptr, );
+   if (ACPI_FAILURE(status))
+   return -ENODEV;
+
+   device = acpi_bus_get_acpi_device(handle);
+   if (!device)
+   return -ENODEV;
+
+   domain = irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY);
+   if (!domain) {
+   ret = -EPROBE_DEFER;
+   goto out_put_device;
+   }
+
+   type = acpi_dev_get_irq_type(trigger, polarity);
+   ret = irq_create_mapping(domain, rcirq);
+   if (ret)
+   irq_set_irq_type(ret, type);
+
+out_put_device:
+   acpi_bus_put_acpi_device(device);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
+
+/**
+ * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ 
produced
+ *by the given 
acpi_resource_source to a

+ *Linux IRQ number
+ * @source: IRQ source
+ * @rcirq: IRQ number
+ *
+ * Returns: 0 on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EINVAL for all other errors
+ */
+int acpi_irq_domain_unregister_irq(struct acpi_resource_source 
*source,

+  u32 rcirq)
+{
+   struct irq_domain *domain;
+   struct acpi_device *device;
+   acpi_handle handle;
+   acpi_status status;
+   int ret = 0;
+
+   status = acpi_get_handle(NULL, source->string_ptr, );
+   if (ACPI_FAILURE(status))
+   return -ENODEV;
+
+   device = acpi_bus_get_acpi_device(handle);
+   if (!device)
+   return -ENODEV;
+
+   domain = irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY);
+   if (!domain) {
+   ret = -EINVAL;
+   goto out_put_device;
+   }
+
+   irq_dispose_mapping(irq_find_mapping(domain, rcirq));
+
+out_put_device:
+   acpi_bus_put_acpi_device(device);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(acpi_irq_domain_unregister_irq);
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 56241eb..1551698 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@

Re: [PATCH V3 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

2016-05-25 Thread agustinv


Adding linux-arm-kernel and linux-acpi

On 2016-05-13 12:16, Agustin Vega-Frias wrote:

This allows irqchip drivers to associate an ACPI DSDT device to
an IRQ domain and provides support for using the ResourceSource
in Extended IRQ Resources to find the domain and map the IRQs
specified on that domain.

Signed-off-by: Agustin Vega-Frias 
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/irqdomain.c | 108 
+++

 drivers/acpi/resource.c  |  23 ++
 include/linux/acpi.h |   6 +++
 4 files changed, 130 insertions(+), 8 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b12fa64..79db78f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -56,6 +56,7 @@ acpi-$(CONFIG_ACPI_NUMA)  += numa.o
 acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 acpi-y += acpi_lpat.o
 acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
+acpi-y += irqdomain.o

 # These are (potentially) separate modules

diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
new file mode 100644
index 000..0fd10a9
--- /dev/null
+++ b/drivers/acpi/irqdomain.c
@@ -0,0 +1,108 @@
+/*
+ * ACPI ResourceSource/IRQ domain mapping support
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify

+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+/**
+ * acpi_irq_domain_register_irq() - Register the mapping for an IRQ 
produced
+ *  by the given acpi_resource_source 
to a

+ *  Linux IRQ number
+ * @source: IRQ source
+ * @rcirq: IRQ number
+ * @trigger: trigger type of the IRQ number to be mapped
+ * @polarity: polarity of the IRQ to be mapped
+ *
+ * Returns: a valid linux IRQ number on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EPROBE_DEFER if the IRQ domain has not been registered
+ *  -EINVAL for all other errors
+ */
+int acpi_irq_domain_register_irq(struct acpi_resource_source *source,
u32 rcirq,
+int trigger, int polarity)
+{
+   struct irq_domain *domain;
+   struct acpi_device *device;
+   acpi_handle handle;
+   acpi_status status;
+   unsigned int type;
+   int ret;
+
+   status = acpi_get_handle(NULL, source->string_ptr, );
+   if (ACPI_FAILURE(status))
+   return -ENODEV;
+
+   device = acpi_bus_get_acpi_device(handle);
+   if (!device)
+   return -ENODEV;
+
+   domain = irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY);
+   if (!domain) {
+   ret = -EPROBE_DEFER;
+   goto out_put_device;
+   }
+
+   type = acpi_dev_get_irq_type(trigger, polarity);
+   ret = irq_create_mapping(domain, rcirq);
+   if (ret)
+   irq_set_irq_type(ret, type);
+
+out_put_device:
+   acpi_bus_put_acpi_device(device);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
+
+/**
+ * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ 
produced
+ *by the given 
acpi_resource_source to a

+ *Linux IRQ number
+ * @source: IRQ source
+ * @rcirq: IRQ number
+ *
+ * Returns: 0 on success
+ *  -ENODEV if the given acpi_resource_source cannot be found
+ *  -EINVAL for all other errors
+ */
+int acpi_irq_domain_unregister_irq(struct acpi_resource_source 
*source,

+  u32 rcirq)
+{
+   struct irq_domain *domain;
+   struct acpi_device *device;
+   acpi_handle handle;
+   acpi_status status;
+   int ret = 0;
+
+   status = acpi_get_handle(NULL, source->string_ptr, );
+   if (ACPI_FAILURE(status))
+   return -ENODEV;
+
+   device = acpi_bus_get_acpi_device(handle);
+   if (!device)
+   return -ENODEV;
+
+   domain = irq_find_matching_fwnode(>fwnode, DOMAIN_BUS_ANY);
+   if (!domain) {
+   ret = -EINVAL;
+   goto out_put_device;
+   }
+
+   irq_dispose_mapping(irq_find_mapping(domain, rcirq));
+
+out_put_device:
+   acpi_bus_put_acpi_device(device);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(acpi_irq_domain_unregister_irq);
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 56241eb..1551698 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -381,14 +381,15 @@ static

Re: [PATCH V3 0/2] irqchip: qcom: Add IRQ combiner driver

2016-05-25 Thread agustinv


Adding linux-arm-kernel and linux-acpi

On 2016-05-13 12:16, Agustin Vega-Frias wrote:

Add support for IRQ combiners in the Top-level Control and Status
Registers (TCSR) hardware block in Qualcomm Technologies chips.

The first patch adds support for ResourceSource/IRQ domain mapping
when using Extended IRQ Resources with a specific ResourceSource.
The core ACPI resource management code has been changed to lookup
the IRQ domain when an IRQ resource indicates a ResourceSource,
and register the IRQ on that domain, instead of a GSI.

The second patch takes advantage of the new capabilities to implement
the driver for the IRQ combiners.

Changes V1 -> V2:
* Remove use of GPIO library for the combiner
* Refactor to use fwnode/ResourceSource to IRQ domain mapping
  introduced in ACPI core

Changes V2 -> V3:
* Removed parsing of _PRS to find IRQs
* Removed acpi_irq_domain_create and acpi_irq_domain_remove

Agustin Vega-Frias (2):
  ACPI: Add support for ResourceSource/IRQ domain mapping
  irqchip: qcom: Add IRQ combiner driver

 drivers/acpi/Makefile   |   1 +
 drivers/acpi/irqdomain.c| 108 +++
 drivers/acpi/resource.c |  23 ++-
 drivers/irqchip/Kconfig |   8 +
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/qcom-irq-combiner.c | 344 


 include/linux/acpi.h|   6 +
 7 files changed, 483 insertions(+), 8 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c
 create mode 100644 drivers/irqchip/qcom-irq-combiner.c

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project.


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project.

Re: [PATCH V3 0/2] irqchip: qcom: Add IRQ combiner driver

2016-05-25 Thread agustinv


Adding linux-arm-kernel and linux-acpi

On 2016-05-13 12:16, Agustin Vega-Frias wrote:

Add support for IRQ combiners in the Top-level Control and Status
Registers (TCSR) hardware block in Qualcomm Technologies chips.

The first patch adds support for ResourceSource/IRQ domain mapping
when using Extended IRQ Resources with a specific ResourceSource.
The core ACPI resource management code has been changed to lookup
the IRQ domain when an IRQ resource indicates a ResourceSource,
and register the IRQ on that domain, instead of a GSI.

The second patch takes advantage of the new capabilities to implement
the driver for the IRQ combiners.

Changes V1 -> V2:
* Remove use of GPIO library for the combiner
* Refactor to use fwnode/ResourceSource to IRQ domain mapping
  introduced in ACPI core

Changes V2 -> V3:
* Removed parsing of _PRS to find IRQs
* Removed acpi_irq_domain_create and acpi_irq_domain_remove

Agustin Vega-Frias (2):
  ACPI: Add support for ResourceSource/IRQ domain mapping
  irqchip: qcom: Add IRQ combiner driver

 drivers/acpi/Makefile   |   1 +
 drivers/acpi/irqdomain.c| 108 +++
 drivers/acpi/resource.c |  23 ++-
 drivers/irqchip/Kconfig |   8 +
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/qcom-irq-combiner.c | 344 


 include/linux/acpi.h|   6 +
 7 files changed, 483 insertions(+), 8 deletions(-)
 create mode 100644 drivers/acpi/irqdomain.c
 create mode 100644 drivers/irqchip/qcom-irq-combiner.c

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project.


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project.

Re: [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH v3 11/14] ACPI: irq: introduce interrupt producer

Re: [PATCH v3 11/14] ACPI: irq: introduce interrupt producer

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V3 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V3 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V3 2/2] irqchip: qcom: Add IRQ combiner driver

Re: [PATCH V3 2/2] irqchip: qcom: Add IRQ combiner driver

Re: [PATCH V3 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V3 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Re: [PATCH V3 0/2] irqchip: qcom: Add IRQ combiner driver

Re: [PATCH V3 0/2] irqchip: qcom: Add IRQ combiner driver

20 matches

Site Navigation

Mail list logo

Footer information