* [PATCH 5/8] onkey: da9055: Remove use of platform_get_irq_byname()
From: Adam Thomson @ 2014-02-05 17:48 UTC (permalink / raw)
To: Mark Brown, Lee Jones
Cc: devicetree, alsa-devel, Alessandro Zummo, Linus Walleij,
Dmitry Torokhov, linux-kernel, Guenter Roeck, Rob Herring
In-Reply-To: <cover.1391614923.git.Adam.Thomson.Opensource@diasemi.com>
Using platform_get_irq_byname() to retrieve the IRQ number
returns the VIRQ number rather than the local IRQ number for
the device. Passing that value then into regmap_irq_get_virq()
causes a failure because the function is expecting the local
IRQ number (e.g. 0, 1, 2, 3, etc). This patch removes use of
platform_get_irq_byname() and uses the local IRQ number instead.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
---
drivers/input/misc/da9055_onkey.c | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/drivers/input/misc/da9055_onkey.c b/drivers/input/misc/da9055_onkey.c
index 4b11ede..4842c6c 100644
--- a/drivers/input/misc/da9055_onkey.c
+++ b/drivers/input/misc/da9055_onkey.c
@@ -79,13 +79,6 @@ static int da9055_onkey_probe(struct platform_device *pdev)
struct input_dev *input_dev;
int irq, err;
- irq = platform_get_irq_byname(pdev, "ONKEY");
- if (irq < 0) {
- dev_err(&pdev->dev,
- "Failed to get an IRQ for input device, %d\n", irq);
- return -EINVAL;
- }
-
onkey = devm_kzalloc(&pdev->dev, sizeof(*onkey), GFP_KERNEL);
if (!onkey) {
dev_err(&pdev->dev, "Failed to allocate memory\n");
@@ -109,7 +102,7 @@ static int da9055_onkey_probe(struct platform_device *pdev)
INIT_DELAYED_WORK(&onkey->work, da9055_onkey_work);
- irq = regmap_irq_get_virq(da9055->irq_data, irq);
+ irq = regmap_irq_get_virq(da9055->irq_data, DA9055_IRQ_NONKEY);
err = request_threaded_irq(irq, NULL, da9055_onkey_irq,
IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
"ONKEY", onkey);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 6/8] hwmon: da9055: Remove use of platform_get_irq_byname()
From: Adam Thomson @ 2014-02-05 17:48 UTC (permalink / raw)
To: Mark Brown, Lee Jones
Cc: devicetree, alsa-devel, Alessandro Zummo, Linus Walleij,
Dmitry Torokhov, linux-kernel, Rob Herring, Guenter Roeck
In-Reply-To: <cover.1391614923.git.Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
---
drivers/hwmon/da9055-hwmon.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/hwmon/da9055-hwmon.c b/drivers/hwmon/da9055-hwmon.c
index 029ecab..1867682 100644
--- a/drivers/hwmon/da9055-hwmon.c
+++ b/drivers/hwmon/da9055-hwmon.c
@@ -274,11 +274,8 @@ static int da9055_hwmon_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, hwmon);
- hwmon_irq = platform_get_irq_byname(pdev, "HWMON");
- if (hwmon_irq < 0)
- return hwmon_irq;
-
- hwmon_irq = regmap_irq_get_virq(hwmon->da9055->irq_data, hwmon_irq);
+ hwmon_irq = regmap_irq_get_virq(hwmon->da9055->irq_data,
+ DA9055_IRQ_HWMON);
if (hwmon_irq < 0)
return hwmon_irq;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 4/8] regulator: da9055: Add DT support
From: Adam Thomson @ 2014-02-05 17:48 UTC (permalink / raw)
To: Mark Brown, Lee Jones
Cc: devicetree, alsa-devel, Alessandro Zummo, Linus Walleij,
Dmitry Torokhov, linux-kernel, Rob Herring, Guenter Roeck
In-Reply-To: <cover.1391614923.git.Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
---
drivers/regulator/da9055-regulator.c | 59 +++++++++++++++++++++++++++++++---
1 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/da9055-regulator.c b/drivers/regulator/da9055-regulator.c
index 7f34020..bc41137 100644
--- a/drivers/regulator/da9055-regulator.c
+++ b/drivers/regulator/da9055-regulator.c
@@ -19,6 +19,10 @@
#include <linux/platform_device.h>
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
+#ifdef CONFIG_OF
+#include <linux/of.h>
+#include <linux/regulator/of_regulator.h>
+#endif /* CONFIG_OF */
#include <linux/mfd/da9055/core.h>
#include <linux/mfd/da9055/reg.h>
@@ -446,6 +450,9 @@ static int da9055_gpio_init(struct da9055_regulator *regulator,
struct da9055_regulator_info *info = regulator->info;
int ret = 0;
+ if (!pdata)
+ return 0;
+
if (pdata->gpio_ren && pdata->gpio_ren[id]) {
char name[18];
int gpio_mux = pdata->gpio_ren[id];
@@ -530,6 +537,46 @@ static inline struct da9055_regulator_info *find_regulator_info(int id)
return NULL;
}
+#ifdef CONFIG_OF
+static int da9055_regulator_dt_init(struct platform_device *pdev,
+ struct da9055_regulator *regulator,
+ struct regulator_config *config)
+{
+ struct device_node *nproot, *np;
+
+ nproot = of_node_get(pdev->dev.parent->of_node);
+ if (!nproot)
+ return -ENODEV;
+
+ nproot = of_find_node_by_name(nproot, "regulators");
+ if (!nproot)
+ return -ENODEV;
+
+ for_each_child_of_node(nproot, np) {
+ if (!of_node_cmp(np->name,
+ regulator->info->reg_desc.name)) {
+ config->init_data = of_get_regulator_init_data(
+ &pdev->dev, np);
+ config->of_node = np;
+ break;
+ }
+ }
+ of_node_put(nproot);
+
+ if (!config->of_node)
+ return -ENODEV;
+
+ return 0;
+}
+#else
+static inline da9055_regulator_dt_init(struct platform_device *pdev,
+ struct da9055_regulator *regulator,
+ struct regulator_config *config)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_OF */
+
static int da9055_regulator_probe(struct platform_device *pdev)
{
struct regulator_config config = { };
@@ -538,9 +585,6 @@ static int da9055_regulator_probe(struct platform_device *pdev)
struct da9055_pdata *pdata = dev_get_platdata(da9055->dev);
int ret, irq;
- if (pdata == NULL || pdata->regulators[pdev->id] == NULL)
- return -ENODEV;
-
regulator = devm_kzalloc(&pdev->dev, sizeof(struct da9055_regulator),
GFP_KERNEL);
if (!regulator)
@@ -559,6 +603,11 @@ static int da9055_regulator_probe(struct platform_device *pdev)
if (pdata && pdata->regulators)
config.init_data = pdata->regulators[pdev->id];
+ else {
+ ret = da9055_regulator_dt_init(pdev, regulator, &config);
+ if (ret < 0)
+ return ret;
+ }
ret = da9055_gpio_init(regulator, &config, pdata, pdev->id);
if (ret < 0)
@@ -575,8 +624,8 @@ static int da9055_regulator_probe(struct platform_device *pdev)
/* Only LDO 5 and 6 has got the over current interrupt */
if (pdev->id == DA9055_ID_LDO5 || pdev->id == DA9055_ID_LDO6) {
- irq = platform_get_irq_byname(pdev, "REGULATOR");
- irq = regmap_irq_get_virq(da9055->irq_data, irq);
+ irq = regmap_irq_get_virq(da9055->irq_data,
+ DA9055_IRQ_REGULATOR);
ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
da9055_ldo5_6_oc_irq,
IRQF_TRIGGER_HIGH |
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/8] mfd: da9055: Add DT support for PMIC
From: Adam Thomson @ 2014-02-05 17:48 UTC (permalink / raw)
To: Mark Brown, Lee Jones
Cc: devicetree, alsa-devel, Alessandro Zummo, Linus Walleij,
Dmitry Torokhov, linux-kernel, Rob Herring, Guenter Roeck
In-Reply-To: <cover.1391614923.git.Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
---
Documentation/devicetree/bindings/mfd/da9055.txt | 73 ++++++++++++++++++++++
drivers/mfd/da9055-i2c.c | 8 +++
2 files changed, 81 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/da9055.txt
diff --git a/Documentation/devicetree/bindings/mfd/da9055.txt b/Documentation/devicetree/bindings/mfd/da9055.txt
new file mode 100644
index 0000000..f903c3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/da9055.txt
@@ -0,0 +1,73 @@
+* Dialog DA9055 Power Management Integrated Circuit (PMIC)
+
+DA9055 consists of a large and varied group of sub-devices (I2C Only):
+
+Device Supply Names Description
+------ ------------ -----------
+da9055-gpio : : GPIOs
+da9055-regulator : : Regulators
+da9055-onkey : : On key
+da9055-rtc : : RTC
+da9055-hwmon : : ADC
+da9055-watchdog : : Watchdog
+
+The CODEC device in DA9055 has a separate, configurable I2C address and so
+is instantiated separately from the PMIC.
+
+For details on accompanying CODEC I2C device, see the following:
+Documentation/devicetree/bindings/sound/da9055.txt
+
+======
+
+Required properties:
+- compatible : Should be "dlg,da9055-pmic"
+- reg: Specifies the I2C slave address (defaults to 0x5a but can be modified)
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+ the IRQs from da9055 are delivered to.
+- interrupts: IRQ line info for da9055 chip.
+- interrupt-controller: da9055 has internal IRQs (has own IRQ domain).
+- #interrupt-cells: Should be 1, is the local IRQ number for da9055.
+
+Sub-nodes:
+- regulators : Contain the regulator nodes. The DA9055 regulators are
+ bound using their names as listed below:
+
+ buck1 : regulator BUCK1
+ buck2 : regulator BUCK2
+ ldo1 : regulator LDO1
+ ldo2 : regulator LDO2
+ ldo3 : regulator LDO3
+ ldo4 : regulator LDO4
+ ldo5 : regulator LDO5
+ ldo6 : regulator LDO6
+
+ The bindings details of individual regulator device can be found in:
+ Documentation/devicetree/bindings/regulator/regulator.txt
+
+
+Example:
+
+ pmic: da9055-pmic@5a {
+ compatible = "dlg,da9055-pmic";
+ reg = <0x5a>;
+ interrupt-parent = <&intc>;
+ interrupts = <5 0x8>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <2075000>;
+ };
+
+ buck2: BUCK2 {
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <2500000>;
+ };
+ ldo1: LDO1 {
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+ };
diff --git a/drivers/mfd/da9055-i2c.c b/drivers/mfd/da9055-i2c.c
index 8103e43..366a3e2 100644
--- a/drivers/mfd/da9055-i2c.c
+++ b/drivers/mfd/da9055-i2c.c
@@ -15,6 +15,8 @@
#include <linux/device.h>
#include <linux/i2c.h>
#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/mfd/da9055/core.h>
@@ -66,6 +68,11 @@ static struct i2c_device_id da9055_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, da9055_i2c_id);
+static const struct of_device_id da9055_of_match[] = {
+ { .compatible = "dlg,da9055-pmic", .data = (void *)&da9055_i2c_id[0] },
+ { }
+};
+
static struct i2c_driver da9055_i2c_driver = {
.probe = da9055_i2c_probe,
.remove = da9055_i2c_remove,
@@ -73,6 +80,7 @@ static struct i2c_driver da9055_i2c_driver = {
.driver = {
.name = "da9055-pmic",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(da9055_of_match),
},
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/8] ASoC: da9055: Add DT support for CODEC
From: Adam Thomson @ 2014-02-05 17:48 UTC (permalink / raw)
To: Mark Brown, Lee Jones
Cc: devicetree, alsa-devel, Alessandro Zummo, Linus Walleij,
Dmitry Torokhov, linux-kernel, Guenter Roeck, Rob Herring
In-Reply-To: <cover.1391614923.git.Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
---
Documentation/devicetree/bindings/sound/da9055.txt | 22 ++++++++++++++++++++
sound/soc/codecs/da9055.c | 8 +++++++
2 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/da9055.txt
diff --git a/Documentation/devicetree/bindings/sound/da9055.txt b/Documentation/devicetree/bindings/sound/da9055.txt
new file mode 100644
index 0000000..ed1b7cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/da9055.txt
@@ -0,0 +1,22 @@
+* Dialog DA9055 Audio CODEC
+
+DA9055 provides Audio CODEC support (I2C only).
+
+The Audio CODEC device in DA9055 has it's own I2C address which is configurable,
+so the device is instantiated separately from the PMIC (MFD) device.
+
+For details on accompanying PMIC I2C device, see the following:
+Documentation/devicetree/bindings/mfd/da9055.txt
+
+Required properties:
+
+ - compatible: "dlg,da9055-codec"
+ - reg: Specifies the I2C slave address
+
+
+Example:
+
+ codec: da9055-codec@1a {
+ compatible = "dlg,da9055-codec";
+ reg = <0x1a>;
+ };
diff --git a/sound/soc/codecs/da9055.c b/sound/soc/codecs/da9055.c
index 4228126..be31f3c 100644
--- a/sound/soc/codecs/da9055.c
+++ b/sound/soc/codecs/da9055.c
@@ -18,6 +18,8 @@
#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include <sound/pcm.h>
#include <sound/pcm_params.h>
#include <sound/soc.h>
@@ -1536,11 +1538,17 @@ static const struct i2c_device_id da9055_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, da9055_i2c_id);
+static const struct of_device_id da9055_of_match[] = {
+ { .compatible = "dlg,da9055-codec", },
+ { }
+};
+
/* I2C codec control layer */
static struct i2c_driver da9055_i2c_driver = {
.driver = {
.name = "da9055-codec",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(da9055_of_match),
},
.probe = da9055_i2c_probe,
.remove = da9055_remove,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/8] ASoC: da9055: Fix device registration of PMIC and CODEC devices
From: Adam Thomson @ 2014-02-05 17:48 UTC (permalink / raw)
To: Mark Brown, Lee Jones
Cc: devicetree, alsa-devel, Alessandro Zummo, Linus Walleij,
Dmitry Torokhov, linux-kernel, Rob Herring, Guenter Roeck
In-Reply-To: <cover.1391614923.git.Adam.Thomson.Opensource@diasemi.com>
Currently the I2C device Ids conflict for the MFD and CODEC so
cannot be both instantiated on one platform. This patch updates
the Ids and names to make them unique from each other.
It should be noted that the I2C addresses for both PMIC and CODEC
are modifiable so instantiation of the two are kept as separate
devices, rather than instantiating the CODEC from the MFD code.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
---
drivers/mfd/da9055-i2c.c | 12 ++++++++++--
sound/soc/codecs/da9055.c | 11 +++++++++--
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/da9055-i2c.c b/drivers/mfd/da9055-i2c.c
index 13af7e5..8103e43 100644
--- a/drivers/mfd/da9055-i2c.c
+++ b/drivers/mfd/da9055-i2c.c
@@ -53,17 +53,25 @@ static int da9055_i2c_remove(struct i2c_client *i2c)
return 0;
}
+/*
+ * DO NOT change the device Ids. The naming is intentionally specific as both
+ * the PMIC and CODEC parts of this chip are instantiated separately as I2C
+ * devices (both have configurable I2C addresses, and are to all intents and
+ * purposes separate). As a result there are specific DA9055 ids for PMIC
+ * and CODEC, which must be different to operate together.
+ */
static struct i2c_device_id da9055_i2c_id[] = {
- {"da9055", 0},
+ {"da9055-pmic", 0},
{ }
};
+MODULE_DEVICE_TABLE(i2c, da9055_i2c_id);
static struct i2c_driver da9055_i2c_driver = {
.probe = da9055_i2c_probe,
.remove = da9055_i2c_remove,
.id_table = da9055_i2c_id,
.driver = {
- .name = "da9055",
+ .name = "da9055-pmic",
.owner = THIS_MODULE,
},
};
diff --git a/sound/soc/codecs/da9055.c b/sound/soc/codecs/da9055.c
index 52b79a4..4228126 100644
--- a/sound/soc/codecs/da9055.c
+++ b/sound/soc/codecs/da9055.c
@@ -1523,8 +1523,15 @@ static int da9055_remove(struct i2c_client *client)
return 0;
}
+/*
+ * DO NOT change the device Ids. The naming is intentionally specific as both
+ * the CODEC and PMIC parts of this chip are instantiated separately as I2C
+ * devices (both have configurable I2C addresses, and are to all intents and
+ * purposes separate). As a result there are specific DA9055 Ids for CODEC
+ * and PMIC, which must be different to operate together.
+ */
static const struct i2c_device_id da9055_i2c_id[] = {
- { "da9055", 0 },
+ { "da9055-codec", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, da9055_i2c_id);
@@ -1532,7 +1539,7 @@ MODULE_DEVICE_TABLE(i2c, da9055_i2c_id);
/* I2C codec control layer */
static struct i2c_driver da9055_i2c_driver = {
.driver = {
- .name = "da9055",
+ .name = "da9055-codec",
.owner = THIS_MODULE,
},
.probe = da9055_i2c_probe,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/8] da9055: Driver initialisation fixes, add DT support
From: Adam Thomson @ 2014-02-05 17:48 UTC (permalink / raw)
To: Mark Brown, Lee Jones
Cc: devicetree, alsa-devel, Alessandro Zummo, Linus Walleij,
Dmitry Torokhov, linux-kernel, Rob Herring, Guenter Roeck
This patch series provides the following updates for DA9055 drivers:
- Fixes an issue with da9055 driver initialisation (conflicting device ids) of
PMIC (MFD) and CODEC drivers.
- Add initial DT support for DA9055 related drivers, including binding
documentation.
- Remove conflicting use of platform_get_irq_byname() in driver probes.
- Remove unnecessary resource structures for MFD cells as a result of removing
use of platform_get_irq_byname().
Adam Thomson (8):
ASoC: da9055: Fix device registration of PMIC and CODEC devices
ASoC: da9055: Add DT support for CODEC
mfd: da9055: Add DT support for PMIC
regulator: da9055: Add DT support
onkey: da9055: Remove use of platform_get_irq_byname()
hwmon: da9055: Remove use of platform_get_irq_byname()
rtc: da9055: Remove use of platform_get_irq_byname()
mfd: da9055: Remove unused resource structures for mfd cells.
Documentation/devicetree/bindings/mfd/da9055.txt | 73 ++++++++++++++++++++
Documentation/devicetree/bindings/sound/da9055.txt | 22 ++++++
drivers/hwmon/da9055-hwmon.c | 7 +--
drivers/input/misc/da9055_onkey.c | 9 +--
drivers/mfd/da9055-core.c | 46 ------------
drivers/mfd/da9055-i2c.c | 20 +++++-
drivers/regulator/da9055-regulator.c | 59 ++++++++++++++--
drivers/rtc/rtc-da9055.c | 3 +-
sound/soc/codecs/da9055.c | 19 +++++-
9 files changed, 188 insertions(+), 70 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/da9055.txt
create mode 100644 Documentation/devicetree/bindings/sound/da9055.txt
^ permalink raw reply
* Re: [PATCH v5 2/3] clocksource: keystone: add bindings for keystone timer
From: Rob Herring @ 2014-02-05 17:41 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: Santosh Shilimkar, Rob Landley, Russell King - ARM Linux,
Kumar Gala, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Daniel Lezcano, Thomas Gleixner, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Grygorii Strashko
In-Reply-To: <52F26444.5090707@ti.com>
On Wed, Feb 5, 2014 at 10:18 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote:
>
> On 02/05/2014 04:39 PM, Rob Herring wrote:
>>
>> On Wed, Feb 5, 2014 at 7:47 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
>> wrote:
>>>
>>> This patch provides bindings for the 64-bit timer in the KeyStone
>>> architecture devices. The timer can be configured as a general-purpose
>>> 64-bit
>>> timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
>>> timers, each half can operate in conjunction (chain mode) or
>>> independently
>>> (unchained mode) of each other.
>>
>> This is software configurable or h/w design time configurations?
>>
>> Rob
>>
>
> This is h/w design time configurations
Then it seems like the binding should provide for describing those
differences either with a property or different compatible strings.
Rob
^ permalink raw reply
* Re: [PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy framework
From: Olof Johansson @ 2014-02-05 17:30 UTC (permalink / raw)
To: Kamil Debski
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kyungmin Park,
Kishon Vijay Abraham I, Tomasz Figa, Sylwester Nawrocki,
Marek Szyprowski, Vivek Gautam, Mateusz Krawczuk,
yulgon.kim-Sze3O3UU22JBDgjK7y7TUQ, Praveen Paneri,
av.tikhomirov-Sze3O3UU22JBDgjK7y7TUQ, Jingoo Han, Kumar Gala,
Matt Porter, tjakobi-o02PS0xoJP9W0yFyLvAVXMxlOr/tl8fh, Alan Stern
In-Reply-To: <054501cf228a$f45c61c0$dd152540$%debski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Wed, Feb 5, 2014 at 7:57 AM, Kamil Debski <k.debski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi Olof,
>
> Thank you for your review.
>
>> From: Olof Johansson [mailto:olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org]
>> Sent: Wednesday, January 29, 2014 9:55 PM
>>
>> Hi,
>>
>> On Wed, Jan 29, 2014 at 9:29 AM, Kamil Debski <k.debski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> wrote:
>> > Change the phy provider used from the old one using the USB phy
>> > framework to a new one using the Generic phy framework.
>> >
>> > Signed-off-by: Kamil Debski <k.debski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> > ---
>> > .../devicetree/bindings/usb/exynos-usb.txt | 13 +++
>> > drivers/usb/host/ehci-exynos.c | 97
>> +++++++++++++-------
>> > 2 files changed, 76 insertions(+), 34 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> > b/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> > index d967ba1..25e199a 100644
>> > --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> > +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> > @@ -12,6 +12,10 @@ Required properties:
>> > - interrupts: interrupt number to the cpu.
>> > - clocks: from common clock binding: handle to usb clock.
>> > - clock-names: from common clock binding: Shall be "usbhost".
>> > + - port: if in the SoC there are EHCI phys, they should be listed
>> here.
>> > +One phy per port. Each port should have its reg entry with a
>> > +consecutive number. Also it should contain phys and phy-names
>> entries
>> > +specifying the phy used by the port.
>> >
>> > Optional properties:
>> > - samsung,vbus-gpio: if present, specifies the GPIO that @@ -27,6
>> > +31,15 @@ Example:
>> >
>> > clocks = <&clock 285>;
>> > clock-names = "usbhost";
>> > +
>> > + #address-cells = <1>;
>> > + #size-cells = <0>;
>> > + port@0 {
>> > + reg = <0>;
>> > + phys = <&usb2phy 1>;
>> > + phy-names = "host";
>> > + status = "disabled";
>> > + };
>> > };
>> >
>> > OHCI
>>
>> [...]
>>
>> > @@ -102,14 +132,26 @@ static int exynos_ehci_probe(struct
>> platform_device *pdev)
>> > "samsung,exynos5440-ehci"))
>> > goto skip_phy;
>> >
>> > - phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
>> > - if (IS_ERR(phy)) {
>> > - usb_put_hcd(hcd);
>> > - dev_warn(&pdev->dev, "no platform data or transceiver
>> defined\n");
>> > - return -EPROBE_DEFER;
>> > - } else {
>> > - exynos_ehci->phy = phy;
>> > - exynos_ehci->otg = phy->otg;
>> > + for_each_available_child_of_node(pdev->dev.of_node, child) {
>> > + err = of_property_read_u32(child, "reg",
>> &phy_number);
>> > + if (err) {
>> > + dev_err(&pdev->dev, "Failed to parse device
>> tree\n");
>> > + of_node_put(child);
>> > + return err;
>> > + }
>> > + if (phy_number >= PHY_NUMBER) {
>> > + dev_err(&pdev->dev, "Failed to parse device
>> tree - number out of range\n");
>> > + of_node_put(child);
>> > + return -EINVAL;
>> > + }
>> > + phy = devm_of_phy_get(&pdev->dev, child, 0);
>> > + of_node_put(child);
>> > + if (IS_ERR(phy)) {
>> > + dev_err(&pdev->dev, "Failed to get phy number
>> %d",
>> > +
>> phy_number);
>> > + return PTR_ERR(phy);
>> > + }
>> > + exynos_ehci->phy[phy_number] = phy;
>>
>> this looks like it is now breaking older device trees, where ports
>> might not be described. Since device tree interfaces need to be
>> backwards compatible, you still need to handle the old case of not
>> having ports described.
>>
>> There are two ways of doing this:
>>
>> 1. Fall back to the old behavior if there are no ports 2. Use a new
>> compatible value for the new model with port subnodes, and if the old
>> compatible value is used, then fall back to the old behavior.
>>
>> I'm guessing (1) might be easiest since you can check for the presence
>> of #address-cells to tell if this is just an old style node, or if it's
>> a new-style node without any ports below it.
>
> The ultimate goal is to remove the old phy driver. Unfortunately
> this has to be synced with the new USB3 phy driver by Vivek Gautam. I think
> he
> is also close to completion. What about this case? In the end the old driver
> will be removed and no longer be supported. Having backward compatibility in
> mind, it is possible to have the old and the new phy driver together in one
> kernel release. But do we want to have two drivers doing the same thing at
> the same time?
It is mostly irrelevant if there is a new driver or not -- the old
device tree has to keep working. In this case it would mean that the
new driver needs to work with older device trees as well, or people
will see functionality regressing.
The device tree is a description of the hardware, not an extension of
the driver.
-Olof
--
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 0/7] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs
From: David Lanzendörfer @ 2014-02-05 17:17 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson, Laurent Pinchart,
Simon Baatz, Hans de Goede, Emilio López,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Chris Ball,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, H Hartley Sweeten,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Tejun Heo, Maxime Ripard,
Guennadi Liakhovetski
In-Reply-To: <20140205134741.3027.50207.stgit-GPtPHOohwllnsqa/0SyWJQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
As Maxime has pointed out, I've forgotten to add a changelog
in my coverletter.
Here is, what has changed in this revision:
Changes since v1:
-Using mmc_of_parse instead of diy dt parsing
-Adding nodes for all mmc controller to the dtsi files, including sofar unused
controllers
-Using generic GPIO slot library
-Adding additional MMC device nodes into DTSI files
Changes since v2:
-Add missing Signed-off-by tags
-Stop using __raw_readl / __raw_writel so that barriers are properly used
-Adding missing new lines
-Adding missing patch for automatic reparenting of clocks
cheers
david
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: How to support SDIO wifi/bt in DT
From: Mark Brown @ 2014-02-05 17:11 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Belloni, devicetree@vger.kernel.org,
Russell King - ARM Linux, Arnd Bergmann,
linux-mmc@vger.kernel.org, Olof Johansson,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20140117104423.GR17530@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 184 bytes --]
On Fri, Jan 17, 2014 at 11:44:23AM +0100, Andrew Lunn wrote:
> I've not looked at regulators, but i would hope it also does reference
> counting of a regulators users.
Yes, it does.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 45/47] adv7604: Add DT support
From: Laurent Pinchart @ 2014-02-05 16:42 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil, Lars-Peter Clausen, devicetree
In-Reply-To: <1391618558-5580-1-git-send-email-laurent.pinchart@ideasonboard.com>
Parse the device tree node to populate platform data.
Cc: devicetree@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
.../devicetree/bindings/media/i2c/adv7604.txt | 56 ++++++++++++
drivers/media/i2c/adv7604.c | 101 ++++++++++++++++++---
2 files changed, 143 insertions(+), 14 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/adv7604.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
new file mode 100644
index 0000000..0845c50
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -0,0 +1,56 @@
+* Analog Devices ADV7604/11 video decoder with HDMI receiver
+
+The ADV7604 and ADV7611 are multiformat video decoders with an integrated HDMI
+receiver. The ADV7604 has four multiplexed HDMI inputs and one analog input,
+and the ADV7611 has one HDMI input and no analog input.
+
+Required Properties:
+
+ - compatible: Must contain one of the following
+ - "adi,adv7604" for the ADV7604
+ - "adi,adv7611" for the ADV7611
+
+ - reg: I2C slave address
+
+ - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
+ detection pins, one per HDMI input. The active flag indicates the GPIO
+ level that enables hot-plug detection.
+
+Optional Properties:
+
+ - reset-gpios: Reference to the GPIO connected to the device's reset pin.
+
+ - adi,default-input: Index of the input to be configured as default. Valid
+ values are 0..5 for the ADV7604 and 0 for the ADV7611.
+
+ - adi,disable-power-down: Boolean property. When set forces the device to
+ ignore the power-down pin. The property is valid for the ADV7604 only as
+ the ADV7611 has no power-down pin.
+
+ - adi,disable-cable-reset: Boolean property. When set disables the HDMI
+ receiver automatic reset when the HDMI cable is unplugged.
+
+Example:
+
+ hdmi_receiver@4c {
+ compatible = "adi,adv7611";
+ reg = <0x4c>;
+
+ reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
+ hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
+
+ adi,default-input = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ hdmi_in: endpoint {
+ remote-endpoint = <&ccdc_in>;
+ };
+ };
+ };
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e586c1c..cd8a2dc 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -32,6 +32,7 @@
#include <linux/i2c.h>
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/of_gpio.h>
#include <linux/slab.h>
#include <linux/v4l2-dv-timings.h>
#include <linux/videodev2.h>
@@ -2641,13 +2642,83 @@ static const struct adv7604_chip_info adv7604_chip_info[] = {
},
};
+static struct i2c_device_id adv7604_i2c_id[] = {
+ { "adv7604", (kernel_ulong_t)&adv7604_chip_info[ADV7604] },
+ { "adv7611", (kernel_ulong_t)&adv7604_chip_info[ADV7611] },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
+
+static struct of_device_id adv7604_of_id[] = {
+ { .compatible = "adi,adv7604", .data = &adv7604_chip_info[ADV7604] },
+ { .compatible = "adi,adv7611", .data = &adv7604_chip_info[ADV7611] },
+ { }
+};
+MODULE_DEVICE_TABLE(of, adv7604_of_id);
+
+static int adv7604_parse_dt(struct adv7604_state *state)
+{
+ struct device_node *np;
+ unsigned int i;
+ int ret;
+
+ np = state->i2c_clients[ADV7604_PAGE_IO]->dev.of_node;
+ state->info = of_match_node(adv7604_of_id, np)->data;
+
+ state->pdata.disable_pwrdnb =
+ of_property_read_bool(np, "adi,disable-power-down");
+ state->pdata.disable_cable_det_rst =
+ of_property_read_bool(np, "adi,disable-cable-reset");
+
+ ret = of_property_read_u32(np, "adi,default-input",
+ &state->pdata.default_input);
+ if (ret < 0)
+ state->pdata.default_input = -1;
+
+ for (i = 0; i < state->info->num_dv_ports; ++i) {
+ enum of_gpio_flags flags;
+
+ state->pdata.hpd_gpio[i] =
+ of_get_named_gpio_flags(np, "hpd-gpios", i, &flags);
+ if (IS_ERR_VALUE(state->pdata.hpd_gpio[i]))
+ continue;
+
+ state->pdata.hpd_gpio_low[i] = flags == OF_GPIO_ACTIVE_LOW;
+ }
+
+ /* Disable the interrupt for now as no DT-based board uses it. */
+ state->pdata.int1_config = ADV7604_INT1_CONFIG_DISABLED;
+
+ /* Use the default I2C addresses. */
+ state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42;
+ state->pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40;
+ state->pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME] = 0x3e;
+ state->pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38;
+ state->pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c;
+ state->pdata.i2c_addresses[ADV7604_PAGE_AFE] = 0x26;
+ state->pdata.i2c_addresses[ADV7604_PAGE_REP] = 0x32;
+ state->pdata.i2c_addresses[ADV7604_PAGE_EDID] = 0x36;
+ state->pdata.i2c_addresses[ADV7604_PAGE_HDMI] = 0x34;
+ state->pdata.i2c_addresses[ADV7604_PAGE_TEST] = 0x30;
+ state->pdata.i2c_addresses[ADV7604_PAGE_CP] = 0x22;
+ state->pdata.i2c_addresses[ADV7604_PAGE_VDP] = 0x24;
+
+ /* HACK: Hardcode the remaining platform data fields. */
+ state->pdata.blank_data = 1;
+ state->pdata.op_656_range = 1;
+ state->pdata.alt_data_sat = 1;
+ state->pdata.insert_av_codes = 1;
+ state->pdata.op_format_mode_sel = ADV7604_OP_FORMAT_MODE0;
+
+ return 0;
+}
+
static int adv7604_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
static const struct v4l2_dv_timings cea640x480 =
V4L2_DV_BT_CEA_640X480P59_94;
struct adv7604_state *state;
- struct adv7604_platform_data *pdata = client->dev.platform_data;
struct v4l2_ctrl_handler *hdl;
struct v4l2_subdev *sd;
unsigned int i;
@@ -2666,19 +2737,27 @@ static int adv7604_probe(struct i2c_client *client,
return -ENOMEM;
}
- state->info = &adv7604_chip_info[id->driver_data];
state->i2c_clients[ADV7604_PAGE_IO] = client;
/* initialize variables */
state->restart_stdi_once = true;
state->selected_input = ~0;
- /* platform data */
- if (!pdata) {
+ if (client->dev.of_node) {
+ err = adv7604_parse_dt(state);
+ if (err < 0) {
+ v4l_err(client, "DT parsing error\n");
+ return err;
+ }
+ } else if (client->dev.platform_data) {
+ struct adv7604_platform_data *pdata = client->dev.platform_data;
+
+ state->info = (const struct adv7604_chip_info *)id->driver_data;
+ state->pdata = *pdata;
+ } else {
v4l_err(client, "No platform data!\n");
return -ENODEV;
}
- state->pdata = *pdata;
/* Request GPIOs. */
for (i = 0; i < state->info->num_dv_ports; ++i) {
@@ -2786,7 +2865,7 @@ static int adv7604_probe(struct i2c_client *client,
continue;
state->i2c_clients[i] =
- adv7604_dummy_client(sd, pdata->i2c_addresses[i],
+ adv7604_dummy_client(sd, state->pdata.i2c_addresses[i],
0xf2 + i);
if (state->i2c_clients[i] == NULL) {
err = -ENOMEM;
@@ -2860,21 +2939,15 @@ static int adv7604_remove(struct i2c_client *client)
/* ----------------------------------------------------------------------- */
-static struct i2c_device_id adv7604_id[] = {
- { "adv7604", ADV7604 },
- { "adv7611", ADV7611 },
- { }
-};
-MODULE_DEVICE_TABLE(i2c, adv7604_id);
-
static struct i2c_driver adv7604_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "adv7604",
+ .of_match_table = of_match_ptr(adv7604_of_id),
},
.probe = adv7604_probe,
.remove = adv7604_remove,
- .id_table = adv7604_id,
+ .id_table = adv7604_i2c_id,
};
module_i2c_driver(adv7604_driver);
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCHv9 1/4] clk: socfpga: Add a clk-phase property to the "altr, socfpga-gate-clk"
From: Dinh Nguyen @ 2014-02-05 16:39 UTC (permalink / raw)
To: Mike Turquette
Cc: Dinh Nguyen, Jaehoon Chung, arnd, cjb, tgih.jun, heiko, dianders,
alim.akhtar, bzhao, zhangfei.gao, linux-mmc, linux-arm-kernel,
devicetree
In-Reply-To: <20140205160350.22158.37384@quantum>
On Wed, 2014-02-05 at 08:03 -0800, Mike Turquette wrote:
> Quoting Dinh Nguyen (2014-01-15 04:36:52)
> > Hi Mike,
> >
> > Can you apply this to your clk tree?
>
> The patch looks good to me, but I think it depends on your pending pull
> request. Can you add this to that pull request and rebase it to
> 3.14-rc1?
Yes, I will send an updated pull request shortly.
Thanks,
Dinh
>
> Thanks,
> Mike
>
> >
> > Thanks,
> > Dinh
> >
>
^ permalink raw reply
* Re: [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Lars-Peter Clausen @ 2014-02-05 16:30 UTC (permalink / raw)
To: Srikanth Thokala
Cc: Vinod Koul, dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA, Grant Likely,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CA+mB=1L9XFC8h_qW_-K-cv5sYondL_0NiLr=9XCFxwWRjDHn1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 02/05/2014 05:25 PM, Srikanth Thokala wrote:
> On Fri, Jan 31, 2014 at 12:21 PM, Srikanth Thokala <sthokal-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>> Hi Vinod,
>>
>> On Tue, Jan 28, 2014 at 8:43 AM, Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>>> On Mon, Jan 27, 2014 at 06:42:36PM +0530, Srikanth Thokala wrote:
>>>> Hi Lars/Vinod,
>>>>>> The question here i think would be waht this device supports? Is the hardware
>>>>>> capable of doing interleaved transfers, then would make sense.
>>>>>
>>>>> The hardware does 2D transfers. The parameters for a transfer are height,
>>>>> width and stride. That's only a subset of what interleaved transfers can be
>>>>> (xt->num_frames must be one for 2d transfers). But if I remember correctly
>>>>> there has been some discussion on this in the past and the result of that
>>>>> discussion was that using interleaved transfers for 2D transfers is
>>>>> preferred over adding a custom API for 2D transfers.
>>>>
>>>> I went through the prep_interleaved_dma API and I see only one descriptor
>>>> is prepared per API call (i.e. per frame). As our IP supports upto 16 frame
>>>> buffers (can be more in future), isn't it less efficient compared to the
>>>> prep_slave_sg where we get a single sg list and can prepare all the descriptors
>>>> (of non-contiguous buffers) in one go? Correct me, if am wrong and let me
>>>> know your opinions.
>>> Well the descriptor maybe one, but that can represent multiple frames, for
>>> example 16 as in your case. Can you read up the documentation of how multiple
>>> frames are passed. Pls see include/linux/dmaengine.h
>>>
>>> /**
>>> * Interleaved Transfer Request
>>> * ----------------------------
>>> * A chunk is collection of contiguous bytes to be transfered.
>>> * The gap(in bytes) between two chunks is called inter-chunk-gap(ICG).
>>> * ICGs may or maynot change between chunks.
>>> * A FRAME is the smallest series of contiguous {chunk,icg} pairs,
>>> * that when repeated an integral number of times, specifies the transfer.
>>> * A transfer template is specification of a Frame, the number of times
>>> * it is to be repeated and other per-transfer attributes.
>>> *
>>> * Practically, a client driver would have ready a template for each
>>> * type of transfer it is going to need during its lifetime and
>>> * set only 'src_start' and 'dst_start' before submitting the requests.
>>> *
>>> *
>>> * | Frame-1 | Frame-2 | ~ | Frame-'numf' |
>>> * |====....==.===...=...|====....==.===...=...| ~ |====....==.===...=...|
>>> *
>>> * == Chunk size
>>> * ... ICG
>>> */
>>
>> Yes, it can handle multiple frames specified by 'numf' each of size
>> 'frame_size * sgl[0].size'.
>> But, I see it only works if all the frames' memory is contiguous and
>> in this case we
>> can just increment 'src_start' by the total frame size 'numf' number
>> of times to fill in
>> for each HW descriptor (each frame is one HW descriptor). So, there
>> is no issue when the
>> memory is contiguous. If the frames are non contiguous, we have to
>> call this API for each
>> frame (hence for each descriptor), as the src_start for each frame is
>> different. Is it correct?
>>
>> FYI: This hardware has an inbuilt Scatter-Gather engine.
>>
>
> Ping?
If you want to submit multiple frames at once I think you should look at how
the current dmaengine API can be extended to allow that. And also provide an
explanation on how this is superior over submitting them one by one.
- Lars
--
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] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Srikanth Thokala @ 2014-02-05 16:25 UTC (permalink / raw)
To: Srikanth Thokala
Cc: Vinod Koul, Lars-Peter Clausen, dan.j.williams, michal.simek,
Grant Likely, robh+dt, linux-arm-kernel,
linux-kernel@vger.kernel.org, devicetree, dmaengine
In-Reply-To: <CA+mB=1K8Cqe_c6_ce-fLyphvqcr90mhCjFdZ_d4BV-VkUk-gXw@mail.gmail.com>
On Fri, Jan 31, 2014 at 12:21 PM, Srikanth Thokala <sthokal@xilinx.com> wrote:
> Hi Vinod,
>
> On Tue, Jan 28, 2014 at 8:43 AM, Vinod Koul <vinod.koul@intel.com> wrote:
>> On Mon, Jan 27, 2014 at 06:42:36PM +0530, Srikanth Thokala wrote:
>>> Hi Lars/Vinod,
>>> >> The question here i think would be waht this device supports? Is the hardware
>>> >> capable of doing interleaved transfers, then would make sense.
>>> >
>>> > The hardware does 2D transfers. The parameters for a transfer are height,
>>> > width and stride. That's only a subset of what interleaved transfers can be
>>> > (xt->num_frames must be one for 2d transfers). But if I remember correctly
>>> > there has been some discussion on this in the past and the result of that
>>> > discussion was that using interleaved transfers for 2D transfers is
>>> > preferred over adding a custom API for 2D transfers.
>>>
>>> I went through the prep_interleaved_dma API and I see only one descriptor
>>> is prepared per API call (i.e. per frame). As our IP supports upto 16 frame
>>> buffers (can be more in future), isn't it less efficient compared to the
>>> prep_slave_sg where we get a single sg list and can prepare all the descriptors
>>> (of non-contiguous buffers) in one go? Correct me, if am wrong and let me
>>> know your opinions.
>> Well the descriptor maybe one, but that can represent multiple frames, for
>> example 16 as in your case. Can you read up the documentation of how multiple
>> frames are passed. Pls see include/linux/dmaengine.h
>>
>> /**
>> * Interleaved Transfer Request
>> * ----------------------------
>> * A chunk is collection of contiguous bytes to be transfered.
>> * The gap(in bytes) between two chunks is called inter-chunk-gap(ICG).
>> * ICGs may or maynot change between chunks.
>> * A FRAME is the smallest series of contiguous {chunk,icg} pairs,
>> * that when repeated an integral number of times, specifies the transfer.
>> * A transfer template is specification of a Frame, the number of times
>> * it is to be repeated and other per-transfer attributes.
>> *
>> * Practically, a client driver would have ready a template for each
>> * type of transfer it is going to need during its lifetime and
>> * set only 'src_start' and 'dst_start' before submitting the requests.
>> *
>> *
>> * | Frame-1 | Frame-2 | ~ | Frame-'numf' |
>> * |====....==.===...=...|====....==.===...=...| ~ |====....==.===...=...|
>> *
>> * == Chunk size
>> * ... ICG
>> */
>
> Yes, it can handle multiple frames specified by 'numf' each of size
> 'frame_size * sgl[0].size'.
> But, I see it only works if all the frames' memory is contiguous and
> in this case we
> can just increment 'src_start' by the total frame size 'numf' number
> of times to fill in
> for each HW descriptor (each frame is one HW descriptor). So, there
> is no issue when the
> memory is contiguous. If the frames are non contiguous, we have to
> call this API for each
> frame (hence for each descriptor), as the src_start for each frame is
> different. Is it correct?
>
> FYI: This hardware has an inbuilt Scatter-Gather engine.
>
Ping?
> Srikanth
>
>>
>> --
>> ~Vinod
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 1/6] i2c: bcm-kona: register with subsys_initcall
From: Matt Porter @ 2014-02-05 16:19 UTC (permalink / raw)
To: Alan Stern
Cc: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Liam Girdwood,
Mark Brown, Christian Daudt, Devicetree List, Linux I2C List,
Linux ARM Kernel List, Linux Kernel Mailing List, Felipe Balbi,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <Pine.LNX.4.44L0.1402051028350.1312-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Wed, Feb 05, 2014 at 10:30:29AM -0500, Alan Stern wrote:
> On Wed, 5 Feb 2014, Matt Porter wrote:
>
> > On Wed, Feb 05, 2014 at 10:08:18AM +0100, Wolfram Sang wrote:
> > > On Tue, Feb 04, 2014 at 07:19:07AM -0500, Matt Porter wrote:
> > >
> > > > Voltage regulators are needed very early due to deferred probe
> > > > being incompatible with built-in USB gadget drivers.
> > >
> > > What does it need to fix those instead?
> >
> > [added Alan/Felipe for more insight]
> >
> > Discussion on that topic came about from this submission:
> > http://www.spinics.net/lists/linux-usb/msg94217.html
> >
> > End of it is:
> > http://www.spinics.net/lists/linux-usb/msg94731.html
> >
> > We can either add to the many drivers that already do subsys_initcall()
> > for similar reasons...or I can drop this from the series and add gadget
> > probe ordering to my TODO list.
> >
> > In short, it can't be a late_initcall() hack like the original post and
> > really could be solved by converting to a real bus (and letting
> > deferred probe do its job)..but Alan voiced concerns about that.
>
> Don't worry too much about what I said. If adding a "gadget" bus will
> solve the problem in an appropriate way, and if nobody else objects
> (particularly Felipe, who is on vacation now), then go for it.
Ok, I'll take a look at what can be done and restart the conversation
when Felipe returns.
Wolfram: given this, as I mentioned, I'll simply drop this patch from
the series and work around it for now. This will probably make Lee and
Mark happy to not see subsys_initcall() in the MFD/regulator drivers as
well.
-Matt
^ permalink raw reply
* Re: [PATCH v5 2/3] clocksource: keystone: add bindings for keystone timer
From: Ivan Khoronzhuk @ 2014-02-05 16:18 UTC (permalink / raw)
To: Rob Herring
Cc: Santosh Shilimkar, Rob Landley, Russell King - ARM Linux,
Kumar Gala, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Daniel Lezcano, Thomas Gleixner, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Grygorii Strashko
In-Reply-To: <CAL_JsqKVc2fdg1Q+TH6ro9kpJmUYyHw8FCwhORfm2_oj6GYM2Q@mail.gmail.com>
On 02/05/2014 04:39 PM, Rob Herring wrote:
> On Wed, Feb 5, 2014 at 7:47 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote:
>> This patch provides bindings for the 64-bit timer in the KeyStone
>> architecture devices. The timer can be configured as a general-purpose 64-bit
>> timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
>> timers, each half can operate in conjunction (chain mode) or independently
>> (unchained mode) of each other.
> This is software configurable or h/w design time configurations?
>
> Rob
>
This is h/w design time configurations
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH v4] gpio: Driver for SYSCON-based GPIOs
From: Alexander Shiyan @ 2014-02-05 16:08 UTC (permalink / raw)
To: Linus Walleij
Cc: Arnd Bergmann, Olof Johansson, Kevin Hilman,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Alexandre Courbot, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CACRpkdaVn0iNFYKE3HXWxnb4iCJorF0HSVG4Uvz8Q18SiF5PUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 30 Jan 2014 14:54:36 +0100
Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Mon, Jan 13, 2014 at 5:56 PM, Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org> wrote:
>
> > SYSCON driver was designed for using memory areas (registers)
> > that are used in several subsystems. There are systems (CPUs)
> > which use bits in one register for various purposes and thus
> > should be handled by various kernel subsystems. This driver
> > allows you to use the individual SYSCON bits as GPIOs.
> > ARM CLPS711X SYSFLG1 input lines has been added as first user
> > of this driver.
> >
> > Signed-off-by: Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org>
>
> Oh the pain. I am so ambivalent of this patch as it obfuscates
> some stuff about the hardware that the driver should know,
> while at the same time being elegant in a way.
>
> What does the ARM SoC maintainers think about this approach?
>
> Arnd, Olof, Kevin: is this something you'd like to see deployed?
Ping.
--
Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org>
--
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: [PATCHv9 1/4] clk: socfpga: Add a clk-phase property to the "altr, socfpga-gate-clk"
From: Mike Turquette @ 2014-02-05 16:03 UTC (permalink / raw)
To: Dinh Nguyen, Jaehoon Chung, dinguyen, arnd, cjb, tgih.jun, heiko,
dianders, alim.akhtar, bzhao
Cc: zhangfei.gao, linux-mmc, linux-arm-kernel, devicetree
In-Reply-To: <52D680E4.6090608@gmail.com>
Quoting Dinh Nguyen (2014-01-15 04:36:52)
> Hi Mike,
>
> Can you apply this to your clk tree?
The patch looks good to me, but I think it depends on your pending pull
request. Can you add this to that pull request and rebase it to
3.14-rc1?
Thanks,
Mike
>
> Thanks,
> Dinh
>
^ permalink raw reply
* RE: [PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy framework
From: Kamil Debski @ 2014-02-05 15:57 UTC (permalink / raw)
To: 'Olof Johansson'
Cc: linux-kernel, linux-samsung-soc, linux-usb, devicetree,
'Kyungmin Park', 'Kishon Vijay Abraham I',
Tomasz Figa, Sylwester Nawrocki, Marek Szyprowski,
'Vivek Gautam', mat.krawczuk, yulgon.kim, p.paneri,
av.tikhomirov, 'Jingoo Han', 'Kumar Gala',
'Matt Porter', tjakobi, 'Alan Stern'
In-Reply-To: <CAOesGMgKQrW=Rb6ZtpOVKAZ6dDzy82CzbmOJtKRb8x6JaS1QLg@mail.gmail.com>
Hi Olof,
Thank you for your review.
> From: Olof Johansson [mailto:olof@lixom.net]
> Sent: Wednesday, January 29, 2014 9:55 PM
>
> Hi,
>
> On Wed, Jan 29, 2014 at 9:29 AM, Kamil Debski <k.debski@samsung.com>
> wrote:
> > Change the phy provider used from the old one using the USB phy
> > framework to a new one using the Generic phy framework.
> >
> > Signed-off-by: Kamil Debski <k.debski@samsung.com>
> > ---
> > .../devicetree/bindings/usb/exynos-usb.txt | 13 +++
> > drivers/usb/host/ehci-exynos.c | 97
> +++++++++++++-------
> > 2 files changed, 76 insertions(+), 34 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> > b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> > index d967ba1..25e199a 100644
> > --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> > +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> > @@ -12,6 +12,10 @@ Required properties:
> > - interrupts: interrupt number to the cpu.
> > - clocks: from common clock binding: handle to usb clock.
> > - clock-names: from common clock binding: Shall be "usbhost".
> > + - port: if in the SoC there are EHCI phys, they should be listed
> here.
> > +One phy per port. Each port should have its reg entry with a
> > +consecutive number. Also it should contain phys and phy-names
> entries
> > +specifying the phy used by the port.
> >
> > Optional properties:
> > - samsung,vbus-gpio: if present, specifies the GPIO that @@ -27,6
> > +31,15 @@ Example:
> >
> > clocks = <&clock 285>;
> > clock-names = "usbhost";
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + port@0 {
> > + reg = <0>;
> > + phys = <&usb2phy 1>;
> > + phy-names = "host";
> > + status = "disabled";
> > + };
> > };
> >
> > OHCI
>
> [...]
>
> > @@ -102,14 +132,26 @@ static int exynos_ehci_probe(struct
> platform_device *pdev)
> > "samsung,exynos5440-ehci"))
> > goto skip_phy;
> >
> > - phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
> > - if (IS_ERR(phy)) {
> > - usb_put_hcd(hcd);
> > - dev_warn(&pdev->dev, "no platform data or transceiver
> defined\n");
> > - return -EPROBE_DEFER;
> > - } else {
> > - exynos_ehci->phy = phy;
> > - exynos_ehci->otg = phy->otg;
> > + for_each_available_child_of_node(pdev->dev.of_node, child) {
> > + err = of_property_read_u32(child, "reg",
> &phy_number);
> > + if (err) {
> > + dev_err(&pdev->dev, "Failed to parse device
> tree\n");
> > + of_node_put(child);
> > + return err;
> > + }
> > + if (phy_number >= PHY_NUMBER) {
> > + dev_err(&pdev->dev, "Failed to parse device
> tree - number out of range\n");
> > + of_node_put(child);
> > + return -EINVAL;
> > + }
> > + phy = devm_of_phy_get(&pdev->dev, child, 0);
> > + of_node_put(child);
> > + if (IS_ERR(phy)) {
> > + dev_err(&pdev->dev, "Failed to get phy number
> %d",
> > +
> phy_number);
> > + return PTR_ERR(phy);
> > + }
> > + exynos_ehci->phy[phy_number] = phy;
>
> this looks like it is now breaking older device trees, where ports
> might not be described. Since device tree interfaces need to be
> backwards compatible, you still need to handle the old case of not
> having ports described.
>
> There are two ways of doing this:
>
> 1. Fall back to the old behavior if there are no ports 2. Use a new
> compatible value for the new model with port subnodes, and if the old
> compatible value is used, then fall back to the old behavior.
>
> I'm guessing (1) might be easiest since you can check for the presence
> of #address-cells to tell if this is just an old style node, or if it's
> a new-style node without any ports below it.
The ultimate goal is to remove the old phy driver. Unfortunately
this has to be synced with the new USB3 phy driver by Vivek Gautam. I think
he
is also close to completion. What about this case? In the end the old driver
will be removed and no longer be supported. Having backward compatibility in
mind, it is possible to have the old and the new phy driver together in one
kernel release. But do we want to have two drivers doing the same thing at
the same time?
Best wishes,
--
Kamil Debski
Samsung R&D Institute Poland
^ permalink raw reply
* RE: [PATCH v6 3/8] dts: Add usb2phy to Exynos 4
From: Kamil Debski @ 2014-02-05 15:57 UTC (permalink / raw)
To: 'Olof Johansson'
Cc: linux-kernel, linux-samsung-soc, linux-usb, devicetree,
'Kyungmin Park', 'Kishon Vijay Abraham I',
Tomasz Figa, Sylwester Nawrocki, Marek Szyprowski,
'Vivek Gautam', mat.krawczuk, yulgon.kim, p.paneri,
av.tikhomirov, 'Jingoo Han', 'Kumar Gala',
'Matt Porter', tjakobi, 'Alan Stern'
In-Reply-To: <CAOesGMh8qEumWGb_mVuiSTWE=tsEusntG5r9xL3Z+f_WUnBQSw@mail.gmail.com>
Hi Olof,
> From: Olof Johansson [mailto:olof@lixom.net]
> Sent: Wednesday, January 29, 2014 9:51 PM
>
> On Wed, Jan 29, 2014 at 9:29 AM, Kamil Debski <k.debski@samsung.com>
> wrote:
> > Add support to PHY of USB2 of the Exynos 4 SoC.
> >
> > Signed-off-by: Kamil Debski <k.debski@samsung.com>
> > ---
> > .../devicetree/bindings/arm/samsung/pmu.txt | 2 ++
> > arch/arm/boot/dts/exynos4.dtsi | 31
> ++++++++++++++++++++
> > arch/arm/boot/dts/exynos4210.dtsi | 17
> +++++++++++
> > arch/arm/boot/dts/exynos4x12.dtsi | 17
> +++++++++++
> > 4 files changed, 67 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> > b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> > index 307e727..a76f91d 100644
> > --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> > +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> > @@ -3,6 +3,8 @@ SAMSUNG Exynos SoC series PMU Registers
> > Properties:
> > - name : should be 'syscon';
> > - compatible : should contain two values. First value must be one
> from following list:
> > + - "samsung,exynos4210-pmu" - for Exynos4210 SoC,
> > + - "samsung,exynos4x12-pmu" - for Exynos4212 SoC,
> > - "samsung,exynos5250-pmu" - for Exynos5250 SoC,
> > - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
> > second value must be always "syscon".
>
> This and other PMU related bindings/dts changes should probably go in
> separate patch(es) instead of being snuck in with USB changes.
O, I will move this to a separate patch.
Best wishes,
--
Kamil Debski
Samsung R&D Institute Poland
^ permalink raw reply
* RE: [PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy framework
From: Kamil Debski @ 2014-02-05 15:57 UTC (permalink / raw)
To: 'Alan Stern'
Cc: linux-kernel, linux-samsung-soc, linux-usb, devicetree,
kyungmin.park, kishon, Tomasz Figa, Sylwester Nawrocki,
Marek Szyprowski, gautam.vivek, mat.krawczuk, yulgon.kim,
p.paneri, av.tikhomirov, jg1.han, galak, matt.porter, tjakobi
In-Reply-To: <Pine.LNX.4.44L0.1401291530001.23560-100000@netrider.rowland.org>
Hi Alan,
Thank you for your review.
> From: Alan Stern [mailto:stern@rowland.harvard.edu]
> Sent: Wednesday, January 29, 2014 9:43 PM
>
> On Wed, 29 Jan 2014, Kamil Debski wrote:
>
> > Change the phy provider used from the old one using the USB phy
> > framework to a new one using the Generic phy framework.
> >
> > Signed-off-by: Kamil Debski <k.debski@samsung.com>
> > ---
> > .../devicetree/bindings/usb/exynos-usb.txt | 13 +++
> > drivers/usb/host/ehci-exynos.c | 97
> +++++++++++++-------
> > 2 files changed, 76 insertions(+), 34 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> > b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> > index d967ba1..25e199a 100644
> > --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> > +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> > @@ -12,6 +12,10 @@ Required properties:
> > - interrupts: interrupt number to the cpu.
> > - clocks: from common clock binding: handle to usb clock.
> > - clock-names: from common clock binding: Shall be "usbhost".
> > + - port: if in the SoC there are EHCI phys, they should be listed
> here.
> > +One phy per port. Each port should have its reg entry with a
> > +consecutive number. Also it should contain phys and phy-names
> entries
> > +specifying the phy used by the port.
>
> What is the reg entry number used for? As far as I can see, it isn't
> used for anything. In which case, why have it at all?
Tomasz Figa already commented this. I agree with him, that this should
be better described in the documentation.
>
> > @@ -42,10 +42,10 @@
> > static const char hcd_name[] = "ehci-exynos"; static struct
> > hc_driver __read_mostly exynos_ehci_hc_driver;
> >
> > +#define PHY_NUMBER 3
> > struct exynos_ehci_hcd {
> > struct clk *clk;
> > - struct usb_phy *phy;
> > - struct usb_otg *otg;
>
> You have removed all the OTG stuff from the driver. This wasn't
> mentioned in the patch description, and it has no connection with the
> PHY work.
Maybe I'll explain more about what are we trying to achieve. The goal
is to replace the old phy driver with the new one. In the old driver it was
difficult to add support to new SoC. It also had issues with having device
and
host working together.
You're right that until the old phy driver is removed support for the it
should
remain. To be able to remove the old driver both new USB2 and new USB3 phy
drivers
have to be ready. The USB3 driver is written by Vivek Gautam and as I see
it, he
is also close to completion.
Regarding the otg part. The old phy driver is the only provider of the otg
structure. It sets the host field of the structure. It is then used by
samsung_usb2phy_init (drivers/usb/phy/phy-samsung-usb2.c) to check which
driver is requesting the phy (is it host or device). In the new driver this
is determined by the entry in device tree. So no need to check the otg
struct
and strstr (!) to check if dev_name is ehci, ohci or other, like the old
driver.
> > + struct phy *phy[PHY_NUMBER];
> > };
> >
> > #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd
> > *)(hcd_to_ehci(hcd)->priv) @@ -69,13 +69,43 @@ static void
> exynos_setup_vbus_gpio(struct platform_device *pdev)
> > dev_err(dev, "can't request ehci vbus gpio %d", gpio); }
> >
> > +static int exynos_phys_on(struct phy *p[]) {
> > + int i;
> > + int ret = 0;
> > +
> > + for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
> > + if (p[i])
> > + ret = phy_power_on(p[i]);
> > + if (ret)
> > + for (i--; i > 0; i--)
> > + if (p[i])
> > + phy_power_off(p[i]);
>
> This loop runs while i > 0. Therefore you will never turn off the
> power to p[0].
Ups, my bad. Thank you for spotting this.
>
> > @@ -102,14 +132,26 @@ static int exynos_ehci_probe(struct
> platform_device *pdev)
> > "samsung,exynos5440-ehci"))
> > goto skip_phy;
> >
> > - phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
> > - if (IS_ERR(phy)) {
> > - usb_put_hcd(hcd);
>
> You omitted this line from the new error returns below.
I see.
>
> > - dev_warn(&pdev->dev, "no platform data or transceiver
> defined\n");
> > - return -EPROBE_DEFER;
> > - } else {
> > - exynos_ehci->phy = phy;
> > - exynos_ehci->otg = phy->otg;
> > + for_each_available_child_of_node(pdev->dev.of_node, child) {
> > + err = of_property_read_u32(child, "reg", &phy_number);
> > + if (err) {
> > + dev_err(&pdev->dev, "Failed to parse device
tree\n");
> > + of_node_put(child);
> > + return err;
>
> Here, for example. Wouldn't it be better to goto fail_clk?
Right, I will fix this. Thank you.
Best wishes,
--
Kamil Debski
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v2 0/6] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs
From: Hans de Goede @ 2014-02-05 15:47 UTC (permalink / raw)
To: David Lanzendörfer, Maxime Ripard
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson, Laurent Pinchart,
Simon Baatz, linux-mmc-u79uwXL29TY76Z2rM5mHXA, Chris Ball,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, H Hartley Sweeten,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Tejun Heo,
Guennadi Liakhovetski,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1676482.sbjAhaSLaV-GPtPHOohwllnsqa/0SyWJQ@public.gmane.org>
Hi David,
On 02/05/2014 02:01 PM, David Lanzendörfer wrote:
> Hi Maxime
>> I have four comments here:
>> - Read Documentation/SubmittingPatches, especially Section 5 and 12
>> (hints, you forgot the clock maintainers for your clock patches
>> and you didn't put any signed-off-by tags)
> Oops. I added signed-offs now
>> - You ignored pretty much all the comments that were made during the
>> review of the first version. Go through
> Uh? I just fixed the commits and squashed them together for easier handling.
> I'm even using mmc_of_parse now...
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219339.
>> html and address the comments that were made.
>> - Each of your patches should compile. Fix the order of your
>> patches.
> Done.
>> - Submit a v3, with the changes you made. Otherwise we have no way
>> of knowing what have been fixed and what didn't
> Too many patches would be bloaty.
> That's why I've squashed them into small and corrected patches.
The squashing is fine, what Maxime means is that normally you would include
a changelog in the coverletter (the [patch 0/x] mail) documenting changes
done since the previous posting of the patchset, so for v3 that would have been
something like:
Changes since v1:
-use mmc_of_parse instead of diy dt parsing
-add nodes for all mmc controller to the dtsi files, including sofar unused
controllers
Changes since v2:
-Add missing Signed-off-by tags
-stop using __raw_readl / __raw_writel so that barriers are properly used
I've probably forgotten a few things, it would be good if you could send
a reply to the:
"[PATCH v3 0/7] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs"
mail with the above changelog, amended with whatever I've forgotten to add
to the above changelog
Thanks & Regards,
Hans
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* [PATCH v4] gpio: davinci: reuse for keystone soc
From: Grygorii Strashko @ 2014-02-05 15:47 UTC (permalink / raw)
To: Linus Walleij, santosh.shilimkar-l0cyMroinI0, nsekhar-l0cyMroinI0,
Rob Herring
Cc: Alexandre Courbot,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
The similar GPIO HW block is used by keystone SoCs as
in Davinci SoCs.
Hence, reuse Davinci GPIO driver for Keystone taking into
account that Keystone contains ARM GIC IRQ controller which
is implemented using IRQ Chip.
Documentation:
http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
Acked-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
---
Changes in v4:
- rebased on top of v3.14 +
[patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()
.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-
drivers/gpio/gpio-davinci.c | 48 ++++++++++++++++----
2 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index a2e839d..4ce9862 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,7 +1,7 @@
-Davinci GPIO controller bindings
+Davinci/Keystone GPIO controller bindings
Required Properties:
-- compatible: should be "ti,dm6441-gpio"
+- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"
- reg: Physical base address of the controller and the size of memory mapped
registers.
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index b0e98d3..5c97f61 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -37,6 +37,8 @@ struct davinci_gpio_regs {
u32 intstat;
};
+typedef struct irq_chip *(*gpio_get_irq_chip_cb_t)(unsigned int irq);
+
#define BINTEN 0x8 /* GPIO Interrupt Per-Bank Enable Register */
#define chip2controller(chip) \
@@ -413,6 +415,26 @@ static const struct irq_domain_ops davinci_gpio_irq_ops = {
.xlate = irq_domain_xlate_onetwocell,
};
+static struct irq_chip *davinci_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip_type gpio_unbanked;
+
+ gpio_unbanked = *container_of(irq_get_chip(irq),
+ struct irq_chip_type, chip);
+
+ return &gpio_unbanked.chip;
+};
+
+static struct irq_chip *keystone_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip gpio_unbanked;
+
+ gpio_unbanked = *irq_get_chip(irq);
+ return &gpio_unbanked;
+};
+
+static const struct of_device_id davinci_gpio_ids[];
+
/*
* NOTE: for suspend/resume, probably best to make a platform_device with
* suspend_late/resume_resume calls hooking into results of the set_wake()
@@ -434,6 +456,18 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
struct davinci_gpio_regs __iomem *g;
struct irq_domain *irq_domain = NULL;
int irq;
+ const struct of_device_id *match;
+ struct irq_chip *irq_chip;
+ gpio_get_irq_chip_cb_t gpio_get_irq_chip;
+
+ /*
+ * Use davinci_gpio_get_irq_chip by default to handle non DT cases
+ */
+ gpio_get_irq_chip = davinci_gpio_get_irq_chip;
+ match = of_match_device(of_match_ptr(davinci_gpio_ids),
+ dev);
+ if (match)
+ gpio_get_irq_chip = (gpio_get_irq_chip_cb_t)match->data;
ngpio = pdata->ngpio;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -490,8 +524,6 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
* IRQ mux conflicts; gpio_irq_type_unbanked() is only for GPIOs.
*/
if (pdata->gpio_unbanked) {
- static struct irq_chip_type gpio_unbanked;
-
/* pass "bank 0" GPIO IRQs to AINTC */
chips[0].chip.to_irq = gpio_to_irq_unbanked;
chips[0].gpio_irq = bank_irq;
@@ -500,10 +532,9 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
/* AINTC handles mask/unmask; GPIO handles triggering */
irq = bank_irq;
- gpio_unbanked = *container_of(irq_get_chip(irq),
- struct irq_chip_type, chip);
- gpio_unbanked.chip.name = "GPIO-AINTC";
- gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked;
+ irq_chip = gpio_get_irq_chip(irq);
+ irq_chip->name = "GPIO-AINTC";
+ irq_chip->irq_set_type = gpio_irq_type_unbanked;
/* default trigger: both edges */
g = gpio2regs(0);
@@ -512,7 +543,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
/* set the direct IRQs up to use that irqchip */
for (gpio = 0; gpio < pdata->gpio_unbanked; gpio++, irq++) {
- irq_set_chip(irq, &gpio_unbanked.chip);
+ irq_set_chip(irq, irq_chip);
irq_set_handler_data(irq, &chips[gpio / 32]);
irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
}
@@ -555,7 +586,8 @@ done:
#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id davinci_gpio_ids[] = {
- { .compatible = "ti,dm6441-gpio", },
+ { .compatible = "ti,keystone-gpio", keystone_gpio_get_irq_chip},
+ { .compatible = "ti,dm6441-gpio", davinci_gpio_get_irq_chip},
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, davinci_gpio_ids);
--
1.7.9.5
^ permalink raw reply related
* [RFC] Documentation: devicetree: bindings: drm: Xylon binding
From: Davor Joja @ 2014-02-05 15:36 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA; +Cc: Davor Joja
In-Reply-To: <1391614588-2831-1-git-send-email-davorjoja-bBue3UIS71U2IjGS+8YXRQ@public.gmane.org>
Xylon binding of DRM driver and logiCVC IP core.
Signed-off-by: Davor Joja <davorjoja-bBue3UIS71U2IjGS+8YXRQ@public.gmane.org>
---
.../devicetree/bindings/drm/xylon/logicvc.txt | 79 ++++++++++++++++++++
.../devicetree/bindings/drm/xylon/xylon_drm.txt | 24 ++++++
2 files changed, 103 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/xylon/logicvc.txt
create mode 100644 Documentation/devicetree/bindings/drm/xylon/xylon_drm.txt
diff --git a/Documentation/devicetree/bindings/drm/xylon/logicvc.txt b/Documentation/devicetree/bindings/drm/xylon/logicvc.txt
new file mode 100644
index 0000000..505e655
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/xylon/logicvc.txt
@@ -0,0 +1,79 @@
+Binding for Xylon configurable video controller logiCVC IP core
+
+Required properties:
+ - compatible: value must be "xylon,logicvc-4.00.a"
+ - reg: MMIO base address and size of the logiCVC IP core address space
+ - interrupts-parent: the phandle for interrupt controller
+ - interrupts: the interrupt number
+ - background-layer-bits-per-pixel: background layer bits per pixel (16, 32)
+ if omitted, last available layer is logiCVC standard layer, which has its
+ own video memory of specific size, color format and specified
+ bits per pixel
+ if 16 or 32, last available layer is logiCVC background layer,
+ with only specified bits per pixel value
+ - interface: logiCVC to display physical interface
+ (0=Parallel, 1=ITU656)
+ - color-space: logiCVC to display physical color space
+ (0=RGB, 1=YCbCr 4:2:2, 2=YCbCr 4:4:4)
+ - is-readable-regs: all logiCVC registers are available for reading
+ if omitted, only Interrupt Status, Power Control and IP Version registers
+ are available for reading
+ - is-size-position: logiCVC functionality for controlling on screen layer size
+ and position is available
+ if omitted, functionality is not available
+ - pixel-stride: layer video memory width in pixels
+ common for all available logiCVC standard layers
+ - layer_0: layer has its own configuration described with below properties
+ - bits-per-pixel: layer bits per pixel configuration (16, 32)
+ layer is configured to be used with specific pixel width in bits
+ pixels written to layer video memory must match in size to configured
+ bits per pixel value
+ - format: layer format (0=RGB, 1=YCbCr)
+ layer is configured to be used with specific color format
+ pixels written to layer video memory must match specified color format
+ - transparency: layer transparency (0=Layer, 1=Pixel)
+ logiCVC layer can be configured to have transparency control on
+ layer or pixel level
+ "Layer" mode enables controlling of layer transparency by changing
+ alpha value in single logiCVC register
+ "Pixel" mode enables controlling of pixel transparency by changing
+ dedicated alpha bits of specific pixel in video memory
+
+Example:
+
+ logicvc_0: logicvc@40000000 {
+ compatible = "xylon,logicvc-4.00.a";
+ reg = <0x40000000 0x6000>;
+ interrupt-parent = <&gic_0>;
+ interrupts = <0 59 4>;
+ background-layer-bits-per-pixel = <32>;
+ interface = <0>;
+ color-space = <1>;
+ is-readable-regs;
+ is-size-position;
+ pixel-stride = <2048>;
+ layer_0 {
+ address = <0x30000000>;
+ bits-per-pixel = <16>;
+ format = <0>;
+ transparency = <0>;
+ };
+ layer_1 {
+ address = <0x30500000>;
+ bits-per-pixel = <32>;
+ format = <0>;
+ transparency = <0>;
+ };
+ layer_2 {
+ address = <0x30E00000>;
+ bits-per-pixel = <32>;
+ format = <0>;
+ transparency = <1>;
+ };
+ layer_3 {
+ address = <0x31700000>;
+ bits-per-pixel = <16>;
+ format = <1>;
+ transparency = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/drm/xylon/xylon_drm.txt b/Documentation/devicetree/bindings/drm/xylon/xylon_drm.txt
new file mode 100644
index 0000000..da4940e
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/xylon/xylon_drm.txt
@@ -0,0 +1,24 @@
+Binding for Xylon DRM driver
+
+Xylon DRM driver supports the Xylon configurable video controller
+logiCVC FPGA IP core device.
+
+On ZC702, ZC706, ZED boards, logiCVC uses SI570 CCF driver for pixel clock
+generation, and ADV7511 DRM encoder driver to set video encoding configuration.
+
+Required properties:
+ - compatible: value should be "xylon,drm-1.00.a".
+ - clocks: the phandle for the pixel clock generator
+ - device: the phandle for logiCVC video controller device
+ - encoder: the phandle for the video encoder
+ - private-plane: logiCVC layer id used for DRM driver private plane
+
+Example:
+
+ xylon_drm {
+ compatible = "xylon,drm-1.00.a";
+ clocks = <&si570>;
+ device = <&logicvc_0>;
+ encoder = <&adv7511>;
+ private-plane = <0>;
+ };
--
1.7.9.5
--
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
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