* [PATCH 2/4] arm: vt8500: Remove single platform Kconfig options
From: Tony Prisk @ 2013-01-11 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357935162-7672-1-git-send-email-linux@prisktech.co.nz>
This patch completes the move of arch-vt8500 to multiplatform only.
The remaining single-image Kconfig options are removed from
arch/arm/Kconfig and the options in arch/arm/mach-vt8500/Kconfig
are updated.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
arch/arm/Kconfig | 21 ---------------------
arch/arm/mach-vt8500/Kconfig | 13 +++----------
2 files changed, 3 insertions(+), 31 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fbb9492..76efd43 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -950,27 +950,6 @@ config ARCH_OMAP
help
Support for TI's OMAP platform (OMAP1/2/3/4).
-config ARCH_VT8500_SINGLE
- bool "VIA/WonderMedia 85xx"
- select ARCH_VT8500
- select COMMON_CLK
- select CPU_ARM926T
- select MULTI_IRQ_HANDLER
- select SPARSE_IRQ
- select USE_OF
- help
- Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip.
-
-config ARCH_WM8750_SINGLE
- bool "WonderMedia WM8750/WM8850"
- select ARCH_VT8500
- select COMMON_CLK
- select MULTI_IRQ_HANDLER
- select SPARSE_IRQ
- select USE_OF
- help
- Support for WonderMedia WM8750/WM8850 System-on-Chip.
-
endchoice
menu "Multiple platform selection"
diff --git a/arch/arm/mach-vt8500/Kconfig b/arch/arm/mach-vt8500/Kconfig
index d67c7fa..f466b58 100644
--- a/arch/arm/mach-vt8500/Kconfig
+++ b/arch/arm/mach-vt8500/Kconfig
@@ -8,9 +8,8 @@ config ARCH_VT8500
select HAVE_CLK
config ARCH_WM8505
- bool "VIA/WonderMedia 85xx" if !ARCH_VT8500_SINGLE
+ bool "VIA/WonderMedia 85xx"
depends on ARCH_MULTI_V5
- default ARCH_VT8500_SINGLE
select ARCH_VT8500
select CPU_ARM926T
help
@@ -18,7 +17,7 @@ config ARCH_WM8505
config ARCH_WM8750
bool "WonderMedia WM8750"
- depends on ARCH_MULTI_V6 || ARCH_WM8750_SINGLE
+ depends on ARCH_MULTI_V6
select ARCH_VT8500
select CPU_V6
help
@@ -26,14 +25,8 @@ config ARCH_WM8750
config ARCH_WM8850
bool "WonderMedia WM8850"
- depends on ARCH_MULTI_V7 || ARCH_WM8750_SINGLE
+ depends on ARCH_MULTI_V7
select ARCH_VT8500
select CPU_V7
help
Support for WonderMedia WM8850 System-on-Chip.
-
-# ensure that ARCH_WM8850 is on if ARCH_WM8750 is off
-config ARCH_WM8850_AUTO
- def_bool y
- depends on ARCH_WM8750_SINGLE && !ARCH_WM8750
- select ARCH_WM8850
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/4] arm: vt8500: Add support for Wondermedia WM8750/WM8850
From: Tony Prisk @ 2013-01-11 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357935162-7672-1-git-send-email-linux@prisktech.co.nz>
This patch adds support for the WM8750 (ARMv6) and WM8850 (ARMv7).
Common features across all SoCs are split into ARCH_VT8500 and
unique features are specified by each SoC option.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
Documentation/devicetree/bindings/arm/vt8500.txt | 8 ++++++
arch/arm/Kconfig | 17 +++++++----
arch/arm/mach-vt8500/Kconfig | 33 ++++++++++++++++++++--
arch/arm/mach-vt8500/vt8500.c | 2 ++
4 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/vt8500.txt b/Documentation/devicetree/bindings/arm/vt8500.txt
index d657832..87dc1dd 100644
--- a/Documentation/devicetree/bindings/arm/vt8500.txt
+++ b/Documentation/devicetree/bindings/arm/vt8500.txt
@@ -12,3 +12,11 @@ compatible = "wm,wm8505";
Boards with the Wondermedia WM8650 SoC shall have the following properties:
Required root node property:
compatible = "wm,wm8650";
+
+Boards with the Wondermedia WM8750 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8750";
+
+Boards with the Wondermedia WM8850 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8850";
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f95ba14..fbb9492 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -952,20 +952,25 @@ config ARCH_OMAP
config ARCH_VT8500_SINGLE
bool "VIA/WonderMedia 85xx"
- select ARCH_HAS_CPUFREQ
- select ARCH_REQUIRE_GPIOLIB
- select CLKDEV_LOOKUP
+ select ARCH_VT8500
select COMMON_CLK
select CPU_ARM926T
- select GENERIC_CLOCKEVENTS
- select GENERIC_GPIO
- select HAVE_CLK
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
select USE_OF
help
Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip.
+config ARCH_WM8750_SINGLE
+ bool "WonderMedia WM8750/WM8850"
+ select ARCH_VT8500
+ select COMMON_CLK
+ select MULTI_IRQ_HANDLER
+ select SPARSE_IRQ
+ select USE_OF
+ help
+ Support for WonderMedia WM8750/WM8850 System-on-Chip.
+
endchoice
menu "Multiple platform selection"
diff --git a/arch/arm/mach-vt8500/Kconfig b/arch/arm/mach-vt8500/Kconfig
index 2ed0b7d..d67c7fa 100644
--- a/arch/arm/mach-vt8500/Kconfig
+++ b/arch/arm/mach-vt8500/Kconfig
@@ -1,12 +1,39 @@
config ARCH_VT8500
- bool "VIA/WonderMedia 85xx" if ARCH_MULTI_V5
- default ARCH_VT8500_SINGLE
+ bool
select ARCH_HAS_CPUFREQ
select ARCH_REQUIRE_GPIOLIB
select CLKDEV_LOOKUP
- select CPU_ARM926T
select GENERIC_CLOCKEVENTS
select GENERIC_GPIO
select HAVE_CLK
+
+config ARCH_WM8505
+ bool "VIA/WonderMedia 85xx" if !ARCH_VT8500_SINGLE
+ depends on ARCH_MULTI_V5
+ default ARCH_VT8500_SINGLE
+ select ARCH_VT8500
+ select CPU_ARM926T
help
Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip.
+
+config ARCH_WM8750
+ bool "WonderMedia WM8750"
+ depends on ARCH_MULTI_V6 || ARCH_WM8750_SINGLE
+ select ARCH_VT8500
+ select CPU_V6
+ help
+ Support for WonderMedia WM8750 System-on-Chip.
+
+config ARCH_WM8850
+ bool "WonderMedia WM8850"
+ depends on ARCH_MULTI_V7 || ARCH_WM8750_SINGLE
+ select ARCH_VT8500
+ select CPU_V7
+ help
+ Support for WonderMedia WM8850 System-on-Chip.
+
+# ensure that ARCH_WM8850 is on if ARCH_WM8750 is off
+config ARCH_WM8850_AUTO
+ def_bool y
+ depends on ARCH_WM8750_SINGLE && !ARCH_WM8750
+ select ARCH_WM8850
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 3c66d48..55162ab 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -183,6 +183,8 @@ static const char * const vt8500_dt_compat[] = {
"via,vt8500",
"wm,wm8650",
"wm,wm8505",
+ "wm,wm8750",
+ "wm,wm8850",
};
DT_MACHINE_START(WMT_DT, "VIA/Wondermedia SoC (Device Tree Support)")
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/4] arm: vt8500: Add support for Wondermedia WM8750/WM8850
From: Tony Prisk @ 2013-01-11 20:12 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
are available in the git repository at:
git://server.prisktech.co.nz/git/linuxwmt.git tags/armsoc-3.9
for you to fetch changes up to 82c8f175662873f7f7f4c78698888ee963d7d967:
arm: vt8500: Remove remaining mach includes (2012-12-28 21:05:19 +1300)
----------------------------------------------------------------
arm: vt8500: Add support for WM8750/WM8850. Cleanup multiplatform changes
This patchset adds support for the WM8750 (ARMv6) and WM8850 (ARMv7), and
cleans up changes for multiplatform configuration.
Single platform Kconfig options are removed, along with the remaining
mach/includes.
The debug-macro.s is moved to arm/include/debug/ to allow DEBUG_LL on
multi-platform.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
----------------------------------------------------------------
Tony Prisk (4):
arm: vt8500: Add support for Wondermedia WM8750/WM8850
arm: vt8500: Remove single platform Kconfig options
arm: vt8500: Convert debug-macro.S to be multiplatform friendly
arm: vt8500: Remove remaining mach includes
Documentation/devicetree/bindings/arm/vt8500.txt | 8 +++++
arch/arm/Kconfig | 16 ---------
arch/arm/Kconfig.debug | 8 +++++
.../mach/debug-macro.S => include/debug/vt8500.S} | 24 ++++++++-----
arch/arm/mach-vt8500/Kconfig | 26 ++++++++++++--
arch/arm/mach-vt8500/include/mach/timex.h | 26 --------------
arch/arm/mach-vt8500/include/mach/uncompress.h | 37 --------------------
arch/arm/mach-vt8500/vt8500.c | 2 ++
8 files changed, 56 insertions(+), 91 deletions(-)
rename arch/arm/{mach-vt8500/include/mach/debug-macro.S => include/debug/vt8500.S} (56%)
delete mode 100644 arch/arm/mach-vt8500/include/mach/timex.h
delete mode 100644 arch/arm/mach-vt8500/include/mach/uncompress.h
^ permalink raw reply
* [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS
From: Scott Wood @ 2013-01-11 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <A6843D28-E2AF-4EFF-8C9B-232B804C01E7@suse.de>
On 01/11/2013 09:42:55 AM, Alexander Graf wrote:
>
> On 11.01.2013, at 02:10, Scott Wood wrote:
>
> > struct kvm_device_attr {
> > __u32 device;
>
> This needs some semantic specification. Is device a constant value?
> Is it the return value of CREATE_IRQCHIP?
As proposed, it's up to the architecture to provide that
specification. In theory this could be used for things other than IRQ
chips. We could still say that device creation functions return a
valid device ID (if the device has any attributes), as well as have
other architecture-specific ways of describing device IDs (static
enumeration). Or we could have non-architecture-specific static
enumeration. Or just require that all devices be explicitly created by
something that returns the ID.
Do you have a preferred approach?
-Scott
^ permalink raw reply
* arm: mvebu: Fix compile for multiplatform when ARMv6 is selected
From: Tony Lindgren @ 2013-01-11 20:05 UTC (permalink / raw)
To: linux-arm-kernel
Some systems compile in both ARMv6 and ARMv7 into multiplatform
configurations. This means the default compiler flags are for ARMv6,
and we will get:
arch/arm/mach-mvebu/coherency_ll.S: Assembler messages:
arch/arm/mach-mvebu/coherency_ll.S:45: Error: selected processor does not support `dsb'
Fix this by specifying ARMv7 flags for coherency_ll.o.
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -1,6 +1,8 @@
ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
-I$(srctree)/arch/arm/plat-orion/include
+AFLAGS_coherency_ll.o := -Wa,-march=armv7-a
+
obj-y += system-controller.o
obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o coherency_ll.o pmsu.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
^ permalink raw reply
* [PATCH 02/16] ARM: b.L: introduce the CPU/cluster power API
From: Nicolas Pitre @ 2013-01-11 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F05CD4.8050905@ti.com>
On Sat, 12 Jan 2013, Santosh Shilimkar wrote:
> On Saturday 12 January 2013 12:03 AM, Nicolas Pitre wrote:
> > On Fri, 11 Jan 2013, Santosh Shilimkar wrote:
> >
> > > On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
> > > > This is the basic API used to handle the powering up/down of individual
> > > > CPUs in a big.LITTLE system. The platform specific backend
> > > > implementation
> > > > has the responsibility to also handle the cluster level power as well
> > > > when
> > > > the first/last CPU in a cluster is brought up/down.
> > > >
> > > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > > > ---
> > > > arch/arm/common/bL_entry.c | 88
> > > > +++++++++++++++++++++++++++++++++++++++
> > > > arch/arm/include/asm/bL_entry.h | 92
> > > > +++++++++++++++++++++++++++++++++++++++++
> > > > 2 files changed, 180 insertions(+)
> > > >
> > > > diff --git a/arch/arm/common/bL_entry.c b/arch/arm/common/bL_entry.c
> > > > index 80fff49417..41de0622de 100644
> > > > --- a/arch/arm/common/bL_entry.c
> > > > +++ b/arch/arm/common/bL_entry.c
> > > > @@ -11,11 +11,13 @@
> > > >
> > > > #include <linux/kernel.h>
> > > > #include <linux/init.h>
> > > > +#include <linux/irqflags.h>
> > > >
> > > > #include <asm/bL_entry.h>
> > > > #include <asm/barrier.h>
> > > > #include <asm/proc-fns.h>
> > > > #include <asm/cacheflush.h>
> > > > +#include <asm/idmap.h>
> > > >
> > > > extern volatile unsigned long
> > > > bL_entry_vectors[BL_NR_CLUSTERS][BL_CPUS_PER_CLUSTER];
> > > >
> > > > @@ -28,3 +30,89 @@ void bL_set_entry_vector(unsigned cpu, unsigned
> > > > cluster,
> > > > void *ptr)
> > > > outer_clean_range(__pa(&bL_entry_vectors[cluster][cpu]),
> > > > __pa(&bL_entry_vectors[cluster][cpu + 1]));
> > > > }
> > > > +
> > > > +static const struct bL_platform_power_ops *platform_ops;
> > > > +
> > > > +int __init bL_platform_power_register(const struct
> > > > bL_platform_power_ops
> > > > *ops)
> > > > +{
> > > > + if (platform_ops)
> > > > + return -EBUSY;
> > > > + platform_ops = ops;
> > > > + return 0;
> > > > +}
> > > > +
> > > > +int bL_cpu_power_up(unsigned int cpu, unsigned int cluster)
> > > > +{
> > > > + if (!platform_ops)
> > > > + return -EUNATCH;
> > > > + might_sleep();
> > > > + return platform_ops->power_up(cpu, cluster);
> > > > +}
> > > > +
> > > > +typedef void (*phys_reset_t)(unsigned long);
> > > > +
> > > > +void bL_cpu_power_down(void)
> > > > +{
> > > > + phys_reset_t phys_reset;
> > > > +
> > > > + BUG_ON(!platform_ops);
> > > > + BUG_ON(!irqs_disabled());
> > > > +
> > > > + /*
> > > > + * Do this before calling into the power_down method,
> > > > + * as it might not always be safe to do afterwards.
> > > > + */
> > > > + setup_mm_for_reboot();
> > > > +
> > > > + platform_ops->power_down();
> > > > +
> > > > + /*
> > > > + * It is possible for a power_up request to happen concurrently
> > > > + * with a power_down request for the same CPU. In this case the
> > > > + * power_down method might not be able to actually enter a
> > > > + * powered down state with the WFI instruction if the power_up
> > > > + * method has removed the required reset condition. The
> > > > + * power_down method is then allowed to return. We must perform
> > > > + * a re-entry in the kernel as if the power_up method just had
> > > > + * deasserted reset on the CPU.
> > > > + *
> > > > + * To simplify race issues, the platform specific implementation
> > > > + * must accommodate for the possibility of unordered calls to
> > > > + * power_down and power_up with a usage count. Therefore, if a
> > > > + * call to power_up is issued for a CPU that is not down, then
> > > > + * the next call to power_down must not attempt a full shutdown
> > > > + * but only do the minimum (normally disabling L1 cache and CPU
> > > > + * coherency) and return just as if a concurrent power_up request
> > > > + * had happened as described above.
> > > > + */
> > > > +
> > > > + phys_reset = (phys_reset_t)(unsigned long)virt_to_phys(cpu_reset);
> > > > + phys_reset(virt_to_phys(bL_entry_point));
> > > > +
> > > > + /* should never get here */
> > > > + BUG();
> > > > +}
> > > > +
> > > > +void bL_cpu_suspend(u64 expected_residency)
> > > > +{
> > > > + phys_reset_t phys_reset;
> > > > +
> > > > + BUG_ON(!platform_ops);
> > > > + BUG_ON(!irqs_disabled());
> > > > +
> > > > + /* Very similar to bL_cpu_power_down() */
> > > > + setup_mm_for_reboot();
> > > > + platform_ops->suspend(expected_residency);
> > > > + phys_reset = (phys_reset_t)(unsigned long)virt_to_phys(cpu_reset);
> > > > + phys_reset(virt_to_phys(bL_entry_point));
> > > > + BUG();
> > > >
> > > I might be missing all the rationales behind not having a recovery for
> > > CPUs entering suspend if they actualy come here because of some events.
> > > This is pretty much possible in many scenario's and hence letting CPU
> > > cpu come out of suspend should be possible. May be switcher code don't
> > > have such requirement but it appeared bit off to me.
> >
> > There are two things to consider here:
> >
> > 1) The CPU is suspended. CPU state is lost. Next interrupt to wake up
> > the CPU will make it restart from the reset vector and re-entry in
> > the kernel will happen via bL_entry_point to deal with the various
> > cluster issues, to eventually resume kernel code via cpu_resume.
> > Obviously, the machine specific backend code would have set the
> > bL_entry_point address in its machine specific reset vector in
> > advance.
> This is the successful case and in that case you will anyway not hit the
> BUG.
> >
> > 2) An interrupt comes along before the CPU is effectively suspended, say
> > right before the backend code executes a WFI to shut the CPU down.
> > The CPU and possibly cluster state was already set for being powered
> > off. We cannot simply return at this point as caches are off, the
> > CPU is not coherent with the rest of the system anymore, etc. So if
> > the platform specific backend ever returns, say because the final WFI
> > exited, then we have to go through the same arbitration process to
> > restore the CPU and cluster state as if that was a hard reset. Hence
> > the cpu_reset call to loop back into bL_entry_point.
> >
> This is the one I was thinking. Enabling C bit and SMP bit should be
> enough for CPU to get back to right state since the CPU has not lost
> the context all the registers including SP is intact and CPU should
> be able to resume.
No. If we are the last man then the CCI is disabled and we cannot just
enable the C and SMP bits anymore without turning the CCI back on. And
even if we are not the last man, maybe another CPU is concurrently going
through the same code and that one _is_ the last man, in which case it
will have waited until we are done flushing our cache to turn off the
CCI but we don't know about that. And yet another CPU might be coming
up just at the same moment but this one will want to turn on the CCI and
that has to be done in a controlled way, and that control is performed
in the code from bL_entry_point. So, in short, we cannot just return
from here.
> > In either cases, we simply cannot ever return from bL_cpu_suspend()
> > directly. Of course, the caller is expected to have used
> > bL_set_entry_vector() beforehand, most probably with cpu_resume as
> > argument.
> >
> The above might get complicated if when above situation happens on
> last CPU where even CCI gets disabled and then adding the rever code
> for all of that may not be worth. You approach is much safer.
Indeed. Furthermore, that revert code does exist already: it is all in
bL_head.S. Hence the cpu_reset(bL_entry_point) call.
> Thanks for explaining it further.
No problem. That literally took us months to get this code
right so it might not be fully obvious to others after the first look.
Nicolas
^ permalink raw reply
* [PATCH 0/2 v2] at91/ssc: fixes on ASoC tree for 3.8
From: Olof Johansson @ 2013-01-11 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130111193948.GA8677@opensource.wolfsonmicro.com>
On Fri, Jan 11, 2013 at 07:39:49PM +0000, Mark Brown wrote:
> On Fri, Jan 11, 2013 at 10:52:19AM -0800, Olof Johansson wrote:
> > On Fri, Jan 11, 2013 at 6:08 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> >
> > > This material was designed to enter Mark's fixes queue, but as discussed with
> > > Olof, we can imagine merging everything through arm-soc or split the series (of
> > > 2 patches) and let them progress upstream separated (option that I do not like
> > > even if I know that the consequences are not so dramatic).
> > > So please, Olof, if you feel confortable with this series, tell us what you
> > > prefer and we will make our best to make this material go forward...
>
> > You're setting yourself up for awkward merges. The driver change is
> > strongly dependent on the device tree change by failing probe unless
> > the device tree update is there, while before this patch, it still
> > worked.
>
> This is partly my fault for getting grumpy about adding the bolier plate
> code without error checking - overall Linus' change to do the get in the
> core seems like the most sane approach here.
>
> > But to be honest, I don't think this is a fix, it's a feature that you
> > just didn't include in time for the merge window. I don't really see
> > them as appropriate 3.8 material at this point.
>
> Jean-Christophe has been most insistent that pinctrl support is now
> manadatory for all AT91 systems using device tree.
That's a noble goal but enforcing it early gives everyone a lot of pain, and
quite honestly doesn't make sense. During transition it's better to be lenient
and allow both old and new methods (without breakage), unless it causes
significant extra churn.
> Unfortunately
> pinctrl support for AT91 only came in during the merge window and it
> seems like it's sadly been impossible to do what seemd like the obvious
> thing and add the pinctrl bindings to the DT prior to the merge down so
> now we've got this mess. I believe the way the pinctrl conversion was
> done renders the audio driver non-functional without this series.
The problem is that at91 tries to do too much in a single release, and then do
nothing in several releases after. If there was a steadier trickle of code
coming in, then these kind of complex dependencies wouldn't show up all at
once, and could be handled with much less overhead for everyone else involved.
:(
>
> > So, nack on this series. Please make the driver change non-dependent
> > on the new dtsi contents, and merge that through the ASoC tree. Then
> > the dtsi update can go through arm-soc, and later on you can make it
> > mandatory.
>
> Like I say I'm not thrilled about ignoring the return code TBH, nor am I
> thrilled with the way this has been handled overall. That said, the
> current series does seem like the best of a bad job - as I understand it
> we need something like this in v3.8 to make the driver functional.
To be honest, if Atmel can't figure out how to merge a complete feature
without causing intentional regressions during the merge window, and plan
on brokenness to be fixed as late as in -rc4, then they deserve to have
a broken platform. Unfortunately the victim of that is end users, and we
don't want to leave them hanging. This really can't become a trend though.
Sigh. Feel free to add:
Reluctantly-acked-by: Olof Johansson <olof@lixom.net>
to the patches when you apply them (based on IRC discussion, might as
well take both through ASoC).
-Olof
^ permalink raw reply
* [PATCH v3 0/9] Migrate Tegra to common clock framework
From: Marc Dietrich @ 2013-01-11 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F058BC.9090909@wwwdotorg.org>
On Friday 11 January 2013 11:23:56 Stephen Warren wrote:
> On 01/11/2013 08:59 AM, Marc Dietrich wrote:
> > On Friday 11 January 2013 13:40:03 Prashant Gaikwad wrote:
> >> On Thursday 10 January 2013 02:14 AM, Stephen Warren wrote:
> >>> On 01/09/2013 10:34 AM, Stephen Warren wrote:
> ...
>
> >>> Your changes don't actually cause the driver to break though, since it
> >>> abuses clk_get_sys() to retrieve clocks under a different driver name,
> >>> which matches what the clock driver provides. However, I think you
> >>> should also include the following patch at the end of your series to fix
> >>>
> >>> this up, so the clock looking happens through device tree:
> >>>> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
> >>>> index d8826ed..6d44076 100644
> >>>> --- a/drivers/staging/nvec/nvec.c
> >>>> +++ b/drivers/staging/nvec/nvec.c
> >>>> @@ -770,7 +770,7 @@ static int tegra_nvec_probe(struct platform_device
> >>>> *pdev)>>
> >>>>
> >>>> return -ENODEV;
> >>>>
> >>>> }
> >>>>
> >>>> - i2c_clk = clk_get_sys("tegra-i2c.2", "div-clk");
> >>>> + i2c_clk = clk_get(&pdev->dev, "div-clk");
> >>>>
> >>>> if (IS_ERR(i2c_clk)) {
> >>>>
> >>>> dev_err(nvec->dev, "failed to get controller
> >>>> clock\n");
> >>>> return -ENODEV;
> >>
> >> Included in the latest patches sent.
> >
> > em, not yet in V4.
>
> It's in V2 of the other series Prashant posted which sits on top of the
> CCF rework series.
ahh, sorry - I didn't see it because of the changed subject line.
> > Maybe you can also adjust the TODO (2nd entry) file now
> > that this issue is fixed.
>
> I'll try to remember to repost an updated version of the patch which
> does that...
no need if it just adds this change. I'll need to update the file anyway soon.
Thanks
Marc
^ permalink raw reply
* [GIT PULL] enable multiplatform support for omap2+ for v3.9
From: Tony Lindgren @ 2013-01-11 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130110194217.GA14149@atomide.com>
* Tony Lindgren <tony@atomide.com> [130110 11:46]:
> Hi Arnd, Olof,
>
> Below is a pull request to enable multiplatform support for omap2+.
Now that -rc3 is out, here's this one rebased on v3.8-rc3 as requested
by Olof.
Regards,
Tony
The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.9/multiplatform-enable-signed-v2
for you to fetch changes up to ad1bb1b4e01c5ecbe32133ce6921d0e76cb76dcf:
ARM: OMAP2+: Remove now obsolete uncompress.h and debug-macro.S (2013-01-11 11:24:20 -0800)
----------------------------------------------------------------
The last dependency for enabling multiplatform support for omap2+ is now
finally gone with commit 62e4d357 (ARM: 7609/1: disable errata work-arounds
which access secure registers) that was preventing booting omap4.
Note that make uImage will no longer work properly because of unspecified
load address, so uImage needs to be created manually with:
$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
-n "Linux" -d zImage-omap2plus uImage-omap2plus
You can also boot minimal vexpress configuration using qemu with:
$ qemu-system-arm -machine vexpress-a9 -m 1024 -net nic -net user -serial stdio \
-append "console=ttyAMA0,115200n8 rw root=/dev/mmcblk0p2 rootwait" \
-kernel zImage-omap2plus -initrd initrd.img -sd rootfs.img
Please note that some custom defconfigs now need to be updated to include
the following options:
CONFIG_ARCH_MULTIPLATFORM=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_OMAP2PLUS=y
And possibly also:
CONFIG_ARCH_MULTI_V6=y
Updating is needed at least for RMK's minimal allnoconfig files.
And if you need DEBUG_LL for earlyprintk, you now have to select the
debug port manually with Kconfig.
----------------------------------------------------------------
Tony Lindgren (9):
ARM: OMAP2+: Limit omap initcalls to omap only on multiplatform kernels
ARM: OMAP2+: Use omap initcalls
ARM: OMAP: Fix i2c cmdline initcall for multiplatform
ARM: OMAP: Fix dmaengine init for multiplatform
ARM: OMAP2+: Add multiplatform debug_ll support
ARM: OMAP2+: Disable code that currently does not work with multiplaform
ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support
ARM: OMAP2+: Add minimal support for booting vexpress
ARM: OMAP2+: Remove now obsolete uncompress.h and debug-macro.S
arch/arm/Kconfig | 13 +-
arch/arm/Kconfig.debug | 56 +++++++
arch/arm/configs/omap2plus_defconfig | 6 +-
.../debug-macro.S => include/debug/omap2plus.S} | 137 +++++++++-------
arch/arm/mach-omap1/dma.c | 18 ++-
arch/arm/mach-omap1/i2c.c | 6 +
arch/arm/mach-omap2/Kconfig | 25 ++-
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
arch/arm/mach-omap2/board-rx51-video.c | 3 +-
arch/arm/mach-omap2/clock2xxx.c | 2 +-
arch/arm/mach-omap2/clock3xxx.c | 2 +-
arch/arm/mach-omap2/devices.c | 6 +-
arch/arm/mach-omap2/dma.c | 23 ++-
arch/arm/mach-omap2/drm.c | 2 +-
arch/arm/mach-omap2/emu.c | 2 +-
arch/arm/mach-omap2/fb.c | 4 +-
arch/arm/mach-omap2/gpio.c | 5 +-
arch/arm/mach-omap2/gpmc.c | 4 +-
arch/arm/mach-omap2/hdq1w.c | 3 +-
arch/arm/mach-omap2/hwspinlock.c | 2 +-
arch/arm/mach-omap2/i2c.c | 5 +
arch/arm/mach-omap2/include/mach/serial.h | 37 -----
arch/arm/mach-omap2/include/mach/uncompress.h | 176 ---------------------
arch/arm/mach-omap2/mcbsp.c | 3 +-
arch/arm/mach-omap2/omap-iommu.c | 2 +-
arch/arm/mach-omap2/omap2-restart.c | 3 +-
arch/arm/mach-omap2/omap4-common.c | 4 +-
arch/arm/mach-omap2/omap_device.c | 5 +-
arch/arm/mach-omap2/omap_hwmod.c | 2 +-
arch/arm/mach-omap2/omap_phy_internal.c | 2 +-
arch/arm/mach-omap2/opp3xxx_data.c | 2 +-
arch/arm/mach-omap2/opp4xxx_data.c | 2 +-
arch/arm/mach-omap2/pm-debug.c | 2 +-
arch/arm/mach-omap2/pm.c | 2 +-
arch/arm/mach-omap2/pmu.c | 2 +-
arch/arm/mach-omap2/prm3xxx.c | 2 +-
arch/arm/mach-omap2/prm44xx.c | 2 +-
arch/arm/mach-omap2/serial.c | 2 +-
arch/arm/mach-omap2/smartreflex-class3.c | 2 +-
arch/arm/mach-omap2/soc.h | 29 ++++
arch/arm/mach-omap2/timer.c | 2 +-
arch/arm/mach-omap2/wd_timer.c | 2 +-
arch/arm/plat-omap/Kconfig | 32 +---
arch/arm/plat-omap/Makefile | 2 +
arch/arm/plat-omap/i2c.c | 3 +-
arch/arm/plat-omap/include/plat/i2c.h | 6 +
drivers/crypto/omap-sham.c | 3 +
drivers/dma/omap-dma.c | 20 +--
drivers/media/rc/Kconfig | 2 +-
drivers/staging/tidspbridge/Kconfig | 2 +-
51 files changed, 314 insertions(+), 370 deletions(-)
rename arch/arm/{mach-omap2/include/mach/debug-macro.S => include/debug/omap2plus.S} (56%)
delete mode 100644 arch/arm/mach-omap2/include/mach/uncompress.h
^ permalink raw reply
* [PATCH 0/2 v2] at91/ssc: fixes on ASoC tree for 3.8
From: Mark Brown @ 2013-01-11 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhhSkrvP7X=y8qmdMKKXZ694+1+ZXY3y6HK1E85qaN5sQ@mail.gmail.com>
On Fri, Jan 11, 2013 at 10:52:19AM -0800, Olof Johansson wrote:
> On Fri, Jan 11, 2013 at 6:08 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>
> > This material was designed to enter Mark's fixes queue, but as discussed with
> > Olof, we can imagine merging everything through arm-soc or split the series (of
> > 2 patches) and let them progress upstream separated (option that I do not like
> > even if I know that the consequences are not so dramatic).
> > So please, Olof, if you feel confortable with this series, tell us what you
> > prefer and we will make our best to make this material go forward...
> You're setting yourself up for awkward merges. The driver change is
> strongly dependent on the device tree change by failing probe unless
> the device tree update is there, while before this patch, it still
> worked.
This is partly my fault for getting grumpy about adding the bolier plate
code without error checking - overall Linus' change to do the get in the
core seems like the most sane approach here.
> But to be honest, I don't think this is a fix, it's a feature that you
> just didn't include in time for the merge window. I don't really see
> them as appropriate 3.8 material at this point.
Jean-Christophe has been most insistent that pinctrl support is now
manadatory for all AT91 systems using device tree. Unfortunately
pinctrl support for AT91 only came in during the merge window and it
seems like it's sadly been impossible to do what seemd like the obvious
thing and add the pinctrl bindings to the DT prior to the merge down so
now we've got this mess. I believe the way the pinctrl conversion was
done renders the audio driver non-functional without this series.
> So, nack on this series. Please make the driver change non-dependent
> on the new dtsi contents, and merge that through the ASoC tree. Then
> the dtsi update can go through arm-soc, and later on you can make it
> mandatory.
Like I say I'm not thrilled about ignoring the return code TBH, nor am I
thrilled with the way this has been handled overall. That said, the
current series does seem like the best of a bad job - as I understand it
we need something like this in v3.8 to make the driver functional.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130111/3d4e2769/attachment-0001.sig>
^ permalink raw reply
* [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS
From: Christoffer Dall @ 2013-01-11 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130111191808.GA18512@amt.cnet>
On Fri, Jan 11, 2013 at 2:18 PM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
>> > Can you make KVM_SET_ARM_DEVICE address extensible?
>> > Add some reserved space and a flags field.
>>
>> Can't we do this for the new ioctl that we all would agree on rather than the interim one that's only a short term solution for a greater problem?
>>
>>
>> Alex
>
> OK.
>
Good. It's decided - the KVM/ARM patches remain in their current state
with an ARM specific ioctl, and will transition to something generic
post merge.
-Christoffer
^ permalink raw reply
* [PATCH 15/16] ARM: vexpress/dcscb: handle platform coherency exit/setup and CCI
From: Nicolas Pitre @ 2013-01-11 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F059A4.4010107@ti.com>
On Fri, 11 Jan 2013, Santosh Shilimkar wrote:
> On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
> > From: Dave Martin <dave.martin@linaro.org>
> >
> > + /*
> > + * Flush the local CPU cache.
> > + *
> > + * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
> > + * a preliminary flush here for those CPUs. At least, that's
> > + * the theory -- without the extra flush, Linux explodes on
> > + * RTSM (maybe not needed anymore, to be investigated).
> > + */
> This is expected if the entire code is not in one stack frame and the
> additional flush is needed to avoid possible stack corruption. This
> issue has been discussed in past on the list.
I missed that. Do you have a reference or pointer handy?
What is strange is that this is 100% reproducible on RTSM while this
apparently is not an issue on real hardware so far.
Nicolas
^ permalink raw reply
* [PATCH] ARM: integrator: move syscon remap for AP PCIv3
From: Olof Johansson @ 2013-01-11 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357809529-3851-1-git-send-email-linus.walleij@linaro.org>
On Thu, Jan 10, 2013 at 10:18:49AM +0100, Linus Walleij wrote:
> The Integrator/AP syscon remapping was done in the .setup()
> function rather than .preinit() which is wrong - .preinit()
> is called before .setup() and the former also use the syscon
> base and cause a crash since it was not yet remapped.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ARM SoC guys: please apply this patch directly to the fixes branch
> if there are no comments, it is a pure v3.8 regression fix for
> the -rc:s and I do not expect to send more regression fixes for
> the Integrators this cycle.
Applied to fixes.
Thanks!
-Olof
^ permalink raw reply
* [PATCH 0/3] arch_decomp_wdog cleanup
From: Olof Johansson @ 2013-01-11 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130111170843.GG23505@n2100.arm.linux.org.uk>
On Fri, Jan 11, 2013 at 05:08:43PM +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 10, 2013 at 10:12:42PM +0800, Shawn Guo wrote:
> > All the arch_decomp_wdog related codes are there without any users,
> > since ARCH_HAS_DECOMP_WDOG is only used by lib/inflate.c which however
> > is not used by arch/arm/boot/compressed/decompress.c.
>
> Hmm, this suggests that those samsung platforms haven't been booted for
> a while - because the decompressor will enable the watchdog, but won't
> pat it at all. So, do we still need them in the kernel?
Well, they haven't been booted with the watchdog enabled at least.
> Other than that, this looks good. Who's going to deal with it though?
Given that it touches include files under mach-*/include, we might be better
off taking it through arm-soc from conflicts point of view. Ok with you?
-Olof
^ permalink raw reply
* [PATCH 13/16] drivers: misc: add ARM CCI support
From: Nicolas Pitre @ 2013-01-11 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F057D7.1010808@ti.com>
On Fri, 11 Jan 2013, Santosh Shilimkar wrote:
> On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
> > From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >
> > 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.
> >
> > This patch enables the basic infrastructure required in Linux to
> > handle and programme the CCI component. The first implementation is
> > based on a platform device, its relative DT compatible property and
> > a simple programming interface.
> >
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > ---
> > drivers/misc/Kconfig | 3 ++
> > drivers/misc/Makefile | 1 +
> > drivers/misc/arm-cci.c | 107
> > ++++++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/arm-cci.h | 30 ++++++++++++++
> How about 'drivers/bus/' considering CCI is an interconnect bus (though
> for coherency)
Yes, I like that better.
> > 4 files changed, 141 insertions(+)
> > create mode 100644 drivers/misc/arm-cci.c
> > create mode 100644 include/linux/arm-cci.h
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index b151b7c1bd..30d5be1ad2 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -499,6 +499,9 @@ config USB_SWITCH_FSA9480
> > stereo and mono audio, video, microphone and UART data to use
> > a common connector port.
> >
> > +config ARM_CCI
> You might want add depends on ARM big.LITTTLE otherwise it will
> break build for other arch's with random configurations.
As far as this patch goes, this is buildable on other architectures too.
The next patch changes that though.
> [..]
>
> > diff --git a/drivers/misc/arm-cci.c b/drivers/misc/arm-cci.c
> > new file mode 100644
> > index 0000000000..f329c43099
> > --- /dev/null
> > +++ b/drivers/misc/arm-cci.c
> > @@ -0,0 +1,107 @@
> > +/*
> > + * CCI support
> > + *
> > + * Copyright (C) 2012 ARM Ltd.
> > + * Author: Lorenzo Pieralisi <lorenzo.pieralisi@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/device.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>
> > +#include <linux/arm-cci.h>
> > +
> > +#define CCI400_EAG_OFFSET 0x4000
> > +#define CCI400_KF_OFFSET 0x5000
> > +
> > +#define DRIVER_NAME "CCI"
> > +struct cci_drvdata {
> > + void __iomem *baseaddr;
> > + spinlock_t lock;
> > +};
> > +
> > +static struct cci_drvdata *info;
> > +
> > +void disable_cci(int cluster)
> > +{
> > + u32 cci_reg = cluster ? CCI400_KF_OFFSET : CCI400_EAG_OFFSET;
> > + writel_relaxed(0x0, info->baseaddr + cci_reg);
> > +
> > + while (readl_relaxed(info->baseaddr + 0xc) & 0x1)
> > + ;
> > +}
> > +EXPORT_SYMBOL_GPL(disable_cci);
> > +
> Is more functionality going to be added for CCI driver. Having this
> much of driver code for just a disable_cci() functions seems like
> overkill.
Yes. More code will appear here to provide pmu functionalities, etc.
Nicolas
^ permalink raw reply
* [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS
From: Marcelo Tosatti @ 2013-01-11 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5FF73B8-DAB5-4B6D-977C-7908483F660B@suse.de>
> > Can you make KVM_SET_ARM_DEVICE address extensible?
> > Add some reserved space and a flags field.
>
> Can't we do this for the new ioctl that we all would agree on rather than the interim one that's only a short term solution for a greater problem?
>
>
> Alex
OK.
^ permalink raw reply
* [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS
From: Alexander Graf @ 2013-01-11 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130110222801.GB17111@amt.cnet>
On 10.01.2013, at 23:28, Marcelo Tosatti wrote:
> On Wed, Jan 09, 2013 at 10:37:20PM +0100, Alexander Graf wrote:
>>
>>>
>>>>>> We can start to introduce (and fix ARM) with a generic ioctl in the MPIC patches then.
>>>>>
>>>>> The ioctl is already generic, except for its name.
>>>> It's making a few wrong assumptions:
>>>> * maximum size of value is u64
>>>
>>> This is tolerable IMHO.
>>>
>>>> * combining device id (variable) with addr type id (const) into a single field. It could just be split into multiple fields
>>>
>>> I agree, but that could be lived with as well.
>>>
>>> I get that there's a tradeoff between getting something in now, versus waiting until the API is more refined. Tagging it with a particular ISA seems like an odd way of saying "soon to be deprecated", though. What happens if we're still squabbling over the perfect replacement API when we're trying to push PPC MPIC stuff in?
>
> As mentioned, i fail to see the benefit in sharing 0.0x% of the code (the
> interface), while the remaining code is not shared.
Important code sharing happens in user space.
>
>> Then we're the ones who have to come up with a good interface.
>
> Or just have KVM_SET_PPC_DEVICE_ADDRESS. Is there a downside to that?
Yes. Harder to read code and a lack of commonality. Also it wouldn't cut it for us, as we need to set more than just addresses. But most of all I really hate to take a generic problem and solve it only for myself.
Btw, x86 has the same issue too, it just only somehow got away with not caring too much about it. The LAPIC has a version register that Mac OS X guests read. If the version is too old, it doesn't boot. So some time ago we just changed the version register.
The real, backwards compatible change however would've been to have user space tell us which version to emulate and set it accordingly. The way we did it basically broke backwards compatibility. We only got away with it because the register is rarely read.
Alex
^ permalink raw reply
* [PATCH 10/16] ARM: vexpress: introduce DCSCB support
From: Nicolas Pitre @ 2013-01-11 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F05606.9060703@ti.com>
On Fri, 11 Jan 2013, Santosh Shilimkar wrote:
> On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
> > This adds basic CPU and cluster reset controls on RTSM for the
> > A15x4-A7x4 model configuration using the Dual Cluster System
> > Configuration Block (DCSCB).
> >
> > The cache coherency interconnect (CCI) is not handled yet.
> >
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > ---
> > arch/arm/mach-vexpress/Kconfig | 8 ++
> > arch/arm/mach-vexpress/Makefile | 1 +
> > arch/arm/mach-vexpress/dcscb.c | 160
> > ++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 169 insertions(+)
> > create mode 100644 arch/arm/mach-vexpress/dcscb.c
> >
> > diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> > index 99e63f5f99..e55c02562f 100644
> > --- a/arch/arm/mach-vexpress/Kconfig
> > +++ b/arch/arm/mach-vexpress/Kconfig
> > @@ -53,4 +53,12 @@ config ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA
> > config ARCH_VEXPRESS_CA9X4
> > bool "Versatile Express Cortex-A9x4 tile"
> >
> > +config ARCH_VEXPRESS_DCSCB
> > + bool "Dual Cluster System Control Block (DCSCB) support"
> > + depends on BIG_LITTLE
> > + help
> > + Support for the Dual Cluster System Configuration Block (DCSCB).
> > + This is needed to provide CPU and cluster power management
> > + on RTSM.
> > +
> > endmenu
> > diff --git a/arch/arm/mach-vexpress/Makefile
> > b/arch/arm/mach-vexpress/Makefile
> > index 80b64971fb..2253644054 100644
> > --- a/arch/arm/mach-vexpress/Makefile
> > +++ b/arch/arm/mach-vexpress/Makefile
> > @@ -6,5 +6,6 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) :=
> > -I$(srctree)/$(src)/include \
> >
> > obj-y := v2m.o reset.o
> > obj-$(CONFIG_ARCH_VEXPRESS_CA9X4) += ct-ca9x4.o
> > +obj-$(CONFIG_ARCH_VEXPRESS_DCSCB) += dcscb.o
> > obj-$(CONFIG_SMP) += platsmp.o
> > obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
> > diff --git a/arch/arm/mach-vexpress/dcscb.c b/arch/arm/mach-vexpress/dcscb.c
> > new file mode 100644
> > index 0000000000..cccd943cd4
> > --- /dev/null
> > +++ b/arch/arm/mach-vexpress/dcscb.c
> > @@ -0,0 +1,160 @@
> > +/*
> > + * arch/arm/mach-vexpress/dcscb.c - Dual Cluster System Control Block
> > + *
> > + * Created by: Nicolas Pitre, May 2012
> > + * Copyright: (C) 2012 Linaro Limited
> > + *
> > + * 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.
> > + */
> > +
> > +#include <linux/init.h>
> > +#include <linux/kernel.h>
> > +#include <linux/io.h>
> > +#include <linux/spinlock.h>
> > +#include <linux/errno.h>
> > +#include <linux/vexpress.h>
> > +
> > +#include <asm/bL_entry.h>
> > +#include <asm/proc-fns.h>
> > +#include <asm/cacheflush.h>
> > +
> > +
> > +#define DCSCB_PHYS_BASE 0x60000000
> > +
> > +#define RST_HOLD0 0x0
> > +#define RST_HOLD1 0x4
> > +#define SYS_SWRESET 0x8
> > +#define RST_STAT0 0xc
> > +#define RST_STAT1 0x10
> > +#define EAG_CFG_R 0x20
> > +#define EAG_CFG_W 0x24
> > +#define KFC_CFG_R 0x28
> > +#define KFC_CFG_W 0x2c
> > +#define DCS_CFG_R 0x30
> > +
> > +/*
> > + * We can't use regular spinlocks. In the switcher case, it is possible
> > + * for an outbound CPU to call power_down() after its inbound counterpart
> > + * is already live using the same logical CPU number which trips lockdep
> > + * debugging.
> > + */
> > +static arch_spinlock_t dcscb_lock = __ARCH_SPIN_LOCK_UNLOCKED;
> > +
> > +static void __iomem *dcscb_base;
> > +
> > +static int dcscb_power_up(unsigned int cpu, unsigned int cluster)
> > +{
> > + unsigned int rst_hold, cpumask = (1 << cpu);
> > +
> > + pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
> > + if (cpu >= 4 || cluster >= 2)
> > + return -EINVAL;
> > +
> > + /*
> > + * Since this is called with IRQs enabled, and no arch_spin_lock_irq
> > + * variant exists, we need to disable IRQs manually here.
> > + */
> > + local_irq_disable();
> > + arch_spin_lock(&dcscb_lock);
> > +
> > + rst_hold = readl_relaxed(dcscb_base + RST_HOLD0 + cluster * 4);
> > + if (rst_hold & (1 << 8)) {
> > + /* remove cluster reset and add individual CPU's reset */
> > + rst_hold &= ~(1 << 8);
> > + rst_hold |= 0xf;
> > + }
> > + rst_hold &= ~(cpumask | (cpumask << 4));
> > + writel(rst_hold, dcscb_base + RST_HOLD0 + cluster * 4);
> > +
> > + arch_spin_unlock(&dcscb_lock);
> > + local_irq_enable();
> > +
> > + return 0;
> > +}
> > +
> > +static void dcscb_power_down(void)
> > +{
> > + unsigned int mpidr, cpu, cluster, rst_hold, cpumask, last_man;
> > +
> > + asm ("mrc p15, 0, %0, c0, c0, 5" : "=r" (mpidr));
> > + cpu = mpidr & 0xff;
> > + cluster = (mpidr >> 8) & 0xff;
> > + cpumask = (1 << cpu);
> > +
> > + pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
> > + BUG_ON(cpu >= 4 || cluster >= 2);
> > +
> > + arch_spin_lock(&dcscb_lock);
> > + rst_hold = readl_relaxed(dcscb_base + RST_HOLD0 + cluster * 4);
> > + rst_hold |= cpumask;
> > + if (((rst_hold | (rst_hold >> 4)) & 0xf) == 0xf)
> > + rst_hold |= (1 << 8);
> > + writel(rst_hold, dcscb_base + RST_HOLD0 + cluster * 4);
> > + arch_spin_unlock(&dcscb_lock);
> > + last_man = (rst_hold & (1 << 8));
> > +
> > + /*
> > + * Now let's clean our L1 cache and shut ourself down.
> > + * If we're the last CPU in this cluster then clean L2 too.
> > + */
> > +
> Do you wanted to have C bit clear code here ?
cpu_proc_fin() does it.
> > + /*
> > + * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
> > + * a preliminary flush here for those CPUs. At least, that's
> > + * the theory -- without the extra flush, Linux explodes on
> > + * RTSM (maybe not needed anymore, to be investigated)..
> > + */
> > + flush_cache_louis();
> > + cpu_proc_fin();
> > +
> > + if (!last_man) {
> > + flush_cache_louis();
> > + } else {
> > + flush_cache_all();
> > + outer_flush_all();
> > + }
> > +
> > + /* Disable local coherency by clearing the ACTLR "SMP" bit: */
> > + asm volatile (
> > + "mrc p15, 0, ip, c1, c0, 1 \n\t"
> > + "bic ip, ip, #(1 << 6) @ clear SMP bit \n\t"
> > + "mcr p15, 0, ip, c1, c0, 1"
> > + : : : "ip" );
> > +
> > + /* Now we are prepared for power-down, do it: */
> You need dsb here, right ?
Probably. However this code is being refactored significantly with
subsequent patches. This intermediate step was kept not to introduce
too many concepts at once.
> > + wfi();
> > +
> > + /* Not dead at this point? Let our caller cope. */
> > +}
> > +
>
> Regards
> Santosh
>
Nicolas
^ permalink raw reply
* [GIT PULL] imx uncompress debug for 3.9
From: Olof Johansson @ 2013-01-11 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130110125547.GB8680@S2101-09.ap.freescale.net>
Hi,
On Thu, Jan 10, 2013 at 08:55:50PM +0800, Shawn Guo wrote:
> The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
>
> Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
>
> are available in the git repository at:
>
> git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-uncompress-3.9
>
> for you to fetch changes up to 0edbac9d72158b443368d7002db387463fe08ffd:
>
> ARM: uncompress: support uncompress debug for multiplatform build (2012-12-22 21:01:50 +0800)
>
> ----------------------------------------------------------------
> I did not get any comment on the series, so would think it's an
> acceptable solution for multiplatform build to get uncompress debug
> capability back.
>
> ----------------------------------------------------------------
> Shawn Guo (4):
> ARM: imx: use separated debug uart symbol for imx31 and imx35
> ARM: imx: support DEBUG_LL uart port selection for all i.MX SoCs
> ARM: imx: restore uncompress.h to a common place
> ARM: uncompress: support uncompress debug for multiplatform build
See my comment on the last patch. I would prefer to see a generic solution
instead of having to add a debug/uncompress/ file for every platform.
-Olof
^ permalink raw reply
* [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS
From: Alexander Graf @ 2013-01-11 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130111183907.GA15113@amt.cnet>
On 11.01.2013, at 19:39, Marcelo Tosatti wrote:
> On Fri, Jan 11, 2013 at 02:26:51AM -0500, Christoffer Dall wrote:
>> On 10/01/2013, at 20.10, Scott Wood <scottwood@freescale.com> wrote:
>>
>>> On 01/10/2013 06:35:02 PM, Marcelo Tosatti wrote:
>>>> On Thu, Jan 10, 2013 at 04:40:12PM -0600, Scott Wood wrote:
>>>>> On 01/10/2013 04:28:01 PM, Marcelo Tosatti wrote:
>>>>>> Or just have KVM_SET_PPC_DEVICE_ADDRESS. Is there a downside to that?
>>>>>
>>>>> Besides the above, and my original complaint that it shouldn't be
>>>>> specific to addresses?
>>>>>
>>>>> -Scott
>>>> I did not really grasp that ('shouldnt be specific to addresses'), but
>>>> anyway.
>>>
>>> A device may have other configuration parameters that need to be set,
>>> besides addresses. PPC MPIC will require information about the vendor
>>> and version, for example.
>>>
>>>> OK, can you write down your proposed improvements to the interface?
>>>> In case you have something ready, otherwise there is time pressure
>>>> to merge the ARM port.
>>>
>>> My original request was just to change the name to something like
>>> KVM_SET_DEVICE_CONFIG or KVM_SET_DEVICE_ATTR, and not make the id
>>> encoding architecture-specific (preferably, separate into a "device id"
>>> field and an "attribute id" field rather than using bitfields). Actual
>>> values for device id could be architecture-specific (or there could be a
>>> global enumeration), and attribute id values would be device-specific.
>>>
>>> Alex suggested that an ideal interface might accept values larger than 64
>>> bits, though I think it's good enough -- there are currently no proposed
>>> uses that need more than 64 bits for a single attribute (unlike ONE_REG),
>>> and if it is needed, such configuration could be split up between
>>> multiple attributes, or the attribute could specify that "value" be a
>>> userspace pointer to the actual data (as with ONE_REG).
>>>
>>> Here's a writeup (the ARM details would go under ARM/vGIC-specific
>>> documentation):
>>>
>>> 4.80 KVM_SET_DEVICE_ATTR
>>>
>>> Capability: KVM_CAP_SET_DEVICE_ATTR
>>> Type: vm ioctl
>>> Parameters: struct kvm_device_attr (in)
>>> Returns: 0 on success, -1 on error
>>> Errors:
>>> ENODEV: The device id is unknown
>>> ENXIO: Device not supported on current system
>>> Other errors may be returned by specific devices and attributes.
>>>
>>> struct kvm_device_attr {
>>> __u32 device;
>>> __u32 attr;
>>> __u64 value;
>>> };
>>>
>>> Specify an attribute of a device emulated or directly exposed by the
>>> kernel, which the host kernel needs to know about. The device field is an
>>> architecture-specific identifier for a specific device. The attr field
>>> is a device-specific identifier for a specific attribute. Individual
>>> attributes may have particular requirements for when they can and cannot
>>> be set.
>>>
>>>> That is, if you have interest/energy to spend in a possibly reusable
>>>> interface, as long as that does not delay integration of the ARM code,
>>>> i don't think the ARM people will mind that.
>>>
>>> The impression I've been given is that just about any change will delay
>>> the integration at this point. If that's the case, and everyone's OK
>>> with having an interface that is deprecated on arrival, then fine.
>>
>>
>> That is not entirely the case, but there wasn't event agreement on this revised API, and we didn't want to wait for weeks until a decision was made. Alex suggested we use a DEV_REG API similar to the ONE_REG API, but I am quite strongly against having such an API for this specific purpose as it is too semantically distant to what we do on ARM. (Having a DEV_REG API for other purposes might be fine though).
>>
>> So I have no problem with your suggestion, although we could consider having a size and addr field in the struct instead and be slightly more extensible. But I don't feel strongly about it.
>>
>> If we can agree on Scott's suggestion or with my modification (Alex, Gleb, Marcelo ?) then I'll change the KVM/ARM patches to use this and resend them right away. But we have to agree now!
>>
>> If not, I really think we should keep things as they are now, as we're really discussing idealistic scenarios here, and the ARM patches have been out of tree for long enough. As Marcelo pointed out, the benefits of the perfect API are really minimal.
>>
>> -Christoffer--
>
> Can you make KVM_SET_ARM_DEVICE address extensible?
> Add some reserved space and a flags field.
Can't we do this for the new ioctl that we all would agree on rather than the interim one that's only a short term solution for a greater problem?
Alex
^ permalink raw reply
* [PATCH 4/4] ARM: uncompress: support uncompress debug for multiplatform build
From: Olof Johansson @ 2013-01-11 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355319945-3199-5-git-send-email-shawn.guo@linaro.org>
Hi,
On Wed, Dec 12, 2012 at 09:45:45PM +0800, Shawn Guo wrote:
> When moving to multiplatform build, platforms lose the output from
> decompressor. Not only does it mean that we will never see message
> "Uncompressing Linux... done, booting the kernel.", but also that
> the debug facility in arch/arm/boot/compressed/head.S outputs nothing
> even DEBUG is turned on.
>
> The patch follows the approach handling DEBUG_LL to create a Kconfig
> symbol CONFIG_UNCOMPRESS_INCLUDE for choosing the correct uncompress
> header. For traditional build, mach/uncompress.h will be included in
> arch/arm/boot/compressed/misc.c. For multiplatform build with none
> DEBUG_LL port enabled, debug/uncompress/dummy.h will be used. And
> for multiplatform build with a DEBUG_LL port, platform specific
> uncompress header like debug/uncompress/imx.h will come to play.
>
> Different from traditional build that uncompress output and DEBUG_LL
> are two separated pieces, for multiplatform build uncompress output
> becomes a subset of DEBUG_LL and will not work unless DEBUG_LL is
> enabled.
>
> The arch/arm/include/debug/uncompress/imx.h is cleaned up and added
> here as an example to show how this approach works.
Since this requires you to define a debug uart to get uncompress output,
it would make more sense to do a generic wrapper that uses the debug
code generically, instead of having to add this kind of wrapper for
every platform. That would solve it for all of them at once.
-Olof
^ permalink raw reply
* [PATCH 08/16] ARM: bL_platsmp.c: make sure the GIC interface of a dying CPU is disabled
From: Nicolas Pitre @ 2013-01-11 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F054E7.9000004@ti.com>
On Fri, 11 Jan 2013, Santosh Shilimkar wrote:
> On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
> > Otherwise there might be some interrupts or IPIs becoming pending and the
> > CPU will not enter low power mode when doing a WFI. The effect of this
> > is a CPU that loops back into the kernel, go through the first man
> > election, signals itself as alive, and prevent the cluster from being
> > shut down.
> >
> > This could benefit from a better solution.
> >
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > ---
> > arch/arm/common/bL_platsmp.c | 1 +
> > arch/arm/common/gic.c | 6 ++++++
> > arch/arm/include/asm/hardware/gic.h | 2 ++
> > 3 files changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/common/bL_platsmp.c b/arch/arm/common/bL_platsmp.c
> > index 0ae44123bf..6a3b251b97 100644
> > --- a/arch/arm/common/bL_platsmp.c
> > +++ b/arch/arm/common/bL_platsmp.c
> > @@ -68,6 +68,7 @@ static void __ref bL_cpu_die(unsigned int cpu)
> > pcpu = mpidr & 0xff;
> > pcluster = (mpidr >> 8) & 0xff;
> > bL_set_entry_vector(pcpu, pcluster, NULL);
> > + gic_cpu_if_down();
>
> So for a case where CPU still don't power down for some reason even
> after CPU interface is disabled, can not listen to and SGI or PPI.
> Not sure if this happens on big.LITTLE but i have seen one such issue
> on Cortex-A9 based SOC.
Here the problem was the reverse i.e. a CPU wouldn't go down because
some pending SGIs prevented that.
Nicolas
^ permalink raw reply
* [GIT PULL V2] ARM: mvebu fixes for v3.8-rc3
From: Olof Johansson @ 2013-01-11 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50ef5850.2663340a.6dbf.ffffb886SMTPIN_ADDED_MISSING@mx.google.com>
On Thu, Jan 10, 2013 at 07:21:21PM +0000, Jason Cooper wrote:
> The following changes since commit ba607b6238a1f418c45b9d7f73212bcc6922da53:
>
> pinctrl: mvebu: make pdma clock on dove mandatory (2013-01-07 16:19:02 +0000)
>
> are available in the git repository at:
>
> git://git.infradead.org/users/jcooper/linux.git tags/mvebu_fixes_for_v3.8-rc3
Pulled, thanks.
-Olof
^ permalink raw reply
* [PATCH] ARM: VIC: use irq_domain_add_simple()
From: Grant Likely @ 2013-01-11 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbtn4Pz3uLCxDGOBSVW7vfLECf2UZkT5+X9ip1ZZFb8Lw@mail.gmail.com>
On Thu, 20 Dec 2012 19:45:24 +0100, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Dec 19, 2012 at 12:34 AM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>
> > It looks to me like the below patch breaks versatile because it makes
> > it try to register a linear irq_domain instead of the legacy one that
> > it needs. Here are the relevant commits:
> >
> > 07c9249f1: "ARM: 7554/1: VIC: use irq_domain_add_simple()"
> > 946c59a08: "ARM: vic: fix build warning caused by previous commit"
(sorry for the really late reply on this. I took a break at Christmas
and jetlag has been beating up my concentration since I got back. I
actually started writing this reply before Christmas, but the
investigation sidetracked me enough that I never finished it.)
> > I'm working on getting it properly sorted out (and more importantly
> > *simplified*), but in the mean time I think the above two commits need
> > to be reverted. Reverting them on my tree fixes booting for me.
>
> Isn't that a bit violent, can't we just fix the real bug?
I did try to fix the bug first, but it became more involved that I would
like for a stablization change (and I went down a lot of rabbit trails
in the process). I preferred reverting because this was all contained
to a single driver which can be backed out easily to have another cycle
for a correct fix. I did try your change though...
> Does the below patch work for you, it does two things:
>
> 1) Bump all Versatile IRQs to offset at 32, because it is using
> IRQ 0 which is NO_IRQ and illegal anyway so it's anyway
> a bug that should be fixed.
>
> 2) Make sure we call irq_create_mapping() if the start IRQ is
> anyway 0, as in the device tree case, and make sure to
> actually pass zero in that case.
In actual fact, only changing the offset to 32 is required to get
Versatile to boot with DT. That platform doesn't yet use vic_of_init().
It currently depends on pre-allocated irq_descs. Calling
irq_create_mapping() doesn't resolve this. I now have patches to rework
the versatile OF support to use irq_of_init(), but they aren't ready
for posting yet. Merging the bump to offset 32 would be fine for now.
> diff --git a/arch/arm/mach-versatile/include/mach/irqs.h
> b/arch/arm/mach-versatile/include/mach/irqs.h
> index bf44c61..0fd771c 100644
> --- a/arch/arm/mach-versatile/include/mach/irqs.h
> +++ b/arch/arm/mach-versatile/include/mach/irqs.h
> @@ -25,7 +25,7 @@
> * IRQ interrupts definitions are the same as the INT definitions
> * held within platform.h
> */
> -#define IRQ_VIC_START 0
> +#define IRQ_VIC_START 32
> #define IRQ_WDOGINT (IRQ_VIC_START + INT_WDOGINT)
> #define IRQ_SOFTINT (IRQ_VIC_START + INT_SOFTINT)
> #define IRQ_COMMRx (IRQ_VIC_START + INT_COMMRx)
> @@ -100,7 +100,7 @@
> /*
> * Secondary interrupt controller
> */
> -#define IRQ_SIC_START 32
> +#define IRQ_SIC_START 64
Since you're touching this line anyway, please change to:
#define IRQ_SIC_START (IRQ_VIC_START + 32)
> #define IRQ_SIC_MMCI0B (IRQ_SIC_START + SIC_INT_MMCI0B)
> #define IRQ_SIC_MMCI1B (IRQ_SIC_START + SIC_INT_MMCI1B)
> #define IRQ_SIC_KMI0 (IRQ_SIC_START + SIC_INT_KMI0)
> @@ -120,7 +120,7 @@
> #define IRQ_SIC_PCI1 (IRQ_SIC_START + SIC_INT_PCI1)
> #define IRQ_SIC_PCI2 (IRQ_SIC_START + SIC_INT_PCI2)
> #define IRQ_SIC_PCI3 (IRQ_SIC_START + SIC_INT_PCI3)
> -#define IRQ_SIC_END 63
> +#define IRQ_SIC_END 95
Similarly here: #define IRQ_SIC_END (IRQ_SIC_START + 31)
And then you can add my acked by for the irq number changes.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
g.
^ permalink raw reply
* [PATCH 0/2 v2] at91/ssc: fixes on ASoC tree for 3.8
From: Olof Johansson @ 2013-01-11 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1357912706.git.nicolas.ferre@atmel.com>
Hi,
On Fri, Jan 11, 2013 at 6:08 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> This material was designed to enter Mark's fixes queue, but as discussed with
> Olof, we can imagine merging everything through arm-soc or split the series (of
> 2 patches) and let them progress upstream separated (option that I do not like
> even if I know that the consequences are not so dramatic).
> So please, Olof, if you feel confortable with this series, tell us what you
> prefer and we will make our best to make this material go forward...
You're setting yourself up for awkward merges. The driver change is
strongly dependent on the device tree change by failing probe unless
the device tree update is there, while before this patch, it still
worked.
If you instead use the dts update if it's there, you can merge the two
through independent paths, and later make it mandatory to use the
pinctrl specification. That way you avoid these complicated merge
scenarios where you have to send your platform code through a
subsystem tree instead.
But to be honest, I don't think this is a fix, it's a feature that you
just didn't include in time for the merge window. I don't really see
them as appropriate 3.8 material at this point.
So, nack on this series. Please make the driver change non-dependent
on the new dtsi contents, and merge that through the ASoC tree. Then
the dtsi update can go through arm-soc, and later on you can make it
mandatory.
-Olof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox