[Xenomai] RT serial cross-link failure

[Xenomai] RT serial cross-link failure

[Michael Welling]

I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.

The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.

When I run the cross-link demo the system hangs after an error in read_task.

Here is the output that I get:
main : write-file opened
main : write-config written
main : read-file opened
main : read-config written
main : write-task created
main : read-task created
main : starting write-task
main : strating read-task
 Nr |   write-irq    |    irq->read    |   write->read   |
----------------------------------------------------------
read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
main : /dev/rtdm/rtser1 (read) -> closed
read_task: exit

Any ideas why this would happen?

I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.

Re: [Xenomai] RT serial cross-link failure

[Wolfgang Netbal]

Am 2016-02-15 um 18:41 schrieb Michael Welling:
> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
>
> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
>
> When I run the cross-link demo the system hangs after an error in read_task.
>
> Here is the output that I get:
> main : write-file opened
> main : write-config written
> main : read-file opened
> main : read-config written
> main : write-task created
> main : read-task created
> main : starting write-task
> main : strating read-task
>   Nr |   write-irq    |    irq->read    |   write->read   |
> ----------------------------------------------------------
> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> main : /dev/rtdm/rtser1 (read) -> closed
> read_task: exit
>
> Any ideas why this would happen?
>
> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
Dear Michael,

I added a patch on December where I extended the IMX UART driver to 
support open firmware, maybe my patch can help you to find your issue.
I posted the patch in the mailing list, you can find it here 
https://xenomai.org/pipermail/xenomai/2015-December/035655.html

Kind regards
Wolfgang
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>

Re: [Xenomai] RT serial cross-link failure

[Michael Welling]

On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> 
> 
> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> >I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> >
> >The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> >
> >When I run the cross-link demo the system hangs after an error in read_task.
> >
> >Here is the output that I get:
> >main : write-file opened
> >main : write-config written
> >main : read-file opened
> >main : read-config written
> >main : write-task created
> >main : read-task created
> >main : starting write-task
> >main : strating read-task
> >  Nr |   write-irq    |    irq->read    |   write->read   |
> >----------------------------------------------------------
> >read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> >main : /dev/rtdm/rtser1 (read) -> closed
> >read_task: exit
> >
> >Any ideas why this would happen?
> >
> >I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> Dear Michael,
> 
> I added a patch on December where I extended the IMX UART driver to support
> open firmware, maybe my patch can help you to find your issue.
> I posted the patch in the mailing list, you can find it here
> https://xenomai.org/pipermail/xenomai/2015-December/035655.html

This patch does not seem to apply to the driver in the xenomai-3
repository.

Is there another patch that adds the devicetree stuff?

Re: [Xenomai] RT serial cross-link failure

[Gilles Chanteperdrix]

On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> 
> 
> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> > I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> >
> > The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> >
> > When I run the cross-link demo the system hangs after an error in read_task.
> >
> > Here is the output that I get:
> > main : write-file opened
> > main : write-config written
> > main : read-file opened
> > main : read-config written
> > main : write-task created
> > main : read-task created
> > main : starting write-task
> > main : strating read-task
> >   Nr |   write-irq    |    irq->read    |   write->read   |
> > ----------------------------------------------------------
> > read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> > main : /dev/rtdm/rtser1 (read) -> closed
> > read_task: exit
> >
> > Any ideas why this would happen?
> >
> > I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> Dear Michael,
> 
> I added a patch on December where I extended the IMX UART driver to 
> support open firmware, maybe my patch can help you to find your issue.
> I posted the patch in the mailing list, you can find it here 
> https://xenomai.org/pipermail/xenomai/2015-December/035655.html

Please, as indicated at the bottom of every mail you receive from
the mailing list, and in the mail headers, the address of the
mailing list is xenomai@xenomai.org.

IT IS NOT xenomai-bounces@xenomai.org

When you send a regular mail to this wrong address, the mail
administrators receive a mail, because, as its name indicates, this
address is made to receive bounces. This is annoying.


-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] RT serial cross-link failure

[Michael Welling]

On Tue, Feb 16, 2016 at 06:29:24PM +0100, Gilles Chanteperdrix wrote:
> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> > 
> > 
> > Am 2016-02-15 um 18:41 schrieb Michael Welling:
> > > I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> > >
> > > The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> > >
> > > When I run the cross-link demo the system hangs after an error in read_task.
> > >
> > > Here is the output that I get:
> > > main : write-file opened
> > > main : write-config written
> > > main : read-file opened
> > > main : read-config written
> > > main : write-task created
> > > main : read-task created
> > > main : starting write-task
> > > main : strating read-task
> > >   Nr |   write-irq    |    irq->read    |   write->read   |
> > > ----------------------------------------------------------
> > > read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> > > main : /dev/rtdm/rtser1 (read) -> closed
> > > read_task: exit
> > >
> > > Any ideas why this would happen?
> > >
> > > I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> > Dear Michael,
> > 
> > I added a patch on December where I extended the IMX UART driver to 
> > support open firmware, maybe my patch can help you to find your issue.
> > I posted the patch in the mailing list, you can find it here 
> > https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> 
> Please, as indicated at the bottom of every mail you receive from
> the mailing list, and in the mail headers, the address of the
> mailing list is xenomai@xenomai.org.
> 
> IT IS NOT xenomai-bounces@xenomai.org
> 
> When you send a regular mail to this wrong address, the mail
> administrators receive a mail, because, as its name indicates, this
> address is made to receive bounces. This is annoying.
>

Sorry I did not notice this on the reply.

Do you have any idea what driver Wolfgang's patch applies to?
 
> 
> -- 
> 					    Gilles.
> https://click-hack.org
> 
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] RT serial cross-link failure

[Michael Welling]

On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> 
> 
> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> >I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> >
> >The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> >
> >When I run the cross-link demo the system hangs after an error in read_task.
> >
> >Here is the output that I get:
> >main : write-file opened
> >main : write-config written
> >main : read-file opened
> >main : read-config written
> >main : write-task created
> >main : read-task created
> >main : starting write-task
> >main : strating read-task
> >  Nr |   write-irq    |    irq->read    |   write->read   |
> >----------------------------------------------------------
> >read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> >main : /dev/rtdm/rtser1 (read) -> closed
> >read_task: exit
> >
> >Any ideas why this would happen?
> >
> >I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> Dear Michael,
> 
> I added a patch on December where I extended the IMX UART driver to support
> open firmware, maybe my patch can help you to find your issue.
> I posted the patch in the mailing list, you can find it here
> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> 
> Kind regards
> Wolfgang

See patch for what I have done so far below:

diff --git a/kernel/drivers/serial/rt_imx_uart.c b/kernel/drivers/serial/rt_imx_uart.c
index 092cecc..91f86ce 100644
--- a/kernel/drivers/serial/rt_imx_uart.c
+++ b/kernel/drivers/serial/rt_imx_uart.c
@@ -36,8 +36,10 @@
 #include <asm/irq.h>
 #include <asm/dma.h>
 #include <asm/div64.h>
-#include <mach/hardware.h>
-#include <mach/imx-uart.h>
+#include <linux/platform_data/serial-imx.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
 
 #include <rtdm/serial.h>
 #include <rtdm/driver.h>
@@ -65,7 +67,9 @@ MODULE_LICENSE("GPL");
 #define UBMR	0xa8 /* BRM Modulator Register */
 #define UBRC	0xac /* Baud Rate Count Register */
 #define MX2_ONEMS 0xb0 /* One Millisecond register */
-#define UTS (cpu_is_mx1() ? 0xd0 : 0xb4) /* UART Test Register */
+#define IMX1_UTS 0xd0 /* UART Test Register on i.mx1 */
+#define IMX21_UTS 0xb4 /* UART Test Register on all other i.mx*/
+
 
 /* UART Control Register Bit Fields.*/
 #define URXD_CHARRDY	(1<<15)
@@ -189,18 +193,32 @@ MODULE_LICENSE("GPL");
 #define RT_IMX_UART_MAX		5
 
 static int tx_fifo[RT_IMX_UART_MAX];
-compat_module_param_array(tx_fifo, int, RT_IMX_UART_MAX, 0400);
+module_param_array(tx_fifo, int, NULL, 0400);
 MODULE_PARM_DESC(tx_fifo, "Transmitter FIFO size");
 
+/* i.mx21 type uart runs on all i.mx except i.mx1 */
+enum imx_uart_type {
+        IMX1_UART,
+        IMX21_UART,
+        IMX6Q_UART,
+};
+
+/* device type dependent stuff */
+struct imx_uart_data {
+        unsigned uts_reg;
+        enum imx_uart_type devtype;
+};
+
 struct rt_imx_uart_port {
 	unsigned char __iomem *membase;	/* read/write[bwl] */
-	resource_size_t mapbase;	/* for ioremap */
 	unsigned int irq;		/* irq number */
 	int tx_fifo;			/* TX fifo size*/
 	unsigned int have_rtscts;
 	unsigned int use_dcedte;
 	unsigned int use_hwflow;
-	struct clk *clk;		/* clock id for UART clock */
+	struct clk *clk_ipg;
+	struct clk *clk_per;
+	const struct imx_uart_data *devdata;
 	unsigned int uartclk;		/* base uart clock */
 	struct rtdm_device rtdm_dev;	/* RTDM device structure */
 };
@@ -344,6 +362,7 @@ static int rt_imx_uart_rx_chars(struct rt_imx_uart_ctx *ctx,
 static void rt_imx_uart_tx_chars(struct rt_imx_uart_ctx *ctx)
 {
 	int ch, count;
+	unsigned uts_reg = ctx->port->devdata->uts_reg;
 
 	for (count = ctx->port->tx_fifo;
 	     (count > 0) && (ctx->out_npend > 0);
@@ -352,7 +371,7 @@ static void rt_imx_uart_tx_chars(struct rt_imx_uart_ctx *ctx)
 		writel(ch, ctx->port->membase + URTX0);
 		ctx->out_head &= (OUT_BUFFER_SIZE - 1);
 
-		if (readl(ctx->port->membase + UTS) & UTS_TXFULL)
+		if (readl(ctx->port->membase + uts_reg) & UTS_TXFULL)
 			break;
 	}
 }
@@ -493,9 +512,10 @@ static unsigned int rt_imx_uart_get_msr(struct rt_imx_uart_ctx *ctx)
 static void rt_imx_uart_set_mcr(struct rt_imx_uart_ctx *ctx,
 				unsigned int mcr)
 {
+	unsigned uts_reg = ctx->port->devdata->uts_reg;
 	unsigned long ucr2 = readl(ctx->port->membase + UCR2);
 	unsigned long ucr3 = readl(ctx->port->membase + UCR3);
-	unsigned long uts = readl(ctx->port->membase + UTS);
+	unsigned long uts = readl(ctx->port->membase + uts_reg);
 
 	if (mcr & RTSER_MCR_RTS) {
 		/*
@@ -523,7 +543,7 @@ static void rt_imx_uart_set_mcr(struct rt_imx_uart_ctx *ctx,
 		uts |= UTS_LOOP;
 	else
 		uts &= ~UTS_LOOP;
-	writel(uts, ctx->port->membase + UTS);
+	writel(uts, ctx->port->membase + uts_reg);
 }
 
 static void rt_imx_uart_break_ctl(struct rt_imx_uart_ctx *ctx,
@@ -723,7 +743,7 @@ static int rt_imx_uart_setup_ufcr(struct rt_imx_uart_port *port)
 	 * RFDIV is set such way to satisfy requested uartclk value
 	 */
 	val = TXTL << 10 | RXTL;
-	ufcr_rfdiv = (clk_get_rate(port->clk) + port->uartclk / 2) /
+	ufcr_rfdiv = (clk_get_rate(port->clk_per) + port->uartclk / 2) /
 		port->uartclk;
 
 	if (!ufcr_rfdiv)
@@ -897,7 +917,7 @@ static int rt_imx_uart_ioctl(struct rtdm_fd *fd,
 		}
 
 		if ((config->config_mask & RTSER_SET_BAUD) &&
-		    (config->baud_rate > clk_get_rate(ctx->port->clk) / 16 ||
+		    (config->baud_rate > clk_get_rate(ctx->port->clk_per) / 16 ||
 		     config->baud_rate <= 0))
 			/* invalid baudrate for this port */
 			return -EINVAL;
@@ -1382,42 +1402,134 @@ static struct rtdm_driver imx_uart_driver = {
 	},
 };
 
+static struct imx_uart_data imx_uart_devdata[] = {
+        [IMX1_UART] = {
+                .uts_reg = IMX1_UTS,
+                .devtype = IMX1_UART,
+        },
+        [IMX21_UART] = {
+                .uts_reg = IMX21_UTS,
+                .devtype = IMX21_UART,
+        },
+        [IMX6Q_UART] = {
+                .uts_reg = IMX21_UTS,
+                .devtype = IMX6Q_UART,
+        },
+};
+
+static struct platform_device_id rt_imx_uart_id_table[] = {
+        {
+                .name = "imx1-uart",
+                .driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX1_UART],
+        }, {
+                .name = "imx21-uart",
+                .driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX21_UART],
+        }, {
+                .name = "imx6q-uart",
+                .driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX6Q_UART],
+        }, {
+                /* sentinel */
+        }
+};
+MODULE_DEVICE_TABLE(platform, rt_imx_uart_id_table);
+
+static struct of_device_id rt_imx_uart_dt_ids[] = {
+        { .compatible = "fsl,imx6q-uart", .data = &imx_uart_devdata[IMX6Q_UART], },
+        { .compatible = "fsl,imx1-uart", .data = &imx_uart_devdata[IMX1_UART], },
+        { .compatible = "fsl,imx21-uart", .data = &imx_uart_devdata[IMX21_UART], },
+        { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rt_imx_uart_dt_ids);
+
+#ifdef CONFIG_OF
+
+/*
+ * This function returns 1 iff pdev isn't a device instatiated by dt, 0 iff it
+ * could successfully get all information from dt or a negative errno.
+ */
+static int rt_imx_uart_probe_dt(struct rt_imx_uart_port *port,
+                struct platform_device *pdev)
+{
+        struct device_node *np = pdev->dev.of_node;
+        const struct of_device_id *of_id =
+                        of_match_device(rt_imx_uart_dt_ids, &pdev->dev);
+        int ret;
+
+        if (!np)
+                /* no device tree device */
+                return 1;
+
+        ret = of_alias_get_id(np, "serial");
+        if (ret < 0) {
+                dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
+                return ret;
+        }
+
+	pdev->id = ret;
+
+        if (of_get_property(np, "fsl,uart-has-rtscts", NULL))
+                port->have_rtscts = 1;
+
+        if (of_get_property(np, "fsl,irda-mode", NULL))
+                dev_warn(&pdev->dev, "IRDA not yet supported\n");
+
+        if (of_get_property(np, "fsl,dte-mode", NULL))
+		port->use_dcedte = 1;
+
+        port->devdata = of_id->data;
+
+        return 0;
+}
+#else
+static inline int rt_imx_uart_probe_dt(struct rt_imx_uart_port *port,
+                struct platform_device *pdev)
+{
+        return 1;
+}
+#endif
+
+static void rt_imx_uart_probe_pdata(struct rt_imx_uart_port *port,
+                struct platform_device *pdev)
+{
+        struct imxuart_platform_data *pdata = dev_get_platdata(&pdev->dev);
+
+        port->devdata = (struct imx_uart_data  *) pdev->id_entry->driver_data;
+
+        if (!pdata)
+                return;
+
+        if (pdata->flags & IMXUART_HAVE_RTSCTS)
+                port->have_rtscts = 1;
+}
+
 static int rt_imx_uart_probe(struct platform_device *pdev)
 {
-	struct imxuart_platform_data *pdata;
 	struct rtdm_device *dev;
 	struct rt_imx_uart_port *port;
 	struct resource *res;
-	int err;
+	int ret;
 
-	port = kzalloc(sizeof(*port), GFP_KERNEL);
+	port = devm_kzalloc(&pdev->dev, sizeof(*port), GFP_KERNEL);
 	if (!port)
 		return -ENOMEM;
 
+        ret = rt_imx_uart_probe_dt(port, pdev);
+        if (ret > 0)
+                rt_imx_uart_probe_pdata(port, pdev);
+        else if (ret < 0)
+                return ret;
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!res) {
-		err = -ENODEV;
-		goto kfree_out;
-	}
-	port->mapbase = res->start;
+	if (!res)
+		return -ENODEV;
 
 	port->irq = platform_get_irq(pdev, 0);
-	if (port->irq <= 0) {
-		err = -ENODEV;
-		goto kfree_out;
-	}
-
-	if (!request_mem_region(port->mapbase, PAGE_SIZE, DRIVER_NAME)) {
-		err = -EBUSY;
-		goto kfree_out;
-	}
-
-	port->membase = ioremap(port->mapbase, PAGE_SIZE);
-	if (!port->membase) {
-		err = -ENOMEM;
-		goto release_mem_region_out;
-	}
+	if (port->irq <= 0)
+		return -ENODEV;
 
+	port->membase = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(port->membase))
+		return PTR_ERR(port->membase);
 
 	dev = &port->rtdm_dev;
 	dev->driver = &imx_uart_driver;
