* [PATCH] radeonfb: DDC i2c fix
@ 2005-03-11 5:46 Benjamin Herrenschmidt
2005-03-11 20:13 ` Kronos
0 siblings, 1 reply; 4+ messages in thread
From: Benjamin Herrenschmidt @ 2005-03-11 5:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Fbdev development list
Hi !
The radeonfb code for DDC probing (like it's X.org counterpart) uses to
leave the DDC clock & data lines asserted after the probing is complete.
This causes problems with some Apple monitors like the new Cinema HD
23", who will turn themselves off when that happens. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/drivers/video/aty/radeon_i2c.c
===================================================================
--- linux-work.orig/drivers/video/aty/radeon_i2c.c 2005-01-24 17:09:44.000000000 +1100
+++ linux-work/drivers/video/aty/radeon_i2c.c 2005-03-04 17:26:42.000000000 +1100
@@ -236,6 +236,12 @@
if (edid)
break;
}
+ /* Release the DDC lines when done or the Apple Cinema HD display
+ * will switch off
+ */
+ OUTREG(reg, INREG(reg) & ~(VGA_DDC_CLK_OUT_EN | VGA_DDC_DATA_OUT_EN));
+ (void)INREG(reg);
+
if (out_edid)
*out_edid = edid;
if (!edid) {
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] radeonfb: DDC i2c fix 2005-03-11 5:46 [PATCH] radeonfb: DDC i2c fix Benjamin Herrenschmidt @ 2005-03-11 20:13 ` Kronos 2005-03-11 23:52 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 4+ messages in thread From: Kronos @ 2005-03-11 20:13 UTC (permalink / raw) To: linux-fbdev-devel; +Cc: Andrew Morton, Benjamin Herrenschmidt Il Fri, Mar 11, 2005 at 04:46:10PM +1100, Benjamin Herrenschmidt ha scritto: > The radeonfb code for DDC probing (like it's X.org counterpart) uses to > leave the DDC clock & data lines asserted after the probing is complete. > This causes problems with some Apple monitors like the new Cinema HD > 23", who will turn themselves off when that happens. This fixes it. Fix is correct, but comment is not ;) After the loop SCL and SDA are left low. Pulling them high puts the I2C bus in the stop condition. Luca -- Home: http://kronoz.cjb.net Inquietudine sintetica Solo, davanti all'ignoto Tienimi stretto a te ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] radeonfb: DDC i2c fix 2005-03-11 20:13 ` Kronos @ 2005-03-11 23:52 ` Benjamin Herrenschmidt 2005-03-12 1:06 ` Kronos 0 siblings, 1 reply; 4+ messages in thread From: Benjamin Herrenschmidt @ 2005-03-11 23:52 UTC (permalink / raw) To: Kronos; +Cc: Linux Fbdev development list, Andrew Morton On Fri, 2005-03-11 at 21:13 +0100, Kronos wrote: > Il Fri, Mar 11, 2005 at 04:46:10PM +1100, Benjamin Herrenschmidt ha scritto: > > The radeonfb code for DDC probing (like it's X.org counterpart) uses to > > leave the DDC clock & data lines asserted after the probing is complete. > > This causes problems with some Apple monitors like the new Cinema HD > > 23", who will turn themselves off when that happens. This fixes it. > > Fix is correct, but comment is not ;) After the loop SCL and SDA are > left low. Pulling them high puts the I2C bus in the stop condition. Well, they are pull-up lines. I'm not pulling them high per-se, I'm "releasing" them to their natural state, which is high ;) The ATI code does some weird shit around the i2c transfer proper, and I don't know exactly why. I don't have any spec about DDC2 though, my understand is that it's more than just i2c EEPROM though. It used to leave the 2 lines "assserted" at the end of the transfer (after the last stop condition) and that sounded wrong and causes the misbehaviour on the Apple display ... Ben. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] radeonfb: DDC i2c fix 2005-03-11 23:52 ` Benjamin Herrenschmidt @ 2005-03-12 1:06 ` Kronos 0 siblings, 0 replies; 4+ messages in thread From: Kronos @ 2005-03-12 1:06 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Kronos, Linux Fbdev development list, Andrew Morton Il Sat, Mar 12, 2005 at 10:52:17AM +1100, Benjamin Herrenschmidt ha scritto: > On Fri, 2005-03-11 at 21:13 +0100, Kronos wrote: > > Il Fri, Mar 11, 2005 at 04:46:10PM +1100, Benjamin Herrenschmidt ha scritto: > > > The radeonfb code for DDC probing (like it's X.org counterpart) uses to > > > leave the DDC clock & data lines asserted after the probing is complete. > > > This causes problems with some Apple monitors like the new Cinema HD > > > 23", who will turn themselves off when that happens. This fixes it. > > > > Fix is correct, but comment is not ;) After the loop SCL and SDA are > > left low. Pulling them high puts the I2C bus in the stop condition. > > Well, they are pull-up lines. I'm not pulling them high per-se, I'm > "releasing" them to their natural state, which is high ;) The ATI code > does some weird shit around the i2c transfer proper, and I don't know > exactly why. When I wrote that code I asked a clarification from ATI (IIRC I spoke with Hui Yu) and they said that it was needed to cover some strange corner case. My tests showed that I was able to read EDID even without that black magic but since the code originated from ATI I left it in place. > I don't have any spec about DDC2 though, my understand is > that it's more than just i2c EEPROM though. I don't have DDC2 spec because VESA.org prices are too high... but I know that it's based on I2C protocol and it follows I2C format (ie. start-stop sequencies and so on). AFAIK for EDID initiating a read at the right address is enough, but DDC2 is meant to be bi-directional to control brightness, contrast, you name it. I'm clueless on this part of DCC2. Luca -- Home: http://kronoz.cjb.net Il piu` bel momento dell'amore e` quando ci si illude che duri per sempre; il piu` brutto, quando ci si accorge che dura da troppo. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-03-12 1:05 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-03-11 5:46 [PATCH] radeonfb: DDC i2c fix Benjamin Herrenschmidt 2005-03-11 20:13 ` Kronos 2005-03-11 23:52 ` Benjamin Herrenschmidt 2005-03-12 1:06 ` Kronos
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).