linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).