@@ -1429,54 +1541,31 @@ static int rt_imx_uart_probe(struct platform_device *pdev)
 	else
 		port->tx_fifo = tx_fifo[pdev->id];
 
-	port->clk = clk_get(&pdev->dev, "uart");
-	if (IS_ERR(port->clk)) {
-		err = PTR_ERR(port->clk);
-		goto iounmap_out;
-	}
-	clk_enable(port->clk);
-	port->uartclk = clk_get_rate(port->clk);
+	port->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
+	if (IS_ERR(port->clk_ipg))
+		return PTR_ERR(port->clk_ipg);
 
-	port->use_hwflow = 1;
+	port->clk_per = devm_clk_get(&pdev->dev, "per");
+	if (IS_ERR(port->clk_per))
+		return PTR_ERR(port->clk_per);
 
-	pdata = pdev->dev.platform_data;
-	if (pdata && (pdata->flags & IMXUART_HAVE_RTSCTS))
-		port->have_rtscts = 1;
-	if (pdata && (pdata->flags & IMXUART_USE_DCEDTE))
-		port->use_dcedte = 1;
-	if (pdata && pdata->init) {
-		err = pdata->init(pdev);
-		if (err)
-			goto clk_disable_out;
-	}
+	clk_enable(port->clk_ipg);
+	clk_enable(port->clk_per);
+	port->uartclk = clk_get_rate(port->clk_per);
+
+	port->use_hwflow = 1;
 
-	err = rtdm_dev_register(dev);
-	if (err)
-		goto pdata_exit_out;
+	ret = rtdm_dev_register(dev);
+	if (ret)
+		return ret;
 
 	platform_set_drvdata(pdev, port);
 
 	printk(KERN_INFO
-	       "%s on IMX UART%d: membase=0x%p mapbase=%#x irq=%d uartclk=%d\n",
-	       dev->name, pdev->id, port->membase, (u32)port->mapbase,
-	       port->irq, port->uartclk);
+	       "%s on IMX UART%d: membase=0x%p irq=%d uartclk=%d\n",
+	       dev->name, pdev->id, port->membase, port->irq, port->uartclk);
 
 	return 0;
-
-pdata_exit_out:
-	if (pdata && pdata->exit)
-		pdata->exit(pdev);
-clk_disable_out:
-	clk_put(port->clk);
-	clk_disable(port->clk);
-iounmap_out:
-	iounmap(port->membase);
-release_mem_region_out:
-	release_mem_region(port->mapbase, SZ_4K);
-kfree_out:
-	kfree(port);
-
-	return err;
 }
 
 static int rt_imx_uart_remove(struct platform_device *pdev)
@@ -1490,26 +1579,9 @@ static int rt_imx_uart_remove(struct platform_device *pdev)
 
 	rtdm_dev_unregister(dev);
 
-	if (port->clk) {
-		clk_put(port->clk);
-		clk_disable(port->clk);
-	}
-
-	if (pdata && pdata->exit)
-		pdata->exit(pdev);
-
-	iounmap(port->membase);
-	release_mem_region(port->mapbase, PAGE_SIZE);
-	kfree(port);
-
 	return 0;
 }
 
-static const struct platform_device_id rt_imx_uart_id_table[] = {
-	{"imx-uart",},
-	{},
-};
-
 static struct platform_driver rt_imx_uart_driver = {
 	.probe = rt_imx_uart_probe,
 	.remove	= rt_imx_uart_remove,
@@ -1517,6 +1589,7 @@ static struct platform_driver rt_imx_uart_driver = {
 	.driver = {
 		.name = DRIVER_NAME,
 		.owner = THIS_MODULE,
+		.of_match_table = rt_imx_uart_dt_ids,
 	},
 };
 

Re: [Xenomai] RT serial cross-link failure

[Wolfgang Netbal]

Am 2016-02-16 um 18:58 schrieb Michael Welling:
> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
>>
>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
>>>
>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
>>>
>>> When I run the cross-link demo the system hangs after an error in read_task.
>>>
>>> Here is the output that I get:
>>> main : write-file opened
>>> main : write-config written
>>> main : read-file opened
>>> main : read-config written
>>> main : write-task created
>>> main : read-task created
>>> main : starting write-task
>>> main : strating read-task
>>>   Nr |   write-irq    |    irq->read    |   write->read   |
>>> ----------------------------------------------------------
>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
>>> main : /dev/rtdm/rtser1 (read) -> closed
>>> read_task: exit
>>>
>>> Any ideas why this would happen?
>>>
>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
>> Dear Michael,
>>
>> I added a patch on December where I extended the IMX UART driver to support
>> open firmware, maybe my patch can help you to find your issue.
>> I posted the patch in the mailing list, you can find it here
>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
>>
>> Kind regards
>> Wolfgang
Sorry Michael,

My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> See patch for what I have done so far below:
>
> diff --git a/kernel/drivers/serial/rt_imx_uart.c b/kernel/drivers/serial/rt_imx_uart.c
> index 092cecc..91f86ce 100644
> --- a/kernel/drivers/serial/rt_imx_uart.c
> +++ b/kernel/drivers/serial/rt_imx_uart.c
> @@ -36,8 +36,10 @@
>   #include <asm/irq.h>
>   #include <asm/dma.h>
>   #include <asm/div64.h>
> -#include <mach/hardware.h>
> -#include <mach/imx-uart.h>
> +#include <linux/platform_data/serial-imx.h>
> +#include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
>   
>   #include <rtdm/serial.h>
>   #include <rtdm/driver.h>
> @@ -65,7 +67,9 @@ MODULE_LICENSE("GPL");
>   #define UBMR	0xa8 /* BRM Modulator Register */
>   #define UBRC	0xac /* Baud Rate Count Register */
>   #define MX2_ONEMS 0xb0 /* One Millisecond register */
> -#define UTS (cpu_is_mx1() ? 0xd0 : 0xb4) /* UART Test Register */
> +#define IMX1_UTS 0xd0 /* UART Test Register on i.mx1 */
> +#define IMX21_UTS 0xb4 /* UART Test Register on all other i.mx*/
> +
>   
>   /* UART Control Register Bit Fields.*/
>   #define URXD_CHARRDY	(1<<15)
> @@ -189,18 +193,32 @@ MODULE_LICENSE("GPL");
>   #define RT_IMX_UART_MAX		5
>   
>   static int tx_fifo[RT_IMX_UART_MAX];
> -compat_module_param_array(tx_fifo, int, RT_IMX_UART_MAX, 0400);
> +module_param_array(tx_fifo, int, NULL, 0400);
>   MODULE_PARM_DESC(tx_fifo, "Transmitter FIFO size");
>   
> +/* i.mx21 type uart runs on all i.mx except i.mx1 */
> +enum imx_uart_type {
> +        IMX1_UART,
> +        IMX21_UART,
> +        IMX6Q_UART,
> +};
> +
> +/* device type dependent stuff */
> +struct imx_uart_data {
> +        unsigned uts_reg;
> +        enum imx_uart_type devtype;
> +};
> +
>   struct rt_imx_uart_port {
>   	unsigned char __iomem *membase;	/* read/write[bwl] */
> -	resource_size_t mapbase;	/* for ioremap */
>   	unsigned int irq;		/* irq number */
>   	int tx_fifo;			/* TX fifo size*/
>   	unsigned int have_rtscts;
>   	unsigned int use_dcedte;
>   	unsigned int use_hwflow;
> -	struct clk *clk;		/* clock id for UART clock */
> +	struct clk *clk_ipg;
> +	struct clk *clk_per;
> +	const struct imx_uart_data *devdata;
>   	unsigned int uartclk;		/* base uart clock */
>   	struct rtdm_device rtdm_dev;	/* RTDM device structure */
>   };
> @@ -344,6 +362,7 @@ static int rt_imx_uart_rx_chars(struct rt_imx_uart_ctx *ctx,
>   static void rt_imx_uart_tx_chars(struct rt_imx_uart_ctx *ctx)
>   {
>   	int ch, count;
> +	unsigned uts_reg = ctx->port->devdata->uts_reg;
>   
>   	for (count = ctx->port->tx_fifo;
>   	     (count > 0) && (ctx->out_npend > 0);
> @@ -352,7 +371,7 @@ static void rt_imx_uart_tx_chars(struct rt_imx_uart_ctx *ctx)
>   		writel(ch, ctx->port->membase + URTX0);
>   		ctx->out_head &= (OUT_BUFFER_SIZE - 1);
>   
> -		if (readl(ctx->port->membase + UTS) & UTS_TXFULL)
> +		if (readl(ctx->port->membase + uts_reg) & UTS_TXFULL)
>   			break;
>   	}
>   }
> @@ -493,9 +512,10 @@ static unsigned int rt_imx_uart_get_msr(struct rt_imx_uart_ctx *ctx)
>   static void rt_imx_uart_set_mcr(struct rt_imx_uart_ctx *ctx,
>   				unsigned int mcr)
>   {
> +	unsigned uts_reg = ctx->port->devdata->uts_reg;
>   	unsigned long ucr2 = readl(ctx->port->membase + UCR2);
>   	unsigned long ucr3 = readl(ctx->port->membase + UCR3);
> -	unsigned long uts = readl(ctx->port->membase + UTS);
> +	unsigned long uts = readl(ctx->port->membase + uts_reg);
>   
>   	if (mcr & RTSER_MCR_RTS) {
>   		/*
> @@ -523,7 +543,7 @@ static void rt_imx_uart_set_mcr(struct rt_imx_uart_ctx *ctx,
>   		uts |= UTS_LOOP;
>   	else
>   		uts &= ~UTS_LOOP;
> -	writel(uts, ctx->port->membase + UTS);
> +	writel(uts, ctx->port->membase + uts_reg);
>   }
>   
>   static void rt_imx_uart_break_ctl(struct rt_imx_uart_ctx *ctx,
> @@ -723,7 +743,7 @@ static int rt_imx_uart_setup_ufcr(struct rt_imx_uart_port *port)
>   	 * RFDIV is set such way to satisfy requested uartclk value
>   	 */
>   	val = TXTL << 10 | RXTL;
> -	ufcr_rfdiv = (clk_get_rate(port->clk) + port->uartclk / 2) /
> +	ufcr_rfdiv = (clk_get_rate(port->clk_per) + port->uartclk / 2) /
>   		port->uartclk;
>   
>   	if (!ufcr_rfdiv)
> @@ -897,7 +917,7 @@ static int rt_imx_uart_ioctl(struct rtdm_fd *fd,
>   		}
>   
>   		if ((config->config_mask & RTSER_SET_BAUD) &&
> -		    (config->baud_rate > clk_get_rate(ctx->port->clk) / 16 ||
> +		    (config->baud_rate > clk_get_rate(ctx->port->clk_per) / 16 ||
>   		     config->baud_rate <= 0))
>   			/* invalid baudrate for this port */
>   			return -EINVAL;
> @@ -1382,42 +1402,134 @@ static struct rtdm_driver imx_uart_driver = {
>   	},
>   };
>   
> +static struct imx_uart_data imx_uart_devdata[] = {
> +        [IMX1_UART] = {
> +                .uts_reg = IMX1_UTS,
> +                .devtype = IMX1_UART,
> +        },
> +        [IMX21_UART] = {
> +                .uts_reg = IMX21_UTS,
> +                .devtype = IMX21_UART,
> +        },
> +        [IMX6Q_UART] = {
> +                .uts_reg = IMX21_UTS,
> +                .devtype = IMX6Q_UART,
> +        },
> +};
> +
> +static struct platform_device_id rt_imx_uart_id_table[] = {
> +        {
> +                .name = "imx1-uart",
> +                .driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX1_UART],
> +        }, {
> +                .name = "imx21-uart",
> +                .driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX21_UART],
> +        }, {
> +                .name = "imx6q-uart",
> +                .driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX6Q_UART],
> +        }, {
> +                /* sentinel */
> +        }
> +};
> +MODULE_DEVICE_TABLE(platform, rt_imx_uart_id_table);
> +
> +static struct of_device_id rt_imx_uart_dt_ids[] = {
> +        { .compatible = "fsl,imx6q-uart", .data = &imx_uart_devdata[IMX6Q_UART], },
> +        { .compatible = "fsl,imx1-uart", .data = &imx_uart_devdata[IMX1_UART], },
> +        { .compatible = "fsl,imx21-uart", .data = &imx_uart_devdata[IMX21_UART], },
> +        { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, rt_imx_uart_dt_ids);
> +
> +#ifdef CONFIG_OF
> +
> +/*
> + * This function returns 1 iff pdev isn't a device instatiated by dt, 0 iff it
> + * could successfully get all information from dt or a negative errno.
> + */
> +static int rt_imx_uart_probe_dt(struct rt_imx_uart_port *port,
> +                struct platform_device *pdev)
> +{
> +        struct device_node *np = pdev->dev.of_node;
> +        const struct of_device_id *of_id =
> +                        of_match_device(rt_imx_uart_dt_ids, &pdev->dev);
> +        int ret;
> +
> +        if (!np)
> +                /* no device tree device */
> +                return 1;
> +
> +        ret = of_alias_get_id(np, "serial");
> +        if (ret < 0) {
> +                dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
> +                return ret;
> +        }
> +
> +	pdev->id = ret;
> +
> +        if (of_get_property(np, "fsl,uart-has-rtscts", NULL))
> +                port->have_rtscts = 1;
> +
> +        if (of_get_property(np, "fsl,irda-mode", NULL))
> +                dev_warn(&pdev->dev, "IRDA not yet supported\n");
> +
> +        if (of_get_property(np, "fsl,dte-mode", NULL))
> +		port->use_dcedte = 1;
> +
> +        port->devdata = of_id->data;
> +
> +        return 0;
> +}
> +#else
> +static inline int rt_imx_uart_probe_dt(struct rt_imx_uart_port *port,
> +                struct platform_device *pdev)
> +{
> +        return 1;
> +}
> +#endif
> +
> +static void rt_imx_uart_probe_pdata(struct rt_imx_uart_port *port,
> +                struct platform_device *pdev)
> +{
> +        struct imxuart_platform_data *pdata = dev_get_platdata(&pdev->dev);
> +
> +        port->devdata = (struct imx_uart_data  *) pdev->id_entry->driver_data;
> +
> +        if (!pdata)
> +                return;
> +
> +        if (pdata->flags & IMXUART_HAVE_RTSCTS)
> +                port->have_rtscts = 1;
> +}
> +
>   static int rt_imx_uart_probe(struct platform_device *pdev)
>   {
> -	struct imxuart_platform_data *pdata;
>   	struct rtdm_device *dev;
>   	struct rt_imx_uart_port *port;
>   	struct resource *res;
> -	int err;
> +	int ret;
>   
> -	port = kzalloc(sizeof(*port), GFP_KERNEL);
> +	port = devm_kzalloc(&pdev->dev, sizeof(*port), GFP_KERNEL);
>   	if (!port)
>   		return -ENOMEM;
>   
> +        ret = rt_imx_uart_probe_dt(port, pdev);
> +        if (ret > 0)
> +                rt_imx_uart_probe_pdata(port, pdev);
> +        else if (ret < 0)
> +                return ret;
> +
>   	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	if (!res) {
> -		err = -ENODEV;
> -		goto kfree_out;
> -	}
> -	port->mapbase = res->start;
> +	if (!res)
> +		return -ENODEV;
>   
>   	port->irq = platform_get_irq(pdev, 0);
> -	if (port->irq <= 0) {
> -		err = -ENODEV;
> -		goto kfree_out;
> -	}
> -
> -	if (!request_mem_region(port->mapbase, PAGE_SIZE, DRIVER_NAME)) {
> -		err = -EBUSY;
> -		goto kfree_out;
> -	}
> -
> -	port->membase = ioremap(port->mapbase, PAGE_SIZE);
> -	if (!port->membase) {
> -		err = -ENOMEM;
> -		goto release_mem_region_out;
> -	}
> +	if (port->irq <= 0)
> +		return -ENODEV;
>   
> +	port->membase = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(port->membase))
> +		return PTR_ERR(port->membase);
>   
>   	dev = &port->rtdm_dev;
>   	dev->driver = &imx_uart_driver;
> @@ -1429,54 +1541,31 @@ static int rt_imx_uart_probe(struct platform_device *pdev)
>   	else
>   		port->tx_fifo = tx_fifo[pdev->id];
>   
> -	port->clk = clk_get(&pdev->dev, "uart");
> -	if (IS_ERR(port->clk)) {
> -		err = PTR_ERR(port->clk);
> -		goto iounmap_out;
> -	}
> -	clk_enable(port->clk);
> -	port->uartclk = clk_get_rate(port->clk);
> +	port->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
> +	if (IS_ERR(port->clk_ipg))
> +		return PTR_ERR(port->clk_ipg);
>   
> -	port->use_hwflow = 1;
> +	port->clk_per = devm_clk_get(&pdev->dev, "per");
> +	if (IS_ERR(port->clk_per))
> +		return PTR_ERR(port->clk_per);
>   
> -	pdata = pdev->dev.platform_data;
> -	if (pdata && (pdata->flags & IMXUART_HAVE_RTSCTS))
> -		port->have_rtscts = 1;
> -	if (pdata && (pdata->flags & IMXUART_USE_DCEDTE))
> -		port->use_dcedte = 1;
> -	if (pdata && pdata->init) {
> -		err = pdata->init(pdev);
> -		if (err)
> -			goto clk_disable_out;
> -	}
> +	clk_enable(port->clk_ipg);
> +	clk_enable(port->clk_per);
> +	port->uartclk = clk_get_rate(port->clk_per);
> +
> +	port->use_hwflow = 1;
>   
> -	err = rtdm_dev_register(dev);
> -	if (err)
> -		goto pdata_exit_out;
> +	ret = rtdm_dev_register(dev);
> +	if (ret)
> +		return ret;
>   
>   	platform_set_drvdata(pdev, port);
>   
>   	printk(KERN_INFO
> -	       "%s on IMX UART%d: membase=0x%p mapbase=%#x irq=%d uartclk=%d\n",
> -	       dev->name, pdev->id, port->membase, (u32)port->mapbase,
> -	       port->irq, port->uartclk);
> +	       "%s on IMX UART%d: membase=0x%p irq=%d uartclk=%d\n",
> +	       dev->name, pdev->id, port->membase, port->irq, port->uartclk);
>   
>   	return 0;
> -
> -pdata_exit_out:
> -	if (pdata && pdata->exit)
> -		pdata->exit(pdev);
> -clk_disable_out:
> -	clk_put(port->clk);
> -	clk_disable(port->clk);
> -iounmap_out:
> -	iounmap(port->membase);
> -release_mem_region_out:
> -	release_mem_region(port->mapbase, SZ_4K);
> -kfree_out:
> -	kfree(port);
> -
> -	return err;
>   }
>   
>   static int rt_imx_uart_remove(struct platform_device *pdev)
> @@ -1490,26 +1579,9 @@ static int rt_imx_uart_remove(struct platform_device *pdev)
>   
>   	rtdm_dev_unregister(dev);
>   
> -	if (port->clk) {
> -		clk_put(port->clk);
> -		clk_disable(port->clk);
> -	}
> -
> -	if (pdata && pdata->exit)
> -		pdata->exit(pdev);
> -
> -	iounmap(port->membase);
> -	release_mem_region(port->mapbase, PAGE_SIZE);
> -	kfree(port);
> -
>   	return 0;
>   }
>   
> -static const struct platform_device_id rt_imx_uart_id_table[] = {
> -	{"imx-uart",},
> -	{},
> -};
> -
>   static struct platform_driver rt_imx_uart_driver = {
>   	.probe = rt_imx_uart_probe,
>   	.remove	= rt_imx_uart_remove,
> @@ -1517,6 +1589,7 @@ static struct platform_driver rt_imx_uart_driver = {
>   	.driver = {
>   		.name = DRIVER_NAME,
>   		.owner = THIS_MODULE,
> +		.of_match_table = rt_imx_uart_dt_ids,
>   	},
>   };
>   
>

Re: [Xenomai] RT serial cross-link failure

[Michael Welling]

On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> 
> 
> Am 2016-02-16 um 18:58 schrieb Michael Welling:
> >On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> >>
> >>Am 2016-02-15 um 18:41 schrieb Michael Welling:
> >>>I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> >>>
> >>>The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> >>>
> >>>When I run the cross-link demo the system hangs after an error in read_task.
> >>>
> >>>Here is the output that I get:
> >>>main : write-file opened
> >>>main : write-config written
> >>>main : read-file opened
> >>>main : read-config written
> >>>main : write-task created
> >>>main : read-task created
> >>>main : starting write-task
> >>>main : strating read-task
> >>>  Nr |   write-irq    |    irq->read    |   write->read   |
> >>>----------------------------------------------------------
> >>>read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> >>>main : /dev/rtdm/rtser1 (read) -> closed
> >>>read_task: exit
> >>>
> >>>Any ideas why this would happen?
> >>>
> >>>I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> >>Dear Michael,
> >>
> >>I added a patch on December where I extended the IMX UART driver to support
> >>open firmware, maybe my patch can help you to find your issue.
> >>I posted the patch in the mailing list, you can find it here
> >>https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> >>
> >>Kind regards
> >>Wolfgang
> Sorry Michael,
> 
> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c

I am pretty sure that there is another patch applied previous.

If you look at your patch you see German comments and open firmware code that
is obviously not in the v2.6.4 on the git repository.

https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4

Re: [Xenomai] RT serial cross-link failure

[Wolfgang Netbal]

Am 2016-02-18 um 08:10 schrieb Michael Welling:
> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
>>
>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
>>>>>
>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
>>>>>
>>>>> When I run the cross-link demo the system hangs after an error in read_task.
>>>>>
>>>>> Here is the output that I get:
>>>>> main : write-file opened
>>>>> main : write-config written
>>>>> main : read-file opened
>>>>> main : read-config written
>>>>> main : write-task created
>>>>> main : read-task created
>>>>> main : starting write-task
>>>>> main : strating read-task
>>>>>   Nr |   write-irq    |    irq->read    |   write->read   |
>>>>> ----------------------------------------------------------
>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
>>>>> main : /dev/rtdm/rtser1 (read) -> closed
>>>>> read_task: exit
>>>>>
>>>>> Any ideas why this would happen?
>>>>>
>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
>>>> Dear Michael,
>>>>
>>>> I added a patch on December where I extended the IMX UART driver to support
>>>> open firmware, maybe my patch can help you to find your issue.
>>>> I posted the patch in the mailing list, you can find it here
>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
>>>>
>>>> Kind regards
>>>> Wolfgang
>> Sorry Michael,
>>
>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> I am pretty sure that there is another patch applied previous.
>
> If you look at your patch you see German comments and open firmware code that
> is obviously not in the v2.6.4 on the git repository.
>
> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
>
I posted my patch, because I thought that Wolfgang Grandegger the author 
of the driver may check it and include it to the xenomai if it is 
useable for other users.

Re: [Xenomai] RT serial cross-link failure

[Michael Welling]

On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
> 
> 
> Am 2016-02-18 um 08:10 schrieb Michael Welling:
> >On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> >>
> >>Am 2016-02-16 um 18:58 schrieb Michael Welling:
> >>>On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> >>>>Am 2016-02-15 um 18:41 schrieb Michael Welling:
> >>>>>I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> >>>>>
> >>>>>The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> >>>>>
> >>>>>When I run the cross-link demo the system hangs after an error in read_task.
> >>>>>
> >>>>>Here is the output that I get:
> >>>>>main : write-file opened
> >>>>>main : write-config written
> >>>>>main : read-file opened
> >>>>>main : read-config written
> >>>>>main : write-task created
> >>>>>main : read-task created
> >>>>>main : starting write-task
> >>>>>main : strating read-task
> >>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
> >>>>>----------------------------------------------------------
> >>>>>read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> >>>>>main : /dev/rtdm/rtser1 (read) -> closed
> >>>>>read_task: exit
> >>>>>
> >>>>>Any ideas why this would happen?
> >>>>>
> >>>>>I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> >>>>Dear Michael,
> >>>>
> >>>>I added a patch on December where I extended the IMX UART driver to support
> >>>>open firmware, maybe my patch can help you to find your issue.
> >>>>I posted the patch in the mailing list, you can find it here
> >>>>https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> >>>>
> >>>>Kind regards
> >>>>Wolfgang
> >>Sorry Michael,
> >>
> >>My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> >I am pretty sure that there is another patch applied previous.
> >
> >If you look at your patch you see German comments and open firmware code that
> >is obviously not in the v2.6.4 on the git repository.
> >
> >https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
> >
> I posted my patch, because I thought that Wolfgang Grandegger the author of
> the driver may check it and include it to the xenomai if it is useable for
> other users.
>

Yes but the patch does not apply to the driver in the source tree.
Please provide the driver that you have after the patch.

Re: [Xenomai] RT serial cross-link failure

[Michael Welling]

On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
> > 
> > 
> > Am 2016-02-18 um 08:10 schrieb Michael Welling:
> > >On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> > >>
> > >>Am 2016-02-16 um 18:58 schrieb Michael Welling:
> > >>>On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> > >>>>Am 2016-02-15 um 18:41 schrieb Michael Welling:
> > >>>>>I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> > >>>>>
> > >>>>>The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> > >>>>>
> > >>>>>When I run the cross-link demo the system hangs after an error in read_task.
> > >>>>>
> > >>>>>Here is the output that I get:
> > >>>>>main : write-file opened
> > >>>>>main : write-config written
> > >>>>>main : read-file opened
> > >>>>>main : read-config written
> > >>>>>main : write-task created
> > >>>>>main : read-task created
> > >>>>>main : starting write-task
> > >>>>>main : strating read-task
> > >>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
> > >>>>>----------------------------------------------------------
> > >>>>>read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> > >>>>>main : /dev/rtdm/rtser1 (read) -> closed
> > >>>>>read_task: exit
> > >>>>>
> > >>>>>Any ideas why this would happen?
> > >>>>>
> > >>>>>I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> > >>>>Dear Michael,
> > >>>>
> > >>>>I added a patch on December where I extended the IMX UART driver to support
> > >>>>open firmware, maybe my patch can help you to find your issue.
> > >>>>I posted the patch in the mailing list, you can find it here
> > >>>>https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> > >>>>
> > >>>>Kind regards
> > >>>>Wolfgang
> > >>Sorry Michael,
> > >>
> > >>My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> > >I am pretty sure that there is another patch applied previous.
> > >
> > >If you look at your patch you see German comments and open firmware code that
> > >is obviously not in the v2.6.4 on the git repository.
> > >
> > >https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
> > >
> > I posted my patch, because I thought that Wolfgang Grandegger the author of
> > the driver may check it and include it to the xenomai if it is useable for
> > other users.
> >
> 
> Yes but the patch does not apply to the driver in the source tree.
> Please provide the driver that you have after the patch.

Any ideas out there?

Re: [Xenomai] RT serial cross-link failure

[Jan Kiszka]

On 2016-02-22 18:53, Michael Welling wrote:
> On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
>> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
>>>
>>>
>>> Am 2016-02-18 um 08:10 schrieb Michael Welling:
>>>> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
>>>>>
>>>>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
>>>>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
>>>>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
>>>>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
>>>>>>>>
>>>>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
>>>>>>>>
>>>>>>>> When I run the cross-link demo the system hangs after an error in read_task.
>>>>>>>>
>>>>>>>> Here is the output that I get:
>>>>>>>> main : write-file opened
>>>>>>>> main : write-config written
>>>>>>>> main : read-file opened
>>>>>>>> main : read-config written
>>>>>>>> main : write-task created
>>>>>>>> main : read-task created
>>>>>>>> main : starting write-task
>>>>>>>> main : strating read-task
>>>>>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
>>>>>>>> ----------------------------------------------------------
>>>>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
>>>>>>>> main : /dev/rtdm/rtser1 (read) -> closed
>>>>>>>> read_task: exit
>>>>>>>>
>>>>>>>> Any ideas why this would happen?
>>>>>>>>
>>>>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
>>>>>>> Dear Michael,
>>>>>>>
>>>>>>> I added a patch on December where I extended the IMX UART driver to support
>>>>>>> open firmware, maybe my patch can help you to find your issue.
>>>>>>> I posted the patch in the mailing list, you can find it here
>>>>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
>>>>>>>
>>>>>>> Kind regards
>>>>>>> Wolfgang
>>>>> Sorry Michael,
>>>>>
>>>>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
>>>> I am pretty sure that there is another patch applied previous.
>>>>
>>>> If you look at your patch you see German comments and open firmware code that
>>>> is obviously not in the v2.6.4 on the git repository.
>>>>
>>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
>>>>
>>> I posted my patch, because I thought that Wolfgang Grandegger the author of
>>> the driver may check it and include it to the xenomai if it is useable for
>>> other users.
>>>
>>
>> Yes but the patch does not apply to the driver in the source tree.
>> Please provide the driver that you have after the patch.
> 
> Any ideas out there?
> 

Are you now referring to the incomplete patch or your original problem
again?

For the latter case, I would recommend debugging the error code, ie.
what threw this at you. In Xenomai context, -EPERM often means that the
caller is requesting some (potentially) blocking service without being a
real-time task. But, of course, also the driver itself may decide to
raise this for whatever reasons.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] RT serial cross-link failure

