Hi Rob,

El 11 mar 2021, a las 19:24, Rob Herring [off-list ref] escribió:

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

quoted

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

Yes, I know because I’m the author of that driver…
What I meant at that time is that it could be used temporarily until a proper “full” pinctrl driver was added.

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.

There are other registers, but dirout and data registers are contiguous and separate from the others.

quoted

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.

Best regards,
Álvaro.


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