[Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Greg Gallagher]

This patch is based on one that was submitted by Wolfgang Netbal back in Feb
2016 but a formal patch was never submitted.
I added a couple small changes (style errors and imx7 define) and tested on a
imx7d board. One quick note, the IMX7D define may not really be needed since
most imx7 uarts look to be compatible with imx6. The original thread that this
patch was derived from is located here:

https://xenomai.org/pipermail/xenomai/2016-February/035924.html

Signed-off-by: Greg Gallagher 
---
 kernel/drivers/serial/rt_imx_uart.c | 326 
 1 file changed, 218 insertions(+), 108 deletions(-)

diff --git a/kernel/drivers/serial/rt_imx_uart.c 
b/kernel/drivers/serial/rt_imx_uart.c
index 092cecc..61836ae 100644
--- a/kernel/drivers/serial/rt_imx_uart.c
+++ b/kernel/drivers/serial/rt_imx_uart.c
@@ -36,8 +36,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -65,7 +67,10 @@ 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)
@@ -143,7 +148,7 @@ MODULE_LICENSE("GPL");
 #define USR1_DTRD  (1<<7)  /* DTR Delta */
 #define USR1_RXDS  (1<<6)  /* Receiver idle interrupt flag */
 #define USR1_AIRINT(1<<5)  /* Async IR wake interrupt flag */
-#define USR1_AWAKE (1<<4)  /* Aysnc wake interrupt flag */
+#define USR1_AWAKE (1<<4)  /* Async wake interrupt flag */
 #define USR2_ADET  (1<<15) /* Auto baud rate detect complete */
 #define USR2_TXFE  (1<<14) /* Transmit buffer FIFO empty */
 #define USR2_DTRF  (1<<13) /* DTR edge interrupt flag */
@@ -189,9 +194,24 @@ MODULE_LICENSE("GPL");
 #define RT_IMX_UART_MAX5
 
 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 and i.MX6q */
+enum imx_uart_type {
+   IMX1_UART,
+   IMX21_UART,
+   IMX53_UART,
+   IMX6Q_UART,
+};
+
+/* device type dependent stuff */
+struct imx_uart_data {
+   unsigned int 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 */
@@ -200,11 +220,69 @@ struct rt_imx_uart_port {
unsigned int have_rtscts;
unsigned int use_dcedte;
unsigned int use_hwflow;
-   struct clk *clk;/* clock id for UART clock */
+   struct clk *clk_ipg;/* clock id for UART clock */
+   struct clk *clk_per;/* clock id for UART clock */
+   const struct imx_uart_data *devdata;
unsigned int uartclk;   /* base uart clock */
struct rtdm_device rtdm_dev;/* RTDM device structure */
 };
 
+
+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,
+   },
+   [IMX53_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX53_UART,
+   },
+   [IMX6Q_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX6Q_UART,
+   },
+};
+
+static const struct platform_device_id rt_imx_uart_id_table[] = {
+   {
+   .name = "imx1-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX1_UART],
+   }, {
+   .name = "imx21-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX21_UART],
+   }, {
+   .name = "imx53-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX53_UART],
+   }, {
+   .name = "imx6q-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX6Q_UART],
+   }, {
+   /* sentinel */
+   }
+};
+MODULE_DEVICE_TABLE(platform, rt_imx_uart_id_table);
+
+static const struct of_device_id rt_imx_uart_dt_ids[] = {
+   {
+   .compatible = "fsl,imx6q-uart",
+   .data = _uart_devdata[IMX6Q_UART], },
+   {
+   .compatible = "fsl,imx53-uart",
+   .data = _uart_devdata[IMX53_UART], },
+   {
+   .compatible = "fsl,imx1-uart",
+   .data = _uart_devdata[IMX1_UART], },
+   {
+   .compatible = "fsl,imx21-uart",
+   .data = _uart_devdata[IMX21_UART], },
+  

[Xenomai] [PATCH 2/3] Handle device paths from the device tree that start with a forward slash

[Greg Gallagher]

If the device name from the device tree starts with a forward slash (/) the
rtdm device stores it in the registry including the forward slash.  When we
go to use that device and do the registry lookup we use a relative path from
/dev/rtdm which doesn't contain the forward slash and fails to find a match.
Open won't return an error but IO calls will fail.  To fix this when we
register an RTDM device skip the first character if it's a forward slash.

In my case the path from the device tree is
/amba_pl/gpio@4120/gpio905
which gets stored in the registry. When we want to use the device and look up
the device path in the registry we use
amba_pl/gpio@4120/gpio905
which won't find a match in the registry.

Tested on Zynq7000 gpio drivers
---
 kernel/cobalt/rtdm/device.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/cobalt/rtdm/device.c b/kernel/cobalt/rtdm/device.c
index 4533dfb..4cfdb1c 100644
--- a/kernel/cobalt/rtdm/device.c
+++ b/kernel/cobalt/rtdm/device.c
@@ -394,6 +394,7 @@ int rtdm_dev_register(struct rtdm_device *dev)
int ret, major, minor;
xnkey_t id;
dev_t rdev;
+   const char *dev_name;
 
secondary_mode_only();
 
@@ -446,8 +447,12 @@ int rtdm_dev_register(struct rtdm_device *dev)
ret = -ENOMEM;
goto fail;
}
-
-   ret = xnregistry_enter(dev->name, dev,
+   if (dev->name[0] == '/') {
+   dev_name = dev->name+1;
+   } else {
+   dev_name = dev->name;
+   }
+   ret = xnregistry_enter(dev_name, dev,
   >named.handle, NULL);
if (ret)
goto fail;
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH 3/3] Allow for more then one rt gpio driver to be built and loaded at the same build