[Michael Welling]

On Mon, Feb 22, 2016 at 07:05:44PM +0100, Jan Kiszka wrote:
> On 2016-02-22 18:53, Michael Welling wrote:
> > On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
> >> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
> >>>
> >>>
> >>> Am 2016-02-18 um 08:10 schrieb Michael Welling:
> >>>> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> >>>>>
> >>>>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
> >>>>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> >>>>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> >>>>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> >>>>>>>>
> >>>>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> >>>>>>>>
> >>>>>>>> When I run the cross-link demo the system hangs after an error in read_task.
> >>>>>>>>
> >>>>>>>> Here is the output that I get:
> >>>>>>>> main : write-file opened
> >>>>>>>> main : write-config written
> >>>>>>>> main : read-file opened
> >>>>>>>> main : read-config written
> >>>>>>>> main : write-task created
> >>>>>>>> main : read-task created
> >>>>>>>> main : starting write-task
> >>>>>>>> main : strating read-task
> >>>>>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
> >>>>>>>> ----------------------------------------------------------
> >>>>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> >>>>>>>> main : /dev/rtdm/rtser1 (read) -> closed
> >>>>>>>> read_task: exit
> >>>>>>>>
> >>>>>>>> Any ideas why this would happen?
> >>>>>>>>
> >>>>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> >>>>>>> Dear Michael,
> >>>>>>>
> >>>>>>> I added a patch on December where I extended the IMX UART driver to support
> >>>>>>> open firmware, maybe my patch can help you to find your issue.
> >>>>>>> I posted the patch in the mailing list, you can find it here
> >>>>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> >>>>>>>
> >>>>>>> Kind regards
> >>>>>>> Wolfgang
> >>>>> Sorry Michael,
> >>>>>
> >>>>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> >>>> I am pretty sure that there is another patch applied previous.
> >>>>
> >>>> If you look at your patch you see German comments and open firmware code that
> >>>> is obviously not in the v2.6.4 on the git repository.
> >>>>
> >>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
> >>>>
> >>> I posted my patch, because I thought that Wolfgang Grandegger the author of
> >>> the driver may check it and include it to the xenomai if it is useable for
> >>> other users.
> >>>
> >>
> >> Yes but the patch does not apply to the driver in the source tree.
> >> Please provide the driver that you have after the patch.
> > 
> > Any ideas out there?
> > 
> 
> Are you now referring to the incomplete patch or your original problem
> again?

The original problem is my primary concern. I would not mind having another
version of the driver to test against as well.

> 
> For the latter case, I would recommend debugging the error code, ie.
> what threw this at you. In Xenomai context, -EPERM often means that the
> caller is requesting some (potentially) blocking service without being a
> real-time task. But, of course, also the driver itself may decide to
> raise this for whatever reasons.

Here is the snippet of code from the user app that concerns me:
.
.
        printf(" Nr |   write->irq    |    irq->read    |   write->read   |\n");
        printf("-----------------------------------------------------------\n");

        /*
         * We are in secondary mode now due to printf, the next
         * blocking Xenomai or driver call will switch us back
         * (here: RTSER_RTIOC_WAIT_EVENT).
         */

        while (1) {
                /* waiting for event */
                err = ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
.
.

So is the comment no longer true with Xenomai 3?

Here is the content of the corresponding ioctl in the driver:
.
.
        case RTSER_RTIOC_WAIT_EVENT: {
                struct rtser_event ev = { .rxpend_timestamp = 0 };
                rtdm_toseq_t timeout_seq;

                if (!rtdm_in_rt_context())
                        return -ENOSYS;

                /* Only one waiter allowed, stop any further attempts here. */
                if (test_and_set_bit(0, &ctx->ioc_event_lock))
                        return -EBUSY;

                rtdm_toseq_init(&timeout_seq, ctx->config.event_timeout);

                rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);

                while (!ctx->ioc_events) {
                        /* Only enable error interrupt
                           when the user waits for it. */
                        if (ctx->config.event_mask & RTSER_EVENT_ERRPEND) {
                                ctx->ier_status |= IER_STAT;
#ifdef FIXME
                                rt_imx_uart_reg_out(mode, base, IER,
                                                 ctx->ier_status);
#endif
                        }

                        rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);

                        err = rtdm_event_timedwait(&ctx->ioc_event,
                                                   ctx->config.event_timeout,
                                                   &timeout_seq);
                        if (err) {
                                /* Device has been closed? */
                                if (err == -EIDRM)
                                        err = -EBADF;
                                goto wait_unlock_out;
                        }

                        rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
                }

                ev.events = ctx->ioc_events;
                ctx->ioc_events &=
                    ~(RTSER_EVENT_MODEMHI | RTSER_EVENT_MODEMLO);

                ev.last_timestamp = ctx->last_timestamp;
                ev.rx_pending = ctx->in_npend;

                if (ctx->in_history)
                        ev.rxpend_timestamp = ctx->in_history[ctx->in_head];

                rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);

                if (rtdm_fd_is_user(fd))
                        err =
                            rtdm_safe_copy_to_user(fd, arg, &ev,
                                                   sizeof(struct
                                                          rtser_event));
                        else
                                memcpy(arg, &ev, sizeof(struct rtser_event));

wait_unlock_out:
                /* release the simple event waiter lock */
                clear_bit(0, &ctx->ioc_event_lock);
                break;
        }
.
.

So either rtdm_event_timedwait or rtdm_safe_copy_to_user is returing -EPERM.
Looking at the documentation rtdm_safe_copy_to_user does not appear to return -EPERM.

Looking at the documentation rtdm_event_timedwait:
-EPERM may be returned if an illegal invocation environment is detected.

So are we stuck in secondary mode?
Ideas?
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT RDA ITP SES-DE
> Corporate Competence Center Embedded Linux

Re: [Xenomai] RT serial cross-link failure

[Jan Kiszka]

On 2016-02-22 20:04, Michael Welling wrote:
> On Mon, Feb 22, 2016 at 07:05:44PM +0100, Jan Kiszka wrote:
>> On 2016-02-22 18:53, Michael Welling wrote:
>>> On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
>>>> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
>>>>>
>>>>>
>>>>> Am 2016-02-18 um 08:10 schrieb Michael Welling:
>>>>>> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
>>>>>>>
>>>>>>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
>>>>>>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
>>>>>>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
>>>>>>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
>>>>>>>>>>
>>>>>>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
>>>>>>>>>>
>>>>>>>>>> When I run the cross-link demo the system hangs after an error in read_task.
>>>>>>>>>>
>>>>>>>>>> Here is the output that I get:
>>>>>>>>>> main : write-file opened
>>>>>>>>>> main : write-config written
>>>>>>>>>> main : read-file opened
>>>>>>>>>> main : read-config written
>>>>>>>>>> main : write-task created
>>>>>>>>>> main : read-task created
>>>>>>>>>> main : starting write-task
>>>>>>>>>> main : strating read-task
>>>>>>>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
>>>>>>>>>> ----------------------------------------------------------
>>>>>>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
>>>>>>>>>> main : /dev/rtdm/rtser1 (read) -> closed
>>>>>>>>>> read_task: exit
>>>>>>>>>>
>>>>>>>>>> Any ideas why this would happen?
>>>>>>>>>>
>>>>>>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
>>>>>>>>> Dear Michael,
>>>>>>>>>
>>>>>>>>> I added a patch on December where I extended the IMX UART driver to support
>>>>>>>>> open firmware, maybe my patch can help you to find your issue.
>>>>>>>>> I posted the patch in the mailing list, you can find it here
>>>>>>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
>>>>>>>>>
>>>>>>>>> Kind regards
>>>>>>>>> Wolfgang
>>>>>>> Sorry Michael,
>>>>>>>
>>>>>>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
>>>>>> I am pretty sure that there is another patch applied previous.
>>>>>>
>>>>>> If you look at your patch you see German comments and open firmware code that
>>>>>> is obviously not in the v2.6.4 on the git repository.
>>>>>>
>>>>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
>>>>>>
>>>>> I posted my patch, because I thought that Wolfgang Grandegger the author of
>>>>> the driver may check it and include it to the xenomai if it is useable for
>>>>> other users.
>>>>>
>>>>
>>>> Yes but the patch does not apply to the driver in the source tree.
>>>> Please provide the driver that you have after the patch.
>>>
>>> Any ideas out there?
>>>
>>
>> Are you now referring to the incomplete patch or your original problem
>> again?
> 
> The original problem is my primary concern. I would not mind having another
> version of the driver to test against as well.
> 
>>
>> For the latter case, I would recommend debugging the error code, ie.
>> what threw this at you. In Xenomai context, -EPERM often means that the
>> caller is requesting some (potentially) blocking service without being a
>> real-time task. But, of course, also the driver itself may decide to
>> raise this for whatever reasons.
> 
> Here is the snippet of code from the user app that concerns me:
> .
> .
>         printf(" Nr |   write->irq    |    irq->read    |   write->read   |\n");
>         printf("-----------------------------------------------------------\n");
> 
>         /*
>          * We are in secondary mode now due to printf, the next
>          * blocking Xenomai or driver call will switch us back
>          * (here: RTSER_RTIOC_WAIT_EVENT).
>          */
> 
>         while (1) {
>                 /* waiting for event */
>                 err = ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
> .
> .
> 
> So is the comment no longer true with Xenomai 3?

No, that would be a bug.

> 
> Here is the content of the corresponding ioctl in the driver:
> .
> .
>         case RTSER_RTIOC_WAIT_EVENT: {
>                 struct rtser_event ev = { .rxpend_timestamp = 0 };
>                 rtdm_toseq_t timeout_seq;
> 
>                 if (!rtdm_in_rt_context())
>                         return -ENOSYS;
> 
>                 /* Only one waiter allowed, stop any further attempts here. */
>                 if (test_and_set_bit(0, &ctx->ioc_event_lock))
>                         return -EBUSY;
> 
>                 rtdm_toseq_init(&timeout_seq, ctx->config.event_timeout);
> 
>                 rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
> 
>                 while (!ctx->ioc_events) {
>                         /* Only enable error interrupt
>                            when the user waits for it. */
>                         if (ctx->config.event_mask & RTSER_EVENT_ERRPEND) {
>                                 ctx->ier_status |= IER_STAT;
> #ifdef FIXME
>                                 rt_imx_uart_reg_out(mode, base, IER,
>                                                  ctx->ier_status);
> #endif
>                         }
> 
>                         rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> 
>                         err = rtdm_event_timedwait(&ctx->ioc_event,
>                                                    ctx->config.event_timeout,
>                                                    &timeout_seq);
>                         if (err) {
>                                 /* Device has been closed? */
>                                 if (err == -EIDRM)
>                                         err = -EBADF;
>                                 goto wait_unlock_out;
>                         }
> 
>                         rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
>                 }
> 
>                 ev.events = ctx->ioc_events;
>                 ctx->ioc_events &=
>                     ~(RTSER_EVENT_MODEMHI | RTSER_EVENT_MODEMLO);
> 
>                 ev.last_timestamp = ctx->last_timestamp;
>                 ev.rx_pending = ctx->in_npend;
> 
>                 if (ctx->in_history)
>                         ev.rxpend_timestamp = ctx->in_history[ctx->in_head];
> 
>                 rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> 
>                 if (rtdm_fd_is_user(fd))
>                         err =
>                             rtdm_safe_copy_to_user(fd, arg, &ev,
>                                                    sizeof(struct
>                                                           rtser_event));
>                         else
>                                 memcpy(arg, &ev, sizeof(struct rtser_event));
> 
> wait_unlock_out:
>                 /* release the simple event waiter lock */
>                 clear_bit(0, &ctx->ioc_event_lock);
>                 break;
>         }
> .
> .
> 
> So either rtdm_event_timedwait or rtdm_safe_copy_to_user is returing -EPERM.

Or things terminate earlier / later in the ioctl dispatching path.

> Looking at the documentation rtdm_safe_copy_to_user does not appear to return -EPERM.
> 
> Looking at the documentation rtdm_event_timedwait:
> -EPERM may be returned if an illegal invocation environment is detected.
> 
> So are we stuck in secondary mode?

Probably.

> Ideas?

You will not get around debugging more information out of your setup.
Use tracing, use well-placed printk.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] RT serial cross-link failure

[Gilles Chanteperdrix]

On Mon, Feb 22, 2016 at 08:16:20PM +0100, Jan Kiszka wrote:
> On 2016-02-22 20:04, Michael Welling wrote:
> > On Mon, Feb 22, 2016 at 07:05:44PM +0100, Jan Kiszka wrote:
> >> On 2016-02-22 18:53, Michael Welling wrote:
> >>> On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
> >>>> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
> >>>>>
> >>>>>
> >>>>> Am 2016-02-18 um 08:10 schrieb Michael Welling:
> >>>>>> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> >>>>>>>
> >>>>>>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
> >>>>>>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> >>>>>>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> >>>>>>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> >>>>>>>>>>
> >>>>>>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> >>>>>>>>>>
> >>>>>>>>>> When I run the cross-link demo the system hangs after an error in read_task.
> >>>>>>>>>>
> >>>>>>>>>> Here is the output that I get:
> >>>>>>>>>> main : write-file opened
> >>>>>>>>>> main : write-config written
> >>>>>>>>>> main : read-file opened
> >>>>>>>>>> main : read-config written
> >>>>>>>>>> main : write-task created
> >>>>>>>>>> main : read-task created
> >>>>>>>>>> main : starting write-task
> >>>>>>>>>> main : strating read-task
> >>>>>>>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
> >>>>>>>>>> ----------------------------------------------------------
> >>>>>>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> >>>>>>>>>> main : /dev/rtdm/rtser1 (read) -> closed
> >>>>>>>>>> read_task: exit
> >>>>>>>>>>
> >>>>>>>>>> Any ideas why this would happen?
> >>>>>>>>>>
> >>>>>>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> >>>>>>>>> Dear Michael,
> >>>>>>>>>
> >>>>>>>>> I added a patch on December where I extended the IMX UART driver to support
> >>>>>>>>> open firmware, maybe my patch can help you to find your issue.
> >>>>>>>>> I posted the patch in the mailing list, you can find it here
> >>>>>>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> >>>>>>>>>
> >>>>>>>>> Kind regards
> >>>>>>>>> Wolfgang
> >>>>>>> Sorry Michael,
> >>>>>>>
> >>>>>>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> >>>>>> I am pretty sure that there is another patch applied previous.
> >>>>>>
> >>>>>> If you look at your patch you see German comments and open firmware code that
> >>>>>> is obviously not in the v2.6.4 on the git repository.
> >>>>>>
> >>>>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
> >>>>>>
> >>>>> I posted my patch, because I thought that Wolfgang Grandegger the author of
> >>>>> the driver may check it and include it to the xenomai if it is useable for
> >>>>> other users.
> >>>>>
> >>>>
> >>>> Yes but the patch does not apply to the driver in the source tree.
> >>>> Please provide the driver that you have after the patch.
> >>>
> >>> Any ideas out there?
> >>>
> >>
> >> Are you now referring to the incomplete patch or your original problem
> >> again?
> > 
> > The original problem is my primary concern. I would not mind having another
> > version of the driver to test against as well.
> > 
> >>
> >> For the latter case, I would recommend debugging the error code, ie.
> >> what threw this at you. In Xenomai context, -EPERM often means that the
> >> caller is requesting some (potentially) blocking service without being a
> >> real-time task. But, of course, also the driver itself may decide to
> >> raise this for whatever reasons.
> > 
> > Here is the snippet of code from the user app that concerns me:
> > .
> > .
> >         printf(" Nr |   write->irq    |    irq->read    |   write->read   |\n");
> >         printf("-----------------------------------------------------------\n");
> > 
> >         /*
> >          * We are in secondary mode now due to printf, the next
> >          * blocking Xenomai or driver call will switch us back
> >          * (here: RTSER_RTIOC_WAIT_EVENT).
> >          */
> > 
> >         while (1) {
> >                 /* waiting for event */
> >                 err = ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
> > .
> > .
> > 
> > So is the comment no longer true with Xenomai 3?
> 
> No, that would be a bug.

The part of the comment which says that printf causes a switch to
secondary mode has been wrong for some time now. printf is wrapped
and stays in primary mode.

Can not the problem be that the thread is not auto-shadowed?

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] RT serial cross-link failure

[Michael Welling]

