* [PATCH 07/14] usb: ehci-omap: Instantiate PHY devices if required
From: Alan Stern @ 2013-01-11 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50EFF075.5090203@ti.com>
On Fri, 11 Jan 2013, Roger Quadros wrote:
> Alan,
>
> Thanks for the patch. I've pasted the version that builds and works and
> put you as the Author of the patch, hope it is fine.
As far as I can see, yours is the same as what I posted except that:
You altered the changes to ehci-hcd.c and Makefile to remove
the dependency on the ehci-mxc patch;
You made an unimportant whitespace change in ehci-omap.c
(moved a blank line before ehci_write()).
Right? It's hard to compare the patches directly because the one you
posted was whitespace-damaged.
Anyway, if this is okay and there's nothing wrong with the ehci-mxc
change (other than the comment for ehci->priv), I'll submit both of
them to Greg soon.
Alan Stern
^ permalink raw reply
* [PATCH 2/3] ARM: hw_breakpoint: Check function for OS Save and Restore mechanism
From: Will Deacon @ 2013-01-11 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357918138-20222-1-git-send-email-will.deacon@arm.com>
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
v7 debug introduced OS Save and Restore mechanism. On a v7 debug SinglePower
system, i.e a system without a separate core and debug power domain, which does
not support external debug over powerdown, it is implementation defined whether
OS Save and Restore is implemented.
v7.1 debug requires OS Save and Restore mechanism. v6 debug and v6.1 debug do
not implement it.
A new global variable bool has_ossr is introduced and is determined in
arch_hw_breakpoint_init() like debug_arch or the number of BRPs/WRPs.
The logic how to check if OS Save and Restore is supported has changed with
this patch. In reset_ctrl_regs() a mask consisting of OSLM[1] (OSLSR.3) and
OSLM[0] (OSLSR.0) was used to check if the system supports OS Save and
Restore. In the new function core_has_os_save_restore() only OSLM[0] is used.
It is not necessary to check OSLM[1] too since it is v7.1 debug specific and
v7.1 debug requires OS Save and Restore and thus OS Lock.
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/hw_breakpoint.h | 3 +++
arch/arm/kernel/hw_breakpoint.c | 28 +++++++++++++++++++++++-----
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/hw_breakpoint.h b/arch/arm/include/asm/hw_breakpoint.h
index 01169dd..eef55ea 100644
--- a/arch/arm/include/asm/hw_breakpoint.h
+++ b/arch/arm/include/asm/hw_breakpoint.h
@@ -85,6 +85,9 @@ static inline void decode_ctrl_reg(u32 reg,
#define ARM_DSCR_HDBGEN (1 << 14)
#define ARM_DSCR_MDBGEN (1 << 15)
+/* OSLSR os lock model bits */
+#define ARM_OSLSR_OSLM0 (1 << 0)
+
/* opcode2 numbers for the co-processor instructions. */
#define ARM_OP2_BVR 4
#define ARM_OP2_BCR 5
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 34e9375..201d440 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -50,6 +50,9 @@ static int core_num_wrps;
/* Debug architecture version. */
static u8 debug_arch;
+/* Does debug architecture support OS Save and Restore? */
+static bool has_ossr;
+
/* Maximum supported watchpoint length. */
static u8 max_watchpoint_len;
@@ -904,6 +907,23 @@ static struct undef_hook debug_reg_hook = {
.fn = debug_reg_trap,
};
+/* Does this core support OS Save and Restore? */
+static bool core_has_os_save_restore(void)
+{
+ u32 oslsr;
+
+ switch (get_debug_arch()) {
+ case ARM_DEBUG_ARCH_V7_1:
+ return true;
+ case ARM_DEBUG_ARCH_V7_ECP14:
+ ARM_DBG_READ(c1, c1, 4, oslsr);
+ if (oslsr & ARM_OSLSR_OSLM0)
+ return true;
+ default:
+ return false;
+ }
+}
+
static void reset_ctrl_regs(void *unused)
{
int i, raw_num_brps, err = 0, cpu = smp_processor_id();
@@ -931,11 +951,7 @@ static void reset_ctrl_regs(void *unused)
if ((val & 0x1) == 0)
err = -EPERM;
- /*
- * Check whether we implement OS save and restore.
- */
- ARM_DBG_READ(c1, c1, 4, val);
- if ((val & 0x9) == 0)
+ if (!has_ossr)
goto clear_vcr;
break;
case ARM_DEBUG_ARCH_V7_1:
@@ -1025,6 +1041,8 @@ static int __init arch_hw_breakpoint_init(void)
return 0;
}
+ has_ossr = core_has_os_save_restore();
+
/* Determine how many BRPs/WRPs are available. */
core_num_brps = get_num_brps();
core_num_wrps = get_num_wrps();
--
1.8.0
^ permalink raw reply related
* [PATCH 3/3] ARM: hw_breakpoint: Debug powerdown support for self-hosted debug
From: Will Deacon @ 2013-01-11 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357918138-20222-1-git-send-email-will.deacon@arm.com>
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
This patch introduces debug powerdown support for self-hosted debug for v7
and v7.1 debug architecture for a SinglePower system, i.e. a system without a
separate core and debug power domain. On a SinglePower system the OS Lock is
lost over a powerdown.
If CONFIG_CPU_PM is set the new function pm_init() registers hw_breakpoint
with CPU PM for a system supporting OS Save and Restore.
Receiving a CPU PM EXIT notifier indicates that a single CPU has exited a low
power state. A call to reset_ctrl_regs() is hooked into the CPU PM EXIT
notifier chain. This function makes sure that the sticky power-down is clear
(only v7 debug), the OS Double Lock is clear (only v7.1 debug) and it clears
the OS Lock for v7 debug (for a system supporting OS Save and Restore) and
v7.1 debug. Furthermore, it clears any vector-catch events and all
breakpoint/watchpoint control/value registers for v7 and v7.1 debug.
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
[will: removed redundant has_ossr check]
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/hw_breakpoint.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 201d440..5eae53e 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -28,6 +28,7 @@
#include <linux/perf_event.h>
#include <linux/hw_breakpoint.h>
#include <linux/smp.h>
+#include <linux/cpu_pm.h>
#include <asm/cacheflush.h>
#include <asm/cputype.h>
@@ -1032,6 +1033,30 @@ static struct notifier_block __cpuinitdata dbg_reset_nb = {
.notifier_call = dbg_reset_notify,
};
+#ifdef CONFIG_CPU_PM
+static int dbg_cpu_pm_notify(struct notifier_block *self, unsigned long action,
+ void *v)
+{
+ if (action == CPU_PM_EXIT)
+ reset_ctrl_regs(NULL);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block __cpuinitdata dbg_cpu_pm_nb = {
+ .notifier_call = dbg_cpu_pm_notify,
+};
+
+static void __init pm_init(void)
+{
+ cpu_pm_register_notifier(&dbg_cpu_pm_nb);
+}
+#else
+static inline void pm_init(void)
+{
+}
+#endif
+
static int __init arch_hw_breakpoint_init(void)
{
debug_arch = get_debug_arch();
@@ -1081,8 +1106,9 @@ static int __init arch_hw_breakpoint_init(void)
hook_ifault_code(FAULT_CODE_DEBUG, hw_breakpoint_pending, SIGTRAP,
TRAP_HWBKPT, "breakpoint debug exception");
- /* Register hotplug notifier. */
+ /* Register hotplug and PM notifiers. */
register_cpu_notifier(&dbg_reset_nb);
+ pm_init();
return 0;
}
arch_initcall(arch_hw_breakpoint_init);
--
1.8.0
^ permalink raw reply related
* [PATCH 0/6] Random collection of hyp-boot fixes and updates
From: Will Deacon @ 2013-01-11 15:34 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I've been collecting random patches to the hyp-boot code, but it's
reached the point where much of it should go in as fixes for 3.8, CC'd
to stable. I've included the full series here, with the fixes marked
for stable.
I plan to send the fixes to Russell next week and then the three updates
later for 3.9.
All feedback welcome,
Will
Dave Martin (1):
ARM: virt: Avoid bx instruction for compatibility with <=ARMv4
Marc Zyngier (2):
ARM: virt: boot secondary CPUs through the right entry point
ARM: virt: simplify __hyp_stub_install epilog
Russell King (1):
ARM: virt: avoid clobbering lr when forcing svc mode
Will Deacon (2):
ARM: virt: use PSR_N_BIT for detecting boot CPU mode mismatch
ARM: virt: hide CONFIG_ARM_VIRT_EXT from user
arch/arm/include/asm/assembler.h | 10 +++-------
arch/arm/include/asm/virt.h | 4 ++--
arch/arm/kernel/head.S | 2 +-
arch/arm/kernel/hyp-stub.S | 18 ++++++------------
arch/arm/mm/Kconfig | 10 +++-------
5 files changed, 15 insertions(+), 29 deletions(-)
--
1.8.0
^ permalink raw reply
* [PATCH 1/6] ARM: virt: Avoid bx instruction for compatibility with <=ARMv4
From: Will Deacon @ 2013-01-11 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357918457-20469-1-git-send-email-will.deacon@arm.com>
From: Dave Martin <dave.martin@linaro.org>
Non-T variants of ARMv4 do not support the bx instruction.
However, __hyp_stub_install is always called from the same
instruction set used to build the bulk of the kernel, so bx should
not be necessary.
This patch uses the traditional "mov pc" instead of bx.
Cc: <stable@vger.kernel.org>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
[will: fixed up remaining bx instruction]
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/hyp-stub.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
index 65b2417..3c60256 100644
--- a/arch/arm/kernel/hyp-stub.S
+++ b/arch/arm/kernel/hyp-stub.S
@@ -99,7 +99,7 @@ ENTRY(__hyp_stub_install_secondary)
* immediately.
*/
compare_cpu_mode_with_primary r4, r5, r6, r7
- bxne lr
+ movne pc, lr
/*
* Once we have given up on one CPU, we do not try to install the
@@ -111,7 +111,7 @@ ENTRY(__hyp_stub_install_secondary)
*/
cmp r4, #HYP_MODE
- bxne lr @ give up if the CPU is not in HYP mode
+ movne pc, lr @ give up if the CPU is not in HYP mode
/*
* Configure HSCTLR to set correct exception endianness/instruction set
@@ -200,7 +200,7 @@ ENDPROC(__hyp_get_vectors)
@ fall through
ENTRY(__hyp_set_vectors)
__HVC(0)
- bx lr
+ mov pc, lr
ENDPROC(__hyp_set_vectors)
#ifndef ZIMAGE
--
1.8.0
^ permalink raw reply related
* [PATCH 2/6] ARM: virt: boot secondary CPUs through the right entry point
From: Will Deacon @ 2013-01-11 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357918457-20469-1-git-send-email-will.deacon@arm.com>
From: Marc Zyngier <marc.zyngier@arm.com>
Secondary CPUs should use the __hyp_stub_install_secondary entry
point, so boot mode inconsistencies can be detected.
Cc: <stable@vger.kernel.org>
Acked-by: Dave Martin <dave.martin@linaro.org>
Reported-by: Ian Molton <ian.molton@collabora.co.uk>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/head.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 4eee351..16abc83 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -331,7 +331,7 @@ ENTRY(secondary_startup)
* as it has already been validated by the primary processor.
*/
#ifdef CONFIG_ARM_VIRT_EXT
- bl __hyp_stub_install
+ bl __hyp_stub_install_secondary
#endif
safe_svcmode_maskall r9
--
1.8.0
^ permalink raw reply related
* [PATCH 3/6] ARM: virt: simplify __hyp_stub_install epilog
From: Will Deacon @ 2013-01-11 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357918457-20469-1-git-send-email-will.deacon@arm.com>
From: Marc Zyngier <marc.zyngier@arm.com>
__hyp_stub_install duplicates quite a bit of safe_svcmode_maskall
by forcing the CPU back to SVC. This is unnecessary, as
safe_svcmode_maskall is called just after.
Furthermore, the way we build SPSR_hyp is buggy as we fail to mask
the interrupts, leading to interesting behaviours on TC2 + UEFI.
The fix is to simply remove this code and rely on safe_svcmode_maskall
to do the right thing.
Cc: <stable@vger.kernel.org>
Reviewed-by: Dave Martin <dave.martin@linaro.org>
Reported-by: Harry Liebel <harry.liebel@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/hyp-stub.S | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
index 3c60256..1315c4c 100644
--- a/arch/arm/kernel/hyp-stub.S
+++ b/arch/arm/kernel/hyp-stub.S
@@ -120,7 +120,8 @@ ENTRY(__hyp_stub_install_secondary)
* Eventually, CPU-specific code might be needed -- assume not for now
*
* This code relies on the "eret" instruction to synchronize the
- * various coprocessor accesses.
+ * various coprocessor accesses. This is done when we switch to SVC
+ * (see safe_svcmode_maskall).
*/
@ Now install the hypervisor stub:
adr r7, __hyp_stub_vectors
@@ -155,14 +156,7 @@ THUMB( orr r7, #(1 << 30) ) @ HSCTLR.TE
1:
#endif
- bic r7, r4, #MODE_MASK
- orr r7, r7, #SVC_MODE
-THUMB( orr r7, r7, #PSR_T_BIT )
- msr spsr_cxsf, r7 @ This is SPSR_hyp.
-
- __MSR_ELR_HYP(14) @ msr elr_hyp, lr
- __ERET @ return, switching to SVC mode
- @ The boot CPU mode is left in r4.
+ bx lr @ The boot CPU mode is left in r4.
ENDPROC(__hyp_stub_install_secondary)
__hyp_stub_do_trap:
--
1.8.0
^ permalink raw reply related
* [PATCH 4/6] ARM: virt: avoid clobbering lr when forcing svc mode
From: Will Deacon @ 2013-01-11 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357918457-20469-1-git-send-email-will.deacon@arm.com>
From: Russell King <rmk+kernel@arm.linux.org.uk>
The safe_svcmode_maskall macro is used to ensure that we are running in
svc mode, causing an exception return from hvc mode if required.
This patch removes the unneeded lr clobber from the macro and operates
entirely on the temporary parameter register instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[will: updated comment]
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/assembler.h | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index eb87200..05ee9ee 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -246,18 +246,14 @@
*
* This macro is intended for forcing the CPU into SVC mode at boot time.
* you cannot return to the original mode.
- *
- * Beware, it also clobers LR.
*/
.macro safe_svcmode_maskall reg:req
#if __LINUX_ARM_ARCH__ >= 6
mrs \reg , cpsr
- mov lr , \reg
- and lr , lr , #MODE_MASK
- cmp lr , #HYP_MODE
- orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT
+ eor \reg, \reg, #HYP_MODE
+ tst \reg, #MODE_MASK
bic \reg , \reg , #MODE_MASK
- orr \reg , \reg , #SVC_MODE
+ orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT | SVC_MODE
THUMB( orr \reg , \reg , #PSR_T_BIT )
bne 1f
orr \reg, \reg, #PSR_A_BIT
--
1.8.0
^ permalink raw reply related
* [PATCH 5/6] ARM: virt: use PSR_N_BIT for detecting boot CPU mode mismatch
From: Will Deacon @ 2013-01-11 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357918457-20469-1-git-send-email-will.deacon@arm.com>
During boot, we detect whether or not all CPUs are brought up in the
same mode and signal this to the kernel using the N bit in the SPSR.
This patch tidies up the checking code to use the PSR_N_BIT macro,
rather than hardcoding the bit field and commenting it as such.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/virt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
index 86164df..50af92b 100644
--- a/arch/arm/include/asm/virt.h
+++ b/arch/arm/include/asm/virt.h
@@ -24,9 +24,9 @@
/*
* Flag indicating that the kernel was not entered in the same mode on every
* CPU. The zImage loader stashes this value in an SPSR, so we need an
- * architecturally defined flag bit here (the N flag, as it happens)
+ * architecturally defined flag bit here.
*/
-#define BOOT_CPU_MODE_MISMATCH (1<<31)
+#define BOOT_CPU_MODE_MISMATCH PSR_N_BIT
#ifndef __ASSEMBLY__
--
1.8.0
^ permalink raw reply related
* [PATCH 6/6] ARM: virt: hide CONFIG_ARM_VIRT_EXT from user
From: Will Deacon @ 2013-01-11 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357918457-20469-1-git-send-email-will.deacon@arm.com>
ARM_VIRT_EXT is a property of CPU_V7, but does not adversely affect
other CPUs that can be built into the same kernel image (i.e. ARMv6+).
This patch defaults ARM_VIRT_EXT to y if CPU_V7, allowing hypervisors
such as KVM to make better use of the option and being able to rely
on hyp-mode boot support.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/mm/Kconfig | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 3fd629d..025d173 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -629,8 +629,9 @@ config ARM_THUMBEE
make use of it. Say N for code that can run on CPUs without ThumbEE.
config ARM_VIRT_EXT
- bool "Native support for the ARM Virtualization Extensions"
- depends on MMU && CPU_V7
+ bool
+ depends on MMU
+ default y if CPU_V7
help
Enable the kernel to make use of the ARM Virtualization
Extensions to install hypervisors without run-time firmware
@@ -640,11 +641,6 @@ config ARM_VIRT_EXT
use of this feature. Refer to Documentation/arm/Booting for
details.
- It is safe to enable this option even if the kernel may not be
- booted in HYP mode, may not have support for the
- virtualization extensions, or may be booted with a
- non-compliant bootloader.
-
config SWP_EMULATE
bool "Emulate SWP/SWPB instructions"
depends on !CPU_USE_DOMAINS && CPU_V7
--
1.8.0
^ permalink raw reply related
* [PATCH] ARM: let CPUs not being able to run in ARM mode enter in THUMB mode
From: Jonathan Austin @ 2013-01-11 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357904397-8476-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hi Uwe,
On 11/01/13 11:39, Uwe Kleine-K?nig wrote:
> Some ARM cores are not capable to run in ARM mode (e.g. Cortex-M3). So
> obviously these cannot enter the kernel in ARM mode. Make an exception
> for them and let them enter in THUMB mode.
Clearly something like this is necessary, but it isn't something I'd
like for people to start using *unless* they have a THUMB only CPU (for
example, to work around dodgy boot-loaders, etc)
Seeing as there are no THUMB-only CPUs with an MMU, I think we could
safely constrain this change to:
a) depend on !MMU
b) only touch head-nommu.S
Does that cause any issue for what you're doing.
[...]
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 3fd629d..bc3150c 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -1,5 +1,11 @@
> comment "Processor Type"
>
> +# Select this if your CPU doesn't support the 32 bit ARM instructions.
> +config THUMBONLY_CPU
> + bool
> + select THUMB2_KERNEL
> + select ARM_THUMB
> +
> # Select CPU types depending on the architecture selected. This selects
> # which CPUs we support in the kernel image, and the compiler instruction
> # optimiser behaviour.
Also, a couple of minor questions about this:
- What's the rationale for the placement within the file - it looks a
bit curious up the top there.
- Given the fact that we don't want people using this except in very
specific circumstances, should we write a little bit of help for the option?
Jonny
^ permalink raw reply
* [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
From: Arnd Bergmann @ 2013-01-11 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130111034015.GA28094@avionic-0098.adnet.avionic-design.de>
On Friday 11 January 2013, Thierry Reding wrote:
> Right, it'll need #ifdefs around the arch_{setup,teardown}_msi_irq(). Or
> select PCI_MSI unconditionally. Once this is merged I was going to post
> a patch that enables PCI_MSI in tegra_defconfig anyway. But it might be
> better to keep it optional anyway since the remainder of the code copes
> with it properly.
>
Actually, we need something better than that. You cannot define
arch_setup_msi_irq in a tegra specific pci host driver, because that
will seriously mess up other platforms in multiplatform configurations
by giving a link error when they also define this function, or with a
run-time error when they don't support it.
I think what we should do here is fix it the right way by adding
a pci host specific callback rather than an architecture specific
callback in drivers/pci/msi.c. There is already a default version
of arch_setup_msi_irqs (with s), and we can probably do the
same for arch_setup_msi_irq (without s) to fall back to the
arch version for most architectures.
Most architectures (at least powerpc, sparc, ia64 and x86) already
multiplex the msi handlers internally, but ARM does not because
there is only one implementation (iop33x) at the moment.
We can add a generix multiplex and then move architectures over to
use it.
Arnd
^ permalink raw reply
* [PATCH 6/6] ARM: virt: hide CONFIG_ARM_VIRT_EXT from user
From: Christopher Covington @ 2013-01-11 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357918457-20469-7-git-send-email-will.deacon@arm.com>
Hi Will,
On 01/11/2013 10:34 AM, Will Deacon wrote:
> ARM_VIRT_EXT is a property of CPU_V7, but does not adversely affect
> other CPUs that can be built into the same kernel image (i.e. ARMv6+).
>
> This patch defaults ARM_VIRT_EXT to y if CPU_V7, allowing hypervisors
> such as KVM to make better use of the option and being able to rely
> on hyp-mode boot support.
[...]
> @@ -640,11 +641,6 @@ config ARM_VIRT_EXT
> use of this feature. Refer to Documentation/arm/Booting for
> details.
>
> - It is safe to enable this option even if the kernel may not be
> - booted in HYP mode, may not have support for the
> - virtualization extensions, or may be booted with a
> - non-compliant bootloader.
Why take this out?
[...]
Regards,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
the Linux Foundation
^ permalink raw reply
* [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS
From: Alexander Graf @ 2013-01-11 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357866627.27576.21@snotra>
On 11.01.2013, at 02:10, Scott Wood 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;
This needs some semantic specification. Is device a constant value? Is it the return value of CREATE_IRQCHIP?
> __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.
To me it's perfectly fine to merge the patches with the arm specific interface and then push an interface like the above in in the next merge window.
Alex
^ permalink raw reply
* [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
From: Thierry Reding @ 2013-01-11 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301111536.14799.arnd@arndb.de>
On Fri, Jan 11, 2013 at 03:36:14PM +0000, Arnd Bergmann wrote:
> On Friday 11 January 2013, Thierry Reding wrote:
> > Right, it'll need #ifdefs around the arch_{setup,teardown}_msi_irq(). Or
> > select PCI_MSI unconditionally. Once this is merged I was going to post
> > a patch that enables PCI_MSI in tegra_defconfig anyway. But it might be
> > better to keep it optional anyway since the remainder of the code copes
> > with it properly.
> >
> Actually, we need something better than that. You cannot define
> arch_setup_msi_irq in a tegra specific pci host driver, because that
> will seriously mess up other platforms in multiplatform configurations
> by giving a link error when they also define this function, or with a
> run-time error when they don't support it.
>
> I think what we should do here is fix it the right way by adding
> a pci host specific callback rather than an architecture specific
> callback in drivers/pci/msi.c. There is already a default version
> of arch_setup_msi_irqs (with s), and we can probably do the
> same for arch_setup_msi_irq (without s) to fall back to the
> arch version for most architectures.
> Most architectures (at least powerpc, sparc, ia64 and x86) already
> multiplex the msi handlers internally, but ARM does not because
> there is only one implementation (iop33x) at the moment.
>
> We can add a generix multiplex and then move architectures over to
> use it.
I already hinted at that in one of the other subthreads. Having such a
multiplex would also allow the driver to be built as a module. I had
already thought about this when I was working on an earlier version of
these patches. Basically these would be two ops attached to the host
bridge, and the generic arch_setup_msi_irq() could then look that up
given the struct pci_dev that is passed to it and call this new per-
host bridge .setup_msi_irq().
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130111/2731df24/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] ARM: ux500: Provide a link from AB8500 Pinctrl to the PRCMU
From: Lee Jones @ 2013-01-11 15:45 UTC (permalink / raw)
To: linux-arm-kernel
The AB8500 Pinctrl driver uses PRCMU register addresses to
control Pinctrl related functions. For this to happen, the
Pinctrl driver needs the PRCMU base to work from. We can do
that using standard Open Firmware (of_*) function calls, but
first we need a mechanism to gain access to the PRCMU
device node. We're going to use a Phandle in this case.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index db69f3c..3381ba6 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -170,10 +170,9 @@
gpio-bank = <8>;
};
- pinctrl at 80157000 {
- // This is actually the PRCMU base address
- reg = <0x80157000 0x2000>;
+ pinctrl {
compatible = "stericsson,nmk_pinctrl";
+ prcm = <&prcmu>;
};
usb at a03e0000 {
@@ -190,7 +189,7 @@
interrupts = <0 25 0x4>;
};
- prcmu at 80157000 {
+ prcmu: prcmu at 80157000 {
compatible = "stericsson,db8500-prcmu";
reg = <0x80157000 0x2000>;
interrupts = <0 47 0x4>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] pinctrl: nomadik: Allow prcm_base to be extracted from Device Tree
From: Lee Jones @ 2013-01-11 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357919129-1928-1-git-send-email-lee.jones@linaro.org>
The Nomadik Pinctrl driver requires access to some PRCMU registers
in order to run with full functionality. When Device Tree is
disabled the required PRCMU base address is passed in via platform
data, so in order for Device Tree booting to be as functional, we
need a similar mechanism to fetch it from Device Tree.
The new semantics goes like this: Parse the Device Tree and look
for the PRCMU node using a provided Phandle. Obtain the ioremaped
address from that node. If one was supplied via platform data
over-write it with anything found in Device Tree. Fail if either
the prcm_base can't be found if we're running on anything other
than an STN8815 ASIC.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/pinctrl/pinctrl-nomadik.c | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index 292c909..4954302 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -25,6 +25,7 @@
#include <linux/irqdomain.h>
#include <linux/slab.h>
#include <linux/of_device.h>
+#include <linux/of_address.h>
#include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/pinmux.h>
#include <linux/pinctrl/pinconf.h>
@@ -1856,6 +1857,7 @@ static int nmk_pinctrl_probe(struct platform_device *pdev)
{
const struct platform_device_id *platid = platform_get_device_id(pdev);
struct device_node *np = pdev->dev.of_node;
+ struct device_node *prcm_np;
struct nmk_pinctrl *npct;
struct resource *res;
unsigned int version = 0;
@@ -1884,21 +1886,26 @@ static int nmk_pinctrl_probe(struct platform_device *pdev)
if (version == PINCTRL_NMK_DB8540)
nmk_pinctrl_db8540_init(&npct->soc);
+ if (np) {
+ prcm_np = of_parse_phandle(np, "prcm", 0);
+ if (prcm_np)
+ npct->prcm_base = of_iomap(prcm_np, 0);
+ }
+
+ /* Allow platform passed information to over-write DT. */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res) {
+ if (res)
npct->prcm_base = devm_ioremap(&pdev->dev, res->start,
resource_size(res));
- if (!npct->prcm_base) {
- dev_err(&pdev->dev,
- "failed to ioremap PRCM registers\n");
- return -ENOMEM;
+ if (!npct->prcm_base) {
+ if (version == PINCTRL_NMK_STN8815) {
+ dev_info(&pdev->dev,
+ "No PRCM base, "
+ "assuming no ALT-Cx control is available\n");
+ } else {
+ dev_err(&pdev->dev, "missing PRCM base address\n");
+ return -EINVAL;
}
- } else if (version == PINCTRL_NMK_STN8815) {
- dev_info(&pdev->dev,
- "No PRCM base, assume no ALT-Cx control is available\n");
- } else {
- dev_err(&pdev->dev, "missing PRCM base address\n");
- return -EINVAL;
}
/*
--
1.7.9.5
^ permalink raw reply related
* [PATCH] cpsw: Add support to read cpu MAC address
From: Russell King - ARM Linux @ 2013-01-11 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357917302-32550-1-git-send-email-michal.bachraty@streamunlimited.com>
On Fri, Jan 11, 2013 at 04:15:02PM +0100, Michal Bachraty wrote:
> + if (!request_mem_region(priv->conf_res->start,
> + resource_size(priv->conf_res), ndev->name)) {
> + dev_err(priv->dev, "failed request i/o region\n");
> + ret = -ENXIO;
> + goto clean_clk_ret;
> + }
> +
> + regs = ioremap(priv->conf_res->start,
> + resource_size(priv->conf_res));
> + if (!regs) {
> + dev_err(priv->dev, "unable to map i/o region\n");
> + goto clean_configuration_iores_ret;
> + }
In this day and age where error paths don't get any testing, and are
frequently buggy, where we have alternative APIs which make those paths
more reliable, I think we should do everything to make use of that.
And, to prove the point, your error paths are buggy. Yes, you release
the mem region correctly (well done for picking the right interface for
that!) but the ioremap() is never cleaned up.
So, any chance of converting the above to devm_request_and_ioremap() ?
Thanks.
^ permalink raw reply
* [PATCH] ARM: let CPUs not being able to run in ARM mode enter in THUMB mode
From: Uwe Kleine-König @ 2013-01-11 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F0310F.3070502@arm.com>
Hi Jonny,
On Fri, Jan 11, 2013 at 03:34:39PM +0000, Jonathan Austin wrote:
> Hi Uwe,
> On 11/01/13 11:39, Uwe Kleine-K?nig wrote:
> >Some ARM cores are not capable to run in ARM mode (e.g. Cortex-M3). So
> >obviously these cannot enter the kernel in ARM mode. Make an exception
> >for them and let them enter in THUMB mode.
>
> Clearly something like this is necessary, but it isn't something I'd
> like for people to start using *unless* they have a THUMB only CPU
> (for example, to work around dodgy boot-loaders, etc)
>
> Seeing as there are no THUMB-only CPUs with an MMU, I think we could
> safely constrain this change to:
> a) depend on !MMU
> b) only touch head-nommu.S
>
> Does that cause any issue for what you're doing.
Would be ok for me, too. I don't care much.
> >diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> >index 3fd629d..bc3150c 100644
> >--- a/arch/arm/mm/Kconfig
> >+++ b/arch/arm/mm/Kconfig
> >@@ -1,5 +1,11 @@
> > comment "Processor Type"
> >
> >+# Select this if your CPU doesn't support the 32 bit ARM instructions.
> >+config THUMBONLY_CPU
> >+ bool
> >+ select THUMB2_KERNEL
> >+ select ARM_THUMB
> >+
> > # Select CPU types depending on the architecture selected. This selects
> > # which CPUs we support in the kernel image, and the compiler instruction
> > # optimiser behaviour.
>
> Also, a couple of minor questions about this:
> - What's the rationale for the placement within the file - it looks
> a bit curious up the top there.
Conceptually it's a symbol that is selected by the different processor
symbols. So IMHO it's fine to have it in front of the processor symbols.
Maybe it should even go before the line reading:
comment "Processor Type"
. OTOH similar symbols (like CPU_32v4, CPU_CP15) are at the end, too.
So yes, probably it's better to move it further down. And maybe rename
it to CPU_THUMBONLY?
> - Given the fact that we don't want people using this except in very
> specific circumstances, should we write a little bit of help for the
> option?
I can move what I wrote in the comment above the symbol into a help text
instead.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
From: 'Joerg Roedel' @ 2013-01-11 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <02ae01cdef69$67d66200$37832600$@samsung.com>
Hi Kukjin,
On Thu, Jan 10, 2013 at 11:33:41AM -0800, Kukjin Kim wrote:
> Sure, keep going on with
>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Done that. Applied the patch, some manual work was necessary as the
patch didn't apply cleanly to v3.8-rc3. Please double-check if the
result is correct.
> OK, good. Let me know the name of branch when you set-up it :-)
I pushed the branch to
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git arm/exynos
>From there you can pull it into your tree.
Have fun,
Joerg
^ permalink raw reply
* Question:add Iirq mask method in irq disable call.
From: Thomas Gleixner @ 2013-01-11 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKvkGKfG-3Y=azedkPyLwYffZKOE0sYH6LjMCfuMAgMKMBYWGA@mail.gmail.com>
On Fri, 11 Jan 2013, steve.zhan wrote:
> Resend Email because MUTT email send error.
>
> 2013/1/11 Steve zhan <zhanzhenbo@gmail.com>:
> > All:
> > I have find that arm gic driver have not register irq_disable
> > method, as below:
> > static struct irq_chip gic_chip = {
> > .name = "GIC",
> > .irq_mask = gic_mask_irq,
> > .irq_unmask = gic_unmask_irq,
> > .irq_eoi = gic_eoi_irq,
> > .irq_set_type = gic_set_type,
> > .irq_retrigger = gic_retrigger,
> > #ifdef CONFIG_SMP
> > .irq_set_affinity = gic_set_affinity,
> > #endif
> > .irq_set_wake = gic_set_wake,
> > };
> >
> > Question is:
> > When some drivers want to disable irq, maybe it will call
> > linux standard inerface: irq_disable() that defined in include\
> > linux\interrupt.h, this function will call
> > void irq_disable(struct irq_desc *desc)
> > {
> > irq_state_set_disabled(desc);
> > if (desc->irq_data.chip->irq_disable) {
> > desc->irq_data.chip->irq_disable(&desc->irq_data);
> > irq_state_set_masked(desc);
> > }
> > }
> >
> > Because gic have not register irq_diable method, so the interrupt can
> > not disable immediately, it is enable until the interrupt come next time,
> > then disalbed by mask because irq_state_set_disable(desc);
> >
> > I have checked irq_enable method:
> > void irq_enable(struct irq_desc *desc)
> > {
> > irq_state_clr_disabled(desc);
> > if (desc->irq_data.chip->irq_enable)
> > desc->irq_data.chip->irq_enable(&desc->irq_data);
> > else
> > desc->irq_data.chip->irq_unmask(&desc->irq_data);
> > irq_state_clr_masked(desc);
> > }
> > This method have do unmask when irq_enable method is not exist.
> >
> > Is it a good idea to add irq_mask call in irq_disable()?
No. It's a very bad idea. We intentionally disable interrupts lazy.
Thanks,
tglx
^ permalink raw reply
* [PATCH v3 0/9] Migrate Tegra to common clock framework
From: Marc Dietrich @ 2013-01-11 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50EFC8DB.6090903@nvidia.com>
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:
...
> > Second, the Toshiba AC100 uses an alternative driver for the I2C HW,
> > since it operates in I2C slave mode. So, the DT node for that driver
> > needs to include the clocks properties so the driver can get the clocks
> >
> > through DT:
> >> diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
> >> b/arch/arm/boot/dts/tegra20-paz00.dts index edef66c..6495425 100644
> >> --- a/arch/arm/boot/dts/tegra20-paz00.dts
> >> +++ b/arch/arm/boot/dts/tegra20-paz00.dts
> >> @@ -278,6 +278,8 @@
> >>
> >> clock-frequency = <50000>;
> >> request-gpios = <&gpio 170 0>; /* gpio PV2 */
> >> slave-addr = <138>;
> >>
> >> + clocks = <&tegra_car 67>, <&tegra_car 124>;
> >> + clock-names = "div-clk", "fast-clk";
> >>
> >> };
> >>
> >> i2c at 7000d000 {
> >
> > 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. Maybe you can also adjust the TODO (2nd entry) file now
that this issue is fixed.
Thanks for taking care of this.
Marc
^ permalink raw reply
* [PATCH 07/14] usb: ehci-omap: Instantiate PHY devices if required
From: Roger Quadros @ 2013-01-11 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1301111019340.1730-100000@iolanthe.rowland.org>
On 01/11/2013 05:28 PM, Alan Stern wrote:
> On Fri, 11 Jan 2013, Roger Quadros wrote:
>
>> Alan,
>>
>> Thanks for the patch. I've pasted the version that builds and works and
>> put you as the Author of the patch, hope it is fine.
>
> As far as I can see, yours is the same as what I posted except that:
>
> You altered the changes to ehci-hcd.c and Makefile to remove
> the dependency on the ehci-mxc patch;
>
> You made an unimportant whitespace change in ehci-omap.c
> (moved a blank line before ehci_write()).
>
> Right? It's hard to compare the patches directly because the one you
> posted was whitespace-damaged.
My bad pasting it. Patch is attached now.
Apart from what you mentioned I did some more trivial changes. e.g.
+ !IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) && \
instead of
+ !defined(CONFIG_USB_EHCI_HCD_OMAP) && \
use ehci_hcd_omap_driver instead of ehci_omap_driver
>
> Anyway, if this is okay and there's nothing wrong with the ehci-mxc
> change (other than the comment for ehci->priv), I'll submit both of
> them to Greg soon.
>
OK, thanks.
I tried using ehci->priv in ehci-omap driver but noticed that the
private data gets corrupted after the EHCI controller is running and has
enumerated a few devices.
If I disable USB_DEBUG then things are fine. Could it be possible
that someone is overflowing data when USB_DEBUG is enabled?
My implementation is pasted below. (May contain whitespace errors due to
MS exchange). Patch 2 attached in case.
What was happening there is that omap_priv->phy was not the same during
remove() as it was set to during probe().
Would be nice if you could check if the same happens with ehci-mxc.
cheers,
-roger
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 6388aa6..23c9b9c 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -70,6 +70,11 @@ static const char hcd_name[] = "ehci-omap";
/*-------------------------------------------------------------------------*/
+struct omap_ehci_hcd {
+ struct usb_hcd *hcd;
+ struct usb_phy **phy; /* one PHY for each port */
+ int nports;
+};
static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
{
@@ -194,6 +199,8 @@ static int ehci_hcd_omap_probe(struct
platform_device *pdev)
struct usbhs_omap_platform_data *pdata = dev->platform_data;
struct resource *res;
struct usb_hcd *hcd;
+ struct omap_ehci_hcd *omap_hcd;
+ struct usb_phy *phy;
void __iomem *regs;
int ret = -ENODEV;
int irq;
@@ -208,6 +215,25 @@ static int ehci_hcd_omap_probe(struct
platform_device *pdev)
return -ENODEV;
}
+ if (!pdata) {
+ dev_err(dev, "Missing platform data\n");
+ return -ENODEV;
+ }
+
+ omap_hcd = devm_kzalloc(&pdev->dev, sizeof(*omap_hcd), GFP_KERNEL);
+ if (!omap_hcd) {
+ dev_err(dev, "Memory allocation failed\n");
+ return -ENOMEM;
+ }
+
+ omap_hcd->nports = pdata->nports;
+ i = sizeof(struct usb_phy *) * omap_hcd->nports;
+ omap_hcd->phy = devm_kzalloc(&pdev->dev, i, GFP_KERNEL);
+ if (!omap_hcd->phy) {
+ dev_err(dev, "Memory allocation failed\n");
+ return -ENOMEM;
+ }
+
irq = platform_get_irq_byname(pdev, "ehci-irq");
if (irq < 0) {
dev_err(dev, "EHCI irq failed\n");
@@ -238,9 +264,15 @@ static int ehci_hcd_omap_probe(struct
platform_device *pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
hcd->regs = regs;
+ omap_hcd->hcd = hcd;
+
+ platform_set_drvdata(pdev, omap_hcd);
/* get ehci regulator and enable */
- for (i = 0 ; i < OMAP3_HS_USB_PORTS ; i++) {
+ for (i = 0 ; i < omap_hcd->nports ; i++) {
+ struct platform_device *phy_pdev;
+ struct usbhs_phy_config *phy_config;
+
if (pdata->port_mode[i] != OMAP_EHCI_PORT_MODE_PHY) {
pdata->regulator[i] = NULL;
continue;
@@ -254,6 +286,33 @@ static int ehci_hcd_omap_probe(struct
platform_device *pdev)
} else {
regulator_enable(pdata->regulator[i]);
}
+
+ /* instantiate PHY */
+ if (!pdata->phy_config[i]) {
+ dev_dbg(dev, "missing phy_config for port %d\n", i);
+ continue;
+ }
+
+ phy_config = pdata->phy_config[i];
+ phy_pdev = platform_device_register_data(&pdev->dev,
+ phy_config->name, i, phy_config->pdata,
+ phy_config->pdata_size);
+ if (IS_ERR(phy_pdev)) {
+ dev_dbg(dev, "error creating PHY device for port %d\n",
+ i);
+ }
+
+ phy = usb_get_phy_from_dev(&phy_pdev->dev);
+ if (IS_ERR(phy)) {
+ dev_dbg(dev, "could not get USB PHY for port %d\n", i);
+ platform_device_unregister(phy_pdev);
+ continue;
+ }
+
+ usb_phy_init(phy);
+ omap_hcd->phy[i] = phy;
+ /* bring PHY out of suspend */
+ usb_phy_set_suspend(omap_hcd->phy[i], 0);
}
pm_runtime_enable(dev);
@@ -284,6 +343,12 @@ err_pm_runtime:
disable_put_regulator(pdata);
pm_runtime_put_sync(dev);
usb_put_hcd(hcd);
+ for (i = 0 ; i < omap_hcd->nports ; i++) {
+ phy = omap_hcd->phy[i];
+ if (!phy)
+ continue;
+ platform_device_unregister(to_platform_device(phy->dev));
+ }
err_io:
iounmap(regs);
@@ -301,14 +366,26 @@ err_io:
*/
static int ehci_hcd_omap_remove(struct platform_device *pdev)
{
- struct device *dev = &pdev->dev;
- struct usb_hcd *hcd = dev_get_drvdata(dev);
+ struct device *dev = &pdev->dev;
+ struct omap_ehci_hcd *omap_hcd = dev_get_drvdata(dev);
+ struct usb_hcd *hcd = omap_hcd->hcd;
+ int i;
usb_remove_hcd(hcd);
disable_put_regulator(dev->platform_data);
iounmap(hcd->regs);
usb_put_hcd(hcd);
+ for (i = 0; i < omap_hcd->nports; i++) {
+ struct usb_phy *phy = omap_hcd->phy[i];
+
+ if (!phy)
+ continue;
+
+ usb_phy_shutdown(phy);
+ platform_device_unregister(to_platform_device(phy->dev));
+ }
+
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index d63eb7d..927b8a1 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -38,6 +38,12 @@ enum usbhs_omap_port_mode {
OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM
};
+struct usbhs_phy_config {
+ char *name; /* binds to device driver */
+ void *pdata; /* platform data for the phy */
+ size_t pdata_size;
+};
+
struct usbhs_omap_platform_data {
int nports;
enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
@@ -49,6 +55,8 @@ struct usbhs_omap_platform_data {
unsigned single_ulpi_bypass:1;
unsigned es2_compatibility:1;
unsigned phy_reset:1;
+
+ struct usbhs_phy_config *phy_config[OMAP3_HS_USB_PORTS];
};
/*-------------------------------------------------------------------------*/
--
1.7.4.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-USB-ehci-omap-Convert-to-platform-driver.patch
Type: text/x-patch
Size: 5842 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130111/84d5647c/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-usb-ehci-omap-Instantiate-PHY-devices-if-required.patch
Type: text/x-patch
Size: 5784 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130111/84d5647c/attachment-0003.bin>
^ permalink raw reply related
* [PATCH] ARM: let CPUs not being able to run in ARM mode enter in THUMB mode
From: Russell King - ARM Linux @ 2013-01-11 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357904397-8476-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Fri, Jan 11, 2013 at 12:39:57PM +0100, Uwe Kleine-K?nig wrote:
> +# Select this if your CPU doesn't support the 32 bit ARM instructions.
> +config THUMBONLY_CPU
> + bool
> + select THUMB2_KERNEL
> + select ARM_THUMB
Hmm, not convinced this is the best solution. Yes, fine for there to be
a THUMBONLY_CPU option, _but_ not the select statements onto user visible
symbols. We can get this instead by:
config THUMB2_KERNEL
bool "Compile the kernel in Thumb-2 mode" if !THUMBONLY_CPU
depends on (CPU_V7 && !CPU_V6 && !CPU_V6K) || THUMBONLY_CPU
default y if THUMBONLY_CPU
select AEABI
select ARM_ASM_UNIFIED
select ARM_UNWIND
and:
config ARM_THUMB
bool "Support Thumb user binaries" if !THUMBONLY_CPU
depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || \
CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || \
CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || \
CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || \
CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || \
CPU_V6K || CPU_V7 || CPU_FEROCEON || THUMBONLY_CPU
default y
And... I'm left wondering - should we have this instead:
config CPU_ARM
bool
config CPU_THUMB
bool
which indicates whether the CPU supports the ARM instruction set or the
Thumb instruction set (or both) - that should then allow us to select
those from the individual CPU_xxx options and eliminate that big long
list of dependencies against ARM_THUMB.
^ permalink raw reply
* [PATCH] ARM: kernel: DT cpu map validity check helper function
From: Lorenzo Pieralisi @ 2013-01-11 16:17 UTC (permalink / raw)
To: linux-arm-kernel
Since the introduction of /cpu nodes bindings for ARM and the
corresponding parse function arm_dt_init_cpu_maps(), the cpu_logical_map
and the number of possible CPUs are set according to the DT /cpu
nodes entries. Currently most of the existing ARM SMP platforms detect the
number of cores through HW probing in their .smp_init_cpus functions and set
the possible CPU mask accordingly.
This method should be upgraded so that the CPU counting mechanism will be
based on DT, keeping legacy HW probing mechanism as a fall back solution.
In order to implement this fall back solution mechanism, the ARM DT code
should provide a helper function to platforms to check if the cpu map
has been properly initialized through DT. If the check fails the
platform will resort to legacy HW based cores counting mechanism.
This patch implements a helper function that platforms can call to check
whether DT based cpu map initialization and cores count were completed
successfully.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
arch/arm/include/asm/prom.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index a219227..a913989 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -13,11 +13,21 @@
#define HAVE_ARCH_DEVTREE_FIXUPS
+#include <linux/cpumask.h>
+
#ifdef CONFIG_OF
extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
extern void arm_dt_memblock_reserve(void);
extern void __init arm_dt_init_cpu_maps(void);
+/*
+ * Return true if cpu map initialization has been
+ * carried out correctly from DT
+ */
+static inline bool __init arm_dt_cpu_map_valid(void)
+{
+ return !!(num_possible_cpus());
+}
#else /* CONFIG_OF */
@@ -28,6 +38,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
static inline void arm_dt_memblock_reserve(void) { }
static inline void arm_dt_init_cpu_maps(void) { }
+static inline bool __init arm_dt_cpu_map_valid(void) { return false; }
#endif /* CONFIG_OF */
#endif /* ASMARM_PROM_H */
--
1.7.12
^ permalink raw reply related
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