Re: [PATCH v3 1/2] memory-hotplug: introduce CONFIG_HAVE_BOOTMEM_INFO_NODE and revert register_page_bootmem_info_node() when platform not support

2013-01-17 Thread Lin Feng
Hi Michal,

On 01/17/2013 09:05 PM, Michal Hocko wrote:
> On Thu 17-01-13 18:37:10, Lin Feng wrote:
> [...]
>>> > > I am still not sure I understand the relation to MEMORY_HOTREMOVE.
>>> > > Is register_page_bootmem_info_node required/helpful even if
>>> > > !CONFIG_MEMORY_HOTREMOVE?
>> > From old kenrel's view register_page_bootmem_info_node() is defined in 
>> > CONFIG_MEMORY_HOTPLUG_SPARSE, it registers some info for 
>> > memory hotplug/remove. If we don't use MEMORY_HOTPLUG feature, this
>> > function is empty, we don't need the info at all.
>> > So this info is not required/helpful if !CONFIG_MEMORY_HOTREMOVE.
> OK, then I suggest moving it under CONFIG_MEMORY_HOTREMOVE guards rather
> than CONFIG_MEMORY_HOTPLUG.
I can't agree more ;-) 
I also find that page_isolation.c selected by MEMORY_ISOLATION under 
MEMORY_HOTPLUG
is also such case, I fix it by the way.

thanks,
linfeng
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 17/17] powerpc: Documentation for transactional memory on powerpc

2013-01-17 Thread Michael Neuling
Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 Documentation/powerpc/transactional_memory.txt |  175 
 1 file changed, 175 insertions(+)
 create mode 100644 Documentation/powerpc/transactional_memory.txt

diff --git a/Documentation/powerpc/transactional_memory.txt 
b/Documentation/powerpc/transactional_memory.txt
new file mode 100644
index 000..c907be4
--- /dev/null
+++ b/Documentation/powerpc/transactional_memory.txt
@@ -0,0 +1,175 @@
+Transactional Memory support
+
+
+POWER kernel support for this feature is currently limited to supporting
+its use by user programs.  It is not currently used by the kernel itself.
+
+This file aims to sum up how it is supported by Linux and what behaviour you
+can expect from your user programs.
+
+
+Basic overview
+==
+
+Hardware Transactional Memory is supported on POWER8 processors, and is a
+feature that enables a different form of atomic memory access.  Several new
+instructions are presented to delimit transactions; transactions are
+guaranteed to either complete atomically or roll back and undo any partial
+changes.
+
+A simple transaction looks like this:
+
+begin_move_money:
+  tbegin
+  beq   abort_handler
+
+  ldr4, SAVINGS_ACCT(r3)
+  ldr5, CURRENT_ACCT(r3)
+  subi  r5, r5, 1
+  addi  r4, r4, 1
+  std   r4, SAVINGS_ACCT(r3)
+  std   r5, CURRENT_ACCT(r3)
+
+  tend
+
+  b continue
+
+abort_handler:
+  ... test for odd failures ...
+
+  /* Retry the transaction if it failed because it conflicted with
+   * someone else: */
+  b begin_move_money
+
+
+The 'tbegin' instruction denotes the start point, and 'tend' the end point.
+Between these points the processor is in 'Transactional' state; any memory
+references will complete in one go if there are no conflicts with other
+transactional or non-transactional accesses within the system.  In this
+example, the transaction completes as though it were normal straight-line code
+IF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an
+atomic move of money from the current account to the savings account has been
+performed.  Even though the normal ld/std instructions are used (note no
+lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
+updated, or neither will be updated.
+
+If, in the meantime, there is a conflict with the locations accessed by the
+transaction, the transaction will be aborted by the CPU.  Register and memory
+state will roll back to that at the 'tbegin', and control will continue from
+'tbegin+4'.  The branch to abort_handler will be taken this second time; the
+abort handler can check the cause of the failure, and retry.
+
+Checkpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR
+and a few other status/flag regs; see the ISA for details.
+
+Causes of transaction aborts
+
+
+- Conflicts with cache lines used by other processors
+- Signals
+- Context switches
+- See the ISA for full documentation of everything that will abort 
transactions.
+
+
+Syscalls
+
+
+Performing syscalls from within transaction is not recommended, and can lead
+to unpredictable results.
+
+Syscalls do not by design abort transactions, but beware: The kernel code will
+not be running in transactional state.  The effect of syscalls will always
+remain visible, but depending on the call they may abort your transaction as a
+side-effect, read soon-to-be-aborted transactional data that should not remain
+invisible, etc.  If you constantly retry a transaction that constantly aborts
+itself by calling a syscall, you'll have a livelock & make no progress.
+
+Simple syscalls (e.g. sigprocmask()) "could" be OK.  Even things like write()
+from, say, printf() should be OK as long as the kernel does not access any
+memory that was accessed transactionally.
+
+Consider any syscalls that happen to work as debug-only -- not recommended for
+production use.  Best to queue them up till after the transaction is over.
+
+
+Signals
+===
+
+Delivery of signals (both sync and async) during transactions provides a second
+thread state (ucontext/mcontext) to represent the second transactional register
+state.  Signal delivery 'treclaim's to capture both register states, so signals
+abort transactions.  The usual ucontext_t passed to the signal handler
+represents the checkpointed/original register state; the signal appears to have
+arisen at 'tbegin+4'.
+
+If the sighandler ucontext has uc_link set, a second ucontext has been
+delivered.  For future compatibility the MSR.TS field should be checked to
+determine the transactional state -- if so, the second ucontext in uc->uc_link
+represents the active transactional registers at the point of the signal.
+
+For 64-bit processes, uc->uc_mcontext.regs->msr is a full 64-bit MSR and its TS
+field shows the transactional mode.
+
+For 32-bit processes, the mcontext's MSR register is only 32 bits; the top 32

[PATCH 16/17] powerpc: Add transactional memory to pseries and ppc64 defconfigs

2013-01-17 Thread Michael Neuling
Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/configs/ppc64_defconfig   |2 ++
 arch/powerpc/configs/pseries_defconfig |2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 6cbdeb4..01e2e86 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -49,6 +49,8 @@ CONFIG_CPU_FREQ_GOV_USERSPACE=y
 CONFIG_CPU_FREQ_PMAC64=y
 CONFIG_HZ_100=y
 CONFIG_BINFMT_MISC=m
+CONFIG_TRANSACTIONAL_MEM=y
+CONFIG_HOTPLUG_CPU=y
 CONFIG_KEXEC=y
 CONFIG_IRQ_ALL_CPUS=y
 CONFIG_MEMORY_HOTREMOVE=y
diff --git a/arch/powerpc/configs/pseries_defconfig 
b/arch/powerpc/configs/pseries_defconfig
index 04fa7f2..a50484f 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -43,6 +43,8 @@ CONFIG_RTAS_FLASH=m
 CONFIG_IBMEBUS=y
 CONFIG_HZ_100=y
 CONFIG_BINFMT_MISC=m
+CONFIG_TRANSACTIONAL_MEM=y
+CONFIG_HOTPLUG_CPU=y
 CONFIG_KEXEC=y
 CONFIG_IRQ_ALL_CPUS=y
 CONFIG_MEMORY_HOTPLUG=y
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 15/17] powerpc: Add config option for transactional memory

2013-01-17 Thread Michael Neuling
Kconfig option for transactional memory on powerpc.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/Kconfig |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 684fa64..349ed12 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -309,6 +309,14 @@ config MATH_EMULATION
  unit, which will allow programs that use floating-point
  instructions to run.
 
+config TRANSACTIONAL_MEM
+   bool "Transactional Memory support"
+   depends on PPC64
+   depends on SMP
+   default n
+   ---help---
+ Support user-mode Transactional Memory.
+
 config 8XX_MINIMAL_FPEMU
bool "Minimal math emulation for 8xx"
depends on 8xx && !MATH_EMULATION
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 14/17] powerpc: Add transactional memory to POWER8 cpu features

2013-01-17 Thread Michael Neuling
Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/include/asm/cputable.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 71a498b..5ab77f4 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -421,7 +421,7 @@ extern const char *powerpc_base_platform;
CPU_FTR_DSCR | CPU_FTR_SAO  | \
CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
-   CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_DAWR)
+   CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_DAWR | CPU_FTR_TM_COMP)
 #define CPU_FTRS_CELL  (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 13/17] powerpc: Add new transactional memory state to the signal context

2013-01-17 Thread Michael Neuling
This adds the new transactional memory archtected state to the signal context
in both 32 and 64 bit.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/include/asm/reg.h  |1 +
 arch/powerpc/kernel/signal.h|8 +
 arch/powerpc/kernel/signal_32.c |  500 ++-
 arch/powerpc/kernel/signal_64.c |  337 +-
 4 files changed, 830 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index d19581ae4..41894dc 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -120,6 +120,7 @@
 #define TM_CAUSE_FAC_UNAV  0xfa
 #define TM_CAUSE_SYSCALL   0xf9 /* Persistent */
 #define TM_CAUSE_MISC  0xf6
+#define TM_CAUSE_SIGNAL0xf4
 
 #if defined(CONFIG_PPC_BOOK3S_64)
 #define MSR_64BIT  MSR_SF
diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
index e00acb4..ec84c90 100644
--- a/arch/powerpc/kernel/signal.h
+++ b/arch/powerpc/kernel/signal.h
@@ -25,13 +25,21 @@ extern int handle_rt_signal32(unsigned long sig, struct 
k_sigaction *ka,
 
 extern unsigned long copy_fpr_to_user(void __user *to,
  struct task_struct *task);
+extern unsigned long copy_transact_fpr_to_user(void __user *to,
+  struct task_struct *task);
 extern unsigned long copy_fpr_from_user(struct task_struct *task,
void __user *from);
+extern unsigned long copy_transact_fpr_from_user(struct task_struct *task,
+void __user *from);
 #ifdef CONFIG_VSX
 extern unsigned long copy_vsx_to_user(void __user *to,
  struct task_struct *task);
+extern unsigned long copy_transact_vsx_to_user(void __user *to,
+  struct task_struct *task);
 extern unsigned long copy_vsx_from_user(struct task_struct *task,
void __user *from);
+extern unsigned long copy_transact_vsx_from_user(struct task_struct *task,
+void __user *from);
 #endif
 
 #ifdef CONFIG_PPC64
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 804e323..9dc2472 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_PPC64
 #include "ppc32.h"
 #include 
@@ -293,6 +294,10 @@ long sys_sigaction(int sig, struct old_sigaction __user 
*act,
 struct sigframe {
struct sigcontext sctx; /* the sigcontext */
struct mcontext mctx;   /* all the register values */
+#ifdef CONFIG_TRANSACTIONAL_MEM
+   struct sigcontext sctx_transact;
+   struct mcontext mctx_transact;
+#endif
/*
 * Programs using the rs6000/xcoff abi can save up to 19 gp
 * regs and 18 fp regs below sp before decrementing it.
@@ -321,6 +326,9 @@ struct rt_sigframe {
struct siginfo info;
 #endif
struct ucontext uc;
+#ifdef CONFIG_TRANSACTIONAL_MEM
+   struct ucontext uc_transact;
+#endif
/*
 * Programs using the rs6000/xcoff abi can save up to 19 gp
 * regs and 18 fp regs below sp before decrementing it.
@@ -381,6 +389,61 @@ unsigned long copy_vsx_from_user(struct task_struct *task,
task->thread.fpr[i][TS_VSRLOWOFFSET] = buf[i];
return 0;
 }
+
+#ifdef CONFIG_TRANSACTIONAL_MEM
+unsigned long copy_transact_fpr_to_user(void __user *to,
+ struct task_struct *task)
+{
+   double buf[ELF_NFPREG];
+   int i;
+
+   /* save FPR copy to local buffer then write to the thread_struct */
+   for (i = 0; i < (ELF_NFPREG - 1) ; i++)
+   buf[i] = task->thread.TS_TRANS_FPR(i);
+   memcpy(&buf[i], &task->thread.transact_fpscr, sizeof(double));
+   return __copy_to_user(to, buf, ELF_NFPREG * sizeof(double));
+}
+
+unsigned long copy_transact_fpr_from_user(struct task_struct *task,
+ void __user *from)
+{
+   double buf[ELF_NFPREG];
+   int i;
+
+   if (__copy_from_user(buf, from, ELF_NFPREG * sizeof(double)))
+   return 1;
+   for (i = 0; i < (ELF_NFPREG - 1) ; i++)
+   task->thread.TS_TRANS_FPR(i) = buf[i];
+   memcpy(&task->thread.transact_fpscr, &buf[i], sizeof(double));
+
+   return 0;
+}
+
+unsigned long copy_transact_vsx_to_user(void __user *to,
+ struct task_struct *task)
+{
+   double buf[ELF_NVSRHALFREG];
+   int i;
+
+   /* save FPR copy to local buffer then write to the thread_struct */
+   for (i = 0; i < ELF_NVSRHALFREG; i++)
+   buf[i] = task->thread.transact_fpr[i][TS_VSRLOWOFFSET];
+   return __copy_to_user(to, buf, ELF_NVSRHALFREG * si

[PATCH 12/17] powerpc: Hook in new transactional memory code

2013-01-17 Thread Michael Neuling
This hooks the new transactional memory code into context switching, FP/VMX/VMX
unavailable and exception return.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/kernel/exceptions-64s.S |   48 --
 arch/powerpc/kernel/fpu.S|1 -
 arch/powerpc/kernel/process.c|   15 +--
 arch/powerpc/kernel/traps.c  |   32 +++
 arch/powerpc/kernel/vector.S |1 -
 arch/powerpc/mm/hash_utils_64.c  |   13 +
 6 files changed, 104 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index d0cc657..c4a20d1 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1147,9 +1147,24 @@ fp_unavailable_common:
addir3,r1,STACK_FRAME_OVERHEAD
bl  .kernel_fp_unavailable_exception
BUG_OPCODE
-1: bl  .load_up_fpu
+1:
+#ifdef CONFIG_TRANSACTIONAL_MEM
+BEGIN_FTR_SECTION
+   srdir0, r12, MSR_TS_LG
+   andi.   r0, r0, 3
+   bne-2f
+END_FTR_SECTION_IFSET(CPU_FTR_TM)
+#endif
+   bl  .load_up_fpu
+   std r12,_MSR(r1)
b   fast_exception_return
-
+#ifdef CONFIG_TRANSACTIONAL_MEM
+2: /* User process was in a transaction */
+   bl  .save_nvgprs
+   addir3,r1,STACK_FRAME_OVERHEAD
+   bl  .fp_unavailable_tm
+   b   .ret_from_except
+#endif
.align  7
.globl altivec_unavailable_common
 altivec_unavailable_common:
@@ -1157,8 +1172,23 @@ altivec_unavailable_common:
 #ifdef CONFIG_ALTIVEC
 BEGIN_FTR_SECTION
beq 1f
+#ifdef CONFIG_TRANSACTIONAL_MEM
+  BEGIN_FTR_SECTION_NESTED(69)
+   srdir0, r12, MSR_TS_LG
+   andi.   r0, r0, 3
+   bne-2f
+  END_FTR_SECTION_NESTED(CPU_FTR_TM, CPU_FTR_TM, 69)
+#endif
bl  .load_up_altivec
+   std r12,_MSR(r1)
b   fast_exception_return
+#ifdef CONFIG_TRANSACTIONAL_MEM
+2: /* User process was in a transaction */
+   bl  .save_nvgprs
+   addir3,r1,STACK_FRAME_OVERHEAD
+   bl  .altivec_unavailable_tm
+   b   .ret_from_except
+#endif
 1:
 END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
 #endif
@@ -1175,7 +1205,21 @@ vsx_unavailable_common:
 #ifdef CONFIG_VSX
 BEGIN_FTR_SECTION
beq 1f
+#ifdef CONFIG_TRANSACTIONAL_MEM
+  BEGIN_FTR_SECTION_NESTED(69)
+   srdir0, r12, MSR_TS_LG
+   andi.   r0, r0, 3
+   bne-2f
+  END_FTR_SECTION_NESTED(CPU_FTR_TM, CPU_FTR_TM, 69)
+#endif
b   .load_up_vsx
+#ifdef CONFIG_TRANSACTIONAL_MEM
+2: /* User process was in a transaction */
+   bl  .save_nvgprs
+   addir3,r1,STACK_FRAME_OVERHEAD
+   bl  .vsx_unavailable_tm
+   b   .ret_from_except
+#endif
 1:
 END_FTR_SECTION_IFSET(CPU_FTR_VSX)
 #endif
diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
index 6ab0e87..08b6a12f 100644
--- a/arch/powerpc/kernel/fpu.S
+++ b/arch/powerpc/kernel/fpu.S
@@ -170,7 +170,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
lwz r4,THREAD_FPEXC_MODE(r5)
ori r12,r12,MSR_FP
or  r12,r12,r4
-   std r12,_MSR(r1)
 #endif
lfd fr0,THREAD_FPSCR(r5)
MTFSF_L(fr0)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 14fabd1..bccc81b 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -510,7 +510,7 @@ out_and_saveregs:
tm_save_sprs(thr);
 }
 
-static inline void __maybe_unused tm_recheckpoint_new_task(struct task_struct 
*new)
+static inline void tm_recheckpoint_new_task(struct task_struct *new)
 {
unsigned long msr;
 
@@ -585,6 +585,8 @@ struct task_struct *__switch_to(struct task_struct *prev,
struct ppc64_tlb_batch *batch;
 #endif
 
+   __switch_to_tm(prev);
+
 #ifdef CONFIG_SMP
/* avoid complexity of lazy save/restore of fpu
 * by just saving it every time we switch out if
@@ -700,6 +702,9 @@ struct task_struct *__switch_to(struct task_struct *prev,
 * of sync. Hard disable here.
 */
hard_irq_disable();
+
+   tm_recheckpoint_new_task(new);
+
last = _switch(old_thread, new_thread);
 
 #ifdef CONFIG_PPC_BOOK3S_64
@@ -1075,7 +1080,6 @@ void start_thread(struct pt_regs *regs, unsigned long 
start, unsigned long sp)
regs->msr = MSR_USER32;
}
 #endif
-
discard_lazy_cpu_state();
 #ifdef CONFIG_VSX
current->thread.used_vsr = 0;
@@ -1095,6 +1099,13 @@ void start_thread(struct pt_regs *regs, unsigned long 
start, unsigned long sp)
current->thread.spefscr = 0;
current->thread.used_spe = 0;
 #endif /* CONFIG_SPE */
+#ifdef CONFIG_TRANSACTIONAL_MEM
+   if (cpu_has_feature(CPU_FTR_TM))
+   regs->msr |= MSR_TM;
+   current->thread.tm_tfhar = 0;
+   current->thread.tm_texasr = 0;
+   current->thread.tm_tfiar = 0;
+#end

[PATCH 11/17] powerpc: Assembler routines for FP/VSX/VMX unavailable during a transaction

2013-01-17 Thread Michael Neuling
We do lazy FP but not lazy TM (ie. userspace starts with MSR TM=1 FP=0).  Hence
if userspace does an FP instruction during a transaction, we'll take an
fp unavailable exception.

This adds functions needed to handle this case.  We have to inject the current
FP state into the checkpoint so that the hardware can decide what to do with
the transaction.  We can't inject only the FP so we have to do a full treclaim
and recheckpoint to inject just the FP state.  This will cause the transaction
to be marked as aborted by the hardware.

This just add the routines needed to do this for FP, VMX and VSX.  It doesn't
hook them into the rest of the code yet.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/kernel/traps.c |   95 +++
 1 file changed, 95 insertions(+)

diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index dda0517..311770d 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -58,6 +58,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
@@ -1192,6 +1193,100 @@ void tm_unavailable_exception(struct pt_regs *regs)
die("Unexpected TM unavailable exception", regs, SIGABRT);
 }
 
+#ifdef CONFIG_TRANSACTIONAL_MEM
+
+extern void do_load_up_fpu(struct pt_regs *regs);
+
+void fp_unavailable_tm(struct pt_regs *regs)
+{
+   /* Note:  This does not handle any kind of FP laziness. */
+
+   /* We restore the interrupt state now */
+   if (!arch_irq_disabled_regs(regs))
+   local_irq_enable();
+
+   TM_DEBUG("FP Unavailable trap whilst transactional at 0x%lx, MSR=%lx\n",
+regs->nip, regs->msr);
+   tm_enable();
+
+/* We can only have got here if the task started using FP after
+ * beginning the transaction.  So, the transactional regs are just a
+ * copy of the checkpointed ones.  But, we still need to recheckpoint
+ * as we're enabling FP for the process; it will return, abort the
+ * transaction, and probably retry but now with FP enabled.  So the
+ * checkpointed FP registers need to be loaded.
+*/
+   tm_reclaim(¤t->thread, current->thread.regs->msr,
+  TM_CAUSE_FAC_UNAV);
+   /* Reclaim didn't save out any FPRs to transact_fprs. */
+
+   /* Enable FP for the task: */
+   regs->msr |= (MSR_FP | current->thread.fpexc_mode);
+
+   /* This loads and recheckpoints the FP registers from
+* thread.fpr[].  They will remain in registers after the
+* checkpoint so we don't need to reload them after.
+*/
+   tm_recheckpoint(¤t->thread, regs->msr);
+}
+
+#ifdef CONFIG_ALTIVEC
+extern void do_load_up_altivec(struct pt_regs *regs);
+
+void altivec_unavailable_tm(struct pt_regs *regs)
+{
+   /* See the comments in fp_unavailable_tm().  This function operates
+* the same way.
+*/
+
+   /* We restore the interrupt state now */
+   if (!arch_irq_disabled_regs(regs))
+   local_irq_enable();
+
+   TM_DEBUG("Vector Unavailable trap whilst transactional at 0x%lx,"
+"MSR=%lx\n",
+regs->nip, regs->msr);
+   tm_enable();
+   tm_reclaim(¤t->thread, current->thread.regs->msr,
+  TM_CAUSE_FAC_UNAV);
+   regs->msr |= MSR_VEC;
+   tm_recheckpoint(¤t->thread, regs->msr);
+   current->thread.used_vr = 1;
+}
+#endif
+
+#ifdef CONFIG_VSX
+void vsx_unavailable_tm(struct pt_regs *regs)
+{
+   /* See the comments in fp_unavailable_tm().  This works similarly,
+* though we're loading both FP and VEC registers in here.
+*
+* If FP isn't in use, load FP regs.  If VEC isn't in use, load VEC
+* regs.  Either way, set MSR_VSX.
+*/
+
+   /* We restore the interrupt state now */
+   if (!arch_irq_disabled_regs(regs))
+   local_irq_enable();
+
+   TM_DEBUG("VSX Unavailable trap whilst transactional at 0x%lx,"
+"MSR=%lx\n",
+regs->nip, regs->msr);
+
+   tm_enable();
+   /* This reclaims FP and/or VR regs if they're already enabled */
+   tm_reclaim(¤t->thread, current->thread.regs->msr,
+  TM_CAUSE_FAC_UNAV);
+
+   regs->msr |= MSR_VEC | MSR_FP | current->thread.fpexc_mode |
+   MSR_VSX;
+   /* This loads & recheckpoints FP and VRs. */
+   tm_recheckpoint(¤t->thread, regs->msr);
+   current->thread.used_vsr = 1;
+}
+#endif
+#endif /* CONFIG_TRANSACTIONAL_MEM */
+
 void performance_monitor_exception(struct pt_regs *regs)
 {
__get_cpu_var(irq_stat).pmu_irqs++;
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 10/17] powerpc: Add transactional memory unavaliable execption handler

2013-01-17 Thread Michael Neuling
These should never happen since we always turn on MSR TM when in userspace. We
don't do lazy TM.

Hence if we hit this, we barf and kill the task as something's gone horribly
wrong.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/kernel/exceptions-64s.S |   19 +++
 arch/powerpc/kernel/traps.c  |   21 +
 2 files changed, 40 insertions(+)

diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index 7a1c87c..d0cc657 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -313,6 +313,9 @@ vsx_unavailable_pSeries_1:
. = 0xf40
b   vsx_unavailable_pSeries
 
+   . = 0xf60
+   b   tm_unavailable_pSeries
+
 #ifdef CONFIG_CBE_RAS
STD_EXCEPTION_HV(0x1200, 0x1202, cbe_system_error)
KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0x1202)
@@ -528,6 +531,8 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0xf20)
STD_EXCEPTION_PSERIES(., 0xf40, vsx_unavailable)
KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0xf40)
+   STD_EXCEPTION_PSERIES(., 0xf60, tm_unavailable)
+   KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0xf60)
 
 /*
  * An interrupt came in while soft-disabled. We set paca->irq_happened, then:
@@ -817,6 +822,10 @@ vsx_unavailable_relon_pSeries_1:
. = 0x4f40
b   vsx_unavailable_relon_pSeries
 
+tm_unavailable_relon_pSeries_1:
+   . = 0x4f60
+   b   tm_unavailable_relon_pSeries
+
 #ifdef CONFIG_CBE_RAS
STD_RELON_EXCEPTION_HV(0x5200, 0x1202, cbe_system_error)
 #endif /* CONFIG_CBE_RAS */
@@ -1177,6 +1186,15 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
b   .ret_from_except
 
.align  7
+   .globl tm_unavailable_common
+tm_unavailable_common:
+   EXCEPTION_PROLOG_COMMON(0xf60, PACA_EXGEN)
+   bl  .save_nvgprs
+   addir3,r1,STACK_FRAME_OVERHEAD
+   bl  .tm_unavailable_exception
+   b   .ret_from_except
+
+   .align  7
.globl  __end_handlers
 __end_handlers:
 
@@ -1195,6 +1213,7 @@ __end_handlers:
STD_RELON_EXCEPTION_PSERIES(., 0xf00, performance_monitor)
STD_RELON_EXCEPTION_PSERIES(., 0xf20, altivec_unavailable)
STD_RELON_EXCEPTION_PSERIES(., 0xf40, vsx_unavailable)
+   STD_RELON_EXCEPTION_PSERIES(., 0xf60, tm_unavailable)
 
 #if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
 /*
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 2a62f54..dda0517 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1171,6 +1171,27 @@ void vsx_unavailable_exception(struct pt_regs *regs)
die("Unrecoverable VSX Unavailable Exception", regs, SIGABRT);
 }
 
+void tm_unavailable_exception(struct pt_regs *regs)
+{
+   /* We restore the interrupt state now */
+   if (!arch_irq_disabled_regs(regs))
+   local_irq_enable();
+
+   /* Currently we never expect a TMU exception.  Catch
+* this and kill the process!
+*/
+   printk(KERN_EMERG "Unexpected TM unavailable exception at %lx "
+  "(msr %lx)\n",
+  regs->nip, regs->msr);
+
+   if (user_mode(regs)) {
+   _exception(SIGILL, regs, ILL_ILLOPC, regs->nip);
+   return;
+   }
+
+   die("Unexpected TM unavailable exception", regs, SIGABRT);
+}
+
 void performance_monitor_exception(struct pt_regs *regs)
 {
__get_cpu_var(irq_stat).pmu_irqs++;
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 09/17] powerpc: Add reclaim and recheckpoint functions for context switching transactional memory processes

2013-01-17 Thread Michael Neuling
When we switch out a task, we need to save both the checkpointed and the
speculated state into the thread struct.

Similarly when we are switching in a task we need to load both the checkpointed
and speculated state.  If the task was using FP, we non-lazily reload both the
original and the speculative FP register states.  This is because the kernel
doesn't see if/when a TM rollback occurs, so if we take an FP unavoidable
later, we are unable to determine which set of FP regs need to be restored.

This simply adds these functions.  It doesn't hook them into the existing code
yet.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/kernel/process.c |  112 +
 1 file changed, 112 insertions(+)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index cb11fed..14fabd1 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #ifdef CONFIG_PPC64
 #include 
@@ -462,6 +463,117 @@ static inline bool hw_brk_match(struct arch_hw_breakpoint 
*a,
return false;
return true;
 }
