Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <1593762506-32680-1-git-send-email-rnayak@codeaurora.org>
 <CAD=FV=WyhJ6g0DZS=ysT-AyXJoiRX=UFE9fXY2NEHfuUHYUXCQ@mail.gmail.com>
 <20200706203805.GS388985@builder.lan> <c747043d-c69e-4153-f2ca-16f1fc3063c2@codeaurora.org>
 <CAD=FV=Xs9Z37hv=CPgLEALoSoX=Uyir0s=ker=YKecA+Lhy1Qg@mail.gmail.com>
In-Reply-To: <CAD=FV=Xs9Z37hv=CPgLEALoSoX=Uyir0s=ker=YKecA+Lhy1Qg@mail.gmail.com>
From:   Doug Anderson <dianders@chromium.org>
Date:   Tue, 7 Jul 2020 18:13:33 -0700
Message-ID: <CAD=FV=WH_SkmbYeF9Bif-sw9=nKGbDg869AVC_wg8S_TH5V_HA@mail.gmail.com>
Subject: Re: [PATCH v2] pinctrl: qcom: sc7180: Make gpio28 non wakeup capable
 for google,lazor
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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

On Tue, Jul 7, 2020 at 4:03 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Mon, Jul 6, 2020 at 9:52 PM Rajendra Nayak <rnayak@codeaurora.org> wrote:
> >
> >
> > []..
> >
> > >>> @@ -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.
> > >
> > > I second that.
> > >
> > >> 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
> >
> > FWIK, this is really a PDC hardware issue (with the specific IP rev that exists
> > on sc7180) so working it around in SW could get ugly.
>
> Ugh.  I guess it's ugly because the workaround would need to be in the
> PDC driver but to properly do the workaround you need to be able to
> read the state of the pin from the PDC driver?  ...and I guess you
> can't do that with the PDC register space so you'd either need to
> violate a layer or 3 of abstraction and snarf into the GPIO register
> space from the PDC driver or you'd have to provide some sort of API
> access from the PDC back down to the GPIO driver?
>
> --
>
> Actually, though, I'm still not sure why this would need to be in the
> PDC driver.  Sure, you can't just magically re-use the existing
> dual-edge emulation in pinctrl-msm.c, but you can add some new
> dual-edge emulation for when your parent handles your interrupts,
> can't you?  As per usually, I'm talking out of my rear end, but I
> sorta imagine:
>
> 1. At the head of msm_gpio_irq_set_type() if you detect that
> "skip_wake_irqs" is set and you're on an SoC with this hardware errata
> then you do a loop much like the one in
> msm_gpio_update_dual_edge_pos() except that instead of changing the
> polarity with msm_writel_intr_cfg() you change the polarity with
> "irq_chip_set_type_parent()".
>
> 2. At the head of msm_gpio_irq_ack() you make the same function call
> if "skip_wake_irqs" is set and you're on an SoC with this hardware
> errata.
>
> It doesn't feel all that ugly to me, assuming I'm understanding it
> correctly.  ...or maybe you can tell me why it'd be harder than that?

So I REALLY don't know what I'm doing and this is very rough and
probably all sorts of illegal (maybe?), but in the limited testing I
was able to do it seemed to work:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2285815
WIP: proof of concept workaround for PDC wakeup problem

If there's anything worthwhile to steal from that, please feel free
and post your own patch based on it.  :-)

-Doug