diff mbox series

[v4,2/2] gpio: sch: Hook into ACPI SCI handler to catch GPIO edge events

Message ID 20210316162613.87710-3-andriy.shevchenko@linux.intel.com
State New
Headers show
Series gpio: sch: Interrupt support | expand

Commit Message

Andy Shevchenko March 16, 2021, 4:26 p.m. UTC 
From: Jan Kiszka <jan.kiszka@siemens.com>

Neither the ACPI description on the Quark platform provides the required
information is to do establish generic handling nor hardware capable of
doing it. According to the datasheet the hardware can generate SCI events.
Therefore, we need to hook from the driver directly into SCI handler of
the ACPI subsystem in order to catch and report GPIO-related events.

Validated on the Quark-based IOT2000 platform.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Co-developed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpio/gpio-sch.c | 55 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

Comments

Andy Shevchenko March 16, 2021, 8:49 p.m. UTC | #1 
On Tue, Mar 16, 2021 at 06:26:13PM +0200, Andy Shevchenko wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Neither the ACPI description on the Quark platform provides the required
> information is to do establish generic handling nor hardware capable of
> doing it. According to the datasheet the hardware can generate SCI events.
> Therefore, we need to hook from the driver directly into SCI handler of
> the ACPI subsystem in order to catch and report GPIO-related events.
> 
> Validated on the Quark-based IOT2000 platform.

This patch must be dropped completely. SCI handler is not correct way to do
this. The proper way (and we have already few examples in the kernel) is to
register GPE event.

It took me a while to gather all bits of this puzzle.

At least now I get an event, but kernel oopses, I'll continue debugging
tomorrow.
Jan Kiszka March 17, 2021, 6:57 a.m. UTC | #2 
On 16.03.21 21:49, Andy Shevchenko wrote:
> On Tue, Mar 16, 2021 at 06:26:13PM +0200, Andy Shevchenko wrote:

>> From: Jan Kiszka <jan.kiszka@siemens.com>

>>

>> Neither the ACPI description on the Quark platform provides the required

>> information is to do establish generic handling nor hardware capable of

>> doing it. According to the datasheet the hardware can generate SCI events.

>> Therefore, we need to hook from the driver directly into SCI handler of

>> the ACPI subsystem in order to catch and report GPIO-related events.

>>

>> Validated on the Quark-based IOT2000 platform.

> 

> This patch must be dropped completely. SCI handler is not correct way to do

> this. The proper way (and we have already few examples in the kernel) is to

> register GPE event.


As explained above, this is not supported by the preexisting firmware,
and there won't be any updates to it anymore.

This platform is history, the SoC was discontinued by Intel long ago,
and our devices reaching their support end as well. The race to upstream
was lost in this case - backlog too long, we being too slow.

Jan

> 

> It took me a while to gather all bits of this puzzle.

> 

> At least now I get an event, but kernel oopses, I'll continue debugging

> tomorrow.

> 


-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Andy Shevchenko March 17, 2021, 9:52 a.m. UTC | #3 
On Wed, Mar 17, 2021 at 07:57:44AM +0100, Jan Kiszka wrote:
> On 16.03.21 21:49, Andy Shevchenko wrote:

> > On Tue, Mar 16, 2021 at 06:26:13PM +0200, Andy Shevchenko wrote:

> >> From: Jan Kiszka <jan.kiszka@siemens.com>

> >>

> >> Neither the ACPI description on the Quark platform provides the required

> >> information is to do establish generic handling nor hardware capable of

> >> doing it. According to the datasheet the hardware can generate SCI events.

> >> Therefore, we need to hook from the driver directly into SCI handler of

> >> the ACPI subsystem in order to catch and report GPIO-related events.

> >>

> >> Validated on the Quark-based IOT2000 platform.

> > 

> > This patch must be dropped completely. SCI handler is not correct way to do

> > this. The proper way (and we have already few examples in the kernel) is to

> > register GPE event.

> 

> As explained above, this is not supported by the preexisting firmware,

> and there won't be any updates to it anymore.

> 

> This platform is history, the SoC was discontinued by Intel long ago,

> and our devices reaching their support end as well. The race to upstream

> was lost in this case - backlog too long, we being too slow.


So you have no device to test and there is actually no device which has this
capability in the wild.

Am I reading this correct?

In any case, we have platforms in the wild that actually support GPEs and this
makes sense for them.

> > It took me a while to gather all bits of this puzzle.

> > 

> > At least now I get an event, but kernel oopses, I'll continue debugging

> > tomorrow.


-- 
With Best Regards,
Andy Shevchenko
Jan Kiszka March 17, 2021, 9:57 a.m. UTC | #4 
On 17.03.21 10:52, Andy Shevchenko wrote:
> On Wed, Mar 17, 2021 at 07:57:44AM +0100, Jan Kiszka wrote:

>> On 16.03.21 21:49, Andy Shevchenko wrote:

>>> On Tue, Mar 16, 2021 at 06:26:13PM +0200, Andy Shevchenko wrote:

>>>> From: Jan Kiszka <jan.kiszka@siemens.com>

>>>>

>>>> Neither the ACPI description on the Quark platform provides the required

>>>> information is to do establish generic handling nor hardware capable of

>>>> doing it. According to the datasheet the hardware can generate SCI events.

>>>> Therefore, we need to hook from the driver directly into SCI handler of

>>>> the ACPI subsystem in order to catch and report GPIO-related events.

>>>>

>>>> Validated on the Quark-based IOT2000 platform.

>>>

>>> This patch must be dropped completely. SCI handler is not correct way to do

>>> this. The proper way (and we have already few examples in the kernel) is to

>>> register GPE event.

>>

>> As explained above, this is not supported by the preexisting firmware,

>> and there won't be any updates to it anymore.

>>

>> This platform is history, the SoC was discontinued by Intel long ago,

>> and our devices reaching their support end as well. The race to upstream

>> was lost in this case - backlog too long, we being too slow.

> 

> So you have no device to test and there is actually no device which has this

> capability in the wild.

> 

> Am I reading this correct?


No. We do have devices but we don't have the time to invest further into
bringing missing features upstream - not to speak of changing the
firmware in order to support cleaner upstream integration.

For the remaining lifetime of the devices, we are stuck on 4.4.y-cip
with a few additional patches, including this one.

> 

> In any case, we have platforms in the wild that actually support GPEs and this

> makes sense for them.


Sure, I don't want to judge for them. Just our original target of this
patch is no longer relevant for upstream.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
diff mbox series

Patch

diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index bbf8ee0b54de..022677d36a7c 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -26,6 +26,7 @@ 
 struct sch_gpio {
 	struct gpio_chip chip;
 	struct irq_chip irqchip;
+	acpi_sci_handler sci_handler;
 	spinlock_t lock;
 	unsigned short iobase;
 	unsigned short resume_base;
@@ -152,6 +153,28 @@  static const struct gpio_chip sch_gpio_chip = {
 	.get_direction		= sch_gpio_get_direction,
 };
 
+static u32 sch_gpio_sci_handler(void *context)
+{
+	struct sch_gpio *sch = context;
+	struct gpio_chip *gc = &sch->chip;
+	unsigned long core_status, resume_status;
+	unsigned long pending;
+	int offset;
+
+	core_status = inl(sch->iobase + GTS + 0x00);
+	resume_status = inl(sch->iobase + GTS + 0x20);
+
+	pending = (resume_status << sch->resume_base) | core_status;
+
+	for_each_set_bit(offset, &pending, sch->chip.ngpio)
+		generic_handle_irq(irq_find_mapping(gc->irq.domain, offset));
+
+	outl(core_status, sch->iobase + GTS + 0x00);
+	outl(resume_status, sch->iobase + GTS + 0x20);
+
+	return pending ? ACPI_INTERRUPT_HANDLED : ACPI_INTERRUPT_NOT_HANDLED;
+}
+
 static int sch_irq_type(struct irq_data *d, unsigned int type)
 {
 	struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
@@ -211,10 +234,36 @@  static void sch_irq_unmask(struct irq_data *d)
 	sch_irq_set_enable(d, 1);
 }
 
+static void sch_gpio_remove_sci_handler(void *data)
+{
+	struct sch_gpio *sch = data;
+	struct device *dev = sch->chip.parent;
+	acpi_status status;
+
+	status = acpi_remove_sci_handler(sch->sci_handler);
+	if (ACPI_FAILURE(status))
+		dev_err(dev, "Can't remove SCI handler\n");
+}
+
+static int sch_gpio_install_sci_handler(struct sch_gpio *sch)
+{
+	struct device *dev = sch->chip.parent;
+	acpi_status status;
+
+	status = acpi_install_sci_handler(sch->sci_handler, sch);
+	if (ACPI_SUCCESS(status))
+		return devm_add_action_or_reset(dev, sch_gpio_remove_sci_handler, sch);
+
+	/* SCI handler is optional */
+	dev_warn(dev, "Can't install SCI handler, no IRQ support\n");
+	return 0;
+}
+
 static int sch_gpio_probe(struct platform_device *pdev)
 {
 	struct sch_gpio *sch;
 	struct resource *res;
+	int ret;
 
 	sch = devm_kzalloc(&pdev->dev, sizeof(*sch), GFP_KERNEL);
 	if (!sch)
@@ -286,6 +335,12 @@  static int sch_gpio_probe(struct platform_device *pdev)
 	sch->chip.irq.default_type = IRQ_TYPE_NONE;
 	sch->chip.irq.handler = handle_bad_irq;
 
+	sch->sci_handler = sch_gpio_sci_handler;
+
+	ret = sch_gpio_install_sci_handler(sch);
+	if (ret)
+		return ret;
+
 	return devm_gpiochip_add_data(&pdev->dev, &sch->chip, sch);
 }