problem:
I see sometimes on my mpc5200 based board such printk timing
information:
[0.00] NR_IRQS:512 nr_irqs:512 16
[0.00] MPC52xx PIC is up and running!
[0.00] clocksource: timebase mult[79364d9] shift[22] registered
[0.00] console [ttyPSC0] enabled
[ 130.300633
Eliminate duplicate #include from
sound/soc/fsl/mpc5200_dma.c
Signed-off-by: Jesper Juhl
---
mpc5200_dma.c |1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index dce6b55..f92dca0 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/so
On Mon, 2010-11-22 at 03:01 -0700, Gary Thomas wrote:
> I have a bit more information on this. I'm pretty sure that the failures
> are only happening in my SCSI (SATA actually) code. My board (8347ea) has
> a PCI bus with a SIL SATA controller. This combo works perfectly in 2.6.28.
> In 2.6.32,
On Fri, 19 Nov 2010 16:44:18 +1100
Michael Ellerman wrote:
> On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
> > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman
> > wrote:
> > >
> > > I vote for:
> > >
> > > -> Exception: 401 (Instruction Access) at f7937794
> >
> > Or
Hi Wolfram,
I seem to be mistaken. I retried "compatible=" and it did
all the right
things. I was mistaken that request_module() only takes the driver
name, at24 in this
case, and not all device names in the table_ids.
This pretty much makes my patch redundant. Thanks for helping me clear
things
On Sun, Nov 21, 2010 at 6:05 PM, Michael Ellerman
wrote:
> On Fri, 2010-11-19 at 17:02 +1100, Michael Neuling wrote:
>> > On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
>> > > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman
>> > > > > au> wrote:
>> > > >
>> > > > I vote for:
>> >
This patch enables support for Xilinx Virtex 4 FX singe-float FPU.> This patch
enables support for Xilinx Virtex 4 FX singe-float FPU.
Changelog v3-v4
-Added help for CONFIG_XILINX_SOFTFPU option
-Made kernel math emulation dependent on !PPC_FPU.
Changelog v2-v3:
-Fixed w
On Fri, Nov 19, 2010 at 08:42:46AM -0700, Gary Thomas wrote:
> In this case, note that PCI device :00:0c.0 is at 0xc000.
> This causes problems because it's a truly stupid device that does
> not work properly at PCI [relative] address 0x. It simply
> does not respond at that addres
On 11/21/2010 10:59 AM, Gary Thomas wrote:
On 11/19/2010 02:46 PM, Benjamin Herrenschmidt wrote:
On Fri, 2010-11-19 at 08:42 -0700, Gary Thomas wrote:
In this case, note that PCI device :00:0c.0 is at 0xc000.
This causes problems because it's a truly stupid device that does
not work pro
