Re: BeagleBone Black and GPIO issues

[Lloyd Parkes <lloyd%must-have-coffee.gen.nz@localhost>]

On Sun, 2024-10-13 at 18:57 -0600, Brook Milligan wrote:
> Thanks for this.  However, this is also where I get confused, because
> these numbers do not seem to agree with the TRM, which for reference
> is available here:
> these numbers do not seem to agree with the TRM, which for reference
> is available here:


Yes. That's why it hasn't been implemented yet. The GPIO is in one
place in the memory map and the pin control is somewhere completely
different. 


> The tigpio driver (arch/arm/ti/ti_gpio.c) maps its address space with
> the following call:

	bus_space_map(sc->sc_bst, addr, size, 0, &sc->sc_bsh)

and then uses sc->sc_bst and sc->sc_bsh for all the
> reads/writes.  This seems to imply that the driver is accessing only
> the block of GPIO registers beginning at one of the addresses above,
> none of which control, for example, pull-up/pull-down state.

...
> Does this mean that, if pull-up/pull-down state is to be made
> available, a new driver is required to access the control module
> registers?

If you are doing a proper job, then maybe. If not an actual driver then
something close to one. This is the part I haven't researched, which is
why my only ideas right now involve vile hacks.

> 
> This looks substantially more complicated than a tweak to the tigpio
> driver, but I would like to be proven wrong.  Perhaps this is not so
> complicated for a driver wizard?
> 

I suspect there hasn't been a sufficient confluence of FDT pinctrl
understanding and BBB hardware to make this happen. Neither should be
super difficult, but we need both. Also, TI's documentation doesn't
help with it's barking made register names.

I honestly don't mind if someone creates a PR and assigns it to me. I'm
happy to pick up that work once I have reworked my patches for Zynq
ethernet PHYs. Obviously I'm happy to build on and use any information
and work others produce as well.

Ngā mihi,
Lloyd