[alsa-devel] [PATCH 1/1] ASoC: Fix compilation error with davinci-sffsdr module
The SFFSDR audio codec sampling frequency clock is generated by a FPGA, and set by the FPGA driver. The FPGA driver is not yet in the mainline kernel, so that is why an extern declaration is used in the meantime.
Signed-off-by: Hugo Villeneuve hugo@hugovil.com --- sound/soc/davinci/davinci-sffsdr.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/sound/soc/davinci/davinci-sffsdr.c b/sound/soc/davinci/davinci-sffsdr.c index 1bbde3e..0a03b41 100644 --- a/sound/soc/davinci/davinci-sffsdr.c +++ b/sound/soc/davinci/davinci-sffsdr.c @@ -25,7 +25,6 @@ #include <asm/gpio.h> #include <asm/dma.h> #include <asm/mach-types.h> -#include <asm/plat-sffsdr/sffsdr-fpga.h>
#include <mach/asp.h> #include <mach/edma.h> @@ -34,6 +33,11 @@ #include "davinci-pcm.h" #include "davinci-i2s.h"
+/* The SFFSDR audio codec sampling frequency clock is generated by a FPGA. + * The FPGA driver is not yet in the mainline kernel, so that is + * why an extern declaration is used in the meantime. */ +extern int sffsdr_fpga_set_codec_fs(int fs); + static int sffsdr_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) {
On Tue, Jan 06, 2009 at 04:23:45PM -0500, Hugo Villeneuve wrote:
The SFFSDR audio codec sampling frequency clock is generated by a FPGA, and set by the FPGA driver. The FPGA driver is not yet in the mainline kernel, so that is why an extern declaration is used in the meantime.
Signed-off-by: Hugo Villeneuve hugo@hugovil.com
If the driver is for is not yet in mainline I'd be more inclined to fix this by providing the relevant Kconfig dependency to exclude it from the build rather than changing the C file - the dependency will be needed anyway when the FPGA driver is in mainline.
Do the DaVinci drivers build at all in mainline, anyway? Last time I checked they required out of tree DMA patches.
On Tue, 6 Jan 2009 21:31:17 +0000 Mark Brown broonie@sirena.org.uk wrote:
On Tue, Jan 06, 2009 at 04:23:45PM -0500, Hugo Villeneuve wrote:
The SFFSDR audio codec sampling frequency clock is generated by a FPGA, and set by the FPGA driver. The FPGA driver is not yet in the mainline kernel, so that is why an extern declaration is used in the meantime.
Signed-off-by: Hugo Villeneuve hugo@hugovil.com
If the driver is for is not yet in mainline I'd be more inclined to fix this by providing the relevant Kconfig dependency to exclude it from the build rather than changing the C file - the dependency will be needed anyway when the FPGA driver is in mainline.
Hi Mark, The problem is that some people may want to do modifications to this soc driver, and they won´t be able to test that their changes are valid (ex: do not break compilation).
Do the DaVinci drivers build at all in mainline, anyway? Last time I checked they required out of tree DMA patches.
I just sucessfully compiled the davinci-sffsdr soc driver (although audio seems broken for me at the moment when I actually test it).
Hugo V.
--------------- Hugo Villeneuve www.hugovil.com ---------------
On Tue, Jan 06, 2009 at 04:41:20PM -0500, Hugo Villeneuve wrote:
Mark Brown broonie@sirena.org.uk wrote:
If the driver is for is not yet in mainline I'd be more inclined to fix this by providing the relevant Kconfig dependency to exclude it
The problem is that some people may want to do modifications to this soc driver, and they won?t be able to test that their changes are valid (ex: do not break compilation).
Speaking as the person who I expect most frequently tries that I wouldn't worry about it - it's easy enough to see what's happened and there will still be errors at link time even with the extern. I'd certainly want to see the Kconfig fix as well, independantly of this.
Do the DaVinci drivers build at all in mainline, anyway? Last time I checked they required out of tree DMA patches.
I just sucessfully compiled the davinci-sffsdr soc driver (although audio seems broken for me at the moment when I actually test it).
That's good news - previously it would fail to build at all. What sort of breakage are you seeing (and what was the version you used when you developed the driver)?
[Your MUA isn't doing word wrapping, BTW.]
On Tue, 6 Jan 2009 22:00:06 +0000 Mark Brown broonie@sirena.org.uk wrote:
On Tue, Jan 06, 2009 at 04:41:20PM -0500, Hugo Villeneuve wrote:
Mark Brown broonie@sirena.org.uk wrote:
If the driver is for is not yet in mainline I'd be more inclined to fix this by providing the relevant Kconfig dependency to exclude it
The problem is that some people may want to do modifications to this soc driver, and they won?t be able to test that their changes are valid (ex: do not break compilation).
Speaking as the person who I expect most frequently tries that I wouldn't worry about it - it's easy enough to see what's happened and there will still be errors at link time even with the extern.
No, there won´t be errors when compiling as a module. Only when actually loading the module.
I'd certainly want to see the Kconfig fix as well, independantly of this.
I will look into this eventually.
Do the DaVinci drivers build at all in mainline, anyway? Last time I checked they required out of tree DMA patches.
I just sucessfully compiled the davinci-sffsdr soc driver (although audio seems broken for me at the moment when I actually test it).
That's good news - previously it would fail to build at all. What sort of breakage are you seeing (and what was the version you used when you developed the driver)?
I developped the driver with version 2.6.27-rc6-davinci1-05187-g91c2c53.
The breakage I see when I run the aplay utility is this:
aplay: pcm_write:1394: write error: Input/output error
davinci-git version is the latest as of january 14 (2.6.28-davinci1-06546-gcfb152b)
[Your MUA isn't doing word wrapping, BTW.]
Fixed, thanks :)
Hugo v.
--------------- Hugo Villeneuve www.hugovil.com ---------------
") Fcc: +sent-mail
On Wed, Jan 14, 2009 at 03:54:06PM -0500, Hugo Villeneuve wrote:
Mark Brown broonie@sirena.org.uk wrote:
Speaking as the person who I expect most frequently tries that I wouldn't worry about it - it's easy enough to see what's happened and there will still be errors at link time even with the extern.
No, there won?t be errors when compiling as a module. Only when actually loading the module.
Check again - the kernel will detect those errors at build time. The module itself will compile but once all the modules are built Kbuild verifies that all the symbols they use can be found.
That's good news - previously it would fail to build at all. What sort of breakage are you seeing (and what was the version you used when you developed the driver)?
I developped the driver with version 2.6.27-rc6-davinci1-05187-g91c2c53.
The breakage I see when I run the aplay utility is this:
aplay: pcm_write:1394: write error: Input/output error
davinci-git version is the latest as of january 14 (2.6.28-davinci1-06546-gcfb152b)
Hrm, OK. That's not terribly informative - does the error get reported after about 10 seconds by any chance? I suspect that DMA just isn't happening.
On Thu, 15 Jan 2009 11:18:07 +0000 Mark Brown broonie@sirena.org.uk wrote:
") Fcc: +sent-mail
On Wed, Jan 14, 2009 at 03:54:06PM -0500, Hugo Villeneuve wrote:
Mark Brown broonie@sirena.org.uk wrote:
Speaking as the person who I expect most frequently tries that I wouldn't worry about it - it's easy enough to see what's happened and there will still be errors at link time even with the extern.
No, there won?t be errors when compiling as a module. Only when actually loading the module.
Check again - the kernel will detect those errors at build time. The module itself will compile but once all the modules are built Kbuild verifies that all the symbols they use can be found.
Hi Mark, I just checked again and at first I tought you were wrong :)
Just to be sure, I cloned a fresh copy of linux-davinci-git kernel. This tree doesn´t have the SFFSDR FPGA module with the sffsdr_fpga_set_codec_fs() function.
If I compile this tree as is for the SFFSDR board, I sure have the error for the missing header file <asm/plat-sffsdr/sffsdr-fpga.h>, containing the declaration for the function sffsdr_fpga_set_codec_fs. But if I remove the #include for that header file and add the following extern declaration:
extern int sffsdr_fpga_set_codec_fs(int fs);
I can successfully compile the whole kernel and all the selected modules without any errors.
But in fact you were right, because I just found out that someone has added the following check to sffsdr_init() in davinci-sffsdr.c:
if (!machine_is_sffsdr()) return -EINVAL;
For a reason that I don´t yet understand, that function doesn´t seem to be defined (always return 0) and so gcc has correctly optimised my module by removing the sffsdr_hw_params function, and thus also removing the call to my sffsdr_fpga_set_codec_fs function, and this is why Kbuild never complained!
That's good news - previously it would fail to build at all. What sort of breakage are you seeing (and what was the version you used when you developed the driver)?
I developped the driver with version 2.6.27-rc6-davinci1-05187-g91c2c53.
The breakage I see when I run the aplay utility is this:
aplay: pcm_write:1394: write error: Input/output error
davinci-git version is the latest as of january 14 (2.6.28-davinci1-06546-gcfb152b)
Hrm, OK. That's not terribly informative - does the error get reported after about 10 seconds by any chance? I suspect that DMA just isn't happening.
Sorry about the non-verbosity :) Yes it happens almost exactly after 10 seconds. I´m not an expert with audio nor DMA, but can you indicate me where I should be looking for signs of trouble (which source files for example)?
Thank-you, Hugo.
--------------- Hugo Villeneuve www.hugovil.com ---------------
On Thu, Jan 15, 2009 at 02:54:54PM -0500, Hugo Villeneuve wrote:
Mark Brown broonie@sirena.org.uk wrote:
The breakage I see when I run the aplay utility is this:
aplay: pcm_write:1394: write error: Input/output error
davinci-git version is the latest as of january 14 (2.6.28-davinci1-06546-gcfb152b)
Hrm, OK. That's not terribly informative - does the error get reported after about 10 seconds by any chance? I suspect that DMA just isn't happening.
Sorry about the non-verbosity :)
I actually meant the error message rather than your posting, sorry!
Yes it happens almost exactly after 10 seconds. I?m not an expert with audio nor DMA, but can you indicate me where I should be looking for signs of trouble (which source files for example)?
sound/soc/davinci/davinci-pcm.c and the underlying DMA APIs it calls. I wouldn't be surprised if either there had been some change in the DMA APIs that required an update in the driver or the DMA APIs haven't been fully merged.
Hopefully a comparison of the mainline and DaVinci trees will show something...
On Thu, 15 Jan 2009 20:01:22 +0000 Mark Brown broonie@sirena.org.uk wrote:
On Thu, Jan 15, 2009 at 02:54:54PM -0500, Hugo Villeneuve wrote:
Mark Brown broonie@sirena.org.uk wrote:
The breakage I see when I run the aplay utility is this:
aplay: pcm_write:1394: write error: Input/output error
davinci-git version is the latest as of january 14 (2.6.28-davinci1-06546-gcfb152b)
Hrm, OK. That's not terribly informative - does the error get reported after about 10 seconds by any chance? I suspect that DMA just isn't happening.
Sorry about the non-verbosity :)
I actually meant the error message rather than your posting, sorry!
I know :)
In the meantime, I will send you a patch that will fix the compilation problems for the SFFSDR ASoC module.
Yes it happens almost exactly after 10 seconds. I?m not an expert
with audio nor DMA, but can you indicate me where I should be looking for signs of trouble (which source files for example)?
sound/soc/davinci/davinci-pcm.c and the underlying DMA APIs it calls. I wouldn't be surprised if either there had been some change in the DMA APIs that required an update in the driver or the DMA APIs haven't been fully merged.
Hopefully a comparison of the mainline and DaVinci trees will show something...
Anyone on the DaVinci mailing list that could shed some light on this issue?
Thank-you, Hugo.
--------------- Hugo Villeneuve www.hugovil.com ---------------
Mark Brown wrote:
On Thu, Jan 15, 2009 at 02:54:54PM -0500, Hugo Villeneuve wrote:
Mark Brown broonie@sirena.org.uk wrote:
The breakage I see when I run the aplay utility is this:
aplay: pcm_write:1394: write error: Input/output error
davinci-git version is the latest as of january 14 (2.6.28-davinci1-06546-gcfb152b)
Hrm, OK. That's not terribly informative - does the error get reported after about 10 seconds by any chance? I suspect that DMA just isn't happening.
Sorry about the non-verbosity :)
I actually meant the error message rather than your posting, sorry!
Yes it happens almost exactly after 10 seconds. I?m not an expert with audio nor DMA, but can you indicate me where I should be looking for signs of trouble (which source files for example)?
sound/soc/davinci/davinci-pcm.c and the underlying DMA APIs it calls. I wouldn't be surprised if either there had been some change in the DMA APIs that required an update in the driver or the DMA APIs haven't been fully merged.
Hopefully a comparison of the mainline and DaVinci trees will show something... _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
In davinci-sffsdr.c I see
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_RIGHT_J | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_IB_NF);
When I changed the evm board flags passed, I didn't change this file. So, you'll need something like
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_NB_NF);
But, you should be seeing error messages.
Troy
On Thu, 15 Jan 2009 15:10:01 -0700 Troy Kisky troy.kisky@boundarydevices.com wrote:
Hopefully a comparison of the mainline and DaVinci trees will show something...
In davinci-sffsdr.c I see
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_RIGHT_J | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_IB_NF);
When I changed the evm board flags passed, I didn't change this file. So, you'll need something like
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_NB_NF);
I´m not using the same codec as on the EVM. I´m using the PCM3008 and I need to use the right-justified mode and the SND_SOC_DAIFMT_IB_NF flag for it to work (it used to work a few weeks/months ago).
But, you should be seeing error messages.
Did someone test the latest git tree and audio on a DM644x EVM to see if it still works?
Hugo.
--------------- Hugo Villeneuve www.hugovil.com ---------------
Hugo Villeneuve wrote:
On Thu, 15 Jan 2009 15:10:01 -0700 Troy Kisky troy.kisky@boundarydevices.com wrote:
Hopefully a comparison of the mainline and DaVinci trees will show something...
In davinci-sffsdr.c I see
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_RIGHT_J | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_IB_NF);
When I changed the evm board flags passed, I didn't change this file. So, you'll need something like
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_NB_NF);
I´m not using the same codec as on the EVM.
I know your not using the AIC33, but if your using davinci-i2s, then the change will affect you.
I´m using the PCM3008 and I need to use the right-justified mode and the SND_SOC_DAIFMT_IB_NF flag for it to work (it used to work a few weeks/months ago).
Davinci does not support a general right justified mode. But DSP_A may be close enough. Especially if it worked before.
But, you should be seeing error messages.
Did someone test the latest git tree and audio on a DM644x EVM to see if it still works?
I don't have an evm, but our custom board works fine.
Troy
Hugo Villeneuve wrote:
On Thu, 15 Jan 2009 15:10:01 -0700 Troy Kisky troy.kisky@boundarydevices.com wrote:
Hopefully a comparison of the mainline and DaVinci trees will show something...
In davinci-sffsdr.c I see
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_RIGHT_J | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_IB_NF);
When I changed the evm board flags passed, I didn't change this file. So, you'll need something like
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_NB_NF);
Actually, that should be
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_NB_NF);
I had dsp_a and dsp_b backwards again.
Troy
On Thu, 15 Jan 2009 15:50:52 -0700 Troy Kisky troy.kisky@boundarydevices.com wrote:
Hugo Villeneuve wrote:
On Thu, 15 Jan 2009 15:10:01 -0700 Troy Kisky troy.kisky@boundarydevices.com wrote:
Hopefully a comparison of the mainline and DaVinci trees will show something...
In davinci-sffsdr.c I see
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_RIGHT_J | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_IB_NF);
When I changed the evm board flags passed, I didn't change this file. So, you'll need something like
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_NB_NF);
Actually, that should be
ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_NB_NF);
I had dsp_a and dsp_b backwards again.
Hi Troy, Finally the problem was hardware related. The PLL feeding the clocks to the ASP was dead, so that is why the DMA were never triggered. I replaced it and everything is working fine now, using my original config: SND_SOC_DAIFMT_RIGHT_J | SND_SOC_DAIFMT_CBM_CFS | SND_SOC_DAIFMT_IB_NF);
Mark: this also means that the latest davinci git tree has working audio support (without needing any DMA patch) :)
Thank-you all, Hugo.
--------------- Hugo Villeneuve www.hugovil.com ---------------
participants (4)
-
David Brownell -
Hugo Villeneuve -
Mark Brown -
Troy Kisky