Re: STM32MP1 level triggered interrupts

[Marc Zyngier <maz@kernel.org>]

On 2020-02-05 11:53, Marek Vasut wrote:
> On 2/5/20 12:42 PM, Marc Zyngier wrote:
>> On 2020-01-28 18:32, Marek Vasut wrote:
>>> On 1/24/20 10:24 AM, Marc Zyngier wrote:
>>>> On 2020-01-24 09:17, Alexandre Torgue wrote:
>>>>> On 1/23/20 11:21 PM, Marek Vasut wrote:
>>>> 
>>>> [...]
>>>> 
>>>>>> But I still wonder, what is the purpose of the EXTImux in that 
>>>>>> SoC?
>>>>>> Shouldn't that permit routing GPIOs directly into GIC SPIs, which
>>>>>> would
>>>>>> then permit detecting at least level-high interrupts ?
>>>>>> 
>>>>> 
>>>>> For this SoC, EXTI block detects external line edges and rises a 
>>>>> GIC
>>>>> SPI interrupt. This EXTi block is mainly used to handle HW events 
>>>>> like
>>>>> buttons, clocks ... So first issue seems more to be a design issue
>>>>> (your design doesn't fit with MP1 datasheet).
>>>>> 
>>>>> Now, let's find a solution. I'll have a look on your proposition:
>>>>> "check the line in EOI callback and retrig".
>>>>> 
>>>>> Marc, this kind a solution could be acceptable on your side ?
>>>> 
>>>> It will depend on the nature of the hack you will have to put in 
>>>> there.
>>>> If it is 100% reliable, why not? Anything short of that, probably 
>>>> not.
>>> 
>>> I had another look into this, and what we would end up is some sort 
>>> of
>>> phandle from exti to all the gpioX nodes in DT, would that be OK ?
>>> However, if we do that, then we will have the pinctrl controller 
>>> (which
>>> has the gpio banks as subnodes) require the exti through a phandle 
>>> and
>>> exti require the gpio banks through a phandle, so we end up with some
>>> sort of cyclic dependency there.
>>> 
>>> So we would need to somehow have exti lazily deal with it's gpioX
>>> controller phandles only when someone requests level interrupt ? That
>>> would probably do.
>> 
>> TBH, I don't have much of an opinion here. If you can deal with the
>> plumbing
>> that's required to make this thing work reliably, then why not?
>> 
>> What I insist on is that the sampling/retriggering is made 100% 
>> reliable.
>> I'd prefer we don't offer the functionality if it there is any doubt
>> about it.
> 
> That question was more in the direction of ST, to see how it fits in
> their design/plans. I would hate to work on something only to have it
> rejected because ST developed something else in parallel.

I think this is more of a "whoever needs it writes it" case, and ST
obviously didn't care much about supporting external level interrupts.

So if you have the need *and* a clear idea on how to make it work, 
please
post patches. If ST wakes up and wants to chime in, LKML is the right
forum for having the discussion.

Thanks,

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel