All drivers embed gem-objects into their own buffer objects. There is no
reason to keep drm_gem_object_alloc(), gem->driver_private and
->gem_init_object() anymore.
New drivers are highly encouraged to do the same. There is no benefit in
allocating gem-objects separately.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Ben Skeggs <skeggsb@gmail.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.
So give it to them and roll it out in all drivers.
This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for gem
drivers.
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Ben Skeggs <skeggsb@gmail.com>
Reviwed-by: Rob Clark <robdclark@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
At the larger resolutions, the g200e series sometimes struggles with
maintaining a proper output. Problems like flickering or black bands appearing
on screen can occur. In order to avoid this, limitations regarding resolutions
and bandwidth have been added for the different variations of the g200e series.
This code was ported from the old xorg mga driver.
Signed-off-by: Julia Lemire <jlemire@matrox.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
G200 cards support, at best, 16 colour palleted images for the cursor
so we do a conversion in the cursor_set function, and reject cursors
with more than 16 colours, or cursors with partial transparency. Xorg
falls back gracefully to software cursors in this case.
We can't disable/enable the cursor hardware without causing momentary
corruption around the cursor. Instead, once the cursor is on we leave
it on, and simulate turning the cursor off by moving it
offscreen. This works well.
Since we can't disable -> update -> enable the cursors, we double
buffer cursor icons, then just move the base address that points to
the old cursor, to the new. This also works well, but uses an extra
page of memory.
The cursor buffers are lazily-allocated on first cursor_set. This is
to make sure they don't take priority over any framebuffers in case of
limited memory.
Here is a representation of how the bitmap for the cursor is mapped in G200 memory :
Each line of color cursor use 6 Slices of 8 bytes. Slices 0 to 3
are used for the 4bpp bitmap, slice 4 for XOR mask and slice 5 for
AND mask. Each line has the following format:
// Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
//
// S0: P00-01 P02-03 P04-05 P06-07 P08-09 P10-11 P12-13 P14-15
// S1: P16-17 P18-19 P20-21 P22-23 P24-25 P26-27 P28-29 P30-31
// S2: P32-33 P34-35 P36-37 P38-39 P40-41 P42-43 P44-45 P46-47
// S3: P48-49 P50-51 P52-53 P54-55 P56-57 P58-59 P60-61 P62-63
// S4: X63-56 X55-48 X47-40 X39-32 X31-24 X23-16 X15-08 X07-00
// S5: A63-56 A55-48 A47-40 A39-32 A31-24 A23-16 A15-08 A07-00
//
// S0 to S5 = Slices 0 to 5
// P00 to P63 = Bitmap - pixels 0 to 63
// X00 to X63 = always 0 - pixels 0 to 63
// A00 to A63 = transparent markers - pixels 0 to 63
// 1 means colour, 0 means transparent
Signed-off-by: Christopher Harvey <charvey@matrox.com>
Signed-off-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Acked-by: Julia Lemire <jlemire@matrox.com>
Tested-by: Julia Lemire <jlemire@matrox.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
On F19 testing, it was noticed we get a lot of errors in dmesg
about being unable to reserve the buffer when plymouth starts,
this is due to the buffer being in the process of migrating,
so it makes sense we can't reserve it.
In order to deal with it, this adds delayed updates for the dirty
updates, when the bo is unreservable, in the normal console case
this shouldn't ever happen, its just when plymouth or X is
pushing the console bo to system memory.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pull drm merge (part 1) from Dave Airlie:
"So first of all my tree and uapi stuff has a conflict mess, its my
fault as the nouveau stuff didn't hit -next as were trying to rebase
regressions out of it before we merged.
Highlights:
- SH mobile modesetting driver and associated helpers
- some DRM core documentation
- i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write
combined pte writing, ilk rc6 support,
- nouveau: major driver rework into a hw core driver, makes features
like SLI a lot saner to implement,
- psb: add eDP/DP support for Cedarview
- radeon: 2 layer page tables, async VM pte updates, better PLL
selection for > 2 screens, better ACPI interactions
The rest is general grab bag of fixes.
So why part 1? well I have the exynos pull req which came in a bit
late but was waiting for me to do something they shouldn't have and it
looks fairly safe, and David Howells has some more header cleanups
he'd like me to pull, that seem like a good idea, but I'd like to get
this merge out of the way so -next dosen't get blocked."
Tons of conflicts mostly due to silly include line changes, but mostly
mindless. A few other small semantic conflicts too, noted from Dave's
pre-merged branch.
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits)
drm/nv98/crypt: fix fuc build with latest envyas
drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering
drm/nv41/vm: fix and enable use of "real" pciegart
drm/nv44/vm: fix and enable use of "real" pciegart
drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie
drm/nouveau: store supported dma mask in vmmgr
drm/nvc0/ibus: initial implementation of subdev
drm/nouveau/therm: add support for fan-control modes
drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules
drm/nouveau/therm: calculate the pwm divisor on nv50+
drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster
drm/nouveau/therm: move thermal-related functions to the therm subdev
drm/nouveau/bios: parse the pwm divisor from the perf table
drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices
drm/nouveau/therm: rework thermal table parsing
drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table
drm/nouveau: fix pm initialization order
drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it
drm/nouveau: log channel debug/error messages from client object rather than drm client
drm/nouveau: have drm debugging macros build on top of core macros
...
Convert #include "..." to #include <path/...> in drivers/gpu/.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Dave Jones <davej@redhat.com>
This is a driver for the G200 server engines chips,
it doesn't driver any of the Matrix G series desktop cards.
It will bind to G200 SE A,B, G200EV, G200WB, G200EH and G200ER cards.
Its based on previous work done my Matthew Garrett but remodelled
to follow the same style and flow as the AST server driver. It also
works along the same lines as the AST server driver wrt memory management.
There is no userspace driver planned, xf86-video-modesetting should be used.
It also appears these GPUs have no ARGB hw cursors.
v2: add missing tagfifo reset + G200 SE memory bw setup pieces.
Signed-off-by: Dave Airlie <airlied@redhat.com>
David Herrmann