On Dec 03, 2011, at 10:53, Kumar Gala wrote:
On Dec 2, 2011, at 10:27 AM, Kyle Moffett wrote:
Instead of using the open-coded reg property lookup and address
translation in mpic_alloc(), directly call of_address_to_resource().
This includes various workarounds for special cases which the naive
Ben,
I fixed the 3 issues that Paul and Michael reported and I can provide them
to you two different ways, however you would prefer. I can also send the
patches via email if that's more convenient.
Option 1: Squashed into the the original patches for bisectability:
On Nov 15, 2011, at 23:40, Paul Mackerras wrote:
On Tue, Nov 15, 2011 at 04:45:18PM -0600, Moffett, Kyle D wrote:
I guess that's doable, although I have to admit that idea almost gives
me more of a headache than trying to fix up the 32-bit ASM.
One thing that bothers me in particular
On Nov 15, 2011, at 17:29, Benjamin Herrenschmidt wrote:
On Mon, 2011-11-14 at 21:32 -0500, Kyle Moffett wrote:
Unfortunately, I've been staring at PPC asm for long enough that I
have a migraine headache and I'm going to have to stop here for now.
If somebody else wants to tackle fixing up the
On Nov 15, 2011, at 18:46, Benjamin Herrenschmidt wrote:
On Tue, 2011-11-15 at 16:45 -0600, Moffett, Kyle D wrote:
With that said, I'm curious about the origin of the PPC32 ASM. In
particular, it looks like it was generated by GCC at some point in the
distant past, and I'm wondering
On Nov 10, 2011, at 23:40, Benjamin Herrenschmidt wrote:
On Thu, 2011-11-10 at 18:38 -0600, Moffett, Kyle D wrote:
(2) Make the ppc64_caches struct apply to ppc32 as well, and
preinitialize it with a minimum value used by any platform being
compiled in (for dcbXX/icbXX purposes
On Nov 10, 2011, at 09:04, Timur Tabi wrote:
Kyle Moffett wrote:
CONFIG_PHYS_64BIT_SUPPORTED:
This hidden option should be selected by any CPU type which supports
64-bit physical addresses. This will enable the PHYS_64BIT option
to be selected. It is (obviously) always set on
On Nov 10, 2011, at 08:37, Kumar Gala wrote:
On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
+#if defined(CONFIG_FSL_E500MC) || defined(CONFIG_FSL_E5500)
+#ifdef CONFIG_FSL_E500_V1_V2
doesn't exist yet, so patch is wrong sequence order.
Oops, d'oh.
You are completely correct, thanks for
On Nov 10, 2011, at 08:59, Kumar Gala wrote:
On Nov 9, 2011, at 6:03 PM, Kyle Moffett wrote:
I saw Baruch Siach's patch:
powerpc: 85xx: separate e500 from e500mc
Unfortunately, that patch breaks the dependencies for the P5020DS
platform and does not fix the underlying code which does not
On Nov 10, 2011, at 12:03, Scott Wood wrote:
On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote:
On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.
I see
On Nov 10, 2011, at 11:54, Scott Wood wrote:
On Thu, Nov 10, 2011 at 10:30:41AM -0600, Kumar Gala wrote:
On Nov 10, 2011, at 10:17 AM, Moffett, Kyle D wrote:
Furthermore, it looks like there are a couple issues here I missed
before. PPC64 systems all appear to have an L1_CACHE_SHIFT of 7
On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
after investigating problems with sata_sil24.c on a freescale p2020
soc, I wonder if this driver works on powerpc at all?
Does anyone know of a working setup of sata_sil24 on a big endian
powerpc system?
Our P2020 boards work fine with
Hello everyone,
I'm currently cleaning up a new P2020 (mpc85xx) board port for submission and I
was noticing a lot of commonalities between the various ports.
In particular, at least 80% of the mpic_alloc() callers seem to do something
like this (with more error-checking):
struct resource r;
Hello everyone,
I just started trying to update some patches for our P2020-based unit to the
latest Linus upstream, hoping to take advantage of the recent mpc85xx kexec()
support.
Unfortunately I'm getting a compile error:
arch/powerpc/platforms/85xx/smp.c:241: error: 'struct machdep_calls'
14 matches
Mail list logo
