pinctrl: add bcm2708 driver

[notro]

This driver is a verbatim copy of the pinctrl-bcm2835 driver, except for:

• changed 2835 to 2708
• gpio_chip and IRQ part are removed
• Probing function is changed.

Because armctrl sets up the gpio irqs, we use the bcm2708_gpio driver.
This hack is used to be able to support both DT and non-DT builds.

Binding document: brcm,bcm2835-gpio.txt
It's not possible to set trigger type and level flags for IRQs in the DT.

Signed-off-by: Noralf Tronnes notro@tronnes.org

[notro]

Test

Pin states

# the gpio utility is from WiringPi
$ gpio readall
+----------+-Rev2-+------+--------+------+-------+
| wiringPi | GPIO | Phys | Name   | Mode | Value |
+----------+------+------+--------+------+-------+
|      0   |  17  |  11  | GPIO 0 | IN   | Low   |
|      1   |  18  |  12  | GPIO 1 | IN   | Low   |
|      2   |  27  |  13  | GPIO 2 | IN   | Low   |
|      3   |  22  |  15  | GPIO 3 | IN   | Low   |
|      4   |  23  |  16  | GPIO 4 | IN   | Low   |
|      5   |  24  |  18  | GPIO 5 | IN   | Low   |
|      6   |  25  |  22  | GPIO 6 | IN   | Low   |

Add patch

diff --git a/arch/arm/boot/dts/bcm2708-rpi-b.dts b/arch/arm/boot/dts/bcm2708-rpi-b.dts
index e319c8e..28e9713 100644
--- a/arch/arm/boot/dts/bcm2708-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2708-rpi-b.dts
@@ -6,3 +6,37 @@
        compatible = "brcm,bcm2708";
        model = "Raspberry Pi";
 };
+
+&gpio {
+       pinctrl-names = "default";
+       pinctrl-0 = <&pullup_test &function_test>;
+
+/*
+- brcm,pull: Integer, representing the pull-down/up to apply to the pin(s):
+  0: none
+  1: down
+  2: up
+*/
+       pullup_test: test1 {
+               brcm,pins = <17>;
+               brcm,function = <0>;
+               brcm,pull = <2>;
+       };
+
+/*
+- brcm,function: Integer, containing the function to mux to the pin(s):
+  0: GPIO in
+  1: GPIO out
+  2: alt5
+  3: alt4
+  4: alt0
+  5: alt1
+  6: alt2
+  7: alt3
+*/
+       function_test: test0 {
+               brcm,pins = <18 27 22 23 24 25>;
+               brcm,function = <2 3 7 0 1 1>;
+       };
+
+};

Pin states

$ gpio readall
+----------+-Rev2-+------+--------+------+-------+
| wiringPi | GPIO | Phys | Name   | Mode | Value |
+----------+------+------+--------+------+-------+
|      0   |  17  |  11  | GPIO 0 | IN   | High  |
|      1   |  18  |  12  | GPIO 1 | ALT5 | Low   |
|      2   |  27  |  13  | GPIO 2 | ALT4 | Low   |
|      3   |  22  |  15  | GPIO 3 | ALT3 | High  |
|      4   |  23  |  16  | GPIO 4 | IN   | Low   |
|      5   |  24  |  18  | GPIO 5 | OUT  | Low   |
|      6   |  25  |  22  | GPIO 6 | OUT  | Low   |

Kernel debug messages: https://gist.github.com/notro/3c9258688f2fd8ad280d

[notro]

Seems you're right: Ranges (Address Translation)

[popcornmix]

Interesting. I wonder if we could handle BCM2708_NOL2CACHE:
https://github.com/raspberrypi/linux/blob/rpi-3.12.y/arch/arm/mach-bcm2708/include/mach/memory.h

through this mechanism. It's something configured by the GPU, and the kernel config option needs to match the GPU option (disable_l2cache in config.txt) for boot to work, so it would be cleaner if firmware populated the "bus" offset and a single kernel image could be used for both modes.

[notro]

This is the formal specification: 2.3.8 ranges (page26)

[popcornmix]

This looks wrong (upstream)
https://github.com/raspberrypi/linux/blob/rpi-3.15.y/arch/arm/boot/dts/bcm2835.dtsi#L114
All other nodes use the 7e address.

For info:
Bus: 0x7e000000 Physical: 0x20000000 Length: 0x02000000
Bus: 0x40000000 Physical: 0x00000000 Length: 0x20000000

and when BCM2708_NOL2CACHE is enabled:
Bus: 0xC0000000 Physical: 0x00000000 Length: 0x20000000

I'm not sure where the physical to bus mapping is described in the upstream world.
I would have thought a ranges node in the device tree would make sense.

[notro]

This looks wrong (upstream)

It doesn't affect functionality since it's the reg property that carries the address. The norm is to put the address in the name. Clearly a misspelling here.

Bus: 0x40000000 Physical: 0x00000000 Length: 0x20000000

What's this?

I'm not sure where the physical to bus mapping is described in the upstream world.
I would have thought a ranges node in the device tree would make sense.

What do you mean? It's decribed in the ranges property on the soc bus isn't it?

[notro]

I see now that I use 'axi' instead of 'soc' as it's done upstream. I belive this was because the VC bootloader adds some info to the axi tree (mac address etc.).

[popcornmix]

What's this?
See the BUS address description here:
http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

When the ARM accesses physical address 0, it goes through a mapping to a bus address which results in 0x40000000 (when L2 enabled) or 0xC0000000 (when disabled).
Normally the ARM doesn't care, but if it wants to use DMA which uses bus addresses, or communicate addresses to GPU, then it needs to know the physical->bus mapping.

This is handled through BUS_OFFSET here:
https://github.com/raspberrypi/linux/blob/rpi-3.12.y/arch/arm/mach-bcm2708/include/mach/memory.h#L51

I'm trying to work out where this mapping happens in device tree world. It seems a ranges node would make sense, but I don't see that in the 2835 device tree.

[popcornmix]

I see now that I use 'axi' instead of 'soc' as it's done upstream. I belive this was because the VC bootloader adds some info to the axi tree (mac address etc.).

If you would prefer VC bootloader to fill in different nodes to fit in with upstream better, then let me know what the changes should be.

[notro]

Is IOMMU the part responsible for such bus mapping?
Found this: ARM DMA-Mapping Framework Redesign and IOMMU integration

I guess one should find references to this in DMA related drivers like:
http://lxr.free-electrons.com/source/drivers/dma/bcm2835-dma.c
http://lxr.free-electrons.com/source/sound/soc/bcm/bcm2835-i2s.c

bcm2835-i2s.c has this:

/* I2S DMA interface */
/* FIXME: Needs IOMMU support */
#define BCM2835_VCMMU_SHIFT             (0x7E000000 - 0x20000000)

        /* Set the DMA address */
        dev->dma_data[SNDRV_PCM_STREAM_PLAYBACK].addr =
                (dma_addr_t)mem[0]->start + BCM2835_I2S_FIFO_A_REG
                                          + BCM2835_VCMMU_SHIFT;

        dev->dma_data[SNDRV_PCM_STREAM_CAPTURE].addr =
                (dma_addr_t)mem[0]->start + BCM2835_I2S_FIFO_A_REG
                                          + BCM2835_VCMMU_SHIFT;

[notro]

If you would prefer VC bootloader to fill in different nodes to fit in with upstream better, then let me know what the changes should be.

Yes, it's best changing axi to soc since this is part of an upstreaming effort. I'll make a PR later.
We can deal with the bootloader changes when we need them.

[popcornmix]

The physical->bus mapping is a kind of mmu, but not a standard arm one.
The GPU sets up a coarse (64 entries of 16M) mapping table that arm accesses go through before reaching the bus.
bcm2835-i2s.c seems to be mapping the peripheral addresses (although surely that use the DT?) but there should also be a mapping for sdram addresses (mapping 0x00000000 -> 0x40000000).