[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c747043d-c69e-4153-f2ca-16f1fc3063c2@codeaurora.org>
Date: Tue, 7 Jul 2020 10:22:25 +0530
From: Rajendra Nayak <rnayak@...eaurora.org>
To: Bjorn Andersson <bjorn.andersson@...aro.org>,
Doug Anderson <dianders@...omium.org>
Cc: LinusW <linus.walleij@...aro.org>, Andy Gross <agross@...nel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Maulik Shah <mkshah@...eaurora.org>,
Lina Iyer <ilina@...eaurora.org>
Subject: Re: [PATCH v2] pinctrl: qcom: sc7180: Make gpio28 non wakeup capable
for google,lazor
[]..
>>> @@ -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.
>> 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
>>
>
> pinctrl-msm already supports emulating dual edge, but my understanding
> was that the problem lies in that somehow this emulation would have to
> be tied to or affect the PDC driver?
yes, thats correct, pinctrl-msm already supports it, the problem lies
in the fact that PDC does not. This patch, infact was trying to fix the
issue by removing all PDC involvement for gpio28 and making pinctrl-msm
in charge of it.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Powered by blists - more mailing lists