[PATCH 0/4] Add SDHI2 support to iwg23s

[PATCH 0/4] Add SDHI2 support to iwg23s

[Fabrizio Castro]

Dear All,

this series adds SDHI2 support to the iwg23s.
The RZ/G1C (the SoC powering the iwg23s) is slightly different from
the other R-Car and RZ/G1 devices, in the sense that this device uses
only one bit of the POC Control Register to control the voltage of the
entire interface, as opposed to one bit per pin.
There is a discussion on the ML that is going on about this:
https://patchwork.kernel.org/patch/10604395/
and the patches from this series implement "option 2".

Thanks,
Fab

Fabrizio Castro (4):
  dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
  pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage switch
  ARM: dts: r8a77470: Add SDHI2 support
  ARM: dts: iwg23s-sbc: Add uSD card support

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts          | 49 ++++++++++++++++++++++
 arch/arm/boot/dts/r8a77470.dtsi                    | 15 +++++++
 drivers/pinctrl/sh-pfc/pfc-r8a77470.c              | 32 +++++++++++++-
 4 files changed, 96 insertions(+), 1 deletion(-)

-- 
2.7.4

[PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Fabrizio Castro]

Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
 Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index c434200..8f3a113 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -17,6 +17,7 @@ Required properties:
 		"renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
 		"renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
 		"renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
+		"renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
 		"renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
 		"renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
 		"renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
-- 
2.7.4

Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 314 bytes --]

On Fri, Sep 21, 2018 at 12:55:08PM +0100, Fabrizio Castro wrote:
> Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
> 
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>

Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Simon Horman]

On Fri, Sep 21, 2018 at 12:55:08PM +0100, Fabrizio Castro wrote:
> Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
> 
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>

Reviewed-by: Simon Horman <horms+renesas@verge.net.au>

Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Geert Uytterhoeven]

Hi Fabrizio,

On Fri, Sep 21, 2018 at 1:55 PM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> index c434200..8f3a113 100644
> --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> @@ -17,6 +17,7 @@ Required properties:
>                 "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
>                 "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
>                 "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
> +               "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
>                 "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
>                 "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
>                 "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC

It seems RZ/G1C has two slighty different types of SD card interfaces:
  1. SDHI0 and SDHI2 use SYS-DMAC,
  2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.

Do we need to distinguish between them using the compatible value, or
are there other ways?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]


> It seems RZ/G1C has two slighty different types of SD card interfaces:
>   1. SDHI0 and SDHI2 use SYS-DMAC,
>   2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.
> 
> Do we need to distinguish between them using the compatible value, or
> are there other ways?

Yes, that seems to need an update to our current implementation which is
per-SoC only. One idea from my side would be to whitelist SYS-DMAC for
this compatible and then check if dma-properties are present, otherwise
fall back to internal DMAC?

Fabrizio, did you have any plans how to handle that?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Geert Uytterhoeven]

Hi Wolfram,

On Mon, Sep 24, 2018 at 2:26 PM Wolfram Sang <wsa@the-dreams.de> wrote:
> > It seems RZ/G1C has two slighty different types of SD card interfaces:
> >   1. SDHI0 and SDHI2 use SYS-DMAC,
> >   2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.
> >
> > Do we need to distinguish between them using the compatible value, or
> > are there other ways?
>
> Yes, that seems to need an update to our current implementation which is
> per-SoC only. One idea from my side would be to whitelist SYS-DMAC for
> this compatible and then check if dma-properties are present, otherwise
> fall back to internal DMAC?

I'm afraid that won't work, as the "dmas" properties are optional. So you
cannot distinguish between optional properties missing and internal DMA
present.

A dirty hack would be checking the device name for xxxxxxxx.sdhi, like how
whitelisting is implemented in the IPMMU driver.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Fabrizio Castro]

Hello Geert,

> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Fabrizio,
>
> On Fri, Sep 21, 2018 at 1:55 PM Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > ---
> >  Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > index c434200..8f3a113 100644
> > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > @@ -17,6 +17,7 @@ Required properties:
> >                 "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
> >                 "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
> >                 "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
> > +               "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
> >                 "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
> >                 "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
> >                 "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
>
> It seems RZ/G1C has two slighty different types of SD card interfaces:
>   1. SDHI0 and SDHI2 use SYS-DMAC,
>   2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.
>
> Do we need to distinguish between them using the compatible value, or
> are there other ways?

The most sensible thing to do here is probably to distinguish between them using
the compatible value, we were thinking about using the following for SDHI1:
compatible = "renesas,sdhi-mmc-r8a77470", "renesas,rcar-gen3-sdhi";

What do you guys think?

I have a prototype for this and it seems to be working fine, but I have only run some
basic checks at run time on the MMC, that's why I haven't sent anything just yet.

Thanks,
Fab

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Fabrizio Castro]

Hello Geert,

> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Fabrizio,
>
> On Fri, Sep 21, 2018 at 1:55 PM Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > ---
> >  Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > index c434200..8f3a113 100644
> > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > @@ -17,6 +17,7 @@ Required properties:
> >                 "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
> >                 "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
> >                 "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
> > +               "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
> >                 "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
> >                 "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
> >                 "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
>
> It seems RZ/G1C has two slighty different types of SD card interfaces:
>   1. SDHI0 and SDHI2 use SYS-DMAC,
>   2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.
>
> Do we need to distinguish between them using the compatible value, or
> are there other ways?

The most sensible thing to do here is probably to distinguish between them using
the compatible value, we were thinking about using the following for SDHI1:
compatible = "renesas,sdhi-mmc-r8a77470", "renesas,rcar-gen3-sdhi";

What do you guys think?

I have a prototype for this and it seems to be working fine, but I have only run some
basic checks at run time on the MMC, that's why I haven't sent anything just yet.

Thanks,
Fab

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Geert Uytterhoeven]

Hi Fabrizio,

On Mon, Sep 24, 2018 at 8:34 PM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> > Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
> > On Fri, Sep 21, 2018 at 1:55 PM Fabrizio Castro
> > <fabrizio.castro@bp.renesas.com> wrote:
> > > Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
> > >
> > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>

> > > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > @@ -17,6 +17,7 @@ Required properties:
> > >                 "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
> > >                 "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
> > >                 "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
> > > +               "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
> > >                 "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
> > >                 "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
> > >                 "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
> >
> > It seems RZ/G1C has two slighty different types of SD card interfaces:
> >   1. SDHI0 and SDHI2 use SYS-DMAC,
> >   2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.
> >
> > Do we need to distinguish between them using the compatible value, or
> > are there other ways?
>
> The most sensible thing to do here is probably to distinguish between them using
> the compatible value, we were thinking about using the following for SDHI1:
> compatible = "renesas,sdhi-mmc-r8a77470", "renesas,rcar-gen3-sdhi";
>
> What do you guys think?

