Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 180 replies
  • Subscribers 689 subscribers
  • Views 23042 views
  • Users 0 members are here
Related

Driver fixes and updates to kernel 3.18.16 and 4.0.5

hiassoft

Edit: Current kernel versions and install/config instructions are also available from my webpage http://www.horus.com/~hias/cirrus-driver.html

 

During the last few weeks I fixed various issues in the Wolfson/Cirrus driver and rebased it so it works with the current RPi kernel versions (3.18.16 and 4.0.5).

 

You can download the patches from my GitHub repository. The 3.18 kernel with Cirrus drivers is in the cirrus-3.18.y branch, the 4.0 kernel with Cirrus drivers is in the cirrus-4.0.y branch. I'll rebase and update these branches from time to time so that the Cirrus driver and my changes will stay on top of the commit list.

 

If you just want to have an updated 3.18.16 kernel you can download precompiled binaries from here. Just unpack the tarball in the root directory. Before you do that it might be a good idea to update the firmware files (bootcode.bin, start*.elf and fixup*.dat in the boot directory) to the latest version.

 

Here's a list of my changes:

- Added the FLL1 setup back so that switching between 44.1kHz and 48kHz (and other sample rates) works fine.

- Don't register Arizona IRQ if it's set to 0. The Cirrus driver uses polling here and if we register an interrupt handler for irq 0 we get lots of "spurious interrupt" messages spamming dmesg in kernel 3.19 and newer. IRQ 0 is wrong anyway.

- Include DCVDD patches from the Cirrus linux-drivers repository. These patches make sure the WM8804 chip is initialized properly. Without this patch I sometimes had SPDIF audio out only on the right channel.

- Disable spidev0 in Cirrus device tree overlay. That's mainly a safety precaution so that userspace programs trying to access spi0.0 won't interfere with the WM8804 reset line. I'm not 100% sure this is needed at all, so maybe I'll remove it some time later.

 

And some important notes:

I haven't included the mmap patch, this is already supported in the upstream kernels but currently disabled by default. To enable mmap support add the following line to config.txt:

dtoverlay=i2s-mmap

 

If you compile the kernel on your own please note that the devicetree overlays have now been moved to arch/arm/boot/dts/overlays.

 

Kernel 4.0 now uses spi_bcm2835 by default (the older spi_bcm2708 module is available via a devicetree overlay) so you have to extend your /etc/modprobe.d conf file and add a pre-depend for spi_bcm2835 as well. It's safe to have both the old and the new module in here, so just use this configuration:

softdep arizona-spi pre: arizona-ldo1
softdep spi-bcm2708 pre: fixed
softdep spi-bcm2835 pre: fixed

 

so long,

 

Hias

Parents

  • Hi Matthias,

    I'm interested in modifying the driver so the card will only record certain frequencies and ignore the others. Do you mind sharing your workflow on modifying the driver code? for example how do you build,deploy,debug only the driver? do you use a linux host or perform all the work on the pi?

     

    Thanks in advance.

     

    Mike

Reply

  • Hi Matthias,

    I'm interested in modifying the driver so the card will only record certain frequencies and ignore the others. Do you mind sharing your workflow on modifying the driver code? for example how do you build,deploy,debug only the driver? do you use a linux host or perform all the work on the pi?

     

    Thanks in advance.

     

    Mike

Children
  • in reply to Former Member

    Hi Mike!

    I'm interested in modifying the driver so the card will only record certain frequencies and ignore the others.

    If you want to do software audio processing the kernel's not the right place for that. Better write a userspace alsa or ladspa plugin for that. You can then enable the plugin in your ~/.asoundrc to get an additional, filtered, alsa device that you can use with other programs like arecord. Maybe there's already a alsa/ladspa plugin readily available that suits your needs.

     

    Another alternative might be to use the integrated low/high-pass filters and/or the 5-band equalizer of the WM5102 - if they are sufficient for your needs. Most of the wm5102 functionality is exposed to userspace via alsa mixer controls and you can simply configure signal routing so that the analog input signal is passed through the filters/EQ. Here's a simple example:

    DC offset on microphones and workaround.

     

    It would be cool if we could use the DSP inside the wm5102, but unfortunately this doesn't seem to be an option (requires expensive development software)

    AEC / DSP code on Wolfson audio card for Pi

    Do you mind sharing your workflow on modifying the driver code? for example how do you build,deploy,debug only the driver? do you use a linux host or perform all the work on the pi?

    My workflow is pretty straight forward. I cross-compile the kernel on my Debian PC, install the kernel+modules+dtbs to a local directory and then use rsync to transfer them to the RPi. Compiling locally on the RPi would work fine too, but my main PC is faster so I prefer this method.

     

    I use git a lot, have tons of local branches for different kernel versions / feature tests and several separate working copies of different trees so I can test and compare very quickly.

     

    To speed things up I setup the RPi to allow root login via ssh key and created a bunch of shell scripts - nothing really fancy though. I've attached them, but you'll need to change the hardcoded absolute paths (I'm using a separate harddrive mounted at /wd because I ran out of space on my home partition).

     

    The workflow looks like this:

     

    First I source the cc-rpi.env file to setup environment variables for cross-compiling and add a path to the helper scripts (all living in /wd/rpi/bin)

    . /wd/rpi/bin/cc-rpi.env

     

    Then I do the usual "make bcm2709_defconfig", edit files and "make" to compile the kernel. To transfer the files over to the RPi I simply do a

    install-rpi-rsync

    By setting the KERNELVER environment variable I can set the local installation directory. I can also pass an optional hostname to the install-rpi-rsync script which the script also uses to set the kernel image name (kernel.img when installing to rpi1, kernel7.img for rpi2). All quick-and-dirty hardcoded stuff image

     

    To run the new kernel I just use ssh to reboot the RPi

    ssh root@rpi2 "sync;reboot"

     

    As for debugging: again nothing fancy, mainly good old dev_dbg/printk statements and then checking the kernel log. Looking at the files in the kernel debugfs and /proc/device-tree also helped a lot to track down problems. I had a quick look at kgdb some 10 years or so ago but never really used it - most of the stuff I worked on so far was timing critical and standard debugging / single-stepping isn't an option in this case.

     

    A few weeks ago I suspected a problem with the FLL/SYSCLK configuration, to test this I simply hacked up the wm5102_revb_patch table to configure FLL/SYSCLK output to the GPIOs and enabled GPIO3/4 outputs in the devicetree file (the gpio-defauls section). Then I could check the wm5102 internal FLL/SYSCLK on the wm5102's GPIOs with my scope, turned out everything was fine in this area.

     

    BTW: Kernel 4.3 contains several upstream fixes to the wm5102/arizona code. So far I hadn't issues with the 4.1 kernel, but doing a quick test with 4.3 might be worth a try before spending too much time with debugging. I've pushed a 4.3 tree with the cirrus driver and some additonal fixes to github:

    https://github.com/HiassofT/rpi-linux/tree/cirrus-4.3.y

     

    so long,

     

    Hias

    Attachments:
    https://community.element14.com/cfs-file/__key/communityserver-discussions-components-files/91/cc_2D00_scripts.tar