On 02/07/2013 02:09 AM, Linus Walleij wrote: > On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart <dvh...@linux.intel.com> wrote: > >> Is it that some other driver has claimed these GPIO lines? If so, how do >> I determine which one? > > Yes I think that could be it, the driver would need to call > gpio_export() for it to also be accessible in sysfs. > > Configure in debugfs and check the file "gpio" in debugfs > to figure out the client.
I added dynamic printk and queried the relevant files. I didn't see any dev_* or pr_* messages. # dmesg | grep -i gpio Kernel command line: BOOT_IMAGE=/vmlinuz root=/dev/sda2 console=ttyPCH0,115200 cons ole=tty0 vmalloc=256MB "dyndbg=file gpiolib.c +p;file gpio-sch.c +p; file gpio-pch. c +p" dynamic_debug.verbose=1 debug loglevel=8 dynamic_debug:ddebug_add_module: 17 debug prints in module gpiolib dynamic_debug:ddebug_add_module: 2 debug prints in module gpio_pch pch_gpio 0000:02:00.2: enabling device (0000 -> 0002) gpiochip_find_base: found new base at 244 gpiochip_add: registered GPIOs 244 to 255 on device: 0000:02:00.2 gpiochip_add: registered GPIOs 0 to 4 on device: sch_gpio_core gpiochip_add: registered GPIOs 5 to 13 on device: sch_gpio_resume The GPIO debugfs and SYSFS interfaces only show the GPIO from the PCH, nothing from the SCH (CPU): # cat /debug/gpio GPIOs 244-255, 0000:02:00.2: # ls /sys/class/gpio/ export gpiochip244 unexport Instrumenting gpiochip_export, I see: gpiochip_export: base=0 ngpio=5 label=sch_gpio_core gpiochip_add: registered GPIOs 0 to 4 on device: sch_gpio_core gpiochip_export: base=5 ngpio=9 label=sch_gpio_resume gpiochip_add: registered GPIOs 5 to 13 on device: sch_gpio_resume So the calls to gpiochip_export for the sch driver are being made, and my on-error instrumentation did not trigger. Finally, I do see an "irq 16: nobody cared" with the sch driver as the handler. It isn't clear to me that this would cause the chip not to appear in sysfs, but I'm including it here for completeness: irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper/0 Not tainted 3.4.26-yocto-standard #2 Call Trace: [<c1648288>] ? printk+0x2e/0x30 [<c1093cfa>] __report_bad_irq+0x2a/0xd0 [<c1389719>] ? add_interrupt_randomness+0x19/0x150 [<c1093fd4>] note_interrupt+0x174/0x1c0 [<c1009fbf>] ? cpu_idle+0x1f/0xb0 [<c1091da2>] handle_irq_event_percpu+0xb2/0x220 [<c1653fc9>] ? add_preempt_count+0x9/0xb0 [<c1091f4b>] handle_irq_event+0x3b/0x60 [<c1094940>] ? unmask_irq+0x30/0x30 [<c1094990>] handle_fasteoi_irq+0x50/0xe0 <IRQ> [<c16576b3>] ? do_IRQ+0x43/0xb0 [<c1056f04>] ? scheduler_ipi+0x74/0xd0 [<c16575e9>] ? common_interrupt+0x29/0x30 [<c1009fbf>] ? cpu_idle+0x1f/0xb0 [<c1632518>] ? rest_init+0x6c/0x74 [<c193b71d>] ? start_kernel+0x30c/0x313 [<c193b243>] ? repair_env_string+0x51/0x51 [<c193b078>] ? i386_start_kernel+0x78/0x7d handlers: [<c130aec0>] pch_gpio_handler -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
