* Re: [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) [not found] <mailman.117.1496166485.4225.xenomai@xenomai.org> @ 2017-05-30 18:02 ` Nitin Kulkarni 2017-05-31 7:16 ` Philippe Gerum 0 siblings, 1 reply; 10+ messages in thread From: Nitin Kulkarni @ 2017-05-30 18:02 UTC (permalink / raw) To: xenomai Hi Philippe, >From your reply I guess its the same issue with my SoC also. Do you think in my case the Intel joule pinctrl driver is not aware of Ipipe ? Do you have any instances where an x86 based SoC was ported to solve this issue ? Thanks for the info it explains a lot of things now. - Nitin ________________________________________ From: Xenomai <xenomai-bounces@xenomai.org> on behalf of xenomai-request@xenomai.org <xenomai-request@xenomai.org> Sent: Tuesday, May 30, 2017 7:48 PM To: xenomai@xenomai.org Subject: Xenomai Digest, Vol 61, Issue 25 Send Xenomai mailing list submissions to xenomai@xenomai.org To subscribe or unsubscribe via the World Wide Web, visit https://xenomai.org/mailman/listinfo/xenomai or, via email, send a message with subject or body 'help' to xenomai-request@xenomai.org You can reach the person managing the list at xenomai-owner@xenomai.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Xenomai digest..." Today's Topics: 1. Re: problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) (Philippe Gerum) 2. Re: problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) (Nitin Kulkarni) ---------------------------------------------------------------------- Message: 1 Date: Tue, 30 May 2017 19:30:58 +0200 From: Philippe Gerum <rpm@xenomai.org> To: Harco Kuppens <h.kuppens@cs.ru.nl>, xenomai@xenomai.org Subject: Re: [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) Message-ID: <cb912c40-1247-6395-9a84-a3203dd5f022@xenomai.org> Content-Type: text/plain; charset=utf-8 On 05/30/2017 06:38 PM, Harco Kuppens wrote: > So I decided to also test these wiringpi test programs on mine build > xenomai 3 image for the rpi2. Unfortunately the isr.c wiringpi program > didn't work anymore on mine build image. So even without using xenomai3, > but just using linux the pi2 just hangs and a hard reset was needed. > > Thus I guess there is still something wrong with mine image? > Does anybody know what I'm doing wrong? > Or is this still a bug in the gpio library or in the patches applied? > It looks obvious that you tried hard and got your feet wet with Xenomai already, so let's go straight to the point: the lockup issue when using GPIO interrupts is most likely due to the I-pipe patch not properly adapting the GPIO chip driver for dealing with IRQ virtualization. In short, each IRQ controller which may be active on a SoC must be driven by I-pipe aware code. For instance, the bcm2835 family has common GPIOs controlled by the driver at drivers/pinctrl/pinctrl-bcm2835.c. If that driver has not been patched specifically for supporting the IRQ pipeline, then this won't work with Xenomai, and may well end up with painful IRQ storms causing a machine hang. The same goes for any other chip serving as an IRQ controller you might need on your platform. So, first and foremost, I would recommend to make sure the I-pipe code is right for your kernel, then build on top of that. A good way to figure out which IRQ controllers are active is look at the output of /proc/interrupts on a kernel that disables the interrupt pipeline. Each IRQ information mentions the label of the controller which deals with it. With that information, you need to cross-check whether the corresponding IRQ chip driver (the one that bears this label in the irq_chip descriptor structure) was made I-pipe aware. Some time ago, I ported Xenomai 3 to the PI Zero (kernel 4.1.18), which is based on the bcm2835 SoC like the PI 1 series. That code is available from the vendors/raspberry/ipipe-4.1 branch at git://git.xenomai.org/ipipe.git. This may be a good starting point, at least for testing with a PI 1, before working on the required fixups for supporting other Broadcom SoCs. IIRC, RPI 2B and RPI 3 are based on the bcm2836, bcm2837 SoCs resp., which are not covered by the port just mentioned. You may find some preliminary I-pipe related changes in the bcm2836 core interrupt support code, but those have never been tested. By preliminary, I mean that there is likely a few more IRQ controllers to make I-pipe aware on these SoCs, aside of testing the initial changes. Bottom line: using a stock I-pipe patch is unlikely to work out of the box. The fact that such patch does support several SoCs equipped with Cortex A7/A9 CPUs is by no mean a guarantee that all Cortex-based SoCs are supported by the same code. -- Philippe. ------------------------------ Message: 2 Date: Tue, 30 May 2017 17:47:58 +0000 From: Nitin Kulkarni <nitink@kth.se> To: "xenomai@xenomai.org" <xenomai@xenomai.org>, "h.kuppens@cs.ru.nl" <h.kuppens@cs.ru.nl> Subject: Re: [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) Message-ID: <1496166479457.35714@kth.se> Content-Type: text/plain; charset="iso-8859-1" Hi Harco, Even I have a similar issue which I posted yesterday. Subject was "GPIO Interrupt is registered in Xenomai but handler is not invoked when triggered". In my case I am not using an Intel Joule module. I have searched a bit and I think its an issue with the ipipe patch and GPIO irq handling. My rtdm irq is registered and it shows in the /proc/xenomai/irq file but it is not triggered. I am waiting for someone to reply, I am sure I missing something here or its an issue with few of the GPIO drivers not being aware of Ipipe. @Others: If you have experienced similar issues please let me know. -Nitin ________________________________________ From: Xenomai <xenomai-bounces@xenomai.org> on behalf of xenomai-request@xenomai.org <xenomai-request@xenomai.org> Sent: Tuesday, May 30, 2017 6:38 PM To: xenomai@xenomai.org Subject: Xenomai Digest, Vol 61, Issue 24 Send Xenomai mailing list submissions to xenomai@xenomai.org To subscribe or unsubscribe via the World Wide Web, visit https://xenomai.org/mailman/listinfo/xenomai or, via email, send a message with subject or body 'help' to xenomai-request@xenomai.org You can reach the person managing the list at xenomai-owner@xenomai.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Xenomai digest..." Today's Topics: 1. Re: dlopen failing when using shared library on xenomai 3.0.4 (Fyleo) 2. Re: dlopen failing when using shared library on xenomai 3.0.4 (Fyleo) 3. Re: dlopen failing when using shared library on xenomai 3.0.4 (Philippe Gerum) 4. vortex86dx (ali hagigat) 5. Re: Problem with the T_LOCK (Philippe Gerum) 6. problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) (Harco Kuppens) ---------------------------------------------------------------------- Message: 1 Date: Tue, 30 May 2017 12:17:59 +0200 From: Fyleo <fyleo45@gmail.com> To: xenomai@xenomai.org Subject: Re: [Xenomai] dlopen failing when using shared library on xenomai 3.0.4 Message-ID: <bbc4317c-2238-b9f1-0e4d-10a683618af8@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed > Le 29/05/2017 ? 23:19, Fyleo a ?crit : >> Hello all, >> >> I'm trying to port machinekit (machinekit.io) to xenomai 3.0.4 which >> support only xenomai 2.6.4 for the moment. >> >> This software is design this way : >> >> A : main executable >> >> B : shared library abstracting thread API, with one library for >> posix, for xenomai, ... >> >> The xenomai B library is linked against alchemy, copperplate, ... >> (xeno-config --ldflags --auto-init-solib --skin=alchemy) >> >> The program works in a way that, at start time, it load with dlopen >> the configured API (B). >> >> My problem is that dlopen(with RTLD_GLOBAL|RTLD_NOW) fail with the >> error : "/usr/lib/libcopperplate.so.0: undefined symbol: main" >> >> Here is the simplified test case to reproduce the problem : >> >> main.c: >> #include <stdio.h> >> #include <stdlib.h> >> #include <dlfcn.h> >> >> int main(int argc, char *const argv[]) >> { >> void *handle; >> >> handle = dlopen("./ulapi-xenomai.so", RTLD_GLOBAL|RTLD_NOW); >> if (!handle) { >> fprintf(stderr, "%s\n", dlerror()); >> exit(EXIT_FAILURE); >> } >> >> dlclose(handle); >> exit(EXIT_SUCCESS); >> } >> >> gcc main.c -o testcase -ldl >> gcc -Wl,-soname,ulapi-xenomai.so -shared -o ulapi-xenomai.so >> `xeno-config --ldflags --auto-init-solib --skin=alchemy` >> >> run testcase >> >> I am missing something or is there a solution that doesn't imply to >> use RTLD_LAZY ? >> >> my xeno-config --info >> Xenomai version: Xenomai/cobalt v3.0.4 >> Linux beaglebone 4.4.62-ti-xenomai-r105 #1 SMP Wed May 24 00:09:09 >> UTC 2017 armv7l GNU/Linux >> Kernel parameters: console=ttyO0,115200n8 >> capemgr.disable_partno=BB-BONELT-HDMI >> bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro >> rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet >> I-pipe release #7 detected >> Cobalt core 3.0.4 detected >> Compiler: gcc version 4.9.2 (Debian 4.9.2-10) >> Build args: --prefix=/usr --includedir=/usr/include/xenomai >> --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite >> --enable-dlopen-libs --enable-smp --build arm-linux-gnueabihf >> build_alias=arm-linux-gnueabihf >> >> Regards, >> >> Fyleo >> >> _______________________________________________ >> Xenomai mailing list >> Xenomai@xenomai.org >> https://xenomai.org/mailman/listinfo/xenomai On 30/05/2017 09:22, St?phane Ancelot wrote: > Hi, > > Why don't you link the shared lib at compilation ? > > Regards, > S.Ancelot Hi, Because there is multiple ulapi that can be loaded at execution time to switch between posix (non-xenomai) thread, xenomai thread, rtai thread and so on, depending on environnement variable. It is not my program so i want to be less invasive as possible. Regards, Fyleo ------------------------------ Message: 2 Date: Tue, 30 May 2017 12:23:01 +0200 From: Fyleo <fyleo45@gmail.com> To: Philippe Gerum <rpm@xenomai.org>, xenomai@xenomai.org Subject: Re: [Xenomai] dlopen failing when using shared library on xenomai 3.0.4 Message-ID: <90600d56-7dfa-7726-f25b-d9301a915820@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed On 30/05/2017 09:12, Philippe Gerum wrote: > On 05/29/2017 11:19 PM, Fyleo wrote: >> Hello all, >> >> I'm trying to port machinekit (machinekit.io) to xenomai 3.0.4 which >> support only xenomai 2.6.4 for the moment. >> >> This software is design this way : >> >> A : main executable >> >> B : shared library abstracting thread API, with one library for posix, >> for xenomai, ... >> >> The xenomai B library is linked against alchemy, copperplate, ... >> (xeno-config --ldflags --auto-init-solib --skin=alchemy) >> >> The program works in a way that, at start time, it load with dlopen the >> configured API (B). >> >> My problem is that dlopen(with RTLD_GLOBAL|RTLD_NOW) fail with the error >> : "/usr/lib/libcopperplate.so.0: undefined symbol: main" >> > Could you pick the change below and retry? Feedback welcome. > > http://git.xenomai.org/xenomai-3.git/commit/?id=48b2e57e29ca1c33eba14abb4b5eaa15431130fa > Hi, This fix works, thanks. But will it always work in executable auto init ? The symbol "__real_main" have to be defined in user code if linked with bootstrap.o ? Fyleo ------------------------------ Message: 3 Date: Tue, 30 May 2017 12:39:46 +0200 From: Philippe Gerum <rpm@xenomai.org> To: Fyleo <fyleo45@gmail.com>, xenomai@xenomai.org Subject: Re: [Xenomai] dlopen failing when using shared library on xenomai 3.0.4 Message-ID: <5f442ab6-0cf8-2c5d-bfca-53a0c2fa5ecd@xenomai.org> Content-Type: text/plain; charset=utf-8 On 05/30/2017 12:23 PM, Fyleo wrote: > On 30/05/2017 09:12, Philippe Gerum wrote: >> On 05/29/2017 11:19 PM, Fyleo wrote: >>> Hello all, >>> >>> I'm trying to port machinekit (machinekit.io) to xenomai 3.0.4 which >>> support only xenomai 2.6.4 for the moment. >>> >>> This software is design this way : >>> >>> A : main executable >>> >>> B : shared library abstracting thread API, with one library for posix, >>> for xenomai, ... >>> >>> The xenomai B library is linked against alchemy, copperplate, ... >>> (xeno-config --ldflags --auto-init-solib --skin=alchemy) >>> >>> The program works in a way that, at start time, it load with dlopen the >>> configured API (B). >>> >>> My problem is that dlopen(with RTLD_GLOBAL|RTLD_NOW) fail with the error >>> : "/usr/lib/libcopperplate.so.0: undefined symbol: main" >>> >> Could you pick the change below and retry? Feedback welcome. >> >> http://git.xenomai.org/xenomai-3.git/commit/?id=48b2e57e29ca1c33eba14abb4b5eaa15431130fa >> >> > Hi, > > This fix works, thanks. > > But will it always work in executable auto init ? The symbol > "__real_main" have to be defined in user code if linked with bootstrap.o ? > __real_main() stands for the actual main as generated by the linker when the auto-bootstrap feature is in effect (i.e. --wrap=main --dynamic-list=...), and bootstrap.o is glued to executables/DSOs only in such a case. IOW, __real_main() is guaranteed to exist if bootstrap.o is part of the binary image. So yes, we should be safe. This change has been tested with the alchemy testsuite which is copperplate-based, a C++ application enabling auto-init-solib, and Xenomai's base utility programs enabling the auto-bootstrap, so far so good. -- Philippe. ------------------------------ Message: 4 Date: Tue, 30 May 2017 17:32:09 +0430 From: ali hagigat <hagigatali@gmail.com> To: xenomai@xenomai.org Subject: [Xenomai] vortex86dx Message-ID: <CAKKWdtfpTs1O5b-ihm2JP8vSm7KxZn7YAaOGO6Zy3H7we=SAYw@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" I use xenomai for vortex86dx and cpc307 board. the kernel hangs. why? Linux version 2.6.30 (am@localhost.localdomain) (gcc version 4.9.3 (Buildroot 2016.05) ) #6 Tue May 30 12:41:26 IRDT 2017 KERNEL supported cpus:************************************** Intel GenuineIntel* Please select boot device: * AMD AuthenticAMD **************************************** NSC Geode by NSC * HDD:PM-Fastwel Embedded ATA Fla * Cyrix CyrixInstead* USB:JetFlash Transcend * Centaur CentaurHauls<Enter Setup> * Transmeta GenuineTMx86 * Transmeta TransmetaCPU * UMC UMC UMC UMC * * CPU: vendor_id 'Vortex86 SoC' unknown, using generic init. * CPU: Your system may be unstable. * BIOS-provided physical RAM map:***************************** BIOS-e820: 0000000000000000 - 000000000009a000 (usable) * BIOS-e820: 000000000009a000 - 00000000000a0000 (reserved) * BIOS-e820: 00000000000efff0 - 0000000000100000 (reserved) * BIOS-e820: 0000000000100000 - 0000000010000000 (usable)**** BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) DMI not present or invalid. last_pfn = 0x10000 max_arch_pfn = 0x100000 init_memory_mapping: 0000000000000000-0000000010000000 256MB LOWMEM available. mapped low ram: 0 - 100000004 bytes nvram low ram: 0 - 10000000 interface driver hiddev node 0 low ram: 00000000 - 10000000ver usbhid node 0 bootmap 00001000 - 00003000 (6 early reservations) ==> bootmem [0000000000 - 0010000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] #1 [0000100000 - 000043e824] TEXT DATA BSS ==> [0000100000 - 000043e824] #2 [000009a000 - 0000100000] BIOS reserved ==> [000009a000 - 0000100000] #3 [000043f000 - 0000441000] BRK ==> [000043f000 - 0000441000]4) #4 [0000007000 - 0000045000] PGTABLE ==> [0000007000 - 0000045000] #5 [0000001000 - 0000003000] BOOTMAP ==> [0000001000 - 0000003000] Zone PFN ranges:correct "root=" boot option; here are the available partitions: DMA 0x00000000 -> 0x00001000e-gd Normal 0x00001000 -> 0x00010000 Movable zone start PFN for each node early_node_map[2] active PFN rangesable to mount root fs on unknown-block(0,0) 0: 0x00000000 -> 0x0000009aed 2.6.30 #5 0: 0x00000100 -> 0x00010000 Allocating PCI resources starting at 20000000 (gap: 10000000:ef000000) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64922 Kernel command line: root=/dev/sda2 nosmp tsc=reliable rootdelay=15 rw console=ttyS0,115200n8 init=/bin/busybox init BOOT_IMAGE=bzima Initializing CPU#0t_root+0x4f/0x57 Experimental hierarchical RCU implementation. Experimental hierarchical RCU init done. NR_IRQS:167>] ? kernel_init+0x0/0xb2 PID hash table entries: 1024 (order: 10, 4096 bytes) Fast TSC calibration using PIT Detected 599.908 MHz processor. I-pipe 2.4-05: pipeline enabled. Console: colour dummy device 80x25 console [ttyS0] enabled Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255720k/262144k available (2056k kernel code, 5832k reserved, 873k data, 188k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffeb000 - 0xfffff000 ( 80 kB) vmalloc : 0xd0800000 - 0xfffe9000 ( 759 MB) lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) .init : 0xc03e0000 - 0xc040f000 ( 188 kB) .data : 0xc030224b - 0xc03dc85c ( 873 kB) .text : 0xc0100000 - 0xc030224b (2056 kB) Checking if this processor honours the WP bit even in supervisor mode...Ok. Calibrating delay loop (skipped), value calculated using timer frequency.. 1199.81 BogoMIPS (lpj=5999080) Mount-cache hash table entries: 512 CPU: Vortex86 SoC 05/02 stepping 02 Checking 'hlt' instruction... OK. net_namespace: 296 bytes NET: Registered protocol family 16 PCI: Using configuration type 1 for base access bio: create slab <bio-0> at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Probing PCI hardware pci 0000:00:07.0: default IRQ router [17f3:6031] NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered NET: Registered protocol family 1 platform rtc_cmos: registered platform RTC device (no PNP device found) I-pipe: Domain Xenomai registered. Xenomai: hal/i386 started. Xenomai: scheduling class idle registered. Xenomai: scheduling class rt registered. Xenomai: real-time nucleus v2.6.5 (Lost in a Memory) loaded. Xenomai: debug mode enabled. Xenomai: starting native API services. Xenomai: starting POSIX services. Xenomai: starting RTDM services. Installing knfsd (copyright (C) 1996 okir@monad.swb.de). msgmni has been set to 499 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered (default) isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Serial: 8250/16550 driver, 12 ports, IRQ sharing enabled ?serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A serial8250: ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A serial8250: ttyS3 at I/O 0x2e8 (irq = 3) is a 16550A brd: module loaded loop: module loaded usbcore: registered new interface driver ub Uniform Multi-Platform E-IDE driver piix 0000:00:0c.0: IDE controller (0x17f3:0x1011 rev 0x01) PIIX_IDE 0000:00:0c.0: guessed PCI INT A -> IRQ 14 piix 0000:00:0c.0: IDE port disabled piix 0000:00:0c.0: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xfb00-0xfb07 hda: Fastwel Embedded ATA Flash Disk, ATA DISK drive ------------------------------ Message: 5 Date: Tue, 30 May 2017 17:04:23 +0200 From: Philippe Gerum <rpm@xenomai.org> To: Aur?lien Le Floc'h <le.floch.aurelien94@gmail.com>, xenomai@xenomai.org Subject: Re: [Xenomai] Problem with the T_LOCK Message-ID: <f8e492cb-9b0a-ff9b-da48-5cd86a27ccb1@xenomai.org> Content-Type: text/plain; charset=utf-8 On 05/22/2017 05:45 PM, Aur?lien Le Floc'h wrote: > Hello everyone, > > > I am working on task priority with Xenomai. I am trying to create some > example of preemption depending on the task priority. For now I have > some example which works thanks to new patch on Xenomai-3.0.5. To work > on this example I work on a single core hardware (in my case a > Raspberry Pi B+) which runs Xenomai 3 generated by Buildroot. > > On all this program you have one father thread which creates two > childrens threads (child1 and child2). We are on a single core so two > thread can?t run at the same time. In this configuration it is > possible to provide an order of apparition of my printf. To execute > all my program the priority order to give in entry is ./Program_name > prio_thread_father prio_thread_child1 prio_thread_child2 > > > In this program (attached in this email) I am trying to use the T_LOCK > in rt_task_create. My goal is to create the thread_father with T_LOCK > the child1 and child2 with T_JOINABLE. > The goal is that the father is always terminating before the child > even if his priority is lower than the child. > > For example if prio_father < prio_child2 < prio_child1 this is the output > Entry in task_father! > End of task_father! > Entry in task_child2! > Entry in task_child1! > > Now the output is like this : > DEBUG > Entry in task_father! > Entry in task_child1! > Entry in task_child2! > End of task_father! > > It's seems that the T_LOCK argument in rt_task_create has no effect > and only the priority keeps the effect. I try to lock the scheduler > with mutex and it's work. But my goal is to have the same result with > T_LOCK. > Do you have some advices ? > This pattern cannot work. As part of the start up protocol for a thread, the parent explicitly blocks waiting for the child to handshake internally, as explained earlier. A thread that blocks relinquishes the scheduler lock while it sleeps. My advice would be to forget about T_LOCK, this turns out to be error-prone, especially in complex applications, not to speak of the performance issue. If you really need some kind of thread factory, explicit synchronization (sems, condvars) is a better option. Besides, I would recommend to stick with POSIX if using the alchemy API is not a requirement. -- Philippe. ------------------------------ Message: 6 Date: Tue, 30 May 2017 18:38:30 +0200 From: Harco Kuppens <h.kuppens@cs.ru.nl> To: xenomai@xenomai.org Subject: [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) Message-ID: <46850988-a862-b747-f11d-1191f7e13458@cs.ru.nl> Content-Type: text/plain; charset=utf-8; format=flowed note: all resources referred to in this email can be found in the public repository at https://github.com/harcokuppens/xenomai3_rpi2_gpio/ At the Radboud University Nijmegen we are already succesfully using xenomai 2 for several years in a course about embedded systems. Currently we are using old intel pc's which need to be replaced. The idea is to replace them with the raspberry pi2 or pi3. We already managed to get xenomai2 to work on the raspberry pi1 but installing xenomai3 seems problematic and is becoming replace with the pi2 and pi3, so we deciced to go for the pi2 or pi3. We found on the internet several descriptions pages which describe how to install xenomai on a raspberry pi2/3. An overview of these links can be found at : https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/install/overview_xenomai3_installations_found_online.txt note: some instructions are in japanese or french but with the help of google translate they are easy to read. I managed to install xenomai3 on the rpi2, you can find mine installation instructions at : https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/install/install_xenomai-3-3.0.5_on_rpi2.txt Everything seems fine except for the interrupt handling! In https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/circuit/button_toggles_led.png is displayed the electronic circuit I build to do my tests. It consists of two simple circuits : 1. led circuit : https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/circuit/led.png 2. pullup circuit with a switch to trigger an interrupt : https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/circuit/pullup.png I tried both a xenomai program in user space and kernel space (gpiotest). In user space the pi just hangs, and I need a hard reboot. In kernel space no interrupt happens at all. Maybe I do something wrong in kernel space. At some point I was afraid that maybe my pi was broke, so I installed the standard raspbian image, which is just linux, and runned some interrupt test program within linux in userspace using the wiringpi library. These programs just worked fine. My pi2 wasn't broken :) You can find the programs at : https://github.com/harcokuppens/xenomai3_rpi2_gpio/tree/master/examples/wiringpi_examples/ So I decided to also test these wiringpi test programs on mine build xenomai 3 image for the rpi2. Unfortunately the isr.c wiringpi program didn't work anymore on mine build image. So even without using xenomai3, but just using linux the pi2 just hangs and a hard reset was needed. Thus I guess there is still something wrong with mine image? Does anybody know what I'm doing wrong? Or is this still a bug in the gpio library or in the patches applied? Hope someone can help me, so that we can switch to xenomai3 on the rpi2/3 in the course next semester. Best regards, Harco Kuppens ps. there is a newer version of the rpi2 called v1.2 which has the same cpu as the rpi3. But if the problem can be solved for the pi3 I'm also very happy. I tried the same procedure for the pi3 based on the instructions linked in https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/install/overview_xenomai3_installations_found_online.txt ------------------------------ Subject: Digest Footer _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai ------------------------------ End of Xenomai Digest, Vol 61, Issue 24 *************************************** ------------------------------ Subject: Digest Footer _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai ------------------------------ End of Xenomai Digest, Vol 61, Issue 25 *************************************** ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) 2017-05-30 18:02 ` [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) Nitin Kulkarni @ 2017-05-31 7:16 ` Philippe Gerum 2017-05-31 10:34 ` Nitin Kulkarni 0 siblings, 1 reply; 10+ messages in thread From: Philippe Gerum @ 2017-05-31 7:16 UTC (permalink / raw) To: Nitin Kulkarni, xenomai On 05/30/2017 08:02 PM, Nitin Kulkarni wrote: > Hi Philippe, >>From your reply I guess its the same issue with my SoC also. Do you think in my case the Intel joule pinctrl driver is not aware of Ipipe ? > Do you have any instances where an x86 based SoC was ported to solve this issue ? > Thanks for the info it explains a lot of things now. What is the output of /proc/interrupts on your board? -- Philippe. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) 2017-05-31 7:16 ` Philippe Gerum @ 2017-05-31 10:34 ` Nitin Kulkarni 2017-06-01 7:11 ` Philippe Gerum 0 siblings, 1 reply; 10+ messages in thread From: Nitin Kulkarni @ 2017-05-31 10:34 UTC (permalink / raw) To: Philippe Gerum, xenomai This is the output from /proc/interrupts (Note: irq 300 is the one I have requested ) root@intel-corei7-64:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 84 0 0 0 IO-APIC 2-edge timer 3: 7666 0 0 0 IO-APIC 3-fasteoi mmc0 4: 0 0 0 0 IO-APIC 4-fasteoi idma64.7 5: 0 0 0 0 IO-APIC 5-fasteoi idma64.8 6: 1276 0 0 0 IO-APIC 6-fasteoi serial 8: 1 0 0 0 IO-APIC 8-fasteoi rtc0 9: 39 0 0 0 IO-APIC 9-fasteoi acpi 14: 0 0 0 0 IO-APIC 14-fasteoi INT34D1:00, INT34D1:01, INT34D1:02, INT34D1:03, INT34D1:04 27: 70 0 0 0 IO-APIC 27-fasteoi idma64.0, i2c_designware.0 28: 0 0 0 0 IO-APIC 28-fasteoi idma64.1, i2c_designware.1 29: 0 0 0 0 IO-APIC 29-fasteoi idma64.2, i2c_designware.2 30: 0 0 0 0 IO-APIC 30-fasteoi idma64.3, i2c_designware.3 31: 0 0 0 0 IO-APIC 31-fasteoi idma64.4, i2c_designware.4 33: 0 0 0 0 IO-APIC 33-fasteoi idma64.5, i2c_designware.5 34: 0 0 0 0 IO-APIC 34-fasteoi idma64.6, i2c_designware.6 35: 0 0 0 0 IO-APIC 35-fasteoi idma64.11, pxa2xx-spi.11 36: 0 0 0 0 IO-APIC 36-fasteoi idma64.12, pxa2xx-spi.12 37: 0 0 0 0 IO-APIC 37-fasteoi idma64.13, pxa2xx-spi.13 39: 1483 0 0 0 IO-APIC 39-fasteoi mmc1 40: 1141 0 0 0 IO-APIC 40-fasteoi intel_pmc_ipc 41: 1 0 0 0 IO-APIC 41-fasteoi bxtwc_irq_chip, bxtwc_irq_chip_level2, bxtwc_irq_chip_tmu 120: 1 0 0 0 PCI-MSI 327680-edge PCIe PME 121: 4838 0 0 0 PCI-MSI 344064-edge xhci_hcd 122: 31 0 0 0 PCI-MSI 245760-edge mei_me 142: 0 0 0 0 intel-gpio 19 bq25890_irq 300: 0 0 0 0 intel-gpio 22 test_interrupt 371: 31 0 0 0 PCI-MSI 32768-edge i915 372: 1525 0 0 0 PCI-MSI 524288-edge iwlwifi 373: 0 0 0 0 bxtwc_irq_chip_level2 0 pmic_thermal 374: 0 0 0 0 bxtwc_irq_chip_level2 1 pmic_thermal 375: 0 0 0 0 bxtwc_irq_chip_level2 2 pmic_thermal 383: 1 0 0 0 Whiskey Cove 7 ACPI:Event 470: 1 0 0 0 bxtwc_irq_chip_level2 7 bxt_wcove_gpio 471: 1 0 0 0 bxtwc_irq_chip_level2 5 wcove_typec 472: 0 0 0 0 bxtwc_irq_chip_tmu 10 bxt_wcove_tmu 473: 69 0 0 0 PCI-MSI 229376-edge snd_hda_intel NMI: 0 0 0 0 Non-maskable interrupts LOC: 12420 8239 7278 6081 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 0 0 0 0 IRQ work interrupts RTR: 0 0 0 0 APIC ICR read retries RES: 600 558 934 711 Rescheduling interrupts CAL: 142 339 343 348 Function call interrupts TLB: 63 50 75 71 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts DFR: 0 0 0 0 Deferred Error APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 6 6 6 6 Machine check polls ERR: 0 MIS: 2 PIN: 0 0 0 0 Posted-interrupt notification event PIW: 0 0 0 0 Posted-interrupt wakeup event ________________________________________ From: Philippe Gerum <rpm@xenomai.org> Sent: Wednesday, May 31, 2017 9:16 AM To: Nitin Kulkarni; xenomai@xenomai.org Subject: Re: [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) On 05/30/2017 08:02 PM, Nitin Kulkarni wrote: > Hi Philippe, >>From your reply I guess its the same issue with my SoC also. Do you think in my case the Intel joule pinctrl driver is not aware of Ipipe ? > Do you have any instances where an x86 based SoC was ported to solve this issue ? > Thanks for the info it explains a lot of things now. What is the output of /proc/interrupts on your board? -- Philippe. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) 2017-05-31 10:34 ` Nitin Kulkarni @ 2017-06-01 7:11 ` Philippe Gerum [not found] ` <1497222185664.65276@kth.se> 0 siblings, 1 reply; 10+ messages in thread From: Philippe Gerum @ 2017-06-01 7:11 UTC (permalink / raw) To: Nitin Kulkarni, xenomai On 05/31/2017 12:34 PM, Nitin Kulkarni wrote: > This is the output from /proc/interrupts (Note: irq 300 is the one I have requested ) > > root@intel-corei7-64:~# cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 [snip] > 142: 0 0 0 0 intel-gpio 19 bq25890_irq > 300: 0 0 0 0 intel-gpio 22 test_interrupt [snip] > 373: 0 0 0 0 bxtwc_irq_chip_level2 0 pmic_thermal > 374: 0 0 0 0 bxtwc_irq_chip_level2 1 pmic_thermal > 375: 0 0 0 0 bxtwc_irq_chip_level2 2 pmic_thermal > 383: 1 0 0 0 Whiskey Cove 7 ACPI:Event > 470: 1 0 0 0 bxtwc_irq_chip_level2 7 bxt_wcove_gpio > 471: 1 0 0 0 bxtwc_irq_chip_level2 5 wcove_typec > 472: 0 0 0 0 bxtwc_irq_chip_tmu 10 bxt_wcove_tmu There are several IRQ chip controllers which are not I-pipe aware on this Soc. The bxtwc and the pin controller allow multiple GPIO modules to sit on the same IRQ vector (IRQF_SHARED), this is not going to work with pipelined interrupts, at least not with the current implementation of the I-pipe patch (at some point in the future this will be the case, but we are not there yet). We can still fix the situation for a single GPIO module per IRQ line though. This is how I would fix up the code for the pin controller driver you are interested in; not tested, not even compiled, just some hints about the way to do it. Until there are fixups for the other drivers (bxtwc abd whiskey cove), you may want to disable them, only to make sure that they won't freak out if/when receiving an interrupt. diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c index 0144376..f8bf54b 100644 --- a/drivers/pinctrl/intel/pinctrl-intel.c +++ b/drivers/pinctrl/intel/pinctrl-intel.c @@ -91,7 +91,11 @@ struct intel_pinctrl_context { */ struct intel_pinctrl { struct device *dev; +#ifdef CONFIG_IPIPE + ipipe_spinlock_t lock; +#else raw_spinlock_t lock; +#endif struct pinctrl_desc pctldesc; struct pinctrl_dev *pctldev; struct gpio_chip chip; @@ -647,15 +651,13 @@ static const struct gpio_chip intel_gpio_chip = { .set = intel_gpio_set, }; -static void intel_gpio_irq_ack(struct irq_data *d) +static void __intel_gpio_irq_ack(struct irq_data *d) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct intel_pinctrl *pctrl = gpiochip_get_data(gc); const struct intel_community *community; unsigned pin = irqd_to_hwirq(d); - raw_spin_lock(&pctrl->lock); - community = intel_get_community(pctrl, pin); if (community) { unsigned padno = pin_to_padno(community, pin); @@ -664,7 +666,14 @@ static void intel_gpio_irq_ack(struct irq_data *d) writel(BIT(gpp_offset), community->regs + GPI_IS + gpp * 4); } +} +static void intel_gpio_irq_ack(struct irq_data *d) +{ + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + + raw_spin_lock(&pctrl->lock); + __intel_gpio_irq_ack(d); raw_spin_unlock(&pctrl->lock); } @@ -694,18 +703,17 @@ static void intel_gpio_irq_enable(struct irq_data *d) writel(value, community->regs + community->ie_offset + gpp * 4); } + ipipe_unlock_irq(d->irq); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); } -static void intel_gpio_irq_mask_unmask(struct irq_data *d, bool mask) +static void __intel_gpio_irq_mask_unmask(struct irq_data *d, bool mask) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct intel_pinctrl *pctrl = gpiochip_get_data(gc); const struct intel_community *community; unsigned pin = irqd_to_hwirq(d); - unsigned long flags; - - raw_spin_lock_irqsave(&pctrl->lock, flags); community = intel_get_community(pctrl, pin); if (community) { @@ -723,20 +731,55 @@ static void intel_gpio_irq_mask_unmask(struct irq_data *d, bool mask) value |= BIT(gpp_offset); writel(value, reg); } - - raw_spin_unlock_irqrestore(&pctrl->lock, flags); } static void intel_gpio_irq_mask(struct irq_data *d) { - intel_gpio_irq_mask_unmask(d, true); + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + + raw_spin_lock_irqsave(&pctrl->lock, flags); + ipipe_lock_irq(d->irq); + __intel_gpio_irq_mask_unmask(d, true); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); } static void intel_gpio_irq_unmask(struct irq_data *d) { - intel_gpio_irq_mask_unmask(d, false); + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + + raw_spin_lock_irqsave(&pctrl->lock, flags); + __intel_gpio_irq_mask_unmask(d, false); + ipipe_unlock_irq(d->irq); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); +} + +#ifdef CONFIG_IPIPE + +static void intel_gpio_irq_hold(struct irq_data *d) +{ + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + + raw_spin_lock_irqsave(&pctrl->lock, flags); + __intel_gpio_irq_mask_unmask(d, true); + __intel_gpio_irq_ack(d); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); +} + +static void intel_gpio_irq_release(struct irq_data *d) +{ + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + + raw_spin_lock_irqsave(&pctrl->lock, flags); + __intel_gpio_irq_mask_unmask(d, false); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); } +#endif + static int intel_gpio_irq_type(struct irq_data *d, unsigned type) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); @@ -837,7 +880,7 @@ static irqreturn_t intel_gpio_community_irq_handler(struct intel_pinctrl *pctrl, irq = irq_find_mapping(gc->irqdomain, community->pin_base + padno); - generic_handle_irq(irq); + ipipe_handle_demuxed_irq(irq); ret |= IRQ_HANDLED; } @@ -862,6 +905,14 @@ static irqreturn_t intel_gpio_irq(int irq, void *data) return ret; } +static void ipipe_irq_cascade(struct irq_desc *desc) +{ +#ifdef CONFIG_IPIPE + intel_gpio_irq(irq_desc_get_irq(desc), + irq_desc_get_handler_data(desc)); +#endif +} + static struct irq_chip intel_gpio_irqchip = { .name = "intel-gpio", .irq_enable = intel_gpio_irq_enable, @@ -870,6 +921,10 @@ static struct irq_chip intel_gpio_irqchip = { .irq_unmask = intel_gpio_irq_unmask, .irq_set_type = intel_gpio_irq_type, .irq_set_wake = intel_gpio_irq_wake, +#ifdef CONFIG_IPIPE + .irq_hold = intel_gpio_irq_hold, + .irq_release = intel_gpio_irq_release, +#endif }; static int intel_gpio_probe(struct intel_pinctrl *pctrl, int irq) @@ -902,12 +957,17 @@ static int intel_gpio_probe(struct intel_pinctrl *pctrl, int irq) * to the irq directly) because on some platforms several GPIO * controllers share the same interrupt line. */ - ret = devm_request_irq(pctrl->dev, irq, intel_gpio_irq, - IRQF_SHARED | IRQF_NO_THREAD, - dev_name(pctrl->dev), pctrl); - if (ret) { - dev_err(pctrl->dev, "failed to request interrupt\n"); - goto fail; + if (IS_ENABLED(CONFIG_IPIPE)) + irq_set_chained_handler_and_data(irq, + ipipe_irq_cascade, pctrl); + else { + ret = devm_request_irq(pctrl->dev, irq, intel_gpio_irq, + IRQF_SHARED | IRQF_NO_THREAD, + dev_name(pctrl->dev), pctrl); + if (ret) { + dev_err(pctrl->dev, "failed to request interrupt\n"); + goto fail; + } } ret = gpiochip_irqchip_add(&pctrl->chip, &intel_gpio_irqchip, 0, -- Philippe. ^ permalink raw reply related [flat|nested] 10+ messages in thread
[parent not found: <1497222185664.65276@kth.se>]
* [Xenomai] Problem with gpio interrupts for xenomai3 on Intel joule [not found] ` <1497222185664.65276@kth.se> @ 2017-06-12 11:02 ` Nitin Kulkarni 2017-06-14 8:27 ` Philippe Gerum 0 siblings, 1 reply; 10+ messages in thread From: Nitin Kulkarni @ 2017-06-12 11:02 UTC (permalink / raw) To: xenomai Hi Philippe, Correcting the subject of this thread and adding it to the mailing list. Thanks for those precise code suggestions. There are two issues. 1. I found that the ipipe_irq_cascade handler is called but the problem is that there are 5 pinctrl devices on this soc and all of them share the same irq line. Hence I see that the intel_gpio_probe() runs for all the 5 pin controllers during kernel initialization and overwrites the irq descriptor with respective pinctrl data each time the probe runs. When the interrupt is triggered ipipe_irq_cascade invoked with the irq desc, I always see that the pinctrl data retrieved from irq_desc using irq_desc_get_handler_data is always the last pinctrl. Hence I do not read the right pinctrl to call intel_gpio_irq() and read the right interrupt enable reg for the gpio pin I enabled as interrupt. 2. When I forced it to read the right pinctrl data by storing that information when intel_gpio_irq_enable is executed. The rtdm handller from my module is executed but the ack call intel_gpio_irq_ack is not called. Hence the irq flags were never cleared and the mmc driver also starts complaining about interrupts not being received. The whole system slows down and virtually hangs. *I tried some fixes* -> I changed the flow handler type from handle_simple_irq to handle_edge_irq while calling gpiochip_irqchip_add() in intel_gpio_probe. -> I called the ack function in ipipe_irq_cascade using the irq_desc which it has. It seems to work perfectly with this fix but this is a raw and a hackish way of doing. I am not sure if this has any consequences. Can you suggest me whats wrong with the ack not being called and how to deal with multiple pinctrl devices sharing the same irq. Regards, Nitin ________________________________________ From: Philippe Gerum <rpm@xenomai.org> Sent: Thursday, June 1, 2017 9:11 AM To: Nitin Kulkarni; xenomai@xenomai.org Subject: Re: [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) On 05/31/2017 12:34 PM, Nitin Kulkarni wrote: > This is the output from /proc/interrupts (Note: irq 300 is the one I have requested ) > > root@intel-corei7-64:~# cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 [snip] > 142: 0 0 0 0 intel-gpio 19 bq25890_irq > 300: 0 0 0 0 intel-gpio 22 test_interrupt [snip] > 373: 0 0 0 0 bxtwc_irq_chip_level2 0 pmic_thermal > 374: 0 0 0 0 bxtwc_irq_chip_level2 1 pmic_thermal > 375: 0 0 0 0 bxtwc_irq_chip_level2 2 pmic_thermal > 383: 1 0 0 0 Whiskey Cove 7 ACPI:Event > 470: 1 0 0 0 bxtwc_irq_chip_level2 7 bxt_wcove_gpio > 471: 1 0 0 0 bxtwc_irq_chip_level2 5 wcove_typec > 472: 0 0 0 0 bxtwc_irq_chip_tmu 10 bxt_wcove_tmu There are several IRQ chip controllers which are not I-pipe aware on this Soc. The bxtwc and the pin controller allow multiple GPIO modules to sit on the same IRQ vector (IRQF_SHARED), this is not going to work with pipelined interrupts, at least not with the current implementation of the I-pipe patch (at some point in the future this will be the case, but we are not there yet). We can still fix the situation for a single GPIO module per IRQ line though. This is how I would fix up the code for the pin controller driver you are interested in; not tested, not even compiled, just some hints about the way to do it. Until there are fixups for the other drivers (bxtwc abd whiskey cove), you may want to disable them, only to make sure that they won't freak out if/when receiving an interrupt. diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c index 0144376..f8bf54b 100644 --- a/drivers/pinctrl/intel/pinctrl-intel.c +++ b/drivers/pinctrl/intel/pinctrl-intel.c @@ -91,7 +91,11 @@ struct intel_pinctrl_context { */ struct intel_pinctrl { struct device *dev; +#ifdef CONFIG_IPIPE + ipipe_spinlock_t lock; +#else raw_spinlock_t lock; +#endif struct pinctrl_desc pctldesc; struct pinctrl_dev *pctldev; struct gpio_chip chip; @@ -647,15 +651,13 @@ static const struct gpio_chip intel_gpio_chip = { .set = intel_gpio_set, }; -static void intel_gpio_irq_ack(struct irq_data *d) +static void __intel_gpio_irq_ack(struct irq_data *d) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct intel_pinctrl *pctrl = gpiochip_get_data(gc); const struct intel_community *community; unsigned pin = irqd_to_hwirq(d); - raw_spin_lock(&pctrl->lock); - community = intel_get_community(pctrl, pin); if (community) { unsigned padno = pin_to_padno(community, pin); @@ -664,7 +666,14 @@ static void intel_gpio_irq_ack(struct irq_data *d) writel(BIT(gpp_offset), community->regs + GPI_IS + gpp * 4); } +} +static void intel_gpio_irq_ack(struct irq_data *d) +{ + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + + raw_spin_lock(&pctrl->lock); + __intel_gpio_irq_ack(d); raw_spin_unlock(&pctrl->lock); } @@ -694,18 +703,17 @@ static void intel_gpio_irq_enable(struct irq_data *d) writel(value, community->regs + community->ie_offset + gpp * 4); } + ipipe_unlock_irq(d->irq); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); } -static void intel_gpio_irq_mask_unmask(struct irq_data *d, bool mask) +static void __intel_gpio_irq_mask_unmask(struct irq_data *d, bool mask) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct intel_pinctrl *pctrl = gpiochip_get_data(gc); const struct intel_community *community; unsigned pin = irqd_to_hwirq(d); - unsigned long flags; - - raw_spin_lock_irqsave(&pctrl->lock, flags); community = intel_get_community(pctrl, pin); if (community) { @@ -723,20 +731,55 @@ static void intel_gpio_irq_mask_unmask(struct irq_data *d, bool mask) value |= BIT(gpp_offset); writel(value, reg); } - - raw_spin_unlock_irqrestore(&pctrl->lock, flags); } static void intel_gpio_irq_mask(struct irq_data *d) { - intel_gpio_irq_mask_unmask(d, true); + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + + raw_spin_lock_irqsave(&pctrl->lock, flags); + ipipe_lock_irq(d->irq); + __intel_gpio_irq_mask_unmask(d, true); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); } static void intel_gpio_irq_unmask(struct irq_data *d) { - intel_gpio_irq_mask_unmask(d, false); + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + + raw_spin_lock_irqsave(&pctrl->lock, flags); + __intel_gpio_irq_mask_unmask(d, false); + ipipe_unlock_irq(d->irq); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); +} + +#ifdef CONFIG_IPIPE + +static void intel_gpio_irq_hold(struct irq_data *d) +{ + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + + raw_spin_lock_irqsave(&pctrl->lock, flags); + __intel_gpio_irq_mask_unmask(d, true); + __intel_gpio_irq_ack(d); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); +} + +static void intel_gpio_irq_release(struct irq_data *d) +{ + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + + raw_spin_lock_irqsave(&pctrl->lock, flags); + __intel_gpio_irq_mask_unmask(d, false); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); } +#endif + static int intel_gpio_irq_type(struct irq_data *d, unsigned type) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); @@ -837,7 +880,7 @@ static irqreturn_t intel_gpio_community_irq_handler(struct intel_pinctrl *pctrl, irq = irq_find_mapping(gc->irqdomain, community->pin_base + padno); - generic_handle_irq(irq); + ipipe_handle_demuxed_irq(irq); ret |= IRQ_HANDLED; } @@ -862,6 +905,14 @@ static irqreturn_t intel_gpio_irq(int irq, void *data) return ret; } +static void ipipe_irq_cascade(struct irq_desc *desc) +{ +#ifdef CONFIG_IPIPE + intel_gpio_irq(irq_desc_get_irq(desc), + irq_desc_get_handler_data(desc)); +#endif +} + static struct irq_chip intel_gpio_irqchip = { .name = "intel-gpio", .irq_enable = intel_gpio_irq_enable, @@ -870,6 +921,10 @@ static struct irq_chip intel_gpio_irqchip = { .irq_unmask = intel_gpio_irq_unmask, .irq_set_type = intel_gpio_irq_type, .irq_set_wake = intel_gpio_irq_wake, +#ifdef CONFIG_IPIPE + .irq_hold = intel_gpio_irq_hold, + .irq_release = intel_gpio_irq_release, +#endif }; static int intel_gpio_probe(struct intel_pinctrl *pctrl, int irq) @@ -902,12 +957,17 @@ static int intel_gpio_probe(struct intel_pinctrl *pctrl, int irq) * to the irq directly) because on some platforms several GPIO * controllers share the same interrupt line. */ - ret = devm_request_irq(pctrl->dev, irq, intel_gpio_irq, - IRQF_SHARED | IRQF_NO_THREAD, - dev_name(pctrl->dev), pctrl); - if (ret) { - dev_err(pctrl->dev, "failed to request interrupt\n"); - goto fail; + if (IS_ENABLED(CONFIG_IPIPE)) + irq_set_chained_handler_and_data(irq, + ipipe_irq_cascade, pctrl); + else { + ret = devm_request_irq(pctrl->dev, irq, intel_gpio_irq, + IRQF_SHARED | IRQF_NO_THREAD, + dev_name(pctrl->dev), pctrl); + if (ret) { + dev_err(pctrl->dev, "failed to request interrupt\n"); + goto fail; + } } ret = gpiochip_irqchip_add(&pctrl->chip, &intel_gpio_irqchip, 0, -- Philippe. ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [Xenomai] Problem with gpio interrupts for xenomai3 on Intel joule 2017-06-12 11:02 ` [Xenomai] Problem with gpio interrupts for xenomai3 on Intel joule Nitin Kulkarni @ 2017-06-14 8:27 ` Philippe Gerum 2017-06-14 12:57 ` Nitin Kulkarni 0 siblings, 1 reply; 10+ messages in thread From: Philippe Gerum @ 2017-06-14 8:27 UTC (permalink / raw) To: Nitin Kulkarni, xenomai On 06/12/2017 01:02 PM, Nitin Kulkarni wrote: > Hi Philippe, > Correcting the subject of this thread and adding it to the mailing list. > Thanks for those precise code suggestions. There are two issues. > > 1. I found that the ipipe_irq_cascade handler is called but the problem is that > there are 5 pinctrl devices on this soc and all of them share the same irq line. Hence I see that the intel_gpio_probe() > runs for all the 5 pin controllers during kernel initialization and overwrites the irq descriptor with respective pinctrl data each time the probe runs. > When the interrupt is triggered ipipe_irq_cascade invoked with the irq desc, I always see that the pinctrl data retrieved from > irq_desc using irq_desc_get_handler_data is always the last pinctrl. Hence I do not read the right pinctrl to call intel_gpio_irq() and read the right interrupt enable reg for the gpio pin I enabled as interrupt. > > 2. When I forced it to read the right pinctrl data by storing that information when intel_gpio_irq_enable is executed. > The rtdm handller from my module is executed but the ack call intel_gpio_irq_ack is not called. Hence the irq flags were never cleared and the mmc driver also starts complaining about interrupts not being received. The whole system slows down and virtually hangs. > > *I tried some fixes* > -> I changed the flow handler type from handle_simple_irq to handle_edge_irq while calling gpiochip_irqchip_add() > in intel_gpio_probe. > -> I called the ack function in ipipe_irq_cascade using the irq_desc which it has. > It seems to work perfectly with this fix but this is a raw and a hackish way of doing. I am not sure if this has any consequences. > Can you suggest me whats wrong with the ack not being called and how to deal with multiple pinctrl devices sharing the same irq. > Please send a patch including your changes; it should be easier to review and comment. -- Philippe. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Problem with gpio interrupts for xenomai3 on Intel joule 2017-06-14 8:27 ` Philippe Gerum @ 2017-06-14 12:57 ` Nitin Kulkarni 2017-06-25 13:59 ` Philippe Gerum 0 siblings, 1 reply; 10+ messages in thread From: Nitin Kulkarni @ 2017-06-14 12:57 UTC (permalink / raw) To: Philippe Gerum, xenomai Major change is use of handle_level_irq flow handler instead of handle_simple_irq & calling the ack function manually in ipipe_irq_cascade. Here is the Patch : diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c index 3b19ef0..4f41532 100644 --- a/drivers/pinctrl/intel/pinctrl-intel.c +++ b/drivers/pinctrl/intel/pinctrl-intel.c @@ -22,6 +22,9 @@ #include <linux/pinctrl/pinmux.h> #include <linux/pinctrl/pinconf.h> #include <linux/pinctrl/pinconf-generic.h> +#include <linux/ipipe.h> #include "pinctrl-intel.h" @@ -65,6 +68,8 @@ #define PADCFG1_TERM_5K 2 #define PADCFG1_TERM_1K 1 +static struct intel_pinctrl *hack_pctrl; + struct intel_pad_context { u32 padcfg0; u32 padcfg1; @@ -94,7 +99,11 @@ struct intel_pinctrl_context { */ struct intel_pinctrl { struct device *dev; - spinlock_t lock; +#ifdef CONFIG_IPIPE + ipipe_spinlock_t lock; +#else + raw_spinlock_t lock; +#endif struct pinctrl_desc pctldesc; struct pinctrl_dev *pctldev; struct gpio_chip chip; @@ -324,7 +333,7 @@ static int intel_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned function, unsigned long flags; int i; - spin_lock_irqsave(&pctrl->lock, flags); + raw_spin_lock_irqsave(&pctrl->lock, flags); /* * All pins in the groups needs to be accessible and writable @@ -332,7 +341,7 @@ static int intel_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned function, */ for (i = 0; i < grp->npins; i++) { if (!intel_pad_usable(pctrl, grp->pins[i])) { - spin_unlock_irqrestore(&pctrl->lock, flags); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); return -EBUSY; } } @@ -351,7 +360,7 @@ static int intel_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned function, writel(value, padcfg0); } - spin_unlock_irqrestore(&pctrl->lock, flags); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); return 0; } @@ -365,10 +374,10 @@ static int intel_gpio_request_enable(struct pinctrl_dev *pctldev, unsigned long flags; u32 value; - spin_lock_irqsave(&pctrl->lock, flags); + raw_spin_lock_irqsave(&pctrl->lock, flags); if (!intel_pad_usable(pctrl, pin)) { - spin_unlock_irqrestore(&pctrl->lock, flags); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); return -EBUSY; } @@ -383,7 +392,7 @@ static int intel_gpio_request_enable(struct pinctrl_dev *pctldev, value |= PADCFG0_GPIOTXDIS; writel(value, padcfg0); - spin_unlock_irqrestore(&pctrl->lock, flags); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); return 0; } @@ -397,7 +406,7 @@ static int intel_gpio_set_direction(struct pinctrl_dev *pctldev, unsigned long flags; u32 value; - spin_lock_irqsave(&pctrl->lock, flags); + raw_spin_lock_irqsave(&pctrl->lock, flags); padcfg0 = intel_get_padcfg(pctrl, pin, PADCFG0); @@ -408,7 +417,7 @@ static int intel_gpio_set_direction(struct pinctrl_dev *pctldev, value &= ~PADCFG0_GPIOTXDIS; writel(value, padcfg0); - spin_unlock_irqrestore(&pctrl->lock, flags); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); return 0; } @@ -496,7 +505,7 @@ static int intel_config_set_pull(struct intel_pinctrl *pctrl, unsigned pin, int ret = 0; u32 value; - spin_lock_irqsave(&pctrl->lock, flags); + raw_spin_lock_irqsave(&pctrl->lock, flags); padcfg1 = intel_get_padcfg(pctrl, pin, PADCFG1); value = readl(padcfg1); @@ -550,7 +559,7 @@ static int intel_config_set_pull(struct intel_pinctrl *pctrl, unsigned pin, if (!ret) writel(value, padcfg1); - spin_unlock_irqrestore(&pctrl->lock, flags); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); return ret; } @@ -617,14 +626,14 @@ static void intel_gpio_set(struct gpio_chip *chip, unsigned offset, int value) unsigned long flags; u32 padcfg0; - spin_lock_irqsave(&pctrl->lock, flags); + raw_spin_lock_irqsave(&pctrl->lock, flags); padcfg0 = readl(reg); if (value) padcfg0 |= PADCFG0_GPIOTXSTATE; else padcfg0 &= ~PADCFG0_GPIOTXSTATE; writel(padcfg0, reg); - spin_unlock_irqrestore(&pctrl->lock, flags); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); } } @@ -650,14 +659,14 @@ static const struct gpio_chip intel_gpio_chip = { .set = intel_gpio_set, }; -static void intel_gpio_irq_ack(struct irq_data *d) +static void __intel_gpio_irq_ack(struct irq_data *d) + { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct intel_pinctrl *pctrl = gpiochip_get_data(gc); const struct intel_community *community; unsigned pin = irqd_to_hwirq(d); - spin_lock(&pctrl->lock); community = intel_get_community(pctrl, pin); if (community) { @@ -668,20 +677,32 @@ static void intel_gpio_irq_ack(struct irq_data *d) writel(BIT(gpp_offset), community->regs + GPI_IS + gpp * 4); } - spin_unlock(&pctrl->lock); } + +static void intel_gpio_irq_ack(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + + raw_spin_lock(&pctrl->lock); + __intel_gpio_irq_ack(d); + raw_spin_unlock(&pctrl->lock); +} + + static void intel_gpio_irq_enable(struct irq_data *d) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + const struct intel_community *community; unsigned pin = irqd_to_hwirq(d); unsigned long flags; - - spin_lock_irqsave(&pctrl->lock, flags); + raw_spin_lock_irqsave(&pctrl->lock, flags); community = intel_get_community(pctrl, pin); + if (community) { unsigned padno = pin_to_padno(community, pin); unsigned gpp_size = community->gpp_size; @@ -694,21 +715,24 @@ static void intel_gpio_irq_enable(struct irq_data *d) value = readl(community->regs + community->ie_offset + gpp * 4); value |= BIT(gpp_offset); - writel(value, community->regs + community->ie_offset + gpp * 4); + writel(value, community->regs + community->ie_offset + gpp * 4); + } - spin_unlock_irqrestore(&pctrl->lock, flags); + hack_pctrl = pctrl; + + ipipe_unlock_irq(d->irq); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); } -static void intel_gpio_irq_mask_unmask(struct irq_data *d, bool mask) +static void __intel_gpio_irq_mask_unmask(struct irq_data *d, bool mask) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct intel_pinctrl *pctrl = gpiochip_get_data(gc); const struct intel_community *community; unsigned pin = irqd_to_hwirq(d); - unsigned long flags; - - spin_lock_irqsave(&pctrl->lock, flags); community = intel_get_community(pctrl, pin); if (community) { @@ -727,23 +751,63 @@ static void intel_gpio_irq_mask_unmask(struct irq_data *d, bool mask) writel(value, reg); } - spin_unlock_irqrestore(&pctrl->lock, flags); } + static void intel_gpio_irq_mask(struct irq_data *d) { - intel_gpio_irq_mask_unmask(d, true); + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + + raw_spin_lock_irqsave(&pctrl->lock, flags); + ipipe_lock_irq(d->irq); + __intel_gpio_irq_mask_unmask(d, true); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); } static void intel_gpio_irq_unmask(struct irq_data *d) { - intel_gpio_irq_mask_unmask(d, false); + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + + raw_spin_lock_irqsave(&pctrl->lock, flags); + __intel_gpio_irq_mask_unmask(d, false); + ipipe_unlock_irq(d->irq); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); } +#ifdef CONFIG_IPIPE + +static void intel_gpio_irq_hold(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + raw_spin_lock_irqsave(&pctrl->lock, flags); + __intel_gpio_irq_mask_unmask(d, true); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); + +} + +static void intel_gpio_irq_release(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct intel_pinctrl *pctrl = gpiochip_get_data(gc); + unsigned long flags; + raw_spin_lock_irqsave(&pctrl->lock, flags); + __intel_gpio_irq_mask_unmask(d, false); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); + } + +#endif + static int intel_gpio_irq_type(struct irq_data *d, unsigned type) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct intel_pinctrl *pctrl = gpiochip_get_data(gc); unsigned pin = irqd_to_hwirq(d); unsigned long flags; void __iomem *reg; @@ -763,7 +827,7 @@ static int intel_gpio_irq_type(struct irq_data *d, unsigned type) return -EPERM; } - spin_lock_irqsave(&pctrl->lock, flags); + raw_spin_lock_irqsave(&pctrl->lock, flags); value = readl(reg); @@ -790,7 +854,7 @@ static int intel_gpio_irq_type(struct irq_data *d, unsigned type) else if (type & IRQ_TYPE_LEVEL_MASK) irq_set_handler_locked(d, handle_level_irq); - spin_unlock_irqrestore(&pctrl->lock, flags); + raw_spin_unlock_irqrestore(&pctrl->lock, flags); return 0; } @@ -840,12 +904,14 @@ static irqreturn_t intel_gpio_community_irq_handler(struct intel_pinctrl *pctrl, irq = irq_find_mapping(gc->irqdomain, community->pin_base + padno); - generic_handle_irq(irq); + ipipe_handle_demuxed_irq(irq); ret |= IRQ_HANDLED; } } + return ret; } @@ -853,11 +919,13 @@ static irqreturn_t intel_gpio_irq(int irq, void *data) { const struct intel_community *community; struct intel_pinctrl *pctrl = data; + irqreturn_t ret = IRQ_NONE; int i; /* Need to check all communities for pending interrupts */ for (i = 0; i < pctrl->ncommunities; i++) { + community = &pctrl->communities[i]; ret |= intel_gpio_community_irq_handler(pctrl, community); } @@ -865,6 +933,20 @@ static irqreturn_t intel_gpio_irq(int irq, void *data) return ret; } +static void ipipe_irq_cascade(struct irq_desc *desc) +{ + +#ifdef CONFIG_IPIPE + struct intel_pinctrl *pctrl = hack_pctrl; + int irq = irq_desc_get_irq(desc); + + desc->irq_data.chip->irq_ack(&desc->irq_data); + + intel_gpio_irq(irq,pctrl); +#endif + +} + static struct irq_chip intel_gpio_irqchip = { .name = "intel-gpio", .irq_enable = intel_gpio_irq_enable, @@ -873,11 +955,18 @@ static struct irq_chip intel_gpio_irqchip = { .irq_unmask = intel_gpio_irq_unmask, .irq_set_type = intel_gpio_irq_type, .irq_set_wake = intel_gpio_irq_wake, +#ifdef CONFIG_IPIPE + .irq_hold = intel_gpio_irq_hold, + .irq_release = intel_gpio_irq_release, +#endif }; + + static int intel_gpio_probe(struct intel_pinctrl *pctrl, int irq) { int ret; + pctrl->chip = intel_gpio_chip; @@ -887,6 +976,7 @@ static int intel_gpio_probe(struct intel_pinctrl *pctrl, int irq) pctrl->chip.base = -1; pctrl->irq = irq; + ret = gpiochip_add_data(&pctrl->chip, pctrl); if (ret) { dev_err(pctrl->dev, "failed to register gpiochip\n"); @@ -900,20 +990,28 @@ static int intel_gpio_probe(struct intel_pinctrl *pctrl, int irq) goto fail; } + if (IS_ENABLED(CONFIG_IPIPE)) + { + irq_set_chained_handler_and_data(irq, + ipipe_irq_cascade,pctrl); + } + else { /* * We need to request the interrupt here (instead of providing chip * to the irq directly) because on some platforms several GPIO * controllers share the same interrupt line. */ - ret = devm_request_irq(pctrl->dev, irq, intel_gpio_irq, IRQF_SHARED, - dev_name(pctrl->dev), pctrl); - if (ret) { - dev_err(pctrl->dev, "failed to request interrupt\n"); - goto fail; + ret = devm_request_irq(pctrl->dev, irq, intel_gpio_irq, + IRQF_SHARED | IRQF_NO_THREAD, + dev_name(pctrl->dev), pctrl); + if (ret) { + dev_err(pctrl->dev, "failed to request interrupt\n"); + goto fail; + } } ret = gpiochip_irqchip_add(&pctrl->chip, &intel_gpio_irqchip, 0, - handle_simple_irq, IRQ_TYPE_NONE); + handle_level_irq, IRQ_TYPE_NONE); if (ret) { dev_err(pctrl->dev, "failed to add irqchip\n"); goto fail; @@ -921,6 +1019,8 @@ static int intel_gpio_probe(struct intel_pinctrl *pctrl, int irq) gpiochip_set_chained_irqchip(&pctrl->chip, &intel_gpio_irqchip, irq, NULL); + + return 0; fail: @@ -981,7 +1081,7 @@ int intel_pinctrl_probe(struct platform_device *pdev, pctrl->dev = &pdev->dev; pctrl->soc = soc_data; - spin_lock_init(&pctrl->lock); + raw_spin_lock_init(&pctrl->lock); /* * Make a copy of the communities which we can use to hold pointers Note: I am working on kernel version 4.4.43, hence there are some differences from the recent version of pinctrl-intel. For example, I had to change the spinlocks into raw spinlocks. regards, Nitin ________________________________________ From: Philippe Gerum <rpm@xenomai.org> Sent: Wednesday, June 14, 2017 10:27 AM To: Nitin Kulkarni; xenomai@xenomai.org Subject: Re: [Xenomai] Problem with gpio interrupts for xenomai3 on Intel joule On 06/12/2017 01:02 PM, Nitin Kulkarni wrote: > Hi Philippe, > Correcting the subject of this thread and adding it to the mailing list. > Thanks for those precise code suggestions. There are two issues. > > 1. I found that the ipipe_irq_cascade handler is called but the problem is that > there are 5 pinctrl devices on this soc and all of them share the same irq line. Hence I see that the intel_gpio_probe() > runs for all the 5 pin controllers during kernel initialization and overwrites the irq descriptor with respective pinctrl data each time the probe runs. > When the interrupt is triggered ipipe_irq_cascade invoked with the irq desc, I always see that the pinctrl data retrieved from > irq_desc using irq_desc_get_handler_data is always the last pinctrl. Hence I do not read the right pinctrl to call intel_gpio_irq() and read the right interrupt enable reg for the gpio pin I enabled as interrupt. > > 2. When I forced it to read the right pinctrl data by storing that information when intel_gpio_irq_enable is executed. > The rtdm handller from my module is executed but the ack call intel_gpio_irq_ack is not called. Hence the irq flags were never cleared and the mmc driver also starts complaining about interrupts not being received. The whole system slows down and virtually hangs. > > *I tried some fixes* > -> I changed the flow handler type from handle_simple_irq to handle_edge_irq while calling gpiochip_irqchip_add() > in intel_gpio_probe. > -> I called the ack function in ipipe_irq_cascade using the irq_desc which it has. > It seems to work perfectly with this fix but this is a raw and a hackish way of doing. I am not sure if this has any consequences. > Can you suggest me whats wrong with the ack not being called and how to deal with multiple pinctrl devices sharing the same irq. > Please send a patch including your changes; it should be easier to review and comment. -- Philippe. ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [Xenomai] Problem with gpio interrupts for xenomai3 on Intel joule 2017-06-14 12:57 ` Nitin Kulkarni @ 2017-06-25 13:59 ` Philippe Gerum 2017-06-28 10:47 ` Nitin Kulkarni 0 siblings, 1 reply; 10+ messages in thread From: Philippe Gerum @ 2017-06-25 13:59 UTC (permalink / raw) To: Nitin Kulkarni, xenomai On 06/14/2017 02:57 PM, Nitin Kulkarni wrote: > Major change is use of handle_level_irq flow handler instead of handle_simple_irq > & calling the ack function manually in ipipe_irq_cascade. > Here is the Patch : > > diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c > index 3b19ef0..4f41532 100644 > > +static struct intel_pinctrl *hack_pctrl; > + > static void intel_gpio_irq_enable(struct irq_data *d) > { > + hack_pctrl = pctrl; > The interrupt pipeline does not support shared IRQs with regular drivers, that is the basic issue. The problem with handler data being overwritten stems from this one, since we cannot support multiple IRQ actions on a single interrupt channel in pipelined interrupt mode. You could share an IRQ strictly in real-time mode between multiple devices only with a Xenomai driver, at the expense of implementing all the driver's logic on the RTDM side. Conversely, there is no problem in sharing IRQs between multiple devices in non-rt mode as well, although a way would have to be found in order to fix the handler data issue discussed earlier. The problem starts with mixing real-time and non-rt activities on a single interrupt channel. Your fix up here simply restricts the usage to having a single pin controller active in the system, the one that gets enabled. So in effect, you stop sharing the IRQ between multiple gpio controller devices, which makes things somewhat usable in your case - assuming that you only need to enable a single gpio module. > +static void ipipe_irq_cascade(struct irq_desc *desc) > +{ > + > +#ifdef CONFIG_IPIPE > + struct intel_pinctrl *pctrl = hack_pctrl; > + int irq = irq_desc_get_irq(desc); > + > + desc->irq_data.chip->irq_ack(&desc->irq_data); Correct. A chained IRQ handler should ack the event in the interrupt controller when the pipeline is enabled. > ret = gpiochip_irqchip_add(&pctrl->chip, &intel_gpio_irqchip, 0, > - handle_simple_irq, IRQ_TYPE_NONE); > + handle_level_irq, IRQ_TYPE_NONE); Correct too. The level flow handler must be used for the pipelined interrupt, since the IRQ handler on the linux stage may be delayed until the real-time core relinquishes the CPU, so we need masking to prevent an IRQ storm when the interrupts are enabled again in the meantime. That also explains why sharing an IRQ between linux and Xenomai to serve devices with mismatching "priorities" won't work: the IRQ would be masked on receipt, then delivered to a real-time handler for probing. The real-time side would want to enable it back asap, not to delay any further (real-time) IRQ from the same device. Which means it could not wait for the linux flow handlers to eventually unmask it, "at some point later". But, unmasking the interrupt immediately would cause an IRQ storm if the current request could not be handled by the real-time driver, but should wait until a linux driver later in the chain accepts it. In the meantime, the CPU would have resumed accepting interrupts again. -- Philippe. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Problem with gpio interrupts for xenomai3 on Intel joule 2017-06-25 13:59 ` Philippe Gerum @ 2017-06-28 10:47 ` Nitin Kulkarni 2017-06-30 19:40 ` Philippe Gerum 0 siblings, 1 reply; 10+ messages in thread From: Nitin Kulkarni @ 2017-06-28 10:47 UTC (permalink / raw) To: Philippe Gerum, xenomai Hi Philippe, Thanks for the review and you comments are very helpful. I think my fix-up would just be fine for us as we just need one gpio interrupt to process SPI transfers with an XMOS microcontroller. Hence my next challenge is to do SPI communication in real-time domain (My colleague Stefano once had a discussion over emails with you I think about streaming audio over SPI in realtime domain), I know that I will have to port the spi-pxa2xx platform driver to RTDM. i was looking at the bcm2835 spi driver that you have ported for RTDM. Is this a good reference to start ? Thanks and regards, Nitin ____________________________ From: Philippe Gerum <rpm@xenomai.org> Sent: Sunday, June 25, 2017 3:59 PM To: Nitin Kulkarni; xenomai@xenomai.org Subject: Re: [Xenomai] Problem with gpio interrupts for xenomai3 on Intel joule On 06/14/2017 02:57 PM, Nitin Kulkarni wrote: > Major change is use of handle_level_irq flow handler instead of handle_simple_irq > & calling the ack function manually in ipipe_irq_cascade. > Here is the Patch : > > diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c > index 3b19ef0..4f41532 100644 > > +static struct intel_pinctrl *hack_pctrl; > + > static void intel_gpio_irq_enable(struct irq_data *d) > { > + hack_pctrl = pctrl; > The interrupt pipeline does not support shared IRQs with regular drivers, that is the basic issue. The problem with handler data being overwritten stems from this one, since we cannot support multiple IRQ actions on a single interrupt channel in pipelined interrupt mode. You could share an IRQ strictly in real-time mode between multiple devices only with a Xenomai driver, at the expense of implementing all the driver's logic on the RTDM side. Conversely, there is no problem in sharing IRQs between multiple devices in non-rt mode as well, although a way would have to be found in order to fix the handler data issue discussed earlier. The problem starts with mixing real-time and non-rt activities on a single interrupt channel. Your fix up here simply restricts the usage to having a single pin controller active in the system, the one that gets enabled. So in effect, you stop sharing the IRQ between multiple gpio controller devices, which makes things somewhat usable in your case - assuming that you only need to enable a single gpio module. > +static void ipipe_irq_cascade(struct irq_desc *desc) > +{ > + > +#ifdef CONFIG_IPIPE > + struct intel_pinctrl *pctrl = hack_pctrl; > + int irq = irq_desc_get_irq(desc); > + > + desc->irq_data.chip->irq_ack(&desc->irq_data); Correct. A chained IRQ handler should ack the event in the interrupt controller when the pipeline is enabled. > ret = gpiochip_irqchip_add(&pctrl->chip, &intel_gpio_irqchip, 0, > - handle_simple_irq, IRQ_TYPE_NONE); > + handle_level_irq, IRQ_TYPE_NONE); Correct too. The level flow handler must be used for the pipelined interrupt, since the IRQ handler on the linux stage may be delayed until the real-time core relinquishes the CPU, so we need masking to prevent an IRQ storm when the interrupts are enabled again in the meantime. That also explains why sharing an IRQ between linux and Xenomai to serve devices with mismatching "priorities" won't work: the IRQ would be masked on receipt, then delivered to a real-time handler for probing. The real-time side would want to enable it back asap, not to delay any further (real-time) IRQ from the same device. Which means it could not wait for the linux flow handlers to eventually unmask it, "at some point later". But, unmasking the interrupt immediately would cause an IRQ storm if the current request could not be handled by the real-time driver, but should wait until a linux driver later in the chain accepts it. In the meantime, the CPU would have resumed accepting interrupts again. -- Philippe. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Problem with gpio interrupts for xenomai3 on Intel joule 2017-06-28 10:47 ` Nitin Kulkarni @ 2017-06-30 19:40 ` Philippe Gerum 0 siblings, 0 replies; 10+ messages in thread From: Philippe Gerum @ 2017-06-30 19:40 UTC (permalink / raw) To: Nitin Kulkarni, xenomai On 06/28/2017 12:47 PM, Nitin Kulkarni wrote: > Hi Philippe, > Thanks for the review and you comments are very helpful. > I think my fix-up would just be fine for us as we just need one gpio interrupt to process SPI transfers > with an XMOS microcontroller. > > Hence my next challenge is to do SPI communication in real-time domain (My colleague > Stefano once had a discussion over emails with you I think about streaming audio over SPI in realtime domain), > I know that I will have to port the spi-pxa2xx platform driver to RTDM. > i was looking at the bcm2835 spi driver that you have ported for RTDM. > Is this a good reference to start ? At least to understand which handler need to be provided to Cobalt's generic SPI core, yes. -- Philippe. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-06-30 19:40 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.117.1496166485.4225.xenomai@xenomai.org>
2017-05-30 18:02 ` [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3) Nitin Kulkarni
2017-05-31 7:16 ` Philippe Gerum
2017-05-31 10:34 ` Nitin Kulkarni
2017-06-01 7:11 ` Philippe Gerum
[not found] ` <1497222185664.65276@kth.se>
2017-06-12 11:02 ` [Xenomai] Problem with gpio interrupts for xenomai3 on Intel joule Nitin Kulkarni
2017-06-14 8:27 ` Philippe Gerum
2017-06-14 12:57 ` Nitin Kulkarni
2017-06-25 13:59 ` Philippe Gerum
2017-06-28 10:47 ` Nitin Kulkarni
2017-06-30 19:40 ` Philippe Gerum
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.