[Greg Gallagher]

Some SOCs will have two GPIO chips that require two independent drivers.  In my
case I was working with the Zynq SOC and needed a driver for the gpios on the
FPGA and a driver for the gpios available on the ARM core. This change allows
for two rt gpio drivers to be built and loaded at the same time.
The rt gpio driver will be renamed from xeno-gpio to the following:

xeno-gpio-bcm2835.ko
xeno-gpio-mxc.ko
xeno-gpio-sun8i-h3.ko
xeno-gpio-zynq7000.ko

This also moves the gpio-core logic into the kernel image.
---
 kernel/drivers/gpio/Kconfig  | 12 ++--
 kernel/drivers/gpio/Makefile | 22 --
 2 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
index b7efa54..48475f2 100644
--- a/kernel/drivers/gpio/Kconfig
+++ b/kernel/drivers/gpio/Kconfig
@@ -1,7 +1,7 @@
 menu "Real-time GPIO drivers"
 
 config XENO_DRIVERS_GPIO
-   tristate "GPIO controller"
+   bool "GPIO controller"
depends on GPIOLIB
help
 
@@ -11,7 +11,7 @@ if XENO_DRIVERS_GPIO
 
 config XENO_DRIVERS_GPIO_BCM2835
depends on MACH_BCM2708 || ARCH_BCM2835
-   bool "Support for BCM2835 GPIOs"
+   tristate "Support for BCM2835 GPIOs"
help
 
Enables support for the GPIO controller available from
@@ -19,7 +19,7 @@ config XENO_DRIVERS_GPIO_BCM2835
 
 config XENO_DRIVERS_GPIO_MXC
depends on GPIO_MXC
-   bool "Support for MXC GPIOs"
+   tristate "Support for MXC GPIOs"
help
 
Suitable for the GPIO controller available from
@@ -27,7 +27,7 @@ config XENO_DRIVERS_GPIO_MXC
 
 config XENO_DRIVERS_GPIO_SUN8I_H3
depends on MACH_SUN8I && PINCTRL_SUN8I_H3
-   bool "Support for SUN8I H3 GPIOs"
+   tristate "Support for SUN8I H3 GPIOs"
help
 
Suitable for the GPIO controller available from Allwinner's H3
@@ -35,7 +35,7 @@ config XENO_DRIVERS_GPIO_SUN8I_H3
 
 config XENO_DRIVERS_GPIO_ZYNQ7000
depends on ARCH_ZYNQ
-   bool "Support for Zynq7000 GPIOs"
+   tristate "Support for Zynq7000 GPIOs"
help
 
Enables support for the GPIO controller available from
@@ -43,7 +43,7 @@ config XENO_DRIVERS_GPIO_ZYNQ7000
 
 config XENO_DRIVERS_GPIO_XILINX
depends on ARCH_ZYNQ
-   bool "Support for Xilinx GPIOs"
+   tristate "Support for Xilinx GPIOs"
help
 
Enables support for the GPIO controller available from
diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
index 3737330..8648fcc 100644
--- a/kernel/drivers/gpio/Makefile
+++ b/kernel/drivers/gpio/Makefile
@@ -1,12 +1,14 @@
 ccflags-$(CONFIG_XENO_DRIVERS_GPIO_DEBUG) := -DDEBUG
 
-obj-$(CONFIG_XENO_DRIVERS_GPIO) += xeno_gpio.o
-
-xeno_gpio-y := gpio-core.o
-
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += gpio-bcm2835.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += gpio-mxc.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += gpio-sun8i-h3.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += gpio-zynq7000.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += gpio-xilinx.o
-
+obj-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += xeno-gpio-bcm2835.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += xeno-gpio-mxc.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += xeno-gpio-sun8i-h3.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += xeno-gpio-zynq7000.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += xeno-gpio-xilinx.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO) += gpio-core.o
+
+xeno-gpio-bcm2835-y := gpio-bcm2835.o
+xeno-gpio-mxc-y := gpio-mxc.o
+xeno-gpio-sun8i-h3-y := gpio-sun8i-h3.o
+xeno-gpio-zynq7000-y := gpio-zynq7000.o
+xeno-gpio-xilinx-y := gpio-xilinx.o
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH 1/3] Add Xilinx AXI gpio driver

[Greg Gallagher]

---
 kernel/drivers/gpio/Kconfig   | 10 +-
 kernel/drivers/gpio/Makefile  |  3 ++-
 kernel/drivers/gpio/gpio-xilinx.c | 40 +++
 3 files changed, 51 insertions(+), 2 deletions(-)
 create mode 100644 kernel/drivers/gpio/gpio-xilinx.c

diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
index 81fc442..b7efa54 100644
--- a/kernel/drivers/gpio/Kconfig
+++ b/kernel/drivers/gpio/Kconfig
@@ -6,7 +6,7 @@ config XENO_DRIVERS_GPIO
help
 
Real-time capable GPIO module.
-  
+
 if XENO_DRIVERS_GPIO
 
 config XENO_DRIVERS_GPIO_BCM2835
@@ -41,6 +41,14 @@ config XENO_DRIVERS_GPIO_ZYNQ7000
Enables support for the GPIO controller available from
Xilinx's Zynq7000 SoC.
 
+config XENO_DRIVERS_GPIO_XILINX
+   depends on ARCH_ZYNQ
+   bool "Support for Xilinx GPIOs"
+   help
+
+   Enables support for the GPIO controller available from
+   Xilinx's softcore IP.
+
 config XENO_DRIVERS_GPIO_DEBUG
bool "Enable GPIO core debugging features"
 
diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
index 7f28403..3737330 100644
--- a/kernel/drivers/gpio/Makefile
+++ b/kernel/drivers/gpio/Makefile
@@ -1,4 +1,3 @@
-
 ccflags-$(CONFIG_XENO_DRIVERS_GPIO_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_XENO_DRIVERS_GPIO) += xeno_gpio.o
