* Re: [PATCH] hwmon: twl4030-madc-hwmon: Add device tree support.
From: Mark Rutland @ 2014-02-14 13:31 UTC (permalink / raw)
To: Marek Belisko
Cc: robh+dt@kernel.org, Pawel Moll, ijc+devicetree@hellion.org.uk,
galak@codeaurora.org, rob@landley.net, jdelvare@suse.de,
linux@roeck-us.net, grant.likely@linaro.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org,
hns@goldelico.com
In-Reply-To: <1392384058-14240-1-git-send-email-marek@goldelico.com>
On Fri, Feb 14, 2014 at 01:20:58PM +0000, Marek Belisko wrote:
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
> Documentation/devicetree/bindings/hwmon/twl4030-madc-hwmon.txt | 9 +++++++++
> drivers/hwmon/twl4030-madc-hwmon.c | 10 ++++++++++
> 2 files changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/twl4030-madc-hwmon.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/twl4030-madc-hwmon.txt b/Documentation/devicetree/bindings/hwmon/twl4030-madc-hwmon.txt
> new file mode 100644
> index 0000000..e8016d1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/twl4030-madc-hwmon.txt
> @@ -0,0 +1,9 @@
> +TWL4030 MADC hwmon.
> +
> +Required properties:
> +- compatible: "ti,twl4030-madc-hwmon"
> +
> +Example:
> +madc-hwmon {
> + compatible = "ti,twl4030-madc-hwmon";
> +};
Huh?
What is this a binding for? From a look at the driver in mainline this
just calls into functions from the twl4030 madc driver (which doesn't
seem to have a binding).
This doesn't look like a description of hardware, but rather a hack to
get a Linux driver to probe. As far as I can see, no useful information
is given by this binding.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] power: twl4030_madc_battery: Add device tree support.
From: Marek Belisko @ 2014-02-14 13:24 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, rob,
dbaryshkov, dwmw2, grant.likely
Cc: devicetree, linux-doc, linux-kernel, hns, Marek Belisko
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
.../bindings/power_supply/twl4030_madc_battery.txt | 15 +++
drivers/power/twl4030_madc_battery.c | 109 +++++++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
new file mode 100644
index 0000000..bebc876
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
@@ -0,0 +1,15 @@
+twl4030_madc_battery
+
+Required properties:
+ - compatible : "ti,twl4030-madc-battery"
+ - capacity : battery capacity in uAh
+ - charging-calibration-data : list of voltage(mV):level(%) values for charging calibration (see example)
+ - discharging-calibration-data : list of voltage(mV):level(%) values for discharging calibration (see example)
+
+Example:
+ madc-battery {
+ compatible = "ti,twl4030-madc-battery";
+ capacity = <1200000>;
+ charging-calibration-data = <4200 100 4100 75 4000 55 3900 25 3800 5 3700 2 3600 1 3300 0>;
+ discharging-calibration-data = <4200 100 4100 95 4000 70 3800 50 3700 10 3600 5 3300 0>;
+ };
diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index 7ef445a..2843382 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -19,6 +19,7 @@
#include <linux/sort.h>
#include <linux/i2c/twl4030-madc.h>
#include <linux/power/twl4030_madc_battery.h>
+#include <linux/of.h>
struct twl4030_madc_battery {
struct power_supply psy;
@@ -188,6 +189,110 @@ static int twl4030_cmp(const void *a, const void *b)
((struct twl4030_madc_bat_calibration *)a)->voltage;
}
+#ifdef CONFIG_OF
+static struct twl4030_madc_bat_platform_data *
+ twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+ struct twl4030_madc_bat_platform_data *pdata;
+ struct device_node *np = pdev->dev.of_node;
+ struct property *prop;
+ int ret;
+ int sz, i, j = 0;
+
+ pdata = devm_kzalloc(&pdev->dev,
+ sizeof(struct twl4030_madc_bat_platform_data),
+ GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ ret = of_property_read_u32(np, "capacity", &pdata->capacity);
+ if (ret != 0)
+ return ERR_PTR(-EINVAL);
+
+ /* parse and prepare charging data */
+ prop = of_find_property(np, "charging-calibration-data", &sz);
+ if (!prop)
+ return ERR_PTR(-EINVAL);
+
+ if (sz % 2) {
+ dev_warn(&pdev->dev, "Count of charging-calibration-data must be even!\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ sz /= sizeof(u32);
+
+ {
+ u32 data[sz];
+
+ ret = of_property_read_u32_array(np,
+ "charging-calibration-data", &data[0], sz);
+ if (ret)
+ return ERR_PTR(ret);
+
+ pdata->charging = devm_kzalloc(&pdev->dev,
+ sizeof(struct twl4030_madc_bat_calibration) * (sz / 2),
+ GFP_KERNEL);
+
+ for (i = 0; i < sz; i += 2) {
+ pdata->charging[j].voltage = data[i];
+ pdata->charging[j].level = data[i+1];
+ j++;
+ }
+
+ pdata->charging_size = sz / 2;
+ }
+
+ /* parse and prepare discharging data */
+ prop = of_find_property(np, "discharging-calibration-data", &sz);
+ if (!prop)
+ return ERR_PTR(-EINVAL);
+
+ if (sz % 2) {
+ dev_warn(&pdev->dev, "Count of discharging-calibration-data must be even!\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ sz /= sizeof(u32);
+
+ {
+ u32 data[sz];
+
+ ret = of_property_read_u32_array(np,
+ "discharging-calibration-data", &data[0], sz);
+ if (ret)
+ return ERR_PTR(ret);
+
+ j = 0;
+
+ pdata->discharging = devm_kzalloc(&pdev->dev,
+ sizeof(struct twl4030_madc_bat_calibration) * (sz / 2),
+ GFP_KERNEL);
+
+ for (i = 0; i < sz; i += 2) {
+ pdata->discharging[j].voltage = data[i];
+ pdata->discharging[j].level = data[i+1];
+ j++;
+ }
+
+ pdata->discharging_size = sz / 2;
+ }
+
+ return pdata;
+}
+
+static const struct of_device_id of_twl4030_madc_match[] = {
+ { .compatible = "ti,twl4030-madc-battery", },
+ {},
+};
+
+#else
+static struct twl4030_madc_bat_platform_data *
+ twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
static int twl4030_madc_battery_probe(struct platform_device *pdev)
{
struct twl4030_madc_battery *twl4030_madc_bat;
@@ -197,6 +302,9 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
if (!twl4030_madc_bat)
return -ENOMEM;
+ if (!pdata)
+ pdata = twl4030_madc_dt_probe(pdev);
+
twl4030_madc_bat->psy.name = "twl4030_battery";
twl4030_madc_bat->psy.type = POWER_SUPPLY_TYPE_BATTERY;
twl4030_madc_bat->psy.properties = twl4030_madc_bat_props;
@@ -234,6 +342,7 @@ static int twl4030_madc_battery_remove(struct platform_device *pdev)
static struct platform_driver twl4030_madc_battery_driver = {
.driver = {
.name = "twl4030_madc_battery",
+ .of_match_table = of_match_ptr(of_twl4030_madc_match),
},
.probe = twl4030_madc_battery_probe,
.remove = twl4030_madc_battery_remove,
--
1.8.3.2
^ permalink raw reply related
* [PATCH] hwmon: twl4030-madc-hwmon: Add device tree support.
From: Marek Belisko @ 2014-02-14 13:20 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, rob,
jdelvare, linux, grant.likely
Cc: devicetree, linux-doc, linux-kernel, lm-sensors, hns,
Marek Belisko
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
Documentation/devicetree/bindings/hwmon/twl4030-madc-hwmon.txt | 9 +++++++++
drivers/hwmon/twl4030-madc-hwmon.c | 10 ++++++++++
2 files changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/twl4030-madc-hwmon.txt
diff --git a/Documentation/devicetree/bindings/hwmon/twl4030-madc-hwmon.txt b/Documentation/devicetree/bindings/hwmon/twl4030-madc-hwmon.txt
new file mode 100644
index 0000000..e8016d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/twl4030-madc-hwmon.txt
@@ -0,0 +1,9 @@
+TWL4030 MADC hwmon.
+
+Required properties:
+- compatible: "ti,twl4030-madc-hwmon"
+
+Example:
+madc-hwmon {
+ compatible = "ti,twl4030-madc-hwmon";
+};
diff --git a/drivers/hwmon/twl4030-madc-hwmon.c b/drivers/hwmon/twl4030-madc-hwmon.c
index 6c6d440..05fb572 100644
--- a/drivers/hwmon/twl4030-madc-hwmon.c
+++ b/drivers/hwmon/twl4030-madc-hwmon.c
@@ -96,6 +96,15 @@ static const struct attribute_group twl4030_madc_group = {
.attrs = twl4030_madc_attributes,
};
+#ifdef CONFIG_OF
+
+static const struct of_device_id of_twl4030_madc_hwmon_match[] = {
+ { .compatible = "ti,twl4030-madc-hwmon", },
+ {},
+};
+
+#endif
+
static int twl4030_madc_hwmon_probe(struct platform_device *pdev)
{
int ret;
@@ -134,6 +143,7 @@ static struct platform_driver twl4030_madc_hwmon_driver = {
.driver = {
.name = "twl4030_madc_hwmon",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(of_twl4030_madc_hwmon_match),
},
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: twl4030: Add twl4030-madc node.
From: Marek Belisko @ 2014-02-14 13:17 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, rob,
linux, grant.likely
Cc: devicetree, linux-doc, linux-kernel, linux-arm-kernel, hns,
Marek Belisko
In-Reply-To: <1392383861-14169-1-git-send-email-marek@goldelico.com>
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/boot/dts/twl4030.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 4217096..e6dec53 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -145,4 +145,9 @@
compatible = "ti,twl4030-pwrbutton";
interrupts = <8>;
};
+
+ twl_madc: madc {
+ compatible = "ti,twl4030-madc";
+ interrupts = <1>;
+ };
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/2] mfd: twl4030-madc: Add devicetree support.
From: Marek Belisko @ 2014-02-14 13:17 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, rob,
linux, grant.likely
Cc: devicetree, linux-doc, linux-kernel, linux-arm-kernel, hns,
Marek Belisko
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
.../devicetree/bindings/mfd/twl4030-madc.txt | 18 +++++++++++++
drivers/mfd/twl4030-madc.c | 31 ++++++++++++++++++++--
2 files changed, 47 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/twl4030-madc.txt
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-madc.txt b/Documentation/devicetree/bindings/mfd/twl4030-madc.txt
new file mode 100644
index 0000000..9df66ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/twl4030-madc.txt
@@ -0,0 +1,18 @@
+Texas Instruments TWL family (twl4030) analog signal conversion monitor module
+
+Required properties:
+- compatible : must be "ti,twl4030-madc"
+- interrupts : interrupt number
+
+Example:
+twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+
+ twl_madc: madc {
+ compatible = "ti,twl4030-madc";
+ interrupts = <1>;
+ };
+};
+
diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 4c583e4..9a2bbcf 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -695,6 +695,29 @@ static int twl4030_madc_set_power(struct twl4030_madc_data *madc, int on)
return 0;
}
+#ifdef CONFIG_OF
+static struct twl4030_madc_platform_data *
+ twl4030_madc_of_parse(struct platform_device *pdev)
+{
+ struct twl4030_madc_platform_data *pdata;
+
+ pdata = devm_kzalloc(&pdev->dev,
+ sizeof(struct twl4030_madc_platform_data), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ pdata->irq_line = platform_get_irq(pdev, 0);
+
+ return pdata;
+}
+
+static const struct of_device_id twl4030_madc_dt_match_table[] = {
+ { .compatible = "ti,twl4030-madc" },
+ {},
+};
+
+#endif
+
/*
* Initialize MADC and request for threaded irq
*/
@@ -706,8 +729,11 @@ static int twl4030_madc_probe(struct platform_device *pdev)
u8 regval;
if (!pdata) {
- dev_err(&pdev->dev, "platform_data not available\n");
- return -EINVAL;
+ pdata = twl4030_madc_of_parse(pdev);
+ if (!pdata) {
+ dev_err(&pdev->dev, "platform_data not available\n");
+ return -EINVAL;
+ }
}
madc = kzalloc(sizeof(*madc), GFP_KERNEL);
if (!madc)
@@ -807,6 +833,7 @@ static struct platform_driver twl4030_madc_driver = {
.driver = {
.name = "twl4030_madc",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(twl4030_madc_dt_match_table),
},
};
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v7 03/12] mfd: omap-usb-host: Use clock names as per function for reference clocks
From: Roger Quadros @ 2014-02-14 13:12 UTC (permalink / raw)
To: Lee Jones
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, bcousson-rdvid1DuHRBWk0Htik3J/w,
balbi-l0cyMroinI0, nm-l0cyMroinI0, khilman-QSEj5FYQhm4dnm+yROfE0A,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz
In-Reply-To: <20140214100915.GD7380@lee--X1>
On 02/14/2014 12:09 PM, Lee Jones wrote:
>> Use a meaningful name for the reference clocks so that it indicates the function.
>>
>> CC: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> CC: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>> ---
>> drivers/mfd/omap-usb-host.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 60a3bed..ce620a8 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
>> goto err_mem;
>> }
>>
>> - omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
>> + omap->xclk60mhsp1_ck = devm_clk_get(dev, "refclk_60m_ext_p1");
>
> You can't do that. These changes will have to be in the same patch as
> the core change i.e. where they are initialised.
I'm not touching them anywhere in this series. When core changes are you
referring to?
>
>> if (IS_ERR(omap->xclk60mhsp1_ck)) {
>> ret = PTR_ERR(omap->xclk60mhsp1_ck);
>> dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
>> goto err_mem;
>> }
>>
>> - omap->xclk60mhsp2_ck = devm_clk_get(dev, "xclk60mhsp2_ck");
>> + omap->xclk60mhsp2_ck = devm_clk_get(dev, "refclk_60m_ext_p2");
>> if (IS_ERR(omap->xclk60mhsp2_ck)) {
>> ret = PTR_ERR(omap->xclk60mhsp2_ck);
>> dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
>> goto err_mem;
>> }
>>
>> - omap->init_60m_fclk = devm_clk_get(dev, "init_60m_fclk");
>> + omap->init_60m_fclk = devm_clk_get(dev, "refclk_60m_int");
>> if (IS_ERR(omap->init_60m_fclk)) {
>> ret = PTR_ERR(omap->init_60m_fclk);
>> dev_err(dev, "init_60m_fclk failed error:%d\n", ret);
>
--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Instructions to release your payment.
From: Dr.William Davies @ 2014-02-14 12:30 UTC (permalink / raw)
Attention
Sir,
Following an application brought, seeking the release of your due payment
through British bank, I am directed to inform you that the application has
been approved and Natwest bank of London has been mandated to make transfer
of your payment to the bank account you will nominate. Please kindly reply
for immediate release of your US$6.2 Million to you nominates account.
Sir, for the avoidance of doubts, reconfirm the following information to
me to enable us forward same to Natwest bank to contact you for your
payment.
Name:
Address:
Tel/Fax No.:
Nationality:
Occupation:
Date of birth:
As soon as I received the above information, I will forward them to
Natwest bank to contact you for your approved payment. Please see in the
attachment, letter I wrote to Natwest bank informing them of the
transaction
Yours faithfully
Dr.William Davies
Chairman,British Banking Regulatory Board.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 3/3] mmc: core: Add DT bindings for eMMC HS200 1.8/1.2V
From: Ulf Hansson @ 2014-02-14 12:27 UTC (permalink / raw)
To: linux-mmc, Chris Ball; +Cc: Jaehoon Chung, devicetree
In-Reply-To: <1392380829-8473-1-git-send-email-ulf.hansson@linaro.org>
From: Jaehoon Chung <jh80.chung@samsung.com>
Provide the option to configure these speed modes per host, for those
host driver's that can't distinguish this in runtime.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++
drivers/mmc/core/host.c | 4 ++++
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index 519d952..9dce540 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -36,6 +36,8 @@ Optional properties:
- full-pwr-cycle: full power cycle of the card is supported
- mmc-highspeed-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported
- mmc-highspeed-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported
+- mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported
+- mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
*NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
polarity properties, we have to fix the meaning of the "normal" and "inverted"
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index d014127..453573d 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -443,6 +443,10 @@ int mmc_of_parse(struct mmc_host *host)
host->caps |= MMC_CAP_1_8V_DDR;
if (of_find_property(np, "mmc-ddr-1_2v", &len))
host->caps |= MMC_CAP_1_2V_DDR;
+ if (of_find_property(np, "mmc-hs200-1_8v", &len))
+ host->caps2 |= MMC_CAP2_HS200_1_8V_SDR;
+ if (of_find_property(np, "mmc-hs200-1_2v", &len))
+ host->caps2 |= MMC_CAP2_HS200_1_2V_SDR;
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] mmc: core: Add DT bindings for eMMC high-speed DDR 1.8/1.2V
From: Ulf Hansson @ 2014-02-14 12:27 UTC (permalink / raw)
To: linux-mmc, Chris Ball; +Cc: Jaehoon Chung, devicetree, Ulf Hansson
In-Reply-To: <1392380829-8473-1-git-send-email-ulf.hansson@linaro.org>
Provide the option to configure these speed modes per host, for those
host driver's that can't distinguish this in runtime.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++
drivers/mmc/core/host.c | 4 ++++
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index bd2ce67..519d952 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -34,6 +34,8 @@ Optional properties:
- cap-power-off-card: powering off the card is safe
- cap-sdio-irq: enable SDIO IRQ signalling on this interface
- full-pwr-cycle: full power cycle of the card is supported
+- mmc-highspeed-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported
+- mmc-highspeed-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported
*NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
polarity properties, we have to fix the meaning of the "normal" and "inverted"
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 2644d91..d014127 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -439,6 +439,10 @@ int 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;
+ if (of_find_property(np, "mmc-ddr-1_8v", &len))
+ host->caps |= MMC_CAP_1_8V_DDR;
+ if (of_find_property(np, "mmc-ddr-1_2v", &len))
+ host->caps |= MMC_CAP_1_2V_DDR;
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] mmc: core: Add DT bindings for SD card's UHS bus speed modes
From: Ulf Hansson @ 2014-02-14 12:27 UTC (permalink / raw)
To: linux-mmc, Chris Ball; +Cc: Jaehoon Chung, devicetree, Ulf Hansson
Provide the option to configure these speed modes per host, for those
host driver's that can't distinguish this in runtime.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Documentation/devicetree/bindings/mmc/mmc.txt | 5 +++++
drivers/mmc/core/host.c | 10 ++++++++++
2 files changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index 458b57f..bd2ce67 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -26,6 +26,11 @@ Optional properties:
this system, even if the controller claims it is.
- cap-sd-highspeed: SD high-speed timing is supported
- cap-mmc-highspeed: MMC high-speed timing is supported
+- sd-uhs-sdr12: SD UHS SDR12 speed is supported
+- sd-uhs-sdr25: SD UHS SDR25 speed is supported
+- sd-uhs-sdr50: SD UHS SDR50 speed is supported
+- sd-uhs-sdr104: SD UHS SDR104 speed is supported
+- sd-uhs-ddr50: SD UHS DDR50 speed is supported
- cap-power-off-card: powering off the card is safe
- cap-sdio-irq: enable SDIO IRQ signalling on this interface
- full-pwr-cycle: full power cycle of the card is supported
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 49bc403..2644d91 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -419,6 +419,16 @@ int mmc_of_parse(struct mmc_host *host)
host->caps |= MMC_CAP_SD_HIGHSPEED;
if (of_find_property(np, "cap-mmc-highspeed", &len))
host->caps |= MMC_CAP_MMC_HIGHSPEED;
+ if (of_find_property(np, "sd-uhs-sdr12", &len))
+ host->caps |= MMC_CAP_UHS_SDR12;
+ if (of_find_property(np, "sd-uhs-sdr25", &len))
+ host->caps |= MMC_CAP_UHS_SDR25;
+ if (of_find_property(np, "sd-uhs-sdr50", &len))
+ host->caps |= MMC_CAP_UHS_SDR50;
+ if (of_find_property(np, "sd-uhs-sdr104", &len))
+ host->caps |= MMC_CAP_UHS_SDR104;
+ if (of_find_property(np, "sd-uhs-ddr50", &len))
+ host->caps |= MMC_CAP_UHS_DDR50;
if (of_find_property(np, "cap-power-off-card", &len))
host->caps |= MMC_CAP_POWER_OFF_CARD;
if (of_find_property(np, "cap-sdio-irq", &len))
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
From: Tomasz Figa @ 2014-02-14 11:49 UTC (permalink / raw)
To: Rahul Sharma, Tomasz Figa
Cc: Rahul Sharma, linux-samsung-soc, Kukjin Kim, sunil joshi,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, Mark Rutland, Grant Likely, Ian Campbell, Pawel Moll,
Kumar Gala
In-Reply-To: <CAPdUM4Pr7UC3wzYMsO+sYQHRDGixSNsR3XQuHBomsi-H-dfOZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 14.02.2014 12:28, Rahul Sharma wrote:
> On 14 February 2014 08:54, Rahul Sharma <r.sh.open-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Thanks Tomasz,
>>
>> I will add these changes to v3.
>>
>> Regards,
>> Rahul Sharma.
>>
>> On 11 February 2014 15:34, Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> Hi Rahul,
>>>
>>>
>>> On 11.02.2014 06:22, Rahul Sharma wrote:
>>>>
>>>> Hi Tomasz,
>>>>
>>>> On 6 February 2014 18:51, Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>>>>>
>>>>> Hi Rahul, Pankaj, Arun,
>>>>>
>>>>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>>>>>
>>>>> I think it's good time to stop accepting DTS files like this and force
>>>>> new
>>>>> ones to use the proper structure with soc node, labels for every node and
>>>>> node references.
>>>>
>>>>
>>>> I am unable to find information on SoC node and grouping inside SoC node.
>>>> Please
>>>> share some pointers.
>>>
>>>
>>> Well, there is not much information needed about this. Basically all the
>>> devices built into the SoC should be listed under respective bus nodes or a
>>> single soc node, instead of root level. Such node should be a "simple-bus"
>>> and just group the components together to separate board-specific devices
>>> (which are still at root level) from SoC devices.
>>>
>>> Even though it might seem useless, it improves DT readability a bit and
>>> still most of the platforms use this approach, so for consistency, Exynos
>>> should use too.
>>>
>>> Just for reference, back in April 2013, in his review of S3C64xx DT series
>>> [1], Rob Herring requested that we don't submit any new device trees using
>>> flat approach and start using bus hierarchy.
>>>
>>> [1]
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html
>>>
>>>
>>>>>
>>>>>> + spi0_bus: spi0-bus {
>>>>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>>>>>> "gpa2-3";
>>>>>
>>>>>
>>>>>
>>>>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>>>>>
>>>>
>>>> I should align SPI1 with SPI0.
>>>>
>>>
>>> Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI,
>>> SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to
>>> the fact that the controller can only support one dedicated chip select and
>>> with direct GPIO control you can have more.
>>>
>>> What is the fourth pin here?
>>>
>
> As you said, these are CLK, SS, MISO, MOSI (gpa2-0 to gpa2-3). Fourth pin is
> CS. It can be defined as a simple GPIO but better to include it in the
> SPI pingroup
> as it belongs to there.
I have to disagree here.
If you define a pin in pinctrl group then it is tied to this specific
hardware function and you can't use it as GPIO.
Since it's board specific to use it as HW chip select or GPIO chip
select (the usual setup), it should not be included in this group.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
From: Rahul Sharma @ 2014-02-14 11:28 UTC (permalink / raw)
To: Tomasz Figa
Cc: Tomasz Figa, Rahul Sharma, linux-samsung-soc, Kukjin Kim,
sunil joshi, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Rob Herring, Mark Rutland,
Grant Likely, Ian Campbell, Pawel Moll, Kumar Gala
In-Reply-To: <CAPdUM4Pu-CbuNwwjrd_8itbSbjKqTBLE5u_T_vO89jreOy4=kQ@mail.gmail.com>
On 14 February 2014 08:54, Rahul Sharma <r.sh.open@gmail.com> wrote:
> Thanks Tomasz,
>
> I will add these changes to v3.
>
> Regards,
> Rahul Sharma.
>
> On 11 February 2014 15:34, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>> Hi Rahul,
>>
>>
>> On 11.02.2014 06:22, Rahul Sharma wrote:
>>>
>>> Hi Tomasz,
>>>
>>> On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
>>>>
>>>> Hi Rahul, Pankaj, Arun,
>>>>
>>>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>>>>
>>>> I think it's good time to stop accepting DTS files like this and force
>>>> new
>>>> ones to use the proper structure with soc node, labels for every node and
>>>> node references.
>>>
>>>
>>> I am unable to find information on SoC node and grouping inside SoC node.
>>> Please
>>> share some pointers.
>>
>>
>> Well, there is not much information needed about this. Basically all the
>> devices built into the SoC should be listed under respective bus nodes or a
>> single soc node, instead of root level. Such node should be a "simple-bus"
>> and just group the components together to separate board-specific devices
>> (which are still at root level) from SoC devices.
>>
>> Even though it might seem useless, it improves DT readability a bit and
>> still most of the platforms use this approach, so for consistency, Exynos
>> should use too.
>>
>> Just for reference, back in April 2013, in his review of S3C64xx DT series
>> [1], Rob Herring requested that we don't submit any new device trees using
>> flat approach and start using bus hierarchy.
>>
>> [1]
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html
>>
>>
>>>>
>>>>> + spi0_bus: spi0-bus {
>>>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>>>>> "gpa2-3";
>>>>
>>>>
>>>>
>>>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>>>>
>>>
>>> I should align SPI1 with SPI0.
>>>
>>
>> Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI,
>> SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to
>> the fact that the controller can only support one dedicated chip select and
>> with direct GPIO control you can have more.
>>
>> What is the fourth pin here?
>>
As you said, these are CLK, SS, MISO, MOSI (gpa2-0 to gpa2-3). Fourth pin is
CS. It can be defined as a simple GPIO but better to include it in the
SPI pingroup
as it belongs to there.
Regards,
Rahul Sharma.
>>
>>>>
>>>>> + cpu@1 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a15";
>>>>> + reg = <1>;
>>>>> + cci-control-port = <&cci_control1>;
>>>>> + };
>>>>> + cpu@100 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x100>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + cpu@101 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x101>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + cpu@102 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x102>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + cpu@103 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x103>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + cmus {
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <1>;
>>>>> + ranges;
>>>>> +
>>>>
>>>>
>>>>
>>>> I don't think there is a need to group these nodes under a parent node
>>>> that
>>>> doesn't give any additional information, especially when the CMUs are
>>>> scattered trough the whole address space, while we'd like to keep the
>>>> nodes
>>>> ordered by their addresses, as most platforms do.
>>>>
>>>
>>> This is exactly the same case as "cpus". I mean, "cpus" also doesn't
>>> provide
>>> any common information about child cpu nodes. This looks to me as a
>>> logical
>>> grouping and I have implemented same thing for cmu nodes.
>>> I am ok with removing this grouping Just want to understand the rational
>>> behind
>>> grouping cpus which seems similar to cmus.
>>
>>
>> The "cpus" node is a defined standard node that should be present at root of
>> device tree and include subnodes for all CPUs. This is a standard binding
>> defined for low level code to be able to simply find nodes of all CPUs in
>> the system - so they can expect that at /cpus node all the subnodes are
>> subsequent CPUs.
>>
>>
>>> Similarly "soc" is just a logical entity used to group SoC elements which
>>> looks
>>> optional to me. What are we achieving with this? Please help me in
>>> understanding
>>> this better.
>>
>>
>> Also "soc" has a slightly wider meaning. It is a node grouping all nodes
>> from a single address space - the node specifies #address-cells and
>> #size-cells of this address space and all the devices under this
>> "simple-bus" can be accessed using addresses in this format. In addition, it
>> separates board-level devices from generic SoC devices.
>>
>> Now, in case of "cmus", the only purpose is to group all CMU nodes together
>> and, while this improves readability a bit, it doesn't make the DT better
>> express the hardware topology, because the CMUs in the hardware are in fact
>> scattered through the whole address space, not under a contiguous block of
>> it, as the grouping would suggest.
>>
>> Best regards,
>> Tomasz
^ permalink raw reply
* Re: [PATCH RFC v3 3/3] Documentation: arm: define DT idle states bindings
From: Lorenzo Pieralisi @ 2014-02-14 11:27 UTC (permalink / raw)
To: Sebastian Capella
Cc: Mark Rutland, Mike Turquette, Tomasz Figa, Mark Hambleton,
Russell King, Nicolas Pitre, Daniel Lezcano,
linux-arm-kernel@lists.infradead.org, grant.likely@linaro.org,
Dave P Martin, Charles Garcia-Tobin, devicetree@vger.kernel.org,
Kevin Hilman, linux-pm@vger.kernel.org, Kumar Gala, Rob Herring,
Vincent Guittot, Antti Miettinen, pveerapa@broadcom.com,
Peter De Schrijver
In-Reply-To: <20140214002926.1014.3599@capellas-linux>
On Fri, Feb 14, 2014 at 12:29:26AM +0000, Sebastian Capella wrote:
> Quoting Lorenzo Pieralisi (2014-02-13 04:47:32)
>
> > Such as ? "idle-states" ?
>
> That sounds good to me. Our preference is for idle-states to be used
> for name of the idle-states.txt node.
Ok, so s/cpu-idle-state/idle-state everywhere, inclusive of state nodes
compatible properties ("arm,cpu-idle-state" becomes "arm,idle-state") ?
> > > During last connect, we'd discussed that the small set of
> > > states here could apply to a single node, which can represent a cpu, a
> > > cluster with cache etc. Then the complexities of the system power state
> > > would be represented using a heirarchy, with each node in the
> > > tree having its own state from the list above. This would allow
> > > a fairly rich system state while having just a few power states defined
> > > at each level. Is this how you're intending these bindings to go?
> >
> > Yes, CPUs point at states that can be reached by that CPU (eg a CPU core
> > gating state is represented by a single node pointed at by all CPUs in the
> > system - it the same state data, different power domains though).
> >
> > States are hierarchical, which means that a parent state implies entry on all
> > substates that's how cluster states are defined.
>
> The cpu 0 node, in its cpu-idle-state array is also pointing at a cluster
> node right? STATE0 -> power-domains refers to <pd_clusters 0>. Is it
> correct that if the cpu's workload is such that it tolerates the
> 500/1000/2500 entry/exit latency/min-residency, it will call the
> entry-method with the psci-power-state of 0x10100000 matching that node?
Yes. As we know, since it is a cluster state, that might happen or not
depending on the state of other CPUs.
> > > Also, would it be nice to have a name field for each state?
> >
> > There is:
> >
> > "The state node name shall be "stateN", where N = {0, 1, ...} is
> > the node number; state nodes which are siblings within a single
> > common parent node must be given a unique and sequential N value,
> > starting from 0."
> > I can remove the rule and allow people to call states as they wish
> > since they already have a compatible property to match them.
> >
> > Actually, states can be called with any name, provided it is unique.
>
> Sorry, I was referring to a descriptive name string property. Something
> that can be useful to help a human understand what's going on. Naming
> the nodes might work too.
I do not like that, but I can remove the naming scheme and let people
find a naming scheme that complies with DT rules (nodes within a parent
must have a unique name). Not sure this would make dts more readable, but
I do not think it is a problem either.
> > > > + A state node can contain state child nodes. A state node with
> > > > + children represents a hierarchical state, which is a superset of
> > > > + the child states. Hierarchical states require all CPUs on which
> > > > + they are valid to request the state in order for it to be entered.
> > >
> > > Is it possible for a cpu to request a deeper state and unblock other cpus
> > > from entering this state?
> >
> > That's not DT bindings business, hierarchical states define states that
> > require all CPUs on which they are valid to enter that state for it to
> > be considered "enabled".
> >
> > It is a hard nut to crack. In x86 this stuff does not exist and it is
> > managed in HW, basically an idle state is always per-cpu (but it might
> > end up becoming a package state when all CPUs in a package enter that
> > state). On ARM, we want to define hierarchical states explicitly to
> > link resources (ie caches) to them.
> >
> > CPUs are not prevented from requesting a hierarchical state, but the
> > state only becomes "enabled" when all CPUs on which it is valid request
> > it.
>
> The way we've seen it work, is a cpu tries to enter the lowest state it can
> tolerate (including for eg. cluster off). The system level code then looks
> at the allowable states from all the cpus and selects the lowest power
> state permissible for the heirarchies.
>
> Eg. this way, the last cpu preventing a cluster from going to sleep enters
> cluster sleep state (where peer cpu's have already voted for cluster
> sleep) and the cluster will sleep. Alternately if the same cpu cannot
> tolerate the additional latency of the cluster sleeping, it will vote
> only for cpu-sleep, then the cluster remains in a state where all cpu's are
> sleeping but the cluster remains up.
That's exactly what these bindings are meant to describe too and I think they
do. There is also loads of information that can be used for tuning (what
caches are affected by an idle state, what CPUs "share" an idle-state
and so on).
> > I cannot think of any other way of to express this properly but still in
> > a compact way.
>
> You're doing a great job by the way! Thanks! :)
Thank you, we are almost there.
> > > "all CPUs on which they are valid" is this determined by seeing which
> > > state's phandle is in each cpu->cpu-idle-states?
> >
> > Yes, does it make sense ?
>
> Yup, maybe adding a little parenthetical text like below may help others
> as well?
>
> Hierarchical states require all CPUs on which they are valid (ie. CPU nodes
> containing cpu-idle-state arrays having a phandle reference to the state)
> to request the state in order for it to be entered.
OK, applied.
> >
> > > Definition: It represents an idle state index.
> > >
> > > Index 0 and 1 shall not be specified and are reserved for ARM
> > > states where index 0 is running, and index 1 is idle_standby
> > > entered by executing a wfi instruction (SBSA,[3])
> > >
> > > What mechanism is used to order the power states WRT power consumption?
> >
> > I think we should use index for that. The higher the index the lower the
> > power consumption.
>
> Ok, I think I get it now.
> If we decouple index and SBSA states, do we really need to reserve index
> 0 and 1 then?
What I will do: move the entry-method to top-level cpu-idle-states node
(soon to be idle-states node) and add a property there:
"arm,has-idlewfi"
which allows me to prevent people from adding an explicit state that just
executes the wfi instruction on entry.
This way we can have a *global* entry-method, and we can also detect if the
platform supports wfi in its bare form.
Yes, index can start from 0, disallowing 0 and 1 was a (odd) way to prevent
people from adding wfi to DT. If the platform supports simple idlestandby
(ie wfi) it has to add the boolean property above.
How does that sound ?
> > > Can this field be used to combine both psci and non-psci states in any order?
> >
> > No. I will enforce a unique entry method.
>
> So a single entry-method for all states in idle-states node?
> Should this be specified once only then?
Yes, see above.
> Should we not allow more flexibility here to mix methods where some
> states use one method and some use others? Is this mostly a security
> concern? What if a vendor wants to introduce a state between wfi and
> cpu-sleep?
entry-method-param is the way to differentiate. One interface/entry-method
(PSCI or vendor specific), different state parameters.
We are not installing multiple back-ends to enter different idle states,
are we ? That would be awkward.
ACK ?
> > > I assume psci will be turning off the powerdomains not Linux right?
> >
> > This is not a PSCI only document, and even if it was, we still need to deal
> > with devices. Which means we need to know what we have to save/restore (PMU,
> > arch timer, GIC), and power domains help us detect that.
>
> > > > +
> > > > +cpus {
> > > > + #size-cells = <0>;
> > > > + #address-cells = <2>;
> > > > +
> > > > + cpu-idle-states {
> > > > +
> > > > + STATE0: state0 {
> > > > + compatible = "arm,cpu-idle-state";
> > > > + index = <3>;
> > >
> > > Are the index fields of nested states independent of each other or
> > > sequential?
> > ...
> > I understand index is misleading and either I remove it, or I
> > leave it there to define power savings scale as you mentioned.
>
> I like index, but I was confused. You cleared it up pretty quick with
> your earlier comment. Removing the numbering may help, but I think
> keeping the index is useful.
I will leave the index to sort the states according to power consumption.
Thanks !
Lorenzo
^ permalink raw reply
* [PATCH 3/4] ARM: DT: STi: Add DT node for MiPHY365x
From: Lee Jones @ 2014-02-14 11:23 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: alexandre.torgue, Lee Jones, devicetree, Srinivas Kandagatla
In-Reply-To: <1392377036-12816-1-git-send-email-lee.jones@linaro.org>
The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
devices. It has 2 ports which it can use for either; both SATA, both
PCIe or one of each in any configuration.
Cc: devicetree@vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/stih416-b2020-revE.dts | 6 +++++-
arch/arm/boot/dts/stih416-b2020.dts | 6 ++++++
arch/arm/boot/dts/stih416.dtsi | 13 +++++++++++++
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stih416-b2020-revE.dts b/arch/arm/boot/dts/stih416-b2020-revE.dts
index a874570..dbe67fa 100644
--- a/arch/arm/boot/dts/stih416-b2020-revE.dts
+++ b/arch/arm/boot/dts/stih416-b2020-revE.dts
@@ -32,6 +32,10 @@
ethernet1: ethernet@fef08000 {
snps,reset-gpio = <&PIO0 7>;
};
- };
+ miphy365x_phy: miphy365x@0 {
+ st,pcie_tx_pol_inv = <1>;
+ st,sata_gen = "gen3";
+ };
+ };
};
diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
index 276f28d..fd9cbad 100644
--- a/arch/arm/boot/dts/stih416-b2020.dts
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -13,4 +13,10 @@
model = "STiH416 B2020";
compatible = "st,stih416", "st,stih416-b2020";
+ soc {
+ miphy365x_phy: miphy365x@0 {
+ st,pcie_tx_pol_inv = <1>;
+ st,sata_gen = "gen3";
+ };
+ };
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 85b8063..9fd8efb 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -9,6 +9,8 @@
#include "stih41x.dtsi"
#include "stih416-clock.dtsi"
#include "stih416-pinctrl.dtsi"
+
+#include <dt-bindings/phy/phy-miphy365x.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset-controller/stih416-resets.h>
/ {
@@ -140,5 +142,16 @@
clocks = <&CLK_S_ICN_REG_0>;
};
+ miphy365x_phy: miphy365x@0 {
+ compatible = "st,miphy365x-phy";
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+
+ #phy-cells = <2>;
+ st,syscfg = <&syscfg_rear>;
+ };
};
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/4] phy: miphy365x: Add MiPHY365x header file for DT x Driver defines
From: Lee Jones @ 2014-02-14 11:23 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: alexandre.torgue-qxv4g6HH51o, Lee Jones,
devicetree-u79uwXL29TY76Z2rM5mHXA, Srinivas Kandagatla
In-Reply-To: <1392377036-12816-1-git-send-email-lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This provides the shared header file which will be reference from both
the MiPHY365x driver and its associated Device Tree node(s).
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Srinivas Kandagatla <srinivas.kandagatla-qxv4g6HH51o@public.gmane.org>
Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
include/dt-bindings/phy/phy-miphy365x.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 include/dt-bindings/phy/phy-miphy365x.h
diff --git a/include/dt-bindings/phy/phy-miphy365x.h b/include/dt-bindings/phy/phy-miphy365x.h
new file mode 100644
index 0000000..8757c02
--- /dev/null
+++ b/include/dt-bindings/phy/phy-miphy365x.h
@@ -0,0 +1,25 @@
+/*
+ * This header provides constants for the phy framework
+ * based on the STMicroelectronics miphy365x.
+ */
+#ifndef _DT_BINDINGS_PHY_MIPHY
+#define _DT_BINDINGS_PHY_MIPHY
+
+/* Supports 16 ports without a datatype change (u8 & 0xF0). */
+#define MIPHY_PORT_0 0
+#define MIPHY_PORT_1 1
+#define MIPHY_PORT_2 2
+#define MIPHY_PORT_3 3
+
+/* Supports 16 types without a datatype change (u8 & 0x0F). */
+#define MIPHY_TYPE_SHIFT 4
+#define MIPHY_TYPE_SATA (0 << MIPHY_TYPE_SHIFT)
+#define MIPHY_TYPE_PCIE (1 << MIPHY_TYPE_SHIFT)
+#define MIPHY_TYPE_USB (2 << MIPHY_TYPE_SHIFT)
+
+#define MIPHY_SATA_PORT0 (MIPHY_TYPE_SATA) | (MIPHY_PORT_0)
+#define MIPHY_SATA_PORT1 (MIPHY_TYPE_SATA) | (MIPHY_PORT_1)
+#define MIPHY_PCIE_PORT0 (MIPHY_TYPE_PCIE) | (MIPHY_PORT_0)
+#define MIPHY_PCIE_PORT1 (MIPHY_TYPE_PCIE) | (MIPHY_PORT_1)
+
+#endif /* _DT_BINDINGS_PHY_MIPHY */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
From: Lee Jones @ 2014-02-14 11:23 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: alexandre.torgue-qxv4g6HH51o, Lee Jones,
devicetree-u79uwXL29TY76Z2rM5mHXA, Srinivas Kandagatla
The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
devices. It has 2 ports which it can use for either; both SATA, both
PCIe or one of each in any configuration.
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Srinivas Kandagatla <srinivas.kandagatla-qxv4g6HH51o@public.gmane.org>
Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/phy/phy-miphy365x.txt | 54 ++++++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
new file mode 100644
index 0000000..96f269f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,54 @@
+STMicroelectronics STi MIPHY365x PHY binding
+============================================
+
+This binding describes a miphy device that is used to control PHY hardware
+for SATA and PCIe.
+
+Required properties:
+- compatible: Should be "st,miphy365x-phy"
+- #phy-cells: Should be 2 (See second example)
+ First cell is the port number; MIPHY_PORT_{0,1}
+ Second cell is device type; MIPHY_TYPE_{SATA,PCI}
+- reg: Address and length of the register set for the device
+- reg-names: The names of the register addresses corresponding to the
+ registers filled in "reg"
+ Options are; sata{0,1} and pcie{0,1} (See first example)
+- st,syscfg : Should be a phandle of the system configuration register group
+ which contain the SATA, PCIe mode setting bits
+
+Optional properties:
+- st,sata-gen : Generation of locally attached SATA IP. Expected values
+ are {1,2,3). If not supplied generation 1 hardware will
+ be expected
+- st,pcie-tx-pol-inv : Bool property to invert the polarity PCIe Tx (Txn/Txp)
+- st,sata-tx-pol-inv : Bool property to invert the polarity SATA Tx (Txn/Txp)
+
+Example:
+
+ miphy365x_phy: miphy365x@0 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <2>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg= <&syscfg_rear>;
+ };
+
+Specifying phy control of devices
+=================================
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the miphy device node, a port number
+and a device type.
+
+Example:
+
+#include <dt-bindings/phy/phy-miphy365x.h>
+
+ sata0: sata@fe380000 {
+ ...
+ phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
+ ...
+ };
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH RESEND v2 00/12] clk/exynos convert clock IDs to macros
From: Sachin Kamat @ 2014-02-14 11:14 UTC (permalink / raw)
To: Tomasz Figa
Cc: Kukjin Kim, Mike Turquette, moderated list:OPEN FIRMWARE AND...,
Andrzej Hajda, Kyungmin Park, moderated list:ARM/S5P EXYNOS AR...,
linux-arm-kernel
In-Reply-To: <52FDF2C9.6060403@samsung.com>
Hi Tomasz,
On 14 February 2014 16:11, Tomasz Figa <t.figa@samsung.com> wrote:
> Hi Kukjin,
>
>
> On 14.02.2014 01:17, Kukjin Kim wrote:
>>
>> On 02/14/14 09:10, Kukjin Kim wrote:
>>>
>>> On 01/28/14 06:49, Mike Turquette wrote:
>>>>
>>>> Quoting Tomasz Figa (2014-01-07 07:17:22)
>>>>>
>>>>> Hi Mike,
>>>>>
>>>>> On Tuesday 07 of January 2014 15:47:28 Andrzej Hajda wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> This patch set adds header files with macros defining exynos clocks.
>>>>>> Then it converts dts files and drivers to use macros instead
>>>>>> of magic numbers or enums to describe clock bindings.
>>>>>>
>>>>>> The patch set is rebased on the latest samsung-clk/samsung-next
>>>>>> branch.
>>>>>>
>>>>>> The patches are generated by script.
>>>>>> Many clocks I have verified by hand.
>>>>>> I have also tested it successfully on exynos4 based board.
>>>>>>
>>>>>> This is the 2nd version of the patchset.
>>>>>> Changes:
>>>>>> - corrected devicetree mailing list,
>>>>>> - added comments to include/dt-bindings/clock/exynos4.h for
>>>>>> clocks present only in particular chip,
>>>>>> - added tab alignement in headers,
>>>>>> - added comment to CLK_NR_CLKS,
>>>>>> - added copyright headers,
>>>>>> - split long lines in dts,
>>>>>> - corrected example in bindings/clock/exynos5250-clock.txt, to point
>>>>>> appropriate clocks.
>>>>>
>>>>>
>>>>> I believe this has been already acked before, so could you still take
>>>>> it for 3.14? For now I'd merge only the patches adding headers and
>>>>> updating clock drivers to avoid merge conflicts and then after
>>>>> release of 3.14-rc1 we could early merge dts patches for 3.15.
>>>>
>>>>
>>>> Hi Tomasz,
>>>>
>>>> Let's go ahead and merge this after 3.14-rc1. I'll take it in when that
>>>> drops and the DTS data will go in during the same merge window.
>>>>
>>>
>>> Hi Mike,
>>>
>>> As I talked to Tomasz, would be better to us if this series could be
>>> handled in Samsung tree so I'm going to do it. How do you think?
>>>
>> Oops, already merged into mainline ;-)
>> Sorry, please kindly ignore my previous e-mail.
>
>
> As you probably found out already, we've merged clock-side part of the
> series for 3.14 to ease things a bit and let you simply merge the DT-side
> for 3.15.
>
> Also, since there were patches floating on the ML still using clock numbers,
> we decided to give them some more time to be applied, then stop accepting
> such patches and then finally rerun Andrzej's script on your tree and ask
> you to apply resulting conversion patches.
>
> Since you seem to have already applied most of such floating patches,
> Andrzej will send you new series soon.
There are still quite a few board support patches of Arndale-octa and 5420 SMDK
that need to be applied. I believe Kukjin will apply them over the weekend.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH v7 02/12] mfd: omap-usb-host: Get clocks based on hardware revision
From: Roger Quadros @ 2014-02-14 11:12 UTC (permalink / raw)
To: Lee Jones
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, bcousson-rdvid1DuHRBWk0Htik3J/w,
balbi-l0cyMroinI0, nm-l0cyMroinI0, khilman-QSEj5FYQhm4dnm+yROfE0A,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz
In-Reply-To: <20140214100701.GC7380@lee--X1>
On 02/14/2014 12:07 PM, Lee Jones wrote:
>> Not all revisions have all the clocks so get the necessary clocks
>> based on hardware revision.
>>
>> This should avoid un-necessary clk_get failure messages that were
>> observed earlier.
>>
>> Be more strict and always fail on clk_get() error.
>
> It might have been clearer if you'd broken these two pieces of
> functionality changes into two different patches. In future it would
> be preferred.
OK.
>
>> CC: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> CC: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>> ---
>> drivers/mfd/omap-usb-host.c | 92 +++++++++++++++++++++++++++++++--------------
>> 1 file changed, 64 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 0c3c9a0..60a3bed 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -665,22 +665,41 @@ static int usbhs_omap_probe(struct platform_device *pdev)
>> goto err_mem;
>> }
>>
>> - need_logic_fck = false;
>> + /* Set all clocks as invalid to begin with */
>> + omap->ehci_logic_fck = omap->init_60m_fclk = ERR_PTR(-ENODEV);
>> + omap->utmi_p1_gfclk = omap->utmi_p2_gfclk = ERR_PTR(-ENODEV);
>> + omap->xclk60mhsp1_ck = omap->xclk60mhsp2_ck = ERR_PTR(-ENODEV);
>> +
>
> For readability you should probably do these one per line.
OK.
>
>> for (i = 0; i < omap->nports; i++) {
>> - if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
>> - is_ehci_hsic_mode(i))
>> - need_logic_fck |= true;
>> + omap->utmi_clk[i] = ERR_PTR(-ENODEV);
>> + omap->hsic480m_clk[i] = ERR_PTR(-ENODEV);
>> + omap->hsic60m_clk[i] = ERR_PTR(-ENODEV);
>> }
>>
>> - omap->ehci_logic_fck = ERR_PTR(-EINVAL);
>> - if (need_logic_fck) {
>> - omap->ehci_logic_fck = devm_clk_get(dev, "ehci_logic_fck");
>
> Has this clock been renamed, or is it no longer required?
It is only for OMAP3 and it's actual name is "usbhost_120m_fck".
"ehci_logic_fck" is just an alias.
>
> Perhaps you should be explicit in the commit log as to which clocks
> you're removing.
>
>> - if (IS_ERR(omap->ehci_logic_fck)) {
>> - ret = PTR_ERR(omap->ehci_logic_fck);
>> - dev_dbg(dev, "ehci_logic_fck failed:%d\n", ret);
>> + /* for OMAP3 i.e. USBHS REV1 */
>> + if (omap->usbhs_rev == OMAP_USBHS_REV1) {
>> + need_logic_fck = false;
>> + for (i = 0; i < omap->nports; i++) {
>> + if (is_ehci_phy_mode(pdata->port_mode[i]) ||
>> + is_ehci_tll_mode(pdata->port_mode[i]) ||
>> + is_ehci_hsic_mode(pdata->port_mode[i]))
>> +
>> + need_logic_fck |= true;
>> + }
>> +
>> + if (need_logic_fck) {
>> + omap->ehci_logic_fck = clk_get(dev, "usbhost_120m_fck");
>
> devm_clk_get()?
Indeed.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RESEND v2 00/12] clk/exynos convert clock IDs to macros
From: Tomasz Figa @ 2014-02-14 10:41 UTC (permalink / raw)
To: Kukjin Kim
Cc: Mike Turquette, moderated list:OPEN FIRMWARE AND...,
Andrzej Hajda, Kyungmin Park, moderated list:ARM/S5P EXYNOS AR...,
linux-arm-kernel
In-Reply-To: <52FD60A8.8070402@samsung.com>
Hi Kukjin,
On 14.02.2014 01:17, Kukjin Kim wrote:
> On 02/14/14 09:10, Kukjin Kim wrote:
>> On 01/28/14 06:49, Mike Turquette wrote:
>>> Quoting Tomasz Figa (2014-01-07 07:17:22)
>>>> Hi Mike,
>>>>
>>>> On Tuesday 07 of January 2014 15:47:28 Andrzej Hajda wrote:
>>>>> Hi,
>>>>>
>>>>> This patch set adds header files with macros defining exynos clocks.
>>>>> Then it converts dts files and drivers to use macros instead
>>>>> of magic numbers or enums to describe clock bindings.
>>>>>
>>>>> The patch set is rebased on the latest samsung-clk/samsung-next
>>>>> branch.
>>>>>
>>>>> The patches are generated by script.
>>>>> Many clocks I have verified by hand.
>>>>> I have also tested it successfully on exynos4 based board.
>>>>>
>>>>> This is the 2nd version of the patchset.
>>>>> Changes:
>>>>> - corrected devicetree mailing list,
>>>>> - added comments to include/dt-bindings/clock/exynos4.h for
>>>>> clocks present only in particular chip,
>>>>> - added tab alignement in headers,
>>>>> - added comment to CLK_NR_CLKS,
>>>>> - added copyright headers,
>>>>> - split long lines in dts,
>>>>> - corrected example in bindings/clock/exynos5250-clock.txt, to point
>>>>> appropriate clocks.
>>>>
>>>> I believe this has been already acked before, so could you still take
>>>> it for 3.14? For now I'd merge only the patches adding headers and
>>>> updating clock drivers to avoid merge conflicts and then after
>>>> release of 3.14-rc1 we could early merge dts patches for 3.15.
>>>
>>> Hi Tomasz,
>>>
>>> Let's go ahead and merge this after 3.14-rc1. I'll take it in when that
>>> drops and the DTS data will go in during the same merge window.
>>>
>>
>> Hi Mike,
>>
>> As I talked to Tomasz, would be better to us if this series could be
>> handled in Samsung tree so I'm going to do it. How do you think?
>>
> Oops, already merged into mainline ;-)
> Sorry, please kindly ignore my previous e-mail.
As you probably found out already, we've merged clock-side part of the
series for 3.14 to ease things a bit and let you simply merge the
DT-side for 3.15.
Also, since there were patches floating on the ML still using clock
numbers, we decided to give them some more time to be applied, then stop
accepting such patches and then finally rerun Andrzej's script on your
tree and ask you to apply resulting conversion patches.
Since you seem to have already applied most of such floating patches,
Andrzej will send you new series soon.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH 2/2] ARM: bcm2835: fix clock DT node names
From: Mark Rutland @ 2014-02-14 10:39 UTC (permalink / raw)
To: Stephen Warren
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mike Turquette,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <1392358613-19962-2-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On Fri, Feb 14, 2014 at 06:16:53AM +0000, Stephen Warren wrote:
> DT nodes should be named according to the type of object that they
> represent rather than the identity. DT nodes that contain a reg
> property should include a unit address in their name. Fix these issues.
As mentioned on patch one, I don't think this makes sense. clock@N is
simply not correct, and if simple-bus weren't being abused it would be
far clearer that that is the case.
Please use clock_N rather than clock@N here, and get rid of the
meaningless reg values.
The simple-bus should either be removed or fixed up to meet the
requirements of the simple-bus binding (i.e. add a ranges property). I
would prefer the former.
Thanks,
Mark.
>
> Signed-off-by: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> ---
> This is the bcm2835 patch which depends on patch 1. I guess this could
> also go through the clk tree if that makes it easier, although there's
> always the small risk of conflicts if you do that.
>
> arch/arm/boot/dts/bcm2835.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
> index a2d4889..1cf1ae7 100644
> --- a/arch/arm/boot/dts/bcm2835.dtsi
> +++ b/arch/arm/boot/dts/bcm2835.dtsi
> @@ -155,21 +155,21 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> - clk_mmc: mmc {
> + clk_mmc: clock@0 {
> compatible = "fixed-clock";
> reg = <0>;
> #clock-cells = <0>;
> clock-frequency = <100000000>;
> };
>
> - clk_i2c: i2c {
> + clk_i2c: clock@1 {
> compatible = "fixed-clock";
> reg = <1>;
> #clock-cells = <0>;
> clock-frequency = <250000000>;
> };
>
> - clk_spi: spi {
> + clk_spi: clock@2 {
> compatible = "fixed-clock";
> reg = <2>;
> #clock-cells = <0>;
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 1/2] clk: fixed-rate: use full DT node name
From: Mark Rutland @ 2014-02-14 10:35 UTC (permalink / raw)
To: Stephen Warren
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mike Turquette,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <1392358613-19962-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On Fri, Feb 14, 2014 at 06:16:52AM +0000, Stephen Warren wrote:
> clk-fixed-rate currently names clocks according to a node's name without
> the unit address. When faced with the legal and technically correct DT
> structure below, this causes rgistration attempts for 3 clocks with the
> same name, 2 of which fail.
>
> clocks {
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <0>;
>
> clk_mmc: clock@0 {
> compatible = "fixed-clock";
> reg = <0>;
> ...
> clk_i2c: clock@1 {
> compatible = "fixed-clock";
> reg = <1>;
> ...
> clk_spi: clock@2 {
> compatible = "fixed-clock";
> reg = <2>;
> ...
I'd argue that this case isn't valid.
The fixed-clock binding doesn't define a reg, yet simple bus binding
implies that the reg property of child nodes should be interpretted as
the same address space as their parent (MMIO in this case?). The
fixed-clock nodes reg proeprties clearly aren't MMIO addresses.
Additionally, the _requred_ ranges property is missing.
It's just nonsensical; rename them to clock_{0,1,..} instead and get rid
of the reg properties. Then they're named uniquely.
However, for cases where the reg value is meaningful the below patch
makes sense.
Thanks,
Mark.
>
> Solve this by naming the clocks after the full node name rather than the
> short version (e.g. /clocks/clock@0).
>
> Signed-off-by: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> ---
> Note that if this is accepted, I intend to submit a patch for the RPi DTS
> which uses the naming structure above, so it might be useful to place this
> patch in its own branch. Or, I could submit the cleanup after 3.15-rc1.
> ---
> drivers/clk/clk-fixed-rate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
> index 0fc56ab..3335b3c 100644
> --- a/drivers/clk/clk-fixed-rate.c
> +++ b/drivers/clk/clk-fixed-rate.c
> @@ -115,7 +115,7 @@ EXPORT_SYMBOL_GPL(clk_register_fixed_rate);
> void of_fixed_clk_setup(struct device_node *node)
> {
> struct clk *clk;
> - const char *clk_name = node->name;
> + const char *clk_name = node->full_name;
> u32 rate;
> u32 accuracy = 0;
>
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v3 1/2] Documentation: Add GPIO reset binding to reset binding documentation
From: Philipp Zabel @ 2014-02-14 10:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Roger Quadros, Mark Rutland,
Maxime Ripard, Stephen Warren
In-Reply-To: <1391701458.5008.15.camel-/rZezPiN1rtR6QfukMTsflXZhhPuCNm+@public.gmane.org>
Am Donnerstag, den 06.02.2014, 16:44 +0100 schrieb Philipp Zabel:
> Hi Arnd,
>
> Am Freitag, den 10.01.2014, 12:25 +0100 schrieb Philipp Zabel:
> > Hi Arnd,
> >
> > Am Mittwoch, den 08.01.2014, 17:08 +0100 schrieb Arnd Bergmann:
> > > On Wednesday 08 January 2014, Philipp Zabel wrote:
> > > > += GPIO Reset consumers =
> > > > +
> > > > +For the common case of reset lines controlled by GPIOs, the GPIO binding
> > > > +documented in devicetree/bindings/gpio/gpio.txt should be used:
> > > > +
> > > > +Required properties:
> > > > +reset-gpios or Reset GPIO using standard GPIO bindings,
> > > > +<name>-reset-gpios: optionally named to specify the reset line
> > > > +
> > > > +Optional properties:
> > > > +reset-boot-asserted or Boolean. If set, the corresponding reset is
> > > > +<name>-reset-boot-asserted: initially asserted and should be kept that way
> > > > + until released by the driver.
> > >
> > > I don't get this one. Why would you use a different reset binding for the case
> > > where the reset line is connected to the gpio controller rather than a
> > > specialized reset controller?
> > >
> > > I was expecting to see the definition of a generic reset controller that
> > > in turn uses gpio lines, like
> > >
> > >
> > > reset {
> > > compatible = "gpio-reset";
> > > /* provides three reset lines through these GPIOs */
> > > gpios = <&gpioA 1 &gpioB 7 <gpioD 17>;
> > > #reset-cells = <1>;
> > > };
> > >
> > > foo {
> > > ...
> > > resets = <&reset 0>; /* uses first reset line of the gpio-reset controller */
> > > };
> >
> > That is what I initially proposed...
> >
> > > I realize it would be a little more verbose, but it also seems more
> > > regular and wouldn't stand out from the rest of the reset interfaces.
> >
> > ... but it can also be argued that GPIO resets shouldn't stand out from
> > other GPIOs.
> >
> > Mark Rutland spoke out against having a 'GPIO reset device' node in the
> > device tree:
> >
> > http://comments.gmane.org/gmane.linux.drivers.devicetree/41596
> >
> > and I see his point. Using different bindings for reset controller IPs
> > and for single GPIOs better describes the actual hardware and it is less
> > Linux specific: it still allows an OS without gpio-reset framework to
> > let each driver handle the GPIO itself.
> >
> > Also Stephen Warren pointed out that we'll have to support the existing
> > GPIO bindings anyway: in the meantime there are a lot of GPIO resets in
> > various device trees that use the GPIO bindings.
> >
> > regards
> > Philipp
>
> do you have further comments on this?
Yes? No? Maybe later?
> I'd like to request a pull of the changes in
> http://git.pengutronix.de/?p=pza/linux.git;a=shortlog;h=refs/heads/reset/for_v3.15
> and I wonder whether I should submit that now without the GPIO patches
> or hold it back a bit and add them on top.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v5 09/10] Documentation: add Device tree bindings for Broadcom GENET
From: Mark Rutland @ 2014-02-14 10:19 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, davem@davemloft.net,
devicetree@vger.kernel.org, cernekee@gmail.com,
romieu@fr.zoreil.com
In-Reply-To: <1392336531-28875-10-git-send-email-f.fainelli@gmail.com>
On Fri, Feb 14, 2014 at 12:08:50AM +0000, Florian Fainelli wrote:
> This patch adds the Device Tree bindings for the Broadcom GENET Gigabit
> Ethernet controller. A bunch of examples are provided to illustrate the
> versatile aspect of the hardare.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Changes in v5:
> - respin due to the CONFIG_OF dependency fix
>
> Changes in v4:
> - respin due to the Kconfig dependency
>
> Changes in v3
> - improve compatible property description to specify all compatible strings
> supported
> - move MDIO bus node to a separate section, to separate from the properties
> - detail which exact phy-mode strings are supported and that this refers to
> the ePAPR 'phy-connection-type' modes
> - fixed MDIO bus node compatible string to match what is really provided by
> the bootloader and use the same details as for the GENET compatible string
> - add address-cells and size-cells required properties for the GENET device
> tree node
> - add a better description for the 'fixed-link' property with reference to
> existing binding documentation
> - add a reference to the Ethernet PHY device tree binding
> - add a description for the interrupts properties
> - add a documentation for the optional clocks properties
> - removed unused and deprecated device_type properties
>
> Changes in v2:
> - rebased against net-next/master
>
> .../devicetree/bindings/net/broadcom-bcmgenet.txt | 121 +++++++++++++++++++++
> 1 file changed, 121 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
>
> diff --git a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
> new file mode 100644
> index 0000000..afd31f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
> @@ -0,0 +1,121 @@
> +* Broadcom BCM7xxx Ethernet Controller (GENET)
> +
> +Required properties:
> +- compatible: should contain one of "brcm,genet-v1", "brcm,genet-v2",
> + "brcm,genet-v3", "brcm,genet-v4".
> +- reg: address and length of the register set for the device
> +- interrupts: must be two cells, the first cell is the general purpose
> + interrupt line, while the second cell is the interrupt for the ring
> + RX and TX queues operating in ring mode
> +- phy-mode: String, operation mode of the PHY interface. Supported values are
> + "mii", "rgmii", "rgmii-txid", "rev-mii", "moca". Analogous to ePAPR
> + "phy-connection-type" values
> +- address-cells: should be 1
> +- size-cells: should be 1
> +
> +Optional properties:
> +- clocks: When provided, must be two cells, first one is the main GENET clock
> + and the second cell is the Genet Wake-on-LAN clock.
Clocks aren't just cells. They are referred to with phandle +
clock-specificer pairs.
This doesn't document the names that the driver requests the clocks by.
Just listing the clocks isn't sufficient, as any dts will have to add a
clock-names property to get those clocks probed.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH 00/10] Support TI Light Management Unit devices
From: Lee Jones @ 2014-02-14 10:14 UTC (permalink / raw)
To: Milo Kim
Cc: Jingoo Han, Bryan Wu, Mark Brown, linux-kernel, devicetree,
Samuel Ortiz
In-Reply-To: <1392359410-6852-1-git-send-email-milo.kim@ti.com>
> Milo Kim (10):
> mfd: Add TI LMU driver
> backlight: Add TI LMU backlight common driver
> backlight: ti-lmu-backlight: Add LM3532 driver
> backlight: ti-lmu-backlight: Add LM3631 driver
> backlight: ti-lmu-backlight: Add LM3633 driver
> backlight: ti-lmu-backlight: Add LM3695 driver
> backlight: ti-lmu-backlight: Add LM3697 driver
> leds: Add LM3633 driver
> regulator: Add LM3631 driver
> Documentation: Add device tree bindings for TI LMU devices
It makes it much easier to track if you send your patch set (shallow)
threaded i.e. all patches attached to [PATCH 0/x]. Having all of the
patches sent individually they will get split up and spread out all
over the reviewers INBOX, which becomes unwieldy very quickly.
Please see git send-email options:
`--[no-]thread` and `--[no-]chain-reply-to`
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 02/10] backlight: Add TI LMU backlight common driver
From: Mark Rutland @ 2014-02-14 10:13 UTC (permalink / raw)
To: Milo Kim
Cc: Lee Jones, Jingoo Han, Bryan Wu, Mark Brown,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Samuel Ortiz
In-Reply-To: <1392359468-6925-1-git-send-email-milo.kim-l0cyMroinI0@public.gmane.org>
On Fri, Feb 14, 2014 at 06:31:08AM +0000, Milo Kim wrote:
> TI LMU backlight driver provides common driver features.
> Chip specific configuration is handled by each backlight driver such like
> LM3532, LM3631, LM3633, LM3695 and LM3697.
>
> It supports common features as below.
> - Consistent device control flow
> - Control bank assignment from the platform data
> - Backlight subsystem control
> - PWM brightness control
> - Shared device tree node
>
> Cc: Jingoo Han <jg1.han-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Cc: Bryan Wu <cooloney-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Milo Kim <milo.kim-l0cyMroinI0@public.gmane.org>
> ---
> drivers/video/backlight/Kconfig | 7 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/ti-lmu-backlight.c | 369 ++++++++++++++++++++++++++++
> drivers/video/backlight/ti-lmu-backlight.h | 78 ++++++
> 4 files changed, 455 insertions(+)
> create mode 100644 drivers/video/backlight/ti-lmu-backlight.c
> create mode 100644 drivers/video/backlight/ti-lmu-backlight.h
[...]
> +static int ti_lmu_backlight_parse_dt(struct device *dev, struct ti_lmu *lmu)
> +{
> + struct ti_lmu_backlight_platform_data *pdata;
> + struct device_node *node = dev->of_node;
> + struct device_node *child;
> + int num_backlights;
> + int i = 0;
> + u8 imax_mA;
> +
> + if (!node) {
> + dev_err(dev, "No device node exists\n");
> + return -ENODEV;
> + }
> +
> + num_backlights = of_get_child_count(node);
> + if (num_backlights == 0) {
> + dev_err(dev, "No backlight strings\n");
> + return -EINVAL;
> + }
> +
> + pdata = devm_kzalloc(dev, sizeof(*pdata) * num_backlights, GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + for_each_child_of_node(node, child) {
> + of_property_read_string(child, "bl-name", &pdata[i].name);
> +
> + /* Make backlight strings */
> + pdata[i].bl_string = 0;
> + if (of_find_property(child, "hvled1-used", NULL))
> + pdata[i].bl_string |= LMU_HVLED1;
> + if (of_find_property(child, "hvled2-used", NULL))
> + pdata[i].bl_string |= LMU_HVLED2;
> + if (of_find_property(child, "hvled3-used", NULL))
> + pdata[i].bl_string |= LMU_HVLED3;
Use of_property_read_bool here.
> +
> + of_property_read_u8(child, "max-current-milliamp", &imax_mA);
> + pdata[i].imax = ti_lmu_get_current_code(imax_mA);
If this is missing from a node, imax_mA will have the value from the
last iteration (or an uninitialised value).
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox