| Message ID | 20171207224322.20362-1-ard.biesheuvel@linaro.org |
|---|---|
| Headers | show |
| Series | quirks handling for SDHCI controllers | expand |
On 7 December 2017 at 22:43, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > Many SDHCI implementations exist that are almost spec complicant, and > could be driven by the generic SD/MMC host controller driver except > for some minimal necessary init time tweaks. > > Adding such tweaks to the generic driver is undesirable. On the other > hand, forking the driver for every platform that has such a SDHCI > controller is problematic when it comes to upstreaming and ongoing > maintenance (which is arguably the point of upstreaming in the first > place). > > So these patches propose a workaround that is minimally invasive on the > EDK2 side, but gives platforms a lot of leeway when it comes to applying > SDHCI quirks. > > Changes since v3: > - remove PassThru argument from protocol members: it is unclear whether the > protocol is available when the override protocol is invoked, and my > example use case does not need it > - replace incorrect HandleProtocol with LocateProtocol, given that the override > protocol is now a singleton instance > - merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this > required changing the prototype to take a SD_MMC_HC_PRIVATE_DATA* argument > and so the prototypes no longer belong in SdMmcPciHci.h and have been moved > to SdMmcPciHcDxe.h > - use VOID* type for capability not UINT64* since we don't know its alignment > > Changes since v2: > - use a singleton instance of the SD/MMC protocol rather than one per > controller; this is needed to support 'reconnect -r', as pointed out > by Ray > - use EDKII prefixes for all types defined by the protocol > - replace 'hook' with 'notify', and tweak some other identifiers > - add missing function comment headers for factored out functions > > Changes since RFC/v1: > - add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override methods > - use UINT64* not VOID* to pass capability structure (which is always 64 bits > in size) > > Ard Biesheuvel (2): > MdeModulePkg: introduce SD/MMC override protocol > MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden > OK, so I did send my v4 but I couldn't find it in my mail folders :-) Comments anyone? _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Hi Ard, > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard > Biesheuvel > Sent: Tuesday, December 12, 2017 3:00 PM > To: edk2-devel@lists.01.org > Cc: Ni, Ruiyu; Tian, Feng; Ard Biesheuvel; Wu, Hao A; Leif Lindholm; Kinney, > Michael D; Zeng, Star > Subject: Re: [edk2] [PATCH v4 0/2] quirks handling for SDHCI controllers > > On 7 December 2017 at 22:43, Ard Biesheuvel <ard.biesheuvel@linaro.org> > wrote: > > Many SDHCI implementations exist that are almost spec complicant, and > > could be driven by the generic SD/MMC host controller driver except > > for some minimal necessary init time tweaks. > > > > Adding such tweaks to the generic driver is undesirable. On the other > > hand, forking the driver for every platform that has such a SDHCI > > controller is problematic when it comes to upstreaming and ongoing > > maintenance (which is arguably the point of upstreaming in the first > > place). > > > > So these patches propose a workaround that is minimally invasive on the > > EDK2 side, but gives platforms a lot of leeway when it comes to applying > > SDHCI quirks. > > > > Changes since v3: > > - remove PassThru argument from protocol members: it is unclear whether the > > protocol is available when the override protocol is invoked, and my > > example use case does not need it > > - replace incorrect HandleProtocol with LocateProtocol, given that the > override > > protocol is now a singleton instance > > - merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this > > required changing the prototype to take a SD_MMC_HC_PRIVATE_DATA* > argument > > and so the prototypes no longer belong in SdMmcPciHci.h and have been > moved > > to SdMmcPciHcDxe.h > > - use VOID* type for capability not UINT64* since we don't know its > alignment > > > > Changes since v2: > > - use a singleton instance of the SD/MMC protocol rather than one per > > controller; this is needed to support 'reconnect -r', as pointed out > > by Ray > > - use EDKII prefixes for all types defined by the protocol > > - replace 'hook' with 'notify', and tweak some other identifiers > > - add missing function comment headers for factored out functions > > > > Changes since RFC/v1: > > - add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override methods > > - use UINT64* not VOID* to pass capability structure (which is always 64 bits > > in size) > > > > Ard Biesheuvel (2): > > MdeModulePkg: introduce SD/MMC override protocol > > MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden > > > > OK, so I did send my v4 but I couldn't find it in my mail folders :-) > > Comments anyone? I still need some time to evaluate whether the current proposed override protocol can be utilized in our using scenario. Will let you know the feedbacks as soon as I finish the evaluation. Really sorry for the delay. Best Regards, Hao Wu > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 12 December 2017 at 10:56, Wu, Hao A <hao.a.wu@intel.com> wrote: > Hi Ard, > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard >> Biesheuvel >> Sent: Tuesday, December 12, 2017 3:00 PM >> To: edk2-devel@lists.01.org >> Cc: Ni, Ruiyu; Tian, Feng; Ard Biesheuvel; Wu, Hao A; Leif Lindholm; Kinney, >> Michael D; Zeng, Star >> Subject: Re: [edk2] [PATCH v4 0/2] quirks handling for SDHCI controllers >> >> On 7 December 2017 at 22:43, Ard Biesheuvel <ard.biesheuvel@linaro.org> >> wrote: >> > Many SDHCI implementations exist that are almost spec complicant, and >> > could be driven by the generic SD/MMC host controller driver except >> > for some minimal necessary init time tweaks. >> > >> > Adding such tweaks to the generic driver is undesirable. On the other >> > hand, forking the driver for every platform that has such a SDHCI >> > controller is problematic when it comes to upstreaming and ongoing >> > maintenance (which is arguably the point of upstreaming in the first >> > place). >> > >> > So these patches propose a workaround that is minimally invasive on the >> > EDK2 side, but gives platforms a lot of leeway when it comes to applying >> > SDHCI quirks. >> > >> > Changes since v3: >> > - remove PassThru argument from protocol members: it is unclear whether the >> > protocol is available when the override protocol is invoked, and my >> > example use case does not need it >> > - replace incorrect HandleProtocol with LocateProtocol, given that the >> override >> > protocol is now a singleton instance >> > - merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this >> > required changing the prototype to take a SD_MMC_HC_PRIVATE_DATA* >> argument >> > and so the prototypes no longer belong in SdMmcPciHci.h and have been >> moved >> > to SdMmcPciHcDxe.h >> > - use VOID* type for capability not UINT64* since we don't know its >> alignment >> > >> > Changes since v2: >> > - use a singleton instance of the SD/MMC protocol rather than one per >> > controller; this is needed to support 'reconnect -r', as pointed out >> > by Ray >> > - use EDKII prefixes for all types defined by the protocol >> > - replace 'hook' with 'notify', and tweak some other identifiers >> > - add missing function comment headers for factored out functions >> > >> > Changes since RFC/v1: >> > - add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override methods >> > - use UINT64* not VOID* to pass capability structure (which is always 64 bits >> > in size) >> > >> > Ard Biesheuvel (2): >> > MdeModulePkg: introduce SD/MMC override protocol >> > MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden >> > >> >> OK, so I did send my v4 but I couldn't find it in my mail folders :-) >> >> Comments anyone? > > I still need some time to evaluate whether the current proposed override > protocol can be utilized in our using scenario. > > Will let you know the feedbacks as soon as I finish the evaluation. > > Really sorry for the delay. > No problem at all. Just keep me informed. Thanks, Ard. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 12 December 2017 at 10:56, Wu, Hao A <hao.a.wu@intel.com> wrote: > Hi Ard, > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard >> Biesheuvel >> Sent: Tuesday, December 12, 2017 3:00 PM >> To: edk2-devel@lists.01.org >> Cc: Ni, Ruiyu; Tian, Feng; Ard Biesheuvel; Wu, Hao A; Leif Lindholm; Kinney, >> Michael D; Zeng, Star >> Subject: Re: [edk2] [PATCH v4 0/2] quirks handling for SDHCI controllers >> >> On 7 December 2017 at 22:43, Ard Biesheuvel <ard.biesheuvel@linaro.org> >> wrote: >> > Many SDHCI implementations exist that are almost spec complicant, and >> > could be driven by the generic SD/MMC host controller driver except >> > for some minimal necessary init time tweaks. >> > >> > Adding such tweaks to the generic driver is undesirable. On the other >> > hand, forking the driver for every platform that has such a SDHCI >> > controller is problematic when it comes to upstreaming and ongoing >> > maintenance (which is arguably the point of upstreaming in the first >> > place). >> > >> > So these patches propose a workaround that is minimally invasive on the >> > EDK2 side, but gives platforms a lot of leeway when it comes to applying >> > SDHCI quirks. >> > >> > Changes since v3: >> > - remove PassThru argument from protocol members: it is unclear whether the >> > protocol is available when the override protocol is invoked, and my >> > example use case does not need it >> > - replace incorrect HandleProtocol with LocateProtocol, given that the >> override >> > protocol is now a singleton instance >> > - merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this >> > required changing the prototype to take a SD_MMC_HC_PRIVATE_DATA* >> argument >> > and so the prototypes no longer belong in SdMmcPciHci.h and have been >> moved >> > to SdMmcPciHcDxe.h >> > - use VOID* type for capability not UINT64* since we don't know its >> alignment >> > >> > Changes since v2: >> > - use a singleton instance of the SD/MMC protocol rather than one per >> > controller; this is needed to support 'reconnect -r', as pointed out >> > by Ray >> > - use EDKII prefixes for all types defined by the protocol >> > - replace 'hook' with 'notify', and tweak some other identifiers >> > - add missing function comment headers for factored out functions >> > >> > Changes since RFC/v1: >> > - add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override methods >> > - use UINT64* not VOID* to pass capability structure (which is always 64 bits >> > in size) >> > >> > Ard Biesheuvel (2): >> > MdeModulePkg: introduce SD/MMC override protocol >> > MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden >> > >> >> OK, so I did send my v4 but I couldn't find it in my mail folders :-) >> >> Comments anyone? > > I still need some time to evaluate whether the current proposed override > protocol can be utilized in our using scenario. > > Will let you know the feedbacks as soon as I finish the evaluation. > > Really sorry for the delay. > Any news on this? _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
One minor comment, please help to remove the line (around line 1067): @param[in] Capability The capability of the slot. within function description comment for SdMmcHcInitHost() in file: MdeModulePkg\Bus\Pci\SdMmcPciHcDxe\SdMmcPciHci.c Other than that, the series is good to me: Reviewed-by: Hao Wu <hao.a.wu@intel.com> Really sorry for the delay. Best Regards, Hao Wu > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Friday, December 08, 2017 6:43 AM > To: edk2-devel@lists.01.org > Cc: leif.lindholm@linaro.org; Kinney, Michael D; Zeng, Star; Tian, Feng; Ni, > Ruiyu; Wu, Hao A; Ard Biesheuvel > Subject: [PATCH v4 0/2] quirks handling for SDHCI controllers > > Many SDHCI implementations exist that are almost spec complicant, and > could be driven by the generic SD/MMC host controller driver except > for some minimal necessary init time tweaks. > > Adding such tweaks to the generic driver is undesirable. On the other > hand, forking the driver for every platform that has such a SDHCI > controller is problematic when it comes to upstreaming and ongoing > maintenance (which is arguably the point of upstreaming in the first > place). > > So these patches propose a workaround that is minimally invasive on the > EDK2 side, but gives platforms a lot of leeway when it comes to applying > SDHCI quirks. > > Changes since v3: > - remove PassThru argument from protocol members: it is unclear whether the > protocol is available when the override protocol is invoked, and my > example use case does not need it > - replace incorrect HandleProtocol with LocateProtocol, given that the override > protocol is now a singleton instance > - merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this > required changing the prototype to take a SD_MMC_HC_PRIVATE_DATA* > argument > and so the prototypes no longer belong in SdMmcPciHci.h and have been > moved > to SdMmcPciHcDxe.h > - use VOID* type for capability not UINT64* since we don't know its alignment > > Changes since v2: > - use a singleton instance of the SD/MMC protocol rather than one per > controller; this is needed to support 'reconnect -r', as pointed out > by Ray > - use EDKII prefixes for all types defined by the protocol > - replace 'hook' with 'notify', and tweak some other identifiers > - add missing function comment headers for factored out functions > > Changes since RFC/v1: > - add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override methods > - use UINT64* not VOID* to pass capability structure (which is always 64 bits > in size) > > Ard Biesheuvel (2): > MdeModulePkg: introduce SD/MMC override protocol > MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 35 ++++++- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 36 ++++++++ > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf | 2 + > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 95 > +++++++++++++++++-- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 35 ------- > MdeModulePkg/Include/Protocol/SdMmcOverride.h | 97 > ++++++++++++++++++++ > MdeModulePkg/MdeModulePkg.dec | 3 + > 7 files changed, 257 insertions(+), 46 deletions(-) > create mode 100644 MdeModulePkg/Include/Protocol/SdMmcOverride.h > > -- > 2.11.0 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 29 January 2018 at 05:13, Wu, Hao A <hao.a.wu@intel.com> wrote: > One minor comment, please help to remove the line (around line 1067): > @param[in] Capability The capability of the slot. > > within function description comment for SdMmcHcInitHost() in file: > MdeModulePkg\Bus\Pci\SdMmcPciHcDxe\SdMmcPciHci.c > > Other than that, the series is good to me: > Reviewed-by: Hao Wu <hao.a.wu@intel.com> > Thank you very much! > Really sorry for the delay. > No worries. Star, Ray, any more comments from your side? > >> -----Original Message----- >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >> Sent: Friday, December 08, 2017 6:43 AM >> To: edk2-devel@lists.01.org >> Cc: leif.lindholm@linaro.org; Kinney, Michael D; Zeng, Star; Tian, Feng; Ni, >> Ruiyu; Wu, Hao A; Ard Biesheuvel >> Subject: [PATCH v4 0/2] quirks handling for SDHCI controllers >> >> Many SDHCI implementations exist that are almost spec complicant, and >> could be driven by the generic SD/MMC host controller driver except >> for some minimal necessary init time tweaks. >> >> Adding such tweaks to the generic driver is undesirable. On the other >> hand, forking the driver for every platform that has such a SDHCI >> controller is problematic when it comes to upstreaming and ongoing >> maintenance (which is arguably the point of upstreaming in the first >> place). >> >> So these patches propose a workaround that is minimally invasive on the >> EDK2 side, but gives platforms a lot of leeway when it comes to applying >> SDHCI quirks. >> >> Changes since v3: >> - remove PassThru argument from protocol members: it is unclear whether the >> protocol is available when the override protocol is invoked, and my >> example use case does not need it >> - replace incorrect HandleProtocol with LocateProtocol, given that the override >> protocol is now a singleton instance >> - merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this >> required changing the prototype to take a SD_MMC_HC_PRIVATE_DATA* >> argument >> and so the prototypes no longer belong in SdMmcPciHci.h and have been >> moved >> to SdMmcPciHcDxe.h >> - use VOID* type for capability not UINT64* since we don't know its alignment >> >> Changes since v2: >> - use a singleton instance of the SD/MMC protocol rather than one per >> controller; this is needed to support 'reconnect -r', as pointed out >> by Ray >> - use EDKII prefixes for all types defined by the protocol >> - replace 'hook' with 'notify', and tweak some other identifiers >> - add missing function comment headers for factored out functions >> >> Changes since RFC/v1: >> - add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override methods >> - use UINT64* not VOID* to pass capability structure (which is always 64 bits >> in size) >> >> Ard Biesheuvel (2): >> MdeModulePkg: introduce SD/MMC override protocol >> MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden >> >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 35 ++++++- >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 36 ++++++++ >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf | 2 + >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 95 >> +++++++++++++++++-- >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 35 ------- >> MdeModulePkg/Include/Protocol/SdMmcOverride.h | 97 >> ++++++++++++++++++++ >> MdeModulePkg/MdeModulePkg.dec | 3 + >> 7 files changed, 257 insertions(+), 46 deletions(-) >> create mode 100644 MdeModulePkg/Include/Protocol/SdMmcOverride.h >> >> -- >> 2.11.0 > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Reviewed-by: Star Zeng <star.zeng@intel.com> Thanks Hao's investigation and Ard's contribution. Star -----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Monday, January 29, 2018 4:26 PM To: Wu, Hao A <hao.a.wu@intel.com>; Zeng, Star <star.zeng@intel.com>; Ni, Ruiyu <ruiyu.ni@intel.com> Cc: edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney, Michael D <michael.d.kinney@intel.com>; Tian, Feng <feng.tian@intel.com> Subject: Re: [PATCH v4 0/2] quirks handling for SDHCI controllers On 29 January 2018 at 05:13, Wu, Hao A <hao.a.wu@intel.com> wrote: > One minor comment, please help to remove the line (around line 1067): > @param[in] Capability The capability of the slot. > > within function description comment for SdMmcHcInitHost() in file: > MdeModulePkg\Bus\Pci\SdMmcPciHcDxe\SdMmcPciHci.c > > Other than that, the series is good to me: > Reviewed-by: Hao Wu <hao.a.wu@intel.com> > Thank you very much! > Really sorry for the delay. > No worries. Star, Ray, any more comments from your side? > >> -----Original Message----- >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >> Sent: Friday, December 08, 2017 6:43 AM >> To: edk2-devel@lists.01.org >> Cc: leif.lindholm@linaro.org; Kinney, Michael D; Zeng, Star; Tian, >> Feng; Ni, Ruiyu; Wu, Hao A; Ard Biesheuvel >> Subject: [PATCH v4 0/2] quirks handling for SDHCI controllers >> >> Many SDHCI implementations exist that are almost spec complicant, and >> could be driven by the generic SD/MMC host controller driver except >> for some minimal necessary init time tweaks. >> >> Adding such tweaks to the generic driver is undesirable. On the other >> hand, forking the driver for every platform that has such a SDHCI >> controller is problematic when it comes to upstreaming and ongoing >> maintenance (which is arguably the point of upstreaming in the first >> place). >> >> So these patches propose a workaround that is minimally invasive on >> the >> EDK2 side, but gives platforms a lot of leeway when it comes to >> applying SDHCI quirks. >> >> Changes since v3: >> - remove PassThru argument from protocol members: it is unclear whether the >> protocol is available when the override protocol is invoked, and my >> example use case does not need it >> - replace incorrect HandleProtocol with LocateProtocol, given that the override >> protocol is now a singleton instance >> - merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this >> required changing the prototype to take a SD_MMC_HC_PRIVATE_DATA* >> argument >> and so the prototypes no longer belong in SdMmcPciHci.h and have >> been moved >> to SdMmcPciHcDxe.h >> - use VOID* type for capability not UINT64* since we don't know its >> alignment >> >> Changes since v2: >> - use a singleton instance of the SD/MMC protocol rather than one per >> controller; this is needed to support 'reconnect -r', as pointed out >> by Ray >> - use EDKII prefixes for all types defined by the protocol >> - replace 'hook' with 'notify', and tweak some other identifiers >> - add missing function comment headers for factored out functions >> >> Changes since RFC/v1: >> - add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override methods >> - use UINT64* not VOID* to pass capability structure (which is always 64 bits >> in size) >> >> Ard Biesheuvel (2): >> MdeModulePkg: introduce SD/MMC override protocol >> MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden >> >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 35 ++++++- >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 36 ++++++++ >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf | 2 + >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 95 >> +++++++++++++++++-- >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 35 ------- >> MdeModulePkg/Include/Protocol/SdMmcOverride.h | 97 >> ++++++++++++++++++++ >> MdeModulePkg/MdeModulePkg.dec | 3 + >> 7 files changed, 257 insertions(+), 46 deletions(-) create mode >> 100644 MdeModulePkg/Include/Protocol/SdMmcOverride.h >> >> -- >> 2.11.0 > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Ard, No more comments from my side. Thanks/Ray > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Monday, January 29, 2018 4:26 PM > To: Wu, Hao A <hao.a.wu@intel.com>; Zeng, Star <star.zeng@intel.com>; Ni, > Ruiyu <ruiyu.ni@intel.com> > Cc: edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney, Michael D > <michael.d.kinney@intel.com>; Tian, Feng <feng.tian@intel.com> > Subject: Re: [PATCH v4 0/2] quirks handling for SDHCI controllers > > On 29 January 2018 at 05:13, Wu, Hao A <hao.a.wu@intel.com> wrote: > > One minor comment, please help to remove the line (around line 1067): > > @param[in] Capability The capability of the slot. > > > > within function description comment for SdMmcHcInitHost() in file: > > MdeModulePkg\Bus\Pci\SdMmcPciHcDxe\SdMmcPciHci.c > > > > Other than that, the series is good to me: > > Reviewed-by: Hao Wu <hao.a.wu@intel.com> > > > > Thank you very much! > > > Really sorry for the delay. > > > > No worries. Star, Ray, any more comments from your side? > > > > > >> -----Original Message----- > >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > >> Sent: Friday, December 08, 2017 6:43 AM > >> To: edk2-devel@lists.01.org > >> Cc: leif.lindholm@linaro.org; Kinney, Michael D; Zeng, Star; Tian, > >> Feng; Ni, Ruiyu; Wu, Hao A; Ard Biesheuvel > >> Subject: [PATCH v4 0/2] quirks handling for SDHCI controllers > >> > >> Many SDHCI implementations exist that are almost spec complicant, and > >> could be driven by the generic SD/MMC host controller driver except > >> for some minimal necessary init time tweaks. > >> > >> Adding such tweaks to the generic driver is undesirable. On the other > >> hand, forking the driver for every platform that has such a SDHCI > >> controller is problematic when it comes to upstreaming and ongoing > >> maintenance (which is arguably the point of upstreaming in the first > >> place). > >> > >> So these patches propose a workaround that is minimally invasive on > >> the > >> EDK2 side, but gives platforms a lot of leeway when it comes to > >> applying SDHCI quirks. > >> > >> Changes since v3: > >> - remove PassThru argument from protocol members: it is unclear whether > the > >> protocol is available when the override protocol is invoked, and my > >> example use case does not need it > >> - replace incorrect HandleProtocol with LocateProtocol, given that the > override > >> protocol is now a singleton instance > >> - merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this > >> required changing the prototype to take a SD_MMC_HC_PRIVATE_DATA* > >> argument > >> and so the prototypes no longer belong in SdMmcPciHci.h and have > >> been moved > >> to SdMmcPciHcDxe.h > >> - use VOID* type for capability not UINT64* since we don't know its > >> alignment > >> > >> Changes since v2: > >> - use a singleton instance of the SD/MMC protocol rather than one per > >> controller; this is needed to support 'reconnect -r', as pointed out > >> by Ray > >> - use EDKII prefixes for all types defined by the protocol > >> - replace 'hook' with 'notify', and tweak some other identifiers > >> - add missing function comment headers for factored out functions > >> > >> Changes since RFC/v1: > >> - add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override methods > >> - use UINT64* not VOID* to pass capability structure (which is always 64 bits > >> in size) > >> > >> Ard Biesheuvel (2): > >> MdeModulePkg: introduce SD/MMC override protocol > >> MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden > >> > >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 35 ++++++- > >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 36 > ++++++++ > >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf | 2 + > >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 95 > >> +++++++++++++++++-- > >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 35 ------- > >> MdeModulePkg/Include/Protocol/SdMmcOverride.h | 97 > >> ++++++++++++++++++++ > >> MdeModulePkg/MdeModulePkg.dec | 3 + > >> 7 files changed, 257 insertions(+), 46 deletions(-) create mode > >> 100644 MdeModulePkg/Include/Protocol/SdMmcOverride.h > >> > >> -- > >> 2.11.0 > > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 30 January 2018 at 01:24, Zeng, Star <star.zeng@intel.com> wrote: > Reviewed-by: Star Zeng <star.zeng@intel.com> > > Thanks Hao's investigation and Ard's contribution. > Thanks all Pushed as 864701886fc3..b23fc39cd3c3 > > Star > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Monday, January 29, 2018 4:26 PM > To: Wu, Hao A <hao.a.wu@intel.com>; Zeng, Star <star.zeng@intel.com>; Ni, Ruiyu <ruiyu.ni@intel.com> > Cc: edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney, Michael D <michael.d.kinney@intel.com>; Tian, Feng <feng.tian@intel.com> > Subject: Re: [PATCH v4 0/2] quirks handling for SDHCI controllers > > On 29 January 2018 at 05:13, Wu, Hao A <hao.a.wu@intel.com> wrote: >> One minor comment, please help to remove the line (around line 1067): >> @param[in] Capability The capability of the slot. >> >> within function description comment for SdMmcHcInitHost() in file: >> MdeModulePkg\Bus\Pci\SdMmcPciHcDxe\SdMmcPciHci.c >> >> Other than that, the series is good to me: >> Reviewed-by: Hao Wu <hao.a.wu@intel.com> >> > > Thank you very much! > >> Really sorry for the delay. >> > > No worries. Star, Ray, any more comments from your side? > > >> >>> -----Original Message----- >>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >>> Sent: Friday, December 08, 2017 6:43 AM >>> To: edk2-devel@lists.01.org >>> Cc: leif.lindholm@linaro.org; Kinney, Michael D; Zeng, Star; Tian, >>> Feng; Ni, Ruiyu; Wu, Hao A; Ard Biesheuvel >>> Subject: [PATCH v4 0/2] quirks handling for SDHCI controllers >>> >>> Many SDHCI implementations exist that are almost spec complicant, and >>> could be driven by the generic SD/MMC host controller driver except >>> for some minimal necessary init time tweaks. >>> >>> Adding such tweaks to the generic driver is undesirable. On the other >>> hand, forking the driver for every platform that has such a SDHCI >>> controller is problematic when it comes to upstreaming and ongoing >>> maintenance (which is arguably the point of upstreaming in the first >>> place). >>> >>> So these patches propose a workaround that is minimally invasive on >>> the >>> EDK2 side, but gives platforms a lot of leeway when it comes to >>> applying SDHCI quirks. >>> >>> Changes since v3: >>> - remove PassThru argument from protocol members: it is unclear whether the >>> protocol is available when the override protocol is invoked, and my >>> example use case does not need it >>> - replace incorrect HandleProtocol with LocateProtocol, given that the override >>> protocol is now a singleton instance >>> - merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this >>> required changing the prototype to take a SD_MMC_HC_PRIVATE_DATA* >>> argument >>> and so the prototypes no longer belong in SdMmcPciHci.h and have >>> been moved >>> to SdMmcPciHcDxe.h >>> - use VOID* type for capability not UINT64* since we don't know its >>> alignment >>> >>> Changes since v2: >>> - use a singleton instance of the SD/MMC protocol rather than one per >>> controller; this is needed to support 'reconnect -r', as pointed out >>> by Ray >>> - use EDKII prefixes for all types defined by the protocol >>> - replace 'hook' with 'notify', and tweak some other identifiers >>> - add missing function comment headers for factored out functions >>> >>> Changes since RFC/v1: >>> - add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override methods >>> - use UINT64* not VOID* to pass capability structure (which is always 64 bits >>> in size) >>> >>> Ard Biesheuvel (2): >>> MdeModulePkg: introduce SD/MMC override protocol >>> MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden >>> >>> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 35 ++++++- >>> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 36 ++++++++ >>> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf | 2 + >>> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 95 >>> +++++++++++++++++-- >>> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 35 ------- >>> MdeModulePkg/Include/Protocol/SdMmcOverride.h | 97 >>> ++++++++++++++++++++ >>> MdeModulePkg/MdeModulePkg.dec | 3 + >>> 7 files changed, 257 insertions(+), 46 deletions(-) create mode >>> 100644 MdeModulePkg/Include/Protocol/SdMmcOverride.h >>> >>> -- >>> 2.11.0 >> _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Hi, I am using Mmc Driver implemented in " EmbeddedPkg/Universal/MmcDxe/" for my SD/MMC controller and my controller is not on PCI bus. I am a bit confused if i should move to SD implementation available in 'MdeModulePkg\Bus\Pci\SdMmcPciHcDxe". Please suggest. Thanks, Meenakshi > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > Ard Biesheuvel > Sent: Tuesday, January 30, 2018 3:22 PM > To: Zeng, Star <star.zeng@intel.com> > Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Tian, Feng <feng.tian@intel.com>; Wu, > Hao A <hao.a.wu@intel.com>; edk2-devel@lists.01.org; > leif.lindholm@linaro.org; Kinney, Michael D <michael.d.kinney@intel.com> > Subject: Re: [edk2] [PATCH v4 0/2] quirks handling for SDHCI controllers > > On 30 January 2018 at 01:24, Zeng, Star <star.zeng@intel.com> wrote: > > Reviewed-by: Star Zeng <star.zeng@intel.com> > > > > Thanks Hao's investigation and Ard's contribution. > > > > Thanks all > > Pushed as 864701886fc3..b23fc39cd3c3 > > > > > Star > > -----Original Message----- > > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > > Sent: Monday, January 29, 2018 4:26 PM > > To: Wu, Hao A <hao.a.wu@intel.com>; Zeng, Star <star.zeng@intel.com>; > Ni, Ruiyu <ruiyu.ni@intel.com> > > Cc: edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney, Michael D > <michael.d.kinney@intel.com>; Tian, Feng <feng.tian@intel.com> > > Subject: Re: [PATCH v4 0/2] quirks handling for SDHCI controllers > > > > On 29 January 2018 at 05:13, Wu, Hao A <hao.a.wu@intel.com> wrote: > >> One minor comment, please help to remove the line (around line 1067): > >> @param[in] Capability The capability of the slot. > >> > >> within function description comment for SdMmcHcInitHost() in file: > >> MdeModulePkg\Bus\Pci\SdMmcPciHcDxe\SdMmcPciHci.c > >> > >> Other than that, the series is good to me: > >> Reviewed-by: Hao Wu <hao.a.wu@intel.com> > >> > > > > Thank you very much! > > > >> Really sorry for the delay. > >> > > > > No worries. Star, Ray, any more comments from your side? > > > > > >> > >>> -----Original Message----- > >>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > >>> Sent: Friday, December 08, 2017 6:43 AM > >>> To: edk2-devel@lists.01.org > >>> Cc: leif.lindholm@linaro.org; Kinney, Michael D; Zeng, Star; Tian, > >>> Feng; Ni, Ruiyu; Wu, Hao A; Ard Biesheuvel > >>> Subject: [PATCH v4 0/2] quirks handling for SDHCI controllers > >>> > >>> Many SDHCI implementations exist that are almost spec complicant, and > >>> could be driven by the generic SD/MMC host controller driver except > >>> for some minimal necessary init time tweaks. > >>> > >>> Adding such tweaks to the generic driver is undesirable. On the other > >>> hand, forking the driver for every platform that has such a SDHCI > >>> controller is problematic when it comes to upstreaming and ongoing > >>> maintenance (which is arguably the point of upstreaming in the first > >>> place). > >>> > >>> So these patches propose a workaround that is minimally invasive on > >>> the > >>> EDK2 side, but gives platforms a lot of leeway when it comes to > >>> applying SDHCI quirks. > >>> > >>> Changes since v3: > >>> - remove PassThru argument from protocol members: it is unclear > whether the > >>> protocol is available when the override protocol is invoked, and my > >>> example use case does not need it > >>> - replace incorrect HandleProtocol with LocateProtocol, given that the > override > >>> protocol is now a singleton instance > >>> - merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this > >>> required changing the prototype to take a > SD_MMC_HC_PRIVATE_DATA* > >>> argument > >>> and so the prototypes no longer belong in SdMmcPciHci.h and have > >>> been moved > >>> to SdMmcPciHcDxe.h > >>> - use VOID* type for capability not UINT64* since we don't know its > >>> alignment > >>> > >>> Changes since v2: > >>> - use a singleton instance of the SD/MMC protocol rather than one per > >>> controller; this is needed to support 'reconnect -r', as pointed out > >>> by Ray > >>> - use EDKII prefixes for all types defined by the protocol > >>> - replace 'hook' with 'notify', and tweak some other identifiers > >>> - add missing function comment headers for factored out functions > >>> > >>> Changes since RFC/v1: > >>> - add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override > methods > >>> - use UINT64* not VOID* to pass capability structure (which is always 64 > bits > >>> in size) > >>> > >>> Ard Biesheuvel (2): > >>> MdeModulePkg: introduce SD/MMC override protocol > >>> MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be > overridden > >>> > >>> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 35 > ++++++- > >>> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 36 > ++++++++ > >>> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf | 2 + > >>> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 95 > >>> +++++++++++++++++-- > >>> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 35 ------- > >>> MdeModulePkg/Include/Protocol/SdMmcOverride.h | 97 > >>> ++++++++++++++++++++ > >>> MdeModulePkg/MdeModulePkg.dec | 3 + > >>> 7 files changed, 257 insertions(+), 46 deletions(-) create mode > >>> 100644 MdeModulePkg/Include/Protocol/SdMmcOverride.h > >>> > >>> -- > >>> 2.11.0 > >> > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.01.org%2Fmailman%2Flistinfo%2Fedk2- > devel&data=02%7C01%7Cmeenakshi.aggarwal%40nxp.com%7Ce1c1a5872a7 > 1476d17fc08d567c7280c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0% > 7C636529027474388370&sdata=gkmLosBokCxUJsWSPlvmsUABakEYdbIZTOho > qFsbbpI%3D&reserved=0 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 6 March 2018 at 05:14, Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com> wrote: > Hi, > > I am using Mmc Driver implemented in " EmbeddedPkg/Universal/MmcDxe/" for my SD/MMC controller and my controller is not on PCI bus. > > I am a bit confused if i should move to SD implementation available in 'MdeModulePkg\Bus\Pci\SdMmcPciHcDxe". > > Please suggest. > It really depends on whether the IP is SDHCI compatible or not. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Tuesday, March 06, 2018 4:41 PM > To: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com> > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH v4 0/2] quirks handling for SDHCI controllers > > On 6 March 2018 at 05:14, Meenakshi Aggarwal > <meenakshi.aggarwal@nxp.com> wrote: > > Hi, > > > > I am using Mmc Driver implemented in " > EmbeddedPkg/Universal/MmcDxe/" for my SD/MMC controller and my > controller is not on PCI bus. > > > > I am a bit confused if i should move to SD implementation available in > 'MdeModulePkg\Bus\Pci\SdMmcPciHcDxe". > > > > Please suggest. > > > > It really depends on whether the IP is SDHCI compatible or not. Thanks for reply Ard, its not SDHCI compatible, so i guess no additional advantage in moving to 'MdeModulePkg\Bus\Pci\SdMmcPciHcDxe' for my IP. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel