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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Apr 2010 10:52:41 +0200
From:	Bruno Prémont <bonbons@...ux-vserver.org>
To:	Florian Tobias Schandinat <FlorianSchandinat@....de>
Cc:	Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
	Harald Welte <laforge@...monks.org>, JosephChan@....com.tw,
	ScottFang@...tech.com.cn, Deepak Saxena <dsaxena@...top.org>,
	linux-fbdev-devel@...ts.sourceforge.net
Subject: Re: [RFC] Initial OLPC Viafb merge

On Sat, 10 April 2010 Florian Tobias Schandinat <FlorianSchandinat@....de> wrote:
> Jonathan Corbet schrieb:
> > On Sat, 10 Apr 2010 01:32:36 +0200
> > Florian Tobias Schandinat <FlorianSchandinat@....de> wrote:
> > 
> >> Please correct me if I am wrong but the remaining 6 patches concerning 
> >> suspend&resume look like a real big FIXME. So at the end it is expected 
> >> to work only on VX855 and needs something called OFW?
> > 
> > OFW = OpenFirmware.  You could say BIOS instead.  It's pretty normal to
> > expect the BIOS to put things into a semi-rational state at resume time.
> 
> So its more or less the same I always do for testing the module.
> 
> > Well, if we want to keep s/r out of tree, we can do that.  It will
> > complicate the merge of the other stuff, since it's got hooks into the
> > GPIO and camera code too.  But, like everything else I've posted so
> > far, it's not the work that I personally set out to do.  I can push
> > that work on others :)
> > 
> > That said, the suspend/resume support in this patch set makes suspend
> > work on one chipset, and probably comes pretty close on the others
> > without breaking anything there.  I don't see the harm in merging it;
> > it makes the code better than it is now.  I would rather not have to
> > separate it out from the rest.  But I'll not fight over this one; if
> > there's real opposition then we can force OLPC to continue to carry it
> > out of tree.
> 
> At least I'd like some more time (multiple weeks) to have a look at this 
> issue & patches and try to come up with improvements that make it likely 
> work on other IGPs and eventually not needing any BIOS/OFW. I agree its 
> already an improvement but certainly one of the kind I like less as VIA 
> could come up with such "improvements" too. IMHO it's a bad thing to 
> push one chipset first if the target is to support all equally well (as 
> long as the hardware permits).
> So I'd be glad if you could go on with the patches that are less painful 
> and get them ready for the merge window (as I really don't have a clue 
> how long it will take me to get the suspend/resume stuff to a state I 
> consider acceptable). Perhaps we should make suspend and resume a 
> configure option and mark it as experimental?

In my case (Commell LE 365) the BIOS offers an option to restore graphics
to text mode on resume so the manual call of 'fbset -a $MODE' works
pretty well, only the acceleration has issues.
I don't remember if accel can get revived with vanilla 2.6.34-rc2 if it
was disabled before suspend.

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).

Thanks,
Bruno
--
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/