* Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
From: Segher Boessenkool @ 2009-11-27 12:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <9741644C-BED3-45D9-B405-4C4FC2184DC7@kernel.crashing.org>
>>>>>> +/*
>>>>>> + * Each interrupt has a corresponding bit in both
>>>>>> + * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
>>>>>> + *
>>>>>> + * Enabling/disabling an interrupt line involves asserting/
>>>>>> clearing
>>>>>> + * the corresponding bit in IMR. ACK'ing a request simply
>>>>>> involves
>>>>>> + * asserting the corresponding bit in ICR.
>>>>>> + */
>>>
>>> I looked it up in YAGCD; it says that _reading_ the ICR reg already
>>> acks all interrupts (and clears the bits), you never write this reg!
>>
>> YAGCD is not always right. You should not take it as _the truth_.
>
> Oh I know. But I have no better source of information. Well I could
> actually test it, that's very easy using OF :-) Let's do that.
I tested it. It turns out that neither reading or writing this register
does anything; the bits are automatically cleared when the source
deasserts.
I didn't test all interrupts, some are harder to generate "on demand"
than
others.
Segher
^ permalink raw reply
* Re: [RFC PATCH 06/19] powerpc: gamecube/wii: introduce GAMECUBE_COMMON
From: Segher Boessenkool @ 2009-11-27 12:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259212129.16367.262.camel@pasglop>
>>>> Add a config option GAMECUBE_COMMON to be used as a dependency
>>>> for all
>>>> options common to the Nintendo GameCube and Wii video game
>>>> consoles.
>>>
>>> Maybe something like GAMECUBE_OR_WII instead? "COMMON" is so
>>> common it's meaningless.
>>
>> I don't like either GAMECUBE_OR_WII.
>> It looks as if it can be used to match options for the GAMECUBE
>> _or_ WII. But that's not the meaning of it.
>>
>> This option should be used only for options applicable to both the
>> GAMECUBE and WII, i.e. basically those options in the WII which
>> where "inherited" from the GAMECUBE to make it retro-compatible.
>>
>> If GAMECUBE_COMMON is unacceptable, maybe GAMECUBE_LEGACY or
>> GAMECUBE_COMPAT?
>
> I don't have any strong opinion. Maybe NINTENDO_COMMON ?
That is much worse than GAMECUBE_COMMON.
Can you call the "common" option GAMECUBE, and have WII be for support
for whatever is new on the Wii? Or is there some significant code that
is only needed on the old gamecube?
Segher
^ permalink raw reply
* Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
From: Segher Boessenkool @ 2009-11-27 12:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259209392.16367.242.camel@pasglop>
>> Similarly, it is better to use a compatible value of something like:
>> compatible = "nintendo,flipper-immr"; (instead of "nintendo,flipper")
>> because your describing just the internal bus, not the entire chip.
>
> I would just call the nodes "flipper" and "hollywood".
Either that, or not have these omnibus nodes at all, they are useless
and do not describe the hardware very well either.
Segher
^ permalink raw reply
* Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
From: Segher Boessenkool @ 2009-11-27 12:07 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B0D7AD0.5030605@yahoo.es>
>>> + soc {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + #interrupt-cells = <1>;
>>
>> This isn't an interrupt controller, don't put #interrupt-cells
>> here.
>
> Isn't this needed to define what is to be expected in the
> "interrupts" properties of the child nodes?
Nope. Only interrupt controllers have a #interrupt-cells. When
interpreting the "interrupts" property of some node, you walk the
interrupt tree (which can be the same as the device tree, or fully
separate, or share some things; and doesn't have to be a tree either)
up to the next interrupt controller, and use the #interrupt-cells
from that. (This is simplified a little bit).
>>> + auxram@0c005000 {
>>> + compatible = "nintendo,flipper-auxram";
>>> + reg = <0x0c005000 0x200>; /* DSP */
>>> + interrupts = <6>;
>>> + interrupt-parent = <&pic>;
>>> + };
>>> +
>>> + audio@0c005000 {
>>> + compatible = "nintendo,flipper-audio";
>>> + reg = <0x0c005000 0x200 /* DSP */
>>> + 0x0c006c00 0x20>; /* AI */
>>> + interrupts = <6>;
>>> + interrupt-parent = <&pic>;
>>> + };
>>
>> These two have the same address, not good. Just remove the
>> auxram node?
>
> The DSP and the ARAM control/status bits share some registers in
> the same block.
>
> How should I match the aram block driver if I remove the auxram node?
You can make aram a child node of dsp, which allows you to show
its size as well. I.e. you do #a-cells=1 #s-cells=1 in the dsp
node, and reg=<0 01000000> in the aram node.
Or you can do a simple property in the dsp node saying how big
the aram is, and assume the driver(s) that match know(s) how to
drive it. You have to assume this anyway, you're not putting
e.g. bytecode drivers in the device tree ;-)
>> ...and all the applicable things I mentioned in my Wii dev tree
>> reply, of course.
>>
>> Wow, it wasn't as bad as I expected actually. But you cheated,
>> you omitted most devices from the device trees :-)
>
> You're welcome to add them too if you have information about them :)
I'll do that later, yes. It's not so big a problem if the device
tree doesn't describe devices you do not support at all.
Segher
^ permalink raw reply
* Re: [PATCH] Reserve memory for kdump kernel within RMO region
From: Simon Horman @ 2009-11-27 11:51 UTC (permalink / raw)
To: M. Mohan Kumar; +Cc: Bernhard Walle, kexec, ppcdev
In-Reply-To: <4B0F8F62.3050000@in.ibm.com>
On Fri, Nov 27, 2009 at 02:05:46PM +0530, M. Mohan Kumar wrote:
> On 11/27/2009 12:56 AM, Bernhard Walle wrote:
> >M. Mohan Kumar schrieb:
> >>On 11/26/2009 12:22 AM, Bernhard Walle wrote:
> >>>M. Mohan Kumar schrieb:
> >>>>Reserve memory for kdump kernel within RMO region
> >>>>
> >>>>When the kernel size exceeds 32MB(observed with some distros), memory
> >>>>for kdump kernel can not be reserved as kdump kernel base is assumed to
> >>>>be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
> >>>>provide the feature to reserve the memory for kdump kernel anywhere in
> >>>>the RMO region.
> >>
> >>Hi Bernhard,
> >>
> >>>Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that
> >>>gets loaded as crashkernel, not for the kernel that loads the
> >>>crashkernel. So it would be perfectly fine that a kernel that has not
> >>>CONFIG_RELOCATABLE set would load another kernel that has
> >>>CONFIG_RELOCATABLE set on an address != 32 M.
> >>
> >>No, with relocatable option, the same kernel is used as both production
> >>and kdump kernel.
> >
> >Can be, but it's not strictly necessary. It depends what userland does.
> >Especially it's possible that a non-relocatable, self-compiled kernel
> >loads a relocatable distribution kernel as capture kernel.
> >
>
> I don't understand why a non-relocatable kernel will use relocatable
> kernel for capturing kdump kernel. The idea for relocatable kernel
> is to avoid using two different kernels to capture kernel dump.
True, but that doesn't necessarily mean that using a relocatable
kdump kernel is required. Well, hopefully not.
> >Also, it would make sense to make the behaviour symmetric across
> >platforms. Currently we have:
> >
> > - x86 and ia64: Without offset on command line, use any offset
> > With offset on command line, use that offset and fail
> > if no memory is available at that offset.
> > - ppc64: Always use 32M and ignore the offset.
> >
> >If your patch gets applied, we have:
> >
> > - ppc64: With CONFIG_RELOCATABLE, use any offset
> > With offset on command
> >
> >I don't see why the behaviour on ppc64 should be completely different.
> >
> >Having maintained kdump for SUSE for x86, ia64 and partly ppc64 in the
> >past, I always felt that ppc64 is more different from x86 than ia64 is
> >from x86. That's one more step into that direction without a technical
> >reason.
>
> Also with the crashkernel=auto parameter (patches are not yet
> merged), the crashkernel base (offset) by default would be 32MB. In
> this case if a kernel passed with crashkernel=auto and if the first
> kernel size exceeds 32MB, memory for kdump kernel will always fail.
>
> >
> >Having that all said: If your patch gets in mainline kernel, than we
> >should change the behaviour also for x86 and ia64.
> >
> >
> >
> >Regards,
> >Bernhard
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH] fix PPC floating point debug
From: Benjamin Herrenschmidt @ 2009-11-27 11:01 UTC (permalink / raw)
To: Stefani Seibold; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1259312340.9648.6.camel@wall-e>
On Fri, 2009-11-27 at 09:59 +0100, Stefani Seibold wrote:
> The PPC architecture is unable to debug applications using hardware
> floating point, because it would not save the floating point registers.
>
> After returning from the debugger, the contents of register was
> modified. This patch fix this bug.
I'm not sure what problem you are trying to fix... debugging FP apps
works just fine afaik. You don't need to flush the FP state into the
thread when delivering the SIGTRAP. If you have a signal handler, that
will be done for you by the signal code before laying out the signal
frame. If you are using ptrace, you should be using the appropriate
ptrace calls to retrieve the FP state and they should do the right thing
to.
Do you have a precise example that doesn't work and which is fixed by
your patch ?
Cheers,
Ben.
> Signed-off-by: Stefani Seibold <stefani@seibold.net>
> ---
> traps.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> --- linux-2.6.32-rc5/arch/powerpc/kernel/traps.c.orig 2009-11-27 09:47:37.989943124 +0100
> +++ linux-2.6.32-rc5/arch/powerpc/kernel/traps.c 2009-11-27 09:47:41.088330825 +0100
> @@ -559,6 +559,8 @@ void instruction_breakpoint_exception(st
> return;
> if (debugger_iabr_match(regs))
> return;
> + if (regs->msr & MSR_FP)
> + giveup_fpu(current);
> _exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
> }
>
> @@ -577,6 +579,8 @@ void __kprobes single_step_exception(str
> if (debugger_sstep(regs))
> return;
>
> + if (regs->msr & MSR_FP)
> + giveup_fpu(current);
> _exception(SIGTRAP, regs, TRAP_TRACE, regs->nip);
> }
>
> @@ -834,6 +838,8 @@ void __kprobes program_check_exception(s
> regs->nip += 4;
> return;
> }
> + if (regs->msr & MSR_FP)
> + giveup_fpu(current);
> _exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
> return;
> }
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 00/10 v6] Fix 8xx MMU/TLB
From: Joakim Tjernlund @ 2009-11-27 10:57 UTC (permalink / raw)
Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1258712471-3104-1-git-send-email-Joakim.Tjernlund@transmode.se>
Scott and Rex, I think we need you s-o-b to make it into the kernel proper.
Marcelo and Vitaly, I noticed you guys are listed as 8xx maintainers.
Have you seen this? What do you think?
Jocke
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote on 20/11/2009 11:21:01:
>
> Yet again an iteration of the series.
> Rex & Scott, please test and signoff.
> Changes since last version:
> - Fix rlwimi insn(from Scott)
>
> Joakim Tjernlund (10):
> 8xx: invalidate non present TLBs
> 8xx: Update TLB asm so it behaves as linux mm expects.
> 8xx: Tag DAR with 0x00f0 to catch buggy instructions.
> 8xx: Always pin kernel instruction TLB
> 8xx: Fixup DAR from buggy dcbX instructions.
> 8xx: Add missing Guarded setting in DTLB Error.
> 8xx: Restore _PAGE_WRITETHRU
> 8xx: start using dcbX instructions in various copy routines
> 8xx: Remove DIRTY pte handling in DTLB Error.
> 8xx: DTLB Miss cleanup
>
> arch/powerpc/include/asm/pte-8xx.h | 14 +-
> arch/powerpc/kernel/head_8xx.S | 315 ++++++++++++++++++++++--------------
> arch/powerpc/kernel/misc_32.S | 18 --
> arch/powerpc/lib/copy_32.S | 24 ---
> arch/powerpc/mm/fault.c | 8 +-
> 5 files changed, 211 insertions(+), 168 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2] ppc440spe-adma: adds updated ppc440spe adma driver
From: Anatolij Gustschin @ 2009-11-27 10:26 UTC (permalink / raw)
To: Tirumala Reddy Marri
Cc: wd, dzu, Yuri Tikhonov, linux-raid, linuxppc-dev, dan.j.williams
In-Reply-To: <AC5E1C3367E37D44970B81A6ADD1DA2C08642A43@SDCEXCHANGE01.ad.amcc.com>
"Tirumala Reddy Marri" <tmarri@amcc.com> wrote:
> Why are we having separate directory for 440spe. Can this be generalized
> arch/dma/ppc4xx/ppc4xx_dma.c ?
currently there is only tested support for 440spe. If the driver
will be extended to support other CPUs, then the renaming can be
done while adding support for other CPUs. 'arch/' is not correct,
it should be 'driver/'.
Best regards,
Anatolij
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* [PATCH] powerpc/ipic: support external edge triggered IRQ0
From: Norbert van Bolhuis @ 2009-11-27 10:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: nvbolhuis
Currently an external edge triggered IRQ0 gives 2 problems.
It gives a sense error ("edge sense not supported on internal interrupts")
and it isn't acked.
This patch takes into account IRQ0 can be internal or external and fixes
both issues.
Signed-off-by: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
---
arch/powerpc/sysdev/ipic.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index cb7689c..3201db1 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -316,6 +316,7 @@ static struct ipic_info ipic_info[] = {
.prio_mask = 7,
},
[48] = {
+ .ack = IPIC_SEPNR,
.mask = IPIC_SEMSR,
.prio = IPIC_SMPRR_A,
.force = IPIC_SEFCR,
@@ -619,7 +620,9 @@ static int ipic_set_irq_type(unsigned int virq, unsigned int flow_type)
return -EINVAL;
}
/* ipic supports only edge mode on external interrupts */
- if ((flow_type & IRQ_TYPE_EDGE_FALLING) && !ipic_info[src].ack) {
+ if ((flow_type & IRQ_TYPE_EDGE_FALLING) &&
+ ((src != IPIC_IRQ_EXT0 && !ipic_info[src].ack) ||
+ (src == IPIC_IRQ_EXT0 && (ipic_read(ipic->regs, IPIC_SEMSR) & SEMSR_SIRQ0)))) {
printk(KERN_ERR "ipic: edge sense not supported on internal "
"interrupts\n");
return -EINVAL;
--
1.5.2.2
^ permalink raw reply related
* [PATCH] fix PPC floating point debug
From: Stefani Seibold @ 2009-11-27 8:59 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
The PPC architecture is unable to debug applications using hardware
floating point, because it would not save the floating point registers.
After returning from the debugger, the contents of register was
modified. This patch fix this bug.
Signed-off-by: Stefani Seibold <stefani@seibold.net>
---
traps.c | 6 ++++++
1 file changed, 6 insertions(+)
--- linux-2.6.32-rc5/arch/powerpc/kernel/traps.c.orig 2009-11-27 09:47:37.989943124 +0100
+++ linux-2.6.32-rc5/arch/powerpc/kernel/traps.c 2009-11-27 09:47:41.088330825 +0100
@@ -559,6 +559,8 @@ void instruction_breakpoint_exception(st
return;
if (debugger_iabr_match(regs))
return;
+ if (regs->msr & MSR_FP)
+ giveup_fpu(current);
_exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
}
@@ -577,6 +579,8 @@ void __kprobes single_step_exception(str
if (debugger_sstep(regs))
return;
+ if (regs->msr & MSR_FP)
+ giveup_fpu(current);
_exception(SIGTRAP, regs, TRAP_TRACE, regs->nip);
}
@@ -834,6 +838,8 @@ void __kprobes program_check_exception(s
regs->nip += 4;
return;
}
+ if (regs->msr & MSR_FP)
+ giveup_fpu(current);
_exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
return;
}
^ permalink raw reply
* Re: [PATCH] Reserve memory for kdump kernel within RMO region
From: M. Mohan Kumar @ 2009-11-27 8:35 UTC (permalink / raw)
To: Bernhard Walle; +Cc: kexec, ppcdev
In-Reply-To: <4B0ED674.6050501@bwalle.de>
On 11/27/2009 12:56 AM, Bernhard Walle wrote:
> M. Mohan Kumar schrieb:
>> On 11/26/2009 12:22 AM, Bernhard Walle wrote:
>>> M. Mohan Kumar schrieb:
>>>> Reserve memory for kdump kernel within RMO region
>>>>
>>>> When the kernel size exceeds 32MB(observed with some distros), memory
>>>> for kdump kernel can not be reserved as kdump kernel base is assumed to
>>>> be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
>>>> provide the feature to reserve the memory for kdump kernel anywhere in
>>>> the RMO region.
>>
>> Hi Bernhard,
>>
>>> Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that
>>> gets loaded as crashkernel, not for the kernel that loads the
>>> crashkernel. So it would be perfectly fine that a kernel that has not
>>> CONFIG_RELOCATABLE set would load another kernel that has
>>> CONFIG_RELOCATABLE set on an address != 32 M.
>>
>> No, with relocatable option, the same kernel is used as both production
>> and kdump kernel.
>
> Can be, but it's not strictly necessary. It depends what userland does.
> Especially it's possible that a non-relocatable, self-compiled kernel
> loads a relocatable distribution kernel as capture kernel.
>
I don't understand why a non-relocatable kernel will use relocatable
kernel for capturing kdump kernel. The idea for relocatable kernel is to
avoid using two different kernels to capture kernel dump.
> Also, it would make sense to make the behaviour symmetric across
> platforms. Currently we have:
>
> - x86 and ia64: Without offset on command line, use any offset
> With offset on command line, use that offset and fail
> if no memory is available at that offset.
> - ppc64: Always use 32M and ignore the offset.
>
> If your patch gets applied, we have:
>
> - ppc64: With CONFIG_RELOCATABLE, use any offset
> With offset on command
>
> I don't see why the behaviour on ppc64 should be completely different.
>
> Having maintained kdump for SUSE for x86, ia64 and partly ppc64 in the
> past, I always felt that ppc64 is more different from x86 than ia64 is
> from x86. That's one more step into that direction without a technical
> reason.
Also with the crashkernel=auto parameter (patches are not yet merged),
the crashkernel base (offset) by default would be 32MB. In this case if
a kernel passed with crashkernel=auto and if the first kernel size
exceeds 32MB, memory for kdump kernel will always fail.
>
> Having that all said: If your patch gets in mainline kernel, than we
> should change the behaviour also for x86 and ia64.
>
>
>
> Regards,
> Bernhard
^ permalink raw reply
* ucc_geth: Fix the wrong the Rx/Tx FIFO size
From: Dave Liu @ 2009-11-27 8:16 UTC (permalink / raw)
To: davem; +Cc: netdev, @vger.kernel.org, linuxppc-dev
current the Rx/Tx FIFO size settings cause problem
when four UEC ethernets work simultaneously.
eg: GETH1, UEM-J15, GETH2, UEC-J5 on 8569MDS board
$ ifconfig eth0 10.193.20.166
$ ifconfig eth1 10.193.20.167
$ ifconfig eth2 10.193.20.168
then
$ ifconfig eth3 10.193.20.169
The fourth ethernet will cause all of interface broken,
you cann't ping successfully any more.
The patch fix this issue for MPC8569 Rev1.0 and Rev2.0
Signed-off-by: Dave Liu <daveliu@freescale.com>
---
drivers/net/ucc_geth.h | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 03a6ca0..26a43ed 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -838,13 +838,13 @@ struct ucc_geth_hardware_statistics {
using the maximum is
easier */
#define UCC_GETH_SEND_QUEUE_QUEUE_DESCRIPTOR_ALIGNMENT 32
-#define UCC_GETH_SCHEDULER_ALIGNMENT 4 /* This is a guess */
+#define UCC_GETH_SCHEDULER_ALIGNMENT 8 /* This is a guess */
#define UCC_GETH_TX_STATISTICS_ALIGNMENT 4 /* This is a guess */
#define UCC_GETH_RX_STATISTICS_ALIGNMENT 4 /* This is a guess */
#define UCC_GETH_RX_INTERRUPT_COALESCING_ALIGNMENT 64
#define UCC_GETH_RX_BD_QUEUES_ALIGNMENT 8 /* This is a guess */
#define UCC_GETH_RX_PREFETCHED_BDS_ALIGNMENT 128 /* This is a guess */
-#define UCC_GETH_RX_EXTENDED_FILTERING_GLOBAL_PARAMETERS_ALIGNMENT 4 /* This
+#define UCC_GETH_RX_EXTENDED_FILTERING_GLOBAL_PARAMETERS_ALIGNMENT 8 /* This
is a
guess
*/
@@ -899,16 +899,17 @@ struct ucc_geth_hardware_statistics {
#define UCC_GETH_UTFS_INIT 512 /* Tx virtual FIFO size
*/
#define UCC_GETH_UTFET_INIT 256 /* 1/2 utfs */
-#define UCC_GETH_UTFTT_INIT 128
+#define UCC_GETH_UTFTT_INIT 512
/* Gigabit Ethernet (1000 Mbps) */
#define UCC_GETH_URFS_GIGA_INIT 4096/*2048*/ /* Rx virtual
FIFO size */
#define UCC_GETH_URFET_GIGA_INIT 2048/*1024*/ /* 1/2 urfs */
#define UCC_GETH_URFSET_GIGA_INIT 3072/*1536*/ /* 3/4 urfs */
-#define UCC_GETH_UTFS_GIGA_INIT 8192/*2048*/ /* Tx virtual
+#define UCC_GETH_UTFS_GIGA_INIT 4096/*2048*/ /* Tx virtual
+ FIFO size */
+#define UCC_GETH_UTFET_GIGA_INIT 2048/*1024*/ /* 1/2 utfs */
+#define UCC_GETH_UTFTT_GIGA_INIT 4096/*0x40*/ /* Tx virtual
FIFO size */
-#define UCC_GETH_UTFET_GIGA_INIT 4096/*1024*/ /* 1/2 utfs */
-#define UCC_GETH_UTFTT_GIGA_INIT 0x400/*0x40*/ /* */
#define UCC_GETH_REMODER_INIT 0 /* bits that must be
set */
--
1.6.4
^ permalink raw reply related
* [PATCH] via-pmu: convert to proc_fops/seq_file
From: Alexey Dobriyan @ 2009-11-27 6:53 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, akpm, paulus
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/macintosh/via-pmu.c | 160 +++++++++++++++++++++++++-------------------
1 file changed, 91 insertions(+), 69 deletions(-)
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -36,6 +36,7 @@
#include <linux/spinlock.h>
#include <linux/pm.h>
#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/device.h>
@@ -186,17 +187,11 @@ static int init_pmu(void);
static void pmu_start(void);
static irqreturn_t via_pmu_interrupt(int irq, void *arg);
static irqreturn_t gpio1_interrupt(int irq, void *arg);
-static int proc_get_info(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-static int proc_get_irqstats(char *page, char **start, off_t off,
- int count, int *eof, void *data);
+static const struct file_operations pmu_info_proc_fops;
+static const struct file_operations pmu_irqstats_proc_fops;
static void pmu_pass_intr(unsigned char *data, int len);
-static int proc_get_batt(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-static int proc_read_options(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-static int proc_write_options(struct file *file, const char __user *buffer,
- unsigned long count, void *data);
+static const struct file_operations pmu_battery_proc_fops;
+static const struct file_operations pmu_options_proc_fops;
#ifdef CONFIG_ADB
struct adb_driver via_pmu_driver = {
@@ -507,19 +502,15 @@ static int __init via_pmu_dev_init(void)
for (i=0; i<pmu_battery_count; i++) {
char title[16];
sprintf(title, "battery_%ld", i);
- proc_pmu_batt[i] = create_proc_read_entry(title, 0, proc_pmu_root,
- proc_get_batt, (void *)i);
+ proc_pmu_batt[i] = proc_create_data(title, 0, proc_pmu_root,
+ &pmu_battery_proc_fops, (void *)i);
}
- proc_pmu_info = create_proc_read_entry("info", 0, proc_pmu_root,
- proc_get_info, NULL);
- proc_pmu_irqstats = create_proc_read_entry("interrupts", 0, proc_pmu_root,
- proc_get_irqstats, NULL);
- proc_pmu_options = create_proc_entry("options", 0600, proc_pmu_root);
- if (proc_pmu_options) {
- proc_pmu_options->read_proc = proc_read_options;
- proc_pmu_options->write_proc = proc_write_options;
- }
+ proc_pmu_info = proc_create("info", 0, proc_pmu_root, &pmu_info_proc_fops);
+ proc_pmu_irqstats = proc_create("interrupts", 0, proc_pmu_root,
+ &pmu_irqstats_proc_fops);
+ proc_pmu_options = proc_create("options", 0600, proc_pmu_root,
+ &pmu_options_proc_fops);
}
return 0;
}
@@ -799,27 +790,33 @@ query_battery_state(void)
2, PMU_SMART_BATTERY_STATE, pmu_cur_battery+1);
}
-static int
-proc_get_info(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int pmu_info_proc_show(struct seq_file *m, void *v)
{
- char* p = page;
-
- p += sprintf(p, "PMU driver version : %d\n", PMU_DRIVER_VERSION);
- p += sprintf(p, "PMU firmware version : %02x\n", pmu_version);
- p += sprintf(p, "AC Power : %d\n",
+ seq_printf(m, "PMU driver version : %d\n", PMU_DRIVER_VERSION);
+ seq_printf(m, "PMU firmware version : %02x\n", pmu_version);
+ seq_printf(m, "AC Power : %d\n",
((pmu_power_flags & PMU_PWR_AC_PRESENT) != 0) || pmu_battery_count == 0);
- p += sprintf(p, "Battery count : %d\n", pmu_battery_count);
+ seq_printf(m, "Battery count : %d\n", pmu_battery_count);
+
+ return 0;
+}
- return p - page;
+static int pmu_info_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, pmu_info_proc_show, NULL);
}
-static int
-proc_get_irqstats(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static const struct file_operations pmu_info_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = pmu_info_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static int pmu_irqstats_proc_show(struct seq_file *m, void *v)
{
int i;
- char* p = page;
static const char *irq_names[] = {
"Total CB1 triggered events",
"Total GPIO1 triggered events",
@@ -835,60 +832,76 @@ proc_get_irqstats(char *page, char **start, off_t off,
};
for (i=0; i<11; i++) {
- p += sprintf(p, " %2u: %10u (%s)\n",
+ seq_printf(m, " %2u: %10u (%s)\n",
i, pmu_irq_stats[i], irq_names[i]);
}
- return p - page;
+ return 0;
}
-static int
-proc_get_batt(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int pmu_irqstats_proc_open(struct inode *inode, struct file *file)
{
- long batnum = (long)data;
- char *p = page;
+ return single_open(file, pmu_irqstats_proc_show, NULL);
+}
+
+static const struct file_operations pmu_irqstats_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = pmu_irqstats_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static int pmu_battery_proc_show(struct seq_file *m, void *v)
+{
+ long batnum = (long)m->private;
- p += sprintf(p, "\n");
- p += sprintf(p, "flags : %08x\n",
- pmu_batteries[batnum].flags);
- p += sprintf(p, "charge : %d\n",
- pmu_batteries[batnum].charge);
- p += sprintf(p, "max_charge : %d\n",
- pmu_batteries[batnum].max_charge);
- p += sprintf(p, "current : %d\n",
- pmu_batteries[batnum].amperage);
- p += sprintf(p, "voltage : %d\n",
- pmu_batteries[batnum].voltage);
- p += sprintf(p, "time rem. : %d\n",
- pmu_batteries[batnum].time_remaining);
-
- return p - page;
+ seq_putc(m, '\n');
+ seq_printf(m, "flags : %08x\n", pmu_batteries[batnum].flags);
+ seq_printf(m, "charge : %d\n", pmu_batteries[batnum].charge);
+ seq_printf(m, "max_charge : %d\n", pmu_batteries[batnum].max_charge);
+ seq_printf(m, "current : %d\n", pmu_batteries[batnum].amperage);
+ seq_printf(m, "voltage : %d\n", pmu_batteries[batnum].voltage);
+ seq_printf(m, "time rem. : %d\n", pmu_batteries[batnum].time_remaining);
+ return 0;
}
-static int
-proc_read_options(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int pmu_battery_proc_open(struct inode *inode, struct file *file)
{
- char *p = page;
+ return single_open(file, pmu_battery_proc_show, PDE(inode)->data);
+}
+static const struct file_operations pmu_battery_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = pmu_battery_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static int pmu_options_proc_show(struct seq_file *m, void *v)
+{
#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
if (pmu_kind == PMU_KEYLARGO_BASED &&
pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,-1) >= 0)
- p += sprintf(p, "lid_wakeup=%d\n", option_lid_wakeup);
+ seq_printf(m, "lid_wakeup=%d\n", option_lid_wakeup);
#endif
if (pmu_kind == PMU_KEYLARGO_BASED)
- p += sprintf(p, "server_mode=%d\n", option_server_mode);
+ seq_printf(m, "server_mode=%d\n", option_server_mode);
- return p - page;
+ return 0;
}
-
-static int
-proc_write_options(struct file *file, const char __user *buffer,
- unsigned long count, void *data)
+
+static int pmu_options_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, pmu_options_proc_show, NULL);
+}
+
+static ssize_t pmu_options_proc_write(struct file *file,
+ const char __user *buffer, size_t count, loff_t *pos)
{
char tmp[33];
char *label, *val;
- unsigned long fcount = count;
+ size_t fcount = count;
if (!count)
return -EINVAL;
@@ -927,6 +940,15 @@ proc_write_options(struct file *file, const char __user *buffer,
return fcount;
}
+static const struct file_operations pmu_options_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = pmu_options_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = pmu_options_proc_write,
+};
+
#ifdef CONFIG_ADB
/* Send an ADB command */
static int pmu_send_request(struct adb_request *req, int sync)
^ permalink raw reply
* [PATCH] iseries: convert to proc_fops
From: Alexey Dobriyan @ 2009-11-27 6:47 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, akpm, paulus
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
arch/powerpc/platforms/iseries/mf.c | 147 ++++++++++++++++++++----------------
1 file changed, 83 insertions(+), 64 deletions(-)
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -855,59 +855,58 @@ static int mf_get_boot_rtc(struct rtc_time *tm)
}
#ifdef CONFIG_PROC_FS
-
-static int proc_mf_dump_cmdline(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int mf_cmdline_proc_show(struct seq_file *m, void *v)
{
- int len;
- char *p;
+ char *page, *p;
struct vsp_cmd_data vsp_cmd;
int rc;
dma_addr_t dma_addr;
/* The HV appears to return no more than 256 bytes of command line */
- if (off >= 256)
- return 0;
- if ((off + count) > 256)
- count = 256 - off;
+ page = kmalloc(256, GFP_KERNEL);
+ if (!page)
+ return -ENOMEM;
- dma_addr = iseries_hv_map(page, off + count, DMA_FROM_DEVICE);
- if (dma_addr == DMA_ERROR_CODE)
+ dma_addr = iseries_hv_map(page, 256, DMA_FROM_DEVICE);
+ if (dma_addr == DMA_ERROR_CODE) {
+ kfree(page);
return -ENOMEM;
- memset(page, 0, off + count);
+ }
+ memset(page, 0, 256);
memset(&vsp_cmd, 0, sizeof(vsp_cmd));
vsp_cmd.cmd = 33;
vsp_cmd.sub_data.kern.token = dma_addr;
vsp_cmd.sub_data.kern.address_type = HvLpDma_AddressType_TceIndex;
- vsp_cmd.sub_data.kern.side = (u64)data;
- vsp_cmd.sub_data.kern.length = off + count;
+ vsp_cmd.sub_data.kern.side = (u64)m->private;
+ vsp_cmd.sub_data.kern.length = 256;
mb();
rc = signal_vsp_instruction(&vsp_cmd);
- iseries_hv_unmap(dma_addr, off + count, DMA_FROM_DEVICE);
- if (rc)
+ iseries_hv_unmap(dma_addr, 256, DMA_FROM_DEVICE);
+ if (rc) {
+ kfree(page);
return rc;
- if (vsp_cmd.result_code != 0)
+ }
+ if (vsp_cmd.result_code != 0) {
+ kfree(page);
return -ENOMEM;
+ }
p = page;
- len = 0;
- while (len < (off + count)) {
- if ((*p == '\0') || (*p == '\n')) {
- if (*p == '\0')
- *p = '\n';
- p++;
- len++;
- *eof = 1;
+ while (p - page < 256) {
+ if (*p == '\0' || *p == '\n') {
+ *p = '\n';
break;
}
p++;
- len++;
- }
- if (len < off) {
- *eof = 1;
- len = 0;
}
- return len;
+ seq_write(m, page, p - page);
+ kfree(page);
+ return 0;
+}
+
+static int mf_cmdline_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, mf_cmdline_proc_show, PDE(inode)->data);
}
#if 0
@@ -962,10 +961,8 @@ static int proc_mf_dump_vmlinux(char *page, char **start, off_t off,
}
#endif
-static int proc_mf_dump_side(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int mf_side_proc_show(struct seq_file *m, void *v)
{
- int len;
char mf_current_side = ' ';
struct vsp_cmd_data vsp_cmd;
@@ -989,21 +986,17 @@ static int proc_mf_dump_side(char *page, char **start, off_t off,
}
}
- len = sprintf(page, "%c\n", mf_current_side);
+ seq_printf(m, "%c\n", mf_current_side);
+ return 0;
+}
- if (len <= (off + count))
- *eof = 1;
- *start = page + off;
- len -= off;
- if (len > count)
- len = count;
- if (len < 0)
- len = 0;
- return len;
+static int mf_side_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, mf_side_proc_show, NULL);
}
-static int proc_mf_change_side(struct file *file, const char __user *buffer,
- unsigned long count, void *data)
+static ssize_t mf_side_proc_write(struct file *file, const char __user *buffer,
+ size_t count, loff_t *pos)
{
char side;
u64 newSide;
@@ -1041,6 +1034,15 @@ static int proc_mf_change_side(struct file *file, const char __user *buffer,
return count;
}
+static const struct file_operations mf_side_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = mf_side_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = mf_side_proc_write,
+};
+
#if 0
static void mf_getSrcHistory(char *buffer, int size)
{
@@ -1087,8 +1089,7 @@ static void mf_getSrcHistory(char *buffer, int size)
}
#endif
-static int proc_mf_dump_src(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int mf_src_proc_show(struct seq_file *m, void *v)
{
#if 0
int len;
@@ -1109,8 +1110,13 @@ static int proc_mf_dump_src(char *page, char **start, off_t off,
#endif
}
-static int proc_mf_change_src(struct file *file, const char __user *buffer,
- unsigned long count, void *data)
+static int mf_src_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, mf_src_proc_show, NULL);
+}
+
+static ssize_t mf_src_proc_write(struct file *file, const char __user *buffer,
+ size_t count, loff_t *pos)
{
char stkbuf[10];
@@ -1135,9 +1141,19 @@ static int proc_mf_change_src(struct file *file, const char __user *buffer,
return count;
}
-static int proc_mf_change_cmdline(struct file *file, const char __user *buffer,
- unsigned long count, void *data)
+static const struct file_operations mf_src_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = mf_src_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = mf_src_proc_write,
+};
+
+static ssize_t mf_cmdline_proc_write(struct file *file, const char __user *buffer,
+ size_t count, loff_t *pos)
{
+ void *data = PDE(file->f_path.dentry->d_inode)->data;
struct vsp_cmd_data vsp_cmd;
dma_addr_t dma_addr;
char *page;
@@ -1172,6 +1188,15 @@ out:
return ret;
}
+static const struct file_operations mf_cmdline_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = mf_cmdline_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = mf_cmdline_proc_write,
+};
+
static ssize_t proc_mf_change_vmlinux(struct file *file,
const char __user *buf,
size_t count, loff_t *ppos)
@@ -1246,12 +1271,10 @@ static int __init mf_proc_init(void)
if (!mf)
return 1;
- ent = create_proc_entry("cmdline", S_IFREG|S_IRUSR|S_IWUSR, mf);
+ ent = proc_create_data("cmdline", S_IRUSR|S_IWUSR, mf,
+ &mf_cmdline_proc_fops, (void *)(long)i);
if (!ent)
return 1;
- ent->data = (void *)(long)i;
- ent->read_proc = proc_mf_dump_cmdline;
- ent->write_proc = proc_mf_change_cmdline;
if (i == 3) /* no vmlinux entry for 'D' */
continue;
@@ -1263,19 +1286,15 @@ static int __init mf_proc_init(void)
return 1;
}
- ent = create_proc_entry("side", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root);
+ ent = proc_create("side", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root,
+ &mf_side_proc_fops);
if (!ent)
return 1;
- ent->data = (void *)0;
- ent->read_proc = proc_mf_dump_side;
- ent->write_proc = proc_mf_change_side;
- ent = create_proc_entry("src", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root);
+ ent = proc_create("src", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root,
+ &mf_src_proc_fops);
if (!ent)
return 1;
- ent->data = (void *)0;
- ent->read_proc = proc_mf_dump_src;
- ent->write_proc = proc_mf_change_src;
return 0;
}
^ permalink raw reply
* Re: Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT (v2)
From: David Gibson @ 2009-11-27 4:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev, Sachin Sant
In-Reply-To: <20091124053114.GD2737@yookeroo>
Oops, stupid compile bug in the !CONFIG_PPC_SUBPAGE_PROT case with the
last version. Fixed below.
Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
Commit a0668cdc154e54bf0c85182e0535eea237d53146 cleans up the handling
of kmem_caches for allocating various levels of pagetables.
Unfortunately, it conflicts badly with CONFIG_PPC_SUBPAGE_PROT, due to
the latter's cleverly hidden technique of adding some extra allocation
space to the top level page directory to store the extra information
it needs.
Since that extra allocation really doesn't fit into the cleaned up
page directory allocating scheme, this patch alters
CONFIG_PPC_SUBPAGE_PROT to instead allocate its struct
subpage_prot_table as part of the mm_context_t.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/arch/powerpc/include/asm/mmu-hash64.h
===================================================================
--- working-2.6.orig/arch/powerpc/include/asm/mmu-hash64.h 2009-11-27 10:40:40.000000000 +1100
+++ working-2.6/arch/powerpc/include/asm/mmu-hash64.h 2009-11-27 15:54:27.423721648 +1100
@@ -373,6 +373,38 @@ extern void slb_set_size(u16 size);
#ifndef __ASSEMBLY__
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+/*
+ * For the sub-page protection option, we extend the PGD with one of
+ * these. Basically we have a 3-level tree, with the top level being
+ * the protptrs array. To optimize speed and memory consumption when
+ * only addresses < 4GB are being protected, pointers to the first
+ * four pages of sub-page protection words are stored in the low_prot
+ * array.
+ * Each page of sub-page protection words protects 1GB (4 bytes
+ * protects 64k). For the 3-level tree, each page of pointers then
+ * protects 8TB.
+ */
+struct subpage_prot_table {
+ unsigned long maxaddr; /* only addresses < this are protected */
+ unsigned int **protptrs[2];
+ unsigned int *low_prot[4];
+};
+
+#define SBP_L1_BITS (PAGE_SHIFT - 2)
+#define SBP_L2_BITS (PAGE_SHIFT - 3)
+#define SBP_L1_COUNT (1 << SBP_L1_BITS)
+#define SBP_L2_COUNT (1 << SBP_L2_BITS)
+#define SBP_L2_SHIFT (PAGE_SHIFT + SBP_L1_BITS)
+#define SBP_L3_SHIFT (SBP_L2_SHIFT + SBP_L2_BITS)
+
+extern void subpage_prot_free(struct mm_struct *mm);
+extern void subpage_prot_init_new_context(struct mm_struct *mm);
+#else
+static inline void subpage_prot_free(struct mm_struct *mm) {}
+static inline void subpage_prot_init_new_context(struct mm_struct *mm) { }
+#endif /* CONFIG_PPC_SUBPAGE_PROT */
+
typedef unsigned long mm_context_id_t;
typedef struct {
@@ -386,6 +418,9 @@ typedef struct {
u16 sllp; /* SLB page size encoding */
#endif
unsigned long vdso_base;
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+ struct subpage_prot_table spt;
+#endif /* CONFIG_PPC_SUBPAGE_PROT */
} mm_context_t;
Index: working-2.6/arch/powerpc/include/asm/pgalloc-64.h
===================================================================
--- working-2.6.orig/arch/powerpc/include/asm/pgalloc-64.h 2009-11-27 10:40:40.000000000 +1100
+++ working-2.6/arch/powerpc/include/asm/pgalloc-64.h 2009-11-27 10:55:00.654766147 +1100
@@ -28,10 +28,6 @@
*/
#define MAX_PGTABLE_INDEX_SIZE 0xf
-#ifndef CONFIG_PPC_SUBPAGE_PROT
-static inline void subpage_prot_free(pgd_t *pgd) {}
-#endif
-
extern struct kmem_cache *pgtable_cache[];
#define PGT_CACHE(shift) (pgtable_cache[(shift)-1])
@@ -42,7 +38,6 @@ static inline pgd_t *pgd_alloc(struct mm
static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
{
- subpage_prot_free(pgd);
kmem_cache_free(PGT_CACHE(PGD_INDEX_SIZE), pgd);
}
Index: working-2.6/arch/powerpc/include/asm/pte-hash64-64k.h
===================================================================
--- working-2.6.orig/arch/powerpc/include/asm/pte-hash64-64k.h 2009-11-17 11:55:00.000000000 +1100
+++ working-2.6/arch/powerpc/include/asm/pte-hash64-64k.h 2009-11-27 10:55:00.654766147 +1100
@@ -76,41 +76,4 @@
remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE, \
__pgprot(pgprot_val((prot)) | _PAGE_4K_PFN))
-
-#ifdef CONFIG_PPC_SUBPAGE_PROT
-/*
- * For the sub-page protection option, we extend the PGD with one of
- * these. Basically we have a 3-level tree, with the top level being
- * the protptrs array. To optimize speed and memory consumption when
- * only addresses < 4GB are being protected, pointers to the first
- * four pages of sub-page protection words are stored in the low_prot
- * array.
- * Each page of sub-page protection words protects 1GB (4 bytes
- * protects 64k). For the 3-level tree, each page of pointers then
- * protects 8TB.
- */
-struct subpage_prot_table {
- unsigned long maxaddr; /* only addresses < this are protected */
- unsigned int **protptrs[2];
- unsigned int *low_prot[4];
-};
-
-#undef PGD_TABLE_SIZE
-#define PGD_TABLE_SIZE ((sizeof(pgd_t) << PGD_INDEX_SIZE) + \
- sizeof(struct subpage_prot_table))
-
-#define SBP_L1_BITS (PAGE_SHIFT - 2)
-#define SBP_L2_BITS (PAGE_SHIFT - 3)
-#define SBP_L1_COUNT (1 << SBP_L1_BITS)
-#define SBP_L2_COUNT (1 << SBP_L2_BITS)
-#define SBP_L2_SHIFT (PAGE_SHIFT + SBP_L1_BITS)
-#define SBP_L3_SHIFT (SBP_L2_SHIFT + SBP_L2_BITS)
-
-extern void subpage_prot_free(pgd_t *pgd);
-
-static inline struct subpage_prot_table *pgd_subpage_prot(pgd_t *pgd)
-{
- return (struct subpage_prot_table *)(pgd + PTRS_PER_PGD);
-}
-#endif /* CONFIG_PPC_SUBPAGE_PROT */
#endif /* __ASSEMBLY__ */
Index: working-2.6/arch/powerpc/mm/subpage-prot.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/subpage-prot.c 2009-11-17 11:55:00.000000000 +1100
+++ working-2.6/arch/powerpc/mm/subpage-prot.c 2009-11-27 10:55:00.658768751 +1100
@@ -24,9 +24,9 @@
* Also makes sure that the subpage_prot_table structure is
* reinitialized for the next user.
*/
-void subpage_prot_free(pgd_t *pgd)
+void subpage_prot_free(struct mm_struct *mm)
{
- struct subpage_prot_table *spt = pgd_subpage_prot(pgd);
+ struct subpage_prot_table *spt = &mm->context.spt;
unsigned long i, j, addr;
u32 **p;
@@ -51,6 +51,13 @@ void subpage_prot_free(pgd_t *pgd)
spt->maxaddr = 0;
}
+void subpage_prot_init_new_context(struct mm_struct *mm)
+{
+ struct subpage_prot_table *spt = &mm->context.spt;
+
+ memset(spt, 0, sizeof(*spt));
+}
+
static void hpte_flush_range(struct mm_struct *mm, unsigned long addr,
int npages)
{
@@ -87,7 +94,7 @@ static void hpte_flush_range(struct mm_s
static void subpage_prot_clear(unsigned long addr, unsigned long len)
{
struct mm_struct *mm = current->mm;
- struct subpage_prot_table *spt = pgd_subpage_prot(mm->pgd);
+ struct subpage_prot_table *spt = &mm->context.spt;
u32 **spm, *spp;
int i, nw;
unsigned long next, limit;
@@ -136,7 +143,7 @@ static void subpage_prot_clear(unsigned
long sys_subpage_prot(unsigned long addr, unsigned long len, u32 __user *map)
{
struct mm_struct *mm = current->mm;
- struct subpage_prot_table *spt = pgd_subpage_prot(mm->pgd);
+ struct subpage_prot_table *spt = &mm->context.spt;
u32 **spm, *spp;
int i, nw;
unsigned long next, limit;
Index: working-2.6/arch/powerpc/mm/hash_utils_64.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/hash_utils_64.c 2009-11-27 10:40:40.000000000 +1100
+++ working-2.6/arch/powerpc/mm/hash_utils_64.c 2009-11-27 15:53:15.231721501 +1100
@@ -835,9 +835,9 @@ void demote_segment_4k(struct mm_struct
* Result is 0: full permissions, _PAGE_RW: read-only,
* _PAGE_USER or _PAGE_USER|_PAGE_RW: no access.
*/
-static int subpage_protection(pgd_t *pgdir, unsigned long ea)
+static int subpage_protection(struct mm_struct *mm, unsigned long ea)
{
- struct subpage_prot_table *spt = pgd_subpage_prot(pgdir);
+ struct subpage_prot_table *spt = &mm->context.spt;
u32 spp = 0;
u32 **sbpm, *sbpp;
@@ -865,7 +865,7 @@ static int subpage_protection(pgd_t *pgd
}
#else /* CONFIG_PPC_SUBPAGE_PROT */
-static inline int subpage_protection(pgd_t *pgdir, unsigned long ea)
+static inline int subpage_protection(struct mm_struct *mm, unsigned long ea)
{
return 0;
}
Index: working-2.6/arch/powerpc/mm/mmu_context_hash64.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/mmu_context_hash64.c 2009-11-27 10:40:40.000000000 +1100
+++ working-2.6/arch/powerpc/mm/mmu_context_hash64.c 2009-11-27 10:55:00.658768751 +1100
@@ -76,6 +76,7 @@ int init_new_context(struct task_struct
*/
if (slice_mm_new_context(mm))
slice_set_user_psize(mm, mmu_virtual_psize);
+ subpage_prot_init_new_context(mm);
mm->context.id = index;
return 0;
@@ -92,5 +93,6 @@ EXPORT_SYMBOL_GPL(__destroy_context);
void destroy_context(struct mm_struct *mm)
{
__destroy_context(mm->context.id);
+ subpage_prot_free(mm);
mm->context.id = NO_CONTEXT;
}
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 0/4] powerpc: Fix minor build issues on 2.6.32-rc7 without CONFIG_XICS set
From: Benjamin Herrenschmidt @ 2009-11-27 2:40 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20091118170510.GA1119@csn.ul.ie>
On Wed, 2009-11-18 at 17:05 +0000, Mel Gorman wrote:
>
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
> index 04a8061..a82c470 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -52,9 +52,9 @@ config PPC_UDBG_BEAT
> default n
>
> config XICS
> - depends on PPC_PSERIES
> + depends on PCI_MSI
> bool
> - default y
> + default n
Why the above ? XICS only exist on PSERIES and select bypass depends in
nasty ways anyways.
> config IPIC
> bool
> diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
> index f0e6f28..81c2289 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -5,6 +5,8 @@ config PPC_PSERIES
> select PPC_I8259
> select PPC_RTAS
> select RTAS_ERROR_LOGGING
> + select PCI_MSI
> + select XICS
> select PPC_UDBG_16550
> select PPC_NATIVE
> select PPC_PCI_CHOICE if EMBEDDED
The above bits look plenty enough. Can you also stick it next to the
MPIC one ?
Cheers,
Ben.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] powerpc/mm: honor O_SYNC flag for memory mapping
From: Paul Mackerras @ 2009-11-27 2:40 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1259222529-27645-1-git-send-email-leoli@freescale.com>
Li Yang writes:
> There was no way to set mapped memory as cacheable if the memory
> is not managed by Linux kernel. It's not rare in real system to
> allocate some dedicated memory to a certain application which is not
> managed by kernel and then mmap'ed the memory to the application.
> The memory should be cacheable but we can't map it to be cacheable
> due to the intelligent setting of cacheability.
>
> The patch makes the cacheability depend on O_SYNC flag of the file
> mapped for non-kernel managed memory. Also prints a deprecation
> warning for mmap users without using O_SYNC.
NAK, since it is an incompatible change to the kernel ABI.
What sort of memory is this that you want to map as cacheable? Is it
normal system RAM that your platform code reserves, or is it some
other kind of memory?
If it's the normal system RAM, you could make phys_mem_access_prot()
smart enough to recognize that (by looking in the lmb array or the
device tree).
If it's another kind of memory, it should be described in the device
tree, and you could have a platform-specific phys_mem_access_prot
function for your platform that looks in the device tree to see if the
memory being mapped is this special sort of memory.
Paul.
^ permalink raw reply
* Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
From: Paul Mackerras @ 2009-11-27 2:30 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, Li Yang-R58472
In-Reply-To: <2a27d3730911252343j6a938d99n7152b7cc8d01c0bf@mail.gmail.com>
Li Yang writes:
> That's my concern too. But after all mmap without O_SYNC on I/O
> devices should be deprecated.
It should? Why?
Shouldn't the onus rather be on those proposing an incompatible change
to the kernel ABI, such as this is, to show why the change is
absolutely essential?
> A warning message in deprecation period
> could reduce potential problem caused by this change.
Not making the change at all would reduce the potential problems even
further. :)
Paul.
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Benjamin Herrenschmidt @ 2009-11-27 0:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <4AE0F44D-CAD9-457C-9E5D-0279F28D70AF@kernel.crashing.org>
On Fri, 2009-11-27 at 01:16 +0100, Segher Boessenkool wrote:
>
> In all code I have done for the XFB, I map it like any other RAM and
> dcbst it after writing to it. Maybe that is slower though, WIMG=0100
> might be better. Dunno.
Well, it depends also what you want to do with it. If you want to expose
it as a standard linux fbdev, it might break apps to expect them to use
dcbst... but it will make rmw cycles a lot faster and avoid wasting
memory with shadowfb.
It's going to mostly depend on what kind of HW accel we can get out of
it, if we get good enough accel we can probably got for I=1 like a
standard fb
Ben.
^ permalink raw reply
* Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
From: Segher Boessenkool @ 2009-11-27 0:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259275130.2659.4.camel@pasglop>
>>>> If you have only one interrupt controller, like here, you don't
>>>> need to refer to it _at all_ :-)
>>>
>>> I think Linux requires that you do though. It might be a mistake on
>>> our
>>> part but heh ...
>>
>> Linux doesn't require it; (old) Macs are like this, for example,
>> and that works fine. Oh and all Maple firmwares are like that as
>> well I think. Etc.
>
> It works fine on old macs thanks to a quirk we enable in the mac code
> iirc and old maple works thanks to mere luck with the fallback code we
> have which reads things of PCI config space :-)
>
> Don't rely on that.
It is standard OF. Let's fix the Linux code if that is needed (and I
don't
think it is, anyway).
OTOH, it's nice to use the interrupt mapping stuff in all new device
trees.
Segher
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Segher Boessenkool @ 2009-11-27 0:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259275057.2659.3.camel@pasglop>
>> Yup. The idea is to map the first 16MB of MEM1 with a BAT.
>> Mapping the whole 24MB with BATs may not be possible because we
>> want the framebuffer
>> in MEM1 for performance reasons.
>
> How big is the fb ?
A bit more than a megabyte, something like that.
> We have plenty of BATs on these things... so one 16M
> for the low mem and one 64M for the "high" mem, that leaves something
> like 6 to manage as much as possible up to the fb :-)
The CXe in the gamecube has only four BATs though.
In all code I have done for the XFB, I map it like any other RAM and
dcbst it after writing to it. Maybe that is slower though, WIMG=0100
might be better. Dunno.
Segher
^ permalink raw reply
* Re: [RFC PATCH 12/19] powerpc: gamecube: platform support
From: Segher Boessenkool @ 2009-11-27 0:09 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B0EFC1D.5030806@yahoo.es>
>>> We need it as it currently doesn't match with the default bus ids.
>>
>>> Should I introduce a .type property matching any of those above
>>> in the
>>> soc node, and get rid of the explicit bus probe?
>>
>> You don't need any fake bus as far as I can see, just probe the
>> devices
>> you want.
>
> But it's way easier to let the bus probe do it for us. I don't see
> the win here.
As long as this doesn't leak into the device tree in any way, I don't
care. How's that? :-)
Segher
^ permalink raw reply
* Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
From: Segher Boessenkool @ 2009-11-27 0:06 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B0EFBB2.9090206@yahoo.es>
>>>> Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of
>>>> GAMECUBE_COMMON
>>>> is a good name?
>>>
>>> I'd prefer to not use a name that implies a specific hardware to
>>> describe two (mostly) similar but different hardwares.
>>
>> Hollywood is 100% compatible to Flipper though.
>
> No. There's no ARAM for example :)
ARAM is an external device.
>>>>> +/*
>>>>> + * Each interrupt has a corresponding bit in both
>>>>> + * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
>>>>> + *
>>>>> + * Enabling/disabling an interrupt line involves asserting/
>>>>> clearing
>>>>> + * the corresponding bit in IMR. ACK'ing a request simply
>>>>> involves
>>>>> + * asserting the corresponding bit in ICR.
>>>>> + */
>>
>> I looked it up in YAGCD; it says that _reading_ the ICR reg already
>> acks all interrupts (and clears the bits), you never write this reg!
>
> YAGCD is not always right. You should not take it as _the truth_.
Oh I know. But I have no better source of information. Well I could
actually test it, that's very easy using OF :-) Let's do that.
>>> No, it acks just a single IRQ.
>>
>> No it doesn't. Say IRQs 1 and 3 are asserted, so the reg contains
>> 0x0a.
>> Now you want to ack IRQ1; set_bit() will write 0x0a | 0x02, not
>> just 0x02.
>
> Let me rephrase it. No it should just ack a single IRQ :)
>
> So then this is working by accident.
> If that's the case, I guess it works because the interrupt is not
> cleared at the source and the ICR is set again immediately for any
> pending interrupt?
Probably, yes. Also, you will not often have more than one interrupt
pending anyway (on the legacy PIC).
Segher
^ permalink raw reply
* Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
From: Benjamin Herrenschmidt @ 2009-11-26 23:38 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <8DD300BC-A3F3-4569-9BFC-62366F59BDA0@kernel.crashing.org>
On Fri, 2009-11-27 at 00:00 +0100, Segher Boessenkool wrote:
> >>> +unsigned int flipper_pic_get_irq(void)
> >>> +{
> >>> + void __iomem *io_base = flipper_irq_host->host_data;
> >>> + int irq;
> >>> + u32 irq_status;
> >>> +
> >>> + irq_status = in_be32(io_base + FLIPPER_ICR) &
> >>> + in_be32(io_base + FLIPPER_IMR);
> >>> + if (irq_status == 0)
> >>> + return -1; /* no more IRQs pending */
> >>
> >> NO_IRQ_IGNORE
> >
> > Why no just 0 ? (aka NO_IRQ)
> >
> > Or do you know you are getting lots of spurrious that you don't
> > want to
> > account ?
>
> IRQ #0 is a valid IRQ here (graphics error IIRC), it should be
> remapped I suppose?
All interrupts are remapped. _get_irq() should call the appropriate
revmap function to remap the HW number into a linux number. 0 is never a
valid linux number and means "no interrupt".
In the above case, it would seem to me that what he gets is a bitfield
so 0 means no interrupt. Hence the code should be:
if (irq_status == 0)
return 0;
Then, find first bit and return the linear revmap... Just look at what
the old pmac_pic does, same stuff basically.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
From: David Miller @ 2009-11-26 23:32 UTC (permalink / raw)
To: segher
Cc: sfr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev
In-Reply-To: <F307E7FB-0819-47E8-9CF4-CA1433C18DA6@kernel.crashing.org>
From: Segher Boessenkool <segher@kernel.crashing.org>
Date: Thu, 26 Nov 2009 22:36:41 +0100
>>> You're right, it's not, but makes merging less complex, and then I can
>>> refactor properly.
>>
>> Still, make them __be32 at least
>
> There is no alignment guarantee at all either, better make it all u8
> and use accessor functions everywhere.
I think that might be overkill.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox