From: Eugen Hristev <[email protected]>
Add mmc capabilities for SDMMC0 for this board.
With this enabled, eMMC connected card is detected as:
mmc0: new DDR MMC card at address 0001
Signed-off-by: Eugen Hristev <[email protected]>
---
arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index 149e539..194b3a3 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -54,6 +54,7 @@
sdmmc0: sdio-host@a0000000 {
bus-width = <8>;
+ mmc-ddr-3_3v;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sdmmc0_default>;
status = "okay";
--
2.7.4
On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
> From: Eugen Hristev <[email protected]>
>
> Add mmc capabilities for SDMMC0 for this board.
> With this enabled, eMMC connected card is detected as:
>
> mmc0: new DDR MMC card at address 0001
>
> Signed-off-by: Eugen Hristev <[email protected]>
Acked-by: Ludovic Desroches <[email protected]>
I am interested to have the some insights about the use of sd-uhs-*
properties.
Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can
be used as the logic control input of a mux. So even if the IP claims
to support UHS modes, it depends on the board.
Are the sd-uhs-* properties a way to deal with this? I tend to think no
as sdhci_setup_host() will set the caps depending on the content of the
capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS
quirk or sdhci-caps/sdhci-caps-mask?
Regards
Ludovic
> ---
> arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
> index 149e539..194b3a3 100644
> --- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
> +++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
> @@ -54,6 +54,7 @@
>
> sdmmc0: sdio-host@a0000000 {
> bus-width = <8>;
> + mmc-ddr-3_3v;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_sdmmc0_default>;
> status = "okay";
> --
> 2.7.4
>
On 8/08/19 3:42 PM, Ludovic Desroches wrote:
> On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
>> From: Eugen Hristev <[email protected]>
>>
>> Add mmc capabilities for SDMMC0 for this board.
>> With this enabled, eMMC connected card is detected as:
>>
>> mmc0: new DDR MMC card at address 0001
>>
>> Signed-off-by: Eugen Hristev <[email protected]>
> Acked-by: Ludovic Desroches <[email protected]>
>
> I am interested to have the some insights about the use of sd-uhs-*
> properties.
>
> Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can
> be used as the logic control input of a mux. So even if the IP claims
> to support UHS modes, it depends on the board.
>
> Are the sd-uhs-* properties a way to deal with this? I tend to think no
> as sdhci_setup_host() will set the caps depending on the content of the
> capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS
> quirk or sdhci-caps/sdhci-caps-mask?
There is "no-1-8-v" which it looks like sdhci-of-at91.c already supports:
sdhci_at91_probe() -> sdhci_get_of_property() -> sdhci_get_property()
if (device_property_present(dev, "no-1-8-v"))
host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>
> Regards
>
> Ludovic
>
>> ---
>> arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
>> index 149e539..194b3a3 100644
>> --- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
>> +++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
>> @@ -54,6 +54,7 @@
>>
>> sdmmc0: sdio-host@a0000000 {
>> bus-width = <8>;
>> + mmc-ddr-3_3v;
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_sdmmc0_default>;
>> status = "okay";
>> --
>> 2.7.4
>>
>
On Thu, Aug 08, 2019 at 03:57:30PM +0300, Adrian Hunter wrote:
> On 8/08/19 3:42 PM, Ludovic Desroches wrote:
> > On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
> >> From: Eugen Hristev <[email protected]>
> >>
> >> Add mmc capabilities for SDMMC0 for this board.
> >> With this enabled, eMMC connected card is detected as:
> >>
> >> mmc0: new DDR MMC card at address 0001
> >>
> >> Signed-off-by: Eugen Hristev <[email protected]>
> > Acked-by: Ludovic Desroches <[email protected]>
> >
> > I am interested to have the some insights about the use of sd-uhs-*
> > properties.
> >
> > Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can
> > be used as the logic control input of a mux. So even if the IP claims
> > to support UHS modes, it depends on the board.
> >
> > Are the sd-uhs-* properties a way to deal with this? I tend to think no
> > as sdhci_setup_host() will set the caps depending on the content of the
> > capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS
> > quirk or sdhci-caps/sdhci-caps-mask?
>
> There is "no-1-8-v" which it looks like sdhci-of-at91.c already supports:
>
> sdhci_at91_probe() -> sdhci_get_of_property() -> sdhci_get_property()
>
> if (device_property_present(dev, "no-1-8-v"))
> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>
Right, I forgot this property. Thanks.
Eugen, do you see cases we can't cover with this property?
Regards
Ludovic
>
> >
> > Regards
> >
> > Ludovic
> >
> >> ---
> >> arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
> >> index 149e539..194b3a3 100644
> >> --- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
> >> +++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
> >> @@ -54,6 +54,7 @@
> >>
> >> sdmmc0: sdio-host@a0000000 {
> >> bus-width = <8>;
> >> + mmc-ddr-3_3v;
> >> pinctrl-names = "default";
> >> pinctrl-0 = <&pinctrl_sdmmc0_default>;
> >> status = "okay";
> >> --
> >> 2.7.4
> >>
> >
>
On 09.08.2019 09:23, Ludovic Desroches wrote:
> On Thu, Aug 08, 2019 at 03:57:30PM +0300, Adrian Hunter wrote:
>> On 8/08/19 3:42 PM, Ludovic Desroches wrote:
>>> On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
>>>> From: Eugen Hristev <[email protected]>
>>>>
>>>> Add mmc capabilities for SDMMC0 for this board.
>>>> With this enabled, eMMC connected card is detected as:
>>>>
>>>> mmc0: new DDR MMC card at address 0001
>>>>
>>>> Signed-off-by: Eugen Hristev <[email protected]>
>>> Acked-by: Ludovic Desroches <[email protected]>
>>>
>>> I am interested to have the some insights about the use of sd-uhs-*
>>> properties.
>>>
>>> Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can
>>> be used as the logic control input of a mux. So even if the IP claims
>>> to support UHS modes, it depends on the board.
>>>
>>> Are the sd-uhs-* properties a way to deal with this? I tend to think no
>>> as sdhci_setup_host() will set the caps depending on the content of the
>>> capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS
>>> quirk or sdhci-caps/sdhci-caps-mask?
>>
>> There is "no-1-8-v" which it looks like sdhci-of-at91.c already supports:
>>
>> sdhci_at91_probe() -> sdhci_get_of_property() -> sdhci_get_property()
>>
>> if (device_property_present(dev, "no-1-8-v"))
>> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>>
>
> Right, I forgot this property. Thanks.
>
> Eugen, do you see cases we can't cover with this property?
Hi,
For current requirements and driver support, this should be enough.
I noticed one thing regarding SD-Cards, if I add property sd-uhs-sdr104
the class 10 uhs1 cards are detected as SDR104 . Without this property
they are detected as DDR50. Any idea why the difference ? The controller
does not claim to have SDR104 support ? We should add it ?
Eugen
>
> Regards
>
> Ludovic
>
>>
>>>
>>> Regards
>>>
>>> Ludovic
>>>
>>>> ---
>>>> arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
>>>> index 149e539..194b3a3 100644
>>>> --- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
>>>> +++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
>>>> @@ -54,6 +54,7 @@
>>>>
>>>> sdmmc0: sdio-host@a0000000 {
>>>> bus-width = <8>;
>>>> + mmc-ddr-3_3v;
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <&pinctrl_sdmmc0_default>;
>>>> status = "okay";
>>>> --
>>>> 2.7.4
>>>>
>>>
>>
>
On Mon, Aug 12, 2019 at 03:38:34PM +0000, [email protected] wrote:
> On 09.08.2019 09:23, Ludovic Desroches wrote:
> > On Thu, Aug 08, 2019 at 03:57:30PM +0300, Adrian Hunter wrote:
> >> On 8/08/19 3:42 PM, Ludovic Desroches wrote:
> >>> On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
> >>>> From: Eugen Hristev <[email protected]>
> >>>>
> >>>> Add mmc capabilities for SDMMC0 for this board.
> >>>> With this enabled, eMMC connected card is detected as:
> >>>>
> >>>> mmc0: new DDR MMC card at address 0001
> >>>>
> >>>> Signed-off-by: Eugen Hristev <[email protected]>
> >>> Acked-by: Ludovic Desroches <[email protected]>
> >>>
> >>> I am interested to have the some insights about the use of sd-uhs-*
> >>> properties.
> >>>
> >>> Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can
> >>> be used as the logic control input of a mux. So even if the IP claims
> >>> to support UHS modes, it depends on the board.
> >>>
> >>> Are the sd-uhs-* properties a way to deal with this? I tend to think no
> >>> as sdhci_setup_host() will set the caps depending on the content of the
> >>> capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS
> >>> quirk or sdhci-caps/sdhci-caps-mask?
> >>
> >> There is "no-1-8-v" which it looks like sdhci-of-at91.c already supports:
> >>
> >> sdhci_at91_probe() -> sdhci_get_of_property() -> sdhci_get_property()
> >>
> >> if (device_property_present(dev, "no-1-8-v"))
> >> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
> >>
> >
> > Right, I forgot this property. Thanks.
> >
> > Eugen, do you see cases we can't cover with this property?
>
> Hi,
>
> For current requirements and driver support, this should be enough.
>
> I noticed one thing regarding SD-Cards, if I add property sd-uhs-sdr104
> the class 10 uhs1 cards are detected as SDR104 . Without this property
> they are detected as DDR50. Any idea why the difference ? The controller
> does not claim to have SDR104 support ? We should add it ?
With the mainline, our tree or both? In our tree, SDR104 is removed from
the capabilities.
Ludovic
On 13.08.2019 09:53, Ludovic Desroches wrote:
> On Mon, Aug 12, 2019 at 03:38:34PM +0000, [email protected] wrote:
>> On 09.08.2019 09:23, Ludovic Desroches wrote:
>>> On Thu, Aug 08, 2019 at 03:57:30PM +0300, Adrian Hunter wrote:
>>>> On 8/08/19 3:42 PM, Ludovic Desroches wrote:
>>>>> On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
>>>>>> From: Eugen Hristev <[email protected]>
>>>>>>
>>>>>> Add mmc capabilities for SDMMC0 for this board.
>>>>>> With this enabled, eMMC connected card is detected as:
>>>>>>
>>>>>> mmc0: new DDR MMC card at address 0001
>>>>>>
>>>>>> Signed-off-by: Eugen Hristev <[email protected]>
>>>>> Acked-by: Ludovic Desroches <[email protected]>
>>>>>
>>>>> I am interested to have the some insights about the use of sd-uhs-*
>>>>> properties.
>>>>>
>>>>> Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can
>>>>> be used as the logic control input of a mux. So even if the IP claims
>>>>> to support UHS modes, it depends on the board.
>>>>>
>>>>> Are the sd-uhs-* properties a way to deal with this? I tend to think no
>>>>> as sdhci_setup_host() will set the caps depending on the content of the
>>>>> capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS
>>>>> quirk or sdhci-caps/sdhci-caps-mask?
>>>>
>>>> There is "no-1-8-v" which it looks like sdhci-of-at91.c already supports:
>>>>
>>>> sdhci_at91_probe() -> sdhci_get_of_property() -> sdhci_get_property()
>>>>
>>>> if (device_property_present(dev, "no-1-8-v"))
>>>> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>>>>
>>>
>>> Right, I forgot this property. Thanks.
>>>
>>> Eugen, do you see cases we can't cover with this property?
>>
>> Hi,
>>
>> For current requirements and driver support, this should be enough.
>>
>> I noticed one thing regarding SD-Cards, if I add property sd-uhs-sdr104
>> the class 10 uhs1 cards are detected as SDR104 . Without this property
>> they are detected as DDR50. Any idea why the difference ? The controller
>> does not claim to have SDR104 support ? We should add it ?
>
> With the mainline, our tree or both? In our tree, SDR104 is removed from
> the capabilities.
>
> Ludovic
>
Hello Alexandre,
Anything more needed regarding this patch ?
Thanks,
Eugen
On 03/10/2019 10:24:52+0000, [email protected] wrote:
>
>
> On 13.08.2019 09:53, Ludovic Desroches wrote:
> > On Mon, Aug 12, 2019 at 03:38:34PM +0000, [email protected] wrote:
> >> On 09.08.2019 09:23, Ludovic Desroches wrote:
> >>> On Thu, Aug 08, 2019 at 03:57:30PM +0300, Adrian Hunter wrote:
> >>>> On 8/08/19 3:42 PM, Ludovic Desroches wrote:
> >>>>> On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
> >>>>>> From: Eugen Hristev <[email protected]>
> >>>>>>
> >>>>>> Add mmc capabilities for SDMMC0 for this board.
> >>>>>> With this enabled, eMMC connected card is detected as:
> >>>>>>
> >>>>>> mmc0: new DDR MMC card at address 0001
> >>>>>>
> >>>>>> Signed-off-by: Eugen Hristev <[email protected]>
> >>>>> Acked-by: Ludovic Desroches <[email protected]>
> >>>>>
> >>>>> I am interested to have the some insights about the use of sd-uhs-*
> >>>>> properties.
> >>>>>
> >>>>> Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can
> >>>>> be used as the logic control input of a mux. So even if the IP claims
> >>>>> to support UHS modes, it depends on the board.
> >>>>>
> >>>>> Are the sd-uhs-* properties a way to deal with this? I tend to think no
> >>>>> as sdhci_setup_host() will set the caps depending on the content of the
> >>>>> capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS
> >>>>> quirk or sdhci-caps/sdhci-caps-mask?
> >>>>
> >>>> There is "no-1-8-v" which it looks like sdhci-of-at91.c already supports:
> >>>>
> >>>> sdhci_at91_probe() -> sdhci_get_of_property() -> sdhci_get_property()
> >>>>
> >>>> if (device_property_present(dev, "no-1-8-v"))
> >>>> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
> >>>>
> >>>
> >>> Right, I forgot this property. Thanks.
> >>>
> >>> Eugen, do you see cases we can't cover with this property?
> >>
> >> Hi,
> >>
> >> For current requirements and driver support, this should be enough.
> >>
> >> I noticed one thing regarding SD-Cards, if I add property sd-uhs-sdr104
> >> the class 10 uhs1 cards are detected as SDR104 . Without this property
> >> they are detected as DDR50. Any idea why the difference ? The controller
> >> does not claim to have SDR104 support ? We should add it ?
> >
> > With the mainline, our tree or both? In our tree, SDR104 is removed from
> > the capabilities.
> >
> > Ludovic
> >
>
>
> Hello Alexandre,
>
> Anything more needed regarding this patch ?
>
I was not sure it was applicable, seeing the discussion. I'll apply it
now.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com