Re: [PATCH] pinctrl: cherryview: Add a quirk to make Acer Chromebook keyboard work again

[Marc Zyngier <marc.zyngier@xxxxxxx>]

On 06/04/17 11:50, Mika Westerberg wrote:
> On Thu, Apr 06, 2017 at 11:32:59AM +0100, Marc Zyngier wrote:
>> On 06/04/17 10:59, Mika Westerberg wrote:
>>> On Thu, Mar 30, 2017 at 12:00:47PM +0300, Mika Westerberg wrote:
>>>>>> Isn't the right solution to translate this back to the offset from the "Linux
>>>>>> IRQ" and use that offset? This quirk seems pretty violent.
>>>>>
>>>>> I'm not sure I understand the quirk here, but my personal approach would
>>>>> be to provide an inverse mapping oldIRQ->hwirq, and use the usual
>>>>> irqdomain lookup to get back to the real thing.
>>>>
>>>> OK, thanks for tip. Let me try both approaches and see which one works
>>>> better :)
>>>
>>> I've now looked at the issue again and I'm actually not sure if we can
>>> use either of the proposals here :/
>>>
>>> Essentially all the Linux IRQ<->hwirq mappings are created when the
>>> gpiochip is initialized in gpiochip_irqchip_add(). Because of that, I
>>> don't see how we can change those afterwards when the i8042 keyboard
>>> driver asks for IRQ 182. Maybe I'm missing something obvious but to me
>>> the only way to go forward is to do what this patch does and add all the
>>> GPIOs to the irqdomain (if we don't want to add a custom IRQ domain for
>>> cherryview).
>>
>> Something is very fishy here: You say that the i8042 asks for IRQ 182.
>> But surely that's a hwirq. Or is it directly poking at the ACPI table,
>> extracting a number and do a request_irq() on it? If that's the case,
>> this is a bug (or at least a severe limitation) in the i8042 driver.
> 
> Yes, it gets the number 182 from ACPI tables but that's not hwirq but
> instead it is the Linux IRQ number the cherryview-pinctrl driver has
> assigned for the GPIO in question (as far as I can tell).

But whatever number gets put there is by definition wrong. There is no
"right" number, except for something that identifies the HW connection.

> 
> This is already reported as a bug in coreboot for the particular machine
> but we need to work it around in Linux anyway, even though it may break
> again if Linux IRQ numbering changes.
> 
>> If the latter, even adding all the GPIOs to the domain do not guarantee
>> that the allocated interrupts will always be in the range you expect
>> (depending on the order of things being initialized).
>>
>> It all feels extremely fragile to me...
> 
> Yes, it is unfortunately.
> 
> There is a proper way to use GPIOs as interrupts in ACPI, namely GpioInt
> resource but it has not been used in that particular machine for some
> reason.

OK, that explains it. One thing you could try would be to allocate the
domain as a legacy one, which allows you to specify the virtual
interrupt range you require. Not sure that's any better though.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html