On Wed, Oct 26, 2011 at 11:57 PM, radha krishna wrote:
> Hi ,
>
> The subject is changed to "Kdump/kexec for mpc85xx", as i am going to use it
> on P2010 and MPC8567 processors as will. So that it will not confuse others
> and to continue as a separate topic. In fact, i have selected P2041 which i
On Sun, Oct 23, 2011 at 2:00 AM, Olof Johansson wrote:
>
> Hi,
>
> On Fri, Oct 21, 2011 at 10:33 AM, Olof Johansson wrote:
> > On Fri, Oct 14, 2011 at 03:08:34PM -0700, tma...@apm.com wrote:
> >> From: Tirumala Marri
> >
> > Overall this driver seems to be based on the IP vendor driver? It
> > l
On Wed, Oct 26, 2011 at 10:17:19AM -0700, Tirumala Marri wrote:
> Greg,
>
> <
>
Hi All,
Just for anyone interested, my ps3-linux kernel git repo is back
at kernel.org:
http://git.kernel.org/?p=linux/kernel/git/geoff/ps3-linux.git
I haven't merged in mainline for a while because there is a bug
in the scheduler IPI code I want to get fix before I merge.
-Geoff
___
Hi Marri,
On Wed, 2011-10-26 at 09:06 -0700, Tirumala Marri wrote:
> <
> <
>
The DDW feature relies on there being sufficient TCE space to allocate
for the requested DMA window size. The default window uses up some of
that space, though, and it is recommended to first remove the default
window and then allocate the larger window advertised by firmware. Do
this by abstractin
On Freescale parts with multiple MSI controllers, the controllers are
combined into one "pool" of interrupts. Whenever a device requests an MSI
interrupt, the next available interrupt from the pool is selected,
regardless of which MSI controller the interrupt is from. This works
because each PCI
On Freescale parts with multiple MSI controllers, the controllers are
combined into one "pool" of interrupts. Whenever a device requests an MSI
interrupt, the next available interrupt from the pool is selected,
regardless of which MSI controller the interrupt is from. This works
because each PCI
On 10/26/2011 02:12 PM, Suzuki Poulose wrote:
> On 10/25/11 21:04, Scott Wood wrote:
>> On 10/12/2011 09:15 AM, Dave Hansen wrote:
>>> This is not the place to enforce that kind of thing. If
>>> CONFIG_RELOCATABLE is only supported on one platform, then do:
>>>
>>> config RELOCATABLE
>>>
On 10/25/11 21:04, Scott Wood wrote:
On 10/12/2011 09:15 AM, Dave Hansen wrote:
On Tue, 2011-10-11 at 18:24 +0530, Suzuki Poulose wrote:
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
This is listed as a requirement for Freescale CoreNet based devices (e.g
p4080ds with MPIC v4.x) after issuing a core reset to properly clear pending
interrupts.
Signed-off-by: Matthew McClintock
---
v2: Updated commit message
v3: Added detail in code comment as well
v4: Check for MPIC_FSL in
This is listed as a requirement for Freescale CoreNet based devices (e.g
p4080ds with MPIC v4.x) after issuing a core reset to properly clear pending
interrupts.
Signed-off-by: Matthew McClintock
---
v2: Updated commit message
v3: Added detail in code comment as well
arch/powerpc/sysdev/mpic.
@@ -1759,6 +1760,12 @@ void mpic_reset_core(int cpu)
pir &= ~(1 << cpuid);
mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+
+ /* Perform 15 EOI on each reset core to clear pending interrupts */
+
This is listed as a requirement for Freescale CoreNet based devices (e.g
p4080ds with MPIC v4.x) after issuing a core reset to properly clear pending
interrupts.
Signed-off-by: Matthew McClintock
---
v2: Updated commit message
arch/powerpc/sysdev/mpic.c |7 +++
1 files changed, 7 inser
Greg,
<
<
Could you please comment on this. This has been reviewed so many times
And we did the major changes. I think it is un-acceptable to say to
re-write
The driver now after 15 reviews? This should have happened in first 5
reviews.
Thx,
Marri
__
<
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 10/25/2011 10:35 PM, Kumar Gala wrote:
>
> On Oct 25, 2011, at 5:19 PM, Scott Wood wrote:
>
>> On 10/22/2011 04:20 PM, Kumar Gala wrote:
>>> All eTSEC2 controllers support waking on magic packet so fixup device
>>> tree to report that.
>>
>> If they *all* support it, we can make the driver rel
On Tue, Oct 25, 2011 at 2:54 PM, Tirumala Marri wrote:
> <
><
> [Tirumala Marri] Some what true that it was based on skeletal driver
> Provided from IP vendor.
Please use a real mail program instead of this [name] comment style.
It's hard to read.
><
><
> [Tirumala Marri] I can sure
18 matches
Mail list logo
