Skip to contentSkip to conversation

mmc: sdhci-s3c: Add device tree support for Samsung's sdhci controller driver

PATCH New Thomas Abraham 3 participants 10 messages Oct 5, 2011 – Oct 11, 2011

Subsystems (5)
lore
Share & tools
lore
#0 lore raw

cover mmc: sdhci-s3c: Add device tree support for Samsung's sdhci controller driver

This patchset adds device tree support for Samsung's sdhci controller driver.

The first patch modifies the sdhcis-s3c driver to mainatain a local copy of the platform data, which makes it easier to add device tree support for the driver.

The second patch adds support for parsing of mmc host controller capabilities from a device node. This code would be reusable across other platforms as well. The third patch device tree based discovery for the sdhci-s3c driver.

This patchset is based on the following tree:
https://github.com/kgene/linux-samsung.git branch: for-next and tested on smdkv310 board.

Thomas Abraham (3):
mmc: sdhci-s3c: Keep a copy of platform data and use it
mmc: Add OF bindings support for mmc host controller capabilities
mmc: sdhci-s3c: Add device tree support

 .../devicetree/bindings/mmc/linux-mmc-host.txt     |   11 ++
 .../devicetree/bindings/mmc/samsung-sdhci.txt      |   75 ++++++++++
 drivers/mmc/core/host.c                            |   31 ++++
 drivers/mmc/host/sdhci-s3c.c                       |  155 +++++++++++++++++++-
 include/linux/mmc/host.h                           |    3 +
 5 files changed, 270 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/linux-mmc-host.txt
 create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
#1 lore raw

PATCH 1/3 mmc: sdhci-s3c: Keep a copy of platform data and use it

The platform data is copied into driver's private data and the copy is used for all access to the platform data. This simpifies the addition of device tree support for the sdhci-s3c driver.

---
 drivers/mmc/host/sdhci-s3c.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)
drivers/mmc/host/sdhci-s3c.c +9 -2
index 871cf4f..8280af0 100644
@@ -424,7 +424,7 @@ static inline struct sdhci_s3c_drv_data *sdhci_s3c_get_driver_data(
 
 static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
 {
-	struct s3c_sdhci_platdata *pdata = pdev->dev.platform_data;
+	struct s3c_sdhci_platdata *pdata;
 	struct sdhci_s3c_drv_data *drv_data;
 	struct device *dev = &pdev->dev;
 	struct sdhci_host *host;
@@ -432,7 +432,7 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
 	struct resource *res;
 	int ret, irq, ptr, clks;
 
-	if (!pdata) {
+	if (!pdev->dev.platform_data) {
 		dev_err(dev, "no device data specified\n");
 		return -ENOENT;
 	}
@@ -455,6 +455,13 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
 		return PTR_ERR(host);
 	}
 
+	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata) {
+		ret = -ENOMEM;
+		goto err_io_clk;
+	}
+	memcpy(pdata, pdev->dev.platform_data, sizeof(*pdata));
+
 	drv_data = sdhci_s3c_get_driver_data(pdev);
 	sc = sdhci_priv(host);
 
Signature · 1 line
1.6.6.rc2
#2 lore raw

PATCH 2/3 mmc: Add OF bindings support for mmc host controller capabilities

In reply to Thomas Abraham

Device nodes representing sd/mmc controllers in a device tree would include mmc host controller capabilities. Add support for parsing of mmc host controller capabilities included in device nodes.

---
 .../devicetree/bindings/mmc/linux-mmc-host.txt     |   11 +++++++
 drivers/mmc/core/host.c                            |   31 ++++++++++++++++++++
 include/linux/mmc/host.h                           |    3 ++
 3 files changed, 45 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/linux-mmc-host.txt
Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file +11 -0
new file mode 100644
index 0000000..cb43905
@@ -0,0 +1,11 @@
+* Linux mmc host capabilities
+
+MMC Host Controller capabilities used in linux:
+- linux,mmc_cap_4_bit_data - host can do 4 bit transfers
+- linux,mmc_cap_mmc_highspeed - host can do MMC high-speed timing
+- linux,mmc_cap_sd_highspeed - host can do SD high-speed timing
+- linux,mmc_cap_needs_poll - host needs polling for card detection
+- linux,mmc_cap_8_bit_data - host can do 8 bit transfer
+- linux,mmc_cap_disable - host can be disabled
+- linux,mmc_cap_nonremovable - host is connected to nonremovable media
+- linux,mmc_cap_erase - host allows erase/trim commands
drivers/mmc/core/host.c +31 -0
index 793d0a0..4ee2e43 100644
@@ -19,6 +19,7 @@
 #include <linux/leds.h>
 #include <linux/slab.h>
 #include <linux/suspend.h>
+#include <linux/of.h>
 
 #include <linux/mmc/host.h>
 #include <linux/mmc/card.h>
@@ -385,3 +386,33 @@ void mmc_free_host(struct mmc_host *host)
 }
 
 EXPORT_SYMBOL(mmc_free_host);
+
+#ifdef CONFIG_OF
+/**
+ *	mmc_of_parse_host_caps - parse mmc host capabilities from device node
+ *	@np: pointer to device node in device tree
+ *	@caps: pointer to host caps value to be returned
+ *
+ *	Search the device node in device tree for mmc host capabilities.
+ */
+void mmc_of_parse_host_caps(struct device_node *np, unsigned long *caps)
+{
+	if (of_find_property(np, "linux,mmc_cap_4_bit_data", NULL))
+		*caps |= MMC_CAP_4_BIT_DATA;
+	if (of_find_property(np, "linux,mmc_cap_mmc_highspeed", NULL))
+		*caps |= MMC_CAP_MMC_HIGHSPEED;
+	if (of_find_property(np, "linux,mmc_cap_sd_highspeed", NULL))
+		*caps |= MMC_CAP_SD_HIGHSPEED;
+	if (of_find_property(np, "linux,mmc_cap_needs_poll", NULL))
+		*caps |= MMC_CAP_NEEDS_POLL;
+	if (of_find_property(np, "linux,mmc_cap_8_bit_data", NULL))
+		*caps |= MMC_CAP_8_BIT_DATA;
+	if (of_find_property(np, "linux,mmc_cap_disable", NULL))
+		*caps |= MMC_CAP_DISABLE;
+	if (of_find_property(np, "linux,mmc_cap_nonremovable", NULL))
+		*caps |= MMC_CAP_NONREMOVABLE;
+	if (of_find_property(np, "linux,mmc_cap_erase", NULL))
+		*caps |= MMC_CAP_ERASE;
+}
+EXPORT_SYMBOL(mmc_of_parse_host_caps);
+#endif /* CONFIG_OF */
include/linux/mmc/host.h +3 -0
index 1d09562..72b5df2 100644
@@ -309,6 +309,9 @@ extern struct mmc_host *mmc_alloc_host(int extra, struct device *);
 extern int mmc_add_host(struct mmc_host *);
 extern void mmc_remove_host(struct mmc_host *);
 extern void mmc_free_host(struct mmc_host *);
+#ifdef CONFIG_OF
+extern void mmc_of_parse_host_caps(struct device_node *np, unsigned long *caps);
+#endif
 
 static inline void *mmc_priv(struct mmc_host *host)
 {
Signature · 1 line
1.6.6.rc2
#3 lore raw

PATCH 2/3 mmc: Add OF bindings support for mmc host controller capabilities

Thomas,

Quoted 18 lines · Thomas Abraham

Device nodes representing sd/mmc controllers in a device tree would include mmc host controller capabilities. Add support for parsing of mmc host controller capabilities included in device nodes.

---
 .../devicetree/bindings/mmc/linux-mmc-host.txt     |   11 +++++++
 drivers/mmc/core/host.c                            |   31 ++++++++++++++++++++
 include/linux/mmc/host.h                           |    3 ++
 3 files changed, 45 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/linux-mmc-host.txt
Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file +0 -0
new file mode 100644
index 0000000..cb43905

Documentation/devicetree/bindings/mmc/linux-mmc-host.txt line 3

Quoted 3 lines
Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file +3 -0
@@ -0,0 +1,11 @@
+* Linux mmc host capabilities
+
+MMC Host Controller capabilities used in linux:

These aren't really linux properties... Is the capabilities register really this broken that all these are needed? If so, perhaps just a straight caps register value to override with would be better.

Documentation/devicetree/bindings/mmc/linux-mmc-host.txt line 8

Quoted 5 lines
Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file +5 -0
+- linux,mmc_cap_4_bit_data - host can do 4 bit transfers
+- linux,mmc_cap_mmc_highspeed - host can do MMC high-speed timing
+- linux,mmc_cap_sd_highspeed - host can do SD high-speed timing
+- linux,mmc_cap_needs_poll - host needs polling for card detection
+- linux,mmc_cap_8_bit_data - host can do 8 bit transfer

"sdhci,1-bit-only" already exists as a binding. Perhaps add "sdhci,4-bit-only". No property then means can do 8-bit.

Documentation/devicetree/bindings/mmc/linux-mmc-host.txt line 9

Quoted 1 line
Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file +1 -0
+- linux,mmc_cap_disable - host can be disabled

What?

Documentation/devicetree/bindings/mmc/linux-mmc-host.txt line 11

Quoted 2 lines
Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file +2 -0
+- linux,mmc_cap_nonremovable - host is connected to nonremovable media
+- linux,mmc_cap_erase - host allows erase/trim commands

Isn't TRIM a card property and transparent to the host controller?

Quoted 51 lines
drivers/mmc/core/host.c +31 -0
index 793d0a0..4ee2e43 100644
@@ -19,6 +19,7 @@
 #include <linux/leds.h>
 #include <linux/slab.h>
 #include <linux/suspend.h>
+#include <linux/of.h>
 
 #include <linux/mmc/host.h>
 #include <linux/mmc/card.h>
@@ -385,3 +386,33 @@ void mmc_free_host(struct mmc_host *host)
 }
 
 EXPORT_SYMBOL(mmc_free_host);
+
+#ifdef CONFIG_OF
+/**
+ *	mmc_of_parse_host_caps - parse mmc host capabilities from device node
+ *	@np: pointer to device node in device tree
+ *	@caps: pointer to host caps value to be returned
+ *
+ *	Search the device node in device tree for mmc host capabilities.
+ */
+void mmc_of_parse_host_caps(struct device_node *np, unsigned long *caps)
+{
+	if (of_find_property(np, "linux,mmc_cap_4_bit_data", NULL))
+		*caps |= MMC_CAP_4_BIT_DATA;
+	if (of_find_property(np, "linux,mmc_cap_mmc_highspeed", NULL))
+		*caps |= MMC_CAP_MMC_HIGHSPEED;
+	if (of_find_property(np, "linux,mmc_cap_sd_highspeed", NULL))
+		*caps |= MMC_CAP_SD_HIGHSPEED;
+	if (of_find_property(np, "linux,mmc_cap_needs_poll", NULL))
+		*caps |= MMC_CAP_NEEDS_POLL;
+	if (of_find_property(np, "linux,mmc_cap_8_bit_data", NULL))
+		*caps |= MMC_CAP_8_BIT_DATA;
+	if (of_find_property(np, "linux,mmc_cap_disable", NULL))
+		*caps |= MMC_CAP_DISABLE;
+	if (of_find_property(np, "linux,mmc_cap_nonremovable", NULL))
+		*caps |= MMC_CAP_NONREMOVABLE;
+	if (of_find_property(np, "linux,mmc_cap_erase", NULL))
+		*caps |= MMC_CAP_ERASE;
+}
+EXPORT_SYMBOL(mmc_of_parse_host_caps);
+#endif /* CONFIG_OF */
include/linux/mmc/host.h +0 -0
index 1d09562..72b5df2 100644

include/linux/mmc/host.h extern struct mmc_host *mmc_alloc_host(int extra, struct device *); · line 314

Quoted 6 lines
include/linux/mmc/host.h +3 -0
@@ -309,6 +309,9 @@ extern struct mmc_host *mmc_alloc_host(int extra, struct device *);
 extern int mmc_add_host(struct mmc_host *);
 extern void mmc_remove_host(struct mmc_host *);
 extern void mmc_free_host(struct mmc_host *);
+#ifdef CONFIG_OF
+extern void mmc_of_parse_host_caps(struct device_node *np, unsigned long *caps);
+#endif

You don't need a ifdef around this.

Rob

#4 lore raw

PATCH 2/3 mmc: Add OF bindings support for mmc host controller capabilities

Hi Rob,

