Message ID | 20201106022726.19831-1-takahiro.akashi@linaro.org |
---|---|
Headers | show |
Series | Add support UHS-II for GL9755 | expand |
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 >
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
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
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.
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
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.
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
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
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