[Openchrome-users] [openChrome] #288: openchrome interferes with b43

[OpenChrome Trac]

#288: openchrome interferes with b43
--------------------+-------------------------------------------------------
 Reporter:  ljacob  |        Owner:  jnettlet      
     Type:  defect  |       Status:  assigned      
 Priority:  major   |    Component:  initialization
  Version:  trunk   |   Resolution:                
 Keywords:          |     Blocking:  261           
Blockedby:          |  
--------------------+-------------------------------------------------------

Comment(by fhn):

 Since Register 2A of Port 3C5 seems to cause the trouble i did some more
 investigations on it this morning.

 To show what i've found i executed the following commands via ssh right
 after a fresh reboot with X (kdm) running on a 2.6.30 kernel. My screen is
 the 1280x768 pixel version.

 `root at mini:> inb 0x3C4    #check which register is active`[[br]]
 `0x00`[[br]]
 `root at mini:> outb 0x3C4 0x2a #i want to acess register 2A`[[br]]
 `root at mini:> inb 0x3C4       #check if it got set`[[br]]
 `0x2A`[[br]]
 `root at mini:> inb 0x3C5       #get current value of 2A`[[br]]
 `0x03                        #LVDS Ch1 power controlled by PMS, Ch2 always
 off`[[br]]
 `root at mini:> outb 0x3C5 0x03 #write back currently active value: wireless
 still works`[[br]]
 `root at mini:> outb 0x3C5 0x00 #set LVDS pads off: screen does funny things
 (1), wireless works`[[br]]
 `root at mini:> outb 0x3C5 0x03 #write back old value: screen shows X again,
 wireless works`[[br]]
 `root at mini:> outb 0x3C5 0x0f #activate LVDS Ch2: wireless stops working
 (2),  screen normal`[[br]]
 `root at mini:> inb 0x3C4       #make sure that we still work on register
 2A`[[br]]
 `0x2A`[[br]]
 `root at mini:> outb 0x3C5 0x03 #restore old value of 2A: wireless is still
 dead, screen normal`[[br]]
 `root at mini:> inb 0x3C4       #again check we wrote to 2A`[[br]]
 `0x2A`

 (1) "funny things" means the screen shows a completely black image (with
 backlight on of course) for about 1 second, then switches to a dark grey,
 after another second it shows a light grey, then white, red, green, blue
 and then it starts again with black.
 This would be a very nice feauture if you want to test for dead pixels. (I
 have none ;) )

 (2) "lspci -d 14e4:4312 -x" shows all ff's


 So after a fresh reboot and starting X 0x3C4 points to 0x00, which is the
 Reset register. This may indicate that either nobody did write to port 3C5
 until now or the last action accessed the Reset register. I have no clue
 if this could be a hint later on.

 The interesting thing is the fact that the wireless card stops working
 once i enabled the second LVDS Channel. I don't know what the display link
 has to do with the wireless chip, but maybe we should simply keep Ch2
 switched off for now. (This is what my previous patch already does.)
 In fact this seems to be exatly what Yuval found:
 http://wiki.openchrome.org/pipermail/openchrome-
 devel/2008-November/000139.html
 He commented the line which activated both channels and due to the fact
 that the curret openchrome code contains the mask 0x0F instead of 0xF0
 (point 1 of my last post) the channels don't get disabled so there is no
 need to re-enable them.


 Call for help:[[br]]
 1.) Someone has to clarify if we actually need the LVDS Ch2 on another
 hardware. I definitely need the help of someone with more insight here.
 Perhaps we can somehow detect which channels are used?[[br]]
 2.) It's still a mystery why the display interface has an impact on the
 WLAN. Apparently this is not driver related since it does not matter
 whether the WLAN driver is loaded or not.
 I intended to measure the supply voltages of the wireless chip but there
 seems to be no way of accessing the wlan board without moving the whole
 laptop into another casing.

-- 
Ticket URL: <http://www.openchrome.org/trac/ticket/288#comment:20>
openChrome <http://www.openchrome.org/>
The openChrome project