public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Wu, Hao A" <hao.a.wu@intel.com>
To: Marcin Wojtas <mw@semihalf.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>,
	"Gao, Liming" <liming.gao@intel.com>,
	"Leif Lindholm" <leif.lindholm@linaro.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"nadavh@marvell.com" <nadavh@marvell.com>,
	"jsd@semihalf.com" <jsd@semihalf.com>,
	Tomasz Michalec <tm@semihalf.com>
Subject: Re: [PATCH v2 2/4] MdeModulePkg/SdMmcPciHcDxe: Add UhsSignaling to SdMmcOverride protocol
Date: Sat, 3 Nov 2018 02:57:17 +0000	[thread overview]
Message-ID: <B80AF82E9BFB8E4FBD8C89DA810C6A093C84A013@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <CAPv3WKefMTVQJ1u8G3XFdq+AhXtFvYoK5FMJwnr1irh3oAryuQ@mail.gmail.com>

> -----Original Message-----
> From: Marcin Wojtas [mailto:mw@semihalf.com]
> Sent: Friday, November 02, 2018 8:17 PM
> To: Wu, Hao A
> Cc: edk2-devel-01; Kinney, Michael D; Gao, Liming; Leif Lindholm; Ard
> Biesheuvel; nadavh@marvell.com; jsd@semihalf.com; Tomasz Michalec
> Subject: Re: [PATCH v2 2/4] MdeModulePkg/SdMmcPciHcDxe: Add UhsSignaling
> to SdMmcOverride protocol
> 
> pt., 2 lis 2018 o 09:21 Marcin Wojtas <mw@semihalf.com> napisał(a):
> >
> > Hi Hao,
> >
> > czw., 1 lis 2018 o 08:06 Wu, Hao A <hao.a.wu@intel.com> napisał(a):
> > >
> > > Hi Marcin,
> > >
> > > > -----Original Message-----
> > > > From: Marcin Wojtas [mailto:mw@semihalf.com]
> > > > Sent: Friday, October 05, 2018 9:25 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Tian, Feng; Kinney, Michael D; Gao, Liming; leif.lindholm@linaro.org;
> Wu,
> > > > Hao A; ard.biesheuvel@linaro.org; nadavh@marvell.com;
> > > > mw@semihalf.com; jsd@semihalf.com; tm@semihalf.com
> > > > Subject: [PATCH v2 2/4] MdeModulePkg/SdMmcPciHcDxe: Add
> UhsSignaling
> > > > to SdMmcOverride protocol
> > > >
> > > > From: Tomasz Michalec <tm@semihalf.com>
> > > >
> > > > Some SD Host Controlers use different values in Host Control 2 Register
> > > > to select UHS Mode. This patch adds a new UhsSignaling type routine to
> > > > the NotifyPhase of the SdMmcOverride protocol.
> > > >
> > > > UHS signaling configuration is moved to a common, default routine
> > > > (SdMmcHcUhsSignaling), which is called when SdMmcOverride does not
> > > > cover this functionality.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> > > > ---
> > > >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h |  50 +++++++
> > > >  MdeModulePkg/Include/Protocol/SdMmcOverride.h    |   2 +
> > > >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c  | 153
> > > > ++++++++++++--------
> > > >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c    |  37 +++--
> > > >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c |  69
> +++++++++
> > > >  5 files changed, 243 insertions(+), 68 deletions(-)
> > > >
> > > > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> > > > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> > > > index e389d52..a03160d 100644
> > > > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> > > > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> > > > @@ -63,6 +63,39 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> > > > ANY KIND, EITHER EXPRESS OR IMPLIED.
> > > >  #define SD_MMC_HC_CTRL_VER            0xFE
> > > >
> > > >  //
> > > > +// SD Host Controler bits to HOST_CTRL2 register
> > > > +//
> > > > +#define SD_MMC_HC_CTRL_UHS_MASK       0x0007
> > > > +#define SD_MMC_HC_CTRL_UHS_SDR12      0x0000
> > > > +#define SD_MMC_HC_CTRL_UHS_SDR25      0x0001
> > > > +#define SD_MMC_HC_CTRL_UHS_SDR50      0x0002
> > > > +#define SD_MMC_HC_CTRL_UHS_SDR104     0x0003
> > > > +#define SD_MMC_HC_CTRL_UHS_DDR50      0x0004
> > > > +#define SD_MMC_HC_CTRL_MMC_DDR52      0x0004
> > > > +#define SD_MMC_HC_CTRL_MMC_SDR50      0x0002
> > >
> > > I think SD_MMC_HC_CTRL_MMC_SDR50 is not needed here.
> > >
> > > Since according to the SD Physical Layer Simplified Specification, max clock
> > > frequency for SD bus mode SDR50 is 100MHz. And there is no eMMC bus
> mode whose
> > > max clock frequency is at 100MHz in Embedded Multi-Media Card Electrical
> > > Standard (5.1).
> >
> > Ok, will drop it.
> >
> > >
> > > > +#define SD_MMC_HC_CTRL_MMC_SDR25      0x0001
> > > > +#define SD_MMC_HC_CTRL_MMC_SDR12      0x0000
> > > > +#define SD_MMC_HC_CTRL_HS200          0x0003
> > > > +#define SD_MMC_HC_CTRL_HS400          0x0005
> > >
> > > How about the below renames & reorder?
> > >
> > > SD_MMC_HC_CTRL_MMC_LEGACY      0x0000
> > > SD_MMC_HC_CTRL_MMC_HS_SDR      0x0001
> > > SD_MMC_HC_CTRL_MMC_HS_DDR      0x0004
> > > SD_MMC_HC_CTRL_MMC_HS200      0x0003
> > > SD_MMC_HC_CTRL_MMC_HS400      0x0005
> >
> > Ok.
> >
> > >
> > > > +
> > > > +//
> > > > +// Timing modes for uhs
> > > > +//
> > > > +typedef enum {
> > > > +  SdMmcUhsSdr12,
> > > > +  SdMmcUhsSdr25,
> > > > +  SdMmcUhsSdr50,
> > > > +  SdMmcUhsSdr104,
> > > > +  SdMmcUhsDdr50,
> > > > +  SdMmcMmcDdr52,
> > > > +  SdMmcMmcSdr50,
> > > > +  SdMmcMmcSdr25,
> > > > +  SdMmcMmcSdr12,
> > > > +  SdMmcMmcHs200,
> > > > +  SdMmcMmcHs400,
> > > > +} SD_MMC_UHS_TIMING;
> > >
> > > Suggest a similar drop of 'SdMmcMmcSdr50' and rename according to the
> above
> > > comments upon HOST_CTRL2 register value definitions. Also, how about a
> rename
> > > for enum to SD_MMC_BUS_MODE?
> >
> > Ok.
> >
> > >
> > > > +
> > > > +//
> > > >  // The transfer modes supported by SD Host Controller
> > > >  // Simplified Spec 3.0 Table 1-2
> > > >  //
> > > > @@ -508,4 +541,21 @@ SdMmcHcInitTimeoutCtrl (
> > > >    IN UINT8                  Slot
> > > >    );
> > > >
> > > > +/**
> > > > +  Set SD Host Controler control 2 registry according to selected speed.
> > > > +
> > > > +  @param[in] PciIo          The PCI IO protocol instance.
> > > > +  @param[in] Slot           The slot number of the SD card to send the
> > > > command to.
> > > > +  @param[in] Timing         The timing to select.
> > > > +
> > > > +  @retval EFI_SUCCESS       The timing is set successfully.
> > > > +  @retval Others            The timing isn't set successfully.
> > > > +**/
> > > > +EFI_STATUS
> > > > +SdMmcHcUhsSignaling (
> > > > +  IN EFI_PCI_IO_PROTOCOL    *PciIo,
> > > > +  IN UINT8                  Slot,
> > > > +  IN SD_MMC_UHS_TIMING      Timing
> > > > +  );
> > > > +
> > > >  #endif
> > > > diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h
> > > > b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
> > > > index 178945f..25db98a 100644
> > > > --- a/MdeModulePkg/Include/Protocol/SdMmcOverride.h
> > > > +++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
> > > > @@ -17,6 +17,7 @@
> > > >  #ifndef __SD_MMC_OVERRIDE_H__
> > > >  #define __SD_MMC_OVERRIDE_H__
> > > >
> > > > +#include <Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h>
> > >
> > > Please do not expose a module private header file here.
> > >
> > > One approach comes to me is to keep the SD/MMC bus mode enumeration
> structure
> > > in this protocol header file. SdMmcPciHcDxe driver and producers of the
> > > Override protocol keep a version of the HOST_CTRL2 register value macros
> of
> > > their own.
> >
> > Agree. I will move necessary defines to
> > Include/Protocol/SdMmcOverride.h instead of exposing SdMmcPciHci.h.
> > HOST_CTRL2 contents will be a local define in producer code.
> >
> > >
> > > >  #include <Protocol/SdMmcPassThru.h>
> > > >
> > > >  #define EDKII_SD_MMC_OVERRIDE_PROTOCOL_GUID \
> > > > @@ -31,6 +32,7 @@ typedef enum {
> > > >    EdkiiSdMmcResetPost,
> > > >    EdkiiSdMmcInitHostPre,
> > > >    EdkiiSdMmcInitHostPost,
> > > > +  EdkiiSdMmcUhsSignaling,
> > > >  } EDKII_SD_MMC_PHASE_TYPE;
> > > >
> > > >  /**
> > > > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > > > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > > > index c5fd214..05bd4a0 100755
> > > > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > > > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > > > @@ -740,10 +740,13 @@ EmmcSwitchToHighSpeed (
> > > >    IN UINT8                              BusWidth
> > > >    )
> > > >  {
> > > > -  EFI_STATUS          Status;
> > > > -  UINT8               HsTiming;
> > > > -  UINT8               HostCtrl1;
> > > > -  UINT8               HostCtrl2;
> > > > +  EFI_STATUS              Status;
> > > > +  UINT8                   HsTiming;
> > > > +  UINT8                   HostCtrl1;
> > > > +  SD_MMC_UHS_TIMING       Timing;
> > > > +  SD_MMC_HC_PRIVATE_DATA  *Private;
> > > > +
> > > > +  Private = SD_MMC_HC_PRIVATE_FROM_THIS (PassThru);
> > > >
> > > >    Status = EmmcSwitchBusWidth (PciIo, PassThru, Slot, Rca, IsDdr,
> BusWidth);
> > > >    if (EFI_ERROR (Status)) {
> > > > @@ -758,27 +761,37 @@ EmmcSwitchToHighSpeed (
> > > >      return Status;
> > > >    }
> > > >
> > > > -  //
> > > > -  // Clean UHS Mode Select field of Host Control 2 reigster before update
> > > > -  //
> > > > -  HostCtrl2 = (UINT8)~0x7;
> > > > -  Status = SdMmcHcAndMmio (PciIo, Slot, SD_MMC_HC_HOST_CTRL2,
> > > > sizeof (HostCtrl2), &HostCtrl2);
> > > > -  if (EFI_ERROR (Status)) {
> > > > -    return Status;
> > > > -  }
> > > > -  //
> > > > -  // Set UHS Mode Select field of Host Control 2 reigster to SDR12/25/50
> > > > -  //
> > > >    if (IsDdr) {
> > > > -    HostCtrl2 = BIT2;
> > > > +    Timing = SdMmcMmcDdr52;
> > > >    } else if (ClockFreq == 52) {
> > > > -    HostCtrl2 = BIT0;
> > > > +    Timing = SdMmcMmcSdr50;
> > > > +  } else if (ClockFreq == 26) {
> > > > +    Timing = SdMmcMmcSdr25;
> > > >    } else {
> > > > -    HostCtrl2 = 0;
> > > > +    Timing = SdMmcMmcSdr12;
> > > >    }
> > >
> > > As mentioned above, "SdMmcMmcSdr50" can be dropped here.
> > > And considering the rename above, how about:
> > >
> > >   if (IsDdr) {
> > >     Timing = SdMmcMmcHsDdr;
> > >   } else if (ClockFreq == 52) {
> > >     Timing = SdMmcMmcHsSdr;
> > >   } else {
> > >     Timing = SdMmcMmcLegacy;
> > >   }
> >
> > Ok.
> >
> > >
> > > > -  Status = SdMmcHcOrMmio (PciIo, Slot, SD_MMC_HC_HOST_CTRL2,
> sizeof
> > > > (HostCtrl2), &HostCtrl2);
> > > > -  if (EFI_ERROR (Status)) {
> > > > -    return Status;
> > > > +
> > > > +  if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
> > > > +    Status = mOverride->NotifyPhase (
> > > > +                          Private->ControllerHandle,
> > > > +                          Slot,
> > > > +                          EdkiiSdMmcUhsSignaling,
> > > > +                          &Timing
> > > > +                          );
> > > > +    if (EFI_ERROR (Status)) {
> > > > +      DEBUG ((
> > > > +        DEBUG_ERROR,
> > > > +        "%a: SD/MMC uhs signaling notifier callback failed - %r\n",
> > > > +        __FUNCTION__,
> > > > +        Status
> > > > +        ));
> > > > +      return Status;
> > > > +    }
> > > > +  } else {
> > > > +    Status = SdMmcHcUhsSignaling (PciIo, Slot, Timing);
> > > > +    if (EFI_ERROR (Status)) {
> > > > +      return Status;
> > > > +    }
> > > >    }
> > >
> > > I have concern for this, current existing hook points for the NotifyPhase()
> > > service are performing additional operations during the controller
> > > initialization process.
> > >
> > > Producer of the override protocol can simply return EFI_SUCCESS, if there is
> > > nothing to do for a specific hook point.
> > >
> > > But this hook here is to override the behavior when setting the "UHS Mode
> > > Select" field of Host Control 2 Register. If the override protocol producer
> > > does not want to override the behavior at the 'EdkiiSdMmcUhsSignaling'
> hook,
> > > but has to do something in other hooks, one cannot directly return
> EFI_SUCCESS
> > > for the 'EdkiiSdMmcUhsSignaling' hook. For this case, one has to implement
> the
> > > 'EdkiiSdMmcUhsSignaling' hook even if the behavior will be exactly the
> same as
> > > the SdMmcPciHcDxe driver.
> >
> > I see your point. It's not additional code, but replacing the default.
> > IMO the easiest way to handle it is to go back to a separate
> > UhsSignaling callback, so that it's either omitted or explicitly
> > defined by Override protocol producer driver. What do you think?
> >
> 
> Second thought here, as previously I discussed a lot with Ard, how to
> keep only Notify and Capability callbacks. I think the best compromise
> would be to call SdMmcHcUhsSignaling unconditionally before
> SdMmcOverride callback. In case the producer does nothing, the
> defaults would be used. This way, in case of deviations from standard,
> the the producer driver would have to handle updating only affected
> timing values.

Yes, I was thinking quite the same:

A. Set the "UHS Mode Select" field more than 1 time

Abstracted code:

  Status = SdMmcHcUhsSignaling (PciIo, Slot, Timing);
  if (EFI_ERROR (Status)) {
    return Status;
  }

  if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
    Status = mOverride->NotifyPhase (EdkiiSdMmcUhsSignaling);
    ...
  }

For this approach, I am not very sure if setting the "UHS Mode Select" field
multiple times will bring any side effect.


Another possible approach comes to my mind is that:

B. Introduce a new return status to the NotifyPhase() service to indicate
nothing has been done (in other words, the hook type is just ignored by the
implementation)

The current implementation of the NotifyPhase() service will return EFI_SUCCESS
when:
1) the additional operations finished successfully;
2) nothing has been done for a specific hook type.

I am thinking whether a new return status (like EFI_UNSUPPORTED) can be
introduced to distinguish the above 2 cases.

For this approach, the caller of the NotifyPhase() will then not treat this new
return status as a fatal error, and the initialization process should continue.


Best Regards,
Hao Wu

> 
> Best regards,
> Marcin

  reply	other threads:[~2018-11-03  2:57 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-05 13:25 [PATCH v2 0/4] SdMmcOverride extension Marcin Wojtas
2018-10-05 13:25 ` [PATCH v2 1/4] MdeModulePkg/SdMmcPciHcDxe: Add an optional parameter in NotifyPhase Marcin Wojtas
2018-10-08 12:21   ` Ard Biesheuvel
2018-10-05 13:25 ` [PATCH v2 2/4] MdeModulePkg/SdMmcPciHcDxe: Add UhsSignaling to SdMmcOverride protocol Marcin Wojtas
2018-10-05 15:12   ` Philippe Mathieu-Daudé
2018-10-05 15:17     ` Marcin Wojtas
2018-10-08 12:41   ` Ard Biesheuvel
2018-10-08 12:59     ` Marcin Wojtas
2018-10-08 13:07       ` Ard Biesheuvel
2018-10-08 13:17         ` Marcin Wojtas
2018-10-08 13:27           ` Ard Biesheuvel
2018-10-08 13:37             ` Marcin Wojtas
2018-10-08 13:43               ` Ard Biesheuvel
2018-10-08 14:52                 ` Marcin Wojtas
2018-10-08 15:10                   ` Ard Biesheuvel
2018-10-09 11:22                     ` Wu, Hao A
2018-10-09 11:32                       ` Marcin Wojtas
2018-10-09 11:45                         ` Ard Biesheuvel
2018-10-09 11:51                           ` Marcin Wojtas
2018-10-11 15:43                             ` Marcin Wojtas
2018-10-12  1:39                               ` Wu, Hao A
2018-10-12  5:06                                 ` Marcin Wojtas
2018-10-12 15:55                                   ` Ard Biesheuvel
2018-10-12 16:04                                     ` Marcin Wojtas
2018-10-12 16:24                                       ` Ard Biesheuvel
2018-10-12 16:49                                         ` Marcin Wojtas
2018-11-01  7:04   ` Wu, Hao A
2018-11-02  8:21     ` Marcin Wojtas
2018-11-02 12:16       ` Marcin Wojtas
2018-11-03  2:57         ` Wu, Hao A [this message]
2018-10-05 13:25 ` [PATCH v2 3/4] MdeModulePkg/SdMmcPciHcDxe: Add SwitchClockFreqPost to SdMmcOverride Marcin Wojtas
2018-10-08 12:44   ` Ard Biesheuvel
2018-11-01  7:06   ` Wu, Hao A
2018-11-02  9:39     ` Marcin Wojtas
2018-11-03  3:19       ` Wu, Hao A
2018-10-05 13:25 ` [PATCH v2 4/4] MdeModulePkg/SdMmcPciHcDxe: Allow overriding base clock frequency Marcin Wojtas
2018-10-08 12:49   ` Ard Biesheuvel
2018-11-01  7:11   ` Wu, Hao A
2018-11-02  9:52     ` Marcin Wojtas
2018-10-12  5:24 ` [PATCH v2 0/4] SdMmcOverride extension Wu, Hao A
2018-10-12  5:33   ` Marcin Wojtas
2018-10-12 12:48     ` Wu, Hao A
2018-10-12 12:50       ` Marcin Wojtas
2018-10-25 12:43         ` Marcin Wojtas
2018-10-26  7:22           ` Wu, Hao A
2018-11-01  7:11 ` Wu, Hao A
2018-11-02 10:09   ` Marcin Wojtas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B80AF82E9BFB8E4FBD8C89DA810C6A093C84A013@SHSMSX104.ccr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox