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 i
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 n
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
>> attr
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 le16_to_cpu(ent
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 driv
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 dr
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 wrote:
> > > Converting all (ca. 20?) ppc and m68k RTC support code into individual RTC
> > > class drivers would add ca. 1
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 wrote:
> >
> > > > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk()
> > > > [m68k],
> > > > mach_gettod() [m6
On Wed, 25 Feb 2009 11:00:13 +0100 (CET)
Geert Uytterhoeven 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 time to the hardware
rtc ever
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 STAL
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 p
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
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 th
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. Obvious
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 c
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 actuall
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 BD_LEN
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: p.
Signed-off-by: Wolfram Sang
---
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 |3 +-
4 files chang
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 lo
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
>> -
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 d
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 wor
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:
> >
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
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,
alon
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()
Hi Linus !
Please pull a few regression fixes for powerpc.
Cheers,
Ben.
The following changes since commit 169d418b127b98a3e464e9c4b807ad083760f98c:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../tiwai/sound-2.6
are available in the git repository at:
git:
On Thu, Feb 26, 2009 at 3:51 AM, Michael Bergandi 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 LTIB kernel--- fo
35 matches
Mail list logo