@@ -9,3 +8,5 @@ xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += gpio-bcm2835.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += gpio-mxc.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += gpio-sun8i-h3.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += gpio-zynq7000.o
+xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += gpio-xilinx.o
+
diff --git a/kernel/drivers/gpio/gpio-xilinx.c 
b/kernel/drivers/gpio/gpio-xilinx.c
new file mode 100644
index 000..e982f5f
--- /dev/null
+++ b/kernel/drivers/gpio/gpio-xilinx.c
@@ -0,0 +1,40 @@
+/**
+ * @note Copyright (C) 2017 Greg Gallagher 
+ *
+ * This driver controls the gpio that can be located on the PL
+ * of the Zynq SOC
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+#include 
+#include 
+
+#define RTDM_SUBCLASS_XILINX  5
+
+static int __init xilinx_gpio_init(void)
+{
+   return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a",
+ RTDM_SUBCLASS_XILINX);
+}
+module_init(xilinx_gpio_init);
+
+static void __exit xilinx_gpio_exit(void)
+{
+   rtdm_gpiochip_remove_of(RTDM_SUBCLASS_XILINX);
+}
+module_exit(xilinx_gpio_exit);
+
+MODULE_LICENSE("GPL");
+
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] libs: Mode-switching notice/debug/warning/panic

[Philippe Gerum]

On 02/01/2018 05:43 PM, Jan Kiszka wrote:
> Hi,
> 
> it seems those functions above force the caller always to secondary mode
> (ok, panic is not an issue). Intentionally? To avoid using the wrapped
> versions which may trigger one of the calls again? Or could we also call
> the RT versions, at least after init_done?
> 

If you refer to __printout() in libboilerplate, I believe so, since all
the preceding code assumes the process is already bound to the rt system
anyway, which is required to init the printf support. Synchronizing with
the printer loop before leaving would be a must though - maybe directly
into __panic() for that purpose.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] libs: Mode-switching notice/debug/warning/panic

[Jan Kiszka]

Hi,

it seems those functions above force the caller always to secondary mode
(ok, panic is not an issue). Intentionally? To avoid using the wrapped
versions which may trigger one of the calls again? Or could we also call
the RT versions, at least after init_done?

Jan

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

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] rtnet/tdma: fix lockup issue

[Jan Kiszka]

On 2018-01-30 10:58, Philippe Gerum wrote:
> On 01/30/2018 07:59 AM, Jan Kiszka wrote:
>> On 2018-01-30 01:26, Joonyoung Shim wrote:
>>> Sometimes the kernel lockup occurs with "rtifconfig rteth0 down" command
>>> execution on TDMA slave.
>>>
>>> [525182.648366] INFO: rcu_sched detected stalls on CPUs/tasks:
>>> [525182.648372] 7-...: (0 ticks this GP) idle=415/140/0 
>>> softirq=1249048/1249048 fqs=6628
>>> [525182.648374] (detected by 0, t=15002 jiffies, g=2145322, c=2145321, 
>>> q=131873)
>>> [525182.648376] Task dump for CPU 7:
>>> [525182.648377] rtifconfig  R  running task0 24290  24278 
>>> 0x000c
>>> [525182.648381]   888b9ede5640 0001 
>>> a35bbc00
>>> [525182.648384]  888b8be78000 b20f8413bc10 a446e80d 
>>> 0001aa50
>>> [525182.648387]  888b9ede5480 b20f8413bc50 a459720d 
>>> 888b88510440
>>> [525182.648390] Call Trace:
>>> [525182.648395]  [] ? xnarch_switch_to+0x5d/0xa0
>>> [525182.648398]  [] ___xnsched_run.part.64+0x1ed/0x390
>>> [525182.648400]  [] __xnsched_run_handler+0xc3/0xe0
>>> [525182.648402]  [] __ipipe_do_sync_stage+0xdc/0x170
>>> [525182.648404]  [] __ipipe_do_sync_pipeline+0x33/0x90
>>> [525182.648405]  [] __ipipe_restore_head+0x6d/0xb0
>>> [525182.648407]  [] __rtdm_synch_flush+0xf8/0x130
>>> [525182.648410]  [] rtdm_event_destroy+0x21/0x70
>>> [525182.648412]  [] tdma_detach+0x1b/0x100 [tdma]
>>> [525182.648415]  [] rtmac_disc_detach+0x44/0xd0 [rtmac]
>>> [525182.648418]  [] rtnet_core_ioctl+0x2b8/0x490 [rtnet]
>>> [525182.648421]  [] rtnet_ioctl+0x103/0x150 [rtnet]
>>> [525182.648423]  [] do_vfs_ioctl+0xa1/0x5d0
>>> [525182.648425]  [] ? putname+0x54/0x60
>>> [525182.648426]  [] SyS_ioctl+0x79/0x90
>>> [525182.648429]  [] entry_SYSCALL_64_fastpath+0x16/0x1b
>>>
>>> It is suspected of causing the lockup that the sync_event used in the
>>> task is destroyed in advance before the task is destroyed.
>>>
>>> Fixes: bd971c3a9624 ("rtnet: adapt to RTDM task management changes")
>>> Signed-off-by: Joonyoung Shim 
>>> ---
>>>  kernel/drivers/net/stack/rtmac/tdma/tdma_module.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/drivers/net/stack/rtmac/tdma/tdma_module.c 
>>> b/kernel/drivers/net/stack/rtmac/tdma/tdma_module.c
>>> index e367d21..854a996 100644
>>> --- a/kernel/drivers/net/stack/rtmac/tdma/tdma_module.c
>>> +++ b/kernel/drivers/net/stack/rtmac/tdma/tdma_module.c
>>> @@ -227,14 +227,14 @@ int tdma_detach(struct rtnet_device *rtdev, void 
>>> *priv)
>>>  struct tdma_job *job, *tmp;
>>>  
>>>  
>>> +rtdm_task_destroy(>worker_task);
>>> +
>>>  rtdm_event_destroy(>sync_event);
>>>  rtdm_event_destroy(>xmit_event);
>>>  rtdm_event_destroy(>worker_wakeup);
>>>  
>>>  tdma_dev_release(tdma);
>>>  
>>> -rtdm_task_destroy(>worker_task);
>>> -
>>>  list_for_each_entry_safe(job, tmp, >first_job->entry, entry) {
>>> if (job->id >= 0)
>>> tdma_cleanup_slot(tdma, SLOT_JOB(job));
>>>
>>
>> That used to work properly: The rtdm_event_destroy call would have woken
>> up the worker thread when blocked on the events, they detected the
>> destruction and terminated themselves.
>>
>> Philippe, did something related change when mapping RTDM on Xenomai 3?
>> I'm seeing in bd971c3a9624 some other places in RTnet that were
>> reordered in the way like above, but I'm not finding a reference in the
>> migration guide Xenomai 2->3.
>>
>> Jan
>>
> 
> For the original scheme to work reliably, I would have added this:
> 
> diff --git a/kernel/drivers/net/stack/rtmac/tdma/tdma_worker.c
> b/kernel/drivers/net/stack/rtmac/tdma/tdma_worker.c
> index ad29d5dab..d21cdb5f6 100644
> --- a/kernel/drivers/net/stack/rtmac/tdma/tdma_worker.c
> +++ b/kernel/drivers/net/stack/rtmac/tdma/tdma_worker.c
> @@ -189,7 +189,9 @@ void tdma_worker(void *arg)
>  switch (job->id) {
>  case WAIT_ON_SYNC:
>  rtdm_lock_put_irqrestore(>lock, lockctx);
> -rtdm_event_wait(>sync_event);
> +ret = rtdm_event_wait(>sync_event);
> + if (ret == -EIDRM)
> + return;
>  rtdm_lock_get_irqsave(>lock, lockctx);
>  break;

Well, regression of bd971c3a9624: TDMA_FLAG_SHUTDOWN was set before in
order to break the loop without that check. But doing the above is also
fine.

> 
> AFAIU, the cancellation request is issued on behalf of a regular linux
> context calling a discipline detach handler, which originally led to the
> following sequence with v2:
> 
> [detach_handler] xnsynch_destroy(_event)
>xnsynch_flush(_event, XNRMID)
>release event resources
> [tdma_worker]back from rtdm_event_wait() => -ERMID
> [tdma_worker]back sleeping on rtdm_event_wait()
> [detach_handler] rtdm_task_destroy(_worker)
>

Re: [Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Greg Gallagher]

Makes sense, after the fact I realized this would diverge from the
mainline structs.  Will fix up and update.

On Thu, Feb 1, 2018 at 5:02 AM, Philippe Gerum  wrote:
> On 01/31/2018 03:28 AM, Greg Gallagher wrote:
>> This patch is based on one that was submitted by Wolfgang Netbal back in Feb
>> 2016 but a formal patch was never submitted.
>> I added a couple small changes (style errors and imx7 define) and tested on a
>> imx7d board. One quick note, the IMX7D define may not really be needed since
>> most imx7 uarts look to be compatible with imx6.
>
> I would drop this additional definition. DT indeed says that imx7d uarts
> can be handled by the i.MX serial driver as imx6q devices, and
> fsl,imx7d-uart is a mere alias to fsl,imx6q-uart AFAICS in the mainline
> tree up to 4.15.
>
> --
> Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH 2/3] Handle device paths from the device tree that start with a forward slash

[Greg Gallagher]

Yep, sorry I thought I removed that. Will update

On Thu, Feb 1, 2018 at 5:29 AM, Philippe Gerum  wrote:
> On 01/31/2018 03:36 AM, Greg Gallagher wrote:
>> If the device name from the device tree starts with a forward slash (/) the
>> rtdm device stores it in the registry including the forward slash.  When we
>> go to use that device and do the registry lookup we use a relative path from
>> /dev/rtdm which doesn't contain the forward slash and fails to find a match.
>> Open won't return an error but IO calls will fail.  To fix this when we
>> register an RTDM device skip the first character if it's a forward slash.
>>
>> In my case the path from the device tree is
>> /amba_pl/gpio@4120/gpio905
>> which gets stored in the registry. When we want to use the device and look up
>> the device path in the registry we use
>> amba_pl/gpio@4120/gpio905
>> which won't find a match in the registry.
>>
>
> Good catch, thanks.
>
>> Tested on Zynq7000 gpio drivers
>> ---
>>  kernel/cobalt/rtdm/device.c | 14 +++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/cobalt/rtdm/device.c b/kernel/cobalt/rtdm/device.c
>> index 4533dfb..89e0815 100644
>> --- a/kernel/cobalt/rtdm/device.c
>> +++ b/kernel/cobalt/rtdm/device.c
>> @@ -91,9 +91,12 @@ struct rtdm_device *__rtdm_get_namedev(const char *path)
>>   if (strncmp(path, "rtdm/", 5) == 0)
>>   path += 5;
>>
>> + printk(KERN_ERR "path to bind %s\n", path);
>
> Debug stuff to remove before merging.
>
> --
> Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH 3/3] Allow for more then one rt gpio driver to be built and loaded at the same build

[Greg Gallagher]

Yes, will fix that

On Thu, Feb 1, 2018 at 5:30 AM, Philippe Gerum  wrote:
> On 01/31/2018 03:36 AM, Greg Gallagher wrote:
>> Some SOCs will have two GPIO chips that require two independent drivers.  In 
>> my
>> case I was working with the Zynq SOC and needed a driver for the gpios on the
>> FPGA and a driver for the gpios available on the ARM core. This change allows
>> for two rt gpio drivers to be built and loaded at the same time.
>> The rt gpio driver will be renamed from xeno-gpio to the following:
>>
>> xeno-gpio-bcm2835.ko
>> xeno-gpio-mxc.ko
>> xeno-gpio-sun8i-h3.ko
>> xeno-gpio-zynq7000.ko
>>
>> This also moves the gpio-core logic into the kernel image.
>> ---
>>  kernel/drivers/gpio/Kconfig   | 12 ++--
>>  kernel/drivers/gpio/Makefile  | 22 --
>>  kernel/drivers/gpio/gpio-xilinx.c |  4 ++--
>>  3 files changed, 20 insertions(+), 18 deletions(-)
>>
>> diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
>> index b7efa54..48475f2 100644
>> --- a/kernel/drivers/gpio/Kconfig
>> +++ b/kernel/drivers/gpio/Kconfig
>> @@ -1,7 +1,7 @@
>>  menu "Real-time GPIO drivers"
>>
>>  config XENO_DRIVERS_GPIO
>> -   tristate "GPIO controller"
>> +   bool "GPIO controller"
>> depends on GPIOLIB
>> help
>>
>> @@ -11,7 +11,7 @@ if XENO_DRIVERS_GPIO
>>
>>  config XENO_DRIVERS_GPIO_BCM2835
>>   depends on MACH_BCM2708 || ARCH_BCM2835
>> - bool "Support for BCM2835 GPIOs"
>> + tristate "Support for BCM2835 GPIOs"
>>   help
>>
>>   Enables support for the GPIO controller available from
>> @@ -19,7 +19,7 @@ config XENO_DRIVERS_GPIO_BCM2835
>>
>>  config XENO_DRIVERS_GPIO_MXC
>>   depends on GPIO_MXC
>> - bool "Support for MXC GPIOs"
>> + tristate "Support for MXC GPIOs"
>>   help
>>
>>   Suitable for the GPIO controller available from
>> @@ -27,7 +27,7 @@ config XENO_DRIVERS_GPIO_MXC
>>
>>  config XENO_DRIVERS_GPIO_SUN8I_H3
>>   depends on MACH_SUN8I && PINCTRL_SUN8I_H3
>> - bool "Support for SUN8I H3 GPIOs"
>> + tristate "Support for SUN8I H3 GPIOs"
>>   help
>>
>>   Suitable for the GPIO controller available from Allwinner's H3
>> @@ -35,7 +35,7 @@ config XENO_DRIVERS_GPIO_SUN8I_H3
>>
>>  config XENO_DRIVERS_GPIO_ZYNQ7000
>>   depends on ARCH_ZYNQ
>> - bool "Support for Zynq7000 GPIOs"
>> + tristate "Support for Zynq7000 GPIOs"
>>   help
>>
>>   Enables support for the GPIO controller available from
>> @@ -43,7 +43,7 @@ config XENO_DRIVERS_GPIO_ZYNQ7000
>>
>>  config XENO_DRIVERS_GPIO_XILINX
>>   depends on ARCH_ZYNQ
>> - bool "Support for Xilinx GPIOs"
>> + tristate "Support for Xilinx GPIOs"
>>   help
>>
>>   Enables support for the GPIO controller available from
>> diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
>> index 3737330..8648fcc 100644
>> --- a/kernel/drivers/gpio/Makefile
>> +++ b/kernel/drivers/gpio/Makefile
>> @@ -1,12 +1,14 @@
>>  ccflags-$(CONFIG_XENO_DRIVERS_GPIO_DEBUG) := -DDEBUG
>>
>> -obj-$(CONFIG_XENO_DRIVERS_GPIO) += xeno_gpio.o
>> -
>> -xeno_gpio-y := gpio-core.o
>> -
>> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += gpio-bcm2835.o
>> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += gpio-mxc.o
>> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += gpio-sun8i-h3.o
>> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += gpio-zynq7000.o
>> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += gpio-xilinx.o
>> -
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += xeno-gpio-bcm2835.o
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += xeno-gpio-mxc.o
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += xeno-gpio-sun8i-h3.o
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += xeno-gpio-zynq7000.o
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += xeno-gpio-xilinx.o
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO) += gpio-core.o
>> +
>> +xeno-gpio-bcm2835-y := gpio-bcm2835.o
>> +xeno-gpio-mxc-y := gpio-mxc.o
>> +xeno-gpio-sun8i-h3-y := gpio-sun8i-h3.o
>> +xeno-gpio-zynq7000-y := gpio-zynq7000.o
>> +xeno-gpio-xilinx-y := gpio-xilinx.o
>
> Ok.
>
>> diff --git a/kernel/drivers/gpio/gpio-xilinx.c 
>> b/kernel/drivers/gpio/gpio-xilinx.c
>> index 72d4364..e982f5f 100644
>> --- a/kernel/drivers/gpio/gpio-xilinx.c
>> +++ b/kernel/drivers/gpio/gpio-xilinx.c
>> @@ -19,13 +19,13 @@
>>   * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, 
>> USA.
>>   */
>>  #include 
>> -#include "gpio-core.h"
>> +#include 
>>
>>  #define RTDM_SUBCLASS_XILINX  5
>>
>>  static int __init xilinx_gpio_init(void)
>>  {
>> - return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a",
>> + return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a",
>>   RTDM_SUBCLASS_XILINX);
>>  }
>>  module_init(xilinx_gpio_init);
>>
>
> Left over from patch #1?
>
> --
> Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH 3/3] Allow for more then one rt gpio driver to be built and loaded at the same build

