The current mostly random sort order hinders code readability. Sort the
options alphabetically in the code, and by group in the help message.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Those variables are declared in unistd.h, there's no need to redeclare
them here.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Enable all standard automake warnings except for -Wpointer-arith (as the
test pattern generation code uses void pointer arithmetics) and fix
them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Mark the address ranges as accessible with VALGRIND_MAKE_MEM_DEFINED.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No need to prepare the .aub header and dump in that case, it'll be
done with the next call with true.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
RADEON_GEM_WAIT_IDLE is declared DRM_IOW but libdrm
uses it with drmCommandWriteRead instead of drmCommandWrite
which leads to the ioctl being unmatched and returning an
error on at least OpenBSD.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
At DDX commit Chris mentioned the tendency we have of finding out more
PCI IDs only when users report. So Let's add all new reserved Haswell IDs.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=63701
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
When publishing first HSW ids we weren't allowed to use "GT3" codname.
But this is the correct codname and Mesa is using it already.
So to avoid people getting confused why in Mesa it is called GT3 and here
it is called GT2_PLUS let's fix this name in a standard and correct way.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Render the crosshairs for 565 and x888/a888 formats.
v2: Use the drm format to determine cairo format
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
When adding the name tracking, I missed removing from the name table
when the bo was deleted, leaving a dangling pointer.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Things are worse if we issueibcmds with bogus gpu ptrs, so it is better
to just make userspace crash when things go pear shaped.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Due to the evil userspace buffer tracking we have to do, and hacks for
creating GEM buffer from fbdev/scanout, "evil-twin" fd_bo objects are
problematic. So introduce hashtable tracking of bo's and dev's, to
avoid getting duplicate fd_bo ptrs for the same underlying gem object,
in particular when importing via flink name.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Super-cheezy way to synchronization between mesa and ddx.. the
SET_ACTIVE ioctl gives us a way to stash a 32b # w/ a GEM bo, and
GET_BUFINFO gives us a way to retrieve it. We use this to stash
the timestamp of the last ISSUEIBCMDS on the buffer.
To avoid an obscene amount of syscalls, we:
1) Only set the timestamp for buffers w/ an flink name, ie.
only buffers shared across processes. This is enough to
catch the DRI2 buffers.
2) Only set the timestamp for buffers submitted to the 3d ring
and only check the timestamps on buffers submitted to the
2d ring. This should be enough to handle synchronizing of
presentation blit. We could do synchronization in the other
direction too, but that would be problematic if we are using
the 3d ring from DDX, since client side wouldn't know this.
The waiting on timestamp happens before flush, and setting of
timestamp happens after flush. It is transparent to the user
of libdrm_freedreno as all the tracking of buffers happens via
_emit_reloc()..
Signed-off-by: Rob Clark <robclark@freedesktop.org>
YUV420 support is trivial to add since the code already supports
YVU420.
But it looks like the YVU420 support is a bit broken. The chroma
planes are passed in the wrong order to the fill functions, so
fix that while were at it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The fourcc is inside the format_info structure, so if we want to use
it inside the various fill_tiles functions, we need to pass down the
whole format_info, not just the rgb/yuv infos.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Spelling out eDP or DP make for a ridicilously long string which plays
havoc with formatting. Just say eDP or DP.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
libkms only has the xrgb8888 format, so we're overallocating the bo by
quite a lot in some cases. But we still need to get the pitch from the
libkms since it's the driver that decides how to align it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The function returns returns 0 on success or a negative value in case of an
error, except when given invalid attributes in which case it returns the
positive EINVAL value. Replace that with -EINVAL to allow the caller to detect
errors with a < 0 check.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jakob Bornecrantz <wallbraker@gmail.com>
v2: Only writte tile index if flags for it is set
v3: Remove useless allow2d scanout flags
v4: Split radeon_drm.h update to its own patch
v5: update against lastest next tree for radeon
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
It accidentally used the cmd id for the gen7 command and had an
outdated lenght field. Spotted while trying to make sense of an ivb
error_state from mesa 7.11 ...
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The second digit was off by one, which meant we accidentally treated
GT(n) as GT(n-1). This also meant no support for GT1 at all.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
If clock_gettime did fail, it would return -1 and set errno.
What we really want to strerror() is the errno.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Laurent Pinchart
Rob Clark
Chia-I Wu
Imre Deak
Dave Airlie
Alex Deucher
Damien Lespiau
Mark Kettenis
Rodrigo Vivi
Ville Syrjälä
Marek Olšák
Xiang, Haihao
Jerome Glisse
Rob Clark
Daniel Vetter
Kenneth Graunke
Daniel Kurtz
Maarten Lankhorst