+#ifdef CONFIG_TRANSACTIONAL_MEM
+static inline void tm_reclaim_task(struct task_struct *tsk)
+{
+   /* We have to work out if we're switching from/to a task that's in the
+* middle of a transaction.
+*
+* In switching we need to maintain a 2nd register state as
+* oldtask->thread.ckpt_regs.  We tm_reclaim(oldproc); this saves the
+* checkpointed (tbegin) state in ckpt_regs and saves the transactional
+* (current) FPRs into oldtask->thread.transact_fpr[].
+*
+* We also context switch (save) TFHAR/TEXASR/TFIAR in here.
+*/
+   struct thread_struct *thr = &tsk->thread;
+
+   if (!thr->regs)
+   return;
+
+   if (!MSR_TM_ACTIVE(thr->regs->msr))
+   goto out_and_saveregs;
+
+   /* Stash the original thread MSR, as giveup_fpu et al will
+* modify it.  We hold onto it to see whether the task used
+* FP & vector regs.
+*/
+   thr->tm_orig_msr = thr->regs->msr;
+
+   TM_DEBUG("--- tm_reclaim on pid %d (NIP=%lx, "
+"ccr=%lx, msr=%lx, trap=%lx)\n",
+tsk->pid, thr->regs->nip,
+thr->regs->ccr, thr->regs->msr,
+thr->regs->trap);
+
+   tm_reclaim(thr, thr->regs->msr, TM_CAUSE_RESCHED);
+
+   TM_DEBUG("--- tm_reclaim on pid %d complete\n",
+tsk->pid);
+
+out_and_saveregs:
+   /* Always save the regs here, even if a transaction's not active.
+* This context-switches a thread's TM info SPRs.  We do it here to
+* be consistent with the restore path (in recheckpoint) which
+* cannot happen later in _switch().
+*/
+   tm_save_sprs(thr);
+}
+
+static inline void __maybe_unused tm_recheckpoint_new_task(struct task_struct 
*new)
+{
+   unsigned long msr;
+
+   if (!cpu_has_feature(CPU_FTR_TM))
+   return;
+
+   /* Recheckpoint the registers of the thread we're about to switch to.
+*
+* If the task was using FP, we non-lazily reload both the original and
+* the speculative FP register states.  This is because the kernel
+* doesn't see if/when a TM rollback occurs, so if we take an FP
+* unavoidable later, we are unable to determine which set of FP regs
+* need to be restored.
+*/
+   if (!new->thread.regs)
+   return;
+
+   /* The TM SPRs are restored here, so that TEXASR.FS can be set
+* before the trecheckpoint and no explosion occurs.
+*/
+   tm_restore_sprs(&new->thread);
+
+   if (!MSR_TM_ACTIVE(new->thread.regs->msr))
+   return;
+   msr = new->thread.tm_orig_msr;
+   /* Recheckpoint to restore original checkpointed register state. */
+   TM_DEBUG("*** tm_recheckpoint of pid %d "
+"(new->msr 0x%lx, new->origmsr 0x%lx)\n",
+new->pid, new->thread.regs->msr, msr);
+
+   /* This loads the checkpointed FP/VEC state, if used */
+   tm_recheckpoint(&new->thread, msr);
+
+   /* This loads the speculative FP/VEC state, if used */
+   if (msr & MSR_FP) {
+   do_load_up_transact_fpu(&new->thread);
+   new->thread.regs->msr |=
+   (MSR_FP | new->thread.fpexc_mode);
+   }
+   if (msr & MSR_VEC) {
+   do_load_up_transact_altivec(&new->thread);
+   new->thread.regs->msr |= MSR_VEC;
+   }
+   /* We may as well turn on VSX too since all the state is restored now */
+   if (msr & MSR_VSX)
+   new->thread.regs->msr |= MSR_VSX;
+
+   TM_DEBUG("*** tm_recheckpoint of pid %d complete "
+"(kernel msr 0x%lx)\n",
+new->pid, mfmsr());
+}
+
+static inline void __switch_to_tm(struct task_str

[PATCH 08/17] powerpc: Add FP/VSX and VMX register load functions for transactional memory

2013-01-17 Thread Michael Neuling
This adds functions to restore the state of the FP/VSX registers from
what's stored in the thread_struct.  Two version for FP/VSX are required
since one restores them from transactional/checkpoint side of the
thread_struct and the other from the speculated side.

Similar functions are added for VMX registers.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/kernel/fpu.S|   54 ++
 arch/powerpc/kernel/vector.S |   51 +++
 2 files changed, 105 insertions(+)

diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
index adb1551..6ab0e87 100644
--- a/arch/powerpc/kernel/fpu.S
+++ b/arch/powerpc/kernel/fpu.S
@@ -62,6 +62,60 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX);  
\
__REST_32FPVSRS_TRANSACT(n,__REG_##c,__REG_##base)
 #define SAVE_32FPVSRS(n,c,base) __SAVE_32FPVSRS(n,__REG_##c,__REG_##base)
 
+#ifdef CONFIG_TRANSACTIONAL_MEM
+/*
+ * Wrapper to call load_up_fpu from C.
+ * void do_load_up_fpu(struct pt_regs *regs);
+ */
+_GLOBAL(do_load_up_fpu)
+   mflrr0
+   std r0, 16(r1)
+   stdur1, -112(r1)
+
+   subir6, r3, STACK_FRAME_OVERHEAD
+   /* load_up_fpu expects r12=MSR, r13=PACA, and returns
+* with r12 = new MSR.
+*/
+   ld  r12,_MSR(r6)
+   GET_PACA(r13)
+
+   bl  load_up_fpu
+   std r12,_MSR(r6)
+
+   ld  r0, 112+16(r1)
+   addir1, r1, 112
+   mtlrr0
+   blr
+
+
+/* void do_load_up_fpu(struct thread_struct *thread)
+ *
+ * This is similar to load_up_fpu but for the transactional version of the FP
+ * register set.  It doesn't mess with the task MSR or valid flags.
+ * Furthermore, we don't do lazy FP with TM currently.
+ */
+_GLOBAL(do_load_up_transact_fpu)
+   mfmsr   r6
+   ori r5,r6,MSR_FP
+#ifdef CONFIG_VSX
+BEGIN_FTR_SECTION
+   orisr5,r5,MSR_VSX@h
+END_FTR_SECTION_IFSET(CPU_FTR_VSX)
+#endif
+   SYNC
+   MTMSRD(r5)
+
+   lfd fr0,THREAD_TRANSACT_FPSCR(r3)
+   MTFSF_L(fr0)
+   REST_32FPVSRS_TRANSACT(0, R4, R3)
+
+   /* FP/VSX off again */
+   MTMSRD(r6)
+   SYNC
+
+   blr
+#endif /* CONFIG_TRANSACTIONAL_MEM */
+
 /*
  * This task wants to use the FPU now.
  * On UP, disable FP for the task which had the FPU previously,
diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
index e830289..330fc8c 100644
--- a/arch/powerpc/kernel/vector.S
+++ b/arch/powerpc/kernel/vector.S
@@ -7,6 +7,57 @@
 #include 
 #include 
 
+#ifdef CONFIG_TRANSACTIONAL_MEM
+/*
+ * Wrapper to call load_up_altivec from C.
+ * void do_load_up_altivec(struct pt_regs *regs);
+ */
+_GLOBAL(do_load_up_altivec)
+   mflrr0
+   std r0, 16(r1)
+   stdur1, -112(r1)
+
+   subir6, r3, STACK_FRAME_OVERHEAD
+   /* load_up_altivec expects r12=MSR, r13=PACA, and returns
+* with r12 = new MSR.
+*/
+   ld  r12,_MSR(r6)
+   GET_PACA(r13)
+   bl  load_up_altivec
+   std r12,_MSR(r6)
+
+   ld  r0, 112+16(r1)
+   addir1, r1, 112
+   mtlrr0
+   blr
+
+/* void do_load_up_altivec(struct thread_struct *thread)
+ *
+ * This is similar to load_up_altivec but for the transactional version of the
+ * vector regs.  It doesn't mess with the task MSR or valid flags.
+ * Furthermore, VEC laziness is not supported with TM currently.
+ */
+_GLOBAL(do_load_up_transact_altivec)
+   mfmsr   r6
+   orisr5,r6,MSR_VEC@h
+   MTMSRD(r5)
+   isync
+
+   li  r4,1
+   stw r4,THREAD_USED_VR(r3)
+
+   li  r10,THREAD_TRANSACT_VSCR
+   lvx vr0,r10,r3
+   mtvscr  vr0
+   REST_32VRS_TRANSACT(0,r4,r3)
+
+   /* Disable VEC again. */
+   MTMSRD(r6)
+   isync
+
+   blr
+#endif
+
 /*
  * load_up_altivec(unused, unused, tsk)
  * Disable VMX for the task which had it previously,
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 07/17] powerpc: Add helper functions for transactional memory context switching

2013-01-17 Thread Michael Neuling
Here we add the helper functions to be used when context switching.  These
allow us to fully reclaim and recheckpoint a transaction.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/include/asm/reg.h |2 +-
 arch/powerpc/include/asm/tm.h  |   20 +++
 arch/powerpc/kernel/Makefile   |2 +
 arch/powerpc/kernel/tm.S   |  383 
 4 files changed, 406 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/include/asm/tm.h
 create mode 100644 arch/powerpc/kernel/tm.S

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 3acef78..d19581ae4 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -794,7 +794,7 @@
  *HV mode in which case it is HSPRG0
  *
  * 64-bit server:
- * - SPRG0 unused (reserved for HV on Power4)
+ * - SPRG0 scratch for TM recheckpoint/reclaim (reserved for HV on Power4)
  * - SPRG2 scratch for exception vectors
  * - SPRG3 CPU and NUMA node for VDSO getcpu (user visible)
  *  - HSPRG0 stores PACA in HV mode
diff --git a/arch/powerpc/include/asm/tm.h b/arch/powerpc/include/asm/tm.h
new file mode 100644
index 000..e9ad010
--- /dev/null
+++ b/arch/powerpc/include/asm/tm.h
@@ -0,0 +1,20 @@
+/*
+ * Transactional memory support routines to reclaim and recheckpoint
+ * transactional process state.
+ *
+ * Copyright 2012 Matt Evans & Michael Neuling, IBM Corporation.
+ */
+
+#ifdef CONFIG_TRANSACTIONAL_MEM
+extern void do_load_up_transact_fpu(struct thread_struct *thread);
+extern void do_load_up_transact_altivec(struct thread_struct *thread);
+#endif
+
+extern void tm_enable(void);
+extern void tm_reclaim(struct thread_struct *thread,
+  unsigned long orig_msr, uint8_t cause);
+extern void tm_recheckpoint(struct thread_struct *thread,
+   unsigned long orig_msr);
+extern void tm_abort(uint8_t cause);
+extern void tm_save_sprs(struct thread_struct *thread);
+extern void tm_restore_sprs(struct thread_struct *thread);
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index b4f0e36..7554968 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -121,6 +121,8 @@ ifneq ($(CONFIG_PPC_INDIRECT_IO),y)
 obj-y  += iomap.o
 endif
 
+obj64-$(CONFIG_TRANSACTIONAL_MEM)  += tm.o
+
 obj-$(CONFIG_PPC64)+= $(obj64-y)
 obj-$(CONFIG_PPC32)+= $(obj32-y)
 
diff --git a/arch/powerpc/kernel/tm.S b/arch/powerpc/kernel/tm.S
new file mode 100644
index 000..0517b08
--- /dev/null
+++ b/arch/powerpc/kernel/tm.S
@@ -0,0 +1,383 @@
+/*
+ * Transactional memory support routines to reclaim and recheckpoint
+ * transactional process state.
+ *
+ * Copyright 2012 Matt Evans & Michael Neuling, IBM Corporation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_VSX
+/* See fpu.S, this is very similar but to save/restore checkpointed FPRs/VSRs 
*/
+#define __SAVE_32FPRS_VSRS_TRANSACT(n,c,base)  \
+BEGIN_FTR_SECTION  \
+   b   2f; \
+END_FTR_SECTION_IFSET(CPU_FTR_VSX);\
+   SAVE_32FPRS_TRANSACT(n,base);   \
+   b   3f; \
+2: SAVE_32VSRS_TRANSACT(n,c,base); \
+3:
+/* ...and this is just plain borrowed from there. */
+#define __REST_32FPRS_VSRS(n,c,base)   \
+BEGIN_FTR_SECTION  \
+   b   2f; \
+END_FTR_SECTION_IFSET(CPU_FTR_VSX);\
+   REST_32FPRS(n,base);\
+   b   3f; \
+2: REST_32VSRS(n,c,base);  \
+3:
+#else
+#define __SAVE_32FPRS_VSRS_TRANSACT(n,c,base) SAVE_32FPRS_TRANSACT(n, base)
+#define __REST_32FPRS_VSRS(n,c,base) REST_32FPRS(n, base)
+#endif
+#define SAVE_32FPRS_VSRS_TRANSACT(n,c,base) \
+   __SAVE_32FPRS_VSRS_TRANSACT(n,__REG_##c,__REG_##base)
+#define REST_32FPRS_VSRS(n,c,base) \
+   __REST_32FPRS_VSRS(n,__REG_##c,__REG_##base)
+
+/* Stack frame offsets for local variables. */
+#define TM_FRAME_L0TM_FRAME_SIZE-16
+#define TM_FRAME_L1TM_FRAME_SIZE-8
+#define STACK_PARAM(x) (48+((x)*8))
+
+
+/* In order to access the TM SPRs, TM must be enabled.  So, do so: */
+_GLOBAL(tm_enable)
+   mfmsr   r4
+   li  r3, MSR_TM >> 32
+   sldir3, r3, 32
+   and.r0, r4, r3
+   bne 1f
+   or  r4, r4, r3
+   mtmsrd  r4
+1: blr
+
+_GLOBAL(tm_save_sprs)
+   mfspr   r0, SPRN_TFHAR
+   std r0, THREAD_TM_TFHAR(r3)
+   mfspr   r0, SPRN_TEXASR
+   std r0, THREAD_TM_TEXASR(r3)
+   mfspr   r0, SPRN_TFIAR
+   std r0, THREAD_TM_TFIAR(r3)
+   blr
+
+_GLOBAL(tm_restore_sprs)
+   ld  r0, THREAD_TM_TFHAR(r3)
+   mtspr   SPRN_TFHAR, r0
+   ld  r0, THREAD_TM_TEXASR(r3)
+   mtspr   SPRN_TEXASR,

[PATCH 06/17] powerpc: Add transactional memory paca scratch register to show_regs

2013-01-17 Thread Michael Neuling
Add transactional memory paca scratch register to show_regs.  This is useful
for debugging.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/include/asm/paca.h   |1 +
 arch/powerpc/kernel/asm-offsets.c |1 +
 arch/powerpc/kernel/entry_64.S|4 
 arch/powerpc/kernel/process.c |3 +++
 4 files changed, 9 insertions(+)

diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index c47d687..07e9851 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -137,6 +137,7 @@ struct paca_struct {
u8 irq_work_pending;/* IRQ_WORK interrupt while 
soft-disable */
u8 nap_state_lost;  /* NV GPR values lost in power7_idle */
u64 sprg3;  /* Saved user-visible sprg */
+   u64 tm_scratch; /* TM scratch area for reclaim */
 
 #ifdef CONFIG_PPC_POWERNV
/* Pointer to OPAL machine check event structure set by the
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index 3b81960..c9cdec4 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -123,6 +123,7 @@ int main(void)
 #endif
 
 #ifdef CONFIG_TRANSACTIONAL_MEM
+   DEFINE(PACATMSCRATCH, offsetof(struct paca_struct, tm_scratch));
DEFINE(THREAD_TM_TFHAR, offsetof(struct thread_struct, tm_tfhar));
DEFINE(THREAD_TM_TEXASR, offsetof(struct thread_struct, tm_texasr));
DEFINE(THREAD_TM_TFIAR, offsetof(struct thread_struct, tm_tfiar));
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 6faf51e..283bc61 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -752,6 +752,10 @@ fast_exception_return:
andcr4,r4,r0 /* r0 contains MSR_RI here */
mtmsrd  r4,1
 
+#ifdef CONFIG_TRANSACTIONAL_MEM
+   /* TM debug */
+   std r3, PACATMSCRATCH(r13) /* Stash returned-to MSR */
+#endif
/*
 * r13 is our per cpu area, only restore it if we are returning to
 * userspace the value stored in the stack frame may belong to
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 1ab3a2c..cb11fed 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -749,6 +749,9 @@ void show_regs(struct pt_regs * regs)
printk("NIP ["REG"] %pS\n", regs->nip, (void *)regs->nip);
printk("LR ["REG"] %pS\n", regs->link, (void *)regs->link);
 #endif
+#ifdef CONFIG_TRANSACTIONAL_MEM
+   printk("PACATMSCRATCH [%llx]\n", get_paca()->tm_scratch);
+#endif
show_stack(current, (unsigned long *) regs->gpr[1]);
if (!user_mode(regs))
show_instructions(regs);
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 05/17] powerpc: Register defines for various transactional memory registers

2013-01-17 Thread Michael Neuling
Defines for MSR bits and transactional memory related SPRs TFIAR, TEXASR and
TEXASRU.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/include/asm/reg.h |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 1f59fbb..3acef78 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -29,6 +29,10 @@
 #define MSR_SF_LG  63  /* Enable 64 bit mode */
 #define MSR_ISF_LG 61  /* Interrupt 64b mode valid on 630 */
 #define MSR_HV_LG  60  /* Hypervisor state */
+#define MSR_TS_T_LG34  /* Trans Mem state: Transactional */
+#define MSR_TS_S_LG33  /* Trans Mem state: Suspended */
+#define MSR_TS_LG  33  /* Trans Mem state (2 bits) */
+#define MSR_TM_LG  32  /* Trans Mem Available */
 #define MSR_VEC_LG 25  /* Enable AltiVec */
 #define MSR_VSX_LG 23  /* Enable VSX */
 #define MSR_POW_LG 18  /* Enable Power Management */
@@ -98,6 +102,25 @@
 #define MSR_RI __MASK(MSR_RI_LG)   /* Recoverable Exception */
 #define MSR_LE __MASK(MSR_LE_LG)   /* Little Endian */
 
+#define MSR_TM __MASK(MSR_TM_LG)   /* Transactional Mem Available 
*/
+#define MSR_TS_N   0   /*  Non-transactional */
+#define MSR_TS_S   __MASK(MSR_TS_S_LG) /*  Transaction Suspended */
+#define MSR_TS_T   __MASK(MSR_TS_T_LG) /*  Transaction Transactional */
+#define MSR_TS_MASK(MSR_TS_T | MSR_TS_S)   /* Transaction State bits */
+#define MSR_TM_ACTIVE(x) (((x) & MSR_TS_MASK) != 0) /* Transaction active? */
+#define MSR_TM_TRANSACTIONAL(x)(((x) & MSR_TS_MASK) == MSR_TS_T)
+#define MSR_TM_SUSPENDED(x)(((x) & MSR_TS_MASK) == MSR_TS_S)
+
+/* Reason codes describing kernel causes for transaction aborts.  By
+   convention, bit0 is copied to TEXASR[56] (IBM bit 7) which is set if
+   the failure is persistent.
+*/
+#define TM_CAUSE_RESCHED   0xfe
+#define TM_CAUSE_TLBI  0xfc
+#define TM_CAUSE_FAC_UNAV  0xfa
+#define TM_CAUSE_SYSCALL   0xf9 /* Persistent */
+#define TM_CAUSE_MISC  0xf6
+
 #if defined(CONFIG_PPC_BOOK3S_64)
 #define MSR_64BIT  MSR_SF
 
@@ -193,6 +216,10 @@
 #define SPRN_UAMOR 0x9d/* User Authority Mask Override Register */
 #define SPRN_AMOR  0x15d   /* Authority Mask Override Register */
 #define SPRN_ACOP  0x1F/* Available Coprocessor Register */
+#define SPRN_TFIAR 0x81/* Transaction Failure Inst Addr   */
+#define SPRN_TEXASR0x82/* Transaction EXception & Summary */
+#define SPRN_TEXASRU   0x83/* ''  ''  ''Upper 32  */
+#define SPRN_TFHAR 0x80/* Transaction Failure Handler Addr */
 #define SPRN_CTRLF 0x088
 #define SPRN_CTRLT 0x098
 #define   CTRL_CT  0xc000  /* current thread */
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 04/17] powerpc: New macros for transactional memory support

2013-01-17 Thread Michael Neuling
This adds new macros for saving and restoring checkpointed architected state
from and to the thread_struct.

It also adds some debugging macros for when your brain explodes trying to debug
your transactional memory enabled kernel.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/include/asm/ppc_asm.h   |   83 ++
 arch/powerpc/include/asm/processor.h |1 +
 arch/powerpc/kernel/asm-offsets.c|   24 ++
 arch/powerpc/kernel/fpu.S|   12 +
 arch/powerpc/kernel/process.c|   10 
 arch/powerpc/kernel/traps.c  |   11 +
 6 files changed, 141 insertions(+)

diff --git a/arch/powerpc/include/asm/ppc_asm.h 
b/arch/powerpc/include/asm/ppc_asm.h
index c2d0e58..54219ce 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -123,6 +123,89 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
 #define REST_16VRS(n,b,base)   REST_8VRS(n,b,base); REST_8VRS(n+8,b,base)
 #define REST_32VRS(n,b,base)   REST_16VRS(n,b,base); REST_16VRS(n+16,b,base)
 
+/* Save/restore FPRs, VRs and VSRs from their checkpointed backups in
+ * thread_struct:
+ */
+#define SAVE_FPR_TRANSACT(n, base) stfd n,THREAD_TRANSACT_FPR0+\
+   8*TS_FPRWIDTH*(n)(base)
+#define SAVE_2FPRS_TRANSACT(n, base)   SAVE_FPR_TRANSACT(n, base); \
+   SAVE_FPR_TRANSACT(n+1, base)
+#define SAVE_4FPRS_TRANSACT(n, base)   SAVE_2FPRS_TRANSACT(n, base);   \
+   SAVE_2FPRS_TRANSACT(n+2, base)
+#define SAVE_8FPRS_TRANSACT(n, base)   SAVE_4FPRS_TRANSACT(n, base);   \
+   SAVE_4FPRS_TRANSACT(n+4, base)
+#define SAVE_16FPRS_TRANSACT(n, base)  SAVE_8FPRS_TRANSACT(n, base);   \
+   SAVE_8FPRS_TRANSACT(n+8, base)
+#define SAVE_32FPRS_TRANSACT(n, base)  SAVE_16FPRS_TRANSACT(n, base);  \
+   SAVE_16FPRS_TRANSACT(n+16, base)
+
+#define REST_FPR_TRANSACT(n, base) lfd n,THREAD_TRANSACT_FPR0+ \
+   8*TS_FPRWIDTH*(n)(base)
+#define REST_2FPRS_TRANSACT(n, base)   REST_FPR_TRANSACT(n, base); \
+   REST_FPR_TRANSACT(n+1, base)
+#define REST_4FPRS_TRANSACT(n, base)   REST_2FPRS_TRANSACT(n, base);   \
+   REST_2FPRS_TRANSACT(n+2, base)
+#define REST_8FPRS_TRANSACT(n, base)   REST_4FPRS_TRANSACT(n, base);   \
+   REST_4FPRS_TRANSACT(n+4, base)
+#define REST_16FPRS_TRANSACT(n, base)  REST_8FPRS_TRANSACT(n, base);   \
+   REST_8FPRS_TRANSACT(n+8, base)
+#define REST_32FPRS_TRANSACT(n, base)  REST_16FPRS_TRANSACT(n, base);  \
+   REST_16FPRS_TRANSACT(n+16, base)
+
+
+#define SAVE_VR_TRANSACT(n,b,base) li b,THREAD_TRANSACT_VR0+(16*(n)); \
+   stvx n,b,base
+#define SAVE_2VRS_TRANSACT(n,b,base)   SAVE_VR_TRANSACT(n,b,base); \
+   SAVE_VR_TRANSACT(n+1,b,base)
+#define SAVE_4VRS_TRANSACT(n,b,base)   SAVE_2VRS_TRANSACT(n,b,base);   \
+   SAVE_2VRS_TRANSACT(n+2,b,base)
+#define SAVE_8VRS_TRANSACT(n,b,base)   SAVE_4VRS_TRANSACT(n,b,base);   \
+   SAVE_4VRS_TRANSACT(n+4,b,base)
+#define SAVE_16VRS_TRANSACT(n,b,base)  SAVE_8VRS_TRANSACT(n,b,base);   \
+   SAVE_8VRS_TRANSACT(n+8,b,base)
+#define SAVE_32VRS_TRANSACT(n,b,base)  SAVE_16VRS_TRANSACT(n,b,base);  \
+   SAVE_16VRS_TRANSACT(n+16,b,base)
+
+#define REST_VR_TRANSACT(n,b,base) li b,THREAD_TRANSACT_VR0+(16*(n)); \
+   lvx n,b,base
+#define REST_2VRS_TRANSACT(n,b,base)   REST_VR_TRANSACT(n,b,base); \
+   REST_VR_TRANSACT(n+1,b,base)
+#define REST_4VRS_TRANSACT(n,b,base)   REST_2VRS_TRANSACT(n,b,base);   \
+   REST_2VRS_TRANSACT(n+2,b,base)
+#define REST_8VRS_TRANSACT(n,b,base)   REST_4VRS_TRANSACT(n,b,base);   \
+   REST_4VRS_TRANSACT(n+4,b,base)
+#define REST_16VRS_TRANSACT(n,b,base)  REST_8VRS_TRANSACT(n,b,base);   \
+   REST_8VRS_TRANSACT(n+8,b,base)
+#define REST_32VRS_TRANSACT(n,b,base)  REST_16VRS_TRANSACT(n,b,base);  \
+   REST_16VRS_TRANSACT(n+16,b,base)
+
+
+#define SAVE_VSR_TRANSACT(n,b,base)li b,THREAD_TRANSACT_VSR0+(16*(n)); \
+   STXVD2X(n,R##base,R##b)
+#define SAVE_2VSRS_TRANSACT(n,b,base)  SAVE_VSR_TRANSACT(n,b,base);\
+   SAVE_VSR_TRANSACT(n+1,b,base)
+#define SAVE_4VSRS_TRANSACT(n,b,base)  SAVE_2VSRS_TRANSACT(n,b,base);  \
+ 

[PATCH 03/17] powerpc: Add additional state needed for transactional memory to thread struct

2013-01-17 Thread Michael Neuling
Set of new archtected state for saving away on context switch.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/include/asm/processor.h |   28 
 1 file changed, 28 insertions(+)

diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index 7938658..1ffed17 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -246,6 +246,34 @@ struct thread_struct {
unsigned long   spefscr;/* SPE & eFP status */
int used_spe;   /* set if process has used spe */
 #endif /* CONFIG_SPE */
+#ifdef CONFIG_TRANSACTIONAL_MEM
+   u64 tm_tfhar;   /* Transaction fail handler addr */
+   u64 tm_texasr;  /* Transaction exception & summary */
+   u64 tm_tfiar;   /* Transaction fail instr address reg */
+   unsigned long   tm_orig_msr;/* Thread's MSR on ctx switch */
+   struct pt_regs  ckpt_regs;  /* Checkpointed registers */
+
+   /*
+* Transactional FP and VSX 0-31 register set.
+* NOTE: the sense of these is the opposite of the integer ckpt_regs!
+*
+* When a transaction is active/signalled/scheduled etc., *regs is the
+* most recent set of/speculated GPRs with ckpt_regs being the older
+* checkpointed regs to which we roll back if transaction aborts.
+*
+* However, fpr[] is the checkpointed 'base state' of FP regs, and
+* transact_fpr[] is the new set of transactional values.
+* VRs work the same way.
+*/
+   double  transact_fpr[32][TS_FPRWIDTH];
+   struct {
+   unsigned int pad;
+   unsigned int val;   /* Floating point status */
+   } transact_fpscr;
+   vector128   transact_vr[32] __attribute__((aligned(16)));
+   vector128   transact_vscr __attribute__((aligned(16)));
+   unsigned long   transact_vrsave;
+#endif /* CONFIG_TRANSACTIONAL_MEM */
 #ifdef CONFIG_KVM_BOOK3S_32_HANDLER
void*   kvm_shadow_vcpu; /* KVM internal data */
 #endif /* CONFIG_KVM_BOOK3S_32_HANDLER */
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 02/17] powerpc: Add new instructions for transactional memory

2013-01-17 Thread Michael Neuling
Here we define the new instructions we need for transactional memory in the
kernel.  This is so we can support compiling with binutils that don't support
the new transactional memory instructions.

Transactional memory results in two sets of architected state (GPRs/VSRs
etc).

treclaim allows us to read the checkpointed state (from the tbegin) so that we
can store it away on a context switch.  It does this by overwriting the exiting
architected state, so you have to save that away before you treclaim.  treclaim
will also abort a transaction, so you can give a register value which contains
an abort reason.

trecheckpoint allows us to inject into the checkpointed state as if it were at
the tbegin.  It does this by copying the current architected state into the
checkpointed state.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/include/asm/ppc-opcode.h |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
b/arch/powerpc/include/asm/ppc-opcode.h
index 0fd1928..8752bc8 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -129,6 +129,9 @@
 #define PPC_INST_TLBSRX_DOT0x7c0006a5
 #define PPC_INST_XXLOR 0xf510
 #define PPC_INST_XVCPSGNDP 0xf780
+#define PPC_INST_TRECHKPT  0x7c0007dd
+#define PPC_INST_TRECLAIM  0x7c00075d
+#define PPC_INST_TABORT0x7c00071d
 
 #define PPC_INST_NAP   0x4c000364
 #define PPC_INST_SLEEP 0x4c0003a4
@@ -294,4 +297,11 @@
 #define PPC_NAPstringify_in_c(.long PPC_INST_NAP)
 #define PPC_SLEEP  stringify_in_c(.long PPC_INST_SLEEP)
 
+/* Transactional memory instructions */
+#define TRECHKPT   stringify_in_c(.long PPC_INST_TRECHKPT)
+#define TRECLAIM(r)stringify_in_c(.long PPC_INST_TRECLAIM \
+  | __PPC_RA(r))
+#define TABORT(r)  stringify_in_c(.long PPC_INST_TABORT \
+  | __PPC_RA(r))
+
 #endif /* _ASM_POWERPC_PPC_OPCODE_H */
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 01/17] powerpc: Add new CPU feature bit for transactional memory

2013-01-17 Thread Michael Neuling
Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
---
 arch/powerpc/include/asm/cputable.h |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 06f7fb9..71a498b 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -220,6 +220,13 @@ extern const char *powerpc_base_platform;
 #define PPC_FEATURE_HAS_EFP_DOUBLE_COMP 0
 #endif
 
+/* We only set the TM feature if the kernel was compiled with TM supprt */
+#ifdef CONFIG_TRANSACTIONAL_MEM
+#define CPU_FTR_TM_COMPCPU_FTR_TM
+#else
+#define CPU_FTR_TM_COMP0
+#endif
+
 /* We need to mark all pages as being coherent if we're SMP or we have a
  * 74[45]x and an MPC107 host bridge. Also 83xx and PowerQUICC II
  * require it for PCI "streaming/prefetch" to work properly.
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 00/17] powerpc: Hardware transactional memory support for POWER8

2013-01-17 Thread Michael Neuling
POWER8 implements hardware transactional memory support.  This patch series
adds kernel support so that user programs can use this hardware transactional
memory and the new state is properly context switched.  It is not currently
used by the kernel itself.

This patch series was originally developed by Matt Evans.

v2 changes
 Adds signal handling
 Removes some code for detecting when to restore all register or not
 Added tabort for local tlb invalidates 
 Rebased on benh's next tree

Basic overview of a POWER8 hardware transaction memory
=
Hardware transactional memory is a feature that enables a different form of
atomic memory access.  Several new instructions are presented to delimit
transactions; transactions are guaranteed to either complete atomically or roll
back and undo any partial changes.

A simple transaction looks like this:

begin_move_money:
  tbegin
  beq   abort_handler

  ldr4, SAVINGS_ACCT(r3)
  ldr5, CURRENT_ACCT(r3)
  subi  r5, r5, 1
  addi  r4, r4, 1
  std   r4, SAVINGS_ACCT(r3)
  std   r5, CURRENT_ACCT(r3)

  tend

  b continue

abort_handler:
  ... test for odd failures ...

  /* Retry the transaction if it failed because it conflicted with
   * someone else: */
  b begin_move_money


The 'tbegin' instruction denotes the start point, and 'tend' the end point.
Between these points the processor is in 'Transactional' state; any memory
references will complete in one go if there are no conflicts with other
transactional or non-transactional accesses within the system.  In this
example, the transaction completes as though it were normal straight-line code
IF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an
atomic move of money from the current account to the savings account has been
performed.  Even though the normal ld/std instructions are used (note no
lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
updated, or neither will be updated.

If, in the meantime, there is a conflict with the locations accessed by the
transaction, the transaction will be aborted by the CPU.  Register and memory
state will roll back to that at the 'tbegin', and control will continue from
'tbegin+4'.  The branch to abort_handler will be taken this second time; the
abort handler can check the cause of the failure, and retry.

Checkpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR
and a few other status/flag regs; 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 3/6] usb: otg: utils: change the phy lib to support multiple PHYs of same type

2013-01-17 Thread kishon

Hi,

On Thursday 17 January 2013 09:37 PM, Roger Quadros wrote:

On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:

In order to add support for multipe PHY's of the same type, the API's
for adding PHY and getting PHY has been changed. Now the binding
information of the PHY and controller should be done in platform file
using usb_bind_phy API. And for getting a PHY, the device pointer of the
USB controller and an index should be passed. Based on the binding
information that is added in the platform file, get_phy will return the
approappropriate PHY.

Signed-off-by: Kishon Vijay Abraham I 
---
  arch/arm/mach-shmobile/board-marzen.c |2 +-
  drivers/power/ab8500_charger.c|2 +-
  drivers/power/isp1704_charger.c   |2 +-
  drivers/power/pda_power.c |2 +-
  drivers/power/twl4030_charger.c   |2 +-
  drivers/usb/chipidea/udc.c|2 +-
  drivers/usb/dwc3/core.c   |4 +-
  drivers/usb/gadget/fsl_udc_core.c |2 +-
  drivers/usb/gadget/mv_udc_core.c  |2 +-
  drivers/usb/gadget/omap_udc.c |2 +-
  drivers/usb/gadget/pxa25x_udc.c   |2 +-
  drivers/usb/gadget/pxa27x_udc.c   |2 +-
  drivers/usb/gadget/s3c-hsudc.c|2 +-
  drivers/usb/host/ehci-fsl.c   |2 +-
  drivers/usb/host/ehci-msm.c   |2 +-
  drivers/usb/host/ehci-mv.c|2 +-
  drivers/usb/host/ehci-tegra.c |2 +-
  drivers/usb/host/ohci-omap.c  |2 +-
  drivers/usb/musb/am35x.c  |2 +-
  drivers/usb/musb/blackfin.c   |2 +-
  drivers/usb/musb/da8xx.c  |2 +-
  drivers/usb/musb/davinci.c|2 +-
  drivers/usb/musb/musb_dsps.c  |2 +-
  drivers/usb/musb/omap2430.c   |2 +-
  drivers/usb/musb/tusb6010.c   |2 +-
  drivers/usb/musb/ux500.c  |2 +-
  drivers/usb/otg/ab8500-usb.c  |3 +-
  drivers/usb/otg/fsl_otg.c |5 ++-
  drivers/usb/otg/gpio_vbus.c   |3 +-
  drivers/usb/otg/isp1301_omap.c|3 +-
  drivers/usb/otg/msm_otg.c |3 +-
  drivers/usb/otg/mv_otg.c  |3 +-
  drivers/usb/otg/nop-usb-xceiv.c   |3 +-
  drivers/usb/otg/otg.c |   67 +++--
  drivers/usb/otg/twl4030-usb.c |3 +-
  drivers/usb/phy/mv_u3d_phy.c  |3 +-
  drivers/usb/phy/omap-usb2.c   |   11 ++
  drivers/usb/phy/rcar-phy.c|3 +-
  include/linux/usb/phy.h   |   12 +++---
  39 files changed, 87 insertions(+), 89 deletions(-)


I think it better to leave the existing add/get APIs as they are add add
new APIs that support multiple PHYs. You could probably mark the old
ones as deprecated.

That way you don't need to wait till all users are converted and tested.


Makes sense. Will do that :-)

Thanks
Kishon
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v7 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc

2013-01-17 Thread Peter Chen
On Fri, Jan 18, 2013 at 10:23:39AM +0800, Shawn Guo wrote:
> Peter,
> 
> On Fri, Jan 18, 2013 at 10:15:49AM +0800, Peter Chen wrote:
> > As we use platform_device_id for fsl-usb2-udc driver, it needs to
> > change clk connection-id, or the related devm_clk_get will be failed.
> > 
> > Signed-off-by: Peter Chen 
> 
> You should have my ACK put after your SoB, since I have provided it
> on v6 of this patch.  It will make balbi's life a little bit easier
> when he applies the patch.
thanks, will do next time
> 
> So again,
> 
> Acked-by: Shawn Guo 
> 
> Shawn

-- 

Best Regards,
Peter Chen

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v7 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc

2013-01-17 Thread Shawn Guo
Peter,

On Fri, Jan 18, 2013 at 10:15:49AM +0800, Peter Chen wrote:
> As we use platform_device_id for fsl-usb2-udc driver, it needs to
> change clk connection-id, or the related devm_clk_get will be failed.
> 
> Signed-off-by: Peter Chen 

You should have my ACK put after your SoB, since I have provided it
on v6 of this patch.  It will make balbi's life a little bit easier
when he applies the patch.

So again,

Acked-by: Shawn Guo 

Shawn

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v7 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc

2013-01-17 Thread Peter Chen
As we use platform_device_id for fsl-usb2-udc driver, it needs to
change clk connection-id, or the related devm_clk_get will be failed.

