Commit Graph

10 Commits

Author SHA1 Message Date
marius
b730263346 Make sparc64 compatible with NEW_PCIB and enable it:
- Implement bus_adjust_resource() methods as far as necessary and in non-PCI
  bridge drivers as far as feasible without rototilling them.
- As NEW_PCIB does a layering violation by activating resources at layers
  above pci(4) without previously bubbling up their allocation there, move
  the assignment of bus tags and handles from the bus_alloc_resource() to
  the bus_activate_resource() methods like at least the other NEW_PCIB
  enabled architectures do. This is somewhat unfortunate as previously
  sparc64 (ab)used resource activation to indicate whether SYS_RES_MEMORY
  resources should be mapped into KVA, which is only necessary if their
  going to be accessed via the pointer returned from rman_get_virtual() but
  not for bus_space(9) as the later always uses physical access on sparc64.
  Besides wasting KVA if we always map in SYS_RES_MEMORY resources, a driver
  also may deliberately not map them in if the firmware already has done so,
  possibly in a special way. So in order to still allow a driver to decide
  whether a SYS_RES_MEMORY resource should be mapped into KVA we let it
  indicate that by calling bus_space_map(9) with BUS_SPACE_MAP_LINEAR as
  actually documented in the bus_space(9) page. This is implemented by
  allocating a separate bus tag per SYS_RES_MEMORY resource and passing the
  resource via the previously unused bus tag cookie so we later on can call
  rman_set_virtual() in sparc64_bus_mem_map(). As a side effect this now
  also allows to actually indicate that a SYS_RES_MEMORY resource should be
  mapped in as cacheable and/or read-only via BUS_SPACE_MAP_CACHEABLE and
  BUS_SPACE_MAP_READONLY respectively.
- Do some minor cleanup like taking advantage of rman_init_from_resource(),
  factor out the common part of bus tag allocation into a newly added
  sparc64_alloc_bus_tag(), hook up some missing newbus methods and replace
  some homegrown versions with the generic counterparts etc.
- While at it, let apb_attach() (which can't use the generic NEW_PCIB code
  as APB bridges just don't have the base and limit registers implemented)
  regarding the config space registers cached in pcib_softc and the SYSCTL
  reporting nodes set up.
2011-10-02 23:22:38 +00:00
rnoland
3dc3ad8568 Update d_mmap() to accept vm_ooffset_t and vm_memattr_t.
This replaces d_mmap() with the d_mmap2() implementation and also
changes the type of offset to vm_ooffset_t.

Purge d_mmap2().

All driver modules will need to be rebuilt since D_VERSION is also
bumped.

Reviewed by:	jhb@
MFC after:	Not in this lifetime...
2009-12-29 21:51:28 +00:00
marius
02cba76cdb - Remove the second license as I'm also fine with the first one.
- Remove redundant softc members for RIDs.
- Change some softc members to be unsigned where more appropriate.
- Add some missing const.
- Remove support for mmap(2)'ing VGA I/O as it was broken [1] and
  not required by X.Org anyway.
- Fix some confusion between bus, physical and virtual addresses
  which mostly consisted in using members of struct video_adapter
  inappropriately but wasn't fatal except for the regular framebuffer
  mmap(2)'ing.
- Remove redundant bzero(9)'ing of the softc.
- Don't map the framebuffer twice in case the firmware has already
  mapped it as besides wasting resources this isn't possible with
  all MMUs. This is a bit tricky as a) just because the firmware
  provides a property with a virtual address doesn't mean it's
  actually mapped (but typically is when the framebuffer is the
  console) and b) the firmware doesn't necessarily map the it with
  the same byteorder as we do. This make machfb(4) work on machines
  with cheetah-class MMUs (including X.Org).

Reported by:	Michael Plass [1]
MFC after:	3 days
2009-04-14 20:23:47 +00:00
marius
a8c597d29e Fix whitespace. 2009-04-14 19:11:02 +00:00
wkoszek
bb029b61d9 Replace explicit calls to video methods with their respective variants
implemented with macros. This patch improves code readability. Reasoning
behind vidd_* is a sort of "video discipline".

List of macros is supposed to be complete--all methods of video_switch
ought to have their respective macros from now on.

Functionally, this code should be no-op. My intention is to leave current
behaviour of touched code as is.

No objections:	rwatson
Silence on:	freebsd-current@
Approved by:	cognet
2007-12-29 23:26:59 +00:00
marius
9dc384d0c4 Move the gallant 12 x 22 font data from a .h to a .c so it doesn't need
to be compiled into every driver making use of it. Use a const instance
of struct gfb_font for this as the font isn't intended to be changed at
run-time and in order to accompany the font data with height and width
info.
2007-06-16 21:48:50 +00:00
marius
fe0a34c8f1 Add a font width argument to vi_load_font_t, vi_save_font_t and vi_putm_t
and do some preparations for handling 12x22 fonts (currently lots of code
implies and/or hardcodes a font width of 8 pixels). This will be required
on sparc64 which uses a default font size of 12x22 in order to add font
loading and saving support as well as to use a syscons(4)-supplied mouse
pointer image.
This API breakage is committed now so it can be MFC'ed in time for 6.0
and later on upcoming framebuffer drivers destined for use on sparc64
and which are expected to rely on using font loading internally and on
a syscons(4)-supplied mouse pointer image can be easily MFC'ed to
RELENG_6 rather than requiring a backport.

