mmc: mmci: Improve DT support
Subsystems (7)
cover mmc: mmci: Improve DT support
Step by step, improve the DT support for the mmci host driver.
This enables us to move the final pieces of platform data for mmci for ux500 into DT. We are then able to remove yet another machine specific file for ux500.
This patchset needs to be merged together. I suggest we go through Russell's ARM tree, since most of the patches are mmci specific which he maintains - unless someone think there is a better alternative.
I will thus seek acks from the SOC maintainers as well as the regulator maintainers. Note, one minor patch was needed for a specific regulator used by ux500, I assumes it will be a trivial patch to ack, but let's see. :-)
The goal is to queue this for 3.16, thus I might need to rebase the patches for 3.15 rc[n]. Still I would appreciate any comments at this point.
Ulf Hansson (20):
mmc: mmci: Convert to the mmc gpio API
mmc: mmci: Convert to devm functions
mmc: mmci: Update DT documentation
mmc: mmci: Move signal directions bits into DT include file
mmc: mmci: Add DT bindings for signal direction
mmc: mmci: Use the common mmc DT parser
ARM: ux500: Add mmci signal directions in DT for href
ARM: ux500: Convert to the common mmc DT bindings for highspeed mode
ARM: nomadik: Convert to the common mmc DT bindings for highspeed
mode
ARM: u300: Convert to the common mmc DT bindings for highspeed mode
mmc: mmci: Mark the DT bindings for highspeed mode as deprecated
mmc: mmci: Enable MMC_CAP_CMD23
ARM: ux500: Add the mmc capabilities flags to DT
regulator: db8500-prcmu: Set 1.8V as a fixed voltage for vsmps2
ARM: ux500: Add a vmmc regulator through DT for the poped eMMC for
href
ARM: ux500: Remove redundant board file for mmci platform data
mmc: mmci: Enforce DT for signal direction
mmc: mmci: Enforce mmc capabilities through DT
mmc: mmci: Enforce DMA configuration through DT
mmc: mmci: Enforce max frequency configuration through DT
Documentation/devicetree/bindings/mmc/mmci.txt | 41 +++- arch/arm/boot/dts/ste-ccu9540.dts | 6 +- arch/arm/boot/dts/ste-href.dtsi | 20 +- arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 4 +- arch/arm/boot/dts/ste-snowball.dts | 4 +- arch/arm/boot/dts/ste-u300.dts | 4 +- arch/arm/mach-ux500/Makefile | 3 +- arch/arm/mach-ux500/board-mop500-sdi.c | 166 --------------- arch/arm/mach-ux500/board-mop500.h | 5 - arch/arm/mach-ux500/cpu-db8500.c | 4 - drivers/mmc/host/mmci.c | 259 ++++++------------------ drivers/mmc/host/mmci.h | 4 +- drivers/regulator/db8500-prcmu.c | 2 + include/dt-bindings/mmc/mmci.h | 21 ++ include/linux/amba/mmci.h | 42 ---- 15 files changed, 153 insertions(+), 432 deletions(-) delete mode 100644 arch/arm/mach-ux500/board-mop500-sdi.c create mode 100644 include/dt-bindings/mmc/mmci.h
Signature · 1 line
1.7.9.5
PATCH 1/20 mmc: mmci: Convert to the mmc gpio API
To avoid duplication of code while handling card detect and write protect GPIO pins/irqs, let's convert to use the mmc gpio API.
--- drivers/mmc/host/mmci.c | 97 ++++++++--------------------------------------- drivers/mmc/host/mmci.h | 3 -- 2 files changed, 15 insertions(+), 85 deletions(-)
drivers/mmc/host/mmci.c +15 -82
@@ -23,6 +23,7 @@#include <linux/mmc/pm.h> #include <linux/mmc/host.h> #include <linux/mmc/card.h> +#include <linux/mmc/slot-gpio.h> #include <linux/amba/bus.h> #include <linux/clk.h> #include <linux/scatterlist.h>
@@ -1326,35 +1327,18 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)pm_runtime_put_autosuspend (mmc_dev (mmc)); } -static int mmci_get_ro (struct mmc_host *mmc) -{ -struct mmci_host *host =mmc_priv (mmc); - -if (host->gpio_wp == -ENOSYS ) -return -ENOSYS ; - -return gpio_get_value_cansleep (host->gpio_wp); -} -static int mmci_get_cd (struct mmc_host *mmc) {struct mmci_host *host =mmc_priv (mmc);struct mmci_platform_data *plat = host->plat; -unsigned int status; +unsigned int status =mmc_gpio_get_cd (mmc); -if (host->gpio_cd == -ENOSYS ) { +if (status == -ENOSYS ) {if (!plat->status)return 1 ;/* Assume always present */ status = plat->status (mmc_dev (host->mmc)); - }else - status = !!gpio_get_value_cansleep (host->gpio_cd) - ^ plat->cd_invert; - -/* -* Use positive logic throughout - status is zero for no card, -* non-zero for card inserted. -*/ + }return status; }
@@ -1391,21 +1375,12 @@ static int mmci_sig_volt_switch(struct mmc_host *mmc, struct mmc_ios *ios)return ret; } -static irqreturn_t mmci_cd_irq (int irq,void *dev_id) -{ -struct mmci_host *host = dev_id; - -mmc_detect_change (host->mmc,msecs_to_jiffies (500 )); - -return IRQ_HANDLED ; -} -static struct mmc_host_ops mmci_ops = { .request = mmci_request, .pre_req = mmci_pre_request, .post_req = mmci_post_request, .set_ios = mmci_set_ios, - .get_ro = mmci_get_ro, + .get_ro = mmc_gpio_get_ro, .get_cd = mmci_get_cd, .start_signal_voltage_switch = mmci_sig_volt_switch, };
@@ -1494,10 +1469,6 @@ static int mmci_probe(struct amba_device *dev, host =mmc_priv (mmc); host->mmc = mmc; - host->gpio_wp = -ENOSYS ; - host->gpio_cd = -ENOSYS ; - host->gpio_cd_irq =-1 ; - host->hw_designer =amba_manf (dev); host->hw_revision =amba_rev (dev);dev_dbg (mmc_dev (mmc),"designer ID = 0x%02x\n" , host->hw_designer);
@@ -1568,6 +1539,9 @@ static int mmci_probe(struct amba_device *dev, mmc->caps = plat->capabilities; mmc->caps2 = plat->capabilities2; +if (!plat->cd_invert) + mmc->caps2 |=MMC_CAP2_CD_ACTIVE_HIGH ; + mmc->caps2 |=MMC_CAP2_RO_ACTIVE_HIGH ;if (variant->busy_detect) { mmci_ops.card_busy = mmci_card_busy;
@@ -1621,49 +1595,23 @@ static int mmci_probe(struct amba_device *dev, goto err_gpio_cd; }if (gpio_is_valid (plat->gpio_cd)) { - ret =gpio_request (plat->gpio_cd,DRIVER_NAME " (cd)" ); -if (ret ==0 ) - ret =gpio_direction_input (plat->gpio_cd); -if (ret ==0 ) - host->gpio_cd = plat->gpio_cd; -else if (ret != -ENOSYS ) + ret =mmc_gpio_request_cd (mmc, plat->gpio_cd,0 ); +if (ret) goto err_gpio_cd; - -/* -* A gpio pin that will detect cards when inserted and removed -* will most likely want to trigger on the edges if it is -* 0 when ejected and 1 when inserted (or mutatis mutandis -* for the inverted case) so we request triggers on both -* edges. -*/ - ret =request_any_context_irq (gpio_to_irq (plat->gpio_cd), - mmci_cd_irq, -IRQF_TRIGGER_RISING |IRQF_TRIGGER_FALLING , -DRIVER_NAME " (cd)" , host); -if (ret >=0 ) - host->gpio_cd_irq =gpio_to_irq (plat->gpio_cd); }if (plat->gpio_wp == -EPROBE_DEFER ) { ret = -EPROBE_DEFER ; - goto err_gpio_wp; + goto err_gpio_cd; }if (gpio_is_valid (plat->gpio_wp)) { - ret =gpio_request (plat->gpio_wp,DRIVER_NAME " (wp)" ); -if (ret ==0 ) - ret =gpio_direction_input (plat->gpio_wp); -if (ret ==0 ) - host->gpio_wp = plat->gpio_wp; -else if (ret != -ENOSYS ) - goto err_gpio_wp; + ret =mmc_gpio_request_ro (mmc, plat->gpio_wp); +if (ret) + goto err_gpio_cd; } -if ((host->plat->status || host->gpio_cd != -ENOSYS ) - && host->gpio_cd_irq <0 ) - mmc->caps |=MMC_CAP_NEEDS_POLL ; - ret =request_irq (dev->irq[0 ], mmci_irq,IRQF_SHARED ,DRIVER_NAME " (cmd)" , host);if (ret) - goto unmap; + goto err_gpio_cd;if (!dev->irq[1 ]) host->singleirq = true;
@@ -1695,14 +1643,6 @@ static int mmci_probe(struct amba_device *dev, irq0_free:free_irq (dev->irq[0 ], host); - unmap: -if (host->gpio_wp != -ENOSYS ) -gpio_free (host->gpio_wp); - err_gpio_wp: -if (host->gpio_cd_irq >=0 ) -free_irq (host->gpio_cd_irq, host); -if (host->gpio_cd != -ENOSYS ) -gpio_free (host->gpio_cd); err_gpio_cd:iounmap (host->base); clk_disable:
@@ -1741,13 +1681,6 @@ static int mmci_remove(struct amba_device *dev)if (!host->singleirq)free_irq (dev->irq[1 ], host); -if (host->gpio_wp != -ENOSYS ) -gpio_free (host->gpio_wp); -if (host->gpio_cd_irq >=0 ) -free_irq (host->gpio_cd_irq, host); -if (host->gpio_cd != -ENOSYS ) -gpio_free (host->gpio_cd); -iounmap (host->base);clk_disable_unprepare (host->clk);
drivers/mmc/host/mmci.h +0 -3
@@ -176,9 +176,6 @@ struct mmci_host {struct mmc_data *data;struct mmc_host *mmc;struct clk *clk; -int gpio_cd; -int gpio_wp; -int gpio_cd_irq;bool singleirq;spinlock_t lock;
Signature · 1 line
1.7.9.5
PATCH 2/20 mmc: mmci: Convert to devm functions
In reply to Ulf HanssonConverting to devm functions to simplify error handling in ->probe() and to cleanup ->remove().
--- drivers/mmc/host/mmci.c | 51 ++++++++++++++++++----------------------------- 1 file changed, 19 insertions(+), 32 deletions(-)
drivers/mmc/host/mmci.c +19 -32
@@ -13,6 +13,7 @@#include <linux/init.h> #include <linux/ioport.h> #include <linux/device.h> +#include <linux/io.h> #include <linux/interrupt.h> #include <linux/kernel.h> #include <linux/slab.h>
@@ -1456,15 +1457,13 @@ static int mmci_probe(struct amba_device *dev,if (np)mmci_dt_populate_generic_pdata (np, plat); - ret =amba_request_regions (dev,DRIVER_NAME ); -if (ret) - goto out; +if (!devm_request_mem_region (&dev->dev, dev->res.start, +resource_size (&dev->res),DRIVER_NAME )) +return -ENOMEM ; mmc =mmc_alloc_host (sizeof (struct mmci_host ), &dev->dev); -if (!mmc) { - ret = -ENOMEM ; - goto rel_regions; - } +if (!mmc) +return -ENOMEM ; host =mmc_priv (mmc); host->mmc = mmc;
@@ -1500,8 +1499,10 @@ static int mmci_probe(struct amba_device *dev,dev_dbg (mmc_dev (mmc),"eventual mclk rate: %u Hz\n" , host->mclk); } + host->phybase = dev->res.start; - host->base =ioremap (dev->res.start,resource_size (&dev->res)); + host->base =devm_ioremap (&dev->dev, host->phybase, +resource_size (&dev->res));if (!host->base) { ret = -ENOMEM ; goto clk_disable;
@@ -1592,34 +1593,35 @@ static int mmci_probe(struct amba_device *dev,if (plat->gpio_cd == -EPROBE_DEFER ) { ret = -EPROBE_DEFER ; - goto err_gpio_cd; + goto clk_disable; }if (gpio_is_valid (plat->gpio_cd)) { ret =mmc_gpio_request_cd (mmc, plat->gpio_cd,0 );if (ret) - goto err_gpio_cd; + goto clk_disable; }if (plat->gpio_wp == -EPROBE_DEFER ) { ret = -EPROBE_DEFER ; - goto err_gpio_cd; + goto clk_disable; }if (gpio_is_valid (plat->gpio_wp)) { ret =mmc_gpio_request_ro (mmc, plat->gpio_wp);if (ret) - goto err_gpio_cd; + goto clk_disable; } - ret =request_irq (dev->irq[0 ], mmci_irq,IRQF_SHARED ,DRIVER_NAME " (cmd)" , host); + ret =devm_request_irq (&dev->dev, dev->irq[0 ], mmci_irq,IRQF_SHARED , +DRIVER_NAME " (cmd)" , host);if (ret) - goto err_gpio_cd; + goto clk_disable;if (!dev->irq[1 ]) host->singleirq = true;else { - ret =request_irq (dev->irq[1 ], mmci_pio_irq,IRQF_SHARED , -DRIVER_NAME " (pio)" , host); + ret =devm_request_irq (&dev->dev, dev->irq[1 ], mmci_pio_irq, +IRQF_SHARED ,DRIVER_NAME " (pio)" , host);if (ret) - goto irq0_free; + goto clk_disable; }writel (MCI_IRQENABLE , host->base +MMCIMASK0 );
@@ -1641,17 +1643,10 @@ static int mmci_probe(struct amba_device *dev,return 0 ; - irq0_free: -free_irq (dev->irq[0 ], host); - err_gpio_cd: -iounmap (host->base); clk_disable:clk_disable_unprepare (host->clk); host_free:mmc_free_host (mmc); - rel_regions: -amba_release_regions (dev); - out:return ret; }
@@ -1677,16 +1672,8 @@ static int mmci_remove(struct amba_device *dev)writel (0 , host->base +MMCIDATACTRL );mmci_dma_release (host); -free_irq (dev->irq[0 ], host); -if (!host->singleirq) -free_irq (dev->irq[1 ], host); - -iounmap (host->base);clk_disable_unprepare (host->clk); -mmc_free_host (mmc); - -amba_release_regions (dev); }return 0 ;
Signature · 1 line
1.7.9.5
PATCH 3/20 mmc: mmci: Update DT documentation
In reply to Ulf HanssonDocument how to configure the regulator supplies and add an example of a typical mmci DT node.
--- Documentation/devicetree/bindings/mmc/mmci.txt | 35 ++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/mmc/mmci.txt +33 -2
@@ -9,7 +9,38 @@ by mmc.txt and the properties used by the mmci driver. Required properties: - compatible : contains "arm,pl18x", "arm,primecell". - arm,primecell-periphid : contains the PrimeCell Peripheral ID. +- vmmc-supply : phandle to the regulator device tree node. Optional properties: -- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable -- mmc-cap-sd-highspeed : indicates whether SD is high speed capable +- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. +- mmc-cap-sd-highspeed : indicates whether SD is high speed capable. +- vqmmc-supply : phandle to the regulator device tree node. + +Example: + +sdi0_per1 at 80126000 { + compatible = "arm,pl18x", "arm,primecell"; + arm,primecell-periphid = <0x10480180>; + reg = <0x80126000 0x1000>; + interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>; + + dmas = <&dma 29 0 0x2>, /* Logical - DevToMem */ + <&dma 29 0 0x0>; /* Logical - MemToDev */ + dma-names = "rx", "tx"; + + clocks = <&prcc_kclk 1 5>, <&prcc_pclk 1 5>; + clock-names = "sdi", "apb_pclk"; + + max-frequency = <100000000>; + bus-width = <4>; + mmc-cap-sd-highspeed; + mmc-cap-mmc-highspeed; + cd-gpios = <&gpio2 31 0x4>; // 95 + + vmmc-supply = <&ab8500_ldo_aux3_reg>; + vqmmc-supply = <&vmmci>; + + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&sdi0_default_mode>; + pinctrl-1 = <&sdi0_sleep_mode>; +};
Signature · 1 line
1.7.9.5
PATCH 3/20 mmc: mmci: Update DT documentation
Quoted 13 lines · Ulf Hansson
Document how to configure the regulator supplies and add an example of a typical mmci DT node.
Signed-off-by Ulf Hansson <[email protected]>--- Documentation/devicetree/bindings/mmc/mmci.txt | 35 ++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-)Documentation/devicetree/bindings/mmc/mmci.txt +0
-0
Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 11
Quoted 3 lines
Documentation/devicetree/bindings/mmc/mmci.txt +0
-0@@ -9,7 +9,38 @@ by mmc.txt and the properties used by the mmci driver. Required properties: - compatible : contains "arm,pl18x", "arm,primecell". - arm,primecell-periphid : contains the PrimeCell Peripheral ID.
This should not be required. This is only for if the peripheral ID is wrong in the h/w.
Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 12
Quoted 1 line
Documentation/devicetree/bindings/mmc/mmci.txt +1
-0+- vmmc-supply : phandle to the regulator device tree node.
You cannot add new required properties as that breaks the ABI. The exception is if you *know* it is okay to break all users of this binding.
Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 17
Quoted 6 lines
Documentation/devicetree/bindings/mmc/mmci.txt +3
-2Optional properties: -- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable -- mmc-cap-sd-highspeed : indicates whether SD is high speed capable +- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. +- mmc-cap-sd-highspeed : indicates whether SD is high speed capable. +- vqmmc-supply : phandle to the regulator device tree node.
Is this a standard property? If not, explain what vmmc and vgmmc are for and what the difference is.
Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 23
Quoted 6 lines
Documentation/devicetree/bindings/mmc/mmci.txt +6
-0+ +Example: + +sdi0_per1 at 80126000 { + compatible = "arm,pl18x", "arm,primecell"; + arm,primecell-periphid = <0x10480180>;
Drop this from the example.
Quoted 30 lines
Documentation/devicetree/bindings/mmc/mmci.txt +23
-1+ reg = <0x80126000 0x1000>; + interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>; + + dmas = <&dma 29 0 0x2>, /* Logical - DevToMem */ + <&dma 29 0 0x0>; /* Logical - MemToDev */ + dma-names = "rx", "tx"; + + clocks = <&prcc_kclk 1 5>, <&prcc_pclk 1 5>; + clock-names = "sdi", "apb_pclk"; + + max-frequency = <100000000>; + bus-width = <4>; + mmc-cap-sd-highspeed; + mmc-cap-mmc-highspeed; + cd-gpios = <&gpio2 31 0x4>; // 95 + + vmmc-supply = <&ab8500_ldo_aux3_reg>; + vqmmc-supply = <&vmmci>; + + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&sdi0_default_mode>; + pinctrl-1 = <&sdi0_sleep_mode>; +}; --1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 3/20 mmc: mmci: Update DT documentation
Quoted 9 lines · Rob Herring
Quoted 8 lines · Ulf Hansson
Document how to configure the regulator supplies and add an example of a typical mmci DT node.
Signed-off-by Ulf Hansson <[email protected]>--- Documentation/devicetree/bindings/mmc/mmci.txt | 35 ++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-)
Quoted 11 lines
Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 11
Quoted 8 lines
Documentation/devicetree/bindings/mmc/mmci.txt +0
-0@@ -9,7 +9,38 @@ by mmc.txt and the properties used by the mmci driver. Required properties: - compatible : contains "arm,pl18x", "arm,primecell". - arm,primecell-periphid : contains the PrimeCell Peripheral ID.This should not be required. This is only for if the peripheral ID is wrong in the h/w.
You are right, I will move it to the optional section and add better comment for it.
Quoted 6 lines
Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 12
Quoted 2 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1
-0+- vmmc-supply : phandle to the regulator device tree node.You cannot add new required properties as that breaks the ABI. The exception is if you *know* it is okay to break all users of this binding.
It's okay, this is already supported by the users.
Quoted 10 lines
Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 17
Quoted 7 lines
Documentation/devicetree/bindings/mmc/mmci.txt +3
-2Optional properties: -- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable -- mmc-cap-sd-highspeed : indicates whether SD is high speed capable +- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. +- mmc-cap-sd-highspeed : indicates whether SD is high speed capable. +- vqmmc-supply : phandle to the regulator device tree node.Is this a standard property? If not, explain what vmmc and vgmmc are for and what the difference is.
Currently both vqmmc and vmmc are handled through an API provided by the mmc core. It's up to each mmc host driver to use it. So, yes - this is a standard mmc binding, but it depends on the host if it's supported.
I suppose I could add it as an optional binding for the generic mmc bindings and then keep them here for mmci as well?
Quoted 36 lines
Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 23
Quoted 7 lines
Documentation/devicetree/bindings/mmc/mmci.txt +6
-0+ +Example: + +sdi0_per1 at 80126000 { + compatible = "arm,pl18x", "arm,primecell"; + arm,primecell-periphid = <0x10480180>;Drop this from the example.
Quoted 26 lines
Documentation/devicetree/bindings/mmc/mmci.txt +23
-1+ reg = <0x80126000 0x1000>; + interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>; + + dmas = <&dma 29 0 0x2>, /* Logical - DevToMem */ + <&dma 29 0 0x0>; /* Logical - MemToDev */ + dma-names = "rx", "tx"; + + clocks = <&prcc_kclk 1 5>, <&prcc_pclk 1 5>; + clock-names = "sdi", "apb_pclk"; + + max-frequency = <100000000>; + bus-width = <4>; + mmc-cap-sd-highspeed; + mmc-cap-mmc-highspeed; + cd-gpios = <&gpio2 31 0x4>; // 95 + + vmmc-supply = <&ab8500_ldo_aux3_reg>; + vqmmc-supply = <&vmmci>; + + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&sdi0_default_mode>; + pinctrl-1 = <&sdi0_sleep_mode>; +}; --1.7.9.5
Quoted 4 lines
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks for reviewing!
Kind regards
Ulf Hansson
PATCH 4/20 mmc: mmci: Move signal directions bits into DT include file
In reply to Ulf HanssonThese bits is currently used from platform data, but will be needed from DT as well, so let's make them available.
--- include/dt-bindings/mmc/mmci.h | 21 +++++++++++++++++++++ include/linux/amba/mmci.h | 14 +------------- 2 files changed, 22 insertions(+), 13 deletions(-) create mode 100644 include/dt-bindings/mmc/mmci.h
include/dt-bindings/mmc/mmci.h new file +21 -0
@@ -0,0 +1,21 @@ +/* +* This header provides constants for the mmci bindings. +* +*/ + +#ifndef _DT_BINDINGS_MMC_MMCI_H +#define _DT_BINDINGS_MMC_MMCI_H + +/* +* Bus signal direction bits. +* The ST Micro version does not have ROD and reuse the voltage registers +* for direction settings. +*/ +#define MCI_ST_DATA2DIREN (1 << 2) +#define MCI_ST_CMDDIREN (1 << 3) +#define MCI_ST_DATA0DIREN (1 << 4) +#define MCI_ST_DATA31DIREN (1 << 5) +#define MCI_ST_FBCLKEN (1 << 7) +#define MCI_ST_DATA74DIREN (1 << 8) + +#endif
include/linux/amba/mmci.h +1 -13
@@ -5,19 +5,7 @@#define AMBA_MMCI_H #include <linux/mmc/host.h> - - -/* -* These defines is places here due to access is needed from machine -* configuration files. The ST Micro version does not have ROD and -* reuse the voltage registers for direction settings. -*/ -#define MCI_ST_DATA2DIREN (1 << 2) -#define MCI_ST_CMDDIREN (1 << 3) -#define MCI_ST_DATA0DIREN (1 << 4) -#define MCI_ST_DATA31DIREN (1 << 5) -#define MCI_ST_FBCLKEN (1 << 7) -#define MCI_ST_DATA74DIREN (1 << 8) +#include <dt-bindings/mmc/mmci.h> /* Just some dummy forwarding */ struct dma_chan ;
Signature · 1 line
1.7.9.5
PATCH 4/20 mmc: mmci: Move signal directions bits into DT include file
Quoted 4 lines · Ulf Hansson
These bits is currently used from platform data, but will be needed from DT as well, so let's make them available.
Signed-off-by Ulf Hansson <[email protected]>
(...)
include/dt-bindings/mmc/mmci.h line 19
Quoted 3 lines
include/dt-bindings/mmc/mmci.h new file +3
-0+#define MCI_ST_DATA31DIREN (1 << 5) +#define MCI_ST_FBCLKEN (1 << 7) +#define MCI_ST_DATA74DIREN (1 << 8)
Isn't MCI_ST_FBCLKEN = feedback clock enable and nothing to do with directions really?
Or can you convince me ...
Maybe we should just have single strings for these things in the binding instead, like:
@@ -118,6 +119,10 @@
bus-width = <4>;
mmc-cap-sd-highspeed;
mmc-cap-mmc-highspeed;
+ st,signal-direction-data2;
+ st,signal-direction-cmd;
+ st,signal-direction-data0;
+ st,feedback-clock-enable;
vmmc-supply = <&ab8500_ldo_aux3_reg>;
vqmmc-supply = <&vmmci>;
pinctrl-names = "default", "sleep";And for FBCLKEN is that really something that should be configured... in the device tree after all?
Yours,
Linus Walleij
PATCH 4/20 mmc: mmci: Move signal directions bits into DT include file
Quoted 5 lines · Linus Walleij
Quoted 3 lines · Ulf Hansson
These bits is currently used from platform data, but will be needed from DT as well, so let's make them available.
Quoted 8 lines
Quoted 1 line
Signed-off-by Ulf Hansson <[email protected]>(...)
include/dt-bindings/mmc/mmci.h line 19
Quoted 3 lines
include/dt-bindings/mmc/mmci.h new file +3
-0+#define MCI_ST_DATA31DIREN (1 << 5) +#define MCI_ST_FBCLKEN (1 << 7) +#define MCI_ST_DATA74DIREN (1 << 8)Isn't
MCI_ST_FBCLKEN= feedback clock enable and nothing to do with directions really?
You do have a point here, but then we are about to go into the details. :-)
What MCI_ST_FBCLKEN means, is that the internal logic in the primecell can decide whether to use the signal from clockout pin or the feebackclock pin, when its latching incoming signals on the data bus.
That said, we for sure need a dt binding for bit as well, since this is not possible to figure out how pins are routed in runtime.
Also, I do believe it is very closely related to the other sigdir pins, since it's all about how pins is being routed, even if it's as you say - in this case a matter of signal directions.
So, I guess we have two options here; Either move the MCI_ST_FBCLKEN out of the signal-direction binding and invent a separate binding for it, or just keep them as is.
Quoted 7 lines
Or can you convince me ...
Maybe we should just have single strings for these things in the binding instead, like:
Review line 128
Quoted 10 lines
(quoted diff) +4
-0@@ -118,6 +119,10 @@ bus-width = <4>; mmc-cap-sd-highspeed; mmc-cap-mmc-highspeed; + st,signal-direction-data2; + st,signal-direction-cmd; + st,signal-direction-data0; + st,feedback-clock-enable; vmmc-supply = <&ab8500_ldo_aux3_reg>; vqmmc-supply = <&vmmci>; pinctrl-names = "default", "sleep";
I guess this is an option. To me it just seems a bit silly to have one separate binding for each single bit, but maybe it becomes clearer?
Quoted 3 lines
And for FBCLKEN is that really something that should be configured... in the device tree after all?
We need a DT binding, see above.
Quoted 3 lines
Yours,
Linus Walleij
Thanks for reviewing.
Please tell me your ideas on how to proceed, I happy to change to whatever you like. :-)
Kind regards
Ulf Hansson
PATCH 4/20 mmc: mmci: Move signal directions bits into DT include file
Quoted 24 lines · Ulf Hansson
Quoted 5 lines · Linus Walleij
Quoted 3 lines · Ulf Hansson
These bits is currently used from platform data, but will be needed from DT as well, so let's make them available.
Quoted 8 lines
Quoted 1 line
Signed-off-by Ulf Hansson <[email protected]>(...)
include/dt-bindings/mmc/mmci.h line 19
Quoted 3 lines
include/dt-bindings/mmc/mmci.h new file +3
-0+#define MCI_ST_DATA31DIREN (1 << 5) +#define MCI_ST_FBCLKEN (1 << 7) +#define MCI_ST_DATA74DIREN (1 << 8)Isn't
MCI_ST_FBCLKEN= feedback clock enable and nothing to do with directions really?You do have a point here, but then we are about to go into the details. :-)
What
MCI_ST_FBCLKENmeans, is that the internal logic in the primecell can decide whether to use the signal from clockout pin or the feebackclock pin, when its latching incoming signals on the data bus.That said, we for sure need a dt binding for bit as well, since this is not possible to figure out how pins are routed in runtime.
Quoted 7 lines
Also, I do believe it is very closely related to the other sigdir pins, since it's all about how pins is being routed, even if it's as you say - in this case a matter of signal directions.
So, I guess we have two options here; Either move the
MCI_ST_FBCLKENout of the signal-direction binding and invent a separate binding for it, or just keep them as is.
If they are very closely related I guess that will become very clear when you document it in the requested explicit bindings, so no strong opinion here. I'd probably ACK either version.
Quoted 17 lines
Quoted 4 lines
Maybe we should just have single strings for these things in the binding instead, like:
Review line 128
Quoted 10 lines
(quoted diff) +4
-0@@ -118,6 +119,10 @@ bus-width = <4>; mmc-cap-sd-highspeed; mmc-cap-mmc-highspeed; + st,signal-direction-data2; + st,signal-direction-cmd; + st,signal-direction-data0; + st,feedback-clock-enable; vmmc-supply = <&ab8500_ldo_aux3_reg>; vqmmc-supply = <&vmmci>; pinctrl-names = "default", "sleep";I guess this is an option. To me it just seems a bit silly to have one separate binding for each single bit, but maybe it becomes clearer?
The idea with device trees is to be very human-readable, so I guess if you have preprocessor macro things |:ing the arguments together to a singular 32bit value it serves the same purpose. Arguably this version is even easier for a human to read though.
What we should avoid is using magic number assignments to save space (e.g. have magic numbers in the tree rather than readable strings) so I lean toward this, but it's admittedly in a grey area, so again no strong opinion.
Yours,
Linus Walleij
PATCH 4/20 mmc: mmci: Move signal directions bits into DT include file
Quoted 60 lines · Linus Walleij
Quoted 24 lines · Ulf Hansson
Quoted 5 lines · Linus Walleij
Quoted 3 lines · Ulf Hansson
These bits is currently used from platform data, but will be needed from DT as well, so let's make them available.
Quoted 8 lines
Quoted 1 line
Signed-off-by Ulf Hansson <[email protected]>(...)
include/dt-bindings/mmc/mmci.h line 19
Quoted 3 lines
include/dt-bindings/mmc/mmci.h new file +3
-0+#define MCI_ST_DATA31DIREN (1 << 5) +#define MCI_ST_FBCLKEN (1 << 7) +#define MCI_ST_DATA74DIREN (1 << 8)Isn't
MCI_ST_FBCLKEN= feedback clock enable and nothing to do with directions really?You do have a point here, but then we are about to go into the details. :-)
What
MCI_ST_FBCLKENmeans, is that the internal logic in the primecell can decide whether to use the signal from clockout pin or the feebackclock pin, when its latching incoming signals on the data bus.That said, we for sure need a dt binding for bit as well, since this is not possible to figure out how pins are routed in runtime.
Quoted 7 lines
Also, I do believe it is very closely related to the other sigdir pins, since it's all about how pins is being routed, even if it's as you say - in this case a matter of signal directions.
So, I guess we have two options here; Either move the
MCI_ST_FBCLKENout of the signal-direction binding and invent a separate binding for it, or just keep them as is.If they are very closely related I guess that will become very clear when you document it in the requested explicit bindings, so no strong opinion here. I'd probably ACK either version.
Quoted 17 lines
Quoted 4 lines
Maybe we should just have single strings for these things in the binding instead, like:
Review line 128
Quoted 10 lines
(quoted diff) +4
-0@@ -118,6 +119,10 @@ bus-width = <4>; mmc-cap-sd-highspeed; mmc-cap-mmc-highspeed; + st,signal-direction-data2; + st,signal-direction-cmd; + st,signal-direction-data0; + st,feedback-clock-enable; vmmc-supply = <&ab8500_ldo_aux3_reg>; vqmmc-supply = <&vmmci>; pinctrl-names = "default", "sleep";I guess this is an option. To me it just seems a bit silly to have one separate binding for each single bit, but maybe it becomes clearer?
The idea with device trees is to be very human-readable, so I guess if you have preprocessor macro things |:ing the arguments together to a singular 32bit value it serves the same purpose. Arguably this version is even easier for a human to read though.
Quoted 4 lines
What we should avoid is using magic number assignments to save space (e.g. have magic numbers in the tree rather than readable strings) so I lean toward this, but it's admittedly in a grey area, so again no strong opinion.
Thanks for your advise. I seems like a good idea to move to use readable strings instead.
In that way, we also get the clean cut between signal directions and the feedback clock pin.
Kind regards
Ulf Hansson
Quoted 3 lines
Yours,
Linus Walleij
PATCH 5/20 mmc: mmci: Add DT bindings for signal direction
In reply to Ulf HanssonSome variants have support for indicating the bus signal directions, which currently are configured through platform data.
Add corresponding DT bindings to enable us to move away from using the platform data.
--- Documentation/devicetree/bindings/mmc/mmci.txt | 4 ++++ drivers/mmc/host/mmci.c | 7 +++++++ 2 files changed, 11 insertions(+)
Documentation/devicetree/bindings/mmc/mmci.txt +4 -0
@@ -15,6 +15,7 @@ Optional properties: - mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. - mmc-cap-sd-highspeed : indicates whether SD is high speed capable. - vqmmc-supply : phandle to the regulator device tree node. +- signal-direction : a bit pattern, indicating bus signals directions. Example:
@@ -37,6 +38,9 @@ sdi0_per1 at 80126000 { mmc-cap-mmc-highspeed; cd-gpios = <&gpio2 31 0x4>; // 95 + signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN | + MCI_ST_DATA0DIREN | MCI_ST_FBCLKEN)>; + vmmc-supply = <&ab8500_ldo_aux3_reg>; vqmmc-supply = <&vmmci>;
drivers/mmc/host/mmci.c +7 -0
@@ -1390,8 +1390,15 @@ static struct mmc_host_ops mmci_ops = {static void mmci_dt_populate_generic_pdata (struct device_node *np,struct mmci_platform_data *pdata) { +u32 sigdir =0 ;int bus_width =0 ; +if (!of_property_read_u32 (np,"signal-direction" , &sigdir)) { + sigdir &=MCI_ST_DATA2DIREN |MCI_ST_CMDDIREN |MCI_ST_DATA0DIREN | +MCI_ST_DATA31DIREN |MCI_ST_FBCLKEN |MCI_ST_DATA74DIREN ; + pdata->sigdir = sigdir; + } + pdata->gpio_wp =of_get_named_gpio (np,"wp-gpios" ,0 ); pdata->gpio_cd =of_get_named_gpio (np,"cd-gpios" ,0 );
Signature · 1 line
1.7.9.5
PATCH 5/20 mmc: mmci: Add DT bindings for signal direction
Quoted 17 lines · Ulf Hansson
Some variants have support for indicating the bus signal directions, which currently are configured through platform data.
Add corresponding DT bindings to enable us to move away from using the platform data.
Signed-off-by Ulf Hansson <[email protected]>--- Documentation/devicetree/bindings/mmc/mmci.txt | 4 ++++ drivers/mmc/host/mmci.c | 7 +++++++ 2 files changed, 11 insertions(+)Documentation/devicetree/bindings/mmc/mmci.txt +0
-0
Documentation/devicetree/bindings/mmc/mmci.txt Optional properties: · line 18
Quoted 4 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1
-0@@ -15,6 +15,7 @@ Optional properties: - mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. - mmc-cap-sd-highspeed : indicates whether SD is high speed capable. - vqmmc-supply : phandle to the regulator device tree node. +- signal-direction : a bit pattern, indicating bus signals directions.
You need to define the bit positions.
Documentation/devicetree/bindings/mmc/mmci.txt sdi0_per1 at 80126000 { · line 42
Quoted 9 lines
Documentation/devicetree/bindings/mmc/mmci.txt +2
-0Example:@@ -37,6 +38,9 @@ sdi0_per1 at 80126000 { mmc-cap-mmc-highspeed; cd-gpios = <&gpio2 31 0x4>; // 95 + signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN | + MCI_ST_DATA0DIREN | MCI_ST_FBCLKEN)>;
The "ST" here is for STMicro or some ST based company? Use the vendor prefix here.
I don't really understand why you need to specify the direction here. Data lines are bi-directional and cmd and clk are outputs.
Quoted 9 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1
-0+ vmmc-supply = <&ab8500_ldo_aux3_reg>; vqmmc-supply = <&vmmci>;drivers/mmc/host/mmci.c +0
-0
drivers/mmc/host/mmci.c static struct mmc_host_ops mmci_ops = { · line 1398
Quoted 9 lines
drivers/mmc/host/mmci.c +4
-0@@ -1390,8 +1390,15 @@ static struct mmc_host_ops mmci_ops = {static void mmci_dt_populate_generic_pdata (struct device_node *np,struct mmci_platform_data *pdata) { +u32 sigdir =0 ;int bus_width =0 ; +if (!of_property_read_u32 (np,"signal-direction" , &sigdir)) { + sigdir &=MCI_ST_DATA2DIREN |MCI_ST_CMDDIREN |MCI_ST_DATA0DIREN | +MCI_ST_DATA31DIREN |MCI_ST_FBCLKEN |MCI_ST_DATA74DIREN ;
Spaces around the '|'.
Rob
PATCH 5/20 mmc: mmci: Add DT bindings for signal direction
Quoted 13 lines · Rob Herring
Quoted 12 lines · Ulf Hansson
Some variants have support for indicating the bus signal directions, which currently are configured through platform data.
Add corresponding DT bindings to enable us to move away from using the platform data.
Signed-off-by Ulf Hansson <[email protected]>--- Documentation/devicetree/bindings/mmc/mmci.txt | 4 ++++ drivers/mmc/host/mmci.c | 7 +++++++ 2 files changed, 11 insertions(+)
Quoted 11 lines
Documentation/devicetree/bindings/mmc/mmci.txt Optional properties: · line 18
Quoted 9 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1
-0@@ -15,6 +15,7 @@ Optional properties: - mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. - mmc-cap-sd-highspeed : indicates whether SD is high speed capable. - vqmmc-supply : phandle to the regulator device tree node. +- signal-direction : a bit pattern, indicating bus signals directions.You need to define the bit positions.
May I refer to the <dt-bindings/mmc/mmci.h> instead? To me, it seems a bit silly to duplicate that information in the documentation.
Quoted 8 lines
Quoted 8 lines
Documentation/devicetree/bindings/mmc/mmci.txt +0
-0Example:@@ -37,6 +38,9 @@ sdi0_per1 at 80126000 { mmc-cap-mmc-highspeed; cd-gpios = <&gpio2 31 0x4>; // 95
Quoted 5 lines
Documentation/devicetree/bindings/mmc/mmci.txt sdi0_per1 at 80126000 { · line 42
Quoted 2 lines
Documentation/devicetree/bindings/mmc/mmci.txt +2
-0+ signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN | + MCI_ST_DATA0DIREN | MCI_ST_FBCLKEN)>;The "ST" here is for STMicro or some ST based company? Use the vendor prefix here.
We have way back already concluded to use "ST" as prefix for all STMicro specific defines used in mmci. Please have a look at drivers/mmc/host/mmci.h.
I would prefer to keep these aligned with the other defines, though if you have strong feelings about it, sure I can change them.
Quoted 4 lines
I don't really understand why you need to specify the direction here. Data lines are bi-directional and cmd and clk are outputs.
These bits are being used when you have an external levelshifter.
Without going into too much details, it all depends on how the different pins are connected to the levelshifter, which isn't possible to figure out in runtime.
Quoted 15 lines
Quoted 15 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1
-0+ vmmc-supply = <&ab8500_ldo_aux3_reg>; vqmmc-supply = <&vmmci>;drivers/mmc/host/mmci.c +1
-0@@ -1390,8 +1390,15 @@ static struct mmc_host_ops mmci_ops = {static void mmci_dt_populate_generic_pdata (struct device_node *np,struct mmci_platform_data *pdata) { +u32 sigdir =0 ;int bus_width =0 ;
Quoted 7 lines
drivers/mmc/host/mmci.c static struct mmc_host_ops mmci_ops = { · line 1398
Quoted 3 lines
drivers/mmc/host/mmci.c +3
-0+if (!of_property_read_u32 (np,"signal-direction" , &sigdir)) { + sigdir &=MCI_ST_DATA2DIREN |MCI_ST_CMDDIREN |MCI_ST_DATA0DIREN | +MCI_ST_DATA31DIREN |MCI_ST_FBCLKEN |MCI_ST_DATA74DIREN ;Spaces around the '|'.
Rob
Kind regards
Ulf Hansson
PATCH 5/20 mmc: mmci: Add DT bindings for signal direction
Quoted 26 lines · Ulf Hansson
Quoted 13 lines · Rob Herring
Quoted 12 lines · Ulf Hansson
Some variants have support for indicating the bus signal directions, which currently are configured through platform data.
Add corresponding DT bindings to enable us to move away from using the platform data.
Signed-off-by Ulf Hansson <[email protected]>--- Documentation/devicetree/bindings/mmc/mmci.txt | 4 ++++ drivers/mmc/host/mmci.c | 7 +++++++ 2 files changed, 11 insertions(+)Quoted 11 lines
Documentation/devicetree/bindings/mmc/mmci.txt Optional properties: · line 18
Quoted 9 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1
-0@@ -15,6 +15,7 @@ Optional properties: - mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. - mmc-cap-sd-highspeed : indicates whether SD is high speed capable. - vqmmc-supply : phandle to the regulator device tree node. +- signal-direction : a bit pattern, indicating bus signals directions.You need to define the bit positions.
Quoted 2 lines
May I refer to the <
dt-bindings/mmc/mmci.h> instead? To me, it seems a bit silly to duplicate that information in the documentation.
We really prefer that the binding doc stand on it's own such that you could write the header based on the binding.
Quoted 14 lines
Quoted 8 lines
Quoted 8 lines
Documentation/devicetree/bindings/mmc/mmci.txt +0
-0Example:@@ -37,6 +38,9 @@ sdi0_per1 at 80126000 { mmc-cap-mmc-highspeed; cd-gpios = <&gpio2 31 0x4>; // 95Quoted 5 lines
Documentation/devicetree/bindings/mmc/mmci.txt sdi0_per1 at 80126000 { · line 42
Quoted 2 lines
Documentation/devicetree/bindings/mmc/mmci.txt +2
-0+ signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN | + MCI_ST_DATA0DIREN | MCI_ST_FBCLKEN)>;The "ST" here is for STMicro or some ST based company? Use the vendor prefix here.
Quoted 5 lines
We have way back already concluded to use "ST" as prefix for all STMicro specific defines used in mmci. Please have a look at
drivers/mmc/host/mmci.h.
I would prefer to keep these aligned with the other defines, though if you have strong feelings about it, sure I can change them.
I don't mean change the defines. I mean name the property "st,signal-direction" and indicate it only applies to the STMicro variant.
Quoted 9 lines
Quoted 3 lines
I don't really understand why you need to specify the direction here. Data lines are bi-directional and cmd and clk are outputs.
These bits are being used when you have an external levelshifter.
Without going into too much details, it all depends on how the different pins are connected to the levelshifter, which isn't possible to figure out in runtime.
Okay.
Rob
PATCH 6/20 mmc: mmci: Use the common mmc DT parser
In reply to Ulf HanssonLet mmci DT parser only handle the specific bindings related to mmci and extend the DT support by converting to the common mmc DT parser.
While both DT and platform data exist, DT takes precedence. If there are supplied DT data, the card detect and write protect GPIOS are enforced to be provided through it.
--- drivers/mmc/host/mmci.c | 92 +++++++++++++++++------------------------------ 1 file changed, 33 insertions(+), 59 deletions(-)
drivers/mmc/host/mmci.c +33 -59
@@ -1386,58 +1386,31 @@ static struct mmc_host_ops mmci_ops = { .start_signal_voltage_switch = mmci_sig_volt_switch, }; -#ifdef CONFIG_OF static void mmci_dt_populate_generic_pdata (struct device_node *np,struct mmci_platform_data *pdata) {u32 sigdir =0 ; -int bus_width =0 ;if (!of_property_read_u32 (np,"signal-direction" , &sigdir)) { sigdir &=MCI_ST_DATA2DIREN |MCI_ST_CMDDIREN |MCI_ST_DATA0DIREN |MCI_ST_DATA31DIREN |MCI_ST_FBCLKEN |MCI_ST_DATA74DIREN ; pdata->sigdir = sigdir; } +} - pdata->gpio_wp =of_get_named_gpio (np,"wp-gpios" ,0 ); - pdata->gpio_cd =of_get_named_gpio (np,"cd-gpios" ,0 ); - -if (of_get_property (np,"cd-inverted" ,NULL )) - pdata->cd_invert = true; -else - pdata->cd_invert = false; - -of_property_read_u32 (np,"max-frequency" , &pdata->f_max); -if (!pdata->f_max) -pr_warn ("%s has no 'max-frequency' property\n" , np->full_name); +static int mmci_of_parse (struct device_node *np,struct mmc_host *mmc) +{ +int ret =mmc_of_parse (mmc); +if (ret) +return ret;if (of_get_property (np,"mmc-cap-mmc-highspeed" ,NULL )) - pdata->capabilities |=MMC_CAP_MMC_HIGHSPEED ; + mmc->caps |=MMC_CAP_MMC_HIGHSPEED ;if (of_get_property (np,"mmc-cap-sd-highspeed" ,NULL )) - pdata->capabilities |=MMC_CAP_SD_HIGHSPEED ; + mmc->caps |=MMC_CAP_SD_HIGHSPEED ; -of_property_read_u32 (np,"bus-width" , &bus_width); -switch (bus_width) { -case 0 : -/* No bus-width supplied. */ -break ; -case 4 : - pdata->capabilities |=MMC_CAP_4_BIT_DATA ; -break ; -case 8 : - pdata->capabilities |=MMC_CAP_8_BIT_DATA ; -break ; -default : -pr_warn ("%s: Unsupported bus width\n" , np->full_name); - } -} -#else -static void mmci_dt_populate_generic_pdata (struct device_node *np, -struct mmci_platform_data *pdata) -{ -return ; +return 0 ; } -#endif static int mmci_probe (struct amba_device *dev,const struct amba_id *id)
@@ -1472,6 +1445,10 @@ static int mmci_probe(struct amba_device *dev,if (!mmc)return -ENOMEM ; + ret =mmci_of_parse (np, mmc); +if (ret) + goto host_free; + host =mmc_priv (mmc); host->mmc = mmc;
@@ -1525,14 +1502,15 @@ static int mmci_probe(struct amba_device *dev,else mmc->f_min =DIV_ROUND_UP (host->mclk,512 );/* -* If the platform data supplies a maximum operating -* frequency, this takes precedence. Else, we fall back -* to using the module parameter, which has a (low) -* default value in case it is not specified. Either -* value must not exceed the clock rate into the block, -* of course. +* If no maximum operating frequency is supplied, fall back to use +* the module parameter, which has a (low) default value in case it +* is not specified. Either value must not exceed the clock rate into +* the block, of course. Also note that DT takes precedence over +* platform data. */ -if (plat->f_max) +if (mmc->f_max) + mmc->f_max =min (host->mclk, mmc->f_max); +else if (plat->f_max) mmc->f_max =min (host->mclk, plat->f_max);else mmc->f_max =min (host->mclk, fmax);
@@ -1545,11 +1523,14 @@ static int mmci_probe(struct amba_device *dev,else if (plat->ocr_mask)dev_warn (mmc_dev (mmc),"Platform OCR mask is ignored\n" ); - mmc->caps = plat->capabilities; - mmc->caps2 = plat->capabilities2; -if (!plat->cd_invert) - mmc->caps2 |=MMC_CAP2_CD_ACTIVE_HIGH ; - mmc->caps2 |=MMC_CAP2_RO_ACTIVE_HIGH ; +/* DT takes precedence over platform data. */ + mmc->caps = np ? mmc->caps : plat->capabilities; + mmc->caps2 = np ? mmc->caps2 : plat->capabilities2; +if (!np) { +if (!plat->cd_invert) + mmc->caps2 |=MMC_CAP2_CD_ACTIVE_HIGH ; + mmc->caps2 |=MMC_CAP2_RO_ACTIVE_HIGH ; + }if (variant->busy_detect) { mmci_ops.card_busy = mmci_card_busy;
@@ -1561,7 +1542,7 @@ static int mmci_probe(struct amba_device *dev, mmc->ops = &mmci_ops;/* We support these PM capabilities. */ - mmc->pm_caps =MMC_PM_KEEP_POWER ; + mmc->pm_caps |=MMC_PM_KEEP_POWER ;/* * We can do SGIO
@@ -1598,20 +1579,13 @@ static int mmci_probe(struct amba_device *dev,writel (0 , host->base +MMCIMASK1 );writel (0xfff , host->base +MMCICLEAR ); -if (plat->gpio_cd == -EPROBE_DEFER ) { - ret = -EPROBE_DEFER ; - goto clk_disable; - } -if (gpio_is_valid (plat->gpio_cd)) { +/* If DT, cd/wp gpios must be supplied through it. */ +if (!np &&gpio_is_valid (plat->gpio_cd)) { ret =mmc_gpio_request_cd (mmc, plat->gpio_cd,0 );if (ret) goto clk_disable; } -if (plat->gpio_wp == -EPROBE_DEFER ) { - ret = -EPROBE_DEFER ; - goto clk_disable; - } -if (gpio_is_valid (plat->gpio_wp)) { +if (!np &&gpio_is_valid (plat->gpio_wp)) { ret =mmc_gpio_request_ro (mmc, plat->gpio_wp);if (ret) goto clk_disable;
Signature · 1 line
1.7.9.5
PATCH 7/20 ARM: ux500: Add mmci signal directions in DT for href
In reply to Ulf Hansson--- arch/arm/boot/dts/ste-href.dtsi | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm/boot/dts/ste-href.dtsi +5 -0
@@ -10,6 +10,7 @@ */ #include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/mmc/mmci.h> #include "ste-dbx5x0.dtsi" #include "ste-href-family-pinctrl.dtsi"
@@ -118,6 +119,10 @@ bus-width = <4>; mmc-cap-sd-highspeed; mmc-cap-mmc-highspeed; + signal-direction = <(MCI_ST_DATA2DIREN | + MCI_ST_CMDDIREN | + MCI_ST_DATA0DIREN | + MCI_ST_FBCLKEN)>; vmmc-supply = <&ab8500_ldo_aux3_reg>; vqmmc-supply = <&vmmci>; pinctrl-names = "default", "sleep";
Signature · 1 line
1.7.9.5
PATCH 8/20 ARM: ux500: Convert to the common mmc DT bindings for highspeed mode
In reply to Ulf HanssonThe mmci host driver supports the common mmc DT parser, which enables us to use the use common names instead.
--- arch/arm/boot/dts/ste-ccu9540.dts | 6 +++--- arch/arm/boot/dts/ste-href.dtsi | 8 ++++---- arch/arm/boot/dts/ste-snowball.dts | 4 ++-- 3 files changed, 9 insertions(+), 9 deletions(-)
arch/arm/boot/dts/ste-ccu9540.dts +3 -3
@@ -38,8 +38,8 @@ arm,primecell-periphid = <0x10480180>; max-frequency = <100000000>; bus-width = <4>; - mmc-cap-sd-highspeed; - mmc-cap-mmc-highspeed; + cap-sd-highspeed; + cap-mmc-highspeed; vmmc-supply = <&ab8500_ldo_aux3_reg>; cd-gpios = <&gpio7 6 0x4>; // 230
@@ -63,7 +63,7 @@ arm,primecell-periphid = <0x10480180>; max-frequency = <100000000>; bus-width = <8>; - mmc-cap-mmc-highspeed; + cap-mmc-highspeed; vmmc-supply = <&ab8500_ldo_aux2_reg>; status = "okay";
arch/arm/boot/dts/ste-href.dtsi +4 -4
@@ -117,8 +117,8 @@ arm,primecell-periphid = <0x10480180>; max-frequency = <100000000>; bus-width = <4>; - mmc-cap-sd-highspeed; - mmc-cap-mmc-highspeed; + cap-sd-highspeed; + cap-mmc-highspeed; signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN | MCI_ST_DATA0DIREN |
@@ -149,7 +149,7 @@ arm,primecell-periphid = <0x10480180>; max-frequency = <100000000>; bus-width = <8>; - mmc-cap-mmc-highspeed; + cap-mmc-highspeed; pinctrl-names = "default", "sleep"; pinctrl-0 = <&sdi2_default_mode>; pinctrl-1 = <&sdi2_sleep_mode>;
@@ -162,7 +162,7 @@ arm,primecell-periphid = <0x10480180>; max-frequency = <100000000>; bus-width = <8>; - mmc-cap-mmc-highspeed; + cap-mmc-highspeed; vmmc-supply = <&ab8500_ldo_aux2_reg>; pinctrl-names = "default", "sleep"; pinctrl-0 = <&sdi4_default_mode>;
arch/arm/boot/dts/ste-snowball.dts +2 -2
@@ -156,7 +156,7 @@ arm,primecell-periphid = <0x10480180>; max-frequency = <100000000>; bus-width = <4>; - mmc-cap-mmc-highspeed; + cap-mmc-highspeed; vmmc-supply = <&ab8500_ldo_aux3_reg>; vqmmc-supply = <&vmmci>; pinctrl-names = "default", "sleep";
@@ -195,7 +195,7 @@ arm,primecell-periphid = <0x10480180>; max-frequency = <100000000>; bus-width = <8>; - mmc-cap-mmc-highspeed; + cap-mmc-highspeed; vmmc-supply = <&ab8500_ldo_aux2_reg>; pinctrl-names = "default", "sleep"; pinctrl-0 = <&sdi4_default_mode>;
Signature · 1 line
1.7.9.5
PATCH 8/20 ARM: ux500: Convert to the common mmc DT bindings for highspeed mode
Quoted 4 lines · Ulf Hansson
The mmci host driver supports the common mmc DT parser, which enables us to use the use common names instead.
Signed-off-by Ulf Hansson <[email protected]>
Yours,
Linus Walleij
PATCH 9/20 ARM: nomadik: Convert to the common mmc DT bindings for highspeed mode
In reply to Ulf HanssonThe mmci host driver supports the common mmc DT parser, which enables us to use the use common names instead.
--- arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/ste-nomadik-stn8815.dtsi +2 -2
@@ -840,8 +840,8 @@ interrupts = <22>; max-frequency = <48000000>; bus-width = <4>; - mmc-cap-mmc-highspeed; - mmc-cap-sd-highspeed; + cap-mmc-highspeed; + cap-sd-highspeed; cd-gpios = <&gpio3 15 0x1>; cd-inverted; pinctrl-names = "default";
Signature · 1 line
1.7.9.5
PATCH 9/20 ARM: nomadik: Convert to the common mmc DT bindings for highspeed mode
Quoted 5 lines · Ulf Hansson
The mmci host driver supports the common mmc DT parser, which enables us to use the use common names instead.
Cc Alessandro Rubini <[email protected]>Signed-off-by Ulf Hansson <[email protected]>
Yours,
Linus Walleij
PATCH 10/20 ARM: u300: Convert to the common mmc DT bindings for highspeed mode
In reply to Ulf HanssonThe mmci host driver supports the common mmc DT parser, which enables us to use the use common names instead.
--- arch/arm/boot/dts/ste-u300.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/ste-u300.dts +2 -2
@@ -442,8 +442,8 @@ clock-names = "apb_pclk", "mclk"; max-frequency = <24000000>; bus-width = <4>; // SD-card slot - mmc-cap-mmc-highspeed; - mmc-cap-sd-highspeed; + cap-mmc-highspeed; + cap-sd-highspeed; cd-gpios = <&gpio 12 0x4>; cd-inverted; vmmc-supply = <&ab3100_ldo_g_reg>;
Signature · 1 line
1.7.9.5
PATCH 10/20 ARM: u300: Convert to the common mmc DT bindings for highspeed mode
Quoted 4 lines · Ulf Hansson
The mmci host driver supports the common mmc DT parser, which enables us to use the use common names instead.
Signed-off-by Ulf Hansson <[email protected]>
Yours,
Linus Walleij
PATCH 11/20 mmc: mmci: Mark the DT bindings for highspeed mode as deprecated
In reply to Ulf HanssonThe common mmc DT parser supports bindings for highspeed mode, thus there are no need for mmci to provide it's own versions for these. Mark them as deprecated in the documentation.
--- Documentation/devicetree/bindings/mmc/mmci.txt | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
Documentation/devicetree/bindings/mmc/mmci.txt +6 -4
@@ -12,11 +12,13 @@ Required properties: - vmmc-supply : phandle to the regulator device tree node. Optional properties: -- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. -- mmc-cap-sd-highspeed : indicates whether SD is high speed capable. - vqmmc-supply : phandle to the regulator device tree node. - signal-direction : a bit pattern, indicating bus signals directions. +Deprecated properties: +- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. +- mmc-cap-sd-highspeed : indicates whether SD is high speed capable. + Example: sdi0_per1 at 80126000 {
@@ -34,8 +36,8 @@ sdi0_per1 at 80126000 { max-frequency = <100000000>; bus-width = <4>; - mmc-cap-sd-highspeed; - mmc-cap-mmc-highspeed; + cap-sd-highspeed; + cap-mmc-highspeed; cd-gpios = <&gpio2 31 0x4>; // 95 signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN |
Signature · 1 line
1.7.9.5
PATCH 12/20 mmc: mmci: Enable MMC_CAP_CMD23
In reply to Ulf HanssonThis is pure software configuration, which mmci has been supporting for a while. Let's enable it as default so we can take benefit from it.
--- drivers/mmc/host/mmci.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/mmc/host/mmci.c +3 -0
@@ -1532,6 +1532,9 @@ static int mmci_probe(struct amba_device *dev, mmc->caps2 |=MMC_CAP2_RO_ACTIVE_HIGH ; } +/* We support these capabilities. */ + mmc->caps |=MMC_CAP_CMD23 ; +if (variant->busy_detect) { mmci_ops.card_busy = mmci_card_busy;mmci_write_datactrlreg (host,MCI_ST_DPSM_BUSYMODE );
Signature · 1 line
1.7.9.5
PATCH 13/20 ARM: ux500: Add the mmc capabilities flags to DT
In reply to Ulf Hansson--- arch/arm/boot/dts/ste-href.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm/boot/dts/ste-href.dtsi +6 -0
@@ -119,10 +119,13 @@ bus-width = <4>; cap-sd-highspeed; cap-mmc-highspeed; + full-pwr-cycle; signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN | MCI_ST_DATA0DIREN | MCI_ST_FBCLKEN)>; + sd-uhs-sdr12; + sd-uhs-sdr25; vmmc-supply = <&ab8500_ldo_aux3_reg>; vqmmc-supply = <&vmmci>; pinctrl-names = "default", "sleep";
@@ -137,6 +140,7 @@ arm,primecell-periphid = <0x10480180>; max-frequency = <100000000>; bus-width = <4>; + non-removable; pinctrl-names = "default", "sleep"; pinctrl-0 = <&sdi1_default_mode>; pinctrl-1 = <&sdi1_sleep_mode>;
@@ -150,6 +154,7 @@ max-frequency = <100000000>; bus-width = <8>; cap-mmc-highspeed; + non-removable; pinctrl-names = "default", "sleep"; pinctrl-0 = <&sdi2_default_mode>; pinctrl-1 = <&sdi2_sleep_mode>;
@@ -163,6 +168,7 @@ max-frequency = <100000000>; bus-width = <8>; cap-mmc-highspeed; + non-removable; vmmc-supply = <&ab8500_ldo_aux2_reg>; pinctrl-names = "default", "sleep"; pinctrl-0 = <&sdi4_default_mode>;
Signature · 1 line
1.7.9.5
PATCH 13/20 ARM: ux500: Add the mmc capabilities flags to DT
Quoted 1 line · Ulf Hansson
Signed-off-by Ulf Hansson <[email protected]>
Yours,
Linus Walleij
PATCH 14/20 regulator: db8500-prcmu: Set 1.8V as a fixed voltage for vsmps2
In reply to Ulf HanssonThis regulator is used for system IO and is fixed to 1.8V. Let's give consumers the option to fetch the voltage level.
---
Hi Mark and Liam,
Then intent is to merge this complete patchset all together to not break anything. Thus I only request for an ack for this particular patch.
Kind regards
Ulf Hansson
--- drivers/regulator/db8500-prcmu.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/regulator/db8500-prcmu.c +2 -0
@@ -263,6 +263,8 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = { .ops = &db8500_regulator_ops, .type = REGULATOR_VOLTAGE, .owner = THIS_MODULE, + .fixed_uV = 1800000, + .n_voltages = 1, }, .exclude_from_power_state = true, },
Signature · 1 line
1.7.9.5
Mark Brown
maintainerPATCH 14/20 regulator: db8500-prcmu: Set 1.8V as a fixed voltage for vsmps2
Quoted 2 lines · Ulf Hansson
Then intent is to merge this complete patchset all together to not break anything. Thus I only request for an ack for this particular patch.
TBH given that we're at -rc7 and you're unlikely to get the rest of
whatever this is merged before the merge window it's as easy for me to
just apply it. Make sense?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140321/7f798cb9/attachment.sig>
PATCH 14/20 regulator: db8500-prcmu: Set 1.8V as a fixed voltage for vsmps2
Quoted 8 lines · Mark Brown
Quoted 2 lines · Ulf Hansson
Then intent is to merge this complete patchset all together to not break anything. Thus I only request for an ack for this particular patch.
TBH given that we're at -rc7 and you're unlikely to get the rest of whatever this is merged before the merge window it's as easy for me to just apply it. Make sense?
Absolutely, go ahead! Thanks!
Kind regards
Uffe
Quoted 6 lines
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Mark Brown
maintainerPATCH 14/20 regulator: db8500-prcmu: Set 1.8V as a fixed voltage for vsmps2
In reply to Ulf HanssonQuoted 2 lines · Ulf Hansson
This regulator is used for system IO and is fixed to 1.8V. Let's give consumers the option to fetch the voltage level.
Applied, thanks. If the rest of the series can get applied I can
easily drop this one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140321/cda303ca/attachment-0001.sig>
PATCH 15/20 ARM: ux500: Add a vmmc regulator through DT for the poped eMMC for href
In reply to Ulf HanssonAdd a node in DT for the proper regulator which means we can move away from the mmci platform data which currently holds the corresponding OCR mask.
The mmci driver can then calculate the OCR mask based on the voltages supported by the regulator, instead of relying on the platform data.
--- arch/arm/boot/dts/ste-href.dtsi | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/ste-href.dtsi +1 -0
@@ -155,6 +155,7 @@ bus-width = <8>; cap-mmc-highspeed; non-removable; + vmmc-supply = <&db8500_vsmps2_reg>; pinctrl-names = "default", "sleep"; pinctrl-0 = <&sdi2_default_mode>; pinctrl-1 = <&sdi2_sleep_mode>;
Signature · 1 line
1.7.9.5
PATCH 15/20 ARM: ux500: Add a vmmc regulator through DT for the poped eMMC for href
Quoted 17 lines · Ulf Hansson
Add a node in DT for the proper regulator which means we can move away from the mmci platform data which currently holds the corresponding OCR mask.
The mmci driver can then calculate the OCR mask based on the voltages supported by the regulator, instead of relying on the platform data.
Signed-off-by Ulf Hansson <[email protected]>--- arch/arm/boot/dts/ste-href.dtsi | 1 + 1 file changed, 1 insertion(+)arch/arm/boot/dts/ste-href.dtsi +0
-0
arch/arm/boot/dts/ste-href.dtsi line 158
Quoted 4 lines
arch/arm/boot/dts/ste-href.dtsi +1
-0@@ -155,6 +155,7 @@ bus-width = <8>; cap-mmc-highspeed; non-removable; + vmmc-supply = <&db8500_vsmps2_reg>;
Don't you need a similar oneliner to ste-snowball.dts? That board is not including this file...
Yours,
Linus Walleij
PATCH 15/20 ARM: ux500: Add a vmmc regulator through DT for the poped eMMC for href
Quoted 14 lines · Linus Walleij
Quoted 12 lines · Ulf Hansson
Add a node in DT for the proper regulator which means we can move away from the mmci platform data which currently holds the corresponding OCR mask.
The mmci driver can then calculate the OCR mask based on the voltages supported by the regulator, instead of relying on the platform data.
Signed-off-by Ulf Hansson <[email protected]>--- arch/arm/boot/dts/ste-href.dtsi | 1 + 1 file changed, 1 insertion(+)
Quoted 12 lines
arch/arm/boot/dts/ste-href.dtsi line 158
Quoted 9 lines
arch/arm/boot/dts/ste-href.dtsi +1
-0@@ -155,6 +155,7 @@ bus-width = <8>; cap-mmc-highspeed; non-removable; + vmmc-supply = <&db8500_vsmps2_reg>;Don't you need a similar oneliner to
ste-snowball.dts? That board is not including this file...
Snowball don't have the poped eMMC, which mean the vsmps2 is not used as the vmmc-supply.
I still plan to have a look at snowball, handled as a separate task, since I have heard people complaining about the SD card and/or the eMMC is working properly.
Kind regards
Ulf Hansson
Quoted 5 lines
Acked-by Linus Walleij <[email protected]>Yours,
Linus Walleij
PATCH 15/20 ARM: ux500: Add a vmmc regulator through DT for the poped eMMC for href
Quoted 28 lines · Ulf Hansson
Quoted 14 lines · Linus Walleij
Quoted 12 lines · Ulf Hansson
Add a node in DT for the proper regulator which means we can move away from the mmci platform data which currently holds the corresponding OCR mask.
The mmci driver can then calculate the OCR mask based on the voltages supported by the regulator, instead of relying on the platform data.
Signed-off-by Ulf Hansson <[email protected]>--- arch/arm/boot/dts/ste-href.dtsi | 1 + 1 file changed, 1 insertion(+)Quoted 12 lines
arch/arm/boot/dts/ste-href.dtsi line 158
Quoted 9 lines
arch/arm/boot/dts/ste-href.dtsi +1
-0@@ -155,6 +155,7 @@ bus-width = <8>; cap-mmc-highspeed; non-removable; + vmmc-supply = <&db8500_vsmps2_reg>;Don't you need a similar oneliner to
ste-snowball.dts? That board is not including this file...
Quoted 6 lines
Snowball don't have the poped eMMC, which mean the vsmps2 is not used as the vmmc-supply.
I still plan to have a look at snowball, handled as a separate task, since I have heard people complaining about the SD card and/or the eMMC is working properly.
/s /is /is not
Quoted 9 lines
Kind regards
Ulf HanssonQuoted 5 lines
Acked-by Linus Walleij <[email protected]>Yours,
Linus Walleij
PATCH 16/20 ARM: ux500: Remove redundant board file for mmci platform data
In reply to Ulf HanssonSince all platform data has been transfered to DT, we don't need the container for the mmci platform data anymore. Remove the file and the corresponding references to it's data.
--- arch/arm/mach-ux500/Makefile | 3 +- arch/arm/mach-ux500/board-mop500-sdi.c | 166 -------------------------------- arch/arm/mach-ux500/board-mop500.h | 5 - arch/arm/mach-ux500/cpu-db8500.c | 4 - 4 files changed, 1 insertion(+), 177 deletions(-) delete mode 100644 arch/arm/mach-ux500/board-mop500-sdi.c
arch/arm/mach-ux500/Makefile +1 -2
@@ -5,8 +5,7 @@ obj-y := cpu.o id.o timer.o pm.o obj-$(CONFIG_CACHE_L2X0) += cache-l2x0.o obj-$(CONFIG_UX500_SOC_DB8500) += cpu-db8500.o -obj-$(CONFIG_MACH_MOP500) += board-mop500-sdi.o \ - board-mop500-regulators.o \ +obj-$(CONFIG_MACH_MOP500) += board-mop500-regulators.o \ board-mop500-audio.o obj-$(CONFIG_SMP) += platsmp.o headsmp.o obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
arch/arm/mach-ux500/board-mop500-sdi.c deleted +0 -166
166 lines not on this page · raw message
arch/arm/mach-ux500/board-mop500.h +0 -5
@@ -8,12 +8,7 @@#define __BOARD_MOP500_H#include <linux/platform_data/asoc-ux500-msp.h> -#include <linux/amba/mmci.h> -extern struct mmci_platform_data mop500_sdi0_data; -extern struct mmci_platform_data mop500_sdi1_data; -extern struct mmci_platform_data mop500_sdi2_data; -extern struct mmci_platform_data mop500_sdi4_data;extern struct msp_i2s_platform_data msp0_platform_data;extern struct msp_i2s_platform_data msp1_platform_data;extern struct msp_i2s_platform_data msp2_platform_data;
arch/arm/mach-ux500/cpu-db8500.c +0 -4
@@ -146,10 +146,6 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {/* Requires call-back bindings. */ OF_DEV_AUXDATA ("arm,cortex-a9-pmu" ,0 ,"arm-pmu" , &db8500_pmu_platdata),/* Requires DMA bindings. */ -OF_DEV_AUXDATA ("arm,pl18x" ,0x80126000 ,"sdi0" , &mop500_sdi0_data), -OF_DEV_AUXDATA ("arm,pl18x" ,0x80118000 ,"sdi1" , &mop500_sdi1_data), -OF_DEV_AUXDATA ("arm,pl18x" ,0x80005000 ,"sdi2" , &mop500_sdi2_data), -OF_DEV_AUXDATA ("arm,pl18x" ,0x80114000 ,"sdi4" , &mop500_sdi4_data),OF_DEV_AUXDATA ("stericsson,ux500-msp-i2s" ,0x80123000 ,"ux500-msp-i2s.0" , &msp0_platform_data), OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80124000,
Signature · 1 line
1.7.9.5
PATCH 16/20 ARM: ux500: Remove redundant board file for mmci platform data
Quoted 5 lines · Ulf Hansson
Since all platform data has been transfered to DT, we don't need the container for the mmci platform data anymore. Remove the file and the corresponding references to it's data.
Signed-off-by Ulf Hansson <[email protected]>
Yours,
Linus Walleij
PATCH 17/20 mmc: mmci: Enforce DT for signal direction
In reply to Ulf HanssonRemove the option to provide signal direction configuration as platform data, enforce it through DT.
--- drivers/mmc/host/mmci.c | 24 ++++++++---------------- drivers/mmc/host/mmci.h | 1 + include/linux/amba/mmci.h | 4 ---- 3 files changed, 9 insertions(+), 20 deletions(-)
drivers/mmc/host/mmci.c +8 -16
@@ -34,6 +34,7 @@#include <linux/dmaengine.h> #include <linux/dma-mapping.h> #include <linux/amba/mmci.h> +#include <dt-bindings/mmc/mmci.h> #include <linux/pm_runtime.h> #include <linux/types.h> #include <linux/pinctrl/consumer.h>
@@ -1287,7 +1288,7 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)* indicating signal direction for the signals in * the SD/MMC bus and feedback-clock usage. */ - pwr |= host->plat->sigdir; + pwr |= host->sigdir;if (ios->bus_width ==MMC_BUS_WIDTH_4 ) pwr &= ~MCI_ST_DATA74DIREN ;
@@ -1386,24 +1387,18 @@ static struct mmc_host_ops mmci_ops = { .start_signal_voltage_switch = mmci_sig_volt_switch, }; -static void mmci_dt_populate_generic_pdata (struct device_node *np, -struct mmci_platform_data *pdata) -{ -u32 sigdir =0 ; - -if (!of_property_read_u32 (np,"signal-direction" , &sigdir)) { - sigdir &=MCI_ST_DATA2DIREN |MCI_ST_CMDDIREN |MCI_ST_DATA0DIREN | -MCI_ST_DATA31DIREN |MCI_ST_FBCLKEN |MCI_ST_DATA74DIREN ; - pdata->sigdir = sigdir; - } -} -static int mmci_of_parse (struct device_node *np,struct mmc_host *mmc) { +struct mmci_host *host =mmc_priv (mmc);int ret =mmc_of_parse (mmc);if (ret)return ret; +if (!of_property_read_u32 (np,"signal-direction" , &host->sigdir)) + host->sigdir &=MCI_ST_DATA2DIREN |MCI_ST_CMDDIREN | +MCI_ST_DATA0DIREN |MCI_ST_DATA31DIREN | +MCI_ST_FBCLKEN |MCI_ST_DATA74DIREN ; +if (of_get_property (np,"mmc-cap-mmc-highspeed" ,NULL )) mmc->caps |=MMC_CAP_MMC_HIGHSPEED ;if (of_get_property (np,"mmc-cap-sd-highspeed" ,NULL ))
@@ -1434,9 +1429,6 @@ static int mmci_probe(struct amba_device *dev,return -ENOMEM ; } -if (np) -mmci_dt_populate_generic_pdata (np, plat); -if (!devm_request_mem_region (&dev->dev, dev->res.start,resource_size (&dev->res),DRIVER_NAME ))return -ENOMEM ;
drivers/mmc/host/mmci.h +1 -0
@@ -188,6 +188,7 @@ struct mmci_host {u32 busy_status;bool vqmmc_enabled;struct mmci_platform_data *plat; +u32 sigdir;struct variant_data *variant;u8 hw_designer;
include/linux/amba/mmci.h +0 -4
@@ -5,7 +5,6 @@#define AMBA_MMCI_H #include <linux/mmc/host.h> -#include <dt-bindings/mmc/mmci.h> /* Just some dummy forwarding */ struct dma_chan ;
@@ -33,8 +32,6 @@ struct dma_chan;* @capabilities: the capabilities of the block as implemented in * this platform, signify anything MMC_CAP_* from mmc/host.h * @capabilities2: more capabilities, MMC_CAP2_* from mmc/host.h -* @sigdir: a bit field indicating for what bits in the MMC bus the host -* should enable signal direction indication. * @dma_filter: function used to select an appropriate RX and TX * DMA channel to be used for DMA, if and only if you're deploying the * generic DMA engine
@@ -57,7 +54,6 @@ struct mmci_platform_data {bool cd_invert;unsigned long capabilities;unsigned long capabilities2; -u32 sigdir;bool (*dma_filter)(struct dma_chan *chan,void *filter_param);void *dma_rx_param;void *dma_tx_param;
Signature · 1 line
1.7.9.5
PATCH 18/20 mmc: mmci: Enforce mmc capabilities through DT
In reply to Ulf HanssonRemove the option to provide the flags for mmc capabilities as platform data, enforce it through DT.
--- drivers/mmc/host/mmci.c | 2 -- include/linux/amba/mmci.h | 5 ----- 2 files changed, 7 deletions(-)
drivers/mmc/host/mmci.c +0 -2
@@ -1516,8 +1516,6 @@ static int mmci_probe(struct amba_device *dev,dev_warn (mmc_dev (mmc),"Platform OCR mask is ignored\n" );/* DT takes precedence over platform data. */ - mmc->caps = np ? mmc->caps : plat->capabilities; - mmc->caps2 = np ? mmc->caps2 : plat->capabilities2;if (!np) {if (!plat->cd_invert) mmc->caps2 |=MMC_CAP2_CD_ACTIVE_HIGH ;
include/linux/amba/mmci.h +0 -5
@@ -29,9 +29,6 @@ struct dma_chan;* @gpio_wp: read this GPIO pin to see if the card is write protected * @gpio_cd: read this GPIO pin to detect card insertion * @cd_invert: true if the gpio_cd pin value is active low -* @capabilities: the capabilities of the block as implemented in -* this platform, signify anything MMC_CAP_* from mmc/host.h -* @capabilities2: more capabilities, MMC_CAP2_* from mmc/host.h * @dma_filter: function used to select an appropriate RX and TX * DMA channel to be used for DMA, if and only if you're deploying the * generic DMA engine
@@ -52,8 +49,6 @@ struct mmci_platform_data {int gpio_wp;int gpio_cd;bool cd_invert; -unsigned long capabilities; -unsigned long capabilities2;bool (*dma_filter)(struct dma_chan *chan,void *filter_param);void *dma_rx_param;void *dma_tx_param;
Signature · 1 line
1.7.9.5
PATCH 19/20 mmc: mmci: Enforce DMA configuration through DT
In reply to Ulf HanssonRemove the option to provide DMA configuration as platform data, enforce it through DT.
--- drivers/mmc/host/mmci.c | 24 +----------------------- include/linux/amba/mmci.h | 17 ----------------- 2 files changed, 1 insertion(+), 40 deletions(-)
drivers/mmc/host/mmci.c +1 -23
@@ -367,7 +367,6 @@ static void mmci_init_sg(struct mmci_host *host, struct mmc_data *data)#ifdef CONFIG_DMA_ENGINE static void mmci_dma_setup (struct mmci_host *host) { -struct mmci_platform_data *plat = host->plat;const char *rxname, *txname;dma_cap_mask_t mask;
@@ -381,25 +380,6 @@ static void mmci_dma_setup(struct mmci_host *host)dma_cap_zero (mask);dma_cap_set (DMA_SLAVE , mask); -if (plat && plat->dma_filter) { -if (!host->dma_rx_channel && plat->dma_rx_param) { - host->dma_rx_channel =dma_request_channel (mask, - plat->dma_filter, - plat->dma_rx_param); -/* E.g if no DMA hardware is present */ -if (!host->dma_rx_channel) -dev_err (mmc_dev (host->mmc),"no RX DMA channel\n" ); - } - -if (!host->dma_tx_channel && plat->dma_tx_param) { - host->dma_tx_channel =dma_request_channel (mask, - plat->dma_filter, - plat->dma_tx_param); -if (!host->dma_tx_channel) -dev_warn (mmc_dev (host->mmc),"no TX DMA channel\n" ); - } - } -/* * If only an RX channel is specified, the driver will * attempt to use it bidirectionally, however if it is
@@ -447,11 +427,9 @@ static void mmci_dma_setup(struct mmci_host *host)*/ static inline void mmci_dma_release (struct mmci_host *host) { -struct mmci_platform_data *plat = host->plat; -if (host->dma_rx_channel)dma_release_channel (host->dma_rx_channel); -if (host->dma_tx_channel && plat->dma_tx_param) +if (host->dma_tx_channel)dma_release_channel (host->dma_tx_channel); host->dma_rx_channel = host->dma_tx_channel =NULL ; }
include/linux/amba/mmci.h +0 -17
@@ -6,9 +6,6 @@#include <linux/mmc/host.h> -/* Just some dummy forwarding */ -struct dma_chan ; -/** * struct mmci_platform_data - platform configuration for the MMCI * (also known as PL180) block.
@@ -29,17 +26,6 @@ struct dma_chan;* @gpio_wp: read this GPIO pin to see if the card is write protected * @gpio_cd: read this GPIO pin to detect card insertion * @cd_invert: true if the gpio_cd pin value is active low -* @dma_filter: function used to select an appropriate RX and TX -* DMA channel to be used for DMA, if and only if you're deploying the -* generic DMA engine -* @dma_rx_param: parameter passed to the DMA allocation -* filter in order to select an appropriate RX channel. If -* there is a bidirectional RX+TX channel, then just specify -* this and leave dma_tx_param set to NULL -* @dma_tx_param: parameter passed to the DMA allocation -* filter in order to select an appropriate TX channel. If this -* is NULL the driver will attempt to use the RX channel as a -* bidirectional channel */ struct mmci_platform_data {unsigned int f_max;
@@ -49,9 +35,6 @@ struct mmci_platform_data {int gpio_wp;int gpio_cd; bool cd_invert; -bool (*dma_filter)(struct dma_chan *chan,void *filter_param); -void *dma_rx_param; - void *dma_tx_param; };#endif
Signature · 1 line
1.7.9.5
PATCH 20/20 mmc: mmci: Enforce max frequency configuration through DT
In reply to Ulf HanssonRemove the option to provide a maximum frequency as platform data, enforce it through DT.
--- drivers/mmc/host/mmci.c | 5 +---- include/linux/amba/mmci.h | 4 ---- 2 files changed, 1 insertion(+), 8 deletions(-)
drivers/mmc/host/mmci.c +1 -4
@@ -1475,13 +1475,10 @@ static int mmci_probe(struct amba_device *dev,* If no maximum operating frequency is supplied, fall back to use * the module parameter, which has a (low) default value in case it * is not specified. Either value must not exceed the clock rate into -* the block, of course. Also note that DT takes precedence over -* platform data. +* the block, of course. */ if (mmc->f_max) mmc->f_max =min (host->mclk, mmc->f_max); -else if (plat->f_max) - mmc->f_max =min (host->mclk, plat->f_max);else mmc->f_max =min (host->mclk, fmax);dev_dbg (mmc_dev (mmc),"clocking block at %u Hz\n" , mmc->f_max);
include/linux/amba/mmci.h +0 -4
@@ -9,9 +9,6 @@/** * struct mmci_platform_data - platform configuration for the MMCI * (also known as PL180) block. -* @f_max: the maximum operational frequency for this host in this -* platform configuration. When this is specified it takes precedence -* over the module parameter for the same frequency. * @ocr_mask: available voltages on the 4 pins from the block, this * is ignored if a regulator is used, see the MMC_VDD_* masks in * mmc/host.h
@@ -28,7 +25,6 @@* @cd_invert: true if the gpio_cd pin value is active low */ struct mmci_platform_data { -unsigned int f_max;unsigned int ocr_mask;int (*ios_handler)(struct device *,struct mmc_ios *);unsigned int (*status)(struct device *);
Signature · 1 line
1.7.9.5