Add overlay for Chipdip I2S master DAC

[chipdipru]

Configures Raspberry PI to work as I2S slave with BCLK = 64Fs. Tested on Raspberry PI3 with Chipdip I2S master DACs based on ADAU1701 and PCM5242.

[pelwell]

1. The overlay file has the wrong name - chipdip-i2s-master-dac-overlay.dts is required, otherwise the kernel make rules won't work.
2. There is no Makefile entry for the overlay.
3. There is no README entry for the overlay.
4. See inline comments.

[chipdipru]

Hello! Thank you for paying attention to the request. Your comments were taken into account axcept two: about Makefile entry and README entry for the overlay. I am very new to the system, could you please give a link with explanation or example of what I shall do. Thank you.

[pelwell]

Every overlay needs an entry in arch/arm/boot/dts/overlays/Makefile and arch/arm/boot/dts/overlays/README. Without the Makefile entry the overlay will not be compiled and installed. Without the README entry users will not be able to discover the overlay (using the command dtoverlay -a) and learn about it (using the command dtoverlay -h).

The Makefile entry is very simple - it just needs a line with the name of the overlay once compiled - in your case chipdip-i2s-master-dac.dtbo.

The README entry is also not difficult to write, but you need to follow some strict rules:

1. Entries are in alphabetical order.
2. Two blank lines between entries.
3. No lines longer that 80 characters.
4. Strict indentation levels - copy other entries, using only spaces (no TABs)!
5. The "Load:" example line must match the name of the overlay.
6. Any parameters must be documented (you have none).

Just find an entry for a simple overlay with no parameters and copy it, being sure to update the names and description.

[chipdipru]

Thank you very much for explanation! Changes are made to Makefile and README files. It seems that I have placed "chipdip-i2s-master-dac-overlay.dts" overlay in wrong folder. Now it is in arch/arm/boot/dts, but other similar overlays for sound cards are in arch/arm/boot/dts/overlays/. Is it possible at this stage to change folder and place "chipdip-i2s-master-dac-overlay.dts" in arch/arm/boot/dts/overlays/ ?

[pelwell]

I'll review your updates later, but in the meantime you can move the overlay using "git mv ", "git commit" and "git push ..." in the usual way.

[chipdipru]

Thank you!

[chipdipru]

Excuse me for offtop, but I did not manage to find any information regarding to the following situation.
Our sound cards use software for controlling Raspberry GPIOs. Can this software be added to the kernel to be launched automatically if our sound card is shosen?

[pelwell]

I'm happy with that. If you give me an name/email address for the "Signed-off-by:" line I can squash and merge your commits.

Our sound cards use software for controlling Raspberry GPIOs. Can this software be added to the kernel to be launched automatically if our sound card is shosen?

The kernel won't launch any user processes - it relies on systemd, udev and other external mechanisms to start programs in response to events. With a bit more information about the sequence of operations involved I can perhaps suggest an approach that might work.

[chipdipru]

Thanks a lot!
Name: Evgenij Sapunov
Email address: evgenij.sapunov@chipdip.ru

With a bit more information about the sequence of operations involved I can perhaps suggest an approach that might work.

Thank you for your help!
We have several I2S DACs for Raspberry based on different DSP chips. DSP chips are controlled by MCU, not by Raspberry. This approach is simpler for us because we need only one generic overlay to make Raspberry work as slave and we are free to choose different DSP chips without having to write drivers for Raspberry. MCU does all the job. To make such a system work correctly we need to know resolution and frequency of audio track being played. For that reason we wrote a program which polls ALSA state and changes Raspberry GPIOs according to resolution and frequency of current audio track. MCU polls its inputs state and reconfigures DSP when audio resolution and frequency change. Now we are going to ask Volumio team to add our DACs support to Volumio image. (Necessary files have been prepared.) In Volumio there is a special folder in which a script file for a DAC can be placed. When Volumio starts this script executes automatically which allows to preconfigure DSP or do something. While testing our DACs we use this way to launch our program for controlling Raspberry GPIOs - script launches it. But frankly speaking I do not know if Volumio allows to place executable files in script folder (although it works fine). So overlay configures Raspberry I2S and program changes Raspberry GPIO states according to resolution and frequency of audio track.
Can be such a system realized at some low level to free users from doing it manually?

[pelwell]

A better way to achieve what you are trying to do would have been to write a codec driver that, instead of sending I2C commands to configure the real codec, changes the GPIOs for you. I don't think it would be a lot of work, it should be more responsive and more efficient, and it doesn't need the user or distribution to install and start any extra programs.

[chipdipru]

Thank you very much for help!

[chipdipru]

Phil, when is new release of the kernel planned?

[pelwell]

We never provide guarantees on updates - we don't work to a strict schedule - but the usual "rule of thumb" is:

• rpi-update - when there are enough significant changes to warrant it, which typically is about once a week.
• apt install raspberrypi-kernel - every few months, when we think the current kernel is stable.
• a full downloadable image - roughly every 6 months.

[chipdipru]

Thank you.

[chipdipru]

Hello, Phil! We need to have the same overlay in the 4.19.y kernel. What do we have to do for that? Shall we create a new pull request and as a base repository select rpi-4.19.y or should this be done in some other way?

[pelwell]

We won't be building any more 4.19 kernels, but the commit is in rpi-4.19.y tree now: bfef951

[chipdipru]

Thank you very much!

[chipdipru]

A better way to achieve what you are trying to do would have been to write a codec driver...

Phil, as you suggested I am trying writing driver for our sound cards. Being new to the kernel I have difficulties I have not yet managed to break through. I looked through drivers available for other cards https://github.com/raspberrypi/linux/tree/rpi-5.10.y/sound/soc/bcm but did not understand their principles. I could not find information on how drivers are called, how (from where) their functions are called, how actually the system knows what functions are included in a driver or maybe there is some another software thing which is aware of the dirver internals.
Could you please advise some information links for studying to help me clarify driver principles?

[pelwell]

I guess I've been putting off this reply because saying exactly what you need to do would take a long time (including some research because I'm not really fluent in ALSA).

First of all, I made a mistake in my comment when I suggested writing a codec driver - a sound card driver would be a better fit, because you want to make use of the existing spdif-dit codec but also intercept the hw_params method. Rather than write it all out I'll suggest a few initial steps and then make it an interactive exchange:

1. Start with a simple soundcard driver - sound/soc/bcm/justboom-dac.c for example. Don't worry about plagiarism - this is all open-source code and a lot of it is copied from other drivers, but it's polite to put a note at the top of your file listing any major "inspirations".
2. Delete any register definitions and hardware accesses that use them - calls to snd_soc_component_read, snd_soc_component_write, snd_soc_component_update_bits, etc.
3. The struct snd_soc_ops instance declares the methods supported by your soundcard. You might not need .startup and .shutdown, but keep them for now. You will need to add .hw_params - look at the allo-piano-dac-plus and allo-boss2-dac drivers for examples of how to extract the sample rate and sample bits.
4. Find the SND_SOC_DAILINK_DEFS and struct snd_soc_dai_link sections and change the names and codec to fit your application; the sound/soc/samsung/smdk_spdif.c uses spdif-dit and is reassuringly simple.

[chipdipru]

Phil, thank you very much for help!
There are driver and overlay files in attachment I started from. As I understand driver is loaded by overlay when their "compatible" fields are matched. But I did not manage to get this way working. The driver is placed in /lib/modules/5.10.17-v7+/kernel/sound/soc/bcm/ as other existing ones. By means of "insmod" driver module is loaded without errors, it is seen by "lsmod", "dmesg". But it is not loaded by overlay. Although if overlay compatible with existing driver module ( "compatible" field refers to kernel module) this driver module is loaded as expected. In the Internet forum I read that out of tree modules are not loaded by overlays and must be loaded manually. But when I load the driver with "insmod" it is not regarding to and not used by any entity, it is on its own. How can one make a connection between hardware and driver loaded by "insmod"?
Thank you.

ChipDip_driver.zip

[pelwell]

Modules are located based on the various aliases that they export - "of:" aliases contain compatible strings. All aliases end up in /lib/modules/<kernel version>/modules.alias, and depmod is the tool that extracts them from modules and writes them there.
Note that <kernel version> is the string returned by:

$ uname -r
5.10.50-v7l+

so the path above can be rewritten as:

/lib/modules/`uname -r`/modules.alias

If your intention is to get this module into our kernel tree eventually then I suggest you save some time and make it an in-tree module now, at which point make ... modules_install will run depmod for you.

[pelwell]

Look at https://github.com/pelwell/linux/tree/chipdipdac - all I had to do was change the CODEC string to spdif-transmitter and it loaded OK. You'll need to add a README and make the soundcard driver do something useful with the hw_params.

[chipdipru]

Oh, Phil, thank you endlessly! Now it works as expected. I am searching information on GPIO usage. Drivers using GPIOs, I looked through, get information about GPIOs from overlay. Is it possible to assign GPIOs in driver directly leaving overlay without GPIO information?

[chipdipru]

I have added code for GPIO to the driver and overlay. It seems the driver works as expected and controls GPIOs. I am going to test it for some time to be sure everything is correct. Thank you very much, Phil!

[pelwell]

Congratulations. I think you made the right choice by putting the GPIO declarations in the overlay - it makes the code simpler.

Have a think about whether you want to replace the old overlay with the new one - I allowed them to coexist, but there's probably no reason to keep the old one as well. I'll take another pull request when you're ready, and don't feel you need to keep my Signed-off-by on the commits - it's just how I have git configured.

[chipdipru]

Yes of cause, it would be better to replace the old overlay by a newer one. As for Signed-off-by field, if you do not mind I am going to add you as driver co author because without your help it would be much longer way to get it working.

[pelwell]

I'm fine with that, although I don't feel it's necessary.