omap hsmmc device tree support
Subsystems (6)
cover omap hsmmc device tree support
This series adds device tree support for omap hsmmc driver. The series is currently based on my patch series[1] to add dt support for twl-regulators, since hsmmc requires regulators to work.
I have also pulled the patch from Thomas Abraham which adds mmc host controller bindings[2]
'mmc: Add OF bindings support for mmc host controller capabilities'
The series currently adds supports for only omap4-panda and omap4-sdp boards and uses auxdata to pass platform specific function pointers to the driver.
All the dependent patches along with this series can be found heregit://gitorious.org/omap-pm/linux.git for-dt/regulator-i2c-twl-mmc
regards,
Rajendra
[1] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-October/009185.html
[2] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-November/009237.html
Rajendra Nayak (4):
mmc: Add additional binding for mmc host controller
mmc: omap: adapt the hsmmc driver to device tree
omap4: mmc: Pass SoC and board data for omap4 mmc from dt
omap4: mmc: use auxdata to pass platform function ptrs
.../devicetree/bindings/mmc/linux-mmc-host.txt | 1 + .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 ++++++++ arch/arm/boot/dts/omap4-panda.dts | 23 ++++ arch/arm/boot/dts/omap4-sdp.dts | 33 +++++ arch/arm/boot/dts/omap4.dtsi | 46 +++++++ arch/arm/mach-omap2/board-generic.c | 19 +++- arch/arm/mach-omap2/hsmmc.c | 9 +- arch/arm/mach-omap2/hsmmc.h | 5 + drivers/mmc/core/host.c | 2 + drivers/mmc/host/omap_hsmmc.c | 125 ++++++++++++++++++++ 10 files changed, 307 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
PATCH 1/4 mmc: Add additional binding for mmc host controller
Add mmc host controller capability binding to support 'MMC_CAP_POWER_OFF_CARD' powering off of the card after boot.
--- .../devicetree/bindings/mmc/linux-mmc-host.txt | 1 + drivers/mmc/core/host.c | 2 ++ 2 files changed, 3 insertions(+), 0 deletions(-)
Documentation/devicetree/bindings/mmc/linux-mmc-host.txt +1 -0
@@ -11,3 +11,4 @@ specific mmc host controller capabilities. - linux,mmc_cap_disable - Host can be disabled and re-enabled to save power - linux,mmc_cap_nonremovable - Host is connected to nonremovable media - linux,mmc_cap_erase - Host allows erase/trim commands +- linux,mmc_cap_power_off_card - Host can power off the card after boot
drivers/mmc/core/host.c +2 -0
@@ -413,6 +413,8 @@ void mmc_of_parse_host_caps(struct device_node *np, unsigned long *caps) *caps |=MMC_CAP_NONREMOVABLE ;if (of_find_property (np,"linux,mmc_cap_erase" ,NULL )) *caps |=MMC_CAP_ERASE ; +if (of_find_property (np,"linux,mmc_cap_power_off_card" ,NULL )) + *caps |= MMC_CAP_POWER_OFF_CARD; }EXPORT_SYMBOL (mmc_of_parse_host_caps);#endif /* CONFIG_OF */
Signature · 1 line
1.7.1
PATCH 1/4 mmc: Add additional binding for mmc host controller
Quoted 2 lines · Rajendra Nayak
Add mmc host controller capability binding to support '
MMC_CAP_POWER_OFF_CARD' powering off of the card after boot.
This adds a new undocumented property (also, see comments on Thomas Abraham's patch for more comments on that approach and why it's the wrong thing to do).
This needs to be handled differently.
-Olof
PATCH 2/4 mmc: omap: adapt the hsmmc driver to device tree
In reply to Rajendra NayakDefine dt bindings for the ti-omap-hsmmc, and adapt the driver to extract data (which was earlier passed as platform_data) from device tree node.
--- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 +++++++++ drivers/mmc/host/omap_hsmmc.c | 117 ++++++++++++++++++++ 2 files changed, 167 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +50 -0
@@ -0,0 +1,50 @@ +* TI Highspeed MMC host controller for OMAP + +The Highspeed MMC Host Controller on TI OMAP family +provides an interface for MMC, SD, and SDIO types of memory cards. + +Required properties: +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc"; +n is controller instance starting 0, for OMAP2/3 controllers +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc"; +n is controller instance starting 0, for OMAP4 controllers +- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1 +- reg : should contain hsmmc registers location and length + +Optional properties: +ti,hsmmc-supports-dual-volt: boolean, supports dual voltage cards +ti,hsmmc-nr-slots: Number of mmc slots +<supply-name>-supply: phandle to the regulator device tree node +"supply-name" examples are "vmmc", "vmmc_aux" etc +ti,hsmmc-has-pbias: Has PBIAS cell support +ti,hsmmc-has-special-reset: Requires a special softreset sequence + +For every supported slot a slot node can be defined +with the following optional properties + +ti,hsmmc-slot-name: Name assocaited to the mmc slot +ti,hsmmc-gpio-cd: gpio for card detect +ti,hsmmc-gpio-wp: gpio for write protect +ti,hsmmc-ocr-mask: mmc/sd/sdio ocr mask +ti,hsmmc-non-removable: non-removable slot (like eMMC) + +One or more of the linux specific mmc host bindings can also be used. +See Documentation/devicetree/bindings/mmc/linux-mmc-host.txt for all the +linux mmc host controller specific bindings. + +Example: + mmc1: mmc at 0x4809c000 { + compatible = "ti,omap-hsmmc0", "ti,omap4-hsmmc"; + reg = <0x4809c000 0x400>; + ti,hwmods = "mmc1"; + ti,hsmmc-supports-dual-volt; + ti,hsmmc-nr-slots = <1>; + vmmc-supply = <&vmmc>; /* phandle to regulator node */ + slot at 1 { + ti,hsmmc-slot-name = "wlan"; + linux,mmc_cap_4_bit_data; + linux,mmc_cap_power_off_card; + ti,hsmmc-ocr-mask = <0x80>; + ti,hsmmc-nonremovable; + }; + };
drivers/mmc/host/omap_hsmmc.c +117 -0
159 lines not on this page · raw message
Signature · 1 line
1.7.1
PATCH 2/4 mmc: omap: adapt the hsmmc driver to device tree
Quoted 17 lines · Rajendra Nayak
Define dt bindings for the ti-omap-hsmmc, and adapt the driver to extract data (which was earlier passed as
platform_data) from device tree node.Signed-off-by Rajendra Nayak <[email protected]>--- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 +++++++++ drivers/mmc/host/omap_hsmmc.c | 117 ++++++++++++++++++++ 2 files changed, 167 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txtDocumentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +0
-0
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 8
Quoted 8 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +8
-0@@ -0,0 +1,50 @@ +* TI Highspeed MMC host controller for OMAP + +The Highspeed MMC Host Controller on TI OMAP family +provides an interface for MMC, SD, and SDIO types of memory cards. + +Required properties: +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc"; +n is controller instance starting 0, for OMAP2/3 controllers
No, no, no. You should not have to specify the unit-address in the compatible field. They are all programmed the same way, right?
Also, they should go from the specific to the generic, but the first property is the same for 2/3 and 4. That's wrong.
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 11
Quoted 3 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +3
-0+- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc"; +n is controller instance starting 0, for OMAP4 controllers +- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
I didn't think hwmod bindings were settled on yet?
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 15
Quoted 4 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +4
-0+- reg : should contain hsmmc registers location and length + +Optional properties: +ti,hsmmc-supports-dual-volt: boolean, supports dual voltage cards
ti,dual-voltage is a better name here (by definition, if it has the property it supports it, the word "supports" is redundant).
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 16
Quoted 1 line
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +1
-0+ti,hsmmc-nr-slots: Number of mmc slots
You shouldn't have to specify this, it can be derived from the number of child nodes.
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 20
Quoted 4 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +4
-0+<supply-name>-supply: phandle to the regulator device tree node +"supply-name" examples are "vmmc", "vmmc_aux" etc +ti,hsmmc-has-pbias: Has PBIAS cell support +ti,hsmmc-has-special-reset: Requires a special softreset sequence
you can drop hsmmc- from the properties here
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 27
Quoted 7 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +7
-0+ +For every supported slot a slot node can be defined +with the following optional properties + +ti,hsmmc-slot-name: Name assocaited to the mmc slot +ti,hsmmc-gpio-cd: gpio for card detect +ti,hsmmc-gpio-wp: gpio for write protect
Please use the same standard as the other mmc controllers for CD/WP.
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 28
Quoted 1 line
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +1
-0+ti,hsmmc-ocr-mask: mmc/sd/sdio ocr mask
What is OCR mask?
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 29
Quoted 1 line
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +1
-0+ti,hsmmc-non-removable: non-removable slot (like eMMC)
Same here, non-removable should be standardized.
-Olof
PATCH 2/4 mmc: omap: adapt the hsmmc driver to device tree
Hi Olof,
Quoted 21 lines · Olof Johansson
Quoted 20 lines · Rajendra Nayak
Define dt bindings for the ti-omap-hsmmc, and adapt the driver to extract data (which was earlier passed as
platform_data) from device tree node.Signed-off-by Rajendra Nayak<[email protected]>--- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 +++++++++ drivers/mmc/host/omap_hsmmc.c | 117 ++++++++++++++++++++ 2 files changed, 167 insertions(+), 0 deletions(-)create mode 100644
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txtDocumentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +3
-0@@ -0,0 +1,50 @@ +* TI Highspeed MMC host controller for OMAP + +The Highspeed MMC Host Controller on TI OMAP family
Quoted 8 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 8
Quoted 5 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +5
-0+provides an interface for MMC, SD, and SDIO types of memory cards. + +Required properties: +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc"; +n is controller instance starting 0, for OMAP2/3 controllersNo, no, no. You should not have to specify the unit-address in the compatible field. They are all programmed the same way, right?
AFAIR, 2 instances contain a DMA engine, but that should anyway be detected using a "ti,had-dma-engine" extra property and not like that.
Checking the code in #2, it is used to get the instance of the MMC.
+static unsigned int of_get_hsmmc_instance(struct device_node *np) +{
+ int i;
+ char comp[32];
+
+ for (; i < OMAP_MMC_DEV_MAX; i++) {
+ snprintf(comp, 32, "ti,omap-hsmmc%d", i);
+ if (of_device_is_compatible(np, comp))
+ break;
+ }
+ return i;
+}
Which does not seems to be a good usage of the compatible property anyway. For a similar issue someone on the list suggested using the "cell-index" property. But the definition I found in some binding documentation seems to reserve that to: "enumerate logical devices within an IP core." Ideally the driver should probably get rid of the need for an index. I didn't check the original driver, but that should be needed for some legacy reason.
Quoted 8 lines
Also, they should go from the specific to the generic, but the first property is the same for 2/3 and 4. That's wrong.
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 11
Quoted 3 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +3
-0+- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc"; +n is controller instance starting 0, for OMAP4 controllers +- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1I didn't think hwmod bindings were settled on yet?
Why did you think that?
That binding was pretty straightforward and mandatory for starting any OMAP device tree migration until we have the proper reg-names, irq-names and dma-names generic binding.
Did you had any concern with that binding?
Regards,
Benoit
PATCH 2/4 mmc: omap: adapt the hsmmc driver to device tree
Quoted 39 lines · Benoit
Hi Olof,
Quoted 27 lines · Olof Johansson
Quoted 25 lines · Rajendra Nayak
Define dt bindings for the ti-omap-hsmmc, and adapt the driver to extract data (which was earlier passed as
platform_data) from device tree node.Signed-off-by Rajendra Nayak<[email protected]>---
?.../devicetree/bindings/mmc/ti-omap-hsmmc.txt ? ? ?| ? 50 +++++++++ ?drivers/mmc/host/omap_hsmmc.c ? ? ? ? ? ? ? ? ? ? ?| ?117
++++++++++++++++++++
?2 files changed, 167 insertions(+), 0 deletions(-) ?create mode 100644Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txtDocumentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +4
-0@@ -0,0 +1,50 @@ +* TI Highspeed MMC host controller for OMAP + +The Highspeed MMC Host Controller on TI OMAP family +provides an interface for MMC, SD, and SDIO types of memory cards.Quoted 8 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 8
Quoted 4 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +4
-0+ +Required properties: +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc"; +n is controller instance starting 0, for OMAP2/3 controllersNo, no, no. You should not have to specify the unit-address in the compatible
field. They are all programmed the same way, right?
Quoted 2 lines
AFAIR, 2 instances contain a DMA engine, but that should anyway be detected using a "ti,had-dma-engine" extra property and not like that.
Yep, it should be described by properties instead, such that future products won't need new bindings unless they add new hardware features (i.e. just new combinations of existing features should just work, more or less).
Quoted 9 lines
Quoted 1 line
I didn't think hwmod bindings were settled on yet?
Why did you think that?
That binding was pretty straightforward and mandatory for starting any OMAP device tree migration until we have the proper reg-names, irq-names and dma-names generic binding.
Did you had any concern with that binding?
Nope, just wasn't sure if it had settled down since I hadn't followed it closely. No concerns.
-Olof
PATCH 2/4 mmc: omap: adapt the hsmmc driver to device tree
In reply to Cousson, BenoitQuoted 26 lines · Benoit
Quoted 7 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 8
Quoted 3 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +3
-0+Required properties: +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc"; +n is controller instance starting 0, for OMAP2/3 controllersNo, no, no. You should not have to specify the unit-address in the compatible
field. They are all programmed the same way, right?AFAIR, 2 instances contain a DMA engine, but that should anyway be detected using a "ti,had-dma-engine" extra property and not like that.
Checking the code in #2, it is used to get the instance of the MMC.
drivers/mmc/host/omap_hsmmc.c +12
-0+static unsigned int of_get_hsmmc_instance (struct device_node *np) +{ +int i; +char comp[32 ]; + +for (; i <OMAP_MMC_DEV_MAX ; i++) { +snprintf (comp,32 ,"ti,omap-hsmmc%d" , i); +if (of_device_is_compatible (np, comp)) +break ; + } +return i; +}
Quoted 7 lines
Which does not seems to be a good usage of the compatible property anyway. For a similar issue someone on the list suggested using the "cell-index" property. But the definition I found in some binding documentation seems to reserve that to: "enumerate logical devices within an IP core." Ideally the driver should probably get rid of the need for an index. I didn't check the original driver, but that should be needed for some legacy reason.
yes, there are a bunch of things done inside the driver based on the instance id which seem wrong, but I agree, encoding the instance in the compatible property seems really bad and non-scalable. Will look at how some of this legacy code in the driver can be removed/cleaned up.
PATCH 2/4 mmc: omap: adapt the hsmmc driver to device tree
In reply to Olof JohanssonQuoted 3 lines
Quoted 1 line
+ti,hsmmc-non-removable: non-removable slot (like eMMC)
Same here, non-removable should be standardized.
CHRP has a "built-in" property for this. That was standardised in 1998, you could reuse it :-)
Segher
PATCH 2/4 mmc: omap: adapt the hsmmc driver to device tree
In reply to Olof JohanssonQuoted 30 lines · Olof Johansson
Quoted 17 lines · Rajendra Nayak
Define dt bindings for the ti-omap-hsmmc, and adapt the driver to extract data (which was earlier passed as
platform_data) from device tree node.Signed-off-by Rajendra Nayak<[email protected]>--- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 +++++++++ drivers/mmc/host/omap_hsmmc.c | 117 ++++++++++++++++++++ 2 files changed, 167 insertions(+), 0 deletions(-)create mode 100644
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txtDocumentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +0
-0Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 8
Quoted 8 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +8
-0@@ -0,0 +1,50 @@ +* TI Highspeed MMC host controller for OMAP + +The Highspeed MMC Host Controller on TI OMAP family +provides an interface for MMC, SD, and SDIO types of memory cards. + +Required properties: +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc"; +n is controller instance starting 0, for OMAP2/3 controllersNo, no, no. You should not have to specify the unit-address in the compatible field. They are all programmed the same way, right?
Quoted 2 lines
Also, they should go from the specific to the generic, but the first property is the same for 2/3 and 4. That's wrong.
agreed, will get rid of instance number from the compatible property.
Quoted 7 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 11
Quoted 4 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +3
-0+- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc"; +n is controller instance starting 0, for OMAP4 controllers +- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1I didn't think hwmod bindings were settled on yet?
Quoted 7 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 15
Quoted 4 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +4
-0+- reg : should contain hsmmc registers location and length + +Optional properties: +ti,hsmmc-supports-dual-volt: boolean, supports dual voltage cardsti,dual-voltage is a better name here (by definition, if it has the property it supports it, the word "supports" is redundant).
Ok.
Quoted 5 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 16
Quoted 2 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +1
-0+ti,hsmmc-nr-slots: Number of mmc slotsYou shouldn't have to specify this, it can be derived from the number of child nodes.
right, will do that.
Quoted 7 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 20
Quoted 5 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +4
-0+<supply-name>-supply: phandle to the regulator device tree node +"supply-name" examples are "vmmc", "vmmc_aux" etc +ti,hsmmc-has-pbias: Has PBIAS cell support +ti,hsmmc-has-special-reset: Requires a special softreset sequenceyou can drop hsmmc- from the properties here
Ok.
Quoted 10 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 27
Quoted 8 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +7
-0+ +For every supported slot a slot node can be defined +with the following optional properties + +ti,hsmmc-slot-name: Name assocaited to the mmc slot +ti,hsmmc-gpio-cd: gpio for card detect +ti,hsmmc-gpio-wp: gpio for write protectPlease use the same standard as the other mmc controllers for CD/WP.
Ok.
Quoted 4 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 28
Quoted 2 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +1
-0+ti,hsmmc-ocr-mask: mmc/sd/sdio ocr maskWhat is OCR mask?
Its used to derive the vdd range the card supports. I hadn't looked at this closely, but looks like this isn't something that needs to be told to the driver anyway, it can always just query the card about the voltages it supports and derive the ocrmask internally. One more of the hacks in the driver to be cleaned up. Will drop this property completely.
Quoted 4 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt line 29
Quoted 2 lines
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt new file +1
-0+ti,hsmmc-non-removable: non-removable slot (like eMMC)Same here, non-removable should be standardized.
You mean there is already a binding available for this?
Thanks for the review.
regards,
Rajendra
Quoted 3 lines
-Olof
Tony Lindgren
maintainerPATCH 2/4 mmc: omap: adapt the hsmmc driver to device tree
In reply to Rajendra Nayakdrivers/mmc/host/omap_hsmmc.c static int __init omap_hsmmc_probe(struct platform_device *pdev) · line 1967
Quoted 12 lines · Rajendra Nayak
drivers/mmc/host/omap_hsmmc.c +8
-0@@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)struct omap_hsmmc_host *host =NULL ;struct resource *res;int ret, irq; +const struct of_device_id *match; + + match =of_match_device (omap_mmc_of_match, &pdev->dev); +if (match) { + pdata =of_get_hsmmc_pdata (&pdev->dev); +if (match->data) + pdata->reg_offset = *(u16 *)match->data; + }
So this is now using both DT and pdata?
We want to use DT only, and get rid of pdata. Other than the deferred probe, is there some other dependency remaining to having to use the pdata also?
Regards,
Tony
PATCH 2/4 mmc: omap: adapt the hsmmc driver to device tree
Quoted 16 lines · Tony Lindgren
drivers/mmc/host/omap_hsmmc.c static int __init omap_hsmmc_probe(struct platform_device *pdev) · line 1967
Quoted 12 lines · Rajendra Nayak
drivers/mmc/host/omap_hsmmc.c +8
-0@@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)struct omap_hsmmc_host *host =NULL ;struct resource *res;int ret, irq; +const struct of_device_id *match; + + match =of_match_device (omap_mmc_of_match,&pdev->dev); +if (match) { + pdata =of_get_hsmmc_pdata (&pdev->dev); +if (match->data) + pdata->reg_offset = *(u16 *)match->data; + }So this is now using both DT and pdata?
Quoted 3 lines
We want to use DT only, and get rid of pdata. Other than the deferred probe, is there some other dependency remaining to having to use the pdata also?
We are using pdata today mainly for the platform function pointers that get passed for MMC, which can never be passed from DT.
The omap_mmc_platform_data structure today has '17' function pointers. Most might be sparingly used, nevertheless, its an awfully large number.
Here's the list...
---------
int (*switch_slot)(struct device *dev, int slot); int (*init)(struct device *dev);
void (*cleanup)(struct device *dev);
void (*shutdown)(struct device *dev);
int (*suspend)(struct device *dev, int slot); int (*resume)(struct device *dev, int slot); int (*get_context_loss_count)(struct device *dev);
per-slot functions
int (*set_bus_mode)(struct device *dev, int slot, int bus_mode); int (*set_power)(struct device *dev, int slot,
int power_on, int vdd);
int (*get_ro)(struct device *dev, int slot);
int (*set_sleep)(struct device *dev, int slot, int sleep,
int vdd, int cardsleep);
void (*remux)(struct device *dev, int slot, int power_on);
void (*before_set_reg)(struct device *dev, int slot,
int power_on, int vdd);
void (*after_set_reg)(struct device *dev, int slot,
int power_on, int vdd);void (*init_card)(struct mmc_card *card);
int (*get_cover_state)(struct device *dev, int slot); int (*card_detect)(struct device *dev, int slot);
---------
regards,
Rajendra
Quoted 8 lines
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Tony Lindgren
maintainerPATCH 2/4 mmc: omap: adapt the hsmmc driver to device tree
Quoted 21 lines · Rajendra Nayak
Quoted 16 lines · Tony Lindgren
drivers/mmc/host/omap_hsmmc.c static int __init omap_hsmmc_probe(struct platform_device *pdev) · line 1967
Quoted 12 lines · Rajendra Nayak
drivers/mmc/host/omap_hsmmc.c +8
-0@@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)struct omap_hsmmc_host *host =NULL ;struct resource *res;int ret, irq; +const struct of_device_id *match; + + match =of_match_device (omap_mmc_of_match,&pdev->dev); +if (match) { + pdata =of_get_hsmmc_pdata (&pdev->dev); +if (match->data) + pdata->reg_offset = *(u16 *)match->data; + }So this is now using both DT and pdata?
Quoted 3 lines
We want to use DT only, and get rid of pdata. Other than the deferred probe, is there some other dependency remaining to having to use the pdata also?
Quoted 5 lines
We are using pdata today mainly for the platform function pointers that get passed for MMC, which can never be passed from DT.
The
omap_mmc_platform_datastructure today has '17' function pointers. Most might be sparingly used, nevertheless, its an awfully large number.
Yeah OK.
Quoted 23 lines
Here's the list...
---------
int (*switch_slot)(struct device *dev, int slot); int (*init)(struct device *dev);
void (*cleanup)(struct device *dev);
void (*shutdown)(struct device *dev);
int (*suspend)(struct device *dev, int slot); int (*resume)(struct device *dev, int slot); int (*get_context_loss_count)(struct device *dev);per-slot functions
int (*set_bus_mode)(struct device *dev, int slot, int
bus_mode); int (*set_power)(struct device *dev, int slot,int power_on, int vdd); int (*get_ro)(struct device *dev, int slot); int (*set_sleep)(struct device *dev, int slot, int sleep, int vdd, int cardsleep); void (*remux)(struct device *dev, int slot, int power_on); void (*before_set_reg)(struct device *dev, int slot, int power_on, int vdd); void (*after_set_reg)(struct device *dev, int slot, int power_on, int vdd);
Quoted 4 lines
void (*init_card)(struct
mmc_card*card);
int (*get_cover_state)(struct device *dev, int slot); int (*card_detect)(struct device *dev, int slot);
---------
To me it seems we should move these into drivers/mmc/host/omap_hsmmc.c and set them based on DT compatible (or some other) property.
If these functions tinker with some internal registers, then we need to fix those too to use regulator/gpio API.
This way we don't need the platform_data any longer.
Regards,
Tony
PATCH 3/4 omap4: mmc: Pass SoC and board data for omap4 mmc from dt
In reply to Rajendra NayakPass all omap4-hsmmc related data from device tree. Currenly limited to only omap4-panda and omap4-sdp boards.
--- arch/arm/boot/dts/omap4-panda.dts | 23 ++++++++++++++++++ arch/arm/boot/dts/omap4-sdp.dts | 33 ++++++++++++++++++++++++++ arch/arm/boot/dts/omap4.dtsi | 46 +++++++++++++++++++++++++++++++++++++ 3 files changed, 102 insertions(+), 0 deletions(-)
arch/arm/boot/dts/omap4-panda.dts +23 -0
@@ -105,3 +105,26 @@ &i2c4 { clock-frequency = <400000>; }; + +&mmc1 { + ti,hsmmc-nr-slots = <1>; + vmmc-supply = <&vmmc>; + slot at 1 { + linux,mmc_cap_4_bit_data; + linux,mmc_cap_8_bit_data; + ti,hsmmc-has-special-reset; + }; +}; + +&mmc5 { + ti,hsmmc-nr-slots = <1>; + vmmc-supply = <&vwl1271>; + slot at 1 { + ti,hsmmc-slot-name = "wl1271"; + linux,mmc_cap_4_bit_data; + linux,mmc_cap_power_off_card; + ti,hsmmc-ocr-mask = <0x80>; + ti,hsmmc-nonremovable; + ti,hsmmc-has-special-reset; + }; +};
arch/arm/boot/dts/omap4-sdp.dts +33 -0
@@ -125,3 +125,36 @@ reg = <0x1e>; }; }; + +&mmc1 { + ti,hsmmc-nr-slots = <1>; + vmmc-supply = <&vmmc>; + slots at 1 { + linux,mmc_cap_4_bit_data; + linux,mmc_cap_8_bit_data; + ti,hsmmc-has-special-reset; + }; +}; + +&mmc2 { + ti,hsmmc-nr-slots = <1>; + vmmc-supply = <&vaux1>; + slots at 1 { + linux,mmc_cap_4_bit_data; + linux,mmc_cap_8_bit_data; + ti,hsmmc-nonremovable; + ti,hsmmc-ocr-mask = <0x20000>; + ti,hsmmc-has-special-reset; + }; +}; + +&mmc5 { + ti,hsmmc-nr-slots = <1>; + slots at 1 { + linux,mmc_cap_4_bit_data; + linux,mmc_cap_power_off_card; + ti,hsmmc-nonremovable; + ti,hsmmc-ocr-mask = <0x80>; + ti,hsmmc-has-special-reset; + }; +};
arch/arm/boot/dts/omap4.dtsi +46 -0
57 lines not on this page · raw message
Signature · 1 line
1.7.1
PATCH 4/4 omap4: mmc: use auxdata to pass platform function ptrs
In reply to Rajendra Nayakmmc driver still relies on platform specific functions being invoked from the driver by means of function pointers being passed through platform_data structure.
use the auxdata for now to pass these the same way until we find a way to get rid of these calls from the driver.
--- arch/arm/mach-omap2/board-generic.c | 19 +++++++++++++++++-- arch/arm/mach-omap2/hsmmc.c | 9 +++++---- arch/arm/mach-omap2/hsmmc.h | 5 +++++ drivers/mmc/host/omap_hsmmc.c | 8 ++++++++ 4 files changed, 35 insertions(+), 6 deletions(-)
arch/arm/mach-omap2/board-generic.c +17 -2
@@ -15,14 +15,29 @@#include <linux/io.h> #include <linux/of_platform.h> #include <linux/irqdomain.h> +#include <linux/i2c/twl.h> #include <mach/hardware.h> #include <asm/mach/arch.h> #include <plat/board.h> #include <plat/common.h> +#include <plat/mmc.h> #include <mach/omap4-common.h> +#include "hsmmc.h" + +struct omap_mmc_platform_data omap4_mmc1_pdata = { + .init = twl6030_mmc_card_detect_config, + .slots[0 ] = { + .before_set_reg = omap4_hsmmc1_before_set_reg, + .after_set_reg = omap4_hsmmc1_after_set_reg, + }, +}; +struct of_dev_auxdata omap_auxdata_lookup[]__initdata = { +OF_DEV_AUXDATA ("ti,omap-hsmmc0" ,0x4809c000 ,"omap_hsmmc.0" , &omap4_mmc1_pdata), + {} +};static struct of_device_id omap_dt_match_table[]__initdata = { { .compatible ="simple-bus" , },
@@ -44,8 +59,8 @@ static void __init omap_generic_init(void)omap_serial_init ();omap_sdrc_init (NULL ,NULL ); - -of_platform_populate (NULL , omap_dt_match_table,NULL ,NULL ); +omap2_hsmmc_init (NULL ); +of_platform_populate (NULL , omap_dt_match_table, omap_auxdata_lookup,NULL ); }#if defined(CONFIG_SOC_OMAP2420 )
arch/arm/mach-omap2/hsmmc.c +5 -4
@@ -120,7 +120,7 @@ static void omap_hsmmc1_after_set_reg(struct device *dev, int slot, } } -static void omap4_hsmmc1_before_set_reg (struct device *dev,int slot, +void omap4_hsmmc1_before_set_reg (struct device *dev,int slot,int power_on,int vdd) {u32 reg;
@@ -141,7 +141,7 @@ static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,omap4_ctrl_pad_writel (reg, control_pbias_offset); } -static void omap4_hsmmc1_after_set_reg (struct device *dev,int slot, +void omap4_hsmmc1_after_set_reg (struct device *dev,int slot,int power_on,int vdd) {u32 reg;
@@ -495,8 +495,9 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)omap4_ctrl_pad_writel (reg, control_mmc1); } -for (; controllers->mmc; controllers++) -omap_init_hsmmc (controllers, controllers->mmc); +if (controllers) +for (; controllers->mmc; controllers++) +omap_init_hsmmc (controllers, controllers->mmc); }
arch/arm/mach-omap2/hsmmc.h +5 -0
@@ -34,6 +34,11 @@ struct omap2_hsmmc_info {#if defined(CONFIG_MMC_OMAP_HS ) || defined(CONFIG_MMC_OMAP_HS_MODULE )void omap2_hsmmc_init (struct omap2_hsmmc_info *); +extern void omap4_hsmmc1_before_set_reg (struct device *dev,int slot, +int power_on,int vdd); +extern void omap4_hsmmc1_after_set_reg (struct device *dev,int slot, +int power_on,int vdd); +#else
drivers/mmc/host/omap_hsmmc.c +8 -0
@@ -1953,6 +1953,7 @@ static const struct of_device_id omap_mmc_of_match[];static int __init omap_hsmmc_probe (struct platform_device *pdev) {struct omap_mmc_platform_data *pdata = pdev->dev.platform_data; +struct omap_mmc_platform_data *aux_pdata = pdev->dev.platform_data;struct mmc_host *mmc;struct omap_hsmmc_host *host =NULL ;struct resource *res;
@@ -1964,6 +1965,13 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) pdata =of_get_hsmmc_pdata (&pdev->dev);if (match->data) pdata->reg_offset = *(u16 *)match->data; +if (aux_pdata) { + pdata->init = aux_pdata->init; + pdata->slots[0 ].before_set_reg = + aux_pdata->slots[0 ].before_set_reg; + pdata->slots[0 ].after_set_reg = + aux_pdata->slots[0 ].after_set_reg; + } }if (pdata ==NULL ) {
Signature · 1 line
1.7.1