linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>,
	Grant Likely <glikely@secretlab.ca>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Mark Brown <broonie@kernel.org>, Tero Kristo <t-kristo@ti.com>,
	Maxime Ripard <mripard@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>
Subject: Re: [RFC 0/2] gpio: Support for shared GPIO lines on boards
Date: Tue, 19 Nov 2019 17:01:10 +0200	[thread overview]
Message-ID: <df10bfc0-0ad5-36f5-ea68-9fee82cd2c5a@ti.com> (raw)
In-Reply-To: <56916577-8d39-f98f-9fd6-2fdc6e1e0023@ti.com>

Hi Linus,

On 19/11/2019 10.34, Peter Ujfalusi wrote:
>> So begin with creating a way to pull the shared handling of
>> regulators into gpiolib with these clearly cut semantics
>> delete the NONEXCLUSIVE thing and then when you are
>> done with that exploit the same
>> infrastructure for GPIO reset.
> 
> The logic is relatively simple, 229 lines in gpio-shared, but moving
> that into core will explode things a bit and going to add more
> complexity to all gpio lines.
> For one, we must maintain a list of clients requesting the line to be
> able to do proper refcounting and this needs to be done for all pins as
> we don't know beforehand that the given line is going to be shared.
> 
> Or add gpio-shared block similar to gpio-hog to prepare a given line for
> sharing? I think this might be a better thing to do and some of the code
> from gpio-shared.c can be reused.

I had some time today and now have a working support for shared GPIOs in
the gpio core.

Works fine with regulators and with my board which have two ocm3168a
codec with shared reset GPIO.

There are couple of things initially not going to work, like supporting
clients with different GPIO_ACTIVE_HIGH/LOW as we have only one
gpio_desc which got it's GPIO_ACTIVE_* form the gpio-shared child.

The means that all clients has to have the same GPIO_ACTIVE_* as how the
gpio-shared child is configured:

gpio1 {
	p00 {
		gpio-shared;
		/* raw level high is refcounted */
		gpios = <0 GPIO_ACTIVE_HIGH>;
		/* Initially set the gpio line to raw level high */
		output-high;
		line-name = "CODEC RESET";
	};
};

now clients can:
...
enable-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
...
enable-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
...

I'm reusing some of the gpio-hog code for this from gpiolib-of.c

For supporting different GPIO_ACTIVE_* on the client side might be
tricky as we might need to create dummy gpio_desc for each client and
put them on a list for the shared gpio_desc.

In any case I try to clean up the patch and add some documentation and
send it for review as RFC in couple of days.



- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

  reply	other threads:[~2019-11-19 15:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-30 11:45 [RFC 0/2] gpio: Support for shared GPIO lines on boards Peter Ujfalusi
2019-10-30 11:45 ` [RFC 1/2] dt-bindings: gpio: Add binding document for shared GPIO Peter Ujfalusi
2019-10-30 11:45 ` [RFC 2/2] gpio: Add new driver for handling 'shared' gpio lines on boards Peter Ujfalusi
2019-10-30 12:03 ` [RFC 0/2] gpio: Support for shared GPIO " Peter Ujfalusi
2019-11-01 15:56 ` Linus Walleij
2019-11-08 11:21   ` Peter Ujfalusi
2019-11-12  8:17     ` Peter Ujfalusi
2019-11-13 17:06     ` Linus Walleij
2019-11-19  8:34       ` Peter Ujfalusi
2019-11-19 15:01         ` Peter Ujfalusi [this message]
2019-11-21 14:47         ` Linus Walleij
2019-11-22 12:49           ` Peter Ujfalusi

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=df10bfc0-0ad5-36f5-ea68-9fee82cd2c5a@ti.com \
    --to=peter.ujfalusi@ti.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=glikely@secretlab.ca \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mripard@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=rnayak@codeaurora.org \
    --cc=robh+dt@kernel.org \
    --cc=t-kristo@ti.com \
    /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).