Signed-off-by: Peter Chen 
---
 arch/arm/mach-imx/clk-imx25.c   |6 +++---
 arch/arm/mach-imx/clk-imx27.c   |6 +++---
 arch/arm/mach-imx/clk-imx31.c   |6 +++---
 arch/arm/mach-imx/clk-imx35.c   |6 +++---
 arch/arm/mach-imx/clk-imx51-imx53.c |6 +++---
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index b197aa7..2c570cd 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -254,9 +254,9 @@ int __init mx25_clocks_init(void)
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usbotg_ahb], "ahb", "mxc-ehci.2");
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2");
-   clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usbotg_ahb], "ahb", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
+   clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx27");
+   clk_register_clkdev(clk[usbotg_ahb], "ahb", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27");
clk_register_clkdev(clk[nfc_ipg_per], NULL, "imx25-nand.0");
/* i.mx25 has the i.mx35 type cspi */
clk_register_clkdev(clk[cspi1_ipg], NULL, "imx35-cspi.0");
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 4c1d1e4..1ffe3b5 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -236,9 +236,9 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx21-fb.0");
clk_register_clkdev(clk[csi_ahb_gate], "ahb", "imx27-camera.0");
clk_register_clkdev(clk[per4_gate], "per", "imx27-camera.0");
-   clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc");
+   clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_ipg_gate], "ipg", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_ahb_gate], "ahb", "imx-udc-mx27");
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.0");
clk_register_clkdev(clk[usb_ipg_gate], "ipg", "mxc-ehci.0");
clk_register_clkdev(clk[usb_ahb_gate], "ahb", "mxc-ehci.0");
diff --git a/arch/arm/mach-imx/clk-imx31.c b/arch/arm/mach-imx/clk-imx31.c
index 8be64e0..16ccbd4 100644
--- a/arch/arm/mach-imx/clk-imx31.c
+++ b/arch/arm/mach-imx/clk-imx31.c
@@ -139,9 +139,9 @@ int __init mx31_clocks_init(unsigned long fref)
clk_register_clkdev(clk[usb_div_post], "per", "mxc-ehci.2");
clk_register_clkdev(clk[usb_gate], "ahb", "mxc-ehci.2");
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
-   clk_register_clkdev(clk[usb_div_post], "per", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_gate], "ahb", "fsl-usb2-udc");
-   clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
+   clk_register_clkdev(clk[usb_div_post], "per", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_gate], "ahb", "imx-udc-mx27");
+   clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx27");
clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0");
/* i.mx31 has the i.mx21 type uart */
clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0");
diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c
index 66f3d65..f0727e8 100644
--- a/arch/arm/mach-imx/clk-imx35.c
+++ b/arch/arm/mach-imx/clk-imx35.c
@@ -251,9 +251,9 @@ int __init mx35_clocks_init()
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2");
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usbotg_gate], "ahb", "mxc-ehci.2");
-   clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
-   clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usbotg_gate], "ahb", "fsl-usb2-udc");
+   clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27");
+   clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx27");
+   clk_register_clkdev(clk[usbotg_gate], "ahb", "imx-udc-mx27");
clk_register_clkdev(clk[wdog_gate], NULL, "imx2-wdt.0");
clk_register_clkdev(clk[nfc_div], NULL, "imx25-nand.0");
clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0");
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c 
b/arch/arm/mach-imx/clk-imx51-imx53.c
index 579023f..fb7cb84 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -269,9 +269,9 @@ static void __init mx5_clocks_common_init(unsigned long 
rate_ckil,
clk_register_clkdev(clk[usboh3_per_gate], "per", "mxc-ehci.2");
clk_register_clkdev(clk[usboh3_gate], "ipg", "mx

[PATCH v7 2/3] usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap

2013-01-17 Thread Peter Chen
As mach/hardware.h is deleted, we can't visit platform code at driver.
It has no phy driver to combine with this controller, so it has to use
ioremap to map phy address as a workaround.

Signed-off-by: Peter Chen 
---
 drivers/usb/gadget/fsl_mxc_udc.c  |   30 +++---
 drivers/usb/gadget/fsl_udc_core.c |4 +++-
 drivers/usb/gadget/fsl_usb2_udc.h |5 +++--
 3 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index aa81ac5..f1aeb5c 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -23,7 +23,8 @@ static struct clk *mxc_per_clk;
 static struct clk *mxc_ipg_clk;
 
 /* workaround ENGcm09152 for i.MX35 */
-#define USBPHYCTRL_OTGBASE_OFFSET  0x608
+#define MX35_USBPHYCTRL_OFFSET 0x600
+#define USBPHYCTRL_OTGBASE_OFFSET  0x8
 #define USBPHYCTRL_EVDO(1 << 23)
 
 int fsl_udc_clk_init(struct platform_device *pdev)
@@ -81,25 +82,40 @@ eclkrate:
return ret;
 }
 
-void fsl_udc_clk_finalize(struct platform_device *pdev)
+int fsl_udc_clk_finalize(struct platform_device *pdev)
 {
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
-   unsigned int v;
+   int ret = 0;
 
/* workaround ENGcm09152 for i.MX35 */
if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
-   v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
-   USBPHYCTRL_OTGBASE_OFFSET));
+   unsigned int v;
+   struct resource *res = platform_get_resource
+   (pdev, IORESOURCE_MEM, 0);
+   void __iomem *phy_regs = ioremap(res->start +
+   MX35_USBPHYCTRL_OFFSET, 512);
+   if (!phy_regs) {
+   dev_err(&pdev->dev, "ioremap for phy address fails\n");
+   ret = -EINVAL;
+   goto ioremap_err;
+   }
+
+   v = readl(phy_regs + USBPHYCTRL_OTGBASE_OFFSET);
writel(v | USBPHYCTRL_EVDO,
-   MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
-   USBPHYCTRL_OTGBASE_OFFSET));
+   phy_regs + USBPHYCTRL_OTGBASE_OFFSET);
+
+   iounmap(phy_regs);
}
 
+
+ioremap_err:
/* ULPI transceivers don't need usbpll */
if (pdata->phy_mode == FSL_USB2_PHY_ULPI) {
clk_disable_unprepare(mxc_per_clk);
mxc_per_clk = NULL;
}
+
+   return ret;
 }
 
 void fsl_udc_clk_release(void)
diff --git a/drivers/usb/gadget/fsl_udc_core.c 
b/drivers/usb/gadget/fsl_udc_core.c
index 5fc1d72..667275c 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2543,7 +2543,9 @@ static int __init fsl_udc_probe(struct platform_device 
*pdev)
dr_controller_setup(udc_controller);
}
 
-   fsl_udc_clk_finalize(pdev);
+   ret = fsl_udc_clk_finalize(pdev);
+   if (ret)
+   goto err_free_irq;
 
/* Setup gadget structure */
udc_controller->gadget.ops = &fsl_gadget_ops;
diff --git a/drivers/usb/gadget/fsl_usb2_udc.h 
b/drivers/usb/gadget/fsl_usb2_udc.h
index f61a967..c6703bb 100644
--- a/drivers/usb/gadget/fsl_usb2_udc.h
+++ b/drivers/usb/gadget/fsl_usb2_udc.h
@@ -592,15 +592,16 @@ static inline struct ep_queue_head *get_qh_by_ep(struct 
fsl_ep *ep)
 struct platform_device;
 #ifdef CONFIG_ARCH_MXC
 int fsl_udc_clk_init(struct platform_device *pdev);
-void fsl_udc_clk_finalize(struct platform_device *pdev);
+int fsl_udc_clk_finalize(struct platform_device *pdev);
 void fsl_udc_clk_release(void);
 #else
 static inline int fsl_udc_clk_init(struct platform_device *pdev)
 {
return 0;
 }
-static inline void fsl_udc_clk_finalize(struct platform_device *pdev)
+static inline int fsl_udc_clk_finalize(struct platform_device *pdev)
 {
+   return 0;
 }
 static inline void fsl_udc_clk_release(void)
 {
-- 
1.7.0.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v7 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Peter Chen
As mach/hardware.h is deleted, we need to use platform_device_id to
differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
already used pdata to differentiate runtime

Meanwhile we update the platform code accordingly.

Signed-off-by: Peter Chen 
---
 arch/arm/mach-imx/devices/devices-common.h|1 +
 arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c |   15 
 drivers/usb/gadget/fsl_mxc_udc.c  |   30 
 drivers/usb/gadget/fsl_udc_core.c |   38 -
 4 files changed, 46 insertions(+), 38 deletions(-)

diff --git a/arch/arm/mach-imx/devices/devices-common.h 
b/arch/arm/mach-imx/devices/devices-common.h
index 6277baf..9bd5777 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -63,6 +63,7 @@ struct platform_device *__init imx_add_flexcan(
 
 #include 
 struct imx_fsl_usb2_udc_data {
+   const char *devid;
resource_size_t iobase;
resource_size_t irq;
 };
diff --git a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c 
b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
index 37e4439..3c06bd9 100644
--- a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
+++ b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
@@ -11,35 +11,36 @@
 #include "../hardware.h"
 #include "devices-common.h"
 
-#define imx_fsl_usb2_udc_data_entry_single(soc)
\
+#define imx_fsl_usb2_udc_data_entry_single(soc, _devid)
\
{   \
+   .devid = _devid,\
.iobase = soc ## _USB_OTG_BASE_ADDR,\
.irq = soc ## _INT_USB_OTG, \
}
 
 #ifdef CONFIG_SOC_IMX25
 const struct imx_fsl_usb2_udc_data imx25_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX25);
+   imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX25 */
 
 #ifdef CONFIG_SOC_IMX27
 const struct imx_fsl_usb2_udc_data imx27_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX27);
+   imx_fsl_usb2_udc_data_entry_single(MX27, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX27 */
 
 #ifdef CONFIG_SOC_IMX31
 const struct imx_fsl_usb2_udc_data imx31_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX31);
+   imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX31 */
 
 #ifdef CONFIG_SOC_IMX35
 const struct imx_fsl_usb2_udc_data imx35_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX35);
+   imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX35 */
 
 #ifdef CONFIG_SOC_IMX51
 const struct imx_fsl_usb2_udc_data imx51_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX51);
+   imx_fsl_usb2_udc_data_entry_single(MX51, "imx-udc-mx51");
 #endif
 
 struct platform_device *__init imx_add_fsl_usb2_udc(
@@ -57,7 +58,7 @@ struct platform_device *__init imx_add_fsl_usb2_udc(
.flags = IORESOURCE_IRQ,
},
};
-   return imx_add_platform_device_dmamask("fsl-usb2-udc", -1,
+   return imx_add_platform_device_dmamask(data->devid, -1,
res, ARRAY_SIZE(res),
pdata, sizeof(*pdata), DMA_BIT_MASK(32));
 }
diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index 1b0f086..aa81ac5 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -18,8 +18,6 @@
 #include 
 #include 
 
-#include 
-
 static struct clk *mxc_ahb_clk;
 static struct clk *mxc_per_clk;
 static struct clk *mxc_ipg_clk;
@@ -58,8 +56,12 @@ int fsl_udc_clk_init(struct platform_device *pdev)
clk_prepare_enable(mxc_ahb_clk);
clk_prepare_enable(mxc_per_clk);
 
-   /* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
-   if (!cpu_is_mx51()) {
+   /*
+* Make sure USB_CLK is running at 60 MHz +/- 1000 Hz
+* Only two types of udc currently, imx-udc-mx27 and
+* imx-udc-mx51 (mx51 & mx53)
+*/
+   if (strcmp(pdev->id_entry->name, "imx-udc-mx27") == 0) {
freq = clk_get_rate(mxc_per_clk);
if (pdata->phy_mode != FSL_USB2_PHY_ULPI &&
(freq < 5000 || freq > 60001000)) {
@@ -82,17 +84,15 @@ eclkrate:
 void fsl_udc_clk_finalize(struct platform_device *pdev)
 {
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
-   if (cpu_is_mx35()) {
-   unsigned int v;
-
-   /* workaround ENGcm09152 for i.MX35 */
-   if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
-   v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
-

[PATCH v7 0/3] Fix the Build error for fsl_mxc_udc.c

2013-01-17 Thread Peter Chen
Changes for v7:
- Change !strcmp(str1, str2) to strcmp(str1, str2) == 0

Changes for v6:
- Only using imx-udc-mx27 and imx-udc-mx51 stands for
all kinds of i.mx udc
- Fix below build error for platform_device_id at fsl_udc_core.c
drivers/usb/gadget/fsl_usb2_udc: struct platform_device_id is 24 bytes.? The 
last of 5 is:
| 0x69 0x6d 0x78 0x2d 0x75 0x64 0x63 0x2d 0x6d 0x78 0x35 0x31 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00
+0x00 0x00 0x00
| FATAL: drivers/usb/gadget/fsl_usb2_udc: struct platform_device_id is not 
terminated with a NULL entry!
| make[1]: *** [__modpost] Error 1

Changes for v5:
- Using strcmp to get specific SoC
- Delete one cpu_is_mx35() as it has already pdata runtime check

Changes for v4:
- Using pdev's struct resource to do ioremap
- Add ioremap return value check

Changes for v3:
- Split the one big patch into three patches

Changes for v2:
- Add const for fsl_udc_devtype
- Do ioremap for phy address at fsl-mxc-udc

Peter Chen (3):
  usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
  usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap
  ARM: i.MX clock: Change the connection-id for fsl-usb2-udc

 arch/arm/mach-imx/clk-imx25.c |6 +-
 arch/arm/mach-imx/clk-imx27.c |6 +-
 arch/arm/mach-imx/clk-imx31.c |6 +-
 arch/arm/mach-imx/clk-imx35.c |6 +-
 arch/arm/mach-imx/clk-imx51-imx53.c   |6 +-
 arch/arm/mach-imx/devices/devices-common.h|1 +
 arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c |   15 ---
 drivers/usb/gadget/fsl_mxc_udc.c  |   46 ++---
 drivers/usb/gadget/fsl_udc_core.c |   42 +++
 drivers/usb/gadget/fsl_usb2_udc.h |5 +-
 10 files changed, 83 insertions(+), 56 deletions(-)


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v6 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Peter Chen
On Thu, Jan 17, 2013 at 12:43:23PM -0200, Fabio Estevam wrote:
> On Thu, Jan 17, 2013 at 9:25 AM, Lothar Waßmann  
> wrote:
> 
> > The equivalent of !cpu_is_mx51() would be
> > strcmp(pdev->id_entry->name, "imx-udc-mx51") (without the '!') meaning
> > id_entry->name is different from "imx-udc-mx51".

Thanks, Lothar and Fabio, I will change, and send v7.
> 
> Yes, agree.
> 
> strcmp(pdev->id_entry->name, "imx-udc-mx51") is also better than
> !strcmp(pdev->id_entry->name, "imx-udc-mx27"))

We just think this feature only belongs to imx-udc-mx27 type udc
> 
> because in the case of another soc entry gets added, let's say
> "imx-udc-mxyy" then
> 
> !strcmp(pdev->id_entry->name, "imx-udc-mx27")) will not correspond to
> !cpu_is_mx51() anymore.
> 

-- 

Best Regards,
Peter Chen

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 1/2] powerpc/5200: Fix size to request_mem_region() call

2013-01-17 Thread Grant Likely
The Bestcomm driver requests a memory region larger than the one
described in the device tree. This is due to an extra undocumented field
in the bestcomm register structure. This hasn't been a problem up to
now, but there is a patch pending to make the DT platform_bus support
code use platform_device_add() which tightens the rules and provides
extra checks for drivers to stay within the specified register regions.

Alternately, I could have removed the extra field from the structure,
but I'm not sure if it is still needed for resume to work. Better be
safe and leave it in.

Signed-off-by: Grant Likely 
Cc: Benjamin Herrenschmidt 
Cc: Anatolij Gustschin 
---
 arch/powerpc/sysdev/bestcomm/bestcomm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/bestcomm/bestcomm.c 
b/arch/powerpc/sysdev/bestcomm/bestcomm.c
index d913063..81c3314 100644
--- a/arch/powerpc/sysdev/bestcomm/bestcomm.c
+++ b/arch/powerpc/sysdev/bestcomm/bestcomm.c
@@ -414,7 +414,7 @@ static int mpc52xx_bcom_probe(struct platform_device *op)
goto error_sramclean;
}
 
-   if (!request_mem_region(res_bcom.start, sizeof(struct mpc52xx_sdma),
+   if (!request_mem_region(res_bcom.start, resource_size(&res_bcom),
DRIVER_NAME)) {
printk(KERN_ERR DRIVER_NAME ": "
"Can't request registers region\n");
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 2/2] of: use platform_device_add

2013-01-17 Thread Grant Likely
This allows platform_device_add a chance to call insert_resource on all
of the resources from OF. At a minimum this fills in proc/iomem and
presumably makes resource tracking and conflict detection work better.
However, it has the side effect of moving all OF generated platform
devices from /sys/devices to /sys/devices/platform/. It /shouldn't/
break userspace because userspace is not supposed to depend on the full
path (because userspace always does what it is supposed to, right?).

This may cause breakage if either:
1) any two nodes in a given device tree have overlapping & staggered
   regions (ie. 0x80..0xbf and 0xa0..0xdf; where one is not contained
   within the other). In this case one of the devices will fail to
   register and an exception will be needed in platform_device_add() to
   complain but not fail.
2) any device calls request_mem_region() on a region larger than
   specified in the device tree. In this case the device node may be
   wrong, or the driver is overreaching. In either case I'd like to know
   about any problems and fix them.

Please test. Despite the above, I'm still fairly confident that this
patch is in good shape. I'd like to put it into linux-next, but would
appreciate some bench testing from others before I do; particularly on
PowerPC machines.

v2: Remove powerpc special-case

Cc: Jason Gunthorpe 
Cc: Benjamin Herrenschmidt 
Cc: Rob Herring 
Cc: Greg Kroah-Hartman 
Signed-off-by: Grant Likely 
---
 drivers/of/platform.c |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b80891b..3c3e3ca 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -203,6 +203,7 @@ struct platform_device *of_platform_device_create_pdata(
struct device *parent)
 {
struct platform_device *dev;
+   int rc;
 
if (!of_device_is_available(np))
return NULL;
@@ -214,16 +215,24 @@ struct platform_device *of_platform_device_create_pdata(
 #if defined(CONFIG_MICROBLAZE)
dev->archdata.dma_mask = 0xUL;
 #endif
+   dev->name = dev_name(&dev->dev);
dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-   dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
+   dev->dev.id = PLATFORM_DEVID_NONE;
+   /* device_add will assume that this device is on the same node as
+* the parent. If there is no parent defined, set the node
+* explicitly */
+   if (!parent)
+   set_dev_node(&dev->dev, of_node_to_nid(np));
 
/* We do not fill the DMA ops for platform devices by default.
 * This is currently the responsibility of the platform code
 * to do such, possibly using a device notifier
 */
 
-   if (of_device_add(dev) != 0) {
+   rc = platform_device_add(dev);
+   if (rc) {
+   dev_err(&dev->dev, "device registration failed\n");
platform_device_put(dev);
return NULL;
}
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: therm_pm72 units, interface

2013-01-17 Thread Benjamin Herrenschmidt
On Thu, 2013-01-17 at 15:38 +0100, Jan Engelhardt wrote:
> 
> Meanwhile, I run Linux 3.7.1 and the software side changed somewhat.
> windfarm_rm31 seems to no longer calm the fans down once loaded,
> whereas therm_pm72 on Linux 3.0 did so.

Hrm, that would be a bug ... unfortunately I never got to test it
properly due to my xserve being dead.

Can you turn on debug in there ?

-#undef DEBUG
-#undef LOTSA_DEBUG
+#define DEBUG
+#define LOTSA_DEBUG

It will be *very* verbose 

Cheers,
Ben.



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] [v2] powerpc/fsl: remove extraneous DIU platform functions

2013-01-17 Thread Timur Tabi
From: Timur Tabi 

The Freescale DIU driver was recently updated to not require every DIU
platform function, so now we can remove the unneeded functions from
some boards.

Signed-off-by: Timur Tabi 
---
 arch/powerpc/platforms/512x/mpc512x_shared.c |5 ---
 arch/powerpc/platforms/85xx/p1022_ds.c   |   38 --
 arch/powerpc/platforms/85xx/p1022_rdk.c  |   12 
 3 files changed, 0 insertions(+), 55 deletions(-)

diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c 
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index 35f14fd..c7f47cf 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -68,10 +68,6 @@ struct fsl_diu_shared_fb {
boolin_use;
 };
 
-void mpc512x_set_monitor_port(enum fsl_diu_monitor_port port)
-{
-}
-
 #define DIU_DIV_MASK   0x00ff
 void mpc512x_set_pixel_clock(unsigned int pixclock)
 {
@@ -303,7 +299,6 @@ void __init mpc512x_setup_diu(void)
}
}
 
-   diu_ops.set_monitor_port= mpc512x_set_monitor_port;
diu_ops.set_pixel_clock = mpc512x_set_pixel_clock;
diu_ops.valid_monitor_port  = mpc512x_valid_monitor_port;
diu_ops.release_bootmem = mpc512x_release_bootmem;
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c 
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 7328b8d..c4777ee 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -106,42 +106,6 @@
(c2 << AD_COMP_2_SHIFT) | (c1 << AD_COMP_1_SHIFT) | \
(c0 << AD_COMP_0_SHIFT) | (size << AD_PIXEL_S_SHIFT))
 
