[alsa-devel] [PATCH] ASoC: sun4i-codec: Rework and fix headphone routing
Most of the boards have their headphone jack directly connected to the matching pins of the SoCs. Since most of the time we will have the same routing path, it makes sense to put that in the driver, and only have a property describing whether that route is enabled or not.
It also fixes the following warning messages that were seen so far: sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Left -> direct -> Headphone Jack sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Right -> direct -> Headphone Jack
Reported-by: Priit Laes plaes@plaes.org Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com --- .../devicetree/bindings/sound/sun4i-codec.txt | 9 ++++---- sound/soc/sunxi/sun4i-codec.c | 25 +++++++++++++++++----- 2 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt index 680144b74ae9..470823845698 100644 --- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt +++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt @@ -13,10 +13,10 @@ Required properties: - clock-names: should contain followings: - "apb": the parent APB clock for this controller - "codec": the parent module clock -- routing : A list of the connections between audio components. Each - entry is a pair of strings, the first being the connection's sink, - the second being the connection's source.
+Optional Properties: +- allwinner,hp-jack-attached: Indicates that the headphone jack on the + board is directly routed to the SoC pins
Example: codec: codec@01c22c00 { @@ -28,6 +28,5 @@ codec: codec@01c22c00 { clock-names = "apb", "codec"; dmas = <&dma 0 19>, <&dma 0 19>; dma-names = "rx", "tx"; - routing = "Headphone Jack", "HP Right", - "Headphone Jack", "HP Left"; + allwinner,hp-jack-attached; }; diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c index 47780552dcd0..e86b8fcede5a 100644 --- a/sound/soc/sunxi/sun4i-codec.c +++ b/sound/soc/sunxi/sun4i-codec.c @@ -568,10 +568,18 @@ static struct snd_soc_dai_link *sun4i_codec_create_link(struct device *dev, return link; };
+static const struct snd_soc_dapm_widget sun4i_codec_sink_widgets[] = { + SND_SOC_DAPM_HP("Headphone Jack", NULL), +}; + +static const struct snd_soc_dapm_route sun4i_codec_sink_routes[] = { + { "Headphone Jack", NULL, "HP Right" }, + { "Headphone Jack", NULL, "HP Left" }, +}; + static struct snd_soc_card *sun4i_codec_create_card(struct device *dev) { struct snd_soc_card *card; - int ret;
card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL); if (!card) @@ -584,10 +592,17 @@ static struct snd_soc_card *sun4i_codec_create_card(struct device *dev) card->dev = dev; card->name = "sun4i-codec";
- ret = snd_soc_of_parse_audio_routing(card, "routing"); - if (ret) { - dev_err(dev, "Failed to create our audio routing\n"); - return NULL; + /* + * FIXME: This will probably require more logic once we will + * support other sinks (for capture for example), or + * encounter more complicated setups where the + * headphone jack is not directly connected to the SoC. + */ + if (of_property_read_bool(dev->of_node, "allwinner,hp-jack-attached")) { + card->dapm_widgets = sun4i_codec_sink_widgets; + card->num_dapm_widgets = ARRAY_SIZE(sun4i_codec_sink_widgets); + card->dapm_routes = sun4i_codec_sink_routes; + card->num_dapm_routes = ARRAY_SIZE(sun4i_codec_sink_routes); }
return card;
On Sun, Oct 04, 2015 at 03:38:16PM +0200, Maxime Ripard wrote:
Most of the boards have their headphone jack directly connected to the matching pins of the SoCs. Since most of the time we will have the same routing path, it makes sense to put that in the driver, and only have a property describing whether that route is enabled or not.
What is the value in having just a dumb jack with no detection configured? It doesn't actually do anything...
It also fixes the following warning messages that were seen so far: sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Left -> direct -> Headphone Jack sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Right -> direct -> Headphone Jack
Why are these routes being added separately to adding the jack? Just remove the broken routes.
Hi Mark,
On Mon, Oct 05, 2015 at 10:44:35AM +0100, Mark Brown wrote:
On Sun, Oct 04, 2015 at 03:38:16PM +0200, Maxime Ripard wrote:
Most of the boards have their headphone jack directly connected to the matching pins of the SoCs. Since most of the time we will have the same routing path, it makes sense to put that in the driver, and only have a property describing whether that route is enabled or not.
What is the value in having just a dumb jack with no detection configured? It doesn't actually do anything...
Well, it's how it's wired on most boards. The jack is directly connected to the SoC, without any detection mechanism, not even a GPIO, so we can only assume it's always there if we want it to work properly.
It also fixes the following warning messages that were seen so far: sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Left -> direct -> Headphone Jack sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Right -> direct -> Headphone Jack
Why are these routes being added separately to adding the jack? Just remove the broken routes.
I'm not sure I understand here. The former DT bindings example was adding this route, which was broken because of the missing output widget for the headphone jack.
My patch here adds both if the DT says that the headphone jack is actually used on that board, so it should fix both issues: no broken route, and no missing widgets. right?
Maxime
On Mon, Oct 05, 2015 at 12:25:50PM +0200, Maxime Ripard wrote:
On Mon, Oct 05, 2015 at 10:44:35AM +0100, Mark Brown wrote:
On Sun, Oct 04, 2015 at 03:38:16PM +0200, Maxime Ripard wrote:
Most of the boards have their headphone jack directly connected to the matching pins of the SoCs. Since most of the time we will have the same routing path, it makes sense to put that in the driver, and only have a property describing whether that route is enabled or not.
What is the value in having just a dumb jack with no detection configured? It doesn't actually do anything...
Well, it's how it's wired on most boards. The jack is directly connected to the SoC, without any detection mechanism, not even a GPIO, so we can only assume it's always there if we want it to work properly.
Sure, but what is the point of representing this in the driver?
It also fixes the following warning messages that were seen so far: sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Left -> direct -> Headphone Jack sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Right -> direct -> Headphone Jack
Why are these routes being added separately to adding the jack? Just remove the broken routes.
I'm not sure I understand here. The former DT bindings example was adding this route, which was broken because of the missing output widget for the headphone jack.
If those warnings are being seen whatever added the routes is buggy as-is.
My patch here adds both if the DT says that the headphone jack is actually used on that board, so it should fix both issues: no broken route, and no missing widgets. right?
It's not really a scalable binding - it's a boolean for this one configuration, even adding a GPIO for detection isn't going to fit in terribly neatly. I'm trying to figure out if we even need a binding here.
participants (2)
-
Mark Brown -
Maxime Ripard