* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-08 21:26 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <20101208142551.19ea2333@udp111988uds.am.freescale.net>
Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 21:25:51:
>
> On Wed, 8 Dec 2010 21:11:08 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 20:59:28:
> > >
> > > On Wed, 8 Dec 2010 20:57:03 +0100
> > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > >
> > > > Can you think of any workaround such as not connecting the BUSY pin at all?
> > >
> > > Maybe connect the busy pin to a gpio?
> >
> > Is BUSY required for sane operation or it an optimization?
>
> You could probably get away without it by inserting delays if you know
> the chip specs well enough.
Urgh, that does not feel like a good solution. One would have add
big margins to the delays mking the NAND much slower.
>
> > Is there any risk that the NAND device will drive the LB and corrupt
> > the bus for other devices?
>
> I think the only thing the NAND chip should be driving is the busy pin,
OK, good. What function is actually lost if one uses an GPIO instead of
BUSY?
You think Freescale could test and validate a GPIO solution? I don't
think we will be very happy to design our board around an unproven
workaround.
An even better workaround would be if one could add logic between the
NAND and the CPU which would compensate for this defect without needing
special SW fixes.
^ permalink raw reply
* Re: [PATCH 3/5] of/device: Make of_get_next_child() check status properties
From: Scott Wood @ 2010-12-08 21:01 UTC (permalink / raw)
To: Deepak Saxena; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20101208192944.GE32473@mentor.com>
On Wed, 8 Dec 2010 11:29:44 -0800
Deepak Saxena <deepak_saxena@mentor.com> wrote:
> We only return the next child if the device is available.
>
> Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
> Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
> ---
> drivers/of/base.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 5d269a4..81b2601 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -321,6 +321,8 @@ struct device_node *of_get_next_parent(struct device_node *node)
> *
> * Returns a node pointer with refcount incremented, use
> * of_node_put() on it when done.
> + *
> + * Does not return nodes marked unavailable by a status property.
> */
> struct device_node *of_get_next_child(const struct device_node *node,
> struct device_node *prev)
> @@ -330,7 +332,7 @@ struct device_node *of_get_next_child(const struct device_node *node,
> read_lock(&devtree_lock);
> next = prev ? prev->sibling : node->child;
> for (; next; next = next->sibling)
> - if (of_node_get(next))
> + if (of_device_is_available(next) && of_node_get(next))
> break;
> of_node_put(prev);
> read_unlock(&devtree_lock);
This seems like too low-level a place to put this. Some code may know
how to un-disable a device in certain situations, or it may be part of
debug code trying to dump the whole device tree, etc. Looking
further[1], I see a raw version of this function, but not other things
like of_find_compatible_node.
Could this be done more othogonally, so that the caller specifies in a
parameter whether to skip based on status?
-Scott
[1] For some reason I received some of these patches from
linuxppc-dev, and others from devicetree-discuss. I wish lists
wouldn't try to be "smart" about discarding duplicates -- it messes with
filters.
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-08 20:25 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <OFC37E86C9.59866BED-ONC12577F3.006E8F8D-C12577F3.006EE1FA@transmode.se>
On Wed, 8 Dec 2010 21:11:08 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 20:59:28:
> >
> > On Wed, 8 Dec 2010 20:57:03 +0100
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > > Can you think of any workaround such as not connecting the BUSY pin at all?
> >
> > Maybe connect the busy pin to a gpio?
>
> Is BUSY required for sane operation or it an optimization?
You could probably get away without it by inserting delays if you know
the chip specs well enough.
> Is there any risk that the NAND device will drive the LB and corrupt
> the bus for other devices?
I think the only thing the NAND chip should be driving is the busy pin,
until nCE and nRE are lowered.
-Scott
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-08 20:11 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <20101208135928.0278f97d@udp111988uds.am.freescale.net>
Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 20:59:28:
>
> On Wed, 8 Dec 2010 20:57:03 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > Mark Mason <mason@postdiluvian.org> wrote on 2010/12/08 20:26:16:
> > >
> > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > >
> > > > Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 18:18:39:
> > > > >
> > > > > On Wed, 8 Dec 2010 08:59:49 +0100
> > > > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > > >
> > > > > > > If you attach NAND to the LBC, you should not attach anything else to
> > > > > > > it which is latency-sensitive.
> > > > > >
> > > > > > This "feature" makes the LBC useless to us. Is there some workaround or plan
> > > > > > to address this limitation?
> > > > >
> > > > > Complain to your support or sales contact.
> > > > >
> > > > > I've complained about it in the past, and got a "but pins are a limited
> > > > > resource!" response. They need to hear that it's a problem from
> > > > > customers.
> > > >
> > > > Done, lets see what I get in return. I think this problem will be
> > > > a major obstacle for our next generation boards which will be NAND
> > > > based.
> > >
> > > It was a big problem, and a big surprise, for me too. The next
> > > generation of a couple of the chips on the bus have pcie, but those
> > > are noticably more expensive.
> >
> > Can you think of any workaround such as not connecting the BUSY pin at all?
>
> Maybe connect the busy pin to a gpio?
Is BUSY required for sane operation or it an optimization?
Is there any risk that the NAND device will drive the LB and corrupt
the bus for other devices?
I can't tell, haven't studied NAND in detail yet.
Jocke
^ permalink raw reply
* [PATCH 3/5] of/device: Make of_get_next_child() check status properties
From: Deepak Saxena @ 2010-12-08 19:29 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
In-Reply-To: <cover.1291799069.git.deepak_saxena@mentor.com>
We only return the next child if the device is available.
Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
---
drivers/of/base.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5d269a4..81b2601 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -321,6 +321,8 @@ struct device_node *of_get_next_parent(struct device_node *node)
*
* Returns a node pointer with refcount incremented, use
* of_node_put() on it when done.
+ *
+ * Does not return nodes marked unavailable by a status property.
*/
struct device_node *of_get_next_child(const struct device_node *node,
struct device_node *prev)
@@ -330,7 +332,7 @@ struct device_node *of_get_next_child(const struct device_node *node,
read_lock(&devtree_lock);
next = prev ? prev->sibling : node->child;
for (; next; next = next->sibling)
- if (of_node_get(next))
+ if (of_device_is_available(next) && of_node_get(next))
break;
of_node_put(prev);
read_unlock(&devtree_lock);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 4/5] of/device: Create _of_get_next_child()
From: Deepak Saxena @ 2010-12-08 19:29 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
In-Reply-To: <cover.1291799069.git.deepak_saxena@mentor.com>
There aren't many, but some of_get_next_child() callers do need an unabridged
view of the device tree so we provide a wrapper that can be used by them.
Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
---
drivers/of/base.c | 26 ++++++++++++++++++++++++++
include/linux/of.h | 2 ++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 81b2601..7bc1398 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -315,6 +315,32 @@ struct device_node *of_get_next_parent(struct device_node *node)
}
/**
+ * _of_get_next_child - Iterate a node childs
+ * @node: parent node
+ * @prev: previous child of the parent node, or NULL to get first
+ *
+ * Returns a node pointer with refcount incremented, use
+ * of_node_put() on it when done.
+ *
+ * Unlike most other node accessors, ignores status properties.
+ */
+struct device_node *_of_get_next_child(const struct device_node *node,
+ struct device_node *prev)
+{
+ struct device_node *next;
+
+ read_lock(&devtree_lock);
+ next = prev ? prev->sibling : node->child;
+ for (; next; next = next->sibling)
+ if (of_device_is_available(next) && of_node_get(next))
+ break;
+ of_node_put(prev);
+ read_unlock(&devtree_lock);
+ return next;
+}
+EXPORT_SYMBOL(_of_get_next_child);
+
+/**
* of_get_next_child - Iterate a node childs
* @node: parent node
* @prev: previous child of the parent node, or NULL to get first
diff --git a/include/linux/of.h b/include/linux/of.h
index cad7cf0..1fea01d 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -175,6 +175,8 @@ extern struct device_node *of_find_node_by_path(const char *path);
extern struct device_node *of_find_node_by_phandle(phandle handle);
extern struct device_node *of_get_parent(const struct device_node *node);
extern struct device_node *of_get_next_parent(struct device_node *node);
+extern struct device_node *_of_get_next_child(const struct device_node *node,
+ struct device_node *prev);
extern struct device_node *of_get_next_child(const struct device_node *node,
struct device_node *prev);
#define for_each_child_of_node(parent, child) \
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/5] Hide devices with non-available status from kernel
From: Deepak Saxena @ 2010-12-08 19:29 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
Device tree nodes can have a "status" property that is currently checked
for in several places in the kernel. This patch set centralizes handling
of the property and simply does not call a driver's probe() function
if a device is not available. This is of particular use in environments
where we may want to hide certain devices, for example, a multi-core
AMP environment where we are partitioning the system. The patchset
exposes all the devices in the system in /proc as that is a useful
debug tool to have in case the bootloader or user does something wrong.
Deepak Saxena (5):
of/device: Centralize checking of 'status' properties
of/device: make for_each_node* check status properties
of/device: Make of_get_next_child() check status properties
of/device: Create _of_get_next_child()
of/device: Show even unavailable nodes in procfs
arch/powerpc/kernel/pci_of_scan.c | 2 -
arch/powerpc/platforms/83xx/suspend.c | 3 --
arch/powerpc/platforms/83xx/usb.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 13 +------
arch/powerpc/sysdev/fsl_pci.c | 5 ---
arch/powerpc/sysdev/ppc4xx_pci.c | 15 --------
drivers/mmc/host/sdhci-of-core.c | 3 --
drivers/net/gianfar.c | 2 +-
drivers/net/ibm_newemac/core.c | 2 +-
drivers/of/base.c | 55 +++++++++++++++++++++++++++--
drivers/of/platform.c | 7 +++-
fs/proc/proc_devtree.c | 2 +-
include/linux/of.h | 2 +
13 files changed, 65 insertions(+), 48 deletions(-)
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-08 19:59 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <OF14047E09.664EC753-ONC12577F3.006CF507-C12577F3.006D97EA@transmode.se>
On Wed, 8 Dec 2010 20:57:03 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Mark Mason <mason@postdiluvian.org> wrote on 2010/12/08 20:26:16:
> >
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > > Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 18:18:39:
> > > >
> > > > On Wed, 8 Dec 2010 08:59:49 +0100
> > > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > >
> > > > > > If you attach NAND to the LBC, you should not attach anything else to
> > > > > > it which is latency-sensitive.
> > > > >
> > > > > This "feature" makes the LBC useless to us. Is there some workaround or plan
> > > > > to address this limitation?
> > > >
> > > > Complain to your support or sales contact.
> > > >
> > > > I've complained about it in the past, and got a "but pins are a limited
> > > > resource!" response. They need to hear that it's a problem from
> > > > customers.
> > >
> > > Done, lets see what I get in return. I think this problem will be
> > > a major obstacle for our next generation boards which will be NAND
> > > based.
> >
> > It was a big problem, and a big surprise, for me too. The next
> > generation of a couple of the chips on the bus have pcie, but those
> > are noticably more expensive.
>
> Can you think of any workaround such as not connecting the BUSY pin at all?
Maybe connect the busy pin to a gpio?
-Scott
^ permalink raw reply
* [PATCH 2/5] of/device: make for_each_node* check status properties
From: Deepak Saxena @ 2010-12-08 19:29 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
In-Reply-To: <cover.1291799069.git.deepak_saxena@mentor.com>
Some early device drivers don't actually implement a struct of_platform_driver,
and instead use the for_each_node* iterators to search for matching device
nodes. Disabled device nodes will no longer be returned by these iterators.
Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
---
arch/powerpc/kernel/pci_of_scan.c | 2 --
arch/powerpc/platforms/83xx/usb.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 13 ++-----------
arch/powerpc/sysdev/fsl_pci.c | 5 -----
arch/powerpc/sysdev/ppc4xx_pci.c | 15 ---------------
drivers/of/base.c | 25 +++++++++++++++++++++++--
6 files changed, 26 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index e751506..fa4f719 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -310,8 +310,6 @@ static void __devinit __of_scan_bus(struct device_node *node,
/* Scan direct children */
for_each_child_of_node(node, child) {
pr_debug(" * %s\n", child->full_name);
- if (!of_device_is_available(child))
- continue;
reg = of_get_property(child, "reg", ®len);
if (reg == NULL || reglen < 20)
continue;
diff --git a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/platforms/83xx/usb.c
index 3ba4bb7..749c70b 100644
--- a/arch/powerpc/platforms/83xx/usb.c
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -211,7 +211,7 @@ int mpc837x_usb_cfg(void)
int ret = 0;
np = of_find_compatible_node(NULL, NULL, "fsl-usb2-dr");
- if (!np || !of_device_is_available(np))
+ if (!np)
return -ENODEV;
prop = of_get_property(np, "phy_type", NULL);
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index aa34cac..5d1a33f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -170,10 +170,8 @@ static void __init mpc85xx_publish_qe_devices(void)
struct device_node *np;
np = of_find_compatible_node(NULL, NULL, "fsl,qe");
- if (!of_device_is_available(np)) {
- of_node_put(np);
+ if (!np)
return;
- }
of_platform_bus_probe(NULL, mpc85xx_qe_ids, NULL);
}
@@ -267,11 +265,6 @@ static void __init mpc85xx_mds_qe_init(void)
return;
}
- if (!of_device_is_available(np)) {
- of_node_put(np);
- return;
- }
-
qe_reset();
of_node_put(np);
@@ -328,10 +321,8 @@ static void __init mpc85xx_mds_qeic_init(void)
struct device_node *np;
np = of_find_compatible_node(NULL, NULL, "fsl,qe");
- if (!of_device_is_available(np)) {
- of_node_put(np);
+ if (!np)
return;
- }
np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
if (!np) {
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 818f7c6..fba4ec7 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -623,11 +623,6 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
is_mpc83xx_pci = 1;
- if (!of_device_is_available(dev)) {
- pr_warning("%s: disabled by the firmware.\n",
- dev->full_name);
- return -ENODEV;
- }
pr_debug("Adding PCI host bridge %s\n", dev->full_name);
/* Fetch host bridge registers address */
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 156aa7d..cf2adec 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -321,13 +321,6 @@ static void __init ppc4xx_probe_pci_bridge(struct device_node *np)
const int *bus_range;
int primary = 0;
- /* Check if device is enabled */
- if (!of_device_is_available(np)) {
- printk(KERN_INFO "%s: Port disabled via device-tree\n",
- np->full_name);
- return;
- }
-
/* Fetch config space registers address */
if (of_address_to_resource(np, 0, &rsrc_cfg)) {
printk(KERN_ERR "%s: Can't get PCI config register base !",
@@ -1890,14 +1883,6 @@ static void __init ppc4xx_probe_pciex_bridge(struct device_node *np)
port = &ppc4xx_pciex_ports[portno];
port->index = portno;
- /*
- * Check if device is enabled
- */
- if (!of_device_is_available(np)) {
- printk(KERN_INFO "PCIE%d: Port disabled via device-tree\n", port->index);
- return;
- }
-
port->node = of_node_get(np);
pval = of_get_property(np, "sdr-base", NULL);
if (pval == NULL) {
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 710b53b..5d269a4 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -344,6 +344,8 @@ EXPORT_SYMBOL(of_get_next_child);
*
* Returns a node pointer with refcount incremented, use
* of_node_put() on it when done.
+ *
+ * Does not return nodes marked unavailable by a status property.
*/
struct device_node *of_find_node_by_path(const char *path)
{
@@ -352,6 +354,7 @@ struct device_node *of_find_node_by_path(const char *path)
read_lock(&devtree_lock);
for (; np; np = np->allnext) {
if (np->full_name && (of_node_cmp(np->full_name, path) == 0)
+ && of_device_is_available(np)
&& of_node_get(np))
break;
}
@@ -370,6 +373,8 @@ EXPORT_SYMBOL(of_find_node_by_path);
*
* Returns a node pointer with refcount incremented, use
* of_node_put() on it when done.
+ *
+ * Does not return nodes marked unavailable by a status property.
*/
struct device_node *of_find_node_by_name(struct device_node *from,
const char *name)
@@ -380,6 +385,7 @@ struct device_node *of_find_node_by_name(struct device_node *from,
np = from ? from->allnext : allnodes;
for (; np; np = np->allnext)
if (np->name && (of_node_cmp(np->name, name) == 0)
+ && of_device_is_available(np)
&& of_node_get(np))
break;
of_node_put(from);
@@ -399,6 +405,8 @@ EXPORT_SYMBOL(of_find_node_by_name);
*
* Returns a node pointer with refcount incremented, use
* of_node_put() on it when done.
+ *
+ * Does not return nodes marked unavailable by a status property.
*/
struct device_node *of_find_node_by_type(struct device_node *from,
const char *type)
@@ -409,6 +417,7 @@ struct device_node *of_find_node_by_type(struct device_node *from,
np = from ? from->allnext : allnodes;
for (; np; np = np->allnext)
if (np->type && (of_node_cmp(np->type, type) == 0)
+ && of_device_is_available(np)
&& of_node_get(np))
break;
of_node_put(from);
@@ -430,6 +439,8 @@ EXPORT_SYMBOL(of_find_node_by_type);
*
* Returns a node pointer with refcount incremented, use
* of_node_put() on it when done.
+ *
+ * Does not return nodes marked unavailable by a status property.
*/
struct device_node *of_find_compatible_node(struct device_node *from,
const char *type, const char *compatible)
@@ -442,7 +453,9 @@ struct device_node *of_find_compatible_node(struct device_node *from,
if (type
&& !(np->type && (of_node_cmp(np->type, type) == 0)))
continue;
- if (of_device_is_compatible(np, compatible) && of_node_get(np))
+ if (of_device_is_compatible(np, compatible)
+ && of_device_is_available(np)
+ && of_node_get(np))
break;
}
of_node_put(from);
@@ -462,6 +475,8 @@ EXPORT_SYMBOL(of_find_compatible_node);
*
* Returns a node pointer with refcount incremented, use
* of_node_put() on it when done.
+ *
+ * Does not return nodes marked unavailable by a status property.
*/
struct device_node *of_find_node_with_property(struct device_node *from,
const char *prop_name)
@@ -472,6 +487,8 @@ struct device_node *of_find_node_with_property(struct device_node *from,
read_lock(&devtree_lock);
np = from ? from->allnext : allnodes;
for (; np; np = np->allnext) {
+ if (!of_device_is_available(np))
+ continue;
for (pp = np->properties; pp != 0; pp = pp->next) {
if (of_prop_cmp(pp->name, prop_name) == 0) {
of_node_get(np);
@@ -526,6 +543,8 @@ EXPORT_SYMBOL(of_match_node);
*
* Returns a node pointer with refcount incremented, use
* of_node_put() on it when done.
+ *
+ * Does not return nodes marked unavailable by a status property.
*/
struct device_node *of_find_matching_node(struct device_node *from,
const struct of_device_id *matches)
@@ -535,7 +554,9 @@ struct device_node *of_find_matching_node(struct device_node *from,
read_lock(&devtree_lock);
np = from ? from->allnext : allnodes;
for (; np; np = np->allnext) {
- if (of_match_node(matches, np) && of_node_get(np))
+ if (of_match_node(matches, np)
+ && of_device_is_available(np)
+ && of_node_get(np))
break;
}
of_node_put(from);
--
1.6.3.3
^ permalink raw reply related
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-08 19:57 UTC (permalink / raw)
To: Mark Mason; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20101208192616.GA24560@postdiluvian.org>
Mark Mason <mason@postdiluvian.org> wrote on 2010/12/08 20:26:16:
>
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 18:18:39:
> > >
> > > On Wed, 8 Dec 2010 08:59:49 +0100
> > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > >
> > > > >
> > > > > On Mon, 6 Dec 2010 22:15:54 -0500
> > > > > Mark Mason <mason@postdiluvian.org> wrote:
> > > > >
> > > > > > A few months ago I ran into some performance problems involving
> > > > > > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > > > > > found a solution for this, which worked well, at least with the
> > > > > > hardware I was working with. I suspect the same problem affects other
> > > > > > PPCs, probably including multicore devices, and maybe other
> > > > > > architectures as well.
> > > > > >
> > > > > > I don't have experience with similar NAND controllers on other
> > > > > > devices, so I'd like to explain what I found and see if someone who's
> > > > > > more familiar with the family and/or driver can tell if this is
> > > > > > useful.
> > > > > >
> > > > > > The problem cropped up when there was a lot of traffic to the NAND
> > > > > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > > > > a video chip that needed constant and prompt attention.
> > > > >
> > > > > If you attach NAND to the LBC, you should not attach anything else to
> > > > > it which is latency-sensitive.
> > > >
> > > > This "feature" makes the LBC useless to us. Is there some workaround or plan
> > > > to address this limitation?
> > >
> > > Complain to your support or sales contact.
> > >
> > > I've complained about it in the past, and got a "but pins are a limited
> > > resource!" response. They need to hear that it's a problem from
> > > customers.
> >
> > Done, lets see what I get in return. I think this problem will be
> > a major obstacle for our next generation boards which will be NAND
> > based.
>
> It was a big problem, and a big surprise, for me too. The next
> generation of a couple of the chips on the bus have pcie, but those
> are noticably more expensive.
Can you think of any workaround such as not connecting the BUSY pin at all?
^ permalink raw reply
* [PATCH 1/5] of/device: Centralize checking of 'status' properties
From: Deepak Saxena @ 2010-12-08 19:29 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
In-Reply-To: <cover.1291799069.git.deepak_saxena@mentor.com>
Don't call any of_platform_driver's probe() function if the device node is
not accessible (as denoted in the status property).
Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
---
arch/powerpc/platforms/83xx/suspend.c | 3 ---
drivers/mmc/host/sdhci-of-core.c | 3 ---
drivers/net/gianfar.c | 2 +-
drivers/net/ibm_newemac/core.c | 2 +-
drivers/of/platform.c | 7 +++++--
5 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/suspend.c b/arch/powerpc/platforms/83xx/suspend.c
index 75ae77f..a5a54aa 100644
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -326,9 +326,6 @@ static int pmc_probe(struct platform_device *ofdev,
struct pmc_type *type = match->data;
int ret = 0;
- if (!of_device_is_available(np))
- return -ENODEV;
-
has_deep_sleep = type->has_deep_sleep;
immrbase = get_immrbase();
pmc_dev = ofdev;
diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index c51b711..51218d4 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -126,9 +126,6 @@ static int __devinit sdhci_of_probe(struct platform_device *ofdev,
int size;
int ret;
- if (!of_device_is_available(np))
- return -ENODEV;
-
host = sdhci_alloc_host(&ofdev->dev, sizeof(*of_host));
if (IS_ERR(host))
return -ENOMEM;
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index d1bec62..9918914 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -620,7 +620,7 @@ static int gfar_of_init(struct platform_device *ofdev, struct net_device **pdev)
unsigned int num_tx_qs, num_rx_qs;
u32 *tx_queues, *rx_queues;
- if (!np || !of_device_is_available(np))
+ if (!np)
return -ENODEV;
/* parse the num of tx and rx queues */
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 06bb9b7..290fff2 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2732,7 +2732,7 @@ static int __devinit emac_probe(struct platform_device *ofdev,
* property here for now, but new flat device trees should set a
* status property to "disabled" instead.
*/
- if (of_get_property(np, "unused", NULL) || !of_device_is_available(np))
+ if (of_get_property(np, "unused", NULL))
return -ENODEV;
/* Find ourselves in the bootlist if we are there */
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 5b4a07f..14370a0 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -56,7 +56,10 @@ static int platform_driver_probe_shim(struct platform_device *pdev)
* come up empty. Return -EINVAL in this case so other drivers get
* the chance to bind. */
match = of_match_device(pdev->dev.driver->of_match_table, &pdev->dev);
- return match ? ofpdrv->probe(pdev, match) : -EINVAL;
+ if (match && of_device_is_available(pdev->dev.of_node))
+ return ofpdrv->probe(pdev, match);
+
+ return -EINVAL;
}
static void platform_driver_shutdown_shim(struct platform_device *pdev)
@@ -142,7 +145,7 @@ static int of_platform_device_probe(struct device *dev)
of_dev_get(of_dev);
match = of_match_device(drv->driver.of_match_table, dev);
- if (match)
+ if (match && of_device_is_available(dev->of_node))
error = drv->probe(of_dev, match);
if (error)
of_dev_put(of_dev);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 5/5] of/device: Show even unavailable nodes in procfs
From: Deepak Saxena @ 2010-12-08 19:29 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
In-Reply-To: <cover.1291799069.git.deepak_saxena@mentor.com>
Use the new "raw" of_get_next_child() variant so all device tree nodes
will appear in procfs.
Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
---
fs/proc/proc_devtree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/proc/proc_devtree.c b/fs/proc/proc_devtree.c
index d9396a4..aa914eb 100644
--- a/fs/proc/proc_devtree.c
+++ b/fs/proc/proc_devtree.c
@@ -188,7 +188,7 @@ void proc_device_tree_add_node(struct device_node *np,
const char *p;
set_node_proc_entry(np, de);
- for (child = NULL; (child = of_get_next_child(np, child));) {
+ for (child = NULL; (child = _of_get_next_child(np, child));) {
/* Use everything after the last slash, or the full name */
p = strrchr(child->full_name, '/');
if (!p)
--
1.6.3.3
^ permalink raw reply related
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Joachim Förster @ 2010-12-08 19:20 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <1291815910.12093.15.camel@concordia>
Hi Guillaume,
Michael Ellerman wrote:
> On Wed, 2010-12-08 at 11:18 +0100, Guillaume Dargaud wrote:
>> ///////////////////////////////////////////////////////////////////////////////
>> // Called on insmod
>> static int __init xad_init(void) {
>> int rc=0;
>> printk(KERN_INFO SD "Module %s: loading...\n" FL, NAME);
>>
Are you sure that you want to have the chrdev registration here (the
following code)?
Such stuff typically goes into the probe() function. The modules's
init() just registers the driver. Furthermore your global variables
prohibit having more than one device instance using the driver.
>> // Deal with the device
>> first = MKDEV (my_major, my_minor);
>> register_chrdev_region(first, count, DEVNAME);
>> my_cdev = cdev_alloc ();
>> if (NULL==my_cdev) goto Err;
>>
>> cdev_init(my_cdev, &fops);
>> cdev_add (my_cdev, first, count);
>>
>> printk(KERN_INFO SD "Module %s: Major=%d, Minor=%d, Count=%d\n" FL, NAME,
>> my_major, my_minor, count);
>>
>> // Driver
>> rc = platform_driver_register(&xad_driver);
>
> Should be of_register_platform_driver()
>
>> // rc = platform_driver_probe(&xad_driver, xad_driver_probe);
>> if (rc) goto err_plat;
>>
I think the following function call to platform_device_register_simple()
and if() does not belong here.
As was said before, "devices" are registered by the (platform) bus. Your
driver module, needs to just register, well, the "driver". You are doing
this above - and that's it: (of_)platform_driver_register().
>> // Device
>> pdev=platform_device_register_simple("xps-acqui-data", -1, NULL, 0);
>> if (IS_ERR(pdev)) {
>> rc = PTR_ERR(pdev);
>> platform_driver_unregister(&xad_driver);
>> goto err_plat;
>> }
>>
>>
>> return 0;
>>
>> err_plat:
>> unregister_chrdev_region(first, count);
>> Err:
>> printk(KERN_ERR SD "Module %s: Failed loading rc=%d\n" FL, NAME, rc);
>> return rc;
>> }
Joachim
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Mark Mason @ 2010-12-08 19:26 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <OF349DC945.8BC48D34-ONC12577F3.00601D94-C12577F3.00605153@transmode.se>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 18:18:39:
> >
> > On Wed, 8 Dec 2010 08:59:49 +0100
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > > >
> > > > On Mon, 6 Dec 2010 22:15:54 -0500
> > > > Mark Mason <mason@postdiluvian.org> wrote:
> > > >
> > > > > A few months ago I ran into some performance problems involving
> > > > > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > > > > found a solution for this, which worked well, at least with the
> > > > > hardware I was working with. I suspect the same problem affects other
> > > > > PPCs, probably including multicore devices, and maybe other
> > > > > architectures as well.
> > > > >
> > > > > I don't have experience with similar NAND controllers on other
> > > > > devices, so I'd like to explain what I found and see if someone who's
> > > > > more familiar with the family and/or driver can tell if this is
> > > > > useful.
> > > > >
> > > > > The problem cropped up when there was a lot of traffic to the NAND
> > > > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > > > a video chip that needed constant and prompt attention.
> > > >
> > > > If you attach NAND to the LBC, you should not attach anything else to
> > > > it which is latency-sensitive.
> > >
> > > This "feature" makes the LBC useless to us. Is there some workaround or plan
> > > to address this limitation?
> >
> > Complain to your support or sales contact.
> >
> > I've complained about it in the past, and got a "but pins are a limited
> > resource!" response. They need to hear that it's a problem from
> > customers.
>
> Done, lets see what I get in return. I think this problem will be
> a major obstacle for our next generation boards which will be NAND
> based.
It was a big problem, and a big surprise, for me too. The next
generation of a couple of the chips on the bus have pcie, but those
are noticably more expensive.
Another problem I ran into was that the DMA performance from a
non-incrementing address was abysmal, PIO turned out to be
significantly faster. I guess internally the bus does an entire
cacheline transfer for every word read from a fixed address, or
something like that. I was doing DMA from a device that had only six
address bits, it should have been in the middle of the bus with the
bottom address pins not connected, which would have allowed
incrementing address DMA. The transfer speed wasn't so much of a
problem, but the longer transfers meant that there was that much less
bus bandwidth for the other devices, so we wound up sacrificing CPU to
get more bus bandwidth.
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-08 17:32 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <20101208111839.1cf95553@udp111988uds.am.freescale.net>
Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 18:18:39:
>
> On Wed, 8 Dec 2010 08:59:49 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > >
> > > On Mon, 6 Dec 2010 22:15:54 -0500
> > > Mark Mason <mason@postdiluvian.org> wrote:
> > >
> > > > A few months ago I ran into some performance problems involving
> > > > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > > > found a solution for this, which worked well, at least with the
> > > > hardware I was working with. I suspect the same problem affects other
> > > > PPCs, probably including multicore devices, and maybe other
> > > > architectures as well.
> > > >
> > > > I don't have experience with similar NAND controllers on other
> > > > devices, so I'd like to explain what I found and see if someone who's
> > > > more familiar with the family and/or driver can tell if this is
> > > > useful.
> > > >
> > > > The problem cropped up when there was a lot of traffic to the NAND
> > > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > > a video chip that needed constant and prompt attention.
> > >
> > > If you attach NAND to the LBC, you should not attach anything else to
> > > it which is latency-sensitive.
> >
> > This "feature" makes the LBC useless to us. Is there some workaround or plan
> > to address this limitation?
>
> Complain to your support or sales contact.
>
> I've complained about it in the past, and got a "but pins are a limited
> resource!" response. They need to hear that it's a problem from
> customers.
Done, lets see what I get in return. I think this problem will be
a major obstacle for our next generation boards which will be NAND
based.
Jocke
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-08 17:18 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <OFF94B1B01.88594E81-ONC12577F3.002B63AA-C12577F3.002BEE0B@transmode.se>
On Wed, 8 Dec 2010 08:59:49 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > On Mon, 6 Dec 2010 22:15:54 -0500
> > Mark Mason <mason@postdiluvian.org> wrote:
> >
> > > A few months ago I ran into some performance problems involving
> > > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > > found a solution for this, which worked well, at least with the
> > > hardware I was working with. I suspect the same problem affects other
> > > PPCs, probably including multicore devices, and maybe other
> > > architectures as well.
> > >
> > > I don't have experience with similar NAND controllers on other
> > > devices, so I'd like to explain what I found and see if someone who's
> > > more familiar with the family and/or driver can tell if this is
> > > useful.
> > >
> > > The problem cropped up when there was a lot of traffic to the NAND
> > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > a video chip that needed constant and prompt attention.
> >
> > If you attach NAND to the LBC, you should not attach anything else to
> > it which is latency-sensitive.
>
> This "feature" makes the LBC useless to us. Is there some workaround or plan
> to address this limitation?
Complain to your support or sales contact.
I've complained about it in the past, and got a "but pins are a limited
resource!" response. They need to hear that it's a problem from
customers.
-Scott
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-08 15:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291815910.12093.15.camel@concordia>
> Sorry I assumed you were working on mainline. In 2.6.35 you still need
> to use an of_platform_driver, I'll describe below.
> So basically you need to change all occurrences of platform_driver to
> of_platform_driver.
OK, thanks, I did that, compiled and ran the driver and its test prog... no
changes: xad_driver_probe() doesn't get called.
...?
--
Guillaume Dargaud
http://www.gdargaud.net/Antarctica/
^ permalink raw reply
* Re: [PATCH v2] powerpc, 5200: add support for charon board
From: Wolfram Sang @ 2010-12-08 15:49 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <1291705135-26805-1-git-send-email-hs@denx.de>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On Tue, Dec 07, 2010 at 07:58:55AM +0100, Heiko Schocher wrote:
> Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 4/4] microblaze/of: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/microblaze/boot/Makefile | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
index be01d78..4c4e58e 100644
--- a/arch/microblaze/boot/Makefile
+++ b/arch/microblaze/boot/Makefile
@@ -10,9 +10,6 @@ targets := linux.bin linux.bin.gz simpleImage.%
OBJCOPYFLAGS := -O binary
-# Where the DTS files live
-dtstree := $(srctree)/$(src)/dts
-
# Ensure system.dtb exists
$(obj)/linked_dtb.o: $(obj)/system.dtb
@@ -51,14 +48,11 @@ $(obj)/simpleImage.%: vmlinux FORCE
$(call if_changed,strip)
@echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
-# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
# Rule to build device tree blobs
-quiet_cmd_dtc = DTC $@
- cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 -p 1024 $(dtstree)/$*.dts
+DTC_FLAGS := -p 1024
-$(obj)/%.dtb: $(dtstree)/%.dts FORCE
- $(call if_changed,dtc)
+$(obj)/%.dtb: $(src)/dts/%.dts FORCE
+ $(call cmd,dtc)
clean-files += *.dtb simpleImage.*.unstrip linux.bin.ub
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/4] of/powerpc: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/powerpc/boot/Makefile | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index fae8192..96deec6 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -35,7 +35,7 @@ endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-DTS_FLAGS ?= -p 1024
+DTC_FLAGS ?= -p 1024
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
@@ -332,10 +332,8 @@ $(obj)/treeImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,,$(obj)/$*.dtb)
# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
-
-$(obj)/%.dtb: $(dtstree)/%.dts
- $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(DTS_FLAGS) $(dtstree)/$*.dts
+$(obj)/%.dtb: $(src)/dts/%.dts
+ $(call cmd,dtc)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds linking device tree blob into vmlinux. DTB's are
added by adding the blob object name to list of objects to be linked
into the image.
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile
index 91fc929..e5f3b7b 100644
--- a/arch/x86/platform/ce4100/Makefile
+++ b/arch/x86/platform/ce4100/Makefile
@@ -1 +1,11 @@
obj-$(CONFIG_X86_INTEL_CE) += ce4100.o
+clean-files := *dtb.S
+
+ifdef CONFIG_X86_OF
+###
+# device tree blob
+obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
+
+$(obj)/%.dtb: $(src)/%.dts
+ $(call cmd,dtc)
+endif
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds support for linking device tree blob(s) into
vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
.dtb sections into vmlinux. To maintain compatiblity with the of/fdt
driver code platforms MUST copy the blob to a non-init memory location
before the kernel frees the .init.* sections in the image.
Modifies scripts/Makefile.lib to add a kbuild command to
compile DTS files to device tree blobs and a rule to create objects to
wrap the blobs for linking.
STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
create wrapper objects for the dtb in Makefile.lib. The
STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
STRUCT_ALIGNMENT definition.
The DTB's are placed on 32 byte boundries to allow parsing the blob
with driver/of/fdt.c during early boot without having to copy the blob
to get the structure alignment GCC expects.
A DTB is linked in by adding the DTB object to the list of objects to
be linked into vmlinux in the archtecture specific Makefile using
obj-y += foo.dtb.o
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
scripts/Makefile.lib | 23 +++++++++++++++++++++++
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 0ef00bd..86e3cd0 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
resulting in the target file being recompiled for no
obvious reason.
+ dtc
+ Create flattend device tree blob object suitable for linking
+ into vmlinux. Device tree blobs linked into vmlinux are placed
+ in an init section in the image. Platform code *must* copy the
+ blob to non-init memory prior to calling unflatten_device_tree().
+
+ Example:
+ #arch/x86/platform/ce4100/Makefile
+ clean-files := *dtb.S
+
+ DTC_FLAGS := -p 1024
+ obj-y += foo.dtb.o
+
+ $(obj)/%.dtb: $(src)/%.dts
+ $(call cmd,dtc)
--- 6.7 Custom kbuild commands
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index bd69d79..05cbad0 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -67,7 +67,8 @@
* Align to a 32 byte boundary equal to the
* alignment gcc 4.5 uses for a struct
*/
-#define STRUCT_ALIGN() . = ALIGN(32)
+#define STRUCT_ALIGNMENT 32
+#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
/* The actual configuration determine if the init/exit sections
* are handled as text/data or they can be discarded (which
@@ -146,6 +147,13 @@
#define TRACE_SYSCALLS()
#endif
+
+#define KERNEL_DTB() \
+ STRUCT_ALIGN(); \
+ VMLINUX_SYMBOL(__dtb_start) = .; \
+ *(.dtb.init.rodata) \
+ VMLINUX_SYMBOL(__dtb_end) = .;
+
/* .data section */
#define DATA_DATA \
*(.data) \
@@ -468,7 +476,8 @@
MCOUNT_REC() \
DEV_DISCARD(init.rodata) \
CPU_DISCARD(init.rodata) \
- MEM_DISCARD(init.rodata)
+ MEM_DISCARD(init.rodata) \
+ KERNEL_DTB()
#define INIT_TEXT \
*(.init.text) \
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 4c72c11..63b287c 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -200,6 +200,29 @@ quiet_cmd_gzip = GZIP $@
cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
(rm -f $@ ; false)
+# DTC
+# ---------------------------------------------------------------------------
+
+# Generate an assembly file to wrap the output of the device tree compiler
+quiet_cmd_dt_S_dtb= DTB $@
+cmd_dt_S_dtb= \
+( \
+ echo '\#include <asm-generic/vmlinux.lds.h>'; \
+ echo '.section .dtb.init.rodata,"a"'; \
+ echo '.balign STRUCT_ALIGNMENT'; \
+ echo '.global __dtb_$(*F)_begin'; \
+ echo '__dtb_$(*F)_begin:'; \
+ echo '.incbin "$<" '; \
+ echo '__dtb_$(*F)_end:'; \
+ echo '.global __dtb_$(*F)_end'; \
+ echo '.balign STRUCT_ALIGNMENT'; \
+) > $@
+
+$(obj)/%.dtb.S: $(obj)/%.dtb
+ $(call cmd,dt_S_dtb)
+
+quiet_cmd_dtc = DTC $@
+ cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
# Bzip2
# ---------------------------------------------------------------------------
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/4] V3 Add ability to link device blob(s) into vmlinux
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch set adds the ability to link device tree blobs into
vmlinux.
Patch 1 implements the changes to include/asm-generic/vmlinux.lds.h and
adds a generic rule for generating DTB objects to be linked vmlinux.
Patch 2 implements linking a DTB into an x86 image.
Patch 3-4 move {powerpc,microblaze}/boot/Makefile to use the dtc rule
in patch 1.
This patch set has been tested on x86.
Powerpc and Microblaze have been compile tested with and without patch
3 and 4 applied.
Changes from V1:
Documentation added for dtc command in Makefile.lib to
Documentation/kbuild/makefiles.txt
Separate DTB_ALIGNMENT define removed.
FORCE removed from dtc rule.
Removed hardcoded path to dts files from dtc command.
Moved %.dtb: %.dts rule to arch specific makefiles.
Patch for adding kernel command line option to pass in dtb_compat
string dropped from this set will be submitted seperately.
Changes from V2:
Rule to create assembly wrapper for blob changed to use Sam Ravnborgs
suggested implementation.
Rules in architecture specific Makefiles changed to use the cmd
function instead of the if_changed function.
Dirk Brandewie (4):
of: Add support for linking device tree blobs into vmlinux
x86/of: Add building device tree blob(s) into image.
of/powerpc: Use generic rule to build dtb's
microblaze/of: Use generic rule to build dtb's
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
arch/microblaze/boot/Makefile | 12 +++---------
arch/powerpc/boot/Makefile | 8 +++-----
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
scripts/Makefile.lib | 23 +++++++++++++++++++++++
6 files changed, 65 insertions(+), 16 deletions(-)
--
1.7.2.3
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-08 13:45 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012081118.13977.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 7255 bytes --]
On Wed, 2010-12-08 at 11:18 +0100, Guillaume Dargaud wrote:
> Thanks again for your detailed answer,
> I'm learning, but not as fast as my colleagues with a deadline want me to !
:)
> > The platform code does that. That function create devices on the
> > platform bus by examining the device tree. It looks for nodes that are
> > compatible with the compatible strings you give it, and treats them as
> > busses, ie. creates devices for all child nodes of those nodes.
>
> Is there a way to enable some debug output from it, to see what's going on ?
Not really, but there probably should be.
> > > ...hmm I had to "git pull" in order for this to compile your snippet.
> > > That's really recent! Unfortunately i need to reflash my device with the
> > > new kernel before i can begin testing my module.
> >
> > It shouldn't be that recent, what kernel version were you using?
>
> I had to go from 2.6.34 to 2.6.35, xilinx git tree.
Ah that is the problem I think.
Sorry I assumed you were working on mainline. In 2.6.35 you still need
to use an of_platform_driver, I'll describe below.
> > platform_device_register() tends to be for cases where you can't
> > discover or probe a device, but you "know" that it exists.
>
> When you see something in /sys/devices/plb.0/, it means that you don't need
> platform_device_register, right ?
That's right.
> > Yes, "make tags", then use vim :)
>
> Great, that works.
Cool.
> OK, here's the relevant part of my code, ripped directly from your sample,
> with a few additions and different variable names. Why do you think
> xad_driver_probe() is not being called ?
As I said above in 2.6.35 platform drivers and of_platform drivers were
still separate. So your device is on the of_platform_bus (ie. was
discovered using the device tree), but your driver is on the
platform_bus. Yes this is very confusing.
So basically you need to change all occurrences of platform_driver to
of_platform_driver.
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <asm/device.h>
> #include <linux/platform_device.h>
> #include <linux/cdev.h> // char device
> #include <linux/fs.h>
> #include <linux/of.h>
> #include <linux/interrupt.h>
>
> #define DEVNAME "xps-acqui-data"
> #define NAME "xad" // This is only used for printk
>
> #define SD "{%s %d} "
> #define FL , __func__, __LINE__
>
> static dev_t first;
> static unsigned int count = 1;
> static int my_major = 241, my_minor = 0;
> // You must run "mknod /dev/xad c 241 0" in a shell at least once
>
> struct cdev *my_cdev=NULL;
> struct platform_device *pdev=NULL;
>
> typedef struct XadDevice {
> struct resource *hw_region;
> struct device *dev;
> int irq;
> } tXadDevice;
> tXadDevice Xad;
>
> // There should be something in:
> // ll /sys/devices/plb.0/c9800000.xps-acqui-data
> static const struct of_device_id xad_device_id[] = {
> { .compatible = "xlnx,xps-acqui-data-3.00.a" }, // Must match
> the DTS
> {}
> };
>
>
> static irqreturn_t XadIsr(int irq, void *dev_id) {
> printk(KERN_INFO SD "IRQ:%d\n" FL, irq);
> return IRQ_HANDLED;
> }
>
> ///////////////////////////////////////////////////////////////////////////////
> // Platform Bus Support
> ///////////////////////////////////////////////////////////////////////////////
>
> static int xad_driver_probe(struct platform_device *device /*,
> const struct of_device_id *device_id*/ ) {
So you need to switch the prototype here to:
static int xad_driver_probe(struct of_platform_device *ofdev,
const struct of_device_id *device_id) {
> struct device_node *dn = device->dev.of_node;
> int rc;
>
> pr_devel("Probing %s\n", dn->full_name);
>
> Xad.irq = irq_of_parse_and_map(dn, 0);
> rc=request_irq(Xad.irq, XadIsr, IRQF_TRIGGER_RISING | IRQF_DISABLED,
> "XadIsr", &Xad);
> if (rc) printk(KERN_INFO SD "Failled IRQ request: %d\n" FL, rc);
>
> return 0;
> }
>
> static int __devexit xad_driver_remove(struct platform_device *device) {
> printk(KERN_INFO SD "Removing...\n" FL);
> return 0;
> }
>
> static struct platform_driver xad_driver = {
Becomes of_platform_driver
> .probe = xad_driver_probe,
> .remove = xad_driver_remove,
> .driver = {
> .owner = THIS_MODULE,
> .name = "xad-driver",
> .of_match_table = xad_device_id,
> },
> };
>
>
> ///////////////////////////////////////////////////////////////////////////////
> // This section deals with the /dev/xad device
> ///////////////////////////////////////////////////////////////////////////////
> static int xad_open(struct inode *node, struct file *filep) {
> printk (KERN_INFO SD "OPENING device: %s\n" FL, NAME);
> return 0;
> }
>
> static int xad_release(struct inode *node, struct file *filep) {
> printk (KERN_INFO SD "RELEASING device: %s\n" FL, NAME);
> return 0;
> }
>
> static int xad_ioctl(struct inode *node, struct file *filep, unsigned int cmd,
> unsigned long arg) {
> printk (KERN_INFO SD "IOCTL on device: %s, cmd:%d, arg:%lu\n" FL, NAME, cmd,
> arg);
> return 0;
> }
>
> static struct file_operations fops = {
> .owner = THIS_MODULE,
> .open = xad_open,
> .release = xad_release,
> .ioctl = xad_ioctl,
> };
>
>
> ///////////////////////////////////////////////////////////////////////////////
> // Called on insmod
> static int __init xad_init(void) {
> int rc=0;
> printk(KERN_INFO SD "Module %s: loading...\n" FL, NAME);
>
> // Deal with the device
> first = MKDEV (my_major, my_minor);
> register_chrdev_region(first, count, DEVNAME);
> my_cdev = cdev_alloc ();
> if (NULL==my_cdev) goto Err;
>
> cdev_init(my_cdev, &fops);
> cdev_add (my_cdev, first, count);
>
> printk(KERN_INFO SD "Module %s: Major=%d, Minor=%d, Count=%d\n" FL, NAME,
> my_major, my_minor, count);
>
> // Driver
> rc = platform_driver_register(&xad_driver);
Should be of_register_platform_driver()
> // rc = platform_driver_probe(&xad_driver, xad_driver_probe);
> if (rc) goto err_plat;
>
> // Device
> pdev=platform_device_register_simple("xps-acqui-data", -1, NULL, 0);
> if (IS_ERR(pdev)) {
> rc = PTR_ERR(pdev);
> platform_driver_unregister(&xad_driver);
> goto err_plat;
> }
>
>
> return 0;
>
> err_plat:
> unregister_chrdev_region(first, count);
> Err:
> printk(KERN_ERR SD "Module %s: Failed loading rc=%d\n" FL, NAME, rc);
> return rc;
> }
>
> ///////////////////////////////////////////////////////////////////////////////
> // Called on rmmod
> static void xad_exit(void) {
> platform_device_unregister(pdev); pdev=NULL;
> platform_driver_unregister(&xad_driver);
>
> cdev_del (my_cdev); my_cdev=NULL;
> unregister_chrdev_region (first, count);
> printk(KERN_INFO SD "Module %s unloaded\n" FL, NAME);
> }
>
> module_init(xad_init);
> module_exit(xad_exit);
>
> MODULE_AUTHOR("Guillaume Dargaud");
> MODULE_LICENSE("GPL");
>
>
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix incorrect comment about interrupt stack allocation
From: Anton Blanchard @ 2010-12-08 10:55 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
We now allow interrupt stacks anywhere in the first segment which can be
256M or 1TB. Fix the comment.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/setup_64.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/setup_64.c 2010-08-19 09:05:17.090741942 +1000
+++ powerpc.git/arch/powerpc/kernel/setup_64.c 2010-08-19 09:06:08.151991499 +1000
@@ -428,8 +428,8 @@ static void __init irqstack_early_init(v
unsigned int i;
/*
- * interrupt stacks must be under 256MB, we cannot afford to take
- * SLB misses on them.
+ * Interrupt stacks must be in the first segment since we
+ * cannot afford to take SLB misses on them.
*/
for_each_possible_cpu(i) {
softirq_ctx[i] = (struct thread_info *)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox