* Re: [PATCH] PowerPC: usb ehci of_platform bindings for Sequoia 440EPx
From: Kumar Gala @ 2007-09-14 15:35 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46EA9B44.6030606@ru.mvista.com>
On Sep 14, 2007, at 9:31 AM, Valentine Barshak wrote:
> Segher Boessenkool wrote:
>>> EHCI OF bindings for PowerPC 440EPx Sequoia.
>>
>> Those aren't bindings, they are examples. Bindings are pieces
>> of documentation that describe what device-specific properties
>> mean what, what standard properties are required with what
>> values, etc.
>>
>> Examples are good to have, of course.
>>
>> One thing you really need to document is what "ehci-be-desc"
>> and friends mean. I can give you one comment already: for
>> devices that are usually little-endian, but an implementation
>> implements registers as big-endian, precedent is to show that
>> in the device tree by including an (empty) "big-endian" property,
>> rather than inventing new "compatible" values.
>
> I was looking at the ohci-ppc-of driver that has "ohci-bigendian"
> compatible string and enables both be-mmio and be-desc for the
> device in
> this case. I just wanted to separate mmio and desc stuff for ehci,
> since
> some devices need be-mmio only.
> I'll use "big-endian" property instead of "ehci-be-mmio" compatible
> value. That's a good point, thanks.
> Do I have to add "sequoia usb ehci" description to
> Documentation/powerpc/booting-without-of.txt?
> Do I also have to describe ehci-ppc-of stuff in general?
> BTW, I see nothing about ohci-ppc-of there.
We may need to comprehend the Freescale USB controller since its
technically an EHCI controller. There should be some stuff in
booting-without-of.txt related to it.
- k
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: Grant Likely @ 2007-09-14 15:49 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, S. Fricke
In-Reply-To: <46EAA65E.5080006@genesi-usa.com>
On 9/14/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Grant Likely wrote:
> > On 9/14/07, Matt Sealey <matt@genesi-usa.com> wrote:
> >> sparse, irq_of_find_and_map isn't much help). Maybe I am just not
> >> looking in the right place but not being an MPC52xx PIC Expert I
> >> wouldn't even know where to start...
> >
> > The l2 irq numbers map directly to the interrupt numbers listed in the
> > 5200b user guide. For example, on p7-11, the masks are listed for
> > main interrupts 0 through 16. and on p7-17,18, the peripherial
> > interrupts are listed as numbered from 0 to 23 (but notice that it
> > does *not* line up with bit positions).
>
> Wow I even had to search.. it's on p7-13 here..
>
> Right but it does start from a certain bit and progress linearly
> across the rest of the register.
>
> However, what is interrupt 0 and what is interrupt 16? Do you start
> from the left or the right (i.e. Motorola big endian or Rest Of
> World big endian)??
>
> > However, it is interesting to note that other than in the register
> > definitions, I don't think there is anywhere in the 5200b user manual
> > that simple lists the interrupt numbers for each interrupt type.
>
> I think the interesting note is that picking out "what does IRQ 4
> in the main interrupt group handle" or picking out a device and
> saying "this is IRQ 10" is still, even with your explanation, a
> matter of luck and handedness.
>
> Personally I would count from the right (Motorola bit 31) and
> work my way from LSB to MSB, but Motorola likes it's backwards
> representation and so do some other people. So, does bit 31
> equal interrupt 0 or interrupt 16? :)
No, they are explicitly numbered. Are you looking at the 5200 or the
5200B user manual? In my copy, on page 7-17, I see this: PSa0 in
peripheral interrupt 0 (l2=3D0), PSa23 is peripheral interrupt #23
(l2=3D23)
Bits Name
8 PSa23 BestCom
9 PSa22 BDLC
10 PSa0 BestCom
11 PSa1 PSC1
12 PSa2 PSC2
13 PSa3 PSC3
14 PSa4 PSC6
15 PSa5 Ethernet
16 PSa6 USB
17 PSa7 ATA
18 PSa8 PCI Contr
19 PSa9 PCI SC In
20 PSa10 PCI SC In
21 PSa11 PSC4
22 PSa12 PSC5
23 PSa13 SPI modf
24 PSa14 SPI spif
25 PSa15 I2C1
26 PSa16 I2C2
27 PSa17 CAN1
28 PSa18 CAN2
29:30 =97 Reserved
31 PSa21 XLB Arbit
>
> Then there are the status encoded registers, which report which
> IRQ is firing. They are just values. But which value corresponds
> to which interrupt (left or right reading) here or do they even
> have completely different ones?
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
From: Laurent Pinchart @ 2007-09-14 15:55 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200707111517.52663.laurent.pinchart@technotrade.biz>
> On Sep 13, 2007, at 8:53 AM, Laurent Pinchart wrote:
>> On Wednesday 11 July 2007 15:17, Laurent Pinchart wrote:
>>> cpm2_clk_setup() supports setting FCC clocks only, even though the
>>> cpm_clk_target enumeration lists SCC clocks. This patch adds SCC =20
>>> clock support.
>>
>> Any chance this patch (and its 2/2 brother) could be committed ?
>
> Have you looked at Scott Wood's cleanup patches. They seem to do =20
> some of this.
Where can I find them ? I checked in
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
and found nothing relevant.
Best regard,
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: Matt Sealey @ 2007-09-14 16:04 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, S. Fricke
In-Reply-To: <fa686aa40709140849o400fc5d0oaaee540fa416fefe@mail.gmail.com>
Grant Likely wrote:
>
> No, they are explicitly numbered. Are you looking at the 5200 or the
> 5200B user manual?
MPC5200B User's Manual, Rev. 1.3 (MPC5200BUM.pdf)
> In my copy, on page 7-17, I see this:
Ah! 7-20 here. Do we have different revisions of the manual, perhaps? :)
PSa0 in
> peripheral interrupt 0 (l2=0), PSa23 is peripheral interrupt #23
> (l2=23)
>
> Bits Name
> 8 PSa23 BestCom
So, the numbering of the interrupts is not derived from anything but
the "Name" field in those tables? 0 1 3 would be Slice Timer 0, 1 0 3
would be Slice Timer 1 (main, interrupt 0, we always use 3 on Efika
for some reason) and 1 9 3 would be TMR0? PCI control and initiator
interrupts would be 2 (8,9,10) 3?
Well, this certainly makes a lot more sense, at least in terms of
deriving the numbers, however it looks like it's a fairly nonsensical
numbering system to be fair.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 02/12] IB/ehca: Add 1 is not longer needed because of firmware interface change
From: Roland Dreier @ 2007-09-14 16:05 UTC (permalink / raw)
To: Joachim Fenkes
Cc: OF-EWG, LKML, LinuxPPC-Dev, Christoph Raisch, OF-General,
Stefan Roscher
In-Reply-To: <OF628247C3.FB0AFE13-ONC1257355.005E8356-C1257356.004BCE85@de.ibm.com>
> If the rest of this patchset is okay with you, could you apply it and
> leave out this one patch? The patchset will apply cleanly without it.
Yes, no problem, I'll drop this patch for now.
- R.
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
From: Scott Wood @ 2007-09-14 16:08 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200709141755.45559.laurentp@cse-semaphore.com>
On Fri, Sep 14, 2007 at 05:55:45PM +0200, Laurent Pinchart wrote:
> > On Sep 13, 2007, at 8:53 AM, Laurent Pinchart wrote:
> >> On Wednesday 11 July 2007 15:17, Laurent Pinchart wrote:
> >>> cpm2_clk_setup() supports setting FCC clocks only, even though the
> >>> cpm_clk_target enumeration lists SCC clocks. This patch adds SCC
> >>> clock support.
> >>
> >> Any chance this patch (and its 2/2 brother) could be committed ?
> >
> > Have you looked at Scott Wood's cleanup patches. They seem to do
> > some of this.
>
> Where can I find them ? I checked in
>
> git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
>
> and found nothing relevant.
Check the linuxppc-dev archives... I should have another respin soon
(hopefully today).
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] DTS cleanup
From: Jon Loeliger @ 2007-09-14 16:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B89BC392-2366-42E0-BEA0-4A781A9437D3@kernel.crashing.org>
Kumar Gala wrote:
> Someone really needs to add some macro/preprocessor magic into DTC so
> this is made a lot simpler.
>
> - k
Kumar,
I am seriously contemplating this problem.
The trick is, I need to quit with the whole
Power Point Programmer job title for a bit...
jdl
^ permalink raw reply
* Re: rtc-ds1742.c should use resource_size_t for base address
From: Atsushi Nemoto @ 2007-09-14 16:09 UTC (permalink / raw)
To: david; +Cc: akpm, linuxppc-dev, linux-kernel, rtc-linux
In-Reply-To: <20070914055427.GM481@localhost.localdomain>
On Fri, 14 Sep 2007 15:54:27 +1000, David Gibson <david@gibson.dropbear.id.au> wrote:
> Currently the rtc driver, rtc-ds1742.c uses an unsigned long to store
> the base mmio address of the NVRAM/RTC. This breaks on systems like
> PowerPC 440, which is a 32-bit core with 36-bit physical addresses: IO
> on the system, including the RTC, is typically above the 4GB point,
> and cannot fit into an unsigned long.
>
> This patch fixes the problem by replacing the unsigned long with a
> resource_size_t. Tested on Ebony (PPC440) (with additional patches to
> instantiate the ds1742 platform device appropriately).
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Thanks!
Acked-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
^ permalink raw reply
* Re: [PATCH] pcmcia: Convert io_req_t to use kio_addr_t
From: Olof Johansson @ 2007-09-14 16:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel, hch
In-Reply-To: <20070914034854.1658a9cf.akpm@linux-foundation.org>
On Fri, Sep 14, 2007 at 03:48:54AM -0700, Andrew Morton wrote:
> On Wed, 5 Sep 2007 09:27:43 -0500 Olof Johansson <olof@lixom.net> wrote:
>
> > Convert the io_req_t members to kio_addr_t, to allow use on machines with
> > more than 16 bits worth of IO port address space (ppc64 in this case,
> > but it applies to others as well).
>
> drivers/usb/host/sl811_cs.c: In function 'sl811_cs_config':
> drivers/usb/host/sl811_cs.c:263: warning: format '%04x' expects type 'unsigned int', but argument 2 has type 'kio_addr_t'
> drivers/usb/host/sl811_cs.c:263: warning: format '%04x' expects type 'unsigned int', but argument 3 has type 'long unsigned int'
>
> That's not just a cosmetic thing - the printk can print junk and if there's
> a %s in the control string after the %x's, printk() will crash.
>
> I don't know how many instances of this are in the tree, but they'll all
> need to be found and fixed.
A crap, I completely forgot to check drivers/, and my default builds
don't contain many of them. My bad.
I'll do a full pass and review all references to the changed variables. So
far I've only noticed printk stuff, but I'm not done. There's a fair
amount lot of places where they're cast into ints instead of longs,
but that's a whole other ball of wax (and shouldn't cause regressions
like the printk ones could).
-Olof
^ permalink raw reply
* Re: rtc-ds1742.c should use resource_size_t for base address
From: Josh Boyer @ 2007-09-14 17:20 UTC (permalink / raw)
To: David Gibson
Cc: Andrew Morton, linuxppc-dev, Atsushi Nemoto, linux-kernel,
rtc-linux
In-Reply-To: <20070914055427.GM481@localhost.localdomain>
On Fri, 14 Sep 2007 15:54:27 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> Currently the rtc driver, rtc-ds1742.c uses an unsigned long to store
> the base mmio address of the NVRAM/RTC. This breaks on systems like
> PowerPC 440, which is a 32-bit core with 36-bit physical addresses: IO
> on the system, including the RTC, is typically above the 4GB point,
> and cannot fit into an unsigned long.
>
> This patch fixes the problem by replacing the unsigned long with a
> resource_size_t. Tested on Ebony (PPC440) (with additional patches to
> instantiate the ds1742 platform device appropriately).
Where would those additional patches be? :)
josh
^ permalink raw reply
* Re: Please pull from for-2.6.24
From: Josh Boyer @ 2007-09-14 17:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <AC7B9A70-5050-4191-A20E-B92686B675D4@kernel.crashing.org>
On Fri, 14 Sep 2007 09:02:04 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 13, 2007, at 3:55 PM, Kumar Gala wrote:
>
> > Please pull from 'for-2.6.24' branch of
> >
> > master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
> > for-2.6.24
> >
> > to receive the following updates:
>
> I've updated the branch with the following changes:
>
> > Anton Vorontsov (3):
> > [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register
> > mmc_spi stub
>
> Updated commit message. (let me know if you want me to drop this for
> now and wait til mmc_spi gets merged)
>
> > Roy Zang (1):
> > [POWERPC] Update mpc7448hpc2 device tree to be compatible for
> > tsi109 chip
>
> Dropped for now. I doubt we want this based on Segher's comments.
> (pretty sure its a ts108 on the hpc2 board).
It is a tsi108 on hpc2. Holly has tsi109. From a Linux perspective,
there is no difference. And the comment Segher made on the list was
"Looks good, thanks!" So what other comment are you talking about?
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] DTS cleanup
From: Kumar Gala @ 2007-09-14 18:11 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <46EAB69C.104@freescale.com>
On Sep 14, 2007, at 11:28 AM, Jon Loeliger wrote:
> Kumar Gala wrote:
>
>> Someone really needs to add some macro/preprocessor magic into DTC
>> so this is made a lot simpler.
>> - k
>
> Kumar,
>
> I am seriously contemplating this problem.
> The trick is, I need to quit with the whole
> Power Point Programmer job title for a bit...
I'm all for both of these things. You working on getting DTC to have
some macro/include ability and you not being a powerpoint programmer.
- k
^ permalink raw reply
* Re: Please pull from for-2.6.24
From: Kumar Gala @ 2007-09-14 18:24 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <20070914122510.6dffb747@weaponx.rchland.ibm.com>
>>> Roy Zang (1):
>>> [POWERPC] Update mpc7448hpc2 device tree to be compatible for
>>> tsi109 chip
>>
>> Dropped for now. I doubt we want this based on Segher's comments.
>> (pretty sure its a ts108 on the hpc2 board).
>
> It is a tsi108 on hpc2. Holly has tsi109. From a Linux perspective,
> there is no difference. And the comment Segher made on the list was
> "Looks good, thanks!" So what other comment are you talking about?
I think that was to the .dts clean ups. The patch from Roy wasn't
part of that.
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042499.html
But, I think segher is right in saying we should have tsi109 props if
the HW is actually tsi108.
- k
^ permalink raw reply
* Re: Define termios_1 functions for powerpc, s390, avr32 and frv
From: David Miller @ 2007-09-14 18:33 UTC (permalink / raw)
To: akpm
Cc: mikey, hskinnemoen, torvalds, heiko.carstens, linux-kernel,
linuxppc-dev, lethal, paulus, alan, jdi
In-Reply-To: <20070913035506.b599e84f.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Thu, 13 Sep 2007 03:55:06 -0700
> I think we need to go with Tony's patch. sparc32 and sparc64 are
> presently broken too, and the patch which converts sparc to use the
> new interfaces introduces a few build errors.
The problem with the asm-generic/termios.h thing is it only works
if your copying functions are just a copy_{to,from}_user() and you
can define that __ARCH_* macro.
In retrospect what that header should do is, outside of the
ARCH_* block, define the foo_1 interfaces plainly to foo.
Alternatively, here is a patch that gets sparc compiling and
working again in the current tree.
This whole termios thing hasn't been handled very well, and it's maybe
not what we should be doing so late in the -rc cycle. And yes,
this is coming from the guy who added the TCP oops'er two weeks ago
:-P
[SPARC]: Fix build due to termios changes.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/include/asm-sparc/termios.h b/include/asm-sparc/termios.h
index d767f20..25e9cbb 100644
--- a/include/asm-sparc/termios.h
+++ b/include/asm-sparc/termios.h
@@ -142,6 +142,11 @@ struct winsize {
0; \
})
+#define user_termios_to_kernel_termios_1(k, u) \
+ user_termios_to_kernel_termios(k, u)
+#define kernel_termios_to_user_termios_1(u, k) \
+ kernel_termios_to_user_termios(u, k)
+
#endif /* __KERNEL__ */
#endif /* _SPARC_TERMIOS_H */
diff --git a/include/asm-sparc64/termios.h b/include/asm-sparc64/termios.h
index f05d390..6fc71e6 100644
--- a/include/asm-sparc64/termios.h
+++ b/include/asm-sparc64/termios.h
@@ -145,6 +145,11 @@ struct winsize {
err; \
})
+#define user_termios_to_kernel_termios_1(k, u) \
+ user_termios_to_kernel_termios(k, u)
+#define kernel_termios_to_user_termios_1(u, k) \
+ kernel_termios_to_user_termios(u, k)
+
#endif /* __KERNEL__ */
#endif /* _SPARC64_TERMIOS_H */
^ permalink raw reply related
* Re: Please pull from for-2.6.24
From: Josh Boyer @ 2007-09-14 18:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <16B381A2-66F5-4E7A-BDDC-6E536296C933@kernel.crashing.org>
On Fri, 14 Sep 2007 13:24:17 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
> >>> Roy Zang (1):
> >>> [POWERPC] Update mpc7448hpc2 device tree to be compatible for
> >>> tsi109 chip
> >>
> >> Dropped for now. I doubt we want this based on Segher's comments.
> >> (pretty sure its a ts108 on the hpc2 board).
> >
> > It is a tsi108 on hpc2. Holly has tsi109. From a Linux perspective,
> > there is no difference. And the comment Segher made on the list was
> > "Looks good, thanks!" So what other comment are you talking about?
>
> I think that was to the .dts clean ups. The patch from Roy wasn't
> part of that.
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042499.html
Nope, on the original patch:
http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039289.html
Guess Segher changed his mind :)
> But, I think segher is right in saying we should have tsi109 props if
> the HW is actually tsi108.
Yeah, that's probably true.
josh
^ permalink raw reply
* Re: Please pull from for-2.6.24
From: Segher Boessenkool @ 2007-09-14 18:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <20070914133710.541f0dbb@weaponx.rchland.ibm.com>
>>>> Dropped for now. I doubt we want this based on Segher's comments.
>>>> (pretty sure its a ts108 on the hpc2 board).
>>>
>>> It is a tsi108 on hpc2. Holly has tsi109. From a Linux perspective,
>>> there is no difference. And the comment Segher made on the list was
>>> "Looks good, thanks!" So what other comment are you talking about?
>>
>> I think that was to the .dts clean ups. The patch from Roy wasn't
>> part of that.
>>
>> http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042499.html
>
> Nope, on the original patch:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039289.html
>
> Guess Segher changed his mind :)
I didn't notice this issue before, that's all :-)
>> But, I think segher is right in saying we should have tsi109 props if
>> the HW is actually tsi108.
>
> Yeah, that's probably true.
Segher
^ permalink raw reply
* [patch 0/4] Small 4xx updates for 2.6.24
From: Josh Boyer @ 2007-09-14 18:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
Below is a small update series for 4xx that I intend to put in my
2.6.24 branch soon and send to Paul. It contains an already acked
cuboot wrapper for Bamboo, a fix for the newly updated physmap_of
driver, and updates to the walnut and sequoia flash nodes in the DTS
files.
josh
--
^ permalink raw reply
* [patch 4/4] 4xx: Convert Seqouia flash mappings to new binding
From: Josh Boyer @ 2007-09-14 18:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
In-Reply-To: <20070914185410.387074000@linux.vnet.ibm.com>
A new binding for flash devices was recently introduced. This updates the
Sequoia DTS to use the new binding and enabled MTD in the defconfig.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/dts/sequoia.dts | 38 +++++++++----
arch/powerpc/configs/sequoia_defconfig | 91 +++++++++++++++++++++++++++++++--
2 files changed, 115 insertions(+), 14 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts
+++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts
@@ -142,19 +142,35 @@
interrupt-parent = <&UIC1>;
nor_flash@0,0 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "CFI";
+ compatible = "amd,s29gl256n", "cfi-flash";
bank-width = <2>;
- partitions = < 0 180000
- 180000 200000
- 380000 3aa0000
- 3e20000 140000
- 3f60000 40000
- 3fa0000 60000>;
- partition-names = "Kernel", "ramdisk", "file system",
- "kozio", "env", "u-boot";
reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "Kernel";
+ reg = <0 180000>;
+ };
+ partition@180000 {
+ label = "ramdisk";
+ reg = <180000 200000>;
+ };
+ partition@380000 {
+ label = "file system";
+ reg = <380000 3aa0000>;
+ };
+ partition@3e20000 {
+ label = "kozio";
+ reg = <3e20000 140000>;
+ };
+ partition@3f60000 {
+ label = "env";
+ reg = <3f60000 40000>;
+ };
+ partition@3fa0000 {
+ label = "u-boot";
+ reg = <3fa0000 60000>;
+ };
};
};
--- linux-2.6.orig/arch/powerpc/configs/sequoia_defconfig
+++ linux-2.6/arch/powerpc/configs/sequoia_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.23-rc3
-# Mon Aug 27 20:19:13 2007
+# Linux kernel version: 2.6.23-rc6
+# Fri Sep 14 13:20:06 2007
#
# CONFIG_PPC64 is not set
@@ -146,6 +146,7 @@ CONFIG_440A=y
# CONFIG_GENERIC_IOMAP is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_CPM2 is not set
+# CONFIG_FSL_ULI1575 is not set
#
# Kernel options
@@ -317,7 +318,81 @@ CONFIG_FW_LOADER=y
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+# CONFIG_MTD_BLKDEVS is not set
+# CONFIG_MTD_BLOCK is not set
+# CONFIG_MTD_BLOCK_RO is not set
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+CONFIG_MTD_JEDECPROBE=y
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
@@ -613,6 +688,15 @@ CONFIG_RAMFS=y
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
+CONFIG_JFFS2_FS=y
+CONFIG_JFFS2_FS_DEBUG=0
+CONFIG_JFFS2_FS_WRITEBUFFER=y
+# CONFIG_JFFS2_SUMMARY is not set
+# CONFIG_JFFS2_FS_XATTR is not set
+# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
+CONFIG_JFFS2_ZLIB=y
+CONFIG_JFFS2_RTIME=y
+# CONFIG_JFFS2_RUBIN is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
@@ -671,6 +755,7 @@ CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
+CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
--
^ permalink raw reply
* [patch 2/4] Make partitions optional in physmap_of
From: Josh Boyer @ 2007-09-14 18:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
In-Reply-To: <20070914185410.387074000@linux.vnet.ibm.com>
The latest physmap_of driver has a small error where it will fail the probe
with:
physmap-flash: probe of fff00000.small-flas failed with error -2
if there are no partition subnodes in the device tree and the old style binding
is not used. Since partition definitions are optional, the probe should still
succeed.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
drivers/mtd/maps/physmap_of.c | 2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.orig/drivers/mtd/maps/physmap_of.c
+++ linux-2.6/drivers/mtd/maps/physmap_of.c
@@ -142,6 +142,8 @@ static int __devinit process_partitions(
}
} else {
nr_parts = parse_obsolete_partitions(dev, info, dp);
+ if (nr_parts == -ENOENT)
+ nr_parts = 0;
}
if (nr_parts < 0)
--
^ permalink raw reply
* [patch 1/4] cuimage for Bamboo board
From: Josh Boyer @ 2007-09-14 18:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
In-Reply-To: <20070914185410.387074000@linux.vnet.ibm.com>
Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
linker declarations that have been moved into ops.h
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/boot/44x.h | 2 +-
arch/powerpc/boot/Makefile | 4 ++--
arch/powerpc/boot/bamboo.c | 8 +++++---
arch/powerpc/boot/cuboot-bamboo.c | 30 ++++++++++++++++++++++++++++++
arch/powerpc/boot/treeboot-bamboo.c | 22 +++++++++++++++++++---
5 files changed, 57 insertions(+), 9 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -49,7 +49,7 @@ src-wlib := string.S crt0.S stdio.c main
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
+ cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -146,7 +146,7 @@ image-$(CONFIG_8260) += cuImage.pq2
image-$(CONFIG_PPC_83xx) += cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
-image-$(CONFIG_BAMBOO) += treeImage.bamboo
+image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
image-$(CONFIG_SEQUOIA) += cuImage.sequoia
image-$(CONFIG_WALNUT) += treeImage.walnut
endif
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/cuboot-bamboo.c
@@ -0,0 +1,30 @@
+/*
+ * Old U-boot compatibility for Ebony
+ *
+ * Author: Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * Copyright 2007 IBM Corporation
+ *
+ * Based on cuboot-ebony.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "44x.h"
+#include "cuboot.h"
+
+#define TARGET_44x
+#include "ppcboot.h"
+
+static bd_t bd;
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ bamboo_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
+}
--- linux-2.6.orig/arch/powerpc/boot/44x.h
+++ linux-2.6/arch/powerpc/boot/44x.h
@@ -11,6 +11,6 @@
#define _PPC_BOOT_44X_H_
void ebony_init(void *mac0, void *mac1);
-void bamboo_init(void);
+void bamboo_init(void *mac0, void *mac1);
#endif /* _PPC_BOOT_44X_H_ */
--- linux-2.6.orig/arch/powerpc/boot/bamboo.c
+++ linux-2.6/arch/powerpc/boot/bamboo.c
@@ -24,8 +24,7 @@
#include "4xx.h"
#include "44x.h"
-extern char _dtb_start[];
-extern char _dtb_end[];
+static u8 *bamboo_mac0, *bamboo_mac1;
static void bamboo_fixups(void)
{
@@ -34,12 +33,15 @@ static void bamboo_fixups(void)
ibm440ep_fixup_clocks(sysclk, 11059200);
ibm4xx_fixup_memsize();
ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
+ dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
}
-void bamboo_init(void)
+void bamboo_init(void *mac0, void *mac1)
{
platform_ops.fixups = bamboo_fixups;
platform_ops.exit = ibm44x_dbcr_reset;
+ bamboo_mac0 = mac0;
+ bamboo_mac1 = mac1;
ft_init(_dtb_start, 0, 32);
serial_console_init();
}
--- linux-2.6.orig/arch/powerpc/boot/treeboot-bamboo.c
+++ linux-2.6/arch/powerpc/boot/treeboot-bamboo.c
@@ -12,16 +12,32 @@
#include "ops.h"
#include "stdio.h"
#include "44x.h"
-
-extern char _end[];
+#include "stdlib.h"
BSS_STACK(4096);
+#define PIBS_MAC0 0xfffc0400
+#define PIBS_MAC1 0xfffc0500
+char pibs_mac0[6];
+char pibs_mac1[6];
+
+static void read_pibs_mac(void)
+{
+ unsigned long long mac64;
+
+ mac64 = strtoull((char *)PIBS_MAC0, 0, 16);
+ memcpy(&pibs_mac0, (char *)&mac64+2, 6);
+
+ mac64 = strtoull((char *)PIBS_MAC1, 0, 16);
+ memcpy(&pibs_mac1, (char *)&mac64+2, 6);
+}
+
void platform_init(void)
{
unsigned long end_of_ram = 0x8000000;
unsigned long avail_ram = end_of_ram - (unsigned long)_end;
simple_alloc_init(_end, avail_ram, 32, 64);
- bamboo_init();
+ read_pibs_mac();
+ bamboo_init((u8 *)&pibs_mac0, (u8 *)&pibs_mac1);
}
--
^ permalink raw reply
* [patch 3/4] 4xx: Convert Walnut flash mappings to new binding
From: Josh Boyer @ 2007-09-14 18:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
In-Reply-To: <20070914185410.387074000@linux.vnet.ibm.com>
A new binding for flash devices was recently introduced. This updates the
Walnut DTS to use the new binding.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/dts/walnut.dts | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/dts/walnut.dts
+++ linux-2.6/arch/powerpc/boot/dts/walnut.dts
@@ -137,6 +137,10 @@
dcr-reg = <012 2>;
#address-cells = <2>;
#size-cells = <1>;
+ /* The ranges property is supplied by the bootwrapper
+ * and is based on the firmware's configuration of the
+ * EBC bridge
+ */
clock-frequency = <0>; /* Filled in by zImage */
sram@0,0 {
@@ -144,13 +148,16 @@
};
flash@0,80000 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "JEDEC";
+ compatible = "jedec-flash";
bank-width = <1>;
- partitions = <0 80000>;
- partition-names = "OpenBIOS";
reg = <0 80000 80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "OpenBIOS";
+ reg = <0 80000>;
+ read-only;
+ };
};
ds1743@1,0 {
--
^ permalink raw reply
* [patch 0/4] Small 4xx updates for 2.6.24
From: Josh Boyer @ 2007-09-14 18:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
Below is a small update series for 4xx that I intend to put in my 2.6.24 branch
soon and send to Paul. It contains an already acked cuboot wrapper for Bamboo,
a fix for the newly updated physmap_of driver, and updates to the walnut and
sequoia flash nodes in the DTS files.
josh
--
^ permalink raw reply
* Re: [patch 0/4] Small 4xx updates for 2.6.24
From: Josh Boyer @ 2007-09-14 19:09 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, david
In-Reply-To: <20070914135914.4037a5cb@weaponx.rchland.ibm.com>
On Fri, 14 Sep 2007 13:59:14 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> Below is a small update series for 4xx that I intend to put in my
> 2.6.24 branch soon and send to Paul. It contains an already acked
> cuboot wrapper for Bamboo, a fix for the newly updated physmap_of
> driver, and updates to the walnut and sequoia flash nodes in the DTS
> files.
Ignore this particular email. I had two mailers competing to send out
patches and couldn't kill one of them before this got out. The other
one with the patches actually following it is the right one :)
josh
^ permalink raw reply
* SPI INT line
From: Nicholas Hickman @ 2007-09-14 19:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 458 bytes --]
We are developing a system around the mpc8270. On this system we are
using an ISDN controller connected to the SPI interface of the 8270.
For the INT line coming from the controller, should this be connected to
one of the IRQ lines that we typically use for PCI bus, or should we
connect it to one of the GPIO Group C pins? Currently we have it to
IRQ4, but I am worried that this is incorrect.
Thanks in advance.
Nicholas Hickman
[-- Attachment #2: Type: text/html, Size: 1235 bytes --]
^ permalink raw reply
* CONFIG_BLK_DEV_BSG=n
From: Medve Emilian-EMMEDVE1 @ 2007-09-14 19:50 UTC (permalink / raw)
To: fujita.tomonori, James.Bottomley, James.Bottomley, paulus,
Gala Kumar-B11780
Cc: linuxppc-dev, linux-scsi
Hello,
I'm trying to get powerpc to build without block device support
(CONFIG_BLOCK=3Dn). I'm getting the following errors:
CC arch/powerpc/kernel/setup_32.o
In file included from include/linux/blkdev.h:17,
from include/linux/ide.h:13,
from arch/powerpc/kernel/setup_32.c:13:
include/linux/bsg.h:67: warning: 'struct request_queue' declared inside
parameter list
include/linux/bsg.h:67: warning: its scope is only this definition or
declaration, which is probably not what you want
include/linux/bsg.h:71: warning: 'struct request_queue' declared inside
parameter list
In file included from arch/powerpc/kernel/setup_32.c:13:
include/linux/ide.h:857: error: field 'wrq' has incomplete type
CC arch/powerpc/kernel/ppc_ksyms.o
In file included from include/linux/blkdev.h:17,
from include/linux/ide.h:13,
from arch/powerpc/kernel/ppc_ksyms.c:15:
include/linux/bsg.h:67: warning: 'struct request_queue' declared inside
parameter list
include/linux/bsg.h:67: warning: its scope is only this definition or
declaration, which is probably not what you want
include/linux/bsg.h:71: warning: 'struct request_queue' declared inside
parameter list
In file included from arch/powerpc/kernel/ppc_ksyms.c:15:
include/linux/ide.h:857: error: field 'wrq' has incomplete type
I fixed the errors with a small patch in the powerpc code only and I'm
comfortable with that. The matter I wanted your input on is the warnings
from bsg.h coming from this are of the file:
...
#ifdef __KERNEL__
#if defined(CONFIG_BLK_DEV_BSG)
struct bsg_class_device {
struct class_device *class_dev;
struct device *dev;
int minor;
struct request_queue *queue;
};
extern int bsg_register_queue(struct request_queue *, struct device *,
const char *);
extern void bsg_unregister_queue(struct request_queue *);
#else
static inline int bsg_register_queue(struct request_queue * rq, struct
device *dev, const char *name
)
{
return 0;
}
static inline void bsg_unregister_queue(struct request_queue *rq)
{
}
#endif
#endif /* __KERNEL__ */
...
I noticed that the '#else' branch was last updated by James (a4ee0df8)
in order to address some other warnings in scsi_sysfs.c, for example, in
the next piece of code:
...
error =3D bsg_register_queue(rq, &sdev->sdev_gendev, NULL);
if (error)
sdev_printk(KERN_INFO, sdev,
"Failed to register bsg queue, =
errno=3D%d\n",
error);
/* we're treating error on bsg register as non-fatal, so pretend
* nothing went wrong */
error =3D 0;
...
The quick fix to those warnings is to add a declaration of struct
request_queue in bsg.h something looking like this:
...
#ifdef __KERNEL__
struct request_queue; <- This is the addition
#if defined(CONFIG_BLK_DEV_BSG)
struct bsg_class_device {
struct class_device *class_dev;
...
However, I was wondering if there isn't a cleaner way of doing it. For
example, from the comments in scsi_sysfs.c it looks like it would be
possible not to call bsg_register_queue() at all when
CONFIG_BLK_DEV_BSG=3Dn and get rid of the '#else' branch in bsg.h as I
don't think bsg_register_queue() and bsg_unregister_queue() should be
called when CONFIG_BLK_DEV_BSG=3Dn.
Which solution would you be more comfortable with?
Thanks,
Emil.
This e-mail, and any associated attachments have been classified as:
--------------------------------------------------------------------
[ ] Public
[x] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
^ 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