FSL PCIe controller v2.1:
- New MSI inbound window
- Same Inbound windows address as PCIe controller v1.x
Added new pit_t member(pmit) to struct ccsr_pci for MSI inbound window
FSL PCIe controller v2.2 and v2.3:
- Different addresses for PCIe inbound window 3,2,1
- Exposed
-Original Message-
From: Dan Malek [mailto:ppc6...@digitaldans.com]
Sent: Wednesday, February 23, 2011 8:39 PM
To: John Linn
Cc: linuxppc-...@ozlabs.org
Subject: Re: Flushing data cache on PPC405 in Linux
Hi John.
On Feb 23, 2011, at 5:04 PM, John Linn wrote:
Any
-Original Message-
From: John Linn
Sent: Thursday, February 24, 2011 7:15 AM
To: 'Dan Malek'
Cc: linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca
Subject: RE: Flushing data cache on PPC405 in Linux
-Original Message-
From: Dan Malek [mailto:ppc6...@digitaldans.com]
On Wed, Feb 23, 2011 at 10:54:59AM -0700, Grant Likely wrote:
On Wed, Feb 23, 2011 at 11:26:12AM -0600, Scott Wood wrote:
The eTSEC revision is probeable as well, but due the way PTP is described as
a separate node, the driver doesn't have straightforward access to those
registers.
On Wed, Feb 23, 2011 at 01:24:44PM -0600, Scott Wood wrote:
Whatever string is used should be written into a binding document.
fsl,etsec-v1.6-ptp seems like it would be just as good for that purpose.
Even just fsl,etsec-ptp will identify the binding, though it's lacking in
identifying the
On Thu, 24 Feb 2011 17:39:44 +0100
Richard Cochran richardcoch...@gmail.com wrote:
On Wed, Feb 23, 2011 at 10:54:59AM -0700, Grant Likely wrote:
On Wed, Feb 23, 2011 at 11:26:12AM -0600, Scott Wood wrote:
The eTSEC revision is probeable as well, but due the way PTP is described
as
On Wed, Feb 23, 2011 at 09:50:58AM -0700, Grant Likely wrote:
On Wed, Feb 23, 2011 at 11:38:17AM +0100, Richard Cochran wrote:
+Clock Properties:
+
+ - tclk-period Timer reference clock period in nanoseconds.
+ - tmr-prsc Prescaler, divides the output clock.
+ - tmr-add
On Thu, 24 Feb 2011 17:50:04 +0100
Richard Cochran richardcoch...@gmail.com wrote:
On Wed, Feb 23, 2011 at 01:24:44PM -0600, Scott Wood wrote:
Whatever string is used should be written into a binding document.
fsl,etsec-v1.6-ptp seems like it would be just as good for that purpose.
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;
Hi,
Thanks for taking some of your valuable time to reply.
Now I can't get it to fail. I don't know what I did wrong??? These
things are tryin' to push me over the edge!
Part of the problem may be the /dev/rtc (10:135 or whatever the PC
numbers are) PC device that gets put into /dev/ (udev) on
On Feb 24, 2011, at 6:43 AM, John Linn wrote:
It seems like this also depends on that fact that __GFP_COLD will
work,
otherwise some of the data could
already be in the cache such that you're not guaranteed to get
everything out of the cache.
I wouldn't count on GFP_COLD as a guarantee the
On Thu, 2011-02-24 at 11:43 -0600, Moffett, Kyle D wrote:
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
On Wed, 2011-02-23 at 22:18 +0100, Robert Thorhuus wrote:
Hello!
I'm quite new to linux and Open Firmware.
I have a PPC processor. To this I have a Compact Flash connected. The Compact
Flash is using external interrupt 0 of the processor.
In my DTS file I have specified a Compact Flash
On Thu, 30 Dec 2010, Benjamin Herrenschmidt wrote:
On Wed, 2010-12-29 at 14:54 -0800, Hugh Dickins wrote:
With recent 2.6.37-rc, with CONFIG_PREEMPT=y CONFIG_DEBUG_PREEMPT=y
on the PowerPC G5, I get spammed by BUG warnings each time I swapoff:
BUG: using smp_processor_id() in preemptible
On Thu, 2011-02-24 at 12:47 -0800, Hugh Dickins wrote:
Lovely problem :-), benh mentioned it on IRC, but I never got around to
finding the email thread, thanks for the CC.
What would be better for 2.6.38 and 2.6.37-stable? Moving that call to
vunmap_page_range back under vb-lock, or the
On Thu, 2011-02-24 at 12:47 -0800, Hugh Dickins wrote:
Reading back, I see Jeremy suggested moving vb_free()'s call to
vunmap_page_range() back inside vb-lock: it certainly was his moving
the call out from under that lock that brought the issue to my notice;
but it looked as if there were
On Thu, 2011-02-24 at 22:07 +0100, Peter Zijlstra wrote:
Lovely problem :-), benh mentioned it on IRC, but I never got around
to
finding the email thread, thanks for the CC.
What would be better for 2.6.38 and 2.6.37-stable? Moving that call
to
vunmap_page_range back under vb-lock, or
On Fri, 2011-02-25 at 08:23 +1100, Benjamin Herrenschmidt wrote:
I don't think that's needed here as there shall be no batching happening
on the vmalloc space, but it can't hurt to merge it regardless :-)
Ah, due to the !batch-active thing? OK, then yeah Hugh's bit is
sufficient.
The patch below removes an extra l in the word.
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
---
arch/powerpc/platforms/pseries/eeh.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh.c
Thank you Benjamin!
Sorry for not using your qouting schema :(
Benjamin, you are right about the IRQ flags. Those interrupt.h flags seems to
differ from my processor reference manual.
None the less. Antov, I saw that the code snippet I refer to below:
ret = of_irq_to_resource(dn, 0,
On Thu, Feb 24, 2011 at 11:27:31AM -0600, Scott Wood wrote:
My vote, if it goes in a separate node at all, is fsl,etsec-ptp,
So, that is what the patch does.
and let the driver use SVR.
What is SVR?
Thanks,
Richard
___
Linuxppc-dev mailing list
21 matches
Mail list logo