Oh, so it's identical (or "sufficiently compatible") with the SD card
interface on R-Car Gen3?
"renesas,sdhi-mmc-r8a77470" may be a good way to distinguish.
I'm a bit reluctant to add "renesas,rcar-gen3-sdhi", though.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Simon Horman]

On Tue, Sep 25, 2018 at 08:47:38AM +0200, Geert Uytterhoeven wrote:
> Hi Fabrizio,
> 
> On Mon, Sep 24, 2018 at 8:34 PM Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > > Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
> > > On Fri, Sep 21, 2018 at 1:55 PM Fabrizio Castro
> > > <fabrizio.castro@bp.renesas.com> wrote:
> > > > Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
> > > >
> > > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> 
> > > > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > > @@ -17,6 +17,7 @@ Required properties:
> > > >                 "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
> > > >                 "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
> > > >                 "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
> > > > +               "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
> > > >                 "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
> > > >                 "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
> > > >                 "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
> > >
> > > It seems RZ/G1C has two slighty different types of SD card interfaces:
> > >   1. SDHI0 and SDHI2 use SYS-DMAC,
> > >   2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.
> > >
> > > Do we need to distinguish between them using the compatible value, or
> > > are there other ways?
> >
> > The most sensible thing to do here is probably to distinguish between them using
> > the compatible value, we were thinking about using the following for SDHI1:
> > compatible = "renesas,sdhi-mmc-r8a77470", "renesas,rcar-gen3-sdhi";
> >
> > What do you guys think?
> 
> Oh, so it's identical (or "sufficiently compatible") with the SD card
> interface on R-Car Gen3?
> "renesas,sdhi-mmc-r8a77470" may be a good way to distinguish.
> I'm a bit reluctant to add "renesas,rcar-gen3-sdhi", though.

I am also reluctant to add "renesas,rcar-gen3-sdhi", because as we are
seeing things are not so simple wrt to compatible.

Can I clarify the proposal regarding "renesas,sdhi-mmc-r8a77470",
would it be as well as or instead of "renesas,sdhi-r8a77470" ?

And what is signified by "mmc" that is not implied by (some of the)
existing compat strings?


Perhaps stating the obvious: this feels a lot like the problem we thought
we had with different Gen-3 SoCs/ES versions. And in that case we decided
against using compat strings to differentiate. The main difference here
seems to be that we need to differentiate between different ports on the
same SoC.

Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Geert Uytterhoeven]

Hi Simon,

On Tue, Sep 25, 2018 at 9:47 AM Simon Horman <horms@verge.net.au> wrote:
> On Tue, Sep 25, 2018 at 08:47:38AM +0200, Geert Uytterhoeven wrote:
> > On Mon, Sep 24, 2018 at 8:34 PM Fabrizio Castro
> > <fabrizio.castro@bp.renesas.com> wrote:
> > > > Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
> > > > On Fri, Sep 21, 2018 at 1:55 PM Fabrizio Castro
> > > > <fabrizio.castro@bp.renesas.com> wrote:
> > > > > Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
> > > > >
> > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> >
> > > > > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > > > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > > > @@ -17,6 +17,7 @@ Required properties:
> > > > >                 "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
> > > > >                 "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
> > > > >                 "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
> > > > > +               "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
> > > > >                 "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
> > > > >                 "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
> > > > >                 "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
> > > >
> > > > It seems RZ/G1C has two slighty different types of SD card interfaces:
> > > >   1. SDHI0 and SDHI2 use SYS-DMAC,
> > > >   2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.
> > > >
> > > > Do we need to distinguish between them using the compatible value, or
> > > > are there other ways?
> > >
> > > The most sensible thing to do here is probably to distinguish between them using
> > > the compatible value, we were thinking about using the following for SDHI1:
> > > compatible = "renesas,sdhi-mmc-r8a77470", "renesas,rcar-gen3-sdhi";
> > >
> > > What do you guys think?
> >
> > Oh, so it's identical (or "sufficiently compatible") with the SD card
> > interface on R-Car Gen3?
> > "renesas,sdhi-mmc-r8a77470" may be a good way to distinguish.
> > I'm a bit reluctant to add "renesas,rcar-gen3-sdhi", though.
>
> I am also reluctant to add "renesas,rcar-gen3-sdhi", because as we are
> seeing things are not so simple wrt to compatible.
>
> Can I clarify the proposal regarding "renesas,sdhi-mmc-r8a77470",
> would it be as well as or instead of "renesas,sdhi-r8a77470" ?

AFAIU, "renesas,sdhi-r8a77470" would be still used for SDHI0 and SDHI2.

> And what is signified by "mmc" that is not implied by (some of the)
> existing compat strings?

"SDHI1 can also be used as an MMC interface".

Note that this (can also be used as an MMC interface) seems to be true
for the SD card interfaces in R-Car Gen3, too.

> Perhaps stating the obvious: this feels a lot like the problem we thought
> we had with different Gen-3 SoCs/ES versions. And in that case we decided
> against using compat strings to differentiate. The main difference here
> seems to be that we need to differentiate between different ports on the
> same SoC.

So either
  a) SDHI0/2 vs. SDHI1 are different, deserving different compatible values, or
  b) SDHI0/1/2 are identical, but SDHI1 is wired different, deserving the same
     compatible value, but one or more additional properties describing the
     different wiring.

Wolfram's proposal for b) was looking at the (lack of) dmas properties, but
that's not sufficient, as they are optional anyway.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]


> > Perhaps stating the obvious: this feels a lot like the problem we thought
> > we had with different Gen-3 SoCs/ES versions. And in that case we decided
> > against using compat strings to differentiate. The main difference here
> > seems to be that we need to differentiate between different ports on the
> > same SoC.

Yes, I agree. Our so far agreed solution didn't take into account that
there are different SDHI versions on the same SoC. Adding a compatible
might be the easiest solution, but then we have a mix of compatibles,
soc_device_match, and even version register (deeper in the driver). My
gut feeling is we should take the time to rethink all this?

> So either
>   a) SDHI0/2 vs. SDHI1 are different, deserving different compatible values, or
>   b) SDHI0/1/2 are identical, but SDHI1 is wired different, deserving the same
>      compatible value, but one or more additional properties describing the
>      different wiring.

Actually, SDHI2 seems different, too. It doesn't support SDR104. I don't
have the SDHI specific docs, but from the main docs, all SDHI instances
are different.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Geert Uytterhoeven]

Hi Wolfram,

On Tue, Sep 25, 2018 at 10:22 AM Wolfram Sang <wsa@the-dreams.de> wrote:
> > > Perhaps stating the obvious: this feels a lot like the problem we thought
> > > we had with different Gen-3 SoCs/ES versions. And in that case we decided
> > > against using compat strings to differentiate. The main difference here
> > > seems to be that we need to differentiate between different ports on the
> > > same SoC.
>
> Yes, I agree. Our so far agreed solution didn't take into account that
> there are different SDHI versions on the same SoC. Adding a compatible
> might be the easiest solution, but then we have a mix of compatibles,
> soc_device_match, and even version register (deeper in the driver). My
> gut feeling is we should take the time to rethink all this?
>
> > So either
> >   a) SDHI0/2 vs. SDHI1 are different, deserving different compatible values, or
> >   b) SDHI0/1/2 are identical, but SDHI1 is wired different, deserving the same
> >      compatible value, but one or more additional properties describing the
> >      different wiring.
>
> Actually, SDHI2 seems different, too. It doesn't support SDR104. I don't
> have the SDHI specific docs, but from the main docs, all SDHI instances
> are different.

I forgot about the version register.

Fabrizio: can you please check what the 3 instances report in their version
registers? Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Fabrizio Castro]

Hi Geert,

> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Wolfram,
>
> On Tue, Sep 25, 2018 at 10:22 AM Wolfram Sang <wsa@the-dreams.de> wrote:
> > > > Perhaps stating the obvious: this feels a lot like the problem we thought
> > > > we had with different Gen-3 SoCs/ES versions. And in that case we decided
> > > > against using compat strings to differentiate. The main difference here
> > > > seems to be that we need to differentiate between different ports on the
> > > > same SoC.
> >
> > Yes, I agree. Our so far agreed solution didn't take into account that
> > there are different SDHI versions on the same SoC. Adding a compatible
> > might be the easiest solution, but then we have a mix of compatibles,
> > soc_device_match, and even version register (deeper in the driver). My
> > gut feeling is we should take the time to rethink all this?
> >
> > > So either
> > >   a) SDHI0/2 vs. SDHI1 are different, deserving different compatible values, or
> > >   b) SDHI0/1/2 are identical, but SDHI1 is wired different, deserving the same
> > >      compatible value, but one or more additional properties describing the
> > >      different wiring.
> >
> > Actually, SDHI2 seems different, too. It doesn't support SDR104. I don't
> > have the SDHI specific docs, but from the main docs, all SDHI instances
> > are different.
>
> I forgot about the version register.
>
> Fabrizio: can you please check what the 3 instances report in their version
> registers? Thanks!

SDHI0: 0xcc0d
SDHI1: 0xcc10
SDHI2: 0xcc0d

Cheers,
Fab

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Fabrizio Castro]

Hi Geert,

> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Wolfram,
>
> On Tue, Sep 25, 2018 at 10:22 AM Wolfram Sang <wsa@the-dreams.de> wrote:
> > > > Perhaps stating the obvious: this feels a lot like the problem we thought
> > > > we had with different Gen-3 SoCs/ES versions. And in that case we decided
> > > > against using compat strings to differentiate. The main difference here
> > > > seems to be that we need to differentiate between different ports on the
> > > > same SoC.
> >
> > Yes, I agree. Our so far agreed solution didn't take into account that
> > there are different SDHI versions on the same SoC. Adding a compatible
> > might be the easiest solution, but then we have a mix of compatibles,
> > soc_device_match, and even version register (deeper in the driver). My
> > gut feeling is we should take the time to rethink all this?
> >
> > > So either
> > >   a) SDHI0/2 vs. SDHI1 are different, deserving different compatible values, or
> > >   b) SDHI0/1/2 are identical, but SDHI1 is wired different, deserving the same
> > >      compatible value, but one or more additional properties describing the
> > >      different wiring.
> >
> > Actually, SDHI2 seems different, too. It doesn't support SDR104. I don't
> > have the SDHI specific docs, but from the main docs, all SDHI instances
> > are different.
>
> I forgot about the version register.
>
> Fabrizio: can you please check what the 3 instances report in their version
> registers? Thanks!

SDHI0: 0xcc0d
SDHI1: 0xcc10
SDHI2: 0xcc0d

Cheers,
Fab

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Geert Uytterhoeven]

Hi Fabrizio,

On Tue, Sep 25, 2018 at 2:45 PM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> > Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
> > On Tue, Sep 25, 2018 at 10:22 AM Wolfram Sang <wsa@the-dreams.de> wrote:
> > > > > Perhaps stating the obvious: this feels a lot like the problem we thought
> > > > > we had with different Gen-3 SoCs/ES versions. And in that case we decided
> > > > > against using compat strings to differentiate. The main difference here
> > > > > seems to be that we need to differentiate between different ports on the
> > > > > same SoC.
> > >
> > > Yes, I agree. Our so far agreed solution didn't take into account that
> > > there are different SDHI versions on the same SoC. Adding a compatible
> > > might be the easiest solution, but then we have a mix of compatibles,
> > > soc_device_match, and even version register (deeper in the driver). My
> > > gut feeling is we should take the time to rethink all this?
> > >
> > > > So either
> > > >   a) SDHI0/2 vs. SDHI1 are different, deserving different compatible values, or
> > > >   b) SDHI0/1/2 are identical, but SDHI1 is wired different, deserving the same
> > > >      compatible value, but one or more additional properties describing the
> > > >      different wiring.
> > >
> > > Actually, SDHI2 seems different, too. It doesn't support SDR104. I don't
> > > have the SDHI specific docs, but from the main docs, all SDHI instances
> > > are different.
> >
> > I forgot about the version register.
> >
> > Fabrizio: can you please check what the 3 instances report in their version
> > registers? Thanks!
>
> SDHI0: 0xcc0d
> SDHI1: 0xcc10
> SDHI2: 0xcc0d

Thank you. So SDHI1 differs from SDH0/2.
SDHI2 probably doesn't support SDR104 because its parent clock is a div6
clock, while the others have SDCKCR parents.

Plus we don't describe the relation to the SDH clock yet.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Fabrizio Castro]

Hello Geert,

> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Fabrizio,
>
> On Tue, Sep 25, 2018 at 2:45 PM Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > > Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
> > > On Tue, Sep 25, 2018 at 10:22 AM Wolfram Sang <wsa@the-dreams.de> wrote:
> > > > > > Perhaps stating the obvious: this feels a lot like the problem we thought
> > > > > > we had with different Gen-3 SoCs/ES versions. And in that case we decided
> > > > > > against using compat strings to differentiate. The main difference here
> > > > > > seems to be that we need to differentiate between different ports on the
> > > > > > same SoC.
> > > >
> > > > Yes, I agree. Our so far agreed solution didn't take into account that
> > > > there are different SDHI versions on the same SoC. Adding a compatible
> > > > might be the easiest solution, but then we have a mix of compatibles,
> > > > soc_device_match, and even version register (deeper in the driver). My
> > > > gut feeling is we should take the time to rethink all this?
> > > >
> > > > > So either
> > > > >   a) SDHI0/2 vs. SDHI1 are different, deserving different compatible values, or
> > > > >   b) SDHI0/1/2 are identical, but SDHI1 is wired different, deserving the same
> > > > >      compatible value, but one or more additional properties describing the
> > > > >      different wiring.
> > > >
> > > > Actually, SDHI2 seems different, too. It doesn't support SDR104. I don't
> > > > have the SDHI specific docs, but from the main docs, all SDHI instances
> > > > are different.
> > >
> > > I forgot about the version register.
> > >
> > > Fabrizio: can you please check what the 3 instances report in their version
> > > registers? Thanks!
> >
> > SDHI0: 0xcc0d
> > SDHI1: 0xcc10
> > SDHI2: 0xcc0d
>
> Thank you. So SDHI1 differs from SDH0/2.
> SDHI2 probably doesn't support SDR104 because its parent clock is a div6
> clock, while the others have SDCKCR parents.
>
> Plus we don't describe the relation to the SDH clock yet.

I am looking into the remaining SDHI interfaces now, how do you want me to handle SDHI1?

Thanks,
Fab

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Fabrizio Castro]

Hello Geert,

> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Fabrizio,
>
> On Tue, Sep 25, 2018 at 2:45 PM Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > > Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
> > > On Tue, Sep 25, 2018 at 10:22 AM Wolfram Sang <wsa@the-dreams.de> wrote:
> > > > > > Perhaps stating the obvious: this feels a lot like the problem we thought
> > > > > > we had with different Gen-3 SoCs/ES versions. And in that case we decided
> > > > > > against using compat strings to differentiate. The main difference here
> > > > > > seems to be that we need to differentiate between different ports on the
> > > > > > same SoC.
> > > >
> > > > Yes, I agree. Our so far agreed solution didn't take into account that
> > > > there are different SDHI versions on the same SoC. Adding a compatible
> > > > might be the easiest solution, but then we have a mix of compatibles,
> > > > soc_device_match, and even version register (deeper in the driver). My
> > > > gut feeling is we should take the time to rethink all this?
> > > >
> > > > > So either
> > > > >   a) SDHI0/2 vs. SDHI1 are different, deserving different compatible values, or
> > > > >   b) SDHI0/1/2 are identical, but SDHI1 is wired different, deserving the same
> > > > >      compatible value, but one or more additional properties describing the
> > > > >      different wiring.
> > > >
> > > > Actually, SDHI2 seems different, too. It doesn't support SDR104. I don't
> > > > have the SDHI specific docs, but from the main docs, all SDHI instances
> > > > are different.
> > >
> > > I forgot about the version register.
> > >
> > > Fabrizio: can you please check what the 3 instances report in their version
> > > registers? Thanks!
> >
> > SDHI0: 0xcc0d
> > SDHI1: 0xcc10
> > SDHI2: 0xcc0d
>
> Thank you. So SDHI1 differs from SDH0/2.
> SDHI2 probably doesn't support SDR104 because its parent clock is a div6
> clock, while the others have SDCKCR parents.
>
> Plus we don't describe the relation to the SDH clock yet.

I am looking into the remaining SDHI interfaces now, how do you want me to handle SDHI1?

Thanks,
Fab

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Fabrizio Castro]

Hello Geert,

> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Fabrizio,
>
> On Mon, Sep 24, 2018 at 8:34 PM Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > > Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
> > > On Fri, Sep 21, 2018 at 1:55 PM Fabrizio Castro
> > > <fabrizio.castro@bp.renesas.com> wrote:
> > > > Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
> > > >
> > > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
>
> > > > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > > @@ -17,6 +17,7 @@ Required properties:
> > > >                 "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
> > > >                 "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
> > > >                 "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
> > > > +               "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
> > > >                 "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
> > > >                 "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
> > > >                 "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
> > >
> > > It seems RZ/G1C has two slighty different types of SD card interfaces:
> > >   1. SDHI0 and SDHI2 use SYS-DMAC,
> > >   2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.
> > >
> > > Do we need to distinguish between them using the compatible value, or
> > > are there other ways?
> >
> > The most sensible thing to do here is probably to distinguish between them using
> > the compatible value, we were thinking about using the following for SDHI1:
> > compatible = "renesas,sdhi-mmc-r8a77470", "renesas,rcar-gen3-sdhi";
> >
> > What do you guys think?
>
> Oh, so it's identical (or "sufficiently compatible") with the SD card
> interface on R-Car Gen3?

It seems identical to R-Car Gen3. I have done proper testing now and everything
seems to be working as expected.

> "renesas,sdhi-mmc-r8a77470" may be a good way to distinguish.
> I'm a bit reluctant to add "renesas,rcar-gen3-sdhi", though.

We could just use "renesas,sdhi-mmc-r8a77470" for SDHI1 and "renesas,sdhi- r8a77470"
for SDHI0 and SDHI2 then, without generic compatible strings, or maybe we could
use "renesas,rcar-gen2-sdhi" for both even though that would be incorrect as per the
current implementation of the drivers.

Today I have given some thought on how to distinguish the two types of IP from the
two different drivers without having driver specific compatible strings, and unfortunately
we would still need to take into account some information coming from the device tree
(like the memory address of the interface) in order to decide if we need to fail the probing.
I can't use the VERSION register to make any decision as to read the registers in a meaningful
way we still need to know bus_shift, and then the DMA properties are optional, therefore
using different compatible strings for the two types of IP still feels like the best option to me.

I am dropping all of the patches from this series and I am going to send another version
to address the comments on the implementation of r8a77470_pin_to_pocctrl, but also
to address both SD card and eMMC, so that we can reason about what's the best thing to do
by looking at the implementation of a working example.

Cheers,
Fab

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

RE: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Fabrizio Castro]

Hello Geert,

> Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
>
> Hi Fabrizio,
>
> On Mon, Sep 24, 2018 at 8:34 PM Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > > Subject: Re: [PATCH 1/4] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
> > > On Fri, Sep 21, 2018 at 1:55 PM Fabrizio Castro
> > > <fabrizio.castro@bp.renesas.com> wrote:
> > > > Document SDHI support for the RZ/G1C (a.k.a. R8A77470) SoC.
> > > >
> > > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
>
> > > > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > > > @@ -17,6 +17,7 @@ Required properties:
> > > >                 "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
> > > >                 "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
> > > >                 "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
> > > > +               "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC
> > > >                 "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
> > > >                 "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
> > > >                 "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
> > >
> > > It seems RZ/G1C has two slighty different types of SD card interfaces:
> > >   1. SDHI0 and SDHI2 use SYS-DMAC,
> > >   2. SDHI1 can also be used as an MMC interface, and has an internal DMAC.
> > >
> > > Do we need to distinguish between them using the compatible value, or
> > > are there other ways?
> >
> > The most sensible thing to do here is probably to distinguish between them using
> > the compatible value, we were thinking about using the following for SDHI1:
> > compatible = "renesas,sdhi-mmc-r8a77470", "renesas,rcar-gen3-sdhi";
> >
> > What do you guys think?
>
> Oh, so it's identical (or "sufficiently compatible") with the SD card
> interface on R-Car Gen3?

It seems identical to R-Car Gen3. I have done proper testing now and everything
seems to be working as expected.

> "renesas,sdhi-mmc-r8a77470" may be a good way to distinguish.
> I'm a bit reluctant to add "renesas,rcar-gen3-sdhi", though.

We could just use "renesas,sdhi-mmc-r8a77470" for SDHI1 and "renesas,sdhi- r8a77470"
for SDHI0 and SDHI2 then, without generic compatible strings, or maybe we could
use "renesas,rcar-gen2-sdhi" for both even though that would be incorrect as per the
current implementation of the drivers.

Today I have given some thought on how to distinguish the two types of IP from the
two different drivers without having driver specific compatible strings, and unfortunately
we would still need to take into account some information coming from the device tree
(like the memory address of the interface) in order to decide if we need to fail the probing.
I can't use the VERSION register to make any decision as to read the registers in a meaningful
way we still need to know bus_shift, and then the DMA properties are optional, therefore
using different compatible strings for the two types of IP still feels like the best option to me.

I am dropping all of the patches from this series and I am going to send another version
to address the comments on the implementation of r8a77470_pin_to_pocctrl, but also
to address both SD card and eMMC, so that we can reason about what's the best thing to do
by looking at the implementation of a working example.

Cheers,
Fab

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

[PATCH 2/4] pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage switch

[Fabrizio Castro]

Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI2 pins
capable of switching voltage. Please note that with the
RZ/G1C only 1 bit of the POC Control Register is used to
control each interface.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index 9d3ed43..a1248e2 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -17,7 +17,19 @@
 	PORT_GP_1(3, 27, fn, sfx),					\
 	PORT_GP_1(3, 28, fn, sfx),					\
 	PORT_GP_1(3, 29, fn, sfx),					\
-	PORT_GP_26(4, fn, sfx),						\
+	PORT_GP_14(4, fn, sfx),						\
+	PORT_GP_CFG_1(4, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE),	\
+	PORT_GP_CFG_1(4, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE),	\
+	PORT_GP_CFG_1(4, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE),	\
+	PORT_GP_CFG_1(4, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE),	\
+	PORT_GP_CFG_1(4, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE),	\
+	PORT_GP_CFG_1(4, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE),	\
+	PORT_GP_1(4, 20, fn, sfx),					\
+	PORT_GP_1(4, 21, fn, sfx),					\
+	PORT_GP_1(4, 22, fn, sfx),					\
+	PORT_GP_1(4, 23, fn, sfx),					\
+	PORT_GP_1(4, 24, fn, sfx),					\
+	PORT_GP_1(4, 25, fn, sfx),					\
 	PORT_GP_32(5, fn, sfx)
 
 enum {
@@ -2321,9 +2333,27 @@ static const struct pinmux_cfg_reg pinmux_config_regs[] = {
 	{ },
 };
 
+static int r8a77470_pin_to_pocctrl(struct sh_pfc *pfc, unsigned int pin,
+				   u32 *pocctrl)
+{
+	unsigned int _bank = pin >> 5;
+	unsigned int _pin = pin & 0x1f;
+	*pocctrl = 0xe60600b0;
+
+	if (_bank == 4 && _pin >= 14 && _pin <= 19)
+		return 1;
+
+	return -EINVAL;
+}
+
+static const struct sh_pfc_soc_operations r8a77470_pinmux_ops = {
+	.pin_to_pocctrl = r8a77470_pin_to_pocctrl,
+};
+
 #ifdef CONFIG_PINCTRL_PFC_R8A77470
 const struct sh_pfc_soc_info r8a77470_pinmux_info = {
 	.name = "r8a77470_pfc",
+	.ops = &r8a77470_pinmux_ops,
 	.unlock_reg = 0xe6060000, /* PMMR */
 
 	.function = { PINMUX_FUNCTION_BEGIN, PINMUX_FUNCTION_END },
-- 
2.7.4

Re: [PATCH 2/4] pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage switch

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

On Fri, Sep 21, 2018 at 12:55:09PM +0100, Fabrizio Castro wrote:
> Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI2 pins
> capable of switching voltage. Please note that with the
> RZ/G1C only 1 bit of the POC Control Register is used to
> control each interface.
> 
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>

In general:

Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

> +	if (_bank == 4 && _pin >= 14 && _pin <= 19)
> +		return 1;
> +
> +	return -EINVAL;

I'd like a tad better to bail out on the error case and have the main
path returning on the good case, but no strong opinion...


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/4] pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage switch

[Geert Uytterhoeven]

On Sat, Sep 22, 2018 at 8:44 PM Wolfram Sang <wsa@the-dreams.de> wrote:
> On Fri, Sep 21, 2018 at 12:55:09PM +0100, Fabrizio Castro wrote:
> > Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI2 pins
> > capable of switching voltage. Please note that with the
> > RZ/G1C only 1 bit of the POC Control Register is used to
> > control each interface.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
>
> In general:
>
> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> > +     if (_bank == 4 && _pin >= 14 && _pin <= 19)
> > +             return 1;
> > +
> > +     return -EINVAL;
>
> I'd like a tad better to bail out on the error case and have the main
> path returning on the good case, but no strong opinion...

And we have these nice RCAR_GP_PIN() macros to check pin ranges.
Please have a look at the flow in e.g. r8a7795_pin_to_pocctrl().

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 2/4] pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage switch

[Fabrizio Castro]

Hello Geert, hello Wolfram,

Thank you both for your feedback.

> Subject: Re: [PATCH 2/4] pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage switch
>
> On Sat, Sep 22, 2018 at 8:44 PM Wolfram Sang <wsa@the-dreams.de> wrote:
> > On Fri, Sep 21, 2018 at 12:55:09PM +0100, Fabrizio Castro wrote:
> > > Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI2 pins
> > > capable of switching voltage. Please note that with the
> > > RZ/G1C only 1 bit of the POC Control Register is used to
> > > control each interface.
> > >
> > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> >
> > In general:
> >
> > Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> >
> > > +     if (_bank == 4 && _pin >= 14 && _pin <= 19)
> > > +             return 1;
> > > +
> > > +     return -EINVAL;
> >
> > I'd like a tad better to bail out on the error case and have the main
> > path returning on the good case, but no strong opinion...
>
> And we have these nice RCAR_GP_PIN() macros to check pin ranges.
> Please have a look at the flow in e.g. r8a7795_pin_to_pocctrl().

I'll send a v2 to address this, thank you for pointing me to the right direction.

Cheers,
Fab

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

RE: [PATCH 2/4] pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage switch

[Fabrizio Castro]

Hello Geert, hello Wolfram,

Thank you both for your feedback.

> Subject: Re: [PATCH 2/4] pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage switch
>
> On Sat, Sep 22, 2018 at 8:44 PM Wolfram Sang <wsa@the-dreams.de> wrote:
> > On Fri, Sep 21, 2018 at 12:55:09PM +0100, Fabrizio Castro wrote:
> > > Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI2 pins
> > > capable of switching voltage. Please note that with the
> > > RZ/G1C only 1 bit of the POC Control Register is used to
> > > control each interface.
> > >
> > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> >
> > In general:
> >
> > Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> >
> > > +     if (_bank == 4 && _pin >= 14 && _pin <= 19)
> > > +             return 1;
> > > +
> > > +     return -EINVAL;
> >
> > I'd like a tad better to bail out on the error case and have the main
> > path returning on the good case, but no strong opinion...
>
> And we have these nice RCAR_GP_PIN() macros to check pin ranges.
> Please have a look at the flow in e.g. r8a7795_pin_to_pocctrl().

I'll send a v2 to address this, thank you for pointing me to the right direction.

Cheers,
Fab

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

[PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support

[Fabrizio Castro]

Add SoC specific device tree definitions for the SDHI2 interface.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
 arch/arm/boot/dts/r8a77470.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 9aba350..9e7f86d 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -412,6 +412,21 @@
 			status = "disabled";
 		};
 
+		sdhi2: sd@ee160000 {
+			compatible = "renesas,sdhi-r8a77470",
+				     "renesas,rcar-gen2-sdhi";
+			reg = <0 0xee160000 0 0x328>;
+			interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 312>;
+			dmas = <&dmac0 0xd3>, <&dmac0 0xd4>,
+			       <&dmac1 0xd3>, <&dmac1 0xd4>;
+			dma-names = "tx", "rx", "tx", "rx";
+			max-frequency = <97500000>;
+			power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
+			resets = <&cpg 312>;
+			status = "disabled";
+		};
+
 		gic: interrupt-controller@f1001000 {
 			compatible = "arm,gic-400";
 			#interrupt-cells = <3>;
-- 
2.7.4

Re: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

On Fri, Sep 21, 2018 at 12:55:10PM +0100, Fabrizio Castro wrote:
> Add SoC specific device tree definitions for the SDHI2 interface.
> 
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>

Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support

[Simon Horman]

On Sat, Sep 22, 2018 at 08:44:50PM +0200, Wolfram Sang wrote:
> On Fri, Sep 21, 2018 at 12:55:10PM +0100, Fabrizio Castro wrote:
> > Add SoC specific device tree definitions for the SDHI2 interface.
> > 
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> 
> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

Thanks, applied for v4.20.

RE: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support

[Fabrizio Castro]

Hello Simon,

Do you think you can drop this patch or is it too late?

Cheers,
Fab

> Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support
>
> On Sat, Sep 22, 2018 at 08:44:50PM +0200, Wolfram Sang wrote:
> > On Fri, Sep 21, 2018 at 12:55:10PM +0100, Fabrizio Castro wrote:
> > > Add SoC specific device tree definitions for the SDHI2 interface.
> > >
> > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> >
> > Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> Thanks, applied for v4.20.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

Re: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support

[Simon Horman]

On Fri, Sep 28, 2018 at 09:31:16AM +0000, Fabrizio Castro wrote:
> Hello Simon,
> 
> Do you think you can drop this patch or is it too late?

Unfortunately it was too late.

RE: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support

[Fabrizio Castro]

Hello Simon,

> Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support
>
> On Fri, Sep 28, 2018 at 09:31:16AM +0000, Fabrizio Castro wrote:
> > Hello Simon,
> >
> > Do you think you can drop this patch or is it too late?
>
> Unfortunately it was too late.

No worries, thank you anyway.

Cheers,
Fab



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

Re: [PATCH 3/4] ARM: dts: r8a77470: Add SDHI2 support

[Simon Horman]

On Sat, Sep 22, 2018 at 08:44:50PM +0200, Wolfram Sang wrote:
> On Fri, Sep 21, 2018 at 12:55:10PM +0100, Fabrizio Castro wrote:
> > Add SoC specific device tree definitions for the SDHI2 interface.
> > 
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> 
> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

Thanks, applied for v4.20.

[PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support

[Fabrizio Castro]

Add uSD card support to the iwg23s single board computer powered
by the RZ/G1C SoC (a.k.a. r8a77470).

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
Hello Simon,

this patch can only be taken after patch "pinctrl: sh-pfc: r8a77470:
Add SDHI2 voltage switch" from this series appears on a release candidate
or a release.
Shall I re-send it at a later stage or are you happy to keep it around
and defer its application to when its dependency is sorted?

Thanks,
Fab

 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 49 +++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index 22da819..cd9c3fc 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -6,6 +6,7 @@
  */
 
 /dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
 #include "r8a77470.dtsi"
 / {
 	model = "iWave iW-RainboW-G23S single board computer based on RZ/G1C";
@@ -25,6 +26,29 @@
 		device_type = "memory";
 		reg = <0 0x40000000 0 0x20000000>;
 	};
+
+	vcc_sdhi2: regulator-vcc-sdhi2 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "SDHI2 Vcc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		enable-active-high;
+	};
+
+	vccq_sdhi2: regulator-vccq-sdhi2 {
+		compatible = "regulator-gpio";
+
+		regulator-name = "SDHI2 VccQ";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpios = <&gpio2 24 GPIO_ACTIVE_LOW>;
+		gpios-states = <1>;
+		states = <3300000 1
+			  1800000 0>;
+	};
 };
 
 &avb {
@@ -50,6 +74,18 @@
 		groups = "scif1_data_b";
 		function = "scif1";
 	};
+
+	sdhi2_pins: sd2 {
+		groups = "sdhi2_data4", "sdhi2_ctrl";
+		function = "sdhi2";
+		power-source = <3300>;
+	};
+
+	sdhi2_pins_uhs: sd2_uhs {
+		groups = "sdhi2_data4", "sdhi2_ctrl";
+		function = "sdhi2";
+		power-source = <1800>;
+	};
 };
 
 &scif1 {
@@ -58,3 +94,16 @@
 
 	status = "okay";
 };
+
+&sdhi2 {
+	pinctrl-0 = <&sdhi2_pins>;
+	pinctrl-1 = <&sdhi2_pins_uhs>;
+	pinctrl-names = "default", "state_uhs";
+
+	vmmc-supply = <&vcc_sdhi2>;
+	vqmmc-supply = <&vccq_sdhi2>;
+	bus-width = <4>;
+	cd-gpios = <&gpio4 20 GPIO_ACTIVE_LOW>;
+	sd-uhs-sdr50;
+	status = "okay";
+};
-- 
2.7.4

Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

On Fri, Sep 21, 2018 at 12:55:11PM +0100, Fabrizio Castro wrote:
> Add uSD card support to the iwg23s single board computer powered
> by the RZ/G1C SoC (a.k.a. r8a77470).
> 
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>

Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support

[Simon Horman]

On Fri, Sep 21, 2018 at 12:55:11PM +0100, Fabrizio Castro wrote:
> Add uSD card support to the iwg23s single board computer powered
> by the RZ/G1C SoC (a.k.a. r8a77470).
> 
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> Hello Simon,
> 
> this patch can only be taken after patch "pinctrl: sh-pfc: r8a77470:
> Add SDHI2 voltage switch" from this series appears on a release candidate
> or a release.

What is the nature of that dependency. Does adding this patch without
its dependency cause a regression?

> Shall I re-send it at a later stage or are you happy to keep it around
> and defer its application to when its dependency is sorted?

I'd rather that you repost or otherwise ping me once any dependency is sorted.

RE: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support

[Fabrizio Castro]

Hello Simon,

Thank you for your feedback.

> -----Original Message-----
> From: Simon Horman <horms@verge.net.au>
> Sent: 24 September 2018 10:14
> To: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>; Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Linus Walleij
> <linus.walleij@linaro.org>; Wolfram Sang <wsa+renesas@sang-engineering.com>; Magnus Damm <magnus.damm@gmail.com>;
> linux-mmc@vger.kernel.org; devicetree@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-gpio@vger.kernel.org; Chris
> Paterson <Chris.Paterson2@renesas.com>; Biju Das <biju.das@bp.renesas.com>
> Subject: Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support
>
> On Fri, Sep 21, 2018 at 12:55:11PM +0100, Fabrizio Castro wrote:
> > Add uSD card support to the iwg23s single board computer powered
> > by the RZ/G1C SoC (a.k.a. r8a77470).
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > ---
> > Hello Simon,
> >
> > this patch can only be taken after patch "pinctrl: sh-pfc: r8a77470:
> > Add SDHI2 voltage switch" from this series appears on a release candidate
> > or a release.
>
> What is the nature of that dependency. Does adding this patch without
> its dependency cause a regression?

Since the SDHI2 pins definition contain "power-source" property, adding this
patch without its dependency will cause an error at boot up as the kernel
would be looking for flag SH_PFC_PIN_CFG_IO_VOLTAGE for each pin contained
in sdhi2_pins and sdhi2_pins_uhs, and since that particular flag would be missing
(as such a definition comes from patch "pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage
switch") the SD card would not be functional, but this won't have any impact on
the rest of the system.

>
> > Shall I re-send it at a later stage or are you happy to keep it around
> > and defer its application to when its dependency is sorted?
>
> I'd rather that you repost or otherwise ping me once any dependency is sorted.

Ok, I will do that.

Thanks,
Fab



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support

[Geert Uytterhoeven]

Hi Fabrizio,

On Mon, Sep 24, 2018 at 11:30 AM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> > -----Original Message-----
> > From: Simon Horman <horms@verge.net.au>
> > Sent: 24 September 2018 10:14
> > To: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>; Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Laurent
> > Pinchart <laurent.pinchart@ideasonboard.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Linus Walleij
> > <linus.walleij@linaro.org>; Wolfram Sang <wsa+renesas@sang-engineering.com>; Magnus Damm <magnus.damm@gmail.com>;
> > linux-mmc@vger.kernel.org; devicetree@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-gpio@vger.kernel.org; Chris
> > Paterson <Chris.Paterson2@renesas.com>; Biju Das <biju.das@bp.renesas.com>
> > Subject: Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support
> >
> > On Fri, Sep 21, 2018 at 12:55:11PM +0100, Fabrizio Castro wrote:
> > > Add uSD card support to the iwg23s single board computer powered
> > > by the RZ/G1C SoC (a.k.a. r8a77470).
> > >
> > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > > ---
> > > Hello Simon,
> > >
> > > this patch can only be taken after patch "pinctrl: sh-pfc: r8a77470:
> > > Add SDHI2 voltage switch" from this series appears on a release candidate
> > > or a release.
> >
> > What is the nature of that dependency. Does adding this patch without
> > its dependency cause a regression?
>
> Since the SDHI2 pins definition contain "power-source" property, adding this
> patch without its dependency will cause an error at boot up as the kernel
> would be looking for flag SH_PFC_PIN_CFG_IO_VOLTAGE for each pin contained
> in sdhi2_pins and sdhi2_pins_uhs, and since that particular flag would be missing
> (as such a definition comes from patch "pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage
> switch") the SD card would not be functional, but this won't have any impact on
> the rest of the system.

But that won't be a regression, as currently there's no support for
SDHI2 anyway,
right? All pieces will start working when both the pinctrl and DTS support will
be merged together.

This is different from the case where you first add a device node to enable a
device (which makes it work), and later add pinctrl properties (which may
break it, if the pinctrl driver doesn't have support for it yet).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support

[Fabrizio Castro]

Hello Geert,

Thank you for your feedback.

> Subject: Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support
>
> Hi Fabrizio,
>
> On Mon, Sep 24, 2018 at 11:30 AM Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > > -----Original Message-----
> > > From: Simon Horman <horms@verge.net.au>
> > > Sent: 24 September 2018 10:14
> > > To: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > Cc: Ulf Hansson <ulf.hansson@linaro.org>; Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Laurent
> > > Pinchart <laurent.pinchart@ideasonboard.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Linus Walleij
> > > <linus.walleij@linaro.org>; Wolfram Sang <wsa+renesas@sang-engineering.com>; Magnus Damm <magnus.damm@gmail.com>;
> > > linux-mmc@vger.kernel.org; devicetree@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-gpio@vger.kernel.org; Chris
> > > Paterson <Chris.Paterson2@renesas.com>; Biju Das <biju.das@bp.renesas.com>
> > > Subject: Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support
> > >
> > > On Fri, Sep 21, 2018 at 12:55:11PM +0100, Fabrizio Castro wrote:
> > > > Add uSD card support to the iwg23s single board computer powered
> > > > by the RZ/G1C SoC (a.k.a. r8a77470).
> > > >
> > > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > > > ---
> > > > Hello Simon,
> > > >
> > > > this patch can only be taken after patch "pinctrl: sh-pfc: r8a77470:
> > > > Add SDHI2 voltage switch" from this series appears on a release candidate
> > > > or a release.
> > >
> > > What is the nature of that dependency. Does adding this patch without
> > > its dependency cause a regression?
> >
> > Since the SDHI2 pins definition contain "power-source" property, adding this
> > patch without its dependency will cause an error at boot up as the kernel
> > would be looking for flag SH_PFC_PIN_CFG_IO_VOLTAGE for each pin contained
> > in sdhi2_pins and sdhi2_pins_uhs, and since that particular flag would be missing
> > (as such a definition comes from patch "pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage
> > switch") the SD card would not be functional, but this won't have any impact on
> > the rest of the system.
>
> But that won't be a regression, as currently there's no support for
> SDHI2 anyway,
> right? All pieces will start working when both the pinctrl and DTS support will
> be merged together.

Exactly, it won't be a regression, you'd just get weird messages from the kernel, that's all.

Thanks,
Fab

>
> This is different from the case where you first add a device node to enable a
> device (which makes it work), and later add pinctrl properties (which may
> break it, if the pinctrl driver doesn't have support for it yet).
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

RE: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support

[Fabrizio Castro]

Hello Geert,

Thank you for your feedback.

> Subject: Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support
>
> Hi Fabrizio,
>
> On Mon, Sep 24, 2018 at 11:30 AM Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > > -----Original Message-----
> > > From: Simon Horman <horms@verge.net.au>
> > > Sent: 24 September 2018 10:14
> > > To: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > Cc: Ulf Hansson <ulf.hansson@linaro.org>; Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Laurent
> > > Pinchart <laurent.pinchart@ideasonboard.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Linus Walleij
> > > <linus.walleij@linaro.org>; Wolfram Sang <wsa+renesas@sang-engineering.com>; Magnus Damm <magnus.damm@gmail.com>;
> > > linux-mmc@vger.kernel.org; devicetree@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-gpio@vger.kernel.org; Chris
> > > Paterson <Chris.Paterson2@renesas.com>; Biju Das <biju.das@bp.renesas.com>
> > > Subject: Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support
> > >
> > > On Fri, Sep 21, 2018 at 12:55:11PM +0100, Fabrizio Castro wrote:
> > > > Add uSD card support to the iwg23s single board computer powered
> > > > by the RZ/G1C SoC (a.k.a. r8a77470).
> > > >
> > > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > > > ---
> > > > Hello Simon,
> > > >
> > > > this patch can only be taken after patch "pinctrl: sh-pfc: r8a77470:
> > > > Add SDHI2 voltage switch" from this series appears on a release candidate
> > > > or a release.
> > >
> > > What is the nature of that dependency. Does adding this patch without
> > > its dependency cause a regression?
> >
> > Since the SDHI2 pins definition contain "power-source" property, adding this
> > patch without its dependency will cause an error at boot up as the kernel
> > would be looking for flag SH_PFC_PIN_CFG_IO_VOLTAGE for each pin contained
> > in sdhi2_pins and sdhi2_pins_uhs, and since that particular flag would be missing
> > (as such a definition comes from patch "pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage
> > switch") the SD card would not be functional, but this won't have any impact on
> > the rest of the system.
>
> But that won't be a regression, as currently there's no support for
> SDHI2 anyway,
> right? All pieces will start working when both the pinctrl and DTS support will
> be merged together.

Exactly, it won't be a regression, you'd just get weird messages from the kernel, that's all.

Thanks,
Fab

>
> This is different from the case where you first add a device node to enable a
> device (which makes it work), and later add pinctrl properties (which may
> break it, if the pinctrl driver doesn't have support for it yet).
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support

[Simon Horman]

On Mon, Sep 24, 2018 at 03:09:49PM +0000, Fabrizio Castro wrote:
> Hello Geert,
> 
> Thank you for your feedback.
> 
> > Subject: Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support
> >
> > Hi Fabrizio,
> >
> > On Mon, Sep 24, 2018 at 11:30 AM Fabrizio Castro
> > <fabrizio.castro@bp.renesas.com> wrote:
> > > > -----Original Message-----
> > > > From: Simon Horman <horms@verge.net.au>
> > > > Sent: 24 September 2018 10:14
> > > > To: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > Cc: Ulf Hansson <ulf.hansson@linaro.org>; Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Laurent
> > > > Pinchart <laurent.pinchart@ideasonboard.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Linus Walleij
> > > > <linus.walleij@linaro.org>; Wolfram Sang <wsa+renesas@sang-engineering.com>; Magnus Damm <magnus.damm@gmail.com>;
> > > > linux-mmc@vger.kernel.org; devicetree@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-gpio@vger.kernel.org; Chris
> > > > Paterson <Chris.Paterson2@renesas.com>; Biju Das <biju.das@bp.renesas.com>
> > > > Subject: Re: [PATCH 4/4] ARM: dts: iwg23s-sbc: Add uSD card support
> > > >
> > > > On Fri, Sep 21, 2018 at 12:55:11PM +0100, Fabrizio Castro wrote:
> > > > > Add uSD card support to the iwg23s single board computer powered
> > > > > by the RZ/G1C SoC (a.k.a. r8a77470).
> > > > >
> > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > > > > ---
> > > > > Hello Simon,
> > > > >
> > > > > this patch can only be taken after patch "pinctrl: sh-pfc: r8a77470:
> > > > > Add SDHI2 voltage switch" from this series appears on a release candidate
> > > > > or a release.
> > > >
> > > > What is the nature of that dependency. Does adding this patch without
> > > > its dependency cause a regression?
> > >
> > > Since the SDHI2 pins definition contain "power-source" property, adding this
> > > patch without its dependency will cause an error at boot up as the kernel
> > > would be looking for flag SH_PFC_PIN_CFG_IO_VOLTAGE for each pin contained
> > > in sdhi2_pins and sdhi2_pins_uhs, and since that particular flag would be missing
> > > (as such a definition comes from patch "pinctrl: sh-pfc: r8a77470: Add SDHI2 voltage
> > > switch") the SD card would not be functional, but this won't have any impact on
> > > the rest of the system.
> >
> > But that won't be a regression, as currently there's no support for
> > SDHI2 anyway,
> > right? All pieces will start working when both the pinctrl and DTS support will
> > be merged together.
> 
> Exactly, it won't be a regression, you'd just get weird messages from the kernel, that's all.

That is fine. But lets finalise the discussion of the bindings before
I apply this patch.