On Thu, 2009-02-05 at 22:44 +, David Woodhouse wrote:
On Fri, 2008-11-21 at 18:27 +0100, Joerg Roedel wrote:
On Fri, Nov 21, 2008 at 05:24:29PM +, David Woodhouse wrote:
On Fri, 2008-11-21 at 18:20 +0100, Joerg Roedel wrote:
Ok, I will move the generic bits to lib/ and
Hi all
I am busy porting my board to Linux 2.6.27 from 2.6.19. The old Linux
was compiled using the ppc architecture, and had a platform_device
struct ure containing the custom devices on my board. (
/arch/ppc/platform/sdh8548.c and /arch/ppc/platform/sdh8548.h )
I assume these devices should
Daniel Ng wrote:
Now, I'm seeing these boot messages:
f0010d40:00 not found
eth0: Could not attach to PHY
Daniel,
These messages are typical of having the wrong GPIO pins in the mdio
node or the wrong MDIO address (reg property) in the ethernet-phy node.
Currently, our PHY
attributes eg.
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
Jan Kara wrote:
Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
somehow got beyond end of the page referenced by bh-b_data. So it means
that
On Wed, 25 Feb 2009, David Woodhouse wrote:
On Mon, 2009-02-23 at 13:34 +0100, Geert Uytterhoeven wrote:
my opinion on this kind of stuff is that I want to avoid the layering
of implementations under the rtc subsystem. I'd rather prefer that each
rtc device had its own driver.
On Tue, 24 Feb 2009, Helge Deller wrote:
Geert Uytterhoeven wrote:
I've been looking into problems with auto-loading the RTC driver on PPC
(more
specifically on PS3):
- The recent rtc-ppc RTC class driver is not autoloaded by udev because
it's an old style platform driver that
On Tue, 24 Feb 2009, Brad Boyer wrote:
On Tue, Feb 24, 2009 at 07:37:08PM +0100, Alessandro Zummo wrote:
On Tue, 24 Feb 2009 18:56:03 +0100 (CET)
Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote:
Converting all (ca. 20?) ppc and m68k RTC support code into individual RTC
class
On Wed, 25 Feb 2009, David Woodhouse wrote:
On Tue, 2009-02-24 at 23:11 +0100, Alessandro Zummo wrote:
On Wed, 25 Feb 2009 06:35:27 +0900
David Woodhouse dw...@infradead.org wrote:
So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk()
[m68k],
mach_gettod()
On Wed, 25 Feb 2009 11:00:13 +0100 (CET)
Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote:
I didn't know NTP was broken with RTC class drivers?
So we should actually keep on using genrtc instead of rtc-ppc/rtc-generic for
now? ;-)
broken here means that the kernel won't save the
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Wed, 25 Feb 2009 05:01:59 am Geert Uytterhoeven wrote:
On Mon, 23 Feb 2009, Paul Mackerras wrote:
Andrew Morton writes:
It looks like we died in ext3_xattr_block_get():
memcpy(buffer, bh-b_data +
Mark Nelson wrote:
Hi Sanchin and Geert,
Does the patch below fix the problems you're seeing? If it does I'll send
a properly written up and formatted patch to linuxppc-dev (as well as
another one to fix the same problem in copy_tofrom_user()).
This patch fixes the issue at my side. I tried
Hello,
I am developing a Host Controller Driver for the PPC405EX based board. I
have a OTG controller on it, which I have to configure as Host Controller
and thus I am witting a HCD for the same. I am stuck at the Control stage
wherein although my SETUP stage seems to be going through I get a
On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
Jan Kara wrote:
Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
somehow got beyond end of the page
On Wed, 25 Feb 2009 10:08:22 pm Sachin P. Sant wrote:
Mark Nelson wrote:
Hi Sanchin and Geert,
Does the patch below fix the problems you're seeing? If it does I'll send
a properly written up and formatted patch to linuxppc-dev (as well as
another one to fix the same problem in
On Wednesday 25 February 2009, Adish Kuvelker wrote:
I am developing a Host Controller Driver for the PPC405EX based board. I
have a OTG controller on it, which I have to configure as Host Controller
and thus I am witting a HCD for the same. I am stuck at the Control stage
wherein although my
On Wednesday 25 February 2009, Stefan Roese wrote:
On Wednesday 25 February 2009, Adish Kuvelker wrote:
I am developing a Host Controller Driver for the PPC405EX based board. I
have a OTG controller on it, which I have to configure as Host Controller
and thus I am witting a HCD for the
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
Jan Kara wrote:
Hmm, OK. But then I'm not sure how that can happen. Obviously,
Hi Stefan,
Also in the SETUP stage where I have set my packet size as 1, as I treat
each of this 3 stages (SETUP, DATA and STATUS) as three different
stages/transactions, I find that the Non-Periodic Transmit FIFO/Queue
Status Register read as soon as I write to the Non-Periodic Transmit FIFO
On Feb 24, 2009, at 7:19 PM, Mark Bishop wrote:
I am trying to understand more about how to talk to different spi
chips using the MPC8313. The documentation that comes with the
development board is really lacking and I am relying on the /usr/src/
linux/Documentaion/spi. However, I still
Hi,
we have investigated this problem but didn't understand to root cause of
this problem so far.
The things we observed:
- The warning is only shown when the ehea module is loaded while the
machine is booting.
- If you load the module later (modprobe) no warnings are shown
- Machine never
Hi,
We have a home made board with the mpc8377E.
We use the latest linux kernel 2.6.29-rc6.
The problem occurs when send a lot of tcp packet (eg by iperf as client)
sometimes we get an watchdog timeout : see below.
If we undo the commit :
-#define BD_LENGTH_MASK 0x00ff
+#define
I have two [internal] boards with MPC8347. Both have a PCI
bus, slightly different set of wired peripherals.
On one board, the PCI seems to be working fine. I can talk
to all of my wired devices, plus one in a plugin slot. The
[PCI portion] DTS for this board looks like this:
pci0:
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
arch/powerpc/boot/dts/pcm032.dts | 391 +++
arch/powerpc/configs/52xx/pcm032_defconfig | 1394 ++
arch/powerpc/platforms/52xx/Kconfig |1 +
arch/powerpc/platforms/52xx/mpc5200_simple.c |
Forgot to mention that this goes on top of Grant's 'next'-branch.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
On Wed, 2009-02-25 at 16:05 +0100, Jan-Bernd Themann wrote:
- When open is called for a registered network device, port-port_lock
is taken first,
then ehea_fw_handles.lock
- When open is left these locks are released in a proper way (inverse
order)
So this has:
port-port_lock
Gary Thomas wrote:
I have two [internal] boards with MPC8347. Both have a PCI
bus, slightly different set of wired peripherals.
On one board, the PCI seems to be working fine. I can talk
to all of my wired devices, plus one in a plugin slot. The
[PCI portion] DTS for this board looks
Hi,
yes, sorry for the funny wrapping... and thanks for your quick answer!
Peter Zijlstra wrote:
On Wed, 2009-02-25 at 16:05 +0100, Jan-Bernd Themann wrote:
- When open is called for a registered network device, port-port_lock
is taken first,
then ehea_fw_handles.lock
- When open is
On Wed, 2009-02-25 at 18:07 +0100, Jan-Bernd Themann wrote:
Hi,
yes, sorry for the funny wrapping... and thanks for your quick answer!
Peter Zijlstra wrote:
On Wed, 2009-02-25 at 16:05 +0100, Jan-Bernd Themann wrote:
- When open is called for a registered network device,
Hi all,
I am hoping someone can shed some light on the state of the USB support in
the
2.6.28 kernel for USB OTG on the MPC8313E RDB. The configuration options are
a bit different than the ones from the provided LTIB kernel--- for obvious
reasons---
and I am trying to figure out how to get OTG
On Thu, 26 Feb 2009 12:31:20 am Geert Uytterhoeven wrote:
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
Jan Kara wrote:
Hmm, OK.
On Thu, 26 Feb 2009 09:45:41 am Mark Nelson wrote:
On Thu, 26 Feb 2009 12:31:20 am Geert Uytterhoeven wrote:
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Tue, 24 Feb 2009 05:38:37 pm
This fixes a regression introduced by commit
25d6e2d7c58ddc4a3b614fc5381591c0cfe66556 (powerpc: Update 64bit memcpy()
using CPU_FTR_UNALIGNED_LD_STD).
This commit allowed CPUs that have the CPU_FTR_UNALIGNED_LD_STD CPU
feature bit present to do the memcpy() with unaligned load doubles. But,
along
This fixes a regression introduced by commit
a4e22f02f5b6518c1484faea1f88d81802b9feac (powerpc: Update 64bit
__copy_tofrom_user() using CPU_FTR_UNALIGNED_LD_STD).
The same bug that existed in the 64bit memcpy() also exists here so fix
it here too. The fix is the same as that applied to memcpy()
On Thu, Feb 26, 2009 at 3:51 AM, Michael Bergandi mberga...@gmail.com wrote:
Hi all,
I am hoping someone can shed some light on the state of the USB support in
the
2.6.28 kernel for USB OTG on the MPC8313E RDB. The configuration options are
a bit different than the ones from the provided
34 matches
Mail list logo
