lkml.org 
[lkml]   [2010]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Initial OLPC Viafb merge
[Trying to get caught up again ... ]

On Tue, 13 Apr 2010 05:03:33 +0200
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:

> Good news! After some hours of hacking, damaging a filesystem and nearly
> smashing my SD card I've found a promising way to implement suspend and
> resume in viafb based on the first patch of this series. I think this is
> something that can be done for the next merge window.

This all sounds good.

> I'll start a clean
> implementation after Jon sent an updated patch series (including the
> initial s&r implementation)

I'd missed that on my previous reading. Do you want me to post a new
S/R version over the latest patch set?

> However:
> - suspending is very slow, looks like it takes double the time compared
> to before s&r support was added to viafb (this is also with only the
> original patch)

You mean, double the time without actually dealing with the frame
buffer? I'm a little confused there.

> - does not restore some values in the mmio but reinitializes it instead.
> Do you need any special values restored, Jon?

Code using MMIO (the camera in particular) definitely needs stuff
done; the OLPC code can currently suspend and resume with the camera
streaming and it all works.

What I'd done was to move core S/R into via-core.c (which you've not
yet seen, but which I hope to get posted tomorrow) and give subdevices
a hook so they can be called for S/R events. That lets each subdev
ensure that its own needs are met.

Now, I'd been expecting to strip that out on the assumption that the
current S/R code wasn't going to make it upstream. I could change
plans, though, if that's helpful.

> > When I get time to, I will give these patches a try. A central GIT tree
> > where all viafb patches get collected would definitely be nice (even with
> > multiple semi-throw-away "topic" branches).
>
> Yes, I guess that would be a good idea at least now where 2 people are
> actively working on viafb. I have also a few minor patches ready I'll
> send in a few days (after having repaired my development environment).

As a starting point, I've set up:

git://git.lwn.net/linux-2.6.git viafb-next

That's for patches aimed at linux-next. It contains the last series I
sent out, plus one embarrassing compilation fix. Once I have other
stuff ready for review (soon!), I'll stick it into a different branch.

Incidentally, the "olpc-2.6.31-cam" branch there has the full set of
code as used by OLPC now. That branch reflects a lot history of
figuring out how this hardware actually works (sometimes it looks
vaguely like what's in the datasheet, but I think that's coincidental);
some real cleanup needs to happen on the way to the mainline.

Thanks,

jon


\
 
 \ /
  Last update: 2010-04-21 22:39    [W:0.074 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site