Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

Sean Paul writes: > Sphinx won't pick these up, and will issue warnings. Please update to @ > instead of \param > > If you want to try it out: > make htmldocs Yeah, I was attempting to emulate the existing style. I suggest that a general cleanup to fix the docstrings

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

Sean Paul writes: > Sphinx won't pick these up, and will issue warnings. Please update to @ > instead of \param > > If you want to try it out: > make htmldocs Yeah, I was attempting to emulate the existing style. I suggest that a general cleanup to fix the docstrings should be in a separate

[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

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

[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

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

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

On Tue, Oct 10, 2017 at 05:45:14PM -0700, Keith Packard wrote: > 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

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

On Tue, Oct 10, 2017 at 05:45:14PM -0700, Keith Packard wrote: > 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

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

On 11/10/17 02:45 AM, Keith Packard wrote: > 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 > >

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

On 11/10/17 02:45 AM, Keith Packard wrote: > 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 > >

[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

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

[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

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

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On Mon, Oct 09, 2017 at 10:18:30AM -0700, Keith Packard wrote: > Daniel Vetter writes: > > > I just figured that -modesetting would be the simplest domenstration > > vehicle, since the vulkan patches don't look ready yet. I need fully > > reviewed userspace before we can land

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On Mon, Oct 09, 2017 at 10:18:30AM -0700, Keith Packard wrote: > Daniel Vetter writes: > > > I just figured that -modesetting would be the simplest domenstration > > vehicle, since the vulkan patches don't look ready yet. I need fully > > reviewed userspace before we can land any kernel stuff.

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

Daniel Vetter writes: > I just figured that -modesetting would be the simplest domenstration > vehicle, since the vulkan patches don't look ready yet. I need fully > reviewed userspace before we can land any kernel stuff. Doing > the quick modesetting conversion would unblock.

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

Daniel Vetter writes: > I just figured that -modesetting would be the simplest domenstration > vehicle, since the vulkan patches don't look ready yet. I need fully > reviewed userspace before we can land any kernel stuff. Doing > the quick modesetting conversion would unblock. I've provided a

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On Sun, Aug 6, 2017 at 5:32 AM, Keith Packard wrote: > Daniel Vetter writes: > >> Since I missed all the details Michel spotted, so I'll defer to his r-b. >> Also, before merging we need the userspace user. Do we have e.g. >> -modesetting patch for this, fully

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On Sun, Aug 6, 2017 at 5:32 AM, Keith Packard wrote: > Daniel Vetter writes: > >> Since I missed all the details Michel spotted, so I'll defer to his r-b. >> Also, before merging we need the userspace user. Do we have e.g. >> -modesetting patch for this, fully reviewed for merging, just as >>

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On 06/08/17 12:42 PM, Keith Packard wrote: > Michel Dänzer writes: > >> [...] >> >>> +#define DRM_CRTC_SEQUENCE_NEXT_ON_MISS 0x0002 /* Use >>> next sequence if we've missed */ >> >> Do you have userspace making use of DRM_CRTC_SEQUENCE_NEXT_ON_MISS? If

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On 06/08/17 12:42 PM, Keith Packard wrote: > Michel Dänzer writes: > >> [...] >> >>> +#define DRM_CRTC_SEQUENCE_NEXT_ON_MISS 0x0002 /* Use >>> next sequence if we've missed */ >> >> Do you have userspace making use of DRM_CRTC_SEQUENCE_NEXT_ON_MISS? If >> not, drop it. > >

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On 06/08/17 12:32 PM, Keith Packard wrote: > Daniel Vetter writes: > >>> +#define DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT 0x0004 /* Signal when >>> first pixel is displayed */ >> >> Note that right now vblank events are defined as: >> - The even will be delivered "somewhen"

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On 06/08/17 12:32 PM, Keith Packard wrote: > Daniel Vetter writes: > >>> +#define DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT 0x0004 /* Signal when >>> first pixel is displayed */ >> >> Note that right now vblank events are defined as: >> - The even will be delivered "somewhen" around vblank

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

Michel Dänzer writes: > [...] > >> +#define DRM_CRTC_SEQUENCE_NEXT_ON_MISS 0x0002 /* Use >> next sequence if we've missed */ > > Do you have userspace making use of DRM_CRTC_SEQUENCE_NEXT_ON_MISS? If > not, drop it. I added this so that the new ioctl

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

Michel Dänzer writes: > [...] > >> +#define DRM_CRTC_SEQUENCE_NEXT_ON_MISS 0x0002 /* Use >> next sequence if we've missed */ > > Do you have userspace making use of DRM_CRTC_SEQUENCE_NEXT_ON_MISS? If > not, drop it. I added this so that the new ioctl would be compatible

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

Daniel Vetter writes: > Since I missed all the details Michel spotted, so I'll defer to his r-b. > Also, before merging we need the userspace user. Do we have e.g. > -modesetting patch for this, fully reviewed for merging, just as > demonstration? Well, given that we'll have to

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

Daniel Vetter writes: > Since I missed all the details Michel spotted, so I'll defer to his r-b. > Also, before merging we need the userspace user. Do we have e.g. > -modesetting patch for this, fully reviewed for merging, just as > demonstration? Well, given that we'll have to keep the old API

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On 01/08/17 02:03 PM, Keith Packard wrote: > 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 > >

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On 01/08/17 02:03 PM, Keith Packard wrote: > 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 > >

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On Mon, Jul 31, 2017 at 10:03:06PM -0700, Keith Packard wrote: > 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

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

On Mon, Jul 31, 2017 at 10:03:06PM -0700, Keith Packard wrote: > 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

[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

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

[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

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

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 6, 2017 at 6:27 PM, Keith Packard wrote: > Daniel Vetter writes: > >> I very much like this since the old ioctl really is a rather bad horror >> show. And since it's tied in with ums drivers everything is >> complicated. > > Thanks for your kind

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 6, 2017 at 6:27 PM, Keith Packard wrote: > Daniel Vetter writes: > >> I very much like this since the old ioctl really is a rather bad horror >> show. And since it's tied in with ums drivers everything is >> complicated. > > Thanks for your kind words. > >> I started a discussion a

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > With the disable_immediate thing we only wait until the next vblank > before disabling the irq again. Ok, still sounds like we'll be doing fine if the application does a get immediately followed by a queue event. At least most of the time.

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > With the disable_immediate thing we only wait until the next vblank > before disabling the irq again. Ok, still sounds like we'll be doing fine if the application does a get immediately followed by a queue event. At least most of the time. -- -keith signature.asc

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 11:22:43AM -0700, Keith Packard wrote: > Ville Syrjälä writes: > > > I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern > > where we can avoid doing the full update more than once if we enable > > the interrupt already

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 11:22:43AM -0700, Keith Packard wrote: > Ville Syrjälä writes: > > > I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern > > where we can avoid doing the full update more than once if we enable > > the interrupt already during the query. > > Don't we

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern > where we can avoid doing the full update more than once if we enable > the interrupt already during the query. Don't we still wait 5 seconds before disabling vblank? In

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern > where we can avoid doing the full update more than once if we enable > the interrupt already during the query. Don't we still wait 5 seconds before disabling vblank? In that case, the chances of

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 09:28:40AM -0700, Keith Packard wrote: > Ville Syrjälä writes: > > > Maybe, or maybe we want to turn the interrupt on in that case? That's > > what the old ioctl does. > > That's what I suggested in my reply to Daniel's review. Even if we

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 09:28:40AM -0700, Keith Packard wrote: > Ville Syrjälä writes: > > > Maybe, or maybe we want to turn the interrupt on in that case? That's > > what the old ioctl does. > > That's what I suggested in my reply to Daniel's review. Even if we add > the accurate function,

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > Maybe, or maybe we want to turn the interrupt on in that case? That's > what the old ioctl does. That's what I suggested in my reply to Daniel's review. Even if we add the accurate function, we'll still need the interrupt-enable case as a

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > Maybe, or maybe we want to turn the interrupt on in that case? That's > what the old ioctl does. That's what I suggested in my reply to Daniel's review. Even if we add the accurate function, we'll still need the interrupt-enable case as a fallback for drivers which don't

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Daniel Vetter writes: > I very much like this since the old ioctl really is a rather bad horror > show. And since it's tied in with ums drivers everything is > complicated. Thanks for your kind words. > I started a discussion a while back whether these should be restricted to

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Daniel Vetter writes: > I very much like this since the old ioctl really is a rather bad horror > show. And since it's tied in with ums drivers everything is > complicated. Thanks for your kind words. > I started a discussion a while back whether these should be restricted to > DRM_MASTER

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 01:04:18PM +0200, Daniel Vetter wrote: > On Thu, Jul 6, 2017 at 12:16 PM, Ville Syrjälä > wrote: > >> > + if (!dev->irq_enabled) > >> > + return -EINVAL; > >> > + > >> > + crtc = drm_crtc_find(dev, get_seq->crtc_id); > >> > +

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 01:04:18PM +0200, Daniel Vetter wrote: > On Thu, Jul 6, 2017 at 12:16 PM, Ville Syrjälä > wrote: > >> > + if (!dev->irq_enabled) > >> > + return -EINVAL; > >> > + > >> > + crtc = drm_crtc_find(dev, get_seq->crtc_id); > >> > + if (!crtc) > >> > +

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 6, 2017 at 12:16 PM, Ville Syrjälä wrote: >> > + if (!dev->irq_enabled) >> > + return -EINVAL; >> > + >> > + crtc = drm_crtc_find(dev, get_seq->crtc_id); >> > + if (!crtc) >> > + return -ENOENT; >> > + >> > + pipe =

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 6, 2017 at 12:16 PM, Ville Syrjälä wrote: >> > + if (!dev->irq_enabled) >> > + return -EINVAL; >> > + >> > + crtc = drm_crtc_find(dev, get_seq->crtc_id); >> > + if (!crtc) >> > + return -ENOENT; >> > + >> > + pipe = drm_crtc_index(crtc); >> > + >> > +

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 09:53:13AM +0200, Daniel Vetter wrote: > On Wed, Jul 05, 2017 at 03:10:13PM -0700, Keith Packard wrote: > > 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

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 09:53:13AM +0200, Daniel Vetter wrote: > On Wed, Jul 05, 2017 at 03:10:13PM -0700, Keith Packard wrote: > > 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

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Wed, Jul 05, 2017 at 03:10:13PM -0700, Keith Packard wrote: > 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. > > Signed-off-by: Keith Packard I very

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Wed, Jul 05, 2017 at 03:10:13PM -0700, Keith Packard wrote: > 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. > > Signed-off-by: Keith Packard I very much like this

[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

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. Signed-off-by: Keith Packard --- drivers/gpu/drm/drm_internal.h | 6 ++ drivers/gpu/drm/drm_ioctl.c|

[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

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. Signed-off-by: Keith Packard --- drivers/gpu/drm/drm_internal.h | 6 ++ drivers/gpu/drm/drm_ioctl.c| 2 +