From: Timur Tabi <timur@codeaurora.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
thierry.reding@gmail.com, david.brown@linaro.org,
andy.gross@linaro.org,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Varadarajan Narayanan <varada@codeaurora.org>,
Archit Taneja <architt@codeaurora.org>
Subject: Re: [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
Date: Wed, 20 Dec 2017 19:06:56 -0600 [thread overview]
Message-ID: <38463c81-eeab-85dc-d197-6081ce1d1130@codeaurora.org> (raw)
In-Reply-To: <20171221003947.GJ7997@codeaurora.org>
On 12/20/17 6:39 PM, Stephen Boyd wrote:
> I don't see how it hurts to treat it generically. Presumably
> that's the way it will be done on ACPI platforms going forward?
> No need to tie it to some ACPI HID.
But it is tied to a HID. The "num-gpios" and "gpios" properties belong
to a specific HID. Someone could create a new HID with different
properties, and then what? That's why I want all the ACPI stuff in the
client driver.
At this point I don't really care any more about what the patches look
like, but I really do think that putting the ACPI code in pinctrl-msm is
a bad idea.
We're debating adding support for multiple TLMMs, and we may create a
new HID for that, so that we can define all pins on all TLMMs in one
device. We would need to create a new HID and new DSDs to go with it.
> I'm trying to resolve everything at once: gpios, pinctrl pins,
> and irqs exposed by the TLMM hardware. The value is that we solve
> it all, once, now.
Keep in mind that I am now in vacation, and so I won't be able to submit
any more patches for a while.
> The DT binding can also be resolved at the
> same time, so when we need to express this in DT it's already
> done.
Ok.
> Otherwise, something can request irqs from the irqdomain
> even if the irq can't be enabled, or it can try to mux the pin to
> some other function, even if the function selection can't be
> configured.
Is it possible to request an IRQ for a pin if the pin itself can't be
requested?
> Boiling everything down into the irq valid mask should cover all
> these cases, and not require us to strip const from all the data
> in the non-ACPI pinctrl drivers to replace the value in the npins
> field at runtime.
Ok.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2017-12-21 1:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 18:30 [PATCH 0/3] [v10] pinctrl: qcom: add support for sparse GPIOs Timur Tabi
2017-12-13 18:30 ` [PATCH 1/3] [v2] Revert "gpio: set up initial state from .get_direction()" Timur Tabi
2017-12-13 22:37 ` Stephen Boyd
2017-12-13 18:30 ` [PATCH 2/3] [v8] pinctrl: qcom: disable GPIO groups with no pins Timur Tabi
2017-12-13 22:37 ` Stephen Boyd
2017-12-13 18:30 ` [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002 Timur Tabi
2017-12-13 23:01 ` Stephen Boyd
2017-12-13 23:09 ` Timur Tabi
2017-12-19 1:18 ` Timur Tabi
2017-12-19 2:39 ` Stephen Boyd
2017-12-19 4:47 ` Timur Tabi
2017-12-19 19:10 ` Stephen Boyd
2017-12-19 19:27 ` Timur Tabi
2017-12-19 20:30 ` Stephen Boyd
2017-12-19 20:32 ` Timur Tabi
2017-12-19 22:56 ` Timur Tabi
2017-12-20 2:26 ` Stephen Boyd
2017-12-20 4:05 ` Timur Tabi
2017-12-20 8:15 ` Stephen Boyd
2017-12-20 17:46 ` Timur Tabi
2017-12-21 0:39 ` Stephen Boyd
2017-12-21 1:06 ` Timur Tabi [this message]
2017-12-22 1:46 ` Stephen Boyd
2018-01-04 15:46 ` Timur Tabi
2018-01-04 16:04 ` Andy Shevchenko
2018-01-09 13:46 ` Linus Walleij
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=38463c81-eeab-85dc-d197-6081ce1d1130@codeaurora.org \
--to=timur@codeaurora.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.gross@linaro.org \
--cc=architt@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=david.brown@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=sboyd@codeaurora.org \
--cc=thierry.reding@gmail.com \
--cc=varada@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).