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
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, &i
The patch below removes an extra "l" in the word.
Signed-off-by: Justin P. Mattock
---
arch/powerpc/platforms/pseries/eeh.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh.c
b/arch/powerpc/platforms/pseries/eeh.c
index 17a11c8..3cc4d
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.
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
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 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 par
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 pre
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 F
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 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
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 Y
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
On Thu, 24 Feb 2011 17:50:04 +0100
Richard Cochran 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.
> >
> > Even just fsl,e
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-ad
On Thu, 24 Feb 2011 17:39:44 +0100
Richard Cochran 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
> > > a separate n
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
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.
>
> -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...@digitalda
> -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:
>
> >
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 PCI
21 matches
Mail list logo
