search for: uabi

.... I think having this as a helper would be cleaner ... The other bit is drm_encoder->possible_crtcs. If we do create a helper for these, lets at least try to make them not suck too badly :-) Otherwise I guess it would be time to officially document what exactly possible_crtcs == 0 means from an uabi pov. -Daniel > --- > drivers/gpu/drm/drm_encoder.c | 116 ++++++++++++++++++++++++++++++++++ > include/drm/drm_encoder.h | 10 +++ > 2 files changed, 126 insertions(+) > > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c > index ffe691a1bf34..1...

.... I think having this as a helper would be cleaner ... The other bit is drm_encoder->possible_crtcs. If we do create a helper for these, lets at least try to make them not suck too badly :-) Otherwise I guess it would be time to officially document what exactly possible_crtcs == 0 means from an uabi pov. -Daniel > --- > drivers/gpu/drm/drm_encoder.c | 116 ++++++++++++++++++++++++++++++++++ > include/drm/drm_encoder.h | 10 +++ > 2 files changed, 126 insertions(+) > > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c > index ffe691a1bf34..1...

...ommend to look at rtc and tpm for fairly simple easy to follow patterns for creating a subsystem in the kernel. A subsystem owns a class, allows HW drivers to plug in to it, and provides a consistent user API via a cdev/sysfs/etc. The driver model class should revolve around the char dev and sysfs uABI - if you enumerate the devices on the class then they should all follow the char dev and sysfs interfaces contract of that class. Those examples show how to do all the refcounting semi-sanely, introduce sysfs, cdevs, etc. I thought the latest proposal was to use the existing vhost class and large...

...turn can be used to synchronize > > their jobs with either the scanout engine or the GPU. > > Whilst hooking up fences, I advise you to also hook up drm_syncobj. > Internally they each resolve to another fence, so the mechanics are > identical, you just need another array in the uABI for in/out syncobj. > The advantage of drm_syncobj is that userspace can track internal fences > using inexhaustible handles, reserving the precious fd for IPC or KMS. I'm not sure that I properly understand how to use these. It looks as if they are better fence FDs, so in case where you...

...t; their jobs with either the scanout engine or the GPU. > > > > > > Whilst hooking up fences, I advise you to also hook up drm_syncobj. > > > Internally they each resolve to another fence, so the mechanics are > > > identical, you just need another array in the uABI for in/out syncobj. > > > The advantage of drm_syncobj is that userspace can track internal fences > > > using inexhaustible handles, reserving the precious fd for IPC or KMS. > > > > I'm not sure that I properly understand how to use these. It looks as if > &g...

...to emit fence FDs that in turn can be used to synchronize > their jobs with either the scanout engine or the GPU. Whilst hooking up fences, I advise you to also hook up drm_syncobj. Internally they each resolve to another fence, so the mechanics are identical, you just need another array in the uABI for in/out syncobj. The advantage of drm_syncobj is that userspace can track internal fences using inexhaustible handles, reserving the precious fd for IPC or KMS. -Chris

...hronize > > > their jobs with either the scanout engine or the GPU. > > > > Whilst hooking up fences, I advise you to also hook up drm_syncobj. > > Internally they each resolve to another fence, so the mechanics are > > identical, you just need another array in the uABI for in/out syncobj. > > The advantage of drm_syncobj is that userspace can track internal fences > > using inexhaustible handles, reserving the precious fd for IPC or KMS. > > I'm not sure that I properly understand how to use these. It looks as if > they are better fence...

...s the third driver which supports syncobj timelines and > > looking at one of the implementations ... it is not great. Note that > > this suggestion is _not_ a blocker. > > Would like to see a third driver starting to use the exactly same > drm_execbuffer_syncobj struct because UABI part isn't generic, though > it's a replica of the MSM driver for now. > > The virtio-gpu is only at the beginning of starting to use sync objects, > compared to MSM driver. Will be better to defer the generalization until > virtio-gpu will become more mature, like maybe afte...

...k like? Best regards Thomas > > The other bit is drm_encoder->possible_crtcs. If we do create a helper for > these, lets at least try to make them not suck too badly :-) Otherwise I > guess it would be time to officially document what exactly possible_crtcs > == 0 means from an uabi pov. > -Daniel > >> --- >> drivers/gpu/drm/drm_encoder.c | 116 ++++++++++++++++++++++++++++++++++ >> include/drm/drm_encoder.h | 10 +++ >> 2 files changed, 126 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_enc...

On Wed, Apr 29, 2020 at 2:57 AM Jason Wang <jasowang at redhat.com> wrote: > > > On 2020/4/29 ??4:47, Lepton Wu wrote: > > This is a way to create virtio based devices from user space. This is the > > background for this patch: > > > > We have some images works fine under qemu, we'd like to also run the same image > > on Google Cloud. Currently

On Thu, Feb 13, 2020 at 10:41:06AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 13, 2020 at 11:05:42AM -0400, Jason Gunthorpe wrote: > > On Thu, Feb 13, 2020 at 10:58:44PM +0800, Jason Wang wrote: > > > > > > On 2020/2/13 ??9:41, Jason Gunthorpe wrote: > > > > On Thu, Feb 13, 2020 at 11:34:10AM +0800, Jason Wang wrote: > > > > > > >

