From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lrg@ti.com>
Subject: Re: [PATCH] ASoC: core: Configure pin muxing via pinctrl when registering a DAI
Date: Fri, 21 Sep 2012 17:55:11 +0300 [thread overview]
Message-ID: <505C7FCF.1050509@ti.com> (raw)
In-Reply-To: <505C68AA.7080907@ti.com>
On 09/21/2012 04:16 PM, Peter Ujfalusi wrote:
>> I would be more inclined to do this on card init time, doing it at
>> registration seems wrong as systems typically have interfaces that
>> aren't used and share pins with other functions. By the time we are
>> setting up a card we've got a good idea we actually want to use the IP
>> but at probe time that's not the case.
>
> Make sense. My first candidate to do this is the soc_probe_link_dais()
> function and to call snd_soc_configure_dai_pins() for both the cpu_dai and
> codec_dai.
If we are going to do the pinctrl mux configuration in core we should also
consider the machine driver as well.
But they tend to request the needed GPIOs in their probe before registering
the card.
Same can be true for codec drivers where they might need the mux configured
before they request the GPIOs they need.
It might be better to leave this to the drivers?
>
>> It also seems bad that we're ignoring errors, does the pinctl API not
>> stub itself out well enough.
>
> pinctrl_get_select() returns with a pointer to struct pinctrl. If the platform
> does not have CONFIG_PINCTRL enabled it will return with NULL.
> If no pinctrl has been specified for the device it will return with error
> (-ENODEV).
> Neither of these cases should be considered as error. We do print out with
> dev_info() to notify the developer, but having pinctrl mux should not be
> mandatory.
>
--
Péter
next prev parent reply other threads:[~2012-09-21 14:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-21 7:54 [PATCH] ASoC: core: Configure pin muxing via pinctrl when registering a DAI Peter Ujfalusi
2012-09-21 11:13 ` Mark Brown
2012-09-21 13:16 ` Peter Ujfalusi
2012-09-21 14:55 ` Peter Ujfalusi [this message]
2012-09-22 15:23 ` Mark Brown
2012-09-21 16:23 ` Stephen Warren
2012-09-22 15:28 ` Mark Brown
2012-09-23 3:23 ` Stephen Warren
2012-09-24 9:20 ` Linus Walleij
2012-09-24 10:17 ` Mark Brown
2012-09-24 14:37 ` Linus Walleij
2012-09-25 11:11 ` Mark Brown
2012-09-25 11:24 ` Peter Ujfalusi
2012-09-25 11:43 ` Linus Walleij
2012-09-25 11:43 ` Mark Brown
2012-09-25 11:56 ` Linus Walleij
2012-09-25 12:24 ` Mark Brown
2012-09-25 17:00 ` Stephen Warren
2012-09-24 15:41 ` Stephen Warren
2012-09-25 11:22 ` Mark Brown
2012-09-24 8:34 ` Linus Walleij
2012-09-24 10:23 ` Mark Brown
2012-09-24 15:38 ` Stephen Warren
2012-09-22 15:18 ` 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=505C7FCF.1050509@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=lrg@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).