Messages in this thread | | | Subject | Re: [PATCH 2/2] gpio: sch: Add interrupt support | From | Jan Kiszka <> | Date | Fri, 26 Apr 2019 19:52:48 +0200 |
| |
On 26.04.19 19:46, Manivannan Sadhasivam wrote: > On Fri, Apr 26, 2019 at 07:39:56PM +0200, Jan Kiszka wrote: >> On 26.04.19 19:33, Manivannan Sadhasivam wrote: >>> On Fri, Apr 26, 2019 at 08:20:19PM +0300, Andy Shevchenko wrote: >>>> On Fri, Apr 26, 2019 at 7:05 PM Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>>> >>>>> On 26.04.19 16:42, Enrico Weigelt, metux IT consult wrote: >>>>>> On 26.04.19 15:36, Jan Kiszka wrote: >>>>>> >>>>>>> At the same time, there are no real alternatives - to my> knowledge - for the value it brings (various bindings) to simply >>>>>> switch> the engine. >>>>>> Which value exactly does that collection of crude wrappers and broken >>>>>> attempts to buypass the kernel (driving gpios via /dev/mem *facepalm*) >>>>>> provide ? >>>>> >>>>> Leaving that blunt hack aside: >>>>> >>>>> import mraa >>>>> >>>>> pin = mraa.Gpio(13) >>>>> pin.dir(mraa.DIR_OUT) >>>>> pin.write(1) >>>>> >>>>> And the same goes for nodejs, java and c++. >>>>> >>>>> Moreover, this allows you to abstract away where "Pin 13" actually came from on >>>>> that board if the kernel changes (BSP -> upstream...) or the extension board or >>>>> ... >>>> >>>> The problem here is opaque number. This has to be chip + *relative* pin number/ >>>> See this: >>>> https://stackoverflow.com/questions/55532410/how-do-linux-gpio-numbers-get-their-values/55579640#55579640 >>>> >>> >>> But for platform like 96Boards we don't need controller specific lookup, these >>> are all handled by the platform code [1] so that the users can use the standard >>> pinout number to access GPIOs. For instance, pin 23 on the Low Speed expansion >>> header is the GPIO for all 96Boards platform, so the user can access that pin >>> using 23 itself in the application and it will run across all supported >>> 96Boards. >> >> Can you ensure stable numbering when probing order changes, e.g. due to >> adding an extension board? >> > > Good point! For tackling this, I'm planning to introduce an API for accessing > the GPIO by its line name. It will be tricky to implement but once done, it > will serve.
Whatever is stable and handy. As cited in the other thread, I played with the device path as well, see [1][2]. Feel free to pick what what is useful, I will likely not have time to work on that soon again.
Jan
[1] https://github.com/siemens/mraa/commit/034d787eea1a5b201ea77a6549ffc0bdbc3b776d [2] https://github.com/siemens/mraa/commit/6fd8a3c27764718c1e62a4938a6dc88819c3f65f
-- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
| |