[Philippe Gerum]

On 01/31/2018 03:36 AM, Greg Gallagher wrote:
> Some SOCs will have two GPIO chips that require two independent drivers.  In 
> my
> case I was working with the Zynq SOC and needed a driver for the gpios on the
> FPGA and a driver for the gpios available on the ARM core. This change allows
> for two rt gpio drivers to be built and loaded at the same time.
> The rt gpio driver will be renamed from xeno-gpio to the following:
> 
> xeno-gpio-bcm2835.ko
> xeno-gpio-mxc.ko
> xeno-gpio-sun8i-h3.ko
> xeno-gpio-zynq7000.ko
> 
> This also moves the gpio-core logic into the kernel image.
> ---
>  kernel/drivers/gpio/Kconfig   | 12 ++--
>  kernel/drivers/gpio/Makefile  | 22 --
>  kernel/drivers/gpio/gpio-xilinx.c |  4 ++--
>  3 files changed, 20 insertions(+), 18 deletions(-)
> 
> diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
> index b7efa54..48475f2 100644
> --- a/kernel/drivers/gpio/Kconfig
> +++ b/kernel/drivers/gpio/Kconfig
> @@ -1,7 +1,7 @@
>  menu "Real-time GPIO drivers"
>  
>  config XENO_DRIVERS_GPIO
> -   tristate "GPIO controller"
> +   bool "GPIO controller"
> depends on GPIOLIB
> help
>  
> @@ -11,7 +11,7 @@ if XENO_DRIVERS_GPIO
>  
>  config XENO_DRIVERS_GPIO_BCM2835
>   depends on MACH_BCM2708 || ARCH_BCM2835
> - bool "Support for BCM2835 GPIOs"
> + tristate "Support for BCM2835 GPIOs"
>   help
>  
>   Enables support for the GPIO controller available from
> @@ -19,7 +19,7 @@ config XENO_DRIVERS_GPIO_BCM2835
>  
>  config XENO_DRIVERS_GPIO_MXC
>   depends on GPIO_MXC
> - bool "Support for MXC GPIOs"
> + tristate "Support for MXC GPIOs"
>   help
>  
>   Suitable for the GPIO controller available from
> @@ -27,7 +27,7 @@ config XENO_DRIVERS_GPIO_MXC
>  
>  config XENO_DRIVERS_GPIO_SUN8I_H3
>   depends on MACH_SUN8I && PINCTRL_SUN8I_H3
> - bool "Support for SUN8I H3 GPIOs"
> + tristate "Support for SUN8I H3 GPIOs"
>   help
>  
>   Suitable for the GPIO controller available from Allwinner's H3
> @@ -35,7 +35,7 @@ config XENO_DRIVERS_GPIO_SUN8I_H3
>  
>  config XENO_DRIVERS_GPIO_ZYNQ7000
>   depends on ARCH_ZYNQ
> - bool "Support for Zynq7000 GPIOs"
> + tristate "Support for Zynq7000 GPIOs"
>   help
>  
>   Enables support for the GPIO controller available from
> @@ -43,7 +43,7 @@ config XENO_DRIVERS_GPIO_ZYNQ7000
>  
>  config XENO_DRIVERS_GPIO_XILINX
>   depends on ARCH_ZYNQ
> - bool "Support for Xilinx GPIOs"
> + tristate "Support for Xilinx GPIOs"
>   help
>  
>   Enables support for the GPIO controller available from
> diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
> index 3737330..8648fcc 100644
> --- a/kernel/drivers/gpio/Makefile
> +++ b/kernel/drivers/gpio/Makefile
> @@ -1,12 +1,14 @@
>  ccflags-$(CONFIG_XENO_DRIVERS_GPIO_DEBUG) := -DDEBUG
>  
> -obj-$(CONFIG_XENO_DRIVERS_GPIO) += xeno_gpio.o
> -
> -xeno_gpio-y := gpio-core.o
> -
> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += gpio-bcm2835.o
> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += gpio-mxc.o
> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += gpio-sun8i-h3.o
> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += gpio-zynq7000.o
> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += gpio-xilinx.o
> -
> +obj-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += xeno-gpio-bcm2835.o
> +obj-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += xeno-gpio-mxc.o
> +obj-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += xeno-gpio-sun8i-h3.o
> +obj-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += xeno-gpio-zynq7000.o
> +obj-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += xeno-gpio-xilinx.o
> +obj-$(CONFIG_XENO_DRIVERS_GPIO) += gpio-core.o
> +
> +xeno-gpio-bcm2835-y := gpio-bcm2835.o
> +xeno-gpio-mxc-y := gpio-mxc.o
> +xeno-gpio-sun8i-h3-y := gpio-sun8i-h3.o
> +xeno-gpio-zynq7000-y := gpio-zynq7000.o
> +xeno-gpio-xilinx-y := gpio-xilinx.o

