RE: Endianness versus too many byte swaps??
Charles Krinke wrote: This routine uses a ccsr_pci struct to assign potar2, powar2, powbar2 and others like this: pci-potar2 = 0x0010; pci-powar2 = 0x8004401a; pci-powbar2 = 0x00888000; This is big-endian access to the registers, right? I tend to prefer explicit macros like the following when accessing CCSR and such. It also adds IO synchronization as a bonus. out_be32(pci-potar2, 0x0010); out_be32(pci-powar2, 0x8004401a); out_be32(pci-powbar2, 0x00888000); Where I have changed the constants for our board. The issue is that when I call readl to read back these same registers at the end of this same subroutine, I get into endianess issues. That is, I read back POTAR2 == 0x1000 POWAR2 == 0x1A400480 POWBAR2 == 0x00800800 Where the four bytes in each 32bit word are now exchanged so that 80_04_40_1A became 1A_40_04_80. I understand big versus little endian, that isn't the question. The question is What is really in the POTAR2, POWAR2 POWBAR2 registers and how can I prove that what is in the registers is really what I wish to be in the registers? You do understand that readl is in fact a call to in_le32() on ppc (cf. include/asm-ppc/io.h). The question now is, what endianness you would like in that register? Regards -- Stephane ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH alternative] lite5200(b) support for i2c
Domen Puncer wrote: Add fsl-i2c to lite5200 i2c nodes in device tree, and enable FSL_SOC. Tested to work with built-in eeprom on lite5200b. Signed-off-by: Domen Puncer [EMAIL PROTECTED] --- This patch obsoletes the previous one, and is shorter too :-) arch/powerpc/Kconfig|1 + arch/powerpc/boot/dts/lite5200.dts |6 -- arch/powerpc/boot/dts/lite5200b.dts |6 -- 3 files changed, 9 insertions(+), 4 deletions(-) Index: grant.git/arch/powerpc/Kconfig === --- grant.git.orig/arch/powerpc/Kconfig +++ grant.git/arch/powerpc/Kconfig @@ -128,6 +128,7 @@ config CLASSIC32 bool 52xx/6xx/7xx/74xx select PPC_FPU select 6xx + select FSL_SOC help There are four families of PowerPC chips supported. The more common types (601, 603, 604, 740, 750, 7400), the Motorola embedded I would put the select FSL_SOC under the PPC_MPC52xx symbol and not the CLASSIC32 one. Otherwise, looks good. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH try3] lite5200(b) support for i2c
Add fsl-i2c to mpc5200 i2c node in device tree, and enable FSL_SOC.
Tested to work with built-in eeprom on lite5200b.
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
D'oh, of course it makes more sense under PPC_MPC52xx.
arch/powerpc/Kconfig|1 +
arch/powerpc/boot/dts/lite5200.dts |6 --
arch/powerpc/boot/dts/lite5200b.dts |6 --
3 files changed, 9 insertions(+), 4 deletions(-)
Index: grant.git/arch/powerpc/Kconfig
===
--- grant.git.orig/arch/powerpc/Kconfig
+++ grant.git/arch/powerpc/Kconfig
@@ -434,6 +434,7 @@ config PPC_CHRP
config PPC_MPC52xx
bool
+ select FSL_SOC
default n
config PPC_MPC5200
Index: grant.git/arch/powerpc/boot/dts/lite5200b.dts
===
--- grant.git.orig/arch/powerpc/boot/dts/lite5200b.dts
+++ grant.git/arch/powerpc/boot/dts/lite5200b.dts
@@ -323,20 +323,22 @@
[EMAIL PROTECTED] {
device_type = i2c;
- compatible = mpc5200b-i2c\0mpc5200-i2c;
+ compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c;
cell-index = 0;
reg = 3d00 40;
interrupts = 2 f 0;
interrupt-parent = 500;
+ fsl5200-clocking;
};
[EMAIL PROTECTED] {
device_type = i2c;
- compatible = mpc5200b-i2c\0mpc5200-i2c;
+ compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c;
cell-index = 1;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = 500;
+ fsl5200-clocking;
};
[EMAIL PROTECTED] {
device_type = sram;
Index: grant.git/arch/powerpc/boot/dts/lite5200.dts
===
--- grant.git.orig/arch/powerpc/boot/dts/lite5200.dts
+++ grant.git/arch/powerpc/boot/dts/lite5200.dts
@@ -318,20 +318,22 @@
[EMAIL PROTECTED] {
device_type = i2c;
- compatible = mpc5200-i2c;
+ compatible = mpc5200-i2c\0fsl-i2c;
cell-index = 0;
reg = 3d00 40;
interrupts = 2 f 0;
interrupt-parent = 500;
+ fsl5200-clocking;
};
[EMAIL PROTECTED] {
device_type = i2c;
- compatible = mpc5200-i2c;
+ compatible = mpc5200-i2c\0fsl-i2c;
cell-index = 1;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = 500;
+ fsl5200-clocking;
};
[EMAIL PROTECTED] {
device_type = sram;
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 0/7] MPC5200 and Lite5200b low power modes
On 03/03/07 08:33 +0100, Domen Puncer wrote:
On 02/03/07 22:35 +0100, Sylvain Munaut wrote:
Hi,
Thanks for providing theses.
I hadn't a chance to test them yet, I'll try that this week end. A
couple of comments already though :
- Is saving the SDMA / PIC registers necessary ? Doesn't the cpu keep
those when at sleep ?
For deep-sleep this is true, but not for low-power mode (the CPU
isn't even powered in that case).
- And if it is, won't a memcpy_io of the whole zone do the trick ?
Oh, nice. I wasn't aware of _memcpy_{to,from}io. I'll try it.
OK, one can't copy the whole zone :-(
Ie. reading from MBAR+0x3B00 seems to freeze Linux.
Currently I'm having something like (obsoletes PIC and SDMA patches):
Index: grant.git/arch/powerpc/platforms/52xx/lite5200_pm.c
===
--- /dev/null
+++ grant.git/arch/powerpc/platforms/52xx/lite5200_pm.c
@@ -0,0 +1,125 @@
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include asm/io.h
+#include asm/mpc52xx.h
+#include mpc52xx_pic.h
+#include bestcomm.h
+
+extern void lite5200_low_power(void *sram, void *mbar);
+extern int mpc52xx_pm_enter(suspend_state_t);
+extern int mpc52xx_pm_prepare(suspend_state_t);
+
+static void __iomem *mbar;
+
+static int lite5200_pm_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ case PM_SUSPEND_MEM:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+static int lite5200_pm_prepare(suspend_state_t state)
+{
+ /* deep sleep? let mpc52xx code handle that */
+ if (state == PM_SUSPEND_STANDBY)
+ return mpc52xx_pm_prepare(state);
+
+ if (state != PM_SUSPEND_MEM)
+ return -EINVAL;
+
+ /* map registers */
+ mbar = ioremap_nocache(0xf000, 0x8000);
+ if (!mbar) {
+ printk(KERN_ERR %s:%i Error mapping registers\n, __func__,
__LINE__);
+ return -ENOSYS;
+ }
+
+ return 0;
+}
+
+/* save and restore registers not bound to any real devices */
+static struct mpc52xx_cdm __iomem *cdm;
+static struct mpc52xx_cdm scdm;
+static struct mpc52xx_intr __iomem *pic;
+static struct mpc52xx_intr spic;
+static struct mpc52xx_sdma __iomem *bes;
+static struct mpc52xx_sdma sbes;
+static struct mpc52xx_xlb __iomem *xlb;
+static struct mpc52xx_xlb sxlb;
+static struct mpc52xx_gpio __iomem *gps;
+static struct mpc52xx_gpio sgps;
+static struct mpc52xx_gpio_wkup __iomem *gpw;
+static struct mpc52xx_gpio_wkup sgpw;
+extern char saved_sram[0x4000];
+
+static void lite5200_save_regs(void)
+{
+ _memcpy_fromio(sbes, bes, sizeof(*bes));
+ _memcpy_fromio(spic, pic, sizeof(*pic));
+ _memcpy_fromio(scdm, cdm, sizeof(*cdm));
+ _memcpy_fromio(sxlb, xlb, sizeof(*xlb));
+ _memcpy_fromio(sgps, gps, sizeof(*gps));
+ _memcpy_fromio(sgpw, gpw, sizeof(*gpw));
+
+ memcpy(saved_sram, sdma.sram, sdma.sram_size);
+}
+
+static void lite5200_restore_regs(void)
+{
+ memcpy(sdma.sram, saved_sram, sdma.sram_size);
+
+ _memcpy_toio(gpw, sgpw, sizeof(*gpw));
+ _memcpy_toio(gps, sgps, sizeof(*gps));
+ _memcpy_toio(xlb, sxlb, sizeof(*xlb));
+ _memcpy_toio(cdm, scdm, sizeof(*cdm));
+ _memcpy_toio(pic, spic, sizeof(*pic));
+ _memcpy_toio(bes, sbes, sizeof(*bes));
+}
+
+static int lite5200_pm_enter(suspend_state_t state)
+{
+ /* deep sleep? let mpc52xx code handle that */
+ if (state == PM_SUSPEND_STANDBY) {
+ return mpc52xx_pm_enter(state);
+ }
+
+ cdm = mbar + 0x200;
+ pic = mbar + 0x500;
+ gps = mbar + 0xb00;
+ gpw = mbar + 0xc00;
+ bes = mbar + 0x1200;
+ xlb = mbar + 0x1f00;
+ lite5200_save_regs();
+
+ lite5200_low_power(sdma.sram, mbar);
+
+ lite5200_restore_regs();
+
+ iounmap(mbar);
+ return 0;
+}
+
+static int lite5200_pm_finish(suspend_state_t state)
+{
+ return 0;
+}
+
+static struct pm_ops lite5200_pm_ops = {
+ .valid = lite5200_pm_valid,
+ .prepare= lite5200_pm_prepare,
+ .enter = lite5200_pm_enter,
+ .finish = lite5200_pm_finish,
+};
+
+static int __init lite5200_pm_init(void)
+{
+ pm_set_ops(lite5200_pm_ops);
+ return 0;
+}
+
+arch_initcall(lite5200_pm_init);
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH try3] lite5200(b) support for i2c
Domen Puncer wrote:
Add fsl-i2c to mpc5200 i2c node in device tree, and enable FSL_SOC.
Tested to work with built-in eeprom on lite5200b.
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Acked-by: Sylvain Munaut [EMAIL PROTECTED]
I'll make sure this is included in my next merge batch to Paul.
Sylvain
---
D'oh, of course it makes more sense under PPC_MPC52xx.
arch/powerpc/Kconfig|1 +
arch/powerpc/boot/dts/lite5200.dts |6 --
arch/powerpc/boot/dts/lite5200b.dts |6 --
3 files changed, 9 insertions(+), 4 deletions(-)
Index: grant.git/arch/powerpc/Kconfig
===
--- grant.git.orig/arch/powerpc/Kconfig
+++ grant.git/arch/powerpc/Kconfig
@@ -434,6 +434,7 @@ config PPC_CHRP
config PPC_MPC52xx
bool
+ select FSL_SOC
default n
config PPC_MPC5200
Index: grant.git/arch/powerpc/boot/dts/lite5200b.dts
===
--- grant.git.orig/arch/powerpc/boot/dts/lite5200b.dts
+++ grant.git/arch/powerpc/boot/dts/lite5200b.dts
@@ -323,20 +323,22 @@
[EMAIL PROTECTED] {
device_type = i2c;
- compatible = mpc5200b-i2c\0mpc5200-i2c;
+ compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c;
cell-index = 0;
reg = 3d00 40;
interrupts = 2 f 0;
interrupt-parent = 500;
+ fsl5200-clocking;
};
[EMAIL PROTECTED] {
device_type = i2c;
- compatible = mpc5200b-i2c\0mpc5200-i2c;
+ compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c;
cell-index = 1;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = 500;
+ fsl5200-clocking;
};
[EMAIL PROTECTED] {
device_type = sram;
Index: grant.git/arch/powerpc/boot/dts/lite5200.dts
===
--- grant.git.orig/arch/powerpc/boot/dts/lite5200.dts
+++ grant.git/arch/powerpc/boot/dts/lite5200.dts
@@ -318,20 +318,22 @@
[EMAIL PROTECTED] {
device_type = i2c;
- compatible = mpc5200-i2c;
+ compatible = mpc5200-i2c\0fsl-i2c;
cell-index = 0;
reg = 3d00 40;
interrupts = 2 f 0;
interrupt-parent = 500;
+ fsl5200-clocking;
};
[EMAIL PROTECTED] {
device_type = i2c;
- compatible = mpc5200-i2c;
+ compatible = mpc5200-i2c\0fsl-i2c;
cell-index = 1;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = 500;
+ fsl5200-clocking;
};
[EMAIL PROTECTED] {
device_type = sram;
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 0/7] MPC5200 and Lite5200b low power modes
Domen Puncer wrote:
On 03/03/07 08:33 +0100, Domen Puncer wrote:
On 02/03/07 22:35 +0100, Sylvain Munaut wrote:
Hi,
Thanks for providing theses.
I hadn't a chance to test them yet, I'll try that this week end. A
couple of comments already though :
- Is saving the SDMA / PIC registers necessary ? Doesn't the cpu keep
those when at sleep ?
For deep-sleep this is true, but not for low-power mode (the CPU
isn't even powered in that case).
- And if it is, won't a memcpy_io of the whole zone do the trick ?
Oh, nice. I wasn't aware of _memcpy_{to,from}io. I'll try it.
OK, one can't copy the whole zone :-(
Ie. reading from MBAR+0x3B00 seems to freeze Linux.
Currently I'm having something like (obsoletes PIC and SDMA patches):
And does that work ?
I was also wondering if some registers don't need to be restored last.
For example,
the task status in sdma would be restored to 0 then just at the end set
to their real value.
Saving / Restoring all theses system zones makes more sense to me than
to just save / restore the pic sdma and hoping than mpc52xx_setup_cpu
will make the rest ...
But saving/restoring all the mbar isn't good either because peripheral
drivers should handle their own setup restore. The suspend / resume
method of the peripheral should differentiate how deep their suspending
/ resuming and do what's necessary accordingly.
Sylvain
Index: grant.git/arch/powerpc/platforms/52xx/lite5200_pm.c
===
--- /dev/null
+++ grant.git/arch/powerpc/platforms/52xx/lite5200_pm.c
@@ -0,0 +1,125 @@
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include asm/io.h
+#include asm/mpc52xx.h
+#include mpc52xx_pic.h
+#include bestcomm.h
+
+extern void lite5200_low_power(void *sram, void *mbar);
+extern int mpc52xx_pm_enter(suspend_state_t);
+extern int mpc52xx_pm_prepare(suspend_state_t);
+
+static void __iomem *mbar;
+
+static int lite5200_pm_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ case PM_SUSPEND_MEM:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+static int lite5200_pm_prepare(suspend_state_t state)
+{
+ /* deep sleep? let mpc52xx code handle that */
+ if (state == PM_SUSPEND_STANDBY)
+ return mpc52xx_pm_prepare(state);
+
+ if (state != PM_SUSPEND_MEM)
+ return -EINVAL;
+
+ /* map registers */
+ mbar = ioremap_nocache(0xf000, 0x8000);
+ if (!mbar) {
+ printk(KERN_ERR %s:%i Error mapping registers\n, __func__,
__LINE__);
+ return -ENOSYS;
+ }
+
+ return 0;
+}
+
+/* save and restore registers not bound to any real devices */
+static struct mpc52xx_cdm __iomem *cdm;
+static struct mpc52xx_cdm scdm;
+static struct mpc52xx_intr __iomem *pic;
+static struct mpc52xx_intr spic;
+static struct mpc52xx_sdma __iomem *bes;
+static struct mpc52xx_sdma sbes;
+static struct mpc52xx_xlb __iomem *xlb;
+static struct mpc52xx_xlb sxlb;
+static struct mpc52xx_gpio __iomem *gps;
+static struct mpc52xx_gpio sgps;
+static struct mpc52xx_gpio_wkup __iomem *gpw;
+static struct mpc52xx_gpio_wkup sgpw;
+extern char saved_sram[0x4000];
+
+static void lite5200_save_regs(void)
+{
+ _memcpy_fromio(sbes, bes, sizeof(*bes));
+ _memcpy_fromio(spic, pic, sizeof(*pic));
+ _memcpy_fromio(scdm, cdm, sizeof(*cdm));
+ _memcpy_fromio(sxlb, xlb, sizeof(*xlb));
+ _memcpy_fromio(sgps, gps, sizeof(*gps));
+ _memcpy_fromio(sgpw, gpw, sizeof(*gpw));
+
+ memcpy(saved_sram, sdma.sram, sdma.sram_size);
+}
+
+static void lite5200_restore_regs(void)
+{
+ memcpy(sdma.sram, saved_sram, sdma.sram_size);
+
+ _memcpy_toio(gpw, sgpw, sizeof(*gpw));
+ _memcpy_toio(gps, sgps, sizeof(*gps));
+ _memcpy_toio(xlb, sxlb, sizeof(*xlb));
+ _memcpy_toio(cdm, scdm, sizeof(*cdm));
+ _memcpy_toio(pic, spic, sizeof(*pic));
+ _memcpy_toio(bes, sbes, sizeof(*bes));
+}
+
+static int lite5200_pm_enter(suspend_state_t state)
+{
+ /* deep sleep? let mpc52xx code handle that */
+ if (state == PM_SUSPEND_STANDBY) {
+ return mpc52xx_pm_enter(state);
+ }
+
+ cdm = mbar + 0x200;
+ pic = mbar + 0x500;
+ gps = mbar + 0xb00;
+ gpw = mbar + 0xc00;
+ bes = mbar + 0x1200;
+ xlb = mbar + 0x1f00;
+ lite5200_save_regs();
+
+ lite5200_low_power(sdma.sram, mbar);
+
+ lite5200_restore_regs();
+
+ iounmap(mbar);
+ return 0;
+}
+
+static int lite5200_pm_finish(suspend_state_t state)
+{
+ return 0;
+}
+
+static struct pm_ops lite5200_pm_ops = {
+ .valid = lite5200_pm_valid,
+ .prepare= lite5200_pm_prepare,
+ .enter = lite5200_pm_enter,
+ .finish = lite5200_pm_finish,
+};
+
+static int __init
Re: Getting the LED light up... (AM Rattler 8250PCI linux 2.6.13-AM)
#define P00x8000 // P0 bit in registers #define P10x4000 // P1 bit in registers #define P20x2000 // P2 bit in registers Shouldn't that be #define P00x8000 // P0 bit in registers #define P10x4000 // P1 bit in registers #define P20x2000 // P2 bit in registers ? shamedHmmm, next time I'll better use my calculator figuring out how many digits there is in a 32bit hex number... :P /shamed Many thanks for the assistance Laurent! (the LED came to life) And you all may have a good long laugh of me now, I deserve it! :) br Robert ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH try3] lite5200(b) support for i2c
On Mar 5, 2007, at 4:53 AM, Sylvain Munaut wrote: Domen Puncer wrote: Add fsl-i2c to mpc5200 i2c node in device tree, and enable FSL_SOC. Tested to work with built-in eeprom on lite5200b. Signed-off-by: Domen Puncer [EMAIL PROTECTED] Acked-by: Sylvain Munaut [EMAIL PROTECTED] I'll make sure this is included in my next merge batch to Paul. Driver patches should go via the driver subsystem maintainers and not Paul. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH try3] lite5200(b) support for i2c
On Mar 5, 2007, at 8:53 AM, Kumar Gala wrote: On Mar 5, 2007, at 4:53 AM, Sylvain Munaut wrote: Domen Puncer wrote: Add fsl-i2c to mpc5200 i2c node in device tree, and enable FSL_SOC. Tested to work with built-in eeprom on lite5200b. Signed-off-by: Domen Puncer [EMAIL PROTECTED] Acked-by: Sylvain Munaut [EMAIL PROTECTED] I'll make sure this is included in my next merge batch to Paul. Driver patches should go via the driver subsystem maintainers and not Paul. Sorry, ignore me. I was looking at Domen's initial patch which touched drivers/i2c/busses/i2c-mpc.c - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Endianness versus too many byte swaps??
You do understand that readl is in fact a call to in_le32() on ppc (cf. include/asm-ppc/io.h). The question now is, what endianness you would like in that register? Regards -- Stephane Dear Stephane: Your point is well made. I can see that readl is in fact a call to in_le32. Maybe there is a more basic problem here. If I change the call to readl to a call to in_be32, things make sense again. So, maybe I don't quite understand the endianness setup of this Linux project. I am told that we are running this ppc in big endian, so would this mean that readl writel should actually be resolving to in_be32/out_be32 respectively? Is there some other setup that may be wrong? Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Endianness versus too many byte swaps??
On Mar 5, 2007, at 9:02 AM, Charles Krinke wrote: You do understand that readl is in fact a call to in_le32() on ppc (cf. include/asm-ppc/io.h). The question now is, what endianness you would like in that register? Regards -- Stephane Dear Stephane: Your point is well made. I can see that readl is in fact a call to in_le32. Maybe there is a more basic problem here. If I change the call to readl to a call to in_be32, things make sense again. So, maybe I don't quite understand the endianness setup of this Linux project. readl/writel are for PCI bus accesses. PCI is inherently little endian. I am told that we are running this ppc in big endian, so would this mean that readl writel should actually be resolving to in_be32/out_be32 respectively? Is there some other setup that may be wrong? Nope, readl/writel are doing the write thing, they will ALWAYS be little endian. You truly want in_be*/out_be* when accessing 85xx CCSR registers since all of them are big endian. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Endianness versus too many byte swaps??
Charles Krinke wrote: [...] I am told that we are running this ppc in big endian, so would this mean that readl writel should actually be resolving to in_be32/out_be32 respectively? Is there some other setup that may be wrong? IIRC, readl and writel were defined this way in order to ease PCI driver portability from x86 PC centric world to big-endian arch's. That's why now I'm always using in_be*/out_be*/in_le*/out_le*, to make things explicit, and let the header files do the swapping if need be. Regards -- Stephane ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Endianness versus too many byte swaps??
Thank you Stephane and Kumar. I think the moral of this story is that the drive logic created by my predecessor that calls readl/writel to read/write ppc registers needs to be changed to call in_be32 outbe32 so I don't continue a mistake. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problems with PHY on STK5200
On Thursday 01 March 2007 19:57, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
I'm trying to compile a recent kernel from DENX linuxppc_2_4_devel for
my STK5200 using ELDK 3.1.1.
It should compile and run fine.
It is compiling fine and it is basically working, but I get lot of receive
errors on the link, making it (almost) unusable for NFS root file system.
If I connect the STK5200 directly to my workstation using a crossover cable,
everything works fine.
It seems that the current kernel there is not configuring the PHY. It
looks like the link is configured for full-duplex (although it should be
configured half-duplex).
What makes you think it should be half duplex only?
The old version (up to and including cc891b92c2540487be1eeba4b5d38c913570d339)
is negotiating half duplex. My linux workstation is also using half duplex if
plugged into the same hub (a D-Link DFE-905DX).
However, I'm not 100% sure that the PHY on STK5200 is operating with
full-duplex, because the link status is not reported by the kernel.
BTW: What is the normal way to reference a commit in a git-repository? I
haven't seen any revision numbers.
You specify the git commit ID.
I hope the number above is a commit-ID...
Can anybody explain what the driver should to? Or even better has some
patch to make it work?
The driver should work :-) And it certainly does for me.
It certainly doesn't work for me ;-(
All least newer versions of the kernel don't register mdio_timer_callback().
So, link up report isn't working.
This is caused by two occurences of the following code in mpc5xxx_fec_setup().
if(!reinit) {
...
if(reinit) {
...
}
...
}
Nevertheless, the MDIO-code is doing something useful. Without CONFIG_USE_MDIO
I don't get a single packet through the network interface (using either hub
or crossover-cable).
I'm willing to do further tests and provide more information. However, I need
some advice on the direction, because I don't understand enough of the code,
yet.
Best regards,
Jan-Hinnerk Dumjahn
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
boot LITE5200B
Hello all, I have a problem to boot a linux image in a Freescale LITE5200B, I compile a Kernel image and a rootfs image with the scripts where I found in the page http://cross-stuff.sourceforge.net/ , the LITE5200B post in the screen: ## Booting image at ff0a ... Image Name: Linux MPC5200 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1298549 Bytes = 1.2 MB Load Address: Entry Point: Uncompressing Kernel Image ... OK id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit setup_arch: enter setup_arch: bootmem arch: exit and my variables are: = printenv baudrate=115200 preboot=echo;echo Type run flash_nfs to mount root filesystem over NFS;echo skipnetcheck=y skippcicheck=y skipidecheck=y verify=n netdev=eth0 nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath) ramargs=setenv bootargs root=/dev/ram rw addip=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):$(netdev):off panic=1 flash_nfs=run nfsargs addip;bootm $(kernel_addr) flash_self=run ramargs addip;bootm $(kernel_addr) $(ramdisk_addr) net_nfs=tftp 20 $(bootfile);run nfsargs addip;bootm rootpath=/opt/eldk/ppc_82xx autoload=no autostart=no ethaddr=00:04:9f:00:5b:46 ethact=FEC ETHERNET mtd_args=setenv bootargs root=8.142.77:10.48.142.152:10.48.142.152:255.255.255.0:::off jff2args=setenv bootargs root=/dev/mtdblock0 rw rootfstype=jffs2 flash_jffs2=run jffs2args kernel_adrr=0xFF0A kernel_addr=0xFF0A hostname=dhcp30-56139 dnsip=10.30.1.2 bootfile=uImage-LITE5200 ipddr=192.168.0.20 filesize=f8 fileaddr=20 gatewayip=192.168.0.1 netmask=255.255.0.0 ipaddr=192.168.0.20 serverip=192.168.0.11 bootdelay=3 bootargs=root=/dev/mtdblock3 ro console=ttyS1 rootfstype=jffs2 bootcmd=bootm 0xFF0A stdin=serial stdout=serial stderr=serial Environment size: 1348/65524 bytes somebody knows that it happens?? Thanks ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: boot LITE5200B
Juan Lopez wrote: Hello all, I have a problem to boot a linux image in a Freescale LITE5200B, I compile a Kernel image What kernel version, what origin ? ... bootargs=root=/dev/mtdblock3 ro console=ttyS1 rootfstype=jffs2 The console = ttyS1 sounds weird ... there is only 1 serial on the lite5200b IIRC For 2.4 that's ttyS0 For 2.6 ttyPSC0 Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Help Melinda with a 2.6 spi driver for mpc875!
Hi,
I attached a driver for the SPI controller of MPC875 that I'm developing. It's
not yet complete, actually, in the mpc8xx_transfer () method simply tries to
transmit 3 bytes (the SPI controller is looped) and thus I expect to receive
the same three bytes. It works sometimes, but not always and I don't know why.
In the init I configure the SPI controller, to do this, I do a ioremap_nocache
of physaddr IMMAP address and then write the relevant registers. I also tried
to put __iomem qualifier to the SPI registers pointers thinking that the writes
to the SPI registers were cached. No success! What could be the problem?
Bye,
Melinda.
-
Everyone is raving about the all-new Yahoo! Mail beta./*
* MPC83xx SPI controller driver.
*
* Maintainer: Kumar Gala
*
* Copyright (C) 2006 Polycom, Inc.
*
* 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.
*/
#include linux/module.h
#include linux/init.h
#include linux/types.h
#include linux/kernel.h
#include linux/completion.h
#include linux/interrupt.h
#include linux/delay.h
#include linux/irq.h
#include linux/dma-mapping.h
#include linux/device.h
#include linux/spi/spi.h
#include linux/spi/spi_bitbang.h
#include linux/platform_device.h
#include linux/fsl_devices.h
#include linux/fs_spi_pd.h
#include asm/irq.h
#include asm/io.h
#include asm/commproc.h
/* MPC8xx SPI Controller mode register definitions are in commproc.h */
#define SPMODE_LEN(x) ((x-1) 4)
#define SPMODE_PM(x) ((x))
#define SPI_MAX_BUFFER_SIZE 32
/*
* Default for SPI Mode:
* SPI MODE 0 (inactive low, phase middle, MSB, 8-bit length, slow clk
*/
#define SPMODE_INIT_VAL (SPMODE_CI | SPMODE_DIV16 | SPMODE_REV | \
SPMODE_MS | SPMODE_LEN(7) | SPMODE_PM(0xf))
/* SPIE/SPIM register values */
#define SPIE_MME 0x20 /* Multimaster error */
#define SPIE_TXE 0x10 /* Tx error */
#define SPIE_BSY 0x04/* No rx buffer available */
#define SPIE_TXB 0x02/* Tx buffer transmitted */
#define SPIE_NF 0x01/* Rx buffer filled */
/* SPCOM values */
#define SPCOM_START 0x80/* Start transmission command */
#ifndef BD_SC_ME
#define BD_SC_ME((ushort)0x0001)/* Multi Master Error */
#endif
/*/
int j = 0;
static u8* rxbuffer;
static u8* txbuffer;
void spi_activate_cs(u8 cs, u8 polarity);
void spi_deactivate_cs(u8 cs, u8 polarity);
static car8xx_t *carp;
static spi_t *spi;
static immap_t *immap;
static cpic8xx_t*cpi;
static cpm8xx_t *cp;
static iop8xx_t *iop;
static cbd_t*tbdf;
static cbd_t*rbdf;
static unsigned short r_tbase, r_rbase;
/* SPI Controller driver's private data. */
struct mpc8xx_spi {
struct completion done;
dma_addr_t scratchbuf;
/* lock to avoid contemporaneous transmission */
spinlock_t lock;
unsigned int count;
u32 irq;
unsigned nsecs; /* (clock cycle time)/2 */
u32 inpclk;
u16 mode; /* spi mode in hardware specific way */
void (*activate_cs) (u8 cs, u8 polarity);
void (*deactivate_cs) (u8 cs, u8 polarity);
};
static
u16 mpc8xx_spi_hwmode(u8 mode, int len, u32 inpclk, u32 speedhz)
{
/* DFBRG is zero */
u16 modehw = SPMODE_MSTR ;
/* setup spi mode */
if (mode SPI_CPOL)
modehw |= SPMODE_CI;
if (mode SPI_CPHA)
modehw |= SPMODE_CP;
if (!(mode SPI_LSB_FIRST))
modehw |= SPMODE_REV;
modehw |= SPMODE_LEN(len);
/* Setting desired speed */
modehw |= SPMODE_PM((u8)((inpclk/speedhz)/4-1));
return modehw;
}
static
int mpc8xx_transmit(u8* tx_buf, u8* rx_buf, int tx_size, int rx_size)
{
int result, i;
// copy data to be sent into the transmit buffer
if (tx_buf)
memcpy((void*)(txbuffer), (void*)tx_buf, tx_size);
// BD data length register
tbdf-cbd_datlen = rbdf-cbd_datlen = tx_size + rx_size;
printk(SPI TX: );
for (i = 0; i tx_size; i++)
printk(%02X , txbuffer[i]);
printk(\n);
// BD status/control register
tbdf-cbd_sc = BD_SC_READY | BD_SC_WRAP | BD_SC_LAST;
rbdf-cbd_sc = BD_SC_EMPTY | BD_SC_WRAP | BD_SC_INTRPT;
cp-cp_spmode = 0x4678; // spi mode setting
cp-cp_spmode |= 0x0100;// enable SPI
cp-cp_spie = 0xff; // clear all spi events
cp-cp_spim = 0x37; // mask all SPI events
udelay(10); // Wait 5 microsecs
cp-cp_spcom = 0x80; // start the transfer
udelay(10);
cp-cp_spmode = 0x00; // reset spi mode
udelay(10); // Wait 10 microsecs
// test receive and transmit buffer descriptor for errors
if
Re: [PATCH 0/7] MPC5200 and Lite5200b low power modes
On 05/03/07 11:58 +0100, Sylvain Munaut wrote:
Domen Puncer wrote:
- And if it is, won't a memcpy_io of the whole zone do the trick ?
Oh, nice. I wasn't aware of _memcpy_{to,from}io. I'll try it.
OK, one can't copy the whole zone :-(
Ie. reading from MBAR+0x3B00 seems to freeze Linux.
Currently I'm having something like (obsoletes PIC and SDMA patches):
And does that work ?
Yes, it does.
I was also wondering if some registers don't need to be restored last.
For example,
the task status in sdma would be restored to 0 then just at the end set
to their real value.
I was wondering about that, but it seems to work as-is.
Any real test cases for which it would matter?
Saving / Restoring all theses system zones makes more sense to me than
to just save / restore the pic sdma and hoping than mpc52xx_setup_cpu
will make the rest ...
But saving/restoring all the mbar isn't good either because peripheral
drivers should handle their own setup restore. The suspend / resume
method of the peripheral should differentiate how deep their suspending
/ resuming and do what's necessary accordingly.
I was aiming for that.
Domen
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Reset cause API
Hello, Is there an API call, either Linux or PowerPC-specific, for determining the cause of the last reset? I can certainly read the RSR myself, but why bother if the information's available elsewhere. thanks, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [patch 1/1] ppc: Possible bug fix for FCC driver
Hi Cedric, For ppc embedded related patches, please also cc: [EMAIL PROTECTED] We use a kernel 2.6.14 on PPC platform (MPC 8555). The FCC driver works To submit a kernel patch upstream, the patch should be against the latest kernel version which is 2.6.21-rc now. well with a 100Mbps link. But it doesn't with a 10Mbps link. To solve it, I modified the GFMR register init: removed TCI bit and set CRC32 bit instead of. I don't know how these bits caused the 10M link issue. Do you have any reasoning? Signed-off-by: Cedric Pontois [EMAIL PROTECTED] - diff -ruN pa-original/arch/ppc/8260_io/fcc_enet.c pa-patched/arch/ppc/8260_io/fcc_enet.c --- pa-original/arch/ppc/8260_io/fcc_enet.c 2007-03-02 14:57:07.000197000 +0100 +++ pa-patched/arch/ppc/8260_io/fcc_enet.c2007-03-02 14:57:08.38000 +0100 @@ -2232,7 +2232,7 @@ /* Set GFMR to enable Ethernet operating mode. */ - fccp-fcc_gfmr = (FCC_GFMR_TCI | FCC_GFMR_MODE_ENET); + fccp-fcc_gfmr = (FCC_GFMR_TCRC_32 | FCC_GFMR_MODE_ENET); /* Set sync/delimiters. */ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
