From: "Antonino A. Daplas" <adaplas@gmail.com>
To: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Cc: James Simmons <jsimmons@infradead.org>,
Luca Tettamanti <kronos@people.it>,
linux-fbdev-devel@lists.sourceforge.net,
Andrew Morton <akpm@osdl.org>, Dave Airlie <airlied@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
Date: Sun, 25 Feb 2007 05:16:08 +0800 [thread overview]
Message-ID: <1172351769.4415.5.camel@daplas> (raw)
In-Reply-To: <cb7bb73a0702240116g33a9b5bv2e3668a536a70938@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> > >
> > > The snowy is constant and abundant, and it seems to be independent of
> > > video size (640 through 1600) and screen occupation (single prompt
> > > line to fullscreen mc session) and usage.
> > >
> > > > I presume that X's nv driver or vesafb does not exhibit this problem?
> > >
> > > X's nv gives a very clean display, /unless/ I load nvidiafb before: if
> > > I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
> > > this reason), then the screen is very snowy with X's nv too.
> > >
> >
> > Hmm..., I really don't know how to fix this except to look at Xorg's
> > code and look for a difference.
>
> Keep in mind that setting nvidiafb to totally ignore the EDID (either
> by not compiling in EDID support or by using e.g. the ignoreedid patch
> I had proposed) the snow effect is extremely reduced,
I did not know that, just scanned the entire thread. Try this patch, it
makes use of fb_ddc_read*() which I believe has extra steps to prevent
display corruption. It also incorporates Luca's i2c fix.
Tony
[-- Attachment #2: nvidafb_generic_ddc --]
[-- Type: text/plain, Size: 1948 bytes --]
nvidiafb: Bring back generic ddc reading
Make nvidiafb use fb_ddc_read(). This patch was submitted before but was
reverted due to problems in a non-x86 platform. This includes a fix for that
where ddc reading is bypassed if there is no DDC bus (duh).
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
---
drivers/video/nvidia/nv_i2c.c | 44 ++---------------------------------------
1 files changed, 2 insertions(+), 42 deletions(-)
diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index b858897..b91d404 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -70,8 +70,6 @@ static int nvidia_gpio_getscl(void *data
if (VGA_RD08(par->PCIO, 0x3d5) & 0x04)
val = 1;
- val = VGA_RD08(par->PCIO, 0x3d5);
-
return val;
}
@@ -159,51 +157,13 @@ void nvidia_delete_i2c_busses(struct nvi
}
-static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan *chan)
-{
- u8 start = 0x0;
- struct i2c_msg msgs[] = {
- {
- .addr = 0x50,
- .len = 1,
- .buf = &start,
- }, {
- .addr = 0x50,
- .flags = I2C_M_RD,
- .len = EDID_LENGTH,
- },
- };
- u8 *buf;
-
- if (!chan->par)
- return NULL;
-
- buf = kmalloc(EDID_LENGTH, GFP_KERNEL);
- if (!buf) {
- dev_warn(&chan->par->pci_dev->dev, "Out of memory!\n");
- return NULL;
- }
- msgs[1].buf = buf;
-
- if (i2c_transfer(&chan->adapter, msgs, 2) == 2)
- return buf;
- dev_dbg(&chan->par->pci_dev->dev, "Unable to read EDID block.\n");
- kfree(buf);
- return NULL;
-}
-
int nvidia_probe_i2c_connector(struct fb_info *info, int conn, u8 **out_edid)
{
struct nvidia_par *par = info->par;
u8 *edid = NULL;
- int i;
- for (i = 0; i < 3; i++) {
- /* Do the real work */
- edid = nvidia_do_probe_i2c_edid(&par->chan[conn - 1]);
- if (edid)
- break;
- }
+ if (par->chan[conn - 1].par)
+ edid = fb_ddc_read(&par->chan[conn - 1].adapter);
if (!edid && conn == 1) {
/* try to get from firmware */
next prev parent reply other threads:[~2007-02-24 21:16 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ephv35$4i3$1@sea.gmane.org>
2007-01-29 0:08 ` [PATCH] nvidiafb: allow ignoring EDID info Andrew Morton
2007-01-29 0:12 ` Dave Airlie
2007-01-29 0:27 ` Andrew Morton
2007-01-29 0:29 ` Andrew Morton
2007-01-29 0:39 ` Dave Airlie
2007-01-29 14:37 ` [Linux-fbdev-devel] " Giuseppe Bilotta
2007-01-30 20:33 ` Luca Tettamanti
2007-02-04 20:17 ` [Linux-fbdev-devel] " Luca Tettamanti
2007-02-04 21:17 ` Giuseppe Bilotta
2007-02-05 20:18 ` Luca Tettamanti
2007-02-05 21:28 ` [Linux-fbdev-devel] " Giuseppe Bilotta
2007-02-06 21:22 ` James Simmons
2007-02-07 23:48 ` Luca Tettamanti
2007-02-08 0:19 ` [Linux-fbdev-devel] " Giuseppe Bilotta
2007-02-11 18:17 ` Luca Tettamanti
2007-02-13 9:25 ` [Linux-fbdev-devel] " Giuseppe Bilotta
2007-02-17 18:14 ` Luca Tettamanti
2007-02-17 18:46 ` [Linux-fbdev-devel] " Giuseppe Bilotta
2007-02-08 17:56 ` James Simmons
2007-02-07 23:57 ` Luca Tettamanti
2007-02-06 20:37 ` [Linux-fbdev-devel] " James Simmons
2007-02-06 23:08 ` Giuseppe Bilotta
2007-02-21 23:43 ` Antonino A. Daplas
2007-02-22 8:01 ` [Linux-fbdev-devel] " Giuseppe Bilotta
2007-02-22 8:40 ` Antonino A. Daplas
[not found] ` <cb7bb73a0702220548s55380f7fk995726ffd349823b@mail.gmail.com>
[not found] ` <1172153358.4306.17.camel@daplas>
2007-02-22 15:55 ` [Linux-fbdev-devel] " Giuseppe Bilotta
2007-02-22 16:21 ` Antonino A. Daplas
2007-02-22 19:08 ` [Linux-fbdev-devel] " Giuseppe Bilotta
2007-02-22 23:34 ` Antonino A. Daplas
2007-02-23 13:34 ` Giuseppe Bilotta
2007-02-24 7:04 ` Antonino A. Daplas
2007-02-24 9:16 ` Giuseppe Bilotta
2007-02-24 21:16 ` Antonino A. Daplas [this message]
2007-02-25 10:26 ` Giuseppe Bilotta
2007-02-25 11:10 ` Antonino A. Daplas
2007-02-25 13:16 ` Giuseppe Bilotta
2007-02-26 12:46 ` [Linux-fbdev-devel] " Antonino A. Daplas
2007-02-22 17:03 ` Antonino A. Daplas
2007-02-22 20:39 ` Luca Tettamanti
2007-02-22 23:34 ` Antonino A. Daplas
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=1172351769.4415.5.camel@daplas \
--to=adaplas@gmail.com \
--cc=airlied@gmail.com \
--cc=akpm@osdl.org \
--cc=giuseppe.bilotta@gmail.com \
--cc=jsimmons@infradead.org \
--cc=kronos@people.it \
--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).