On Saturday 28 December 2013, Zhangfei Gao wrote:
> Add dw_mmc-k3.c for k3v2, support sd/emmc
>
> Signed-off-by: Zhangfei Gao <zhangfei....@linaro.org>
> Signed-off-by: Zhigang Wang <brooke.wangzhig...@huawei.com>
> ---
> .../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 linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
