* [PATCH] Fix interrupt handling in MPC8xxx GPIO driver
From: Felix Radensky @ 2011-10-11 8:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Felix Radensky, stable
Interrupt handler in MPC8xxx GPIO driver is missing the call
to PIC EOI (end of interrupt) handler. As a result, at least
on 85XX systems, GPIO interrupt is delivered only once. This
patch adds the missing EOI call. Tested on custom P1022 board.
Signed-off-by: Felix Radensky <felix@embedded-sol.com>
---
arch/powerpc/sysdev/mpc8xxx_gpio.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index fb4963a..d2e0e1c 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -153,6 +153,7 @@ static void mpc8xxx_gpio_irq_cascade(unsigned int irq, struct irq_desc *desc)
if (mask)
generic_handle_irq(irq_linear_revmap(mpc8xxx_gc->irq,
32 - ffs(mask)));
+ desc->chip->eoi(irq);
}
static void mpc8xxx_irq_unmask(struct irq_data *d)
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] Fix interrupt handling in MPC8xxx GPIO driver
From: Greg KH @ 2011-10-11 12:00 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, stable
In-Reply-To: <1318321461-3066-1-git-send-email-felix@embedded-sol.com>
On Tue, Oct 11, 2011 at 10:24:21AM +0200, Felix Radensky wrote:
> Interrupt handler in MPC8xxx GPIO driver is missing the call
> to PIC EOI (end of interrupt) handler. As a result, at least
> on 85XX systems, GPIO interrupt is delivered only once. This
> patch adds the missing EOI call. Tested on custom P1022 board.
>
> Signed-off-by: Felix Radensky <felix@embedded-sol.com>
> ---
> arch/powerpc/sysdev/mpc8xxx_gpio.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* Re: [PATCH 2/3] [44x] Enable CONFIG_RELOCATABLE for PPC44x
From: Suzuki Poulose @ 2011-10-11 12:54 UTC (permalink / raw)
To: Scott Wood
Cc: Michal Simek, tmarri, Mahesh Jagannath Salgaonkar, Dave Hansen,
David Laight, Paul Mackerras, linux ppc dev, Vivek Goyal
In-Reply-To: <4E9332AA.1050307@freescale.com>
On 10/10/11 23:30, Scott Wood wrote:
> On 10/10/2011 04:56 AM, Suzuki K. Poulose wrote:
>> #if defined(CONFIG_RELOCATABLE)&& defined(CONFIG_44x)
>> #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) - PHYSICAL_START + (KERNELBASE + RELOC_OFFSET)))
>> #define __pa(x) ((unsigned long)(x) + PHYSICAL_START - (KERNELBASE + RELOC_OFFSET))
>> #endif
>
> Why is this 44x-specific?
As of now, we compile with relocations only for the 44x. We could make this
generic once the approach is accepted by everyone and implemented on the other
platforms.
Thanks
Suzuki
^ permalink raw reply
* Re: [PATCH v2] powerpc: book3e: WSP: Add Chroma as a new WSP/PowerEN platform.
From: Jimi Xenidis @ 2011-10-11 14:47 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
On Tue Oct 4 05:02:41 EST 2011, Scott Wood wrote:
Looking at your comments below, will the following be acceptable
> On 09/29/2011 09:27 PM, Jimi Xenidis wrote:
> > diff --git a/arch/powerpc/platforms/wsp/Kconfig =
b/arch/powerpc/platforms/wsp/Kconfig
> > index ea2811c..a3eef8e 100644
> > --- a/arch/powerpc/platforms/wsp/Kconfig
> > +++ b/arch/powerpc/platforms/wsp/Kconfig
> > @@ -1,6 +1,7 @@
> > config PPC_WSP
> > bool
> > select PPC_A2
> > + select GENERIC_TBSYNC
> > select PPC_ICSWX
> > select PPC_SCOM
> > select PPC_XICS
> > @@ -8,14 +9,20 @@ config PPC_WSP
> > select PCI
> > select PPC_IO_WORKAROUNDS if PCI
> > select PPC_INDIRECT_PIO if PCI
> > + select PPC_WSP_COPRO
> > default n
> > =20
> > menu "WSP platform selection"
> > depends on PPC_BOOK3E_64
add "&& SMP"
> > =20
> > config PPC_PSR2
> > - bool "PSR-2 platform"
> > - select GENERIC_TBSYNC
> > + bool "PowerEN System Reference Platform 2"
> > + select EPAPR_BOOT
> > + select PPC_WSP
> > + default y
Make these "default n"
Will that address everything?
-jx
> > +
> > +config PPC_CHROMA
> > + bool "PowerEN PCIe Chroma Card"
> > select EPAPR_BOOT
> > select PPC_WSP
> > default y
>=20
> This is an existing problem with PSR2, but please don't hide "default =
y"
> in a menu (at least make it a menuconfig).
> As is, it's not obvious from
> looking at the toplevel platforms menu that these platforms are =
enabled
> at all.
>=20
> Further, PPC_WSP doesn't build on non-SMP (undefined references to
> boot_cpuid and get_hard_smp_processor_id in ics.c), but the platforms
> that select it don't depend on SMP.
this I can solve with=20
>=20
> -Scott
>=20
^ permalink raw reply
* RE: [PATCH v14 10/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
From: Tirumala Marri @ 2011-10-11 22:43 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Mark Miesfeld, greg, linux-usb, linuxppc-dev, Fushen Chen
In-Reply-To: <4E8EDD75.5090107@ru.mvista.com>
<> +# dwc_otg builds in ../dwc along with host support
<> +config USB_GADGET_DWC_HDRC
<> + boolean "DesignWare USB Peripheral"
<> + depends on DWC_OTG_MODE || DWC_DEVICE_ONLY
<> + select USB_GADGET_DUALSPEED
<> + select USB_GADGET_SELECTED
<> + select USB_GADGET_DWC_OTG
<
< I don't see where this one is defined...
<
[Tirumala Marri] You mean USB_GADGET_SELECTED ? Ok I will add it.
--marri
^ permalink raw reply
* RE: [PATCH v14 02/10] USB/ppc4xx: Add Synopsys DesignWare HS USB OTG driver framework
From: Tirumala Marri @ 2011-10-11 22:46 UTC (permalink / raw)
To: Kassey Lee; +Cc: Mark Miesfeld, greg, linux-usb, linuxppc-dev, Fushen Chen
In-Reply-To: <CAKwPUowTCS2jO1QdFMCFg86Mb_d_yo2NvnWQ=Lh6N1tdgZE1rA@mail.gmail.com>
Hi,
<
< I did find any private info for ppc in
< drivers/usb/dwc/apmppc.c
<
< do you want make it generic driver ? if yes, it could be a
<generic name too.
[Tirumala Marri] This file has of PPC specific functions, like device tree
which actually contains PPC specific address ranges, interrupt numbers
etc.
--marri
^ permalink raw reply
* [PATCH] powerpc/85xx: Fix doorbells
From: Matthew McClintock @ 2011-10-12 0:06 UTC (permalink / raw)
To: kumar.gala, linuxppc-dev
Commit 765342526246c97600e5344c0949824d94bb51c3 made some small
changes to IPI, message_pass in smp_ops was initialized to NULL
for other platforms but not for 85xx which causes us to always
use the mpic for IPI's. This patch makes doorbells work again.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/platforms/85xx/smp.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index 5b9b901..d6e4746 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -243,6 +243,7 @@ void __init mpc85xx_smp_init(void)
* If left NULL, .message_pass defaults to
* smp_muxed_ipi_message_pass
*/
+ smp_85xx_ops.message_pass = NULL;
smp_85xx_ops.cause_ipi = doorbell_cause_ipi;
}
--
1.7.6.1
^ permalink raw reply related
* Re: [PATCH 1/2] [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
From: David Gibson @ 2011-10-12 3:33 UTC (permalink / raw)
To: K.Prasad; +Cc: linuxppc-dev, Thiago Jung Bauermann, Edjunior Barbosa Machado
In-Reply-To: <20110916072710.GA28060@in.ibm.com>
On Fri, Sep 16, 2011 at 12:57:10PM +0530, K.Prasad wrote:
> On Fri, Aug 26, 2011 at 03:05:52PM +0530, K.Prasad wrote:
> > On Wed, Aug 24, 2011 at 01:59:39PM +1000, David Gibson wrote:
> > > On Tue, Aug 23, 2011 at 02:55:13PM +0530, K.Prasad wrote:
> > > > On Tue, Aug 23, 2011 at 03:08:50PM +1000, David Gibson wrote:
> > > > > On Fri, Aug 19, 2011 at 01:21:36PM +0530, K.Prasad wrote:
> > > > > > PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
> > > > > > PowerPC specific ptrace flags that use the watchpoint register. While they are
> > > > > > targeted primarily towards BookE users, user-space applications such as GDB
> > > > > > have started using them for BookS too.
> > > > > >
> > > > > > This patch enables the use of generic hardware breakpoint interfaces for these
> > > > > > new flags. The version number of the associated data structures
> > > > > > "ppc_hw_breakpoint" and "ppc_debug_info" is incremented to denote new semantics.
> > > > >
> > > > > So, the structure itself doesn't seem to have been extended. I don't
> > > > > understand what the semantic difference is - your patch comment needs
> > > > > to explain this clearly.
> > > > >
> > > >
> > > > We had a request to extend the structure but thought it was dangerous to
> > > > do so. For instance if the user-space used version1 of the structure,
> > > > while kernel did a copy_to_user() pertaining to version2, then we'd run
> > > > into problems. Unfortunately the ptrace flags weren't designed to accept
> > > > a version number as input from the user through the
> > > > PPC_PTRACE_GETHWDBGINFO flag (which would have solved this issue).
> > >
> > > I still don't follow you.
> > >
> >
> > Two things here.
> >
> > One, the change of semantics warranted an increment of the version
> > number. The new semantics accepts PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE on
> > BookS, while the old version number did not. I've added a small comment
> > in the code to this effect.
> >
> > Two, regarding changes in the "ppc_hw_breakpoint" and "ppc_debug_info"
> > structures - we would like to add more members to it if we can (GDB has a
> > pending request to add more members to it). However the problem foreseen
> > is that there could be a mismatch between the versions of the structure
> > used by the user vs kernel-space i.e. if a new version of the structure,
> > known to the kernel, had an extra member while the user-space still had
> > the old version, then it becomes dangerous because the __copy_to_user
> > function would overflow the buffer size in user-space.
> >
> > This could have been avoided if PPC_PTRACE_GETHWDBGINFO was originally
> > designed to accept a version number (and provide corresponding
> > "struct ppc_debug_info") rather than send a populated "ppc_debug_info"
> > structure along with the version number.
> >
>
> Based on further discussions with the code-reviewer (David Gibson
> <dwg@au1.ibm.com>), it was decided that incrementing the version number
> for the proposed changes is unnecessary as the patch only introduces new
> features but not a change in semantics.
>
> Please find a new version of the patch where the version number is
> retained as 1, along with the other planned changes.
>
> Thanks,
> K.Prasad
>
>
> [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
>
> PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
> PowerPC specific ptrace flags that use the watchpoint register. While they are
> targeted primarily towards BookE users, user-space applications such as GDB
> have started using them for BookS too.
>
> This patch enables the use of generic hardware breakpoint interfaces for these
> new flags. The version number of the associated data structures
> "ppc_hw_breakpoint" and "ppc_debug_info" is incremented to denote new semantics.
Above pargraph needs revision.
> Apart from the usual benefits of using generic hw-breakpoint interfaces, these
> changes allow debuggers (such as GDB) to use a common set of ptrace flags for
> their watchpoint needs and allow more precise breakpoint specification (length
> of the variable can be specified).
>
> [Edjunior: Identified an issue in the patch with the sanity check for version
> numbers]
>
> Tested-by: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
> Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
>
> diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
> index f4a5499..04656ec 100644
> --- a/Documentation/powerpc/ptrace.txt
> +++ b/Documentation/powerpc/ptrace.txt
> @@ -127,6 +127,22 @@ Some examples of using the structure to:
> p.addr2 = (uint64_t) end_range;
> p.condition_value = 0;
>
> +- set a watchpoint in server processors (BookS)
> +
> + p.version = 1;
> + p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
> + p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
> + or
> + p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_EXACT;
MODE_RANGE_EXACT? Shouldn't that just be MODE_EXACT?
> +
> + p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
> + p.addr = (uint64_t) begin_range;
> + /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
> + * addr2 - addr <= 8 Bytes.
> + */
> + p.addr2 = (uint64_t) end_range;
> + p.condition_value = 0;
> +
> 3. PTRACE_DELHWDEBUG
>
> Takes an integer which identifies an existing breakpoint or watchpoint
> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> index 05b7dd2..2449495 100644
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -1339,6 +1339,12 @@ static int set_dac_range(struct task_struct *child,
> static long ppc_set_hwdebug(struct task_struct *child,
> struct ppc_hw_breakpoint *bp_info)
> {
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> + int ret, len = 0;
> + struct thread_struct *thread = &(child->thread);
> + struct perf_event *bp;
> + struct perf_event_attr attr;
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> #ifndef CONFIG_PPC_ADV_DEBUG_REGS
> unsigned long dabr;
> #endif
> @@ -1382,13 +1388,9 @@ static long ppc_set_hwdebug(struct task_struct *child,
> */
> if ((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0 ||
> (bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0 ||
> - bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT ||
> bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE)
> return -EINVAL;
>
> - if (child->thread.dabr)
> - return -ENOSPC;
> -
> if ((unsigned long)bp_info->addr >= TASK_SIZE)
> return -EIO;
>
> @@ -1398,15 +1400,83 @@ static long ppc_set_hwdebug(struct task_struct *child,
> dabr |= DABR_DATA_READ;
> if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
> dabr |= DABR_DATA_WRITE;
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> + if (ptrace_get_breakpoints(child) < 0)
> + return -ESRCH;
>
> - child->thread.dabr = dabr;
> + bp = thread->ptrace_bps[0];
> + if (!bp_info->addr) {
I think this is treating a hardware breakpoint at address 0 as if it
didn't exist. That seems wrong.
> + if (bp) {
> + unregister_hw_breakpoint(bp);
> + thread->ptrace_bps[0] = NULL;
> + }
> + ptrace_put_breakpoints(child);
> + return 0;
> + }
> + /*
> + * Check if the request is for 'range' breakpoints. We can
> + * support it if range < 8 bytes.
> + */
> + if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE)
> + len = bp_info->addr2 - bp_info->addr;
> + else if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) {
> + ptrace_put_breakpoints(child);
> + return -EINVAL;
> + }
Misindent here. This statement would be clearer if you had {} on all
of the if branches.
> + if (bp) {
> + attr = bp->attr;
> + attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> + arch_bp_generic_fields(dabr &
> + (DABR_DATA_WRITE | DABR_DATA_READ),
> + &attr.bp_type);
> + attr.bp_len = len;
If gdb is using the new breakpoint interface, surely it should just
use it, rather than doing this bit frobbing as in the old SET_DABR
call.
> + ret = modify_user_hw_breakpoint(bp, &attr);
> + if (ret) {
> + ptrace_put_breakpoints(child);
> + return ret;
> + }
> + thread->ptrace_bps[0] = bp;
> + ptrace_put_breakpoints(child);
> + thread->dabr = dabr;
> + return 0;
> + }
>
> + /* Create a new breakpoint request if one doesn't exist already */
> + hw_breakpoint_init(&attr);
> + attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> + attr.bp_len = len;
> + arch_bp_generic_fields(dabr & (DABR_DATA_WRITE | DABR_DATA_READ),
> + &attr.bp_type);
> +
> + thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
> + ptrace_triggered, NULL, child);
> + if (IS_ERR(bp)) {
> + thread->ptrace_bps[0] = NULL;
> + ptrace_put_breakpoints(child);
> + return PTR_ERR(bp);
> + }
> +
> + ptrace_put_breakpoints(child);
> + return 1;
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> +
> + if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT)
> + return -EINVAL;
> +
> + if (child->thread.dabr)
> + return -ENOSPC;
> +
> + child->thread.dabr = dabr;
> return 1;
> #endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */
> }
>
> static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
> {
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> + struct thread_struct *thread = &(child->thread);
> + struct perf_event *bp;
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> int rc;
>
> @@ -1426,10 +1496,24 @@ static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
> #else
> if (data != 1)
> return -EINVAL;
> +
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> + if (ptrace_get_breakpoints(child) < 0)
> + return -ESRCH;
> +
> + bp = thread->ptrace_bps[0];
> + if (bp) {
> + unregister_hw_breakpoint(bp);
> + thread->ptrace_bps[0] = NULL;
> + }
> + ptrace_put_breakpoints(child);
> + return 0;
> +#else /* CONFIG_HAVE_HW_BREAKPOINT */
> if (child->thread.dabr == 0)
> return -ENOENT;
>
> child->thread.dabr = 0;
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
>
> return 0;
> #endif
> @@ -1560,7 +1644,7 @@ long arch_ptrace(struct task_struct *child, long request,
> dbginfo.data_bp_alignment = 4;
> #endif
> dbginfo.sizeof_condition = 0;
> - dbginfo.features = 0;
> + dbginfo.features = PPC_DEBUG_FEATURE_DATA_BP_RANGE;
> #endif /* CONFIG_PPC_ADV_DEBUG_REGS */
>
> if (!access_ok(VERIFY_WRITE, datavp,
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powerpc/82xx: updates for mgcoge
From: Kumar Gala @ 2011-10-12 4:16 UTC (permalink / raw)
To: Holger Brunck; +Cc: linuxppc-dev
In-Reply-To: <1317109490-4449-1-git-send-email-holger.brunck@keymile.com>
On Sep 27, 2011, at 2:44 AM, Holger Brunck wrote:
> Add:
> - Setup dts node for USB
> - pin description and setup for SMC1 (serial interface)
>
> Update and cleanup mgcoge_defconfig:
> - enable: TIPC, UBIFS, USB_GADGET driver, SQUASHFS, HIGHRES timers
> POSIX_MQUEUE, EMBEDDED
> - disable: EXT3, PPC_PMAC
>
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
> Acked-by: Heiko Schocher <hs@denx.de>
> cc: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/mgcoge.dts | 9 +++++++++
> arch/powerpc/configs/mgcoge_defconfig | 27 ++++++++++++++++-----------
> arch/powerpc/platforms/82xx/km82xx.c | 4 ++++
> 3 files changed, 29 insertions(+), 11 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH 0/3] math_emu: fixup for efp
From: Kumar Gala @ 2011-10-12 4:17 UTC (permalink / raw)
To: Liu Yu; +Cc: linuxppc-dev
In-Reply-To: <1315213283-3800-1-git-send-email-yu.liu@freescale.com>
On Sep 5, 2011, at 4:01 AM, Liu Yu wrote:
> These patches fix some issues in efp.
applied
- k
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-booke: Handle L1 D-cache parity error correctly on e500mc
From: Kumar Gala @ 2011-10-12 4:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1314443917-18515-1-git-send-email-galak@kernel.crashing.org>
On Aug 27, 2011, at 6:18 AM, Kumar Gala wrote:
> If the L1 D-Cache is in write shadow mode the HW will auto-recover the
> error. However we might still log the error and cause a machine check
> (if L1CSR0[CPE] - Cache error checking enable). We should only treat
> the non-write shadow case as non-recoverable.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/include/asm/reg_booke.h | 3 +++
> arch/powerpc/kernel/traps.c | 9 ++++++++-
> 2 files changed, 11 insertions(+), 1 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH] powerpc/fsl_msi: fix support for multiple MSI ranges
From: Kumar Gala @ 2011-10-12 4:19 UTC (permalink / raw)
To: Timur Tabi; +Cc: scottwood, linuxppc-dev
In-Reply-To: <1315948620-12402-1-git-send-email-timur@freescale.com>
On Sep 13, 2011, at 4:17 PM, Timur Tabi wrote:
> Commit 6820fead ("powerpc/fsl_msi: Handle msi-available-ranges =
better") added
> support for multiple ranges in the msi-available-ranges property, but =
it
> miscalculated the MSIR index when multiple ranges are used.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_msi.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
applied
- k=
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/85xx: Rename p2040_rdb.c to p2041_rdb.c
From: Kumar Gala @ 2011-10-12 4:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Mingkai Hu
In-Reply-To: <1314905178-4394-1-git-send-email-galak@kernel.crashing.org>
On Sep 1, 2011, at 2:26 PM, Kumar Gala wrote:
> From: Mingkai Hu <Mingkai.hu@freescale.com>
>=20
> There's only p2041rdb board for official release, but the p2041 =
silicon
> on the board can be converted to p2040 silicon without XAUI and L2 =
cache
> function, then the board becomes p2040rdb board. so we use the file =
name
> p2041_rdb.c to handle P2040RDB board and P2041RDB board which is also
> consistent with the board name under U-Boot.
>=20
> During the rename we make few other minor changes to the device tree:
> * Move USB phy setting into p2041si.dtsi as its SoC not board defined
> * Convert PCI clock-frequency to decimal to be more readable
>=20
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/p2040rdb.dts | 166 -------
> arch/powerpc/boot/dts/p2040si.dtsi | 623 =
--------------------------
> arch/powerpc/boot/dts/p2041rdb.dts | 161 +++++++
> arch/powerpc/boot/dts/p2041si.dtsi | 623 =
++++++++++++++++++++++++++
> arch/powerpc/configs/corenet32_smp_defconfig | 2 +-
> arch/powerpc/platforms/85xx/Kconfig | 6 +-
> arch/powerpc/platforms/85xx/Makefile | 2 +-
> arch/powerpc/platforms/85xx/p2040_rdb.c | 88 ----
> arch/powerpc/platforms/85xx/p2041_rdb.c | 88 ++++
> 9 files changed, 877 insertions(+), 882 deletions(-)
> delete mode 100644 arch/powerpc/boot/dts/p2040rdb.dts
> delete mode 100644 arch/powerpc/boot/dts/p2040si.dtsi
> create mode 100644 arch/powerpc/boot/dts/p2041rdb.dts
> create mode 100644 arch/powerpc/boot/dts/p2041si.dtsi
> delete mode 100644 arch/powerpc/platforms/85xx/p2040_rdb.c
> create mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c
applied
- k
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/85xx: Rename PowerPC core nodes to match other e500mc based .dts
From: Kumar Gala @ 2011-10-12 4:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1314905175-4371-1-git-send-email-galak@kernel.crashing.org>
On Sep 1, 2011, at 2:26 PM, Kumar Gala wrote:
> The P4080 silicon device tree was using PowerPC,4080 while the other
> e500mc based SoCs used PowerPC,e500mc. Use the core name to be
> consistent going forward.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/p4080si.dtsi | 16 ++++++++--------
> 1 files changed, 8 insertions(+), 8 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH] powerpc: e500mc: Fix: use CONFIG_PPC_E500MC in idle_e500.S
From: Kumar Gala @ 2011-10-12 4:24 UTC (permalink / raw)
To: Bharat Bhushan; +Cc: Bharat Bhushan, linuxppc-dev, bharatb.yadav
In-Reply-To: <1318312568-23181-1-git-send-email-bharat.bhushan@freescale.com>
On Oct 11, 2011, at 12:56 AM, Bharat Bhushan wrote:
> It is wrongly using undefined CONFIG_E500MC.
>
> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> ---
> arch/powerpc/kernel/idle_e500.S | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied, can you send this linux-stable for v3.0.x inclusion
- k
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Fix doorbells
From: Kumar Gala @ 2011-10-12 4:26 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1318378002-32531-1-git-send-email-msm@freescale.com>
On Oct 11, 2011, at 7:06 PM, Matthew McClintock wrote:
> Commit 765342526246c97600e5344c0949824d94bb51c3 made some small
> changes to IPI, message_pass in smp_ops was initialized to NULL
> for other platforms but not for 85xx which causes us to always
> use the mpic for IPI's. This patch makes doorbells work again.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
applied (updated commit message a bit).
- k
^ permalink raw reply
* Re: [PATCH 12/13] powerpc: Update corenet64_smp_defconfig
From: Kumar Gala @ 2011-10-12 4:29 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, david
In-Reply-To: <13182798902823-git-send-email-beckyb@kernel.crashing.org>
On Oct 10, 2011, at 3:50 PM, Becky Bruce wrote:
> From: Becky Bruce <beckyb@kernel.crashing.org>
>
> Updates from make savedefconfig.
>
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
> ---
> arch/powerpc/configs/corenet64_smp_defconfig | 5 -----
> 1 files changed, 0 insertions(+), 5 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH 10/13] powerpc: Update mpc85xx/corenet 32-bit defconfigs
From: Kumar Gala @ 2011-10-12 4:29 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, david
In-Reply-To: <13182798883685-git-send-email-beckyb@kernel.crashing.org>
On Oct 10, 2011, at 3:50 PM, Becky Bruce wrote:
> From: Becky Bruce <beckyb@kernel.crashing.org>
>
> Results from updates via make savedefconfig.
>
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
> ---
> arch/powerpc/configs/corenet32_smp_defconfig | 8 --------
> arch/powerpc/configs/mpc85xx_defconfig | 5 +----
> arch/powerpc/configs/mpc85xx_smp_defconfig | 6 +-----
> 3 files changed, 2 insertions(+), 17 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: respect mem= setting for early memory limit setup
From: Kumar Gala @ 2011-10-12 4:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1316187599-27549-1-git-send-email-galak@kernel.crashing.org>
On Sep 16, 2011, at 10:39 AM, Kumar Gala wrote:
> For those MMUs that have some form of bolt'd linear mapping (TLB)
> required its rare that one ever sets mem= smaller than the size of that
> mapping.
>
> However, on Book-E 64 parts the initial linear mapping is quite large
> (1G) so its quite reasonable that mem= is set smaller than that.
>
> We need to parse the command line for mem= limit and constrain the
> amount of memory we map initially by it if need be.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/kernel/prom.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/fsl-booke: Fix setup_initial_memory_limit to not blindly map
From: Kumar Gala @ 2011-10-12 4:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1316187599-27549-2-git-send-email-galak@kernel.crashing.org>
On Sep 16, 2011, at 10:39 AM, Kumar Gala wrote:
> On FSL Book-E devices we support multiple large TLB sizes and so we can
> get into situations in which the initial 1G TLB size is too big and
> we're asked for a size that is not mappable by a single entry (like
> 512M). The single entry is important because when we bring up secondary
> cores they need to ensure any data structure they need to access (eg
> PACA or stack) is always mapped.
>
> So we really need to determine what size will actually be mapped by the
> first TLB entry to ensure we limit early memory references to that
> region. We refactor the map_mem_in_cams() code to provider a helper
> function that we can utilize to determine the size of the first TLB
> entry while taking into account size and alignment constraints.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/mm/fsl_booke_mmu.c | 31 +++++++++++++++++++------------
> arch/powerpc/mm/mmu_decl.h | 2 ++
> arch/powerpc/mm/tlb_nohash.c | 21 ++++++++++++++++++---
> 3 files changed, 39 insertions(+), 15 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH] [v3] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
From: Kumar Gala @ 2011-10-12 4:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1316109853-6665-1-git-send-email-timur@freescale.com>
On Sep 15, 2011, at 1:04 PM, Timur Tabi wrote:
> Standarize and document the FPGA nodes used on Freescale QorIQ =
reference
> boards. There are different kinds of FPGAs used on the boards, but
> only two are currently standard: "pixis", "ngpixis", and "qixis". =
Although
> there are minor differences among the boards that have one kind of =
FPGA, most
> of the functionality is the same, so it makes sense to create common
> compatibility strings.
>=20
> We also need to update the P1022DS platform file, because the =
compatible
> string for its PIXIS node has changed. This means that older kernels =
are
> not compatible with newer device trees. This is not a real problem, =
however,
> since that particular function doesn't work anyway. When the DIU is =
active,
> the PIXIS is in "indirect mode", and so cannot be accessed as a =
memory-mapped
> device.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> v3: added "ngpixis" to list
>=20
> v2: removed references to the CPLD
>=20
> This patch only adds "ngpixis" nodes, because that's the easiest. The
> P3060QDS device tree already has a qixis node. Support for older =
boards
> with the old "pixis" will be added later.
applied
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: fix PHYS_64BIT selection for P1022DS
From: Kumar Gala @ 2011-10-12 4:53 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <1316806370-21067-1-git-send-email-agust@denx.de>
On Sep 23, 2011, at 2:32 PM, Anatolij Gustschin wrote:
> Remove wrong CONFIG_ prefix in Kconfig file.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH v3] powerpc/85xx: Adding DCSR node to dtsi device trees
From: Kumar Gala @ 2011-10-12 4:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Stephen George
In-Reply-To: <1316187394-858-1-git-send-email-galak@kernel.crashing.org>
On Sep 16, 2011, at 10:36 AM, Kumar Gala wrote:
> From: Stephen George <stephen.george@freescale.com>
>
> Adding new device tree binding file for the DCSR node. Modifying device
> tree dtsi files to add DCSR node for P2041, P3041, P3060, P4080, & P5020.
>
> Signed-off-by: Stephen George <stephen.george@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> v3:
> * fix IRQs #, (should be +16 because of external IRQs starting at 0)
>
> v2:
> * include dscr.txt binding spec
> * moved around dcsr nodes to keep sorted in addr order
applied, dropped p3060 for now (will pick up in the P3060QDS board patch).
- k
^ permalink raw reply
* Re: [PATCH v14 10/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
From: Sergei Shtylyov @ 2011-10-12 11:16 UTC (permalink / raw)
To: Tirumala Marri; +Cc: Mark Miesfeld, greg, linux-usb, linuxppc-dev, Fushen Chen
In-Reply-To: <85bdbe5686e64bd0be07b07e2bb9a0ac@mail.gmail.com>
Hello.
On 12-10-2011 2:43, Tirumala Marri wrote:
> <> +# dwc_otg builds in ../dwc along with host support
> <> +config USB_GADGET_DWC_HDRC
> <> + boolean "DesignWare USB Peripheral"
> <> + depends on DWC_OTG_MODE || DWC_DEVICE_ONLY
> <> + select USB_GADGET_DUALSPEED
> <> + select USB_GADGET_SELECTED
> <> + select USB_GADGET_DWC_OTG
> < I don't see where this one is defined...
> [Tirumala Marri] You mean USB_GADGET_SELECTED ? Ok I will add it.
No, I mean USB_GADGET_DWC_OTG. USB_GADGET_SELECTED is already defined.
> --marri
WBR, Sergei
^ permalink raw reply
* [PATCH] ll_temac: Add support for ethtool
From: Ricardo Ribalda Delgado @ 2011-10-12 11:47 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-netdev, dhlii, ville.sundell,
grant.likely
Cc: Ricardo Ribalda Delgado
This patch enables the ethtool interface. The implementation is done
using the libphy helper functions.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
drivers/net/ll_temac_main.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 728fe41..91a9804 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -957,6 +957,32 @@ static const struct attribute_group temac_attr_group = {
.attrs = temac_device_attrs,
};
+/* ethtool support */
+static int temac_get_settings(struct net_device *ndev, struct ethtool_cmd *cmd)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_ethtool_gset(lp->phy_dev, cmd);
+}
+
+static int temac_set_settings(struct net_device *ndev, struct ethtool_cmd *cmd)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_ethtool_sset(lp->phy_dev, cmd);
+}
+
+static int temac_nway_reset(struct net_device *ndev)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_start_aneg(lp->phy_dev);
+}
+
+static const struct ethtool_ops temac_ethtool_ops = {
+ .get_settings = temac_get_settings,
+ .set_settings = temac_set_settings,
+ .nway_reset = temac_nway_reset,
+ .get_link = ethtool_op_get_link,
+};
+
static int __devinit temac_of_probe(struct platform_device *op)
{
struct device_node *np;
@@ -978,6 +1004,7 @@ static int __devinit temac_of_probe(struct platform_device *op)
ndev->flags &= ~IFF_MULTICAST; /* clear multicast */
ndev->features = NETIF_F_SG | NETIF_F_FRAGLIST;
ndev->netdev_ops = &temac_netdev_ops;
+ ndev->ethtool_ops= &temac_ethtool_ops;
#if 0
ndev->features |= NETIF_F_IP_CSUM; /* Can checksum TCP/UDP over IPv4. */
ndev->features |= NETIF_F_HW_CSUM; /* Can checksum all the packets. */
--
1.7.6.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox