OSDev.org

When the link is enabled by the assertion of CRST, the codecs will detect the de-assertion of the RESET# signal and request a status change and enumeration by the controller. As the controller hardware detects these requests, it will provide the codecs with their unique addresses and set the controller STATESTS bits to indicate that a Status Change event was detected on the appropriate SDATA_INx signals. Software can use these bits to determine the addresses of the codecs attached to the link. A 1 in a given bit position indicates that a codec at that associated address is present.
For instance, a value of 05h means that there are codecs with addresses 0 and 2 attached to the link.
From RESET# de-assertion until codecs requesting the enumeration can be as late as 25 frames. The software must wait at least 521 us (25 frames) after reading CRST as a 1 before assuming that codecs have all made status change requests and have been registered by the controller. This gives codecs sufficient time to perform self-initialization.
If software wishes to get an interrupt when new codecs are attached, such as during a mobile docking event, the software can set the CIE bit in the INTCTL register to a 1 to enable Controller interrupts which include the Status Change event. When the interrupt is received, the STATESTS bits can be examined to determine if a codec not previously identified has requested a status change.

Ethin wrote:Does this mean that checking the STATESTS register (offset 0Ah), and determining what links are active, is the right path? Then, for each bit that is set, does this mean the offset from 80H?

DavidCooper wrote:

Ethin wrote:Does this mean that checking the STATESTS register (offset 0Ah), and determining what links are active, is the right path? Then, for each bit that is set, does this mean the offset from 80H?

My code never looks at the STATESTS register. It appears to be there partly to support machines with a detachable codec, but I don't expect to encounter any of those. It also refers to the whole codec, and it doesn't tell you the location of anything. When you reset the codec, you do it using CRST in the Global Control Register at 08h and there's no need to check STATESTS.

To help get you and Klakap started, I'll describe what my code originally did to get CORB and RIRB functioning. I always write directly in machine code and that is my source code, but I'll translate from there directly into English:-

(1) I start by putting the address of the memory mapped ports for HDA in register ESI (and you need to get that information from the PCI ports in advance). I later use instructions that take offsets to address different ports while keeping the value in ESI unchanged, as you'll see as we go along.

(2) I then load EAX with the address of the buffer I want to use for CORB.

(3) I post that address to ESI+40h which is the HDA register used by HDA to determine where my CORB buffer is. That's just the lower 32 bits of the address, but I send the upper bits later.

(4) I copy the address of the CORB buffer to register EDI for further use later when I start writing commands to it.

(5) I load EAX with the address of the buffer I want to use for RIRB.

(6) I post that address to ESI+50h which is the HDA register used by HDA to determine where my RIRB buffer is.

(7) I set EAX to 0 then post that to ESI+44h and also to ESI+54h to set the higher bits of both of the 64-bit buffer addresses.

(8) I then write lots of commands into my CORB buffer with the help of EDI which contains its address, starting with a null instruction in case the first instruction isn't run. I'll leave it to you to work out your own commands.

(9) I put the number of commands in AL, then post that value to ESI+48h to tell HDA how many commands it needs to process.

(10) I create a value in AX which has AL=0 and AH=80h, then push it onto the stack. (In other words, I set bit-15 and reset the rest.)

(11) I send that value to ESI+4A to reset the CORB read-pointer.

(12) I set up a delay loop value of 256 in ECX, then loop repeatedly to run it down to zero. I do this solely because I don't like hammering ports while waiting for things to be reset. The spec does not tell you to do this and it is likely completely unnecessary, but I've burned out ports in the past by polling them aggressively and so I don't take chances with them.

(13) I read the port back (ESI+4A) and jump back to repeat step (12) if it isn't ready. To tell if it's ready, I rotate bit-15 into the carry flag.

(14) I set AX to zero and send that to the same port (ESI+4A).

(15) I set up a delay loop as before and run it down to zero.

(16) I read the port back and jump back to step (15) if it isn't ready. Again I rotate bit-15 into the carry flag, but this time the value of the bit must be 0 before we can move on.

(17) I recover (to EAX) the value on the stack which was put there in step (10). I then post that value to ESI+58h to set the RIRB write-pointer to the right place for the replies from the codec.

(18) I read (into AL) RIRB's control register using ESI+5C. I then OR it with 2 (to set the bit that will start the DMA engine, then AND it with 250 (to make sure bits 0 and 2 are zero because I don't want interrupts generated), then write the result back to the same control register to start RIRB's DMA engine.

(19) I read (into AL) CORB's control register using ESI+4C. I then OR it with 2 (to set the bit that will start the DMA engine), then AND it with 254 (to make sure bit-0 is zero, again to avoid interrupts), then write the result back to the same control register to start CORB's DMA engine.

(20) I now wait for the codec's replies to appear in my RIRB buffer and watch for changes to the write-pointer to see when replies arrive. (Note that some responses can come in without responding to a command, such as when a microphone or headphones are plugged in or removed, so if you don't want to use interrupts at all, you'll want your software to check the write pointer perhaps once a second, but you don't have to worry about that at this stage.)

I later wrote more complex code to keep pace with CORB and RIRB write and read locations so that my device driver can send commands and read responses whenever it needs to, but you'll want to design code for all of that yourself. Whenever you need to send more commands, you simply write them at the current read location in the CORB buffer and then use port 48h to tell the DMA engine how many new commands it needs to process. You shouldn't need to use any ports other than the ones I used in those 20 steps for handling CORB and RIRB.

procedure init_hda()
let bar = get_hda_addr_pci();
let corb buffer = 0xDEADBEEF;
write_memory(bar + 0x40, corb buffer);
let rirb buffer = 0x451554a0;
write_memory(bar + 0x50, rirb buffer);
write_memory(bar + 0x44, 0);
write_memory(bar + 0x54, 0);
# we just write some get commands here for now
write_command(corb buffer, 0xF00);
write_command(corb buffer, 0xF07);
write_command(corb buffer, 0xF2D);
write_memory(bar + 0x48, 3);
let corb rp = 1 << 15;
write_memory(bar + 0x4A, corb rp);
loop
for i = 256 to 0 inclusive do
continue;
end for
let tmp corb rp = read_memory(bar + 0x4A);
if tmp corb rp & 15 then
break;
end if
end loop
write_memory(bar + 0x4A, 0);
loop
for i = 256 to 0 inclusive do
continue;
end for
let tmp corb rp = read_memory(bar + 0x4A);
if (tmp corb rp & 15) == 0 then
break;
end if
end loop
write_memory(bar + 0x58, corb rp);
let mut rirbctl = read_memory(bar + 0x5C);
rirbctl |= 2;
rirbctl &= 250;
write_memory(bar + 0x5C, rirbctl);
let mut corbctl = read_memory(bar + 0x4C);
corbctl |= 2;
corbctl &= 254;
write_memory(bar + 0x4C, corbctl);
monitor_rirb();
end procedure