* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: Olof Johansson @ 2007-10-31 1:56 UTC (permalink / raw)
To: Valentine Barshak, linuxppc-dev
In-Reply-To: <20071030230805.GC2784@localhost.localdomain>
On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > PowerPC 440GRx Rainier DTS.
> [snip]
> > + SDRAM0: sdram {
> > + device_type = "memory-controller";
>
> How many times do we need to say it...
>
> Don't make up random device_type values. This does not belong here.
Maybe there should be something like checkpatch.pl that warns about
these kinds of things so people can check for it without getting flamed
first. :-)
Lots of people base their dts'es on other ones, so until the kernel has
bene clean a while, this will happen all the time. I'm saying "a while"
because people tend to base them on what's fresh when they do the work,
but it might take a few months between then and when they post, etc.
-Olof
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: Josh Boyer @ 2007-10-31 2:09 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071031015651.GB19318@lixom.net>
On Tue, 30 Oct 2007 20:56:51 -0500
Olof Johansson <olof@lixom.net> wrote:
> On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> > On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > > PowerPC 440GRx Rainier DTS.
> > [snip]
> > > + SDRAM0: sdram {
> > > + device_type = "memory-controller";
> >
> > How many times do we need to say it...
> >
> > Don't make up random device_type values. This does not belong here.
>
> Maybe there should be something like checkpatch.pl that warns about
> these kinds of things so people can check for it without getting flamed
> first. :-)
That's actually a decent idea. We could even have this thing that
takes DTS files and processes them... oh wait.
So why can't we make a whitelist of "allowed" device_types in DTC and
make it whine about anything outside of that?
josh
^ permalink raw reply
* Re: Merge dtc
From: David Gibson @ 2007-10-31 2:45 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: ppcdev, Paul Mackerras, Milton Miller
In-Reply-To: <20071019184249.GA32015@uranus.ravnborg.org>
On Fri, Oct 19, 2007 at 08:42:49PM +0200, Sam Ravnborg wrote:
> Hi David.
>
> > > Give me a day or two then I shall give it a try and see what I can
> > > do about it. I will use the previsous posted URL as basis if you do
> > > not tell me otherwise.
> >
> > Thank you. The previous URL should be fine, I've made no changes
> > since then.
>
> I decided to go for a kbuild specific version integrated
> in boot/Makefile.
> This is much more readable because this syntax is explicit.
> We do not favour 3 levels of variabls to avoid rewriting the same
> filename two times.
Well, yes, on consideration the substitutions in Makefile.dtc are a
bit over-involved. Although I still find describing its dozen or so
lines as unreadable when set next to the intricate wonders of Kbuild a
little... bemusing.
> I have tested the change only with a O=.. crosscompile build.
>
> I have tested the patch with and without DTC_GENPARSER=1.
> It does not rebuild if not needed and is OK with -j10 builds.
>
> Please consider this version in favour of your old version.
Ok. I'll use this version in my next spin; except for adding one
dependency you missed, and removing one which should never have been
there (unneccessary #include, which I've already fixed in dtc
upstream).
--
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] using mii-bitbang on different processor ports
From: Stephen Rothwell @ 2007-10-31 2:50 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev
In-Reply-To: <1193760559.6244.25.camel@p60635-ste.ids.de>
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
On Tue, 30 Oct 2007 17:09:19 +0100 Sergej Stepanov <Sergej.Stepanov@ids.de> wrote:
>
> static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
> struct device_node *np)
> {
> - struct resource res;
> + struct resource res[2];
Why not just reuse the same resource structure? You don't seem to need
them both at the same time.
> + if( !of_address_to_resource(np, 1, &res[1]))
> + {
> + bitbang->mdio.dir = ioremap(res[1].start, res[1].end - res[1].start + 1);
> + if (!bitbang->mdio.dir)
> + {
> + iounmap(bitbang->mdc.dir);
> + return -ENOMEM;
> + }
> + bitbang->mdio.dat = bitbang->mdio.dir + 4;
> + }
> + else{
Formatting:
if () {
} else {
}
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
No spaces after (, please. Here and elsewhere.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: David Gibson @ 2007-10-31 2:56 UTC (permalink / raw)
To: Josh Boyer; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <20071030210917.42cfb88b@vader.jdub.homelinux.org>
On Tue, Oct 30, 2007 at 09:09:17PM -0500, Josh Boyer wrote:
> On Tue, 30 Oct 2007 20:56:51 -0500
> Olof Johansson <olof@lixom.net> wrote:
>
> > On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> > > On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > > > PowerPC 440GRx Rainier DTS.
> > > [snip]
> > > > + SDRAM0: sdram {
> > > > + device_type = "memory-controller";
> > >
> > > How many times do we need to say it...
> > >
> > > Don't make up random device_type values. This does not belong here.
> >
> > Maybe there should be something like checkpatch.pl that warns about
> > these kinds of things so people can check for it without getting flamed
> > first. :-)
I'd be gentler; except that I know Valentine has been active on this
list recently, so has almost certainly seen similar comments before.
> That's actually a decent idea. We could even have this thing that
> takes DTS files and processes them... oh wait.
>
> So why can't we make a whitelist of "allowed" device_types in DTC and
> make it whine about anything outside of that?
Well, that sort of thing is the idea for dtc to check, when it has
checks enabled anyway. Getting it so that it doesn't have too many
false positives is the tricky bit, as we've seen with some of the
existing checks (where "too many" is "almost any").
Patches welcome...
--
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 3/4] PowerPC: 440GRx Rainier board support.
From: Stephen Rothwell @ 2007-10-31 3:11 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071030165739.GA22126@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
On Tue, 30 Oct 2007 19:57:39 +0300 Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> +++ linux-2.6/arch/powerpc/platforms/44x/rainier.c 2007-10-30 18:00:15.000000000 +0300
> +#include <linux/init.h>
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/time.h>
> +#include <asm/uic.h>
> +#include <asm/of_platform.h>
You want <linux/of_platform.h>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [0/2] Embed a copy of dtc in the kernel source
From: David Gibson @ 2007-10-31 3:24 UTC (permalink / raw)
To: linuxppc-dev
These two patches are a respin of my previous patch to merge a copy of
dtc into the kernel tree, so that kernel builds no longer depend on an
externally installed copy of dtc.
This respin embeds a newer revision of dtc, and incorporates Sam
Ravnborg's preferred approach to Makefile integration. Also, since so
many people whinged about it last time, I've split the patch into two
parts, the first is the too-large-for-the-list patch just verbatim
adding files and the second has the changes to existing kernel files
to build and use the embedded code.
--
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
* [1/2] Merge dtc
From: David Gibson @ 2007-10-31 3:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071031032401.GD7772@localhost.localdomain>
This very large patch incorporates a copy of dtc into the kernel
source, in arch/powerpc/boot/dtc-src. This patch only imports the dtc
sources verbatim, another patch coming to actually link it into the
kernel Makefiles and use the embedded copy of dtc for kernel builds.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Too big for this list. Full patch at:
http://ozlabs.org/~dgibson/home/merge-dtc.patch
--
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
* [2/2] Use embedded dtc in kernel builds
From: David Gibson @ 2007-10-31 3:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071031032401.GD7772@localhost.localdomain>
This patch alters the kernel makefiles to build dtc from the sources
embedded in the previous patch. It also changes the
arch/powerpc/boot/wrapper script to use the embedded dtc, rather than
expecting a copy of dtc already installed on the system.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/arch/powerpc/boot/Makefile
===================================================================
--- working-2.6.orig/arch/powerpc/boot/Makefile 2007-10-22 13:55:49.000000000 +1000
+++ working-2.6/arch/powerpc/boot/Makefile 2007-10-31 14:02:40.000000000 +1100
@@ -108,17 +108,52 @@ $(patsubst %.S,%.o, $(filter %.S, $(src-
$(obj)/wrapper.a: $(obj-wlib) FORCE
$(call if_changed,bootar)
-hostprogs-y := addnote addRamDisk hack-coff mktree
+hostprogs-y := addnote addRamDisk hack-coff mktree dtc
targets += $(patsubst $(obj)/%,%,$(obj-boot) wrapper.a)
extra-y := $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \
$(obj)/zImage.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds
wrapper :=$(srctree)/$(src)/wrapper
-wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \
+wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree dtc) \
$(wrapper) FORCE
#############
+# Bits for building dtc
+# DTC_GENPARSER := 1 # Uncomment to rebuild flex/bison output
+
+dtc-objs := dtc.o flattree.o fstree.o data.o livetree.o treesource.o srcpos.o
+dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o
+dtc-objs := $(addprefix dtc-src/, $(dtc-objs))
+
+# prerequisites on generated files needs to be explicit
+$(obj)/dtc-src/dtc-parser.tab.o: $(obj)/dtc-src/dtc-parser.tab.c $(obj)/dtc-src/dtc-parser.tab.h
+$(obj)/dtc-src/dtc-lexer.lex.o: $(obj)/dtc-src/dtc-lexer.lex.c $(obj)/dtc-src/dtc-parser.tab.h
+
+HOSTCFLAGS += -I$(src)/dtc-src/
+
+targets += dtc-src/dtc-parser.tab.c
+targets += dtc-src/dtc-lexer.lex.c
+
+ifdef DTC_GENPARSER
+BISON = bison
+FLEX = flex
+
+quiet_cmd_bison = BISON $@
+ cmd_bison = $(BISON) -o$@ -d $<; cp $@ $@_shipped
+quiet_cmd_flex = FLEX $@
+ cmd_flex = $(FLEX) -o$@ $<; cp $@ $@_shipped
+
+$(obj)/dtc-src/dtc-parser.tab.c: $(src)/dtc-src/dtc-parser.y FORCE
+ $(call if_changed,bison)
+
+$(obj)/dtc-src/dtc-parser.tab.h: $(obj)/dtc-src/dtc-parser.tab.c
+
+$(obj)/dtc-src/dtc-lexer.lex.c: $(src)/dtc-src/dtc-lexer.l FORCE
+ $(call if_changed,flex)
+endif
+
+#############
# Bits for building various flavours of zImage
ifneq ($(CROSS32_COMPILE),)
@@ -236,7 +271,7 @@ install: $(CONFIGURE) $(addprefix $(obj)
# anything not in $(targets)
clean-files += $(image-) $(initrd-) zImage zImage.initrd cuImage.* treeImage.* \
- otheros.bld
+ otheros.bld $(dtc-clean-files)
# clean up files cached by wrapper
clean-kernel := vmlinux.strip vmlinux.bin
Index: working-2.6/arch/powerpc/boot/wrapper
===================================================================
--- working-2.6.orig/arch/powerpc/boot/wrapper 2007-10-22 13:55:50.000000000 +1000
+++ working-2.6/arch/powerpc/boot/wrapper 2007-10-31 14:02:40.000000000 +1100
@@ -111,7 +111,7 @@ if [ -n "$dts" ]; then
if [ -z "$dtb" ]; then
dtb="$platform.dtb"
fi
- dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
+ $object/dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
fi
if [ -z "$kernel" ]; then
--
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: [0/2] Embed a copy of dtc in the kernel source
From: Kumar Gala @ 2007-10-31 4:37 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071031032401.GD7772@localhost.localdomain>
On Oct 30, 2007, at 10:24 PM, David Gibson wrote:
> These two patches are a respin of my previous patch to merge a copy of
> dtc into the kernel tree, so that kernel builds no longer depend on an
> externally installed copy of dtc.
>
> This respin embeds a newer revision of dtc, and incorporates Sam
> Ravnborg's preferred approach to Makefile integration. Also, since so
> many people whinged about it last time, I've split the patch into two
> parts, the first is the too-large-for-the-list patch just verbatim
> adding files and the second has the changes to existing kernel files
> to build and use the embedded code.
What about doing part of this via git-submodule?
- k
^ permalink raw reply
* Re: [0/2] Embed a copy of dtc in the kernel source
From: David Gibson @ 2007-10-31 4:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <DFBF9FAC-012A-47C6-9EC0-CDD365F67A97@kernel.crashing.org>
On Tue, Oct 30, 2007 at 11:37:15PM -0500, Kumar Gala wrote:
>
> On Oct 30, 2007, at 10:24 PM, David Gibson wrote:
>
> > These two patches are a respin of my previous patch to merge a copy of
> > dtc into the kernel tree, so that kernel builds no longer depend on an
> > externally installed copy of dtc.
> >
> > This respin embeds a newer revision of dtc, and incorporates Sam
> > Ravnborg's preferred approach to Makefile integration. Also, since so
> > many people whinged about it last time, I've split the patch into two
> > parts, the first is the too-large-for-the-list patch just verbatim
> > adding files and the second has the changes to existing kernel files
> > to build and use the embedded code.
>
> What about doing part of this via git-submodule?
Uh.. where do I find out what that does? My version of git (Ubuntu
gutsy) doesn't seem to know anything about it...
--
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
* ring on PowerPC
From: Bai Shuwei @ 2007-10-31 5:05 UTC (permalink / raw)
To: linuxppc-embedded, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
Hi, everyone
As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
3) and the linux kernel run in the ring 0 and user program in the ring 3.
And now I want to know wether there is a simple mechanism on the PowerPC
architecture? thx all!
best regards!
Buroc
--
Add: Tianshui South Road 222, Lanzhou, P.R.China
Tel: +86-931-8912025
Zip Code: 730000
URL: oss.lzu.edu.cn
Email: baishuwei@gmail.com, buroc@126.com
[-- Attachment #2: Type: text/html, Size: 675 bytes --]
^ permalink raw reply
* Re: ring on PowerPC
From: Grant Likely @ 2007-10-31 5:18 UTC (permalink / raw)
To: Bai Shuwei; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <f3566d60710302205g2dd867bbk8a3494ceeda569f0@mail.gmail.com>
On 10/30/07, Bai Shuwei <baishuwei@gmail.com> wrote:
> Hi, everyone
> As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
> 3) and the linux kernel run in the ring 0 and user program in the ring 3.
> And now I want to know wether there is a simple mechanism on the PowerPC
> architecture? thx all!
Powerpc has 2 privilege levels; user and supervisor. The kernel runs
in supervisor mode, and user-space runs in user mode.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
From: KAMEZAWA Hiroyuki @ 2007-10-31 5:28 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, anton, Paul Mackerras, linux-mm
In-Reply-To: <1193771951.8904.22.camel@dyn9047017100.beaverton.ibm.com>
On Tue, 30 Oct 2007 11:19:11 -0800
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> Hi KAME,
>
> As I mentioned while ago, ppc64 does not export information about
> "system RAM" in /proc/iomem. Looking at the code and usage
> scenerios I am not sure what its really serving. Could you
> explain what its purpose & how the range can be invalid ?
>
Hm, I added walk_memory_resource() for hot-add, at first.
Size of memory section is fixed and just depend on architecture, but
any machine can have any memory-hole within continuous memory-section-size
range of physical memory. Then we have to detect which page can be
target of online_page() and which are leaved as Reserved.
ioresource was good structure for remembering "which memory is conventional
memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
when I posted patch. (just say "System Ram" is not for memory hotplug.)
I used walk_memory_resource() again in memory hotremove.
(If I rememember correctly, walk_memory_resouce() helps x86_64 memory hot-add.
than our ia64 box.
In our ia64 box, we do node-hotadd. Section size is 1GiB and it has some
"for firmware" area in newly-added node.)
> At least on ppc64, all the memory ranges we get passed comes from
> /sysfs memblock information and they are guaranteed to match
> device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry
> and it will be part of the /proc/device-tree entry. Since we do
> "online" or "offline" to /sysfs entries to add/remove pages -
> these ranges are guaranteed to be valid.
>
ok.
> Since this check is redundant for ppc64, I propose following patch.
> Is this acceptable ? If some one really really wants, I can code
> up this to walk lmb or /proc/device-tree and verify the range &
> adjust the entries for overlap (I don't see how that can happen).
>
ok. If ppc64 guarantees "there is no memory hole in section", please try.
I have no objection.
I just would like to ask to add some text to explain
"ppc64 doesn't need to care memory hole in a section."
Thanks,
-Kame
^ permalink raw reply
* Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
From: KAMEZAWA Hiroyuki @ 2007-10-31 5:34 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-mm, Paul Mackerras, anton, Badari Pulavarty, linuxppc-dev
In-Reply-To: <20071031142846.aef9c545.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 31 Oct 2007 14:28:46 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> ioresource was good structure for remembering "which memory is conventional
> memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
> when I posted patch. (just say "System Ram" is not for memory hotplug.)
>
If I remember correctly, System RAM is for kdump (to know which memory should
be dumped.) Then, memory-hotadd/remove has to modify it anyway.
Thanks,
-Kame
^ permalink raw reply
* Re: ring on PowerPC
From: Benjamin Herrenschmidt @ 2007-10-31 5:36 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <fa686aa40710302218s3dfe4d42red589fc5692e4c1@mail.gmail.com>
On Tue, 2007-10-30 at 23:18 -0600, Grant Likely wrote:
> On 10/30/07, Bai Shuwei <baishuwei@gmail.com> wrote:
> > Hi, everyone
> > As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
> > 3) and the linux kernel run in the ring 0 and user program in the ring 3.
> > And now I want to know wether there is a simple mechanism on the PowerPC
> > architecture? thx all!
>
> Powerpc has 2 privilege levels; user and supervisor. The kernel runs
> in supervisor mode, and user-space runs in user mode.
To be complete here, some implementations have 3 :-) Don't forget
hypervisor mode !
Ben.
^ permalink raw reply
* [PATCH] powerpc: Deal with 44x virtually tagged icache
From: Benjamin Herrenschmidt @ 2007-10-31 5:42 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
The 44x family has an interesting "feature" which is a virtually
tagged instruction cache (yuck !). So far, we haven't dealt with
it properly, which means we've been mostly lucky or people didn't
report the problems, unless people have been running custom patches
in their distro...
This is an attempt at fixing it properly. I chose to do it by
setting a global flag whenever we change a PTE that was previously
marked executable, and flush the entire instruction cache upon
return to user space when that happens.
This is a bit heavy handed, but it's hard to do more fine grained
flushes as the icbi instruction, on those processor, for some very
strange reasons (since the cache is virtually mapped) still requires
a valid TLB entry for reading in the target address space, which
isn't something I want to deal with.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This version fixes the double iccci noticed by josh and does
arch/ppc (untested).
arch/powerpc/kernel/entry_32.S | 23 +++++++++++++++++++++++
arch/powerpc/kernel/misc_32.S | 9 +++++++++
arch/powerpc/mm/44x_mmu.c | 1 +
arch/ppc/kernel/entry.S | 23 +++++++++++++++++++++++
arch/ppc/kernel/misc.S | 9 +++++++++
arch/ppc/mm/44x_mmu.c | 1 +
include/asm-powerpc/pgtable-ppc32.h | 13 +++++++++++++
7 files changed, 79 insertions(+)
Index: linux-work/arch/powerpc/kernel/entry_32.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/entry_32.S 2007-10-15 11:19:35.000000000 +1000
+++ linux-work/arch/powerpc/kernel/entry_32.S 2007-10-31 10:40:45.000000000 +1100
@@ -244,6 +244,13 @@ syscall_exit_cont:
andis. r10,r0,DBCR0_IC@h
bnel- load_dbcr0
#endif
+#ifdef CONFIG_44x
+ lis r4,icache_44x_need_flush@ha
+ lwz r5,icache_44x_need_flush@l(r4)
+ cmplwi cr0,r5,0
+ bne- 2f
+1:
+#endif /* CONFIG_44x */
stwcx. r0,0,r1 /* to clear the reservation */
lwz r4,_LINK(r1)
lwz r5,_CCR(r1)
@@ -258,6 +265,12 @@ syscall_exit_cont:
mtspr SPRN_SRR1,r8
SYNC
RFI
+#ifdef CONFIG_44x
+2: li r7,0
+ iccci r0,r0
+ stw r7,icache_44x_need_flush@l(r4)
+ b 1b
+#endif /* CONFIG_44x */
66: li r3,-ENOSYS
b ret_from_syscall
@@ -683,6 +696,16 @@ resume_kernel:
/* interrupts are hard-disabled at this point */
restore:
+#ifdef CONFIG_44x
+ lis r4,icache_44x_need_flush@ha
+ lwz r5,icache_44x_need_flush@l(r4)
+ cmplwi cr0,r5,0
+ beq+ 1f
+ li r6,0
+ iccci r0,r0
+ stw r6,icache_44x_need_flush@l(r4)
+1:
+#endif /* CONFIG_44x */
lwz r0,GPR0(r1)
lwz r2,GPR2(r1)
REST_4GPRS(3, r1)
Index: linux-work/arch/powerpc/mm/44x_mmu.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/44x_mmu.c 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/powerpc/mm/44x_mmu.c 2007-10-30 15:30:50.000000000 +1100
@@ -35,6 +35,7 @@
*/
unsigned int tlb_44x_index; /* = 0 */
unsigned int tlb_44x_hwater = PPC44x_TLB_SIZE - 1 - PPC44x_EARLY_TLBS;
+int icache_44x_need_flush;
/*
* "Pins" a 256MB TLB entry in AS0 for kernel lowmem
Index: linux-work/include/asm-powerpc/pgtable-ppc32.h
===================================================================
--- linux-work.orig/include/asm-powerpc/pgtable-ppc32.h 2007-09-28 11:42:10.000000000 +1000
+++ linux-work/include/asm-powerpc/pgtable-ppc32.h 2007-10-30 15:30:50.000000000 +1100
@@ -11,6 +11,11 @@
extern unsigned long va_to_phys(unsigned long address);
extern pte_t *va_to_pte(unsigned long address);
extern unsigned long ioremap_bot, ioremap_base;
+
+#ifdef CONFIG_44x
+extern int icache_44x_need_flush;
+#endif
+
#endif /* __ASSEMBLY__ */
/*
@@ -562,6 +567,10 @@ static inline unsigned long pte_update(p
: "=&r" (old), "=&r" (tmp), "=m" (*p)
: "r" (p), "r" (clr), "r" (set), "m" (*p)
: "cc" );
+#ifdef CONFIG_44x
+ if ((old & _PAGE_USER) && (old & _PAGE_HWEXEC))
+ icache_44x_need_flush = 1;
+#endif
return old;
}
#else
@@ -582,6 +591,10 @@ static inline unsigned long long pte_upd
: "=&r" (old), "=&r" (tmp), "=m" (*p)
: "r" (p), "r" ((unsigned long)(p) + 4), "r" (clr), "r" (set), "m" (*p)
: "cc" );
+#ifdef CONFIG_44x
+ if ((old & _PAGE_USER) && (old & _PAGE_HWEXEC))
+ icache_44x_need_flush = 1;
+#endif
return old;
}
#endif
Index: linux-work/arch/powerpc/kernel/misc_32.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/misc_32.S 2007-10-30 15:15:03.000000000 +1100
+++ linux-work/arch/powerpc/kernel/misc_32.S 2007-10-30 15:30:50.000000000 +1100
@@ -543,12 +543,21 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_I
addi r3,r3,L1_CACHE_BYTES
bdnz 0b
sync
+#ifndef CONFIG_44x
+ /* We don't flush the icache on 44x. Those have a virtual icache
+ * and we don't have access to the virtual address here (it's
+ * not the page vaddr but where it's mapped in user space). The
+ * flushing of the icache on these is handled elsewhere, when
+ * a change in the address space occurs, before returning to
+ * user space
+ */
mtctr r4
1: icbi 0,r6
addi r6,r6,L1_CACHE_BYTES
bdnz 1b
sync
isync
+#endif /* CONFIG_44x */
blr
/*
Index: linux-work/arch/ppc/kernel/entry.S
===================================================================
--- linux-work.orig/arch/ppc/kernel/entry.S 2007-10-31 10:39:32.000000000 +1100
+++ linux-work/arch/ppc/kernel/entry.S 2007-10-31 10:40:46.000000000 +1100
@@ -244,6 +244,13 @@ syscall_exit_cont:
andis. r10,r0,DBCR0_IC@h
bnel- load_dbcr0
#endif
+#ifdef CONFIG_44x
+ lis r4,icache_44x_need_flush@ha
+ lwz r5,icache_44x_need_flush@l(r4)
+ cmplwi cr0,r5,0
+ bne- 2f
+1:
+#endif /* CONFIG_44x */
stwcx. r0,0,r1 /* to clear the reservation */
lwz r4,_LINK(r1)
lwz r5,_CCR(r1)
@@ -258,6 +265,12 @@ syscall_exit_cont:
mtspr SPRN_SRR1,r8
SYNC
RFI
+#ifdef CONFIG_44x
+2: li r7,0
+ iccci r0,r0
+ stw r7,icache_44x_need_flush@l(r4)
+ b 1b
+#endif /* CONFIG_44x */
66: li r3,-ENOSYS
b ret_from_syscall
@@ -679,6 +692,16 @@ resume_kernel:
/* interrupts are hard-disabled at this point */
restore:
+#ifdef CONFIG_44x
+ lis r4,icache_44x_need_flush@ha
+ lwz r5,icache_44x_need_flush@l(r4)
+ cmplwi cr0,r5,0
+ beq+ 1f
+ li r6,0
+ iccci r0,r0
+ stw r6,icache_44x_need_flush@l(r4)
+1:
+#endif /* CONFIG_44x */
lwz r0,GPR0(r1)
lwz r2,GPR2(r1)
REST_4GPRS(3, r1)
Index: linux-work/arch/ppc/kernel/misc.S
===================================================================
--- linux-work.orig/arch/ppc/kernel/misc.S 2007-10-31 10:41:21.000000000 +1100
+++ linux-work/arch/ppc/kernel/misc.S 2007-10-31 10:43:06.000000000 +1100
@@ -499,12 +499,21 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_I
addi r3,r3,L1_CACHE_BYTES
bdnz 0b
sync
+#ifndef CONFIG_44x
+ /* We don't flush the icache on 44x. Those have a virtual icache
+ * and we don't have access to the virtual address here (it's
+ * not the page vaddr but where it's mapped in user space). The
+ * flushing of the icache on these is handled elsewhere, when
+ * a change in the address space occurs, before returning to
+ * user space
+ */
mtctr r4
1: icbi 0,r6
addi r6,r6,L1_CACHE_BYTES
bdnz 1b
sync
isync
+#endif /* CONFIG_44x */
blr
/*
Index: linux-work/arch/ppc/mm/44x_mmu.c
===================================================================
--- linux-work.orig/arch/ppc/mm/44x_mmu.c 2007-10-31 10:39:04.000000000 +1100
+++ linux-work/arch/ppc/mm/44x_mmu.c 2007-10-31 10:39:15.000000000 +1100
@@ -61,6 +61,7 @@ extern char etext[], _stext[];
*/
unsigned int tlb_44x_index = 0;
unsigned int tlb_44x_hwater = 62;
+int icache_44x_need_flush;
/*
* "Pins" a 256MB TLB entry in AS0 for kernel lowmem
^ permalink raw reply
* Re: ring on PowerPC
From: Wang, Baojun @ 2007-10-31 6:12 UTC (permalink / raw)
To: linuxppc-embedded, Bai Shuwei
In-Reply-To: <393807697.25590@lzu.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
On Wednesday 31 October 2007 13:05:16, Bai Shuwei wrote：
> Hi, everyone
> As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
> 3) and the linux kernel run in the ring 0 and user program in the ring 3.
> And now I want to know wether there is a simple mechanism on the PowerPC
> architecture? thx all!
>
> best regards!
>
> Buroc
powerpc has a machine state register(MSR), bit MSR_PR present the current
privilege level, if msr & MSR_PR, then it's from user space, otherwise(msr &
MSR_PR == 0) it's kernel space.
besides, the linux implementation only use ring0 and ring3 under i386, ring0
is highest(kernel space), ring3 is lowest (userspace)
Wang
--
Wang, Baojun Lanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering wangbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 .P.R.China
Tel:+86-931-8912025 Fax:+86-931-8912022
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2/2] [POWERPC] Fix region size check in mpc5200 FEC driver
From: Grant Likely @ 2007-10-31 6:28 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
In-Reply-To: <20071031062842.7966.99739.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Driver shouldn't complain if the register range is larger than what
it expects. This works around failures with some device trees.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/fec_mpc52xx.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index fc1cf0b..a8a0ee2 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -879,9 +879,9 @@ mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
"Error while parsing device node resource\n" );
return rv;
}
- if ((mem.end - mem.start + 1) != sizeof(struct mpc52xx_fec)) {
+ if ((mem.end - mem.start + 1) < sizeof(struct mpc52xx_fec)) {
printk(KERN_ERR DRIVER_NAME
- " - invalid resource size (%lx != %x), check mpc52xx_devices.c\n",
+ " - invalid resource size (%lx < %x), check mpc52xx_devices.c\n",
(unsigned long)(mem.end - mem.start + 1), sizeof(struct mpc52xx_fec));
return -EINVAL;
}
^ permalink raw reply related
* [PATCH 1/2] [POWERPC] mpc5200: Fix Kconfig dependancies on MPC5200 FEC device driver
From: Grant Likely @ 2007-10-31 6:28 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
When not building an arch/powerpc kernel, the mpc5200 FEC driver depends
on some symbols which are not defined (BESTCOMM & BESTCOMM_FEC).
This patch flips around the dependancy logic so that it cannot be
selected unless BESTCOMM_FEC is selected first. Kconfig stops
complaining this way.
Also, the driver only works for arch/powerpc (not arch/ppc) anyway so
it should depend on PPC_MERGE also.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/Kconfig | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 867cb73..5f800a6 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1883,9 +1883,7 @@ config FEC2
config FEC_MPC52xx
tristate "MPC52xx FEC driver"
- depends on PPC_MPC52xx
- select PPC_BESTCOMM
- select PPC_BESTCOMM_FEC
+ depends on PPC_MERGE && PPC_MPC52xx && PPC_BESTCOMM_FEC
select CRC32
select PHYLIB
---help---
^ permalink raw reply related
* [PATCH] [POWERPC] ppc405 Fix arithmatic rollover bug when memory size under 16M
From: Grant Likely @ 2007-10-31 6:41 UTC (permalink / raw)
To: mh, jwboyer, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
mmu_mapin_ram() loops over total_lowmem to setup page tables. However, if
total_lowmem is less that 16M, the subtraction rolls over and results in
a number just under 4G (because total_lowmem is an unsigned value).
This patch rejigs the loop from countup to countdown to eliminate the
bug.
Special thanks to Magnus Hjorth who wrote the original patch to fix this
bug. This patch improves on his by making the loop code simpler (which
also eliminates the possibility of another rollover at the high end)
and also applies the change to arch/powerpc.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Josh, I've tested this change on arch/ppc, but not arch/powerpc. The
ppc and powerpc code are darn near identical so it should be correct,
but you might want to boot a kernel before you push it to Paulus
anyway.
Cheers,
g.
arch/powerpc/mm/40x_mmu.c | 17 ++++++++---------
arch/ppc/mm/4xx_mmu.c | 17 ++++++++---------
2 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/mm/40x_mmu.c b/arch/powerpc/mm/40x_mmu.c
index e067df8..3899ea9 100644
--- a/arch/powerpc/mm/40x_mmu.c
+++ b/arch/powerpc/mm/40x_mmu.c
@@ -98,13 +98,12 @@ unsigned long __init mmu_mapin_ram(void)
v = KERNELBASE;
p = PPC_MEMSTART;
- s = 0;
+ s = total_lowmem;
- if (__map_without_ltlbs) {
- return s;
- }
+ if (__map_without_ltlbs)
+ return 0;
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_16M)) {
+ while (s >= LARGE_PAGE_SIZE_16M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC | _PAGE_HWWRITE;
@@ -116,10 +115,10 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_16M;
p += LARGE_PAGE_SIZE_16M;
- s += LARGE_PAGE_SIZE_16M;
+ s -= LARGE_PAGE_SIZE_16M;
}
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_4M)) {
+ while (s >= LARGE_PAGE_SIZE_4M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC | _PAGE_HWWRITE;
@@ -128,8 +127,8 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_4M;
p += LARGE_PAGE_SIZE_4M;
- s += LARGE_PAGE_SIZE_4M;
+ s -= LARGE_PAGE_SIZE_4M;
}
- return s;
+ return total_lowmem - s;
}
diff --git a/arch/ppc/mm/4xx_mmu.c b/arch/ppc/mm/4xx_mmu.c
index 838e09d..ea785db 100644
--- a/arch/ppc/mm/4xx_mmu.c
+++ b/arch/ppc/mm/4xx_mmu.c
@@ -99,13 +99,12 @@ unsigned long __init mmu_mapin_ram(void)
v = KERNELBASE;
p = PPC_MEMSTART;
- s = 0;
+ s = total_lowmem;
- if (__map_without_ltlbs) {
- return s;
- }
+ if (__map_without_ltlbs)
+ return 0;
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_16M)) {
+ while (s >= LARGE_PAGE_SIZE_16M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC | _PAGE_HWWRITE;
@@ -117,10 +116,10 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_16M;
p += LARGE_PAGE_SIZE_16M;
- s += LARGE_PAGE_SIZE_16M;
+ s -= LARGE_PAGE_SIZE_16M;
}
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_4M)) {
+ while (s >= LARGE_PAGE_SIZE_4M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC | _PAGE_HWWRITE;
@@ -129,8 +128,8 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_4M;
p += LARGE_PAGE_SIZE_4M;
- s += LARGE_PAGE_SIZE_4M;
+ s -= LARGE_PAGE_SIZE_4M;
}
- return s;
+ return total_lowmem - s;
}
^ permalink raw reply related
* Re: ring on PowerPC
From: Bai Shuwei @ 2007-10-31 7:09 UTC (permalink / raw)
To: Wang, Baojun; +Cc: linuxppc-embedded
In-Reply-To: <393873503.24962@eyou.net>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
thanks all
On 10/31/07, Wang, Baojun <wangbj@lzu.edu.cn> wrote:
>
> On Wednesday 31 October 2007 13:05:16, Bai Shuwei wrote：
> > Hi, everyone
> > As we know, the program on the X86 can run on the differnt ring(0, 1,
> 2,
> > 3) and the linux kernel run in the ring 0 and user program in the ring
> 3.
> > And now I want to know wether there is a simple mechanism on the PowerPC
> > architecture? thx all!
> >
> > best regards!
> >
> > Buroc
>
> powerpc has a machine state register(MSR), bit MSR_PR present the current
> privilege level, if msr & MSR_PR, then it's from user space, otherwise(msr
> &
> MSR_PR == 0) it's kernel space.
>
> besides, the linux implementation only use ring0 and ring3 under i386,
> ring0
> is highest(kernel space), ring3 is lowest (userspace)
>
> Wang
> --
> Wang, Baojun Lanzhou University
> Distributed & Embedded System Lab http://dslab.lzu.edu.cn
> School of Information Science and Engeneering wangbj@lzu.edu.cn
> Tianshui South Road 222. Lanzhou 730000 .P.R.China
> Tel:+86-931-8912025 Fax:+86-931-8912022
>
>
--
Add: Tianshui South Road 222, Lanzhou, P.R.China
Tel: +86-931-8912025
Zip Code: 730000
URL: oss.lzu.edu.cn
Email: baishuwei@gmail.com, buroc@126.com
[-- Attachment #2: Type: text/html, Size: 1784 bytes --]
^ permalink raw reply
* Re: [PATCH v2] using mii-bitbang on different processor ports
From: Sergej Stepanov @ 2007-10-31 7:30 UTC (permalink / raw)
To: linuxppc-dev, netdev, jgarzik
In-Reply-To: <472776AE.2060009@freescale.com>
Am Dienstag, den 30.10.2007, 13:23 -0500 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > + if( !of_address_to_resource(np, 1, &res[1])) {
>=20
> The spacing is still wrong.
>=20
> > - iounmap(bitbang->dir);
> > + if ( bitbang->mdio.dir !=3D bitbang->mdc.dir)
> > + iounmap(bitbang->mdio.dir);
> > + iounmap(bitbang->mdc.dir);
>=20
> And here.
>=20
> -Scott
Oh, sorry.
--=20
Sergej I. Stepanov
E-PA
IDS GmbH
Nobelstr. 18, Zim. 2.1.05
D-76275 Ettlingen
T +49 (0) 72 43/2 18-615
F +49 (0) 72 43/2 18-400
Email: <Sergej.Stepanov@ids.de>
<http://www.ids.de>
Gesch=C3=A4ftsf=C3=BChrer: Norbert Wagner, Friedrich Abri=C3=9F=20
Sitz der Gesellschaft: Ettlingen=20
Amtsgericht Mannheim HRB 362503
^ permalink raw reply
* [PATCH v3] using mii-bitbang on different processor ports
From: Sergej Stepanov @ 2007-10-31 8:32 UTC (permalink / raw)
To: linuxppc-dev, netdev, jgarzik
The patch makes possible to have mdio and mdc pins on different physical ports
also for CONFIG_PPC_CPM_NEW_BINDING.
To setup it in the device tree:
reg = <10d40 14 10d60 14>; // mdc: 0x10d40, mdio: 0x10d60
or
reg = <10d40 14>; // mdc and mdio have the same offset 10d40
The approach was taken from older version.
Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
--
diff --git a/drivers/net/fs_enet/mii-bitbang.c b/drivers/net/fs_enet/mii-bitbang.c
index b8e4a73..83ce0c6 100644
--- a/drivers/net/fs_enet/mii-bitbang.c
+++ b/drivers/net/fs_enet/mii-bitbang.c
@@ -29,12 +29,16 @@
#include "fs_enet.h"
-struct bb_info {
- struct mdiobb_ctrl ctrl;
+struct bb_port {
__be32 __iomem *dir;
__be32 __iomem *dat;
- u32 mdio_msk;
- u32 mdc_msk;
+ u32 msk;
+};
+
+struct bb_info {
+ struct mdiobb_ctrl ctrl;
+ struct bb_port mdc;
+ struct bb_port mdio;
};
/* FIXME: If any other users of GPIO crop up, then these will have to
@@ -62,18 +66,18 @@ static inline void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (dir)
- bb_set(bitbang->dir, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dir, bitbang->mdio.msk);
else
- bb_clr(bitbang->dir, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dir, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dir);
+ in_be32(bitbang->mdio.dir);
}
static inline int mdio_read(struct mdiobb_ctrl *ctrl)
{
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
- return bb_read(bitbang->dat, bitbang->mdio_msk);
+ return bb_read(bitbang->mdio.dat, bitbang->mdio.msk);
}
static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
@@ -81,12 +85,12 @@ static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dat, bitbang->mdio.msk);
else
- bb_clr(bitbang->dat, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dat, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdio.dat);
}
static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
@@ -94,12 +98,12 @@ static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdc_msk);
+ bb_set(bitbang->mdc.dat, bitbang->mdc.msk);
else
- bb_clr(bitbang->dat, bitbang->mdc_msk);
+ bb_clr(bitbang->mdc.dat, bitbang->mdc.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdc.dat);
}
static struct mdiobb_ops bb_ops = {
@@ -142,15 +146,32 @@ static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
return -ENODEV;
mdc_pin = *data;
- bitbang->dir = ioremap(res.start, res.end - res.start + 1);
- if (!bitbang->dir)
+ bitbang->mdc.dir = ioremap(res.start, res.end - res.start + 1);
+ if (!bitbang->mdc.dir)
return -ENOMEM;
- bitbang->dat = bitbang->dir + 4;
- bitbang->mdio_msk = 1 << (31 - mdio_pin);
- bitbang->mdc_msk = 1 << (31 - mdc_pin);
+ bitbang->mdc.dat = bitbang->mdc.dir + 4;
+ if (!of_address_to_resource(np, 1, &res)) {
+ if (res.end - res.start < 13)
+ goto bad_resource;
+ bitbang->mdio.dir = ioremap(res.start, res.end - res.start + 1);
+ if (!bitbang->mdio.dir)
+ goto unmap_and_exit;
+ bitbang->mdio.dat = bitbang->mdio.dir + 4;
+ } else {
+ bitbang->mdio.dir = bitbang->mdc.dir;
+ bitbang->mdio.dat = bitbang->mdc.dat;
+ }
+ bitbang->mdio.msk = 1 << (31 - mdio_pin);
+ bitbang->mdc.msk = 1 << (31 - mdc_pin);
return 0;
+bad_resource:
+ iounmap(bitbang->mdc.dir);
+ return -ENODEV;
+unmap_and_exit:
+ iounmap(bitbang->mdc.dir);
+ return -ENOMEM;
}
static void __devinit add_phy(struct mii_bus *bus, struct device_node *np)
@@ -220,7 +241,9 @@ out_free_irqs:
dev_set_drvdata(&ofdev->dev, NULL);
kfree(new_bus->irq);
out_unmap_regs:
- iounmap(bitbang->dir);
+ if (bitbang->mdio.dir != bitbang->mdc.dir)
+ iounmap(bitbang->mdio.dir);
+ iounmap(bitbang->mdc.dir);
out_free_bus:
kfree(new_bus);
out_free_priv:
@@ -238,6 +261,8 @@ static int fs_enet_mdio_remove(struct of_device *ofdev)
free_mdio_bitbang(bus);
dev_set_drvdata(&ofdev->dev, NULL);
kfree(bus->irq);
- iounmap(bitbang->dir);
+ if (bitbang->mdio.dir != bitbang->mdc.dir)
+ iounmap(bitbang->mdio.dir);
+ iounmap(bitbang->mdc.dir);
kfree(bitbang);
kfree(bus);
^ permalink raw reply related
* Re: [POWERPC] Fix off-by-one error in setting decrementer on Book E
From: Paul Mackerras @ 2007-10-31 9:40 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <47260FE5.5080107@ru.mvista.com>
Sergei Shtylyov writes:
> + /*
> + * The "classic" decrementer interrupts at 0 to -1 transition, while
> + * 40x and book E decrementers interrupt at 1 to 0 transition.
Funky spacing . : )
If I take out the removed lines in the rest of your patch, I get:
> + */
> #if defined(CONFIG_40x)
> mtspr(SPRN_PIT, val);
> +#else
> +#if !defined(CONFIG_BOOKE)
> + val = val ? val - 1 : 0;
> +#endif
> +#if defined(CONFIG_8xx_CPU6)
> set_dec_cpu6(val);
> +#if defined(CONFIG_PPC_ISERIES)
I think you're missing a #else here.
Paul.
^ 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