Hi Rob,
> El 11 mar 2021, a las 19:24, Rob Herring <robh+dt@xxxxxxxxxx> escribió:
>
> On Thu, Mar 11, 2021 at 10:00 AM Álvaro Fernández Rojas
> <noltari@xxxxxxxxx> wrote:
>>
>> 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
>
> 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.
>
>>
>> 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.
