All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fenglin Wu <fenglinw-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	Linus Walleij
	<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	collinsd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	aghayal-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	wruan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	kgunda-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
Subject: Re: [PATCH V1] pinctrl: qcom: spmi-gpio: Add support for qcom,gpios-disallowed property
Date: Tue, 25 Jul 2017 09:05:22 +0800	[thread overview]
Message-ID: <4bb5757c-44b0-c760-2d70-df0e607de0d7@codeaurora.org> (raw)
In-Reply-To: <20170724190949.y45cx4zextmvb4tn@rob-hp-laptop>

On 7/25/2017 3:09 AM, Rob Herring wrote:
>>   <prop-encoded-array>
>> +	Definition: Array of the GPIO hardware numbers corresponding to GPIOs
>> +		    which the APSS processor is not allowed to configure.
>> +		    The hardware numbers are indexed from 1.
>> +		    The interrupt resources for these GPIOs must not be defined
>> +		    in "interrupts" and "interrupt-names" properties.
>> +		    GPIOs defined in this array won't be registered as pins
>> +		    in the pinctrl device or gpios in the gpio chip.
> Isn't simply not assigning GPIOs to anything in the DT sufficient to not

Thanks for the question, Ron.
Previous implementation assumes all GPIOs are accessible from APSS
processor and it gets the total pin numbers by counting IRQs. It
registers pinctrl devices with the total pin numbers and assumes all the
pin are indexed continuously from hardware.
Current case is, some GPIOs' interrupt are not owned by APSS processor
and there would be errors when creating IRQ mapping for them. Yes, We
can exclude them from the "interrupts" property but the driver won't
shift the GPIO pad index automatically. Such as: PMI8998 has 14 GPIOs
from GPIO1 to GPIO14, and GPIO4/GPIO7/GPIO13 are not accessible from
APPS processor, we can excluded them from the interrupt assignment (in
following sample) and DON'T expect to register pins for them, but the
driver would count the IRQ numbers to 11 and register pins for
GPIO1 ~ GPIO11.
So I am adding this property "qcom,gpios-disallowed"  for these
inaccessible GPIOs then the driver would exclude them and register pins
for the right GPIO pads.

Samples:

interrupts = <0x2 0xc0 0 IRQ_TYPE_NONE>,
                 <0x2 0xc1 0 IRQ_TYPE_NONE>,
                 <0x2 0xc2 0 IRQ_TYPE_NONE>,
                 <0x2 0xc4 0 IRQ_TYPE_NONE>,
                 <0x2 0xc5 0 IRQ_TYPE_NONE>,
                 <0x2 0xc7 0 IRQ_TYPE_NONE>,
                 <0x2 0xc8 0 IRQ_TYPE_NONE>,
                 <0x2 0xc9 0 IRQ_TYPE_NONE>,
                 <0x2 0xca 0 IRQ_TYPE_NONE>,
                 <0x2 0xcb 0 IRQ_TYPE_NONE>,
                 <0x2 0xcd 0 IRQ_TYPE_NONE>;
interrupt-names = "pmi8998_gpio1", "pmi8998_gpio2",
                 "pmi8998_gpio3", "pmi8998_gpio5",
                 "pmi8998_gpio6", "pmi8998_gpio8",
                 "pmi8998_gpio9", "pmi8998_gpio10",
                 "pmi8998_gpio11", "pmi8998_gpio12",
                 "pmi8998_gpio14";
qcom,gpios-disallowed = <4 7 13>;

-- 
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Fenglin Wu <fenglinw@codeaurora.org>
To: Rob Herring <robh@kernel.org>
Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	bjorn.andersson@linaro.org,
	Linus Walleij <linus.walleij@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
	collinsd@codeaurora.org, aghayal@codeaurora.org,
	wruan@codeaurora.org, kgunda@codeaurora.org
Subject: Re: [PATCH V1] pinctrl: qcom: spmi-gpio: Add support for qcom,gpios-disallowed property
Date: Tue, 25 Jul 2017 09:05:22 +0800	[thread overview]
Message-ID: <4bb5757c-44b0-c760-2d70-df0e607de0d7@codeaurora.org> (raw)
In-Reply-To: <20170724190949.y45cx4zextmvb4tn@rob-hp-laptop>

On 7/25/2017 3:09 AM, Rob Herring wrote:
>>   <prop-encoded-array>
>> +	Definition: Array of the GPIO hardware numbers corresponding to GPIOs
>> +		    which the APSS processor is not allowed to configure.
>> +		    The hardware numbers are indexed from 1.
>> +		    The interrupt resources for these GPIOs must not be defined
>> +		    in "interrupts" and "interrupt-names" properties.
>> +		    GPIOs defined in this array won't be registered as pins
>> +		    in the pinctrl device or gpios in the gpio chip.
> Isn't simply not assigning GPIOs to anything in the DT sufficient to not

Thanks for the question, Ron.
Previous implementation assumes all GPIOs are accessible from APSS
processor and it gets the total pin numbers by counting IRQs. It
registers pinctrl devices with the total pin numbers and assumes all the
pin are indexed continuously from hardware.
Current case is, some GPIOs' interrupt are not owned by APSS processor
and there would be errors when creating IRQ mapping for them. Yes, We
can exclude them from the "interrupts" property but the driver won't
shift the GPIO pad index automatically. Such as: PMI8998 has 14 GPIOs
from GPIO1 to GPIO14, and GPIO4/GPIO7/GPIO13 are not accessible from
APPS processor, we can excluded them from the interrupt assignment (in
following sample) and DON'T expect to register pins for them, but the
driver would count the IRQ numbers to 11 and register pins for
GPIO1 ~ GPIO11.
So I am adding this property "qcom,gpios-disallowed"  for these
inaccessible GPIOs then the driver would exclude them and register pins
for the right GPIO pads.

Samples:

interrupts = <0x2 0xc0 0 IRQ_TYPE_NONE>,
                 <0x2 0xc1 0 IRQ_TYPE_NONE>,
                 <0x2 0xc2 0 IRQ_TYPE_NONE>,
                 <0x2 0xc4 0 IRQ_TYPE_NONE>,
                 <0x2 0xc5 0 IRQ_TYPE_NONE>,
                 <0x2 0xc7 0 IRQ_TYPE_NONE>,
                 <0x2 0xc8 0 IRQ_TYPE_NONE>,
                 <0x2 0xc9 0 IRQ_TYPE_NONE>,
                 <0x2 0xca 0 IRQ_TYPE_NONE>,
                 <0x2 0xcb 0 IRQ_TYPE_NONE>,
                 <0x2 0xcd 0 IRQ_TYPE_NONE>;
interrupt-names = "pmi8998_gpio1", "pmi8998_gpio2",
                 "pmi8998_gpio3", "pmi8998_gpio5",
                 "pmi8998_gpio6", "pmi8998_gpio8",
                 "pmi8998_gpio9", "pmi8998_gpio10",
                 "pmi8998_gpio11", "pmi8998_gpio12",
                 "pmi8998_gpio14";
qcom,gpios-disallowed = <4 7 13>;

-- 
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

  reply	other threads:[~2017-07-25  1:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-19  7:17 [PATCH V1] pinctrl: qcom: spmi-gpio: Add support for qcom,gpios-disallowed property fenglinw-sgV2jX0FEOL9JmXXK+q4OQ
2017-07-19  7:17 ` fenglinw
2017-07-24 19:09 ` Rob Herring
2017-07-25  1:05   ` Fenglin Wu [this message]
2017-07-25  1:05     ` Fenglin Wu
     [not found]     ` <4bb5757c-44b0-c760-2d70-df0e607de0d7-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-07-25  1:11       ` Fenglin Wu
2017-08-28 14:54 ` Shawn Guo
2017-08-29  1:03   ` Fenglin Wu
2017-08-29  1:51     ` Shawn Guo
2017-08-29  2:04       ` Fenglin Wu

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=4bb5757c-44b0-c760-2d70-df0e607de0d7@codeaurora.org \
    --to=fenglinw-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
    --cc=aghayal-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=collinsd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=kgunda-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=wruan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.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.