[PATCH v3 0/3] mmc: sh_mobile_sdhi: Add r7s72100 support

[PATCH v3 0/3] mmc: sh_mobile_sdhi: Add r7s72100 support

[Chris Brandt]

For the most part, the SDHI controller in the RZ/A1 (r7s72100)
is the same as other Renesas SoC...except for the fact that the 
data port register was widened to 32-bits and the 16-bit accesses
in the current tmio driver aren't going to cut it.

Also, the tmio driver allows you to pass in what voltages you
support via the ocr_mask. For the RZ/A1, it's just simple 3.3v.
So, I added the ability to pass that when using DT.

Chris Brandt (3):
  mmc: sh_mobile_sdhi: add ocr_mask option
  mmc: tmio-mmc: add support for 32bit data port
  mmc: sh_mobile_sdhi: Add r7s72100 support

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
 drivers/mmc/host/sh_mobile_sdhi.c                  |  9 +++++++
 drivers/mmc/host/tmio_mmc.h                        | 12 +++++++++
 drivers/mmc/host/tmio_mmc_pio.c                    | 30 ++++++++++++++++++++++
 include/linux/mfd/tmio.h                           |  5 ++++
 5 files changed, 57 insertions(+)

-- 
2.9.2

[PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

[Chris Brandt]

In moving platforms from board files to DT, there still needs to be a way
to set the ocr_mask setting for the tmio driver during probe. Without this
setting, the probe will fail because the supported voltages are not known.

This patch will also traditional platform registration platforms to
migrate to DT.

Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
 drivers/mmc/host/sh_mobile_sdhi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 5334f24..b033500 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -59,6 +59,7 @@ enum tmio_mmc_dmac_type {
 
 struct sh_mobile_sdhi_of_data {
 	unsigned long tmio_flags;
+	u32	      tmio_ocr_mask;
 	unsigned long capabilities;
 	unsigned long capabilities2;
 	enum dma_slave_buswidth dma_buswidth;
@@ -630,6 +631,7 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
 		const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
 
 		mmc_data->flags |= of_data->tmio_flags;
+		mmc_data->ocr_mask = of_data->tmio_ocr_mask;
 		mmc_data->capabilities |= of_data->capabilities;
 		mmc_data->capabilities2 |= of_data->capabilities2;
 		mmc_data->dma_rx_offset = of_data->dma_rx_offset;
-- 
2.9.2

Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

[Ulf Hansson]

On 12 September 2016 at 16:15, Chris Brandt <chris.brandt@renesas.com> wrote:
> In moving platforms from board files to DT, there still needs to be a way
> to set the ocr_mask setting for the tmio driver during probe. Without this
> setting, the probe will fail because the supported voltages are not known.

Regarding the ocr_mask; How do these SoCs provides the power to the mmc/sd card?

Do note, I am *not* talking about the I/O voltage but the core power
to the card.

The reason for raising the question is that we have infrastructures in
the mmc core which can create the ocr_mask, by parsing a regulator's
voltage range. This is the recommended method to use, instead of using
hard coded ocr mask values.

Kind regards
Uffe

>
> This patch will also traditional platform registration platforms to
> migrate to DT.
>
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
> ---
>  drivers/mmc/host/sh_mobile_sdhi.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
> index 5334f24..b033500 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -59,6 +59,7 @@ enum tmio_mmc_dmac_type {
>
>  struct sh_mobile_sdhi_of_data {
>         unsigned long tmio_flags;
> +       u32           tmio_ocr_mask;
>         unsigned long capabilities;
>         unsigned long capabilities2;
>         enum dma_slave_buswidth dma_buswidth;
> @@ -630,6 +631,7 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
>                 const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
>
>                 mmc_data->flags |= of_data->tmio_flags;
> +               mmc_data->ocr_mask = of_data->tmio_ocr_mask;
>                 mmc_data->capabilities |= of_data->capabilities;
>                 mmc_data->capabilities2 |= of_data->capabilities2;
>                 mmc_data->dma_rx_offset = of_data->dma_rx_offset;
> --
> 2.9.2
>
>

Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

[Geert Uytterhoeven]

Hi Ulf,

On Tue, Sep 13, 2016 at 2:57 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 12 September 2016 at 16:15, Chris Brandt <chris.brandt@renesas.com> wrote:
>> In moving platforms from board files to DT, there still needs to be a way
>> to set the ocr_mask setting for the tmio driver during probe. Without this
>> setting, the probe will fail because the supported voltages are not known.
>
> Regarding the ocr_mask; How do these SoCs provides the power to the mmc/sd card?
>
> Do note, I am *not* talking about the I/O voltage but the core power
> to the card.
>
> The reason for raising the question is that we have infrastructures in
> the mmc core which can create the ocr_mask, by parsing a regulator's
> voltage range. This is the recommended method to use, instead of using
> hard coded ocr mask values.

On RSKRZA1, 3.3V is provided to the SD/MMC socket through an MIC2026
MOSFET switch.
On Genmai, 3.3V or 5V is provided through an LTC1471 switch.

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 v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

[Chris Brandt]

Here's a question:

The DT regulator method is good if you want to be able to control the regulator at run-time by the system.

But for MMC and SDHI, why isn't there a way to just set the OCR voltage in the board's DT if it's fixed (other than making a fixed regulator node)?
Why isn't there a mmc-ocr-mask property? That's really what I want and it seems like it would make a lot of dts files more simple.


Chris

Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

[Ulf Hansson]

On 13 September 2016 at 15:50, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> Here's a question:
>
> The DT regulator method is good if you want to be able to control the regulator at run-time by the system.
>
> But for MMC and SDHI, why isn't there a way to just set the OCR voltage in the board's DT if it's fixed (other than making a fixed regulator node)?
> Why isn't there a mmc-ocr-mask property? That's really what I want and it seems like it would make a lot of dts files more simple.

Because, if you have an external regulator feeding the mmc with power
you should set it up and use it.

Now, we do have cases where it's actually the MMC controller that
manges the power to the card. So no external regulators being used.
For these case we have the "voltage-ranges" DT binding, but I don't
think you should be using that for these cases. :-)

Kind regards
Uffe

RE: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

[Chris Brandt]

Hello Uffe

Thank you for your reply.

On 9/13/2016, Ulf Hansson wrote:
> Because, if you have an external regulator feeding the mmc with power you
> should set it up and use it.

But in many board designs, there is no control over the regulator supply (or you would rather have your bootloader do that, not the kernel).

So what this patch is doing is setting it to a default of 3.3v (for just this SoC) and if someone wants to add a regulator in the board's DT file, that will override the ocr_mask set by the driver.


I'm assuming I'll have to do the same for MMC (sh_mmcif.c) once I get to that driver (I need to find my MMC PLUS card first for testing).


Chris

Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

[Ulf Hansson]

On 13 September 2016 at 17:59, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> Hello Uffe
>
> Thank you for your reply.
>
> On 9/13/2016, Ulf Hansson wrote:
>> Because, if you have an external regulator feeding the mmc with power you
>> should set it up and use it.
>
> But in many board designs, there is no control over the regulator supply (or you would rather have your bootloader do that, not the kernel).
>
> So what this patch is doing is setting it to a default of 3.3v (for just this SoC) and if someone wants to add a regulator in the board's DT file, that will override the ocr_mask set by the driver.

That's perfectly okay to me! I just wanted to get clear picture of
*why* this change was needed.

>
>
> I'm assuming I'll have to do the same for MMC (sh_mmcif.c) once I get to that driver (I need to find my MMC PLUS card first for testing).

Okay!

Kind regards
Uffe

RE: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

[Chris Brandt]

On 9/17/2016, Ulf Hansson wrote:
> > I'm assuming I'll have to do the same for MMC (sh_mmcif.c) once I get to
> that driver (I need to find my MMC PLUS card first for testing).
> 
> Okay!
> 
> Kind regards
> Uffe

Just FYI,
For the eMMC case,  I decided not to modify sh_mmcif.c to add the OCR and instead just create a 3.3 fixed regulator in the DT.

The reason is that if someone is using eMMC for their file system, they are probably using external RAM (since block data needs to be copied out of eMMC into RAM before they can be executed). So the extra RAM needed for the regular DT is not really an issue.


However, the people using SDHI are using it for SDIO for Wifi modules and they are the ones with the slimmed down RAM systems. So for them, removing the regulator DT will help squeeze their system into 3MB or 5MB of in-chip system RAM.


Chris

RE: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

[Chris Brandt]

On 9/13/2016, Ulf Hansson wrote:
> Regarding the ocr_mask; How do these SoCs provides the power to the mmc/sd
> card?
> 
> Do note, I am *not* talking about the I/O voltage but the core power to
> the card.

The SoC does not *provide* power to the card. It's not that fancy. How the 3.3v is supplied to the card slot is up to the board designer. But, the SoC spec says the I/O should be 3.3v, so we might as well fix the OCR as 3.3v because they don't have a choice.

I did see all the DT regulator stuff for the other Renesas SoC, but all that is beyond how this chip is being used.

Also note that this SoC (Renesas RZ/A1), unlike the others, is being used with XIP_KERNEL because it's possible to run a full kernel without any external memory (it comes in a 3MB, 5MB, or 10RM internal RAM versions). So, I'm trying to avoid adding extra DT "stuff" that just takes up more RAM resources and has no value for these simple embedded systems. I know in other DDR based system with Megs and Megs of RAM to spare this isn't a problem, but in an XIP_KERNEL environment, it all adds up.

One of the reasons why I haven't been trying to push our BSP upstream and move everyone is because I'm afraid of what all the new DT bloat is going to do to the kernel RAM usage.

Chris

Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

[Wolfram Sang]

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

On Mon, Sep 12, 2016 at 10:15:05AM -0400, Chris Brandt wrote:
> In moving platforms from board files to DT, there still needs to be a way
> to set the ocr_mask setting for the tmio driver during probe. Without this
> setting, the probe will fail because the supported voltages are not known.
> 
> This patch will also traditional platform registration platforms to
> migrate to DT.
> 
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>

I'm fine with this change:

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

Maybe some details from this discussion could be added to the commit
message?


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

[PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Chris Brandt]

For the r7s72100 SOC, the DATA_PORT register was changed to 32-bits wide.
Therefore a new flag has been created that will allow 32-bit reads/writes
to the DATA_PORT register instead of 16-bit (because 16-bits accesses are
not supported).

Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
v3:
* changed loops to memcpy
v2:
* changed 'data * 0xFF' to 'data & 0xFF'
* added 'const' for sd_ctrl_write32_rep
---
 drivers/mmc/host/tmio_mmc.h     | 12 ++++++++++++
 drivers/mmc/host/tmio_mmc_pio.c | 30 ++++++++++++++++++++++++++++++
 include/linux/mfd/tmio.h        |  5 +++++
 3 files changed, 47 insertions(+)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index ecb99fc..a99e634 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -237,6 +237,12 @@ static inline u32 sd_ctrl_read16_and_16_as_32(struct tmio_mmc_host *host, int ad
 	       readw(host->ctl + ((addr + 2) << host->bus_shift)) << 16;
 }
 
+static inline void sd_ctrl_read32_rep(struct tmio_mmc_host *host, int addr,
+		u32 *buf, int count)
+{
+	readsl(host->ctl + (addr << host->bus_shift), buf, count);
+}
+
 static inline void sd_ctrl_write16(struct tmio_mmc_host *host, int addr, u16 val)
 {
 	/* If there is a hook and it returns non-zero then there
@@ -259,4 +265,10 @@ static inline void sd_ctrl_write32_as_16_and_16(struct tmio_mmc_host *host, int
 	writew(val >> 16, host->ctl + ((addr + 2) << host->bus_shift));
 }
 
+static inline void sd_ctrl_write32_rep(struct tmio_mmc_host *host, int addr,
+		const u32 *buf, int count)
+{
+	writesl(host->ctl + (addr << host->bus_shift), buf, count);
+}
+
 #endif
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 017a4dc..59fac7d 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -443,6 +443,36 @@ static void tmio_mmc_transfer_data(struct tmio_mmc_host *host,
 	/*
 	 * Transfer the data
 	 */
+	if (host->pdata->flags & TMIO_MMC_32BIT_DATA_PORT) {
+		u8 data[4] = { };
+
+		if (is_read)
+			sd_ctrl_read32_rep(host, CTL_SD_DATA_PORT, (u32 *)buf,
+					   count >> 2);
+		else
+			sd_ctrl_write32_rep(host, CTL_SD_DATA_PORT, (u32 *)buf,
+					    count >> 2);
+
+		/* if count was multiple of 4 */
+		if (!(count & 0x3))
+			return;
+
+		buf8 = (u8 *)(buf + (count >> 2));
+		count %= 4;
+
+		if (is_read) {
+			sd_ctrl_read32_rep(host, CTL_SD_DATA_PORT,
+					   (u32 *)data, 1);
+			memcpy(buf8, data, count);
+		} else {
+			memcpy(data, buf8, count);
+			sd_ctrl_write32_rep(host, CTL_SD_DATA_PORT,
+					    (u32 *)data, 1);
+		}
+
+		return;
+	}
+
 	if (is_read)
 		sd_ctrl_read16_rep(host, CTL_SD_DATA_PORT, buf, count >> 1);
 	else
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index 3b95dc7..0dbcb7e 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -100,6 +100,11 @@
 #define TMIO_MMC_SDIO_STATUS_QUIRK	(1 << 8)
 
 /*
+ * Some controllers have a 32-bit wide data port register
+ */
+#define TMIO_MMC_32BIT_DATA_PORT	(1 << 9)
+
+/*
  * Some controllers allows to set SDx actual clock
  */
 #define TMIO_MMC_CLK_ACTUAL		(1 << 10)
-- 
2.9.2

Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Ulf Hansson]

+ Lee

On 12 September 2016 at 16:15, Chris Brandt <chris.brandt@renesas.com> wrote:
> For the r7s72100 SOC, the DATA_PORT register was changed to 32-bits wide.
> Therefore a new flag has been created that will allow 32-bit reads/writes
> to the DATA_PORT register instead of 16-bit (because 16-bits accesses are
> not supported).
>
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
> ---
> v3:
> * changed loops to memcpy
> v2:
> * changed 'data * 0xFF' to 'data & 0xFF'
> * added 'const' for sd_ctrl_write32_rep
> ---
>  drivers/mmc/host/tmio_mmc.h     | 12 ++++++++++++
>  drivers/mmc/host/tmio_mmc_pio.c | 30 ++++++++++++++++++++++++++++++
>  include/linux/mfd/tmio.h        |  5 +++++

This header file needs to be split up. The mmc specific bits, should
be moved to a local header file under driver/mmc/host/*.

Sure, we don't need to do that as part of $subject patch, but then I
need an ack from Lee Jones, the mfd maintainer. I have added him on
cc.

>  3 files changed, 47 insertions(+)
>
> diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
> index ecb99fc..a99e634 100644
> --- a/drivers/mmc/host/tmio_mmc.h
> +++ b/drivers/mmc/host/tmio_mmc.h
> @@ -237,6 +237,12 @@ static inline u32 sd_ctrl_read16_and_16_as_32(struct tmio_mmc_host *host, int ad
>                readw(host->ctl + ((addr + 2) << host->bus_shift)) << 16;
>  }
>
> +static inline void sd_ctrl_read32_rep(struct tmio_mmc_host *host, int addr,
> +               u32 *buf, int count)
> +{
> +       readsl(host->ctl + (addr << host->bus_shift), buf, count);
> +}
> +
>  static inline void sd_ctrl_write16(struct tmio_mmc_host *host, int addr, u16 val)
>  {
>         /* If there is a hook and it returns non-zero then there
> @@ -259,4 +265,10 @@ static inline void sd_ctrl_write32_as_16_and_16(struct tmio_mmc_host *host, int
>         writew(val >> 16, host->ctl + ((addr + 2) << host->bus_shift));
>  }
>
> +static inline void sd_ctrl_write32_rep(struct tmio_mmc_host *host, int addr,
> +               const u32 *buf, int count)
> +{
> +       writesl(host->ctl + (addr << host->bus_shift), buf, count);
> +}
> +
>  #endif
> diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
> index 017a4dc..59fac7d 100644
> --- a/drivers/mmc/host/tmio_mmc_pio.c
> +++ b/drivers/mmc/host/tmio_mmc_pio.c
> @@ -443,6 +443,36 @@ static void tmio_mmc_transfer_data(struct tmio_mmc_host *host,
>         /*
>          * Transfer the data
>          */
> +       if (host->pdata->flags & TMIO_MMC_32BIT_DATA_PORT) {
> +               u8 data[4] = { };
> +
> +               if (is_read)
> +                       sd_ctrl_read32_rep(host, CTL_SD_DATA_PORT, (u32 *)buf,
> +                                          count >> 2);
> +               else
> +                       sd_ctrl_write32_rep(host, CTL_SD_DATA_PORT, (u32 *)buf,
> +                                           count >> 2);
> +
> +               /* if count was multiple of 4 */
> +               if (!(count & 0x3))
> +                       return;
> +
> +               buf8 = (u8 *)(buf + (count >> 2));
> +               count %= 4;
> +
> +               if (is_read) {
> +                       sd_ctrl_read32_rep(host, CTL_SD_DATA_PORT,
> +                                          (u32 *)data, 1);
> +                       memcpy(buf8, data, count);
> +               } else {
> +                       memcpy(data, buf8, count);
> +                       sd_ctrl_write32_rep(host, CTL_SD_DATA_PORT,
> +                                           (u32 *)data, 1);
> +               }
> +
> +               return;
> +       }
> +
>         if (is_read)
>                 sd_ctrl_read16_rep(host, CTL_SD_DATA_PORT, buf, count >> 1);
>         else
> diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
> index 3b95dc7..0dbcb7e 100644
> --- a/include/linux/mfd/tmio.h
> +++ b/include/linux/mfd/tmio.h
> @@ -100,6 +100,11 @@
>  #define TMIO_MMC_SDIO_STATUS_QUIRK     (1 << 8)
>
>  /*
> + * Some controllers have a 32-bit wide data port register
> + */
> +#define TMIO_MMC_32BIT_DATA_PORT       (1 << 9)
> +
> +/*
>   * Some controllers allows to set SDx actual clock
>   */
>  #define TMIO_MMC_CLK_ACTUAL            (1 << 10)
> --
> 2.9.2
>
>

Kind regards
Uffe

RE: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Chris Brandt]

On 9/22/2016, Ulf Hansson wrote:
> To: Chris Brandt <Chris.Brandt@renesas.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>; Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com>; Geert Uytterhoeven <geert@linux-
> m68k.org>; Simon Horman <horms+renesas@verge.net.au>; linux-mmc <linux-
> mmc@vger.kernel.org>; Linux-Renesas <linux-renesas-soc@vger.kernel.org>;
> Lee Jones <lee@kernel.org>
> Subject: Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port
> 
> + Lee
> 
> On 12 September 2016 at 16:15, Chris Brandt <chris.brandt@renesas.com>
> wrote:
> > For the r7s72100 SOC, the DATA_PORT register was changed to 32-bits wide.
> > Therefore a new flag has been created that will allow 32-bit
> > reads/writes to the DATA_PORT register instead of 16-bit (because
> > 16-bits accesses are not supported).
> >
> > Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
> > ---
> > v3:
> > * changed loops to memcpy
> > v2:
> > * changed 'data * 0xFF' to 'data & 0xFF'
> > * added 'const' for sd_ctrl_write32_rep
> > ---
> >  drivers/mmc/host/tmio_mmc.h     | 12 ++++++++++++
> >  drivers/mmc/host/tmio_mmc_pio.c | 30 ++++++++++++++++++++++++++++++
> >  include/linux/mfd/tmio.h        |  5 +++++
> 
> This header file needs to be split up. The mmc specific bits, should be
> moved to a local header file under driver/mmc/host/*.
> 
> Sure, we don't need to do that as part of $subject patch, but then I need
> an ack from Lee Jones, the mfd maintainer. I have added him on cc.


Is this still waiting on an ACK from Lee Jones because it touches the tmio.h file under include/linux/mfd/ ?





 
> >  3 files changed, 47 insertions(+)
> >
> > diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
> > index ecb99fc..a99e634 100644
> > --- a/drivers/mmc/host/tmio_mmc.h
> > +++ b/drivers/mmc/host/tmio_mmc.h
> > @@ -237,6 +237,12 @@ static inline u32
> sd_ctrl_read16_and_16_as_32(struct tmio_mmc_host *host, int ad
> >                readw(host->ctl + ((addr + 2) << host->bus_shift)) <<
> > 16;  }
> >
> > +static inline void sd_ctrl_read32_rep(struct tmio_mmc_host *host, int
> addr,
> > +               u32 *buf, int count)
> > +{
> > +       readsl(host->ctl + (addr << host->bus_shift), buf, count); }
> > +
> >  static inline void sd_ctrl_write16(struct tmio_mmc_host *host, int
> > addr, u16 val)  {
> >         /* If there is a hook and it returns non-zero then there @@
> > -259,4 +265,10 @@ static inline void sd_ctrl_write32_as_16_and_16(struct
> tmio_mmc_host *host, int
> >         writew(val >> 16, host->ctl + ((addr + 2) <<
> > host->bus_shift));  }
> >
> > +static inline void sd_ctrl_write32_rep(struct tmio_mmc_host *host, int
> addr,
> > +               const u32 *buf, int count) {
> > +       writesl(host->ctl + (addr << host->bus_shift), buf, count); }
> > +
> >  #endif
> > diff --git a/drivers/mmc/host/tmio_mmc_pio.c
> > b/drivers/mmc/host/tmio_mmc_pio.c index 017a4dc..59fac7d 100644
> > --- a/drivers/mmc/host/tmio_mmc_pio.c
> > +++ b/drivers/mmc/host/tmio_mmc_pio.c
> > @@ -443,6 +443,36 @@ static void tmio_mmc_transfer_data(struct
> tmio_mmc_host *host,
> >         /*
> >          * Transfer the data
> >          */
> > +       if (host->pdata->flags & TMIO_MMC_32BIT_DATA_PORT) {
> > +               u8 data[4] = { };
> > +
> > +               if (is_read)
> > +                       sd_ctrl_read32_rep(host, CTL_SD_DATA_PORT, (u32
> *)buf,
> > +                                          count >> 2);
> > +               else
> > +                       sd_ctrl_write32_rep(host, CTL_SD_DATA_PORT, (u32
> *)buf,
> > +                                           count >> 2);
> > +
> > +               /* if count was multiple of 4 */
> > +               if (!(count & 0x3))
> > +                       return;
> > +
> > +               buf8 = (u8 *)(buf + (count >> 2));
> > +               count %= 4;
> > +
> > +               if (is_read) {
> > +                       sd_ctrl_read32_rep(host, CTL_SD_DATA_PORT,
> > +                                          (u32 *)data, 1);
> > +                       memcpy(buf8, data, count);
> > +               } else {
> > +                       memcpy(data, buf8, count);
> > +                       sd_ctrl_write32_rep(host, CTL_SD_DATA_PORT,
> > +                                           (u32 *)data, 1);
> > +               }
> > +
> > +               return;
> > +       }
> > +
> >         if (is_read)
> >                 sd_ctrl_read16_rep(host, CTL_SD_DATA_PORT, buf, count >>
> 1);
> >         else
> > diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h index
> > 3b95dc7..0dbcb7e 100644
> > --- a/include/linux/mfd/tmio.h
> > +++ b/include/linux/mfd/tmio.h
> > @@ -100,6 +100,11 @@
> >  #define TMIO_MMC_SDIO_STATUS_QUIRK     (1 << 8)
> >
> >  /*
> > + * Some controllers have a 32-bit wide data port register  */
> > +#define TMIO_MMC_32BIT_DATA_PORT       (1 << 9)
> > +
> > +/*
> >   * Some controllers allows to set SDx actual clock
> >   */
> >  #define TMIO_MMC_CLK_ACTUAL            (1 << 10)
> > --
> > 2.9.2
> >
> >
> 
> Kind regards
> Uffe

Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Ulf Hansson]

On 14 October 2016 at 15:18, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On 9/22/2016, Ulf Hansson wrote:
>> To: Chris Brandt <Chris.Brandt@renesas.com>
>> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>; Sergei Shtylyov
>> <sergei.shtylyov@cogentembedded.com>; Geert Uytterhoeven <geert@linux-
>> m68k.org>; Simon Horman <horms+renesas@verge.net.au>; linux-mmc <linux-
>> mmc@vger.kernel.org>; Linux-Renesas <linux-renesas-soc@vger.kernel.org>;
>> Lee Jones <lee@kernel.org>
>> Subject: Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port
>>
>> + Lee
>>
>> On 12 September 2016 at 16:15, Chris Brandt <chris.brandt@renesas.com>
>> wrote:
>> > For the r7s72100 SOC, the DATA_PORT register was changed to 32-bits wide.
>> > Therefore a new flag has been created that will allow 32-bit
>> > reads/writes to the DATA_PORT register instead of 16-bit (because
>> > 16-bits accesses are not supported).
>> >
>> > Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
>> > ---
>> > v3:
>> > * changed loops to memcpy
>> > v2:
>> > * changed 'data * 0xFF' to 'data & 0xFF'
>> > * added 'const' for sd_ctrl_write32_rep
>> > ---
>> >  drivers/mmc/host/tmio_mmc.h     | 12 ++++++++++++
>> >  drivers/mmc/host/tmio_mmc_pio.c | 30 ++++++++++++++++++++++++++++++
>> >  include/linux/mfd/tmio.h        |  5 +++++
>>
>> This header file needs to be split up. The mmc specific bits, should be
>> moved to a local header file under driver/mmc/host/*.
>>
>> Sure, we don't need to do that as part of $subject patch, but then I need
>> an ack from Lee Jones, the mfd maintainer. I have added him on cc.
>
>
> Is this still waiting on an ACK from Lee Jones because it touches the tmio.h file under include/linux/mfd/ ?
>

Yes, but more important is Wolfram's ack as he maintains
drivers/mmc/host/tmio_mmc*

Kind regards
Uffe

Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Wolfram Sang]

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


> > Is this still waiting on an ACK from Lee Jones because it touches the tmio.h file under include/linux/mfd/ ?
> >
> 
> Yes, but more important is Wolfram's ack as he maintains
> drivers/mmc/host/tmio_mmc*

Sorry, LinuxCon and ELC Europe kept me very busy. Will do this week.


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

Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Wolfram Sang]

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

On Mon, Sep 12, 2016 at 10:15:06AM -0400, Chris Brandt wrote:
> For the r7s72100 SOC, the DATA_PORT register was changed to 32-bits wide.
> Therefore a new flag has been created that will allow 32-bit reads/writes
> to the DATA_PORT register instead of 16-bit (because 16-bits accesses are
> not supported).
> 
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
> ---
> v3:
> * changed loops to memcpy
> v2:
> * changed 'data * 0xFF' to 'data & 0xFF'
> * added 'const' for sd_ctrl_write32_rep

Sadly, I don't have SDHI documentation for this SoC.

* Does it have a version register (CTL_VERSION)? If so, what does it
  say?
* Does it have SD_BUF0 width setting (named either EXT_ACC or HOST_MODE,
  so far always comes after the version register)? If so, what is its
  layout?

Unrelated to this patch but nice to know:

* Does it support DMA? Is it compatible to the current implementation?

That being asked, R-Car SoCs can have SDBUF0 32-bit wide as well (Gen3
even 64-bit). So far, this is only used for DMA, though.

Thanks,

   Wolfram

> +		/* if count was multiple of 4 */
> +		if (!(count & 0x3))
> +			return;
> +		buf8 = (u8 *)(buf + (count >> 2));
> +		count %= 4;

To skip the same operation done on 'count' twice, maybe?

		buf8 = (u8 *)(buf + (count >> 2));
		count &= 3;

		if (!count)
			return;


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

RE: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Chris Brandt]

On 10/20/2016, Wolfram Sang wrote:
> Sadly, I don't have SDHI documentation for this SoC.

In the current hardware manual on renesas.com, the SHDI section is not included.
However, for version 3.0 that will be posted shortly, it will start to include the SDHI section.


> * Does it have a version register (CTL_VERSION)? If so, what does it
>   say?

0x820B


> * Does it have SD_BUF0 width setting (named either EXT_ACC or HOST_MODE,
>   so far always comes after the version register)? If so, what is its
>   layout?

There is a "EXT_SWAP" register. It is the only thing after VERSION.
   VERSION = 0xE804E0E2
  EXT_SWAP = 0xE804E0F0

Here are the bits in that register:

DMASE (bit 8)
	DMA Transfer Size Select
	Selects the transfer unit for SD_BUF read/write DMA transfer. Set this bit
	in combination with the transfer size set in the DMA Channel
	Configuration register.
	0: 4-byte (longword) unit
	1: 64-byte (longword  16) unit

SDBRSWAP (bit 7)
	SD_BUF0 Swap Read*1
	When reading from SD_BUF0, data stored in SD_BUF0 can be replaced
	and then read.*2
	0: The current data is read without replacement.
	1: Data replacement for reading proceeds in bytes

SDBWSWAP (bit 6)
	SD_BUF0 Swap Write*1
	When writing to SD_BUF0, data to be written can be replaced and then
	stored in SD_BUF0.*2
	0: The current data is written without replacement.
	1: Data replacement for writing proceeds in bytes.


> * Does it support DMA?
Yes.


> Is it compatible to the current implementation?

I don't know yet. The current BSP is on 3.14 and it uses DMA, but I'm not sure what's going to happen as I start moving things to 4.9+.




> > +		/* if count was multiple of 4 */
> > +		if (!(count & 0x3))
> > +			return;
> > +		buf8 = (u8 *)(buf + (count >> 2));
> > +		count %= 4;
> 
> To skip the same operation done on 'count' twice, maybe?
> 
> 		buf8 = (u8 *)(buf + (count >> 2));
> 		count &= 3;
> 
> 		if (!count)
> 			return;


That looks like it should work.
I can try it out and see if there is something we are missing.


Thanks

Chris

Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Wolfram Sang]

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


