All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"Antoine Ténart" <antoine.tenart@free-electrons.com>
Subject: Re: [RFI] pinmux: pin group ownership
Date: Tue, 12 May 2015 12:53:29 +0100	[thread overview]
Message-ID: <5551E9B9.5030208@nvidia.com> (raw)
In-Reply-To: <CACRpkdY_Le063_hA4+kKMD8NFMFdVVB89g8YeCsWnoTg4dADxw@mail.gmail.com>

Hi Linus,

On 12/05/15 12:30, Linus Walleij wrote:
> On Fri, May 8, 2015 at 5:01 PM, Jon Hunter <jonathanh@nvidia.com> wrote:
> 
>> Looking at this change, if pinmux_enable_setting() is called but
>> .get_group_pins() is not defined, then num_pins will be 0. If this is
>> the case then pin_request() is not called to allocate the pins in the
>> group (because no pins are defined for the group). So that makes sense.
>>
>> However, I am trying to understand then, if the pinmux driver will
>> protect against another device attempting to use the same group for a
>> different function when already in-use?
>>
>> For example, if you have the two functions i2c0 and uart0 mapped to pin
>> group A, but no pins are defined for group A, will pinmux prevent
>> someone attempting to configure both functions on the same group at the
>> same time?
>>
>> I did not see anywhere that sets a usecount for a group (ie. allocates
>> the group) but only for a pin.
> 
> The usecount are done on individual pins, not groups.

Thanks for confirming. With regard to the change
e5b3b2d9ed202697a937c282f9c4d93b1e3e0848, IIUC then this allows devices
not to define any pins but just groups. Probably because from some
devices (such as berlin) pinmux'ing is always done at the group level.
If this is the case then it would appear that there is no protection
against two devices trying to use the same group. Is this correct?

> In the devel tree you can even set the pinmux_ops.strict to disallow
> GPIOs and other functions to share a pin.

Thanks, however, I don't think that this helps in this case because
pin_request() would not be called by pinmux_enable_setting() as num_pins
= 0.

Cheers
Jon

  reply	other threads:[~2015-05-12 11:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-08 15:01 [RFI] pinmux: pin group ownership Jon Hunter
2015-05-12 11:30 ` Linus Walleij
2015-05-12 11:53   ` Jon Hunter [this message]
2015-05-12 12:10     ` Linus Walleij
2015-05-12 12:55       ` Jon Hunter

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=5551E9B9.5030208@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=antoine.tenart@free-electrons.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.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.