* Re: [PATCH] keywest: Convert to new-style i2c driver
From: Jean Delvare @ 2009-04-23 9:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Takashi Iwai, linuxppc-dev, alsa-devel
In-Reply-To: <18927.5140.888171.141615@cargo.ozlabs.ibm.com>
Hi Paul,
On Wed, 22 Apr 2009 22:56:52 +1000, Paul Mackerras wrote:
> Jean Delvare writes:
> > We're past -rc3 because people discuss instead of testing my patches.
> > Otherwise everything would be merged already.
>
> Well, no. The first conversion patch that I saw was posted after the
> merge window had already closed, on 8 April.
I had the hope that the developers/maintainers involved would not
ignore the warnings and had patches ready, that would go to Linus
during the merge window. This didn't happen, call me naive if you want.
So right after rc1 I started working on the conversion myself.
> > And really, these changes (sound drivers) don't qualify as disruptive.
> > You might argue about the thermal management driver changes if you
> > want. But sound drivers, nothing bad will happen if they accidentally
> > break.
>
> That's what we call a "regression". :)
Regressions happen all the time, no matter how hard we all try to avoid
them. As long as they are fixed before -final, this isn't a big problem
though.
> > But linux-next will only build-test the code. That I have already done,
> > so it really doesn't buy my anything. Developers (including me) don't
> > look at warnings in linux-next, and I don't think linux-next gets a lot
> > of testing.
>
> If you remove the legacy interfaces then even a build test will point
> out the drivers that still need to be converted. :)
I don't consider breaking the linux-next build a good practice, sorry.
I suspect this tree doesn't get a lot of testing, breaking it isn't
going to improve the situation. Not to mention that this will make
Stephen's life harder, which isn't my goal. I do have a list of drivers
that aren't yet converted upstream, I don't need linux-next to tell me.
Except for new drivers, of course, there I agree your strategy has
value (but has a flaw, see below.)
> > Also, I can't push all untested patches to linux-next. In particular
> > the 4 patches that touch thermal management on powermac, need to be
> > tested successfully by at least one person before I can push them. You
> > did test the therm_pm72 patch, and I thank you for that, so that one is
> > in linux-next, but the other 3 ones need testing.
> >
> > So, really, you're trying to solve the wrong problem. Whether the
> > patches go to Linus now or in the next merge window, doesn't really
> > matter.
>
> It does matter, actually.
>
> > And 2.6.31 isn't the kernel to remove an interface which was scheduled
> > for removal in 2.6.29 and then 2.6.30 and which is blocking the
> > development of features people need badly.
>
> What's so special about 2.6.30 that it matters whether the legacy
> interfaces are still there or not?
3 months ago, people told me "what's so special about 2.6.29". The
result is that we made very little progress and the legacy interface
was still used by 10 (non-staging) drivers in 2.6.30-rc1. There's
nothing special about 2.6.30 other than the fact that I am fed up
waiting for all drivers to drop using a deprecated API so that I can
remove it. Again, further i2c developments are blocked by the existence
of this deprecated API.
> As for blocking development, you can remove the legacy interfaces
> today in your next branch and get on with development immediately.
No, I can't, that would break the linux-next build, as explained above.
I would also have to include all the driver conversion patches there.
The problem is that this still touches drivers/macintosh,
drivers/media/video and sound/ppc at the moment, each of which is
supposed to be maintained in a different tree. If I include these
patches in my i2c tree, chances of collisions with other trees are big,
which means more work for Stephen. If the patches are instead included
in their respective trees (as Takashi just did for sound/ppc), you
avoid the collisions, but then I can't remove the legacy API in
linux-next, because the i2c tree is listed relatively early, so
bisecting (or just incrementally building) linux-next would fail
horribly.
So, as you can see, the problem you think is so easily solved by
linux-next, isn't. The only thing I can do at this point is keep the
patches in a local tree and point other interested developers thereto.
Basically I'll tell them "you need to use linux-next plus a number of
public patches that can't go to linux-next plus the development patches
we are discussing." This makes the work and discussions about further
developments much more difficult, and results in zero testing outside
the development group, which makes it unclear if they will be ready for
2.6.31.
Compare this with the case where all driver conversions are already in
Linus' tree (even without removing the legacy interface): I can put the
legacy interface removal and all the development patches in linux-next
and interested people can test just this, and this is build tested on
several architectures, and possibly even runtime-tested by a few random
users. This is way less work for everyone and a much better quality in
the end.
> So
> the "blocking development" argument has zero relevance to what goes
> into Linus' tree for 2.6.30. Even if you got the legacy interfaces
> removed for 2.6.30 you still wouldn't be able to get any new features
> based on that into 2.6.30.
But I would be able to get the new features in 2.6.31. With your plan,
I doubt this can happen.
> And this is a particularly bad time to be hastily trying to get
> powermac driver changes upstream, since Ben H. is on vacation.
Yes, that I admit is pretty bad luck :(
> > So, once again, can powermac developers/users please test my patches?
>
> Can we compromise on this? I'll do everything I reasonably can to
> help you get the powermac driver patches tested and working before the
> 2.6.31 merge window, if you agree to leave the drivers and interfaces
> in Linus' tree as they are for 2.6.30.
"Before the 2.6.31 merge window" is way too late if I want any i2c
development to make it into 2.6.31 as well. The conversions must go in
linux-next as soon as possible. Even that isn't ideal as I explained
above, but that's the bare minimum to make sure everything (driver
conversions, interface removal and i2c developments) has a chance to be
ready for 2.6.31.
Note that I did get some more test results meanwhile. Johannes Berg
was able to test the windfarm drivers conversion, and Andreas Schwab
tested the therm_adt746x conversion, both successfully. So the only two
drivers which didn't get any testing at this point are keywest
(snd-powermac) and therm_windtunnel. That being said, more testing for
every driver is certainly welcome. You can check the current status at:
http://i2c.wiki.kernel.org/index.php/Legacy_drivers_to_be_converted
I agree to stop pushing driver conversions to Linus for 2.6.30, which
means the legacy API will stay there. Some drivers have already been
converted though (go7007 in rc3) and some conversions are scheduled to
go to Linus already (sound drivers in rc4, Takashi said.) This means 7
remaining unconverted drivers in 2.6.30 (6 powermac thermal management
drivers, and ir-kbd-i2c.)
--
Jean Delvare
^ permalink raw reply
* Re: linux-next: upstream tree build failure
From: Josh Boyer @ 2009-04-23 10:33 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Paul Mackerras, LKML, linuxppc-dev
In-Reply-To: <20090423160656.fac84e3f.sfr@canb.auug.org.au>
On Thu, Apr 23, 2009 at 04:06:56PM +1000, Stephen Rothwell wrote:
>Hi all,
>
>[I am now using gcc version 4.4.0 ...]
>
>Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
>
>arch/powerpc/mm/tlb_nohash_low.S:206:6: error: #elif with no expression
>
>Previous gcc versions didn't notice this because one of the preceding
>#ifs always evaluated to true. I have applied the following patch for today.
>
>--
>Cheers,
>Stephen Rothwell sfr@canb.auug.org.au
>http://www.canb.auug.org.au/~sfr/
>
>From: Stephen Rothwell <sfr@canb.auug.org.au>
>Date: Thu, 23 Apr 2009 16:00:47 +1000
>Subject: [PATCH] powerpc: fix for long standing bug noticed by gcc 4.4.0
>
>Previous gcc versions didn't notice this because one of the preceding
>
>gcc 4.4.0 produced this error:
>
>arch/powerpc/mm/tlb_nohash_low.S:206:6: error: #elif with no expression
>
>Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Your changelog got truncated in the first sentence. No big deal.
I have a gcc 4.4.0 system as well. I'll try a bunch of various builds to see
if it catches anything else. This fix looks good to me in the meantime.
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
josh
>---
> arch/powerpc/mm/tlb_nohash_low.S | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>diff --git a/arch/powerpc/mm/tlb_nohash_low.S b/arch/powerpc/mm/tlb_nohash_low.S
>index 45fed36..21e1b9a 100644
>--- a/arch/powerpc/mm/tlb_nohash_low.S
>+++ b/arch/powerpc/mm/tlb_nohash_low.S
>@@ -203,6 +203,6 @@ ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_USE_TLBILX)
> isync
> 1: wrtee r10
> blr
>-#elif
>+#else
> #error Unsupported processor type !
> #endif
^ permalink raw reply
* Re: [PATCH] powerpc/cell: Select PCI for IBM_CELL_BLADE AND CELLEB
From: Arnd Bergmann @ 2009-04-23 11:07 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Geert.Uytterhoeven, linuxppc-dev, randy.dunlap, subrata
In-Reply-To: <cf386cee8d45e3aac21cfc8af3dc17c5335c516b.1240476177.git.michael@ellerman.id.au>
On Thursday 23 April 2009, Michael Ellerman wrote:
> Currently PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but does not
> select PCI. This can lead to a config with the former and the latter
> disabled, which does not build.
>
> To fix this PPC_CELL_NATIVE should select PCI. However, that would
> force PCI on for QPACE, which also selects PPC_CELL_NATIVE. So
> instead move the select of PPC_OF_PLATFORM_PCI and PCI under both
> IBM_CELL_BLADE and CELLEB.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Yes, this one looks right, thanks for following up on this.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH] powerpc/86xx: clean up smp init code
From: Martyn Welch @ 2009-04-23 12:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1240421691-10193-1-git-send-email-galak@kernel.crashing.org>
Kumar Gala wrote:
> Removed the need for asm/mpc86xx.h as it was only used in mpc86xx_smp.c
> and just moved the defines it cared about into there. Also fixed up
> the ioremap to only map the one 4k page we need access to and to iounmap
> when we are done.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/include/asm/mpc86xx.h | 33 ----------------------------
> arch/powerpc/platforms/86xx/gef_ppc9a.c | 1 -
> arch/powerpc/platforms/86xx/gef_sbc310.c | 1 -
> arch/powerpc/platforms/86xx/gef_sbc610.c | 1 -
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1 -
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1 -
> arch/powerpc/platforms/86xx/mpc86xx_smp.c | 8 ++++++-
> arch/powerpc/platforms/86xx/sbc8641d.c | 1 -
> 8 files changed, 7 insertions(+), 40 deletions(-)
> delete mode 100644 arch/powerpc/include/asm/mpc86xx.h
>
>
I assume this patch relies on one of the other patches posted?
Just applying this patch to my development tree (based on your main
branch) resulted in the following on a PPC9A:
mpic: requesting IPIs ...
__ioremap(): phys addr 0x0 is RAM lr c041e5c8
Unable to handle kernel paging request for data at address 0x00000010
Faulting instruction address: 0xc041e5cc
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP NR_CPUS=2 GE Fanuc PPC9A
Modules linked in:
NIP: c041e5cc LR: c041e5c8 CTR: c0013d90
REGS: ef841ea0 TRAP: 0300 Not tainted (2.6.30-rc3-00016-gabae74f)
MSR: 00001032 <ME,IR,DR> CR: 24000022 XER: 00000000
DAR: 00000010, DSISR: 40000000
TASK = ef83f980[1] 'swapper' THREAD: ef840000 CPU: 0
GPR00: c041e5c8 ef841f50 ef83f980 00000000 00001032 ffffffff c0480000
00004000
GPR08: c0441a4c 00000000 ef840000 c0440000 22000042 ffffdfff 0ff50d00
00000001
GPR16: ffffffff 00000000 c0440000 c0480000 c0480000 c0468000 c0440000
c0442838
GPR24: 00000002 c0480000 c0480000 7d5043a6 00009032 00000004 00000001
0000c350
NIP [c041e5cc] smp_86xx_kick_cpu+0x70/0x11c
LR [c041e5c8] smp_86xx_kick_cpu+0x6c/0x11c
Call Trace:
[ef841f50] [c041e5c8] smp_86xx_kick_cpu+0x6c/0x11c (unreliable)
[ef841f70] [c0435010] __cpu_up+0xa4/0x1b0
[ef841f90] [c04355ec] cpu_up+0x104/0x1cc
[ef841fd0] [c0412368] kernel_init+0x1d8/0x1f0
[ef841ff0] [c0012cb8] kernel_thread+0x4c/0x68
Instruction dump:
3c80c000 61290100 38a00001 7d234b78 38843464 83690000 4bbfa7f9 4bbfcb21
38801000 38631000 4bbf91ad 7c0004ac <81230010> 0c090000 4c00012c 38000001
---[ end trace 31fd0ba7d8756001 ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..
Martyn
^ permalink raw reply
* [PATCH v2] powerpc: fix for long standing bug noticed by gcc 4.4.0
From: Stephen Rothwell @ 2009-04-23 12:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev, linux-next, LKML
In-Reply-To: <20090423103336.GA3825@zod.rchland.ibm.com>
Previous gcc versions didn't notice this because one of the preceding
#ifs always evaluated to true.
gcc 4.4.0 produced this error:
arch/powerpc/mm/tlb_nohash_low.S:206:6: error: #elif with no expression
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/mm/tlb_nohash_low.S | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
v2: fixed up commit message, added Josh'd Ack.
diff --git a/arch/powerpc/mm/tlb_nohash_low.S b/arch/powerpc/mm/tlb_nohash_low.S
index 45fed36..21e1b9a 100644
--- a/arch/powerpc/mm/tlb_nohash_low.S
+++ b/arch/powerpc/mm/tlb_nohash_low.S
@@ -203,6 +203,6 @@ ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_USE_TLBILX)
isync
1: wrtee r10
blr
-#elif
+#else
#error Unsupported processor type !
#endif
--
1.6.2.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: removing get_immrbase()??
From: Timur Tabi @ 2009-04-23 13:02 UTC (permalink / raw)
To: Kumar Gala, Scott Wood, Linuxppc-dev Development
In-Reply-To: <20090423022610.GA19376@yookeroo.seuss>
David Gibson wrote:
> It's not so much point of view as situation. Putting the device tree
> in the firmware and putting the device tree in the kernel are both
> valid choices, with their own distinct advantages and drawbacks.
I was under the impression that the reason we put the device trees in
the kernel is because we didn't have a better place to put them.
Keeping them in the kernel repository was just convenient.
So I personally don't consider the *location* of the DTS files to be a
basis for deciding what they really mean.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: removing get_immrbase()??
From: Timur Tabi @ 2009-04-23 13:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, Linuxppc-dev Development, David Gibson
In-Reply-To: <80CA86D4-3DA5-4C28-AE7A-C03CE5758774@kernel.crashing.org>
Kumar Gala wrote:
> Until we meet the most basic level of properly describing 95% of the
> HW I don't see the value you guys prescribe to FW compatibility.
> Additionally I believe for embedded developers its perfectly
> reasonable to expect them (if they are using u-boot) to possibly have
> to update their .dts/dtb if they want to update their kernel.
That sounds like you want to throw out the baby with the bathwater.
Just because we can't get close to 100% representation of the hardware
in the DTS, that does not mean that the representation we do have should
be considered tenuous (for lack of a better word).
We should *strive* to maintain backwards compatibility. If that means
adding a few lines of isolated code every now and then, I don't see that
as a bad thing at all.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] PPC440EPx SDRAM width
From: Steven A. Falco @ 2009-04-23 13:36 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
There is an error in the way ibm4xx_denali_fixup_memsize calculates
memory size. When testing the DDR_REDUC bit, the polarity is
backwards. A "1" implies 32-bit wide memory while a "0" implies
64-bit wide memory.
For a 32-bit wide system, this bug causes twice the memory to be
reported, leading to boot failure.
Signed-off-by: Steven A. Falco <sfalco@harris.com>
---
Here is a partial log showing what happens in the
ibm4xx_denali_fixup_memsize routine. This board has
128 Mbytes of RAM in a 32-bit wide configuration, but
the REDUC bug causes the path width to report as "8",
and the memory size to be doubled to 255 MB. Once I
applied my patch, the memory correctly reported as
127 MB.
max_cs=00000002 max_col=0000000c max_row=0000000e
cs 00000001
path width 00000008
row=0000000d col=0000000a bank=00000004
ibm4xx_denali_fixup_memsize 10000000
Memory <- <0x0 0x0 0xffff000> (255MB)
diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
index 5c87843..3595c0a 100644
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -193,9 +193,9 @@ void ibm4xx_denali_fixup_memsize(void)
val = SDRAM0_READ(DDR0_14);
if (DDR_GET_VAL(val, DDR_REDUC, DDR_REDUC_SHIFT))
- dpath = 8; /* 64 bits */
- else
dpath = 4; /* 32 bits */
+ else
+ dpath = 8; /* 64 bits */
/* get address pins (rows) */
val = SDRAM0_READ(DDR0_42);
^ permalink raw reply related
* Re: [PATCH] PPC440EPx SDRAM width
From: Josh Boyer @ 2009-04-23 13:45 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev@ozlabs.org, sr
In-Reply-To: <49F06ECC.7030904@harris.com>
On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>There is an error in the way ibm4xx_denali_fixup_memsize calculates
>memory size. When testing the DDR_REDUC bit, the polarity is
>backwards. A "1" implies 32-bit wide memory while a "0" implies
>64-bit wide memory.
>
>For a 32-bit wide system, this bug causes twice the memory to be
>reported, leading to boot failure.
>
>Signed-off-by: Steven A. Falco <sfalco@harris.com>
So we had a previous patch for this, and a very long discussion on what the
right solution was. Either we never came to a resolution, or I have just
forgotten what it was.
Stefan, Valentine, do either of you remember? IIRC, it wasn't something that
effected Sequoia or Rainier, but it could (and obviously does) effect custom
boards. I don't remember what we agreed on for the proper fix.
josh
^ permalink raw reply
* Re: removing get_immrbase()??
From: Anton Vorontsov @ 2009-04-23 13:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <49F066DC.402@freescale.com>
On Thu, Apr 23, 2009 at 08:02:20AM -0500, Timur Tabi wrote:
> David Gibson wrote:
>
> > It's not so much point of view as situation. Putting the device tree
> > in the firmware and putting the device tree in the kernel are both
> > valid choices, with their own distinct advantages and drawbacks.
>
> I was under the impression that the reason we put the device trees in
> the kernel is because we didn't have a better place to put them.
> Keeping them in the kernel repository was just convenient.
>
> So I personally don't consider the *location* of the DTS files to be a
> basis for deciding what they really mean.
I'm not sure why are we trying to make things harder for ourselves?
x86 has a long history fighting with bogus bioses/dmi/acpi tables,
up to the point where they completely ignore any information that
BIOS provides, because that information is unreliable or hard to
deal with.
With FDT (i.e. not hard-coded OF), we have a great opportunity to
keep both device tree and Linux code legacyjunk-free.
All we have to do is to declare one simple thing: don't put
device-tree into the read-only memory. Upgrading device tree blob
in the rewritable NOR/NAND flashes is safe in overwhelming cases,
just as safe as upgrading kernel image in the NOR/NAND.
And for those who didn't listen our pleases, i.e. for those
who put device-tree blob into some kind of ROM or dangerous-
to-upgrade memory or region of memory, we can always provide
boot wrappers, and thus isolate the legacy stuff. I mean isolate
it in their small legacy world, if anyone actually cares about
these cases.
As for Freescale parts, all the reference board I've seen were
very friendly wrt upgrading their device-trees, i.e. none of
the boards were shipping with device-tree soldered into the
firmware.
And note that most developers are using up-to-date firmwares
(U-Boots), device trees, and kernels. And that means that old
device-tree + new kernel combination is left untested for years.
And untested stuff is broken stuff, by definition.
Sure, there is a completely different story wrt device-tree
changes that might break firmwares. And that I believe we'd
better avoid. For example device_type = "soc", if removed,
most firmwares would not fix-up {clock,bus}-frequency properties.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] Revert "powerpc: Add support for early tlbilx opcode"
From: Kumar Gala @ 2009-04-23 13:53 UTC (permalink / raw)
To: linuxppc-dev
This reverts commit e9965577406a2148ade97b5e0ce7c448b4ba4ef6. Our HW
guys were able to fix this so it never sees the light of day.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/mmu.h | 6 ------
arch/powerpc/include/asm/ppc-opcode.h | 11 +----------
arch/powerpc/kernel/cputable.c | 2 +-
arch/powerpc/mm/tlb_nohash_low.S | 14 +-------------
4 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 86d2366..cbf1543 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -52,12 +52,6 @@
*/
#define MMU_FTR_NEED_DTLB_SW_LRU ASM_CONST(0x00200000)
-/* This indicates that the processor uses the wrong opcode for tlbilx
- * instructions. During the ISA 2.06 development the opcode for tlbilx
- * changed and some early implementations used to old opcode
- */
-#define MMU_FTR_TLBILX_EARLY_OPCODE ASM_CONST(0x00400000)
-
#ifndef __ASSEMBLY__
#include <asm/cputable.h>
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index ef4da37..640ccbb 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -44,7 +44,6 @@
#define PPC_INST_STSWI 0x7c0005aa
#define PPC_INST_STSWX 0x7c00052a
#define PPC_INST_TLBILX 0x7c000024
-#define PPC_INST_TLBILX_EARLY 0x7c000626
#define PPC_INST_WAIT 0x7c00007c
/* macros to insert fields into opcodes */
@@ -64,18 +63,10 @@
#define PPC_RFDI stringify_in_c(.long PPC_INST_RFDI)
#define PPC_RFMCI stringify_in_c(.long PPC_INST_RFMCI)
#define PPC_TLBILX(t, a, b) stringify_in_c(.long PPC_INST_TLBILX | \
- __PPC_T_TLB(t) | \
- __PPC_RA(a) | __PPC_RB(b))
+ __PPC_T_TLB(t) | __PPC_RA(a) | __PPC_RB(b))
#define PPC_TLBILX_ALL(a, b) PPC_TLBILX(0, a, b)
#define PPC_TLBILX_PID(a, b) PPC_TLBILX(1, a, b)
#define PPC_TLBILX_VA(a, b) PPC_TLBILX(3, a, b)
-
-#define PPC_TLBILX_EARLY(t, a, b) stringify_in_c(.long PPC_INST_TLBILX_EARLY | \
- __PPC_T_TLB(t) | \
- __PPC_RA(a) | __PPC_RB(b))
-#define PPC_TLBILX_ALL_EARLY(a, b) PPC_TLBILX_EARLY(0, a, b)
-#define PPC_TLBILX_PID_EARLY(a, b) PPC_TLBILX_EARLY(1, a, b)
-#define PPC_TLBILX_VA_EARLY(a, b) PPC_TLBILX_EARLY(3, a, b)
#define PPC_WAIT(w) stringify_in_c(.long PPC_INST_WAIT | \
__PPC_WC(w))
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 57db50f..cd1b687 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1766,7 +1766,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_features = CPU_FTRS_E500MC,
.cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
.mmu_features = MMU_FTR_TYPE_FSL_E | MMU_FTR_BIG_PHYS |
- MMU_FTR_USE_TLBILX | MMU_FTR_TLBILX_EARLY_OPCODE,
+ MMU_FTR_USE_TLBILX,
.icache_bsize = 64,
.dcache_bsize = 64,
.num_pmcs = 4,
diff --git a/arch/powerpc/mm/tlb_nohash_low.S b/arch/powerpc/mm/tlb_nohash_low.S
index 45fed36..788b87c 100644
--- a/arch/powerpc/mm/tlb_nohash_low.S
+++ b/arch/powerpc/mm/tlb_nohash_low.S
@@ -138,11 +138,7 @@ BEGIN_MMU_FTR_SECTION
andi. r3,r3,MMUCSR0_TLBFI@l
bne 1b
MMU_FTR_SECTION_ELSE
- BEGIN_MMU_FTR_SECTION_NESTED(96)
- PPC_TLBILX_ALL(0,r3)
- MMU_FTR_SECTION_ELSE_NESTED(96)
- PPC_TLBILX_ALL_EARLY(0,r3)
- ALT_MMU_FTR_SECTION_END_NESTED_IFCLR(MMU_FTR_TLBILX_EARLY_OPCODE, 96)
+ PPC_TLBILX_ALL(0,0)
ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_USE_TLBILX)
msync
isync
@@ -155,11 +151,7 @@ BEGIN_MMU_FTR_SECTION
wrteei 0
mfspr r4,SPRN_MAS6 /* save MAS6 */
mtspr SPRN_MAS6,r3
- BEGIN_MMU_FTR_SECTION_NESTED(96)
PPC_TLBILX_PID(0,0)
- MMU_FTR_SECTION_ELSE_NESTED(96)
- PPC_TLBILX_PID_EARLY(0,0)
- ALT_MMU_FTR_SECTION_END_NESTED_IFCLR(MMU_FTR_TLBILX_EARLY_OPCODE, 96)
mtspr SPRN_MAS6,r4 /* restore MAS6 */
wrtee r10
MMU_FTR_SECTION_ELSE
@@ -193,11 +185,7 @@ BEGIN_MMU_FTR_SECTION
mtspr SPRN_MAS1,r4
tlbwe
MMU_FTR_SECTION_ELSE
- BEGIN_MMU_FTR_SECTION_NESTED(96)
PPC_TLBILX_VA(0,r3)
- MMU_FTR_SECTION_ELSE_NESTED(96)
- PPC_TLBILX_VA_EARLY(0,r3)
- ALT_MMU_FTR_SECTION_END_NESTED_IFCLR(MMU_FTR_TLBILX_EARLY_OPCODE, 96)
ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_USE_TLBILX)
msync
isync
--
1.6.0.6
^ permalink raw reply related
* Re: removing get_immrbase()??
From: Grant Likely @ 2009-04-23 13:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, Linuxppc-dev Development, Timur Tabi
In-Reply-To: <282847E1-AE1A-44EF-9D18-AF2884105FA5@kernel.crashing.org>
On Wed, Apr 22, 2009 at 3:31 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
>
> On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote:
>
>> Scott Wood wrote:
>>>
>>> Timur Tabi wrote:
>>>>>
>>>>> =A0 =A0 =A0these two are related and seem like we could look for "fsl=
,cpm2"
>>>>
>>>> That's okay, as long as you don't break compatibility with older
>>>> device trees that don't have that property, unless you can demonstrate
>>>> that these trees would never work with the current kernel anyway.
>>>
>>> All CPM2 device trees should have fsl,cpm2 listed in the compatible of
>>> the CPM node.
>>
>> Yes, but did they always have that compatible field? =A0I'm concerned
>> about situations where someone updates his kernel but not his device
>> tree. =A0This is a scenerio that we always need to try to support.
>
> I disagree. =A0If you update your kernel you should update your device tr=
ee
> (thus we have .dts in the kernel tree and not somewhere else).
Not always possible. The device tree may be 'softer' than firmware,
and easier to update, but it is still firmer than the kernel. That is
why so much effort has been spent to not break compatibility with
older device trees.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: removing get_immrbase()??
From: Arnd Bergmann @ 2009-04-23 13:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
In-Reply-To: <A6732FD8-FBC6-420F-9318-CC111D266993@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]
On Wednesday 22 April 2009, Kumar Gala wrote:
First of all, thanks for bringing this up, I'd love to see get_immrbase() gone.
> arch/powerpc/sysdev/cpm1.c: mpc8xx_immr = ioremap(get_immrbase(),
> 0x4000);
> not sure? ideas?
Nobody has commented on this, so I've taken a brief look at it.
I'd suggest moving the logic up one step at a time. im_cpm, im_siu_conf and
im_ioport could be defined locally in sysdev/cpm1.c rather than through
mpc8xx_immr, all you need for this is to export accessor functions from cpm1 for
iop_pcso and cp_cptr:
void cpm1_set_iop_pcso(u16 pcso)
{
setbits16(cpm1_ioport.iop_pcso, pcso);
}
void cpm1_clear_iop_pcso(u16 pcso)
{
clearbits16(cpm1_ioport.iop_pcso, pcso);
}
...
im_sit, im_sitk, im_clkrst and im_clkrstk should be defined locally in m8xx_setup.c,
which is the only place that they are used in. Fortunately, the are all contiguous
in the address sapce, so they can be moved into one new data structure with
a single static pointer to it in m8xx_setup.c:
static struct {
struct sys_int_timers sit;
struct clk_and_reset clkrst;
struct sitk sitk;
struct cark clkrstk;
} *m8xx_setup_regs;
When this is done, 8xx_immap.h along with all the unused stuff therein can be removed.
In the last step, the device trees can be cleaned up so that you can of_iomap
the regions in those two files directly.
Arnd <><
[-- Attachment #2: Type: text/html, Size: 8243 bytes --]
^ permalink raw reply
* Re: removing get_immrbase()??
From: Grant Likely @ 2009-04-23 13:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, Linuxppc-dev Development, Timur Tabi
In-Reply-To: <DC91BA72-AF10-41DD-B610-EDEFD106A811@kernel.crashing.org>
On Wed, Apr 22, 2009 at 3:39 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
>
> On Apr 22, 2009, at 4:33 PM, Timur Tabi wrote:
>
>> Kumar Gala wrote:
>>
>>> I disagree. =A0If you update your kernel you should update your device
>>> tree (thus we have .dts in the kernel tree and not somewhere else).
>>
>> Is this a new policy? =A0I was under the impression that supporting olde=
r
>> device trees, if not too inconvenient, is desirable. =A0I've nack'd
>> patches before that broke backwards compatibility unnecessarily.
>
> The specific issue I'm talking about is the addition of new nodes that mi=
ght
> break old device trees. =A0I have no desire to try and say that I can't a=
dd
> new nodes and code related to them just because old device tree's didn't
> have them.
Ah... yes, you're right. Never mind my previous reply.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] powerpc: fix for long standing bug noticed by gcc 4.4.0
From: Kumar Gala @ 2009-04-23 13:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: LKML, linuxppc-dev, linux-next, Paul Mackerras
In-Reply-To: <20090423225611.d569764c.sfr@canb.auug.org.au>
On Apr 23, 2009, at 7:56 AM, Stephen Rothwell wrote:
> Previous gcc versions didn't notice this because one of the preceding
> #ifs always evaluated to true.
>
> gcc 4.4.0 produced this error:
>
> arch/powerpc/mm/tlb_nohash_low.S:206:6: error: #elif with no
> expression
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/tlb_nohash_low.S | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> v2: fixed up commit message, added Josh'd Ack.
applied to merge. Picking this up as I'm touching tlb_nohash_low.S w/
another "fix".
- k
^ permalink raw reply
* Please pull from 'merge' branch for 2.6.30
From: Kumar Gala @ 2009-04-23 13:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
to receive the following updates:
arch/powerpc/include/asm/mmu.h | 6 ------
arch/powerpc/include/asm/ppc-opcode.h | 11 +----------
arch/powerpc/kernel/cputable.c | 2 +-
arch/powerpc/mm/tlb_nohash_low.S | 16 ++--------------
4 files changed, 4 insertions(+), 31 deletions(-)
Kumar Gala (1):
Revert "powerpc: Add support for early tlbilx opcode"
Stephen Rothwell (1):
powerpc: fix for long standing bug noticed by gcc 4.4.0
^ permalink raw reply
* Re: removing get_immrbase()??
From: Timur Tabi @ 2009-04-23 14:02 UTC (permalink / raw)
To: avorontsov; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <20090423135005.GA18462@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> And note that most developers are using up-to-date firmwares
> (U-Boots), device trees, and kernels.
Developers? Yes.
End-users? No.
Updating U-Boot itself is often unacceptable for end-users. There's
also a strong connection between U-Boot and the device tree. That
connection gets stronger with every release, as U-Boot makes more and
more changes to the device tree before passing it to the kernel. This
means that if you cannot update U-Boot, you might not be able to update
your device tree either.
We've run into plenty of situations where customers will update the
kernel, but insist that U-Boot and the device tree remain unchanged.
> And that means that old
> device-tree + new kernel combination is left untested for years.
> And untested stuff is broken stuff, by definition.
I'm not saying that should officially support it. I'm saying we should
make an effort to minimize the problem. Adding a few isolated lines of
code to maintain that compatibility, and running a few tests, is not a
bad idea and can save headaches for some people in the future.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: removing get_immrbase()??
From: Anton Vorontsov @ 2009-04-23 14:03 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, Linuxppc-dev Development, Timur Tabi
In-Reply-To: <fa686aa40904230653j6855f8bai5248b250eb3ef515@mail.gmail.com>
On Thu, Apr 23, 2009 at 07:53:11AM -0600, Grant Likely wrote:
> On Wed, Apr 22, 2009 at 3:31 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> > On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote:
> >
> >> Scott Wood wrote:
> >>>
> >>> Timur Tabi wrote:
> >>>>>
> >>>>> these two are related and seem like we could look for "fsl,cpm2"
> >>>>
> >>>> That's okay, as long as you don't break compatibility with older
> >>>> device trees that don't have that property, unless you can demonstrate
> >>>> that these trees would never work with the current kernel anyway.
> >>>
> >>> All CPM2 device trees should have fsl,cpm2 listed in the compatible of
> >>> the CPM node.
> >>
> >> Yes, but did they always have that compatible field? I'm concerned
> >> about situations where someone updates his kernel but not his device
> >> tree. This is a scenerio that we always need to try to support.
> >
> > I disagree. If you update your kernel you should update your device tree
> > (thus we have .dts in the kernel tree and not somewhere else).
>
> Not always possible. The device tree may be 'softer' than firmware,
> and easier to update, but it is still firmer than the kernel. That is
> why so much effort has been spent to not break compatibility with
> older device trees.
I'd suggest to deal with this on case-by-case basis. In every MPC8xx
and MPC8xxx boards I've seen from Freescale there is absolutely no
difference in upgrading kernel or device-tree blob.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] PPC440EPx SDRAM width
From: Stefan Roese @ 2009-04-23 14:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090423134538.GB3825@zod.rchland.ibm.com>
On Thursday 23 April 2009, Josh Boyer wrote:
> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
> >There is an error in the way ibm4xx_denali_fixup_memsize calculates
> >memory size. When testing the DDR_REDUC bit, the polarity is
> >backwards. A "1" implies 32-bit wide memory while a "0" implies
> >64-bit wide memory.
> >
> >For a 32-bit wide system, this bug causes twice the memory to be
> >reported, leading to boot failure.
> >
> >Signed-off-by: Steven A. Falco <sfalco@harris.com>
>
> So we had a previous patch for this, and a very long discussion on what the
> right solution was. Either we never came to a resolution, or I have just
> forgotten what it was.
>
> Stefan, Valentine, do either of you remember?
Not really, sorry. Must be longer than 2 weeks ago, so it's already flushed
from my cache. :)
> IIRC, it wasn't something
> that effected Sequoia or Rainier, but it could (and obviously does) effect
> custom boards. I don't remember what we agreed on for the proper fix.
It would effect all 32-bit wide 440EPx/GRx boards using the boot wrapper. I
never used the wrapper on those platforms though. Sorry, I don't remember the
outcome of the discussion either.
Thanks,
Stefan
^ permalink raw reply
* Re: removing get_immrbase()??
From: Kumar Gala @ 2009-04-23 14:06 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <49F07509.8030603@freescale.com>
On Apr 23, 2009, at 9:02 AM, Timur Tabi wrote:
> We've run into plenty of situations where customers will update the
> kernel, but insist that U-Boot and the device tree remain unchanged.
when? I'm not aware of any significant # of cases that customer is
willing to update kernel & not dts. Usually if they are willing to
update kernel they tend to be willing to update everything.
- k
^ permalink raw reply
* Re: removing get_immrbase()??
From: Timur Tabi @ 2009-04-23 14:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <76E4F93E-F75F-4CDC-A281-F4703275BEC1@kernel.crashing.org>
Kumar Gala wrote:
> when? I'm not aware of any significant # of cases that customer is
> willing to update kernel & not dts. Usually if they are willing to
> update kernel they tend to be willing to update everything.
Well, now that you ask, I can't give you specifics, because I don't
remember.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: removing get_immrbase()??
From: Anton Vorontsov @ 2009-04-23 14:13 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <49F07509.8030603@freescale.com>
On Thu, Apr 23, 2009 at 09:02:49AM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> > And note that most developers are using up-to-date firmwares
> > (U-Boots), device trees, and kernels.
>
> Developers? Yes.
> End-users? No.
If end-users upgraded the kernel on some FSL board, then there
should be no technical problem upgrading device tree too.
> Updating U-Boot itself is often unacceptable for end-users. There's
> also a strong connection between U-Boot and the device tree. That
> connection gets stronger with every release, as U-Boot makes more and
> more changes to the device tree before passing it to the kernel. This
> means that if you cannot update U-Boot, you might not be able to update
> your device tree either.
As I said, this case is a separate matter. Just as device_type = "soc",
yes we should avoid removing it. But if we 100% sure that our device
tree changes won't break compatibility with officially supported
firmware, then IMO we should just go ahead with the changes.
> We've run into plenty of situations where customers will update the
> kernel, but insist that U-Boot
That I can understand.
> and the device tree remain unchanged.
That I can't. I wonder what was the rationale behind this.
> > And that means that old
> > device-tree + new kernel combination is left untested for years.
> > And untested stuff is broken stuff, by definition.
>
> I'm not saying that should officially support it. I'm saying we should
> make an effort to minimize the problem.
That doesn't work in practice. I bet if I'll try booting recent Linux
with FSL-provided device-tree on, say, MPC8323E-RDB it simply won't
boot.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Gary Thomas @ 2009-04-23 14:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B869D8DC-2A3B-4B53-8BFD-15D403CE20D4@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2847 bytes --]
Kumar Gala wrote:
>
> On Apr 21, 2009, at 6:45 PM, Gary Thomas wrote:
>
>> Kumar Gala wrote:
>>>
>>> On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>>>
>>>>
>>>> I found the difference - in 2.6.28 the inbound/outbound windows
>>>> don't seem to be set up at all. In 2.6.26, the function
>>>> 'fsl_add_bridge'
>>>> was common among architectures and ended up calling 'setup_pci_atmu'
>>>> which created those mappings. In 2.6.28, the 83xx PCI setup code
>>>> has been refactored. It uses 'mpc83xx_add_bridge' instead of
>>>> 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
>>>>
>>>> I'm sure this is the problem.
>>>
>>> Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code
>>> calling setup_pci_atmu().
>>
>> It did not directly; it called 'fsl_add_bridge' which in turn called
>> 'setup_pci_atmu'
>
> Don't ever see 83xx boards calling fsl_add_bridge -- that is 85xx/86xx
> only in 83xx.
Sorry, you're correct. I got lost looking through the code :-(
No matter, none of that code seems to be relevant to the change
in behaviour.
>> I modified the 2.6.28 driver to also call this function. Now the
>> inbound/outbound windows are set up, but the bridge still has
>> no allocations, so the problem remains.
>>
>> I need to move on; I may just live with sliding the PCI space
>> up for now (doesn't really hurt anything, just seems like a hack)
>
> It is and you are glossing over a real bug.
I have found the culprit - in arch/powerpc/kernel/pci_32.c
static void
fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev->class >> 8;
#if 0
if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
class == PCI_CLASS_BRIDGE_OTHER) &&
#else
if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
#endif
(dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
(dev->bus->parent == NULL)) {
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
dev->resource[i].start = 0;
dev->resource[i].end = 0;
dev->resource[i].flags = 0;
}
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID, fixup_hide_host_resource_fsl);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, fixup_hide_host_resource_fsl);
This function is now (the #if 0 case is in 2.6.28) tossing out
the memory resources used by the PCI bridge itself. This makes
everything fall over, at least on my 834x platform.
This change was applied 2008-10-08, but it seems incorrect on the 834x.
> Are you using u-boot to boot? If so is the board port public?
My systems use RedBoot (I'm the original author of RedBoot, so one would
expect that). At this moment, the code isn't public, sorry.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 4387 bytes --]
From: John Rigby <jrigby@freescale.com>
To: linuxppc-dev@ozlabs.org
Cc: John Rigby <jrigby@freescale.com>
Subject: [PATCH 3/3] powerpc: pci: 5121: Hide pci bridge.
Date: Tue, 7 Oct 2008 13:00:20 -0600
Message-ID: <1223406020-12278-4-git-send-email-jrigby@freescale.com>
The class of the MPC5121 pci host bridge is PCI_CLASS_BRIDGE_OTHER
while other freescale host bridges have class set to
PCI_CLASS_PROCESSOR_POWERPC.
This patch makes fixup_hide_host_resource_fsl match
PCI_CLASS_BRIDGE_OTHER in addition to PCI_CLASS_PROCESSOR_POWERPC.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/powerpc/kernel/pci_32.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 174b77e..a848c63 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -54,11 +54,12 @@ LIST_HEAD(hose_list);
static int pci_bus_count;
static void
-fixup_hide_host_resource_fsl(struct pci_dev* dev)
+fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev->class >> 8;
- if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
+ if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
+ class == PCI_CLASS_BRIDGE_OTHER) &&
(dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
(dev->bus->parent == NULL)) {
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
--
1.5.6.2.255.gbed62
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply related
* Re: [PATCH] 83xx: add support for the kmeter1 board.
From: Kumar Gala @ 2009-04-23 14:25 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <49F00605.1080605@denx.de>
>
> diff --git a/arch/powerpc/boot/dts/kmeter1.dts b/arch/powerpc/boot/
> dts/kmeter1.dts
> new file mode 100644
> index 0000000..4f343ca
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/kmeter1.dts
> @@ -0,0 +1,518 @@
> +/*
> + * Keymile KMETER1 Device Tree Source
> + *
> + * 2008 DENX Software Engineering GmbH
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +
> +/*
> +/memreserve/ 00000000 1000000;
> +*/
is this needed for something?
>
> +
> +/dts-v1/;
> +
> +/ {
> + model = "KMETER1";
> + compatible = "keymile,KMETER1";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + aliases {
> + ethernet0 = &enet_piggy2;
> + ethernet1 = &enet_estar1;
> + ethernet2 = &enet_estar2;
> + ethernet3 = &enet_eth1;
> + ethernet4 = &enet_eth2;
> + ethernet5 = &enet_eth3;
> + ethernet6 = &enet_eth4;
> + serial0 = &serial0;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,8360@0 {
> + device_type = "cpu";
> + reg = <0x0>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <32768>; // L1, 32K
> + i-cache-size = <32768>; // L1, 32K
> + timebase-frequency = <66000000>;
> + bus-frequency = <264000000>;
> + clock-frequency = <528000000>;
is the board running at a fixed frequency that isn't possible to change?
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x10000000>;
> + };
does u-boot not set this? Also is the amount of memory fixed?
> +
> + soc8360@e0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + compatible = "simple-bus";
> + ranges = <0x0 0xe0000000 0x00100000>;
> + reg = <0xe0000000 0x00000200>;
> + bus-frequency = <264000000>;
> +
> + i2c@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <0>;
> + compatible = "fsl-i2c";
> + reg = <0x3000 0x100>;
> + interrupts = <14 0x8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + };
> +
> + serial0: serial@4500 {
> + cell-index = <0>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x4500 0x100>;
> + clock-frequency = <264000000>;
> + interrupts = <9 0x8>;
> + interrupt-parent = <&ipic>;
> + };
> +
> + dma@82a8 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8360-dma", "fsl,elo-dma";
> + reg = <0x82a8 4>;
> + ranges = <0 0x8100 0x1a8>;
> + interrupt-parent = <&ipic>;
> + interrupts = <71 8>;
> + cell-index = <0>;
> + dma-channel@0 {
> + compatible = "fsl,mpc8360-dma-channel", "fsl,elo-dma-channel";
> + reg = <0 0x80>;
> + interrupt-parent = <&ipic>;
> + interrupts = <71 8>;
> + };
> + dma-channel@80 {
> + compatible = "fsl,mpc8360-dma-channel", "fsl,elo-dma-channel";
> + reg = <0x80 0x80>;
> + interrupt-parent = <&ipic>;
> + interrupts = <71 8>;
> + };
> + dma-channel@100 {
> + compatible = "fsl,mpc8360-dma-channel", "fsl,elo-dma-channel";
> + reg = <0x100 0x80>;
> + interrupt-parent = <&ipic>;
> + interrupts = <71 8>;
> + };
> + dma-channel@180 {
> + compatible = "fsl,mpc8360-dma-channel", "fsl,elo-dma-channel";
> + reg = <0x180 0x28>;
> + interrupt-parent = <&ipic>;
> + interrupts = <71 8>;
> + };
> + };
> +
> + ipic: pic@700 {
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + compatible = "fsl,pq2pro-pic", "fsl,ipic";
> + interrupt-controller;
> + reg = <0x700 0x100>;
> + device_type = "ipic";
> + };
> +
> + par_io@1400 {
> + reg = <0x1400 0x100>;
> + device_type = "par_io";
> + num-ports = <7>;
> +
> + pio_ucc1: ucc_pin@00 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 0 1 3 0 2 0 /* MDIO */
> + 0 2 1 0 1 0 /* MDC */
> +
> + 0 3 1 0 1 0 /* TxD0 */
> + 0 4 1 0 1 0 /* TxD1 */
> + 0 5 1 0 1 0 /* TxD2 */
> + 0 6 1 0 1 0 /* TxD3 */
> + 0 9 2 0 1 0 /* RxD0 */
> + 0 10 2 0 1 0 /* RxD1 */
> + 0 11 2 0 1 0 /* RxD2 */
> + 0 12 2 0 1 0 /* RxD3 */
> + 0 7 1 0 1 0 /* TX_EN */
> + 0 8 1 0 1 0 /* TX_ER */
> + 0 15 2 0 1 0 /* RX_DV */
> + 0 16 2 0 1 0 /* RX_ER */
> + 0 0 2 0 1 0 /* RX_CLK */
> + 2 9 1 0 3 0 /* GTX_CLK - CLK10 */
> + 2 8 2 0 1 0 /* GTX125 - CLK9 */
> + >;
> + };
> +
> + pio_ucc2: ucc_pin@01 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 0 1 3 0 2 0 /* MDIO */
> + 0 2 1 0 1 0 /* MDC */
> +
> + 0 17 1 0 1 0 /* TxD0 */
> + 0 18 1 0 1 0 /* TxD1 */
> + 0 19 1 0 1 0 /* TxD2 */
> + 0 20 1 0 1 0 /* TxD3 */
> + 0 23 2 0 1 0 /* RxD0 */
> + 0 24 2 0 1 0 /* RxD1 */
> + 0 25 2 0 1 0 /* RxD2 */
> + 0 26 2 0 1 0 /* RxD3 */
> + 0 21 1 0 1 0 /* TX_EN */
> + 0 22 1 0 1 0 /* TX_ER */
> + 0 29 2 0 1 0 /* RX_DV */
> + 0 30 2 0 1 0 /* RX_ER */
> + 0 31 2 0 1 0 /* RX_CLK */
> + 2 2 1 0 2 0 /* GTX_CLK - CLK3 */
> + 2 3 2 0 1 0 /* GTX125 - CLK4 */
> + >;
> + };
> +
> + pio_ucc4: ucc_pin@03 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 0 1 3 0 2 0 /* MDIO */
> + 0 2 1 0 1 0 /* MDC */
> +
> + 1 14 1 0 1 0 /* TxD0 (PB14, out, f1) */
> + 1 15 1 0 1 0 /* TxD1 (PB15, out, f1) */
> + 1 20 2 0 1 0 /* RxD0 (PB20, in, f1) */
> + 1 21 2 0 1 0 /* RxD1 (PB21, in, f1) */
> + 1 18 1 0 1 0 /* TX_EN (PB18, out, f1) */
> + 1 26 2 0 1 0 /* RX_DV (PB26, in, f1) */
> + 1 27 2 0 1 0 /* RX_ER (PB27, in, f1) */
> +
> + 2 16 2 0 1 0 /* UCC4_RMII_CLK (CLK17) */
> + >;
> + };
> +
> + pio_ucc5: ucc_pin@04 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 0 1 3 0 2 0 /* MDIO */
> + 0 2 1 0 1 0 /* MDC */
> +
> + 3 0 1 0 1 0 /* TxD0 (PD0, out, f1) */
> + 3 1 1 0 1 0 /* TxD1 (PD1, out, f1) */
> + 3 6 2 0 1 0 /* RxD0 (PD6, in, f1) */
> + 3 7 2 0 1 0 /* RxD1 (PD7, in, f1) */
> + 3 4 1 0 1 0 /* TX_EN (PD4, out, f1) */
> + 3 12 2 0 1 0 /* RX_DV (PD12, in, f1) */
> + 3 13 2 0 1 0 /* RX_ER (PD13, in, f1) */
> + >;
> + };
> +
> + pio_ucc6: ucc_pin@05 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 0 1 3 0 2 0 /* MDIO */
> + 0 2 1 0 1 0 /* MDC */
> +
> + 3 14 1 0 1 0 /* TxD0 (PD14, out, f1) */
> + 3 15 1 0 1 0 /* TxD1 (PD15, out, f1) */
> + 3 20 2 0 1 0 /* RxD0 (PD20, in, f1) */
> + 3 21 2 0 1 0 /* RxD1 (PD21, in, f1) */
> + 3 18 1 0 1 0 /* TX_EN (PD18, out, f1) */
> + 3 26 2 0 1 0 /* RX_DV (PD26, in, f1) */
> + 3 27 2 0 1 0 /* RX_ER (PD27, in, f1) */
> + >;
> + };
> +
> + pio_ucc7: ucc_pin@06 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 0 1 3 0 2 0 /* MDIO */
> + 0 2 1 0 1 0 /* MDC */
> +
> + 4 0 1 0 1 0 /* TxD0 (PE0, out, f1) */
> + 4 1 1 0 1 0 /* TxD1 (PE1, out, f1) */
> + 4 6 2 0 1 0 /* RxD0 (PE6, in, f1) */
> + 4 7 2 0 1 0 /* RxD1 (PE7, in, f1) */
> + 4 4 1 0 1 0 /* TX_EN (PE4, out, f1) */
> + 4 12 2 0 1 0 /* RX_DV (PE12, in, f1) */
> + 4 13 2 0 1 0 /* RX_ER (PE13, in, f1) */
> + >;
> + };
> +
> + pio_ucc8: ucc_pin@07 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 0 1 3 0 2 0 /* MDIO */
> + 0 2 1 0 1 0 /* MDC */
> +
> + 4 14 1 0 2 0 /* TxD0 (PE14, out, f2) */
> + 4 15 1 0 1 0 /* TxD1 (PE15, out, f1) */
> + 4 20 2 0 1 0 /* RxD0 (PE20, in, f1) */
> + 4 21 2 0 1 0 /* RxD1 (PE21, in, f1) */
> + 4 18 1 0 1 0 /* TX_EN (PE18, out, f1) */
> + 4 26 2 0 1 0 /* RX_DV (PE26, in, f1) */
> + 4 27 2 0 1 0 /* RX_ER (PE27, in, f1) */
> +
> + 2 15 2 0 1 0 /* UCCx_RMII_CLK (CLK16) */
> + >;
> + };
> +
> + };
> + };
> +
> + qe@e0100000 {
why isn't this under the SOC?
>
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "qe";
> + compatible = "fsl,qe";
> + ranges = <0x0 0xe0100000 0x00100000>;
> + reg = <0xe0100000 0x480>;
> + brg-frequency = <0>;
> + bus-frequency = <396000000>;
> +
> + muram@10000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,qe-muram", "fsl,cpm-muram";
> + ranges = <0x0 0x00010000 0x0000c000>;
> +
> + data-only@0 {
> + compatible = "fsl,qe-muram-data",
> + "fsl,cpm-muram-data";
> + reg = <0x0 0xc000>;
> + };
> + };
> +
> + /* ESTAR-1 (UCC1, MDIO 0x10, RGMII) */
> + enet_estar1: ucc@2000 {
> + device_type = "network";
> + compatible = "ucc_geth";
> + cell-index = <1>;
> + reg = <0x2000 0x200>;
> + interrupts = <32>;
> + interrupt-parent = <&qeic>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + rx-clock-name = "none";
> + tx-clock-name = "clk9";
> + phy-handle = <&phy_estar1>;
> + phy-connection-type = "rgmii-id";
> + pio-handle = <&pio_ucc1>;
> + };
> +
> + /* ESTAR-2 (UCC2, MDIO 0x11, RGMII) */
> + enet_estar2: ucc@3000 {
> + device_type = "network";
> + compatible = "ucc_geth";
> + cell-index = <2>;
> + reg = <0x3000 0x200>;
> + interrupts = <33>;
> + interrupt-parent = <&qeic>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + rx-clock-name = "none";
> + tx-clock-name = "clk4";
> + phy-handle = <&phy_estar2>;
> + phy-connection-type = "rgmii-id";
> + pio-handle = <&pio_ucc2>;
> + };
> +
> + /* Piggy2 (UCC4, MDIO 0x00, RMII) */
> + enet_piggy2: ucc@3200 {
> + device_type = "network";
> + compatible = "ucc_geth";
> + cell-index = <4>;
> + reg = <0x3200 0x200>;
> + interrupts = <35>;
> + interrupt-parent = <&qeic>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + rx-clock-name = "none";
> + tx-clock-name = "clk17";
> + phy-handle = <&phy_piggy2>;
> + phy-connection-type = "rmii";
> + pio-handle = <&pio_ucc4>;
> + };
> +
> + /* Eth-1 (UCC5, MDIO 0x08, RMII) */
> + enet_eth1: ucc@2400 {
> + device_type = "network";
> + compatible = "ucc_geth";
> + cell-index = <5>;
> + reg = <0x2400 0x200>;
> + interrupts = <40>;
> + interrupt-parent = <&qeic>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + rx-clock-name = "none";
> + tx-clock-name = "clk16";
> + phy-handle = <&phy_eth1>;
> + phy-connection-type = "rmii";
> + pio-handle = <&pio_ucc5>;
> + };
> +
> + /* Eth-2 (UCC6, MDIO 0x09, RMII) */
> + enet_eth2: ucc@3400 {
> + device_type = "network";
> + compatible = "ucc_geth";
> + cell-index = <6>;
> + reg = <0x3400 0x200>;
> + interrupts = <41>;
> + interrupt-parent = <&qeic>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + rx-clock-name = "none";
> + tx-clock-name = "clk16";
> + phy-handle = <&phy_eth2>;
> + phy-connection-type = "rmii";
> + pio-handle = <&pio_ucc6>;
> + };
> +
> + /* Eth-3 (UCC7, MDIO 0x0a, RMII) */
> + enet_eth3: ucc@2600 {
> + device_type = "network";
> + compatible = "ucc_geth";
> + cell-index = <7>;
> + reg = <0x2600 0x200>;
> + interrupts = <42>;
> + interrupt-parent = <&qeic>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + rx-clock-name = "none";
> + tx-clock-name = "clk16";
> + phy-handle = <&phy_eth3>;
> + phy-connection-type = "rmii";
> + pio-handle = <&pio_ucc7>;
> + };
> +
> + /* Eth-4 (UCC8, MDIO 0x0b, RMII) */
> + enet_eth4: ucc@3600 {
> + device_type = "network";
> + compatible = "ucc_geth";
> + cell-index = <8>;
> + reg = <0x3600 0x200>;
> + interrupts = <43>;
> + interrupt-parent = <&qeic>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + rx-clock-name = "none";
> + tx-clock-name = "clk16";
> + phy-handle = <&phy_eth4>;
> + phy-connection-type = "rmii";
> + pio-handle = <&pio_ucc8>;
> + };
> +
> + mdio@3320 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x3320 0x18>;
> + compatible = "fsl,ucc-mdio";
> +
> + /* Piggy2 (UCC4, MDIO 0x00, RMII) */
> + phy_piggy2: ethernet-phy@00 {
> + reg = <0x0>;
> + device_type = "ethernet-phy";
> + };
> +
> + /* Eth-1 (UCC5, MDIO 0x08, RMII) */
> + phy_eth1: ethernet-phy@08 {
> + reg = <0x08>;
> + device_type = "ethernet-phy";
> + };
> +
> + /* Eth-2 (UCC6, MDIO 0x09, RMII) */
> + phy_eth2: ethernet-phy@09 {
> + reg = <0x09>;
> + device_type = "ethernet-phy";
> + };
> +
> + /* Eth-3 (UCC7, MDIO 0x0a, RMII) */
> + phy_eth3: ethernet-phy@0a {
> + reg = <0x0a>;
> + device_type = "ethernet-phy";
> + };
> +
> + /* Eth-4 (UCC8, MDIO 0x0b, RMII) */
> + phy_eth4: ethernet-phy@0b {
> + reg = <0x0b>;
> + device_type = "ethernet-phy";
> + };
> +
> + /* ESTAR-1 (UCC1, MDIO 0x10, RGMII) */
> + phy_estar1: ethernet-phy@10 {
> + interrupt-parent = <&ipic>;
> + interrupts = <17 0x8>;
> + reg = <0x10>;
> + device_type = "ethernet-phy";
> + };
> +
> + /* ESTAR-2 (UCC2, MDIO 0x11, RGMII) */
> + phy_estar2: ethernet-phy@11 {
> + interrupt-parent = <&ipic>;
> + interrupts = <18 0x8>;
> + reg = <0x11>;
> + device_type = "ethernet-phy";
> + };
> + };
> +
> + qeic: interrupt-controller@80 {
> + interrupt-controller;
> + compatible = "fsl,qe-ic";
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + reg = <0x80 0x80>;
> + big-endian;
seems unnecessary .. the qe is only big-endian.
> + interrupts = <32 8 33 8>;
> + interrupt-parent = <&ipic>;
> + };
> + };
> diff --git a/arch/powerpc/platforms/83xx/kmeter1.c b/arch/powerpc/
> platforms/83xx/kmeter1.c
> new file mode 100644
> index 0000000..99cf5c6
> --- /dev/null
> +++ b/arch/powerpc/platforms/83xx/kmeter1.c
> @@ -0,0 +1,170 @@
> +/*
> + * Copyright 2008 DENX Software Engineering GmbH
> + * Author: Heiko Schocher <hs@denx.de>
> + *
> + * Description:
> + * Keymile KMETER1 board specific routines.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/reboot.h>
> +#include <linux/pci.h>
> +#include <linux/kdev_t.h>
> +#include <linux/major.h>
> +#include <linux/console.h>
> +#include <linux/delay.h>
> +#include <linux/seq_file.h>
> +#include <linux/root_dev.h>
> +#include <linux/initrd.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_device.h>
> +
> +#include <asm/system.h>
> +#include <asm/atomic.h>
> +#include <asm/time.h>
> +#include <asm/io.h>
> +#include <asm/machdep.h>
> +#include <asm/ipic.h>
> +#include <asm/irq.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <sysdev/fsl_soc.h>
> +#include <sysdev/fsl_pci.h>
> +#include <asm/qe.h>
> +#include <asm/qe_ic.h>
> +
> +#include "mpc83xx.h"
> +
> +/*
> ************************************************************************
> + *
> + * Setup the architecture
> + *
> + */
> +static void __init kmeter1_setup_arch(void)
> +{
> + struct device_node *np;
> +
> + if (ppc_md.progress)
> + ppc_md.progress("kmeter1_setup_arch()", 0);
> +
> +#ifdef CONFIG_PCI
> + for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
> + mpc83xx_add_bridge(np);
> +#endif
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + qe_reset();
> +
> + np = of_find_node_by_name(NULL, "par_io");
> + if (np != NULL) {
> + par_io_init(np);
> + of_node_put(np);
> +
> + for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
> + par_io_of_config(np);
> + }
> +
> + np = of_find_compatible_node(NULL, "network", "ucc_geth");
> + if (np != NULL) {
> + uint svid;
> +
> + /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
> + svid = mfspr(SPRN_SVR);
> + if (svid == 0x80480021) {
> + void __iomem *immap;
> +
> + immap = ioremap(get_immrbase() + 0x14a8, 8);
we should add a proper device node to cover whatever register space
this is.
>
> +
> + /*
> + * IMMR + 0x14A8[4:5] = 11 (clk delay for UCC 2)
> + * IMMR + 0x14A8[18:19] = 11 (clk delay for UCC 1)
> + */
> + setbits32(immap, 0x0c003000);
> +
> + /*
> + * IMMR + 0x14AC[20:27] = 10101010
> + * (data delay for both UCC's)
> + */
> + clrsetbits_be32(immap + 4, 0xff0, 0xaa0);
> + iounmap(immap);
> + }
> + of_node_put(np);
> + }
> +#endif /* CONFIG_QUICC_ENGINE */
> +}
> +
^ permalink raw reply
* Re: [PATCH] PPC440EPx SDRAM width
From: Josh Boyer @ 2009-04-23 14:59 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <49F07DF0.5020207@ru.mvista.com>
On Thu, Apr 23, 2009 at 06:40:48PM +0400, Valentine Barshak wrote:
> Stefan Roese wrote:
>> On Thursday 23 April 2009, Josh Boyer wrote:
>>> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>>>> There is an error in the way ibm4xx_denali_fixup_memsize calculates
>>>> memory size. When testing the DDR_REDUC bit, the polarity is
>>>> backwards. A "1" implies 32-bit wide memory while a "0" implies
>>>> 64-bit wide memory.
>>>>
>>>> For a 32-bit wide system, this bug causes twice the memory to be
>>>> reported, leading to boot failure.
>>>>
>>>> Signed-off-by: Steven A. Falco <sfalco@harris.com>
>>> So we had a previous patch for this, and a very long discussion on what the
>>> right solution was. Either we never came to a resolution, or I have just
>>> forgotten what it was.
>>>
>>> Stefan, Valentine, do either of you remember?
>>
>
> The patch will break sequia/rainier since u-boot doesn't set the number
> of chipselects correctly for them. IIRC, the last conversation didn't
> come to any conclusion. We sort of wanted to fix that regardless of
> whether we had corrected u-boot or not.
>
> Could we use a "model" property to distinguish between the "real"
> sequoia/rainier and other custom boards?
> If yes, we could add a workaround the ibm4xx_denali_fixup_memsize to
> hardcode the chipselect number to 1 for sequoia/rainier.
We could do that perhaps, yes. In cases where the board has a newer U-Boot
with the fix already, it shouldn't really cause any harm, correct?
josh
^ 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