> However, for version 3.0 that will be posted shortly, it will start to include the SDHI section.

Nice. Could you ping me when this comes out?

> > * Does it have a version register (CTL_VERSION)? If so, what does it
> >   say?
> 
> 0x820B

Okay, this is a version I have not seen before.

> > * Does it have SD_BUF0 width setting (named either EXT_ACC or HOST_MODE,
> >   so far always comes after the version register)? If so, what is its
> >   layout?
> 
> There is a "EXT_SWAP" register. It is the only thing after VERSION.
>    VERSION = 0xE804E0E2
>   EXT_SWAP = 0xE804E0F0

This SWAP register exists on R-Car as well. Out of curiosity, what is the
register value of 0xE804E0E4?


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

RE: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Chris Brandt]

> > > * Does it have a version register (CTL_VERSION)? If so, what does it
> > >   say?
> >
> > 0x820B
> 
> Okay, this is a version I have not seen before.

The SDHI IP came from the SH7269 (SH-2A device).

For the VERSION register, the low byte is the version of the IP, but the upper byte is a number that the design group that made the part gives it any time they make a change. So, since this IP was from a SH2A team, the numbering might look different than what the SH4A or R-Car teams have used in the past.



> This SWAP register exists on R-Car as well. Out of curiosity, what is the
> register value of 0xE804E0E4?

