[patch] usb: phy: signedness bug in suspend/resume
ret should be signed here for the error handling to work.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 15ab3d6..d36c282 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -120,7 +120,7 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
static int omap_usb2_suspend(struct usb_phy *x, int suspend)
{
- u32 ret;
+ int ret;
struct omap_usb *phy = phy_to_omapusb(x);
if (suspend !phy-is_suspended) {
@@ -223,7 +223,7 @@ static int omap_usb2_runtime_suspend(struct device *dev)
static int omap_usb2_runtime_resume(struct device *dev)
{
- u32 ret = 0;
+ int ret;
struct platform_device *pdev = to_platform_device(dev);
struct omap_usb *phy = platform_get_drvdata(pdev);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3.6.0-rc5] dt: introduce of_get_child to get child node by name.
On 13/09/12 21:32, Rob Herring wrote:
On 09/13/2012 06:10 AM, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch introduces of_get_child function to get a child node by its
name in a given parent node.
Without this patch each driver code has to iterate the parent and do
a string compare, However having of_get_child libary function would
avoid code duplication, errors and is more convenient.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/of/base.c | 27 +++
include/linux/of.h |2 ++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4a1c9a..d4b6840 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -391,6 +391,33 @@ struct device_node *of_get_next_available_child(const
struct device_node *node,
EXPORT_SYMBOL(of_get_next_available_child);
/**
+ * of_get_child - Find the child node by name for given parent
+ * @node: parent node
+ * @name: child name to look for.
+ *
+ * This function looks for child node for given matching name
+ *
+ * Returns a node pointer if found, with refcount incremented, use
+ * of_node_put() on it when done.
+ * else returns NULL.
+ */
+
+struct device_node *of_get_child(const struct device_node *node,
of_get_child_by_name would be more consistent naming with other apis.
I agree.
+const char *name)
+{
+struct device_node *child;
+
+read_lock(devtree_lock);
I don't think you need the lock here. The for_each takes the lock while
finding the node.
yes, you are correct. We don't need a readlock here.
+for_each_child_of_node(node, child)
+if (child-name (of_node_cmp(child-name, name) == 0)
+ of_node_get(child))
+break;
+read_unlock(devtree_lock);
+return child;
+}
+EXPORT_SYMBOL(of_get_child);
+
+/**
* of_find_node_by_path - Find a node matching a full OF path
* @path: The full path to match
*
diff --git a/include/linux/of.h b/include/linux/of.h
index 1b11632..510e1fe 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -192,6 +192,8 @@ extern struct device_node *of_get_next_child(const
struct device_node *node,
struct device_node *prev);
extern struct device_node *of_get_next_available_child(
const struct device_node *node, struct device_node *prev);
+extern struct device_node *of_get_child(const struct device_node *node,
+const char *name);
#define for_each_child_of_node(parent, child) \
for (child = of_get_next_child(parent, NULL); child != NULL; \
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/4] lis3: lis3lv02d_spi: Add lis3lv02d device tree init
Add lis3lv02d device tree initialization code/API to take pdata
from device node. Also remove CONFIG_OF ifdef from the driver,
if CONFIG_OF is not defined then OF APIs returns 0.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/misc/lis3lv02d/lis3lv02d_spi.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
index 23f3986..e1db6f4 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
@@ -84,10 +84,12 @@ static int __devinit lis302dl_spi_probe(struct spi_device
*spi)
lis3_dev.ac = lis3lv02d_axis_normal;
lis3_dev.pdata = spi-dev.platform_data;
-#ifdef CONFIG_OF
- if (of_match_device(lis302dl_spi_dt_ids, spi-dev))
+ if (of_match_device(lis302dl_spi_dt_ids, spi-dev)) {
lis3_dev.of_node = spi-dev.of_node;
-#endif
+ ret = lis3lv02d_init_dt(lis3_dev);
+ if (ret)
+ return ret;
+ }
spi_set_drvdata(spi, lis3_dev);
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/4] lis3: lis3lv02d: remove lis3lv02d driver DT init
Remove lis3lv02d driver device tree initialization from core driver
and move it to individual drivers. With the current implementation
some pdata parameters are missing if we use lis3lv02d_init_device()
in lis3lv02d_i2c driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/misc/lis3lv02d/lis3lv02d.c |8 ++--
drivers/misc/lis3lv02d/lis3lv02d.h |1 +
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
index 79349ec..026021e 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -944,7 +944,7 @@ static void lis3lv02d_8b_configure(struct lis3lv02d *lis3,
}
#ifdef CONFIG_OF
-static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
+int lis3lv02d_init_dt(struct lis3lv02d *lis3)
{
struct lis3lv02d_platform_data *pdata;
struct device_node *np = lis3-of_node;
@@ -1084,7 +1084,7 @@ static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
}
#else
-static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
+int lis3lv02d_init_dt(struct lis3lv02d *lis3)
{
return 0;
}
@@ -1100,10 +1100,6 @@ int lis3lv02d_init_device(struct lis3lv02d *lis3)
irq_handler_t thread_fn;
int irq_flags = 0;
- err = lis3lv02d_init_dt(lis3);
- if (err 0)
- return err;
-
lis3-whoami = lis3lv02d_read_8(lis3, WHO_AM_I);
switch (lis3-whoami) {
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.h
b/drivers/misc/lis3lv02d/lis3lv02d.h
index 4cf0779..b5505fa 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.h
+++ b/drivers/misc/lis3lv02d/lis3lv02d.h
@@ -326,5 +326,6 @@ void lis3lv02d_joystick_disable(struct lis3lv02d *lis3);
void lis3lv02d_poweroff(struct lis3lv02d *lis3);
int lis3lv02d_poweron(struct lis3lv02d *lis3);
int lis3lv02d_remove_fs(struct lis3lv02d *lis3);
+int lis3lv02d_init_dt(struct lis3lv02d *lis3);
extern struct lis3lv02d lis3_dev;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 4/4] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
Add lis331dlh device tree data to am335x-evm.dts. In AM335x EVM
lis331dlh accelerometer is connected to I2C2 bus. So this patch
change the status of I2C2 node to okay to use I2C2 bus. Also
added all the required platform data to am335x-evm.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9fb59c5..890f955 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -47,6 +47,15 @@
};
};
+ i2c2: i2c@4802a000 {
+ status = okay;
+ clock-frequency = 40;
+
+ lis331dlh: lis331dlh@18 {
+ reg = 0x18;
+ };
+ };
+
dcan1: d_can@481d {
status = okay;
pinctrl-names = default;
@@ -61,6 +70,39 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ lis3_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = lis3_reg;
+ regulator-boot-on;
+ };
+};
+
+lis331dlh {
+ compatible = st,lis331dlh-i2c;
+ Vdd-supply = lis3_reg;
+ Vdd_IO-supply = lis3_reg;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = 10;
+ st,click-thresh-y = 10;
+ st,click-thresh-z = 10;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ st,min-limit-x = 120;
+ st,min-limit-y = 120;
+ st,min-limit-z = 140;
+ st,max-limit-x = 550;
+ st,max-limit-y = 550;
+ st,max-limit-z = 750;
};
/include/ tps65910.dtsi
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 3/4] lis3: lis3lv02d_i2c: Add lis3lv02d device tree init
Add lis3lv02d device tree initialization code/API to take pdata
from device node. Also adds device tree init matching table
support to lis3lv02d_i2c driver. If the driver data is passed
from device tree, then this driver picks up platform data
from device node through common/generic lis3lv02d.c driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/misc/lis3lv02d/lis3lv02d_i2c.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
b/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
index 15255eb..56b5124 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
@@ -31,6 +31,9 @@
#include linux/i2c.h
#include linux/pm_runtime.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_platform.h
+
#include lis3lv02d.h
#define DRV_NAME lis3lv02d_i2c
@@ -102,12 +105,27 @@ static int lis3_i2c_init(struct lis3lv02d *lis3)
static union axis_conversion lis3lv02d_axis_map =
{ .as_array = { LIS3_DEV_X, LIS3_DEV_Y, LIS3_DEV_Z } };
+static struct of_device_id lis3lv02d_i2c_dt_ids[] = {
+ { .compatible = st,lis3lv02d-i2c },
+ { .compatible = st,lis331dlh-i2c },
+ {}
+};
+MODULE_DEVICE_TABLE(of, lis3lv02d_i2c_dt_ids);
+
static int __devinit lis3lv02d_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
int ret = 0;
struct lis3lv02d_platform_data *pdata = client-dev.platform_data;
+ if (of_match_device(lis3lv02d_i2c_dt_ids, client-dev)) {
+ lis3_dev.of_node = client-dev.of_node;
+ ret = lis3lv02d_init_dt(lis3_dev);
+ if (ret)
+ return ret;
+ pdata = lis3_dev.pdata;
+ }
+
if (pdata) {
if ((pdata-driver_features LIS3_USE_BLOCK_READ)
(i2c_check_functionality(client-adapter,
@@ -255,6 +273,7 @@ static struct i2c_driver lis3lv02d_i2c_driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
.pm = lis3_pm_ops,
+ .of_match_table = of_match_ptr(lis3lv02d_i2c_dt_ids),
},
.probe = lis3lv02d_i2c_probe,
.remove = __devexit_p(lis3lv02d_i2c_remove),
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 0/4] lis3: lis3lv02d_i2c: Add device tree support
Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. Changes from v1: - Moved lis3lv02d_init_dt to individual drivers with some code clean-up. - Added lis331dlh compatible entry for lis331dlh parts AnilKumar Ch (4): lis3: lis3lv02d: remove lis3lv02d driver DT init lis3: lis3lv02d_spi: Add lis3lv02d device tree init lis3: lis3lv02d_i2c: Add lis3lv02d device tree init ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm arch/arm/boot/dts/am335x-evm.dts | 42 drivers/misc/lis3lv02d/lis3lv02d.c |8 ++ drivers/misc/lis3lv02d/lis3lv02d.h |1 + drivers/misc/lis3lv02d/lis3lv02d_i2c.c | 19 +++ drivers/misc/lis3lv02d/lis3lv02d_spi.c |8 +++--- 5 files changed, 69 insertions(+), 9 deletions(-) -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 0/7] Introduce of_get_child_by_name.
From: Srinivas Kandagatla srinivas.kandaga...@st.com This patch series introduces of_get_child_by_name function to get a child node by its name in a given parent node and also removes code duplication in some of the existing driver code by using of_get_child_by_name. Normally if a driver want to get a child node it would iterate all the nodes of parent and compare its name and then get it. This use case is becoming common as device trees are used more, so moving this functionality to a libary function makes sense. Having of_get_child_by_name libary function would avoid code duplication, errors and is more convenient. Changes from v1: -rename of_get_child to of_get_child_by_name. -remove read lock in of_get_child_by_name. -make use of of_get_child_by_name in the existing kernel code. Srinivas Kandagatla (7): dt: introduce of_get_child_by_name to get child node by name. dt/powerpc: Use of_get_child_by_name to get a named child. dt/powerpc/powernv: Use of_get_child_by_name to get a named child. dt/powerpc/sysdev: Use of_get_child_by_name to get a named child. dt/net/fsl_pq_mdio: Use of_get_child_by_name to get a named child. dt/s3c64xx/spi: Use of_get_child_by_name to get a named child. dt/tty/opal: Use of_get_child_by_name to get a named child. arch/powerpc/kernel/prom.c |5 + arch/powerpc/platforms/powernv/opal.c|6 ++ arch/powerpc/sysdev/qe_lib/qe.c |5 + drivers/net/ethernet/freescale/fsl_pq_mdio.c |5 + drivers/of/base.c| 25 + drivers/spi/spi-s3c64xx.c|4 +--- drivers/tty/hvc/hvc_opal.c |9 ++--- include/linux/of.h |2 ++ 8 files changed, 35 insertions(+), 26 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/7] dt: introduce of_get_child_by_name to get child node by name.
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch introduces of_get_child_by_name function to get a child node
by its name in a given parent node.
Without this patch each driver code has to iterate the parent and do
a string compare, However having of_get_child_by_name libary function would
avoid code duplication, errors and is more convenient.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/of/base.c | 25 +
include/linux/of.h |2 ++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4a1c9a..7391f8a 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -391,6 +391,31 @@ struct device_node *of_get_next_available_child(const
struct device_node *node,
EXPORT_SYMBOL(of_get_next_available_child);
/**
+ * of_get_child_by_name - Find the child node by name for a given parent
+ * @node: parent node
+ * @name: child name to look for.
+ *
+ * This function looks for child node for given matching name
+ *
+ * Returns a node pointer if found, with refcount incremented, use
+ * of_node_put() on it when done.
+ * Returns NULL if node is not found.
+ */
+
+struct device_node *of_get_child_by_name(const struct device_node *node,
+ const char *name)
+{
+ struct device_node *child;
+
+ for_each_child_of_node(node, child)
+ if (child-name (of_node_cmp(child-name, name) == 0)
+of_node_get(child))
+ break;
+ return child;
+}
+EXPORT_SYMBOL(of_get_child_by_name);
+
+/**
* of_find_node_by_path - Find a node matching a full OF path
* @path: The full path to match
*
diff --git a/include/linux/of.h b/include/linux/of.h
index 1b11632..7b8e3cd 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -192,6 +192,8 @@ extern struct device_node *of_get_next_child(const struct
device_node *node,
struct device_node *prev);
extern struct device_node *of_get_next_available_child(
const struct device_node *node, struct device_node *prev);
+extern struct device_node *of_get_child_by_name(const struct device_node *node,
+ const char *name);
#define for_each_child_of_node(parent, child) \
for (child = of_get_next_child(parent, NULL); child != NULL; \
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/7] dt/powerpc: Use of_get_child_by_name to get a named child.
From: Srinivas Kandagatla srinivas.kandaga...@st.com
As follow-up to dt: introduce of_get_child_by_name to get child node by
name. patch, This patch removes some of the code duplication in the
driver by replacing it with of_get_child_by_name instead.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
arch/powerpc/kernel/prom.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index f191bf0..80e5b6c 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -735,7 +735,6 @@ void __init early_init_devtree(void *params)
*/
struct device_node *of_find_next_cache_node(struct device_node *np)
{
- struct device_node *child;
const phandle *handle;
handle = of_get_property(np, l2-cache, NULL);
@@ -749,9 +748,7 @@ struct device_node *of_find_next_cache_node(struct
device_node *np)
* beneath CPU nodes.
*/
if (!strcmp(np-type, cpu))
- for_each_child_of_node(np, child)
- if (!strcmp(child-type, cache))
- return child;
+ return of_get_child_by_name(np, cache);
return NULL;
}
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 3/7] dt/powerpc/powernv: Use of_get_child_by_name to get a named child.
From: Srinivas Kandagatla srinivas.kandaga...@st.com
As follow-up to dt: introduce of_get_child_by_name to get child node by
name. patch, This patch removes some of the code duplication in the
driver by replacing it with of_get_child_by_name instead.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
arch/powerpc/platforms/powernv/opal.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index aaa0dba..6dfb8af 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -294,11 +294,9 @@ static int __init opal_init(void)
consoles = of_node_get(opal_node);
/* Register serial ports */
- for_each_child_of_node(consoles, np) {
- if (strcmp(np-name, serial))
- continue;
+ np = of_get_child_by_name(consoles, serial);
+ if (np)
of_platform_device_create(np, NULL, NULL);
- }
of_node_put(consoles);
/* Find all OPAL interrupts and request them */
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 4/7] dt/powerpc/sysdev: Use of_get_child_by_name to get a named child.
From: Srinivas Kandagatla srinivas.kandaga...@st.com
As follow-up to dt: introduce of_get_child_by_name to get child node by
name. patch, This patch removes some of the code duplication in the
driver by replacing it with of_get_child_by_name instead.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
arch/powerpc/sysdev/qe_lib/qe.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index b043675..fd1c15d 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -568,10 +568,7 @@ struct qe_firmware_info *qe_get_firmware_info(void)
}
/* Find the 'firmware' child node */
- for_each_child_of_node(qe, fw) {
- if (strcmp(fw-name, firmware) == 0)
- break;
- }
+ fw = of_get_child_by_name(qe firmware);
of_node_put(qe);
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 5/7] dt/net/fsl_pq_mdio: Use of_get_child_by_name to get a named child.
From: Srinivas Kandagatla srinivas.kandaga...@st.com
As follow-up to dt: introduce of_get_child_by_name to get child node by
name. patch, This patch removes some of the code duplication in the
driver by replacing it with of_get_child_by_name instead.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/net/ethernet/freescale/fsl_pq_mdio.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
index 9527b28..e710c60 100644
--- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
+++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
@@ -355,10 +355,7 @@ static int fsl_pq_mdio_probe(struct platform_device *ofdev)
goto err_free_irqs;
}
- for_each_child_of_node(np, tbi) {
- if (!strncmp(tbi-type, tbi-phy, 8))
- break;
- }
+ tbi = of_get_child_by_name(np, tbi-phy);
if (tbi) {
const u32 *prop = of_get_property(tbi, reg, NULL);
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 6/7] dt/s3c64xx/spi: Use of_get_child_by_name to get a named child.
From: Srinivas Kandagatla srinivas.kandaga...@st.com
As follow-up to dt: introduce of_get_child_by_name to get child node by
name. patch, This patch removes some of the code duplication in the
driver by replacing it with of_get_child_by_name instead.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/spi/spi-s3c64xx.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d1c8441..1fa231b 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -835,9 +835,7 @@ static struct s3c64xx_spi_csinfo
*s3c64xx_get_slave_ctrldata(
return ERR_PTR(-EINVAL);
}
- for_each_child_of_node(slave_np, data_np)
- if (!strcmp(data_np-name, controller-data))
- break;
+ data_np = of_get_child_by_name(slave_np, controller-data);
if (!data_np) {
dev_err(spi-dev, child node 'controller-data' not found\n);
return ERR_PTR(-EINVAL);
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 7/7] dt/tty/opal: Use of_get_child_by_name to get a named child.
From: Srinivas Kandagatla srinivas.kandaga...@st.com
As follow-up to dt: introduce of_get_child_by_name to get child node by
name. patch, This patch removes some of the code duplication in the
driver by replacing it with of_get_child_by_name instead.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/tty/hvc/hvc_opal.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
index 0d2ea0c..4c7d161 100644
--- a/drivers/tty/hvc/hvc_opal.c
+++ b/drivers/tty/hvc/hvc_opal.c
@@ -344,7 +344,7 @@ void __init hvc_opal_init_early(void)
return;
}
} else {
- struct device_node *opal, *np;
+ struct device_node *opal;
/* Current OPAL takeover doesn't provide the stdout
* path, so we hard wire it
@@ -360,12 +360,7 @@ void __init hvc_opal_init_early(void)
}
if (!opal)
return;
- for_each_child_of_node(opal, np) {
- if (!strcmp(np-name, serial)) {
- stdout_node = np;
- break;
- }
- }
+ stdout_node = of_get_child_by_name(opal, serial);
of_node_put(opal);
}
if (!stdout_node)
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
On Thursday 13 September 2012, AnilKumar Ch wrote:
Add lis331dlh device tree data to am335x-evm.dts. In AM335x EVM
lis331dlh accelerometer is connected to I2C2 bus. So this patch
change the status to okay to use I2C2 bus. Also added all the
required platform data to am335x-evm.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 42
++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 9fb59c5..9e5a878 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -47,6 +47,15 @@
};
};
+ i2c2: i2c@4802a000 {
+ status = okay;
+ clock-frequency = 40;
+
+ lis331dlh: lis331dlh@18 {
+ reg = 0x18;
+ };
+ };
Why do you put the reg property here
dcan1: d_can@481d {
status = okay;
pinctrl-names = default;
@@ -61,6 +70,39 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ lis3_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = lis3_reg;
+ regulator-boot-on;
+ };
+};
+lis331dlh {
+ compatible = st,lis3lv02d-i2c;
and all the rest here? At least I would expect the compatible property
to be in the same place above.
Also, I think you should remove the -i2c postfix from the name, that
is already implied by the parent bus.
+ Vdd-supply = lis3_reg;
+ Vdd_IO-supply = lis3_reg;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = 10;
+ st,click-thresh-y = 10;
+ st,click-thresh-z = 10;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ st,min-limit-x = 120;
+ st,min-limit-y = 120;
+ st,min-limit-z = 140;
+ st,max-limit-x = 550;
+ st,max-limit-y = 550;
+ st,max-limit-z = 750;
Is there a binding document that describes all these?
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 2/2] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
Hi Arnd,
Thanks for the review,
On Fri, Sep 14, 2012 at 13:56:06, Arnd Bergmann wrote:
On Thursday 13 September 2012, AnilKumar Ch wrote:
Add lis331dlh device tree data to am335x-evm.dts. In AM335x EVM
lis331dlh accelerometer is connected to I2C2 bus. So this patch
change the status to okay to use I2C2 bus. Also added all the
required platform data to am335x-evm.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 42
++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 9fb59c5..9e5a878 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -47,6 +47,15 @@
};
};
+ i2c2: i2c@4802a000 {
+ status = okay;
+ clock-frequency = 40;
+
+ lis331dlh: lis331dlh@18 {
+ reg = 0x18;
+ };
+ };
Why do you put the reg property here
Here I specified reg property because lis331dlh I2C slave address is 0x18.
dcan1: d_can@481d {
status = okay;
pinctrl-names = default;
@@ -61,6 +70,39 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ lis3_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = lis3_reg;
+ regulator-boot-on;
+ };
+};
+lis331dlh {
+ compatible = st,lis3lv02d-i2c;
and all the rest here? At least I would expect the compatible property
to be in the same place above.
This data is appended to above one, to make it readable I moved remaining
properties to here.
Also, I think you should remove the -i2c postfix from the name, that
is already implied by the parent bus.
I will remove, but in case of spi the compatible name is lis3lv02d_spi.
By mistake I have uses -i2c instead of _i2c.
+ Vdd-supply = lis3_reg;
+ Vdd_IO-supply = lis3_reg;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = 10;
+ st,click-thresh-y = 10;
+ st,click-thresh-z = 10;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ st,min-limit-x = 120;
+ st,min-limit-y = 120;
+ st,min-limit-z = 140;
+ st,max-limit-x = 550;
+ st,max-limit-y = 550;
+ st,max-limit-z = 750;
Is there a binding document that describes all these?
Document is already present,
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=2f2ff3cc8d930493f9a598b9192706c09403e12e
Some minor changes in docs, in my next version I will update document
as well. I will send V3 if there are no comments on v2.
Thanks
AnilKumar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
On Friday 14 September 2012, AnilKumar, Chimata wrote:
On Fri, Sep 14, 2012 at 13:56:06, Arnd Bergmann wrote:
On Thursday 13 September 2012, AnilKumar Ch wrote:
Why do you put the reg property here
Here I specified reg property because lis331dlh I2C slave address is 0x18.
dcan1: d_can@481d {
status = okay;
pinctrl-names = default;
@@ -61,6 +70,39 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ lis3_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = lis3_reg;
+ regulator-boot-on;
+ };
+};
+lis331dlh {
+ compatible = st,lis3lv02d-i2c;
and all the rest here? At least I would expect the compatible property
to be in the same place above.
This data is appended to above one, to make it readable I moved remaining
properties to here.
I don't follow how this is making things more readable.
Maybe a more logical way to do this would be use the existing i2c2 label
and write all the additions as
i2c2: {
status = okay;
clock-frequency = 40;
lis331dlh@18 {
compatible = st,lis3lv02d;
reg = 0x18;
vdd-supply = lis3_reg;
vdd-io-supply = lis3_reg;
...
};
Also, I think you should remove the -i2c postfix from the name, that
is already implied by the parent bus.
I will remove, but in case of spi the compatible name is lis3lv02d_spi.
By mistake I have uses -i2c instead of _i2c.
The normal convention is to use '-', not '_', so that part was ok.
I think naming the other one lis3lv02d_spi was a mistake, it should
be named 'st,lis3lv02d' independent of the bus IMHO.
Document is already present,
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=2f2ff3cc8d930493f9a598b9192706c09403e12e
Some minor changes in docs, in my next version I will update document
as well. I will send V3 if there are no comments on v2.
Ok.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 06/24] docs: Xen ARM DT bindings
Add a doc to describe the Xen ARM device tree bindings
Changes in v4:
- xen,xen should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
CC: devicetree-discuss@lists.ozlabs.org
CC: David Vrabel david.vra...@citrix.com
CC: Rob Herring robherri...@gmail.com
CC: Dave Martin dave.mar...@linaro.org
---
Documentation/devicetree/bindings/arm/xen.txt | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
diff --git a/Documentation/devicetree/bindings/arm/xen.txt
b/Documentation/devicetree/bindings/arm/xen.txt
new file mode 100644
index 000..1f8f7d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,22 @@
+* Xen hypervisor device tree bindings
+
+Xen ARM virtual platforms shall have the following properties:
+
+- compatible:
+ compatible = xen,xen-version, xen,xen;
+ where version is the version of the Xen ABI of the platform.
+
+- reg: specifies the base physical address and size of a region in
+ memory where the grant table should be mapped to, using an
+ HYPERVISOR_memory_op hypercall.
+
+- interrupts: the interrupt used by Xen to inject event notifications.
+
+
+Example:
+
+hypervisor {
+ compatible = xen,xen-4.3, xen,xen;
+ reg = 0 0xb000 0 0x2;
+ interrupts = 1 15 0xf08;
+};
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] usb: gadget: s3c-hsotg: Add device tree support
This patch adds device tree support for s3c-hsotg driver
used for Samsung platforms.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
.../devicetree/bindings/usb/s3c-hsotg.txt | 16
drivers/usb/gadget/s3c-hsotg.c | 20
2 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/s3c-hsotg.txt
diff --git a/Documentation/devicetree/bindings/usb/s3c-hsotg.txt
b/Documentation/devicetree/bindings/usb/s3c-hsotg.txt
new file mode 100644
index 000..30b26c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/s3c-hsotg.txt
@@ -0,0 +1,16 @@
+Samsung HSOTG controller s3c-hsotg
+
+Required properties:
+ - compatible : should be samsung,exynos-hsotg.
+ - reg : should contain at least address and length of the standard HSOTG
+register set for the device.
+ - interrupts : one HSOTG interrupt should be described here.
+
+Example (Samsung Origen):
+
+ usb@1248 {
+ compatible = samsung,exynos-hsotg;
+ reg = 0x1248 0x2;
+ interrupts = 0 71 0;
+ };
+
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index b13e0bb..d7f557f 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -28,6 +28,7 @@
#include linux/io.h
#include linux/slab.h
#include linux/clk.h
+#include linux/of.h
#include linux/regulator/consumer.h
#include linux/usb/ch9.h
@@ -3485,6 +3486,8 @@ static void s3c_hsotg_release(struct device *dev)
kfree(hsotg);
}
+static u64 s3c_hsotg_dma_mask = DMA_BIT_MASK(32);
+
/**
* s3c_hsotg_probe - probe function for hsotg driver
* @pdev: The platform information for the driver
@@ -3507,6 +3510,14 @@ static int __devinit s3c_hsotg_probe(struct
platform_device *pdev)
return -EINVAL;
}
+ /*
+* Right now device-tree probed devices don't get dma_mask set.
+*/
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = s3c_hsotg_dma_mask;
+ if (!pdev-dev.coherent_dma_mask)
+ pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+
hsotg = devm_kzalloc(pdev-dev, sizeof(struct s3c_hsotg), GFP_KERNEL);
if (!hsotg) {
dev_err(dev, cannot get memory\n);
@@ -3701,10 +3712,19 @@ static int __devexit s3c_hsotg_remove(struct
platform_device *pdev)
#define s3c_hsotg_resume NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_hsotg_match[] = {
+ { .compatible = samsung,exynos-hsotg },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_hsotg_match);
+#endif
+
static struct platform_driver s3c_hsotg_driver = {
.driver = {
.name = s3c-hsotg,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(exynos_hsotg_match),
},
.probe = s3c_hsotg_probe,
.remove = __devexit_p(s3c_hsotg_remove),
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/7] dt/powerpc/sysdev: Use of_get_child_by_name to get a named child.
On 09/14/2012 03:19 AM, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
As follow-up to dt: introduce of_get_child_by_name to get child node by
name. patch, This patch removes some of the code duplication in the
driver by replacing it with of_get_child_by_name instead.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
arch/powerpc/sysdev/qe_lib/qe.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index b043675..fd1c15d 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -568,10 +568,7 @@ struct qe_firmware_info *qe_get_firmware_info(void)
}
/* Find the 'firmware' child node */
- for_each_child_of_node(qe, fw) {
- if (strcmp(fw-name, firmware) == 0)
- break;
- }
+ fw = of_get_child_by_name(qe firmware);
Missing comma.
of_node_put(qe);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/7] dt/powerpc: Use of_get_child_by_name to get a named child.
On 09/14/2012 03:18 AM, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
As follow-up to dt: introduce of_get_child_by_name to get child node by
name. patch, This patch removes some of the code duplication in the
driver by replacing it with of_get_child_by_name instead.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
arch/powerpc/kernel/prom.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index f191bf0..80e5b6c 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -735,7 +735,6 @@ void __init early_init_devtree(void *params)
*/
struct device_node *of_find_next_cache_node(struct device_node *np)
{
- struct device_node *child;
const phandle *handle;
handle = of_get_property(np, l2-cache, NULL);
@@ -749,9 +748,7 @@ struct device_node *of_find_next_cache_node(struct
device_node *np)
* beneath CPU nodes.
*/
if (!strcmp(np-type, cpu))
- for_each_child_of_node(np, child)
- if (!strcmp(child-type, cache))
name and type are not the same thing.
Rob
- return child;
+ return of_get_child_by_name(np, cache);
return NULL;
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/5] Documentation: add description of DT binding for the gpio-mvebu driver
On Thu, Sep 13, 2012 at 10:34 PM, Rob Herring robherri...@gmail.com wrote: On 09/13/2012 03:30 PM, Thomas Petazzoni wrote: Dear Rob Herring, On Thu, 13 Sep 2012 15:20:54 -0500, Rob Herring wrote: On 09/13/2012 10:54 AM, Thomas Petazzoni wrote: Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Linus Walleij linus.wall...@stericsson.com Cc: Andrew Lunn and...@lunn.ch Cc: Jason Cooper ja...@lakedaemon.net Cc: Gregory Clement gregory.clem...@free-electrons.com --- Grant is pretty much offline right now. Yes, I know, but MAINTAINERS does not mention an alternate maintainer for the GPIO subsystem. Who is the interim maintainer that will ultimately have to ack/nack those patches? Linus W. is. I stated Reviewed-by: on the GPIO patch, please merge it through the Marvell tree (I guess that's the plan?) Acked-by: on the rest FWIW, I'm no ARM SoC nor DT maintainer... Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/7] dt/powerpc/sysdev: Use of_get_child_by_name to get a named child.
Thanks for pointing the typo..
On 14/09/12 14:05, Rob Herring wrote:
On 09/14/2012 03:19 AM, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
As follow-up to dt: introduce of_get_child_by_name to get child node by
name. patch, This patch removes some of the code duplication in the
driver by replacing it with of_get_child_by_name instead.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
arch/powerpc/sysdev/qe_lib/qe.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c
b/arch/powerpc/sysdev/qe_lib/qe.c
index b043675..fd1c15d 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -568,10 +568,7 @@ struct qe_firmware_info *qe_get_firmware_info(void)
}
/* Find the 'firmware' child node */
-for_each_child_of_node(qe, fw) {
-if (strcmp(fw-name, firmware) == 0)
-break;
-}
+fw = of_get_child_by_name(qe firmware);
Missing comma.
of_node_put(qe);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/7] dt/powerpc: Use of_get_child_by_name to get a named child.
My bad...
Will skip this patch in next patch-set...
On 14/09/12 14:06, Rob Herring wrote:
On 09/14/2012 03:18 AM, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
As follow-up to dt: introduce of_get_child_by_name to get child node by
name. patch, This patch removes some of the code duplication in the
driver by replacing it with of_get_child_by_name instead.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
arch/powerpc/kernel/prom.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index f191bf0..80e5b6c 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -735,7 +735,6 @@ void __init early_init_devtree(void *params)
*/
struct device_node *of_find_next_cache_node(struct device_node *np)
{
-struct device_node *child;
const phandle *handle;
handle = of_get_property(np, l2-cache, NULL);
@@ -749,9 +748,7 @@ struct device_node *of_find_next_cache_node(struct
device_node *np)
* beneath CPU nodes.
*/
if (!strcmp(np-type, cpu))
-for_each_child_of_node(np, child)
-if (!strcmp(child-type, cache))
name and type are not the same thing.
Rob
-return child;
+return of_get_child_by_name(np, cache);
return NULL;
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
Hi Arnd,
On 09/14/2012 04:43 AM, Arnd Bergmann wrote:
On Thursday 13 September 2012, Jon Hunter wrote:
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
I think we're getting very close now, I only have a few small comments left
that should all be uncontroversial.
+
+Client drivers should specify the DMA property using a phandle to the
controller
+followed by DMA controller specific data.
+
+Required property:
+- dmas: List of one or more DMA specifiers, each
consisting of
+- A phandle pointing to DMA controller node
+- A single integer cell containing DMA controller
+ specific information. This typically contains a dma
+ request line number or a channel number, but can
+ contain any data that is used required for configuring
+ a channel.
+- dma-names:Contains one identifier string for each dma
specifier in
+the dmas property. The specific strings that can be used
+are defined in the binding of the DMA client device.
I think here we need to clarify that listing the same name multiple times
implies
having multiple alternatives for the same channel.
Ok, however, the way it works right now is that we will use the first
specifier that matches the name. So if there are multiple with the same
name that would imply that someone will need call the
xxx_request_slave_channel() multiple times to extract these. Is that ok?
+Example:
+
+- One DMA write channel, one DMA read/write channel:
+
+i2c1: i2c@1 {
+...
+dmas = sdma 2 /* read channel */
+sdma 3; /* write channel */
+dma-names = rx, tx
+...
+};
And please add an example documenting this case.
Ok.
+/**
+ * of_dma_find_channel - Find a DMA channel by name
+ * @np: device node to look for DMA channels
+ * @name: name of desired channel
+ * @dma_spec: pointer to DMA specifier as found in the device tree
+ *
+ * Find a DMA channel by the name. Returns 0 on success or appropriate
+ * errno value on error.
+ */
+static int of_dma_find_channel(struct device_node *np, char *name,
+ struct of_phandle_args *dma_spec)
+{
+int count, i;
+const char *s;
+
+count = of_property_count_strings(np, dma-names);
+if (count 0)
+return count;
+
+for (i = 0; i count; i++) {
+of_property_read_string_index(np, dma-names, i, s);
+
+if (strcmp(name, s))
+continue;
+
+return of_parse_phandle_with_args(np, dmas, #dma-cells,
+i, dma_spec);
+}
+
+return -ENODEV;
+}
I think we should at least keep trying the other channels with the same name
when
of_parse_phandle_with_args fails. We might want to do something smarter in
the long run, e.g. to spread channel allocations across the avaialable
controllers.
Ok, can add this.
+/**
+ * of_dma_request_slave_channel - Get the DMA slave channel
+ * @np: device node to get DMA request from
+ * @name: name of desired channel
+ *
+ * Returns pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
+ char *name)
+{
...
+}
+EXPORT_SYMBOL_GPL(of_dma_request_slave_channel);
I think this no longer needs to be exported, with patch 2 on top.
Right, I was in two minds but I can remove this.
+/**
+ * of_dma_simple_xlate - Simple DMA engine translation function
+ * @dma_spec: pointer to DMA specifier as found in the device tree
+ * @of_dma: pointer to DMA controller data
+ *
+ * A simple translation function for devices that use a 32-bit value for the
+ * filter_param when calling the DMA engine dma_request_channel() function.
+ * Note that this translation function requires that #dma-cells is equal to
1
+ * and the argument of the dma specifier is the 32-bit filter_param. Returns
+ * pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
+struct of_dma *ofdma)
+{
+int count = dma_spec-args_count;
+struct of_dma_filter_info *info = ofdma-of_dma_data;
+
+if (!info || !info-filter_fn)
+return NULL;
+
+if (count != 1)
+return NULL;
+
+return dma_request_channel(info-dma_cap, info-filter_fn,
+dma_spec-args[0]);
+}
But this one does.
Good catch!
Thanks
Jon
Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
On Friday 14 September 2012, Jon Hunter wrote: On 09/14/2012 04:43 AM, Arnd Bergmann wrote: + +Client drivers should specify the DMA property using a phandle to the controller +followed by DMA controller specific data. + +Required property: +- dmas: List of one or more DMA specifiers, each consisting of + - A phandle pointing to DMA controller node + - A single integer cell containing DMA controller +specific information. This typically contains a dma +request line number or a channel number, but can +contain any data that is used required for configuring +a channel. +- dma-names: Contains one identifier string for each dma specifier in + the dmas property. The specific strings that can be used + are defined in the binding of the DMA client device. I think here we need to clarify that listing the same name multiple times implies having multiple alternatives for the same channel. Ok, however, the way it works right now is that we will use the first specifier that matches the name. So if there are multiple with the same name that would imply that someone will need call the xxx_request_slave_channel() multiple times to extract these. Is that ok? I would expect a driver to only call the function once, and get something back from the dmaengine layer that works. If there are two controllers to choose from and one is busy, then it should definitely give a channel from the non-busy one. It's not much of an issue if the code doesn't handle all corner cases at first, but I would expect that the binding correctly describes how to write a device tree that will work once the code implements it correctly. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
On 09/14/2012 08:32 AM, Arnd Bergmann wrote:
On Friday 14 September 2012, Jon Hunter wrote:
On 09/14/2012 04:43 AM, Arnd Bergmann wrote:
+
+Client drivers should specify the DMA property using a phandle to the
controller
+followed by DMA controller specific data.
+
+Required property:
+- dmas: List of one or more DMA specifiers, each
consisting of
+ - A phandle pointing to DMA controller node
+ - A single integer cell containing DMA controller
+specific information. This typically contains a dma
+request line number or a channel number, but can
+contain any data that is used required for configuring
+a channel.
+- dma-names: Contains one identifier string for each dma
specifier in
+ the dmas property. The specific strings that can be used
+ are defined in the binding of the DMA client device.
I think here we need to clarify that listing the same name multiple times
implies
having multiple alternatives for the same channel.
Ok, however, the way it works right now is that we will use the first
specifier that matches the name. So if there are multiple with the same
name that would imply that someone will need call the
xxx_request_slave_channel() multiple times to extract these. Is that ok?
I would expect a driver to only call the function once, and get something
back from the dmaengine layer that works. If there are two controllers
to choose from and one is busy, then it should definitely give a channel
from the non-busy one.
It's not much of an issue if the code doesn't handle all corner cases at
first, but I would expect that the binding correctly describes how to write
a device tree that will work once the code implements it correctly.
Gotcha, may be something like the following should work then ...
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index 4025f2f..de59611 100644
--- a/drivers/of/dma.c
+++ b/drivers/of/dma.c
@@ -127,13 +127,15 @@ static int of_dma_find_channel(struct device_node *np,
char *name,
return count;
for (i = 0; i count; i++) {
- of_property_read_string_index(np, dma-names, i, s);
+ if (of_property_read_string_index(np, dma-names, i, s))
+ continue;
if (strcmp(name, s))
continue;
- return of_parse_phandle_with_args(np, dmas, #dma-cells,
- i, dma_spec);
+ if (!of_parse_phandle_with_args(np, dmas, #dma-cells, i,
+ dma_spec))
+ return 0;
}
return -ENODEV;
@@ -159,33 +161,34 @@ struct dma_chan *of_dma_request_slave_channel(struct
device_node *np,
return NULL;
}
- r = of_dma_find_channel(np, name, dma_spec);
-
- if (r) {
- pr_err(%s: can't find DMA channel\n, np-full_name);
- return NULL;
- }
+ do {
+ r = of_dma_find_channel(np, name, dma_spec);
+ if (r) {
+ pr_err(%s: can't find DMA channel\n, np-full_name);
+ return NULL;
+ }
+
+ ofdma = of_dma_find_controller(dma_spec.np);
+ if (!ofdma) {
+ pr_debug(%s: can't find DMA controller %s\n,
+ np-full_name, dma_spec.np-full_name);
+ continue;
+ }
- ofdma = of_dma_find_controller(dma_spec.np);
- if (!ofdma) {
- pr_err(%s: can't find DMA controller %s\n, np-full_name,
- dma_spec.np-full_name);
- return NULL;
- }
+ if (dma_spec.args_count != ofdma-of_dma_nbcells) {
+ pr_debug(%s: wrong #dma-cells for %s\n, np-full_name,
+ dma_spec.np-full_name);
+ continue;
+ }
- if (dma_spec.args_count != ofdma-of_dma_nbcells) {
- pr_err(%s: wrong #dma-cells for %s\n, np-full_name,
- dma_spec.np-full_name);
- return NULL;
- }
+ chan = ofdma-of_dma_xlate(dma_spec, ofdma);
- chan = ofdma-of_dma_xlate(dma_spec, ofdma);
+ of_node_put(dma_spec.np);
- of_node_put(dma_spec.np);
+ } while (!chan);
return chan;
}
-EXPORT_SYMBOL_GPL(of_dma_request_slave_channel);
Cheers
Jon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 06/24] docs: Xen ARM DT bindings
On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
Add a doc to describe the Xen ARM device tree bindings
Changes in v4:
- xen,xen should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
CC: devicetree-discuss@lists.ozlabs.org
CC: David Vrabel david.vra...@citrix.com
CC: Rob Herring robherri...@gmail.com
CC: Dave Martin dave.mar...@linaro.org
---
Documentation/devicetree/bindings/arm/xen.txt | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
diff --git a/Documentation/devicetree/bindings/arm/xen.txt
b/Documentation/devicetree/bindings/arm/xen.txt
new file mode 100644
index 000..1f8f7d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,22 @@
+* Xen hypervisor device tree bindings
+
+Xen ARM virtual platforms shall have the following properties:
+
+- compatible:
+ compatible = xen,xen-version, xen,xen;
+ where version is the version of the Xen ABI of the platform.
+
+- reg: specifies the base physical address and size of a region in
+ memory where the grant table should be mapped to, using an
+ HYPERVISOR_memory_op hypercall.
+
+- interrupts: the interrupt used by Xen to inject event notifications.
Its singular here.. but in the example its plurar. What if you use
multiple of the same number (16 0xf)?
The interrupts property in the example below is a standard property to
describe interrupts. We just happen to declare only one interrupt.
From the device tree point of view it would be possible to declare more
than one interrupt here, but Xen only supports one really.
Regarding the three cells used in the example (1 15 0xf08), they have
a specific meaning in the GIC context:
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
the interrupt is wired to that CPU. Only valid for PPI interrupts.
So 1 15 0xf08 means the last PPI.
+
+
+Example:
+
+hypervisor {
+ compatible = xen,xen-4.3, xen,xen;
+ reg = 0 0xb000 0 0x2;
So two grant tables?
Hm, physical address is zero, and the size is 0xbignumber?
Or is the '0' denotating a seperator of arguments, so it is
0xb000.. for physical address and 0x2 for size?
from http://devicetree.org/Device_Tree_Usage:
Each addressable device gets a reg which is a list of tuples in the
form reg = address1 length1 [address2 length2] [address3 length3] ...
Each tuple represents an address range used by the device. Each address
value is a list of one or more 32 bit integers called cells. Similarly,
the length value can either be a list of cells, or empty.
In this case the address is: [0 0xb000], that means
0xb000, and the length is [0 0x2], that means
0x0002.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V5 0/2] of: Add generic device tree DMA helpers
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic device-tree helpers to retrieve a DMA controller device_node and the DMA request/channel information. v5: - minor update to binding documentation - added loop to exhaustively search for a slave channel in the case where there could be alternative channels available v4: - revert the removal of xlate function from v3 - update the proposed binding format and APIs based upon discussions [3] v3: - avoid passing an xlate function and instead pass DMA engine parameters - define number of dma channels and requests in dma-controller node v2: - remove of_dma_to_resource API - make property #dma-cells required (no fallback anymore) - another check in of_dma_xlate_onenumbercell() function [1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022 [2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622 [3] http://marc.info/?l=linux-omapm=133582085008539w=2 Jon Hunter (2): of: Add generic device tree DMA helpers dmaengine: add helper function to request a slave DMA channel Documentation/devicetree/bindings/dma/dma.txt | 80 + drivers/dma/dmaengine.c | 16 ++ drivers/of/Makefile |2 +- drivers/of/dma.c | 219 + include/linux/dmaengine.h |6 + include/linux/of_dma.h| 45 + 6 files changed, 367 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/dma/dma.txt create mode 100644 drivers/of/dma.c create mode 100644 include/linux/of_dma.h -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V5 2/2] dmaengine: add helper function to request a slave DMA channel
Currently slave DMA channels are requested by calling dma_request_channel()
and requires DMA clients to pass various filter parameters to obtain the
appropriate channel.
With device-tree being used by architectures such as arm and the addition of
device-tree helper functions to extract the relevant DMA client information
from device-tree, add a new function to request a slave DMA channel using
device-tree. This function is currently a simple wrapper that calls the
device-tree of_dma_request_slave_channel() function.
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/dma/dmaengine.c | 16
include/linux/dmaengine.h |6 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 3491654..9b466da 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -62,6 +62,7 @@
#include linux/rculist.h
#include linux/idr.h
#include linux/slab.h
+#include linux/of_dma.h
static DEFINE_MUTEX(dma_list_mutex);
static DEFINE_IDR(dma_idr);
@@ -546,6 +547,21 @@ struct dma_chan *__dma_request_channel(dma_cap_mask_t
*mask, dma_filter_fn fn, v
}
EXPORT_SYMBOL_GPL(__dma_request_channel);
+/**
+ * dma_request_slave_channel - try to allocate an exclusive slave channel
+ * @dev: pointer to client device structure
+ * @name: slave channel name
+ */
+struct dma_chan *dma_request_slave_channel(struct device *dev, char *name)
+{
+ /* If device-tree is present get slave info from here */
+ if (dev-of_node)
+ return of_dma_request_slave_channel(dev-of_node, name);
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(dma_request_slave_channel);
+
void dma_release_channel(struct dma_chan *chan)
{
mutex_lock(dma_list_mutex);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9c02a45..9500aa5 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -973,6 +973,7 @@ enum dma_status dma_sync_wait(struct dma_chan *chan,
dma_cookie_t cookie);
enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
void dma_issue_pending_all(void);
struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn,
void *fn_param);
+struct dma_chan *dma_request_slave_channel(struct device *dev, char *name);
void dma_release_channel(struct dma_chan *chan);
#else
static inline enum dma_status dma_wait_for_async_tx(struct
dma_async_tx_descriptor *tx)
@@ -987,6 +988,11 @@ static inline struct dma_chan
*__dma_request_channel(dma_cap_mask_t *mask,
{
return NULL;
}
+static inline struct dma_chan *dma_request_slave_channel(struct device *dev,
+char *name)
+{
+ return NULL
+}
static inline void dma_release_channel(struct dma_chan *chan)
{
}
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V5 1/2] of: Add generic device tree DMA helpers
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
Thinking about DMA controllers purely from the context of the hardware to
begin with, we can describe a device in terms of a DMA controller as
follows ...
1. Number of DMA controllers
2. Number of channels (maybe physical or logical)
3. Mapping of DMA requests signals to DMA controller
4. Number of DMA interrupts
5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to extract
the above information from the DT and provide to the appropriate driver.
However, due to the vast number of DMA controllers and not all are using a
common driver (such as DMA Engine) it has been seen that this is not a
trivial task. In previous discussions on this topic the following concerns
have been raised ...
1. How does the binding support devices with multiple DMA controllers?
2. How to support both legacy DMA controllers not using DMA Engine as
well as those that support DMA Engine.
3. When using with DMA Engine how do we support the various
implementations where the opaque filter function parameter differs
between implementations?
4. How do we handle DMA channels that are identified with a string
versus a integer?
- Hence the design of the DMA helpers has to accomodate the above or align on
an agreement what can be or should be supported.
Design of DMA helpers
1. Registering DMA controllers
In the case of DMA controllers that are using DMA Engine, requesting a
channel is performed by calling the following function.
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
dma_filter_fn filter_fn,
void *filter_param);
The mask variable is used to match a type of the device controller in a list
of controllers. The filter_fn and filter_param are used to identify the
required dma channel and return a handle to the dma channel of type dma_chan.
From the examples I have seen, the mask and filter_fn are constant
for a given DMA controller and therefore, we can specify these as controller
specific data when registering the DMA controller with the device-tree DMA
helpers.
The filter_param variable is of an unknown type and is typically specific
to the DMA engine implementation for a given DMA controller. To allow some
flexibility in the type and formating of this filter_param we employ an
xlate to translate the device-tree binding information into the appropriate
format. The xlate function used for a DMA controller can also be specified
when registering the DMA controller with the device-tree DMA helpers.
Based upon the above, a function for registering the DMA controller with the
DMA helpers now looks like the below. The data variable is used to pass a
pointer to DMA controller specific data used by the xlate function.
int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data)
For example, in the case where DMA engine is used, we define the following
structure (that stores the DMA engine capability mask and filter function)
and pass this to the data variable in the above function.
struct of_dma_filter_info {
dma_cap_mask_t dma_cap;
dma_filter_fn filter_fn;
};
2. Representing and requesting channel information
Please see the dma binding documentation included in this patch for a
description of how DMA controllers and client information should be
represented with device-tree. For more information on how this binding
came about please see [3]. In addition to this, feedback received from
the Linux kernel summit showed a consensus (among those who attended) to
use a name to identify DMA client information [4].
A DMA channel can be requested by calling the following function, where name
is a required parameter used for identifying a DMA channel. This function
has been designed to return a structure of type dma_chan to work with the
DMA engine driver. Note that if DMA engine is used then drivers should be
using the DMA engine API dma_request_slave_channel() (implemented in part 2
of this series, dmaengine: add helper function to request a slave DMA
channel) which will in turn call the below function if device-tree is
present. The aim being to have a common DMA engine interface regardless of
whether device tree is being used.
struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
Re: [PATCH V5 1/2] of: Add generic device tree DMA helpers
On Friday 14 September 2012, Jon Hunter wrote: Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Benoit Cousson b-cous...@ti.com Cc: Stephen Warren swar...@nvidia.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Russell King li...@arm.linux.org.uk Cc: Rob Herring rob.herr...@calxeda.com Cc: Arnd Bergmann a...@arndb.de Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Signed-off-by: Jon Hunter jon-hun...@ti.com Reviewed-by: Arnd Bergmann a...@arndb.de Thanks for all this work, looks great! My final (tiny) comment on this: +2. A single read-write channel with two alternative dma controllers: + + dmas = dma1 5 + dma2 7 + dma3 2; + dma-names = rx-tx, rx-tx, rx-tx *three* alternative dma controllers, not two. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V5 2/2] dmaengine: add helper function to request a slave DMA channel
On Friday 14 September 2012, Jon Hunter wrote: Currently slave DMA channels are requested by calling dma_request_channel() and requires DMA clients to pass various filter parameters to obtain the appropriate channel. With device-tree being used by architectures such as arm and the addition of device-tree helper functions to extract the relevant DMA client information from device-tree, add a new function to request a slave DMA channel using device-tree. This function is currently a simple wrapper that calls the device-tree of_dma_request_slave_channel() function. Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Benoit Cousson b-cous...@ti.com Cc: Stephen Warren swar...@nvidia.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Russell King li...@arm.linux.org.uk Cc: Rob Herring rob.herr...@calxeda.com Cc: Arnd Bergmann a...@arndb.de Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Signed-off-by: Jon Hunter jon-hun...@ti.com Acked-by: Arnd Bergmann a...@arndb.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
On Friday 14 September 2012, AnilKumar, Chimata wrote:
Small question here, in my v2 version I have specified both
the compatible names lis3lv02d and lis331dlh is it fine or
only one is sufficient?
+static struct of_device_id lis3lv02d_i2c_dt_ids[] = {
+ { .compatible = st,lis3lv02d },
+ { .compatible = st,lis331dlh },
+ {}
+};
That's ok. In most cases, people will need the data field to point to a
data structure with the differences between two chips, but not if they are
identical from the software side.
It's also fine if you just list one entry here and put both values as
compatible in the device tree, to signify that the device is backwards
compatible with the older variant.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Friday 14 September 2012, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. No further comments on this version besides the ones I already gave on v1. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V5 1/2] of: Add generic device tree DMA helpers
On 09/14/2012 05:18 PM, Jon Hunter :
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
Thinking about DMA controllers purely from the context of the hardware to
begin with, we can describe a device in terms of a DMA controller as
follows ...
1. Number of DMA controllers
2. Number of channels (maybe physical or logical)
3. Mapping of DMA requests signals to DMA controller
4. Number of DMA interrupts
5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to extract
the above information from the DT and provide to the appropriate driver.
However, due to the vast number of DMA controllers and not all are using a
common driver (such as DMA Engine) it has been seen that this is not a
trivial task. In previous discussions on this topic the following concerns
have been raised ...
1. How does the binding support devices with multiple DMA controllers?
2. How to support both legacy DMA controllers not using DMA Engine as
well as those that support DMA Engine.
3. When using with DMA Engine how do we support the various
implementations where the opaque filter function parameter differs
between implementations?
4. How do we handle DMA channels that are identified with a string
versus a integer?
- Hence the design of the DMA helpers has to accomodate the above or align on
an agreement what can be or should be supported.
Design of DMA helpers
1. Registering DMA controllers
In the case of DMA controllers that are using DMA Engine, requesting a
channel is performed by calling the following function.
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
dma_filter_fn filter_fn,
void *filter_param);
The mask variable is used to match a type of the device controller in a
list
of controllers. The filter_fn and filter_param are used to identify the
required dma channel and return a handle to the dma channel of type
dma_chan.
From the examples I have seen, the mask and filter_fn are constant
for a given DMA controller and therefore, we can specify these as
controller
specific data when registering the DMA controller with the device-tree DMA
helpers.
The filter_param variable is of an unknown type and is typically specific
to the DMA engine implementation for a given DMA controller. To allow some
flexibility in the type and formating of this filter_param we employ an
xlate to translate the device-tree binding information into the appropriate
format. The xlate function used for a DMA controller can also be specified
when registering the DMA controller with the device-tree DMA helpers.
Based upon the above, a function for registering the DMA controller with
the
DMA helpers now looks like the below. The data variable is used to pass a
pointer to DMA controller specific data used by the xlate function.
int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data)
For example, in the case where DMA engine is used, we define the following
structure (that stores the DMA engine capability mask and filter function)
and pass this to the data variable in the above function.
struct of_dma_filter_info {
dma_cap_mask_t dma_cap;
dma_filter_fn filter_fn;
};
2. Representing and requesting channel information
Please see the dma binding documentation included in this patch for a
description of how DMA controllers and client information should be
represented with device-tree. For more information on how this binding
came about please see [3]. In addition to this, feedback received from
the Linux kernel summit showed a consensus (among those who attended) to
use a name to identify DMA client information [4].
A DMA channel can be requested by calling the following function, where
name
is a required parameter used for identifying a DMA channel. This function
has been designed to return a structure of type dma_chan to work with the
DMA engine driver. Note that if DMA engine is used then drivers should be
using the DMA engine API dma_request_slave_channel() (implemented in part 2
of this series, dmaengine: add helper function to request a slave DMA
channel) which will in turn call the below function if device-tree is
present. The aim being to have a common DMA engine interface regardless of
whether device tree is being used.
[PATCH V3 1/2] hwmon: Add devicetree bindings to gpio-fan
Allow a gpio-fan to be defined in devicetree, see binding documentation
for details.
Signed-off-by: Jamie Lentin j...@lentin.co.uk
Acked-by: Andrew Lunn and...@lunn.ch
---
Changes since V2:-
* Correct error message terminology
* Check of_gpio_count returns some GPIOs [Guenter Roeck]
* Whitespace fix [Guenter Roeck]
Changes since V1:-
* Don't hide return codes [Guenter Roeck]
* Remove typecast noise [Guenter Roeck]
* Use of_find_property instead of counting u32s [Guenter Roeck]
* Don't count GPIOs twice [Andrew Lunn]
* Use of_prop_next_u32 to get records in a more obvious fashion
* Use CONFIG_OF_GPIO instead of CONFIG_OF
* Apply __devinitdata to of_gpio_fan_match [Andrew Lunn]
---
.../devicetree/bindings/gpio/gpio-fan.txt | 25
drivers/hwmon/gpio-fan.c | 120
2 files changed, 145 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-fan.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-fan.txt
b/Documentation/devicetree/bindings/gpio/gpio-fan.txt
new file mode 100644
index 000..2dd457a
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-fan.txt
@@ -0,0 +1,25 @@
+Bindings for fan connected to GPIO lines
+
+Required properties:
+- compatible : gpio-fan
+- gpios: Specifies the pins that map to bits in the control value,
+ ordered MSB--LSB.
+- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the
+ control value that should be set to achieve them. This array
+ must have the RPM values in ascending order.
+
+Optional properties:
+- alarm-gpios: This pin going active indicates something is wrong with
+ the fan, and a udev event will be fired.
+
+Examples:
+
+ gpio_fan {
+ compatible = gpio-fan;
+ gpios = gpio1 14 1
+gpio1 13 1;
+ gpio-fan,speed-map = 00
+ 3000 1
+ 6000 2;
+ alarm-gpios = gpio1 15 1;
+ };
diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c
index 2f4b01b..36509ae 100644
--- a/drivers/hwmon/gpio-fan.c
+++ b/drivers/hwmon/gpio-fan.c
@@ -31,6 +31,8 @@
#include linux/hwmon.h
#include linux/gpio.h
#include linux/gpio-fan.h
+#include linux/of_platform.h
+#include linux/of_gpio.h
struct gpio_fan_data {
struct platform_device *pdev;
@@ -400,14 +402,131 @@ static ssize_t show_name(struct device *dev,
static DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
+
+#ifdef CONFIG_OF_GPIO
+/*
+ * Translate OpenFirmware node properties into platform_data
+ */
+static int gpio_fan_get_of_pdata(struct device *dev,
+ struct gpio_fan_platform_data *pdata)
+{
+ struct device_node *node;
+ struct gpio_fan_speed *speed;
+ unsigned *ctrl;
+ unsigned i;
+ u32 u;
+ struct property *prop;
+ const __be32 *p;
+
+ node = dev-of_node;
+
+ /* Fill GPIO pin array */
+ pdata-num_ctrl = of_gpio_count(node);
+ if (!pdata-num_ctrl) {
+ dev_err(dev, gpios DT property empty / missing);
+ return -ENODEV;
+ }
+ ctrl = devm_kzalloc(dev, pdata-num_ctrl * sizeof(unsigned),
+ GFP_KERNEL);
+ if (!ctrl)
+ return -ENOMEM;
+ for (i = 0; i pdata-num_ctrl; i++) {
+ int val;
+
+ val = of_get_gpio(node, i);
+ if (val 0)
+ return val;
+ ctrl[i] = val;
+ }
+ pdata-ctrl = ctrl;
+
+ /* Get number of RPM/ctrl_val pairs in speed map */
+ prop = of_find_property(node, gpio-fan,speed-map, i);
+ if (!prop) {
+ dev_err(dev, gpio-fan,speed-map DT property missing);
+ return -ENODEV;
+ }
+ i = i / sizeof(u32);
+ if (i == 0 || i 1) {
+ dev_err(dev, gpio-fan,speed-map contains zero/odd number of
entries);
+ return -ENODEV;
+ }
+ pdata-num_speed = i / 2;
+
+ /*
+* Populate speed map
+* Speed map is in the form RPM ctrl_val RPM ctrl_val ...
+* this needs splitting into pairs to create gpio_fan_speed structs
+*/
+ speed = devm_kzalloc(dev,
+ pdata-num_speed * sizeof(struct gpio_fan_speed),
+ GFP_KERNEL);
+ if (!speed)
+ return -ENOMEM;
+ p = NULL;
+ for (i = 0; i pdata-num_speed; i++) {
+ p = of_prop_next_u32(prop, p, u);
+ if (!p)
+ return -ENODEV;
+ speed[i].rpm = u;
+ p = of_prop_next_u32(prop, p, u);
+ if (!p)
+ return -ENODEV;
+ speed[i].ctrl_val = u;
+ }
+ pdata-speed = speed;
+
+ /* Alarm GPIO if one exists */
+ if (of_gpio_named_count(node, alarm-gpios)) {
+ struct
[PATCH v3] of: Add videomode helper
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
Hi!
The original patch was done by Sascha Hauer. I reworked his v2 a little bit.
Changes since v2:
- use hardware-near property-names
- provide a videomode structure
- allow ranges for all properties (min,typ,max)
- functions to get display_mode or fb_videomode
Regards,
Steffen
.../devicetree/bindings/video/displaymode | 74 ++
drivers/of/Kconfig |5 +
drivers/of/Makefile|1 +
drivers/of/of_videomode.c | 236
include/linux/of_videomode.h | 56 +
5 files changed, 372 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/displaymode
create mode 100644 drivers/of/of_videomode.c
create mode 100644 include/linux/of_videomode.h
diff --git a/Documentation/devicetree/bindings/video/displaymode
b/Documentation/devicetree/bindings/video/displaymode
new file mode 100644
index 000..990ca52
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/displaymode
@@ -0,0 +1,74 @@
+videomode bindings
+==
+
+Required properties:
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
+ lines
+ - clock: displayclock in Hz
+
+Optional properties:
+ - width-mm, height-mm: Display dimensions in mm
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
+ - interlaced (bool): This is an interlaced mode
+ - doublescan (bool): This is a doublescan mode
+
+There are different ways of describing a display mode. The devicetree
representation
+corresponds to the one commonly found in datasheets for displays.
+The description of the display and its mode is split in two parts: first the
display
+properties like size in mm and (optionally) multiple subnodes with the
supported modes.
+
+Example:
+
+ display@0 {
+ width-mm = 800;
+ height-mm = 480;
+ modes {
+ mode0: mode@0 {
+ /* 1920x1080p24 */
+ clock = 5200;
+ hactive = 1920;
+ vactive = 1080;
+ hfront-porch = 25;
+ hback-porch = 25;
+ hsync-len = 25;
+ vback-porch = 2;
+ vfront-porch = 2;
+ vsync-len = 2;
+ hsync-active-high;
+ };
+ };
+ };
+
+Every property also supports the use of ranges, so the commonly used datasheet
+description with min typ max-tuples can be used.
+
+Example:
+
+ mode1: mode@1 {
+ /* 1920x1080p24 */
+ clock = 14850;
+ hactive = 1920;
+ vactive = 1080;
+ hsync-len = 0 44 60;
+ hfront-porch = 80 88 95;
+ hback-porch = 100 148 160;
+ vfront-porch = 0 4 6;
+ vback-porch = 0 36 50;
+ vsync-len = 0 5 6;
+ };
+
+The videomode can be linked to a connector via phandles. The connector has to
+support the display- and default-mode-property to link to and select a mode.
+
+Example:
+
+ hdmi@0012 {
+ status = okay;
+ display = benq;
+ default-mode = mode1;
+ };
+
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index dfba3e6..a3acaa3 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -83,4 +83,9 @@ config OF_MTD
depends on MTD
def_bool y
+config OF_VIDEOMODE
+ def_bool y
+ help
+ helper to parse videomodes from the devicetree
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e027f44..80e6db3 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
+obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
new file mode 100644
index 000..217edf8
--- /dev/null
+++ b/drivers/of/of_videomode.c
@@ -0,0 +1,236 @@
+/*
+ * OF helpers for parsing display modes
+ *
+ * Copyright (c) 2012 Sascha Hauer s.ha...@pengutronix.de, Pengutronix
+ * Copyright (c) 2012 Steffen Trumtrar
Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
On 09/13/2012 04:00 PM, Jon Hunter wrote: This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt +* Generic DMA Controller and DMA request bindings + +Generic binding to provide a way for a driver using DMA Engine to retrieve the +DMA request or channel information that goes from a hardware device to a DMA +controller. + + +* DMA controller + +Required property: +- #dma-cells:Must be at least 1. Used to provide DMA controller + specific information. See DMA client binding below for ... +* DMA client + +Client drivers should specify the DMA property using a phandle to the controller +followed by DMA controller specific data. + +Required property: +- dmas: List of one or more DMA specifiers, each consisting of + - A phandle pointing to DMA controller node + - A single integer cell containing DMA controller + specific information. This typically contains a dma + request line number or a channel number, but can + contain any data that is used required for configuring + a channel. A single integer cell doesn't sound correct; shouldn't this be something like a number of integer cells, as determined by the #dma-cells property in the node referenced by phandle? +- dma-names: Contains one identifier string for each dma specifier in + the dmas property. The specific strings that can be used + are defined in the binding of the DMA client device. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 00/10] pinctrl: mvebu: pinctrl driver
On 09/13/2012 09:41 AM, Sebastian Hesselbarth wrote: This patch set adds a core pinctrl driver for Marvell MVEBU SoCs and SoC specific stubs for Armada 370, Armada XP, Dove, and Kirkwood. The SoC specific stubs use the pinctrl-mvebu core driver that handles pinctrl API and register accesses for common pinctrl registers. As especially Dove has some pinctrl registers that do not match the common pinctrl register layout the core driver has been extended by some callbacks to allow uncommon Dove pinctrl registers. DT binding documentation is added for all supported SoCs but as Dove and Kirkwood are not yet ready for full DT support, the pinctrl driver is only activated for Armada 370 and XP. The driver of latest patch v4 has been tested on Dove, Armada 370, Armada XP, and 88f6281 variant of Kirkwood. The series, Reviewed-by: Stephen Warren swar...@wwwdotorg.org (Mainly the DT bindings and .dts file edits) In past versions of this series, we were had discussions about the best way to represent the data tables in the SoC-specific pinctrl drivers. I haven't actually looked at the current state in this patchset, but since this is an internal implementation detail and doesn't affect the DT bindings at all, I figure it's not a big deal right now; if it is ever a problem, it can be fixed without affecting anything outside the driver, so I won't worry about it:-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
On 09/14/2012 11:28 AM, Stephen Warren wrote: On 09/13/2012 04:00 PM, Jon Hunter wrote: This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt +* Generic DMA Controller and DMA request bindings + +Generic binding to provide a way for a driver using DMA Engine to retrieve the +DMA request or channel information that goes from a hardware device to a DMA +controller. + + +* DMA controller + +Required property: +- #dma-cells: Must be at least 1. Used to provide DMA controller +specific information. See DMA client binding below for ... +* DMA client + +Client drivers should specify the DMA property using a phandle to the controller +followed by DMA controller specific data. + +Required property: +- dmas: List of one or more DMA specifiers, each consisting of +- A phandle pointing to DMA controller node +- A single integer cell containing DMA controller + specific information. This typically contains a dma + request line number or a channel number, but can + contain any data that is used required for configuring + a channel. A single integer cell doesn't sound correct; shouldn't this be something like a number of integer cells, as determined by the #dma-cells property in the node referenced by phandle? Thanks for catching that. I had been re-working this a few times and must have forgotten to update that. Cheers Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V5 1/2] of: Add generic device tree DMA helpers
On 09/14/2012 10:26 AM, Arnd Bergmann wrote: On Friday 14 September 2012, Jon Hunter wrote: Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Benoit Cousson b-cous...@ti.com Cc: Stephen Warren swar...@nvidia.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Russell King li...@arm.linux.org.uk Cc: Rob Herring rob.herr...@calxeda.com Cc: Arnd Bergmann a...@arndb.de Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Signed-off-by: Jon Hunter jon-hun...@ti.com Reviewed-by: Arnd Bergmann a...@arndb.de Thanks for all this work, looks great! Thanks! My final (tiny) comment on this: +2. A single read-write channel with two alternative dma controllers: + +dmas = dma1 5 +dma2 7 +dma3 2; +dma-names = rx-tx, rx-tx, rx-tx *three* alternative dma controllers, not two. Oops! I have been starring at this so long I can no longer see the wood for the trees! Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 01/10] PCI: Keep pci_fixup_irqs() around after init
On Fri, Sep 07, 2012 at 10:22:28AM -0700, Bjorn Helgaas wrote: On Fri, Sep 7, 2012 at 10:00 AM, Thierry Reding thierry.red...@avionic-design.de wrote: On Fri, Sep 07, 2012 at 10:19:46AM -0600, Stephen Warren wrote: On 08/15/2012 01:42 PM, Bjorn Helgaas wrote: On Wed, Aug 15, 2012 at 1:28 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Wed, Aug 15, 2012 at 10:06:27AM -0700, Bjorn Helgaas wrote: On Thu, Jul 26, 2012 at 12:55 PM, Thierry Reding thierry.red...@avionic-design.de wrote: When using deferred driver probing, PCI host controller drivers may actually require this function after the init stage. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- Changes in v3: - none Changes in v2: - use __devinit annotations Your original patch removed __init completely. Here you change it to __devinit. That means we decide whether to discard the function based on whether CONFIG_HOTPLUG is supported. But I think your point is not about hotplug; it's merely that we should be able to scan a PCI bus after init-time. We ought to be able to do a late PCI scan even if hotplug is not supported. Therefore, I'd be inclined to remove __init completely unless you have another reason for preferring __devinit. I thought __devinit would resolve to nothing if HOTPLUG is defined and __init otherwise. That seemed more appropriate. However you are right that it is useful to always have it available, so I'm fine with removing the annotations altogether. Do you want me to follow up with a patch? Or can you just take the first version? I'm not sure if it still applies. You're right about how __devinit works. It's just that I don't think hotplug is actually relevant here. We're trying to make pci_fixup_irqs() work after init, whether it's because of hotplug or simply because the arch scans host bridges after init. I applied this to my next branch. Thanks! Bjorn, I don't see this patch in next-20120907. Did it get dropped for some reason? Yes, it turns out that dropping the annotations causes lots of section mismatches on other architectures. See here[0] for the details. I think the solution to the issue would be to either remove HOTPLUG altogether and drop __devinit and __devexit annotations or update all architectures to fix these warnings. I think Bjorn and I settled on the latter because it's obviously less intrusive. I've been busy building toolchains for all the PCI architectures and I think I have all of them. I'll just need some more time to build, find and fix any remaining section mismatches. Greg KH is actively removing CONFIG_HOTPLUG altogether -- see https://lkml.org/lkml/2012/9/4/489 That will make __devinit resolve to nothing in all cases, and we'll eventually remove __devinit completely. So we don't want to convert __init to __devinit; we have to remove the __init altogether. I think that means we have to update all arches first to avoid the section mismatches. So I think Thierry is on the right track: 1) Change all arch pcibios_update_irq() implementations (and probably a few other things) to be non-__init 2) Change pci_fixup_irqs() to be non-__init Okay this wasn't as much work as I had thought. It turns out that there very few dependencies other than pcibios_update_irq(). Actually none at all. In addition some of the architectures already had these annotated with __devinit. Luckily those were the ones I wasn't able to build a cross-compiler for. Note that I resolved to converting all annotations from __init to __devinit first. I'll try to find out what exactly Greg is planning to do. If it turns out that the plan is to just remove the __devinit incrementally I could just drop all of these. Otherwise maybe a better option would be to leave them in and remove them all at once when the HOTPLUG symbol is removed. Furthermore it seems like almost all implementations are the same, so I was going to include a patch that moves the common implementation to the PCI core and make it a weak symbol so architectures would still have the possibility to override it. The only exception to this is 64-bit SPARC, which apparently doesn't do anything in pcibios_update_irq(). I wonder if it would hurt to just use the generic implementation anyway, which just sets a byte in the configuration space. That should work regardless of architecture, right? Unicore32 and ARM also output a debugging message and maybe it would be okay to include that with the generic implementation as well. Do you have any objections? Thierry pgpkp73TMSzKV.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 01/10] PCI: Keep pci_fixup_irqs() around after init
On Fri, Sep 14, 2012 at 12:55 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Fri, Sep 07, 2012 at 10:22:28AM -0700, Bjorn Helgaas wrote: On Fri, Sep 7, 2012 at 10:00 AM, Thierry Reding thierry.red...@avionic-design.de wrote: On Fri, Sep 07, 2012 at 10:19:46AM -0600, Stephen Warren wrote: On 08/15/2012 01:42 PM, Bjorn Helgaas wrote: On Wed, Aug 15, 2012 at 1:28 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Wed, Aug 15, 2012 at 10:06:27AM -0700, Bjorn Helgaas wrote: On Thu, Jul 26, 2012 at 12:55 PM, Thierry Reding thierry.red...@avionic-design.de wrote: When using deferred driver probing, PCI host controller drivers may actually require this function after the init stage. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- Changes in v3: - none Changes in v2: - use __devinit annotations Your original patch removed __init completely. Here you change it to __devinit. That means we decide whether to discard the function based on whether CONFIG_HOTPLUG is supported. But I think your point is not about hotplug; it's merely that we should be able to scan a PCI bus after init-time. We ought to be able to do a late PCI scan even if hotplug is not supported. Therefore, I'd be inclined to remove __init completely unless you have another reason for preferring __devinit. I thought __devinit would resolve to nothing if HOTPLUG is defined and __init otherwise. That seemed more appropriate. However you are right that it is useful to always have it available, so I'm fine with removing the annotations altogether. Do you want me to follow up with a patch? Or can you just take the first version? I'm not sure if it still applies. You're right about how __devinit works. It's just that I don't think hotplug is actually relevant here. We're trying to make pci_fixup_irqs() work after init, whether it's because of hotplug or simply because the arch scans host bridges after init. I applied this to my next branch. Thanks! Bjorn, I don't see this patch in next-20120907. Did it get dropped for some reason? Yes, it turns out that dropping the annotations causes lots of section mismatches on other architectures. See here[0] for the details. I think the solution to the issue would be to either remove HOTPLUG altogether and drop __devinit and __devexit annotations or update all architectures to fix these warnings. I think Bjorn and I settled on the latter because it's obviously less intrusive. I've been busy building toolchains for all the PCI architectures and I think I have all of them. I'll just need some more time to build, find and fix any remaining section mismatches. Greg KH is actively removing CONFIG_HOTPLUG altogether -- see https://lkml.org/lkml/2012/9/4/489 That will make __devinit resolve to nothing in all cases, and we'll eventually remove __devinit completely. So we don't want to convert __init to __devinit; we have to remove the __init altogether. I think that means we have to update all arches first to avoid the section mismatches. So I think Thierry is on the right track: 1) Change all arch pcibios_update_irq() implementations (and probably a few other things) to be non-__init 2) Change pci_fixup_irqs() to be non-__init Okay this wasn't as much work as I had thought. It turns out that there very few dependencies other than pcibios_update_irq(). Actually none at all. In addition some of the architectures already had these annotated with __devinit. Luckily those were the ones I wasn't able to build a cross-compiler for. Note that I resolved to converting all annotations from __init to __devinit first. I'll try to find out what exactly Greg is planning to do. If it turns out that the plan is to just remove the __devinit incrementally I could just drop all of these. Otherwise maybe a better option would be to leave them in and remove them all at once when the HOTPLUG symbol is removed. Furthermore it seems like almost all implementations are the same, so I was going to include a patch that moves the common implementation to the PCI core and make it a weak symbol so architectures would still have the possibility to override it. The only exception to this is 64-bit SPARC, which apparently doesn't do anything in pcibios_update_irq(). I wonder if it would hurt to just use the generic implementation anyway, which just sets a byte in the configuration space. That should work regardless of architecture, right? Unicore32 and ARM also output a debugging message and maybe it would be okay to include that with the generic implementation as well. Do you have any objections? Sounds good to me. DaveM is really responsive -- if you propose using the generic implementation on SPARC, I bet he'd either ack it or tell you why SPARC needs to be special.
Re: [PATCH v2 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Fri, 14 Sep 2012 15:31:36 + Arnd Bergmann a...@arndb.de wrote: On Friday 14 September 2012, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. No further comments on this version besides the ones I already gave on v1. My linux-arm-kernel subscription died so I don't know what your v1 comments said. Were they fatal? ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Friday 14 September 2012, Andrew Morton wrote: On Fri, 14 Sep 2012 15:31:36 + Arnd Bergmann a...@arndb.de wrote: On Friday 14 September 2012, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. No further comments on this version besides the ones I already gave on v1. My linux-arm-kernel subscription died so I don't know what your v1 comments said. Were they fatal? Just details. AnilKumar just said in that thread that he'd do a version 3 based on the earlier discussion once I was done looking at v2, so I replied here to say that there is nothing new to add. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/5] Documentation: add description of DT binding for the gpio-mvebu driver
On 09/13/2012 09:54 AM, Thomas Petazzoni wrote:
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
+- #interrupt-cells: specifies the number of celles needed to encode an
+ interrupt source
s/celles/cells/
What value should this property contain for this driver, and what do
those cells mean?
This property is missing from the example below.
+ gpio0: gpio@d0018100 {
+ compatible = marvell,armadaxp-gpio;
+ reg = 0xd0018100 0x40,
+ 0xd0018800 0x30;
+ ngpios = 32;
+ gpio-controller;
+ #gpio-cells = 2;
+ interrupt-controller;
+ interrupts = 16, 17, 18, 19;
+ };
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 4/5] arm: mvebu: add DT information for GPIO banks on Armada 370 and XP
On 09/13/2012 09:54 AM, Thomas Petazzoni wrote: The gpioX aliases are needed so that the driver can use of_alias_get_id() to get a 0-based number of the GPIO bank, which we then use to compute the base GPIO of the bank being probed. This is similar to what gpio-mxs.c is doing. #interrupt-cells is missing from all the gpio nodes here too. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V6 0/2] of: Add generic device tree DMA helpers
Hi all, I apologise for sending out so many updates in quick succession before everyone has had chance to review, however, I will be out of office next week and I know that several people have been waiting for this. Normally, I would not send out a series and disappear for a week, but Arnd agreed to help while I am out. Arnd, Feel free to make any changes you see fit while I am out or correct any balls-up I have made! Cheers Jon This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic device-tree helpers to retrieve a DMA controller device_node and the DMA request/channel information. v6: - minor corrections in DMA binding documentation v5: - minor update to binding documentation - added loop to exhaustively search for a slave channel in the case where there could be alternative channels available v4: - revert the removal of xlate function from v3 - update the proposed binding format and APIs based upon discussions [3] v3: - avoid passing an xlate function and instead pass DMA engine parameters - define number of dma channels and requests in dma-controller node v2: - remove of_dma_to_resource API - make property #dma-cells required (no fallback anymore) - another check in of_dma_xlate_onenumbercell() function [1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022 [2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622 [3] http://marc.info/?l=linux-omapm=133582085008539w=2 Jon Hunter (2): of: Add generic device tree DMA helpers dmaengine: add helper function to request a slave DMA channel Documentation/devicetree/bindings/dma/dma.txt | 81 + drivers/dma/dmaengine.c | 16 ++ drivers/of/Makefile |2 +- drivers/of/dma.c | 219 + include/linux/dmaengine.h |6 + include/linux/of_dma.h| 45 + 6 files changed, 368 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/dma/dma.txt create mode 100644 drivers/of/dma.c create mode 100644 include/linux/of_dma.h -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel
Currently slave DMA channels are requested by calling dma_request_channel()
and requires DMA clients to pass various filter parameters to obtain the
appropriate channel.
With device-tree being used by architectures such as arm and the addition of
device-tree helper functions to extract the relevant DMA client information
from device-tree, add a new function to request a slave DMA channel using
device-tree. This function is currently a simple wrapper that calls the
device-tree of_dma_request_slave_channel() function.
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/dma/dmaengine.c | 16
include/linux/dmaengine.h |6 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 3491654..9b466da 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -62,6 +62,7 @@
#include linux/rculist.h
#include linux/idr.h
#include linux/slab.h
+#include linux/of_dma.h
static DEFINE_MUTEX(dma_list_mutex);
static DEFINE_IDR(dma_idr);
@@ -546,6 +547,21 @@ struct dma_chan *__dma_request_channel(dma_cap_mask_t
*mask, dma_filter_fn fn, v
}
EXPORT_SYMBOL_GPL(__dma_request_channel);
+/**
+ * dma_request_slave_channel - try to allocate an exclusive slave channel
+ * @dev: pointer to client device structure
+ * @name: slave channel name
+ */
+struct dma_chan *dma_request_slave_channel(struct device *dev, char *name)
+{
+ /* If device-tree is present get slave info from here */
+ if (dev-of_node)
+ return of_dma_request_slave_channel(dev-of_node, name);
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(dma_request_slave_channel);
+
void dma_release_channel(struct dma_chan *chan)
{
mutex_lock(dma_list_mutex);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9c02a45..9500aa5 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -973,6 +973,7 @@ enum dma_status dma_sync_wait(struct dma_chan *chan,
dma_cookie_t cookie);
enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
void dma_issue_pending_all(void);
struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn,
void *fn_param);
+struct dma_chan *dma_request_slave_channel(struct device *dev, char *name);
void dma_release_channel(struct dma_chan *chan);
#else
static inline enum dma_status dma_wait_for_async_tx(struct
dma_async_tx_descriptor *tx)
@@ -987,6 +988,11 @@ static inline struct dma_chan
*__dma_request_channel(dma_cap_mask_t *mask,
{
return NULL;
}
+static inline struct dma_chan *dma_request_slave_channel(struct device *dev,
+char *name)
+{
+ return NULL
+}
static inline void dma_release_channel(struct dma_chan *chan)
{
}
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V6 1/2] of: Add generic device tree DMA helpers
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
Thinking about DMA controllers purely from the context of the hardware to
begin with, we can describe a device in terms of a DMA controller as
follows ...
1. Number of DMA controllers
2. Number of channels (maybe physical or logical)
3. Mapping of DMA requests signals to DMA controller
4. Number of DMA interrupts
5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to extract
the above information from the DT and provide to the appropriate driver.
However, due to the vast number of DMA controllers and not all are using a
common driver (such as DMA Engine) it has been seen that this is not a
trivial task. In previous discussions on this topic the following concerns
have been raised ...
1. How does the binding support devices with multiple DMA controllers?
2. How to support both legacy DMA controllers not using DMA Engine as
well as those that support DMA Engine.
3. When using with DMA Engine how do we support the various
implementations where the opaque filter function parameter differs
between implementations?
4. How do we handle DMA channels that are identified with a string
versus a integer?
- Hence the design of the DMA helpers has to accomodate the above or align on
an agreement what can be or should be supported.
Design of DMA helpers
1. Registering DMA controllers
In the case of DMA controllers that are using DMA Engine, requesting a
channel is performed by calling the following function.
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
dma_filter_fn filter_fn,
void *filter_param);
The mask variable is used to match a type of the device controller in a list
of controllers. The filter_fn and filter_param are used to identify the
required dma channel and return a handle to the dma channel of type dma_chan.
From the examples I have seen, the mask and filter_fn are constant
for a given DMA controller and therefore, we can specify these as controller
specific data when registering the DMA controller with the device-tree DMA
helpers.
The filter_param variable is of an unknown type and is typically specific
to the DMA engine implementation for a given DMA controller. To allow some
flexibility in the type and formating of this filter_param we employ an
xlate to translate the device-tree binding information into the appropriate
format. The xlate function used for a DMA controller can also be specified
when registering the DMA controller with the device-tree DMA helpers.
Based upon the above, a function for registering the DMA controller with the
DMA helpers now looks like the below. The data variable is used to pass a
pointer to DMA controller specific data used by the xlate function.
int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data)
For example, in the case where DMA engine is used, we define the following
structure (that stores the DMA engine capability mask and filter function)
and pass this to the data variable in the above function.
struct of_dma_filter_info {
dma_cap_mask_t dma_cap;
dma_filter_fn filter_fn;
};
2. Representing and requesting channel information
Please see the dma binding documentation included in this patch for a
description of how DMA controllers and client information should be
represented with device-tree. For more information on how this binding
came about please see [3]. In addition to this, feedback received from
the Linux kernel summit showed a consensus (among those who attended) to
use a name to identify DMA client information [4].
A DMA channel can be requested by calling the following function, where name
is a required parameter used for identifying a DMA channel. This function
has been designed to return a structure of type dma_chan to work with the
DMA engine driver. Note that if DMA engine is used then drivers should be
using the DMA engine API dma_request_slave_channel() (implemented in part 2
of this series, dmaengine: add helper function to request a slave DMA
channel) which will in turn call the below function if device-tree is
present. The aim being to have a common DMA engine interface regardless of
whether device tree is being used.
struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers
On 09/14/2012 04:41 PM, Jon Hunter wrote: This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. The binding looks good to me now, so, Reviewed-by: Stephen Warren swar...@wwwdotorg.org ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/5] Documentation: add description of DT binding for the gpio-mvebu driver
On Fri, Sep 14, 2012 at 04:54:08PM +0200, Thomas Petazzoni wrote: Dear Linus Walleij, On Fri, 14 Sep 2012 15:17:09 +0200, Linus Walleij wrote: Yes, I know, but MAINTAINERS does not mention an alternate maintainer for the GPIO subsystem. Who is the interim maintainer that will ultimately have to ack/nack those patches? Linus W. is. I stated Reviewed-by: on the GPIO patch, please merge it through the Marvell tree (I guess that's the plan?) Yes, I guess it's the easiest plan (Jason ? Andrew ?). We however need Acks on the pinctrl patch series as well, since this one depends on it. Yes, that's the plan. I'm currently waiting for my previous series of pull requests to get pulled before I start pulling in anything else. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: 3. Supporting legacy devices not using DMA Engine These devices present a problem, as there may not be a uniform way to easily support them with regard to device tree. Ideally, these should be migrated to DMA engine. However, if this is not possible, then they should still be able to use this binding, the only constaint imposed by this implementation is that when requesting a DMA channel via of_dma_request_slave_channel(), it will return a type of dma_chan. As far as devices not using DMA engine, the answer is we don't support their specification in the DT model. Note that the legacy OMAP DMA API is scheduled for removal next year, so it's not going to be around that much longer. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 1/2] hwmon: Add devicetree bindings to gpio-fan
On Fri, Sep 14, 2012 at 07:28:33PM -0700, Guenter Roeck wrote: On Fri, Sep 14, 2012 at 05:07:06PM +0100, Jamie Lentin wrote: Allow a gpio-fan to be defined in devicetree, see binding documentation for details. Signed-off-by: Jamie Lentin j...@lentin.co.uk Acked-by: Andrew Lunn and...@lunn.ch Acked-by: Guenter Roeck li...@roeck-us.net I take it this will go through the arm tree ? Yes, unless there is an objection. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
