Quote:
1.) Am I right in the fact that the cs42l51 at I2C addr 0x4a is not physically present in the CuBox ?
To me it looks like it is instantiated solely to enable S/PDIF on older ALSA versions. Since
this is no longer necessary, it could be removed from arch/arm/mach-dove/cubox-setup.c
avoiding the error message (and admittedly small delay) on boot.
True
Quote:
2.) What is the purpose of sound/soc/kirkwood/dove_cubox.c ? Is that an incomplete attempt to
add some features or just a leftover from the past ? If the latter, it could be removed as well.
That's the original code I wrote; but then was overriden by code from Sebastian Hasselbrath.
So this code can be removed.
Quote:
3.) It the above file turns out to be unneeded, there is no real reason for the config setting
CONFIG_SND_DOVE_SOC_CUBOX as well, since the CuBox is now covered by
SND_KIRKWOOD_SOC_SPDIF (i.e. "SoC Audio support for Kirkwood generic S/PDIF")
True this can be removed too.
Quote:
4.) We could also disable CONFIG_SND_SOC_ALL_CODECS in arch/arm/configs/cubox_defconfig
to avoid building all of these modules. The only codec we really need is spdif_tranciever.c (note the typo
in the file name).
Can be optimized too.
Notice that the 3.5 kernel tree uses an external clock generator for the audio clock, and can cover 192khz easily with -+30ppm clock accuracy; thus making this device also attractive for
hi fidelity users.Quote:
And finally and unrelated: Would it be possible to enable DEVTMPFS in the CuBox default config so that
people can build a working kernel right away.
Yes. I will enable and push upstream.
By the way; you can have a github account and send merge requests if this makes it easier.
Login
Register
FAQ
Search
This might be considered...