#1671 NORM Gen2: DCON2 wishlist

[Zarro Boogs per Child]

#1671: DCON2 wishlist
-----------------------------------+----------------------------------------
           Reporter:  ajax         |       Owner:  mlj   
               Type:  enhancement  |      Status:  closed
           Priority:  normal       |   Milestone:  Gen2  
          Component:  hardware     |     Version:        
         Resolution:  fixed        |    Keywords:        
        Next_action:  never set    |    Verified:  0     
Deployment_affected:               |   Blockedby:        
           Blocking:               |  
-----------------------------------+----------------------------------------
Changes (by wad):

  * status:  assigned => closed
  * next_action:  => never set
  * resolution:  => fixed


Comment:

 As I work on the specifications for the next DCON, I feel compelled to
 reply to this ticket's comments (before closing it):

 "The current DCONLOAD semantics are just broken"   This comment shows
 ignorance of the hardware signaling.   Yes, it is an atomic command, but
 one that can be aborted at any time, with little to no visible artifacts.
 In the current (first) version of the DCON, if the DCONLOAD signal is
 deasserted before control has been transferred to the DCON, control is not
 transferred to the DCON and the system proceeds normally (never generating
 the interrupt indicating that a DisplayLoad occurred. This behavior was
 encountered in debugging #9869.)   If the frame buffer has completed
 loading and control has been switched, then there will be one frame
 displayed from the DCON's frame buffer before transferring control back.
 Note, however, that non-atomic control wouldn't improve this degenerate
 case (where you realize you are modifying the frame buffer at the same
 time you are transferring control to the DCON).

 Continuously loading the DCON frame buffer would cost upwards of 50mW.

 There is no disagreement about the transition back to host control.
 Unfortunately, that isn't a problem with the DCON, rather a problem that
 most SoC display controllers no longer support genlock (even of the
 limited vertical kind).  The LX used in XO-1 supported genlock, but it
 multiplexed the sync. input signals with others that we needed, preventing
 its use.  More recent chipsets used in OLPC laptops (Via VX855, Marvell
 A610) do not support genlock of their display controllers.

 In an ideal world, frame rates could be arbitrarily set.  In the real
 world, memory and bus bandwidth constraints prevent such arbitrary
 settings.

 DPVL (Design Professionals Volleyball League ?) never really existed.  The
 rumors that the nice features were incorporated into DisplayPort are
 untrue.   It's real descendant is a proprietary and publicly undocumented
 technology called "Smart Panel".   Unfortunately, Smart Panel (which I'm
 sure is somebody's trademark) is used mainly for small displays for
 automotive applications.   I do agree that a more intelligent interconnect
 with the display is the right direction for future development, but it
 requires that the display panel incorporate a full frame buffer (DCON) and
 currently has little to no support in the marketplace.

 The reason there is no register for reading the current state of the DCON
 is that the register interface is 100Kbps I2C.   In the time it takes to
 read a register, 20 scan lines have passed.

 Additional comments from Adam about the DCON may be found at:
 http://lists.laptop.org/pipermail/devel/2007-December/008624.html

 One of the silicon bugs listed there, the fact that DCONBLANK is asserted
 at the wrong time, will be fixed.

 Regarding all the comments about black and white mode and color anti-
 aliasing --- these features are being dropped from future DCON designs as
 both the pixel layout is returning to a more conventional one and there is
 no explicit B&W mode in future displays --- they are likely to provide a
 slight amount of desaturated color in reflective mode.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1671#comment:4>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system