[Openchrome-users] [openChrome] #288: openchrome interferes with PCI-Express (was: openchrome interferes with b43)

[OpenChrome Trac]

#288: openchrome interferes with PCI-Express
--------------------+-------------------------------------------------------
 Reporter:  ljacob  |        Owner:  jnettlet      
     Type:  defect  |       Status:  assigned      
 Priority:  major   |    Component:  initialization
  Version:  trunk   |   Resolution:                
 Keywords:          |     Blocking:  261           
Blockedby:          |  
--------------------+-------------------------------------------------------
Changes (by stuge):

 * cc: peter at stuge.se (added)


Comment:

 This has nothing to do with b43. (But if there had been no post about this
 on that list back in November I wouldn't have seen the issue. :)

 The chipset in the Mini-Note 2133, VIA CN896, supports among many other
 things PCI-Express (PCIe) and two digital video outputs, DVP1 and DVP2.

 DVP1 is multiplexed with PCIe, for easy support also of discrete PCIe
 graphics. DVP1 is intended to drive LVDS (internal LCD panel) or DVI. DVP2
 is intended to drive TV-out, but can also be configured to drive DVI.

 A patch which appears to resolve the issue was proposed in
 http://www.openchrome.org/trac/ticket/288#comment:17 but there was some
 uncertainty as to whether it is actually an appropriate fix.

 That patch does two things; it changes how the extended sequencer register
 0x2A is being masked, and it then comments out the call to the code which
 was just fixed.

 Per http://www.x.org/docs/via/OGPM_Chrome9%20HC3_R100a_Part1_Core_2D.pdf
 page 36 (30 in the footer) the extended sequencer register 0x2A, "Power
 Management Control 5", has two reserved bits, one of which is read only.
 Without the patch, these two bits were written and the bit which was read-
 write could very possibly end up being changed.

 It is an ABSOLUTE no-no to change the value of a reserved bit!

 The only time this can be safe is if you happen to be the chip designer,
 and you actually know what the bit does. If you can, please document it in
 that case.

 The first hunk of the patch is correct and a good fix. It was committed as
 r746 on 2009-04-25. From the comments in the code and the register
 description in the above PDF it is clear that this was a simple mistake in
 the driver.

 This change could certainly be enough to solve the problem, because
 writing to just one single reserved bit can really have any effect
 whatsoever on the system, and in particular because DVP1 is so "near" PCIe
 in this chipset it's totally possible that this bit causes the PCIe
 problems that were observed.

 The committed fix is safe for any board configuration, using any
 combination of DVP1 and DVP2.

 I would expect r746 to solve this issue. Can anyone confirm whether the
 issue still remains?

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