On Thu, Mar 11, 2021 at 10:00 AM Álvaro Fernández Rojas
[off-list ref] wrote:

Hi Rob and Linus,

El 11/03/2021 a las 17:13, Linus Walleij escribió:

quoted

On Thu, Mar 11, 2021 at 3:58 PM Rob Herring [off-list ref] wrote:

quoted

On Wed, Mar 10, 2021 at 6:09 PM Linus Walleij [off-list ref] wrote:

quoted

On Wed, Mar 10, 2021 at 6:51 PM Rob Herring [off-list ref] wrote:

quoted

quoted

+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.

quoted

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 ...

quoted

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

Well, since it's the bindings we're talking about:
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.txt

Which says this:
"These bindings can be used on any BCM63xx SoC. However, BCM6338 and
BCM6345 are the only ones which don't need a pinctrl driver."

Not that the 1 in tree user of this is perfect. Seems like it too
should be a child of a system controller if there's other registers.

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel