Hi all,
I try to write a native sound driver for the Geode GX1/5530a Companion chip. Problem here: The sound chip only generates SMI. Does anyone knows a trick or a chipset switch that let me forward this SMI to a regular IRQ? Its too ugly to use a polling loop.... ;-)
Regards, Juergen
Hi all,
On Monday 07 August 2006 11:19, myself wrote:
I try to write a native sound driver for the Geode GX1/5530a Companion chip. Problem here: The sound chip only generates SMI. Does anyone knows a trick or a chipset switch that let me forward this SMI to a regular IRQ? Its too ugly to use a polling loop.... ;-)
Sorry. I think I must explain: I'm using linuxbios on this Geode system, so there is no SMM emulation of the sound hardware. Thats why I'm searching for a solution to forward the SMI to a regular IRQ. Has someone experience in programming this SMM code? Maybe a short routine that only triggers a regular interrupt when an SMI occures would help.
Regards, Juergen
Juergen Beisert wrote:
Hi all,
On Monday 07 August 2006 11:19, myself wrote:
I try to write a native sound driver for the Geode GX1/5530a Companion chip. Problem here: The sound chip only generates SMI. Does anyone knows a trick or a chipset switch that let me forward this SMI to a regular IRQ? Its too ugly to use a polling loop.... ;-)
Sorry. I think I must explain: I'm using linuxbios on this Geode system, so there is no SMM emulation of the sound hardware. Thats why I'm searching for a solution to forward the SMI to a regular IRQ. Has someone experience in programming this SMM code? Maybe a short routine that only triggers a regular interrupt when an SMI occures would help.
Is there some reason to continue to use SMI? why not just drive the hardware directly w/o smi?
ron
If I understand the question correctly Juergen want to tell the chipset to issue a IRQ not a SMI. There is no SMM code in LB.
Tim
Ronald G Minnich rminnich@lanl.gov 08/07/06 2:48 PM >>>
Juergen Beisert wrote:
Hi all,
On Monday 07 August 2006 11:19, myself wrote:
I try to write a native sound driver for the Geode GX1/5530a Companion chip. Problem here: The sound chip only generates SMI. Does anyone knows a trick or a chipset switch that let me forward this SMI to a regular IRQ? Its too ugly to use a polling loop.... ;- )
Sorry. I think I must explain: I'm using linuxbios on this Geode system, so there is no SMM emulation of the sound hardware. Thats why I'm searching for a solution to forward the SMI to a regular IRQ. Has someone experience in programming this SMM code? Maybe a short routine that only triggers a regular interrupt when an SMI occures would help.
Is there some reason to continue to use SMI? why not just drive the hardware directly w/o smi?
ron
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
Tim Crawford wrote:
If I understand the question correctly Juergen want to tell the chipset to issue a IRQ not a SMI. There is no SMM code in LB.
Tim
Ronald G Minnich rminnich@lanl.gov 08/07/06 2:48 PM >>>
Juergen Beisert wrote:
Hi all,
On Monday 07 August 2006 11:19, myself wrote:
I try to write a native sound driver for the Geode GX1/5530a Companion chip. Problem here: The sound chip only generates SMI. Does anyone knows a trick or a chipset switch that let me forward this SMI to a regular IRQ? Its too ugly to use a polling loop.... ;- )
Sorry. I think I must explain: I'm using linuxbios on this Geode system, so there is no SMM emulation of the sound hardware. Thats why I'm searching for a solution to forward the SMI to a regular IRQ. Has someone experience in programming this SMM code? Maybe a short routine that only triggers a regular interrupt when an SMI occures would help.
Is there some reason to continue to use SMI? why not just drive the hardware directly w/o smi?
apologies, I am really in 'slow mode' today.
we may need to write a stupid trampoline to get from smi to linux.
ron
Hi Ronald,
On Monday 07 August 2006 22:48, Ronald G Minnich wrote:
On Monday 07 August 2006 11:19, myself wrote:
I try to write a native sound driver for the Geode GX1/5530a Companion chip. Problem here: The sound chip only generates SMI. Does anyone knows a trick or a chipset switch that let me forward this SMI to a regular IRQ? Its too ugly to use a polling loop.... ;-)
Sorry. I think I must explain: I'm using linuxbios on this Geode system, so there is no SMM emulation of the sound hardware. Thats why I'm searching for a solution to forward the SMI to a regular IRQ. Has someone experience in programming this SMM code? Maybe a short routine that only triggers a regular interrupt when an SMI occures would help.
Is there some reason to continue to use SMI? why not just drive the hardware directly w/o smi?
Yes, there is: The audio hardware part of the chip can only generate SMI. I didn't find any chipset settings to let it generate a regular IRQ instead. There is only one register to let the SMM software trigger a regular IRQ.
On Monday 07 August 2006 23:27, Ronald G Minnich wrote:
we may need to write a stupid trampoline to get from smi to linux.
What does it mean? A small SMM rotuine? That would be great. Can I help to write it?
Juergen
Juergen Beisert wrote:
What does it mean? A small SMM rotuine? That would be great. Can I help to write it?
I talked to some amd guys about this. We think it is doable. You need an SMI handler that does nothing more than fix up the stack with a pointer to a kernel assembly thing that does a soft interrupt. Then you do a ret from SMI mode and you end up back in the kernel where you want.
If you study SMI mode a bit, we can do this.
ron
On Tue, 2006-08-08 at 08:47 +0200, Juergen Beisert wrote:
Hi Ronald,
On Monday 07 August 2006 22:48, Ronald G Minnich wrote:
On Monday 07 August 2006 11:19, myself wrote:
I try to write a native sound driver for the Geode GX1/5530a Companion chip. Problem here: The sound chip only generates SMI. Does anyone knows a trick or a chipset switch that let me forward this SMI to a regular IRQ? Its too ugly to use a polling loop.... ;-)
Sorry. I think I must explain: I'm using linuxbios on this Geode system, so there is no SMM emulation of the sound hardware. Thats why I'm searching for a solution to forward the SMI to a regular IRQ. Has someone experience in programming this SMM code? Maybe a short routine that only triggers a regular interrupt when an SMI occures would help.
Is there some reason to continue to use SMI? why not just drive the hardware directly w/o smi?
Yes, there is: The audio hardware part of the chip can only generate SMI. I didn't find any chipset settings to let it generate a regular IRQ instead. There is only one register to let the SMM software trigger a regular IRQ.
Under what circumstances do you want the audio device generate SMI? If you just want to translate SMI to IRQ for DMA completion like other sound devices do, it should not be difficult to write a small SMM code to do that.
Ollie
On Tuesday 08 August 2006 19:03, ollie wrote:
On Tue, 2006-08-08 at 08:47 +0200, Juergen Beisert wrote:
Hi Ronald,
On Monday 07 August 2006 22:48, Ronald G Minnich wrote:
On Monday 07 August 2006 11:19, myself wrote:
I try to write a native sound driver for the Geode GX1/5530a Companion chip. Problem here: The sound chip only generates SMI. Does anyone knows a trick or a chipset switch that let me forward this SMI to a regular IRQ? Its too ugly to use a polling loop.... ;-)
Sorry. I think I must explain: I'm using linuxbios on this Geode system, so there is no SMM emulation of the sound hardware. Thats why I'm searching for a solution to forward the SMI to a regular IRQ. Has someone experience in programming this SMM code? Maybe a short routine that only triggers a regular interrupt when an SMI occures would help.
Is there some reason to continue to use SMI? why not just drive the hardware directly w/o smi?
Yes, there is: The audio hardware part of the chip can only generate SMI. I didn't find any chipset settings to let it generate a regular IRQ instead. There is only one register to let the SMM software trigger a regular IRQ.
Under what circumstances do you want the audio device generate SMI? If you just want to translate SMI to IRQ for DMA completion like other sound devices do, it should not be difficult to write a small SMM code to do that.
ALSA wants to be informed when a buffer is transmitted to the sound device (and the next begins). Thats on reason. CS5530's master DMA generates an SMI whenever it jumps to the next buffer to transmitt. The other reason is, if I do not read back the SMI status registers until a second jump to another block happens the sound hardware stops with a bus error. So my answer to your question is: Yes, only to translate the SMI to a DMA completion IRQ. There are some registers in this audio hardware to trigger a regular interrupt in software from inside an SMI routine. Maybe this could be a starting point.
Regards Juergen
On Tue, 2006-08-08 at 20:05 +0200, Juergen Beisert wrote:
ALSA wants to be informed when a buffer is transmitted to the sound device (and the next begins). Thats on reason. CS5530's master DMA generates an SMI whenever it jumps to the next buffer to transmitt. The other reason is, if I do not read back the SMI status registers until a second jump to another block happens the sound hardware stops with a bus error. So my answer to your question is: Yes, only to translate the SMI to a DMA completion IRQ. There are some registers in this audio hardware to trigger a regular interrupt in software from inside an SMI routine. Maybe this could be a starting point.
Now the problem is you have to write a bunch of code to load and initialize your 2 line SMI->IRQ translator. Is VSA source code for GX2 freely from AMD or not?
BTW, how "native" is your driver? Do you rd/wrmsr all the operations?
Ollie
Hi Ollie,
On Tuesday 08 August 2006 20:30, you wrote:
On Tue, 2006-08-08 at 20:05 +0200, Juergen Beisert wrote:
ALSA wants to be informed when a buffer is transmitted to the sound device (and the next begins). Thats on reason. CS5530's master DMA generates an SMI whenever it jumps to the next buffer to transmitt. The other reason is, if I do not read back the SMI status registers until a second jump to another block happens the sound hardware stops with a bus error. So my answer to your question is: Yes, only to translate the SMI to a DMA completion IRQ. There are some registers in this audio hardware to trigger a regular interrupt in software from inside an SMI routine. Maybe this could be a starting point.
Now the problem is you have to write a bunch of code to load and initialize your 2 line SMI->IRQ translator. Is VSA source code for GX2 freely from AMD or not?
BTW, how "native" is your driver? Do you rd/wrmsr all the operations?
rd/wrmsr? What does it mean?
I am using the native PCI hardware and its registers only. AC97 works, I can configure the AC97 codec. Only sending/capturing audio data is missing...
Juergen
Are you porting the FreeBSD geode gx1 native audio driver to linux? ie: http://alumni.cse.ucsc.edu/%7Ebrucem/gx_audio/
rd/wrmsr? What does it mean?
I am using the native PCI hardware and its registers only. AC97 works, I can configure the AC97 codec. Only sending/capturing audio data is missing...
Juergen
Hi Bryan,
On Tuesday 08 August 2006 21:33, Bryan E. Chafy wrote:
Are you porting the FreeBSD geode gx1 native audio driver to linux? ie: http://alumni.cse.ucsc.edu/%7Ebrucem/gx_audio/
I read this BDS driver also. But then I cloned the cs5535 driver. Most of it can be used with the cs5530. That was much easier than porting the BSD driver.
Regards Jürgen
Hi Bryan,
On Tuesday 08 August 2006 21:33, Bryan E. Chafy wrote:
Are you porting the FreeBSD geode gx1 native audio driver to linux? ie: http://alumni.cse.ucsc.edu/%7Ebrucem/gx_audio/
Here is the current driver. Does not work correctly yet. I have two Geode GX1 systems here: One with regular BIOS (and SMM software) that is currently working and a second one (different manufacturer) with a not complete LinuxBIOS (not working yet). My tests are running on the BIOS based system yet. So maybe some of my problems are founded in interference with the SMM. -> Someone clears my Bus Master Control bit soon or later, but not my driver :-(
There are some open questions the datasheet not answers:
- How does the Audio Bus Master 0 (and 1) handle the data in memory? I think left and right audio sample (16 bit each) in one 32 bit word. Correct? What sample in the upper, what in the lower bits? - Reading back any PRD pointer from hardware register always has bit 0 set. Datasheet says to set the lower two bits to 0. Maybe this bit has a meaning? Status?
I did not understand completly how the PCM framework works yet. So I don't know what happens if the master DMA unit reaches the last PRD in the chain (I did not reach this point yet, someone clears the Bus Master Control bit...). This PRD points back to the first PRD. But this would play the same samples ever and ever...
Any comments and ideas are appreciated.
Regards, Juergen
On Tue, 2006-08-08 at 20:53 +0200, Juergen Beisert wrote:
BTW, how "native" is your driver? Do you rd/wrmsr all the operations?
rd/wrmsr? What does it mean?
I am using the native PCI hardware and its registers only. AC97 works, I can configure the AC97 codec. Only sending/capturing audio data is missing...
I am sorry that I didn't RTFM but is that there is no physical PCI stuff in the GX1 too? Every PCI CS registers are emulated by the VSA software. Is the 5530 a real and physical PCI device?
Ollie
On Wed, Aug 09, 2006 at 09:26:30AM -0600, ollie wrote:
I am sorry that I didn't RTFM but is that there is no physical PCI stuff in the GX1 too? Every PCI CS registers are emulated by the VSA software. Is the 5530 a real and physical PCI device?
Yes. From CS5530A.pdf p.117:
"The CS5530A audio hardware includes six PCI bus masters (three for input and three for output) for transferring digitized audio between memory and the external codec."
//Peter
Hi Ollie,
On Wednesday 09 August 2006 17:26, ollie wrote:
On Tue, 2006-08-08 at 20:53 +0200, Juergen Beisert wrote:
BTW, how "native" is your driver? Do you rd/wrmsr all the operations?
rd/wrmsr? What does it mean?
I am using the native PCI hardware and its registers only. AC97 works, I can configure the AC97 codec. Only sending/capturing audio data is missing...
I am sorry that I didn't RTFM but is that there is no physical PCI stuff in the GX1 too? Every PCI CS registers are emulated by the VSA software. Is the 5530 a real and physical PCI device?
The VSA only emulates a soundblaster. So all accesses to legacy io-space will trap if enabled. I'm working with the PCI registers. There are *physical* registers to communicate with the external AC97 codec and to setup the master DMA engines (PCI function #3 of the kahlua chip is the audio function). FBAR3 points to 128 bytes memory mapped register space that I'm using.
$ lspci -v [...] 00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua] Flags: bus master, medium devsel, latency 0 Memory at 40011000 (32-bit, non-prefetchable) [size=128] [...]
Offset Function ------------------------------------------------------ 00..03 Codec GPOIO Status Register 04..07 Codec GPIO Control Register 08..0B Codec Status Register 0C..0F Codec Command Register 10..11 SMI Status Mirror Register 12..13 SMI Status Register 14..17 SMI Trap Status Register 18..19 SMI Trap-Enable Register 1A..1B IRQ Emulation Enable 1C..1D IRQ Emulation Control 1E..1F IRQ Emulation Mask 20..27 DMA Master 0 engine (Playback) 28..2F DMA Master 1 engine (Capture) 30..3F DMA Master 2 engine (Modem out) 38..3F DMA Master 3 engine (Modem in) 40..47 DMA Master 4 engine (Mono out/Modem handset) 48..4F DMA Master 5 engine (Micro in/Modem handset) 50..7F reserved? (no docu available)
Regards, Juergen
Hi Jonathan,
On Friday 01 September 2006 15:02, you wrote:
I am catching up on some LB threads in my Inbox, and found this one. I don't have anything technical to contribute, but am definitely interested in your progress! To have Kahlua audio without VSA would be fantastic!
Good luck, and keep us updated on your progress.
Thanks, here it comes.
Its state is: "it works for me". I can play sounds and MP3s with it.
It was easier to poll the SMI status bits than to forward an SMI to a regular IRQ. So I divide my driver into two parts: One for SMI polling, and one for kahlua sound. The sound drivers registers itself by the SMI handler, to get called whenever an SMI related to the sound chip occures. That does not work very well under heavy load! But: On a 233MHz Geode with VSA BIOS playing network radio the system has 50% to 60% load (Sound Blaster Emulation with 2.4.x kernel). On my 300Mhz Geode with LinuxBios and my native sound driver playing an MP3 has a load of 3% to 5%.
Some problems are still unresolved: - very short sounds do not stop at the end. The stop command from the ALSA framework is always to late, so a little piece of the last period will be repeated like an echo (due to ring buffering) - I'm not sure if the AC97 codec programming interface works correctly. Sometimes the ALSA framework finds two codecs, sometime only one (but one is correct). And most of the times the alsamixer "forgets" that the master volume also has a "mute" bit. So I have to change the bit manually to hear anything. - capturing is completely untested, it only compiles yet. - high system load increases the SMI polling latency. So some sound periods gets repeated.
Comments are welcome (and recommendations how to solve the increasing SMI polling latency under heavy system load). Attached a quilt stack for a 2.6.17 kernel.
Regards Juergen
PS: I'm on holiday next week, without email access ;-) Back Sun, 10th.
-
Bryan E. Chafy -
Jonathan Sturges -
Juergen Beisert -
ollie -
Peter Stuge -
Ronald G Minnich -
Tim Crawford