Re: [PATCH] of: provide of_platform_unpopulate()
On 07/19/2013 01:14 PM, Sebastian Andrzej Siewior wrote:
So I called of_platform_populate() on a device to get each child device
probed and on rmmod and I need to reverse its doing. After a quick grep
I did what others did as well and rmmod ended in:
| Unable to handle kernel NULL pointer dereference at virtual address 0018
| PC is at release_resource+0x18/0x80
| Process rmmod (pid: 2005, stack limit = 0xedc30238)
| [c003add0] (release_resource+0x18/0x80) from [c0300e08]
(platform_device_del+0x78/0xac)
| [c0300e08] (platform_device_del+0x78/0xac) from [c0301358]
(platform_device_unregister+0xc/0x18)
The problem is that platform_device_del() releases each ressource in its
tree. This does not work on platform_devices created by OF becuase they
were never added via insert_resource(). As a consequence old-parent in
__release_resource() is NULL and we explode while accessing -child.
So I either I do something completly wrong _or_ nobody here tested the
rmmod path of their driver.
Wouldn't the correct fix be to call insert_resource somehow? The problem
I have is that while of_platform_populate is all about parsing the DT
and creating devices, the removal side has nothing to do with DT. So
this should not be in the DT code. I think the core device code should
be able to handle removal if the device creation side is done correctly.
It looks to me like of_device_add either needs to call
platform_device_add rather than device_add. I think the device name
setting in platform_device_add should be a nop. If not, a check that the
name is already set could be added.
Rob
This patch provides a common function to unregister / remove devices
which added to the system via of_platform_populate(). While this works
now on my test case I have not tested any of the driver I modify here so
feedback is greatly appreciated.
Cc: Tony Lindgren t...@atomide.com
Cc: Doug Anderson diand...@chromium.org
Cc: Vivek Gautam gautam.vi...@samsung.com
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Kishon Vijay Abraham I kis...@ti.com
Cc: Roger Quadros rog...@ti.com
Cc: George Cherian george.cher...@ti.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/bus/omap-ocp2scp.c | 13 ++---
drivers/iio/adc/exynos_adc.c | 15 ++-
drivers/mfd/omap-usb-host.c| 9 +
drivers/of/platform.c | 22 ++
drivers/usb/dwc3/dwc3-exynos.c | 11 +--
drivers/usb/dwc3/dwc3-omap.c | 12 +---
include/linux/of_platform.h| 4
7 files changed, 33 insertions(+), 53 deletions(-)
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
index 5511f98..510bb9e 100644
--- a/drivers/bus/omap-ocp2scp.c
+++ b/drivers/bus/omap-ocp2scp.c
@@ -23,15 +23,6 @@
#include linux/of.h
#include linux/of_platform.h
-static int ocp2scp_remove_devices(struct device *dev, void *c)
-{
- struct platform_device *pdev = to_platform_device(dev);
-
- platform_device_unregister(pdev);
-
- return 0;
-}
-
static int omap_ocp2scp_probe(struct platform_device *pdev)
{
int ret;
@@ -51,7 +42,7 @@ static int omap_ocp2scp_probe(struct platform_device *pdev)
return 0;
err0:
- device_for_each_child(pdev-dev, NULL, ocp2scp_remove_devices);
+ of_platform_unpopulate(pdev-dev);
return ret;
}
@@ -59,7 +50,7 @@ static int omap_ocp2scp_probe(struct platform_device *pdev)
static int omap_ocp2scp_remove(struct platform_device *pdev)
{
pm_runtime_disable(pdev-dev);
- device_for_each_child(pdev-dev, NULL, ocp2scp_remove_devices);
+ of_platform_unpopulate(pdev-dev);
return 0;
}
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 9809fc9..10248e1 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -216,15 +216,6 @@ static const struct iio_chan_spec
exynos_adc_iio_channels[] = {
ADC_CHANNEL(9, adc9),
};
-static int exynos_adc_remove_devices(struct device *dev, void *c)
-{
- struct platform_device *pdev = to_platform_device(dev);
-
- platform_device_unregister(pdev);
-
- return 0;
-}
-
static void exynos_adc_hw_init(struct exynos_adc *info)
{
u32 con1, con2;
@@ -357,8 +348,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
return 0;
err_of_populate:
- device_for_each_child(pdev-dev, NULL,
- exynos_adc_remove_devices);
+ of_platform_unpopulate(pdev-dev);
regulator_disable(info-vdd);
clk_disable_unprepare(info-clk);
err_iio_dev:
@@ -375,8 +365,7 @@ static int exynos_adc_remove(struct platform_device *pdev)
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct exynos_adc *info = iio_priv(indio_dev);
- device_for_each_child(pdev-dev, NULL,
-
Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership
On 07/19/2013 10:19 PM, Grant Likely wrote: Device tree bindings require a lot more attention than they used to. We've got a group of volunteers willing to take over maintaining bindings. This patch adds them to the MAINTAINERS file. This group still needs to work out a process for maintainership and how they are going to work together. I recommend that they set up a shared tree on git.kernel.org that they each have commit access to similar to the tip tree or the arm-soc tree, but it is up to them. Signed-off-by: Grant Likely grant.lik...@linaro.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Ian Campbell ian.campb...@citrix.com Cc: Rob Herring rob.herr...@calxeda.com Cc: Olof Johansson o...@lixom.net Cc: devicetree-discuss@lists.ozlabs.org Cc: devicet...@vger.kernel.org --- MAINTAINERS | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index bc286e4..12c95d5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6050,13 +6050,24 @@ L:devicet...@vger.kernel.org W: http://fdt.secretlab.ca T: git git://git.secretlab.ca/git/linux-2.6.git S: Maintained -F: Documentation/devicetree F: drivers/of F: include/linux/of*.h F: scripts/dtc K: of_get_property K: of_match_table +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS +M: Pawel Moll pawel.m...@arm.com +M: Mark Rutland mark.rutl...@arm.com +M: Stephen Warren swar...@wwwdotorg.org +M: Ian Campbell ian.campb...@citrix.com You can add me. I was not intending to step down. What about creating an email alias for the group instead? Rob +L: devicet...@vger.kernel.org +S: Maintained +F: Documentation/devicetree +F: arch/*/boot/dts +F: arch/*/ +F: include/dt-bindings + OPENRISC ARCHITECTURE M: Jonas Bonn jo...@southpole.se W: http://openrisc.net ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: match the compatible in the order set by the dts file
On Sat, Jul 20, 2013 at 12:44 AM, Grant Likely grant.lik...@linaro.org
wrote:
On Tue, 9 Jul 2013 16:10:53 +0800, Huang Shijie b32...@freescale.com wrote:
于 2013年07月09日 15:51, Sascha Hauer 写道:
On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
于 2013年07月09日 15:05, Sascha Hauer 写道:
Why don't you set the matching order in the driver the way you want it
to be, i.e.:
{ .compatible = fsl,imx6q-uart, ... },
{ .compatible = fsl,imx21-uart, ... },
{ .compatible = fsl,imx1-uart, ... },
yes. i can set it like this.
but this method looks like a ugly workaround.
If a driver has different ways of supporting a single device, then
putting the preferred or most feature rich on top doesn't look very ugly
to me.
this method makes it much _coupled_ between the driver and the dts file.
IMHO, it's an unnecessary _burden_ to the driver programmer:
he should puts the most feature compatible on the top.
it's much graceful if we let the driver programmer be transparent about
this.
Absolutely true. Applied, thanks.
We can debate whether the driver order matters or not, but either way
I'm not sure this patch does the right thing. It doesn't really look
correct to me, but I haven't dug into it.
We've already tried to fix matching and reverted the fix once before
(commit below). So this patch needs careful review and thought about
cases where the name and/or type is used to match.
commit bc51b0c22cebf5c311a6f1895fcca9f78efd0478
Author: Linus Torvalds torva...@linux-foundation.org
Date: Tue Jul 10 12:49:32 2012 -0700
Revert of: match by compatible property first
This reverts commit 107a84e61cdd3406c842a0e4be7efffd3a05dba6.
Meelis Roos reports a regression since 3.5-rc5 that stops Sun Fire V100
and Sun Netra X1 sparc64 machines from booting, hanging after enabling
serial console. He bisected it to commit 107a84e61cdd.
Rob Herring explains:
The problem is match combinations of compatible plus name and/or type
fail to match correctly. I have a fix for this, but given how late it
is for 3.5 I think it is best to revert this for now. There could be
other cases that rely on the current although wrong behavior. I will
post an updated version for 3.6.
Bisected-and-reported-by: Meelis Roos mr...@linux.ee
Requested-by: Rob Herring rob.herr...@calxeda.com
Cc: Thierry Reding thierry.red...@avionic-design.de
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: provide of_platform_unpopulate()
On 07/21/2013 09:42 AM, Rob Herring wrote: On 07/19/2013 01:14 PM, Sebastian Andrzej Siewior wrote: So I called of_platform_populate() on a device to get each child device probed and on rmmod and I need to reverse its doing. After a quick grep I did what others did as well and rmmod ended in: | Unable to handle kernel NULL pointer dereference at virtual address 0018 | PC is at release_resource+0x18/0x80 | Process rmmod (pid: 2005, stack limit = 0xedc30238) | [c003add0] (release_resource+0x18/0x80) from [c0300e08] (platform_device_del+0x78/0xac) | [c0300e08] (platform_device_del+0x78/0xac) from [c0301358] (platform_device_unregister+0xc/0x18) The problem is that platform_device_del() releases each ressource in its tree. This does not work on platform_devices created by OF becuase they were never added via insert_resource(). As a consequence old-parent in __release_resource() is NULL and we explode while accessing -child. So I either I do something completly wrong _or_ nobody here tested the rmmod path of their driver. Wouldn't the correct fix be to call insert_resource somehow? The problem I have is that while of_platform_populate is all about parsing the DT and creating devices, the removal side has nothing to do with DT. So this should not be in the DT code. I think the core device code should be able to handle removal if the device creation side is done correctly. It looks to me like of_device_add either needs to call platform_device_add rather than device_add. I think the device name setting in platform_device_add should be a nop. If not, a check that the name is already set could be added. BTW, it looks like Grant has attempted this already: commit 02bbde7849e68e193cefaa1885fe0df0f03c9fcd Author: Grant Likely grant.lik...@secretlab.ca Date: Sun Feb 17 20:03:27 2013 + Revert of: use platform_device_add This reverts commit aac73f34542bc7ae4317928d2eabfeb21d247323. That commit causes two kinds of breakage; it breaks registration of AMBA devices when one of the parent nodes already contains overlapping resource regions, and it breaks calls to request_region() by device drivers in certain conditions where there are overlapping memory regions. Both of these problems can probably be fixed, but it is better to back out the commit and get a proper fix designed before trying again. Signed-off-by: Grant Likely grant.lik...@secretlab.ca Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of/irq: init struct resource to 0 in of_irq_to_resource()
On Fri, Jul 19, 2013 at 1:57 AM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
On 07/19/2013 04:49 AM, Rob Herring wrote:
On 07/18/2013 05:24 AM, Sebastian Andrzej Siewior wrote:
It almost does not matter because most users use only the -start member
of the struct. However if this struct is passed to a platform device
which is then added via platform_device_add() then the -parent member is
also used.
Most users don't use the resource struct at all. The ones that do, all
seem to do a memset beforehand. So I think current behavior is correct.
Seriously? That is your argument here? Most users use memset()
beforehand and that makes it correct? Now look at this: you pass a
pointer to fill out a struct and you don't do it properly.
From a standpoint of initializing variables close to the point it is
allocated, yes.
There is of_address_to_resource() which does a memset() why is okay
here use memset()?
Fair enough. Consistency is important too. Rather than a memset, I'd
rather see the 3 remaining fields initialized and avoid setting most
of them twice.
Rob
There are some occurrences that pass a resource in, but then don't
actually use the resource. Those we should fix.
Rob
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/of/irq.c | 1 +
1 file changed, 1 insearch/powerpc/sysdev/mv64x60_dev.crtion(+)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index a3c1c5a..e0a72fb 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -345,6 +345,7 @@ int of_irq_to_resource(struct device_node *dev, int
index, struct resource *r)
if (r irq) {
const char *name = NULL;
+memset(r, 0, sizeof(*r));
/*
* Get optional interrupts-names property to add a name
* to the resource.
Sebastian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2 11/15] cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes
On 07/18/2013 05:14 AM, Sudeep KarkadaNagesha wrote: On 18/07/13 09:24, Sudeep KarkadaNagesha wrote: On 17/07/13 15:43, Andrew Lunn wrote: On Wed, Jul 17, 2013 at 03:06:20PM +0100, sudeep.karkadanage...@arm.com wrote: From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com [...] Are we not going a bit backwards here? You are replacing two lines with 10 lines. How about putting these 10 lines into some helper, of_get_cpu_device()? It would be useful for spear, kirkwood and imx6q, and maybe others. Yes I realised that after making changes to this and pmac32 drivers. I have already made those changes in v3. I am waiting for more response before posting them. I thought of placing this helper in include/linux/of_device.h but I see: #include linux/of_platform.h /* temporary until merge */ Does this mean of_platform.h and of_device.h will be merged ? No, I think that was probably to avoid adding includes of of_platform.h for 100's of files. Maybe things are cleaned up enough to remove this line. If so, which will be the final merged one ? I would like to avoid changing all the header file inclusions later in users of this new helper. of_device.h is the right place. Rob Regards, Sudeep ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of/irq: init struct resource to 0 in of_irq_to_resource()
On 07/18/2013 05:24 AM, Sebastian Andrzej Siewior wrote:
It almost does not matter because most users use only the -start member
of the struct. However if this struct is passed to a platform device
which is then added via platform_device_add() then the -parent member is
also used.
Most users don't use the resource struct at all. The ones that do, all
seem to do a memset beforehand. So I think current behavior is correct.
There are some occurrences that pass a resource in, but then don't
actually use the resource. Those we should fix.
Rob
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/of/irq.c | 1 +
1 file changed, 1 insearch/powerpc/sysdev/mv64x60_dev.crtion(+)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index a3c1c5a..e0a72fb 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -345,6 +345,7 @@ int of_irq_to_resource(struct device_node *dev, int
index, struct resource *r)
if (r irq) {
const char *name = NULL;
+ memset(r, 0, sizeof(*r));
/*
* Get optional interrupts-names property to add a name
* to the resource.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2 01/15] of: add support for retrieving cpu node for a given logical cpu index
On 07/17/2013 09:06 AM, sudeep.karkadanage...@arm.com wrote:
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Currently different drivers requiring to access cpu device node are
parsing the device tree themselves. Since the ordering in the DT need
not match the logical cpu ordering, the parsing logic needs to consider
that. However, this has resulted in lots of code duplication and in some
cases even incorrect logic.
It's better to consolidate them by adding support for getting cpu
device node for a given logical cpu index in DT core library. However
logical to physical index mapping can be architecture specific.
This patch adds of_get_cpu_node to retrieve a cpu device node for a
given logical cpu index. The default matching of the physical id to the
logical cpu index can be overridden by architecture specific code.
It is recommended to use these helper function only in pre-SMP/early
initialisation stages to retrieve CPU device node pointers in logical
ordering. Once the cpu devices are registered, it can be retrieved easily
from cpu device of_node which avoids unnecessary parsing and matching.
Cc: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
One comment below, but otherwise for patches 1-4, 8 and 9:
Acked-by: Rob Herring rob.herr...@calxeda.com
Also, patch 3 needs to come before patch 2 or the matching will be wrong
if patch 3 is not applied.
---
drivers/of/base.c | 66
++
include/linux/of.h | 5 +
2 files changed, 71 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5c54279..363b8f9 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -230,6 +230,72 @@ const void *of_get_property(const struct device_node
*np, const char *name,
}
EXPORT_SYMBOL(of_get_property);
+/*
+ * arch_match_cpu_phys_id - Match the given logical CPU and physical id
+ *
+ * @cpu: logical index of a cpu
+ * @phys_id: physical identifier of a cpu
+ *
+ * CPU logical to physical index mapping is architecure specific.
+ * However this __weak function provides a default match of physical
+ * id to logical cpu index.
+ *
+ * Returns 1 if the physical identifier and the logical index correspond
+ * to the same cpu, 0 otherwise.
+ */
+int __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)
+{
+ return (u32)phys_id == cpu;
+}
+
+/**
+ * of_get_cpu_node - Get device node associated with the given logical CPU
+ *
+ * @cpu: CPU number(logical index) for which device node is required
+ *
+ * The main purpose of this function is to retrieve the device node for the
+ * given logical CPU index. It should be used to intialise the of_node in
+ * cpu device. Once of_node in cpu device is populated, all the further
+ * references can use that instead.
+ *
+ * CPU logical to physical index mapping is architecure specific and is built
+ * before booting secondary cores. This function uses arch_match_cpu_phys_id
+ * which can be overridden by architecture specific implementation.
+ *
+ * Returns a node pointer for the logical cpu if found, else NULL.
+ */
+struct device_node *of_get_cpu_node(int cpu)
+{
+ struct device_node *cpun, *cpus;
+ const u32 *cell;
+ u64 hwid;
+ int ac, prop_len;
+
+ cpus = of_find_node_by_path(/cpus);
+ if (WARN(!cpus, Missing cpus node, bailing out\n))
What happens on a system with no /cpus nodes? Seems like this is another
case of adding new warnings to existing working systems.
I'd replace all the WARN's with a single pr_warn on any errors below.
For missing /cpus, I would just silently return.
Rob
+ return NULL;
+
+ if (WARN_ON(of_property_read_u32(cpus, #address-cells, ac)))
+ ac = of_n_addr_cells(cpus);
+
+ for_each_child_of_node(cpus, cpun) {
+ if (of_node_cmp(cpun-type, cpu))
+ continue;
+ cell = of_get_property(cpun, reg, prop_len);
+ if (WARN(!cell, %s: missing reg property\n, cpun-full_name))
+ continue;
+
+ while (prop_len) {
+ hwid = of_read_number(cell, ac);
+ prop_len -= ac;
+ if (arch_match_cpu_phys_id(cpu, hwid))
+ return cpun;
+ }
+ }
+
+ return NULL;
+}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
On 07/16/2013 11:05 AM, Lorenzo Pieralisi wrote:
The TC2 versatile express core tile integrates a logic block that provides the
interface between the dual cluster test-chip and the M3 microcontroller that
carries out power management. The logic block, called Serial Power Controller
(SPC), contains several memory mapped registers to control among other things
low-power states, wake-up irqs and per-CPU jump addresses registers.
This patch provides a driver that enables run-time control of features
implemented by the SPC power management control logic.
The SPC control logic is required to be programmed very early in the boot
process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and
wake-up IRQs for power management. Hence, waiting for core changes to be
made in the device core code to enable early registration of platform
devices, the driver puts in place an early init scheme that allows kernel
drivers to initialize the SPC driver directly from the components requiring
it, if their initialization routine is called before the driver init
function by the boot process.
Device tree bindings documentation for the SPC component is provided with
the patchset.
Just curious, wouldn't a TC2 PSCI implementation eliminate the need for
most/all of this code?
Rob
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Olof Johansson o...@lixom.net
Cc: Pawel Moll pawel.m...@arm.com
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Jon Medhurst t...@linaro.org
Signed-off-by: Achin Gupta achin.gu...@arm.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
Documentation/devicetree/bindings/mfd/vexpress-spc.txt | 36 ++
drivers/mfd/Kconfig| 10 +
drivers/mfd/Makefile | 1 +
drivers/mfd/vexpress-spc.c | 253 ++
include/linux/vexpress.h | 17 +
5 files changed, 317 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
new file mode 100644
index 000..1614725
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
@@ -0,0 +1,36 @@
+* ARM Versatile Express Serial Power Controller device tree bindings
+
+Latest ARM development boards implement a power management interface (serial
+power controller - SPC) that is capable of managing power states transitions,
+wake-up IRQs and resume addresses for ARM multiprocessor testchips.
+The serial controller can be programmed through a memory mapped interface
+that enables communication between firmware running on the microcontroller
+managing power states and the application processors.
+
+The SPC DT bindings are defined as follows:
+
+- spc node
+
+ - compatible:
+ Usage: required
+ Value type: stringlist
+ Definition: must be
+ arm,vexpress-spc,v2p-ca15_a7, arm,vexpress-spc
+ - reg:
+ Usage: required
+ Value type: prop-encode-array
+ Definition: A standard property that specifies the base address
+ and the size of the SPC address space
+ - interrupts:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: SPC interrupt configuration. A standard property
+ that follows ePAPR interrupts specifications
+
+Example:
+
+spc: spc@7fff {
+ compatible = arm,vexpress-spc,v2p-ca15_a7, arm,vexpress-spc;
+ reg = 0x7fff 0x1000;
+ interrupts = 0 95 4;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6959b8d..ebd23f4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1149,3 +1149,13 @@ config VEXPRESS_CONFIG
help
Platform configuration infrastructure for the ARM Ltd.
Versatile Express.
+
+config VEXPRESS_SPC
+ bool Versatile Express SPC driver support
+ depends on ARM
+ help
+ The Serial Power Controller (SPC) for ARM Ltd. test chips, is
+ an IP that provides a memory mapped interface to power controller
+ HW. The driver provides an API abstraction allowing to program
+ registers controlling low-level power management features like power
+ down flags, global and per-cpu wake-up IRQs.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 718e94a..3a01203 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -153,5 +153,6 @@ obj-$(CONFIG_MFD_SEC_CORE)+= sec-core.o sec-irq.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
obj-$(CONFIG_VEXPRESS_CONFIG)+= vexpress-config.o vexpress-sysreg.o
+obj-$(CONFIG_VEXPRESS_SPC) += vexpress-spc.o
obj-$(CONFIG_MFD_RETU)
Re: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
On Tue, Jul 16, 2013 at 6:30 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 07/15/2013 05:02 PM, Stephen Warren wrote: On 07/15/2013 01:34 PM, Rob Herring wrote: On 07/15/2013 01:40 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This property is no longer required by the GPIO binding. Remove it. Won't this break compatibility with older kernel? It is one thing to deprecate, but removal is another. If the relevant maintainers don't care, then I guess it is fine. Yes. I had originally hoped this could sneak in late for 3.11, but I suppose it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to protect. Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10. One more thought here: I know DT bindings are supposed to evolve so that a new kernel will support arbitrary old DTs. I'll call that backwards-compatibility for the DT parsing code. That is the more common case. However, this situation is the reverse; this patch would prevent a new DT running on an older kernel. I'll call that forwards-compatibility. I'm not sure if the intent is to support this or not? It's certainly the first I explicitly thought about compatibility in this direction... So you would be okay if your computer stopped booting a kernel after a BIOS update? It's the same deal. It's both forwards and backwards compatibility that is needed. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4] Input: sysrq - DT binding for key sequence
On Tue, Jul 16, 2013 at 5:24 PM, Mathieu Poirier
mathieu.poir...@linaro.org wrote:
On 15 July 2013 20:43, Rob Herring robherri...@gmail.com wrote:
On 07/15/2013 10:36 AM, mathieu.poir...@linaro.org wrote:
From: Mathieu J. Poirier mathieu.poir...@linaro.org
[snip]
+ prop = of_find_property(np, keyset, NULL);
+ if (!prop || !prop-value) {
+ pr_err(Invalid input keyset);
+ goto out;
+ }
+
+ count = prop-length / sizeof(u32);
+ val = prop-value;
None of the existing helpers to retrieve property arrays doesn't work
here?
The problem here is that we never know how long the sequence will be. As
such the 'of_property_read_uXY_array' functions won't work. Or maybe you're
referring to another set of helpers... If so, please clarify.
What about of_property_for_each_u32? Or we should make
of_property_read_uXY_array work with arrays that can be less than some
max size.
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On 07/16/2013 04:45 AM, Lorenzo Pieralisi wrote: On Mon, Jul 15, 2013 at 07:50:46PM +0100, Rob Herring wrote: On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote: On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote: On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. I had to ask Russell again to drop the bindings patches from the patch system, and this is not acceptable since two months have passed and the entire series was reviewed, acked and partially merged. I will review these bindings again but I would like to understand who should give the final go ahead to get these patches queued for upstreaming, I can't continue updating this stuff forever. Most of my comments are for 64-bit. So don't blame me that it had to be reverted. I said up front I was concerned about this change breaking things and it appears it did. New kernels must not require a new DT. The patches in Russell's tree do not break anything, I asked him to drop them since, if we change the bindings again, those patches change and have to be reworked. It was not meant to blame you at all, just saying that the process to get this stuff in the kernel should be defined properly and patches reviewed in a timely fashion. And for legacy reasons the situation related to cpu/cpus node bindings is a complicated one, there are bindings in the ePAPR, bindings in the kernel, people are confused and with this set we wanted to draw a line. For arm64 this is an absolute must. I disagree with you on the new kernels must not require a new DT. That's true if bindings are well defined, not for a mix of legacy ePAPR and bindings-in-the-kernel. Well defined depends on the platform. For purposes of a single cluster ARM system, the ePAPR was pretty much sufficient for cpu node description. The initial discussion was whether we even needed cpu nodes at all. We're always going to have something new that we did not account for. So even for well defined bindings, we'll have to make changes/extensions at some point. It just needs to be years, not months for changes. What's the DT standard for ARM cpu/cpus node ? ePAPR ? In kernel docs ? A combination thereof ? Things are not clear cut and I do not like that, it is confusing. ePAPR is a guideline, but in the end it is a PowerPC document. In some cases we can just use what it defines and in others we need to deviate. In an ideal world, we would create the equivalent for ARM or figure out how to merge ARM requirements with ePAPR. However, since UEFI and ACPI are going to solve all our problems, no one seems interested in defining a more formal document. To further complicate things, there is also the original OF specification to follow as well. So I would say all the docs apply and the order of priority is DT binding docs, ePAPR, OF specs. The DT binding docs need to be complete enough to avoid confusion. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote: On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote: On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. I had to ask Russell again to drop the bindings patches from the patch system, and this is not acceptable since two months have passed and the entire series was reviewed, acked and partially merged. I will review these bindings again but I would like to understand who should give the final go ahead to get these patches queued for upstreaming, I can't continue updating this stuff forever. Most of my comments are for 64-bit. So don't blame me that it had to be reverted. I said up front I was concerned about this change breaking things and it appears it did. New kernels must not require a new DT. But yes, this should have been reviewed more quickly. We're working on a plan to help address DT binding reviews. We have not enforced that Grant and I must ack all bindings, but in this case you certainly need mine since I have reviewed it and if you want to me to pull it. Main changes: - adds 64-bit bindings - define usage of #address-cells - define 32/64 dts compatibility settings - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) [snip] + # On ARM v8 64-bit systems, where the reg property + size can be 1 or 2 cells (as defined by cpus node's + #address-cells property), this property is + required and matches: + + - On systems running the OS in AArch32: The DTS cannot change based on 32-bit or 64-bit OS. On systems running the OS in AArch32 implies a dependency on the HW execution state. Since the DT is used to configure OSs I thought that could be a valid sentence. Unfortunately this stuff is not C, so I reiterate my point above, before changing it I would like to understand who should say the wording is ok otherwise we could argue forever. It does configure the OS, but not for 32 vs. 64 bit. That is more of a problem for the bootloader to know which mode to boot in and covered under something like Documentation/arm/Booting. Booting ARM vs. Thumb mode would be similar situation. Think about how your PC boots and add to that having a DTB as part of the firmware shipped with your PC. Then the end user can install a 32-bit or 64-bit OS on it. That is the usecase that needs to be supported and having different DTB for 32 and 64 bit is totally broken and doesn't even help solve that problem. + + - cpu-release-addr + Usage: required for systems that have an enable-method + property value of spin-table. + Value type: prop-encoded-array + Definition: + # On ARM v8 64-bit systems must be a two cell + property identifying a 64-bit zero-initialised + memory location. As I mentioned previously, isn't some wake-up method needed? Most systems will be in wfi or wfe rather than continuously spinning. Mmm...this can become a minefield, wfe, wfi, CPU in reset..this needs some thought. Yes, it is today and standardizing this is a good thing. Which is what PSCI does. So why are you adding the spintable at all? Are you trying to set this as the standard for non-PSCI enabled platforms? Why not just say v8 boot interface is PSCI. Sure, we'll probably have to deal with other methods, but documenting something else here is not going to prevent that problem. I don't think a simple spintable would even work for any/most current platforms. I'd think we'd want to define something that would work for existing platforms (chances are new platforms will work like vendors' existing 32-bit platforms). Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
On 07/15/2013 01:40 PM, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This property is no longer required by the GPIO binding. Remove it.
Won't this break compatibility with older kernel? It is one thing to
deprecate, but removal is another. If the relevant maintainers don't
care, then I guess it is fine.
Signed-off-by: Stephen Warren swar...@nvidia.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
---
This should presumably be applied along with the previous changes
The rest looks fine to me. I can take this series, but would actually
prefer that this patch go separately to arm-soc.
Rob
v2: Squash spear and mxc changes into a single patch; there's no
need to keep vf610.dtsi separate now that this series will go into
v3.12 or later, and that file is part of v3.11-rc1.
---
arch/arm/boot/dts/spear1310.dtsi | 1 -
arch/arm/boot/dts/spear1340.dtsi | 1 -
arch/arm/boot/dts/spear310.dtsi | 1 -
arch/arm/boot/dts/spear320.dtsi | 2 --
arch/arm/boot/dts/vf610.dtsi | 1 -
5 files changed, 6 deletions(-)
diff --git a/arch/arm/boot/dts/spear1310.dtsi
b/arch/arm/boot/dts/spear1310.dtsi
index 122ae94..90e99b5 100644
--- a/arch/arm/boot/dts/spear1310.dtsi
+++ b/arch/arm/boot/dts/spear1310.dtsi
@@ -89,7 +89,6 @@
pinmux: pinmux@e070 {
compatible = st,spear1310-pinmux;
reg = 0xe070 0x1000;
- #gpio-range-cells = 3;
};
apb {
diff --git a/arch/arm/boot/dts/spear1340.dtsi
b/arch/arm/boot/dts/spear1340.dtsi
index 54d128d..5003013 100644
--- a/arch/arm/boot/dts/spear1340.dtsi
+++ b/arch/arm/boot/dts/spear1340.dtsi
@@ -63,7 +63,6 @@
pinmux: pinmux@e070 {
compatible = st,spear1340-pinmux;
reg = 0xe070 0x1000;
- #gpio-range-cells = 3;
};
pwm: pwm@e018 {
diff --git a/arch/arm/boot/dts/spear310.dtsi b/arch/arm/boot/dts/spear310.dtsi
index 9537208..1e1318e 100644
--- a/arch/arm/boot/dts/spear310.dtsi
+++ b/arch/arm/boot/dts/spear310.dtsi
@@ -25,7 +25,6 @@
pinmux: pinmux@b400 {
compatible = st,spear310-pinmux;
reg = 0xb400 0x1000;
- #gpio-range-cells = 3;
};
fsmc: flash@4400 {
diff --git a/arch/arm/boot/dts/spear320.dtsi b/arch/arm/boot/dts/spear320.dtsi
index ffea342..f630d0c 100644
--- a/arch/arm/boot/dts/spear320.dtsi
+++ b/arch/arm/boot/dts/spear320.dtsi
@@ -1,4 +1,3 @@
-/*
* DTS file for SPEAr320 SoC
*
* Copyright 2012 Viresh Kumar viresh.li...@gmail.com
@@ -24,7 +23,6 @@
pinmux: pinmux@b300 {
compatible = st,spear320-pinmux;
reg = 0xb300 0x1000;
- #gpio-range-cells = 3;
};
clcd@9000 {
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index e1eb7da..8577780 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -162,7 +162,6 @@
iomuxc: iomuxc@40048000 {
compatible = fsl,vf610-iomuxc;
reg = 0x40048000 0x1000;
- #gpio-range-cells = 3;
/* functions and groups pins */
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4] Input: sysrq - DT binding for key sequence
On 07/15/2013 10:36 AM, mathieu.poir...@linaro.org wrote:
From: Mathieu J. Poirier mathieu.poir...@linaro.org
Adding a simple device tree binding for the specification of key sequences.
Definition of the keys found in the sequence are located in
'include/uapi/linux/input.h'.
For the sysrq driver, holding the sequence of keys down for a specific amount
of time
will reset the system.
Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org
---
changes for v4:
- Moved seach of reset sequence nodes to a single call.
---
.../devicetree/bindings/input/input-reset.txt | 34 ++
drivers/tty/sysrq.c| 54
++
2 files changed, 88 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/input-reset.txt
diff --git a/Documentation/devicetree/bindings/input/input-reset.txt
b/Documentation/devicetree/bindings/input/input-reset.txt
new file mode 100644
index 000..79504af
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/input-reset.txt
@@ -0,0 +1,34 @@
+Input: sysrq reset sequence
+
+A simple binding to represent a set of keys as described in
+include/uapi/linux/input.h. This is to communicate a
+sequence of keys to the sysrq driver. Upon holding the keys
+for a specified amount of time (if specified) the system is
+sync'ed and reset.
+
+Key sequences are global to the system but all the keys in a
+set must be coming from the same input device.
+
+The /chosen node should contain a 'linux,sysrq-reset-seq' child
+node to define a set of keys.
+
+Required property:
+sysrq-reset-seq: array of keycodes
+
+Optional property:
+timeout-ms: duration keys must be pressed together in microseconds
milliseconds (ms) or microseconds (us)?
+before generating a sysrq
+
+Example:
+
+ chosen {
+linux,sysrq-reset-seq {
+keyset = 0x03
+ 0x04
+ 0x0a;
+timeout-ms = 3000;
+};
+ };
+
+Would represent KEY_2, KEY_3 and KEY_9.
+
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index b51c154..01a8729 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -44,6 +44,7 @@
#include linux/uaccess.h
#include linux/moduleparam.h
#include linux/jiffies.h
+#include linux/of.h
#include asm/ptrace.h
#include asm/irq_regs.h
@@ -671,6 +672,50 @@ static void sysrq_detect_reset_sequence(struct
sysrq_state *state,
}
}
+static void sysrq_of_get_keyreset_config(void)
+{
+ unsigned short key;
+ struct device_node *np;
+ const struct property *prop;
+ const __be32 *val;
+ int count, i;
+
+ np = of_find_node_by_path(/chosen/linux,sysrq-reset-seq);
+ if (!np) {
+ pr_debug(No sysrq node found);
+ goto out;
+ }
+
+ prop = of_find_property(np, keyset, NULL);
+ if (!prop || !prop-value) {
+ pr_err(Invalid input keyset);
+ goto out;
+ }
+
+ count = prop-length / sizeof(u32);
+ val = prop-value;
None of the existing helpers to retrieve property arrays doesn't work here?
+
+ if (count SYSRQ_KEY_RESET_MAX)
+ count = SYSRQ_KEY_RESET_MAX;
+
+ /* reset in case a __weak definition was present */
+ sysrq_reset_seq_len = 0;
+
+ for (i = 0; i count; i++) {
+ key = (unsigned short)be32_to_cpup(val++);
+ if (key == KEY_RESERVED || key KEY_MAX)
+ break;
+
+ sysrq_reset_seq[sysrq_reset_seq_len++] = key;
+ }
+
+ /* get reset timeout if any */
+ of_property_read_u32(np, timeout-ms, sysrq_reset_downtime_ms);
+
+ out:
+ ;
+}
+
static void sysrq_reinject_alt_sysrq(struct work_struct *work)
{
struct sysrq_state *sysrq =
@@ -688,6 +733,7 @@ static void sysrq_reinject_alt_sysrq(struct work_struct
*work)
input_inject_event(handle, EV_KEY, KEY_SYSRQ, 1);
input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
+
spurious ws change
input_inject_event(handle, EV_KEY, KEY_SYSRQ, 0);
input_inject_event(handle, EV_KEY, alt_code, 0);
input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
@@ -903,6 +949,7 @@ static inline void sysrq_register_handler(void)
int error;
int i;
+ /* first check if a __weak interface was instantiated */
for (i = 0; i ARRAY_SIZE(sysrq_reset_seq); i++) {
key = platform_sysrq_reset_seq[i];
if (key == KEY_RESERVED || key KEY_MAX)
@@ -911,6 +958,13 @@ static inline void sysrq_register_handler(void)
sysrq_reset_seq[sysrq_reset_seq_len++] = key;
}
+ /*
+ * DT configuration takes precedence over anything
+ * that would have been defined via the __weak
+ * interface
+ */
+
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. Main changes: - adds 64-bit bindings - define usage of #address-cells - define 32/64 dts compatibility settings - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) [snip] + # On ARM v8 64-bit systems, where the reg property + size can be 1 or 2 cells (as defined by cpus node's + #address-cells property), this property is + required and matches: + + - On systems running the OS in AArch32: The DTS cannot change based on 32-bit or 64-bit OS. + + * If the cpus node's #address-cells value is 2: + + The first reg cell must be set to 0. + + The second reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cells must be set to 0. + + * If the cpus node's #address-cells value is 1: + + Bits [23:0] in the reg cell must be set to + bits [23:0] in MPIDR_EL1. + + All other bits in the reg cell must be 0. + + - On systems running the OS in AArch64: + + * If the cpus node's #address-cells value is 2: + + The first reg cell bits [7:0] must be set to + bits [39:32] of MPIDR_EL1. + + The second reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cells must be set to 0. + + * If the cpus node's #address-cells value is 1: + + MPIDR_EL1[63:32] is 0 on all processors in the + system. Your logic is backwards here. If the MPIDR_EL1[63:32] is 0, then #address-cells can be 1. You could say the upper bits are ignored and treated as 0. However, you should simplify all this and just mandate that #address-cells must be 2 for ARMv8 or more generally must match the size of the MPIDR. If we want to boot a 32-bit kernel, then the kernel will have to adapt to support this. + + The reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cell must be set to 0. + + - compatible: + Usage: required + Value type: string + Definition: should be one of: + arm,arm710t + arm,arm720t + arm,arm740t + arm,arm7ej-s + arm,arm7tdmi + arm,arm7tdmi-s + arm,arm9es + arm,arm9ej-s + arm,arm920t + arm,arm922t + arm,arm925 + arm,arm926e-s + arm,arm926ej-s + arm,arm940t + arm,arm946e-s + arm,arm966e-s + arm,arm968e-s + arm,arm9tdmi + arm,arm1020e + arm,arm1020t + arm,arm1022e + arm,arm1026ej-s + arm,arm1136j-s + arm,arm1136jf-s + arm,arm1156t2-s + arm,arm1156t2f-s + arm,arm1176jzf + arm,arm1176jz-s + arm,arm1176jzf-s + arm,arm11mpcore + arm,cortex-a5 + arm,cortex-a7 + arm,cortex-a8 + arm,cortex-a9 + arm,cortex-a15 + arm,cortex-a53 + arm,cortex-a57 + arm,cortex-m0 +
Re: Sharing *.dtsi between Linux architectures?
On 07/12/2013 02:58 PM, Stephen Warren wrote: Is there a (possibly just proposed) mechanism in place to allow *.dts from multiple Linux architectures to share common *.dtsi files? Nothing proposed yet. There was some discussion at Connect (which I missed part of). We're certainly going to start to have that issue between arm and arm64 as well as probably FSL powerpc and arm. I would like to move all dts files out of arch. I think we should think about how we construct a separate dts repository and then move the kernel structure in that direction (it's still believed there is too much interdependency to have separate repo yet). I don't think cpu architecture is the right top level structure for dts files. Probably something by vendor and/or SOC family is more appropriate. Then you have to figure out how to handle board vs. chip vendors. As an example, consider two SoCs that are identical except for the CPU complex. One uses an ARMv7 CPU (DTs in arch/arm/boot/dts/) and the other uses some ARMv8 CPU (DTs in arch/am64/boot/dts/). It'd be useful to define all the SoC components in some common .dtsi file to avoid duplication, and have both arch/arm/boot/dts/tegraXXX.dtsi and arch/arm64/boot/dts/tegraYYY.dtsi include that and add the relevant CPU-related nodes. I could imagine creating one of the following paths for this purpose: arch/common/dts/ include/dt-common/ include/dtsi/ ... or perhaps re-using the existing: include/dt-bindings/ ... although my original intent for that last location was just to house header files that define constants that are part of binding definitions, rather than actual structural content. I think we should stick with defines there. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] gps6507x.txt: Remove executable bits
On 07/12/2013 12:31 PM, Joe Perches wrote: Documentation shouldn't be executable. Signed-off-by: Joe Perches j...@perches.com Acked-by: Rob Herring rob.herr...@calxeda.com --- diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt b/Documentation/devicetree/bindings/mfd/tps6507x.txt old mode 100755 new mode 100644 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: match the compatible in the order set by the dts file
On Tue, Jul 9, 2013 at 3:10 AM, Huang Shijie b32...@freescale.com wrote:
于 2013年07月09日 15:51, Sascha Hauer 写道:
On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
于 2013年07月09日 15:05, Sascha Hauer 写道:
Why don't you set the matching order in the driver the way you want it
to be, i.e.:
{ .compatible = fsl,imx6q-uart, ... },
{ .compatible = fsl,imx21-uart, ... },
{ .compatible = fsl,imx1-uart, ... },
yes. i can set it like this.
but this method looks like a ugly workaround.
If a driver has different ways of supporting a single device, then
putting the preferred or most feature rich on top doesn't look very ugly
to me.
this method makes it much _coupled_ between the driver and the dts file.
IMHO, it's an unnecessary _burden_ to the driver programmer:
he should puts the most feature compatible on the top.
it's much graceful if we let the driver programmer be transparent about
this.
The dts requires compatible strings to be most specific to least
specific. There is no reason that driver match tables should not be
the same and that is the assumption. Matching is not just based on
compatible properties and your patch does not handle the other cases.
Rob
thanks
Huang Shijie
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/6] misc: sram: add ability to mark sram sections as reserved
On Fri, Jul 5, 2013 at 7:41 AM, Heiko Stübner he...@sntech.de wrote:
Some SoCs need parts of their sram for special purposes. So while being part
of the periphal, it should not be part of the genpool controlling the sram.
s/periphal/peripheral/
Threfore add an option mmio-sram-reserved to keep arbitary portions of the
s/Threfore/Therefore/
s/arbitary/arbitrary/
sram from being part of the pool.
Suggested-by: Rob Herring robherri...@gmail.com
Signed-off-by: Heiko Stuebner he...@sntech.de
Tested-by: Ulrich Prinz ulrich.pr...@googlemail.com
---
Documentation/devicetree/bindings/misc/sram.txt |8 +++
drivers/misc/sram.c | 80
+--
2 files changed, 82 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/misc/sram.txt
b/Documentation/devicetree/bindings/misc/sram.txt
index 4d0a00e..eae080e 100644
--- a/Documentation/devicetree/bindings/misc/sram.txt
+++ b/Documentation/devicetree/bindings/misc/sram.txt
@@ -8,9 +8,17 @@ Required properties:
- reg : SRAM iomem address range
+Optional properties:
+
+- mmio-sram-reserved: ordered list of reserved chunks inside the sram that
+ should not become part of the genalloc pool.
genalloc is linux specific. should not be used by the OS would be better.
+ Format is base size, base size, ...; with base being relative to the
+ reg property base.
+
Example:
sram: sram@5c00 {
compatible = mmio-sram;
reg = 0x5c00 0x4; /* 256 KiB SRAM at address 0x5c00 */
+ mmio-sram-reserved = 0x0 0x100; /* reserve 0x5c00-0x5c000100 */
};
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index afe66571..9131e4a 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -42,6 +42,13 @@ static int sram_probe(struct platform_device *pdev)
struct sram_dev *sram;
struct resource *res;
unsigned long size;
+ const __be32 *reserved_list = NULL;
+ int reserved_size = 0;
+ unsigned int cur_start = 0;
+ unsigned int cur_size;
+ unsigned int rstart;
+ unsigned int rsize;
Use one line for each type.
+ int i;
int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -65,12 +72,73 @@ static int sram_probe(struct platform_device *pdev)
if (!sram-pool)
return -ENOMEM;
- ret = gen_pool_add_virt(sram-pool, (unsigned long)virt_base,
- res-start, size, -1);
- if (ret 0) {
- if (sram-clk)
- clk_disable_unprepare(sram-clk);
- return ret;
+ if (pdev-dev.of_node) {
+ reserved_list = of_get_property(pdev-dev.of_node,
+ mmio-sram-reserved,
+ reserved_size);
+ if (reserved_list) {
+ reserved_size /= sizeof(*reserved_list);
+ if (!reserved_size || reserved_size % 2) {
+ dev_warn(pdev-dev, wrong number of
arguments in mmio-sram-reserved\n);
+ reserved_list = NULL;
+ }
+ }
+ }
+
+ if (!reserved_list)
+ reserved_size = 0;
This can be moved to where you set reserved_list to NULL.
+
+ for (i = 0; i (reserved_size + 2); i += 2) {
+ if (i reserved_size) {
This loop is hard to follow. For example, it is not immediate obvious
why you loop an extra time. I think it would be more straight forward
to determine the free regions first and then do the allocations. This
will require a kmalloc or fixed max number of regions, but would
improve readability.
Rob
+ /* get the next reserved block */
+ rstart = be32_to_cpu(*reserved_list++);
+ rsize = be32_to_cpu(*reserved_list++);
+
+ /* catch unsorted list entries */
+ if (rstart cur_start) {
+ dev_err(pdev-dev,
+ unsorted reserved list (0x%x before
current 0x%x)\n,
+ rstart, cur_start);
+ if (sram-clk)
+ clk_disable_unprepare(sram-clk);
+ return -EINVAL;
+ }
+
+ dev_dbg(pdev-dev,
+ found reserved block 0x%x-0x%x\n,
+ rstart, rstart + rsize);
+ } else {
+ /* the last chunk extends to the end of the region */
+ rstart = size;
+ rsize = 0;
+ }
+
+ /* current start is in a reserved block
Re: [PATCH] of: Fix address decoding on Bimini and js2x machines
On 07/03/2013 01:01 AM, Benjamin Herrenschmidt wrote:
Commit:
e38c0a1fbc5803cbacdaac0557c70ac8ca5152e7
of/address: Handle #address-cells 2 specially
broke real time clock access on Bimini, js2x, and similar powerpc
machines using the maple platform. That code was indirectly relying
on the old (broken) behaviour of the translation for the hypertransport
to ISA bridge.
This fixes it by treating hypertransport as a PCI bus
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: sta...@vger.kernel.org [v3.6+]
---
Rob, if you have no objection I will put that in powerpc -next
NP.
Acked-by: Rob Herring rob.herr...@calxeda.com
Rob
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..7c8221d 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -106,8 +106,12 @@ static unsigned int of_bus_default_get_flags(const
__be32 *
static int of_bus_pci_match(struct device_node *np)
{
- /* vci is for the /chaos bridge on 1st-gen PCI powermacs */
- return !strcmp(np-type, pci) || !strcmp(np-type, vci);
+ /*
+* vci is for the /chaos bridge on 1st-gen PCI powermacs
+* ht is hypertransport
+*/
+ return !strcmp(np-type, pci) || !strcmp(np-type, vci) ||
+ !strcmp(np-type, ht);
}
static void of_bus_pci_count_cells(struct device_node *np,
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] of: Specify initrd location using 64-bit
On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch globally modifies the early_init_dt_setup_initrd_arch() function to
use 64-bit numbers instead of the current unsigned long.
There has been quite a bit of debate about whether to use u64 or phys_addr_t.
It was concluded to stick to u64 to be consistent with rest of the device
tree code. As summarized by Geert, The address to load the initrd is decided
by the bootloader/user and set at that point later in time. The dtb should not
be tied to the kernel you are booting
That was quoting me. Otherwise:
Acked-by: Rob Herring rob.herr...@calxeda.com
Unless Grant feels compelled to pick this up for 3.11, I think it has to
wait for 3.12.
Rob
More details on the discussion can be found here:
https://lkml.org/lkml/2013/6/20/690
https://lkml.org/lkml/2012/9/13/544
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Vineet Gupta vgu...@synopsys.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Mark Salter msal...@redhat.com
Cc: Aurelien Jacquiot a-jacqu...@ti.com
Cc: James Hogan james.ho...@imgtec.com
Cc: Michal Simek mon...@monstr.eu
Cc: Ralf Baechle r...@linux-mips.org
Cc: Jonas Bonn jo...@southpole.se
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: x...@kernel.org
Cc: a...@kernel.org
Cc: Chris Zankel ch...@zankel.net
Cc: Max Filippov jcmvb...@gmail.com
Cc: bige...@linutronix.de
Cc: robherri...@gmail.com
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-c6x-...@linux-c6x.org
Cc: linux-m...@linux-mips.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-xte...@linux-xtensa.org
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arc/mm/init.c|5 ++---
arch/arm/mm/init.c|2 +-
arch/arm64/mm/init.c |3 +--
arch/c6x/kernel/devicetree.c |3 +--
arch/metag/mm/init.c |5 ++---
arch/microblaze/kernel/prom.c |3 +--
arch/mips/kernel/prom.c |3 +--
arch/openrisc/kernel/prom.c |3 +--
arch/powerpc/kernel/prom.c|3 +--
arch/x86/kernel/devicetree.c |3 +--
arch/xtensa/kernel/setup.c|3 +--
drivers/of/fdt.c | 10 ++
include/linux/of_fdt.h|3 +--
13 files changed, 20 insertions(+), 29 deletions(-)
diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index 4a17736..7991e08 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -157,9 +157,8 @@ void __init free_initrd_mem(unsigned long start, unsigned
long end)
#endif
#ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
- pr_err(%s(%lx, %lx)\n, __func__, start, end);
+ pr_err(%s(%llx, %llx)\n, __func__, start, end);
}
#endif /* CONFIG_OF_FLATTREE */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 9a5cdc0..afeaef7 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
__tagtable(ATAG_INITRD2, parse_tag_initrd2);
#ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned
long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
phys_initrd_start = start;
phys_initrd_size = end - start;
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f497ca7..7047708 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -44,8 +44,7 @@ static unsigned long phys_initrd_size __initdata = 0;
phys_addr_t memstart_addr __read_mostly = 0;
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
phys_initrd_start = start;
phys_initrd_size = end - start;
diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
index bdb56f0..287d0e6 100644
--- a/arch/c6x/kernel/devicetree.c
+++ b/arch/c6x/kernel/devicetree.c
@@ -33,8 +33,7 @@ void __init early_init_devtree(void *params)
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end
Re: [PATCH] of: Specify initrd location using 64-bit
On 06/21/2013 12:20 PM, Santosh Shilimkar wrote:
On Friday 21 June 2013 05:04 AM, Sebastian Andrzej Siewior wrote:
On 06/21/2013 02:52 AM, Santosh Shilimkar wrote:
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index 0a2c68f..62e2e8f 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
}
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
I think it would better to go here for phys_addr_t instead of u64. This
would force you in of_flat_dt_match() to check if the value passed from
DT specifies a memory address outside of 32bit address space and the
kernel can't deal with this because its phys_addr_t is 32bit only due
to a Kconfig switch.
For x86, the initrd has to remain in the 32bit address space so passing
the initrd in the upper range would violate the ABI. Not sure if this
is true for other archs as well (ARM obviously not).
That pretty much means phys_addr_t. It will work for me as well but
in last thread from consistency with memory and reserved node, Rob
insisted to keep it as u64. So before I re-spin another version,
would like to here what Rob has to say considering the x86 requirement.
Rob,
Are you ok with phys_addr_t since your concern was about rest
of the memory specific bits of the device-tree code use u64 ?
No. I still think it should be u64 for same reasons I said originally.
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Add more stubs for non-OF builds
Perhaps a more specific subject.
On 06/17/2013 12:24 PM, Alexander Shiyan wrote:
Patch adds of_get_next_child and of_get_next_available_child
stubs for non-OF builds.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
What changed for v2?
include/linux/of.h | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 1fd08ca..df0e644 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -366,8 +366,17 @@ static inline bool of_have_populated_dt(void)
return false;
}
-#define for_each_child_of_node(parent, child) \
- while (0)
+static struct device_node *of_get_next_child(const struct device_node *node,
+ struct device_node *prev)
+{
+ return NULL;
+}
+
+static struct device_node *of_get_next_available_child(
+ const struct device_node *node, struct device_node *prev)
+{
+ return NULL;
+}
static inline struct device_node *of_get_child_by_name(
const struct device_node *node,
@@ -376,6 +385,9 @@ static inline struct device_node *of_get_child_by_name(
return NULL;
}
+#define for_each_child_of_node(parent, child) \
parent and child need unused annotations to avoid unused variable warnings.
Rob
+ while (0)
+
static inline int of_get_child_count(const struct device_node *np)
{
return 0;
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH REBASE] i2c-designware: make SDA hold time configurable
On 05/14/2013 08:04 AM, Christian Ruppert wrote:
This patch makes the SDA hold time configurable through device tree.
[rebased to i2c-current/i2c-next/mainline-3.10-rc1]
Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
Signed-off-by: Pierrick Hascoet pierrick.hasc...@abilis.com
---
.../devicetree/bindings/i2c/i2c-designware.txt | 14 ++
drivers/i2c/busses/i2c-designware-core.c |5 +
drivers/i2c/busses/i2c-designware-core.h |1 +
drivers/i2c/busses/i2c-designware-platdrv.c|9 +
4 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
index e42a2ee..21fabe7 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
@@ -10,6 +10,9 @@ Recommended properties :
- clock-frequency : desired I2C bus clock frequency in Hz.
+Optional properties :
+ - sda-hold-time : should contain the SDA hold time in nanoseconds.
Please specify time units in the property name. Perhaps
i2c-sda-hold-time-ns.
Based on reading the discussion, there is one similar property I have
found: samsung,i2c-sda-delay = 100. I wouldn't copy it as it doesn't
tell the units or what the delay is.
Otherwise, looks fine to me.
Rob
+
Example :
i2c@f {
@@ -20,3 +23,14 @@ Example :
interrupts = 11;
clock-frequency = 40;
};
+
+ i2c@112 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = snps,designware-i2c;
+ reg = 0x112 0x1000;
+ interrupt-parent = ictl;
+ interrupts = 12 1;
+ clock-frequency = 40;
+ sda-hold-time = 300;
+ };
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index 21fbb34..91d422c 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -67,6 +67,7 @@
#define DW_IC_STATUS 0x70
#define DW_IC_TXFLR 0x74
#define DW_IC_RXFLR 0x78
+#define DW_IC_SDA_HOLD 0x7c
#define DW_IC_TX_ABRT_SOURCE 0x80
#define DW_IC_ENABLE_STATUS 0x9c
#define DW_IC_COMP_PARAM_1 0xf4
@@ -332,6 +333,10 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
dw_writel(dev, lcnt, DW_IC_FS_SCL_LCNT);
dev_dbg(dev-dev, Fast-mode HCNT:LCNT = %d:%d\n, hcnt, lcnt);
+ /* Configure SDA Hold Time if required */
+ if (dev-sda_hold_time)
+ dw_writel(dev, dev-sda_hold_time, DW_IC_SDA_HOLD);
+
/* Configure Tx/Rx FIFO threshold levels */
dw_writel(dev, dev-tx_fifo_depth - 1, DW_IC_TX_TL);
dw_writel(dev, 0, DW_IC_RX_TL);
diff --git a/drivers/i2c/busses/i2c-designware-core.h
b/drivers/i2c/busses/i2c-designware-core.h
index 9c1840e..33dfec3 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -88,6 +88,7 @@ struct dw_i2c_dev {
u32 master_cfg;
unsigned inttx_fifo_depth;
unsigned intrx_fifo_depth;
+ u32 sda_hold_time;
};
#define ACCESS_SWAP 0x0001
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 8ec9133..589f414 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -34,6 +34,7 @@
#include linux/sched.h
#include linux/err.h
#include linux/interrupt.h
+#include linux/of.h
#include linux/of_i2c.h
#include linux/platform_device.h
#include linux/pm.h
@@ -120,6 +121,14 @@ static int dw_i2c_probe(struct platform_device *pdev)
return PTR_ERR(dev-clk);
clk_prepare_enable(dev-clk);
+ if (pdev-dev.of_node) {
+ u32 ht;
+ u32 ic_clk = dev-get_clk_rate_khz(dev);
+
+ of_property_read_u32(pdev-dev.of_node, sda-hold-time, ht);
+ dev-sda_hold_time = ((u64)ic_clk * ht + 50) / 100;
+ }
+
dev-functionality =
I2C_FUNC_I2C |
I2C_FUNC_10BIT_ADDR |
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: socfpga: dts: Add support for SD/MMC
On 06/11/2013 07:28 PM, dingu...@altera.com wrote:
From: Dinh Nguyen dingu...@altera.com
Add bindings for SD/MMC for SOCFPGA.
Add syscon to the altr,sys-mgr binding.
Not sure how I see syscon is related to SD? That is a pretty vague name
as well.
Signed-off-by: Dinh Nguyen dingu...@altera.com
Reviewed-by: Pavel Machek pa...@denx.de
CC: Arnd Bergmann a...@arndb.de
CC: Olof Johansson o...@lixom.net
Cc: Pavel Machek pa...@denx.de
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Chris Ball c...@laptop.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
CC: li...@arm.linux.org.uk
v2:
- Add syscon to altr,sys-mgr
- Remove pwr-en field
---
.../devicetree/bindings/mmc/socfpga-dw-mshc.txt| 60
arch/arm/boot/dts/socfpga.dtsi | 13 -
arch/arm/boot/dts/socfpga_cyclone5.dts | 13 +
arch/arm/boot/dts/socfpga_vt.dts | 12
4 files changed, 97 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
new file mode 100644
index 000..9d7062c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
@@ -0,0 +1,60 @@
+* Altera SOCFPGA specific extensions to the Synopsis Designware Mobile
+ Storage Host Controller
+
+Required Properties:
+
+* compatible: should be
+ - altr,socfpga-dw-mshc: for controllers with Altera SOCFPGA
+ specific extentions.
s/extentions/extensions/
+
+* altr,dw-mshc-ciu-div: Specifies the divider value for the card interface
+ unit (ciu) clock. The value should be (n-1). For Altera's SOCFPGA, the
divider
+ value is fixed at 3, which mean parent_clock/4.
+
+* altr,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift value
+ in transmit mode and CIU clock phase shift value in receive mode for single
+ data rate mode operation. Refer notes below for the order of the cells and
the
+ valid values.
+
+ Notes for the sdr-timing values:
+
+The order of the cells should be
+ - First Cell: CIU clock phase shift value for RX mode, smplsel bits in
+ the system manager SDMMC control group.
+ - Second Cell: CIU clock phase shift value for TX mode, drvsel bits in
+ the system manager SDMMC control group.
+
+Valid values for SDR CIU clock timing for SOCFPGA:
+ - valid value for tx phase shift and rx phase shift is 0 to 7.
+
+Required properties for a slot:
+
+* bus-width: Data width for card slot. 4-bit or 8-bit data.
+
+Example:
+
+ The MSHC controller node can be split into two portions, SoC specific and
+ board specific portions as listed below.
+
+ dwmmc0@ff704000 {
+ compatible = altr,socfpga-dw-mshc;
+ reg = 0xff704000 0x1000;
+ interrupts = 0 139 4;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
+
+ dwmmc0@ff704000 {
+ num-slots = 1;
+ supports-highspeed;
+ broken-cd;
+ fifo-depth = 0x400;
Are these already documented. If so, can you add a reference to the
binding doc.
+ altr,dw-mshc-ciu-div = 3;
+ altr,dw-mshc-sdr-timing = 0 3;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 4;
+ };
+ };
+
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index bee62a2..dbf7f22 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -468,6 +468,17 @@
cache-level = 2;
};
+ mmc: dwmmc0@ff704000 {
+ compatible = altr,socfpga-dw-mshc;
+ reg = 0xff704000 0x1000;
+ interrupts = 0 139 4;
+ fifo-depth = 0x400;
+ #address-cells = 1;
+ #size-cells = 0;
+ clocks = l4_mp_clk, sdmmc_clk;
+ clock-names = biu, ciu;
+ };
+
/* Local timer */
timer@fffec600 {
compatible = arm,cortex-a9-twd-timer;
@@ -521,7 +532,7 @@
};
sysmgr@ffd08000 {
- compatible = altr,sys-mgr;
+ compatible = altr,sys-mgr, syscon;
reg = 0xffd08000 0x4000;
};
};
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dts
b/arch/arm/boot/dts/socfpga_cyclone5.dts
index 973999d..1853cb1 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dts
@@ -54,6 +54,19 @@
status = okay
Re: [RFC] dw_apb_timer_of: use clocksource_of_init
On 06/03/2013 07:15 AM, Heiko Stübner wrote: dw_apb_timer_init used to search the devicetree for matching timer devices, making calls to it from board files necessary. Change the dw_apb_timer_init to work with CLOCKSOURCE_OF_DECLARE. With this change the function gets called once for each timer node and tracks these number of calls to attach clockevent and clocksource devices to the nodes. Also convert all previous users of dw_apb_timer_init to use clocksource_of_init. Tested on the upcoming rk3066 code. Signed-off-by: Heiko Stuebner he...@sntech.de Acked-by: Rob Herring rob.herr...@calxeda.com But 1 comment: @@ -88,7 +88,7 @@ DT_MACHINE_START(PICOXCELL, Picochip picoXcell) .map_io = picoxcell_map_io, .nr_irqs= NR_IRQS_LEGACY, .init_irq = irqchip_init, - .init_time = dw_apb_timer_init, + .init_time = clocksource_of_init, clocksource_of_init is the default now, so you can just remove this and the one in socfpga. Same for irqchip_init BTW, but that's another patch. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC] [PATCH 3/3] IRQ: irq domain: defer of irq ressoure resolve at platform_drv_probe
On 05/28/2013 10:08 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
Today in the current of implementation we populate all the ressources
typo
at of_platform_populate time. But this leed to a chicken-egg dilemat
2 typos
some the irq present in DT are from platform_device too. And you can
not resolve them as of_platform_populate. So delay the populate of irq
at platform_drv_probe.
And if the irq_domain is not yet present just defer the probe (GPIO as
example)
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Ralf Baechle r...@linux-mips.org
Cc: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/base/platform.c |5 +
drivers/of/platform.c | 29 +++--
include/linux/of_platform.h |7 +++
3 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 9eda842..c0f7906 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -13,6 +13,7 @@
#include linux/string.h
#include linux/platform_device.h
#include linux/of_device.h
+#include linux/of_platform.h
#include linux/module.h
#include linux/init.h
#include linux/dma-mapping.h
@@ -484,6 +485,10 @@ static int platform_drv_probe(struct device *_dev)
struct platform_device *dev = to_platform_device(_dev);
int ret;
+ ret = of_device_init_irq(dev);
+ if (ret)
+ return ret;
+
if (ACPI_HANDLE(_dev))
acpi_dev_pm_attach(_dev, true);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 00a0971..c290943 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -131,6 +131,32 @@ void of_device_make_bus_id(struct device *dev)
}
/**
+ * of_device_alloc_irq - initialize irq of an platfrom_device
typo
+ * @dev: plaform_device to work on
same word, different typo.
+ */
+int of_device_init_irq(struct platform_device *dev)
+{
+ struct device_node *np = dev-dev.of_node;
+ int num_irq;
+ int ret;
+ struct resource *res = dev-resource;
+
+ if (!np)
+ return 0;
+
+ num_irq = of_irq_count(np);
+ if (!num_irq)
+ return 0;
+
+ res += dev-num_resources - num_irq;
This looks fragile to me as it relies on how of_device_alloc happens to
be implemented.
+ ret = of_irq_to_resource_table(np, res, num_irq);
+ if (ret != num_irq)
+ return -EPROBE_DEFER;
+
+ return 0;
+}
+
+/**
* of_device_alloc - Allocate and initialize an of_device
* @np: device node to assign to device
* @bus_id: Name to assign to the device. May be null to use default name.
@@ -152,7 +178,7 @@ struct platform_device *of_device_alloc(struct
device_node *np,
if (of_can_translate_address(np))
while (of_address_to_resource(np, num_reg, temp_res) == 0)
num_reg++;
- num_irq = of_irq_valid_count(np);
+ num_irq = of_irq_count(np);
/* Populate the resource table */
if (num_irq || num_reg) {
@@ -168,7 +194,6 @@ struct platform_device *of_device_alloc(struct
device_node *np,
rc = of_address_to_resource(np, i, res);
WARN_ON(rc);
}
- WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
}
dev-dev.of_node = of_node_get(np);
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 3863a4d..b5f9bb6 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -79,6 +79,7 @@ extern const struct of_device_id
of_default_bus_match_table[];
extern struct platform_device *of_device_alloc(struct device_node *np,
const char *bus_id,
struct device *parent);
+extern int of_device_init_irq(struct platform_device *dev);
extern struct platform_device *of_find_device_by_node(struct device_node
*np);
#ifdef CONFIG_OF_ADDRESS /* device reg helpers depend on OF_ADDRESS */
@@ -101,6 +102,7 @@ extern int of_platform_populate(struct device_node *root,
#if !defined(CONFIG_OF_ADDRESS)
struct of_dev_auxdata;
struct device;
+struct platform_device;
static inline int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
@@ -108,6 +110,11 @@ static inline int of_platform_populate(struct
device_node *root,
{
return -ENODEV;
}
+
+static inline int of_device_init_irq(struct platform_device *dev)
+{
+ return 0;
+}
#endif /* !CONFIG_OF_ADDRESS */
#endif
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On Thu, Apr 25, 2013 at 3:45 PM, Rob Herring robherri...@gmail.com wrote: On 04/25/2013 03:12 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-04-25 at 14:14 -0500, Rob Herring wrote: On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote: [...] You need patch 2 of this series to fix this: driver core: move to_platform_driver to platform_device.h which as Arnd pointed out needs to come first. I've fixed that in my tree, but I don't think it warrants another post. Can I pull you tree from somewhere to test ? Here you go: git://sources.calxeda.com/kernel/linux.git of-platform-removal Ben, Did you have a chance to test this? I want to get this into -next. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 01/18] ARM: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodes
On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
The introduction of the cpu-map topology node in the cpus node implies
that cpus node might have children that are not cpu nodes. The DT
parsing code needs updating otherwise it would check for cpu nodes
properties in nodes that are not required to contain them, resulting
in warnings that have no bearing on bindings defined in the dts source file.
Great, so a new DT with cpu-map entries may not work with old kernels.
Please check the behavior. This should go to stable kernels.
Rob
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/devtree.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5af04f6..904cad5 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -92,6 +92,9 @@ void __init arm_dt_init_cpu_maps(void)
for_each_child_of_node(cpus, cpu) {
u32 hwid;
+ if (of_node_cmp(cpu-type, cpu))
+ continue;
+
pr_debug( * %s...\n, cpu-full_name);
/*
* A device tree containing CPU nodes with missing reg
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] linux/of_platform.h: fix compilation warnings with DT disabled
On Thu, May 16, 2013 at 3:58 PM, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: Hello. On 03/01/2013 05:02 PM, Rob Herring wrote: Fix the following compilation warnings (in Simon Horman's renesas.git repo): In file included from arch/arm/mach-shmobile/setup-r8a7779.c:24:0: include/linux/of_platform.h:107:13: warning: ‘struct of_device_id’ declared inside parameter list [enabled by default] include/linux/of_platform.h:107:13: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] include/linux/of_platform.h:107:13: warning: ‘struct device_node’ declared inside parameter list [enabled by default] linux/of_platform.h only #include's headers with definitions of the above mentioned structures if CONFIG_OF_DEVICE=y but uses them even if not. One solution is to move some #include's out of #ifdef CONFIG_OF_DEVICE and use incomplete declarations for the rest of the structures where the #ifdef move doesn't help... Reported-by: Vladimir Barinov vladimir.bari...@cogentembedded.com Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Reviewed-by: Simon Horman horms+rene...@verge.net.au Grant, could you consider taking this patch? Yes, I can, but I don't seem to have the original patch. Can you send it again. Nevermind. Found it. I'll apply it. Will you drop 'struct device_node' declaration then or should I resend? In fact, I think I should better resend it with the changelog somewhat edited. No, I plan to leave it as is and not rely on device.h by chance declaring device_node. I hoped to see this fix in 3.10-rc1. Is there any hope to see it in 3.10-rc's? The code it fixes the warnings in is already in Linus tree. So I had this queued up, but Grant did not send DT update to Linus for 3.10. The main thing we had was the preprocessor support and that went thru arm-soc tree. I plan to send this and other fixes to Linus for 3.10. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 2/8] ARM:global_timer: Add ARM global timer support.
On 05/08/2013 09:11 AM, Srinivas KANDAGATLA wrote:
From: Stuart Menefy stuart.men...@st.com
This is a simple driver for the global timer module found in the Cortex
A9-MP cores from revision r1p0 onwards. This should be able to perform
the functions of the system timer and the local timer in an SMP system.
The global timer has the following features:
The global timer is a 64-bit incrementing counter with an
auto-incrementing feature. It continues incrementing after sending
interrupts. The global timer is memory mapped in the private memory
region.
The global timer is accessible to all Cortex-A9 processors in the
cluster. Each Cortex-A9 processor has a private 64-bit comparator that
is used to assert a private interrupt when the global timer has reached
the comparator value. All the Cortex-A9 processors in a design use the
banked ID, ID27, for this interrupt. ID27 is sent to the Interrupt
Controller as a Private Peripheral Interrupt. The global timer is
clocked by PERIPHCLK.
PERIPHCLK scales with cpu clock typically so the global timer is not a
suitable clocksource if you use cpufreq. You can deal with the scaling
on clockevents, but not a clocksource. I imagine the global timers is
also typically power-gated in some low power modes. This is why no one
has added support already. Are neither of those an issue or going to be
an issue for you?
Rob
Signed-off-by: Stuart Menefy stuart.men...@st.com
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
Documentation/devicetree/bindings/arm/gt.txt | 21 ++
arch/arm/Kconfig |6 +
arch/arm/include/asm/global_timer.h | 12 +
arch/arm/kernel/Makefile |1 +
arch/arm/kernel/global_timer.c | 325
++
5 files changed, 365 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/gt.txt
create mode 100644 arch/arm/include/asm/global_timer.h
create mode 100644 arch/arm/kernel/global_timer.c
diff --git a/Documentation/devicetree/bindings/arm/gt.txt
b/Documentation/devicetree/bindings/arm/gt.txt
new file mode 100644
index 000..4ec5fb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/gt.txt
@@ -0,0 +1,21 @@
+
+* ARM Global Timer
+ Cortex-A9 are often associated with a per-core Global timer.
+
+** Timer node required properties:
+
+- compatible : Should be one of:
+ arm,cortex-a9-global-timer
+
+- interrupts : One interrupt to each core
+
+- reg : Specify the base address and the size of the GT timer
+ register window.
+
+Example:
+
+ gt-timer@2c000600 {
+ compatible = arm,cortex-a9-global-timer;
+ reg = 0x2c000600 0x20;
+ interrupts = 1 13 0xf01;
+ };
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..c8c524e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1606,6 +1606,12 @@ config HAVE_ARM_TWD
help
This options enables support for the ARM timer and watchdog unit
+config HAVE_ARM_GT
+ bool
+ select CLKSRC_OF if OF
+ help
+ This options enables support for the ARM global timer unit
+
choice
prompt Memory split
default VMSPLIT_3G
diff --git a/arch/arm/include/asm/global_timer.h
b/arch/arm/include/asm/global_timer.h
new file mode 100644
index 000..46f9188
--- /dev/null
+++ b/arch/arm/include/asm/global_timer.h
@@ -0,0 +1,12 @@
+/*
+ * arch/arm/include/asm/global_timer.h
+ *
+ * Copyright (C) 2013 STMicroelectronics (RD) Limited.
+ * Author: Stuart Menefy stuart.men...@st.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+int __init global_timer_init(void __iomem *base, unsigned int timer_irq);
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..af51808 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_ARM_CPU_SUSPEND) += sleep.o suspend.o
obj-$(CONFIG_SMP)+= smp.o smp_tlb.o
obj-$(CONFIG_HAVE_ARM_SCU) += smp_scu.o
obj-$(CONFIG_HAVE_ARM_TWD) += smp_twd.o
+obj-$(CONFIG_HAVE_ARM_GT)+= global_timer.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arch_timer.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o insn.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o insn.o
diff --git a/arch/arm/kernel/global_timer.c b/arch/arm/kernel/global_timer.c
new file mode 100644
index 000..0ab1af3
--- /dev/null
+++ b/arch/arm/kernel/global_timer.c
@@ -0,0 +1,325 @@
+/*
+ * linux/arch/arm/kernel/global_timer.c
+ *
+ * Copyright (C) 2013 STMicroelectronics (RD) Limited.
+ * Author: Stuart Menefy stuart.men...@st.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General
Re: [patch 8/8] irqchip: sun4i: Convert to generic irq chip
On 05/06/2013 09:30 AM, Thomas Gleixner wrote:
Proof of concept patch to demonstrate the new irqdomain support for
the generic irq chip. Untested !!
Signed-off-by: Thomas Gleixner t...@linutronix.de
Cc: Maxime Ripard maxime.rip...@free-electrons.com
---
drivers/irqchip/irq-sun4i.c | 100
1 file changed, 29 insertions(+), 71 deletions(-)
Index: linux-2.6/drivers/irqchip/irq-sun4i.c
===
--- linux-2.6.orig/drivers/irqchip/irq-sun4i.c
+++ linux-2.6/drivers/irqchip/irq-sun4i.c
@@ -32,70 +32,43 @@
#define SUN4I_IRQ_FIQ_PENDING_REG(x) (0x20 + 0x4 * x)
#define SUN4I_IRQ_ENABLE_REG(x) (0x40 + 0x4 * x)
#define SUN4I_IRQ_MASK_REG(x)(0x50 + 0x4 * x)
+#define SUN4I_NUM_CHIPS 3
+#define SUN4I_IRQS_PER_CHIP 32
static void __iomem *sun4i_irq_base;
static struct irq_domain *sun4i_irq_domain;
static asmlinkage void __exception_irq_entry sun4i_handle_irq(struct pt_regs
*regs);
-void sun4i_irq_ack(struct irq_data *irqd)
+static int __init sun4i_init_domain_chips(void)
{
- unsigned int irq = irqd_to_hwirq(irqd);
- unsigned int irq_off = irq % 32;
- int reg = irq / 32;
- u32 val;
-
- val = readl(sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
- writel(val | (1 irq_off),
-sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
-}
-
-static void sun4i_irq_mask(struct irq_data *irqd)
-{
- unsigned int irq = irqd_to_hwirq(irqd);
- unsigned int irq_off = irq % 32;
- int reg = irq / 32;
- u32 val;
-
- val = readl(sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(reg));
- writel(val ~(1 irq_off),
-sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(reg));
-}
-
-static void sun4i_irq_unmask(struct irq_data *irqd)
-{
- unsigned int irq = irqd_to_hwirq(irqd);
- unsigned int irq_off = irq % 32;
- int reg = irq / 32;
- u32 val;
-
- val = readl(sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(reg));
- writel(val | (1 irq_off),
-sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(reg));
-}
-
-static struct irq_chip sun4i_irq_chip = {
- .name = sun4i_irq,
- .irq_ack= sun4i_irq_ack,
- .irq_mask = sun4i_irq_mask,
- .irq_unmask = sun4i_irq_unmask,
-};
-
-static int sun4i_irq_map(struct irq_domain *d, unsigned int virq,
- irq_hw_number_t hw)
-{
- irq_set_chip_and_handler(virq, sun4i_irq_chip,
- handle_level_irq);
- set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
-
+ unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN;
+ struct irq_chip_generic *gc;
+ int i, ret, base = 0;
+
+ ret = irq_alloc_domain_generic_chips(d, SUN4I_IRQS_PER_CHIP, 1,
1 should be SUN4I_NUM_CHIPS.
+ sun4i_irq, handle_level_irq,
+ clr, 0, IRQ_GC_INIT_MASK_CACHE);
+ if (ret)
+ return ret;
+
+ for (i = 0; i SUN4I_NUM_CHIPS; i++, base += SUN4I_IRQS_PER_CHIP) {
+ gc = irq_get_domain_generic_chip(sun4i_irq_domain, base);
Perhaps this could be an iterator macro.
+ gc-reg_base = sun4i_irq_base;
+ gc-chip_types[0].regs.mask = SUN4I_IRQ_ENABLE_REG(i);
+ gc-chip_types[0].regs.ack = SUN4I_IRQ_PENDING_REG(i);
+ gc-chip_types[0].chip.mask = irq_gc_mask_clr_bit;
+ gc-chip_types[0].chip.ack = irq_gc_ack_set_bit;
+ gc-chip_types[0].chip.unmask = irq_gc_mask_set_bit;
+
+ /* Disable, mask and clear all pending interrupts */
+ writel(0, sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(i));
+ writel(0, sun4i_irq_base + SUN4I_IRQ_MASK_REG(i));
+ writel(0x, sun4i_irq_base + SUN4I_IRQ_PENDING_REG(i));
+ }
return 0;
}
-static struct irq_domain_ops sun4i_irq_ops = {
- .map = sun4i_irq_map,
- .xlate = irq_domain_xlate_onecell,
-};
-
static int __init sun4i_of_init(struct device_node *node,
struct device_node *parent)
{
@@ -104,21 +77,6 @@ static int __init sun4i_of_init(struct d
panic(%s: unable to map IC registers\n,
node-full_name);
- /* Disable all interrupts */
- writel(0, sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(0));
- writel(0, sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(1));
- writel(0, sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(2));
-
- /* Mask all the interrupts */
- writel(0, sun4i_irq_base + SUN4I_IRQ_MASK_REG(0));
- writel(0, sun4i_irq_base + SUN4I_IRQ_MASK_REG(1));
- writel(0, sun4i_irq_base + SUN4I_IRQ_MASK_REG(2));
-
- /* Clear all the pending interrupts */
- writel(0x, sun4i_irq_base + SUN4I_IRQ_PENDING_REG(0));
- writel(0x,
Re: [PATCH 03/23] ARM: u300: device tree support for the timer
On 04/26/2013 08:38 AM, Linus Walleij wrote:
On Mon, Apr 22, 2013 at 1:36 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 22 April 2013, Linus Walleij wrote:
+#ifdef CONFIG_OF
+ struct device_node *timer = NULL;
+
+ timer = of_find_node_by_path(/timer0@c0014000);
+ if (timer) {
+ struct resource irq_res;
+
+ u300_timer_base = of_iomap(timer, 0);
+ /* Get the IRQ for the GP1 timer */
+ irq = of_irq_to_resource(timer, 2, irq_res);
+ }
+#endif
Do you need the #ifdef? The functions should be defined in a way that
removes this code if CONFIG_OF is not defined.
Actually not, this happens without CONFIG_OF:
CC arch/arm/mach-u300/timer.o
/home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c: In function
'u300_timer_init':
/home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c:371:2:
error: implicit declaration of function 'of_find_node_by_path'
[-Werror=implicit-function-declaration]
/home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c:371:8:
warning: assignment makes pointer from integer without a cast [enabled
by default]
/home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c:377:3:
error: implicit declaration of function 'of_irq_to_resource'
[-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [arch/arm/mach-u300/timer.o] Error 1
make[2]: *** [arch/arm/mach-u300] Error 2
make[2]: *** Waiting for unfinished jobs
Maybe it's just a bug that these don't have the proper stubs in linux/of.h?
Or is there a deeper idea behind this? (CC some OF ppl.)
Yes, you could add empty function, but searching by path is probably not
the right thing to do. Why not use clocksource_of_init? That's what all
the cool kids are doing now. Is there some special feature of the timer
at this address? If so, then add a property to describe that feature and
key off of that plus the compatible prop.
Rob
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] of: Set the DMA mask to 64 bits when dma_addr_t is 64-bits
On 04/26/2013 01:06 PM, Laura Abbott wrote: Currently, of_platform_device_create_pdata always sets the coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA, arm_dma_limit gets set to ~0 or 0x on LPAE based systems. Since arm_dma_limit represents the smallest dma_mask on the system, the default of 32 bits prevents any dma_coherent allocation from succeeding unless clients manually set the dma mask first. Rather than make every client on an LPAE system set the mask, set the mask to a 64 bit value on systems with 64-bit dma addresses. Signed-off-by: Laura Abbott lau...@codeaurora.org --- drivers/of/platform.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 0970505..c669ab4 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata( #if defined(CONFIG_MICROBLAZE) dev-archdata.dma_mask = 0xUL; #endif +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT + dev-dev.coherent_dma_mask = DMA_BIT_MASK(64); +#else dev-dev.coherent_dma_mask = DMA_BIT_MASK(32); +#endif How about DMA_BIT_MASK(sizeof(dma_addr_t) * 8)) and avoid the ifdef. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is 64-bits
On 04/26/2013 03:31 PM, Laura Abbott wrote: Currently, of_platform_device_create_pdata always sets the coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA, arm_dma_limit gets set to ~0 or 0x on LPAE based systems. Since arm_dma_limit represents the smallest dma_mask on the system, the default of 32 bits prevents any dma_coherent allocation from succeeding unless clients manually set the dma mask first. Rather than make every client on an LPAE system set the mask manually, account for the size of dma_addr_t when setting the coherent mask. Signed-off-by: Laura Abbott lau...@codeaurora.org --- drivers/of/platform.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 0970505..5f0ba94 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -214,7 +214,7 @@ struct platform_device *of_platform_device_create_pdata( #if defined(CONFIG_MICROBLAZE) dev-archdata.dma_mask = 0xUL; #endif - dev-dev.coherent_dma_mask = DMA_BIT_MASK(32); + dev-dev.coherent_dma_mask = DMA_BIT_MASK(sizeof(dma_addr_t) * 8); This is going to change the mask from 32 to 64 bits on 64-bit powerpc and others possibly. Maybe it doesn't matter. I think it doesn't, but I'm not sure enough to apply for 3.10. So I'll queue it for 3.11. Rob dev-dev.bus = platform_bus_type; dev-dev.platform_data = platform_data; ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On Sun, Apr 21, 2013 at 9:13 PM, Rob Herring robherri...@gmail.com wrote:
From: Rob Herring rob.herr...@calxeda.com
ibmebus is the last remaining user of of_platform_driver and the
conversion to a regular platform driver is trivial.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Hoang-Nam Nguyen hngu...@de.ibm.com
Cc: Christoph Raisch rai...@de.ibm.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-r...@vger.kernel.org
Cc: net...@vger.kernel.org
Ben, Can I have your Ack for this? The change is straightforward and
neither of the 2 drivers used the id parameter that is removed.
Rob
---
arch/powerpc/include/asm/ibmebus.h|4 ++--
arch/powerpc/kernel/ibmebus.c | 22 ++
drivers/infiniband/hw/ehca/ehca_main.c|5 ++---
drivers/net/ethernet/ibm/ehea/ehea_main.c |8 +++-
4 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/ibmebus.h
b/arch/powerpc/include/asm/ibmebus.h
index 1a9d9ae..088f95b 100644
--- a/arch/powerpc/include/asm/ibmebus.h
+++ b/arch/powerpc/include/asm/ibmebus.h
@@ -48,8 +48,8 @@
extern struct bus_type ibmebus_bus_type;
-int ibmebus_register_driver(struct of_platform_driver *drv);
-void ibmebus_unregister_driver(struct of_platform_driver *drv);
+int ibmebus_register_driver(struct platform_driver *drv);
+void ibmebus_unregister_driver(struct platform_driver *drv);
int ibmebus_request_irq(u32 ist, irq_handler_t handler,
unsigned long irq_flags, const char *devname,
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 8220baa..16a7c23 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -205,7 +205,7 @@ static int ibmebus_create_devices(const struct
of_device_id *matches)
return ret;
}
-int ibmebus_register_driver(struct of_platform_driver *drv)
+int ibmebus_register_driver(struct platform_driver *drv)
{
/* If the driver uses devices that ibmebus doesn't know, add them */
ibmebus_create_devices(drv-driver.of_match_table);
@@ -215,7 +215,7 @@ int ibmebus_register_driver(struct of_platform_driver
*drv)
}
EXPORT_SYMBOL(ibmebus_register_driver);
-void ibmebus_unregister_driver(struct of_platform_driver *drv)
+void ibmebus_unregister_driver(struct platform_driver *drv)
{
driver_unregister(drv-driver);
}
@@ -338,11 +338,10 @@ static int ibmebus_bus_bus_match(struct device *dev,
struct device_driver *drv)
static int ibmebus_bus_device_probe(struct device *dev)
{
int error = -ENODEV;
- struct of_platform_driver *drv;
+ struct platform_driver *drv;
struct platform_device *of_dev;
- const struct of_device_id *match;
- drv = to_of_platform_driver(dev-driver);
+ drv = to_platform_driver(dev-driver);
of_dev = to_platform_device(dev);
if (!drv-probe)
@@ -350,9 +349,8 @@ static int ibmebus_bus_device_probe(struct device *dev)
of_dev_get(of_dev);
- match = of_match_device(drv-driver.of_match_table, dev);
- if (match)
- error = drv-probe(of_dev, match);
+ if (of_driver_match_device(dev, dev-driver))
+ error = drv-probe(of_dev);
if (error)
of_dev_put(of_dev);
@@ -362,7 +360,7 @@ static int ibmebus_bus_device_probe(struct device *dev)
static int ibmebus_bus_device_remove(struct device *dev)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev-driver);
+ struct platform_driver *drv = to_platform_driver(dev-driver);
if (dev-driver drv-remove)
drv-remove(of_dev);
@@ -372,7 +370,7 @@ static int ibmebus_bus_device_remove(struct device *dev)
static void ibmebus_bus_device_shutdown(struct device *dev)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev-driver);
+ struct platform_driver *drv = to_platform_driver(dev-driver);
if (dev-driver drv-shutdown)
drv-shutdown(of_dev);
@@ -419,7 +417,7 @@ struct device_attribute ibmebus_bus_device_attrs[] = {
static int ibmebus_bus_legacy_suspend(struct device *dev, pm_message_t mesg)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev-driver);
+ struct platform_driver *drv = to_platform_driver(dev-driver);
int ret = 0;
if (dev-driver drv-suspend)
@@ -430,7 +428,7
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-04-25 at 10:23 -0500, Rob Herring wrote: Ben, Can I have your Ack for this? The change is straightforward and neither of the 2 drivers used the id parameter that is removed. Didn't you get my mail about a compile failure caused by this patch ? No, and I can't find any evidence of a mail in my inbox or in the list archives. A quick build test leads to: /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_probe': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:2: error: implicit declaration of function 'to_platform_driver' [-Werror=implicit-function-declaration] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:6: error: assignment makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_remove': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:363:32: error: initialization makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_device_shutdown': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:373:32: error: initialization makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_legacy_suspend': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:420:32: error: initialization makes pointer from integer without a cast [-Werror] /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function 'ibmebus_bus_legacy_resume': /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:431:32: error: initialization makes pointer from integer without a cast [-Werror] cc1: all warnings being treated as errors make[2]: *** [arch/powerpc/kernel/ibmebus.o] Error 1 make[2]: *** Waiting for unfinished jobs Haven't had a chance to look too closely today -EJETLAG :-) You need patch 2 of this series to fix this: driver core: move to_platform_driver to platform_device.h which as Arnd pointed out needs to come first. I've fixed that in my tree, but I don't think it warrants another post. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On 04/25/2013 03:12 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-04-25 at 14:14 -0500, Rob Herring wrote: On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote: [...] You need patch 2 of this series to fix this: driver core: move to_platform_driver to platform_device.h which as Arnd pointed out needs to come first. I've fixed that in my tree, but I don't think it warrants another post. Can I pull you tree from somewhere to test ? Here you go: git://sources.calxeda.com/kernel/linux.git of-platform-removal Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected timer binding
On 04/15/2013 04:33 PM, Stephen Boyd wrote: On 04/15/13 14:20, Rob Herring wrote: On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd sb...@codeaurora.org wrote: @@ -26,3 +30,52 @@ Example: 1 10 0xf08; clock-frequency = 1; }; + +** Memory mapped timer node properties + +- compatible : Should at least contain arm,armv7-timer-mem. Everything about this timer is architecturally defined? If not, let's use a more specific name. I'm not sure I'm following you, but everything described here is part of the ARM definition. What would be a more specific name? Something that corresponds to the particular implementation like cortex-a15 (obviously not an example that has this). I'm fine with leaving this for now, but would like to see that added when specific SOC dts are added. Better to be specific in case we need to use it for something like errata work-arounds. Of course we haven't done that so far with the arch timer bindings... + +- clock-frequency : The frequency of the main counter, in Hz. Optional. + +- reg : The control frame base address. + +Note that #address-cells, #size-cells, and ranges shall be present to ensure +the CPU can address a frame's registers. + +Frame: + +- frame-number: 0 to 7. I'd really like to get rid of the frame numbers and sub-nodes. Is the frame number significant to software? We need the frame number to read and write registers in the control frame (the first base in the parent node). We currently use it to determine if a frame has support for the virtual timer by reading the CNTTIDR (a register with 4 bits per frame describing capabilities). If we wanted to control access to the second view of a frame we would also need to configure the CNTPL0ACRn register that pertains to the frame we're controlling. Without a frame number we wouldn't know which register to write. I've gone thru the memory mapped part of the spec now, so I think I understand things better. I see how the frame number is needed, but... The control base is only accessible in secure or hyp mode. How does a guest know that it is a guest and can't map the control base? Seems like we need to allow a subset of the binding that is just a reg and interrupts properties without the frame sub nodes. Rob +- interrupts : Interrupt list for physical and virtual timers in that order. + The virtual timer interrupt is optional. Is that optional per frame? Yes the virtual and physical timer interrupt is per-frame and the virtual interrupt is optional. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation/devicetree: make semantic of initrd-end more explicit
On 04/25/2013 07:27 AM, Uwe Kleine-König wrote: Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- Documentation/devicetree/usage-model.txt | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) Applied. Thanks, Rob diff --git a/Documentation/devicetree/usage-model.txt b/Documentation/devicetree/usage-model.txt index ef9d06c..0efedaa 100644 --- a/Documentation/devicetree/usage-model.txt +++ b/Documentation/devicetree/usage-model.txt @@ -191,9 +191,11 @@ Linux it will look something like this: }; The bootargs property contains the kernel arguments, and the initrd-* -properties define the address and size of an initrd blob. The -chosen node may also optionally contain an arbitrary number of -additional properties for platform-specific configuration data. +properties define the address and size of an initrd blob. Note that +initrd-end is the first address after the initrd image, so this doesn't +match the usual semantic of struct resource. The chosen node may also +optionally contain an arbitrary number of additional properties for +platform-specific configuration data. During early boot, the architecture setup code calls of_scan_flat_dt() several times with different helper callbacks to parse device tree ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected timer binding
On 04/25/2013 05:48 PM, Stephen Boyd wrote: On 04/25/13 14:47, Rob Herring wrote: On 04/15/2013 04:33 PM, Stephen Boyd wrote: On 04/15/13 14:20, Rob Herring wrote: On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd sb...@codeaurora.org wrote: @@ -26,3 +30,52 @@ Example: 1 10 0xf08; clock-frequency = 1; }; + +** Memory mapped timer node properties + +- compatible : Should at least contain arm,armv7-timer-mem. Everything about this timer is architecturally defined? If not, let's use a more specific name. I'm not sure I'm following you, but everything described here is part of the ARM definition. What would be a more specific name? Something that corresponds to the particular implementation like cortex-a15 (obviously not an example that has this). I'm fine with leaving this for now, but would like to see that added when specific SOC dts are added. Better to be specific in case we need to use it for something like errata work-arounds. Of course we haven't done that so far with the arch timer bindings... Agreed. I'm under the impression that most of our compatible fields should be more specific than they currently are so we can workaround hw bugs like you say. Perhaps the catch all generic one should just be arm,arm-timer-mem since it isn't tied to any particular CPU type? + +- clock-frequency : The frequency of the main counter, in Hz. Optional. + +- reg : The control frame base address. + +Note that #address-cells, #size-cells, and ranges shall be present to ensure +the CPU can address a frame's registers. + +Frame: + +- frame-number: 0 to 7. I'd really like to get rid of the frame numbers and sub-nodes. Is the frame number significant to software? We need the frame number to read and write registers in the control frame (the first base in the parent node). We currently use it to determine if a frame has support for the virtual timer by reading the CNTTIDR (a register with 4 bits per frame describing capabilities). If we wanted to control access to the second view of a frame we would also need to configure the CNTPL0ACRn register that pertains to the frame we're controlling. Without a frame number we wouldn't know which register to write. I've gone thru the memory mapped part of the spec now, so I think I understand things better. I see how the frame number is needed, but... The control base is only accessible in secure or hyp mode. How does a guest know that it is a guest and can't map the control base? Seems like we need to allow a subset of the binding that is just a reg and interrupts properties without the frame sub nodes. I don't see that part. My understanding is that the control base is accessible in non-secure mode and by the guests. There are certain registers within that base that are only accessible in secure mode though: CNTFRQ and CNTNSAR. Also some registers are configurable: CNTACRn and CNTVOFFN. CNTVOFFN is only accessible in the hypervisor. The example is section E.8 seems to say otherwise. Perhaps Mark R can comment further. We don't really care about CNTFRQ because it's duplicated into each view. We do care about CNTNSAR. Luckily the spec just works there in the sense that we can use CNTTIDR in conjunction with CNTACRn and determine if we have access to a frame we're interested in if the CNTTIDR bits say the frame is present and the CNTACRn register says we can access it. If not then it must be locked down for secure users. Unfortunately hardware doesn't have a way to say that a particular frame is reserved for the hypervisor or the guest kernel/userspace. We need some help from software, so we have the status property express that a particular frame is available. We have to assume the DT is going to be different depending on if you're the hypervisor or the guest. That's a valid assumption right? Otherwise I hope we can do some trapping of the guest's mapping to the control base and then rewrite what they read so that they only see the frame that we want to be available to them. Yeah, I believe the only way to prevent access within non-secure world is with the MMU. So I guess the example is just policy that the hypervisor would/may not create a stage2 mapping. You still have the same issue that the guest should not be passed the control base. You could make the reg property optional, but then what do you do with the node name? Certainly the guest dtb will be different. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Wed, Apr 24, 2013 at 12:28 PM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Main changes: - adds 64-bit bindings - define usage of #address-cells - define 32/64 dts compatibility settings - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- [...] + - enable-method + Value type: stringlist + Usage and definition depend on ARM architecture version and + configuration: + # On ARM v8 64-bit systems running the OS in AArch64, + this property is required and must be spin-table. What about PSCI? I don't think the ePAPR spin-table definition is sufficient for ARM. How do you define wake up by SGI or sev instruction. + # On ARM 32-bit systems or ARM v8 systems running + the OS in AArch32 this property is prohibited. Why? Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2 03/13] ARM: mach-at91: cpus/cpu node dts updates
On 04/22/2013 10:27 AM, Lorenzo Pieralisi wrote:
This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
arch/arm/boot/dts/at91sam9n12.dtsi | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index cb7bcc5..2e9de85 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -33,7 +33,7 @@
};
cpus {
cpu@0 {
- compatible = arm,arm926ejs;
+ compatible = arm,arm926;
I don't understand why you are doing this. If this does not match the
documentation, fix the documentation. We can't continue on changing dts
files without reqard to breaking compatibility.
Rob
};
};
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
b/arch/arm/boot/dts/at91sam9263.dtsi
index 271d4de..25c4725 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -30,7 +30,7 @@
};
cpus {
cpu@0 {
- compatible = arm,arm926ejs;
+ compatible = arm,arm926;
};
};
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
b/arch/arm/boot/dts/at91sam9g45.dtsi
index 6b1d4ca..cf647d1 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -36,7 +36,7 @@
};
cpus {
cpu@0 {
- compatible = arm,arm926ejs;
+ compatible = arm,arm926;
};
};
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi
b/arch/arm/boot/dts/at91sam9n12.dtsi
index 7750f98..d531ae3 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -32,7 +32,7 @@
};
cpus {
cpu@0 {
- compatible = arm,arm926ejs;
+ compatible = arm,arm926;
};
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/5] of_platform_driver and OF_DEVICE removal
From: Rob Herring rob.herr...@calxeda.com This series is a relatively straight-forward removal of the last remaining user of of_platform_driver (ibmebus) and removal of CONFIG_OF_DEVICE which is always enabled when CONFIG_OF is enabled. Compile tested on powerpc and sparc. Rob Rob Herring (5): ibmebus: convert of_platform_driver to platform_driver driver core: move to_platform_driver to platform_device.h of: remove of_platform_driver usb: chipidea: depend on CONFIG_OF instead of CONFIG_OF_DEVICE of: remove CONFIG_OF_DEVICE arch/powerpc/include/asm/ibmebus.h|4 ++-- arch/powerpc/kernel/ibmebus.c | 22 ++--- drivers/base/platform.c |3 --- drivers/infiniband/hw/ehca/ehca_main.c|5 ++--- drivers/net/ethernet/ibm/ehea/ehea_main.c |8 +++- drivers/of/Kconfig|3 --- drivers/of/Makefile |3 +-- drivers/usb/chipidea/Makefile |2 +- include/linux/of_device.h |6 +++--- include/linux/of_platform.h | 30 + include/linux/platform_device.h |3 +++ 11 files changed, 26 insertions(+), 63 deletions(-) -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/5] of: remove of_platform_driver
From: Rob Herring rob.herr...@calxeda.com
The last user of of_platform_driver is converted to a regular
platform_driver, so of_platform_driver can be removed now.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@linaro.org
---
include/linux/of_platform.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 2a93b64..aa7eb02 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -53,27 +53,6 @@ struct of_dev_auxdata {
{ .compatible = _compat, .phys_addr = _phys, .name = _name, \
.platform_data = _pdata }
-/**
- * of_platform_driver - Legacy of-aware driver for platform devices.
- *
- * An of_platform_driver driver is attached to a basic platform_device on
- * the ibm ebus (ibmebus_bus_type).
- */
-struct of_platform_driver
-{
- int (*probe)(struct platform_device* dev,
-const struct of_device_id *match);
- int (*remove)(struct platform_device* dev);
-
- int (*suspend)(struct platform_device* dev, pm_message_t state);
- int (*resume)(struct platform_device* dev);
- int (*shutdown)(struct platform_device* dev);
-
- struct device_driverdriver;
-};
-#defineto_of_platform_driver(drv) \
- container_of(drv,struct of_platform_driver, driver)
-
extern const struct of_device_id of_default_bus_match_table[];
/* Platform drivers register/unregister */
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/5] driver core: move to_platform_driver to platform_device.h
From: Rob Herring rob.herr...@calxeda.com
In converting the last remaining of_platform_driver (ibmebus) to a regular
platform driver, to_platform_driver is needed to replace
to_of_platform_driver.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Grant Likely grant.lik...@linaro.org
---
drivers/base/platform.c |3 ---
include/linux/platform_device.h |3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index c0b8df3..819ecb0 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -29,9 +29,6 @@
/* For automatically allocated device IDs */
static DEFINE_IDA(platform_devid_ida);
-#define to_platform_driver(drv)(container_of((drv), struct
platform_driver, \
-driver))
-
struct device platform_bus = {
.init_name = platform,
};
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index c082c71..6e4e096 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -176,6 +176,9 @@ struct platform_driver {
const struct platform_device_id *id_table;
};
+#define to_platform_driver(drv)(container_of((drv), struct
platform_driver, \
+driver))
+
extern int platform_driver_register(struct platform_driver *);
extern void platform_driver_unregister(struct platform_driver *);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
From: Rob Herring rob.herr...@calxeda.com
ibmebus is the last remaining user of of_platform_driver and the
conversion to a regular platform driver is trivial.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Hoang-Nam Nguyen hngu...@de.ibm.com
Cc: Christoph Raisch rai...@de.ibm.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-r...@vger.kernel.org
Cc: net...@vger.kernel.org
---
arch/powerpc/include/asm/ibmebus.h|4 ++--
arch/powerpc/kernel/ibmebus.c | 22 ++
drivers/infiniband/hw/ehca/ehca_main.c|5 ++---
drivers/net/ethernet/ibm/ehea/ehea_main.c |8 +++-
4 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/ibmebus.h
b/arch/powerpc/include/asm/ibmebus.h
index 1a9d9ae..088f95b 100644
--- a/arch/powerpc/include/asm/ibmebus.h
+++ b/arch/powerpc/include/asm/ibmebus.h
@@ -48,8 +48,8 @@
extern struct bus_type ibmebus_bus_type;
-int ibmebus_register_driver(struct of_platform_driver *drv);
-void ibmebus_unregister_driver(struct of_platform_driver *drv);
+int ibmebus_register_driver(struct platform_driver *drv);
+void ibmebus_unregister_driver(struct platform_driver *drv);
int ibmebus_request_irq(u32 ist, irq_handler_t handler,
unsigned long irq_flags, const char *devname,
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 8220baa..16a7c23 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -205,7 +205,7 @@ static int ibmebus_create_devices(const struct of_device_id
*matches)
return ret;
}
-int ibmebus_register_driver(struct of_platform_driver *drv)
+int ibmebus_register_driver(struct platform_driver *drv)
{
/* If the driver uses devices that ibmebus doesn't know, add them */
ibmebus_create_devices(drv-driver.of_match_table);
@@ -215,7 +215,7 @@ int ibmebus_register_driver(struct of_platform_driver *drv)
}
EXPORT_SYMBOL(ibmebus_register_driver);
-void ibmebus_unregister_driver(struct of_platform_driver *drv)
+void ibmebus_unregister_driver(struct platform_driver *drv)
{
driver_unregister(drv-driver);
}
@@ -338,11 +338,10 @@ static int ibmebus_bus_bus_match(struct device *dev,
struct device_driver *drv)
static int ibmebus_bus_device_probe(struct device *dev)
{
int error = -ENODEV;
- struct of_platform_driver *drv;
+ struct platform_driver *drv;
struct platform_device *of_dev;
- const struct of_device_id *match;
- drv = to_of_platform_driver(dev-driver);
+ drv = to_platform_driver(dev-driver);
of_dev = to_platform_device(dev);
if (!drv-probe)
@@ -350,9 +349,8 @@ static int ibmebus_bus_device_probe(struct device *dev)
of_dev_get(of_dev);
- match = of_match_device(drv-driver.of_match_table, dev);
- if (match)
- error = drv-probe(of_dev, match);
+ if (of_driver_match_device(dev, dev-driver))
+ error = drv-probe(of_dev);
if (error)
of_dev_put(of_dev);
@@ -362,7 +360,7 @@ static int ibmebus_bus_device_probe(struct device *dev)
static int ibmebus_bus_device_remove(struct device *dev)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev-driver);
+ struct platform_driver *drv = to_platform_driver(dev-driver);
if (dev-driver drv-remove)
drv-remove(of_dev);
@@ -372,7 +370,7 @@ static int ibmebus_bus_device_remove(struct device *dev)
static void ibmebus_bus_device_shutdown(struct device *dev)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev-driver);
+ struct platform_driver *drv = to_platform_driver(dev-driver);
if (dev-driver drv-shutdown)
drv-shutdown(of_dev);
@@ -419,7 +417,7 @@ struct device_attribute ibmebus_bus_device_attrs[] = {
static int ibmebus_bus_legacy_suspend(struct device *dev, pm_message_t mesg)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev-driver);
+ struct platform_driver *drv = to_platform_driver(dev-driver);
int ret = 0;
if (dev-driver drv-suspend)
@@ -430,7 +428,7 @@ static int ibmebus_bus_legacy_suspend(struct device *dev,
pm_message_t mesg)
static int ibmebus_bus_legacy_resume(struct device *dev)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev-driver);
+ struct
[PATCH 4/5] usb: chipidea: depend on CONFIG_OF instead of CONFIG_OF_DEVICE
From: Rob Herring rob.herr...@calxeda.com CONFIG_OF_DEVICE is going away, so use CONFIG_OF instead. It does not appear that CONFIG_OF_DEVICE was the correct dependency either. Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Alexander Shishkin alexander.shish...@linux.intel.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Grant Likely grant.lik...@linaro.org Cc: linux-...@vger.kernel.org --- drivers/usb/chipidea/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile index d92ca32..0895e3e 100644 --- a/drivers/usb/chipidea/Makefile +++ b/drivers/usb/chipidea/Makefile @@ -16,6 +16,6 @@ ifneq ($(CONFIG_PCI),) obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_pci.o endif -ifneq ($(CONFIG_OF_DEVICE),) +ifneq ($(CONFIG_OF),) obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o usbmisc_imx6q.o endif -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/5] of: remove CONFIG_OF_DEVICE
From: Rob Herring rob.herr...@calxeda.com
CONFIG_OF_DEVICE is always selected when CONFIG_OF is enabled, so remove
it and simplify of_platform.h and of_device.h headers. This also fixes
!OF compiles using of_platform_populate.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@linaro.org
---
drivers/of/Kconfig |3 ---
drivers/of/Makefile |3 +--
include/linux/of_device.h |6 +++---
include/linux/of_platform.h |9 +
4 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index d37bfcf..80e5c13 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -48,9 +48,6 @@ config OF_IRQ
def_bool y
depends on !SPARC
-config OF_DEVICE
- def_bool y
-
config OF_I2C
def_tristate I2C
depends on I2C
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e027f44..1f9c0c4 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,9 +1,8 @@
-obj-y = base.o
+obj-y = base.o device.o platform.o
obj-$(CONFIG_OF_FLATTREE) += fdt.o
obj-$(CONFIG_OF_PROMTREE) += pdt.o
obj-$(CONFIG_OF_ADDRESS) += address.o
obj-$(CONFIG_OF_IRQ)+= irq.o
-obj-$(CONFIG_OF_DEVICE) += device.o platform.o
obj-$(CONFIG_OF_I2C) += of_i2c.o
obj-$(CONFIG_OF_NET) += of_net.o
obj-$(CONFIG_OF_SELFTEST) += selftest.o
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 901b743..9d27475 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -4,12 +4,12 @@
#include linux/platform_device.h
#include linux/of_platform.h /* temporary until merge */
-#ifdef CONFIG_OF_DEVICE
#include linux/of.h
#include linux/mod_devicetable.h
struct device;
+#ifdef CONFIG_OF
extern const struct of_device_id *of_match_device(
const struct of_device_id *matches, const struct device *dev);
extern void of_device_make_bus_id(struct device *dev);
@@ -43,7 +43,7 @@ static inline void of_device_node_put(struct device *dev)
of_node_put(dev-of_node);
}
-#else /* CONFIG_OF_DEVICE */
+#else /* CONFIG_OF */
static inline int of_driver_match_device(struct device *dev,
struct device_driver *drv)
@@ -67,6 +67,6 @@ static inline const struct of_device_id *of_match_device(
{
return NULL;
}
-#endif /* CONFIG_OF_DEVICE */
+#endif /* CONFIG_OF */
#endif /* _LINUX_OF_DEVICE_H */
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index aa7eb02..6b840f0 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -13,8 +13,6 @@
#include linux/device.h
#include linux/mod_devicetable.h
-
-#ifdef CONFIG_OF_DEVICE
#include linux/pm.h
#include linux/of_device.h
#include linux/platform_device.h
@@ -74,13 +72,8 @@ extern int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
struct device *parent);
-#endif /* CONFIG_OF_ADDRESS */
-
-#endif /* CONFIG_OF_DEVICE */
+#else
-#if !defined(CONFIG_OF_ADDRESS)
-struct of_dev_auxdata;
-struct device_node;
static inline int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
On Tue, Apr 16, 2013 at 8:19 AM, Tomasz Figa t.f...@samsung.com wrote:
On Tuesday 16 of April 2013 08:09:10 Rob Herring wrote:
On 04/15/2013 04:14 PM, Tomasz Figa wrote:
This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
Since all the SoCs in the series are very similar, the files are created
hierarchically - one file for the whole series and then separate files
for particular SoCs including the common one.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
arch/arm/boot/dts/s3c6400.dtsi | 33 ++
arch/arm/boot/dts/s3c6410.dtsi | 33 ++
arch/arm/boot/dts/s3c64xx-pinctrl.dtsi | 683
+ arch/arm/boot/dts/s3c64xx.dtsi
| 136 +++
4 files changed, 885 insertions(+)
create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
create mode 100644 arch/arm/boot/dts/s3c64xx-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi
[...]
+
+ vic0: interrupt-controller@7120 {
These nodes should be off a simple-bus node.
Hmm, is there any reason behind it?
I thought simple bus was just a convenient helper to represent hierarchical
bus structures if one has a need to do so.
No. The DT should reflect the bus structure of the chip. How
accurately it is done is up to you and the information available, but
you have to have a bus of some sort.
There's obvious examples that don't follow this, but I'd like to not have more.
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
On 04/15/2013 04:14 PM, Tomasz Figa wrote:
This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
Since all the SoCs in the series are very similar, the files are created
hierarchically - one file for the whole series and then separate files
for particular SoCs including the common one.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
arch/arm/boot/dts/s3c6400.dtsi | 33 ++
arch/arm/boot/dts/s3c6410.dtsi | 33 ++
arch/arm/boot/dts/s3c64xx-pinctrl.dtsi | 683
+
arch/arm/boot/dts/s3c64xx.dtsi | 136 +++
4 files changed, 885 insertions(+)
create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
create mode 100644 arch/arm/boot/dts/s3c64xx-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi
[...]
+
+ vic0: interrupt-controller@7120 {
These nodes should be off a simple-bus node.
Rob
+ compatible = arm,pl192-vic;
+ interrupt-controller;
+ reg = 0x7120 0x1000;
+ #interrupt-cells = 1;
+ };
+
+ vic1: interrupt-controller@7130 {
+ compatible = arm,pl192-vic;
+ interrupt-controller;
+ reg = 0x7130 0x1000;
+ #interrupt-cells = 1;
+ };
+
+ pinctrl0: pinctrl@7f008000 {
+ compatible = samsung,s3c64xx-pinctrl;
+ reg = 0x7f008000 0x1000;
+ interrupt-parent = vic1;
+ interrupts = 21;
+
+ pctrl_int_map: pinctrl-interrupt-map {
+ interrupt-map = 0 vic0 0,
+ 1 vic0 1,
+ 2 vic1 0,
+ 3 vic1 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 1;
+ };
+
+ wakeup-interrupt-controller {
+ compatible = samsung,s3c64xx-wakeup-eint;
+ interrupts = 0, 1, 2, 3;
+ interrupt-parent = pctrl_int_map;
+ };
+ };
+
+ pwm: pwm@7f006000 {
+ compatible = samsung,s3c6400-pwm;
+ reg = 0x7f006000 0x1000;
+ interrupt-parent = vic0;
+ interrupts = 23, 24, 25, 27, 28;
+ samsung,pwm-outputs = 0, 1;
+ #pwm-cells = 3;
+ status = disabled;
+ };
+
+ uart0: serial@7f005000 {
+ compatible = samsung,s3c6400-uart;
+ reg = 0x7f005000 0x100;
+ interrupt-parent = vic1;
+ interrupts = 5;
+ status = disabled;
+ };
+
+ uart1: serial@7f005400 {
+ compatible = samsung,s3c6400-uart;
+ reg = 0x7f005400 0x100;
+ interrupt-parent = vic1;
+ interrupts = 6;
+ status = disabled;
+ };
+
+ uart2: serial@7f005800 {
+ compatible = samsung,s3c6400-uart;
+ reg = 0x7f005800 0x100;
+ interrupt-parent = vic1;
+ interrupts = 7;
+ status = disabled;
+ };
+
+ uart3: serial@7f005c00 {
+ compatible = samsung,s3c6400-uart;
+ reg = 0x7f005c00 0x100;
+ interrupt-parent = vic1;
+ interrupts = 8;
+ status = disabled;
+ };
+
+ sdhci0: sdhci@7c20 {
+ compatible = samsung,s3c6410-sdhci;
+ reg = 0x7c20 0x100;
+ interrupt-parent = vic1;
+ interrupts = 24;
+ status = disabled;
+ };
+
+ sdhci1: sdhci@7c30 {
+ compatible = samsung,s3c6410-sdhci;
+ reg = 0x7c30 0x100;
+ interrupt-parent = vic1;
+ interrupts = 25;
+ status = disabled;
+ };
+
+ sdhci2: sdhci@7c40 {
+ compatible = samsung,s3c6410-sdhci;
+ reg = 0x7c40 0x100;
+ interrupt-parent = vic1;
+ interrupts = 17;
+ status = disabled;
+ };
+};
+
+/include/ s3c64xx-pinctrl.dtsi
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected timer binding
On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd sb...@codeaurora.org wrote:
Add a binding for the arm architected timer hardware's memory
mapped interface. The mmio timer hardware is made up of one base
frame and a collection of up to 8 timer frames, where each of the
8 timer frames can have either one or two views. A frame
typically maps to a privilege level (user/kernel, hypervisor,
secure). The first view has full access to the registers within a
frame, while the second view can be restricted to particular
registers within a frame. Each frame must support a physical
timer. It's optional for a frame to support a virtual timer.
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Marc Zyngier marc.zyng...@arm.com
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
.../devicetree/bindings/arm/arch_timer.txt | 59
--
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt
b/Documentation/devicetree/bindings/arm/arch_timer.txt
index 20746e5..ac20cde 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -1,10 +1,14 @@
* ARM architected timer
-ARM cores may have a per-core architected timer, which provides per-cpu
timers.
+ARM cores may have a per-core architected timer, which provides per-cpu
timers,
+or a memory mapped architected timer, which provides up to 8 frames with a
+physical and optional virtual timer per frame.
-The timer is attached to a GIC to deliver its per-processor interrupts.
+The per-core architected timer is attached to a GIC to deliver its
+per-processor interrupts via PPIs. The memory mapped timer is attached to a
GIC
+to deliver its interrupts via SPIs.
-** Timer node properties:
+** CP15 Timer node properties:
- compatible : Should at least contain one of
arm,armv7-timer
@@ -26,3 +30,52 @@ Example:
1 10 0xf08;
clock-frequency = 1;
};
+
+** Memory mapped timer node properties
+
+- compatible : Should at least contain arm,armv7-timer-mem.
Everything about this timer is architecturally defined? If not, let's
use a more specific name.
+
+- clock-frequency : The frequency of the main counter, in Hz. Optional.
+
+- reg : The control frame base address.
+
+Note that #address-cells, #size-cells, and ranges shall be present to ensure
+the CPU can address a frame's registers.
+
+Frame:
+
+- frame-number: 0 to 7.
I'd really like to get rid of the frame numbers and sub-nodes. Is the
frame number significant to software?
+- interrupts : Interrupt list for physical and virtual timers in that order.
+ The virtual timer interrupt is optional.
Is that optional per frame?
Rob
+
+- reg : The first and second view base addresses in that order. The second
view
+ base address is optional.
+
+- status : disabled indicates the frame is not available for use.
+
+Example:
+
+ timer@f000 {
+ compatible = arm,armv7-timer-mem;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ reg = 0xf000 0x1000;
+ clock-frequency = 5000;
+
+ frame@f0001000 {
+ frame-number = 0
+ interrupts = 0 13 0x8,
+0 14 0x8;
+ reg = 0xf0001000 0x1000,
+ 0xf0002000 0x1000;
+ };
+
+ frame@f0003000 {
+ frame-number = 1
+ interrupts = 0 15 0x8;
+ reg = 0xf0003000 0x1000;
+ status = disabled;
+ };
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology bindings
On 04/11/2013 04:12 AM, Mark Rutland wrote:
From: Lorenzo Pieralisi lorenzo.pieral...@arm.com
The advent of multi-cluster ARM systems requires a mechanism to describe
how in hierarchical terms CPUs are connected in ARM SoCs so that the kernel
can initialize and map resources like IRQs and memory space to specific
group(s) of CPUs.
The CPU topology is made up of multiple hierarchy levels whose bottom
layers (aka leaf nodes in device tree syntax) contain links to the HW
CPUs in the system.
The topology bindings are generic for both 32-bit and 64-bit systems and
lay the groundwork on top of which affinity schemes can be built.
This patch provides the documentation in the kernel required to define the
device tree bindings describing the CPU topology for ARM 32-bit and 64-bit
systems.
I'm now very weary of continued /cpu changes after the pain of making
the reg property reflect the mpidr value in 3.8.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Mark Rutland mark.rutl...@arm.com
---
Documentation/devicetree/bindings/arm/topology.txt | 524
+
1 file changed, 524 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/topology.txt
diff --git a/Documentation/devicetree/bindings/arm/topology.txt
b/Documentation/devicetree/bindings/arm/topology.txt
new file mode 100644
index 000..07c4961
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/topology.txt
@@ -0,0 +1,524 @@
+===
+ARM topology binding description
+===
+
+===
+1 - Introduction
+===
+
+In an ARM system, the hierarchy of CPUs is defined through three entities
that
+are used to describe the layout of physical CPUs in the system:
+
+- cluster
+- core
+- thread
+
+The cpu nodes (bindings defined in [1]) represent the devices that
+correspond to physical CPUs and are to be mapped to the hierarchy levels.
+
+The bottom hierarchy level sits at core or thread level depending on whether
+symmetric multi-threading (SMT) is supported or not.
+
+For instance in a system where CPUs support SMT, cpu nodes represent all
+threads existing in the system and map to the hierarchy level thread above.
+In systems where SMT is not supported cpu nodes represent all cores present
+in the system and map to the hierarchy level core above.
+
+ARM topology bindings allow one to associate cpu nodes with hierarchical
groups
+corresponding to the system hierarchy; syntactically they are defined as
device
+tree nodes.
+
+The remainder of this document provides the topology bindings for ARM, based
+on the ePAPR standard, available from:
+
+http://devicetree.org
+
+If not stated otherwise, whenever a reference to a cpu node phandle is made
its
+value must point to a cpu node compliant with the cpu node bindings as
+documented in [1].
+A topology description containing phandles to cpu nodes that are not
compliant
+with bindings standardized in [1] is therefore considered invalid.
+
+===
+2 - cpu-map node
+===
+
+The ARM CPU topology is defined within a container node, sitting at the top
+level of the device tree (/), the cpu-map node.
+
+- cpu-map node
+
+ Usage: Required to define ARM CPU topology
+
+ Description: The cpu-map node is just a container node where its
+ subnodes describe the CPU topology
+
+ Node name must be cpu-map.
+
+ A cpu-map node's child nodes can be:
+
+ - one or more cluster nodes
+
+ Any other configuration is considered invalid.
+
+The cpu-map node can only contain three types of child nodes:
+
+- cluster node
+- core node
+- thread node
+
Why not put the topology in the /cpus nodes? I don't really see the
point of having a flat list of cpus and separate topology info. There is
some compatibility issue, but adding optional levels for clusters can be
handled.
+whose bindings are described in paragraph 3.
+
+The nodes describing the CPU topology (cluster/core/thread) can only be
+defined within the cpu-map node.
+Any other configuration is consider invalid and therefore must be ignored.
+
+===
+2.1 - cpu-map child nodes naming convention
+===
+
+cpu-map child nodes must follow a naming convention where the node name
+must be clusterN, coreN, threadN depending on the node type (ie
+cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
+are siblings within a single common parent node must be given a unique and
+sequential N value, starting from 0).
+cpu-map child nodes which do not share a common parent node can have the same
+name (ie same number N as other cpu-map child nodes at
Re: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology bindings
On 04/11/2013 10:50 AM, Lorenzo Pieralisi wrote: On Thu, Apr 11, 2013 at 04:00:47PM +0100, Rob Herring wrote: On 04/11/2013 04:12 AM, Mark Rutland wrote: From: Lorenzo Pieralisi lorenzo.pieral...@arm.com The advent of multi-cluster ARM systems requires a mechanism to describe how in hierarchical terms CPUs are connected in ARM SoCs so that the kernel can initialize and map resources like IRQs and memory space to specific group(s) of CPUs. The CPU topology is made up of multiple hierarchy levels whose bottom layers (aka leaf nodes in device tree syntax) contain links to the HW CPUs in the system. The topology bindings are generic for both 32-bit and 64-bit systems and lay the groundwork on top of which affinity schemes can be built. This patch provides the documentation in the kernel required to define the device tree bindings describing the CPU topology for ARM 32-bit and 64-bit systems. I'm now very weary of continued /cpu changes after the pain of making the reg property reflect the mpidr value in 3.8. We won't change the reg property value, the code I am about to post provides stricter bindings, stricter semantics and extends bindings to cater for arm 64-bit systems. Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com Signed-off-by: Mark Rutland mark.rutl...@arm.com --- Documentation/devicetree/bindings/arm/topology.txt | 524 + 1 file changed, 524 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/topology.txt diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt new file mode 100644 index 000..07c4961 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/topology.txt @@ -0,0 +1,524 @@ +=== +ARM topology binding description +=== + +=== +1 - Introduction +=== + +In an ARM system, the hierarchy of CPUs is defined through three entities that +are used to describe the layout of physical CPUs in the system: + +- cluster +- core +- thread + +The cpu nodes (bindings defined in [1]) represent the devices that +correspond to physical CPUs and are to be mapped to the hierarchy levels. + +The bottom hierarchy level sits at core or thread level depending on whether +symmetric multi-threading (SMT) is supported or not. + +For instance in a system where CPUs support SMT, cpu nodes represent all +threads existing in the system and map to the hierarchy level thread above. +In systems where SMT is not supported cpu nodes represent all cores present +in the system and map to the hierarchy level core above. + +ARM topology bindings allow one to associate cpu nodes with hierarchical groups +corresponding to the system hierarchy; syntactically they are defined as device +tree nodes. + +The remainder of this document provides the topology bindings for ARM, based +on the ePAPR standard, available from: + +http://devicetree.org + +If not stated otherwise, whenever a reference to a cpu node phandle is made its +value must point to a cpu node compliant with the cpu node bindings as +documented in [1]. +A topology description containing phandles to cpu nodes that are not compliant +with bindings standardized in [1] is therefore considered invalid. + +=== +2 - cpu-map node +=== + +The ARM CPU topology is defined within a container node, sitting at the top +level of the device tree (/), the cpu-map node. + +- cpu-map node + + Usage: Required to define ARM CPU topology + + Description: The cpu-map node is just a container node where its +subnodes describe the CPU topology + + Node name must be cpu-map. + + A cpu-map node's child nodes can be: + + - one or more cluster nodes + + Any other configuration is considered invalid. + +The cpu-map node can only contain three types of child nodes: + +- cluster node +- core node +- thread node + Why not put the topology in the /cpus nodes? I don't really see the point of having a flat list of cpus and separate topology info. There is some compatibility issue, but adding optional levels for clusters can be handled. I thought this would break all code relying on /cpu nodes being /cpus node's children. Furthermore, I was told that the /cpus node can only have /cpu nodes as children. IIRC the context, that was in regards to putting things like the PMUs under the /cpus node. Or are you referring to something else? I think this situation is a bit different. You will have to support existing single cluster systems without the hierarchy. If you wish so, we can define the topology in the /cpus node, fine by me. +whose bindings are described in paragraph 3. + +The nodes
Re: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
Adding Ben H and Michal...
On 04/10/2013 02:29 AM, Andrew Murray wrote:
The pci_process_bridge_OF_ranges function, used to parse the ranges
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
One comment below. Otherwise,
Reviewed-by: Rob Herring rob.herr...@calxeda.com
You need also need acks from Ben and Michal.
[...]
+ /* Act based on address space type */
+ res = NULL;
+ switch ((pci_space 24) 0x3) {
+ case 1: /* PCI IO space */
+ pr_info( IO 0x%016llx..0x%016llx - 0x%016llx\n,
+cpu_addr, cpu_addr + size - 1, pci_addr);
+
+ /* We support only one IO range */
+ if (hose-pci_io_size) {
+ pr_info( \\-- Skipped (too many) !\n);
+ continue;
+ }
+#if defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE)
How about if (!IS_ENABLED(CONFIG_64BIT)) instead.
+ /* On 32 bits, limit I/O space to 16MB */
+ if (size 0x0100)
+ size = 0x0100;
+
+ /* 32 bits needs to map IOs here */
+ hose-io_base_virt = ioremap(cpu_addr, size);
+
+ /* Expect trouble if pci_addr is not 0 */
+ if (primary)
+ isa_io_base =
+ (unsigned long)hose-io_base_virt;
+#endif /* CONFIG_PPC32 || CONFIG_MICROBLAZE */
+ /* pci_io_size and io_base_phys always represent IO
+ * space starting at 0 so we factor in pci_addr
+ */
+ hose-pci_io_size = pci_addr + size;
+ hose-io_base_phys = cpu_addr - pci_addr;
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 2/3] of/pci: Provide support for parsing PCI DT ranges property
On 04/10/2013 02:29 AM, Andrew Murray wrote:
This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture
specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
A few minor things below, otherwise:
Reviewed-by: Rob Herring rob.herr...@calxeda.com
drivers/of/address.c | 63 +
drivers/of/of_pci.c| 112
include/linux/of_address.h | 42
3 files changed, 145 insertions(+), 72 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..e87f45e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,69 @@ int of_pci_address_to_resource(struct device_node *dev,
int bar,
return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser-node = node;
+ parser-pna = of_n_addr_cells(node);
+ parser-np = parser-pna + na + ns;
+
+ parser-range = of_get_property(node, ranges, rlen);
+ if (parser-range == NULL)
+ return -ENOENT;
+
+ parser-end = parser-range + rlen / sizeof(__be32);
+
+ return 0;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser
*parser,
+ struct of_pci_range *range)
+{
+ const int na = 3, ns = 2;
+
+ if (!parser-range || parser-range + parser-np parser-end)
Add a !range check
+ return NULL;
+
+ range-pci_space = be32_to_cpup(parser-range);
+ range-flags = of_bus_pci_get_flags(parser-range);
+ range-pci_addr = of_read_number(parser-range + 1, ns);
+ range-cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ range-size = of_read_number(parser-range + parser-pna + na, ns);
+
+ parser-range += parser-np;
+
+ /* Now consume following elements while they are contiguous */
+ while (parser-range + parser-np = parser-end) {
+ u32 flags, pci_space;
+ u64 pci_addr, cpu_addr, size;
+
+ pci_space = be32_to_cpup(parser-range);
This line doesn't do anything.
+ flags = of_bus_pci_get_flags(parser-range);
+ pci_addr = of_read_number(parser-range + 1, ns);
+ cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ size = of_read_number(parser-range + parser-pna + na, ns);
+
+ if (flags != range-flags)
+ break;
+ if (pci_addr != range-pci_addr + range-size ||
+ cpu_addr != range-cpu_addr + range-size)
+ break;
+
+ range-size += size;
+ parser-range += parser-np;
+ }
+
+ return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
#endif /* CONFIG_PCI */
/*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0611248..9680dc6 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -82,67 +82,43 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
void pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary)
{
- const u32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(dev);
- int np = pna + 5;
int memno = 0, isa_hole = -1;
- u32 pci_space;
- unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
unsigned long long
Re: [PATCH v5 3/3] of/pci: mips: convert to common of_pci_range_parser
On 04/10/2013 02:29 AM, Andrew Murray wrote:
This patch converts the pci_load_of_ranges function to use the new common
of_pci_range_parser.
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Reviewed-by: Rob Herring rob.herr...@calxeda.com
---
arch/mips/pci/pci.c | 50 --
1 files changed, 16 insertions(+), 34 deletions(-)
diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 0872f12..bee49a4 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
#ifdef CONFIG_OF
void pci_load_of_ranges(struct pci_controller *hose, struct device_node
*node)
{
- const __be32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(node);
- int np = pna + 5;
+ struct of_pci_range_range range;
+ struct of_pci_range_parser parser;
+ u32 res_type;
pr_info(PCI host bridge %s ranges:\n, node-full_name);
- ranges = of_get_property(node, ranges, rlen);
- if (ranges == NULL)
- return;
hose-of_node = node;
- while ((rlen -= np * 4) = 0) {
- u32 pci_space;
+ if (of_pci_range_parser(parser, node))
+ return;
+
+ for_each_of_pci_range(parser, range) {
struct resource *res = NULL;
- u64 addr, size;
-
- pci_space = be32_to_cpup(ranges[0]);
- addr = of_translate_address(node, ranges + 3);
- size = of_read_number(ranges + pna + 3, 2);
- ranges += np;
- switch ((pci_space 24) 0x3) {
- case 1: /* PCI IO space */
+
+ res_type = range.flags IORESOURCE_TYPE_BITS;
+ if (res_type == IORESOURCE_IO) {
pr_info( IO 0x%016llx..0x%016llx\n,
- addr, addr + size - 1);
+ range.addr, range.addr + range.size - 1);
hose-io_map_base =
- (unsigned long)ioremap(addr, size);
+ (unsigned long)ioremap(range.addr, range.size);
res = hose-io_resource;
- res-flags = IORESOURCE_IO;
- break;
- case 2: /* PCI Memory space */
- case 3: /* PCI 64 bits Memory space */
+ } else if (res_type == IORESOURCE_MEM) {
pr_info( MEM 0x%016llx..0x%016llx\n,
- addr, addr + size - 1);
+ range.addr, range.addr + range.size - 1);
res = hose-mem_resource;
- res-flags = IORESOURCE_MEM;
- break;
- }
- if (res != NULL) {
- res-start = addr;
- res-name = node-full_name;
- res-end = res-start + size - 1;
- res-parent = NULL;
- res-sibling = NULL;
- res-child = NULL;
}
+ if (res != NULL)
+ of_pci_range_to_resource(range, node, res);
}
}
#endif
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv8 04/19] of/pci: Add of_pci_get_devfn() function
On 04/09/2013 04:06 PM, Thomas Petazzoni wrote:
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Reviewed-by: Rob Herring rob.herr...@calxeda.com
---
drivers/of/of_pci.c| 34 +-
include/linux/of_pci.h |1 +
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index ebb408b..b77e8d8 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -9,14 +9,15 @@
#endif
static inline int __of_pci_pci_compare(struct device_node *node,
-unsigned int devfn)
+unsigned int data)
{
- unsigned int size;
- const __be32 *reg = of_get_property(node, reg, size);
+ int devfn;
- if (!reg || size 5 * sizeof(__be32))
+ devfn = of_pci_get_devfn(node);
+ if (devfn 0)
return 0;
- return ((be32_to_cpup(reg[0]) 8) 0xff) == devfn;
+
+ return devfn == data;
}
struct device_node *of_pci_find_child_device(struct device_node *parent,
@@ -208,3 +209,26 @@ void pci_process_bridge_OF_ranges(struct pci_controller
*hose,
}
}
#endif
+
+/**
+ * of_pci_get_devfn() - Get device and function numbers for a device node
+ * @np: device node
+ *
+ * Parses a standard 5-cell PCI resource and returns an 8-bit value that can
+ * be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
+ * and function numbers respectively. On error a negative error code is
+ * returned.
+ */
+int of_pci_get_devfn(struct device_node *np)
+{
+ unsigned int size;
+ const __be32 *reg;
+
+ reg = of_get_property(np, reg, size);
+
+ if (!reg || size 5 * sizeof(__be32))
+ return -EINVAL;
+
+ return (be32_to_cpup(reg) 8) 0xff;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_devfn);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index e56182f..302aca0 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,6 +11,7 @@ int of_irq_map_pci(const struct pci_dev *pdev, struct
of_irq *out_irq);
struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
+int of_pci_get_devfn(struct device_node *np);
void pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv8 05/19] of/pci: Add of_pci_parse_bus_range() function
On 04/09/2013 04:06 PM, Thomas Petazzoni wrote:
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse a bus-range property as specified by
device nodes representing PCI bridges.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Reviewed-by: Rob Herring rob.herr...@calxeda.com
---
drivers/of/of_pci.c| 25 +
include/linux/of_pci.h |1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index b77e8d8..e9106dc 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -232,3 +232,28 @@ int of_pci_get_devfn(struct device_node *np)
return (be32_to_cpup(reg) 8) 0xff;
}
EXPORT_SYMBOL_GPL(of_pci_get_devfn);
+
+/**
+ * of_pci_parse_bus_range() - parse the bus-range property of a PCI device
+ * @node: device node
+ * @res: address to a struct resource to return the bus-range
+ *
+ * Returns 0 on success or a negative error-code on failure.
+ */
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
+{
+ const __be32 *values;
+ int len;
+
+ values = of_get_property(node, bus-range, len);
+ if (!values || len sizeof(*values) * 2)
+ return -EINVAL;
+
+ res-name = node-name;
+ res-start = be32_to_cpup(values++);
+ res-end = be32_to_cpup(values);
+ res-flags = IORESOURCE_BUS;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 302aca0..be97a6f 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -12,6 +12,7 @@ struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
int of_pci_get_devfn(struct device_node *np);
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
void pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [GIT PULL] dt: run C pre-processor on *.dts, create some standard headers
On 04/05/2013 01:46 PM, Stephen Warren wrote: Rob, it might be worth keeping this in a separate branch in linux-next so you can pull it out if it causes any issues. I've been using these patches for quite a while now, but there's always opportunity for surprises on architectures I don't use. I did just fix a bug when building with O= a few days back, hence the V2 that I posted as patches. Pulled into my for-next branch. Rob This branch enhances the support for running dtc on device tree files. A dedicated directory is created for header files that provide constants for device-tree bindings. The kbuild dependency script processor is enhanced to support processing the dependency outputs from multiple separate commands at once. The kbuild dtc rule is modified so that the C pre-processor is always applied when compiling any device tree. Some standard headers are created which define common constants for GPIO, IRQ, and ARM GIC device tree bindings. The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-dtc-cpp-chroot-std-headers for you to fetch changes up to 4be505d4fc7a07371a2b658469ca1dda3ca3: ARM: dt: create a DT header for the GIC Stephen Warren (7): kbuild: create an include chroot for DT bindings kbuild: fixdep: support concatenated dep files kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp ARM: dt: add header to define GPIO flags ARM: dt: add header to define IRQ flags ARM: dt: create a DT header for the GIC arch/arm/boot/dts/include/dt-bindings |1 + include/dt-bindings/gpio/gpio.h | 15 +++ .../dt-bindings/interrupt-controller/arm-gic.h | 22 + include/dt-bindings/interrupt-controller/irq.h | 19 scripts/Makefile.lib| 17 ++-- scripts/basic/fixdep.c | 93 -- 6 files changed, 125 insertions(+), 42 deletions(-) create mode 12 arch/arm/boot/dts/include/dt-bindings create mode 100644 include/dt-bindings/gpio/gpio.h create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h create mode 100644 include/dt-bindings/interrupt-controller/irq.h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] of/pci: Provide support for parsing PCI DT ranges property
Adding PPC and Microblaze maintainers.
On 04/08/2013 09:33 AM, Andrew Murray wrote:
This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture
specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).
The modifications to microblaze, mips and powerpc have not been tested.
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
Compared to the v3 sent by Andrew Murray, the following changes have
been made:
* Unify and move duplicate pci_process_bridge_OF_ranges functions to
drivers/of/of_pci.c as suggested by Rob Herring
This part should really be a separate patch with just the move and
should have acks from PPC and Microblaze maintainers.
Otherwise it looks okay to me.
Rob
* Fix potential build errors with Microblaze/MIPS
Compared to [PATCH v5 01/17] of/pci: Provide support for parsing PCI DT
ranges property, the following changes have been made:
* Correct use of IORESOURCE_* as suggested by Russell King
* Improved interface and naming as suggested by Thierry Reding
Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did:
* Add a memset() on the struct of_pci_range_iter when starting the
for loop in for_each_pci_range(). Otherwise, with an uninitialized
of_pci_range_iter, of_pci_process_ranges() may crash.
* Add parenthesis around 'res', 'np' and 'iter' in the
for_each_of_pci_range macro definitions. Otherwise, passing
something like foobar as 'res' didn't work.
* Rebased on top of 3.9-rc2, which required fixing a few conflicts in
the Microblaze code.
v2:
This follows on from suggestions made by Grant Likely
(marc.info/?l=linux-kernelm=136079602806328)
---
arch/microblaze/include/asm/pci-bridge.h |5 +-
arch/microblaze/pci/pci-common.c | 192
--
arch/mips/pci/pci.c | 50 +++--
arch/powerpc/include/asm/pci-bridge.h|5 +-
arch/powerpc/kernel/pci-common.c | 192
--
drivers/of/address.c | 63 ++
drivers/of/of_pci.c | 168 ++
include/linux/of_address.h | 42 +++
include/linux/of_pci.h |3 +
9 files changed, 294 insertions(+), 426 deletions(-)
diff --git a/arch/microblaze/include/asm/pci-bridge.h
b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
#include linux/pci.h
#include linux/list.h
#include linux/ioport.h
+#include linux/of_pci.h
struct device_node;
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller
*hose,
extern struct pci_controller *pci_find_hose_for_OF_device(
struct device_node *node);
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary);
-
/* Allocate free a PCI host bridge structure */
extern struct pci_controller *pcibios_alloc_controller(struct device_node
*dev);
extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c
b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev,
int bar,
*end = rsrc-end - offset;
}
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify a single interrupt.
A commonly used variant is two cell on which #interrupt-cells = 2
and the first cell defines the index of the interrupt in the controller
and the second cell is used to specify any of the following flags:
- 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
An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)
But setting #interrupt-cells = 2 on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.
This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)
interrupt-parent = gpio6;
interrupts = 16 8;
A call to of_irq_to_resource() is made and this function calls to
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
int irq = irq_of_parse_and_map(dev, index);
..
r-start = r-end = irq;
}
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that need the IRQ type/level flags defined in
the DT won't be able to get it.
But the interrupt controllers that need the information should be able
to get to it via irqd_get_trigger_type. What problem exactly are you
trying to fix? What driver would use this?
My understanding of the IORESOURCE_IRQ_xxx (and DMA) bits are they are
ISA specific and therefore should not be used on non-ISA buses.
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6] pstore/ram: Add ramoops support for the Flattened Device Tree.
On 04/08/2013 02:54 PM, Bryan Freed wrote: Sorry for dropping the ball on this one, Anton. Thank you for your feedback and modifications in the code. I gotta ask, however, why do you completely remove key ramoops fields like record_size and ftrace_size? From your 9/7/2012 comments (again, sorry for the delay in getting back to you): Personally, I don't see how this fits into device tree. It doesn't describe hardware, instead it's more a configuration stuff, which usually we try to not put into the device tree. It would be better to have a sane defaults in ramoops, instead of introducing more virtual stuff in the device tree. That is, feel free to change defaults if they seem to be not enough for most your setups. So there are only two alternatives I can see to set these fields. 1. Pass kernel command line parameters, or 2. Modify the defaults in ram.c. Neither of these alternatives is particularly clean to me. The first is shunned to avoid clutter on the command line. And the second requires us to maintain our own version of ram.c or push our defaults on the rest of the community. We (ok, maybe just 'I') prefer to keep our device specific values in the device tree, even though it is not strictly defining hardware in the system. What do you think of at least keeping the record_size, console_size and ftrace_size fields as optional in the ramoops device tree specification? And as a more general question, why should we try not to put configuration in the device tree? It seems like a great (and portable) place to put this stuff. It certainly seems better to have it there than hardwired in the kernel or tacked onto the kernel command line. You have to account for the fact that you may not be able to update the dtb which may be part of firmware. I can imagine you might want to change some of the sizes frequently based on what you are doing and trying to capture. So even if you put in the DT, you need some easy way to override the settings. This could always be fixed-up by the bootloader which is what is done for things we don't expect the firmware to know like initrd address/size and kernel command line. This is why the prior discussion I mentioned below suggested putting all this in the /chosen node. Rob Thanks, bryan. On Sun, Apr 7, 2013 at 10:43 AM, Anton Vorontsov an...@enomsg.org wrote: On Thu, Apr 04, 2013 at 09:03:47PM -0500, Rob Herring wrote: On Mon, Sep 17, 2012 at 1:23 AM, Anton Vorontsov cbouatmai...@gmail.com wrote: On Fri, Sep 07, 2012 at 10:29:10PM -0700, Anton Vorontsov wrote: On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote: When called with a non-zero of_node, fill out a new ramoops_platform_data with data from the specified Flattened Device Tree node. Update ramoops documentation with the new FDT interface. Update devicetree/binding documentation with pstore/ramoops.txt. Thanks for your work, Bryan! There were a few issues, I fixed them myself but I need your confirmation if you're OK w/ all the changes. [...] So, the resulting patch is down below. But I have not pushed it out yet, I'm waiting for your sign off. If you're OK with the changes, please reply with 'Signed-off-by: Bryan Freed bfr...@chromium.org' Bryan, have you had a chance to look into this? Whatever happened to this? Olof was also looking at doing a binding back in Jan 2012: http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg09905.html I don't know. Bryan's patch looked good, I'd happily apply it. But I still need Bryan's Signed-off-by tag. :-/ Or, somebody needs to sign off on his behalf (anyone from Chromium project?). Or redo the patch. Thanks, Anton ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote: On 04/09/2013 12:16 AM, Stephen Warren wrote: On 04/08/2013 04:05 PM, Rob Herring wrote: On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt the #interrupt-cells property of an interrupt-controller is used to define the number of cells needed to specify a single interrupt. ... But the type is never returned so it can't be saved on the IRQ struct resource flags member. This means that drivers that need the IRQ type/level flags defined in the DT won't be able to get it. But the interrupt controllers that need the information should be able to get to it via irqd_get_trigger_type. What problem exactly are you trying to fix? What driver would use this? FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking back, I'm not sure if that was the right thing or whether I should have sent this same patch:-) Hi Stephen, I'm glad you agree :-) I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for the IRQ with irqd_get_trigger_type() but I prefer $subject because: irqd_get_trigger_type probably is not meant for outside of irqchips. Creating an irq_get_irq_type function which takes an irq number would be the right function as that does not expose struct irq_data. a) This works in the non-DT case with board files and filling the resources from platform data in arch/arm/mach-omap2/gpmc-smsc911x.c. So this is definitely a bug on the DT core. And hackery/abuse like this: arch/arm/mach-omap2/board-3630sdp.c:32:.flags = GPMC_MUX_ADD_DATA | IORESOURCE_IRQ_LOWLEVEL, b) I don't see why of_irq_to_resource() should discard the type/level flags when filling the IORESOURCE_IRQ if it was specified on the DT. c) We will have to change all drivers that expect to get the IRQ type flags from a IORESOURCE_IRQ struct resource. I'm not convinced that is a high number of drivers. Nearly all the occurrences of IORESOURCE_IRQ_ in drivers/ are for ISA (acpi/pnp) and drivers for ISA devices. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/7] kbuild: create an include chroot for DT bindings
On 04/04/2013 08:01 PM, Stephen Warren wrote: On 04/04/2013 05:17 PM, Rob Herring wrote: On 04/03/2013 06:34 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com The recent dtc+cpp support allows header files and C pre-processor defines/macros to be used when compiling device tree files. These headers will typically define various constants that are part of the device tree bindings. The original patch which set up the dtc+cpp include path only considered using those headers from device tree files. However, most are also useful for kernel code which needs to interpret the device tree. In both the DT files and the kernel, I'd like to include the DT-related headers in the same way, for example, dt-bindings/gpio/tegra-gpio.h. That will simplify any text which discusses the DT header locations. Creating a dt-bindings/ for kernel source to use is as simple as placing files into include/dt-bindings/. However, when compiling DT files, the include path should be restricted so that only the dt-bindings path is available; arbitrary kernel headers shouldn't be exposed. For this reason, create a specific include directory for use by dtc+cpp, and symlink dt-bindings from there to the actual location of include/dt-bindings/. For want of a better location, place this include chroot into the existing dts/ directory. arch/*/boot/dts/include/dt-bindings - ../../../../../include/dt-bindings Some headers used by device tree files may not be useful to the kernel; they may be used simply to aid in constructing the DT file (e.g. macros to create a node), but not define any information that the kernel needs to share. These may be placed directly into arch/*/boot/dts/ along with the DT files themselves. Cc: Shawn Guo shawn@linaro.org Cc: Hiroshi Doyu hd...@nvidia.com Acked-by: Michal Marek mma...@suse.cz Acked-by: Shawn Guo shawn@linaro.org Acked-by: Rob Herring rob.herr...@calxeda.com Signed-off-by: Stephen Warren swar...@nvidia.com --- Grant, Rob, Michal, I'm hoping for acks or comments from you so this series can be placed into a topic branch in the arm-soc repo, for others to build on during the 3.10 kernel cycle. Thanks. Well, you have mine here and the rest looks fine, so add it to the others. Rob, I had originally hoped for this to go into an arm-soc branch so that a number of SoCs could convert to use the feature in the same release, hence I was looking for acks to let that happen. However, it's too late in the 3.10 cycle now for that to happen. Can the series be applied to the DT tree instead; people can convert during the 3.11 cycle. That is fine. Can you send me a pull request. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] documentation: iommu: add description of ARM System MMU binding
On 04/04/2013 11:50 AM, Will Deacon wrote:
This patch adds a description of the device tree binding for the ARM
System MMU architecture.
Cc: Rob Herring robherri...@gmail.com
Cc: Andreas Herrmann andreas.herrm...@calxeda.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
Hello,
The driver for this is still a WIP. Both Andreas and myself have prototype
code, but we're planning to merge that together to get something more
general. Deciding on the binding is a good first step.
Thanks for getting this out.
All comments welcome,
Will
.../devicetree/bindings/iommu/arm,smmu.txt | 61
++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
new file mode 100644
index 000..938325f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -0,0 +1,61 @@
+* ARM System MMU Architecture Implementation
+
+ARM SoCs may contain an implementation of the ARM System Memory
+Management Unit Architecture, which can be used to provide 1 or 2 stages
+of address translation to bus masters external to the CPU.
+
+The SMMU may also raise interrupts in response to various fault
+conditions.
+
+** System MMU required properties:
+
+- compatible: Should be one of arm,smmu-v1 or arm,smmu-v2
+ depending on the version of the architecture
+ implemented.
We can keep these, but we should have specific models like arm,smmu-400,
etc. as well.
+
+- reg : Base address and size of the SMMU.
+
+- #global-interrupts : The number of global interrupts exposed by the
+ device.
+
+- interrupts: Interrupt list, with the first #global-irqs entries
+ corresponding to the global interrupts and any
+ following entries corresponding to context interrupts,
+ specified in order of their indexing by the SMMU.
+
+- mmu-masters : A list of phandles to device nodes representing bus
+ masters for which the SMMU can provide a translation.
+
+- stream-ids: A list of 16-bit values corresponding to the StreamIDs
+ for the devices listed in the mmu-masters property.
+ This list must be same length as mmu-masters, so
+ masters with multiple stream-ids will have multiple
+ entries in mmu-masters.
Your example below is actually 32-bit values in the DTB. You can
annotate them to actually be 16-bit if you want. But I would just leave
them as 32-bit.
+
+** System MMU optional properties:
+
+- smmu-parent : When multiple SMMUs are chained together, this
+ property can be used to provide a phandle to the
+ parent SMMU (that is the next SMMU on the path going
+ from the mmu-masters towards memory) node for this
+ SMMU.
Does the SMMU need to know if it is coherent or not?
Rob
+
+Example:
+
+smmu {
+compatible = arm,smmu-v1;
+reg = 0xba5e 0x1;
+#global-interrupts = 2;
+interrupts = 0 32 4,
+ 0 33 4,
+ 0 34 4, /* This is the first context
interrupt */
+ 0 35 4,
+ 0 36 4,
+ 0 37 4;
+mmu-masters = dma0,
+ dma0,
+ dma1;
+stream-ids = 0xd01d,
+ 0xd01e,
+ 0xd11c;
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] documentation: iommu: add description of ARM System MMU binding
On 04/05/2013 11:57 AM, Will Deacon wrote: Hi Rob, On Fri, Apr 05, 2013 at 05:43:06PM +0100, Rob Herring wrote: [...] +- compatible: Should be one of arm,smmu-v1 or arm,smmu-v2 + depending on the version of the architecture + implemented. We can keep these, but we should have specific models like arm,smmu-400, etc. as well. Ok, if distinctions need to be between MMU-400 and a v1 implementation, then we can add those strings later. No, you want to have specific values in the dtb's up front. If there is something needed later in the kernel, you don't want to require a dtb update then. Adding future parts later is fine, but we already know what blocks we have. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [GIT PULL] dt: run C pre-processor on *.dts, create some standard headers
On 04/05/2013 01:46 PM, Stephen Warren wrote: Rob, it might be worth keeping this in a separate branch in linux-next so you can pull it out if it causes any issues. I've been using these patches for quite a while now, but there's always opportunity for surprises on architectures I don't use. I did just fix a bug when building with O= a few days back, hence the V2 that I posted as patches. No, you're on the hook to fix anything. :) My next branch is pulled by Grant and is not rebased. Perhaps we should change that, but it's not going to happen right away. Rob This branch enhances the support for running dtc on device tree files. A dedicated directory is created for header files that provide constants for device-tree bindings. The kbuild dependency script processor is enhanced to support processing the dependency outputs from multiple separate commands at once. The kbuild dtc rule is modified so that the C pre-processor is always applied when compiling any device tree. Some standard headers are created which define common constants for GPIO, IRQ, and ARM GIC device tree bindings. The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-dtc-cpp-chroot-std-headers for you to fetch changes up to 4be505d4fc7a07371a2b658469ca1dda3ca3: ARM: dt: create a DT header for the GIC Stephen Warren (7): kbuild: create an include chroot for DT bindings kbuild: fixdep: support concatenated dep files kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp ARM: dt: add header to define GPIO flags ARM: dt: add header to define IRQ flags ARM: dt: create a DT header for the GIC arch/arm/boot/dts/include/dt-bindings |1 + include/dt-bindings/gpio/gpio.h | 15 +++ .../dt-bindings/interrupt-controller/arm-gic.h | 22 + include/dt-bindings/interrupt-controller/irq.h | 19 scripts/Makefile.lib| 17 ++-- scripts/basic/fixdep.c | 93 -- 6 files changed, 125 insertions(+), 42 deletions(-) create mode 12 arch/arm/boot/dts/include/dt-bindings create mode 100644 include/dt-bindings/gpio/gpio.h create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h create mode 100644 include/dt-bindings/interrupt-controller/irq.h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 1/8] dt: describe base reset signal binding
On 03/28/2013 11:35 AM, Philipp Zabel wrote:
From: Stephen Warren swar...@nvidia.com
This binding is intended to represent the hardware reset signals present
internally in most IC (SoC, FPGA, ...) designs.
It consists of a binding for a reset controller device (provider), and a
pair of properties, resets and reset-names, to link a device node
(consumer) to its reset controller via phandle, similarly to the clock
and interrupt bindings.
The reset controller has all information necessary to reset the consumer
device. That could be provided via device tree, or it could be implemented
in hardware.
The aim is to enable device drivers to request a framework API to issue a
reset simply by providing their struct device pointer as the most common
case.
Signed-off-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Shawn Guo shawn@linaro.org
Reviewed-by: Marek Vasut ma...@denx.de
Looks good.
Acked-by: Rob Herring rob.herr...@calxeda.com
Rob
---
Documentation/devicetree/bindings/reset/reset.txt | 75
+++
1 file changed, 75 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/reset.txt
diff --git a/Documentation/devicetree/bindings/reset/reset.txt
b/Documentation/devicetree/bindings/reset/reset.txt
new file mode 100644
index 000..31db6ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/reset.txt
@@ -0,0 +1,75 @@
+= Reset Signal Device Tree Bindings =
+
+This binding is intended to represent the hardware reset signals present
+internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
+standalone chips are most likely better represented as GPIOs, although there
+are likely to be exceptions to this rule.
+
+Hardware blocks typically receive a reset signal. This signal is generated by
+a reset provider (e.g. power management or clock module) and received by a
+reset consumer (the module being reset, or a module managing when a sub-
+ordinate module is reset). This binding exists to represent the provider and
+consumer, and provide a way to couple the two together.
+
+A reset signal is represented by the phandle of the provider, plus a reset
+specifier - a list of DT cells that represents the reset signal within the
+provider. The length (number of cells) and semantics of the reset specifier
+are dictated by the binding of the reset provider, although common schemes
+are described below.
+
+A word on where to place reset signal consumers in device tree: It is
possible
+in hardware for a reset signal to affect multiple logically separate HW
blocks
+at once. In this case, it would be unwise to represent this reset signal in
+the DT node of each affected HW block, since if activated, an unrelated block
+may be reset. Instead, reset signals should be represented in the DT node
+where it makes most sense to control it; this may be a bus node if all
+children of the bus are affected by the reset signal, or an individual HW
+block node for dedicated reset signals. The intent of this binding is to give
+appropriate software access to the reset signals in order to manage the HW,
+rather than to slavishly enumerate the reset signal that affects each HW
+block.
+
+= Reset providers =
+
+Required properties:
+#reset-cells:Number of cells in a reset specifier; Typically 0 for
nodes
+ with a single reset output and 1 for nodes with multiple
+ reset outputs.
+
+For example:
+
+ rst: reset-controller {
+ #reset-cells = 1;
+ };
+
+= Reset consumers =
+
+Required properties:
+resets: List of phandle and reset specifier pairs, one pair
+ for each reset signal that affects the device, or that the
+ device manages. Note: if the reset provider specifies '0' for
+ #reset-cells, then only the phandle portion of the pair will
+ appear.
+
+Optional properties:
+reset-names: List of reset signal name strings sorted in the same order as
+ the resets property. Consumers drivers will use reset-names to
+ match reset signal names with reset specifiers.
+
+For example:
+
+ device {
+ resets = rst 20;
+ reset-names = reset;
+ };
+
+This represents a device with a single reset signal named reset.
+
+ bus {
+ resets = rst 10 rst 11 rst 12 rst 11;
+ reset-names = i2s1, i2s2, dma, mixer;
+ };
+
+This represents a bus that controls the reset signal of each of four sub-
+ordinate devices. Consider for example a bus that fails to operate unless no
+child device has reset asserted.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/7] kbuild: create an include chroot for DT bindings
On 04/03/2013 06:34 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com The recent dtc+cpp support allows header files and C pre-processor defines/macros to be used when compiling device tree files. These headers will typically define various constants that are part of the device tree bindings. The original patch which set up the dtc+cpp include path only considered using those headers from device tree files. However, most are also useful for kernel code which needs to interpret the device tree. In both the DT files and the kernel, I'd like to include the DT-related headers in the same way, for example, dt-bindings/gpio/tegra-gpio.h. That will simplify any text which discusses the DT header locations. Creating a dt-bindings/ for kernel source to use is as simple as placing files into include/dt-bindings/. However, when compiling DT files, the include path should be restricted so that only the dt-bindings path is available; arbitrary kernel headers shouldn't be exposed. For this reason, create a specific include directory for use by dtc+cpp, and symlink dt-bindings from there to the actual location of include/dt-bindings/. For want of a better location, place this include chroot into the existing dts/ directory. arch/*/boot/dts/include/dt-bindings - ../../../../../include/dt-bindings Some headers used by device tree files may not be useful to the kernel; they may be used simply to aid in constructing the DT file (e.g. macros to create a node), but not define any information that the kernel needs to share. These may be placed directly into arch/*/boot/dts/ along with the DT files themselves. Cc: Shawn Guo shawn@linaro.org Cc: Hiroshi Doyu hd...@nvidia.com Acked-by: Michal Marek mma...@suse.cz Acked-by: Shawn Guo shawn@linaro.org Acked-by: Rob Herring rob.herr...@calxeda.com Signed-off-by: Stephen Warren swar...@nvidia.com --- Grant, Rob, Michal, I'm hoping for acks or comments from you so this series can be placed into a topic branch in the arm-soc repo, for others to build on during the 3.10 kernel cycle. Thanks. Well, you have mine here and the rest looks fine, so add it to the others. Rob This first patch was previously posted separately as V2. I'm including it here to keep it with the whole series. I hope this series can be applied as a topic branch in arm-soc. --- arch/arm/boot/dts/include/dt-bindings |1 + scripts/Makefile.lib |2 +- 2 files changed, 2 insertions(+), 1 deletion(-) create mode 12 arch/arm/boot/dts/include/dt-bindings diff --git a/arch/arm/boot/dts/include/dt-bindings b/arch/arm/boot/dts/include/dt-bindings new file mode 12 index 000..08c00e4 --- /dev/null +++ b/arch/arm/boot/dts/include/dt-bindings @@ -0,0 +1 @@ +../../../../../include/dt-bindings \ No newline at end of file diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 07125e6..af35521 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -158,7 +158,7 @@ ld_flags = $(LDFLAGS) $(ldflags-y) dtc_cpp_flags = -Wp,-MD,$(depfile) -nostdinc\ -I$(srctree)/arch/$(SRCARCH)/boot/dts \ - -I$(srctree)/arch/$(SRCARCH)/include/dts\ + -I$(srctree)/arch/$(SRCARCH)/boot/dts/include \ -undef -D__DTS__ # Finds the multi-part object the current object will be linked into ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6] pstore/ram: Add ramoops support for the Flattened Device Tree.
On Mon, Sep 17, 2012 at 1:23 AM, Anton Vorontsov cbouatmai...@gmail.com wrote: On Fri, Sep 07, 2012 at 10:29:10PM -0700, Anton Vorontsov wrote: On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote: When called with a non-zero of_node, fill out a new ramoops_platform_data with data from the specified Flattened Device Tree node. Update ramoops documentation with the new FDT interface. Update devicetree/binding documentation with pstore/ramoops.txt. Thanks for your work, Bryan! There were a few issues, I fixed them myself but I need your confirmation if you're OK w/ all the changes. [...] So, the resulting patch is down below. But I have not pushed it out yet, I'm waiting for your sign off. If you're OK with the changes, please reply with 'Signed-off-by: Bryan Freed bfr...@chromium.org' Bryan, have you had a chance to look into this? Whatever happened to this? Olof was also looking at doing a binding back in Jan 2012: http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg09905.html Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: of_iomap() and devres questions
On 04/02/2013 02:25 PM, Markus Mayer wrote: Hi all, I have a few questions regarding the implementation of the of_iomap() function. As it currently stands, the function parses the device tree for the device's address and then simply calls ioremap() with that address and the associated size. The first question that has come up is why of_iomap() doesn't also call request_mem_region()? Is there a particular reason for it or has it just not yet been implemented? Don't know. It probably should not and make cause some breakage. The second question is regarding the use of devres in of_iomap(). Would it make sense for of_iomap() to use devm_ioremap() or, better yet, devm_request_and_ioremap() instead of simply calling ioremap()? You should not be using of_iomap in a driver, but rather the functions you mention. of_iomap is mainly used in cases where there is no driver or struct device. Which means devm_* functions would be pointless. Also there is no way to get from a struct device_node ptr to a struct device ptr. Rob Thanks, -Markus ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2] DMA: PL330: Add check if device tree compatible
On Thu, Mar 21, 2013 at 4:39 AM, Vinod Koul vinod.k...@intel.com wrote:
On Tue, Mar 05, 2013 at 02:55:31PM +0530, Padmavathi Venna wrote:
This patch register the dma controller with generic dma helpers only
in DT case. This also adds some extra error handling in the driver.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Reported-by: Sachin Kamat sachin.ka...@linaro.org
What's the status on this? It is needed for 3.9 to fix pl330 on highbank.
Rob
---
Based on Vinod Koul next branch.
Changes since V1:
- return silently when of_dma_controller_register fails, as
suggested by Arnd.
drivers/dma/pl330.c | 38 +++---
1 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 7181531..5dbc594 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
{
struct dma_pl330_platdata *pdat;
struct dma_pl330_dmac *pdmac;
- struct dma_pl330_chan *pch;
+ struct dma_pl330_chan *pch, *_p;
struct pl330_info *pi;
struct dma_device *pd;
struct resource *res;
@@ -2984,7 +2984,16 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
ret = dma_async_device_register(pd);
if (ret) {
dev_err(adev-dev, unable to register DMAC\n);
- goto probe_err2;
+ goto probe_err3;
+ }
+
+ if (adev-dev.of_node) {
+ ret = of_dma_controller_register(adev-dev.of_node,
+ of_dma_pl330_xlate, pdmac);
+ if (ret) {
+ dev_err(adev-dev,
+ unable to register DMA to the generic DT DMA
helpers\n);
Indent?
+ }
}
dev_info(adev-dev,
@@ -2995,16 +3004,21 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
pi-pcfg.data_bus_width / 8, pi-pcfg.num_chan,
pi-pcfg.num_peri, pi-pcfg.num_events);
- ret = of_dma_controller_register(adev-dev.of_node,
- of_dma_pl330_xlate, pdmac);
- if (ret) {
- dev_err(adev-dev,
- unable to register DMA to the generic DT DMA helpers\n);
- goto probe_err2;
- }
-
return 0;
+probe_err3:
+ amba_set_drvdata(adev, NULL);
+ /* Idle the DMAC */
+ list_for_each_entry_safe(pch, _p, pdmac-ddma.channels,
+ chan.device_node) {
+
+ /* Remove the channel */
+ list_del(pch-chan.device_node);
+
+ /* Flush the channel */
+ pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
+ pl330_free_chan_resources(pch-chan);
free_chan for error handling in probe?
+ }
probe_err2:
pl330_del(pi);
probe_err1:
@@ -3023,8 +3037,10 @@ static int pl330_remove(struct amba_device *adev)
if (!pdmac)
return 0;
- of_dma_controller_free(adev-dev.of_node);
+ if (adev-dev.of_node)
+ of_dma_controller_free(adev-dev.of_node);
+ dma_async_device_unregister(pdmac-ddma);
amba_set_drvdata(adev, NULL);
/* Idle the DMAC */
--
1.7.4.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of_net.h: Provide dummy functions if OF_NET is not configured
On 04/01/2013 01:19 PM, Guenter Roeck wrote:
of_get_mac_address() and of_get_phy_mode() are only provided if OF_NET
is configured. While most callers check for the define, not all do, and those
who do require #ifdef around the code. For those who don't, the missing check
can result in errors such as
How about removing the ifdef from those callers?
Rob
arch/powerpc/sysdev/tsi108_dev.c:107:3: error: implicit declaration of
function 'of_get_mac_address' [-Werror=implicit-function-declaration]
arch/powerpc/sysdev/mv64x60_dev.c:253:2: error: implicit declaration of
function 'of_get_mac_address' [-Werror=implicit-function-declaration]
Provide dummy function declarations if OF_NET is not configured. This is safe
because all callers do check the return values. If desired, at least some of
the #ifdefs in the code can subsequently be removed.
Cc: David Daney david.da...@cavium.com
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
include/linux/of_net.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/of_net.h b/include/linux/of_net.h
index f474641..61bf53b 100644
--- a/include/linux/of_net.h
+++ b/include/linux/of_net.h
@@ -11,6 +11,16 @@
#include linux/of.h
extern const int of_get_phy_mode(struct device_node *np);
extern const void *of_get_mac_address(struct device_node *np);
+#else
+static inline const int of_get_phy_mode(struct device_node *np)
+{
+ return -ENODEV;
+}
+
+static inline const void *of_get_mac_address(struct device_node *np)
+{
+ return NULL;
+}
#endif
#endif /* __LINUX_OF_NET_H */
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of_net.h: Provide dummy functions if OF_NET is not configured
On 04/01/2013 02:01 PM, Guenter Roeck wrote:
On Mon, Apr 01, 2013 at 01:44:24PM -0500, Rob Herring wrote:
On 04/01/2013 01:19 PM, Guenter Roeck wrote:
of_get_mac_address() and of_get_phy_mode() are only provided if OF_NET
is configured. While most callers check for the define, not all do, and
those
who do require #ifdef around the code. For those who don't, the missing
check
can result in errors such as
How about removing the ifdef from those callers?
That would be the next step, after/if this one is accepted.
If not, it doesn't make sense to waste my time.
Assuming that is done:
Acked-by: Rob Herring rob.herr...@calxeda.com
Presumably with the follow-on patches, this can go in thru the net tree.
Rob
Thanks,
Guenter
Rob
arch/powerpc/sysdev/tsi108_dev.c:107:3: error: implicit declaration of
function 'of_get_mac_address' [-Werror=implicit-function-declaration]
arch/powerpc/sysdev/mv64x60_dev.c:253:2: error: implicit declaration of
function 'of_get_mac_address' [-Werror=implicit-function-declaration]
Provide dummy function declarations if OF_NET is not configured. This is
safe
because all callers do check the return values. If desired, at least some of
the #ifdefs in the code can subsequently be removed.
Cc: David Daney david.da...@cavium.com
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
include/linux/of_net.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/of_net.h b/include/linux/of_net.h
index f474641..61bf53b 100644
--- a/include/linux/of_net.h
+++ b/include/linux/of_net.h
@@ -11,6 +11,16 @@
#include linux/of.h
extern const int of_get_phy_mode(struct device_node *np);
extern const void *of_get_mac_address(struct device_node *np);
+#else
+static inline const int of_get_phy_mode(struct device_node *np)
+{
+ return -ENODEV;
+}
+
+static inline const void *of_get_mac_address(struct device_node *np)
+{
+ return NULL;
+}
#endif
#endif /* __LINUX_OF_NET_H */
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Add missing node iteration stubs for disabled CONFIG_OF
On 03/09/2013 02:15 PM, Tomasz Figa wrote:
This patch moves several for_each macros out of the #ifdef CONFIG_OF
block and adds inline stubs for functions used by these macros, compiled
conditionally when CONFIG_OF is not enabled.
This eliminates the need to explicitly check for CONFIG_OF in driver
code using mentioned functions and macros.
Do you have some users of this?
Rob
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
include/linux/of.h | 92
+-
1 file changed, 63 insertions(+), 29 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index a0f1292..7a736b8 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -86,6 +86,31 @@ static inline struct device_node *of_node_get(struct
device_node *node)
static inline void of_node_put(struct device_node *node) { }
#endif /* !CONFIG_OF_DYNAMIC */
+#define for_each_node_by_name(dn, name) \
+ for (dn = of_find_node_by_name(NULL, name); dn; \
+ dn = of_find_node_by_name(dn, name))
+#define for_each_node_by_type(dn, type) \
+ for (dn = of_find_node_by_type(NULL, type); dn; \
+ dn = of_find_node_by_type(dn, type))
+#define for_each_compatible_node(dn, type, compatible) \
+ for (dn = of_find_compatible_node(NULL, type, compatible); dn; \
+ dn = of_find_compatible_node(dn, type, compatible))
+#define for_each_matching_node(dn, matches) \
+ for (dn = of_find_matching_node(NULL, matches); dn; \
+ dn = of_find_matching_node(dn, matches))
+#define for_each_matching_node_and_match(dn, matches, match) \
+ for (dn = of_find_matching_node_and_match(NULL, matches, match); \
+ dn; dn = of_find_matching_node_and_match(dn, matches, match))
+#define for_each_child_of_node(parent, child) \
+ for (child = of_get_next_child(parent, NULL); child != NULL; \
+ child = of_get_next_child(parent, child))
+#define for_each_available_child_of_node(parent, child) \
+ for (child = of_get_next_available_child(parent, NULL); child != NULL; \
+ child = of_get_next_available_child(parent, child))
+#define for_each_node_with_property(dn, prop_name) \
+ for (dn = of_find_node_with_property(NULL, prop_name); dn; \
+ dn = of_find_node_with_property(dn, prop_name))
+
#ifdef CONFIG_OF
/* Pointer for first entry in chain of all nodes. */
@@ -167,19 +192,10 @@ static inline const char *of_node_full_name(const
struct device_node *np)
extern struct device_node *of_find_node_by_name(struct device_node *from,
const char *name);
-#define for_each_node_by_name(dn, name) \
- for (dn = of_find_node_by_name(NULL, name); dn; \
- dn = of_find_node_by_name(dn, name))
extern struct device_node *of_find_node_by_type(struct device_node *from,
const char *type);
-#define for_each_node_by_type(dn, type) \
- for (dn = of_find_node_by_type(NULL, type); dn; \
- dn = of_find_node_by_type(dn, type))
extern struct device_node *of_find_compatible_node(struct device_node *from,
const char *type, const char *compat);
-#define for_each_compatible_node(dn, type, compatible) \
- for (dn = of_find_compatible_node(NULL, type, compatible); dn; \
- dn = of_find_compatible_node(dn, type, compatible))
extern struct device_node *of_find_matching_node_and_match(
struct device_node *from,
const struct of_device_id *matches,
@@ -190,12 +206,6 @@ static inline struct device_node *of_find_matching_node(
{
return of_find_matching_node_and_match(from, matches, NULL);
}
-#define for_each_matching_node(dn, matches) \
- for (dn = of_find_matching_node(NULL, matches); dn; \
- dn = of_find_matching_node(dn, matches))
-#define for_each_matching_node_and_match(dn, matches, match) \
- for (dn = of_find_matching_node_and_match(NULL, matches, match); \
- dn; dn = of_find_matching_node_and_match(dn, matches, match))
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);
@@ -207,14 +217,6 @@ extern struct device_node *of_get_next_available_child(
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; \
- child = of_get_next_child(parent, child))
-
-#define for_each_available_child_of_node(parent, child) \
- for (child = of_get_next_available_child(parent, NULL); child != NULL; \
- child = of_get_next_available_child(parent, child))
-
static inline int of_get_child_count(const struct device_node *np)
{
struct device_node *child;
@@ -228,10 +230,6 @@ static inline int
Re: [PATCH v6 7/7] irqchip: s3c24xx: add devicetree support
On 03/26/2013 05:10 PM, Heiko Stübner wrote:
Add the necessary code to initialize the interrupt controller
thru devicetree data using the irqchip infrastructure.
Signed-off-by: Heiko Stuebner he...@sntech.de
Acked-by: Rob Herring rob.herr...@calxeda.com
---
.../interrupt-controller/samsung,s3c24xx-irq.txt | 53 +
drivers/irqchip/irq-s3c24xx.c | 231
+++-
2 files changed, 278 insertions(+), 6 deletions(-)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
new file mode 100644
index 000..c54c5a9
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
@@ -0,0 +1,53 @@
+Samsung S3C24XX Interrupt Controllers
+
+The S3C24XX SoCs contain a custom set of interrupt controllers providing a
+varying number of interrupt sources. The set consists of a main- and sub-
+controller and on newer SoCs even a second main controller.
+
+Required properties:
+- compatible: Compatible property value should be samsung,s3c2410-irq
+ for machines before s3c2416 and samsung,s3c2416-irq for s3c2416 and
later.
+
+- reg: Physical base address of the controller and length of memory mapped
+ region.
+
+- interrupt-controller : Identifies the node as an interrupt controller
+
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value shall be 4 and interrupt descriptor shall
+ have the following format:
+ ctrl_num parent_irq ctrl_irq type
+
+ ctrl_num contains the controller to use:
+ - 0 ... main controller
+ - 1 ... sub controller
+ - 2 ... second main controller on s3c2416 and s3c2450
+ parent_irq contains the parent bit in the main controller and will be
+ ignored in main controllers
+ ctrl_irq contains the interrupt bit of the controller
+ type contains the trigger type to use
+
+Example:
+
+ interrupt-controller@4a00 {
+ compatible = samsung,s3c2410-irq;
+ reg = 0x4a00 0x100;
+ interrupt-controller;
+ #interrupt-cells=4;
+ };
+
+ [...]
+
+ serial@5000 {
+ compatible = samsung,s3c2410-uart;
+ reg = 0x5000 0x4000;
+ interrupt-parent = subintc;
+ interrupts = 1 28 0 4, 1 28 1 4;
+ };
+
+ rtc@5700 {
+ compatible = samsung,s3c2410-rtc;
+ reg = 0x5700 0x100;
+ interrupt-parent = intc;
+ interrupts = 0 30 0 3, 0 8 0 3;
+ };
diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index 02b82db..5e40b34 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -25,6 +25,9 @@
#include linux/ioport.h
#include linux/device.h
#include linux/irqdomain.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/of_address.h
#include asm/exception.h
#include asm/mach/irq.h
@@ -36,6 +39,8 @@
#include plat/regs-irqtype.h
#include plat/pm.h
+#include irqchip.h
+
#define S3C_IRQTYPE_NONE 0
#define S3C_IRQTYPE_EINT 1
#define S3C_IRQTYPE_EDGE 2
@@ -94,7 +99,10 @@ static void s3c_irq_mask(struct irq_data *data)
if (parent_intc) {
parent_data = parent_intc-irqs[irq_data-parent_irq];
- /* check to see if we need to mask the parent IRQ */
+ /* check to see if we need to mask the parent IRQ
+ * The parent_irq is always in main_intc, so the hwirq
+ * for find_mapping does not need an offset in any case.
+ */
if ((mask parent_data-sub_bits) == parent_data-sub_bits) {
irqno = irq_find_mapping(parent_intc-domain,
irq_data-parent_irq);
@@ -294,10 +302,18 @@ static void s3c_irq_demux(unsigned int irq, struct
irq_desc *desc)
{
struct irq_chip *chip = irq_desc_get_chip(desc);
struct s3c_irq_data *irq_data = irq_desc_get_chip_data(desc);
+ struct s3c_irq_intc *intc = irq_data-intc;
struct s3c_irq_intc *sub_intc = irq_data-sub_intc;
unsigned long src;
unsigned long msk;
unsigned int n;
+ unsigned int offset;
+
+ /* we're using individual domains for the non-dt case
+ * and one big domain for the dt case where the subintc
+ * starts at hwirq number 32.
+ */
+ offset = (intc-domain-of_node) ? 32 : 0;
chained_irq_enter(chip, desc);
@@ -310,14 +326,15 @@ static void s3c_irq_demux(unsigned int irq, struct
irq_desc *desc)
while (src) {
n = __ffs(src);
src = ~(1 n);
- generic_handle_irq
Re: [PATCH V2] cpufreq: ARM big LITTLE: Add generic cpufreq driver and its DT glue
On 03/26/2013 04:51 AM, Viresh Kumar wrote:
big LITTLE is ARM's new Architecture focussing power/performance needs of
modern
world. More information about big LITTLE can be found here:
http://www.arm.com/products/processors/technologies/biglittleprocessing.php
http://lwn.net/Articles/481055/
In order to keep cpufreq support for all big LITTLE platforms simple/generic,
this patch tries to add a generic cpufreq driver layer for all big LITTLE
platforms.
The driver is divided into two parts:
- Core driver: Generic and shared across all big LITTLE SoC's
- Glue drivers: Per platform drivers providing ops to the core driver
This patch adds in a generic glue driver which would extract information from
Device Tree.
Future SoC's can either reuse the DT glue or write their own depending on the
need.
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
V1-V2:
- It was reviewed here earlier: https://lkml.org/lkml/2013/3/4/614
- It supports OPP library now and doesn't create a new binding for cpufreq
table
- It doesn't add any dependency on cluster node in DT, rather we work with
existing cpu nodes, Documentation updated.
- cpu_dev used because of OPP library and hence dev_err/dbg/info used at
multiple places.
- Interface with glue driver updated a bit
- IS_ERR_OR_NULL replaced with IS_ERR for clk_get
- clk_get_sys used instead of clk_get and name of clk is also updated
- Few more minor cleanups done.
It is pushed here:
http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/cpufreq-biglittle
.../bindings/cpufreq/arm_big_little_dt.txt | 65 +
MAINTAINERS| 11 +
drivers/cpufreq/Kconfig.arm| 12 +
drivers/cpufreq/Makefile | 4 +
drivers/cpufreq/arm_big_little.c | 282
+
drivers/cpufreq/arm_big_little.h | 40 +++
drivers/cpufreq/arm_big_little_dt.c| 92 +++
7 files changed, 506 insertions(+)
create mode 100644
Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
create mode 100644 drivers/cpufreq/arm_big_little.c
create mode 100644 drivers/cpufreq/arm_big_little.h
create mode 100644 drivers/cpufreq/arm_big_little_dt.c
diff --git a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
new file mode 100644
index 000..34a460d
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
@@ -0,0 +1,65 @@
+Generic ARM big LITTLE cpufreq driver's DT glue
+---
+
+This is DT specific glue layer for generic cpufreq driver for big LITTLE
+systems.
I fail to see anything bL specific here. This is just multi-cluster, but
even for that I don't see anything new other than simply allowing per
cpu or per cluster opp's. The fact that we have one opp for a cluster is
simply an implementation decision in CortexA cores.
+
+Both required and optional properties listed below must be defined
+under node /cpus/cpu@x. Where x is the first cpu inside a cluster.
+
+NOTE: Cpus should boot in the order specified in DT and all cpus for a
cluster
+must be present contiguously. Generic DT driver will check only node 'x' for
+cpu:x.
The OS cannot necessarily control the order. The OS should be able to
boot on which ever core comes up first.
+
+Required properties:
+- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
+ for details
+
+Optional properties:
+- clock-latency: Specify the possible maximum transition latency for clock,
+ in unit of nanoseconds.
Don't we already have transition-latency defined? Don't create
something new. Ideally, this should have had -ns appended, but the
binding is already defined.
+
+Examples:
+
+cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ compatible = arm,cortex-a15;
+ reg = 0;
+ next-level-cache = L2;
+ operating-points =
+ /* kHzuV */
+ 792000 110
+ 396000 95
+ 198000 85
+ ;
+ clock-latency = 61036; /* two CLK32 periods */
+ };
+
+ cpu@1 {
+ compatible = arm,cortex-a15;
+ reg = 1;
+ next-level-cache = L2;
+ };
+
+ cpu@100 {
+ compatible = arm,cortex-a7;
+ reg = 100;
+ next-level-cache = L2;
+ operating-points =
+ /* kHzuV */
+ 792000 95
+ 396000 75
+ 198000 45
+ ;
+ clock-latency = 61036; /* two CLK32
Re: [PATCH 4/6] pci: Add PCIe driver for Samsung Exynos
On 03/22/2013 11:07 PM, Jingoo Han wrote: Exynos5440 has a PCIe controller which can be used as Root Complex. This driver supports a PCIe controller as Root Complex mode. Signed-off-by: Surendranath Gurivireddy Balla suren.re...@samsung.com Signed-off-by: Siva Reddy Kallam siva.kal...@samsung.com Signed-off-by: Jingoo Han jg1@samsung.com --- .../devicetree/bindings/pci/exynos-pcie.txt| 56 + drivers/pci/host/Kconfig |5 + drivers/pci/host/Makefile |1 + drivers/pci/host/pci-exynos.c | 1139 4 files changed, 1201 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/exynos-pcie.txt create mode 100644 drivers/pci/host/Makefile create mode 100644 drivers/pci/host/pci-exynos.c [...] + +/* synopsis specific PCIE configuration registers*/ If this is a standard IP block, then the driver naming should reflect that. I suspect there are several others with the same IP block. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/11] sp804 and integrator timer CLKSRC_OF support
On 03/21/2013 08:24 AM, Arnd Bergmann wrote:
On Wednesday 20 March 2013, Rob Herring wrote:
This series is dependent on my CLKSRC_OF clean-up in arm-soc, my
sched_clock selection series[1], and Arnd's default machine descriptor
patch (for default clocksource_of_init call). The full series is
available here:
All your patches look good to me, but I'd suggest you don't depend on
my default machine descriptor patch yet, that just makes the dependencies
harder to track, and we can easily remove all the calls once they
are obsoletely.
I really only need the hunk that calls clocksource_of_init which is
really somewhat unrelated to a default machine desc. So what if I just
pull out this hunk to a separate patch:
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 955d92d..abff4e9 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -22,6 +22,7 @@
#include linux/errno.h
#include linux/profile.h
#include linux/timer.h
+#include linux/clocksource.h
#include linux/irq.h
#include asm/thread_info.h
@@ -115,6 +116,10 @@ int __init
register_persistent_clock(clock_access_fn read_boot,
void __init time_init(void)
{
- machine_desc-init_time();
+ if (machine_desc-init_time)
+ machine_desc-init_time();
+ else
+ clocksource_of_init();
+
sched_clock_postinit();
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 01/11] OF: add empty of_device_is_available for !OF
On 03/21/2013 09:18 AM, Mark Rutland wrote: On Wed, Mar 20, 2013 at 10:54:01PM +, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com Add an empty version of of_device_is_available. Signed-off-by: Rob Herring rob.herr...@calxeda.com --- include/linux/of.h |5 + 1 file changed, 5 insertions(+) diff --git a/include/linux/of.h b/include/linux/of.h index a0f1292..6fe655b 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -379,6 +379,11 @@ static inline int of_device_is_compatible(const struct device_node *device, return 0; } +static inline int of_device_is_available(const struct device_node *device,) I assume that comma shouldn't be there? ^ Right. I've fixed that up in my git tree. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On 03/21/2013 11:26 AM, Gregory CLEMENT wrote:
In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.
Armada XP and Armada 370 share a dtsi file which have also be
converted to 64 bits. This lead to convert all the device tree files
to 64 bits even the one used for Armada 370 (which don't support
LPAE)
This was heavily based on the work of Lior Amsalem.
Signed-off-by: Lior Amsalem al...@marvell.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
[snip]
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 5b70820..562f24c 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -15,8 +15,7 @@
* This file contains the definitions that are common to the Armada
* 370 and Armada XP SoC.
*/
-
-/include/ skeleton.dtsi
+/include/ skeleton64.dtsi
/ {
model = Marvell Armada 370 and XP SoC;
@@ -37,20 +36,20 @@
coherency-fabric@d0020200 {
compatible = marvell,coherency-fabric;
- reg = 0xd0020200 0xb0,
- 0xd0021810 0x1c;
+ reg = 0 0xd0020200 0 0xb0,
+ 0 0xd0021810 0 0x1c;
};
soc {
- #address-cells = 1;
- #size-cells = 1;
+ #address-cells = 2;
+ #size-cells = 2;
If all the addresses for the soc bus are below 4GB or even within a 4GB
range if using the ranges property, then changing all this and
everything below it is kind of pointless.
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 02/11] ARM: remove extra timer-sp control register clearing
On 03/21/2013 12:58 PM, Linus Walleij wrote: On Wed, Mar 20, 2013 at 11:54 PM, Rob Herring robherri...@gmail.com wrote: From: Rob Herring rob.herr...@calxeda.com The timer-sp initialization code clears the control register before initializing the timers, so every platform doing this is redundant. For unused timers, we should not care what state they are in. Signed-off-by: Rob Herring rob.herr...@calxeda.com (...) diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c index ea96144..4cb322d 100644 --- a/arch/arm/mach-integrator/integrator_ap.c +++ b/arch/arm/mach-integrator/integrator_ap.c @@ -643,10 +643,6 @@ static void __init ap_timer_init(void) clk_prepare_enable(clk); rate = clk_get_rate(clk); - writel(0, TIMER0_VA_BASE + TIMER_CTRL); - writel(0, TIMER1_VA_BASE + TIMER_CTRL); - writel(0, TIMER2_VA_BASE + TIMER_CTRL); - As noted this is not an init function for timer-sp.c so please drop this hunk of the patch. Maybe this zeroing is pointless but that would be a separate patch that I can test. Okay. I'll split this out. diff --git a/arch/arm/mach-integrator/integrator_cp.c b/arch/arm/mach-integrator/integrator_cp.c index 2b0db82..c68e7d8 100644 --- a/arch/arm/mach-integrator/integrator_cp.c +++ b/arch/arm/mach-integrator/integrator_cp.c @@ -33,7 +33,6 @@ #include mach/platform.h #include asm/setup.h #include asm/mach-types.h -#include asm/hardware/arm_timer.h What doe this change has to do with $SUBJECT? If I remove TIMER_CTRL use, then I don't need the header that defines it any more. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] arm: mvebu: Select DMA_BOUNCE when LPAE is selected in Kconfig
On 03/21/2013 11:26 AM, Gregory CLEMENT wrote: From: Lior Amsalem al...@marvell.com For mvebu IOs are 32 bits and we have 40 bits memory due to LPAE so make sure we give 32 bits addresses to the IOs. Signed-off-by: Lior Amsalem al...@marvell.com Tested-by: Franklin f...@marvell.com Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com --- arch/arm/mach-mvebu/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 440b13e..617da94 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -13,6 +13,7 @@ config ARCH_MVEBU select MVEBU_CLK_CORE select MVEBU_CLK_CPU select MVEBU_CLK_GATING + select DMABOUNCE if ARM_LPAE This alone is not enough to use bounce buffers. Am I missing something? Rob if ARCH_MVEBU ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 03/11] ARM: timer-sp: convert to use CLKSRC_OF init
On 03/21/2013 02:35 PM, Russell King - ARM Linux wrote:
On Wed, Mar 20, 2013 at 05:54:03PM -0500, Rob Herring wrote:
+clk0 = of_clk_get(np, 0);
+if (IS_ERR(clk0))
+clk0 = NULL;
+
+/* Get the 2nd clock if the timer has 2 timer clocks */
+if (of_count_phandle_with_args(np, clocks, #clock-cells) == 3) {
+clk1 = of_clk_get(np, 1);
+if (IS_ERR(clk1)) {
+pr_err(sp804: %s clock not found: %d\n, np-name,
+(int)PTR_ERR(clk1));
+return;
+}
+} else
+clk1 = clk0;
+
+irq = irq_of_parse_and_map(np, 0);
+if (irq = 0)
+return;
+
+of_property_read_u32(np, arm,sp804-has-irq, irq_num);
+if (irq_num == 2)
+tmr2_evt = true;
+
+__sp804_clockevents_init(base + (tmr2_evt ? TIMER_2_BASE : 0),
+ irq, tmr2_evt ? clk1 : clk0, name);
+__sp804_clocksource_and_sched_clock_init(base + (tmr2_evt ? 0 :
TIMER_2_BASE),
+ name, tmr2_evt ? clk0 : clk1,
1);
This just looks totally screwed to me.
A SP804 cell has two timers, and has one clock input and two clock
enable inputs. The clock input is common to both timers. The timers
only count on the rising edge of the clock input when the enable
input is high. (the APB PCLK also matters too...)
Now, the clock enable inputs are controlled by the SP810 system
controller to achieve different clock rates for each. So, we *can*
view an SP804 as having two clock inputs.
Exactly. Effectively, the TIMCLKENx are just dividers of the clock input.
However, the two clock inputs do not depend on whether one or the
other has an IRQ or not. Timer 1 is always clocked by TIMCLK
TIMCLKEN1. Timer 2 is always clocked by TIMCLK TIMCLKEN2.
Using the logic above, the clocks depend on how the IRQs are wired
up... really? Can you see from my description above why that is
screwed? What bearing does the IRQ have on the wiring of the
clock inputs?
No. I'm simply swapping which timer is used for clksrc vs. clkevt based
on the irq connection DT describes. If only timer 2's irq being hooked
up, then timer 2 is the clkevt. Otherwise I always use timer 1 for the
clkevt because I either have a combined interrupt or timer 1 interrupt
hooked up.
Perhaps re-writing it like this would be more clear:
if (irq_num == 2){
__sp804_clockevents_init(base + TIMER_2_BASE, irq, clk1, name);
__sp804_clocksource_and_sched_clock_init(base, name, clk0, 1);
} else {
__sp804_clockevents_init(base, irq, clk0, name);
__sp804_clocksource_and_sched_clock_init(base + TIMER_2_BASE,
name, clk1, 1);
}
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 02/11] ARM: remove extra timer-sp control register clearing
On 03/21/2013 02:23 PM, Russell King - ARM Linux wrote: On Wed, Mar 20, 2013 at 05:54:02PM -0500, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com The timer-sp initialization code clears the control register before initializing the timers, so every platform doing this is redundant. For unused timers, we should not care what state they are in. NAK. We do care what state they're in. What if they have their interrupt enable bit set, and IRQ is shared with the clock event timer? No, this patch is just wrong. Okay, I can have the timer init function clear the register in the case that even when the timer is unused. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] of: remove /proc/device-tree
On 03/20/2013 09:51 AM, Grant Likely wrote:
The same data is now available in sysfs, so we can remove the code
that exports it in /proc and replace it with a symlink to the sysfs
version.
Tested on versatile qemu model and mpc5200 eval board. More testing
would be appreciated.
I would suggest testing with lshw in particular. That's the only
/proc/device-tree user I've come across. lshw can get system data from
either DMI or DT, so it is a possible alternative to dmidecode on ARM.
There aren't a large number of properties that it reads though.
Rob
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: David S. Miller da...@davemloft.net
---
drivers/of/Kconfig |8 --
drivers/of/base.c | 59 +---
fs/proc/Makefile|1 -
fs/proc/proc_devtree.c | 243
---
fs/proc/root.c |3 -
include/linux/of.h |1 -
include/linux/proc_fs.h | 16
7 files changed, 2 insertions(+), 329 deletions(-)
delete mode 100644 fs/proc/proc_devtree.c
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index d2d7be9..edb97e2 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -7,14 +7,6 @@ config OF
menu Device Tree and Open Firmware support
depends on OF
-config PROC_DEVICETREE
- bool Support for device tree in /proc
- depends on PROC_FS !SPARC
- help
- This option adds a device-tree directory under /proc which contains
- an image of the device tree that the kernel copies from Open
- Firmware or other boot firmware. If unsure, say Y here.
-
config OF_SELFTEST
bool Device Tree Runtime self tests
help
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 363e98b..6714114 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -184,6 +184,8 @@ static int __of_node_add(struct device_node *np)
np-kobj.kset = of_kset;
if (!np-parent) {
/* Nodes without parents are new top level trees */
+ if (extra == 0)
+ proc_symlink(device-tree, NULL,
/sys/firmware/ofw/device-tree-0);
rc = kobject_add(np-kobj, NULL, device-tree-%i, extra++);
} else {
name = kbasename(np-full_name);
@@ -1375,12 +1377,6 @@ int of_add_property(struct device_node *np, struct
property *prop)
*next = prop;
raw_spin_unlock_irqrestore(devtree_lock, flags);
-#ifdef CONFIG_PROC_DEVICETREE
- /* try to add to proc as well if it was initialized */
- if (np-pde)
- proc_device_tree_add_prop(np-pde, prop);
-#endif /* CONFIG_PROC_DEVICETREE */
-
return 0;
}
@@ -1421,12 +1417,6 @@ int of_remove_property(struct device_node *np, struct
property *prop)
if (!found)
return -ENODEV;
-#ifdef CONFIG_PROC_DEVICETREE
- /* try to remove the proc node as well */
- if (np-pde)
- proc_device_tree_remove_prop(np-pde, prop);
-#endif /* CONFIG_PROC_DEVICETREE */
-
return 0;
}
@@ -1475,12 +1465,6 @@ int of_update_property(struct device_node *np, struct
property *newprop)
if (!found)
return -ENODEV;
-#ifdef CONFIG_PROC_DEVICETREE
- /* try to add to proc as well if it was initialized */
- if (np-pde)
- proc_device_tree_update_prop(np-pde, newprop, oldprop);
-#endif /* CONFIG_PROC_DEVICETREE */
-
return 0;
}
@@ -1515,22 +1499,6 @@ int of_reconfig_notify(unsigned long action, void *p)
return notifier_to_errno(rc);
}
-#ifdef CONFIG_PROC_DEVICETREE
-static void of_add_proc_dt_entry(struct device_node *dn)
-{
- struct proc_dir_entry *ent;
-
- ent = proc_mkdir(strrchr(dn-full_name, '/') + 1, dn-parent-pde);
- if (ent)
- proc_device_tree_add_node(dn, ent);
-}
-#else
-static void of_add_proc_dt_entry(struct device_node *dn)
-{
- return;
-}
-#endif
-
/**
* of_attach_node - Plug a device node into the tree and global list.
*/
@@ -1551,31 +1519,9 @@ int of_attach_node(struct device_node *np)
raw_spin_unlock_irqrestore(devtree_lock, flags);
of_node_add(np);
- of_add_proc_dt_entry(np);
return 0;
}
-#ifdef CONFIG_PROC_DEVICETREE
-static void of_remove_proc_dt_entry(struct device_node *dn)
-{
- struct device_node *parent = dn-parent;
- struct property *prop = dn-properties;
-
- while (prop) {
- remove_proc_entry(prop-name, dn-pde);
- prop = prop-next;
- }
-
- if (dn-pde)
- remove_proc_entry(dn-pde-name, parent-pde);
-}
-#else
-static void of_remove_proc_dt_entry(struct device_node *dn)
-{
- return;
-}
-#endif
-
/**
* of_detach_node - Unplug a node from the device tree.
*
@@ -1631,7
[PATCH 01/11] OF: add empty of_device_is_available for !OF
From: Rob Herring rob.herr...@calxeda.com
Add an empty version of of_device_is_available.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
include/linux/of.h |5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/of.h b/include/linux/of.h
index a0f1292..6fe655b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -379,6 +379,11 @@ static inline int of_device_is_compatible(const struct
device_node *device,
return 0;
}
+static inline int of_device_is_available(const struct device_node *device,)
+{
+ return 0;
+}
+
static inline struct property *of_find_property(const struct device_node *np,
const char *name,
int *lenp)
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 02/11] ARM: remove extra timer-sp control register clearing
From: Rob Herring rob.herr...@calxeda.com
The timer-sp initialization code clears the control register before
initializing the timers, so every platform doing this is redundant.
For unused timers, we should not care what state they are in.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
arch/arm/mach-integrator/integrator_ap.c |4
arch/arm/mach-integrator/integrator_cp.c |7 ---
arch/arm/mach-realview/core.c|9 -
arch/arm/mach-versatile/core.c |9 -
arch/arm/mach-vexpress/v2m.c |3 ---
5 files changed, 32 deletions(-)
diff --git a/arch/arm/mach-integrator/integrator_ap.c
b/arch/arm/mach-integrator/integrator_ap.c
index ea96144..4cb322d 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -643,10 +643,6 @@ static void __init ap_timer_init(void)
clk_prepare_enable(clk);
rate = clk_get_rate(clk);
- writel(0, TIMER0_VA_BASE + TIMER_CTRL);
- writel(0, TIMER1_VA_BASE + TIMER_CTRL);
- writel(0, TIMER2_VA_BASE + TIMER_CTRL);
-
integrator_clocksource_init(rate, (void __iomem *)TIMER2_VA_BASE);
integrator_clockevent_init(rate, (void __iomem *)TIMER1_VA_BASE,
IRQ_TIMERINT1);
diff --git a/arch/arm/mach-integrator/integrator_cp.c
b/arch/arm/mach-integrator/integrator_cp.c
index 2b0db82..c68e7d8 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -33,7 +33,6 @@
#include mach/platform.h
#include asm/setup.h
#include asm/mach-types.h
-#include asm/hardware/arm_timer.h
#include asm/hardware/icst.h
#include mach/cm.h
@@ -267,7 +266,6 @@ static void __init cp_of_timer_init(void)
base = of_iomap(node, 0);
if (WARN_ON(!base))
return;
- writel(0, base + TIMER_CTRL);
sp804_clocksource_init(base, node-name);
err = of_property_read_string(of_aliases,
@@ -279,7 +277,6 @@ static void __init cp_of_timer_init(void)
if (WARN_ON(!base))
return;
irq = irq_of_parse_and_map(node, 0);
- writel(0, base + TIMER_CTRL);
sp804_clockevents_init(base, irq, node-name);
}
@@ -510,10 +507,6 @@ static void __init intcp_init_irq(void)
static void __init cp_timer_init(void)
{
- writel(0, TIMER0_VA_BASE + TIMER_CTRL);
- writel(0, TIMER1_VA_BASE + TIMER_CTRL);
- writel(0, TIMER2_VA_BASE + TIMER_CTRL);
-
sp804_clocksource_init(TIMER2_VA_BASE, timer2);
sp804_clockevents_init(TIMER1_VA_BASE, IRQ_TIMERINT1, timer1);
}
diff --git a/arch/arm/mach-realview/core.c b/arch/arm/mach-realview/core.c
index 1d5ee5c..8ce6366 100644
--- a/arch/arm/mach-realview/core.c
+++ b/arch/arm/mach-realview/core.c
@@ -35,7 +35,6 @@
#include mach/hardware.h
#include asm/irq.h
#include asm/mach-types.h
-#include asm/hardware/arm_timer.h
#include asm/hardware/icst.h
#include asm/mach/arch.h
@@ -355,14 +354,6 @@ void __init realview_timer_init(unsigned int timer_irq)
(REALVIEW_TIMCLK REALVIEW_TIMER4_EnSel) | val,
__io_address(REALVIEW_SCTL_BASE));
- /*
-* Initialise to a known state (all timers off)
-*/
- writel(0, timer0_va_base + TIMER_CTRL);
- writel(0, timer1_va_base + TIMER_CTRL);
- writel(0, timer2_va_base + TIMER_CTRL);
- writel(0, timer3_va_base + TIMER_CTRL);
-
sp804_clocksource_init(timer3_va_base, timer3);
sp804_clockevents_init(timer0_va_base, timer_irq, timer0);
}
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 25160ae..286303a 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -40,7 +40,6 @@
#include linux/bitops.h
#include asm/irq.h
-#include asm/hardware/arm_timer.h
#include asm/hardware/icst.h
#include asm/mach-types.h
@@ -799,14 +798,6 @@ void __init versatile_timer_init(void)
(VERSATILE_TIMCLK VERSATILE_TIMER4_EnSel) | val,
__io_address(VERSATILE_SCTL_BASE));
- /*
-* Initialise to a known state (all timers off)
-*/
- writel(0, TIMER0_VA_BASE + TIMER_CTRL);
- writel(0, TIMER1_VA_BASE + TIMER_CTRL);
- writel(0, TIMER2_VA_BASE + TIMER_CTRL);
- writel(0, TIMER3_VA_BASE + TIMER_CTRL);
-
sp804_clocksource_init(TIMER3_VA_BASE, timer3);
sp804_clockevents_init(TIMER0_VA_BASE, IRQ_TIMERINT0_1, timer0);
}
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 6215717..9fbfbe4 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -61,9 +61,6 @@ static void __init v2m_sp804_init(void __iomem *base,
unsigned int irq)
if (WARN_ON(!base || irq == NO_IRQ))
return;
- writel(0, base + TIMER_1_BASE + TIMER_CTRL);
- writel(0, base + TIMER_2_BASE + TIMER_CTRL);
-
sp804_clocksource_init(base
[PATCH 03/11] ARM: timer-sp: convert to use CLKSRC_OF init
From: Rob Herring rob.herr...@calxeda.com
This adds CLKSRC_OF based init for sp804 timer. The clock initialization is
refactored to support retrieving the clock(s) from the DT.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
arch/arm/Kconfig |1 +
arch/arm/common/timer-sp.c | 98 +-
arch/arm/include/asm/hardware/timer-sp.h | 16 +++--
3 files changed, 95 insertions(+), 20 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f0f90f0..774131a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1172,6 +1172,7 @@ config PLAT_VERSATILE
config ARM_TIMER_SP804
bool
select CLKSRC_MMIO
+ select CLKSRC_OF if OF
select HAVE_SCHED_CLOCK
source arch/arm/mm/Kconfig
diff --git a/arch/arm/common/timer-sp.c b/arch/arm/common/timer-sp.c
index 9d2d3ba..3e86835 100644
--- a/arch/arm/common/timer-sp.c
+++ b/arch/arm/common/timer-sp.c
@@ -25,33 +25,28 @@
#include linux/interrupt.h
#include linux/irq.h
#include linux/io.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_irq.h
#include asm/sched_clock.h
#include asm/hardware/arm_timer.h
-static long __init sp804_get_clock_rate(const char *name)
+static long __init sp804_get_clock_rate(struct clk *clk)
{
- struct clk *clk;
long rate;
int err;
- clk = clk_get_sys(sp804, name);
- if (IS_ERR(clk)) {
- pr_err(sp804: %s clock not found: %d\n, name,
- (int)PTR_ERR(clk));
- return PTR_ERR(clk);
- }
-
err = clk_prepare(clk);
if (err) {
- pr_err(sp804: %s clock failed to prepare: %d\n, name, err);
+ pr_err(sp804: clock failed to prepare: %d\n, err);
clk_put(clk);
return err;
}
err = clk_enable(clk);
if (err) {
- pr_err(sp804: %s clock failed to enable: %d\n, name, err);
+ pr_err(sp804: clock failed to enable: %d\n, err);
clk_unprepare(clk);
clk_put(clk);
return err;
@@ -59,7 +54,7 @@ static long __init sp804_get_clock_rate(const char *name)
rate = clk_get_rate(clk);
if (rate 0) {
- pr_err(sp804: %s clock failed to get rate: %ld\n, name, rate);
+ pr_err(sp804: clock failed to get rate: %ld\n, rate);
clk_disable(clk);
clk_unprepare(clk);
clk_put(clk);
@@ -77,9 +72,21 @@ static u32 sp804_read(void)
void __init __sp804_clocksource_and_sched_clock_init(void __iomem *base,
const char *name,
+struct clk *clk,
int use_sched_clock)
{
- long rate = sp804_get_clock_rate(name);
+ long rate;
+
+ if (!clk) {
+ clk = clk_get_sys(sp804, name);
+ if (IS_ERR(clk)) {
+ pr_err(sp804: clock not found: %d\n,
+ (int)PTR_ERR(clk));
+ return;
+ }
+ }
+
+ rate = sp804_get_clock_rate(clk);
if (rate 0)
return;
@@ -171,12 +178,20 @@ static struct irqaction sp804_timer_irq = {
.dev_id = sp804_clockevent,
};
-void __init sp804_clockevents_init(void __iomem *base, unsigned int irq,
- const char *name)
+void __init __sp804_clockevents_init(void __iomem *base, unsigned int irq,
struct clk *clk, const char *name)
{
struct clock_event_device *evt = sp804_clockevent;
- long rate = sp804_get_clock_rate(name);
+ long rate;
+
+ if (!clk)
+ clk = clk_get_sys(sp804, name);
+ if (IS_ERR(clk)) {
+ pr_err(sp804: %s clock not found: %d\n, name,
+ (int)PTR_ERR(clk));
+ return;
+ }
+ rate = sp804_get_clock_rate(clk);
if (rate 0)
return;
@@ -186,6 +201,57 @@ void __init sp804_clockevents_init(void __iomem *base,
unsigned int irq,
evt-irq = irq;
evt-cpumask = cpu_possible_mask;
+ writel(0, clkevt_base + TIMER_CTRL);
+
setup_irq(irq, sp804_timer_irq);
clockevents_config_and_register(evt, rate, 0xf, 0x);
}
+
+static void __init sp804_of_init(struct device_node *np)
+{
+ static bool initialized = false;
+ void __iomem *base;
+ int irq;
+ u32 irq_num = 0;
+ bool tmr2_evt = false;
+ struct clk *clk0, *clk1;
+ const char *name = of_get_property(np, compatible, NULL);
+
+ if (initialized || !of_device_is_available(np))
+ return;
+
+ base = of_iomap(np, 0);
+ if (WARN_ON(!base))
+ return;
+
+ clk0 = of_clk_get(np, 0);
+ if (IS_ERR(clk0))
+ clk0 = NULL;
+
+ /* Get
[PATCH 04/11] ARM: highbank: use OF init for sp804 timer
From: Rob Herring rob.herr...@calxeda.com
Remove the highbank specific setup for the sp804 timer now that
clocksource_of_init will do it.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
arch/arm/mach-highbank/highbank.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/arch/arm/mach-highbank/highbank.c
b/arch/arm/mach-highbank/highbank.c
index 758150e..e7df2dd 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -32,8 +32,6 @@
#include asm/cacheflush.h
#include asm/cputype.h
#include asm/smp_plat.h
-#include asm/hardware/arm_timer.h
-#include asm/hardware/timer-sp.h
#include asm/hardware/cache-l2x0.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -90,33 +88,16 @@ static void __init highbank_init_irq(void)
#endif
}
-static struct clk_lookup lookup = {
- .dev_id = sp804,
- .con_id = NULL,
-};
-
static void __init highbank_timer_init(void)
{
- int irq;
struct device_node *np;
- void __iomem *timer_base;
/* Map system registers */
np = of_find_compatible_node(NULL, NULL, calxeda,hb-sregs);
sregs_base = of_iomap(np, 0);
WARN_ON(!sregs_base);
- np = of_find_compatible_node(NULL, NULL, arm,sp804);
- timer_base = of_iomap(np, 0);
- WARN_ON(!timer_base);
- irq = irq_of_parse_and_map(np, 0);
-
of_clk_init(NULL);
- lookup.clk = of_clk_get(np, 0);
- clkdev_add(lookup);
-
- sp804_clocksource_and_sched_clock_init(timer_base + 0x20, timer1);
- sp804_clockevents_init(timer_base, irq, timer0);
clocksource_of_init();
}
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 05/11] ARM: vexpress: remove sp804 OF init
From: Rob Herring rob.herr...@calxeda.com
Remove the vexpress specific setup for the sp804 timer now that
clocksource_of_init will do it.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
arch/arm/mach-vexpress/v2m.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 9fbfbe4..09e571d 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -428,20 +428,9 @@ void __init v2m_dt_init_early(void)
static void __init v2m_dt_timer_init(void)
{
- struct device_node *node = NULL;
-
vexpress_clk_of_init();
clocksource_of_init();
- do {
- node = of_find_compatible_node(node, NULL, arm,sp804);
- } while (node vexpress_get_site_by_node(node) != VEXPRESS_SITE_MB);
- if (node) {
- pr_info(Using SP804 '%s' as a clock events source\n,
- node-full_name);
- v2m_sp804_init(of_iomap(node, 0),
- irq_of_parse_and_map(node, 0));
- }
versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
2400);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 06/11] ARM: dts: vexpress: disable CA9 core tile sp804 timer
From: Rob Herring rob.herr...@calxeda.com
The motherboard sp804 timer is used, but core tile sp804 timer is not.
According to Russell King, the clock configuration is undocumented and
defaults to 32kHz which is not desireable. So mark core tile sp804 timer
as disabled.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/vexpress-v2p-ca9.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
index 1420bb1..62d9b22 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -98,6 +98,7 @@
0 49 4;
clocks = oscclk2, oscclk2;
clock-names = timclk, apb_pclk;
+ status = disabled;
};
watchdog@100e5000 {
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 09/11] ARM: integrator-cp: convert use CLKSRC_OF for timer init
From: Rob Herring rob.herr...@calxeda.com
Move the integrator-cp timer init to timer-sp.c and use CLKSRC_OF. There is
no reason to use the aliases, so drop them from the init code.
The integrator-cp timers are mistakenly called sp804 timers in the dts, but
in fact they are not sp804 dual timers, but single timers with the same
programming model. Fix the dts to reflect this.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/integratorcp.dts |6 +++---
arch/arm/common/timer-sp.c | 29 +++
arch/arm/mach-integrator/integrator_cp.c | 32 --
3 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/arch/arm/boot/dts/integratorcp.dts
b/arch/arm/boot/dts/integratorcp.dts
index 8b11939..ff1aea0 100644
--- a/arch/arm/boot/dts/integratorcp.dts
+++ b/arch/arm/boot/dts/integratorcp.dts
@@ -24,15 +24,15 @@
};
timer0: timer@1300 {
- compatible = arm,sp804, arm,primecell;
+ compatible = arm,integrator-cp-timer;
};
timer1: timer@13000100 {
- compatible = arm,sp804, arm,primecell;
+ compatible = arm,integrator-cp-timer;
};
timer2: timer@13000200 {
- compatible = arm,sp804, arm,primecell;
+ compatible = arm,integrator-cp-timer;
};
pic: pic@1400 {
diff --git a/arch/arm/common/timer-sp.c b/arch/arm/common/timer-sp.c
index 3e86835..203a2b3 100644
--- a/arch/arm/common/timer-sp.c
+++ b/arch/arm/common/timer-sp.c
@@ -31,6 +31,7 @@
#include asm/sched_clock.h
#include asm/hardware/arm_timer.h
+#include asm/hardware/timer-sp.h
static long __init sp804_get_clock_rate(struct clk *clk)
{
@@ -255,3 +256,31 @@ static void __init sp804_of_init(struct device_node *np)
initialized = true;
}
CLOCKSOURCE_OF_DECLARE(sp804, arm,sp804, sp804_of_init);
+
+static void __init integrator_cp_of_init(struct device_node *np)
+{
+ static int init_count = 0;
+ void __iomem *base;
+ int irq;
+ const char *name = of_get_property(np, compatible, NULL);
+
+ if (init_count == 2 || !of_device_is_available(np))
+ return;
+
+ base = of_iomap(np, 0);
+ if (WARN_ON(!base))
+ return;
+
+ if (!init_count)
+ sp804_clocksource_init(base, name);
+ else {
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq = 0)
+ return;
+
+ sp804_clockevents_init(base, irq, name);
+ }
+
+ init_count++;
+}
+CLOCKSOURCE_OF_DECLARE(intcp, arm,integrator-cp-timer,
integrator_cp_of_init);
\ No newline at end of file
diff --git a/arch/arm/mach-integrator/integrator_cp.c
b/arch/arm/mach-integrator/integrator_cp.c
index c68e7d8..5729c3d 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -249,37 +249,6 @@ static void __init intcp_init_early(void)
}
#ifdef CONFIG_OF
-
-static void __init cp_of_timer_init(void)
-{
- struct device_node *node;
- const char *path;
- void __iomem *base;
- int err;
- int irq;
-
- err = of_property_read_string(of_aliases,
- arm,timer-primary, path);
- if (WARN_ON(err))
- return;
- node = of_find_node_by_path(path);
- base = of_iomap(node, 0);
- if (WARN_ON(!base))
- return;
- sp804_clocksource_init(base, node-name);
-
- err = of_property_read_string(of_aliases,
- arm,timer-secondary, path);
- if (WARN_ON(err))
- return;
- node = of_find_node_by_path(path);
- base = of_iomap(node, 0);
- if (WARN_ON(!base))
- return;
- irq = irq_of_parse_and_map(node, 0);
- sp804_clockevents_init(base, irq, node-name);
-}
-
static const struct of_device_id fpga_irq_of_match[] __initconst = {
{ .compatible = arm,versatile-fpga-irq, .data = fpga_irq_of_init, },
{ /* Sentinel */ }
@@ -383,7 +352,6 @@ DT_MACHINE_START(INTEGRATOR_CP_DT, ARM Integrator/CP
(Device Tree))
.init_early = intcp_init_early,
.init_irq = intcp_init_irq_of,
.handle_irq = fpga_handle_irq,
- .init_time = cp_of_timer_init,
.init_machine = intcp_init_of,
.restart= integrator_restart,
.dt_compat = intcp_dt_board_compat,
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 10/11] ARM: move sp804 and integrator timers to drivers/clocksource
From: Rob Herring rob.herr...@calxeda.com
Move timer-sp and integrator-ap timer code to drivers/clocksource and
update timer-sp.h and arm_timer.h includes.
This adds CLKSRC_OF support for the integrator-ap timer and removes the
use of arm,timer-primary and arm,timer-secondary aliases. The timer
selection should not be important as all 3 timers are equal capability.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Russell King li...@arm.linux.org.uk
Cc: John Stultz john.stu...@linaro.org
Cc: Thomas Gleixner t...@linutronix.de
---
arch/arm/Kconfig |6 -
arch/arm/common/Makefile |1 -
arch/arm/mach-integrator/Kconfig |1 +
arch/arm/mach-integrator/integrator_ap.c | 169 +
arch/arm/mach-integrator/integrator_cp.c |3 +-
arch/arm/mach-realview/core.c |3 +-
arch/arm/mach-versatile/core.c |2 +-
arch/arm/mach-vexpress/ct-ca9x4.c |4 +-
arch/arm/mach-vexpress/v2m.c |3 +-
drivers/clocksource/Kconfig| 12 ++
drivers/clocksource/Makefile |2 +
.../hardware = drivers/clocksource}/arm_timer.h |6 +-
drivers/clocksource/integrator_ap_timer.c | 190
.../arm/common = drivers/clocksource}/timer-sp.c |9 +-
include/clocksource/integrator_ap_timer.h |7 +
.../hardware = include/clocksource}/timer-sp.h|8 +
16 files changed, 232 insertions(+), 194 deletions(-)
rename {arch/arm/include/asm/hardware = drivers/clocksource}/arm_timer.h (89%)
create mode 100644 drivers/clocksource/integrator_ap_timer.c
rename {arch/arm/common = drivers/clocksource}/timer-sp.c (98%)
create mode 100644 include/clocksource/integrator_ap_timer.h
rename {arch/arm/include/asm/hardware = include/clocksource}/timer-sp.h (84%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 774131a..46970d7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1169,12 +1169,6 @@ config PLAT_PXA
config PLAT_VERSATILE
bool
-config ARM_TIMER_SP804
- bool
- select CLKSRC_MMIO
- select CLKSRC_OF if OF
- select HAVE_SCHED_CLOCK
-
source arch/arm/mm/Kconfig
config ARM_NR_BANKS
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index dc8dd0d..5a4cc1a 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -10,4 +10,3 @@ obj-$(CONFIG_SHARP_LOCOMO)+= locomo.o
obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
-obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index abeff25..c5e4ff3 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -5,6 +5,7 @@ menu Integrator Options
config ARCH_INTEGRATOR_AP
bool Support Integrator/AP and Integrator/PP2 platforms
select CLKSRC_MMIO
+ select INTEGRATOR_AP_TIMER
select MIGHT_HAVE_PCI
select SERIAL_AMBA_PL010
select SERIAL_AMBA_PL010_CONSOLE
diff --git a/arch/arm/mach-integrator/integrator_ap.c
b/arch/arm/mach-integrator/integrator_ap.c
index 4cb322d..6b5f540 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -27,8 +27,6 @@
#include linux/syscore_ops.h
#include linux/amba/bus.h
#include linux/amba/kmi.h
-#include linux/clocksource.h
-#include linux/clockchips.h
#include linux/interrupt.h
#include linux/io.h
#include linux/irqchip/versatile-fpga.h
@@ -41,15 +39,14 @@
#include linux/stat.h
#include linux/sys_soc.h
#include linux/termios.h
+#include clocksource/integrator_ap_timer.h
#include video/vga.h
#include mach/hardware.h
#include mach/platform.h
-#include asm/hardware/arm_timer.h
#include asm/setup.h
#include asm/param.h /* HZ */
#include asm/mach-types.h
-#include asm/sched_clock.h
#include mach/lm.h
#include mach/irqs.h
@@ -58,7 +55,6 @@
#include asm/mach/irq.h
#include asm/mach/map.h
#include asm/mach/pci.h
-#include asm/mach/time.h
#include common.h
@@ -296,174 +292,12 @@ struct amba_pl010_data ap_uart_data = {
#define TIMER1_VA_BASE __io_address(INTEGRATOR_TIMER1_BASE)
#define TIMER2_VA_BASE __io_address(INTEGRATOR_TIMER2_BASE)
-static unsigned long timer_reload;
-
-static u32 notrace integrator_read_sched_clock(void)
-{
- return -readl((void __iomem *) TIMER2_VA_BASE + TIMER_VALUE);
-}
-
-static void integrator_clocksource_init(unsigned long inrate,
- void __iomem *base)
-{
- u32 ctrl = TIMER_CTRL_ENABLE | TIMER_CTRL_PERIODIC;
- unsigned long rate = inrate;
-
- if (rate = 150) {
- rate /= 16;
- ctrl |= TIMER_CTRL_DIV16;
- }
-
- writel(0x, base + TIMER_LOAD
Re: [PATCH V3 12/18] ARM: OMAP2+: Add additional GPMC timing parameters
On 03/15/2013 10:21 AM, Jon Hunter wrote:
Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to read them.
The existing code in gpmc_read_timings_dt() is checking the value of
of_property_read_u32() and only is successful storing the value read
in the gpmc_timings structure. Checking the return value in this case
is not necessary and we can simply read the value, if present, and
store directly in the gpmc_timings structure. Therefore, simplify the
code by removing these checks.
The comment in the gpmc_read_timings_dt() function, only for OMAP3430
is also incorrect as it is applicable to all OMAP3+ devices. So correct
this too.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 25 +-
arch/arm/mach-omap2/gpmc.c| 93
++---
2 files changed, 66 insertions(+), 52 deletions(-)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 6fde1cf..a63bd93 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -56,10 +56,27 @@ Timing properties for child nodes. All are optional and
default to 0.
- gpmc,oe-off: Deassertion time
Access time and cycle time timings corresponding to GPMC_CONFIG5:
- - gpmc,page-burst-access: Multiple access word delay
- - gpmc,access: Start-cycle to first data valid delay
- - gpmc,rd-cycle:Total read cycle time
- - gpmc,wr-cycle:Total write cycle time
+ - gpmc,page-burst-access: Multiple access word delay
+ - gpmc,access: Start-cycle to first data valid delay
+ - gpmc,rd-cycle:Total read cycle time
+ - gpmc,wr-cycle:Total write cycle time
+ - gpmc,bus-turnaround: Turn-around time between successive
accesses
+ - gpmc,cycle2cycle-delay: Delay between chip-select pulses
+ - gpmc,clk-activation: GPMC clock activation time
+ - gpmc,wait-monitoring: Start of wait monitoring with regard to valid
+ data
What units are these in? If in nanoseconds, can you append -ns
+
+Boolean timing parameters. If property is present parameter enabled and
+disabled if omitted:
+ - gpmc,adv-extra-delay: ADV signal is delayed by half GPMC clock
+ - gpmc,cs-extra-delay: CS signal is delayed by half GPMC clock
+ - gpmc,cycle2cycle-diffcsen:Add cycle2cycle-delay between
successive
+ accesses to a different CS
+ - gpmc,cycle2cycle-samecsen:Add cycle2cycle-delay between
successive
+ accesses to the same CS
+ - gpmc,oe-extra-delay: OE signal is delayed by half GPMC clock
+ - gpmc,we-extra-delay: WE signal is delayed by half GPMC clock
+ - gpmc,time-para-granularity: Multiply all access times by 2
The following are only applicable to OMAP3+ and AM335x:
- gpmc,wr-access
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 85b1a35..c928a8c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1274,67 +1274,64 @@ void gpmc_read_settings_dt(struct device_node *np,
struct gpmc_settings *p)
static void __maybe_unused gpmc_read_timings_dt(struct device_node *np,
struct gpmc_timings *gpmc_t)
{
- u32 val;
-
memset(gpmc_t, 0, sizeof(*gpmc_t));
/* minimum clock period for syncronous mode */
- if (!of_property_read_u32(np, gpmc,sync-clk, val))
- gpmc_t-sync_clk = val;
+ of_property_read_u32(np, gpmc,sync-clk, gpmc_t-sync_clk);
/* chip select timtings */
- if (!of_property_read_u32(np, gpmc,cs-on, val))
- gpmc_t-cs_on = val;
-
- if (!of_property_read_u32(np, gpmc,cs-rd-off, val))
- gpmc_t-cs_rd_off = val;
-
- if (!of_property_read_u32(np, gpmc,cs-wr-off, val))
- gpmc_t-cs_wr_off = val;
+ of_property_read_u32(np, gpmc,cs-on, gpmc_t-cs_on);
+ of_property_read_u32(np, gpmc,cs-rd-off, gpmc_t-cs_rd_off);
+ of_property_read_u32(np, gpmc,cs-wr-off, gpmc_t-cs_wr_off);
/* ADV signal timings */
- if (!of_property_read_u32(np, gpmc,adv-on, val))
- gpmc_t-adv_on = val;
-
- if (!of_property_read_u32(np, gpmc,adv-rd-off, val))
- gpmc_t-adv_rd_off = val;
-
- if (!of_property_read_u32(np, gpmc,adv-wr-off, val))
- gpmc_t-adv_wr_off = val;
+ of_property_read_u32(np, gpmc,adv-on, gpmc_t-adv_on);
+ of_property_read_u32(np, gpmc,adv-rd-off, gpmc_t-adv_rd_off);
+ of_property_read_u32(np, gpmc,adv-wr-off, gpmc_t-adv_wr_off);
/* WE signal timings */
- if
Re: [PATCH] ARM: dts: add interrupt-names property to get interrupt resource by name
On 03/13/2013 05:42 PM, Sylwester Nawrocki wrote: Rob, On 03/13/2013 03:39 PM, Rob Herring wrote: I fail to see what the hack is. The order of interrupt properties must be defined by the binding. interrupt-names is auxiliary data and must not be required by an OS. It is clear that the order of the interrupts must be defined by the bindings. But how useful resource-names properties are when we cannot define them as required ? If an OS cannot rely on them then it must use some other, reliable, method to identify the resources, e.g. by hard coding the indexes. If we have to do it then why even bother with the resource-names properties ? I can see interrupt-names property specified as required in at least 2 bindings' documentation and all bindings having reg-names property define it as required. Are they wrong them ? You can require the name for a binding definition, but that does not remove the requirement that the order and index of interrupts also be defined by the binding. Then it is up to the OS to use names or hard-coded indexes. Hard-coded indexes are not a hack. This is how FDT and OF are defined to work. I'm still not clear how changing the order of the interrupts removes a hack. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 6/6] irqchip: s3c24xx: add s3c2450 interrupt definitions
On 03/17/2013 08:09 AM, Heiko Stübner wrote:
The s3c2450 is special in that it shares the cpu identification with the
s3c2416 but provides more interrupts for its additional components.
It also shares the layout of the main interrupt register with the s3c2443
and therefore reuses this definition.
As no non-dt boards are present, the s3c2450 irqs will only be
accessible thru devicetree.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/irqchip/irq-s3c24xx.c | 62 +++-
1 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index 55cb363..7ddf8e8 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -852,6 +852,51 @@ static struct s3c_irq_data init_s3c2416_second[32] = {
{ .type = S3C_IRQTYPE_EDGE }, /* I2S0 */
};
+static struct s3c_irq_data init_s3c2450subint[32] = {
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 28 }, /* UART0-RX */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 28 }, /* UART0-TX */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 28 }, /* UART0-ERR */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 23 }, /* UART1-RX */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 23 }, /* UART1-TX */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 23 }, /* UART1-ERR */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 15 }, /* UART2-RX */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 15 }, /* UART2-TX */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 15 }, /* UART2-ERR */
+ { .type = S3C_IRQTYPE_EDGE, .parent_irq = 31 }, /* TC */
+ { .type = S3C_IRQTYPE_EDGE, .parent_irq = 31 }, /* ADC */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 6 }, /* CAM_C */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 6 }, /* CAM_P */
+ { .type = S3C_IRQTYPE_NONE }, /* reserved */
+ { .type = S3C_IRQTYPE_NONE }, /* reserved */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 16 }, /* LCD2 */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 16 }, /* LCD3 */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 16 }, /* LCD4 */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 17 }, /* DMA0 */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 17 }, /* DMA1 */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 17 }, /* DMA2 */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 17 }, /* DMA3 */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 17 }, /* DMA4 */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 17 }, /* DMA5 */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 18 }, /* UART3-RX */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 18 }, /* UART3-TX */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 18 }, /* UART3-ERR */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 9 }, /* WDT */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 9 }, /* AC97 */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 17 }, /* DMA6 */
+ { .type = S3C_IRQTYPE_LEVEL, .parent_irq = 17 }, /* DMA7 */
This all seems like information that should come from DT.
+};
+
+static struct s3c_irq_data init_s3c2450second[32] = {
+ { .type = S3C_IRQTYPE_EDGE }, /* 2D */
+ { .type = S3C_IRQTYPE_EDGE }, /* IIC1 */
+ { .type = S3C_IRQTYPE_NONE }, /* reserved */
+ { .type = S3C_IRQTYPE_NONE }, /* reserved */
+ { .type = S3C_IRQTYPE_EDGE }, /* PCM0 */
+ { .type = S3C_IRQTYPE_EDGE }, /* PCM1 */
+ { .type = S3C_IRQTYPE_EDGE }, /* I2S0 */
+ { .type = S3C_IRQTYPE_EDGE }, /* I2S1 */
+};
+
void __init s3c2416_init_irq(void)
{
struct s3c_irq_intc *main_intc;
@@ -1024,7 +1069,7 @@ void __init s3c2442_init_irq(void)
}
#endif
-#ifdef CONFIG_CPU_S3C2443
+#if defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
static struct s3c_irq_data init_s3c2443base[32] = {
{ .type = S3C_IRQTYPE_EINT, }, /* EINT0 */
{ .type = S3C_IRQTYPE_EINT, }, /* EINT1 */
@@ -1059,8 +1104,9 @@ static struct s3c_irq_data init_s3c2443base[32] = {
{ .type = S3C_IRQTYPE_EDGE, }, /* RTC */
{ .type = S3C_IRQTYPE_LEVEL, }, /* ADCPARENT */
};
+#endif
-
+#ifdef CONFIG_CPU_S3C2443
static struct s3c_irq_data init_s3c2443subint[32] = {
{ .type = S3C_IRQTYPE_LEVEL, .parent_irq = 28 }, /* UART0-RX */
{ .type = S3C_IRQTYPE_LEVEL, .parent_irq = 28 }, /* UART0-TX */
@@ -1172,6 +1218,17 @@ struct s3c24xx_irq_of_data s3c2416_irq_data = {
.irq_ctrl = s3c2416_ctrl,
.num_ctrl = ARRAY_SIZE(s3c2416_ctrl),
};
+
+static struct s3c24xx_irq_of_ctrl s3c2450_ctrl[] = {
+ S3C24XX_IRQCTRL(intc, 0, init_s3c2443base, main_intc, NULL),
+ S3C24XX_IRQCTRL(subintc, 0x18, init_s3c2450subint, NULL, main_intc),
+ S3C24XX_IRQCTRL(intc2, 0x40, init_s3c2450second, main_intc2, NULL),
+};
+
+static struct s3c24xx_irq_of_data s3c2450_irq_data = {
+ .irq_ctrl = s3c2450_ctrl,
+ .num_ctrl = ARRAY_SIZE(s3c2450_ctrl),
+};
#endif
#ifdef
Re: [PATCH v3 5/6] irqchip: s3c24xx: add devicetree support
On 03/17/2013 08:07 AM, Heiko Stübner wrote:
Add the necessary code to initialize the interrupt controller
thru devicetree data using the irqchip infrastructure.
On dt machines the eint-type interrupts in the main interrupt controller
get mapped as regular edge-types, as their wakeup and interrupt type
properties will be handled by the upcoming pinctrl driver.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
.../interrupt-controller/samsung,s3c24xx-irq.txt | 54 +
drivers/irqchip/irq-s3c24xx.c | 222
2 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
new file mode 100644
index 000..be5dead
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
@@ -0,0 +1,54 @@
+Samsung S3C24XX Interrupt Controllers
+
+The S3C24XX SoCs contain a custom set of interrupt controllers providing a
+varying number of interrupt sources. The set consists of a main- and sub-
+controller and on newer SoCs even a second main controller.
+
+Required properties:
+- compatible: Compatible property value should be one of
samsung,s3c2410-irq,
+ samsung,s3c2412-irq, samsung,s3c2416-irq, samsung,s3c2440-irq,
+ samsung,s3c2442-irq, samsung,s3c2443-irq depending on the SoC variant.
+
+- reg: Physical base address of the controller and length of memory mapped
+ region.
+
+- interrupt-controller : Identifies the node as an interrupt controller
+
+Sub-controllers as child nodes:
+ The interrupt controllers that should be referenced by device nodes are
+ represented by child nodes. Valid names are intc, subintc and intc2.
+ The interrupt values in device nodes are then mapped directly to the
+ bit-numbers of the pending register of the named interrupt controller.
+
+Required properties:
+- interrupt-controller : Identifies the node as an interrupt controller
+
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value shall be 2.
+
+Example:
+
+ interrupt-controller@4a00 {
+ compatible = samsung,s3c2416-irq;
+ reg = 0x4a00 0x100;
+ interrupt-controller;
+
+ intc:intc {
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ subintc:subintc {
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+ };
+
+ [...]
+
+ serial@5000 {
+ compatible = samsung,s3c2410-uart;
+ reg = 0x5000 0x4000;
+ interrupt-parent = subintc;
+ interrupts = 0 0, 1 0;
+ };
diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index 1eba289..55cb363 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -25,6 +25,9 @@
#include linux/ioport.h
#include linux/device.h
#include linux/irqdomain.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/of_address.h
#include asm/exception.h
#include asm/mach/irq.h
@@ -36,6 +39,8 @@
#include plat/regs-irqtype.h
#include plat/pm.h
+#include irqchip.h
+
#define S3C_IRQTYPE_NONE 0
#define S3C_IRQTYPE_EINT 1
#define S3C_IRQTYPE_EDGE 2
@@ -380,6 +385,10 @@ static int s3c24xx_irq_map(struct irq_domain *h,
unsigned int virq,
parent_intc = intc-parent;
+ /* on dt platforms the extints get handled by the pinctrl driver */
+ if (h-of_node irq_data-type == S3C_IRQTYPE_EINT)
+ irq_data-type = S3C_IRQTYPE_EDGE;
+
/* set handler and flags */
switch (irq_data-type) {
case S3C_IRQTYPE_NONE:
@@ -1104,3 +1113,216 @@ void __init s3c2443_init_irq(void)
s3c24xx_init_intc(NULL, init_s3c2443subint[0], main_intc, 0x4a18);
}
#endif
+
+#ifdef CONFIG_OF
+struct s3c24xx_irq_of_ctrl {
+ char*name;
+ unsigned long offset;
+ struct s3c_irq_data *irq_data;
+ struct s3c_irq_intc **handle;
+ struct s3c_irq_intc **parent;
+};
+
+#define S3C24XX_IRQCTRL(n, o, d, h, p) \
+{\
+ .name = n,\
+ .offset = o,\
+ .irq_data = d,\
+ .handle = h,\
+ .parent = p,\
+}
+
+struct s3c24xx_irq_of_data {
+ struct s3c24xx_irq_of_ctrl *irq_ctrl;
+ int num_ctrl;
+};
+
+#ifdef CONFIG_CPU_S3C2410
+static struct