Quoted 15 lines · Rob Herring

Thomas,

Quoted 12 lines · Thomas Abraham

Device nodes representing sd/mmc controllers in a device tree would include mmc host controller capabilities. Add support for parsing of mmc host controller capabilities included in device nodes.

---

?.../devicetree/bindings/mmc/linux-mmc-host.txt ? ? | ? 11 +++++++
?drivers/mmc/core/host.c ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 31 ++++++++++++++++++++
?include/linux/mmc/host.h ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?3 ++

?3 files changed, 45 insertions(+), 0 deletions(-)
?create mode 100644 Documentation/devicetree/bindings/mmc/linux-mmc-host.txt

Quoted 13 lines

Documentation/devicetree/bindings/mmc/linux-mmc-host.txt line 3

Quoted 9 lines
Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file +3 -0
new file mode 100644
index 0000000..cb43905
@@ -0,0 +1,11 @@
+* Linux mmc host capabilities
+
+MMC Host Controller capabilities used in linux:

These aren't really linux properties... Is the capabilities register really this broken that all these are needed? If so, perhaps just a straight caps register value to override with would be better.

I was trying to provide bindings for the MMC_CAP_XXX defined in include/linux/mmc/host.h file. I am no expert in mmc subsystem but I believe that these capabilities are not directly mapped to any capabilities register in the host controller hardware. All of the MMC_CAP_XXX defines are flags used by the mmc core to make runtime decisions. The host controller driver would read its capability register and report its capabilities to the mmc core layer using these MMC_CAP_XXX defines.

But not all of the MMC_CAP_XXX defines can be derived from a capabilities register of a host controller. Some of the MMC_CAP_XXX capabilities are used as defaults by the host controller driver while some others which are board dependent are feed to the host controller driver using the platform data.

While migrating a host controller driver to device tree, and not relying on the aux data for platform data, there has to be mechanism to specify the mmc core subsystem capabilities which are board specific and I though bindings for MMC_CAP_XXX could be an option.

Quoted 9 lines

Documentation/devicetree/bindings/mmc/linux-mmc-host.txt line 8

Quoted 6 lines
Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file +5 -0
+- linux,mmc_cap_4_bit_data - host can do 4 bit transfers
+- linux,mmc_cap_mmc_highspeed - host can do MMC high-speed timing
+- linux,mmc_cap_sd_highspeed - host can do SD high-speed timing
+- linux,mmc_cap_needs_poll - host needs polling for card detection
+- linux,mmc_cap_8_bit_data - host can do 8 bit transfer

"sdhci,1-bit-only" already exists as a binding. Perhaps add "sdhci,4-bit-only". No property then means can do 8-bit.

Ok. But that would remain just as sdhci host controller capability and will not be applicable to other types of host controllers.

Quoted 4 lines

Documentation/devicetree/bindings/mmc/linux-mmc-host.txt line 9

Quoted 2 lines
Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file +1 -0
+- linux,mmc_cap_disable - host can be disabled

What?

Apologies. I will be more verbose next time.

Quoted 5 lines

Documentation/devicetree/bindings/mmc/linux-mmc-host.txt line 11

Quoted 3 lines
Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file +2 -0
+- linux,mmc_cap_nonremovable - host is connected to nonremovable media
+- linux,mmc_cap_erase - host allows erase/trim commands

Isn't TRIM a card property and transparent to the host controller?

I am not sure on this. Maybe it might have some dependency on the host controller as well.

Quoted 52 lines
Quoted 52 lines
drivers/mmc/core/host.c +0 -0
index 793d0a0..4ee2e43 100644
@@ -19,6 +19,7 @@

?#include <linux/leds.h>
?#include <linux/slab.h>
?#include <linux/suspend.h>
+#include <linux/of.h>

?#include <linux/mmc/host.h>
?#include <linux/mmc/card.h>

drivers/mmc/core/host.c +30 -0
@@ -385,3 +386,33 @@ void mmc_free_host(struct mmc_host *host)
 ?}
 
 ?EXPORT_SYMBOL(mmc_free_host);
+
+#ifdef CONFIG_OF
+/**
+ * ? mmc_of_parse_host_caps - parse mmc host capabilities from device node
+ * ? @np: pointer to device node in device tree
+ * ? @caps: pointer to host caps value to be returned
+ *
+ * ? Search the device node in device tree for mmc host capabilities.
+ */
+void mmc_of_parse_host_caps(struct device_node *np, unsigned long *caps)
+{
+ ? ? if (of_find_property(np, "linux,mmc_cap_4_bit_data", NULL))
+ ? ? ? ? ? ? *caps |= MMC_CAP_4_BIT_DATA;
+ ? ? if (of_find_property(np, "linux,mmc_cap_mmc_highspeed", NULL))
+ ? ? ? ? ? ? *caps |= MMC_CAP_MMC_HIGHSPEED;
+ ? ? if (of_find_property(np, "linux,mmc_cap_sd_highspeed", NULL))
+ ? ? ? ? ? ? *caps |= MMC_CAP_SD_HIGHSPEED;
+ ? ? if (of_find_property(np, "linux,mmc_cap_needs_poll", NULL))
+ ? ? ? ? ? ? *caps |= MMC_CAP_NEEDS_POLL;
+ ? ? if (of_find_property(np, "linux,mmc_cap_8_bit_data", NULL))
+ ? ? ? ? ? ? *caps |= MMC_CAP_8_BIT_DATA;
+ ? ? if (of_find_property(np, "linux,mmc_cap_disable", NULL))
+ ? ? ? ? ? ? *caps |= MMC_CAP_DISABLE;
+ ? ? if (of_find_property(np, "linux,mmc_cap_nonremovable", NULL))
+ ? ? ? ? ? ? *caps |= MMC_CAP_NONREMOVABLE;
+ ? ? if (of_find_property(np, "linux,mmc_cap_erase", NULL))
+ ? ? ? ? ? ? *caps |= MMC_CAP_ERASE;
+}
+EXPORT_SYMBOL(mmc_of_parse_host_caps);
+#endif /* CONFIG_OF */
include/linux/mmc/host.h +0 -0
index 1d09562..72b5df2 100644
@@ -309,6 +309,9 @@ extern struct mmc_host *mmc_alloc_host(int extra, struct device *);
Quoted 8 lines

include/linux/mmc/host.h extern struct mmc_host *mmc_alloc_host(int extra, struct device *); · line 314

Quoted 6 lines
include/linux/mmc/host.h +3 -0
 ?extern int mmc_add_host(struct mmc_host *);
 ?extern void mmc_remove_host(struct mmc_host *);
 ?extern void mmc_free_host(struct mmc_host *);
+#ifdef CONFIG_OF
+extern void mmc_of_parse_host_caps(struct device_node *np, unsigned long *caps);
+#endif

You don't need a ifdef around this.

Ok.

Quoted 3 lines

Rob

Thanks for your review.

Regards,
Thomas.

#5 lore raw

PATCH 2/3 mmc: Add OF bindings support for mmc host controller capabilities

Thomas Abraham wrote at Wednesday, October 05, 2011 8:28 AM:

Quoted 5 lines · Rob Herring
Quoted 4 lines · Thomas Abraham
Quoted 3 lines

Device nodes representing sd/mmc controllers in a device tree would include mmc host controller capabilities. Add support for parsing of mmc host controller capabilities included in device nodes.

...

Quoted 11 lines
Quoted 8 lines
Quoted 5 lines
+- linux,mmc_cap_4_bit_data - host can do 4 bit transfers
+- linux,mmc_cap_mmc_highspeed - host can do MMC high-speed timing
+- linux,mmc_cap_sd_highspeed - host can do SD high-speed timing
+- linux,mmc_cap_needs_poll - host needs polling for card detection
+- linux,mmc_cap_8_bit_data - host can do 8 bit transfer

"sdhci,1-bit-only" already exists as a binding. Perhaps add "sdhci,4-bit-only". No property then means can do 8-bit.

Ok. But that would remain just as sdhci host controller capability and will not be applicable to other types of host controllers.

Just as an FYI, NVIDIA's SDHCI controller bindings use property "support-8bit" to indicate 8-bit support. A similar property could be used for 4-bit support too.

Signature · 1 line
nvpublic
#6 lore raw

PATCH 2/3 mmc: Add OF bindings support for mmc host controller capabilities

Quoted 16 lines · Stephen Warren

Thomas Abraham wrote at Wednesday, October 05, 2011 8:28 AM:

Quoted 5 lines · Rob Herring
Quoted 4 lines · Thomas Abraham
Quoted 3 lines

Device nodes representing sd/mmc controllers in a device tree would include mmc host controller capabilities. Add support for parsing of mmc host controller capabilities included in device nodes.

...

Quoted 9 lines
Quoted 8 lines
Quoted 5 lines
+- linux,mmc_cap_4_bit_data - host can do 4 bit transfers
+- linux,mmc_cap_mmc_highspeed - host can do MMC high-speed timing
+- linux,mmc_cap_sd_highspeed - host can do SD high-speed timing
+- linux,mmc_cap_needs_poll - host needs polling for card detection
+- linux,mmc_cap_8_bit_data - host can do 8 bit transfer

"sdhci,1-bit-only" already exists as a binding. Perhaps add "sdhci,4-bit-only". No property then means can do 8-bit.

Quoted 6 lines
Quoted 2 lines

Ok. But that would remain just as sdhci host controller capability and will not be applicable to other types of host controllers.

Just as an FYI, NVIDIA's SDHCI controller bindings use property "support-8bit" to indicate 8-bit support. A similar property could be used for 4-bit support too.

In this case, the binding would be applicable only to nVidia's SDHCI controller. And this binding would select MMC_CAP_8_BIT_DATA in the sdhci-tegra driver. There are sdhci drivers that can accept host capabilities via platform data.

The MMC_CAP_XXX macros in linux/mmc/host.h file are usuable across host controllers and some of them are supplied as platform data for non-device tree platforms.

So, bindings for MMC_CAP_XXX macros can be defined which any host controller supporting device tree could use. Host controllers could use the mmc_of_parse_host_caps() helper function (listed in this patch) to parse all the bindings for MMC_CAP_XXX available in the device node.

I would like to retain this patch in this series but if there is a definite no, then I will drop it. Please let me know your opinion.

Thanks,
Thomas.

Quoted 5 lines

--
nvpublic

#7 lore raw

PATCH 2/3 mmc: Add OF bindings support for mmc host controller capabilities

Thomas Abraham wrote at Sunday, October 09, 2011 12:58 AM:

Quoted 20 lines · Stephen Warren
Quoted 19 lines

Thomas Abraham wrote at Wednesday, October 05, 2011 8:28 AM:

Quoted 5 lines · Rob Herring
Quoted 4 lines · Thomas Abraham
Quoted 3 lines

Device nodes representing sd/mmc controllers in a device tree would include mmc host controller capabilities. Add support for parsing of mmc host controller capabilities included in device nodes.

...

Quoted 11 lines
Quoted 8 lines
Quoted 5 lines
+- linux,mmc_cap_4_bit_data - host can do 4 bit transfers
+- linux,mmc_cap_mmc_highspeed - host can do MMC high-speed timing
+- linux,mmc_cap_sd_highspeed - host can do SD high-speed timing
+- linux,mmc_cap_needs_poll - host needs polling for card detection
+- linux,mmc_cap_8_bit_data - host can do 8 bit transfer

"sdhci,1-bit-only" already exists as a binding. Perhaps add "sdhci,4-bit-only". No property then means can do 8-bit.

Ok. But that would remain just as sdhci host controller capability and will not be applicable to other types of host controllers.

Quoted 6 lines
Quoted 3 lines

Just as an FYI, NVIDIA's SDHCI controller bindings use property "support-8bit" to indicate 8-bit support. A similar property could be used for 4-bit support too.

In this case, the binding would be applicable only to nVidia's SDHCI controller.

Sure, this is the case right now. And I thought I'd copied this property name from some other driver, but it looks like I'm mistaken.

Quoted 8 lines

And this binding would select MMC_CAP_8_BIT_DATA in the sdhci-tegra driver. There are sdhci drivers that can accept host capabilities via platform data.

The MMC_CAP_XXX macros in linux/mmc/host.h file are usuable across host controllers and some of them are supplied as platform data for non-device tree platforms.

Quoted 8 lines

So, bindings for MMC_CAP_XXX macros can be defined which any host controller supporting device tree could use. Host controllers could use the mmc_of_parse_host_caps() helper function (listed in this patch) to parse all the bindings for MMC_CAP_XXX available in the device node.

I would like to retain this patch in this series but if there is a definite no, then I will drop it. Please let me know your opinion.

I was simply pointing out that there are already some properties in this area. It'd be nice if we could unify everything on a single style; either expanding the existing "sdhci,1-bit-only" style that Rob mentioned, or expanding the "support-8bit" style that Tegra currently uses, rather than adding a third way of indicating this. Still, given the early state of DT on Tegra, I'd be happy migrating Tegra to whatever single unified approach is chosen, so don't take my comments as nak'ing your patch or anything like that.

Signature · 1 line
nvpublic
#8 lore raw

PATCH 2/3 mmc: Add OF bindings support for mmc host controller capabilities

Quoted 48 lines · Stephen Warren

Thomas Abraham wrote at Sunday, October 09, 2011 12:58 AM:

Quoted 20 lines · Stephen Warren
Quoted 19 lines

Thomas Abraham wrote at Wednesday, October 05, 2011 8:28 AM:

Quoted 5 lines · Rob Herring
Quoted 4 lines · Thomas Abraham
Quoted 3 lines

Device nodes representing sd/mmc controllers in a device tree would include mmc host controller capabilities. Add support for parsing of mmc host controller capabilities included in device nodes.

...

Quoted 11 lines
Quoted 8 lines
Quoted 5 lines
+- linux,mmc_cap_4_bit_data - host can do 4 bit transfers
+- linux,mmc_cap_mmc_highspeed - host can do MMC high-speed timing
+- linux,mmc_cap_sd_highspeed - host can do SD high-speed timing
+- linux,mmc_cap_needs_poll - host needs polling for card detection
+- linux,mmc_cap_8_bit_data - host can do 8 bit transfer

"sdhci,1-bit-only" already exists as a binding. Perhaps add "sdhci,4-bit-only". No property then means can do 8-bit.

Ok. But that would remain just as sdhci host controller capability and will not be applicable to other types of host controllers.

Quoted 6 lines
Quoted 3 lines

Just as an FYI, NVIDIA's SDHCI controller bindings use property "support-8bit" to indicate 8-bit support. A similar property could be used for 4-bit support too.

In this case, the binding would be applicable only to nVidia's SDHCI controller.

Sure, this is the case right now. And I thought I'd copied this property name from some other driver, but it looks like I'm mistaken.

Quoted 8 lines

And this binding would select MMC_CAP_8_BIT_DATA in the sdhci-tegra driver. There are sdhci drivers that can accept host capabilities via platform data.

The MMC_CAP_XXX macros in linux/mmc/host.h file are usuable across host controllers and some of them are supplied as platform data for non-device tree platforms.

Quoted 8 lines

So, bindings for MMC_CAP_XXX macros can be defined which any host controller supporting device tree could use. Host controllers could use the mmc_of_parse_host_caps() helper function (listed in this patch) to parse all the bindings for MMC_CAP_XXX ?available in the device node.

I would like to retain this patch in this series but if there is a definite no, then I will drop it. Please let me know your opinion.

Quoted 8 lines

I was simply pointing out that there are already some properties in this area. It'd be nice if we could unify everything on a single style; either expanding the existing "sdhci,1-bit-only" style that Rob mentioned, or expanding the "support-8bit" style that Tegra currently uses, rather than adding a third way of indicating this. Still, given the early state of DT on Tegra, I'd be happy migrating Tegra to whatever single unified approach is chosen, so don't take my comments as nak'ing your patch or anything like that.

Ok.

The sdhci bus width binding is an example that can be extended as you have suggested. If done this way, the sdhci bus width bindings would be converted by the driver to either of MMC_CAP_[4/8]_BIT_DATA capability.

But there are other MMC_CAP_XXX values as well which the host controller driver needs to report to the upper mmc core layer. Some of these capabilities are determined by reading caps register of the host controller and converting them to equivalent MMC_CAP_XXX flags. But some of them are board dependent such as

MMC_CAP_NEEDS_POLL,
MMC_CAP_DISABLE,
MMC_CAP_NONREMOVABLE,
MMC_CAP_POWER_OFF_CARD and others.

These flags which are tied to the characteristics of the board is usually supplied using platform data. The driver picks up these from platform data, adds its own set of CAP's and reports to the upper layer.

