Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
On 09/11/07 00:31 -0500, Jon Smirl wrote:
This is the reason I couldn't get user space started or connect to my
nfs server. Patch is against current linus git.
mpc5200 fec driver is corrupting memory. This patch fixes two bugs
where the wrong skb buffer was being referenced.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
Acked-by: Domen Puncer [EMAIL PROTECTED]
I can't test it at the moment, but the patch is obviously correct,
mapped buffer should be the _same_ as submitted.
---
drivers/net/fec_mpc52xx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index a8a0ee2..ddfcc0b 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
rskb = bcom_retrieve_buffer(priv-rx_dmatsk, status,
(struct bcom_bd **)bd);
- dma_unmap_single(dev-dev, bd-skb_pa, skb-len,
DMA_FROM_DEVICE);
+ dma_unmap_single(dev-dev, bd-skb_pa, rskb-len,
DMA_FROM_DEVICE);
/* Test for errors in received frame */
if (status BCOM_FEC_RX_BD_ERRORS) {
@@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
bcom_prepare_next_buffer(priv-rx_dmatsk);
bd-status = FEC_RX_BUFFER_SIZE;
- bd-skb_pa = dma_map_single(dev-dev, rskb-data,
+ bd-skb_pa = dma_map_single(dev-dev, skb-data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv-rx_dmatsk, skb);
--
Jon Smirl
[EMAIL PROTECTED]
--
Domen Puncer | Research Development
.
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.
www.telargo.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Fix oops related to 4xx flush_tlb_page modification
kmap_atomic calls flush_tlb_page with a NULL VMA and thus we end
up dereferencing a NULL pointer to try and get the context.id.
If the VMA is null use the global pid value of 0.
---
include/asm-powerpc/tlbflush.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/tlbflush.h b/include/asm-powerpc/tlbflush.h
index e7b4c0d..5c91081 100644
--- a/include/asm-powerpc/tlbflush.h
+++ b/include/asm-powerpc/tlbflush.h
@@ -44,13 +44,13 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma-vm_mm-context.id);
+ _tlbie(vmaddr, vma ? vma-vm_mm-context.id : 0);
}
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma-vm_mm-context.id);
+ _tlbie(vmaddr, vma ? vma-vm_mm-context.id : 0);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
--
1.5.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.24' branch
Please pull from 'for-2.6.24' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24 to receive the following updates: arch/powerpc/Makefile|3 +++ arch/powerpc/sysdev/cpm_common.c |4 +--- include/asm-powerpc/tlbflush.h |4 ++-- 3 files changed, 6 insertions(+), 5 deletions(-) Kumar Gala (2): [POWERPC] Add -mno-spe for ARCH=powerpc builds [POWERPC] Fix oops related to 4xx flush_tlb_page modification Scott Wood (1): [POWERPC] cpm: Fix a couple minor issues in cpm_common.c. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
Am Donnerstag, den 08.11.2007, 14:20 -0600 schrieb Scott Wood:
Sergej Stepanov wrote:
If both mdio and mdc controlling pins are on the same processor port,
one resource should be used.
Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc.
How about:
The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC.
Ok.
We also need to change the reference to port C in fsl,mdio-pin and
fsl,mdc-pin.
Do you mean this:
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
- fsl,cpm2-mdio-bitbang (reg is port C registers)
Properties for fsl,cpm2-mdio-bitbang:
- fsl,mdio-pin : pin of port C controlling mdio data
- fsl,mdc-pin : pin of port C controlling mdio clock
Right. But i thought it would be related to the example,
and than the reader gets the short comment about I/O ports.
Or the other variant would be:
iv) MDIO
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
fsl,cpm2-mdio-bitbang (reg is the I/O port register block(s))
Properties for fsl,cpm2-mdio-bitbang:
The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC.
fsl,mdio-pin : pin of chosen port for controlling mdio data
fsl,mdc-pin : pin of chosen port for controlling mdio clock
Example:
[EMAIL PROTECTED] {
device_type = mdio;
compatible = fsl,mpc8272ads-mdio-bitbang,
fsl,mpc8272-mdio-bitbang,
fsl,cpm2-mdio-bitbang;
reg = 10d40 14;
#address-cells = 1;
#size-cells = 0;
fsl,mdio-pin = 12;
fsl,mdc-pin = 13;
};
-
Regards
Sergej.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
help linux for linux2.6
Hi These days I am working on a MPC8270 based board with linux 2.6.10 kernel. When I use the default kernel and load the uImage to the target board. The kernel hangs after uncompressing kernel image ... ok . I am freshman in the embedded linux area,So I do not know how to go on this project. From internet , I searched many articles,and no gain. Please help me . Thanks a lot. -- vincent.liu 2007-11-09 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] balance ioremap/iounmap in {sycamore, walnut}_setup_arch()
Valentine Barshak wrote: Roel Kluin wrote: I guess it should be done after the last usage of kb_data or fpga_status? I think no iounmap(kb_data) needed. Looks like the pointer kn_cs (kb_cs = kb_data + 1) is used by the serio driver (drivers/input/serio/i8042-ppcio.h). Please note that we just ioremap and assign pointers here, not actually reading the registers. Also, looks like you unmap the fpga registers too early. Thanks, Valentine. Thanks for your pointers. I'm new, so I'm not sure how this should be done. I have removed the iounmap(kb_data), and moved the iounmap(fpga_status) lower. possibly the latter could be done before the sycamore_rtc_base assignment? -- Balance ioremap/iounmap Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/arch/ppc/platforms/4xx/sycamore.c b/arch/ppc/platforms/4xx/sycamore.c index 8689f3e..6ce4815 100644 --- a/arch/ppc/platforms/4xx/sycamore.c +++ b/arch/ppc/platforms/4xx/sycamore.c @@ -132,6 +132,7 @@ sycamore_setup_arch(void) sycamore_rtc_base = (void *) SYCAMORE_RTC_VADDR; TODC_INIT(TODC_TYPE_DS1743, sycamore_rtc_base, sycamore_rtc_base, sycamore_rtc_base, 8); + iounmap(fpga_status); /* Identify the system */ printk(KERN_INFO IBM Sycamore (IBM405GPr) Platform\n); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Appletouch going wild
Every once in a while the touchpad in my iBook G4 (geyser1, 030B) is going wild, emitting random movement events even when not being touched. That started only with 2.6.24-rc1. The only way to stop it is to reload the appletouch module. My guess would be that reinitializing the touchpad can result in some kind of race condition. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote: [...] right, but whether it does or not doesn't affect your failure outcome either I'm assuming. If it's something like 0x03, the u-boot patch will probably look like: if ((bcsr[12] == 0x10) (immr-sysconf.spridr == SPR_8360_REV21 || immr-sysconf.spridr == SPR_8360E_REV21)) /* if phy-connection-type is rgmii-id, set it to rgmii-rxid */ ... but these linux patches would remain the same (the clk and data delay settings for the UCC's are still valid; it's just the PHY config that is triggering your problem from what I can tell). Yup, most likely this is not UCC specific, but PHY. For some reason delays making harm here... And today I was unable to reproduce yesterday's behaviour. Your patches works fine, with sixth patch and without it. With -rxid and with just -id. Though, after few resets I hit on that: - - - - U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX Reset Status: External/Internal Soft, External/Internal Hard CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz Board: Freescale MPC8360EMDS I2C: ready DRAM: 256 MB (DDR2, 64-bit, ECC on) SDRAM: 64 MB (local bus) FLASH: 32 MB In:serial Out: serial Err: serial Net: UEC: PHY is Marvell 88E11x1 (1410cc2) FSL UEC0: Full Duplex switching to rgmii 100 FSL UEC0: Speed 100BT FSL UEC0: Link is up read wrong value : mii_id 1,mii_reg 2, base e0103120 read wrong value : mii_id 1,mii_reg 3, base e0103120 UEC: PHY is Generic MII () read wrong value : mii_id 1,mii_reg 1, base e0103120 read wrong value : mii_id 1,mii_reg 1, base e0103120 read wrong value : mii_id 1,mii_reg 5, base e0103120 FSL UEC1: Full Duplex switching to rgmii 100 FSL UEC1: Speed 100BT FSL UEC1: Link is up FSL UEC0, FSL UEC1 - - - - And UCC1 does not work at all. After another reset that message disappears and it does work again. So, I think hardware is tricking me in various ways, not your patches fault. :-( -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ehea: Add kdump support
To support ehea driver reloading in a kdump kernel the driver has to perform
firmware handle deregistrations when the original kernel crashes. As there's
currently no notifier chain for machine crashes this patch enables kdump support
in the ehea driver by bending the ppc_md.machine_crash_shutdown hook to its own
machine crash handler. The original machine_crash_shutdown() fn is called
afterwards. This works fine as long as the ehea driver is the only one which
does so. Problems may occur if other drivers do the same and unload regularly.
This patch enables 2.6.24-rc2 to use kdump with ehea and only puts a very
low risk on base kernel. In 2.6.24 we know ehea is the only user of this
mechanism. The next step for 2.6.25 would be to add a proper notifier chain.
The full solution might be that register_reboot_notifier() provides sth
like a SYS_CRASH action. Please apply.
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c | 28
2 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index f78e5bf..5935899 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0080
+#define DRV_VERSIONEHEA_0081
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f0319f1..40a732e 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -37,6 +37,7 @@
#include linux/reboot.h
#include net/ip.h
+#include asm-powerpc/machdep.h
#include ehea.h
#include ehea_qmr.h
@@ -98,6 +99,7 @@ static int port_name_cnt = 0;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags = 0;
struct work_struct ehea_rereg_mr_task;
+static void (*orig_machine_crash_shutdown)(struct pt_regs *regs);
struct semaphore dlpar_mem_lock;
@@ -3312,6 +3314,29 @@ static struct notifier_block ehea_reboot_nb = {
.notifier_call = ehea_reboot_notifier,
};
+void ehea_crash_notifier(struct pt_regs *regs)
+{
+ ehea_info(Machine crash: freeing all eHEA resources);
+ ibmebus_unregister_driver(ehea_driver);
+ orig_machine_crash_shutdown(regs);
+}
+
+void ehea_register_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ orig_machine_crash_shutdown =
+ (void*)__xchg_u64((unsigned
long*)ppc_md.machine_crash_shutdown,
+(unsigned long)ehea_crash_notifier);
+#endif
+}
+
+void ehea_unregister_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ ppc_md.machine_crash_shutdown = orig_machine_crash_shutdown;
+#endif
+}
+
static int check_module_parm(void)
{
int ret = 0;
@@ -3369,6 +3394,7 @@ int __init ehea_module_init(void)
goto out;
register_reboot_notifier(ehea_reboot_nb);
+ ehea_register_crash_notifier();
ret = ibmebus_register_driver(ehea_driver);
if (ret) {
@@ -3382,6 +3408,7 @@ int __init ehea_module_init(void)
ehea_error(failed to register capabilities attribute, ret=%d,
ret);
unregister_reboot_notifier(ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ibmebus_unregister_driver(ehea_driver);
goto out;
}
@@ -3396,6 +3423,7 @@ static void __exit ehea_module_exit(void)
driver_remove_file(ehea_driver.driver, driver_attr_capabilities);
ibmebus_unregister_driver(ehea_driver);
unregister_reboot_notifier(ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ehea_destroy_busmap();
}
--
1.5.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote: Hello all, the following patches fix RGMII timing for rev. 2.1 of the mpc8360, according to erratum #2 (erratum text included below). Basically the most intrusive part is the addition of two new RGMII Internal Delay modes; one for TX delay only, and the other for RX delay only (i.e, not both at the same time). Please review, and since this affects both netdev and powerpc trees, one maintainer should ack them for the other to push upstream (i.e, Kumar acks them, and Leo picks them up to go through netdev or the other way around; either way is fine with me). I'm hoping they're trivial enough to go in 2.6.24. All five patches are Tested-by: Anton Vorontsov [EMAIL PROTECTED] Let's hope they'll hit 2.6.24. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
On 11/9/07, Domen Puncer [EMAIL PROTECTED] wrote:
On 09/11/07 00:31 -0500, Jon Smirl wrote:
This is the reason I couldn't get user space started or connect to my
nfs server. Patch is against current linus git.
mpc5200 fec driver is corrupting memory. This patch fixes two bugs
where the wrong skb buffer was being referenced.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
Acked-by: Domen Puncer [EMAIL PROTECTED]
Signed-off-by: Grant Likely [EMAIL PROTECTED]
Jeff, can you please pick this up for .24?
Thanks,
g.
I can't test it at the moment, but the patch is obviously correct,
mapped buffer should be the _same_ as submitted.
---
drivers/net/fec_mpc52xx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index a8a0ee2..ddfcc0b 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
rskb = bcom_retrieve_buffer(priv-rx_dmatsk, status,
(struct bcom_bd **)bd);
- dma_unmap_single(dev-dev, bd-skb_pa, skb-len,
DMA_FROM_DEVICE);
+ dma_unmap_single(dev-dev, bd-skb_pa, rskb-len,
DMA_FROM_DEVICE);
/* Test for errors in received frame */
if (status BCOM_FEC_RX_BD_ERRORS) {
@@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
bcom_prepare_next_buffer(priv-rx_dmatsk);
bd-status = FEC_RX_BUFFER_SIZE;
- bd-skb_pa = dma_map_single(dev-dev, rskb-data,
+ bd-skb_pa = dma_map_single(dev-dev, skb-data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv-rx_dmatsk, skb);
--
Jon Smirl
[EMAIL PROTECTED]
--
Domen Puncer | Research Development
.
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.
www.telargo.com
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
Hi Stephen, Stephen Rothwell wrote: On Tue, 06 Nov 2007 21:05:20 +0100 Marian Balakowicz [EMAIL PROTECTED] wrote: +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c + +#include linux/pci.h +#include linux/of.h +#include asm/time.h +#include asm/io.h Its not clear to me that you need any of the above four includes. #include asm/time.h is needed for generic_calibrate_decr() but other few includes are in fact not necessary. Thanks. Cheers, m. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 07/13] [POWERPC] TQM5200 DTS
David Gibson wrote:
On Tue, Nov 06, 2007 at 09:05:48PM +0100, Marian Balakowicz wrote:
Add device tree source file for TQM5200 board.
[snip]
+[EMAIL PROTECTED] {
+device_type = usb-ohci-be;
This device_type is bogus. Remember having a valid device_type is the
exception not the rule. Really the only common device_type values are
cpu, memory, network and serial.
Ok, rechecked this one, doesn't seem necessary, removed.
+[EMAIL PROTECTED] { // PSC1
+device_type = serial;
+compatible = mpc5200-psc-uart;
+port-number = 0; // Logical port assignment
I know you said this is still needed, but the driver really needs to
be fixed. This is not a proper way of using the device tree for
logical numbering.
True, driver needs fixing, but there are also other boards that use
that driver, and I am not able to test them right now. And, as I
recall Grant mentioned that he's working on straightening this up.
Cheers,
m.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 12/13] [POWERPC] Promess Motion-PRO DTS
David Gibson wrote:
On Tue, Nov 06, 2007 at 09:06:34PM +0100, Marian Balakowicz wrote:
Add device tree source file for Motion-PRO board.
[snip]
+[EMAIL PROTECTED] { // Motion-PRO status LED
+compatible = promess,motionpro-statusled;
+reg = 660 10;
+interrupts = 1 f 0;
+interrupt-parent = mpc5200_pic;
+blink-delay = 64; // 100 msec
+};
+
+[EMAIL PROTECTED] { // Motion-PRO ready LED
+compatible = promess,motionpro-readyled;
+reg = 670 10;
+interrupts = 1 10 0;
+interrupt-parent = mpc5200_pic;
+};
Is there actually any difference in behaviour betweeen the two LEDs?
If not, they should probably have the same compatible value, and
perhaps a label property or some such to associate them with a
particular LED.
In fact they are identical, so I have used the same compatible
property and added label property do distinguish them.
[snip]
+[EMAIL PROTECTED] {
+device_type = spi;
No device_type!
Removed.
+compatible = mpc5200b-spi,mpc5200-spi;
+reg = f00 20;
+interrupts = 2 d 0 2 e 0;
+interrupt-parent = mpc5200_pic;
+};
+
+[EMAIL PROTECTED] {
+device_type = usb-ohci-be;
Nor here.
Removed.
[snip]
+// PSC2 in spi master mode
+[EMAIL PROTECTED] { // PSC2
+compatible = mpc5200b-psc-spi,mpc5200-psc-spi;
+cell-index = 1;
From your description, this is an incorrect usage of cell-index - it
should *only* be used to index into SoC shared registers; never for
logical numbering.
Again true, but the situation is similar to the one with the serial
node.
Cheers,
m.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] DTC: Polish up the DTS Version 1 implementation.
So, like, the other day David Gibson mumbled: But you do take a hit w.r.t. *minimum* representation size - there's no form amongst all the possibilities here more compact than pure hex. Especially since spaces are optional in the old form. The fact that [ab cd 00] and [abcd00] are equivalent was a deliberate choice in the original form. The point of [] is for random binary data which is neither strings (even with the odd strange character) nor sensibly organized into 32-bit (or larger) integers. Wanting something other than hex here is much rarer than in the case. You're seeing and [ ] as basically the same thing - a list of values - with the only difference being the size of those values. That's not wrong, but it's not the only way to look at it - and it's not the way I was thinking of [ ] when I invented it. Your proposal makes perfect sense while you think of [] as a list of values - but not so much when it's thought of as a direct binary representation. So I'm thinking perhaps we need two different things here: a list of values representation, which can accomodate expressions and can also have multiple sizes (because expressions which are evaluated to a 16-bit or 64-bit value could also be useful under the right circumstances), and the [ ] bytestring literal representation. Perhaps something like: (32-bit values) 0xdeadbeef (1+1) or.32 0xdeadbeef (1+1) (64-bit values) .64 (0xdeadbeef 32) (-1) (8-bit values) .8 0x00 0x0a 0xe4 0x2c 0x23 (0x10 + n) i.e. is list of values form, with size of each value as a sort of parameter (defaulting to 32-bit, of course). I'm not sure I like that particular syntax, it's just the first thing I came up with to demonstrate the idea. Ah ha! I see. You want this, then: x = .srec C001C0DEGE75BABE F1 OK. That was entirely joking. We all know that the cool code does NOT get the babe. Seriously though, I see your point, and I don't really have a strong opinion here, so in the interest of making some headway, we can just leave it as is for now. If it turns out to be a bad decision later, we'll fix it. :-) And with that issue behind us I'm going to post these patches to introduce the new DTS format! Any last straggler comments? Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
Hi Grant, Grant Likely wrote: On 11/6/07, Wolfgang Denk [EMAIL PROTECTED] wrote: in message [EMAIL PROTECTED] you wrote: In other words; make the assumption that it is easier to change the kernel than it is to change the device tree. Are you serious about this? Reading this from someone with your experience with device trees if feeding my worst fears... I think I better clarify. Once a device tree is written and shipped on a deployed board, it may never change again. Or, the kernel version may be updated more frequently than the device tree. Say, for example, that in kernel 2.6.25 tqm5200 and cm5200 are both handled by the same platform code. And lets say that in 2.6.26 we decide that they really need to have separate platform code (perhaps due to a firmware bug that needs to be worked around on one board). In this case, mpc5200-simple-platform has suddenly become useless. Or, does mpc5200-simple-platform now describe the cm5200 or the tqm5200? (an assumption which cannot be made due to deployed boards of both types claiming mpc5200-simple-platform). Trying to claim compatible at the board level is far more difficult than claiming it at the device level. Segher suggested on IRC: for boards it is pretty much useless most of the time, i think -- use model instead I can imagine that we may get into various trouble (or at least the situation is less flexible) if we are unable to update .dts file along with the kernel image on a deployed board. If so, then in fact there is little sens in using mpc5200-simple-platform compatible. But how serious is that, does such situation frequently happen in field? If we are able to update kernel image than what prevents .dts file update? Cheers, m. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
On 11/9/07, Marian Balakowicz [EMAIL PROTECTED] wrote: I can imagine that we may get into various trouble (or at least the situation is less flexible) if we are unable to update .dts file along with the kernel image on a deployed board. If so, then in fact there is little sens in using mpc5200-simple-platform compatible. But how serious is that, does such situation frequently happen in field? If we are able to update kernel image than what prevents .dts file update? Not everything in the device tree is in the .dts file. U-boot or other firmware can modify the device tree before passing it to the kernel. It may not always be possible to update the device tree without also updating the firmware. I already know of changes that I'd like to make to the lite5200 tree which I know will break u-boot. That isn't the situation in this particular case, but we must always keep it in mind. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
Jerry Van Baren wrote: My concern from the u-boot side is that u-boot has to know exactly *where* to put the expanded blob because it has to pass it to linux and keep it out of linux' way so it doesn't get stepped on. Linux has an advantage in that it owns all of memory and can allocate and deallocate whatever and wherever and it won't step on itself (hopefully). Linux is pretty careful not to step on the device tree; it marks the area as reserved, and moves it if it really has to. The only scenario I think would be problematic is if the kernel is started somewhere other than zero, and has to relocate itself, and the relocation clobbers the device tree. That's easily avoided by making sure the device tree is at a higher address than the kernel -- and is really not much different than the old bd_t mechanism, which didn't use a user provided address AFAIK. I'm assuming your boot wedge has the advantage of being able to use linux's malloc() and thus don't have to worry about coordinating with linux on memory allocation. No, it uses its own malloc. With the current u-boot fdt command, you can resize the blob, and this can be done in a script with all the (somewhat limited) capabilities of the u-boot shell (an adaptation of hush). OK, I'm just going by the behavior of the default boot commands on (at least some of) our boards, which just give you an error if the blob isn't already enlarged. Maybe I should just poke Kim et al. about fixing our default environment -- though I'm guessing it'd still have to know from the script how much to enlarge the blob. In the u-boot world, we fixate on memory maps and putting things in specific places. I've noticed. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
Sergej Stepanov wrote: We also need to change the reference to port C in fsl,mdio-pin and fsl,mdc-pin. Do you mean this: Currently defined compatibles: fsl,pq1-fec-mdio (reg is same as first resource of FEC device) - fsl,cpm2-mdio-bitbang (reg is port C registers) Properties for fsl,cpm2-mdio-bitbang: - fsl,mdio-pin : pin of port C controlling mdio data - fsl,mdc-pin : pin of port C controlling mdio clock Yes. Right. But i thought it would be related to the example, and than the reader gets the short comment about I/O ports. No, the example is the example, and the spec is the spec. :-) Or the other variant would be: iv) MDIO Currently defined compatibles: fsl,pq1-fec-mdio (reg is same as first resource of FEC device) fsl,cpm2-mdio-bitbang (reg is the I/O port register block(s)) Properties for fsl,cpm2-mdio-bitbang: The first reg resource is the I/O port register block on which MDIO resides. The second reg resource is the I/O port register block on which MDC resides. If there is only one reg resource, it is used for both MDIO and MDC. fsl,mdio-pin : pin of chosen port for controlling mdio data fsl,mdc-pin : pin of chosen port for controlling mdio clock Looks good. We can eliminate the parenthetical for fsl,cpm2-mdio-bitbang because reg is now explained below. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 00/13] [POWERPC] Add TQM5200/CM5200/Motion-PRO board support
This is a yet another version of the patches that add arch/powerpc support for three MPC5200 based boards: TQ-Components TQM5200, Schindler CM5200 and Promess Motion-PRO. Updates include modifications to mpc5200_simple_probe() routine in the generic support for simple MPC5200 based boards, changes to leds-motionpro driver - using common compatility property for both LEDs, and few other .dts cleanups. [POWERPC] Promess Motion-PRO defconfig [POWERPC] Promess Motion-PRO DTS [POWERPC] Motion-PRO: Add LED support. [POWERPC] CM5200 defconfig [POWERPC] CM5200 DTS [POWERPC] TQM5200 defconfig [POWERPC] TQM5200 DTS [POWERPC] Use EXPORT_SYMBOL_GPL for 52xx common routines symbol export [POWERPC] Export mpc52xx_map_node() routine symbol [POWERPC] Add generic support for simple MPC5200 based boards [POWERPC] Add common mpc52xx_setup_pci() routine [POWERPC] Add 'fsl,lpb' bus type for MPC5200 LocalPlus Bus [POWERPC] Add 'model: ...' line to common show_cpuinfo() Please review, and if everything is ok schedule for 2.6.24-rc3. Cheers, m. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 02/13] [POWERPC] Add 'fsl, lpb' bus type for MPC5200 LocalPlus Bus
Define MPC52xx specific device id list, add new
'fsl,lpb' compatible id for LocalPlus Bus.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
Acked-by: David Gibson [EMAIL PROTECTED]
---
arch/powerpc/platforms/52xx/mpc52xx_common.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c
b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 9850685..2df97c5 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -124,11 +124,18 @@ mpc5200_setup_xlb_arbiter(void)
iounmap(xlb);
}
+static struct of_device_id mpc52xx_ids[] = {
+ { .type = soc, },
+ { .compatible = soc, },
+ { .compatible = fsl,lpb, },
+ {},
+};
+
void __init
mpc52xx_declare_of_platform_devices(void)
{
/* Find every child of the SOC node and add it to of_platform */
- if (of_platform_bus_probe(NULL, NULL, NULL))
+ if (of_platform_bus_probe(NULL, mpc52xx_ids, NULL))
printk(KERN_ERR __FILE__ :
Error while probing of_platform bus\n);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 03/13] [POWERPC] Add common mpc52xx_setup_pci() routine
This patch moves a generic pci init code from lite5200
platform file to a common mpc52xx_setup_pci() routine
and adds additional compatibility property verification.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
arch/powerpc/platforms/52xx/lite5200.c| 12 +---
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 15 +++
include/asm-powerpc/mpc52xx.h |5 +
3 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/lite5200.c
b/arch/powerpc/platforms/52xx/lite5200.c
index 25d2bfa..ce903be 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -131,10 +131,6 @@ static void lite5200_resume_finish(void __iomem *mbar)
static void __init lite5200_setup_arch(void)
{
-#ifdef CONFIG_PCI
- struct device_node *np;
-#endif
-
if (ppc_md.progress)
ppc_md.progress(lite5200_setup_arch(), 0);
@@ -154,13 +150,7 @@ static void __init lite5200_setup_arch(void)
lite5200_pm_init();
#endif
-#ifdef CONFIG_PCI
- np = of_find_node_by_type(NULL, pci);
- if (np) {
- mpc52xx_add_bridge(np);
- of_node_put(np);
- }
-#endif
+ mpc52xx_setup_pci();
}
/*
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
index 4c6c82a..89304f2 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
@@ -406,3 +406,18 @@ mpc52xx_add_bridge(struct device_node *node)
return 0;
}
+
+void __init mpc52xx_setup_pci(void)
+{
+ struct device_node *pci;
+
+ pci = of_find_node_by_type(NULL, pci);
+ if (!pci)
+ return;
+
+ if (of_device_is_compatible(pci, fsl,mpc5200-pci) ||
+ of_device_is_compatible(pci, mpc5200-pci))
+ mpc52xx_add_bridge(pci);
+
+ of_node_put(pci);
+}
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index fcb2ebb..d7efbe0 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -257,7 +257,12 @@ extern void mpc52xx_declare_of_platform_devices(void);
extern void mpc52xx_init_irq(void);
extern unsigned int mpc52xx_get_irq(void);
+#ifdef CONFIG_PCI
extern int __init mpc52xx_add_bridge(struct device_node *node);
+extern void __init mpc52xx_setup_pci(void);
+#else
+static inline void mpc52xx_setup_pci(void) { }
+#endif
extern void __init mpc52xx_map_wdt(void);
extern void mpc52xx_restart(char *cmd);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 05/13] [POWERPC] Export mpc52xx_map_node() routine symbol
Make, so far static, mpc52xx_map_node() routine
symbol available for general use.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
arch/powerpc/platforms/52xx/mpc52xx_common.c |3 ++-
include/asm-powerpc/mpc52xx.h|1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c
b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 2df97c5..7224bfe 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -26,7 +26,7 @@
*/
static volatile struct mpc52xx_gpt *mpc52xx_wdt = NULL;
-static void __iomem *
+void __iomem *
mpc52xx_map_node(struct device_node *ofn)
{
const u32 *regaddr_p;
@@ -47,6 +47,7 @@ mpc52xx_map_node(struct device_node *ofn)
return ioremap((u32)regaddr64, (u32)size64);
}
+EXPORT_SYMBOL_GPL(mpc52xx_map_node);
void __iomem *
mpc52xx_find_and_map(const char *compatible)
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index d7efbe0..1887b13 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -248,6 +248,7 @@ struct mpc52xx_cdm {
#ifndef __ASSEMBLY__
+extern void __iomem * mpc52xx_map_node(struct device_node *);
extern void __iomem * mpc52xx_find_and_map(const char *);
extern void __iomem * mpc52xx_find_and_map_path(const char *path);
extern unsigned int mpc52xx_find_ipb_freq(struct device_node *node);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 07/13] [POWERPC] TQM5200 DTS
Add device tree source file for TQM5200 board.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm5200.dts | 184 +
1 files changed, 184 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/tqm5200.dts
diff --git a/arch/powerpc/boot/dts/tqm5200.dts
b/arch/powerpc/boot/dts/tqm5200.dts
new file mode 100644
index 000..5017cec
--- /dev/null
+++ b/arch/powerpc/boot/dts/tqm5200.dts
@@ -0,0 +1,184 @@
+/*
+ * TQM5200 board Device Tree Source
+ *
+ * Copyright (C) 2007 Semihalf
+ * Marian Balakowicz [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/*
+ * WARNING: Do not depend on this tree layout remaining static just yet.
+ * The MPC5200 device tree conventions are still in flux
+ * Keep an eye on the linuxppc-dev mailing list for more details
+ */
+
+/ {
+ model = tqc,tqm5200;
+ compatible = tqc,tqm5200;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 20;
+ i-cache-line-size = 20;
+ d-cache-size = 4000; // L1, 16K
+ i-cache-size = 4000; // L1, 16K
+ timebase-frequency = 0; // from bootloader
+ bus-frequency = 0;// from bootloader
+ clock-frequency = 0; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0400; // 64MB
+ };
+
+ [EMAIL PROTECTED] {
+ model = fsl,mpc5200;
+ compatible = fsl,mpc5200;
+ revision = ; // from bootloader
+ device_type = soc;
+ ranges = 0 f000 c000;
+ reg = f000 0100;
+ bus-frequency = 0;// from bootloader
+ system-frequency = 0; // from bootloader
+
+ [EMAIL PROTECTED] {
+ compatible = mpc5200-cdm;
+ reg = 200 38;
+ };
+
+ mpc5200_pic: [EMAIL PROTECTED] {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ compatible = mpc5200-pic;
+ reg = 500 80;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200-gpt;
+ reg = 600 10;
+ interrupts = 1 9 0;
+ interrupt-parent = mpc5200_pic;
+ fsl,has-wdt;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = mpc5200-gpio;
+ reg = b00 40;
+ interrupts = 1 7 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = mpc5200-ohci,ohci-be;
+ reg = 1000 ff;
+ interrupts = 2 6 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = mpc5200-bestcomm;
+ reg = 1200 80;
+ interrupts = 3 0 0 3 1 0 3 2 0 3 3 0
+ 3 4 0 3 5 0 3 6 0 3 7 0
+ 3 8 0 3 9 0 3 a 0 3 b 0
+ 3 c 0 3 d 0 3 e 0 3 f 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = mpc5200-xlb;
+ reg = 1f00 100;
+ };
+
+ [EMAIL PROTECTED] { // PSC1
+ device_type = serial;
+ compatible = mpc5200-psc-uart;
+ port-number = 0; // Logical port assignment
+ reg = 2000 100;
+ interrupts = 2 1 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // PSC2
+ device_type = serial;
+ compatible = mpc5200-psc-uart;
+ port-number = 1; // Logical port assignment
+ reg = 2200 100;
+
[PATCH v4 08/13] [POWERPC] TQM5200 defconfig
Add TQM5200 board defconfig file. Signed-off-by: Marian Balakowicz [EMAIL PROTECTED] --- arch/powerpc/configs/tqm5200_defconfig | 1306 1 files changed, 1306 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/configs/tqm5200_defconfig diff --git a/arch/powerpc/configs/tqm5200_defconfig b/arch/powerpc/configs/tqm5200_defconfig new file mode 100644 index 000..53fa968 --- /dev/null +++ b/arch/powerpc/configs/tqm5200_defconfig @@ -0,0 +1,1306 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.23 +# Mon Oct 29 14:01:58 2007 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_PPC_FPU=y +# CONFIG_ALTIVEC is not set +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +# CONFIG_SMP is not set +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +# CONFIG_PPC_UDBG_16550 is not set +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +# CONFIG_PPC_DCR_NATIVE is not set +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +# CONFIG_SYSCTL_SYSCALL is not set +# CONFIG_KALLSYMS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +# CONFIG_EPOLL is not set +CONFIG_SIGNALFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +# CONFIG_KMOD is not set +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory + +# +# Platform support +# +CONFIG_PPC_MULTIPLATFORM=y +# CONFIG_PPC_82xx is not set +# CONFIG_PPC_83xx is not set +# CONFIG_PPC_86xx is not set +CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +CONFIG_PPC_MPC52xx=y +CONFIG_PPC_MPC5200=y +# CONFIG_PPC_MPC5200_BUGFIX is not set +CONFIG_PPC_MPC5200_SIMPLE=y +# CONFIG_PPC_EFIKA is not set +# CONFIG_PPC_LITE5200 is not set +# CONFIG_PPC_PMAC is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +# CONFIG_EMBEDDED6xx is not set +# CONFIG_MPIC is not set +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is not set +# CONFIG_CPU_FREQ is not set +# CONFIG_TAU is not set +# CONFIG_CPM2 is not set +# CONFIG_FSL_ULI1575 is not set +# CONFIG_PPC_BESTCOMM is not set + +# +# Kernel options +# +# CONFIG_HIGHMEM is not set +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set +CONFIG_HZ=250 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set
[PATCH v4 09/13] [POWERPC] CM5200 DTS
Add device tree source file for CM5200 board.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/cm5200.dts | 236 ++
1 files changed, 236 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/cm5200.dts
diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
new file mode 100644
index 000..9295083
--- /dev/null
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -0,0 +1,236 @@
+/*
+ * CM5200 board Device Tree Source
+ *
+ * Copyright (C) 2007 Semihalf
+ * Marian Balakowicz [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/*
+ * WARNING: Do not depend on this tree layout remaining static just yet.
+ * The MPC5200 device tree conventions are still in flux
+ * Keep an eye on the linuxppc-dev mailing list for more details
+ */
+
+/ {
+ model = schindler,cm5200;
+ compatible = schindler,cm5200;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 20;
+ i-cache-line-size = 20;
+ d-cache-size = 4000; // L1, 16K
+ i-cache-size = 4000; // L1, 16K
+ timebase-frequency = 0; // from bootloader
+ bus-frequency = 0;// from bootloader
+ clock-frequency = 0; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0400; // 64MB
+ };
+
+ [EMAIL PROTECTED] {
+ model = fsl,mpc5200b;
+ compatible = fsl,mpc5200b;
+ revision = ; // from bootloader
+ device_type = soc;
+ ranges = 0 f000 c000;
+ reg = f000 0100;
+ bus-frequency = 0;// from bootloader
+ system-frequency = 0; // from bootloader
+
+ [EMAIL PROTECTED] {
+ compatible = mpc5200b-cdm,mpc5200-cdm;
+ reg = 200 38;
+ };
+
+ mpc5200_pic: [EMAIL PROTECTED] {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ compatible = mpc5200b-pic,mpc5200-pic;
+ reg = 500 80;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 600 10;
+ interrupts = 1 9 0;
+ interrupt-parent = mpc5200_pic;
+ fsl,has-wdt;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 610 10;
+ interrupts = 1 a 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 620 10;
+ interrupts = 1 b 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 630 10;
+ interrupts = 1 c 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 640 10;
+ interrupts = 1 d 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 650 10;
+ interrupts = 1 e 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 660 10;
+ interrupts = 1 f 0;
+
[PATCH v4 10/13] [POWERPC] CM5200 defconfig
Add CM5200 board defconfig file. Signed-off-by: Marian Balakowicz [EMAIL PROTECTED] --- arch/powerpc/configs/cm5200_defconfig | 1031 + 1 files changed, 1031 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/configs/cm5200_defconfig diff --git a/arch/powerpc/configs/cm5200_defconfig b/arch/powerpc/configs/cm5200_defconfig new file mode 100644 index 000..a17d966 --- /dev/null +++ b/arch/powerpc/configs/cm5200_defconfig @@ -0,0 +1,1031 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.23 +# Mon Oct 29 14:06:34 2007 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_PPC_FPU=y +# CONFIG_ALTIVEC is not set +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +# CONFIG_SMP is not set +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +# CONFIG_PPC_UDBG_16550 is not set +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +# CONFIG_PPC_DCR_NATIVE is not set +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +# CONFIG_SYSCTL_SYSCALL is not set +# CONFIG_KALLSYMS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +# CONFIG_EPOLL is not set +CONFIG_SIGNALFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +# CONFIG_KMOD is not set +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory + +# +# Platform support +# +CONFIG_PPC_MULTIPLATFORM=y +# CONFIG_PPC_82xx is not set +# CONFIG_PPC_83xx is not set +# CONFIG_PPC_86xx is not set +CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +CONFIG_PPC_MPC52xx=y +CONFIG_PPC_MPC5200=y +# CONFIG_PPC_MPC5200_BUGFIX is not set +CONFIG_PPC_MPC5200_SIMPLE=y +# CONFIG_PPC_EFIKA is not set +# CONFIG_PPC_LITE5200 is not set +# CONFIG_PPC_PMAC is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +# CONFIG_EMBEDDED6xx is not set +# CONFIG_MPIC is not set +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is not set +# CONFIG_CPU_FREQ is not set +# CONFIG_TAU is not set +# CONFIG_CPM2 is not set +# CONFIG_FSL_ULI1575 is not set +# CONFIG_PPC_BESTCOMM is not set + +# +# Kernel options +# +# CONFIG_HIGHMEM is not set +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set +CONFIG_HZ=250 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set
[PATCH v4 11/13] [POWERPC] Motion-PRO: Add LED support
Add LED driver for Promess Motion-PRO board.
Signed-off-by: Jan Wrobel [EMAIL PROTECTED]
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
drivers/leds/Kconfig |7 +
drivers/leds/Makefile |3
drivers/leds/leds-motionpro.c | 250 +
include/asm-powerpc/mpc52xx.h |5 +
4 files changed, 264 insertions(+), 1 deletions(-)
create mode 100644 drivers/leds/leds-motionpro.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ec568fa..1567ed6 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -55,6 +55,13 @@ config LEDS_TOSA
This option enables support for the LEDs on Sharp Zaurus
SL-6000 series.
+config LEDS_MOTIONPRO
+ tristate Motion-PRO LEDs Support
+ depends on LEDS_CLASS PPC_MPC5200
+ help
+ This option enables support for status and ready LEDs connected
+ to GPIO lines on Motion-PRO board.
+
config LEDS_S3C24XX
tristate LED Support for Samsung S3C24XX GPIO LEDs
depends on LEDS_CLASS ARCH_S3C2410
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index a60de1b..a56d399 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -18,7 +18,8 @@ obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
obj-$(CONFIG_LEDS_COBALT_QUBE) += leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
-obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_MOTIONPRO) += leds-motionpro.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
diff --git a/drivers/leds/leds-motionpro.c b/drivers/leds/leds-motionpro.c
new file mode 100644
index 000..7c422d2
--- /dev/null
+++ b/drivers/leds/leds-motionpro.c
@@ -0,0 +1,250 @@
+/*
+ * LEDs driver for the Motion-PRO board.
+ *
+ * Copyright (C) 2007 Semihalf
+ * Jan Wrobel [EMAIL PROTECTED]
+ * Marian Balakowicz [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ *
+ * Decription:
+ * This driver enables control over Motion-PRO status and ready LEDs through
+ * sysfs. LEDs can be controlled by writing to sysfs files:
+ * class/leds/led-name/(brightness|delay_off|delay_on).
+ * See Documentation/leds-class.txt for more details.
+ * led-name is the set to the value of 'label' property of the
+ * corresponding GPT node.
+ *
+ * Before user issues first control command via sysfs, LED blinking is
+ * controlled by the kernel ('blink-delay' property of the GPT node
+ * in the device tree blob).
+ *
+ */
+
+#define DEBUG
+
+#include linux/module.h
+#include linux/leds.h
+#include linux/of_platform.h
+#include asm/mpc52xx.h
+
+/* LED control bits */
+#define LED_ON MPC52xx_GPT_OUTPUT_1
+
+/* LED mode */
+#define LED_MODE_KERNEL1
+#define LED_MODE_USER 2
+
+struct motionpro_led {
+ spinlock_t led_lock;/* Protects the LED data */
+ struct mpc52xx_gpt __iomem *gpt;/* LED registers */
+ struct timer_list blink_timer; /* Used if blink_delay is nonzero */
+ unsigned int blink_delay; /* [ms], if set to 0 blinking is off */
+ unsigned int mode; /* kernel/user */
+ struct led_classdev mpled_cdev; /* LED class */
+};
+
+/*
+ * Timer event - blinks LED before user takes control over it
+ * with the first access via sysfs.
+ */
+static void mpled_timer_toggle(unsigned long data)
+{
+ struct motionpro_led *mpled = (struct motionpro_led *)data;
+
+ spin_lock_bh(mpled-led_lock);
+ if (mpled-mode == LED_MODE_KERNEL) {
+ u32 val = in_be32(mpled-gpt-mode);
+ val ^= LED_ON;
+ out_be32(mpled-gpt-mode, val);
+
+ mod_timer(mpled-blink_timer,
+ jiffies + msecs_to_jiffies(mpled-blink_delay));
+ }
+ spin_unlock_bh(mpled-led_lock);
+}
+
+/*
+ * Turn on/off led according to user settings in sysfs.
+ * First call to this function disables kernel blinking.
+ */
+static void mpled_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct motionpro_led *mpled;
+ int old_mode;
+ u32 val;
+
+ mpled = container_of(led_cdev, struct
[PATCH v4 06/13] [POWERPC] Use EXPORT_SYMBOL_GPL for 52xx common routines symbol export
Replace EXPORT_SYMBOL with EXPORT_SYMBOL_GPL in mpc52xx_common.c
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
arch/powerpc/platforms/52xx/mpc52xx_common.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c
b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 7224bfe..c9e1ab9 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -55,16 +55,14 @@ mpc52xx_find_and_map(const char *compatible)
return mpc52xx_map_node(
of_find_compatible_node(NULL, NULL, compatible));
}
-
-EXPORT_SYMBOL(mpc52xx_find_and_map);
+EXPORT_SYMBOL_GPL(mpc52xx_find_and_map);
void __iomem *
mpc52xx_find_and_map_path(const char *path)
{
return mpc52xx_map_node(of_find_node_by_path(path));
}
-
-EXPORT_SYMBOL(mpc52xx_find_and_map_path);
+EXPORT_SYMBOL_GPL(mpc52xx_find_and_map_path);
/**
* mpc52xx_find_ipb_freq - Find the IPB bus frequency for a device
@@ -93,7 +91,7 @@ mpc52xx_find_ipb_freq(struct device_node *node)
return p_ipb_freq ? *p_ipb_freq : 0;
}
-EXPORT_SYMBOL(mpc52xx_find_ipb_freq);
+EXPORT_SYMBOL_GPL(mpc52xx_find_ipb_freq);
/*
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: help linux for linux2.6
On Fri, Nov 09, 2007 at 02:39:04PM +0800, vincent.liu wrote: These days I am working on a MPC8270 based board with linux 2.6.10 kernel. When I use the default kernel and load the uImage to the target board. The kernel hangs after uncompressing kernel image ... ok . The default kernel for what board? I am freshman in the embedded linux area,So I do not know how to go on this project. From internet , I searched many articles,and no gain. I suggest trying head-of-tree (with arch/powerpc, not arch/ppc) rather than very old kernels, and making sure that the kernel you're building actually supports your hardware. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4 00/13] [POWERPC] Add TQM5200/CM5200/Motion-PRO board support
On 11/9/07, Marian Balakowicz [EMAIL PROTECTED] wrote: This is a yet another version of the patches that add arch/powerpc support for three MPC5200 based boards: TQ-Components TQM5200, Schindler CM5200 and Promess Motion-PRO. Updates include modifications to mpc5200_simple_probe() routine in the generic support for simple MPC5200 based boards, changes to leds-motionpro driver - using common compatility property for both LEDs, and few other .dts cleanups. [POWERPC] Promess Motion-PRO defconfig [POWERPC] Promess Motion-PRO DTS [POWERPC] Motion-PRO: Add LED support. [POWERPC] CM5200 defconfig [POWERPC] CM5200 DTS [POWERPC] TQM5200 defconfig [POWERPC] TQM5200 DTS [POWERPC] Use EXPORT_SYMBOL_GPL for 52xx common routines symbol export [POWERPC] Export mpc52xx_map_node() routine symbol [POWERPC] Add generic support for simple MPC5200 based boards [POWERPC] Add common mpc52xx_setup_pci() routine [POWERPC] Add 'fsl,lpb' bus type for MPC5200 LocalPlus Bus [POWERPC] Add 'model: ...' line to common show_cpuinfo() Please review, and if everything is ok schedule for 2.6.24-rc3. Just to be clear, I won't be picking up these changes until the 2.6.25 merge window. The .24 tree is closed for new board support patches and is in bug fix only mode. Thanks, g. Cheers, m. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 12/13] [POWERPC] Promess Motion-PRO DTS
On 11/6/07, David Gibson [EMAIL PROTECTED] wrote:
On Tue, Nov 06, 2007 at 09:06:34PM +0100, Marian Balakowicz wrote:
[snip]
+ // PSC2 in spi master mode
+ [EMAIL PROTECTED] { // PSC2
+ compatible = mpc5200b-psc-spi,mpc5200-psc-spi;
+ cell-index = 1;
From your description, this is an incorrect usage of cell-index - it
should *only* be used to index into SoC shared registers; never for
logical numbering.
Actually, this one is correct. PSCs are numbered in the data sheet
from PSC1 to PSC6; so cell-index = 0 for PSC1, cell-index = 1 for
PSC2, etc.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 12/13] [POWERPC] Promess Motion-PRO DTS
Add device tree source file for Motion-PRO board.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/motionpro.dts | 309 +++
1 files changed, 309 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/motionpro.dts
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
new file mode 100644
index 000..d8c316a
--- /dev/null
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -0,0 +1,309 @@
+/*
+ * Motion-PRO board Device Tree Source
+ *
+ * Copyright (C) 2007 Semihalf
+ * Marian Balakowicz [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/*
+ * WARNING: Do not depend on this tree layout remaining static just yet.
+ * The MPC5200 device tree conventions are still in flux
+ * Keep an eye on the linuxppc-dev mailing list for more details
+ */
+
+/ {
+ model = promess,motionpro;
+ compatible = promess,motionpro;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 20;
+ i-cache-line-size = 20;
+ d-cache-size = 4000; // L1, 16K
+ i-cache-size = 4000; // L1, 16K
+ timebase-frequency = 0; // from bootloader
+ bus-frequency = 0;// from bootloader
+ clock-frequency = 0; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0400; // 64MB
+ };
+
+ [EMAIL PROTECTED] {
+ model = fsl,mpc5200b;
+ compatible = fsl,mpc5200b;
+ revision = ; // from bootloader
+ device_type = soc;
+ ranges = 0 f000 c000;
+ reg = f000 0100;
+ bus-frequency = 0;// from bootloader
+ system-frequency = 0; // from bootloader
+
+ [EMAIL PROTECTED] {
+ compatible = mpc5200b-cdm,mpc5200-cdm;
+ reg = 200 38;
+ };
+
+ mpc5200_pic: [EMAIL PROTECTED] {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ compatible = mpc5200b-pic,mpc5200-pic;
+ reg = 500 80;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 600 10;
+ interrupts = 1 9 0;
+ interrupt-parent = mpc5200_pic;
+ fsl,has-wdt;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 610 10;
+ interrupts = 1 a 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 620 10;
+ interrupts = 1 b 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 630 10;
+ interrupts = 1 c 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 640 10;
+ interrupts = 1 d 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 650 10;
+ interrupts = 1 e 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // Motion-PRO status LED
+ compatible = promess,motionpro-led;
+ label = motionpro-statusled;
+ reg = 660 10;
+
[PATCH v4 13/13] [POWERPC] Promess Motion-PRO defconfig
Add Motion-PRO board defconfig file. Signed-off-by: Marian Balakowicz [EMAIL PROTECTED] --- arch/powerpc/configs/motionpro_defconfig | 989 ++ 1 files changed, 989 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/configs/motionpro_defconfig diff --git a/arch/powerpc/configs/motionpro_defconfig b/arch/powerpc/configs/motionpro_defconfig new file mode 100644 index 000..fd7a327 --- /dev/null +++ b/arch/powerpc/configs/motionpro_defconfig @@ -0,0 +1,989 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.23 +# Mon Oct 29 14:11:27 2007 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_PPC_FPU=y +# CONFIG_ALTIVEC is not set +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +# CONFIG_SMP is not set +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +# CONFIG_PPC_UDBG_16550 is not set +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +# CONFIG_PPC_DCR_NATIVE is not set +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +# CONFIG_SYSCTL_SYSCALL is not set +# CONFIG_KALLSYMS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +# CONFIG_EPOLL is not set +CONFIG_SIGNALFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +# CONFIG_KMOD is not set +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory + +# +# Platform support +# +CONFIG_PPC_MULTIPLATFORM=y +# CONFIG_PPC_82xx is not set +# CONFIG_PPC_83xx is not set +# CONFIG_PPC_86xx is not set +CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +CONFIG_PPC_MPC52xx=y +CONFIG_PPC_MPC5200=y +# CONFIG_PPC_MPC5200_BUGFIX is not set +CONFIG_PPC_MPC5200_SIMPLE=y +# CONFIG_PPC_EFIKA is not set +# CONFIG_PPC_LITE5200 is not set +# CONFIG_PPC_PMAC is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +# CONFIG_EMBEDDED6xx is not set +# CONFIG_MPIC is not set +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is not set +# CONFIG_CPU_FREQ is not set +# CONFIG_TAU is not set +# CONFIG_CPM2 is not set +# CONFIG_FSL_ULI1575 is not set +# CONFIG_PPC_BESTCOMM is not set + +# +# Kernel options +# +# CONFIG_HIGHMEM is not set +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set +CONFIG_HZ=250 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set
Re: PPC440EPx on Sequoia: /proc/iomem acts weird
On Fri, 09 Nov 2007 13:30:03 -0500 Steven A. Falco [EMAIL PROTECTED] wrote: If I cat /proc/iomem on a Sequoia board, it never stops printing. Here are the first 10 lines: bash-3.00# head -10 /proc/iomem e100-e17f : usb e100-e17f : musbhsfc_udc e300-e38f : ehci_hcd 18000-18fff : /plb/[EMAIL PROTECTED] 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc Basically, the last line (regarding the nand flash) keeps repeating forever. Is anyone else seeing this behavior? My kernel is 2.6.23 with Xenomai patched in. Erm.. 2.6.23? There is no Sequoia support in arch/ppc or arch/powerpc for 2.6.23 in the official trees. What is Xenomai? You should probably talk to them. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PPC440EPx on Sequoia: /proc/iomem acts weird
If I cat /proc/iomem on a Sequoia board, it never stops printing. Here are the first 10 lines: bash-3.00# head -10 /proc/iomem e100-e17f : usb e100-e17f : musbhsfc_udc e300-e38f : ehci_hcd 18000-18fff : /plb/[EMAIL PROTECTED] 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc Basically, the last line (regarding the nand flash) keeps repeating forever. Is anyone else seeing this behavior? My kernel is 2.6.23 with Xenomai patched in. Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC440EPx on Sequoia: /proc/iomem acts weird
I am using the Denx 2.6.32 kernel, which does have powerpc/sequoia. Xenomai is a real-time kernel built on Adeos/Ipipe. I'll dig into it further. Steve Josh Boyer wrote: On Fri, 09 Nov 2007 13:30:03 -0500 Steven A. Falco [EMAIL PROTECTED] wrote: If I cat /proc/iomem on a Sequoia board, it never stops printing. Here are the first 10 lines: bash-3.00# head -10 /proc/iomem e100-e17f : usb e100-e17f : musbhsfc_udc e300-e38f : ehci_hcd 18000-18fff : /plb/[EMAIL PROTECTED] 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc 1d000-1d0001fff : ndfc Basically, the last line (regarding the nand flash) keeps repeating forever. Is anyone else seeing this behavior? My kernel is 2.6.23 with Xenomai patched in. Erm.. 2.6.23? There is no Sequoia support in arch/ppc or arch/powerpc for 2.6.23 in the official trees. What is Xenomai? You should probably talk to them. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hardware watchpoints on Cell/B.E. broken
Hello, I've noticed that GDB hardware watchpoints do not work at all on Cell/B.E. (when running without hypervisor); the kernel accepts the PTRACE_SET_DEBUGREG call without error, but watchpoints never trigger. This turns out to be caused by a new hardware feature in the PowerPC 2.02 architecture level: the DABRX register. This register controls in which modes of operation (problem state, privileged state, hypervisor state) the DABR register takes effect. (See Book III v 2.02 page 40.) The default setting of that register on Cell/B.E. (at least on IBM blades), which the Linux kernel currently never modifies, is to ignore DABR in all modes -- thus watchpoints do not work at all. The following hack sets the bit in the DABRX that enables the DABR for problem state, whenever the DABR is set. With this patch on top of the current Fedora 8 update kernel (kernel-2.6.23.1-48.fc8) watchpoints work again -- all relevant test cases in the GDB test suite now pass. Obviously, the patch cannot be applied as-is; we need to make sure we are on a machine that supports the DABRX feature. Arnd asked me to post this anyway as a heads-up on that problem ... Bye, Ulrich --- linux-2.6.23.ppc64/arch/powerpc/kernel/process.c.orig +++ linux-2.6.23.ppc64/arch/powerpc/kernel/process.c @@ -229,6 +229,7 @@ /* XXX should we have a CPU_FTR_HAS_DABR ? */ #if defined(CONFIG_PPC64) || defined(CONFIG_6xx) mtspr(SPRN_DABR, dabr); + mtspr(1015, 1); /* enable DABR for user space */ #endif return 0; } -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Fri, 9 Nov 2007 16:25:07 +0300 Anton Vorontsov [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote: [...] right, but whether it does or not doesn't affect your failure outcome either I'm assuming. If it's something like 0x03, the u-boot patch will probably look like: if ((bcsr[12] == 0x10) (immr-sysconf.spridr == SPR_8360_REV21 || immr-sysconf.spridr == SPR_8360E_REV21)) /* if phy-connection-type is rgmii-id, set it to rgmii-rxid */ ... but these linux patches would remain the same (the clk and data delay settings for the UCC's are still valid; it's just the PHY config that is triggering your problem from what I can tell). Yup, most likely this is not UCC specific, but PHY. For some reason delays making harm here... And today I was unable to reproduce yesterday's behaviour. Your patches works fine, with sixth patch and without it. With -rxid and with just -id. excellent. btw, you should be paying a 50% packet loss price by not going with the -rxid. ping your board with '-q -s 1400 -i 0.01 -c 100' to notice the difference. Though, after few resets I hit on that: - - - - U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX Reset Status: External/Internal Soft, External/Internal Hard CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz Board: Freescale MPC8360EMDS I2C: ready DRAM: 256 MB (DDR2, 64-bit, ECC on) SDRAM: 64 MB (local bus) FLASH: 32 MB In:serial Out: serial Err: serial Net: UEC: PHY is Marvell 88E11x1 (1410cc2) FSL UEC0: Full Duplex switching to rgmii 100 FSL UEC0: Speed 100BT FSL UEC0: Link is up read wrong value : mii_id 1,mii_reg 2, base e0103120 read wrong value : mii_id 1,mii_reg 3, base e0103120 UEC: PHY is Generic MII () read wrong value : mii_id 1,mii_reg 1, base e0103120 read wrong value : mii_id 1,mii_reg 1, base e0103120 read wrong value : mii_id 1,mii_reg 5, base e0103120 FSL UEC1: Full Duplex switching to rgmii 100 FSL UEC1: Speed 100BT FSL UEC1: Link is up FSL UEC0, FSL UEC1 - - - - And UCC1 does not work at all. After another reset that message disappears and it does work again. the RGMII bcsr settings survive soft-resets, which confuse u-boot since it uses GMII mode. Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Using PVR value after boot?
I'm writing a module for the Security/KASUMI function on the PPC440EPx-S and PPC440GRx-S. This relies on checking the PVR value at runtime, which is done early on in the boot process. What would be the correct way to check which CPU is present during module initialization? Thanks, Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] fix multiple bugs in rtas_ibm_suspend_me code
There are several issues with the rtas_ibm_suspend_me code, which
enables platform-assisted suspension of an LPAR for migration or
hibernation as covered in PAPR 2.2.
1.) rtas_ibm_suspend_me uses on_each_cpu() to invoke
rtas_percpu_suspend_me on all cpus via IPI:
if (on_each_cpu(rtas_percpu_suspend_me, data, 1, 0))
...
'data' is on the calling task's stack, but rtas_ibm_suspend_me takes
no measures to ensure that all instances of rtas_percpu_suspend_me are
finished accessing 'data' before returning. This can result in the
IPI'd cpus accessing random stack data and getting stuck in H_JOIN.
This is addressed by using an atomic count of workers and a completion
on the stack.
2.) rtas_percpu_suspend_me is needlessly calling H_JOIN in a loop.
The only event that can cause a cpu to return from H_JOIN is an H_PROD
from another cpu or a NMI/system reset. Each cpu need call H_JOIN
only once per suspend operation.
Remove the loop and the now unnecessary 'waiting' state variable.
3.) H_JOIN must be called with MSR[EE] off, but lazy interrupt
disabling may cause the caller of rtas_ibm_suspend_me to call H_JOIN
with it on; the local_irq_disable() in on_each_cpu() is not
sufficient.
Fix this by explicitly saving the MSR and clearing the EE bit before
calling H_JOIN.
4.) H_PROD is being called with the Linux logical cpu number as the
parameter, not the platform interrupt server value. (It's also being
called for all possible cpus, which is harmless, but unnecessary.)
This is fixed by calling H_PROD for each online cpu using
get_hard_smp_processor_id(cpu) for the argument.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/rtas.c | 94 +---
1 files changed, 53 insertions(+), 41 deletions(-)
Changes since v1:
- the completion is adequate for ensuring that all IPIs have
completed, so there's no need for a mutex and rtas_suspend_me_data
can be on the stack as before.
- add fix for hard-disabling interrupts before H_JOIN
- remove unnecessary H_JOIN loop and state machinery
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 2147807..3afe771 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -41,8 +41,10 @@ struct rtas_t rtas = {
EXPORT_SYMBOL(rtas);
struct rtas_suspend_me_data {
- long waiting;
- struct rtas_args *args;
+ atomic_t working; /* number of cpus accessing this struct */
+ int token; /* ibm,suspend-me */
+ int error;
+ struct completion *complete; /* wait on this until working == 0 */
};
DEFINE_SPINLOCK(rtas_data_buf_lock);
@@ -657,50 +659,62 @@ static int ibm_suspend_me_token = RTAS_UNKNOWN_SERVICE;
#ifdef CONFIG_PPC_PSERIES
static void rtas_percpu_suspend_me(void *info)
{
- int i;
long rc;
- long flags;
+ unsigned long msr_save;
+ int cpu;
struct rtas_suspend_me_data *data =
(struct rtas_suspend_me_data *)info;
- /*
-* We use waiting to indicate our state. As long
-* as it is 0, we are still trying to all join up.
-* If it goes to 0, we have successfully joined up and
-* one thread got H_CONTINUE. If any error happens,
-* we set it to 0.
-*/
- local_irq_save(flags);
- do {
- rc = plpar_hcall_norets(H_JOIN);
- smp_rmb();
- } while (rc == H_SUCCESS data-waiting 0);
- if (rc == H_SUCCESS)
- goto out;
+ atomic_inc(data-working);
+
+ /* really need to ensure MSR.EE is off for H_JOIN */
+ msr_save = mfmsr();
+ mtmsr(msr_save ~(MSR_EE));
+
+ rc = plpar_hcall_norets(H_JOIN);
+
+ mtmsr(msr_save);
- if (rc == H_CONTINUE) {
- data-waiting = 0;
- data-args-args[data-args-nargs] =
- rtas_call(ibm_suspend_me_token, 0, 1, NULL);
- for_each_possible_cpu(i)
- plpar_hcall_norets(H_PROD,i);
+ if (rc == H_SUCCESS) {
+ /* This cpu was prodded and the suspend is complete. */
+ goto out;
+ } else if (rc == H_CONTINUE) {
+ /* All other cpus are in H_JOIN, this cpu does
+* the suspend.
+*/
+ printk(KERN_DEBUG calling ibm,suspend-me on cpu %i\n,
+ smp_processor_id());
+ data-error = rtas_call(data-token, 0, 1, NULL);
+
+ if (data-error)
+ printk(KERN_DEBUG ibm,suspend-me returned %d\n,
+ data-error);
} else {
- data-waiting = -EBUSY;
- printk(KERN_ERR Error on H_JOIN hypervisor call\n);
+ printk(KERN_ERR H_JOIN on cpu %i failed with rc = %ld\n,
+ smp_processor_id(), rc);
+ data-error = rc;
}
-
+ /* This cpu did the suspend or got an error; in either case,
+
Re: Using PVR value after boot?
On Fri, 2007-11-09 at 15:39 -0500, Mike Nuss wrote: I'm writing a module for the Security/KASUMI function on the PPC440EPx-S and PPC440GRx-S. This relies on checking the PVR value at runtime, which is done early on in the boot process. What would be the correct way to check which CPU is present during module initialization? Checking the PVR can be done at any time, though a better option would be to put something in device-tree of course :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware watchpoints on Cell/B.E. broken
On Fri, 2007-11-09 at 19:54 +0100, Ulrich Weigand wrote: Hello, I've noticed that GDB hardware watchpoints do not work at all on Cell/B.E. (when running without hypervisor); the kernel accepts the PTRACE_SET_DEBUGREG call without error, but watchpoints never trigger. This turns out to be caused by a new hardware feature in the PowerPC 2.02 architecture level: the DABRX register. This register controls in which modes of operation (problem state, privileged state, hypervisor state) the DABR register takes effect. (See Book III v 2.02 page 40.) The default setting of that register on Cell/B.E. (at least on IBM blades), which the Linux kernel currently never modifies, is to ignore DABR in all modes -- thus watchpoints do not work at all. The following hack sets the bit in the DABRX that enables the DABR for problem state, whenever the DABR is set. With this patch on top of the current Fedora 8 update kernel (kernel-2.6.23.1-48.fc8) watchpoints work again -- all relevant test cases in the GDB test suite now pass. Obviously, the patch cannot be applied as-is; we need to make sure we are on a machine that supports the DABRX feature. Arnd asked me to post this anyway as a heads-up on that problem ... Hrm, ok, something we missed, I'll have a look. The whole DABR / debug register handling need work anyway. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Appletouch going wild
On Fri, 2007-11-09 at 13:58 +0100, Andreas Schwab wrote: Every once in a while the touchpad in my iBook G4 (geyser1, 030B) is going wild, emitting random movement events even when not being touched. That started only with 2.6.24-rc1. The only way to stop it is to reload the appletouch module. My guess would be that reinitializing the touchpad can result in some kind of race condition. I always had that problem if I do something like leaving my finger too long on it... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix oops related to 4xx flush_tlb_page modification
On Fri, 2007-11-09 at 03:58 -0600, Kumar Gala wrote:
kmap_atomic calls flush_tlb_page with a NULL VMA and thus we end
up dereferencing a NULL pointer to try and get the context.id.
If the VMA is null use the global pid value of 0.
Ack.
---
include/asm-powerpc/tlbflush.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/tlbflush.h b/include/asm-powerpc/tlbflush.h
index e7b4c0d..5c91081 100644
--- a/include/asm-powerpc/tlbflush.h
+++ b/include/asm-powerpc/tlbflush.h
@@ -44,13 +44,13 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma-vm_mm-context.id);
+ _tlbie(vmaddr, vma ? vma-vm_mm-context.id : 0);
}
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma-vm_mm-context.id);
+ _tlbie(vmaddr, vma ? vma-vm_mm-context.id : 0);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On-going 4xx porting
Hi All, For those interested, I have a few things I'd like to focus on for 2.6.25 in regards to the current arch/powerpc 4xx porting effort. Below is a brief list of drivers in no particular order: PCI support USB (440EP(x), etc) I2C GPIO NDFC RTC I'd also like to try and get the larger page size patches ported and merged. If another hugetlbfs type patch shows up, that would be good too. There is also the HW watchpoint support patch, and of course new board ports. At some point we should really be able to have a single vmlinux be wrapped with different zImage wrappers and .dts files and have it boot on those various boards just fine. So I'll be looking at accomplishing that as well. That should make new board ports fairly easy to do. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Avoid unpaired stwcx. on some processors
The context switch code in the kernel issues a dummy stwcx. to clear the reservation, as recommended by the architecture. However, some processors can have issues if this stwcx to address A occurs while the reservation is already held to a different address B. To avoid this problem, the dummy stwcx. needs to be paired with a dummy lwarx to the same address. This patch adds the dummy lwarx, and creates a cpu feature bit to indicate which cpus are affected. Tested on mpc8641_hpcn_defconfig in arch/powerpc; build tested in arch/ppc. Signed-off-by Becky Bruce [EMAIL PROTECTED] --- arch/powerpc/kernel/entry_32.S |6 ++ arch/ppc/kernel/entry.S|6 ++ include/asm-powerpc/cputable.h | 22 -- 3 files changed, 24 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 21d889e..6461dca 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -244,6 +244,9 @@ syscall_exit_cont: andis. r10,r0,[EMAIL PROTECTED] bnel- load_dbcr0 #endif +BEGIN_FTR_SECTION + lwarx r7,0,r1 +END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) stwcx. r0,0,r1 /* to clear the reservation */ lwz r4,_LINK(r1) lwz r5,_CCR(r1) @@ -694,6 +697,9 @@ restore: mtctr r11 PPC405_ERR77(0,r1) +BEGIN_FTR_SECTION + lwarx r11,0,r1 +END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) stwcx. r0,0,r1 /* to clear the reservation */ #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE)) diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S index fba7ca1..aa57dee 100644 --- a/arch/ppc/kernel/entry.S +++ b/arch/ppc/kernel/entry.S @@ -244,6 +244,9 @@ syscall_exit_cont: andis. r10,r0,[EMAIL PROTECTED] bnel- load_dbcr0 #endif +BEGIN_FTR_SECTION + lwarx r7,0,r1 +END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) stwcx. r0,0,r1 /* to clear the reservation */ lwz r4,_LINK(r1) lwz r5,_CCR(r1) @@ -690,6 +693,9 @@ restore: mtctr r11 PPC405_ERR77(0,r1) +BEGIN_FTR_SECTION + lwarx r11,0,r1 +END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) stwcx. r0,0,r1 /* to clear the reservation */ #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE)) diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h index 9d74338..4525c78 100644 --- a/include/asm-powerpc/cputable.h +++ b/include/asm-powerpc/cputable.h @@ -138,6 +138,7 @@ extern void do_feature_fixups(unsigned long value, void *fixup_start, #define CPU_FTR_FPU_UNAVAILABLEASM_CONST(0x0080) #define CPU_FTR_UNIFIED_ID_CACHE ASM_CONST(0x0100) #define CPU_FTR_SPEASM_CONST(0x0200) +#define CPU_FTR_NEED_PAIRED_STWCX ASM_CONST(0x0400) /* * Add the 64-bit processor unique features in the top half of the word; @@ -261,25 +262,25 @@ extern void do_feature_fixups(unsigned long value, void *fixup_start, #define CPU_FTRS_7450_20 (CPU_FTR_COMMON | \ CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \ - CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE) + CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX) #define CPU_FTRS_7450_21 (CPU_FTR_COMMON | \ CPU_FTR_USE_TB | \ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP | \ - CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE) + CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX) #define CPU_FTRS_7450_23 (CPU_FTR_COMMON | \ - CPU_FTR_USE_TB | \ + CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE) #define CPU_FTRS_7455_1(CPU_FTR_COMMON | \ - CPU_FTR_USE_TB | \ + CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \ CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | CPU_FTR_L3CR | \ CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | CPU_FTR_HAS_HIGH_BATS | \ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE) #define CPU_FTRS_7455_20 (CPU_FTR_COMMON | \ - CPU_FTR_USE_TB | \ + CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP | \ @@ -289,31 +290,32 @@ extern void do_feature_fixups(unsigned
[PATCH] Avoid unpaired stwcx. on some processors
The context switch code in the kernel issues a dummy stwcx. to clear the reservation, as recommended by the architecture. However, some processors can have issues if this stwcx to address A occurs while the reservation is already held to a different address B. To avoid this problem, the dummy stwcx. needs to be paired with a dummy lwarx to the same address. This patch adds the dummy lwarx, and creates a cpu feature bit to indicate which cpus are affected. Tested on mpc8641_hpcn_defconfig in arch/powerpc; build tested in arch/ppc. Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- Resend with correct signed-off-by line! arch/powerpc/kernel/entry_32.S |6 ++ arch/ppc/kernel/entry.S|6 ++ include/asm-powerpc/cputable.h | 22 -- 3 files changed, 24 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 21d889e..6461dca 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -244,6 +244,9 @@ syscall_exit_cont: andis. r10,r0,[EMAIL PROTECTED] bnel- load_dbcr0 #endif +BEGIN_FTR_SECTION + lwarx r7,0,r1 +END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) stwcx. r0,0,r1 /* to clear the reservation */ lwz r4,_LINK(r1) lwz r5,_CCR(r1) @@ -694,6 +697,9 @@ restore: mtctr r11 PPC405_ERR77(0,r1) +BEGIN_FTR_SECTION + lwarx r11,0,r1 +END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) stwcx. r0,0,r1 /* to clear the reservation */ #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE)) diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S index fba7ca1..aa57dee 100644 --- a/arch/ppc/kernel/entry.S +++ b/arch/ppc/kernel/entry.S @@ -244,6 +244,9 @@ syscall_exit_cont: andis. r10,r0,[EMAIL PROTECTED] bnel- load_dbcr0 #endif +BEGIN_FTR_SECTION + lwarx r7,0,r1 +END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) stwcx. r0,0,r1 /* to clear the reservation */ lwz r4,_LINK(r1) lwz r5,_CCR(r1) @@ -690,6 +693,9 @@ restore: mtctr r11 PPC405_ERR77(0,r1) +BEGIN_FTR_SECTION + lwarx r11,0,r1 +END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) stwcx. r0,0,r1 /* to clear the reservation */ #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE)) diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h index 9d74338..4525c78 100644 --- a/include/asm-powerpc/cputable.h +++ b/include/asm-powerpc/cputable.h @@ -138,6 +138,7 @@ extern void do_feature_fixups(unsigned long value, void *fixup_start, #define CPU_FTR_FPU_UNAVAILABLEASM_CONST(0x0080) #define CPU_FTR_UNIFIED_ID_CACHE ASM_CONST(0x0100) #define CPU_FTR_SPEASM_CONST(0x0200) +#define CPU_FTR_NEED_PAIRED_STWCX ASM_CONST(0x0400) /* * Add the 64-bit processor unique features in the top half of the word; @@ -261,25 +262,25 @@ extern void do_feature_fixups(unsigned long value, void *fixup_start, #define CPU_FTRS_7450_20 (CPU_FTR_COMMON | \ CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \ - CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE) + CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX) #define CPU_FTRS_7450_21 (CPU_FTR_COMMON | \ CPU_FTR_USE_TB | \ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP | \ - CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE) + CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX) #define CPU_FTRS_7450_23 (CPU_FTR_COMMON | \ - CPU_FTR_USE_TB | \ + CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE) #define CPU_FTRS_7455_1(CPU_FTR_COMMON | \ - CPU_FTR_USE_TB | \ + CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \ CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | CPU_FTR_L3CR | \ CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | CPU_FTR_HAS_HIGH_BATS | \ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE) #define CPU_FTRS_7455_20 (CPU_FTR_COMMON | \ - CPU_FTR_USE_TB | \ + CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP | \ @@ -289,31 +290,32
Re: [PATCH 0/5 v3] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver.
Zhang Wei-r63237 wrote: Yes, I'm working on it. Do not worry about it. How's this going? I've been working on this a bit myself, but if you are close to posting your stuff, I'll stop and wait for your version instead. It doesn't make sense for us to duplicate the same work. Randy Vinson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Avoid unpaired stwcx. on some processors
On Fri, Nov 09, 2007 at 04:08:06PM -0600, Becky Bruce wrote: The context switch code in the kernel issues a dummy stwcx. to clear the reservation, as recommended by the architecture. However, some processors can have issues if this stwcx to address A occurs while the reservation is already held to a different address B. To avoid this problem, the dummy stwcx. needs to be paired with a dummy lwarx to the same address. This patch adds the dummy lwarx, and creates a cpu feature bit to indicate which cpus are affected. Tested on mpc8641_hpcn_defconfig in arch/powerpc; build tested in arch/ppc. You're still exposed even with this patch. The stwcx is there to protect from the cases where process 1 does lwarx and get context switched out to process 2 that by pure random chance does a stwcx. to the same reservation granule and succeeds, in spite of not having done the lwarx (on this side of the context switch). In exactly that case, process 2 will instead of doing a store to a reservation it didn't take on it's own, do a dangling stwcx, which is your erratum. Right? Seems like a better (but still ugly) workaround would be to create a _new_ reservation to a RA that's unavailable to any userspace process, so that they could never do a successful store to it. That way you would have stray reservations, but never dangling stwcx:es. No? -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: On-going 4xx porting
On Fri, 09 Nov 2007 16:01:41 -0600 Josh Boyer wrote: Hi All, For those interested, I have a few things I'd like to focus on for 2.6.25 in regards to the current arch/powerpc 4xx porting effort. Below is a brief list of drivers in no particular order: PCI support I'll look at that stuff once again. maybe it worths to head fir compromise solution in favor of replacing 32/64 ranges parsing func + a bunch of other things in one single step. USB (440EP(x), etc) looks like we have code ready for that... I2C Stefan's approach seems pretty close GPIO NDFC I'd rather follow platform device wrapper way.. Big NDFC of_device rework can be done anytime later. RTC I'd also like to try and get the larger page size patches ported and merged. If another hugetlbfs type patch shows up, that would be good too. There is also the HW watchpoint support patch, and of course new board ports. At some point we should really be able to have a single vmlinux be wrapped with different zImage wrappers and .dts files and have it boot on those various boards just fine. So I'll be looking at accomplishing that as well. That should make new board ports fairly easy to do. just my $0.02... josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Avoid unpaired stwcx. on some processors
On Nov 9, 2007, at 5:19 PM, Olof Johansson wrote: On Fri, Nov 09, 2007 at 04:08:06PM -0600, Becky Bruce wrote: The context switch code in the kernel issues a dummy stwcx. to clear the reservation, as recommended by the architecture. However, some processors can have issues if this stwcx to address A occurs while the reservation is already held to a different address B. To avoid this problem, the dummy stwcx. needs to be paired with a dummy lwarx to the same address. This patch adds the dummy lwarx, and creates a cpu feature bit to indicate which cpus are affected. Tested on mpc8641_hpcn_defconfig in arch/ powerpc; build tested in arch/ppc. You're still exposed even with this patch. The stwcx is there to protect from the cases where process 1 does lwarx and get context switched out to process 2 that by pure random chance does a stwcx. to the same reservation granule and succeeds, in spite of not having done the lwarx (on this side of the context switch). In exactly that case, process 2 will instead of doing a store to a reservation it didn't take on it's own, do a dangling stwcx, which is your erratum. Right? I don't think so. It's not plain old dangling stwcx that's the problem. It's dangling stwcx when the reservation is held to another address. The lwarx that I've added prevents the normally dangling stwcx. in the context switch/syscall path from meeting this condition. Any process that gets swapped in and executes stwcx. first thing is fine, because the reservation was previously cleared by the stwcx. in the context switch path. BTW, I think you're missing a key point here, which is this: Architecturally, there is a single reservation per core. On e600 and other parts, the stwcx. does *not* take the address into account for success. If you stwcx, and the reservation is held, it succeeds regardless of the address. Fun, no? That's one of the reasons it's so important that the kernel have the dummy stwcx. in place. Does that make sense? -B ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Avoid unpaired stwcx. on some processors
On Fri, Nov 09, 2007 at 05:52:30PM -0600, Becky Bruce wrote: I don't think so. It's not plain old dangling stwcx that's the problem. It's dangling stwcx when the reservation is held to another address. Gack, I misread the description. My bad. The lwarx that I've added prevents the normally dangling stwcx. in the context switch/syscall path from meeting this condition. Any process that gets swapped in and executes stwcx. first thing is fine, because the reservation was previously cleared by the stwcx. in the context switch path. BTW, I think you're missing a key point here, which is this: Architecturally, there is a single reservation per core. On e600 and other parts, the stwcx. does *not* take the address into account for success. If you stwcx, and the reservation is held, it succeeds regardless of the address. Fun, no? That's one of the reasons it's so important that the kernel have the dummy stwcx. in place. Does that make sense? Yep, it does, doesn't seem to be a better way to work around it. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: On-going 4xx porting
On Sat, 2007-11-10 at 02:48 +0300, Vitaly Bordug wrote: On Fri, 09 Nov 2007 16:01:41 -0600 Josh Boyer wrote: Hi All, For those interested, I have a few things I'd like to focus on for 2.6.25 in regards to the current arch/powerpc 4xx porting effort. Below is a brief list of drivers in no particular order: PCI support I'll look at that stuff once again. maybe it worths to head fir compromise solution in favor of replacing 32/64 ranges parsing func + a bunch of other things in one single step. Sure, that's fine. You and Ben were working on it at one point, so I figured you would look at it again. USB (440EP(x), etc) looks like we have code ready for that... It's mostly there, yes. Should be pretty easy to get in :). I2C Stefan's approach seems pretty close Agreed. GPIO NDFC I'd rather follow platform device wrapper way.. Big NDFC of_device rework can be done anytime later. I would seriously consider that too. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: Add kdump support
To support ehea driver reloading in a kdump kernel the driver has to
perform firmware handle deregistrations when the original kernel
crashes. As there's currently no notifier chain for machine crashes
this patch enables kdump support in the ehea driver by bending the
ppc_md.machine_crash_shutdown hook to its own machine crash
handler. The original machine_crash_shutdown() fn is called
afterwards. This works fine as long as the ehea driver is the only one
which does so. Problems may occur if other drivers do the same and
unload regularly . This patch enables 2.6.24-rc2 to use kdump with
ehea and only puts a very low risk on base kernel. In 2.6.24 we know
ehea is the only user of this mechanism. The next step for 2.6.25
would be to add a proper notifier chain. The full solution might be
that register_reboot_notifier() provides sth like a SYS_CRASH
action. Please apply.
If we are going to do this workaround, I'd prefer the notifier chain be
done correctly now. The way it's hacked in here, it's more likely to
cause even more issues.
Either way, if this is going to go in, it at least needs to be acked by
Paulus.
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c | 28
2 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index f78e5bf..5935899 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSION EHEA_0080
+#define DRV_VERSION EHEA_0081
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f0319f1..40a732e 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -37,6 +37,7 @@
#include linux/reboot.h
#include net/ip.h
+#include asm-powerpc/machdep.h
#include ehea.h
#include ehea_qmr.h
@@ -98,6 +99,7 @@ static int port_name_cnt = 0;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags = 0;
struct work_struct ehea_rereg_mr_task;
+static void (*orig_machine_crash_shutdown)(struct pt_regs *regs);
struct semaphore dlpar_mem_lock;
@@ -3312,6 +3314,29 @@ static struct notifier_block ehea_reboot_nb = {
.notifier_call = ehea_reboot_notifier,
};
+void ehea_crash_notifier(struct pt_regs *regs)
+{
+ ehea_info(Machine crash: freeing all eHEA resources);
+ ibmebus_unregister_driver(ehea_driver);
+ orig_machine_crash_shutdown(regs);
+}
+
+void ehea_register_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ orig_machine_crash_shutdown =
+ (void*)__xchg_u64((unsigned long*)ppc_md.machine_crash_shutd
own,
+ (unsigned long)ehea_crash_notifier);
+#endif
+}
+
+void ehea_unregister_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ ppc_md.machine_crash_shutdown = orig_machine_crash_shutdown;
+#endif
+}
+
static int check_module_parm(void)
{
int ret = 0;
@@ -3369,6 +3394,7 @@ int __init ehea_module_init(void)
goto out;
register_reboot_notifier(ehea_reboot_nb);
+ ehea_register_crash_notifier();
ret = ibmebus_register_driver(ehea_driver);
if (ret) {
@@ -3382,6 +3408,7 @@ int __init ehea_module_init(void)
ehea_error(failed to register capabilities attribute, ret=%d,
ret);
unregister_reboot_notifier(ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ibmebus_unregister_driver(ehea_driver);
goto out;
}
@@ -3396,6 +3423,7 @@ static void __exit ehea_module_exit(void)
driver_remove_file(ehea_driver.driver, driver_attr_capabilities);
ibmebus_unregister_driver(ehea_driver);
unregister_reboot_notifier(ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ehea_destroy_busmap();
}
--
1.5.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
On Fri, 09 Nov 2007 18:12:02 +0100 Marian Balakowicz [EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
+static int __init mpc5200_simple_probe(void)
+{
+ unsigned long node = of_get_flat_dt_root();
You need to include asm/prom.h to use the flattened device tree accessors.
+ /* list of the supported boards */
+ const char *board[] = {
+ tqc,tqm5200,
+ promess,motionpro,
+ schindler,cm5200,
+ NULL
+ };
Make that static.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpMu2Bkhvlxi.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
Scott Wood wrote: Jerry Van Baren wrote: My concern from the u-boot side is that u-boot has to know exactly *where* to put the expanded blob because it has to pass it to linux and keep it out of linux' way so it doesn't get stepped on. Linux has an advantage in that it owns all of memory and can allocate and deallocate whatever and wherever and it won't step on itself (hopefully). Linux is pretty careful not to step on the device tree; it marks the area as reserved, and moves it if it really has to. The only scenario I think would be problematic is if the kernel is started somewhere other than zero, and has to relocate itself, and the relocation clobbers the device tree. That's easily avoided by making sure the device tree is at a higher address than the kernel -- and is really not much different than the old bd_t mechanism, which didn't use a user provided address AFAIK. That is good to know, makes things much easier. I'm assuming your boot wedge has the advantage of being able to use linux's malloc() and thus don't have to worry about coordinating with linux on memory allocation. No, it uses its own malloc. With the current u-boot fdt command, you can resize the blob, and this can be done in a script with all the (somewhat limited) capabilities of the u-boot shell (an adaptation of hush). OK, I'm just going by the behavior of the default boot commands on (at least some of) our boards, which just give you an error if the blob isn't already enlarged. Maybe I should just poke Kim et al. about fixing our default environment -- though I'm guessing it'd still have to know from the script how much to enlarge the blob. Currently it is a manual thing, my point was that it is potentially scriptable (but would probably take a genius or 3 days of experimentation to make the script work ;-). If we can settle on a safe way to expand the blob automatically, I'm all for that. In the u-boot world, we fixate on memory maps and putting things in specific places. I've noticed. :-) -Scott Yeah, I had a ruder term than fixate but changed it for public consumption. ;-) Best regards, gvb ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Appletouch going wild
Benjamin Herrenschmidt [EMAIL PROTECTED] writes: On Fri, 2007-11-09 at 13:58 +0100, Andreas Schwab wrote: Every once in a while the touchpad in my iBook G4 (geyser1, 030B) is going wild, emitting random movement events even when not being touched. That started only with 2.6.24-rc1. The only way to stop it is to reload the appletouch module. My guess would be that reinitializing the touchpad can result in some kind of race condition. I always had that problem if I do something like leaving my finger too long on it... I have definitely never seen it before. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Appletouch going wild
On Fri, 2007-11-09 at 13:58 +0100, Andreas Schwab wrote: Every once in a while the touchpad in my iBook G4 (geyser1, 030B) is going wild, emitting random movement events even when not being touched. That started only with 2.6.24-rc1. The only way to stop it is to reload the appletouch module. My guess would be that reinitializing the touchpad can result in some kind of race condition. Is it the same in -rc2? The bad patch that broke fountains was fixed later, but you do have a geyser. I see random movements once a while too on my fountain touchpad but it's been a long time since I saw that last. My guess would be that the reinit changes the zero levels and therefore the zero levels are wrong, but I don't understand that part of the driver too well. johannes 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 v4 00/13] [POWERPC] Add TQM5200/CM5200/Motion-PRO board support
On 11/9/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/9/07, Marian Balakowicz [EMAIL PROTECTED] wrote: Please review, and if everything is ok schedule for 2.6.24-rc3. Just to be clear, I won't be picking up these changes until the 2.6.25 merge window. The .24 tree is closed for new board support patches and is in bug fix only mode. Ummm; on rereading this (after getting gently nudged on IRC) I realize my reply was both inaccurate and just plain rude. Sorry about that, it was unintentional. Yes, I'll be picking up your patches into my tree fairly soon (before the .25 merge window opens), but I cannot ask Paul to pick it up for 2.6.24 because .24 is only open for bug fixes. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
