Re: [PATCH v2] Parameterize EMAC Multicast Match Handling
Stefan and/or Ben: Any thoughts on this? I was hesitating a bit... do we really need to be -that- flexible ? That is, either that or use some new compatible entry to detect the new reg layout and whack that as a feature bit instead ? The advantage of the later is that we have the possibility of doing conditional compile for kernels that support only a given processor or set of processors (not that we have implemented much of it, but it just becomes Kconfig mumbo jumbo and a little bit of defines in the .h by turning the feature test into a compile-time 0 or 1. But this isn't a hot path and not a lot of code so maybe not worth bothering... however, it does add 3 properties to the DT and I know embedded people (especially Xilinx) are a bit concerned about the size of the DT when they try to fit it in block RAM... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'.
On Fri, 2008-06-06 at 09:16 -0700, Stephen Neuendorffer wrote: legacy_serial identifies a valid ns16550 on a simple-bus, but the legacy_serial driver doesn't understand the shift and offset flags necessary to get it to work, which results in no console. I think the easiest solution is to change the Kconfig so that PPC_UDBG_16550 is only selected based on !XILINX_VIRTEX. I've done this in my tree, but I've been swamped with other things at the moment, so I haven't verified it. Or is legacy_serial just legacy at this point and can go away entirely? I got the impression from some of the earlier discussion that it wasn't preferred, at least No, legacy serial is useful. Just grow it an understanding of the shift offset bits :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][RESEND] powerpc: Add 82xx/83xx/86xx to 6xx Multiplatform
On Tuesday 01 July 2008, Kumar Gala wrote: There isn't any reason at this point that we can't build 82xx, 83xx 86xx support in with the other 6xx based boards. Twiddle the Kconfigs to allow this. This allows us to remove the machine type selection for related to 6xx. Signed-off-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] Thanks for doing this now. I had sent a similar patch last year when there were still bugs in the source preventing it from working, but now it all looks good. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fixup lwsync at runtime
On Tue, 2008-07-01 at 00:32 -0500, Kumar Gala wrote:
To allow for a single kernel image on e500 v1/v2/mc we need to fixup lwsync
at runtime. On e500v1/v2 lwsync causes an illop so we need to patch up
the code. We default to 'sync' since that is always safe and if the cpu
is capable we will replace 'sync' with 'lwsync'.
We introduce CPU_FTR_LWSYNC as a way to determine at runtime if this is
needed. This flag could be moved elsewhere since we dont really use it
for the normal CPU_FTR purpose.
Finally we only store the relative offset in the fixup section to keep it
as small as possible rather than using a full fixup_entry.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
I'd rather have some more generic alternatives stuff but in the
meantime, Ack.
---
Rebased against latest powerpc-next tree.
- k
arch/powerpc/kernel/module.c|6 ++
arch/powerpc/kernel/setup_32.c |4
arch/powerpc/kernel/setup_64.c |2 ++
arch/powerpc/kernel/vdso.c | 10 ++
arch/powerpc/kernel/vdso32/vdso32.lds.S |3 +++
arch/powerpc/kernel/vdso64/vdso64.lds.S |3 +++
arch/powerpc/kernel/vmlinux.lds.S |6 ++
arch/powerpc/lib/feature-fixups.c | 16
include/asm-powerpc/code-patching.h |3 ++-
include/asm-powerpc/cputable.h | 21 +++--
include/asm-powerpc/synch.h | 27 ++-
11 files changed, 85 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index 40dd52d..af07003 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -86,6 +86,12 @@ int module_finalize(const Elf_Ehdr *hdr,
(void *)sect-sh_addr + sect-sh_size);
#endif
+ sect = find_section(hdr, sechdrs, __lwsync_fixup);
+ if (sect != NULL)
+ do_lwsync_fixups(cur_cpu_spec-cpu_features,
+ (void *)sect-sh_addr,
+ (void *)sect-sh_addr + sect-sh_size);
+
return 0;
}
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 9e83add..0109e7f 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -101,6 +101,10 @@ unsigned long __init early_init(unsigned long dt_ptr)
PTRRELOC(__start___ftr_fixup),
PTRRELOC(__stop___ftr_fixup));
+ do_lwsync_fixups(spec-cpu_features,
+ PTRRELOC(__start___lwsync_fixup),
+ PTRRELOC(__stop___lwsync_fixup));
+
return KERNELBASE + offset;
}
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 098fd96..04d8de9 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -363,6 +363,8 @@ void __init setup_system(void)
__start___ftr_fixup, __stop___ftr_fixup);
do_feature_fixups(powerpc_firmware_features,
__start___fw_ftr_fixup, __stop___fw_ftr_fixup);
+ do_lwsync_fixups(cur_cpu_spec-cpu_features,
+ __start___lwsync_fixup, __stop___lwsync_fixup);
/*
* Unflatten the device-tree passed by prom_init or kexec
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index ce245a8..f177c60 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -571,6 +571,11 @@ static __init int vdso_fixup_features(struct
lib32_elfinfo *v32,
if (start64)
do_feature_fixups(powerpc_firmware_features,
start64, start64 + size64);
+
+ start64 = find_section64(v64-hdr, __lwsync_fixup, size64);
+ if (start64)
+ do_lwsync_fixups(cur_cpu_spec-cpu_features,
+ start64, start64 + size64);
#endif /* CONFIG_PPC64 */
start32 = find_section32(v32-hdr, __ftr_fixup, size32);
@@ -585,6 +590,11 @@ static __init int vdso_fixup_features(struct
lib32_elfinfo *v32,
start32, start32 + size32);
#endif /* CONFIG_PPC64 */
+ start32 = find_section32(v32-hdr, __lwsync_fixup, size32);
+ if (start32)
+ do_lwsync_fixups(cur_cpu_spec-cpu_features,
+ start32, start32 + size32);
+
return 0;
}
diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S
b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index 2717935..be3b6a4 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -33,6 +33,9 @@ SECTIONS
. = ALIGN(8);
__ftr_fixup : { *(__ftr_fixup) }
+ . = ALIGN(8);
+ __lwsync_fixup : { *(__lwsync_fixup) }
+
#ifdef CONFIG_PPC64
. = ALIGN(8);
__fw_ftr_fixup : { *(__fw_ftr_fixup) }
diff --git
RE: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
As for the copyright, I haven't been able to find much information on whether or not generated files are even copyrightable. One might argue that they don't have sufficient 'creative value' to be copyrightable. Or arguably, they are as copyrightable by the generator author as by the author or the .mhs file. I admit in this case, I've followed the safe route by claiming a copyright, which at least at Xilinx has significant precedent. Also, thinking about your idea of sticking bits in BRAM etc... what would be nice would be the ability to merge trees. We've been talking about that multiple times, it would be useful at several levels: - We could provide pre-made DTs for known CPUs (ie, 440GP, 440GX, 405EX, ...) - Boards can then include that, and then override some properties (clocks, PHY wiring, ...) - That could be done at the binary level too so that the BRAM contains on overlay on top of the base ref. platform device-tree that comes with the kernel for example. This is slightly different between doing that in the .dts source via some kind of #include vs. doing that by merging blobs but we could make it be essentially be the same internally: The #include generates a blob that is then merged in. Just random thoughts... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fixup lwsync at runtime
On Tue, 2008-07-01 at 00:32 -0500, Kumar Gala wrote:
To allow for a single kernel image on e500 v1/v2/mc we need to fixup lwsync
at runtime. On e500v1/v2 lwsync causes an illop so we need to patch up
the code. We default to 'sync' since that is always safe and if the cpu
is capable we will replace 'sync' with 'lwsync'.
We introduce CPU_FTR_LWSYNC as a way to determine at runtime if this is
needed. This flag could be moved elsewhere since we dont really use it
for the normal CPU_FTR purpose.
Finally we only store the relative offset in the fixup section to keep it
as small as possible rather than using a full fixup_entry.
How many entries are we talking? I guess it's not much bother to have a
separate section.
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 9e83add..0109e7f 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -101,6 +101,10 @@ unsigned long __init early_init(unsigned long dt_ptr)
PTRRELOC(__start___ftr_fixup),
PTRRELOC(__stop___ftr_fixup));
+ do_lwsync_fixups(spec-cpu_features,
+ PTRRELOC(__start___lwsync_fixup),
+ PTRRELOC(__stop___lwsync_fixup));
+
This could be changed to use cur_cpu_spec-cpu_features, and then all
the call sites would be passing that, which would mean
do_lwsync_fixups() could just check cur_cpu_spec-cpu_features directly.
diff --git a/arch/powerpc/lib/feature-fixups.c
b/arch/powerpc/lib/feature-fixups.c
index 48e1ed8..ac5f5a1 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -110,6 +110,22 @@ void do_feature_fixups(unsigned long value, void
*fixup_start, void *fixup_end)
}
}
+void do_lwsync_fixups(unsigned long value, void *fixup_start, void
*fixup_end)
+{
+ unsigned int *start, *end, *dest;
+
+ if (!(value CPU_FTR_LWSYNC))
+ return ;
+
+ start = fixup_start;
+ end = fixup_end;
+
+ for (; start end; start++) {
+ dest = (void *)start + *start;
+ patch_instruction(dest, PPC_LWSYNC_INSTR);
+ }
+}
+
#ifdef CONFIG_FTR_FIXUP_SELFTEST
...
No tests? :)
diff --git a/include/asm-powerpc/synch.h b/include/asm-powerpc/synch.h
index 42a1ef5..4737c61 100644
--- a/include/asm-powerpc/synch.h
+++ b/include/asm-powerpc/synch.h
@@ -3,20 +3,37 @@
#ifdef __KERNEL__
#include linux/stringify.h
+#include asm/feature-fixups.h
-#if defined(__powerpc64__) || defined(CONFIG_PPC_E500MC)
-#define __SUBARCH_HAS_LWSYNC
-#endif
+#ifndef __ASSEMBLY__
+extern unsigned int __start___lwsync_fixup, __stop___lwsync_fixup;
+extern void do_lwsync_fixups(unsigned long value, void *fixup_start,
+ void *fixup_end);
+#endif /* __ASSEMBLY__ */
+
+#define START_LWSYNC_SECTION(label) label##1:
+#define MAKE_LWSYNC_SECTION_ENTRY(label, sect) \
+label##4:\
+ .pushsection sect,a; \
+ .align 2; \
+label##5:\
+ .long label##1b-label##5b; \
+ .popsection;
I'd rather this was in feature-fixups.h, seeing as I just moved all the
feature-fixup related macros in there :)
It might make more sense to use label##2 and label##3.
-#ifdef __SUBARCH_HAS_LWSYNC
+#if defined(__powerpc64__)
#define LWSYNC lwsync
+#elif defined(CONFIG_E500)
+#define LWSYNC \
+ START_LWSYNC_SECTION(97); \
+ sync; \
+ MAKE_LWSYNC_SECTION_ENTRY(97, __lwsync_fixup);
#else
#define LWSYNC sync
#endif
Using 97 means you can't nest an LWSYNC inside a feature or firmware
feature section, if you use say 96 then nesting should work.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Parameterize EMAC Multicast Match Handling
On Tuesday 01 July 2008, Benjamin Herrenschmidt wrote: Stefan and/or Ben: Any thoughts on this? I was hesitating a bit... do we really need to be -that- flexible ? That is, either that or use some new compatible entry to detect the new reg layout and whack that as a feature bit instead ? The advantage of the later is that we have the possibility of doing conditional compile for kernels that support only a given processor or set of processors (not that we have implemented much of it, but it just becomes Kconfig mumbo jumbo and a little bit of defines in the .h by turning the feature test into a compile-time 0 or 1. But this isn't a hot path and not a lot of code so maybe not worth bothering... however, it does add 3 properties to the DT and I know embedded people (especially Xilinx) are a bit concerned about the size of the DT when they try to fit it in block RAM... Yes, this was my feeling too. Not the size of the dtb but more the increased complexity of the EMAC device node. I would prefer Ben's idea with this new compatible entry too. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: manual merge of the powerpc tree
Hi Paul, Today's linux-next merge of the powerpc tree got a conflict in drivers/macintosh/mediabay.c between commit 3fdba626506365e3aaf49140632120cd9156c2e8 (ide-pmac: media-bay support fixes (take 3)) from the ide tree and commit 9a24729d8aeef967eac7af71c6a69edc83d06558 (macintosh/media bay: Convert semaphore to mutex) from the powerpc tree. I used the version from the ide tree but with the down/up - mutex_lock/mutex_unlock changes applied. It may be worth a check to make sure I got it right. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpzjvbx89bEb.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix compile warning in init_thread
arch/powerpc/kernel/init_task.c:33: warning: missing braces around initializer
arch/powerpc/kernel/init_task.c:33: warning: (near initialization for
'init_task.thread.fpr[0]')
Noticed by SFR.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
include/asm-powerpc/processor.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6-ozlabs/include/asm-powerpc/processor.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/processor.h
+++ linux-2.6-ozlabs/include/asm-powerpc/processor.h
@@ -222,7 +222,7 @@ struct thread_struct {
.ksp_limit = INIT_SP_LIMIT, \
.regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \
.fs = KERNEL_DS, \
- .fpr = {0}, \
+ .fpr = {{0}}, \
.fpscr = { .val = 0, }, \
.fpexc_mode = 0, \
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: manual merge of the net tree
Hi Dave,
Today's linux-next merge of the net tree got a trivial conflict in
drivers/net/fs_enet/fs_enet-main.c between commit
55b6c8e99d582cc66947b465d0ff3147a0219808 (drivers/net: Use linux/of_
{device,platform}.h instead of asm) from the powerpc tree and commit
d8b35fac8c7e1b44d873c1afcc5f88bc5ef4b361 (fs_enet: MDIO on GPIO
support) from the net tree.
I fixed it up and can carry the fixup.
(The powerpc commit just changed asm/of_platform.h to linux/of_platform.h)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpmwefGEwJPt.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fixup lwsync at runtime
On Tue, 2008-07-01 at 16:23 +1000, Benjamin Herrenschmidt wrote: On Tue, 2008-07-01 at 00:32 -0500, Kumar Gala wrote: To allow for a single kernel image on e500 v1/v2/mc we need to fixup lwsync at runtime. On e500v1/v2 lwsync causes an illop so we need to patch up the code. We default to 'sync' since that is always safe and if the cpu is capable we will replace 'sync' with 'lwsync'. We introduce CPU_FTR_LWSYNC as a way to determine at runtime if this is needed. This flag could be moved elsewhere since we dont really use it for the normal CPU_FTR purpose. Finally we only store the relative offset in the fixup section to keep it as small as possible rather than using a full fixup_entry. Signed-off-by: Kumar Gala [EMAIL PROTECTED] I'd rather have some more generic alternatives stuff but in the meantime, Ack. Hrm... minus mpe's comments... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: manual merge of the net tree
Hi Dave, Today's linux-next merge of the net tree got a conflict in between commits aee1dc73b519227084d77b0b2fc972b68b4153d8 ([POWERPC] Update booting-without-of for Freescale PCIe MSI) and 83ff9dcf375c418ca3b98eb950711525ca1269e2 (powerpc/sysdev: implement FSL GTM support) from the powerpc tree and commit a5edeccb1a8432ae5d9fb9bccea5a4b64c565017 (net: OpenFirmware GPIO based MDIO bitbang driver) from the net tree. They are just overlapping additions. I renumbered(?) the MDIO on GPIOs section to 'v'. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpbG14XWbhyI.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC83xx ipic problem
Scott, thanks for your reply. Honestly I don't think the board wiring is incorrect. FPGA goes to IRQ0 and miniPCI is wired to IRQ1. Maybe there's a crosstalk problem since the pull-up resistors are packaged inside an array ... I'll check this. regards, André Scott Wood schrieb: André Schwarz wrote: There are two external PCI devices connected (FPGA + miniPCI socket). The FPGA is working fine and uses IRQ0 for its PCI_INTA line. As soon there's a miniPCI module present and the driver loaded (actually an ath5k WiFi module) the system complains after a while : irq 48: nobody cared handlers: location of the FPGA irq handler Disabling IRQ #48 - This is weird since the FPGA isn't working at all and IRQ0 is *not* asserted ! Are you *sure* that IRQ0 isn't asserted? The IPIC seems to think it is. Of course the miniPCI irq is routed to a different pin on the CPU (IRQ1). Perhaps the board wiring is incorrect? interrupt-map = 0x5800 0 0 1 ipic 0x30 0x8 - FPGA @ IRQ0 0x6000 0 0 1 ipic 0x11 0x8 - miniPCI INTA @ IRQ1 0x6000 0 0 2 ipic 0x11 0x8;- miniPCI INTB @ IRQ1 Is it legal to use a single irq pin twice ? Yes. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev MATRIX VISION GmbH, Talstra�e 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Gesch�ftsf�hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD-FAILURE] linux-next: Tree for June 30 - powerpc - build failure at arch_add_memory()
Tony Breeds wrote: On Mon, Jun 30, 2008 at 11:55:02PM +0530, Kamalesh Babulal wrote: Hi Stephen, next-20080630 kernel build fails on powerpc, with randconfig CC arch/powerpc/mm/mem.o arch/powerpc/mm/mem.c: In function ‘arch_add_memory’: arch/powerpc/mm/mem.c:130: error: implicit declaration of function ‘create_section_mapping’ make[1]: *** [arch/powerpc/mm/mem.o] Error 1 make: *** [arch/powerpc/mm] Error 2 This problem exists in in 2.6.26-rc8, so it's not specifially linux-next realted. The patch at: http://patchwork.ozlabs.org/linuxppc/patch?id=19347 should fix it but is un-ACK'd ;P Hi Tony, Thanks, the patch fixes the build failure on the machine. Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Commits added to powerpc.git master and powerpc-next branches
Hi Paul, On Tuesday 01 July 2008, Paul Mackerras wrote: The following commits have been added to the master and powerpc-next branches of the powerpc.git repository. This includes patches pulled from Kumar's and Josh's trees. Any change of getting the following patches into 2.6.27 ? They have either been acked and not picked, or just ignored so far :-/ [PATCHv2] fs_enet: restore promiscuous and multicast settings in restart() http://patchwork.ozlabs.org/linuxppc/patch?person=968id=19228 [PATCH 2/2] fs_enet: MDIO on GPIO support http://patchwork.ozlabs.org/linuxppc/patch?person=968id=18693 [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC. http://patchwork.ozlabs.org/linuxppc/patch?person=968id=19045 [PATCH] powerpc: Modem control lines support for the cpm_uart driver http://patchwork.ozlabs.org/linuxppc/patch?person=968id=17928 [PATCH] cpm_uart: Support uart_wait_until_sent() http://patchwork.ozlabs.org/linuxppc/patch?person=968id=19233 Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] ibm_newemac: Fixes kernel crashes when speed of cable connected changes
From: Sathya Narayanan [EMAIL PROTECTED] The descriptor pointers were not initialized to NIL values, so it was poiniting to some random addresses which was completely invalid. This fix takes care of initializing the descriptor to NIL values and clearing the valid descriptors on clean ring operation. Signed-off-by: Sathya Narayanan [EMAIL PROTECTED] Signed-off-by: Stefan Roese [EMAIL PROTECTED] --- drivers/net/ibm_newemac/core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c index 5d2108c..ca63fa0 100644 --- a/drivers/net/ibm_newemac/core.c +++ b/drivers/net/ibm_newemac/core.c @@ -2719,6 +2719,8 @@ static int __devinit emac_probe(struct of_device *ofdev, /* Clean rings */ memset(dev-tx_desc, 0, NUM_TX_BUFF * sizeof(struct mal_descriptor)); memset(dev-rx_desc, 0, NUM_RX_BUFF * sizeof(struct mal_descriptor)); + memset(dev-tx_skb, 0, NUM_TX_BUFF * sizeof(struct sk_buff *)); + memset(dev-rx_skb, 0, NUM_RX_BUFF * sizeof(struct sk_buff *)); /* Attach to ZMII, if needed */ if (emac_has_feature(dev, EMAC_FTR_HAS_ZMII) -- 1.5.6.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] ibm_newemac: Fixes entry of short packets
From: Sathya Narayanan [EMAIL PROTECTED]
Short packets has to be discarded by the driver. So this patch addresses the
issue of discarding the short packets of size lesser then ethernet header
size.
Signed-off-by: Sathya Narayanan [EMAIL PROTECTED]
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index ca63fa0..babc79a 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -1636,6 +1636,12 @@ static int emac_poll_rx(void *param, int budget)
goto next;
}
+ if (len ETH_HLEN) {
+ ++dev-estats.rx_dropped_stack;
+ emac_recycle_rx_skb(dev, slot, len);
+ goto next;
+ }
+
if (len len EMAC_RX_COPY_THRESH) {
struct sk_buff *copy_skb =
alloc_skb(len + EMAC_RX_SKB_HEADROOM + 2,
GFP_ATOMIC);
--
1.5.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/6] mm: Allow architectures to define additional protection bits
On Wed, 18 Jun 2008 17:32:55 -0500 [EMAIL PROTECTED] wrote:
This patch allows architectures to define functions to deal with
additional protections bits for mmap() and mprotect().
arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags
arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot
arch_validate_prot() checks for valid values of the protection bits
It'd be simpler if Paul were to merge this. It doesn't conflict with
any pending work.
Acked-by: Andrew Morton [EMAIL PROTECTED]
Note: vm_get_page_prot() is now pretty ugly.
It is. But afacit it generates the same code for non-powerpc.
Suggestions?
nfi. Let us rub the Hugh-summoning lamp.
Signed-off-by: Dave Kleikamp [EMAIL PROTECTED]
---
include/linux/mman.h | 28 +++-
mm/mmap.c|5 +++--
mm/mprotect.c|2 +-
3 files changed, 31 insertions(+), 4 deletions(-)
Index: linux-2.6.26-rc5/include/linux/mman.h
===
--- linux-2.6.26-rc5.orig/include/linux/mman.h
+++ linux-2.6.26-rc5/include/linux/mman.h
@@ -34,6 +34,31 @@ static inline void vm_unacct_memory(long
}
/*
+ * Allow architectures to handle additional protection bits
+ */
+
+#ifndef arch_calc_vm_prot_bits
+#define arch_calc_vm_prot_bits(prot) 0
+#endif
+
+#ifndef arch_vm_get_page_prot
+#define arch_vm_get_page_prot(vm_flags) __pgprot(0)
+#endif
+
+#ifndef arch_validate_prot
+/*
+ * This is called from mprotect(). PROT_GROWSDOWN and PROT_GROWSUP have
+ * already been masked out.
+ *
+ * Returns true if the prot flags are valid
+ */
+static inline int arch_validate_prot(unsigned long prot)
+{
+ return (prot ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) == 0;
+}
Officially we should now have
#define arch_validate_prot arch_validate_prot
here.
+#endif
+
+/*
* Optimisation macro. It is equivalent to:
* (x bit1) ? bit2 : 0
* but this version is faster.
@@ -51,7 +76,8 @@ calc_vm_prot_bits(unsigned long prot)
{
return _calc_vm_trans(prot, PROT_READ, VM_READ ) |
_calc_vm_trans(prot, PROT_WRITE, VM_WRITE) |
-_calc_vm_trans(prot, PROT_EXEC, VM_EXEC );
+_calc_vm_trans(prot, PROT_EXEC, VM_EXEC) |
+arch_calc_vm_prot_bits(prot);
}
/*
Index: linux-2.6.26-rc5/mm/mmap.c
===
--- linux-2.6.26-rc5.orig/mm/mmap.c
+++ linux-2.6.26-rc5/mm/mmap.c
@@ -72,8 +72,9 @@ pgprot_t protection_map[16] = {
pgprot_t vm_get_page_prot(unsigned long vm_flags)
{
- return protection_map[vm_flags
- (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
+ return __pgprot(pgprot_val(protection_map[vm_flags
+ (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
+ pgprot_val(arch_vm_get_page_prot(vm_flags)));
}
EXPORT_SYMBOL(vm_get_page_prot);
Index: linux-2.6.26-rc5/mm/mprotect.c
===
--- linux-2.6.26-rc5.orig/mm/mprotect.c
+++ linux-2.6.26-rc5/mm/mprotect.c
@@ -239,7 +239,7 @@ sys_mprotect(unsigned long start, size_t
end = start + len;
if (end = start)
return -ENOMEM;
- if (prot ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM))
+ if (!arch_validate_prot(prot))
return -EINVAL;
reqprot = prot;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix compile warning in init_thread
On Tue, 2008-07-01 at 17:00 +1000, Michael Neuling wrote:
arch/powerpc/kernel/init_task.c:33: warning: missing braces around initializer
arch/powerpc/kernel/init_task.c:33: warning: (near initialization for
'init_task.thread.fpr[0]')
Noticed by SFR.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
That's when fpr is part of the union but what if CONFIG_VSX is off ?
Ben.
---
include/asm-powerpc/processor.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6-ozlabs/include/asm-powerpc/processor.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/processor.h
+++ linux-2.6-ozlabs/include/asm-powerpc/processor.h
@@ -222,7 +222,7 @@ struct thread_struct {
.ksp_limit = INIT_SP_LIMIT, \
.regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \
.fs = KERNEL_DS, \
- .fpr = {0}, \
+ .fpr = {{0}}, \
.fpscr = { .val = 0, }, \
.fpexc_mode = 0, \
}
___
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
linux-next: manual merge of the ttydev tree
Hi Alan, Today's linux-next merge of the ttydev tree got a conflict in drivers/serial/cpm_uart/cpm_uart_core.c between commit 0b2a2e5b7747f1f63bd86ca22b5c6097da5b2137 (cpm_uart: Remove !CONFIG_PPC_CPM_NEW_BINDING code) from the powerpc tree and commit 33e211d606d46d18befa6fe6aec76aa7971eefa8 (03-serial_vcs) from the ttydev tree. The former removes some of the code modified by the latter. It is a simple fixup and I can carry it. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgph8pPzb5VtA.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix compile warning in init_thread
In message [EMAIL PROTECTED] you wrote:
On Tue, 2008-07-01 at 17:00 +1000, Michael Neuling wrote:
arch/powerpc/kernel/init_task.c:33: warning: missing braces around initiali
zer
arch/powerpc/kernel/init_task.c:33: warning: (near initialization for 'init
_task.thread.fpr[0]')
Noticed by SFR.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
That's when fpr is part of the union but what if CONFIG_VSX is off ?
It's not a union anymore. It's a 2D array irrespective of CONFIG_VSX.
double fpr[32][TS_FPRWIDTH];
Mikey
Ben.
---
include/asm-powerpc/processor.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6-ozlabs/include/asm-powerpc/processor.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/processor.h
+++ linux-2.6-ozlabs/include/asm-powerpc/processor.h
@@ -222,7 +222,7 @@ struct thread_struct {
.ksp_limit = INIT_SP_LIMIT, \
.regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \
.fs = KERNEL_DS, \
- .fpr = {0}, \
+ .fpr = {{0}}, \
.fpscr = { .val = 0, }, \
.fpexc_mode = 0, \
}
___
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
[BUG] 2.6.26-rc8-git2 - powerpc - circular locking dependency detected with net/ehea driver
Hi,
circular locking dependency is detected, while booting the
powerpc box with the 2.6.26-rc8-git2 kernel.
===
[ INFO: possible circular locking dependency detected ]
2.6.26-rc8-git2 #1
---
ip/2214 is trying to acquire lock:
(ehea_fw_handles.lock){--..}, at: [d07b4fa8] .ehea_up+0x6c/0x6f8
[ehea]
but task is already holding lock:
(port-port_lock){--..}, at: [d07b57bc] .ehea_open+0x44/0xcc [ehea]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #2 (port-port_lock){--..}:
[c00aa0e8] .__lock_acquire+0xc84/0xee0
[c00aa41c] .lock_acquire+0xd8/0x124
[c0452008] .mutex_lock_nested+0x168/0x420
[d07b57bc] .ehea_open+0x44/0xcc [ehea]
[c03b62b0] .dev_open+0xec/0x160
[c03b46a4] .dev_change_flags+0x10c/0x210
[c04162b0] .devinet_ioctl+0x2cc/0x778
[c04173e0] .inet_ioctl+0xdc/0x134
[c03a4464] .sock_ioctl+0x2dc/0x338
[c012d12c] .vfs_ioctl+0x64/0xfc
[c012d614] .do_vfs_ioctl+0x450/0x494
[c012d6d0] .sys_ioctl+0x78/0xc0
[c016413c] .dev_ifsioc+0x1e8/0x450
[c0163588] .compat_sys_ioctl+0x3ec/0x484
[c00086dc] syscall_exit+0x0/0x40
- #1 (rtnl_mutex){--..}:
[c00aa0e8] .__lock_acquire+0xc84/0xee0
[c00aa41c] .lock_acquire+0xd8/0x124
[c0452008] .mutex_lock_nested+0x168/0x420
[c03c1ad0] .rtnl_lock+0x28/0x44
[c03b5334] .register_netdev+0x24/0x8c
[d07b3810] .ehea_setup_single_port+0x2d4/0x3e0 [ehea]
[d07ba434] .ehea_probe_adapter+0x290/0x3a0 [ehea]
[c03a0098] .of_platform_device_probe+0x80/0x8c4
[c0305ce4] .driver_probe_device+0x144/0x20c
[c0305e14] .__driver_attach+0x68/0xb0
[c0304ed4] .bus_for_each_dev+0x88/0xe4
[c0305a24] .driver_attach+0x34/0x50
[c0305524] .bus_add_driver+0xe0/0x294
[c0306178] .driver_register+0xcc/0x1a4
[c039ff30] .of_register_driver+0x54/0x6c
[c00256f4] .ibmebus_register_driver+0x40/0x60
[d07ba728] .ehea_module_init+0x1e4/0x22fc [ehea]
[c00b5294] .sys_init_module+0x19a0/0x1b80
[c00086dc] syscall_exit+0x0/0x40
- #0 (ehea_fw_handles.lock){--..}:
[c00a9fe4] .__lock_acquire+0xb80/0xee0
[c00aa41c] .lock_acquire+0xd8/0x124
[c0452008] .mutex_lock_nested+0x168/0x420
[d07b4fa8] .ehea_up+0x6c/0x6f8 [ehea]
[d07b57e4] .ehea_open+0x6c/0xcc [ehea]
[c03b62b0] .dev_open+0xec/0x160
[c03b46a4] .dev_change_flags+0x10c/0x210
[c04162b0] .devinet_ioctl+0x2cc/0x778
[c04173e0] .inet_ioctl+0xdc/0x134
[c03a4464] .sock_ioctl+0x2dc/0x338
[c012d12c] .vfs_ioctl+0x64/0xfc
[c012d614] .do_vfs_ioctl+0x450/0x494
[c012d6d0] .sys_ioctl+0x78/0xc0
[c016413c] .dev_ifsioc+0x1e8/0x450
[c0163588] .compat_sys_ioctl+0x3ec/0x484
[c00086dc] syscall_exit+0x0/0x40
other info that might help us debug this:
2 locks held by ip/2214:
#0: (rtnl_mutex){--..}, at: [c03c1ad0] .rtnl_lock+0x28/0x44
#1: (port-port_lock){--..}, at: [d07b57bc] .ehea_open+0x44/0xcc
[ehea]
stack backtrace:
Call Trace:
[c000f4d0f030] [c0010b9c] .show_stack+0x78/0x1c8 (unreliable)
[c000f4d0f0e0] [c0010d0c] .dump_stack+0x20/0x34
[c000f4d0f160] [c00a7644] .print_circular_bug_tail+0x84/0xa8
[c000f4d0f230] [c00a9fe4] .__lock_acquire+0xb80/0xee0
[c000f4d0f320] [c00aa41c] .lock_acquire+0xd8/0x124
[c000f4d0f3e0] [c0452008] .mutex_lock_nested+0x168/0x420
[c000f4d0f4d0] [d07b4fa8] .ehea_up+0x6c/0x6f8 [ehea]
[c000f4d0f5e0] [d07b57e4] .ehea_open+0x6c/0xcc [ehea]
[c000f4d0f680] [c03b62b0] .dev_open+0xec/0x160
[c000f4d0f710] [c03b46a4] .dev_change_flags+0x10c/0x210
[c000f4d0f7c0] [c04162b0] .devinet_ioctl+0x2cc/0x778
[c000f4d0f8d0] [c04173e0] .inet_ioctl+0xdc/0x134
[c000f4d0f950] [c03a4464] .sock_ioctl+0x2dc/0x338
[c000f4d0f9f0] [c012d12c] .vfs_ioctl+0x64/0xfc
[c000f4d0fa90] [c012d614] .do_vfs_ioctl+0x450/0x494
[c000f4d0fb50] [c012d6d0] .sys_ioctl+0x78/0xc0
[c000f4d0fc10] [c016413c] .dev_ifsioc+0x1e8/0x450
[c000f4d0fd30] [c0163588] .compat_sys_ioctl+0x3ec/0x484
[c000f4d0fe30] [c00086dc] syscall_exit+0x0/0x40
ehea: eth0: Physical port up
ehea: External switch port is backup port
BUG: sleeping function called from invalid context at kernel/mutex.c:209
[PATCH] powerpc/86xx: mpc8610_hpcd: fix interrupt trigger type for ULi IDE
i8259 PIC is disabled on MPC8610HPCD, and ULi IDE is configured to use PCI sideband interrupt that is specified in the device tree. Current HPCD's device tree specify that IDE interrupt is low to high sensitive, but in practice ULi IDE throws active-high interrupts (not active-low as all normal PCI devices). Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- This is for -next, since the bug could be triggered only on RT kernels with hardirq preemption. arch/powerpc/boot/dts/mpc8610_hpcd.dts |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts index 65a5f64..981941e 100644 --- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts +++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts @@ -363,7 +363,7 @@ 0xe000 0 0 4 mpic 1 1 /* IDSEL 0x1f */ - 0xf800 0 0 1 mpic 3 0 + 0xf800 0 0 1 mpic 3 2 0xf800 0 0 2 mpic 0 1 ; -- 1.5.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/6] mm: Allow architectures to define additional protection bits
On Tue, 2008-07-01 at 01:53 -0700, Andrew Morton wrote:
On Wed, 18 Jun 2008 17:32:55 -0500 [EMAIL PROTECTED] wrote:
This patch allows architectures to define functions to deal with
additional protections bits for mmap() and mprotect().
arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags
arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot
arch_validate_prot() checks for valid values of the protection bits
It'd be simpler if Paul were to merge this. It doesn't conflict with
any pending work.
That works for me. Paul, I'll send you an updated patchset.
Acked-by: Andrew Morton [EMAIL PROTECTED]
Note: vm_get_page_prot() is now pretty ugly.
It is. But afacit it generates the same code for non-powerpc.
Suggestions?
nfi. Let us rub the Hugh-summoning lamp.
Signed-off-by: Dave Kleikamp [EMAIL PROTECTED]
---
include/linux/mman.h | 28 +++-
mm/mmap.c|5 +++--
mm/mprotect.c|2 +-
3 files changed, 31 insertions(+), 4 deletions(-)
Index: linux-2.6.26-rc5/include/linux/mman.h
===
--- linux-2.6.26-rc5.orig/include/linux/mman.h
+++ linux-2.6.26-rc5/include/linux/mman.h
@@ -34,6 +34,31 @@ static inline void vm_unacct_memory(long
}
/*
+ * Allow architectures to handle additional protection bits
+ */
+
+#ifndef arch_calc_vm_prot_bits
+#define arch_calc_vm_prot_bits(prot) 0
+#endif
+
+#ifndef arch_vm_get_page_prot
+#define arch_vm_get_page_prot(vm_flags) __pgprot(0)
+#endif
+
+#ifndef arch_validate_prot
+/*
+ * This is called from mprotect(). PROT_GROWSDOWN and PROT_GROWSUP have
+ * already been masked out.
+ *
+ * Returns true if the prot flags are valid
+ */
+static inline int arch_validate_prot(unsigned long prot)
+{
+ return (prot ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) == 0;
+}
Officially we should now have
#define arch_validate_prot arch_validate_prot
here.
No problem.
+#endif
+
+/*
* Optimisation macro. It is equivalent to:
* (x bit1) ? bit2 : 0
* but this version is faster.
@@ -51,7 +76,8 @@ calc_vm_prot_bits(unsigned long prot)
{
return _calc_vm_trans(prot, PROT_READ, VM_READ ) |
_calc_vm_trans(prot, PROT_WRITE, VM_WRITE) |
- _calc_vm_trans(prot, PROT_EXEC, VM_EXEC );
+ _calc_vm_trans(prot, PROT_EXEC, VM_EXEC) |
+ arch_calc_vm_prot_bits(prot);
}
/*
Index: linux-2.6.26-rc5/mm/mmap.c
===
--- linux-2.6.26-rc5.orig/mm/mmap.c
+++ linux-2.6.26-rc5/mm/mmap.c
@@ -72,8 +72,9 @@ pgprot_t protection_map[16] = {
pgprot_t vm_get_page_prot(unsigned long vm_flags)
{
- return protection_map[vm_flags
- (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
+ return __pgprot(pgprot_val(protection_map[vm_flags
+ (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
+ pgprot_val(arch_vm_get_page_prot(vm_flags)));
}
EXPORT_SYMBOL(vm_get_page_prot);
Index: linux-2.6.26-rc5/mm/mprotect.c
===
--- linux-2.6.26-rc5.orig/mm/mprotect.c
+++ linux-2.6.26-rc5/mm/mprotect.c
@@ -239,7 +239,7 @@ sys_mprotect(unsigned long start, size_t
end = start + len;
if (end = start)
return -ENOMEM;
- if (prot ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM))
+ if (!arch_validate_prot(prot))
return -EINVAL;
reqprot = prot;
--
--
David Kleikamp
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] IB/ehca: Make device table externally visible
This gives ehca an autogenerated modalias and therefore enables automatic
loading.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_main.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c
b/drivers/infiniband/hw/ehca/ehca_main.c
index 482103e..598844d 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -923,6 +923,7 @@ static struct of_device_id ehca_device_table[] =
},
{},
};
+MODULE_DEVICE_TABLE(of, ehca_device_table);
static struct of_platform_driver ehca_driver = {
.name= ehca,
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fixup lwsync at runtime
On Jul 1, 2008, at 1:29 AM, Michael Ellerman wrote: On Tue, 2008-07-01 at 00:32 -0500, Kumar Gala wrote: To allow for a single kernel image on e500 v1/v2/mc we need to fixup lwsync at runtime. On e500v1/v2 lwsync causes an illop so we need to patch up the code. We default to 'sync' since that is always safe and if the cpu is capable we will replace 'sync' with 'lwsync'. We introduce CPU_FTR_LWSYNC as a way to determine at runtime if this is needed. This flag could be moved elsewhere since we dont really use it for the normal CPU_FTR purpose. Finally we only store the relative offset in the fixup section to keep it as small as possible rather than using a full fixup_entry. How many entries are we talking? I guess it's not much bother to have a separate section. On the order of 1000 entries for an SMP build. diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/ setup_32.c index 9e83add..0109e7f 100644 --- a/arch/powerpc/kernel/setup_32.c +++ b/arch/powerpc/kernel/setup_32.c @@ -101,6 +101,10 @@ unsigned long __init early_init(unsigned long dt_ptr) PTRRELOC(__start___ftr_fixup), PTRRELOC(__stop___ftr_fixup)); + do_lwsync_fixups(spec-cpu_features, +PTRRELOC(__start___lwsync_fixup), +PTRRELOC(__stop___lwsync_fixup)); + This could be changed to use cur_cpu_spec-cpu_features, and then all the call sites would be passing that, which would mean do_lwsync_fixups() could just check cur_cpu_spec-cpu_features directly. cur_cpu_spec and spec at this point arent the same thing. will post a new version w/fixes. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AZFS file system proposal
On Wednesday 18 June 2008, Maxim Shchetynin wrote:
AZFS patch updated accordinly to comments of Christoph Hellwig and Dmitri
Vorobiev.
Sorry for my not commenting earlier on this. I'm finally collecting my
2.6.27 patches and stumbled over it again. There are a few details
that I hope we can fix up quickly, other than that, it looks good now,
great work!
Subject: azfs: initial submit of azfs, a non-buffered filesystem
Please make the patch subject the actual subject of your email next time,
and put the introductory text below the Signed-off-by: lines, separated
by a --- line. That will make the standard tools work without extra
effort on my side. Also, please always Cc the person you want to merge
the patch, in this case probably me.
diff -Nuar linux-2.6.26-rc6/fs/Makefile linux-2.6.26-rc6-azfs/fs/Makefile
--- linux-2.6.26-rc6/fs/Makefile 2008-06-12 23:22:24.0 +0200
+++ linux-2.6.26-rc6-azfs/fs/Makefile 2008-06-16 11:17:50.0 +0200
@@ -119,3 +119,4 @@
obj-$(CONFIG_DEBUG_FS) += debugfs/
obj-$(CONFIG_OCFS2_FS) += ocfs2/
obj-$(CONFIG_GFS2_FS) += gfs2/
+obj-$(CONFIG_AZ_FS) += azfs.o
diff -Nuar linux-2.6.26-rc6/fs/azfs.c linux-2.6.26-rc6-azfs/fs/azfs.c
--- linux-2.6.26-rc6/fs/azfs.c1970-01-01 01:00:00.0 +0100
+++ linux-2.6.26-rc6-azfs/fs/azfs.c 2008-06-18 15:56:13.252266896 +0200
All other file systems are in separate directories, so it would be better
to rename fs/azfs.c to fs/azfs/inode.c
+#define AZFS_FILESYSTEM_NAME azfs
+#define AZFS_FILESYSTEM_FLAGSFS_REQUIRES_DEV
+
+#define AZFS_SUPERBLOCK_MAGIC0xABBA1972
+#define AZFS_SUPERBLOCK_FLAGSMS_NOEXEC | \
+ MS_SYNCHRONOUS | \
+ MS_DIRSYNC | \
+ MS_ACTIVE
Why MS_NOEXEC? What happens on a remount if the user does not specifies
-o remount,exec?
+/**
+ * azfs_block_find - get real address of a part of a file
+ * @inode: inode
+ * @direction: data direction
+ * @from: offset for read/write operation
+ * @size: pointer to a value of the amount of data to be read/written
+ */
+static unsigned long
+azfs_block_find(struct inode *inode, enum azfs_direction direction,
+ unsigned long from, unsigned long *size)
+{
+ struct azfs_super *super;
+ struct azfs_znode *znode;
+ struct azfs_block *block;
+ unsigned long block_id, west, east;
+
+ super = inode-i_sb-s_fs_info;
+ znode = I2Z(inode);
+
+ if (from + *size znode-size) {
+ i_size_write(inode, from + *size);
+ inode-i_op-truncate(inode);
+ }
+
+ read_lock(znode-lock);
+
+ if (list_empty(znode-block_list)) {
+ read_unlock(znode-lock);
+ return 0;
+ }
+
+ block_id = from super-block_shift;
+
+ for_each_block(block, znode-block_list) {
+ if (block-count block_id)
+ break;
+ block_id -= block-count;
+ }
+
+ west = from % super-block_size;
+ east = ((block-count - block_id) super-block_shift) - west;
+
+ if (*size east)
+ *size = east;
+
+ block_id = ((block-id + block_id) super-block_shift) + west;
+
+ read_unlock(znode-lock);
+
+ block_id += direction == AZFS_MMAP ? super-ph_addr : super-io_addr;
+
+ return block_id;
+}
This overloading of the return type to mean either a pointer or an offset
on the block device is rather confusing. Why not just return the raw block_id
before the last += and leave that part up to the caller?
static void __iomem *
azfs_block_addr(struct inode *inode, enum azfs_direction direction,
unsigned long from, unsigned long *size)
{
struct azfs_super *super;
unsigned long offset;
void __iomem *p;
super = inode-i_sb-s_fs_info;
offset = azfs_block_find(inode, super, 0, from, size);
p = super-ph_addr + offset;
return p;
}
+ target = iov-iov_base;
+ todo = min((loff_t) iov-iov_len, i_size_read(inode) - pos);
+
+ for (step = todo; step; step -= size) {
+ size = step;
+ pin = azfs_block_find(inode, AZFS_READ, pos, size);
+ if (!pin) {
+ rc = -ENOSPC;
+ goto out;
+ }
+ if (copy_to_user(target, (void*) pin, size)) {
+ rc = -EFAULT;
+ goto out;
+ }
Question to the powerpc folks: is copy_to_user safe for an __iomem source?
Should there be two copies (memcpy_fromio and copy_to_user) instead?
+ page_prot = pgprot_val(vma-vm_page_prot);
+ page_prot |= (_PAGE_NO_CACHE | _PAGE_RW);
+ page_prot = ~_PAGE_GUARDED;
+ vma-vm_page_prot = __pgprot(page_prot);
The pgprot modifications rely on powerpc specific flags,
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
Hi Jon,
On Mon, 30 Jun 2008 19:01:28 -0400, Jon Smirl wrote:
Add the of_find_i2c_device_by_node function. This allows you to
follow a reference in the device to an i2c device node and then
locate the linux device instantiated by the device tree. Example
use, an i2s codec controlled by i2c.
---
drivers/i2c/i2c-core.c |2 +-
drivers/of/of_i2c.c| 37 ++---
include/linux/i2c.h|3 +++
include/linux/of_i2c.h |2 ++
4 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index d0175f4..e3abe1b 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -208,7 +208,7 @@ static struct device_attribute i2c_dev_attrs[] = {
{ },
};
-static struct bus_type i2c_bus_type = {
+struct bus_type i2c_bus_type = {
.name = i2c,
.dev_attrs = i2c_dev_attrs,
.match = i2c_device_match,
What if i2c-core is built as a module? Don't you need to export the
symbol then?
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index 715a444..ca69a16 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -75,7 +75,7 @@ static int of_find_i2c_driver(struct device_node *node,
void of_register_i2c_devices(struct i2c_adapter *adap,
struct device_node *adap_node)
{
- void *result;
+ struct i2c_client *i2c_dev;
struct device_node *node;
for_each_child_of_node(adap_node, node) {
@@ -90,29 +90,44 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
continue;
}
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- if (of_find_i2c_driver(node, info) 0) {
- irq_dispose_mapping(info.irq);
+ if (of_find_i2c_driver(node, info) 0)
continue;
- }
+ info.irq = irq_of_parse_and_map(node, 0);
info.addr = *addr;
- request_module(info.type);
+ request_module(%s, info.type);
A separate fix for this issue was already sent by Maximilian Attems a
few days go:
http://lists.lm-sensors.org/pipermail/i2c/2008-June/004030.html
- result = i2c_new_device(adap, info);
- if (result == NULL) {
+ i2c_dev = i2c_new_device(adap, info);
+ if (i2c_dev == NULL) {
printk(KERN_ERR
of-i2c: Failed to load driver for %s\n,
info.type);
irq_dispose_mapping(info.irq);
continue;
}
+
+ i2c_dev-dev.archdata.of_node = of_node_get(node);
}
}
EXPORT_SYMBOL(of_register_i2c_devices);
+static int of_dev_node_match(struct device *dev, void *data)
+{
+return dev-archdata.of_node == data;
+}
+
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
+{
+ struct device *dev;
+
+ dev = bus_find_device(i2c_bus_type, NULL, node,
+ of_dev_node_match);
+ if (!dev)
+ return NULL;
+
+ return to_i2c_client(dev);
+}
+EXPORT_SYMBOL(of_find_i2c_device_by_node);
+
MODULE_LICENSE(GPL);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index fb9af6a..186b22d 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -92,6 +92,9 @@ extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client
* client,
extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client,
u8 command, u8 length,
const u8 *values);
+
+/* Base of the i2c bus */
+extern struct bus_type i2c_bus_type;
/*
* A driver is capable of handling one or more physical devices present on
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
index bd2a870..17d5897 100644
--- a/include/linux/of_i2c.h
+++ b/include/linux/of_i2c.h
@@ -16,5 +16,7 @@
void of_register_i2c_devices(struct i2c_adapter *adap,
struct device_node *adap_node);
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node);
+
#endif /* __LINUX_OF_I2C_H */
I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
It was un-exported only because it had no user left, but it can be
exported again if needed.
I'm not the one to push this upstream though, as the patch is
essentially an openfirmware patch. That would be something for Jochen
Friedrich and Paul Mackerras I guess. Would be nice to have a
MAINTAINERS entry for OF...
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Re: linux-next: manual merge of the net tree
On Tue, 1 Jul 2008 17:19:40 +1000 Stephen Rothwell [EMAIL PROTECTED] wrote: Hi Dave, Today's linux-next merge of the net tree got a conflict in between ^ Documentation/powerpc/booting-without-of.txt -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpglOlQwQ7aB.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote: I'm fine with this patch. In particular, exporting i2c_bus_type is OK. It was un-exported only because it had no user left, but it can be exported again if needed. Another solution would be to move drivers/of/of_i2c into the i2c directory and make it part of i2c core on powerpc builds. I'm not the one to push this upstream though, as the patch is essentially an openfirmware patch. That would be something for Jochen Friedrich and Paul Mackerras I guess. Would be nice to have a MAINTAINERS entry for OF... -- Jean Delvare -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 1/2] powerpc: Fix building of feature-fixup tests on ppc32
We need to use PPC_LCMPI otherwise we get compile errors like: arch/powerpc/lib/feature-fixups-test.S: Assembler messages: arch/powerpc/lib/feature-fixups-test.S:142: Error: Unrecognized opcode: `cmpdi' arch/powerpc/lib/feature-fixups-test.S:149: Error: Unrecognized opcode: `cmpdi' arch/powerpc/lib/feature-fixups-test.S:164: Error: Unrecognized opcode: `cmpdi' Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- arch/powerpc/lib/feature-fixups-test.S |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/lib/feature-fixups-test.S b/arch/powerpc/lib/feature-fixups-test.S index 10d038b..0549be0 100644 --- a/arch/powerpc/lib/feature-fixups-test.S +++ b/arch/powerpc/lib/feature-fixups-test.S @@ -139,14 +139,14 @@ globl(ftr_fixup_test6) 1: or 1,1,1 BEGIN_FTR_SECTION or 5,5,5 -2: cmpdi r3,0 +2: PPC_LCMPI r3,0 beq 4f blt 2b b 1b b 4f FTR_SECTION_ELSE 2: or 2,2,2 - cmpdi r3,1 + PPC_LCMPI r3,1 beq 3f blt 2b b 3f @@ -161,7 +161,7 @@ globl(end_ftr_fixup_test6) globl(ftr_fixup_test6_expected) 1: or 1,1,1 2: or 2,2,2 - cmpdi r3,1 + PPC_LCMPI r3,1 beq 3f blt 2b b 3f -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 2/2] powerpc: fixup lwsync at runtime
To allow for a single kernel image on e500 v1/v2/mc we need to fixup lwsync
at runtime. On e500v1/v2 lwsync causes an illop so we need to patch up
the code. We default to 'sync' since that is always safe and if the cpu
is capable we will replace 'sync' with 'lwsync'.
We introduce CPU_FTR_LWSYNC as a way to determine at runtime if this is
needed. This flag could be moved elsewhere since we dont really use it
for the normal CPU_FTR purpose.
Finally we only store the relative offset in the fixup section to keep it
as small as possible rather than using a full fixup_entry.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
* Moved and fixed up LWSYNC macros to feature-fixups.h
* Added lwsync test case to feature-fixups
* Reworked synch.h to be usable in asm code.
- k
arch/powerpc/kernel/module.c|6 +
arch/powerpc/kernel/setup_32.c |4 +++
arch/powerpc/kernel/setup_64.c |2 +
arch/powerpc/kernel/vdso.c | 10
arch/powerpc/kernel/vdso32/vdso32.lds.S |3 ++
arch/powerpc/kernel/vdso64/vdso64.lds.S |3 ++
arch/powerpc/kernel/vmlinux.lds.S |6 +
arch/powerpc/lib/feature-fixups-test.S | 15
arch/powerpc/lib/feature-fixups.c | 36 +
include/asm-powerpc/code-patching.h |3 +-
include/asm-powerpc/cputable.h | 21 +
include/asm-powerpc/feature-fixups.h| 10
include/asm-powerpc/synch.h | 38 ++
13 files changed, 131 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index 40dd52d..af07003 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -86,6 +86,12 @@ int module_finalize(const Elf_Ehdr *hdr,
(void *)sect-sh_addr + sect-sh_size);
#endif
+ sect = find_section(hdr, sechdrs, __lwsync_fixup);
+ if (sect != NULL)
+ do_lwsync_fixups(cur_cpu_spec-cpu_features,
+(void *)sect-sh_addr,
+(void *)sect-sh_addr + sect-sh_size);
+
return 0;
}
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 9e83add..0109e7f 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -101,6 +101,10 @@ unsigned long __init early_init(unsigned long dt_ptr)
PTRRELOC(__start___ftr_fixup),
PTRRELOC(__stop___ftr_fixup));
+ do_lwsync_fixups(spec-cpu_features,
+PTRRELOC(__start___lwsync_fixup),
+PTRRELOC(__stop___lwsync_fixup));
+
return KERNELBASE + offset;
}
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 098fd96..04d8de9 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -363,6 +363,8 @@ void __init setup_system(void)
__start___ftr_fixup, __stop___ftr_fixup);
do_feature_fixups(powerpc_firmware_features,
__start___fw_ftr_fixup, __stop___fw_ftr_fixup);
+ do_lwsync_fixups(cur_cpu_spec-cpu_features,
+__start___lwsync_fixup, __stop___lwsync_fixup);
/*
* Unflatten the device-tree passed by prom_init or kexec
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index ce245a8..f177c60 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -571,6 +571,11 @@ static __init int vdso_fixup_features(struct lib32_elfinfo
*v32,
if (start64)
do_feature_fixups(powerpc_firmware_features,
start64, start64 + size64);
+
+ start64 = find_section64(v64-hdr, __lwsync_fixup, size64);
+ if (start64)
+ do_lwsync_fixups(cur_cpu_spec-cpu_features,
+start64, start64 + size64);
#endif /* CONFIG_PPC64 */
start32 = find_section32(v32-hdr, __ftr_fixup, size32);
@@ -585,6 +590,11 @@ static __init int vdso_fixup_features(struct lib32_elfinfo
*v32,
start32, start32 + size32);
#endif /* CONFIG_PPC64 */
+ start32 = find_section32(v32-hdr, __lwsync_fixup, size32);
+ if (start32)
+ do_lwsync_fixups(cur_cpu_spec-cpu_features,
+start32, start32 + size32);
+
return 0;
}
diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S
b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index 2717935..be3b6a4 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -33,6 +33,9 @@ SECTIONS
. = ALIGN(8);
__ftr_fixup : { *(__ftr_fixup) }
+ . = ALIGN(8);
+ __lwsync_fixup : { *(__lwsync_fixup) }
+
#ifdef CONFIG_PPC64
. = ALIGN(8);
__fw_ftr_fixup : { *(__fw_ftr_fixup) }
Cascaded interrupt controller causing unbalanced interrupt.
Hi,
I'm having a spot of trouble writing a driver for a cascaded interrupt
handler used on one of our boards (8641D based board), patches to be
forth-coming as soon as I have access to this list without Outlook (I'm
working on it!).
I have attached the driver at the bottom of the email for reference
(sorry for the long email).
The driver is cascaded like this:
static void __init
gef_sbc610_init_irq(void)
{
struct mpic *mpic1;
struct device_node *np, *cascade_node = NULL;
struct resource res;
/* Determine MPIC address. */
np = of_find_node_by_type(NULL, open-pic);
if (np == NULL)
return;
of_address_to_resource(np, 0, res);
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET |
MPIC_BIG_ENDIAN,
0, 256, mpic);
of_node_put(np);
BUG_ON(mpic1 == NULL);
mpic_init(mpic1);
/*
* There is a simple interrupt handler in the main FPGA,
this
* needs To be cascaded into the MPIC
*/
cascade_node = of_find_compatible_node(NULL, NULL,
gef,fpga-pic);
if(!cascade_node) {
printk(KERN_WARNING SBC610: No FPGA PIC\n);
return;
}
gef_pic_init(cascade_node);
of_node_put(cascade_node);
}
The cascaded interrupt controller is connected to the 8641D's mpic on
interrupts 8 9, from the DTS file:
gef_pic: [EMAIL PROTECTED],4000 {
#interrupt-cells = 2;
interrupt-controller;
device_type = interrupt-controller;
compatible = gef,fpga-pic;
reg = 0x4 0x4000 0x20;
interrupts = 0x8 0x1
0x9 0x1;
interrupt-parent = mpic;
};
The interrupts from the phys are connected to the cascaded interrupt
controller:
phy0: [EMAIL PROTECTED] {
#interrupt-cells = 2;
interrupt-parent = gef_pic;
interrupts = 0x16 0x4;
reg = 0x0001;
device_type = ethernet-phy;
};
phy2: [EMAIL PROTECTED] {
#interrupt-cells = 2;
interrupt-parent = gef_pic;
interrupts = 0x17 0x4;
reg = 0x0003;
device_type = ethernet-phy;
};
When I boot (with the debugging turned on) I see the following:
mpic: Setting up MPIC mpic version 1.2 at fef4, max 2 CPUs
mpic: ISU size: 88, shift: 7, mask: 7f
mpic: Initializing for 88 sources
gef_pic: gef_pic_init(/[EMAIL PROTECTED]/[EMAIL PROTECTED],4000)
gef_pic: cascade mapped to irq 16
gef_pic: Setting up GEF FPGA pic at fdbf4000
...
gef_pic: gef_pic_host_xlate()
gef_pic: Setting flags from intspec:4
gef_pic: gef_pic_host_map(/[EMAIL PROTECTED]/[EMAIL PROTECTED],4000, 22, 16)
gef_pic: map virq 22, hwirq 0x16
gef_pic: gef_pic_host_xlate()
gef_pic: Setting flags from intspec:4
gef_pic: gef_pic_host_map(/[EMAIL PROTECTED]/[EMAIL PROTECTED],4000, 23, 17)
gef_pic: map virq 23, hwirq 0x17
...
gef_pic: Unmasking virtual interrupt 22, hw:22
Unbalanced enable for IRQ 22
[ cut here ]
Badness at c0055868 [verbose debug info unavailable]
NIP: c0055868 LR: c0055868 CTR: c01b3eb0
REGS: ef85be60 TRAP: 0700 Not tainted (2.6.26-rc8-13367-g62635be)
MSR: 00021032 ME,IR,DR CR: 2222 XER:
TASK = ef859970[10] 'events/1' THREAD: ef85a000 CPU: 1
GPR00: c0055868 ef85bf10 ef859970 0020 0001 0001
4000
GPR08: 0001 63f1 c03d 4282 0ff4ce00
0001
GPR16: c03c3040 c03a97f0 c03b c03a97f0 ef843f9c ef843f98 c03b
GPR24: c004 c033 ef85a000 c01b1b40 c03c3a90 9032 c03c3a60
c03c3a60
NIP [c0055868] __enable_irq+0x50/0x84
LR [c0055868] __enable_irq+0x50/0x84
Call Trace:
[ef85bf10] [c0055868] __enable_irq+0x50/0x84 (unreliable)
[ef85bf20] [c0055cf8] enable_irq+0x50/0x70
[ef85bf40] [c01b1ba8] phy_change+0x68/0x108
[ef85bf60] [c003ade4] run_workqueue+0xac/0x15c
[ef85bf90] [c003b330] worker_thread+0x74/0xd4
[ef85bfd0] [c003f3bc] kthread+0x48/0x84
[ef85bff0] [c00115f0] kernel_thread+0x44/0x60
Instruction dump:
419e0024 419a0044 3809 901f001c 80010014 83e1000c 38210010 7c0803a6
4e800020 3c60c033 3863f3a0 4bfd28c5 0fe0 80010014 83e1000c
38210010
...
gef_pic: Unmasking virtual interrupt 23, hw:23
Unbalanced enable for IRQ 23
[ cut here
Re: [PATCH2/2] [POWERPC] CPM1: implement GPIO LIB API on CPM1 Freescale SoC.
Hi Grant, sorry for the late response on this one. 2. You need to specifiy exact chip names in your compatible string. fsl,cpm1-pario-bank is a made up thing. + for_each_compatible_node(np, NULL, fsl,cpm1-pario-bank16) + cpm1_gpiochip_add16(np); + + for_each_compatible_node(np, NULL, fsl,cpm1-pario-bank32b) + cpm1_gpiochip_add32(np); + + /* Port E uses CPM2 layout */ + for_each_compatible_node(np, NULL, fsl,cpm1-pario-bank32e) + cpm2_gpiochip_add32(np); What do you suggest here? All GPIO ports of CPM1/CPM2 are on the SoC, so the chip name is in fact the CPU itself (like fsl,mpc866-pario-bank16). Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
Hi Jean, I'm not the one to push this upstream though, as the patch is essentially an openfirmware patch. That would be something for Jochen Friedrich and Paul Mackerras I guess. Would be nice to have a MAINTAINERS entry for OF... Nope. I only did a small contribution to the OF stuff. I guess, Grant Likely or Stephen Rothwell are the defacto maintainers for OF. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Commits added to powerpc.git master and powerpc-next branches
Hi Paul, On Tuesday 01 July 2008, Paul Mackerras wrote: The following commits have been added to the master and powerpc-next branches of the powerpc.git repository. This includes patches pulled from Kumar's and Josh's trees. Now that the I2C driver for CPM1/CPM2 boards is in the i2c tree, is there any chance to get this one into 2.6.27? [POWERPC] Add i2c pins to dts and board setup http://patchwork.ozlabs.org/linuxppc/patch?person=1023id=18603 Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
Doing this at the binary level would be nice, but I see enough problems just doing it at the source level and at least for my purposes, doing it on a dtb would be overkill, I think. The main difficulty remains how to deal with cross references between nodes in a reasonable way where the references cross from one fragment to another. Steve -Original Message- From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] Sent: Monday, June 30, 2008 11:22 PM To: Stephen Neuendorffer Cc: John Williams; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Michal Simek; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux- [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; John Linn; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [PATCH 12/60] microblaze_v4: Generic dts file for platforms As for the copyright, I haven't been able to find much information on whether or not generated files are even copyrightable. One might argue that they don't have sufficient 'creative value' to be copyrightable. Or arguably, they are as copyrightable by the generator author as by the author or the .mhs file. I admit in this case, I've followed the safe route by claiming a copyright, which at least at Xilinx has significant precedent. Also, thinking about your idea of sticking bits in BRAM etc... what would be nice would be the ability to merge trees. We've been talking about that multiple times, it would be useful at several levels: - We could provide pre-made DTs for known CPUs (ie, 440GP, 440GX, 405EX, ...) - Boards can then include that, and then override some properties (clocks, PHY wiring, ...) - That could be done at the binary level too so that the BRAM contains on overlay on top of the base ref. platform device-tree that comes with the kernel for example. This is slightly different between doing that in the .dts source via some kind of #include vs. doing that by merging blobs but we could make it be essentially be the same internally: The #include generates a blob that is then merged in. Just random thoughts... Ben. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Convert i2c-mpc from a platform driver into a of_platform driver, V4
Hi Jon,
On Mon, 30 Jun 2008 19:01:26 -0400, Jon Smirl wrote:
Convert i2c-mpc to an of_platform driver. Utilize the code in drivers/of-i2c.c
to make i2c modules dynamically loadable by the device tree.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 122
-
drivers/i2c/busses/i2c-mpc.c | 104 ---
2 files changed, 60 insertions(+), 166 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3a7054e..ebcec73 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -414,128 +414,6 @@ err:
arch_initcall(gfar_of_init);
-#ifdef CONFIG_I2C_BOARDINFO
-#include linux/i2c.h
-struct i2c_driver_device {
- char*of_device;
- char*i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] __initdata = {
- {ricoh,rs5c372a, rs5c372a},
- {ricoh,rs5c372b, rs5c372b},
- {ricoh,rv5c386, rv5c386},
- {ricoh,rv5c387a, rv5c387a},
- {dallas,ds1307, ds1307},
- {dallas,ds1337, ds1337},
- {dallas,ds1338, ds1338},
- {dallas,ds1339, ds1339},
- {dallas,ds1340, ds1340},
- {stm,m41t00, m41t00},
- {dallas,ds1374, rtc-ds1374},
-};
-
-static int __init of_find_i2c_driver(struct device_node *node,
- struct i2c_board_info *info)
-{
- int i;
-
- for (i = 0; i ARRAY_SIZE(i2c_devices); i++) {
- if (!of_device_is_compatible(node, i2c_devices[i].of_device))
- continue;
- if (strlcpy(info-type, i2c_devices[i].i2c_type,
- I2C_NAME_SIZE) = I2C_NAME_SIZE)
- return -ENOMEM;
- return 0;
- }
- return -ENODEV;
-}
-
-static void __init of_register_i2c_devices(struct device_node *adap_node,
-int bus_num)
-{
- struct device_node *node = NULL;
-
- while ((node = of_get_next_child(adap_node, node))) {
- struct i2c_board_info info = {};
- const u32 *addr;
- int len;
-
- addr = of_get_property(node, reg, len);
- if (!addr || len sizeof(int) || *addr (1 10) - 1) {
- printk(KERN_WARNING fsl_soc.c: invalid i2c device
entry\n);
- continue;
- }
-
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- if (of_find_i2c_driver(node, info) 0)
- continue;
-
- info.addr = *addr;
-
- i2c_register_board_info(bus_num, info, 1);
- }
-}
-
-static int __init fsl_i2c_of_init(void)
-{
- struct device_node *np;
- unsigned int i = 0;
- struct platform_device *i2c_dev;
- int ret;
-
- for_each_compatible_node(np, NULL, fsl-i2c) {
- struct resource r[2];
- struct fsl_i2c_platform_data i2c_data;
- const unsigned char *flags = NULL;
-
- memset(r, 0, sizeof(r));
- memset(i2c_data, 0, sizeof(i2c_data));
-
- ret = of_address_to_resource(np, 0, r[0]);
- if (ret)
- goto err;
-
- of_irq_to_resource(np, 0, r[1]);
-
- i2c_dev = platform_device_register_simple(fsl-i2c, i, r, 2);
- if (IS_ERR(i2c_dev)) {
- ret = PTR_ERR(i2c_dev);
- goto err;
- }
-
- i2c_data.device_flags = 0;
- flags = of_get_property(np, dfsrr, NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
-
- flags = of_get_property(np, fsl5200-clocking, NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
-
- ret =
- platform_device_add_data(i2c_dev, i2c_data,
- sizeof(struct
- fsl_i2c_platform_data));
- if (ret)
- goto unreg;
-
- of_register_i2c_devices(np, i++);
- }
-
- return 0;
-
-unreg:
- platform_device_unregister(i2c_dev);
-err:
- return ret;
-}
-
-arch_initcall(fsl_i2c_of_init);
-#endif
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index a076129..4fdfb62 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -17,7 +17,8 @@
#include linux/module.h
#include linux/sched.h
#include linux/init.h
-#include linux/platform_device.h
+#include linux/of_platform.h
+#include linux/of_i2c.h
#include asm/io.h
#include linux/fsl_devices.h
@@ -25,13
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote:
Hi Jon,
On Mon, 30 Jun 2008 19:01:28 -0400, Jon Smirl wrote:
Add the of_find_i2c_device_by_node function. This allows you to
follow a reference in the device to an i2c device node and then
locate the linux device instantiated by the device tree. Example
use, an i2s codec controlled by i2c.
---
drivers/i2c/i2c-core.c |2 +-
drivers/of/of_i2c.c| 37 ++---
include/linux/i2c.h|3 +++
include/linux/of_i2c.h |2 ++
4 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index d0175f4..e3abe1b 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -208,7 +208,7 @@ static struct device_attribute i2c_dev_attrs[] = {
{ },
};
-static struct bus_type i2c_bus_type = {
+struct bus_type i2c_bus_type = {
.name = i2c,
.dev_attrs = i2c_dev_attrs,
.match = i2c_device_match,
What if i2c-core is built as a module? Don't you need to export the
symbol then?
Jean, can you re-export i2c_bus_type and then I'll drop that part from
the patch? That way the patch won't hit multiple maintainers.
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index 715a444..ca69a16 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -75,7 +75,7 @@ static int of_find_i2c_driver(struct device_node *node,
void of_register_i2c_devices(struct i2c_adapter *adap,
struct device_node *adap_node)
{
- void *result;
+ struct i2c_client *i2c_dev;
struct device_node *node;
for_each_child_of_node(adap_node, node) {
@@ -90,29 +90,44 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
continue;
}
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- if (of_find_i2c_driver(node, info) 0) {
- irq_dispose_mapping(info.irq);
+ if (of_find_i2c_driver(node, info) 0)
continue;
- }
+ info.irq = irq_of_parse_and_map(node, 0);
info.addr = *addr;
- request_module(info.type);
+ request_module(%s, info.type);
A separate fix for this issue was already sent by Maximilian Attems a
few days go:
http://lists.lm-sensors.org/pipermail/i2c/2008-June/004030.html
- result = i2c_new_device(adap, info);
- if (result == NULL) {
+ i2c_dev = i2c_new_device(adap, info);
+ if (i2c_dev == NULL) {
printk(KERN_ERR
of-i2c: Failed to load driver for %s\n,
info.type);
irq_dispose_mapping(info.irq);
continue;
}
+
+ i2c_dev-dev.archdata.of_node = of_node_get(node);
}
}
EXPORT_SYMBOL(of_register_i2c_devices);
+static int of_dev_node_match(struct device *dev, void *data)
+{
+return dev-archdata.of_node == data;
+}
+
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
+{
+ struct device *dev;
+
+ dev = bus_find_device(i2c_bus_type, NULL, node,
+ of_dev_node_match);
+ if (!dev)
+ return NULL;
+
+ return to_i2c_client(dev);
+}
+EXPORT_SYMBOL(of_find_i2c_device_by_node);
+
MODULE_LICENSE(GPL);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index fb9af6a..186b22d 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -92,6 +92,9 @@ extern s32 i2c_smbus_read_i2c_block_data(struct
i2c_client * client,
extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client,
u8 command, u8 length,
const u8 *values);
+
+/* Base of the i2c bus */
+extern struct bus_type i2c_bus_type;
/*
* A driver is capable of handling one or more physical devices present on
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
index bd2a870..17d5897 100644
--- a/include/linux/of_i2c.h
+++ b/include/linux/of_i2c.h
@@ -16,5 +16,7 @@
void of_register_i2c_devices(struct i2c_adapter *adap,
struct device_node *adap_node);
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node);
+
#endif /* __LINUX_OF_I2C_H */
I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
It was un-exported only because it had no user left, but it can be
exported again if needed.
I'm not the one
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote: I'm fine with this patch. In particular, exporting i2c_bus_type is OK. It was un-exported only because it had no user left, but it can be exported again if needed. Another solution would be to move drivers/of/of_i2c into the i2c directory and make it part of i2c core on powerpc builds. I don't think this is a good idea. Merging arch-specific code (or half-arch-specific code in this case) into arch-neutral drivers ends up being a pain to maintain. People will keep sending me patches for stuff I don't know anything about and can't help with. Having of-specific stuff in just one directory as is the case now sounds much better to me. All it's missing is a MAINTAINERS entry. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: legacy_serial: reg-offset shift aren't used
The legacy serial driver does not work with an 8250 type UART that uses reg-offset and reg-shift. This change updates the driver so it doesn't find the UART when those properties are present on the UART in the device tree for soc devices. Signed-off-by: John Linn [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] --- arch/powerpc/kernel/legacy_serial.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c index 61dd174..b43235f 100644 --- a/arch/powerpc/kernel/legacy_serial.c +++ b/arch/powerpc/kernel/legacy_serial.c @@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct device_node *np, if (of_get_property(np, clock-frequency, NULL) == NULL) return -1; + /* if reg-shift and offset, don't try to use it */ + if ((of_get_property(np, reg-shift, NULL) != NULL) + (of_get_property(np, reg-offset, NULL) != NULL)) + return -1; + /* if rtas uses this device, don't try to use it as well */ if (of_get_property(np, used-by-rtas, NULL) != NULL) return -1; -- 1.5.2.1 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 12:29:29 -0400, Jon Smirl wrote:
On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote:
Hi Jon,
On Mon, 30 Jun 2008 19:01:28 -0400, Jon Smirl wrote:
Add the of_find_i2c_device_by_node function. This allows you to
follow a reference in the device to an i2c device node and then
locate the linux device instantiated by the device tree. Example
use, an i2s codec controlled by i2c.
---
drivers/i2c/i2c-core.c |2 +-
drivers/of/of_i2c.c| 37 ++---
include/linux/i2c.h|3 +++
include/linux/of_i2c.h |2 ++
4 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index d0175f4..e3abe1b 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -208,7 +208,7 @@ static struct device_attribute i2c_dev_attrs[] = {
{ },
};
-static struct bus_type i2c_bus_type = {
+struct bus_type i2c_bus_type = {
.name = i2c,
.dev_attrs = i2c_dev_attrs,
.match = i2c_device_match,
What if i2c-core is built as a module? Don't you need to export the
symbol then?
Jean, can you re-export i2c_bus_type and then I'll drop that part from
the patch? That way the patch won't hit multiple maintainers.
Just send me a patch doing just that and I will be glad to push early in
the 2.6.27 merge window.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH2/2] [POWERPC] CPM1: implement GPIO LIB API on CPM1 Freescale SoC.
On Tue, Jul 01, 2008 at 05:40:46PM +0200, Jochen Friedrich wrote: Hi Grant, sorry for the late response on this one. 2. You need to specifiy exact chip names in your compatible string. fsl,cpm1-pario-bank is a made up thing. + for_each_compatible_node(np, NULL, fsl,cpm1-pario-bank16) + cpm1_gpiochip_add16(np); + + for_each_compatible_node(np, NULL, fsl,cpm1-pario-bank32b) + cpm1_gpiochip_add32(np); + + /* Port E uses CPM2 layout */ + for_each_compatible_node(np, NULL, fsl,cpm1-pario-bank32e) + cpm2_gpiochip_add32(np); What do you suggest here? All GPIO ports of CPM1/CPM2 are on the SoC, so the chip name is in fact the CPU itself (like fsl,mpc866-pario-bank16). Right; so that is what I think you should call them. 'fsl,mpc866-*' instead of 'fsl,cpm1-*'. If multiple mpc8xx parts have the cpm1 core, then choose one of the parts for all the others to claim compatibility with. Now, there is a possible exception here... *IF* 'fsl,cpm1' is a very well defined ASIC logic block that is known to be identical or versioned between the various 8xx parts, *THEN* it is probably okay to call it fsl,cpm1 and my previous comment does not apply. But, I think it must be documented in the device tree binding as to what it is and where to get documentation for it. And you should still have the first compatible value to be something like fsl,mpc866-pario-bank16, followed by the cpm ones. This was recently discussed between Kim and Segher. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: boot: update for initrd with simpleImage
This change to the makefile corrects the build of a simpleImage with initrd. Signed-off-by: John Linn [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] --- arch/powerpc/boot/Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 1cee2f9..095e04d 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -273,7 +273,8 @@ endif initrd- := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-)) initrd-y := $(patsubst zImage%, zImage.initrd%, \ $(patsubst dtbImage%, dtbImage.initrd%, \ - $(patsubst treeImage%, treeImage.initrd%, $(image-y + $(patsubst simpleImage%, simpleImage.initrd%, \ + $(patsubst treeImage%, treeImage.initrd%, $(image-y) initrd-y := $(filter-out $(image-y), $(initrd-y)) targets+= $(image-y) $(initrd-y) -- 1.5.2.1 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote: On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote: I'm fine with this patch. In particular, exporting i2c_bus_type is OK. It was un-exported only because it had no user left, but it can be exported again if needed. Another solution would be to move drivers/of/of_i2c into the i2c directory and make it part of i2c core on powerpc builds. I don't think this is a good idea. Merging arch-specific code (or half-arch-specific code in this case) into arch-neutral drivers ends up being a pain to maintain. People will keep sending me patches for stuff I don't know anything about and can't help with. Having of-specific stuff in just one directory as is the case now sounds much better to me. All it's missing is a MAINTAINERS entry. A side effect of this is that the small pieces of code in drivers/of have to be compiled into stand alone modules and they may need access to internal symbols from the subsystem. If they were directly linked into the subsystems you wouldn't need to make the internal symbols visible. Now the subsystems have to be careful about breaking the in-kernel, external users of the symbols and we've made it possible for out of tree drivers to get to internal structures. -- Jean Delvare -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Xilinx: adding Xilinx 440 cpu support
The following change updates the cputable to support the
440 processor in the Xilinx Virtex5 FXT FPGA.
Signed-off-by: John Linn [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]
---
arch/powerpc/kernel/cputable.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e44d553..ae3660b 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1410,6 +1410,16 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_440A,
.platform = ppc440,
},
+ { /* 440 in Xilinx Virtex-5 FXT */
+ .pvr_mask = 0xfff0,
+ .pvr_value = 0x7ff21910,
+ .cpu_name = 440 in Virtex-5 FXT,
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .platform = ppc440,
+ },
{ /* 460EX */
.pvr_mask = 0x0002,
.pvr_value = 0x13020002,
--
1.5.2.1
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, Jul 01, 2008 at 11:12:58AM -0400, Jon Smirl wrote: On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote: I'm fine with this patch. In particular, exporting i2c_bus_type is OK. It was un-exported only because it had no user left, but it can be exported again if needed. Another solution would be to move drivers/of/of_i2c into the i2c directory and make it part of i2c core on powerpc builds. My preference is for things like of_spi and of_i2c to go with the related busses; I think it makes more sense to keep all the I2C stuff together, but I've already lost that battle once. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 12:38:05 -0400, Jon Smirl wrote: On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote: On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote: I'm fine with this patch. In particular, exporting i2c_bus_type is OK. It was un-exported only because it had no user left, but it can be exported again if needed. Another solution would be to move drivers/of/of_i2c into the i2c directory and make it part of i2c core on powerpc builds. I don't think this is a good idea. Merging arch-specific code (or half-arch-specific code in this case) into arch-neutral drivers ends up being a pain to maintain. People will keep sending me patches for stuff I don't know anything about and can't help with. Having of-specific stuff in just one directory as is the case now sounds much better to me. All it's missing is a MAINTAINERS entry. A side effect of this is that the small pieces of code in drivers/of have to be compiled into stand alone modules and they may need access to internal symbols from the subsystem. If they were directly linked into the subsystems you wouldn't need to make the internal symbols visible. Do you think you'll need something else than i2c_bus_type? That I don't consider an i2c-core internal. As I said, the lack of export was simply due to a lack of user. Now the subsystems have to be careful about breaking the in-kernel, external users of the symbols Same holds if the code is merged into i2c-core. and we've made it possible for out of tree drivers to get to internal structures. Hopefully the namespaced exports which some kernel developers are working on, will become a reality soon, to mitigate that kind of issue. That being said... As an upstream kernel developer / maintainer, I don't care about that. If external modules make use of internals they shouldn't touch, and later changes cause them to break, that's none of my business. I leave this to distribution maintainers. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, Jul 01, 2008 at 06:29:49PM +0200, Jean Delvare wrote: On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote: I'm fine with this patch. In particular, exporting i2c_bus_type is OK. It was un-exported only because it had no user left, but it can be exported again if needed. Another solution would be to move drivers/of/of_i2c into the i2c directory and make it part of i2c core on powerpc builds. I don't think this is a good idea. Merging arch-specific code (or half-arch-specific code in this case) into arch-neutral drivers ends up being a pain to maintain. People will keep sending me patches for stuff I don't know anything about and can't help with. Having of-specific stuff in just one directory as is the case now sounds much better to me. All it's missing is a MAINTAINERS entry. But the other side of the coin is that each driver must have driver-specific OF code to translate data in the device tree to data usable by the driver. It doesn't make any sense to me for that stuff to live anywhere other that with the driver that it supports. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc: legacy_serial: reg-offset shift aren't used
-Original Message- From: John Linn [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2008 9:32 AM To: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stephen Neuendorffer Cc: John Linn Subject: [PATCH] powerpc: legacy_serial: reg-offset shift aren't used The legacy serial driver does not work with an 8250 type UART that uses reg-offset and reg-shift. This change updates the driver so it doesn't find the UART when those properties are present on the UART in the device tree for soc devices. Signed-off-by: John Linn [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] --- arch/powerpc/kernel/legacy_serial.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c index 61dd174..b43235f 100644 --- a/arch/powerpc/kernel/legacy_serial.c +++ b/arch/powerpc/kernel/legacy_serial.c @@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct device_node *np, if (of_get_property(np, clock-frequency, NULL) == NULL) return -1; + /* if reg-shift and offset, don't try to use it */ + if ((of_get_property(np, reg-shift, NULL) != NULL) + (of_get_property(np, reg-offset, NULL) != NULL)) + return -1; Um, shouldn't this be || ? + /* if rtas uses this device, don't try to use it as well */ if (of_get_property(np, used-by-rtas, NULL) != NULL) return -1; -- 1.5.2.1 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc: legacy_serial: reg-offset shift aren't used
It could be || but I didn't know if there were cases where that wouldn't be true. I don't know that code that well so I was being conservative and maybe shouldn't be. Our specific case works fine with since we have both in the device tree. -- John -Original Message- From: Stephen Neuendorffer Sent: Tuesday, July 01, 2008 10:48 AM To: John Linn; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [PATCH] powerpc: legacy_serial: reg-offset shift aren't used -Original Message- From: John Linn [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2008 9:32 AM To: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stephen Neuendorffer Cc: John Linn Subject: [PATCH] powerpc: legacy_serial: reg-offset shift aren't used The legacy serial driver does not work with an 8250 type UART that uses reg-offset and reg-shift. This change updates the driver so it doesn't find the UART when those properties are present on the UART in the device tree for soc devices. Signed-off-by: John Linn [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] --- arch/powerpc/kernel/legacy_serial.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c index 61dd174..b43235f 100644 --- a/arch/powerpc/kernel/legacy_serial.c +++ b/arch/powerpc/kernel/legacy_serial.c @@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct device_node *np, if (of_get_property(np, clock-frequency, NULL) == NULL) return -1; + /* if reg-shift and offset, don't try to use it */ + if ((of_get_property(np, reg-shift, NULL) != NULL) + (of_get_property(np, reg-offset, NULL) != NULL)) + return -1; Um, shouldn't this be || ? + /* if rtas uses this device, don't try to use it as well */ if (of_get_property(np, used-by-rtas, NULL) != NULL) return -1; -- 1.5.2.1 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Grant Likely [EMAIL PROTECTED] wrote:
On Tue, Jul 01, 2008 at 11:12:58AM -0400, Jon Smirl wrote:
On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote:
I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
It was un-exported only because it had no user left, but it can be
exported again if needed.
Another solution would be to move drivers/of/of_i2c into the i2c
directory and make it part of i2c core on powerpc builds.
My preference is for things like of_spi and of_i2c to go with the
related busses; I think it makes more sense to keep all the I2C stuff
together, but I've already lost that battle once.
This is a similar problem to adding aliases to the i2c driver drivers
for the device tree names of the i2c devices. Instead we have code in
drivers/of/of_i2c.c that tries to guess the translation from device
tree to linux names. Adding aliases to the drivers would eliminate the
need for of_find_i2c_driver().
I've previously posted patches implementing device tree names in the
drivers that used ifdef to only instantiate on powerpc builds. For
example
diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
index e07274d..9cd1770 100644
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
{ tps65011, TPS65011 },
{ tps65012, TPS65012 },
{ tps65013, TPS65013 },
+ OF_ID(ti,tps65010, TPS65010)
+ OF_ID(ti,tps65011, TPS65011)
+ OF_ID(ti,tps65012, TPS65012)
+ OF_ID(ti,tps65013, TPS65013)
{ },
};
MODULE_DEVICE_TABLE(i2c, tps65010_id);
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 10:45:18 -0600, Grant Likely wrote: On Tue, Jul 01, 2008 at 06:29:49PM +0200, Jean Delvare wrote: On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote: I'm fine with this patch. In particular, exporting i2c_bus_type is OK. It was un-exported only because it had no user left, but it can be exported again if needed. Another solution would be to move drivers/of/of_i2c into the i2c directory and make it part of i2c core on powerpc builds. I don't think this is a good idea. Merging arch-specific code (or half-arch-specific code in this case) into arch-neutral drivers ends up being a pain to maintain. People will keep sending me patches for stuff I don't know anything about and can't help with. Having of-specific stuff in just one directory as is the case now sounds much better to me. All it's missing is a MAINTAINERS entry. But the other side of the coin is that each driver must have driver-specific OF code to translate data in the device tree to data usable by the driver. It doesn't make any sense to me for that stuff to live anywhere other that with the driver that it supports. This code is glue between OF and subsystems. As with any glue code, you can argue forever on which side you want to push the code to. Both answers are valid. All I see on my personal side is that I don't have any system using OF and no knowledge about it either, so I can't maintain of_i2c. So having that file in drivers/of rather than drivers/i2c will make my life easier for sure. While I'd guess that most (all?) OF-based systems have an I2C bus, so whoever is responsible for drivers/of should be able to maintain of_i2c. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: legacy_serial: reg-offset shift aren't used
On Tue, Jul 01, 2008 at 10:52:20AM -0600, John Linn wrote: It could be || but I didn't know if there were cases where that wouldn't be true. I don't know that code that well so I was being conservative and maybe shouldn't be. No, Stephen is right. It should be || g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote: On Tue, 1 Jul 2008 10:45:18 -0600, Grant Likely wrote: On Tue, Jul 01, 2008 at 06:29:49PM +0200, Jean Delvare wrote: On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote: I'm fine with this patch. In particular, exporting i2c_bus_type is OK. It was un-exported only because it had no user left, but it can be exported again if needed. Another solution would be to move drivers/of/of_i2c into the i2c directory and make it part of i2c core on powerpc builds. I don't think this is a good idea. Merging arch-specific code (or half-arch-specific code in this case) into arch-neutral drivers ends up being a pain to maintain. People will keep sending me patches for stuff I don't know anything about and can't help with. Having of-specific stuff in just one directory as is the case now sounds much better to me. All it's missing is a MAINTAINERS entry. But the other side of the coin is that each driver must have driver-specific OF code to translate data in the device tree to data usable by the driver. It doesn't make any sense to me for that stuff to live anywhere other that with the driver that it supports. This code is glue between OF and subsystems. As with any glue code, you can argue forever on which side you want to push the code to. Both answers are valid. All I see on my personal side is that I don't have any system using OF and no knowledge about it either, so I can't maintain of_i2c. So having that file in drivers/of rather than drivers/i2c will make my life easier for sure. While I'd guess that most (all?) OF-based systems have an I2C bus, so whoever is responsible for drivers/of should be able to maintain of_i2c. We could modify the Makefile for i2c core to get the source out of drivers/of and link it into i2c-core. That would remove the need to export symbols. Or you could move the file into the i2c directory and just put a note on it that Grant is the maintainer. -- Jean Delvare -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc: legacy_serial: reg-offset shift aren't used
I'll respin the patch and send again. -- John -Original Message- From: Grant Likely [mailto:[EMAIL PROTECTED] On Behalf Of Grant Likely Sent: Tuesday, July 01, 2008 11:06 AM To: John Linn Cc: Stephen Neuendorffer; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] powerpc: legacy_serial: reg-offset shift aren't used On Tue, Jul 01, 2008 at 10:52:20AM -0600, John Linn wrote: It could be || but I didn't know if there were cases where that wouldn't be true. I don't know that code that well so I was being conservative and maybe shouldn't be. No, Stephen is right. It should be || g. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote:
On 7/1/08, Grant Likely [EMAIL PROTECTED] wrote:
My preference is for things like of_spi and of_i2c to go with the
related busses; I think it makes more sense to keep all the I2C stuff
together, but I've already lost that battle once.
This is a similar problem to adding aliases to the i2c driver drivers
for the device tree names of the i2c devices. Instead we have code in
drivers/of/of_i2c.c that tries to guess the translation from device
tree to linux names. Adding aliases to the drivers would eliminate the
need for of_find_i2c_driver().
I've previously posted patches implementing device tree names in the
drivers that used ifdef to only instantiate on powerpc builds. For
example
diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
index e07274d..9cd1770 100644
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
{ tps65011, TPS65011 },
{ tps65012, TPS65012 },
{ tps65013, TPS65013 },
+ OF_ID(ti,tps65010, TPS65010)
+ OF_ID(ti,tps65011, TPS65011)
+ OF_ID(ti,tps65012, TPS65012)
+ OF_ID(ti,tps65013, TPS65013)
{ },
};
MODULE_DEVICE_TABLE(i2c, tps65010_id);
Yeah, yeah, you've been asking for this for months already, but it's
just not going to happen, sorry. You want to abuse the standard Linux
alias mechanism for your personal (i.e. openfirmware) use, but that's
bad. Linux drivers shouldn't have to know whether they are used in
openfirmware trees and what device names are used there. And device
names as seen by user-space shouldn't vary depending on whether the
device comes from an openfirmware tree or not - otherwise all
user-space apps need to learn about both naming conversions.
Unsurprisingly, no other subsystem does what you propose.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote:
On 7/1/08, Grant Likely [EMAIL PROTECTED] wrote:
My preference is for things like of_spi and of_i2c to go with the
related busses; I think it makes more sense to keep all the I2C stuff
together, but I've already lost that battle once.
This is a similar problem to adding aliases to the i2c driver drivers
for the device tree names of the i2c devices. Instead we have code in
drivers/of/of_i2c.c that tries to guess the translation from device
tree to linux names. Adding aliases to the drivers would eliminate the
need for of_find_i2c_driver().
I've previously posted patches implementing device tree names in the
drivers that used ifdef to only instantiate on powerpc builds. For
example
diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
index e07274d..9cd1770 100644
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
{ tps65011, TPS65011 },
{ tps65012, TPS65012 },
{ tps65013, TPS65013 },
+ OF_ID(ti,tps65010, TPS65010)
+ OF_ID(ti,tps65011, TPS65011)
+ OF_ID(ti,tps65012, TPS65012)
+ OF_ID(ti,tps65013, TPS65013)
{ },
};
MODULE_DEVICE_TABLE(i2c, tps65010_id);
Yeah, yeah, you've been asking for this for months already, but it's
just not going to happen, sorry. You want to abuse the standard Linux
alias mechanism for your personal (i.e. openfirmware) use, but that's
bad. Linux drivers shouldn't have to know whether they are used in
openfirmware trees and what device names are used there. And device
names as seen by user-space shouldn't vary depending on whether the
device comes from an openfirmware tree or not - otherwise all
user-space apps need to learn about both naming conversions.
Unsurprisingly, no other subsystem does what you propose.
Then what are all of the PCI aliases doing?
The only difference is that you are recognizing the PCI group as a
naming authority and not recognizing the PowerPC device tree group.
But on the PowerPC platform that is our naming authority. That's why I
proposed adding the names on ifdefs so that they disappear on non
PowerPC platforms.
PS - adding an alias to a driver does not change the name of the
driver. My PCI e1000 module has about 100 aliases but it is always
e1000.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [V2] powerpc: legacy_serial: reg-offset shift aren't used
The legacy serial driver does not work with an 8250 type UART that uses reg-offset and reg-shift. This change updates the driver so it doesn't find the UART when those properties are present on the UART in the device tree for soc devices. Signed-off-by: John Linn [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] --- V2 Corrected logic to use || rather than . arch/powerpc/kernel/legacy_serial.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c index 61dd174..cf37f5c 100644 --- a/arch/powerpc/kernel/legacy_serial.c +++ b/arch/powerpc/kernel/legacy_serial.c @@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct device_node *np, if (of_get_property(np, clock-frequency, NULL) == NULL) return -1; + /* if reg-shift or offset, don't try to use it */ + if ((of_get_property(np, reg-shift, NULL) != NULL) || + (of_get_property(np, reg-offset, NULL) != NULL)) + return -1; + /* if rtas uses this device, don't try to use it as well */ if (of_get_property(np, used-by-rtas, NULL) != NULL) return -1; -- 1.5.2.1 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] IB/ehca: Make device table externally visible
thanks, applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH] powerpc/bootwrapper: Allow user to specify additional default targets
From: Grant Likely [EMAIL PROTECTED] It is inconvenient to add additional default targets to the bootwrapper Makefile for each new board supported which just needs a different dts file. This change allows the defconfig to specify additional build targets. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- arch/powerpc/Kconfig | 13 + arch/powerpc/boot/Makefile |3 +++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 3934e26..f09f617 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -458,6 +458,19 @@ config CMDLINE some command-line options at build time by entering them here. In most cases you will need to specify the root device here. +config EXTRA_TARGETS + string Additional default image types + help + List additional targets to be built by the bootwrapper here (separated + by spaces). This is useful for targets that depend of device tree + files in the .dts directory. + + Targets in this list will be build as part of the default build + target, or when the user does a 'make zImage' or a + 'make zImage.initrd'. + + If unsure, leave blank + if !44x || BROKEN config ARCH_WANTS_FREEZER_CONTROL def_bool y diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 1cee2f9..1e38237 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -270,6 +270,9 @@ ifeq ($(CONFIG_PPC32),y) image-$(CONFIG_PPC_PMAC) += zImage.coff zImage.miboot endif +# Allow extra targets to be added to the defconfig +image-y+= $(subst ,,$(CONFIG_EXTRA_TARGETS)) + initrd- := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-)) initrd-y := $(patsubst zImage%, zImage.initrd%, \ $(patsubst dtbImage%, dtbImage.initrd%, \ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Parameterize EMAC Multicast Match Handling
On 6/30/08 11:37 PM, Stefan Roese wrote: On Tuesday 01 July 2008, Benjamin Herrenschmidt wrote: Stefan and/or Ben: Any thoughts on this? I was hesitating a bit... do we really need to be -that- flexible ? That is, either that or use some new compatible entry to detect the new reg layout and whack that as a feature bit instead ? The advantage of the later is that we have the possibility of doing conditional compile for kernels that support only a given processor or set of processors (not that we have implemented much of it, but it just becomes Kconfig mumbo jumbo and a little bit of defines in the .h by turning the feature test into a compile-time 0 or 1. But this isn't a hot path and not a lot of code so maybe not worth bothering... however, it does add 3 properties to the DT and I know embedded people (especially Xilinx) are a bit concerned about the size of the DT when they try to fit it in block RAM... Yes, this was my feeling too. Not the size of the dtb but more the increased complexity of the EMAC device node. I would prefer Ben's idea with this new compatible entry too. In terms of the device tree expression, you would both favor something akin to the following? - compatible = ibm,emac-405exr, ibm,emac4; + compatible = ibm,emac-405exr, ibm,emac4, ibm,emac4sync; Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch] PS3: Quiet system bus match output
Reduce the output verbosity of ps3_system_bus_match(). Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- Paul, Please queue for 2.6.27. -Geoff arch/powerpc/platforms/ps3/system-bus.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) --- a/arch/powerpc/platforms/ps3/system-bus.c +++ b/arch/powerpc/platforms/ps3/system-bus.c @@ -349,9 +349,14 @@ static int ps3_system_bus_match(struct d result = dev-match_id == drv-match_id; - pr_info(%s:%d: dev=%u(%s), drv=%u(%s): %s\n, __func__, __LINE__, - dev-match_id, dev-core.bus_id, drv-match_id, drv-core.name, - (result ? match : miss)); + if (result) + pr_info(%s:%d: dev=%u(%s), drv=%u(%s): match\n, __func__, + __LINE__, dev-match_id, dev-core.bus_id, + drv-match_id, drv-core.name); + else + pr_debug(%s:%d: dev=%u(%s), drv=%u(%s): miss\n, __func__, + __LINE__, dev-match_id, dev-core.bus_id, + drv-match_id, drv-core.name); return result; } @@ -362,7 +367,7 @@ static int ps3_system_bus_probe(struct d struct ps3_system_bus_driver *drv; BUG_ON(!dev); - pr_info( - %s:%d: %s\n, __func__, __LINE__, _dev-bus_id); + pr_debug( - %s:%d: %s\n, __func__, __LINE__, _dev-bus_id); drv = ps3_system_bus_dev_to_system_bus_drv(dev); BUG_ON(!drv); @@ -370,10 +375,10 @@ static int ps3_system_bus_probe(struct d if (drv-probe) result = drv-probe(dev); else - pr_info(%s:%d: %s no probe method\n, __func__, __LINE__, + pr_debug(%s:%d: %s no probe method\n, __func__, __LINE__, dev-core.bus_id); - pr_info( - %s:%d: %s\n, __func__, __LINE__, dev-core.bus_id); + pr_debug( - %s:%d: %s\n, __func__, __LINE__, dev-core.bus_id); return result; } @@ -384,7 +389,7 @@ static int ps3_system_bus_remove(struct struct ps3_system_bus_driver *drv; BUG_ON(!dev); - pr_info( - %s:%d: %s\n, __func__, __LINE__, _dev-bus_id); + pr_debug( - %s:%d: %s\n, __func__, __LINE__, _dev-bus_id); drv = ps3_system_bus_dev_to_system_bus_drv(dev); BUG_ON(!drv); @@ -395,7 +400,7 @@ static int ps3_system_bus_remove(struct dev_dbg(dev-core, %s:%d %s: no remove method\n, __func__, __LINE__, drv-core.name); - pr_info( - %s:%d: %s\n, __func__, __LINE__, dev-core.bus_id); + pr_debug( - %s:%d: %s\n, __func__, __LINE__, dev-core.bus_id); return result; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jon Smirl [EMAIL PROTECTED] wrote:
On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote:
On 7/1/08, Grant Likely [EMAIL PROTECTED] wrote:
My preference is for things like of_spi and of_i2c to go with the
related busses; I think it makes more sense to keep all the I2C stuff
together, but I've already lost that battle once.
This is a similar problem to adding aliases to the i2c driver drivers
for the device tree names of the i2c devices. Instead we have code in
drivers/of/of_i2c.c that tries to guess the translation from device
tree to linux names. Adding aliases to the drivers would eliminate the
need for of_find_i2c_driver().
I've previously posted patches implementing device tree names in the
drivers that used ifdef to only instantiate on powerpc builds. For
example
diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
index e07274d..9cd1770 100644
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
{ tps65011, TPS65011 },
{ tps65012, TPS65012 },
{ tps65013, TPS65013 },
+ OF_ID(ti,tps65010, TPS65010)
+ OF_ID(ti,tps65011, TPS65011)
+ OF_ID(ti,tps65012, TPS65012)
+ OF_ID(ti,tps65013, TPS65013)
{ },
};
MODULE_DEVICE_TABLE(i2c, tps65010_id);
Yeah, yeah, you've been asking for this for months already, but it's
just not going to happen, sorry. You want to abuse the standard Linux
alias mechanism for your personal (i.e. openfirmware) use, but that's
bad. Linux drivers shouldn't have to know whether they are used in
openfirmware trees and what device names are used there. And device
names as seen by user-space shouldn't vary depending on whether the
device comes from an openfirmware tree or not - otherwise all
user-space apps need to learn about both naming conversions.
Unsurprisingly, no other subsystem does what you propose.
Then what are all of the PCI aliases doing?
The only difference is that you are recognizing the PCI group as a
naming authority and not recognizing the PowerPC device tree group.
But on the PowerPC platform that is our naming authority. That's why I
proposed adding the names on ifdefs so that they disappear on non
PowerPC platforms.
PS - adding an alias to a driver does not change the name of the
driver. My PCI e1000 module has about 100 aliases but it is always
e1000.
Here's my e1000e sysfs entry:
[EMAIL PROTECTED]:/sys/bus/pci/devices/:00:19.0$ ls
broken_parity_status device local_cpus power resource2 uevent
bus driver modaliasresource subsystem vendor
class enable msi_bus resource0 subsystem_device
configirq net:eth0resource1 subsystem_vendor
[EMAIL PROTECTED]:/sys/bus/pci/devices/:00:19.0$ cat modalias
pci:v8086d104Bsv1028sd01DBbc02sc00i00
This is the module alias that was used to load the driver.
[EMAIL PROTECTED]:/sys/bus/pci/devices/:00:19.0$ ls -l driver
lrwxrwxrwx 1 root root 0 2008-07-01 08:52 driver -
../../../bus/pci/drivers/e1000e
The driver is always e1000e no matter which alias was used to load it.
e1000e is controled by the name field of the driver structure. That's
the publicly visible name for the driver.
Adding the OF aliases would change the modalias entry, not the driver
name.
The i2c implementation is adding a field to a device entry that
contains the driver name. No other device drivers I could find do
this.
[EMAIL PROTECTED]:/sys/bus/i2c/devices/1-0050$ ls
bus driver eeprom modalias name power subsystem uevent
[EMAIL PROTECTED]:/sys/bus/i2c/devices/1-0050$ cat name
eeprom
[EMAIL PROTECTED]:/sys/bus/i2c/devices/1-0050$ ls -l driver
lrwxrwxrwx 1 root root 0 2008-07-01 14:05 driver -
../../../../bus/i2c/drivers/eeprom
[EMAIL PROTECTED]:/sys/bus/i2c/devices/1-0050$ cat modalias
[EMAIL PROTECTED]:/sys/bus/i2c/devices/1-0050$
I believe the correct way to get the driver name from sysfs is to
follow the driver link. The name field is probably legacy. Other
drivers in the system don't have a name entry on the device node.
Is the user space i2c code looking at the modalias entry?
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add the of_find_i2c_device_by_node function, standalone V1
Add the of_find_i2c_device_by_node function. This allows you to follow a
reference in the device tree to an i2c device node and then locate the linux
device instantiated by the device tree. Example use, an i2s codec controlled by
i2c. Depends on patch exporting i2c root bus symbol.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
drivers/of/of_i2c.c| 37 ++---
include/linux/of_i2c.h |2 ++
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index 715a444..ca69a16 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -75,7 +75,7 @@ static int of_find_i2c_driver(struct device_node *node,
void of_register_i2c_devices(struct i2c_adapter *adap,
struct device_node *adap_node)
{
- void *result;
+ struct i2c_client *i2c_dev;
struct device_node *node;
for_each_child_of_node(adap_node, node) {
@@ -90,29 +90,44 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
continue;
}
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- if (of_find_i2c_driver(node, info) 0) {
- irq_dispose_mapping(info.irq);
+ if (of_find_i2c_driver(node, info) 0)
continue;
- }
+ info.irq = irq_of_parse_and_map(node, 0);
info.addr = *addr;
- request_module(info.type);
+ request_module(%s, info.type);
- result = i2c_new_device(adap, info);
- if (result == NULL) {
+ i2c_dev = i2c_new_device(adap, info);
+ if (i2c_dev == NULL) {
printk(KERN_ERR
of-i2c: Failed to load driver for %s\n,
info.type);
irq_dispose_mapping(info.irq);
continue;
}
+
+ i2c_dev-dev.archdata.of_node = of_node_get(node);
}
}
EXPORT_SYMBOL(of_register_i2c_devices);
+static int of_dev_node_match(struct device *dev, void *data)
+{
+return dev-archdata.of_node == data;
+}
+
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
+{
+ struct device *dev;
+
+ dev = bus_find_device(i2c_bus_type, NULL, node,
+of_dev_node_match);
+ if (!dev)
+ return NULL;
+
+ return to_i2c_client(dev);
+}
+EXPORT_SYMBOL(of_find_i2c_device_by_node);
+
MODULE_LICENSE(GPL);
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
index bd2a870..17d5897 100644
--- a/include/linux/of_i2c.h
+++ b/include/linux/of_i2c.h
@@ -16,5 +16,7 @@
void of_register_i2c_devices(struct i2c_adapter *adap,
struct device_node *adap_node);
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node);
+
#endif /* __LINUX_OF_I2C_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 13:27:57 -0400, Jon Smirl wrote:
On 7/1/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote:
On 7/1/08, Grant Likely [EMAIL PROTECTED] wrote:
My preference is for things like of_spi and of_i2c to go with the
related busses; I think it makes more sense to keep all the I2C stuff
together, but I've already lost that battle once.
This is a similar problem to adding aliases to the i2c driver drivers
for the device tree names of the i2c devices. Instead we have code in
drivers/of/of_i2c.c that tries to guess the translation from device
tree to linux names. Adding aliases to the drivers would eliminate the
need for of_find_i2c_driver().
I've previously posted patches implementing device tree names in the
drivers that used ifdef to only instantiate on powerpc builds. For
example
diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
index e07274d..9cd1770 100644
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
{ tps65011, TPS65011 },
{ tps65012, TPS65012 },
{ tps65013, TPS65013 },
+ OF_ID(ti,tps65010, TPS65010)
+ OF_ID(ti,tps65011, TPS65011)
+ OF_ID(ti,tps65012, TPS65012)
+ OF_ID(ti,tps65013, TPS65013)
{ },
};
MODULE_DEVICE_TABLE(i2c, tps65010_id);
Yeah, yeah, you've been asking for this for months already, but it's
just not going to happen, sorry. You want to abuse the standard Linux
alias mechanism for your personal (i.e. openfirmware) use, but that's
bad. Linux drivers shouldn't have to know whether they are used in
openfirmware trees and what device names are used there. And device
names as seen by user-space shouldn't vary depending on whether the
device comes from an openfirmware tree or not - otherwise all
user-space apps need to learn about both naming conversions.
Unsurprisingly, no other subsystem does what you propose.
Then what are all of the PCI aliases doing?
The only difference is that you are recognizing the PCI group as a
naming authority and not recognizing the PowerPC device tree group.
But on the PowerPC platform that is our naming authority. That's why I
proposed adding the names on ifdefs so that they disappear on non
PowerPC platforms.
You're comparing PCI devices those ID is built-in, with I2C devices
with no ID. This just can't compare.
PS - adding an alias to a driver does not change the name of the
driver. My PCI e1000 module has about 100 aliases but it is always
e1000.
I said device names, not driver names. Linux I2C devices have a name
attribute which contains the (Linux) device name. That's something a
number of user-space applications are relying on.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Parameterize EMAC Multicast Match Handling
On Tuesday 01 July 2008, Grant Erickson wrote: Yes, this was my feeling too. Not the size of the dtb but more the increased complexity of the EMAC device node. I would prefer Ben's idea with this new compatible entry too. In terms of the device tree expression, you would both favor something akin to the following? - compatible = ibm,emac-405exr, ibm,emac4; + compatible = ibm,emac-405exr, ibm,emac4, ibm,emac4sync; If this is how IBM/AMCC call this new EMAC version, then yes. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 27/60] microblaze_v4: virtualization
On Thu, Jun 26, 2008 at 02:29:56PM +0200, [EMAIL PROTECTED] wrote: From: Michal Simek [EMAIL PROTECTED] Signed-off-by: Michal Simek [EMAIL PROTECTED] --- include/asm-microblaze/kvm.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 include/asm-microblaze/kvm.h diff --git a/include/asm-microblaze/kvm.h b/include/asm-microblaze/kvm.h new file mode 100644 index 000..01c5e79 --- /dev/null +++ b/include/asm-microblaze/kvm.h @@ -0,0 +1 @@ +/* Microblaze does not support KVM */ There's a patch pending for 2.6.27 that will remove the requirement for this empty header. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/mpc5200: Fix lite5200b suspend/resume
From: Tim Yamin [EMAIL PROTECTED]
Suspend/resume (echo mem /sys/power/state) does not work with
vanilla kernels -- the system does not suspend correctly and just
hangs. This patch fixes this so suspend/resume works:
1) of_iomap does not map the whole 0xC000 of the MPC5200 immr so
saving registers does not work.
2) PCI registers need to be saved and restored.
Signed-off-by: Tim Yamin [EMAIL PROTECTED]
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
Tim, please test this version. I fixed a couple of bugs and want to make
sure I haven't broken anything. Once you ack it I'll ask Paul to pull it
into 2.6.26.
g.
arch/powerpc/platforms/52xx/lite5200_pm.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/lite5200_pm.c
b/arch/powerpc/platforms/52xx/lite5200_pm.c
index 41c7fd9..fe92e65 100644
--- a/arch/powerpc/platforms/52xx/lite5200_pm.c
+++ b/arch/powerpc/platforms/52xx/lite5200_pm.c
@@ -14,6 +14,7 @@ static struct mpc52xx_sdma __iomem *bes;
static struct mpc52xx_xlb __iomem *xlb;
static struct mpc52xx_gpio __iomem *gps;
static struct mpc52xx_gpio_wkup __iomem *gpw;
+static void __iomem *pci;
static void __iomem *sram;
static const int sram_size = 0x4000; /* 16 kBytes */
static void __iomem *mbar;
@@ -50,6 +51,8 @@ static int lite5200_pm_prepare(void)
{ .type = builtin, .compatible = mpc5200, }, /* efika */
{}
};
+ u64 regaddr64 = 0;
+ const u32 *regaddr_p;
/* deep sleep? let mpc52xx code handle that */
if (lite5200_pm_target_state == PM_SUSPEND_STANDBY)
@@ -60,8 +63,12 @@ static int lite5200_pm_prepare(void)
/* map registers */
np = of_find_matching_node(NULL, immr_ids);
- mbar = of_iomap(np, 0);
+ regaddr_p = of_get_address(np, 0, NULL, NULL);
+ if (regaddr_p)
+ regaddr64 = of_translate_address(np, regaddr_p);
of_node_put(np);
+
+ mbar = ioremap((u32) regaddr64, 0xC000);
if (!mbar) {
printk(KERN_ERR %s:%i Error mapping registers\n, __func__,
__LINE__);
return -ENOSYS;
@@ -71,6 +78,7 @@ static int lite5200_pm_prepare(void)
pic = mbar + 0x500;
gps = mbar + 0xb00;
gpw = mbar + 0xc00;
+ pci = mbar + 0xd00;
bes = mbar + 0x1200;
xlb = mbar + 0x1f00;
sram = mbar + 0x8000;
@@ -85,6 +93,7 @@ static struct mpc52xx_sdma sbes;
static struct mpc52xx_xlb sxlb;
static struct mpc52xx_gpio sgps;
static struct mpc52xx_gpio_wkup sgpw;
+static char spci[0x200];
static void lite5200_save_regs(void)
{
@@ -94,6 +103,7 @@ static void lite5200_save_regs(void)
_memcpy_fromio(sxlb, xlb, sizeof(*xlb));
_memcpy_fromio(sgps, gps, sizeof(*gps));
_memcpy_fromio(sgpw, gpw, sizeof(*gpw));
+ _memcpy_fromio(spci, pci, 0x200);
_memcpy_fromio(saved_sram, sram, sram_size);
}
@@ -103,6 +113,8 @@ static void lite5200_restore_regs(void)
int i;
_memcpy_toio(sram, saved_sram, sram_size);
+ /* PCI Configuration */
+ _memcpy_toio(pci, spci, 0x200);
/*
* GPIOs. Interrupt Master Enable has higher address then other
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull into 2.6.26
Hi Josh Paul, Here are a couple of last minute bug fixes for 2.6.26. These are both Xilinx 4xx related. Could either of you please pull the tree? Thanks, g. The following changes since commit 1702b52092e9a6d05398d3f9581ddc050ef00d06: Linus Torvalds (1): Merge git://git.kernel.org/.../mchehab/v4l-dvb are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-virtex.git virtex-for-2.6.26 John Linn (2): powerpc/bootwrapper: update for initrd with simpleImage powerpc/legacy_serial: Bail if reg-offset/shift properties are present arch/powerpc/boot/Makefile |3 ++- arch/powerpc/kernel/legacy_serial.c |5 + 2 files changed, 7 insertions(+), 1 deletions(-) -- 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]: [MPC5200] (v2) Add ATA DMA support
On Fri, Jun 27, 2008 at 01:44:08PM +0100, Tim Yamin wrote:
diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.c
linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.c
--- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.c 2008-03-18
15:49:53.0 +
+++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.c
2008-04-15 10:42:38.0 +0100
@@ -330,11 +330,10 @@
/* Init 'always' initiator */
out_8(bcom_eng-regs-ipr[BCOM_INITIATOR_ALWAYS], BCOM_IPR_ALWAYS);
- /* Disable COMM Bus Prefetch on the original 5200; it's broken */
- if ((mfspr(SPRN_SVR) MPC5200_SVR_MASK) == MPC5200_SVR) {
- regval = in_be16(bcom_eng-regs-PtdCntrl);
- out_be16(bcom_eng-regs-PtdCntrl, regval | 1);
- }
+ /* Disable COMM Bus Prefetch; ATA DMA does not work properly with it
+enabled. */
+ regval = in_be16(bcom_eng-regs-PtdCntrl);
+ out_be16(bcom_eng-regs-PtdCntrl, regval | 1);
This could have a performance impact on existing systems that don't
use/need ATA DMA.
Please run next version through checkpatch. There's lots of minor
cosmetic stuff, but there are also a few important errors.
diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.h
linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.h
--- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.h 2008-03-18
15:49:53.0 +
+++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.h
2008-04-15 10:42:38.0 +0100
@@ -17,6 +17,7 @@
#define __BESTCOMM_H__
struct bcom_bd; /* defined later on ... */
+struct bcom_bd_2;
/*
*/
@@ -49,6 +50,22 @@
void* priv;
};
+struct bcom_task_2 {
+ unsigned inttasknum;
+ unsigned intflags;
+ int irq;
+
+ struct bcom_bd_2*bd;
+ phys_addr_t bd_pa;
+ void**cookie;
+ unsigned short index;
+ unsigned short outdex;
+ unsigned intnum_bd;
+ unsigned intbd_size;
+
+ void* priv;
+};
+
Oh, ugly. The only difference seems to be that bcom_bd_2 is 1 word
larger than bcom_bd. There must be a better way to do this rather
than just duplicating all the functions and structures.. It would
probably be better to use bd_size to determine how to dereference an
index into the *bd list. It will require a bit of refactoring, but
it will be much cleaner and more maintainable that way.
diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h
linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h
--- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h
2008-03-18 15:49:53.0 +
+++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h
2008-04-15 10:42:38.0 +0100
@@ -198,8 +198,8 @@ struct bcom_task_header {
#define BCOM_IPR_SCTMR_1 2
#define BCOM_IPR_FEC_RX 6
#define BCOM_IPR_FEC_TX 5
-#define BCOM_IPR_ATA_RX 4
-#define BCOM_IPR_ATA_TX 3
+#define BCOM_IPR_ATA_RX 7
+#define BCOM_IPR_ATA_TX 7
#define BCOM_IPR_SCPCI_RX2
#define BCOM_IPR_SCPCI_TX2
#define BCOM_IPR_PSC3_RX 2
Is this a bug fix? If so, please put it into a separate patch.
diff -Nurp linux-2.6.26-rc6/drivers/ata/Kconfig
linux-2.6.26-rc6.new/drivers/ata/Kconfig
--- linux-2.6.26-rc6/drivers/ata/Kconfig 2008-03-18 15:49:33.0
+
+++ linux-2.6.26-rc6.new/drivers/ata/Kconfig 2008-04-15 10:41:51.0
+0100
@@ -462,6 +462,15 @@
If unsure, say N.
+config PATA_MPC52xx_DMA
+ tristate Freescale MPC52xx SoC internal IDE DMA
+ depends on PATA_MPC52xx
+ help
+ This option enables support for DMA on the MPC52xx SoC PATA
+ controller.
+
+ If unsure, say N.
+
Good, it can be turned off. Do you think there is any risk to existing
ATA users with this patch applied if this is turned off?
config PATA_MPIIX
tristate Intel PATA MPIIX support
depends on PCI
diff -Nurp linux-2.6.26-rc6/drivers/ata/pata_mpc52xx.c
linux-2.6.26-rc6.new/drivers/ata/pata_mpc52xx.c
--- linux-2.6.26-rc6/drivers/ata/pata_mpc52xx.c 2008-03-18
15:49:33.0 +
+++ linux-2.6.26-rc6.new/drivers/ata/pata_mpc52xx.c 2008-04-15
10:41:49.0 +0100
@@ -6,6 +6,9 @@
* Copyright (C) 2006 Sylvain Munaut [EMAIL PROTECTED]
* Copyright (C) 2003 Mipsys - Benjamin Herrenschmidt
*
+ * UDMA support based on patches by Freescale (Bernard Kuhn, John Rigby),
+ * Domen Puncer and Tim Yamin.
+ *
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed as is without any warranty of any
* kind, whether express or implied.
@@ -17,28 +20,47 @@
#include
Re: [PATCH v2] Parameterize EMAC Multicast Match Handling
On Tue, 2008-07-01 at 11:13 -0700, Grant Erickson wrote: In terms of the device tree expression, you would both favor something akin to the following? - compatible = ibm,emac-405exr, ibm,emac4; + compatible = ibm,emac-405exr, ibm,emac4, ibm,emac4sync; leave ibm,emac4 either at the end or totally out Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Grant Likely [EMAIL PROTECTED]
Simple utility layer for creating ASoC machine instances based on data
in the OpenFirmware device tree. OF aware platform drivers and codec
drivers register themselves with this framework and the framework
automatically instantiates a machine driver.
This is most likely temporary glue code to work around limitations in
the ASoC v1 framework. I expect ASoC v2 won't need this.
---
sound/soc/Kconfig |6 ++
sound/soc/Makefile |1
sound/soc/soc-of.c | 171
3 files changed, 178 insertions(+), 0 deletions(-)
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 18f28ac..c5736e5 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -23,6 +23,12 @@ config SND_SOC
This ASoC audio support can also be built as a module. If so, the
module
will be called snd-soc-core.
+config SND_SOC_OF
+ tristate OF helpers for SoC audio support
+ depends on SND_SOC
+ ---help---
+ Add support for OpenFirmware device tree descriptions of sound device
+
# All the supported Soc's
source sound/soc/at91/Kconfig
source sound/soc/pxa/Kconfig
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index 782db21..191c2e5 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -2,3 +2,4 @@ snd-soc-core-objs := soc-core.o soc-dapm.o
obj-$(CONFIG_SND_SOC) += snd-soc-core.o
obj-$(CONFIG_SND_SOC) += codecs/ at91/ pxa/ s3c24xx/ sh/ fsl/ davinci/ omap/
+obj-$(CONFIG_SND_SOC_OF) += soc-of.o
diff --git a/sound/soc/soc-of.c b/sound/soc/soc-of.c
new file mode 100644
index 000..9694979
--- /dev/null
+++ b/sound/soc/soc-of.c
@@ -0,0 +1,171 @@
+/*
+ * OF helpers for ALSA SoC Layer
+ *
+ * Copyright (C) 2008, Secret Lab Technologies Ltd.
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include linux/bitops.h
+#include linux/platform_device.h
+#include linux/of.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/soc-of.h
+#include sound/initval.h
+
+MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]);
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(ALSA SoC OpenFirmware bindings);
+
+DEFINE_MUTEX(of_snd_soc_mutex);
+LIST_HEAD(of_snd_soc_device_list);
+static int of_snd_soc_next_index;
+
+struct of_snd_soc_device {
+ int id;
+ struct list_head list;
+ struct snd_soc_device device;
+ struct snd_soc_machine machine;
+ struct snd_soc_dai_link dai_link;
+ struct platform_device *pdev;
+ struct device_node *platform_node;
+ struct device_node *codec_node;
+};
+
+static struct snd_soc_ops of_snd_soc_ops = {
+};
+
+static struct of_snd_soc_device *
+of_snd_soc_get_device(struct device_node *codec_node)
+{
+ struct of_snd_soc_device *of_soc;
+
+ list_for_each_entry(of_soc, of_snd_soc_device_list, list) {
+ if (of_soc-codec_node == codec_node)
+ return of_soc;
+ }
+
+ of_soc = kzalloc(sizeof(struct of_snd_soc_device), GFP_KERNEL);
+ if (!of_soc)
+ return NULL;
+
+ /* Initialize the structure and add it to the global list */
+ of_soc-codec_node = codec_node;
+ of_soc-id = of_snd_soc_next_index++;
+ of_soc-machine.dai_link = of_soc-dai_link;
+ of_soc-machine.num_links = 1;
+ of_soc-device.machine = of_soc-machine;
+ of_soc-dai_link.ops = of_snd_soc_ops;
+ list_add(of_soc-list, of_snd_soc_device_list);
+
+ return of_soc;
+}
+
+static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
+{
+ struct platform_device *pdev;
+ int rc;
+
+ /* Only register the device if both the codec and platform have
+* been registered */
+ if ((!of_soc-device.codec_data) || (!of_soc-platform_node))
+ return;
+
+ pr_info(platform--codec match achieved; registering machine\n);
+
+ pdev = platform_device_alloc(soc-audio, of_soc-id);
+ if (!pdev) {
+ pr_err(of_soc: platform_device_alloc() failed\n);
+ return;
+ }
+
+ pdev-dev.platform_data = of_soc;
+ platform_set_drvdata(pdev, of_soc-device);
+ of_soc-device.dev = pdev-dev;
+
+ /* The ASoC device is complete; register it */
+ rc = platform_device_add(pdev);
+ if (rc) {
+ pr_err(of_soc: platform_device_add() failed\n);
+ return;
+ }
+
+}
+
+int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
+ void *codec_data, struct snd_soc_codec_dai *dai,
+ struct device_node *node)
+{
+ struct of_snd_soc_device *of_soc;
+ int rc = 0;
+
+ pr_info(registering ASoC codec driver: %s\n, node-full_name);
+
+ mutex_lock(of_snd_soc_mutex);
+ of_soc = of_snd_soc_get_device(node);
+ if
[PATCH 2/3] ALSA SoC: Add mpc5200-psc I2S driver
From: Grant Likely [EMAIL PROTECTED]
This is an I2S bus driver for the MPC5200 PSC device. It is probably
will not be merged as-is because it uses v1 of the ASoC API, but I want
to get it out there for comments.
---
sound/soc/fsl/Kconfig |6
sound/soc/fsl/Makefile |2
sound/soc/fsl/mpc5200_psc_i2s.c | 899 +++
3 files changed, 907 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 257101f..5daa8d3 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -17,4 +17,10 @@ config SND_SOC_MPC8610_HPCD
help
Say Y if you want to enable audio on the Freescale MPC8610 HPCD.
+config SND_SOC_MPC5200_I2S
+ bool Freescale MPC5200 PSC in I2S mode driver
+ depends on SND_SOC PPC_MPC52xx
+ help
+ Say Y here to support the MPC5200 PSCs in I2S mode.
+
endmenu
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 62f680a..98729a1 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -4,3 +4,5 @@ obj-$(CONFIG_SND_SOC_MPC8610_HPCD) += mpc8610_hpcd.o
# MPC8610 Platform Support
obj-$(CONFIG_SND_SOC_MPC8610) += fsl_ssi.o fsl_dma.o
+obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
+
diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c
new file mode 100644
index 000..81d0933
--- /dev/null
+++ b/sound/soc/fsl/mpc5200_psc_i2s.c
@@ -0,0 +1,899 @@
+/*
+ * Freescale MPC5200 PSC in I2S mode
+ * ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ * Copyright (C) 2008 Secret Lab Technologies Ltd.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/of_device.h
+#include linux/of_platform.h
+#include linux/dma-mapping.h
+
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/initval.h
+#include sound/soc.h
+#include sound/soc-of.h
+
+#include sysdev/bestcomm/bestcomm.h
+#include sysdev/bestcomm/gen_bd.h
+#include asm/mpc52xx_psc.h
+
+MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Freescale MPC5200 PSC in I2S mode ASoC Driver);
+MODULE_LICENSE(GPL);
+
+/**
+ * PSC_I2S_RATES: sample rates supported by the I2S
+ *
+ * This driver currently only supports the PSC running in I2S slave mode,
+ * which means the codec determines the sample rate. Therefore, we tell
+ * ALSA that we support all rates and let the codec driver decide what rates
+ * are really supported.
+ */
+#define PSC_I2S_RATES (SNDRV_PCM_RATE_5512 | SNDRV_PCM_RATE_8000_192000 | \
+ SNDRV_PCM_RATE_CONTINUOUS)
+
+/**
+ * PSC_I2S_FORMATS: audio formats supported by the PSC I2S mode
+ */
+#define PSC_I2S_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | \
+SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE | \
+SNDRV_PCM_FMTBIT_S32_BE)
+
+/**
+ * psc_i2s_stream - Data specific to a single stream (playback or capture)
+ * @active:flag indicating if the stream is active
+ * @psc_i2s: pointer back to parent psc_i2s data structure
+ * @bcom_task: bestcomm task structure
+ * @irq: irq number for bestcomm task
+ * @period_start: physical address of start of DMA region
+ * @period_end:physical address of end of DMA region
+ * @period_next_pt:physical address of next DMA buffer to enqueue
+ * @period_bytes: size of DMA period in bytes
+ */
+struct psc_i2s_stream {
+ int active;
+ struct psc_i2s *psc_i2s;
+ struct bcom_task *bcom_task;
+ int irq;
+ struct snd_pcm_substream *stream;
+ dma_addr_t period_start;
+ dma_addr_t period_end;
+ dma_addr_t period_next_pt;
+ dma_addr_t period_current_pt;
+ int period_bytes;
+};
+
+/**
+ * psc_i2s - Private driver data
+ * @name: short name for this device (PSC0, PSC1, etc)
+ * @psc_regs: pointer to the PSC's registers
+ * @fifo_regs: pointer to the PSC's FIFO registers
+ * @irq: IRQ of this PSC
+ * @dev: struct device pointer
+ * @playback: the number of playback streams opened
+ * @capture: the number of capture streams opened
+ * @dai: the CPU DAI for this device
+ * @playback_stream: Playback stream context data
+ * @capture_stream: Capture stream context data
+ */
+struct psc_i2s {
+ char name[32];
+ struct mpc52xx_psc __iomem *psc_regs;
+ struct mpc52xx_psc_fifo __iomem *fifo_regs;
+ unsigned int irq;
+ struct device *dev;
+ struct snd_soc_cpu_dai dai;
+ spinlock_t lock;
+
+ /* per-stream data */
+ struct psc_i2s_stream playback_stream;
+ struct psc_i2s_stream capture_stream;
+
+ /* Statistics */
+ struct {
+ int overrun_count;
+ int underrun_count;
+ } stats;
+};
+
+/*
+ * Interrupt handlers
+ */
+static irqreturn_t psc_i2s_status_irq(int irq, void
[PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Grant Likely [EMAIL PROTECTED] ASoC Codec driver for the TLV320AIC26 device. This driver uses the ASoC v1 API, so I don't expect it to get merged as-is, but I want to get it out there for review. --- sound/soc/codecs/Kconfig |4 sound/soc/codecs/Makefile |2 sound/soc/codecs/tlv320aic26.c | 630 3 files changed, 636 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 3903ab7..96c7bfe 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -41,6 +41,10 @@ config SND_SOC_CS4270_VD33_ERRATA bool depends on SND_SOC_CS4270 +config SND_SOC_TLV320AIC26 + tristate TI TLB320AIC26 Codec support + depends on SND_SOC SPI + config SND_SOC_TLV320AIC3X tristate depends on SND_SOC I2C diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index 4e1314c..ec0cd93 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -5,6 +5,7 @@ snd-soc-wm8753-objs := wm8753.o snd-soc-wm9712-objs := wm9712.o snd-soc-wm9713-objs := wm9713.o snd-soc-cs4270-objs := cs4270.o +snd-soc-tlv320aic26-objs := tlv320aic26.o snd-soc-tlv320aic3x-objs := tlv320aic3x.o obj-$(CONFIG_SND_SOC_AC97_CODEC) += snd-soc-ac97.o @@ -14,4 +15,5 @@ obj-$(CONFIG_SND_SOC_WM8753) += snd-soc-wm8753.o obj-$(CONFIG_SND_SOC_WM9712) += snd-soc-wm9712.o obj-$(CONFIG_SND_SOC_WM9713) += snd-soc-wm9713.o obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o +obj-$(CONFIG_SND_SOC_TLV320AIC26) += snd-soc-tlv320aic26.o obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c new file mode 100644 index 000..aee1dbc --- /dev/null +++ b/sound/soc/codecs/tlv320aic26.c @@ -0,0 +1,630 @@ +/* + * Texas Instruments TLV320AIC26 low power audio CODEC + * ALSA SoC CODEC driver + * + * Copyright (C) 2008 Secret Lab Technologies Ltd. + */ + +#include linux/module.h +#include linux/moduleparam.h +#include linux/init.h +#include linux/delay.h +#include linux/pm.h +#include linux/device.h +#include linux/sysfs.h +#include linux/spi/spi.h +#include sound/core.h +#include sound/pcm.h +#include sound/pcm_params.h +#include sound/soc.h +#include sound/soc-dapm.h +#include sound/soc-of.h +#include sound/initval.h + +MODULE_DESCRIPTION(ASoC TLV320AIC26 codec driver); +MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]); +MODULE_LICENSE(GPL); + +/* AIC26 Registers */ +#define AIC26_READ_COMMAND_WORD(addr) ((1 15) | (addr 5)) +#define AIC26_WRITE_COMMAND_WORD(addr) ((0 15) | (addr 5)) +#define AIC26_PAGE_ADDR(page, offset) ((page 6) | offset) +#define AIC26_NUM_REGS AIC26_PAGE_ADDR(3, 0) +#define AIC26_REG_CACHE_SIZE (0x20) /* only page 2 cached */ +#define AIC26_REG_IS_CACHED(addr) ((addr ~0x1f) == (2 6)) +#define AIC26_REG_CACHE_ADDR(addr) (addr 0x1f) + +/* Page 0: Auxillary data registers */ +#define AIC26_REG_BAT1 AIC26_PAGE_ADDR(0, 0x05) +#define AIC26_REG_BAT2 AIC26_PAGE_ADDR(0, 0x06) +#define AIC26_REG_AUX AIC26_PAGE_ADDR(0, 0x07) +#define AIC26_REG_TEMP1AIC26_PAGE_ADDR(0, 0x09) +#define AIC26_REG_TEMP2AIC26_PAGE_ADDR(0, 0x0A) + +/* Page 1: Auxillary control registers */ +#define AIC26_REG_AUX_ADC AIC26_PAGE_ADDR(1, 0x00) +#define AIC26_REG_STATUS AIC26_PAGE_ADDR(1, 0x01) +#define AIC26_REG_REFERENCEAIC26_PAGE_ADDR(1, 0x03) +#define AIC26_REG_RESETAIC26_PAGE_ADDR(1, 0x04) + +/* Page 2: Audio control registers */ +#define AIC26_REG_AUDIO_CTRL1 AIC26_PAGE_ADDR(2, 0x00) +#define AIC26_REG_ADC_GAIN AIC26_PAGE_ADDR(2, 0x01) +#define AIC26_REG_DAC_GAIN AIC26_PAGE_ADDR(2, 0x02) +#define AIC26_REG_SIDETONE AIC26_PAGE_ADDR(2, 0x03) +#define AIC26_REG_AUDIO_CTRL2 AIC26_PAGE_ADDR(2, 0x04) +#define AIC26_REG_POWER_CTRL AIC26_PAGE_ADDR(2, 0x05) +#define AIC26_REG_AUDIO_CTRL3 AIC26_PAGE_ADDR(2, 0x06) + +#define AIC26_REG_FILTER_COEFF_L_N0AIC26_PAGE_ADDR(2, 0x07) +#define AIC26_REG_FILTER_COEFF_L_N1AIC26_PAGE_ADDR(2, 0x08) +#define AIC26_REG_FILTER_COEFF_L_N2AIC26_PAGE_ADDR(2, 0x09) +#define AIC26_REG_FILTER_COEFF_L_N3AIC26_PAGE_ADDR(2, 0x0A) +#define AIC26_REG_FILTER_COEFF_L_N4AIC26_PAGE_ADDR(2, 0x0B) +#define AIC26_REG_FILTER_COEFF_L_N5AIC26_PAGE_ADDR(2, 0x0C) +#define AIC26_REG_FILTER_COEFF_L_D1AIC26_PAGE_ADDR(2, 0x0D) +#define AIC26_REG_FILTER_COEFF_L_D2AIC26_PAGE_ADDR(2, 0x0E) +#define AIC26_REG_FILTER_COEFF_L_D4AIC26_PAGE_ADDR(2, 0x0F) +#define AIC26_REG_FILTER_COEFF_L_D5AIC26_PAGE_ADDR(2, 0x10) +#define AIC26_REG_FILTER_COEFF_R_N0AIC26_PAGE_ADDR(2, 0x11) +#define AIC26_REG_FILTER_COEFF_R_N1AIC26_PAGE_ADDR(2, 0x12) +#define AIC26_REG_FILTER_COEFF_R_N2
RE: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
On Tue, 2008-07-01 at 08:58 -0700, Stephen Neuendorffer wrote: Doing this at the binary level would be nice, but I see enough problems just doing it at the source level and at least for my purposes, doing it on a dtb would be overkill, I think. The main difficulty remains how to deal with cross references between nodes in a reasonable way where the references cross from one fragment to another. I would have those done in the toplevel .dts You can always override the property with the reference Ie. you #include your CPU or your SOC for example, and then override some property to point to something else using the override mechanism I mentioned. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Xilinx: add dts file for ML507 board
On Tue, 1 Jul 2008 16:02:54 -0700 John Linn [EMAIL PROTECTED] wrote: This new file adds support for the ML507 board which has a Virtex 5 FXT FPGA with a 440. I haven't looked this over thoroughly yet, but an immediate question comes to mind. Any way this can get converted to dts-v1 before it's pulled in? All of the in-tree DTS files should be dts-v1 now, so I'd like to have new ones go in as that. (Also CC'ing the proper list) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: cleanup copy_to/from_user for vsx and fpr
This merges and cleans up some of the ugly copy/to from user code
which is required for the new fpr and vsx layout in the thread_struct.
Also fixes some hard coded buffer sizes and removes a redundant
fpr_flush_to_thread.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
arch/powerpc/kernel/signal.h| 10 +++
arch/powerpc/kernel/signal_32.c | 40 ++
arch/powerpc/kernel/signal_64.c | 112
3 files changed, 96 insertions(+), 66 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal.h
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal.h
+++ linux-2.6-ozlabs/arch/powerpc/kernel/signal.h
@@ -24,6 +24,16 @@ extern int handle_rt_signal32(unsigned l
siginfo_t *info, sigset_t *oldset,
struct pt_regs *regs);
+extern unsigned long copy_fpr_to_user(void __user *to,
+ struct task_struct *task);
+extern unsigned long copy_fpr_from_user(struct task_struct *task,
+ void __user *from);
+#ifdef CONFIG_VSX
+extern unsigned long copy_vsx_to_user(void __user *to,
+ struct task_struct *task);
+extern unsigned long copy_vsx_from_user(struct task_struct *task,
+ void __user *from);
+#endif
#ifdef CONFIG_PPC64
Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal_32.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c
@@ -337,10 +337,6 @@ static int save_user_regs(struct pt_regs
int sigret)
{
unsigned long msr = regs-msr;
-#ifdef CONFIG_VSX
- double buf[32];
- int i;
-#endif
/* Make sure floating point registers are stored in regs */
flush_fp_to_thread(current);
@@ -370,14 +366,9 @@ static int save_user_regs(struct pt_regs
if (__put_user(current-thread.vrsave, (u32 __user
*)frame-mc_vregs[32]))
return 1;
#endif /* CONFIG_ALTIVEC */
-#ifdef CONFIG_VSX
- /* save FPR copy to local buffer then write to the thread_struct */
- flush_fp_to_thread(current);
- for (i = 0; i 32 ; i++)
- buf[i] = current-thread.TS_FPR(i);
- memcpy(buf[i], current-thread.fpscr, sizeof(double));
- if (__copy_to_user(frame-mc_fregs, buf, ELF_NFPREG * sizeof(double)))
+ if (copy_fpr_to_user(frame-mc_fregs, current))
return 1;
+#ifdef CONFIG_VSX
/*
* Copy VSR 0-31 upper half from thread_struct to local
* buffer, then write that to userspace. Also set MSR_VSX in
@@ -386,18 +377,10 @@ static int save_user_regs(struct pt_regs
*/
if (current-thread.used_vsr) {
flush_vsx_to_thread(current);
- for (i = 0; i 32 ; i++)
- buf[i] = current-thread.fpr[i][TS_VSRLOWOFFSET];
- if (__copy_to_user(frame-mc_vsregs, buf,
- ELF_NVSRHALFREG * sizeof(double)))
+ if (copy_vsx_to_user(frame-mc_vsregs, current))
return 1;
msr |= MSR_VSX;
}
-#else
- /* save floating-point registers */
- if (__copy_to_user(frame-mc_fregs, current-thread.fpr,
- ELF_NFPREG * sizeof(double)))
- return 1;
#endif /* CONFIG_VSX */
#ifdef CONFIG_SPE
/* save spe registers */
@@ -442,7 +425,6 @@ static long restore_user_regs(struct pt_
unsigned int save_r2 = 0;
unsigned long msr;
#ifdef CONFIG_VSX
- double buf[32];
int i;
#endif
@@ -490,13 +472,10 @@ static long restore_user_regs(struct pt_
if (__get_user(current-thread.vrsave, (u32 __user *)sr-mc_vregs[32]))
return 1;
#endif /* CONFIG_ALTIVEC */
+ if (copy_fpr_from_user(current, sr-mc_fregs))
+ return 1;
#ifdef CONFIG_VSX
- if (__copy_from_user(buf, sr-mc_fregs,sizeof(sr-mc_fregs)))
- return 1;
- for (i = 0; i 32 ; i++)
- current-thread.TS_FPR(i) = buf[i];
- memcpy(current-thread.fpscr, buf[i], sizeof(double));
/*
* Force the process to reload the VSX registers from
* current-thread when it next does VSX instruction.
@@ -507,18 +486,11 @@ static long restore_user_regs(struct pt_
* Restore altivec registers from the stack to a local
* buffer, then write this out to the thread_struct
*/
- if (__copy_from_user(buf, sr-mc_vsregs,
-sizeof(sr-mc_vsregs)))
+ if (copy_vsx_from_user(current, sr-mc_vsregs))
return 1;
- for (i = 0; i 32 ; i++)
-
[PATCH] powerpc: cleanup copy_to/from_user for vsx and fpr
This merges and cleans up some of the ugly copy/to from user code
which is required for the new fpr and vsx layout in the thread_struct.
Also fixes some hard coded buffer sizes and removes a redundant
fpr_flush_to_thread.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Sorry, the last version broke 32bit kernel builds
signal.h| 10 +
signal_32.c | 109 +---
signal_64.c | 43 ++-
3 files changed, 96 insertions(+), 66 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal.h
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal.h
+++ linux-2.6-ozlabs/arch/powerpc/kernel/signal.h
@@ -24,6 +24,16 @@ extern int handle_rt_signal32(unsigned l
siginfo_t *info, sigset_t *oldset,
struct pt_regs *regs);
+extern unsigned long copy_fpr_to_user(void __user *to,
+ struct task_struct *task);
+extern unsigned long copy_fpr_from_user(struct task_struct *task,
+ void __user *from);
+#ifdef CONFIG_VSX
+extern unsigned long copy_vsx_to_user(void __user *to,
+ struct task_struct *task);
+extern unsigned long copy_vsx_from_user(struct task_struct *task,
+ void __user *from);
+#endif
#ifdef CONFIG_PPC64
Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal_32.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c
@@ -328,6 +328,75 @@ struct rt_sigframe {
int abigap[56];
};
+#ifdef CONFIG_VSX
+unsigned long copy_fpr_to_user(void __user *to,
+ struct task_struct *task)
+{
+ double buf[ELF_NFPREG];
+ int i;
+
+ /* save FPR copy to local buffer then write to the thread_struct */
+ for (i = 0; i (ELF_NFPREG - 1) ; i++)
+ buf[i] = task-thread.TS_FPR(i);
+ memcpy(buf[i], task-thread.fpscr, sizeof(double));
+ return __copy_to_user(to, buf, ELF_NFPREG * sizeof(double));
+}
+
+unsigned long copy_fpr_from_user(struct task_struct *task,
+void __user *from)
+{
+ double buf[ELF_NFPREG];
+ int i;
+
+ if (__copy_from_user(buf, from, ELF_NFPREG * sizeof(double)))
+ return 1;
+ for (i = 0; i (ELF_NFPREG - 1) ; i++)
+ task-thread.TS_FPR(i) = buf[i];
+ memcpy(task-thread.fpscr, buf[i], sizeof(double));
+
+ return 0;
+}
+
+unsigned long copy_vsx_to_user(void __user *to,
+ struct task_struct *task)
+{
+ double buf[ELF_NVSRHALFREG];
+ int i;
+
+ /* save FPR copy to local buffer then write to the thread_struct */
+ for (i = 0; i ELF_NVSRHALFREG; i++)
+ buf[i] = task-thread.fpr[i][TS_VSRLOWOFFSET];
+ return __copy_to_user(to, buf, ELF_NVSRHALFREG * sizeof(double));
+}
+
+unsigned long copy_vsx_from_user(struct task_struct *task,
+void __user *from)
+{
+ double buf[ELF_NVSRHALFREG];
+ int i;
+
+ if (__copy_from_user(buf, from, ELF_NVSRHALFREG * sizeof(double)))
+ return 1;
+ for (i = 0; i ELF_NVSRHALFREG ; i++)
+ task-thread.fpr[i][TS_VSRLOWOFFSET] = buf[i];
+ return 0;
+}
+#else
+inline unsigned long copy_fpr_to_user(void __user *to,
+ struct task_struct *task)
+{
+ return __copy_to_user(to, task-thread.fpr,
+ ELF_NFPREG * sizeof(double));
+}
+
+inline unsigned long copy_fpr_from_user(struct task_struct *task,
+ void __user *from)
+{
+ return __copy_from_user(task-thread.fpr, from,
+ ELF_NFPREG * sizeof(double));
+}
+#endif
+
/*
* Save the current user registers on the user stack.
* We only save the altivec/spe registers if the process has used
@@ -337,10 +406,6 @@ static int save_user_regs(struct pt_regs
int sigret)
{
unsigned long msr = regs-msr;
-#ifdef CONFIG_VSX
- double buf[32];
- int i;
-#endif
/* Make sure floating point registers are stored in regs */
flush_fp_to_thread(current);
@@ -370,14 +435,9 @@ static int save_user_regs(struct pt_regs
if (__put_user(current-thread.vrsave, (u32 __user
*)frame-mc_vregs[32]))
return 1;
#endif /* CONFIG_ALTIVEC */
-#ifdef CONFIG_VSX
- /* save FPR copy to local buffer then write to the thread_struct */
- flush_fp_to_thread(current);
- for (i = 0; i 32 ; i++)
- buf[i] = current-thread.TS_FPR(i);
- memcpy(buf[i], current-thread.fpscr, sizeof(double));
- if
Re: [PATCH] ibm_newemac: Fixes memory leak in ibm_newemac ethernet driver
Hi Benn,
Please find my comments below.
On Tue, Jun 24, 2008 at 4:51 AM, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Mon, 2008-06-23 at 14:55 +0200, Stefan Roese wrote:
From: Sathya Narayanan [EMAIL PROTECTED]
This patch addresses the memory leak happenning in drivers transmit queue
under heavy load condition. Once the transmit queue becomes full, driver
does an automatic wrapup of queue. During which the untransmitted SKB's
are
lost without getting freed up.
This would be a bug. We should stop the queue when full instead.
Actually the meachanism of stopping the queue and starting it is already
there. But even then due to some sync issue between the poll routine and
xmit, we were resulted in using the slots of skb which was not actually got
freed before.
I agree this could a bug , Since its not is not clear why buffers are not
getting transferred timely?. But to handle this we should have a work around
otherwise system may go out of memory. If we go for stopping the queue in
these scenario also ( Where a unfreed skbs slot has been assigned to
another ), Then kernel may call tx timeout, And reset the driver. In that
case handelling this special case here could lead us better performance as
compared to stopping the queue
Let me know your comments.
Signed-off-by: Sathya Narayanan [EMAIL PROTECTED]
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c
b/drivers/net/ibm_newemac/core.c
index aa407b2..ee868b6 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -1328,6 +1328,13 @@ static int emac_start_xmit(struct sk_buff *skb,
struct net_device *ndev)
DBG2(dev, xmit(%u) %d NL, len, slot);
+ if (dev-tx_skb[slot] dev-tx_desc[slot].data_ptr) {
+ dev_kfree_skb(dev-tx_skb[slot]);
+ dev-tx_skb[slot] = NULL;
+ dev-tx_cnt--;
+ ++dev-estats.tx_dropped;
+ }
+
dev-tx_skb[slot] = skb;
dev-tx_desc[slot].data_ptr = dma_map_single(dev-ofdev-dev,
skb-data, len,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Fixes memory leak in ibm_newemac ethernet driver
Actually the meachanism of stopping the queue and starting it is already there. But even then due to some sync issue between the poll routine and xmit, we were resulted in using the slots of skb which was not actually got freed before. I agree this could a bug , Since its not is not clear why buffers are not getting transferred timely?. But to handle this we should have a work around otherwise system may go out of memory. If we go for stopping the queue in these scenario also ( Where a unfreed skbs slot has been assigned to another ), Then kernel may call tx timeout, And reset the driver. In that case handelling this special case here could lead us better performance as compared to stopping the queue Let me know your comments. Well, if we have a bug, we need to fix it. ie, understand how it is that the existing mechanism to stop the queue doesn't work, and prevent xmit from overwriting a non-clear transmit slot (possibly displaying an error to help us track down the bug). I'll have to dig a bit, I'll see if I can find some time tomorrow. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
