awesome! thx to you and kernel workers! 2011/5/20 Martin Jansa <[email protected]>
> 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] > > _______________________________________________ > Shr-devel mailing list > [email protected] > http://lists.shr-project.org/mailman/listinfo/shr-devel > >
_______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