When we do not have platform data (as in the case of dt), there could be two options to bind these CAP's. Either define custom bindings for these and then translate them in each host controller driver using them or provide direct bindings for MMC_CAP_xxx with a common function to parse them. I tend towards direct bindings for MMC_CAP_XXX because it can be used by any type of mmc/sd host controller and not just sdhci controller and provides common binding for all host controllers.

Thanks for your comments.

Regards,
Thomas.

Quoted 5 lines

--
nvpublic

#9 lore raw

PATCH 3/3 mmc: sdhci-s3c: Add device tree support

In reply to Thomas Abraham

Add device tree based discovery support for Samsung's sdhci controller

---
 .../devicetree/bindings/mmc/samsung-sdhci.txt      |   75 ++++++++++
 drivers/mmc/host/sdhci-s3c.c                       |  150 +++++++++++++++++++-
 2 files changed, 219 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
Documentation/devicetree/bindings/mmc/samsung-sdhci.txt new file +75 -0
new file mode 100644
index 0000000..dc94d24
@@ -0,0 +1,75 @@
+* Samsung's SDHCI Controller device tree bindings
+
+Samsung's SDHCI controller is used as a connectivity interface with external
+MMC, SD and eMMC storage mediums.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+  - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
+    controller.
+  - "samsung,exynos4-sdhci": For controller compatible with Exynos4 sdhci
+    controller.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- interrupts: The interrupt number to the cpu. The interrupt specifier format
+  depends on the interrupt controller.
+
+
+Required Board Specific Properties:
+- gpios: Should specify the gpios used for clock, command and data lines. The
+  gpio specifier format depends on the gpio controller. Note: There is no
+  particular order in which the gpio's have to be listed.
+
+
+Optional Board Specific Properties:
+- samsung,sdhci-bus-width: Number of data lines connected to the controller.
+  Note: This excludes the clock,command and card detect lines. If this property
+  is not specified, default value is 1.
+
+- samsung,cd-gpio-invert: If 'samsung,sdhci-cd-gpio' card detect method is
+  selected, this property can be optionally specified to invert the value of
+  external card detect gpio line.
+
+- One of the following properties for card detect type.
+  - samsung,sdhci-cd-internal: Card detect line from the card slot  is
+    connected to the card detect pad of the sdhci controller. A gpio is
+    used for this connection (with possible pin function settings).
+  - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
+    is used a card detect line. This gpio line is not connected to card detect
+    pad of the sdhci controller.
+  - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
+    detect the presence of the card. (DEFAULT, if no card detect property
+    is specified).
+  - samsung,sdhci-cd-permanent: There is no card detect line. The card is
+    permanently connected to the sdhci controller.
+
+- gpio-cd: The gpio to be used as card detect line for
+  'samsung,sdhci-cd-internal' or 'samsung,sdhci-cd-gpio' card detection method.
+  The gpio specifier format depends on the gpio controller.
+
+- One or more of the linux specific mmc host bindings.
+  See Documentation/devicetree/bindings/mmc/linux-mmc-host.txt for all the
+  linux mmc host controller specific bindings.
+
+Example:
+	sdhci at 12530000 {
+		compatible = "samsung,exynos4-sdhci";
+		reg = <0x12530000 0x100>;
+		interrupts = <139>;
+		samsung,sdhci-bus-width = <4>;
+		linux,mmc_cap_4_bit_data;
+		samsung,sdhci-cd-internal;
+		gpio-cd = <&gpk2 2 2 3 3>;
+		gpios = <&gpk2 0 2 0 3>,  /* clock line */
+			<&gpk2 1 2 0 3>,  /* command line */
+			<&gpk2 3 2 3 3>,  /* data line 0 */
+			<&gpk2 4 2 3 3>,  /* data line 1 */
+			<&gpk2 5 2 3 3>,  /* data line 2 */
+			<&gpk2 6 2 3 3>;  /* data line 3 */
+	};
+
+	Note: This example shows both SoC specific and board specific properties
+	in a single device node. The properties can be actually be seperated
+	into SoC specific node and board specific node.
drivers/mmc/host/sdhci-s3c.c +144 -6

235 lines not on this page · raw message

Signature · 1 line
1.6.6.rc2