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 13:55:42 +0100	[thread overview]
Message-ID: <5551F84E.9040602@nvidia.com> (raw)
In-Reply-To: <CACRpkdYMgu-_52gYT54W0dSLXap9spDuaz35rcnrx0mGvu=B2Q@mail.gmail.com>


On 12/05/15 13:10, Linus Walleij wrote:
> On Tue, May 12, 2015 at 1:53 PM, Jon Hunter <jonathanh@nvidia.com> wrote:
> 
> [Me]:
>>> 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.
> 
> That's correct.
> 
>> 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?
> 
> Seems like so... darn you found a loophole.

Ok, I was hoping I had missed something, so thanks for confirming.

>>> 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.
> 
> You're right.
> 
> The implementation assumes collissions happen at pin level,
> not group level.
> 
> I wonder if there are enough devices out there with this problem
> that we need to check for it?

Probably not many, indeed.

> If so I would opt to create a bool .group_only property
> on pinmux_ops like we created .strict so that we can
> avoid all pin-specific code on such pin controllers.
> 
> But I don't know it it's worth it for these few pin controllers :/
> 
> On the U300 there is only group selection, but the datasheet
> helpfully defined all pins anyway so I could handle collissions
> on the pin level. This is the ideal solution if possible.

Yes, I agree registering all pins would be ideal, however, I could see
that this may seem unnecessary for some devices.

Thanks for the info.

Cheers
Jon

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

      reply	other threads:[~2015-05-12 12:55 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
2015-05-12 12:10     ` Linus Walleij
2015-05-12 12:55       ` Jon Hunter [this message]

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=5551F84E.9040602@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.