AC '97 and PCI DMA

[XanClic]

Hi,

I'm trying to get a "simple" AC '97 driver working, but I don't know how to do.
I downloaded the specification "AC '97 - revision 2.3", but it tells me about the registers only, I think. So I also received the "Programmer's Reference Manual". Now I know that it is necessary to use PCI DMA but I don't know anything about that. I tried to implement ISA DMA some time ago, but that's all. I read the wiki article [wiki]ATA/ATAPI_using_DMA[/wiki] but it tells me too few things about PCI DMA.

Hence I have some questions.
1st: What is PCI DMA and how can I work with it?
2nd: QEMU and VirtualBox both tell me about two I/O spaces. Do I have to use the first or the second space?

PS: If anyone knows about problems I will have to solve in future, you are of course allowed to tell me about these...

[CmpXchg]

Hey, let me outline a few things:

-) There is an actual PCI device, with PCI configuration space and assigned I/O space, which your driver should make accesses to.

-) AC97 revision 2.3 is just a specification of what this device should be able to do, what the registers are for and some other general rambling (I'm personally fascinated with PC Beep Register 0Ah, which can be used to emit kinda basic samples). The first thing your driver need to do is to unmute the AC97 device by tweaking Volume Registers (02h, 04h, 06h and also 0Ch through 18h).

-) That PCI device which I'm talking about defines a way you access those registers. You've gotta find out what kinda device you've got by probing PCI for Multimedia Audio Devices. In my case, it's built-in chip on my VIA VT8237 Southbridge, with its specific PCI_VENDOR_ID and PCI_DEVICE_ID values. The Datasheet, or a spec should tell you how to interface this device. Is it legal to attach datasheets here, I could upload mine?

-) In that spec, you'll find all the details about DMA and stuff. It's probably gonna be Scatter/Gather DMA (SGD), which is easy and intuitive.

-) That spec should tell you all about I/O spaces. You are probably referring to PCI configuration space (access via ports СF8-CFF) and the I/O space (all the ports). In case your sound chip is built-in into the motherboard, you'll get the whole System I/O Map and description of every built-in piece of hardware. The whole thing.

So, that's it, basically. I'm pleased with the opportunity to explain this stuff. Correct me if you find anything not true or not what XanClic was asking:) Oh, and by the way, Linux sources have been invaluable for me in this area...

[Dex]

CmpXchg as put the basic very well, i would just add that this program written by a friend of mine, should help you to understand how to tranlate the manual to code.
http://www.programmersheaven.com/downlo ... nload.aspx
Its a Dos wav player with built in driver for AC97, it come with full asm code.

[jal]

The first thing your driver need to do is to unmute the AC97 device by tweaking Volume Registers

Are you really sure? It seems to me that unmuting is about the last step to take after configuring everything, or risk the chance of blowing your speakers...


JAL

[CmpXchg]

The first thing your driver need to do is to unmute the AC97 device by tweaking Volume Registers

Are you really sure? It seems to me that unmuting is about the last step to take after configuring everything, or risk the chance of blowing your speakers...

Nah, just perform a Cold Reset through some PCI space register (0x41 in my case), then a Warm Reset through AC97 register 0, then write well-defined values to AC97 Volume Control registers with mute bit 0. It's as simple as that. Yep, unmuting is the last step in this scheme

[XanClic]

I do have access to the PCI device and hence I know about the two I/O spaces (I'm talking about the device's ports, not the PCI configuration space).

Mmh, the DMA stuff was really easier than I thought it would be. My driver works on QEMU and on VirtualPC up to now. One real machine gives me a bluescreen.

The things I'm doing are:

• Activating the I/O space and the bus master (via the command register in the configuration space)
  Performing a reset in NAMBAR (writing 42 to the first register there)
  Doing a reset in NABMBAR (writing 2 to the Global Control/Status register)
  Raising the master, mono, "beep" and PCM volume to 100% (I hope so, I'm just writing 0 to those registers - and it works)
  If the sample rate is variable, I set it to 44,1 kHz (activating variable sample rate and setting front and left/right sample rate to that value)

btw: I have activated the "IOC" field in all buffer descriptors, but I don't receive an interrupt on completion of one buffer. Do you know why? I have enabled the IRQ and I have an ISR.
btw2: @Dex: I still knew that code, but anyway it's very good.

[CmpXchg]

Buffer descriptors? Do they look like this:

Code: Select all

Audio SGD Table Format 
63    62       61-56       55-32 31-0 
 EOL FLAG  -reserved- Base Base 
                   Count Address 
                   [23:0] [31:0] 
EOL  End Of Link.  1 indicates this block is the last of the 
link.  If the channel “Interrupt on EOL” bit is set, 
then an interrupt is generated at the end of the 
transfer. 
FLAG Block Flag.  If set, transfer pauses at the end of this 
block.  If the channel “Interrupt on FLAG” bit is set, 
then an interrupt is generated at the end of this block.

And then there's the SGD control register with the "Interrupt on EOL" and "Interrupt on FLAG" bits.

Are we talking about the same sound cards here?

[XanClic]

Mmh... It looks much the same way. Just the flags are not completely the same.
"IOC" should trigger an interrupt when the buffer has been transferrend.

[CmpXchg]

Then IOC must be EOL in the above table...

Mm, what are your values for PCI Vendor ID and Device ID?
Mine are 1106h for VIA Technologies (Vendor ID) and 3059h for VIA8237 Audio Controller (Device ID).

[XanClic]

The ones I'm using are:
Vendor ID: 0x8086 (Intel)
Device ID: 0x2415 (ICH0, 82801AA); 0x2425 (ICH2, 82801AB); 0x2445 (ICH4, 82801BA)

QEMU and VirtualBox use 0x8086->0x2415 (ICH0) afaik.

[CmpXchg]

Well, then we are talking about different devices, so I can't help you that much

And by the way, you can't 'decide' to use a value like Vendor or Device ID. They are pre-programmed into the devices. Drivers identify their devices by reading these values, afaik.