RE: [PATCH] Add device file bindings for MAPLE
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, July 30, 2013 5:31 AM
To: Leekha Shaveta-B20052
Cc: devicetree-disc...@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org; Leekha
Shaveta-B20052
Subject: Re: [PATCH] Add device file bindings for MAPLE
On 07/27/2013 08:03:42 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha
> ---
> .../devicetree/bindings/powerpc/fsl/maple.txt | 50
>
> 1 files changed, 50 insertions(+), 0 deletions(-) create mode 100644
> Documentation/devicetree/bindings/powerpc/fsl/maple.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
> new file mode 100644
> index 000..23b80a7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
> @@ -0,0 +1,50 @@
> +* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3
> + (MAPLE-B3)device nodes
> +
> +Supported chips:
> +Example: B4860
> +
> +Required properties:
> +
> +- compatible:Should contain "fsl,maple-b3" as the value
> + This identifies Multi Accelerator Platform Engine
> + Baseband 3 block.
> +
> +- reg: offset and length of the register set for the
> device
> +
> +- interrupts
> + Usage: required
> + Value type:
> + Definition: Specifies the interrupts generated by this
> device. The
> + value of the interrupts property consists of
> one interrupt
> + specifier. The format of the specifier is
> defined by the
> + binding document describing the node's
> interrupt parent.
Please clean up whitespace so the text aligns.
[Leekha Shaveta-B20052] ok. Will remove whitespaces.
> +
> + A single IRQ that handles error conditions is specified
> by
> + this property. (Typically shared with port-write).
> +
> +Devices that have LIODNs need to specify links to the parent PAMU
> controller
> +(the actual PAMU controller that this device is connected to) and a
> pointer to
> +the LIODN register, if applicable.
> +
> +- fsl,iommu-parent
> + :
> + This property should be present
> +
> +- status = "disabled"
> + In this example, status is set "disabled",
> + As Maple device wouldn't be used by PPC Linux. This
> representation is required
> + for doing the PAMU programming on the Linux side.
Is it proper for Linux to even set the LIODN on a device that is "disabled"?
Perhaps the compatible should be different, such as "fsl,maple-b3-liodn" to
indicate that that is the only portion of the device that is owned by this
partition.
> +Example:
> + /* B4860 */
> +
> + maple@80 {
> + #address-cells = <0>;
> + #size-cells = <0>;
> + status = "disabled";
> + compatible = "fsl,maple-b3";
> + reg = <0x800 0x1>;
> + interrupts = <16 2 1 18>;
> + fsl,iommu-parent = <&pamu1>;
> + };
This error interrupt is documented as 13, not 18. b4860 (and maybe other b4?)
have an erratum that says that error interrupts are reversed, but this is
generally implemented in b4si-post.dtsi, not in block-specific include files.
Will no chip without the erratum ever have maple?
[Leekha Shaveta-B20052] You are right here. Will add the interrupts in b4si or
b4860si file, as other chips may have maple.
Regards,
Shaveta
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC 1/2] fsl/pm: combined the idle(PH&PW) state
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 30, 2013 1:22 AM
> To: Wang Dongsheng-B40534
> Cc: b...@kernel.crashing.org; ga...@kernel.crashing.org; Zhao Chenhui-
> B35336; Li Yang-R58472; Wang Dongsheng-B40534
> Subject: Re: [RFC 1/2] fsl/pm: combined the idle(PH&PW) state
>
> On 07/10/2013 03:27:55 AM, Dongsheng Wang wrote:
> > From: Wang Dongsheng
> >
> > move wait instructions from idle_e500.S to idle_book3e.S
> >
> > idle_e500.S: rename e500_idle to e500_idle_ph.
>
> What does _ph mean?
>
> If this is a reference to the new PHnn/PWnn terminology used on e6500, I
> don't see how that's relevant to this file, which isn't used on e6500.
> Or if you do plan to use this on e6500, why?
>
ph10/ph15 means doze/nap on freescale e500 family processors. On the IBM
platform does not "ph" concept.
Yes, "ph" maybe that's not a good idea. We should keep e500_idle.
On e500 processor, there is doze/nap, but e500mc/e5500/e6500 is using "wait".
I want to move "wait" from idle_e500.S into idle_book3e.S, but "book3e" means
64bit mode... Now 32bit using idle_e500, 64bit using idle_book3e, and the idle
method
does not distinguish according to the platform, only in accordance with the CPU
running mode(32bit/64bit) to distinguish.
So did you have any idea about this? Or another way as follows,
We do not touch idle_e500.S and idle_e6500.S, add fsl_cpuidle_wait() into
"machdep.h"
arch/powerpc/include/asm/machdep.h
/* Wait for Interrupt */
static inline void fsl_cpuidle_wait(void)
{
#ifdef CONFIG_PPC64
book3e_idle();
#else
e500_idle();
#endif
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linux-pm] [PATCH 1/3] cpuidle/powernv: cpuidle backend driver for powernv
On 07/29/2013 08:23 PM, Daniel Lezcano wrote:
> On 07/29/2013 04:39 PM, Deepthi Dharwar wrote:
>> Hi Daniel,
>>
>> On 07/27/2013 10:57 AM, Daniel Lezcano wrote:
>>> On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
This patch implements a back-end cpuidle driver for
powernv calling power7_nap and snooze idle states.
This can be extended by adding more idle states
in the future to the existing framework.
Signed-off-by: Deepthi Dharwar
>
> [ ... ]
>
+static int snooze_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ int cpu = dev->cpu;
+
+ local_irq_enable();
+ set_thread_flag(TIF_POLLING_NRFLAG);
+
+ while ((!need_resched()) && cpu_online(cpu)) {
+ ppc64_runlatch_off();
+ HMT_very_low();
+ }
>>>
>>> Why are you using the cpu_online test here ?
>>
>> Snooze state is an idle state where cpu executes an infinite loop by
>> reducing the priority of the thread and the idle cpu can come out of it
>> only if need_resched is set or in case the cpu is offlined. In order to
>> continue executing this loop to remain in this idle state, we need the
>> check just to be safe.
>
> Yes, but if the cpu is offline you are no longer executing this code, no ?
>
Yes, not needed.
Thanks !
Deepthi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] cpuidle/powernv: Enable idle powernv cpu to call into the cpuidle framework.
On 07/29/2013 08:14 PM, Daniel Lezcano wrote:
> On 07/29/2013 04:27 PM, Deepthi Dharwar wrote:
>> On 07/27/2013 10:59 AM, Daniel Lezcano wrote:
>>> On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
This patch enables idle powernv cpu to hook on to the cpuidle
framework, if available, else call on to default idle platform
code.
>>>
>>> Why do you need to do that ?
>>>
>>
>> Hi Daniel,
>>
>> Well, this is needed in case when one does not compile with CPU_IDLE
>> config option.
>>
>> When CPUIDLE is not configured, idle cpus are needed to be running some
>> sort of default idle code or loop ( in the worst case) if cpuidle driver
>> is not registered or if one decides not to have that config enabled.
>
> Hi Deepthi,
>
> ok may be there is some difference with the other platform but the
> arch_cpu_idle function defined in the other archs do:
>
> void arch_cpu_idle(void)
> {
> if (cpuidle_idle_call())
> x86_idle();
> else
> local_irq_enable();
> }
>
> or
>
> void arch_cpu_idle(void)
> {
> if (cpuidle_idle_call())
> default_idle();
> }
>
> When the cpuidle driver is not compiled or not loaded, cpuidle_idle_call
> fails, falling back to the default idle function.
>
> The arch_cpu_idle function is called from the generic code in
> kernel/cpu/idle.c.
>
> Is there a particular reason to do it in a different way ?
On powerpc, we have another parameter, ppc_md.powersave
knob. In arch_cpu_idle, we check for this knob. This is kernel command
line parameter too. If this is not set then default idle is executed.
ppc_md is generic powerpc structure, which points to idle routine that
needs to be executed.
In arch_cpu_idle code for powerpc:
arch_cpu_idle()
{
if (ppc_md.powersave())
ppc_md.powersave()
} else
/* default idle */
}
Not all flavors of powerpc arch support cpuidle.
So only those that support, powersave is set to cpuidle backend call.
And this check is necessary there.
Regards,
Deepthi
> Thanks
> -- Daniel
>
>>>
Signed-off-by: Deepthi Dharwar
---
arch/powerpc/platforms/powernv/setup.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c
b/arch/powerpc/platforms/powernv/setup.c
index 84438af..97d0951 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -196,6 +197,15 @@ static int __init pnv_probe(void)
return 1;
}
+void powernv_idle(void)
+{
+ /* Hook to cpuidle framework if available, else
+ * call on default platform idle code
+ */
+ if (cpuidle_idle_call())
+ power7_idle();
+}
+
define_machine(powernv) {
.name = "PowerNV",
.probe = pnv_probe,
@@ -205,7 +215,7 @@ define_machine(powernv) {
.show_cpuinfo = pnv_show_cpuinfo,
.progress = pnv_progress,
.machine_shutdown = pnv_shutdown,
- .power_save = power7_idle,
+ .power_save = powernv_idle,
.calibrate_decr = generic_calibrate_decr,
#ifdef CONFIG_KEXEC
.kexec_cpu_down = pnv_kexec_cpu_down,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
>>>
>>>
>>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 30, 2013 1:27 AM
> To: Wang Dongsheng-B40534
> Cc: b...@kernel.crashing.org; ga...@kernel.crashing.org; Zhao Chenhui-
> B35336; Li Yang-R58472; Wang Dongsheng-B40534
> Subject: Re: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel
> features
>
> On 07/10/2013 03:27:56 AM, Dongsheng Wang wrote:
> > From: Wang Dongsheng
> >
> > Signed-off-by: Wang Dongsheng
> >
> > diff --git a/arch/powerpc/include/asm/cputable.h
> > b/arch/powerpc/include/asm/cputable.h
> > index 6f3887d..0a8d0cb 100644
> > --- a/arch/powerpc/include/asm/cputable.h
> > +++ b/arch/powerpc/include/asm/cputable.h
> > @@ -138,6 +138,7 @@ extern const char *powerpc_base_platform;
> > #define CPU_FTR_NOEXECUTE ASM_CONST(0x1000)
> > #define CPU_FTR_INDEXED_DCRASM_CONST(0x2000)
> > #define CPU_FTR_EMB_HV ASM_CONST(0x4000)
> > +#define CPU_FTR_CAN_WAIT ASM_CONST(0x8000)
>
> Note that this is the last 32-bit CPU feature flag; it's time to start
> thinking about other mechanisms. We should probably reserve feature
> flags for things that need to use code patching due to being on a
> performance critical path, and move other things into struct cpu_spec.
> CPU_FTR_CAN_WAIT seems like a good candidate to be moved.
>
First of all, why should I do, I need to distinguish between the core, which
is to support the wait instruction. The CPU_FTR_CAN_WAIT looks easy.
How to fix this problem:
1/ I can drop this cpu feature, and move it into struct cpu_spec.
Add a pm_feature in struct cpu_spec? like,
struct cpu_spec {
...
unsigned long pm_features;
...
}
2/ Drop this cpu feature, using CPU_FTRS_E6500/CPU_FTRS_E5500.. to distinguish
wait or doze/nap.
Like,
CPU_FTRS_E500/CPU_FTRS_E500_2 support doze/nap.
CPU_FTRS_E500MC/CPU_FTRS_E5500/CPU_FTRS_E6500 support wait.
If using this method, inside the cpuidle driver needs to do a lot of judgment.
So I'm not sure this
is a very good solution.
Thanks.
- dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: powerpc: kvm: add signed type cast for comparation
Hello Maintainers:
Please help check this patch whether OK or not, when you have time.
Thanks.
On 07/22/2013 02:32 PM, Chen Gang wrote:
> 'rmls' is 'unsigned long', lpcr_rmls() will return negative number when
> failure occurs, so it need a type cast for comparing.
>
> 'lpid' is 'unsigned long', kvmppc_alloc_lpid() return negative number
> when failure occurs, so it need a type cast for comparing.
>
>
> Signed-off-by: Chen Gang
> ---
> arch/powerpc/kvm/book3s_hv.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 2efa9dd..7629cd3 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1809,7 +1809,7 @@ static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu
> *vcpu)
> rma_size <<= PAGE_SHIFT;
> rmls = lpcr_rmls(rma_size);
> err = -EINVAL;
> - if (rmls < 0) {
> + if ((long)rmls < 0) {
> pr_err("KVM: Can't use RMA of 0x%lx bytes\n", rma_size);
> goto out_srcu;
> }
> @@ -1874,7 +1874,7 @@ int kvmppc_core_init_vm(struct kvm *kvm)
> /* Allocate the guest's logical partition ID */
>
> lpid = kvmppc_alloc_lpid();
> - if (lpid < 0)
> + if ((long)lpid < 0)
> return -ENOMEM;
> kvm->arch.lpid = lpid;
>
>
--
Chen Gang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4 v6] powerpc: export debug registers save function for KVM
Alexander Graf wrote:
>
> On 04.07.2013, at 08:57, Bharat Bhushan wrote:
>
> > KVM need this function when switching from vcpu to user-space
> > thread. My subsequent patch will use this function.
> >
> > Signed-off-by: Bharat Bhushan
>
> Ben / Michael, please ack.
It's not really my area of expertise, but it applies and compiles for me
and it's relatively simple, so FWIW...
Acked-by: Michael Neuling
>
>
> Alex
>
> > ---
> > v5->v6
> > - switch_booke_debug_regs() not guarded by the compiler switch
> >
> > arch/powerpc/include/asm/switch_to.h |1 +
> > arch/powerpc/kernel/process.c|3 ++-
> > 2 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/switch_to.h
> > b/arch/powerpc/include/asm/switch_to.h
> > index 200d763..db68f1d 100644
> > --- a/arch/powerpc/include/asm/switch_to.h
> > +++ b/arch/powerpc/include/asm/switch_to.h
> > @@ -29,6 +29,7 @@ extern void giveup_vsx(struct task_struct *);
> > extern void enable_kernel_spe(void);
> > extern void giveup_spe(struct task_struct *);
> > extern void load_up_spe(struct task_struct *);
> > +extern void switch_booke_debug_regs(struct thread_struct *new_thread);
> >
> > #ifndef CONFIG_SMP
> > extern void discard_lazy_cpu_state(void);
> > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> > index 01ff496..da586aa 100644
> > --- a/arch/powerpc/kernel/process.c
> > +++ b/arch/powerpc/kernel/process.c
> > @@ -362,12 +362,13 @@ static void prime_debug_regs(struct thread_struct
> > *thread)
> > * debug registers, set the debug registers from the values
> > * stored in the new thread.
> > */
> > -static void switch_booke_debug_regs(struct thread_struct *new_thread)
> > +void switch_booke_debug_regs(struct thread_struct *new_thread)
> > {
> > if ((current->thread.debug.dbcr0 & DBCR0_IDM)
> > || (new_thread->debug.dbcr0 & DBCR0_IDM))
> > prime_debug_regs(new_thread);
> > }
> > +EXPORT_SYMBOL_GPL(switch_booke_debug_regs);
> > #else /* !CONFIG_PPC_ADV_DEBUG_REGS */
> > #ifndef CONFIG_HAVE_HW_BREAKPOINT
> > static void set_debug_reg_defaults(struct thread_struct *thread)
> > --
> > 1.7.0.4
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 07/30/2013 06:10 AM, Scott Wood wrote: On 07/29/2013 05:49:03 AM, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds the device tree nodes for them. Signed-off-by: Hongbo Zhang --- .../devicetree/bindings/powerpc/fsl/dma.txt| 66 arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- 5 files changed, 232 insertions(+), 4 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi ACK Thank you Scott for all the review comments. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 0/3] DMA: Freescale: Add support for 8-channel DMA engine
On 07/29/2013 06:59 PM, Vinod Koul wrote: On Mon, Jul 29, 2013 at 06:49:01PM +0800, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches. The dma relates changes look okay to me. I need someone to review and ACK the DT bindings. Scott Wood has ACKed the [1/3] and [2/3]. Thank you Vinod. ~Vinod Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set adds support this DMA engine. V6->V7 changes: - only remove unnecessary "CHIP-dma" explanations in [1/3] V5->V6 changes: - minor updates of descriptions in binding document and Kconfig - remove [4/4], that should be another patch in future V4->V5 changes: - update description in the dt binding document, to make it more resonable - add new patch [4/4] to eliminate a compiling warning which already exists for a long time V3->V4 changes: - introduce new patch [1/3] to revise the legacy dma binding document - and then add new paragraph to describe new dt node binding in [2/3] - rebase to latest kernel v3.11-rc1 V2->V3 changes: - edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt - edit text string in Kconfig and the driver files, using "elo series" to mention all the current "elo*" V1->V2 changes: - removed the codes handling the register dgsr1, since it isn't used currently - renamed the DMA DT compatible to "fsl,elo3-dma" - renamed the new dts files to "elo3-dma-.dtsi" Hongbo Zhang (3): DMA: Freescale: revise device tree binding document DMA: Freescale: Add new 8-channel DMA engine device tree nodes DMA: Freescale: update driver to support 8-channel DMA engine .../devicetree/bindings/powerpc/fsl/dma.txt| 114 +++- arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- drivers/dma/Kconfig|9 +- drivers/dma/fsldma.c |9 +- drivers/dma/fsldma.h |2 +- 8 files changed, 264 insertions(+), 40 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] mmc:core: parse voltage from device-tree
On 07/30/2013 06:07 AM, Scott Wood wrote: On 07/28/2013 09:56:33 PM, Haijun Zhang wrote: Add function to support get voltage from device-tree. If there are voltage-range specified in device-tree node, this function will parse it and return the avail voltage mask. Signed-off-by: Haijun Zhang --- drivers/mmc/core/core.c | 48 include/linux/mmc/core.h | 1 + 2 files changed, 49 insertions(+) Move the code rather than copying it. -Scott Hi, Scott You mean? -- Thanks & Regards Haijun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/85xx: Add P1023RDB board support
On Fri, Jun 14, 2013 at 04:26:20PM +0800, Chunhe Lan wrote:
> P1023RDB Specification:
> ---
> Memory subsystem:
>512MB DDR3 (Fixed DDR on board)
>64MB NOR flash
>128MB NAND flash
Where is NAND in the device tree?
> Ethernet:
>eTSEC1: Connected to Atheros AR8035 GETH PHY
>eTSEC2: Connected to Atheros AR8035 GETH PHY
Where are the PHYs in the device tree?
> + partition@3f0 {
> + label = "firmware";
> + reg = <0x03f0 0x0008>;
> + read-only;
> + };
> + partition@3f8 {
> + label = "u-boot";
> + reg = <0x03f8 0x0008>;
> + read-only;
> + };
What is "firmware" if not U-Boot? FMan firmware? Note that part of your
"firmware" partition contains the U-Boot environment.
> diff --git a/arch/powerpc/configs/85xx/p1023rds_defconfig
> b/arch/powerpc/configs/85xx/p1023rds_defconfig
> index b80bcc6..092a746 100644
> --- a/arch/powerpc/configs/85xx/p1023rds_defconfig
> +++ b/arch/powerpc/configs/85xx/p1023rds_defconfig
> @@ -22,6 +22,7 @@ CONFIG_MODVERSIONS=y
> # CONFIG_BLK_DEV_BSG is not set
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_MAC_PARTITION=y
> +CONFIG_P1023_RDB=y
> CONFIG_P1023_RDS=y
> CONFIG_QUICC_ENGINE=y
> CONFIG_QE_GPIO=y
> @@ -67,6 +68,7 @@ CONFIG_PROC_DEVICETREE=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_SIZE=131072
> +CONFIG_EEPROM_AT24=y
> CONFIG_EEPROM_LEGACY=y
> CONFIG_BLK_DEV_SD=y
> CONFIG_CHR_DEV_ST=y
> @@ -102,6 +104,7 @@ CONFIG_SERIAL_8250_RSA=y
> CONFIG_SERIAL_QE=m
> CONFIG_NVRAM=y
> CONFIG_I2C=y
> +CONFIG_I2C_CHARDEV=y
> CONFIG_I2C_CPM=m
> CONFIG_I2C_MPC=y
> CONFIG_GPIO_MPC8XXX=y
> @@ -121,6 +124,7 @@ CONFIG_USB_STORAGE=y
> CONFIG_EDAC=y
> CONFIG_EDAC_MM_EDAC=y
> CONFIG_RTC_CLASS=y
> +CONFIG_RTC_DRV_DS1307=y
> CONFIG_RTC_DRV_CMOS=y
> CONFIG_DMADEVICES=y
> CONFIG_FSL_DMA=y
This isn't a p1023rds. Having one defconfig to support both boards is
good, but the defconfig should be renamed to p1023_defconfig.
> diff --git a/arch/powerpc/platforms/85xx/Kconfig
> b/arch/powerpc/platforms/85xx/Kconfig
> index efdd37c..d0e8ff9 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -111,6 +111,12 @@ config P1022_RDK
> This option enables support for the Freescale / iVeia P1022RDK
> reference board.
>
> +config P1023_RDB
> + bool "Freescale P1023 RDB"
> + select P1023_RDS
> + help
> + This option enables support for the P1023 RDB board
> +
Why do you need a new kconfig option, if you're supporting both boards
with the same C file? Just update the name and description of the
existing kconfig symbol.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add device file bindings for MAPLE
On Mon, 2013-07-29 at 19:00 -0500, Scott Wood wrote: > On 07/27/2013 08:03:42 AM, Shaveta Leekha wrote: > > Signed-off-by: Shaveta Leekha > > --- > > .../devicetree/bindings/powerpc/fsl/maple.txt | 50 > > BTW, that's confusing, we have a platform called maple ... oh well... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/1] MPC831x: fix PCI express probing
On Mon, May 27, 2013 at 02:29:43PM +0200, Sergey Gerasimov wrote:
> For MPC831x the bus probing function also needs the fixup to assign
> addresses to the PCI devices as it was for MPC85xx and MPC86xx.
> The fixup of the bridge vendor and device ID should be done early in
> PCI probing. Else the bridge is not detected as FIXUP_HEADER is called
> too late.
>
> Signed-off-by: Sergey Gerasimov
>
> ---
> arch/powerpc/sysdev/fsl_pci.c | 68 +++
> 1 file changed, 30 insertions(+), 38 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
> index 028ac1f..94d1bd4 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -84,6 +84,34 @@ static int fsl_pcie_check_link(struct pci_controller *hose)
> return 0;
> }
>
> +void fsl_pcibios_fixup_bus(struct pci_bus *bus)
> +{
> + struct pci_controller *hose = (struct pci_controller *) bus->sysdata;
> + int i;
> +
> +
> + if ((bus->parent == hose->bus)
> + && ((fsl_pcie_bus_fixup
> + && pci_bus_find_capability(bus, 0, PCI_CAP_ID_EXP))
> + || (hose->indirect_type
> + & PPC_INDIRECT_TYPE_NO_PCIE_LINK))) {
> + for (i = 0; i < 4; ++i) {
> + struct resource *res = bus->resource[i];
> + struct resource *par = bus->parent->resource[i];
> + if (res) {
> + res->start = 0;
> + res->end = 0;
> + res->flags = 0;
> + }
> + if (res && par) {
> + res->start = par->start;
> + res->end = par->end;
> + res->flags = par->flags;
> + }
> + }
> + }
> +}
Why are you moving this function? This makes it hardaer to see the
changes you make -- and is likely the cause of unintended changes being
made due to a bad conflict resolution. In particular, you seem to be
reverting commit 13635dfdc6aa8d2890e02dc441decfcb4ae63e14
("powerpc/fsl/pci: Fix PCIe fixup regression").
Also please confirm that the problem still exists in after "Fix PCIe
fixup regression".
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add device file bindings for MAPLE
On 07/27/2013 08:03:42 AM, Shaveta Leekha wrote:
Signed-off-by: Shaveta Leekha
---
.../devicetree/bindings/powerpc/fsl/maple.txt | 50
1 files changed, 50 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/powerpc/fsl/maple.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
new file mode 100644
index 000..23b80a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
@@ -0,0 +1,50 @@
+* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3
+ (MAPLE-B3)device nodes
+
+Supported chips:
+Example: B4860
+
+Required properties:
+
+- compatible: Should contain "fsl,maple-b3" as the value
+ This identifies Multi Accelerator Platform Engine
+ Baseband 3 block.
+
+- reg: offset and length of the register set for the
device
+
+- interrupts
+ Usage: required
+ Value type:
+ Definition: Specifies the interrupts generated by this
device. The
+ value of the interrupts property consists of
one interrupt
+ specifier. The format of the specifier is
defined by the
+ binding document describing the node's
interrupt parent.
Please clean up whitespace so the text aligns.
+
+ A single IRQ that handles error conditions is specified
by
+ this property. (Typically shared with port-write).
+
+Devices that have LIODNs need to specify links to the parent PAMU
controller
+(the actual PAMU controller that this device is connected to) and a
pointer to
+the LIODN register, if applicable.
+
+- fsl,iommu-parent
+ :
+ This property should be present
+
+- status = "disabled"
+ In this example, status is set "disabled",
+ As Maple device wouldn't be used by PPC Linux. This
representation is required
+ for doing the PAMU programming on the Linux side.
Is it proper for Linux to even set the LIODN on a device that is
"disabled"? Perhaps the compatible should be different, such as
"fsl,maple-b3-liodn" to indicate that that is the only portion of the
device that is owned by this partition.
+Example:
+ /* B4860 */
+
+ maple@80 {
+ #address-cells = <0>;
+ #size-cells = <0>;
+ status = "disabled";
+ compatible = "fsl,maple-b3";
+ reg = <0x800 0x1>;
+ interrupts = <16 2 1 18>;
+ fsl,iommu-parent = <&pamu1>;
+ };
This error interrupt is documented as 13, not 18. b4860 (and maybe
other b4?) have an erratum that says that error interrupts are
reversed, but this is generally implemented in b4si-post.dtsi, not in
block-specific include files. Will no chip without the erratum ever
have maple?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Update compilation flags with core specific options
On 07/25/2013 06:54:14 AM, Catalin Udma wrote: If CONFIG_E500 is enabled, the compilation flags are updated specifying the target core -mcpu=e5500/e500mc/8540 Also remove -Wa,-me500, being incompatible with -mcpu=e5500/e6500 The assembler option is redundant if the -mcpu= flag is set. The patch fixes the kernel compilation problem for e5500/e6500 when using gcc option -mcpu=e5500/e6500. Signed-off-by: Catalin Udma --- changes for v2: - update also KBUILD_AFLAGS with -mcpu and -msoft-float flags arch/powerpc/Makefile | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 0624909..cb5cbe2 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -140,6 +140,21 @@ ifeq ($(CONFIG_6xx),y) KBUILD_CFLAGS += -mcpu=powerpc endif +ifeq ($(CONFIG_E500),y) +ifeq ($(CONFIG_64BIT),y) +KBUILD_CFLAGS += -mcpu=e5500 +KBUILD_AFLAGS += -mcpu=e5500 -msoft-float +else +ifeq ($(CONFIG_PPC_E500MC),y) +KBUILD_CFLAGS += -mcpu=e500mc +KBUILD_AFLAGS += -mcpu=e500mc -msoft-float +else +KBUILD_CFLAGS += -mcpu=8540 +KBUILD_AFLAGS += -mcpu=8540 -msoft-float +endif +endif +endif Instead of specifying -msoft-float here, shouldn't it go on the main KBUILD_AFLAGS in arch/powerpc/Makefile, right next to where it's added for KBUILD_CFLAGS? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: P1021rdb-pc
On 07/25/2013 03:29:45 AM, BHARATHI KANDIMALLA wrote: Dear Sir, We are using P1021rdb-pc board with p1021 processor. 1. compilation and build process is taking so much of time. How should I reduce the time for linux build process? Remove things from the .config that you don't need. Be sure you're using a -j value that is large enough to keep all your CPUs busy. Use ccache. Get a faster build machine. :-) 2. In kernel configuration we are not able to select P1021rdb., When we configured the board for p1021RDB-PC , in default kenel config file all the below platforms are selected , We want only p1021rdb , what should we select here? CONFIG_PPC_CELL is not set CONFIG_FSL_SOC_BOOKE=y CONFIG_FSL_85XX_CACHE_SRAM=y CONFIG_MPC8540_ADS=y CONFIG_MPC8560_ADS=y CONFIG_MPC85xx_CDS=y CONFIG_MPC85xx_MDS=y CONFIG_MPC8536_DS=y CONFIG_MPC85xx_DS=y CONFIG_MPC85xx_RDB=y fsl,P1021RDB-PC is handled by mpc85xx_rdb.c (and thus CONFIG_MPC85xx_RDB). 3. We are using p1021 processor which has 36 bit support , but we have compiled uboot for 32 bit only.Is there any specfic use of 36 bit compilation, ? If your U-Boot is configured for 32 bits, there's no benefit to enabling CONFIG_PHYS_64BIT (unless you're remapping things yourself, such as moving the PCIe windows), and it can slow things down. 4. Now we are using SDK 1.3.2 for p1021 procesor .Is there any specific necessity that we should switch to sdk1.4 regarding linux drivers specially included for p1021 procesor? It's generally good to use more recent code for the various improvements and fixes it contains, but I don't know of a specific p1021-related requirement. Note that this list is for upstream Linux; for help with Freescale SDKs go to https://community.freescale.com/ Also note that p1021rdb-pc is supported in upstream Linux; you do not need to use the SDK at all unless there is something specific you need beyond basic board support. 5.UMCC driver is available in linux driver ? No. where should I get some help regarding UMCC ? community.freescale.com, supp...@freescale.com, or your sales/FAE contact. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] powerpc: Convert platforms to smp_generic_cpu_bootable
T4, Cell, powernv, and pseries had the same implementation, so switch
them to use a generic version. A2 apparently had a version, but
removed it at some point, so we remove the declaration, too.
Signed-off-by: Andy Fleming
---
v2: Removed conflict and Change-Id foo
arch/powerpc/platforms/85xx/smp.c|1 +
arch/powerpc/platforms/cell/smp.c| 15 +--
arch/powerpc/platforms/powernv/smp.c | 18 +-
arch/powerpc/platforms/pseries/smp.c | 18 +-
arch/powerpc/platforms/wsp/wsp.h |1 -
5 files changed, 4 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 5ced4f5..ea9c626 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -255,6 +255,7 @@ out:
struct smp_ops_t smp_85xx_ops = {
.kick_cpu = smp_85xx_kick_cpu,
+ .cpu_bootable = smp_generic_cpu_bootable,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_disable= generic_cpu_disable,
.cpu_die= generic_cpu_die,
diff --git a/arch/powerpc/platforms/cell/smp.c
b/arch/powerpc/platforms/cell/smp.c
index f75f6fc..90745ea 100644
--- a/arch/powerpc/platforms/cell/smp.c
+++ b/arch/powerpc/platforms/cell/smp.c
@@ -136,25 +136,12 @@ static int smp_cell_kick_cpu(int nr)
return 0;
}
-static int smp_cell_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
-* during boot if the user requests it. Odd-numbered
-* cpus are assumed to be secondary threads.
-*/
- if (system_state == SYSTEM_BOOTING &&
- cpu_has_feature(CPU_FTR_SMT) &&
- !smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
- return 0;
-
- return 1;
-}
static struct smp_ops_t bpa_iic_smp_ops = {
.message_pass = iic_message_pass,
.probe = smp_iic_probe,
.kick_cpu = smp_cell_kick_cpu,
.setup_cpu = smp_cell_setup_cpu,
- .cpu_bootable = smp_cell_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
};
/* This is called very early */
diff --git a/arch/powerpc/platforms/powernv/smp.c
b/arch/powerpc/platforms/powernv/smp.c
index 89e3857..908672b 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -46,22 +46,6 @@ static void pnv_smp_setup_cpu(int cpu)
xics_setup_cpu();
}
-static int pnv_smp_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
-* during boot if the user requests it.
-*/
- if (system_state == SYSTEM_BOOTING && cpu_has_feature(CPU_FTR_SMT)) {
- if (!smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
- return 0;
- if (smt_enabled_at_boot
- && cpu_thread_in_core(nr) >= smt_enabled_at_boot)
- return 0;
- }
-
- return 1;
-}
-
int pnv_smp_kick_cpu(int nr)
{
unsigned int pcpu = get_hard_smp_processor_id(nr);
@@ -195,7 +179,7 @@ static struct smp_ops_t pnv_smp_ops = {
.probe = xics_smp_probe,
.kick_cpu = pnv_smp_kick_cpu,
.setup_cpu = pnv_smp_setup_cpu,
- .cpu_bootable = pnv_smp_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_disable= pnv_smp_cpu_disable,
.cpu_die= generic_cpu_die,
diff --git a/arch/powerpc/platforms/pseries/smp.c
b/arch/powerpc/platforms/pseries/smp.c
index 306643c..ca2d1f6 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -187,22 +187,6 @@ static int smp_pSeries_kick_cpu(int nr)
return 0;
}
-static int smp_pSeries_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
-* during boot if the user requests it.
-*/
- if (system_state == SYSTEM_BOOTING && cpu_has_feature(CPU_FTR_SMT)) {
- if (!smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
- return 0;
- if (smt_enabled_at_boot
- && cpu_thread_in_core(nr) >= smt_enabled_at_boot)
- return 0;
- }
-
- return 1;
-}
-
/* Only used on systems that support multiple IPI mechanisms */
static void pSeries_cause_ipi_mux(int cpu, unsigned long data)
{
@@ -237,7 +221,7 @@ static struct smp_ops_t pSeries_xics_smp_ops = {
.probe = pSeries_smp_probe,
.kick_cpu = smp_pSeries_kick_cpu,
.setup_cpu = smp_xics_setup_cpu,
- .cpu_bootable = smp_pSeries_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
};
/* This is called very early */
diff --git a/arch/powerpc/platforms/wsp/wsp.h b/arch/powerpc/platforms/wsp/wsp.h
index 62ef21a..a563a8a 100644
--- a/arch/powerpc/platforms/wsp/wsp.h
+++ b/arch/powerpc/platforms/wsp/wsp.h
@
[PATCH v2 1/2] powerpc: Add smp_generic_cpu_bootable
Cell and PSeries both implemented their own versions of a
cpu_bootable smp_op which do the same thing (well, the PSeries
one has support for more than 2 threads). Copy the PSeries one
to generic code, and rename it smp_generic_cpu_bootable.
Signed-off-by: Andy Fleming
---
v2: Removed Change-Id
arch/powerpc/include/asm/smp.h |2 ++
arch/powerpc/kernel/smp.c | 23 +++
2 files changed, 25 insertions(+)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index ffbaabe..f2b5d41 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -182,6 +182,8 @@ extern int smt_enabled_at_boot;
extern int smp_mpic_probe(void);
extern void smp_mpic_setup_cpu(int cpu);
extern int smp_generic_kick_cpu(int nr);
+extern int smp_generic_cpu_bootable(unsigned int nr);
+
extern void smp_generic_give_timebase(void);
extern void smp_generic_take_timebase(void);
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 38b0ba6..3cd42aa 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -81,6 +81,29 @@ int smt_enabled_at_boot = 1;
static void (*crash_ipi_function_ptr)(struct pt_regs *) = NULL;
+/*
+ * Returns 1 if the specified cpu should be brought up during boot.
+ * Used to inhibit booting threads if they've been disabled or
+ * limited on the command line
+ */
+int smp_generic_cpu_bootable(unsigned int nr)
+{
+ /* Special case - we inhibit secondary thread startup
+* during boot if the user requests it.
+*/
+ if (system_state == SYSTEM_BOOTING && cpu_has_feature(CPU_FTR_SMT)) {
+ if (!smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
+ return 0;
+ if (smt_enabled_at_boot
+ && cpu_thread_in_core(nr) >= smt_enabled_at_boot)
+ return 0;
+ }
+
+ return 1;
+}
+EXPORT_SYMBOL(smp_generic_cpu_bootable);
+
+
#ifdef CONFIG_PPC64
int smp_generic_kick_cpu(int nr)
{
--
1.7.9.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: visible memory seems wrong in kexec crash dump kernel
On 07/13/2013 01:30:50 AM, Chris Friesen wrote: On 07/12/2013 04:59 PM, Chris Friesen wrote: On 07/12/2013 03:08 PM, Chris Friesen wrote: I turned on the instrumentation in early_init_dt_scan_memory() and got the following when jumping to the capture kernel: memory scan node memory, reg size 16, data: 0 0 2 0, - 0 , 2 That 0x2 matches the fact that I'm seeing 8GB of memory available in the recovery kernel. If I boot the original kernel with "crashkernel=224M@32M", should I expect that only 224MB is marked as "linux,usable-memory" in the recovery kernel? I started looking at the kexec side of things, and I noticed something a bit odd. In most places dealing with the device tree in kexec it accepts either "memory" or "memory@" for the memory node name. In add_usable_mem_property() in arch/ppc64/fs2dt.c it seems to only accept "memory@". Is this expected behaviour? It seems to be the same in current git versions of kexec-tools. On my system I see "/proc/device-tree/memory". If I modify add_usable_mem_property() to also accept "/memory" then my recovery kernel boots up with physicalMemorySize = 0x1000 which is 256MB (which is still a bit odd since I specified 224MB for the crashkernel). However, it then hits the BUG() call at the end of mark_bootmem() in mm/bootmem.c. One final thing and I'll stop replying to myself. :) It looks like the problem is that some board-specific freescale code was calling lmb_reserve() with a base address in the 4GB range. It seems odd that lmb_reserve() didn't throw some kind of error when the recovery kernel was supposed to be limited to 224MB. Rather than try and fix the bug, I turned off the (unneeded) config options related to the above lmb_reserve() calls and was able to successfully access the information I needed via /dev/oldmem. The upshot is that there seems to be a number of things that could be improved: 1) kexec should accept "/memory" and not just "/memory@" 2) lmb_reserve() should really respect the crashkernel memory limit 3) the freescale stuff really shouldn't assume it can map things wherever it feels like What "board-specific freescale code" are you referring to? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 07/29/2013 05:49:03 AM, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds the device tree nodes for them. Signed-off-by: Hongbo Zhang --- .../devicetree/bindings/powerpc/fsl/dma.txt| 66 arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- 5 files changed, 232 insertions(+), 4 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi ACK -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/3] DMA: Freescale: revise device tree binding document
On 07/29/2013 05:49:02 AM, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang This patch updates the discription of each type of DMA controller and its channels, it is preparation for adding another new DMA controller binding, it also fixes some defects of indent for text alignment at the same time. Signed-off-by: Hongbo Zhang ACK, but next time please do the whitespace fixes as a separate patch so that it's easier to see what's actually changing. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] mmc:core: parse voltage from device-tree
On 07/28/2013 09:56:33 PM, Haijun Zhang wrote: Add function to support get voltage from device-tree. If there are voltage-range specified in device-tree node, this function will parse it and return the avail voltage mask. Signed-off-by: Haijun Zhang --- drivers/mmc/core/core.c | 48 include/linux/mmc/core.h | 1 + 2 files changed, 49 insertions(+) Move the code rather than copying it. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN
On Monday, July 29, 2013 12:34:24 PM Joe Perches wrote:
> On Mon, 2013-07-29 at 13:59 +0200, Rafael J. Wysocki wrote:
> > On Sunday, July 28, 2013 10:29:04 PM Joe Perches wrote:
> > > It's convenient to have ethernet mac addresses use
> > > ETH_ALEN to be able to grep for them a bit easier and
> > > also to ensure that the addresses are __aligned(2).
> []
> > > diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
> []
> > > @@ -44,6 +44,8 @@
> []
> > > +#include
> > > +
> []
> > > @@ -605,7 +607,7 @@ struct acpi_ibft_nic {
> []
> > > - u8 mac_address[6];
> > > + u8 mac_address[ETH_ALEN];
>
> > Please don't touch this file.
> >
> > It comes from a code base outside of the kernel and should be kept in sync
> > with
> > the upstream.
>
> Which files in include/acpi have this characteristic?
Generally, all whose names start with "ac" except for acpi_bus.h,
acpi_drivers.h and acpi_numa.h.
> Perhaps an include/acpi/README is appropriate.
Yes, we can add one.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN
On Mon, 2013-07-29 at 13:59 +0200, Rafael J. Wysocki wrote:
> On Sunday, July 28, 2013 10:29:04 PM Joe Perches wrote:
> > It's convenient to have ethernet mac addresses use
> > ETH_ALEN to be able to grep for them a bit easier and
> > also to ensure that the addresses are __aligned(2).
[]
> > diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
[]
> > @@ -44,6 +44,8 @@
[]
> > +#include
> > +
[]
> > @@ -605,7 +607,7 @@ struct acpi_ibft_nic {
[]
> > - u8 mac_address[6];
> > + u8 mac_address[ETH_ALEN];
> Please don't touch this file.
>
> It comes from a code base outside of the kernel and should be kept in sync
> with
> the upstream.
Which files in include/acpi have this characteristic?
Perhaps an include/acpi/README is appropriate.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] powerpc/85xx: Add C293PCIE board support
On 07/28/2013 09:20:11 PM, Liu Po-B43644 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, July 27, 2013 5:59 AM
> To: Liu Po-B43644
> Cc: linuxppc-...@ozlabs.org; ga...@kernel.crashing.org; Fleming
Andy-
> AFLEMING; Hu Mingkai-B21284; Liu Po-B43644
> Subject: Re: [PATCH v2 3/3] powerpc/85xx: Add C293PCIE board
support
>
> On 07/25/2013 09:41:19 PM, Po Liu wrote:
> > +partition@190 {
> > +/* 7MB for User Area */
> > +reg = <0x0190 0x0070>;
> > +label = "NAND User area";
> > +};
> > +
> > +partition@200 {
> > +/* 96MB for Root File System */
> > +reg = <0x0200 0x0600>;
> > +label = "NAND Root File System";
> > +};
> > +
> > +partition@800 {
> > +/* 3968MB for Others */
> > +reg = <0x0800 0xF800>;
> > +label = "NAND Others";
> > +};
>
> Again, what is the difference between "user area" and "others"?
I'm not
> even sure why it needs to be separate from "root file system", but
at
> least the root filesystem should be larger given the size of the
overall
> flash.
Do you mean just merge up four partition into one "RFS"? Or merge up
four partition into "RFS" and "User area" is better?
If you don't have a reason for separating them, then probably yes,
merge them all into one. If you do keep RFS and "user area" separate,
then "user area" should be the larger of the two, but the RFS should be
more than just 96 MiB.
> > +partition@58 {
> > +/* 10.5MB for Compressed RFS
Image */
> > +reg = <0x0058 0x00a8>;
> > +label = "SPI Flash Compressed
RFSImage";
> > +};
>
> Space before "Image". Why specifiy that it's compressed, versus
some
> other filesystem type?
>
Remove all the "compressed" comments when express the RFS partition?
Yes.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linux-pm] [PATCH 1/3] cpuidle/powernv: cpuidle backend driver for powernv
On 07/29/2013 04:39 PM, Deepthi Dharwar wrote:
> Hi Daniel,
>
> On 07/27/2013 10:57 AM, Daniel Lezcano wrote:
>> On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
>>> This patch implements a back-end cpuidle driver for
>>> powernv calling power7_nap and snooze idle states.
>>> This can be extended by adding more idle states
>>> in the future to the existing framework.
>>>
>>> Signed-off-by: Deepthi Dharwar
[ ... ]
>>> +static int snooze_loop(struct cpuidle_device *dev,
>>> + struct cpuidle_driver *drv,
>>> + int index)
>>> +{
>>> + int cpu = dev->cpu;
>>> +
>>> + local_irq_enable();
>>> + set_thread_flag(TIF_POLLING_NRFLAG);
>>> +
>>> + while ((!need_resched()) && cpu_online(cpu)) {
>>> + ppc64_runlatch_off();
>>> + HMT_very_low();
>>> + }
>>
>> Why are you using the cpu_online test here ?
>
> Snooze state is an idle state where cpu executes an infinite loop by
> reducing the priority of the thread and the idle cpu can come out of it
> only if need_resched is set or in case the cpu is offlined. In order to
> continue executing this loop to remain in this idle state, we need the
> check just to be safe.
Yes, but if the cpu is offline you are no longer executing this code, no ?
--
Facebook |
Twitter |
Re: [PATCH 2/3] cpuidle/powernv: Enable idle powernv cpu to call into the cpuidle framework.
On 07/29/2013 04:27 PM, Deepthi Dharwar wrote:
> On 07/27/2013 10:59 AM, Daniel Lezcano wrote:
>> On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
>>> This patch enables idle powernv cpu to hook on to the cpuidle
>>> framework, if available, else call on to default idle platform
>>> code.
>>
>> Why do you need to do that ?
>>
>
> Hi Daniel,
>
> Well, this is needed in case when one does not compile with CPU_IDLE
> config option.
>
> When CPUIDLE is not configured, idle cpus are needed to be running some
> sort of default idle code or loop ( in the worst case) if cpuidle driver
> is not registered or if one decides not to have that config enabled.
Hi Deepthi,
ok may be there is some difference with the other platform but the
arch_cpu_idle function defined in the other archs do:
void arch_cpu_idle(void)
{
if (cpuidle_idle_call())
x86_idle();
else
local_irq_enable();
}
or
void arch_cpu_idle(void)
{
if (cpuidle_idle_call())
default_idle();
}
When the cpuidle driver is not compiled or not loaded, cpuidle_idle_call
fails, falling back to the default idle function.
The arch_cpu_idle function is called from the generic code in
kernel/cpu/idle.c.
Is there a particular reason to do it in a different way ?
Thanks
-- Daniel
>>
>>> Signed-off-by: Deepthi Dharwar
>>> ---
>>> arch/powerpc/platforms/powernv/setup.c | 12 +++-
>>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/platforms/powernv/setup.c
>>> b/arch/powerpc/platforms/powernv/setup.c
>>> index 84438af..97d0951 100644
>>> --- a/arch/powerpc/platforms/powernv/setup.c
>>> +++ b/arch/powerpc/platforms/powernv/setup.c
>>> @@ -25,6 +25,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>> #include
>>> @@ -196,6 +197,15 @@ static int __init pnv_probe(void)
>>> return 1;
>>> }
>>>
>>> +void powernv_idle(void)
>>> +{
>>> + /* Hook to cpuidle framework if available, else
>>> +* call on default platform idle code
>>> +*/
>>> + if (cpuidle_idle_call())
>>> + power7_idle();
>>> +}
>>> +
>>> define_machine(powernv) {
>>> .name = "PowerNV",
>>> .probe = pnv_probe,
>>> @@ -205,7 +215,7 @@ define_machine(powernv) {
>>> .show_cpuinfo = pnv_show_cpuinfo,
>>> .progress = pnv_progress,
>>> .machine_shutdown = pnv_shutdown,
>>> - .power_save = power7_idle,
>>> + .power_save = powernv_idle,
>>> .calibrate_decr = generic_calibrate_decr,
>>> #ifdef CONFIG_KEXEC
>>> .kexec_cpu_down = pnv_kexec_cpu_down,
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>
>>
>
--
Facebook |
Twitter |
Re: [linux-pm] [PATCH 1/3] cpuidle/powernv: cpuidle backend driver for powernv
Hi Daniel,
On 07/27/2013 10:57 AM, Daniel Lezcano wrote:
> On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
>> This patch implements a back-end cpuidle driver for
>> powernv calling power7_nap and snooze idle states.
>> This can be extended by adding more idle states
>> in the future to the existing framework.
>>
>> Signed-off-by: Deepthi Dharwar
>> ---
>> arch/powerpc/platforms/powernv/Kconfig |9 +
>> arch/powerpc/platforms/powernv/Makefile |1
>> arch/powerpc/platforms/powernv/processor_idle.c | 239
>> +++
>> 3 files changed, 249 insertions(+)
>> create mode 100644 arch/powerpc/platforms/powernv/processor_idle.c
>>
>> diff --git a/arch/powerpc/platforms/powernv/Kconfig
>> b/arch/powerpc/platforms/powernv/Kconfig
>> index c24684c..ace2d22 100644
>> --- a/arch/powerpc/platforms/powernv/Kconfig
>> +++ b/arch/powerpc/platforms/powernv/Kconfig
>> @@ -20,3 +20,12 @@ config PPC_POWERNV_RTAS
>> default y
>> select PPC_ICS_RTAS
>> select PPC_RTAS
>> +
>> +config POWERNV_IDLE
>> +bool "CPUIdle driver for powernv platform"
>> +depends on CPU_IDLE
>> +depends on PPC_POWERNV
>> +default y
>> +help
>> +Select this option to enable processor idle state management
>> +through cpuidle subsystem.
>> diff --git a/arch/powerpc/platforms/powernv/Makefile
>> b/arch/powerpc/platforms/powernv/Makefile
>> index 7fe5951..c0e44eb 100644
>> --- a/arch/powerpc/platforms/powernv/Makefile
>> +++ b/arch/powerpc/platforms/powernv/Makefile
>> @@ -4,3 +4,4 @@ obj-y+= opal-rtc.o opal-nvram.o
>> obj-$(CONFIG_SMP) += smp.o
>> obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o
>> obj-$(CONFIG_EEH) += eeh-ioda.o eeh-powernv.o
>> +obj-$(CONFIG_POWERNV_IDLE) += processor_idle.o
>> diff --git a/arch/powerpc/platforms/powernv/processor_idle.c
>> b/arch/powerpc/platforms/powernv/processor_idle.c
>> new file mode 100644
>> index 000..f43ad91a
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/powernv/processor_idle.c
>> @@ -0,0 +1,239 @@
>> +/*
>> + * processor_idle - idle state cpuidle driver.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +
>> +struct cpuidle_driver powernv_idle_driver = {
>> +.name = "powernv_idle",
>> +.owner =THIS_MODULE,
>> +};
>> +
>> +#define MAX_IDLE_STATE_COUNT2
>> +
>> +static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
>> +static struct cpuidle_device __percpu *powernv_cpuidle_devices;
>> +static struct cpuidle_state *cpuidle_state_table;
>> +
>> +static int snooze_loop(struct cpuidle_device *dev,
>> +struct cpuidle_driver *drv,
>> +int index)
>> +{
>> +int cpu = dev->cpu;
>> +
>> +local_irq_enable();
>> +set_thread_flag(TIF_POLLING_NRFLAG);
>> +
>> +while ((!need_resched()) && cpu_online(cpu)) {
>> +ppc64_runlatch_off();
>> +HMT_very_low();
>> +}
>
> Why are you using the cpu_online test here ?
Snooze state is an idle state where cpu executes an infinite loop by
reducing the priority of the thread and the idle cpu can come out of it
only if need_resched is set or in case the cpu is offlined. In order to
continue executing this loop to remain in this idle state, we need the
check just to be safe.
>> +
>> +HMT_medium();
>> +clear_thread_flag(TIF_POLLING_NRFLAG);
>> +smp_mb();
>> +return index;
>> +}
>> +
>> +
>> +static int nap_loop(struct cpuidle_device *dev,
>> +struct cpuidle_driver *drv,
>> +int index)
>> +{
>> +ppc64_runlatch_off();
>> +power7_idle();
>> +return index;
>> +}
>> +
>> +/*
>> + * States for dedicated partition case.
>> + */
>> +static struct cpuidle_state powernv_states[MAX_IDLE_STATE_COUNT] = {
>> +{ /* Snooze */
>> +.name = "snooze",
>> +.desc = "snooze",
>> +.flags = CPUIDLE_FLAG_TIME_VALID,
>> +.exit_latency = 0,
>> +.target_residency = 0,
>> +.enter = &snooze_loop },
>> + { /* Nap */
>> +.name = "Nap",
>> +.desc = "Nap",
>> +.flags = CPUIDLE_FLAG_TIME_VALID,
>> +.exit_latency = 10,
>> +.target_residency = 100,
>> +.enter = &nap_loop },
>> +};
>> +
>> +static int powernv_cpuidle_add_cpu_notifier(struct notifier_block *n,
>> +unsigned long action, void *hcpu)
>> +{
>> +int hotcpu = (unsigned long)hcpu;
>> +struct cpuidle_device *dev =
>> +per_cpu_ptr(powernv_cpuidle_devices, hotcpu);
>> +
>> +if (dev && cpuidle_get_driver()) {
>> +switch (action) {
>> +case CPU_ONLINE:
>> +case CPU_ONLINE_FROZEN:
>> +cpuidle_pause_and_lock();
>> +cpuidle_enable_device(dev);
>> +cpuidle_r
Re: [PATCH 2/3] cpuidle/powernv: Enable idle powernv cpu to call into the cpuidle framework.
On 07/27/2013 10:59 AM, Daniel Lezcano wrote:
> On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
>> This patch enables idle powernv cpu to hook on to the cpuidle
>> framework, if available, else call on to default idle platform
>> code.
>
> Why do you need to do that ?
>
Hi Daniel,
Well, this is needed in case when one does not compile with CPU_IDLE
config option.
When CPUIDLE is not configured, idle cpus are needed to be running some
sort of default idle code or loop ( in the worst case) if cpuidle driver
is not registered or if one decides not to have that config enabled.
Regards,
Deepthi
>
>> Signed-off-by: Deepthi Dharwar
>> ---
>> arch/powerpc/platforms/powernv/setup.c | 12 +++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/setup.c
>> b/arch/powerpc/platforms/powernv/setup.c
>> index 84438af..97d0951 100644
>> --- a/arch/powerpc/platforms/powernv/setup.c
>> +++ b/arch/powerpc/platforms/powernv/setup.c
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -196,6 +197,15 @@ static int __init pnv_probe(void)
>> return 1;
>> }
>>
>> +void powernv_idle(void)
>> +{
>> +/* Hook to cpuidle framework if available, else
>> + * call on default platform idle code
>> + */
>> +if (cpuidle_idle_call())
>> +power7_idle();
>> +}
>> +
>> define_machine(powernv) {
>> .name = "PowerNV",
>> .probe = pnv_probe,
>> @@ -205,7 +215,7 @@ define_machine(powernv) {
>> .show_cpuinfo = pnv_show_cpuinfo,
>> .progress = pnv_progress,
>> .machine_shutdown = pnv_shutdown,
>> -.power_save = power7_idle,
>> +.power_save = powernv_idle,
>> .calibrate_decr = generic_calibrate_decr,
>> #ifdef CONFIG_KEXEC
>> .kexec_cpu_down = pnv_kexec_cpu_down,
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN
On Sunday, July 28, 2013 10:29:04 PM Joe Perches wrote:
> It's convenient to have ethernet mac addresses use
> ETH_ALEN to be able to grep for them a bit easier and
> also to ensure that the addresses are __aligned(2).
>
> Add #include as necessary.
>
> Signed-off-by: Joe Perches
> ---
> include/acpi/actbl2.h | 4 ++-
> include/linux/dm9000.h | 4 ++-
> include/linux/fs_enet_pd.h | 3 ++-
> include/linux/ieee80211.h | 59
> +
> include/linux/mlx4/device.h | 11
> include/linux/mlx4/qp.h | 5 ++--
> include/linux/mv643xx_eth.h | 3 ++-
> include/linux/sh_eth.h | 3 ++-
> include/linux/smsc911x.h| 3 ++-
> include/linux/uwb/spec.h| 5 ++--
> include/media/tveeprom.h| 4 ++-
> include/net/irda/irlan_common.h | 3 ++-
> 12 files changed, 61 insertions(+), 46 deletions(-)
>
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
> index ffaac0e..3f0f11c 100644
> --- a/include/acpi/actbl2.h
> +++ b/include/acpi/actbl2.h
> @@ -44,6 +44,8 @@
> #ifndef __ACTBL2_H__
> #define __ACTBL2_H__
>
> +#include
> +
>
> /***
> *
> * Additional ACPI Tables (2)
> @@ -605,7 +607,7 @@ struct acpi_ibft_nic {
> u8 secondary_dns[16];
> u8 dhcp[16];
> u16 vlan;
> - u8 mac_address[6];
> + u8 mac_address[ETH_ALEN];
> u16 pci_address;
> u16 name_length;
> u16 name_offset;
Please don't touch this file.
It comes from a code base outside of the kernel and should be kept in sync with
the upstream.
Thanks,
Rafael
> diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
> index 96e8769..841925f 100644
> --- a/include/linux/dm9000.h
> +++ b/include/linux/dm9000.h
> @@ -14,6 +14,8 @@
> #ifndef __DM9000_PLATFORM_DATA
> #define __DM9000_PLATFORM_DATA __FILE__
>
> +#include
> +
> /* IO control flags */
>
> #define DM9000_PLATF_8BITONLY(0x0001)
> @@ -27,7 +29,7 @@
>
> struct dm9000_plat_data {
> unsigned intflags;
> - unsigned char dev_addr[6];
> + unsigned char dev_addr[ETH_ALEN];
>
> /* allow replacement IO routines */
>
> diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
> index 51b7934..343d82a 100644
> --- a/include/linux/fs_enet_pd.h
> +++ b/include/linux/fs_enet_pd.h
> @@ -18,6 +18,7 @@
>
> #include
> #include
> +#include
> #include
>
> #define FS_ENET_NAME "fs_enet"
> @@ -135,7 +136,7 @@ struct fs_platform_info {
> const struct fs_mii_bus_info *bus_info;
>
> int rx_ring, tx_ring; /* number of buffers on rx */
> - __u8 macaddr[6];/* mac address */
> + __u8 macaddr[ETH_ALEN]; /* mac address */
> int rx_copybreak; /* limit we copy small frames */
> int use_napi; /* use NAPI*/
> int napi_weight;/* NAPI weight */
> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> index b0dc87a..4e101af 100644
> --- a/include/linux/ieee80211.h
> +++ b/include/linux/ieee80211.h
> @@ -16,6 +16,7 @@
> #define LINUX_IEEE80211_H
>
> #include
> +#include
> #include
>
> /*
> @@ -209,28 +210,28 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
> struct ieee80211_hdr {
> __le16 frame_control;
> __le16 duration_id;
> - u8 addr1[6];
> - u8 addr2[6];
> - u8 addr3[6];
> + u8 addr1[ETH_ALEN];
> + u8 addr2[ETH_ALEN];
> + u8 addr3[ETH_ALEN];
> __le16 seq_ctrl;
> - u8 addr4[6];
> + u8 addr4[ETH_ALEN];
> } __packed __aligned(2);
>
> struct ieee80211_hdr_3addr {
> __le16 frame_control;
> __le16 duration_id;
> - u8 addr1[6];
> - u8 addr2[6];
> - u8 addr3[6];
> + u8 addr1[ETH_ALEN];
> + u8 addr2[ETH_ALEN];
> + u8 addr3[ETH_ALEN];
> __le16 seq_ctrl;
> } __packed __aligned(2);
>
> struct ieee80211_qos_hdr {
> __le16 frame_control;
> __le16 duration_id;
> - u8 addr1[6];
> - u8 addr2[6];
> - u8 addr3[6];
> + u8 addr1[ETH_ALEN];
> + u8 addr2[ETH_ALEN];
> + u8 addr3[ETH_ALEN];
> __le16 seq_ctrl;
> __le16 qos_ctrl;
> } __packed __aligned(2);
> @@ -608,8 +609,8 @@ struct ieee80211s_hdr {
> u8 flags;
> u8 ttl;
> __le32 seqnum;
> - u8 eaddr1[6];
> - u8 eaddr2[6];
> + u8 eaddr1[ETH_ALEN];
> + u8 eaddr2[ETH_ALEN];
> } __packed __aligned(2);
>
> /* Mesh flags */
> @@ -758,7 +759,7 @@ struct ieee80211_rann_ie {
> u8 rann_flags;
> u8 rann_hopcount;
> u8 rann_ttl;
> - u8 rann_addr[6];
> + u8 rann_addr[ETH_ALEN];
> __le32 rann_seq;
> __le32 rann_interval;
> __le32 rann_metric;
> @@ -802,9 +803,9 @@ enum ieee80211_vht_opmode_bits {
> struct ieee80211_mgmt {
> __le16 frame_control;
> __le16 duration;
> - u8 da
Re: [PATCH v7 0/3] DMA: Freescale: Add support for 8-channel DMA engine
On Mon, Jul 29, 2013 at 06:49:01PM +0800, hongbo.zh...@freescale.com wrote: > From: Hongbo Zhang > > Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches. The dma relates changes look okay to me. I need someone to review and ACK the DT bindings. ~Vinod > > Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set > adds support this DMA engine. > > V6->V7 changes: > - only remove unnecessary "CHIP-dma" explanations in [1/3] > > V5->V6 changes: > - minor updates of descriptions in binding document and Kconfig > - remove [4/4], that should be another patch in future > > V4->V5 changes: > - update description in the dt binding document, to make it more resonable > - add new patch [4/4] to eliminate a compiling warning which already exists > for a long time > > V3->V4 changes: > - introduce new patch [1/3] to revise the legacy dma binding document > - and then add new paragraph to describe new dt node binding in [2/3] > - rebase to latest kernel v3.11-rc1 > > V2->V3 changes: > - edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt > - edit text string in Kconfig and the driver files, using "elo series" to > mention all the current "elo*" > > V1->V2 changes: > - removed the codes handling the register dgsr1, since it isn't used currently > - renamed the DMA DT compatible to "fsl,elo3-dma" > - renamed the new dts files to "elo3-dma-.dtsi" > > Hongbo Zhang (3): > DMA: Freescale: revise device tree binding document > DMA: Freescale: Add new 8-channel DMA engine device tree nodes > DMA: Freescale: update driver to support 8-channel DMA engine > > .../devicetree/bindings/powerpc/fsl/dma.txt| 114 > +++- > arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- > arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 ++ > arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 ++ > arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- > drivers/dma/Kconfig|9 +- > drivers/dma/fsldma.c |9 +- > drivers/dma/fsldma.h |2 +- > 8 files changed, 264 insertions(+), 40 deletions(-) > create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi > create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi > > -- > 1.7.9.5 > > > -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
From: Hongbo Zhang
This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang
---
drivers/dma/Kconfig |9 +
drivers/dma/fsldma.c |9 ++---
drivers/dma/fsldma.h |2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
Support the Atmel AHB DMA controller.
config FSL_DMA
- tristate "Freescale Elo and Elo Plus DMA support"
+ tristate "Freescale Elo series DMA support"
depends on FSL_SOC
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
---help---
- Enable support for the Freescale Elo and Elo Plus DMA controllers.
- The Elo is the DMA controller on some 82xx and 83xx parts, and the
- Elo Plus is the DMA controller on 85xx and 86xx parts.
+ Enable support for the Freescale Elo series DMA controllers.
+ The Elo is the DMA controller on some mpc82xx and mpc83xx parts, the
+ EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is on
+ some Txxx and Bxxx parts.
config MPC512X_DMA
tristate "Freescale MPC512x built-in DMA engine support"
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
WARN_ON(fdev->feature != chan->feature);
chan->dev = fdev->dev;
- chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+ chan->id = (res.start & 0xfff) < 0x300 ?
+ ((res.start - 0x100) & 0xfff) >> 7 :
+ ((res.start - 0x200) & 0xfff) >> 7;
if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev->dev, "too many channels for device\n");
err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct platform_device *op)
}
static const struct of_device_id fsldma_of_ids[] = {
+ { .compatible = "fsl,elo3-dma", },
{ .compatible = "fsl,eloplus-dma", },
{ .compatible = "fsl,elo-dma", },
{}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
static __init int fsldma_init(void)
{
- pr_info("Freescale Elo / Elo Plus DMA driver\n");
+ pr_info("Freescale Elo series DMA driver\n");
return platform_driver_register(&fsldma_of_driver);
}
@@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)
subsys_initcall(fsldma_init);
module_exit(fsldma_exit);
-MODULE_DESCRIPTION("Freescale Elo / Elo Plus DMA driver");
+MODULE_DESCRIPTION("Freescale Elo series DMA driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
};
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
void __iomem *regs; /* DGSR register base */
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7 1/3] DMA: Freescale: revise device tree binding document
From: Hongbo Zhang This patch updates the discription of each type of DMA controller and its channels, it is preparation for adding another new DMA controller binding, it also fixes some defects of indent for text alignment at the same time. Signed-off-by: Hongbo Zhang --- .../devicetree/bindings/powerpc/fsl/dma.txt| 48 1 file changed, 20 insertions(+), 28 deletions(-) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt index 2a4b4bc..6e9384b 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt @@ -1,33 +1,29 @@ -* Freescale 83xx DMA Controller +* Freescale DMA Controllers -Freescale PowerPC 83xx have on chip general purpose DMA controllers. +** Freescale Elo DMA Controller + This is a little-endian DMA controller, used in Freescale mpc83xx series + chips such as mpc8315, mpc8349, mpc8379 etc. Required properties: -- compatible: compatible list, contains 2 entries, first is -"fsl,CHIP-dma", where CHIP is the processor -(mpc8349, mpc8360, etc.) and the second is -"fsl,elo-dma" +- compatible: must include "fsl,elo-dma" - reg : -- ranges : Should be defined as specified in 1) to describe the - DMA controller channels. +- ranges: describes the mapping between the address space of the + DMA channels and the address space of the DMA controller - cell-index: controller index. 0 for controller @ 0x8100 - interrupts: - interrupt-parent : optional, if needed for interrupt mapping - - DMA channel nodes: -- compatible: compatible list, contains 2 entries, first is -"fsl,CHIP-dma-channel", where CHIP is the processor -(mpc8349, mpc8350, etc.) and the second is -"fsl,elo-dma-channel". However, see note below. +- compatible: must include "fsl,elo-dma-channel" + However, see note below. - reg : - cell-index: dma channel index starts at 0. Optional properties: - interrupts: - (on 83xx this is expected to be identical to - the interrupts property of the parent node) + (on 83xx this is expected to be identical to + the interrupts property of the parent node) - interrupt-parent : optional, if needed for interrupt mapping Example: @@ -70,27 +66,23 @@ Example: }; }; -* Freescale 85xx/86xx DMA Controller - -Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers. +** Freescale EloPlus DMA Controller + This is DMA controller with extended addresses and chaining, mainly used in + Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as mpc8540, mpc8641 + p4080, bsc9131 etc. Required properties: -- compatible: compatible list, contains 2 entries, first is -"fsl,CHIP-dma", where CHIP is the processor -(mpc8540, mpc8540, etc.) and the second is -"fsl,eloplus-dma" +- compatible: must include "fsl,eloplus-dma" - reg : - cell-index: controller index. 0 for controller @ 0x21000, 1 for controller @ 0xc000 -- ranges : Should be defined as specified in 1) to describe the - DMA controller channels. +- ranges: describes the mapping between the address space of the + DMA channels and the address space of the DMA controller - DMA channel nodes: -- compatible: compatible list, contains 2 entries, first is -"fsl,CHIP-dma-channel", where CHIP is the processor -(mpc8540, mpc8560, etc.) and the second is -"fsl,eloplus-dma-channel". However, see note below. +- compatible: must include "fsl,eloplus-dma-channel" + However, see note below. - cell-index: dma channel index starts at 0. - reg : - interrupts: -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 66
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 232 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 6e9384b..2e66c3d 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg :
+- ranges: describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg :
+- interrupts:
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4 0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <79 2 0 0>;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = <0xe2000 0x1000>;
};
-/include/ "qoriq-dma-0.dtsi"
+/include/ "elo3-dma-0.dtsi"
dma@100300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */
};
-/include/ "qoriq-dma-1.dtsi"
+/include/ "elo3-dma-1.dtsi"
dma@101300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
new file mode 100644
index 000..69a3277
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
@@ -0,0 +1,81 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x10 ]
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or
[PATCH v7 0/3] DMA: Freescale: Add support for 8-channel DMA engine
From: Hongbo Zhang Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches. Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set adds support this DMA engine. V6->V7 changes: - only remove unnecessary "CHIP-dma" explanations in [1/3] V5->V6 changes: - minor updates of descriptions in binding document and Kconfig - remove [4/4], that should be another patch in future V4->V5 changes: - update description in the dt binding document, to make it more resonable - add new patch [4/4] to eliminate a compiling warning which already exists for a long time V3->V4 changes: - introduce new patch [1/3] to revise the legacy dma binding document - and then add new paragraph to describe new dt node binding in [2/3] - rebase to latest kernel v3.11-rc1 V2->V3 changes: - edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt - edit text string in Kconfig and the driver files, using "elo series" to mention all the current "elo*" V1->V2 changes: - removed the codes handling the register dgsr1, since it isn't used currently - renamed the DMA DT compatible to "fsl,elo3-dma" - renamed the new dts files to "elo3-dma-.dtsi" Hongbo Zhang (3): DMA: Freescale: revise device tree binding document DMA: Freescale: Add new 8-channel DMA engine device tree nodes DMA: Freescale: update driver to support 8-channel DMA engine .../devicetree/bindings/powerpc/fsl/dma.txt| 114 +++- arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- drivers/dma/Kconfig|9 +- drivers/dma/fsldma.c |9 +- drivers/dma/fsldma.h |2 +- 8 files changed, 264 insertions(+), 40 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
Hi, On 07/29/2013 10:58 AM, Vaidyanathan Srinivasan wrote: > * Preeti U Murthy [2013-07-27 13:20:37]: > >> Hi Ben, >> >> On 07/27/2013 12:00 PM, Benjamin Herrenschmidt wrote: >>> On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote: *The lapic of a broadcast CPU is active always*. Say CPUX, wants the broadcast CPU to wake it up at timeX. Since we cannot program the lapic of a remote CPU, CPUX will need to send an IPI to the broadcast CPU, asking it to program its lapic to fire at timeX so as to wake up CPUX. *With multiple CPUs the overhead of sending IPI, could result in performance bottlenecks and may not scale well.* Hence the workaround is that the broadcast CPU on each of its timer interrupt checks if any of the next timer event of a CPU in deep idle state has expired, which can very well be found from dev->next_event of that CPU. For example the timeX that has been mentioned above has expired. If so the broadcast handler is called to send an IPI to the idling CPU to wake it up. *If the broadcast CPU, is in tickless idle, its timer interrupt could be many ticks away. It could miss waking up a CPU in deep idle*, if its wakeup is much before this timer interrupt of the broadcast CPU. But without tickless idle, atleast at each period we are assured of a timer interrupt. At which time broadcast handling is done as stated in the previous paragraph and we will not miss wakeup of CPUs in deep idle states. >>> >>> But that means a great loss of power saving on the broadcast CPU when the >>> machine >>> is basically completely idle. We might be able to come up with some thing >>> better. >>> >>> (Note : I do no know the timer offload code if it exists already, I'm >>> describing >>> how things could happen "out of the blue" without any knowledge of >>> pre-existing >>> framework here) >>> >>> We can know when the broadcast CPU expects to wake up next. When a CPU goes >>> to >>> a deep sleep state, it can then >>> >>> - Indicate to the broadcast CPU when it intends to be woken up by queuing >>> itself into an ordered queue (ordered by target wakeup time). (OPTIMISATION: >>> Play with the locality of that: have one queue (and one "broadcast CPU") per >>> chip or per node instead of a global one to limit cache bouncing). >>> >>> - Check if that happens before the broadcast CPU intended wake time (we >>> need statistics to see how often that happens), and in that case send an IPI >>> to wake it up now. When the broadcast CPU goes to sleep, it limits its sleep >>> time to the min of it's intended sleep time and the new sleeper time. >>> (OPTIMISATION: Dynamically chose a broadcast CPU based on closest expiry ?) >>> >>> - We can probably limit spurrious wakeups a *LOT* by aligning that target >>> time >>> to a global jiffy boundary, meaning that several CPUs going to idle are >>> likely >>> to be choosing the same. Or maybe better, an adaptative alignment by >>> essentially >>> getting more coarse grained as we go further in the future >>> >>> - When the "broadcast" CPU goes to sleep, it can play the same game of >>> alignment. >>> >>> I don't like the concept of a dedicated broadcast CPU however. I'd rather >>> have a >>> general queue (or per node) of sleepers needing a wakeup and more/less >>> dynamically >>> pick a waker to be the last man standing, but it does make things a bit more >>> tricky with tickless scheduler (non-idle). >>> >>> Still, I wonder if we could just have some algorithm to actually pick wakers >>> more dynamically based on who ever has the closest "next wakeup" planned, >>> that sort of thing. A fixed broadcaster will create an imbalance in >>> power/thermal within the chip in addition to needing to be moved around on >>> hotplug etc... >> >> Thank you for having listed out the above suggestions. Below, I will >> bring out some ideas about how the concerns that you have raised can be >> addressed in the increasing order of priority. >> >> - To begin with, I think we can have the following model to have the >> responsibility of the broadcast CPU float around certain CPUs. i.e. Not >> have a dedicated broadcast CPU. I will refer to the broadcast CPU as the >> bc_cpu henceforth for convenience. >> >> 1. The first CPU that intends to enter deep sleep state will be the bc_cpu. >> >> 2. Every other CPU that intends to enter deep idle state will enter >> themselves into a mask, say the bc_mask, which is already being done >> today, after they check that a bc_cpu has been assigned. >> >> 3. The bc_cpu should not enter tickless idle, until step 5a holds true. >> >> 4. So on every timer interrupt, which is at-least every period, it >> checks the bc_mask to see if any CPUs need to be woken up. >> >> 5. The bc cpu should not enter tickless idle *until* it is de-nominated >> as the bc_cpu. The de-nomination occurs when: >> a. In one of its timer interrupts, it does broadcast handlin
RE: [PATCH v2] powerpc: Update compilation flags with core specific options
> > The assembler option is redundant if the -mcpu= flag is set.
> > The patch fixes the kernel compilation problem for e5500/e6500
> > when using gcc option -mcpu=e5500/e6500.
> >
> > Signed-off-by: Catalin Udma
> > ---
> > changes for v2:
> >- update also KBUILD_AFLAGS with -mcpu and -msoft-float flags
> >
> > arch/powerpc/Makefile | 16 +++-
> > 1 files changed, 15 insertions(+), 1 deletions(-)
>
> Is the assembler redundant for older toolchains?
>
> - k
[CU] gcc defines the mapping from -mcpu to assembler options in file
gcc/config/rs6000/rs6000.h, like this:
%{mcpu=8540: -me500} \
%{mcpu=8548: -me500} \
%{mcpu=e300c2: -me300} \
%{mcpu=e300c3: -me300} \
%{mcpu=e500mc: -me500mc} \
%{mcpu=e500mc64: -me500mc64} \
%{mcpu=e5500: -me5500} \
%{mcpu=e6500: -me6500} \
I have checked this mapping from gcc 3.3 (where 8540 entry was added) to
3.4, 4.3, 4.4 and 4.8.1...The -Wa option is redundant for all these
older toolchains.
Catalin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
