Re: [PATCH 1/3] powerpc/mpc85xx: Add FMan clock nodes
On Tue, 2015-03-24 at 03:26 -0500, Emil Medve wrote:
> Hello Scott,
>
>
> On 03/23/2015 06:30 PM, Scott Wood wrote:
> > On Thu, 2015-02-26 at 09:26 -0600, Emil Medve wrote:
> >> From: Igal Liberman
> >>
> >> Signed-off-by: Igal Liberman
> >> ---
> >> arch/powerpc/boot/dts/fsl/b4si-post.dtsi| 11 +++
> >> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 8
> >> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 8
> >> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 16
> >> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 13 +
> >> arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 26
> >> ++
> >> arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 8
> >> arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 11 +++
> >> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 20
> >> 9 files changed, 121 insertions(+)
> >>
> >> diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> >> b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> >> index f8c325e..38621ef 100644
> >> --- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> >> +++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> >> @@ -395,6 +395,17 @@
> >>reg = <0xe 0xe00>;
> >>fsl,has-rstcr;
> >>fsl,liodn-bits = <12>;
> >> +
> >> + fm0clk: fm0-clk-mux {
> >> + #clock-cells = <0>;
> >> + compatible = "fsl,fman-clk-mux";
> >> + clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>, <&pll0 3>,
> >> + <&platform_pll 0>, <&pll1 1>, <&pll1 2>;
> >> + clock-names = "pll0", "pll0-div2", "pll0-div3",
> >> +"pll0-div4", "platform-pll", "pll1-div2",
> >> +"pll1-div3";
> >> + clock-output-names = "fm0-clk";
> >> + };
> >
> > Where's the binding for fsl,fman-clk-mux?
> >
>
> Igal will follow-up with the binding document
Igal, ping?
I need a binding before I can apply the dts patch.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/4] powerpc/cache: add cache flush operation for various e500
On Thu, Mar 26, 2015 at 06:18:12PM +0800, chenhui zhao wrote:
> Various e500 core have different cache architecture, so they
> need different cache flush operations. Therefore, add a callback
> function cpu_flush_caches to the struct cpu_spec. The cache flush
> operation for the specific kind of e500 is selected at init time.
> The callback function will flush all caches inside the current cpu.
>
> Signed-off-by: Chenhui Zhao
> ---
> arch/powerpc/include/asm/cacheflush.h | 2 -
> arch/powerpc/include/asm/cputable.h | 11 +++
> arch/powerpc/kernel/asm-offsets.c | 3 +
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 114
> +-
> arch/powerpc/kernel/cputable.c| 4 ++
> arch/powerpc/kernel/head_fsl_booke.S | 74 ---
> arch/powerpc/platforms/85xx/smp.c | 3 +-
> 7 files changed, 133 insertions(+), 78 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cacheflush.h
> b/arch/powerpc/include/asm/cacheflush.h
> index 30b35ff..729fde4 100644
> --- a/arch/powerpc/include/asm/cacheflush.h
> +++ b/arch/powerpc/include/asm/cacheflush.h
> @@ -30,8 +30,6 @@ extern void flush_dcache_page(struct page *page);
> #define flush_dcache_mmap_lock(mapping) do { } while (0)
> #define flush_dcache_mmap_unlock(mapping)do { } while (0)
>
> -extern void __flush_disable_L1(void);
> -
> extern void flush_icache_range(unsigned long, unsigned long);
> extern void flush_icache_user_range(struct vm_area_struct *vma,
> struct page *page, unsigned long addr,
> diff --git a/arch/powerpc/include/asm/cputable.h
> b/arch/powerpc/include/asm/cputable.h
> index 5cf5a6d..c776efe4 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -43,6 +43,13 @@ extern int machine_check_e500(struct pt_regs *regs);
> extern int machine_check_e200(struct pt_regs *regs);
> extern int machine_check_47x(struct pt_regs *regs);
>
> +#if defined(CONFIG_E500) || defined(CONFIG_PPC_E500MC)
> +extern void __flush_caches_e500v2(void);
> +extern void __flush_caches_e500mc(void);
> +extern void __flush_caches_e5500(void);
> +extern void __flush_caches_e6500(void);
> +#endif
Why the leading underscores?
> /* NOTE WELL: Update identify_cpu() if fields are added or removed! */
> struct cpu_spec {
> /* CPU is matched via (PVR & pvr_mask) == pvr_value */
> @@ -59,6 +66,10 @@ struct cpu_spec {
> unsigned inticache_bsize;
> unsigned intdcache_bsize;
>
> +#if defined(CONFIG_E500) || defined(CONFIG_PPC_E500MC)
CONFIG_PPC_E500MC implies CONFIG_E500. Why do we need this ifdef?
> + /* flush caches inside the current cpu */
> + void (*cpu_flush_caches)(void);
> +#endif
It seems you literally mean "in the cpu" -- If it's a threaded core, then
by "cpu" do you mean "thread" (like we usually do) and thus no caches get
flushed (ignore the fact that it's moot on e6500 -- this is an interface
and needs to be clear).
Also, no-oping L1 flush on e6500 is not compliant with the claim that
you're flushing the cache. You're relying on an unstated assumption that
you'll invalidate that cache later instead.
If you want to make this "flush whatever needs to be flushed for
suspend/hotplug", call it that.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [2/4] powerpc/rcpm: add RCPM driver
On Thu, Mar 26, 2015 at 06:18:13PM +0800, chenhui zhao wrote:
> There is a RCPM (Run Control/Power Management) in Freescale QorIQ
> series processors. The device performs tasks associated with device
> run control and power management.
>
> The driver implements some features: mask/unmask irq, enter/exit low
> power states, freeze time base, etc.
>
> Signed-off-by: Chenhui Zhao
> ---
> Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 23 ++
> arch/powerpc/include/asm/fsl_guts.h| 105 ++
> arch/powerpc/include/asm/fsl_pm.h | 49 +++
> arch/powerpc/platforms/85xx/Kconfig| 1 +
> arch/powerpc/sysdev/Kconfig| 5 +
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/fsl_rcpm.c | 353
> +
> 7 files changed, 537 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> create mode 100644 arch/powerpc/include/asm/fsl_pm.h
> create mode 100644 arch/powerpc/sysdev/fsl_rcpm.c
>
> diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> new file mode 100644
> index 000..8c21b6c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> @@ -0,0 +1,23 @@
> +* Run Control and Power Management
> +
> +The RCPM performs all device-level tasks associated with device run control
> +and power management.
> +
> +Required properites:
> + - reg : Offset and length of the register set of RCPM block.
> + - compatible : Specifies the compatibility list for the RCPM. The type
> +should be string, such as "fsl,qoriq-rcpm-1.0", "fsl,qoriq-rcpm-2.0".
> +
> +Example:
> +The RCPM node for T4240:
> + rcpm: global-utilities@e2000 {
> + compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
> + reg = <0xe2000 0x1000>;
> + };
> +
> +The RCPM node for P4080:
> + rcpm: global-utilities@e2000 {
> + compatible = "fsl,qoriq-rcpm-1.0";
> + reg = <0xe2000 0x1000>;
> + #sleep-cells = <1>;
> + };
Where is #sleep-cells documented? It's copy-and-paste from something
that was never finished from many years ago.
> diff --git a/arch/powerpc/include/asm/fsl_pm.h
> b/arch/powerpc/include/asm/fsl_pm.h
> new file mode 100644
> index 000..bbe6089
> --- /dev/null
> +++ b/arch/powerpc/include/asm/fsl_pm.h
> @@ -0,0 +1,49 @@
> +/*
> + * Support Power Management
> + *
> + * Copyright 2014-2015 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +#ifndef __PPC_FSL_PM_H
> +#define __PPC_FSL_PM_H
> +#ifdef __KERNEL__
Put a space after #ifdef, not a tab.
> +#define E500_PM_PH10 1
> +#define E500_PM_PH15 2
> +#define E500_PM_PH20 3
> +#define E500_PM_PH30 4
> +#define E500_PM_DOZE E500_PM_PH10
> +#define E500_PM_NAP E500_PM_PH15
> +
> +#define PLAT_PM_SLEEP20
> +#define PLAT_PM_LPM2030
> +
> +#define FSL_PM_SLEEP (1 << 0)
> +#define FSL_PM_DEEP_SLEEP(1 << 1)
> +
> +struct fsl_pm_ops {
> + /* mask pending interrupts to the RCPM from MPIC */
> + void (*irq_mask)(int cpu);
> + /* unmask pending interrupts to the RCPM from MPIC */
> + void (*irq_unmask)(int cpu);
> + /* place the CPU in the specified state */
> + void (*cpu_enter_state)(int cpu, int state);
> + /* exit the CPU from the specified state */
> + void (*cpu_exit_state)(int cpu, int state);
> + /* place the platform in the sleep state */
> + int (*plat_enter_sleep)(void);
> + /* freeze the time base */
> + void (*freeze_time_base)(int freeze);
> + /* keep the power of IP blocks during sleep/deep sleep */
> + void (*set_ip_power)(int enable, u32 *mask);
> + /* get platform supported power management modes */
> + unsigned int (*get_pm_modes)(void);
> +};
Drop the comments that are basically just a restatement of the function
name. Where there are comments, it'd be easier to read with a blank line
between a function and the next comment.
s/int enable/bool enable/
s/int freeze/bool freeze/
> +#endif /* __KERNEL__ */
> +#endif /* __PPC_FSL_PM_H */
Please be consistent with whitespace.
> + default:
> + pr_err("%s: Unknown cpu PM state (%d)\n", __func__, state);
WARN?
> +static int rcpm_v2_plat_enter_state(int state)
> +{
> + u32 *pmcsr_reg = &rcpm_v2_regs->powmgtcsr;
> + int ret = 0;
> + int result;
> +
> + switch (state) {
> + case PLAT_PM_LPM20:
> + /* clear previous LPM20 status */
> + setbits32(pmcsr_reg, RCPM_POWMGTCSR_P_LPM20_ST);
How would the bit be set when you enter here, given that you wait for it
to clear when l
Re: [3/4] powerpc: support CPU hotplug for e500mc, e5500 and e6500
On Thu, Mar 26, 2015 at 06:18:14PM +0800, chenhui zhao wrote:
> Implemented CPU hotplug on e500mc, e5500 and e6500, and support
> multiple threads mode and 64-bits mode.
>
> For e6500 with two threads, if one thread is online, it can
> enable/disable the other thread in the same core. If two threads of
> one core are offline, the core will enter the PH20 state (a low power
> state). When the core is up again, Thread0 is up first, and it will be
> bound with the present booting cpu. This way, all CPUs can hotplug
> separately.
>
> Signed-off-by: Chenhui Zhao
> ---
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/include/asm/fsl_pm.h | 4 +
> arch/powerpc/include/asm/smp.h| 2 +
> arch/powerpc/kernel/head_64.S | 20 +++--
> arch/powerpc/kernel/smp.c | 5 ++
> arch/powerpc/platforms/85xx/smp.c | 182
> +-
> arch/powerpc/sysdev/fsl_rcpm.c| 56
> 7 files changed, 220 insertions(+), 51 deletions(-)
Please factor out changes to generic code (including but not limited to
cur_boot_cpu and PIR handling) into separate patches with clear
explanations.
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 22b0940..9846c83 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -380,7 +380,7 @@ config SWIOTLB
> config HOTPLUG_CPU
> bool "Support for enabling/disabling CPUs"
> depends on SMP && (PPC_PSERIES || \
> - PPC_PMAC || PPC_POWERNV || (PPC_85xx && !PPC_E500MC))
> + PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE)
> ---help---
> Say Y here to be able to disable and re-enable individual
> CPUs at runtime on SMP machines.
> diff --git a/arch/powerpc/include/asm/fsl_pm.h
> b/arch/powerpc/include/asm/fsl_pm.h
> index bbe6089..579f495 100644
> --- a/arch/powerpc/include/asm/fsl_pm.h
> +++ b/arch/powerpc/include/asm/fsl_pm.h
> @@ -34,6 +34,10 @@ struct fsl_pm_ops {
> void (*cpu_enter_state)(int cpu, int state);
> /* exit the CPU from the specified state */
> void (*cpu_exit_state)(int cpu, int state);
> + /* cpu up */
> + void (*cpu_up)(int cpu);
Again, this sort of comment is useless. Tell us what "cpu up" *does*,
when it should be called, etc.
> @@ -189,16 +193,14 @@ _GLOBAL(fsl_secondary_thread_init)
> isync
>
> /*
> - * Fix PIR to match the linear numbering in the device tree.
> - *
> - * On e6500, the reset value of PIR uses the low three bits for
> - * the thread within a core, and the upper bits for the core
> - * number. There are two threads per core, so shift everything
> - * but the low bit right by two bits so that the cpu numbering is
> - * continuous.
Why are you getting rid of this? If it's to avoid doing it twice on the
same thread, in my work-in-progress kexec patches I instead check to see
whether BUCSR has already been set up -- if it has, I assume we've
already been here.
> + * The current thread has been in 64-bit mode,
> + * see the value of TMRN_IMSR.
I don't see what the relevance of this comment is here.
> + * compute the address of __cur_boot_cpu
>*/
> - mfspr r3, SPRN_PIR
> - rlwimi r3, r3, 30, 2, 30
> + bl 10f
> +10: mflrr22
> + addir22,r22,(__cur_boot_cpu - 10b)
> + lwz r3,0(r22)
Please save non-volatile registers for things that need to stick around
for a while.
> mtspr SPRN_PIR, r3
If __cur_boot_cpu is meant to be the PIR of the currently booting CPU,
it's a misleading. It looks like it's supposed to have something to do
with the boot cpu (not "booting").
Also please don't put leading underscores on symbols just because the
adjacent symbols have them.
> -#ifdef CONFIG_HOTPLUG_CPU
> +#ifdef CONFIG_PPC_E500MC
> +static void qoriq_cpu_wait_die(void)
> +{
> + unsigned int cpu = smp_processor_id();
> +
> + hard_irq_disable();
> + /* mask all irqs to prevent cpu wakeup */
> + qoriq_pm_ops->irq_mask(cpu);
> + idle_task_exit();
> +
> + mtspr(SPRN_TCR, 0);
> + mtspr(SPRN_TSR, mfspr(SPRN_TSR));
> +
> + cur_cpu_spec->cpu_flush_caches();
> +
> + generic_set_cpu_dead(cpu);
> + smp_mb();
Comment memory barriers, as checkpatch says.
> + while (1)
> + ;
Indent the ;
> @@ -174,17 +232,29 @@ static inline u32 read_spin_table_addr_l(void
> *spin_table)
> static void wake_hw_thread(void *info)
> {
> void fsl_secondary_thread_init(void);
> - unsigned long imsr1, inia1;
> + unsigned long imsr, inia;
> int nr = *(const int *)info;
> -
> - imsr1 = MSR_KERNEL;
> - inia1 = *(unsigned long *)fsl_secondary_thread_init;
> -
> - mttmr(TMRN_IMSR1, imsr1);
> - mttmr(TMRN_INIA1, inia1);
> - mtspr(SPRN_TENS, TEN_THREAD(1));
> + int hw_cpu = get_hard_smp_processor_id(nr);
> + int thread_idx = cpu_thread_in_core(hw_cpu);
> +
> + __cur_boot_cpu = (u32)hw_cpu;
> + imsr = MSR_KERNEL;
> + inia = *(un
Re: [4/4] powerpc/85xx: support sleep feature on QorIQ SoCs with RCPM
On Thu, Mar 26, 2015 at 06:18:15PM +0800, chenhui zhao wrote:
> In sleep mode, the clocks of e500 cores and unused IP blocks is
> turned off. The IP blocks which are allowed to wake up the processor
> are still running.
>
> The sleep mode is equal to the Standby state in Linux. Use the
> command to enter sleep mode:
> echo standby > /sys/power/state
>
> Signed-off-by: Chenhui Zhao
> ---
> arch/powerpc/Kconfig | 3 +-
> arch/powerpc/platforms/85xx/Kconfig| 5 +++
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/qoriq_pm.c | 59
> ++
> arch/powerpc/platforms/86xx/Kconfig| 1 +
> 5 files changed, 67 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/platforms/85xx/qoriq_pm.c
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 9846c83..162eb53 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -233,7 +233,7 @@ config ARCH_HIBERNATION_POSSIBLE
> config ARCH_SUSPEND_POSSIBLE
> def_bool y
> depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
> -(PPC_85xx && !PPC_E500MC) || PPC_86xx || PPC_PSERIES \
> +FSL_SOC_BOOKE || PPC_86xx || PPC_PSERIES \
> || 44x || 40x
>
> config PPC_DCR_NATIVE
> @@ -747,7 +747,6 @@ config FSL_PCI
>
> config FSL_PMC
> bool
> - default y
> depends on SUSPEND && (PPC_85xx || PPC_86xx)
Get rid of this depends line if you're going to use select instead.
> +static int qoriq_suspend_valid(suspend_state_t state)
> +{
> + unsigned int pm_modes;
> +
> + pm_modes = qoriq_pm_ops->get_pm_modes();
> +
> + if ((state == PM_SUSPEND_STANDBY) && (pm_modes & FSL_PM_SLEEP))
> + return 1;
Unnecessary parentheses around ==
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2,2/2] powerpc32: add support for csum_add()
On Tue, Feb 03, 2015 at 12:39:27PM +0100, LEROY Christophe wrote:
> The C version of csum_add() as defined in include/net/checksum.h gives the
> following assembly:
>0: 7c 04 1a 14 add r0,r4,r3
>4: 7c 64 00 10 subfc r3,r4,r0
>8: 7c 63 19 10 subfe r3,r3,r3
>c: 7c 63 00 50 subfr3,r3,r0
>
> include/net/checksum.h also offers the possibility to define an arch specific
> function.
> This patch provides a ppc32 specific csum_add() inline function.
>
> Signed-off-by: Christophe Leroy
> ---
> v2: changed constraints on the __asm__
>
> arch/powerpc/include/asm/checksum.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/checksum.h
> b/arch/powerpc/include/asm/checksum.h
> index cfe806a..1e48cc7 100644
> --- a/arch/powerpc/include/asm/checksum.h
> +++ b/arch/powerpc/include/asm/checksum.h
> @@ -141,6 +141,18 @@ static inline __sum16 csum_tcpudp_magic(__be32 saddr,
> __be32 daddr,
> {
> return csum_fold(csum_tcpudp_nofold(saddr, daddr, len, proto, sum));
> }
> +
> +#define HAVE_ARCH_CSUM_ADD
> +static inline __wsum csum_add(__wsum csum, __wsum addend)
> +{
> +__asm__("\n\
s/__asm__/asm/
Use tabs to indent
> + addc %0,%0,%1 \n\
> + addze %0,%0 \n\
Use ; to separate asm statements instead of using \n
Use string concatenation instead of \
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/4] powerpc/fsl-booke: Add device tree support for T1024/T1023 SoC
On Mon, 2015-03-30 at 22:32 -0500, Liu Shengzhou-B36685 wrote:
> > > > There are other differences between t1023 an t1024. Where do you
> > > > describe t1024's QE? Where do you describe the DDR and IFC differences?
> > > > can they be detected at runtime? t1024 supports deep sleep, but
> > > > t1023 doesn't -- yet you label both chips as having t1024 rcpm.
> > > >
> > > As QE IP block has not been upstream yet,
> > Huh?
> > arch/powerpc/sysdev/qe_lib/
>
> arch/powerpc/boot/dts/fsl/qoriq-tdm1.0.dtsi has not been upstream by TDM
> owner.
> Ok, I will first send qoriq-tdm1.0.dtsi upstream in order to include QE in
> t1024 dts.
Thanks, but make sure there's also a binding for it.
> > > DDR and IFC differences are in u-boot, not in dts.
> > The differences are in hardware, which is what the dts is supposed to
> > describe.
>
> Theoretically I think so, but not all hardware details must be described in
> dts
No, but all hardware should be properly identified.
> as current IP driver doesn't take care of it from dts.
The device tree describes the hardware, not the driver.
> If so, IP owners will have to update drivers, for now let's keep as it's.
Please don't use the phrase "IP owner" in upstream discussions. Besides
being a bad name for "maintainer", SDK maintainership isn't relevant
here.
> > > Both t1023 and t1024 support sleep, so label both chips as having t1024
> > > rcpm.
> >
> > That's not how it works.
> >
> > > Only t1024 has deep sleep, the difference is identified in *.c not in dts
> > > (confirmed with deep sleep owner).
> >
> > Even if the C code chooses to use SVR to identify the difference (why?),
> > that doesn't mean it's OK for the device tree to contain wrong information.
>
> Where is the wrong information?
>
> rcpm: global-utilities@e2000 {
> compatible = "fsl,t1024-rcpm", "fsl,qoriq-rcpm-2.0";
> reg = <0xe2000 0x1000>;
> };
>
> sdhc@114000 {
> compatible = "fsl,t1024-esdhc", "fsl,esdhc";
> fsl,iommu-parent = <&pamu0>;
> fsl,liodn-reg = <&guts 0x530>; /* eSDHCLIODNR */
> sdhci,auto-cmd12;
> no-1-8-v;
> sleep = <&rcpm 0x0080>;
> };
> t1023 also supports sleep(not deep sleep), it needs the info above.
The part that's wrong is where it says "t1024". It's not t1024 and for
rcpm it's not 100% compatible with t1024.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: add support for mpc8306
On Sat, 2015-03-28 at 17:59 +0100, Filip Brozovic wrote:
> diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
> index c2518cd..f967ff6 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -278,12 +278,17 @@ static void qe_snums_init(void)
> 0xF4, 0xF5, 0xFC, 0xFD,
> };
> static const u8 snum_init_46[] = {
> +#if !defined(CONFIG_QE_8306)
> 0x04, 0x05, 0x0C, 0x0D, 0x14, 0x15, 0x1C, 0x1D,
> - 0x24, 0x25, 0x2C, 0x2D, 0x34, 0x35, 0x88, 0x89,
> - 0x98, 0x99, 0xA8, 0xA9, 0xB8, 0xB9, 0xC8, 0xC9,
> - 0xD8, 0xD9, 0xE8, 0xE9, 0x08, 0x09, 0x18, 0x19,
> - 0x28, 0x29, 0x38, 0x39, 0x48, 0x49, 0x58, 0x59,
> - 0x68, 0x69, 0x78, 0x79, 0x80, 0x81,
> + 0x24, 0x25, 0x2C, 0x2D, 0x34, 0x35,
> +#endif
> + 0x88, 0x89, 0x98, 0x99, 0xA8, 0xA9, 0xB8, 0xB9,
> + 0xC8, 0xC9, 0xD8, 0xD9, 0xE8, 0xE9,
> +#if !defined(CONFIG_QE_8306)
> + 0x08, 0x09, 0x18, 0x19, 0x28, 0x29, 0x38, 0x39,
> + 0x48, 0x49, 0x58, 0x59, 0x68, 0x69, 0x78, 0x79,
> + 0x80, 0x81,
> +#endif
> };
> static const u8 *snum_init;
This breaks multiplatform support. You need to determine this at
runtime.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [2/4] powerpc/rcpm: add RCPM driver
On Thu, 2015-04-02 at 05:33 -0500, Zhao Chenhui-B35336 wrote:
> > +static int rcpm_v2_plat_enter_state(int state)
> > +{
> > + u32 *pmcsr_reg = &rcpm_v2_regs->powmgtcsr;
> > + int ret = 0;
> > + int result;
> > +
> > + switch (state) {
> > + case PLAT_PM_LPM20:
> > + /* clear previous LPM20 status */
> > + setbits32(pmcsr_reg, RCPM_POWMGTCSR_P_LPM20_ST);
>
> How would the bit be set when you enter here, given that you wait for it
> to clear when leaving?
>
> [chenhui] Actually, the bit is not used by software. Just follow the
> instruction in RM.
Sorry, I missed the "_P_" and thought it was RCPM_POWMGTCSR_LPM20_ST.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [3/4] powerpc: support CPU hotplug for e500mc, e5500 and e6500
On Thu, 2015-04-02 at 06:16 -0500, Zhao Chenhui-B35336 wrote:
>
>
> From: Wood Scott-B07421
> Sent: Tuesday, March 31, 2015 10:07
> To: Zhao Chenhui-B35336
> Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org;
> linux-ker...@vger.kernel.org; Jin Zhengxiong-R64188
> Subject: Re: [3/4] powerpc: support CPU hotplug for e500mc, e5500 and e6500
>
> On Thu, Mar 26, 2015 at 06:18:14PM +0800, chenhui zhao wrote:
> > @@ -189,16 +193,14 @@ _GLOBAL(fsl_secondary_thread_init)
> > isync
> >
> > /*
> > - * Fix PIR to match the linear numbering in the device tree.
> > - *
> > - * On e6500, the reset value of PIR uses the low three bits for
> > - * the thread within a core, and the upper bits for the core
> > - * number. There are two threads per core, so shift everything
> > - * but the low bit right by two bits so that the cpu numbering is
> > - * continuous.
>
> Why are you getting rid of this? If it's to avoid doing it twice on the
> same thread, in my work-in-progress kexec patches I instead check to see
> whether BUCSR has already been set up -- if it has, I assume we've
> already been here.
>
> [chenhui] I didn't delete the branch prediction related code.
I didn't say you did. I'm saying that you can check whether BUCSR has
been set up, to determine whether PIR has already been adjusted, if your
concern is avoiding running this twice on a thread between core resets.
If that's not your concern, then please explain.
> > + /*
> > + * If both threads are offline, reset core to start.
> > + * When core is up, Thread 0 always gets up first,
> > + * so bind the current logical cpu with Thread 0.
> > + */
>
> What if the core is not in a PM state that requires a reset?
> Where does this reset occur?
>
> [chenhui] Reset occurs in the function mpic_reset_core().
>
> > + if (hw_cpu != cpu_first_thread_sibling(hw_cpu)) {
> > + int hw_cpu1, hw_cpu2;
> > +
> > + hw_cpu1 = get_hard_smp_processor_id(primary);
> > + hw_cpu2 = get_hard_smp_processor_id(primary + 1);
> > + set_hard_smp_processor_id(primary, hw_cpu2);
> > + set_hard_smp_processor_id(primary + 1, hw_cpu1);
> > + /* get new physical cpu id */
> > + hw_cpu = get_hard_smp_processor_id(nr);
>
> Why are you swapping the hard smp ids?
>
> [chenhui] For example, Core1 has two threads, Thread0 and Thread1. In normal
> boot, Thread0 is CPU2, and Thread1 is CPU3.
> But, if CPU2 and CPU3 are all off, user wants CPU3 up first. we need to call
> Thread0 as CPU3 and Thead1 as CPU2, considering
> the limitation, after core is reset, only Thread0 is up, then Thread0 kicks
> up Thread1.
There's no need for this. I have booting from a thread1, and having it
kick its thread0, working locally without messing with the hwid/cpu
mapping.
> > @@ -252,11 +340,7 @@ static int smp_85xx_kick_cpu(int nr)
> > spin_table = phys_to_virt(*cpu_rel_addr);
> >
> > local_irq_save(flags);
> > -#ifdef CONFIG_PPC32
> > #ifdef CONFIG_HOTPLUG_CPU
> > - /* Corresponding to generic_set_cpu_dead() */
> > - generic_set_cpu_up(nr);
> > -
>
> Why did you move this?
>
> [chenhui] It would be better to set this after CPU is really up.
Please make it a separate patch with an explanation.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v8, 2/2] powerpc/mpc85xx: Add FSL QorIQ DPAA QMan support to device tree(s)
On Tue, Mar 24, 2015 at 11:55:09AM -0500, Emil Medve wrote: > From: Kumar Gala > > Signed-off-by: Kumar Gala > Signed-off-by: Geoff Thorpe > Signed-off-by: Hai-Ying Wang > Signed-off-by: Chunhe Lan > Signed-off-by: Poonam Aggrwal > [Emil Medve: Sync with the upstream binding] > Signed-off-by: Emil Medve This patch causes U-Boot to crash when doing device tree fixups, due to the lack of cell-index. Since we'd rather not break compatibility with existing U-Boot (at least over something this trivial), I'll respin this with cell-index, and add cell-index to the binding with a note that it's only for U-Boot compatibility and is otherwise deprecated. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Pull request: scottwood/linux.git next
Highlights include BMan device tree nodes, an MSI erratum workaround, a couple minor performance improvements, config updates, and misc fixes/cleanup. The following changes since commit 6eca8933d3ff17bff39d5f10a2a22366d8622fa6: powerpc/kernel: Rename copy_thread() 'arg' argument to 'kthread_arg' (2015-03-20 12:41:15 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next for you to fetch changes up to d41444daba1fd65e5a998c83398f44524f638d07: powerpc/corenet: enable CONFIG_I2C_MUX and CONFIG_I2C_MUX_PCA954x (2015-03-31 22:23:21 -0500) Andy Fleming (1): powerpc/corenet: Enable muxing MDIO buses via GPIO Benjamin Herrenschmidt (1): powerpc: Make corenet64_defconfig a bit more useful Bogdan Purcareata (1): powerpc/mpic: Remove WHOAMI readback after EOI Emil Medve (1): powerpc/dts: Remove B4860 emulator support Hongtao Jia (4): powerpc/mpic: Add get_version API both for internal and external use powerpc/85xx: workaround for chips with MSI hardware errata powerpc: Enable thermal monitor feature in defconfig for supported platforms powerpc: Enable power monitor feature in defconfig for supported platforms Igal Liberman (1): powerpc/mpc85xx: Add FMan platform support Julia Lawall (1): powerpc: don't export static symbol Kevin Hao (1): powerpc: book3e_64: fix the align size for paca_struct Kumar Gala (1): powerpc/mpc85xx: Add FSL QorIQ DPAA BMan support to device tree(s) Madalin Bucur (1): powerpc/fsl-booke: Add T4080 SVR value Shengzhou Liu (2): powerpc/t2080qds: fix rtc interrupt powerpc/corenet: enable CONFIG_I2C_MUX and CONFIG_I2C_MUX_PCA954x Shruti Kanetkar (1): powerpc/corenet: Enable muxing MDIO buses via FPGA Yanjiang Jin (1): powerpc/mpc85xx: call k(un)map_atomic rather than k(un)map arch/powerpc/boot/dts/b4860emu.dts| 223 -- arch/powerpc/boot/dts/b4qds.dtsi | 17 +- arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 60 +- arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 89 - arch/powerpc/boot/dts/fsl/p1023si-post.dtsi | 37 +++- arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 11 +- arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 11 +- arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 11 +- arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 11 +- arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 11 +- arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 65 ++- arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 105 +- arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 265 +- arch/powerpc/boot/dts/kmcoge4.dts | 15 ++ arch/powerpc/boot/dts/oca4080.dts | 15 ++ arch/powerpc/boot/dts/p1023rdb.dts| 18 +- arch/powerpc/boot/dts/p2041rdb.dts| 17 +- arch/powerpc/boot/dts/p3041ds.dts | 17 +- arch/powerpc/boot/dts/p4080ds.dts | 17 +- arch/powerpc/boot/dts/p5020ds.dts | 17 +- arch/powerpc/boot/dts/p5040ds.dts | 17 +- arch/powerpc/boot/dts/t104xqds.dtsi | 17 +- arch/powerpc/boot/dts/t104xrdb.dtsi | 14 ++ arch/powerpc/boot/dts/t208xqds.dtsi | 19 +- arch/powerpc/boot/dts/t208xrdb.dtsi | 15 ++ arch/powerpc/boot/dts/t4240qds.dts| 17 +- arch/powerpc/boot/dts/t4240rdb.dts| 15 ++ arch/powerpc/configs/corenet32_smp_defconfig | 7 +- arch/powerpc/configs/corenet64_smp_defconfig | 15 +- arch/powerpc/configs/mpc85xx_defconfig| 3 +- arch/powerpc/configs/mpc85xx_smp_defconfig| 2 +- arch/powerpc/include/asm/mpc85xx.h| 1 + arch/powerpc/include/asm/mpic.h | 3 + arch/powerpc/include/asm/paca.h | 4 +- arch/powerpc/platforms/85xx/common.c | 1 + arch/powerpc/platforms/85xx/corenet_generic.c | 12 ++ arch/powerpc/platforms/85xx/smp.c | 4 +- arch/powerpc/sysdev/fsl_msi.c | 29 ++- arch/powerpc/sysdev/fsl_msi.h | 2 + arch/powerpc/sysdev/mpic.c| 11 +- arch/powerpc/sysdev/qe_lib/qe_io.c| 25 --- 41 files changed, 981 insertions(+), 284 deletions(-) delete mode 100644 arch/powerpc/boot/dts/b4860emu.dts ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On Fri, 2015-03-27 at 19:07 +0200, Purcareata Bogdan wrote: > On 27.02.2015 03:05, Scott Wood wrote: > > On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote: > >> On 02/26/2015 02:02 PM, Paolo Bonzini wrote: > >>> > >>> > >>> On 24/02/2015 00:27, Scott Wood wrote: > >>>> This isn't a host PIC driver. It's guest PIC emulation, some of which > >>>> is indeed not suitable for a rawlock (in particular, openpic_update_irq > >>>> which loops on the number of vcpus, with a loop body that calls > >>>> IRQ_check() which loops over all pending IRQs). > >>> > >>> The question is what behavior is wanted of code that isn't quite > >>> RT-ready. What is preferred, bugs or bad latency? > >>> > >>> If the answer is bad latency (which can be avoided simply by not running > >>> KVM on a RT kernel in production), patch 1 can be applied. If the > >> can be applied *but* makes no difference if applied or not. > >> > >>> answer is bugs, patch 1 is not upstream material. > >>> > >>> I myself prefer to have bad latency; if something takes a spinlock in > >>> atomic context, that spinlock should be raw. If it hurts (latency), > >>> don't do it (use the affected code). > >> > >> The problem, that is fixed by this s/spin_lock/raw_spin_lock/, exists > >> only in -RT. There is no change upstream. In general we fix such things > >> in -RT first and forward the patches upstream if possible. This convert > >> thingy would be possible. > >> Bug fixing comes before latency no matter if RT or not. Converting > >> every lock into a rawlock is not always the answer. > >> Last thing I read from Scott is that he is not entirely sure if this is > >> the right approach or not and patch #1 was not acked-by him either. > >> > >> So for now I wait for Scott's feedback and maybe a backtrace :) > > > > Obviously leaving it in a buggy state is not what we want -- but I lean > > towards a short term "fix" of putting "depends on !PREEMPT_RT" on the > > in-kernel MPIC emulation (which is itself just an optimization -- you > > can still use KVM without it). This way people don't enable it with RT > > without being aware of the issue, and there's more of an incentive to > > fix it properly. > > > > I'll let Bogdan supply the backtrace. > > So about the backtrace. Wasn't really sure how to "catch" this, so what > I did was to start a 24 VCPUs guest on a 24 CPU board, and in the guest > run 24 netperf flows with an external back to back board of the same > kind. I assumed this would provide the sufficient VCPUs and external > interrupt to expose an alleged culprit. > > With regards to measuring the latency, I thought of using ftrace, > specifically the preemptirqsoff latency histogram. Unfortunately, I > wasn't able to capture any major differences between running a guest > with in-kernel MPIC emulation (with the openpic raw_spinlock_conversion > applied) vs. no in-kernel MPIC emulation. Function profiling > (trace_stat) shows that in the second case there's a far greater time > spent in kvm_handle_exit (100x), but overall, the maximum latencies for > preemptirqsoff don't look that much different. > > Here are the max numbers (preemptirqsoff) for the 24 CPUs, on the host > RT Linux, sorted in descending order, expressed in microseconds: > > In-kernel MPICQEMU MPIC > 3975 5105 What are you measuring? Latency in the host, or in the guest? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: add support for mpc8306
On Tue, 2015-03-31 at 21:58 +0200, Filip Brozović wrote: > On 3/31/2015 7:54 PM, Scott Wood wrote: > > This breaks multiplatform support. You need to determine this at > > runtime. > > Understood, but I'm unsure of how to do this exactly. Would it be > appropriate to define another array, snum_init_14, with the SNUM values > for the MPC8306 QE, change the minimum number of SNUMs in > qe_get_num_of_snums() to 14 and set the correct values this way? In that > case, compatibility with other platforms would be kept intact, and the > QE device tree node for MPC8306 (and MPC8309) boards would just have to > have the fsl,qe-num-snums property set to 14 in order for the driver to > set the correct values. Yes. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/config: add SCSI configs for corenet64_smp_defconfig
On Tue, 2015-03-31 at 18:00 +0800, yuantian.t...@freescale.com wrote: > From: Tang Yuantian > > Otherwise there wil be no SCSI device nodes. > > Signed-off-by: Shaohui Xie > Signed-off-by: Tang Yuantian > --- > arch/powerpc/configs/corenet64_smp_defconfig | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/powerpc/configs/corenet64_smp_defconfig > b/arch/powerpc/configs/corenet64_smp_defconfig > index 04737aa..77a8151 100644 > --- a/arch/powerpc/configs/corenet64_smp_defconfig > +++ b/arch/powerpc/configs/corenet64_smp_defconfig > @@ -75,6 +75,13 @@ CONFIG_BLK_DEV_LOOP=y > CONFIG_BLK_DEV_RAM=y > CONFIG_BLK_DEV_RAM_SIZE=131072 > CONFIG_EEPROM_LEGACY=y > +CONFIG_BLK_DEV_SD=y > +CONFIG_CHR_DEV_ST=y > +CONFIG_BLK_DEV_SR=y > +CONFIG_CHR_DEV_SG=y Ben already sent a patch enabling these (except ST -- do we really need that?) in both corenet32 and corenet64. > +CONFIG_SCSI_MULTI_LUN=y This option was removed by c309b35171dd > +CONFIG_SCSI_LOGGING=y > +CONFIG_SCSI_SPI_ATTRS=y If you want these enabled, do it in a separate patch with an explanation of why we should enable them by default, and do it for other 85xx/corenet configs as well. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/3][PATCH][v2] Device Tree bindings for Freescale TDM controller
On Thu, 2015-04-02 at 16:17 +0530, sand...@freescale.com wrote:
> From: Sandeep Singh
>
> This controller is available on many Freescale SOCs like MPC8315, P1020,
> P1010,
> P1022 and P1024
>
> Signed-off-by: Sandeep Singh
> Signed-off-by: Poonam Aggrwal
> ---
> Documentation/devicetree/bindings/tdm/fsl-tdm.txt | 65
> +
> 1 files changed, 65 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/tdm/fsl-tdm.txt
Add devicet...@vger.kernel.org to CC for device tree patches.
> diff --git a/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
> b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
> new file mode 100644
> index 000..1258b89
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
> @@ -0,0 +1,65 @@
> +=
> +TDM Device Tree Binding
> +Copyright (C) 2012 Freescale Semiconductor Inc.
> +
> +NOTE: The bindings described in this document are preliminary
> +and subject to change.
Get rid of this note. Bindings are expected to be stable ABI once
merged.
> +=
> +TDM (Time Division Multiplexing)
> +
> +DESCRIPTION
> +
> +The TDM is full duplex serial port designed to allow various devices
> including
> +digital signal processors (DSPs) to communicate with a variety of serial
> devices
> +including industry standard framers, codecs, other DSPs and microprocessors.
> +
> +The below properties describe the device tree bindings for Freescale TDM
> +controller.
> +This TDM controller is available on various Freescale Processors like
> +MPC8313, P1020, P1022 and P1010.
> +
> +PROPERTIES
> +
> + - compatible
> + Usage: required
> + Value type:
> + Definition: Should contain "fsl,tdm1.0".
What does 1.0 refer to? Is the TDM block identical on all the chips
that currently have it? Is this a real version number scheme (public or
otherwise) or something made up for software?
> + - reg
> + Usage: required
> + Definition: A standard property. The first reg specifier describes the
> + TDM registers, and the second describes the TDM DMAC registers.
> +
> + - clock-frequency
> + Usage: optional
> + Value type:
> + Definition: The frequency at which the TDM block is operating.
It'd be nice if new bindings used clock nodes rather than relying on
U-Boot fixups.
> + - interrupts
> + Usage: required
> + Definition: Definition: Two interrupt specifiers. The first is TDM
> + error, and the second is TDM EMAC.
> +
> + - phy-handle
> + Usage: optional
> + Value type:
> + Definition: Phandle of the line controller node or framer node eg.
> SLIC,
> + E1/T1 etc.
> +
> + - fsl,max-time-slots
> + Usage: required
> + Value type:
> + Definition: Maximum number of 8-bit time slots in one TDM frame.
> + This is the maximum number which TDM hardware supports.
> +
> +EXAMPLE
> +
> + tdm@16000 {
> + compatible = "fsl,tdm1.0";
> + reg = <0x16000 0x200 0x2c000 0x2000>;
> + clock-frequency = <0>;
> + interrupts = <16 8 62 8>;
> + phy-handle = <&zarlink1>;
> + fsl,max-time-slots = <128>;
> + };
The example refers to a "zarlink1" node but it is not present. What
does a "line controller or framer node" look like?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc/85xx: miscellaneous changes on mpc85xx_defconfig
On Thu, 2015-04-02 at 16:37 -0500, Lijun Pan wrote:
> Merge Freescale's Internal mpc85xx_defconfig with upstream's.
> Run savedefconfig to get the minimal change.
What makes the internal config preferred without any explanation of why
we want or don't want specific config items? Especially where things
are being turned off, rather than on.
Are any of these changes due to running savedefconfig on the upstream
config (if so, make that a separate patch)?
> @@ -50,8 +50,6 @@ CONFIG_BINFMT_MISC=m
> CONFIG_MATH_EMULATION=y
> CONFIG_FORCE_MAX_ZONEORDER=12
> CONFIG_PCI=y
> -CONFIG_PCIEPORTBUS=y
> -# CONFIG_PCIEASPM is not set
PCIEPORTBUS was enabled by commit 2727ed54716e60 ("powerpc/85xx: Add
support for Emerson/Artesyn MVME2500."). Presumably that board needs
it.
> CONFIG_PCI_MSI=y
> CONFIG_RAPIDIO=y
> CONFIG_NET=y
> @@ -88,21 +86,17 @@ CONFIG_FTL=y
> CONFIG_MTD_CFI=y
> CONFIG_MTD_CFI_INTELEXT=y
> CONFIG_MTD_CFI_AMDSTD=y
> -CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_PHYSMAP_OF=y
> -CONFIG_MTD_PLATRAM=y
> -CONFIG_MTD_M25P80=y
> CONFIG_MTD_NAND=y
> CONFIG_MTD_NAND_FSL_ELBC=y
> CONFIG_MTD_NAND_FSL_IFC=y
> -CONFIG_MTD_SPI_NOR=y
Why?
> CONFIG_EDAC=y
> CONFIG_EDAC_MM_EDAC=y
> -CONFIG_EDAC_MPC85XX=y
Umm... What other EDAC driver are you expecting to be used with this
config?
> CONFIG_RTC_CLASS=y
> -CONFIG_RTC_DRV_DS1307=y
> -CONFIG_RTC_DRV_DS1374=y
> -CONFIG_RTC_DRV_DS3232=y
mpc8568/8569 have ds1374. mpc8536/p1022 have ds3232. Various tqm
boards have ds1337 which uses the ds1307 driver.
> @@ -218,9 +206,6 @@ CONFIG_ADFS_FS=m
> CONFIG_AFFS_FS=m
> CONFIG_HFS_FS=m
> CONFIG_HFSPLUS_FS=m
> -CONFIG_BEFS_FS=m
> -CONFIG_BFS_FS=m
> -CONFIG_EFS_FS=m
> CONFIG_JFFS2_FS=y
> CONFIG_JFFS2_FS_DEBUG=1
> CONFIG_UBIFS_FS=y
This is pretty random. If we want to remove fringe filesystems, fine,
but why just these three?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/e6500: Optimize hugepage TLB misses
Some workloads take a lot of TLB misses despite using traditional hugepages. Handle these TLB misses in the asm fastpath rather than going through a bunch of C code. With this patch I measured around a 5x speedup in handling hugepage TLB misses. Signed-off-by: Scott Wood --- arch/powerpc/mm/tlb_low_64e.S | 51 --- 1 file changed, 48 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S index 89bf95b..765b419 100644 --- a/arch/powerpc/mm/tlb_low_64e.S +++ b/arch/powerpc/mm/tlb_low_64e.S @@ -398,18 +398,18 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_SMT) rldicl r15,r16,64-PUD_SHIFT+3,64-PUD_INDEX_SIZE-3 clrrdi r15,r15,3 cmpdi cr0,r14,0 - bge tlb_miss_fault_e6500/* Bad pgd entry or hugepage; bail */ + bge tlb_miss_huge_e6500 /* Bad pgd entry or hugepage; bail */ ldx r14,r14,r15 /* grab pud entry */ rldicl r15,r16,64-PMD_SHIFT+3,64-PMD_INDEX_SIZE-3 clrrdi r15,r15,3 cmpdi cr0,r14,0 - bge tlb_miss_fault_e6500 + bge tlb_miss_huge_e6500 ldx r14,r14,r15 /* Grab pmd entry */ mfspr r10,SPRN_MAS0 cmpdi cr0,r14,0 - bge tlb_miss_fault_e6500 + bge tlb_miss_huge_e6500 /* Now we build the MAS for a 2M indirect page: * @@ -428,6 +428,7 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_SMT) clrrdi r15,r16,21 /* make EA 2M-aligned */ mtspr SPRN_MAS2,r15 +tlb_miss_huge_done_e6500: lbz r15,TCD_ESEL_NEXT(r11) lbz r16,TCD_ESEL_MAX(r11) lbz r14,TCD_ESEL_FIRST(r11) @@ -456,6 +457,50 @@ END_FTR_SECTION_IFSET(CPU_FTR_SMT) tlb_epilog_bolted rfi +tlb_miss_huge_e6500: + beq tlb_miss_fault_e6500 + li r10,1 + andi. r15,r14,HUGEPD_SHIFT_MASK@l /* r15 = psize */ + rldimi r14,r10,63,0/* Set PD_HUGE */ + xor r14,r14,r15 /* Clear size bits */ + ldx r14,0,r14 + + /* +* Now we build the MAS for a huge page. +* +* MAS 0 :ESEL needs to be filled by software round-robin +* - can be handled by indirect code +* MAS 1 :Need to clear IND and set TSIZE +* MAS 2,3+7: Needs to be redone similar to non-tablewalk handler +*/ + + subir15,r15,10 /* Convert psize to tsize */ + mfspr r10,SPRN_MAS1 + rlwinm r10,r10,0,~MAS1_IND + rlwimi r10,r15,MAS1_TSIZE_SHIFT,MAS1_TSIZE_MASK + mtspr SPRN_MAS1,r10 + + li r10,-0x400 + sld r15,r10,r15 /* Generate mask based on size */ + and r10,r16,r15 + rldicr r15,r14,64-(PTE_RPN_SHIFT-PAGE_SHIFT),63-PAGE_SHIFT + rlwimi r10,r14,32-19,27,31 /* Insert WIMGE */ + clrldi r15,r15,PAGE_SHIFT /* Clear crap at the top */ + rlwimi r15,r14,32-8,22,25 /* Move in U bits */ + mtspr SPRN_MAS2,r10 + andi. r10,r14,_PAGE_DIRTY + rlwimi r15,r14,32-2,26,31 /* Move in BAP bits */ + + /* Mask out SW and UW if !DIRTY (XXX optimize this !) */ + bne 1f + li r10,MAS3_SW|MAS3_UW + andcr15,r15,r10 +1: + mtspr SPRN_MAS7_MAS3,r15 + + mfspr r10,SPRN_MAS0 + b tlb_miss_huge_done_e6500 + tlb_miss_kernel_e6500: ld r14,PACA_KERNELPGD(r13) cmpldi cr1,r15,8 /* Check for vmalloc region */ -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/83xx: add support for mpc8306
On Fri, 2015-04-03 at 14:45 +0200, Filip Brozović wrote: > On 4/3/2015 2:01 PM, Paul Bolle wrote: > > On Fri, 2015-04-03 at 12:44 +0200, Filip Brozovic wrote: > >> --- a/arch/powerpc/platforms/83xx/Kconfig > >> +++ b/arch/powerpc/platforms/83xx/Kconfig > > > >> +# used for gpio > >> +config PPC_MPC830x > >> + bool > >> + select ARCH_WANT_OPTIONAL_GPIOLIB > >> + > >> +config PPC_MPC8306 > >> + bool > > > > To me these two new Kconfig symbols look pointless: > > - they have no prompt, so one cannot set them manually; > > - no other Kconfig symbol selects them; > > - they do not default to 'y'. > > > > I'm not aware of a way to set these symbols to 'y' outside of those > > three. Is there perhaps a way for kconfig to set these symbols to 'y' > > that I have missed? > > > > Or do you expect to do one of these three things in a separate patch? > > > > The idea was that boards in the Kconfig file would select these symbols > in order to enable support for the 8306. I mainly wanted to get this > patch into mainline in order to make kernel maintenance for a couple of > custom in-house developed boards easier. Since these boards are not > widely available and our customers are unlikely to want to change and > recompile the kernel, I have so far leaned towards not including support > for them in mainline. As far as I can see, boards which are included in > mainline right now are mostly evaluation boards which are easily > available at most electronics distributors. > > That being said, I don't know what the "official" stance on this is; is > adding custom boards encouraged regardless of their availability (e.g. > if I develop a custom board with the intention of only ever actually > making a single prototype for personal use, should I go and submit > patches so that support makes it into the mainline kernel?), or should > there be a minimum level of public interest before incorporating custom > boards into mainline? If it's the latter, I suppose a solution would be > to include support for the Freescale MPC8306SOM in mainline. Of course, > this has its own problems, since someone would have to write and > maintain it (and I don't have an MPC8306SOM nor the time needed to do > maintenance). Custom boards are fine as long as someone will maintain them. What are you using PPC_MPC8306 for in your custom board code? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On Fri, 2015-04-03 at 11:07 +0300, Purcareata Bogdan wrote: > On 03.04.2015 02:11, Scott Wood wrote: > > On Fri, 2015-03-27 at 19:07 +0200, Purcareata Bogdan wrote: > >> On 27.02.2015 03:05, Scott Wood wrote: > >>> On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote: > >>>> On 02/26/2015 02:02 PM, Paolo Bonzini wrote: > >>>>> > >>>>> > >>>>> On 24/02/2015 00:27, Scott Wood wrote: > >>>>>> This isn't a host PIC driver. It's guest PIC emulation, some of which > >>>>>> is indeed not suitable for a rawlock (in particular, openpic_update_irq > >>>>>> which loops on the number of vcpus, with a loop body that calls > >>>>>> IRQ_check() which loops over all pending IRQs). > >>>>> > >>>>> The question is what behavior is wanted of code that isn't quite > >>>>> RT-ready. What is preferred, bugs or bad latency? > >>>>> > >>>>> If the answer is bad latency (which can be avoided simply by not running > >>>>> KVM on a RT kernel in production), patch 1 can be applied. If the > >>>> can be applied *but* makes no difference if applied or not. > >>>> > >>>>> answer is bugs, patch 1 is not upstream material. > >>>>> > >>>>> I myself prefer to have bad latency; if something takes a spinlock in > >>>>> atomic context, that spinlock should be raw. If it hurts (latency), > >>>>> don't do it (use the affected code). > >>>> > >>>> The problem, that is fixed by this s/spin_lock/raw_spin_lock/, exists > >>>> only in -RT. There is no change upstream. In general we fix such things > >>>> in -RT first and forward the patches upstream if possible. This convert > >>>> thingy would be possible. > >>>> Bug fixing comes before latency no matter if RT or not. Converting > >>>> every lock into a rawlock is not always the answer. > >>>> Last thing I read from Scott is that he is not entirely sure if this is > >>>> the right approach or not and patch #1 was not acked-by him either. > >>>> > >>>> So for now I wait for Scott's feedback and maybe a backtrace :) > >>> > >>> Obviously leaving it in a buggy state is not what we want -- but I lean > >>> towards a short term "fix" of putting "depends on !PREEMPT_RT" on the > >>> in-kernel MPIC emulation (which is itself just an optimization -- you > >>> can still use KVM without it). This way people don't enable it with RT > >>> without being aware of the issue, and there's more of an incentive to > >>> fix it properly. > >>> > >>> I'll let Bogdan supply the backtrace. > >> > >> So about the backtrace. Wasn't really sure how to "catch" this, so what > >> I did was to start a 24 VCPUs guest on a 24 CPU board, and in the guest > >> run 24 netperf flows with an external back to back board of the same > >> kind. I assumed this would provide the sufficient VCPUs and external > >> interrupt to expose an alleged culprit. > >> > >> With regards to measuring the latency, I thought of using ftrace, > >> specifically the preemptirqsoff latency histogram. Unfortunately, I > >> wasn't able to capture any major differences between running a guest > >> with in-kernel MPIC emulation (with the openpic raw_spinlock_conversion > >> applied) vs. no in-kernel MPIC emulation. Function profiling > >> (trace_stat) shows that in the second case there's a far greater time > >> spent in kvm_handle_exit (100x), but overall, the maximum latencies for > >> preemptirqsoff don't look that much different. > >> > >> Here are the max numbers (preemptirqsoff) for the 24 CPUs, on the host > >> RT Linux, sorted in descending order, expressed in microseconds: > >> > >> In-kernel MPIC QEMU MPIC > >> 3975 5105 > > > > What are you measuring? Latency in the host, or in the guest? > > This is in the host kernel. Those are terrible numbers in both cases. Can you use those tracing tools to find out what the code path is for QEMU MPIC? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/e500mc: Remove dead L2 flushing code in idle_e500.S
This code can never be executed as it is only built when CONFIG_PPC_E500MC is unset, but the only CPUs that have CPU_FTR_L2CSR require CONFIG_PPC_E500MC and do not have the MSR/HID0-based nap mechanism that this file uses. Signed-off-by: Scott Wood --- arch/powerpc/kernel/idle_e500.S | 9 - 1 file changed, 9 deletions(-) diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S index 1544866..b9b6ef5 100644 --- a/arch/powerpc/kernel/idle_e500.S +++ b/arch/powerpc/kernel/idle_e500.S @@ -58,15 +58,6 @@ BEGIN_FTR_SECTION mtlrr0 lis r3,HID0_NAP@h END_FTR_SECTION_IFSET(CPU_FTR_CAN_NAP) -BEGIN_FTR_SECTION - msync - li r7,L2CSR0_L2FL@l - mtspr SPRN_L2CSR0,r7 -2: - mfspr r7,SPRN_L2CSR0 - andi. r4,r7,L2CSR0_L2FL@l - bne 2b -END_FTR_SECTION_IFSET(CPU_FTR_L2CSR|CPU_FTR_CAN_NAP) 1: /* Go to NAP or DOZE now */ mfspr r4,SPRN_HID0 -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc32: fix warning from include/linux/mm.h
On Tue, 2015-04-07 at 10:07 +0200, leroy christophe wrote: > Le 21/03/2015 00:52, Scott Wood a écrit : > > On Fri, Dec 05, 2014 at 12:20:20PM +0100, LEROY Christophe wrote: > >> include/linux/mm.h: In function 'is_vmalloc_addr': > >> include/linux/mm.h:367:14: warning: comparison between signed and unsigned > >> integer expressions [-Wsign-compare] > >>return addr >= VMALLOC_START && addr < VMALLOC_END; > >>^ > >> > >> Signed-off-by: Christophe Leroy > >> --- > >> arch/powerpc/include/asm/pgtable-ppc32.h | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > That warning doesn't appear to be enabled. What config are you seeing > > this with? > I'm used to adding EXTRA_CFLAGS=-Wextra when checking my own drivers, > as it helps finding additional bugs. It also produces a lot of noise, which is why Linux doesn't enable it. E.g. it enables useless "unused parameter" warnings all over the place. > When doing that, the only warnings I get outside of my own code are this > one, and the other one in my proposed patch identified "powerpc32: fix > warning from include/asm-generic/termios-base.h" > > I though it would be worth fixing those two warnings in order to get a > perfectly clean code. In general I don't think we should clutter up the code with suppression for warnings we don't enable, but in this case we do end up with a value that would be negative if considered as signed. Instead of changing VMALLOC_OFFSET, though, I'd address it where the problem is actually introduced -- which is casting high_memory to (long) rather than (unsigned long) or (uintptr_t). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] powerpc/8xx: Getting rid of CONFIG_8xx
On Tue, 2015-04-07 at 10:19 +0200, leroy christophe wrote: > Le 25/03/2015 01:45, Scott Wood a écrit : > > On Fri, 2015-03-13 at 10:34 +1100, Michael Ellerman wrote: > >> You'll need to collect ACKs, or get the individual patches merged, and > >> then we > >> can take patch 8 through the powerpc tree once those are all in - probably > >> for > >> 4.2. > > It looks like CONFIG_8xx is used a lot more than CONFIG_PPC_8xx, so it > > would be less churn to get rid of the latter (plus, we also have > > CONFIG_4xx, CONFIG_6xx, etc). The only use of PPC_8xx I see outside > > arch/powerpc is in drivers/watchdog/Kconfig. > > Ok, we can do that. But when outside of arch/powerpc/, isn't is more > explicit with CONFIG_PPC_8xx rather that CONFIG_8xx ? Yes, CONFIG_PPC_8xx is a better name, but churn and consistency matter as well. > Now that I have submitted the first set of patch, don't we have a risk > that now it is already merged by some other maintainers ? Sigh. I see a couple in linux-next. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Old regression with MTD devices disappearing from a Kurobox HD/HG
On Sat, 2015-04-04 at 02:40 -0300, Rogério Brito wrote:
> Unfortunately, right now, what I see with Linus's tree
> (4.0.0-rc6-9-g6c310bc) is the following:
>
> ,
> | physmap platform flash device: 0040 at ffc0
> | physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID
> 0x04 Chip ID 0x7e
> | Amd/Fujitsu Extended Query Table at 0x0040
> | Amd/Fujitsu Extended Query version 1.3.
> | physmap-flash.0: Swapping erase regions for top-boot CFI table.
> | number of CFI chips: 1
> `
>
> I note that arch/powerpc/boot/dts/kuroboxH{D,G}.dts have, as one of their
> first lines, the following comment: [0][1]
>
> add flash parts, rtc, ??
>
> [0]:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHD.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> [1]:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHG.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
>
> Is this a problem that can be fixed via additions to the DTS files? Or
> would the problem be solved in a different way?
What are your bootargs?
I suggest putting the flash device into the dts (instead of using
physmap), and specifying the partitions on the command-line using
mtdparts. Putting the partitions in the dts is an option as well, but
less flexible if users may want to change the partition layout -- though
that may be less of a concern here than with reference boards.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Tue, 2015-04-07 at 07:08 +0300, Igal.Liberman wrote: > From: Igal Liberman > > Signed-off-by: Igal Liberman > --- > .../devicetree/bindings/clock/qoriq-clock.txt | 59 > > 1 file changed, 59 insertions(+) > > diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt > b/Documentation/devicetree/bindings/clock/qoriq-clock.txt > index df4a259..a7e84ce 100644 > --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt > +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt > @@ -65,6 +65,7 @@ Required properties: > It takes parent's clock-frequency as its clock. > * "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0) > * "fsl,qoriq-platform-pll-2.0" for the platform PLL clock (v2.0) > + * "fsl,fman-clk-mux" for the Frame Manager clock. Is there any versioning required on this? > - #clock-cells: From common clock binding. The number of cells in a > clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0" > clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks. > @@ -73,6 +74,52 @@ Required properties: > * 0 - equal to the PLL frequency > * 1 - equal to the PLL frequency divided by 2 > * 2 - equal to the PLL frequency divided by 4 > + For "fsl,fman-clk-mux" clocks, the single clock-specifier cell may > + take values according the Reset Configuration Word of the specific > + device: fsl,fman-clk-mux nodes have #clock-cells of zero, so I don't understand this section. If this is meant to refer to the clock specifier that fsl,fman-clk-mux nodes use in their input clocks, that is determined by the clock provider and not the clock consumer. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] powerpc/fsl-booke: Add T1024 RDB board support
On Fri, 2015-04-03 at 18:35 +0800, Shengzhou Liu wrote:
> + board-control@2,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,t1024-cpld", "fsl,deepsleep-cpld";
No "fsl,deepsleep-cpld". Just have the driver recognize the compatibles
for the chips that have deep sleep.
Even if you were to do this, it would need to be documented in a
binding, and you'd need to be more specific about what CPLD family
you're talking about.
> + tdma: ucc@2000 {
> + compatible = "fsl,ucc-tdm";
> + rx-clock-name = "clk8";
> + tx-clock-name = "clk9";
> + fsl,rx-sync-clock = "rsync_pin";
> + fsl,tx-sync-clock = "tsync_pin";
> + fsl,tx-timeslot = <0xfffe>;
> + fsl,rx-timeslot = <0xfffe>;
> + fsl,tdm-framer-type = "e1";
> + fsl,tdm-mode = "normal";
> + fsl,tdm-id = <0>;
> + fsl,siram-entry-id = <0>;
> + };
Binding?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc/fsl-booke: Add device tree support for T1024/T1023 SoC
On Fri, 2015-04-03 at 18:35 +0800, Shengzhou Liu wrote:
> + rcpm: global-utilities@e2000 {
> + compatible = "fsl,t1023-rcpm", "fsl,qoriq-rcpm-2.0";
> + reg = <0xe2000 0x1000>;
> + };
> +
> + sfp: sfp@e8000 {
> + compatible = "fsl,t1023-sfp";
> + reg= <0xe8000 0x1000>;
> + };
> +
> + serdes: serdes@ea000 {
> + compatible = "fsl,t1023-serdes";
> + reg= <0xea000 0x4000>;
> + };
Consistent whitespace please. Just one space after "reg".
> +/include/ "qoriq-esdhc-0.dtsi"
> + sdhc@114000 {
> + compatible = "fsl,t1023-esdhc", "fsl,esdhc";
> + fsl,iommu-parent = <&pamu0>;
> + fsl,liodn-reg = <&guts 0x530>; /* eSDHCLIODNR */
> + sdhci,auto-cmd12;
> + no-1-8-v;
> + sleep = <&rcpm 0x0080>;
Get rid of "sleep" -- it's undocumented copy-and-paste from something
that was never finished.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Old regression with MTD devices disappearing from a Kurobox HD/HG
On Tue, 2015-04-07 at 20:58 -0300, Rogério Brito wrote:
> Dear Scott.
>
> First of all, thank you so very much for your reply.
>
> On Apr 07 2015, Scott Wood wrote:
> > On Sat, 2015-04-04 at 02:40 -0300, Rogério Brito wrote:
> > > ,
> > > | physmap platform flash device: 0040 at ffc0
> > > | physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer
> > > ID 0x04 Chip ID 0x7e
> > > | Amd/Fujitsu Extended Query Table at 0x0040
> > > | Amd/Fujitsu Extended Query version 1.3.
> > > | physmap-flash.0: Swapping erase regions for top-boot CFI table.
> > > | number of CFI chips: 1
> > > `
> > >
> > > I note that arch/powerpc/boot/dts/kuroboxH{D,G}.dts have, as one of their
> > > first lines, the following comment: [0][1]
> > >
> > > add flash parts, rtc, ??
> > >
> > > [0]:
> > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHD.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> > > [1]:
> > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHG.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> > >
> > > Is this a problem that can be fixed via additions to the DTS files? Or
> > > would the problem be solved in a different way?
> >
> > What are your bootargs?
>
> My kernel command line is (specified via uboot) is the following:
>
> ,
> | root=/dev/sda1 netconsole=@192.168.11.150/,@192.168.11.149/
> rtc-rs5c372.probe=0,0x32
> `
>
> Only that.
>
> > I suggest putting the flash device into the dts (instead of using
> > physmap), and specifying the partitions on the command-line using
> > mtdparts.
>
> This is good to know. Is there any reasonable dts that I can copy/adapt?
I'm not familiar with how flash is connected on this chip, so I don't
have a specific recommendation other than to read the binding and look
at several examples.
> I just started to read on the syntax of the dts files and I am still
> not confident that I can write my own without messing everything.
>
> Another question: would putting the description of the flash device into the
> dts file be helpful to remove any code from the kernel?
If you currently have a custom flash map driver, you could get rid of
that, but I suspect that's already gone away due to the fact that it's
no longer working.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Old regression with MTD devices disappearing from a Kurobox HD/HG
On Tue, 2015-04-07 at 21:37 -0300, Rogério Brito wrote:
> Dear Scott,
>
> Once again, thank you very much for your answer.
>
> On Apr 07 2015, Scott Wood wrote:
> > On Tue, 2015-04-07 at 20:58 -0300, Rogério Brito wrote:
> > > This is good to know. Is there any reasonable dts that I can copy/adapt?
> >
> > I'm not familiar with how flash is connected on this chip, so I don't
> > have a specific recommendation other than to read the binding and look
> > at several examples.
>
> How can I discover how the flash is connected? I'm really showing here that
> I am only a luser, but I am willing to find any specs so that this can be
> fixed.
>
> > > Another question: would putting the description of the flash device into
> > > the
> > > dts file be helpful to remove any code from the kernel?
> >
> > If you currently have a custom flash map driver, you could get rid of
> > that, but I suspect that's already gone away due to the fact that it's
> > no longer working.
>
> I see. If I do some "archaeology" (read: bisect when it stopped working),
> would that help to discover how the flash is connected?
It will probably give you the address and size of the flash, which is
good enough to get something working. Does your config (for the old
kernel) have anything with PHYSMAP in it? I suspect it probably broke
with commit dcb3e137ce9be1dfc86e306182b23e3ae5e239c4 ("[MTD] physmap:
make physmap compat explicit").
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
)
On Tue, 2015-04-07 at 22:13 -0300, Rogério Brito wrote:
> Hi, Scott.
>
> On Apr 07 2015, Scott Wood wrote:
> > On Tue, 2015-04-07 at 21:37 -0300, Rogério Brito wrote:
> > > I see. If I do some "archaeology" (read: bisect when it stopped
> > > working), would that help to discover how the flash is connected?
> >
> > It will probably give you the address and size of the flash, which is
> > good enough to get something working. Does your config (for the old
> > kernel) have anything with PHYSMAP in it? I suspect it probably broke
> > with commit dcb3e137ce9be1dfc86e306182b23e3ae5e239c4 ("[MTD] physmap:
> > make physmap compat explicit").
>
> Here is what my 2.6.27 kernel has in the section regarding physmap:
>
> ,
> | #
> | # Mapping drivers for chip access
> | #
> | # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> | CONFIG_MTD_PHYSMAP=y
> | CONFIG_MTD_PHYSMAP_START=0xffc0
> | CONFIG_MTD_PHYSMAP_LEN=0x40
> | CONFIG_MTD_PHYSMAP_BANKWIDTH=1
> | # CONFIG_MTD_PHYSMAP_OF is not set
> | # CONFIG_MTD_INTEL_VR_NOR is not set
> | # CONFIG_MTD_PLATRAM is not set
> `
>
> Here is what my 4.0-rc6 kernel has:
>
> ,
> | #
> | # Mapping drivers for chip access
> | #
> | # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> | CONFIG_MTD_PHYSMAP=y
> | CONFIG_MTD_PHYSMAP_COMPAT=y
> | CONFIG_MTD_PHYSMAP_START=0xffc0
> | CONFIG_MTD_PHYSMAP_LEN=0x40
> | CONFIG_MTD_PHYSMAP_BANKWIDTH=1
> | CONFIG_MTD_PHYSMAP_OF=y
> | # CONFIG_MTD_INTEL_VR_NOR is not set
> | # CONFIG_MTD_PLATRAM is not set
> `
>
> I may try to revert locally that patch here to see if things improve or not,
> but it will take me some time to compile it (I hope not much).
Oh right, it's the partitions that are missing, rather than the flash
device itself. It was probably commit
13e0fe49f676607688da7475c33540ec5dac53b5 ("mtd: drop physmap_configure")
that broke your out-of-tree kernel. Maybe you (or someone) dropped a
call to physmap_set_partitions() to stop the build error, and didn't
replace it with anything?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] QorIQ/TMU: add TMU node to device tree for QorIQ T104x
On Fri, 2015-04-10 at 01:23 -0500, Jia Hongtao-B38951 wrote: > > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Friday, April 10, 2015 11:56 AM > > To: Jia Hongtao-B38951 > > Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; > > robh...@kernel.org; rui.zh...@intel.com > > Subject: Re: [PATCH] QorIQ/TMU: add TMU node to device tree for QorIQ > > T104x > > > > On Tue, 2015-03-31 at 14:17 +0800, Jia Hongtao wrote: > > > This is Thermal Monitoring Unit for QorIQ platform. > > > > > > Signed-off-by: Jia Hongtao > > > --- > > > .../devicetree/bindings/thermal/qoriq-thermal.txt | 58 > > +++ > > > arch/powerpc/boot/dts/fsl/qoriq-tmu-t104xsi.dtsi | 82 > > ++ > > > arch/powerpc/boot/dts/fsl/t1040si-post.dtsi| 1 + > > > 3 files changed, 141 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/thermal/qoriq-thermal.txt > > > create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-tmu-t104xsi.dtsi > > > > > > diff --git > > > a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt > > > b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt > > > new file mode 100644 > > > index 000..dfc17fa > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt > > > @@ -0,0 +1,58 @@ > > > +* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs > > > + > > > +Required properties: > > > +- compatible : "fsl,qoriq-tmu". > > > > compatible: Must include "fsl,qoriq-tmu". The version of the device is > > determined by the TMU IP Block Revision Register (IPBRR0) > > at offset 0x0BF8. > > > > Table of correspondences between IPBRR0 values and example > > chips: > > Value Device > > --- --- > > 0x01900102 T1040 > > I will update it in next version. > > > > > > +- reg : address range of TMU registers. > > > +- interrupts : should contain the interrupt for TMU. > > > > s/should contain/contains/ > > Thanks for the correction. > > > > > > +- calibration : calibration table for TMU. > > > > What is the format of the calibration table, and where does one get the > > data? > > There are four calibration config range, for each range we got a couple of > pairs formatted like at offset of <0x0080, 0x0084>. The binding document needs to explain this, in more detail, as well as how one determines the data. Is this configuration or hardware description? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/hugetlb: Call mm_dec_nr_pmds() in hugetlb_free_pmd_range()
Commit dc6c9a35b66b5 ("mm: account pmd page tables to the process")
added a counter that is incremented whenever a PMD is allocated and
decremented whenever a PMD is freed. For hugepages on PPC, common code
is used to allocated PMDs, but arch-specific code is used to free PMDs.
This results in kernel output such as "BUG: non-zero nr_pmds on freeing
mm: 1" when using hugepages.
Update the PPC hugepage PMD freeing code to decrement the count, just
as the above commit did for free_pmd_range().
Fixes: dc6c9a35b66b5 ("mm: account pmd page tables to the process")
Signed-off-by: Scott Wood
---
Should we also be touching nr_ptes when we alloc/free hugepage PTEs?
arch/powerpc/mm/hugetlbpage.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 7e408bf..cecbe00 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -581,6 +581,7 @@ static void hugetlb_free_pmd_range(struct mmu_gather *tlb,
pud_t *pud,
pmd = pmd_offset(pud, start);
pud_clear(pud);
pmd_free_tlb(tlb, pmd, start);
+ mm_dec_nr_pmds(tlb->mm);
}
static void hugetlb_free_pud_range(struct mmu_gather *tlb, pgd_t *pgd,
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4 v2] powerpc/fsl-booke: Add T1024 RDB board support
On Wed, 2015-04-08 at 18:46 +0800, Shengzhou Liu wrote: > T1024RDB is a Freescale Reference Design Board that hosts the T1024 SoC. > > T1024RDB board Overview > --- > - Processor: T1024 SoC integrating two 64-bit e5500 cores up to 1.4GHz > - Memory: 64-bit 4GB DDR3L UDIMM with ECC and interleaving support > - Ethernet: two 1G RGMII ports, one 2.5G SGMII port and one 10G Base-T port > - Accelerator: DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC > - SerDes: 4 lanes up to 10.3125GHz > - IFC: 128MB NOR Flash, 1GB NAND Flash and CPLD system controlling > - PCIe: one PCIe slot and two Mini-PCIe connectors on-board > - USB: two Type-A USB2.0 ports with internal PHY > - eSDHC: one SDHC/MMC/eMMC connector > - eSPI: one 64MB N25Q512 SPI flash > - QE-TDM: support TDM Riser card >- 32-bit RISC controller for flexible support of the communications > peripherals >- Serial DMA channel for receive and transmit on all serial channels >- Two universal communication controllers, supporting TDM, HDLC, and UART > - I2C: four I2C controllers > - UART: two UART on board > - Deep sleep power management support > > Signed-off-by: Shengzhou Liu > --- > v2: Integrated scott's comments. My comment was to add a binding for the QE TDM stuff, not to remove it. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4 v2] powerpc/fsl-booke: Add device tree support for T1024/T1023 SoC
On Wed, 2015-04-08 at 18:46 +0800, Shengzhou Liu wrote:
> The T1024 SoC includes the following function and features:
> - Two 64-bit Power architecture e5500 cores, up to 1.4GHz
> - private 256KB L2 cache each core and shared 256KB CoreNet platform cache
> (CPC)
> - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
> support
> - Data Path Acceleration Architecture (DPAA) incorporating acceleration
> - Four MAC for 1G/2.5G/10G network interfaces (RGMII, SGMII, QSGMII, XFI)
> - High-speed peripheral interfaces
> - Three PCI Express 2.0 controllers
> - Additional peripheral interfaces
> - One SATA 2.0 controller
> - Two USB 2.0 controllers with integrated PHY
> - Enhanced secure digital host controller (SD/eSDHC/eMMC)
> - Enhanced serial peripheral interface (eSPI)
> - Four I2C controllers
> - Four 2-pin UARTs or two 4-pin UARTs
> - Integrated Flash Controller supporting NAND and NOR flash
> - Two 8-channel DMA engines
> - Multicore programmable interrupt controller (PIC)
> - LCD interface (DIU) with 12 bit dual data rate
> - QUICC Engine block supporting TDM, HDLC, and UART
[snip]
> +&soc {
> +/include/ "qoriq-tdm1.0.dtsi"
Where is this file? Is there some dependency you've forgotten to
mention?
If this is meant to apply after
http://patchwork.ozlabs.org/patch/457605/
is that really QUICC engine TDM as described in the comment above?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Thu, 2015-04-09 at 02:18 -0500, Liberman Igal-B31950 wrote: > > > Regards, > Igal Liberman. > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Thursday, April 09, 2015 12:12 AM > > To: Liberman Igal-B31950 > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > > Subject: Re: [v2] dt/bindings: qoriq-clock: Add binding for FMan clock mux > > > > On Wed, 2015-04-08 at 10:43 +0300, Igal.Liberman wrote: > > > @@ -76,6 +77,52 @@ Required properties: > > > > > > Recommended properties: > > > - clocks: Should be the phandle of input parent clock > > > + For "fsl,fman-clk-mux" clock there are several options for parent > > > + clock (clock provider), the parent is determined according to the > > > + Reset Configuration Word of the specific device: > > > + * P2041, P3041: > > > + * 0 - equal to platform PLL divided by 2 > > > + * 1 - equal to PLL2 divided by 2 > > > + * P4080 (Both FMans): > > > + * 0 - equal to platform PLL divided by 2 > > > + * 1 - equal to PLL3 divided by 2 > > ... > > > > > > Again, the clock specifier format is determined by the clock provider, not > > the > > clock consumer. > > > > Scott, > The "clocks" property contains all possible clock providers, right? > In the text above I'm trying to explain how the FMan clock provider is > determined and what are the options for each SoC. > Do you think that we shouldn't have this explanation? Can you please > elaborate? I'm saying that the clock specifiers must be the same regardless of the node that is consuming the clock. You can't define certain values as only being "for fsl,fman-clk-mux". -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] dt/bindings: fsl/guts: Added global-utilities compatibles
On Thu, 2015-04-09 at 09:19 +0300, Igal.Liberman wrote: > From: Igal Liberman > > Signed-off-by: Igal Liberman > --- > .../devicetree/bindings/powerpc/fsl/guts.txt | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > index 7f150b5..e4f0ac2 100644 > --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > +++ b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > @@ -9,6 +9,20 @@ Required properties: > > - compatible : Should define the compatible device type for > global-utilities. > + Possible compatibles: > + "fsl,qoriq-device-config-1.0" > + "fsl,p2041-device-config" > + "fsl,p3041-device-config" > + "fsl,p4080-device-config" > + "fsl,p5020-device-config" > + "fsl,p5040-device-config" > + "fsl,qoriq-device-config-2.0" > + "fsl,b4860-device-config" > + "fsl,b4420-device-config" > + "fsl,b4-device-config" > + "fsl,t1040-device-config" > + "fsl,t2080-device-config" > + "fsl,t4240-device-config" There's no need to list every chip here. Just list the ones that aren't chips, plus "fsl,-device-config". As for fsl,b4-device-config, does that exist in any final dtb (as opposed to b4si-post.dtsi)? The b4420 and b4860 dtsi files both overwrite that compatible. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/dts: Add some SoC specific "fsl,*-device-config" compatibles
On Thu, 2015-04-09 at 09:21 +0300, Igal.Liberman wrote:
> From: Igal Liberman
>
> This patch is required for: https://patchwork.ozlabs.org/patch/459584/
If it's required for that patch, why aren't they part of a patchset
rather than independently posted? I don't see any mention of a
dependency in that patch, so how would I have known not to apply it?
> Signed-off-by: Igal Liberman
> ---
> arch/powerpc/boot/dts/fsl/b4420si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/b4si-post.dtsi|3 ++-
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi |3 ++-
> 7 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> index 1ea8602..9b14f24 100644
> --- a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> @@ -77,7 +77,8 @@
> };
>
> guts: global-utilities@e {
> - compatible = "fsl,b4420-device-config",
> "fsl,qoriq-device-config-2.0";
> + compatible = "fsl,b4420-device-config", "fsl,b4-device-config",
> + "fsl,qoriq-device-config-2.0";
Why?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4 v2] powerpc/fsl-booke: Add device tree support for T1024/T1023 SoC
On Wed, 2015-04-08 at 18:46 +0800, Shengzhou Liu wrote:
> + clockgen: global-utilities@e1000 {
> + compatible = "fsl,t1023-clockgen", "fsl,qoriq-clockgen-2.0",
> +"fixed-clock";
> + reg = <0xe1000 0x1000>;
> + clock-output-names = "sysclk";
> + #clock-cells = <0>;
Why aren't you using qoriq-clockgen2.dtsi? Where is ranges?
We've been putting the sysclk in its own node, though even after reading
the discussion in http://patchwork.ozlabs.org/patch/274134/ and
http://patchwork.ozlabs.org/patch/290226/ I still don't know what was
wrong with the unified approach.
> + data-only@0 {
> + compatible = "fsl,qe-muram-data",
> + "fsl,cpm-muram-data";
> + reg = <0x0 0x6000>;
Whitespace.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Wed, 2015-04-08 at 10:43 +0300, Igal.Liberman wrote: > @@ -76,6 +77,52 @@ Required properties: > > Recommended properties: > - clocks: Should be the phandle of input parent clock > + For "fsl,fman-clk-mux" clock there are several options for parent > + clock (clock provider), the parent is determined according to the > + Reset Configuration Word of the specific device: > + * P2041, P3041: > + * 0 - equal to platform PLL divided by 2 > + * 1 - equal to PLL2 divided by 2 > + * P4080 (Both FMans): > + * 0 - equal to platform PLL divided by 2 > + * 1 - equal to PLL3 divided by 2 ... Again, the clock specifier format is determined by the clock provider, not the clock consumer. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Sun, 2015-04-12 at 10:54 -0500, Liberman Igal-B31950 wrote: > > > Regards, > Igal Liberman. > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Thursday, April 09, 2015 8:03 PM > > To: Liberman Igal-B31950 > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > > Subject: Re: [v2] dt/bindings: qoriq-clock: Add binding for FMan clock mux > > > > On Thu, 2015-04-09 at 02:18 -0500, Liberman Igal-B31950 wrote: > > > > > > > > > Regards, > > > Igal Liberman. > > > > > > > -Original Message- > > > > From: Wood Scott-B07421 > > > > Sent: Thursday, April 09, 2015 12:12 AM > > > > To: Liberman Igal-B31950 > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > > > > Subject: Re: [v2] dt/bindings: qoriq-clock: Add binding for FMan > > > > clock mux > > > > > > > > On Wed, 2015-04-08 at 10:43 +0300, Igal.Liberman wrote: > > > > > @@ -76,6 +77,52 @@ Required properties: > > > > > > > > > > Recommended properties: > > > > > - clocks: Should be the phandle of input parent clock > > > > > + For "fsl,fman-clk-mux" clock there are several options for > > > > > parent > > > > > + clock (clock provider), the parent is determined according to > > > > > the > > > > > + Reset Configuration Word of the specific device: > > > > > + * P2041, P3041: > > > > > + * 0 - equal to platform PLL divided by 2 > > > > > + * 1 - equal to PLL2 divided by 2 > > > > > + * P4080 (Both FMans): > > > > > + * 0 - equal to platform PLL divided by 2 > > > > > + * 1 - equal to PLL3 divided by 2 > > > > ... > > > > > > > > > > > > Again, the clock specifier format is determined by the clock > > > > provider, not the clock consumer. > > > > > > > > > > Scott, > > > The "clocks" property contains all possible clock providers, right? > > > In the text above I'm trying to explain how the FMan clock provider is > > determined and what are the options for each SoC. > > > Do you think that we shouldn't have this explanation? Can you please > > elaborate? > > > > I'm saying that the clock specifiers must be the same regardless of the node > > that is consuming the clock. You can't define certain values as only being > > "for > > fsl,fman-clk-mux". > > > > Just to make things clear, > In "fm0clk/fm1clk" node, "clocks" holds a list of clock specifiers. > This list reflects all optional clock providers for a specific hardware, this > list varies between different SoCs. > All those possible providers described by other nodes, as clock providers. > Please notice that this bindings describes the possible source clock for FMan > mux, not the providers themselves. > > You mentioned the following: "You can't define certain values as only being > "for fsl,fman-clk-mux"." > I'm defining those values in the clock provider nodes and using those values > as clock providers for FMan mux, it can be used be other HW blocks too. My point is that the encoding of the clock specifier is not fman-specific and thus fman should not appear in the description. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3, 01/11] powerpc/8xx: remove remaining unnecessary code in FixupDAR
On Sun, 2015-04-12 at 18:16 +0200, leroy christophe wrote:
>
> Le 26/03/2015 22:32, Scott Wood a écrit :
> > On Tue, Feb 03, 2015 at 12:38:16PM +0100, LEROY Christophe wrote:
> >> Since commit 33fb845a6f01 ("powerpc/8xx: Don't use MD_TWC for walk"),
> >> MD_EPN and
> >> MD_TWC are not writen anymore in FixupDAR so saving r3 has become useless.
> >>
> >> Signed-off-by: Christophe Leroy
> >> ---
> >> v2: no change
> >> v3: no change
> > This doesn't apply cleanly.
> >
> >
> You already applied part of that patchset it in your next tree,
> including that one (commit 2374d0a).
> You told me to re-submit a patchset with only the remaining ones,
> therefore I sent v4 on the 4th of Feb, based on your tree.
OK. I applied v2, and didn't remember that when I came across v3 in
patchwork.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4 v2] powerpc/fsl-booke: Add device tree support for T1024/T1023 SoC
On Thu, 2015-04-09 at 01:29 -0500, Liu Shengzhou-B36685 wrote:
> > > +&soc {
> > > +/include/ "qoriq-tdm1.0.dtsi"
> >
> > Where is this file? Is there some dependency you've forgotten to mention?
> >
> > If this is meant to apply after
> > http://patchwork.ozlabs.org/patch/457605/
> > is that really QUICC engine TDM as described in the comment above?
> >
> > -Scott
> Yes, it depends on http://patchwork.ozlabs.org/patch/457605/
> right that's really QUICC engine TDM.
That doesn't look like anything related to the QUICC engine, and CCSR
offset 0x185000 is reserved in the t1024 manual.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] powerpc/dts: Add some SoC specific "fsl,*-device-config" compatibles
On Tue, 2015-04-14 at 13:25 +0300, Igal.Liberman wrote:
> From: Igal Liberman
>
> This patch adds "fsl,-device-config" compatibles to guts node.
> The added compatibles used in Freescale FMan clock initialization.
>
> This patches is described by the following binding document update:
> https://patchwork.ozlabs.org/patch/461153/
>
> v2: Updated commit message
>
> Signed-off-by: Igal Liberman
> ---
> arch/powerpc/boot/dts/fsl/b4420si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/b4si-post.dtsi|3 ++-
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi |3 ++-
> 7 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> index 1ea8602..9b14f24 100644
> --- a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> @@ -77,7 +77,8 @@
> };
>
> guts: global-utilities@e {
> - compatible = "fsl,b4420-device-config",
> "fsl,qoriq-device-config-2.0";
> + compatible = "fsl,b4420-device-config", "fsl,b4-device-config",
> + "fsl,qoriq-device-config-2.0";
> };
I thought you said you were going to drop this? Please just use the
existing compatibles.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] dt/bindings: qoriq-clock: Update core PLL binding
On Tue, 2015-04-14 at 12:42 +0300, Igal.Liberman wrote: > From: Igal Liberman > > Added optional divider to "fsl,qoriq-core-pll-2.0". > This option might be used by Freescale hardware accelerators. > > Signed-off-by: Igal Liberman > --- > .../devicetree/bindings/clock/qoriq-clock.txt |8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt > b/Documentation/devicetree/bindings/clock/qoriq-clock.txt > index df4a259..b0d7b73 100644 > --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt > +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt > @@ -68,11 +68,17 @@ Required properties: > - #clock-cells: From common clock binding. The number of cells in a > clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0" > clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks. > - For "fsl,qoriq-core-pll-[1,2].0" clocks, the single > + For "fsl,qoriq-core-pll-1.0" clocks, the single > clock-specifier cell may take the following values: > * 0 - equal to the PLL frequency > * 1 - equal to the PLL frequency divided by 2 > * 2 - equal to the PLL frequency divided by 4 > + For "fsl,qoriq-core-pll-2.0" clocks, the single > + clock-specifier cell may take the following values: > + * 0 - equal to the PLL frequency > + * 1 - equal to the PLL frequency divided by 2 > + * 2 - equal to the PLL frequency divided by 3 > + * 3 - equal to the PLL frequency divided by 4 Thanks. Please update the driver to use the compatible to distinguish as documented above, rather than the number of clock-output-names. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/dts: Update the core cluster PLL node(s)
On Tue, 2015-04-14 at 12:55 +0300, Igal.Liberman wrote:
> From: Igal Liberman
>
> This patch replaces the following:
> https://patchwork.ozlabs.org/patch/427664/
>
> This patch is described by the following binding document update:
> https://patchwork.ozlabs.org/patch/461150/
>
> Signed-off-by: Igal Liberman
> ---
> arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> index 48e0b6e..7e1f074 100644
> --- a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> @@ -49,14 +49,16 @@ global-utilities@e1000 {
> reg = <0x800 0x4>;
> compatible = "fsl,qoriq-core-pll-2.0";
> clocks = <&sysclk>;
> - clock-output-names = "pll0", "pll0-div2", "pll0-div4";
> + clock-output-names = "pll0", "pll0-div2", "pll0-div3",
> + "pll0-div4";
> };
> pll1: pll1@820 {
> #clock-cells = <1>;
> reg = <0x820 0x4>;
> compatible = "fsl,qoriq-core-pll-2.0";
> clocks = <&sysclk>;
> - clock-output-names = "pll1", "pll1-div2", "pll1-div4";
> + clock-output-names = "pll1", "pll1-div2", "pll1-div3",
> + "pll1-div4";
Wait, so if the driver implements the binding you submitted, you'll
break compatibility with these older device trees...
I think we need to just accept the ugly count-the-clock-names approach
and document it.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/dts: Update the core cluster PLL node(s)
On Tue, 2015-04-14 at 15:21 -0500, Scott Wood wrote:
> On Tue, 2015-04-14 at 12:55 +0300, Igal.Liberman wrote:
> > From: Igal Liberman
> >
> > This patch replaces the following:
> > https://patchwork.ozlabs.org/patch/427664/
> >
> > This patch is described by the following binding document update:
> > https://patchwork.ozlabs.org/patch/461150/
> >
> > Signed-off-by: Igal Liberman
> > ---
> > arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi |6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> > b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> > index 48e0b6e..7e1f074 100644
> > --- a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> > +++ b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> > @@ -49,14 +49,16 @@ global-utilities@e1000 {
> > reg = <0x800 0x4>;
> > compatible = "fsl,qoriq-core-pll-2.0";
> > clocks = <&sysclk>;
> > - clock-output-names = "pll0", "pll0-div2", "pll0-div4";
> > + clock-output-names = "pll0", "pll0-div2", "pll0-div3",
> > + "pll0-div4";
> > };
> > pll1: pll1@820 {
> > #clock-cells = <1>;
> > reg = <0x820 0x4>;
> > compatible = "fsl,qoriq-core-pll-2.0";
> > clocks = <&sysclk>;
> > - clock-output-names = "pll1", "pll1-div2", "pll1-div4";
> > + clock-output-names = "pll1", "pll1-div2", "pll1-div3",
> > + "pll1-div4";
>
> Wait, so if the driver implements the binding you submitted, you'll
> break compatibility with these older device trees...
>
> I think we need to just accept the ugly count-the-clock-names approach
> and document it.
Is there any current 2.0 clock consumer that references pll-div4?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] dt/bindings: fsl/guts: Added global-utilities compatibles
On Tue, 2015-04-14 at 13:12 +0300, Igal.Liberman wrote: > From: Igal Liberman > > v2 - Addressed Scott's feedback > > Signed-off-by: Igal Liberman > --- > .../devicetree/bindings/powerpc/fsl/guts.txt |4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > index 7f150b5..69644e6 100644 > --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > +++ b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > @@ -9,6 +9,10 @@ Required properties: > > - compatible : Should define the compatible device type for > global-utilities. > + Possible compatibles: > + "fsl,qoriq-device-config-1.0" > + "fsl,qoriq-device-config-2.0" > + "fsl,-device-config" fsl,-guts is also possible on non-corenet chips. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/3][PATCH][v2] Device Tree bindings for Freescale TDM controller
On Tue, 2015-04-14 at 08:50 -0500, Singh Sandeep-B37400 wrote:
> > > +TDM (Time Division Multiplexing)
> > > +
> > > +DESCRIPTION
> > > +
> > > +The TDM is full duplex serial port designed to allow various devices
> > > +including digital signal processors (DSPs) to communicate with a
> > > +variety of serial devices including industry standard framers, codecs,
> > > other
> > DSPs and microprocessors.
> > > +
> > > +The below properties describe the device tree bindings for Freescale
> > > +TDM controller.
> > > +This TDM controller is available on various Freescale Processors like
> > > +MPC8313, P1020, P1022 and P1010.
> > > +
> > > +PROPERTIES
> > > +
> > > + - compatible
> > > + Usage: required
> > > + Value type:
> > > + Definition: Should contain "fsl,tdm1.0".
> >
> > What does 1.0 refer to? Is the TDM block identical on all the chips that
> > currently
> > have it? Is this a real version number scheme (public or
> > otherwise) or something made up for software?
> [Sandeep] Starlite TDM block is identical on all the chips. This is a
> software only version.
Then I recommend arbitrarily picking one of the chips and naming the
compatible after that: "fsl,mpc8313-tdm".
> > > + - reg
> > > + Usage: required
> > > + Definition: A standard property. The first reg specifier describes
> > > the
> > > + TDM registers, and the second describes the TDM DMAC registers.
> > > +
> > > + - clock-frequency
> > > + Usage: optional
> > > + Value type:
> > > + Definition: The frequency at which the TDM block is operating.
> >
> > It'd be nice if new bindings used clock nodes rather than relying on U-Boot
> > fixups.
> [Sandeep] This field is not currently used, but is planned to be used in
> future.
I don't see how that answers my request.
> > > +EXAMPLE
> > > +
> > > + tdm@16000 {
> > > + compatible = "fsl,tdm1.0";
> > > + reg = <0x16000 0x200 0x2c000 0x2000>;
> > > + clock-frequency = <0>;
> > > + interrupts = <16 8 62 8>;
> > > + phy-handle = <&zarlink1>;
> > > + fsl,max-time-slots = <128>;
> > > + };
> >
> > The example refers to a "zarlink1" node but it is not present. What does a
> > "line
> > controller or framer node" look like?
> [Sandeep] phy-handle again is currently not being used. Added for future use.
Please submit a complete binding.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3, 01/11] powerpc/8xx: remove remaining unnecessary code in FixupDAR
On Tue, 2015-04-14 at 00:19 +0200, leroy christophe wrote:
>
> Le 13/04/2015 22:26, Scott Wood a écrit :
> > On Sun, 2015-04-12 at 18:16 +0200, leroy christophe wrote:
> >> Le 26/03/2015 22:32, Scott Wood a écrit :
> >>> On Tue, Feb 03, 2015 at 12:38:16PM +0100, LEROY Christophe wrote:
> >>>> Since commit 33fb845a6f01 ("powerpc/8xx: Don't use MD_TWC for walk"),
> >>>> MD_EPN and
> >>>> MD_TWC are not writen anymore in FixupDAR so saving r3 has become
> >>>> useless.
> >>>>
> >>>> Signed-off-by: Christophe Leroy
> >>>> ---
> >>>> v2: no change
> >>>> v3: no change
> >>> This doesn't apply cleanly.
> >>>
> >>>
> >> You already applied part of that patchset it in your next tree,
> >> including that one (commit 2374d0a).
> >> You told me to re-submit a patchset with only the remaining ones,
> >> therefore I sent v4 on the 4th of Feb, based on your tree.
> > OK. I applied v2, and didn't remember that when I came across v3 in
> > patchwork.
> >
> >
> What about v4 (the remaining ones) ? You got comments on the last one of
> the set, have you applied the other ones or shall I re-sumbit a full v5 ?
I haven't applied them yet.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3] clk: qoriq: Add support for the FMan clock
On Tue, 2015-04-14 at 14:15 +0300, Igal.Liberman wrote:
> +static int get_fm_clk_idx(int fm_id, int *fm_clk_idx)
> +{
> + struct ccsr_guts __iomem *guts_regs = NULL;
> + struct device_node *guts;
> + uint32_t reg = 0;
> + int clk_src = 0;
> +
> + guts = of_find_matching_node(NULL, guts_device_ids);
> + if (!guts) {
> + pr_err("could not find GUTS node\n");
> + return -ENODEV;
> + }
> +
> + guts_regs = of_iomap(guts, 0);
> + of_node_put(guts);
> + if (!guts_regs) {
> + pr_err("ioremap of GUTS node failed\n");
> + return -ENODEV;
> + }
Error messages should include more context -- at least __func__.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/dts: Update the core cluster PLL node(s)
On Wed, 2015-04-15 at 06:07 -0500, Liberman Igal-B31950 wrote:
>
>
> Regards,
> Igal Liberman.
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, April 14, 2015 11:23 PM
> > To: Liberman Igal-B31950
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH] powerpc/dts: Update the core cluster PLL node(s)
> >
> > On Tue, 2015-04-14 at 15:21 -0500, Scott Wood wrote:
> > > On Tue, 2015-04-14 at 12:55 +0300, Igal.Liberman wrote:
> > > > From: Igal Liberman
> > > >
> > > > This patch replaces the following:
> > > > https://patchwork.ozlabs.org/patch/427664/
> > > >
> > > > This patch is described by the following binding document update:
> > > > https://patchwork.ozlabs.org/patch/461150/
> > > >
> > > > Signed-off-by: Igal Liberman
> > > > ---
> > > > arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi |6 --
> > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> > > > b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> > > > index 48e0b6e..7e1f074 100644
> > > > --- a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> > > > +++ b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
> > > > @@ -49,14 +49,16 @@ global-utilities@e1000 {
> > > > reg = <0x800 0x4>;
> > > > compatible = "fsl,qoriq-core-pll-2.0";
> > > > clocks = <&sysclk>;
> > > > - clock-output-names = "pll0", "pll0-div2", "pll0-div4";
> > > > + clock-output-names = "pll0", "pll0-div2", "pll0-div3",
> > > > + "pll0-div4";
> > > > };
> > > > pll1: pll1@820 {
> > > > #clock-cells = <1>;
> > > > reg = <0x820 0x4>;
> > > > compatible = "fsl,qoriq-core-pll-2.0";
> > > > clocks = <&sysclk>;
> > > > - clock-output-names = "pll1", "pll1-div2", "pll1-div4";
> > > > + clock-output-names = "pll1", "pll1-div2", "pll1-div3",
> > > > + "pll1-div4";
> > >
> > > Wait, so if the driver implements the binding you submitted, you'll
> > > break compatibility with these older device trees...
> > >
> > > I think we need to just accept the ugly count-the-clock-names approach
> > > and document it.
> >
> > Is there any current 2.0 clock consumer that references pll-div4?
> >
>
> I looked at T4240 for example, there's a mux node which adds pll-div4 option:
> mux0: mux0@0 {
> #clock-cells = <0>;
> reg = <0x0 0x4>;
> compatible = "fsl,qoriq-core-mux-2.0";
> clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
> <&pll1 0>, <&pll1 1>, <&pll1 2>,
> <&pll2 0>, <&pll2 1>, <&pll2 2>;
> clock-names = "pll0", "pll0-div2", "pll0-div4",
> "pll1", "pll1-div2", "pll1-div4",
> "pll2", "pll2-div2", "pll2-div4";
> clock-output-names = "cmux0";
> };
>
> After this change <&pll0 2> will represent "pll0-div3" and not "pll0-div4".
So this needs to be updated to match -- and it confirms that existing
device trees will be broken if you base the interpretation on compatible
rather than the number of clock-output-names.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] dt/bindings: fsl/guts: Added global-utilities compatibles
On Wed, 2015-04-15 at 03:43 -0500, Liberman Igal-B31950 wrote: > > > Regards, > Igal Liberman. > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Tuesday, April 14, 2015 11:09 PM > > To: Liberman Igal-B31950 > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > > Subject: Re: [v2] dt/bindings: fsl/guts: Added global-utilities compatibles > > > > On Tue, 2015-04-14 at 13:12 +0300, Igal.Liberman wrote: > > > From: Igal Liberman > > > > > > v2 - Addressed Scott's feedback > > > > > > Signed-off-by: Igal Liberman > > > --- > > > .../devicetree/bindings/powerpc/fsl/guts.txt |4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > > b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > > > index 7f150b5..69644e6 100644 > > > --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > > > +++ b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt > > > @@ -9,6 +9,10 @@ Required properties: > > > > > > - compatible : Should define the compatible device type for > > > global-utilities. > > > + Possible compatibles: > > > + "fsl,qoriq-device-config-1.0" > > > + "fsl,qoriq-device-config-2.0" > > > + "fsl,-device-config" > > > > fsl,-guts is also possible on non-corenet chips. > > > > I added compatibles which are used for FMan Clock only. > Do you want to add other compatibles too? Which? Or just mention that the 3 > compatibles I've added doesn't cover all available options? You're changing the binding from one that doesn't list compatibles to one that does -- so please get all of them. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Tue, 2015-04-14 at 13:56 +0300, Igal.Liberman wrote:
> From: Igal Liberman
>
> v3: Addressed feedback from Scott:
> - Removed clock specifier description.
>
> v2: Addressed feedback from Scott:
> - Moved the "fman-clk-mux" clock provider details
> under "clocks" property.
>
> Signed-off-by: Igal Liberman
> ---
> .../devicetree/bindings/clock/qoriq-clock.txt | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> index b0d7b73..2bb3b38 100644
> --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> @@ -65,9 +65,10 @@ Required properties:
> It takes parent's clock-frequency as its clock.
> * "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0)
> * "fsl,qoriq-platform-pll-2.0" for the platform PLL clock (v2.0)
> + * "fsl,fman-clk-mux" for the Frame Manager clock.
> - #clock-cells: From common clock binding. The number of cells in a
> - clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
> - clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
> + clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0" and
> + "fsl,fman-clk-mux" clocks or <1> for "fsl,qoriq-core-pll-[1,2].0".
> For "fsl,qoriq-core-pll-1.0" clocks, the single
> clock-specifier cell may take the following values:
> * 0 - equal to the PLL frequency
> @@ -145,6 +146,18 @@ Example for clock block and clock provider:
> clocks = <&sysclk>;
> clock-output-names = "platform-pll",
> "platform-pll-div2";
> };
> +
> + fm0clk: fm0-clk-mux {
> + #clock-cells = <0>;
> + reg = <0x10 4>
> + compatible = "fsl,fman-clk-mux";
> + clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>, <&pll0 3>,
> + <&platform_pll 0>, <&pll1 1>, <&pll1 2>;
> + clock-names = "pll0", "pll0-div2", "pll0-div3",
> + "pll0-div4", "platform-pll", "pll1-div2",
> + "pll1-div3";
> + clock-output-names = "fm0-clk";
> + };
> };
> };
>
I don't see this register in the manuals for older DPAA chips, such as
p4080 or p3041. Is it present but undocumented? Should I be looking
somewhere other than "Clocking Memory Map"?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Pull request: scottwood/linux.git master
This is a fix to a 4.0 regression that causes hugetlb use on PPC to emit kernel output such as "BUG: non-zero nr_pmds on freeing mm: 1" The following changes since commit 39a8804455fb23f09157341d3ba7db6d7ae6ee76: Linux 4.0 (2015-04-12 15:12:50 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git master for you to fetch changes up to 50c6a665b383cb5839e45d04e36faeeefaffa052: powerpc/hugetlb: Call mm_dec_nr_pmds() in hugetlb_free_pmd_range() (2015-04-15 15:24:22 -0500) -------- Scott Wood (1): powerpc/hugetlb: Call mm_dec_nr_pmds() in hugetlb_free_pmd_range() arch/powerpc/mm/hugetlbpage.c | 1 + 1 file changed, 1 insertion(+) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mm: Don't call __flush_dcache_icache_phys() with PA>VA
__flush_dcache_icache_phys() requires the ability to access the
memory with the MMU disabled, which means that on a 32-bit system
any memory above 4 GiB is inaccessible. In particular, mpc86xx is
32-bit and can have more than 4 GiB of RAM.
Signed-off-by: Scott Wood
---
arch/powerpc/include/asm/cacheflush.h | 7 ++-
arch/powerpc/mm/mem.c | 14 +++---
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 30b35ff..6229e6b 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -40,7 +40,12 @@ extern void __flush_dcache_icache(void *page_va);
extern void flush_dcache_icache_page(struct page *page);
#if defined(CONFIG_PPC32) && !defined(CONFIG_BOOKE)
extern void __flush_dcache_icache_phys(unsigned long physaddr);
-#endif /* CONFIG_PPC32 && !CONFIG_BOOKE */
+#else
+static inline void __flush_dcache_icache_phys(unsigned long physaddr)
+{
+ BUG();
+}
+#endif
extern void flush_dcache_range(unsigned long start, unsigned long stop);
#ifdef CONFIG_PPC32
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index b7285a5..7297d204 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -417,17 +417,17 @@ void flush_dcache_icache_page(struct page *page)
return;
}
#endif
-#ifdef CONFIG_BOOKE
- {
+#if defined(CONFIG_8xx) || defined(CONFIG_PPC64)
+ /* On 8xx there is no need to kmap since highmem is not supported */
+ __flush_dcache_icache(page_address(page));
+#else
+ if (IS_ENABLED(CONFIG_BOOKE) || sizeof(phys_addr_t) > sizeof(void *)) {
void *start = kmap_atomic(page);
__flush_dcache_icache(start);
kunmap_atomic(start);
+ } else {
+ __flush_dcache_icache_phys(page_to_pfn(page) << PAGE_SHIFT);
}
-#elif defined(CONFIG_8xx) || defined(CONFIG_PPC64)
- /* On 8xx there is no need to kmap since highmem is not supported */
- __flush_dcache_icache(page_address(page));
-#else
- __flush_dcache_icache_phys(page_to_pfn(page) << PAGE_SHIFT);
#endif
}
EXPORT_SYMBOL(flush_dcache_icache_page);
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Thu, 2015-04-16 at 00:44 -0400, Bob Cochran wrote: > As you probably know, Freescale makes use of the Yocto Project build > system for its SDK and submits patches to the SDK at a public > meta-fsl-ppc repo at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/ > > I have seen some kernel related patches in the past come across the > Yocto Project site that made use of the Yocto Project kernel tools, > which includes a process for maintaining kernel configuration fragments. > It sounds like the requirements you have could be met with Yocto's > existing process. > > I was hoping to see Freescale continue to move in the direction of using > the Yocto kernel tools rather than roll its own solution. > > The Yocto kernel tools make use of description files (*.scc) and > configuration fragments (*.cfg). We do use Yocto for our SDK, but there's always going to be a need to be able to build kernels outside of Yocto. The kernel should be self-contained regarding its own configuration. merge_config.sh isn't "rolling our own solution". It's a standard kernel tool. x86 already has a couple config fragments defined. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Old regression with MTD devices disappearing from a Kurobox HD/HG
On Thu, 2015-04-16 at 19:55 -0300, Rogério Brito wrote: > Hi, Scott and others. > > On Apr 09 2015, Rogério Brito wrote: > > On Apr 09 2015, Scott Wood wrote: > > > On Thu, 2015-04-09 at 18:54 -0300, Rogério Brito wrote: > > > > > > > > mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) > > > > > > What is "myflash"? You need to match the device name that the kernel > > > uses. > > > > From the documentation that I read, it *seemed* to be an arbitrary name and, > > to be screamingly different from anything else, I just picked "myflash". > > So, in my case (see dmesg snippet below), I would use "physmap-flash.0", > > right? Or would that be "physmap-flash"? Or something else entirely? > > Is there any "proper" way for me to discover what device name the kernel > uses? I have tried the following command lines without success: > > 1 - > mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) > 2 - > mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) > 3 - > mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) Look in sysfs. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Old regression with MTD devices disappearing from a Kurobox HD/HG
On Thu, 2015-04-16 at 21:01 -0300, Rogério Brito wrote: > Dear Scott. > > On Apr 16 2015, Scott Wood wrote: > > On Thu, 2015-04-16 at 19:55 -0300, Rogério Brito wrote: > > > Is there any "proper" way for me to discover what device name the kernel > > > uses? I have tried the following command lines without success: > > > > > > 1 - > > > mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) > > > 2 - > > > mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) > > > 3 - > > > mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) > > > > Look in sysfs. > > The output that I get from sysfs is: > > # ls -l /sys/block/mtdblock0 > lrwxrwxrwx 1 root root 0 Apr 16 20:42 /sys/block/mtdblock0 -> > ../devices/platform/physmap-flash.0/mtd/mtd0/mtdblock0 > # cat /sys/devices/platform/physmap-flash.0/uevent > DRIVER=physmap-flash > MODALIAS=platform:physmap-flash > # cat /sys/devices/platform/physmap-flash.0/driver_override > (null) > > So, it is saying that the driver is physmap-flash, right? It looks like the device name is "physmap-flash.0". You're partitioning the device, not the driver. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Fri, 2015-04-17 at 10:54 +1000, Michael Ellerman wrote: > On Thu, 2015-04-09 at 21:52 +, Lijun Pan wrote: > > Hi Maintainers, > > > > We have a proposal for writing the defconfigs for freescale's powperpc > > platforms in a new way. > > Can you take a look and provide some feedback? > > > > You know currently we have mpc85xx_defconfig, corenet32_defconfig, > > bsc913x_defconfig, *fman*_defconfig, etc. > > We are going to extract some common parts from the existing defconfigs, and > > name it, say, fsl_basic_defconfig. > > Then, we could create some defconfigs targeting specific features or > > specific platforms. > > Say, features specific: kvm_defconfig, fman_defconfig, etc. > > Platforms specific: p1_defconfig, p2_defcongfig, p4_defconfig, > > t1_defconfig, t2_defconfig, t2_defconfig, b4_defconfig, etc > > When we want to make a kernel image for p1 platform, > > Using the following steps: > > > > make ./scripts/kconfig/merge_config.sh > > arch/powerpc/configs/fsl_basic_config p1_defconfig > > make > > > > What do you think of this new approach? > > I don't like that the user has to manually run merge_config.sh. > > How does a user even know that it's an option? > > It also breaks scripts that auto build the kernel, which expect to be able to > do: > > $ make foo_defconfig > $ make > > Scripts like mine for example :) > > http://kisskb.ellerman.id.au/kisskb/head/8734/ > > What I'd be happy with is something that does merge_config under the covers. > So > a user still runs 'make fsl_plat_foo_defconfig', but under the covers it does > a > merge config. > > kvmconfig and tinyconfig are implemented that way already, so with a bit more > work hopefully you can do that for arch configs also. kvmconfig and tinyconfig are still separate user-visible steps to be applied after running a base defconfig. For breaking a platform defconfig into components, we could do something like this in arch/powerpc/Makefile: # Can't call mergeconfig directly as it isn't defined at this point define domerge @$(MAKE) -f $(srctree)/scripts/kconfig/Makefile $(1).config endef corenet64_smp_defconfig: corenet64_basic_defconfig $(call domerge,smp) $(call domerge,altivec) $(call domerge,corenet_drivers) $(call domerge,embedded_misc) # filesystems etc And this in scripts/kconfig/Makefile: %.config: $(call mergeconfig,$*) One issue with this is that we'd lose the ability to use savedefconfig (at least without manual manipulation of the results) to maintain the defconfigs/fragments. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Thu, 2015-04-16 at 01:11 -0500, Liberman Igal-B31950 wrote:
>
>
> Regards,
> Igal Liberman.
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, April 15, 2015 8:36 PM
> > To: Liberman Igal-B31950
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
> >
> > On Tue, 2015-04-14 at 13:56 +0300, Igal.Liberman wrote:
> > > From: Igal Liberman
> > >
> > > v3: Addressed feedback from Scott:
> > > - Removed clock specifier description.
> > >
> > > v2: Addressed feedback from Scott:
> > > - Moved the "fman-clk-mux" clock provider details
> > > under "clocks" property.
> > >
> > > Signed-off-by: Igal Liberman
> > > ---
> > > .../devicetree/bindings/clock/qoriq-clock.txt | 17
> > > +++--
> > > 1 file changed, 15 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > > b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > > index b0d7b73..2bb3b38 100644
> > > --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > > +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > > @@ -65,9 +65,10 @@ Required properties:
> > > It takes parent's clock-frequency as its clock.
> > > * "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0)
> > > * "fsl,qoriq-platform-pll-2.0" for the platform PLL clock (v2.0)
> > > + * "fsl,fman-clk-mux" for the Frame Manager clock.
> > > - #clock-cells: From common clock binding. The number of cells in a
> > > - clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
> > > - clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
> > > + clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0" and
> > > + "fsl,fman-clk-mux" clocks or <1> for "fsl,qoriq-core-pll-[1,2].0".
> > > For "fsl,qoriq-core-pll-1.0" clocks, the single
> > > clock-specifier cell may take the following values:
> > > * 0 - equal to the PLL frequency
> > > @@ -145,6 +146,18 @@ Example for clock block and clock provider:
> > > clocks = <&sysclk>;
> > > clock-output-names = "platform-pll", "platform-pll-
> > div2";
> > > };
> > > +
> > > + fm0clk: fm0-clk-mux {
> > > + #clock-cells = <0>;
> > > + reg = <0x10 4>
> > > + compatible = "fsl,fman-clk-mux";
> > > + clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>, <&pll0 3>,
> > > + <&platform_pll 0>, <&pll1 1>, <&pll1 2>;
> > > + clock-names = "pll0", "pll0-div2", "pll0-div3",
> > > + "pll0-div4", "platform-pll", "pll1-div2",
> > > + "pll1-div3";
> > > + clock-output-names = "fm0-clk";
> > > + };
> > > };
> > > };
> > >
> >
> > I don't see this register in the manuals for older DPAA chips, such as
> > p4080 or p3041. Is it present but undocumented? Should I be looking
> > somewhere other than "Clocking Memory Map"?
> >
>
> It's available only in part of the new chips (T4, T2, B4).
> In T1024/T1040 there's only one option for FMan clock so this register is not
> available.
So it's part of the 2.0 chassis? I'd stick a 2.0 in there, then. Who
knows what we may see in the future.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/dts: Move pll0/1-div4 index
On Thu, 2015-04-16 at 15:08 +0300, Igal.Liberman wrote: > From: Igal Liberman > > This patch updates pll0/1-div4 index to '3'. > Originally it was '2'. > > The following patch adds pll0/1-div3 option: > https://patchwork.ozlabs.org/patch/461151/ > After this patch, index '2' becomes pll0/1-div3. > > This patch based on top of the following: > https://patchwork.ozlabs.org/patch/461811/ > > Signed-off-by: Igal Liberman This needs to be done in the same patch as the provider change, to avoid a buggy intermediate state. Will there be a new binding patch coming? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 0/5] powerpc8xx: Further optimisation of TLB handling
On Fri, 2015-04-17 at 18:32 +0200, root wrote: > This patchset provides a further optimisation of TLB handling in the 8xx. > Changes are: > - Not saving registers like CR when not needed > - Adding support to any TASK_SIZE > > Only the last patch of the set is changed compared to v4 > > Christophe Leroy (5): > powerpc/8xx: macro for handling CPU15 errata > powerpc/8xx: Handle CR out of exception PROLOG/EPILOG > powerpc/8xx: dont save CR in SCRATCH registers > powerpc/8xx: Use SPRG2 instead of DAR for saving r3 > powerpc/8xx: Add support for TASK_SIZE greater than 0x8000 > > arch/powerpc/kernel/head_8xx.S | 79 > +++--- > 1 file changed, 51 insertions(+), 28 deletions(-) > Do you really want your name in the git history to be "root"? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Fri, 2015-04-17 at 13:50 -0500, Pan Lijun-B44306 wrote: > > > > -Original Message- > > From: Michael Ellerman [mailto:m...@ellerman.id.au] > > Sent: Friday, April 17, 2015 1:19 AM > > To: Wood Scott-B07421 > > Cc: Pan Lijun-B44306; linuxppc-...@ozlabs.org; Schmitt Richard-B43082 > > Subject: Re: new way of writing defconfigs for freescale's powerpc platforms > > > > On Thu, 2015-04-16 at 23:13 -0500, Scott Wood wrote: > > > On Fri, 2015-04-17 at 10:54 +1000, Michael Ellerman wrote: > > > > On Thu, 2015-04-09 at 21:52 +, Lijun Pan wrote: > > > > > Hi Maintainers, > > > > > > > > > > We have a proposal for writing the defconfigs for freescale's powperpc > > platforms in a new way. > > > > > Can you take a look and provide some feedback? > > > > > > > > > > You know currently we have mpc85xx_defconfig, corenet32_defconfig, > > bsc913x_defconfig, *fman*_defconfig, etc. > > > > > We are going to extract some common parts from the existing > > > > > defconfigs, > > and name it, say, fsl_basic_defconfig. > > > > > Then, we could create some defconfigs targeting specific features or > > specific platforms. > > > > > Say, features specific: kvm_defconfig, fman_defconfig, etc. > > > > > Platforms specific: p1_defconfig, p2_defcongfig, p4_defconfig, > > > > > t1_defconfig, t2_defconfig, t2_defconfig, b4_defconfig, etc When > > > > > we want to make a kernel image for p1 platform, Using the following > > steps: > > > > > > > > > > make ./scripts/kconfig/merge_config.sh > > > > > arch/powerpc/configs/fsl_basic_config p1_defconfig make > > > > > > > > > > What do you think of this new approach? > > > > > > > > I don't like that the user has to manually run merge_config.sh. > > > > > > > > How does a user even know that it's an option? > > > > > > > > It also breaks scripts that auto build the kernel, which expect to be > > > > able to > > do: > > > > > > > > $ make foo_defconfig > > > > $ make > > > > > > > > Scripts like mine for example :) > > > > > > > > http://kisskb.ellerman.id.au/kisskb/head/8734/ > > > > > > > > What I'd be happy with is something that does merge_config under the > > > > covers. So a user still runs 'make fsl_plat_foo_defconfig', but > > > > under the covers it does a merge config. > > > > > > > > kvmconfig and tinyconfig are implemented that way already, so with a > > > > bit more work hopefully you can do that for arch configs also. > > > > > > kvmconfig and tinyconfig are still separate user-visible steps to be > > > applied after running a base defconfig. > > > > Not as of recently: > > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/scripts/kc > > onfig/Makefile?id=63a91033d52e64a22e571fe84924c0b7f21c280d > > > > Above patch is very generic. > With this patch, we don't even need to modify arch/powerpc/Makefile. > We can just add fragments (like smp.config, kvm_guest.config, etc) under > arch/powerpc/configs/ or > add platform independent config under kernel/configs/ > > example might be: > make mpc85xx_defconfig > make smp.config > make kvm_guest.config The point is that the user should not have to do that. They can if they want, but there should still be traditional named configs, which would just work differently under the hood. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mm: Use PFN_PHYS() in devmem_is_allowed()
This function can run on systems where physical addresses don't
fit in unsigned long, so make sure to use the macro that contains the
proper cast.
Signed-off-by: Scott Wood
---
arch/powerpc/mm/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 7297d204..07052d9 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -563,7 +563,7 @@ subsys_initcall(add_system_ram_resources);
*/
int devmem_is_allowed(unsigned long pfn)
{
- if (iomem_is_exclusive(pfn << PAGE_SHIFT))
+ if (iomem_is_exclusive(PFN_PHYS(pfn)))
return 0;
if (!page_is_ram(pfn))
return 1;
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [3/3] P1021RDB: Add QE TDM support
On Thu, Mar 26, 2015 at 05:16:17PM +0800, ying.zh...@freescale.com wrote:
> @@ -96,37 +102,63 @@ static void __init mpc85xx_rdb_setup_arch(void)
> #ifdef CONFIG_QUICC_ENGINE
> mpc85xx_qe_init();
> mpc85xx_qe_par_io_init();
> -#if defined(CONFIG_UCC_GETH) || defined(CONFIG_SERIAL_QE)
> - if (machine_is(p1025_rdb)) {
> - struct device_node *np;
> -
> - struct ccsr_guts __iomem *guts;
> -
> - np = of_find_node_by_name(NULL, "global-utilities");
> - if (np) {
> - guts = of_iomap(np, 0);
> - if (!guts) {
> -
> - pr_err("mpc85xx-rdb: could not map global
> utilities register\n");
> +#ifdef CONFIG_SPI_FSL_SPI
> + for_each_node_by_name(qe_spi, "spi")
> + par_io_of_config(qe_spi);
Why are you assuming that any node named "spi" is a QE SPI?
> +#endif /* CONFIG_SPI_FSL_SPI */
>
> - } else {
> - /* P1025 has pins muxed for QE and other functions. To
> - * enable QE UEC mode, we need to set bit QE0 for UCC1
> - * in Eth mode, QE0 and QE3 for UCC5 in Eth mode, QE9
> - * and QE12 for QE MII management singals in PMUXCR
> - * register.
> - */
> + np = of_find_node_by_name(NULL, "global-utilities");
> + if (np) {
> + guts = of_iomap(np, 0);
> + if (!guts)
> + pr_err("mpc85xx-rdb: could not map global %s\n",
> + "utilities register");
> + else {
Don't put a bunch of code in the else of an error check. Factor this out
to its own function and return early if you don't find what you're
looking for.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/qman: Change fsl,qman-channel-id to cell-index
It turns out that existing U-Boots will dereference NULL pointers
if the device tree does not have cell-index in the portal nodes.
No patch has yet been merged adding device tree nodes for this binding
(except a dtsi that has not yet been referenced), nor has any driver
yet been merged making use of the binding, so it's not too late to
change the binding in order to keep compatibility with existing
U-Boots.
Signed-off-by: Scott Wood
Cc: Madalin-Cristian Bucur
---
Documentation/devicetree/bindings/soc/fsl/qman-portals.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt
b/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt
index 48c4dae..47e46cc 100644
--- a/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt
@@ -47,7 +47,7 @@ PROPERTIES
For additional details about the PAMU/LIODN binding(s) see pamu.txt
-- fsl,qman-channel-id
+- cell-index
Usage: Required
Value type:
Definition: The hardware index of the channel. This can also be
@@ -136,7 +136,7 @@ The example below shows a (P4080) QMan portals
container/bus node with two porta
reg = <0x4000 0x4000>, <0x101000 0x1000>;
interrupts = <106 2 0 0>;
fsl,liodn = <3 4>;
- fsl,qman-channel-id = <1>;
+ cell-index = <1>;
fman0 {
fsl,liodn = <0x22>;
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/mpc85xx: Add FSL QorIQ DPAA QMan support to device tree(s)
From: Kumar Gala
Signed-off-by: Kumar Gala
Signed-off-by: Geoff Thorpe
Signed-off-by: Hai-Ying Wang
Signed-off-by: Chunhe Lan
Signed-off-by: Poonam Aggrwal
[Emil Medve: Sync with the upstream binding]
Signed-off-by: Emil Medve
[Scott Wood: s/fsl,qman-channel-id/cell-index]
Signed-off-by: Scott Wood
Cc: Madalin-Cristian Bucur
---
arch/powerpc/boot/dts/b4qds.dtsi | 12 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi| 69 +
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 106 +++
arch/powerpc/boot/dts/fsl/p1023si-post.dtsi| 43 +++
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi| 13 +
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi| 13 +
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi| 13 +
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi| 13 +
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi| 13 +
arch/powerpc/boot/dts/fsl/qoriq-qman1-portals.dtsi | 20 +-
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi| 78 +
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi| 126
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi| 318 +
arch/powerpc/boot/dts/kmcoge4.dts | 12 +
arch/powerpc/boot/dts/oca4080.dts | 12 +
arch/powerpc/boot/dts/p1023rdb.dts | 12 +
arch/powerpc/boot/dts/p2041rdb.dts | 12 +
arch/powerpc/boot/dts/p3041ds.dts | 12 +
arch/powerpc/boot/dts/p4080ds.dts | 12 +
arch/powerpc/boot/dts/p5020ds.dts | 12 +
arch/powerpc/boot/dts/p5040ds.dts | 12 +
arch/powerpc/boot/dts/t104xqds.dtsi| 12 +
arch/powerpc/boot/dts/t104xrdb.dtsi| 12 +
arch/powerpc/boot/dts/t208xqds.dtsi| 12 +
arch/powerpc/boot/dts/t208xrdb.dtsi| 12 +
arch/powerpc/boot/dts/t4240qds.dts | 12 +
arch/powerpc/boot/dts/t4240rdb.dts | 12 +
27 files changed, 995 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index 24ed80d..559d006 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -106,6 +106,14 @@
size = <0 0x100>;
alignment = <0 0x100>;
};
+ qman_fqd: qman-fqd {
+ size = <0 0x40>;
+ alignment = <0 0x40>;
+ };
+ qman_pfdr: qman-pfdr {
+ size = <0 0x200>;
+ alignment = <0 0x200>;
+ };
};
dcsr: dcsr@f {
@@ -116,6 +124,10 @@
ranges = <0x0 0xf 0xf400 0x200>;
};
+ qportals: qman-portals@ff600 {
+ ranges = <0x0 0xf 0xf600 0x200>;
+ };
+
soc: soc@ffe00 {
ranges = <0x 0xf 0xfe00 0x100>;
reg = <0xf 0xfe00 0 0x1000>;
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index f35e9e0..5af90fd 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -167,6 +167,75 @@
};
};
+&qportals {
+ qportal14: qman-portal@38000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x38000 0x4000>, <0x100e000 0x1000>;
+ interrupts = <132 0x2 0 0>;
+ cell-index = <0xe>;
+ };
+ qportal15: qman-portal@3c000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x3c000 0x4000>, <0x100f000 0x1000>;
+ interrupts = <134 0x2 0 0>;
+ cell-index = <0xf>;
+ };
+ qportal16: qman-portal@4 {
+ compatible = "fsl,qman-portal";
+ reg = <0x4 0x4000>, <0x101 0x1000>;
+ interrupts = <136 0x2 0 0>;
+ cell-index = <0x10>;
+ };
+ qportal17: qman-portal@44000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x44000 0x4000>, <0x1011000 0x1000>;
+ interrupts = <138 0x2 0 0>;
+ cell-index = <0x11>;
+ };
+ qportal18: qman-portal@48000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x48000 0x4000>, <0x1012000 0x1000>;
+ interrupts = <140 0x2 0 0>;
+ cell-index = <0x12>;
+ };
+ qportal19: qman-portal@4c000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x4c000 0x4000>, <0x1013000 0x1000>;
+ interrup
Re: [PATCH] powerpc/dts: Move pll0/1-div4 index
On Mon, 2015-04-20 at 06:10 -0500, Liberman Igal-B31950 wrote: > > > Regards, > Igal Liberman. > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Friday, April 17, 2015 8:42 AM > > To: Liberman Igal-B31950 > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > > Subject: Re: [PATCH] powerpc/dts: Move pll0/1-div4 index > > > > On Thu, 2015-04-16 at 15:08 +0300, Igal.Liberman wrote: > > > From: Igal Liberman > > > > > > This patch updates pll0/1-div4 index to '3'. > > > Originally it was '2'. > > > > > > The following patch adds pll0/1-div3 option: > > > https://patchwork.ozlabs.org/patch/461151/ > > > After this patch, index '2' becomes pll0/1-div3. > > > > > > This patch based on top of the following: > > > https://patchwork.ozlabs.org/patch/461811/ > > > > > > Signed-off-by: Igal Liberman > > > > This needs to be done in the same patch as the provider change, to avoid a > > buggy intermediate state. > > > > Will there be a new binding patch coming? > > > > OK, I'll add those changes as on patch. > > Regarding the binding, > I already submitted https://patchwork.ozlabs.org/patch/461150/ Which is an incompatible change as I noted in a comment on a different patch. > Do you mean that I should add comment that the driver parses the node by > reading the number of input clocks and not the compatible? No, you should make the binding document reflect how things currently work. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Sat, 2015-04-18 at 08:46 -0500, Timur Tabi wrote: > On Fri, Apr 17, 2015 at 11:53 PM, Lijun Pan wrote: > > > Have just sent out a patch considering the previous discussion. > > http://patchwork.ozlabs.org/patch/462249/ > > [PATCH] powerpc/defconfig: new way of writing defconfig > > The ability to merge defconfigs is a feature that's been requested by > many people for a long time. Any solution should definitely NOT be > PowerPC-only. The ability to merge configs is already there. We're just talking about using that functionality. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC,1/8] soc/fman: Add FMan MURAM support
On Mon, 2015-04-20 at 03:58 -0500, Liberman Igal-B31950 wrote: > > Regards, > Igal Liberman. > > > -Original Message- > > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > > Sent: Thursday, March 12, 2015 5:57 PM > > To: Liberman Igal-B31950 > > Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org; linux- > > ker...@vger.kernel.org; Wood Scott-B07421 > > Subject: Re: [RFC,1/8] soc/fman: Add FMan MURAM support > > > > > > On Mar 11, 2015, at 12:07 AM, Igal.Liberman > > wrote: > > > > > From: Igal Liberman > > > > > > Add Frame Manager Multi-User RAM support. > > > > > > Signed-off-by: Igal Liberman > > > --- > > > drivers/soc/fsl/fman/Kconfig|1 + > > > drivers/soc/fsl/fman/Makefile |5 +- > > > drivers/soc/fsl/fman/fm_muram.c | 174 > > +++ > > > drivers/soc/fsl/fman/inc/fm_muram_ext.h | 98 + > > > 4 files changed, 276 insertions(+), 2 deletions(-) create mode 100644 > > > drivers/soc/fsl/fman/fm_muram.c create mode 100644 > > > drivers/soc/fsl/fman/inc/fm_muram_ext.h > > > > > > > use lib/genalloc instead of rheap > > > > Hi Kumar, > I looked into lib/genalloc allocator. > As far as I see, the genalloc allocator doesn't allow to control the memory > alignment when you allocate a chunk of memory. > Two important notes regarding MURAM memory: > - The allocated memory chunks should have specific alignment (might be > different in each chunk). > - The allocations must be efficient, we don't want to "waste" MURAM due to > alignment issues. If the requirement is that allocations must be size-aligned, use gen_pool_first_fit_order_align. Otherwise, improve genalloc to do what you need. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Mon, 2015-04-20 at 06:40 -0500, Liberman Igal-B31950 wrote:
>
>
> Regards,
> Igal Liberman.
>
> > -Original Message-
> > From: Liberman Igal-B31950
> > Sent: Monday, April 20, 2015 2:07 PM
> > To: Wood Scott-B07421
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > Subject: RE: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
> >
> >
> >
> > Regards,
> > Igal Liberman.
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, April 17, 2015 8:41 AM
> > > To: Liberman Igal-B31950
> > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock
> > > mux
> > >
> > > On Thu, 2015-04-16 at 01:11 -0500, Liberman Igal-B31950 wrote:
> > > >
> > > >
> > > > Regards,
> > > > Igal Liberman.
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, April 15, 2015 8:36 PM
> > > > > To: Liberman Igal-B31950
> > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan
> > > > > clock mux
> > > > >
> > > > > On Tue, 2015-04-14 at 13:56 +0300, Igal.Liberman wrote:
> > > > > > From: Igal Liberman
> > > > > >
> > > > > > v3: Addressed feedback from Scott:
> > > > > > - Removed clock specifier description.
> > > > > >
> > > > > > v2: Addressed feedback from Scott:
> > > > > > - Moved the "fman-clk-mux" clock provider details
> > > > > > under "clocks" property.
> > > > > >
> > > > > > Signed-off-by: Igal Liberman
> > > > > > ---
> > > > > > .../devicetree/bindings/clock/qoriq-clock.txt | 17
> > > +++--
> > > > > > 1 file changed, 15 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > > > > > b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > > > > > index b0d7b73..2bb3b38 100644
> > > > > > --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > > > > > +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > > > > > @@ -65,9 +65,10 @@ Required properties:
> > > > > > It takes parent's clock-frequency as its clock.
> > > > > > * "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0)
> > > > > > * "fsl,qoriq-platform-pll-2.0" for the platform PLL clock
> > > > > > (v2.0)
> > > > > > + * "fsl,fman-clk-mux" for the Frame Manager clock.
> > > > > > - #clock-cells: From common clock binding. The number of cells in a
> > > > > > - clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
> > > > > > - clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
> > > > > > + clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
> > and
> > > > > > + "fsl,fman-clk-mux" clocks or <1> for "fsl,qoriq-core-pll-
> > [1,2].0".
> > > > > > For "fsl,qoriq-core-pll-1.0" clocks, the single
> > > > > > clock-specifier cell may take the following values:
> > > > > > * 0 - equal to the PLL frequency @@ -145,6 +146,18 @@
> > Example
> > > > > > for clock block and clock provider:
> > > > > > clocks = <&sysclk>;
> > > > > > clock-output-names = "platform-pll",
> > "platform-pll-
> > > > > div2";
> > > > > > };
> > > > > > +
> > > > > > + fm0clk: fm0-clk-mux {
> > > > > > + #clock-cells = <0>;
> > > > > > + reg = <0x10 4>
> > > > > > + compatible = "fsl,fman-clk-mux";
> > > > > > + clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
> > <&pll0 3>,
> > > > > > +<&platform_pll 0>, <&pll1 1>, <&pll1
> > 2>;
> > > > > > + clock-names = "pll0", "pll0-div2", "pll0-div3",
> > > > > > + "pll0-div4", "platform-pll",
> > > > > > "pll1-
> > div2",
> > > > > > + "pll1-div3";
> > > > > > + clock-output-names = "fm0-clk";
> > > > > > + };
> > > > > > };
> > > > > > };
> > > > > >
> > > > >
> > > > > I don't see this register in the manuals for older DPAA chips,
> > > > > such as
> > > > > p4080 or p3041. Is it present but undocumented? Should I be
> > > > > looking somewhere other than "Clocking Memory Map"?
> > > > >
> > > >
> > > > It's available only in part of the new chips (T4, T2, B4).
> > > > In T1024/T1040 there's only one option for FMan clock so this
> > > > register is not
> > > available.
> > >
> > > So it's part of the 2.0 chassis? I'd stick a 2.0 in there, then. Who
> > > knows what we may see in the future.
> > >
> >
> > OK,
> > We can go with "fsl,fman-clk-mux-1/2-0.".
> > In that case, we need to update FMan nodes and the clock driver:
> > https://patchwork.ozlabs.org/patch/443973/
> > https://patchwork.ozlabs.org/patch/461813/
> > I will update those patches separately.
> >
>
>
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote: > On 10.04.2015 02:53, Scott Wood wrote: > > On Thu, 2015-04-09 at 10:44 +0300, Purcareata Bogdan wrote: > >> So at this point I was getting kinda frustrated so I decided to measure > >> the time spend in kvm_mpic_write and kvm_mpic_read. I assumed these were > >> the main entry points in the in-kernel MPIC and were basically executed > >> while holding the spinlock. The scenario was the same - 24 VCPUs guest, > >> with 24 virtio+vhost interfaces, only this time I ran 24 ping flood > >> threads to another board instead of netperf. I assumed this would impose > >> a heavier stress. > >> > >> The latencies look pretty ok, around 1-2 us on average, with the max > >> shown below: > >> > >> .kvm_mpic_read 14.560 > >> .kvm_mpic_write12.608 > >> > >> Those are also microseconds. This was run for about 15 mins. > > > > What about other entry points such as kvm_set_msi() and > > kvmppc_mpic_set_epr()? > > Thanks for the pointers! I redid the measurements, this time for the > functions > run with the openpic lock down: > > .kvm_mpic_read_internal (.kvm_mpic_read) 1.664 > .kvmppc_mpic_set_epr 6.880 > .kvm_mpic_write_internal (.kvm_mpic_write)7.840 > .openpic_msi_write (.kvm_set_msi) 10.560 > > Same scenario, 15 mins, numbers are microseconds. > > There was a weird situation for .kvmppc_mpic_set_epr - its corresponding > inner > function is kvmppc_set_epr, which is a static inline. Removing the static > inline > yields a compiler crash (Segmentation fault (core dumped) - > scripts/Makefile.build:441: recipe for target 'arch/powerpc/kvm/kvm.o' > failed), > but that's a different story, so I just let it be for now. Point is the time > may > include other work after the lock has been released, but before the function > actually returned. I noticed this was the case for .kvm_set_msi, which could > work up to 90 ms, not actually under the lock. This made me change what I'm > looking at. kvm_set_msi does pretty much nothing outside the lock -- I suspect you're measuring an interrupt that happened as soon as the lock was released. > So far it looks pretty decent. Are there any other MPIC entry points worthy > of > investigation? I don't think so. > Or perhaps a different stress scenario involving a lot of VCPUs > and external interrupts? You could instrument the MPIC code to find out how many loop iterations you maxed out on, and compare that to the theoretical maximum. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Mon, 2015-04-20 at 21:02 -0500, Timur Tabi wrote: > On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood wrote: > > > > > > The ability to merge configs is already there. We're just talking about > > using that functionality. > > Why do you need a powerpc-specific way to use merge_config.sh? Other > architectures have the same problem with defconfigs. What are you perceiving as "powerpc-specific" about what we're proposing? Are you complaining about the actual content of which fragments to use to produce which defconfigs going in arch/powerpc? > Besides, wouldn't it make more sense to define a new defconfig type, > like p1_defconfig.merge, and if you do "make p1_defconfig.merge" it > knows to call merge_config.sh? That's already there. "make .config". -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Mon, 2015-04-20 at 22:42 -0500, Timur Tabi wrote: > Scott Wood wrote: > >> > > >> >Why do you need a powerpc-specific way to use merge_config.sh? Other > >> >architectures have the same problem with defconfigs. > > > What are you perceiving as "powerpc-specific" about what we're > > proposing? > > Well, there's the subject of this thread, which is "new way of writing > defconfigs for freescale's powerpc platforms". > > > Are you complaining about the actual content of which > > fragments to use to produce which defconfigs going in arch/powerpc? > > No, I'm just trying to figure out what's powerpc-specific about Lijun's > proposal. The set of defconfigs that we're talking about refactoring to use this mechanism. > >> >Besides, wouldn't it make more sense to define a new defconfig type, > >> >like p1_defconfig.merge, and if you do "make p1_defconfig.merge" it > >> >knows to call merge_config.sh? > > > That's already there. "make .config". > > Ok, so I'm definitely confused now. I have no idea what's actually > being proposed, since apparently the ability to have merge configs > already exists. The proposal is that we make use of that mechanism. > Wouldn't it just be simpler to pass multiple defconfigs to 'make', and > then 'make' will know to call merge_config.sh on them? So instead of > > make ./scripts/kconfig/merge_config.sh > arch/powerpc/configs/fsl_basic_config p1_defconfig > make > > we can just do > > make fsl_basic_config p1_defconfig > make We want single-name config targets to still work from the user's perspective, but we want to reduce the (often imperfect) duplication under the hood. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Tue, 2015-04-21 at 08:25 -0500, Timur Tabi wrote: > Scott Wood wrote: > > We want single-name config targets to still work from the user's > > perspective, but we want to reduce the (often imperfect) duplication > > under the hood. > > Ok, then define a new Kconfig option that merge_config.sh will look for. > So in p1_defconfig, there will be this line: > > CONFIG_OTHER_DEFCONFIGS=fsl_basic_config If you want to do that go ahead. In the meantime we'll use the mechanism that already exists. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Tue, 2015-04-21 at 13:11 -0500, Timur Tabi wrote: > On 04/21/2015 12:55 PM, Scott Wood wrote: > >> > > >> >Ok, then define a new Kconfig option that merge_config.sh will look for. > >> > So in p1_defconfig, there will be this line: > >> > > >> >CONFIG_OTHER_DEFCONFIGS=fsl_basic_config > > If you want to do that go ahead. In the meantime we'll use the > > mechanism that already exists. > > Dude, you are not making any sense. If there is a mechanism that > already exists, then what are we talking about? Using it! -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/defconfig: new way of writing defconfig
On Tue, 2015-04-21 at 16:15 +1000, Michael Ellerman wrote: > On Sat, 2015-18-04 at 04:47:21 UTC, Lijun Pan wrote: > > It is always a headache dealing with different defconfigs > > though they only differ in few places. Hence we are proposing a new > > way of writing defconfig: > > So on the whole this is looking promising, some comments ... > > > 1. Define a basic defconfig say mpc85xx_basic_defconfig > > Why can't we just use mpc85xx_defconfig ? It seems like it would be good not to redefine the meaning of existing names. > > 2. Spin off as much features as possible from mpc85xx_defconfig > > and create a separate config file, say, kvm_guest.config > > > Every time we add a new feature, we don't need to change several > > defconfigs, we just add a new *.config We shouldn't do this for every new feature. That would end up with way too many config fragments. There should only be a handful based on logical groupings and/or things that are very commonly enabled/disabled. If the user wants more fine-grained control that's what menuconfig is for. > > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile > > index fc502e0..590b441 100644 > > --- a/arch/powerpc/Makefile > > +++ b/arch/powerpc/Makefile > > @@ -269,6 +269,23 @@ bootwrapper_install: > > %.dtb: scripts > > $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) > > > > +define domerge > > + $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh > > $(srctree)/.config $(srctree)/arch/powerpc/configs/$(1).config > > +endef > > Please look at mergeconfig in scripts/kconfig/Makefile. This needs to: > - deal with objtree/srctree > - run oldconfig > - can you call it mergeconfig oldconfig should be handled by the rules that call this depending on a file-based defconfig. I chose domerge to avoid conflicting with the later definition of mergeconfig in scripts/kconfig/mergeconfig (might not be an actual problem, but reusing names makes it harder to follow what's going on). I do think we should be calling scripts/kconfig/mergeconfig, as I previously suggested, instead of hardcoding this. E.g. that would allow non-arch-specific fragments in kernel/configs/ rather than only looking in arch/powerpc/configs. > > > +mpc85xx_defconfig: mpc85xx_basic_defconfig > > + @: > > + > > +mpc85xx_smp_defconfig: mpc85xx_basic_defconfig > > + $(call domerge,smp) > > + $(call domerge,kvm_guest) > > + > > +corenet32_smp_defconfig: corenet32_basic_defconfig > > + $(call domerge,smp) > > + > > +corenet64_smp_defconfig: corenet64_basic_defconfig > > + $(call domerge,smp) > > Can these be further consolidated into a corenet_defconfig and then a 32-bit > and 64-bit config? A lot of things depend on 32 versus 64 bit so I was hesitant to set that later (though in theory I guess it should be doable). I was thinking the "basic" defconfig would be truly basic, with a common corenet .config that turns on drivers and such. > > diff --git a/arch/powerpc/configs/kvm_guest.config > > b/arch/powerpc/configs/kvm_guest.config > > new file mode 100644 > > index 000..615b0a0 > > --- /dev/null > > +++ b/arch/powerpc/configs/kvm_guest.config > > @@ -0,0 +1,2 @@ > > +CONFIG_KVM_GUEST=y > > +CONFIG_PPC_QEMU_E500=y > > This isn't a general "kvm_guest" config, ie. we don't want that enabled on > 64-bit guest kernels. So can you call it kvm_e500.config or something. s/64-bit/book3s/ I guess the issue here is that the symbol is defined inside an "if", rather than with a depends, so kconfig will raise an error rather than silently ignore it on book3s builds? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: Little endian should depend on PPC64
On Tue, 2015-04-21 at 19:41 +1000, Michael Ellerman wrote: > The only little endian configuration we support is ppc64le, so we > shouldn't be asking which endian to use when building 32-bit kernels, > they are always big endian. > > Signed-off-by: Michael Ellerman > --- > arch/powerpc/platforms/Kconfig.cputype | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/powerpc/platforms/Kconfig.cputype > b/arch/powerpc/platforms/Kconfig.cputype > index 7264e91190be..12fc443b9d54 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -421,6 +421,7 @@ config CPU_BIG_ENDIAN > > config CPU_LITTLE_ENDIAN > bool "Build little endian kernel" > + depends on PPC64 > select PPC64_BOOT_WRAPPER > help > Build a little endian kernel. Shouldn't this be PPC_BOOK3S_64? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Disable building the 32-bit VDSO on little endian
On Tue, 2015-04-21 at 19:41 +1000, Michael Ellerman wrote: > diff --git a/arch/powerpc/platforms/Kconfig.cputype > b/arch/powerpc/platforms/Kconfig.cputype > index 12fc443b9d54..1324f589f43a 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -405,6 +405,16 @@ config PPC_DOORBELL > > endmenu > > +config VDSO32 > + def_bool y > + depends on PPC32 || CPU_BIG_ENDIAN > + help > + This symbol controls whether we build the 32-bit VDSO. We obviously > + want to do that if we're building a 32-bit kernel. If we're building > + a 64-bit kernel then we only want a 32-bit VDSO if we're building for > + big endian. That is because the only little endian configuration we > + support is ppc64le which is 64-bit only. Shouldn't this depend on COMPAT, and COMPAT depend on CPU_BIG_ENDIAN? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/defconfig: new way of writing defconfig
On Fri, 2015-04-17 at 23:47 -0500, Lijun Pan wrote: > diff --git a/arch/powerpc/configs/kvm_guest.config > b/arch/powerpc/configs/kvm_guest.config > new file mode 100644 > index 000..615b0a0 > --- /dev/null > +++ b/arch/powerpc/configs/kvm_guest.config > @@ -0,0 +1,2 @@ > +CONFIG_KVM_GUEST=y > +CONFIG_PPC_QEMU_E500=y > diff --git a/arch/powerpc/configs/mpc85xx_defconfig > b/arch/powerpc/configs/mpc85xx_basic_defconfig > similarity index 100% > rename from arch/powerpc/configs/mpc85xx_defconfig > rename to arch/powerpc/configs/mpc85xx_basic_defconfig If you're just renaming it then it's not basic. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On Wed, 2015-04-22 at 15:06 +0300, Purcareata Bogdan wrote:
> On 21.04.2015 03:52, Scott Wood wrote:
> > On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
> >> There was a weird situation for .kvmppc_mpic_set_epr - its corresponding
> >> inner
> >> function is kvmppc_set_epr, which is a static inline. Removing the static
> >> inline
> >> yields a compiler crash (Segmentation fault (core dumped) -
> >> scripts/Makefile.build:441: recipe for target 'arch/powerpc/kvm/kvm.o'
> >> failed),
> >> but that's a different story, so I just let it be for now. Point is the
> >> time may
> >> include other work after the lock has been released, but before the
> >> function
> >> actually returned. I noticed this was the case for .kvm_set_msi, which
> >> could
> >> work up to 90 ms, not actually under the lock. This made me change what I'm
> >> looking at.
> >
> > kvm_set_msi does pretty much nothing outside the lock -- I suspect
> > you're measuring an interrupt that happened as soon as the lock was
> > released.
>
> That's exactly right. I've seen things like a timer interrupt occuring right
> after the spinlock_irqrestore, but before kvm_set_msi actually returned.
>
> [...]
>
> >> Or perhaps a different stress scenario involving a lot of VCPUs
> >> and external interrupts?
> >
> > You could instrument the MPIC code to find out how many loop iterations
> > you maxed out on, and compare that to the theoretical maximum.
>
> Numbers are pretty low, and I'll try to explain based on my observations.
>
> The problematic section in openpic_update_irq is this [1], since it loops
> through all VCPUs, and IRQ_local_pipe further calls IRQ_check, which loops
> through all pending interrupts for a VCPU [2].
>
> The guest interfaces are virtio-vhostnet, which are based on MSI
> (/proc/interrupts in guest shows they are MSI). For external interrupts to
> the
> guest, the irq_source destmask is currently 0, and last_cpu is 0
> (unitialized),
> so [1] will go on and deliver the interrupt directly and unicast (no VCPUs
> loop).
>
> I activated the pr_debugs in arch/powerpc/kvm/mpic.c, to see how many
> interrupts
> are actually pending for the destination VCPU. At most, there were 3
> interrupts
> - n_IRQ = {224,225,226} - even for 24 flows of ping flood. I understand that
> guest virtio interrupts are cascaded over 1 or a couple of shared MSI
> interrupts.
>
> So worst case, in this scenario, was checking the priorities for 3 pending
> interrupts for 1 VCPU. Something like this (some of my prints included):
>
> [61010.582033] openpic_update_irq: destmask 1 last_cpu 0
> [61010.582034] openpic_update_irq: Only one CPU is allowed to receive this IRQ
> [61010.582036] IRQ_local_pipe: IRQ 224 active 0 was 1
> [61010.582037] IRQ_check: irq 226 set ivpr_pr=8 pr=-1
> [61010.582038] IRQ_check: irq 225 set ivpr_pr=8 pr=-1
> [61010.582039] IRQ_check: irq 224 set ivpr_pr=8 pr=-1
>
> It would be really helpful to get your comments regarding whether these are
> realistical number for everyday use, or they are relevant only to this
> particular scenario.
RT isn't about "realistic numbers for everyday use". It's about worst
cases.
> - Can these interrupts be used in directed delivery, so that the destination
> mask can include multiple VCPUs?
The Freescale MPIC does not support multiple destinations for most
interrupts, but the (non-FSL-specific) emulation code appears to allow
it.
> The MPIC manual states that timer and IPI
> interrupts are supported for directed delivery, altough I'm not sure how much
> of
> this is used in the emulation. I know that kvmppc uses the decrementer
> outside
> of the MPIC.
>
> - How are virtio interrupts cascaded over the shared MSI interrupts?
> /proc/device-tree/soc@e000/msi@41600/interrupts in the guest shows 8
> values
> - 224 - 231 - so at most there might be 8 pending interrupts in IRQ_check, is
> that correct?
It looks like that's currently the case, but actual hardware supports
more than that, so it's possible (albeit unlikely any time soon) that
the emulation eventually does as well.
But it's possible to have interrupts other than MSIs...
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/8xx: Implementation of PAGE_EXEC
On Wed, 2015-04-22 at 12:06 +0200, Christophe Leroy wrote: > diff --git a/arch/powerpc/include/asm/mmu-8xx.h > b/arch/powerpc/include/asm/mmu-8xx.h > index d41200c..1407034 100644 > --- a/arch/powerpc/include/asm/mmu-8xx.h > +++ b/arch/powerpc/include/asm/mmu-8xx.h > @@ -27,6 +27,19 @@ > #define MI_Ks0x8000 /* Should not be set */ > #define MI_Kp0x4000 /* Should always be set */ > > +/* > + * All pages PP exec bits are set to 000, which means Execute for Supervisor > + * and no Execute for User. > + * Then we use the APG to say whether accesses are according to Page rules, > + * "all Supervisor" rules (Exec for all) and "all User" rules (Exec for > noone) > + * Therefore, we define 4 APG groups. msb is _PAGE_EXEC, lsb is _PAGE_USER > + * 0 (00) => Not User, no exec => 11 (all accesses performed as user) > + * 1 (01) => User but no exec => 11 (all accesses performed as user) > + * 2 (10) => Not User, exec => 01 (rights according to page definition) > + * 3 (11) => User, exec => 00 (all accesses performed as supervisor) > + */ > +#define MI_APG_INIT 0xf4ff > + > /* The effective page number register. When read, contains the information > * about the last instruction TLB miss. When MI_RPN is written, bits in > * this register are used to create the TLB entry. > @@ -87,6 +100,19 @@ > #define MD_Ks0x8000 /* Should not be set */ > #define MD_Kp0x4000 /* Should always be set */ > > +/* > + * All pages PP exec bits are set to either 000 or 011, which means > respectively > + * RW for Supervisor and no access for User, or RO for Supervisor and no > access > + * for user. > + * Then we use the APG to say whether accesses are according to Page rules or > + * "all Supervisor" rules (Access to all) > + * Therefore, we define 2 APG groups. lsb is _PAGE_USER > + * 0 => No user => 01 (all accesses performed according to page definition) > + * 1 => User => 00 (all accesses performed as supervisor > + * according to page definition) > + */ > +#define MD_APG_INIT 0x4fff "exec" bits or data? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On Thu, 2015-04-23 at 15:31 +0300, Purcareata Bogdan wrote:
> On 23.04.2015 03:30, Scott Wood wrote:
> > On Wed, 2015-04-22 at 15:06 +0300, Purcareata Bogdan wrote:
> >> On 21.04.2015 03:52, Scott Wood wrote:
> >>> On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
> >>>> There was a weird situation for .kvmppc_mpic_set_epr - its corresponding
> >>>> inner
> >>>> function is kvmppc_set_epr, which is a static inline. Removing the
> >>>> static inline
> >>>> yields a compiler crash (Segmentation fault (core dumped) -
> >>>> scripts/Makefile.build:441: recipe for target 'arch/powerpc/kvm/kvm.o'
> >>>> failed),
> >>>> but that's a different story, so I just let it be for now. Point is the
> >>>> time may
> >>>> include other work after the lock has been released, but before the
> >>>> function
> >>>> actually returned. I noticed this was the case for .kvm_set_msi, which
> >>>> could
> >>>> work up to 90 ms, not actually under the lock. This made me change what
> >>>> I'm
> >>>> looking at.
> >>>
> >>> kvm_set_msi does pretty much nothing outside the lock -- I suspect
> >>> you're measuring an interrupt that happened as soon as the lock was
> >>> released.
> >>
> >> That's exactly right. I've seen things like a timer interrupt occuring
> >> right
> >> after the spinlock_irqrestore, but before kvm_set_msi actually returned.
> >>
> >> [...]
> >>
> >>>>Or perhaps a different stress scenario involving a lot of VCPUs
> >>>> and external interrupts?
> >>>
> >>> You could instrument the MPIC code to find out how many loop iterations
> >>> you maxed out on, and compare that to the theoretical maximum.
> >>
> >> Numbers are pretty low, and I'll try to explain based on my observations.
> >>
> >> The problematic section in openpic_update_irq is this [1], since it loops
> >> through all VCPUs, and IRQ_local_pipe further calls IRQ_check, which loops
> >> through all pending interrupts for a VCPU [2].
> >>
> >> The guest interfaces are virtio-vhostnet, which are based on MSI
> >> (/proc/interrupts in guest shows they are MSI). For external interrupts to
> >> the
> >> guest, the irq_source destmask is currently 0, and last_cpu is 0
> >> (unitialized),
> >> so [1] will go on and deliver the interrupt directly and unicast (no VCPUs
> >> loop).
> >>
> >> I activated the pr_debugs in arch/powerpc/kvm/mpic.c, to see how many
> >> interrupts
> >> are actually pending for the destination VCPU. At most, there were 3
> >> interrupts
> >> - n_IRQ = {224,225,226} - even for 24 flows of ping flood. I understand
> >> that
> >> guest virtio interrupts are cascaded over 1 or a couple of shared MSI
> >> interrupts.
> >>
> >> So worst case, in this scenario, was checking the priorities for 3 pending
> >> interrupts for 1 VCPU. Something like this (some of my prints included):
> >>
> >> [61010.582033] openpic_update_irq: destmask 1 last_cpu 0
> >> [61010.582034] openpic_update_irq: Only one CPU is allowed to receive this
> >> IRQ
> >> [61010.582036] IRQ_local_pipe: IRQ 224 active 0 was 1
> >> [61010.582037] IRQ_check: irq 226 set ivpr_pr=8 pr=-1
> >> [61010.582038] IRQ_check: irq 225 set ivpr_pr=8 pr=-1
> >> [61010.582039] IRQ_check: irq 224 set ivpr_pr=8 pr=-1
> >>
> >> It would be really helpful to get your comments regarding whether these are
> >> realistical number for everyday use, or they are relevant only to this
> >> particular scenario.
> >
> > RT isn't about "realistic numbers for everyday use". It's about worst
> > cases.
> >
> >> - Can these interrupts be used in directed delivery, so that the
> >> destination
> >> mask can include multiple VCPUs?
> >
> > The Freescale MPIC does not support multiple destinations for most
> > interrupts, but the (non-FSL-specific) emulation code appears to allow
> > it.
> >
> >> The MPIC manual states that timer and IPI
> >> interrupts are supported for directed delivery, altough I'm not sure how
> >> much of
> >> this is used in the emulation. I know that kvmppc uses the decrementer
> >> outside
&g
Re: [RFC,v3,00/12] Freescale DPAA FMan
On Wed, 2015-04-29 at 12:26 +0300, Igal.Liberman wrote: > From: Igal Liberman > > The Freescale Data Path Acceleration Architecture (DPAA) > is a set of hardware components on specific QorIQ multicore > processors. This architecture provides the infrastructure to > support simplified sharing of networking interfaces and > accelerators by multiple CPU cores and the accelerators. > Why is this a separate patchset from "Introduce DPAA Ethernet driver"? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Wed, 2015-04-22 at 05:47 -0500, Liberman Igal-B31950 wrote:
>
>
> Regards,
> Igal Liberman.
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, April 21, 2015 3:52 AM
> > To: Liberman Igal-B31950
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Tang
> > Yuantian-B29983
> > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
> >
> > On Mon, 2015-04-20 at 06:40 -0500, Liberman Igal-B31950 wrote:
> > >
> > >
> > > Regards,
> > > Igal Liberman.
> > >
> > > > -Original Message-
> > > > From: Liberman Igal-B31950
> > > > Sent: Monday, April 20, 2015 2:07 PM
> > > > To: Wood Scott-B07421
> > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > > > Subject: RE: [v3] dt/bindings: qoriq-clock: Add binding for FMan
> > > > clock mux
> > > >
> > > >
> > > >
> > > > Regards,
> > > > Igal Liberman.
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Friday, April 17, 2015 8:41 AM
> > > > > To: Liberman Igal-B31950
> > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan
> > > > > clock mux
> > > > >
> > > > > On Thu, 2015-04-16 at 01:11 -0500, Liberman Igal-B31950 wrote:
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Igal Liberman.
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Wednesday, April 15, 2015 8:36 PM
> > > > > > > To: Liberman Igal-B31950
> > > > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > > > > > > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for
> > > > > > > FMan clock mux
> > > > > > >
> > > > > > > On Tue, 2015-04-14 at 13:56 +0300, Igal.Liberman wrote:
> > > > > > > > From: Igal Liberman
> > > > > > > >
> > > > > > > > v3: Addressed feedback from Scott:
> > > > > > > > - Removed clock specifier description.
> > > > > > > >
> > > > > > > > v2: Addressed feedback from Scott:
> > > > > > > > - Moved the "fman-clk-mux" clock provider details
> > > > > > > > under "clocks" property.
> > > > > > > >
> > > > > > > > Signed-off-by: Igal Liberman
> > > > > > > > ---
> > > > > > > > .../devicetree/bindings/clock/qoriq-clock.txt | 17
> > > > > +++--
> > > > > > > > 1 file changed, 15 insertions(+), 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git
> > > > > > > > a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > > > > > > > b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > > > > > > > index b0d7b73..2bb3b38 100644
> > > > > > > > ---
> > > > > > > > a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > > > > > > > +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.tx
> > > > > > > > +++ t
> > > > > > > > @@ -65,9 +65,10 @@ Required properties:
> > > > > > > > It takes parent's clock-frequency as its clock.
> > > > > > > > * "fsl,qoriq-platform-pll-1.0" for the platform PLL
> > > > > > > > clock (v1.0)
> > > > > > > > * "fsl,qoriq-platform-pll-2.0" for the platform PLL
> > > > > > > > clock
> > > > > > > > (v2.0)
> > > > > > > > + * "fsl,fman-clk-mux" for the Frame Manager clock.
> > > > > > > > - #clock-cells: From common clock binding. The number of cells
> > > > > > > > in
> > a
> > > > > > > > - clock-specifier. Should be <0> for
> > > > > > > > "fsl,qoriq-sysclk-[1,2].0"
> > > > > > > > - clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
> > > > > > > > + clock-specifier. Should be <0> for
> > > > > > > > "fsl,qoriq-sysclk-[1,2].0"
> > > > and
> > > > > > > > + "fsl,fman-clk-mux" clocks or <1> for
> > > > > > > > "fsl,qoriq-core-pll-
> > > > [1,2].0".
> > > > > > > > For "fsl,qoriq-core-pll-1.0" clocks, the single
> > > > > > > > clock-specifier cell may take the following values:
> > > > > > > > * 0 - equal to the PLL frequency @@ -145,6 +146,18 @@
> > > > Example
> > > > > > > > for clock block and clock provider:
> > > > > > > > clocks = <&sysclk>;
> > > > > > > > clock-output-names = "platform-pll",
> > > > "platform-pll-
> > > > > > > div2";
> > > > > > > > };
> > > > > > > > +
> > > > > > > > + fm0clk: fm0-clk-mux {
> > > > > > > > + #clock-cells = <0>;
> > > > > > > > + reg = <0x10 4>
> > > > > > > > + compatible = "fsl,fman-clk-mux";
> > > > > > > > + clocks = <&pll0 0>, <&pll0 1>, <&pll0
> > > > > > > > 2>,
> > > > <&pll0 3>,
> > > > > > > > +<&platform_pll 0>, <&pll1 1>,
> > > > > > > > <&pll1
> > > > 2>;
> > > > > > > > + clock-names = "pll0", "pll0-div2",
> > > > > > > > "pll0-div3",
> > > > > > > > + "pll0-div4"
Re: [PATCH] powerpc/85xx: p1025twr: add module conditional to fix QE-uart issue
On Thu, 2015-04-30 at 10:56 +0800, Pengbo Li wrote: > From: Xie Xiaobo > > A ioport setting was needed when used the QE uart function on TWR-P1025. > Added a conditional definition to avoid missing this setting when the > QE-uart driver was bulit to a module. s/was bulit to/is built as/ > Signed-off-by: Xie Xiaobo > Change-Id: I95b40c760335ce5fa7a27a94287dbef28219b5fa > Reviewed-on: http://git.am.freescale.net:8181/6643 > Tested-by: Review Code-CDREVIEW > Reviewed-by: Yang Li > Reviewed-by: Thomas Trefny > Reviewed-on: http://git.am.freescale.net:8181/12045 > Reviewed-by: Jose Rivera > --- > arch/powerpc/platforms/85xx/twr_p102x.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c > b/arch/powerpc/platforms/85xx/twr_p102x.c > index 1eadb6d..069e19b 100644 > --- a/arch/powerpc/platforms/85xx/twr_p102x.c > +++ b/arch/powerpc/platforms/85xx/twr_p102x.c > @@ -101,7 +101,7 @@ static void __init twr_p1025_setup_arch(void) > MPC85xx_PMUXCR_QE(12)); > iounmap(guts); > > -#if defined(CONFIG_SERIAL_QE) > +#if defined(CONFIG_SERIAL_QE) || defined(CONFIG_SERIAL_QE_MODULE) > /* On P1025TWR board, the UCC7 acted as UART port. >* However, The UCC7's CTS pin is low level in default, >* it will impact the transmission in full duplex How about using IS_ENABLED here? Don't you need an equivalent change to "#if defined(CONFIG_UCC_GETH) || defined(CONFIG_SERIAL_QE)" ? Do we really need the ifdefs at all? What's the harm in setting up the pins if those things aren't built into the kernel? Power consumption? Is it a likely use case? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: p1025twr: add module conditional to fix QE-uart issue
On Thu, 2015-04-30 at 10:56 +0800, Pengbo Li wrote: > From: Xie Xiaobo > > A ioport setting was needed when used the QE uart function on TWR-P1025. > Added a conditional definition to avoid missing this setting when the > QE-uart driver was bulit to a module. > > Signed-off-by: Xie Xiaobo > Change-Id: I95b40c760335ce5fa7a27a94287dbef28219b5fa > Reviewed-on: http://git.am.freescale.net:8181/6643 > Tested-by: Review Code-CDREVIEW > Reviewed-by: Yang Li > Reviewed-by: Thomas Trefny > Reviewed-on: http://git.am.freescale.net:8181/12045 > Reviewed-by: Jose Rivera Oh, and get rid of this Gerrit stuff. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Thu, 2015-04-30 at 09:28 -0500, Liberman Igal-B31950 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Thursday, April 30, 2015 3:31 AM
> > To: Liberman Igal-B31950
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Tang
> > Yuantian-B29983
> > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
> >
> > On Wed, 2015-04-22 at 05:47 -0500, Liberman Igal-B31950 wrote:
> > > We have 2 cases:
> > > - Devices (T2/T4/B4) with CLKCG1HWACSR register.
> > > - Devices (P, T1) without CLKCG1HWACSR register (P
> > devices
> > > have many options, T1 has only one option)
> > >
> > > For the first group, we can have " qoriq-hwacsr" property in the clock
> > > node.
> >
> > No, we're not going to describe every register with its own property.
> > Describe the chip and let the driver be the place with the knowledge of what
> > each chip is like.
> >
>
> I think that FMan clock mux (as we defined it) is similar to other muxes
> available in our SoC.
I realize that. I'm saying the way we described existing muxes seems to
be a mistake. We're putting too much complexity in the device tree.
Better to put the complexity in a place that isn't stable ABI.
> If we take T4 as example, it has 3 muxes defined in the device tree (mux0,
> mux1 and mux2).
> Each mux has its own reg property (and clock providers).
> mux2: mux2@40 {
> #clock-cells = <0>;
> reg = <0x40 0x4>;
> compatible = "fsl,qoriq-core-mux-2.0";
> clocks = <&pll3 0>, <&pll3 1>, <&pll3 2>,
> <&pll4 0>, <&pll4 1>, <&pll4 2>;
> clock-names = "pll3", "pll3-div2", "pll3-div4",
> "pll4", "pll4-div2", "pll4-div4";
> clock-output-names = "cmux2";
> };
>
> I agree that "fm1-clk-mux" need to be moved from the "guts" node to
> "clockgen" node.
That's not what I was saying. I'm saying get rid of the node entirely,
in favor of having the clockgen node itself be a clock source with
multiple post-mux outputs.
> However, I'm not sure which changes you want to perform in the node (beside
> adding reg property for SoC which has it for FMan clock).
Again, the clockgen node already has a reg property.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2,2/2] powerpc32: add support for csum_add()
On Tue, 2015-04-28 at 21:01 +0200, christophe leroy wrote:
>
>
> Le 25/03/2015 02:30, Scott Wood a écrit :
>
> > On Tue, Feb 03, 2015 at 12:39:27PM +0100, LEROY Christophe wrote:
> > > The C version of csum_add() as defined in include/net/checksum.h gives the
> > > following assembly:
> > >0: 7c 04 1a 14 add r0,r4,r3
> > >4: 7c 64 00 10 subfc r3,r4,r0
> > >8: 7c 63 19 10 subfe r3,r3,r3
> > >c: 7c 63 00 50 subfr3,r3,r0
> > >
> > > include/net/checksum.h also offers the possibility to define an arch
> > > specific
> > > function.
> > > This patch provides a ppc32 specific csum_add() inline function.
> > What makes it 32-bit specific?
> >
> >
> As far as I understand, the 64-bit will do a 64 bit addition, so we
> will have to handle differently the carry, can't just be an addze like
> in 32-bit.
OK. Before I couldn't find where this was ifdeffed to 32-bit, but it's
in patch 1/2.
> The generated code is most likely different on ppc64. I have no ppc64
> compiler so I can't check what gcc generates for the following code:
>
> __wsum csum_add(__wsum csum, __wsum addend)
> {
> u32 res = (__force u32)csum;
> res += (__force u32)addend;
> return (__force __wsum)(res + (res < (__force u32)addend));
> }
>
> Can someone with a ppc64 compiler tell what we get ?
With CONFIG_GENERIC_CPU:
0xc0001af8 <+0>: add r3,r3,r4
0xc0001afc <+4>: cmplw cr7,r3,r4
0xc0001b00 <+8>: mfcrr4
0xc0001b04 <+12>:rlwinm r4,r4,29,31,31
0xc0001b08 <+16>:add r3,r4,r3
0xc0001b0c <+20>:clrldi r3,r3,32
0xc0001b10 <+24>:blr
The mfcr is particularly nasty, at least on our chips.
With CONFIG_CPU_E6500:
0xc0001b30 <+0>: add r3,r3,r4
0xc0001b34 <+4>: cmplw cr7,r3,r4
0xc0001b38 <+8>: mfocrf r4,1
0xc0001b3c <+12>:rlwinm r4,r4,29,31,31
0xc0001b40 <+16>:add r3,r4,r3
0xc0001b44 <+20>:clrldi r3,r3,32
0xc0001b48 <+24>:blr
Ideal (short of a 64-bit __wsum) would probably be something like (untested):
add r3,r3,r4
srdir5,r3,32
add r3,r3,r5
clrldi r3,r3,32
Or in C code (which would let the compiler schedule it better):
static inline __wsum csum_add(__wsum csum, __wsum addend)
{
u64 res = (__force u64)csum;
res += (__force u32)addend;
return (__force __wsum)((u32)res + (res >> 32));
}
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: fix the dependency issue for CRASH_DUMP
On Thu, 2015-04-30 at 20:29 +0800, Kevin Hao wrote: > In the current code, the RELOCATABLE will be forcedly enabled when > enabling CRASH_DUMP. But for ppc32, the RELOCABLE also depend on > ADVANCED_OPTIONS and select NONSTATIC_KERNEL. This will cause build > error when CRASH_DUMP=y && ADVANCED_OPTIONS=n. Even there is no such > issue for ppc64, but select is only for non-visible symbols and for > symbols with no dependencies. As for a symbol like RELOCATABLE, it is > definitely not suitable to select it. So choose to depend on it. Why is it "definitely not suitable to select it", provided the ADVANCED_OPTIONS dependency is removed, and the FLATMEM dependency is moved to places that select RELOCATABLE? It seems wrong that the user should have to enable ADVANCED_OPTIONS to even see the option to build a crash kernel. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: fix the dependency issue for CRASH_DUMP
On Tue, 2015-05-05 at 10:27 +0800, Kevin Hao wrote: > On Mon, May 04, 2015 at 05:17:17PM -0500, Scott Wood wrote: > > On Thu, 2015-04-30 at 20:29 +0800, Kevin Hao wrote: > > > In the current code, the RELOCATABLE will be forcedly enabled when > > > enabling CRASH_DUMP. But for ppc32, the RELOCABLE also depend on > > > ADVANCED_OPTIONS and select NONSTATIC_KERNEL. This will cause build > > > error when CRASH_DUMP=y && ADVANCED_OPTIONS=n. Even there is no such > > > issue for ppc64, but select is only for non-visible symbols and for > > > symbols with no dependencies. As for a symbol like RELOCATABLE, it is > > > definitely not suitable to select it. So choose to depend on it. > > > > Why is it "definitely not suitable to select it", provided the > > ADVANCED_OPTIONS dependency is removed, and the FLATMEM dependency is > > moved to places that select RELOCATABLE? > > Even with this change, the definition of RELOCATABLE still be something like > this: > config RELOCATABLE >bool "Build a relocatable kernel" >depends on (PPC64 && !COMPILE_TEST) || 44x || FSL_BOOKE >select NONSTATIC_KERNEL That matches the cases where CRASH_DUMP selects RELOCATABLE. > Quoted form Documentation/kbuild/kconfig-language.txt: > select should be used with care. select will force > a symbol to a value without visiting the dependencies. > By abusing select you are able to select a symbol FOO even > if FOO depends on BAR that is not set. > In general use select only for non-visible symbols > (no prompts anywhere) and for symbols with no dependencies. > That will limit the usefulness but on the other hand avoid > the illegal configurations all over. > > So it is always error prone to select a kernel option like this. Yes, but these days Kbuild does warn about selecting a symbol with unmet dependencies, which IIRC wasn't the case when that was written. > > It seems wrong that the user > > should have to enable ADVANCED_OPTIONS to even see the option to build a > > crash kernel. > > Yes, it seems ridiculous. But this is fixed in the patch 2. OK... Still non-obvious, but at least not *as* bad. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/qman: Change fsl,qman-channel-id to cell-index
On Tue, 2015-05-05 at 11:04 -0500, Pledge Roy-R01356 wrote: > Sorry for the slow reply. > > I don't believe this is correct - let me explain the rational why we had two > properties in the QMan portal to begin with. > > The two properties in question are cell-index and fsl,qman-channel-id. > > The cell-index property is used in u-boot as an index for the software portal > ID when adding the fsl,liodn from the U-boot table into the device tree. The device tree is not supposed to contain arbitrary software identifiers. > The fsl,qman-channel-id property is used in Linux and corresponds to a > hardware value that indicates which channel is dedicated to the > software portal. > > While I'm not aware of a current SoC where the channel ID for a > software portal does not match the index (i.e. SWP 0 uses channel 0, > etc.) Thus there's no backward compatibility issue with redefining cell-index to mean the channel ID. > it is possible that future SoCs could stray from this model, > there is no reason for portal index to equal channel ID at all times. How can future SoCs dictate how we assign a software-defined identifier? If software wants it to be the same as the channel id, then it will be. If there is some aspect of the hardware itself (not the documentation) that cell-index currently corresponds to, other than the channel id, please make that clear. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Tue, 2015-05-05 at 16:02 -0500, Liberman Igal-B31950 wrote:
>
>
> Regards,
> Igal Liberman.
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Saturday, May 02, 2015 2:43 AM
> > To: Liberman Igal-B31950
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Tang
> > Yuantian-B29983
> > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
> >
> > On Thu, 2015-04-30 at 09:28 -0500, Liberman Igal-B31950 wrote:
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Thursday, April 30, 2015 3:31 AM
> > > > To: Liberman Igal-B31950
> > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Tang
> > > > Yuantian-B29983
> > > > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan
> > > > clock mux
> > > >
> > > > On Wed, 2015-04-22 at 05:47 -0500, Liberman Igal-B31950 wrote:
> > > > > We have 2 cases:
> > > > > - Devices (T2/T4/B4) with CLKCG1HWACSR register.
> > > > > - Devices (P, T1) without CLKCG1HWACSR register (P
> > > > devices
> > > > > have many options, T1 has only one option)
> > > > >
> > > > > For the first group, we can have " qoriq-hwacsr" property in the clock
> > node.
> > > >
> > > > No, we're not going to describe every register with its own property.
> > > > Describe the chip and let the driver be the place with the knowledge
> > > > of what each chip is like.
> > > >
> > >
> > > I think that FMan clock mux (as we defined it) is similar to other muxes
> > available in our SoC.
> >
> > I realize that. I'm saying the way we described existing muxes seems to be
> > a
> > mistake. We're putting too much complexity in the device tree.
> > Better to put the complexity in a place that isn't stable ABI.
> >
> > > If we take T4 as example, it has 3 muxes defined in the device tree (mux0,
> > mux1 and mux2).
> > > Each mux has its own reg property (and clock providers).
> > > mux2: mux2@40 {
> > > #clock-cells = <0>;
> > > reg = <0x40 0x4>;
> > > compatible = "fsl,qoriq-core-mux-2.0";
> > > clocks = <&pll3 0>, <&pll3 1>, <&pll3 2>,
> > > <&pll4 0>, <&pll4 1>, <&pll4 2>;
> > > clock-names = "pll3", "pll3-div2", "pll3-div4",
> > > "pll4", "pll4-div2", "pll4-div4";
> > > clock-output-names = "cmux2";
> > > };
> > >
> > > I agree that "fm1-clk-mux" need to be moved from the "guts" node to
> > "clockgen" node.
> >
> > That's not what I was saying. I'm saying get rid of the node entirely, in
> > favor
> > of having the clockgen node itself be a clock source with multiple post-mux
> > outputs.
> >
>
> Scott,
> Currently the clockgen node has a number of sub nodes (platform clock,
> sysclock, PLLs and muxes, the number of muxes/PLLs is SoC dependent).
> The clockgen node has reg property, however, all other nodes have reg
> property too (The clockgen points to the clocking block address and the sub
> nodes point to the specific register in the clock block).
> Do you want to change this structure completely?
Yes, I want to change it completely (while ensuring the kernel still
works, albeit without new functionality, with older device trees).
> I'm not sure I understand the exact way you want see those nodes (in the
> final state).
Something like:
clockgen: global-utilities@e1000 {
compatible = "fsl,-clockgen";
clock-frequency = <...>;
reg = <0xe1000 0x1000>;
#clock-cells = <2>;
};
cpu0: PowerPC,e6500@0 {
device_type = "cpu";
reg = <0 1>;
clocks = <&clockgen 0 0>;
next-level-cache = <&L2_1>;
fsl,portid-mapping = <0x8000>;
};
cpu4: PowerPC,e6500@0 {
device_type = "cpu";
reg = <4 5>;
clocks = <&clockgen 0 1>;
next-level-cache = <&L2_1>;
fsl,portid-mapping = <0x8000>;
};
fman@... {
...
clocks = <&clockgen 1 0>;
...
};
...with the clockgen binding explaining the format of the clock
specifier, and the clockgen driver containing the chip-specific muxing
details.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v4] clk: qoriq: Add support for the FMan clock
On Wed, 2015-05-06 at 00:02 -0700, Stephen Boyd wrote:
> On 04/16, Igal.Liberman wrote:
> > +static int get_fm_clk_idx(int fm_id, int *fm_clk_idx)
> > +{
> > + struct ccsr_guts __iomem *guts_regs = NULL;
>
> Unnecessary initialization to NULL. Also, marking a structure as
> __iomem is odd. Why do we need to use a struct to figure out
> offsets for registers? Why not just use #defines? That would
> probably also make it easy to avoid the asm include here.
Using a struct for registers is quite common:
scott@snotra:~/fsl/git/linux/upstream$ git grep struct|grep __iomem|wc -l
3005
It provides type-safety, and makes accessing the registers more natural.
> > + struct device_node *guts;
> > + uint32_t reg = 0;
>
> s/uint32_t/u32/
Why?
> Also unnecessary initialization.
Given the if/else if/else if/... nature of how reg is initialized, this
seems like a useful and harmless way of making behavior predictable if
there is a bug.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/dts: Add 1588 timer node for eTSEC
On Wed, 2015-05-06 at 17:40 +0800, Yangbo Lu wrote:
> Add 1588 timer node in files:
> arch/powerpc/boot/dts/bsc9131rdb.dtsi
> arch/powerpc/boot/dts/bsc9132qds.dtsi
> arch/powerpc/boot/dts/p1010rdb.dtsi
> arch/powerpc/boot/dts/p1020rdb-pd.dts
> arch/powerpc/boot/dts/p1021rdb-pc.dtsi
> arch/powerpc/boot/dts/p1022ds.dtsi
> arch/powerpc/boot/dts/p1025twr.dtsi
> arch/powerpc/boot/dts/p2020rdb-pc.dtsi
>
> Signed-off-by: Yangbo Lu
> ---
> arch/powerpc/boot/dts/bsc9131rdb.dtsi | 12
> arch/powerpc/boot/dts/bsc9132qds.dtsi | 12
> arch/powerpc/boot/dts/p1010rdb.dtsi| 12
> arch/powerpc/boot/dts/p1020rdb-pd.dts | 12
> arch/powerpc/boot/dts/p1021rdb-pc.dtsi | 12
> arch/powerpc/boot/dts/p1022ds.dtsi | 12
> arch/powerpc/boot/dts/p1025twr.dtsi| 12
> arch/powerpc/boot/dts/p2020rdb-pc.dtsi | 15 +--
> 8 files changed, 93 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> index 45efcba..629cc03 100644
> --- a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> +++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> @@ -80,6 +80,18 @@
> status = "disabled";
> };
>
> + ptp_clock@b0e00 {
> + compatible = "fsl,etsec-ptp";
> + reg = <0xb0e00 0xb0>;
> + interrupts = <68 2 0 0 69 2 0 0>;
> + fsl,tclk-period = <5>;
> + fsl,tmr-prsc= <2>;
> + fsl,tmr-add = <0xcccd>;
> + fsl,tmr-fiper1 = <0x3b9ac9fb>;
> + fsl,tmr-fiper2 = <0x00018696>;
> + fsl,max-adj = <24999>;
Please don't use hex for numbers that make more sense as decimal.
> --- a/arch/powerpc/boot/dts/p2020rdb-pc.dtsi
> +++ b/arch/powerpc/boot/dts/p2020rdb-pc.dtsi
> @@ -215,12 +215,15 @@
> };
>
> ptp_clock@24e00 {
> - fsl,tclk-period = <5>;
> - fsl,tmr-prsc = <200>;
> - fsl,tmr-add = <0xCCCD>;
> - fsl,tmr-fiper1 = <0x3B9AC9FB>;
> - fsl,tmr-fiper2 = <0x0001869B>;
> - fsl,max-adj = <24999>;
> + compatible = "fsl,etsec-ptp";
> + reg = <0x24e00 0xb0>;
> + interrupts = <68 2 0 0 69 2 0 0>;
> + fsl,tclk-period = <5>;
> + fsl,tmr-prsc= <2>;
> + fsl,tmr-add = <0xaaab>;
> + fsl,tmr-fiper1 = <0x3b9ac9fb>;
> + fsl,tmr-fiper2 = <0x00018696>;
> + fsl,max-adj = <2>;
> };
This isn't adding a node -- it's changing values. If the old ones were
wrong, explain that in the changelog.
Also, p2020si-post.dtsi already adds interrupts to this node (and it
contains one more interrupt than the above), and it includes
pq3-etsec1-timer-0.dtsi which contains the compatible and reg (and
interrupts with two specifiers). Probably all of these should be using
pq3-etsec1-timer-0.dtsi and only specifying the board-specific values.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v4] clk: qoriq: Add support for the FMan clock
On Wed, 2015-05-06 at 15:25 -0700, Stephen Boyd wrote:
> On 05/06, Scott Wood wrote:
> > On Wed, 2015-05-06 at 00:02 -0700, Stephen Boyd wrote:
> > > On 04/16, Igal.Liberman wrote:
> > > > +static int get_fm_clk_idx(int fm_id, int *fm_clk_idx)
> > > > +{
> > > > + struct ccsr_guts __iomem *guts_regs = NULL;
> > >
> > > Unnecessary initialization to NULL. Also, marking a structure as
> > > __iomem is odd. Why do we need to use a struct to figure out
> > > offsets for registers? Why not just use #defines? That would
> > > probably also make it easy to avoid the asm include here.
> >
> > Using a struct for registers is quite common:
> > scott@snotra:~/fsl/git/linux/upstream$ git grep struct|grep __iomem|wc -l
> > 3005
>
> $ git grep -E 'struct \w+ __iomem' | wc -l
> 2212
>
> That's slightly inflated, but ok.
>
> Within drivers/clk there aren't any though, hence my apprehension
>
> $ git grep -E 'struct \w+ __iomem' -- drivers/clk/ | wc -l
> 0
I'm not sure why clk should be special. Plus, this is a struct that's
been used by other parts of the kernel since before git history began,
rather than something defined specifically for drivers/clk.
> > It provides type-safety, and makes accessing the registers more natural.
>
> Sure, we can leave the struct as is, but to make this compile on
> ARM we need to figure something out. Move the struct definition
> into include/linux/platform_data/ perhaps?
It's register definition rather than platform data, but yes, it should
go somewhere in include/linux. Or I suppose we could put #ifdef
CONFIG_PPC around the fman stuff.
> > > Also unnecessary initialization.
> >
> > Given the if/else if/else if/... nature of how reg is initialized, this
> > seems like a useful and harmless way of making behavior predictable if
> > there is a bug.
> >
>
> If there's a possibility of a bug due to missed initialization
> perhaps it's a sign the code is too complicated and should be
> broken down into smaller functions.
Well, there's always a possibility. :-)
Though rereading this function, reg is only used in the locations where
it's set -- not after the if/else stuff -- so I no longer think this is
a particularly high risk situation. Plus, GCC's gotten pretty
aggressive about warning about such possibilities.
> For example, this function could be rewritten to have a match table
> with function pointers that return the fm_clk_idx.
Yes, that'd be nice.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/dts: Add 1588 timer node for eTSEC
On Wed, 2015-05-06 at 21:26 -0500, Lu Yangbo-B47093 wrote:
> Thanks.
> Pls see my comments below.
>
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, May 07, 2015 4:44 AM
> To: Lu Yangbo-B47093
> Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] powerpc/dts: Add 1588 timer node for eTSEC
>
> On Wed, 2015-05-06 at 17:40 +0800, Yangbo Lu wrote:
> > Add 1588 timer node in files:
> > arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > arch/powerpc/boot/dts/bsc9132qds.dtsi
> > arch/powerpc/boot/dts/p1010rdb.dtsi
> > arch/powerpc/boot/dts/p1020rdb-pd.dts
> > arch/powerpc/boot/dts/p1021rdb-pc.dtsi
> > arch/powerpc/boot/dts/p1022ds.dtsi
> > arch/powerpc/boot/dts/p1025twr.dtsi
> > arch/powerpc/boot/dts/p2020rdb-pc.dtsi
> >
> > Signed-off-by: Yangbo Lu
> > ---
> > arch/powerpc/boot/dts/bsc9131rdb.dtsi | 12
> > arch/powerpc/boot/dts/bsc9132qds.dtsi | 12
> > arch/powerpc/boot/dts/p1010rdb.dtsi| 12
> > arch/powerpc/boot/dts/p1020rdb-pd.dts | 12
> > arch/powerpc/boot/dts/p1021rdb-pc.dtsi | 12
> > arch/powerpc/boot/dts/p1022ds.dtsi | 12
> > arch/powerpc/boot/dts/p1025twr.dtsi| 12
> > arch/powerpc/boot/dts/p2020rdb-pc.dtsi | 15 +--
> > 8 files changed, 93 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > index 45efcba..629cc03 100644
> > --- a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > +++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > @@ -80,6 +80,18 @@
> > status = "disabled";
> > };
> >
> > + ptp_clock@b0e00 {
> > + compatible = "fsl,etsec-ptp";
> > + reg = <0xb0e00 0xb0>;
> > + interrupts = <68 2 0 0 69 2 0 0>;
> > + fsl,tclk-period = <5>;
> > + fsl,tmr-prsc= <2>;
> > + fsl,tmr-add = <0xcccd>;
> > + fsl,tmr-fiper1 = <0x3b9ac9fb>;
> > + fsl,tmr-fiper2 = <0x00018696>;
> > + fsl,max-adj = <24999>;
>
> Please don't use hex for numbers that make more sense as decimal.
> [Lu Yangbo-B47093] The hex value is register value, I think it's better to
> use hex.
Whether it goes into a register doesn't matter. Hex values are useful
for values which are subdivided into various bitfields, or whose hex
representation is simpler than decimal. I'm not familiar with the
details of this hardware, but I doubt the former is the case for
0x3b9ac9fb == 95 or 0x18696 == 0.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc: mpc85xx: Add board support for ucp1020
On Tue, 2015-05-05 at 11:52 -0400, Oleksandr G Zhadan wrote:
> New QorIQ p1020 based board support from Arcturus Networks Inc.
> http://www.arcturusnetworks.com/products/ucp1020/
>
> Signed-off-by: Michael Durrant
> Signed-off-by: Oleksandr G Zhadan
> ---
> Documentation/devicetree/bindings/pci/fsl,pci.txt |2 +-
> .../devicetree/bindings/powerpc/arcturus/board.txt | 149 ++
> .../devicetree/bindings/powerpc/arcturus/ecm.txt | 64 +
> Documentation/devicetree/bindings/usb/fsl-usb.txt |2 +-
> .../devicetree/bindings/vendor-prefixes.txt|1 +
> arch/powerpc/boot/dts/fsl/ucp1020som-post.dtsi | 179 ++
> arch/powerpc/boot/dts/fsl/ucp1020som-pre.dtsi | 70 +
> arch/powerpc/boot/dts/ucp1020_32b.dts | 88 +
> arch/powerpc/boot/dts/ucp1020_32b.dtsi | 174 ++
> arch/powerpc/configs/ucp1020_defconfig | 2731
>
> arch/powerpc/platforms/85xx/Kconfig|7 +
> arch/powerpc/platforms/85xx/Makefile |1 +
> arch/powerpc/platforms/85xx/ucp1020_som.c | 100 +
> 13 files changed, 3566 insertions(+), 2 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/powerpc/arcturus/board.txt
> create mode 100644 Documentation/devicetree/bindings/powerpc/arcturus/ecm.txt
> create mode 100644 arch/powerpc/boot/dts/fsl/ucp1020som-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/ucp1020som-pre.dtsi
> create mode 100644 arch/powerpc/boot/dts/ucp1020_32b.dts
> create mode 100644 arch/powerpc/boot/dts/ucp1020_32b.dtsi
> create mode 100644 arch/powerpc/configs/ucp1020_defconfig
> create mode 100644 arch/powerpc/platforms/85xx/ucp1020_som.c
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,pci.txt
> b/Documentation/devicetree/bindings/pci/fsl,pci.txt
> index d8ac4a7..298a5e6 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,pci.txt
> +++ b/Documentation/devicetree/bindings/pci/fsl,pci.txt
> @@ -20,7 +20,7 @@ Example:
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> - compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
> + compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci",
> "fsl,mpc8548-pcie";
> device_type = "pci";
> ...
> ...
> diff --git a/Documentation/devicetree/bindings/powerpc/arcturus/board.txt
> b/Documentation/devicetree/bindings/powerpc/arcturus/board.txt
> new file mode 100644
> index 000..54e9765
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/arcturus/board.txt
> @@ -0,0 +1,149 @@
> +UCP1020 module Tree Bindings
> +
> +
> +Copyright 2013-2015 Arcturus Networks, Inc.
> +
> +QorIQ p1020 based board
> +http://www.arcturusnetworks.com/products/ucp1020/
> +-
> +
> +Root Module
> +
> +Properties:
> +- model: "arcturus,uCP1020"
> +- compatible:"arcturus,uCP1020"
> +- SN:"1234567890-1234"
> +
> +/ {
> + model = "arcturus,uCP1020";
> + compatible = "arcturus,uCP1020", "fsl,P1020";
> + SN = "1234567890-1234";
> + ...
> + }
Drop the "fsl,P1020" compatible. Top-level compatible strings describe
the whole board.
SN is a bad property name. Call it something like "arcturus,serial#",
and define what it actually means rather than just giving an example.
> +-
> +
> +P1020 SPI controller
> +
> +Properties:
> +- compatible:"spansion,s25fl008k", "winbond,w25q80bl"
> +
> +Example:
> + spi@7000 {
> + flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "spansion,s25fl008k", "winbond,w25q80bl";
> + reg = <0>;
> + spi-max-frequency = <4000>; /* input clock */
> + ...
> + };
This isn't describing the controller, but rather a SPI chip attached to
the controller. This also doesn't seem like the right place for random
SPI chips.
If all you're specifying is the compatible, maybe create a
spi/trivial-devices.txt similar to i2c/trivial-devices.txt? Or
something specific to SPI flash chips to describe the partition
specification, though I generally recommend against describing
partitions in the device tree -- especially if this is a developer board
rather than something fixed-purpose where the partitioning is not going
to change based on user requirements.
> +-
> +
> +Chipselect/Local Bus
> +
> +Properties:
> +- #address-cells:<2>.
> +- #size-cells: <1>.
> +- compatible:"fsl,p1020-elbc", "fsl,elbc",
> "simple-bus","fsl,p1020-immr"
> +- interrupts:interrupts to report localbus events.
> +
> +Example:
> +
> +&lbc {
> + #addre
Re: [PATCH 1/1] powerpc: mpc85xx: Add board support for ucp1020
On Thu, 2015-05-07 at 12:31 -0400, Oleksandr G Zhadan wrote:
> Hi Scott,
>
> Thanks for fast response, please see inline.
>
> On 05/06/2015 11:22 PM, Scott Wood wrote:
> > On Tue, 2015-05-05 at 11:52 -0400, Oleksandr G Zhadan wrote:
> >> +-
> >> +
> >> +P1020 SPI controller
> >> +
> >> +Properties:
> >> +- compatible: "spansion,s25fl008k", "winbond,w25q80bl"
> >> +
> >> +Example:
> >> + spi@7000 {
> >> + flash@0 {
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + compatible = "spansion,s25fl008k", "winbond,w25q80bl";
> >> + reg = <0>;
> >> + spi-max-frequency = <4000>; /* input clock */
> >> + ...
> >> + };
> >
> > This isn't describing the controller, but rather a SPI chip attached to
> > the controller. This also doesn't seem like the right place for random
> > SPI chips.
> >
> > If all you're specifying is the compatible, maybe create a
> > spi/trivial-devices.txt similar to i2c/trivial-devices.txt? Or
> > something specific to SPI flash chips to describe the partition
> > specification, though I generally recommend against describing
> > partitions in the device tree -- especially if this is a developer board
> > rather than something fixed-purpose where the partitioning is not going
> > to change based on user requirements.
> >
> >
>
> Mostly in all Documentation/devicetree/bindings/ I tried to satisfy
> checkpatch script as simple as possible. And for me as well it looks
> reasonable to create spi/trivial-devices.txt file and I will.
Checkpatch is a tool, not a dictator. Sometimes it gets things wrong.
Also, please CC devicet...@vger.kernel.org when adding bindings or
modifying dts files.
> >> +-
> >> +
> >> +Chipselect/Local Bus
> >> +
> >> +Properties:
> >> +- #address-cells: <2>.
> >> +- #size-cells:<1>.
> >> +- compatible: "fsl,p1020-elbc", "fsl,elbc",
> >> "simple-bus","fsl,p1020-immr"
> >> +- interrupts: interrupts to report localbus events.
> >> +
> >> +Example:
> >> +
> >> +&lbc {
> >> + #address-cells = <2>;
> >> + #size-cells = <1>;
> >> + compatible = "fsl,p1020-elbc", "fsl,elbc", "simple-bus";
> >> + interrupts = <19 2 0 0>;
> >> +};
> >
> > There's already a binding for elbc -- and the elbc node certainly should
> > not claim compatibility with "fsl,p1020-immr".
> >
> >
>
> to satisfy checkpatch script.
Even if that were necessary, why do it by copy-and-paste, and why put
the immr compatible in the binding for a different node?
> >> diff --git a/arch/powerpc/boot/dts/fsl/ucp1020som-post.dtsi
> >> b/arch/powerpc/boot/dts/fsl/ucp1020som-post.dtsi
> >> new file mode 100644
> >> index 000..930a6e3
> >> --- /dev/null
> >> +++ b/arch/powerpc/boot/dts/fsl/ucp1020som-post.dtsi
> >
> > Why can't you use p1020si-post.dtsi? The "si" means "silicon" -- it's
> > meant to be included by all p1020 boards.
> >
>
> Yes, silicon is the same, but p1020 boards using all 3 etsec ethernet
> controllers. Our board using only 2: etsec1 and etsec3.
So have your board write status = "disabled" into the etsec2 node after
including the post file.
> >> diff --git a/arch/powerpc/configs/ucp1020_defconfig
> >> b/arch/powerpc/configs/ucp1020_defconfig
> >> new file mode 100644
> >> index 000..62f99aa
> >> --- /dev/null
> >> +++ b/arch/powerpc/configs/ucp1020_defconfig
> >
> > Please explain why your board needs its own defconfig.
> >
>
> Because, it's our own board and it has some specific to board
> definitions like CONFIG_DEFAULT_HOSTNAME and some specific to product
> definitions.
>
> If I can do it in some other way could you please give me some example
> if it's possible.
I don't think stuff like CONFIG_DEFAULT_HOSTNAME belongs upstream.
Could you list what you need to be set that mpc85xx_smp_defconfig
doesn't set?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc: mpc85xx: Add board support for ucp1020
On Thu, 2015-05-07 at 15:29 -0400, Oleksandr G Zhadan wrote: > On 05/07/2015 02:18 PM, Scott Wood wrote: > > On Thu, 2015-05-07 at 12:31 -0400, Oleksandr G Zhadan wrote: > >>>> diff --git a/arch/powerpc/configs/ucp1020_defconfig > >>>> b/arch/powerpc/configs/ucp1020_defconfig > >>>> new file mode 100644 > >>>> index 000..62f99aa > >>>> --- /dev/null > >>>> +++ b/arch/powerpc/configs/ucp1020_defconfig > >>> > >>> Please explain why your board needs its own defconfig. > >>> > >> > >> Because, it's our own board and it has some specific to board > >> definitions like CONFIG_DEFAULT_HOSTNAME and some specific to product > >> definitions. > >> > >> If I can do it in some other way could you please give me some example > >> if it's possible. > > > > I don't think stuff like CONFIG_DEFAULT_HOSTNAME belongs upstream. > > Could you list what you need to be set that mpc85xx_smp_defconfig > > doesn't set? > > I make diff "mpc85xx_smp_defconfig" vs "ucp1020_defconfig after make > savedefconfig" and it's some differences like: > > - mpc85xx_smp_defconfig has: > CONFIG_PHYS_64BIT=y > CONFIG_NR_CPUS=8 These won't prevent your board from working. If you want CONFIG_PHYS_64BIT disabled for performance, I could see a fragment being used for that as per the recent defconfig discussions. I wouldn't expect NR_CPUS being 8 instead of 2 to be noticeable. > - it enabled almost all boards to build. What for ? Because that's what the common defconfigs are for. We don't want a defconfig for each board (most of the board-specific configs that are currently there were added long ago). If you want a config that contains nothing your board doesn't need, you can maintain that locally. > - it has MTD related differences (doesn't enabled spi flashes support we > need): > -CONFIG_MTD_M25P80=y > -CONFIG_MTD_SST25L=y So add them to the existing defconfig. > - It includes some PHY support, but not phy we are using This should not harm your board. > and we need include intel wifi support: > -CONFIG_MICREL_PHY=y > -CONFIG_IWLWIFI=y So add them to the existing defconfig. > - It doesn't enable EXT4 fs support. I think this would be a reasonable thing to add. > Etc... > > You can see it yourself below: That doesn't show me the set of changes that you *need*, only the set of changes that you have. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
