linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Rajendra Nayak <rnayak@codeaurora.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	LinusW <linus.walleij@linaro.org>, Andy Gross <agross@kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Maulik Shah <mkshah@codeaurora.org>,
	Lina Iyer <ilina@codeaurora.org>
Subject: Re: [PATCH v2] pinctrl: qcom: sc7180: Make gpio28 non wakeup capable for google,lazor
Date: Mon, 6 Jul 2020 13:24:18 -0700	[thread overview]
Message-ID: <CAD=FV=WyhJ6g0DZS=ysT-AyXJoiRX=UFE9fXY2NEHfuUHYUXCQ@mail.gmail.com> (raw)
In-Reply-To: <1593762506-32680-1-git-send-email-rnayak@codeaurora.org>

Hi,

On Fri, Jul 3, 2020 at 12:49 AM Rajendra Nayak <rnayak@codeaurora.org> wrote:
>
> The PDC irqchip driver currently does not handle dual-edge interrupts,
> and we have google,lazor board with sc7180 designed to configure gpio28
> as a dual-edge interrupt. This interrupt is however not expected to be
> wakeup capable on this board, so an easy way to fix this, seems to be to
> make this gpio non wakeup capable and let TLMM handle it (which is capable
> of handling dual-edge irqs)
>
> To be able to do so only on this board, so other boards designed with
> this SoC can continue to use gpio28 as a wakeup capable one, make a
> copy of msm_gpio_wakeirq_map for lazor and remove gpio28 from the
> list.
>
> Reported-by: Jimmy Cheng-Yi Chiang <cychiang@google.com>
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
> ---
>  drivers/pinctrl/qcom/pinctrl-sc7180.c | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-sc7180.c b/drivers/pinctrl/qcom/pinctrl-sc7180.c
> index 1b6465a..0668933 100644
> --- a/drivers/pinctrl/qcom/pinctrl-sc7180.c
> +++ b/drivers/pinctrl/qcom/pinctrl-sc7180.c
> @@ -1135,7 +1135,24 @@ static const struct msm_gpio_wakeirq_map sc7180_pdc_map[] = {
>         {117, 114}, {118, 119},
>  };
>
> -static const struct msm_pinctrl_soc_data sc7180_pinctrl = {
> +/* Dropped gpio28 from the map for the google,lazor board */
> +static const struct msm_gpio_wakeirq_map sc7180_lazor_pdc_map[] = {
> +       {0, 40}, {3, 50}, {4, 42}, {5, 70}, {6, 41}, {9, 35},
> +       {10, 80}, {11, 51}, {16, 20}, {21, 55}, {22, 90}, {23, 21},
> +       {24, 61}, {26, 52}, {30, 100}, {31, 33}, {32, 81},
> +       {33, 62}, {34, 43}, {36, 91}, {37, 53}, {38, 63}, {39, 72},
> +       {41, 101}, {42, 7}, {43, 34}, {45, 73}, {47, 82}, {49, 17},
> +       {52, 109}, {53, 102}, {55, 92}, {56, 56}, {57, 57}, {58, 83},
> +       {59, 37}, {62, 110}, {63, 111}, {64, 74}, {65, 44}, {66, 93},
> +       {67, 58}, {68, 112}, {69, 32}, {70, 54}, {72, 59}, {73, 64},
> +       {74, 71}, {78, 31}, {82, 30}, {85, 103}, {86, 38}, {87, 39},
> +       {88, 45}, {89, 46}, {90, 47}, {91, 48}, {92, 60}, {93, 49},
> +       {94, 84}, {95, 94}, {98, 65}, {101, 66}, {104, 67}, {109, 104},
> +       {110, 68}, {113, 69}, {114, 113}, {115, 108}, {116, 121},
> +       {117, 114}, {118, 119},
> +};
> +
> +static struct msm_pinctrl_soc_data sc7180_pinctrl = {
>         .pins = sc7180_pins,
>         .npins = ARRAY_SIZE(sc7180_pins),
>         .functions = sc7180_functions,
> @@ -1151,6 +1168,10 @@ static const struct msm_pinctrl_soc_data sc7180_pinctrl = {
>
>  static int sc7180_pinctrl_probe(struct platform_device *pdev)
>  {
> +       if (of_machine_is_compatible("google,lazor")) {
> +               sc7180_pinctrl.wakeirq_map = sc7180_lazor_pdc_map;
> +               sc7180_pinctrl.nwakeirq_map = ARRAY_SIZE(sc7180_lazor_pdc_map);
> +       }

As much as I want patches landed and things working, the above just
doesn't feel like a viable solution.  I guess it could work as a short
term hack but it's going to become untenable pretty quickly.  As we
have more variants of this we're going to have to just keep piling
more machines in here, right?  ...this is also already broken for us
because not all boards will have the "google,lazor" compatible.  From
the current Chrome OS here are the compatibles for various revs/SKUs

compatible = "google,lazor-rev0", "qcom,sc7180";
compatible = "google,lazor-rev0-sku0", "qcom,sc7180";
compatible = "google,lazor", "qcom,sc7180";
compatible = "google,lazor-sku0", "qcom,sc7180";
compatible = "google,lazor-rev2", "qcom,sc7180";

...so of the 5 boards you'll only match one of them.


Maybe I'm jumping into a situation again where I'm ignorant since I
haven't followed all the prior conversation, but is it really that
hard to just add dual edge support to the PDC irqchip driver?  ...or
maybe it's just easier to change the pinctrl driver to emulate dual
edge itself and that can work around the problem in the PDC?  There
seem to be a few samples you could copy from:

$ git log --oneline --no-merges --grep=emulate drivers/pinctrl/
3221f40b7631 pinctrl: mediatek: emulate GPIO interrupt on both-edges
5a92750133ff pinctrl: rockchip: emulate both edge triggered interrupts

...and if you look at those two commits they refer to other examples.
The mediatek one says:

> This follows an example of drivers/gpio/gpio-mxc.c.

...and the Rockchip one says:

> implement a solution similar to pinctrl-coh901

That means you have at least 4 samples to look at?


-Doug

  reply	other threads:[~2020-07-06 20:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-03  7:48 [PATCH v2] pinctrl: qcom: sc7180: Make gpio28 non wakeup capable for google,lazor Rajendra Nayak
2020-07-06 20:24 ` Doug Anderson [this message]
2020-07-06 20:38   ` Bjorn Andersson
2020-07-07  4:52     ` Rajendra Nayak
2020-07-07 23:03       ` Doug Anderson
2020-07-08  1:13         ` Doug Anderson
2020-07-08  5:29         ` Maulik Shah
2020-07-08 13:42           ` Doug Anderson
2020-07-08 21:19             ` Doug Anderson

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='CAD=FV=WyhJ6g0DZS=ysT-AyXJoiRX=UFE9fXY2NEHfuUHYUXCQ@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=ilina@codeaurora.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkshah@codeaurora.org \
    --cc=rnayak@codeaurora.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).