For those who are not on [email protected] ML. This is fantastic news, More patches upstream :) Improved MMC performance :) GSM_N will allow us to fix GPRS on gta02 easier :) OE build is already prepared, if tests went ok I'll push it to http://build.shr-project.org/shr-kernels/ later today
----- Forwarded message from Lars-Peter Clausen <[email protected]> ----- Date: Thu, 19 May 2011 21:50:27 -0700 From: Lars-Peter Clausen <[email protected]> To: ML Openmoko-kernel <[email protected]> Subject: 2.6.39 for the Freerunner Hi I've just pushed the 2.6.39 branches for the gta02 to the openmoko git server. http://git.openmoko.org/?p=kernel.git;a=summary So, whats new in this release? 1) Upstream merges The bq27x00 and wm8753 branches have been merged upstream. Additional above half of the patches from the gta02-machine branch have been merged, adding button and touchscreen support as well as some minor cleanups. Unfortunately merging patches upstream has come to a halt for now, since ARM has stopped accepting patches which add new platform code.[1] To get things in motion again, we would have to add device-tree support for the s3c24xx platform and to our device drivers. [1] http://lwn.net/Articles/437162/ 2) Improved MMC performance Per Forlin has posted a patch series to the linux mmc mailinglist[2], which allows to have two MMC read or write requests pending at the same time. Previously it was only possible to have one request pending at a time. Having two requests pending at the same time allows us to improve upon the MMC read/write performance on the Freerunner. I've added these patches to the Glamo branch and adjusted the glamo driver to make use of this new feature. Some basic background on how it works: The MMC card on the Freerunner is controlled by the Glamo chip, which has its own RAM. So when data is read from the MMC card, it is first written to the Glamo RAM and then, when the request is done, copied by the CPU to the main RAM. So while the CPU copies data from the Glamo, the Glamo MMC core is idle and while the Glamo reads data from the MMC card the CPU is idle. But if there are two requests active at the same time, one request can read from the MMC card to the Glamo RAM and the other can copy from the Glamo RAM to the main RAM. Thus improving the overall throughput. Previously reading data from the MMC look like this: [MMC->Glamo #1] [Glamo->RAM #1] [MMC->Glamo #2] [Glamo->RAM #2] ... With the new patchset it looks like this: [MMC->Glamo #1] [MMC->Glamo #2] [MMC->Glamo #3] [Glamo->RAM #1] [Glamo->RAM #2] [Glamo->RAM #3] I've done some very basic benchmarking, dd'ing data from and to the raw MMC block device: Raw-Read performance Old New 8MHz: 2.2 MB/s 3.5 MB/s +59% 16Mhz: 3.1 MB/s 4.6 MB/s +48% 25Mhz: 3.7 MB/s 4.5 MB/s +21% Raw-Write performance Old New 8MHz: 2.6 MB/s 3.4 MB/s +30% 16Mhz: 3.8 MB/s 5.0 MB/s +31% 25Mhz: 4.5 MB/s 6.1 MB/s +35% [2] https://lkml.org/lkml/2011/5/7/139 - Lars ----- End forwarded message ----- -- Martin 'JaMa' Jansa jabber: [email protected]
pgpdnq3kOycfw.pgp
Description: PGP signature
_______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
