mbox series

[v4,0/3] mmc: renesas_sdhi: improve performance by changing max_segs

Message ID 1559301371-21200-1-git-send-email-yoshihiro.shimoda.uh@renesas.com (mailing list archive)
Headers show
Series mmc: renesas_sdhi: improve performance by changing max_segs | expand

Message

Yoshihiro Shimoda May 31, 2019, 11:16 a.m. UTC
This patch series is based on iommu.git / next branch.

Since SDHI host internal DMAC of the R-Car Gen3 cannot handle two or more
segments, the performance rate (especially, eMMC HS400 reading) is not good.
However, if IOMMU is enabled on the DMAC, since IOMMU will map multiple
scatter gather buffers as one contignous iova, the DMAC can handle the iova
as well and then the performance rate is possible to improve. In fact,
I have measured the performance by using bonnie++, "Sequential Input - block"
rate was improved on r8a7795.

However, in case of a sdio card (especiialy some WiFi cards/drivers),
scatter gather buffers are possible to be not contiguous iova because
each scatter gather buffer has only about 1500 bytes, the DMAC cannot
handle it. So, this patch set adds init_card() ops to detect the card
type, and then the driver changes the max_segs if the DMAC is under
IOMMU environment and an sd card/mmc is detected.

Changes from v3 [1]:
 - Use a helper function device_iommu_mapped on patch 1 and 3.
 - Check if R-Car Gen3 IPMMU is used or not on patch 3.
 - Check if all multiple segment buffers are aligned to PAGE_SIZE on patch 3.
 - Add Reviewed-by Wolfram-san on patch 1 and 2. Note that I also got his
   Reviewed-by on patch 3, but I changed it from v2. So, I didn't add
   his Reviewed-by at this time.

Changes from v2 [2]:
 - Add some conditions in the init_card().
 - Add a comment in the init_card().
 - Add definitions for some "MAX_SEGS".

Changes from v1 [3]:
 - Remove adding init_card ops into struct tmio_mmc_dma_ops and
   tmio_mmc_host and just set init_card on renesas_sdhi_core.c.
 - Revise typos on "mmc: tmio: No memory size limitation if runs on IOMMU".
 - Add Simon-san's Reviewed-by on a tmio patch.

[1]
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=120985

[2]
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=116729

[3]
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=110485


Yoshihiro Shimoda (3):
  mmc: tmio: No memory size limitation if runs on IOMMU
  mmc: tmio: Add a definition for default max_segs
  mmc: renesas_sdhi: use multiple segments if possible

 drivers/mmc/host/renesas_sdhi.h               |  1 +
 drivers/mmc/host/renesas_sdhi_core.c          | 60 +++++++++++++++++++++++++++
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 19 +++++++++
 drivers/mmc/host/tmio_mmc.h                   |  1 +
 drivers/mmc/host/tmio_mmc_core.c              |  7 ++--
 5 files changed, 85 insertions(+), 3 deletions(-)

Comments

Wolfram Sang June 3, 2019, 12:57 p.m. UTC | #1
On Fri, May 31, 2019 at 08:16:08PM +0900, Yoshihiro Shimoda wrote:
> This patch series is based on iommu.git / next branch.
> 
> Since SDHI host internal DMAC of the R-Car Gen3 cannot handle two or more
> segments, the performance rate (especially, eMMC HS400 reading) is not good.
> However, if IOMMU is enabled on the DMAC, since IOMMU will map multiple
> scatter gather buffers as one contignous iova, the DMAC can handle the iova
> as well and then the performance rate is possible to improve. In fact,
> I have measured the performance by using bonnie++, "Sequential Input - block"
> rate was improved on r8a7795.
> 
> However, in case of a sdio card (especiialy some WiFi cards/drivers),
> scatter gather buffers are possible to be not contiguous iova because
> each scatter gather buffer has only about 1500 bytes, the DMAC cannot
> handle it. So, this patch set adds init_card() ops to detect the card
> type, and then the driver changes the max_segs if the DMAC is under
> IOMMU environment and an sd card/mmc is detected.
> 
> Changes from v3 [1]:
>  - Use a helper function device_iommu_mapped on patch 1 and 3.
>  - Check if R-Car Gen3 IPMMU is used or not on patch 3.
>  - Check if all multiple segment buffers are aligned to PAGE_SIZE on patch 3.
>  - Add Reviewed-by Wolfram-san on patch 1 and 2. Note that I also got his
>    Reviewed-by on patch 3, but I changed it from v2. So, I didn't add
>    his Reviewed-by at this time.

Yes, dropping my rev on patch 3 is a good thing to do. I added Christoph
to the CC list because he gave valuable input last time.

@hch: If you didn't get the original mails from some list, I can bounce
them to you or you can find them here:

https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=125593

> 
> Changes from v2 [2]:
>  - Add some conditions in the init_card().
>  - Add a comment in the init_card().
>  - Add definitions for some "MAX_SEGS".
> 
> Changes from v1 [3]:
>  - Remove adding init_card ops into struct tmio_mmc_dma_ops and
>    tmio_mmc_host and just set init_card on renesas_sdhi_core.c.
>  - Revise typos on "mmc: tmio: No memory size limitation if runs on IOMMU".
>  - Add Simon-san's Reviewed-by on a tmio patch.
> 
> [1]
> https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=120985
> 
> [2]
> https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=116729
> 
> [3]
> https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=110485
> 
> 
> Yoshihiro Shimoda (3):
>   mmc: tmio: No memory size limitation if runs on IOMMU
>   mmc: tmio: Add a definition for default max_segs
>   mmc: renesas_sdhi: use multiple segments if possible
> 
>  drivers/mmc/host/renesas_sdhi.h               |  1 +
>  drivers/mmc/host/renesas_sdhi_core.c          | 60 +++++++++++++++++++++++++++
>  drivers/mmc/host/renesas_sdhi_internal_dmac.c | 19 +++++++++
>  drivers/mmc/host/tmio_mmc.h                   |  1 +
>  drivers/mmc/host/tmio_mmc_core.c              |  7 ++--
>  5 files changed, 85 insertions(+), 3 deletions(-)
> 
> -- 
> 2.7.4
>
Christoph Hellwig June 3, 2019, 1:11 p.m. UTC | #2
On Mon, Jun 03, 2019 at 02:57:01PM +0200, Wolfram Sang wrote:
> Yes, dropping my rev on patch 3 is a good thing to do. I added Christoph
> to the CC list because he gave valuable input last time.

Assuming iommu merging in a driver using the DMA API is always bogus
as mentioned last time.  As this cover letter don't seem to include
any higher level DMA subsystem or block changes I'll stick to my NAK.
Yoshihiro Shimoda June 4, 2019, 1:27 a.m. UTC | #3
Hi Christoph, Wolfram,

> From: Christoph Hellwig, Sent: Monday, June 3, 2019 10:12 PM
> 
> On Mon, Jun 03, 2019 at 02:57:01PM +0200, Wolfram Sang wrote:
> > Yes, dropping my rev on patch 3 is a good thing to do. I added Christoph
> > to the CC list because he gave valuable input last time.
> 
> Assuming iommu merging in a driver using the DMA API is always bogus
> as mentioned last time.  As this cover letter don't seem to include
> any higher level DMA subsystem or block changes I'll stick to my NAK.

Thank you very much for your reply again. I understood this patch series is NAK.
I'll continue to investigate DMA or block subsystem to achieve this. (I'm not sure
I can succeed or not though...)

Best regards,
Yoshihiro Shimoda