Often, the interrupt is the hardware peripheral's way of informing the system – the driver, really – that data is available and that it should pick it up. This is what typical drivers do: they grab the incoming data from the device buffers (or port, or whatever). Not just that, it's also possible that there are user mode processes (or threads) that want this data. Thus, they have quite possibly opened the device file and have issued the read(2) (or equivalent) system call. This has them currently blocking (sleeping) upon this very event; that is, data arriving from the device.
On detecting that data currently isn't available, the driver's read method typically puts the process context to sleep using one of the wait_event*() APIs.
So, once your driver's interrupt handler has fetched the data into some kernel buffer, it typically awakens the sleeping readers. They now run through the driver...
