On Fri, Aug 7, 2015 at 6:22 AM, Peter Hurley pe...@hurleysoftware.com wrote:
I agree; this is what we should do first because someone might want it
for backports.
Got an idea how far this can be ported back?
I'm being hampered by severe performance issues on a
beagleboneblack-like device
is the best among other alternative solutions?
I think the below commit messages is too short and does not explain
this.
OK. I will resubmit this done a different way. The patch I submitted does not
work as generally as it should.
On Thu, 2011-01-06 at 14:39 +1300, Charles Manning wrote
Subpage reading already provides a certain degree of alignment in that it
aligns the reads to 16-bits if the bus is 16-bits wide.
For some situations this is not enough. For eample, the OMAP2 prefetch
engine only works with u32 aligned buffers and read sizes.
This patch set adds a mechanism to
Some nand controllers (eg. omap2) need to have their buffers u32 aligned
to use high speed transfer mechanisms.
This commit provides a way to plug in an alignment function and provides a
32-bit algnment function.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
drivers/mtd/nand
Set align_subpage to align buffer to u32 to use the prefetch engine.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
drivers/mtd/nand/omap2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index cd41c58
arch/arm/mach-omap2/pm24xx.c doesn't compile without CONFIG_SUSPEND
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index aaeea49..ae6abda 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -53,8 +53,8 @@
#include plat/powerdomain.h
#include
On Thursday 23 December 2010 11:22:42 Kevin Hilman wrote:
Charles Manning mannin...@actrix.gen.nz writes:
arch/arm/mach-omap2/pm24xx.c doesn't compile without CONFIG_SUSPEND
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index aaeea49..ae6abda 100644
--- a/arch
Hi All
I've been looking into a ubifs performance regression on linux-omap 2.6.37.
My test is pretty simple, copy a 2Mbyte file and sync.
# sync; date; cp 2Mbyte-file foo; sync; date
On 2.6.32 and earler, the time between the two dates was around 3 seconds.
On linux-omap master it is around
Hello All
I see there is a master and a pm branch. What's the difference? Why would I
use each of these?
Also, when is 32.6.37 expected to be done?
Thanks
Charles
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
Hello All
Over the last while I have been working on getting ubifs working on omap3530
using 16-bit NAND with the latest 2.6.37 prefetch code. This is basically a
tweaked Overo kernel.
Here is what I found:
After initial exploration I found that there were three problem:
* ECC bytes not
On Wednesday 15 December 2010 17:13:42 Charles Manning wrote:
On Thursday 09 December 2010 21:30:48 Luca Ceresoli wrote:
Charles Manning wrote:
Luca, I have been having similar problems on a hacked Overo kernel.
I have no problems with 2.6.35.
I tried just commenting out
On Thursday 09 December 2010 21:30:48 Luca Ceresoli wrote:
Charles Manning wrote:
Luca, I have been having similar problems on a hacked Overo kernel.
I have no problems with 2.6.35.
I tried just commenting out the define and disabling PREFETCH and did not
get a good boot due to ubi
On Tuesday 07 December 2010 23:29:59 Luca Ceresoli wrote:
Luca Ceresoli wrote:
While I thank you for you proposed solution, I see it does not work here.
In fact I commented the #define CONFIG_MTD_NAND_OMAP_HWECC and left
MTD_NAND_OMAP_PREFETCH disabled as it previously was, and got
On Saturday 27 November 2010 06:57:37 Ghorai, Sukumar wrote:
Hello Grazvydas Charles,
Would you please check this series in you setup and please update the
status or any issue you observe?
Hello
It took a while for me to get back to this.
I applied the patches but still no luck running with
On Friday 19 November 2010 03:33:24 Ghorai, Sukumar wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Charles Manning
Sent: Thursday, November 18, 2010 6:36 AM
To: linux-omap@vger.kernel.org
Subject: No more
Between 2.6.35 and 2.6.36 there have need quite a few changes in the NAND
driver, including a change from software to hardware ECC.
The new code has hardware ECC forced on by:
#define CONFIG_MTD_NAND_OMAP_HWECC
I am surprised that this was done. Surely this should have been a Kconfig
option
16 matches
Mail list logo
