Re: BeagleBone Black and GPIO issues

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

> On Oct 13, 2024, at 4:26 PM, Lloyd Parkes <lloyd%must-have-coffee.gen.nz@localhost> wrote:
> 
> Warning: It's been a while since I use the bus_space stuff and the
> following might be (mis)guided by how I would implement it instead of
> how it is actually implemented.

Please chime in if you know somethiing that will keep this on the rails. :)

> The numbers to use come from the FDT, although hard coding them during
> initial prototyping works too.
> 
> To read/write a 32 bit value you will use bus_space_read/write_4 with
> an appropriate handle.
> 
>        bus_space_map(SPACE, ADDRESS, SIZE, 0, &HANDLE);
>        ...
>        value = bus_space_read_4(SPACE, HANDLE, offset);
>        value |= 0x80;
>        bus_space_write_4(SPACE, HANDLE, offset, value);
> 
> The SPACE comes from your autoconf parent in the attach args. ADDRESS
> and SIZE comes from the FDT, but as a filthy dirty hack that does not
> belong in CVS you can set the ADDRESS to be 0x44e10000 and the size to
> be 0x2000. The offsets are then the offsets docement on chapter 9 of
> AM335x and AMIC110 Sitara™ Processors Technical Reference Manual (Rev.
> Q). The offsets you care about are 0x800 - 0xa34.

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:

	https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf

As an example, let’s take the kernel devices probed the by NetBSD 10 kernel (apparently, -current swaps the first two):

	tigpio0 at tisysc4: GPIO (gpio@4804c000)
	tigpio1 at tisysc8: GPIO (gpio@44e07000)
	tigpio2 at tisysc40: GPIO (gpio@481ac000)
	tigpio3 at tisysc41: GPIO (gpio@481ae000)

The TRM memory map (section 2.1, pp. 177ff) indicates that the 4kb block starting at each of those addresses are GPIO registers.

In TRM section 25.4.1 (pp. 4990ff) the GPIO registers are described in detail.  These registers control interrupts, clocks, data in/out, level detection, debouncing, etc.

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.

However, TRM chapter 9 (pp. 1448ff) describes the control module registers, which are mapped to a 64kb block starting at 0x44e1000.  These control I/O multiplexing and device status for individual CPU pads.  Specifically, these registers control the MUX mode, pull-up/pull-down mode, receiver enabled/disabled, etc. (TRM section 9.2.2, pp. 1449ff).  TRM section 9.3.1 (pp. 1458ff) lists the register offsets for each individual pad.  More specifically, TRM section 9.3.1.50 (p. 1515) lists the control registers for GPIO pads.  To check or control the pull-up/pull-down state of a GPIO pin, for example, reads/writes to offsets in the range 0x800-0xa34 (e.g., to 0x44e1000 + 0x800) are required.   However, these addresses are outside the memory space accessible to the tigpio driver.

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?

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?

Cheers,
Brook