Mailing List Archive

[PATCH V4 2/2] gpio: virtio: Add IRQ support
This patch adds IRQ support for the virtio GPIO driver. Note that this
uses the irq_bus_lock/unlock() callbacks, since those operations over
virtio may sleep. Also the notifications for the eventq are processed
using a work item to allow sleep-able operations.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/gpio/Kconfig | 1 +
drivers/gpio/gpio-virtio.c | 281 ++++++++++++++++++++++++++++++-
include/uapi/linux/virtio_gpio.h | 25 +++
3 files changed, 303 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index e5993d6864fb..222f4ae98a35 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1672,6 +1672,7 @@ config GPIO_MOCKUP
config GPIO_VIRTIO
tristate "VirtIO GPIO support"
depends on VIRTIO
+ select GPIOLIB_IRQCHIP
help
Say Y here to enable guest support for virtio-based GPIO controllers.

diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
index 3ed4240fe670..0be132d75396 100644
--- a/drivers/gpio/gpio-virtio.c
+++ b/drivers/gpio/gpio-virtio.c
@@ -17,6 +17,7 @@
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/virtio_config.h>
+#include <linux/workqueue.h>
#include <uapi/linux/virtio_gpio.h>
#include <uapi/linux/virtio_ids.h>

@@ -28,6 +29,16 @@ struct virtio_gpio_line {
unsigned int rxlen;
};

+struct vgpio_irq_line {
+ u8 type;
+ bool masked;
+ bool update_pending;
+ bool queued;
+
+ struct virtio_gpio_irq_request ireq;
+ struct virtio_gpio_irq_response ires;
+};
+
struct virtio_gpio {
struct virtio_device *vdev;
struct mutex lock; /* Protects virtqueue operation */
@@ -35,6 +46,12 @@ struct virtio_gpio {
struct virtio_gpio_config config;
struct virtio_gpio_line *lines;
struct virtqueue *request_vq;
+
+ /* fields for irq support */
+ struct virtqueue *event_vq;
+ struct mutex irq_lock; /* Protects irq operation */
+ struct work_struct work;
+ struct vgpio_irq_line *irq_lines;
};

static int _virtio_gpio_req(struct virtio_gpio *vgpio, u16 type, u16 gpio,
@@ -187,6 +204,220 @@ static void virtio_gpio_set(struct gpio_chip *gc, unsigned int gpio, int value)
virtio_gpio_req(vgpio, VIRTIO_GPIO_MSG_SET_VALUE, gpio, value, NULL);
}

+/* Interrupt handling */
+static void virtio_gpio_irq_prepare(struct virtio_gpio *vgpio, u16 gpio)
+{
+ struct vgpio_irq_line *irq_line = &vgpio->irq_lines[gpio];
+ struct virtio_gpio_irq_request *ireq = &irq_line->ireq;
+ struct virtio_gpio_irq_response *ires = &irq_line->ires;
+ struct scatterlist *sgs[2], req_sg, res_sg;
+ int ret;
+
+ ireq->gpio = cpu_to_le16(gpio);
+ sg_init_one(&req_sg, ireq, sizeof(*ireq));
+ sg_init_one(&res_sg, ires, sizeof(*ires));
+ sgs[0] = &req_sg;
+ sgs[1] = &res_sg;
+
+ ret = virtqueue_add_sgs(vgpio->event_vq, sgs, 1, 1, irq_line, GFP_KERNEL);
+ if (ret) {
+ dev_err(&vgpio->vdev->dev, "failed to add request to eventq\n");
+ return;
+ }
+
+ WARN_ON(irq_line->queued);
+
+ irq_line->queued = true;
+ virtqueue_kick(vgpio->event_vq);
+}
+
+static void virtio_gpio_irq_eoi(struct irq_data *d)
+{
+ /*
+ * Queue buffers, by calling virtio_gpio_irq_prepare(), from
+ * virtio_gpio_event_vq() itself, after taking into consideration the
+ * masking status of the interrupt.
+ */
+}
+
+static void virtio_gpio_irq_mask(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct virtio_gpio *vgpio = gpiochip_get_data(gc);
+ struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
+
+ irq_line->masked = true;
+ irq_line->update_pending = true;
+}
+
+static void virtio_gpio_irq_unmask(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct virtio_gpio *vgpio = gpiochip_get_data(gc);
+ struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
+
+ irq_line->masked = false;
+ irq_line->update_pending = true;
+}
+
+static int virtio_gpio_irq_set_type(struct irq_data *d, unsigned int type)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct virtio_gpio *vgpio = gpiochip_get_data(gc);
+ struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
+
+ switch (type) {
+ case IRQ_TYPE_NONE:
+ type = VIRTIO_GPIO_IRQ_TYPE_NONE;
+ break;
+ case IRQ_TYPE_EDGE_RISING:
+ type = VIRTIO_GPIO_IRQ_TYPE_EDGE_RISING;
+ break;
+ case IRQ_TYPE_EDGE_FALLING:
+ type = VIRTIO_GPIO_IRQ_TYPE_EDGE_FALLING;
+ break;
+ case IRQ_TYPE_EDGE_BOTH:
+ type = VIRTIO_GPIO_IRQ_TYPE_EDGE_BOTH;
+ break;
+ case IRQ_TYPE_LEVEL_LOW:
+ type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_LOW;
+ break;
+ case IRQ_TYPE_LEVEL_HIGH:
+ type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_HIGH;
+ break;
+ default:
+ dev_err(&vgpio->vdev->dev, "unsupported irq type: %u\n", type);
+ return -EINVAL;
+ }
+
+ irq_line->type = type;
+ irq_line->update_pending = true;
+
+ return 0;
+}
+
+static void update_irq_type(struct virtio_gpio *vgpio, u16 gpio, u8 type)
+{
+ virtio_gpio_req(vgpio, VIRTIO_GPIO_MSG_IRQ_TYPE, gpio, type, NULL);
+}
+
+static void virtio_gpio_irq_bus_lock(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct virtio_gpio *vgpio = gpiochip_get_data(gc);
+
+ mutex_lock(&vgpio->irq_lock);
+}
+
+static void virtio_gpio_irq_bus_sync_unlock(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct virtio_gpio *vgpio = gpiochip_get_data(gc);
+ int gpio = d->hwirq;
+ struct vgpio_irq_line *irq_line = &vgpio->irq_lines[gpio];
+
+ if (unlikely(!irq_line->update_pending))
+ goto out;
+
+ if (irq_line->masked) {
+ update_irq_type(vgpio, gpio, VIRTIO_GPIO_IRQ_TYPE_NONE);
+ } else {
+ update_irq_type(vgpio, gpio, irq_line->type);
+ virtio_gpio_irq_prepare(vgpio, gpio);
+ }
+
+ irq_line->update_pending = false;
+
+out:
+ mutex_unlock(&vgpio->irq_lock);
+}
+
+static struct irq_chip vgpio_irq_chip = {
+ .name = "virtio-gpio",
+ .irq_eoi = virtio_gpio_irq_eoi,
+ .irq_mask = virtio_gpio_irq_mask,
+ .irq_unmask = virtio_gpio_irq_unmask,
+ .irq_set_type = virtio_gpio_irq_set_type,
+
+ /* These are required to implement irqchip for slow busses */
+ .irq_bus_lock = virtio_gpio_irq_bus_lock,
+ .irq_bus_sync_unlock = virtio_gpio_irq_bus_sync_unlock,
+};
+
+static void vgpio_work_handler(struct work_struct *work)
+{
+ struct virtio_gpio *vgpio = container_of(work, struct virtio_gpio,
+ work);
+ struct device *dev = &vgpio->vdev->dev;
+ struct vgpio_irq_line *irq_line;
+ int irq, gpio, ret;
+ unsigned int len;
+
+ mutex_lock(&vgpio->irq_lock);
+
+ while (true) {
+ irq_line = virtqueue_get_buf(vgpio->event_vq, &len);
+ if (!irq_line)
+ break;
+
+ if (len != sizeof(irq_line->ires)) {
+ dev_err(dev, "irq with incorrect length (%u : %lu)\n",
+ len, sizeof(irq_line->ires));
+ continue;
+ }
+
+ WARN_ON(!irq_line->queued);
+ irq_line->queued = false;
+
+ /* Buffer is returned after interrupt is masked */
+ if (irq_line->ires.status == VIRTIO_GPIO_IRQ_STATUS_INVALID)
+ continue;
+
+ if (WARN_ON(irq_line->ires.status != VIRTIO_GPIO_IRQ_STATUS_VALID))
+ continue;
+
+ /*
+ * Find GPIO line number from the offset of irq_line within the
+ * irq_lines block. We can also get GPIO number from
+ * irq-request, but better not rely on a value returned by
+ * remote.
+ */
+ gpio = irq_line - vgpio->irq_lines;
+ WARN_ON(gpio >= vgpio->config.ngpio);
+
+ irq = irq_find_mapping(vgpio->gc.irq.domain, gpio);
+ WARN_ON(!irq);
+
+ local_irq_disable();
+ ret = generic_handle_irq(irq);
+ local_irq_enable();
+
+ if (ret)
+ dev_err(dev, "failed to handle interrupt: %d\n", ret);
+
+ /* The interrupt may have been disabled by now */
+ if (irq_line->update_pending && irq_line->masked)
+ update_irq_type(vgpio, gpio, VIRTIO_GPIO_IRQ_TYPE_NONE);
+ else
+ virtio_gpio_irq_prepare(vgpio, gpio);
+
+ irq_line->update_pending = false;
+ };
+
+ mutex_unlock(&vgpio->irq_lock);
+}
+
+static void virtio_gpio_event_vq(struct virtqueue *vq)
+{
+ struct virtio_gpio *vgpio = vq->vdev->priv;
+
+ /*
+ * We can't initiate virtio-gpio operations from hard irq context, as
+ * they need sleep-able context.
+ */
+ schedule_work(&vgpio->work);
+}
+
static void virtio_gpio_request_vq(struct virtqueue *vq)
{
struct virtio_gpio_line *line;
@@ -211,14 +442,15 @@ static void virtio_gpio_free_vqs(struct virtio_device *vdev)
static int virtio_gpio_alloc_vqs(struct virtio_gpio *vgpio,
struct virtio_device *vdev)
{
- const char * const names[] = { "requestq" };
+ const char * const names[] = { "requestq", "eventq" };
vq_callback_t *cbs[] = {
virtio_gpio_request_vq,
+ virtio_gpio_event_vq,
};
- struct virtqueue *vqs[1] = { NULL };
+ struct virtqueue *vqs[2] = { NULL, NULL };
int ret;

- ret = virtio_find_vqs(vdev, 1, vqs, cbs, names, NULL);
+ ret = virtio_find_vqs(vdev, vgpio->irq_lines ? 2 : 1, vqs, cbs, names, NULL);
if (ret) {
dev_err(&vdev->dev, "failed to find vqs: %d\n", ret);
return ret;
@@ -226,11 +458,23 @@ static int virtio_gpio_alloc_vqs(struct virtio_gpio *vgpio,

if (!vqs[0]) {
dev_err(&vdev->dev, "failed to find requestq vq\n");
- return -ENODEV;
+ goto out;
}
vgpio->request_vq = vqs[0];

+ if (vgpio->irq_lines && !vqs[1]) {
+ dev_err(&vdev->dev, "failed to find eventq vq\n");
+ goto out;
+ }
+ vgpio->event_vq = vqs[1];
+
return 0;
+
+out:
+ if (vqs[0] || vqs[1])
+ virtio_gpio_free_vqs(vdev);
+
+ return -ENODEV;
}

static const char **virtio_gpio_get_names(struct virtio_gpio *vgpio)
@@ -326,6 +570,29 @@ static int virtio_gpio_probe(struct virtio_device *vdev)
vgpio->gc.owner = THIS_MODULE;
vgpio->gc.can_sleep = true;

+ /* Interrupt support */
+ if (virtio_has_feature(vdev, VIRTIO_GPIO_F_IRQ)) {
+ vgpio->irq_lines = devm_kcalloc(dev, config->ngpio,
+ sizeof(*vgpio->irq_lines),
+ GFP_KERNEL);
+ if (!vgpio->irq_lines)
+ return -ENOMEM;
+
+ /* The event comes from the outside so no parent handler */
+ vgpio->gc.irq.parent_handler = NULL;
+ vgpio->gc.irq.num_parents = 0;
+ vgpio->gc.irq.parents = NULL;
+ vgpio->gc.irq.default_type = IRQ_TYPE_NONE;
+ vgpio->gc.irq.handler = handle_fasteoi_irq;
+ vgpio->gc.irq.chip = &vgpio_irq_chip;
+
+ for (i = 0; i < config->ngpio; i++)
+ vgpio->irq_lines[i].type = VIRTIO_GPIO_IRQ_TYPE_NONE;
+
+ mutex_init(&vgpio->irq_lock);
+ INIT_WORK(&vgpio->work, vgpio_work_handler);
+ }
+
ret = virtio_gpio_alloc_vqs(vgpio, vdev);
if (ret)
return ret;
@@ -358,7 +625,13 @@ static const struct virtio_device_id id_table[] = {
};
MODULE_DEVICE_TABLE(virtio, id_table);

+static const unsigned int features[] = {
+ VIRTIO_GPIO_F_IRQ,
+};
+
static struct virtio_driver virtio_gpio_driver = {
+ .feature_table = features,
+ .feature_table_size = ARRAY_SIZE(features),
.id_table = id_table,
.probe = virtio_gpio_probe,
.remove = virtio_gpio_remove,
diff --git a/include/uapi/linux/virtio_gpio.h b/include/uapi/linux/virtio_gpio.h
index 844574acf095..297ffdae1a5d 100644
--- a/include/uapi/linux/virtio_gpio.h
+++ b/include/uapi/linux/virtio_gpio.h
@@ -5,12 +5,16 @@

#include <linux/types.h>

+/* Virtio GPIO Feature bits */
+#define VIRTIO_GPIO_F_IRQ 0
+
/* Virtio GPIO request types */
#define VIRTIO_GPIO_MSG_GET_NAMES 0x0001
#define VIRTIO_GPIO_MSG_GET_DIRECTION 0x0002
#define VIRTIO_GPIO_MSG_SET_DIRECTION 0x0003
#define VIRTIO_GPIO_MSG_GET_VALUE 0x0004
#define VIRTIO_GPIO_MSG_SET_VALUE 0x0005
+#define VIRTIO_GPIO_MSG_IRQ_TYPE 0x0006

/* Possible values of the status field */
#define VIRTIO_GPIO_STATUS_OK 0x0
@@ -21,6 +25,14 @@
#define VIRTIO_GPIO_DIRECTION_OUT 0x01
#define VIRTIO_GPIO_DIRECTION_IN 0x02

+/* Virtio GPIO IRQ types */
+#define VIRTIO_GPIO_IRQ_TYPE_NONE 0x00
+#define VIRTIO_GPIO_IRQ_TYPE_EDGE_RISING 0x01
+#define VIRTIO_GPIO_IRQ_TYPE_EDGE_FALLING 0x02
+#define VIRTIO_GPIO_IRQ_TYPE_EDGE_BOTH 0x03
+#define VIRTIO_GPIO_IRQ_TYPE_LEVEL_HIGH 0x04
+#define VIRTIO_GPIO_IRQ_TYPE_LEVEL_LOW 0x08
+
struct virtio_gpio_config {
__u16 ngpio;
__u8 padding[2];
@@ -44,4 +56,17 @@ struct virtio_gpio_response_get_names {
__u8 value[];
};

+/* Virtio GPIO IRQ Request / Response */
+struct virtio_gpio_irq_request {
+ __u16 gpio;
+};
+
+struct virtio_gpio_irq_response {
+ __u8 status;
+};
+
+/* Possible values of the interrupt status field */
+#define VIRTIO_GPIO_IRQ_STATUS_INVALID 0x0
+#define VIRTIO_GPIO_IRQ_STATUS_VALID 0x1
+
#endif /* _LINUX_VIRTIO_GPIO_H */
--
2.31.1.272.g89b43f80a514
Re: [PATCH V4 2/2] gpio: virtio: Add IRQ support [ In reply to ]
On Tue, Aug 3, 2021 at 1:36 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> This patch adds IRQ support for the virtio GPIO driver. Note that this
> uses the irq_bus_lock/unlock() callbacks, since those operations over
> virtio may sleep. Also the notifications for the eventq are processed
> using a work item to allow sleep-able operations.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/gpio/Kconfig | 1 +
> drivers/gpio/gpio-virtio.c | 281 ++++++++++++++++++++++++++++++-
> include/uapi/linux/virtio_gpio.h | 25 +++
> 3 files changed, 303 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index e5993d6864fb..222f4ae98a35 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -1672,6 +1672,7 @@ config GPIO_MOCKUP
> config GPIO_VIRTIO
> tristate "VirtIO GPIO support"
> depends on VIRTIO
> + select GPIOLIB_IRQCHIP
> help
> Say Y here to enable guest support for virtio-based GPIO controllers.
>

> +struct vgpio_irq_line {
> + u8 type;
> + bool masked;
> + bool update_pending;
> + bool queued;
> +
> + struct virtio_gpio_irq_request ireq;
> + struct virtio_gpio_irq_response ires;
> +};

I think the last two members should be marked as __cacheline_aligned,
since they are transferred separately over DMA.

> +static void virtio_gpio_irq_eoi(struct irq_data *d)
> +{
> + /*
> + * Queue buffers, by calling virtio_gpio_irq_prepare(), from
> + * virtio_gpio_event_vq() itself, after taking into consideration the
> + * masking status of the interrupt.
> + */
> +}

Shouldn't this just requeue the interrupt? There is no reason to
defer this, and I think we want the normal operation to not have
to involve any scheduling.

> +static void virtio_gpio_irq_unmask(struct irq_data *d)
> +{
> + struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> + struct virtio_gpio *vgpio = gpiochip_get_data(gc);
> + struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
> +
> + irq_line->masked = false;
> + irq_line->update_pending = true;
> +}

Same here. unmask is probably less important, but it's the
same operation: if you want interrupts to become active
again when they are not, just queue the request

> +static void virtio_gpio_irq_mask(struct irq_data *d)
> +{
> + struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> + struct virtio_gpio *vgpio = gpiochip_get_data(gc);
> + struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
> +
> + irq_line->masked = true;
> + irq_line->update_pending = true;
> +}

This is of course the tricky bit, I was hoping you had found a solution
based on what I wrote above for eio() and unmask().

> +static void vgpio_work_handler(struct work_struct *work)
> +{
> + struct virtio_gpio *vgpio = container_of(work, struct virtio_gpio,
> + work);
> + struct device *dev = &vgpio->vdev->dev;
> + struct vgpio_irq_line *irq_line;
> + int irq, gpio, ret;
> + unsigned int len;
> +
> + mutex_lock(&vgpio->irq_lock);
> +
> + while (true) {
> + irq_line = virtqueue_get_buf(vgpio->event_vq, &len);
> + if (!irq_line)
> + break;

Related to above, I think all the eventq handling should be moved into the
virtio_gpio_event_vq() function directly.

> + /* The interrupt may have been disabled by now */
> + if (irq_line->update_pending && irq_line->masked)
> + update_irq_type(vgpio, gpio, VIRTIO_GPIO_IRQ_TYPE_NONE);

This is a part I'm not sure about, and I suppose it's the same part that
Marc was also confused by.

As far as I can tell, the update_irq_type() message would lead to the
interrupt getting delivered when it was armed and is now getting disabled,
but I don't see why we would call update_irq_type() as a result of the
eventq notification.

Arnd
Re: [PATCH V4 2/2] gpio: virtio: Add IRQ support [ In reply to ]
On 03-08-21, 17:01, Arnd Bergmann wrote:
> On Tue, Aug 3, 2021 at 1:36 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > +struct vgpio_irq_line {
> > + u8 type;
> > + bool masked;
> > + bool update_pending;
> > + bool queued;
> > +
> > + struct virtio_gpio_irq_request ireq;
> > + struct virtio_gpio_irq_response ires;
> > +};
>
> I think the last two members should be marked as __cacheline_aligned,
> since they are transferred separately over DMA.

Right.

> > +static void virtio_gpio_irq_eoi(struct irq_data *d)
> > +{
> > + /*
> > + * Queue buffers, by calling virtio_gpio_irq_prepare(), from
> > + * virtio_gpio_event_vq() itself, after taking into consideration the
> > + * masking status of the interrupt.
> > + */
> > +}
>
> Shouldn't this just requeue the interrupt? There is no reason to
> defer this, and I think we want the normal operation to not have
> to involve any scheduling.
>
> > +static void virtio_gpio_irq_unmask(struct irq_data *d)
> > +{
> > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> > + struct virtio_gpio *vgpio = gpiochip_get_data(gc);
> > + struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
> > +
> > + irq_line->masked = false;
> > + irq_line->update_pending = true;
> > +}
>
> Same here. unmask is probably less important, but it's the
> same operation: if you want interrupts to become active
> again when they are not, just queue the request

We can't because its a slow bus ? And unmask can be called from
irq-context. That's exactly why we had the irq_bus_lock/unlock
discussion earlier.

> > +static void virtio_gpio_irq_mask(struct irq_data *d)
> > +{
> > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> > + struct virtio_gpio *vgpio = gpiochip_get_data(gc);
> > + struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
> > +
> > + irq_line->masked = true;
> > + irq_line->update_pending = true;
> > +}
>
> This is of course the tricky bit, I was hoping you had found a solution
> based on what I wrote above for eio() and unmask().
>
> > +static void vgpio_work_handler(struct work_struct *work)
> > +{
> > + struct virtio_gpio *vgpio = container_of(work, struct virtio_gpio,
> > + work);
> > + struct device *dev = &vgpio->vdev->dev;
> > + struct vgpio_irq_line *irq_line;
> > + int irq, gpio, ret;
> > + unsigned int len;
> > +
> > + mutex_lock(&vgpio->irq_lock);
> > +
> > + while (true) {
> > + irq_line = virtqueue_get_buf(vgpio->event_vq, &len);
> > + if (!irq_line)
> > + break;
>
> Related to above, I think all the eventq handling should be moved into the
> virtio_gpio_event_vq() function directly.

You mean without scheduling a work ?

> > + /* The interrupt may have been disabled by now */
> > + if (irq_line->update_pending && irq_line->masked)
> > + update_irq_type(vgpio, gpio, VIRTIO_GPIO_IRQ_TYPE_NONE);
>
> This is a part I'm not sure about, and I suppose it's the same part that
> Marc was also confused by.
>
> As far as I can tell, the update_irq_type() message would lead to the
> interrupt getting delivered when it was armed and is now getting disabled,
> but I don't see why we would call update_irq_type() as a result of the
> eventq notification.

Lemme try to explain answer to all other question together here.

The irq related functions get called in two scenarios:

- request_irq() or irq_set_irq_type(), enable/disable_irq(), etc:

The call sequence here is like this:

->irq_bus_lock()

->spin-lock-irqsave
->irq_mask()/irq_unmask()/irq_set_type()..
->spin-unlock-irqsave

->irq_bus_unlock()


So the mask/unmask/set-type routines can't issue virtio requests and
we need to do that from irq_bus_unlock(). This shall answer your
question about mask/unmask, right ? Or maybe I misunderstood them
then ?


- Interrupt: i.e. buffer sent back by the host over virtio.

virtio_gpio_event_vq() schedules a work item, which processes the
items from the eventq virtqueue and eventually calls
generic_handle_irq(). The irq-core can issue calls to
->irq_mask/unmask() here without a prior call to
irq_bus_lock/unlock(), normally they will balance out by the end,
but I am not sure if it is guaranteed. Moreover, interrupt should be
re-enabled only after unmask() is called (for ONESHOT) and not at
EOI, right ?

I chose not to queue the buffers back from eoi() as it is possible
that we won't want to queue them at all, as the interrupt needs to
be disabled by the time generic_handle_irq() returns. And so I did
everything from the end of vgpio_work_handler()'s loop, i.e. either
disable the interrupts with VIRTIO_GPIO_IRQ_TYPE_NONE or enable the
interrupt again by re-queuing the buffer.

Regarding irq handling using work-item, I had to move to that to take
care of locking for re-queuing the buffers for a GPIO line from
irq-handler and bus-unlock. Nothing else seemed to work, though I am
continuing to look into that to see if there is an alternative here.

--
viresh
Re: [PATCH V4 2/2] gpio: virtio: Add IRQ support [ In reply to ]
On Wed, Aug 4, 2021 at 9:05 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 03-08-21, 17:01, Arnd Bergmann wrote:
> > >
> > > +static void virtio_gpio_irq_unmask(struct irq_data *d)
> > > +{
> > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> > > + struct virtio_gpio *vgpio = gpiochip_get_data(gc);
> > > + struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
> > > +
> > > + irq_line->masked = false;
> > > + irq_line->update_pending = true;
> > > +}
> >
> > Same here. unmask is probably less important, but it's the
> > same operation: if you want interrupts to become active
> > again when they are not, just queue the request
>
> We can't because its a slow bus ? And unmask can be called from
> irq-context. That's exactly why we had the irq_bus_lock/unlock
> discussion earlier.

I thought only 'mask' is slow, since that has to wait for the completion,
but 'unmask' just involves sending the eventq request without having
to wait for it.

> > > +static void vgpio_work_handler(struct work_struct *work)
> > > +{
> > > + struct virtio_gpio *vgpio = container_of(work, struct virtio_gpio,
> > > + work);
> > > + struct device *dev = &vgpio->vdev->dev;
> > > + struct vgpio_irq_line *irq_line;
> > > + int irq, gpio, ret;
> > > + unsigned int len;
> > > +
> > > + mutex_lock(&vgpio->irq_lock);
> > > +
> > > + while (true) {
> > > + irq_line = virtqueue_get_buf(vgpio->event_vq, &len);
> > > + if (!irq_line)
> > > + break;
> >
> > Related to above, I think all the eventq handling should be moved into the
> > virtio_gpio_event_vq() function directly.
>
> You mean without scheduling a work ?

Yes.

> > > + /* The interrupt may have been disabled by now */
> > > + if (irq_line->update_pending && irq_line->masked)
> > > + update_irq_type(vgpio, gpio, VIRTIO_GPIO_IRQ_TYPE_NONE);
> >
> > This is a part I'm not sure about, and I suppose it's the same part that
> > Marc was also confused by.
> >
> > As far as I can tell, the update_irq_type() message would lead to the
> > interrupt getting delivered when it was armed and is now getting disabled,
> > but I don't see why we would call update_irq_type() as a result of the
> > eventq notification.
>
> Lemme try to explain answer to all other question together here.
>
> The irq related functions get called in two scenarios:
>
> - request_irq() or irq_set_irq_type(), enable/disable_irq(), etc:
>
> The call sequence here is like this:
>
> ->irq_bus_lock()
>
> ->spin-lock-irqsave
> ->irq_mask()/irq_unmask()/irq_set_type()..
> ->spin-unlock-irqsave
>
> ->irq_bus_unlock()
>
>
> So the mask/unmask/set-type routines can't issue virtio requests and
> we need to do that from irq_bus_unlock(). This shall answer your
> question about mask/unmask, right ? Or maybe I misunderstood them
> then ?

I don't think it is correct that you cannot issue virtio requests from
atomic context, only that you cannot wait for the reply.

For 'unmask', there is no waiting, since the reply is the actual IRQ
event. For the others, the sequence makes sense.

> - Interrupt: i.e. buffer sent back by the host over virtio.
>
> virtio_gpio_event_vq() schedules a work item, which processes the
> items from the eventq virtqueue and eventually calls
> generic_handle_irq(). The irq-core can issue calls to
> ->irq_mask/unmask() here without a prior call to
> irq_bus_lock/unlock(), normally they will balance out by the end,
> but I am not sure if it is guaranteed. Moreover, interrupt should be
> re-enabled only after unmask() is called (for ONESHOT) and not at
> EOI, right ?
>
> I chose not to queue the buffers back from eoi() as it is possible
> that we won't want to queue them at all, as the interrupt needs to
> be disabled by the time generic_handle_irq() returns. And so I did
> everything from the end of vgpio_work_handler()'s loop, i.e. either
> disable the interrupts with VIRTIO_GPIO_IRQ_TYPE_NONE or enable the
> interrupt again by re-queuing the buffer.
>
> Regarding irq handling using work-item, I had to move to that to take
> care of locking for re-queuing the buffers for a GPIO line from
> irq-handler and bus-unlock. Nothing else seemed to work, though I am
> continuing to look into that to see if there is an alternative here.

I don't think it makes sense to optimize for the rare case that the
irq handler disables the irq, when that makes the common case
(irq remains unmasked and enabled) much slower.

Arnd
Re: [PATCH V4 2/2] gpio: virtio: Add IRQ support [ In reply to ]
On 04-08-21, 10:27, Arnd Bergmann wrote:
> On Wed, Aug 4, 2021 at 9:05 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 03-08-21, 17:01, Arnd Bergmann wrote:
> > > >
> > > > +static void virtio_gpio_irq_unmask(struct irq_data *d)
> > > > +{
> > > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> > > > + struct virtio_gpio *vgpio = gpiochip_get_data(gc);
> > > > + struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
> > > > +
> > > > + irq_line->masked = false;
> > > > + irq_line->update_pending = true;
> > > > +}
> > >
> > > Same here. unmask is probably less important, but it's the
> > > same operation: if you want interrupts to become active
> > > again when they are not, just queue the request
> >
> > We can't because its a slow bus ? And unmask can be called from
> > irq-context. That's exactly why we had the irq_bus_lock/unlock
> > discussion earlier.
>
> I thought only 'mask' is slow, since that has to wait for the completion,
> but 'unmask' just involves sending the eventq request without having
> to wait for it.

Ahh, so you are suggesting of just sending the request without waiting
for the response. We can do it, but I am not sure if it is going to be
worth it considering the additional complexity in the driver.

Maybe lets come back to this later, if this is going to make anything
better, once the basic support for irqs look good here.

> I don't think it is correct that you cannot issue virtio requests from
> atomic context, only that you cannot wait for the reply.

Yes, you are right. I was having a mess because of all the races and
different ways things were getting called.

> For 'unmask', there is no waiting, since the reply is the actual IRQ
> event. For the others, the sequence makes sense.

> > - Interrupt: i.e. buffer sent back by the host over virtio.
> >
> > virtio_gpio_event_vq() schedules a work item, which processes the
> > items from the eventq virtqueue and eventually calls
> > generic_handle_irq(). The irq-core can issue calls to
> > ->irq_mask/unmask() here without a prior call to
> > irq_bus_lock/unlock(), normally they will balance out by the end,
> > but I am not sure if it is guaranteed. Moreover, interrupt should be
> > re-enabled only after unmask() is called (for ONESHOT) and not at
> > EOI, right ?
> >
> > I chose not to queue the buffers back from eoi() as it is possible
> > that we won't want to queue them at all, as the interrupt needs to
> > be disabled by the time generic_handle_irq() returns. And so I did
> > everything from the end of vgpio_work_handler()'s loop, i.e. either
> > disable the interrupts with VIRTIO_GPIO_IRQ_TYPE_NONE or enable the
> > interrupt again by re-queuing the buffer.
> >
> > Regarding irq handling using work-item, I had to move to that to take
> > care of locking for re-queuing the buffers for a GPIO line from
> > irq-handler and bus-unlock. Nothing else seemed to work, though I am
> > continuing to look into that to see if there is an alternative here.
>
> I don't think it makes sense to optimize for the rare case that the
> irq handler disables the irq, when that makes the common case
> (irq remains unmasked and enabled) much slower.

I am not worried about that case only, i.e. where the
interrupt-handler disables the interrupt. It should work fine though,
even if it isn't optimized.

A) If the client has registered with irq with IRQF_ONESHOT, irq core
will call ->irq_mask(), irq-handler(), ->irq_eoi(), and finally
->irq_unmask(). Looking at this basic sequence itself, irq_eoi()
shouldn't enable the interrupt again by re-queuing the buffer,
rather it should happen from unmask in this case.

B) If the client has registered a threaded-irq, it gets even more
complex. The core does this in that case:

call ->irq_mask(), ->irq_eoi(), and return control back to
virtio_gpio_event_vq().

The thread gets scheduled then and calls the irq-handler and then
the irq-core calls irq-bus-lock(), ->irq_unmask(),
irq-bus-unlock().

Looking at these, eoi shouldn't be queuing the buffer. Also, I wonder
if we should use handle_fasteoi_irq() here or something else.

--
viresh
Re: [PATCH V4 2/2] gpio: virtio: Add IRQ support [ In reply to ]
On 03-08-21, 17:01, Arnd Bergmann wrote:
> As far as I can tell, the update_irq_type() message would lead to the
> interrupt getting delivered when it was armed and is now getting disabled,
> but I don't see why we would call update_irq_type() as a result of the
> eventq notification.

Based on discussion we had today (offline), I changed the design a bit
and used handle_level_irq() instead, as it provides consistent calls
to mask/unmask(), which simplified the whole thing a bit.

Also I have broken the rule from specs, maybe we should update spec
with that, where the specs said that the buffer must not be queued
before enabling the interrupt. I just queue the buffer unconditionally
now from unmask().

I am not sure but there may be some race around the "queued" flag and
I wonder if we can land in a scenario where the buffer is left
un-queued somehow, while an interrupt is enabled.

diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
index 199f8ace1e88..114ce2640944 100644
--- a/drivers/gpio/gpio-virtio.c
+++ b/drivers/gpio/gpio-virtio.c
@@ -28,6 +28,17 @@ struct virtio_gpio_line {
unsigned int rxlen;
};

+struct vgpio_irq_line {
+ u8 type;
+ bool type_pending;
+ bool masked;
+ bool mask_pending;
+ bool queued;
+
+ struct virtio_gpio_irq_request ireq ____cacheline_aligned;
+ struct virtio_gpio_irq_response ires ____cacheline_aligned;
+};
+
struct virtio_gpio {
struct virtio_device *vdev;
struct mutex lock; /* Protects virtqueue operation */
@@ -35,6 +46,11 @@ struct virtio_gpio {
struct virtio_gpio_config config;
struct virtio_gpio_line *lines;
struct virtqueue *request_vq;
+
+ /* irq support */
+ struct virtqueue *event_vq;
+ struct mutex irq_lock; /* Protects irq operation */
+ struct vgpio_irq_line *irq_lines;
};

static int _virtio_gpio_req(struct virtio_gpio *vgpio, u16 type, u16 gpio,
@@ -187,6 +203,186 @@ static void virtio_gpio_set(struct gpio_chip *gc, unsigned int gpio, int value)
virtio_gpio_req(vgpio, VIRTIO_GPIO_MSG_SET_VALUE, gpio, value, NULL);
}

+/* Interrupt handling */
+static void virtio_gpio_irq_prepare(struct virtio_gpio *vgpio, u16 gpio)
+{
+ struct vgpio_irq_line *irq_line = &vgpio->irq_lines[gpio];
+ struct virtio_gpio_irq_request *ireq = &irq_line->ireq;
+ struct virtio_gpio_irq_response *ires = &irq_line->ires;
+ struct scatterlist *sgs[2], req_sg, res_sg;
+ int ret;
+
+ if (unlikely(irq_line->queued))
+ return;
+
+ ireq->gpio = cpu_to_le16(gpio);
+ sg_init_one(&req_sg, ireq, sizeof(*ireq));
+ sg_init_one(&res_sg, ires, sizeof(*ires));
+ sgs[0] = &req_sg;
+ sgs[1] = &res_sg;
+
+ ret = virtqueue_add_sgs(vgpio->event_vq, sgs, 1, 1, irq_line, GFP_ATOMIC);
+ if (ret) {
+ dev_err(&vgpio->vdev->dev, "failed to add request to eventq\n");
+ return;
+ }
+
+ irq_line->queued = true;
+ virtqueue_kick(vgpio->event_vq);
+}
+
+static void virtio_gpio_irq_mask(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct virtio_gpio *vgpio = gpiochip_get_data(gc);
+ struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
+
+ if (irq_line->masked)
+ return;
+
+ irq_line->masked = true;
+ irq_line->mask_pending = !irq_line->mask_pending;
+}
+
+static void virtio_gpio_irq_unmask(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct virtio_gpio *vgpio = gpiochip_get_data(gc);
+ struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
+
+ /* Queue the buffer unconditionally on unmask */
+ virtio_gpio_irq_prepare(vgpio, d->hwirq);
+
+ if (!irq_line->masked)
+ return;
+
+ irq_line->masked = false;
+ irq_line->mask_pending = !irq_line->mask_pending;
+}
+
+static int virtio_gpio_irq_set_type(struct irq_data *d, unsigned int type)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct virtio_gpio *vgpio = gpiochip_get_data(gc);
+ struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
+
+ switch (type) {
+ case IRQ_TYPE_NONE:
+ type = VIRTIO_GPIO_IRQ_TYPE_NONE;
+ break;
+ case IRQ_TYPE_EDGE_RISING:
+ type = VIRTIO_GPIO_IRQ_TYPE_EDGE_RISING;
+ break;
+ case IRQ_TYPE_EDGE_FALLING:
+ type = VIRTIO_GPIO_IRQ_TYPE_EDGE_FALLING;
+ break;
+ case IRQ_TYPE_EDGE_BOTH:
+ type = VIRTIO_GPIO_IRQ_TYPE_EDGE_BOTH;
+ break;
+ case IRQ_TYPE_LEVEL_LOW:
+ type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_LOW;
+ break;
+ case IRQ_TYPE_LEVEL_HIGH:
+ type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_HIGH;
+ break;
+ default:
+ dev_err(&vgpio->vdev->dev, "unsupported irq type: %u\n", type);
+ return -EINVAL;
+ }
+
+ irq_line->type = type;
+ irq_line->type_pending = true;
+
+ return 0;
+}
+
+static void update_irq_type(struct virtio_gpio *vgpio, u16 gpio, u8 type)
+{
+ virtio_gpio_req(vgpio, VIRTIO_GPIO_MSG_IRQ_TYPE, gpio, type, NULL);
+}
+
+static void virtio_gpio_irq_bus_lock(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct virtio_gpio *vgpio = gpiochip_get_data(gc);
+
+ mutex_lock(&vgpio->irq_lock);
+}
+
+static void virtio_gpio_irq_bus_sync_unlock(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct virtio_gpio *vgpio = gpiochip_get_data(gc);
+ struct vgpio_irq_line *irq_line = &vgpio->irq_lines[d->hwirq];
+ u8 type = irq_line->masked ? VIRTIO_GPIO_IRQ_TYPE_NONE : irq_line->type;
+
+ if (irq_line->mask_pending || irq_line->type_pending) {
+ irq_line->mask_pending = false;
+ irq_line->type_pending = false;
+ update_irq_type(vgpio, d->hwirq, type);
+ }
+
+ mutex_unlock(&vgpio->irq_lock);
+}
+
+static struct irq_chip vgpio_irq_chip = {
+ .name = "virtio-gpio",
+ .irq_mask = virtio_gpio_irq_mask,
+ .irq_unmask = virtio_gpio_irq_unmask,
+ .irq_set_type = virtio_gpio_irq_set_type,
+
+ /* These are required to implement irqchip for slow busses */
+ .irq_bus_lock = virtio_gpio_irq_bus_lock,
+ .irq_bus_sync_unlock = virtio_gpio_irq_bus_sync_unlock,
+};
+
+static void virtio_gpio_event_vq(struct virtqueue *vq)
+{
+ struct virtio_gpio *vgpio = vq->vdev->priv;
+ struct device *dev = &vgpio->vdev->dev;
+ struct vgpio_irq_line *irq_line;
+ int irq, gpio, ret;
+ unsigned int len;
+
+ while (true) {
+ irq_line = virtqueue_get_buf(vgpio->event_vq, &len);
+ if (!irq_line)
+ break;
+
+ if (len != sizeof(irq_line->ires)) {
+ dev_err(dev, "irq with incorrect length (%u : %u)\n",
+ len, (unsigned)sizeof(irq_line->ires));
+ continue;
+ }
+
+ WARN_ON(!irq_line->queued);
+ irq_line->queued = false;
+
+ /* Buffer is returned after interrupt is masked */
+ if (irq_line->ires.status == VIRTIO_GPIO_IRQ_STATUS_INVALID)
+ continue;
+
+ if (WARN_ON(irq_line->ires.status != VIRTIO_GPIO_IRQ_STATUS_VALID))
+ continue;
+
+ /*
+ * Find GPIO line number from the offset of irq_line within the
+ * irq_lines block. We can also get GPIO number from
+ * irq-request, but better not rely on a value returned by
+ * remote.
+ */
+ gpio = irq_line - vgpio->irq_lines;
+ WARN_ON(gpio >= vgpio->config.ngpio);
+
+ irq = irq_find_mapping(vgpio->gc.irq.domain, gpio);
+ WARN_ON(!irq);
+
+ ret = generic_handle_irq(irq);
+ if (ret)
+ dev_err(dev, "failed to handle interrupt: %d\n", ret);
+ };
+}
+
static void virtio_gpio_request_vq(struct virtqueue *vq)
{
struct virtio_gpio_line *line;
@@ -211,14 +407,15 @@ static void virtio_gpio_free_vqs(struct virtio_device *vdev)
static int virtio_gpio_alloc_vqs(struct virtio_gpio *vgpio,
struct virtio_device *vdev)
{
- const char * const names[] = { "requestq" };
+ const char * const names[] = { "requestq", "eventq" };
vq_callback_t *cbs[] = {
virtio_gpio_request_vq,
+ virtio_gpio_event_vq,
};
- struct virtqueue *vqs[1] = { NULL };
+ struct virtqueue *vqs[2] = { NULL, NULL };
int ret;

- ret = virtio_find_vqs(vdev, 1, vqs, cbs, names, NULL);
+ ret = virtio_find_vqs(vdev, vgpio->irq_lines ? 2 : 1, vqs, cbs, names, NULL);
if (ret) {
dev_err(&vdev->dev, "failed to find vqs: %d\n", ret);
return ret;
@@ -226,11 +423,23 @@ static int virtio_gpio_alloc_vqs(struct virtio_gpio *vgpio,

if (!vqs[0]) {
dev_err(&vdev->dev, "failed to find requestq vq\n");
- return -ENODEV;
+ goto out;
}
vgpio->request_vq = vqs[0];

+ if (vgpio->irq_lines && !vqs[1]) {
+ dev_err(&vdev->dev, "failed to find eventq vq\n");
+ goto out;
+ }
+ vgpio->event_vq = vqs[1];
+
return 0;
+
+out:
+ if (vqs[0] || vqs[1])
+ virtio_gpio_free_vqs(vdev);
+
+ return -ENODEV;
}

static const char **virtio_gpio_get_names(struct virtio_gpio *vgpio)
@@ -326,6 +535,30 @@ static int virtio_gpio_probe(struct virtio_device *vdev)
vgpio->gc.owner = THIS_MODULE;
vgpio->gc.can_sleep = true;

+ /* Interrupt support */
+ if (virtio_has_feature(vdev, VIRTIO_GPIO_F_IRQ)) {
+ vgpio->irq_lines = devm_kcalloc(dev, config->ngpio,
+ sizeof(*vgpio->irq_lines),
+ GFP_KERNEL);
+ if (!vgpio->irq_lines)
+ return -ENOMEM;
+
+ /* The event comes from the outside so no parent handler */
+ vgpio->gc.irq.parent_handler = NULL;
+ vgpio->gc.irq.num_parents = 0;
+ vgpio->gc.irq.parents = NULL;
+ vgpio->gc.irq.default_type = IRQ_TYPE_NONE;
+ vgpio->gc.irq.handler = handle_level_irq;
+ vgpio->gc.irq.chip = &vgpio_irq_chip;
+
+ for (i = 0; i < config->ngpio; i++) {
+ vgpio->irq_lines[i].type = VIRTIO_GPIO_IRQ_TYPE_NONE;
+ vgpio->irq_lines[i].masked = true;
+ }
+
+ mutex_init(&vgpio->irq_lock);
+ }
+
ret = virtio_gpio_alloc_vqs(vgpio, vdev);
if (ret)
return ret;
@@ -358,7 +591,13 @@ static const struct virtio_device_id id_table[] = {
};
MODULE_DEVICE_TABLE(virtio, id_table);

+static const unsigned int features[] = {
+ VIRTIO_GPIO_F_IRQ,
+};
+
static struct virtio_driver virtio_gpio_driver = {
+ .feature_table = features,
+ .feature_table_size = ARRAY_SIZE(features),
.id_table = id_table,
.probe = virtio_gpio_probe,
.remove = virtio_gpio_remove,