From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Timur Tabi <timur@codeaurora.org>,
Andy Gross <andy.gross@linaro.org>,
David Brown <david.brown@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH] pinctrl: qcom: qdf2xxx: expose only some GPIO pins
Date: Wed, 28 Jun 2017 12:12:04 -0700 [thread overview]
Message-ID: <20170628191204.GP18666@tuxbook> (raw)
In-Reply-To: <CACRpkdZeDjS_g27=1e7uCmFpjnqX+sDSu5G2VAuwFr_GJW1mug@mail.gmail.com>
On Fri 23 Jun 05:33 PDT 2017, Linus Walleij wrote:
> On Thu, Jun 22, 2017 at 10:54 PM, Timur Tabi <timur@codeaurora.org> wrote:
>
> > On Qualcomm Technologies QDF2xxx platforms, only a subset of the GPIOs
> > are actually available to the HLOS. The others are blocked by the XPU,
> > and any attempt to access them will cause an XPU violation that halts
> > the system.
>
> That's a bummer. Looking for Björn's review on this patch.
>
The TLMM block on this platform has N gpios, regardless of the XPU
configuration. The ACPI table provides the kernel with a list of
available "logical" GPIOs based on some system specification (or
reference design perhaps?).
I have not seen the Qualcomm server platforms, but I imagine that
customers can alter this list.
I think the numbering of the GPIOs should be that of the TLMM and the
"logical" names should be populated from ACPI by using gpio_chip->names.
The question left is how to represent the XPU locked gpios - a problem
we do share with in the mobile TLMM drivers.
It seems that if we extend the msm_pingroup with a flag to carry the XPU
lock information and then implement pinmux_ops->request() and deny any
requests on the locked pins, we should cover all[*] the normal GPIO code
paths.
[*] Except the reported case of gpiochip_add_data() looping over all
pins and calling get_direction() without first requesting the pin.
@Linus, do you see any flaws in this scheme?
PS. gpiochip_generic_request() ends up calling pinmux_ops->request()
Regards,
Bjorn
next prev parent reply other threads:[~2017-06-28 19:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-22 20:54 [PATCH] pinctrl: qcom: qdf2xxx: expose only some GPIO pins Timur Tabi
2017-06-23 12:33 ` Linus Walleij
2017-06-23 13:28 ` Timur Tabi
2017-06-28 19:12 ` Bjorn Andersson [this message]
2017-06-28 19:23 ` Timur Tabi
2017-06-28 22:38 ` Timur Tabi
2017-06-29 19:37 ` Timur Tabi
2017-06-29 21:49 ` Bjorn Andersson
2017-06-29 22:10 ` 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=20170628191204.GP18666@tuxbook \
--to=bjorn.andersson@linaro.org \
--cc=andy.gross@linaro.org \
--cc=david.brown@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=timur@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).