mbox series

[v4,00/12] mmc: sdhci-omap: Add UHS/HS200 mode support

Message ID 20180425120937.29867-1-kishon@ti.com
Headers show
Series mmc: sdhci-omap: Add UHS/HS200 mode support | expand

Message

Kishon Vijay Abraham I April 25, 2018, 12:09 p.m. UTC 
Add UHS/HS200 mode support in sdhci-omap. The programming sequence
for voltage switching, tuning is followed from AM572x TRM
http://www.ti.com/lit/ug/spruhz6j/spruhz6j.pdf
(Similar to all AM57x/DRA7x SoCs). The patch series also implements
workaround for errata published in
http://www.ti.com/lit/er/sprz429l/sprz429l.pdf

patches are created on top of
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next

Changes from v3:
*) Fixed Adrian's comment on error handling when __sdhci_add_host()
   fails
*) Used Adrian's patches for programming SW timeout value.

Changes from v2:
*) Patches in v2 already applied to mmc -next are dropped from the
   series.
*) Changed SW timeout logic as per Adrians's suggestion
*) Validated SDIO with the current patches (added a couple of fixes
   found while adding SDIO support).
*) Used soc_device_match() instead of pdata-quirks as per Tony's
   suggestions.

Changes from v1:
*) Only poll on DAT0 and DATI for card_busy status
*) Cleanup iodelay patch as suggested by Tony.
*) Added quirk to disable HW timeout
*) Use the existing data timer but program a relatively accurate
   SW timeout value (Impacts all platforms)
*) Fix a bug in sdhci which was using data_timer for non data line
   commands

Adrian Hunter (2):
  mmc: sdhci: Add quirk to disable HW timeout
  mmc: sdhci: Factor out target_timeout calculation

Kishon Vijay Abraham I (10):
  mmc: sdhci-omap: Fix when capabilities are obtained from
    SDHCI_CAPABILITIES reg
  mmc: sdhci-omap: Remove setting ADMA capability in driver
  mmc: sdhci-omap: Workaround for Errata i843
  mmc: sdhci-omap: Invoke sdhci_get_of_property to read sdhci dt
    properties
  mmc: sdhci: Disable HS200 mode if controller can't support 1.8v
  mmc: sdhci: Program a relatively accurate SW timeout value
  mmc: sdhci-omap: Workaround for Errata i834
  dt-bindings: sdhci-omap: Add K2G specific binding
  mmc: sdhci-omap: Add support for MMC/SD controller in k2g SoC
  mmc: sdhci-omap: Add sdhci_omap specific ops for enable_sdio_irq

 .../devicetree/bindings/mmc/sdhci-omap.txt    |   2 +
 drivers/mmc/host/sdhci-omap.c                 |  81 ++++++++++--
 drivers/mmc/host/sdhci.c                      | 123 ++++++++++++++----
 drivers/mmc/host/sdhci.h                      |  15 +++
 include/linux/mmc/host.h                      |   1 +
 5 files changed, 191 insertions(+), 31 deletions(-)

-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Kishon Vijay Abraham I April 26, 2018, 10:08 a.m. UTC | #1 
Hi Adrian,

On Thursday 26 April 2018 02:25 PM, Adrian Hunter wrote:
> On 25/04/18 15:09, Kishon Vijay Abraham I wrote:

>> Though MMC controller can indicate HS200/HS400 mode capability (by

>> using "mmc-hs200-1_8v"/"mmc-hs400-1_8v" dt property), if the IO lines

>> in the board is connected to 3.3v supply, HS200/HS400 mode cannot be

>> supported. Such boards have "no-1-8-v" property in their dts file.

>> Disable HS200/HS400 mode for boards which have "no-1-8-v" set.

>>

>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

>> Acked-by: Tony Lindgren <tony@atomide.com>

>> ---

>>  drivers/mmc/host/sdhci.c | 1 +

>>  include/linux/mmc/host.h | 1 +

>>  2 files changed, 2 insertions(+)

>>

>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c

>> index 2ededa7f43df..b5f047b5f3ae 100644

>> --- a/drivers/mmc/host/sdhci.c

>> +++ b/drivers/mmc/host/sdhci.c

>> @@ -3672,6 +3672,7 @@ int sdhci_setup_host(struct sdhci_host *host)

>>  	if (host->quirks2 & SDHCI_QUIRK2_NO_1_8_V) {

>>  		host->caps1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |

>>  				 SDHCI_SUPPORT_DDR50);

>> +		mmc->caps2 &= ~MMC_CAP2_HSX00_1_8V;

> 

> Seems weird for sdhci to clear flags it never set.  Also couldn't we

> reasonably expect dt properties to be consistent?  Is this really about

> setting SDHCI_QUIRK2_NO_1_8_V in your driver and expecting it to override

> other dt properties?  Although that still begs the question why anyone would

> set dt properties that the hardware doesn't support?  I guess you should

> also clear MMC_CAP2_HS400_ES.


The SoC might support a specific mode like HS200. So the SoC specific dtsi file
might have dt properties for HS200 mode set. But the board which uses the SoC
might be modeled in a way a particular mode cannot be used (like IO lines not
connected to 1.8v). One option is to use /delete-property/ in the board dts
file. But since "no-1-8-v" property already indicates HS200 mode cannot be
supported, having a /delete-property/ might be redundant.

I can reset caps2 in sdhci-omap after invoking mmc_of_parse if you feel that
makes more sense.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Adrian Hunter April 26, 2018, 10:40 a.m. UTC | #2 
On 26/04/18 13:08, Kishon Vijay Abraham I wrote:
> Hi Adrian,

> 

> On Thursday 26 April 2018 02:25 PM, Adrian Hunter wrote:

>> On 25/04/18 15:09, Kishon Vijay Abraham I wrote:

>>> Though MMC controller can indicate HS200/HS400 mode capability (by

>>> using "mmc-hs200-1_8v"/"mmc-hs400-1_8v" dt property), if the IO lines

>>> in the board is connected to 3.3v supply, HS200/HS400 mode cannot be

>>> supported. Such boards have "no-1-8-v" property in their dts file.

>>> Disable HS200/HS400 mode for boards which have "no-1-8-v" set.

>>>

>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

>>> Acked-by: Tony Lindgren <tony@atomide.com>

>>> ---

>>>  drivers/mmc/host/sdhci.c | 1 +

>>>  include/linux/mmc/host.h | 1 +

>>>  2 files changed, 2 insertions(+)

>>>

>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c

>>> index 2ededa7f43df..b5f047b5f3ae 100644

>>> --- a/drivers/mmc/host/sdhci.c

>>> +++ b/drivers/mmc/host/sdhci.c

>>> @@ -3672,6 +3672,7 @@ int sdhci_setup_host(struct sdhci_host *host)

>>>  	if (host->quirks2 & SDHCI_QUIRK2_NO_1_8_V) {

>>>  		host->caps1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |

>>>  				 SDHCI_SUPPORT_DDR50);

>>> +		mmc->caps2 &= ~MMC_CAP2_HSX00_1_8V;

>>

>> Seems weird for sdhci to clear flags it never set.  Also couldn't we

>> reasonably expect dt properties to be consistent?  Is this really about

>> setting SDHCI_QUIRK2_NO_1_8_V in your driver and expecting it to override

>> other dt properties?  Although that still begs the question why anyone would

>> set dt properties that the hardware doesn't support?  I guess you should

>> also clear MMC_CAP2_HS400_ES.

> 

> The SoC might support a specific mode like HS200. So the SoC specific dtsi file

> might have dt properties for HS200 mode set. But the board which uses the SoC

> might be modeled in a way a particular mode cannot be used (like IO lines not

> connected to 1.8v). One option is to use /delete-property/ in the board dts

> file. But since "no-1-8-v" property already indicates HS200 mode cannot be

> supported, having a /delete-property/ might be redundant.

> 

> I can reset caps2 in sdhci-omap after invoking mmc_of_parse if you feel that

> makes more sense.


Just add the explanation to the commit message, add a comment to the code,
and also clear MMC_CAP_1_8V_DDR and MMC_CAP2_HS400_ES and MMC_CAP_UHS_*.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html