On Fri, 2009-10-09 at 07:14 +0200, Wolfram Sang wrote:
> And while doing this and figuring the pro/cons of those methods, I
> stumbled over this commit:
>
> gpio: pca953x: Get platform_data from OpenFirmware
> (1965d30356c1c65660ba3330927671cfe81acdd5)
Aside from any issues you ha
On Thu, 2009-10-08 at 23:40 -0600, Grant Likely wrote:
> For your future reference, patches that look at the device tree should
> also cc: devicetree-disc...@lists.ozlabs.org so that new bindings can
> be reviewed and common mistakes can be avoided. It is expected that
> new device tree bindings a
Signed-off-by: Nate Case
---
arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 1821 +++
1 files changed, 1821 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/configs/85xx/xes_mpc85xx_defconfig
diff --git a/arch/powerpc/configs/85xx/xes_mpc85xx_defconfig
b
.
Signed-off-by: Nate Case
---
arch/powerpc/boot/wrapper |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 3ac75ae..4db487d 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -225,6 +225,10
Add support for X-ES single-board computers based on the Freescale
MPC85xx processors.
Signed-off-by: Nate Case
---
arch/powerpc/platforms/85xx/Kconfig | 10 +
arch/powerpc/platforms/85xx/Makefile |1 +
arch/powerpc/platforms/85xx/xes_mpc85xx.c | 282
d defconfig for X-ES MPC85xx boards
[4/4] powerpc/bootwrapper: Custom build options for XPedite52xx targets
This shouldn't be too invasive since the bulk of the changes are new
files. This version should address the items brought up by Kumar and
David G
e system clock and not the
RTC. Use "hwclock" for the RTC.
--
Nate Case
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ars
to rely on it. A future patch I suppose?
> Analagous comments for the other device trees.
Thanks again. I'll fix up the other things you and Kumar mentioned and
re-submit today.
--
Nate Case
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
xt branch -- so I was just following your
lead here.
I'll split up the patch as well. It's not obvious where the 4-line boot
wrapper change should go, so I can make that one separate as well unless
you object.
--
Nate Case
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
question to Kumar about my recent
-next submissions being eligible for 2.6.31. Sorry for not paying
closer attention -- I just assumed we weren't even close to the cutoff
time. I didn't even see Kumar's "next" branch until April 30th (around
-rc6..rc7 time I think).
them.
> > +machine_device_initcall(xes_mpc8572, xes_mpc85xx_publish_devices);
> > +machine_device_initcall(xes_mpc8548, xes_mpc85xx_publish_devices);
>
> Do you not need this for xes_mpc8540?
Yes, thanks. I'll fix this and the other things you mentioned and
re-submit. Wi
Some boot loaders may not enable L1 instruction/data cache. Check if
data and instruction caches are enabled, and enable them if needed.
Signed-off-by: Nate Case
---
arch/powerpc/include/asm/reg_booke.h |2 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 49
On Mon, 2009-06-08 at 17:52 -0500, Kumar Gala wrote:
> > +static void xes_mpc85xx_configure_l1(void)
> > +{
[snip]
>
> I'd prefer we move this into __setup_cpu_e500v1/__setup_cpu_e500v2 so
> its done for all processors regardless of platform.
How does something like this look? Let me know and
MPC85xx platforms do support 4 ethernet ports, so make sure the boot
wrapper fixes up all of them in the fdt.
Signed-off-by: Nate Case
---
arch/powerpc/boot/cuboot-85xx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/cuboot-85xx.c b/arch/powerpc
trip mkimage
default: mkimage
---[snip]---
Then just run 'make -f Makefile.mkimage' from within tools/. Of course
this uses some nasty tricks that will only work on i386 host. I don't
think I'm the first person to have this need, so others here may have
better solutions.
--
Nate Case &l
latform_data for a specific I2C chip based on a
device tree node -- similarly to how we register the I2C devices
already. Is anyone working on this? Did anyone have anything else in
mind?
--
Nate Case <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
r the TFTP boot
case, but that wasn't the case fortunately).
Thanks for the patch!
--
Nate Case <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
t benefit from the speed boosts in your MPC8572
GPIO driver (without explicitly calling mpc8572_gpio_lock and
_mpc8572_gpio_set, etc). Is that correct? In any case, I appreciate
what you did with your driver, so please don't give up on getting some
of you
o the PHY (note that this does not affect the link speed
on the external side of the external PHY).
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
I'm submitting this to linuxppc-dev and netdev, though I'm not sure
which tree it should go through. It touches network driver code
an
On Fri, 2008-10-17 at 09:02 -0500, Nate Case wrote:
> > With this patch it compiles and boots fine.
> > The option -mabi=no-spe is not required.
>
> Please don't accept this patch yet. My past testing showed that
> "-mabi=no-spe" was required for my toolcha
#x27;ll go back and double
check though.
- Nate Case <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
-spe -mabi=no-spe", the results will differ. In the case of the
kernel, you'll get a bunch of "SPE used in kernel" messages with the
"-mno-spe -mabi=spe" combination.
- Nate Case <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Tue, 2008-10-14 at 14:25 -0500, Nate Case wrote:
>
> -mno-spe: Deprecated way to say "no SPE instructions"
> -mspe=no: New way to do -mno-spe
Sorry, I got this backwards (as Kumar pointed out in his other reply).
-mspe=no is actually deprecated.
- Nate Cas
e=no: New way to do -mno-spe
-mabi=no-spe: Disable SPE ABI
Some compilers may enable "-mabi=spe" and/or "-mspe=yes" by default, so
explicitly disabling both is necessary. I recently built a SPE
toolchain which enabled both by default, so I ran into the "SPE u
lkenny <[EMAIL PROTECTED]>
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
drivers/edac/mpc85xx_edac.c | 28 +++-
1 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..63bdc47 10
lf I was wrong when I saw fsl,85xx in so many other places :)
Thanks for the feedback. I'll correct these and re-submit.
--
Nate Case <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
lkenny <[EMAIL PROTECTED]>
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
drivers/edac/mpc85xx_edac.c | 34 +++---
1 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..06
/'master' purely 2.6.28 material currently while 'merge'
is for whatever the next target release is (currently 2.6.27)?
I couldn't find this explained officially anywhere, so I thought I'd
ask. Maybe it'd shed some light for other people too.
--
Nate Case
> drivers/net/gianfar.h |2 ++
> 2 files changed, 20 insertions(+), 4 deletions(-)
This looks good to me.
--
Nate Case <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
in
a workqueue conditionally if in interrupt context? Between these two
I'd lean toward the latter.
Does anyone have any better ideas?
--
Nate Case <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
perty which would set
cdev.default_trigger in the same manner? It would be useful for boards
to be able to specify this in the device tree (e.g., if a certain LED is
meant to be used as a "heartbeat").
--
Nate Case <[EMAIL PROTECTED]>
__
On Wed, 2008-07-02 at 17:53 -0500, Nate Case wrote:
> I'm looking at gfar_configure_serdes() and I'm at a loss as to why
> this
> is always called when the MAC is in SGMII mode. It looks like it
> assumes the use of TBI for some reason. On my board it's just a
>
no TBI
involved.
I'm guessing this is a case of the driver making incorrect assumptions
based on the existing Freescale boards. Or am I missing something
here?
--
Nate Case <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozl
fault values.
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
This version addresses feedback from Sebastian Siewior and
Olof Johansson. Specifically, a new flag was added for ISP1761 which
is set during probe time. This is used instead of checking the Chip
ID register (which doesn
fault values.
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
drivers/usb/host/isp1760-hcd.c | 68 +++
drivers/usb/host/isp1760-hcd.h | 19 ++-
drivers/usb/host/isp1760-if.c | 34 +++-
3 files changed, 103 insertions(+), 1
This fixes the bogus "io mem 0x" message printed
during driver init due to hcd->rsrc_start being assigned after
the call to usb_add_hcd().
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
drivers/usb/host/isp1760-hcd.c |8
1 files changed, 4 inserti
the same for you with
these patches applied. However, I only have an ISP1761 to test with so
I'd appreciate it if you could test with your board.
I'm CCing linuxppc-dev in case there's any feedback on the OF device
tree property usage in patch 2/2.
--
Nate Case &l
Calls to copy_to_user() or copy_from_user() can fail
when copying N bytes, where N is a constant less than 8,
but not 1, 2, 4, or 8.
Signed-off-by: Dave Scidmore <[EMAIL PROTECTED]>
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
include/asm-powerpc/uaccess.h |4 ++--
1 file
works fine without the patch of course. If legacy I/O
port addresses are not permitted in device trees this way and we don't
want to support it, then you can ignore my patch. However, it does seem
a little strange to me that __of_address_to_resource() assumes anything
with IORESOURCE_IO is a PCI device.
- Nate Case <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
This printk() appears twice in the same function. Only the latter one
in the inval_range: section appears to be legitimate.
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/kernel/isa-bridge.c b/arch/powerpc/kernel/isa-bridge.c
index ee172aa..e35092e 100644
---
board that accesses
the IPMI controller via the legacy I/O region.
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/prom_parse.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse
41 matches
Mail list logo
