Re: BeagleBone Black and GPIO issues

[Brook Milligan <brook%nmsu.edu@localhost>]

> On Oct 20, 2024, at 2:15 PM, Lloyd Parkes <lloyd%must-have-coffee.gen.nz@localhost> wrote:
> 
> The fdtbus framework provides a pin controller driver for the BBB.
> There are two problems with us using this framework for GPIO, this
> first is difficult and the second is insurmountable.
> 
> The first problem is that pin changes (such as pullups) need to be
> passed up the protocol stack to the ftdbus framework and them come back
> down the stack to the pin controller. This is slightly inefficient and
> might not play well with systems that I timing sensitive.
> 
> The second problem is that the data being passed up and down the
> "protocol stack" is raw DTB data. There is little chance we are going
> to be generating that data format in the kernel.

It sounds like you are focusing on how other drivers could access the pinctrl driver.  Am I understanding correctly?  No doubt that would be ideal.

However, from the perspective of userland control of gpio state, why is that needed?  When does a driver need access to the control module?  For now, drivers seem to do fine ignoring it.

Could there not be a separate driver for the BBB control registers with appropriate ioctl functions?  Then, for example, gpioctl or other userland programs could inspect or modify the gpio state, both in the gpio registers and the control registers.  I think that covers the cases that have been mentioned so far, but perhaps I’m misunderstanding.

In any case, it might be a useful and doable starting pathway.

Cheers,
Brook