Bug 17902

Summary: [830M missing dvo driver] need support for DVO-LVDS via na2501
Product: DRI Reporter: Hernan Pastoriza <hpastoriza>
Component: DRM/IntelAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED WORKSFORME QA Contact:
Severity: enhancement    
Priority: low CC: aaardwark, andrelarsson200, ben, b.harrington, chris, chrome.x86, ciaran.gillespie, daniel, eugeni, florian, gilles.dartiguelongue, jbarnes, jim.bailey, mereandor, remi, rogutes, thep, thor, tlinden
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log with ModeDebug yes.
none
xorg.conf
none
output of intel_reg_dumper running the 1.7.4 version of the driver
none
Video ROM
none
xorg.conf with Option "ModeDebug" "yes"
none
Xorg.0.log with only the internal TFT display attached
none
Xorg.0.log using both the internal TFT and an external 1600x1200 VGA display
none
Output of intel_reg_dumper using internal TFT and external VGA displays.
none
The video ROM of the graphics chipset.
none
output of intel_reg_dumper with only internal TFT display and framebuffer driver
none
output of intel_reg_dumper with framebuffer driving internal TFT and external VGA
none
Xorg.0.log for the S6010 with the old i810 driver running Knoppix 5.1.1
none
Xorg.0.log with external display attached and using a Fedora 11 beta Live CD
none
Fujitsu Stylistic ST4110 Video ROM
none
0001-Initial-support-for-NS2501-LVDS-driving-chip.patch
none
Xorg.0.log using intel driver and ns2501 patch
none
xorg.conf using the intel driver
none
Xorg.0.log with Option "ModeDebug" "true"
none
drm driver reload script
none
rom_loki.bin
none
intel_drm_dumper
none
lspci -v
none
dmesg.txt none

Description Hernan Pastoriza 2008-10-04 09:13:30 UTC
Created attachment 19367 [details]
Xorg.0.log with ModeDebug yes.

I can not make to work the intel driver in my computer. The last working driver is the old i810-1.7.4.

X fails to start as no valid screens are found.

This is a Fujitsu lifebook S6110. 
uname -m: i686

Display chipset from lspci -v:

00:02.0 VGA compatible controller: Intel Corporation 82830 CGC [Chipset Graphics Controller] (rev 04) (prog-if 00 [VGA controller])
	Subsystem: Fujitsu Limited. Device 113c
	Flags: bus master, fast devsel, latency 0, IRQ 11
	Memory at e8000000 (32-bit, prefetchable) [size=128M]
	Memory at e0080000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: [d0] Power Management version 1
	Kernel driver in use: i915

00:02.1 Display controller: Intel Corporation 82830 CGC [Chipset Graphics Controller]
	Subsystem: Fujitsu Limited. Device 113c
	Flags: bus master, fast devsel, latency 0
	Memory at f0000000 (32-bit, prefetchable) [size=128M]
	Memory at e0100000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: [d0] Power Management version 1
	Kernel driver in use: i915

kernel: 2.6.26-gentoo-r1
Linux distribution: Gentoo ~x86 actualized. Masked xorg-server > version 1.4.9 and xf86-video-i810  > version 1.7.4, because problem with versions of this driver newer than that.

I tried changing options in the xorg.conf without success.

Reproducible: always from 2.0 version of the driver.
Comment 1 Hernan Pastoriza 2008-10-04 09:18:22 UTC
Created attachment 19368 [details]
xorg.conf
Comment 2 Hernan Pastoriza 2008-10-04 10:45:03 UTC
Created attachment 19370 [details]
output of intel_reg_dumper running the 1.7.4 version of the driver
Comment 3 Jesse Barnes 2008-10-06 15:07:06 UTC
Can you attach your video rom?

# cd /sys/devices/pci0000\:00/0000\:00\:02.0/
# echo 1 > rom
# cat rom > /tmp/rom.bin
# echo 0 > rom
Comment 4 Hernan Pastoriza 2008-10-07 05:19:37 UTC
Created attachment 19436 [details]
Video ROM

Here it is.
Comment 5 Tomas Lindén 2008-11-24 09:24:56 UTC
I have exactly the same problem that the intel driver for a 830M fails to start with the error messages
(EE) intel(0): sil164 not detected got 5: from DVOI2C_E Slave 112.
(EE) intel(0): tfp410 not detected got VID 1305: from DVOI2C_E Slave 112.
(EE) intel(0): No valid modes.
(EE) Screen(s) found, but none have a usable configuration.

System environment:
-- chipset: Intel Corporation 82830
-- system architecture: 32-bit
-- xf86-video-intel: 2.5.0-3 (from Fedora 10)
-- xserver: X.Org X Server 1.5.2
-- kernel: 2.6.27.5-41.fc9.i686
-- Linux distribution: Fedora 9
-- Machine or mobo model: Fujitsu Siemens S6010 Lifebook laptop
-- Display connector: Internal TFT-display

Additional info: The S6010 laptop has an internal 1024*768 TFT display and there is also the normal external VGA connector.

The BIOS has the following settings:
  Video Features / Display
    Internal Flat Display
    External
    Simultaneous
At the moment I use the setting "nternal Flat Display".

I have used RedHat 7.3, Fedora Core 3, 4, 5 and 6 and Fedora 7, 8 and 9 on this 
S6010 laptop. Only the old i810 driver has worked and I have never been able to start the new intel driver.

I created a minimal xorg.conf with
  system-config-display --set-driver=intel --reconfig
and added
  Option      "ModeDebug" "yes"
Comment 6 Tomas Lindén 2008-11-24 09:26:51 UTC
Created attachment 20555 [details]
xorg.conf with  Option      "ModeDebug" "yes"
Comment 7 Tomas Lindén 2008-11-24 09:27:45 UTC
Created attachment 20556 [details]
Xorg.0.log with only the internal TFT display attached
Comment 8 Tomas Lindén 2008-11-24 09:29:22 UTC
Created attachment 20557 [details]
Xorg.0.log using both the internal TFT and an external 1600x1200 VGA display
Comment 9 Tomas Lindén 2008-11-24 09:32:14 UTC
Attaching an external 1600x1200 monitor to the VGA port results in that startx hangs instead of ending with error messages as in the previous case. While startx was hanging I run
  intel_reg_dumper
see the next attachement.
Comment 10 Tomas Lindén 2008-11-24 09:33:31 UTC
Created attachment 20558 [details]
Output of intel_reg_dumper using internal TFT and external VGA displays.
Comment 11 Tomas Lindén 2008-11-24 09:40:02 UTC
lspci -v for the display chipset:

00:02.0 VGA compatible controller: Intel Corporation 82830 CGC [Chipset Graphics Controller] (rev 04) (prog-if 00 [VGA controller])
        Subsystem: Fujitsu Limited. Unknown device 113c
        Flags: bus master, fast devsel, latency 0, IRQ 11
        Memory at e8000000 (32-bit, prefetchable) [size=128M]
        Memory at e0080000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: [d0] Power Management version 1
        Kernel modules: i915, intelfb

00:02.1 Display controller: Intel Corporation 82830 CGC [Chipset Graphics Controller]
        Subsystem: Fujitsu Limited. Unknown device 113c
        Flags: bus master, fast devsel, latency 0
        Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Memory at e0100000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: [d0] Power Management version 1
        Kernel modules: i915
Comment 12 Tomas Lindén 2008-11-24 09:43:51 UTC
The video rom output obtained with:
  cd /sys/devices/pci0000\:00/0000\:00\:02.0/
  echo 1 > rom
  cat rom > /tmp/rom.bin
  echo 0 > rom
is shown in the next attachement.
Comment 13 Tomas Lindén 2008-11-24 09:45:10 UTC
Created attachment 20559 [details]
The video ROM of the graphics chipset.
Comment 14 Tomas Lindén 2008-11-24 13:51:42 UTC
This seems to be the same as bug 11148 which has been marked as a duplicate of bug 13722.
Comment 15 Tomas Lindén 2008-11-25 01:32:21 UTC
I have been using the framebuffer driver fbdev on my S6010 since the intel driver replaced the old i810 driver in Fedora. 
The next attachment is the output of  
  intel_reg_dumper
when I use the fbdev driver and only the internal TFT screen with the BIOS setting
  Video Features / Display
    Internal Flat Display
Comment 16 Tomas Lindén 2008-11-25 01:34:41 UTC
Created attachment 20570 [details]
output of intel_reg_dumper with only internal TFT display and framebuffer driver
Comment 17 Tomas Lindén 2008-11-25 01:35:54 UTC
To be able to drive a projector I need to use the BIOS setting
  Video Features / Display
    Simultaneous
when using the frambuffer driver. The next attachment is the output of
this situation with both the internal TFT and external VGA display in
use.
Comment 18 Tomas Lindén 2008-11-25 01:37:42 UTC
Created attachment 20571 [details]
output of intel_reg_dumper with framebuffer driving internal TFT and external VGA
Comment 19 Jesse Barnes 2008-11-25 15:42:00 UTC
Thanks for attaching your video BIOSes.  Unfortunately the info I was looking for isn't as easy to find as I had hoped.  My guess is that on these platforms the DVO attached LVDS encoder is at an address not expected by the i830_dvo.c code.  You could try playing with the addrs or disassembling your ROMs to see what ends up getting poked.

Based on Tomas' logs, it looks like there's something at i2c slave addr 112, but apparently not a TI TFP410 (since it returns 1305 for a read of addresses 0 and 1).  So it could be that your encoder is at the TFP410 address but is a different device that we don't handle yet...
Comment 20 Tomas Lindén 2008-11-29 00:25:18 UTC
Created attachment 20686 [details]
Xorg.0.log for the S6010 with the old i810 driver running Knoppix 5.1.1
Comment 21 Tomas Lindén 2008-11-29 02:10:46 UTC
I attached in the previous post the Xorg.0.log from the old i810 driver which worked fine. Hopefully that could give some clue about what goes wrong with the new intel driver. 

I have tried to use also the vesa and vga drivers on Fedora 9 and they both fail to start, so the the only driver that works at the moment is the fbdev. Does each driver detect the hardware independently?
Comment 22 Kieron Gillespie 2008-12-17 22:22:13 UTC
I have the exact same problem with my Fujitsu Stylistic ST4110, and the "intel" driver. It worked fine with the "i810" driver, but openSUSE 11.1 no longer has it as an option.

It too uses the i830M "82830 CGC" Intel chip set, and gives an "X fails to start as no valid screens are found."

Unless an external monitor is connected, then the external monitor displays a running X session, but the internal flat panel shows white vertical stripes that get progressively brighter.

I'd love for this bug to be fixed.
Comment 23 Tomas Lindén 2009-04-08 11:55:44 UTC
I booted my S6010 laptop with a Fedora 11 beta Live CD. If I have an external monitor connected to the laptop, then only the external monitor shows any picture. Without the external monitor I get no picture at all.
With this setup the error messages 
  (EE) intel(0): sil164 not detected got 5: from DVOI2C_E Slave 112.
  (EE) intel(0): tfp410 not detected got VID 1305: from DVOI2C_E Slave 112.
are gone. There are these warnings given
  (WW) Falling back to old probe method for vesa
  (WW) Falling back to old probe method for fbdev
  (WW) intel(0): Disabling Xv because no adaptors could be initialized.
I also set in the BIOS that I want to have simultaneously the internal and external displays. I still have not been able to find any way of getting the output on the laptops TFT screen.
Comment 24 Tomas Lindén 2009-04-08 11:57:15 UTC
Created attachment 24677 [details]
Xorg.0.log with external display attached and using a Fedora 11 beta Live CD
Comment 25 Tomas Lindén 2009-04-08 12:02:18 UTC
The intel driver does not give any output on the laptop screen or only a grey slowly changing pattern that probably is because the display is being driven by a too high refresh rate, which might potentially be dangerous for the display. I changed the severity of the bug therefore from enhancement to major.
Comment 26 Jesse Barnes 2009-05-11 12:25:20 UTC
Sorry, still an enhancement.  This feature has never been supported by driver code (prior to 2.0 it was done in the VBIOS).  Someone needs to write support for this DVO chip.  If you can figure out which DVO chip your machine has, the docs are often available, so you could get it going yourself (the drivers are usually pretty simple).
Comment 27 Jesse Barnes 2009-05-11 12:25:50 UTC
Oh and I don't think I'll be doing this.  I don't have any test hardware for it.
Comment 28 Tomas Lindén 2009-06-12 05:50:55 UTC
Do I understand correctly that the old i810 driver relied on the VBIOS to initialize the DVO-LVDS?

Can the DVO chip be identified from the VBIOS dump?

Can the DVO chip be identified by running a software tool, without opening the machine?

Is the DVO chip separate from the 830MG chipset itself?

Which DVO chips are usually used on laptops with 830MG chipsets?
Comment 29 Tomas Lindén 2009-06-16 14:30:52 UTC
How is the framebuffer setting up the DVO LVDS transmitter chip? Is it using the Video BIOS or not?
Comment 30 Tomas Lindén 2009-06-17 01:32:13 UTC
I dumped the Video BIOS as strings using
  od -S 3 rom.bio
In this way I found the promising strings

NA-2501
CH-7009-A
NA-2501
NA-2501
National Semiconductor
2501
BMP_NSLVDS_StartNA-2501
BMP_NSLVDS_FPDATA
CH-7009-A
Chrontel Inc.
7009

The Chrontel CH-7009-A is supported by the ch7xxx driver and it is used within i830_dvo.c.

What about the National Semiconductor NA-2501 chip, does it have X.org support?
I think this is the National Semiconductor NA-2501 datasheet
  http://www.national.com/ds/DS/DS90C2501.pdf#page=1

The same strings are in the Video BIOS dump from Hernan Pastorizas S6110 too.

Kieron Gillespie could you please also dump the Video BIOS of your 
Fujitsu Stylistic ST4110?
Comment 31 Kieron Gillespie 2009-06-17 07:27:58 UTC
Created attachment 26888 [details]
Fujitsu Stylistic ST4110 Video ROM

Here is the video rom image for my fujitsu stylistic st4110.
Comment 32 Hernan Pastoriza 2009-06-17 10:03:08 UTC
I think Thomas has found the clue. 
If you look for the logs the tfp410 driver complains 
"tfp410 not detected got VID 1305: from DVOI2C_E Slave 112" 
and from the datasheet of the DS90C2501 (page 17) the vendor ID is 
13h 05h.


Comment 33 Tomas Lindén 2009-06-17 13:36:29 UTC
The Fujitsu Stylistic ST4110 Video ROM contains these strings
NA-2501
NA-2501
NA-2501
National Semiconductor
2501
BMP_NSLVDS_StartNA-2501
BMP_NSLVDS_FPDATA
so it is also using the same National Semiconductor 2501 chip as the Lifebook S 6110 and 6010.
Comment 34 Tomas Lindén 2009-06-17 14:55:13 UTC
The error message 
  "ftp410 not detected got VID 1305: from DVOI2C_E slave 112." 
