linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Issue with sequence to switch to HS400
@ 2019-07-22 22:31 Alan Cooper
  2019-07-23  5:20 ` Adrian Hunter
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Cooper @ 2019-07-22 22:31 UTC (permalink / raw)
  To: Ulf Hansson, cc: Adrian Hunter, linux-mmc, : Linux Kernel Mailing List

I'm having a problem with a new SD/MMC controller and PHY in our
latest SoC's. The issue I'm seeing is that I can't switch into HS400
mode. This looks like something the driver is doing that doesn't meet
the JEDEC spec. In the "HS400 timing mode selection" section of the
JEDEC spec , in step 7 it states:

7) Set the “Timing Interface” parameter in the HS_TIMING [185] field
of the Extended CSD register to 0x1 to switch to High Speed mode and
then set the clock frequency to a value not greater than 52 MHz.

In the function mmc_select_hs400() in mmc.c, I see that a switch
command is done to set the eMMC device to HS mode and then
mmc_set_timing(card->host, MMC_TIMING_MMC_HS) is used to change the
controller to HS mode. The problem is that the "SD Host Controller
Standard Specification" states that "UHS Mode Select" field of the
"Host Control 2 Register" controls the mode when the "1.8V Signaling
Enable" bit in the same register is set, so mmc_set_timing() is
actually leaving the controller in SDR12 mode and mmc_select_hs400()
will then set the clock to 52MHz. This causes our PHY to detect an
illegal combination and return an error.

I think the easiest fix would be to change mmc_set_timing(card->host,
MMC_TIMING_MMC_HS) to mmc_set_timing(card->host,
MMC_TIMING_UHS_SDR25). The other possibility would be to change
mmc_set_timing to handle the "1.8V Signaling Enable" bit properly.
I'll submit a patch based on the feedback I get.

Thanks
Al Cooper

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Issue with sequence to switch to HS400
  2019-07-22 22:31 Issue with sequence to switch to HS400 Alan Cooper
@ 2019-07-23  5:20 ` Adrian Hunter
  2019-07-23 12:34   ` Alan Cooper
  0 siblings, 1 reply; 7+ messages in thread
From: Adrian Hunter @ 2019-07-23  5:20 UTC (permalink / raw)
  To: Alan Cooper, Ulf Hansson, linux-mmc, : Linux Kernel Mailing List

On 23/07/19 1:31 AM, Alan Cooper wrote:
> I'm having a problem with a new SD/MMC controller and PHY in our
> latest SoC's. The issue I'm seeing is that I can't switch into HS400
> mode. This looks like something the driver is doing that doesn't meet
> the JEDEC spec. In the "HS400 timing mode selection" section of the
> JEDEC spec , in step 7 it states:
> 
> 7) Set the “Timing Interface” parameter in the HS_TIMING [185] field
> of the Extended CSD register to 0x1 to switch to High Speed mode and
> then set the clock frequency to a value not greater than 52 MHz.
> 
> In the function mmc_select_hs400() in mmc.c, I see that a switch
> command is done to set the eMMC device to HS mode and then
> mmc_set_timing(card->host, MMC_TIMING_MMC_HS) is used to change the
> controller to HS mode. The problem is that the "SD Host Controller
> Standard Specification" states that "UHS Mode Select" field of the
> "Host Control 2 Register" controls the mode when the "1.8V Signaling
> Enable" bit in the same register is set, so mmc_set_timing() is
> actually leaving the controller in SDR12 mode and mmc_select_hs400()
> will then set the clock to 52MHz. This causes our PHY to detect an
> illegal combination and return an error.
> 
> I think the easiest fix would be to change mmc_set_timing(card->host,
> MMC_TIMING_MMC_HS) to mmc_set_timing(card->host,
> MMC_TIMING_UHS_SDR25). The other possibility would be to change
> mmc_set_timing to handle the "1.8V Signaling Enable" bit properly.
> I'll submit a patch based on the feedback I get.

eMMC is governed by JEDEC specs not SD specs.

Please consider making a change in your driver instead.  For example, hook
->set_ios() and if 1.8V is enabled and timing is set to MMC_TIMING_MMC_HS
then change it to MMC_TIMING_UHS_SDR25.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Issue with sequence to switch to HS400
  2019-07-23  5:20 ` Adrian Hunter
