<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/gpu/drm/drm_ioctl.c, branch dev-4.17</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.17</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.17'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2018-02-10T22:23:10+00:00</updated>
<entry>
<title>drm: Print the pid when debug logging an ioctl error.</title>
<updated>2018-02-10T22:23:10+00:00</updated>
<author>
<name>Eric Anholt</name>
<email>eric@anholt.net</email>
</author>
<published>2018-01-30T21:56:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9c950e468cb5913d223282a05e6cd22fecce5ac8'/>
<id>urn:sha1:9c950e468cb5913d223282a05e6cd22fecce5ac8</id>
<content type='text'>
When we debug print what ioctl we're calling into, we include the pid.
If you have multiple processes rendering simulataneously, the error
return also needs the pid so you can see which of the ioctl calls was
the one to fail.

Signed-off-by: Eric Anholt &lt;eric@anholt.net&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180130215643.11016-1-eric@anholt.net
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</content>
</entry>
<entry>
<title>drm/ioctl: Remove trailing whitespace</title>
<updated>2018-01-11T16:48:58+00:00</updated>
<author>
<name>Noralf Trønnes</name>
<email>noralf@tronnes.org</email>
</author>
<published>2018-01-03T22:21:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=937f3acc605397ccfce28c835f0bf9d6da589060'/>
<id>urn:sha1:937f3acc605397ccfce28c835f0bf9d6da589060</id>
<content type='text'>
Remove a couple of trailing spaces.

Signed-off-by: Noralf Trønnes &lt;noralf@tronnes.org&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180103222110.45855-3-noralf@tronnes.org
</content>
</entry>
<entry>
<title>drm: Add four ioctls for managing drm mode object leases [v7]</title>
<updated>2017-10-25T06:31:30+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2017-03-17T00:56:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=62884cd386b876638720ef88374b31a84ca7ee5f'/>
<id>urn:sha1:62884cd386b876638720ef88374b31a84ca7ee5f</id>
<content type='text'>
drm_mode_create_lease

	Creates a lease for a list of drm mode objects, returning an
	fd for the new drm_master and a 64-bit identifier for the lessee

drm_mode_list_lesees

	List the identifiers of the lessees for a master file

drm_mode_get_lease

	List the leased objects for a master file

drm_mode_revoke_lease

	Erase the set of objects managed by a lease.

This should suffice to at least create and query leases.

Changes for v2 as suggested by Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;:

 * query ioctls only query the master associated with
   the provided file.

 * 'mask_lease' value has been removed

 * change ioctl has been removed.

Changes for v3 suggested in part by Dave Airlie &lt;airlied@gmail.com&gt;

 * Add revoke ioctl.

Changes for v4 suggested by Dave Airlie &lt;airlied@gmail.com&gt;

 * Expand on the comment about the magic use of &amp;drm_lease_idr_object
 * Pad lease ioctl structures to align on 64-bit boundaries

Changes for v5 suggested by Dave Airlie &lt;airlied@gmail.com&gt;

 * Check for non-negative object_id in create_lease to avoid debug
   output from the kernel.

Changes for v6 provided by Dave Airlie &lt;airlied@gmail.com&gt;

 * For non-universal planes add primary/cursor planes to lease

   If we aren't exposing universal planes to this userspace client,
   and it requests a lease on a crtc, we should implicitly export the
   primary and cursor planes for the crtc.

   If the lessee doesn't request universal planes, it will just see
   the crtc, but if it does request them it will then see the plane
   objects as well.

   This also moves the object look ups earlier as a side effect, so
   we'd exit the ioctl quicker for non-existant objects.

 * Restrict leases to crtc/connector/planes.

   This only allows leasing for objects we wish to allow.

Changes for v7 provided by Dave Airlie &lt;airlied@gmail.com&gt;

 * Check pad args are 0
 * Check create flags and object count are valid.
 * Check return from fd allocation
 * Refactor lease idr setup and add some simple validation
 * Use idr_mutex uniformly (Keith)

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]</title>
<updated>2017-10-23T01:15:03+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2017-06-30T05:49:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3064abfa932bd09faf8da01741d171d476cf7193'/>
<id>urn:sha1:3064abfa932bd09faf8da01741d171d476cf7193</id>
<content type='text'>
These provide crtc-id based functions instead of pipe-number, while
also offering higher resolution time (ns) and wider frame count (64)
as required by the Vulkan API.

v2:

 * Check for DRIVER_MODESET in new crtc-based vblank ioctls

	Failing to check this will oops the driver.

 * Ensure vblank interupt is running in crtc_get_sequence ioctl

	The sequence and timing values are not correct while the
	interrupt is off, so make sure it's running before asking for
	them.

 * Short-circuit get_sequence if the counter is enabled and accurate

	Steal the idea from the code in wait_vblank to avoid the
	expense of drm_vblank_get/put

 * Return active state of crtc in crtc_get_sequence ioctl

	Might be useful for applications that aren't in charge of
	modesetting?

 * Use drm_crtc_vblank_get/put in new crtc-based vblank sequence ioctls

	Daniel Vetter prefers these over the old drm_vblank_put/get
	APIs.

 * Return s64 ns instead of u64 in new sequence event

Suggested-by: Daniel Vetter &lt;daniel@ffwll.ch&gt;
Suggested-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;

v3:

 * Removed FIRST_PIXEL_OUT_FLAG
 * Document that the timestamp in the query and event are
   that of the first pixel leaving the display engine for
   the display (using the same wording as the Vulkan spec).

Suggested-by: Michel Dänzer &lt;michel@daenzer.net&gt;
Acked-by: Dave Airlie &lt;airlied@redhat.com&gt;

[airlied: left-&gt;leaves (Michel)]

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
Reviewed-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm: vblank: remove drm_timestamp_monotonic parameter</title>
<updated>2017-10-12T22:34:50+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-10-11T15:20:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=25e1a79874eb3821d93310c908cc0a81b47af060'/>
<id>urn:sha1:25e1a79874eb3821d93310c908cc0a81b47af060</id>
<content type='text'>
There is a risk of overflowing vblank timestamps in 2038 or 2106 if
someone sets the drm_timestamp_monotonic module parameter to zero.

I found no indication of anyone ever setting the parameter, or
complaining about the default being wrong, after it was introduced
as a way to handle backwards-compatibility with linux prior to
c61eef726a78 ("drm: add support for monotonic vblank timestamps"),
so it's probably safer to just remove the parameter completely
and only allowing the default behavior.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Daniel Stone &lt;daniels@collabora.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/syncobj: Add a signal ioctl (v3)</title>
<updated>2017-08-29T00:16:25+00:00</updated>
<author>
<name>Jason Ekstrand</name>
<email>jason@jlekstrand.net</email>
</author>
<published>2017-08-28T21:10:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ffa9443fb3d3eddf0fdf6ac473dc8b5c87f08f15'/>
<id>urn:sha1:ffa9443fb3d3eddf0fdf6ac473dc8b5c87f08f15</id>
<content type='text'>
This IOCTL provides a mechanism for userspace to trigger a sync object
directly.  There are other ways that userspace can trigger a syncobj
such as submitting a dummy batch somewhere or hanging on to a triggered
sync_file and doing an import.  This just provides an easy way to
manually trigger the sync object without weird hacks.

The motivation for this IOCTL is Vulkan fences.  Vulkan lets you create
a fence already in the signaled state so that you can wait on it
immediatly without stalling.  We could also handle this with a new
create flag to ask the driver to create a syncobj that is already
signaled but the IOCTL seemed a bit cleaner and more generic.

v2:
 - Take an array of sync objects (Dave Airlie)
v3:
 - Throw -EINVAL if pad != 0

Signed-off-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/syncobj: Add a reset ioctl (v3)</title>
<updated>2017-08-29T00:16:19+00:00</updated>
<author>
<name>Jason Ekstrand</name>
<email>jason@jlekstrand.net</email>
</author>
<published>2017-08-28T21:10:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=aa4035d2c7683d2f2fb0ffe8087abd9eabf6d54a'/>
<id>urn:sha1:aa4035d2c7683d2f2fb0ffe8087abd9eabf6d54a</id>
<content type='text'>
This just resets the dma_fence to NULL so it looks like it's never been
signaled.  This will be useful once we add the new wait API for allowing
wait on "submit and signal" behavior.

v2:
 - Take an array of sync objects (Dave Airlie)
v3:
 - Throw -EINVAL if pad != 0

Signed-off-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt; (v1)
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/syncobj: add sync obj wait interface. (v8)</title>
<updated>2017-08-28T20:26:32+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2017-08-25T17:52:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5e60a10eaebab93f823295cd7ec3848ba3b6e553'/>
<id>urn:sha1:5e60a10eaebab93f823295cd7ec3848ba3b6e553</id>
<content type='text'>
This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.

v2: accept relative timeout, pass remaining time back
to userspace.
v3: return to absolute timeouts.
v4: absolute zero = poll,
    rewrite any/all code to have same operation for arrays
    return -EINVAL for 0 fences.
v4.1: fixup fences allocation check, use u64_to_user_ptr
v5: move to sec/nsec, and use timespec64 for calcs.
v6: use -ETIME and drop the out status flag. (-ETIME
is suggested by ickle, I can feel a shed painting)
v7: talked to Daniel/Arnd, use ktime and ns everywhere.
v8: be more careful in the timeout calculations
    use uint32_t for counter variables so we don't overflow
    graciously handle -ENOINT being returned from dma_fence_wait_timeout

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Reviewed-by: Jason Ekstrand &lt;jason@jlekstrand.net&gt;
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm: Document device unplug infrastructure</title>
<updated>2017-08-11T08:48:03+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2017-08-02T11:56:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c07dcd61a0e57c6840c23d90cb1beddad7d682a1'/>
<id>urn:sha1:c07dcd61a0e57c6840c23d90cb1beddad7d682a1</id>
<content type='text'>
While at it, also ocd and give them a consistent drm_dev_ prefix, like
the other device instance functionality. Plus move the functions into
the right places.

Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20170802115604.12734-3-daniel.vetter@ffwll.ch
</content>
</entry>
<entry>
<title>Merge airlied/drm-next into drm-misc-next</title>
<updated>2017-07-26T11:43:33+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2017-07-26T11:23:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=af055598542670c8533a58582813b1419949cae0'/>
<id>urn:sha1:af055598542670c8533a58582813b1419949cae0</id>
<content type='text'>
I need this to be able to apply the deferred fbdev setup patches, I
need the relevant prep work that landed through the drm-intel tree.

Also squash in conflict fixup from Laurent Pinchart.

Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</content>
</entry>
</feed>
