| Message ID | 87cyo7kxek.wl-kuninori.morimoto.gx@renesas.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
| Series | arm64: V4M GrayHawk Sound support | expand |
Hi Morimoto-san, On Mon, Jun 24, 2024 at 2:16 AM Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote: > Because V4M supports only 1 SSI, it can't use Playback/Capture > in the same time. It select Playback as default. > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Thanks for your patch! > --- a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts > +++ b/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts > @@ -5,6 +5,25 @@ > * Copyright (C) 2023 Renesas Electronics Corp. > * Copyright (C) 2024 Glider bv > */ > +/* > + * [How to use Sound] > + * > + * Because R-Car V4M has only 1 SSI, it can't handle both Playback/Capture > + * in the same time. You need to switch the direction which is controlled > + * by GP0_01 pin via amixer. > + * > + * Playback (CN9500) > + * > amixer set "MUX" "Input 1" // for GP0_01 > + * > amixer set "DAC 1" 85% > + * > aplay xxx.wav > + * > + * Capture (CN9501) > + * > amixer set "MUX" "Input 2" // for GP0_01 > + * > amixer set "Mic 1" 80% > + * > amixer set "ADC 1" on > + * > amixer set 'ADC 1' 80% > + * > arecord xxx hoge.wav The use of "Input 1" and "Input 2" sounds a bit strange to me. Looking at sound/soc/codecs/simple-mux.c, these are dictated by the MUX driver. > + */ > > /dts-v1/; > > @@ -59,6 +78,23 @@ reg_3p3v: regulator-3p3v { > regulator-boot-on; > regulator-always-on; > }; > + > + sound_mux: mux { > + compatible = "simple-audio-mux"; > + mux-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>; Adding support to simple-audio-mux to override the default "Input 1" and "Input 2" names, using e.g. state-names = "Playback", "Record"; would make this more user-friendly. Still, I wonder if there are any side-effects of (ab)using simple-audio-mux for your use case. This MUX driver is really meant to pick one of two sources to connect to a single sink, as described by the topology in simple_mux_dapm_routes[] in the driver. Perhaps there exists software which interpretes these routes, and offers the user a graphical description of the topology, which would be wrong? > + }; The rest LGTM. Gr{oetje,eeting}s, Geert
Hi Geert Thank you for your review > The use of "Input 1" and "Input 2" sounds a bit strange to me. > Looking at sound/soc/codecs/simple-mux.c, these are dictated by the > MUX driver. (snip) > Adding support to simple-audio-mux to override the default "Input 1" > and "Input 2" names, using e.g. > > state-names = "Playback", "Record"; > > would make this more user-friendly. I have tried to re-use existing driver without fixes. but yes, using own naming is better idea. I will try to update it, and re-post this patch again. > Still, I wonder if there are any side-effects of (ab)using > simple-audio-mux for your use case. This MUX driver is really meant > to pick one of two sources to connect to a single sink, as described > by the topology in simple_mux_dapm_routes[] in the driver. Perhaps > there exists software which interpretes these routes, and offers the > user a graphical description of the topology, which would be wrong? If you are talking about detail of direction (IN/OUT vs Playback/Capture), indeed it might be a little bit mismatch. But, Playback node and Capture node are not shared in general. R-Car Gen4 Sound concept itself is very special. So I it not cinderella fit driver but enough driver for this purpose. I think there is no *bad* side-effects. Thank you for your help !! Best regards --- Kuninori Morimoto
Hi Morimoto-san, On Thu, Jun 27, 2024 at 2:11 AM Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote: > > The use of "Input 1" and "Input 2" sounds a bit strange to me. > > Looking at sound/soc/codecs/simple-mux.c, these are dictated by the > > MUX driver. > (snip) > > Adding support to simple-audio-mux to override the default "Input 1" > > and "Input 2" names, using e.g. > > > > state-names = "Playback", "Record"; > > > > would make this more user-friendly. > > I have tried to re-use existing driver without fixes. > but yes, using own naming is better idea. > I will try to update it, and re-post this patch again. OK > > Still, I wonder if there are any side-effects of (ab)using > > simple-audio-mux for your use case. This MUX driver is really meant > > to pick one of two sources to connect to a single sink, as described > > by the topology in simple_mux_dapm_routes[] in the driver. Perhaps > > there exists software which interpretes these routes, and offers the > > user a graphical description of the topology, which would be wrong? > > If you are talking about detail of direction (IN/OUT vs Playback/Capture), > indeed it might be a little bit mismatch. But, Playback node and Capture > node are not shared in general. R-Car Gen4 Sound concept itself is very > special. So I it not cinderella fit driver but enough driver for this > purpose. I think there is no *bad* side-effects. Yes, I mean the assignment of sources and sinks in: struct snd_soc_dapm_route { const char *sink; const char *control; const char *source; ... }; static const struct snd_soc_dapm_route simple_mux_dapm_routes[] = { { "OUT", NULL, "MUX" }, { "MUX", "Input 1", "IN1" }, { "MUX", "Input 2", "IN2" }, }; It looks like snd_soc_dapm_route does not support a node that can change roles between sink and source. Gr{oetje,eeting}s, Geert
Hi Geert > struct snd_soc_dapm_route { > const char *sink; > const char *control; > const char *source; > ... > }; > > static const struct snd_soc_dapm_route simple_mux_dapm_routes[] = { > { "OUT", NULL, "MUX" }, > { "MUX", "Input 1", "IN1" }, > { "MUX", "Input 2", "IN2" }, > }; > > It looks like snd_soc_dapm_route does not support a node that can > change roles between sink and source. This part is independent from main Sound system (= R-Car - AK4619). Indeed naming of "sink/source" text is not cinderella matching to our board. It is re-using existing driver, because our case is not general. Thank you for your help !! Best regards --- Kuninori Morimoto
diff --git a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts b/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts index 2b9a19bb1c5d3..717251124a744 100644 --- a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts +++ b/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts @@ -5,6 +5,25 @@ * Copyright (C) 2023 Renesas Electronics Corp. * Copyright (C) 2024 Glider bv */ +/* + * [How to use Sound] + * + * Because R-Car V4M has only 1 SSI, it can't handle both Playback/Capture + * in the same time. You need to switch the direction which is controlled + * by GP0_01 pin via amixer. + * + * Playback (CN9500) + * > amixer set "MUX" "Input 1" // for GP0_01 + * > amixer set "DAC 1" 85% + * > aplay xxx.wav + * + * Capture (CN9501) + * > amixer set "MUX" "Input 2" // for GP0_01 + * > amixer set "Mic 1" 80% + * > amixer set "ADC 1" on + * > amixer set 'ADC 1' 80% + * > arecord xxx hoge.wav + */ /dts-v1/; @@ -59,6 +78,23 @@ reg_3p3v: regulator-3p3v { regulator-boot-on; regulator-always-on; }; + + sound_mux: mux { + compatible = "simple-audio-mux"; + mux-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>; + }; + + sound_card: sound { + compatible = "audio-graph-card2"; + label = "rcar-sound"; + aux-devs = <&sound_mux>; // for GP0_01 + + links = <&rsnd_port>; /* AK4619 Audio Codec */ + }; +}; + +&audio_clkin { + clock-frequency = <24576000>; }; &avb0 { @@ -87,6 +123,15 @@ &extalr_clk { clock-frequency = <32768>; }; +&gpio1 { + audio-power-hog { + gpio-hog; + gpios = <8 GPIO_ACTIVE_HIGH>; + output-high; + line-name = "Audio-Power"; + }; +}; + &hscif0 { pinctrl-0 = <&hscif0_pins>; pinctrl-names = "default"; @@ -139,6 +184,29 @@ eeprom@53 { }; }; +&i2c3 { + pinctrl-0 = <&i2c3_pins>; + pinctrl-names = "default"; + + status = "okay"; + clock-frequency = <400000>; + + ak4619@10 { + compatible = "asahi-kasei,ak4619"; + reg = <0x10>; + + clocks = <&rcar_sound>; + clock-names = "mclk"; + + #sound-dai-cells = <0>; + port { + ak4619_endpoint: endpoint { + remote-endpoint = <&rsnd_endpoint>; + }; + }; + }; +}; + &mmc0 { pinctrl-0 = <&mmc_pins>; pinctrl-1 = <&mmc_pins>; @@ -193,6 +261,11 @@ i2c0_pins: i2c0 { function = "i2c0"; }; + i2c3_pins: i2c3 { + groups = "i2c3"; + function = "i2c3"; + }; + mmc_pins: mmc { groups = "mmc_data8", "mmc_ctrl", "mmc_ds"; function = "mmc"; @@ -213,6 +286,40 @@ scif_clk2_pins: scif-clk2 { groups = "scif_clk2"; function = "scif_clk2"; }; + + sound_pins: sound { + groups = "ssi_ctrl", "ssi_data"; + function = "ssi"; + }; + + sound_clk_pins: sound_clk { + groups = "audio_clkin", "audio_clkout"; + function = "audio_clk"; + }; +}; + +&rcar_sound { + pinctrl-0 = <&sound_clk_pins>, <&sound_pins>; + pinctrl-names = "default"; + + status = "okay"; + + /* audio_clkout */ + clock-frequency = <12288000>; + + ports { + rsnd_port: port { + rsnd_endpoint: endpoint { + remote-endpoint = <&ak4619_endpoint>; + bitclock-master; + frame-master; + + /* see above [How to use Sound] */ + playback = <&ssi0>; + capture = <&ssi0>; + }; + }; + }; }; &rpc {
Because V4M supports only 1 SSI, it can't use Playback/Capture in the same time. It select Playback as default. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> --- .../dts/renesas/r8a779h0-gray-hawk-single.dts | 107 ++++++++++++++++++ 1 file changed, 107 insertions(+)