Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Hi Samuel, On Wed, Jul 17, 2013 at 10:07:00PM +0100, Samuel Ortiz wrote: Hi Lorenzo, On Tue, Jul 16, 2013 at 05:05:42PM +0100, Lorenzo Pieralisi wrote: Hello, version v5 of VExpress SPC driver, please read on the changelog for major changes and explanations. The probing scheme is unchanged, since after trying the early platform devices approach it appeared that the end result was no better than the current one. The only clean solution relies either on changing how secondaries are brought up in the kernel (later than now) or enable early platform device registration through DT. Please check this thread for the related discussion: https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html The interface was adapted to regmap and again reverted to old driver for the following reasons: - Power down registers locking is hairy and requires arch spinlocks in the MCPM back end to work properly, normal spinlocks cannot be used - Regmap adds unnecessary code to manage SPC since it is just a bunch of registers used to control power management flags, the overhead is just not worth it (talking about power down registers, not the vexpress config interface) - The locking scheme behind regmap requires all registers in the map to be protected with the same lock, which is not exactly what we want here - Given the reasons above, adding a regmap interface buys us nothing from a driver readability and maintainability perspective (again just talking about the power interface, a few registers) because for the SPC it would simply not be used /drivers/mfd is probably not the right place for this code as it stands (but probably will be when the entire driver, with DVFS and config interface, is complete). Could you please elaborate on how will the SPC driver extend into an MFD driver? Reading through the thread I noticed Nico explained details properly, I was about to mention a possible solution to the directory issue but I am pretty sure that what he did will turn out for the best. Usually, or better, historically, these pieces of code that program PMICs lived in arch/arm/mach-* directories and that's something we could have done as well (create a static mapping and write some functions to peek and poke a few registers), but we thought that it was not the proper way to go. On top of that, the SPC is part of a component whose register space maps disparate functions (config interface for voltage, clocks, energy probes, frequency scaling and power states management) and basically that's the reason we struggled to partition it properly (with further complexity implied by the way requests - config and frequency scaling - have to be serialized). I hope the end result is reasonable, and overall I think it was a debate that was worth having. Thank you, Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, Jul 17, 2013 at 10:18:25AM +0100, Pawel Moll wrote: On Tue, 2013-07-16 at 17:05 +0100, Lorenzo Pieralisi wrote: /drivers/mfd is probably not the right place for this code as it stands (but probably will be when the entire driver, with DVFS and config interface, is complete). Not that it really matters now, but my vexpress-sysreg rework will - most likely - leave only skeleton in the MFD (registering mfd_cells) and other stuff is going to be spread all around. Then I'm planning to move the remaining of the vexpress-specific initialization to drivers/platform/arm/vexpress.c, so maybe sticking vexpress-spc.c to this (non-existing yet) directory would be the right thing to do? Done. I do not think there is a point in splitting the patch to create the dir and make infrastructure, so I squashed everything in the original patch. I have not added any maintainer for that dir/file, I guess it can wait till you finish the rework so that you can add yourself there. If that's all I need to change I do not even think that reposting is necessary. It does matter though, since it implies changes on who is in charge of ack/nack'ing this code, if it is no more an mfd matter. I will wait to check all interested/concerned parties opinions, that are always welcome. Other than that: Acked-by: Pawel Moll pawel.m...@arm.com Thank you !!! Lorenzo ___ 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 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. 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. 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. Good, that's all I wanted to know, thanks. 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. I will give it more thought, point taken. + + - 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
[RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Hello, version v5 of VExpress SPC driver, please read on the changelog for major changes and explanations. The probing scheme is unchanged, since after trying the early platform devices approach it appeared that the end result was no better than the current one. The only clean solution relies either on changing how secondaries are brought up in the kernel (later than now) or enable early platform device registration through DT. Please check this thread for the related discussion: https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html The interface was adapted to regmap and again reverted to old driver for the following reasons: - Power down registers locking is hairy and requires arch spinlocks in the MCPM back end to work properly, normal spinlocks cannot be used - Regmap adds unnecessary code to manage SPC since it is just a bunch of registers used to control power management flags, the overhead is just not worth it (talking about power down registers, not the vexpress config interface) - The locking scheme behind regmap requires all registers in the map to be protected with the same lock, which is not exactly what we want here - Given the reasons above, adding a regmap interface buys us nothing from a driver readability and maintainability perspective (again just talking about the power interface, a few registers) because for the SPC it would simply not be used /drivers/mfd is probably not the right place for this code as it stands (but probably will be when the entire driver, with DVFS and config interface, is complete). Thank you for the review in advance, Lorenzo This patch is v5 of a previous posting: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/177150.html v5 changes: - Completely removed vexpress-config interface waiting for refactoring based on regmap - Removed frequency scaling interface and operating points programming retrieval - Trimmed the driver code and DT bindings v4 changes: - Applied review comments (trimmed function names, added comments, refactored some APIs) - Added comments throughout the set - Fixed irq handler bug in checking the transaction status - Improved commit log to explain early init synchro scheme - Created a single static structure for variables dynamically allocated to remove usage of static - Improved Kconfig entry v3 changes: - added __refdata to spc_check_loaded pointer - removed some exported symbols - added node pointer check in vexpress_spc_init() v2 changes: - Dropped timeout interface patch - Converted interfaces to non-timeout ones, integrated and retested - Removed mutex used at init - Refactored code to work around init sections warning - Fixed two minor bugs Lorenzo Pieralisi (1): drivers: mfd: vexpress: add Serial Power Controller (SPC) support 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(+) create mode 100644 Documentation/devicetree/bindings/mfd/vexpress-spc.txt create mode 100644 drivers/mfd/vexpress-spc.c -- 1.8.2.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
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.
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) += retu-mfd.o
obj-$(CONFIG_MFD_AS3711) += as3711.o
diff --git a/drivers/mfd/vexpress-spc.c b/drivers/mfd/vexpress-spc.c
new file mode 100644
index 000..aa8c2a4
--- /dev/null
+++ b/drivers
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
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. 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. + + * 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. Fair enough I will see how I can reword it. + + 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
Re: [PATCH 0/2] ARM: sunxi: Convert DTSI to new CPU bindings
On Sun, Jun 30, 2013 at 10:48:46AM +0100, Lorenzo Pieralisi wrote: On Sat, Jun 29, 2013 at 08:38:19PM +0100, Russell King - ARM Linux wrote: On Fri, Jun 28, 2013 at 01:05:42PM -0700, Olof Johansson wrote: On Fri, Jun 28, 2013 at 1:03 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Fri, Jun 28, 2013 at 06:15:32PM +0100, Lorenzo Pieralisi wrote: The patch above should already be queued in next/dt right ? Indeed. Then why the latest patch of your patchset got in 3.10, while the patches actually fixing the DT it would have impacted were delayed to 3.11? (And why was it merged so late in the development cycle?) This. So now we have to scramble because some device trees will produce warnings at boot. Russell, the alternative is to revert Lorenzo's patch for 3.10 (and re-introduce it for 3.11). Do you have a preference? Sorry but I really don't understand what all the fuss in this thread is about. This thread seems to be saying that two development patches were merged, which were 7762/1 and 7763/1, and that 7764/1 is a fix? Are you sure about that, because that's not how they're described, and not how they look either. As Olof's warning downgrade is being merged (thanks for that and apologies for failing to explain patches dependencies properly and stable related issues), 7764/1 won't apply cleanly anymore. Can you please drop it from the patch system, I will update it and test it first thing tomorrow and send a final version to the patch system. Patch 7779/1, replacing 7764/1 is in the patch system now, and is ready to get merged. Unfortunately cpu/cpus bindings documentation updates, following: https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036735.html https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-May/033779.html were not pulled in the kernel. This is an issue since this means that we still have no reference in the kernel or wherever it has to be, to the final cpus/cpu bindings for ARM and ARM64 provided in the pull request link above (that has been reviewed to death and acknowledged). It is a significant overhaul of cpu/cpus bindings standard for ARM/ARM64, covering all CPUs harking back to arm926 and beyond, and should be final. dts updates following that standard have already been pulled into 3.11 through arm-soc. IMHO the bindings contained in pull request above must be merged in the kernel asap, I would like to ask you please what should I do to get them in please. If we want to move bindings documentation elsewhere let's do it, as long as there is a published standard I am happy and will stop annoying you with this stuff. Thank you very much, Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC] early init and DT platform devices allocation/registration
Hi Magnus,
thank you.
On Wed, Jun 26, 2013 at 07:20:32AM +0100, Magnus Damm wrote:
Hi Lorenzo,
On Wed, Jun 26, 2013 at 2:07 AM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
On Tue, Jun 25, 2013 at 03:56:22PM +0100, Stephen Warren wrote:
On 06/25/2013 05:45 AM, Grant Likely wrote:
On Mon, Jun 24, 2013 at 5:33 PM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
Hi all,
I am dealing with a lingering problem related to init and probing of
platform
devices early (before initcalls) in the kernel boot process. The
problem,
which is nothing new, is related to how platform devices are created in
the
kernel from DT and when they become available. Platform devices are
created
through (assuming any legacy static initialization is removed from the
kernel)
of_platform_populate()
at arch_initcall time on ARM. This is a problem for drivers that need
to be
probed and initialized before arch_initcall (ie early_initcall) because
the corresponding platform_device has not been created yet.
What's the use-case here; why does the driver /have/ to be
allocated/probed so early? Can't drivers all be allocated from DT in the
usual fashion, and any dependencies resolved using deferred probe? In
almost all cases, that should work.
The driver must be initialized in order to boot secondary CPUs, so
very very early, its initialization cannot be deferred.
Otherwise we would end up with MCPM back-end having to add ad-hoc
kludges to boot secondary CPUs, and then replace the early function calls
to the power controller drivers when the power controller has been
properly initialized. Feasible, but really horrible.
How about moving part of the SMP initialization to later during boot?
In particular I mean the bring up of the secondary cores. Just booting
with a single CPU for a bit longer is certainly doable because it is
today possible to bring secondary CPU cores up from user space via the
hotplug interface. Below is some old prototype code that I hacked up a
while ago - note that I copied the original comment about that this
should be done in user space. =)
Well, the question is probably why smp_init() is called before
do_basic_setup()
as the kernel does now. We need to check if there is something we are
missing or not, and I guess the only way to do it is to post your patch
to LKML.
I'd like to have secondary CPU cores initialized later so I can use
the regular device model (DT or platform device) to describe one or
more power domain hardware devices. These power domains control the
CPU cores, so there is a dependency on the SMP bring up code...
Looks like we are on the same boat then :-). This way we will solve
this particular issue(s), but still can not rely on DT to initialize early
platform devices.
This stuff requires some serious thought, that's for certain, I will try
to allocate some time to have a thorough look into this.
--- 0001/include/linux/smp.h
+++ work/include/linux/smp.h2013-05-21 20:08:42.0 +0900
@@ -124,6 +124,7 @@ void smp_prepare_boot_cpu(void);
extern unsigned int setup_max_cpus;
extern void __init setup_nr_cpu_ids(void);
extern void __init smp_init(void);
+extern void __init smp_late_init(void);
#else /* !SMP */
--- 0001/init/main.c
+++ work/init/main.c2013-05-21 20:09:34.0 +0900
@@ -334,6 +334,7 @@ static void __init smp_init(void)
static inline void setup_nr_cpu_ids(void) { }
static inline void smp_prepare_cpus(unsigned int maxcpus) { }
+static inline void smp_late_init(void) { }
#endif
/*
@@ -879,6 +880,8 @@ static noinline void __init kernel_init_
do_basic_setup();
+ smp_late_init();
+
/* Open the /dev/console on the rootfs, this should never fail */
if (sys_open((const char __user *) /dev/console, O_RDWR, 0) 0)
pr_err(Warning: unable to open an initial console.\n);
--- 0001/kernel/smp.c
+++ work/kernel/smp.c 2013-05-21 20:07:06.0 +0900
@@ -549,6 +549,20 @@ void __init smp_init(void)
if (!cpu_online(cpu))
cpu_up(cpu);
}
+}
+
+/* Called by boot processor late during boot to activate the rest. */
+void __init smp_late_init(void)
+{
+ unsigned int cpu;
+
+ /* FIXME: This should be done in userspace --RR */
+ for_each_present_cpu(cpu) {
+ if (num_online_cpus() = setup_max_cpus)
+ break;
+ if (!cpu_online(cpu))
+ cpu_up(cpu);
+ }
/* Any cleanup work */
printk(KERN_INFO Brought up %ld CPUs\n, (long)num_online_cpus());
You probably need to remove the same code from smp_init() then ? If you
feel like posting this patch as an RFC (even if it just were to draw
attention to the problem) please go ahead. I still think this is a work
around to make things work, and we are still not solving
Re: [GIT PULL] ARM DT cpus/cpu bindings documentation updates
Hi Grant, Rob, On Thu, May 23, 2013 at 11:33:15AM +0100, Lorenzo Pieralisi wrote: Hi Grant, Rob, please pull the cpus/cpu nodes bindings updates for ARM. This pull request completes my previous pull request: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/169110.html Please let me know if you have any objection to these two pull requests (the one I am replying to and the one provided in the link above). I sent them quite early so I am just reminding you lest you missed them. These bindings are quite important and without them all in-kernel dts files, cpu map parsing code and topology updates are meaningless, I really hope you can queue them for this upcoming merge window. They are based against early kernel versions (3.10-rc1 and 3.10-rc2), but they fast-forward cleanly to -rc7, please let me know if you want me to send pull requests with branches updated to -rc7, I do not think it is necessary. Thank you very much indeed, Lorenzo with the required changes for cpus/cpu nodes. Thanks a lot, Lorenzo The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75: Linux 3.10-rc2 (2013-05-20 14:37:38 -0700) are available in the git repository at: git://linux-arm.org/linux-2.6-lp.git dt-cpus-bindings for you to fetch changes up to 8e11f862d6a5491bb5f8ef73e13cfd66562e7be3: Documentation: devicetree: arm: cpus/cpu nodes bindings updates (2013-05-23 10:46:46 +0100) Lorenzo Pieralisi (1): Documentation: devicetree: arm: cpus/cpu nodes bindings updates Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) ___ 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] early init and DT platform devices allocation/registration
Hi Grant, thanks for commenting. On Tue, Jun 25, 2013 at 12:45:25PM +0100, Grant Likely wrote: On Mon, Jun 24, 2013 at 5:33 PM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: Hi all, I am dealing with a lingering problem related to init and probing of platform devices early (before initcalls) in the kernel boot process. The problem, which is nothing new, is related to how platform devices are created in the kernel from DT and when they become available. Platform devices are created through (assuming any legacy static initialization is removed from the kernel) of_platform_populate() at arch_initcall time on ARM. This is a problem for drivers that need to be probed and initialized before arch_initcall (ie early_initcall) because the corresponding platform_device has not been created yet. To work around this awkward situation, a driver, instead of relying on platform driver probing mechanism, can get initialized using early_initcall mechanism and rely on DT helpers (ie of_iomap() and company) to initialize resources. The problem comes when the driver functions must rely on an API (eg regmap) that requires a struct device to function properly; since the platform_device has not been created yet at early_initcall time, the driver cannot rely on it. The only solution consists in allocating a platform_device on the fly at driver init through of_platform_device_create() and use that device to initialize the (eg regmap) API. There is an issue with this solution, basically a platform device is allocated twice for a given device node - compatible property (because of_platform_populate() allocates a platform device for a node containing a compatible string even if a platform device has already been allocated for that device node). The second solution relies on early platform devices. Early platform devices are added by mach code and driver probing is carried out using the early platform device probing mechanism early_platform_driver_probe() The drawback with this solution is, AFAIK, it does not play well with DT, since the platform device duplication issue is still there (ie of_platform_populate() will allocate a platform device which is a duplicate of the one allocated at early boot to make the early platform device initialization possible). Please correct me if I am wrong, just trying to untangle a problem that does not look easy to solve. How this problem is supposed to be solved in the kernel ? 1- drivers that are to be up and running at early_initcall time must not rely on the device/driver model (but then they cannot use any API that requires a struct device to function (eg regmap)) 2- the driver should allocate a platform device at early initcall from a DT compatible node. Do not know how to deal with platform device duplication though, since of_platform_populate() will create another platform device when the node is parsed While I've resisted it in the past, I would be okay with adding struct device pointer in the device_node structure. I've resisted because I don't want drivers following the device_node pointer and making an assumption about what /kind/ of device is pointed to by it. However, this is an important use case and it makes it feasible to use an early platform device with of_platform_populate. Alternately, if others chime in and think it is too risky to have the device pointer in the device node, we could simply add a flag to the device_node which indicates the node has been parsed by of_platform_populate. There would need to be some careful coding to make sure that any call to early platform device creation sets the pointer in the device node correctly. I would also make it a requirement that any early platform device *must* be converted into a 'real' platform device during initcall time. That includes being possible to be freed correctly. Static early platform device definitions should not be allowed, otherwise there needs to be a special case for the platform device release hook. I really don't want that. Something else that needs to be investigated is how the device hierarchy will be affected by using early_platform_device. We still want the platform_device to appear in the same place in the hierarchy regardless of whether or not it was created 'early'. the question is how to make sure that actually happens. While acknowledging the complexity of adding this code, I tend to prefer a solution that allows allocation of early platform devices from DT instead of adding a flag to avoid duplicates, it is cleaner (but more complex as you mentioned) that's the point I wanted to make, otherwise we end up adding all kinds of kludges to the kernel to make early init work. The question is: should we live with workarounds that allow early allocation of devices or should we fix the kernel to cope with these use cases ? I do not know
Re: [RFC] early init and DT platform devices allocation/registration
On Tue, Jun 25, 2013 at 03:56:22PM +0100, Stephen Warren wrote: On 06/25/2013 05:45 AM, Grant Likely wrote: On Mon, Jun 24, 2013 at 5:33 PM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: Hi all, I am dealing with a lingering problem related to init and probing of platform devices early (before initcalls) in the kernel boot process. The problem, which is nothing new, is related to how platform devices are created in the kernel from DT and when they become available. Platform devices are created through (assuming any legacy static initialization is removed from the kernel) of_platform_populate() at arch_initcall time on ARM. This is a problem for drivers that need to be probed and initialized before arch_initcall (ie early_initcall) because the corresponding platform_device has not been created yet. What's the use-case here; why does the driver /have/ to be allocated/probed so early? Can't drivers all be allocated from DT in the usual fashion, and any dependencies resolved using deferred probe? In almost all cases, that should work. The driver must be initialized in order to boot secondary CPUs, so very very early, its initialization cannot be deferred. Otherwise we would end up with MCPM back-end having to add ad-hoc kludges to boot secondary CPUs, and then replace the early function calls to the power controller drivers when the power controller has been properly initialized. Feasible, but really horrible. On top of that, the HW component is an IP that provides functionality beyond power management, so we really want it to be initialized and running after boot, we cannot just hide a couple of function calls in the MCPM back-end to boot the CPUs and forget about that IP afterwards. ... How this problem is supposed to be solved in the kernel ? 1- drivers that are to be up and running at early_initcall time must not rely on the device/driver model (but then they cannot use any API that requires a struct device to function (eg regmap)) 2- the driver should allocate a platform device at early initcall from a DT compatible node. Do not know how to deal with platform device duplication though, since of_platform_populate() will create another platform device when the node is parsed While I've resisted it in the past, I would be okay with adding struct device pointer in the device_node structure. I've resisted because I don't want drivers following the device_node pointer and making an assumption about what /kind/ of device is pointed to by it. However, this is an important use case and it makes it feasible to use an early platform device with of_platform_populate. Hiroshi (who I have CC'd here) has also been asking about this same issue downstream. The issue for us is that we need to initialize an SMMU driver before any devices that are translated by the SMMU. One option is to force the register/probe of the SMMU driver explicitly, early in the machine's .init_machine() callback, before of_platform_populate(), to ensure the ordering. Then, we run into the same duplicate device issue, and the change Grant mentions above would help solve this. Good to hear we are not alone. I still do not know if we are dealing with specific use cases or this is a problem that should be solved generically at kernel level. I think it is best to solve it once for all, otherwise we will all come up with workarounds to make things work, possibly violating the driver/device model usage guidelines. Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC] early init and DT platform devices allocation/registration
Hi all, I am dealing with a lingering problem related to init and probing of platform devices early (before initcalls) in the kernel boot process. The problem, which is nothing new, is related to how platform devices are created in the kernel from DT and when they become available. Platform devices are created through (assuming any legacy static initialization is removed from the kernel) of_platform_populate() at arch_initcall time on ARM. This is a problem for drivers that need to be probed and initialized before arch_initcall (ie early_initcall) because the corresponding platform_device has not been created yet. To work around this awkward situation, a driver, instead of relying on platform driver probing mechanism, can get initialized using early_initcall mechanism and rely on DT helpers (ie of_iomap() and company) to initialize resources. The problem comes when the driver functions must rely on an API (eg regmap) that requires a struct device to function properly; since the platform_device has not been created yet at early_initcall time, the driver cannot rely on it. The only solution consists in allocating a platform_device on the fly at driver init through of_platform_device_create() and use that device to initialize the (eg regmap) API. There is an issue with this solution, basically a platform device is allocated twice for a given device node - compatible property (because of_platform_populate() allocates a platform device for a node containing a compatible string even if a platform device has already been allocated for that device node). The second solution relies on early platform devices. Early platform devices are added by mach code and driver probing is carried out using the early platform device probing mechanism early_platform_driver_probe() The drawback with this solution is, AFAIK, it does not play well with DT, since the platform device duplication issue is still there (ie of_platform_populate() will allocate a platform device which is a duplicate of the one allocated at early boot to make the early platform device initialization possible). Please correct me if I am wrong, just trying to untangle a problem that does not look easy to solve. How this problem is supposed to be solved in the kernel ? 1- drivers that are to be up and running at early_initcall time must not rely on the device/driver model (but then they cannot use any API that requires a struct device to function (eg regmap)) 2- the driver should allocate a platform device at early initcall from a DT compatible node. Do not know how to deal with platform device duplication though, since of_platform_populate() will create another platform device when the node is parsed 3- driver should rely on early platform device/driver, but this does not solve (?) the platform device duplication problem either, it will happen when of_platform_populate() parses the DT and creates devices on the fly In theory there are other solutions such as: (a) declaring the platform device statically in arm/mach-* code and do not define the device node in dts, basically going back in time to ARM legacy kernel mechanism for this kind of devices (b) add a way to of_platform_populate() to exclude some compatible strings from being matched Honestly there is not a solution I can say I like and maybe I am trying to solve a problem that has already been solved, apologies if so, that's why I am asking on the list to people with more knowledge than me on the subject. Comments are really really welcome, thank you ! Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/6] ARM: dts: imx27 cpufreq-cpu0 frequencies
On Fri, Jun 21, 2013 at 06:23:46AM +0100, Shawn Guo wrote:
On Fri, Jun 21, 2013 at 08:54:53AM +0400, Alexander Shiyan wrote:
On Thu, Jun 20, 2013 at 04:50:14PM +0200, Markus Pargmann wrote:
+ cpus {
+ #size-cells = 0;
+ #address-cells = 1;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = fsl,imx27, arm,arm926ejs;
From what Documentation/devicetree/bindings/arm/cpus.txt tells, it
should be arm,arm926. Also, why do you put fsl,imx27 there?
imx27 is a SoC name not cpu core.
I think Markus take this ARM property from one of existing DTS.
shc@shc /home/git/linux-mx27/arch/arm/boot/dts $ grep arm926 *.dtsi
at91sam9260.dtsi: compatible = arm,arm926ejs;
at91sam9263.dtsi: compatible = arm,arm926ejs;
at91sam9g45.dtsi: compatible = arm,arm926ejs;
at91sam9n12.dtsi: compatible = arm,arm926ejs;
at91sam9x5.dtsi:compatible = arm,arm926ejs;
imx23.dtsi: compatible = arm,arm926ejs;
imx28.dtsi: compatible = arm,arm926ejs;
lpc32xx.dtsi: compatible = arm,arm926ejs;
s3c2416.dtsi: compatible = arm,arm926ejs;
spear3xx.dtsi: compatible = arm,arm926ejs;
spear600.dtsi: compatible = arm,arm926ejs;
wm8505.dtsi:compatible = arm,arm926ejs;
So, documentation need to be updated or these values should be fixed.
Another solution is specify compatible string as:
compatible = arm,arm926ejs, arm,arm926;
What you think about this?
I assume that the compatible string in the binding doc has been reviewed
and agreed by people, so we should fix the existing users before kernel
starts using it to for matching something.
Lorenzo, comment?
I patched them all and changes are queued through arm-soc, according to the
latest bindings that should get merged this cycle and are available here:
git://linux-arm.org/linux-2.6-lp.git dt-cpus-bindings
If you are queuing dts updates please follow rules in there, waiting for
that document to get merged.
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: kernel: document ARM CPUs clock-frequency property
On Wed, Jun 19, 2013 at 11:27:50AM +0100, Florian Fainelli wrote: Hello Mark, 2013/6/19 Mark Rutland mark.rutl...@arm.com: On Wed, Jun 19, 2013 at 10:47:17AM +0100, Florian Fainelli wrote: ARM CPU device tree nodes may contain an optional clock-frequency property, when set, this property must contain the CPU frequency in Hz, which is then used by the topology parsing code in arch/arm/kernel/topology.c to infer the CPU capacity. I see that arch/arm/kernel/topology.c does a pr_err when clock-frequency isn't present. If we're documenting it as optional, should we not downgrade that or remove it entirely? Good question. I think it might be good to just dowgrade the error to a simple warning, we should clearly be fixing the binding if we have a device_type = cpu property but no clock-frequency property. Well, this means that that pr_err will trigger as soon as the dts updates hit the mainline, now probably it is silent because cpu nodes for architectures with arm,cortex-a15 as cpus miss device_type = cpu. ePAPR defines clock-frequency as required. So either we downgrade it to optional or we are in for another slew of dts updates, I am really looking forward to that. Certainly it has to be added to the bindings. Thoughts ? Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
Hi Olof,
thanks a lot.
On Mon, Jun 17, 2013 at 06:44:51PM +0100, Olof Johansson wrote:
On Mon, Jun 17, 2013 at 04:51:09PM +0100, 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, operating points and reset control.
This patch provides a driver that enables run-time control of features
implemented by the SPC 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.
Since the SPC logic is also used to control clocks and operating points,
that have to be initialized early as well, the SPC interface consumers can
not
rely on early initcalls ordering, which is inconsistent, to wait for SPC
initialization. Hence, in order to keep the components relying on the SPC
coded in a sane way, the driver puts in place a synchronization scheme that
allows kernel drivers to check if the SPC driver has been initialized and if
not, to initialize it upon check.
A status variable is kept in memory so that loadable modules that require
SPC
interface (eg CPUfreq drivers) can still check the correct initialization
and
use the driver correctly after functions used at boot to init the driver are
freed.
The driver also provides a bridge interface through the vexpress config
infrastructure. Operations allowing to read/write operating points are
made to go via the same interface as configuration transactions so that
all requests to M3 are serialized.
Device tree bindings documentation for the SPC component is provided with
the patchset.
Sorry, I got to think of this over the weekend and should have replied
before you had a chance to repost, but still:
Why is the operating point and frequency change code in this driver at all?
Usually, the MFD driver contains a shared method to access register space on
a multifunction device, but the actual operation of each subdevice is handled
by individual drivers in the regular locations.
So, in the case of operating points and requencies, that should be in
a cpufreq driver. And the clock setup should presumably be in a clk
framework driver if needed.
Well, yes this can be done. I will probably move this code out of mfd
since this choice caused more issues than the current driver solves.
By moving the frequency changes into subsystems, we are certainly
trimming down the code, not sure we improve the maintainability though,
keep in mind that we already had to change the vexpress-config interface
to cope with SPC oddities, at least now these intricacies are self-contained.
What you are suggesting makes sense though, I will do it.
Then all that would be left here is the functionality for submitting the two
kinds of commands, and handling interrupts.
Not really. There are still a bunch of registers to set-up wake-up IRQs,
power down flags and warm-boot jump addresses that do not go through the
vexpress interface, they are ad-hoc. I could also split that stuff, but I
really do not think it is worth the effort.
That'll trim down the driver to a point where I think you'll find it much
easier to get merged. :-)
To start with I have to understand in which directory this code should
live. Moving the frequency settings in clk/CPUfreq drivers should be
feasible with extra DT complexity for their bindings.
[...]
+struct ve_spc_drvdata {
+ void __iomem *baseaddr;
+ /* A15 processor MPIDR[15:8] bitfield */
A comment describing what the meaning is would be more useful, even if
less technically specific. Or maybe something like Cluster ID of the
A15 cluster, from MPIDR[15:8] or similar.
+ u32 a15_clusid;
(I reserve the right to have more comments later but I think we want to
discuss
the removal of frequency management code first. :-)
I will do that and comments are always welcome.
Thanks,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
On Tue, Jun 18, 2013 at 05:25:22AM +0100, Nicolas Pitre wrote:
On Mon, 17 Jun 2013, 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, operating points and reset control.
[...]
I slightly modified the following before committing this patch to my TC2
branch:
+/**
+ * ve_spc_cpu_wakeup_irq()
+ *
+ * Function to set/clear per-CPU wake-up IRQs. Not protected by locking
since
+ * it might be used in code paths where normal cacheable locks are not
+ * working. Locking must be provided by the caller to ensure atomicity.
+ *
+ * @cpu: mpidr[7:0] bitfield describing cpu affinity level
+ * @cluster: mpidr[15:8] bitfield describing cluster affinity level
+ * @set: if true, wake-up IRQs are set, if false they are cleared
+ */
+void ve_spc_cpu_wakeup_irq(u32 cpu, u32 cluster, bool set)
+{
I made cluster first then cpu. All the other functions have the cluster
argument first, and ve_spc_set_resume_addr() already uses that order.
Ok thanks.
[...]
+#ifdef CONFIG_VEXPRESS_SPC
+int ve_spc_probe(void);
+int ve_spc_get_freq(u32 cluster);
+int ve_spc_set_freq(u32 cluster, u32 freq);
+int ve_spc_get_freq_table(u32 cluster, const u32 **fptr);
+void ve_spc_global_wakeup_irq(bool set);
+void ve_spc_cpu_wakeup_irq(u32 cpu, u32 cluster, bool set);
+void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr);
+u32 ve_spc_get_nr_cpus(u32 cluster);
+void ve_spc_powerdown(u32 cluster, bool enable);
+#else
+static inline bool ve_spc_probe(void) { return -ENODEV; }
s/bool/int/
Bah, sorry.
Thanks a lot,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 1/2] drivers: mfd: refactor the vexpress config bridge API
From: Pawel Moll pawel.m...@arm.com
The introduction of Serial Power Controller (SPC) requires the vexpress
config interface to change slightly since the SPC memory mapped interface
can be used as configuration bus but also for operating points
programming and retrieval. The helper that allocates the bridge functions
requires an additional parameter allowing to request component specific
functions that need not be initialized through device tree bindings but
just using simple look-up and statically defined constants.
This patch introduces the necessary changes to the vexpress config layer
to cater for the new vexpress bridge interface requirements.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Achin Gupta achin.gu...@arm.com
Cc: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Jon Medhurst t...@linaro.org
Signed-off-by: Pawel Moll pawel.m...@arm.com
Acked-by: Nicolas Pitre n...@linaro.org
---
drivers/mfd/vexpress-config.c | 61 ++
drivers/mfd/vexpress-sysreg.c | 2 +-
include/linux/vexpress.h | 16 ++-
3 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index 84ce6b9..1af2b0e 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -86,29 +86,13 @@ void vexpress_config_bridge_unregister(struct
vexpress_config_bridge *bridge)
}
EXPORT_SYMBOL(vexpress_config_bridge_unregister);
-
-struct vexpress_config_func {
- struct vexpress_config_bridge *bridge;
- void *func;
-};
-
-struct vexpress_config_func *__vexpress_config_func_get(struct device *dev,
- struct device_node *node)
+static struct vexpress_config_bridge *
+ vexpress_config_bridge_find(struct device_node *node)
{
- struct device_node *bridge_node;
- struct vexpress_config_func *func;
int i;
+ struct vexpress_config_bridge *res = NULL;
+ struct device_node *bridge_node = of_node_get(node);
- if (WARN_ON(dev node dev-of_node != node))
- return NULL;
- if (dev !node)
- node = dev-of_node;
-
- func = kzalloc(sizeof(*func), GFP_KERNEL);
- if (!func)
- return NULL;
-
- bridge_node = of_node_get(node);
while (bridge_node) {
const __be32 *prop = of_get_property(bridge_node,
arm,vexpress,config-bridge, NULL);
@@ -129,13 +113,46 @@ struct vexpress_config_func
*__vexpress_config_func_get(struct device *dev,
if (test_bit(i, vexpress_config_bridges_map)
bridge-node == bridge_node) {
- func-bridge = bridge;
- func-func = bridge-info-func_get(dev, node);
+ res = bridge;
break;
}
}
mutex_unlock(vexpress_config_bridges_mutex);
+ return res;
+}
+
+
+struct vexpress_config_func {
+ struct vexpress_config_bridge *bridge;
+ void *func;
+};
+
+struct vexpress_config_func *__vexpress_config_func_get(
+ struct vexpress_config_bridge *bridge,
+ struct device *dev,
+ struct device_node *node,
+ const char *id)
+{
+ struct vexpress_config_func *func;
+
+ if (WARN_ON(dev node dev-of_node != node))
+ return NULL;
+ if (dev !node)
+ node = dev-of_node;
+
+ if (!bridge)
+ bridge = vexpress_config_bridge_find(node);
+ if (!bridge)
+ return NULL;
+
+ func = kzalloc(sizeof(*func), GFP_KERNEL);
+ if (!func)
+ return NULL;
+
+ func-bridge = bridge;
+ func-func = bridge-info-func_get(dev, node, id);
+
if (!func-func) {
of_node_put(node);
kfree(func);
diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
index 96a020b..d2599aa 100644
--- a/drivers/mfd/vexpress-sysreg.c
+++ b/drivers/mfd/vexpress-sysreg.c
@@ -165,7 +165,7 @@ static u32 *vexpress_sysreg_config_data;
static int vexpress_sysreg_config_tries;
static void *vexpress_sysreg_config_func_get(struct device *dev,
- struct device_node *node)
+ struct device_node *node, const char *id)
{
struct vexpress_sysreg_config_func *config_func;
u32 site;
diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h
index 6e7980d..50368e0 100644
--- a/include/linux/vexpress.h
+++ b/include/linux/vexpress.h
@@ -68,7 +68,8 @@
*/
struct vexpress_config_bridge_info {
const char *name;
- void *(*func_get)(struct device *dev, struct device_node *node);
+ void *(*func_get)(struct device *dev, struct device_node *node,
+ const char *id);
void (*func_put)(void *func);
int (*func_exec)(void *func, int offset,
[RFC PATCH v4 0/2] drivers: mfd: Versatile Express SPC support
This patch is v4 of a previous posting: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173831.html v4 changes: - Applied review comments (trimmed function names, added comments, refactored some APIs) - Added comments throughout the set - Fixed irq handler bug in checking the transaction status - Improved commit log to explain early init synchro scheme - Created a single static structure for variables dynamically allocated to remove usage of static - Improved Kconfig entry v3 changes: - added __refdata to spc_check_loaded pointer - removed some exported symbols - added node pointer check in vexpress_spc_init() v2 changes: - Dropped timeout interface patch - Converted interfaces to non-timeout ones, integrated and retested - Removed mutex used at init - Refactored code to work around init sections warning - Fixed two minor bugs This patch series introduces support for the Versatile Express Serial Power Controller (SPC) present in ARM Versatile Express TC2 core tiles. SPC driver is a fundamental component of TC2 power management and allows to carry out C-state management and DVFS for A15 and A7 clusters. First patch provides changes required by SPC to comply with the Versatile Express config API, second patch is the SPC driver implementation. Code extensively exercised through CPUidle and CPUfreq power states and operating point transitions. Lorenzo Pieralisi (1): drivers: mfd: vexpress: add Serial Power Controller (SPC) support Pawel Moll (1): drivers: mfd: refactor the vexpress config bridge API Documentation/devicetree/bindings/mfd/vexpress-spc.txt | 36 + drivers/mfd/Kconfig| 13 + drivers/mfd/Makefile | 1 + drivers/mfd/vexpress-config.c | 61 +- drivers/mfd/vexpress-spc.c | 666 ++ drivers/mfd/vexpress-sysreg.c | 2 +- include/linux/vexpress.h | 49 +- 7 files changed, 800 insertions(+), 28 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/vexpress-spc.txt create mode 100644 drivers/mfd/vexpress-spc.c -- 1.8.2.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
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, operating points and reset control.
This patch provides a driver that enables run-time control of features
implemented by the SPC 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.
Since the SPC logic is also used to control clocks and operating points,
that have to be initialized early as well, the SPC interface consumers can not
rely on early initcalls ordering, which is inconsistent, to wait for SPC
initialization. Hence, in order to keep the components relying on the SPC
coded in a sane way, the driver puts in place a synchronization scheme that
allows kernel drivers to check if the SPC driver has been initialized and if
not, to initialize it upon check.
A status variable is kept in memory so that loadable modules that require SPC
interface (eg CPUfreq drivers) can still check the correct initialization and
use the driver correctly after functions used at boot to init the driver are
freed.
The driver also provides a bridge interface through the vexpress config
infrastructure. Operations allowing to read/write operating points are
made to go via the same interface as configuration transactions so that
all requests to M3 are serialized.
Device tree bindings documentation for the SPC component is provided with
the patchset.
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
Reviewed-by: Nicolas Pitre n...@linaro.org
---
Documentation/devicetree/bindings/mfd/vexpress-spc.txt | 36 +
drivers/mfd/Kconfig| 13 +
drivers/mfd/Makefile | 1 +
drivers/mfd/vexpress-spc.c | 666 ++
include/linux/vexpress.h | 33 +
5 files changed, 749 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..bd381d1
--- /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/voltage and
+operating point transitions, through memory mapped registers interface.
+
+On testchips like TC2 it also provides a serial configuration interface
+that can be used to retrieve temperature sensors, energy/voltage/current
+probes and oscillators values through the SYS configuration protocol defined
+for versatile express motherboards.
+
+- 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 d54e985..e032099 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1148,3 +1148,16 @@ 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
+ depends on VEXPRESS_CONFIG
+ help
+ The Serial Power Controller (SPC) for ARM Ltd. test chips, is
+ an IP that provides a memory mapped interface to power controller
+ HW and also a configuration interface compatible with the existing
+ Versatile Express SYS configuration protocol. The driver provides
+ an API abstraction allowing to control operating
Re: [RFC PATCH v3 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
Hi Olof,
thank you very much for having a look.
On Thu, Jun 13, 2013 at 11:52:33PM +0100, Olof Johansson wrote:
Hi,
Overall this driver looks like it just needs more cooking
time. It's... gritty. Complicated when it should be simple and
layered. Naming is nonobvious, and overall it's hard to glance at a
function and say ah, it does x.
It is hard to make it clear too, and I am not on the defensive, it is
not a standard component following a standard interface, but point taken
I will do my best to improve it according to your reviews.
I think some of this might be because of naming conventions. Lots of long
prefixes, subsystem indirection, etc. I wish I had a straight answer to
what would make it better, but just more overall polish.
So, I have a bunch of comments below. Most of these are related to
readability, which is one of the most important things of new code
these days.
Please find a shorter suitable prefix than vexpress_spc_.* too, it's
way too long.
Ok.
On Thu, Jun 06, 2013 at 10:59:23AM +0100, 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, operating points and reset control.
This patch provides a driver that enables run-time control of features
implemented by the SPC control logic.
The driver also provides a bridge interface through the vexpress config
infrastructure. Operations allowing to read/write operating points are
made to go via the same interface as configuration transactions so that
all requests to M3 are serialized.
Device tree bindings documentation for the SPC component is provided with
the patchset.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Nicolas Pitre nicolas.pi...@linaro.org
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
Reviewed-by: Nicolas Pitre n...@linaro.org
---
Documentation/devicetree/bindings/mfd/vexpress-spc.txt | 35 +
drivers/mfd/Kconfig| 7 +
drivers/mfd/Makefile | 1 +
drivers/mfd/vexpress-spc.c | 633 ++
include/linux/vexpress.h | 43 +
5 files changed, 719 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..1d71dc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
@@ -0,0 +1,35 @@
+* 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/voltage and
+operating point transitions, through memory mapped registers interface.
+
+On testchips like TC2 it also provides a configuration interface that can
+be used to read/write values which cannot be read/written through simple
+memory mapped reads/writes.
A configuration interface for what? Just having it as a PMIC doesn't warrant
it
being an MFD, really.
Ok, description added.
+- 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;
Nit: space after comma between strings.
+ reg = 0 0x7FFF 0 0x1000;
#size-cells 2 on the parent bus? That's somewhat unusual. We tend to prefer
lowercase hex.
Ok on both counts.
+ interrupts = 0 95 4;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d54e985..391eda1 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1148,3 +1148,10 @@ config VEXPRESS_CONFIG
help
Platform configuration infrastructure for the ARM Ltd.
Versatile
Re: [RFC PATCH v3 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
Hi Samuel,
first things first, thanks a lot for having a look.
On Thu, Jun 13, 2013 at 01:01:43AM +0100, Samuel Ortiz wrote:
Hi Lorenzo,
I don't particularily like this code, but I guess most of my dislike
comes from the whole bridge interface API and how that forces you into
implementing pretty much static code.
I do not particularly like it either; you have to grant us though, as Nico
explained, that the usage of this piece of hardware very early at boot is
forcing us to find a solution that is not necessarily easy to implement.
A few nitpicks:
On Thu, Jun 06, 2013 at 10:59:23AM +0100, Lorenzo Pieralisi wrote:
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d54e985..391eda1 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1148,3 +1148,10 @@ 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
+ depends on VEXPRESS_CONFIG
+ help
Please provide a detailed help entry here.
Ok.
+ Serial Power Controller driver for ARM Ltd. test chips.
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
So you have Versatile Express platforms that will not need SPC ? i.e.
why isn't all that stuff under a generic CONFIG_VEXPRESS symbol ?
You answered your own question, the Serial Power Controller aka SPC is
present only in one of the many coretiles that can be stacked on top
of the versatile express motherboard, so it requires a specific entry
unless we want to compile it in for all vexpress platforms.
+static struct vexpress_spc_drvdata *info;
+static u32 *vexpress_spc_config_data;
+static struct vexpress_config_bridge *vexpress_spc_config_bridge;
+static struct vexpress_config_func *opp_func, *perf_func;
+
+static int vexpress_spc_load_result = -EAGAIN;
As I said, quite static...
I will have a look and see if I can improve it, I could include some of
those variables in the driver data and alloc them dynamically.
+irqreturn_t vexpress_spc_irq_handler(int irq, void *data)
missing a static here ?
Were not there enough :-) ? Correct, I will fix it.
+static bool __init __vexpress_spc_check_loaded(void);
+/*
+ * Pointer spc_check_loaded is swapped after init hence it is safe
+ * to initialize it to a function in the __init section
+ */
+static bool (*spc_check_loaded)(void) __refdata =
__vexpress_spc_check_loaded;
+
+static bool __init __vexpress_spc_check_loaded(void)
+{
+ if (vexpress_spc_load_result == -EAGAIN)
+ vexpress_spc_load_result = vexpress_spc_init();
+ spc_check_loaded = vexpress_spc_initialized;
+ return vexpress_spc_initialized();
+}
+
+/*
+ * Function exported to manage early_initcall ordering.
+ * SPC code is needed very early in the boot process
+ * to bring CPUs out of reset and initialize power
+ * management back-end. After boot swap pointers to
+ * make the functionality check available to loadable
+ * modules, when early boot init functions have been
+ * already freed from kernel address space.
+ */
+bool vexpress_spc_check_loaded(void)
+{
+ return spc_check_loaded();
+}
+EXPORT_SYMBOL_GPL(vexpress_spc_check_loaded);
That one and the previous function look really nasty to me.
The simple fact that you need a static variable in your code to check if
your module is loaded sounds really fishy.
Nico explained the reasons behind this nasty hack, because that's what it
is. The only solution is resorting to vexpress platform code to initialize
this driver directly (providing a static virtual memory mapping since that
has to happen very early) to remove all needs for early_initcall
synchronization and remove that variable. It won't look nicer though.
I will review the code again to see how I can improve it.
Thanks a lot,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 0/2] drivers: mfd: Versatile Express SPC support
Hi Samuel, if nobody has objections I think this set is ready to get merged. As Nico mentioned in: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173541.html since we would like to get it merged through the ARM SoC tree owing to dependencies between this code and ARM power management back-ends, your ack would be appreciated, if you think it is worth it of course. Thank you very much indeed, Lorenzo On Thu, Jun 06, 2013 at 10:59:21AM +0100, Lorenzo Pieralisi wrote: This patch is v3 of a previous posting: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173464.html v3 changes: - added __refdata to spc_check_loaded pointer - removed some exported symbols - added node pointer check in vexpress_spc_init() v2 changes: - Dropped timeout interface patch - Converted interfaces to non-timeout ones, integrated and retested - Removed mutex used at init - Refactored code to work around init sections warning - Fixed two minor bugs This patch series introduces support for the Versatile Express Serial Power Controller (SPC) present in ARM Versatile Express TC2 core tiles. SPC driver is a fundamental component of TC2 power management and allows to carry out C-state management and DVFS for A15 and A7 clusters. First patch provides changes required by SPC to comply with the Versatile Express config API, second patch is the SPC driver implementation. Code extensively exercised through CPUidle and CPUfreq power states and operating point transitions. Lorenzo Pieralisi (1): drivers: mfd: vexpress: add Serial Power Controller (SPC) support Pawel Moll (1): drivers: mfd: refactor the vexpress config bridge API Documentation/devicetree/bindings/mfd/vexpress-spc.txt | 35 + drivers/mfd/Kconfig| 7 + drivers/mfd/Makefile | 1 + drivers/mfd/vexpress-config.c | 61 +- drivers/mfd/vexpress-spc.c | 633 ++ drivers/mfd/vexpress-sysreg.c | 2 +- include/linux/vexpress.h | 59 +- 7 files changed, 770 insertions(+), 28 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/vexpress-spc.txt create mode 100644 drivers/mfd/vexpress-spc.c -- 1.8.2.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm/dt: Don't add disabled CPUs to system topology
On Fri, Jun 07, 2013 at 03:20:20PM +0100, Rob Herring wrote: On 06/07/2013 05:23 AM, Lorenzo Pieralisi wrote: Hi James, On Thu, Jun 06, 2013 at 06:11:25PM +0100, James King wrote: If CPUs are marked as disabled in the devicetree, make sure they do not exist in the system CPU information and CPU topology information. In this case these CPUs will not be able to be added to the system later using hot-plug. This allows a single chip with many CPUs to be easily used in a variety of hardware devices where they may have different actual processing requirements (eg for thermal/cost reasons). - Change devicetree.c to ignore any cpu nodes marked as disabled, this effectively limits the number of active cpu cores so no need for the max_cpus=x in the chosen node. - Change topology.c to ignore any cpu nodes marked as disabled, this is where the scheduler would learn about big/LITTLE cores so this effectively keeps the scheduler in sync. I have two questions: 1) Since with this approach the DT should change anyway if on different hardware devices based on the same chip you want to allow booting a different number of CPUs, why do not we remove the cpu nodes instead of disabling them ? Put it another way: cpu nodes define a cpu as possible (currently), we can simply remove the node if we do not want that cpu to be seen by the kernel. 2) If we go for the status property, why do not we use it to set present mask ? That way the cpu is possible but not present, you cannot hotplug it in. It is a bit of a stretch, granted, the cpu _is_ present, we just want to disable it, do not know how this is handled in x86 and other archs though. The meaning of disabled for cpus in ePAPR is that the cpu is offline (i.e. in a spinloop or wfi), not that the cpu is unavailable. This is a bit of a departure and inconsistency from how status for devices are used. That would imply that we should be setting status to disabled for all secondary cores and that possibly the status value should get updated to reflect the state of the cpu. Yes, that's what I understood from the ePAPR as well. According to the ePAPR, as you say, a cpu with its status property == disabled is a possible CPU, since it can be enabled (through a specific enable-method). I am not sure status can be reused for the purpose this patch was developed for without changing the bindings in the ePAPR (ie if DT parsing skips cpu nodes with status == disabled, this is a significant departure from what ePAPR defines, and it would force us to define an enable-method to enable/online those CPUs which is not what this patch was developed for). How was PowerPC tackling the problem James set about solving ? Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm/dt: Don't add disabled CPUs to system topology
On Fri, Jun 07, 2013 at 12:48:58PM +0100, James King wrote:
Hi Lorenzo,
On 7 June 2013 11:23, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote:
Hi James,
On Thu, Jun 06, 2013 at 06:11:25PM +0100, James King wrote:
If CPUs are marked as disabled in the devicetree, make sure they do
not exist in the system CPU information and CPU topology information.
In this case these CPUs will not be able to be added to the system later
using hot-plug. This allows a single chip with many CPUs to be easily
used in a variety of hardware devices where they may have different
actual processing requirements (eg for thermal/cost reasons).
- Change devicetree.c to ignore any cpu nodes marked as disabled,
this effectively limits the number of active cpu cores so no need
for the max_cpus=x in the chosen node.
- Change topology.c to ignore any cpu nodes marked as disabled, this
is where the scheduler would learn about big/LITTLE cores so this
effectively keeps the scheduler in sync.
I have two questions:
1) Since with this approach the DT should change anyway if on different
hardware devices based on the same chip you want to allow booting a
different number of CPUs, why do not we remove the cpu nodes instead of
disabling them ? Put it another way: cpu nodes define a cpu as
possible (currently), we can simply remove the node if we do not want
that cpu to be seen by the kernel.
The reason we want disabled status rather than just remove the nodes
is to use a common soc.dtsi file which is included in many board.dts
files - eg:
file soc.dtsi contains:
cpus {
cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a7;
reg = 0;
cluster = cluster0;
core = core0;
Minor nit, cluster and core phandles are not part of cpu the bindings
that will be merged this cycle, I know it is just an example.
};
cpu1: cpu@1 {
device_type = cpu;
compatible = arm,cortex-a7;
reg = 1;
cluster = cluster0;
core = core1;
};
cpu2: cpu@2 {
device_type = cpu;
compatible = arm,cortex-a15;
reg = 2;
cluster = cluster0;
core = core2;
};
};
file board1.dts where we want the A15 disabled contains:
/include/ soc.dtsi
cpus {
cpu2: cpu@2 {
status = disabled;
};
};
Understood, see the other reply as far as the status property is concerned.
2) If we go for the status property, why do not we use it to set present
mask ? That way the cpu is possible but not present, you cannot
hotplug it in. It is a bit of a stretch, granted, the cpu _is_ present,
we just want to disable it, do not know how this is handled in x86
and other archs though.
I have been struggling to find any equivalent example for another
arch, so just tried to solve our problem. I guess in the x86 world it
is less likely to want to disable processors in a SoC for heat/battery
issues so this has just never arisen. In this case the cpu is
physically present but not possible, but I am not sure it should be in
a present mask (giving the impression it can be used). Perhaps you
could elaborate with an example what you are thinking about here?
I was thinking about using status == disabled to mark a cpu as
possible but not present; that is a bad idea for the reason you mentioned
and also for the point Rob raised related to the ePAPR.
I am not sure how we can solve this issue, as I mentioned the easiest
solution consists in not defining cpu nodes in the DT or probably add
an additional property != status with proper bindings attached to it.
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 1/2] drivers: mfd: refactor the vexpress config bridge API
From: Pawel Moll pawel.m...@arm.com
The introduction of Serial Power Controller (SPC) requires the vexpress
config interface to change slightly since the SPC memory mapped interface
can be used as configuration bus but also for operating points
programming and retrieval. The helper that allocates the bridge functions
requires an additional parameter allowing to request component specific
functions that need not be initialized through device tree bindings but
just using simple look-up and statically defined constants.
This patch introduces the necessary changes to the vexpress config layer
to cater for the new vexpress bridge interface requirements.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Achin Gupta achin.gu...@arm.com
Cc: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Jon Medhurst t...@linaro.org
Signed-off-by: Pawel Moll pawel.m...@arm.com
Acked-by: Nicolas Pitre n...@linaro.org
---
drivers/mfd/vexpress-config.c | 61 ++
drivers/mfd/vexpress-sysreg.c | 2 +-
include/linux/vexpress.h | 16 ++-
3 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index 84ce6b9..1af2b0e 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -86,29 +86,13 @@ void vexpress_config_bridge_unregister(struct
vexpress_config_bridge *bridge)
}
EXPORT_SYMBOL(vexpress_config_bridge_unregister);
-
-struct vexpress_config_func {
- struct vexpress_config_bridge *bridge;
- void *func;
-};
-
-struct vexpress_config_func *__vexpress_config_func_get(struct device *dev,
- struct device_node *node)
+static struct vexpress_config_bridge *
+ vexpress_config_bridge_find(struct device_node *node)
{
- struct device_node *bridge_node;
- struct vexpress_config_func *func;
int i;
+ struct vexpress_config_bridge *res = NULL;
+ struct device_node *bridge_node = of_node_get(node);
- if (WARN_ON(dev node dev-of_node != node))
- return NULL;
- if (dev !node)
- node = dev-of_node;
-
- func = kzalloc(sizeof(*func), GFP_KERNEL);
- if (!func)
- return NULL;
-
- bridge_node = of_node_get(node);
while (bridge_node) {
const __be32 *prop = of_get_property(bridge_node,
arm,vexpress,config-bridge, NULL);
@@ -129,13 +113,46 @@ struct vexpress_config_func
*__vexpress_config_func_get(struct device *dev,
if (test_bit(i, vexpress_config_bridges_map)
bridge-node == bridge_node) {
- func-bridge = bridge;
- func-func = bridge-info-func_get(dev, node);
+ res = bridge;
break;
}
}
mutex_unlock(vexpress_config_bridges_mutex);
+ return res;
+}
+
+
+struct vexpress_config_func {
+ struct vexpress_config_bridge *bridge;
+ void *func;
+};
+
+struct vexpress_config_func *__vexpress_config_func_get(
+ struct vexpress_config_bridge *bridge,
+ struct device *dev,
+ struct device_node *node,
+ const char *id)
+{
+ struct vexpress_config_func *func;
+
+ if (WARN_ON(dev node dev-of_node != node))
+ return NULL;
+ if (dev !node)
+ node = dev-of_node;
+
+ if (!bridge)
+ bridge = vexpress_config_bridge_find(node);
+ if (!bridge)
+ return NULL;
+
+ func = kzalloc(sizeof(*func), GFP_KERNEL);
+ if (!func)
+ return NULL;
+
+ func-bridge = bridge;
+ func-func = bridge-info-func_get(dev, node, id);
+
if (!func-func) {
of_node_put(node);
kfree(func);
diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
index 96a020b..d2599aa 100644
--- a/drivers/mfd/vexpress-sysreg.c
+++ b/drivers/mfd/vexpress-sysreg.c
@@ -165,7 +165,7 @@ static u32 *vexpress_sysreg_config_data;
static int vexpress_sysreg_config_tries;
static void *vexpress_sysreg_config_func_get(struct device *dev,
- struct device_node *node)
+ struct device_node *node, const char *id)
{
struct vexpress_sysreg_config_func *config_func;
u32 site;
diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h
index 6e7980d..50368e0 100644
--- a/include/linux/vexpress.h
+++ b/include/linux/vexpress.h
@@ -68,7 +68,8 @@
*/
struct vexpress_config_bridge_info {
const char *name;
- void *(*func_get)(struct device *dev, struct device_node *node);
+ void *(*func_get)(struct device *dev, struct device_node *node,
+ const char *id);
void (*func_put)(void *func);
[RFC PATCH v2 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
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, operating points and reset control.
This patch provides a driver that enables run-time control of features
implemented by the SPC control logic.
The driver also provides a bridge interface through the vexpress config
infrastructure. Operations allowing to read/write operating points are
made to go via the same interface as configuration transactions so that
all requests to M3 are serialized.
Device tree bindings documentation for the SPC component is provided with
the patchset.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Nicolas Pitre nicolas.pi...@linaro.org
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
---
.../devicetree/bindings/mfd/vexpress-spc.txt | 35 ++
drivers/mfd/Kconfig| 7 +
drivers/mfd/Makefile | 1 +
drivers/mfd/vexpress-spc.c | 630 +
include/linux/vexpress.h | 43 ++
5 files changed, 716 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/vexpress-spc.txt
create mode 100644 drivers/mfd/vexpress-spc.c
diff --git a/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
new file mode 100644
index 000..1d71dc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
@@ -0,0 +1,35 @@
+* 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/voltage and
+operating point transitions, through memory mapped registers interface.
+
+On testchips like TC2 it also provides a configuration interface that can
+be used to read/write values which cannot be read/written through simple
+memory mapped reads/writes.
+
+- 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 = 0 0x7FFF 0 0x1000;
+ interrupts = 0 95 4;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d54e985..391eda1 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1148,3 +1148,10 @@ 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
+ depends on VEXPRESS_CONFIG
+ help
+ Serial Power Controller driver for ARM Ltd. test chips.
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) += retu-mfd.o
obj-$(CONFIG_MFD_AS3711) += as3711.o
diff --git a/drivers/mfd/vexpress-spc.c b/drivers/mfd/vexpress-spc.c
new file mode 100644
index 000..1aaa673
--- /dev/null
+++ b/drivers/mfd/vexpress-spc.c
@@ -0,0 +1,630 @@
+/*
+ * Versatile Express Serial Power Controller (SPC) support
+ *
+ * Copyright (C) 2013 ARM Ltd.
+ *
+ * Author(s): Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
+ *Achin Gupta achin.gu...@arm.com
+ *Lorenzo Pieralisi lorenzo.pieral...@arm.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
[RFC PATCH v2 1/2] drivers: mfd: refactor the vexpress config bridge API
From: Pawel Moll pawel.m...@arm.com
The introduction of Serial Power Controller (SPC) requires the vexpress
config interface to change slightly since the SPC memory mapped interface
can be used as configuration bus but also for operating points
programming and retrieval. The helper that allocates the bridge functions
requires an additional parameter allowing to request component specific
functions that need not be initialized through device tree bindings but
just using simple look-up and statically defined constants.
This patch introduces the necessary changes to the vexpress config layer
to cater for the new vexpress bridge interface requirements.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Achin Gupta achin.gu...@arm.com
Cc: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Jon Medhurst t...@linaro.org
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
drivers/mfd/vexpress-config.c | 61 +++
drivers/mfd/vexpress-sysreg.c | 2 +-
include/linux/vexpress.h | 16
3 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index 84ce6b9..1af2b0e 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -86,29 +86,13 @@ void vexpress_config_bridge_unregister(struct
vexpress_config_bridge *bridge)
}
EXPORT_SYMBOL(vexpress_config_bridge_unregister);
-
-struct vexpress_config_func {
- struct vexpress_config_bridge *bridge;
- void *func;
-};
-
-struct vexpress_config_func *__vexpress_config_func_get(struct device *dev,
- struct device_node *node)
+static struct vexpress_config_bridge *
+ vexpress_config_bridge_find(struct device_node *node)
{
- struct device_node *bridge_node;
- struct vexpress_config_func *func;
int i;
+ struct vexpress_config_bridge *res = NULL;
+ struct device_node *bridge_node = of_node_get(node);
- if (WARN_ON(dev node dev-of_node != node))
- return NULL;
- if (dev !node)
- node = dev-of_node;
-
- func = kzalloc(sizeof(*func), GFP_KERNEL);
- if (!func)
- return NULL;
-
- bridge_node = of_node_get(node);
while (bridge_node) {
const __be32 *prop = of_get_property(bridge_node,
arm,vexpress,config-bridge, NULL);
@@ -129,13 +113,46 @@ struct vexpress_config_func
*__vexpress_config_func_get(struct device *dev,
if (test_bit(i, vexpress_config_bridges_map)
bridge-node == bridge_node) {
- func-bridge = bridge;
- func-func = bridge-info-func_get(dev, node);
+ res = bridge;
break;
}
}
mutex_unlock(vexpress_config_bridges_mutex);
+ return res;
+}
+
+
+struct vexpress_config_func {
+ struct vexpress_config_bridge *bridge;
+ void *func;
+};
+
+struct vexpress_config_func *__vexpress_config_func_get(
+ struct vexpress_config_bridge *bridge,
+ struct device *dev,
+ struct device_node *node,
+ const char *id)
+{
+ struct vexpress_config_func *func;
+
+ if (WARN_ON(dev node dev-of_node != node))
+ return NULL;
+ if (dev !node)
+ node = dev-of_node;
+
+ if (!bridge)
+ bridge = vexpress_config_bridge_find(node);
+ if (!bridge)
+ return NULL;
+
+ func = kzalloc(sizeof(*func), GFP_KERNEL);
+ if (!func)
+ return NULL;
+
+ func-bridge = bridge;
+ func-func = bridge-info-func_get(dev, node, id);
+
if (!func-func) {
of_node_put(node);
kfree(func);
diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
index 96a020b..d2599aa 100644
--- a/drivers/mfd/vexpress-sysreg.c
+++ b/drivers/mfd/vexpress-sysreg.c
@@ -165,7 +165,7 @@ static u32 *vexpress_sysreg_config_data;
static int vexpress_sysreg_config_tries;
static void *vexpress_sysreg_config_func_get(struct device *dev,
- struct device_node *node)
+ struct device_node *node, const char *id)
{
struct vexpress_sysreg_config_func *config_func;
u32 site;
diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h
index 6e7980d..50368e0 100644
--- a/include/linux/vexpress.h
+++ b/include/linux/vexpress.h
@@ -68,7 +68,8 @@
*/
struct vexpress_config_bridge_info {
const char *name;
- void *(*func_get)(struct device *dev, struct device_node *node);
+ void *(*func_get)(struct device *dev, struct device_node *node,
+ const char *id);
void (*func_put)(void *func);
Re: [RFC PATCH 2/3] drivers: mfd: vexpress: add timeout API to vexpress config interface
On Mon, Jun 03, 2013 at 11:15:32AM +0100, Jon Medhurst (Tixy) wrote:
On Fri, 2013-05-24 at 13:53 +0100, Lorenzo Pieralisi wrote:
In case some transactions to the Serial Power Controller (SPC) are lost
owing
to multiple operations handled at once by the M3 controller the OS needs to
rely on a configuration API that can time out so that failures do not result
in an unusable system.
This patch adds a timeout API to the vexpress config programming interface,
and refactors the existing read/write functions so that they can be reused
seamlessly on top of the newly defined API.
Isn't one of the main purposes of the config interface to serialise
transactions to the config bus, so why would the SPC be handling
multiple transactions at once? And if we can in fact loose transactions
doesn't this mean we get random failures in the system? E.g. if this
happened at boot in vexpress_spc_populate_opps then cpufreq will fail.
It has more to do with firmware carrying out background operations like
powering up a cluster when a DVFS is requested. You are absolutely right
though:
a) the timeout interface is broken, as you mentioned (I noticed after
posting it)
b) we should not add a timeout interface to paper over FW issues
I can prepare a v2 with timeout interface dropped and extensively test that
one, I do not think we should add the required complexity that you describe
below for something that should never happen.
Also, I think the code implementing timeouts is broken, see below.
I will have a look asap and repost a v2 accordingly.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Achin Gupta achin.gu...@arm.com
Cc: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Jon Medhurst t...@linaro.org
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
drivers/mfd/vexpress-config.c | 26 +++---
include/linux/vexpress.h | 23 ++--
2 files changed, 37 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index 1af2b0e..6f4aa5a 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -266,8 +266,18 @@ int vexpress_config_wait(struct vexpress_config_trans
*trans)
}
EXPORT_SYMBOL(vexpress_config_wait);
-int vexpress_config_read(struct vexpress_config_func *func, int offset,
- u32 *data)
+int vexpress_config_wait_timeout(struct vexpress_config_trans *trans,
+ long jiffies)
+{
+ int ret;
+ ret = wait_for_completion_timeout(trans-completion, jiffies);
If the request times out, don't we need to call vexpress_config_complete
to dequeue the timed out request and trigger the next one? Though we
will still have a problem where the timeout happens but the request
then does in fact complete normally, in that case we would signal
completion of the second request before it has in fact completed.
So, if transactions really can get silently dropped by thing on the end
of the config bus, then we must have a mechanism for associating a
particular transaction with a completion signal, otherwise we won't know
what transaction actually got completed OK and which ones were dropped
and should receive -ETIMEDOUT.
Finally, I don't think these issues are purely theoretical, I'm pretty
certain that the kernel panics and spinlock bad magic errors I see with
his patch series are due to requests completing after they have been
timed out and then the stack based transaction object is being accessed
after it has gone out of scope.
You are absolutely right, apologies for wasting your time in testing it.
Thanks a lot for the review,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 2/3] drivers: mfd: vexpress: add timeout API to vexpress config interface
On Mon, Jun 03, 2013 at 01:03:50PM +0100, Jon Medhurst (Tixy) wrote: On Mon, 2013-06-03 at 12:52 +0100, Lorenzo Pieralisi wrote: On Mon, Jun 03, 2013 at 11:15:32AM +0100, Jon Medhurst (Tixy) wrote: On Fri, 2013-05-24 at 13:53 +0100, Lorenzo Pieralisi wrote: In case some transactions to the Serial Power Controller (SPC) are lost owing to multiple operations handled at once by the M3 controller the OS needs to rely on a configuration API that can time out so that failures do not result in an unusable system. This patch adds a timeout API to the vexpress config programming interface, and refactors the existing read/write functions so that they can be reused seamlessly on top of the newly defined API. Isn't one of the main purposes of the config interface to serialise transactions to the config bus, so why would the SPC be handling multiple transactions at once? And if we can in fact loose transactions doesn't this mean we get random failures in the system? E.g. if this happened at boot in vexpress_spc_populate_opps then cpufreq will fail. It has more to do with firmware carrying out background operations like powering up a cluster when a DVFS is requested. Would that make it drop transactions or just take a longer time to get around to servicing them? It should just take longer to service them, that's what the behaviour should be. Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 0/3] drivers: mfd: Versatile Express SPC support
This patch series introduces support for the Versatile Express Serial Power Controller (SPC) present in ARM Versatile Express TC2 core tiles. SPC driver is a fundamental component of TC2 power management and allows to carry out C-state management and DVFS for A15 and A7 clusters. First two patches provide changes required by SPC to comply with the Versatile Express config API, third patch is the SPC driver implementation. Code extensively exercised through CPUidle and CPUfreq power states and operating point transitions. Lorenzo Pieralisi (2): drivers: mfd: vexpress: add timeout API to vexpress config interface drivers: mfd: vexpress: add Serial Power Controller (SPC) support Pawel Moll (1): drivers: mfd: refactor the vexpress config bridge API Documentation/devicetree/bindings/mfd/vexpress-spc.txt | 35 + drivers/mfd/Kconfig| 7 + drivers/mfd/Makefile | 1 + drivers/mfd/vexpress-config.c | 87 +- drivers/mfd/vexpress-spc.c | 626 ++ drivers/mfd/vexpress-sysreg.c | 2 +- include/linux/vexpress.h | 82 +- 7 files changed, 800 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/vexpress-spc.txt create mode 100644 drivers/mfd/vexpress-spc.c -- 1.8.2.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 1/3] drivers: mfd: refactor the vexpress config bridge API
From: Pawel Moll pawel.m...@arm.com
The introduction of Serial Power Controller (SPC) requires the vexpress
config interface to change slightly since the SPC memory mapped interface
can be used as configuration bus but also for operating points
programming and retrieval. The helper that allocates the bridge functions
requires an additional parameter allowing to request component specific
functions that need not be initialized through device tree bindings but
just using simple look-up and statically defined constants.
This patch introduces the necessary changes to the vexpress config layer
to cater for the new vexpress bridge interface requirements.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Achin Gupta achin.gu...@arm.com
Cc: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Jon Medhurst t...@linaro.org
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
drivers/mfd/vexpress-config.c | 61 ++
drivers/mfd/vexpress-sysreg.c | 2 +-
include/linux/vexpress.h | 16 ++-
3 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index 84ce6b9..1af2b0e 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -86,29 +86,13 @@ void vexpress_config_bridge_unregister(struct
vexpress_config_bridge *bridge)
}
EXPORT_SYMBOL(vexpress_config_bridge_unregister);
-
-struct vexpress_config_func {
- struct vexpress_config_bridge *bridge;
- void *func;
-};
-
-struct vexpress_config_func *__vexpress_config_func_get(struct device *dev,
- struct device_node *node)
+static struct vexpress_config_bridge *
+ vexpress_config_bridge_find(struct device_node *node)
{
- struct device_node *bridge_node;
- struct vexpress_config_func *func;
int i;
+ struct vexpress_config_bridge *res = NULL;
+ struct device_node *bridge_node = of_node_get(node);
- if (WARN_ON(dev node dev-of_node != node))
- return NULL;
- if (dev !node)
- node = dev-of_node;
-
- func = kzalloc(sizeof(*func), GFP_KERNEL);
- if (!func)
- return NULL;
-
- bridge_node = of_node_get(node);
while (bridge_node) {
const __be32 *prop = of_get_property(bridge_node,
arm,vexpress,config-bridge, NULL);
@@ -129,13 +113,46 @@ struct vexpress_config_func
*__vexpress_config_func_get(struct device *dev,
if (test_bit(i, vexpress_config_bridges_map)
bridge-node == bridge_node) {
- func-bridge = bridge;
- func-func = bridge-info-func_get(dev, node);
+ res = bridge;
break;
}
}
mutex_unlock(vexpress_config_bridges_mutex);
+ return res;
+}
+
+
+struct vexpress_config_func {
+ struct vexpress_config_bridge *bridge;
+ void *func;
+};
+
+struct vexpress_config_func *__vexpress_config_func_get(
+ struct vexpress_config_bridge *bridge,
+ struct device *dev,
+ struct device_node *node,
+ const char *id)
+{
+ struct vexpress_config_func *func;
+
+ if (WARN_ON(dev node dev-of_node != node))
+ return NULL;
+ if (dev !node)
+ node = dev-of_node;
+
+ if (!bridge)
+ bridge = vexpress_config_bridge_find(node);
+ if (!bridge)
+ return NULL;
+
+ func = kzalloc(sizeof(*func), GFP_KERNEL);
+ if (!func)
+ return NULL;
+
+ func-bridge = bridge;
+ func-func = bridge-info-func_get(dev, node, id);
+
if (!func-func) {
of_node_put(node);
kfree(func);
diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
index 96a020b..d2599aa 100644
--- a/drivers/mfd/vexpress-sysreg.c
+++ b/drivers/mfd/vexpress-sysreg.c
@@ -165,7 +165,7 @@ static u32 *vexpress_sysreg_config_data;
static int vexpress_sysreg_config_tries;
static void *vexpress_sysreg_config_func_get(struct device *dev,
- struct device_node *node)
+ struct device_node *node, const char *id)
{
struct vexpress_sysreg_config_func *config_func;
u32 site;
diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h
index 6e7980d..50368e0 100644
--- a/include/linux/vexpress.h
+++ b/include/linux/vexpress.h
@@ -68,7 +68,8 @@
*/
struct vexpress_config_bridge_info {
const char *name;
- void *(*func_get)(struct device *dev, struct device_node *node);
+ void *(*func_get)(struct device *dev, struct device_node *node,
+ const char *id);
void (*func_put)(void *func);
int (*func_exec)(void *func, int
[RFC PATCH 2/3] drivers: mfd: vexpress: add timeout API to vexpress config interface
In case some transactions to the Serial Power Controller (SPC) are lost owing
to multiple operations handled at once by the M3 controller the OS needs to
rely on a configuration API that can time out so that failures do not result
in an unusable system.
This patch adds a timeout API to the vexpress config programming interface,
and refactors the existing read/write functions so that they can be reused
seamlessly on top of the newly defined API.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Achin Gupta achin.gu...@arm.com
Cc: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Jon Medhurst t...@linaro.org
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
drivers/mfd/vexpress-config.c | 26 +++---
include/linux/vexpress.h | 23 ++--
2 files changed, 37 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index 1af2b0e..6f4aa5a 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -266,8 +266,18 @@ int vexpress_config_wait(struct vexpress_config_trans
*trans)
}
EXPORT_SYMBOL(vexpress_config_wait);
-int vexpress_config_read(struct vexpress_config_func *func, int offset,
- u32 *data)
+int vexpress_config_wait_timeout(struct vexpress_config_trans *trans,
+ long jiffies)
+{
+ int ret;
+ ret = wait_for_completion_timeout(trans-completion, jiffies);
+
+ return ret ? trans-status : -ETIMEDOUT;
+}
+EXPORT_SYMBOL(vexpress_config_wait_timeout);
+
+int vexpress_config_read_timeout(struct vexpress_config_func *func, int offset,
+ u32 *data, long jiffies)
{
struct vexpress_config_trans trans = {
.func = func,
@@ -279,14 +289,14 @@ int vexpress_config_read(struct vexpress_config_func
*func, int offset,
int status = vexpress_config_schedule(trans);
if (status == VEXPRESS_CONFIG_STATUS_WAIT)
- status = vexpress_config_wait(trans);
+ status = vexpress_config_wait_timeout(trans, jiffies);
return status;
}
-EXPORT_SYMBOL(vexpress_config_read);
+EXPORT_SYMBOL(vexpress_config_read_timeout);
-int vexpress_config_write(struct vexpress_config_func *func, int offset,
- u32 data)
+int vexpress_config_write_timeout(struct vexpress_config_func *func,
+ int offset, u32 data, long jiffies)
{
struct vexpress_config_trans trans = {
.func = func,
@@ -298,8 +308,8 @@ int vexpress_config_write(struct vexpress_config_func
*func, int offset,
int status = vexpress_config_schedule(trans);
if (status == VEXPRESS_CONFIG_STATUS_WAIT)
- status = vexpress_config_wait(trans);
+ status = vexpress_config_wait_timeout(trans, jiffies);
return status;
}
-EXPORT_SYMBOL(vexpress_config_write);
+EXPORT_SYMBOL(vexpress_config_write_timeout);
diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h
index 50368e0..e5015d8 100644
--- a/include/linux/vexpress.h
+++ b/include/linux/vexpress.h
@@ -15,6 +15,7 @@
#define _LINUX_VEXPRESS_H
#include linux/device.h
+#include linux/sched.h
#define VEXPRESS_SITE_MB 0
#define VEXPRESS_SITE_DB1 1
@@ -102,10 +103,24 @@ struct vexpress_config_func *__vexpress_config_func_get(
void vexpress_config_func_put(struct vexpress_config_func *func);
/* Both may sleep! */
-int vexpress_config_read(struct vexpress_config_func *func, int offset,
- u32 *data);
-int vexpress_config_write(struct vexpress_config_func *func, int offset,
- u32 data);
+int vexpress_config_read_timeout(struct vexpress_config_func *func, int offset,
+ u32 *data, long jiffies);
+int vexpress_config_write_timeout(struct vexpress_config_func *func,
+ int offset, u32 data, long jiffies);
+
+static inline int vexpress_config_read(struct vexpress_config_func *func,
+int offset, u32 *data)
+{
+ return vexpress_config_read_timeout(func, offset, data,
+MAX_SCHEDULE_TIMEOUT);
+}
+
+static inline int vexpress_config_write(struct vexpress_config_func *func,
+int offset, u32 data)
+{
+ return vexpress_config_write_timeout(func, offset, data,
+MAX_SCHEDULE_TIMEOUT);
+}
/* Platform control */
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 3/3] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
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, operating points and reset control.
This patch provides a driver that enables run-time control of features
implemented by the SPC control logic.
The driver also provides a bridge interface through the vexpress config
infrastructure. Operations allowing to read/write operating points are
made to go via the same interface as configuration transactions so that
all requests to M3 are serialized.
Device tree bindings documentation for the SPC component are provided with
the patchset.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Nicolas Pitre nicolas.pi...@linaro.org
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 | 35 +
drivers/mfd/Kconfig| 7 +
drivers/mfd/Makefile | 1 +
drivers/mfd/vexpress-spc.c | 626 ++
include/linux/vexpress.h | 43 +
5 files changed, 712 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..1d71dc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
@@ -0,0 +1,35 @@
+* 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/voltage and
+operating point transitions, through memory mapped registers interface.
+
+On testchips like TC2 it also provides a configuration interface that can
+be used to read/write values which cannot be read/written through simple
+memory mapped reads/writes.
+
+- 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 = 0 0x7FFF 0 0x1000;
+ interrupts = 0 95 4;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d9aed15..b5259af 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1147,3 +1147,10 @@ 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
+ depends on VEXPRESS_CONFIG
+ help
+ Serial Power Controller driver for ARM Ltd. test chips.
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) += retu-mfd.o
obj-$(CONFIG_MFD_AS3711) += as3711.o
diff --git a/drivers/mfd/vexpress-spc.c b/drivers/mfd/vexpress-spc.c
new file mode 100644
index 000..f78257a
--- /dev/null
+++ b/drivers/mfd/vexpress-spc.c
@@ -0,0 +1,626 @@
+/*
+ * Versatile Express Serial Power Controller (SPC) support
+ *
+ * Copyright (C) 2013 ARM Ltd.
+ *
+ * Author(s): Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
+ *Achin Gupta achin.gu...@arm.com
+ *Lorenzo Pieralisi lorenzo.pieral...@arm.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.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even
[GIT PULL] ARM DT cpus/cpu bindings documentation updates
Hi Grant, Rob, please pull the cpus/cpu nodes bindings updates for ARM. This pull request completes my previous pull request: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/169110.html with the required changes for cpus/cpu nodes. Thanks a lot, Lorenzo The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75: Linux 3.10-rc2 (2013-05-20 14:37:38 -0700) are available in the git repository at: git://linux-arm.org/linux-2.6-lp.git dt-cpus-bindings for you to fetch changes up to 8e11f862d6a5491bb5f8ef73e13cfd66562e7be3: Documentation: devicetree: arm: cpus/cpu nodes bindings updates (2013-05-23 10:46:46 +0100) Lorenzo Pieralisi (1): Documentation: devicetree: arm: cpus/cpu nodes bindings updates Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[GIT PULL] ARM dts cpus/cpu nodes updates
Hi Arnd, Olof, please pull dts cpus/cpu node updates for all non-compliant ARM SoC/boards. Please notice I could not update all dts files since some of them are missing the cpus node altogether and I simply can not know the CPUs configuration for them, it is up to maintainers to patch the respective dts to comply with the latest specification. I have just sent a different pull request for related documentation: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170234.html dts updates comply with those Documentation updates. Thank you very much indeed, Lorenzo The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75: Linux 3.10-rc2 (2013-05-20 14:37:38 -0700) are available in the git repository at: git://linux-arm.org/linux-2.6-lp.git dts-cpus-updates for you to fetch changes up to 14c44aa541744d4cf06db89c27a1e6df293c64d5: ARM: dts: sunxi: cpus/cpu nodes dts updates (2013-05-23 10:45:22 +0100) Lorenzo Pieralisi (14): ARM: dts: am33xx: cpus/cpu nodes dts updates ARM: dts: armada-370-xp: cpus/cpu node dts updates ARM: dts: at91: cpus/cpu node dts updates ARM: dts: exynos5440: cpus/cpu nodes dts updates ARM: dts: imx: cpus/cpu nodes dts updates ARM: dts: lpc32xx: cpus/cpu nodes dts updates ARM: dts: omap: cpus/cpu nodes dts updates ARM: dts: picoxcell: cpus/cpu nodes dts updates ARM: dts: prima2: cpus/cpu node dts updates ARM: dts: pxa2xx: cpus/cpu nodes dts updates ARM: dts: r8a7740: cpus/cpu nodes dts updates ARM: dts: sh7372: cpus/cpu nodes dts updates ARM: dts: spear: cpus/cpu nodes dts updates ARM: dts: sunxi: cpus/cpu nodes dts updates arch/arm/boot/dts/am33xx.dtsi | 4 arch/arm/boot/dts/armada-370-xp.dtsi | 4 arch/arm/boot/dts/at91rm9200.dtsi | 6 +- arch/arm/boot/dts/at91sam9260.dtsi | 8 ++-- arch/arm/boot/dts/at91sam9263.dtsi | 8 ++-- arch/arm/boot/dts/at91sam9g45.dtsi | 8 ++-- arch/arm/boot/dts/at91sam9n12.dtsi | 8 ++-- arch/arm/boot/dts/at91sam9x5.dtsi | 8 ++-- arch/arm/boot/dts/exynos5440.dtsi | 4 arch/arm/boot/dts/imx23.dtsi | 8 ++-- arch/arm/boot/dts/imx28.dtsi | 8 ++-- arch/arm/boot/dts/imx6dl.dtsi | 2 ++ arch/arm/boot/dts/imx6q.dtsi | 4 arch/arm/boot/dts/lpc32xx.dtsi | 8 ++-- arch/arm/boot/dts/omap2.dtsi | 6 +- arch/arm/boot/dts/omap3.dtsi | 5 + arch/arm/boot/dts/omap4.dtsi | 7 +++ arch/arm/boot/dts/omap5.dtsi | 7 +++ arch/arm/boot/dts/picoxcell-pc3x2.dtsi | 8 arch/arm/boot/dts/picoxcell-pc3x3.dtsi | 8 arch/arm/boot/dts/prima2.dtsi | 2 ++ arch/arm/boot/dts/pxa2xx.dtsi | 7 +-- arch/arm/boot/dts/r8a7740.dtsi | 4 arch/arm/boot/dts/sama5d3.dtsi | 2 ++ arch/arm/boot/dts/sh7372.dtsi | 5 + arch/arm/boot/dts/spear13xx.dtsi | 2 ++ arch/arm/boot/dts/spear3xx.dtsi| 8 ++-- arch/arm/boot/dts/spear600.dtsi| 8 ++-- arch/arm/boot/dts/sun4i-a10.dtsi | 2 ++ arch/arm/boot/dts/sun5i-a13.dtsi | 2 ++ 30 files changed, 139 insertions(+), 32 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[GIT PULL] ARM cpu logical map init updates
Hi Russell, following the pull request for DT cpus/cpu bindings for arm/arm64 updates and relative dts files updates: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170234.html http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170242.html please pull the arm core code patches that enable the parsing of the new bindings. First two patches are two fixes, the first aimed also at the stable kernel, as marked in the commit log. Thank you very much indeed, Lorenzo The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75: Linux 3.10-rc2 (2013-05-20 14:37:38 -0700) are available in the git repository at: git://linux-arm.org/linux-2.6-lp.git dt-init-map-updates for you to fetch changes up to 1b4a70726dfafb82ebedc017bf02c20edaf5dd29: ARM: DT: kernel: DT cpus/cpu node bindings update (2013-05-23 12:35:51 +0100) Lorenzo Pieralisi (3): ARM: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodes ARM: kernel: fix __cpu_logical_map default initialization ARM: DT: kernel: DT cpus/cpu node bindings update arch/arm/include/asm/cputype.h | 2 + arch/arm/include/asm/smp_plat.h | 2 +- arch/arm/kernel/devtree.c | 149 arch/arm/kernel/setup.c | 2 +- 4 files changed, 95 insertions(+), 60 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3] drivers: bus: add ARM CCI support
On Mon, May 20, 2013 at 01:11:21PM +0100, Jon Medhurst (Tixy) wrote:
On Thu, 2013-05-09 at 11:34 +0100, Lorenzo Pieralisi wrote:
[...]
+static int __init cci_probe(void)
+{
+ struct cci_nb_ports const *cci_config;
+ int ret, i, nb_ace = 0, nb_ace_lite = 0;
+ struct device_node *np, *cp;
+ const char *match_str;
+ bool is_ace;
+
+ np = of_find_matching_node(NULL, arm_cci_matches);
+ if (!np)
+ return -ENODEV;
+
+ cci_config = of_match_node(arm_cci_matches, np)-data;
+ if (!cci_config)
+ return -ENODEV;
+
+ nb_cci_ports = cci_config-nb_ace + cci_config-nb_ace_lite;
+
+ ports = kcalloc(sizeof(*ports), nb_cci_ports, GFP_KERNEL);
+ if (!ports)
+ return -ENOMEM;
+
+ cci_ctrl_base = of_iomap(np, 0);
+
+ if (!cci_ctrl_base) {
+ WARN(1, unable to ioremap CCI ctrl\n);
+ ret = -ENXIO;
+ goto memalloc_err;
+ }
+
+ for_each_child_of_node(np, cp) {
+ i = nb_ace + nb_ace_lite;
+
+ if (i = nb_cci_ports)
+ break;
I know this is a bit late, but...
Would it not be best to check here that the node type is in fact
slave-if, that way if we add support in later versions for other node
types (e.g. for the PMU) then we don't cause backward compatibility
issues. I'm thinking here of the same concerns that Rob raised with
ARM: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodes
The node name, not type, but point is taken. I prefer to add a
compatible property to slave-if nodes (eg arm,cci-400-control-if),
I do not think that checking the node name is the standard way of doing
things in DT world.
Thoughts ?
Thanks,
Lorenzo
+ if (of_property_read_string(cp, interface-type,
+ match_str)) {
+ WARN(1, node %s missing interface-type property\n,
+ cp-full_name);
+ continue;
+ }
+
[..]
--
Tixy
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 14/18] ARM: dts: r8a7740: cpus/cpu nodes dts updates
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
Acked-by: Simon Horman horms+rene...@verge.net.au
---
arch/arm/boot/dts/r8a7740.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 798fa35..8a831e9 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -14,8 +14,12 @@
compatible = renesas,r8a7740;
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
+ reg = 0x0;
};
};
};
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 15/18] ARM: dts: sh7372: cpus/cpu nodes dts updates
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
Acked-by: Simon Horman horms+rene...@verge.net.au
---
arch/arm/boot/dts/sh7372.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
index 677fc60..7bf020e 100644
--- a/arch/arm/boot/dts/sh7372.dtsi
+++ b/arch/arm/boot/dts/sh7372.dtsi
@@ -14,8 +14,13 @@
compatible = renesas,sh7372;
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
cpu@0 {
compatible = arm,cortex-a8;
+ device_type = cpu;
+ reg = 0x0;
};
};
};
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 00/18] ARM: DT cpu bindings updates
This patchset is an update of a previous posting: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/165219.html v4 changes: - Replaced WARN* with pr_warn - Removed tmp_map in arm_dt_init_cpu_maps() - Rebased against 3.10-rc1 - Patched additional atmel and sunxi dts files - Removed BUG_ON on !bootcpu_valid, now flagged up as an error - Added code to reset invalid entries in cpu_logical_map after DT parsing v3 changes: - More dts fixes of in-kernel dts - Defined ARM v8 behaviour with different cpus node #address-cells - Added pre ARM11 processors suffixes in the cpu node compatible list - Reordered series - Reworded #address-cells definition - Added ARM v8 - cores running on AArch32 bindings example - Moved WARN* calls on one line to prevent grepping issues v2 changes: - Reworded DT cpu bindings - Split the set, with per-mach specific dts updates - Updated cpu node compatible string list - Defined behaviour of OS running on v8 in AArch32 The introduction of DT cpus/cpu bindings for ARM requires well established rules to enforce the reg property definition for 32-bit and 64-bit ARM processors, inclusive of legacy and current uniprocessor/SMP systems. ARM 64 bit architecture also requires dtb compiled for 64-bit configurations to be reused for kernels running in 32 bit mode, so the cpus/cpu bindings specification must be made compliant to cope with this configuration. Patch #1-#2 of this series are fixes and are included to have a clean patch series and should get reviewed and merged separately. Patch #3-18, along with some kernel fixes related to DT parsing function, update the cpu node bindings and in kernel dts files to cope with legacy, current and upcoming ARM systems. In-kernel device tree source files are updated to comply with the latest specification, so thorough testing is required in order to validate all changes on all affected ARM systems, in particular systems with exotic MPIDR configurations that are likely to break with the changes provided. Code relying on the reg property size to be 4-bytes must be updated so that dtbs compiled for 64-bit kernels can also be used to boot a 32-bit system. Lorenzo Pieralisi (18): ARM: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodes ARM: kernel: fix __cpu_logical_map default initialization Documentation: devicetree: arm: cpus/cpu nodes bindings updates ARM: dts: am33xx: cpus/cpu nodes dts updates ARM: dts: armada-370-xp: cpus/cpu node dts updates ARM: dts: at91: cpus/cpu node dts updates ARM: dts: exynos5440: cpus/cpu nodes dts updates ARM: dts: imx: cpus/cpu nodes dts updates ARM: dts: lpc32xx: cpus/cpu nodes dts updates ARM: dts: omap: cpus/cpu nodes dts updates ARM: dts: picoxcell: cpus/cpu nodes dts updates ARM: dts: prima2: cpus/cpu node dts updates ARM: dts: pxa2xx: cpus/cpu nodes dts updates ARM: dts: r8a7740: cpus/cpu nodes dts updates ARM: dts: sh7372: cpus/cpu nodes dts updates ARM: dts: spear: cpus/cpu nodes dts updates ARM: dts: sunxi: cpus/cpu nodes dts updates ARM: DT: kernel: DT cpus/cpu node bindings update Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- arch/arm/boot/dts/am33xx.dtsi | 4 + arch/arm/boot/dts/armada-370-xp.dtsi | 4 + arch/arm/boot/dts/at91rm9200.dtsi | 6 +- arch/arm/boot/dts/at91sam9260.dtsi | 8 +- arch/arm/boot/dts/at91sam9263.dtsi | 8 +- arch/arm/boot/dts/at91sam9g45.dtsi | 8 +- arch/arm/boot/dts/at91sam9n12.dtsi | 8 +- arch/arm/boot/dts/at91sam9x5.dtsi | 8 +- arch/arm/boot/dts/exynos5440.dtsi | 4 + arch/arm/boot/dts/imx23.dtsi | 8 +- arch/arm/boot/dts/imx28.dtsi | 8 +- arch/arm/boot/dts/imx6dl.dtsi | 2 + arch/arm/boot/dts/imx6q.dtsi | 4 + arch/arm/boot/dts/lpc32xx.dtsi | 8 +- arch/arm/boot/dts/omap2.dtsi | 6 +- arch/arm/boot/dts/omap3.dtsi | 5 + arch/arm/boot/dts/omap4.dtsi | 7 + arch/arm/boot/dts/omap5.dtsi | 7 + arch/arm/boot/dts/picoxcell-pc3x2.dtsi | 8 +- arch/arm/boot/dts/picoxcell-pc3x3.dtsi | 8 +- arch/arm/boot/dts/prima2.dtsi | 2 + arch/arm/boot/dts/pxa2xx.dtsi | 7 +- arch/arm/boot/dts/r8a7740.dtsi | 4 + arch/arm/boot/dts/sama5d3.dtsi | 2 + arch/arm/boot/dts/sh7372.dtsi | 5 + arch/arm/boot/dts/spear13xx.dtsi | 2 + arch/arm/boot/dts/spear3xx.dtsi| 8 +- arch/arm/boot/dts/spear600.dtsi| 8 +- arch/arm/boot/dts/sun4i-a10.dtsi | 2 + arch/arm/boot/dts/sun5i-a13.dtsi | 2 + arch/arm/include/asm/cputype.h | 2 + arch/arm/include/asm/smp_plat.h| 2 +- arch/arm
[RFC PATCH v4 07/18] ARM: dts: exynos5440: cpus/cpu nodes dts updates
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/exynos5440.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index f6b1c89..646677e 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -38,18 +38,22 @@
#size-cells = 0;
cpu@0 {
+ device_type = cpu;
compatible = arm,cortex-a15;
reg = 0;
};
cpu@1 {
+ device_type = cpu;
compatible = arm,cortex-a15;
reg = 1;
};
cpu@2 {
+ device_type = cpu;
compatible = arm,cortex-a15;
reg = 2;
};
cpu@3 {
+ device_type = cpu;
compatible = arm,cortex-a15;
reg = 3;
};
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 02/18] ARM: kernel: fix __cpu_logical_map default initialization
The __cpu_logical_map array is statically initialized to 0, which is a valid
MPIDR value. To prevent issues with the current implementation, this patch
defines an MPIDR_INVALID value, and statically initializes the
__cpu_logical_map[] array to it. Entries in the arm_dt_init_cpu_maps()
tmp_map array used to stash DT reg properties while parsing DT are initialized
with the MPIDR_INVALID value as well for consistency.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
CC: Will Deacon will.dea...@arm.com
---
arch/arm/include/asm/cputype.h | 2 ++
arch/arm/include/asm/smp_plat.h | 2 +-
arch/arm/kernel/devtree.c | 2 +-
arch/arm/kernel/setup.c | 2 +-
4 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 7652712..dba62cb 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -32,6 +32,8 @@
#define MPIDR_HWID_BITMASK 0xFF
+#define MPIDR_INVALID (~MPIDR_HWID_BITMASK)
+
#define MPIDR_LEVEL_BITS 8
#define MPIDR_LEVEL_MASK ((1 MPIDR_LEVEL_BITS) - 1)
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index aaa61b6..e789832 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -49,7 +49,7 @@ static inline int cache_ops_need_broadcast(void)
/*
* Logical CPU mapping.
*/
-extern int __cpu_logical_map[];
+extern u32 __cpu_logical_map[];
#define cpu_logical_map(cpu) __cpu_logical_map[cpu]
/*
* Retrieve logical cpu index corresponding to a given MPIDR[23:0]
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 904cad5..0905502 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -82,7 +82,7 @@ void __init arm_dt_init_cpu_maps(void)
u32 i, j, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
- u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = UINT_MAX };
+ u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
bool bootcpu_valid = false;
cpus = of_find_node_by_path(/cpus);
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 6ae71b7..eeac924 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -457,7 +457,7 @@ void notrace cpu_init(void)
: r14);
}
-int __cpu_logical_map[NR_CPUS];
+u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
void __init smp_setup_processor_id(void)
{
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 11/18] ARM: dts: picoxcell: cpus/cpu nodes dts updates
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/picoxcell-pc3x2.dtsi | 8
arch/arm/boot/dts/picoxcell-pc3x3.dtsi | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
b/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
index f0a8c20..533919e 100644
--- a/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
+++ b/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
@@ -18,13 +18,13 @@
#size-cells = 1;
cpus {
- #address-cells = 1;
+ #address-cells = 0;
#size-cells = 0;
- cpu@0 {
- compatible = arm,1176jz-s;
+ cpu {
+ compatible = arm,arm1176jz-s;
+ device_type = cpu;
clock-frequency = 4;
- reg = 0;
d-cache-line-size = 32;
d-cache-size = 32768;
i-cache-line-size = 32;
diff --git a/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
b/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
index daa962d..ab3e800 100644
--- a/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
+++ b/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
@@ -18,13 +18,13 @@
#size-cells = 1;
cpus {
- #address-cells = 1;
+ #address-cells = 0;
#size-cells = 0;
- cpu@0 {
- compatible = arm,1176jz-s;
+ cpu {
+ compatible = arm,arm1176jz-s;
+ device_type = cpu;
cpu-clock = arm_clk, cpu;
- reg = 0;
d-cache-line-size = 32;
d-cache-size = 32768;
i-cache-line-size = 32;
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 18/18] ARM: DT: kernel: DT cpus/cpu node bindings update
DT cpu map parsing code must be made compliant with the latest cpus/cpu
nodes bindings updates, hence this patch updates the arm_dt_init_cpu_maps()
function with checks and additional parsing rules.
Uniprocessor systems predating v7 do not parse the cpus node at all
since the reg property is meaningless on those systems.
Device trees for 64-bit systems can be taken as device tree input also
for 64-bit CPUs running in 32-bit mode. The code checks that the reg entries
are zeroed as required in the respective fields and detects automatically
the cpus node #address-cells value so that device tree written for
64-bit ARM platforms (that can have cpus node #address-cells == 2) can still
be taken as input. The correct device tree entries are to be set up by the
boot loader, kernel code just checks that device tree entries in the cpus
node are as expected for a 32-bit CPU (reg[63:24] == 0).
cpu node entries with invalid reg property or containing duplicates are
ignored and the device tree parsing is not stopped anymore when such
entries are encountered, the device tree cpu node entry is just skipped.
A device tree with cpu nodes missing the boot CPU MPIDR is considered
an error and the kernel flags this up as such to trigger firmware updates.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/devtree.c | 146 --
1 file changed, 88 insertions(+), 58 deletions(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 0905502..80d6cf24 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -23,6 +23,7 @@
#include asm/setup.h
#include asm/page.h
#include asm/smp_plat.h
+#include asm/system_info.h
#include asm/mach/arch.h
#include asm/mach-types.h
@@ -72,100 +73,129 @@ void __init arm_dt_memblock_reserve(void)
*/
void __init arm_dt_init_cpu_maps(void)
{
- /*
-* Temp logical map is initialized with UINT_MAX values that are
-* considered invalid logical map entries since the logical map must
-* contain a list of MPIDR[23:0] values where MPIDR[31:24] must
-* read as 0.
-*/
struct device_node *cpu, *cpus;
- u32 i, j, cpuidx = 1;
+ u32 i, ac, cpuidx = 1;
+ int len;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
- u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
bool bootcpu_valid = false;
cpus = of_find_node_by_path(/cpus);
- if (!cpus)
+ if (!cpus || ((cpu_architecture() CPU_ARCH_ARMv7) !is_smp()))
return;
+ if (of_property_read_u32(cpus, #address-cells, ac)) {
+ pr_warn(%s invalid #address-cells\n, cpus-full_name);
+ ac = of_n_addr_cells(cpus);
+ }
+ /*
+* The boot CPU knows its MPIDR and initialize it
+* to allow DT boot CPU detection.
+*/
+ cpu_logical_map(0) = mpidr;
+
for_each_child_of_node(cpus, cpu) {
- u32 hwid;
+ u64 hwid64;
+ u32 hwid32;
+ const __be32 *prop;
if (of_node_cmp(cpu-type, cpu))
continue;
pr_debug( * %s...\n, cpu-full_name);
/*
-* A device tree containing CPU nodes with missing reg
-* properties is considered invalid to build the
-* cpu_logical_map.
+* A CPU node with missing or wrong reg property is
+* considered invalid to build a cpu_logical_map entry.
*/
- if (of_property_read_u32(cpu, reg, hwid)) {
- pr_debug( * %s missing reg property\n,
-cpu-full_name);
- return;
+ prop = of_get_property(cpu, reg, len);
+ if (!prop || len (ac * sizeof(*prop))) {
+ pr_warn( * %s node missing/wrong reg property,
skipped\n,
+ cpu-full_name);
+ goto next;
}
/*
-* 8 MSBs must be set to 0 in the DT since the reg property
-* defines the MPIDR[23:0].
+* Always read reg as u64 value.
+* For dts with #address-cells == 1 hwid64[63:32]
+* will be set to 0 by of_read_number.
+* Toss away the top 32 bits and store value in hwid32.
*/
- if (hwid ~MPIDR_HWID_BITMASK)
- return;
-
+ hwid32 = hwid64 = of_read_number(prop, ac);
+ /*
+* hwid64[63:24] must be always be 0 since the reg
+* property defines the MPIDR[23:0] bits regardless
+* of the cpus node #address-cells value.
+*/
+ if (hwid64 ~MPIDR_HWID_BITMASK
[RFC PATCH v4 12/18] ARM: dts: prima2: cpus/cpu node dts updates
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
Acked-by: Barry Song baohua.s...@csr.com
---
arch/arm/boot/dts/prima2.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/prima2.dtsi b/arch/arm/boot/dts/prima2.dtsi
index 3329719..02edd89 100644
--- a/arch/arm/boot/dts/prima2.dtsi
+++ b/arch/arm/boot/dts/prima2.dtsi
@@ -18,6 +18,8 @@
#size-cells = 0;
cpu@0 {
+ compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 0x0;
d-cache-line-size = 32;
i-cache-line-size = 32;
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 13/18] ARM: dts: pxa2xx: cpus/cpu nodes dts updates
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/pxa2xx.dtsi | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi
index f18aad3..a5e90f0 100644
--- a/arch/arm/boot/dts/pxa2xx.dtsi
+++ b/arch/arm/boot/dts/pxa2xx.dtsi
@@ -23,8 +23,11 @@
};
cpus {
- cpu@0 {
- compatible = arm,xscale;
+ #address-cells = 0;
+ #size-cells = 0;
+ cpu {
+ compatible = marvell,xscale;
+ device_type = cpu;
};
};
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 06/18] ARM: dts: at91: cpus/cpu node dts updates
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
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/boot/dts/at91rm9200.dtsi | 6 +-
arch/arm/boot/dts/at91sam9260.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9263.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9g45.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9n12.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9x5.dtsi | 8 ++--
arch/arm/boot/dts/sama5d3.dtsi | 2 ++
7 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
b/arch/arm/boot/dts/at91rm9200.dtsi
index 5d3ed5a..0af879a 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -35,8 +35,12 @@
ssc2 = ssc2;
};
cpus {
- cpu@0 {
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
compatible = arm,arm920t;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index 70b5ccb..e1ba7ea 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -32,8 +32,12 @@
ssc0 = ssc0;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
b/arch/arm/boot/dts/at91sam9263.dtsi
index 94b58ab..fcd38f8 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -29,8 +29,12 @@
ssc1 = ssc1;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
b/arch/arm/boot/dts/at91sam9g45.dtsi
index bf18a73..479a062 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -35,8 +35,12 @@
ssc1 = ssc1;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi
b/arch/arm/boot/dts/at91sam9n12.dtsi
index 3de8e6d..01df681 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -31,8 +31,12 @@
ssc0 = ssc0;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
b/arch/arm/boot/dts/at91sam9x5.dtsi
index 1145ac3..6d8bd671 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -33,8 +33,12 @@
ssc0 = ssc0;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 2e643ea..5325371 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -36,7 +36,9 @@
};
cpus {
cpu@0 {
+ device_type = cpu;
compatible = arm,cortex-a5;
+ reg = 0x0;
};
};
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 09/18] ARM: dts: lpc32xx: cpus/cpu nodes dts updates
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/lpc32xx.dtsi | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 1582f48..3abebb7 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -18,8 +18,12 @@
interrupt-parent = mic;
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 04/18] ARM: dts: am33xx: cpus/cpu nodes dts updates
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/am33xx.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1460d9b..6827853 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -26,8 +26,12 @@
};
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
cpu@0 {
compatible = arm,cortex-a8;
+ device_type = cpu;
+ reg = 0;
/*
* To consider voltage drop between PMIC and SoC,
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 08/18] ARM: dts: imx: cpus/cpu nodes dts updates
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
Acked-by: Shawn Guo shawn@linaro.org
---
arch/arm/boot/dts/imx23.dtsi | 8 ++--
arch/arm/boot/dts/imx28.dtsi | 8 ++--
arch/arm/boot/dts/imx6dl.dtsi | 2 ++
arch/arm/boot/dts/imx6q.dtsi | 4
4 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 73fd7d0..587ceef 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -23,8 +23,12 @@
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 600f7cb..4c10a19 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -32,8 +32,12 @@
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 5bcdf3a..62dc781 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -18,12 +18,14 @@
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 0;
next-level-cache = L2;
};
cpu@1 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 1;
next-level-cache = L2;
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 21e6758..dc54a72 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -18,6 +18,7 @@
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 0;
next-level-cache = L2;
operating-points =
@@ -39,18 +40,21 @@
cpu@1 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 1;
next-level-cache = L2;
};
cpu@2 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 2;
next-level-cache = L2;
};
cpu@3 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 3;
next-level-cache = L2;
};
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v4 10/18] ARM: dts: omap: cpus/cpu nodes dts updates
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/omap2.dtsi | 6 +-
arch/arm/boot/dts/omap3.dtsi | 5 +
arch/arm/boot/dts/omap4.dtsi | 7 +++
arch/arm/boot/dts/omap5.dtsi | 7 +++
4 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 37aa748..4aac404 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -21,8 +21,12 @@
};
cpus {
- cpu@0 {
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
compatible = arm,arm1136jf-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 82a404d..ba05d7f 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -21,8 +21,13 @@
};
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
cpu@0 {
compatible = arm,cortex-a8;
+ device_type = cpu;
+ reg = 0x0;
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..33a9450 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -28,13 +28,20 @@
};
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
next-level-cache = L2;
+ reg = 0x0;
};
cpu@1 {
compatible = arm,cortex-a9;
+ device_type = cpu;
next-level-cache = L2;
+ reg = 0x1;
};
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3dd7ff8..35a6536 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -34,11 +34,18 @@
};
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
cpu@0 {
+ device_type = cpu;
compatible = arm,cortex-a15;
+ reg = 0x0;
};
cpu@1 {
+ device_type = cpu;
compatible = arm,cortex-a15;
+ reg = 0x1;
};
};
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[GIT PULL] ARM DT topology bindings
Hi Grant, Rob, since it looks like we reached agreement on DT topology bindings for ARM please pull the bindings documentation so that code relying on the topology to be published and set in stone can be released and can stabilize. The topology documentation relies on updates to the cpus/cpu nodes bindings that I have just posted: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/169083.html I do not know if you prefer to merge both documents at once or we can merge this document first waiting for the other patchset to get merged, please let me know. Thank you very much indeed, Lorenzo The following changes since commit f722406faae2d073cc1d01063d1123c35425939e: Linux 3.10-rc1 (2013-05-11 17:14:08 -0700) are available in the git repository at: git://linux-arm.org/linux-2.6-lp.git dt-topology for you to fetch changes up to 9cb1b6c8d59f09e51c87ac812b83d0350151ed3b: Documentation: DT: arm: define CPU topology bindings (2013-05-17 16:40:12 +0100) Lorenzo Pieralisi (1): Documentation: DT: arm: define CPU topology bindings Documentation/devicetree/bindings/arm/topology.txt | 492 + 1 file changed, 492 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/topology.txt ___ 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 05:31:18PM +0100, Rob Herring wrote:
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.
You are right, and I do not see any other solution if we want the
cpu-map node to live in the cpus node; at the time we added the cpus/cpu
bindings we thought that the cpus node's children would be restricted to cpu
nodes, and well, we are changing that, this is one of the consequences.
Yes, this patch should go to stable kernels, I will do that.
Lorenzo
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
[PATCH 3/3] ARM: kernel: fix __cpu_logical_map default initialization
For legacy reasons, the __cpu_logical_map array is initialized to 0.
On old pre-DT ARM platforms, smp_setup_processor_id() generates
__cpu_logical_map entries at boot before the number of possible CPUs is
set-up, with values that can be considered valid MPIDRs even if they are
not present in the system booting; this implies that the __cpu_logical_map[]
might end up containing MPIDR values that can be considered valid at logical
indexes corresponding to CPUs that are not marked as possible.
To prevent issues with the current implementation, this patch defines an
MPIDR_INVALID value, statically initializes the __cpu_logical_map[] array to it
and allows DT parsing code to overwrite values in the __cpu_logical_map array
that were erroneously set-up in smp_setup_processor_id().
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
CC: Will Deacon will.dea...@arm.com
---
arch/arm/include/asm/cputype.h | 2 ++
arch/arm/include/asm/smp_plat.h | 2 +-
arch/arm/kernel/devtree.c | 10 ++
arch/arm/kernel/setup.c | 2 +-
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 7652712..dba62cb 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -32,6 +32,8 @@
#define MPIDR_HWID_BITMASK 0xFF
+#define MPIDR_INVALID (~MPIDR_HWID_BITMASK)
+
#define MPIDR_LEVEL_BITS 8
#define MPIDR_LEVEL_MASK ((1 MPIDR_LEVEL_BITS) - 1)
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index aaa61b6..e789832 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -49,7 +49,7 @@ static inline int cache_ops_need_broadcast(void)
/*
* Logical CPU mapping.
*/
-extern int __cpu_logical_map[];
+extern u32 __cpu_logical_map[];
#define cpu_logical_map(cpu) __cpu_logical_map[cpu]
/*
* Retrieve logical cpu index corresponding to a given MPIDR[23:0]
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index d2293c0..08f012e 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -79,12 +79,12 @@ void __init arm_dt_init_cpu_maps(void)
* read as 0.
*/
static u32 tmp_map[NR_CPUS] __initdata = {
- [0 ... NR_CPUS-1] = UINT_MAX };
+ [0 ... NR_CPUS-1] = MPIDR_INVALID };
struct device_node *cpu, *cpus;
u32 i, j, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
-
bool bootcpu_valid = false;
+
cpus = of_find_node_by_path(/cpus);
if (!cpus)
@@ -160,11 +160,13 @@ void __init arm_dt_init_cpu_maps(void)
/*
* Since the boot CPU node contains proper data, and all nodes have
* a reg property, the DT CPU list can be considered valid and the
-* logical map created in smp_setup_processor_id() can be overridden
+* logical map created in smp_setup_processor_id() can be overridden,
+* inclusive of entries that must contain invalid MPIDRs
*/
+ memcpy(__cpu_logical_map, tmp_map,
+ nr_cpu_ids * sizeof(tmp_map[0]));
for (i = 0; i cpuidx; i++) {
set_cpu_possible(i, true);
- cpu_logical_map(i) = tmp_map[i];
pr_debug(cpu logical map 0x%x\n, cpu_logical_map(i));
}
}
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 6ae71b7..eeac924 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -457,7 +457,7 @@ void notrace cpu_init(void)
: r14);
}
-int __cpu_logical_map[NR_CPUS];
+u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
void __init smp_setup_processor_id(void)
{
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] ARM: DT: kernel: move temporary cpu map stack array to static data
As the number of CPUs increase, the temporary array allocated on the
stack in arm_dt_init_cpu_maps() can become too big and trigger stack
issues.
This patch moves the allocated memory to static __initdata so that stack
data is not used anymore to allocate the temporary array.
Memory is marked as __initdata since it need not be persistent after boot.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/devtree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5af04f6..3d652e4f 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -78,11 +78,12 @@ void __init arm_dt_init_cpu_maps(void)
* contain a list of MPIDR[23:0] values where MPIDR[31:24] must
* read as 0.
*/
+ static u32 tmp_map[NR_CPUS] __initdata = {
+ [0 ... NR_CPUS-1] = UINT_MAX };
struct device_node *cpu, *cpus;
u32 i, j, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
- u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = UINT_MAX };
bool bootcpu_valid = false;
cpus = of_find_node_by_path(/cpus);
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/3] ARM: kernel: cpu_logical_map misc fixes
Hi Russell, Rob, this series contains simple fixes/improvements related to the DT cpu_logical_map initialization code. I would like to get these patches in in order to have a stable base on top of which I can send the DT topology bindings and cpu_logical_map bindings/parsing code updates for arm and arm64. Thank you very much, Lorenzo Lorenzo Pieralisi (3): ARM: DT: kernel: move temporary cpu map stack array to static data ARM: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodes ARM: kernel: fix __cpu_logical_map default initialization arch/arm/include/asm/cputype.h | 2 ++ arch/arm/include/asm/smp_plat.h | 2 +- arch/arm/kernel/devtree.c | 14 ++ arch/arm/kernel/setup.c | 2 +- 4 files changed, 14 insertions(+), 6 deletions(-) -- 1.8.2.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: kernel: fix __cpu_logical_map default initialization
On Thu, May 16, 2013 at 04:50:38PM +0100, Will Deacon wrote:
On Thu, May 16, 2013 at 04:34:07PM +0100, Lorenzo Pieralisi wrote:
For legacy reasons, the __cpu_logical_map array is initialized to 0.
On old pre-DT ARM platforms, smp_setup_processor_id() generates
__cpu_logical_map entries at boot before the number of possible CPUs is
set-up, with values that can be considered valid MPIDRs even if they are
not present in the system booting; this implies that the __cpu_logical_map[]
might end up containing MPIDR values that can be considered valid at logical
indexes corresponding to CPUs that are not marked as possible.
To prevent issues with the current implementation, this patch defines an
MPIDR_INVALID value, statically initializes the __cpu_logical_map[] array
to it
and allows DT parsing code to overwrite values in the __cpu_logical_map
array
that were erroneously set-up in smp_setup_processor_id().
What issues have you actually hit with this?
I have not hit any, I just thought it would be proper to have the
cpu_logical_map filled with only valid (ie present in HW) MPIDRs (and
by default initialized with MPIDR_INVALID, not 0s which are valid MPIDRs).
I wrote the patch while coding the MPIDR to logical CPU reverse look-up
for the CCI driver and noticed that, if for any reason we do not
constrain the look-up to possible cpus, we might get a logical index
for a CPU that does not exist since smp_setup_processor_id() initializes
the cpu_logical_map up to nr_cpu_ids, with values that might well be
real MPIDRs (but not present in HW).
If we pass an mpidr value to get_logical_index(), that function must not
return a logical index for an MPIDR that does not exist in HW. This can
happen with current code (but I do not think anyone will ever call
get_logical_index() with a mpidr value that has not been read from a CPU
coprocessor, so what I am saying is purely hypothetical).
True, we might check the return value is actually a CPU marked as possible,
provided that check is safe to carry out in low-level PM code where it is
likely to be used.
Overall it can be overkill, granted, it was just meant to clean-up the code,
no more than that.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
CC: Will Deacon will.dea...@arm.com
---
arch/arm/include/asm/cputype.h | 2 ++
arch/arm/include/asm/smp_plat.h | 2 +-
arch/arm/kernel/devtree.c | 10 ++
arch/arm/kernel/setup.c | 2 +-
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 7652712..dba62cb 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -32,6 +32,8 @@
#define MPIDR_HWID_BITMASK 0xFF
+#define MPIDR_INVALID (~MPIDR_HWID_BITMASK)
+
#define MPIDR_LEVEL_BITS 8
#define MPIDR_LEVEL_MASK ((1 MPIDR_LEVEL_BITS) - 1)
diff --git a/arch/arm/include/asm/smp_plat.h
b/arch/arm/include/asm/smp_plat.h
index aaa61b6..e789832 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -49,7 +49,7 @@ static inline int cache_ops_need_broadcast(void)
/*
* Logical CPU mapping.
*/
-extern int __cpu_logical_map[];
+extern u32 __cpu_logical_map[];
#define cpu_logical_map(cpu) __cpu_logical_map[cpu]
/*
* Retrieve logical cpu index corresponding to a given MPIDR[23:0]
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index d2293c0..08f012e 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -79,12 +79,12 @@ void __init arm_dt_init_cpu_maps(void)
* read as 0.
*/
static u32 tmp_map[NR_CPUS] __initdata = {
- [0 ... NR_CPUS-1] = UINT_MAX };
+ [0 ... NR_CPUS-1] = MPIDR_INVALID };
struct device_node *cpu, *cpus;
u32 i, j, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
-
bool bootcpu_valid = false;
+
Random whitespace change.
Gah, sorry.
Thanks for having a look,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3] drivers: bus: add ARM CCI support
On Tue, May 14, 2013 at 11:21:32PM +0100, Nicolas Pitre wrote: On Tue, 14 May 2013, Javi Merino wrote: On Thu, May 09, 2013 at 11:34:00AM +0100, Lorenzo Pieralisi wrote: +static inline void init_cpu_port(struct cpu_port *port, u32 index, u32 mpidr) The mpidr should be u64. Why? Since on arm64 MPIDR_EL1 size is 64 bits, we need the driver to work on both arm and arm64. Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3] drivers: bus: add ARM CCI support
On Wed, May 15, 2013 at 03:51:43PM +0100, Nicolas Pitre wrote: On Wed, 15 May 2013, Lorenzo Pieralisi wrote: On Tue, May 14, 2013 at 11:21:32PM +0100, Nicolas Pitre wrote: On Tue, 14 May 2013, Javi Merino wrote: On Thu, May 09, 2013 at 11:34:00AM +0100, Lorenzo Pieralisi wrote: +static inline void init_cpu_port(struct cpu_port *port, u32 index, u32 mpidr) The mpidr should be u64. Why? Since on arm64 MPIDR_EL1 size is 64 bits, we need the driver to work on both arm and arm64. OK. Are you OK for me to carry this patch in the series for MCPM support on RTSM? I would like to send it to arm-soc ASAP. Absolutely, I will apply the latest fixes and send the updated version to you for arm-soc inclusion today. Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 05/17] ARM: dts: at91: cpus/cpu node dts updates
On Tue, May 14, 2013 at 10:20:00AM +0100, Nicolas Ferre wrote:
On 29/04/2013 11:54, Nicolas Ferre :
On 04/24/2013 07:28 PM, Lorenzo Pieralisi :
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
With changes in compatible string... ok then.
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Now that our Cortex-A5 is in mainline, can you please update the:
arch/arm/boot/dts/sama5d3.dtsi
as-well?
I will, no problems.
Thanks, best regards,
Cheers,
Lorenzo
---
arch/arm/boot/dts/at91rm9200.dtsi | 6 +-
arch/arm/boot/dts/at91sam9260.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9263.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9g45.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9n12.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9x5.dtsi | 8 ++--
6 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
b/arch/arm/boot/dts/at91rm9200.dtsi
index b0268a5..f16b3d4 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -34,8 +34,12 @@
ssc2 = ssc2;
};
cpus {
- cpu@0 {
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
compatible = arm,arm920t;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index cb7bcc5..c4eeef7 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -32,8 +32,12 @@
ssc0 = ssc0;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
b/arch/arm/boot/dts/at91sam9263.dtsi
index 271d4de..f3b5c2a 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -29,8 +29,12 @@
ssc1 = ssc1;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
b/arch/arm/boot/dts/at91sam9g45.dtsi
index 6b1d4ca..6c18bd3 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -35,8 +35,12 @@
ssc1 = ssc1;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi
b/arch/arm/boot/dts/at91sam9n12.dtsi
index 7750f98..c3b11af 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -31,8 +31,12 @@
ssc0 = ssc0;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
b/arch/arm/boot/dts/at91sam9x5.dtsi
index aa98e64..6c39d0f 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -33,8 +33,12 @@
ssc0 = ssc0;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
--
Nicolas Ferre
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3] ARM CCI support
This patch is an updated of a previous posting: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/166173.html main changes in v3: - Changed init to early_initcall and added code to deal with init calls ordering issues - Removed platform driver infrastructure, replaced with DT layer - Added missing pointer flushing - Removed useless includes - Implemented MPIDR stashing - Added basic functions to initialize and carry out CPU ports look-ups - fixed !CONFIG_ARM_CCI compile issue main changes in v2: - Changed way masters are connected to CCI slave ports in DT # now every master has to declare a phandle to a CCI control IF - Fixed warning split on different lines - Added comments to disable function - Moved driver to non-hotpluggable API (registration and probing bundled together) - Upgraded cache flushing API - Reworked the driver to use devm primitives - Added disable/enable by index API - Fixed port enable and added macro for snoops/DVM control ARM multi-cluster systems rely on the cache coherent interconnect (CCI) to support inter-cluster cache coherency and distributed virtual memory (DVM) messaging. CCI kernel driver requires tweaks to the kernel and device tree bindings in order to link specific resources to groups of logical CPUs so that resources can be associated to specific cpu sets (slave ports can be associated with a set of CPUs which are part of a cluster). CCI slave ports must be associated with specific bus masters in the system so that whenever a CCI operation is requested for a specific master (ie disable its CCI slave port, read its PMU counters) the association can be carried out dynamically in the OS through dynamically built data structures. Bus masters in the system connected to CCI ports must define device tree properties, as described in the documentation contained in the patch, in order to explicitly connect ports and allow the OS to build up the required data structures. The current CCI DT bindings define the CCI address space as the same one as the root device tree node, which means that the CCI bus can address the entire address space visible to CPUs. Lorenzo Pieralisi (1): drivers: bus: add ARM CCI support Documentation/devicetree/bindings/arm/cci.txt | 161 ++ drivers/bus/Kconfig | 7 + drivers/bus/Makefile | 2 + drivers/bus/arm-cci.c | 420 ++ include/linux/arm-cci.h | 61 5 files changed, 651 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cci.txt create mode 100644 drivers/bus/arm-cci.c create mode 100644 include/linux/arm-cci.h -- 1.8.2.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3] drivers: bus: add ARM CCI support
On ARM multi-cluster systems coherency between cores running on
different clusters is managed by the cache-coherent interconnect (CCI).
It allows broadcasting of TLB invalidates and memory barriers and it
guarantees cache coherency at system level through snooping of slave
interfaces connected to it.
This patch enables the basic infrastructure required in Linux to handle and
programme the CCI component.
Non-local variables used by the CCI management functions called by power
down function calls after disabling the cache must be flushed out to main
memory in advance, otherwise incoherency of those values may occur if they
are sitting in the cache of some other CPU when power down functions
execute. Driver code ensures that relevant data structures are flushed
from inner and outer caches after the driver probe is completed.
CCI slave port resources are linked to set of CPUs through bus masters
phandle properties that link the interface resources to masters node in
the device tree.
Documentation describing the CCI DT bindings is provided with the patch.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
Documentation/devicetree/bindings/arm/cci.txt | 161 ++
drivers/bus/Kconfig | 7 +
drivers/bus/Makefile | 2 +
drivers/bus/arm-cci.c | 420 ++
include/linux/arm-cci.h | 61
5 files changed, 651 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/cci.txt
create mode 100644 drivers/bus/arm-cci.c
create mode 100644 include/linux/arm-cci.h
diff --git a/Documentation/devicetree/bindings/arm/cci.txt
b/Documentation/devicetree/bindings/arm/cci.txt
new file mode 100644
index 000..384b460
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cci.txt
@@ -0,0 +1,161 @@
+===
+ARM CCI cache coherent interconnect binding description
+===
+
+ARM multi-cluster systems maintain intra-cluster coherency through a
+cache coherent interconnect (CCI) that is capable of monitoring bus
+transactions and manage coherency, TLB invalidations and memory barriers.
+
+It allows snooping and distributed virtual memory message broadcast across
+clusters, through memory mapped interface, with a global control register
+space and multiple sets of interface control registers, one per slave
+interface.
+
+Bindings for the CCI node follow the ePAPR standard, available from:
+
+www.power.org/documentation/epapr-version-1-1/
+
+with the addition of the bindings described in this document which are
+specific to ARM.
+
+* CCI interconnect node
+
+ Description: Describes a CCI cache coherent Interconnect component
+
+ Node name must be cci.
+ Node's parent must be the root node /, and the address space visible
+ through the CCI interconnect is the same as the one seen from the
+ root node (ie from CPUs perspective as per DT standard).
+ Every CCI node has to define the following properties:
+
+ - compatible
+ Usage: required
+ Value type: string
+ Definition: must be set to
+ arm,cci-400
+
+ - reg
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: A standard property. Specifies base physical
+ address of CCI control registers common to all
+ interfaces.
+
+ - ranges:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: A standard property. Follow rules in the ePAPR for
+ hierarchical bus addressing. CCI interfaces
+ addresses refer to the parent node addressing
+ scheme to declare their register bases.
+
+ CCI interconnect node can define the following child nodes:
+
+ - CCI control interface nodes
+
+ Node name must be slave-if.
+ Parent node must be CCI interconnect node.
+
+ A CCI interface node must contain the following properties:
+ - interface-type:
+ Usage: required
+ Value type: string
+ Definition: must be set to one of {ace, ace-lite}
+ depending on the interface type the node
+ represents.
+
+ - reg:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: the base address and size of the
+ corresponding interface programming
+ registers.
+
+* CCI interconnect bus masters
+
+ Description: masters in the device tree connected to a CCI port
Re: [RFC PATCH v2] drivers: bus: add ARM CCI support
On Fri, May 03, 2013 at 04:17:07PM +0100, Javi Merino wrote: Hi Lorenzo, On Wed, May 01, 2013 at 05:18:28PM +0100, Lorenzo Pieralisi wrote: On ARM multi-cluster systems coherency between cores running on different clusters is managed by the cache-coherent interconnect (CCI). It allows broadcasting of TLB invalidates and memory barriers and it guarantees cache coherency at system level through snooping of slave interfaces connected to it. This patch enables the basic infrastructure required in Linux to handle and programme the CCI component. Non-local variables used by the CCI management functions called by power down function calls after disabling the cache must be flushed out to main memory in advance, otherwise incoherency of those values may occur if they are sitting in the cache of some other CPU when power down functions execute. Driver code ensures that relevant data structures are flushed from inner and outer caches after the driver probe is completed. CCI slave port resources are linked to set of CPUs through bus masters phandle properties that link the interface resources to masters node in the device tree. Documentation describing the CCI DT bindings is provided with the patch. Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- [...] diff --git a/include/linux/arm-cci.h b/include/linux/arm-cci.h new file mode 100644 index 000..0e70942 --- /dev/null +++ b/include/linux/arm-cci.h @@ -0,0 +1,59 @@ +/* + * CCI cache coherent interconnect support + * + * Copyright (C) 2013 ARM Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __LINUX_ARM_CCI_H +#define __LINUX_ARM_CCI_H + +#include linux/errno.h +#include linux/types.h + +struct device_node; + +#ifdef CONFIG_ARM_CCI +extern int cci_ace_get_port(struct device_node *dn); +extern int cci_disable_port_by_cpu(u64 mpidr); +extern int __cci_control_port_by_device(struct device_node *dn, bool enable); +extern int __cci_control_port_by_index(u32 port, bool enable); +#else +static inline int cci_ace_get_port(struct device_node *dn, bool cpu) Builds with !CONFIG_ARM_CCI fail because this definition of cci_ace_get_port() takes two arguments whereas the one for CONFIG_ARM_CCI takes only one. Yes, sorry, I missed that while refactoring the interface. Thanks, Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2] drivers: bus: add ARM CCI support
On Mon, May 06, 2013 at 04:05:28PM +0100, Nicolas Pitre wrote:
Review comments below.
Thanks Nico.
On Wed, 1 May 2013, Lorenzo Pieralisi wrote:
index 000..fb9e8e0
--- /dev/null
+++ b/drivers/bus/arm-cci.c
@@ -0,0 +1,372 @@
+/*
+ * CCI cache coherent interconnect driver
+ *
+ * Copyright (C) 2013 ARM Ltd.
+ * Author: Lorenzo Pieralisi lorenzo.pieral...@arm.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.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/arm-cci.h
+#include linux/device.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include asm/cacheflush.h
+#include asm/dt_affinity.h
+#include asm/outercache.h
You don't need this include anymore.
True.
+#include asm/smp_plat.h
+
+#define DRIVER_NAME CCI
+
+#define CCI_PORT_CTRL0x0
+#define CCI_CTRL_STATUS 0xc
+
+#define CCI_ENABLE_SNOOP_REQ 0x1
+#define CCI_ENABLE_DVM_REQ 0x2
+#define CCI_ENABLE_REQ (CCI_ENABLE_SNOOP_REQ |
CCI_ENABLE_DVM_REQ)
+
+struct cci_nb_ports {
+ unsigned int nb_ace;
+ unsigned int nb_ace_lite;
+};
+
+enum cci_ace_port_type {
+ ACE_INVALID_PORT = 0x0,
+ ACE_PORT,
+ ACE_LITE_PORT,
+};
+
+struct cci_ace_port {
+ void __iomem *base;
+ int type;
You could use: enum cci_ace_port_type type;
Ok.
[...]
+ * Disabling a CCI port for a CPU implies disabling the CCI port
+ * controlling that CPU cluster. Code disabling CPU CCI ports
+ * must make sure that the CPU running the code is the last active CPU
+ * in the cluster ie all other CPUs are quiescent in a low power state.
+ */
+int notrace cci_disable_port_by_cpu(u64 mpidr)
+{
+ int cpu = get_logical_index(mpidr MPIDR_HWID_BITMASK);
This is dangerous. Same reasoning for not using cpu_relax() above
should apply here too. Better avoid any external calls and cache things
locally by marking cpu_port[] entries with MPIDR values directly.
Ok, I will stash them at boot.
Furthermore, get_logical_index() might not be reliable when the cache or
local coherency is off. We'd have to flush all the data it might access
to RAM just like it is done for our very own data structures in this
code, but starting doing that outside of this driver would become rather
ugly.
That's correct.
+ if (cpu 0 || cpu_port[cpu] == INVALID_PORT_IDX)
+ return -ENODEV;
+ cci_port_control(cpu_port[cpu], false);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(cci_disable_port_by_cpu);
+
+/*
+ * __cci_control_port_by_device()
+ * @dn = device node pointer of the device whose CCI port should be
+ * controlled
+ * @enable = if true enables the port, if false disables it
+ * Returns:
+ * 0 on success
+ * -ENODEV on port look-up failure
+ */
+int notrace __cci_control_port_by_device(struct device_node *dn, bool
enable)
+{
+ int port;
+
+ if (!dn)
+ return -ENODEV;
+
+ port = __cci_ace_get_port(dn, ACE_LITE_PORT);
+ if (WARN_ONCE(port 0, node %s ACE lite port look-up failure\n,
+ dn-full_name))
+ return -ENODEV;
+ cci_port_control(port, enable);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(__cci_control_port_by_device);
+
+/*
+ * __cci_control_port_by_index()
+ * @port = port index previously retrieved with cci_ace_get_port()
+ * @enable = if true enables the port, if false disables it
+ * Returns:
+ * 0 on success
+ * -ENODEV on port index out of range
+ * -EPERM if operation carried out on an ACE PORT
+ */
+int notrace __cci_control_port_by_index(u32 port, bool enable)
+{
+ if (port = nb_cci_ports || ports[port].type == ACE_INVALID_PORT)
+ return -ENODEV;
+ /*
+ * CCI control for ports connected to CPUS is extremely fragile
+ * and must be made to go through a specific and controlled
+ * interface (ie cci_disable_port_by_cpu(); control by general purpose
+ * indexing is therefore disabled for ACE ports.
+ */
+ if (ports[port].type == ACE_PORT)
+ return -EPERM;
+
+ cci_port_control(port, enable);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(__cci_control_port_by_index);
+
+static const struct cci_nb_ports cci400_ports = {
+ .nb_ace = 2,
+ .nb_ace_lite = 3
Re: [RFC PATCH v2 13/13] ARM: DT: kernel: DT cpu node bindings update
On Thu, May 02, 2013 at 07:31:05PM +0100, Stephen Warren wrote: On 04/22/2013 09:27 AM, Lorenzo Pieralisi 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. Since I'm late reviewing this due to vacation, I imagine this has been applied by now. But for the record, the structure of the DT binding documentation in this version does look much better to me, and addresses any concerns I had with v1. It is not merged yet, but hopefully it can be as soon as the merge window closes, I just need to update some bits and bobs after rebasing, to take into account changes that got merged this cycle. I will repost a, hopefully, final series as soon as the merge window closes. Thanks, Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2] ARM CCI support
This patch is an updated of a previous posting: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/162539.html Patch depends on commit: id: 0c91e7e07ebf08092bf8e28d8cd8d420732fc716 ARM: cacheflush: add synchronization helpers for mixed cache state accesses in RMK tree: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git branch: devel-stable main changes in v2: - Changed way masters are connected to CCI slave ports in DT # now every master has to declare a phandle to a CCI control IF - Fixed warning split on different lines - Added comments to disable function - Moved driver to non-hotpluggable API (registration and probing bundled together) - Upgraded cache flushing API - Reworked the driver to use devm primitives - Added disable/enable by index API - Fixed port enable and added macro for snoops/DVM control ARM multi-cluster systems rely on the cache coherent interconnect (CCI) to support inter-cluster cache coherency and distributed virtual memory (DVM) messaging. CCI kernel driver requires tweaks to the kernel and device tree bindings in order to link specific resources to groups of logical CPUs so that resources can be associated to specific cpu sets (slave ports can be associated with a set of CPUs which are part of a cluster). CCI slave ports must be associated with specific bus masters in the system so that whenever a CCI operation is requested for a specific master (ie disable its CCI slave port, read its PMU counters) the association can be carried out dynamically in the OS through dynamically built data structures. Bus masters in the system connected to CCI ports must define device tree properties, as described in the documentation contained in the patch, in order to explicitly connect ports and allow the OS to build up the required data structures. The current CCI DT bindings define the CCI address space as the same one as the root device tree node, which means that the CCI bus can address the entire address space visible to CPUs. Lorenzo Pieralisi (1): drivers: bus: add ARM CCI support Documentation/devicetree/bindings/arm/cci.txt | 161 +++ drivers/bus/Kconfig | 7 + drivers/bus/Makefile | 2 + drivers/bus/arm-cci.c | 372 ++ include/linux/arm-cci.h | 59 5 files changed, 601 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cci.txt create mode 100644 drivers/bus/arm-cci.c create mode 100644 include/linux/arm-cci.h -- 1.8.2.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2] drivers: bus: add ARM CCI support
On ARM multi-cluster systems coherency between cores running on
different clusters is managed by the cache-coherent interconnect (CCI).
It allows broadcasting of TLB invalidates and memory barriers and it
guarantees cache coherency at system level through snooping of slave
interfaces connected to it.
This patch enables the basic infrastructure required in Linux to handle and
programme the CCI component.
Non-local variables used by the CCI management functions called by power
down function calls after disabling the cache must be flushed out to main
memory in advance, otherwise incoherency of those values may occur if they
are sitting in the cache of some other CPU when power down functions
execute. Driver code ensures that relevant data structures are flushed
from inner and outer caches after the driver probe is completed.
CCI slave port resources are linked to set of CPUs through bus masters
phandle properties that link the interface resources to masters node in
the device tree.
Documentation describing the CCI DT bindings is provided with the patch.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
Documentation/devicetree/bindings/arm/cci.txt | 161 +++
drivers/bus/Kconfig | 7 +
drivers/bus/Makefile | 2 +
drivers/bus/arm-cci.c | 372 ++
include/linux/arm-cci.h | 59
5 files changed, 601 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/cci.txt
create mode 100644 drivers/bus/arm-cci.c
create mode 100644 include/linux/arm-cci.h
diff --git a/Documentation/devicetree/bindings/arm/cci.txt
b/Documentation/devicetree/bindings/arm/cci.txt
new file mode 100644
index 000..384b460
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cci.txt
@@ -0,0 +1,161 @@
+===
+ARM CCI cache coherent interconnect binding description
+===
+
+ARM multi-cluster systems maintain intra-cluster coherency through a
+cache coherent interconnect (CCI) that is capable of monitoring bus
+transactions and manage coherency, TLB invalidations and memory barriers.
+
+It allows snooping and distributed virtual memory message broadcast across
+clusters, through memory mapped interface, with a global control register
+space and multiple sets of interface control registers, one per slave
+interface.
+
+Bindings for the CCI node follow the ePAPR standard, available from:
+
+www.power.org/documentation/epapr-version-1-1/
+
+with the addition of the bindings described in this document which are
+specific to ARM.
+
+* CCI interconnect node
+
+ Description: Describes a CCI cache coherent Interconnect component
+
+ Node name must be cci.
+ Node's parent must be the root node /, and the address space visible
+ through the CCI interconnect is the same as the one seen from the
+ root node (ie from CPUs perspective as per DT standard).
+ Every CCI node has to define the following properties:
+
+ - compatible
+ Usage: required
+ Value type: string
+ Definition: must be set to
+ arm,cci-400
+
+ - reg
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: A standard property. Specifies base physical
+ address of CCI control registers common to all
+ interfaces.
+
+ - ranges:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: A standard property. Follow rules in the ePAPR for
+ hierarchical bus addressing. CCI interfaces
+ addresses refer to the parent node addressing
+ scheme to declare their register bases.
+
+ CCI interconnect node can define the following child nodes:
+
+ - CCI control interface nodes
+
+ Node name must be slave-if.
+ Parent node must be CCI interconnect node.
+
+ A CCI interface node must contain the following properties:
+ - interface-type:
+ Usage: required
+ Value type: string
+ Definition: must be set to one of {ace, ace-lite}
+ depending on the interface type the node
+ represents.
+
+ - reg:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: the base address and size of the
+ corresponding interface programming
+ registers.
+
+* CCI interconnect bus masters
+
+ Description: masters in the device tree connected to a CCI port
Re: [RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Fri, Apr 26, 2013 at 03:51:10AM +0100, Rob Herring wrote: 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 should add it, at least for ARM v8. I don't think the ePAPR spin-table definition is sufficient for ARM. How do you define wake up by SGI or sev instruction. I think Will described the wfe/sev mechanism in: Documentation/arm64/booting.txt and the ePAPR does the same in 5.5.2.2/5.5.2.3. Since this is a document describing cpus/cpu nodes bindings I assume that description does not belong here. Question is: do we need to specify an ARM implementation specific enable-method to describe SGI/sev wake-up (ePAPR 5.5.3) ? + # On ARM 32-bit systems or ARM v8 systems running + the OS in AArch32 this property is prohibited. Why? Because if we define it optional with no possible set of values basically it can be whatever string. I could define it optional with the same allowed values as ARM v8 even if it is currently ignored, at least in Linux, until PSCI implementations get merged. Thanks, Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 07/17] ARM: dts: imx: cpus/cpu nodes dts updates
On Thu, Apr 25, 2013 at 06:44:28AM +0100, Shawn Guo wrote:
On Wed, Apr 24, 2013 at 06:28:12PM +0100, 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/imx23.dtsi | 8 ++--
arch/arm/boot/dts/imx28.dtsi | 8 ++--
arch/arm/boot/dts/imx6dl.dtsi | 2 ++
arch/arm/boot/dts/imx6q.dtsi | 1 +
4 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 56afcf4..0aae18b 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -23,8 +23,12 @@
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..07f131fc 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -32,8 +32,12 @@
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 63fafe2..b76d85e 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -16,12 +16,14 @@
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 0;
next-level-cache = L2;
};
cpu@1 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 1;
next-level-cache = L2;
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index cba021e..65c1b62 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -17,6 +17,7 @@
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
Shouldn't this line be added for cpu@1, cpu@2 and cpu@3 too? Other than
that,
Yes, you are right, fixed. Thanks for reviewing.
Lorenzo
Acked-by: Shawn Guo shawn@linaro.org
reg = 0;
next-level-cache = L2;
operating-points =
--
1.7.12
___
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 08:58:20PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: [...] + - 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 the common name is arm926ejs / arm1026ejs co The TRMs names are arm926ej-s/arm1026ej-s/... and other machs are using that nomenclature already in dts files, time to consolidate. Lorenzo ___ 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 Tue, Apr 23, 2013 at 08:52:59PM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 14:53 Tue 23 Apr , Lorenzo Pieralisi wrote:
On Tue, Apr 23, 2013 at 02:11:46PM +0100, Rob Herring wrote:
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.
IMHO compatibility is already broken. There are a number of dts in the
kernel missing cpus and cpu nodes, others with cpu nodes missing
device_type = cpu, missing cpu nodes compatible properties and the list
goes on and on. Those files got merged in the kernel before bindings were
properly defined for ARM so at that point in time the only reference was the
ePAPR and still, it was not followed (eg my broken patch above fails to add
device_type = cpu to the cpu node, should I change the documentation
(ePAPR)
to make the dts above compliant ? I do not think so, I reckon we should fix
all dts and force them to comply with the ePAPR and the in-kernel bindings).
If we do not set in stone the bindings and draw a line now, this stuff will
go wild, it is already in a state that I do not like much.
The reason we are patching the compatible property above is to avoid having
compatible properties containing suffixes for CPUs, we do not deem that
necessary, see:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/145305.html
That's just my opinion, open to change it to find a proper solution to this
issue as long as we make progress.
I do not agree when you set the compatible you need to be preceise the cpu is
a arm926ejs not a arm926
I updated the bindings with all processor variants so that we will all
be happy again (I hope). My comments still stand though and these dts need
patching, I am posting the required changes in v3.
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 01/17] ARM: DT: kernel: move temporary cpu map stack array to static data
As the number of CPUs increase, the temporary array allocated on the
stack in arm_dt_init_cpu_maps() can become too big and trigger stack
issues.
This patch moves the allocated memory to static __initdata so that stack
data is not used anymore to allocate the temporary array.
Memory is marked as __initdata since it need not be persistent after boot.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/devtree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..f149217 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -78,11 +78,12 @@ void __init arm_dt_init_cpu_maps(void)
* contain a list of MPIDR[23:0] values where MPIDR[31:24] must
* read as 0.
*/
+ static u32 tmp_map[NR_CPUS] __initdata = {
+ [0 ... NR_CPUS-1] = UINT_MAX };
struct device_node *cpu, *cpus;
u32 i, j, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
- u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = UINT_MAX };
bool bootcpu_valid = false;
cpus = of_find_node_by_path(/cpus);
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 00/17] ARM: DT cpu bindings updates
This patchset is an update of a previous posting: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/164587.html v3 changes: - More dts fixes of in-kernel dts - Defined ARM v8 behaviour with different cpus node #address-cells - Added pre ARM11 processors suffixes in the cpu node compatible list - Reordered series - Reworded #address-cells definition - Added ARM v8 - cores running on AArch32 bindings example - Moved WARN* calls on one line to prevent grepping issues v2 changes: - Reworded DT cpu bindings - Split the set, with per-mach specific dts updates - Updated cpu node compatible string list - Defined behaviour of OS running on v8 in AArch32 The introduction of DT cpus/cpu bindings for ARM requires well established rules to enforce the reg property definition for 32-bit and 64-bit ARM processors, inclusive of legacy and current uniprocessor/SMP systems. ARM 64 bit architecture also requires dtb compiled for 64-bit configurations to be reused for kernels running in 32 bit mode, so the cpus/cpu bindings specification must be made compliant to cope with this configuration. Patch #1 of this series is a fix and is included to have a clean patch series and should get reviewed and merged separately. Patch #2-17, along with some kernel fixes related to DT parsing function, update the cpu node bindings and in kernel dts files to cope with legacy, current and upcoming ARM systems. In-kernel device tree source files are updated to comply with the latest specification, so thorough testing is required in order to validate all changes on all affected ARM systems, in particular systems with exotic MPIDR configurations that are likely to break with the changes provided. Code relying on the reg property size to be 4-bytes must be updated so that dtbs compiled for 64-bit kernels can also be used to boot a 32-bit system. Lorenzo Pieralisi (17): ARM: DT: kernel: move temporary cpu map stack array to static data Documentation: devicetree: arm: cpus/cpu nodes bindings updates ARM: dts: am33xx: cpus/cpu nodes dts updates ARM: dts: armada-370-xp: cpus/cpu node dts updates ARM: dts: at91: cpus/cpu node dts updates ARM: dts: exynos5440: cpus/cpu nodes dts updates ARM: dts: imx: cpus/cpu nodes dts updates ARM: dts: lpc32xx: cpus/cpu nodes dts updates ARM: dts: omap: cpus/cpu nodes dts updates ARM: dts: picoxcell: cpus/cpu nodes dts updates ARM: dts: prima2: cpus/cpu node dts updates ARM: dts: pxa2xx: cpus/cpu nodes dts updates ARM: dts: r8a7740: cpus/cpu nodes dts updates ARM: dts: sh7372: cpus/cpu nodes dts updates ARM: dts: spear: cpus/cpu nodes dts updates ARM: dts: sunxi: cpus/cpu nodes dts updates ARM: DT: kernel: DT cpus/cpu node bindings update Documentation/devicetree/bindings/arm/cpus.txt | 457 ++--- arch/arm/boot/dts/am33xx.dtsi | 4 + arch/arm/boot/dts/armada-370-xp.dtsi | 4 + arch/arm/boot/dts/at91rm9200.dtsi | 6 +- arch/arm/boot/dts/at91sam9260.dtsi | 8 +- arch/arm/boot/dts/at91sam9263.dtsi | 8 +- arch/arm/boot/dts/at91sam9g45.dtsi | 8 +- arch/arm/boot/dts/at91sam9n12.dtsi | 8 +- arch/arm/boot/dts/at91sam9x5.dtsi | 8 +- arch/arm/boot/dts/exynos5440.dtsi | 11 + arch/arm/boot/dts/imx23.dtsi | 8 +- arch/arm/boot/dts/imx28.dtsi | 8 +- arch/arm/boot/dts/imx6dl.dtsi | 2 + arch/arm/boot/dts/imx6q.dtsi | 1 + arch/arm/boot/dts/lpc32xx.dtsi | 8 +- arch/arm/boot/dts/omap2.dtsi | 6 +- arch/arm/boot/dts/omap3.dtsi | 5 + arch/arm/boot/dts/omap4.dtsi | 7 + arch/arm/boot/dts/omap5.dtsi | 7 + arch/arm/boot/dts/picoxcell-pc3x2.dtsi | 8 +- arch/arm/boot/dts/picoxcell-pc3x3.dtsi | 8 +- arch/arm/boot/dts/prima2.dtsi | 2 + arch/arm/boot/dts/pxa2xx.dtsi | 7 +- arch/arm/boot/dts/r8a7740.dtsi | 4 + arch/arm/boot/dts/sh7372.dtsi | 5 + arch/arm/boot/dts/spear13xx.dtsi | 2 + arch/arm/boot/dts/spear3xx.dtsi| 8 +- arch/arm/boot/dts/spear600.dtsi| 8 +- arch/arm/boot/dts/sunxi.dtsi | 5 + arch/arm/kernel/devtree.c | 81 +++-- 30 files changed, 602 insertions(+), 110 deletions(-) -- 1.7.12 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 04/17] ARM: dts: armada-370-xp: cpus/cpu node dts updates
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/armada-370-xp.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 6f1acc7..f13b47a 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -23,8 +23,12 @@
compatible = marvell,armada-370-xp;
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
cpu@0 {
compatible = marvell,sheeva-v7;
+ device_type = cpu;
+ reg = 0;
};
};
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 07/17] ARM: dts: imx: cpus/cpu nodes dts updates
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/imx23.dtsi | 8 ++--
arch/arm/boot/dts/imx28.dtsi | 8 ++--
arch/arm/boot/dts/imx6dl.dtsi | 2 ++
arch/arm/boot/dts/imx6q.dtsi | 1 +
4 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 56afcf4..0aae18b 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -23,8 +23,12 @@
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..07f131fc 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -32,8 +32,12 @@
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 63fafe2..b76d85e 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -16,12 +16,14 @@
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 0;
next-level-cache = L2;
};
cpu@1 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 1;
next-level-cache = L2;
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index cba021e..65c1b62 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -17,6 +17,7 @@
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 0;
next-level-cache = L2;
operating-points =
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 09/17] ARM: dts: omap: cpus/cpu nodes dts updates
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/omap2.dtsi | 6 +-
arch/arm/boot/dts/omap3.dtsi | 5 +
arch/arm/boot/dts/omap4.dtsi | 7 +++
arch/arm/boot/dts/omap5.dtsi | 7 +++
4 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..4183027 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -21,8 +21,12 @@
};
cpus {
- cpu@0 {
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
compatible = arm,arm1136jf-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..b6f6502 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -21,8 +21,13 @@
};
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
cpu@0 {
compatible = arm,cortex-a8;
+ device_type = cpu;
+ reg = 0x0;
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..e0f943f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -28,13 +28,20 @@
};
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
next-level-cache = L2;
+ reg = 0x0;
};
cpu@1 {
compatible = arm,cortex-a9;
+ device_type = cpu;
next-level-cache = L2;
+ reg = 0x1;
};
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..e3cc688 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -31,8 +31,13 @@
};
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
cpu@0 {
compatible = arm,cortex-a15;
+ device_type = cpu;
+ reg = 0x0;
timer {
compatible = arm,armv7-timer;
/* 14th PPI IRQ, active low level-sensitive */
@@ -42,6 +47,8 @@
};
cpu@1 {
compatible = arm,cortex-a15;
+ device_type = cpu;
+ reg = 0x1;
timer {
compatible = arm,armv7-timer;
/* 14th PPI IRQ, active low level-sensitive */
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 12/17] ARM: dts: pxa2xx: cpus/cpu nodes dts updates
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/pxa2xx.dtsi | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi
index f18aad3..a5e90f0 100644
--- a/arch/arm/boot/dts/pxa2xx.dtsi
+++ b/arch/arm/boot/dts/pxa2xx.dtsi
@@ -23,8 +23,11 @@
};
cpus {
- cpu@0 {
- compatible = arm,xscale;
+ #address-cells = 0;
+ #size-cells = 0;
+ cpu {
+ compatible = marvell,xscale;
+ device_type = cpu;
};
};
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 14/17] ARM: dts: sh7372: cpus/cpu nodes dts updates
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/sh7372.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
index 677fc60..7bf020e 100644
--- a/arch/arm/boot/dts/sh7372.dtsi
+++ b/arch/arm/boot/dts/sh7372.dtsi
@@ -14,8 +14,13 @@
compatible = renesas,sh7372;
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
cpu@0 {
compatible = arm,cortex-a8;
+ device_type = cpu;
+ reg = 0x0;
};
};
};
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 13/17] ARM: dts: r8a7740: cpus/cpu nodes dts updates
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/r8a7740.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 798fa35..8a831e9 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -14,8 +14,12 @@
compatible = renesas,r8a7740;
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
+ reg = 0x0;
};
};
};
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 11/17] ARM: dts: prima2: cpus/cpu node dts updates
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/prima2.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/prima2.dtsi b/arch/arm/boot/dts/prima2.dtsi
index 3329719..02edd89 100644
--- a/arch/arm/boot/dts/prima2.dtsi
+++ b/arch/arm/boot/dts/prima2.dtsi
@@ -18,6 +18,8 @@
#size-cells = 0;
cpu@0 {
+ compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 0x0;
d-cache-line-size = 32;
i-cache-line-size = 32;
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 06/17] ARM: dts: exynos5440: cpus/cpu nodes dts updates
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/exynos5440.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 5f3562a..fd0966f 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -24,8 +24,13 @@
};
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
cpu@0 {
compatible = arm,cortex-a15;
+ device_type = cpu;
+ reg = 0x0;
timer {
compatible = arm,armv7-timer;
interrupts = 1 13 0xf08;
@@ -34,6 +39,8 @@
};
cpu@1 {
compatible = arm,cortex-a15;
+ device_type = cpu;
+ reg = 0x1;
timer {
compatible = arm,armv7-timer;
interrupts = 1 14 0xf08;
@@ -42,6 +49,8 @@
};
cpu@2 {
compatible = arm,cortex-a15;
+ device_type = cpu;
+ reg = 0x2;
timer {
compatible = arm,armv7-timer;
interrupts = 1 14 0xf08;
@@ -50,6 +59,8 @@
};
cpu@3 {
compatible = arm,cortex-a15;
+ device_type = cpu;
+ reg = 0x3;
timer {
compatible = arm,armv7-timer;
interrupts = 1 14 0xf08;
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
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 --- Documentation/devicetree/bindings/arm/cpus.txt | 457 ++--- 1 file changed, 410 insertions(+), 47 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index f32494d..00badea 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -1,77 +1,440 @@ -* ARM CPUs binding description += +ARM CPUs bindings += The device tree allows to describe the layout of CPUs in a system through the cpus node, which in turn contains a number of subnodes (ie cpu) defining properties for every cpu. -Bindings for CPU nodes follow the ePAPR standard, available from: - -http://devicetree.org - -For the ARM architecture every CPU node must contain the following properties: - -- device_type: must be cpu -- reg: property matching the CPU MPIDR[23:0] register bits - reg[31:24] bits must be set to 0 -- compatible: should be one of: - arm,arm1020 - arm,arm1020e - arm,arm1022 - arm,arm1026 - arm,arm720 - arm,arm740 - arm,arm7tdmi - arm,arm920 - arm,arm922 - arm,arm925 - arm,arm926 - arm,arm940 - arm,arm946 - arm,arm9tdmi - arm,cortex-a5 - arm,cortex-a7 - arm,cortex-a8 - arm,cortex-a9 - arm,cortex-a15 - arm,arm1136 - arm,arm1156 - arm,arm1176 - arm,arm11mpcore - faraday,fa526 - intel,sa110 - intel,sa1100 - marvell,feroceon - marvell,mohawk - marvell,xsc3 - marvell,xscale - -Example: +Bindings for CPU nodes follow the ePAPR v1.1 standard, available from: + +https://www.power.org/documentation/epapr-version-1-1/ + +with updates for 32-bit and 64-bit ARM systems provided in this document. + + +Convention used in this document + + +This document follows the conventions described in the ePAPR v1.1, with +the addition: + +- square brackets define bitfields, eg reg[7:0] value of the bitfield in + the reg property contained in bits 7 down to 0 + += +cpus and cpu node bindings definition += + +The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu +nodes to be present and contain the properties described below. + +- cpus node + + Description: Container of cpu nodes + + The node name must be cpus. + + A cpus node must define the following properties: + + - #address-cells + Usage: required + Value type: u32 + + Definition depends on ARM architecture version and + configuration: + + # On uniprocessor ARM architectures previous to v7 + value must be 0. + # On 32-bit ARM 11 MPcore, ARM v7 or later systems + value must be 1. + # On ARM v8 64-bit systems value must be set to 1 + or 2. Refer to the cpu node's reg property + description for allowed configurations. + + - #size-cells + Usage: required + Value type: u32 + Definition: must be set to 0 + +- cpu node + + Description: Describes a CPU in an ARM based system + + PROPERTIES + + - device_type + Usage: required + Value type: string + Definition: must be cpu + - reg + Usage and definition depend on ARM architecture version and + configuration: + + # On uniprocessor ARM architectures previous to v7 + this property is optional since they do not define + any register that provides a CPU identifier. + Any value set in the reg property for these CPUs + should be ignored. + + # On ARM 11 MPcore based systems this property is + required and matches the CPUID[11:0] register bits
[RFC PATCH v3 15/17] ARM: dts: spear: cpus/cpu nodes dts updates
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/spear13xx.dtsi | 2 ++
arch/arm/boot/dts/spear3xx.dtsi | 8 ++--
arch/arm/boot/dts/spear600.dtsi | 8 ++--
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
index b4ca60f..5093d54 100644
--- a/arch/arm/boot/dts/spear13xx.dtsi
+++ b/arch/arm/boot/dts/spear13xx.dtsi
@@ -22,12 +22,14 @@
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 0;
next-level-cache = L2;
};
cpu@1 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 1;
next-level-cache = L2;
};
diff --git a/arch/arm/boot/dts/spear3xx.dtsi b/arch/arm/boot/dts/spear3xx.dtsi
index c2a852d..f0e3fcf 100644
--- a/arch/arm/boot/dts/spear3xx.dtsi
+++ b/arch/arm/boot/dts/spear3xx.dtsi
@@ -17,8 +17,12 @@
interrupt-parent = vic;
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/spear600.dtsi b/arch/arm/boot/dts/spear600.dtsi
index 19f99dc..9f60a7b 100644
--- a/arch/arm/boot/dts/spear600.dtsi
+++ b/arch/arm/boot/dts/spear600.dtsi
@@ -15,8 +15,12 @@
compatible = st,spear600;
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 08/17] ARM: dts: lpc32xx: cpus/cpu nodes dts updates
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/lpc32xx.dtsi | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 1582f48..3abebb7 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -18,8 +18,12 @@
interrupt-parent = mic;
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 05/17] ARM: dts: at91: cpus/cpu node dts updates
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/at91rm9200.dtsi | 6 +-
arch/arm/boot/dts/at91sam9260.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9263.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9g45.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9n12.dtsi | 8 ++--
arch/arm/boot/dts/at91sam9x5.dtsi | 8 ++--
6 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
b/arch/arm/boot/dts/at91rm9200.dtsi
index b0268a5..f16b3d4 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -34,8 +34,12 @@
ssc2 = ssc2;
};
cpus {
- cpu@0 {
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
compatible = arm,arm920t;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index cb7bcc5..c4eeef7 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -32,8 +32,12 @@
ssc0 = ssc0;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
b/arch/arm/boot/dts/at91sam9263.dtsi
index 271d4de..f3b5c2a 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -29,8 +29,12 @@
ssc1 = ssc1;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
b/arch/arm/boot/dts/at91sam9g45.dtsi
index 6b1d4ca..6c18bd3 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -35,8 +35,12 @@
ssc1 = ssc1;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi
b/arch/arm/boot/dts/at91sam9n12.dtsi
index 7750f98..c3b11af 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -31,8 +31,12 @@
ssc0 = ssc0;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
b/arch/arm/boot/dts/at91sam9x5.dtsi
index aa98e64..6c39d0f 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -33,8 +33,12 @@
ssc0 = ssc0;
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 03/17] ARM: dts: am33xx: cpus/cpu nodes dts updates
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/am33xx.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 0957645..ab1bcf2 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -24,8 +24,12 @@
};
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
cpu@0 {
compatible = arm,cortex-a8;
+ device_type = cpu;
+ reg = 0;
/*
* To consider voltage drop between PMIC and SoC,
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 10/17] ARM: dts: picoxcell: cpus/cpu nodes dts updates
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/picoxcell-pc3x2.dtsi | 8
arch/arm/boot/dts/picoxcell-pc3x3.dtsi | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
b/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
index f0a8c20..533919e 100644
--- a/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
+++ b/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
@@ -18,13 +18,13 @@
#size-cells = 1;
cpus {
- #address-cells = 1;
+ #address-cells = 0;
#size-cells = 0;
- cpu@0 {
- compatible = arm,1176jz-s;
+ cpu {
+ compatible = arm,arm1176jz-s;
+ device_type = cpu;
clock-frequency = 4;
- reg = 0;
d-cache-line-size = 32;
d-cache-size = 32768;
i-cache-line-size = 32;
diff --git a/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
b/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
index daa962d..ab3e800 100644
--- a/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
+++ b/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
@@ -18,13 +18,13 @@
#size-cells = 1;
cpus {
- #address-cells = 1;
+ #address-cells = 0;
#size-cells = 0;
- cpu@0 {
- compatible = arm,1176jz-s;
+ cpu {
+ compatible = arm,arm1176jz-s;
+ device_type = cpu;
cpu-clock = arm_clk, cpu;
- reg = 0;
d-cache-line-size = 32;
d-cache-size = 32768;
i-cache-line-size = 32;
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v3 17/17] ARM: DT: kernel: DT cpus/cpu node bindings update
DT cpu map parsing code must be made compliant with the latest cpus/cpu
nodes bindings updates, hence this patch updates the arm_dt_init_cpu_maps()
function with checks and additional parsing rules.
Uniprocessor systems predating v7 do not parse the cpus node at all
since the reg property is meaningless on those systems.
Device trees for 64-bit systems can be taken as device tree input also
for 64-bit CPUs running in 32-bit mode. The code checks that the reg entries
are zeroed as required in the respective fields and detects automatically
the cpus node #address-cells value so that device tree written for
64-bit ARM platforms (that can have cpus node #address-cells == 2) can still
be taken as input. The correct device tree entries are to be set up by the
boot loader, kernel code just checks that device tree entries in the cpus
node are as expected for a 32-bit CPU (reg[63:24] == 0).
cpu node entries with invalid reg property or containing duplicates are
ignored and the device tree parsing is not stopped anymore when such
entries are encountered, the device tree cpu node entry is just skipped.
A device tree with cpu nodes missing the boot CPU MPIDR is considered a
hard error and the kernel flags this up as a bug to force firmware updates.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/devtree.c | 78 +--
1 file changed, 48 insertions(+), 30 deletions(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f149217..b667217 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -23,6 +23,7 @@
#include asm/setup.h
#include asm/page.h
#include asm/smp_plat.h
+#include asm/system_info.h
#include asm/mach/arch.h
#include asm/mach-types.h
@@ -81,48 +82,64 @@ void __init arm_dt_init_cpu_maps(void)
static u32 tmp_map[NR_CPUS] __initdata = {
[0 ... NR_CPUS-1] = UINT_MAX };
struct device_node *cpu, *cpus;
- u32 i, j, cpuidx = 1;
+ u32 i, j, ac, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
-
+ int len;
bool bootcpu_valid = false;
+
cpus = of_find_node_by_path(/cpus);
- if (!cpus)
+ if (!cpus || ((cpu_architecture() CPU_ARCH_ARMv7) !is_smp()))
return;
+ if (WARN_ON(of_property_read_u32(cpus, #address-cells, ac)))
+ ac = of_n_addr_cells(cpus);
+
for_each_child_of_node(cpus, cpu) {
- u32 hwid;
+ u64 hwid64;
+ u32 hwid32;
+ const __be32 *prop;
pr_debug( * %s...\n, cpu-full_name);
/*
-* A device tree containing CPU nodes with missing reg
-* properties is considered invalid to build the
-* cpu_logical_map.
+* A CPU node with missing or wrong reg property is
+* considered invalid to build a cpu_logical_map entry.
*/
- if (of_property_read_u32(cpu, reg, hwid)) {
- pr_debug( * %s missing reg property\n,
-cpu-full_name);
- return;
+ prop = of_get_property(cpu, reg, len);
+ if (!prop || len (ac * sizeof(*prop))) {
+ WARN(1, * %s node missing/wrong reg property,
skipped\n,
+ cpu-full_name);
+ goto next;
}
-
/*
-* 8 MSBs must be set to 0 in the DT since the reg property
-* defines the MPIDR[23:0].
+* Always read reg as u64 value.
+* For dts with #address-cells == 1 hwid64[63:32]
+* will be set to 0 by of_read_number.
+* Toss away the top 32 bits and store value in hwid32.
+*/
+ hwid32 = hwid64 = of_read_number(prop, ac);
+ /*
+* hwid64[63:24] must be always be 0 since the reg
+* property defines the MPIDR[23:0] bits regardless
+* of the cpus node #address-cells value.
*/
- if (hwid ~MPIDR_HWID_BITMASK)
- return;
+ if (hwid64 ~MPIDR_HWID_BITMASK) {
+ WARN(1, * %s node reg[63:24] must be 0 on 32-bit dts,
got %#016llx, skipped\n,
+ cpu-full_name, hwid64);
+ goto next;
+ }
/*
* Duplicate MPIDRs are a recipe for disaster.
* Scan all initialized entries and check for
-* duplicates. If any is found just bail out.
+* duplicates. If any is found just ignore the CPU.
* temp values were initialized to UINT_MAX
* to avoid matching valid MPIDR[23:0] values
Re: [RFC PATCH v2 12/13] ARM: mach-vt8500: cpus/cpu nodes dts updates
On Tue, Apr 23, 2013 at 03:13:18AM +0100, Tony Prisk wrote:
On 23/04/13 03:27, 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/wm8505.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..a470808 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -13,7 +13,7 @@
cpus {
cpu@0 {
- compatible = arm,arm926ejs;
+ compatible = arm,arm926;
};
};
As the only author for that file, and the arch-vt8500 maintainer, a CC
would have been nice :)
Apologies.
This binding is still incomplete.device_type, compatible and reg are all
required properties.
device_type should already be there and I should not be in charge of
adding it; reg is not required for that processor.
Also, you seem to have only fixed the wm8505.dtsi, while vt8500.dtsi,
wm8650.dtsi and wm8850.dtsi are all left incorrect.
There is no cpus node in there. I can't add cpus node in all dts files
in the kernel where it is missing (why have those dts files been
accepted in the first place, with no cpus node ? why ? cpus node is mandatory
since device tree was introduced, I really do not understand why those dts
landed in the kernel as they are), I would kindly ask maintainers to do
that, I just can not know what cpus are there for every given SoC.
I am already carrying a patch to fix all this properly so could you drop
the arch-vt8500 related patch and I will send in a more complete version
for 3.11
Good, thanks.
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2 12/13] ARM: mach-vt8500: cpus/cpu nodes dts updates
On Tue, Apr 23, 2013 at 03:20:46AM +0100, Tony Prisk wrote:
On 23/04/13 14:13, Tony Prisk wrote:
On 23/04/13 03:27, 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/wm8505.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/wm8505.dtsi
b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..a470808 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -13,7 +13,7 @@
cpus {
cpu@0 {
-compatible = arm,arm926ejs;
+compatible = arm,arm926;
};
};
As the only author for that file, and the arch-vt8500 maintainer, a CC
would have been nice :)
This binding is still incomplete.device_type, compatible and reg are
all required properties.
Also, you seem to have only fixed the wm8505.dtsi, while vt8500.dtsi,
wm8650.dtsi and wm8850.dtsi are all left incorrect.
I am already carrying a patch to fix all this properly so could you
drop the arch-vt8500 related patch and I will send in a more complete
version for 3.11
Regards
Tony Prisk
I didn't notice the rules had been changed in the last patch - shouldn't
you be changing the rules (read: binding) before changing the devicetree
files?
Fair enough, point taken.
Request still stands - please drop this patch and I will submit a more
complete one with the other SoCs updated as well.
Great, thanks,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2 12/13] ARM: mach-vt8500: cpus/cpu nodes dts updates
On Tue, Apr 23, 2013 at 03:43:48AM +0100, Tony Prisk wrote:
On 23/04/13 03:27, 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/wm8505.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..a470808 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -13,7 +13,7 @@
cpus {
cpu@0 {
- compatible = arm,arm926ejs;
+ compatible = arm,arm926;
};
};
The more I look at this, the more wrong it is :/
From the new binding documentation,
+ A cpus node must define the following properties:
+
+ - #address-cells
+ Usage: required
+ Value type: u32
+ Definition: must be set to 1 for 32-bit systems and 2 for
+ 64-bit systems
+ - #size-cells
+ Usage: required
+ Value type: u32
+ Definition: must be set to 0
...
+- cpu node
+
+ Description: Describes a CPU in an ARM based system
+
+ PROPERTIES
+
+ - device_type
+ Usage: required
+ Value type: string
+ Definition: must be cpu
This property is required since DT was invented, again, I should not be
in charge of adding it.
Three required properties that aren't present in the patch.
cpus {
#size-cells = 0;
#address-cells = 1;
cpu {
device_type = cpu
compatible = arm,arm926;
};
};
I am of two minds about this. That processor does not have an MPIDR
equivalent so in theory #address-cells and #size-cells could be omitted
because the reg property is meaningless. I do not know to be honest the
best way to handle this.
Thoughts ?
Thanks for the review,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2 00/13] ARM: DT cpu bindings updates
On Tue, Apr 23, 2013 at 10:09:43AM +0100, Will Deacon wrote: Hi Lorenzo, On Mon, Apr 22, 2013 at 08:18:41PM +0100, Arnd Bergmann wrote: On Monday 22 April 2013, Lorenzo Pieralisi wrote: Thoughts? I notice Catalin has some patches queued for arm64 which unconditionally use of_property_read_u64, but I have a patch to honour the #address-cells property instead. Basically you want me to rule out passing a dtb with cpus node having #address-cells == 2 to a 32-bit kernel, correct ? Or put it another way: No, I'm not proposing that! I don't see why we couldn't make the same change for 32-bit kernels and honour the address-cells field there too. Ok, that was a misunderstanding. I do honour the address-cells field in the arm32 kernel, but there is code that does not and must be fixed (or removed, I have to knock together an RFC to do that or ping the authors and let them do it). - a 32-bit kernel must always get passed a dtb with cpus node #address-cells == 1. Why that? For other registers, we allow leading zeroes. This is already required for MMIO registers on LPAE capable machines. Indeed, we should probably allow any old #address-cells and parse the reg property accordingly. Of course, if any bits above bit 31 are non-zero, then we should complain loudly on an AArch32 system. That's what I do, but again there is code that does not check that and honestly what I would like to do is parsing the reg property once for all at cpu_logical_map init time to avoid reg property parsing proliferation in the kernel. If the system is ARMv8 with CPUs having MPIDR_EL1[63:32] != 0x0, well, running 32-bit kernel on it is not the safest thing to do anyway. I would assume the hypervisor to provide a virtual MPIDR_EL1 for a 32 bit kernel in that case. Correct, but that doesn't help with the bare-metal/host case (where we will need to scream, as described above). Also, when I mentioned the mpidr check, I was just referring to the boot CPU -- you're right about the secondaries. Ok, that's agreed. Thanks, Lorenzo ___ 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 Tue, Apr 23, 2013 at 02:11:46PM +0100, Rob Herring wrote:
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.
IMHO compatibility is already broken. There are a number of dts in the
kernel missing cpus and cpu nodes, others with cpu nodes missing
device_type = cpu, missing cpu nodes compatible properties and the list
goes on and on. Those files got merged in the kernel before bindings were
properly defined for ARM so at that point in time the only reference was the
ePAPR and still, it was not followed (eg my broken patch above fails to add
device_type = cpu to the cpu node, should I change the documentation (ePAPR)
to make the dts above compliant ? I do not think so, I reckon we should fix
all dts and force them to comply with the ePAPR and the in-kernel bindings).
If we do not set in stone the bindings and draw a line now, this stuff will
go wild, it is already in a state that I do not like much.
The reason we are patching the compatible property above is to avoid having
compatible properties containing suffixes for CPUs, we do not deem that
necessary, see:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/145305.html
That's just my opinion, open to change it to find a proper solution to this
issue as long as we make progress.
Thanks for the review,
Lorenzo
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
Re: [RFC PATCH] drivers: bus: add ARM CCI support
On Tue, Apr 23, 2013 at 02:52:08PM +0100, Jon Medhurst (Tixy) wrote:
On Thu, 2013-04-11 at 15:47 +0100, Lorenzo Pieralisi wrote:
[...]
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
new file mode 100644
index 000..81953de
--- /dev/null
+++ b/drivers/bus/arm-cci.c
@@ -0,0 +1,344 @@
+/*
+ * CCI cache coherent interconnect driver
+ *
+ * Copyright (C) 2013 ARM Ltd.
+ * Author: Lorenzo Pieralisi lorenzo.pieral...@arm.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.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/arm-cci.h
+#include linux/device.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include asm/cacheflush.h
+#include asm/dt_affinity.h
+#include asm/outercache.h
+#include asm/smp_plat.h
+
+#define DRIVER_NAMECCI
+#define CCI_CTRL_STATUS0xc
+
+#define CCI_PORT_CTRL 0x0
+
+struct cci_nb_ports {
+ unsigned int nb_ace;
+ unsigned int nb_ace_lite;
+};
+
+enum cci_ace_port_type {
+ ACE_INVALID_PORT = 0x0,
+ ACE_PORT,
+ ACE_LITE_PORT,
+};
+
+struct cci_ace_port {
+ void __iomem *base;
+ int type;
+ union {
+ cpumask_t match_mask;
+ struct device_node *np;
+ } match;
+};
+
+static struct cci_ace_port *ports;
+static unsigned int nb_cci_ports;
+
+static void __iomem *cci_ctrl_base;
+#define INVALID_PORT_IDX -1
+static int cpu_port[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_PORT_IDX };
+
+static void __init cci_ace_init_ports(void)
+{
+ bool is_ace;
+ int port, cpu;
+ /*
+* Port index look-up speeds up the function disabling ports by CPU,
+* since the logical to port index mapping is done once and does
+* not change after system boot.
+* The stashed index array is initialized for all possible CPUs
+* at probe time.
+*/
+ for_each_possible_cpu(cpu) {
+ for (port = 0; port nb_cci_ports; port++) {
+ is_ace = ports[port].type == ACE_PORT;
+ if (is_ace cpu_isset(cpu,
+ports[port].match.match_mask)) {
+ cpu_port[cpu] = port;
+ break;
+ }
+ }
+ WARN(cpu_port[cpu] == INVALID_PORT_IDX, CPU %d has an invalid
+CCI port index\n,
I think the convention is to not split user visible messages across
multiple source lines as this makes grepping for them difficult.
Ok, I will address this issue on the entire patch.
+ cpu);
+ }
+}
+
+/*
+ * cci_ace_lite_port - Function to retrieve the port index corresponding to
+ *a device tree node
+ *
+ * @np = device tree node to match
+ *
+ * Return value:
+ * - ACE LITE port index if success
+ * - -EINVAL if failure
+ *
+ */
+static int cci_ace_lite_port(struct device_node *np)
+{
+ int i;
+ bool is_ace_lite;
+
+ for (i = 0; i nb_cci_ports; i++) {
+ is_ace_lite = ports[i].type == ACE_LITE_PORT;
+ if (is_ace_lite np == ports[i].match.np)
+ return i;
+ }
+ return -ENODEV;
+}
+
+/*
+ * Functions to enable/disable a CCI interconnect slave port
+ *
+ * They are called by low-level power management code to disable slave
+ * interfaces snoops and DVM broadcast.
+ * Since they may execute with cache data allocation disabled and
+ * after the caches have been cleaned and invalidated the functions provide
+ * no explicit locking since they may run with D-cache disabled, so normal
+ * cacheable kernel locks based on ldrex/strex may not work.
+ * Locking has to be provided by BSP implementations to ensure proper
+ * operations.
+ */
+
+/*
+ * cci_port_control()
+ * @port = index of the port to setup
+ * @enable = if true enables the port, if false disables it
+ */
+static void notrace cci_port_control(unsigned int port, bool enable)
+{
+ void __iomem *base = ports[port].base;
+
+ if (!base)
+ return;
+
+ writel_relaxed(enable, base + CCI_PORT_CTRL);
If enable is bool (0 or 1) then this is going to set snoops as specified
but is always going to clear DVM broadcast as that is controlled by bit1
of the register. So, does the API need
[RFC PATCH v2 12/13] ARM: mach-vt8500: cpus/cpu nodes dts updates
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/wm8505.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..a470808 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -13,7 +13,7 @@
cpus {
cpu@0 {
- compatible = arm,arm926ejs;
+ compatible = arm,arm926;
};
};
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 13/13] ARM: DT: kernel: DT cpu node bindings update
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 (inclusive of cpus node #address-cells updates) - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition DT cpu map parsing code must be made compliant with the latest bindings updates, hence this patch also updates the arm_dt_init_cpu_maps() function with checks and additional parsing rules. Uniprocessor systems predating v7 do not parse the cpus node at all since the reg property is meaningless on those systems. Device trees for 64-bit systems can be taken as device tree input also for 64-bit CPUs running in 32-bit mode. The code checks that the reg entries are zeroed as required in the respective fields and detects automatically the cpus node #address-cells value so that device tree written for 64-bit ARM platforms (cpus #address-cells == 2) can still be taken as input. The correct device tree entries are to be set up by the boot loader, kernel code just checks that device tree entries in the cpus node are as expected for a 32-bit CPU (reg[63:24] == 0). cpu node entries with invalid reg property or containing duplicates are ignored and the device tree parsing is not stopped anymore when such entries are encountered, the device tree cpu entry is just skipped. A device tree with cpu nodes missing the boot CPU MPIDR is considered a hard error and the kernel flags this up as a bug to force firmware updates. Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- Documentation/devicetree/bindings/arm/cpus.txt | 378 ++--- arch/arm/kernel/devtree.c | 82 -- 2 files changed, 384 insertions(+), 76 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index f32494d..82684ca 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -1,77 +1,361 @@ -* ARM CPUs binding description += +ARM CPUs bindings += The device tree allows to describe the layout of CPUs in a system through the cpus node, which in turn contains a number of subnodes (ie cpu) defining properties for every cpu. -Bindings for CPU nodes follow the ePAPR standard, available from: - -http://devicetree.org - -For the ARM architecture every CPU node must contain the following properties: - -- device_type: must be cpu -- reg: property matching the CPU MPIDR[23:0] register bits - reg[31:24] bits must be set to 0 -- compatible: should be one of: - arm,arm1020 - arm,arm1020e - arm,arm1022 - arm,arm1026 - arm,arm720 - arm,arm740 - arm,arm7tdmi - arm,arm920 - arm,arm922 - arm,arm925 - arm,arm926 - arm,arm940 - arm,arm946 - arm,arm9tdmi - arm,cortex-a5 - arm,cortex-a7 - arm,cortex-a8 - arm,cortex-a9 - arm,cortex-a15 - arm,arm1136 - arm,arm1156 - arm,arm1176 - arm,arm11mpcore - faraday,fa526 - intel,sa110 - intel,sa1100 - marvell,feroceon - marvell,mohawk - marvell,xsc3 - marvell,xscale - -Example: +Bindings for CPU nodes follow the ePAPR v1.1 standard, available from: + +https://www.power.org/documentation/epapr-version-1-1/ + +with updates for 32-bit and 64-bit ARM systems provided in this document. + + +Convention used in this document + + +This document follows the conventions described in the ePAPR v1.1, with +the addition: + +- square brackets define bitfields, eg reg[7:0] value of the bitfield in + the reg property contained in bits 7 down to 0 + += +cpus and cpu node bindings definition += + +The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu +nodes to be present and contain the properties described below. + +- cpus node + + Description: Container of cpu nodes + + The node name must be cpus. + + A cpus node must define the following properties: + + - #address-cells + Usage: required + Value type: u32 + Definition: must be set to 1 for 32-bit systems and 2 for + 64-bit systems + - #size-cells + Usage: required + Value type: u32 + Definition: must be set to 0 + +- cpu node + + Description: Describes a CPU
[RFC PATCH v2 00/13] ARM: DT cpu bindings updates
This patchset is an update of a previous posting: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163310.html v2 changes: - Reworded DT cpu bindings - Split the set, with per-mach specific dts updates - Updated cpu node compatible string list - Defined behaviour of OS running on v8 in AArch32 The introduction of DT cpus/cpu bindings for ARM requires well established rules to enforce the reg property definition for 32-bit and 64-bit ARM processors, inclusive of legacy and current uniprocessor/SMP systems. ARM 64 bit architecture also requires dtb compiled for 64-bit configurations to be reused for kernels running in 32 bit mode, so the cpus/cpu bindings specification must be made compliant to cope with this configuration. Patch #1 of this series is a fix and is included to have a clean patch series and should get reviewed and merged separately. Patch #2-13, along with some kernel fixes related to DT parsing function, update the cpu node bindings and in kernel dts files to cope with legacy, current and upcoming ARM systems. In-kernel device tree source files are updated to comply with the latest specification, so thorough testing is required in order to validate all changes on all affected ARM systems, in particular systems with exotic MPIDR configurations that are likely to break with the changes provided. Code relying on the reg property size to be 4-bytes will break when dtb compiled for 64-bit kernels are used to boot a 32-bit system so kernel code relying on that (bogus) assumption must be updated properly. Lorenzo Pieralisi (13): ARM: DT: kernel: move temporary cpu map stack array to static data ARM: mach-mv78xx0: cpus/cpu node dts updates ARM: mach-at91: cpus/cpu node dts updates ARM: mach-exynos: cpus/cpu nodes dts updates ARM: mach-imx: cpus/cpu nodes dts updates ARM: mach-lpc32xx: cpus/cpu nodes dts updates ARM: mach-omap2: cpus/cpu nodes dts updates ARM: mach-picoxcell: cpus/cpu nodes dts updates ARM: mach-shmobile: cpus/cpu nodes dts updates ARM: mach-spear: cpus/cpu nodes dts updates ARM: mach-sunxi: cpus/cpu nodes dts updates ARM: mach-vt8500: cpus/cpu nodes dts updates ARM: DT: kernel: DT cpu node bindings update Documentation/devicetree/bindings/arm/cpus.txt | 378 ++--- arch/arm/boot/dts/armada-370-xp.dtsi | 1 + 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 +- arch/arm/boot/dts/exynos5440.dtsi | 7 + arch/arm/boot/dts/imx23.dtsi | 2 +- arch/arm/boot/dts/imx28.dtsi | 2 +- arch/arm/boot/dts/lpc32xx.dtsi | 2 +- arch/arm/boot/dts/omap3.dtsi | 4 + arch/arm/boot/dts/omap4.dtsi | 5 + arch/arm/boot/dts/omap5.dtsi | 5 + arch/arm/boot/dts/picoxcell-pc3x2.dtsi | 2 +- arch/arm/boot/dts/picoxcell-pc3x3.dtsi | 2 +- arch/arm/boot/dts/r8a7740.dtsi | 3 + arch/arm/boot/dts/sh7372.dtsi | 4 + arch/arm/boot/dts/spear3xx.dtsi| 2 +- arch/arm/boot/dts/spear600.dtsi| 2 +- arch/arm/boot/dts/sunxi.dtsi | 4 + arch/arm/boot/dts/wm8505.dtsi | 2 +- arch/arm/kernel/devtree.c | 85 -- 22 files changed, 431 insertions(+), 89 deletions(-) -- 1.7.12 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 09/13] ARM: mach-shmobile: cpus/cpu nodes dts updates
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/r8a7740.dtsi | 3 +++
arch/arm/boot/dts/sh7372.dtsi | 4
2 files changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 798fa35..b47bb36 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -14,8 +14,11 @@
compatible = renesas,r8a7740;
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
cpu@0 {
compatible = arm,cortex-a9;
+ reg = 0x0;
};
};
};
diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
index 677fc60..78478af 100644
--- a/arch/arm/boot/dts/sh7372.dtsi
+++ b/arch/arm/boot/dts/sh7372.dtsi
@@ -14,8 +14,12 @@
compatible = renesas,sh7372;
cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
cpu@0 {
compatible = arm,cortex-a8;
+ reg = 0x0;
};
};
};
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 03/13] ARM: mach-at91: cpus/cpu node dts updates
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;
};
};
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;
};
};
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 01/13] ARM: DT: kernel: move temporary cpu map stack array to static data
As the number of CPUs increase, the temporary array allocated on the
stack in arm_dt_init_cpu_maps() can become too big and trigger stack
issues.
This patch moves the allocated memory to static __initdata so that stack
data is not used anymore to allocate the temporary array.
Memory is marked as __initdata since it need not be persistent after boot.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/devtree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..f149217 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -78,11 +78,12 @@ void __init arm_dt_init_cpu_maps(void)
* contain a list of MPIDR[23:0] values where MPIDR[31:24] must
* read as 0.
*/
+ static u32 tmp_map[NR_CPUS] __initdata = {
+ [0 ... NR_CPUS-1] = UINT_MAX };
struct device_node *cpu, *cpus;
u32 i, j, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
- u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = UINT_MAX };
bool bootcpu_valid = false;
cpus = of_find_node_by_path(/cpus);
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
