[alsa-devel] Fix audio for Lyrtech SFFSDR board
This prevented the FPGA from properly configuring the codec FS when the SFFSDR FPGA was compiled as a module.
Signed-off-by: Hugo Villeneuve hugo@hugovil.com --- sound/soc/davinci/davinci-sffsdr.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/sound/soc/davinci/davinci-sffsdr.c b/sound/soc/davinci/davinci-sffsdr.c index 74f1eb3..1d10957 100644 --- a/sound/soc/davinci/davinci-sffsdr.c +++ b/sound/soc/davinci/davinci-sffsdr.c @@ -25,10 +25,10 @@
#include <asm/dma.h> #include <asm/mach-types.h> -#ifdef CONFIG_SFFSDR_FPGA -#include <asm/plat-sffsdr/sffsdr-fpga.h> -#endif
+#if defined(CONFIG_SFFSDR_FPGA) || defined(CONFIG_SFFSDR_FPGA_MODULE) +#include <mach/sffsdr-fpga.h> +#endif #include <mach/asp.h> #include <mach/edma.h>
@@ -48,7 +48,7 @@ static int sffsdr_hw_params(struct snd_pcm_substream *substream, /* Fsref can be 32000, 44100 or 48000. */ fs = params_rate(params);
-#ifndef CONFIG_SFFSDR_FPGA +#if !defined(CONFIG_SFFSDR_FPGA) && !defined(CONFIG_SFFSDR_FPGA_MODULE) /* Without the FPGA module, the Fs is fixed at 44100 Hz */ if (fs != 44100) { pr_debug("warning: only 44.1 kHz is supported without SFFSDR FPGA module\n"); @@ -68,10 +68,10 @@ static int sffsdr_hw_params(struct snd_pcm_substream *substream,
pr_debug("sffsdr_hw_params: rate = %d Hz\n", fs);
-#ifndef CONFIG_SFFSDR_FPGA - return 0; -#else +#if defined(CONFIG_SFFSDR_FPGA) || defined(CONFIG_SFFSDR_FPGA_MODULE) return sffsdr_fpga_set_codec_fs(fs); +#else + return 0; #endif }
On Mon, Mar 09, 2009 at 11:32:06PM -0400, Hugo Villeneuve wrote:
This prevented the FPGA from properly configuring the codec FS when the SFFSDR FPGA was compiled as a module.
This doesn't apply against mainline either. Please regenerate against the topic/asoc branch of:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
Signed-off-by: Hugo Villeneuve hugo@hugovil.com --- sound/soc/davinci/davinci-sffsdr.c | 17 ++++++++++------- 1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/sound/soc/davinci/davinci-sffsdr.c b/sound/soc/davinci/davinci-sffsdr.c index 1d10957..b338c71 100644 --- a/sound/soc/davinci/davinci-sffsdr.c +++ b/sound/soc/davinci/davinci-sffsdr.c @@ -36,6 +36,14 @@ #include "davinci-pcm.h" #include "davinci-i2s.h"
+/* + * CLKX and CLKR are the inputs for the Sample Rate Generator. + * FSX and FSR are outputs, driven by the sample Rate Generator. + */ +#define AUDIO_FORMAT (SND_SOC_DAIFMT_DSP_B | \ + SND_SOC_DAIFMT_CBM_CFS | \ + SND_SOC_DAIFMT_IB_NF) + static int sffsdr_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params, struct snd_soc_dai *dai) @@ -56,13 +64,8 @@ static int sffsdr_hw_params(struct snd_pcm_substream *substream, } #endif
- /* Set cpu DAI configuration: - * CLKX and CLKR are the inputs for the Sample Rate Generator. - * FSX and FSR are outputs, driven by the sample Rate Generator. */ - ret = snd_soc_dai_set_fmt(cpu_dai, - SND_SOC_DAIFMT_RIGHT_J | - SND_SOC_DAIFMT_CBM_CFS | - SND_SOC_DAIFMT_IB_NF); + /* set cpu DAI configuration */ + ret = snd_soc_dai_set_fmt(cpu_dai, AUDIO_FORMAT); if (ret < 0) return ret;
Signed-off-by: Hugo Villeneuve hugo@hugovil.com --- sound/soc/davinci/davinci-sffsdr.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/sound/soc/davinci/davinci-sffsdr.c b/sound/soc/davinci/davinci-sffsdr.c index b338c71..7fdfba8 100644 --- a/sound/soc/davinci/davinci-sffsdr.c +++ b/sound/soc/davinci/davinci-sffsdr.c @@ -45,8 +45,7 @@ SND_SOC_DAIFMT_IB_NF)
static int sffsdr_hw_params(struct snd_pcm_substream *substream, - struct snd_pcm_hw_params *params, - struct snd_soc_dai *dai) + struct snd_pcm_hw_params *params) { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
Signed-off-by: Hugo Villeneuve hugo@hugovil.com --- sound/soc/davinci/davinci-sffsdr.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/sound/soc/davinci/davinci-sffsdr.c b/sound/soc/davinci/davinci-sffsdr.c index 7fdfba8..1fc53c1 100644 --- a/sound/soc/davinci/davinci-sffsdr.c +++ b/sound/soc/davinci/davinci-sffsdr.c @@ -31,6 +31,7 @@ #endif #include <mach/asp.h> #include <mach/edma.h> +#include <mach/mux.h>
#include "../codecs/pcm3008.h" #include "davinci-pcm.h" @@ -135,6 +136,8 @@ static int __init sffsdr_init(void) if (!machine_is_sffsdr()) return -EINVAL;
+ davinci_cfg_reg(DM644X_MCBSP); + sffsdr_snd_device = platform_device_alloc("soc-audio", 0); if (!sffsdr_snd_device) { printk(KERN_ERR "platform device allocation failed\n");
On Mon, Mar 09, 2009 at 11:32:09PM -0400, Hugo Villeneuve wrote:
return -EINVAL;
- davinci_cfg_reg(DM644X_MCBSP);
I can't find any references to this function in mainline? Most of the ARM variants do this sort of configuration in the arch/arm code which was why I was looking for other users to see what was idiomatic for DaVinci.
I've applied the other three patches.
On Tue, 10 Mar 2009 10:29:23 +0000 Mark Brown broonie@sirena.org.uk wrote:
On Mon, Mar 09, 2009 at 11:32:09PM -0400, Hugo Villeneuve wrote:
return -EINVAL;
- davinci_cfg_reg(DM644X_MCBSP);
I can't find any references to this function in mainline?
Hi Mark, I based those patches on the latest linux-davinci git tree, which has the function.
Most of the ARM variants do this sort of configuration in the arch/arm code which was why I was looking for other users to see what was idiomatic for DaVinci.
In fact I just duplicated what was done for the evm board in sound/soc/davinci/davinci-evm.c, which also has the davinci_cfg_reg() function (in the linux-davinci tree):
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=commit...
I've applied the other three patches.
Thanks, Hugo V.
On Tue, Mar 10, 2009 at 10:03:41AM -0400, Hugo Villeneuve wrote:
I based those patches on the latest linux-davinci git tree, which has the function.
Do not submit patches for mainline which are not based on mainline trees. Code which relies on out of tree changes needs to wait for those out of tree changes to be merged before submitting to mainline.
On Tue, 10 Mar 2009 15:16:32 +0000 Mark Brown broonie@sirena.org.uk wrote:
On Tue, Mar 10, 2009 at 10:03:41AM -0400, Hugo Villeneuve wrote:
I based those patches on the latest linux-davinci git tree, which has the function.
Do not submit patches for mainline which are not based on mainline trees. Code which relies on out of tree changes needs to wait for those out of tree changes to be merged before submitting to mainline.
I did not know that these changes were not in mainline yet. I was told that all davinci ASoC code changes were to be submitted only to ALSA, and then were imported back into the davinci git tree. Apparently this is not quite like that anymore.
Kevin, what is the new rule to submit davinci ASoC patches?
Hugo V.
Hugo Villeneuve hugo@hugovil.com writes:
On Tue, 10 Mar 2009 15:16:32 +0000 Mark Brown broonie@sirena.org.uk wrote:
On Tue, Mar 10, 2009 at 10:03:41AM -0400, Hugo Villeneuve wrote:
I based those patches on the latest linux-davinci git tree, which has the function.
Do not submit patches for mainline which are not based on mainline trees. Code which relies on out of tree changes needs to wait for those out of tree changes to be merged before submitting to mainline.
I did not know that these changes were not in mainline yet. I was told that all davinci ASoC code changes were to be submitted only to ALSA, and then were imported back into the davinci git tree. Apparently this is not quite like that anymore.
Kevin, what is the new rule to submit davinci ASoC patches?
The DaVinci ASoC code is indeed in mainline, but not all of the DaVinci core (in this case the pin mux) is yet in mainline. I will be pushing it during the next merge window.
On a related note, sound/soc/davinci/davinci-[evm,sffsdr].c is actually board-level setup code and should not actually live in sound/asoc/. It should live in arch/arm/mach-davinci/* and follow the rest of the davinci chip/board code upstream.
Kevin
On Tue, Mar 10, 2009 at 08:55:06AM -0700, Kevin Hilman wrote:
On a related note, sound/soc/davinci/davinci-[evm,sffsdr].c is actually board-level setup code and should not actually live in sound/asoc/. It should live in arch/arm/mach-davinci/* and follow the rest of the davinci chip/board code upstream.
No, the ASoC APIs are not stable enough for this - putting this code in arch/arm will just lead to merge pain when code from one tree goes in without updates from the other.
Experience also suggests that audio drivers often get substantial enough and need sufficient review to warrant keeping separate from the core machine code.
Mark Brown broonie@sirena.org.uk writes:
On Tue, Mar 10, 2009 at 08:55:06AM -0700, Kevin Hilman wrote:
On a related note, sound/soc/davinci/davinci-[evm,sffsdr].c is actually board-level setup code and should not actually live in sound/asoc/. It should live in arch/arm/mach-davinci/* and follow the rest of the davinci chip/board code upstream.
No, the ASoC APIs are not stable enough for this - putting this code in arch/arm will just lead to merge pain when code from one tree goes in without updates from the other.
Experience also suggests that audio drivers often get substantial enough and need sufficient review to warrant keeping separate from the core machine code.
OK, good to know your opinion there.
Thanks,
Kevin
On Tue, 10 Mar 2009 08:55:06 -0700 Kevin Hilman khilman@deeprootsystems.com wrote:
Hugo Villeneuve hugo@hugovil.com writes:
On Tue, 10 Mar 2009 15:16:32 +0000 Mark Brown broonie@sirena.org.uk wrote:
On Tue, Mar 10, 2009 at 10:03:41AM -0400, Hugo Villeneuve wrote:
I based those patches on the latest linux-davinci git tree, which has the function.
Do not submit patches for mainline which are not based on mainline trees. Code which relies on out of tree changes needs to wait for those out of tree changes to be merged before submitting to mainline.
I did not know that these changes were not in mainline yet. I was told that all davinci ASoC code changes were to be submitted only to ALSA, and then were imported back into the davinci git tree. Apparently this is not quite like that anymore.
Kevin, what is the new rule to submit davinci ASoC patches?
The DaVinci ASoC code is indeed in mainline, but not all of the DaVinci core (in this case the pin mux) is yet in mainline. I will be pushing it during the next merge window.
That doesn't really answer my question.
I can see that David Brownell pushed a patch to the davinci tree directly modifying sound/soc/davinci/davinci-evm.c which IS in mainline. Does this means that as of now all ASoC patches should be sent first to the Davinci list, and then you will push those to the mainline kernel?
On a related note, sound/soc/davinci/davinci-[evm,sffsdr].c is actually board-level setup code and should not actually live in sound/asoc/. It should live in arch/arm/mach-davinci/* and follow the rest of the davinci chip/board code upstream.
Kevin, you have said the same things months ago and I agree with you. When you or someone else move the evm stuff back into arch/arm/mach-davinci, I will be more than happy to do the same for the SFFSDR.
Hugo V.
Hugo Villeneuve hugo@hugovil.com writes:
On Tue, 10 Mar 2009 08:55:06 -0700 Kevin Hilman khilman@deeprootsystems.com wrote:
Hugo Villeneuve hugo@hugovil.com writes:
On Tue, 10 Mar 2009 15:16:32 +0000 Mark Brown broonie@sirena.org.uk wrote:
On Tue, Mar 10, 2009 at 10:03:41AM -0400, Hugo Villeneuve wrote:
I based those patches on the latest linux-davinci git tree, which has the function.
Do not submit patches for mainline which are not based on mainline trees. Code which relies on out of tree changes needs to wait for those out of tree changes to be merged before submitting to mainline.
I did not know that these changes were not in mainline yet. I was told that all davinci ASoC code changes were to be submitted only to ALSA, and then were imported back into the davinci git tree. Apparently this is not quite like that anymore.
Kevin, what is the new rule to submit davinci ASoC patches?
The DaVinci ASoC code is indeed in mainline, but not all of the DaVinci core (in this case the pin mux) is yet in mainline. I will be pushing it during the next merge window.
That doesn't really answer my question.
I can see that David Brownell pushed a patch to the davinci tree directly modifying sound/soc/davinci/davinci-evm.c which IS in mainline. Does this means that as of now all ASoC patches should be sent first to the Davinci list, and then you will push those to the mainline kernel?
No ASoc patches should be generated against an ASoC tree and submitted to alsa-devel, and CC davinci list.
This means that the until the DaVinci core is in mainline, DaVinci git will have slightly different looking ASoC drivers, but those changes will be minimal.
Kevin
On Tue, 10 Mar 2009 09:20:15 -0700 Kevin Hilman khilman@deeprootsystems.com wrote:
Hugo Villeneuve hugo@hugovil.com writes:
On Tue, 10 Mar 2009 08:55:06 -0700 Kevin Hilman khilman@deeprootsystems.com wrote:
Hugo Villeneuve hugo@hugovil.com writes:
On Tue, 10 Mar 2009 15:16:32 +0000 Mark Brown broonie@sirena.org.uk wrote:
On Tue, Mar 10, 2009 at 10:03:41AM -0400, Hugo Villeneuve wrote:
I based those patches on the latest linux-davinci git tree, which has the function.
Do not submit patches for mainline which are not based on mainline trees. Code which relies on out of tree changes needs to wait for those out of tree changes to be merged before submitting to mainline.
I did not know that these changes were not in mainline yet. I was told that all davinci ASoC code changes were to be submitted only to ALSA, and then were imported back into the davinci git tree. Apparently this is not quite like that anymore.
Kevin, what is the new rule to submit davinci ASoC patches?
The DaVinci ASoC code is indeed in mainline, but not all of the DaVinci core (in this case the pin mux) is yet in mainline. I will be pushing it during the next merge window.
That doesn't really answer my question.
I can see that David Brownell pushed a patch to the davinci tree directly modifying sound/soc/davinci/davinci-evm.c which IS in mainline. Does this means that as of now all ASoC patches should be sent first to the Davinci list, and then you will push those to the mainline kernel?
No ASoc patches should be generated against an ASoC tree and submitted to alsa-devel, and CC davinci list.
This means that the until the DaVinci core is in mainline, DaVinci git will have slightly different looking ASoC drivers, but those changes will be minimal.
Ok, so the patch affecting sound/soc/davinci/davinci-evm.c SHOULD have been submitted to ALSA first.
It is not easy following you guys. You say something and then do the opposite.
Hugo V.
Hugo Villeneuve hugo@hugovil.com writes:
On Tue, 10 Mar 2009 09:20:15 -0700 Kevin Hilman khilman@deeprootsystems.com wrote:
Hugo Villeneuve hugo@hugovil.com writes:
On Tue, 10 Mar 2009 08:55:06 -0700 Kevin Hilman khilman@deeprootsystems.com wrote:
Hugo Villeneuve hugo@hugovil.com writes:
On Tue, 10 Mar 2009 15:16:32 +0000 Mark Brown broonie@sirena.org.uk wrote:
On Tue, Mar 10, 2009 at 10:03:41AM -0400, Hugo Villeneuve wrote:
> I based those patches on the latest linux-davinci git tree, > which has the function.
Do not submit patches for mainline which are not based on mainline trees. Code which relies on out of tree changes needs to wait for those out of tree changes to be merged before submitting to mainline.
I did not know that these changes were not in mainline yet. I was told that all davinci ASoC code changes were to be submitted only to ALSA, and then were imported back into the davinci git tree. Apparently this is not quite like that anymore.
Kevin, what is the new rule to submit davinci ASoC patches?
The DaVinci ASoC code is indeed in mainline, but not all of the DaVinci core (in this case the pin mux) is yet in mainline. I will be pushing it during the next merge window.
That doesn't really answer my question.
I can see that David Brownell pushed a patch to the davinci tree directly modifying sound/soc/davinci/davinci-evm.c which IS in mainline. Does this means that as of now all ASoC patches should be sent first to the Davinci list, and then you will push those to the mainline kernel?
No ASoc patches should be generated against an ASoC tree and submitted to alsa-devel, and CC davinci list.
This means that the until the DaVinci core is in mainline, DaVinci git will have slightly different looking ASoC drivers, but those changes will be minimal.
Ok, so the patch affecting sound/soc/davinci/davinci-evm.c SHOULD have been submitted to ALSA first.
Yes, but it should've been a patch against an ASoC tree, not against DaVinci git which may contain things not (yet) in the ASoC tree.
It is not easy following you guys. You say something and then do the opposite.
Heh, sorry.
Do as I do, not as I say. ;)
Kevin
On Tuesday 10 March 2009, Kevin Hilman wrote:
Ok, so the patch affecting sound/soc/davinci/davinci-evm.c SHOULD have been submitted to ALSA first.
Yes, but it should've been a patch against an ASoC tree, not against DaVinci git which may contain things not (yet) in the ASoC tree.
It is not easy following you guys. You say something and then do the opposite.
Heh, sorry.
Do as I do, not as I say. ;)
I'd say "my bad" ... but in these cases there's seems to be no better solution than having the DaVinci GIT tree diverge a bit from mainline ASoC, in synchrony with arch/arm/mach-davinci which is also diverging from mainline.
There's a general rule that patches should not break builds. And that rule is why there are several ASoC patches I've not yet sent to mainline.
The whole ASoC/DaVinci thing has been nothing but build breakage however, since it depends on EDMA patches which haven't yet gone to mainline. (But, I believe, will soon do so, at which point that breakage will stop.)
- Dave
On Tue, Mar 10, 2009 at 01:07:34PM -0400, Hugo Villeneuve wrote:
It is not easy following you guys. You say something and then do the opposite.
There's a very simple rule which works for all upstream submissions: always generate patches against the tree which the patches are being submitted to. If there are changes that have cross-tree dependencies then those need to be resolved on a case by case basis - normally the best thing to there is for the affected patches to take the same path as whatever they depend on.
It is normal and expected for the different trees people merge on to diverge during a release cycle: for example, changes to a subsystem may well affect large portions of that subsystem while architecture changes may affect a wide range of drivers.
participants (4)
-
David Brownell -
Hugo Villeneuve -
Kevin Hilman -
Mark Brown