[PATCH v2 0/2] uio: Allow to take irq bottom-half into irq_handler with additional dt-binding

[PATCH v2 0/2] uio: Allow to take irq bottom-half into irq_handler with additional dt-binding

[Andrey Zhizhikin]

This patch series aimed to introduce additional feature for UIO driver with
generic interrupt handler to allow IRQ bottom half to be executed in
irq_handler context rather than as threaded IRQ.

Andrey Zhizhikin (2):
  uio: Allow to take irq bottom-half into irq_handler with additional
    dt-binding
  uio: Introduce UIO driver dt-binding documentation

 .../devicetree/bindings/uio/uio-pdrv-genirq.txt    | 46 ++++++++++++++++++++++
 drivers/uio/uio_pdrv_genirq.c                      | 15 +++++++
 2 files changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/uio/uio-pdrv-genirq.txt

-- 
2.7.4

[PATCH v2 1/2] uio: Allow to take irq bottom-half into irq_handler with additional dt-binding

[Andrey Zhizhikin]

Certain Kernel preemption models are using threaded interrupt handlers,
which is in general quite beneficial. However, threaded handlers
introducing additional scheduler overhead, when the bottom-half thread
should be woken up and scheduled for execution. This can result is
additional latency, which in certain cases is not desired.

UIO driver with Generic IRQ handler, that wraps a HW block might suffer
a small degradation when it's bottom half is executed, since it needs
its bottom half to be woken up by the scheduler every time INT is
delivered. For high rate INT signals, this also bring additional
undesired load on the scheduler itself.

Since the actual ACK is performed in the top-half, and bottom-half of
the UIO driver with Generic IRQ handler is relatively slick (only flag
is set based on the INT reception), it might be beneficial to move this
bottom-half to the irq_handler itself, rather than to have a separate
thread to service it.

This patch aims to address the task above by supplying IRQF_NO_THREAD to
request_irq(), based on dt-binding which could be configured on a per-node
basis. That means developers utilizing the UIO driver could decide which
UIO instance is critical in terms of interrupt processing, and move their
corresponding bottom-halves to the irq_handler to fight additional
scheduling latency. When additional property is not found in corresponding
dt-node, then instance behavior is not amended and overall system stays
with default configuration for threaded IRQ (depending on how they are
configured by Preemption model).

Patch was originated on the ARM-based system with Kernel configuration
CONFIG_PREEMPT_RT_FULL set, which effectively promotes all bottom-halves
to threaded interrupt handlers. Once this patch has been enabled on 2
individual uio device nodes (out of around 20 registered in the system),
no additional negative impact has been noted on the system overall.

Having this patch enabled for individual UIO node allowed to have a
latency reduction of around 20-30 usec from INT trigger to the user space
IRQ handler. Those results can vary based on the platform and CPU
architecture, but could be quite beneficial if above gain in comparable
to the worst-case latency figures.

This modification also brings several additional benefits:
- It eliminates few re-scheduling operations, making INT ACK code more
robust and relieves the pressure from the scheduler when HW interrupt
for this IRQ is signaled at a high-enough frequency;
- It makes top and bottom half to be executed back-to-back with IRQ
OFF, making operation pseudo-atomic;
- Above gain might be significant when average latency times for the
systems are comparable

Signed-off-by: Andrey Zhizhikin <andrey.z-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c
index f598ecd..86427a4 100644
--- a/drivers/uio/uio_pdrv_genirq.c
+++ b/drivers/uio/uio_pdrv_genirq.c
@@ -108,6 +108,7 @@ static int uio_pdrv_genirq_probe(struct platform_device *pdev)
 	struct uio_pdrv_genirq_platdata *priv;
 	struct uio_mem *uiomem;
 	int ret = -EINVAL;
+	int no_threaded_irq = 0;
 	int i;
 
 	if (pdev->dev.of_node) {
@@ -121,6 +122,14 @@ static int uio_pdrv_genirq_probe(struct platform_device *pdev)
 		uioinfo->name = pdev->dev.of_node->name;
 		uioinfo->version = "devicetree";
 		/* Multiple IRQs are not supported */
+
+		/* read additional property (if exists) and decide whether
+		 * to have IRQ bottom half to be executed in a separate
+		 * thread, or to have it executed in the irq_handler
+		 * context
+		 */
+		if (of_property_read_bool(pdev->dev.of_node, "no-threaded-irq"))
+			no_threaded_irq = 1;
 	}
 
 	if (!uioinfo || !uioinfo->name || !uioinfo->version) {
@@ -134,6 +143,12 @@ static int uio_pdrv_genirq_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	/* execute BH in irq_handler if property set in FDT */
+	if ((no_threaded_irq > 0) && !(uioinfo->irq_flags & IRQF_NO_THREAD)) {
+		dev_info(&pdev->dev, "promoting INT with IRQF_NO_THREAD\n");
+		uioinfo->irq_flags |= IRQF_NO_THREAD;
+	}
+
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv) {
 		dev_err(&pdev->dev, "unable to kmalloc\n");
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] uio: Introduce UIO driver dt-binding documentation

[Andrey Zhizhikin]

Create Documentation portion of UIO driver with Generic Interrupt Handler.

This patch creates a dt-binding documentation portion of the UIO Driver.

In addition to definition of standard required properties, new optional
property defined:
- no-threaded-irq: when present, request_irq() is called with
  IRQF_NO_THREAD flag set, effectively skipping threaded interrupt
  handler and taking bottom-half into irq_handler

Signed-off-by: Andrey Zhizhikin <andrey.z@gmail.com>

diff --git a/Documentation/devicetree/bindings/uio/uio-pdrv-genirq.txt b/Documentation/devicetree/bindings/uio/uio-pdrv-genirq.txt
new file mode 100644
index 0000000..dfcc362
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/uio-pdrv-genirq.txt
@@ -0,0 +1,46 @@
+* Userspace I/O platform driver with generic IRQ handling code.
+
+Platform driver for User-space IO handling with generic IRQ code.
+This driver is very similar to the regular UIO platform driver, but is
+only suitable for devices that are connected to the interrupt
+controller using unique interrupt lines.
+
+Required properties:
+- compatible: Driver compatible string. For UIO device with generic IRQ
+  handling code this property is defined in device tree to any desired
+  name, and then set via module parameters passed to Kernel command line
+  in a form:
+  uio_pdrv_genirq.of_id=<your name>
+
+- reg: Physical base address and size for memory mapped region to be accessed
+  via UIO driver.
+
+- interrupts: Platform IRQ standard definition. For details on defining this
+  property, see interrupt-controller/interrupts.txt
+
+- interrupt-parent: Parent interrupt controller node.
+  For details, see interrupt-controller/interrupts.txt
+
+Optional properties:
+- no-threaded-irq: when present, request_irq() is called with IRQF_NO_THREAD
+  flag set, effectively skipping threaded interrupt handler and taking
+  bottom-half into irq_handler
+
+
+Examples:
+
+base-uio {
+	compatible = "platform-uio";
+	reg = < 0xC0000000 0x00020000 >;
+	interrupts = < 0 10 1 >;
+	interrupt-parent = <&intc>;
+};
+
+nothreaded-uio {
+	compatible = "platform-uio";
+	reg = < 0xC0040000 0x00020000 >;
+	interrupts = < 0 27 1 >;
+	interrupt-parent = <&intc>;
+	no-threaded-irq;
+};
+
-- 
2.7.4

Re: [PATCH v2 2/2] uio: Introduce UIO driver dt-binding documentation

[Rob Herring]

On Thu, Dec 07, 2017 at 03:46:59PM +0100, Andrey Zhizhikin wrote:
> Create Documentation portion of UIO driver with Generic Interrupt Handler.
> 
> This patch creates a dt-binding documentation portion of the UIO Driver.
> 
> In addition to definition of standard required properties, new optional
> property defined:
> - no-threaded-irq: when present, request_irq() is called with
>   IRQF_NO_THREAD flag set, effectively skipping threaded interrupt
>   handler and taking bottom-half into irq_handler
> 
> Signed-off-by: Andrey Zhizhikin <andrey.z-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> diff --git a/Documentation/devicetree/bindings/uio/uio-pdrv-genirq.txt b/Documentation/devicetree/bindings/uio/uio-pdrv-genirq.txt
> new file mode 100644
> index 0000000..dfcc362
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/uio/uio-pdrv-genirq.txt
> @@ -0,0 +1,46 @@
> +* Userspace I/O platform driver with generic IRQ handling code.

No. See prior discussions:

https://lkml.org/lkml/2016/5/18/457
https://lkml.org/lkml/2017/10/8/238
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] uio: Introduce UIO driver dt-binding documentation

[Andrey Zhizhikin]

Hello Rob,

Thanks for your reply here!

>
> No. See prior discussions:
>
> https://lkml.org/lkml/2016/5/18/457
> https://lkml.org/lkml/2017/10/8/238

Just for my clarify; to understand how to move on with the patch:
Since UIO is not considered as a real HW and rather a aggregate, which
could be used for to wrap virtually any HW block - does that mean no
new dt-bindings would be accepted to it?

I agree it is really hard (and practically impossible) to create
compatible strings for all HW units potentially using UIO as a
container, therefore I can see clearly arguments here.

But if considered from a driver perspective: there is already DT
awareness in the UIO driver (specifically the pdrv-genirq), and we
have a "HW-like" functionality (irq handler, iomem and ioreg regions)
which could be covered by the DT bindings. What if those "generic"
properties that covers only those pieces of the UIO driver code could
be assigned corresponding dt-bindings? I believe it is not the best
and rather contradictory approach to not have any "compatible" string,
but as long as those driver parameters are covered by DT properties,
isn't it OK to have them?

I can assume a lot of people are using UIO in exactly this way:
defining a node in their DTS, assigning "compatible" via kernel
command line and having devnode instantiated. Why can't a possibility
be provided to them to have a generic description of how they can
configure, tweak and use their UIO drivers in the correct and
efficient way? This is especially true for people that are using FPGAs
and enveloping their Soft-IPs with UIO to have a generic
status/control capabilities. I cannot imagine how this tremendous
amount of variations could be easily accommodated inside UIO
compatible names...

Or am I completely missing a point here?

-- 
Regards,
Andrey.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html