Ok.

> diff --git a/kernel/drivers/gpio/gpio-xilinx.c 
> b/kernel/drivers/gpio/gpio-xilinx.c
> index 72d4364..e982f5f 100644
> --- a/kernel/drivers/gpio/gpio-xilinx.c
> +++ b/kernel/drivers/gpio/gpio-xilinx.c
> @@ -19,13 +19,13 @@
>   * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
>   */
>  #include 
> -#include "gpio-core.h"
> +#include 
>  
>  #define RTDM_SUBCLASS_XILINX  5
>  
>  static int __init xilinx_gpio_init(void)
>  {
> - return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a",
> + return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a",
>   RTDM_SUBCLASS_XILINX);
>  }
>  module_init(xilinx_gpio_init);
> 

Left over from patch #1?

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH 2/3] Handle device paths from the device tree that start with a forward slash

[Philippe Gerum]

On 01/31/2018 03:36 AM, Greg Gallagher wrote:
> If the device name from the device tree starts with a forward slash (/) the
> rtdm device stores it in the registry including the forward slash.  When we
> go to use that device and do the registry lookup we use a relative path from
> /dev/rtdm which doesn't contain the forward slash and fails to find a match.
> Open won't return an error but IO calls will fail.  To fix this when we
> register an RTDM device skip the first character if it's a forward slash.
> 
> In my case the path from the device tree is
> /amba_pl/gpio@4120/gpio905
> which gets stored in the registry. When we want to use the device and look up
> the device path in the registry we use
> amba_pl/gpio@4120/gpio905
> which won't find a match in the registry.
> 

