AndrewK

Okay, mainline kernel is now version 4.11 and H3 S/PDIF driver marked as working. Below is a brief guide on how to enable it. Unlike legacy kernel, in which to configure gpio and device drivers it was necessary to edit the .fex file, in mainline we need device tree overlays. Login as root First we need to find out which device tree is being used. To do this, you must execute: cat /proc/device-tree/model; echo In my NanoPI M1, for some reason, is used the device tree for OrangePI PC In order to select the correct device tree and an overlay needed to enable the S/PDIF, we need to do some changes in /boot/armbianEnv.txt file. Open it in editor (root privilegs required) and add 2 lines: fdtfile=sun8i-h3-nanopi-m1.dtb overlays=spdif-out If you need the driver of the IR receiver and (or) an analog audio codec, you need to add the cir and (or) analog-codec to the overlay list via spaces It's all. Save file, exit editor and execute: sync reboot After reboot login as root again Get the list of ALSA devices available: aplay -l **** List of PLAYBACK Hardware Devices **** card 0: SPDIF [On-board SPDIF], device 0: spdif-dit-hifi dit-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0

OK, I made SPDIF work in the mainline kernel (patches in the attachment). But in a way that I do not like I had to change the settings of the "spdif" clock in linux clock tree hierarchy (see 2'nd patch). Now it works like "ac-dig" (analog codec clock) and dvider in OWA Clock register does not used during the frequency selection process. On the good it was necessary to trace the processing of the request for changing frequency through the clock hierarchy: "spdif" -> "pll-audio" -> "pll-audio-base" -> "osc24M" and to find and eliminate the bug. But for my level of understanding the Linux clock tree management, it is very difficult. I'm happy to return to this work if someone more experienced tells me where to look Another problem is that integer audio-pll dividers do not allow to accurately get the requested frequencies: 24571428 instead of 24576000 and 22571428 instead of 22579200 .This is because the driver in kernel 4.10 and 4.11 does not use the PLL_AUDIO Pattern Control Register, unlike the driver in the legacy kernel. spdif-001-driver-from-4.11-kernel.patch spdif-002-change-clock-mode.patch

I found that the correct or incorrect setting of spdif mclk depends on the analog codec. If before using of spdif I play over analog codec a phohogram with sampling frequency of 48 khz, then the spdif correctly reproduces the phonograms with a 48 khz and incorrectly with 44.1 kHz. If I play over analog codec a 44,1 khz phonogram , next the spdif correctly reproduces the 44,1 khz phonograms and 48 khz incorrectly. Apparently, this is due to the fact that all H3 audio devices have a common clock generator and an analog codec has priority in its tuning. Anywhere in the structures describing the analog codec driver there should be a flag that allows other audio devices to set the clock speed. I'll try to find and set it up.

Checked bit numbers and coefficient widths in ccu-sun8i-h3.c - everything is same as in datasheet. In the driver from kernel 4.11 exactly the same. The only difference is the flag CLK_SET_RATE_UNGATE in audio pll structure in 4.10 and zero in 4.11 Replacing this flag with 0 as in 4.11 does not change anything. I added a diagnostic message to the initialization function of the SPDIF with the actual value of the mclk after the call of the clk_set_rate. When reproducing tracks with a sampling rate of a multiple of 48 kHz, the mclk is set to 24571428 Hz instead of 24567000. When reproducing tracks with a sampling rate of a multiple of 44.1 kHz, the mclk is set to 12285714 Hz instead of 22579200. It's not even 22579200/2, but 24571428/2 !!! It seems that the error still somewhere in clk_set_rate

Ok, I tried Your spdif-out overlay. In order for .dtbo to appear in the /boot/dtb/overlay , I had to add the name of this overlay to the Makefile (see 1'st patch in attachment). After compile image and boot system I added to /boot/armbianEnv.txt lines: fdtfile=sun8i-h3-nanopi-m1.dtb overlays=cir spdif-out and after reboot see: cat /proc/device-tree/model; echo FriendlyArm NanoPi M1 and: aplay -l **** List of PLAYBACK Hardware Devices **** card 0: SPDIF [On-board SPDIF], device 0: spdif-dit-hifi dit-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 The music over SPDIF is reproduced in the same way as before, twice as slow. For the experiment, I doubled the frequencies in the source code of the SPDIF driver (see 2'nd patch in attachment), and got an wierd result: the phonograms with sampling frequencies multiples of 48KHz play correctly, and with 44.1KHz multiple is slightly faster than needed. It seems that something wrong not in SPDIF driver, but somewhere where the audio-pll is programmed (where function clk_set_rate resides). I'll read H3 datasheet, I'll see the source code and write here about results. spdif-002-add-spdif-overlay-to-makefile.patch spdif-003-double-mclk.patch

I performed the cat /proc/device-tree/model; echo and got the result Xunlong Orange Pi PС Indeed, the Armbian for NanoPi M1 use .dtb for OrangePi PC. Could You tell me, where in Armbian build system I can select which .dts to use? Judging by the contents of dts for these boards, I see difference in CPU clock speed control. I'm trying to play music through spdif and it plays twice as slow. Maybe the reason is in the wrong .dts? P.S. Since this topic is about device tree overlays, as soon as I properly earn the spdif, I will create an overlay and publish a patch

Thank you! I'll check in the evening.

I think I found a bug. Maybe someone help me here.

Hello! I apologize for offtopic, but I decided not to create new theme and ask here: Is there any way to know which .dtb file was used to configure the running kernel? I got the impression that the system image for NanoPI M1 (mainline krnel 4.10) uses .dtb not for this board, but for OrangePi PC. It turned out when I tried to enable an SPDIF transmitter. When I enable SPDIF in sun8i-h3-nanopi-m1.dts, compile and boot the system for NanoPI M1, the driver was not installed and the SPDIF was not in the list of audio devices. But when I enable SPDIF in sun8i-h3-orangepi-pc.dts ( without any changes in original sun8i-h3-nanopi-m1.dts) and compile the system for NanoPI M1, the driver was installed and the SPDIF appeared in the list of audio devices. Tell me please, where is configured, which .dts for which board, what would I check and, if I find an error, make a patch?

It worked, but wrong To make driver up, by analogy with OrangePi PC, I enable HDMI and CODEC (patches in attachment). As result, player (squeezelite in my case) even plays music but twice as slow as necessary - Shade sings bass As I understand it - the problem is in SPDIF transmitter clocking. In the source code of the SPDIF driver there are a settings of the clock division depending on the sampling frequency of the reproduced music. But divider for 192KHz is 1 so I cah't divide it by 2 to listen 192KHz FLACs. I think that I need to look for where the frequency of the audio PLL is set, perhaps there is some extra divider which must be turned off. spdif-001-driver-from-4.11-kernel.patch spdif-002-nanopim1.patch spdif-003-nanopim1-1.patch

I'm trying to turn on the SPDIF transmitter in the H3 mainline kernel (v4.10). To do this I'm copying sun4i_spdif.c from sunxi-next kernel (spdif marked as working starting from kernel v4.11) and make some changes in .dts files for OrangePi PC: diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts index 90a767f..29980a8 100644 --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts @@ -91,6 +91,24 @@ gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>; }; }; + + sound { + compatible = "simple-audio-card"; + simple-audio-card,name = "On-board SPDIF"; + + simple-audio-card,cpu { + sound-dai = <&spdif>; + }; + + simple-audio-card,codec { + sound-dai = <&spdif_out>; + }; + }; + + spdif_out: spdif-out { + #sound-dai-cells = <0>; + compatible = "linux,spdif-dit"; + }; }; &cpu0 { @@ -338,3 +356,9 @@ allwinner,leds-active-low; status = "okay"; }; + +&spdif { + pinctrl-names = "default"; + pinctrl-0 = <&spdif_tx_pins_a>; + status = "okay"; +}; diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi index 21e3f42..c40d45c 100644 --- a/arch/arm/boot/dts/sun8i-h3.dtsi +++ b/arch/arm/boot/dts/sun8i-h3.dtsi @@ -513,8 +513,8 @@ }; spdif_tx_pins_a: spdif@0 { - pins = "PA17"; - function = "spdif"; + allwinner,pins = "PA17"; + allwinner,function = "spdif"; }; spi0_pins: spi0 { After that, I compile Armbian, copy the image to SD, boot system on OrangePi PC board fnd see spdif presence: root@orangepipc:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: SPDIF [On-board SPDIF], device 0: spdif-dit-hifi dit-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 root@orangepipc:~# I can not test whether it works because it is very difficult to solder the input of my optical transmitter to the PA17 - it is output to miniature camera connector. But module is up and ALSA see it. To check if it works, I did similar things for nanopi m1, but after loading the system the module did not go up and ALSA does not see the SPDIF output: root@nanopim1:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 root@nanopim1:~# Could someone tell me what I'm doing wrong? Patches and logs in attachment. npim1-console.txt npim1-dmesg.txt opipc-console.txt opipc-dmesg.txt spdif-001-driver-from-4.11-kernel.patch spdif-002-nanopim1.patch spdif-002-orangepipc.patch

Here is a short instruction how to enable S/PDIF digital audio output on NanoPI M1 board running Debian Jessie with legacy kernel. This instruction can be applied to other H3 based boards but connect S/PDIF output hardware to GPIOA17 can be tricky (soldering miniature camera connector pins). Operations can be done over serial console or ssh. Login as root Get a .fex file and open it in editor: bin2fex /boot/script.bin /tmp/script.fex nano /tmp/script.fex Search a csi0 (camera) section an disable it: [csi0] vip_used = 0 Search a S/PDIF section and enable it: [spdif0] spdif_used = 1 Get the name of the file pointed by the /boot/script.bin link and convert modified .fex to it: ls -la /boot/script.bin ----- /boot/script.bin -> bin/nanopim1.bin fex2bin /tmp/script.fex /boot/bin/nanopim1.bin Open /etc/modules to instruct Jessie to load S/PDIF modules at boot: nano /etc/modules Add module names near the end of file: sunxi_spdif sunxi_spdma sndspdif sunxi_sndspdif Reboot system: sync reboot After reboot login as root again Get the list of ALSA devices available: aplay -l **** List of PLAYBACK Hardware Devices **** card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC sndcodec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: sndhdmi [sndhdmi], device 0: SUNXI-HDMIAUDIO sndhdmi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: sndspdif [sndspdif], device 0: SUNXI-SPDIF sndspdif-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0 To connect board S/PDIF output to my favorite DAC i use an optical S/PDIF module soldered out from dead DVD player: There are 3 wires connected to board 40-pin connector: GND (pin 6), VDD_5V (pin 2) and SPDIF-OUT/GPIOA17 (pin 26) Module pinout can be found in datasheet http://www.mouser.com/catalog/specsheets/totx177(f,t).pdf Modules come in 2 types: 6-MBit (up to 24 bit / 96KHz) and 15-MBit (up to 24 bit / 192KHz). Most likely from DVD or SAT receiver You get the 6-MBit module. 15-MBit modules can be purchased at Digikey, etc. When listening to music, I faced with spontaneous fadings. This is due to some problem of the CPU speed switching. To this do not happen, I banned the clock frequency of 240 MHz in the /etc/default/cpufrequtils: MIN_SPEED=480000