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.
Created attachment 19368 [details] xorg.conf
Created attachment 19370 [details] output of intel_reg_dumper running the 1.7.4 version of the driver
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
Created attachment 19436 [details] Video ROM Here it is.
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"
Created attachment 20555 [details] xorg.conf with Option "ModeDebug" "yes"
Created attachment 20556 [details] Xorg.0.log with only the internal TFT display attached
Created attachment 20557 [details] Xorg.0.log using both the internal TFT and an external 1600x1200 VGA display
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.
Created attachment 20558 [details] Output of intel_reg_dumper using internal TFT and external VGA displays.
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
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.
Created attachment 20559 [details] The video ROM of the graphics chipset.
This seems to be the same as bug 11148 which has been marked as a duplicate of bug 13722.
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
Created attachment 20570 [details] output of intel_reg_dumper with only internal TFT display and framebuffer driver
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.
Created attachment 20571 [details] output of intel_reg_dumper with framebuffer driving internal TFT and external VGA
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...
Created attachment 20686 [details] Xorg.0.log for the S6010 with the old i810 driver running Knoppix 5.1.1
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?
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.
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.
Created attachment 24677 [details] Xorg.0.log with external display attached and using a Fedora 11 beta Live CD
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.
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).
Oh and I don't think I'll be doing this. I don't have any test hardware for it.
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?
How is the framebuffer setting up the DVO LVDS transmitter chip? Is it using the Video BIOS or not?
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?
Created attachment 26888 [details] Fujitsu Stylistic ST4110 Video ROM Here is the video rom image for my fujitsu stylistic st4110.
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.
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.
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.
*** Bug 22699 has been marked as a duplicate of this bug. ***
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 :)
(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.
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.
(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-
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.
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.
*** Bug 23432 has been marked as a duplicate of this bug. ***
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
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.
(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.
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?
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.
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.
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.
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.
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.
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.
Created attachment 34807 [details] Xorg.0.log using intel driver and ns2501 patch
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
Created attachment 34808 [details] xorg.conf using the intel driver
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?
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.
Created attachment 34840 [details] Xorg.0.log with Option "ModeDebug" "true"
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?
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.
Reassigning to the community. If someone can find docs for this, writing support shouldn't be too hard.
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.
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).
Thanks for working on this Gilles. I wish I could help.
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.
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 ?
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.
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.
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.
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.
*** Bug 50303 has been marked as a duplicate of this bug. ***
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?
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)
> 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).
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?
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).
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 #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).
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?
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.
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.
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?
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, ®9)) { 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?)
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
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
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?
(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).
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
Please help! Here's my rom_loki.bin have it listed two displays NA-2501 CH-7009-A how to solve this problem
Created attachment 69801 [details] rom_loki.bin
Created attachment 69802 [details] intel_drm_dumper
Created attachment 69803 [details] lspci -v My laptop model: Fujitsu Siemens FMV-610NU2
Created attachment 69804 [details] dmesg.txt dmseg.txt kernel 3.7.0-rc4
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.