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: [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]