From: John Keeping <john@metanate.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Daniel Beer <daniel.beer@igorinstitute.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] ASoC: tas5805m: fix pdn polarity
Date: Thu, 10 Mar 2022 20:09:42 +0000 [thread overview]
Message-ID: <YipbBti4yeq2HzCe@donbot> (raw)
In-Reply-To: <YikiXAseSiODXfrD@sirena.org.uk>
On Wed, Mar 09, 2022 at 09:55:40PM +0000, Mark Brown wrote:
> On Wed, Mar 09, 2022 at 08:16:07PM +0000, John Keeping wrote:
> > On Wed, Mar 09, 2022 at 04:28:30PM +0000, Mark Brown wrote:
>
> > > I think the device tree binding needs to be clarified here to be
> > > explicit about this since there's obviously some room for user confusion
> > > here. We can probably get away with a change at this point since it's
> > > not hit a release but we do need to try to avoid the situation where any
> > > other implementations use active high polarity for the bindings.
>
> > Taking a quick survey of the other devices that have a pdn-gpios
> > property:
>
> > - tvp5150 is correct with the driver setting 0 to make the device active
>
> > - tas571x also sets 0 to make the device active
>
> > - ak4375 uses the opposite sense setting PDN = 1 to make the device
> > active; this has no in-tree users and was merged as part of v5.17-rc1
> > so it's not in a released kernel yet
>
> Sure, I still think it would be good to update the binding document to
> clarify things as part of your patch - the binding currently just has it
> as the "pdn" pin not the /pdn pin or anything.
I've been thinking about this but I can't really think what to say.
tas571x's binding says:
GPIO specifier for the TAS571x's active low powerdown line
Is that the sort of wording you have in mind?
To me it seems like a general principle that the GPIO_ACTIVE_{HIGH,LOW}
flags should be used to indicate how the pin works so that the driver
consistently uses logical levels regardless of how the hardware is
wired.
From the driver point of view pdn-gpios is effectively reset-gpios by
another name and it's pretty consistent that setting a reset GPIO to 1
means the device is inaccessible.
Maybe this just means I'm approaching this "down" from the software
abstraction more than "up" from the hardware.
next prev parent reply other threads:[~2022-03-10 20:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 13:56 [PATCH v2] ASoC: tas5805m: fix pdn polarity John Keeping
2022-03-09 15:56 ` Mark Brown
2022-03-09 16:19 ` John Keeping
2022-03-09 16:28 ` Mark Brown
2022-03-09 20:16 ` John Keeping
2022-03-09 21:55 ` Mark Brown
2022-03-10 20:09 ` John Keeping [this message]
2022-03-11 12:03 ` Mark Brown
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=YipbBti4yeq2HzCe@donbot \
--to=john@metanate.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=daniel.beer@igorinstitute.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.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