[PATCH 03/13] dt-bindings: mmc: vt8500-sdmmc: Convert to YAML
Alexey Charkov
alchark at gmail.com
Fri Apr 18 05:38:40 PDT 2025
On Thu, Apr 17, 2025 at 10:25 AM Alexey Charkov <alchark at gmail.com> wrote:
>
> On Thu, Apr 17, 2025 at 12:14 AM Rob Herring <robh at kernel.org> wrote:
> >
> > On Wed, Apr 16, 2025 at 12:21:28PM +0400, Alexey Charkov wrote:
> > > Rewrite the textual description for the WonderMedia SDMMC controller
> > > as YAML schema, and switch the filename to follow the compatible
> > > string.
> > >
> > > Signed-off-by: Alexey Charkov <alchark at gmail.com>
> > > ---
> > > .../devicetree/bindings/mmc/vt8500-sdmmc.txt | 23 --------
> > > .../devicetree/bindings/mmc/wm,wm8505-sdhc.yaml | 61 ++++++++++++++++++++++
> > > MAINTAINERS | 1 +
> > > 3 files changed, 62 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/mmc/vt8500-sdmmc.txt b/Documentation/devicetree/bindings/mmc/vt8500-sdmmc.txt
> > > deleted file mode 100644
> > > index d7fb6abb3eb8c87e698ca4f30270c949878f3cbf..0000000000000000000000000000000000000000
> > > --- a/Documentation/devicetree/bindings/mmc/vt8500-sdmmc.txt
> > > +++ /dev/null
> > > @@ -1,23 +0,0 @@
> > > -* Wondermedia WM8505/WM8650 SD/MMC Host Controller
> > > -
> > > -This file documents differences between the core properties described
> > > -by mmc.txt and the properties used by the wmt-sdmmc driver.
> > > -
> > > -Required properties:
> > > -- compatible: Should be "wm,wm8505-sdhc".
> > > -- interrupts: Two interrupts are required - regular irq and dma irq.
> > > -
> > > -Optional properties:
> > > -- sdon-inverted: SD_ON bit is inverted on the controller
> > > -
> > > -Examples:
> > > -
> > > -sdhc at d800a000 {
> > > - compatible = "wm,wm8505-sdhc";
> > > - reg = <0xd800a000 0x1000>;
> > > - interrupts = <20 21>;
> > > - clocks = <&sdhc>;
> > > - bus-width = <4>;
> > > - sdon-inverted;
> > > -};
> > > -
> > > diff --git a/Documentation/devicetree/bindings/mmc/wm,wm8505-sdhc.yaml b/Documentation/devicetree/bindings/mmc/wm,wm8505-sdhc.yaml
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..a7d962bc13c7ff70b50448201b0416efc7f787af
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mmc/wm,wm8505-sdhc.yaml
> > > @@ -0,0 +1,61 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/mmc/wm,wm8505-sdhc.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: WonderMedia SOC SoC SDHCI Controller
> > > +
> > > +maintainers:
> > > + - Alexey Charkov <alchark at gmail.com>
> > > +
> > > +allOf:
> > > + - $ref: mmc-controller.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > + oneOf:
> > > + - const: wm,wm8505-sdhc
> > > + - items:
> > > + - const: wm,wm8650-sdhc
> > > + - const: wm,wm8505-sdhc
> > > + - items:
> > > + - const: wm,wm8750-sdhc
> > > + - const: wm,wm8505-sdhc
> > > + - items:
> > > + - const: wm,wm8850-sdhc
> > > + - const: wm,wm8505-sdhc
> >
> > Combine the last 3 entries into 1 using 'enum' for the 1st compatible.
>
> Fair enough, will do.
>
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + clocks:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + items:
> > > + - description: SDMMC controller interrupt
> > > + - description: SDMMC controller DMA interrupt
> > > +
> > > + sdon-inverted:
> > > + type: boolean
> > > + description: SD_ON bit is inverted on the controller
> >
> > This implies I know what the non-inverted state is. If you know, please
> > state that here.
>
> This is a tricky one. The only answer I have is "it's inverted in
> later versions vs. the first version I saw in the wild, and I'm not
> sure if it's board related or IP version related - nor if the original
> was active low or high". No docs, no schematics, no vendor left around
> to chase for answers.
>
> Will dig around some more and update the description if I succeed in
> uncovering any further clues :)
I've found some extra clues and would like to consult on the best way forward.
It turns out (if my understanding of the decompiled binary-only WM8505
vendor driver is correct) that all chips before (not including) WM8505
rev. A2 treated their "clock stop" bit (register offset 0x08 a.k.a.
SDMMC_BUSMODE, bit 0x10 a.k.a. BM_CST in vendor sources, BM_SD_OFF in
mainline) as "set 1 to disable SD clock", while all the later versions
treated it as "set 0 to disable SD clock". Which means that there are
WM8505 based systems that rely on either of those behaviours, while
any later chips need "set 0 to disable". This is not a board related
quirk but an on-chip SDMMC controller revision related quirk.
I'd love to switch to a compatible-based logic and drop the
"sdon-inverted" flag altogether from the binding I'm writing, but here
are my doubts where I'd love to consult.
* Looks like WM8505 rev. A2 needs a separate compatible string vs.
prior WM8505. Can we have something like "wm,wm8505a2-sdhc" and
"wm,wm8505-sdhc" respectively? WM8505a2 not being an actual chip name,
but something discoverable by reading its hardware ID from a system
configuration register at runtime
* If I introduce new compatible strings for "wm,wm8650-sdhc",
"wm,wm8750-sdhc", "wm,wm8850-sdhc" and "wm,wm8880-sdhc" in bindings,
DTS and driver code, then the new driver and new DTB should work fine,
and the DTS should pass schema checks. New driver code won't work with
older DTB unless I keep the logic to parse "sdon-inverted" which
wouldn't be part of the binding. Old driver code would not work with
newer DTB except for pre-A2 versions of WM8505. Is that acceptable?
* Existing DTS doesn't differentiate between pre-A2 vs. post-A2
revisions of WM8505 and is bound to fail on the latter
I realize that breaking backward/forward compatibility is undesirable,
but frankly these systems seem to have few mainline users, and those
people who do run mainline on them ought to be compiling the kernel
and its DTB at the same time, because the firmware doesn't know
anything about DT and any modern kernel can only be booted in
"appended DTB" mode. I also don't know of any non-Linux code that
might be using these device trees.
Any guidance would be much appreciated.
Best regards,
Alexey
More information about the linux-arm-kernel
mailing list