| Message ID | 1411741733-13888-1-git-send-email-zajec5@gmail.com |
|---|---|
| State | Needs Review / ACK, archived |
| Headers | show |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | warning | total: 1 errors, 0 warnings, 0 lines checked |
| robh/patch-applied | success |
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
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)?
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
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.
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 --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:
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(+)