Re: DT GPIO numbering?
On Tue, Aug 14, 2012 at 12:00:23PM +0200, Linus Walleij wrote: > On Fri, Aug 10, 2012 at 11:34 AM, Johannes Stezenbach wrote: > > > Actually I think the kernel internal GPIO numbers shouldn't be in the > > sysfs API, instead userspace should use the names. > > This is true, but we cannot remove these numbers because they > are now in Documentation/ABI/testing/sysfs-gpio > > And while the "testing" ABI is, well for testing, it would probably > break a lot of stuff it we removed it. > > But we can sure add names. However these would still sit under > /sys/class/gpio/gpioN/name > > Or do you suggest we simply duplicate all GPIOs which have > names under /sys/class/gpio/named/ > or something like that? I'm still not sure. One idea was to add /proc/gpios which maps names to numbers, then userspace can look up the number and use that. But the more I think about it /sys/class/gpio/export is just a debug hack and shouldn't be used. Board code should export the available gpio according to pinctrl setup and schematics. The only catch here is that board code then needs to know which gpio are for userspace and which are used by in-kernel drivers. E.g. a LED could be set by LED Triggers or by userspace Blinkenlight app. Johannes -- 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/
Re: DT GPIO numbering?
On Fri, Aug 10, 2012 at 11:34 AM, Johannes Stezenbach wrote: > Actually I think the kernel internal GPIO numbers shouldn't be in the > sysfs API, instead userspace should use the names. This is true, but we cannot remove these numbers because they are now in Documentation/ABI/testing/sysfs-gpio And while the "testing" ABI is, well for testing, it would probably break a lot of stuff it we removed it. But we can sure add names. However these would still sit under /sys/class/gpio/gpioN/name Or do you suggest we simply duplicate all GPIOs which have names under /sys/class/gpio/named/ or something like that? I know Grant may have opinions on this... > Probably it's > best to not use /sys/class/gpio/export but instead let the board > init code export the GPIOs available to userspace with proper names. This sounds true. Yours, Linus Walleij -- 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/
Re: DT GPIO numbering?
On Fri, Aug 10, 2012 at 11:34 AM, Johannes Stezenbach j...@sig21.net wrote: Actually I think the kernel internal GPIO numbers shouldn't be in the sysfs API, instead userspace should use the names. This is true, but we cannot remove these numbers because they are now in Documentation/ABI/testing/sysfs-gpio And while the testing ABI is, well for testing, it would probably break a lot of stuff it we removed it. But we can sure add names. However these would still sit under /sys/class/gpio/gpioN/name Or do you suggest we simply duplicate all GPIOs which have names under /sys/class/gpio/named/name or something like that? I know Grant may have opinions on this... Probably it's best to not use /sys/class/gpio/export but instead let the board init code export the GPIOs available to userspace with proper names. This sounds true. Yours, Linus Walleij -- 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/
Re: DT GPIO numbering?
On Tue, Aug 14, 2012 at 12:00:23PM +0200, Linus Walleij wrote: On Fri, Aug 10, 2012 at 11:34 AM, Johannes Stezenbach j...@sig21.net wrote: Actually I think the kernel internal GPIO numbers shouldn't be in the sysfs API, instead userspace should use the names. This is true, but we cannot remove these numbers because they are now in Documentation/ABI/testing/sysfs-gpio And while the testing ABI is, well for testing, it would probably break a lot of stuff it we removed it. But we can sure add names. However these would still sit under /sys/class/gpio/gpioN/name Or do you suggest we simply duplicate all GPIOs which have names under /sys/class/gpio/named/name or something like that? I'm still not sure. One idea was to add /proc/gpios which maps names to numbers, then userspace can look up the number and use that. But the more I think about it /sys/class/gpio/export is just a debug hack and shouldn't be used. Board code should export the available gpio according to pinctrl setup and schematics. The only catch here is that board code then needs to know which gpio are for userspace and which are used by in-kernel drivers. E.g. a LED could be set by LED Triggers or by userspace Blinkenlight app. Johannes -- 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/
Re: DT GPIO numbering?
On Mon, Aug 06, 2012 at 07:10:00PM +0800, Mitch Bradley wrote: > On 8/6/2012 5:58 PM, Johannes Stezenbach wrote: > > On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote: > >> On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren > >> wrote: > >> > >>> I can't comment on the sysfs-vs-dev interface location, but I don't > >>> think it addresses Johannes' issue; finding out which GPIO IDs are > >>> provided by which devices. > >>> > >>> Perhaps in each device's sysfs node, there should be some information > >>> re: which GPIO range it provides. Right now, perhaps a text file with > >>> the GPIO base it it. > >> > >> Yes that could work ... > > > > The method used by the gpio-mxs.c driver (of_alias_get_id) > > would also work. The question is which method is preferable. > > > > Ideally I would like to use DT attributes to identify my GPIOs > > in the same way as they appear in the schematics. E.g. > > one device may have GPIOs called PORT_A.0 to PORT_A.7, > > another one may be EXT.0 to EXT.15. But a single integer ID > > is good enough since GPIO usage is platform specific anyway. > > However, the mapping must be static and not depend e.g. on > > module load order like now if you use pl061 and some i2c GPIO. > > Software must be able to rely on that e.g. GPIO ID 11 > > always refers to EXT.3. > > There is precedence for a "slot-names" property that correlates specific > hardware entities with physical labels. It has been applied to PCI > plug-in slots and to other devices. See, for example, > http://www.openfirmware.org/1275/proposals/Closed/Accepted/381-it.txt Sorry about the slow response. After thinking it through I decided that a) adding ad-hoc DT bindings isn't good, and b) doing it properly is above my head atm (I have too many other tasks to take care of). So I decided to use platform data to get stable GPIO numbers and names for now. Actually I think the kernel internal GPIO numbers shouldn't be in the sysfs API, instead userspace should use the names. Probably it's best to not use /sys/class/gpio/export but instead let the board init code export the GPIOs available to userspace with proper names. Not sure yet... Thanks, Johannes -- 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/
Re: DT GPIO numbering?
On Mon, Aug 06, 2012 at 07:10:00PM +0800, Mitch Bradley wrote: On 8/6/2012 5:58 PM, Johannes Stezenbach wrote: On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote: On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren swar...@wwwdotorg.org wrote: I can't comment on the sysfs-vs-dev interface location, but I don't think it addresses Johannes' issue; finding out which GPIO IDs are provided by which devices. Perhaps in each device's sysfs node, there should be some information re: which GPIO range it provides. Right now, perhaps a text file with the GPIO base it it. Yes that could work ... The method used by the gpio-mxs.c driver (of_alias_get_id) would also work. The question is which method is preferable. Ideally I would like to use DT attributes to identify my GPIOs in the same way as they appear in the schematics. E.g. one device may have GPIOs called PORT_A.0 to PORT_A.7, another one may be EXT.0 to EXT.15. But a single integer ID is good enough since GPIO usage is platform specific anyway. However, the mapping must be static and not depend e.g. on module load order like now if you use pl061 and some i2c GPIO. Software must be able to rely on that e.g. GPIO ID 11 always refers to EXT.3. There is precedence for a slot-names property that correlates specific hardware entities with physical labels. It has been applied to PCI plug-in slots and to other devices. See, for example, http://www.openfirmware.org/1275/proposals/Closed/Accepted/381-it.txt Sorry about the slow response. After thinking it through I decided that a) adding ad-hoc DT bindings isn't good, and b) doing it properly is above my head atm (I have too many other tasks to take care of). So I decided to use platform data to get stable GPIO numbers and names for now. Actually I think the kernel internal GPIO numbers shouldn't be in the sysfs API, instead userspace should use the names. Probably it's best to not use /sys/class/gpio/export but instead let the board init code export the GPIOs available to userspace with proper names. Not sure yet... Thanks, Johannes -- 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/
Re: DT GPIO numbering?
On 8/6/2012 5:58 PM, Johannes Stezenbach wrote: > On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote: >> On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren wrote: >> >>> I can't comment on the sysfs-vs-dev interface location, but I don't >>> think it addresses Johannes' issue; finding out which GPIO IDs are >>> provided by which devices. >>> >>> Perhaps in each device's sysfs node, there should be some information >>> re: which GPIO range it provides. Right now, perhaps a text file with >>> the GPIO base it it. >> >> Yes that could work ... > > The method used by the gpio-mxs.c driver (of_alias_get_id) > would also work. The question is which method is preferable. > > Ideally I would like to use DT attributes to identify my GPIOs > in the same way as they appear in the schematics. E.g. > one device may have GPIOs called PORT_A.0 to PORT_A.7, > another one may be EXT.0 to EXT.15. But a single integer ID > is good enough since GPIO usage is platform specific anyway. > However, the mapping must be static and not depend e.g. on > module load order like now if you use pl061 and some i2c GPIO. > Software must be able to rely on that e.g. GPIO ID 11 > always refers to EXT.3. There is precedence for a "slot-names" property that correlates specific hardware entities with physical labels. It has been applied to PCI plug-in slots and to other devices. See, for example, http://www.openfirmware.org/1275/proposals/Closed/Accepted/381-it.txt > > >>> With the new /dev interface you mention above, >>> perhaps a symlink to the /dev file, or a file containing the /dev file's >>> major/minor number. Or, is there such a thing already (other than >>> debugfs's gpio file). >> >> Nothing I know of, but yes the day we come up with something, >> it needs to be backward-compatible some way. >> >> The problem is that there is really no reference userspace >> like "lsgpio" or so. Maybe the first step could be to create that. > > I don't know much about OpenWrt, but I've seen they have > something: > https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/char/gpio_dev.c > https://dev.openwrt.org/browser/trunk/target/linux/generic/files/include/linux/gpio_dev.h > https://dev.openwrt.org/browser/trunk/package/gpioctl/src/main.c > > > Johannes > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- 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/
Re: DT GPIO numbering?
On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote: > On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren wrote: > > > I can't comment on the sysfs-vs-dev interface location, but I don't > > think it addresses Johannes' issue; finding out which GPIO IDs are > > provided by which devices. > > > > Perhaps in each device's sysfs node, there should be some information > > re: which GPIO range it provides. Right now, perhaps a text file with > > the GPIO base it it. > > Yes that could work ... The method used by the gpio-mxs.c driver (of_alias_get_id) would also work. The question is which method is preferable. Ideally I would like to use DT attributes to identify my GPIOs in the same way as they appear in the schematics. E.g. one device may have GPIOs called PORT_A.0 to PORT_A.7, another one may be EXT.0 to EXT.15. But a single integer ID is good enough since GPIO usage is platform specific anyway. However, the mapping must be static and not depend e.g. on module load order like now if you use pl061 and some i2c GPIO. Software must be able to rely on that e.g. GPIO ID 11 always refers to EXT.3. > > With the new /dev interface you mention above, > > perhaps a symlink to the /dev file, or a file containing the /dev file's > > major/minor number. Or, is there such a thing already (other than > > debugfs's gpio file). > > Nothing I know of, but yes the day we come up with something, > it needs to be backward-compatible some way. > > The problem is that there is really no reference userspace > like "lsgpio" or so. Maybe the first step could be to create that. I don't know much about OpenWrt, but I've seen they have something: https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/char/gpio_dev.c https://dev.openwrt.org/browser/trunk/target/linux/generic/files/include/linux/gpio_dev.h https://dev.openwrt.org/browser/trunk/package/gpioctl/src/main.c Johannes -- 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/
Re: DT GPIO numbering?
On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren wrote: > I can't comment on the sysfs-vs-dev interface location, but I don't > think it addresses Johannes' issue; finding out which GPIO IDs are > provided by which devices. > > Perhaps in each device's sysfs node, there should be some information > re: which GPIO range it provides. Right now, perhaps a text file with > the GPIO base it it. Yes that could work ... > With the new /dev interface you mention above, > perhaps a symlink to the /dev file, or a file containing the /dev file's > major/minor number. Or, is there such a thing already (other than > debugfs's gpio file). Nothing I know of, but yes the day we come up with something, it needs to be backward-compatible some way. The problem is that there is really no reference userspace like "lsgpio" or so. Maybe the first step could be to create that. Yours, Linus Walleij -- 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/
Re: DT GPIO numbering?
On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren swar...@wwwdotorg.org wrote: I can't comment on the sysfs-vs-dev interface location, but I don't think it addresses Johannes' issue; finding out which GPIO IDs are provided by which devices. Perhaps in each device's sysfs node, there should be some information re: which GPIO range it provides. Right now, perhaps a text file with the GPIO base it it. Yes that could work ... With the new /dev interface you mention above, perhaps a symlink to the /dev file, or a file containing the /dev file's major/minor number. Or, is there such a thing already (other than debugfs's gpio file). Nothing I know of, but yes the day we come up with something, it needs to be backward-compatible some way. The problem is that there is really no reference userspace like lsgpio or so. Maybe the first step could be to create that. Yours, Linus Walleij -- 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/
Re: DT GPIO numbering?
On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote: On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren swar...@wwwdotorg.org wrote: I can't comment on the sysfs-vs-dev interface location, but I don't think it addresses Johannes' issue; finding out which GPIO IDs are provided by which devices. Perhaps in each device's sysfs node, there should be some information re: which GPIO range it provides. Right now, perhaps a text file with the GPIO base it it. Yes that could work ... The method used by the gpio-mxs.c driver (of_alias_get_id) would also work. The question is which method is preferable. Ideally I would like to use DT attributes to identify my GPIOs in the same way as they appear in the schematics. E.g. one device may have GPIOs called PORT_A.0 to PORT_A.7, another one may be EXT.0 to EXT.15. But a single integer ID is good enough since GPIO usage is platform specific anyway. However, the mapping must be static and not depend e.g. on module load order like now if you use pl061 and some i2c GPIO. Software must be able to rely on that e.g. GPIO ID 11 always refers to EXT.3. With the new /dev interface you mention above, perhaps a symlink to the /dev file, or a file containing the /dev file's major/minor number. Or, is there such a thing already (other than debugfs's gpio file). Nothing I know of, but yes the day we come up with something, it needs to be backward-compatible some way. The problem is that there is really no reference userspace like lsgpio or so. Maybe the first step could be to create that. I don't know much about OpenWrt, but I've seen they have something: https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/char/gpio_dev.c https://dev.openwrt.org/browser/trunk/target/linux/generic/files/include/linux/gpio_dev.h https://dev.openwrt.org/browser/trunk/package/gpioctl/src/main.c Johannes -- 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/
Re: DT GPIO numbering?
On 8/6/2012 5:58 PM, Johannes Stezenbach wrote: On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote: On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren swar...@wwwdotorg.org wrote: I can't comment on the sysfs-vs-dev interface location, but I don't think it addresses Johannes' issue; finding out which GPIO IDs are provided by which devices. Perhaps in each device's sysfs node, there should be some information re: which GPIO range it provides. Right now, perhaps a text file with the GPIO base it it. Yes that could work ... The method used by the gpio-mxs.c driver (of_alias_get_id) would also work. The question is which method is preferable. Ideally I would like to use DT attributes to identify my GPIOs in the same way as they appear in the schematics. E.g. one device may have GPIOs called PORT_A.0 to PORT_A.7, another one may be EXT.0 to EXT.15. But a single integer ID is good enough since GPIO usage is platform specific anyway. However, the mapping must be static and not depend e.g. on module load order like now if you use pl061 and some i2c GPIO. Software must be able to rely on that e.g. GPIO ID 11 always refers to EXT.3. There is precedence for a slot-names property that correlates specific hardware entities with physical labels. It has been applied to PCI plug-in slots and to other devices. See, for example, http://www.openfirmware.org/1275/proposals/Closed/Accepted/381-it.txt With the new /dev interface you mention above, perhaps a symlink to the /dev file, or a file containing the /dev file's major/minor number. Or, is there such a thing already (other than debugfs's gpio file). Nothing I know of, but yes the day we come up with something, it needs to be backward-compatible some way. The problem is that there is really no reference userspace like lsgpio or so. Maybe the first step could be to create that. I don't know much about OpenWrt, but I've seen they have something: https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/char/gpio_dev.c https://dev.openwrt.org/browser/trunk/target/linux/generic/files/include/linux/gpio_dev.h https://dev.openwrt.org/browser/trunk/package/gpioctl/src/main.c Johannes ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- 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/
Re: DT GPIO numbering?
On 08/05/2012 04:06 AM, Linus Walleij wrote: > On Wed, Aug 1, 2012 at 5:22 PM, Johannes Stezenbach wrote: > >> I'm currently learning how Linux devicetree support works, >> here is one question I couldn't find an answer for. >> >> I understand that within the devicetree GPIOs are referenced by phandle, >> thus the numbers are irrelevant. However, in sysfs the number is >> what is used to access the GPIO, e.g. for debugging or >> blinkenlight apps. How does this fit together? > > I think it simply does not fit together. > > Grant & me has been claiming the GPIO sysfs interface is a bit > crazy from time to time. > > My long-term plan would be to replace it with /dev/gpio/gpioN > device nodes per-gpiochip and use ioctl etc to control these > beasts instead. However one does not do that overnight, > and my life is too busy, and other refactorings also need to > happen :-/ I can't comment on the sysfs-vs-dev interface location, but I don't think it addresses Johannes' issue; finding out which GPIO IDs are provided by which devices. Perhaps in each device's sysfs node, there should be some information re: which GPIO range it provides. Right now, perhaps a text file with the GPIO base it it. With the new /dev interface you mention above, perhaps a symlink to the /dev file, or a file containing the /dev file's major/minor number. Or, is there such a thing already (other than debugfs's gpio file). -- 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/
Re: DT GPIO numbering?
On Wed, Aug 1, 2012 at 5:22 PM, Johannes Stezenbach wrote: > I'm currently learning how Linux devicetree support works, > here is one question I couldn't find an answer for. > > I understand that within the devicetree GPIOs are referenced by phandle, > thus the numbers are irrelevant. However, in sysfs the number is > what is used to access the GPIO, e.g. for debugging or > blinkenlight apps. How does this fit together? I think it simply does not fit together. Grant & me has been claiming the GPIO sysfs interface is a bit crazy from time to time. My long-term plan would be to replace it with /dev/gpio/gpioN device nodes per-gpiochip and use ioctl etc to control these beasts instead. However one does not do that overnight, and my life is too busy, and other refactorings also need to happen :-/ Yours, Linus Walleij -- 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/
Re: DT GPIO numbering?
On Wed, Aug 1, 2012 at 5:22 PM, Johannes Stezenbach j...@sig21.net wrote: I'm currently learning how Linux devicetree support works, here is one question I couldn't find an answer for. I understand that within the devicetree GPIOs are referenced by phandle, thus the numbers are irrelevant. However, in sysfs the number is what is used to access the GPIO, e.g. for debugging or blinkenlight apps. How does this fit together? I think it simply does not fit together. Grant me has been claiming the GPIO sysfs interface is a bit crazy from time to time. My long-term plan would be to replace it with /dev/gpio/gpioN device nodes per-gpiochip and use ioctl etc to control these beasts instead. However one does not do that overnight, and my life is too busy, and other refactorings also need to happen :-/ Yours, Linus Walleij -- 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/
Re: DT GPIO numbering?
On 08/05/2012 04:06 AM, Linus Walleij wrote: On Wed, Aug 1, 2012 at 5:22 PM, Johannes Stezenbach j...@sig21.net wrote: I'm currently learning how Linux devicetree support works, here is one question I couldn't find an answer for. I understand that within the devicetree GPIOs are referenced by phandle, thus the numbers are irrelevant. However, in sysfs the number is what is used to access the GPIO, e.g. for debugging or blinkenlight apps. How does this fit together? I think it simply does not fit together. Grant me has been claiming the GPIO sysfs interface is a bit crazy from time to time. My long-term plan would be to replace it with /dev/gpio/gpioN device nodes per-gpiochip and use ioctl etc to control these beasts instead. However one does not do that overnight, and my life is too busy, and other refactorings also need to happen :-/ I can't comment on the sysfs-vs-dev interface location, but I don't think it addresses Johannes' issue; finding out which GPIO IDs are provided by which devices. Perhaps in each device's sysfs node, there should be some information re: which GPIO range it provides. Right now, perhaps a text file with the GPIO base it it. With the new /dev interface you mention above, perhaps a symlink to the /dev file, or a file containing the /dev file's major/minor number. Or, is there such a thing already (other than debugfs's gpio file). -- 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/
DT GPIO numbering?
Hi,
I'm currently learning how Linux devicetree support works,
here is one question I couldn't find an answer for.
I understand that within the devicetree GPIOs are referenced by phandle,
thus the numbers are irrelevant. However, in sysfs the number is
what is used to access the GPIO, e.g. for debugging or
blinkenlight apps. How does this fit together?
In the old days platform data was used, e.g.
struct pl061_platform_data {
/* number of the first GPIO */
unsignedgpio_base;
...
};
Now, when DT is used gpio-pl061.c sets gc.base = -1 (dynamic numbering).
Should there be a DT property to assign the number base?
Or is there some better way, e.g. in gpio-mxs.c the code derives
the gc.base from of_alias_get_id(np, "gpio").
Should gpio-pl061.c do the same?
And how about assigning gpio names? When a name is assigned to
the GPIO, is shows up in sysfs instead of gpio%d, however the
number is still needed for /sys/class/gpio/export, right?
Thanks,
Johannes
--
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/
DT GPIO numbering?
Hi,
I'm currently learning how Linux devicetree support works,
here is one question I couldn't find an answer for.
I understand that within the devicetree GPIOs are referenced by phandle,
thus the numbers are irrelevant. However, in sysfs the number is
what is used to access the GPIO, e.g. for debugging or
blinkenlight apps. How does this fit together?
In the old days platform data was used, e.g.
struct pl061_platform_data {
/* number of the first GPIO */
unsignedgpio_base;
...
};
Now, when DT is used gpio-pl061.c sets gc.base = -1 (dynamic numbering).
Should there be a DT property to assign the number base?
Or is there some better way, e.g. in gpio-mxs.c the code derives
the gc.base from of_alias_get_id(np, gpio).
Should gpio-pl061.c do the same?
And how about assigning gpio names? When a name is assigned to
the GPIO, is shows up in sysfs instead of gpio%d, however the
number is still needed for /sys/class/gpio/export, right?
Thanks,
Johannes
--
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/
