FSL eSDHC controller doesn't have highspeed bit in its host control reg.
And the corresponding bit is used to set up the bus width. So add a
quirk to avoid set this bit. Tested on a mpc8377 RDB board.
Signed-off-by: Kevin Hao
---
drivers/mmc/host/sdhci-of.c |3 ++-
drivers/mmc/host/sdhci.c
From: Grant Likely
Date: Fri, 03 Jul 2009 16:20:19 -0600
> Anton, can you please review, comment and test? I've tested it on an
> mpc8349 board, but that is the only hardware that I have. I've also
> probably made mistakes and it needs to be split up into separate patches,
> but this is probabl
On Mon, 2009-07-06 at 08:59 -0500, Olof Johansson wrote:
> On Mon, Jul 06, 2009 at 12:08:52PM +1000, Michael Ellerman wrote:
> > The workaround enabled by CONFIG_MPIC_BROKEN_REGREAD does not work
> > on non-broken MPICs. The symptom is no interrupts being received.
> >
> > The fix is twofold. Firs
Hi Lada:
Please contact supp...@amcc.com for additional help for the coalescing patch.
Feng Kan
AMCC Software
-Original Message-
From: linuxppc-dev-bounces+fkan=amcc@lists.ozlabs.org on behalf of Lada
Podivin
Sent: Fri 7/3/2009 2:09 AM
To: Cote, Sylvain
Cc: linuxppc-...@ozlabs.org
On Tuesday 07 July 2009 03:51:00 Kári Davíðsson wrote:
> I am doing a driver that uses dma_map_single().
>
> After changing to to linux 2.6.29.3 I am getting
> segfaults in dma_map_single() because dma_ops->map_page is NULL.
> Actually dma_ops looks funky too.
When the 32 and 64bit DMA code was m
On Mon, 2009-07-06 at 17:04 +0200, Bartlomiej Zolnierkiewicz wrote:
> > Delay is fixed itself in 2.6.31-rc2. Most likely it was platform specific
> > issue. But lost interrupt still exists.
> > There is log of 2.6.31-rc2:
>
> Thanks for letting us know. When it comes to the lost interrupt issue
On Mon, Jul 6, 2009 at 3:18 PM, Scott Wood wrote:
> Try omitting the spaces around the equal sign.
AHA! Lesson learned :) thanks Scott! That did it.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-d
Scott Wood wrote:
Mikhail Zaturenskiy wrote:
+ CONFIG_BLK_DEV = y
Hmm, missed this. I'm not sure why the subsequent changes didn't take
effect -- what did the .config look like after sucking in the defconfig
changes, but without any Kconfig changes?
I reverted back all the Kconfig chan
Mikhail Zaturenskiy wrote:
+ CONFIG_BLK_DEV = y
Hmm, missed this. I'm not sure why the subsequent changes didn't take
effect -- what did the .config look like after sucking in the defconfig
changes, but without any Kconfig changes?
I reverted back all the Kconfig changes and made the ch
Mikhail Zaturenskiy wrote:
in arch/powerpc/configs/ep88xc_defconfig:
+ CONFIG_BLK_DEV = y
Hmm, missed this. I'm not sure why the subsequent changes didn't take
effect -- what did the .config look like after sucking in the defconfig
c
Mikhail Zaturenskiy wrote:
After doing this testing I have a side question:
If I modify just arch/powerpc/configs/ep88x_defconfig, not all changes
are reflected in the resulting .config when i do "make
ep88x_defconfig; make uImage". I ended up having to modify
arch/powerpc/Kconfig, arch/powerpc/c
>> After doing this testing I have a side question:
>> If I modify just arch/powerpc/configs/ep88x_defconfig, not all changes
>> are reflected in the resulting .config when i do "make
>> ep88x_defconfig; make uImage". I ended up having to modify
>> arch/powerpc/Kconfig, arch/powerpc/configs/ep88xc_
Mikhail Zaturenskiy wrote:
If you have time, could you bisect to see when the slowdown was introduced?
-Scott
Scott, I tested with kernels 2.6.28, 2.6.29 and 2.6.30 all obtained
from git.kernel.org and configured the same.
So, on my EP88xc board 2.6.28 and 2.6.29 work ok, 2.6.30 has the
slowd
> If you have time, could you bisect to see when the slowdown was introduced?
>
> -Scott
>
Scott, I tested with kernels 2.6.28, 2.6.29 and 2.6.30 all obtained
from git.kernel.org and configured the same.
So, on my EP88xc board 2.6.28 and 2.6.29 work ok, 2.6.30 has the
slowdown issue after loading
I am doing a driver that uses dma_map_single().
After changing to to linux 2.6.29.3 I am getting
segfaults in dma_map_single() because dma_ops->map_page is NULL.
Actually dma_ops looks funky too.
The driver is an of_platform_driver which is declared as an child of
the lbp (fsl,lpb) node of the d
On Thu, Jul 02, 2009 at 03:56:39PM -0600, Aaron Pace wrote:
> Secondly, can you elaborate on how/when the reserved area could be
> mapped into the TLB? I don't by any means lay claim to a complete
> understanding of this area, but aside from a direct ioremap/mmap call,
> how would this area get ma
David Brownell wrote:
> On Friday 26 June 2009, Steven A. Falco wrote:
>> +
>> + /*
>> +* If there are no chip selects at all, or if this is the special
>> +* case of a non-existent (dummy) chip select, do nothing.
>> +*/
>> +
>> + if (!hw->master->num_chipselect
On Sunday 05 July 2009 13:17:54 Andrey Gusev wrote:
> On Wed, 10 Jun 2009 13:44:29 +0200
> Bartlomiej Zolnierkiewicz wrote:
>
> > On Tuesday 09 June 2009 01:26:27 Benjamin Herrenschmidt wrote:
> > > On Mon, 2009-06-08 at 22:20 +0200, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > > > [ 70.584122
Hi Ben,
Please pull the fixes below from the 4xx tree. A few Warp platform updates
that should fix the final issues Sean has reported.
thx,
josh
The following changes since commit fd0cca754f3f6756bfdafe500e4f49b1b9e9723f:
Benjamin Herrenschmidt (1):
Merge commit 'kumar/next' into merg
On Mon, Jul 06, 2009 at 12:08:52PM +1000, Michael Ellerman wrote:
> The workaround enabled by CONFIG_MPIC_BROKEN_REGREAD does not work
> on non-broken MPICs. The symptom is no interrupts being received.
>
> The fix is twofold. Firstly the code was broken for multiple isus,
> we need to index into
Hi,
ok, so I have managed to give it some OF support in a preliminary way(see
patch). But now, I am facing serious problems which I am finding difficult
to tackle. I understand that maybe these problems have to do partially or
entirely to the Xilinx ML403. Let me explain myself: First of all, I d
I have re-ported an application that ran (and worked) on linux kernel 2.6.14
(with Xenomai).
Now it works on linux kernel 2.6.29.4.
When I do tcsetattr to change the baud rate (from 9600 to 38400) the function
returns without an error, but does not actually change the baud rate, and it
remains a
Hook up the alignment-faults and emulation-faults events for powerpc.
Signed-off-by: Anton Blanchard
---
Lots of duplication between PPC_WARN_EMULATED() and perf_swcounter_event()
here. Maybe we need to create PPC_WARN_ALIGNMENT(), use it and hide all
calls to perf_swcounter_event in the macros
On Sun, 2009-06-28 at 08:54 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2009-06-27 at 19:46 +0200, Laszlo Fekete wrote:
> > Hello!
> >
> > Thank you very much, this patch works me too.
> >
> > Maybe this patch will be in the debian kernel someday?
>
> The patch isn't actually correct just yet
24 matches
Mail list logo
