linux-kernel - Re: [RFC] Initial OLPC Viafb merge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20100421143721.36f62d4d@bike.lwn.net>
Date:	Wed, 21 Apr 2010 14:37:21 -0600
From:	Jonathan Corbet <corbet@....net>
To:	Florian Tobias Schandinat <FlorianSchandinat@....de>
Cc:	Bruno Prémont <bonbons@...ux-vserver.org>,
	linux-kernel@...r.kernel.org, Harald Welte <laforge@...monks.org>,
	JosephChan@....com.tw, ScottFang@...tech.com.cn,
	Deepak Saxena <dsaxena@...top.org>
Subject: Re: [RFC] Initial OLPC Viafb merge

[Trying to get caught up again ... ]

On Tue, 13 Apr 2010 05:03:33 +0200
Florian Tobias Schandinat <FlorianSchandinat@....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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/