Hi Rob, On 20/05/2020 1.21, Rob Herring wrote: > On Tue, May 12, 2020 at 04:16:32PM +0300, Peter Ujfalusi wrote: >> The audio support on the Common Processor Board board is using >> pcm3168a codec connected to McASP10 serializers in parallel setup. >> >> The Infotainment board plugs into the Common Processor Board, the support >> of the extension board is extending the CPB audio support by adding >> the two codecs on the expansion board. >> >> The audio support on the Infotainment Expansion Board consists of McASP0 >> connected to two pcm3168a codecs with dedicated set of serializers to each. >> The SCKI for pcm3168a is sourced from j721e AUDIO_REFCLK0 pin. >> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@xxxxxx> >> --- >> .../bindings/sound/ti,j721e-cpb-audio.yaml | 93 ++++++++++++ >> .../sound/ti,j721e-cpb-ivi-audio.yaml | 142 ++++++++++++++++++ >> 2 files changed, 235 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml >> create mode 100644 Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml >> >> diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml >> new file mode 100644 >> index 000000000000..0355ffc2b01b >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml >> @@ -0,0 +1,93 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/sound/ti,j721e-cpb-audio.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Texas Instruments J721e Common Processor Board Audio Support >> + >> +maintainers: >> + - Peter Ujfalusi <peter.ujfalusi@xxxxxx> >> + >> +description: | >> + The audio support on the board is using pcm3168a codec connected to McASP10 >> + serializers in parallel setup. >> + The pcm3168a SCKI clock is sourced from j721e AUDIO_REFCLK2 pin. >> + In order to support 48KHz and 44.1KHz family of sampling rates the parent >> + clock for AUDIO_REFCLK2 needs to be changed between PLL4 (for 48KHz) and >> + PLL15 (for 44.1KHz). The same PLLs are used for McASP10's AUXCLK clock via >> + different HSDIVIDER. >> + >> +properties: >> + compatible: >> + items: >> + - const: ti,j721e-cpb-audio >> + >> + model: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: User specified audio sound card name >> + >> + ti,cpb-mcasp: >> + description: phandle to McASP10 >> + allOf: >> + - $ref: /schemas/types.yaml#/definitions/phandle >> + >> + ti,cpb-codec: >> + description: phandle to the pcm3168a codec used on the CPB >> + allOf: >> + - $ref: /schemas/types.yaml#/definitions/phandle >> + >> + clocks: >> + items: >> + - description: PLL4 clock >> + - description: PLL15 clock >> + - description: McASP10 auxclk clock >> + - description: PLL4_HSDIV0 parent for McASP10 auxclk (for 48KHz) >> + - description: PLL15_HSDIV0 parent for McASP10 auxclk (for 44.1KHz) >> + - description: AUDIO_REFCLK2 clock >> + - description: PLL4_HSDIV2 parent for AUDIO_REFCLK2 clock (for 48KHz) >> + - description: PLL15_HSDIV2 parent for AUDIO_REFCLK2 clock (for 44.1KHz) > > What h/w are these connected to? These clocks are internal to the SoC with the exception of AUDIO_REFCLK2 which is routed to SoC pin. > You have no control interface here, so how do you have clocks? I need to control these clocks, the sound card is the user of these clocks. > Defining parent clocks seems wrong, too. This seems to just be a > collection of clocks a driver happens to need. Really, you should be > able query possible parents and select one with the right frequency > multiple. The issue in hand is that I need to dynamically switch between certain parents of the cpb-mcasp (for McASP) and audio-refclk2 (for the codec) based on sampling rate of the stream. The McASP auxclk parent can be selected from 7 source and I must use the two dedicated ones. The REFCLK2 parent can be selected from 30 source. It is also a limitation of the system that I can not query directly the PLL4/PLL15 frequencies, I can only get the frequency on the HSDIVs, but I can not get the divider on them. In order to handle the constraints on clocking I need to know the source rate so the dividers can be taken into account. The codec is picky when it comes to clocking and there is a need to switch between 256/512/768xFS based SCKI in order to be able to support sampling rates. At the moment I have fixed clocks in place for the pll4/15 with the rates they are configured so the dts can switch to a real clock which I can use in the future. As things are it is unlikely that I will ever going to have access to them, but I wanted to avoid in the bindings: ti,j721e-pll4-rate = <1179648000>; ti,j721e-pll15-rate = <1083801600>; >> + >> + clock-names: >> + items: >> + - const: pll4 >> + - const: pll15 >> + - const: cpb-mcasp >> + - const: cpb-mcasp-48000 >> + - const: cpb-mcasp-44100 >> + - const: audio-refclk2 >> + - const: audio-refclk2-48000 >> + - const: audio-refclk2-44100 >> + >> +required: >> + - compatible >> + - model >> + - ti,cpb-mcasp >> + - ti,cpb-codec >> + - clocks >> + - clock-names >> + >> +additionalProperties: false >> + >> +examples: >> + - |+ >> + sound { >> + compatible = "ti,j721e-cpb-audio"; >> + model = "j721e-cpb"; >> + >> + status = "okay"; > > Don't show status in examples. Oops, it is a leftower > >> + >> + ti,cpb-mcasp = <&mcasp10>; >> + ti,cpb-codec = <&pcm3168a_1>; >> + >> + clocks = <&pll4>, <&pll15>, >> + <&k3_clks 184 1>, >> + <&k3_clks 184 2>, <&k3_clks 184 4>, >> + <&k3_clks 157 371>, >> + <&k3_clks 157 400>, <&k3_clks 157 401>; >> + clock-names = "pll4", "pll15", >> + "cpb-mcasp", >> + "cpb-mcasp-48000", "cpb-mcasp-44100", >> + "audio-refclk2", >> + "audio-refclk2-48000", "audio-refclk2-44100"; >> + }; - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Attachment:
pEpkey.asc
Description: application/pgp-keys