Good catch, thanks.

> Tested on Zynq7000 gpio drivers
> ---
>  kernel/cobalt/rtdm/device.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/cobalt/rtdm/device.c b/kernel/cobalt/rtdm/device.c
> index 4533dfb..89e0815 100644
> --- a/kernel/cobalt/rtdm/device.c
> +++ b/kernel/cobalt/rtdm/device.c
> @@ -91,9 +91,12 @@ struct rtdm_device *__rtdm_get_namedev(const char *path)
>   if (strncmp(path, "rtdm/", 5) == 0)
>   path += 5;
>  
> + printk(KERN_ERR "path to bind %s\n", path);

Debug stuff to remove before merging.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH 1/3] Add Xilinx AXI gpio driver

[Philippe Gerum]

On 01/31/2018 03:36 AM, Greg Gallagher wrote:
> ---
>  kernel/drivers/gpio/Kconfig   | 10 +-
>  kernel/drivers/gpio/Makefile  |  3 ++-
>  kernel/drivers/gpio/gpio-xilinx.c | 40 
> +++
>  3 files changed, 51 insertions(+), 2 deletions(-)

[snip]

> diff --git a/kernel/drivers/gpio/gpio-xilinx.c 
> b/kernel/drivers/gpio/gpio-xilinx.c
> new file mode 100644
> index 000..72d4364
> --- /dev/null
> +++ b/kernel/drivers/gpio/gpio-xilinx.c
> @@ -0,0 +1,40 @@
> +/**
> + * @note Copyright (C) 2017 Greg Gallagher 
> + *
> + * This driver controls the gpio that can be located on the PL
> + * of the Zynq SOC
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + */
> +#include 
> +#include "gpio-core.h"
> +

