From: Marc Zyngier <maz@kernel.org>
To: Marek Vasut <marex@denx.de>
Cc: "Alexandre Torgue" <alexandre.torgue@st.com>,
"Patrick Delaunay" <patrick.delaunay@st.com>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
linux-stm32@st-md-mailman.stormreply.com,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>
Subject: Re: STM32MP1 level triggered interrupts
Date: Wed, 05 Feb 2020 11:42:46 +0000 [thread overview]
Message-ID: <dcbb8f0447f2aa75f0cec6f420310b21@kernel.org> (raw)
In-Reply-To: <5e1c419c-b141-52f6-88f1-ee3ab8219a4e@denx.de>
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.
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
next prev parent reply other threads:[~2020-02-05 11:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-20 18:32 STM32MP1 level triggered interrupts Marek Vasut
2020-01-21 17:12 ` Alexandre Torgue
2020-01-21 17:21 ` Marc Zyngier
2020-01-22 16:56 ` Alexandre Torgue
2020-01-21 17:41 ` Marek Vasut
2020-01-22 17:19 ` Alexandre Torgue
2020-01-22 19:29 ` Marek Vasut
2020-01-23 8:27 ` Alexandre Torgue
2020-01-23 9:22 ` Marc Zyngier
2020-01-23 10:12 ` Uwe Kleine-König
2020-01-23 10:44 ` Marc Zyngier
2020-01-23 10:52 ` Uwe Kleine-König
2020-01-23 11:18 ` Marc Zyngier
2020-01-23 22:21 ` Marek Vasut
2020-01-24 9:17 ` Alexandre Torgue
2020-01-24 9:24 ` Marc Zyngier
2020-01-28 18:32 ` Marek Vasut
2020-02-05 10:26 ` Marek Vasut
2020-02-05 11:42 ` Marc Zyngier [this message]
2020-02-05 11:53 ` Marek Vasut
2020-02-05 12:32 ` Marc Zyngier
2020-02-05 15:36 ` Alexandre TORGUE
2020-02-06 2:00 ` Marek Vasut
2020-01-24 12:25 ` Marek Vasut
2020-01-24 9:21 ` Marc Zyngier
2020-01-24 9:35 ` Alexandre Torgue
2020-01-23 22:21 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dcbb8f0447f2aa75f0cec6f420310b21@kernel.org \
--to=maz@kernel.org \
--cc=alexandre.torgue@st.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=marex@denx.de \
--cc=mcoquelin.stm32@gmail.com \
--cc=patrick.delaunay@st.com \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.