[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [PATCH V6 2/2] virtio-gpio: Add support for interrupts
On Tue, Jul 27, 2021 at 1:26 PM Viresh Kumar <viresh.kumar@linaro.org> wrote: > On 27-07-21, 13:16, Arnd Bergmann wrote: > > This was under the assumption that we decide to still keep some > > controlq request that sets the irq type and just remove the 'mask' > > command. > > Right, so I think I can fold all three of irq messages, mask, unmask > and type, to a single message type. Where the value of type can play > the role of masking/unmasking. This should work fine, I will see if I > get any more doubts on this. > > > If we go all the way to having only one message for interrupts, I > > suppose it does get a little uglier than I was hoping for, but it would still > > be doable: in this case, we could allow a flow like this on the eventq: > > > > - driver requests edge interrupts > > This over eventq and .. > > > - (no event happened, so request remains pending) > > - driver queues a new request asking for IRQ_TYPE_NONE notification > > in order to mask this line > > This over controlq. Right ? Sorry for not being too clear: this was meant as the example where both messages are on the eventq. It would work just as well if the irq type setting is a message on the controlq though, so I suppose it doesn't matter what I was thinking as long as we end up with a working design ;-) > > - device replies to both requests saying no interrupt happened > > Yes, that can work. > > > Between this control flow and the version where set-type is part of > > set-direction, I would prefer the other option, but you already said > > that you don't like that one. > > Yeah, I would like to keep this away from set-direction, which I am > already going to use for activate/deactivate :) Ok, so the set of relevant messages here would be: - controlq: set direction (includes enable, but not set-irq-type) - controlq: set-irq-type (may cancel outstanding eventq request) - eventq: request notification (implies unmask, reply implies mask) This sounds like a reasonably consistent and efficient way to do it, I'm happy enough with that design for the next version. Arnd
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]