From: Darren Hart <dvhart@linux.intel.com>
To: "lkml, " <linux-kernel@vger.kernel.org>,
Grant Likely <grant.likely@secretlab.ca>,
Denis Turischev <denis@compulab.co.il>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Walleij <linus.walleij@linaro.org>
Subject: gpio-sch GPIO_SYSFS access
Date: Wed, 06 Feb 2013 16:58:44 -0800 [thread overview]
Message-ID: <5112FC44.2000303@linux.intel.com> (raw)
I'm working with a TunnelCreek + EG20T platform which has two GPIO drivers:
gpio-sch - for the CPU GPIO lines
gpio-pch - for the EG20T GPIO lines
I can see the PCH GPIO lines in /sys/class/gpio, but not the CPU lines:
# dmesg | grep -i gpio
pch_gpio 0000:03:00.2: enabling device (0000 -> 0002)
gpiochip_find_base: found new base at 244
gpiochip_add: registered GPIOs 244 to 255 on device: 0000:03: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
gpio_request: gpio-0 (sysfs) status -22
gpio_request: gpio-243 (sysfs) status -22
gpio_request: gpio-256 (sysfs) status -22
# ls /sys/class/gpio
export gpiochip244 unexport
I can export 244-255 and manipulate and read them through the
sys interface. I cannot seem to access 0-13, although the dmesg
above seems to have successfully added them (and the core/resume
pin mapping is correct for a TunnelCreek CPU).
I'm not seeing any obvious difference in how the two drivers probe and
setup the chip that explains why one is accessible and the other is not.
I've enabled the following GPIO CONFIG* options:
$ cat config-minnow.gpio | grep -e "^CONFIG_.*GPIO"
CONFIG_GENERIC_GPIO=y
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_GPIO_POLLED=y
CONFIG_SPI_GPIO=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_GENERIC=y
CONFIG_GPIO_GENERIC_PLATFORM=y
CONFIG_GPIO_SCH=y
CONFIG_GPIO_PCH=y
CONFIG_LEDS_GPIO=y
I'm working with 3.4.26, but I have not seen anything in the gpio-sch.c
driver commit log that would suggest a fix has landed. I suspect I am
missing something fundamental about how these lines get exported.
Any ideas on what I might be missing?
Is it that some other driver has claimed these GPIO lines? If so, how do
I determine which one?
Thanks!
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
next reply other threads:[~2013-02-07 0:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-07 0:58 Darren Hart [this message]
2013-02-07 10:09 ` gpio-sch GPIO_SYSFS access Linus Walleij
2013-02-07 15:17 ` Darren Hart
2013-02-08 0:36 ` Darren Hart
2013-02-08 4:40 ` Darren Hart
2013-02-08 7:08 ` Darren Hart
2013-02-08 8:49 ` Samuel Ortiz
2013-02-08 10:36 ` Darren Hart
2013-02-08 11:07 ` Samuel Ortiz
2013-02-08 17:43 ` Darren Hart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5112FC44.2000303@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=denis@compulab.co.il \
--cc=grant.likely@secretlab.ca \
--cc=gregkh@linuxfoundation.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.