Hi!
> > Though it's my understanding that at least ia64 does require the
> > explicit barriers anyway, so we are still in a dodgy situation here
> > where it's not clear what drivers should do and we end up with
> > possibly excessive barriers on powerpc where I end up with both
> > the wmb/r
Hi!
> >>The only way to guarantee ordering in the above setup,
> >>is to either
> >>make writel() fully ordered or adding the mmiowb()'s
> >>inbetween the two
> >>writel's. On Altix you have to go and read from the
> >>PCI brige to
> >>ensure all writes to it have been flushed, which is
> >>al
On Fri, May 30, 2008 at 08:49:45AM +0200, Wolfgang Grandegger wrote:
> This patch adds support for the TQM8548 modules from TQ-Components
> GmbH (http://www.tqc.de).
[snip]
> index 000..d09250a
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/tqm8548.dts
> @@ -0,0 +1,370 @@
> +/*
> + * TQM8548 De
On Thu, 2008-05-22 at 14:31 -0400, Steven Rostedt wrote:
> This patch cleans up the ftrace code in PowerPC based on the comments from
> Michael Ellerman.
Hi Steven,
Thanks for that.
I posted some patches last week, also in my git tree[1], that should
allow you to use create_branch() in your code
When building a signal or a ucontext, we can incorrectly set the MSR_VEC
bit of the kernel pt_regs->msr before returning to userspace if the task
-ever- used VMX.
This can lead to funny result if that stack used it in the past, then
"lost" it (ie. it wasn't enabled after a context switch for examp
David Gibson wrote:
> On Fri, May 30, 2008 at 08:49:45AM +0200, Wolfgang Grandegger wrote:
>> This patch adds support for the TQM8548 modules from TQ-Components
>> GmbH (http://www.tqc.de).
>
> [snip]
>> index 000..d09250a
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/tqm8548.dts
>> @@ -0,0
