CVS commit: src/sys/dev/usb

[Izumi Tsutsui <tsutsui%netbsd.org@localhost>]

Module Name:    src
Committed By:   tsutsui
Date:           Mon Nov 30 16:18:35 UTC 2009

Modified Files:
        src/sys/dev/usb: files.usb
Added Files:
        src/sys/dev/usb: udl.c udl.h

Log Message:
Add a driver for DisplayLink DL-1x0/1x5 based USB LCDs and USB-VGA adaptors.
Ported by FUKAUMI Naoki from OpenBSD with many modification.
No particular comments (except from me) on tech-kern@.

There are still many TODO even in MI wscons(4) API to handle this device:

 * No detach function for wsdisplay(9).
   Unpluging a device causes a panic. (should be trivial?)

 * ioctl() for X server support is currently commented out. ("notyet")
   OpenBSD allows device depedent ioctl()s and they introduced
   UDLIO_DAMAGE ioctl for the damage extension ops of X servers for udl(4).
   Before blindly pulling such ioctl(), probably we should discuss
   how such specific operations should be handled in MI wscons(4) API.

 * Screen text of wsemul tty could be mangled during large scroll ops.
   All tty output operations are invoked via ttstart() with the giant
   tty_lock mutex held, so we can't call cv_wait(9) to wait resources
   for data xfers via usbdi(9).h, then text output is silently discarded
   on resource shortage. To handle this without tty_lock reorganization,
   we have to change wsdisplay(9) APIs (especially wsdisplaystart()) to
   return a number of actually handled characters as OpenBSD does, but
   it may require whole API changes around child rasops(9) etc.

 * No MI API definition to convert mmap(9) cookie to physical address.
   The conversion is required to create a cookie which will be passed to
   pmap_phys_address(9) in uvm/uvm_device.c:udv_fault(). Most other
   drivers use bus_dmamem_mmap(9) or bus_space_mmap(9), but udl(4) uses
   kmem_alloc(9)'ed memory for bitmap data.
   Furthermore, pmap(9) man page says about pmap_phys_address(9):

     "This function is provided to accommodate systems which have
      physical address spaces larger than can be directly addressed
      by the platform's paddr_t type. The existence of this function is
      highly dubious, and it is expected that this function will be
      removed from the pmap API in a future release of NetBSD."

   As the man page says we have already had split paddr_t and vaddr_t,
   so it's time to remove such old ugly cookie and change all mmap(4)
   functions (mostly in MD bus_dma(9) and bus_space(9) APIs) to return
   simple physical address in paddr_t?

 * We need proper device names for wsdisplay1 (and more devices).
   Currently wsdisplay0 uses ttyE0 through ttyE253 (minor 0 to 253)
   for screens, ttyEstat (254) for status, and ttyEcfg (255) for config.
   The next wsdisplay1 will use 256 through 509 for screens, 510 for stat,
   and 511 for config but what names should we use for them? ttyFxxx?

 * How to handle multiple sets of wskbd/wsdisplay on a single machine.
   rc.d/wscons doesn't provide method to specify wscons control devices.
   There is no proper interface to specify which keyboard should be connected
   to which wsdisplay, etc.

 * And maybe more...


To generate a diff of this commit:
cvs rdiff -u -r1.91 -r1.92 src/sys/dev/usb/files.usb
cvs rdiff -u -r0 -r1.1 src/sys/dev/usb/udl.c src/sys/dev/usb/udl.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.