On Mon, Feb 22, 2016 at 08:22:08PM +0100, Gilles Chanteperdrix wrote:
> On Mon, Feb 22, 2016 at 08:16:20PM +0100, Jan Kiszka wrote:
> > On 2016-02-22 20:04, Michael Welling wrote:
> > > On Mon, Feb 22, 2016 at 07:05:44PM +0100, Jan Kiszka wrote:
> > >> On 2016-02-22 18:53, Michael Welling wrote:
> > >>> On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
> > >>>> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
> > >>>>>
> > >>>>>
> > >>>>> Am 2016-02-18 um 08:10 schrieb Michael Welling:
> > >>>>>> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> > >>>>>>>
> > >>>>>>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
> > >>>>>>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> > >>>>>>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> > >>>>>>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> > >>>>>>>>>>
> > >>>>>>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> > >>>>>>>>>>
> > >>>>>>>>>> When I run the cross-link demo the system hangs after an error in read_task.
> > >>>>>>>>>>
> > >>>>>>>>>> Here is the output that I get:
> > >>>>>>>>>> main : write-file opened
> > >>>>>>>>>> main : write-config written
> > >>>>>>>>>> main : read-file opened
> > >>>>>>>>>> main : read-config written
> > >>>>>>>>>> main : write-task created
> > >>>>>>>>>> main : read-task created
> > >>>>>>>>>> main : starting write-task
> > >>>>>>>>>> main : strating read-task
> > >>>>>>>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
> > >>>>>>>>>> ----------------------------------------------------------
> > >>>>>>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> > >>>>>>>>>> main : /dev/rtdm/rtser1 (read) -> closed
> > >>>>>>>>>> read_task: exit
> > >>>>>>>>>>
> > >>>>>>>>>> Any ideas why this would happen?
> > >>>>>>>>>>
> > >>>>>>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> > >>>>>>>>> Dear Michael,
> > >>>>>>>>>
> > >>>>>>>>> I added a patch on December where I extended the IMX UART driver to support
> > >>>>>>>>> open firmware, maybe my patch can help you to find your issue.
> > >>>>>>>>> I posted the patch in the mailing list, you can find it here
> > >>>>>>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> > >>>>>>>>>
> > >>>>>>>>> Kind regards
> > >>>>>>>>> Wolfgang
> > >>>>>>> Sorry Michael,
> > >>>>>>>
> > >>>>>>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> > >>>>>> I am pretty sure that there is another patch applied previous.
> > >>>>>>
> > >>>>>> If you look at your patch you see German comments and open firmware code that
> > >>>>>> is obviously not in the v2.6.4 on the git repository.
> > >>>>>>
> > >>>>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
> > >>>>>>
> > >>>>> I posted my patch, because I thought that Wolfgang Grandegger the author of
> > >>>>> the driver may check it and include it to the xenomai if it is useable for
> > >>>>> other users.
> > >>>>>
> > >>>>
> > >>>> Yes but the patch does not apply to the driver in the source tree.
> > >>>> Please provide the driver that you have after the patch.
> > >>>
> > >>> Any ideas out there?
> > >>>
> > >>
> > >> Are you now referring to the incomplete patch or your original problem
> > >> again?
> > > 
> > > The original problem is my primary concern. I would not mind having another
> > > version of the driver to test against as well.
> > > 
> > >>
> > >> For the latter case, I would recommend debugging the error code, ie.
> > >> what threw this at you. In Xenomai context, -EPERM often means that the
> > >> caller is requesting some (potentially) blocking service without being a
> > >> real-time task. But, of course, also the driver itself may decide to
> > >> raise this for whatever reasons.
> > > 
> > > Here is the snippet of code from the user app that concerns me:
> > > .
> > > .
> > >         printf(" Nr |   write->irq    |    irq->read    |   write->read   |\n");
> > >         printf("-----------------------------------------------------------\n");
> > > 
> > >         /*
> > >          * We are in secondary mode now due to printf, the next
> > >          * blocking Xenomai or driver call will switch us back
> > >          * (here: RTSER_RTIOC_WAIT_EVENT).
> > >          */
> > > 
> > >         while (1) {
> > >                 /* waiting for event */
> > >                 err = ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
> > > .
> > > .
> > > 
> > > So is the comment no longer true with Xenomai 3?
> > 
> > No, that would be a bug.
> 
> The part of the comment which says that printf causes a switch to
> secondary mode has been wrong for some time now. printf is wrapped
> and stays in primary mode.
> 
> Can not the problem be that the thread is not auto-shadowed?

How would I go about determining if this is the case?

> 
> -- 
> 					    Gilles.
> https://click-hack.org

Re: [Xenomai] RT serial cross-link failure

[Gilles Chanteperdrix]

On Mon, Feb 22, 2016 at 01:46:18PM -0600, Michael Welling wrote:
> On Mon, Feb 22, 2016 at 08:22:08PM +0100, Gilles Chanteperdrix wrote:
> > On Mon, Feb 22, 2016 at 08:16:20PM +0100, Jan Kiszka wrote:
> > > On 2016-02-22 20:04, Michael Welling wrote:
> > > > On Mon, Feb 22, 2016 at 07:05:44PM +0100, Jan Kiszka wrote:
> > > >> On 2016-02-22 18:53, Michael Welling wrote:
> > > >>> On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
> > > >>>> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>> Am 2016-02-18 um 08:10 schrieb Michael Welling:
> > > >>>>>> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> > > >>>>>>>
> > > >>>>>>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
> > > >>>>>>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> > > >>>>>>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> > > >>>>>>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> > > >>>>>>>>>>
> > > >>>>>>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> > > >>>>>>>>>>
> > > >>>>>>>>>> When I run the cross-link demo the system hangs after an error in read_task.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Here is the output that I get:
> > > >>>>>>>>>> main : write-file opened
> > > >>>>>>>>>> main : write-config written
> > > >>>>>>>>>> main : read-file opened
> > > >>>>>>>>>> main : read-config written
> > > >>>>>>>>>> main : write-task created
> > > >>>>>>>>>> main : read-task created
> > > >>>>>>>>>> main : starting write-task
> > > >>>>>>>>>> main : strating read-task
> > > >>>>>>>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
> > > >>>>>>>>>> ----------------------------------------------------------
> > > >>>>>>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> > > >>>>>>>>>> main : /dev/rtdm/rtser1 (read) -> closed
> > > >>>>>>>>>> read_task: exit
> > > >>>>>>>>>>
> > > >>>>>>>>>> Any ideas why this would happen?
> > > >>>>>>>>>>
> > > >>>>>>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> > > >>>>>>>>> Dear Michael,
> > > >>>>>>>>>
> > > >>>>>>>>> I added a patch on December where I extended the IMX UART driver to support
> > > >>>>>>>>> open firmware, maybe my patch can help you to find your issue.
> > > >>>>>>>>> I posted the patch in the mailing list, you can find it here
> > > >>>>>>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> > > >>>>>>>>>
> > > >>>>>>>>> Kind regards
> > > >>>>>>>>> Wolfgang
> > > >>>>>>> Sorry Michael,
> > > >>>>>>>
> > > >>>>>>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> > > >>>>>> I am pretty sure that there is another patch applied previous.
> > > >>>>>>
> > > >>>>>> If you look at your patch you see German comments and open firmware code that
> > > >>>>>> is obviously not in the v2.6.4 on the git repository.
> > > >>>>>>
> > > >>>>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
> > > >>>>>>
> > > >>>>> I posted my patch, because I thought that Wolfgang Grandegger the author of
> > > >>>>> the driver may check it and include it to the xenomai if it is useable for
> > > >>>>> other users.
> > > >>>>>
> > > >>>>
> > > >>>> Yes but the patch does not apply to the driver in the source tree.
> > > >>>> Please provide the driver that you have after the patch.
> > > >>>
> > > >>> Any ideas out there?
> > > >>>
> > > >>
> > > >> Are you now referring to the incomplete patch or your original problem
> > > >> again?
> > > > 
> > > > The original problem is my primary concern. I would not mind having another
> > > > version of the driver to test against as well.
> > > > 
> > > >>
> > > >> For the latter case, I would recommend debugging the error code, ie.
> > > >> what threw this at you. In Xenomai context, -EPERM often means that the
> > > >> caller is requesting some (potentially) blocking service without being a
> > > >> real-time task. But, of course, also the driver itself may decide to
> > > >> raise this for whatever reasons.
> > > > 
> > > > Here is the snippet of code from the user app that concerns me:
> > > > .
> > > > .
> > > >         printf(" Nr |   write->irq    |    irq->read    |   write->read   |\n");
> > > >         printf("-----------------------------------------------------------\n");
> > > > 
> > > >         /*
> > > >          * We are in secondary mode now due to printf, the next
> > > >          * blocking Xenomai or driver call will switch us back
> > > >          * (here: RTSER_RTIOC_WAIT_EVENT).
> > > >          */
> > > > 
> > > >         while (1) {
> > > >                 /* waiting for event */
> > > >                 err = ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
> > > > .
> > > > .
> > > > 
> > > > So is the comment no longer true with Xenomai 3?
> > > 
> > > No, that would be a bug.
> > 
> > The part of the comment which says that printf causes a switch to
> > secondary mode has been wrong for some time now. printf is wrapped
> > and stays in primary mode.
> > 
> > Can not the problem be that the thread is not auto-shadowed?
> 
> How would I go about determining if this is the case?

Load the program in gdb, put a breakpoint on __wrap_ioctl, run the
program. When it stops, in another terminal see if your program
appears in /proc/xenomai/sched or /proc/xenomai/stat.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] RT serial cross-link failure

[Michael Welling]

On Mon, Feb 22, 2016 at 08:16:20PM +0100, Jan Kiszka wrote:
> On 2016-02-22 20:04, Michael Welling wrote:
> > On Mon, Feb 22, 2016 at 07:05:44PM +0100, Jan Kiszka wrote:
> >> On 2016-02-22 18:53, Michael Welling wrote:
> >>> On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
> >>>> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
> >>>>>
> >>>>>
> >>>>> Am 2016-02-18 um 08:10 schrieb Michael Welling:
> >>>>>> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> >>>>>>>
> >>>>>>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
> >>>>>>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> >>>>>>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> >>>>>>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> >>>>>>>>>>
> >>>>>>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> >>>>>>>>>>
> >>>>>>>>>> When I run the cross-link demo the system hangs after an error in read_task.
> >>>>>>>>>>
> >>>>>>>>>> Here is the output that I get:
> >>>>>>>>>> main : write-file opened
> >>>>>>>>>> main : write-config written
> >>>>>>>>>> main : read-file opened
> >>>>>>>>>> main : read-config written
> >>>>>>>>>> main : write-task created
> >>>>>>>>>> main : read-task created
> >>>>>>>>>> main : starting write-task
> >>>>>>>>>> main : strating read-task
> >>>>>>>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
> >>>>>>>>>> ----------------------------------------------------------
> >>>>>>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> >>>>>>>>>> main : /dev/rtdm/rtser1 (read) -> closed
> >>>>>>>>>> read_task: exit
> >>>>>>>>>>
> >>>>>>>>>> Any ideas why this would happen?
> >>>>>>>>>>
> >>>>>>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> >>>>>>>>> Dear Michael,
> >>>>>>>>>
> >>>>>>>>> I added a patch on December where I extended the IMX UART driver to support
> >>>>>>>>> open firmware, maybe my patch can help you to find your issue.
> >>>>>>>>> I posted the patch in the mailing list, you can find it here
> >>>>>>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> >>>>>>>>>
> >>>>>>>>> Kind regards
> >>>>>>>>> Wolfgang
> >>>>>>> Sorry Michael,
> >>>>>>>
> >>>>>>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> >>>>>> I am pretty sure that there is another patch applied previous.
> >>>>>>
> >>>>>> If you look at your patch you see German comments and open firmware code that
> >>>>>> is obviously not in the v2.6.4 on the git repository.
> >>>>>>
> >>>>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
> >>>>>>
> >>>>> I posted my patch, because I thought that Wolfgang Grandegger the author of
> >>>>> the driver may check it and include it to the xenomai if it is useable for
> >>>>> other users.
> >>>>>
> >>>>
> >>>> Yes but the patch does not apply to the driver in the source tree.
> >>>> Please provide the driver that you have after the patch.
> >>>
> >>> Any ideas out there?
> >>>
> >>
> >> Are you now referring to the incomplete patch or your original problem
> >> again?
> > 
> > The original problem is my primary concern. I would not mind having another
> > version of the driver to test against as well.
> > 
> >>
> >> For the latter case, I would recommend debugging the error code, ie.
> >> what threw this at you. In Xenomai context, -EPERM often means that the
> >> caller is requesting some (potentially) blocking service without being a
> >> real-time task. But, of course, also the driver itself may decide to
> >> raise this for whatever reasons.
> > 
> > Here is the snippet of code from the user app that concerns me:
> > .
> > .
> >         printf(" Nr |   write->irq    |    irq->read    |   write->read   |\n");
> >         printf("-----------------------------------------------------------\n");
> > 
> >         /*
> >          * We are in secondary mode now due to printf, the next
> >          * blocking Xenomai or driver call will switch us back
> >          * (here: RTSER_RTIOC_WAIT_EVENT).
> >          */
> > 
> >         while (1) {
> >                 /* waiting for event */
> >                 err = ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
> > .
> > .
> > 
> > So is the comment no longer true with Xenomai 3?
> 
> No, that would be a bug.
> 
> > 
> > Here is the content of the corresponding ioctl in the driver:
> > .
> > .
> >         case RTSER_RTIOC_WAIT_EVENT: {
> >                 struct rtser_event ev = { .rxpend_timestamp = 0 };
> >                 rtdm_toseq_t timeout_seq;
> > 
> >                 if (!rtdm_in_rt_context())
> >                         return -ENOSYS;
> > 
> >                 /* Only one waiter allowed, stop any further attempts here. */
> >                 if (test_and_set_bit(0, &ctx->ioc_event_lock))
> >                         return -EBUSY;
> > 
> >                 rtdm_toseq_init(&timeout_seq, ctx->config.event_timeout);
> > 
> >                 rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
> > 
> >                 while (!ctx->ioc_events) {
> >                         /* Only enable error interrupt
> >                            when the user waits for it. */
> >                         if (ctx->config.event_mask & RTSER_EVENT_ERRPEND) {
> >                                 ctx->ier_status |= IER_STAT;
> > #ifdef FIXME
> >                                 rt_imx_uart_reg_out(mode, base, IER,
> >                                                  ctx->ier_status);
> > #endif
> >                         }
> > 
> >                         rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> > 
> >                         err = rtdm_event_timedwait(&ctx->ioc_event,
> >                                                    ctx->config.event_timeout,
> >                                                    &timeout_seq);
> >                         if (err) {
> >                                 /* Device has been closed? */
> >                                 if (err == -EIDRM)
> >                                         err = -EBADF;
> >                                 goto wait_unlock_out;
> >                         }
> > 
> >                         rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
> >                 }
> > 
> >                 ev.events = ctx->ioc_events;
> >                 ctx->ioc_events &=
> >                     ~(RTSER_EVENT_MODEMHI | RTSER_EVENT_MODEMLO);
> > 
> >                 ev.last_timestamp = ctx->last_timestamp;
> >                 ev.rx_pending = ctx->in_npend;
> > 
> >                 if (ctx->in_history)
> >                         ev.rxpend_timestamp = ctx->in_history[ctx->in_head];
> > 
> >                 rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> > 
> >                 if (rtdm_fd_is_user(fd))
> >                         err =
> >                             rtdm_safe_copy_to_user(fd, arg, &ev,
> >                                                    sizeof(struct
> >                                                           rtser_event));
> >                         else
> >                                 memcpy(arg, &ev, sizeof(struct rtser_event));
> > 
> > wait_unlock_out:
> >                 /* release the simple event waiter lock */
> >                 clear_bit(0, &ctx->ioc_event_lock);
> >                 break;
> >         }
> > .
> > .
> > 
> > So either rtdm_event_timedwait or rtdm_safe_copy_to_user is returing -EPERM.
> 
> Or things terminate earlier / later in the ioctl dispatching path.
> 
> > Looking at the documentation rtdm_safe_copy_to_user does not appear to return -EPERM.
> > 
> > Looking at the documentation rtdm_event_timedwait:
> > -EPERM may be returned if an illegal invocation environment is detected.
> > 
> > So are we stuck in secondary mode?
> 
> Probably.
> 
> > Ideas?
> 
> You will not get around debugging more information out of your setup.
> Use tracing, use well-placed printk.

So I put a pr_err where I expected the driver was failing:

			rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);

			err = rtdm_event_timedwait(&ctx->ioc_event,
				ctx->config.event_timeout,
				&timeout_seq);
			if (err) {
+				pr_err("Just as I expected rtdm_event_timedwait failed %d\n", err);
				/* Device has been closed? */
				if (err == -EIDRM)
					err = -EBADF;
				goto wait_unlock_out;
			}

Then I found something unexpected:
 Nr |   write->irq    |    irq->read    |   write->read   |
-----------------------------------------------------------
[ 1600.173441] Just as I expected rtdm_event_timedwait failed -110
read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation not permitted
main : /dev/rtdm/rtser1 (read) -> closed

-110 is -ETIMEDOUT not -EPERM.

So then I figured hey that would make sense if the cable is not looped
back. So I made sure I had the NULL modem loop correctly going to the
two ports in question.

root@somimx6:/sys/bus/platform/drivers/imx-uart# /usr/xenomai/demo/cross-link 
main : write-file opened
main : write-config written
main : read-file opened
main : read-config written
main : write-task created
main : read-task created
main : starting write-task
main : starting read-task
 Nr |   write->irq    |    irq->read    |   write->read   |
-----------------------------------------------------------
  0 |18446744046287090290 |     27423201660 |          740334
  1 |18446744046287079290 |     27423200326 |          728000
  2 |18446744046287078623 |     27423200993 |          728000
  3 |18446744046287080623 |     27423199659 |          728666
  4 |18446744046287078623 |     27423201326 |          728333
  5 |18446744046287079622 |     27423200994 |          729000
  6 |18446744046287078289 |     27423200660 |          727333
  7 |18446744046287077956 |     27423201326 |          727666
  8 |18446744046287079956 |     27423201327 |          729667
  9 |18446744046287080623 |     27423199660 |          728667
 10 |18446744046287078623 |     27423199660 |          726667
 11 |18446744046287078956 |     27423203994 |          731334
 12 |18446744046287078956 |     27423200326 |          727666
 13 |18446744046287078623 |     27423202327 |          729334
 14 |18446744046287078290 |     27423200659 |          727333
 15 |18446744046287078623 |     27423200993 |          728000
 16 |18446744046287079290 |     27423201326 |          729000
 17 |18446744046287081290 |     27423199659 |          729333
 18 |18446744046287077957 |     27423200993 |          727334
.
.
.

Why in the world would -ETIMEDOUT come out as Operation not permitted?

Either way it is working and I am happy.

> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT RDA ITP SES-DE
> Corporate Competence Center Embedded Linux

Re: [Xenomai] RT serial cross-link failure

[Gilles Chanteperdrix]

On Mon, Feb 22, 2016 at 02:51:39PM -0600, Michael Welling wrote:
> On Mon, Feb 22, 2016 at 08:16:20PM +0100, Jan Kiszka wrote:
> > On 2016-02-22 20:04, Michael Welling wrote:
> > > On Mon, Feb 22, 2016 at 07:05:44PM +0100, Jan Kiszka wrote:
> > >> On 2016-02-22 18:53, Michael Welling wrote:
> > >>> On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
> > >>>> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
> > >>>>>
> > >>>>>
> > >>>>> Am 2016-02-18 um 08:10 schrieb Michael Welling:
> > >>>>>> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> > >>>>>>>
> > >>>>>>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
> > >>>>>>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> > >>>>>>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> > >>>>>>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> > >>>>>>>>>>
> > >>>>>>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> > >>>>>>>>>>
> > >>>>>>>>>> When I run the cross-link demo the system hangs after an error in read_task.
> > >>>>>>>>>>
> > >>>>>>>>>> Here is the output that I get:
> > >>>>>>>>>> main : write-file opened
> > >>>>>>>>>> main : write-config written
> > >>>>>>>>>> main : read-file opened
> > >>>>>>>>>> main : read-config written
> > >>>>>>>>>> main : write-task created
> > >>>>>>>>>> main : read-task created
> > >>>>>>>>>> main : starting write-task
> > >>>>>>>>>> main : strating read-task
> > >>>>>>>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
> > >>>>>>>>>> ----------------------------------------------------------
> > >>>>>>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> > >>>>>>>>>> main : /dev/rtdm/rtser1 (read) -> closed
> > >>>>>>>>>> read_task: exit
> > >>>>>>>>>>
> > >>>>>>>>>> Any ideas why this would happen?
> > >>>>>>>>>>
> > >>>>>>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> > >>>>>>>>> Dear Michael,
> > >>>>>>>>>
> > >>>>>>>>> I added a patch on December where I extended the IMX UART driver to support
> > >>>>>>>>> open firmware, maybe my patch can help you to find your issue.
> > >>>>>>>>> I posted the patch in the mailing list, you can find it here
> > >>>>>>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> > >>>>>>>>>
> > >>>>>>>>> Kind regards
> > >>>>>>>>> Wolfgang
> > >>>>>>> Sorry Michael,
> > >>>>>>>
> > >>>>>>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> > >>>>>> I am pretty sure that there is another patch applied previous.
> > >>>>>>
> > >>>>>> If you look at your patch you see German comments and open firmware code that
> > >>>>>> is obviously not in the v2.6.4 on the git repository.
> > >>>>>>
> > >>>>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
> > >>>>>>
> > >>>>> I posted my patch, because I thought that Wolfgang Grandegger the author of
> > >>>>> the driver may check it and include it to the xenomai if it is useable for
> > >>>>> other users.
> > >>>>>
> > >>>>
> > >>>> Yes but the patch does not apply to the driver in the source tree.
> > >>>> Please provide the driver that you have after the patch.
> > >>>
> > >>> Any ideas out there?
> > >>>
> > >>
> > >> Are you now referring to the incomplete patch or your original problem
> > >> again?
> > > 
> > > The original problem is my primary concern. I would not mind having another
> > > version of the driver to test against as well.
> > > 
> > >>
> > >> For the latter case, I would recommend debugging the error code, ie.
> > >> what threw this at you. In Xenomai context, -EPERM often means that the
> > >> caller is requesting some (potentially) blocking service without being a
> > >> real-time task. But, of course, also the driver itself may decide to
> > >> raise this for whatever reasons.
> > > 
> > > Here is the snippet of code from the user app that concerns me:
> > > .
> > > .
> > >         printf(" Nr |   write->irq    |    irq->read    |   write->read   |\n");
> > >         printf("-----------------------------------------------------------\n");
> > > 
> > >         /*
> > >          * We are in secondary mode now due to printf, the next
> > >          * blocking Xenomai or driver call will switch us back
> > >          * (here: RTSER_RTIOC_WAIT_EVENT).
> > >          */
> > > 
> > >         while (1) {
> > >                 /* waiting for event */
> > >                 err = ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
> > > .
> > > .
> > > 
> > > So is the comment no longer true with Xenomai 3?
> > 
> > No, that would be a bug.
> > 
> > > 
> > > Here is the content of the corresponding ioctl in the driver:
> > > .
> > > .
> > >         case RTSER_RTIOC_WAIT_EVENT: {
> > >                 struct rtser_event ev = { .rxpend_timestamp = 0 };
> > >                 rtdm_toseq_t timeout_seq;
> > > 
> > >                 if (!rtdm_in_rt_context())
> > >                         return -ENOSYS;
> > > 
> > >                 /* Only one waiter allowed, stop any further attempts here. */
> > >                 if (test_and_set_bit(0, &ctx->ioc_event_lock))
> > >                         return -EBUSY;
> > > 
> > >                 rtdm_toseq_init(&timeout_seq, ctx->config.event_timeout);
> > > 
> > >                 rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
> > > 
> > >                 while (!ctx->ioc_events) {
> > >                         /* Only enable error interrupt
> > >                            when the user waits for it. */
> > >                         if (ctx->config.event_mask & RTSER_EVENT_ERRPEND) {
> > >                                 ctx->ier_status |= IER_STAT;
> > > #ifdef FIXME
> > >                                 rt_imx_uart_reg_out(mode, base, IER,
> > >                                                  ctx->ier_status);
> > > #endif
> > >                         }
> > > 
> > >                         rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> > > 
> > >                         err = rtdm_event_timedwait(&ctx->ioc_event,
> > >                                                    ctx->config.event_timeout,
> > >                                                    &timeout_seq);
> > >                         if (err) {
> > >                                 /* Device has been closed? */
> > >                                 if (err == -EIDRM)
> > >                                         err = -EBADF;
> > >                                 goto wait_unlock_out;
> > >                         }
> > > 
> > >                         rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
> > >                 }
> > > 
> > >                 ev.events = ctx->ioc_events;
> > >                 ctx->ioc_events &=
> > >                     ~(RTSER_EVENT_MODEMHI | RTSER_EVENT_MODEMLO);
> > > 
> > >                 ev.last_timestamp = ctx->last_timestamp;
> > >                 ev.rx_pending = ctx->in_npend;
> > > 
> > >                 if (ctx->in_history)
> > >                         ev.rxpend_timestamp = ctx->in_history[ctx->in_head];
> > > 
> > >                 rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> > > 
> > >                 if (rtdm_fd_is_user(fd))
> > >                         err =
> > >                             rtdm_safe_copy_to_user(fd, arg, &ev,
> > >                                                    sizeof(struct
> > >                                                           rtser_event));
> > >                         else
> > >                                 memcpy(arg, &ev, sizeof(struct rtser_event));
> > > 
> > > wait_unlock_out:
> > >                 /* release the simple event waiter lock */
> > >                 clear_bit(0, &ctx->ioc_event_lock);
> > >                 break;
> > >         }
> > > .
> > > .
> > > 
> > > So either rtdm_event_timedwait or rtdm_safe_copy_to_user is returing -EPERM.
> > 
> > Or things terminate earlier / later in the ioctl dispatching path.
> > 
> > > Looking at the documentation rtdm_safe_copy_to_user does not appear to return -EPERM.
> > > 
> > > Looking at the documentation rtdm_event_timedwait:
> > > -EPERM may be returned if an illegal invocation environment is detected.
> > > 
> > > So are we stuck in secondary mode?
> > 
> > Probably.
> > 
> > > Ideas?
> > 
> > You will not get around debugging more information out of your setup.
> > Use tracing, use well-placed printk.
> 
> So I put a pr_err where I expected the driver was failing:
> 
> 			rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> 
> 			err = rtdm_event_timedwait(&ctx->ioc_event,
> 				ctx->config.event_timeout,
> 				&timeout_seq);
> 			if (err) {
> +				pr_err("Just as I expected rtdm_event_timedwait failed %d\n", err);
> 				/* Device has been closed? */
> 				if (err == -EIDRM)
> 					err = -EBADF;
> 				goto wait_unlock_out;
> 			}
> 
> Then I found something unexpected:
>  Nr |   write->irq    |    irq->read    |   write->read   |
> -----------------------------------------------------------
> [ 1600.173441] Just as I expected rtdm_event_timedwait failed -110
> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation not permitted
> main : /dev/rtdm/rtser1 (read) -> closed
> 
> -110 is -ETIMEDOUT not -EPERM.
> 
> So then I figured hey that would make sense if the cable is not looped
> back. So I made sure I had the NULL modem loop correctly going to the
> two ports in question.
> 
> root@somimx6:/sys/bus/platform/drivers/imx-uart# /usr/xenomai/demo/cross-link 
> main : write-file opened
> main : write-config written
> main : read-file opened
> main : read-config written
> main : write-task created
> main : read-task created
> main : starting write-task
> main : starting read-task
>  Nr |   write->irq    |    irq->read    |   write->read   |
> -----------------------------------------------------------
>   0 |18446744046287090290 |     27423201660 |          740334
>   1 |18446744046287079290 |     27423200326 |          728000
>   2 |18446744046287078623 |     27423200993 |          728000
>   3 |18446744046287080623 |     27423199659 |          728666
>   4 |18446744046287078623 |     27423201326 |          728333
>   5 |18446744046287079622 |     27423200994 |          729000
>   6 |18446744046287078289 |     27423200660 |          727333
>   7 |18446744046287077956 |     27423201326 |          727666
>   8 |18446744046287079956 |     27423201327 |          729667
>   9 |18446744046287080623 |     27423199660 |          728667
>  10 |18446744046287078623 |     27423199660 |          726667
>  11 |18446744046287078956 |     27423203994 |          731334
>  12 |18446744046287078956 |     27423200326 |          727666
>  13 |18446744046287078623 |     27423202327 |          729334
>  14 |18446744046287078290 |     27423200659 |          727333
>  15 |18446744046287078623 |     27423200993 |          728000
>  16 |18446744046287079290 |     27423201326 |          729000
>  17 |18446744046287081290 |     27423199659 |          729333
>  18 |18446744046287077957 |     27423200993 |          727334
> .
> .
> .
> 
> Why in the world would -ETIMEDOUT come out as Operation not permitted?

Because EPERM is -1. ioctl return -1 upon error and the "real" error
status is found in errno. So, in fact, the test should check errno
if err is not 0.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] RT serial cross-link failure

[Michael Welling]

On Mon, Feb 22, 2016 at 10:02:27PM +0100, Gilles Chanteperdrix wrote:
> On Mon, Feb 22, 2016 at 02:51:39PM -0600, Michael Welling wrote:
> > On Mon, Feb 22, 2016 at 08:16:20PM +0100, Jan Kiszka wrote:
> > > On 2016-02-22 20:04, Michael Welling wrote:
> > > > On Mon, Feb 22, 2016 at 07:05:44PM +0100, Jan Kiszka wrote:
> > > >> On 2016-02-22 18:53, Michael Welling wrote:
> > > >>> On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
> > > >>>> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>> Am 2016-02-18 um 08:10 schrieb Michael Welling:
> > > >>>>>> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> > > >>>>>>>
> > > >>>>>>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
> > > >>>>>>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> > > >>>>>>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> > > >>>>>>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> > > >>>>>>>>>>
> > > >>>>>>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> > > >>>>>>>>>>
> > > >>>>>>>>>> When I run the cross-link demo the system hangs after an error in read_task.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Here is the output that I get:
> > > >>>>>>>>>> main : write-file opened
> > > >>>>>>>>>> main : write-config written
> > > >>>>>>>>>> main : read-file opened
> > > >>>>>>>>>> main : read-config written
> > > >>>>>>>>>> main : write-task created
> > > >>>>>>>>>> main : read-task created
> > > >>>>>>>>>> main : starting write-task
> > > >>>>>>>>>> main : strating read-task
> > > >>>>>>>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
> > > >>>>>>>>>> ----------------------------------------------------------
> > > >>>>>>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> > > >>>>>>>>>> main : /dev/rtdm/rtser1 (read) -> closed
> > > >>>>>>>>>> read_task: exit
> > > >>>>>>>>>>
> > > >>>>>>>>>> Any ideas why this would happen?
> > > >>>>>>>>>>
> > > >>>>>>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> > > >>>>>>>>> Dear Michael,
> > > >>>>>>>>>
> > > >>>>>>>>> I added a patch on December where I extended the IMX UART driver to support
> > > >>>>>>>>> open firmware, maybe my patch can help you to find your issue.
> > > >>>>>>>>> I posted the patch in the mailing list, you can find it here
> > > >>>>>>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> > > >>>>>>>>>
> > > >>>>>>>>> Kind regards
> > > >>>>>>>>> Wolfgang
> > > >>>>>>> Sorry Michael,
> > > >>>>>>>
> > > >>>>>>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> > > >>>>>> I am pretty sure that there is another patch applied previous.
> > > >>>>>>
> > > >>>>>> If you look at your patch you see German comments and open firmware code that
> > > >>>>>> is obviously not in the v2.6.4 on the git repository.
> > > >>>>>>
> > > >>>>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
> > > >>>>>>
> > > >>>>> I posted my patch, because I thought that Wolfgang Grandegger the author of
> > > >>>>> the driver may check it and include it to the xenomai if it is useable for
> > > >>>>> other users.
> > > >>>>>
> > > >>>>
> > > >>>> Yes but the patch does not apply to the driver in the source tree.
> > > >>>> Please provide the driver that you have after the patch.
> > > >>>
> > > >>> Any ideas out there?
> > > >>>
> > > >>
> > > >> Are you now referring to the incomplete patch or your original problem
> > > >> again?
> > > > 
> > > > The original problem is my primary concern. I would not mind having another
> > > > version of the driver to test against as well.
> > > > 
> > > >>
> > > >> For the latter case, I would recommend debugging the error code, ie.
> > > >> what threw this at you. In Xenomai context, -EPERM often means that the
> > > >> caller is requesting some (potentially) blocking service without being a
> > > >> real-time task. But, of course, also the driver itself may decide to
> > > >> raise this for whatever reasons.
> > > > 
> > > > Here is the snippet of code from the user app that concerns me:
> > > > .
> > > > .
> > > >         printf(" Nr |   write->irq    |    irq->read    |   write->read   |\n");
> > > >         printf("-----------------------------------------------------------\n");
> > > > 
> > > >         /*
> > > >          * We are in secondary mode now due to printf, the next
> > > >          * blocking Xenomai or driver call will switch us back
> > > >          * (here: RTSER_RTIOC_WAIT_EVENT).
> > > >          */
> > > > 
> > > >         while (1) {
> > > >                 /* waiting for event */
> > > >                 err = ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
> > > > .
> > > > .
> > > > 
> > > > So is the comment no longer true with Xenomai 3?
> > > 
> > > No, that would be a bug.
> > > 
> > > > 
> > > > Here is the content of the corresponding ioctl in the driver:
> > > > .
> > > > .
> > > >         case RTSER_RTIOC_WAIT_EVENT: {
> > > >                 struct rtser_event ev = { .rxpend_timestamp = 0 };
> > > >                 rtdm_toseq_t timeout_seq;
> > > > 
> > > >                 if (!rtdm_in_rt_context())
> > > >                         return -ENOSYS;
> > > > 
> > > >                 /* Only one waiter allowed, stop any further attempts here. */
> > > >                 if (test_and_set_bit(0, &ctx->ioc_event_lock))
> > > >                         return -EBUSY;
> > > > 
> > > >                 rtdm_toseq_init(&timeout_seq, ctx->config.event_timeout);
> > > > 
> > > >                 rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
> > > > 
> > > >                 while (!ctx->ioc_events) {
> > > >                         /* Only enable error interrupt
> > > >                            when the user waits for it. */
> > > >                         if (ctx->config.event_mask & RTSER_EVENT_ERRPEND) {
> > > >                                 ctx->ier_status |= IER_STAT;
> > > > #ifdef FIXME
> > > >                                 rt_imx_uart_reg_out(mode, base, IER,
> > > >                                                  ctx->ier_status);
> > > > #endif
> > > >                         }
> > > > 
> > > >                         rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> > > > 
> > > >                         err = rtdm_event_timedwait(&ctx->ioc_event,
> > > >                                                    ctx->config.event_timeout,
> > > >                                                    &timeout_seq);
> > > >                         if (err) {
> > > >                                 /* Device has been closed? */
> > > >                                 if (err == -EIDRM)
> > > >                                         err = -EBADF;
> > > >                                 goto wait_unlock_out;
> > > >                         }
> > > > 
> > > >                         rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
> > > >                 }
> > > > 
> > > >                 ev.events = ctx->ioc_events;
> > > >                 ctx->ioc_events &=
> > > >                     ~(RTSER_EVENT_MODEMHI | RTSER_EVENT_MODEMLO);
> > > > 
> > > >                 ev.last_timestamp = ctx->last_timestamp;
> > > >                 ev.rx_pending = ctx->in_npend;
> > > > 
> > > >                 if (ctx->in_history)
> > > >                         ev.rxpend_timestamp = ctx->in_history[ctx->in_head];
> > > > 
> > > >                 rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> > > > 
> > > >                 if (rtdm_fd_is_user(fd))
> > > >                         err =
> > > >                             rtdm_safe_copy_to_user(fd, arg, &ev,
> > > >                                                    sizeof(struct
> > > >                                                           rtser_event));
> > > >                         else
> > > >                                 memcpy(arg, &ev, sizeof(struct rtser_event));
> > > > 
> > > > wait_unlock_out:
> > > >                 /* release the simple event waiter lock */
> > > >                 clear_bit(0, &ctx->ioc_event_lock);
> > > >                 break;
> > > >         }
> > > > .
> > > > .
> > > > 
> > > > So either rtdm_event_timedwait or rtdm_safe_copy_to_user is returing -EPERM.
> > > 
> > > Or things terminate earlier / later in the ioctl dispatching path.
> > > 
> > > > Looking at the documentation rtdm_safe_copy_to_user does not appear to return -EPERM.
> > > > 
> > > > Looking at the documentation rtdm_event_timedwait:
> > > > -EPERM may be returned if an illegal invocation environment is detected.
> > > > 
> > > > So are we stuck in secondary mode?
> > > 
> > > Probably.
> > > 
> > > > Ideas?
> > > 
> > > You will not get around debugging more information out of your setup.
> > > Use tracing, use well-placed printk.
> > 
> > So I put a pr_err where I expected the driver was failing:
> > 
> > 			rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> > 
> > 			err = rtdm_event_timedwait(&ctx->ioc_event,
> > 				ctx->config.event_timeout,
> > 				&timeout_seq);
> > 			if (err) {
> > +				pr_err("Just as I expected rtdm_event_timedwait failed %d\n", err);
> > 				/* Device has been closed? */
> > 				if (err == -EIDRM)
> > 					err = -EBADF;
> > 				goto wait_unlock_out;
> > 			}
> > 
> > Then I found something unexpected:
> >  Nr |   write->irq    |    irq->read    |   write->read   |
> > -----------------------------------------------------------
> > [ 1600.173441] Just as I expected rtdm_event_timedwait failed -110
> > read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation not permitted
> > main : /dev/rtdm/rtser1 (read) -> closed
> > 
> > -110 is -ETIMEDOUT not -EPERM.
> > 
> > So then I figured hey that would make sense if the cable is not looped
> > back. So I made sure I had the NULL modem loop correctly going to the
> > two ports in question.
> > 
> > root@somimx6:/sys/bus/platform/drivers/imx-uart# /usr/xenomai/demo/cross-link 
> > main : write-file opened
> > main : write-config written
> > main : read-file opened
> > main : read-config written
> > main : write-task created
> > main : read-task created
> > main : starting write-task
> > main : starting read-task
> >  Nr |   write->irq    |    irq->read    |   write->read   |
> > -----------------------------------------------------------
> >   0 |18446744046287090290 |     27423201660 |          740334
> >   1 |18446744046287079290 |     27423200326 |          728000
> >   2 |18446744046287078623 |     27423200993 |          728000
> >   3 |18446744046287080623 |     27423199659 |          728666
> >   4 |18446744046287078623 |     27423201326 |          728333
> >   5 |18446744046287079622 |     27423200994 |          729000
> >   6 |18446744046287078289 |     27423200660 |          727333
> >   7 |18446744046287077956 |     27423201326 |          727666
> >   8 |18446744046287079956 |     27423201327 |          729667
> >   9 |18446744046287080623 |     27423199660 |          728667
> >  10 |18446744046287078623 |     27423199660 |          726667
> >  11 |18446744046287078956 |     27423203994 |          731334
> >  12 |18446744046287078956 |     27423200326 |          727666
> >  13 |18446744046287078623 |     27423202327 |          729334
> >  14 |18446744046287078290 |     27423200659 |          727333
> >  15 |18446744046287078623 |     27423200993 |          728000
> >  16 |18446744046287079290 |     27423201326 |          729000
> >  17 |18446744046287081290 |     27423199659 |          729333
> >  18 |18446744046287077957 |     27423200993 |          727334
> > .
> > .
> > .
> > 
> > Why in the world would -ETIMEDOUT come out as Operation not permitted?
> 
> Because EPERM is -1. ioctl return -1 upon error and the "real" error
> status is found in errno. So, in fact, the test should check errno
> if err is not 0.

Ah I see it now. Would you like a patch for the cross-link demo?

> 
> -- 
> 					    Gilles.
> https://click-hack.org

Re: [Xenomai] RT serial cross-link failure

[Gilles Chanteperdrix]

On Mon, Feb 22, 2016 at 03:10:59PM -0600, Michael Welling wrote:
> On Mon, Feb 22, 2016 at 10:02:27PM +0100, Gilles Chanteperdrix wrote:
> > On Mon, Feb 22, 2016 at 02:51:39PM -0600, Michael Welling wrote:
> > > On Mon, Feb 22, 2016 at 08:16:20PM +0100, Jan Kiszka wrote:
> > > > On 2016-02-22 20:04, Michael Welling wrote:
> > > > > On Mon, Feb 22, 2016 at 07:05:44PM +0100, Jan Kiszka wrote:
> > > > >> On 2016-02-22 18:53, Michael Welling wrote:
> > > > >>> On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
> > > > >>>> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> Am 2016-02-18 um 08:10 schrieb Michael Welling:
> > > > >>>>>> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> > > > >>>>>>>
> > > > >>>>>>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
> > > > >>>>>>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> > > > >>>>>>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> > > > >>>>>>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> When I run the cross-link demo the system hangs after an error in read_task.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Here is the output that I get:
> > > > >>>>>>>>>> main : write-file opened
> > > > >>>>>>>>>> main : write-config written
> > > > >>>>>>>>>> main : read-file opened
> > > > >>>>>>>>>> main : read-config written
> > > > >>>>>>>>>> main : write-task created
> > > > >>>>>>>>>> main : read-task created
> > > > >>>>>>>>>> main : starting write-task
> > > > >>>>>>>>>> main : strating read-task
> > > > >>>>>>>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
> > > > >>>>>>>>>> ----------------------------------------------------------
> > > > >>>>>>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> > > > >>>>>>>>>> main : /dev/rtdm/rtser1 (read) -> closed
> > > > >>>>>>>>>> read_task: exit
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Any ideas why this would happen?
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> > > > >>>>>>>>> Dear Michael,
> > > > >>>>>>>>>
> > > > >>>>>>>>> I added a patch on December where I extended the IMX UART driver to support
> > > > >>>>>>>>> open firmware, maybe my patch can help you to find your issue.
> > > > >>>>>>>>> I posted the patch in the mailing list, you can find it here
> > > > >>>>>>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> > > > >>>>>>>>>
> > > > >>>>>>>>> Kind regards
> > > > >>>>>>>>> Wolfgang
> > > > >>>>>>> Sorry Michael,
> > > > >>>>>>>
> > > > >>>>>>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> > > > >>>>>> I am pretty sure that there is another patch applied previous.
> > > > >>>>>>
> > > > >>>>>> If you look at your patch you see German comments and open firmware code that
> > > > >>>>>> is obviously not in the v2.6.4 on the git repository.
> > > > >>>>>>
> > > > >>>>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
> > > > >>>>>>
> > > > >>>>> I posted my patch, because I thought that Wolfgang Grandegger the author of
> > > > >>>>> the driver may check it and include it to the xenomai if it is useable for
> > > > >>>>> other users.
> > > > >>>>>
> > > > >>>>
> > > > >>>> Yes but the patch does not apply to the driver in the source tree.
> > > > >>>> Please provide the driver that you have after the patch.
> > > > >>>
> > > > >>> Any ideas out there?
> > > > >>>
> > > > >>
> > > > >> Are you now referring to the incomplete patch or your original problem
> > > > >> again?
> > > > > 
> > > > > The original problem is my primary concern. I would not mind having another
> > > > > version of the driver to test against as well.
> > > > > 
> > > > >>
> > > > >> For the latter case, I would recommend debugging the error code, ie.
> > > > >> what threw this at you. In Xenomai context, -EPERM often means that the
> > > > >> caller is requesting some (potentially) blocking service without being a
> > > > >> real-time task. But, of course, also the driver itself may decide to
> > > > >> raise this for whatever reasons.
> > > > > 
> > > > > Here is the snippet of code from the user app that concerns me:
> > > > > .
> > > > > .
> > > > >         printf(" Nr |   write->irq    |    irq->read    |   write->read   |\n");
> > > > >         printf("-----------------------------------------------------------\n");
> > > > > 
> > > > >         /*
> > > > >          * We are in secondary mode now due to printf, the next
> > > > >          * blocking Xenomai or driver call will switch us back
> > > > >          * (here: RTSER_RTIOC_WAIT_EVENT).
> > > > >          */
> > > > > 
> > > > >         while (1) {
> > > > >                 /* waiting for event */
> > > > >                 err = ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
> > > > > .
> > > > > .
> > > > > 
> > > > > So is the comment no longer true with Xenomai 3?
> > > > 
> > > > No, that would be a bug.
> > > > 
> > > > > 
> > > > > Here is the content of the corresponding ioctl in the driver:
> > > > > .
> > > > > .
> > > > >         case RTSER_RTIOC_WAIT_EVENT: {
> > > > >                 struct rtser_event ev = { .rxpend_timestamp = 0 };
> > > > >                 rtdm_toseq_t timeout_seq;
> > > > > 
> > > > >                 if (!rtdm_in_rt_context())
> > > > >                         return -ENOSYS;
> > > > > 
> > > > >                 /* Only one waiter allowed, stop any further attempts here. */
> > > > >                 if (test_and_set_bit(0, &ctx->ioc_event_lock))
> > > > >                         return -EBUSY;
> > > > > 
> > > > >                 rtdm_toseq_init(&timeout_seq, ctx->config.event_timeout);
> > > > > 
> > > > >                 rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
> > > > > 
> > > > >                 while (!ctx->ioc_events) {
> > > > >                         /* Only enable error interrupt
> > > > >                            when the user waits for it. */
> > > > >                         if (ctx->config.event_mask & RTSER_EVENT_ERRPEND) {
> > > > >                                 ctx->ier_status |= IER_STAT;
> > > > > #ifdef FIXME
> > > > >                                 rt_imx_uart_reg_out(mode, base, IER,
> > > > >                                                  ctx->ier_status);
> > > > > #endif
> > > > >                         }
> > > > > 
> > > > >                         rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> > > > > 
> > > > >                         err = rtdm_event_timedwait(&ctx->ioc_event,
> > > > >                                                    ctx->config.event_timeout,
> > > > >                                                    &timeout_seq);
> > > > >                         if (err) {
> > > > >                                 /* Device has been closed? */
> > > > >                                 if (err == -EIDRM)
> > > > >                                         err = -EBADF;
> > > > >                                 goto wait_unlock_out;
> > > > >                         }
> > > > > 
> > > > >                         rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
> > > > >                 }
> > > > > 
> > > > >                 ev.events = ctx->ioc_events;
> > > > >                 ctx->ioc_events &=
> > > > >                     ~(RTSER_EVENT_MODEMHI | RTSER_EVENT_MODEMLO);
> > > > > 
> > > > >                 ev.last_timestamp = ctx->last_timestamp;
> > > > >                 ev.rx_pending = ctx->in_npend;
> > > > > 
> > > > >                 if (ctx->in_history)
> > > > >                         ev.rxpend_timestamp = ctx->in_history[ctx->in_head];
> > > > > 
> > > > >                 rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> > > > > 
> > > > >                 if (rtdm_fd_is_user(fd))
> > > > >                         err =
> > > > >                             rtdm_safe_copy_to_user(fd, arg, &ev,
> > > > >                                                    sizeof(struct
> > > > >                                                           rtser_event));
> > > > >                         else
> > > > >                                 memcpy(arg, &ev, sizeof(struct rtser_event));
> > > > > 
> > > > > wait_unlock_out:
> > > > >                 /* release the simple event waiter lock */
> > > > >                 clear_bit(0, &ctx->ioc_event_lock);
> > > > >                 break;
> > > > >         }
> > > > > .
> > > > > .
> > > > > 
> > > > > So either rtdm_event_timedwait or rtdm_safe_copy_to_user is returing -EPERM.
> > > > 
> > > > Or things terminate earlier / later in the ioctl dispatching path.
> > > > 
> > > > > Looking at the documentation rtdm_safe_copy_to_user does not appear to return -EPERM.
> > > > > 
> > > > > Looking at the documentation rtdm_event_timedwait:
> > > > > -EPERM may be returned if an illegal invocation environment is detected.
> > > > > 
> > > > > So are we stuck in secondary mode?
> > > > 
> > > > Probably.
> > > > 
> > > > > Ideas?
> > > > 
> > > > You will not get around debugging more information out of your setup.
> > > > Use tracing, use well-placed printk.
> > > 
> > > So I put a pr_err where I expected the driver was failing:
> > > 
> > > 			rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> > > 
> > > 			err = rtdm_event_timedwait(&ctx->ioc_event,
> > > 				ctx->config.event_timeout,
> > > 				&timeout_seq);
> > > 			if (err) {
> > > +				pr_err("Just as I expected rtdm_event_timedwait failed %d\n", err);
> > > 				/* Device has been closed? */
> > > 				if (err == -EIDRM)
> > > 					err = -EBADF;
> > > 				goto wait_unlock_out;
> > > 			}
> > > 
> > > Then I found something unexpected:
> > >  Nr |   write->irq    |    irq->read    |   write->read   |
> > > -----------------------------------------------------------
> > > [ 1600.173441] Just as I expected rtdm_event_timedwait failed -110
> > > read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation not permitted
> > > main : /dev/rtdm/rtser1 (read) -> closed
> > > 
> > > -110 is -ETIMEDOUT not -EPERM.
> > > 
> > > So then I figured hey that would make sense if the cable is not looped
> > > back. So I made sure I had the NULL modem loop correctly going to the
> > > two ports in question.
> > > 
> > > root@somimx6:/sys/bus/platform/drivers/imx-uart# /usr/xenomai/demo/cross-link 
> > > main : write-file opened
> > > main : write-config written
> > > main : read-file opened
> > > main : read-config written
> > > main : write-task created
> > > main : read-task created
> > > main : starting write-task
> > > main : starting read-task
> > >  Nr |   write->irq    |    irq->read    |   write->read   |
> > > -----------------------------------------------------------
> > >   0 |18446744046287090290 |     27423201660 |          740334
> > >   1 |18446744046287079290 |     27423200326 |          728000
> > >   2 |18446744046287078623 |     27423200993 |          728000
> > >   3 |18446744046287080623 |     27423199659 |          728666
> > >   4 |18446744046287078623 |     27423201326 |          728333
> > >   5 |18446744046287079622 |     27423200994 |          729000
> > >   6 |18446744046287078289 |     27423200660 |          727333
> > >   7 |18446744046287077956 |     27423201326 |          727666
> > >   8 |18446744046287079956 |     27423201327 |          729667
> > >   9 |18446744046287080623 |     27423199660 |          728667
> > >  10 |18446744046287078623 |     27423199660 |          726667
> > >  11 |18446744046287078956 |     27423203994 |          731334
> > >  12 |18446744046287078956 |     27423200326 |          727666
> > >  13 |18446744046287078623 |     27423202327 |          729334
> > >  14 |18446744046287078290 |     27423200659 |          727333
> > >  15 |18446744046287078623 |     27423200993 |          728000
> > >  16 |18446744046287079290 |     27423201326 |          729000
> > >  17 |18446744046287081290 |     27423199659 |          729333
> > >  18 |18446744046287077957 |     27423200993 |          727334
> > > .
> > > .
> > > .
> > > 
> > > Why in the world would -ETIMEDOUT come out as Operation not permitted?
> > 
> > Because EPERM is -1. ioctl return -1 upon error and the "real" error
> > status is found in errno. So, in fact, the test should check errno
> > if err is not 0.
> 
> Ah I see it now. Would you like a patch for the cross-link demo?

Yes, thanks.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] RT serial cross-link failure

[Michael Welling]

On Mon, Feb 22, 2016 at 10:14:39PM +0100, Gilles Chanteperdrix wrote:
> > > > Why in the world would -ETIMEDOUT come out as Operation not permitted?
> > > 
> > > Because EPERM is -1. ioctl return -1 upon error and the "real" error
> > > status is found in errno. So, in fact, the test should check errno
> > > if err is not 0.
> > 
> > Ah I see it now. Would you like a patch for the cross-link demo?
> 
> Yes, thanks.

Sent.

Would you like a properly formed patch for the imx uart driver?

> 
> -- 
> 					    Gilles.
> https://click-hack.org