Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/sys/dev/wsfb/genfbvar.h

97 lines
3.2 KiB
C
Raw Normal View History

Expose genfb_restore_palette and allow MD code to specify PMF callbacks.
2009-08-24 15:03:44 +04:00
/* $NetBSD: genfbvar.h,v 1.11 2009/08/24 11:03:44 jmcneill Exp $ */
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
/*-
* Copyright (c) 2007 Michael Lorenz
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include <sys/cdefs.h>
Expose genfb_restore_palette and allow MD code to specify PMF callbacks.
2009-08-24 15:03:44 +04:00
__KERNEL_RCSID(0, "$NetBSD: genfbvar.h,v 1.11 2009/08/24 11:03:44 jmcneill Exp $");
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
#ifndef GENFBVAR_H
#define GENFBVAR_H
#include <sys/param.h>
#include <sys/buf.h>
#include <sys/conf.h>
#include <sys/device.h>
machine/{bus,cpu,intr}.h -> sys/{bus,cpu,intr}.h
2007-10-19 15:59:34 +04:00
#include <sys/bus.h>
- move all memory mapping into the bus frontend - get rid of macppc-isms like *_mmap() returning physical addresses
2007-04-10 04:14:42 +04:00
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
#include <dev/wscons/wsconsio.h>
#include <dev/wscons/wsdisplayvar.h>
#include <dev/rasops/rasops.h>
#include <dev/wscons/wsdisplay_vconsvar.h>
struct genfb_ops {
int (*genfb_ioctl)(void *, void *, u_long, void *, int, struct lwp *);
paddr_t (*genfb_mmap)(void *, void *, off_t, int);
Introduce genfb_ops genfb_borrow callback to allow the bus frontend to lend mappings to drm.
2009-02-15 21:41:49 +03:00
int (*genfb_borrow)(void *, bus_addr_t, bus_space_handle_t *);
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
};
add a callback to change the colour map so now X with wsfb on top of genfb should look right
2007-04-14 23:56:05 +04:00
struct genfb_colormap_callback {
void *gcc_cookie;
void (*gcc_set_mapreg)(void *, int, int, int, int);
};
Expose genfb_restore_palette and allow MD code to specify PMF callbacks.
2009-08-24 15:03:44 +04:00
struct genfb_pmf_callback {
bool (*gpc_suspend)(device_t PMF_FN_PROTO);
bool (*gpc_resume)(device_t PMF_FN_PROTO);
};
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
struct genfb_softc {
struct device sc_dev;
struct vcons_data vd;
struct genfb_ops sc_ops;
struct vcons_screen sc_console_screen;
struct wsscreen_descr sc_defaultscreen_descr;
const struct wsscreen_descr *sc_screens[1];
struct wsscreen_list sc_screenlist;
add a callback to change the colour map so now X with wsfb on top of genfb should look right
2007-04-14 23:56:05 +04:00
struct genfb_colormap_callback *sc_cmcb;
Expose genfb_restore_palette and allow MD code to specify PMF callbacks.
2009-08-24 15:03:44 +04:00
struct genfb_pmf_callback *sc_pmfcb;
add shadow fb support now genfb is actually usable even on slow PCI framebuffers. Yay Jared :)
2007-08-05 03:51:37 +04:00
void *sc_fbaddr; /* kva */
void *sc_shadowfb;
- move all memory mapping into the bus frontend - get rid of macppc-isms like *_mmap() returning physical addresses
2007-04-10 04:14:42 +04:00
bus_addr_t sc_fboffset; /* bus address */
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
int sc_width, sc_height, sc_stride, sc_depth;
size_t sc_fbsize;
int sc_mode;
u_char sc_cmap_red[256];
u_char sc_cmap_green[256];
u_char sc_cmap_blue[256];
Add clear-screen and cursor-row properties to allow genfb to persist screen state from the MD console driver.
2009-02-17 05:19:33 +03:00
bool sc_want_clear;
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
};
Provide a stub genfb_cnattach for md code to call to give a hint to the bus driver's match function to return a higher confidence (so it can beat out vga(4), for example). genfb needs-flag so md code can determine if the genfb driver is present.
2009-02-14 23:33:58 +03:00
void genfb_cnattach(void);
Provide callbacks so MD code can explicitly prevent genfb from matching; works around vga/genfb deathmatches.
2009-02-17 01:24:40 +03:00
void genfb_disable(void);
Provide a stub genfb_cnattach for md code to call to give a hint to the bus driver's match function to return a higher confidence (so it can beat out vga(4), for example). genfb needs-flag so md code can determine if the genfb driver is present.
2009-02-14 23:33:58 +03:00
int genfb_is_console(void);
Provide callbacks so MD code can explicitly prevent genfb from matching; works around vga/genfb deathmatches.
2009-02-17 01:24:40 +03:00
int genfb_is_enabled(void);
- move all memory mapping into the bus frontend - get rid of macppc-isms like *_mmap() returning physical addresses
2007-04-10 04:14:42 +04:00
void genfb_init(struct genfb_softc *);
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
int genfb_attach(struct genfb_softc *, struct genfb_ops *);
Introduce genfb_ops genfb_borrow callback to allow the bus frontend to lend mappings to drm.
2009-02-15 21:41:49 +03:00
int genfb_borrow(bus_addr_t, bus_space_handle_t *);
Expose genfb_restore_palette and allow MD code to specify PMF callbacks.
2009-08-24 15:03:44 +04:00
void genfb_restore_palette(struct genfb_softc *);
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
#endif /* GENFBVAR_H */