Page MenuHomeFreeBSD

Add GPIO MUX support on AR934x and AR1321

Authored by on Mon, May 6, 10:57 AM.



This is GPIO MUX support on AR934x and AR1321


This meen GPIO12 is SPI chip select 1(7).

Value is in AR9344 datasheet at page 53.

This is dmesg.

Test Plan

on AR1321

Diff Detail

rS FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

adrian accepted this revision.Thu, May 9, 2:20 AM

looks good! i'll go commit it tonight.

This revision is now accepted and ready to land.Thu, May 9, 2:20 AM
adrian requested changes to this revision.Sun, May 12, 9:32 PM

so it turns out this isn't "right". There's already a way to configure the output function for the SoC side GPIO pins. look at the existing gpiofunc/gpiomode. That's what gpiofunc does (and gpiomode=1 just says "make it output, value low as a default"). It's only useful for AR934x and later.

Can you try:


.. and see if that has the same effect? if so then great! We don't need this (but we need something different for AR933x..)

This revision now requires changes to proceed.Sun, May 12, 9:32 PM
  • delete new impliment and change logic

    Sorry I miss alrady impliment this. But AR934x gpio mux function need

oe=0. I do modify for this.


This is log.

gpio0: <Atheros AR71XX GPIO driver> at mem 0x18040000-0x18040fff irq 2 on apb0
gpio0: function_set: 0x0
gpio0: function_clear: 0x0
gpio0: gpio pinmask=0x7da000
gpio0: ar71xx_gpio_attach: GPIO 12: func=7, mode=0
gpiobus0: <GPIO bus> on gpio0
gpioled0: <GPIO led> at pin 15 on gpiobus0
gpioled1: <GPIO led> at pin 13 on gpiobus0
gpioled2: <GPIO led> at pin 18 on gpiobus0
gpioc0: <GPIO controller> on gpio0
spi0: <AR71XX SPI> at mem 0x1f000000-0x1f00000f on nexus0
spibus0: <SPI bus> on spi0
mx25l0: <M25Pxx Flash Family> at cs 0 mode 0 on spibus0
mx25l1: <M25Pxx Flash Family> at cs 1 mode 0 on spibus0
GEOM: new disk flash/spi0
GEOM: new disk flash/spi1
MAP: flash/spi0: 0x40000, data=0x40000 "/dev/map/bootloader"
MAP: flash/spi0: 40000x3a0000, data=0x3a0000 "/dev/map/upgrade"
MAP: search flash/spi0 for key ".!/bin/sh" from 0x100000, step 0x10000
MAP: flash/spi0: 40000xf0000, data=0xf0000 "/dev/map/kernel"
MAP: search flash/spi0 for key ".!/bin/sh" from 0x100000, step 0x10000
MAP: flash/spi0: 130000x2b0000, data=0x2b0000 "/dev/map/rootfs"
MAP: flash/spi0: 3f0000x10000, data=0x10000 "/dev/map/ART"
MAP: flash/spi1: 0x400000, data=0x400000 "/dev/map/local"
MAP: No valid partition found at flash/spi1.uzip

oh interesting. er, so i know this is asking a lot but I'm trying to understand explicitly what the hardware setup is.

the idea was setting output would set OE to "output", which on the AR9344 clears the bit. (check ar71xx_gpio_oe_set_output()). Is the SPI chip select pin supposed to NOT be configured as an ouput? what's the value of the AR71XX_GPIO_OE register?

I'd rather have it explicitly be called out. Ie, gpiomode=0 == leave, gpiomode=1 == output, gpiomode=2 == input. Does SPI work if you instead call gpio_oe_set_input() ?


AR9344 data sheet say.

For example, to drive the SPI_CLK signal through the GPIO4 pin:

  1. Set bit[4] of “GPIO Output Enable (GPIO_OE)” register to 0.
  1. Set the 8-bit field ENABLE_GPIO4 (bits [7:0]) of the “GPIO Function 1 (GPIO_OUT_FUNCTION1)” register to 10.For example, to drive the SPI_CLK signal through the GPIO4 pin:

ok, so can you add:

if (gpiomode == 2)

ar71xx_gpio_oe_set_input(sc, i);

.. and then try gpiomode=2 ? That explicitly sets it to 0 on the ar9344. If that works then I'll add that!

I checked code and I think this problem is case of ar71xx_gpio_oe_is_high().

I think same AR9341 and AR9344. But ar71xx_gpio_oe_is_high don' have AR9341.

I think add AR9341 and AR9342 to ar71xx_gpio_oe_is_high.

My target is AR1321. AR1321 is same as AR9341.

Sorry my miss reading.

ooooh ok. yeah maybe we should add that CPU to the detected list?

  • add cpu type to ar71xx_gpio_oe_is_high()

Now work fine this hints.


This revision was not accepted when it landed; it landed in state Needs Review.Wed, May 15, 4:51 PM
This revision was automatically updated to reflect the committed changes.