* [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 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
* 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
* 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: 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: 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: [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: 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: 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: [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: 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] [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: [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 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: [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 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: 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] 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: Matt Sealey @ 2007-09-14 15:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, S. Fricke
In-Reply-To: <fa686aa40709140753sb3e0e9cv28fa5215f4db3a@mail.gmail.com>
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? :)
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
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: Grant Likely @ 2007-09-14 14:53 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, S. Fricke
In-Reply-To: <46EA8CD7.2050304@genesi-usa.com>
On 9/14/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Grant!
>
> I have a newbie question which I never had properly answered. On the
> MPC52xx and specifically regarding the device tree, how are interrupt
> numbers assigned?
>
> On Efika (and in the DT docs) it's basically the X Y Z where X is the
> type (critical, main, peripheral, sdma), Y is the number of the
> interrupt, and Z is it's sense level.
>
> However while X and Z are easy to derive, how do you work out what Y
> is meant to be given a device? Is it a bit number in the interrupt
> register, or the value of the encoded interrupt register or something
> else algorithmically determined?
>
> I am just finding the code in Linux that derives this number fairly
> elusive (the irq setup function for the mpc52xx platform is truly
> 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).
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.
Cheers,
g.
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
> Grant Likely wrote:
> > On 9/11/07, S. Fricke <silvio.fricke@googlemail.com> wrote:
> >> Hello,
> >>
> >>>> [...]
> >>>> intr = mpc52xx_find_and_map("mpc52xx-pic");
> >>>> if(!intr) {
> >>>> panic(__FILE__ ": mpc52xx-pic - MAP failed");
> >>>> }
> >>>>
> >>>> set_irq_chip(MPC52xx_IRQ2, &my_irq_chip);
> >>> You probably don't want to do this (unless you are cascading IRQs to
> >>> custom external hardware). All you should need is the call to
> >>> request_irq() to register your irq handler, and code in your ISR
> >>> handler to clear the interrupt condition.
> >>>
> >>> You do *NOT* want to program the interrupt controller directly. The
> >>> mpc5200 interrupt controller already has a driver. Don't go twiddling
> >>> the registers manually.
> >> OK!
> >>
> >> I have tried it before and i get a "-ENOSYS" returned.
> >>
> >> My code was/is now:
> >> --==>
> >> request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_DISABLED , "intmod",
> >> INTMOD_IRQ_BOARD);
> >> <==--
> >>
> >> I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
> >> "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
> >>
> >> THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
> >> paste), but mpc52xx is (now) a powerpc-arch. What is the desired value for
> >> IRQ-2 on a mpc5200b?
> >
> > The irq number you pass into request_irq is a system-wide irq number;
> > it doesn't necessarily map directly onto the MPC52xx irq number.
> > Typically, you'd have a node for your device in the device tree which
> > has a phandle back to the interrupt node and you would use
> > irq_of_parse_and_map() to map it back to a system-wide irq number.
> >
> > Otherwise, you need to call of_irq_map_raw with the pointer to the
> > 52xx interrupt controller node and the interrupt number in the form
> > expected by the device tree. (But adding a device tree node for your
> > device is far easier).
> >
> > Cheers,
> > g.
> >
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] PowerPC: usb ehci of_platform bindings for Sequoia 440EPx
From: Valentine Barshak @ 2007-09-14 14:31 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <2c5fb8f063c275286b6b26ca734ed64d@kernel.crashing.org>
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.
Thanks,
Valentine.
>
>
> Segher
>
^ permalink raw reply
* RE: 2.6.23-rc3 boot hang on MPC8641D
From: sivaji @ 2007-09-14 14:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <46B96294322F7D458F9648B60E15112C85D82D@zch01exm26.fsl.freescale.net>
Hi Zhang,
Asper ur idea, i downloaded latest BSP(Jun,2007) and the
kernel (2.6.23-rc4) from the Paul's Git tree.
Uboot(1.2.0) was taken from the latest BSP. I portted the new uboot to my
custom board, i got uboot prompt.
When i compiling the kernel i got following warning messages
WARNING: vmlinux.o(.text+0x169f6): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
WARNING: vmlinux.o(.text+0x16a02): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
WARNING: vmlinux.o(.text+0x16a12): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
When i try to boot the kernel, I got following messages
Booting image at 00200000 ...
Image Name: Linux-2.6.23-rc4-g5326152f-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1842307 Bytes = 1.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x600000
I can't know whether the problem is related to uboot or
kernel. But i tested the board with the 2.6.21 kernel, it was up.In that
kernel we face some issues on PCI Express so we plan to upgrade the kernel.
But the latest kernel was not up.
Please advice me.
By
Sivaji
Zhang Wei-r63237 wrote:
>
> Hi, Sivaji,
>
> I've tested the newest git tree of Paul's, which is aleady updated to
> 2.6.23-rc4. The kernel is no problem with the u-boot of our released BSP
> (Jun, 2007) on MPC8641HPCN board.
>
> Maybe you could update to the newest kernel git tree and try again.
>
> Cheers!
> -zw
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+wei.zhang=freescale.com@ozlabs.org
>> [mailto:linuxppc-dev-bounces+wei.zhang=freescale.com@ozlabs.or
>> g] On Behalf Of sivaji
>> Sent: Thursday, September 13, 2007 1:32 PM
>> To: linuxppc-dev@ozlabs.org
>> Subject: RE: 2.6.23-rc3 boot hang on MPC8641D
>>
>>
>> Hi,
>> Sorry i specify the wrong version, we r using
>> 1.2.0. This uboot
>> was taken from the BSP which was released by Freescale.
>> Previously we tested
>> linux 2.6.21 kernel, we got linux prompt. For this we are
>> using the same
>> uboot(1.2.0).
>> In that version we face some issues in the pci express, at
>> that time kumar
>> suggest to upgrade the kernel verison 2.6.23-rc3.
>> Zhang did u suspect the problem is related to uboot?.
>> by
>> sivaji
>>
>>
>> Zhang Wei-r63237 wrote:
>> >
>> > Yes, It's too old. Maybe not fully supports FDT. You can
>> try the version
>> > of Kumar said or in the BSP of Freescale released.
>> >
>> > - zw
>> >
>> >> -----Original Message-----
>> >> From: linuxppc-dev-bounces+wei.zhang=freescale.com@ozlabs.org
>> >> [mailto:linuxppc-dev-bounces+wei.zhang=freescale.com@ozlabs.or
>> >> g] On Behalf Of Kumar Gala
>> >> Sent: Thursday, September 13, 2007 1:11 PM
>> >> To: sivaji
>> >> Cc: linuxppc-dev@ozlabs.org
>> >> Subject: Re: 2.6.23-rc3 boot hang on MPC8641D
>> >>
>> >>
>> >> On Sep 12, 2007, at 11:52 PM, sivaji wrote:
>> >>
>> >> >
>> >> >
>> >> > Hi,
>> >> > I tired to move the dtb to 0x2000000, but the
>> result was
>> >> > same.
>> >> > uboot version is 1.1.6
>> >>
>> >> seems like a pretty old u-boot. Willing to try a 1.3.0-rc1?
>> >>
>> >> - k
>> >> _______________________________________________
>> >> Linuxppc-dev mailing list
>> >> Linuxppc-dev@ozlabs.org
>> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>> >>
>> > _______________________________________________
>> > Linuxppc-dev mailing list
>> > Linuxppc-dev@ozlabs.org
>> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf44335
>> 08.html#a12648963
>> Sent from the linuxppc-dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
View this message in context: http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf4433508.html#a12676464
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Alan Cox @ 2007-09-14 14:20 UTC (permalink / raw)
To: Christoph Hellwig, Heiko Carstens, Andrew Morton, Michael Neuling,
Linus Torvalds, paulus, Alan Cox, David S. Miller, linux-kernel,
linuxppc-dev, Martin Schwidefsky
In-Reply-To: <20070912134910.GA12660@infradead.org>
On Wed, Sep 12, 2007 at 02:49:10PM +0100, Christoph Hellwig wrote:
> On Wed, Sep 12, 2007 at 01:52:57PM +0200, Heiko Carstens wrote:
> > > I might be missing something, but the the right fix is probably to
> > > apply the arch patches from Alan to powerpc and s390. We don't want to
> > > be left over without all the nice termios features on these platforms,
> > > do we?
> >
> > But not in rc6 timeframe, I would guess?
>
> Ask Alan..
Well i've been chasing people for many months on the 390 side so if they missed
a release tough ...
Alan
--
--
"A wiki is where ideas go to die"
-- Becky Hogge
^ permalink raw reply
* Re: [PATCH] ucc_geth: fix compilation
From: Kumar Gala @ 2007-09-14 14:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev@ozlabs.org list, netdev
In-Reply-To: <20070913152333.GA2381@localhost.localdomain>
On Sep 13, 2007, at 10:23 AM, Anton Vorontsov wrote:
> Currently qe_bd_t is used in the macro call -- dma_unmap_single,
> which is a no-op on PPC32, thus error is hidden today. Starting
> with 2.6.24, macro will be replaced by the empty static function,
> and erroneous use of qe_bd_t will trigger compilation error.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
Jeff, I'm going to pick this up via the powerpc.git tree since its
currently only broken in our for-2.6.24 branch (because of other
changes in there). Any issues?
- k
>
> Reposting this to include netdev in Cc.
>
> drivers/net/ucc_geth.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index 12e01b2..9a38dfe 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -2148,7 +2148,7 @@ static void ucc_geth_memclean(struct
> ucc_geth_private *ugeth)
> for (j = 0; j < ugeth->ug_info->bdRingLenTx[i]; j++) {
> if (ugeth->tx_skbuff[i][j]) {
> dma_unmap_single(NULL,
> - ((qe_bd_t *)bd)->buf,
> + ((struct qe_bd *)bd)->buf,
> (in_be32((u32 *)bd) &
> BD_LENGTH_MASK),
> DMA_TO_DEVICE);
> --
> 1.5.0.6
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Please pull from for-2.6.24
From: Kumar Gala @ 2007-09-14 14:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0709131554530.29675@blarg.am.freescale.net>
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).
- k
^ 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