linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-kernel@vger.kernel.org, Harald Welte <laforge@gnumonks.org>,
	Deepak Saxena <dsaxena@laptop.org>,
	linux-fbdev@vger.kernel.org, JosephChan@via.com.tw,
	ScottFang@viatech.com.cn
Subject: Re: [PATCH 10/11] viafb: rework the I2C support in the VIA framebuffer driver
Date: Sat, 24 Apr 2010 00:40:39 +0200	[thread overview]
Message-ID: <4BD221E7.7060705@gmx.de> (raw)
In-Reply-To: <20100423155725.7d3b2d2d@bike.lwn.net>

Jonathan Corbet schrieb:
> On Fri, 23 Apr 2010 23:12:54 +0200
> Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
> 
>> 1. while the module loads the screen shows some strange colours. The 
>> colours itself do not worry me but it probably at least means that the 
>> module load time was increased significantly (2-3 seconds, I guess)
>>
>> 2. most annoyingly after this patch I can no longer get a working VGA 
>> console after unbinding the module. Normally I just do:
> 
> Hmm...compiling the driver as a module is not really something that
> makes sense on the OLPC platform, so I've never done it.
> 
> #1 is weird, there should be nothing there that slows initialization
> down.  Putting in some prints and looking at the timing would be most
> helpful here.

Actually that is probably a mistake on my side. I had the impression 
that it was much longer but didn't take into account that the old 
behaviour allowed the VGA console to work until viafb was completly 
loaded and fbcon took over while the new one immediately destroys the 
screen and shows random things until it is completely loaded. However 
the time between hitting enter for the module load command and getting a 
working fbcon really is at least nearly the same.

> As for #2, I can certainly say that I've never unloaded this code, so
> that's an untested path.  I'll have a look and see if I can see
> anything obvious.

Well as for the behaviour change described above I think the problem 
might be in the load path. At least when I faked an exit as when memory 
size detection or ioremapping fails (which is a very common issue that 
really needs a workaround) I get the same unusable VGA console. This 
needs to be fixed.
This whole I2C stuff seems incredibly unstable I even have indicators 
that the current code might be to blame for freezing the machine on some 
configurations with P4M900 IGP. I just try to prevent it to get even 
worse...


Thanks,

Florian Tobias Schandinat

  reply	other threads:[~2010-04-23 22:40 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-18 18:21 [RFC] Initial OLPC Viafb merge (V2) Jonathan Corbet
2010-04-18 18:21 ` [PATCH 01/11] [FB] viafb: Fix various resource leaks during module_init() Jonathan Corbet
2010-04-18 18:21 ` [PATCH 02/11] viafb: use proper pci config API Jonathan Corbet
2010-04-18 18:21 ` [PATCH 03/11] viafb: Unmap the frame buffer on initialization error Jonathan Corbet
2010-04-18 18:21 ` [PATCH 04/11] viafb: Retain GEMODE reserved bits Jonathan Corbet
2010-04-18 18:21 ` [PATCH 05/11] viafb: Unify duplicated set_bpp() code Jonathan Corbet
2010-04-18 18:21 ` [PATCH 06/11] viafb: Determine type of 2D engine and store it in chip_info Jonathan Corbet
2010-04-18 18:21 ` [PATCH 07/11] viafb: complete support for VX800/VX855 accelerated framebuffer Jonathan Corbet
2010-04-18 18:21 ` [PATCH 08/11] viafb: Add 1200x900 DCON/LCD panel modes for OLPC XO-1.5 Jonathan Corbet
2010-04-18 18:21 ` [PATCH 09/11] viafb: Do not probe for LVDS/TMDS on " Jonathan Corbet
2010-04-23 20:56   ` Florian Tobias Schandinat
2010-04-23 21:09     ` Jonathan Corbet
2010-04-18 18:21 ` [PATCH 10/11] viafb: rework the I2C support in the VIA framebuffer driver Jonathan Corbet
2010-04-23 21:12   ` Florian Tobias Schandinat
2010-04-23 21:57     ` Jonathan Corbet
2010-04-23 22:40       ` Florian Tobias Schandinat [this message]
2010-04-23 22:52         ` Jonathan Corbet
2010-04-23 23:21           ` Florian Tobias Schandinat
2010-04-24 10:47             ` Florian Tobias Schandinat
2010-04-24 13:33               ` Jonathan Corbet
2010-04-24 13:53                 ` Harald Welte
2010-04-25 14:38                   ` Jonathan Corbet
2010-04-25 15:56                     ` Florian Tobias Schandinat
2010-04-26 19:40                       ` Jonathan Corbet
2010-04-18 18:21 ` [PATCH 11/11] suppress verbose debug messages: change printk() to DEBUG_MSG() 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=4BD221E7.7060705@gmx.de \
    --to=florianschandinat@gmx.de \
    --cc=JosephChan@via.com.tw \
    --cc=ScottFang@viatech.com.cn \
    --cc=corbet@lwn.net \
    --cc=dsaxena@laptop.org \
    --cc=laforge@gnumonks.org \
    --cc=linux-fbdev@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).