On Tue, Jan 05, 2016 at 02:20:25PM +0000, Mark Brown wrote:
On Tue, Dec 29, 2015 at 03:43:13PM +0000, Charles Keepax wrote:
On Thu, Dec 24, 2015 at 07:31:37PM +0000, Mark Brown wrote:
I am somewhat torn between a comment and renaming the function. I will try to add some sort of reasonable comment.
This doesn't sound like it's really acknowledging an IRQ - you have level triggered interrupts here so if the interrupt isn't acknowledged the interrupt handler will constantly be called.
It kinda is acking the IRQ just at the firmware level, not the hardware level. The physical IRQ all gets acked through regmap so that is all handled. This code here lets the firmware know, which it will then use to decide whether it should send a new IRQ or not.
That's not an interrupt acknowlegement, it's a request for more data.
Well a request to let us know about there being more data. We will keep consuming data as it is generated until we reach a point where we have less than one fragment, then we set this and wait for an IRQ to say we have more than a fragment again.
I could perhaps rename the function to wm_adsp_buffer_request_irq? and buf->irq_ack to buf->irq_count? That might make the usage a little more clear.
That might be a bit clearer, yes - it looks like this is a mailbox on the DSP that you're kicking?
Effectively you could think of it as a mailbox, I haven't looked much at the framework but I suspect it is a little overkill for what we want to do here.
Thanks, Charles