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 t
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:
git://opensource.exmeritus.c
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.
>>
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 th
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
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 i
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 appea
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 e500
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 d
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, tha
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 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;
o
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' ha
14 matches
Mail list logo
