From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Jonathan Corbet <corbet@lwn.net>
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: [PATCH 07/16] viafb: Add 1200x900 DCON/LCD panel modes for OLPC XO-1.5
Date: Sun, 18 Apr 2010 20:24:36 +0200 [thread overview]
Message-ID: <4BCB4E64.4000407@gmx.de> (raw)
In-Reply-To: <20100418113930.1ba08ee3@bike.lwn.net>
Jonathan Corbet schrieb:
> On Fri, 09 Apr 2010 23:27:30 +0200
> Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
>
>> What will happen if someone with no VX855 will try to enter 1200x900
>> mode? Probably the world won't be destroyed but I have a really ugly
>> feeling that the driver is not well prepared for this situation.
>
> OK, I'm certainly exposing my relative lack of understanding of
> framebuffer issues (I'm here to add a camera driver, remember? :),
Well I wasn't a graphics guy and just wanted a working display driver.
> but...is this really something that older chipsets can't handle? Or is
> it just that nobody has had that size of panel before?
It's not the chipsets that are incapable (AFAIK) it's just that the
patch is only adding the right PLL values for frequency generation for
VX855 and set the values for all other chipsets to 0. Yeah that means
this panel size wasn't supported before (by the driver). 0 is certainly
not what we want and I think about replacing this whole fixed table with
the formulas used in VIAs OpenSource X driver (although those are a bit
more complicated I expected when I looked at unichrome). However this
will certainly be a big change that needs a lot of thought and testing
so nothing that will happen very soon.
I am just worried what will happen if one tries to set this mode with an
older chipset. I'm pretty sure that it won't work and won't fail gracefully.
>> Haven't
>> tested yet as I'm waiting for the official forward port but I think it
>> might be better to reschedule this patch for later or add some PLL
>> values that are supposed to work (using/executing the formulas in the
>> VIA open source X driver)
>
> If it's really not acceptable, then it will stay out, but I would
> rather get it merged. I will leave it in the series for now; it can
> come out later if need be.
Yeah please leave it in the series for now. I'd just appreciate it very
much if one were to generate the missing values before this gets into
mainline....or replacing this hardcoded values.
Thanks,
Florian Tobias Schandinat
next prev parent reply other threads:[~2010-04-18 18:24 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-08 17:15 [RFC] Initial OLPC Viafb merge 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 [this message]
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
2010-04-10 1:02 ` Florian Tobias Schandinat
2010-04-10 8:52 ` Bruno Prémont
2010-04-13 3:03 ` Florian Tobias Schandinat
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=4BCB4E64.4000407@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-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;
as well as URLs for NNTP newsgroup(s).