considering the switch to 2.6.24

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> Andy Green wrote:
>> So the status of 2.6.24-random-upstream-git for our usage is looking
>> pretty decent right now.
> 
> That's wonderful news, thanks ! So I'll keep the new features I've
> recently merged into our 2.6.22 tree in separate patches, to make
> it easier to spot what needs applying to 2.6.24 once we switch.

Great, although I should be able to track it with a little effort either
way.

> Do you have any things that you'd want to get done before we switch,
> or is it basically "as soon as the rest of us is ready" for you ?

We need to do what we are doing on NOR / U-Boot / other partitions I
think at the same time.  The current idea I see for NOR is a 256KB
U-Boot partition in there and an uncommitted 1.75MB partition, we need
to get agreement on what the plan is if people think differently and try
to get it that the first 2.6.24 release supports the "new" partitioning
from the start.

>> The JFFS2 mount time was about the same.
> 
> JFFS2 looks at ever block of the file system for data. So mount time
> is O(partition size), not O(data in use) :-(

Well, at least we take the full hit and it doesn't get 5 times worse
when you fill the filesystem from 20% -> 100% :-)  In this case though
- -- separating the rootfs into two partitions as I suggested before will
definitely cut the initial JFFS2 mount time to 20% of the current time?

>> Clearly we burn a lot of time scrolling that framebuffer at the moment.
> 
> Ah, doing GPU-local copies may be an interesting area for improvements
> then. By the way, Dodji reported that we got a bit of a performance
> boost for Xglamo "for free" (*) yesterday, by letting it have some more
> memory (now 4MB, instead of 640*480*2), so that it can store off-screen
> pixmaps in the frame buffer.
> 
> (*) This came as a side-effect of cleaning up allocations for RandR.

Coolness!  Definitely anything that doesn't have to go through the weedy
16-bit bus on the Glamo over and over is going to be a nice win.  Note
though that the Glamo SD patches mess with that same code -- I have to
reserve a 64K block for shared memory with the SD state machine, but
we'll figure it out.

For end users we don't show them the kernel boot, it won't be an issue
anyway, it was just a pleasant surprise for me that we have a little
secret boot speedup hidden away.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHhgbMOjLpvpq7dMoRAt9UAJ9B+ggWPrw+i6qyYuNFUKF73PbHlACff5+n
3tKrL2G7TAt91C0S5DJhklQ=
=sJXE
-----END PGP SIGNATURE-----