[i830] [Needs DVO-LVDS] Installer unable to launch Xorg on Fujitsu Stylistic ST4120PW

Created an attachment (id=19368)
xorg.conf

Created an attachment (id=19370)
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 an attachment (id=19436)
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 an attachment (id=20555)
xorg.conf with Option "ModeDebug" "yes"

Created an attachment (id=20556)
Xorg.0.log with only the internal TFT display attached

Created an attachment (id=20557)
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 an attachment (id=20558)
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 an attachment (id=20559)
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 an attachment (id=20570)
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 an attachment (id=20571)
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 an attachment (id=20686)
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 an attachment (id=24677)
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?

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
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 disabl...

> 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, <email address hidden> wrote:
> --- Comment #75 from <email address hidden> 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 <email address hidden> 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 def...

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, &reg9)) {
    if (!(reg9 & NS2501_9_RSEN))
      status = connector_status_connected;
    else
      status = connector_status_disconnected;

    ns->reg_9_set = 1;
    ns->reg_9_shadow = reg9;
  } else if (ns->reg_9_set) {
    if (!(ns->reg_9_shadow & NS2501_9_RSEN))
      status = connector_status_connected;
    else
      status = connector_status_disconnected;
  }

  DRM_DEBUG_KMS("%s: Status is %d\n",__FUNCTION__,status);

  return status;
}

Again a shadow register was added.

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

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

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

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

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

(Is actually anyone reading this??? Is there a better way to supply patches?)

On Thu, Jun 7, 2012 at 3:21 AM, <email address hidden> 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 NS250...

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: <email address hidden>) 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 <email address hidden>
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
rom_loki.bin

Created attachment 69802
intel_drm_dumper

Created attachment 69803
lspci -v

My laptop model: Fujitsu Siemens FMV-610NU2

Created attachment 69804
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.