Help on modelling gpio interrupt source when interrupt is shared

[Rajasekhar Pulluru]

Hi Anish,

My intention is just to detect interrupt in the user space and read the
device id without using udev.

I don't want to create a new driver in kernel (assume I can't modify linux
kernel sources), which is the first reason to go for uio generic platform
driver.

If I register a gpio interrupt (level triggered) using a kernel module, I
can get the interrupt detected when device is inserted/removed. But I would
like to detect device presence completely from user space without modifying
linux kernel.

Thanks & Regards,
Rajasekhar

On Tue, Jan 24, 2017 at 11:56 AM, anish singh <anish198519851985 at gmail.com>
wrote:

>
>
> On Mon, Jan 23, 2017 at 7:46 AM, Rajasekhar Pulluru <
> pullururajasekhar at gmail.com> wrote:
>
>> Hi,
>>
>> I have a query on device tree pertaining to modelling a gpio pin as an
>> interrupt source.
>> I have searched mailing list archives and kernel documentation before
>> posting this and couldn't get any direct solution.
>> (My understanding is limited and hence posting the query below:)
>>
>> My SOC has a gpio controller and uart both sharing same interrupt line as
>> specified below.
>>
>> interrupt-parent = <&gic>;
>>
>>         mygpio: gpio at 0x19008000 {
>>                 compatible = "mysoc,mygpio-controller,gc";
>>                 #address-cells = <1>;
>>                 #size-cells = <1>;
>>                 #gpio-cells = <2>;
>>                 reg = gpio: <0x19008000 0x50>;
>>                 ngpios = <12>;
>>                 pin-offset = <4>;
>>                 pin-base = <4>;
>>                 irq-base = <256>; /* sw irq base for irq handlers */
>>                 gpio-controller;
>>                 interrupt-controller;
>>                 interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
>>         };
>>
>>         uart0: serial at 0x19000300 {
>>                 compatible = "snps,dw-apb-uart";
>>                 reg = <0x19000300 0x100>;
>>                 interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
>>                 clock-frequency = <62500000>;
>>         };
>>
>> gpio pin 0 of mygpio is used as an interrupt source for detecting the
>> presence of external pluggable device (that is not driven by kernel).
>> And I intend to detect the presence of the pluggable device from user
>> space by means of generic uio platform driver using below device
>>
>
> What do you intend to achieve by detecting device in userspace?
> You can directly get notification using udev notification.
>
> However, you need to send udev notification from a kernel driver.
>
>
>> tree configuration. (following https://yurovsky.github.io/201
>> 4/10/10/linux-uio-gpio-interrupt/)
>>
>>         user_io at 0 {
>>             compatible = "mydevice,generic-uio,ui_pdrv";
>>             status = "okay";
>>             interrupt-parent = <&mygpio>;
>>             interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
>>         };
>>
>> Running modprobe uio_pdrv_genirq of_id="mydevice,generic-uio,ui_pdrv"
>> and creating /dev/uio0 using mknod (major number from cat /proc/devices |
>> grep uio),
>> I couldn't see an irq entry bind to uio driver under /proc/interrupts.
>> Am I doing anything wrong here?
>>
>> Other method I have tried to get notified of the gpio pin0 interrupt in
>> user space is to poll on /sys/class/gpio/gpio0/value. But merely exporting
>> gpio0
>> wasn't sufficient as kernel should make a call to request_irq on the
>> gpio0 interrupt line. Is there a generic driver framework (like pinctrl)
>> that can export
>> a device node to register the gpio pin0 as an interrupt source that
>> allows me to poll on its sysfs entry?
>>
>
> All sysfs nodes can be polled as it is supported in kernel.
> You can simply create a dummy driver and register the
> irq and in your irq handler send udev notifications using
> kobj.
>
> Or
> just update a sysfs node which can be polled from userspace.
>
> If this answer is not sufficient then please explain in detail
> what you are planning to achieve rather than what you are
> doing to achieve that.
>
>>
>> Thanks,
>> Rajasekhar
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170124/8fa83d5c/attachment.html