OSDev.org

I have a functioning AHCI driver with read and write functions. However, currently I just poll the status in a while loop until the operation is done. I want to enable interrupts for the driver so that i get an interrupt through the PIC. However, there are quite a few "interrupt" bits throughout the structs related to AHCI, and I'm confused on which ones need to be enabled to get the controller to send interrupts.

Could anyone briefly explain the steps to enable interrupts?

LyricalRain wrote:I have a functioning AHCI driver with read and write functions. However, currently I just poll the status in a while loop until the operation is done. I want to enable interrupts for the driver so that i get an interrupt through the PIC. However, there are quite a few "interrupt" bits throughout the structs related to AHCI, and I'm confused on which ones need to be enabled to get the controller to send interrupts.

Could anyone briefly explain the steps to enable interrupts?

Enabling interrupts is quite trivial with AHCI. You first have to set GHC.IE. GHC.IE (interrupt enable) enables all interrupts from the HBA. (You also need to enable interrupts in PCI/PCIe via the command register and, if you want to use it, you need to also configure MSI/MSI-X.) Once interrupts are globally enabled, you can proceed to configure interrupts for each port.
For each port, you have a PxIS and PxIE register. These registers are symmetrical with each other; that is, a bit in PxIE corresponds to the same bit in PxIS and vice-versa. Section 3.3.5 describes the status bits (PxIS) and section 3.3.6 describes the PxIE bits. There are a lot of bits, for sure, so you can choose which ones to enable. (I'm pretty sure you should enable all of them.)

Okay, that makes sense. Thank you!

A little off topic, but after the controller sends an interrupt, how would the process know that data has been transferred? Would the ISR set some flag in the process and the process polls the flag until it is set or something?

That's up to you. You probably don't want to do it that way, though - it's a waste of CPU time.

In the typical synchronous design, making a request blocks the thread, and when the transfer is complete, the thread is unblocked. The thread knows the transfer is complete because the thread can't run while it's waiting for the transfer. (Of course, the thread still has to check whether the transfer was successful - an error will also unblock the thread.)

There are ways to use polling to improve performance, but you wouldn't use IRQs for that, and I'm pretty sure AHCI isn't fast enough for it to be worthwhile anyway.

So how would it be done asynchronously? The process can't do anything until the data has been transferred, right?

LyricalRain wrote:So how would it be done asynchronously?

The process dispatches a transfer request, then later receives a message when the transfer is complete.

LyricalRain wrote:The process can't do anything until the data has been transferred, right?

That depends on the process. If it really can't do anything until the transfer is complete, it sleeps between dispatching the request and receiving a response, just like it would with a synchronous API. The asynchronous API gives it the option of not sleeping if it does have something else to do.

Ahh that makes sense, thanks!