mbox series

[4.4.y-cip,00/83] Add RZ/G1C SD/eMMC support

Message ID 1573115572-13513-1-git-send-email-biju.das@bp.renesas.com (mailing list archive)
Headers show
Series Add RZ/G1C SD/eMMC support | expand

Message

Biju Das Nov. 7, 2019, 8:31 a.m. UTC 
This patch series add SD/eMMC support support for RZ/G1C sbc.

RZ/G1C eMMC IP is different from other RZ/G1 SoC's. It is having an 
internal DMA for data transfer which is similar to R-Car Gen3.

Support for internal DMAC is added in 4.14 kernel and support for 
RZ/G1C added on 4.20 kernel.

Backported the relevent patches to linux-4.4.y-cip.

This patch series is based on linux-4.4.y-cip and all the patches
in this series are cherry-picked from linux rc tree.

Ai Kyuse (3):
  mmc: tmio: enhance illegal sequence handling
  mmc: tmio: Add hw reset support
  mmc: tmio: Add tuning support

Arnd Bergmann (1):
  mmc: tmio_mmc_dma: don't print invalid DMA cookie

Ben Hutchings (2):
  mmc: tmio, sh_mobile_sdhi: Pass tmio_mmc_host ptr to clk_{enable,
    disable} ops
  mmc: tmio, sh_mobile_sdhi: Add support for variable input clock
    frequency

Chris Brandt (3):
  mmc: tmio-mmc: add support for 32bit data port
  mmc: sh_mobile_sdhi: add ocr_mask option
  mmc: tmio-mmc: fix bad pointer math

Fabrizio Castro (6):
  dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
  mmc: renesas_sdhi: Add r8a77470 SDHI1 support
  ARM: dts: r8a77470: Add SDHI2 support
  ARM: dts: r8a77470: Add SDHI0 support
  ARM: dts: r8a77470: Add SDHI1 support
  ARM: dts: iwg23s-sbc: Add uSD and eMMC support

Masaharu Hayakawa (1):
  mmc: tmio: always get number of taps

Masahiro Yamada (1):
  mmc: renesas_sdhi: consolidate DMAC CONFIG options

Simon Horman (14):
  mmc: tmio: document mandatory and optional callbacks
  mmc: core: Add helper to see if a host can be retuned
  mmc: sh_mobile_sdhi: Add tuning support
  mmc: tmio: drop filenames from comment at top of source
  mmc: renesas-sdhi, tmio: make dma more modular
  mmc: tmio: rename tmio_mmc_{pio => core}.c
  mmc: renesas-sdhi: rename tmio_mmc_dma.c => renesas_sdhi_sys_dmac.c
  mmc: renesas-sdhi: rename sh_mobile_sdhi.c => renesas_sdhi_core.c
  mmc: renesas-sdhi: make renesas_sdhi_sys_dmac main module file
  mmc: renesas-sdhi: improve checkpatch cleanness
  mmc: tmio, renesas-sdhi: add dataend to DMA ops
  mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC
  dt-bindings: mmc: renesas_sdhi: add R-Car Gen[123] fallback
    compatibility strings
  mmc: renesas_sdhi: implement R-Car Gen[123] fallback compatibility
    strings

Ulf Hansson (2):
  mmc: tmio: Remove redundant runtime PM calls
  mmc: tmio: Remove redundant check of mmc->slot.cd_irq

Wolfram Sang (49):
  mmc: tmio_dma: remove debug messages with little information
  mmc: tmio: add flag to reduce delay after changing clock status
  mmc: tmio: remove stale comments
  mmc: tmio: refactor set_clock a little
  mmc: tmio: disable clock before changing it
  mmc: sdhi: use faster clock handling on RCar Gen2
  mmc: sdhi: error message on ENOMEM is superfluous
  mmc: sdhi: Add r8a7795 support
  mmc: tmio: Add UHS-I mode support
  mmc: sh_mobile_sdhi: Add UHS-I mode support
  mmc: tmio: always start clock after frequency calculation
  mmc: tmio: stop clock when 0Hz is requested
  mmc: sh_mobile_sdhi: remove obsolete irq_by_name registration
  mmc: tmio: remove now unneeded seperate irq handlers
  mmc: tmio: simplify irq handler
  mmc: tmio: merge distributed include files
  mmc: tmio: give read32/write32 functions more descriptive names
  mmc: tmio: use BIT() within defines
  mmc: tmio: use CTL_STATUS consistently
  mmc: tmio/sdhi: distinguish between SCLKDIVEN and ILL_FUNC
  mmc: tmio: document CTL_STATUS handling
  mmc: tmio/sdhi: introduce flag for RCar 2+ specific features
  mmc: sh_mobile_sdhi: make clk_update function more compact
  mmc: sh_mobile_sdhi: only change the clock on RCar Gen2+
  mmc: sh_mobile_sdhi: check return value when changing clk
  mmc: sh_mobile_sdhi: properly document R-Car versions
  mmc: host: sh_mobile_sdhi: move card_busy from tmio to sdhi
  mmc: host: sh_mobile_sdhi: don't populate unneeded functions
  mmc: tmio: add eMMC support
  mmc: add define for R1 response without CRC
  mmc: tmio: fix wrong bitmask for SDIO irqs
  mmc: tmio: remove SDIO from TODO list
  mmc: tmio: use SDIO master interrupt bit only when allowed
  mmc: sh_mobile_sdhi: simplify accessing DT data
  mmc: sh_mobile_sdhi: improve prerequisite for hw_reset
  mmc: sh_mobile_sdhi: remove superfluous check in hw_reset
  mmc: sh_mobile_sdhi: improve prerequisites for tuning
  mmc: sh_mobile_sdhi: remove superfluous check in SCC error check
  mmc: sh_mobile_sdhi: remove superfluous check in init_tuning
  mmc: sh_mobile_sdhi: enable HS200
  mmc: host: tmio: drop superfluous exit path
  mmc: host: tmio: disable clocks when unbinding
  mmc: host: tmio: refactor calls to sdio irq
  mmc: host: tmio: SDIO_STATUS_QUIRK is rather SDIO_STATUS_SETBITS
  mmc: tmio: discard obsolete SDIO irqs before enabling irqs
  mmc: tmio: ensure end of DMA and SD access are in sync
  mmc: host: tmio: use defines for CTL_STOP_INTERNAL_ACTION values
  mmc: host: tmio: don't BUG on unsupported stop commands
  mmc: host: tmio: fill in response from auto cmd12

Yoshihiro Shimoda (1):
  mmc: tmio, renesas-sdhi: add max_{segs, blk_count} to tmio_mmc_data

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |   12 +
 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts          |   75 ++
 arch/arm/boot/dts/r8a77470.dtsi                    |   38 +
 drivers/mmc/host/Kconfig                           |   21 +-
 drivers/mmc/host/Makefile                          |    6 +-
 drivers/mmc/host/renesas_sdhi.h                    |   41 +
 drivers/mmc/host/renesas_sdhi_core.c               |  632 +++++++++
 drivers/mmc/host/renesas_sdhi_internal_dmac.c      |  273 ++++
 drivers/mmc/host/renesas_sdhi_sys_dmac.c           |  480 +++++++
 drivers/mmc/host/sh_mobile_sdhi.c                  |  397 ------
 drivers/mmc/host/tmio_mmc.c                        |   10 +-
 drivers/mmc/host/tmio_mmc.h                        |  170 ++-
 drivers/mmc/host/tmio_mmc_core.c                   | 1399 ++++++++++++++++++++
 drivers/mmc/host/tmio_mmc_dma.c                    |  356 -----
 drivers/mmc/host/tmio_mmc_pio.c                    | 1275 ------------------
 include/linux/mfd/tmio.h                           |   13 +-
 include/linux/mmc/core.h                           |    3 +
 include/linux/mmc/host.h                           |    5 +
 include/linux/mmc/tmio.h                           |   66 -
 19 files changed, 3120 insertions(+), 2152 deletions(-)
 create mode 100644 drivers/mmc/host/renesas_sdhi.h
 create mode 100644 drivers/mmc/host/renesas_sdhi_core.c
 create mode 100644 drivers/mmc/host/renesas_sdhi_internal_dmac.c
 create mode 100644 drivers/mmc/host/renesas_sdhi_sys_dmac.c
 delete mode 100644 drivers/mmc/host/sh_mobile_sdhi.c
 create mode 100644 drivers/mmc/host/tmio_mmc_core.c
 delete mode 100644 drivers/mmc/host/tmio_mmc_dma.c
 delete mode 100644 drivers/mmc/host/tmio_mmc_pio.c
 delete mode 100644 include/linux/mmc/tmio.h

Comments

Pavel Machek Nov. 7, 2019, 9:01 p.m. UTC | #1 
Hi!

> This patch series add SD/eMMC support support for RZ/G1C sbc.
> 
> RZ/G1C eMMC IP is different from other RZ/G1 SoC's. It is having an 
> internal DMA for data transfer which is similar to R-Car Gen3.
> 
> Support for internal DMAC is added in 4.14 kernel and support for 
> RZ/G1C added on 4.20 kernel.
> 
> Backported the relevent patches to linux-4.4.y-cip.
> 
> This patch series is based on linux-4.4.y-cip and all the patches
> in this series are cherry-picked from linux rc tree.

Thanks for the series. I'm currently reviewing it, I have some
comments but nothing really bad so far. I'm now around the middle.

Best regards,
								Pavel
Chris Paterson Nov. 8, 2019, 10:32 a.m. UTC | #2 
Hello Pavel,

> From: Pavel Machek <pavel@denx.de>
> Sent: 07 November 2019 21:02
>
> Hi!
>
> > This patch series add SD/eMMC support support for RZ/G1C sbc.
> >
> > RZ/G1C eMMC IP is different from other RZ/G1 SoC's. It is having an
> > internal DMA for data transfer which is similar to R-Car Gen3.
> >
> > Support for internal DMAC is added in 4.14 kernel and support for
> > RZ/G1C added on 4.20 kernel.
> >
> > Backported the relevent patches to linux-4.4.y-cip.
> >
> > This patch series is based on linux-4.4.y-cip and all the patches
> > in this series are cherry-picked from linux rc tree.
>
> Thanks for the series. I'm currently reviewing it, I have some
> comments but nothing really bad so far. I'm now around the middle.

Thank you for your work on reviewing this series.

Looking at some of your comments, it looks like there are lots of issues to do with the original patches that were upstreamed, rather than changes that were made specifically for the CIP Kernel.

My understanding is that the CIP project follows an upstream first policy, i.e. code must all be upstreamed before being backported to the CIP kernel(s).

For the changes that you're pointing out, should we be upstreaming the relevant fixes, waiting for them to be released upstream, then re-submitting the whole patch series? Or should we be modifying the patches that we're submitting to the CIP kernel directly?

If the former, I'm not actually sure this will always be technically possible.
If the latter, do you want Biju to update each of the patches in his series? Or submit the new cip-specific changes in a new patch?

Kind regards, Chris

>
> Best regards,
>                                                               Pavel
> --
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Pavel Machek Nov. 8, 2019, 11:32 a.m. UTC | #3 
Hi!

> Thank you for your work on reviewing this series.

(For the record, I'm now done with the review... with exception of
renames&modifications in 66-69).

> Looking at some of your comments, it looks like there are lots of issues to do with the original patches that were upstreamed, rather than changes that were made specifically for the CIP Kernel.
> 
> My understanding is that the CIP project follows an upstream first policy, i.e. code must all be upstreamed before being backported to the CIP kernel(s).
> 
> For the changes that you're pointing out, should we be upstreaming the relevant fixes, waiting for them to be released upstream, then re-submitting the whole patch series? Or should we be modifying the patches that we're submitting to the CIP kernel directly?
>

It really depends on case by case basis -- on severity of the problem.

I can take explanations, maybe I'm just misunderstanding the code.

Or perhaps code is really right, but unclear/needs additional comment,
etc... In such case I guess we can take patch as is, and just queue
cleanups/comments to the mainline.

But patch 34/ introduces data corrupting bug, which is only fixed at
the end of the series. I'd prefer having patches changed / reshuffled
/ something so that it does not corrupt someone's data during bisect.

Plus we need to figure out how to review the renames.

> If the former, I'm not actually sure this will always be technically possible.
> If the latter, do you want Biju to update each of the patches in his series? Or submit the new cip-specific changes in a new patch?
>

Not sure really.

One possible way forward would be to submit 1..33/ as separate series,
then figure out 34.. first rename, then figure out the rest.

Best regards,

								Pavel
Biju Das Nov. 8, 2019, 1:43 p.m. UTC | #4 
Hello Pavel,

Thanks for the feedback.

> Subject: Re: [PATCH 4.4.y-cip 00/83] Add RZ/G1C SD/eMMC support
> 
> Hi!
> 
> > Thank you for your work on reviewing this series.
> 
> (For the record, I'm now done with the review... with exception of
> renames&modifications in 66-69).
> 
> > Looking at some of your comments, it looks like there are lots of issues to
> do with the original patches that were upstreamed, rather than changes that
> were made specifically for the CIP Kernel.
> >
> > My understanding is that the CIP project follows an upstream first policy,
> i.e. code must all be upstreamed before being backported to the CIP
> kernel(s).
> >
> > For the changes that you're pointing out, should we be upstreaming the
> relevant fixes, waiting for them to be released upstream, then re-submitting
> the whole patch series? Or should we be modifying the patches that we're
> submitting to the CIP kernel directly?
> >
> 
> It really depends on case by case basis -- on severity of the problem.
> 
> I can take explanations, maybe I'm just misunderstanding the code.
> 
> Or perhaps code is really right, but unclear/needs additional comment, etc...
> In such case I guess we can take patch as is, and just queue
> cleanups/comments to the mainline.
> 
> But patch 34/ introduces data corrupting bug, which is only fixed at the end
> of the series. I'd prefer having patches changed / reshuffled / something so
> that it does not corrupt someone's data during bisect.
> 
> Plus we need to figure out how to review the renames.
> 
> > If the former, I'm not actually sure this will always be technically possible.
> > If the latter, do you want Biju to update each of the patches in his series?
> Or submit the new cip-specific changes in a new patch?
> >
> 
> Not sure really.
> 
> One possible way forward would be to submit 1..33/ as separate series, then
> figure out 34.. first rename, then figure out the rest.

OK. I will send 1--33 as a separate series and then rest. 

Regards,
Biju
Pavel Machek Nov. 8, 2019, 7:58 p.m. UTC | #5 
Hi!

> > Plus we need to figure out how to review the renames.
> > 
> > > If the former, I'm not actually sure this will always be technically possible.
> > > If the latter, do you want Biju to update each of the patches in his series?
> > Or submit the new cip-specific changes in a new patch?
> > >
> > 
> > Not sure really.
> > 
> > One possible way forward would be to submit 1..33/ as separate series, then
> > figure out 34.. first rename, then figure out the rest.
> 
> OK. I will send 1--33 as a separate series and then rest. 

Actually, it seems that review on 1--33 is "minor updates are possible
in mainline", so if you want (and there are no other comments from
other maintainers), I can just take 1--33 and apply them to -cip tree.

Best regards,
								Pavel
Biju Das Nov. 14, 2019, 4:13 p.m. UTC | #6 
Hi Pavel,

Thanks for the feedback.

> Subject: Re: [PATCH 4.4.y-cip 00/83] Add RZ/G1C SD/eMMC support
> 
> Hi!
> 
> > > Plus we need to figure out how to review the renames.
> > >
> > > > If the former, I'm not actually sure this will always be technically
> possible.
> > > > If the latter, do you want Biju to update each of the patches in his
> series?
> > > Or submit the new cip-specific changes in a new patch?
> > > >
> > >
> > > Not sure really.
> > >
> > > One possible way forward would be to submit 1..33/ as separate
> > > series, then figure out 34.. first rename, then figure out the rest.
> >
> > OK. I will send 1--33 as a separate series and then rest.
> 
> Actually, it seems that review on 1--33 is "minor updates are possible in
> mainline", so if you want (and there are no other comments from other
> maintainers), I can just take 1--33 and apply them to -cip tree.

Yes please, if other maintainers are happy.

Please apply the below patch patch before 33,
https://patchwork.kernel.org/patch/11232167/

Can you please suggest, how you want to handle rest of the patches?

Regards,
Biju
Pavel Machek Nov. 15, 2019, 9:10 p.m. UTC | #7 
Hi!

> > > Yes please, if other maintainers are happy.
> > >
> > > Please apply the below patch patch before 33,
> > > https://patchwork.kernel.org/patch/11232167/
> > 
> > I applied 1..33. That caused build failure. I added 35, which fixes the compile
> > problem.
> 
> Yes. I knew, that is the reason I provided the above link.

Oops, I was not paying close enough attention. Sorry about that.

> > > Can you please suggest, how you want to handle rest of the patches?
> > 
> > Would it be possible to reorder (and/or merge) patches so that the data
> > corruption bug can not trigger, and re-submit series up-to the big renames?
> > That should give about 30 patches to review...
> 
> Will do.

Thanks!

Best regards,
								Pavel
Biju Das Nov. 18, 2019, 7:42 a.m. UTC | #8 
HI Pavel,

Thanks for the feedback.

> Subject: Re: [PATCH 4.4.y-cip 00/83] Add RZ/G1C SD/eMMC support
> 
> Hi!
> 
> > > > Yes please, if other maintainers are happy.
> > > >
> > > > Please apply the below patch patch before 33,
> > > > https://patchwork.kernel.org/patch/11232167/
> > >
> > > I applied 1..33. That caused build failure. I added 35, which fixes
> > > the compile problem.
> >
> > Yes. I knew, that is the reason I provided the above link.
> 
> Oops, I was not paying close enough attention. Sorry about that.

Is it possible for you to rearrange the patch?

Ie, patch " mmc: add define for R1 response without CRC" should go before
" mmc: tmio: add eMMC support". Other wise you will get a compilation error
If someone checkout the branch with the commit id of  later patch.

Cheers,
Biju
Pavel Machek Nov. 18, 2019, 10:38 a.m. UTC | #9 
Hi!

> > > > > Yes please, if other maintainers are happy.
> > > > >
> > > > > Please apply the below patch patch before 33,
> > > > > https://patchwork.kernel.org/patch/11232167/
> > > >
> > > > I applied 1..33. That caused build failure. I added 35, which fixes
> > > > the compile problem.
> > >
> > > Yes. I knew, that is the reason I provided the above link.
> > 
> > Oops, I was not paying close enough attention. Sorry about that.
> 
> Is it possible for you to rearrange the patch?

> Ie, patch " mmc: add define for R1 response without CRC" should go before
> " mmc: tmio: add eMMC support". Other wise you will get a compilation error
> If someone checkout the branch with the commit id of  later patch.

It is possible, but it would require me to rebase and then force push,
causing problems for people who pulled the tree in the meantime. I
believe risks outweight the advantages at this point.

Best regards,
								Pavel