@ 2019-07-23 12:34   ` Alan Cooper
  2019-07-25  7:31     ` Adrian Hunter
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Cooper @ 2019-07-23 12:34 UTC (permalink / raw)
  To: Adrian Hunter; +Cc: Ulf Hansson, linux-mmc, : Linux Kernel Mailing List

On Tue, Jul 23, 2019 at 1:21 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>
> On 23/07/19 1:31 AM, Alan Cooper wrote:
> > I'm having a problem with a new SD/MMC controller and PHY in our
> > latest SoC's. The issue I'm seeing is that I can't switch into HS400
> > mode. This looks like something the driver is doing that doesn't meet
> > the JEDEC spec. In the "HS400 timing mode selection" section of the
> > JEDEC spec , in step 7 it states:
> >
> > 7) Set the “Timing Interface” parameter in the HS_TIMING [185] field
> > of the Extended CSD register to 0x1 to switch to High Speed mode and
> > then set the clock frequency to a value not greater than 52 MHz.
> >
> > In the function mmc_select_hs400() in mmc.c, I see that a switch
> > command is done to set the eMMC device to HS mode and then
> > mmc_set_timing(card->host, MMC_TIMING_MMC_HS) is used to change the
> > controller to HS mode. The problem is that the "SD Host Controller
> > Standard Specification" states that "UHS Mode Select" field of the
> > "Host Control 2 Register" controls the mode when the "1.8V Signaling
> > Enable" bit in the same register is set, so mmc_set_timing() is
> > actually leaving the controller in SDR12 mode and mmc_select_hs400()
> > will then set the clock to 52MHz. This causes our PHY to detect an
> > illegal combination and return an error.
> >
> > I think the easiest fix would be to change mmc_set_timing(card->host,
> > MMC_TIMING_MMC_HS) to mmc_set_timing(card->host,
> > MMC_TIMING_UHS_SDR25). The other possibility would be to change
> > mmc_set_timing to handle the "1.8V Signaling Enable" bit properly.
> > I'll submit a patch based on the feedback I get.
>
> eMMC is governed by JEDEC specs not SD specs.

My understanding is that JEDEC does not have a host controller spec so
this driver uses the "SD Host Controller Standard Specification".

>
> Please consider making a change in your driver instead.  For example, hook
> ->set_ios() and if 1.8V is enabled and timing is set to MMC_TIMING_MMC_HS
> then change it to MMC_TIMING_UHS_SDR25.