0xE804E0E4 = 0x0001

So...something is there!



Chris

Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Wolfram Sang]

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


> For the VERSION register, the low byte is the version of the IP, but
> the upper byte is a number that the design group that made the part

I know. It is just that I haven't seen this one "in the wild" so far.

> > This SWAP register exists on R-Car as well. Out of curiosity, what is the
> > register value of 0xE804E0E4?
> 
> 0xE804E0E4 = 0x0001
> 
> So...something is there!

I am quite convinced there is this BUSWIDTH register. If you are
interested, try setting this to 0 and see if it works without the 32 bit
register patches.


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

Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Geert Uytterhoeven]

Hi Wolfram,

On Fri, Oct 21, 2016 at 11:56 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>> For the VERSION register, the low byte is the version of the IP, but
>> the upper byte is a number that the design group that made the part
>
> I know. It is just that I haven't seen this one "in the wild" so far.

I think you can also see it on your tamed Genmai ;-)

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 v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Wolfram Sang]

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

On Mon, Oct 24, 2016 at 01:06:38PM +0200, Geert Uytterhoeven wrote:
> Hi Wolfram,
> 
> On Fri, Oct 21, 2016 at 11:56 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> >> For the VERSION register, the low byte is the version of the IP, but
> >> the upper byte is a number that the design group that made the part
> >
> > I know. It is just that I haven't seen this one "in the wild" so far.
> 
> I think you can also see it on your tamed Genmai ;-)

I intentionally did not write "couldn't have seen this" ;)


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

RE: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Chris Brandt]

> > > This SWAP register exists on R-Car as well. Out of curiosity, what
> > > is the register value of 0xE804E0E4?
> >
> > 0xE804E0E4 = 0x0001
> >
> > So...something is there!
> 
> I am quite convinced there is this BUSWIDTH register. If you are
> interested, try setting this to 0 and see if it works without the 32 bit
> register patches.

Well, it looks like I can't write that register location to 0.
It always keeps a value of 0x0001. So, it must be read-only.

It was a good idea though.
Still, I might try to find out what is there at that location out of curiosity.

Without my the 32-bit write patch, I get a lot of these messages:

    sh_mobile_sdhi e804e800.sd: timeout waiting for SD bus idle



Chris

RE: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Chris Brandt]

Hello Wolfram,

> > > +		/* if count was multiple of 4 */
> > > +		if (!(count & 0x3))
> > > +			return;
> > > +		buf8 = (u8 *)(buf + (count >> 2));
> > > +		count %= 4;
> >
> > To skip the same operation done on 'count' twice, maybe?
> >
> > 		buf8 = (u8 *)(buf + (count >> 2));
> > 		count &= 3;
> >
> > 		if (!count)
> > 			return;
> 
> 
> That looks like it should work.
> I can try it out and see if there is something we are missing.

Seems to work fine. Although I admit that because the driver is mostly being used as a block device (SD card), all the data requests are an even multiple of 4 (I put a printk after "if (!count) return;" ). Not sure if that will be the case when I test SDIO devices, but I'll find out once I start porting SDIO device drivers to 4.9+.


I'll submit a v4 of this patch series tomorrow.

Thank you.

Chris

Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Wolfram Sang]

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


> I'll submit a v4 of this patch series tomorrow.

Please wait a little. I'd like to use that feature on R-Car, too, so I
wonder if the additional feature flag is the proper path.


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

Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Wolfram Sang]

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

Hi Chris,

On Mon, Sep 12, 2016 at 10:15:06AM -0400, Chris Brandt wrote:
> For the r7s72100 SOC, the DATA_PORT register was changed to 32-bits wide.
> Therefore a new flag has been created that will allow 32-bit reads/writes
> to the DATA_PORT register instead of 16-bit (because 16-bits accesses are
> not supported).
> 
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>

Okay, I have a sketch how to add this feature to R-Car SoCs at a later
stage. This patch is fine with one minor nit which can be done now or I
can do it later when I add the R-Car support.

> + * Some controllers have a 32-bit wide data port register
> + */
> +#define TMIO_MMC_32BIT_DATA_PORT	(1 << 9)

Since R-Car Gen3 has 64 bit port, I'd suggest to use
TMIO_MMC_BIG_DATA_PORT or something. But as I said, I can also do this
later. So

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


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

RE: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Chris Brandt]

Hi Wolfram,


> Okay, I have a sketch how to add this feature to R-Car SoCs at a later
> stage. This patch is fine with one minor nit which can be done now or I
> can do it later when I add the R-Car support.
> 
> > + * Some controllers have a 32-bit wide data port register  */
> > +#define TMIO_MMC_32BIT_DATA_PORT	(1 << 9)
> 
> Since R-Car Gen3 has 64 bit port, I'd suggest to use
> TMIO_MMC_BIG_DATA_PORT or something. But as I said, I can also do this
> later. So

I don't understand "TMIO_MMC_BIG_DATA_PORT" (How do you know 32-bit?? How do you know 64-bit??)


So......maybe you can change it later and your idea will be more clear to me then.


Thank you,
Chris

Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Wolfram Sang]

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

> I don't understand "TMIO_MMC_BIG_DATA_PORT" (How do you know 32-bit?? How do you know 64-bit??)

I think 16 << host->bus_shift should work; need to verify this, though.

> So......maybe you can change it later and your idea will be more clear to me then.

Yes, fine with me.


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

RE: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port

[Chris Brandt]

> > I don't understand "TMIO_MMC_BIG_DATA_PORT" (How do you know 32-bit??
> How do you know 64-bit??)
> 
> I think 16 << host->bus_shift should work; need to verify this, though.


Good idea.

[PATCH v3 3/3] mmc: sh_mobile_sdhi: Add r7s72100 support

[Chris Brandt]

Add support for r7s72100 SoC.

Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
 Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
 drivers/mmc/host/sh_mobile_sdhi.c                  | 7 +++++++
 2 files changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index 13df9c2..08b3a30 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -13,6 +13,7 @@ Required properties:
 - compatible:	"renesas,sdhi-shmobile" - a generic sh-mobile SDHI unit
 		"renesas,sdhi-sh7372" - SDHI IP on SH7372 SoC
 		"renesas,sdhi-sh73a0" - SDHI IP on SH73A0 SoC
+		"renesas,sdhi-r7s72100" - SDHI IP on R7S72100 SoC
 		"renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC
 		"renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
 		"renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index b033500..fe9cc41 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -77,6 +77,12 @@ static const struct sh_mobile_sdhi_of_data of_default_cfg = {
 	.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
 };
 
+static const struct sh_mobile_sdhi_of_data of_rz_compatible = {
+	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_32BIT_DATA_PORT,
+	.tmio_ocr_mask	= MMC_VDD_32_33,
+	.capabilities	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
+};
+
 static const struct sh_mobile_sdhi_of_data of_rcar_gen1_compatible = {
 	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
 			  TMIO_MMC_CLK_ACTUAL,
@@ -133,6 +139,7 @@ static const struct of_device_id sh_mobile_sdhi_of_match[] = {
 	{ .compatible = "renesas,sdhi-sh73a0", .data = &of_default_cfg, },
 	{ .compatible = "renesas,sdhi-r8a73a4", .data = &of_default_cfg, },
 	{ .compatible = "renesas,sdhi-r8a7740", .data = &of_default_cfg, },
+	{ .compatible = "renesas,sdhi-r7s72100", .data = &of_rz_compatible, },
 	{ .compatible = "renesas,sdhi-r8a7778", .data = &of_rcar_gen1_compatible, },
 	{ .compatible = "renesas,sdhi-r8a7779", .data = &of_rcar_gen1_compatible, },
 	{ .compatible = "renesas,sdhi-r8a7790", .data = &of_rcar_gen2_compatible, },
-- 
2.9.2

Re: [PATCH v3 3/3] mmc: sh_mobile_sdhi: Add r7s72100 support

[Wolfram Sang]

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

On Mon, Sep 12, 2016 at 10:15:07AM -0400, Chris Brandt wrote:
> Add support for r7s72100 SoC.
> 
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>

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


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

RE: [PATCH v3 0/3] mmc: sh_mobile_sdhi: Add r7s72100 support

[Chris Brandt]

Hello.

What ever happened to this series of patches?

They didn't seem too outrageous, but they never got applied.

Thank you.

Chris



On 9/12/2016, Chris Brandt wrote:
> To: Ulf Hansson <ulf.hansson@linaro.org>; Wolfram Sang <wsa+renesas@sang-
> engineering.com>; Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>;
> Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Simon Horman <horms+renesas@verge.net.au>; linux-mmc@vger.kernel.org;
> linux-renesas-soc@vger.kernel.org; Chris Brandt <Chris.Brandt@renesas.com>
> Subject: [PATCH v3 0/3] mmc: sh_mobile_sdhi: Add r7s72100 support
> 
> For the most part, the SDHI controller in the RZ/A1 (r7s72100) is the same
> as other Renesas SoC...except for the fact that the data port register was
> widened to 32-bits and the 16-bit accesses in the current tmio driver
> aren't going to cut it.
> 
> Also, the tmio driver allows you to pass in what voltages you support via
> the ocr_mask. For the RZ/A1, it's just simple 3.3v.
> So, I added the ability to pass that when using DT.
> 
> Chris Brandt (3):
>   mmc: sh_mobile_sdhi: add ocr_mask option
>   mmc: tmio-mmc: add support for 32bit data port
>   mmc: sh_mobile_sdhi: Add r7s72100 support
> 
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
>  drivers/mmc/host/sh_mobile_sdhi.c                  |  9 +++++++
>  drivers/mmc/host/tmio_mmc.h                        | 12 +++++++++
>  drivers/mmc/host/tmio_mmc_pio.c                    | 30
> ++++++++++++++++++++++
>  include/linux/mfd/tmio.h                           |  5 ++++
>  5 files changed, 57 insertions(+)
> 
> --
> 2.9.2
> 

Re: [PATCH v3 0/3] mmc: sh_mobile_sdhi: Add r7s72100 support

[Ulf Hansson]

On 12 September 2016 at 16:15, Chris Brandt <chris.brandt@renesas.com> wrote:
> For the most part, the SDHI controller in the RZ/A1 (r7s72100)
> is the same as other Renesas SoC...except for the fact that the
> data port register was widened to 32-bits and the 16-bit accesses
> in the current tmio driver aren't going to cut it.
>
> Also, the tmio driver allows you to pass in what voltages you
> support via the ocr_mask. For the RZ/A1, it's just simple 3.3v.
> So, I added the ability to pass that when using DT.
>
> Chris Brandt (3):
>   mmc: sh_mobile_sdhi: add ocr_mask option
>   mmc: tmio-mmc: add support for 32bit data port
>   mmc: sh_mobile_sdhi: Add r7s72100 support
>
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
>  drivers/mmc/host/sh_mobile_sdhi.c                  |  9 +++++++
>  drivers/mmc/host/tmio_mmc.h                        | 12 +++++++++
>  drivers/mmc/host/tmio_mmc_pio.c                    | 30 ++++++++++++++++++++++
>  include/linux/mfd/tmio.h                           |  5 ++++
>  5 files changed, 57 insertions(+)
>
> --
> 2.9.2
>
>

Thanks, applied for next!

Kind regards
Uffe