On Saturday 28 December 2013, Zhangfei Gao wrote: > Add dw_mmc-k3.c for k3v2, support sd/emmc > > Signed-off-by: Zhangfei Gao <zhangfei.gao@xxxxxxxxxx> > Signed-off-by: Zhigang Wang <brooke.wangzhigang@xxxxxxxxxx> > --- > .../devicetree/bindings/mmc/k3-dw-mshc.txt | 60 ++++++++++ > drivers/mmc/host/Kconfig | 10 ++ > drivers/mmc/host/Makefile | 1 + > drivers/mmc/host/dw_mmc-k3.c | 126 ++++++++++++++++++++ > 4 files changed, 197 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt > create mode 100644 drivers/mmc/host/dw_mmc-k3.c > > diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt > new file mode 100644 > index 000000000000..d7e2d7f159bb > --- /dev/null > +++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt > @@ -0,0 +1,60 @@ > +* Hisilicon specific extensions to the Synopsys Designware Mobile > + Storage Host Controller > + > +Read synopsys-dw-mshc.txt for more details > + > +The Synopsys designware mobile storage host controller is used to interface > +a SoC with storage medium such as eMMC or SD/MMC cards. This file documents > +differences between the core Synopsys dw mshc controller properties described > +by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific > +extensions to the Synopsys Designware Mobile Storage Host Controller. > + > +Required Properties: > + > +* compatible: should be one of the following. > + - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extentions. I wonder if this is actually a different variant of the mshc hardware, or just wired up in a different way. Do you know details? Since the only difference in the binding is the presence of the "clock-freq-table" property, we could also make this property generic for the mshc driver and use it if present but fall back to the normal behavior when it is absent. > +* clock-freq-table: should be the frequency (in Hz) array of the ciu clock > + in each supported mode. > + 0. CIU clock rate in Hz for DS mode > + 1. CIU clock rate in Hz for MMC HS mode > + 2. CIU clock rate in Hz for SD HS mode > + 3. CIU clock rate in Hz for SDR12 mode > + 4. CIU clock rate in Hz for SDR25 mode > + 5. CIU clock rate in Hz for SDR50 mode > + 6. CIU clock rate in Hz for SDR104 mode > + 7. CIU clock rate in Hz for DDR50 mode > + 8. CIU clock rate in Hz for HS200 mode This looks god now. > +static void dw_mci_k3_set_ios(struct dw_mci *host, struct mmc_ios *ios) > +{ > + struct dw_mci_k3_priv_data *priv = host->priv; > + u32 rate = priv->clk_table[ios->timing]; > + int ret; I think this should have some range checking to see if the mode that is being set had a clock frequency set in the DT. > + > + ret = clk_set_rate(host->ciu_clk, rate); > + if (ret) > + dev_warn(host->dev, "failed to set clock rate %uHz\n", rate); > + > + host->bus_hz = clk_get_rate(host->ciu_clk); > +} Why do you call clk_get_rate() here, shouldn't it always be the same rate that you have just set? > +static int dw_mci_k3_parse_dt(struct dw_mci *host) > +{ > + struct dw_mci_k3_priv_data *priv; > + struct device_node *node = host->dev->of_node; > + struct property *prop; > + const __be32 *cur; > + u32 val, num = 0; > + > + priv = devm_kzalloc(host->dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) { > + dev_err(host->dev, "mem alloc failed for private data\n"); > + return -ENOMEM; > + } > + host->priv = priv; > + > + of_property_for_each_u32(node, "clock-freq-table", prop, cur, val) { > + if (num >= MAX_NUMS) > + break; > + priv->clk_table[num++] = val; > + } > + return 0; > +} If we make this property part of the generic binding, this function could also get moved to the main dw_mci driver. > +static int dw_mci_k3_suspend(struct device *dev) > +{ > + struct dw_mci *host = dev_get_drvdata(dev); > + int ret = 0; > + > + ret = dw_mci_suspend(host); You should never initialize local variables when they are set later in the function (the ret = 0 part above). For more complex functions, this prevents gcc from warning you about accidentally uninitialized uses. > + if (!ret) > + clk_disable_unprepare(host->ciu_clk); > + > + return ret; > +} The suspend/resume code also looks very generic. Can't we make these the default for dw-mci? If you do both, you won't even need a k3 specific driver. I think in general we should try hard to add code like this to the common driver when there is a chance that it can be shared with other platforms. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html