That's an easy fix, but it still leaves all other drivers/systems
temporarily using SDR12 at 52MHz during the switch to HS400.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Issue with sequence to switch to HS400
  2019-07-23 12:34   ` Alan Cooper
@ 2019-07-25  7:31     ` Adrian Hunter
  2019-07-25 21:37       ` Alan Cooper
  0 siblings, 1 reply; 7+ messages in thread
From: Adrian Hunter @ 2019-07-25  7:31 UTC (permalink / raw)
  To: Alan Cooper; +Cc: Ulf Hansson, linux-mmc, Linux Kernel Mailing List

On 23/07/19 3:34 PM, Alan Cooper wrote:
> On Tue, Jul 23, 2019 at 1:21 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>>
>> On 23/07/19 1:31 AM, Alan Cooper wrote:
>>> I'm having a problem with a new SD/MMC controller and PHY in our
>>> latest SoC's. The issue I'm seeing is that I can't switch into HS400
>>> mode. This looks like something the driver is doing that doesn't meet
>>> the JEDEC spec. In the "HS400 timing mode selection" section of the
>>> JEDEC spec , in step 7 it states:
>>>
>>> 7) Set the “Timing Interface” parameter in the HS_TIMING [185] field
>>> of the Extended CSD register to 0x1 to switch to High Speed mode and
>>> then set the clock frequency to a value not greater than 52 MHz.
>>>
>>> In the function mmc_select_hs400() in mmc.c, I see that a switch
>>> command is done to set the eMMC device to HS mode and then
>>> mmc_set_timing(card->host, MMC_TIMING_MMC_HS) is used to change the
>>> controller to HS mode. The problem is that the "SD Host Controller
>>> Standard Specification" states that "UHS Mode Select" field of the
>>> "Host Control 2 Register" controls the mode when the "1.8V Signaling
>>> Enable" bit in the same register is set, so mmc_set_timing() is
>>> actually leaving the controller in SDR12 mode and mmc_select_hs400()
>>> will then set the clock to 52MHz. This causes our PHY to detect an
>>> illegal combination and return an error.
>>>
>>> I think the easiest fix would be to change mmc_set_timing(card->host,
>>> MMC_TIMING_MMC_HS) to mmc_set_timing(card->host,
>>> MMC_TIMING_UHS_SDR25). The other possibility would be to change
>>> mmc_set_timing to handle the "1.8V Signaling Enable" bit properly.
>>> I'll submit a patch based on the feedback I get.
>>
>> eMMC is governed by JEDEC specs not SD specs.
> 
> My understanding is that JEDEC does not have a host controller spec so
> this driver uses the "SD Host Controller Standard Specification".

There is no spec for using eMMC with SDHCI.

> 
>>
>> Please consider making a change in your driver instead.  For example, hook
>> ->set_ios() and if 1.8V is enabled and timing is set to MMC_TIMING_MMC_HS
>> then change it to MMC_TIMING_UHS_SDR25.
> 
> That's an easy fix, but it still leaves all other drivers/systems
> temporarily using SDR12 at 52MHz during the switch to HS400.

Yes, I changed my mind.  Does this work:

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 59acf8e3331e..f9d241458dcd 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1849,7 +1849,9 @@ void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
 		ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
 	else if (timing == MMC_TIMING_UHS_SDR12)
 		ctrl_2 |= SDHCI_CTRL_UHS_SDR12;
-	else if (timing == MMC_TIMING_UHS_SDR25)
+	else if (timing == MMC_TIMING_SD_HS ||
+		 timing == MMC_TIMING_MMC_HS ||
+		 timing == MMC_TIMING_UHS_SDR25)
 		ctrl_2 |= SDHCI_CTRL_UHS_SDR25;
 	else if (timing == MMC_TIMING_UHS_SDR50)
 		ctrl_2 |= SDHCI_CTRL_UHS_SDR50;

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: Issue with sequence to switch to HS400
  2019-07-25  7:31     ` Adrian Hunter
@ 2019-07-25 21:37       ` Alan Cooper
  2019-07-30  7:58         ` Adrian Hunter
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Cooper @ 2019-07-25 21:37 UTC (permalink / raw)
  To: Adrian Hunter; +Cc: Ulf Hansson, linux-mmc, Linux Kernel Mailing List

That's an even better solution and it gets my HS400 mode working.
Will you add this change or should I?

Thanks
Al

