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.
WARNING: multiple messages have this Message-ID (diff)
From: timur@codeaurora.org (Timur Tabi)
To: linux-arm-kernel@lists.infradead.org
Subject: [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: 52+ 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 ` 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 18:30 ` Timur Tabi
2017-12-13 22:37 ` Stephen Boyd
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 18:30 ` Timur Tabi
2017-12-13 22:37 ` Stephen Boyd
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 18:30 ` Timur Tabi
2017-12-13 23:01 ` Stephen Boyd
2017-12-13 23:01 ` Stephen Boyd
2017-12-13 23:09 ` Timur Tabi
2017-12-13 23:09 ` Timur Tabi
2017-12-19 1:18 ` Timur Tabi
2017-12-19 1:18 ` Timur Tabi
2017-12-19 2:39 ` Stephen Boyd
2017-12-19 2:39 ` Stephen Boyd
2017-12-19 4:47 ` Timur Tabi
2017-12-19 4:47 ` Timur Tabi
2017-12-19 19:10 ` Stephen Boyd
2017-12-19 19:10 ` Stephen Boyd
2017-12-19 19:27 ` Timur Tabi
2017-12-19 19:27 ` Timur Tabi
2017-12-19 20:30 ` Stephen Boyd
2017-12-19 20:30 ` Stephen Boyd
2017-12-19 20:32 ` Timur Tabi
2017-12-19 20:32 ` Timur Tabi
2017-12-19 22:56 ` Timur Tabi
2017-12-19 22:56 ` Timur Tabi
2017-12-20 2:26 ` Stephen Boyd
2017-12-20 2:26 ` Stephen Boyd
2017-12-20 4:05 ` Timur Tabi
2017-12-20 4:05 ` Timur Tabi
2017-12-20 8:15 ` Stephen Boyd
2017-12-20 8:15 ` Stephen Boyd
2017-12-20 17:46 ` Timur Tabi
2017-12-20 17:46 ` Timur Tabi
2017-12-21 0:39 ` Stephen Boyd
2017-12-21 0:39 ` Stephen Boyd
2017-12-21 1:06 ` Timur Tabi [this message]
2017-12-21 1:06 ` Timur Tabi
2017-12-22 1:46 ` Stephen Boyd
2017-12-22 1:46 ` Stephen Boyd
2018-01-04 15:46 ` Timur Tabi
2018-01-04 15:46 ` Timur Tabi
2018-01-04 16:04 ` Andy Shevchenko
2018-01-04 16:04 ` Andy Shevchenko
2018-01-09 13:46 ` Linus Walleij
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.