[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdatfPK8r-wttDJ=ty--2T7AiW8YiAu6kqKN6FQTf9R23w@mail.gmail.com>
Date: Thu, 24 May 2018 09:37:48 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Sean Wang <sean.wang@...iatek.com>
Cc: Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Matthias Brugger <matthias.bgg@...il.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@...ts.infradead.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 2/7] pinctrl: mediatek: refactor EINT related code for
all MediaTek pinctrl can fit
On Sun, May 20, 2018 at 7:01 PM, <sean.wang@...iatek.com> wrote:
> From: Sean Wang <sean.wang@...iatek.com>
>
> This patch is in preparation for adding EINT support to MT7622 pinctrl,
> and the refactoring doesn't alter any existent logic.
>
> A reason we have to refactor EINT code pieces into a generic way is that
> currently, they're tightly coupled with a certain type of MediaTek pinctrl
> would cause a grown in a very bad way as there is different types of
> pinctrl devices getting to join.
>
> Therefore, it is an essential or urgent thing that EINT code pieces are
> refactored to eliminate any dependencies across GPIO and EINT as possible.
>
> Additional structure mtk_eint_[xt, hw, regs] are being introduced for
> indicating how maps being designed between GPIO and EINT hw number, how to
> set and get GPIO state for a certain EINT pin, what characteristic on a
> EINT device is present on various SoCs.
>
> Signed-off-by: Sean Wang <sean.wang@...iatek.com>
Patch applied.
Yours,
Linus Walleij
Powered by blists - more mailing lists