On Friday 04 February 2011, Meador Inge wrote:
> On 02/03/2011 09:56 AM, Arnd Bergmann wrote:
> So in 'mpic_init' we don't initialize anything and then in
> 'mpic_host_map' we lazily do the VECPRI and CPU binding initialization with:
>
> if (!(mpic->flags & MPIC_WANTS_RESET))
>
On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
>diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
>index 2a030d8..b33c5e6 100644
>--- a/arch/powerpc/mm/tlb_nohash.c
>+++ b/arch/powerpc/mm/tlb_nohash.c
>@@ -35,6 +35,7 @@
> #include
> #include
> #include
>+#i
On Tue, Feb 01, 2011 at 12:48:45PM -0600, Dave Kleikamp wrote:
>+static ibm4xx_memstart;
>+
> static void iss_4xx_fixups(void)
> {
>- ibm4xx_sdram_fixup_memsize();
>+ void *memory;
>+ u32 reg[3];
>+
>+ memory = finddevice("/memory");
>+ if (!memory)
>+ fatal("C
On Fri, 2011-02-04 at 09:07 -0500, Josh Boyer wrote:
> On Tue, Feb 01, 2011 at 12:48:45PM -0600, Dave Kleikamp wrote:
> >+static ibm4xx_memstart;
> >+
> > static void iss_4xx_fixups(void)
> > {
> >-ibm4xx_sdram_fixup_memsize();
> >+void *memory;
> >+u32 reg[3];
> >+
> >+memory = fin
On Fri, 2011-02-04 at 08:56 -0500, Josh Boyer wrote:
> On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> >diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
> >index 2a030d8..b33c5e6 100644
> >--- a/arch/powerpc/mm/tlb_nohash.c
> >+++ b/arch/powerpc/mm/tlb_nohas
Hi,
FYI:
This driver has some pretty good diagnostics/debug capabilities built
in. Once that is enabled it shows that the inquiry works and the sync
negotiation works. The next command (I think) is test unit ready,
which does not work. It is retried multiple times. The result is 2
which I thi
On Fri, 2011-02-04 at 11:21 -0600, kevin diggs wrote:
>
> P.S.: I posted some documentation for dump_stack()/show_stack() but
> have not heard anything? Is that not something we are interested in
> doing?
Or I haven't had a chance to review it yet ... I'm very very busy at the
moment so things
This patch set provides a binding for Open PIC and implements support for
a new property, specified by that binding, called "pic-no-reset". With
"pic-no-reset" in place the "protected-sources" property is no longer needed
and its full implementation was removed. "protected-sources" is still check
In a recent thread [1,2,3] concerning device trees for AMP systems, the
question of whether we really need 'protected-sources' arose. The general
consensus was that a new boolean property 'pic-no-reset' (described in more
detail in a following patch) could be expanded to cover the use cases that
'
This binding documents several properties that have been in use for quite
some time, and adds one new property 'pic-no-reset', which controls the runtime
initialization behavior of the PIC. More specifically, the presence of
'pic-no-reset' mandates that the PIC shall not be reset during runtime
in
This property, defined in the Open PIC binding, tells the kernel not to use the
reset bit in the global configuration register. Additionally, its presence
mandates that only sources which are actually used (i.e. appear in the device
tree) should have their VECPRI bits initialized.
The presence of
The "protected-sources" property was being used in the AMP configured
MPC8572DS and P2020RDB DTS files. This changeset modifies those files
to use "pic-no-reset" instead.
Signed-off-by: Meador Inge
Cc: Hollis Blanchard
Cc: Kumar Gala
---
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts |6 +
Is there any official statement on what the minimum alignment is for
memory returned by dma_alloc_coherent? I know that since it uses a
page allocator to do the actual allocation, that the memory is page
aligned (at least on PowerPC). Is this something I can rely on?
Would anyone have a complain
On Feb 4, 2011, at 4:14 PM, Timur Tabi wrote:
Is there any official statement on what the minimum alignment is for
memory returned by dma_alloc_coherent?
This is dependent upon the particular implementation.
There have been several over the history of this API,
and some would work out of a DM
Dan Malek wrote:
>
>
>> On a side note, do I really need to pass GFP_DMA
>
> The GFP_DMA is architecture dependent. Are you writing
> a driver to be used across multiple architectures?
It's conceivable that the driver could work on PowerPC and ARM.
> If it's
> necessary, I'd document why yo
Hi Mohan,
Were you able to fix your problem? I am having the same problem with my board.
It is PPC750FX with Marvell MV64460.
Jacob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Feb 4, 2011, at 6:04 PM, Tabi Timur-B04825 wrote:
I guess I'm not clear. I was wondering why an API called
"dma_alloc_coherent" (that has the word "dma" in it) needs to be
told to allocate DMA-safe memory.
I understood your question, and I indicated this is used in a
platform specific
Currently, ppc32 uses sysdata for the pci_controller pointer, and
ppc64 uses it to hold the device_node pointer. This patch moves the
of_node pointer into (struct pci_bus*)->dev.of_node and
(struct pci_dev*)->dev.of_node so that sysdata can be converted to always
use the pci_controller pointer ins
18 matches
Mail list logo
