OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [PATCH V5 2/2] virtio-gpio: Add support for interrupts


On 20-07-21, 10:10, Arnd Bergmann wrote:
> I think it can be done either way:
> 
> a) if you have two buffers, the driver asks for an irq event, and
> the driver replies with a filled-out event saying what happened,
> or that it could not do it.
> 
> b) with just one buffer, we know that something happened,
> but now the driver has to ensure that the event request is
> valid before queuing it. If the driver asks for an event on a
> gpio line that is not an irq source, or configured as output,
> or has a mode that the device cannot support, the event
> would either have to be returned immediately or never.

> I think we can live with getting a spurious interrupt in case the
> driver reconfigures the line later on to no longer be an interrupt
> source.

> Right, this case would be easier for the guest if we separate setting
> the irq polarity from the action of asking for an event, but I suspect
> it would make the device implementation trickier in the process
> (which you may not care about as much).
> 
> An easy way to deal with this scenario would be to mandate
> that any VIRTIO_GPIO_MSG_SET_* command forces the
> irq event message to trigger and have to be requeued.

I will put more thought to the whole stuff and update the spec based
on what I get to finally.

But I really liked the idea of the token system, with a separate
message for each GPIO line. That will solve most of our problems.

-- 
viresh


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]