-/**
- * p1022ds_get_pixel_format: return the Area Descriptor for a given pixel depth
- *
- * The Area Descriptor is a 32-bit value that determine which bits in each
- * pixel are to be used for each color.
- */
-static u32 p1022ds_get_pixel_format(enum fsl_diu_monitor_port port,
-   unsigned int bits_per_pixel)
-{
-   switch (bits_per_pixel) {
-   case 32:
-   /* 0x3316 */
-   return MAKE_AD(3, 2, 0, 1, 3, 8, 8, 8, 8);
-   case 24:
-   /* 0x88082219 */
-   return MAKE_AD(4, 0, 1, 2, 2, 0, 8, 8, 8);
-   case 16:
-   /* 0x65053118 */
-   return MAKE_AD(4, 2, 1, 0, 1, 5, 6, 5, 0);
-   default:
-   pr_err("fsl-diu: unsupported pixel depth %u\n", bits_per_pixel);
-   return 0;
-   }
-}
-
-/**
- * p1022ds_set_gamma_table: update the gamma table, if necessary
- *
- * On some boards, the gamma table for some ports may need to be modified.
- * This is not the case on the P1022DS, so we do nothing.
-*/
-static void p1022ds_set_gamma_table(enum fsl_diu_monitor_port port,
-   char *gamma_table_base)
-{
-}
-
 struct fsl_law {
u32 lawbar;
u32 reserved1;
@@ -510,8 +474,6 @@ static void __init p1022_ds_setup_arch(void)
ppc_md.progress("p1022_ds_setup_arch()", 0);
 
 #if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
-   diu_ops.get_pixel_format= p1022ds_get_pixel_format;
-   diu_ops.set_gamma_table = p1022ds_set_gamma_table;
diu_ops.set_monitor_port= p1022ds_set_monitor_port;
diu_ops.set_pixel_clock = p1022ds_set_pixel_clock;
diu_ops.valid_monitor_port  = p1022ds_valid_monitor_port;
diff --git a/arch/powerpc/platforms/85xx/p1022_rdk.c 
b/arch/powerpc/platforms/85xx/p1022_rdk.c
index 55ffa1c..8c92971 100644
--- a/arch/powerpc/platforms/85xx/p1022_rdk.c
+++ b/arch/powerpc/platforms/85xx/p1022_rdk.c
@@ -35,17 +35,6 @@
 #define CLKDVDR_PXCLK_MASK 0x00FF
 
 /**
- * p1022rdk_set_monitor_port: switch the output to a different monitor port
- */
-static void p1022rdk_set_monitor_port(enum fsl_diu_monitor_port port)
-{
-   if (port != FSL_DIU_PORT_DVI) {
-   pr_err("p1022rdk: unsupported monitor port %i\n", port);
-   return;
-   }
-}
-
-/**
  * p1022rdk_set_pixel_clock: program the DIU's clock
  *
  * @pixclock: the wavelength, in picoseconds, of the clock
@@ -124,7 +113,6 @@ static void __init p1022_rdk_setup_arch(void)
ppc_md.progress("p1022_rdk_setup_arch()", 0);
 
 #if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
-   diu_ops.set_monitor_port= p1022rdk_set_monitor_port;
diu_ops.set_pixel_clock = p1022rdk_set_pixel_clock;
diu_ops.valid_monitor_port  = p1022rdk_valid_monitor_port;
 #endif
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Anyone have a PrPmc 280/2800 handy?

2013-01-17 Thread Mark A. Greer
Hello.

I want to make some fixups to the marvell hostbridge and
mpsc code and would like to test them on a PrPmc280/2800.
The problem is, I don't have one anymore.

If you have one handy and don't mind running a quick boot
test for me,  please let me know.

Thanks,

Mark
--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 2/2] powerpc/85xx: describe the PAMU topology in the device tree

2013-01-17 Thread Timur Tabi
From: Timur Tabi 

The PAMU caches use the LIODNs to determine which cache lines hold the
entries for the corresponding LIODs.  The LIODNs must therefore be
carefully assigned to avoid cache thrashing -- two active LIODs with
LIODNs that put them in the same cache line.

Currently, LIODNs are statically assigned by U-Boot, but this has
limitations.  LIODNs are assigned even for devices that may be disabled
or unused by the kernel.  Static assignments also do not allow for device
drivers which may know which LIODs can be used simultaneously.  In
other words, we really should assign LIODNs dynamically in Linux.

To do that, we need to describe the PAMU device and cache topologies in
the device trees.

Signed-off-by: Timur Tabi 
---
 .../devicetree/bindings/powerpc/fsl/guts.txt   |   14 ++-
 .../devicetree/bindings/powerpc/fsl/pamu.txt   |  142 
 arch/powerpc/boot/dts/fsl/p2041si-post.dtsi|   87 +++--
 arch/powerpc/boot/dts/fsl/p3041si-post.dtsi|   87 +++--
 arch/powerpc/boot/dts/fsl/p4080si-post.dtsi|   68 +-
 arch/powerpc/boot/dts/fsl/p5020si-post.dtsi|   92 +++--
 arch/powerpc/boot/dts/fsl/p5040si-post.dtsi|   92 +++--
 7 files changed, 533 insertions(+), 49 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/pamu.txt

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
index 9e7a241..1970542 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
@@ -17,9 +17,21 @@ Recommended properties:
contains a functioning "reset control register" (i.e. the board
is wired to reset upon setting the HRESET_REQ bit in this register).
 
-Example:
+ - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
+   registers, for those SOCs that have a PAMU device.
+
+Examples:
global-utilities@e {/* global utilities block */
compatible = "fsl,mpc8548-guts";
reg = ;
fsl,has-rstcr;
};
+
+   guts: global-utilities@e {
+   compatible = "fsl,qoriq-device-config-1.0";
+   reg = <0xe 0xe00>;
+   fsl,has-rstcr;
+   #sleep-cells = <1>;
+   fsl,liodn-bits = <12>;
+   };
+
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
new file mode 100644
index 000..4826268
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
@@ -0,0 +1,142 @@
+Freescale Peripheral Management Access Unit (PAMU) Device Tree Binding
+
+DESCRIPTION
+
+The PAMU is an I/O MMU that provides device-to-memory access control and
+address translation capabilities.
+
+Required properties:
+
+- compatible   : 
+ First entry is a version-specific string, such as
+ "fsl,pamu-v1.0".  The second is "fsl,pamu".
+- ranges   : 
+ A standard property. Utilized to describe the memory mapped
+ I/O space utilized by the controller.  The size should
+ be set to the total size of the register space of all
+ physically present PAMU controllers.  For example, for
+ PAMU v1.0, on an SOC that has five PAMU devices, the size
+ is 0x5000.
+- interrupts   : 
+ Interrupt mappings.  The first tuple is the normal PAMU
+ interrupt, used for reporting access violations.  The second
+ is for PAMU hardware errors, such as PAMU operation errors
+ and ECC errors.
+- #address-cells: 
+ A standard property.
+- #size-cells  : 
+ A standard property.
+
+Optional properties:
+- reg  : 
+ A standard property.   It represents the CCSR registers of
+ all child PAMUs combined.  Include it to provide support
+ for legacy drivers.
+- interrupt-parent : 
+ Phandle to interrupt controller
+
+Child nodes:
+
+Each child node represents one PAMU controller.  Each SOC device that is
+connected to a specific PAMU device should have a "fsl,pamu-phandle" property
+that links to the corresponding specific child PAMU controller.
+
+- reg  : 
+ A standard property.  Specifies the physical address and
+ length (relative to the parent 'ranges' property) of this
+ PAMU controller's configuration registers.  The size should
+ be set to the size of this PAMU controllers's register space.
+ For PAMU v1.0, this size is 0x1000.
+- fsl,primary-cache-geometry
+   : 
+ Two cells that specify the geometry of the primary PAMU
+ cache.  The first is the number of cache lines

[PATCH 1/2] powerpc/85xx: fix various PCI node compatible strings

2013-01-17 Thread Timur Tabi
From: Timur Tabi 

Fix and/or improve the compatible strings of the PCI device tree nodes for
some Freescale SOCs.  This fixes some issues and improves consistency among
the SOCs.

Specifically:

1) The P1022 has a v1 PCIe controller, so the compatible property should just
say "fsl,mpc8548-pcie".  U-Boot does not look for "fsl,p1022-pcie", so it
wasn't fixing up the node.

2) The P4080 has a v2.1 PCIe controller, so add that version-specific string
to the device tree.  Update the kernel to also look for that string.
Currently, the kernel looks for "fsl,p4080-pcie" specifically, but
eventually that check should be deleted.

3) The P1010 device tree claims compatibility with v2.2 and v2.3, but that's
redundant.  No other device tree does this.  Remove the v2.2 string.

4) The kernel looks for both "fsl,p1023-pcie" and "fsl,qoriq-pcie-v2.2",
even though the P1023 device trees has always included both strings.  Remove
the search for "fsl,p1023-pcie".

Signed-off-by: Timur Tabi 
---
 arch/powerpc/boot/dts/fsl/p1010si-post.dtsi |4 ++--
 arch/powerpc/boot/dts/fsl/p1022si-post.dtsi |6 +++---
 arch/powerpc/boot/dts/fsl/p4080si-post.dtsi |6 +++---
 arch/powerpc/sysdev/fsl_pci.c   |   15 ++-
 4 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
index 0bde9ee..af12ead 100644
--- a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
@@ -41,7 +41,7 @@
 
 /* controller at 0x9000 */
 &pci0 {
-   compatible = "fsl,p1010-pcie", "fsl,qoriq-pcie-v2.3", 
"fsl,qoriq-pcie-v2.2";
+   compatible = "fsl,p1010-pcie", "fsl,qoriq-pcie-v2.3";
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
@@ -69,7 +69,7 @@
 
 /* controller at 0xa000 */
 &pci1 {
-   compatible = "fsl,p1010-pcie", "fsl,qoriq-pcie-v2.3", 
"fsl,qoriq-pcie-v2.2";
+   compatible = "fsl,p1010-pcie", "fsl,qoriq-pcie-v2.3";
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
diff --git a/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
index 06216b8..e179803 100644
--- a/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
@@ -45,7 +45,7 @@
 
 /* controller at 0x9000 */
 &pci0 {
-   compatible = "fsl,p1022-pcie";
+   compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
@@ -73,7 +73,7 @@
 
 /* controller at 0xa000 */
 &pci1 {
-   compatible = "fsl,p1022-pcie";
+   compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
@@ -102,7 +102,7 @@
 
 /* controller at 0xb000 */
 &pci2 {
-   compatible = "fsl,p1022-pcie";
+   compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
diff --git a/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
index 4f9c9f6..cf4f538 100644
--- a/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
@@ -41,7 +41,7 @@
 
 /* controller at 0x20 */
 &pci0 {
-   compatible = "fsl,p4080-pcie";
+   compatible = "fsl,p4080-pcie", "fsl,qoriq-pcie-v2.1";
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
@@ -68,7 +68,7 @@
 
 /* controller at 0x201000 */
 &pci1 {
-   compatible = "fsl,p4080-pcie";
+   compatible = "fsl,p4080-pcie", "fsl,qoriq-pcie-v2.1";
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
@@ -95,7 +95,7 @@
 
 /* controller at 0x202000 */
 &pci2 {
-   compatible = "fsl,p4080-pcie";
+   compatible = "fsl,p4080-pcie", "fsl,qoriq-pcie-v2.1";
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 92a5915..f213fb6 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -827,13 +827,18 @@ static const struct of_device_id pci_ids[] = {
{ .compatible = "fsl,mpc8548-pcie", },
{ .compatible = "fsl,mpc8610-pci", },
{ .compatible = "fsl,mpc8641-pcie", },
+   { .compatible = "fsl,qoriq-pcie-v2.1", },
+   { .compatible = "fsl,qoriq-pcie-v2.2", },
+   { .compatible = "fsl,qoriq-pcie-v2.3", },
+   { .compatible = "fsl,qoriq-pcie-v2.4", },
+
+   /*
+* The following entries are for compatibility with older device
+* trees.
+*/
{ .compatible = "fsl,p1022-pcie", },
-   { .compatible = "fsl,p1010-pcie", },
-   { .compatible = "fsl,p1023-pcie", },
{ .compatible = "fsl,p4080-pcie", },
-   { .compatible = "fsl,qoriq-pcie-v2.4", },
-   { .compatible = "fsl,qoriq-pcie-v2.3", },
-   { .compatible = "fsl,qoriq-

Re: [RFC PATCH v2 00/12] System device hot-plug framework

2013-01-17 Thread Toshi Kani
On Thu, 2013-01-17 at 01:50 +0100, Rafael J. Wysocki wrote:
> On Thursday, January 10, 2013 04:40:18 PM Toshi Kani wrote:
> > This patchset is a prototype of proposed system device hot-plug framework
> > for design review.  Unlike other hot-plug environments, such as USB and
> > PCI, there is no common framework for system device hot-plug [1].
> > Therefore, this patchset is designed to provide a common framework for
> > hot-plugging and online/offline operations of system devices, such as CPU,
> > Memory and Node.  While this patchset only supports ACPI-based hot-plug
> > operations, the framework itself is designed to be platform-neural and
> > can support other FW architectures as necessary.
 :
> At this point I'd like to clearly understand how the code is supposed to work.

Thanks for reviewing!

> From what I can say at the moment it all boils down to having two (ordered)
> lists of notifiers (shp_add_list, shp_del_list) that can be added to or 
> removed
> from with shp_register_handler() and shp_unregister_handler(), respectively

Yes.

> (BTW, the abbreviation "hdr" makes me think about a "header" rather than a
> "handler", but maybe that's just me :-)), 

Well, it makes me think that way as well. :)  How about "hdlr"?

> and a workqueue for requests (why do
> we need a separate workqueue for that?).

This workqueue needs to be platform-neutral and max_active set to 1, and
preferably is dedicated for hotplug operations.  kacpi_hotplug_wq is
close, but is ACPI-specific.  So, I decided to create a new workqueue
for this framework.

> Whoever needs to carry out a hotplug operation is supposed to prepare a 
> request
> and then put it into the workqueue with shp_submit_request().  The framework
> will then execute all of the notifier callbacks from the appropriate notifier
> list (depending on whether the operation is a hot-add or a hot-remove).  If 
> any
> of those callbacks returns an error code and it is not too late (the order of
> the failing notifier is not too high), the already executed notifier callbacks
> will be run again with the "rollback" argument set to 1 (why not to use bool?)

Agreed.  I will change the rollback to bool.

> to indicate that they are supposed to bring things back to the initial state.
> Error codes returned in that stage only cause messages to be printed.
>
> Is the description above correct?

Yes.  It's very good summary!

> If so, it looks like subsystems are supposed to register notifiers (handlers)
> for hotplug/hot-remove operations of the devices they handle.  They are
> supposed to use predefined order values to indicate what kinds of devices
> those are.  Then, hopefully, if they do everything correctly, and the
> initiator of a hotplug/hot-remove operation prepares the request correctly,
> the callbacks will be executed in the right order, they will find their
> devices in the list attached to the request object and they will do what's
> necessary with them.
> 
> Am I still on the right track?

Yes.

> If that's the case, I have a few questions.

Well, there are more than a few :), but they all are excellent
questions!

> (1) Why is this limited to system devices?

It could be extended to other devices, but is specifically designed for
system devices as follows.  So, I think it is best to keep it in that
way.

a) Work with multiple subsystems without bus dependency.  Other hot-plug
frameworks are designed and implemented for a particular bus and a
subsystem.  Therefore, they work best for their targeted environment as
well.

b) Sequence with pre-defined order.  This allows hot-add operation and
the boot sequence to be consistent.  Other non-system devices are
initialized within a subsystem, and do not depend on the boot-up
sequence.

> (2) What's the guarantee that the ordering of hot-removal (for example) of CPU
> cores with respect to memory and host bridges will always be the same?
> What if the CPU cores themselves need to be hot-removed in a specific
> order?

When devices are added in the order of A->B->C, their dependency model
is:
 - B may depend on A (but A may not depend on B)
 - C may depend on A and B (but A and B may not depend on C)

Therefore, they can be deleted in the order of C->B->A.

The boot sequence defines the order for add.  So, it is important to
make sure that we hot-add devices in the same order with the boot
sequence.  Of course, if there is an issue in the order, we need to fix
it.  But the point is that the add order should be consistent between
the boot sequence and hot-add.

In your example, the boot sequence adds them in the order of
memory->CPU->host bridge.  I think this makes sense because cpu may need
its local memory, and host bridge may need its local memory and local
cpu for interrupt.  So, hot-add needs to do the same for node hot-add,
and hot-delete should be able to delete them in the reversed order per
their dependency model.

> (3) What's the guarantee that the ordering of shp_add_list and shp_del_list
>

Re: [PATCH] perf: Fix PMU format parsing test failure

2013-01-17 Thread Jiri Olsa
On Thu, Jan 17, 2013 at 09:28:14AM -0800, Sukadev Bhattiprolu wrote:
> 
> From 776e6d7942754f139c27753213c9cf4617536618 Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu 
> Date: Thu, 17 Jan 2013 09:11:30 -0800
> Subject: [PATCH] perf; Fix PMU format parsing test failure
> 
> On POWER, the 'perf format parsing' test always fails.
> 
> Looks like it is because memset() is being passed number of longs
> rather than number of bytes. It is interesting that the test always
> passes on my x86 box.

indeed.. not sure how the bison 'union' stuff is (z)allocated,
x86 is probably lucky one ;-)

> 
> With this patch, the test passes on POWER and continues to pass on x86.
> 
> Signed-off-by: Sukadev Bhattiprolu 
> ---
>  tools/perf/util/include/linux/bitops.h |1 +
>  tools/perf/util/pmu.c  |2 +-
>  2 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/perf/util/include/linux/bitops.h 
> b/tools/perf/util/include/linux/bitops.h
> index a55d8cf..45cf10a 100644
> --- a/tools/perf/util/include/linux/bitops.h
> +++ b/tools/perf/util/include/linux/bitops.h
> @@ -14,6 +14,7 @@
>  #define BITS_TO_LONGS(nr)   DIV_ROUND_UP(nr, BITS_PER_BYTE * 
> sizeof(long))
>  #define BITS_TO_U64(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(u64))
>  #define BITS_TO_U32(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(u32))
> +#define BITS_TO_BYTES(nr)   DIV_ROUND_UP(nr, BITS_PER_BYTE)
>  
>  #define for_each_set_bit(bit, addr, size) \
>   for ((bit) = find_first_bit((addr), (size));\
> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index 9bdc60c..b93ff14 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c
> @@ -548,7 +548,7 @@ void perf_pmu__set_format(unsigned long *bits, long from, 
> long to)
>   if (!to)
>   to = from;
>  
> - memset(bits, 0, BITS_TO_LONGS(PERF_PMU_FORMAT_BITS));
> + memset(bits, 0, BITS_TO_BYTES(PERF_PMU_FORMAT_BITS));
>   for (b = from; b <= to; b++)
>   set_bit(b, bits);

oops, nice catch!

Acked-by: Jiri Olsa 

thanks,
jirka
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] perf: Fix PMU format parsing test failure

2013-01-17 Thread Sukadev Bhattiprolu

>From 776e6d7942754f139c27753213c9cf4617536618 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu 
Date: Thu, 17 Jan 2013 09:11:30 -0800
Subject: [PATCH] perf; Fix PMU format parsing test failure

On POWER, the 'perf format parsing' test always fails.

Looks like it is because memset() is being passed number of longs
rather than number of bytes. It is interesting that the test always
passes on my x86 box.

With this patch, the test passes on POWER and continues to pass on x86.

Signed-off-by: Sukadev Bhattiprolu 
---
 tools/perf/util/include/linux/bitops.h |1 +
 tools/perf/util/pmu.c  |2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/perf/util/include/linux/bitops.h 
b/tools/perf/util/include/linux/bitops.h
index a55d8cf..45cf10a 100644
--- a/tools/perf/util/include/linux/bitops.h
+++ b/tools/perf/util/include/linux/bitops.h
@@ -14,6 +14,7 @@
 #define BITS_TO_LONGS(nr)   DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))
 #define BITS_TO_U64(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(u64))
 #define BITS_TO_U32(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(u32))
+#define BITS_TO_BYTES(nr)   DIV_ROUND_UP(nr, BITS_PER_BYTE)
 
 #define for_each_set_bit(bit, addr, size) \
for ((bit) = find_first_bit((addr), (size));\
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 9bdc60c..b93ff14 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -548,7 +548,7 @@ void perf_pmu__set_format(unsigned long *bits, long from, 
long to)
if (!to)
to = from;
 
-   memset(bits, 0, BITS_TO_LONGS(PERF_PMU_FORMAT_BITS));
+   memset(bits, 0, BITS_TO_BYTES(PERF_PMU_FORMAT_BITS));
for (b = from; b <= to; b++)
set_bit(b, bits);
 }
-- 
1.7.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 3/6] usb: otg: utils: change the phy lib to support multiple PHYs of same type

2013-01-17 Thread Roger Quadros
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
> In order to add support for multipe PHY's of the same type, the API's
> for adding PHY and getting PHY has been changed. Now the binding
> information of the PHY and controller should be done in platform file
> using usb_bind_phy API. And for getting a PHY, the device pointer of the
> USB controller and an index should be passed. Based on the binding
> information that is added in the platform file, get_phy will return the
> approappropriate PHY.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  arch/arm/mach-shmobile/board-marzen.c |2 +-
>  drivers/power/ab8500_charger.c|2 +-
>  drivers/power/isp1704_charger.c   |2 +-
>  drivers/power/pda_power.c |2 +-
>  drivers/power/twl4030_charger.c   |2 +-
>  drivers/usb/chipidea/udc.c|2 +-
>  drivers/usb/dwc3/core.c   |4 +-
>  drivers/usb/gadget/fsl_udc_core.c |2 +-
>  drivers/usb/gadget/mv_udc_core.c  |2 +-
>  drivers/usb/gadget/omap_udc.c |2 +-
>  drivers/usb/gadget/pxa25x_udc.c   |2 +-
>  drivers/usb/gadget/pxa27x_udc.c   |2 +-
>  drivers/usb/gadget/s3c-hsudc.c|2 +-
>  drivers/usb/host/ehci-fsl.c   |2 +-
>  drivers/usb/host/ehci-msm.c   |2 +-
>  drivers/usb/host/ehci-mv.c|2 +-
>  drivers/usb/host/ehci-tegra.c |2 +-
>  drivers/usb/host/ohci-omap.c  |2 +-
>  drivers/usb/musb/am35x.c  |2 +-
>  drivers/usb/musb/blackfin.c   |2 +-
>  drivers/usb/musb/da8xx.c  |2 +-
>  drivers/usb/musb/davinci.c|2 +-
>  drivers/usb/musb/musb_dsps.c  |2 +-
>  drivers/usb/musb/omap2430.c   |2 +-
>  drivers/usb/musb/tusb6010.c   |2 +-
>  drivers/usb/musb/ux500.c  |2 +-
>  drivers/usb/otg/ab8500-usb.c  |3 +-
>  drivers/usb/otg/fsl_otg.c |5 ++-
>  drivers/usb/otg/gpio_vbus.c   |3 +-
>  drivers/usb/otg/isp1301_omap.c|3 +-
>  drivers/usb/otg/msm_otg.c |3 +-
>  drivers/usb/otg/mv_otg.c  |3 +-
>  drivers/usb/otg/nop-usb-xceiv.c   |3 +-
>  drivers/usb/otg/otg.c |   67 
> +++--
>  drivers/usb/otg/twl4030-usb.c |3 +-
>  drivers/usb/phy/mv_u3d_phy.c  |3 +-
>  drivers/usb/phy/omap-usb2.c   |   11 ++
>  drivers/usb/phy/rcar-phy.c|3 +-
>  include/linux/usb/phy.h   |   12 +++---
>  39 files changed, 87 insertions(+), 89 deletions(-)

I think it better to leave the existing add/get APIs as they are add add
new APIs that support multiple PHYs. You could probably mark the old
ones as deprecated.

That way you don't need to wait till all users are converted and tested.

e.g. you could name the new APIs as

usb_add_phy_dev(struct usb_phy *phy);
usb_get_phy_dev(struct device *dev, int index);

--
cheers,
-roger

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: therm_pm72 units, interface

2013-01-17 Thread Jan Engelhardt

On Wednesday 2012-08-15 23:36, Benjamin Herrenschmidt wrote:

>BTW... On a somewhat related note ... if you happen to have a spare
>Xserve G5 PSU I'm interested :-)

I tried pulling it out, but the PSU stuck so hard in the ATX-like 
mainboard power socket that removing the PSU would have probably meant 
ripping apart the MB.

Anyhow, I did a PMU reset (there's a documented button on the MB),
and 'lo, it seems the auto-poweroff that plagued this machine are
gone - but I'll need a longer uptime than 2 hours to find out.


Meanwhile, I run Linux 3.7.1 and the software side changed somewhat.
windfarm_rm31 seems to no longer calm the fans down once loaded,
whereas therm_pm72 on Linux 3.0 did so.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v6 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Fabio Estevam
On Thu, Jan 17, 2013 at 9:25 AM, Lothar Waßmann  
wrote:

> The equivalent of !cpu_is_mx51() would be
> strcmp(pdev->id_entry->name, "imx-udc-mx51") (without the '!') meaning
> id_entry->name is different from "imx-udc-mx51".

Yes, agree.

strcmp(pdev->id_entry->name, "imx-udc-mx51") is also better than
!strcmp(pdev->id_entry->name, "imx-udc-mx27"))

because in the case of another soc entry gets added, let's say
"imx-udc-mxyy" then

!strcmp(pdev->id_entry->name, "imx-udc-mx27")) will not correspond to
!cpu_is_mx51() anymore.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 6/6][v3] perf: Document the ABI of perf sysfs entries

2013-01-17 Thread Jiri Olsa
On Wed, Jan 16, 2013 at 10:58:16AM -0800, Sukadev Bhattiprolu wrote:
> Jiri Olsa [jo...@redhat.com] wrote:
> | On Tue, Jan 15, 2013 at 03:57:59PM -0300, Arnaldo Carvalho de Melo wrote:
> | > Em Wed, Jan 09, 2013 at 05:07:03PM -0800, Sukadev Bhattiprolu escreveu:
> | > > [PATCH 6/6][v3] perf: Document the ABI of perf sysfs entries
> | > > 
> | > > This patchset addes two new sets of files to sysfs:
> | > > 
> | > > - generic and POWER-specific perf events in 
> /sys/devices/cpu/events/
> | > > - perf event config format in /sys/devices/cpu/format/event
> | > > 
> | > > Document the format of these files which would become part of the ABI.
> | > > 
> | > > Changelog[v3]:
> | > > [Greg KH] Include ABI documentation.
> | > 
> | > Jiri, can I have your ack on this one too?
> | 
> | hm, we already already 'format' definition but in testing section
> | (and we are missing 'events' definition there.. my bad)
> 
> I see that file now ! I have removed that documentation from my patch.
> | 
> | anyway, after reading Documentation/ABI/README looks like we
> | should go for 'testing' section with this as well.. stable
> | seems scary at this point ;-)
> 
> Agree.
> 
> Here is the updated patch.
> ---
> 
> This patchset addes two new sets of files to sysfs for POWER architecture.
> 
>   - perf event config format in /sys/devices/cpu/format/event
>   - generic and POWER-specific perf events in /sys/devices/cpu/events/
> 
> The format of the first file is already documented in:
> 
>   Documentation/ABI/testing/sysfs-bus-event_source-devices-format
> 
> Document the format of the second set of files '/sys/devices/cpu/events/*'
> which would also become part of the ABI.
> 
> Changelog[v3.1]:
>   (small changes to this one patch).
>   [Jiri Olsa]: Remove the documentation for the 'config format' file
>   as it is already documented.
>   [Jiri Olsa]: Move the documentation of 'events' also to 'testing/'
> 
> Changelog[v3]:
>   [Greg KH] Include ABI documentation.
> 
> Signed-off-by: Sukadev Bhattiprolu 
> ---
>  .../testing/sysfs-bus-event_source-devices-events  |   58 
> 
>  1 files changed, 58 insertions(+), 0 deletions(-)
>  delete mode 100644 Documentation/ABI/stable/sysfs-devices-cpu-events
>  create mode 100644 
> Documentation/ABI/testing/sysfs-bus-event_source-devices-events
> 
> diff --git a/Documentation/ABI/stable/sysfs-devices-cpu-events 
> b/Documentation/ABI/stable/sysfs-devices-cpu-events
> deleted file mode 100644
> index e69de29..000
> diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events 
> b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
> new file mode 100644
> index 000..2c4081e
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
> @@ -0,0 +1,58 @@
> +What:/sys/devices/cpu/events/
> + /sys/devices/cpu/events/branch-misses
> + /sys/devices/cpu/events/cache-references
> + /sys/devices/cpu/events/cache-misses
> + /sys/devices/cpu/events/stalled-cycles-frontend
> + /sys/devices/cpu/events/branch-instructions
> + /sys/devices/cpu/events/stalled-cycles-backend
> + /sys/devices/cpu/events/instructions
> + /sys/devices/cpu/events/cpu-cycles
> +
> +Date:2012/01/NN
> +
> +Contact: Linux kernel mailing list 
> +
> +Description: Generic performance monitoring events
> +
> + A collection of performance monitoring events that may be
> + supported by many/most CPUs. These events can be monitored
> + using the 'perf(1)' tool.
> +
> + The contents of each file would look like:
> +
> + event=0x
> +
> + where 'N' is a hex digit and the number '0x' shows the
> + "raw code" for the perf event identified by the file's
> + "basename".

Maybe it'd worth to mention, that it does not need to be just 'event',
but anything from /sys/bus/event_source/devices//format directory,
like

The can be multiple terms like 'event=0x' specified
and separated with comma. All available terms are located
in /sys/bus/event_source/devices//format file.

Please feel free to rephrase or use proper English ;-)

otherwise it's ok,
jirka
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information

2013-01-17 Thread Vivek Gautam
Hi Kishon,


Thanks for the explanation.

On Thu, Jan 17, 2013 at 6:01 PM, kishon  wrote:
> Hi,
>
>
> On Thursday 17 January 2013 05:41 PM, Vivek Gautam wrote:
>>
>> Hi Kishon,
>>
>>
>> On Wed, Jan 16, 2013 at 8:30 PM, Kishon Vijay Abraham I 
>> wrote:
>>>
>>> This is in preparation for the changes in PHY library to support adding
>>> and getting multiple PHYs of the same type. In the new design, the
>>> binding information between the PHY and the USB controller should be
>>> specified in the platform specific initialization code. So it's been
>>> done for OMAP platforms here.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I 
>>> ---
>>> This kind-of binding should be done in all the platforms (I've done only
>>> for OMAP platform).
>>>   arch/arm/mach-omap2/usb-musb.c |7 ++-
>>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/usb-musb.c
>>> b/arch/arm/mach-omap2/usb-musb.c
>>> index 9d27e3f..bbe2fa5 100644
>>> --- a/arch/arm/mach-omap2/usb-musb.c
>>> +++ b/arch/arm/mach-omap2/usb-musb.c
>>> @@ -24,6 +24,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>
>>>   #include "omap_device.h"
>>>   #include "soc.h"
>>> @@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data
>>> *musb_board_data)
>>>  musb_plat.mode = board_data->mode;
>>>  musb_plat.extvbus = board_data->extvbus;
>>>
>>> -   if (cpu_is_omap44xx())
>>> +   if (cpu_is_omap44xx()) {
>>>  musb_plat.has_mailbox = true;
>>> +   usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
>>> +   } else if (cpu_is_omap34xx()) {
>>> +   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
>>> +   }
>>
>>
>> Just trying to understand things here.
>> Is the device name we are using here the platform device name (pdev->name)
>> ?
>
>
> it's pdev->dev.name.
>
>> If i am not wrong then for devices added through device tree
>> the device name would actually include the device address in the string,
>
>
> Ideally for device tree, devm_usb_get_phy_by_phandle() introduced in the 5th
> patch of this series should be used.

Ok.
> usb_bind_phy should be called from platform specific initialization files
> (like your board file), which won't get executed in dt boot.
>
Right.

>> wouldn't that make things somewhat weird, since we will have to add
>> such bindings
>> using this address string.
>>
>> one more doubt please :)
>> is it possible to bind phy in the controllers' driver somehow ?
>
> Thats not going to be good. Why do you need to do that?
>
I was certainly missing something while understanding your patches.
That's why got some doubt on this. :)


> Thanks
> Kishon



-- 
Thanks & Regards
Vivek
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information

2013-01-17 Thread Vivek Gautam
Hi Kishon,


On Wed, Jan 16, 2013 at 8:30 PM, Kishon Vijay Abraham I  wrote:
> This is in preparation for the changes in PHY library to support adding
> and getting multiple PHYs of the same type. In the new design, the
> binding information between the PHY and the USB controller should be
> specified in the platform specific initialization code. So it's been
> done for OMAP platforms here.
>
> Signed-off-by: Kishon Vijay Abraham I 
> ---
> This kind-of binding should be done in all the platforms (I've done only
> for OMAP platform).
>  arch/arm/mach-omap2/usb-musb.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 9d27e3f..bbe2fa5 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "omap_device.h"
>  #include "soc.h"
> @@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data 
> *musb_board_data)
> musb_plat.mode = board_data->mode;
> musb_plat.extvbus = board_data->extvbus;
>
> -   if (cpu_is_omap44xx())
> +   if (cpu_is_omap44xx()) {
> musb_plat.has_mailbox = true;
> +   usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
> +   } else if (cpu_is_omap34xx()) {
> +   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
> +   }

Just trying to understand things here.
Is the device name we are using here the platform device name (pdev->name) ?
If i am not wrong then for devices added through device tree
the device name would actually include the device address in the string,
wouldn't that make things somewhat weird, since we will have to add
such bindings
using this address string.

one more doubt please :)
is it possible to bind phy in the controllers' driver somehow ?

>
> if (soc_is_am35xx()) {
> oh_name = "am35x_otg_hs";
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks & Regards
Vivek
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v6 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Lothar Waßmann
Hi,

Fabio Estevam writes:
> On Thu, Jan 17, 2013 at 8:01 AM, Peter Chen  wrote:
> 
> > /* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
> > -   if (!cpu_is_mx51()) {
> > +   if (!strcmp(pdev->id_entry->name, "imx-udc-mx27")) {]]
> 
> Shouldn't this be:
>  if (!strcmp(pdev->id_entry->name, "imx-udc-mx51"))
>
The equivalent of !cpu_is_mx51() would be
strcmp(pdev->id_entry->name, "imx-udc-mx51") (without the '!') meaning
id_entry->name is different from "imx-udc-mx51".

I personally hate the '!strcmp()' notation and prefer 'strcmp() == 0'
though they are technically equivalent. Using '==' makes it much
clearer to the reader what is intended.
!strcmp() lets one assume that it is true when the comparison fails,
though actually the opposite is true.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information

2013-01-17 Thread Roger Quadros
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
> This is in preparation for the changes in PHY library to support adding
> and getting multiple PHYs of the same type. In the new design, the
> binding information between the PHY and the USB controller should be
> specified in the platform specific initialization code. So it's been
> done for OMAP platforms here.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
> This kind-of binding should be done in all the platforms (I've done only
> for OMAP platform). 
>  arch/arm/mach-omap2/usb-musb.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 9d27e3f..bbe2fa5 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "omap_device.h"
>  #include "soc.h"
> @@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data 
> *musb_board_data)
>   musb_plat.mode = board_data->mode;
>   musb_plat.extvbus = board_data->extvbus;
>  
> - if (cpu_is_omap44xx())
> + if (cpu_is_omap44xx()) {
>   musb_plat.has_mailbox = true;
> + usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
> + } else if (cpu_is_omap34xx()) {
> + usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
> + }

Are you sure than these OMAP platforms cannot be wired in any other way
to the PHY?

If they can be then this association must come from the board files or
device tree.

>  
>   if (soc_is_am35xx()) {
>   oh_name = "am35x_otg_hs";
> 

--
cheers,
-roger
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 1/6] usb: otg: Add an API to bind the USB controller and PHY

2013-01-17 Thread Roger Quadros
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
> New platforms are added which has multiple PHY's (of same type) and
> which has multiple USB controllers. The binding information has to be
> present in the PHY library (otg.c) in order for it to return the
> appropriate PHY whenever the USB controller request for the PHY. So
> added a new API to pass the binding information. This API should be
> called by platform specific initialization code.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/usb/otg/otg.c   |   37 +
>  include/linux/usb/phy.h |   22 ++
>  2 files changed, 59 insertions(+)
> 
> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
> index a30c041..492ba2f 100644
> --- a/drivers/usb/otg/otg.c
> +++ b/drivers/usb/otg/otg.c
> @@ -18,6 +18,7 @@
>  #include 
>  
>  static LIST_HEAD(phy_list);
> +static LIST_HEAD(phy_bind_list);
>  static DEFINE_SPINLOCK(phy_lock);
>  
>  static struct usb_phy *__usb_find_phy(struct list_head *list,
> @@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
>  }
>  EXPORT_SYMBOL(usb_remove_phy);
>  
> +/**
> + * usb_bind_phy - bind the phy and the controller that uses the phy
> + * @dev_name: the device name of the device that will bind to the phy
> + * @index: index to specify the port number
> + * @phy_dev_name: the device name of the phy
> + *
> + * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
> + * be used when the phy driver registers the phy and when the controller
> + * requests this phy.
> + *
> + * To be used by platform specific initialization code.
> + */
> +struct usb_phy_bind __init *usb_bind_phy(const char *dev_name, u8 index,
> + const char *phy_dev_name)
> +{
> + struct usb_phy_bind *phy_bind;
> + unsigned long flags;
> +
> + phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
> + if (!phy_bind) {
> + pr_err("phy_bind(): No memory for phy_bind");

Function name in comment doesn't match the actual.
Instead, you could use
pr_err("%s ...", __func__);

> + return ERR_PTR(-ENOMEM);
> + }
> +
> + phy_bind->dev_name = dev_name;
> + phy_bind->phy_dev_name = phy_dev_name;
> + phy_bind->index = index;
> +
> + spin_lock_irqsave(&phy_lock, flags);
> + list_add_tail(&phy_bind->list, &phy_bind_list);
> + spin_unlock_irqrestore(&phy_lock, flags);
> +
> + return phy_bind;
> +}
> +EXPORT_SYMBOL_GPL(usb_bind_phy);
> +
>  const char *otg_state_string(enum usb_otg_state state)
>  {
>   switch (state) {
> diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
> index a29ae1e..fbeab1a 100644
> --- a/include/linux/usb/phy.h
> +++ b/include/linux/usb/phy.h
> @@ -106,6 +106,21 @@ struct usb_phy {
>   enum usb_device_speed speed);
>  };
>  
> +/**
> + * struct usb_phy_bind - represent the binding for the phy
> + * @dev_name: the device name of the device that will bind to the phy
> + * @phy_dev_name: the device name of the phy
> + * @index: used if a single controller uses multiple phys
> + * @phy: reference to the phy
> + * @list: to maintain a linked list of the binding information
> + */
> +struct usb_phy_bind {
> + const char  *dev_name;
> + const char  *phy_dev_name;
> + u8  index;
> + struct usb_phy  *phy;
> + struct list_head list;
> +};
>  
>  /* for board-specific init logic */
>  extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
> @@ -151,6 +166,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device 
> *dev,
>   enum usb_phy_type type);
>  extern void usb_put_phy(struct usb_phy *);
>  extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
> +extern struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
> + const char *phy_dev_name);
>  #else
>  static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
>  {
> @@ -171,6 +188,11 @@ static inline void devm_usb_put_phy(struct device *dev, 
> struct usb_phy *x)
>  {
>  }
>  
> +static inline struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 
> index,
> + const char *phy_dev_name)
> +{
> + return NULL;
> +}
>  #endif
>  
>  static inline int
> 

Controllers like ehci-omap which don't need OTG functionality would
benefit from this API. Can we make these PHY APIs not dependent on OTG /
OTG_UTILS?

cheers,
-roger

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v3 1/2] memory-hotplug: introduce CONFIG_HAVE_BOOTMEM_INFO_NODE and revert register_page_bootmem_info_node() when platform not support

2013-01-17 Thread Michal Hocko
On Thu 17-01-13 18:37:10, Lin Feng wrote:
[...]
> > I am still not sure I understand the relation to MEMORY_HOTREMOVE.
> > Is register_page_bootmem_info_node required/helpful even if
> > !CONFIG_MEMORY_HOTREMOVE?
> From old kenrel's view register_page_bootmem_info_node() is defined in 
> CONFIG_MEMORY_HOTPLUG_SPARSE, it registers some info for 
> memory hotplug/remove. If we don't use MEMORY_HOTPLUG feature, this
> function is empty, we don't need the info at all.
> So this info is not required/helpful if !CONFIG_MEMORY_HOTREMOVE.

OK, then I suggest moving it under CONFIG_MEMORY_HOTREMOVE guards rather
than CONFIG_MEMORY_HOTPLUG.

> > Also, now that I am thinking about that more, maybe it would
> > be cleaner to put the select into arch/x86/Kconfig and do it
> > same as ARCH_ENABLE_MEMORY_{HOTPLUG,HOTREMOVE} (and name it
> > ARCH_HAVE_BOOTMEM_INFO_NODE).
> > 
> Maybe put it in mm/Kconfig is a better choice, because if one day
> someone implements the register_page_bootmem_info_node() for other
> archs they will get some clues here, that's it has been implemented on
> x86_64.
> But I'm not so sure...

My understanding is that doing that in arch code is more appropriate
because it makes the generic code less complicated. But I do not have
any strong opinion on that. Looking at other ARCH_ENABLE_MEMORY_HOTPLUG
and others suggests that we should be consistent with that.

Thanks!
-- 
Michal Hocko
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information

2013-01-17 Thread kishon

Hi,

On Thursday 17 January 2013 05:41 PM, Vivek Gautam wrote:

Hi Kishon,


On Wed, Jan 16, 2013 at 8:30 PM, Kishon Vijay Abraham I  wrote:

This is in preparation for the changes in PHY library to support adding
and getting multiple PHYs of the same type. In the new design, the
binding information between the PHY and the USB controller should be
specified in the platform specific initialization code. So it's been
done for OMAP platforms here.

Signed-off-by: Kishon Vijay Abraham I 
---
This kind-of binding should be done in all the platforms (I've done only
for OMAP platform).
  arch/arm/mach-omap2/usb-musb.c |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 9d27e3f..bbe2fa5 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "omap_device.h"
  #include "soc.h"
@@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data 
*musb_board_data)
 musb_plat.mode = board_data->mode;
 musb_plat.extvbus = board_data->extvbus;

-   if (cpu_is_omap44xx())
+   if (cpu_is_omap44xx()) {
 musb_plat.has_mailbox = true;
+   usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+   } else if (cpu_is_omap34xx()) {
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+   }


Just trying to understand things here.
Is the device name we are using here the platform device name (pdev->name) ?


it's pdev->dev.name.

If i am not wrong then for devices added through device tree
the device name would actually include the device address in the string,


Ideally for device tree, devm_usb_get_phy_by_phandle() introduced in the 
5th patch of this series should be used.
usb_bind_phy should be called from platform specific initialization 
files (like your board file), which won't get executed in dt boot.

wouldn't that make things somewhat weird, since we will have to add
such bindings
using this address string.

one more doubt please :)
is it possible to bind phy in the controllers' driver somehow ?

Thats not going to be good. Why do you need to do that?

Thanks
Kishon
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 1/6] usb: otg: Add an API to bind the USB controller and PHY

2013-01-17 Thread kishon

Hi,

On Thursday 17 January 2013 03:07 PM, Roger Quadros wrote:

On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:

New platforms are added which has multiple PHY's (of same type) and
which has multiple USB controllers. The binding information has to be
present in the PHY library (otg.c) in order for it to return the
appropriate PHY whenever the USB controller request for the PHY. So
added a new API to pass the binding information. This API should be
called by platform specific initialization code.

Signed-off-by: Kishon Vijay Abraham I 
---
  drivers/usb/otg/otg.c   |   37 +
  include/linux/usb/phy.h |   22 ++
  2 files changed, 59 insertions(+)

diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index a30c041..492ba2f 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -18,6 +18,7 @@
  #include 

  static LIST_HEAD(phy_list);
+static LIST_HEAD(phy_bind_list);
  static DEFINE_SPINLOCK(phy_lock);

  static struct usb_phy *__usb_find_phy(struct list_head *list,
@@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
  }
  EXPORT_SYMBOL(usb_remove_phy);

+/**
+ * usb_bind_phy - bind the phy and the controller that uses the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @index: index to specify the port number
+ * @phy_dev_name: the device name of the phy
+ *
+ * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
+ * be used when the phy driver registers the phy and when the controller
+ * requests this phy.
+ *
+ * To be used by platform specific initialization code.
+ */
+struct usb_phy_bind __init *usb_bind_phy(const char *dev_name, u8 index,
+   const char *phy_dev_name)
+{
+   struct usb_phy_bind *phy_bind;
+   unsigned long flags;
+
+   phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
+   if (!phy_bind) {
+   pr_err("phy_bind(): No memory for phy_bind");


Function name in comment doesn't match the actual.
Instead, you could use
pr_err("%s ...", __func__);


+   return ERR_PTR(-ENOMEM);
+   }
+
+   phy_bind->dev_name = dev_name;
+   phy_bind->phy_dev_name = phy_dev_name;
+   phy_bind->index = index;
+
+   spin_lock_irqsave(&phy_lock, flags);
+   list_add_tail(&phy_bind->list, &phy_bind_list);
+   spin_unlock_irqrestore(&phy_lock, flags);
+
+   return phy_bind;
+}
+EXPORT_SYMBOL_GPL(usb_bind_phy);
+
  const char *otg_state_string(enum usb_otg_state state)
  {
switch (state) {
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index a29ae1e..fbeab1a 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -106,6 +106,21 @@ struct usb_phy {
enum usb_device_speed speed);
  };

+/**
+ * struct usb_phy_bind - represent the binding for the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @phy_dev_name: the device name of the phy
+ * @index: used if a single controller uses multiple phys
+ * @phy: reference to the phy
+ * @list: to maintain a linked list of the binding information
+ */
+struct usb_phy_bind {
+   const char  *dev_name;
+   const char  *phy_dev_name;
+   u8  index;
+   struct usb_phy  *phy;
+   struct list_head list;
+};

  /* for board-specific init logic */
  extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
@@ -151,6 +166,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type);
  extern void usb_put_phy(struct usb_phy *);
  extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
+extern struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
+   const char *phy_dev_name);
  #else
  static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
  {
@@ -171,6 +188,11 @@ static inline void devm_usb_put_phy(struct device *dev, 
struct usb_phy *x)
  {
  }

+static inline struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
+   const char *phy_dev_name)
+{
+   return NULL;
+}
  #endif

  static inline int



Controllers like ehci-omap which don't need OTG functionality would
benefit from this API. Can we make these PHY APIs not dependent on OTG /
OTG_UTILS?


Actually much of whatever is in otg.c can be used by controllers which 
don't have OTG functionality (except otg_state_string). I vaguely 
remember, there was a patch that renamed otg.c to phy.c etc.. I'm not 
sure what happened to that.


Thanks
Kishon
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v6 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Fabio Estevam
On Thu, Jan 17, 2013 at 8:01 AM, Peter Chen  wrote:

