[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-port-sparc
Subject:    Re: SS20 cg14 help
From:       Christian Corti <corti () informatik ! uni-stuttgart ! de>
Date:       2009-08-19 10:37:13
Message-ID: Pine.GSU.4.63.0908191230280.282 () azu
[Download RAW message or body]

Are the following files (and more of this kind) of any interest, or is the 
information already known?

cgfourteen.c
------------
[...]
#pragma ident   "@(#)cgfourteen.c 1.112 96/09/24 SMI"

/*
  * Driver for Campus-II MBus framebuffer (CG14).
  * The CG14 is made up of the MDI, the VBC, the RAMDAC, the PCG, and various
  * amounts of VRAM.  Together, these make up the VSIMM.
  * The CG14 provides access to 24 bit frame buffers and compatibility modes
  * for 8-bit and 16-bit (8+8) frame buffer access. The main functions
  * of this driver are to provide:
  *
  *      a) mappings to the MDI control address space which contains the cursor
  *         color look up tables, the DAC etc.
  *      b) mappings to the frame buffer a.k.a the VRAM in 8 different modes
  *         of access.
  *      c) a cgthree emulation mode to provide backwards binary compatibility
  *         for Pixrect/SunView applications.
  */
[...]

tcx.c
-----
#ifdef  SYSV
#pragma ident   "@(#)tcx.c
#else
#if !defined(lint) && !defined(NOID)
static char sccsid[] = "@(#)tcx.c 1.1 94/10/31 SMI";
#endif
#endif

/*
  * Copyright 1993 1994, Sun Microsystems, Inc.
  */

/*
  * A24 24-bit framebuffer.
  */

/*
  * A24 theory of operation:
  *
  * The A24 is driven by mapping framebuffer memory into process address
  * space and writing to it directly.  There are some control registers
  * that are also accessed by mapping into process address space, but
  * access to these registers are normally limited to the window system
  * only.
  *
  * The A24 is a (mostly) stateless framebuffer.  This means that
  * most operations are atomic to the extent that if a process accessing
  * the framebuffer is interrupted, and then resumes later after the
  * framebuffer state has been altered, there are no bad effects.
  *
  * Different operations on the A24 are achieved by referencing different
  * address spaces.  There is a 24-bit address space where 32-bit writes
  * reference individual 24-bit pixels.  There is an 8-bit address space
  * where 8-bit writes reference the red channel of individual pixels
  * (and 32-bit writes reference four pixels at a time.)
  *
  * In addition, there are special address spaces:  The "stipple" address
  * space allows a 64-bit control word to be written containing a color (24
  * or 8 bit) and a 32-bit pixel mask.  This allows 32 pixels to be written
  * in a single operation.  The address of the 64-bit write determines the
  * starting pixel for the operation.  The "blit" address space is similar
  * to the "stipple" address space, except that the 64-bit control word
  * specifies a source pixel address and a pixel mask rather than a color
  * and a pixel mask.
  *
  * In addition, there are "raw 32", "raw stipple" and "raw blit" address
  * spaces.  These are identical to the 24-bit, stipple and blit address
  * spaces, except that they also access the 2 control planes which determine
  * how underlying pixels are interpreted by the dacs (modes are: 8-bit
  * indexed, 24-bit indexed, 24-bit gamma-corrected and 24-bit raw).
  *
  * Virtual addresses and lengths for mmap() are defined in tcxreg.h.  Since
  * the framebuffer size is not engraved in stone, applications should
  * determine mmap() sizes by multiplying linebytes*height*depth.  Pixel depth
  * is as follows:
  *
  *      dfb8    1
  *      dfb24   4
  *      stip    8
  *      blit    8
  *      rdfb32  4
  *      rstip   8
  *      rblit   8
  *
  * linebytes is returned via the FBIOGXINFO ioctl.
  *
  * Registers used by the driver:
  *
  *      HCMISC          chiprev, reset, video enable, vblank, vbank interrupt
  *      LINECOUNT       current line counter
  *      CURSOR_ADDRESS  cursor address register
  *
  *
  *
  *
  * Note on softc locking:  Bug 1142190 requires that the softc struct
  * *not* be locked during copyin/copyout.  This is because copyin/copyout
  * could generate disk I/O to swap in the user address space.  If
  * a vertical retrace interrupt should occur during this I/O, the tcx
  * interrupt routine would block if softc were locked.  This could block
  * the disk I/O, causing system deadlock.
  */
[...]

Christian
[prev in list] [next in list] [prev in thread] [next in thread]