Re: [PATCH] powerpc: Fix oprofile sampling of marked events on POWER7
Hi Mike, Just a couple of meta things: On Wed, 06 May 2009 15:25:46 -0500 Mike Wolf m...@linux.vnet.ibm.com wrote: From Maynard Johnson mayna...@us.ibm.com This would normally be From: Signed-off-by: Michael Wolf m...@linux.vnet.ibm.com It would be good if you had a Signed-off-by from Maynard as well. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpJbj5CCiIUp.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Trouble using with Kegel cross tool chain
Wow guys, thank you for all the responses. Looks like this mad dive into embedded Linux programming from ASP.NET is not futile. I will take a look at the responses and reply tomorrow. Chris Plasun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/12] mpc5121: Added I2C support.
Grant Likely wrote: On Wed, May 6, 2009 at 4:51 PM, Grant Likely grant.lik...@secretlab.ca wrote: On Wed, May 6, 2009 at 4:19 PM, Wolfgang Denk w...@denx.de wrote: Dear Grant Likely, In message fa686aa40905061401k319313c5q89fd3e245c308...@mail.gmail.com you wrote: On Wed, May 6, 2009 at 2:15 PM, Wolfgang Denk w...@denx.de wrote: From: Piotr Ziecik ko...@semihalf.com - Enabled I2C interrupts on MPC5121. - Updated Kconfig for i2c-mpc driver. I think this workaround belongs in the driver itself. Sorry, I don't get it. Which workaround? What exactly should I change? Sorry, I misread the patch. Never mind. Actually, on 3rd reading, I think my first impression was correct (even if I was wrong about it being a workaround). This code in mpc512x_init_i2c() is only relevant for i2c busses (it isn't shared with any other drivers). Therefore, it belongs with the i2c bus itself. It does not belong in platform code. Right. Furthermore, the i2c-mpc.c should be extened to support bus speed setting for the MPC512x, which has been merged recently (see commit id f2bd5efe). Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 09/12] mpc5121ads: Added I2C RTC node to mpc5121ads DTS.
Wolfgang Denk wrote: From: Piotr Ziecik ko...@semihalf.com Signed-off-by: Piotr Ziecik ko...@semihalf.com Signed-off-by: Wolfgang Denk w...@denx.de Cc: Grant Likely grant.lik...@secretlab.ca Cc: John Rigby jcri...@gmail.com --- arch/powerpc/boot/dts/mpc5121ads.dts |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts b/arch/powerpc/boot/dts/mpc5121ads.dts index 93fe12a..c2d9de9 100644 --- a/arch/powerpc/boot/dts/mpc5121ads.dts +++ b/arch/powerpc/boot/dts/mpc5121ads.dts @@ -210,6 +210,11 @@ interrupts = 9 0x8; interrupt-parent = ipic ; fsl5200-clocking; The above line is obsolete since -rc4. Please check the revised bindings in Documentation/powerpc/dts-bindings/fsl/i2c.txt. You may even want: clock-frequency = 10; Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
Ptrace has performance and/or reliability problems when used to sandbox threaded applications due to potential race conditions when inspecting system call arguments. We hope that we can avoid this problem with seccomp. ptrace certainly has performance issues. I take it the only reliability problems you are talking about are MT races with modifications to user memory that is relevant to a system call. (Is there something else?) That is not a ptrace problem per se at all. It's an intrinsic problem with any method based on generic syscall interception, if the filtering and enforcement decisions depend on examining user memory. By the same token, no such method has a reliability problem if the filtering checks only examine the registers (or other thread-synchronous state). In the sense that I mean, seccomp is generic syscall interception too. (That is, the checks/enforcement are around the call, rather than inside it with direct atomicity controls binding the checks and uses together.) The only reason seccomp does not have this reliability problem is that its filtering is trivial and depends only on registers (in fact, only on one register, the syscall number). If you want to do checks that depend on shared or volatile state, then syscall interception is really not the proper mechanism for you. (Likely examples include user memory, e.g. for file names in open calls, or ioctl struct contents, etc., fd tables or filesystem details, etc.) For that you need mechanisms that look at stable kernel copies of user data that are what the syscall will actually use, such as is done by audit, LSM, etc. If you only have checks confined to thread-synchronous state such as the user registers, then you don't have any reliability problem regardless of the the particular syscall interception mechanism you use. (ptrace has many problems for this or any other purpose, but this is not one of them.) That's unless you are referring to some other reliability problem that I'm not aware of. (And I'll leave aside the is it registers or is it user memory? issue on ia64 as irrelevant, since, you know, it's ia64.) If syscall interception is indeed an appropriate mechanism for your needs and you want something tailored more specifically to your exact use in future kernels, a module doing this would be easy to implement using the utrace API. (That might be a compelling use of utrace by virtue of the Midas brand name effect, if nothing else. ;-) Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
Ptrace has performance and/or reliability problems when used to sandbox threaded applications due to potential race conditions when inspecting system call arguments. We hope that we can avoid this problem with seccomp. ptrace certainly has performance issues. I take it the only reliability problems you are talking about are MT races with modifications to user memory that is relevant to a system call. (Is there something else?) That is not a ptrace problem per se at all. It's an intrinsic problem with any method based on generic syscall interception, if the filtering and enforcement decisions depend on examining user memory. By the same token, no such method has a reliability problem if the filtering checks only examine the registers (or other thread-synchronous state). In the sense that I mean, seccomp is generic syscall interception too. (That is, the checks/enforcement are around the call, rather than inside it with direct atomicity controls binding the checks and uses together.) The only reason seccomp does not have this reliability problem is that its filtering is trivial and depends only on registers (in fact, only on one register, the syscall number). If you want to do checks that depend on shared or volatile state, then syscall interception is really not the proper mechanism for you. (Likely examples include user memory, e.g. for file names in open calls, or ioctl struct contents, etc., fd tables or filesystem details, etc.) For that you need mechanisms that look at stable kernel copies of user data that are what the syscall will actually use, such as is done by audit, LSM, etc. If you only have checks confined to thread-synchronous state such as the user registers, then you don't have any reliability problem regardless of the the particular syscall interception mechanism you use. (ptrace has many problems for this or any other purpose, but this is not one of them.) That's unless you are referring to some other reliability problem that I'm not aware of. (And I'll leave aside the is it registers or is it user memory? issue on ia64 as irrelevant, since, you know, it's ia64.) If syscall interception is indeed an appropriate mechanism for your needs and you want something tailored more specifically to your exact use in future kernels, a module doing this would be easy to implement using the utrace API. (That might be a compelling use of utrace by virtue of the Midas brand name effect, if nothing else. ;-) Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
Ptrace has performance and/or reliability problems when used to sandbox threaded applications due to potential race conditions when inspecting system call arguments. We hope that we can avoid this problem with seccomp. ptrace certainly has performance issues. I take it the only reliability problems you are talking about are MT races with modifications to user memory that is relevant to a system call. (Is there something else?) That is not a ptrace problem per se at all. It's an intrinsic problem with any method based on generic syscall interception, if the filtering and enforcement decisions depend on examining user memory. By the same token, no such method has a reliability problem if the filtering checks only examine the registers (or other thread-synchronous state). In the sense that I mean, seccomp is generic syscall interception too. (That is, the checks/enforcement are around the call, rather than inside it with direct atomicity controls binding the checks and uses together.) The only reason seccomp does not have this reliability problem is that its filtering is trivial and depends only on registers (in fact, only on one register, the syscall number). If you want to do checks that depend on shared or volatile state, then syscall interception is really not the proper mechanism for you. (Likely examples include user memory, e.g. for file names in open calls, or ioctl struct contents, etc., fd tables or filesystem details, etc.) For that you need mechanisms that look at stable kernel copies of user data that are what the syscall will actually use, such as is done by audit, LSM, etc. If you only have checks confined to thread-synchronous state such as the user registers, then you don't have any reliability problem regardless of the the particular syscall interception mechanism you use. (ptrace has many problems for this or any other purpose, but this is not one of them.) That's unless you are referring to some other reliability problem that I'm not aware of. (And I'll leave aside the is it registers or is it user memory? issue on ia64 as irrelevant, since, you know, it's ia64.) If syscall interception is indeed an appropriate mechanism for your needs and you want something tailored more specifically to your exact use in future kernels, a module doing this would be easy to implement using the utrace API. (That might be a compelling use of utrace by virtue of the Midas brand name effect, if nothing else. ;-) Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 06/12] mpc5121: Added NAND Flash Controller driver.
On Wednesday 06 May 2009 22:15:13 Wolfgang Denk wrote:
--- /dev/null
+++ b/drivers/mtd/nand/mpc5121_nfc.c
[...]
+/* Init external chip select logic on ADS5121 board */
+static int ads5121_chipselect_init(struct mtd_info *mtd)
+{
+ struct nand_chip *chip = mtd-priv;
+ struct mpc5121_nfc_prv *prv = chip-priv;
+ struct device_node *dn;
+
+ dn = of_find_compatible_node(NULL, NULL, fsl,mpc5121ads-cpld);
+ if (dn) {
+ prv-csreg = of_iomap(dn, 0);
+ of_node_put(dn);
+ if (!prv-csreg)
+ return -ENOMEM;
+
+ /* CPLD Register 9 controls NAND /CE Lines */
+ prv-csreg += 9;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+/* Control chips select signal on ADS5121 board */
+static void ads5121_select_chip(struct mtd_info *mtd, int chip)
+{
+ struct nand_chip *nand = mtd-priv;
+ struct mpc5121_nfc_prv *prv = nand-priv;
+ u8 v;
+
+ v = in_8(prv-csreg);
+ v |= 0x0F;
+
+ if (chip = 0) {
+ mpc5121_nfc_select_chip(mtd, 0);
+ v = ~(1 chip);
+ } else
+ mpc5121_nfc_select_chip(mtd, -1);
+
+ out_8(prv-csreg, v);
+}
I am just a humble beginner, but isn't this platform dependend code supposed
to be in /arch/powerpc/platforms/ ?
[...]
+static int __init mpc5121_nfc_probe(struct of_device *op,
+ const struct of_device_id *match)
+{
+ struct device_node *rootnode, *dn = op-node;
+ struct device *dev = op-dev;
+ struct mpc5121_nfc_prv *prv;
+ struct resource res;
+ struct mtd_info *mtd;
+#ifdef CONFIG_MTD_PARTITIONS
+ struct mtd_partition *parts;
+#endif
+ struct nand_chip *chip;
+ unsigned long regs_paddr, regs_size;
+ const uint *chips_no;
+ int resettime = 0;
+ int retval = 0;
+ int rev, len;
+
+ /*
+ * Check SoC revision. This driver supports only NFC
+ * in MPC5121 revision 2.
+ */
+ rev = (mfspr(SPRN_SVR) 4) 0xF;
+ if (rev != 2) {
+ printk(KERN_ERR DRV_NAME
+ : SoC revision %u is not supported!\n, rev);
+ return -ENXIO;
+ }
+
+ prv = devm_kzalloc(dev, sizeof(*prv), GFP_KERNEL);
+ if (!prv) {
+ printk(KERN_ERR DRV_NAME : Memory exhausted!\n);
+ return -ENOMEM;
+ }
+
+ mtd = prv-mtd;
+ chip = prv-chip;
+
+ mtd-priv = chip;
+ chip-priv = prv;
+
+ /* Read NFC configuration from Reset Config Word */
+ retval = mpc5121_nfc_read_hw_config(mtd);
+ if (retval) {
+ printk(KERN_ERR DRV_NAME : Unable to read NFC config!\n);
+ return retval;
+ }
+
+ prv-irq = irq_of_parse_and_map(dn, 0);
+ if (prv-irq == NO_IRQ) {
+ printk(KERN_ERR DRV_NAME : Error mapping IRQ!\n);
+ return -EINVAL;
+ }
+
+ retval = of_address_to_resource(dn, 0, res);
+ if (retval) {
+ printk(KERN_ERR DRV_NAME : Error parsing memory region!\n);
+ return retval;
+ }
+
+ chips_no = of_get_property(dn, chips, len);
+ if (!chips_no || len != sizeof(*chips_no)) {
+ printk(KERN_ERR DRV_NAME : Invalid/missing 'chips'
+ property!\n);
+ return -EINVAL;
+ }
+
+ regs_paddr = res.start;
+ regs_size = res.end - res.start + 1;
+
+ if (!devm_request_mem_region(dev, regs_paddr, regs_size, DRV_NAME)) {
+ printk(KERN_ERR DRV_NAME : Error requesting memory region!\n);
+ return -EBUSY;
+ }
+
+ prv-regs = devm_ioremap(dev, regs_paddr, regs_size);
+ if (!prv-regs) {
+ printk(KERN_ERR DRV_NAME : Error mapping memory region!\n);
+ return -ENOMEM;
+ }
+
+ mtd-name = MPC5121 NAND;
+ chip-dev_ready = mpc5121_nfc_dev_ready;
+ chip-cmdfunc = mpc5121_nfc_command;
+ chip-read_byte = mpc5121_nfc_read_byte;
+ chip-read_word = mpc5121_nfc_read_word;
+ chip-read_buf = mpc5121_nfc_read_buf;
+ chip-write_buf = mpc5121_nfc_write_buf;
+ chip-verify_buf = mpc5121_nfc_verify_buf;
+ chip-select_chip = mpc5121_nfc_select_chip;
+ chip-options = NAND_NO_AUTOINCR | NAND_USE_FLASH_BBT;
+ chip-ecc.mode = NAND_ECC_SOFT;
+
+ /* Support external chip-select logic on ADS5121 board */
+ rootnode = of_find_node_by_path(/);
+ if (of_device_is_compatible(rootnode, fsl,mpc5121ads)) {
+ retval = ads5121_chipselect_init(mtd);
+ if (retval) {
+ printk(KERN_ERR DRV_NAME : Chipselect init error!\n);
+ of_node_put(rootnode);
+ return retval;
+ }
+
+ chip-select_chip = ads5121_select_chip;
+ }
Hmmm, I guess it would be overkill to build some sort
Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
On Thursday 07 May 2009 00:29:59 Grant Likely wrote:
On Wed, May 6, 2009 at 4:01 PM, Wolfgang Denk w...@denx.de wrote:
Dear Grant,
in message fa686aa40905061333q29c263c8p24856c048e30f...@mail.gmail.com
you wrote:
...
#ifdef CONFIG_FS_ENET_HAS_FEC
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+ {
+ .compatible = fsl,mpc5121-fec,
+ .data = (void *)fs_fec_ops,
+ },
+#else
{
.compatible = fsl,pq1-fec-enet,
.data = (void *)fs_fec_ops,
},
#endif
+#endif
Hmmm. A lot of these #ifdefs in here. Does this have a multiplatform
impact? Not to mention the fact that it's just plain ugly. :-)
Agreed that it's ugly, but duplicatio9ng the code would have been even
worse. I don't think that it has multiplatform - at least not as long
as you don't ask for one image that runs on 83xx and on 512x.
Actually, I *am* asking for one image that runs on 83xx, 52xx and
521x. I already can and do build and test a single image which boots
on all my 52xx boards, on my 8349 board, and on my G4 Mac.
Cool! I also want that! We have different boards with 5200 and 5121e's and it
would be terrific if one day we'd be able to use just one kernel for all of
them!
(Sorry for being a me-too-er)
Best regards,
--
David Jander
Protonic Holland.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
Signed-off-by: Wolfgang Denk w...@denx.de Cc: Grant Likely grant.lik...@secretlab.ca Cc: John Rigby jcri...@gmail.com --- This patch is NOT intended for inclusion into mainline, but rather a request for help. For some reason which I don't understand yet, the Ethernet interface on the ARIA board does not work in the default configuration, because MII probing fails. What I'm seeing is this; the problem is with this part of code in drivers/net/fs_enet/mii-fec.c: 156 fec-mii_speed = ((ppc_proc_freq + 499) / 500) 1; ... 163 out_be32(fec-fecp-fec_mii_speed, fec-mii_speed); Just a stab in the dark: Perhaps the fec-fecp-fec_mii_speed field is misaligned or is 16 bits ? Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
On Thu, May 7, 2009 at 00:03, Roland McGrath rol...@redhat.com wrote: That is not a ptrace problem per se at all. It's an intrinsic problem with any method based on generic syscall interception, if the filtering and enforcement decisions depend on examining user memory. Yes, this is indeed the main problem that we are aware of. It can be avoided by suspending all threads during user memory inspection, but that's a horrible price to pay (also: see below for an alternative approach, that could in principle be adapted to use with ptrace) The only reason seccomp does not have this reliability problem is that its filtering is trivial and depends only on registers (in fact, only on one register, the syscall number). Simplicity is really the beauty of seccomp. It is very easy to verify that it does the right thing from a security point of view, because any attempt to call unsafe system calls results in the kernel terminating the program. This is much preferable over most ptrace solutions which is more difficult to audit for correctness. The downside is that the sandbox'd code needs to delegate execution of most of its system calls to a monitor process. This is slow and rather awkward. Although due to the magic of clone(), (almost) all system calls can in fact be serialized, sent to the monitor process, have their arguments safely inspected, and then executed on behalf of the sandbox'd process. Details are tedious but we believe they are solvable with current kernel APIs. The other issue is performance. For system calls that are known to be safe, we would rather not pay the penalty of redirecting them. A kernel patch that made seccomp more efficient for these system calls would be very welcome, and we will post such a patch for discussion shortly. If you want to do checks that depend on shared or volatile state, then syscall interception is really not the proper mechanism for you. We agree that syscall interception is a poor abstraction level for a sandbox. But in the short term, we need to work with the APIs that are available in today's kernels. And we believe that seccomp is one of the more promising API that are currently available to us. Markus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
Dear Joakim Tjernlund, In message of97606123.49b50465-onc12575af.002e2518-c12575af.002e6...@transmode.se you wrote: Just a stab in the dark: Perhaps the fec-fecp-fec_mii_speed field is misaligned or is 16 bits ? Good idea. The RM documents the register at offset 0x44 and describes it as 32 bits... and it's working fine on the MPC5121ADS board, but fails on ARIA. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, The City on the Edge of Forever, stardate unknown ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
Wolfgang Denk w...@denx.de wrote on 07/05/2009 11:19:48: Dear Joakim Tjernlund, In message of97606123.49b50465-onc12575af.002e2518-c12575af.002e6...@transmode.se you wrote: Just a stab in the dark: Perhaps the fec-fecp-fec_mii_speed field is misaligned or is 16 bits ? Good idea. The RM documents the register at offset 0x44 and describes it as 32 bits... and it's working fine on the MPC5121ADS board, but fails on ARIA. OK, this is just a guess too: Some odd byte order requirements? No more ideas, sorry. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
On Wed, May 6, 2009 at 4:41 PM, Wolfgang Denk w...@denx.de wrote:
Dear Grant,
In message fa686aa40905061529u11b231afle3b5bb10a2334...@mail.gmail.com you
wrote:
Agreed that it's ugly, but duplicatio9ng the code would have been even
worse. I don't think that it has multiplatform - at least not as long
as you don't ask for one image that runs on 83xx and on 512x.
Actually, I *am* asking for one image that runs on 83xx, 52xx and
521x. I already can and do build and test a single image which boots
on all my 52xx boards, on my 8349 board, and on my G4 Mac.
He. I was afraid you'd say that ;-)
In this case I need a helping hand as I can't figure out how to make
this work. Any suggestions?
Hmmm, it is rather ugly because the layout of fec_t is so different.
Easiest solution would be to duplicate the driver in its entirety, but
as you say it results in a lot of duplicate code. It might be the
lesser of many weevils though.
Second easiest would be to factor out all the common code in the
driver into a separate .c file that gets included by a 'wrapper' .c
file for each config which first includes the correct definition of
fec_t. This approach solves the duplicate code problem, but it also
fell out of the ugly tree and hit every branch on the way down.
ie: the wrappers would look something like this:
fs_enet_cpm1.c:
#include asm/cpm1.h
#include fs_enet_main.c
fs_enet_cpm2.c:
#include asm/cpm2.h
#include fs_enet_main.c
fs_enet_512x.c:
#include asm/mpc512x.h
#include fs_enet_main.c
And then the makefile would be something along the lines of:
obj-${CONFIG_FS_ENET_CPM1_ += fs_enet_cpm1.o
obj-${CONFIG_FS_ENET_CPM2_ += fs_enet_cpm2.o
obj-${CONFIG_FS_ENET_MPC512x_ += fs_enet_512x.o
A brief look at the driver suggests that access to the fec_t structure
is restricted to the fec-mii.c and mac-fec.c files. It might be
appropriate to duplicate just those files and do some form of
fs_enet_ops to select between them.
While on the topic, it looks to me like the driver could really use
some refactoring love. Having multiple definitions of fec_t is
confusing and potentially lead to hard to find bugs if the wrong
header gets included by anyone. I'd like to see all the fec specific
stuff in arch/powerpc/include/asm moved into drivers/net/fs_enet and
renamed to reflect the hardware it is associate with. Stuff like
fec_t is far to generic, not to mention that typedefs are
discouraged now.
Regardless, I feel your pain. It is not a pretty situation.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix oprofile sampling of marked events on POWER7
From: Maynard Johnson mayna...@us.ibm.com
Description
---
Change ppc64 oprofile kernel driver to use the SLOT bits (MMCRA[37:39]only on
older processors where those bits are defined.
Background
--
The performance monitor unit of the 64-bit POWER processor family has the
ability to collect accurate instruction-level samples when profiling on marked
events (i.e., PM_MRK_event-name). In processors prior to POWER6, the MMCRA
register contained slot information that the oprofile kernel driver used to
adjust the value latched in the SIAR at the time of a PMU interrupt. But as of
POWER6, these slot bits in MMCRA are no longer necessary for oprofile to use,
since the SIAR itself holds the accurate sampled instruction address. With
POWER6, these MMCRA slot bits were zero'ed out by hardware so oprofile's use of
these slot bits was, in effect, a NOP. But with POWER7, these bits are no
longer zero'ed out; however, they serve some other purpose rather than slot
information. Thus, using these bits on POWER7 to adjust the SIAR value results
in samples being attributed to the wrong instructions. The attached patch
changes the oprofile kernel driver to ignore these slot bits on all newer
processors starting with POWER6.
Signed-off-by: Maynard Johnson mayna...@us.ibm.com
Signed-off-by: Michael Wolf m...@linux.vnet.ibm.com
---
diff -paur linux/arch/powerpc/oprofile/op_model_power4.c
linux-p7-oprofile-patch//arch/powerpc/oprofile/op_model_power4.c
--- linux/arch/powerpc/oprofile/op_model_power4.c 2009-05-01
08:20:21.0 -0500
+++ linux-p7-oprofile-patch//arch/powerpc/oprofile/op_model_power4.c
2009-05-01 08:20:05.0 -0500
@@ -26,6 +26,7 @@
static unsigned long reset_value[OP_MAX_COUNTER];
static int oprofile_running;
+static int use_slot_nums;
/* mmcr values are set in power4_reg_setup, used in power4_cpu_setup */
static u32 mmcr0_val;
@@ -61,6 +62,12 @@ static int power4_reg_setup(struct op_co
else
mmcr0_val |= MMCR0_PROBLEM_DISABLE;
+ if (__is_processor(PV_POWER4) || __is_processor(PV_POWER4p) ||
+ __is_processor(PV_970) || __is_processor(PV_970FX) ||
+ __is_processor(PV_970MP) || __is_processor(PV_970GX) ||
+ __is_processor(PV_POWER5) || __is_processor(PV_POWER5p))
+ use_slot_nums = 1;
+
return 0;
}
@@ -206,7 +213,7 @@ static unsigned long get_pc(struct pt_re
mmcra = mfspr(SPRN_MMCRA);
- if (mmcra MMCRA_SAMPLE_ENABLE) {
+ if (use_slot_nums (mmcra MMCRA_SAMPLE_ENABLE)) {
slot = ((mmcra MMCRA_SLOT) MMCRA_SLOT_SHIFT);
if (slot 1)
pc += 4 * (slot - 1);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] 83xx: add support for the kmeter1 board.
Hello all,
(FYI I working on the kmeter1)
kmeter1.c reuses the same QE_ENET10 RGMII errata workaround code from
mpc836x_mds.c (MPC8360EMDS eval board).
In my view errata nodes in the dts is overkill. Maybe the errata code can go
into a reusable function somewhere in 83xx/ or in ucc_geth.c?
I also think the original errata code needs improving:
- mask some SVR bits so activated for all matching CPU models, e.g.
MPC8360 MPC8360E.
- The code in mpc836x_mds.c and kmeter1.c does not do exactly what
Freescale errata says!
Here the errata document:
http://www.freescale.com/files/32bit/doc/errata/MPC8360ECE.pdf
Because kmeter1 is using an MPC8360 CPU model the workaround doesn't actually
trigger. So to kill 2 birds with 1 stone we tested a Uboot patch (below) doing
what QE_ENET10 says. It seemed to work fine for us.
/* RGMII timing Errata workaround for rev 2.1 silicon
* (ref: MPC8360ECE rev.1 12/2007 QE_ENET10 UCC2 option 1)
*/
void *reg = (void *)(CONFIG_SYS_IMMR + 0x14ac);
clrsetbits_be32 (reg, 0x00F0, 0x00A0);
From my point of view:
- The workaround code in kmeter1.c could go for now.
- An improved errata workaround for 836x boards would be nice (..who is
motivated? :-))
Best regards
Christopher Varlese
RD Software
KEYMILE AG
Schwarzenburgstrasse 73
3097 Bern, Switzerland
www.keymile.com
-Original Message-
From: linuxppc-dev-bounces+christopher.varlese=keymile@ozlabs.org
[mailto:linuxppc-dev-bounces+christopher.varlese=keymile@ozlabs.org] On
Behalf Of Heiko Schocher
Sent: Monday, April 27, 2009 7:39 AM
To: Kumar Gala
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] 83xx: add support for the kmeter1 board.
Hello Kumar,
Kumar Gala wrote:
[...]
diff --git a/arch/powerpc/platforms/83xx/kmeter1.c
b/arch/powerpc/platforms/83xx/kmeter1.c
new file mode 100644
index 000..99cf5c6
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/kmeter1.c
@@ -0,0 +1,170 @@
+/*
[...]
+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.
What if we do something like the following:
1) add in the soc node an errata node and in this errata node
we can add all CPU specific errata as an example the qe_enet10
errata, which above code covers:
soc8...@e000 {
[...]
errata {
device_type = errata;
compatible = fsl,mpc83xx_errata;
#address-cells = 1;
#size-cells = 1;
qe_ene...@14a8 {
device_type = errata;
compatible = fsl,mpc83xx_errata_qe_enet10;
reg = 0x14a8 0x08;
};
};
[...]
};
2) we add in arch/powerpc/sysdev/fsl_soc.c a
static int __init mpc83xx_errata_init(void)
function, which holds the code for the errata
If you agree with that, I can make a patch ...
Hmm.. Is it OK, if I first sent a v2 of the 83xx: add support for
the kmeter1 board. with the QE_ENET10 errata in kmeter1.c (as it is
also for the mpc836x_mds board), and then send a seperate patch, which
removes this errata from the two boards?
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
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
Re: MPC5121 new board constantly resetting after u-boot passes control to Linux
Dear Damien, in message c788c1220905070143t5271ebe1ra12df43f8f53e...@mail.gmail.com you wrote: We are attempting to bring up a new MPC5121e board, somewhat based on the Silicon Turnkey's ADS5121 development board. We are using a kernel and u-boot based on Freescale/STx's board support package. I recommend to use current code - tip of tree in U-Boot (although I have a long stack of patches in the queue - wait for the weekend) and Linux (use mainline aka kernel.org plus the patches I just posted for a start). We have successfully modified u-boot for the 64MB of DDR2 RAM, and we can use u-boot's (and the BDI's) memory test facility to check that the RAM is working. Let's say, it is *basicly* working. Note that these memory tests don't stress-test the bus; for example, they do not stress-test any burst-mode accesses. See the FAQ: http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation My bet is you got a memory initialization error. At this point, the board immediately resets. There is no hint of life from the kernel from the console, although setting a breakpoint on the BDI at 0x000 and tracing through appears as though some code (although we don't know what) is being executed. Why don't you know which code this is? GDB will tell you. Did you try the standard methods, like post-mortem dump of the log buffer area, etc.? See the FAQ for details. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I think there's a world market for about five computers. -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Trouble using with Kegel cross tool chain
+ echo 'SRC_DIR not set, so source tarballs will be unpacked in the build dir ectory' SRC_DIR not set, so source tarballs will be unpacked in the build directory + case x$PREFIX in + case x$USER in + abort 'Don'\''t run all.sh or crosstool.sh as root, it'\''s dangerous' + echo 'Don'\''t' run all.sh or crosstool.sh as root, 'it'\''s' dangerous Don't run all.sh or crosstool.sh as root, it's dangerous + exec false Are you running as root? If so, don't. Mikey Ah, now it's doing something... Thanks Mikey. I didn't think running as root would prevent the process from running. Everything is running in VirtualBox so I wasn't concerned about blowing things up. The build has been in progress for the past 15 minutes... I set the target as powerpc-603. Is this appropriate for the MPC8313? Thank you. Chris Plasun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Trouble using with Kegel cross tool chain
Hi Wolfgang, Trouble using with Kegel cross tool chain Wolfgang Denk wd at denx.de Thu May 7 15:32:36 EST 2009 * Previous message: Trouble using with Kegel cross tool chain * Next message: Trouble using with Kegel cross tool chain * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Dear Chris, In message 407093.53240.qm at web58102.mail.re3.yahoo.com you wrote: I'm getting a bit desperate trying to build a gcc / glibc cross-toolchainfor use on a Freescale MPC8313 but am having problems. Try using ELDK (see http://www.denx.de/wiki/view/DULG/ELDK resp. ftp://ftp.denx.de/pub/eldk/4.2/); it's based on crosstool but has these issues already solved for you. Best regards, Wolfgang Denk Is Denx your site? I poured over it for U-Boot. I will take a look at this tool. Danke schoen! Chris Plasun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/iseries; fix pci breakage
Hi Ben, On Thu, 7 May 2009 10:07:52 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: This is a regression in v2.6.29 from v2.6.28, so I guess we need to send this to the stable team (backported if necessary) after it is upstream. This same patch applies to 2.6.29.2 and fixes the problem there. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpywCZhm6NTk.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC8247 booting error
thanks for Scott's following
You need to pass your physical address (0xd000) to ioremap() to
obtain a virtual address that you can dereference.
actually, i have done that like you said. pass my phy addr to a virtual
addr, but i suppose it is a kernel virtual addr. i wanna get data from phy
in my application of user space. i try it by copy_to_user transfer a kernel
virtual addr to a use virtual addr for using by user. but copy_to_user
failed...
i do it like this
ssize_t read(,char *buf,,)
{
kernel_buf = (void *)ioremap(0xD000, 4096);
copy_to_user(buf, kernel_buf, 4096);
}
--
View this message in context:
http://www.nabble.com/PPC8247-booting-error-tp23381214p23438722.html
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
Re: [PATCH 08/12] mpc5121: Added I2C support.
On Thu, May 7, 2009 at 8:12 PM, John Rigby jcri...@gmail.com wrote: Ok, the interrupt enabling should happen in the driver. Should it key off compatible or should a new property be added like the existing 5200 clocking property? key off compatible. And the 5200 clocking property has been depreciated. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 06/12] mpc5121: Added NAND Flash Controller driver.
On Thu, May 7, 2009 at 8:22 PM, John Rigby jcri...@gmail.com wrote:
On Wed, May 6, 2009 at 2:59 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index d8cd579..7135d89 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -71,6 +71,7 @@ void __init mpc512x_init_IRQ(void)
static struct of_device_id __initdata of_bus_ids[] = {
{ .compatible = fsl,mpc5121-immr, },
{ .compatible = fsl,mpc5121-localbus, },
+ { .compatible = fsl,mpc5121-nfc, },
This doesn't look right. Shouldn't the NAND controller be hanging of
the IMMR node?
I just wanted to confirm that NFC is in its own memory space. It has its
own mapping and is not part of the IMMR space.
Hmmm... I wonder then if it might be better to have an IPB node, and
hang all the IPB connected nodes off of it.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
Wolfgang,
Welcome to my world and why I gave up on this months ago.
Everyone else,
One thing to consider here is a rewrite with the goal of a new improved fec
driver that would work on both 5121 and the various mx platforms that also
have this same fec core.
Also don't forget that the register map is the same on 512x, mx and coldfire
platforms but not on the other ppc platforms so if you want to one binary to
rule them all you will need to have an offest table or some such.
John
On Thu, May 7, 2009 at 8:09 AM, Grant Likely grant.lik...@secretlab.cawrote:
On Wed, May 6, 2009 at 4:41 PM, Wolfgang Denk w...@denx.de wrote:
Dear Grant,
In message fa686aa40905061529u11b231afle3b5bb10a2334...@mail.gmail.com
you wrote:
Agreed that it's ugly, but duplicatio9ng the code would have been even
worse. I don't think that it has multiplatform - at least not as long
as you don't ask for one image that runs on 83xx and on 512x.
Actually, I *am* asking for one image that runs on 83xx, 52xx and
521x. I already can and do build and test a single image which boots
on all my 52xx boards, on my 8349 board, and on my G4 Mac.
He. I was afraid you'd say that ;-)
In this case I need a helping hand as I can't figure out how to make
this work. Any suggestions?
Hmmm, it is rather ugly because the layout of fec_t is so different.
Easiest solution would be to duplicate the driver in its entirety, but
as you say it results in a lot of duplicate code. It might be the
lesser of many weevils though.
Second easiest would be to factor out all the common code in the
driver into a separate .c file that gets included by a 'wrapper' .c
file for each config which first includes the correct definition of
fec_t. This approach solves the duplicate code problem, but it also
fell out of the ugly tree and hit every branch on the way down.
ie: the wrappers would look something like this:
fs_enet_cpm1.c:
#include asm/cpm1.h
#include fs_enet_main.c
fs_enet_cpm2.c:
#include asm/cpm2.h
#include fs_enet_main.c
fs_enet_512x.c:
#include asm/mpc512x.h
#include fs_enet_main.c
And then the makefile would be something along the lines of:
obj-${CONFIG_FS_ENET_CPM1_ += fs_enet_cpm1.o
obj-${CONFIG_FS_ENET_CPM2_ += fs_enet_cpm2.o
obj-${CONFIG_FS_ENET_MPC512x_ += fs_enet_512x.o
A brief look at the driver suggests that access to the fec_t structure
is restricted to the fec-mii.c and mac-fec.c files. It might be
appropriate to duplicate just those files and do some form of
fs_enet_ops to select between them.
While on the topic, it looks to me like the driver could really use
some refactoring love. Having multiple definitions of fec_t is
confusing and potentially lead to hard to find bugs if the wrong
header gets included by anyone. I'd like to see all the fec specific
stuff in arch/powerpc/include/asm moved into drivers/net/fs_enet and
renamed to reflect the hardware it is associate with. Stuff like
fec_t is far to generic, not to mention that typedefs are
discouraged now.
Regardless, I feel your pain. It is not a pretty situation.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
I think the fec's parent clock is the ipb clock not the ppc core clock. Could that be the problem? On Wed, May 6, 2009 at 2:21 PM, Wolfgang Denk w...@denx.de wrote: Signed-off-by: Wolfgang Denk w...@denx.de Cc: Grant Likely grant.lik...@secretlab.ca Cc: John Rigby jcri...@gmail.com --- This patch is NOT intended for inclusion into mainline, but rather a request for help. For some reason which I don't understand yet, the Ethernet interface on the ARIA board does not work in the default configuration, because MII probing fails. What I'm seeing is this; the problem is with this part of code in drivers/net/fs_enet/mii-fec.c: 156 fec-mii_speed = ((ppc_proc_freq + 499) / 500) 1; ... 163 out_be32(fec-fecp-fec_mii_speed, fec-mii_speed); I added some debug messages, and this is what I see: On the ADS5121, we have the CPU clocked at 400 MHz. I get: ... ## ppc_proc_freq = 39996, fec-mii_speed = 160 FEC MII Bus: probed ... It works fine. According to the Ref. Man.: A value of 0 in this field turns off the MDC and leaves it in a low-voltage state. Any non-zero value results in the MDC frequency of 1/(mii_speed*2) of the system clock frequency. that means we have a MDC frequency of 400 MHz / (2 * 160) = 1.25 MHz which is obviously within the 2.5 MHz limit. Now ARIA is currently running at 316.8 MHz, and this is what I get: ... ## ppc_proc_freq = 31680, fec-mii_speed = 128 fsl-fec-mdio: probe of 80002800.mdio failed with error -5 ... It fails. MDC frequency is 316.8 MHz / (2 * 128) = 1.24 MHz which should be fine. However, If I change the code to fec-mii_speed = (((ppc_proc_freq / 100) / 30) + 1) 1; then I get: ... ## ppc_proc_freq = 31680, fec-mii_speed = 22 FEC MII Bus: probed ... and it's working!!! However, I compute MDC frequency as 316.8 MHz / (2 * 22) = 7.2 MHz which is far above the maximum allowed clock of 2.5 MHz ??? Has anybody any idea what might be going on here? drivers/net/fs_enet/mii-fec.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c index 9d8bd97..a51dd83 100644 --- a/drivers/net/fs_enet/mii-fec.c +++ b/drivers/net/fs_enet/mii-fec.c @@ -153,8 +153,12 @@ static int __devinit fs_enet_mdio_probe(struct of_device *ofdev, if (!fec-fecp) goto out_fec; +#if 0 fec-mii_speed = ((ppc_proc_freq + 499) / 500) 1; - +#else + fec-mii_speed = (((ppc_proc_freq / 100) / 30) + 1) 1; + printk(## ppc_proc_freq = %d, fec-mii_speed = %d\n, ppc_proc_freq, fec-mii_speed); +#endif setbits32(fec-fecp-fec_r_cntrl, FEC_RCNTRL_MII_MODE); setbits32(fec-fecp-fec_ecntrl, FEC_ECNTRL_PINMUX | FEC_ECNTRL_ETHER_EN); -- 1.6.0.6 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/12] mpc5121: Added I2C support.
Ok, the interrupt enabling should happen in the driver. Should it key off compatible or should a new property be added like the existing 5200 clocking property? On Wed, May 6, 2009 at 8:41 PM, Grant Likely grant.lik...@secretlab.cawrote: On Wed, May 6, 2009 at 4:51 PM, Grant Likely grant.lik...@secretlab.ca wrote: On Wed, May 6, 2009 at 4:19 PM, Wolfgang Denk w...@denx.de wrote: Dear Grant Likely, In message fa686aa40905061401k319313c5q89fd3e245c308...@mail.gmail.com you wrote: On Wed, May 6, 2009 at 2:15 PM, Wolfgang Denk w...@denx.de wrote: From: Piotr Ziecik ko...@semihalf.com - Enabled I2C interrupts on MPC5121. - Updated Kconfig for i2c-mpc driver. I think this workaround belongs in the driver itself. Sorry, I don't get it. Which workaround? What exactly should I change? Sorry, I misread the patch. Never mind. Actually, on 3rd reading, I think my first impression was correct (even if I was wrong about it being a workaround). This code in mpc512x_init_i2c() is only relevant for i2c busses (it isn't shared with any other drivers). Therefore, it belongs with the i2c bus itself. It does not belong in platform code. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 06/12] mpc5121: Added NAND Flash Controller driver.
On Wed, May 6, 2009 at 2:59 PM, Grant Likely grant.lik...@secretlab.cawrote:
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index d8cd579..7135d89 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -71,6 +71,7 @@ void __init mpc512x_init_IRQ(void)
static struct of_device_id __initdata of_bus_ids[] = {
{ .compatible = fsl,mpc5121-immr, },
{ .compatible = fsl,mpc5121-localbus, },
+ { .compatible = fsl,mpc5121-nfc, },
This doesn't look right. Shouldn't the NAND controller be hanging of
the IMMR node?
I just wanted to confirm that NFC is in its own memory space. It has its
own mapping and is not part of the IMMR space.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 03/12] fs_enet: Add FEC TX Alignment workaround for MPC5121.
I was having deja-vu with this and realized that I have fixed at least some of the objections to this patch. Wolfgang you may want to look at the patch in my 5121 git tree here: http://git.denx.de/?p=linux-mpc512x.git;a=commit;h=2950be3be42af7449941c3340998c27ef918f10f It does runtime tx packet alignment It also has fewer ifdefs and trys to share more code. It also has a header that explains everything including that fact that there is not a runtime conflict sine the only other ppc that has fec is 8xx which is not in the same family. On Wed, May 6, 2009 at 4:42 PM, Grant Likely grant.lik...@secretlab.cawrote: On Wed, May 6, 2009 at 4:12 PM, Wolfgang Denk w...@denx.de wrote: Dear Grant Likely, In message fa686aa40905061337w6aa82f5aj787618ba108e5...@mail.gmail.com you wrote: The FEC on 5121 has problems with misaligned tx buffers. The RM says any alignment is ok but empirical results show that packet buffers ending in 0x1E will sometimes hang the FEC. Other bad alignment does not hang but will cause silent TX failures resulting in about a 1% packet loss as tested by ping -f from a remote host. This patch is a work around that copies every tx packet to an aligned skb before sending. OUCH! Yes :-( +#else +#define tx_skb_align_workaround(dev, skb) (skb) +#endif Another use of #ifdef blocks. What is the multiplatform impact? Hm... Can you recommend a better way to solve the problem? Suggestions are welcome. I'd rather see a runtime selectable workaround. ie. enable it based on the compatible property. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH 10/12] mpc5121: Add MPC5121 Real time clock driver.
Can we get 5121 support in and add 5200 support later? They are not identical. On Wed, May 6, 2009 at 4:40 PM, Grant Likely grant.lik...@secretlab.cawrote: On Wed, May 6, 2009 at 3:06 PM, Wolfram Sang w.s...@pengutronix.de wrote: On Wed, May 06, 2009 at 10:15:17PM +0200, Wolfgang Denk wrote: From: John Rigby jri...@freescale.com Based on Domen Puncer's rtc driver for 5200 posted to the ppclinux mailing list: http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11675 but never commited anywhere. Changes to Domen's original: Changed filenames/routine names from mpc5200* to mpc5121* Why not changing it to mpc5xxx? From a glimpse, it should still work on MPC5200, too. If this is true, the I heartily agree with Wolfram. :-) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --~--~-~--~~~---~--~~ You received this message because you are subscribed to rtc-linux. Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. -~--~~~~--~~--~--~--- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 11/12] mpc5121: Added MPC512x DMA driver.
On Wed, May 6, 2009 at 3:07 PM, Grant Likely grant.lik...@secretlab.cawrote:
On Wed, May 6, 2009 at 2:15 PM, Wolfgang Denk w...@denx.de wrote:
From: Piotr Ziecik ko...@semihalf.com
This patch adds initial version of MPC512x DMA driver.
Only memory to memory transfers are currenly supported.
Signed-off-by: Piotr Ziecik ko...@semihalf.com
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: John Rigby jcri...@gmail.com
Don't have time to review this in detail right now, but three quick
comments:
drivers/dma/mpc512x_dma.c| 642
++
drivers/dma/mpc512x_dma.h| 192
It looks to me like these two files should be merged.
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts
b/arch/powerpc/boot/dts/mpc5121ads.dts
index c2d9de9..e7f0e09 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -373,7 +373,7 @@
};
d...@14000 {
- compatible = fsl,mpc5121-dma2;
+ compatible = fsl,mpc512x-dma;
Nack. Compatible values should not use wildcards. Be specific. And
be specific about what it is compatible to if another part implements
the same device.
The internal name for the dma module was dma2 that is where the orginal name
came from. There is a dma2 in some 8xxx but last I looked it is not at all
the same. I would vote for fsl,mpc5121-dma.
reg = 0x14000 0x1800;
interrupts = 65 0x8;
interrupt-parent = ipic ;
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index b776e45..135fd6b 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -95,6 +95,7 @@ void __init mpc512x_init_i2c(void)
static struct of_device_id __initdata of_bus_ids[] = {
{ .compatible = fsl,mpc5121-immr, },
{ .compatible = fsl,mpc5121-localbus, },
+ { .compatible = fsl,mpc5121-dma, },
This doesn't look right either. Shouldn't the dma device hang off the
IMMR node?
Yes dma is part of IMMR.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 83xx: add support for the kmeter1 board.
Hello Christopher, Varlese, Christopher wrote: (FYI I working on the kmeter1) kmeter1.c reuses the same QE_ENET10 RGMII errata workaround code from mpc836x_mds.c (MPC8360EMDS eval board). In my view errata nodes in the dts is overkill. Maybe the errata code can go into a reusable function somewhere in 83xx/ or in ucc_geth.c? To put an errata node in the dts was just an idea ;-) I also mentioned putting this code in the ucc_geth.c driver ... I also think the original errata code needs improving: - mask some SVR bits so activated for all matching CPU models, e.g. MPC8360 MPC8360E. Did a first try in my v2 patch, see: http://ozlabs.org/pipermail/linuxppc-dev/2009-April/071384.html but I got no response yet. - The code in mpc836x_mds.c and kmeter1.c does not do exactly what Freescale errata says! :-( Here the errata document: http://www.freescale.com/files/32bit/doc/errata/MPC8360ECE.pdf Because kmeter1 is using an MPC8360 CPU model the workaround doesn't actually trigger. So to kill 2 birds with 1 stone we tested a Uboot patch (below) doing what QE_ENET10 says. It seemed to work fine for us. /* RGMII timing Errata workaround for rev 2.1 silicon * (ref: MPC8360ECE rev.1 12/2007 QE_ENET10 UCC2 option 1) */ void *reg = (void *)(CONFIG_SYS_IMMR + 0x14ac); clrsetbits_be32 (reg, 0x00F0, 0x00A0); From my point of view: - The workaround code in kmeter1.c could go for now. - An improved errata workaround for 836x boards would be nice (..who is motivated? :-)) I can make this errata, if someone gives advice, where to put ... I vote for putting it into the ucc_geth.c driver, and activating it maybe through the phy-connection-type if it activates the rgmii mode ... ? bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
