mbox series

[RFC,v3.1,00/27] Add support UHS-II for GL9755

Message ID 20201106022726.19831-1-takahiro.akashi@linaro.org
Headers show
Series Add support UHS-II for GL9755 | expand

Message

AKASHI Takahiro Nov. 6, 2020, 2:26 a.m. UTC
This is an interim snapshot of our next version, v4, for enabling
UHS-II on MMC/SD.

It is focused on 'sdhci' side to address Adrian's comments regarding
"modularising" sdhci-uhs2.c.
The whole aim of this version is to get early feedback from Adrian (and
others) on this issue. Without any consensus about the code structure,
it would make little sense to go further ahead on sdhci side.
(Actually, Adrian has made no comments other than "modularising" so far.)

I heavily reworked/refactored sdhci-uhs2.c and re-organised the patch
set to meet what I believe Adrian expects; no UHS-II related code in
Legacy (UHS-I) code or sdhci.c.

Nevertheless, almost of all changes I made are trivial and straightforward
in this direction, and I believe that there is no logic changed since v3
except sdhci_uhs2_irq(), as ops->irq hook, where we must deal with UHS-II
command sequences in addition to UHS-II errors. So I added extra handlings.

I admit that there is plenty of room for improvements (for example,
handling host->flags), but again the focal point here is how sdhci-uhs2.c
should be built as a module.

Please review this series (particularly Patch#8-#26 and #27) from this
viewpoint in the first place.
(Ben is working on 'host' side but there is no change on 'host' side
in this submission except a minor tweak.)

Thanks,
-Takahiro Akashi

------ original cover letter from v3 ------
Summary
=======
These patches[1] support UHS-II and fix GL9755 UHS-II compatibility.

About UHS-II, roughly deal with the following three parts:
1) A UHS-II detection and initialization:
- Host setup to support UHS-II (Section 3.13.1 Host Controller Setup Sequence
  [2]).
- Detect a UHS-II I/F (Section 3.13.2 Card Interface Detection Sequence[2]).
- In step(9) of Section 3.13.2 in [2], UHS-II initialization is include Section
  3.13.3 UHS-II Card Initialization and Section 3.13.4 UHS-II Setting Register
  Setup Sequence.

2) Send Legacy SD command through SD-TRAN
- Encapsulated SD packets are defined in SD-TRAN in order to ensure Legacy SD
  compatibility and preserve Legacy SD infrastructures (Section 7.1.1 Packet
  Types and Format Overview[3]).
- Host issue a UHS-II CCMD packet or a UHS-II DCMD (Section 3.13.5 UHS-II
  CCMD Packet issuing and Section 3.13.6 UHS-II DCMD Packet issuing[2]).

3) UHS-II Interrupt
- Except for UHS-II error interrupts, most interrupts share the original
  interrupt registers.

Patch structure
===============
patch#1-#7: for core
patch#8-#17: for sdhci
patch#18-#21: for GL9755

Tests
=====
Ran 'dd' command to evaluate the performance:
(SanDisk UHS-II card on GL9755 controller)
                             Read    Write
UHS-II disabled (UHS-I): 88.3MB/s 60.7MB/s
UHS-II enabled         :  206MB/s   80MB/s

TODO
====
- replace some define with BIT macro

Reference
=========
[1] https://gitlab.com/ben.chuang/linux-uhs2-gl9755.git
[2] SD Host Controller Simplified Specification 4.20
[3] UHS-II Simplified Addendum 1.02

Changes in v3 (Jul. 10, 2020)
* rebased to v5.8-rc4
* add copyright notice
* reorganize the patch set and split some commits into smaller ones
* separate uhs-2 headers from others
* correct wrong spellings
* fix most of checkpatch warnings/errors
* remove all k[cz]alloc() from the code
* guard sdhci-uhs2 specific code with
      'if (IS_ENABLED(CONFIG_MMC_SDHCI_UHS2))'
* make sdhci-uhs2.c as a module
* trivial changes, including
  - rename back sdhci-core.c to sdhci.c
  - allow vendor code to disable uhs2 if v4_mode == 0
      in __sdhci_add_host()
  - merge uhs2_power_up() into mmc_power_up()
  - remove flag_uhs2 from mmc_attach_sd()
  - add function descriptions to EXPORT'ed functions
  - other minor code optimization

Changes in v2 (Jan. 9, 2020)
* rebased to v5.5-rc5

AKASHI Takahiro (23):
  mmc: core: UHS-II support, modify power-up sequence
  mmc: core: UHS-II support, skip set_chip_select()
  mmc: core: UHS-II support, skip TMODE setup in some cases
  mmc: core: UHS-II support, generate UHS-II SD command packet
  mmc: core: UHS-II support, set APP_CMD bit if necessary
  mmc: sdhci: add a kernel configuration for enabling UHS-II support
  mmc: sdhci: add UHS-II related definitions in headers
  mmc: sdhci: add UHS-II module
  mmc: sdhci-uhs2: dump UHS-II registers
  mmc: sdhci-uhs2: add reset function
  mmc: sdhci-uhs2: add set_power() to support vdd2
  mmc: sdhci-uhs2: skip signal_voltage_switch()
  mmc: sdhci-uhs2: add set_timeout()
  mmc: sdhci-uhs2: add set_ios()
  mmc: sdhci-uhs2: add detect_init() to detect the interface
  mmc: sdhci-uhs2: add clock operations
  mmc: sdhci-uhs2: add set_reg() to initialise the interface
  mmc: sdhci-uhs2: add request() and others
  mmc: sdhci-uhs2: add irq() and others
  mmc: sdhci-uhs2: add add_host() and others to set up the driver
  mmc: core: add post-mmc_attach_sd hook
  mmc: sdhci-pci: add UHS-II support framework
  mmc: sdhci-pci-gli: enable UHS-II mode for GL9755

Ben Chuang (4):
  mmc: add UHS-II related definitions in public headers
  mmc: core: UHS-II support, try to select UHS-II interface
  mmc: sdhci-uhs2: add pre-detect_init hook
  mmc: sdhci-uhs2: add post-mmc_attach_sd hook

 drivers/mmc/core/Makefile         |    2 +-
 drivers/mmc/core/block.c          |    7 +-
 drivers/mmc/core/bus.c            |    5 +-
 drivers/mmc/core/core.c           |  118 +-
 drivers/mmc/core/regulator.c      |   14 +
 drivers/mmc/core/sd.c             |   32 +
 drivers/mmc/core/sd_ops.c         |   12 +
 drivers/mmc/core/uhs2.c           |  883 +++++++++++++++
 drivers/mmc/core/uhs2.h           |   21 +
 drivers/mmc/host/Kconfig          |   10 +
 drivers/mmc/host/Makefile         |    1 +
 drivers/mmc/host/sdhci-pci-core.c |   16 +-
 drivers/mmc/host/sdhci-pci-gli.c  |  318 +++++-
 drivers/mmc/host/sdhci-pci.h      |    3 +
 drivers/mmc/host/sdhci-uhs2.c     | 1697 +++++++++++++++++++++++++++++
 drivers/mmc/host/sdhci-uhs2.h     |  224 ++++
 drivers/mmc/host/sdhci.c          |  333 +++---
 drivers/mmc/host/sdhci.h          |  117 +-
 include/linux/mmc/card.h          |    1 +
 include/linux/mmc/core.h          |    6 +
 include/linux/mmc/host.h          |   31 +
 include/linux/mmc/uhs2.h          |  268 +++++
 22 files changed, 3961 insertions(+), 158 deletions(-)
 create mode 100644 drivers/mmc/core/uhs2.c
 create mode 100644 drivers/mmc/core/uhs2.h
 create mode 100644 drivers/mmc/host/sdhci-uhs2.c
 create mode 100644 drivers/mmc/host/sdhci-uhs2.h
 create mode 100644 include/linux/mmc/uhs2.h

Comments

AKASHI Takahiro Nov. 25, 2020, 7:41 a.m. UTC | #1
Gentle ping;

On Fri, Nov 06, 2020 at 11:26:59AM +0900, AKASHI Takahiro wrote:
> This is an interim snapshot of our next version, v4, for enabling

> UHS-II on MMC/SD.

> 

> It is focused on 'sdhci' side to address Adrian's comments regarding

> "modularising" sdhci-uhs2.c.

> The whole aim of this version is to get early feedback from Adrian (and

> others) on this issue. Without any consensus about the code structure,


Any comments so far?

-Takahiro Akashi

> it would make little sense to go further ahead on sdhci side.

> (Actually, Adrian has made no comments other than "modularising" so far.)

> 

> I heavily reworked/refactored sdhci-uhs2.c and re-organised the patch

> set to meet what I believe Adrian expects; no UHS-II related code in

> Legacy (UHS-I) code or sdhci.c.

> 

> Nevertheless, almost of all changes I made are trivial and straightforward

> in this direction, and I believe that there is no logic changed since v3

> except sdhci_uhs2_irq(), as ops->irq hook, where we must deal with UHS-II

> command sequences in addition to UHS-II errors. So I added extra handlings.

> 

> I admit that there is plenty of room for improvements (for example,

> handling host->flags), but again the focal point here is how sdhci-uhs2.c

> should be built as a module.

> 

> Please review this series (particularly Patch#8-#26 and #27) from this

> viewpoint in the first place.

> (Ben is working on 'host' side but there is no change on 'host' side

> in this submission except a minor tweak.)

> 

> Thanks,

> -Takahiro Akashi

> 

> ------ original cover letter from v3 ------

> Summary

> =======

> These patches[1] support UHS-II and fix GL9755 UHS-II compatibility.

> 

> About UHS-II, roughly deal with the following three parts:

> 1) A UHS-II detection and initialization:

> - Host setup to support UHS-II (Section 3.13.1 Host Controller Setup Sequence

>   [2]).

> - Detect a UHS-II I/F (Section 3.13.2 Card Interface Detection Sequence[2]).

> - In step(9) of Section 3.13.2 in [2], UHS-II initialization is include Section

>   3.13.3 UHS-II Card Initialization and Section 3.13.4 UHS-II Setting Register

>   Setup Sequence.

> 

> 2) Send Legacy SD command through SD-TRAN

> - Encapsulated SD packets are defined in SD-TRAN in order to ensure Legacy SD

>   compatibility and preserve Legacy SD infrastructures (Section 7.1.1 Packet

>   Types and Format Overview[3]).

> - Host issue a UHS-II CCMD packet or a UHS-II DCMD (Section 3.13.5 UHS-II

>   CCMD Packet issuing and Section 3.13.6 UHS-II DCMD Packet issuing[2]).

> 

> 3) UHS-II Interrupt

> - Except for UHS-II error interrupts, most interrupts share the original

>   interrupt registers.

> 

> Patch structure

> ===============

> patch#1-#7: for core

> patch#8-#17: for sdhci

> patch#18-#21: for GL9755

> 

> Tests

> =====

> Ran 'dd' command to evaluate the performance:

> (SanDisk UHS-II card on GL9755 controller)

>                              Read    Write

> UHS-II disabled (UHS-I): 88.3MB/s 60.7MB/s

> UHS-II enabled         :  206MB/s   80MB/s

> 

> TODO

> ====

> - replace some define with BIT macro

> 

> Reference

> =========

> [1] https://gitlab.com/ben.chuang/linux-uhs2-gl9755.git

> [2] SD Host Controller Simplified Specification 4.20

> [3] UHS-II Simplified Addendum 1.02

> 

> Changes in v3 (Jul. 10, 2020)

> * rebased to v5.8-rc4

> * add copyright notice

> * reorganize the patch set and split some commits into smaller ones

> * separate uhs-2 headers from others

> * correct wrong spellings

> * fix most of checkpatch warnings/errors

> * remove all k[cz]alloc() from the code

> * guard sdhci-uhs2 specific code with

>       'if (IS_ENABLED(CONFIG_MMC_SDHCI_UHS2))'

> * make sdhci-uhs2.c as a module

> * trivial changes, including

>   - rename back sdhci-core.c to sdhci.c

>   - allow vendor code to disable uhs2 if v4_mode == 0

>       in __sdhci_add_host()

>   - merge uhs2_power_up() into mmc_power_up()

>   - remove flag_uhs2 from mmc_attach_sd()

>   - add function descriptions to EXPORT'ed functions

>   - other minor code optimization

> 

> Changes in v2 (Jan. 9, 2020)

> * rebased to v5.5-rc5

> 

> AKASHI Takahiro (23):

>   mmc: core: UHS-II support, modify power-up sequence

>   mmc: core: UHS-II support, skip set_chip_select()

>   mmc: core: UHS-II support, skip TMODE setup in some cases

>   mmc: core: UHS-II support, generate UHS-II SD command packet

>   mmc: core: UHS-II support, set APP_CMD bit if necessary

>   mmc: sdhci: add a kernel configuration for enabling UHS-II support

>   mmc: sdhci: add UHS-II related definitions in headers

>   mmc: sdhci: add UHS-II module

>   mmc: sdhci-uhs2: dump UHS-II registers

>   mmc: sdhci-uhs2: add reset function

>   mmc: sdhci-uhs2: add set_power() to support vdd2

>   mmc: sdhci-uhs2: skip signal_voltage_switch()

>   mmc: sdhci-uhs2: add set_timeout()

>   mmc: sdhci-uhs2: add set_ios()

>   mmc: sdhci-uhs2: add detect_init() to detect the interface

>   mmc: sdhci-uhs2: add clock operations

>   mmc: sdhci-uhs2: add set_reg() to initialise the interface

>   mmc: sdhci-uhs2: add request() and others

>   mmc: sdhci-uhs2: add irq() and others

>   mmc: sdhci-uhs2: add add_host() and others to set up the driver

>   mmc: core: add post-mmc_attach_sd hook

>   mmc: sdhci-pci: add UHS-II support framework

>   mmc: sdhci-pci-gli: enable UHS-II mode for GL9755

> 

> Ben Chuang (4):

>   mmc: add UHS-II related definitions in public headers

>   mmc: core: UHS-II support, try to select UHS-II interface

>   mmc: sdhci-uhs2: add pre-detect_init hook

>   mmc: sdhci-uhs2: add post-mmc_attach_sd hook

> 

>  drivers/mmc/core/Makefile         |    2 +-

>  drivers/mmc/core/block.c          |    7 +-

>  drivers/mmc/core/bus.c            |    5 +-

>  drivers/mmc/core/core.c           |  118 +-

>  drivers/mmc/core/regulator.c      |   14 +

>  drivers/mmc/core/sd.c             |   32 +

>  drivers/mmc/core/sd_ops.c         |   12 +

>  drivers/mmc/core/uhs2.c           |  883 +++++++++++++++

>  drivers/mmc/core/uhs2.h           |   21 +

>  drivers/mmc/host/Kconfig          |   10 +

>  drivers/mmc/host/Makefile         |    1 +

>  drivers/mmc/host/sdhci-pci-core.c |   16 +-

>  drivers/mmc/host/sdhci-pci-gli.c  |  318 +++++-

>  drivers/mmc/host/sdhci-pci.h      |    3 +

>  drivers/mmc/host/sdhci-uhs2.c     | 1697 +++++++++++++++++++++++++++++

>  drivers/mmc/host/sdhci-uhs2.h     |  224 ++++

>  drivers/mmc/host/sdhci.c          |  333 +++---

>  drivers/mmc/host/sdhci.h          |  117 +-

>  include/linux/mmc/card.h          |    1 +

>  include/linux/mmc/core.h          |    6 +

>  include/linux/mmc/host.h          |   31 +

>  include/linux/mmc/uhs2.h          |  268 +++++

>  22 files changed, 3961 insertions(+), 158 deletions(-)

>  create mode 100644 drivers/mmc/core/uhs2.c

>  create mode 100644 drivers/mmc/core/uhs2.h

>  create mode 100644 drivers/mmc/host/sdhci-uhs2.c

>  create mode 100644 drivers/mmc/host/sdhci-uhs2.h

>  create mode 100644 include/linux/mmc/uhs2.h

> 

> -- 

> 2.28.0

>
Ulf Hansson Nov. 25, 2020, 10:43 a.m. UTC | #2
On Wed, 25 Nov 2020 at 08:41, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
>

> Gentle ping;

>

> On Fri, Nov 06, 2020 at 11:26:59AM +0900, AKASHI Takahiro wrote:

> > This is an interim snapshot of our next version, v4, for enabling

> > UHS-II on MMC/SD.

> >

> > It is focused on 'sdhci' side to address Adrian's comments regarding

> > "modularising" sdhci-uhs2.c.

> > The whole aim of this version is to get early feedback from Adrian (and

> > others) on this issue. Without any consensus about the code structure,

>

> Any comments so far?


I haven't been able to look at sdhci parts (I will try to), but as you
know, I am relying on Adrian's help with this.

When it comes to the core part, I am planning to help to put some of
the foundation in place for the mmc core changes. Although,
unfortunately I haven't been able to post patches, yet. I will keep
you in the loop, when I get to it.

[...]

Kind regards
Uffe
AKASHI Takahiro Nov. 26, 2020, 12:06 a.m. UTC | #3
On Wed, Nov 25, 2020 at 11:43:18AM +0100, Ulf Hansson wrote:
> On Wed, 25 Nov 2020 at 08:41, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> >
> > Gentle ping;
> >
> > On Fri, Nov 06, 2020 at 11:26:59AM +0900, AKASHI Takahiro wrote:
> > > This is an interim snapshot of our next version, v4, for enabling
> > > UHS-II on MMC/SD.
> > >
> > > It is focused on 'sdhci' side to address Adrian's comments regarding
> > > "modularising" sdhci-uhs2.c.
> > > The whole aim of this version is to get early feedback from Adrian (and
> > > others) on this issue. Without any consensus about the code structure,
> >
> > Any comments so far?
> 
> I haven't been able to look at sdhci parts (I will try to), but as you
> know, I am relying on Adrian's help with this.

Yeah, I understand.

> When it comes to the core part, I am planning to help to put some of
> the foundation in place for the mmc core changes. Although,
> unfortunately I haven't been able to post patches, yet. I will keep
> you in the loop, when I get to it.

I think Ben has some idea on the topic.

-Takahiro Akashi


> [...]
> 
> Kind regards
> Uffe
Adrian Hunter Nov. 26, 2020, 8:18 a.m. UTC | #4
On 25/11/20 9:41 am, AKASHI Takahiro wrote:
> Gentle ping;

> 

> On Fri, Nov 06, 2020 at 11:26:59AM +0900, AKASHI Takahiro wrote:

>> This is an interim snapshot of our next version, v4, for enabling

>> UHS-II on MMC/SD.

>>

>> It is focused on 'sdhci' side to address Adrian's comments regarding

>> "modularising" sdhci-uhs2.c.

>> The whole aim of this version is to get early feedback from Adrian (and

>> others) on this issue. Without any consensus about the code structure,

> 

> Any comments so far?

> 


Overall, I like this approach of separating UHS2 from legacy sdhci as much
as possible.  The only major change, is to drop support for legacy quirks
and features that you do not need.  The reason for that, is that there may
be few drivers that end up with UHS-II support (opting instead for SD
Express), so there is no point going to a lot of trouble to support things
that never get used.

From what I have seen that looks like it includes:
	- any quirks
	- SDHCI LED support
	- external DMA support
In this regard, the important thing is to have a comment somewhere that
lists what is not supported.

I have only looked at SDHCI patches so far, and only up to about patch 20,
but maybe that gives you enough to go on for a while.
AKASHI Takahiro Dec. 1, 2020, 3:09 a.m. UTC | #5
Adrian,

Thank you for your review comments.

On Thu, Nov 26, 2020 at 10:18:55AM +0200, Adrian Hunter wrote:
> On 25/11/20 9:41 am, AKASHI Takahiro wrote:

> > Gentle ping;

> > 

> > On Fri, Nov 06, 2020 at 11:26:59AM +0900, AKASHI Takahiro wrote:

> >> This is an interim snapshot of our next version, v4, for enabling

> >> UHS-II on MMC/SD.

> >>

> >> It is focused on 'sdhci' side to address Adrian's comments regarding

> >> "modularising" sdhci-uhs2.c.

> >> The whole aim of this version is to get early feedback from Adrian (and

> >> others) on this issue. Without any consensus about the code structure,

> > 

> > Any comments so far?

> > 

> 

> Overall, I like this approach of separating UHS2 from legacy sdhci as much

> as possible.  The only major change, is to drop support for legacy quirks

> and features that you do not need.  The reason for that, is that there may

> be few drivers that end up with UHS-II support (opting instead for SD

> Express), so there is no point going to a lot of trouble to support things

> that never get used.

> 

> From what I have seen that looks like it includes:

> 	- any quirks


GLI driver (gl9755) needs
  * SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC
  * SDHCI_QUIRK2_BROKEN_DDR50
but they are managed in sdhci code.

> 	- SDHCI LED support

> 	- external DMA support


Should we add 'depends on !SDHCI_UHS2' to MMC_SDHCI_EXTERNAL_DMA?

> In this regard, the important thing is to have a comment somewhere that

> lists what is not supported.

> 

> I have only looked at SDHCI patches so far, and only up to about patch 20,

> but maybe that gives you enough to go on for a while.


Well, I have almost done.
Can I expect your comments on the patches #21-#27 as well soon?

-Takahiro Akashi
Adrian Hunter Dec. 3, 2020, 9:55 a.m. UTC | #6
On 1/12/20 5:09 am, AKASHI Takahiro wrote:
> Adrian,

> 

> Thank you for your review comments.

> 

> On Thu, Nov 26, 2020 at 10:18:55AM +0200, Adrian Hunter wrote:

>> On 25/11/20 9:41 am, AKASHI Takahiro wrote:

>>> Gentle ping;

>>>

>>> On Fri, Nov 06, 2020 at 11:26:59AM +0900, AKASHI Takahiro wrote:

>>>> This is an interim snapshot of our next version, v4, for enabling

>>>> UHS-II on MMC/SD.

>>>>

>>>> It is focused on 'sdhci' side to address Adrian's comments regarding

>>>> "modularising" sdhci-uhs2.c.

>>>> The whole aim of this version is to get early feedback from Adrian (and

>>>> others) on this issue. Without any consensus about the code structure,

>>>

>>> Any comments so far?

>>>

>>

>> Overall, I like this approach of separating UHS2 from legacy sdhci as much

>> as possible.  The only major change, is to drop support for legacy quirks

>> and features that you do not need.  The reason for that, is that there may

>> be few drivers that end up with UHS-II support (opting instead for SD

>> Express), so there is no point going to a lot of trouble to support things

>> that never get used.

>>

>> From what I have seen that looks like it includes:

>> 	- any quirks

> 

> GLI driver (gl9755) needs

>   * SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC

>   * SDHCI_QUIRK2_BROKEN_DDR50

> but they are managed in sdhci code.

> 

>> 	- SDHCI LED support

>> 	- external DMA support

> 

> Should we add 'depends on !SDHCI_UHS2' to MMC_SDHCI_EXTERNAL_DMA?

> 

>> In this regard, the important thing is to have a comment somewhere that

>> lists what is not supported.

>>

>> I have only looked at SDHCI patches so far, and only up to about patch 20,

>> but maybe that gives you enough to go on for a while.

> 

> Well, I have almost done.

> Can I expect your comments on the patches #21-#27 as well soon?


I have made some more comments and that is all for now, except for anything
more you wish to discuss.
Adrian Hunter Dec. 3, 2020, 10:02 a.m. UTC | #7
On 1/12/20 5:09 am, AKASHI Takahiro wrote:
> Adrian,

> 

> Thank you for your review comments.

> 

> On Thu, Nov 26, 2020 at 10:18:55AM +0200, Adrian Hunter wrote:

>> On 25/11/20 9:41 am, AKASHI Takahiro wrote:

>>> Gentle ping;

>>>

>>> On Fri, Nov 06, 2020 at 11:26:59AM +0900, AKASHI Takahiro wrote:

>>>> This is an interim snapshot of our next version, v4, for enabling

>>>> UHS-II on MMC/SD.

>>>>

>>>> It is focused on 'sdhci' side to address Adrian's comments regarding

>>>> "modularising" sdhci-uhs2.c.

>>>> The whole aim of this version is to get early feedback from Adrian (and

>>>> others) on this issue. Without any consensus about the code structure,

>>>

>>> Any comments so far?

>>>

>>

>> Overall, I like this approach of separating UHS2 from legacy sdhci as much

>> as possible.  The only major change, is to drop support for legacy quirks

>> and features that you do not need.  The reason for that, is that there may

>> be few drivers that end up with UHS-II support (opting instead for SD

>> Express), so there is no point going to a lot of trouble to support things

>> that never get used.

>>

>> From what I have seen that looks like it includes:

>> 	- any quirks

> 

> GLI driver (gl9755) needs

>   * SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC

>   * SDHCI_QUIRK2_BROKEN_DDR50

> but they are managed in sdhci code.

> 

>> 	- SDHCI LED support

>> 	- external DMA support

> 

> Should we add 'depends on !SDHCI_UHS2' to MMC_SDHCI_EXTERNAL_DMA?


No because SDHCI_UHS2 does not necessary mean UHS-II is actually being used
i.e. same kernel can support both even if no controller uses both
AKASHI Takahiro Dec. 8, 2020, 7:58 a.m. UTC | #8
Adrian,

On Thu, Dec 03, 2020 at 11:55:23AM +0200, Adrian Hunter wrote:
> On 1/12/20 5:09 am, AKASHI Takahiro wrote:

> > Adrian,

> > 

> > Thank you for your review comments.

> > 

> > On Thu, Nov 26, 2020 at 10:18:55AM +0200, Adrian Hunter wrote:

> >> On 25/11/20 9:41 am, AKASHI Takahiro wrote:

> >>> Gentle ping;

> >>>

> >>> On Fri, Nov 06, 2020 at 11:26:59AM +0900, AKASHI Takahiro wrote:

> >>>> This is an interim snapshot of our next version, v4, for enabling

> >>>> UHS-II on MMC/SD.

> >>>>

> >>>> It is focused on 'sdhci' side to address Adrian's comments regarding

> >>>> "modularising" sdhci-uhs2.c.

> >>>> The whole aim of this version is to get early feedback from Adrian (and

> >>>> others) on this issue. Without any consensus about the code structure,

> >>>

> >>> Any comments so far?

> >>>

> >>

> >> Overall, I like this approach of separating UHS2 from legacy sdhci as much

> >> as possible.  The only major change, is to drop support for legacy quirks

> >> and features that you do not need.  The reason for that, is that there may

> >> be few drivers that end up with UHS-II support (opting instead for SD

> >> Express), so there is no point going to a lot of trouble to support things

> >> that never get used.

> >>

> >> From what I have seen that looks like it includes:

> >> 	- any quirks

> > 

> > GLI driver (gl9755) needs

> >   * SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC

> >   * SDHCI_QUIRK2_BROKEN_DDR50

> > but they are managed in sdhci code.

> > 

> >> 	- SDHCI LED support

> >> 	- external DMA support

> > 

> > Should we add 'depends on !SDHCI_UHS2' to MMC_SDHCI_EXTERNAL_DMA?

> > 

> >> In this regard, the important thing is to have a comment somewhere that

> >> lists what is not supported.

> >>

> >> I have only looked at SDHCI patches so far, and only up to about patch 20,

> >> but maybe that gives you enough to go on for a while.

> > 

> > Well, I have almost done.

> > Can I expect your comments on the patches #21-#27 as well soon?

> 

> I have made some more comments and that is all for now, except for anything

> more you wish to discuss.


Thank you.
I assume that you don't have any objection against adding extra hooks
to sdhci_ops in patch#23 and #25, do you?

If so, since we don't have any critical issues to discuss,
I hope that my changes will be contained in the new version
where a major rework will be done on the core side by Ben.

-Takahiro Akashi
Adrian Hunter Dec. 8, 2020, 8:48 a.m. UTC | #9
On 8/12/20 9:58 am, AKASHI Takahiro wrote:
> Adrian,

> 

> On Thu, Dec 03, 2020 at 11:55:23AM +0200, Adrian Hunter wrote:

>> On 1/12/20 5:09 am, AKASHI Takahiro wrote:

>>> Adrian,

>>>

>>> Thank you for your review comments.

>>>

>>> On Thu, Nov 26, 2020 at 10:18:55AM +0200, Adrian Hunter wrote:

>>>> On 25/11/20 9:41 am, AKASHI Takahiro wrote:

>>>>> Gentle ping;

>>>>>

>>>>> On Fri, Nov 06, 2020 at 11:26:59AM +0900, AKASHI Takahiro wrote:

>>>>>> This is an interim snapshot of our next version, v4, for enabling

>>>>>> UHS-II on MMC/SD.

>>>>>>

>>>>>> It is focused on 'sdhci' side to address Adrian's comments regarding

>>>>>> "modularising" sdhci-uhs2.c.

>>>>>> The whole aim of this version is to get early feedback from Adrian (and

>>>>>> others) on this issue. Without any consensus about the code structure,

>>>>>

>>>>> Any comments so far?

>>>>>

>>>>

>>>> Overall, I like this approach of separating UHS2 from legacy sdhci as much

>>>> as possible.  The only major change, is to drop support for legacy quirks

>>>> and features that you do not need.  The reason for that, is that there may

>>>> be few drivers that end up with UHS-II support (opting instead for SD

>>>> Express), so there is no point going to a lot of trouble to support things

>>>> that never get used.

>>>>

>>>> From what I have seen that looks like it includes:

>>>> 	- any quirks

>>>

>>> GLI driver (gl9755) needs

>>>   * SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC

>>>   * SDHCI_QUIRK2_BROKEN_DDR50

>>> but they are managed in sdhci code.

>>>

>>>> 	- SDHCI LED support

>>>> 	- external DMA support

>>>

>>> Should we add 'depends on !SDHCI_UHS2' to MMC_SDHCI_EXTERNAL_DMA?

>>>

>>>> In this regard, the important thing is to have a comment somewhere that

>>>> lists what is not supported.

>>>>

>>>> I have only looked at SDHCI patches so far, and only up to about patch 20,

>>>> but maybe that gives you enough to go on for a while.

>>>

>>> Well, I have almost done.

>>> Can I expect your comments on the patches #21-#27 as well soon?

>>

>> I have made some more comments and that is all for now, except for anything

>> more you wish to discuss.

> 

> Thank you.

> I assume that you don't have any objection against adding extra hooks

> to sdhci_ops in patch#23 and #25, do you?


No objections at the moment.

> 

> If so, since we don't have any critical issues to discuss,

> I hope that my changes will be contained in the new version

> where a major rework will be done on the core side by Ben.


Ok