The change below is required for this driver to build since recently,
due to moving gpio-core.h to a public header containing the generic GPIO
bits some client drivers may need. Other than that, this looks ok.

diff --git a/kernel/drivers/gpio/gpio-xilinx.c
b/kernel/drivers/gpio/gpio-xilinx.c
index 72d436435..cae88b62f 100644
--- a/kernel/drivers/gpio/gpio-xilinx.c
+++ b/kernel/drivers/gpio/gpio-xilinx.c
@@ -19,7 +19,7 @@
  * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.
  */
 #include 
-#include "gpio-core.h"
+#include 

 #define RTDM_SUBCLASS_XILINX  5

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Philippe Gerum]

On 01/31/2018 03:28 AM, Greg Gallagher wrote:
> This patch is based on one that was submitted by Wolfgang Netbal back in Feb
> 2016 but a formal patch was never submitted.
> I added a couple small changes (style errors and imx7 define) and tested on a
> imx7d board. One quick note, the IMX7D define may not really be needed since
> most imx7 uarts look to be compatible with imx6.

I would drop this additional definition. DT indeed says that imx7d uarts
can be handled by the i.MX serial driver as imx6q devices, and
fsl,imx7d-uart is a mere alias to fsl,imx6q-uart AFAICS in the mainline
tree up to 4.15.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai