diff mbox

bcma: use device from DT (brcm,bus-gpio) for SoC GPIO chip

Message ID 1411741733-13888-1-git-send-email-zajec5@gmail.com
State New, archived
Headers show

Commit Message

Rafał Miłecki Sept. 26, 2014, 2:28 p.m. UTC
This will allow us to define GPIO-attached devices (LEDs, buttons) in
the the device tree.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
This is based on top of
[PATCH v6] bcma: register bcma as device tree driver
that I hope will reach wireless-next git tree.
---
 Documentation/devicetree/bindings/bus/bcma.txt | 15 +++++++++++++++
 drivers/bcma/driver_gpio.c                     |  5 +++++
 2 files changed, 20 insertions(+)

Comments

Arnd Bergmann Sept. 26, 2014, 10:03 p.m. UTC | #1
On Friday 26 September 2014 16:28:53 Rafał Miłecki wrote:
> +The top-level axi bus may contain following children:
> +
> +- gpio: GPIO chip on the SoC
> +
> +  Required properties:
> +  - compatible: "brcm,bus-gpio"
> +  - gpio-controller : makes the node a GPIO controller
> +  - #gpio-cells : size of the GPIO specifier, must be 2
> +
> 

I wonder if it would be better to avoid the subnode here and just
make the parent itself the gpio controller.

Is the gpio controller part of the bus itself in reality, or is it
a device that gets probed on the bus?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafał Miłecki Sept. 27, 2014, 8:05 a.m. UTC | #2
On 27 September 2014 00:03, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 26 September 2014 16:28:53 Rafał Miłecki wrote:
>> +The top-level axi bus may contain following children:
>> +
>> +- gpio: GPIO chip on the SoC
>> +
>> +  Required properties:
>> +  - compatible: "brcm,bus-gpio"
>> +  - gpio-controller : makes the node a GPIO controller
>> +  - #gpio-cells : size of the GPIO specifier, must be 2
>> +
>>
>
> I wonder if it would be better to avoid the subnode here and just
> make the parent itself the gpio controller.
>
> Is the gpio controller part of the bus itself in reality, or is it
> a device that gets probed on the bus?

I'm not sure how to treat this chip.
We control GPIOs using ChipCommon regs (and ChipCommon is one of
cores/devices on the bus), so you could also consider GPIO chip a
sub-device of ChipCommon.
I believe every Broadcom bus has a GPIO chip. In the ancient (MIPS)
times, even if we didn't have ChipCommon, there was an EXTIF core that
used to provide access to the GPIO chip.

What do you think? Should I make it separated device, even it if
depends on the SoC and its ChipCommon core (device)?
Hauke Mehrtens Sept. 27, 2014, 8:33 a.m. UTC | #3
On 09/27/2014 10:05 AM, Rafał Miłecki wrote:
> On 27 September 2014 00:03, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Friday 26 September 2014 16:28:53 Rafał Miłecki wrote:
>>> +The top-level axi bus may contain following children:
>>> +
>>> +- gpio: GPIO chip on the SoC
>>> +
>>> +  Required properties:
>>> +  - compatible: "brcm,bus-gpio"
>>> +  - gpio-controller : makes the node a GPIO controller
>>> +  - #gpio-cells : size of the GPIO specifier, must be 2
>>> +
>>>
>>
>> I wonder if it would be better to avoid the subnode here and just
>> make the parent itself the gpio controller.
>>
>> Is the gpio controller part of the bus itself in reality, or is it
>> a device that gets probed on the bus?
> 
> I'm not sure how to treat this chip.
> We control GPIOs using ChipCommon regs (and ChipCommon is one of
> cores/devices on the bus), so you could also consider GPIO chip a
> sub-device of ChipCommon.
> I believe every Broadcom bus has a GPIO chip. In the ancient (MIPS)
> times, even if we didn't have ChipCommon, there was an EXTIF core that
> used to provide access to the GPIO chip.
> 
> What do you think? Should I make it separated device, even it if
> depends on the SoC and its ChipCommon core (device)?
> 
I would make GPIO a subdevive of chipcommon. The chipcommon core has an
own IRQ which is also used for GPIO.

Hauke
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafał Miłecki Sept. 27, 2014, 10:37 a.m. UTC | #4
On 27 September 2014 10:33, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> I would make GPIO a subdevive of chipcommon. The chipcommon core has an
> own IRQ which is also used for GPIO.

Which ChipCommon do yo mean?
1) chipcommonA (compatible = "simple-bus")
2) chipcommon@0 (child of axi@18000000 AKA brcm,bus-axi)

It seems that for some reason both of them use IRQ 85, while the IRQ
for ChipCommon is 117 I believe.
Hauke Mehrtens Sept. 27, 2014, 8:47 p.m. UTC | #5
On 09/27/2014 12:37 PM, Rafał Miłecki wrote:
> On 27 September 2014 10:33, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>> I would make GPIO a subdevive of chipcommon. The chipcommon core has an
>> own IRQ which is also used for GPIO.
> 
> Which ChipCommon do yo mean?
> 1) chipcommonA (compatible = "simple-bus")
> 2) chipcommon@0 (child of axi@18000000 AKA brcm,bus-axi)

We should combine this (both are describing the same core) I added
chipcommonA to get some serial without adding bcma support first. When
we have dts support added to bcma, I would like to remove chipcommonA
from dtsi and add a chipcommon as a child of axi.

> 
> It seems that for some reason both of them use IRQ 85, while the IRQ
> for ChipCommon is 117 I believe.

That's the same.

In the dtsi file it says:
interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
this will result in the IRQ number 117, when it is GIC_SPI you have to
add 32 to the irq number to get the actual number which will be given to
request_irq().

Hauke
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/bus/bcma.txt b/Documentation/devicetree/bindings/bus/bcma.txt
index e9070c1..f1b381e 100644
--- a/Documentation/devicetree/bindings/bus/bcma.txt
+++ b/Documentation/devicetree/bindings/bus/bcma.txt
@@ -6,6 +6,15 @@  Required properties:
 
 - reg : iomem address range of chipcommon core
 
+The top-level axi bus may contain following children:
+
+- gpio: GPIO chip on the SoC
+
+  Required properties:
+  - compatible: "brcm,bus-gpio"
+  - gpio-controller : makes the node a GPIO controller
+  - #gpio-cells : size of the GPIO specifier, must be 2
+
 The cores on the AXI bus are automatically detected by bcma with the
 memory ranges they are using and they get registered afterwards.
 
@@ -17,4 +26,10 @@  Example:
 		ranges = <0x00000000 0x18000000 0x00100000>;
 		#address-cells = <1>;
 		#size-cells = <1>;
+
+		gpio@0 {
+			compatible = "brcm,bus-gpio";
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
 	};
diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c
index 8ea497c..7ae39a8 100644
--- a/drivers/bcma/driver_gpio.c
+++ b/drivers/bcma/driver_gpio.c
@@ -218,6 +218,11 @@  int bcma_gpio_init(struct bcma_drv_cc *cc)
 #if IS_BUILTIN(CONFIG_BCM47XX)
 	chip->to_irq		= bcma_gpio_to_irq;
 #endif
+#if IS_BUILTIN(CONFIG_OF)
+	if (cc->core->bus->hosttype == BCMA_HOSTTYPE_SOC)
+		chip->of_node	= of_find_compatible_node(NULL, NULL,
+							  "brcm,bus-gpio");
+#endif
 	switch (cc->core->bus->chipinfo.id) {
 	case BCMA_CHIP_ID_BCM5357:
 	case BCMA_CHIP_ID_BCM53572: