On Thu, 2012-04-26 at 14:48 +0100, Dave Airlie wrote:
> +/*
> + * Our emulated hardware has two sets of memory. One is video RAM and can
> + * simply be used as a linear framebuffer - the other provides mmio access
> + * to the display registers. The latter can also be accessed via IO port
> + * access, but we map the range and use mmio to program them instead
> + */
I suspect this comment came from somewhere near the emulated cirrus card
in qemu? G200's definitely not emulated hardware.
> +/*
> + * The meat of this driver. The core passes us a mode and we have to program
> + * it. The modesetting here is the bare minimum required to satisfy the qemu
> + * emulation of this hardware, and running this against a real device is
> + * likely to result in an inadequately programmed mode. We've already had
> + * the opportunity to modify the mode, so whatever we receive here should
> + * be something that can be correctly programmed and displayed
> + */
Yep, drm/cirrus all over the place here.
> +/*
> + * This is called after a mode is programmed. It should reverse anything done
> + * by the prepare function
> + */
> +static void mga_crtc_commit(struct drm_crtc *crtc)
> +{
This appears to be missing the analog of the "Reset tagfifo" commit from
the X driver for G200ER:
http://cgit.freedesktop.org/xorg/driver/xf86-video-mga/commit/?id=01ca2186ea028b2549de509b51726aa08519fce0
Which, admittedly, is in an odd place in the X driver.
- ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
