On Thu, Jan 30, 2014 at 2:50 PM, Steffen Trumtrar <s.trumtrar@xxxxxxxxxxxxxx> wrote: > Hi! > > On Thu, Jan 30, 2014 at 01:40:04PM -0600, delicious quinoa wrote: >> On Thu, Dec 12, 2013 at 3:08 AM, Steffen Trumtrar >> <s.trumtrar@xxxxxxxxxxxxxx> wrote: >> >> > Second: The interrupt is registered as "GIC 37", which is a real interrupt on >> > the Socfpga. I would expect it to be marked as "GPIO 2xx" (or something in that >> > range). The interrupt from the gpiochip itself isn't registered at all ?! >> >> Hi Stephen, >> >> Did you export the gpio lines and set the edge in sysfs? Because the >> interrupts aren't allocated otherwise. >> >> For instance: >> >> root@socfpga_cyclone5:~# echo 195 > /sys/class/gpio/export >> root@socfpga_cyclone5:~# echo rising > /sys/class/gpio/gpio195/edge >> >> Now I can see a pretty nicely named interrupt in /proc/interrupts: >> >> 256: 0 0 gpio-dwapb 24 gpiolib >> > > I didn't try that and I think this behaviour is pretty uncommon. > This should be fixed in the driver. I never wrote a gpiochip-driver, > so I don't know what is missing, but maybe just some functioncall ?! > All other drivers I came across have that entry from probing without > any fiddling. Hi Steffen, Do you mean 'all other gpio drivers' or 'all other non-gpio drivers'? This is the behavior that is implemented in the community gpio framework drivers/gpio/gpiolib.c, not anything special implemented in this dw gpio driver. It's documented in Documentation/gpio/sysfs.txt and Documentation/ABI/testing/sysfs-gpio. You get userspace control of a gpio by 'export'ing it in sysfs. And then by default, the interrupt edge is set to 'none' (no irq) until you set the edge in sysfs. Alan > > Thanks, > Steffen > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html