On Thu, Jul 25, 2019 at 3:33 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>
> On 23/07/19 3:34 PM, Alan Cooper wrote:
> > On Tue, Jul 23, 2019 at 1:21 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
> >>
> >> On 23/07/19 1:31 AM, Alan Cooper wrote:
> >>> I'm having a problem with a new SD/MMC controller and PHY in our
> >>> latest SoC's. The issue I'm seeing is that I can't switch into HS400
> >>> mode. This looks like something the driver is doing that doesn't meet
> >>> the JEDEC spec. In the "HS400 timing mode selection" section of the
> >>> JEDEC spec , in step 7 it states:
> >>>
> >>> 7) Set the “Timing Interface” parameter in the HS_TIMING [185] field
> >>> of the Extended CSD register to 0x1 to switch to High Speed mode and
> >>> then set the clock frequency to a value not greater than 52 MHz.
> >>>
> >>> In the function mmc_select_hs400() in mmc.c, I see that a switch
> >>> command is done to set the eMMC device to HS mode and then
> >>> mmc_set_timing(card->host, MMC_TIMING_MMC_HS) is used to change the
> >>> controller to HS mode. The problem is that the "SD Host Controller
> >>> Standard Specification" states that "UHS Mode Select" field of the
> >>> "Host Control 2 Register" controls the mode when the "1.8V Signaling
> >>> Enable" bit in the same register is set, so mmc_set_timing() is
> >>> actually leaving the controller in SDR12 mode and mmc_select_hs400()
> >>> will then set the clock to 52MHz. This causes our PHY to detect an
> >>> illegal combination and return an error.
> >>>
> >>> I think the easiest fix would be to change mmc_set_timing(card->host,
> >>> MMC_TIMING_MMC_HS) to mmc_set_timing(card->host,
> >>> MMC_TIMING_UHS_SDR25). The other possibility would be to change
> >>> mmc_set_timing to handle the "1.8V Signaling Enable" bit properly.
> >>> I'll submit a patch based on the feedback I get.
> >>
> >> eMMC is governed by JEDEC specs not SD specs.
> >
> > My understanding is that JEDEC does not have a host controller spec so
> > this driver uses the "SD Host Controller Standard Specification".
>
> There is no spec for using eMMC with SDHCI.
>
> >
> >>
> >> Please consider making a change in your driver instead.  For example, hook
> >> ->set_ios() and if 1.8V is enabled and timing is set to MMC_TIMING_MMC_HS
> >> then change it to MMC_TIMING_UHS_SDR25.
> >
> > That's an easy fix, but it still leaves all other drivers/systems
> > temporarily using SDR12 at 52MHz during the switch to HS400.
>
> Yes, I changed my mind.  Does this work:
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 59acf8e3331e..f9d241458dcd 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1849,7 +1849,9 @@ void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
>         else if (timing == MMC_TIMING_UHS_SDR12)
>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR12;
> -       else if (timing == MMC_TIMING_UHS_SDR25)
> +       else if (timing == MMC_TIMING_SD_HS ||
> +                timing == MMC_TIMING_MMC_HS ||
> +                timing == MMC_TIMING_UHS_SDR25)
>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR25;
>         else if (timing == MMC_TIMING_UHS_SDR50)
>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR50;

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Issue with sequence to switch to HS400
  2019-07-25 21:37       ` Alan Cooper
@ 2019-07-30  7:58         ` Adrian Hunter
  2019-08-05 19:43           ` Alan Cooper
  0 siblings, 1 reply; 7+ messages in thread
From: Adrian Hunter @ 2019-07-30  7:58 UTC (permalink / raw)
  To: Alan Cooper; +Cc: Ulf Hansson, linux-mmc, Linux Kernel Mailing List

On 26/07/19 12:37 AM, Alan Cooper wrote:
> That's an even better solution and it gets my HS400 mode working.
> Will you add this change or should I?

You, if you wouldn't mind.

> 
> Thanks
> Al
> 
> On Thu, Jul 25, 2019 at 3:33 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>>
>> On 23/07/19 3:34 PM, Alan Cooper wrote:
>>> On Tue, Jul 23, 2019 at 1:21 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>>>>
>>>> On 23/07/19 1:31 AM, Alan Cooper wrote:
>>>>> I'm having a problem with a new SD/MMC controller and PHY in our
>>>>> latest SoC's. The issue I'm seeing is that I can't switch into HS400
>>>>> mode. This looks like something the driver is doing that doesn't meet
>>>>> the JEDEC spec. In the "HS400 timing mode selection" section of the
>>>>> JEDEC spec , in step 7 it states:
>>>>>
>>>>> 7) Set the “Timing Interface” parameter in the HS_TIMING [185] field
>>>>> of the Extended CSD register to 0x1 to switch to High Speed mode and
>>>>> then set the clock frequency to a value not greater than 52 MHz.
>>>>>
>>>>> In the function mmc_select_hs400() in mmc.c, I see that a switch
>>>>> command is done to set the eMMC device to HS mode and then
>>>>> mmc_set_timing(card->host, MMC_TIMING_MMC_HS) is used to change the
>>>>> controller to HS mode. The problem is that the "SD Host Controller
>>>>> Standard Specification" states that "UHS Mode Select" field of the
>>>>> "Host Control 2 Register" controls the mode when the "1.8V Signaling
>>>>> Enable" bit in the same register is set, so mmc_set_timing() is
>>>>> actually leaving the controller in SDR12 mode and mmc_select_hs400()
>>>>> will then set the clock to 52MHz. This causes our PHY to detect an
>>>>> illegal combination and return an error.
>>>>>
>>>>> I think the easiest fix would be to change mmc_set_timing(card->host,
>>>>> MMC_TIMING_MMC_HS) to mmc_set_timing(card->host,
>>>>> MMC_TIMING_UHS_SDR25). The other possibility would be to change
>>>>> mmc_set_timing to handle the "1.8V Signaling Enable" bit properly.
>>>>> I'll submit a patch based on the feedback I get.
>>>>
>>>> eMMC is governed by JEDEC specs not SD specs.
>>>
>>> My understanding is that JEDEC does not have a host controller spec so
>>> this driver uses the "SD Host Controller Standard Specification".
>>
>> There is no spec for using eMMC with SDHCI.
>>
>>>
>>>>
>>>> Please consider making a change in your driver instead.  For example, hook
>>>> ->set_ios() and if 1.8V is enabled and timing is set to MMC_TIMING_MMC_HS
>>>> then change it to MMC_TIMING_UHS_SDR25.
>>>
>>> That's an easy fix, but it still leaves all other drivers/systems
>>> temporarily using SDR12 at 52MHz during the switch to HS400.
>>
>> Yes, I changed my mind.  Does this work:
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 59acf8e3331e..f9d241458dcd 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1849,7 +1849,9 @@ void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
>>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
>>         else if (timing == MMC_TIMING_UHS_SDR12)
>>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR12;
>> -       else if (timing == MMC_TIMING_UHS_SDR25)
>> +       else if (timing == MMC_TIMING_SD_HS ||
>> +                timing == MMC_TIMING_MMC_HS ||
>> +                timing == MMC_TIMING_UHS_SDR25)
>>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR25;
>>         else if (timing == MMC_TIMING_UHS_SDR50)
>>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR50;
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Issue with sequence to switch to HS400
  2019-07-30  7:58         ` Adrian Hunter