Tested on:	i386, sparc64, make universe
MFC after:	1 week
2005-09-28 14:54:07 +00:00
marius
99f3cd87d0 - Declare lookup tables etc. const. [1]
- Add a missing "ATI" in one of the device descriptions.
- In machfb_init_engine() adjust a wait_for_fifo() call to the
  actual number of operations.
- As a speed optimization cache setting the foreground and back-
  ground colors.
- I got the meaning of V_DISPLAY_BLANK wrong, it's blank like turn
  off and not blank like turn on and clear the screen. So move
  clearing the screen to machfb_clear() were it hopefully belongs.
- Properly implement V_DISPLAY_BLANK, V_DISPLAY_STAND_BY and
  V_DISPLAY_SUSPEND. This makes blank_saver.ko and green_saver.ko
  work. [1]
- Implement machfb_load_palette() and machfb_save_palette() and
  set the V_ADP_PALETTE flag. This makes fade_saver.ko work. [2]
- Install our 16-color color map only once and with an offset of
  16 as the OBP driver expects white to be at index 0 and black at
  255. This fixes the inversion of the colors back at the boot
  prompt after shutting down FreeBSD. This will also be handy if
  we ever want to implement breaking into OFW. Unfortunately there
  doesn't seem to be a better way to achieve this as e.g. bypassing
  the color map isn't supported by all Mach64 chips.
- Move invalidating the cache variables to machfb_set_mode() and
  set the V_ADP_MODECHANGE flag. This causes machfb_set_mode() to
  be called when the X server shuts down. This hopefully will fix
  the screen corruption happening occasionally when shutting down
  the X server and which is present until switching to another VTY.

Inspired by:	NetBSD [1]
Based on:	Xorg [2]
Approved by:	re (scottl)
2005-07-10 11:43:20 +00:00
marius
60be7654fb - In machfb_configure() when probed for the high-level console return
the number of registered adapters instead of determining again whether
  stdout is a supported card (and which might have failed to attach and
  register).
- Fix a bug in the handling of the FBIOSCURSOR IOCTL; the code was meant
  to return ENODEV for all invocations expect when used to disable the
  cursor and not just when used for enabling the cursor.
- In case the adapter is the OFW stdout move its OFW cursor to the start
  of the last line on halt so OFW output doesn't get intermixed with what
  FreeBSD left on the screen.
- Drop variable names in the prototypes of some functions in order to
  match the style of majority of the prototypes in this file.
2005-06-04 21:18:30 +00:00
marius
b81be30085 Add machfb(4), a driver for ATI Mach64 graphics chips intended for
use with syscons(4) on sparc64. It's based on the respective NetBSD
driver with some additional info (initialisation/hardware cursor)
obtained from the Xorg 'ati' driver and some ideas taken from
creator(4). ATI Mach64 chips ("ATI Rage") are quite common as low-
end graphics chips in PCI-based sun4u machines and are used on-board
in e.g. Blade 100 and a couple of OEM products. Most if not all of
the Sun PGX add-on cards family (descriptions of the PGX32 are
conflicting but most say it's a Rage Pro) are also based on these
chips. Depending on the version of the OBP Mach64 cards destined for
use in i386 machines also work in sun4u machines.
The driver uses pixel mode with hardware acceleration as far as
syscons(4) currently permits on sparc64 so text mode is already
quite fast. The hardware cursor is used for the mouse pointer;
for one because this is a "restriction" induced in syscons(4) on
sparc64 by creator(4) and also because of issues with mapping
the aperture when used as a low-level early during boot. Due to
insufficiencies in the available documentation I didn't manage to
get mode switch work properly (sync problems), yet. So for now
this driver relies on the OBP having initialised a mode (as does
creator(4)). On all of the tested machines is even true when using
a serial console (and also not only when the OBP switched to a
serial console because no keyboard is present). In general however
the states the Mach64 chips are left in by the OBP vary a lot
depending on the version of the OBP. This e.g. includes the aperture
not being mapped in even when used as the console and the OBP just
barfing when asked to map it. The latter is also the reason for the
existence of this native driver in FreeBSD rather than taking an
OFW frambuffer approach.
Xorg is also happy to talk to these chips by mmap'ing them through
this driver. For some hardware configs like on the Blade 100 a fix
for the Xorg sparc64 MD bus code is however needed (added in version
6.8.2_2 of the xorg-server port).
The video driver font loading and saving methods are not implemented,
yet, as syscons(4) needs more work in that area to work viable on
sparc64.
With minor modifications machfb(4) would most likely also work on
powerpc, when #ifdef'ing the OFW and possibly implementing mode
setting probably also on the other archs. The latter is however
not very practible at the moment as it would conflict with vga(4).

Tested/developed with:	Rage II+ add-on card on AX1105 and AXi board,
			AXe board (on-board Rage Pro)
Additional testing by:	marcel (Ultra 5 w/ on-board Rage Pro),
			scottl (Naturetech GENIALstation 777S w/ on-board
			Rage Mobility M1),
			Michiel Boland and Ilmar S. Habibulin (Blade 100
			w/ on-board Rage XL)
2005-05-21 20:47:38 +00:00