Re: [PATCH V3 1/2] tps6507x-ts: Add DT support
Hi Manish, On Tue, May 21, 2013 at 02:24:17PM +0530, Vishwanathrao Badarkhe, Manish wrote: > Add device tree based support for TI's tps6507x touchscreen. > > Tested on da850-evm. > > Signed-off-by: Vishwanathrao Badarkhe, Manish > --- > Changes since V2: > - Removed unnecessary code. > - Updated Documentation to provide proper names of >devicetree properties. > > Changes since V1: > - Updated documentation to specify tps6507x as multifunctional >device. > - return proper error value in absence of platform and DT >data for touchscreen. > - Updated commit message. > > :100755 100755 8fffa3c... 65ee2cd... M > Documentation/devicetree/bindings/mfd/tps6507x.txt > :100644 100644 65e0f9a... 89232ee... M > drivers/input/touchscreen/tps6507x-ts.c > Documentation/devicetree/bindings/mfd/tps6507x.txt | 28 ++- > drivers/input/touchscreen/tps6507x-ts.c| 98 > ++-- > 2 files changed, 95 insertions(+), 31 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt > b/Documentation/devicetree/bindings/mfd/tps6507x.txt > index 8fffa3c..65ee2cd 100755 > --- a/Documentation/devicetree/bindings/mfd/tps6507x.txt > +++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt > @@ -1,4 +1,8 @@ > -TPS6507x Power Management Integrated Circuit > +TPS6507x Multifunctional Device. > + > +Features provided by TPS6507x: > +1.Power Management Integrated Circuit. > +2.Touch-Screen. > > Required properties: > - compatible: "ti,tps6507x" > @@ -23,6 +27,12 @@ Required properties: > vindcdc1_2-supply: VDCDC1 and VDCDC2 input. > vindcdc3-supply : VDCDC3 input. > vldo1_2-supply : VLDO1 and VLDO2 input. > +- tsc: This node specifies touch screen data. > + ti,poll-period : Time at which touch input is getting sampled in ms. > + ti,min-pressure: Minimum pressure value to trigger touch. > + ti,vref: voltage reference for ADC. > + 0: Reference voltage for ADC is disabled. > + 1: Reference voltage for ADC is enabled. > > Regulator Optional properties: > - defdcdc_default: It's property of DCDC2 and DCDC3 regulators. > @@ -30,6 +40,14 @@ Regulator Optional properties: > 1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH. >If this property is not defined, it defaults to 0 (not enabled). > > +Touchscreen Optional properties: > +- ti,vendor : Touchscreen vendor id to populate > + in sysclass interface. > +- ti,product: Touchscreen product id to populate > + in sysclass interface. > +- ti,version: Touchscreen version id to populate > + in sysclass interface. > + > Example: > > pmu: tps6507x@48 { > @@ -88,4 +106,12 @@ Example: > }; > }; > > + tsc { > + ti,poll-period = <30>; > + ti,min-pressure = <0x30>; > + ti,vref = <0>; > + ti,vendor = <0>; > + ti,product = <65070>; > + ti,version = <0x100>; > + }; > }; > diff --git a/drivers/input/touchscreen/tps6507x-ts.c > b/drivers/input/touchscreen/tps6507x-ts.c > index 65e0f9a..89232ee 100644 > --- a/drivers/input/touchscreen/tps6507x-ts.c > +++ b/drivers/input/touchscreen/tps6507x-ts.c > @@ -21,6 +21,8 @@ > #include > #include > #include > +#include > +#include > > #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */ > #define TPS_DEFAULT_MIN_PRESSURE 0x30 > @@ -231,36 +233,76 @@ done: > ret = tps6507x_adc_standby(tsc); > } > > +static int tsc_init_data(struct tps6507x_dev *tps6507x_dev, > + struct input_dev *input_dev) > +{ > + struct device_node *node = tps6507x_dev->dev->of_node; > + struct tps6507x_board *tps_board = > + (struct tps6507x_board *)tps6507x_dev->dev->platform_data; Please make tps_board const pointer and use dev_get_platdata() to fetch it. > + struct touchscreen_init_data *init_data = NULL; > + int err; > + > + if (node) > + node = of_find_node_by_name(node, "tsc"); Why do you have to locate OF node manually instead of already having it attached to the device stucture? > + if (tps_board) > + init_data = tps_board->tps6507x_ts_init_data; > + > + if (node == NULL || init_data == NULL) { > + err = -EINVAL; > + goto error_ret; > + } else if (init_data) { > + tps6507x_dev->ts->poll_period = init_data->poll_period; > + tps6507x_dev->ts->min_pressure = init_data->min_pressure; > + tps6507x_dev->ts->vref = init_data->vref; > + input_dev->id.vendor = init_data->vendor; > + input_dev->id.product = init_data->product; > + input_dev->id.version = init_data->version; > + } else if (node) { > + err = of_property_read_u32(node, "ti,poll-period", > +
Re: [PATCH] ARM: dts: Update vdd_arm regulator
On 06/08/2013 05:22 PM, Tomasz Figa wrote: > Hi Tushar, > > On Thursday 06 of June 2013 16:32:52 Tushar Behera wrote: >> Cpufreq driver for EXYNOS4210 is not a platform driver, hence it is not >> possible to provide the regulator supply name through DT bindings. >> Since the cpufreq driver requires the regulator to be named as >> 'vdd_arm', the related regulator name should be kept same. >> >> Signed-off-by: Tushar Behera >> --- >> arch/arm/boot/dts/exynos4210-origen.dts |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts >> b/arch/arm/boot/dts/exynos4210-origen.dts index bcf8079..bd5f589 100644 >> --- a/arch/arm/boot/dts/exynos4210-origen.dts >> +++ b/arch/arm/boot/dts/exynos4210-origen.dts >> @@ -192,7 +192,7 @@ >> }; >> >> buck1_reg: BUCK1 { >> -regulator-name = "VDD_ARM_1.2V"; >> +regulator-name = "vdd_arm"; > > Yes, this is the hack I mentioned in my review of > [PATCH 0/2] Clock update for EXYNOS4210-CPUFREQ driver > We can hold this patch till we get to a conclusion for the above mentioned patch set. > Best regards, > Tomasz > >> regulator-min-microvolt = > <95>; >> regulator-max-microvolt = > <135>; >> regulator-always-on; -- Tushar Behera ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] clk: exynos4: Add alias for cpufreq related clocks
On 06/08/2013 05:20 PM, Tomasz Figa wrote: > On Thursday 06 of June 2013 16:52:28 Tushar Behera wrote: >> cpufreq driver for EXYNOS4 based SoCs are not platform drivers, hence >> we cannot currently pass the clock names through a device tree node. >> Instead, we need to make them available through a global alias. >> >> 'armclk', 'moutcore', 'mout_mpll' and 'mout_apll' clock aliases are >> defined. >> >> Signed-off-by: Tushar Behera >> --- >> drivers/clk/samsung/clk-exynos4.c | 10 +- >> 1 file changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/clk/samsung/clk-exynos4.c >> b/drivers/clk/samsung/clk-exynos4.c index 3c1f888..1e4258a 100644 >> --- a/drivers/clk/samsung/clk-exynos4.c >> +++ b/drivers/clk/samsung/clk-exynos4.c >> @@ -356,8 +356,8 @@ struct samsung_fixed_rate_clock >> exynos4210_fixed_rate_clks[] __initdata = { >> >> /* list of mux clocks supported in all exynos4 soc's */ >> struct samsung_mux_clock exynos4_mux_clks[] __initdata = { >> -MUX_F(mout_apll, "mout_apll", mout_apll_p, SRC_CPU, 0, 1, >> -CLK_SET_RATE_PARENT, 0), >> +MUX_FA(mout_apll, "mout_apll", mout_apll_p, SRC_CPU, 0, 1, >> +CLK_SET_RATE_PARENT, 0, "mout_apll"), >> MUX(none, "mout_hdmi", mout_hdmi_p, SRC_TV, 0, 1), >> MUX(none, "mout_mfc1", sclk_evpll_p, SRC_MFC, 4, 1), >> MUX(none, "mout_mfc", mout_mfc_p, SRC_MFC, 8, 1), >> @@ -385,9 +385,9 @@ struct samsung_mux_clock exynos4210_mux_clks[] >> __initdata = { MUX(none, "mout_g2d", mout_g2d_p, E4210_SRC_IMAGE, 8, >> 1), >> MUX(none, "mout_fimd1", group1_p4210, E4210_SRC_LCD1, 0, 4), >> MUX(none, "mout_mipi1", group1_p4210, E4210_SRC_LCD1, 12, 4), >> -MUX_A(sclk_mpll, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1, > "sclk_mpll"), >> +MUX_A(sclk_mpll, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1, > "mout_mpll"), > > This is not fully compliant with patch description. I'm not sure if there > weren't any users of the sclk_mpll alias. > As of now, there are no other users of sclk_mpll other than a debug print within the same file. >> MUX_A(mout_core, "mout_core", mout_core_p4210, >> -SRC_CPU, 16, 1, "mout_core"), >> +SRC_CPU, 16, 1, "moutcore"), > > IMHO those typo corrections are not part of this patch. > But the older drivers (before migration to CCF) were using the clock "moutcore" (not "mout_core"). >> MUX_A(sclk_vpll, "sclk_vpll", sclk_vpll_p4210, >> SRC_TOP0, 8, 1, "sclk_vpll"), >> MUX(mout_fimc0, "mout_fimc0", group1_p4210, SRC_CAM, 0, 4), >> @@ -534,7 +534,7 @@ struct samsung_div_clock exynos4_div_clks[] >> __initdata = { DIV(none, "div_spi_pre2", "div_spi2", DIV_PERIL2, 8, 8), >> DIV(none, "div_audio1", "mout_audio1", DIV_PERIL4, 0, 4), >> DIV(none, "div_audio2", "mout_audio2", DIV_PERIL4, 16, 4), >> -DIV_A(arm_clk, "arm_clk", "div_core2", DIV_CPU0, 28, 3, > "arm_clk"), >> +DIV_A(arm_clk, "arm_clk", "div_core2", DIV_CPU0, 28, 3, "armclk"), > > Same here. > Same as above, "armclk" is used elsewhere, not "arm_clk". >> DIV_A(sclk_apll, "sclk_apll", "mout_apll", >> DIV_CPU0, 24, 3, "sclk_apll"), >> DIV_F(none, "div_mipi_pre0", "div_mipi0", DIV_LCD0, 20, 4, > > Basically I don't like the idea of those global aliases, which IMHO should > be completely dropped. Someone might not like it, but I'd go with the > conversion of our cpufreq drivers to platform drivers instead, which could > receive things like clocks and regulators using DT-based lookups. > I agree. Migration of exynos-cpufreq driver as a platform driver is the best solution. But unless someone picks up that work, cpufreq support for EXYNOS4 based systems is broken because of the incorrect clock aliases. > This is especially important in case of regulators, which currently have > to be hacked by using vdd_arm as regulator name in device tree. > Agree. > CCing people that might be interested in this topic. > > Best regards, > Tomasz > Thanks. -- Tushar Behera ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Sun, Jun 09, 2013 at 11:09:59PM +0100, luke.leighton wrote: > this is all a rather round-about way to say that for those people who > heard and are thinking of heeding russell's call to "be silent and to > ignore me" Okay, so you've just misrepresented me in the above comment. I never said anything of the sort. The closest that I've come to a comment like that is asking you to stop wasting people's time. So, given your displayed inability to properly convey what people have said to you in a discussion in your own replies, is there *any* reason that anyone should trust you to communicate their position to any other third party? In some ways, I'm *glad* that you've passed everything on verbatum, because it means that it's (hopefully) free from any misrepresentations such as the above. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 8/8] mmc: mvsdio: use standard MMC device-tree binding parser mmc_of_parse()
Instead of parsing the DT binding on our own, use the standard parser mmc_of_parse(), introduced by commit 6c56e7a. Signed-off-by: Simon Baatz --- drivers/mmc/host/mvsdio.c | 73 + 1 file changed, 40 insertions(+), 33 deletions(-) diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c index 8960fc8..edfc481 100644 --- a/drivers/mmc/host/mvsdio.c +++ b/drivers/mmc/host/mvsdio.c @@ -35,7 +35,7 @@ #define DRIVER_NAME"mvsdio" -static int maxfreq = MVSD_CLOCKRATE_MAX; +static int maxfreq; static int nodma; struct mvsd_host { @@ -685,7 +685,6 @@ static int __init mvsd_probe(struct platform_device *pdev) const struct mbus_dram_target_info *dram; struct resource *r; int ret, irq; - int gpio_card_detect, gpio_write_protect; struct pinctrl *pinctrl; r = platform_get_resource(pdev, IORESOURCE_MEM, 0); @@ -718,6 +717,20 @@ static int __init mvsd_probe(struct platform_device *pdev) if (!IS_ERR(host->clk)) clk_prepare_enable(host->clk); + mmc->ops = &mvsd_ops; + + mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34; + + mmc->f_min = DIV_ROUND_UP(host->base_clock, MVSD_BASE_DIV_MAX); + mmc->f_max = MVSD_CLOCKRATE_MAX; + + mmc->max_blk_size = 2048; + mmc->max_blk_count = 65535; + + mmc->max_segs = 1; + mmc->max_seg_size = mmc->max_blk_size * mmc->max_blk_count; + mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count; + if (np) { if (IS_ERR(host->clk)) { dev_err(&pdev->dev, "DT platforms must have a clock associated\n"); @@ -726,35 +739,38 @@ static int __init mvsd_probe(struct platform_device *pdev) } host->base_clock = clk_get_rate(host->clk) / 2; - gpio_card_detect = of_get_named_gpio(np, "cd-gpios", 0); - gpio_write_protect = of_get_named_gpio(np, "wp-gpios", 0); + ret = mmc_of_parse(mmc); + if (ret < 0) + goto out; } else { const struct mvsdio_platform_data *mvsd_data; + mvsd_data = pdev->dev.platform_data; if (!mvsd_data) { ret = -ENXIO; goto out; } + mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ | + MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; host->base_clock = mvsd_data->clock / 2; - gpio_card_detect = mvsd_data->gpio_card_detect ? : -EINVAL; - gpio_write_protect = mvsd_data->gpio_write_protect ? : -EINVAL; - } - - mmc->ops = &mvsd_ops; - - mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34; - mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ | - MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; - - mmc->f_min = DIV_ROUND_UP(host->base_clock, MVSD_BASE_DIV_MAX); - mmc->f_max = maxfreq; + /* GPIO 0 regarded as invalid for backward compatibility */ + if (mvsd_data->gpio_card_detect && + gpio_is_valid(mvsd_data->gpio_card_detect)) { + ret = mmc_gpio_request_cd(mmc, + mvsd_data->gpio_card_detect); + if (ret) + goto out; + } else { + mmc->caps |= MMC_CAP_NEEDS_POLL; + } - mmc->max_blk_size = 2048; - mmc->max_blk_count = 65535; + if (mvsd_data->gpio_write_protect && + gpio_is_valid(mvsd_data->gpio_write_protect)) + mmc_gpio_request_ro(mmc, mvsd_data->gpio_write_protect); + } - mmc->max_segs = 1; - mmc->max_seg_size = mmc->max_blk_size * mmc->max_blk_count; - mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count; + if (maxfreq) + mmc->f_max = maxfreq; spin_lock_init(&host->lock); @@ -777,15 +793,6 @@ static int __init mvsd_probe(struct platform_device *pdev) goto out; } - if (gpio_is_valid(gpio_card_detect)) { - ret = mmc_gpio_request_cd(mmc, gpio_card_detect); - if (ret) - goto out; - } else - mmc->caps |= MMC_CAP_NEEDS_POLL; - - mmc_gpio_request_ro(mmc, gpio_write_protect); - setup_timer(&host->timer, mvsd_timeout_timer, (unsigned long)host); platform_set_drvdata(pdev, mmc); ret = mmc_add_host(mmc); @@ -793,10 +800,10 @@ static int __init mvsd_probe(struct platform_device *pdev) goto out; if (!(mmc->caps & MMC_CAP_NEEDS_POLL)) - dev_notice(&pdev->dev, "using GPIO %d for card detection\n", - gpio_card_detect); + dev_notice(&pdev->dev, "using GPIO for card detectio
[RESEND PATCH V3 6/8] mmc: tegra: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz --- drivers/mmc/host/sdhci-tegra.c |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c index e0dba74..7eb62f8 100644 --- a/drivers/mmc/host/sdhci-tegra.c +++ b/drivers/mmc/host/sdhci-tegra.c @@ -205,7 +205,7 @@ static const struct of_device_id sdhci_tegra_dt_match[] = { }; MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match); -static void sdhci_tegra_parse_dt(struct device *dev) +static int sdhci_tegra_parse_dt(struct device *dev) { struct device_node *np = dev->of_node; struct sdhci_host *host = dev_get_drvdata(dev); @@ -213,7 +213,7 @@ static void sdhci_tegra_parse_dt(struct device *dev) struct sdhci_tegra *tegra_host = pltfm_host->priv; tegra_host->power_gpio = of_get_named_gpio(np, "power-gpios", 0); - mmc_of_parse(host->mmc); + return mmc_of_parse(host->mmc); } static int sdhci_tegra_probe(struct platform_device *pdev) @@ -245,7 +245,9 @@ static int sdhci_tegra_probe(struct platform_device *pdev) tegra_host->soc_data = soc_data; pltfm_host->priv = tegra_host; - sdhci_tegra_parse_dt(&pdev->dev); + rc = sdhci_tegra_parse_dt(&pdev->dev); + if (rc) + goto err_parse_dt; if (gpio_is_valid(tegra_host->power_gpio)) { rc = gpio_request(tegra_host->power_gpio, "sdhci_power"); @@ -278,6 +280,7 @@ err_add_host: err_clk_get: if (gpio_is_valid(tegra_host->power_gpio)) gpio_free(tegra_host->power_gpio); +err_parse_dt: err_power_req: err_alloc_tegra_host: sdhci_pltfm_free(pdev); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 5/8] mmc: sdhci-pxav3: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz --- drivers/mmc/host/sdhci-pxav3.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c index 1ae358e..67ea388 100644 --- a/drivers/mmc/host/sdhci-pxav3.c +++ b/drivers/mmc/host/sdhci-pxav3.c @@ -252,7 +252,9 @@ static int sdhci_pxav3_probe(struct platform_device *pdev) match = of_match_device(of_match_ptr(sdhci_pxav3_of_match), &pdev->dev); if (match) { - mmc_of_parse(host->mmc); + ret = mmc_of_parse(host->mmc); + if (ret) + goto err_of_parse; sdhci_get_of_property(pdev); pdata = pxav3_get_mmc_pdata(dev); } else if (pdata) { @@ -313,10 +315,11 @@ static int sdhci_pxav3_probe(struct platform_device *pdev) return 0; +err_of_parse: +err_cd_req: err_add_host: clk_disable_unprepare(clk); clk_put(clk); -err_cd_req: err_clk_get: sdhci_pltfm_free(pdev); kfree(pxa); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 7/8] ARM: mvebu: Use standard MMC binding for all users of mvsdio
In order to prepare the switch to the standard MMC device tree parser for mvsdio, adapt all current uses of mvsdio in the dts files to the standard format. Signed-off-by: Simon Baatz --- arch/arm/boot/dts/armada-370-db.dts|1 + arch/arm/boot/dts/armada-370-mirabox.dts |1 + arch/arm/boot/dts/armada-370-rd.dts|1 + arch/arm/boot/dts/armada-370-xp.dtsi |4 arch/arm/boot/dts/armada-xp-db.dts |1 + arch/arm/boot/dts/kirkwood-dreamplug.dts |1 + .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |2 ++ arch/arm/boot/dts/kirkwood-mplcec4.dts |2 +- arch/arm/boot/dts/kirkwood-topkick.dts |1 + arch/arm/boot/dts/kirkwood.dtsi|4 10 files changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts index 2353b1f..beee169 100644 --- a/arch/arm/boot/dts/armada-370-db.dts +++ b/arch/arm/boot/dts/armada-370-db.dts @@ -74,6 +74,7 @@ */ status = "disabled"; /* No CD or WP GPIOs */ + broken-cd; }; usb@5 { diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts index 14e36e1..45b1077 100644 --- a/arch/arm/boot/dts/armada-370-mirabox.dts +++ b/arch/arm/boot/dts/armada-370-mirabox.dts @@ -99,6 +99,7 @@ * No CD or WP GPIOs: SDIO interface used for * Wifi/Bluetooth chip */ +broken-cd; }; usb@5 { diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts index 130f839..89c2110 100644 --- a/arch/arm/boot/dts/armada-370-rd.dts +++ b/arch/arm/boot/dts/armada-370-rd.dts @@ -64,6 +64,7 @@ pinctrl-names = "default"; status = "okay"; /* No CD or WP GPIOs */ + broken-cd; }; usb@5 { diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi index 550eb77..0d73570 100644 --- a/arch/arm/boot/dts/armada-370-xp.dtsi +++ b/arch/arm/boot/dts/armada-370-xp.dtsi @@ -143,6 +143,10 @@ reg = <0xd4000 0x200>; interrupts = <54>; clocks = <&gateclk 17>; + bus-width = <4>; + cap-sdio-irq; + cap-sd-highspeed; + cap-mmc-highspeed; status = "disabled"; }; diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts index d6cc8bf..7c22a20 100644 --- a/arch/arm/boot/dts/armada-xp-db.dts +++ b/arch/arm/boot/dts/armada-xp-db.dts @@ -97,6 +97,7 @@ pinctrl-names = "default"; status = "okay"; /* No CD or WP GPIOs */ + broken-cd; }; usb@5 { diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts index 289e51d..be16a84 100644 --- a/arch/arm/boot/dts/kirkwood-dreamplug.dts +++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts @@ -79,6 +79,7 @@ pinctrl-names = "default"; status = "okay"; /* No CD or WP GPIOs */ + broken-cd; }; }; diff --git a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts index 44fd97d..484a2a6 100644 --- a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts +++ b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts @@ -72,6 +72,8 @@ mvsdio@9 { status = "okay"; + /* No CD or WP GPIOs */ + broken-cd; }; }; diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts b/arch/arm/boot/dts/kirkwood-mplcec4.dts index 7588241..bf3a58c 100644 --- a/arch/arm/boot/dts/kirkwood-mplcec4.dts +++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts @@ -136,7 +136,7 @@ pinctrl-0 = <&pmx_sdio &pmx_sdio_cd>; pinctrl-names = "default"; status = "okay"; - cd-gpios = <&gpio1 15 0>; + cd-gpios = <&gpio1 15 1>; /* No WP GPIO */ }; }; diff --git a/arch/arm/b
[RESEND PATCH V3 0/8] mmc_of_parse() adaptations, switch mvsdio to mmc_of_parse()
Hi, RESEND V3: - Dropped patches 9 and 10, they are part of linux-next already NB: patch 7 as well, but I did not want to change the numbering V3 changes: - Patch 01/10: Added EPROBE_DEFER case to mmc_of_parse() - Added Acked-By to (unmodified) patches 02 and 03. V2 changes: - Converted mvsdio to use mmc_of_parse() - Adapted DTS files using mvsdio accordingly - Changed mmc_of_parse() to return errors to the caller While adding DT support for the Sheevaplugs by Globalscale Technologies (Kirkwood), it turned out that the DT binding of mvsdio lacked features to properly support the hardware (active high/low of CD and WP pins could not be described in DT). This is standard functionality provided by the mmc_of_parse() helper function. However, mmc_of_parse() may allocate GPIO lines. If the allocation fails, it outputs an error, but does not return an error to its caller. Therefore, a proposal to handle errors in mmc_of_parse() is made. This also allows to handle the EPROBE_DEFER case when GPIO is not loaded yet. The patch set is structured as follows: 1 Adapt mmc_of_parse() to return errors 2-6 Handle errors in current drivers using mmc_of_parse() (compile tested only) 7-8 Convert mvsdio and respective dts files to mmc_of_parse() (tested on kirkwood) Simon Baatz (8): mmc: return mmc_of_parse() errors to caller mmc: sh_mmcif: handle mmc_of_parse() errors during probe mmc: tmio-mmc: handle mmc_of_parse() errors during probe mmc: mxcmmc: handle mmc_of_parse() errors during probe mmc: sdhci-pxav3: handle mmc_of_parse() errors during probe mmc: tegra: handle mmc_of_parse() errors during probe ARM: mvebu: Use standard MMC binding for all users of mvsdio mmc: mvsdio: use standard MMC device-tree binding parser mmc_of_parse() arch/arm/boot/dts/armada-370-db.dts|1 + arch/arm/boot/dts/armada-370-mirabox.dts |1 + arch/arm/boot/dts/armada-370-rd.dts|1 + arch/arm/boot/dts/armada-370-xp.dtsi |4 ++ arch/arm/boot/dts/armada-xp-db.dts |1 + arch/arm/boot/dts/kirkwood-dreamplug.dts |1 + .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |2 + arch/arm/boot/dts/kirkwood-mplcec4.dts |2 +- arch/arm/boot/dts/kirkwood-topkick.dts |1 + arch/arm/boot/dts/kirkwood.dtsi|4 ++ drivers/mmc/core/host.c| 30 ++-- drivers/mmc/host/mvsdio.c | 73 +++- drivers/mmc/host/mxcmmc.c |4 +- drivers/mmc/host/sdhci-pxav3.c |7 +- drivers/mmc/host/sdhci-tegra.c |9 ++- drivers/mmc/host/sh_mmcif.c|7 +- drivers/mmc/host/tmio_mmc_pio.c|4 +- include/linux/mmc/host.h |2 +- 18 files changed, 106 insertions(+), 48 deletions(-) -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 3/8] mmc: tmio-mmc: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz Acked-by: Guennadi Liakhovetski --- drivers/mmc/host/tmio_mmc_pio.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c index f508ecb..f1a9d4a 100644 --- a/drivers/mmc/host/tmio_mmc_pio.c +++ b/drivers/mmc/host/tmio_mmc_pio.c @@ -988,7 +988,9 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host, if (!mmc) return -ENOMEM; - mmc_of_parse(mmc); + ret = mmc_of_parse(mmc); + if (ret < 0) + goto host_free; pdata->dev = &pdev->dev; _host = mmc_priv(mmc); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 2/8] mmc: sh_mmcif: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz Acked-by: Guennadi Liakhovetski --- drivers/mmc/host/sh_mmcif.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c index ba76a53..6ded7fb 100644 --- a/drivers/mmc/host/sh_mmcif.c +++ b/drivers/mmc/host/sh_mmcif.c @@ -1369,7 +1369,11 @@ static int sh_mmcif_probe(struct platform_device *pdev) ret = -ENOMEM; goto ealloch; } - mmc_of_parse(mmc); + + ret = mmc_of_parse(mmc); + if (ret < 0) + goto eofparse; + host= mmc_priv(mmc); host->mmc = mmc; host->addr = reg; @@ -1464,6 +1468,7 @@ eclkupdate: clk_put(host->hclk); eclkget: pm_runtime_disable(&pdev->dev); +eofparse: mmc_free_host(mmc); ealloch: iounmap(reg); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 1/8] mmc: return mmc_of_parse() errors to caller
In addition to just logging errors encountered during DT parsing or allocating GPIO slots for CD/WP, mmc_of_parse() now returns with an error. In particular, this is needed if the GPIO allocation may return EPROBE_DEFER. Signed-off-by: Simon Baatz Reviewed-by: Ulf Hansson --- changes in V3: - Handle EPROBE_DEFER case drivers/mmc/core/host.c | 30 +- include/linux/mmc/host.h |2 +- 2 files changed, 26 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index 2a3593d..89f5849 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -306,7 +306,7 @@ static inline void mmc_host_clk_sysfs_init(struct mmc_host *host) * parse the properties and set respective generic mmc-host flags and * parameters. */ -void mmc_of_parse(struct mmc_host *host) +int mmc_of_parse(struct mmc_host *host) { struct device_node *np; u32 bus_width; @@ -315,7 +315,7 @@ void mmc_of_parse(struct mmc_host *host) int len, ret, gpio; if (!host->parent || !host->parent->of_node) - return; + return 0; np = host->parent->of_node; @@ -338,6 +338,7 @@ void mmc_of_parse(struct mmc_host *host) default: dev_err(host->parent, "Invalid \"bus-width\" value %ud!\n", bus_width); + return -EINVAL; } /* f_max is obtained from the optional "max-frequency" property */ @@ -367,18 +368,22 @@ void mmc_of_parse(struct mmc_host *host) host->caps |= MMC_CAP_NEEDS_POLL; gpio = of_get_named_gpio_flags(np, "cd-gpios", 0, &flags); + if (gpio == -EPROBE_DEFER) + return gpio; if (gpio_is_valid(gpio)) { if (!(flags & OF_GPIO_ACTIVE_LOW)) gpio_inv_cd = true; ret = mmc_gpio_request_cd(host, gpio); - if (ret < 0) + if (ret < 0) { dev_err(host->parent, "Failed to request CD GPIO #%d: %d!\n", gpio, ret); - else + return ret; + } else { dev_info(host->parent, "Got CD GPIO #%d.\n", gpio); + } } if (explicit_inv_cd ^ gpio_inv_cd) @@ -389,14 +394,23 @@ void mmc_of_parse(struct mmc_host *host) explicit_inv_wp = of_property_read_bool(np, "wp-inverted"); gpio = of_get_named_gpio_flags(np, "wp-gpios", 0, &flags); + if (gpio == -EPROBE_DEFER) { + ret = -EPROBE_DEFER; + goto out; + } if (gpio_is_valid(gpio)) { if (!(flags & OF_GPIO_ACTIVE_LOW)) gpio_inv_wp = true; ret = mmc_gpio_request_ro(host, gpio); - if (ret < 0) + if (ret < 0) { dev_err(host->parent, "Failed to request WP GPIO: %d!\n", ret); + goto out; + } else { + dev_info(host->parent, "Got WP GPIO #%d.\n", +gpio); + } } if (explicit_inv_wp ^ gpio_inv_wp) host->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH; @@ -413,6 +427,12 @@ void mmc_of_parse(struct mmc_host *host) host->pm_caps |= MMC_PM_KEEP_POWER; if (of_find_property(np, "enable-sdio-wakeup", &len)) host->pm_caps |= MMC_PM_WAKE_SDIO_IRQ; + + return 0; + +out: + mmc_gpio_free_cd(host); + return ret; } EXPORT_SYMBOL(mmc_of_parse); diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h index e326ae2..c8c4fbc 100644 --- a/include/linux/mmc/host.h +++ b/include/linux/mmc/host.h @@ -369,7 +369,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *); int mmc_add_host(struct mmc_host *); void mmc_remove_host(struct mmc_host *); void mmc_free_host(struct mmc_host *); -void mmc_of_parse(struct mmc_host *host); +int mmc_of_parse(struct mmc_host *host); static inline void *mmc_priv(struct mmc_host *host) { -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 4/8] mmc: mxcmmc: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz --- drivers/mmc/host/mxcmmc.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c index d503635..f47546f 100644 --- a/drivers/mmc/host/mxcmmc.c +++ b/drivers/mmc/host/mxcmmc.c @@ -1067,7 +1067,9 @@ static int mxcmci_probe(struct platform_device *pdev) goto out_release_mem; } - mmc_of_parse(mmc); + ret = mmc_of_parse(mmc); + if (ret) + goto out_free; mmc->ops = &mxcmci_ops; /* For devicetree parsing, the bus width is read from devicetree */ -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ethernet/arc/arc_emac - Add new driver
On Fri, Jun 7, 2013 at 6:07 PM, Alexey Brodkin wrote: > Driver for non-standard on-chip ethernet device ARC EMAC 10/100, > instantiated in some legacy ARC (Synopsys) FPGA Boards such as > ARCAngel4/ML50x. > > This is based off of current Linus tree, build tested for x86. > +++ b/drivers/net/ethernet/arc/arc_emac_main.c > @@ -0,0 +1,956 @@ > +/* > + * Copyright (C) 2004, 2007-2010, 2011-2013 Synopsys, Inc. (www.synopsys.com) 2004, 2007-2013 ? > + * Driver for the ARC EMAC 10100 (Rev 5) If you are going to upstream this, why do you need revision? > + * Alexey Brodkin: June 2013 > + * -Upsteaming It will be obvious from existence of your commit in the git tree. > + * -Refactoring > + * = Use device-tree/OF for configuration > + * = Use libphy for phy management > + * = Remove non-NAPI code sections > + * = Remove ARC-specific BD management implementations > + * = Add ethtool functionality > + * > + * Vineet Gupta: June 2011 > + * -Issues when working with 64b cache line size > + * = BD rings point to aligned location in an internal buffer > + * = added support for cache coherent BD Ring memory > + * > + * Vineet Gupta: May 2010 > + * -Reduced foot-print of the main ISR (handling for error cases moved out > + * into a separate non-inline function). > + * -Driver Tx path optimized for small packets (which fit into 1 BD = 2K). > + * Any specifics for chaining are in a separate block of code. > + * > + * Vineet Gupta: Nov 2009 > + * -Unified NAPI and Non-NAPI Code. > + * -API changes since 2.6.26 for making NAPI independent of netdevice > + * -Cutting a few checks in main Rx poll routine > + * -Tweaked NAPI implementation: > + * In poll mode, Original driver would always start sweeping BD chain > + * from BD-0 upto poll budget (40). And if it got over-budget it would > + * drop reminder of packets. > + * Instead now we remember last BD polled and in next > + * cycle, we resume from next BD onwards. That way in case of > over-budget > + * no packet needs to be dropped. > + * > + * Vineet Gupta: Nov 2009 > + * -Rewrote the driver register access macros so that multiple accesses > + * in same function use "anchor" reg to save the base addr causing > + * shorter instructions > + * > + * Amit Bhor, Sameer Dhavale: 2004 I don't know if it's a good idea to keep changelog inside source file, we have git commit messages for that. You may move this to the first commit message if you want to keep history, and in future git will do the job for you. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "arc_emac_regs.h" > +#include "arc_emac_mdio.h" Since you are creating driver under its own folder why to keep the prefixes in the filenames? I think regs.h and mdio.h would be enough. > +/* Transmission timeout */ > +#define TX_TIMEOUT (400*HZ/1000) (400 * HZ / 1000) > +struct arc_emac_priv { > + /* Pointers to BD rings - Device side */ What about documenting structure fields in the kerneldoc format on the top of struct definition? > + dma_addr_t rxbd_dma_hdl; > + dma_addr_t txbd_dma_hdl; Perhaps you may consider to reduce field names somethow. I don't know why rxbd_dma and txbd_dma is not enough. > + struct sk_buff *rx_skbuff[RX_BD_NUM]; > + struct sk_buff *tx_skbuff[TX_BD_NUM]; Ditto. > + void __iomem *reg_base_addr; Ditto. For example, base or regs. > +/** > + * arc_emac_adjust_link - Adjust the PHY link speed/duplex. > + * @net_dev: Pointer to the net_device structure. > + * > + * This function is called to change the speed and duplex setting after > + * auto negotiation is done by the PHY. > + */ > +static void arc_emac_adjust_link(struct net_device *net_dev) > +{ > + struct arc_emac_priv *priv = netdev_priv(net_dev); > + struct phy_device *phydev = priv->phy_dev; > + unsigned int reg, status_change = 0; > + > + BUG_ON(!priv->phy_dev); > + > + if (phydev->link && (priv->old_speed != phydev->speed)) { > + /* speed changed */ > + switch (phydev->speed) { > + case SPEED_10: > + case SPEED_100: > + break; > + default: > + netdev_warn(net_dev, "Speed (%d) is not 10/100?\n", > + phydev->speed); > + break; > + } > + priv->old_speed = phydev->speed; > + status_change = 1; > + } > + > + if (phydev->link && (priv->old_duplex != phydev->duplex)) { > + /* duplex mode changed */ > + reg = EMAC_REG_GET(priv->reg_base_addr, R_CTRL); > + > + if (DUPLEX_FULL == phydev->duplex) > + reg |= ENFL_MASK; > + else > + reg &= ~ENFL_MASK; > + > + EMA
Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding
On Sunday 09 June 2013 11:34:24 Ezequiel Garcia wrote: > On Sun, Jun 09, 2013 at 03:42:24PM +0200, Arnd Bergmann wrote: > > On Saturday 08 June 2013 15:38:52 Ezequiel Garcia wrote: > > > On Fri, Jun 07, 2013 at 02:00:54PM -0600, Jason Gunthorpe wrote: > > > > > Right. I think we have two options here for laying the DT ranges. > > > > > > 1) This is the proposal implied in the patchset I sent: > > > > > > mbus { > > > ranges = < we only put the internal-reg translation here> > > > devbus-bootcs { > > > ranges = <0 {target_id/attribute} {window_physical_base} > > > {size}> > > > } > > > } > > > > As Jason explained, you cannot have the window_physical_base in the child > > device, that just wouldn't work. I don't know if that's a typo or a thinko > > > > I'm not sure what you mean by "that just wouldn't work". I understand it > may be a crappy DT layout, but it definitely works. I didn't mean to imply that you hadn't tested it. I guess it works fine if you put the same window_physical_base address into both the source and destination side mbus ranges property, but then you have to pass it three times in total and it gets really messy when you reassign it to a different physical address. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding
On Sat, Jun 08, 2013 at 07:45:06PM -0600, Jason Gunthorpe wrote: > On Sat, Jun 08, 2013 at 03:38:52PM -0300, Ezequiel Garcia wrote: [...] > > There are lots and lots of solutions using the pre-processor, please > take a look and find one that you feel works for you... > Ok, I will. > > We can always improve the dtc envorionment (as was done recently by > adding the preprocessor), we cannot change 'DT ABI' once it it set. > Right. Let me rework this using the preprocessor and send a v2. Thanks for the feedback! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding
On Sun, Jun 09, 2013 at 03:42:24PM +0200, Arnd Bergmann wrote: > On Saturday 08 June 2013 15:38:52 Ezequiel Garcia wrote: > > On Fri, Jun 07, 2013 at 02:00:54PM -0600, Jason Gunthorpe wrote: > > > Right. I think we have two options here for laying the DT ranges. > > > > 1) This is the proposal implied in the patchset I sent: > > > > mbus { > > ranges = < we only put the internal-reg translation here> > > devbus-bootcs { > > ranges = <0 {target_id/attribute} {window_physical_base} {size}> > > } > > } > > As Jason explained, you cannot have the window_physical_base in the child > device, that just wouldn't work. I don't know if that's a typo or a thinko ;-) > I'm not sure what you mean by "that just wouldn't work". I understand it may be a crappy DT layout, but it definitely works. The proposal I've sent in this patchset has been fully tested and works in A370 and AXP, with NOR, and PCIe devices. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: nomadik: add the new clocks to the device tree
On Sunday 09 June 2013, Linus Walleij wrote: > + /* > +* IP AMBA bus clocks, driving the bus side of the > +* peripheral clocking, clock gates. > +*/ > + > + hclkdma0: hclkdma0@48M { > + #clock-cells = <0>; > + compatible = "st,nomadik-src-clock"; > + clock-id = <0>; > + clocks = <&hclk>; > + }; > + hclksmc: hclksmc@48M { > + #clock-cells = <0>; > + compatible = "st,nomadik-src-clock"; > + clock-id = <1>; > + clocks = <&hclk>; > + }; > + hclksdram: hclksdram@48M { > + #clock-cells = <0>; > + compatible = "st,nomadik-src-clock"; > + clock-id = <2>; > + clocks = <&hclk>; > + }; > + hclkdma1: hclkdma1@48M { > + #clock-cells = <0>; > + compatible = "st,nomadik-src-clock"; > + clock-id = <3>; > + clocks = <&hclk>; > + }; Sorry if I'm being slow to understand how the clock bindings work, but if you have 63 identical clocks that only differ in ther clock-id, can't you just have a single DT node for them instead with #clock-cells=1 to pass the number from the device using it? Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding
On Saturday 08 June 2013 15:38:52 Ezequiel Garcia wrote: > On Fri, Jun 07, 2013 at 02:00:54PM -0600, Jason Gunthorpe wrote: > Right. I think we have two options here for laying the DT ranges. > > 1) This is the proposal implied in the patchset I sent: > > mbus { > ranges = < we only put the internal-reg translation here> > devbus-bootcs { > ranges = <0 {target_id/attribute} {window_physical_base} {size}> > } > } As Jason explained, you cannot have the window_physical_base in the child device, that just wouldn't work. I don't know if that's a typo or a thinko ;-) I also think {size} above there would just be 0x, right? > 2) This is what Jason is proposing in his mail: > > mbus { > ranges = <{target_id/attribute} 0 {window_physical_base} {size}> > devbus-bootcs { > ranges = <0 {target_id/attribute} 0 {size}> > } > } > > Of course this looks much cleaner, but it forces a lot of duplication > in the DT files. Now, if you see some of the recent patches we've been > sending, I think this duplication is very error-prone, and it'll be a > nightmare to maintain. Let me propose an example to show this > duplication: I don't see where that duplication comes in. The ranges in the "devbus-bootcs" are just describing how the hardware maps the child address space into the global mbus space, and that never changes. For the cases that only have a single device underneath, you can actually put an empty ranges property in there and adapt the "regs" property of whatever sits underneath it. These two representations would do exactly the same for instance: a) mbus { ranges = <...>; devbus-bootcs { #address-cells = <1>; #size-cells = <1>; ranges = <0 MBUS_BOOTCS 0 0x>; flash { regs = <0 0x10>; }; }; }; mbus { ranges = <...>; devbus-bootcs { #address-cells = <2>; #size-cells = <1>; ranges; flash { regs = ; }; }; }; > Let's suppose we have a board "A" with its armada-A.dts, > and a common one armada.dtsi. > > The common dtsi file would have this ranges property: > > /* armada.dtsi */ > mbus { > ranges = < internal_regs_id 0 internal_regs_base internal_regs_size >bootrom_id 0 bootrom_base bootrom_size > > } > > The A board has a NOR connected to some devbus, so we need to add it > to the ranges, but also need to duplicate the ones in the common dtsi: > > /* armada-A.dts */ > mbus { > ranges = < internal_regs_id 0 internal_regs_base internal_regs_size >bootrom_id 0 bootrom_base bootrom_size >devbus0_id 0 devbus0_base devbus0_size > > } I think the mbus ranges property is best left only in the board specific .dts file, since you don't know if all of the mappings are actually set up to the same value by all boot loaders. In order to avoid a situation where the mbus ranges describes a setting that is not actually programmed into the mbus controller by the boot loader, I would leave that empty by default and only fill it when the OS actually assigns a mapping. > Now, if we add something at the common level, and extend the ranges > property in the common armada.dtsi, we also have to go through *each* of > the per-board dts files (for *each* board) adding that entry, because > entries *need* to be duplicated. Otherwise you're effectively > "shadowing" the entries. We can't really do that anyway, as that would imply we also change all the boot loaders that have been deployed. I mentioned earlier that we could also have the mappings we /want/ described in the DT rather the ones that are set up, but after the discussion about the 0xd0/0xf1 window for the internal registers I think it's better to keep them in sync all the time. We can leave out mappings here that are set up but I'd prefer not to put mappings in there that are actually incorrect. When assigning the mappings, it's best to just go through all devices sitting below the mbus and pick an appropriate address for each 'reg' value that gets put into the mbus hardware and into the ranges property at the same time. The easiest algorithm would be to do a 'first fit' starting at the highest address that is not already occupied. If we need the physical address space to be more compact, we can also first sort all the resources by size. The simpler approach wastes at most the size difference between the smallest and the largest range, and that is probably good enough. I thought this was actually what you implemented already, but it seems I was wrong. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/dev
[patch -next] spi: spi-xilinx: cleanup a check in xilinx_spi_txrx_bufs()
'!' has higher precedence than comparisons so the original condition is equivalent to "if (xspi->remaining_bytes == 0)". This makes the static checkers complain. xspi->remaining_bytes is signed and from looking at the code briefly, I think it might be able to go negative. I suspect that going negative may cause a bug, but I don't have the hardware and can't test. Signed-off-by: Dan Carpenter diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c index 0b8398c..fb56fcf 100644 --- a/drivers/spi/spi-xilinx.c +++ b/drivers/spi/spi-xilinx.c @@ -301,7 +301,7 @@ static int xilinx_spi_txrx_bufs(struct spi_device *spi, struct spi_transfer *t) } /* See if there is more data to send */ - if (!xspi->remaining_bytes > 0) + if (xspi->remaining_bytes <= 0) break; } ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] clk: nomadik: implement the Nomadik clocks properly
The Nomadik clock implementation was a stub just using fixed clocks. This implements the clocks properly instead of relying on them all being on at boot and leaving them all on. The PLLs are on the top locking to the main chrystal oscillator, then the HCLK for the peripherals are below PLL2. The gated clocks are implemented with zero cells and given the clock ID as a property of each node, so every gate need to have its own node in the device tree. This is because the gate registers contain both HCLK gates and PCLK gates, where the latter has HCLK as parent. As can be seen from the register layout, this is a complete mixup, which means all these gates need their own node to properly model parent/child relations for PCLKs apart from the HCLKs. This driver also adds a helpful debugfs file to inspect the hardware state of the clock gates. This is the end result in /clk/clk_summary after applying a proper device tree: ulpiclk0 06000 mxtal 3 31920 pll21 186400 clk483 34800 rngcclk 1 14800 usbmclk 0 04800 mshcclk 0 04800 mspclk3 0 04800 x3dclk0 04800 skeclk0 04800 owmclk0 04800 mspclk2 0 04800 mspclk1 0 04800 uart2clk 0 04800 ipbmcclk 0 04800 ipi2cclk 0 04800 usbclk0 04800 mspclk0 0 04800 uart1clk 1 24800 i2c1clk 0 04800 i2c0clk 0 04800 sdiclk1 14800 uart0clk 0 04800 sspiclk 0 04800 irdaclk 0 04800 clk720 07200 difclk0 07200 clcdclk 0 07200 clk216 0 021600 hsiclkrx 0 021600 clk1080 010800 hsiclktx 0 010800 clk27 0 02700 pll11 126400 hclk 3 326400 hclkrng 1 126400 hclkusbm 0 026400 hclkcryp 0 026400 hclkhash 0 026400 hclk3d0 026400 hclkhpi 0 026400 hclksva 0 026400 hclksaa 0 026400 hclkdif 0 026400 hclkusb 0 026400 hclkclcd 0 026400 hclkdma1 0 026400 hclksdram 0 026400 hclksmc 1 126400 hclkdma0 0 026400 pclk 7 926400 pclkmsp3 0 026400 pclkmshc 0 026400 pclkhsem 0 026400 pclkske0 026400 pclkowm0 026400 pclkmsp2 0 026400 pclkmsp1 0 026400 pclkuart2 0 026400 pclkxti0 026400 pclkhsi0 026400 pclkmsp0 0 026400 pclkuart1 1 126400 pclki2c1 0 026400 pclki2c0 0 026400 pclksdi1 126400 pclkuart0 1 126400 pclkssp0 026400 pclkirda 0 026400 timclk 1 1240 Signed-off-by: Linus Walleij --- Hi Mike, I'm seeking an ACK to take this into the ARM SoC tree on top of the other pending Nomadik clock patches there. --- .../devicetree/bindings/clock/st,nomadik.txt | 104 drivers/clk/clk-nomadik.c | 553 - 2 files changed, 654 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/st,nomadik.txt diff --git a/Documentation/devicetree/bindings/clock/st,nomadik.txt b/Documentation/devicetree/bindings/clock/st,nomadik.txt new file mode 100644 index 000..7fc0977 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st,nomadik.txt @@ -0,0 +1,104 @@ +ST Microelectronics Nomadik SRC System Reset and Control + +This binding uses the common clock binding: +Documentation/devicetree/bindings/clock/clock-bindings.txt + +The Nomadik SRC controller is responsible of controlling chrystals, +PLLs and clock gates. + +Required properties for the SRC node: +- compatible: must be "stericsson,nomadik-src" +- reg: must contain the SRC register base and size + +Optional properties for the SRC node: +- disable-sxtalo: if
[PATCH 2/2] ARM: nomadik: add the new clocks to the device tree
This revamps the device tree to fit with the new clock implementation and brings it quite a bit closer to how the hardware actually works. After this the clock implementation knows about all clock gates and will gate off all unused clocks at boot time and save a bit of power. Signed-off-by: Linus Walleij --- arch/arm/boot/dts/ste-nomadik-s8815.dts| 6 + arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 501 ++--- 2 files changed, 470 insertions(+), 37 deletions(-) diff --git a/arch/arm/boot/dts/ste-nomadik-s8815.dts b/arch/arm/boot/dts/ste-nomadik-s8815.dts index 638ec8d..fd573d2 100644 --- a/arch/arm/boot/dts/ste-nomadik-s8815.dts +++ b/arch/arm/boot/dts/ste-nomadik-s8815.dts @@ -14,6 +14,12 @@ bootargs = "root=/dev/ram0 console=ttyAMA1,115200n8 earlyprintk"; }; + src@101e { + /* These chrystal drivers are not used on this board */ + disable-sxtalo; + disable-mxtalo; + }; + pinctrl { /* Hog CD pins */ pinctrl-names = "default"; diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi index dbf476b..a3acfa7 100644 --- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi +++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi @@ -168,37 +168,464 @@ src: src@101e { compatible = "stericsson,nomadik-src"; reg = <0x101e 0x1000>; - clocks { - /* -* Dummy clock for primecells -*/ - pclk: pclk@0 { - #clock-cells = <0>; - compatible = "fixed-clock"; - clock-frequency = <0>; - }; - /* -* The 2.4 MHz TIMCLK reference clock is active at -* boot time, this is actually the MXTALCLK @19.2 MHz -* divided by 8. This clock is used by the timers and -* watchdog. See page 105 ff. -*/ - timclk: timclk@2.4M { - #clock-cells = <0>; - compatible = "fixed-clock"; - clock-frequency = <240>; - }; - /* -* At boot time, PLL2 is set to generate a set of -* fixed clocks, one of them is CLK48, the 48 MHz -* clock, routed to the UART, MMC/SD, I2C, IrDA, -* USB and SSP blocks. -*/ - clk48: clk48@48M { - #clock-cells = <0>; - compatible = "fixed-clock"; - clock-frequency = <4800>; - }; + disable-sxtalo; + disable-mxtalo; + + /* +* MXTAL "Main Chrystal" is a chrystal oscillator @19.2 MHz +* that is parent of TIMCLK, PLL1 and PLL2 +*/ + mxtal: mxtal@19.2M { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <1920>; + }; + + /* +* The 2.4 MHz TIMCLK reference clock is active at +* boot time, this is actually the MXTALCLK @19.2 MHz +* divided by 8. This clock is used by the timers and +* watchdog. See page 105 ff. +*/ + timclk: timclk@2.4M { + #clock-cells = <0>; + compatible = "fixed-factor-clock"; + clock-div = <8>; + clock-mult = <1>; + clocks = <&mxtal>; + }; + + /* PLL1 is locked to MXTALI and variable from 20.4 to 334 MHz */ + pll1: pll1@0 { + #clock-cells = <0>; + compatible = "st,nomadik-pll-clock"; + pll-id = <1>; + clocks = <&mxtal>; + }; + + /* HCLK divides the PLL1 with 1,2,3 or 4 */ + hclk: hclk@0 { + #clock-cells = <0>; + compatible = "st,nomadik-hclk-clock"; + clocks = <&pll1>; + }; + /* The PCLK domain uses HCLK right off */ + pclk: pclk@0 { + #clock-cells = <0>; + compatible = "fixed-factor-clock"; + clock-div = <1>; + clock-mult = <1>; + clocks = <&hclk>; + }; + + /* PLL2 is usually 864 MHz and divided int
Re: [PATCH 2/2] i2c: designware: Add i2c-designware-hs
Hi zhangfei gao, On Sun, Jun 09, 2013 at 04:59:48PM +0800, zhangfei gao wrote: > >> +++ b/Documentation/devicetree/bindings/i2c/i2c-designware-hs.txt > >> @@ -0,0 +1,30 @@ > >> +* Hisilicon I2C Controller > >> + > >> +Required properties : > >> + > >> + - compatible : should be "hisilicon,designware-i2c" > >> + - reg : Offset and length of the register set for the device > >> + - interrupts : where IRQ is the interrupt number. > >> + > >> +Example : > >> + > >> + i2c0: i2c@fcb08000 { > >> + compatible = "hs,designware-i2c"; > > > > A few comments on this one: > > > > 1. You should Cc devicetree-discuss@lists.ozlabs.org on patches touching ftd > >bindings (added to Cc) > > > > 2. The convention is to use the IC block designer in the "compatible" > > property > >prefix, in this case Symopsys (snps) > > > > 3. This does not match the compatible property in hs_dw_i2c_of_match[] below > >where you use "hisilicon,designware-i2c" > > > > 4. Please update Documentation/devicetree/bindings/vendor-prefixes.txt when > >adding new vendor prefixes > > Thanks Baruch for the kind education, really useful. > How about using .compatible = "snps,hisilicon-i2c" I don't think this is needed. See below. > >> + Client in i2c0 bus with add 0x58 could be added as example > >> + i2c0: i2c@fcb08000 { > >> + status = "ok"; > > > > The convention is to use "okay". > got it. > > > > >> + pinctrl-names = "default"; > >> + pinctrl-0 = <&i2c0_pmx_func &i2c0_cfg_func>; > >> + i2c_client1: i2c_client@58 { > >> + compatible = "hisilicon,i2c_client_tpa2028"; > >> + reg = <0x58>; > >> + }; > >> + }; > > > > [...] > > > > The code below looks like a direct copy of i2c-designware-platdrv.c. Is > > there > > any reason you can't use that code instead? > > Not understood i2c-designware-platdrv.c can be directly touched. > Usually, there is register function, or external function call. > > It would be great if we could directly add hisilicon support in > i2c-designware-platdrv.c. > How about adding these code to distinguish. > > The concern is will platdrv.c become bigger and bigger? The overall code size becomes much bigger when duplicating the code. It makes code maintenance harder. > What in case private register have to be accessed? Good question. I don't know what is the common convention in this case. Do you have such a need here? > struct dw_i2c_data { > u32 accessor_flags; > unsigned int tx_fifo_depth; > unsigned int rx_fifo_depth; > }; > > static struct dw_i2c_data hisilicon_data = { > .accessor_flags = ACCESS_32BIT, This should be detected automatically in i2c_dw_init(). When ACCESS_16BIT is not set, access is 32bit wide. Doesn't it work for you? > .tx_fifo_depth = 16, > .rx_fifo_depth = 16, These should be encoded in new device-tree properties named "tx-fifo-size", and "rx-fifo-size". For example, see Documentation/devicetree/bindings/powerpc/4xx/emac.txt. baruch > }; > { .compatible = "snps,hisilicon-i2c", .data = &hisilicon_data}, -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}ooO--U--Ooo{= - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il - ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss