mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-kernel@vger.kernel.org, Harald Welte <laforge@gnumonks.org>,
	JosephChan@via.com.tw, ScottFang@viatech.com.cn,
	Deepak Saxena <dsaxena@laptop.org>,
	linux-fbdev-devel@lists.sourceforge.net
Subject: Re: [RFC] Initial OLPC Viafb merge
Date: Fri, 9 Apr 2010 18:27:22 -0600	[thread overview]
Message-ID: <20100409182722.3080bb2d@bike.lwn.net> (raw)
In-Reply-To: <4BBFB914.1020600@gmx.de>

On Sat, 10 Apr 2010 01:32:36 +0200
Florian Tobias Schandinat <FlorianSchandinat@gmx.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.

> It doesn't seem to make much sense to review each of them because the 
> following patches might or might not correct some of the issues of the 
> other. It is really a pain to have 6 patches trying to add a single 
> feature. Is there any way to fix this mess. (I assume you didn't merge 
> them due to authorship issues?)

It's true that one needs to look at the end product.  I only looked at
the S/R code recently, and tried to fix some of the biggest issues that
would keep it out of the mainline.

> I think it might be better to drop those for now and wait for viafb to 
> be in a better shape before adding this feature. The mode setting should 
> be in a pretty good shape just 1 or 2 kernel versions ahead so that the 
> dependency on OFW can be dropped I think.
> 
> Sorry but I really think this is not in a shape where merging it is an 
> option. I think it would be better to skip those suspend/resume patches 
> for the next merge window.

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.

jon

  reply	other threads:[~2010-04-10  0:27 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-08 17:15 Jonathan Corbet
2010-04-08 17:15 ` [PATCH 01/16] [FB] viafb: Fix various resource leaks during module_init() Jonathan Corbet
2010-04-08 18:22   ` Florian Tobias Schandinat
2010-04-09 19:31     ` Jonathan Corbet
2010-04-08 17:15 ` [PATCH 02/16] viafb: use proper pci config API Jonathan Corbet
2010-04-08 18:42   ` Florian Tobias Schandinat
2010-04-09 19:46     ` Jonathan Corbet
2010-04-10  6:41       ` Harald Welte
2010-04-08 17:15 ` [PATCH 03/16] viafb: Unmap the frame buffer on initialization error Jonathan Corbet
2010-04-08 18:55   ` Florian Tobias Schandinat
2010-04-08 17:15 ` [PATCH 04/16] viafb: Retain GEMODE reserved bits Jonathan Corbet
2010-04-09  3:07   ` Florian Tobias Schandinat
2010-04-09 19:59     ` Jonathan Corbet
2010-04-09 20:23       ` Florian Tobias Schandinat
2010-04-09 20:30         ` Jonathan Corbet
2010-04-08 17:15 ` [PATCH 05/16] viafb: Determine type of 2D engine and store it in chip_info Jonathan Corbet
2010-04-09  3:20   ` Florian Tobias Schandinat
2010-04-09 20:11     ` Jonathan Corbet
2010-04-09 20:34       ` Florian Tobias Schandinat
2010-04-18 17:34         ` Jonathan Corbet
2010-04-18 18:00           ` Harald Welte
2010-04-18 18:05           ` Florian Tobias Schandinat
2010-04-08 17:15 ` [PATCH 06/16] viafb: complete support for VX800/VX855 accelerated framebuffer Jonathan Corbet
2010-04-09  4:21   ` Florian Tobias Schandinat
2010-04-09 20:18     ` Jonathan Corbet
2010-04-08 17:15 ` [PATCH 07/16] viafb: Add 1200x900 DCON/LCD panel modes for OLPC XO-1.5 Jonathan Corbet
2010-04-09 21:27   ` Florian Tobias Schandinat
2010-04-18 17:39     ` Jonathan Corbet
2010-04-18 18:24       ` Florian Tobias Schandinat
2010-04-08 17:15 ` [PATCH 08/16] viafb: Do not probe for LVDS/TMDS on " Jonathan Corbet
2010-04-09 21:40   ` Florian Tobias Schandinat
2010-04-10  0:19     ` Jonathan Corbet
2010-04-10  0:42       ` Florian Tobias Schandinat
2010-04-10  0:55         ` Jonathan Corbet
2010-04-10  6:34     ` Harald Welte
2010-04-08 17:15 ` [PATCH 09/16] viafb: rework the I2C support in the VIA framebuffer driver Jonathan Corbet
2010-04-09 22:07   ` Florian Tobias Schandinat
2010-04-08 17:15 ` [PATCH 10/16] suppress verbose debug messages: change printk() to DEBUG_MSG() Jonathan Corbet
2010-04-09 22:09   ` Florian Tobias Schandinat
2010-04-08 17:15 ` [PATCH 11/16] Minimal support for viafb suspend/resume Jonathan Corbet
2010-04-08 17:15 ` [PATCH 12/16] fix register save count, so it matches the restore count Jonathan Corbet
2010-04-08 17:15 ` [PATCH 13/16] VIAFB: Update suspend/resume to selectively restore registers Jonathan Corbet
2010-04-08 17:15 ` [PATCH 14/16] Remove cursor restore hack in viafb Jonathan Corbet
2010-04-08 17:15 ` [PATCH 15/16] viafb: rework suspend/resume Jonathan Corbet
2010-04-08 17:15 ` [PATCH 16/16] viafb: Only suspend/resume on VX855 Jonathan Corbet
2010-04-09  5:43 ` [RFC] Initial OLPC Viafb merge Florian Tobias Schandinat
2010-04-09 18:46   ` Jonathan Corbet
2010-04-09 23:32     ` Florian Tobias Schandinat
2010-04-10  0:27       ` Jonathan Corbet [this message]
2010-04-10  1:02         ` Florian Tobias Schandinat
2010-04-10  8:52           ` Bruno Prémont
2010-04-13  3:03             ` Florian Tobias Schandinat
2010-04-21 20:37               ` Jonathan Corbet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100409182722.3080bb2d@bike.lwn.net \
    --to=corbet@lwn.net \
    --cc=FlorianSchandinat@gmx.de \
    --cc=JosephChan@via.com.tw \
    --cc=ScottFang@viatech.com.cn \
    --cc=dsaxena@laptop.org \
    --cc=laforge@gnumonks.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®