On Thu, Feb 13, 2020 at 10:41:06AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 13, 2020 at 11:05:42AM -0400, Jason Gunthorpe wrote: > > On Thu, Feb 13, 2020 at 10:58:44PM +0800, Jason Wang wrote: > > > > > > On 2020/2/13 ??9:41, Jason Gunthorpe wrote: > > > > On Thu, Feb 13, 2020 at 11:34:10AM +0800, Jason Wang wrote: > > > > > > >

...ng the queue of already collected CRCs. (Maarten Lankhorst) - Added a helper to mark BOs purgeable on vc4. (Boris Brezillon) - Moved handling of a "cork" BO into lib from various tests. (Daniele Ceraolo Spurio) - Added support for looping over physical i915 engines, as opposed to uABI engines that can alias. (Chris Wilson) - Added an accelerated method for reading from WC buffers. (Chris Wilson) Tools changes: - Improved intel_vbt_decode output, updated the data from current kernel. (Jani Nikula) - intel_reg can now read/write registers using a given engine. (Mika Kuop...

From: Thierry Reding <treding at nvidia.com> This set of patches adds support for fences to Tegra DRM and complements the fence FD support for Nouveau. Technically this isn't necessary for a fence-based synchronization loop with Nouveau because the KMS core takes care of all that, but engines behind host1x can use the IOCTL extensions provided here to emit fence FDs that in turn can be

From: Gustavo Padovan <gustavo.padovan at collabora.co.uk> Refactor fence creation to remove the potential allocation failure from the cmd_submit and atomic_commit paths. Now the fence should be allocated first and just after we should proceed with the rest of the execution. Signed-off-by: Gustavo Padovan <gustavo.padovan at collabora.co.uk> --- drivers/gpu/drm/virtio/virtgpu_drv.h

From: Gustavo Padovan <gustavo.padovan at collabora.co.uk> Refactor fence creation to remove the potential allocation failure from the cmd_submit and atomic_commit paths. Now the fence should be allocated first and just after we should proceed with the rest of the execution. Signed-off-by: Gustavo Padovan <gustavo.padovan at collabora.co.uk> --- drivers/gpu/drm/virtio/virtgpu_drv.h

...rm_atomic_state; -/* - * Rotation property bits. DRM_ROTATE_<degrees> rotates the image by the - * specified amount in degrees in counter clockwise direction. DRM_REFLECT_X and - * DRM_REFLECT_Y reflects the image along the specified axis prior to rotation - * - * WARNING: These defines are UABI since they're exposed in the rotation - * property. - */ -#define DRM_ROTATE_0 BIT(0) -#define DRM_ROTATE_90 BIT(1) -#define DRM_ROTATE_180 BIT(2) -#define DRM_ROTATE_270 BIT(3) -#define DRM_ROTATE_MASK (DRM_ROTATE_0 | DRM_ROTATE_90 | \ - DRM_ROTATE_180 | DRM_ROTATE_270) -#define DRM_REFLE...

Fix DRM_REFELCT_Y -> DRM_REFLECT_Y. Signed-off-by: Robert Foss <robert.foss at collabora.com> --- drivers/gpu/drm/drm_blend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index a0d0d6843288..dee67ef6c670 100644 --- a/drivers/gpu/drm/drm_blend.c +++ b/drivers/gpu/drm/drm_blend.c @@ -129,7 +129,7 @@ *

...rm_atomic_state; -/* - * Rotation property bits. DRM_ROTATE_<degrees> rotates the image by the - * specified amount in degrees in counter clockwise direction. DRM_REFLECT_X and - * DRM_REFLECT_Y reflects the image along the specified axis prior to rotation - * - * WARNING: These defines are UABI since they're exposed in the rotation - * property. - */ -#define DRM_ROTATE_0 BIT(0) -#define DRM_ROTATE_90 BIT(1) -#define DRM_ROTATE_180 BIT(2) -#define DRM_ROTATE_270 BIT(3) -#define DRM_ROTATE_MASK (DRM_ROTATE_0 | DRM_ROTATE_90 | \ - DRM_ROTATE_180 | DRM_ROTATE_270) -#define DRM_REFLE...

...t; - * Rotation property bits. DRM_ROTATE_<degrees> rotates the image by the > - * specified amount in degrees in counter clockwise direction. DRM_REFLECT_X and > - * DRM_REFLECT_Y reflects the image along the specified axis prior to rotation > - * > - * WARNING: These defines are UABI since they're exposed in the rotation > - * property. > - */ > -#define DRM_ROTATE_0 BIT(0) > -#define DRM_ROTATE_90 BIT(1) > -#define DRM_ROTATE_180 BIT(2) > -#define DRM_ROTATE_270 BIT(3) > -#define DRM_ROTATE_MASK (DRM_ROTATE_0 | DRM_ROTATE_90 | \ > - DRM_ROTATE_...