is also found from a Fujitsu Stylistic 4120
http://www.linuxquestions.org/questions/gentoo-87/xorg.conf.new-for-fujitsu-stylistic-4120-730018/

So this means that there are at least four laptop models affected by this bug.
Comment 35 Gordon Jin 2009-07-12 19:32:32 UTC
*** Bug 22699 has been marked as a duplicate of this bug. ***
Comment 36 Gilles Dartiguelongue 2009-07-15 01:08:59 UTC
Got a ST4110 as well, found the NS2501 datasheet and started hacking. If I don't have something in a week, consider I failed at figuring out how this stuff works :)
Comment 37 Tomas Lindén 2009-07-31 11:08:45 UTC
(In reply to comment #36)
> Got a ST4110 as well, found the NS2501 datasheet and started hacking. If I
> don't have something in a week, consider I failed at figuring out how this
> stuff works :)

Gilles, were you able to make any progress at all? If you would describe your problems, then maybe somebody might be able to help with solving them.
Comment 38 Gilles Dartiguelongue 2009-07-31 16:41:54 UTC
Uh yeah, sorry for keeping silent. So I managed to get the chip detected but reading registers 8 and 9 would fail the second time in init (I added some printf madness everywhere to see what the code was doing). Reading some recent discussions on the xorg mailing list, it might have been a problem in master (which my work is based on) so I'd need to rebase a see what's happening now.
I have been away from computers and will be tomorrow as well but I'll try to attach the patches on sunday so everyone can have a look.
Comment 39 Tomas Lindén 2009-08-08 15:02:58 UTC
(In reply to comment #38)
> Uh yeah, sorry for keeping silent. So I managed to get the chip detected but
> reading registers 8 and 9 would fail the second time in init (I added some
> printf madness everywhere to see what the code was doing). Reading some recent
> discussions on the xorg mailing list, it might have been a problem in master
> (which my work is based on) so I'd need to rebase a see what's happening now.
> I have been away from computers and will be tomorrow as well but I'll try to
> attach the patches on sunday so everyone can have a look.

OK, detecting the chip is already some progress. Please share your work so far-
Comment 40 Gilles Dartiguelongue 2009-08-08 15:30:25 UTC
Created attachment 28441 [details] [review]
0001-Initial-support-for-NS2501-LVDS-driving-chip.patch

Sorry, this slipped again. Anyway here is the rough thing I'm working on.
Comment 41 Tomas Lindén 2009-08-17 15:53:31 UTC
It seems that the Intel Embedded Graphics Driver driver has a NA-2501 driver since it mentions Driver/XFree86-4.2/ns2501.so:
                          Release Notes for the 
               Intel(R) Embedded Graphics Driver for Linux*    
                 Version 5.1 Gold Release, June 2006 

   http://downloadmirror.intel.com/9871/ENG/relnotes_Linux_5_1.txt

Is the source for this ns2501.so driver available somewhere? It might be useful for developing Gilles patch further.
Comment 42 Gordon Jin 2009-09-14 20:21:26 UTC
*** Bug 23432 has been marked as a duplicate of this bug. ***
Comment 43 ykzhao 2009-11-01 17:43:16 UTC
As the 830M chipset is not widely used and there is no corresponding specfic for DVO configuration, this bug will be rejected and marked as "WILLNOTFIX".
Thanks
Comment 44 Roman 2009-12-07 11:03:11 UTC
I don't see that this chipset is not widely used anymore. In the contrary: Up to now I found 5 bug reports on ubuntu only that seem to report this issue. Some of this bug reports have existed for years:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/238105
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/272560
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/257711
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/362582
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/306849

I'm sure though that there are lots of people who have the same problem and never look up the bug reports but simply stay with windows because linux "doesn't work" for them.

The last comments showed at least some progress in the area of discovering how this chip works, so I don't understand why this bug is closed as wontfix.
Comment 45 Theppitak Karoonboonyanan 2009-12-07 19:27:21 UTC
(In reply to comment #44)
> I don't see that this chipset is not widely used anymore. In the contrary: Up
> to now I found 5 bug reports on ubuntu only that seem to report this issue.
> Some of this bug reports have existed for years:

Thanks for reopening it. I was about to request for this action, too.

> I'm sure though that there are lots of people who have the same problem and
> never look up the bug reports but simply stay with windows because linux
> "doesn't work" for them.

For me, I'm fortunate to have installed a very old i810 driver (from Debian sarge version, IIRC) and pinned it at that version. This makes the video work. But as xorg has been developed, I've long suffered from broken XKB support and many other things. And I can't upgrade many GNOME packages due to the dependencies.

> The last comments showed at least some progress in the area of discovering how
> this chip works, so I don't understand why this bug is closed as wontfix.

Would some code from the old i810 driver help? I don't know about X video driver internals. Just hope (and pray) it helps.
Comment 46 Tomas Lindén 2009-12-08 05:48:41 UTC
Reading the X Linux Graphics Drivers from Intel website at
  http://intellinuxgraphics.org/documentation.html
one finds the section
  Supported Hardware
  The Linux graphics drivers from Intel support the following Intel® chipsets:
that lists
  i830M   82830 Chipset Graphics Controller
so the National Semiconductor 2501 driver should be implemented to fix this problem seen on several laptop models.

The Intel binary driver for the National Semiconductor 2501 chip ns2501.so, mentioned in comment #41 is actually available in binary form at
  http://www.spacechimp.net/rm4100/video/IEGD/IEGD_6_1_Linux/Driver/XFree86-4.3/
Could Intel publish the source for it as it might be useful with Gilles patch in comment #40?
Comment 47 Tomas Lindén 2009-12-08 06:43:15 UTC
By doing an octal dump with
  od -s 3 ns2501.so
one can see that this driver consists of the files:
  0034073 ns2501.c
  0034104 read_i2c_reg
  0034121 write_i2c_reg
  0034137 ns2501_driver
  0034155 ns2501_driver_mem
  0034177 ns2501_version
  0034216 ns2501_data.c
and there seems to be the entry points
  0003071 ns2501_exit
  0003105 ns2501_validate
  0003125 ns2501_get_attrs
  0003146 ns2501_get_timing_list
  0003175 ns2501_modes
  0003212 ns2501_1280x768_modes
  0003240 ns2501_get_port_status
  0003267 ns2501_get_power
  0003310 ns2501_init_device
  0003333 lpd_error
  0003345 ns2501_close
  0003362 pd_free
  0003372 ns2501_save
  0003406 pd_malloc
  0003420 pd_memset
  0003432 ns2501_regs
  0003446 ns2501_set_power
  0003467 pd_usleep
  0003501 ns2501_restore
  0003520 ns2501_post_set_mode
  0003545 ns2501_set_mode
  0003565 ns2501_set_attrs
  0003606 pd_get_attr
  0003622 ns2501_open
  0003636 ns2501_attrs
  0003653 pd_memcpy
  0003665 ns2501_init
  0003701 pd_strcpy
  0003713 ns2501_dab_list
  0003733 pd_register
  0003747 ns2501_num_regs
so there exists already code that could be reused and added to the present X Intel driver.
Comment 48 Tomas Lindén 2009-12-08 07:11:25 UTC
Actually the ns2501.so binary driver is available from
  http://downloadcenter.intel.com/confirm.aspx?httpDown=http://downloadmirror.intel.com/16751/eng/IEGD_9_0_2_GOLD_1203.Exe&agr=&ProductID=&DwnldId=16751&strOSs=&OSFullName=&lang=eng

contained in the tarball
  IEGD_9_0_2_Linux.tgz
The file 
  RELNOTES.txt
says
  ======================================================================
  Release Notes for the
  Intel(R) Embedded Graphics Drivers (IEGD) 
  with Configuration Editor (CED) Package

  Version 9.0 Beta Release
  May, 2008
  ======================================================================
and
  Linux: System Requirements    
  ==========================    
    
  This package includes drivers built for the following X servers: 
 
          XFree86 version 4.3.0 
          X.org version 6.7, 6.8, 7.0, 7.1, & 7.2
so the ns2501.so is also available for X.org and not only for XFree86.
Comment 49 Jim Bailey 2009-12-24 10:14:22 UTC
Very relieved to see this re-opened. I SO want to get Ubuntu Netbook Remix running on my Stylistic 4110.
Any help getting it going is appreciated.
Any help needed I will try to provide, but I'm not a programmer. I can follow technical instructions though.
Comment 50 Gilles Dartiguelongue 2010-01-31 11:43:45 UTC
I try to give it a shot again but I'm still blocked at the same point I was last time, running X -verbose with a couple of added debugging message, I get:

(II) Loading /usr/lib/xorg/modules/drivers//ns2501.so
(II) Module ns2501: vendor="X.Org Foundation"
	compiled for 1.6.2, module version = 1.0.0
(II) intel(0): I2C bus "DVOI2C_B" removed.
(II) intel(0): I2C bus "DVOI2C_E" initialized.
(II) intel(0): ns2501_init
(II) intel(0): ns2501 Reading ID.
(II) intel(0): ns2501 READ BYTE, addr 0
(II) intel(0): ns2501 READ BYTE, addr 0, value is: 05
(II) intel(0): ns2501 READ BYTE, addr 1
(II) intel(0): ns2501 READ BYTE, addr 1, value is: 13
(II) intel(0): ns2501 READ BYTE, addr 0
(II) intel(0): ns2501 READ BYTE, addr 0, value is: 05
(II) intel(0): ns2501 READ BYTE, addr 2
(II) intel(0): ns2501 READ BYTE, addr 2, value is: 26
(II) intel(0): ns2501_init FINAL
(II) intel(0): I2C device "DVOI2C_E:NS2501 LVDS Controller" registered at address 0x70.
(II) intel(0): Output LVDS has no monitor section
(II) intel(0): ns2501_save
(II) intel(0): ns2501 READ BYTE, addr 8
(II) intel(0): ns2501 READ BYTE, addr 8, value is: 31
(II) intel(0): ns2501 WRITE BYTE, addr 8: 39
(II) intel(0): ns2501 READ BYTE, addr 9
(II) intel(0): ns2501 READ BYTE, addr 9, value is: bf
(II) intel(0): ns2501 WRITE BYTE, addr 9: 95
(II) intel(0): ns2501 READ BYTE, addr 12
(II) intel(0): ns2501 READ BYTE, addr 12, value is: 00
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): ns2501_dpms
(II) intel(0): ns2501 READ BYTE, addr 8
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(II) intel(0): ns2501_detect
(II) intel(0): ns2501 READ BYTE, addr 9
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(II) intel(0): ns2501_detect, get bf
(II) intel(0): Output VGA disconnected
(II) intel(0): Output LVDS disconnected
(WW) intel(0): No outputs definitely connected, trying again...
(II) intel(0): Output VGA disconnected
(II) intel(0): Output LVDS disconnected
(WW) intel(0): Unable to find initial modes
(EE) intel(0): No valid modes.
(II) intel(0): ns2501_dpms
(II) intel(0): ns2501 READ BYTE, addr 8
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(II) intel(0): ns2501_restore
(II) intel(0): ns2501 WRITE BYTE, addr 8: 30
(II) intel(0): ns2501 WRITE BYTE, addr 9: bf
(II) intel(0): ns2501 WRITE BYTE, addr 12: 00
(II) intel(0): ns2501 WRITE BYTE, addr 8: 31
(II) Unloading /usr/lib/xorg/modules/drivers//ns2501.so
(II) Unloading /usr/lib/xorg/modules/drivers//ivch.so
(II) Unloading /usr/lib/xorg/modules/drivers//ch7xxx.so
(II) Unloading /usr/lib/xorg/modules/drivers//sil164.so
(II) Unloading /usr/lib/xorg/modules//libvgahw.so
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

=========================================

I still don't understand why the driver can't read in ns2501_dpms function while it works elsewhere in the code. Also, I tried to find iegd sources but could only find binaries and I had a look at desassembling it but I'm really a n00b at that. Please help me understand the problem.
Comment 51 Tomas Lindén 2010-02-24 01:32:27 UTC
Gilles, could you please post here your recipe for compiling the driver you are working on? I would be interested in compiling it to try it myself.
Comment 52 Roman 2010-02-26 05:42:01 UTC
I have an old laptop (Fujitsu Siemens S6010) that is affected by this bug.
It has a slightly defective keyboard but is functioning well except that. So it would be possibly to use it as a test machine.
I would send it to anybody who's willing to reimplement support for DVO-chip and needs a machine for testing.

Please contact me via e-mail to discuss further details if you would like to accept this offer.
Comment 53 Tomas Lindén 2010-04-08 02:43:46 UTC
Created attachment 34807 [details]
Xorg.0.log using intel driver and ns2501 patch
Comment 54 Tomas Lindén 2010-04-08 02:45:41 UTC
I tested the ns2501 patch that Gilles Dartiguelongue wrote and it works on my Fujitsu Siemens S6010 Lifebook! Thank you very much Gilles! This is very good progress finally! I hope we can figure out why it does not work on your laptop and to improve the patch to have it included upstream.

This is my recipe for compiling Gilles Dartiguelongues patch on Fedora
12 with kernel 2.6.32.10-90.fc12.i686.

The last version which contains the directories for Gilles patch is
xf86-video-intel-2.9.1. Later versions of the Intel driver require
kernel mode setting, so the patch cannot be applied since the directories have been moved.

Get the source of xf86-video-intel-2.9.1 with
wget http://ftp.x.org/pub/individual/driver/xf86-video-intel-2.9.1.tar.gz
tar -xvzf xf86-video-intel-2.9.1.tar.gz
cp -ax xf86-video-intel-2.9.1 b

Apply Gilles patch

patch -p0 -i 0001-Initial-support-for-NS2501-LVDS-driving-chip.patch
cd b

On Fedora 12 I had to make the following changes in ns2501.c to Gilles 
patch in order to make it compile            
comment out
  #include "xf86Resources.h"
replace
  #include <X11/extensions/dpms.h>
with
  #include <X11/extensions/dpmsconst.h>
  #include <X11/extensions/dpmsproto.h>

Compile the modules with:
  autoconf
On Fedora 12 I get an error message about the version of automake so I
need to run
  autoreconf
  ./configure --prefix=/tmp/intel-test
  make
  make install

Then the new modules need to be taken into use
cp /tmp/lib/xorg/modules/drivers/ns2501.so /usr/lib/xorg/modules/drivers/
mv /usr/lib/xorg/modules/drivers/intel_drv.so /usr/lib/xorg/modules/drivers/intel_drv.so_F12_org
cp /tmp/lib/xorg/modules/drivers/intel_drv.so /usr/lib/xorg/modules/drivers/

With these changes X starts with the intel driver. Glxgears works, but etracer crashes X. Also the beta version of the EVO videoconferencing system uses 3D-graphics which crashes X11.

The output from xrandr is strange since it claims that both outputs are disconnected, while in fact the LVDS does work.

xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048
VGA disconnected (normal left inverted right x axis y axis)
LVDS disconnected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
  1024x768 (0x43)   65.0MHz
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
        v: height  768 start  771 end  777 total  806           clock   60.0Hz
Comment 55 Tomas Lindén 2010-04-08 02:49:36 UTC
Created attachment 34808 [details]
xorg.conf using the intel driver
Comment 56 Tomas Lindén 2010-04-08 02:57:44 UTC
In the attached /var/log/Xorg.0.log logfile there are the error messages 

grep \(EE /var/log/Xorg.0.log
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(EE) intel(0): sil164 not detected got 5: from DVOI2C_E Slave 112.
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.

but apparently they are not fatal. In my BIOS settings I have presently set that I get output both to the internal and external screens. Gilles have you tried doing that?
Comment 57 Tomas Lindén 2010-04-08 03:35:23 UTC
If I attach an external monitor to the VGA connector, then it is recognized by xrandr, but I have not yet been able to enable the external display.

xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048
VGA disconnected (normal left inverted right x axis y axis)
LVDS disconnected 1024x768+0+0 (normal left inverted right x axis y
axis) 0mm x 0mm
  1024x768 (0x43)   65.0MHz
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock
48.4KHz
        v: height  768 start  771 end  777 total  806           clock   60.0Hz

xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048
VGA connected (normal left inverted right x axis y axis)
   1600x1200      60.0 +
   1280x1024      75.0     60.0
   1280x960       75.0     60.0
   1152x864       75.0
   1024x768       85.0     75.0     70.1     60.0
   832x624        74.6
   800x600        85.1     72.2     75.0     60.3     56.2
   640x480        85.0     75.0     72.8     66.7     59.9
   720x400        70.1
LVDS disconnected 1024x768+0+0 (normal left inverted right x axis y
axis) 0mm x 0mm

xrandr --auto
xrandr: cannot find crtc for output VGA

system-config-display draws a thin blue line and then the LVDS display
is covered with a slowly changing greyish pattern, probably because the internal display is driven with a too high refresh rate.

If I boot the S6010 with an external monitor attached, then the internal display shows again the slowly changing greyish pattern.

So having dualhead working needs some more effort. Any hints on how to proceed would be appreciated.
Comment 58 Tomas Lindén 2010-04-09 02:18:41 UTC
Created attachment 34840 [details]
Xorg.0.log with Option "ModeDebug" "true"
Comment 59 Tomas Lindén 2010-05-01 06:08:08 UTC
At the moment it is more chance and good luck that the intel driver starts with Gilles patch. I have the same problem that after initialization the routine that should read the ns2501 registers only returns error messages from the I2C bus. I don't know if some other device is blocking the I2C bus or what the problem is. So far I have not found a workaround. It seems that the routine that writes to the I2C bus works though. 

Has anyone else tried out Gilles patch?
Comment 60 Russell Dwiggins 2010-07-09 08:54:48 UTC
I just tried adding the patch using your instructions, and everything seemed to go well.  What I'm noticing now, though is that udev is creating the same symptoms that xorg did.

I'll have a look through my logs to see if I can find something relevant.
Comment 61 Jesse Barnes 2010-07-15 11:24:15 UTC
Reassigning to the community.  If someone can find docs for this, writing support shouldn't be too hard.
Comment 62 Eugeni Dodonov 2011-09-08 15:56:16 UTC
This issue is affecting a hardware component which is not being actively worked on anymore.

Moving the assignee to the dri-devel list as contact, to give this issue a better coverage.
Comment 63 Gilles Dartiguelongue 2012-04-15 08:56:35 UTC
For the record, I'm still working on this from time to time.
I ported the patch to kernel land quite easily, but still can't figure out what is the problem with register read failures.

Example from a 3.3.1 kernel booted with i915.modeset=1 drm.debug=0x04:

Apr 15 17:52:11 mobilix kernel: [drm:ns2501_init], init ns2501 dvo controller successfully!
Apr 15 17:52:11 mobilix kernel: [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.
Apr 15 17:52:11 mobilix kernel: [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.
Apr 15 17:52:11 mobilix kernel: [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.
Apr 15 17:52:11 mobilix kernel: [drm:ns2501_readb], Unable to read register 0x09 from i915 gmbus dpb:38.
Apr 15 17:52:11 mobilix kernel: [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.

I would really appreciate someone with drm/intel knowledge helping here.
Will post patches later (code is really not that different that my previous post about this).
Comment 64 Jim Bailey 2012-04-16 11:01:27 UTC
Thanks for working on this Gilles. I wish I could help.
Comment 65 Daniel Vetter 2012-04-16 11:24:43 UTC
You need to check where the dvo chip actually is, i915 has about 6 different i2c channels. The easiest way is to use one of the i2c-tools to detect chips on all the i2c buses that drm/i915 exposes.
Comment 66 Gilles Dartiguelongue 2012-04-17 15:37:21 UTC
Ok, I installed i2c-tools and here is what it sees:

# i2cdetect -l
i2c-0	i2c       	i915 gmbus disabled             	I2C adapter
i2c-1	i2c       	i915 gmbus ssc                  	I2C adapter
i2c-2	i2c       	i915 GPIOB                      	I2C adapter
i2c-3	i2c       	i915 gmbus vga                  	I2C adapter
i2c-4	i2c       	i915 GPIOA                      	I2C adapter
i2c-5	i2c       	i915 gmbus panel                	I2C adapter
i2c-6	i2c       	i915 GPIOC                      	I2C adapter
i2c-7	i2c       	i915 gmbus dpc                  	I2C adapter
i2c-8	i2c       	i915 GPIOD                      	I2C adapter
i2c-9	i2c       	i915 gmbus dpb                  	I2C adapter
i2c-10	i2c       	i915 GPIOE                      	I2C adapter
i2c-11	i2c       	i915 gmbus reserved             	I2C adapter
i2c-12	i2c       	i915 gmbus dpd                  	I2C adapter
i2c-13	i2c       	i915 GPIOF                      	I2C adapter
i2c-14	smbus     	SMBus I801 adapter at 1880      	SMBus adapter

Then I run i2cdetect -y on all i2c buses, but only 0 and 11 (and 14 but that's unrelated to our work here I guess) show something.

Here is the output for those two:

# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --         

# i2cdetect -y 11
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- 39 -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- 61 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --             

reserved and disabled does not sound right anyway. Am I doing it right ?
Comment 67 Gilles Dartiguelongue 2012-04-17 15:45:56 UTC
Ok, forget that, I rebooted without kms disabled and now I get 28 i2c/smbus devices (most likely duplicates). Now scanning:

i2c-9	i2c       	i915 gmbus dpb                  	I2C adapter
i2c-10	i2c       	i915 GPIOE                      	I2C adapter

gives:

# i2cdetect -y 9
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

and 

# i2cdump -y 9 0x38
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 05 13 26 67 01 a5 19 a2 31 97 81 ff 00 04 00 00    ??&g????1??..?..
10: 00 a0 02 02 02 02 02 02 07 00 00 11 54 03 02 40    .????????..?T??@
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
30: 00 00 00 00 03 ff 00 28 88 88 00 00 00 00 00 00    ....?..(??......
40: 80 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00    ?..?............
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 11 00 00 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0    ?..?????????????
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00    ..............?.
80: ff 07 3d 05 00 00 00 00 00 00 00 00 10 02 10 00    .?=?........???.
90: ff 07 a0 02 00 00 05 00 00 00 88 00 24 00 25 03    .???..?...?.$.%?
a0: 28 01 28 05 84 00 00 00 00 04 70 4f 00 00 03 03    (?(??....?pO..??
b0: 00 00 00 00 00 00 09 03 00 a0 00 20 33 33 33 33    ......??.?. 3333
c0: 05 90 00 0f 03 16 00 02 02 00 00 00 00 00 00 00    ??.???.??.......
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 98 00 80 00 00 00 80 00 00 00 00 00 00 00    ..?.?...?.......
f0: 71 77 b3 90 00 00 00 88 0a 0f 0a 0a 0a 0a 0a 0a    qw??...?????????

So 1305 and 6726 actually look like the first registers indicated in the datasheet.
Comment 68 Daniel Vetter 2012-04-18 00:22:02 UTC
Yeah, the second i2cdetect dump looks much more reasonable, and it looks like you've indeed found the right bus for your i2c device. So the next step is to use that one with dev_priv->gmbus[GMBUS_PORT_DPB] and see whether it works better.

Btw, the gmbus reserved and disabled don't really exist, 3.5 will kill them. And if you have quick questions I suggest you ask on irc, #intel-gfx on freenode, usually one of us is around.
Comment 69 Gilles Dartiguelongue 2012-04-20 16:41:09 UTC
I pushed the current state of the code here:
https://github.com/EvaSDK/linux/commit/d590f8631a2421ba6bcef7041888b3aa382f87c7

I commented out dpms code for testing, but given the power of the machine it was quite long to get that out already so I'll fix that later.
Comment 70 Daniel Vetter 2012-04-21 06:08:48 UTC
Created attachment 60416 [details] [review]
drm driver reload script

Looks like you've made a start alright. As I've said, I've you're getting stuck somewhere, don't be afreaid to pop up on #intel-gfx on irc. To speed up the development you can also only reload the drm/i915.ko kernel module. It's a bit tricky, so I use the attached script (you still need to compile i915.ko and copy it into the right place, of course).

You also need to enable CONFIG_VT_HW_CONSOLE_BINDING, otherwise the fbcon unbinding won't work and you can't unload i915.ko. Also, a 2nd machine with ssh access is very nice in case the module-reloading failed - otherwise you'll just be starring at a blank screen.
Comment 71 Chris Wilson 2012-05-25 05:01:20 UTC
*** Bug 50303 has been marked as a duplicate of this bug. ***
Comment 72 thor 2012-05-25 14:51:23 UTC
Ok, I managed to cross-compile the patched kernel sources on a much faster x64 machine, so I now have an initrd and a vmlinuz with the patch in it. I won't have access to the machine until tomorrow.

Is this already supposed to do anything interesting, or would anyone just be interested in the debug output?

I also found a datasheet from national semiconductor for the DS90C2501, is this the right one?
Comment 73 thor 2012-05-28 23:59:16 UTC
Ok, so I now fiddled a little bit with the patched kernel and the i2c utilities. In fact, I do get "something like a picture" on this machine. By which I mean that the image is ripped apart, the borders aren't set correctly, but the LVDS is at least detected and the screen is not totally blank.

Playing with the i2c utilities showed that on this Fujitsu Siemens the ns2501 (and yes, it really is one) is on chip address 0x38 on bus number 6.

I played with i2cset here and there and could disable and enable the screen with register #8, bit #0, but I do not get a usable screen. I do not know enough about DVO chips to be of much help as far as the programming is concerned.

What else can be done from here that would help you?

I get the following from /var/log/messages:

[    7.272103] [drm:intel_opregion_setup], graphic opregion physical addr: 0x0
[    7.272113] [drm:intel_opregion_setup], ACPI OpRegion not supported!
[    7.272140] [drm:i915_init_phys_hws], Enabled hardware status page
[    7.272156] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    7.272162] [drm] Driver supports precise vblank timestamp query.
[    7.272176] [drm:init_vbt_defaults], Set default to SSC at 66MHz
[    7.272414] [drm:parse_general_features], BDB_GENERAL_FEATURES int_tv_support 1 int_crt_support 0 lvds_use_ssc 0 lvds_ssc_freq 48 display_clock_mode 0
[    7.272430] [drm:parse_general_definitions], crt_ddc_bus_pin: 2
[    7.272441] [drm:parse_sdvo_device_mapping], different child size is found. Invalid.
[    7.272450] [drm:parse_device_mapping], different child size is found. Invalid.
[    7.272476] [drm:intel_dsm_pci_probe], no _DSM method for intel device
[    7.272516] [drm:intel_modeset_init], 2 display pipes available.
[    7.272539] [drm:intel_modeset_init], plane 0 init failed: -19
[    7.272555] [drm:intel_modeset_init], plane 1 init failed: -19
[    7.272570] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    7.272899] device: 'card0-VGA-1': device_add
[    7.272935] PM: Adding info for No Bus:card0-VGA-1
[    7.274750] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[    7.274763] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[    7.275659] [drm:sil164_init], sil164 not detected got 5: from i915 gmbus dpb Slave 56.
[    7.275676] i2c i2c-6: master_xfer[0] W, addr=0x76, len=1
[    7.275686] i2c i2c-6: master_xfer[1] R, addr=0x76, len=1
[    7.275921] i2c i2c-6: NAK from device addr 0x76 msg #0
[    7.275961] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[    7.275970] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[    7.276900] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[    7.276911] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[    7.291048] [drm:ns2501_init], init ns2501 dvo controller successfully!
[    7.291088] device: 'card0-DVI-I-1': device_add
[    7.291138] PM: Adding info for No Bus:card0-DVI-I-1
[    7.295247] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[    7.295260] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[    7.296382] [drm:i915_get_vblank_timestamp], crtc 0 is disabled
[    7.301363] [drm:intel_update_fbc],
[    7.301375] [drm:i915_get_vblank_timestamp], crtc 1 is disabled
[    7.306349] [drm:intel_update_fbc],
[    7.311054] [drm] initialized overlay support
[    7.311268] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[    7.311279] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[    7.311520] i2c i2c-6: NAK from device addr 0x38 msg #0
[    7.311556] [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.
[    7.311579] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1]
[    7.311594] i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
[    7.311604] i2c i2c-3: master_xfer[1] R, addr=0x50, len=1
[    7.311843] i2c i2c-3: NAK from device addr 0x50 msg #0
[    7.311882] [drm:intel_get_load_detect_pipe], [CONNECTOR:5:VGA-1], [ENCODER:6:DAC-6]
[    7.311893] [drm:intel_get_load_detect_pipe], creating tmp fb for load-detection
[    7.311930] [drm:drm_crtc_helper_set_mode], [CRTC:3]
[    7.311944] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[    7.311954] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[    7.312229] i2c i2c-6: NAK from device addr 0x38 msg #0
[    7.312265] [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.
[    7.319657] [drm:i9xx_crtc_mode_set], Mode for pipe A:
[    7.319667] [drm:drm_mode_debug_printmodeline], Modeline 0:"640x480" 0 31500 640 664 704 832 480 489 491 520 0x10 0xa
[    7.352750] [drm:i9xx_update_plane], Writing base 00020000 00000000 0 0 2560
[    7.352771] [drm:intel_update_fbc],
[    7.352781] [drm:i830_get_fifo_size], FIFO size - (0x00017e5f) A: 47
[    7.352792] [drm:intel_calculate_wm], FIFO entries required for mode: 20
[    7.352800] [drm:intel_calculate_wm], FIFO watermark level: 25
[    7.352809] [drm:i830_update_wm], Setting FIFO watermarks - A: 25
[    7.352823] [drm:drm_crtc_helper_set_mode], [ENCODER:6:DAC-6] set [MODE:0:640x480]
[    7.352836] [drm:i830_get_fifo_size], FIFO size - (0x00017e5f) A: 47
[    7.352845] [drm:intel_calculate_wm], FIFO entries required for mode: 20
[    7.352853] [drm:intel_calculate_wm], FIFO watermark level: 25
[    7.352861] [drm:i830_update_wm], Setting FIFO watermarks - A: 25
[    7.353407] [drm:intel_update_fbc],
[    7.368057] i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
[    7.368070] i2c i2c-3: master_xfer[1] R, addr=0x50, len=1
[    7.368317] i2c i2c-3: NAK from device addr 0x50 msg #0
[    7.368354] [drm:intel_crt_load_detect], starting load-detect on CRT
[    7.375100] [drm:intel_release_load_detect_pipe], [CONNECTOR:5:VGA-1], [ENCODER:6:DAC-6]
[    7.375120] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[    7.375130] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[    7.379836] i2c i2c-6: NAK from device addr 0x38 msg #0
[    7.379878] [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.
[    7.379901] [drm:i915_get_vblank_timestamp], crtc 0 is disabled
[    7.397006] [drm:intel_update_fbc],
[    7.401475] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] disconnected
[    7.401495] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:DVI-I-1]
[    7.401515] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[    7.401525] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[    7.401766] i2c i2c-6: NAK from device addr 0x38 msg #0
[    7.401802] [drm:ns2501_readb], Unable to read register 0x09 from i915 gmbus dpb:38.
[    7.401819] i2c i2c-5: master_xfer[0] W, addr=0x50, len=1
[    7.401829] i2c i2c-5: master_xfer[1] R, addr=0x50, len=1
[    7.402063] i2c i2c-5: NAK from device addr 0x50 msg #0
[    7.402098] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus dpc
[    7.402137] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:DVI-I-1] probed modes :
[    7.402150] [drm:drm_mode_debug_printmodeline], Modeline 13:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x400xa
[    7.402168] [drm:drm_mode_debug_printmodeline], Modeline 11:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
[    7.402186] [drm:drm_mode_debug_printmodeline], Modeline 10:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
[    7.402203] [drm:drm_mode_debug_printmodeline], Modeline 12:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
[    7.402220] [drm:drm_mode_debug_printmodeline], Modeline 9:"640x480" 60 25175 640 656 752 800 480 489 492 525 0x40 0xa
[    7.402237] [drm:drm_setup_crtcs],
[    7.402245] [drm:drm_enable_connectors], connector 5 enabled? no
[    7.402254] [drm:drm_enable_connectors], connector 8 enabled? yes
[    7.402262] [drm:drm_target_preferred], looking for cmdline mode on connector 8
[    7.402272] [drm:drm_target_preferred], looking for preferred mode on connector 8
[    7.402281] [drm:drm_target_preferred], found mode 1024x768
[    7.402289] [drm:drm_setup_crtcs], picking CRTCs for 2048x2048 config
[    7.402302] [drm:drm_setup_crtcs], desired mode 1024x768 set on crtc 3
[    7.413512] [drm:intelfb_create], allocated 1024x768 fb: 0x00020000, bo f6b1e200
[    7.413549] device: 'fb0': device_add
[    7.413685] PM: Adding info for No Bus:fb0
[    7.413950] fbcon: inteldrmfb (fb0) is primary device
[    7.413985] device: 'vtcon1': device_add
[    7.414018] PM: Adding info for No Bus:vtcon1
[    7.415526] [drm:drm_crtc_helper_set_config],
[    7.415534] [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:15] #connectors=1 (x y) (0 0)
[    7.415555] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set
[    7.415564] [drm:drm_crtc_helper_set_config], modes are different, full mode set
[    7.415572] [drm:drm_mode_debug_printmodeline], Modeline 0:"640x480" 0 31500 640 664 704 832 480 489 491 520 0x10 0xa
[    7.415588] [drm:drm_mode_debug_printmodeline], Modeline 14:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[    7.415605] [drm:drm_crtc_helper_set_config], encoder changed, full mode switch
[    7.415613] [drm:drm_crtc_helper_set_config], crtc changed, full mode switch
[    7.415621] [drm:drm_crtc_helper_set_config], [CONNECTOR:8:DVI-I-1] to [CRTC:3]
[    7.415631] [drm:drm_crtc_helper_set_config], attempting to set mode from userspace
[    7.415638] [drm:drm_mode_debug_printmodeline], Modeline 14:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[    7.415662] [drm:drm_crtc_helper_set_mode], [CRTC:3]
[    7.415679] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[    7.415688] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[    7.415929] i2c i2c-6: NAK from device addr 0x38 msg #0
[    7.415964] [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.
[    7.423353] [drm:i9xx_crtc_mode_set], Mode for pipe A:
[    7.423361] [drm:drm_mode_debug_printmodeline], Modeline 14:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[    7.460089] [drm:i9xx_update_plane], Writing base 00020000 00000000 0 0 4096
[    7.460106] [drm:intel_update_fbc],
[    7.460116] [drm:i830_get_fifo_size], FIFO size - (0x00017e5f) A: 47
[    7.460126] [drm:intel_calculate_wm], FIFO entries required for mode: 41
[    7.460134] [drm:intel_calculate_wm], FIFO watermark level: 4
[    7.460141] [drm:i830_update_wm], Setting FIFO watermarks - A: 4
[    7.460156] [drm:drm_crtc_helper_set_mode], [ENCODER:7:None-7] set [MODE:14:1024x768]
[    7.460170] [drm:i830_get_fifo_size], FIFO size - (0x00017e5f) A: 47
[    7.460178] [drm:intel_calculate_wm], FIFO entries required for mode: 41
[    7.460186] [drm:intel_calculate_wm], FIFO watermark level: 4
[    7.460193] [drm:i830_update_wm], Setting FIFO watermarks - A: 4
[    7.460707] [drm:intel_update_fbc],
[    7.460728] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[    7.460737] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[    7.461643] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on
[    7.461653] [drm:drm_crtc_helper_set_config],        [CONNECTOR:8:DVI-I-1] set DPMS on
[    7.461673] [drm:drm_crtc_helper_set_config],
[    7.461680] [drm:drm_crtc_helper_set_config], [CRTC:4] [NOFB]
[    7.461924] [drm:drm_crtc_helper_set_config],
[    7.461931] [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:15] #connectors=1 (x y) (0 0)
[    7.461958] [drm:drm_crtc_helper_set_config], [CONNECTOR:8:DVI-I-1] to [CRTC:3]
[    7.474205] Console: switching to colour frame buffer device 128x48
[    7.474225] [drm:drm_crtc_helper_set_config],
[    7.474231] [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:15] #connectors=1 (x y) (0 0)
[    7.474249] [drm:drm_crtc_helper_set_config], [CONNECTOR:8:DVI-I-1] to [CRTC:3]
[    7.486708] fb0: inteldrmfb frame buffer device
[    7.486715] drm: registered panic notifier
[    7.490839] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[    7.490858] driver: '0000:00:02.0': driver_bound: bound to device 'i915'
[    7.490889] bus: 'pci': really_probe: bound device 0000:00:02.0 to driver i915
[    7.490906] bus: 'pci': driver_probe_device: matched device 0000:00:02.1 with driver i915
[    7.490917] bus: 'pci': really_probe: probing driver i915 with device 0000:00:02.1
[    7.490952] i915: probe of 0000:00:02.1 rejects match -19
[   17.504401] [drm:output_poll_execute], [CONNECTOR:5:VGA-1] status updated from 2 to 2
[   18.689376] uhci_hcd 0000:00:1d.0: reserve dev 2 ep81-INT, period 8, phase 4, 93 us
[   18.690873] uhci_hcd 0000:00:1d.0: release dev 2 ep81-INT, period 8, phase 4, 93 us
[   18.690910] [drm:i915_driver_irq_handler], pipe A underrun
[   18.690919] [drm:i915_driver_irq_handler], pipe B underrun
[   24.166706] [drm:drm_crtc_helper_set_config],
[   24.166720] [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:15] #connectors=1 (x y) (0 0)
[   24.166754] [drm:drm_crtc_helper_set_config], [CONNECTOR:8:DVI-I-1] to [CRTC:3]
[   24.185194] [drm:i915_driver_open],
[   24.185352] [drm:drm_crtc_helper_set_config],
[   24.185362] [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:15] #connectors=1 (x y) (0 0)
[   24.185394] [drm:drm_crtc_helper_set_config], [CONNECTOR:8:DVI-I-1] to [CRTC:3]
[   24.185405] [drm:drm_crtc_helper_set_config],
[   24.185411] [drm:drm_crtc_helper_set_config], [CRTC:4] [NOFB]
[   24.185536] [drm:i915_driver_open],
[   24.186516] [drm:drm_mode_getresources], CRTC[2] CONNECTORS[2] ENCODERS[2]
[   24.186534] [drm:drm_mode_getresources], CRTC[2] CONNECTORS[2] ENCODERS[2]
[   24.186711] [drm:drm_mode_getconnector], [CONNECTOR:5:?]
[   24.186724] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1]
[   24.186744] i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
[   24.186754] i2c i2c-3: master_xfer[1] R, addr=0x50, len=1
[   24.187002] i2c i2c-3: NAK from device addr 0x50 msg #0
[   24.187041] [drm:intel_get_load_detect_pipe], [CONNECTOR:5:VGA-1], [ENCODER:6:DAC-6]
[   24.187054] [drm:intel_get_load_detect_pipe], reusing fbdev for load-detection framebuffer
[   24.187070] [drm:drm_crtc_helper_set_mode], [CRTC:4]
[   24.194578] [drm:i9xx_crtc_mode_set], Mode for pipe B:
[   24.194589] [drm:drm_mode_debug_printmodeline], Modeline 0:"640x480" 0 31500 640 664 704 832 480 489 491 520 0x10 0xa
[   24.208140] [drm:i915_driver_irq_handler], pipe B underrun
[   24.224077] [drm:i9xx_update_plane], Writing base 00020000 00000000 0 0 4096
[   24.224097] [drm:intel_update_fbc],
[   24.224113] [drm:drm_crtc_helper_set_mode], [ENCODER:6:DAC-6] set [MODE:0:640x480]
[   24.224664] [drm:intel_update_fbc],
[   24.240067] i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
[   24.240079] i2c i2c-3: master_xfer[1] R, addr=0x50, len=1
[   24.240327] i2c i2c-3: NAK from device addr 0x50 msg #0
[   24.240366] [drm:intel_crt_load_detect], starting load-detect on CRT
[   24.250023] [drm:intel_release_load_detect_pipe], [CONNECTOR:5:VGA-1], [ENCODER:6:DAC-6]
[   24.251717] [drm:i915_get_vblank_timestamp], crtc 1 is disabled
[   24.269044] [drm:intel_update_fbc],
[   24.269061] [drm:i830_get_fifo_size], FIFO size - (0x00017e5f) A: 47
[   24.269072] [drm:intel_calculate_wm], FIFO entries required for mode: 41
[   24.269081] [drm:intel_calculate_wm], FIFO watermark level: 4
[   24.269090] [drm:i830_update_wm], Setting FIFO watermarks - A: 4
[   24.269121] i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
[   24.269131] i2c i2c-3: master_xfer[1] R, addr=0x50, len=1
[   24.269380] i2c i2c-3: NAK from device addr 0x50 msg #0
[   24.269417] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus vga
[   24.269459] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] probed modes :
[   24.269472] [drm:drm_mode_debug_printmodeline], Modeline 20:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[   24.269490] [drm:drm_mode_debug_printmodeline], Modeline 18:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
[   24.269507] [drm:drm_mode_debug_printmodeline], Modeline 17:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
[   24.269524] [drm:drm_mode_debug_printmodeline], Modeline 19:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
[   24.269541] [drm:drm_mode_debug_printmodeline], Modeline 16:"640x480" 60 25175 640 656 752 800 480 489 492 525 0x40 0xa
[   24.269585] [drm:drm_mode_getconnector], [CONNECTOR:5:?]
[   24.269909] [drm:drm_mode_getconnector], [CONNECTOR:8:?]
[   24.269921] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:DVI-I-1]
[   24.269937] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[   24.269947] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[   24.270838] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:DVI-I-1] disconnected
[   24.270850] [drm:drm_mode_debug_printmodeline], Modeline 13:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[   24.270868] [drm:drm_mode_prune_invalid], Not using 1024x768 mode -3
[   24.270880] [drm:drm_mode_debug_printmodeline], Modeline 11:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
[   24.270896] [drm:drm_mode_prune_invalid], Not using 800x600 mode -3
[   24.270906] [drm:drm_mode_debug_printmodeline], Modeline 10:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
[   24.270922] [drm:drm_mode_prune_invalid], Not using 800x600 mode -3
[   24.270931] [drm:drm_mode_debug_printmodeline], Modeline 12:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
[   24.270948] [drm:drm_mode_prune_invalid], Not using 848x480 mode -3
[   24.270957] [drm:drm_mode_debug_printmodeline], Modeline 9:"640x480" 60 25175 640 656 752 800 480 489 492 525 0x40 0xa
[   24.270973] [drm:drm_mode_prune_invalid], Not using 640x480 mode -3
[   24.270987] [drm:drm_mode_getconnector], [CONNECTOR:8:?]
[   24.270997] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:DVI-I-1]
[   24.271011] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[   24.271021] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[   24.271908] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:DVI-I-1] disconnected
[   24.275869] [drm:drm_mode_getconnector], [CONNECTOR:5:?]
[   24.275881] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1]
[   24.275898] i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
[   24.275908] i2c i2c-3: master_xfer[1] R, addr=0x50, len=1
[   24.276179] i2c i2c-3: NAK from device addr 0x50 msg #0
[   24.276219] [drm:intel_get_load_detect_pipe], [CONNECTOR:5:VGA-1], [ENCODER:6:DAC-6]
[   24.276232] [drm:intel_get_load_detect_pipe], reusing fbdev for load-detection framebuffer
[   24.276252] [drm:drm_crtc_helper_set_mode], [CRTC:4]
[   24.283688] [drm:i9xx_crtc_mode_set], Mode for pipe B:
[   24.283698] [drm:drm_mode_debug_printmodeline], Modeline 0:"640x480" 0 31500 640 664 704 832 480 489 491 520 0x10 0xa
[   24.332074] [drm:i9xx_update_plane], Writing base 00020000 00000000 0 0 4096
[   24.332100] [drm:intel_update_fbc],
[   24.332118] [drm:drm_crtc_helper_set_mode], [ENCODER:6:DAC-6] set [MODE:0:640x480]
[   24.332670] [drm:intel_update_fbc],
[   24.340060] i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
[   24.340071] i2c i2c-3: master_xfer[1] R, addr=0x50, len=1
[   24.340322] i2c i2c-3: NAK from device addr 0x50 msg #0
[   24.340361] [drm:intel_crt_load_detect], starting load-detect on CRT
[   24.352884] [drm:intel_release_load_detect_pipe], [CONNECTOR:5:VGA-1], [ENCODER:6:DAC-6]
[   24.352905] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[   24.352915] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[   24.354530] [drm:i915_get_vblank_timestamp], crtc 0 is disabled
[   24.377007] [drm:intel_update_fbc],
[   24.377022] [drm:i830_get_fifo_size], FIFO size - (0x00017e5f) A: 47
[   24.377034] [drm:intel_calculate_wm], FIFO entries required for mode: 20
[   24.377043] [drm:intel_calculate_wm], FIFO watermark level: 25
[   24.377051] [drm:i830_update_wm], Setting FIFO watermarks - A: 25
[   24.380202] [drm:i915_get_vblank_timestamp], crtc 1 is disabled
[   24.388050] ------------[ cut here ]------------
[   24.388120] WARNING: at drivers/gpu/drm/i915/intel_display.c:994 intel_disable_pipe+0x109/0x140 [i915]()
[   24.388129] Hardware name: LIFEBOOK S Series
[   24.388135] plane B assertion failure, should be off on pipe B but is still active
[   24.388142] Modules linked in: binfmt_misc fuse loop firewire_sbp2 i915 snd_intel8x0 snd_ac97_codec drm_kms_helper drm ac97_bus snd_pcm psmouse pcmcia snd_seq acpi_cpufreq yenta_socket snd_timer snd_seq_device snd microcode apanel pcspkr pcmcia_rsrc input_polldev evdev mperf i2c_algo_bit video processor fujitsu_laptop thermal_sys i2c_i801 i2c_core rng_core soundcore snd_page_alloc pcmcia_core shpchp led_class serio_raw pci_hotplug battery button ac ext3 jbd mbcache usbhid hid sg sr_mod sd_mod cdrom ata_generic ata_piix firewire_ohci uhci_hcd libata 8139too 8139cp scsi_mod usbcore firewire_core crc_itu_t mii usb_common [last unloaded: scsi_wait_scan]
[   24.388273] Pid: 984, comm: Xorg Not tainted 3.4.0 #3
[   24.388280] Call Trace:
[   24.388299]  [<c102a3bd>] warn_slowpath_common+0x6d/0xa0
[   24.388329]  [<f8dc4a39>] ? intel_disable_pipe+0x109/0x140 [i915]
[   24.388358]  [<f8dc4a39>] ? intel_disable_pipe+0x109/0x140 [i915]
[   24.388369]  [<c102a46e>] warn_slowpath_fmt+0x2e/0x30
[   24.388398]  [<f8dc4a39>] intel_disable_pipe+0x109/0x140 [i915]
[   24.388429]  [<f8dcb251>] i9xx_crtc_disable+0x91/0x120 [i915]
[   24.388458]  [<f8dcb30d>] i9xx_crtc_dpms+0x2d/0x40 [i915]
[   24.388487]  [<f8dc5a10>] intel_crtc_dpms+0x40/0x130 [i915]
[   24.388516]  [<f8dc6d58>] intel_crtc_disable+0x48/0xa0 [i915]
[   24.388532]  [<f8c282ef>] drm_helper_disable_unused_functions+0xef/0x140 [drm_kms_helper]
[   24.388562]  [<f8dc8090>] intel_release_load_detect_pipe+0xd0/0xf0 [i915]
[   24.388595]  [<f8dcfb3b>] intel_crt_detect+0x2ab/0x6c0 [i915]
[   24.388610]  [<f8c29358>] drm_helper_probe_single_connector_modes+0x248/0x310 [drm_kms_helper]
[   24.388646]  [<f8be8387>] drm_mode_getconnector+0x2f7/0x350 [drm]
[   24.388665]  [<c10a94a2>] ? get_page_from_freelist+0x262/0x500
[   24.388686]  [<f8bdae32>] drm_ioctl+0x282/0x550 [drm]
[   24.388708]  [<f8be8090>] ? drm_mode_getencoder+0xb0/0xb0 [drm]
[   24.388722]  [<c1001a68>] ? __switch_to+0x288/0x2b0
[   24.388741]  [<f8bdabb0>] ? drm_version+0x90/0x90 [drm]
[   24.388756]  [<c10e8eae>] do_vfs_ioctl+0x7e/0x570
[   24.388769]  [<c10dabdc>] ? vfs_write+0xfc/0x140
[   24.388786]  [<c114bd22>] ? tomoyo_file_ioctl+0x12/0x20
[   24.388796]  [<c10e940f>] sys_ioctl+0x6f/0x80
[   24.388808]  [<c12fff50>] sysenter_do_call+0x12/0x26
[   24.388817] ---[ end trace d244b8b3431a8a36 ]---
[   24.393788] [drm:intel_update_fbc],
[   24.393797] ------------[ cut here ]------------
[   24.393827] WARNING: at drivers/gpu/drm/i915/intel_display.c:963 assert_plane+0x70/0x80 [i915]()
[   24.393835] Hardware name: LIFEBOOK S Series
[   24.393842] plane B assertion failure (expected off, current on)
[   24.393847] Modules linked in: binfmt_misc fuse loop firewire_sbp2 i915 snd_intel8x0 snd_ac97_codec drm_kms_helper drm ac97_bus snd_pcm psmouse pcmcia snd_seq acpi_cpufreq yenta_socket snd_timer snd_seq_device snd microcode apanel pcspkr pcmcia_rsrc input_polldev evdev mperf i2c_algo_bit video processor fujitsu_laptop thermal_sys i2c_i801 i2c_core rng_core soundcore snd_page_alloc pcmcia_core shpchp led_class serio_raw pci_hotplug battery button ac ext3 jbd mbcache usbhid hid sg sr_mod sd_mod cdrom ata_generic ata_piix firewire_ohci uhci_hcd libata 8139too 8139cp scsi_mod usbcore firewire_core crc_itu_t mii usb_common [last unloaded: scsi_wait_scan]
[   24.393959] Pid: 984, comm: Xorg Tainted: G        W    3.4.0 #3
[   24.393966] Call Trace:
[   24.393976]  [<c102a3bd>] warn_slowpath_common+0x6d/0xa0
[   24.394006]  [<f8dc37f0>] ? assert_plane+0x70/0x80 [i915]
[   24.394034]  [<f8dc37f0>] ? assert_plane+0x70/0x80 [i915]
[   24.394045]  [<c102a46e>] warn_slowpath_fmt+0x2e/0x30
[   24.394073]  [<f8dc37f0>] assert_plane+0x70/0x80 [i915]
[   24.394103]  [<f8dc6d6b>] intel_crtc_disable+0x5b/0xa0 [i915]
[   24.394116]  [<f8c282ef>] drm_helper_disable_unused_functions+0xef/0x140 [drm_kms_helper]
[   24.394146]  [<f8dc8090>] intel_release_load_detect_pipe+0xd0/0xf0 [i915]
[   24.394177]  [<f8dcfb3b>] intel_crt_detect+0x2ab/0x6c0 [i915]
[   24.394192]  [<f8c29358>] drm_helper_probe_single_connector_modes+0x248/0x310 [drm_kms_helper]
[   24.394216]  [<f8be8387>] drm_mode_getconnector+0x2f7/0x350 [drm]
[   24.394230]  [<c10a94a2>] ? get_page_from_freelist+0x262/0x500
[   24.394250]  [<f8bdae32>] drm_ioctl+0x282/0x550 [drm]
[   24.394272]  [<f8be8090>] ? drm_mode_getencoder+0xb0/0xb0 [drm]
[   24.394284]  [<c1001a68>] ? __switch_to+0x288/0x2b0
[   24.394303]  [<f8bdabb0>] ? drm_version+0x90/0x90 [drm]
[   24.394314]  [<c10e8eae>] do_vfs_ioctl+0x7e/0x570
[   24.394325]  [<c10dabdc>] ? vfs_write+0xfc/0x140
[   24.394336]  [<c114bd22>] ? tomoyo_file_ioctl+0x12/0x20
[   24.394347]  [<c10e940f>] sys_ioctl+0x6f/0x80
[   24.394357]  [<c12fff50>] sysenter_do_call+0x12/0x26
[   24.394365] ---[ end trace d244b8b3431a8a37 ]---
[   24.400057] i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
[   24.400069] i2c i2c-3: master_xfer[1] R, addr=0x50, len=1
[   24.400317] i2c i2c-3: NAK from device addr 0x50 msg #0
[   24.400354] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus vga
[   24.400403] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] probed modes :
[   24.400415] [drm:drm_mode_debug_printmodeline], Modeline 20:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[   24.400433] [drm:drm_mode_debug_printmodeline], Modeline 18:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
[   24.400451] [drm:drm_mode_debug_printmodeline], Modeline 17:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
[   24.400468] [drm:drm_mode_debug_printmodeline], Modeline 19:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
[   24.400484] [drm:drm_mode_debug_printmodeline], Modeline 16:"640x480" 60 25175 640 656 752 800 480 489 492 525 0x40 0xa
[   24.400529] [drm:drm_mode_getconnector], [CONNECTOR:5:?]
[   24.401228] [drm:drm_mode_getconnector], [CONNECTOR:8:?]
[   24.401241] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:DVI-I-1]
[   24.401257] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[   24.401267] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[   24.401503] i2c i2c-6: NAK from device addr 0x38 msg #0
[   24.401539] [drm:ns2501_readb], Unable to read register 0x09 from i915 gmbus dpb:38.
[   24.401556] i2c i2c-5: master_xfer[0] W, addr=0x50, len=1
[   24.401566] i2c i2c-5: master_xfer[1] R, addr=0x50, len=1
[   24.401800] i2c i2c-5: NAK from device addr 0x50 msg #0
[   24.401835] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus dpc
[   24.401862] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:DVI-I-1] probed modes :
[   24.401873] [drm:drm_mode_debug_printmodeline], Modeline 13:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[   24.401890] [drm:drm_mode_debug_printmodeline], Modeline 11:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
[   24.401907] [drm:drm_mode_debug_printmodeline], Modeline 10:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
[   24.401924] [drm:drm_mode_debug_printmodeline], Modeline 12:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
[   24.401941] [drm:drm_mode_debug_printmodeline], Modeline 9:"640x480" 60 25175 640 656 752 800 480 489 492 525 0x40 0xa
[   24.401964] [drm:drm_mode_getconnector], [CONNECTOR:8:?]
[   24.544577] [drm:drm_mode_addfb], [FB:21]
[   24.544686] [drm:drm_mode_setcrtc], [CRTC:3]
[   24.544704] [drm:drm_mode_setcrtc], [CONNECTOR:5:VGA-1]
[   24.544714] [drm:drm_mode_setcrtc], [CONNECTOR:8:DVI-I-1]
[   24.544723] [drm:drm_crtc_helper_set_config],
[   24.544731] [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:21] #connectors=2 (x y) (0 0)
[   24.544754] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set
[   24.544764] [drm:drm_crtc_helper_set_config], encoder changed, full mode switch
[   24.544772] [drm:drm_crtc_helper_set_config], encoder changed, full mode switch
[   24.544780] [drm:drm_crtc_helper_set_config], crtc changed, full mode switch
[   24.544789] [drm:drm_crtc_helper_set_config], [CONNECTOR:5:VGA-1] to [CRTC:3]
[   24.544799] [drm:drm_crtc_helper_set_config], crtc changed, full mode switch
[   24.544808] [drm:drm_crtc_helper_set_config], [CONNECTOR:8:DVI-I-1] to [CRTC:3]
[   24.544818] [drm:drm_crtc_helper_set_config], attempting to set mode from userspace
[   24.544827] [drm:drm_mode_debug_printmodeline], Modeline 22:"1024x768" 0 65000 1024 1048 1184 1344 768 771 777 806 0x0 0xa
[   24.544850] [drm:drm_crtc_helper_set_mode], [CRTC:3]
[   24.544871] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[   24.544881] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[   24.545123] i2c i2c-6: NAK from device addr 0x38 msg #0
[   24.545159] [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.
[   24.552562] [drm:i9xx_crtc_mode_set], Mode for pipe A:
[   24.552571] [drm:drm_mode_debug_printmodeline], Modeline 22:"1024x768" 0 65000 1024 1048 1184 1344 768 771 777 806 0x0 0xa
[   24.611649] [drm:i9xx_update_plane], Writing base 00400000 00000000 0 0 4096
[   24.611672] [drm:intel_update_fbc],
[   24.611683] [drm:i830_get_fifo_size], FIFO size - (0x00017e5f) A: 47
[   24.611693] [drm:intel_calculate_wm], FIFO entries required for mode: 41
[   24.611702] [drm:intel_calculate_wm], FIFO watermark level: 4
[   24.611710] [drm:i830_update_wm], Setting FIFO watermarks - A: 4
[   24.611725] [drm:drm_crtc_helper_set_mode], [ENCODER:6:DAC-6] set [MODE:22:1024x768]
[   24.611738] [drm:drm_crtc_helper_set_mode], [ENCODER:7:None-7] set [MODE:22:1024x768]
[   24.611752] [drm:i830_get_fifo_size], FIFO size - (0x00017e5f) A: 47
[   24.611762] [drm:intel_calculate_wm], FIFO entries required for mode: 41
[   24.611770] [drm:intel_calculate_wm], FIFO watermark level: 4
[   24.611778] [drm:i830_update_wm], Setting FIFO watermarks - A: 4
[   24.612293] [drm:intel_update_fbc],
[   24.612315] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[   24.612325] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[   24.618118] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on
[   24.618138] [drm:drm_crtc_helper_set_config],        [CONNECTOR:5:VGA-1] set DPMS on
[   24.618150] [drm:drm_crtc_helper_set_config],        [CONNECTOR:8:DVI-I-1] set DPMS on
[   24.618166] ------------[ cut here ]------------
[   24.618232] WARNING: at drivers/gpu/drm/i915/intel_display.c:963 assert_plane+0x70/0x80 [i915]()
[   24.618240] Hardware name: LIFEBOOK S Series
[   24.618247] plane B assertion failure (expected off, current on)
[   24.618253] Modules linked in: binfmt_misc fuse loop firewire_sbp2 i915 snd_intel8x0 snd_ac97_codec drm_kms_helper drm ac97_bus snd_pcm psmouse pcmcia snd_seq acpi_cpufreq yenta_socket snd_timer snd_seq_device snd microcode apanel pcspkr pcmcia_rsrc input_polldev evdev mperf i2c_algo_bit video processor fujitsu_laptop thermal_sys i2c_i801 i2c_core rng_core soundcore snd_page_alloc pcmcia_core shpchp led_class serio_raw pci_hotplug battery button ac ext3 jbd mbcache usbhid hid sg sr_mod sd_mod cdrom ata_generic ata_piix firewire_ohci uhci_hcd libata 8139too 8139cp scsi_mod usbcore firewire_core crc_itu_t mii usb_common [last unloaded: scsi_wait_scan]
[   24.618385] Pid: 984, comm: Xorg Tainted: G        W    3.4.0 #3
[   24.618393] Call Trace:
[   24.618413]  [<c102a3bd>] warn_slowpath_common+0x6d/0xa0
[   24.618442]  [<f8dc37f0>] ? assert_plane+0x70/0x80 [i915]
[   24.618471]  [<f8dc37f0>] ? assert_plane+0x70/0x80 [i915]
[   24.618482]  [<c102a46e>] warn_slowpath_fmt+0x2e/0x30
[   24.618510]  [<f8dc37f0>] assert_plane+0x70/0x80 [i915]
[   24.618541]  [<f8dc6d6b>] intel_crtc_disable+0x5b/0xa0 [i915]
[   24.618557]  [<f8c282ef>] drm_helper_disable_unused_functions+0xef/0x140 [drm_kms_helper]
[   24.618571]  [<f8c29c86>] drm_crtc_helper_set_config+0x856/0x9b0 [drm_kms_helper]
[   24.618604]  [<f8be939d>] drm_mode_setcrtc+0x19d/0x530 [drm]
[   24.618628]  [<f8be718c>] ? drm_mode_gamma_set_ioctl+0x7c/0x120 [drm]
[   24.618648]  [<f8bdae32>] drm_ioctl+0x282/0x550 [drm]
[   24.618670]  [<f8be9200>] ? drm_mode_attachmode_ioctl+0x100/0x100 [drm]
[   24.618691]  [<f8bdabb0>] ? drm_version+0x90/0x90 [drm]
[   24.618707]  [<c10e8eae>] do_vfs_ioctl+0x7e/0x570
[   24.618720]  [<c10dabdc>] ? vfs_write+0xfc/0x140
[   24.618736]  [<c114bd22>] ? tomoyo_file_ioctl+0x12/0x20
[   24.618747]  [<c10e940f>] sys_ioctl+0x6f/0x80
[   24.618758]  [<c12fff50>] sysenter_do_call+0x12/0x26
[   24.618767] ---[ end trace d244b8b3431a8a38 ]---
[   24.683151] [drm:i915_driver_irq_handler], pipe A underrun
[   28.858599] uhci_hcd 0000:00:1d.0: reserve dev 2 ep81-INT, period 8, phase 4, 93 us
[   28.883791] apanel 0-0019: uevent
[   29.216055] eth0: no IPv6 routers present
[   29.288450] [drm:intel_crtc_cursor_set],
[   31.553529] sshd (1224): /proc/1224/oom_adj is deprecated, please use /proc/1224/oom_score_adj instead.
(END)
Comment 74 Daniel Vetter 2012-05-29 00:36:03 UTC
> I played with i2cset here and there and could disable and enable the screen
> with register #8, bit #0, but I do not get a usable screen. I do not know
> enough about DVO chips to be of much help as far as the programming is
> concerned.
>
> What else can be done from here that would help you?

Every dvo chip works in a slightly different way, so the next step is
trying to figure out how to program this chip. I guess you could take
another dvo chip that also drives lvds as an example (e.g. ivch or
ch7017). Last time I've checked the patch it does only detect the dvo
chip and doesn't change anything with the modeset within the dvo chip.
So things should work if you use the exact same mode as the bios (and
otherwise you get bands/tearing or just a black screen).
Comment 75 thor 2012-05-29 12:13:12 UTC
Well, I do have a documentation from National Semiconductors, but there is nothing that would define frequencies or bandwidths - only the sync pulses can be set, and intput to syncs. So I played writing values into all other registers with i2cset, but with little success - not any change, actually, except for the mentioned register. Ok, and you could block off the screen as well by disabling the sync pulses (not much of a surprise, I guess).

However, leaving all that aside - I'm no longer able to talk to the chip, upon rebooting i2cdetect gave me all blanks on bus #6. I really wonder what is going on. Could it be that there is some additional "gating" going on that blocks off access to this chip unless another register is set? Is that typical?
Comment 76 Daniel Vetter 2012-05-29 12:20:12 UTC
On Tue, May 29, 2012 at 9:13 PM,  <bugzilla-daemon@freedesktop.org> wrote:
> --- Comment #75 from thor@math.tu-berlin.de 2012-05-29 12:13:12 PDT ---
> Well, I do have a documentation from National Semiconductors, but there is
> nothing that would define frequencies or bandwidths - only the sync pulses can
> be set, and intput to syncs. So I played writing values into all other
> registers with i2cset, but with little success - not any change, actually,
> except for the mentioned register. Ok, and you could block off the screen as
> well by disabling the sync pulses (not much of a surprise, I guess).

Well, most lvds panels have a fixed mode they work at. We fake
different resolutions by using the hw scaler on the gpu's scanout
unit. Still, having a dvo chip without any means to adjust that sounds
a bit strange.

> However, leaving all that aside - I'm no longer able to talk to the chip, upon
> rebooting i2cdetect gave me all blanks on bus #6. I really wonder what is going
> on. Could it be that there is some additional "gating" going on that blocks off
> access to this chip unless another register is set? Is that typical?

We do have some parts of the mmio space that need unlocking, but i2c
devices should always respond. You might need to power cycle the
machine to get it out of limbo though (i.e. yank the battery).
Comment 77 thor 2012-05-29 14:05:28 UTC
Sorry if this sounds like a stupid question - but how come that i2cdetect only
sees one bus when booting with the vga frame buffer, but 7 with the i915drm
module in place? Is there anything I need to do to activate the remaining
busses (not devices! - that will be the next problem - it is also a problem that bus #6 does not always lists the ns2501).

A second remark is that I found that the documentation I have on the ns2501 does not include the registers for the scaler (*sigh*), so that's my fault. I'll see what I can find.
Comment 78 Daniel Vetter 2012-05-29 14:13:48 UTC
> --- Comment #77 from thor@math.tu-berlin.de 2012-05-29 14:05:28 PDT ---
> Sorry if this sounds like a stupid question - but how come that i2cdetect only
> sees one bus when booting with the vga frame buffer, but 7 with the i915drm
> module in place? Is there anything I need to do to activate the remaining
> busses (not devices! - that will be the next problem - it is also a problem
> that bus #6 does not always lists the ns2501).

We expose all the i2c lines that the gpu can drive as normal i2c
buses. Some are used to read the edid from vga connected screens,
others to communicate to dvo chips. Dunno why ns2501 doesn't show up
all the time for you.

> A second remark is that I found that the documentation I have on the ns2501
> does not include the registers for the scaler (*sigh*), so that's my fault.
> I'll see what I can find.

The scaler is on the gpu side. See the funky computations in
intel_lvds_mode_ fixup in intel_lvds.c and all the pfit_ values
computed in there (grep for these to get to the code that uses them).
Comment 79 thor 2012-05-29 14:29:24 UTC
But as the drm module is never loaded, the corresponding i2c devices are not exposed? Can I trigger this process manually without loading the drm module? The idea was to check which values the bios leaves behind, and then install the same (or similar) values.

Concerning the scaler, the 2501 datasheet mentiones that it includes a built-in scaler, though its interface is not described. "OEM manufacturers please contact your NS representative". Hmm. Do you mean that the built-in scaler is present, though its interface is driven by pins that are controlled by the GPU, and thus are not exposed to its own i2c interface?
Comment 80 Gilles Dartiguelongue 2012-05-29 15:14:55 UTC
Actually, last I read this datasheet, it said that we could obtain the programming guide from our local NS vendor. I think that's what we are missing to have a functional driver (like information about timings or order to set registers to get the desired effect).

I managed to have a working X but it was stuck to the same resolution used by the BIOS/bootloader (skipping writing to registers).

If someone wants to pursue NS to get the programming guide, please do.
Time has been a bit missing to me lately.
Comment 81 thor 2012-06-01 06:10:32 UTC
Well, I've got a bit futher:

1) One can get i2c access mostly reliable when the drm.debug option is set high. Thus, whether or not the i2c interface works is likely a matter of timing. Could it be that the bit-banging interface is too critical to reach the chip in all cases? If so, where could one set the timing?

2) I can get a stable picture by using the video bios to write the chip configuration for me. For this, use

$ vbetool post
$ vbetool vbemode set 280

I also performed an i2c dump with and without the mode set through the video bios:

Properly initialized through the video bios:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 05 13 26 67 01 a5 19 a2 35 95 81 ff 03 04 00 00    ??&g????5??.??..
10: 00 a0 02 02 02 02 02 02 07 00 00 11 54 03 02 40    .????????..?T??@
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
30: 00 00 00 00 03 ff 00 44 88 88 00 00 00 00 00 00    ....?..D??......
40: 80 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00    ?..?............
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 11 00 00 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0    ?..?????????????
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00    ..............?.
80: ff 07 3d 05 00 00 00 00 00 00 00 00 10 02 10 00    .?=?........???.
90: ff 07 a0 02 00 00 05 00 00 00 88 00 24 00 25 03    .???..?...?.$.%?
a0: 28 01 28 05 84 00 00 00 00 04 70 4f 00 00 03 03    (?(??....?pO..??
b0: 00 00 00 00 00 00 09 03 00 a0 00 20 33 33 33 33    ......??.?. 3333
c0: 01 90 00 0f 03 16 00 02 02 00 00 00 00 00 00 00    ??.???.??.......
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 1a 00 80 00 00 00 80 00 00 00 00 00 00 00    ..?.?...?.......
f0: 86 eb ca 90 00 00 00 88 0a 00 0a 0a 0a 0a 0a 0a    ????...??.??????

Improperly initialized (initially):
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 05 13 26 67 01 a5 19 a2 31 95 81 ff 03 04 00 00    ??&g????1??.??..
10: 00 a0 02 02 02 02 02 02 07 00 00 11 54 03 02 40    .????????..?T??@
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
30: 00 00 00 00 03 ff 00 28 88 88 00 00 00 00 00 00    ....?..(??......
40: 80 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00    ?..?............
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 11 00 00 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0    ?..?????????????
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00    ..............?.
80: ff 07 3d 05 00 00 00 00 00 00 00 00 10 02 10 00    .?=?........???.
90: ff 07 a0 02 00 00 05 00 00 00 88 00 24 00 25 03    .???..?...?.$.%?
a0: 28 01 28 05 84 00 00 00 00 04 70 4f 00 00 03 03    (?(??....?pO..??
b0: 00 00 00 00 00 00 09 03 00 a0 00 20 33 33 33 33    ......??.?. 3333
c0: 05 90 00 0f 03 16 00 02 02 00 00 00 00 00 00 00    ??.???.??.......
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 1a 00 80 00 00 00 80 00 00 00 00 00 00 00    ..?.?...?.......
f0: 8f 07 58 90 00 00 00 88 0a 00 0a 0a 0a 0a 0a 0a    ??X?...??.??????

Differences are in registers 0x44 and 0xc0 which must contain 0x37 and 0x01, respectively.

Just using i2cset to define these registers alone does not seem to help, though the "screen ripping" looks different. Register 0xc0 seems to be related to the screen scaler, at least bits 7,2 and 0 do have a function, though I do not know which.

With a couple of vbemode calls issued from a remote console, I could play a round of tuxracer. Given that this is a 1Ghz Pentium III, 10 fps are quite acceptable and I believe that this means that this is accelerated video.

So basically, the dvo chip kernel module should "just" call the video bios to set the screen to the proper dimensions, and should then the chip untouched - this might properly work. Of course, you wouldn't have xrandr support with all that as the resolution would stay fixed, but there would be hardware acceleration.
Comment 82 thor 2012-06-03 10:35:15 UTC
Got a step further. What one can do to get a stable picture is simply to disable the scaler.

For this, insert: in dvo_ns2501.c, in the function

static void ns2501_mode_set

the following line:

  ns2501_writeb(dvo, 0x08, NS2501_8_PD | NS2501_8_BPAS | NS2501_8_VEN | NS2501_8_HEN);

ns2501_dpms should also et the NS2501_8_BPAS bit.

Voila, I get a stable console at boot-up, and a 2D desktop. However, something still seems to be seriously broken outside of the control of the DVO driver. As soon as I start an X session, or a 3D application like tuxracer, the display vanishes. At that point, the DVO also vanishes from the i2c bus for reasons unclear to me. A vbetool post restores the i2cbus.

So at least there seems to be something seriously broken with the i2c communication on this board.

It also happenes that I could start the desktop, but something was wrong with EXA as characters were printed on top of each other (overlayed) instead of erased properly. glxgears seemed to work (at least once).

So what is it with the i2c bus on this system?
Comment 83 thor 2012-06-06 18:21:06 UTC
Finally, success!

I'm not quite sure why, but for reasons unclear to me the DVO chip only wants to talk if the PLL is enabled and running and the screen resolution fits. In addition, the system has apparently a "fake" VGA output that must be disabled to have the system working properly. Otherwise, the KMS layer seems to want to redirect the output to the VGA, and then drops dead, leaving an unusable screen (and DVO!) behind. I do not know yet whether the physical VGA connector works, but basically, here is the receipt:

1) Apply the patches I mentioned above. Especially, the bypass mode of the scaler must be set as its function is unclear.

static void ns2501_dpms(struct intel_dvo_device *dvo, int mode)
{
  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
  unsigned char ch;

  DRM_DEBUG_KMS("%s: Trying set the dpms of the DVO to %d\n",__FUNCTION__,mode);

  if (ns->reg_8_set) {
    ch = ns->reg_8_shadow;
  } else {
    ch = NS2501_8_PD | NS2501_8_BPAS | NS2501_8_VEN | NS2501_8_HEN;
  }
    
  if (mode == DRM_MODE_DPMS_ON)
    ch |= NS2501_8_PD;
  else
    ch &= ~NS2501_8_PD;

  ch |= NS2501_8_BPAS;
  
  if (ns->reg_8_set == 0 || ns->reg_8_shadow != ch) {
    ns->reg_8_set    = 1;
    ns->reg_8_shadow = ch;
    ns2501_writeb(dvo, NS2501_REG8, ch);
  }
}

Here I added a shadow register which is likely not exactly necessary, though I wanted to avoid the i2c communication if not necessary.


2) There is still a bug in the ns2501 source in so far as the query function returns something unitialized if reading from the DVO fails. And it fails quite often.

static enum drm_connector_status ns2501_detect(struct intel_dvo_device *dvo)
{
  uint8_t reg9;
  enum drm_connector_status status = connector_status_unknown;
  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);

  DRM_DEBUG_KMS("%s: Trying to detect the connector status\n",__FUNCTION__);


  if (ns2501_readb(dvo, NS2501_REG9, &reg9)) {
    if (!(reg9 & NS2501_9_RSEN))
      status = connector_status_connected;
    else
      status = connector_status_disconnected;

    ns->reg_9_set    = 1;
    ns->reg_9_shadow = reg9;
  } else if (ns->reg_9_set) {
    if (!(ns->reg_9_shadow & NS2501_9_RSEN))
      status = connector_status_connected;
    else
      status = connector_status_disconnected;
  } 
 
  DRM_DEBUG_KMS("%s: Status is %d\n",__FUNCTION__,status);

  return status;
}

Again a shadow register was added.

3) The following kernel arguments should be added to disable the VGA output:

i915.modeset=1 video=VGA-1:1024x768d video=DVI-I-1:1024x768e

I'm not sure why the system behaives so strange otherwise, I'll try to dig a bit deeper, but I believe that there is some limitation with the i830 and its outputs. Probably I'll find a datasheet.

With the above modifications, you cannot, of course, scale the screen (resolution is fixed), though 3D acceleration works nicely.

The same trick might also apply to the IBM R31, I'll check later next week - it had similar issues.

(Is actually anyone reading this??? Is there a better way to supply patches?)
Comment 84 Daniel Vetter 2012-06-07 00:32:02 UTC
On Thu, Jun 7, 2012 at 3:21 AM,  <bugzilla-daemon@freedesktop.org> wrote:
> (Is actually anyone reading this??? Is there a better way to supply patches?)

Well, if you have a patch that works somewhat attaching it to all the
relevant bugzillas is usually a good way to get test feedback.

If the entire thing works reasonably well (which for this old hw
equals 'it works for you somewhat', no high standards), please submit
the complete kernel patch with a nice changelog to the intel-gfx
mailing list so that it can be merged.
-Daniel
Comment 85 thor 2012-06-08 09:06:59 UTC
Now I also got the scaler "pseudo-working" by inspecting which values the vesa BIOS leaves behind in the DVO and just copying these values. By now I can support 640x480, 800x600 and the native resolution, which is here 1024x768. Unfortunately, I do not have the right vesa BIOS data for the latter, and for anything else, so your milage may vary. Also, the scaler support is somehow hacky as the DVO first needs to be turned on by enabling the PLL by poking into the chipset registers (yuck!). It's really a beasty chip.

I will submit the patch to the mailing list later this day, here for your records:

diff -rup linux-3.4.1-orig/drivers/gpu/drm/i915/dvo.h linux-3.4.1/drivers/gpu/drm/i915/dvo.h
--- linux-3.4.1-orig/drivers/gpu/drm/i915/dvo.h	2012-06-01 09:18:44.000000000 +0200
+++ linux-3.4.1/drivers/gpu/drm/i915/dvo.h	2012-06-08 13:15:19.000000000 +0200
@@ -140,5 +140,6 @@ extern struct intel_dvo_dev_ops ch7xxx_o
 extern struct intel_dvo_dev_ops ivch_ops;
 extern struct intel_dvo_dev_ops tfp410_ops;
 extern struct intel_dvo_dev_ops ch7017_ops;
+extern struct intel_dvo_dev_ops ns2501_ops;
 
 #endif /* _INTEL_DVO_H */
diff -rup linux-3.4.1-orig/drivers/gpu/drm/i915/dvo_ns2501.c linux-3.4.1/drivers/gpu/drm/i915/dvo_ns2501.c
--- linux-3.4.1-orig/drivers/gpu/drm/i915/dvo_ns2501.c	2012-06-08 17:59:20.000000000 +0200
+++ linux-3.4.1/drivers/gpu/drm/i915/dvo_ns2501.c	2012-06-08 17:52:21.000000000 +0200
@@ -0,0 +1,544 @@
+/**************************************************************************
+
+Copyright © 2012 Gilles Dartiguelongue, Thomas Richter
+
+All Rights Reserved.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sub license, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial portions
+of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+**************************************************************************/
+
+#include "dvo.h"
+#include "i915_reg.h"
+#include "i915_drv.h"
+
+#define NS2501_VID 0x1305
+#define NS2501_DID 0x6726
+
+#define NS2501_VID_LO 0x00
+#define NS2501_VID_HI 0x01
+#define NS2501_DID_LO 0x02
+#define NS2501_DID_HI 0x03
+#define NS2501_REV 0x04
+#define NS2501_RSVD 0x05
+#define NS2501_FREQ_LO 0x06
+#define NS2501_FREQ_HI 0x07
+
+#define NS2501_REG8 0x08
+#define NS2501_8_VEN (1<<5)
+#define NS2501_8_HEN (1<<4)
+#define NS2501_8_DSEL (1<<3)
+#define NS2501_8_BPAS (1<<2)
+#define NS2501_8_RSVD (1<<1)
+#define NS2501_8_PD (1<<0)
+
+#define NS2501_REG9 0x09
+#define NS2501_9_VLOW (1<<7)
+#define NS2501_9_MSEL_MASK (0x7<<4)
+#define NS2501_9_TSEL (1<<3)
+#define NS2501_9_RSEN (1<<2)
+#define NS2501_9_RSVD (1<<1)
+#define NS2501_9_MDI (1<<0)
+
+#define NS2501_REGC 0x0c
+
+struct ns2501_priv {
+  //I2CDevRec d;
+  bool quiet;
+  int reg_8_shadow;
+  int reg_8_set;
+  // Shadow registers for i915
+  int dvoc;
+  int pll_a;
+  int srcdim;
+  int fw_blc;
+};
+
+#define NSPTR(d) ((NS2501Ptr)(d->DriverPrivate.ptr))
+
+/*
+** Include the PLL launcher prototype
+*/
+extern void intel_enable_pll(struct drm_i915_private *dev_priv, enum pipe pipe);
+
+/*
+** For reasons unclear to me, the ns2501 at least on the Fujitsu/Siemens
+** laptops does not react on the i2c bus unless
+** both the PLL is running and the display is configured in its native
+** resolution.
+** This function forces the DVO on, and stores the registers it touches.
+** Afterwards, registers are restored to regular values.
+**
+** This is pretty much a hack, though it works.
+** Without that, ns2501_readb and ns2501_writeb fail
+** when switching the resolution.
+*/
+
+static void enable_dvo(struct intel_dvo_device *dvo)
+{
+  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
+  struct i2c_adapter *adapter = dvo->i2c_bus;
+  struct intel_gmbus *bus     = container_of(adapter,
+                                             struct intel_gmbus,
+                                             adapter);
+  struct drm_i915_private *dev_priv = bus->dev_priv;
+
+  DRM_DEBUG_KMS("%s: Trying to re-enable the DVO\n",__FUNCTION__);
+
+  ns->dvoc   = I915_READ(DVO_C);
+  ns->pll_a  = I915_READ(_DPLL_A);
+  ns->srcdim = I915_READ(DVOC_SRCDIM);
+  ns->fw_blc = I915_READ(FW_BLC);
+
+  I915_WRITE(DVOC, 0x10004084);
+  I915_WRITE(_DPLL_A,0xd0820000);
+  I915_WRITE(DVOC_SRCDIM,0x400300); // 1024x768
+  I915_WRITE(FW_BLC,0x1080304);     
+
+  intel_enable_pll(dev_priv,0);
+
+  I915_WRITE(DVOC, 0x90004084);
+}
+
+/*
+** Restore the I915 registers modified by the above
+** trigger function.
+*/
+static void restore_dvo(struct intel_dvo_device *dvo)
+{ 
+  struct i2c_adapter *adapter = dvo->i2c_bus;
+  struct intel_gmbus *bus     = container_of(adapter,
+                                             struct intel_gmbus,
+                                             adapter);
+  struct drm_i915_private *dev_priv = bus->dev_priv;
+  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
+
+  I915_WRITE(DVOC       ,ns->dvoc);
+  I915_WRITE(_DPLL_A    ,ns->pll_a);
+  I915_WRITE(DVOC_SRCDIM,ns->srcdim);
+  I915_WRITE(FW_BLC     ,ns->fw_blc);
+}
+
+/*
+** Read a register from the ns2501.
+** Returns true if successful, false otherwise.
+** If it returns false, it might be wise to enable the
+** DVO with the above function.
+*/
+static bool ns2501_readb(struct intel_dvo_device *dvo, int addr, uint8_t *ch)
+{
+  struct ns2501_priv *ns = dvo->dev_priv;
+  struct i2c_adapter *adapter = dvo->i2c_bus;
+  u8 out_buf[2];
+  u8 in_buf[2];
+
+  struct i2c_msg msgs[] = {
+    {
+      .addr = dvo->slave_addr,
+      .flags = 0,
+      .len = 1,
+      .buf = out_buf,
+    },
+    {
+      .addr = dvo->slave_addr,
+      .flags = I2C_M_RD,
+      .len = 1,
+      .buf = in_buf,
+    }
+  };
+
+  out_buf[0] = addr;
+  out_buf[1] = 0;
+
+  if (i2c_transfer(adapter, msgs, 2) == 2) {
+    *ch = in_buf[0];
+    return true;
+  };
+
+  if (!ns->quiet) {
+    DRM_DEBUG_KMS("Unable to read register 0x%02x from %s:0x%02x.\n",
+		  addr, adapter->name, dvo->slave_addr);
+  }
+
+  return false;
+}
+
+/*
+** Write a register to the ns2501.
+** Returns true if successful, false otherwise.
+** If it returns false, it might be wise to enable the
+** DVO with the above function.
+*/
+static bool ns2501_writeb(struct intel_dvo_device *dvo, int addr, uint8_t ch)
+{
+  struct ns2501_priv *ns = dvo->dev_priv;
+  struct i2c_adapter *adapter = dvo->i2c_bus;
+  uint8_t out_buf[2];
+
+  struct i2c_msg msg = {
+    .addr = dvo->slave_addr,
+    .flags = 0,
+    .len = 2,
+    .buf = out_buf,
+  };
+
+  out_buf[0] = addr;
+  out_buf[1] = ch;
+
+  if (i2c_transfer(adapter, &msg, 1) == 1) {
+    return true;
+  }
+
+  if (!ns->quiet) {
+    DRM_DEBUG_KMS("Unable to write register 0x%02x to %s:%d\n",
+                  addr, adapter->name, dvo->slave_addr);
+  }
+
+  return false;
+}
+
+/* National Semiconductor 2501 driver for chip on i2c bus 
+** scan for the chip on the bus.
+** Hope the VBIOS initialized the PLL correctly so we can
+** talk to it. If not, it will not be seen and not detected.
+** Bummer!
+*/
+static bool ns2501_init(struct intel_dvo_device *dvo,
+			struct i2c_adapter *adapter)
+{
+  /* this will detect the NS2501 chip on the specified i2c bus */
+  struct ns2501_priv *ns;
+  unsigned char ch;
+
+  ns = kzalloc(sizeof(struct ns2501_priv), GFP_KERNEL);
+  if (ns == NULL)
+    return false;
+
+  dvo->i2c_bus = adapter;
+  dvo->dev_priv = ns;
+  ns->quiet = true;
+
+  if (!ns2501_readb(dvo, NS2501_VID_LO, &ch))
+    goto out;
+
+  if (ch != (NS2501_VID & 0xff)) {
+    DRM_DEBUG_KMS("ns2501 not detected got %d: from %s Slave %d.\n",
+		  ch, adapter->name, dvo->slave_addr);
+    goto out;
+  }
+
+  if (!ns2501_readb(dvo, NS2501_DID_LO, &ch))
+    goto out;
+
+  if (ch != (NS2501_DID & 0xff)) {
+    DRM_DEBUG_KMS("ns2501 not detected got %d: from %s Slave %d.\n",
+		  ch, adapter->name, dvo->slave_addr);
+    goto out;
+  }
+  ns->quiet        = false;
+  ns->reg_8_set    = 0;
+  ns->reg_8_shadow = NS2501_8_PD | NS2501_8_BPAS | NS2501_8_VEN | NS2501_8_HEN;
+
+  DRM_DEBUG_KMS("init ns2501 dvo controller successfully!\n");
+  return true;
+
+ out:
+  kfree(ns);
+  return false;
+}
+
+static enum drm_connector_status ns2501_detect(struct intel_dvo_device *dvo)
+{
+  /*
+  ** This is a Laptop display, it doesn't have hotplugging.
+  ** Even if not, the detection bit of the 2501 is unreliable as
+  ** it only works for some display types.
+  ** It is even more unreliable as the PLL must be active for
+  ** allowing reading from the chiop.
+  */
+  return connector_status_connected;
+}
+
+static enum drm_mode_status ns2501_mode_valid(struct intel_dvo_device *dvo,
+					      struct drm_display_mode *mode)
+{
+  DRM_DEBUG_KMS("%s: is mode valid (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d)\n",__FUNCTION__,
+		mode->hdisplay,mode->htotal,mode->vdisplay,mode->vtotal);
+
+
+  /*
+  ** Currently, these are all the modes I have data from.
+  ** More might exist. Unclear how to find the native resolution
+  ** of the panel in here so we could always accept it
+  ** by disabling the scaler.
+  */
+  if ((mode->hdisplay == 800 && mode->vdisplay == 600) ||
+      (mode->hdisplay == 640 && mode->vdisplay == 480) ||
+      (mode->hdisplay == 1024 && mode->vdisplay == 768)) {
+    return MODE_OK;
+  } else {
+    return MODE_ONE_SIZE; /* Is this a reasonable error? */
+  }    
+}
+
+static void ns2501_mode_set(struct intel_dvo_device *dvo,
+			    struct drm_display_mode *mode,
+			    struct drm_display_mode *adjusted_mode)
+{
+  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
+
+  DRM_DEBUG_KMS("%s: set mode (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d).\n",__FUNCTION__,
+		mode->hdisplay,mode->htotal,mode->vdisplay,mode->vtotal);
+
+  /*
+  ** Where do I find the native resolution for which scaling is not required???
+  **
+  ** First trigger the DVO on as otherwise the chip does not appear on the i2c
+  ** bus.
+  */
+  enable_dvo(dvo);
+
+  if (mode->hdisplay == 800 && mode->vdisplay == 600) {
+    /* mode 277 */
+    ns->reg_8_shadow &= ~NS2501_8_BPAS;
+    DRM_DEBUG_KMS("%s: switching to 800x600\n",__FUNCTION__);
+
+    /*
+    ** No, I do not know where this data comes from.
+    ** It is just what the video bios left in the DVO, so
+    ** I'm just copying it here over.
+    ** This also means that I cannot support any other modes
+    ** except the ones supported by the bios.
+    */
+    ns2501_writeb(dvo, 0x11, 0xc8);
+    ns2501_writeb(dvo, 0x1b, 0x19);
+    ns2501_writeb(dvo, 0x1c, 0x64);
+    ns2501_writeb(dvo, 0x1d, 0x02);
+
+    ns2501_writeb(dvo, 0x34, 0x03);
+    ns2501_writeb(dvo, 0x35, 0xff);
+
+    ns2501_writeb(dvo, 0x80, 0x27);
+    ns2501_writeb(dvo, 0x81, 0x03);
+    ns2501_writeb(dvo, 0x82, 0x41);
+    ns2501_writeb(dvo, 0x83, 0x05);
+
+    ns2501_writeb(dvo, 0x8d, 0x02);
+    ns2501_writeb(dvo, 0x8e, 0x04);
+    ns2501_writeb(dvo, 0x8f, 0x00);
+
+    ns2501_writeb(dvo, 0x90, 0xff); /* vertical */
+    ns2501_writeb(dvo, 0x91, 0x07);
+    ns2501_writeb(dvo, 0x94, 0x00);
+    ns2501_writeb(dvo, 0x95, 0x00);
+
+    ns2501_writeb(dvo, 0x96, 0x00);
+
+    ns2501_writeb(dvo, 0x99, 0x00);
+    ns2501_writeb(dvo, 0x9a, 0x88);
+
+    ns2501_writeb(dvo, 0x9c, 0x23);
+    ns2501_writeb(dvo, 0x9d, 0x00);
+    ns2501_writeb(dvo, 0x9e, 0x25);
+    ns2501_writeb(dvo, 0x9f, 0x03);
+
+    ns2501_writeb(dvo, 0xa4, 0x80);
+
+    ns2501_writeb(dvo, 0xb6, 0x00);
+
+    ns2501_writeb(dvo, 0xb9, 0xc8); /* horizontal? */
+    ns2501_writeb(dvo, 0xba, 0x00); /* horizontal? */
+
+    ns2501_writeb(dvo, 0xc0, 0x05); /* horizontal? */
+    ns2501_writeb(dvo, 0xc1, 0xd7);
+
+    ns2501_writeb(dvo, 0xc2, 0x00);
+    ns2501_writeb(dvo, 0xc3, 0xf8);
+
+    ns2501_writeb(dvo, 0xc4, 0x03);
+    ns2501_writeb(dvo, 0xc5, 0x1a);
+
+    ns2501_writeb(dvo, 0xc6, 0x00);
+    ns2501_writeb(dvo, 0xc7, 0x73);
+    ns2501_writeb(dvo, 0xc8, 0x02);
+
+  } else if (mode->hdisplay == 640 && mode->vdisplay == 480) {
+    /* mode 274 */
+    DRM_DEBUG_KMS("%s: switching to 640x480\n",__FUNCTION__);
+    /*
+    ** No, I do not know where this data comes from.
+    ** It is just what the video bios left in the DVO, so
+    ** I'm just copying it here over.
+    ** This also means that I cannot support any other modes
+    ** except the ones supported by the bios.
+    */
+    ns->reg_8_shadow &= ~NS2501_8_BPAS;   
+
+    ns2501_writeb(dvo, 0x11, 0xa0);
+    ns2501_writeb(dvo, 0x1b, 0x11);
+    ns2501_writeb(dvo, 0x1c, 0x54);
+    ns2501_writeb(dvo, 0x1d, 0x03);
+
+    ns2501_writeb(dvo, 0x34, 0x03);
+    ns2501_writeb(dvo, 0x35, 0xff);
+
+    ns2501_writeb(dvo, 0x80, 0xff);
+    ns2501_writeb(dvo, 0x81, 0x07);
+    ns2501_writeb(dvo, 0x82, 0x3d);
+    ns2501_writeb(dvo, 0x83, 0x05);
+
+    ns2501_writeb(dvo, 0x8d, 0x02);
+    ns2501_writeb(dvo, 0x8e, 0x10);
+    ns2501_writeb(dvo, 0x8f, 0x00);
+
+    ns2501_writeb(dvo, 0x90, 0xff); /* vertical */
+    ns2501_writeb(dvo, 0x91, 0x07);
+    ns2501_writeb(dvo, 0x94, 0x00);
+    ns2501_writeb(dvo, 0x95, 0x00);
+
+    ns2501_writeb(dvo, 0x96, 0x05);
+
+    ns2501_writeb(dvo, 0x99, 0x00);
+    ns2501_writeb(dvo, 0x9a, 0x88);
+
+    ns2501_writeb(dvo, 0x9c, 0x24);
+    ns2501_writeb(dvo, 0x9d, 0x00);
+    ns2501_writeb(dvo, 0x9e, 0x25);
+    ns2501_writeb(dvo, 0x9f, 0x03);
+
+    ns2501_writeb(dvo, 0xa4, 0x84);
+
+    ns2501_writeb(dvo, 0xb6, 0x09);
+
+    ns2501_writeb(dvo, 0xb9, 0xa0); /* horizontal? */
+    ns2501_writeb(dvo, 0xba, 0x00); /* horizontal? */
+
+    ns2501_writeb(dvo, 0xc0, 0x05); /* horizontal? */
+    ns2501_writeb(dvo, 0xc1, 0x90);
+
+    ns2501_writeb(dvo, 0xc2, 0x00);
+    ns2501_writeb(dvo, 0xc3, 0x0f);
+
+    ns2501_writeb(dvo, 0xc4, 0x03);
+    ns2501_writeb(dvo, 0xc5, 0x16);
+
+    ns2501_writeb(dvo, 0xc6, 0x00);
+    ns2501_writeb(dvo, 0xc7, 0x02);
+    ns2501_writeb(dvo, 0xc8, 0x02);
+
+  } else if (mode->hdisplay == 1024 && mode->vdisplay == 768) {
+    /* mode 280 */ 
+    DRM_DEBUG_KMS("%s: switching to 1024x768\n",__FUNCTION__);
+    /*
+    ** This might or might not work, actually. I'm silently
+    ** assuming here that the native panel resolution is
+    ** 1024x768. If not, then this leaves the scaler disabled
+    ** generating a picture that is likely not the expected.
+    **
+    ** Problem is that I do not know where to take the panel
+    ** dimensions from.
+    **
+    ** Enable the bypass, scaling not required. 
+    **
+    ** The scaler registers are irrelevant here....
+    **
+    */
+    ns->reg_8_shadow |= NS2501_8_BPAS;
+    ns2501_writeb(dvo, 0x37, 0x44);
+  } else {
+    /* Data not known. Bummer! 
+    ** Hopefully, the code should not go here
+    ** as mode_OK delivered no other modes.
+    */
+    ns->reg_8_shadow |= NS2501_8_BPAS;
+  }
+  ns2501_writeb(dvo, NS2501_REG8, ns->reg_8_shadow); 
+
+  /*
+  ** Restore the old i915 registers before
+  ** forcing the ns2501 on.
+  */
+  restore_dvo(dvo);
+}
+
+/* set the NS2501 power state */
+static void ns2501_dpms(struct intel_dvo_device *dvo, int mode)
+{
+  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
+  unsigned char ch;
+
+  DRM_DEBUG_KMS("%s: Trying set the dpms of the DVO to %d\n",__FUNCTION__,mode);
+
+  ch = ns->reg_8_shadow;
+  
+  if (mode == DRM_MODE_DPMS_ON)
+    ch |= NS2501_8_PD;
+  else
+    ch &= ~NS2501_8_PD;
+
+  if (ns->reg_8_set == 0 || ns->reg_8_shadow != ch) {
+    ns->reg_8_set    = 1;
+    ns->reg_8_shadow = ch;
+    ns2501_writeb(dvo, NS2501_REG8, ch);
+  }
+  /*
+  ** Note that this may actually fail,namely exactly
+  ** when the chip vanished from the bus.
+  **
+  ** Should I force-enable it here??
+  */
+}
+
+static void ns2501_dump_regs(struct intel_dvo_device *dvo)
+{
+  uint8_t val;
+
+  ns2501_readb(dvo, NS2501_FREQ_LO, &val);
+  DRM_LOG_KMS("NS2501_FREQ_LO: 0x%02x\n", val);
+  ns2501_readb(dvo, NS2501_FREQ_HI, &val);
+  DRM_LOG_KMS("NS2501_FREQ_HI: 0x%02x\n", val);
+  ns2501_readb(dvo, NS2501_REG8, &val);
+  DRM_LOG_KMS("NS2501_REG8: 0x%02x\n", val);
+  ns2501_readb(dvo, NS2501_REG9, &val);
+  DRM_LOG_KMS("NS2501_REG9: 0x%02x\n", val);
+  ns2501_readb(dvo, NS2501_REGC, &val);
+  DRM_LOG_KMS("NS2501_REGC: 0x%02x\n", val);
+}
+
+static void ns2501_destroy(struct intel_dvo_device *dvo)
+{
+  struct ns2501_priv *ns = dvo->dev_priv;
+
+  if (ns) {
+    kfree(ns);
+    dvo->dev_priv = NULL;
+  }
+}
+
+struct intel_dvo_dev_ops ns2501_ops = {
+  .init = ns2501_init,
+  .detect = ns2501_detect,
+  .mode_valid = ns2501_mode_valid,
+  .mode_set = ns2501_mode_set,
+  .dpms = ns2501_dpms,
+  .dump_regs = ns2501_dump_regs,
+  .destroy = ns2501_destroy,
+};

diff -rup linux-3.4.1-orig/drivers/gpu/drm/i915/intel_display.c linux-3.4.1/drivers/gpu/drm/i915/intel_display.c
--- linux-3.4.1-orig/drivers/gpu/drm/i915/intel_display.c	2012-06-01 09:18:44.000000000 +0200
+++ linux-3.4.1/drivers/gpu/drm/i915/intel_display.c	2012-06-08 16:55:20.000000000 +0200
@@ -1142,7 +1142,7 @@ static void assert_pch_ports_disabled(st
  *
  * Note!  This is for pre-ILK only.
  */
-static void intel_enable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
+void intel_enable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
 	int reg;
 	u32 val;

diff -rup linux-3.4.1-orig/drivers/gpu/drm/i915/intel_dvo.c linux-3.4.1/drivers/gpu/drm/i915/intel_dvo.c
--- linux-3.4.1-orig/drivers/gpu/drm/i915/intel_dvo.c	2012-06-01 09:18:44.000000000 +0200
+++ linux-3.4.1/drivers/gpu/drm/i915/intel_dvo.c	2012-06-08 12:50:16.000000000 +0200
@@ -37,6 +37,7 @@
 #define SIL164_ADDR	0x38
 #define CH7xxx_ADDR	0x76
 #define TFP410_ADDR	0x38
+#define NS2501_ADDR     0x38
 
 static const struct intel_dvo_device intel_dvo_devices[] = {
 	{
@@ -61,6 +62,13 @@ static const struct intel_dvo_device int
 		.dev_ops = &ivch_ops,
 	},
 	{
+	        .type = INTEL_DVO_CHIP_TMDS,
+	        .name = "ns2501",
+	        .dvo_reg = DVOC,
+	        .slave_addr = NS2501_ADDR,
+	        .dev_ops = &ns2501_ops,
+	},
+	{
 		.type = INTEL_DVO_CHIP_TMDS,
 		.name = "tfp410",
 		.dvo_reg = DVOC,

diff -rup linux-3.4.1-orig/drivers/gpu/drm/i915/Makefile linux-3.4.1/drivers/gpu/drm/i915/Makefile
--- linux-3.4.1-orig/drivers/gpu/drm/i915/Makefile	2012-06-01 09:18:44.000000000 +0200
+++ linux-3.4.1/drivers/gpu/drm/i915/Makefile	2012-06-08 12:50:54.000000000 +0200
@@ -34,7 +34,8 @@ i915-y := i915_drv.o i915_dma.o i915_irq
 	  dvo_ch7017.o \
 	  dvo_ivch.o \
 	  dvo_tfp410.o \
-	  dvo_sil164.o
+	  dvo_sil164.o \
+	  dvo_ns2501.o
 
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
Comment 86 thor 2012-06-27 00:17:50 UTC
Now two weeks passed, I submitted five versions for a patch of this bug to the mailing list, one here in public, yet nothing shows up in the official git repository at all.

Is it just me or is nobody actually interested in getting this working?
Comment 87 Daniel Vetter 2012-06-27 02:08:17 UTC
(In reply to comment #86)
> Now two weeks passed, I submitted five versions for a patch of this bug to the
> mailing list, one here in public, yet nothing shows up in the official git
> repository at all.
> 
> Is it just me or is nobody actually interested in getting this working?

I've replied to your last submission I've seen (Msg-Id: <4FE20B5F.7090502@math.tu-berlin.de>) that the patch is still whitespace mangled. Please simply resubmit the patch (as an attachment, your mailer seem to eat patches).
Comment 88 Florian Mickler 2012-10-15 20:54:03 UTC
A patch referencing this bug report has been merged in Linux v3.7-rc1:

commit 7434a255a5cf42819b7e42377f18aaa02f6be52b
Author: Thomas Richter <thor@math.tu-berlin.de>
Date:   Wed Jul 18 19:22:30 2012 +0200

    drm/i915: Support for ns2501-DVO
Comment 89 Cool Loki 2012-11-09 10:46:12 UTC
Please help!
Here's my rom_loki.bin
have it listed two displays
NA-2501
CH-7009-A
how to solve this problem
Comment 90 Cool Loki 2012-11-09 10:47:45 UTC
Created attachment 69801 [details]
rom_loki.bin
Comment 91 Cool Loki 2012-11-09 10:49:01 UTC
Created attachment 69802 [details]
intel_drm_dumper
Comment 92 Cool Loki 2012-11-09 10:50:53 UTC
Created attachment 69803 [details]
lspci -v

My laptop model: Fujitsu Siemens FMV-610NU2
Comment 93 Cool Loki 2012-11-09 11:06:24 UTC
Created attachment 69804 [details]
dmesg.txt

dmseg.txt
kernel 3.7.0-rc4
Comment 94 Daniel Vetter 2012-11-09 19:51:48 UTC
Loki, if you have a regression with i830M dvo support, please file a new bug report. If it's just lack of support for a specific DVO chipset, we can't really help you.