Re: [PATCHv2 2/2] [VIRTEX] Register AC97 Controller Reference with the platform bus
Hi Grant, Takashi, Stephen,
I tried to correct the issues here, too. But unfortunately Xilinx EDK
uses such long #define macro names. I guess we have to leave it the way
it is?
From: Joachim Foerster <[EMAIL PROTECTED]>
(Patch for Linus' master branch, date 2007/08/08)
Signed-off-by: Joachim Foerster <[EMAIL PROTECTED]>
---
arch/ppc/syslib/virtex_devices.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
index 62a9495..d0b04d6 100644
--- a/arch/ppc/syslib/virtex_devices.c
+++ b/arch/ppc/syslib/virtex_devices.c
@@ -121,6 +121,29 @@
}, \
}
+#define XPAR_AC97_CONTROLLER_REFERENCE(num) { \
+ .name = "ml403-ac97cr", \
+ .id = num, \
+ .num_resources = 3, \
+ .resource = (struct resource[]) { \
+ { \
+ .start = XPAR_OPB_AC97_CONTROLLER_REF_##num##_BASEADDR,
\
+ .end = XPAR_OPB_AC97_CONTROLLER_REF_##num##_HIGHADDR, \
+ .flags = IORESOURCE_MEM, \
+ }, \
+ { \
+ .start =
XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_##num##_PLAYBACK_INTERRUPT_INTR, \
+ .end =
XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_##num##_PLAYBACK_INTERRUPT_INTR, \
+ .flags = IORESOURCE_IRQ, \
+ }, \
+ { \
+ .start =
XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_##num##_RECORD_INTERRUPT_INTR, \
+ .end =
XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_##num##_RECORD_INTERRUPT_INTR, \
+ .flags = IORESOURCE_IRQ, \
+ }, \
+ }, \
+}
+
/* UART 8250 driver platform data table */
struct plat_serial8250_port virtex_serial_platform_data[] = {
#if defined(XPAR_UARTNS550_0_BASEADDR)
@@ -221,6 +244,11 @@ struct platform_device virtex_platform_devices[] = {
#if defined(XPAR_TFT_3_BASEADDR)
XPAR_TFT(3),
#endif
+
+ /* AC97 Controller Reference instances */
+#if defined(XPAR_OPB_AC97_CONTROLLER_REF_0_BASEADDR)
+ XPAR_AC97_CONTROLLER_REFERENCE(0),
+#endif
};
/* Early serial support functions */
--
1.5.2.4
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [alsa-devel] [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
Hi Takashi, again some question came up (while correcting all the other issues): On Thu, 2007-08-09 at 19:13 +0200, Takashi Iwai wrote: > > +static int __init > > +snd_ml403_ac97cr_create(struct snd_card *card, struct platform_device > > *pfdev, > > + struct snd_ml403_ac97cr **rml403_ac97cr) > > It's no longer __init as long as you use platform_device. > It should be __devinit instead. Ok, I changed that (for create(), pcm(), mixer(), etc.). Do I have to change it for the module_init and module_exit functions, too? I guess, they are not in the "scope" of platform device, right? So, they will keep __init / __exit ? > > --- /dev/null > > +++ b/sound/ppc/pcm-indirect2.h > (snip) > > +#ifdef SND_PCM_INDIRECT2_STAT > > +static inline void snd_pcm_indirect2_stat(struct snd_pcm_substream > > *substream, > > + struct snd_pcm_indirect2 *rec) > > Remove inline from the functions in this file. They are too lengthy. > > sound/pcm-indirect.h contain inline functions becuase they are > relatively small, and I didn't want to add them in the core module > unconditionally. I looked at my functions again. And I think we could still go with inline for the *_interrupt() and *_pointer() functions since they have just a few lines. With both *_transfer() functions - I don't know. In fact they shouldn't be much longer than yours in pcm-indirect.h . They seem long, because there are lot of comments and the #ifdef SND_PCM_INDIRECT2_STAT stuff, which is/was a debugging feature, which _won't_ be compiled in without CONFIG_SND_DEBUG. [I removed inline from the _stat() and _min_periods() function - that's true, they are too long.] The other thing I thought about, is: Is it ok to have non-inline functions in a header file? Don't we need a .c file + .h ? (Are there any CodingStyle rules about that?) Joachim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
Hi Grant, On Thu, 2007-08-09 at 11:49 -0600, Grant Likely wrote: > > diff --git a/sound/ppc/Makefile b/sound/ppc/Makefile > > index eacee2d..827f2f5 100644 > > --- a/sound/ppc/Makefile > > +++ b/sound/ppc/Makefile > > Couldn't this end up on MicroBlaze too? If so, sound/ppc is the wrong place. Well, I don't know. The only arch depended calls I use (am aware of) are in/out_be32(), so this _might_ work for mb, too. (I won't be able to test that in the next few months ...) On Thu, 2007-08-09 at 11:17 -0700, Stephen Neuendorffer wrote: > I second grant here... this should eventually work on microblaze, too, > so putting it drivers/ and using XILINX_DRIVERS instead of XILINX_VIRTEX > (based on the patch Wolfgang recently posted) would probably be preferable. > > > + > > +config SND_ML403_AC97CR > > + tristate "Xilinx ML403 AC97 Controller Reference" > > + depends on SND && XILINX_VIRTEX > > Steve So, like Stephen Neuendorffer said, I should move it to sound/drivers, right? Takashi? On Thu, 2007-08-09 at 11:49 -0600, Grant Likely wrote: > > +snd-ml403_ac97cr-objs := ml403_ac97cr.o > > This line is only needed if you're compiling multiple .c files into one .ko Ah, well, then I have to rename the main .c file. But all the other ALSA drivers seem to _not_ include the "snd-" in front of it (ok, except the new PS3 driver and maybe other new ones?) > I'll try adding your patches to my tree this afternoon. I made patch against your tree, too (like a said before). Tell me, then I post it ... Joachim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [alsa-devel] [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
Hi Takashi,
before posting a corrected version, I would like to ask some unclear
things (I think I understood the rest):
On Thu, 2007-08-09 at 19:13 +0200, Takashi Iwai wrote:
> (snip)
> > +static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
> > +static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;
> > +static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE;
>
> Can the driver really support multiple instances?
> If not, better to avoid these arrays.
Well, while I wrote the driver I considered that there might be more
than one instance - though I didn't test it and I won't be able to test
it (no such hardware available - with more than one LM4550 chip).
So, shall I remove it?
> > +struct lm4550_reg lm4550_regfile[64] = {
> > + {.reg = 0x00,
> > +.flag = LM4550_REG_NOSAVE | LM4550_REG_FAKEREAD,
> > +.def = 0x0D50},
>
> Better to use C99 style initialization here, e.g.
>
> [0x00] = { },
> [0x02] = { },
> [0x7e] = { },
>
> so you can avoid writing empty items.
> The index value could be also AC97_XXX, such as [AC97_MASTER] =
> {...}.
>
> What is the purpose of reg field at all, BTW? I guess it's
> superfluous.
No, it's there to provide a shadow copy of the codec's (LM4550)
registers. It contains default values and (while driver is running)
current values, which were written to the hardware. I had to introduce
this, because Xilinx's AC97 Controller Reference has a very ugly bug: It
provides a "register access finish" bit, so the driver is able to tell
when a register read or write access is finished. Unfortunately this
particular bit only works in the range of 0 to 100 times since board
reset. After that many register access it just remains saying: I'm _not_
ready. But in fact, in most cases (98%) the correct value already is the
read register (assume we have just said to the control that we want to
read a register).
I thought, ok we have such RegAccessFinished bit, so use it, if we have
to, until it doesn't work anymore.
So, through a shadow copy of most registers (some cannot be shadow or it
makes no sence) I can provide the values without having to actually read
from the controller/codec. The regfile also contains info which register
might be shadowed, if values get saved at all (if written) ...
Furthermore ALSA's AC97 layer does heavy initialization access series on
the codec, which I tried to "mask out" completely
(LM4550_REG_FAKEPROBE).
> > +#define LM4550_RF_FLAG(reg) lm4550_regfile[reg / 2].flag
> > +static void lm4550_regfile_init(void)
> > +{
> > + int i;
> > + for (i = 0; i < 128; i = i + 2)
> > + if (LM4550_RF_FLAG(i) & LM4550_REG_FAKEPROBE)
> > + LM4550_RF_VAL(i) = LM4550_RF_DEF(i);
>
> "MACRO(x) = XXX" looks a bit strange to me.
Hmmm, ok. I thought about that, too. I think, I'll spell them out?
> RATE_CONTINUOUS and RATE_KNOW are usually exclusive.
Ok, so what I want is RATE_CONTINUOUS, right? (because the LM4550
supports 4000 to 48000kHz in 1Hz steps)
BTW: What is RATE_KNOT good for?
Joachim
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: BUG-REPORT Re: ml403 ac97 driver
Hi Qin Lin, sorry for my late answer. On Tue, 2007-07-31 at 04:49 -0700, Qin Lin wrote: > When i used the aplay to test the drive first time,it played well. But > after restart the board > it is not well again. Well, I don't think the problem occurs due to the restart of your board ... > # aplay yonggan.wav > Playing WAVE 'yonggan.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, > Stereo > [ 258.518119] Kernel stack overflow in process c039ec00, r1=c3e0bf50 ... but unfortunately I can't tell how such an error results from the driver. Are you able to reproduce it? Since the driver "works", I never got such an error nor another kernel panic/error. [The only thing that comes to my mind is the very high interrupt volume, because of the very small size (32 byte) of the playback FIFO (of the AC97 controller) => hardware issue. But, since interrupts are _disabled_ during execution of interrupt handlers, I am sure that this cannot be the source of the problem.] Joachim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH 2/2] [VIRTEX] Register AC97 Controller Reference with the platform bus
From: Joachim Foerster <[EMAIL PROTECTED]>
(Patch for Linus' master branch, date 2007/08/08)
Signed-off-by: Joachim Foerster <[EMAIL PROTECTED]>
---
arch/ppc/syslib/virtex_devices.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
index 62a9495..0d6f0ac 100644
--- a/arch/ppc/syslib/virtex_devices.c
+++ b/arch/ppc/syslib/virtex_devices.c
@@ -121,6 +121,29 @@
}, \
}
+#define XPAR_AC97_CONTROLLER_REFERENCE(num) { \
+ .name = "ml403_ac97cr", \
+ .id = num, \
+ .num_resources = 3, \
+ .resource = (struct resource[]) { \
+ { \
+ .start = XPAR_OPB_AC97_CONTROLLER_REF_0_BASEADDR, \
+ .end = XPAR_OPB_AC97_CONTROLLER_REF_0_HIGHADDR, \
+ .flags = IORESOURCE_MEM, \
+ }, \
+ { \
+ .start =
XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_0_PLAYBACK_INTERRUPT_INTR, \
+ .end =
XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_0_PLAYBACK_INTERRUPT_INTR, \
+ .flags = IORESOURCE_IRQ, \
+ }, \
+ { \
+ .start =
XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_0_RECORD_INTERRUPT_INTR, \
+ .end =
XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_0_RECORD_INTERRUPT_INTR, \
+.flags = IORESOURCE_IRQ, \
+ }, \
+}, \
+}
+
/* UART 8250 driver platform data table */
struct plat_serial8250_port virtex_serial_platform_data[] = {
#if defined(XPAR_UARTNS550_0_BASEADDR)
@@ -221,6 +244,11 @@ struct platform_device virtex_platform_devices[] = {
#if defined(XPAR_TFT_3_BASEADDR)
XPAR_TFT(3),
#endif
+
+ /* AC97 Controller Reference instances */
+#if defined(XPAR_OPB_AC97_CONTROLLER_REF_0_BASEADDR)
+ XPAR_AC97_CONTROLLER_REFERENCE(0),
+#endif
};
/* Early serial support functions */
--
1.5.2.4
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ML403 / ALSA driver for AC97 Controller
Hi Grant, On Sat, 2007-07-21 at 14:17 -0600, Grant Likely wrote: > A few initial comments: > 1. You should post this code as a patch against the kernel tree. > Links to tarballs are not the best way to get code reviewed. Post > your patches to both the ALSA and linuxppc-dev mailing lists. > 2. (get this out of the way quickly) Coding standard doesn't match the > kernel (indent w/ tabs, keep lines < 80 chars, etc). You should run > your code through 'scripts/Lindent' in the kernel tree. That will > sort out many of the whitespace issues. > 3. In the same vein, c++ style comments need to be scrubbed. > 4. Do not directly include xparameters.h in your driver. The driver > should get it's data from the platform bus registration (of the > of_device registration when we move to arch/powerpc). > 5. struct 'platform_device devices[]' needs to be moved to > arch/ppc/sysdev/virtex_devices.c About a week ago I finished work on the last four issues and in last days I created several patches against different kernel trees. ATM I have three patches, against: tag v2.6.22 (Linus) branch master (Linus) branch virtex-dev (your v2.6.22 based branch) I had to make different patches, because one version didn't apply cleanly to the other branches, due to differences in a Kconfig file e.g. and above all in the virtex_devices.c file. Now, my question is: Which one should I post to the mailing list? (after testing these patches - I haven't got a chance yet to test them on real hardware - compilation is ok). One more thing: I made two parts, one patch adds the driver and the other one makes the registration with the platform bus. Is this ok? (I saw this scheme in your virtex-dev branch.) > 6. Have you looked into the new ALSA infrastructure which separates > Codecs from controllers (in sound/soc)? It might be a good idea to go > that route for this driver. Meanwhile, I had a _very_ short look into ASoC ... and I don't really know ... My driver already uses the AC97 Layer of ALSA, so in some way the codec is already separated from the controller. Xilinx' AC97 Controller Reference does have some very bad impact on the codec which forced me to implement codec register shadowing ... h, I have to look at it (ASoC) again - as soon as there is more (free)time ... Joachim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ml403 ac97 driver
Hi Qin Lin, On Mon, 2007-07-30 at 21:22 -0700, Qin Lin wrote: > 1.add the lm4550 driver to kernel source > (someboby may can add them as a patch to kernel source) In fact, in the last few days, I worked on my driver, made changes according to Grant Likely's list of comments (see the thread where I announced the driver). And right now, I'm preparing a patch against the official kernel tree. So, I'll post a patch soon myself - just view more days. Joachim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ml403 ac97 driver
Hi Qin Lin, On Sun, 2007-07-29 at 22:40 -0700, Qin Lin wrote: > # insmod ac97_bus.ko > # insmod snd-ac97-codec.ko > # insmod ml403_ac97cr.ko > [ 79.529114] ml403_ac97cr: remap controller memory region to 0xc500e000 > done > [ 79.611803] ml403_ac97cr: request (playback) irq 7 done > [ 79.674236] ml403_ac97cr: request (capture) irq 6 done > [ 79.784291] snd-ml403_ac97cr: write access to codec register 0x26 with > bad value 0x800f / 32783! > [ 79.900247] snd-ml403_ac97cr: write access to codec register 0x26 with > bad value 0xf / 15! > [ 80.004284] snd-ml403_ac97cr: write access to codec register 0x2a with > bad value 0x2801 / 10241! > [ 80.116228] snd-ml403_ac97cr: write access to codec register 0x2a with > bad value 0x3801 / 14337! Completely fine. > # ls -l /dev/snd > crw-rw-rw-1 root root 116, 0 Jan 1 00:01 controlC0 > crw-rw-rw-1 root root 116, 4 Jan 1 00:01 hwC0D0 > crw-rw-rw-1 root root 116, 5 Jan 1 00:01 hwC0D1 > crw-rw-rw-1 root root 116, 6 Jan 1 00:01 hwC0D2 > crw-rw-rw-1 root root 116, 7 Jan 1 00:01 hwC0D3 > crw-rw-rw-1 root root 116, 24 Jan 1 00:01 pcmC0D0c > crw-rw-rw-1 root root 116, 16 Jan 1 00:01 pcmC0D0p > crw-rw-rw-1 root root 116, 1 Jan 1 00:01 seq > crw-rw-rw-1 root root 116, 33 Jan 1 00:01 timer Ok, should suffice. [In my case snddevices made many other device files.] > # aplay -D /dev/snd/pcmC0D0p > ALSA lib pcm.c:2144:(snd_pcm_open_noupdate) Unknown PCM /dev/snd/pcmC0D0p Well, I think the way you specify the device is wrong. AFAIK the -D option only accepts names which are defined in an ALSA configuration file (.asoundrc & friends). Furthermore: Did you try without any device (without -D option)? The defaults should make ALSA pick the first available sound device. At least, while I was testing, I didn't have to specify any device. BTW: You need to specify the (.wav) file you want to play: # aplay music.wav Otherwise you won't here anything ;-). Read "man aplay" ! > # ./test_sound.out /dev/snd/pcmC0D0p > ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM /dev/snd/pcmC0D0p > cannot open audio device /dev/snd/pcmC0D0p (No such file or directory) Ditto. But I haven't had a look into test_sound source yet, but it might be the same issue. Joachim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ml403 ac97 driver
Hi qin lin, On Sat, 2007-07-28 at 17:04 +0800, qin lin wrote: > I have add the driver to kernel as a module in ml403.When i insmod > the module ,there are warnings followed here: > [ 250.795594] snd-ml403_ac97cr: write access to codec register 0x26 > with bad value 0x800f / 32783! > [ 250.911545] snd-ml403_ac97cr: write access to codec register 0x26 > with bad value 0xf / 15! > [ 251.015576] snd-ml403_ac97cr: write access to codec register 0x2a > with bad value 0x2801 / 10241! > [ 251.127524] snd-ml403_ac97cr: write access to codec register 0x2a > with bad value 0x3801 / 14337! > > And i check the warring find the warnings should be from function > snd_ml403_ac97cr_codec_write() ，i have check the lm4550 codec > datasheet to make sure the mask is what you have written. These warnings are ok. Codec register 0x26 is the "PowerDown Status/Control" register and the ALSA AC97 layer tries to write ones to the lower 4 bits (which are AFAIK read only bits). LM4550 register 0x2a has only one valid bit (lowest), but ALSA tries to write to a not existing bit. So my driver masks out these bits. The warnings show the invalid numbers ALSA wants to write to these registers. > What confused me is that where call the fuction > snd_ml403_ac97cr_codec_write in the module_init program, would you > mind if you point it for me? Well, the function alsa_card_ml403_ac97cr_init() is registered as the module_init function. It registers the driver and the device to the kernel via platform_driver/device_register(). As a consequence the kernel will call the registered probe() function called snd_ml403_ac97cr_probe(). Among other things, the function called snd_ml403_ac97cr_mixer() is invoked. Finally this function registers a mixer device and the codec_read() and codec_write() functions with the ALSA AC97 layer. While registering the ALSA AC97 layer calls the read and write functions several times - a kind of initialization sequence. That's the usual structure of an ALSA driver - not that simple - I know :-) . > There is another problem trouble me .I find a simple test program to > check the codec playback work .But all it said that it cannot find > the pcm file.Would you mind if you suggest something or paste what you > have do to mknod the device? Oh, I forgot to mention that in the README file. I used the "snddevices" script found in ALSA's alsa-driver package (form version 1.0.13, but version shouldn't matter). > # ./test_sound.out /dev/snd/pcmC0D0 > ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown > PCM /dev/snd/pcmC0D0 > cannot open audio device /dev/snd/pcmC0D0 (No such file or directory) Hmmm, try to create the device files with the script from above and see if that happens again ... BTW: (After having created the device files) you can also use aplay (alsa-utils package) for testing. Where did you find "test_sound"? Joachim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
ML403 / ALSA driver for AC97 Controller
Hi all, some days ago I "finished" a first working version of my ALSA driver for Xilinx' AC97 Controller Reference ip core, usually used on Xilinx' ML403 board. In fact it's a kind of byproduct of another project I am currently working on. Anybody interested in the driver may download it here: http://www.esic-solutions.com/support.html The version number 0.0.1-pre1 indicates, that it is a kind of (early) prerelease, which might be far from a "complete" state. So, if you have any problems with it, feel free to mail me ([EMAIL PROTECTED]). Or, if there are any suggestions, opinions, special experience ... etc., let me know it. The tar file contains a README, with all relevant info - I hope I didn't forget something important. Just one thing: Capture support basically works, but there are overruns after ~30s with rates > ~20kHz at least on the board and setup I'm working on => consider this to be a know bug. Playback support (which was the primary goal) seems to be pretty stable. I thought it would be a good idea to publish the driver, because over the last few months, there were - not much - but several mails on this list on sound support for the ML403. Joachim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: can anyone help me to test my ac97 driver
Hi silicom, On Fri, 2007-07-13 at 13:22 +0800, silicom wrote: > I have a simple oss ac97 playback driver for xilinx ml403 and > linux2.6.17 kernel,but when I test it with a *.wav file with sample > rate 44.1k, there is much noisy, and I want to know whether there's > problem with my ml403 board or ac97 driver,could anyone be kind to > help me test it on your board or point out my problem? Today I took some time and tried to compile your driver, but one of the first things I saw was that there is a file missing: "xac97_l.h". I think, it contains your "low level" functions. If you post the file, and I have some time, I'll test your driver and what it does on the board, which I have available. Furthermore your driver depends on xbasic_types.c/h, xio.c/h, which some people might not have, too ... especially xio.c/h (in my experience ;-) ) ... In my last mail (last week) I announced my driver for the AC97 Controller of Xilinx and said that I'm going to release/post it. Since then, I worked on it once more and now it seems to be pretty stable and usable (playback support). I added capture support, too. [Capturing basically works, but there is a problem with higher rates and ALSA not reading from the intermediate buffer anymore ... not yet investigated.] My driver will be published on a website soon. I'll post the link as soon as possible. Meanwhile, if you or anyone want to try it, just mail me ([EMAIL PROTECTED]). Joachim signature.asc Description: This is a digitally signed message part ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Can anyone help me about ac97 driver
Hi silicom, On Tue, 2007-07-03 at 10:22 +0800, silicom wrote: > I'm writing an ac97 driver with interrupt mode on xilinx ml403 and > linux 2.6.17.1 platform but encounter a incredible problem,can anyone > send me a copy of the driver code. I read your previous mails (about a problem with the interrupt handler). Mainly in the last few days/week I wrote an (ALSA) driver for the "Xilinx ML403 AC97 Controller Ref", too (ATM playback part only, no record). And I didn't encounter problems such as your problem. The only difference I see, is, that I don't have an explicit "write process": INT is thrown => INT handler: loop, copy data to the FIFO until full => return from INT handler. I had serious problems with the "Register Access Finished" bit, which stops working after (average) ~80 codec register accesses (bit remains 0). My driver is "working" since yesterday evening ;-) ... so I feel a bit uncertain about "releasing" it to the public right now. I'm willing to post/contribute my driver, but that will have to wait some more days/a week ;-) ... BTW: Is your driver an ALSA driver, too? Or is it an OSS driver? Joachim signature.asc Description: This is a digitally signed message part ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [Fwd: [alsa-devel] embedded sound architecture question]
Hi Sylvain, thank you very much for your mail, On Tue, 2007-05-15 at 09:09 +0200, Sylvain Munaut wrote: > I'm not an alsa expert but I'm working on a driver right now. And alsa > provide you a hook so you can allocate your memory buffer your self. > So as long as your control maps it's memory somewhere in the > cpu address space you should be fine. By "hook", do you mean the prepare()/hw_params() callbacks? I noticed that there is an (undocumented?) mmap() callback, too, so I think, I have to implement that one and call something like io_remap_pfn_range() to "connect" the device's memory to the VMA (virtual memory area) which is provided as an argument to the mmap() callback, right? In our case, we are not going to allocate any memory like a typical ALSA driver does (with DMA) (in prepare()/hw_params() callback), because the device's IO memory will "be there" - we just have to "announce"/map it into kernel space, right? Or is this interpretation wrong? Joachim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[Fwd: [alsa-devel] embedded sound architecture question]
Hi, I posted the following question/mail to the ALSA development mailing list and somebody suggested posting it to the LKML, but I thought, perhaps it is better to ask you, the Linux PPC embedded experts first, since it is right about that topic. It would be nice if somebody can say, if the described architecture makes sense and will work or if it is a complete no-go. Forwarded Message From: Joachim Förster <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [alsa-devel] embedded sound architecture question Date: Wed, 09 May 2007 22:47:34 +0200 Hi ALSA devs, I'm going to write an ALSA driver for a not yet existing AC97 controller, which is going to be "written" (VHDL), too (at the same time). Platform/Board is a Xilinx ML403 with Virtex-4 FPGA, PowerPC 405 architecture, OPB/OCP bus, AC97 Codec LM4550. Before presenting my question, I have to say, that I'm a beginner with ALSA/Linux driver development. My question is: Does the architecture described below make sense/is reasonable with ALSA and Linux? The problem is, that there is no DMA controller and implementing an OPB master device which would be able to do DMA itself is not an option at this time. So our thoughts were: Integrate the "DMA ring buffer" (which is usually somewhere in main memory/RAM) into the AC97 controller. Make ALSA access this HW buffer as if it was in main memory. This way, the device (AC97 controller) has "direct access" to its buffer "memory" - this could be called "fake DMA". The AC97 controller would have tell us where it is while playing and firing interrupts after one period, so that we don't write to values which are in the current period, instead update the area where of the past played periods etc. ... The buffer should be a "ring buffer", right? Mapping this "IO memory" into kernel space should be possible with io_remap_page_range(), right? I would have to implement the mmap() callback in my driver, to setup the given VMA (with the above function), right? So, ALSA library/applications will be able to use MMAP mode, which is what we want to achieve? [We don't want copy()/silence(). An intermediate buffer with ack()/tasklet/workqueue + FIFO in HW would be an alternative.] [snip] Thanks for reading & your time, Joachim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
ML403 and PPC4xx_DMA ?
Hi all, I have a question regarding the PowerPC 405 Core on the Xilinx ML403 board and DMA . The Linux kernel has an option called CONFIG_PPC4xx_DMA. Do all/some PowerPC 4xx Cores have an integrated DMA Controller? I tried to find some documentation about this DMA Controller in several Xilinx and IBM manuals which cover the PowerPC 405 Core - but I didn't find anything. So, my question is: Does the Virtex-4 FX12 PowerPC 405 Core on the ML403 have such DMA Controller? If yes, is it usable within Linux to transfer data from RAM to a device's hardware buffers (typical task of a DMA controller)? Thanks, Joachim PS: I tried to compile a kernel image with CONFIG_PPC4xx_DMA enabled, but gcc complains about missing definitions in ppc4xx_dma.c ... e.g. DCRN_DMASR (defined in ibm405.h). Well I guess I have to have DCRN_MASR_BASE defined in xparameters_ml403.h but defined to what? ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