@ 2019-08-05 19:43           ` Alan Cooper
  0 siblings, 0 replies; 7+ messages in thread
From: Alan Cooper @ 2019-08-05 19:43 UTC (permalink / raw)
  To: Adrian Hunter; +Cc: Ulf Hansson, linux-mmc, Linux Kernel Mailing List

No problem.

Thanks
Al

On Tue, Jul 30, 2019 at 4:00 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>
> On 26/07/19 12:37 AM, Alan Cooper wrote:
> > That's an even better solution and it gets my HS400 mode working.
> > Will you add this change or should I?
>
> You, if you wouldn't mind.
>
> >
> > Thanks
> > Al
> >
> > On Thu, Jul 25, 2019 at 3:33 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
> >>
> >> On 23/07/19 3:34 PM, Alan Cooper wrote:
> >>> On Tue, Jul 23, 2019 at 1:21 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
> >>>>
> >>>> On 23/07/19 1:31 AM, Alan Cooper wrote:
> >>>>> I'm having a problem with a new SD/MMC controller and PHY in our
> >>>>> latest SoC's. The issue I'm seeing is that I can't switch into HS400
> >>>>> mode. This looks like something the driver is doing that doesn't meet
> >>>>> the JEDEC spec. In the "HS400 timing mode selection" section of the
> >>>>> JEDEC spec , in step 7 it states:
> >>>>>
> >>>>> 7) Set the “Timing Interface” parameter in the HS_TIMING [185] field
> >>>>> of the Extended CSD register to 0x1 to switch to High Speed mode and
> >>>>> then set the clock frequency to a value not greater than 52 MHz.
> >>>>>
> >>>>> In the function mmc_select_hs400() in mmc.c, I see that a switch
> >>>>> command is done to set the eMMC device to HS mode and then
> >>>>> mmc_set_timing(card->host, MMC_TIMING_MMC_HS) is used to change the
> >>>>> controller to HS mode. The problem is that the "SD Host Controller
> >>>>> Standard Specification" states that "UHS Mode Select" field of the
> >>>>> "Host Control 2 Register" controls the mode when the "1.8V Signaling
> >>>>> Enable" bit in the same register is set, so mmc_set_timing() is
> >>>>> actually leaving the controller in SDR12 mode and mmc_select_hs400()
> >>>>> will then set the clock to 52MHz. This causes our PHY to detect an
> >>>>> illegal combination and return an error.
> >>>>>
> >>>>> I think the easiest fix would be to change mmc_set_timing(card->host,
> >>>>> MMC_TIMING_MMC_HS) to mmc_set_timing(card->host,
> >>>>> MMC_TIMING_UHS_SDR25). The other possibility would be to change
> >>>>> mmc_set_timing to handle the "1.8V Signaling Enable" bit properly.
> >>>>> I'll submit a patch based on the feedback I get.
> >>>>
> >>>> eMMC is governed by JEDEC specs not SD specs.
> >>>
> >>> My understanding is that JEDEC does not have a host controller spec so
> >>> this driver uses the "SD Host Controller Standard Specification".
> >>
> >> There is no spec for using eMMC with SDHCI.
> >>
> >>>
> >>>>
> >>>> Please consider making a change in your driver instead.  For example, hook
> >>>> ->set_ios() and if 1.8V is enabled and timing is set to MMC_TIMING_MMC_HS
> >>>> then change it to MMC_TIMING_UHS_SDR25.
> >>>
> >>> That's an easy fix, but it still leaves all other drivers/systems
> >>> temporarily using SDR12 at 52MHz during the switch to HS400.
> >>
> >> Yes, I changed my mind.  Does this work:
> >>
> >> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> >> index 59acf8e3331e..f9d241458dcd 100644
> >> --- a/drivers/mmc/host/sdhci.c
> >> +++ b/drivers/mmc/host/sdhci.c
> >> @@ -1849,7 +1849,9 @@ void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
> >>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
> >>         else if (timing == MMC_TIMING_UHS_SDR12)
> >>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR12;
> >> -       else if (timing == MMC_TIMING_UHS_SDR25)
> >> +       else if (timing == MMC_TIMING_SD_HS ||
> >> +                timing == MMC_TIMING_MMC_HS ||
> >> +                timing == MMC_TIMING_UHS_SDR25)
> >>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR25;
> >>         else if (timing == MMC_TIMING_UHS_SDR50)
> >>                 ctrl_2 |= SDHCI_CTRL_UHS_SDR50;
> >
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-08-05 19:43 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-22 22:31 Issue with sequence to switch to HS400 Alan Cooper
2019-07-23  5:20 ` Adrian Hunter
2019-07-23 12:34   ` Alan Cooper
2019-07-25  7:31     ` Adrian Hunter
2019-07-25 21:37       ` Alan Cooper
2019-07-30  7:58         ` Adrian Hunter
2019-08-05 19:43           ` Alan Cooper

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).