> /* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
> -   if (!cpu_is_mx51()) {
> +   if (!strcmp(pdev->id_entry->name, "imx-udc-mx27")) {]]

Shouldn't this be:
 if (!strcmp(pdev->id_entry->name, "imx-udc-mx51"))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v3 1/2] memory-hotplug: introduce CONFIG_HAVE_BOOTMEM_INFO_NODE and revert register_page_bootmem_info_node() when platform not support

2013-01-17 Thread Lin Feng
Hi Michal,

On 01/16/2013 10:14 PM, Michal Hocko wrote:
> On Wed 16-01-13 16:14:18, Lin Feng wrote:
> [...]
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 278e3ab..f8c5799 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -162,10 +162,18 @@ config MOVABLE_NODE
>>Say Y here if you want to hotplug a whole node.
>>Say N here if you want kernel to use memory on all nodes evenly.
>>  
>> +#
>> +# Only be set on architectures that have completely implemented memory 
>> hotplug
>> +# feature. If you are not sure, don't touch it.
>> +#
>> +config HAVE_BOOTMEM_INFO_NODE
>> +def_bool n
>> +
>>  # eventually, we can have this option just 'select SPARSEMEM'
>>  config MEMORY_HOTPLUG
>>  bool "Allow for memory hot-add"
>>  select MEMORY_ISOLATION
>> +select HAVE_BOOTMEM_INFO_NODE if X86_64
>>  depends on SPARSEMEM || X86_64_ACPI_NUMA
>>  depends on HOTPLUG && ARCH_ENABLE_MEMORY_HOTPLUG
>>  depends on (IA64 || X86 || PPC_BOOK3S_64 || SUPERH || S390)
> 
> I am still not sure I understand the relation to MEMORY_HOTREMOVE.
> Is register_page_bootmem_info_node required/helpful even if
> !CONFIG_MEMORY_HOTREMOVE?
>From old kenrel's view register_page_bootmem_info_node() is defined in 
CONFIG_MEMORY_HOTPLUG_SPARSE, it registers some info for 
memory hotplug/remove. If we don't use MEMORY_HOTPLUG feature, this
function is empty, we don't need the info at all.
So this info is not required/helpful if !CONFIG_MEMORY_HOTREMOVE.
> 
> Also, now that I am thinking about that more, maybe it would
> be cleaner to put the select into arch/x86/Kconfig and do it
> same as ARCH_ENABLE_MEMORY_{HOTPLUG,HOTREMOVE} (and name it
> ARCH_HAVE_BOOTMEM_INFO_NODE).
> 
Maybe put it in mm/Kconfig is a better choice, because if one day someone 
implements
the register_page_bootmem_info_node() for other archs they will get some clues
here, that's it has been implemented on x86_64. 
But I'm not so sure...

thanks,
linfeng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information

2013-01-17 Thread kishon

Hi,

On Thursday 17 January 2013 03:09 PM, Roger Quadros wrote:

On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:

This is in preparation for the changes in PHY library to support adding
and getting multiple PHYs of the same type. In the new design, the
binding information between the PHY and the USB controller should be
specified in the platform specific initialization code. So it's been
done for OMAP platforms here.

Signed-off-by: Kishon Vijay Abraham I 
---
This kind-of binding should be done in all the platforms (I've done only
for OMAP platform).
  arch/arm/mach-omap2/usb-musb.c |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 9d27e3f..bbe2fa5 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "omap_device.h"
  #include "soc.h"
@@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data 
*musb_board_data)
musb_plat.mode = board_data->mode;
musb_plat.extvbus = board_data->extvbus;

-   if (cpu_is_omap44xx())
+   if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+   usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+   } else if (cpu_is_omap34xx()) {
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+   }


Are you sure than these OMAP platforms cannot be wired in any other way
to the PHY?

If they can be then this association must come from the board files or
device tree.


I had given some thought about that and since all the existing OMAP 
platforms had it this way, I added it here.

You having pointed that out, I'll move these to board files.

Thanks
Kishon
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v6 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc

2013-01-17 Thread Shawn Guo
On Thu, Jan 17, 2013 at 12:58:33PM +0200, Felipe Balbi wrote:
> On Thu, Jan 17, 2013 at 06:03:17PM +0800, Peter Chen wrote:
> > As we use platform_device_id for fsl-usb2-udc driver, it needs to
> > change clk connection-id, or the related devm_clk_get will be failed.
> > 
> > Signed-off-by: Peter Chen 
> 
> do I get Acked-by for this one ?

Acked-by: Shawn Guo 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v6 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc

2013-01-17 Thread Felipe Balbi
On Thu, Jan 17, 2013 at 06:03:17PM +0800, Peter Chen wrote:
> As we use platform_device_id for fsl-usb2-udc driver, it needs to
> change clk connection-id, or the related devm_clk_get will be failed.
> 
> Signed-off-by: Peter Chen 

do I get Acked-by for this one ?

-- 
balbi


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v6 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc

2013-01-17 Thread Peter Chen
As we use platform_device_id for fsl-usb2-udc driver, it needs to
change clk connection-id, or the related devm_clk_get will be failed.

Signed-off-by: Peter Chen 
---
 arch/arm/mach-imx/clk-imx25.c   |6 +++---
 arch/arm/mach-imx/clk-imx27.c   |6 +++---
 arch/arm/mach-imx/clk-imx31.c   |6 +++---
 arch/arm/mach-imx/clk-imx35.c   |6 +++---
 arch/arm/mach-imx/clk-imx51-imx53.c |6 +++---
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index b197aa7..2c570cd 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -254,9 +254,9 @@ int __init mx25_clocks_init(void)
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usbotg_ahb], "ahb", "mxc-ehci.2");
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2");
-   clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usbotg_ahb], "ahb", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
+   clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx27");
+   clk_register_clkdev(clk[usbotg_ahb], "ahb", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27");
clk_register_clkdev(clk[nfc_ipg_per], NULL, "imx25-nand.0");
/* i.mx25 has the i.mx35 type cspi */
clk_register_clkdev(clk[cspi1_ipg], NULL, "imx35-cspi.0");
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 4c1d1e4..1ffe3b5 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -236,9 +236,9 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx21-fb.0");
clk_register_clkdev(clk[csi_ahb_gate], "ahb", "imx27-camera.0");
clk_register_clkdev(clk[per4_gate], "per", "imx27-camera.0");
-   clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc");
+   clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_ipg_gate], "ipg", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_ahb_gate], "ahb", "imx-udc-mx27");
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.0");
clk_register_clkdev(clk[usb_ipg_gate], "ipg", "mxc-ehci.0");
clk_register_clkdev(clk[usb_ahb_gate], "ahb", "mxc-ehci.0");
diff --git a/arch/arm/mach-imx/clk-imx31.c b/arch/arm/mach-imx/clk-imx31.c
index 8be64e0..16ccbd4 100644
--- a/arch/arm/mach-imx/clk-imx31.c
+++ b/arch/arm/mach-imx/clk-imx31.c
@@ -139,9 +139,9 @@ int __init mx31_clocks_init(unsigned long fref)
clk_register_clkdev(clk[usb_div_post], "per", "mxc-ehci.2");
clk_register_clkdev(clk[usb_gate], "ahb", "mxc-ehci.2");
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
-   clk_register_clkdev(clk[usb_div_post], "per", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_gate], "ahb", "fsl-usb2-udc");
-   clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
+   clk_register_clkdev(clk[usb_div_post], "per", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_gate], "ahb", "imx-udc-mx27");
+   clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx27");
clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0");
/* i.mx31 has the i.mx21 type uart */
clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0");
diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c
index 66f3d65..f0727e8 100644
--- a/arch/arm/mach-imx/clk-imx35.c
+++ b/arch/arm/mach-imx/clk-imx35.c
@@ -251,9 +251,9 @@ int __init mx35_clocks_init()
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2");
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usbotg_gate], "ahb", "mxc-ehci.2");
-   clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
-   clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usbotg_gate], "ahb", "fsl-usb2-udc");
+   clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27");
+   clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx27");
+   clk_register_clkdev(clk[usbotg_gate], "ahb", "imx-udc-mx27");
clk_register_clkdev(clk[wdog_gate], NULL, "imx2-wdt.0");
clk_register_clkdev(clk[nfc_div], NULL, "imx25-nand.0");
clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0");
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c 
b/arch/arm/mach-imx/clk-imx51-imx53.c
index 579023f..fb7cb84 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -269,9 +269,9 @@ static void __init mx5_clocks_common_init(unsigned long 
rate_ckil,
clk_register_clkdev(clk[usboh3_per_gate], "per", "mxc-ehci.2");
clk_register_clkdev(clk[usboh3_gate], "ipg", "mx

[PATCH v6 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Peter Chen
As mach/hardware.h is deleted, we need to use platform_device_id to
differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
already used pdata to differentiate runtime

Meanwhile we update the platform code accordingly.

Signed-off-by: Peter Chen 
---
 arch/arm/mach-imx/devices/devices-common.h|1 +
 arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c |   15 
 drivers/usb/gadget/fsl_mxc_udc.c  |   24 +
 drivers/usb/gadget/fsl_udc_core.c |   38 -
 4 files changed, 41 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mach-imx/devices/devices-common.h 
b/arch/arm/mach-imx/devices/devices-common.h
index 6277baf..9bd5777 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -63,6 +63,7 @@ struct platform_device *__init imx_add_flexcan(
 
 #include 
 struct imx_fsl_usb2_udc_data {
+   const char *devid;
resource_size_t iobase;
resource_size_t irq;
 };
diff --git a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c 
b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
index 37e4439..3c06bd9 100644
--- a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
+++ b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
@@ -11,35 +11,36 @@
 #include "../hardware.h"
 #include "devices-common.h"
 
-#define imx_fsl_usb2_udc_data_entry_single(soc)
\
+#define imx_fsl_usb2_udc_data_entry_single(soc, _devid)
\
{   \
+   .devid = _devid,\
.iobase = soc ## _USB_OTG_BASE_ADDR,\
.irq = soc ## _INT_USB_OTG, \
}
 
 #ifdef CONFIG_SOC_IMX25
 const struct imx_fsl_usb2_udc_data imx25_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX25);
+   imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX25 */
 
 #ifdef CONFIG_SOC_IMX27
 const struct imx_fsl_usb2_udc_data imx27_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX27);
+   imx_fsl_usb2_udc_data_entry_single(MX27, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX27 */
 
 #ifdef CONFIG_SOC_IMX31
 const struct imx_fsl_usb2_udc_data imx31_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX31);
+   imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX31 */
 
 #ifdef CONFIG_SOC_IMX35
 const struct imx_fsl_usb2_udc_data imx35_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX35);
+   imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX35 */
 
 #ifdef CONFIG_SOC_IMX51
 const struct imx_fsl_usb2_udc_data imx51_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX51);
+   imx_fsl_usb2_udc_data_entry_single(MX51, "imx-udc-mx51");
 #endif
 
 struct platform_device *__init imx_add_fsl_usb2_udc(
@@ -57,7 +58,7 @@ struct platform_device *__init imx_add_fsl_usb2_udc(
.flags = IORESOURCE_IRQ,
},
};
-   return imx_add_platform_device_dmamask("fsl-usb2-udc", -1,
+   return imx_add_platform_device_dmamask(data->devid, -1,
res, ARRAY_SIZE(res),
pdata, sizeof(*pdata), DMA_BIT_MASK(32));
 }
diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index 1b0f086..de851e5 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -18,8 +18,6 @@
 #include 
 #include 
 
-#include 
-
 static struct clk *mxc_ahb_clk;
 static struct clk *mxc_per_clk;
 static struct clk *mxc_ipg_clk;
@@ -59,7 +57,7 @@ int fsl_udc_clk_init(struct platform_device *pdev)
clk_prepare_enable(mxc_per_clk);
 
/* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
-   if (!cpu_is_mx51()) {
+   if (!strcmp(pdev->id_entry->name, "imx-udc-mx27")) {
freq = clk_get_rate(mxc_per_clk);
if (pdata->phy_mode != FSL_USB2_PHY_ULPI &&
(freq < 5000 || freq > 60001000)) {
@@ -82,17 +80,15 @@ eclkrate:
 void fsl_udc_clk_finalize(struct platform_device *pdev)
 {
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
-   if (cpu_is_mx35()) {
-   unsigned int v;
-
-   /* workaround ENGcm09152 for i.MX35 */
-   if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
-   v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
-   USBPHYCTRL_OTGBASE_OFFSET));
-   writel(v | USBPHYCTRL_EVDO,
-   MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
-   USBPHYCTRL_OTGBASE_OFFSET));
-  

[PATCH v6 2/3] usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap

2013-01-17 Thread Peter Chen
As mach/hardware.h is deleted, we can't visit platform code at driver.
It has no phy driver to combine with this controller, so it has to use
ioremap to map phy address as a workaround.

Signed-off-by: Peter Chen 
---
 drivers/usb/gadget/fsl_mxc_udc.c  |   30 +++---
 drivers/usb/gadget/fsl_udc_core.c |4 +++-
 drivers/usb/gadget/fsl_usb2_udc.h |5 +++--
 3 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index de851e5..d3bd7b0 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -23,7 +23,8 @@ static struct clk *mxc_per_clk;
 static struct clk *mxc_ipg_clk;
 
 /* workaround ENGcm09152 for i.MX35 */
-#define USBPHYCTRL_OTGBASE_OFFSET  0x608
+#define MX35_USBPHYCTRL_OFFSET 0x600
+#define USBPHYCTRL_OTGBASE_OFFSET  0x8
 #define USBPHYCTRL_EVDO(1 << 23)
 
 int fsl_udc_clk_init(struct platform_device *pdev)
@@ -77,25 +78,40 @@ eclkrate:
return ret;
 }
 
-void fsl_udc_clk_finalize(struct platform_device *pdev)
+int fsl_udc_clk_finalize(struct platform_device *pdev)
 {
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
-   unsigned int v;
+   int ret = 0;
 
/* workaround ENGcm09152 for i.MX35 */
if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
-   v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
-   USBPHYCTRL_OTGBASE_OFFSET));
+   unsigned int v;
+   struct resource *res = platform_get_resource
+   (pdev, IORESOURCE_MEM, 0);
+   void __iomem *phy_regs = ioremap(res->start +
+   MX35_USBPHYCTRL_OFFSET, 512);
+   if (!phy_regs) {
+   dev_err(&pdev->dev, "ioremap for phy address fails\n");
+   ret = -EINVAL;
+   goto ioremap_err;
+   }
+
+   v = readl(phy_regs + USBPHYCTRL_OTGBASE_OFFSET);
writel(v | USBPHYCTRL_EVDO,
-   MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
-   USBPHYCTRL_OTGBASE_OFFSET));
+   phy_regs + USBPHYCTRL_OTGBASE_OFFSET);
+
+   iounmap(phy_regs);
}
 
+
+ioremap_err:
/* ULPI transceivers don't need usbpll */
if (pdata->phy_mode == FSL_USB2_PHY_ULPI) {
clk_disable_unprepare(mxc_per_clk);
mxc_per_clk = NULL;
}
+
+   return ret;
 }
 
 void fsl_udc_clk_release(void)
diff --git a/drivers/usb/gadget/fsl_udc_core.c 
b/drivers/usb/gadget/fsl_udc_core.c
index 5fc1d72..667275c 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2543,7 +2543,9 @@ static int __init fsl_udc_probe(struct platform_device 
*pdev)
dr_controller_setup(udc_controller);
}
 
-   fsl_udc_clk_finalize(pdev);
+   ret = fsl_udc_clk_finalize(pdev);
+   if (ret)
+   goto err_free_irq;
 
/* Setup gadget structure */
udc_controller->gadget.ops = &fsl_gadget_ops;
diff --git a/drivers/usb/gadget/fsl_usb2_udc.h 
b/drivers/usb/gadget/fsl_usb2_udc.h
index f61a967..c6703bb 100644
--- a/drivers/usb/gadget/fsl_usb2_udc.h
+++ b/drivers/usb/gadget/fsl_usb2_udc.h
@@ -592,15 +592,16 @@ static inline struct ep_queue_head *get_qh_by_ep(struct 
fsl_ep *ep)
 struct platform_device;
 #ifdef CONFIG_ARCH_MXC
 int fsl_udc_clk_init(struct platform_device *pdev);
-void fsl_udc_clk_finalize(struct platform_device *pdev);
+int fsl_udc_clk_finalize(struct platform_device *pdev);
 void fsl_udc_clk_release(void);
 #else
 static inline int fsl_udc_clk_init(struct platform_device *pdev)
 {
return 0;
 }
-static inline void fsl_udc_clk_finalize(struct platform_device *pdev)
+static inline int fsl_udc_clk_finalize(struct platform_device *pdev)
 {
+   return 0;
 }
 static inline void fsl_udc_clk_release(void)
 {
-- 
1.7.0.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v6 0/3] Fix the Build error for fsl_mxc_udc.c

2013-01-17 Thread Peter Chen
Changes for v6:
- Only using imx-udc-mx27 and imx-udc-mx51 stands for
all kinds of i.mx udc
- Fix below build error for platform_device_id at fsl_udc_core.c
drivers/usb/gadget/fsl_usb2_udc: struct platform_device_id is 24 bytes.? The 
last of 5 is:
| 0x69 0x6d 0x78 0x2d 0x75 0x64 0x63 0x2d 0x6d 0x78 0x35 0x31 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00
+0x00 0x00 0x00
| FATAL: drivers/usb/gadget/fsl_usb2_udc: struct platform_device_id is not 
terminated with a NULL entry!
| make[1]: *** [__modpost] Error 1

Changes for v5:
- Using strcmp to get specific SoC
- Delete one cpu_is_mx35() as it has already pdata runtime check

Changes for v4:
- Using pdev's struct resource to do ioremap
- Add ioremap return value check

Changes for v3:
- Split the one big patch into three patches

Changes for v2:
- Add const for fsl_udc_devtype
- Do ioremap for phy address at fsl-mxc-udc

Peter Chen (3):
  usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
  usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap
  ARM: i.MX clock: Change the connection-id for fsl-usb2-udc

 arch/arm/mach-imx/clk-imx25.c |6 +-
 arch/arm/mach-imx/clk-imx27.c |6 +-
 arch/arm/mach-imx/clk-imx31.c |6 +-
 arch/arm/mach-imx/clk-imx35.c |6 +-
 arch/arm/mach-imx/clk-imx51-imx53.c   |6 +-
 arch/arm/mach-imx/devices/devices-common.h|1 +
 arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c |   15 ---
 drivers/usb/gadget/fsl_mxc_udc.c  |   40 +---
 drivers/usb/gadget/fsl_udc_core.c |   42 
 drivers/usb/gadget/fsl_usb2_udc.h |5 +-
 10 files changed, 78 insertions(+), 55 deletions(-)


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v6 2/3] usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap

2013-01-17 Thread Peter Chen
As mach/hardware.h is deleted, we can't visit platform code at driver.
It has no phy driver to combine with this controller, so it has to use
ioremap to map phy address as a workaround.

Signed-off-by: Peter Chen 
---
 drivers/usb/gadget/fsl_mxc_udc.c  |   30 +++---
 drivers/usb/gadget/fsl_udc_core.c |4 +++-
 drivers/usb/gadget/fsl_usb2_udc.h |5 +++--
 3 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index de851e5..d3bd7b0 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -23,7 +23,8 @@ static struct clk *mxc_per_clk;
 static struct clk *mxc_ipg_clk;
 
 /* workaround ENGcm09152 for i.MX35 */
-#define USBPHYCTRL_OTGBASE_OFFSET  0x608
+#define MX35_USBPHYCTRL_OFFSET 0x600
+#define USBPHYCTRL_OTGBASE_OFFSET  0x8
 #define USBPHYCTRL_EVDO(1 << 23)
 
 int fsl_udc_clk_init(struct platform_device *pdev)
@@ -77,25 +78,40 @@ eclkrate:
return ret;
 }
 
-void fsl_udc_clk_finalize(struct platform_device *pdev)
+int fsl_udc_clk_finalize(struct platform_device *pdev)
 {
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
-   unsigned int v;
+   int ret = 0;
 
/* workaround ENGcm09152 for i.MX35 */
if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
-   v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
-   USBPHYCTRL_OTGBASE_OFFSET));
+   unsigned int v;
+   struct resource *res = platform_get_resource
+   (pdev, IORESOURCE_MEM, 0);
+   void __iomem *phy_regs = ioremap(res->start +
+   MX35_USBPHYCTRL_OFFSET, 512);
+   if (!phy_regs) {
+   dev_err(&pdev->dev, "ioremap for phy address fails\n");
+   ret = -EINVAL;
+   goto ioremap_err;
+   }
+
+   v = readl(phy_regs + USBPHYCTRL_OTGBASE_OFFSET);
writel(v | USBPHYCTRL_EVDO,
-   MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
-   USBPHYCTRL_OTGBASE_OFFSET));
+   phy_regs + USBPHYCTRL_OTGBASE_OFFSET);
+
+   iounmap(phy_regs);
}
 
+
+ioremap_err:
/* ULPI transceivers don't need usbpll */
if (pdata->phy_mode == FSL_USB2_PHY_ULPI) {
clk_disable_unprepare(mxc_per_clk);
mxc_per_clk = NULL;
}
+
+   return ret;
 }
 
 void fsl_udc_clk_release(void)
diff --git a/drivers/usb/gadget/fsl_udc_core.c 
b/drivers/usb/gadget/fsl_udc_core.c
index 5fc1d72..667275c 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2543,7 +2543,9 @@ static int __init fsl_udc_probe(struct platform_device 
*pdev)
dr_controller_setup(udc_controller);
}
 
-   fsl_udc_clk_finalize(pdev);
+   ret = fsl_udc_clk_finalize(pdev);
+   if (ret)
+   goto err_free_irq;
 
/* Setup gadget structure */
udc_controller->gadget.ops = &fsl_gadget_ops;
diff --git a/drivers/usb/gadget/fsl_usb2_udc.h 
b/drivers/usb/gadget/fsl_usb2_udc.h
index f61a967..c6703bb 100644
--- a/drivers/usb/gadget/fsl_usb2_udc.h
+++ b/drivers/usb/gadget/fsl_usb2_udc.h
@@ -592,15 +592,16 @@ static inline struct ep_queue_head *get_qh_by_ep(struct 
fsl_ep *ep)
 struct platform_device;
 #ifdef CONFIG_ARCH_MXC
 int fsl_udc_clk_init(struct platform_device *pdev);
-void fsl_udc_clk_finalize(struct platform_device *pdev);
+int fsl_udc_clk_finalize(struct platform_device *pdev);
 void fsl_udc_clk_release(void);
 #else
 static inline int fsl_udc_clk_init(struct platform_device *pdev)
 {
return 0;
 }
