Hi Rob and Linus,
El 11/03/2021 a las 17:13, Linus Walleij escribió:
On Thu, Mar 11, 2021 at 3:58 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote:
On Wed, Mar 10, 2021 at 6:09 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
On Wed, Mar 10, 2021 at 6:51 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote:
+static const struct of_device_id bcm63xx_gpio_of_match[] = {
+ { .compatible = "brcm,bcm6318-gpio", },
+ { .compatible = "brcm,bcm6328-gpio", },
+ { .compatible = "brcm,bcm6358-gpio", },
+ { .compatible = "brcm,bcm6362-gpio", },
+ { .compatible = "brcm,bcm6368-gpio", },
+ { .compatible = "brcm,bcm63268-gpio", },
All these would be moved to gpio-mmio.c (or maybe that can have a
fallback compatible?).
This is gpio-regmap.c and it can only be used as a library
by a certain driver. gpio-mmio.c can be used stand-alone
for certain really simple hardware (though most use that
as a library as well).
I don't really care which one is used, but the problem is that this
choice is leaking into the binding design.
Aha I guess I misunderstood your comment.
The primary problem here is
once someone uses regmap, then they think they must have a syscon and
can abandon using 'reg' and normal address properties as Linux happens
to not use them (currently). I think we really need some better regmap
vs. mmio handling to eliminate this duplication of foo-mmio and
foo-regmap drivers and difference in binding design. Not sure exactly
what that looks like, but basically some sort of 'reg' property to
regmap creation.
I see the problem. Yeah we should try to be more strict around
these things. To me there are syscons and "other regmaps",
where syscon is a real hurdle of registers while "other regmaps"
are just regmaps by convenience.
Documentation/devicetree/bindings/mfd/syscon.yaml
describes what a syscon really is so if everyone could
just read the documentation that would be great ...
Given we already have a Broadcom GPIO binding for what looks to be
similar to this one, I'm left wondering what's the real difference
here?
Which one is similar? I can take a look.
@Linus I think @Rob is referring to brcm,bcm6345-gpio:
https://github.com/torvalds/linux/blob/a74e6a014c9d4d4161061f770c9b4f98372ac778/drivers/gpio/gpio-mmio.c#L686
However, the real difference between BCM6345 (and BCM6338) is that these
SoCs have no pin controller at all, only a GPIO controller:
BCM6345:
typedef struct GpioControl {
uint16 unused0;
byte unused1;
byte TBusSel;
uint16 unused2;
uint16 GPIODir;
byte unused3;
byte Leds;
uint16 GPIOio;
uint32 UartCtl;
} GpioControl;
BCM6338:
typedef struct GpioControl {
uint32 unused0;
uint32 GPIODir; /* bits 7:0 */
uint32 unused1;
uint32 GPIOio; /* bits 7:0 */
uint32 LEDCtrl;
uint32 SpiSlaveCfg;
uint32 vRegConfig;
} GpioControl;
BCM6348 and newer also have pinctrl.
That's the main difference between that driver @Rob's referring to and
the ones in this patch series.
We currently have four Broadcom GPIO bindings,
which are stand alone GPIO blocks and eight Broadcom
pin controllers that all do GPIO as well.
This family of pin controllers are (as per subject) is
the bcm63xx series which is a MIPS-based family of SoCs
found in routers, top bindings in
Documentation/devicetree/bindings/mips/brcm/soc.txt
These all have a GPIO block as part of the pin controller
and the GPIO block is a distinct sub-function of the
pin controller, and it has up to 32 GPIOs per block,
hence it has its own subnode inside the pin controller.
This driver follows the pattern of the Ingenic
pin controller, another MIPS SoC:
Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
Another SoC with several GPIO blocks inside the pin
controller is SparX5 and that also follows this pattern:
Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml
(This has an example with more than one GPIO block
inside the pin controller.)
Yours,
Linus Walleij