-static inline void fsl_udc_clk_finalize(struct platform_device *pdev)
+static inline int fsl_udc_clk_finalize(struct platform_device *pdev)
 {
+   return 0;
 }
 static inline void fsl_udc_clk_release(void)
 {
-- 
1.7.0.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v6 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc

2013-01-17 Thread Peter Chen
As we use platform_device_id for fsl-usb2-udc driver, it needs to
change clk connection-id, or the related devm_clk_get will be failed.

Signed-off-by: Peter Chen 
---
 arch/arm/mach-imx/clk-imx25.c   |6 +++---
 arch/arm/mach-imx/clk-imx27.c   |6 +++---
 arch/arm/mach-imx/clk-imx31.c   |6 +++---
 arch/arm/mach-imx/clk-imx35.c   |6 +++---
 arch/arm/mach-imx/clk-imx51-imx53.c |6 +++---
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index b197aa7..2c570cd 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -254,9 +254,9 @@ int __init mx25_clocks_init(void)
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usbotg_ahb], "ahb", "mxc-ehci.2");
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2");
-   clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usbotg_ahb], "ahb", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
+   clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx27");
+   clk_register_clkdev(clk[usbotg_ahb], "ahb", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27");
clk_register_clkdev(clk[nfc_ipg_per], NULL, "imx25-nand.0");
/* i.mx25 has the i.mx35 type cspi */
clk_register_clkdev(clk[cspi1_ipg], NULL, "imx35-cspi.0");
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 4c1d1e4..1ffe3b5 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -236,9 +236,9 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx21-fb.0");
clk_register_clkdev(clk[csi_ahb_gate], "ahb", "imx27-camera.0");
clk_register_clkdev(clk[per4_gate], "per", "imx27-camera.0");
-   clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc");
+   clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_ipg_gate], "ipg", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_ahb_gate], "ahb", "imx-udc-mx27");
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.0");
clk_register_clkdev(clk[usb_ipg_gate], "ipg", "mxc-ehci.0");
clk_register_clkdev(clk[usb_ahb_gate], "ahb", "mxc-ehci.0");
diff --git a/arch/arm/mach-imx/clk-imx31.c b/arch/arm/mach-imx/clk-imx31.c
index 8be64e0..16ccbd4 100644
--- a/arch/arm/mach-imx/clk-imx31.c
+++ b/arch/arm/mach-imx/clk-imx31.c
@@ -139,9 +139,9 @@ int __init mx31_clocks_init(unsigned long fref)
clk_register_clkdev(clk[usb_div_post], "per", "mxc-ehci.2");
clk_register_clkdev(clk[usb_gate], "ahb", "mxc-ehci.2");
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
-   clk_register_clkdev(clk[usb_div_post], "per", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usb_gate], "ahb", "fsl-usb2-udc");
-   clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
+   clk_register_clkdev(clk[usb_div_post], "per", "imx-udc-mx27");
+   clk_register_clkdev(clk[usb_gate], "ahb", "imx-udc-mx27");
+   clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx27");
clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0");
/* i.mx31 has the i.mx21 type uart */
clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0");
diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c
index 66f3d65..f0727e8 100644
--- a/arch/arm/mach-imx/clk-imx35.c
+++ b/arch/arm/mach-imx/clk-imx35.c
@@ -251,9 +251,9 @@ int __init mx35_clocks_init()
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2");
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usbotg_gate], "ahb", "mxc-ehci.2");
-   clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
-   clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
-   clk_register_clkdev(clk[usbotg_gate], "ahb", "fsl-usb2-udc");
+   clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27");
+   clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx27");
+   clk_register_clkdev(clk[usbotg_gate], "ahb", "imx-udc-mx27");
clk_register_clkdev(clk[wdog_gate], NULL, "imx2-wdt.0");
clk_register_clkdev(clk[nfc_div], NULL, "imx25-nand.0");
clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0");
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c 
b/arch/arm/mach-imx/clk-imx51-imx53.c
index 579023f..fb7cb84 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -269,9 +269,9 @@ static void __init mx5_clocks_common_init(unsigned long 
rate_ckil,
clk_register_clkdev(clk[usboh3_per_gate], "per", "mxc-ehci.2");
clk_register_clkdev(clk[usboh3_gate], "ipg", "mx

[PATCH v6 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Peter Chen
As mach/hardware.h is deleted, we need to use platform_device_id to
differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
already used pdata to differentiate runtime

Meanwhile we update the platform code accordingly.

Signed-off-by: Peter Chen 
---
 arch/arm/mach-imx/devices/devices-common.h|1 +
 arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c |   15 
 drivers/usb/gadget/fsl_mxc_udc.c  |   24 +
 drivers/usb/gadget/fsl_udc_core.c |   38 -
 4 files changed, 41 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mach-imx/devices/devices-common.h 
b/arch/arm/mach-imx/devices/devices-common.h
index 6277baf..9bd5777 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -63,6 +63,7 @@ struct platform_device *__init imx_add_flexcan(
 
 #include 
 struct imx_fsl_usb2_udc_data {
+   const char *devid;
resource_size_t iobase;
resource_size_t irq;
 };
diff --git a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c 
b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
index 37e4439..3c06bd9 100644
--- a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
+++ b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
@@ -11,35 +11,36 @@
 #include "../hardware.h"
 #include "devices-common.h"
 
-#define imx_fsl_usb2_udc_data_entry_single(soc)
\
+#define imx_fsl_usb2_udc_data_entry_single(soc, _devid)
\
{   \
+   .devid = _devid,\
.iobase = soc ## _USB_OTG_BASE_ADDR,\
.irq = soc ## _INT_USB_OTG, \
}
 
 #ifdef CONFIG_SOC_IMX25
 const struct imx_fsl_usb2_udc_data imx25_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX25);
+   imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX25 */
 
 #ifdef CONFIG_SOC_IMX27
 const struct imx_fsl_usb2_udc_data imx27_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX27);
+   imx_fsl_usb2_udc_data_entry_single(MX27, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX27 */
 
 #ifdef CONFIG_SOC_IMX31
 const struct imx_fsl_usb2_udc_data imx31_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX31);
+   imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX31 */
 
 #ifdef CONFIG_SOC_IMX35
 const struct imx_fsl_usb2_udc_data imx35_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX35);
+   imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx27");
 #endif /* ifdef CONFIG_SOC_IMX35 */
 
 #ifdef CONFIG_SOC_IMX51
 const struct imx_fsl_usb2_udc_data imx51_fsl_usb2_udc_data __initconst =
-   imx_fsl_usb2_udc_data_entry_single(MX51);
+   imx_fsl_usb2_udc_data_entry_single(MX51, "imx-udc-mx51");
 #endif
 
 struct platform_device *__init imx_add_fsl_usb2_udc(
@@ -57,7 +58,7 @@ struct platform_device *__init imx_add_fsl_usb2_udc(
.flags = IORESOURCE_IRQ,
},
};
-   return imx_add_platform_device_dmamask("fsl-usb2-udc", -1,
+   return imx_add_platform_device_dmamask(data->devid, -1,
res, ARRAY_SIZE(res),
pdata, sizeof(*pdata), DMA_BIT_MASK(32));
 }
diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index 1b0f086..de851e5 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -18,8 +18,6 @@
 #include 
 #include 
 
-#include 
-
 static struct clk *mxc_ahb_clk;
 static struct clk *mxc_per_clk;
 static struct clk *mxc_ipg_clk;
@@ -59,7 +57,7 @@ int fsl_udc_clk_init(struct platform_device *pdev)
clk_prepare_enable(mxc_per_clk);
 
/* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
-   if (!cpu_is_mx51()) {
+   if (!strcmp(pdev->id_entry->name, "imx-udc-mx27")) {
freq = clk_get_rate(mxc_per_clk);
if (pdata->phy_mode != FSL_USB2_PHY_ULPI &&
(freq < 5000 || freq > 60001000)) {
@@ -82,17 +80,15 @@ eclkrate:
 void fsl_udc_clk_finalize(struct platform_device *pdev)
 {
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
-   if (cpu_is_mx35()) {
-   unsigned int v;
-
-   /* workaround ENGcm09152 for i.MX35 */
-   if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
-   v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
-   USBPHYCTRL_OTGBASE_OFFSET));
-   writel(v | USBPHYCTRL_EVDO,
-   MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
-   USBPHYCTRL_OTGBASE_OFFSET));
-  

[PATCH v6 0/3] *** SUBJECT HERE ***

2013-01-17 Thread Peter Chen
Changes for v6:
- Only using imx-udc-mx27 and imx-udc-mx51 stands for
all kinds of i.mx udc
- Fix below build error for platform_device_id at fsl_udc_core.c
drivers/usb/gadget/fsl_usb2_udc: struct platform_device_id is 24 bytes.? The 
last of 5 is:
| 0x69 0x6d 0x78 0x2d 0x75 0x64 0x63 0x2d 0x6d 0x78 0x35 0x31 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00
+0x00 0x00 0x00
| FATAL: drivers/usb/gadget/fsl_usb2_udc: struct platform_device_id is not 
terminated with a NULL entry!
| make[1]: *** [__modpost] Error 1

Changes for v5:
- Using strcmp to get specific SoC
- Delete one cpu_is_mx35() as it has already pdata runtime check

Changes for v4:
- Using pdev's struct resource to do ioremap
- Add ioremap return value check

Changes for v3:
- Split the one big patch into three patches

Changes for v2:
- Add const for fsl_udc_devtype
- Do ioremap for phy address at fsl-mxc-udc

Peter Chen (3):
  usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
  usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap
  ARM: i.MX clock: Change the connection-id for fsl-usb2-udc

 arch/arm/mach-imx/clk-imx25.c |6 +-
 arch/arm/mach-imx/clk-imx27.c |6 +-
 arch/arm/mach-imx/clk-imx31.c |6 +-
 arch/arm/mach-imx/clk-imx35.c |6 +-
 arch/arm/mach-imx/clk-imx51-imx53.c   |6 +-
 arch/arm/mach-imx/devices/devices-common.h|1 +
 arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c |   15 ---
 drivers/usb/gadget/fsl_mxc_udc.c  |   40 +---
 drivers/usb/gadget/fsl_udc_core.c |   42 
 drivers/usb/gadget/fsl_usb2_udc.h |5 +-
 10 files changed, 78 insertions(+), 55 deletions(-)


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v5 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Felipe Balbi
Hi,

On Thu, Jan 17, 2013 at 05:28:30PM +0800, Peter Chen wrote:



> > > > From what I understand balbi's comment, he dislikes this full list of
> > > > device id.  Instead, he prefers to something like below.
> > > > 
> > > > static const struct platform_device_id fsl_udc_devtype[] = {
> > > > {
> > > > .name = "imx-udc-mx27",
> > > > }, {
> > > > .name = "imx-udc-mx51",
> > > > }
> > > > };
> > > > 
> > > > It basically tells that we are handling two type of devices here, one
> > > > is imx-udc-mx27 type and the other is imx-udc-mx51 type, with mx25/31/35
> > > > completely compatible with mx27 type.  We choose mx27 instead of mx25
> > > > to define the type because mx27 Si came out earlier than mx25.  That
> > > > said, we generally choose the earlies SoC name to define a particular
> > > > version of IP block, since hardware version is mostly unavailable or
> > > > unreliable.
> > > > 
> > > > But that also means in platform code which create the platform_device,
> > > > you will need to use name "imx-udc-mx27" for even mx25/31/35.
> > > > 
> > > > imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx27");
> > > > imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx27");
> > > > imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx27");
> > > > 
> > > > Considering this is a piece of code we will not use for any new
> > > > hardware, I'm fine with either way.
> > > > 
> > > > So, balbi, it's all your call to accept the series as it is or ask for
> > > > another iteration.
> > 
> > right :-)
> > 
> > > Thanks Shawn. Let's see Felipe's comment, nevertheless, I will send v6 
> > > patch
> > > due to a compile error at mx25
> > 
> > Shawn is right.
> 
> In fact, this driver is just the temp solution, we will use chipidea
> in future, so just take all i.mx usb as two kinds of ip are ok.
> 
> Do you want me to change like Shawn said, or current version is ok?

yes, please resend with changes.

-- 
balbi


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v5 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Peter Chen
On Thu, Jan 17, 2013 at 11:14:22AM +0200, Felipe Balbi wrote:
> On Wed, Jan 16, 2013 at 09:48:25AM +0800, Peter Chen wrote:
> > On Tue, Jan 15, 2013 at 10:03:46PM +0800, Shawn Guo wrote:
> > > On Tue, Jan 15, 2013 at 10:29:33AM +0800, Peter Chen wrote:
> > > > As mach/hardware.h is deleted, we need to use platform_device_id to
> > > > differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
> > > > already used pdata to differentiate runtime
> > > > 
> > > > Meanwhile we update the platform code accordingly.
> > > > 
> > > > Signed-off-by: Peter Chen 
> > > > ---
> > > >  arch/arm/mach-imx/devices/devices-common.h|1 +
> > > >  arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c |   15 ---
> > > >  drivers/usb/gadget/fsl_mxc_udc.c  |   24 +---
> > > >  drivers/usb/gadget/fsl_udc_core.c |   42 
> > > > +
> > > >  4 files changed, 45 insertions(+), 37 deletions(-)
> > > 
> > > Since we are splitting the original patch anyway, it's a bit strange
> > > to me that you are mixing arch/arm/mach-imx and drivers/usb/gadget
> > > in this patch.  I'm fine with it, since I assume all the patches to
> > > go via USB tree anyway.
> > > 
> > > > 
> > > > diff --git a/arch/arm/mach-imx/devices/devices-common.h 
> > > > b/arch/arm/mach-imx/devices/devices-common.h
> > > > index 6277baf..9bd5777 100644
> > > > --- a/arch/arm/mach-imx/devices/devices-common.h
> > > > +++ b/arch/arm/mach-imx/devices/devices-common.h
> > > > @@ -63,6 +63,7 @@ struct platform_device *__init imx_add_flexcan(
> > > >  
> > > >  #include 
> > > >  struct imx_fsl_usb2_udc_data {
> > > > +   const char *devid;
> > > > resource_size_t iobase;
> > > > resource_size_t irq;
> > > >  };
> > > > diff --git a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c 
> > > > b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> > > > index 37e4439..fb527c7 100644
> > > > --- a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> > > > +++ b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> > > > @@ -11,35 +11,36 @@
> > > >  #include "../hardware.h"
> > > >  #include "devices-common.h"
> > > >  
> > > > -#define imx_fsl_usb2_udc_data_entry_single(soc)
> > > > \
> > > > +#define imx_fsl_usb2_udc_data_entry_single(soc, _devid)
> > > > \
> > > > {   
> > > > \
> > > > +   .devid = _devid,
> > > > \
> > > > .iobase = soc ## _USB_OTG_BASE_ADDR,
> > > > \
> > > > .irq = soc ## _INT_USB_OTG, 
> > > > \
> > > > }
> > > >  
> > > >  #ifdef CONFIG_SOC_IMX25
> > > >  const struct imx_fsl_usb2_udc_data imx25_fsl_usb2_udc_data __initconst 
> > > > =
> > > > -   imx_fsl_usb2_udc_data_entry_single(MX25);
> > > > +   imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx25");
> > > >  #endif /* ifdef CONFIG_SOC_IMX25 */
> > > >  
> > > >  #ifdef CONFIG_SOC_IMX27
> > > >  const struct imx_fsl_usb2_udc_data imx27_fsl_usb2_udc_data __initconst 
> > > > =
> > > > -   imx_fsl_usb2_udc_data_entry_single(MX27);
> > > > +   imx_fsl_usb2_udc_data_entry_single(MX27, "imx-udc-mx27");
> > > >  #endif /* ifdef CONFIG_SOC_IMX27 */
> > > >  
> > > >  #ifdef CONFIG_SOC_IMX31
> > > >  const struct imx_fsl_usb2_udc_data imx31_fsl_usb2_udc_data __initconst 
> > > > =
> > > > -   imx_fsl_usb2_udc_data_entry_single(MX31);
> > > > +   imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx31");
> > > >  #endif /* ifdef CONFIG_SOC_IMX31 */
> > > >  
> > > >  #ifdef CONFIG_SOC_IMX35
> > > >  const struct imx_fsl_usb2_udc_data imx35_fsl_usb2_udc_data __initconst 
> > > > =
> > > > -   imx_fsl_usb2_udc_data_entry_single(MX35);
> > > > +   imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx35");
> > > >  #endif /* ifdef CONFIG_SOC_IMX35 */
> > > >  
> > > >  #ifdef CONFIG_SOC_IMX51
> > > >  const struct imx_fsl_usb2_udc_data imx51_fsl_usb2_udc_data __initconst 
> > > > =
> > > > -   imx_fsl_usb2_udc_data_entry_single(MX51);
> > > > +   imx_fsl_usb2_udc_data_entry_single(MX51, "imx-udc-mx51");
> > > >  #endif
> > > >  
> > > >  struct platform_device *__init imx_add_fsl_usb2_udc(
> > > > @@ -57,7 +58,7 @@ struct platform_device *__init imx_add_fsl_usb2_udc(
> > > > .flags = IORESOURCE_IRQ,
> > > > },
> > > > };
> > > > -   return imx_add_platform_device_dmamask("fsl-usb2-udc", -1,
> > > > +   return imx_add_platform_device_dmamask(data->devid, -1,
> > > > res, ARRAY_SIZE(res),
> > > > pdata, sizeof(*pdata), DMA_BIT_MASK(32));
> > > >  }
> > > 
> > > 
> > > 
> > > > +static const struct platform_device_id fsl_udc_devtype[] = {
> > > > +   {
> > > > +   .name = "imx-udc-mx25",
> > > > +   }, {

Re: [PATCH v5 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

2013-01-17 Thread Felipe Balbi
On Wed, Jan 16, 2013 at 09:48:25AM +0800, Peter Chen wrote:
> On Tue, Jan 15, 2013 at 10:03:46PM +0800, Shawn Guo wrote:
> > On Tue, Jan 15, 2013 at 10:29:33AM +0800, Peter Chen wrote:
> > > As mach/hardware.h is deleted, we need to use platform_device_id to
> > > differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
> > > already used pdata to differentiate runtime
> > > 
> > > Meanwhile we update the platform code accordingly.
> > > 
> > > Signed-off-by: Peter Chen 
> > > ---
> > >  arch/arm/mach-imx/devices/devices-common.h|1 +
> > >  arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c |   15 ---
> > >  drivers/usb/gadget/fsl_mxc_udc.c  |   24 +---
> > >  drivers/usb/gadget/fsl_udc_core.c |   42 
> > > +
> > >  4 files changed, 45 insertions(+), 37 deletions(-)
> > 
> > Since we are splitting the original patch anyway, it's a bit strange
> > to me that you are mixing arch/arm/mach-imx and drivers/usb/gadget
> > in this patch.  I'm fine with it, since I assume all the patches to
> > go via USB tree anyway.
> > 
> > > 
> > > diff --git a/arch/arm/mach-imx/devices/devices-common.h 
> > > b/arch/arm/mach-imx/devices/devices-common.h
> > > index 6277baf..9bd5777 100644
> > > --- a/arch/arm/mach-imx/devices/devices-common.h
> > > +++ b/arch/arm/mach-imx/devices/devices-common.h
> > > @@ -63,6 +63,7 @@ struct platform_device *__init imx_add_flexcan(
> > >  
> > >  #include 
> > >  struct imx_fsl_usb2_udc_data {
> > > + const char *devid;
> > >   resource_size_t iobase;
> > >   resource_size_t irq;
> > >  };
> > > diff --git a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c 
> > > b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> > > index 37e4439..fb527c7 100644
> > > --- a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> > > +++ b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> > > @@ -11,35 +11,36 @@
> > >  #include "../hardware.h"
> > >  #include "devices-common.h"
> > >  
> > > -#define imx_fsl_usb2_udc_data_entry_single(soc)  
> > > \
> > > +#define imx_fsl_usb2_udc_data_entry_single(soc, _devid)  
> > > \
> > >   {   \
> > > + .devid = _devid,\
> > >   .iobase = soc ## _USB_OTG_BASE_ADDR,\
> > >   .irq = soc ## _INT_USB_OTG, \
> > >   }
> > >  
> > >  #ifdef CONFIG_SOC_IMX25
> > >  const struct imx_fsl_usb2_udc_data imx25_fsl_usb2_udc_data __initconst =
> > > - imx_fsl_usb2_udc_data_entry_single(MX25);
> > > + imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx25");
> > >  #endif /* ifdef CONFIG_SOC_IMX25 */
> > >  
> > >  #ifdef CONFIG_SOC_IMX27
> > >  const struct imx_fsl_usb2_udc_data imx27_fsl_usb2_udc_data __initconst =
> > > - imx_fsl_usb2_udc_data_entry_single(MX27);
> > > + imx_fsl_usb2_udc_data_entry_single(MX27, "imx-udc-mx27");
> > >  #endif /* ifdef CONFIG_SOC_IMX27 */
> > >  
> > >  #ifdef CONFIG_SOC_IMX31
> > >  const struct imx_fsl_usb2_udc_data imx31_fsl_usb2_udc_data __initconst =
> > > - imx_fsl_usb2_udc_data_entry_single(MX31);
> > > + imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx31");
> > >  #endif /* ifdef CONFIG_SOC_IMX31 */
> > >  
> > >  #ifdef CONFIG_SOC_IMX35
> > >  const struct imx_fsl_usb2_udc_data imx35_fsl_usb2_udc_data __initconst =
> > > - imx_fsl_usb2_udc_data_entry_single(MX35);
> > > + imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx35");
> > >  #endif /* ifdef CONFIG_SOC_IMX35 */
> > >  
> > >  #ifdef CONFIG_SOC_IMX51
> > >  const struct imx_fsl_usb2_udc_data imx51_fsl_usb2_udc_data __initconst =
> > > - imx_fsl_usb2_udc_data_entry_single(MX51);
> > > + imx_fsl_usb2_udc_data_entry_single(MX51, "imx-udc-mx51");
> > >  #endif
> > >  
> > >  struct platform_device *__init imx_add_fsl_usb2_udc(
> > > @@ -57,7 +58,7 @@ struct platform_device *__init imx_add_fsl_usb2_udc(
> > >   .flags = IORESOURCE_IRQ,
> > >   },
> > >   };
> > > - return imx_add_platform_device_dmamask("fsl-usb2-udc", -1,
> > > + return imx_add_platform_device_dmamask(data->devid, -1,
> > >   res, ARRAY_SIZE(res),
> > >   pdata, sizeof(*pdata), DMA_BIT_MASK(32));
> > >  }
> > 
> > 
> > 
> > > +static const struct platform_device_id fsl_udc_devtype[] = {
> > > + {
> > > + .name = "imx-udc-mx25",
> > > + }, {
> > > + .name = "imx-udc-mx27",
> > > + }, {
> > > + .name = "imx-udc-mx31",
> > > + }, {
> > > + .name = "imx-udc-mx35",
> > > + }, {
> > > + .name = "imx-udc-mx51",
> > > + }
> > > +};
> > 
> > From what I understand balbi's comment, he dislikes this full list of
> > device id.  Instead, he prefers to something like below.
> > 
> > static const struct platform_device_id fsl_udc_devtype[] = {
> > {
> > .name = "imx-udc-mx27",
> > }, {
> > .name = "imx-udc-mx5