Re: [Intel-gfx] [RFC v2 1/8] drm: provide management functions for drm_file

[David Herrmann]

Hi

On Tue, Jan 9, 2018 at 11:20 AM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Wed, Jan 03, 2018 at 11:21:03PM +0100, Noralf Trønnes wrote:
>> From: David Herrmann <dh.herrm...@gmail.com>
>>
>> Rather than doing drm_file allocation/destruction right in the fops, lets
>> provide separate helpers. This decouples drm_file management from the
>> still-mandatory drm-fops. It prepares for use of drm_file without the
>> fops, both by possible separate fops implementations and APIs (not that I
>> am aware of any such plans), and more importantly from in-kernel use where
>> no real file is available.
>>
>> Signed-off-by: David Herrmann <dh.herrm...@gmail.com>
>> [rebased]
>> Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
>> ---

For completeness: Still fine with me! Thanks for picking it up.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v2 3/8] drm: Export some ioctl functions

[David Herrmann]

Hi

On Tue, Jan 9, 2018 at 11:16 AM, Daniel Vetter  wrote:
> On Wed, Jan 03, 2018 at 11:21:05PM +0100, Noralf Trønnes wrote:
>> Export the following functions so in-kernel users can allocate
>> dumb buffers:
>> - drm_file_alloc
>> - drm_file_free
>> - drm_prime_handle_to_fd_ioctl
>> - drm_mode_addfb2
>> - drm_mode_create_dumb_ioctl
>> - drm_dropmaster_ioctl
>>
>> Signed-off-by: Noralf Trønnes 
>> ---
>>  drivers/gpu/drm/drm_auth.c  |  1 +
>>  drivers/gpu/drm/drm_crtc_internal.h |  4 
>>  drivers/gpu/drm/drm_dumb_buffers.c  |  1 +
>>  drivers/gpu/drm/drm_file.c  |  2 ++
>>  drivers/gpu/drm/drm_framebuffer.c   |  1 +
>>  drivers/gpu/drm/drm_internal.h  |  6 --
>>  drivers/gpu/drm/drm_ioctl.c |  1 +
>>  drivers/gpu/drm/drm_prime.c |  1 +
>>  include/drm/drm_auth.h  |  3 +++
>>  include/drm/drm_dumb_buffers.h  | 10 ++
>>  include/drm/drm_file.h  |  2 ++
>>  include/drm/drm_framebuffer.h   |  3 +++
>>  include/drm/drm_prime.h |  2 ++
>>  13 files changed, 27 insertions(+), 10 deletions(-)
>>  create mode 100644 include/drm/drm_dumb_buffers.h
>>
>> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
>> index aad468d170a7..e35ed9ee0c5a 100644
>> --- a/drivers/gpu/drm/drm_auth.c
>> +++ b/drivers/gpu/drm/drm_auth.c
>> @@ -236,6 +236,7 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void 
>> *data,
>>   mutex_unlock(>master_mutex);
>>   return ret;
>>  }
>> +EXPORT_SYMBOL(drm_dropmaster_ioctl);
>>
>>  int drm_master_open(struct drm_file *file_priv)
>>  {
>> diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
>> b/drivers/gpu/drm/drm_crtc_internal.h
>> index 9ebb8841778c..86422492ad00 100644
>> --- a/drivers/gpu/drm/drm_crtc_internal.h
>> +++ b/drivers/gpu/drm/drm_crtc_internal.h
>> @@ -63,8 +63,6 @@ int drm_mode_getresources(struct drm_device *dev,
>>
>>  /* drm_dumb_buffers.c */
>>  /* IOCTLs */
>> -int drm_mode_create_dumb_ioctl(struct drm_device *dev,
>> -void *data, struct drm_file *file_priv);
>>  int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
>>void *data, struct drm_file *file_priv);
>>  int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
>> @@ -164,8 +162,6 @@ void drm_fb_release(struct drm_file *file_priv);
>>  /* IOCTL */
>>  int drm_mode_addfb(struct drm_device *dev,
>>  void *data, struct drm_file *file_priv);
>> -int drm_mode_addfb2(struct drm_device *dev,
>> - void *data, struct drm_file *file_priv);
>>  int drm_mode_rmfb(struct drm_device *dev,
>> void *data, struct drm_file *file_priv);
>>  int drm_mode_getfb(struct drm_device *dev,
>> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c 
>> b/drivers/gpu/drm/drm_dumb_buffers.c
>> index 39ac15ce4702..199b279f7650 100644
>> --- a/drivers/gpu/drm/drm_dumb_buffers.c
>> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
>> @@ -90,6 +90,7 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
>>
>>   return dev->driver->dumb_create(file_priv, dev, args);
>>  }
>> +EXPORT_SYMBOL(drm_mode_create_dumb_ioctl);
>>
>>  /**
>>   * drm_mode_mmap_dumb_ioctl - create an mmap offset for a dumb backing 
>> storage buffer
>> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
>> index d208faade27e..400d44437e93 100644
>> --- a/drivers/gpu/drm/drm_file.c
>> +++ b/drivers/gpu/drm/drm_file.c
>> @@ -180,6 +180,7 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
>>
>>   return ERR_PTR(ret);
>>  }
>> +EXPORT_SYMBOL(drm_file_alloc);
>>
>>  static void drm_events_release(struct drm_file *file_priv)
>>  {
>> @@ -273,6 +274,7 @@ void drm_file_free(struct drm_file *file)
>>   put_pid(file->pid);
>>   kfree(file);
>>  }
>> +EXPORT_SYMBOL(drm_file_free);
>
> I'd put the EXPORT_SYMBOL for the drm_file stuff into the first patch.
> That way it's next to the kerneldoc and code all in the same patch.

I agree. Feel free to amend my patch there.

>>
>>  static int drm_setup(struct drm_device * dev)
>>  {
>> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
>> b/drivers/gpu/drm/drm_framebuffer.c
>> index 5a13ff29f4f0..0493977e6848 100644
>> --- a/drivers/gpu/drm/drm_framebuffer.c
>> +++ b/drivers/gpu/drm/drm_framebuffer.c
>> @@ -341,6 +341,7 @@ int drm_mode_addfb2(struct drm_device *dev,
>>
>>   return 0;
>>  }
>> +EXPORT_SYMBOL(drm_mode_addfb2);
>>
>>  struct drm_mode_rmfb_work {
>>   struct work_struct work;
>> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
>> index 40179c5fc6b8..7d62e412fbb8 100644
>> --- a/drivers/gpu/drm/drm_internal.h
>> +++ b/drivers/gpu/drm/drm_internal.h
>> @@ -26,8 +26,6 @@
>>
>>  /* drm_file.c */
>>  extern struct mutex drm_global_mutex;
>> -struct drm_file *drm_file_alloc(struct drm_minor *minor);
>> -void drm_file_free(struct drm_file *file);
>>  void drm_lastclose(struct drm_device *dev);
>>
>>  /* drm_pci.c */
>> @@ 

Re: [Intel-gfx] [PATCH v4] dma-buf/sync-file: Defer creation of sync_file->name

[David Herrmann]

Hey

On Mon, May 15, 2017 at 1:42 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Mon, May 15, 2017 at 12:50:04PM +0200, David Herrmann wrote:
>> Hey
>>
>> On Mon, May 15, 2017 at 12:10 PM, Chris Wilson <ch...@chris-wilson.co.uk> 
>> wrote:
>> > Constructing the name takes the majority of the time for allocating a
>> > sync_file to wrap a fence, and the name is very rarely used (only via
>> > the sync_file status user interface). To reduce the impact on the common
>> > path (that of creating sync_file to pass around), defer the construction
>> > of the name until it is first used.
>> >
>> > v2: Update kerneldoc (kbuild test robot)
>> > v3: sync_debug.c was peeking at the name
>> > v4: Comment upon the potential race between two users of
>> > sync_file_get_name() and claim that such a race is below the level of
>> > notice. However, to prevent any future nuisance, use a global spinlock
>> > to serialize the assignment of the name.
>> >
>> > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
>> > Cc: Sumit Semwal <sumit.sem...@linaro.org>
>> > Cc: Gustavo Padovan <gust...@padovan.org>
>> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
>> > ---
>> >  drivers/dma-buf/sync_debug.c |  3 ++-
>> >  drivers/dma-buf/sync_file.c  | 54 
>> > ++--
>> >  include/linux/sync_file.h|  5 ++--
>> >  3 files changed, 52 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
>> > index 4b1731ee7458..9a93f1085c63 100644
>> > --- a/drivers/dma-buf/sync_debug.c
>> > +++ b/drivers/dma-buf/sync_debug.c
>> > @@ -134,7 +134,8 @@ static void sync_print_sync_file(struct seq_file *s,
>> >  {
>> > int i;
>> >
>> > -   seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
>> > +   seq_printf(s, "[%p] %s: %s\n", sync_file,
>> > +  sync_file_get_name(sync_file),
>> >
>> > sync_status_str(dma_fence_get_status(sync_file->fence)));
>> >
>> > if (dma_fence_is_array(sync_file->fence)) {
>> > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
>> > index c9eb4997cfcc..0d54de79ba76 100644
>> > --- a/drivers/dma-buf/sync_file.c
>> > +++ b/drivers/dma-buf/sync_file.c
>> > @@ -80,11 +80,6 @@ struct sync_file *sync_file_create(struct dma_fence 
>> > *fence)
>> >
>> > sync_file->fence = dma_fence_get(fence);
>> >
>> > -   snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
>> > -fence->ops->get_driver_name(fence),
>> > -fence->ops->get_timeline_name(fence), fence->context,
>> > -fence->seqno);
>> > -
>> > return sync_file;
>> >  }
>> >  EXPORT_SYMBOL(sync_file_create);
>> > @@ -129,6 +124,51 @@ struct dma_fence *sync_file_get_fence(int fd)
>> >  }
>> >  EXPORT_SYMBOL(sync_file_get_fence);
>> >
>> > +/**
>> > + * sync_file_get_name - get the name of the sync_file
>> > + * @sync_file: sync_file to get the fence from
>> > + *
>> > + * Each sync_file may have a name assigned either by the user (when 
>> > merging
>> > + * sync_files together) or created from the fence it contains. However,
>> > + * construction of the name is deferred until first use.
>> > + *
>> > + * Returns: a string representing the name
>> > + */
>> > +char *sync_file_get_name(struct sync_file *sync_file)
>> > +{
>> > +   static DEFINE_SPINLOCK(name_lock);
>> > +
>> > +   if (!sync_file->user_name[0]) {
>> > +   char buf[sizeof(sync_file->user_name)];
>> > +   struct dma_fence *fence;
>> > +   int len;
>> > +
>> > +   rcu_read_lock();
>> > +   fence = sync_file->fence;
>> > +   len = scnprintf(buf, sizeof(buf), "%s-%s%llu-%d",
>> > +   
>> > fence->ops->get_driver_name(sync_file->fence),
>> > +   
>> > fence->ops->get_timeline_name(sync_file->fence),
>> > +   fence->context,
>

Re: [Intel-gfx] [PATCH v4] dma-buf/sync-file: Defer creation of sync_file->name

[David Herrmann]

Hey

On Mon, May 15, 2017 at 12:10 PM, Chris Wilson  wrote:
> Constructing the name takes the majority of the time for allocating a
> sync_file to wrap a fence, and the name is very rarely used (only via
> the sync_file status user interface). To reduce the impact on the common
> path (that of creating sync_file to pass around), defer the construction
> of the name until it is first used.
>
> v2: Update kerneldoc (kbuild test robot)
> v3: sync_debug.c was peeking at the name
> v4: Comment upon the potential race between two users of
> sync_file_get_name() and claim that such a race is below the level of
> notice. However, to prevent any future nuisance, use a global spinlock
> to serialize the assignment of the name.
>
> Signed-off-by: Chris Wilson 
> Cc: Sumit Semwal 
> Cc: Gustavo Padovan 
> Cc: Daniel Vetter 
> ---
>  drivers/dma-buf/sync_debug.c |  3 ++-
>  drivers/dma-buf/sync_file.c  | 54 
> ++--
>  include/linux/sync_file.h|  5 ++--
>  3 files changed, 52 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> index 4b1731ee7458..9a93f1085c63 100644
> --- a/drivers/dma-buf/sync_debug.c
> +++ b/drivers/dma-buf/sync_debug.c
> @@ -134,7 +134,8 @@ static void sync_print_sync_file(struct seq_file *s,
>  {
> int i;
>
> -   seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
> +   seq_printf(s, "[%p] %s: %s\n", sync_file,
> +  sync_file_get_name(sync_file),
>sync_status_str(dma_fence_get_status(sync_file->fence)));
>
> if (dma_fence_is_array(sync_file->fence)) {
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index c9eb4997cfcc..0d54de79ba76 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -80,11 +80,6 @@ struct sync_file *sync_file_create(struct dma_fence *fence)
>
> sync_file->fence = dma_fence_get(fence);
>
> -   snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
> -fence->ops->get_driver_name(fence),
> -fence->ops->get_timeline_name(fence), fence->context,
> -fence->seqno);
> -
> return sync_file;
>  }
>  EXPORT_SYMBOL(sync_file_create);
> @@ -129,6 +124,51 @@ struct dma_fence *sync_file_get_fence(int fd)
>  }
>  EXPORT_SYMBOL(sync_file_get_fence);
>
> +/**
> + * sync_file_get_name - get the name of the sync_file
> + * @sync_file: sync_file to get the fence from
> + *
> + * Each sync_file may have a name assigned either by the user (when merging
> + * sync_files together) or created from the fence it contains. However,
> + * construction of the name is deferred until first use.
> + *
> + * Returns: a string representing the name
> + */
> +char *sync_file_get_name(struct sync_file *sync_file)
> +{
> +   static DEFINE_SPINLOCK(name_lock);
> +
> +   if (!sync_file->user_name[0]) {
> +   char buf[sizeof(sync_file->user_name)];
> +   struct dma_fence *fence;
> +   int len;
> +
> +   rcu_read_lock();
> +   fence = sync_file->fence;
> +   len = scnprintf(buf, sizeof(buf), "%s-%s%llu-%d",
> +   fence->ops->get_driver_name(sync_file->fence),
> +   
> fence->ops->get_timeline_name(sync_file->fence),
> +   fence->context,
> +   fence->seqno);
> +
> +   /* This is mildly racy, so we stage the printf into a local
> +* buffer and do the copy with preempt disabled to trim the
> +* race down to a few cycles. To completely eliminate the
> +* race, we do the final assignment underneath a global
> +* spinlock. A global lock should be adequate here for this
> +* rare path (called from the middle of a user sw_sync status
> +* ioctl and from debugfs).
> +*/
> +   spin_lock(_lock);
> +   if (!sync_file->user_name[0])
> +   memcpy(sync_file->user_name, buf, len + 1);

A racing reader might get a truncated string here. Note that a racing
reader does not take the lock as soon as the first byte is visible.
Not sure what the name is used for, but with that code it is not
reliable.

Also, please zero-terminate the string... scnprintf() does not
guarantee that, if it follows posix.

> +   spin_unlock(_lock);
> +   rcu_read_unlock();
> +   }
> +
> +   return sync_file->user_name;
> +}
> +
>  static int sync_file_set_fence(struct sync_file *sync_file,
>struct dma_fence **fences, int num_fences)
>  {
> @@ -266,7 +306,7 @@ static struct sync_file *sync_file_merge(const char 
> *name, 

Re: [Intel-gfx] [PATCH] drm: Document code of conduct

[David Herrmann]

Hey

On Tue, Apr 11, 2017 at 8:48 AM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> freedesktop.org has adopted a formal code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
> anything for us, we've already peer-enforced respectful and
> constructive interactions since a long time. But it's good to document
> things properly.
>
> Note: As Daniel Stone mentioned in the announcement fd.o admins
> started chatting with the communities their hosting, which includs the
> X.org foundation board, to figure out how to fan out enforcement and
> allow projects to run things on their own (with fd.o still as the
> fallback).  So the details of enforcement (and appealing decisions)
> might still change, but since this involves the board and lots more
> people it'll take a while to get there. For now this is good enough I
> think.
>
> For the text itself I went with the same blurb as the Wayland project,
> didn't feel creative yet this early in the morning:
>
> https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c
>
> Cc: Daniel Stone <dani...@collabora.com>
> Cc: Keith Packard <kei...@keithp.com>
> Cc: tfh...@err.no
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> ---
>  Documentation/gpu/introduction.rst | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/gpu/introduction.rst 
> b/Documentation/gpu/introduction.rst
> index 05a82bdfbca4..0f5173e29bdc 100644
> --- a/Documentation/gpu/introduction.rst
> +++ b/Documentation/gpu/introduction.rst
> @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one 
> month where feature work
>  can't be merged. The recommended way to deal with that is having a -next tree
>  that's always open, but making sure to not feed it into linux-next during the
>  blackout period. As an example, drm-misc works like that.
> +
> +Code of Conduct
> +---
> +
> +As a freedesktop.org project, dri-devel and the DRM community follows the
> +Contributor Covenant, found at: 
> https://www.freedesktop.org/wiki/CodeOfConduct
> +
> +Please conduct yourself in a respectful and civilised manner when
> +interacting with community members on mailing lists, IRC, or bug
> +trackers. The community represents the project as a whole, and abusive
> +or bullying behaviour is not tolerated by the project.
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/24] drm: Remove DRM_MINOR_CNT

[David Herrmann]

Hi

On Wed, Mar 8, 2017 at 3:12 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> This was originally added by David Herrmann for range checks, but
> entirely unused. It confused me, so let's remove it.
>
> Cc: David Herrmann <dh.herrm...@gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
>  include/drm/drmP.h | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 826101785876..7bd6752683a4 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -444,7 +444,6 @@ enum drm_minor_type {
> DRM_MINOR_PRIMARY,
> DRM_MINOR_CONTROL,
> DRM_MINOR_RENDER,
> -   DRM_MINOR_CNT,
>  };
>
>  /**
> --
> 2.11.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/17] drm/atomic-helpers: Remove outdated comment

[David Herrmann]

Hi

On Thu, Dec 29, 2016 at 9:48 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> We forgot to clean this up when adding connector refcounting.
>
> Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 5 -
>  1 file changed, 5 deletions(-)

Patch 1-10 all:

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 8eab8944c736..5e5224460042 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3286,11 +3286,6 @@ EXPORT_SYMBOL(drm_atomic_helper_duplicate_state);
>  void
>  __drm_atomic_helper_connector_destroy_state(struct drm_connector_state 
> *state)
>  {
> -   /*
> -* This is currently a placeholder so that drivers that subclass the
> -* state will automatically do the right thing if code is ever added
> -* to this function.
> -*/
> if (state->crtc)
> drm_connector_unreference(state->connector);
>  }
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/17] dma-buf: use preferred struct reference in kernel-doc

[David Herrmann]

Hi

On Thu, Dec 29, 2016 at 9:48 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\ \2/' -i
>
> Originally I wasnt a friend of this style because I thought a
> line-break between the "" and "foo" part would break it. But a
> quick test shows that " *  \n * foo\n" works pefectly well with
> current kernel-doc. So time to mass-apply these changes!
>
> Cc: Sumit Semwal <sumit.sem...@linaro.org>
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
>  drivers/dma-buf/dma-buf.c | 6 +++---
>  include/linux/dma-buf.h   | 4 ++--
>  2 files changed, 5 insertions(+), 5 deletions(-)

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 91aff74ed092..ab814aff0a5b 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -128,7 +128,7 @@ static loff_t dma_buf_llseek(struct file *file, loff_t 
> offset, int whence)
>   * DOC: fence polling
>   *
>   * To support cross-device and cross-driver synchronization of buffer access
> - * implicit fences (represented internally in the kernel with struct ) 
> can
> + * implicit fences (represented internally in the kernel with  fence) 
> can
>   * be attached to a _buf. The glue for that and a few related things are
>   * provided in the _object structure.
>   *
> @@ -373,7 +373,7 @@ static inline int is_dma_buf_file(struct file *file)
>   * Additionally, provide a name string for exporter; useful in debugging.
>   *
>   * @exp_info:  [in]holds all the export related information provided
> - * by the exporter. see struct _buf_export_info
> + * by the exporter. see  dma_buf_export_info
>   * for further details.
>   *
>   * Returns, on success, a newly created dma_buf object, which wraps the
> @@ -517,7 +517,7 @@ EXPORT_SYMBOL_GPL(dma_buf_get);
>   *
>   * If, as a result of this call, the refcount becomes 0, the 'release' file
>   * operation related to this fd is called. It calls the release operation of
> - * struct _buf_ops in turn, and frees the memory allocated for dmabuf 
> when
> + *  dma_buf_ops in turn, and frees the memory allocated for dmabuf 
> when
>   * exported.
>   */
>  void dma_buf_put(struct dma_buf *dmabuf)
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 57828154e440..4d61fc55278b 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -278,7 +278,7 @@ struct dma_buf_ops {
>   * Shared dma buffers are reference counted using dma_buf_put() and
>   * get_dma_buf().
>   *
> - * Device DMA access is handled by the separate struct _buf_attachment.
> + * Device DMA access is handled by the separate  dma_buf_attachment.
>   */
>  struct dma_buf {
> size_t size;
> @@ -355,7 +355,7 @@ struct dma_buf_export_info {
>   * DEFINE_DMA_BUF_EXPORT_INFO - helper macro for exporters
>   * @name: export-info name
>   *
> - * DEFINE_DMA_BUF_EXPORT_INFO macro defines the struct _buf_export_info,
> + * DEFINE_DMA_BUF_EXPORT_INFO macro defines the  dma_buf_export_info,
>   * zeroes it out and pre-populates exp_name in it.
>   */
>  #define DEFINE_DMA_BUF_EXPORT_INFO(name)   \
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/17] drm/mm: Some doc polish

[David Herrmann]

Hi

On Thu, Dec 29, 2016 at 9:48 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> Added some boilerplate for the structs, documented members where they
> are relevant and plenty of markup for hyperlinks all over. And a few
> small wording polish.
>
> Note that the intro needs some more love after the DRM_MM_INSERT_*
> patch from Chris has landed.
>
> v2: Spelling fixes (Chris).
>
> v3: Use  foo instead of  structure (Chris).
>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
>  Documentation/gpu/drm-mm.rst |  2 +-
>  drivers/gpu/drm/drm_mm.c | 41 +++--
>  include/drm/drm_mm.h | 84 
> ++--
>  3 files changed, 89 insertions(+), 38 deletions(-)

I liked the "DRM Roaster" more than the "Roster"!

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index cb5daffcd6be..5355e5ad51a7 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -442,7 +442,7 @@ LRU Scan/Eviction Support
>  -
>
>  .. kernel-doc:: drivers/gpu/drm/drm_mm.c
> -   :doc: lru scan roaster
> +   :doc: lru scan roster
>
>  DRM MM Range Allocator Function References
>  --
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index e54aa3fa538f..229b3f525dee 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -59,8 +59,8 @@
>   *
>   * The main data struct is _mm, allocations are tracked in _mm_node.
>   * Drivers are free to embed either of them into their own suitable
> - * datastructures. drm_mm itself will not do any allocations of its own, so 
> if
> - * drivers choose not to embed nodes they need to still allocate them
> + * datastructures. drm_mm itself will not do any memory allocations of its 
> own,
> + * so if drivers choose not to embed nodes they need to still allocate them
>   * themselves.
>   *
>   * The range allocator also supports reservation of preallocated blocks. 
> This is
> @@ -78,7 +78,7 @@
>   * steep cliff not a real concern. Removing a node again is O(1).
>   *
>   * drm_mm supports a few features: Alignment and range restrictions can be
> - * supplied. Further more every _mm_node has a color value (which is 
> just an
> + * supplied. Furthermore every _mm_node has a color value (which is just 
> an
>   * opaque unsigned long) which in conjunction with a driver callback can be 
> used
>   * to implement sophisticated placement restrictions. The i915 DRM driver 
> uses
>   * this to implement guard pages between incompatible caching domains in the
> @@ -296,11 +296,11 @@ static void drm_mm_insert_helper(struct drm_mm_node 
> *hole_node,
>   * @mm: drm_mm allocator to insert @node into
>   * @node: drm_mm_node to insert
>   *
> - * This functions inserts an already set-up drm_mm_node into the allocator,
> - * meaning that start, size and color must be set by the caller. This is 
> useful
> - * to initialize the allocator with preallocated objects which must be set-up
> - * before the range allocator can be set-up, e.g. when taking over a firmware
> - * framebuffer.
> + * This functions inserts an already set-up _mm_node into the allocator,
> + * meaning that start, size and color must be set by the caller. All other
> + * fields must be cleared to 0. This is useful to initialize the allocator 
> with
> + * preallocated objects which must be set-up before the range allocator can 
> be
> + * set-up, e.g. when taking over a firmware framebuffer.
>   *
>   * Returns:
>   * 0 on success, -ENOSPC if there's no hole where @node is.
> @@ -375,7 +375,7 @@ EXPORT_SYMBOL(drm_mm_reserve_node);
>   * @sflags: flags to fine-tune the allocation search
>   * @aflags: flags to fine-tune the allocation behavior
>   *
> - * The preallocated node must be cleared to 0.
> + * The preallocated @node must be cleared to 0.
>   *
>   * Returns:
>   * 0 on success, -ENOSPC if there's no suitable hole.
> @@ -537,7 +537,7 @@ void drm_mm_replace_node(struct drm_mm_node *old, struct 
> drm_mm_node *new)
>  EXPORT_SYMBOL(drm_mm_replace_node);
>
>  /**
> - * DOC: lru scan roaster
> + * DOC: lru scan roster
>   *
>   * Very often GPUs need to have continuous allocations for a given object. 
> When
>   * evicting objects to make space for a new one it is therefore not most
> @@ -549,9 +549,11 @@ EXPORT_SYMBOL(drm_mm_replace_node);
>   * The DRM range allocator supports this use-case t

Re: [Intel-gfx] [PATCH 01/17] drm/docs: Small cleanup in drm-uapi.rst

[David Herrmann]

Hi

On Thu, Dec 29, 2016 at 9:48 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> - Remove the outdated hunk about driver documentation which somehow
>   got misplaced here in the split-up.
>
> - Collect all the testing stuff together and give the CRC
>   section a heading for prettier output.
>
> Cc: Tomeu Vizoso <tomeu.viz...@collabora.com>
> Cc: Jani Nikula <jani.nik...@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
>  Documentation/gpu/drm-uapi.rst | 25 +++--
>  1 file changed, 11 insertions(+), 14 deletions(-)

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index de3ac9f90f8f..fcc228ef5bc4 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -156,8 +156,12 @@ other hand, a driver requires shared state between 
> clients which is
>  visible to user-space and accessible beyond open-file boundaries, they
>  cannot support render nodes.
>
> +
> +Testing and validation
> +==
> +
>  Validating changes with IGT
> -===
> +---
>
>  There's a collection of tests that aims to cover the whole functionality of
>  DRM drivers and that can be used to check that changes to DRM drivers or the
> @@ -193,6 +197,12 @@ run-tests.sh is a wrapper around piglit that will 
> execute the tests matching
>  the -t options. A report in HTML format will be available in
>  ./results/html/index.html. Results can be compared with piglit.
>
> +Display CRC Support
> +---
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
> +   :doc: CRC ABI
> +
>  VBlank event handling
>  =
>
> @@ -209,16 +219,3 @@ DRM_IOCTL_MODESET_CTL
>  mode setting, since on many devices the vertical blank counter is
>  reset to 0 at some point during modeset. Modern drivers should not
>  call this any more since with kernel mode setting it is a no-op.
> -
> -This second part of the GPU Driver Developer's Guide documents driver
> -code, implementation details and also all the driver-specific userspace
> -interfaces. Especially since all hardware-acceleration interfaces to
> -userspace are driver specific for efficiency and other reasons these
> -interfaces can be rather substantial. Hence every driver has its own
> -chapter.
> -
> -Testing and validation
> -==
> -
> -.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
> -   :doc: CRC ABI
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/34] drm: Add a simple linear congruent generator PRNG

[David Herrmann]

Hey Chris

On Tue, Dec 13, 2016 at 4:40 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Tue, Dec 13, 2016 at 04:18:35PM +0100, David Herrmann wrote:
>> On Tue, Dec 13, 2016 at 4:16 PM, David Herrmann <dh.herrm...@gmail.com> 
>> wrote:
>> > On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson <ch...@chris-wilson.co.uk> 
>> > wrote:
>> > for (i = 0; i < count; ++i)
>> > swap(order[i], order[drm_lcg_random(state) % count]);
>> >
>> > Much simpler and I cannot see why it wouldn't work.
>>
>> Hint: swap() does multiple evaluations. So this needs to be:
>
> Hmm, and on switching to size_t count may be larger than u32...

I didn't mean to suggest 'size_t'. All I cared about was 'unsigned'.
So feel free to use 'u32', 'unsigned int', 'size_t', etc.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/34] drm: Add a simple linear congruent generator PRNG

[David Herrmann]

On Tue, Dec 13, 2016 at 4:16 PM, David Herrmann <dh.herrm...@gmail.com> wrote:
> On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson <ch...@chris-wilson.co.uk> 
> wrote:
> for (i = 0; i < count; ++i)
> swap(order[i], order[drm_lcg_random(state) % count]);
>
> Much simpler and I cannot see why it wouldn't work.

Hint: swap() does multiple evaluations. So this needs to be:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/34] drm: Add a simple linear congruent generator PRNG

[David Herrmann]

Hey Chris

On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson  wrote:
> For testing, we want a reproducible PRNG, a plain linear congruent
> generator is suitable for our very limited selftests.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/Kconfig|  5 +
>  drivers/gpu/drm/Makefile   |  1 +
>  drivers/gpu/drm/lib/drm_rand.c | 51 
> ++
>  drivers/gpu/drm/lib/drm_rand.h |  9 
>  4 files changed, 66 insertions(+)
>  create mode 100644 drivers/gpu/drm/lib/drm_rand.c
>  create mode 100644 drivers/gpu/drm/lib/drm_rand.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index fd341ab69c46..04d1d0a32c5c 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -48,10 +48,15 @@ config DRM_DEBUG_MM
>
>   If in doubt, say "N".
>
> +config DRM_LIB_RAND
> +   bool
> +   default n
> +
>  config DRM_DEBUG_MM_SELFTEST
> tristate "kselftests for DRM range manager (struct drm_mm)"
> depends on DRM
> depends on DEBUG_KERNEL
> +   select DRM_LIB_RAND
> default n
> help
>   This option provides a kernel module that can be used to test
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index c8aed3688b20..363eb1a23151 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -18,6 +18,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
> drm_plane.o drm_color_mgmt.o drm_print.o \
> drm_dumb_buffers.o drm_mode_config.o
>
> +drm-$(CONFIG_DRM_LIB_RAND) += lib/drm_rand.o
>  obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/test-drm_mm.o
>
>  drm-$(CONFIG_COMPAT) += drm_ioc32.o
> diff --git a/drivers/gpu/drm/lib/drm_rand.c b/drivers/gpu/drm/lib/drm_rand.c
> new file mode 100644
> index ..f203c47bb525
> --- /dev/null
> +++ b/drivers/gpu/drm/lib/drm_rand.c
> @@ -0,0 +1,51 @@
> +#include 
> +#include 
> +#include 
> +
> +#include "drm_rand.h"
> +
> +u32 drm_lcg_random(u32 *state)
> +{
> +   u32 s = *state;
> +
> +#define rol(x, k) (((x) << (k)) | ((x) >> (32 - (k
> +   s = (s ^ rol(s, 5) ^ rol(s, 24)) + 0x37798849;
> +#undef rol

#include 

static inline __u32 rol32(__u32 word, unsigned int shift);

Allows you to get rid of "rol()" and the temporary "u32 s;".

> +
> +   *state = s;
> +   return s;
> +}
> +EXPORT_SYMBOL(drm_lcg_random);
> +
> +int *drm_random_reorder(int *order, int count, u32 *state)
> +{
> +   int n;
> +
> +   for (n = count-1; n > 1; n--) {
> +   int r = drm_lcg_random(state) % (n + 1);
> +   if (r != n) {

Why not drop that condition? No harm in doing the self-swap, is there?
Makes the code shorter.

> +   int tmp = order[n];
> +   order[n] = order[r];
> +   order[r] = tmp;

swap() in 

> +   }
> +   }

Is there a specific reason to do it that way? How about:

for (i = 0; i < count; ++i)
swap(order[i], order[drm_lcg_random(state) % count]);

Much simpler and I cannot see why it wouldn't work.

> +
> +   return order;

You sure that return value serves any purpose? Is that convenience so
you can use the function in a combined statement?

> +}
> +EXPORT_SYMBOL(drm_random_reorder);
> +
> +int *drm_random_order(int count, u32 *state)
> +{
> +   int *order;
> +   int n;
> +
> +   order = kmalloc_array(count, sizeof(*order), GFP_TEMPORARY);
> +   if (!order)
> +   return order;
> +
> +   for (n = 0; n < count; n++)
> +   order[n] = n;
> +
> +   return drm_random_reorder(order, count, state);

Why "signed int"? We very often use "size_t" to count things. By
making the order signed you just keep running into "comparing signed
vs unsigned" warnings, don't you?

> +}
> +EXPORT_SYMBOL(drm_random_order);
> diff --git a/drivers/gpu/drm/lib/drm_rand.h b/drivers/gpu/drm/lib/drm_rand.h
> new file mode 100644
> index ..a3f22d115aac
> --- /dev/null
> +++ b/drivers/gpu/drm/lib/drm_rand.h
> @@ -0,0 +1,9 @@
> +#ifndef __DRM_RAND_H__
> +#define __DRM_RAND_H
> +
> +u32 drm_lcg_random(u32 *state);
> +
> +int *drm_random_reorder(int *order, int count, u32 *state);
> +int *drm_random_order(int count, u32 *state);
> +
> +#endif /* __DRM_RAND_H__ */

"random.h". Why the abbreviation?

Looks good to me. Only nitpicks, so feel free to ignore.

Thanks
David

> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

[David Herrmann]

Hey

On Fri, Dec 9, 2016 at 2:56 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter to where we want to go with libdrm device
> handling. The function looks in the device hierarchy for whether
> controlD* exist using the following format string:
>
> /sys/bus/pci/devices/%04x:%02x:%02x.%d/drm/controlD%d
>
> The "/drm" subdirectory is the glue directory from the sysfs class
> stuff, and the only way to get at it seems to through
> kdev->kobj.parent (when kdev is represents e.g. the card0 chardev
> instance in sysfs). Git grep says we're not the only ones touching
> that, so I hope it's ok we dig into such internals - I couldn't find a
> proper interface for getting at the glue directory.
>
> Quick git grep shows that at least -amdgpu, -ati are using this.
> -modesetting do not, and on -intel it's only about the 4th fallback
> path for device lookup, which is why this didn't blow up earlier.
>
> Oh well, we need to keep it working, and the simplest way is to add a
> symlink at the right place in sysfs from controlD* to card*.
>
> v2:
> - Fix error path handling by adding if (!minor) return checks (David)
> - Fix the controlD* numbers to match what's been there (David)
> - Add a comment what exactly userspace minimally needs.
> - Correct the analysis for -intel (Chris).
>
> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
> Cc: Dave Airlie <airl...@gmail.com>
> Reported-by: Alex Deucher <alexander.deuc...@amd.com>
> Cc: Alex Deucher <alexander.deuc...@amd.com>
> Cc: David Herrmann <dh.herrm...@gmail.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
>  drivers/gpu/drm/drm_drv.c | 62 
> +++
>  1 file changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 4ec61ac27477..4a7b3e98d586 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -650,6 +650,62 @@ void drm_dev_unref(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_dev_unref);
>
> +static int create_compat_control_link(struct drm_device *dev)
> +{
> +   struct drm_minor *minor;
> +   char *name;
> +   int ret;
> +
> +   if (!drm_core_check_feature(dev, DRIVER_MODESET))
> +   return 0;
> +
> +   minor = *drm_minor_get_slot(dev, DRM_MINOR_PRIMARY);
> +   if (!minor)
> +   return 0;
> +
> +   /*
> +* Some existing userspace out there uses the existing of the 
> controlD*
> +* sysfs files to figure out whether it's a modeset driver. It only 
> does
> +* readdir, hence a symlink is sufficient (and the least confusing
> +* option). Otherwise controlD* is entirely unused.
> +*
> +* Old controlD chardev have been allocated in the range
> +* 64-127.
> +*/
> +   name = kasprintf(GFP_KERNEL, "controlD%d", minor->index + 64);
> +   if (!name)
> +   return -ENOMEM;
> +
> +   ret = sysfs_create_link(minor->kdev->kobj.parent,
> +   >kdev->kobj,
> +   name);
> +
> +   kfree(name);
> +
> +   return ret;
> +}
> +
> +static void remove_compat_control_link(struct drm_device *dev)
> +{
> +   struct drm_minor *minor;
> +   char *name;
> +
> +   if (!drm_core_check_feature(dev, DRIVER_MODESET))
> +   return;
> +
> +   minor = *drm_minor_get_slot(dev, DRM_MINOR_PRIMARY);
> +   if (!minor)
> +   return;
> +
> +   name = kasprintf(GFP_KERNEL, "controlD%d", minor->index);
> +   if (!name)
> +   return;

"%d" is at most 11 characters:

char name[8 + 11 + 1];

snprintf(name, sizeof(name), "controlD%d", minor->index);
sysfs_{create,remove}_link(...);

Makes the code in both paths a lot simpler, at the cost of doing
buffer-length calculations. Also, it avoids failure in the cleanup
path (even though kasprintf() failure is impossible for small
buffers). I prefer anything that is not asprintf(). Up to you.

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> +
> +   sysfs_remove_link(minor->kdev->kobj.parent, name);
> +
> +   kfree(name);
> +}
> +
>  /**
>   * drm_dev_register - Register DRM device
>   * @dev

Re: [Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

[David Herrmann]

Hi Greg

On Fri, Dec 9, 2016 at 11:53 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Fri, Dec 09, 2016 at 11:42:01AM +0100, Daniel Vetter wrote:
>> We thought that no userspace is using them, but oops libdrm is using
>> them to figure out whether a driver supports modesetting. Check out
>> drmCheckModesettingSupported but maybe don't because it's horrible and
>> totally runs counter to where we want to go with libdrm device
>> handling. The function looks in the device hierarchy for whether
>> controlD* exist using the following format string:
>>
>> /sys/bus/pci/devices/%04x:%02x:%02x.%d/drm/controlD%d
>>
>> The "/drm" subdirectory is the glue directory from the sysfs class
>> stuff, and the only way to get at it seems to through
>> kdev->kobj.parent (when kdev is represents e.g. the card0 chardev
>> instance in sysfs). Git grep says we're not the only ones touching
>> that, so I hope it's ok we dig into such internals - I couldn't find a
>> proper interface for getting at the glue directory.
>>
>> Quick git grep shows that at least -amdgpu, -ati and UXA in -intel are
>> using this. -modesetting and SNA in -intel do not, which is why this
>> didn't blow up earlier.
>>
>> Oh well, we need to keep it working, and the simplest way is to add a
>> symlink at the right place in debugfs from controlD* to card*.
>
> In debugfs?  This patch seems to be for sysfs.

Yes, typo. It is meant to be sysfs.

>> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
>> Cc: Dave Airlie <airl...@gmail.com>
>> Reported-by: Alex Deucher <alexander.deuc...@amd.com>
>> Cc: Alex Deucher <alexander.deuc...@amd.com>
>> Cc: David Herrmann <dh.herrm...@gmail.com>
>> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
>> ---
>>  drivers/gpu/drm/drm_drv.c | 47 
>> +++
>>  1 file changed, 47 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 4ec61ac27477..5baec7202558 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -650,6 +650,47 @@ void drm_dev_unref(struct drm_device *dev)
>>  }
>>  EXPORT_SYMBOL(drm_dev_unref);
>>
>> +static int create_compat_control_link(struct drm_device *dev)
>> +{
>> + struct drm_minor *minor;
>> + char *name;
>> + int ret;
>> +
>> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
>> + return 0;
>> +
>> + minor = *drm_minor_get_slot(dev, DRM_MINOR_PRIMARY);
>> + name = kasprintf(GFP_KERNEL, "controlD%d", minor->index);
>> + if (!name)
>> + return -ENOMEM;
>> +
>> + ret = sysfs_create_link(minor->kdev->kobj.parent,
>> + >kdev->kobj,
>> + name);
>
> Ick.  Dropping down to a sysfs call and a kobject isn't nice in driver
> code, but I guess the driver core doesn't provide symlinks.  We do
> provide the "class_compat" functionality, but that doesn't really apply
> here.
>
> So, what happened, you just added a "middle layer" device object for
> these control files?
>
> If you need these compatibility symlinks, why even do the original code
> at all?  That kind of implies it shouldn't have been made one layer
> deeper if it was going to break userspace somehow.
>
> If you add these, what's the odds that they ever can be removed
> (probably never, right?)

Yes. The alternative would be to create a dummy "struct device" and
register it, but do not include any information on it. I don't think
we need the symlink-behavior. Daniel? But the symlink would at least
be kinda useful. The dummy device, on the other hand, would just make
sure the readdir() calls of legacy stuff sees the control nodes (even
though they never use it).

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

[David Herrmann]

Hey

On Fri, Dec 9, 2016 at 11:42 AM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter to where we want to go with libdrm device
> handling. The function looks in the device hierarchy for whether
> controlD* exist using the following format string:
>
> /sys/bus/pci/devices/%04x:%02x:%02x.%d/drm/controlD%d
>
> The "/drm" subdirectory is the glue directory from the sysfs class
> stuff, and the only way to get at it seems to through
> kdev->kobj.parent (when kdev is represents e.g. the card0 chardev
> instance in sysfs). Git grep says we're not the only ones touching
> that, so I hope it's ok we dig into such internals - I couldn't find a
> proper interface for getting at the glue directory.
>
> Quick git grep shows that at least -amdgpu, -ati and UXA in -intel are
> using this. -modesetting and SNA in -intel do not, which is why this
> didn't blow up earlier.
>
> Oh well, we need to keep it working, and the simplest way is to add a
> symlink at the right place in debugfs from controlD* to card*.
>
> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
> Cc: Dave Airlie <airl...@gmail.com>
> Reported-by: Alex Deucher <alexander.deuc...@amd.com>
> Cc: Alex Deucher <alexander.deuc...@amd.com>
> Cc: David Herrmann <dh.herrm...@gmail.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
>  drivers/gpu/drm/drm_drv.c | 47 
> +++
>  1 file changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 4ec61ac27477..5baec7202558 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -650,6 +650,47 @@ void drm_dev_unref(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_dev_unref);
>
> +static int create_compat_control_link(struct drm_device *dev)
> +{
> +   struct drm_minor *minor;
> +   char *name;
> +   int ret;
> +
> +   if (!drm_core_check_feature(dev, DRIVER_MODESET))
> +   return 0;
> +
> +   minor = *drm_minor_get_slot(dev, DRM_MINOR_PRIMARY);

if (!minor)
return -EINVAL;

(I don't insist on that one, but see below)

> +   name = kasprintf(GFP_KERNEL, "controlD%d", minor->index);

Wrong index, right? This would use '0' rather than '64'. Probably does
not matter, though.

> +   if (!name)
> +   return -ENOMEM;
> +
> +   ret = sysfs_create_link(minor->kdev->kobj.parent,
> +   >kdev->kobj,
> +   name);
> +
> +   kfree(name);
> +
> +   return ret;
> +}
> +
> +static void remove_compat_control_link(struct drm_device *dev)
> +{
> +   struct drm_minor *minor;
> +   char *name;
> +
> +   if (!drm_core_check_feature(dev, DRIVER_MODESET))
> +   return;
> +
> +   minor = *drm_minor_get_slot(dev, DRM_MINOR_PRIMARY);

if (!minor)
return;

I mean, our error-paths often coalesce multiple similar destructor
calls, and expect the destructor calls. So no reason to assume the
primary-node is initialized. In fact, our drm_dev_register() creates
the primary node last, so if the render-node creation fails we will
call here and NULL-deref.

Otherwise looks good to me.

Thanks
David

> +   name = kasprintf(GFP_KERNEL, "controlD%d", minor->index);
> +   if (!name)
> +   return;
> +
> +   sysfs_remove_link(minor->kdev->kobj.parent, name);
> +
> +   kfree(name);
> +}
> +
>  /**
>   * drm_dev_register - Register DRM device
>   * @dev: Device to register
> @@ -688,6 +729,10 @@ int drm_dev_register(struct drm_device *dev, unsigned 
> long flags)
> if (ret)
> goto err_minors;
>
> +   ret = create_compat_control_link(dev);
> +   if (ret)
> +   goto err_minors;
> +
> if (dev->driver->load) {
> ret = dev->driver->load(dev, flags);
> if (ret)
> @@ -701,6 +746,7 @@ int drm_dev_register(struct drm_device *dev, unsigned 
> long flags)
> goto out_unlock;
>
>  err_minors:
> +   remove_compat_control_link(dev);
> drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
> drm_minor_unregister(dev, DRM_MINOR_RENDER);
> drm_minor_unregister(dev, DRM_MINOR_CONTROL);
> @@ -741,6 +787,7 @@ void drm_dev_unregister(stru

Re: [Intel-gfx] [PATCH] drm: Convert prime dma-buf <-> handle to rbtree

[David Herrmann]

Hi Chris

On Mon, Sep 26, 2016 at 10:44 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> Currently we use a linear walk to lookup a handle and return a dma-buf,
> and vice versa. A long overdue TODO task is to convert that to a
> hashtable. Since the initial implementation of dma-buf/prime, we now
> have resizeable hashtables we can use (and now a future task is to RCU
> enable the lookup!). However, this patch opts to use an rbtree instead
> to provide O(lgN) lookups (and insertion, deletion). rbtrees were chosen
> over using the RCU backed resizable hashtable to firstly avoid the
> reallocations (rbtrees can be embedded entirely within the parent
> struct) and to favour simpler code with predictable worst case
> behaviour. In simple testing, the difference between using the constant
> lookup and insertion of the rhashtable and the rbtree was less than 10%
> of the wall time (igt/benchmarks/prime_lookup) - both are dramatic
> improvements over the existing linear lists.
>
> v2: Favour rbtree over rhashtable
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94631
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Sean Paul <seanp...@chromium.org>
> Cc: David Herrmann <dh.herrm...@gmail.com>
> ---
>  drivers/gpu/drm/drm_prime.c | 85 
> +++--
>  include/drm/drmP.h  |  5 +--
>  2 files changed, 77 insertions(+), 13 deletions(-)

Thanks for doing the benchmark and rewriting it with rb-trees. I think
the lack of error-handling is a big plus here. Anyway, this is:

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Your tree-traversals are a bit inconsistent in how you order your
iterator against the element to lookup in your conditions, but.. meh.
A big WARN_ON on conflicts might not hurt either. But looks all good.

Thanks
David

> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 780589b420a4..57201d68cf61 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -28,6 +28,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -61,9 +62,11 @@
>   */
>
>  struct drm_prime_member {
> -   struct list_head entry;
> struct dma_buf *dma_buf;
> uint32_t handle;
> +
> +   struct rb_node dmabuf_rb;
> +   struct rb_node handle_rb;
>  };
>
>  struct drm_prime_attachment {
> @@ -75,6 +78,7 @@ static int drm_prime_add_buf_handle(struct 
> drm_prime_file_private *prime_fpriv,
> struct dma_buf *dma_buf, uint32_t handle)
>  {
> struct drm_prime_member *member;
> +   struct rb_node **p, *rb;
>
> member = kmalloc(sizeof(*member), GFP_KERNEL);
> if (!member)
> @@ -83,18 +87,56 @@ static int drm_prime_add_buf_handle(struct 
> drm_prime_file_private *prime_fpriv,
> get_dma_buf(dma_buf);
> member->dma_buf = dma_buf;
> member->handle = handle;
> -   list_add(>entry, _fpriv->head);
> +
> +   rb = NULL;
> +   p = _fpriv->dmabufs.rb_node;
> +   while (*p) {
> +   struct drm_prime_member *pos;
> +
> +   rb = *p;
> +   pos = rb_entry(rb, struct drm_prime_member, dmabuf_rb);
> +   if (dma_buf > pos->dma_buf)
> +   p = >rb_right;
> +   else
> +   p = >rb_left;
> +   }
> +   rb_link_node(>dmabuf_rb, rb, p);
> +   rb_insert_color(>dmabuf_rb, _fpriv->dmabufs);
> +
> +   rb = NULL;
> +   p = _fpriv->handles.rb_node;
> +   while (*p) {
> +   struct drm_prime_member *pos;
> +
> +   rb = *p;
> +   pos = rb_entry(rb, struct drm_prime_member, handle_rb);
> +   if (handle > pos->handle)
> +   p = >rb_right;
> +   else
> +   p = >rb_left;
> +   }
> +   rb_link_node(>handle_rb, rb, p);
> +   rb_insert_color(>handle_rb, _fpriv->handles);
> +
> return 0;
>  }
>
>  static struct dma_buf *drm_prime_lookup_buf_by_handle(struct 
> drm_prime_file_private *prime_fpriv,
>   uint32_t handle)
>  {
> -   struct drm_prime_member *member;
> +   struct rb_node *rb;
> +
> +   rb = prime_fpriv->handles.rb_node;
> +   while (rb) {
> +   struct drm_prime_member *member;
>
> -   list_for_each_entry(member, _fpriv->head, entry) {
> +   member = rb_entry(rb, struct drm_prime_member, handle_rb);
> if (member->han

Re: [Intel-gfx] [PATCH] drm: Declare that create drm_mm nodes with size 0 is illegal

[David Herrmann]

On Wed, Aug 3, 2016 at 8:26 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> At a higher level, all objects are created with definite size i.e. 0 is
> illegal. In forthcoming patches, this assumption is dependent upon in
> the drm_mm range manager, i.e. trying to create a drm_mm node with size
> 0 will have undefined behaviour. Add a couple of WARNs upon creating the
> drm_mm node to prevent later bugs.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/drm_mm.c | 9 +
>  1 file changed, 9 insertions(+)

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index cb39f45d6a16..e8c15795386d 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -185,6 +185,9 @@ int drm_mm_reserve_node(struct drm_mm *mm, struct 
> drm_mm_node *node)
>
> BUG_ON(node == NULL);
>
> +   if (WARN_ON(node->size == 0))
> +   return -EINVAL;
> +
> end = node->start + node->size;
>
> /* Find the relevant hole to add our node to */
> @@ -239,6 +242,9 @@ int drm_mm_insert_node_generic(struct drm_mm *mm, struct 
> drm_mm_node *node,
>  {
> struct drm_mm_node *hole_node;
>
> +   if (WARN_ON(size == 0))
> +   return -EINVAL;
> +
> hole_node = drm_mm_search_free_generic(mm, size, alignment,
>color, sflags);
> if (!hole_node)
> @@ -340,6 +346,9 @@ int drm_mm_insert_node_in_range_generic(struct drm_mm 
> *mm, struct drm_mm_node *n
>  {
> struct drm_mm_node *hole_node;
>
> +   if (WARN_ON(size == 0))
> +   return -EINVAL;
> +
> hole_node = drm_mm_search_free_in_range_generic(mm,
> size, alignment, 
> color,
> start, end, sflags);
> --
> 2.8.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

[David Herrmann]

Hey

On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> In addition to the last-in/first-out stack for accessing drm_mm nodes,
> we occasionally and in the future often want to find a drm_mm_node by an
> address. To do so efficiently we need to track the nodes in an interval
> tree - lookups for a particular address will then be O(lg(N)), where N
> is the number of nodes in the range manager as opposed to O(N).
> Insertion however gains an extra O(lg(N)) step for all nodes
> irrespective of whether the interval tree is in use. For future i915
> patches, eliminating the linear walk is a significant improvement.
>
> v2: Use generic interval-tree template for u64 and faster insertion.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: David Herrmann <dh.herrm...@gmail.com>
> Cc: dri-de...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_mm.c | 133 
> +++
>  include/drm/drm_mm.h |  12 +
>  2 files changed, 122 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index cb39f45d6a16..5c188c56894b 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -46,6 +46,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /**
>   * DOC: Overview
> @@ -103,6 +104,72 @@ static struct drm_mm_node 
> *drm_mm_search_free_in_range_generic(const struct drm_
> u64 end,
> enum drm_mm_search_flags 
> flags);
>
> +#define START(node) ((node)->start)
> +#define LAST(node)  ((node)->start + (node)->size - 1)

So this goes nuts with "size == 0". We do not explicitly prevent that
from happening, I think, but might be prevented in the upper layers.
Might wanna add WARN_ONs?

Otherwise, looks good to me:

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> +
> +INTERVAL_TREE_DEFINE(struct drm_mm_node, rb,
> +u64, __subtree_last,
> +START, LAST, static inline, drm_mm_interval_tree)
> +
> +struct drm_mm_node *
> +drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last)
> +{
> +   return drm_mm_interval_tree_iter_first(>interval_tree,
> +  start, last);
> +}
> +EXPORT_SYMBOL(drm_mm_interval_first);
> +
> +struct drm_mm_node *
> +drm_mm_interval_next(struct drm_mm_node *node, u64 start, u64 last)
> +{
> +   return drm_mm_interval_tree_iter_next(node, start, last);
> +}
> +EXPORT_SYMBOL(drm_mm_interval_next);
> +
> +static void drm_mm_interval_tree_add_node(struct drm_mm_node *hole_node,
> + struct drm_mm_node *node)
> +{
> +   struct drm_mm *mm = hole_node->mm;
> +   struct rb_node **link, *rb;
> +   struct drm_mm_node *parent;
> +
> +   node->__subtree_last = LAST(node);
> +
> +   if (hole_node->allocated) {
> +   rb = _node->rb;
> +   while (rb) {
> +   parent = rb_entry(rb, struct drm_mm_node, rb);
> +   if (parent->__subtree_last >= node->__subtree_last)
> +   break;
> +
> +   parent->__subtree_last = node->__subtree_last;
> +   rb = rb_parent(rb);
> +   }
> +
> +   rb = _node->rb;
> +   link = _node->rb.rb_right;
> +   } else {
> +   rb = NULL;
> +   link = >interval_tree.rb_node;
> +   }
> +
> +   while (*link) {
> +   rb = *link;
> +   parent = rb_entry(rb, struct drm_mm_node, rb);
> +   if (parent->__subtree_last < node->__subtree_last)
> +   parent->__subtree_last = node->__subtree_last;
> +   if (node->start < parent->start)
> +   link = >rb.rb_left;
> +   else
> +   link = >rb.rb_right;
> +   }
> +
> +   rb_link_node(>rb, rb, link);
> +   rb_insert_augmented(>rb,
> +   >interval_tree,
> +   _mm_interval_tree_augment);
> +}
> +
>  static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
>  struct drm_mm_node *node,
>  u64 size, unsigned alignment,
> @@ -153,6 +220,8 @@ static void drm_mm_insert_helper(struct drm_mm_node 
> *hole_node,
> INIT_LIST_HEAD(>hole_stack);
> list_add(&g

Re: [Intel-gfx] [PATCH 3/3] drm: Skip initialising the drm_mm_node->hole_stack

[David Herrmann]

Hi Chris

On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> As we always add this to the drm_mm->hole_stack as our first operation,
> we do not need to initialise the list node.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: David Herrmann <dh.herrm...@gmail.com>
> Cc: dri-de...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_mm.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)

"hole_follows" tells whether it is linked or not. So yeah, indeed, redundant.

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index 5c188c56894b..3f56d4b0cdae 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -217,7 +217,6 @@ static void drm_mm_insert_helper(struct drm_mm_node 
> *hole_node,
> node->color = color;
> node->allocated = 1;
>
> -   INIT_LIST_HEAD(>hole_stack);
> list_add(>node_list, _node->node_list);
>
> drm_mm_interval_tree_add_node(hole_node, node);
> @@ -276,14 +275,13 @@ int drm_mm_reserve_node(struct drm_mm *mm, struct 
> drm_mm_node *node)
> node->mm = mm;
> node->allocated = 1;
>
> -   INIT_LIST_HEAD(>hole_stack);
> list_add(>node_list, >node_list);
>
> drm_mm_interval_tree_add_node(hole, node);
>
> if (node->start == hole_start) {
> hole->hole_follows = 0;
> -   list_del_init(>hole_stack);
> +   list_del(>hole_stack);
> }
>
> node->hole_follows = 0;
> @@ -379,7 +377,6 @@ static void drm_mm_insert_helper_range(struct drm_mm_node 
> *hole_node,
> node->color = color;
> node->allocated = 1;
>
> -   INIT_LIST_HEAD(>hole_stack);
> list_add(>node_list, _node->node_list);
>
> drm_mm_interval_tree_add_node(hole_node, node);
> @@ -833,7 +830,6 @@ void drm_mm_init(struct drm_mm * mm, u64 start, u64 size)
>
> /* Clever trick to avoid a special case in the free hole tracking. */
> INIT_LIST_HEAD(>head_node.node_list);
> -   INIT_LIST_HEAD(>head_node.hole_stack);
> mm->head_node.hole_follows = 1;
> mm->head_node.scanned_block = 0;
> mm->head_node.scanned_prev_free = 0;
> --
> 2.8.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm: Convert drm_vma_manager to embedded interval-tree in drm_mm

[David Herrmann]

Hi Chris

On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> Having added an interval-tree to struct drm_mm, we can replace the
> auxiliary rb-tree inside the drm_vma_manager with it.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: David Herrmann <dh.herrm...@gmail.com>
> Cc: dri-de...@lists.freedesktop.org
> ---

Should have done that right from start when writing drm_vma_manager..

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

>  drivers/gpu/drm/drm_vma_manager.c | 43 
> ---
>  include/drm/drm_vma_manager.h |  2 --
>  2 files changed, 9 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vma_manager.c 
> b/drivers/gpu/drm/drm_vma_manager.c
> index f306c8855978..0aef432679f9 100644
> --- a/drivers/gpu/drm/drm_vma_manager.c
> +++ b/drivers/gpu/drm/drm_vma_manager.c
> @@ -86,7 +86,6 @@ void drm_vma_offset_manager_init(struct 
> drm_vma_offset_manager *mgr,
>  unsigned long page_offset, unsigned long 
> size)
>  {
> rwlock_init(>vm_lock);
> -   mgr->vm_addr_space_rb = RB_ROOT;
> drm_mm_init(>vm_addr_space_mm, page_offset, size);
>  }
>  EXPORT_SYMBOL(drm_vma_offset_manager_init);
> @@ -145,16 +144,16 @@ struct drm_vma_offset_node 
> *drm_vma_offset_lookup_locked(struct drm_vma_offset_m
>  unsigned long start,
>  unsigned long pages)
>  {
> -   struct drm_vma_offset_node *node, *best;
> +   struct drm_mm_node *node, *best;
> struct rb_node *iter;
> unsigned long offset;
>
> -   iter = mgr->vm_addr_space_rb.rb_node;
> +   iter = mgr->vm_addr_space_mm.interval_tree.rb_node;
> best = NULL;
>
> while (likely(iter)) {
> -   node = rb_entry(iter, struct drm_vma_offset_node, vm_rb);
> -   offset = node->vm_node.start;
> +   node = rb_entry(iter, struct drm_mm_node, rb);
> +   offset = node->start;
> if (start >= offset) {
> iter = iter->rb_right;
> best = node;
> @@ -167,38 +166,17 @@ struct drm_vma_offset_node 
> *drm_vma_offset_lookup_locked(struct drm_vma_offset_m
>
> /* verify that the node spans the requested area */
> if (best) {
> -   offset = best->vm_node.start + best->vm_node.size;
> +   offset = best->start + best->size;
> if (offset < start + pages)
> best = NULL;
> }
>
> -   return best;
> -}
> -EXPORT_SYMBOL(drm_vma_offset_lookup_locked);
> -
> -/* internal helper to link @node into the rb-tree */
> -static void _drm_vma_offset_add_rb(struct drm_vma_offset_manager *mgr,
> -  struct drm_vma_offset_node *node)
> -{
> -   struct rb_node **iter = >vm_addr_space_rb.rb_node;
> -   struct rb_node *parent = NULL;
> -   struct drm_vma_offset_node *iter_node;
> -
> -   while (likely(*iter)) {
> -   parent = *iter;
> -   iter_node = rb_entry(*iter, struct drm_vma_offset_node, 
> vm_rb);
> +   if (!best)
> +   return NULL;
>
> -   if (node->vm_node.start < iter_node->vm_node.start)
> -   iter = &(*iter)->rb_left;
> -   else if (node->vm_node.start > iter_node->vm_node.start)
> -   iter = &(*iter)->rb_right;
> -   else
> -   BUG();
> -   }
> -
> -   rb_link_node(>vm_rb, parent, iter);
> -   rb_insert_color(>vm_rb, >vm_addr_space_rb);
> +   return container_of(best, struct drm_vma_offset_node, vm_node);
>  }
> +EXPORT_SYMBOL(drm_vma_offset_lookup_locked);
>
>  /**
>   * drm_vma_offset_add() - Add offset node to manager
> @@ -240,8 +218,6 @@ int drm_vma_offset_add(struct drm_vma_offset_manager *mgr,
> if (ret)
> goto out_unlock;
>
> -   _drm_vma_offset_add_rb(mgr, node);
> -
>  out_unlock:
> write_unlock(>vm_lock);
> return ret;
> @@ -265,7 +241,6 @@ void drm_vma_offset_remove(struct drm_vma_offset_manager 
> *mgr,
> write_lock(>vm_lock);
>
> if (drm_mm_node_allocated(>vm_node)) {
> -   rb_erase(>vm_rb, >vm_addr_space_rb);
> drm_mm_remove_node(>vm_node);
> memset(>vm_node, 0, sizeof(node->vm_node));
> }
> di

Re: [Intel-gfx] [PATCH] dma-buf: Update docs for SYNC ioctl

[David Herrmann]

Hi

On Mon, Mar 28, 2016 at 9:42 PM, Tiago Vignatti
 wrote:
> Do we have an agreement here after all? David? I need to know whether this
> fixup is okay to go cause I'll need to submit to Chrome OS then.

Sure it is fine. The code is already there, we cannot change it.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] dma-buf: Update docs for SYNC ioctl

[David Herrmann]

Hi

On Wed, Mar 23, 2016 at 12:56 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Wed, Mar 23, 2016 at 12:30:42PM +0100, David Herrmann wrote:
>> My question was rather about why we do this? Semantics for EINTR are
>> well defined, and with SA_RESTART (default on linux) user-space can
>> ignore it. However, looping on EAGAIN is very uncommon, and it is not
>> at all clear why it is needed?
>>
>> Returning an error to user-space makes sense if user-space has a
>> reason to react to it. I fail to see how EAGAIN on a cache-flush/sync
>> operation helps user-space at all? As someone without insight into the
>> driver implementation, it is hard to tell why.. Any hints?
>
> The reason we return EAGAIN is to workaround a deadlock we face when
> blocking on the GPU holding the struct_mutex (inside the client's
> process), but the GPU is dead. As our locking is very, very coarse we
> cannot restart the GPU without acquiring the struct_mutex being held by
> the client so we wake the client up and tell them the resource they are
> waiting on (the flush of the object from the GPU into the CPU domain) is
> temporarily unavailable. If they try to immediately wait upon the ioctl
> again, they are blocked waiting for the reset to occur before they may
> complete their flush. There are a few other possible deadlocks that are
> also avoided with EAGAIN (again, the issue is more or less the lack of
> fine grained locking).

...so you hijacked EAGAIN for all DRM ioctls just for a driver
workaround? EAGAIN is universally used to signal the caller about a
blocking resource. It is very much linked to O_NONBLOCK. Why not use
EBUSY, ECANCELED, ECOMM, EDEADLOCK, EIO, EL3RST, ...

Anyhow, I guess that ship has sailed. But just mentioning EAGAIN in a
kernel-doc is way to vague for user-space to figure out they should
loop on it.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] dma-buf: Update docs for SYNC ioctl

[David Herrmann]

Hey

On Mon, Mar 21, 2016 at 6:14 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Mon, Mar 21, 2016 at 01:26:58PM +0100, David Herrmann wrote:
>> Hi
>>
>> On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter <daniel.vet...@ffwll.ch> 
>> wrote:
>> > Just a bit of wording polish plus mentioning that it can fail and must
>> > be restarted.
>> >
>> > Requested by Sumit.
>> >
>> > v2: Fix them typos (Hans).
>> >
>> > Cc: Chris Wilson <ch...@chris-wilson.co.uk>
>> > Cc: Tiago Vignatti <tiago.vigna...@intel.com>
>> > Cc: Stéphane Marchesin <marc...@chromium.org>
>> > Cc: David Herrmann <dh.herrm...@gmail.com>
>> > Cc: Sumit Semwal <sumit.sem...@linaro.org>
>> > Cc: Daniel Vetter <daniel.vet...@intel.com>
>> > CC: linux-me...@vger.kernel.org
>> > Cc: dri-de...@lists.freedesktop.org
>> > Cc: linaro-mm-...@lists.linaro.org
>> > Cc: intel-gfx@lists.freedesktop.org
>> > Cc: de...@driverdev.osuosl.org
>> > Cc: Hans Verkuil <hverk...@xs4all.nl>
>> > Acked-by: Sumit Semwal <sumit.sem...@linaro.org>
>> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
>> > ---
>> >  Documentation/dma-buf-sharing.txt | 11 ++-
>> >  drivers/dma-buf/dma-buf.c |  2 +-
>> >  2 files changed, 7 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/Documentation/dma-buf-sharing.txt 
>> > b/Documentation/dma-buf-sharing.txt
>> > index 32ac32e773e1..ca44c5820585 100644
>> > --- a/Documentation/dma-buf-sharing.txt
>> > +++ b/Documentation/dma-buf-sharing.txt
>> > @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 
>> > 2 main use-cases:
>> >
>> > No special interfaces, userspace simply calls mmap on the dma-buf fd, 
>> > making
>> > sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is 
>> > *always*
>> > -   used when the access happens. This is discussed next paragraphs.
>> > +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail 
>> > with
>> > +   -EAGAIN or -EINTR, in which case it must be restarted.
>>
>> What is "restart on EAGAIN" supposed to mean? Or more generally, what
>> does EAGAIN tell the caller?
>
> Do what drmIoctl does essentially.
>
> while (ret == -1 && (errno == EAGAIN || errno == EINTR)
> ret = ioctl();
>
> Typed from memery, too lazy to look it up in the source ;-) I'm trying to
> sell the idea of a real dma-buf manpage to Sumit, we should clarify this
> in detail there.

My question was rather about why we do this? Semantics for EINTR are
well defined, and with SA_RESTART (default on linux) user-space can
ignore it. However, looping on EAGAIN is very uncommon, and it is not
at all clear why it is needed?

Returning an error to user-space makes sense if user-space has a
reason to react to it. I fail to see how EAGAIN on a cache-flush/sync
operation helps user-space at all? As someone without insight into the
driver implementation, it is hard to tell why.. Any hints?

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] dma-buf: Update docs for SYNC ioctl

[David Herrmann]

Hi

On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> v2: Fix them typos (Hans).
>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Tiago Vignatti <tiago.vigna...@intel.com>
> Cc: Stéphane Marchesin <marc...@chromium.org>
> Cc: David Herrmann <dh.herrm...@gmail.com>
> Cc: Sumit Semwal <sumit.sem...@linaro.org>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> CC: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: de...@driverdev.osuosl.org
> Cc: Hans Verkuil <hverk...@xs4all.nl>
> Acked-by: Sumit Semwal <sumit.sem...@linaro.org>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
>  Documentation/dma-buf-sharing.txt | 11 ++-
>  drivers/dma-buf/dma-buf.c |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..ca44c5820585 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>
> No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> making
> sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
> -   used when the access happens. This is discussed next paragraphs.
> +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> +   -EAGAIN or -EINTR, in which case it must be restarted.

What is "restart on EAGAIN" supposed to mean? Or more generally, what
does EAGAIN tell the caller?

Thanks
David

> Some systems might need some sort of cache coherency management e.g. when
> CPU and GPU domains are being accessed through dma-buf at the same time. 
> To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 
> 2 main use-cases:
> want (with the new data being consumed by the GPU or say scanout 
> device)
>   - munmap once you don't need the buffer any more
>
> -Therefore, for correctness and optimal performance, systems with the 
> memory
> -cache shared by the GPU and CPU i.e. the "coherent" and also the
> -"incoherent" are always required to use SYNC_START and SYNC_END before 
> and
> -after, respectively, when accessing the mapped address.
> +For correctness and optimal performance, it is always required to use
> +SYNC_START and SYNC_END before and after, respectively, when accessing 
> the
> +mapped address. Userspace cannot rely on coherent access, even when there
> +are systems where it just works without calling these ioctls.
>
>  2. Supporting existing mmap interfaces in importers
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>   * @dmabuf:[in]buffer to complete cpu access for.
>   * @direction: [in]length of range for cpu access.
>   *
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
>   */
>  int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>enum dma_data_direction direction)
> --
> 2.8.0.rc3
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/9] drm/core: Add drm_for_each_encoder_mask.

[David Herrmann]

Hi

On Tue, Nov 24, 2015 at 7:00 PM, Jani Nikula
 wrote:
> On Tue, 24 Nov 2015, Maarten Lankhorst  
> wrote:
>> +#define drm_for_each_encoder_mask(encoder, dev, encoder_mask) \
>> + list_for_each_entry((encoder), &(dev)->mode_config.encoder_list, head) 
>> \
>> + if ((encoder_mask) & (1 << drm_encoder_index(encoder)))
>
> How about
>
> if (!((encoder_mask) & (1 << drm_encoder_index(encoder; else
>
> to avoid dangling else problems?

YES! Please use inverted conditions in macros. Otherwise, looks good to me.

But I think an empty block "{ }" is preferable over the empty
statement. llvm tends to warn about empty statements.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/vma_manage: Drop has_offset

[David Herrmann]

Hi

On Thu, Oct 22, 2015 at 7:11 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> It's racy, creating mmap offsets is a slowpath, so better to remove it
> to avoid drivers doing broken things.
>
> The only user is i915, and it's ok there because everything (well
> almost) is protected by dev->struct_mutex in i915-gem.
>
> While at it add a note in the create_mmap_offset kerneldoc that
> drivers must release it again. And then I also noticed that
> drm_gem_object_release entirely lacks kerneldoc.
>
> Cc: David Herrmann <dh.herrm...@gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>

I'd even argue that no driver should ever call into
drm_vma_offset_add() nor drm_vma_offset_remove(). For TTM this is
already the case, for plain old gem drivers still call
drm_vma_offset_add() (which is fine to me, but could be turned into a
gem helper).

Anyway, if TTM wasn't a module, we should drop the export of
drm_vma_offset_remove(), but that'll never happen, I guess.

Long story short: If anyone calls drm_vma_offset_remove() somewhere
but in the destructor, it's probably racy, so I fully support this
patch. The vma helpers are also made fail-safe on purpose, it has
never been a fast-path.

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> ---
>  drivers/gpu/drm/drm_gem.c   | 17 +
>  drivers/gpu/drm/i915/i915_gem.c |  3 ---
>  include/drm/drm_vma_manager.h   | 15 +--
>  3 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 64353d40db53..38680380c6b3 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -387,6 +387,10 @@ EXPORT_SYMBOL(drm_gem_handle_create);
>   * @obj: obj in question
>   *
>   * This routine frees fake offsets allocated by drm_gem_create_mmap_offset().
> + *
> + * Note that drm_gem_object_release() already calls this function, so drivers
> + * don't have to take care of releasing the mmap offset themselves when 
> freeing
> + * the GEM object.
>   */
>  void
>  drm_gem_free_mmap_offset(struct drm_gem_object *obj)
> @@ -410,6 +414,9 @@ EXPORT_SYMBOL(drm_gem_free_mmap_offset);
>   * This routine allocates and attaches a fake offset for @obj, in cases where
>   * the virtual size differs from the physical size (ie. obj->size).  
> Otherwise
>   * just use drm_gem_create_mmap_offset().
> + *
> + * This function is idempotent and handles an already allocated mmap offset
> + * transparently. Drivers do not need to check for this case.
>   */
>  int
>  drm_gem_create_mmap_offset_size(struct drm_gem_object *obj, size_t size)
> @@ -431,6 +438,9 @@ EXPORT_SYMBOL(drm_gem_create_mmap_offset_size);
>   * structures.
>   *
>   * This routine allocates and attaches a fake offset for @obj.
> + *
> + * Drivers can call drm_gem_free_mmap_offset() before freeing @obj to release
> + * the fake offset again.
>   */
>  int drm_gem_create_mmap_offset(struct drm_gem_object *obj)
>  {
> @@ -739,6 +749,13 @@ drm_gem_release(struct drm_device *dev, struct drm_file 
> *file_private)
> idr_destroy(_private->object_idr);
>  }
>
> +/**
> + * drm_gem_object_release - release GEM buffer object resources
> + * @obj: GEM buffer object
> + *
> + * This releases any structures and resources used by @obj and is the invers 
> of
> + * drm_gem_object_init().
> + */
>  void
>  drm_gem_object_release(struct drm_gem_object *obj)
>  {
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d0fa5481543c..01fef54ecb2d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1972,9 +1972,6 @@ static int i915_gem_object_create_mmap_offset(struct 
> drm_i915_gem_object *obj)
> struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
> int ret;
>
> -   if (drm_vma_node_has_offset(>base.vma_node))
> -   return 0;
> -
> dev_priv->mm.shrinker_no_lock_stealing = true;
>
> ret = drm_gem_create_mmap_offset(>base);
> diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
> index 2f63dd5e05eb..06ea8e077ec2 100644
> --- a/include/drm/drm_vma_manager.h
> +++ b/include/drm/drm_vma_manager.h
> @@ -176,19 +176,6 @@ static inline unsigned long drm_vma_node_size(struct 
> drm_vma_offset_node *node)
>  }
>
>  /**
> - * drm_vma_node_has_offset() - Check whether node is added to offset manager
> - * @node: Node to be checked
> - *
> - * RETURNS:
> - * true iff the node was previously allocated an offset and added to
> - * an vma offset manager.
> - */
> -static inline bool drm_vma_node_ha

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

[David Herrmann]

Hi

On Wed, Oct 21, 2015 at 5:11 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
>> In addition to the last-in/first-out stack for accessing drm_mm nodes,
>> we occasionally and in the future often want to find a drm_mm_node by an
>> address. To do so efficiently we need to track the nodes in an interval
>> tree - lookups for a particular address will then be O(lg(N)), where N
>> is the number of nodes in the range manager as opposed to O(N).
>> Insertion however gains an extra O(lg(N)) step for all nodes
>> irrespective of whether the interval tree is in use. For future i915
>> patches, eliminating the linear walk is a significant improvement.
>>
>> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
>> Cc: dri-de...@lists.freedesktop.org
>
> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
>
> I guess for simpler merge ordering we can just pull this into drm-intel
> and patch up the vma manager (just need to drop a lot of code and adjust
> the search to use the drm_mm internal_tree nodes) later on.

Agreed.

Acked-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

[David Herrmann]

Hi

On Tue, Oct 6, 2015 at 1:19 PM, Chris Wilson  wrote:
> On Tue, Oct 06, 2015 at 01:11:56PM +0200, Daniel Vetter wrote:
>> On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
>> > In addition to the last-in/first-out stack for accessing drm_mm nodes,
>> > we occasionally and in the future often want to find a drm_mm_node by an
>> > address. To do so efficiently we need to track the nodes in an interval
>> > tree - lookups for a particular address will then be O(lg(N)), where N
>> > is the number of nodes in the range manager as opposed to O(N).
>> > Insertion however gains an extra O(lg(N)) step for all nodes
>> > irrespective of whether the interval tree is in use. For future i915
>> > patches, eliminating the linear walk is a significant improvement.
>> >
>> > Signed-off-by: Chris Wilson 
>> > Cc: dri-de...@lists.freedesktop.org
>>
>> For the vma manager David Herrman put the interval tree outside of drm_mm.
>> Whichever way we pick, but I think we should be consistent about this.
>
> Given that the basis of this patch is that functionality exposed by
> drm_mm (i.e. drm_mm_reserve_node) is too slow for our use case (i.e.
> there is a measurable perf degradation if we switch over from the mru
> stack to using fixed addresses) it makes sense to improve that
> functionality. The question is then why the drm_vma_manager didn't use
> and improve the existing functionality...

I didn't want to slow down drm_mm operations, so I kept it separate. I
don't mind if it is merged into drm_mm. It'd be trivial to make the
vma-manager use it (only on the top-level, though).

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/doc: Update docs about device instance setup

[David Herrmann]

Hi

On Mon, Aug 10, 2015 at 4:30 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Mon, Aug 10, 2015 at 02:34:18PM +0200, Thierry Reding wrote:
>> On Mon, Aug 10, 2015 at 02:07:49PM +0200, Daniel Vetter wrote:
>> > On Mon, Aug 10, 2015 at 01:59:07PM +0200, Thierry Reding wrote:
>> > > On Mon, Aug 10, 2015 at 11:55:38AM +0200, Daniel Vetter wrote:
>> > > > ->load is depracated, bus functionst are deprecated and everyone
>> > > > should use drm_dev_alloc
>> > >
>> > > Why would you want to deprecated ->load()? Even if you use
>> > > drm_dev_alloc() and drm_dev_register(), there's still use for ->load()
>> > > because it gives you the subsystem-level initialization entry point.
>> >
>> > ->load is called after the drm /dev node is registered and hence you can't
>> > really do any driver setup in there without risking races. We paper over
>> > that using drm_global_mutex, but that doesn't work for any other
>> > driver/userspace interface like sysfs/debugfs because of deadlocks.
>> >
>> > And we can't just reorder ->load to happen before the /dev nodes are
>> > registered because a lot of drivers would fall over if we do that.
>> >
>> > This is typical midlayer fail where the core calls into the driver instead
>> > of the other way round.
>>
>> Okay, but then if we're going to deprecate ->load(), I think we should
>> also come up with an upgrade plan. As it is, this just says that users
>> shouldn't do ->load(), but it doesn't tell them what to do instead.
>>
>> Would the proper procedure be to fix drivers so that ->load() can be
>> called between drm_dev_alloc() and drm_dev_register()? I suppose we
>> could add some sort of (temporary) flag for drivers to signal this and
>> then have drm_dev_register() call ->load() at the right time. If drivers
>> don't support it, we can keep what we have.
>>
>> That, of course, doesn't get rid of the midlayer, so perhaps a better
>> way forward would be to tell driver writers that they should be doing
>> subsystem-level setup between drm_dev_alloc() and drm_dev_register().
>
> That's exactly what this patch tries to accomplish by updating the
> kerneldoc and docbook. New sequence should be
>
> device_probe_callback_or_whatever()
> {
> drm_dev_alloc();
>
> ... driver init code ...
>
> drm_dev_register();
>
> return 0;
> }

_Yes_!

Acked-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/11] drm/drm_ioctl.c: kerneldoc

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> As usual pull it into the drm docbook template, too. And again as
> usual I've decided to only document stuff exported to drivers, so all
> the old leftover markup from the shared drm repo days lost the magic
> ** signature.
>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> ---
>  Documentation/DocBook/drm.tmpl |  1 +
>  drivers/gpu/drm/drm_ioctl.c| 76 
> ++
>  2 files changed, 55 insertions(+), 22 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 7d10be2a2ba0..cfb43203a6a7 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3752,6 +3752,7 @@ int num_ioctls;
>   
> 
>
> +!Edrivers/gpu/drm/drm_ioctl.c
>  
>
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index f0b4f581f6ce..75df8ea87cd7 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -40,7 +40,7 @@
>  static int drm_version(struct drm_device *dev, void *data,
>struct drm_file *file_priv);
>
> -/**
> +/*
>   * Get the bus id.
>   *
>   * \param inode device inode.
> @@ -75,7 +75,7 @@ drm_unset_busid(struct drm_device *dev,
> master->unique_len = 0;
>  }
>
> -/**
> +/*
>   * Set the bus id.
>   *
>   * \param inode device inode.
> @@ -149,7 +149,7 @@ static int drm_set_busid(struct drm_device *dev, struct 
> drm_file *file_priv)
> return 0;
>  }
>
> -/**
> +/*
>   * Get a mapping information.
>   *
>   * \param inode device inode.
> @@ -201,7 +201,7 @@ static int drm_getmap(struct drm_device *dev, void *data,
> return 0;
>  }
>
> -/**
> +/*
>   * Get client information.
>   *
>   * \param inode device inode.
> @@ -244,7 +244,7 @@ static int drm_getclient(struct drm_device *dev, void 
> *data,
> }
>  }
>
> -/**
> +/*
>   * Get statistics information.
>   *
>   * \param inode device inode.
> @@ -265,7 +265,7 @@ static int drm_getstats(struct drm_device *dev, void 
> *data,
> return 0;
>  }
>
> -/**
> +/*
>   * Get device/driver capabilities
>   */
>  static int drm_getcap(struct drm_device *dev, void *data, struct drm_file 
> *file_priv)
> @@ -318,7 +318,7 @@ static int drm_getcap(struct drm_device *dev, void *data, 
> struct drm_file *file_
> return 0;
>  }
>
> -/**
> +/*
>   * Set device/driver capabilities
>   */
>  static int
> @@ -352,7 +352,7 @@ drm_setclientcap(struct drm_device *dev, void *data, 
> struct drm_file *file_priv)
> return 0;
>  }
>
> -/**
> +/*
>   * Setversion ioctl.
>   *
>   * \param inode device inode.
> @@ -406,7 +406,18 @@ done:
> return retcode;
>  }
>
> -/** No-op ioctl. */
> +/**
> + * drm_noop - DRM no-op ioctl implemntation
> + * @dev: DRM device for the ioctl
> + * @data: data pointer for the ioctl
> + * @file_priv: DRM file for the ioctl call
> + *
> + * This no-op implementation for drm ioctls is useful for deprecated
> + * functionality where we can't return a failure code because existing 
> userspace
> + * checks the result of the ioctl, but doesn't care about the action.
> + *
> + * Always returns successfully with 0.
> + */
>  int drm_noop(struct drm_device *dev, void *data,
>  struct drm_file *file_priv)
>  {
> @@ -415,6 +426,21 @@ int drm_noop(struct drm_device *dev, void *data,
>  }
>  EXPORT_SYMBOL(drm_noop);
>
> +/**
> + * drm_invalid_op - DRM invalid ioctl implemntation
> + * @dev: DRM device for the ioctl
> + * @data: data pointer for the ioctl
> + * @file_priv: DRM file for the ioctl call
> + *
> + * This no-op implementation for drm ioctls is useful for deprecated
> + * functionality where we really don't want to allow userspace to call the 
> ioctl
> + * any more. This is the case for old ums interfaces for drivers that
> + * transitioned to kms gradually and so kept the old legacy tables around. 
> This
> + * only applies to radeon and i915 kms drivers, other drivers shouldn't need 
> to
> + * use this function.
> + *
> + * Always fails with a return value of -EINVAL.
> + */
>  int drm_invalid_op(struct drm_device *dev, void *data,
>struct drm_file *file_priv)
>  {
> @@ -422,7 +448,7 @@ int drm_invalid_op(struct drm_device *dev, void *data,
>  }
>  EXPORT_SYMBOL(drm_invalid_op);
>
> -/**
> +/*
>   * Copy and IO

Re: [Intel-gfx] [PATCH 10/11] drm/: Drop DRM_UNLOCKED from modeset drivers

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> Just one special case (since i915 lost its ums code, yay):
> - radeon: Has slots for the old ums ioctls which don't have
>   DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it
>   everywhere.
>
> Every other kms driver just has DRM_UNLOCKED for all their ioctls, as
> they should.
>
> v2: admgpu happened, include that one too. And i915 lost its UMS
> support which means we can change all the i915 ioctls too.
>
> v3: Rebased on top of new vmwgfx DX interface extensions.
>
> v4: Rebase on top of render-node support in exynos.
>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>

With the core-patch fixed:

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Maybe, as a followup, you might want to turn all core-ioctls to
include a DRM_GLOBAL_LOCK flag and then drop DRM_UNLOCKED entirely.
This is more explicit and *way* easier to understand.

Thanks
David

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 24 +--
>  drivers/gpu/drm/armada/armada_drv.c |  9 ++---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 -
>  drivers/gpu/drm/i915/i915_dma.c | 72 
> -
>  drivers/gpu/drm/msm/msm_drv.c   | 14 +++
>  drivers/gpu/drm/nouveau/nouveau_drm.c   | 24 +--
>  drivers/gpu/drm/omapdrm/omap_drv.c  | 12 +++---
>  drivers/gpu/drm/qxl/qxl_ioctl.c | 14 +++
>  drivers/gpu/drm/radeon/radeon_kms.c | 30 +++---
>  drivers/gpu/drm/tegra/drm.c | 28 ++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 54 -
>  11 files changed, 149 insertions(+), 152 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 22367939ebf1..3648fdca6359 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -685,18 +685,18 @@ int amdgpu_get_vblank_timestamp_kms(struct drm_device 
> *dev, int crtc,
>  }
>
>  const struct drm_ioctl_desc amdgpu_ioctls_kms[] = {
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_CREATE, amdgpu_gem_create_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_CTX, amdgpu_ctx_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_BO_LIST, amdgpu_bo_list_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_CREATE, amdgpu_gem_create_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_CTX, amdgpu_ctx_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_BO_LIST, amdgpu_bo_list_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> /* KMS */
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_MMAP, amdgpu_gem_mmap_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_WAIT_IDLE, amdgpu_gem_wait_idle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_CS, amdgpu_cs_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_INFO, amdgpu_info_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_WAIT_CS, amdgpu_cs_wait_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_METADATA, amdgpu_gem_metadata_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_MMAP, amdgpu_gem_mmap_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_WAIT_IDLE, amdgpu_gem_wait_idle_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_CS, amdgpu_cs_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_INFO, amdgpu_info_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_WAIT_CS, amdgpu_cs_wait_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_METADATA, amdgpu_gem_metadata_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
>  };
>  int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_k

Re: [Intel-gfx] [PATCH 09/11] drm/vmwgfx: Stop checking for DRM_UNLOCKED

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> drm core enforces now for DRIVER_MODESET that all ioctls are unlocked.
> And all the old nasty ones from drm core aren't allowed for modern
> drivers any more. Hence this is no longer needed.
>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index e13b20bd9908..2320ba8c5eb1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -1068,14 +1068,6 @@ static struct vmw_master *vmw_master_check(struct 
> drm_device *dev,
> mutex_unlock(>master_mutex);
>
> /*
> -* Taking the drm_global_mutex after the TTM lock might deadlock
> -*/
> -   if (!(flags & DRM_UNLOCKED)) {
> -   DRM_ERROR("Refusing locked ioctl access.\n");
> -   return ERR_PTR(-EDEADLK);
> -   }

Yeah, just drop that right away, regardless of the core changes. We
have lockdep or WARN_ON() for such checks.

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> -
> -   /*
>  * Take the TTM lock. Possibly sleep waiting for the authenticating
>  * master to become master again, or for a SIGTERM if the
>  * authenticating master exits.
> --
> 2.5.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Remove __OS_HAS_AGP

[David Herrmann]

Hi

On Wed, Sep 9, 2015 at 4:45 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> We already express the drm/agp depencies correctly in Kconfig, so we
> can rip this remnant from the shared drm core days.
>
> Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
> if ttm would provide dummy functions. I'm not going to volunteer for
> that though.
>
> v2: Use IS_ENABLED(CONFIG_AGP) as suggested by Ville
>
> v3: Polish from Ville's review.
>
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Reviewed-by: Christian König <christian.koe...@amd.com> (v2)
> Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>

I recommend pushing it on your fdo branch to let the kbuild-bots run
it for some tests. But otherwise, looks good to me:

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> ---
>  drivers/gpu/drm/Makefile |  3 ++-
>  drivers/gpu/drm/drm_agpsupport.c |  4 
>  drivers/gpu/drm/drm_bufs.c   |  6 +++---
>  drivers/gpu/drm/drm_ioc32.c  |  6 +++---
>  drivers/gpu/drm/drm_ioctl.c  |  2 +-
>  drivers/gpu/drm/drm_memory.c |  6 +++---
>  drivers/gpu/drm/drm_vm.c |  8 
>  drivers/gpu/drm/mga/mga_dma.c|  4 ++--
>  drivers/gpu/drm/nouveau/nouveau_bo.c |  8 
>  drivers/gpu/drm/r128/r128_cce.c  | 12 ++--
>  drivers/gpu/drm/radeon/r600_cp.c | 14 +++---
>  drivers/gpu/drm/radeon/radeon_agp.c  |  8 
>  drivers/gpu/drm/radeon/radeon_cp.c   | 16 
>  drivers/gpu/drm/radeon/radeon_ttm.c  | 10 +-
>  include/drm/drm_agpsupport.h |  9 +++--
>  15 files changed, 55 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 45e7719846b1..f458d6e33655 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -6,7 +6,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
> drm_context.o drm_dma.o \
> drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
> drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
> -   drm_agpsupport.o drm_scatter.o drm_pci.o \
> +   drm_scatter.o drm_pci.o \
> drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
> drm_crtc.o drm_modes.o drm_edid.o \
> drm_info.o drm_debugfs.o drm_encoder_slave.o \
> @@ -19,6 +19,7 @@ drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>  drm-$(CONFIG_PCI) += ati_pcigart.o
>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>  drm-$(CONFIG_OF) += drm_of.o
> +drm-$(CONFIG_AGP) += drm_agpsupport.o
>
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
> b/drivers/gpu/drm/drm_agpsupport.c
> index 4b2b4aa5033b..a10ea6aec629 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -36,8 +36,6 @@
>  #include 
>  #include "drm_legacy.h"
>
> -#if __OS_HAS_AGP
> -
>  #include 
>
>  /**
> @@ -502,5 +500,3 @@ drm_agp_bind_pages(struct drm_device *dev,
> return mem;
>  }
>  EXPORT_SYMBOL(drm_agp_bind_pages);
> -
> -#endif /* __OS_HAS_AGP */
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index 569064a00693..f1a204d253cc 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -582,7 +582,7 @@ static void drm_cleanup_buf_error(struct drm_device * dev,
> }
>  }
>
> -#if __OS_HAS_AGP
> +#if IS_ENABLED(CONFIG_AGP)
>  /**
>   * Add AGP buffers for DMA transfers.
>   *
> @@ -756,7 +756,7 @@ int drm_legacy_addbufs_agp(struct drm_device *dev,
> return 0;
>  }
>  EXPORT_SYMBOL(drm_legacy_addbufs_agp);
> -#endif /* __OS_HAS_AGP */
> +#endif /* CONFIG_AGP */
>
>  int drm_legacy_addbufs_pci(struct drm_device *dev,
>struct drm_buf_desc *request)
> @@ -1145,7 +1145,7 @@ int drm_legacy_addbufs(struct drm_device *dev, void 
> *data,
> if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
> return -EINVAL;
>
> -#if __OS_HAS_AGP
> +#if IS_ENABLED(CONFIG_AGP)
> if (request->flags & _DRM_AGP_BUFFER)
> ret = drm_legacy_addbufs_agp(dev, request);
> else
> diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
> index ddfa6014c2c2..57676f8d7ecf 100644
> --- a/drivers/gpu/drm/drm_ioc32.c
> +++ b/drivers/gpu/drm/drm_ioc32.c
> @@ -72

Re: [Intel-gfx] [PATCH 11/11] drm: Remove dummy agp ioctl wrappers

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> They're only used in the drm ioctl table, and there they're excluded
> when AGP support is disabled. So this is just dead code ripe for
> removal.
>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> ---
>  include/drm/drm_agpsupport.h | 48 
> 
>  1 file changed, 48 deletions(-)
>
> diff --git a/include/drm/drm_agpsupport.h b/include/drm/drm_agpsupport.h
> index 3d0833c63af2..addf0ea3e158 100644
> --- a/include/drm/drm_agpsupport.h
> +++ b/include/drm/drm_agpsupport.h
> @@ -105,95 +105,47 @@ static inline int drm_agp_acquire(struct drm_device 
> *dev)
> return -ENODEV;
>  }
>
> -static inline int drm_agp_acquire_ioctl(struct drm_device *dev, void *data,
> -   struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_release(struct drm_device *dev)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_release_ioctl(struct drm_device *dev, void *data,
> -   struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_enable(struct drm_device *dev,
>  struct drm_agp_mode mode)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_enable_ioctl(struct drm_device *dev, void *data,
> -  struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_info(struct drm_device *dev,
>struct drm_agp_info *info)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_info_ioctl(struct drm_device *dev, void *data,
> -struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_alloc(struct drm_device *dev,
> struct drm_agp_buffer *request)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_alloc_ioctl(struct drm_device *dev, void *data,
> - struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_free(struct drm_device *dev,
>struct drm_agp_buffer *request)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_free_ioctl(struct drm_device *dev, void *data,
> -struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_unbind(struct drm_device *dev,
>  struct drm_agp_binding *request)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_unbind_ioctl(struct drm_device *dev, void *data,
> -  struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_bind(struct drm_device *dev,
>struct drm_agp_binding *request)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_bind_ioctl(struct drm_device *dev, void *data,
> -struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  #endif /* CONFIG_AGP */
>
>  #endif /* _DRM_AGPSUPPORT_H_ */
> --
> 2.5.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/11] drm: Enforce unlocked ioctl operation for kms driver ioctls

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter  wrote:
> With the prep patches for i915 all kms drivers either have
> DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns
> with an invariant return value when in modeset mode. But that's only
> the case for i915 and radeon. The drm core ioctls are unfortunately
> too much a mess still to dare this.
>
> Follow-up patches will remove DRM_UNLOCKED from all kms drivers to
> prove that this is indeed the case.
>
> Also update the documentation.
>
> Signed-off-by: Daniel Vetter 

drm_setclientcap() should probably lock _something_. It's not very
crucial, but I think we should guarantee consistency when setting
multiple values. struct_mutex of the corresponding DRM device sounds
sufficient, though not very promising. But drm_file doesn't have any
suitable lock..

drm_setversion(): This definitely needs _some_ lock. DRM_MASTER is not
reliable (we never merged the master-reliability patches).

...skipping review of the other ioctls...
...re-reading patch description...

So this patch is just meant to drop DRM_UNLOCKED from driver-ioctls,
right? See below.

> ---
>  Documentation/DocBook/drm.tmpl | 4 +++-
>  drivers/gpu/drm/drm_ioctl.c| 6 +-
>  2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index cfb43203a6a7..55dc106686df 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3747,7 +3747,9 @@ int num_ioctls;
> 
>  
>   DRM_UNLOCKED - The ioctl handler will be called without locking
> - the DRM global mutex
> + the DRM global mutex. This is the enforced default for kms 
> drivers
> + (i.e. using the DRIVER_MODESET flag) and hence shouldn't be used
> + any more for new drivers.
> 
>   
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 75df8ea87cd7..a5a4aa89b1b4 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -728,6 +728,7 @@ long drm_ioctl(struct file *filp,
> }
>
> retcode = drm_ioctl_permit(ioctl->flags, file_priv);
> +

Weird new-line. I actually prefer the previous style, anyway.

> if (unlikely(retcode))
> goto err_i1;
>
> @@ -755,7 +756,10 @@ long drm_ioctl(struct file *filp,
> memset(kdata, 0, usize);
> }
>
> -   if (ioctl->flags & DRM_UNLOCKED)
> +   /* Enforce sane locking for kms driver ioctls. Core ioctls are
> +* too messy still. */
> +   if (drm_core_check_feature(dev, DRIVER_MODESET) ||
> +   (ioctl->flags & DRM_UNLOCKED))
> retcode = func(dev, kdata, file_priv);

This looks.. weird. Now we *never* lock *anything* for MODESET
drivers? This contradicts your commit-message, which rather tells me
you want _driver_ ioctls of modeset drivers to never rely on
drm_global_mutex. Several ways to make that work (and I'd review it
gladly), but this looks.. weird.

Care to elaborate?

Thanks
David

> else {
> mutex_lock(_global_mutex);
> --
> 2.5.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 12:56 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> From: Matt Roper <matthew.d.ro...@intel.com>
>
> Starting with commit
>
> commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
> Author: Rob Clark <robdcl...@gmail.com>
> Date:   Tue Aug 25 15:36:00 2015 -0400
>
> drm/i915: enable atomic fb-helper
>
> I've been seeing some panics on i915 when the DRM master shuts down that 
> appear
> to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
> dropping our initial FB's reference count to 0 and freeing it, which causes a
> crash when we try to restore it later).  Digging deeper, the state FB
> refcounting is working as expected, but we seem to be missing proper
> refcounting on the legacy plane->fb pointers in the new atomic fbdev code.
>
> Tracking plane->old_fb and then doing a ref/unref at the end of the
> fbdev restore like we do in the legacy ioctl's ensures we don't miscount
> references on plane->fb and avoids the panics.
>
> v2 from Daniel:
>
> Really do what the atomic ioctl does:
> - Also update plane->fb and plane->crtc.
> - Clear out plane->old_fb on failures too.
>
> v3: git add everything. Oops.
>
> Cc: Rob Clark <robdcl...@gmail.com>
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Matt Roper <matthew.d.ro...@intel.com> (v1)
> Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 64fc5ca8fda2..8af522afdfc1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -352,6 +352,8 @@ retry:
> drm_for_each_plane(plane, dev) {
> struct drm_plane_state *plane_state;
>
> +   plane->old_fb = plane->fb;
> +
> plane_state = drm_atomic_get_plane_state(state, plane);
> if (IS_ERR(plane_state)) {
> ret = PTR_ERR(plane_state);
> @@ -382,6 +384,21 @@ retry:
> }
>
> ret = drm_atomic_commit(state);
> +
> +   drm_for_each_plane(plane, dev) {
> +   if (ret == 0) {
> +   struct drm_framebuffer *new_fb = plane->state->fb;
> +   if (new_fb)
> +   drm_framebuffer_reference(new_fb);
> +   plane->fb = new_fb;
> +   plane->crtc = plane->state->crtc;
> +
> +   if (plane->old_fb)
> +   drm_framebuffer_unreference(plane->old_fb);
> +   }
> +   plane->old_fb = NULL;

You still leak "old_fb" if something jumps to "fail:" before
drm_atomic_commit() is called. But I don't mind:

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> +   }
> +
> if (ret != 0)
> goto fail;
>
> --
> 2.5.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 12:33 PM, Maarten Lankhorst
 wrote:
> Hey,
>
> Op 22-09-15 om 11:55 schreef Daniel Vetter:
>> From: Matt Roper 
>>
>> Starting with commit
>>
>> commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
>> Author: Rob Clark 
>> Date:   Tue Aug 25 15:36:00 2015 -0400
>>
>> drm/i915: enable atomic fb-helper
>>
>> I've been seeing some panics on i915 when the DRM master shuts down that 
>> appear
>> to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
>> dropping our initial FB's reference count to 0 and freeing it, which causes a
>> crash when we try to restore it later).  Digging deeper, the state FB
>> refcounting is working as expected, but we seem to be missing proper
>> refcounting on the legacy plane->fb pointers in the new atomic fbdev code.
>>
>> Tracking plane->old_fb and then doing a ref/unref at the end of the
>> fbdev restore like we do in the legacy ioctl's ensures we don't miscount
>> references on plane->fb and avoids the panics.
>>
>> v2 from Daniel:
>>
>> Really do what the atomic ioctl does:
>> - Also update plane->fb and plane->crtc.
>> - Clear out plane->old_fb on failures too.
>>
>> Cc: Rob Clark 
>> Cc: intel-gfx@lists.freedesktop.org
>> Signed-off-by: Matt Roper  (v1)
>> Signed-off-by: Daniel Vetter 
>> ---
>>  drivers/gpu/drm/drm_fb_helper.c | 16 
>>  1 file changed, 16 insertions(+)
>
> Looks sane, but I see a lot of this boilerplate for the plane->fb updates, 
> and we often get it wrong. Like for example in drm_mode_atomic_ioctl.
>
> Could all the plane->fb and old_fb updates be done by drm_atomic_commit or 
> async_commit instead?

If we decide to not care for stale "old_fb" pointers, I agree we
should make the commit-helpers do it.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 11:55 AM, Daniel Vetter  wrote:
> From: Matt Roper 
>
> Starting with commit
>
> commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
> Author: Rob Clark 
> Date:   Tue Aug 25 15:36:00 2015 -0400
>
> drm/i915: enable atomic fb-helper
>
> I've been seeing some panics on i915 when the DRM master shuts down that 
> appear
> to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
> dropping our initial FB's reference count to 0 and freeing it, which causes a
> crash when we try to restore it later).  Digging deeper, the state FB
> refcounting is working as expected, but we seem to be missing proper
> refcounting on the legacy plane->fb pointers in the new atomic fbdev code.
>
> Tracking plane->old_fb and then doing a ref/unref at the end of the
> fbdev restore like we do in the legacy ioctl's ensures we don't miscount
> references on plane->fb and avoids the panics.
>
> v2 from Daniel:
>
> Really do what the atomic ioctl does:
> - Also update plane->fb and plane->crtc.
> - Clear out plane->old_fb on failures too.
>
> Cc: Rob Clark 
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Matt Roper  (v1)
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 64fc5ca8fda2..1b564a69f561 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -352,6 +352,8 @@ retry:
> drm_for_each_plane(plane, dev) {
> struct drm_plane_state *plane_state;
>
> +   plane->old_fb = plane->fb;
> +
> plane_state = drm_atomic_get_plane_state(state, plane);
> if (IS_ERR(plane_state)) {
> ret = PTR_ERR(plane_state);
> @@ -382,6 +384,20 @@ retry:
> }
>
> ret = drm_atomic_commit(state);
> +
> +   drm_for_each_plane(plane, dev) {
> +   if (ret == 0) {
> +   struct drm_framebuffer *new_fb = plane->state->fb;
> +   if (new_fb)
> +   drm_framebuffer_reference(new_fb);
> +   plane->fb = new_fb;
> +   plane->crtc = plane->state->crtc;
> +
> +   if (plane->old_fb)
> +   drm_framebuffer_unreference(plane->old_fb);
> +   }
> +   }
> +
> if (ret != 0)
> goto fail;

Why move the fixup _before_ the error-check? drm_atomic_ioctl() does
this to make sure it never leaves stale "old_fb" pointers, but this is
clearly not what you do here. So either move it after the error-check
and drop the then redundant "if (ret ==0)" from the loop, or move it
into the "fail:" condition (maybe rename it) and properly take care of
"old_fb" and not-freeing "state".

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[David Herrmann]

Hi

On Wed, Sep 9, 2015 at 5:02 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Wed, Sep 09, 2015 at 04:40:56PM +0200, Maarten Lankhorst wrote:
>> Previously RMFB and fd close chose to disable any plane that had
>> an active framebuffer from this file. If it was a primary plane the
>> crtc was disabled. However the fbdev code or any system compositor
>> should restore the planes anyway so there's no need to do it twice.
>>
>> The old fb_id is zero'd, so there's no danger of being able to
>> restore the fb from fb_id.
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
>
> I think the current behaviour was just a side-effect of the original
> implementation and not too intentional - with no refcounting for fbs they
> _had_ to be synchronously reaped. And when I've done the conversion to
> refcounting I kept this to avoid gettting tangled up in an ABI-change
> mess.
>
> But I don't the current behaviour makes much sense and worth an attemp to
> rectify it. And as long as we still clear the fb ids there's no real
> information leak either.
>
> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
>
> But I do want other people's opinion before I pull this in.

We _REALLY_ want this! It makes a lot of our life much easier when
trying to get rid of flicker during boot-up. It currently sucks that
neither the boot-loader screen, nor the boot-splash screen, nor the
login-manager screen can be left around after they quit and handover
to the next stage. We have to stay around for hand-over, which is
nasty and requires a back-channel which is otherwise not needed at
all.

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/core: Preserve the fb id on close.

[David Herrmann]

Hi

On Wed, Sep 9, 2015 at 4:40 PM, Maarten Lankhorst
<maarten.lankho...@linux.intel.com> wrote:
> Keep the fb_id, which means that any application exiting without
> unsetting the framebuffer from all planes will preserve its contents.
>
> This is similar to preserving the initial framebuffer, except all
> planes are preserved.
>
> Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_crtc.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)

Same as 1/2:

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 626b0a57efbf..9d55c0c6aa95 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3320,9 +3320,6 @@ int drm_mode_rmfb(struct drm_device *dev,
> if (!found)
> goto fail_lookup;
>
> -   /* Mark fb as reaped, we still have a ref from fpriv->fbs. */
> -   __drm_framebuffer_unregister(dev, fb);
> -
> list_del_init(>filp_head);
> mutex_unlock(>mode_config.fb_lock);
> mutex_unlock(_priv->fbs_lock);
> @@ -3508,15 +3505,9 @@ void drm_fb_release(struct drm_file *priv)
>  * at it any more.
>  */
> list_for_each_entry_safe(fb, tfb, >fbs, filp_head) {
> -
> -   mutex_lock(>mode_config.fb_lock);
> -   /* Mark fb as reaped, we still have a ref from fpriv->fbs. */
> -   __drm_framebuffer_unregister(dev, fb);
> -   mutex_unlock(>mode_config.fb_lock);
> -
> list_del_init(>filp_head);
>
> -   /* This will also drop the fpriv->fbs reference. */
> +   /* This drops the fpriv->fbs reference. */
> drm_framebuffer_unreference(fb);
> }
>  }
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[David Herrmann]

Hi

On Thu, Sep 10, 2015 at 12:15 PM, Tvrtko Ursulin
 wrote:
> On 09/10/2015 10:56 AM, Daniel Vetter wrote:
>> That's not different from the compositor just freezing instead of
>> crashing: Screen contents stays on and nothing happens. Imo this really is
>> all just broken userspace, and the kernel can't make sure userspace
>> doesn't randomly fall over.
>>
>> What we need to make sure is that assuming things work ok-ish there's no
>> observed regression. And I still think that's the case here.
>
>
> I would disagree on the no regressions when things work okay-ish principle,
> there should be no regressions in the pessimistic scenario when security is
> concerned.
>
> If we can agree the stuck frame on screen is not desirable from the security
> point of view, then this change does enlarge the attack surface.
>
> Because, apart from freezing the compositor, it now also works to crash it
> and prevent restart. Maybe it is far fetched, but as I said, attackers have
> much better imagination with these things.

I'd much more prefer a FB flag that forces a modeset on ID removal.
Anyone who cares for it can set it, and the kernel will make sure to
never keep such FBs around. However, for most use-cases, we want the
FB to stay around after close() or FB removal.

Btw., I also don't see the attack scenario at all. If an attacker
makes your compositor crash at the same moment a security-relevant
information is shown on screen, then the information is already
visible. Who cares that it stays visible? Sure, I can make up an
hypothetical use-case where that matters, but I cannot think of
something real.
Also, if the hypothetical scenario we go for is "if the compositor
crashes", then I guess there's bigger problems than the FB content.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Nuke drm_framebuffer->helper_private

[David Herrmann]

Hi

On Thu, Sep 10, 2015 at 10:39 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> It's completely unused and there's really no reason for this:
> - drm_framebuffer structures are invariant after creation, no need for
>   helpers to manipulate them.
> - drm_framebuffer structures should just be embedded (and that's what
>   all the drivers do).
>
> Stumbled over this since some folks are apparently concerned with the
> overhead of struct drm_framebuffer and this is an easy 8 byte saving.
>
> More could be gained by ditching the legacy fields and recomputing
> stuff from the fourcc value. But that would require some drm-wide
> cocci and real justification.
>
> Cc: gary.k.sm...@intel.com
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
>  include/drm/drm_crtc.h | 2 --
>  1 file changed, 2 deletions(-)

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 75f49c1ef8bb..c0366e9152e2 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -210,8 +210,6 @@ struct drm_framebuffer {
> int flags;
> uint32_t pixel_format; /* fourcc format */
> struct list_head filp_head;
> -   /* if you are using the helper */
> -   void *helper_private;
>  };
>
>  struct drm_property_blob {
> --
> 2.5.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/11] drm: Define a drm_invalid_op ioctl implementation

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> And use it in radeon to replace all the ioctls no longer valid in kms
> mode. I plan to also use this later on when nuking the ums support for
> i915.
>
> Note that setting the function pointer in the ioctl table to NULL
> would amount to the same, but that results in some debug output from
> the drm_ioctl() function. I've figured it's cleaner to have a
> special-purpose function.
>
> Cc: Alex Deucher <alexdeuc...@gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
>  drivers/gpu/drm/drm_ioctl.c |  7 +++
>  drivers/gpu/drm/radeon/radeon_kms.c | 94 
> +++--
>  include/drm/drmP.h  |  2 +
>  3 files changed, 36 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 4d7f2677b2ea..f0b4f581f6ce 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -415,6 +415,13 @@ int drm_noop(struct drm_device *dev, void *data,
>  }
>  EXPORT_SYMBOL(drm_noop);
>
> +int drm_invalid_op(struct drm_device *dev, void *data,
> +  struct drm_file *file_priv)
> +{
> +   return -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_invalid_op);
> +

We could just store ERR_PTR(-EINVAL) in the ioctl-table and make the
ioctl-handler handle this. Anyway:

Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Thanks
David

>  /**
>   * Copy and IOCTL return string to user space
>   */
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 4a119c255ba9..03d285b30c83 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -844,74 +844,34 @@ int radeon_get_vblank_timestamp_kms(struct drm_device 
> *dev, int crtc,
>  drmcrtc, 
> >hwmode);
>  }
>
> -#define KMS_INVALID_IOCTL(name)  
>   \
> -static int name(struct drm_device *dev, void *data, struct drm_file\
> -   *file_priv) \
> -{  \
> -   DRM_ERROR("invalid ioctl with kms %s\n", __func__); \
> -   return -EINVAL; \
> -}
> -
> -/*
> - * All these ioctls are invalid in kms world.
> - */
> -KMS_INVALID_IOCTL(radeon_cp_init_kms)
> -KMS_INVALID_IOCTL(radeon_cp_start_kms)
> -KMS_INVALID_IOCTL(radeon_cp_stop_kms)
> -KMS_INVALID_IOCTL(radeon_cp_reset_kms)
> -KMS_INVALID_IOCTL(radeon_cp_idle_kms)
> -KMS_INVALID_IOCTL(radeon_cp_resume_kms)
> -KMS_INVALID_IOCTL(radeon_engine_reset_kms)
> -KMS_INVALID_IOCTL(radeon_fullscreen_kms)
> -KMS_INVALID_IOCTL(radeon_cp_swap_kms)
> -KMS_INVALID_IOCTL(radeon_cp_clear_kms)
> -KMS_INVALID_IOCTL(radeon_cp_vertex_kms)
> -KMS_INVALID_IOCTL(radeon_cp_indices_kms)
> -KMS_INVALID_IOCTL(radeon_cp_texture_kms)
> -KMS_INVALID_IOCTL(radeon_cp_stipple_kms)
> -KMS_INVALID_IOCTL(radeon_cp_indirect_kms)
> -KMS_INVALID_IOCTL(radeon_cp_vertex2_kms)
> -KMS_INVALID_IOCTL(radeon_cp_cmdbuf_kms)
> -KMS_INVALID_IOCTL(radeon_cp_getparam_kms)
> -KMS_INVALID_IOCTL(radeon_cp_flip_kms)
> -KMS_INVALID_IOCTL(radeon_mem_alloc_kms)
> -KMS_INVALID_IOCTL(radeon_mem_free_kms)
> -KMS_INVALID_IOCTL(radeon_mem_init_heap_kms)
> -KMS_INVALID_IOCTL(radeon_irq_emit_kms)
> -KMS_INVALID_IOCTL(radeon_irq_wait_kms)
> -KMS_INVALID_IOCTL(radeon_cp_setparam_kms)
> -KMS_INVALID_IOCTL(radeon_surface_alloc_kms)
> -KMS_INVALID_IOCTL(radeon_surface_free_kms)
> -
> -
>  const struct drm_ioctl_desc radeon_ioctls_kms[] = {
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_INIT, radeon_cp_init_kms, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_START, radeon_cp_start_kms, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_STOP, radeon_cp_stop_kms, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_RESET, radeon_cp_reset_kms, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_IDLE, radeon_cp_idle_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_RESUME, radeon_cp_resume_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_RESET, radeon_engine_reset_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_FULLSCREEN, radeon_fullscreen_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_SWAP, radeon_cp_swap_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_CLEAR, radeon_cp_clear_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_VERTEX, radeon_cp_vertex_kms, D

Re: [Intel-gfx] drm i915 weirdness with /sys/class/drm/card0*/status

[David Herrmann]

Hi

On Tue, Jun 16, 2015 at 11:25 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 16.06.15 13:47, Daniel Vetter (dan...@ffwll.ch) wrote:

  But what does that actually mean? should logind ever echo detect
  itself into the file? Should it follow uevents for the files? How
  should treat this file?

 Ok here's how this is supposed to work:
 - If anything changes the kernel will send out an uevent and compositors/X
   or anyone else interested can listen for them. We've had a few bugs in
   the past where such events where lost in a combination of bad luck and
   bad hw, but that should all be fixed now.

 - Userspace should never poll these things on its own since probing is
   ridiculously expensive. Unfortunately years of closing bugs as wontfix
   hasn't lead to userspace stop polling (despite that the kernel does that
   too if it's needed) which resulted in the above patch to take away the
   those from at least system deamons.

 I find the kernel patch you applied a bit drastic, it broke userspace,
 returning rubbish unless somebody echoes the detect into the file --
 which apparently nothing does, at least not after we came back from a
 suspend...

I don't think it was supposed to work this way. If I read Daniel's
reply correctly, then the kernel is supposed to re-read connector
state after resume (without explicit trigger from user-space). It
might return 'unknown' for some time, but once it was refreshed, it
should send out a uevent and the correct state should now be read. And
logind works fine with this behavior.

Anyway, I'm not sure why your machine doesn't work that way. I cannot
see the problems here on my machine.

  Well, but things are close enough, closing the lid, plugging in a
  second display and then leaving it off and expecting things to suspend
  now is probably a very exceptional case...
 
  That said, how would I check if the connector is both plugged *and*
  enabled? If there's a sane sysfs API for that, I'd be happy to extend
  the check for you.

 In the same sysyfs directory there's enabled (indicating that an output
 is logically in use) and dpms (which shows the dpms state, but that is
 not clamped to Off when the output isn't in use because of ABI history and
 other hilarious reasons). enabled == enabled  dpms == On is probably
 what you want.

 OK, I will change logind to check these two as well. Thanks for the hint!

I don't think we should look at DPMS (compositors use it for runtime
energy management). Otherwise, looks good to me.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 2/3] drm/ipvr: drm driver for vxd392

[David Herrmann]

Hi

On Thu, Oct 16, 2014 at 3:39 PM, Cheng, Yao yao.ch...@intel.com wrote:
 Accepted :) I will update the patch to implement the mmap interface and 
 remove the legacy MMAP_IOCTL.
 BTW I didn't see a field to get mmap_offset in struct drm_gem_open, I guess 
 something like a new  GET_MMAP_OFFSET_IOCTL need be added to support 
 mapping flinked/primed BO, is it?

Yes. There is currently no generic interface to get mmap offsets for
any gem bo (because some of them may not be mapped from user-space or
require extra parameters).

So, either support dumb-buffers (if you don't need any advanced
parameters like tiling or cache constraints), or add an
MMAP_OFFSET_IOCTL like you proposed (and most drivers do so).

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm: add tile_group support.

[David Herrmann]

Hi

On Mon, Oct 20, 2014 at 8:37 AM, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com

 A tile group is an identifier shared by a single monitor,
 DisplayID topology has 8 bytes we can use for this, just
 use those for now until something else comes up in the
 future. We assign these to an idr and use the idr to
 tell userspace what connectors are in the same tile group.

 DisplayID v1.3 says the serial number must be unique for
 displays from the same manufacturer.

 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  drivers/gpu/drm/drm_crtc.c | 61 
 ++
  include/drm/drm_crtc.h | 16 
  2 files changed, 77 insertions(+)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 90e7730..dfccc34 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -5037,6 +5037,7 @@ void drm_mode_config_init(struct drm_device *dev)
 INIT_LIST_HEAD(dev-mode_config.property_blob_list);
 INIT_LIST_HEAD(dev-mode_config.plane_list);
 idr_init(dev-mode_config.crtc_idr);
 +   idr_init(dev-mode_config.tile_idr);

You are missing a call to idr_destroy() in drm_mode_config_cleanup().
The IDR caches are not cleaned up automatically when it drops to size
0...

Thanks
David


 drm_modeset_lock_all(dev);
 drm_mode_create_standard_connector_properties(dev);
 @@ -5146,3 +5147,63 @@ struct drm_property 
 *drm_mode_create_rotation_property(struct drm_device *dev,
supported_rotations);
  }
  EXPORT_SYMBOL(drm_mode_create_rotation_property);
 +
 +static void drm_tile_group_free(struct kref *kref)
 +{
 +   struct drm_tile_group *tg = container_of(kref, struct drm_tile_group, 
 refcount);
 +   struct drm_device *dev = tg-dev;
 +   mutex_lock(dev-mode_config.idr_mutex);
 +   idr_remove(dev-mode_config.tile_idr, tg-id);
 +   mutex_lock(dev-mode_config.idr_mutex);
 +   kfree(tg);
 +}
 +
 +void drm_mode_put_tile_group(struct drm_device *dev,
 +struct drm_tile_group *tg)
 +{
 +   kref_put(tg-refcount, drm_tile_group_free);
 +}
 +
 +struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
 +  char topology[8])
 +{
 +   struct drm_tile_group *tg;
 +   int id;
 +   mutex_lock(dev-mode_config.idr_mutex);
 +   idr_for_each_entry(dev-mode_config.tile_idr, tg, id) {
 +   if (!memcmp(tg-group_data, topology, 8)) {
 +   kref_get(tg-refcount);
 +   mutex_unlock(dev-mode_config.idr_mutex);
 +   return tg;
 +   }
 +   }
 +   mutex_unlock(dev-mode_config.idr_mutex);
 +   return NULL;
 +}
 +
 +struct drm_tile_group *drm_mode_create_tile_group(struct drm_device *dev,
 + char topology[8])
 +{
 +   struct drm_tile_group *tg;
 +   int ret;
 +
 +   tg = kzalloc(sizeof(*tg), GFP_KERNEL);
 +   if (!tg)
 +   return ERR_PTR(-ENOMEM);
 +
 +   kref_init(tg-refcount);
 +   memcpy(tg-group_data, topology, 8);
 +   tg-dev = dev;
 +
 +   mutex_lock(dev-mode_config.idr_mutex);
 +   ret = idr_alloc(dev-mode_config.tile_idr, tg, 1, 0, GFP_KERNEL);
 +   if (ret = 0) {
 +   tg-id = ret;
 +   } else {
 +   kfree(tg);
 +   tg = NULL;
 +   }
 +
 +   mutex_unlock(dev-mode_config.idr_mutex);
 +   return tg;
 +}
 diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
 index f1105d0..afaec4b 100644
 --- a/include/drm/drm_crtc.h
 +++ b/include/drm/drm_crtc.h
 @@ -136,6 +136,14 @@ struct drm_display_info {
 u8 cea_rev;
  };

 +/* data corresponds to displayid vend/prod/serial */
 +struct drm_tile_group {
 +   struct kref refcount;
 +   struct drm_device *dev;
 +   int id;
 +   u8 group_data[8];
 +};
 +
  struct drm_framebuffer_funcs {
 /* note: use drm_framebuffer_remove() */
 void (*destroy)(struct drm_framebuffer *framebuffer);
 @@ -770,6 +778,7 @@ struct drm_mode_config {
 struct drm_modeset_acquire_ctx *acquire_ctx; /* for legacy 
 _lock_all() / _unlock_all() */
 struct mutex idr_mutex; /* for IDR management */
 struct idr crtc_idr; /* use this idr for all IDs, fb, crtc, 
 connector, modes - just makes life easier */
 +   struct idr tile_idr; /* use this idr for all IDs, fb, crtc, 
 connector, modes - just makes life easier */
 /* this is limited to one for now */


 @@ -1106,6 +1115,13 @@ extern void drm_set_preferred_mode(struct 
 drm_connector *connector,
  extern int drm_edid_header_is_valid(const u8 *raw_edid);
  extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
 print_bad_edid);
  extern bool drm_edid_is_valid(struct edid *edid);
 +
 +extern struct drm_tile_group *drm_mode_create_tile_group(struct 

Re: [Intel-gfx] [RFC PATCH 2/3] drm/ipvr: drm driver for vxd392

[David Herrmann]

Hi

On Wed, Oct 15, 2014 at 4:14 AM, Cheng, Yao yao.ch...@intel.com wrote:
 Hi Herrmann

 -Original Message-
 From: David Herrmann [mailto:dh.herrm...@gmail.com]
 Sent: Monday, October 13, 2014 10:27 PM
 To: Cheng, Yao
 Cc: Intel Graphics Development; Jiang, Fei; dri-de...@lists.freedesktop.org;
 Vetter, Daniel
 Subject: Re: [RFC PATCH 2/3] drm/ipvr: drm driver for vxd392

 Hi

  +static struct drm_ioctl_desc ipvr_gem_ioctls[] = {
  +   DRM_IOCTL_DEF_DRV(IPVR_CONTEXT_CREATE,
  +   ipvr_context_create_ioctl, DRM_UNLOCKED),
  +   DRM_IOCTL_DEF_DRV(IPVR_CONTEXT_DESTROY,
  +   ipvr_context_destroy_ioctl, DRM_UNLOCKED),
  +   DRM_IOCTL_DEF_DRV(IPVR_MISC,
  +   ipvr_misc_ioctl, DRM_AUTH),
  +   DRM_IOCTL_DEF_DRV(IPVR_GEM_EXECBUFFER,
  +   ipvr_gem_execbuffer, DRM_AUTH|DRM_UNLOCKED),
  +   DRM_IOCTL_DEF_DRV(IPVR_GEM_BUSY,
  +   ipvr_gem_busy_ioctl, DRM_AUTH|DRM_UNLOCKED),
  +   DRM_IOCTL_DEF_DRV(IPVR_GEM_CREATE,
  +   ipvr_gem_create_ioctl, DRM_UNLOCKED),
  +   DRM_IOCTL_DEF_DRV(IPVR_GEM_MMAP,
  +   ipvr_gem_mmap_ioctl, DRM_UNLOCKED),

 Why do you need this ioctl? mmap() should work perfectly fine. I don't see
 why you require people to use a ipvr specific ioctl to map buffers.

 Many thanks to your comments, in our existing libdrm helper and userspace 
 drivers, mmap_ioctl was the interface of mapping objects. We continued using 
 the ioctl way for compatibility. Is it mandatory to implement mmap() to 
 replace mmap_ioctl for GEM drivers?

Usually we don't care for existing user-space. We want APIs to be
cleanly designed when they go upstream. But I'm not the authority to
decide that. All I do is recommend hooking it up with mmap() like
everyone else does. If that's not what you want, you have to convince
Dave (and probably Daniel). The least you can do is hook up mmap() and
make it work. Whether there is a legacy ioctl to do the same, I don't
care..

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 2/3] drm/ipvr: drm driver for vxd392

[David Herrmann]

Hi

 +static struct drm_ioctl_desc ipvr_gem_ioctls[] = {
 +   DRM_IOCTL_DEF_DRV(IPVR_CONTEXT_CREATE,
 +   ipvr_context_create_ioctl, DRM_UNLOCKED),
 +   DRM_IOCTL_DEF_DRV(IPVR_CONTEXT_DESTROY,
 +   ipvr_context_destroy_ioctl, DRM_UNLOCKED),
 +   DRM_IOCTL_DEF_DRV(IPVR_MISC,
 +   ipvr_misc_ioctl, DRM_AUTH),
 +   DRM_IOCTL_DEF_DRV(IPVR_GEM_EXECBUFFER,
 +   ipvr_gem_execbuffer, DRM_AUTH|DRM_UNLOCKED),
 +   DRM_IOCTL_DEF_DRV(IPVR_GEM_BUSY,
 +   ipvr_gem_busy_ioctl, DRM_AUTH|DRM_UNLOCKED),
 +   DRM_IOCTL_DEF_DRV(IPVR_GEM_CREATE,
 +   ipvr_gem_create_ioctl, DRM_UNLOCKED),
 +   DRM_IOCTL_DEF_DRV(IPVR_GEM_MMAP,
 +   ipvr_gem_mmap_ioctl, DRM_UNLOCKED),

Why do you need this ioctl? mmap() should work perfectly fine. I don't
see why you require people to use a ipvr specific ioctl to map
buffers.

 +   DRM_IOCTL_DEF_DRV(IPVR_SYNC_CPU,
 +   ipvr_sync_cpu_ioctl, DRM_UNLOCKED),
 +   DRM_IOCTL_DEF_DRV(IPVR_GEM_WAIT,
 +   ipvr_gem_wait_ioctl, DRM_AUTH|DRM_UNLOCKED),
 +   DRM_IOCTL_DEF_DRV(IPVR_GEM_USERPTR,
 +   ipvr_gem_userptr_ioctl, DRM_UNLOCKED),
 +};
 +
 +static void ipvr_gem_init(struct drm_device *dev)
 +{
 +   struct drm_ipvr_private *dev_priv = dev-dev_private;
 +
 +   dev_priv-ipvr_bo_slab = kmem_cache_create(ipvr_gem_object,
 + sizeof(union drm_ipvr_gem_objects), 0,
 + SLAB_HWCACHE_ALIGN, NULL);
 +
 +   INIT_LIST_HEAD(dev_priv-ipvr_mm.unbound_list);
 +   INIT_LIST_HEAD(dev_priv-ipvr_mm.bound_list);
 +   spin_lock_init(dev_priv-ipvr_mm.object_stat_lock);
 +
 +   dev_priv-ipvr_mm.interruptible = true;
 +}
 +
 +static void ipvr_gem_setup_mmu(struct drm_device *dev,
 +  unsigned long linear_start,
 +  unsigned long linear_end,
 +  unsigned long tiling_start,
 +  unsigned long tiling_end)
 +{
 +   /* Let GEM Manage all of the aperture.
 +*
 +* However, leave one page at the end still bound to the scratch page.
 +* There are a number of places where hardware apparently prefetches
 +* past the end of the object, and we've seen multiple hangs with the
 +* GPU head pointer stuck in a batchbuffer bound at last page of the
 +* aperture.  One page should be enough to keep any prefetching inside
 +* of the aperture.
 +*/
 +   struct drm_ipvr_private *dev_priv = dev-dev_private;
 +   struct ipvr_address_space *addr_space = dev_priv-addr_space;
 +
 +   /* todo: add sanity check */
 +   addr_space-dev = dev_priv-dev;
 +   INIT_LIST_HEAD(addr_space-active_list);
 +   INIT_LIST_HEAD(addr_space-inactive_list);
 +
 +   /* Subtract the guard page ... */
 +   drm_mm_init(addr_space-linear_mm, linear_start,
 +   linear_end - linear_start - PAGE_SIZE);
 +   dev_priv-addr_space.linear_start = linear_start;
 +   dev_priv-addr_space.linear_total = linear_end - linear_start;
 +
 +   drm_mm_init(addr_space-tiling_mm, tiling_start,
 +   tiling_end - tiling_start - PAGE_SIZE);
 +   dev_priv-addr_space.tiling_start = tiling_start;
 +   dev_priv-addr_space.tiling_total = tiling_end - tiling_start;
 +}
 +
 +static void ipvr_do_takedown(struct drm_device *dev)
 +{
 +   /* todo: need check if need clean up mm here */
 +   ipvr_ved_uninit(dev);
 +}
 +
 +static int32_t ipvr_drm_unload(struct drm_device *dev)
 +{
 +   struct drm_ipvr_private *dev_priv = dev-dev_private;
 +
 +   BUG_ON(!dev-platformdev);
 +   BUG_ON(atomic_read(dev_priv-ved_power_usage));
 +
 +   IPVR_DEBUG_ENTRY(entered.);
 +   if (dev_priv) {
 +   WARN_ON(pm_runtime_get_sync(dev-platformdev-dev)  0);
 +
 +   if (dev_priv-ipvr_bo_slab)
 +   kmem_cache_destroy(dev_priv-ipvr_bo_slab);
 +   ipvr_fence_driver_fini(dev_priv);
 +
 +   ipvr_do_takedown(dev);
 +
 +   WARN_ON(pm_runtime_put_sync_suspend(dev-platformdev-dev)  
 0);
 +
 +   if (dev_priv-validate_ctx.buffers)
 +   vfree(dev_priv-validate_ctx.buffers);
 +
 +   if (dev_priv-pf_pd) {
 +   ipvr_mmu_free_pagedir(dev_priv-pf_pd);
 +   dev_priv-pf_pd = NULL;
 +   }
 +   if (dev_priv-mmu) {
 +   ipvr_mmu_driver_takedown(dev_priv-mmu);
 +   dev_priv-mmu = NULL;
 +   }
 +
 +   if (dev_priv-ved_reg_base) {
 +   iounmap(dev_priv-ved_reg_base - 
 dev_priv-ved_reg_offset);
 +   dev_priv-ved_reg_base = NULL;
 +

Re: [Intel-gfx] [PATCH] drm: Fixup locking for universal cursor planes

[David Herrmann]

Hi

On Fri, Sep 12, 2014 at 5:07 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 Bunch of things amiss:
 - Updating crtc-cursor_x/y was done without any locking. Spotted by
   David Herrmann.
 - Dereferencing crtc-cursor-fb was using the wrong lock, should take
   the crtc lock.
 - Grabbing _all_ modeset locks torpedoes the reason why we added
   fine-grained locks originally: Cursor updates shouldn't stall on
   background stuff like probing outputs.

 Best is to just grab the crtc lock around everything and drop all the
 other locking. The only issue is that we can't switch planes between
 crtcs with that, so make sure that never happens when someone uses
 universal plane helpers. This shouldn't be a possible regression ever
 since legacy ioctls also only grabbed the crtc lock, so switching
 crtcs was never possible for the underlying plane object. And i915
 (the only user of universal cursors thus far) has fixed cursor-crtc
 links.

 Cc: David Herrmann dh.herrm...@gmail.com
 Cc: Pallavi Gpallav...@intel.com
 Cc: Matt Roper matthew.d.ro...@intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@intel.com

 --
 Totally untested, but should aim in the right direction. Roughly.

 Cheers, Daniel
 ---
  drivers/gpu/drm/drm_crtc.c | 51 
 ++
  1 file changed, 34 insertions(+), 17 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index b1271a8d8ce7..8c1870114a07 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -2262,21 +2262,19 @@ out:
   *
   * src_{x,y,w,h} are provided in 16.16 fixed point format
   */
 -static int setplane_internal(struct drm_plane *plane,
 -struct drm_crtc *crtc,
 -struct drm_framebuffer *fb,
 -int32_t crtc_x, int32_t crtc_y,
 -uint32_t crtc_w, uint32_t crtc_h,
 -/* src_{x,y,w,h} values are 16.16 fixed point */
 -uint32_t src_x, uint32_t src_y,
 -uint32_t src_w, uint32_t src_h)
 +static int __setplane_internal(struct drm_plane *plane,
 +  struct drm_crtc *crtc,
 +  struct drm_framebuffer *fb,
 +  int32_t crtc_x, int32_t crtc_y,
 +  uint32_t crtc_w, uint32_t crtc_h,
 +  /* src_{x,y,w,h} values are 16.16 fixed point 
 */
 +  uint32_t src_x, uint32_t src_y,
 +  uint32_t src_w, uint32_t src_h)
  {
 -   struct drm_device *dev = plane-dev;
 int ret = 0;
 unsigned int fb_width, fb_height;
 int i;

 -   drm_modeset_lock_all(dev);
 /* No fb means shut it down */
 if (!fb) {
 plane-old_fb = plane-fb;
 @@ -2344,10 +2342,28 @@ out:
 if (plane-old_fb)
 drm_framebuffer_unreference(plane-old_fb);
 plane-old_fb = NULL;
 -   drm_modeset_unlock_all(dev);

 return ret;
 +}

 +static int setplane_internal(struct drm_plane *plane,
 +struct drm_crtc *crtc,
 +struct drm_framebuffer *fb,
 +int32_t crtc_x, int32_t crtc_y,
 +uint32_t crtc_w, uint32_t crtc_h,
 +/* src_{x,y,w,h} values are 16.16 fixed point */
 +uint32_t src_x, uint32_t src_y,
 +uint32_t src_w, uint32_t src_h)
 +{
 +   int ret;
 +
 +   drm_modeset_lock_all(plane-dev);
 +   ret = __setplane_internal(plane, crtc, fb,
 + crtc_x, crtc_y, crtc_w, crtc_h,
 + src_x, src_y, src_w, src_h);
 +   drm_modeset_unlock_all(plane-dev);

Might be confusing to call into drivers with different locks held
depending on the plane. But on the other hand, I think drivers should
just assume only the involved CRTCs are locked, so it sounds fine.
With atomic we get the same behavior, presumably.

Reviewed-by: David Herrmann dh.herrm...@gmail.com

Thanks
David

 +
 +   return ret;
  }

  /**
 @@ -2713,6 +2729,7 @@ static int drm_mode_cursor_universal(struct drm_crtc 
 *crtc,
 int ret = 0;

 BUG_ON(!crtc-cursor);
 +   WARN_ON(crtc-cursor-crtc != crtc  crtc-cursor-crtc != NULL);

 /*
  * Obtain fb we'll be using (either new or existing) and take an extra
 @@ -2732,11 +2749,9 @@ static int drm_mode_cursor_universal(struct drm_crtc 
 *crtc,
 fb = NULL;
 }
 } else {
 -   mutex_lock(dev-mode_config.mutex);
 fb = crtc-cursor-fb;
 if (fb)
 drm_framebuffer_reference(fb);
 -   mutex_unlock(dev-mode_config.mutex);
 }

 if (req-flags

Re: [Intel-gfx] [PATCH] drm: Include task-name and master status in debugfs clients info

[David Herrmann]

Hi

On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 Showing who is the current master is useful for trying to decypher
 errors when trying to acquire master (e.g. a race with X taking over
 from plymouth). By including the process name as well as the pid
 simplifies the task of grabbing enough information remotely at the point
 of error.

 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  drivers/gpu/drm/drm_info.c | 17 -
  1 file changed, 12 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
 index 15ec9f4..d813430 100644
 --- a/drivers/gpu/drm/drm_info.c
 +++ b/drivers/gpu/drm/drm_info.c
 @@ -184,14 +184,21 @@ int drm_clients_info(struct seq_file *m, void *data)
 struct drm_file *priv;

 mutex_lock(dev-struct_mutex);
 -   seq_printf(m, a devpiduid  magic\n\n);
 -   list_for_each_entry(priv, dev-filelist, lhead) {
 -   seq_printf(m, %c %3d %5d %5d %10u\n,
 -  priv-authenticated ? 'y' : 'n',
 -  priv-minor-index,
 +   seq_printf(m,pid dev master a   uid  
 magic\n);

Maybe mention task here? Or is this supposed to be a logical part of pid?

 +   list_for_each_entry_reverse(priv, dev-filelist, lhead) {

No idea why you do backwards traversal, but ok..

 +   struct task_struct *task;
 +
 +   rcu_read_lock();

What's that rcu-lock for? task-comm is pre-allocated, priv-pid is
static, kuid... no idea?

Anyway, patch looks good otherwise. Especially task-comm sounds
really handy in that list.

Thanks
David

 +   task = pid_task(priv-pid, PIDTYPE_PID);
 +   seq_printf(m, %20s %5d %3d   %c%c %5d %10u\n,
 +  task ? task-comm : unknown,
pid_vnr(priv-pid),
 +  priv-minor-index,
 +  priv-is_master ? 'y' : 'n',
 +  priv-authenticated ? 'y' : 'n',
from_kuid_munged(seq_user_ns(m), priv-uid),
priv-magic);
 +   rcu_read_unlock();
 }
 mutex_unlock(dev-struct_mutex);
 return 0;
 --
 1.9.1

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Include task-name and master status in debugfs clients info

[David Herrmann]

Hi

On Mon, Sep 1, 2014 at 4:19 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Mon, Sep 01, 2014 at 04:11:43PM +0200, David Herrmann wrote:
 Hi

 On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  Showing who is the current master is useful for trying to decypher
  errors when trying to acquire master (e.g. a race with X taking over
  from plymouth). By including the process name as well as the pid
  simplifies the task of grabbing enough information remotely at the point
  of error.
 
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  ---
   drivers/gpu/drm/drm_info.c | 17 -
   1 file changed, 12 insertions(+), 5 deletions(-)
 
  diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
  index 15ec9f4..d813430 100644
  --- a/drivers/gpu/drm/drm_info.c
  +++ b/drivers/gpu/drm/drm_info.c
  @@ -184,14 +184,21 @@ int drm_clients_info(struct seq_file *m, void *data)
  struct drm_file *priv;
 
  mutex_lock(dev-struct_mutex);
  -   seq_printf(m, a devpiduid  magic\n\n);
  -   list_for_each_entry(priv, dev-filelist, lhead) {
  -   seq_printf(m, %c %3d %5d %5d %10u\n,
  -  priv-authenticated ? 'y' : 'n',
  -  priv-minor-index,
  +   seq_printf(m,pid dev master a   uid  
  magic\n);

 Maybe mention task here? Or is this supposed to be a logical part of pid?

 Yeah, I was thinking that comm/pid were essentially the same column. Top
 uses command which would be reasonable to reuse.

Sounds all fine. Just wanted to go sure it's not a typo.

  +   list_for_each_entry_reverse(priv, dev-filelist, lhead) {

 No idea why you do backwards traversal, but ok..

 Clients are added youngest-first. So traversing backwards gives
   kernel
   X/display manager
   clients

  +   struct task_struct *task;
  +
  +   rcu_read_lock();

 What's that rcu-lock for? task-comm is pre-allocated, priv-pid is
 static, kuid... no idea?

 Cargo-culting the locking from the discussion with Tetsuo:

 commit 3ec2f427e6f82b9b8f9b18dd2c758b864385df39
 Author: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
 Date:   Fri Jan 3 20:42:18 2014 +0900

 drm/i915: Fix refcount leak and possible NULL pointerdereference.

 Since get_pid_task() grabs a reference on the task_struct, we have to 
 drop the
 refcount after reading that task's comm name. Use pid_task() with RCU 
 instead.

 Also, avoid directly reading like pid_task()-comm because
 pid_task() will return NULL if the task have already exit()ed.

 This patch fixes both problems.

Ah, right, this is for pid lookup not task-comm. Should have seen that..

Feel free to add:
Reviewed-by: David Herrmann dh.herrm...@gmail.com

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr

[David Herrmann]

Hi

On Wed, Aug 6, 2014 at 9:10 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 The current refcounting scheme is that the fb lookup idr also holds a
 reference. This works out nicely bacause thus far we've always
 explicitly cleaned up idr entries for framebuffers:
 - Userspace fbs get removed in the rmfb ioctl or when the drm file
   gets closed.
 - Kernel fbs (for fbdev emulation) get cleaned up by the driver code
   at module unload time.

 But now i915 also reconstructs the bios fbs for a smooth transition.
 And that fb is purely transitional and should get removed immmediately
 once all crtcs stop using it. Of course if the i915 fbdev code decides
 to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
 in that case the fbdev code will grab it's own reference.

 The problem is now that we also want to register that takeover fb in
 the idr, so that userspace can do a smooth transition (animated maybe
 even!) itself. But currently we have no one who will clean up the idr
 reference once that fb isn't useful any more, and so essentially leak
 it.

 Fix this by no longer holding a full fb reference for the idr, but
 instead just have a weak reference using kref_get_unless_zero. But
 that requires us to synchronize and clean up with the idr and fb_lock
 in drm_framebuffer_free, so add that. It's a bit ugly that we have to
 unconditionally grab the fb_lock, but without that someone might creep
 through a race.

 This leak was caught by the fb leak check in drm_mode_config_cleanup.
 Originally the leak was introduced in

 commit 46f297fb83d4f9a6f6891964beb184664341a28b
 Author: Jesse Barnes jbar...@virtuousgeek.org
 Date:   Fri Mar 7 08:57:48 2014 -0800

 drm/i915: add plane_config fetching infrastructure v2

 Cc:  Jesse Barnes jbar...@virtuousgeek.org
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/drm_crtc.c | 46 
 --
  1 file changed, 28 insertions(+), 18 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index fa2be24c..33ff631c8d23 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -515,9 +515,6 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
 drm_framebuffer *fb,
 if (ret)
 goto out;

 -   /* Grab the idr reference. */
 -   drm_framebuffer_reference(fb);
 -
 dev-mode_config.num_fb++;
 list_add(fb-head, dev-mode_config.fb_list);
  out:
 @@ -527,10 +524,34 @@ out:
  }
  EXPORT_SYMBOL(drm_framebuffer_init);

 +/* dev-mode_config.fb_lock must be held! */
 +static void __drm_framebuffer_unregister(struct drm_device *dev,
 +struct drm_framebuffer *fb)
 +{
 +   mutex_lock(dev-mode_config.idr_mutex);
 +   idr_remove(dev-mode_config.crtc_idr, fb-base.id);
 +   mutex_unlock(dev-mode_config.idr_mutex);
 +
 +   fb-base.id = 0;
 +}
 +
  static void drm_framebuffer_free(struct kref *kref)
  {
 struct drm_framebuffer *fb =
 container_of(kref, struct drm_framebuffer, refcount);
 +   struct drm_device *dev = fb-dev;
 +
 +   /*
 +* The lookup idr holds a weak reference, which has not necessarily 
 been
 +* removed at this point. Check for that.
 +*/
 +   mutex_lock(dev-mode_config.fb_lock);
 +   if (fb-base.id) {
 +   /* Mark fb as reaped and drop idr ref. */
 +   __drm_framebuffer_unregister(dev, fb);
 +   }
 +   mutex_unlock(dev-mode_config.fb_lock);

Ewww, this is ugly. You now make the unregistration dynamic and it's
no longer under driver control. The typical device-control flow
assumes there's an authority that controls at which point objects are
registered and unregistered. You now bind it to ref-counts. To be
fair, I think lastclose is equally hackish (and doesn't really work
like you argued already).

I think the real problem is that you want two ref-counts: One
ref-count controls the object availability, the other ref-count
controls the visibility to user-space. This is also what gem does: you
have a kernel-internal ref-count for each gem-object, but you also
have user-space handles. A handle implies a kernel-internal ref-count
but not vice versa. And the object is only accessible from user-space,
as long as you own a handle. I think we want something similar for
FBs. This way you could unregister the bios-FB once no handle exists
(assuming a CRTC owns a handle as long as the FB is used as scan-out).

But I guess no-one wants to implement this, so I still think this
patch is the nicest way to make it work. So I'm fine with it.

Thanks
David

 +
 fb-funcs-destroy(fb);
  }

 @@ -567,8 +588,10 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct 
 drm_device *dev,

 mutex_lock(dev-mode_config.fb_lock);
 fb = __drm_framebuffer_lookup(dev, id);
 -   

Re: [Intel-gfx] [PATCH] drm: Restore drm_file-is_master

[David Herrmann]

Hi

On Thu, Aug 7, 2014 at 3:04 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 Despite the claims of

 commit 48ba813701eb14b3008edefef4a0789b328e278c
 Author: David Herrmann dh.herrm...@gmail.com
 Date:   Tue Jul 22 18:46:09 2014 +0200

 drm: drop redundant drm_file-is_master

 drm_file-is_master is not synomous with having drm_file-master ==
 drm_file-minor-master. This is because drm_file-master is the same
 for all drm_files of the same generation and so when there is a master,
 every drm_file believes itself to be the master. Confusion ensues and
 things go pear shaped when one file is closed and there is no master
 anymore.

Uagh, embarrassing. A revert is fine with me, but I'll try to review
your patch once I get home.

Thanks
David

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82283
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Alex Deucher alexander.deuc...@amd.com
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Cc: David Herrmann dh.herrm...@gmail.com
 ---
  drivers/gpu/drm/drm_drv.c  |  5 ++---
  drivers/gpu/drm/drm_fops.c | 12 ++--
  include/drm/drmP.h |  3 ++-
  3 files changed, 10 insertions(+), 10 deletions(-)

 diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
 index a1863d8..76cdb51 100644
 --- a/drivers/gpu/drm/drm_drv.c
 +++ b/drivers/gpu/drm/drm_drv.c
 @@ -198,6 +198,7 @@ int drm_setmaster_ioctl(struct drm_device *dev, void 
 *data,
 if (unlikely(ret != 0))
 drm_master_put(file_priv-minor-master);
 }
 +   file_priv-is_master = ret == 0;

  out_unlock:
 mutex_unlock(dev-master_mutex);
 @@ -213,13 +214,11 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void 
 *data,
 if (!drm_is_master(file_priv))
 goto out_unlock;

 -   if (!file_priv-minor-master)
 -   goto out_unlock;
 -
 ret = 0;
 if (dev-driver-master_drop)
 dev-driver-master_drop(dev, file_priv, false);
 drm_master_put(file_priv-minor-master);
 +   file_priv-is_master = false;

  out_unlock:
 mutex_unlock(dev-master_mutex);
 diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 index c0166ba..083f7b9 100644
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -196,6 +196,7 @@ static int drm_open_helper(struct file *filp, struct 
 drm_minor *minor)

 /* take another reference for the copy in the local file priv 
 */
 priv-master = drm_master_get(priv-minor-master);
 +   priv-is_master = true;
 priv-authenticated = 1;

 if (dev-driver-master_create) {
 @@ -434,12 +435,11 @@ int drm_release(struct inode *inode, struct file *filp)
 }
 mutex_unlock(dev-struct_mutex);

 -   if (file_priv-minor-master == file_priv-master) {
 -   /* drop the reference held my the minor */
 -   if (dev-driver-master_drop)
 -   dev-driver-master_drop(dev, file_priv, 
 true);
 -   drm_master_put(file_priv-minor-master);
 -   }
 +   /* drop the reference held my the minor */
 +   if (dev-driver-master_drop)
 +   dev-driver-master_drop(dev, file_priv, true);
 +   drm_master_put(file_priv-minor-master);
 +   file_priv-is_master = false;
 }

 /* drop the master reference held by the file priv */
 diff --git a/include/drm/drmP.h b/include/drm/drmP.h
 index 0ffce5c..70a6598 100644
 --- a/include/drm/drmP.h
 +++ b/include/drm/drmP.h
 @@ -378,6 +378,7 @@ struct drm_prime_file_private {

  /** File private data */
  struct drm_file {
 +   bool is_master:1;
 unsigned authenticated :1;
 /* true when the client has asked us to expose stereo 3D mode flags */
 unsigned stereo_allowed :1;
 @@ -1177,7 +1178,7 @@ static inline bool drm_is_primary_client(const struct 
 drm_file *file_priv)
   */
  static inline bool drm_is_master(const struct drm_file *file)
  {
 -   return file-master  file-master == file-minor-master;
 +   return file-is_master;
  }

  /**/
 --
 1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Unlink dead file_priv from list of active files first

[David Herrmann]

Hi

On Thu, Jul 24, 2014 at 3:23 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 In order to prevent external observers walking the list of open DRM
 files from seeing an invalid drm_file_private in the process of being
 torndown, the first operation we need to take is to unlink the
 drm_file_private from that list.

 general protection fault:  [#1] PREEMPT SMP
 Modules linked in: i915 i2c_algo_bit drm_kms_helper drm lpc_ich 
 mfd_core nls_iso8859_1 i2c_hid video hid_generic usbhid hid e1000e ahci ptp 
 libahci pps_core
 CPU: 3 PID: 8220 Comm: cat Not tainted 3.16.0-rc6+ #4
 Hardware name: Intel Corporation Shark Bay Client platform/WhiteTip 
 Mountain 1, BIOS HSWLPTU1.86C.0119.R00.1303230105 03/23/2013
 task: 8800219642c0 ti: 880047024000 task.ti: 880047024000
 RIP: 0010:[a0137c70]  [a0137c70] 
 per_file_stats+0x110/0x160 [i915]
 RSP: 0018:880047027d48  EFLAGS: 00010246
 RAX: 6b6b6b6b6b6b6b6b RBX: 880047027e30 RCX: 
 RDX: 0001 RSI:  RDI: 88003a05cd00
 RBP: 880047027d58 R08: 0001 R09: 
 R10: 8800219642c0 R11:  R12: 88003a05cd00
 R13:  R14: 88003a05cd00 R15: 880047027d88
 FS:  7f5f73a13740() GS:88014e38() 
 knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 023ff038 CR3: 21a4b000 CR4: 001407e0
 Stack:
  0001  880047027dc8 813438e4
  880047027e30 a0137b60 880021a8af58 880021a8f1a0
  8800a2061fb0 8800a2062048 8800a2061fb0 8800a1e23478
 Call Trace:
  [813438e4] idr_for_each+0xf4/0x180
  [a0137b60] ? i915_gem_stolen_list_info+0x1f0/0x1f0 [i915]
  [a013a17a] i915_gem_object_info+0x5ca/0x6a0 [i915]
  [81193ec5] seq_read+0xf5/0x3a0
  [8116d950] vfs_read+0x90/0x150
  [8116e509] SyS_read+0x49/0xb0
  [815d8622] tracesys+0xd0/0xd5
 Code: 01 00 00 49 39 84 24 08 01 00 00 74 55 49 8b 84 24 b8 00 00 00 
 48 01 43 18 31 c0 5b 41 5c 5d c3 0f 1f 00 49 8b 44 24 08 4c 89 e7 48 8b 70 
 28 48 81 c6 48 80 00 00 e8 80 14 01 00 84 c0 74 bc 49
 RIP  [a0137c70] per_file_stats+0x110/0x160 [i915]
 RSP 880047027d48

 Reported-by: Ursulin, Tvrtko tvrtko.ursu...@intel.com
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81712
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Ursulin, Tvrtko tvrtko.ursu...@intel.com

I have the same change in my local drm_file cleanup. This is:

Reviewed-by: David Herrmann dh.herrm...@gmail.com

Thanks
David

 ---
  drivers/gpu/drm/drm_fops.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 index a0c63cf..aff8217 100644
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -416,6 +416,10 @@ int drm_release(struct inode *inode, struct file *filp)

 DRM_DEBUG(open_count = %d\n, dev-open_count);

 +   mutex_lock(dev-struct_mutex);
 +   list_del(file_priv-lhead);
 +   mutex_unlock(dev-struct_mutex);
 +
 if (dev-driver-preclose)
 dev-driver-preclose(dev, file_priv);

 @@ -509,10 +513,6 @@ int drm_release(struct inode *inode, struct file *filp)
 file_priv-is_master = 0;
 mutex_unlock(dev-master_mutex);

 -   mutex_lock(dev-struct_mutex);
 -   list_del(file_priv-lhead);
 -   mutex_unlock(dev-struct_mutex);
 -
 if (dev-driver-postclose)
 dev-driver-postclose(dev, file_priv);

 --
 1.9.1

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Only unbind vgacon, not other console drivers

[David Herrmann]

Hi

On Tue, Jul 8, 2014 at 10:08 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 The console subsystem only provides a function to switch to a given
 console, but we want to actually only switach away from vgacon.
 Unconditionally switching to the dummy console resulted in switching
 away from fbcon in multi-gpu setups when other gpu drivers are loaded
 before i915.

 Then either the reinitialization of fbcon when i915 registers its
 fbdev emulation or the teardown of the fbcon driver killed the
 machine. So only switch to the dummy console when it's required.

 Kudos to Chris for the original idea, I've only refined it a bit to
 still unregister vgacon even when it's currently unused.

 This regression has been introduced in

 commit a4de05268e674e8ed31df6348269e22d6c6a1803
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Thu Jun 5 16:20:46 2014 +0200

 drm/i915: Kick out vga console

 Reported-and-tested-by: Ed Tomlinson e...@aei.ca
 Cc: Chris Wilson ch...@chris-wilson.co.uk
 Cc: David Herrmann dh.herrm...@gmail.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Reviewed-by: David Herrmann dh.herrm...@gmail.com

Thanks
David

 ---
  drivers/gpu/drm/i915/i915_dma.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index 6c656392d67d..d44344140627 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -1464,12 +1464,13 @@ static int i915_kick_out_vgacon(struct 
 drm_i915_private *dev_priv)
  #else
  static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
  {
 -   int ret;
 +   int ret = 0;

 DRM_INFO(Replacing VGA console driver\n);

 console_lock();
 -   ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
 +   if (con_is_bound(vga_con))
 +   ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 
 1, 1);
 if (ret == 0) {
 ret = do_unregister_con_driver(vga_con);

 --
 2.0.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console

[David Herrmann]

Hi

On Mon, Jun 30, 2014 at 8:59 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
 On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:

 Resend without html krud which causes list to bounce the message.

  Hi
 
  This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot 
  with 3.16-git.  Reverting it lets the boot proceed.
 
  I have an i7 with a built-in i915 and an pcie r7 260x.  The R7 is the 
  primary console.  The i915 is initialized
  but does not have a physical display attached.
 
  With the patch applied the boot stops at the messages:
 
  [drm] Memory usable by graphics device = 2048M
  [drm] Replacing VGA console driver

 The issue looks like that we are ripping out the radeon fb_con whilst it
 is active and that upsets everyone. In which case, I think the
 compromise is:

do_take_over_console() should only touch console-drivers like fbcon.
How does this affect the underlying fbdev device? Ripping out active
or inactive fbcon should be just fine, shouldn't it?

Given that this hard-locks at kick_out_vgacon(), this looks more like
a dead-lock to me.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: add register and unregister functions for connectors

[David Herrmann]

Hi

On Thu, May 29, 2014 at 5:57 PM, Thomas Wood thomas.w...@intel.com wrote:
 Introduce generic functions to register and unregister connectors. This
 provides a common place to add and remove associated user space
 interfaces.

 Signed-off-by: Thomas Wood thomas.w...@intel.com
 ---
  Documentation/DocBook/drm.tmpl|  6 +++---
  drivers/gpu/drm/armada/armada_output.c|  4 ++--
  drivers/gpu/drm/ast/ast_mode.c|  4 ++--
  drivers/gpu/drm/bridge/ptn3460.c  |  2 +-
  drivers/gpu/drm/drm_crtc.c| 30 
 ++-
  drivers/gpu/drm/drm_sysfs.c   |  2 --
  drivers/gpu/drm/exynos/exynos_dp_core.c   |  2 +-
  drivers/gpu/drm/exynos/exynos_drm_connector.c |  6 +++---
  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  4 ++--
  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  2 +-
  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  2 +-
  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
  drivers/gpu/drm/gma500/cdv_intel_crt.c|  4 ++--
  drivers/gpu/drm/gma500/cdv_intel_dp.c |  4 ++--
  drivers/gpu/drm/gma500/cdv_intel_hdmi.c   |  4 ++--
  drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  4 ++--
  drivers/gpu/drm/gma500/mdfld_dsi_output.c |  4 ++--
  drivers/gpu/drm/gma500/oaktrail_hdmi.c|  2 +-
  drivers/gpu/drm/gma500/oaktrail_lvds.c|  2 +-
  drivers/gpu/drm/gma500/psb_intel_lvds.c   |  4 ++--
  drivers/gpu/drm/gma500/psb_intel_sdvo.c   |  4 ++--
  drivers/gpu/drm/i915/intel_crt.c  |  2 +-
  drivers/gpu/drm/i915/intel_display.c  |  2 +-
  drivers/gpu/drm/i915/intel_dp.c   |  4 ++--
  drivers/gpu/drm/i915/intel_dsi.c  |  2 +-
  drivers/gpu/drm/i915/intel_dvo.c  |  2 +-
  drivers/gpu/drm/i915/intel_hdmi.c |  2 +-
  drivers/gpu/drm/i915/intel_lvds.c |  2 +-
  drivers/gpu/drm/i915/intel_sdvo.c | 10 -
  drivers/gpu/drm/i915/intel_tv.c   |  2 +-
  drivers/gpu/drm/mgag200/mgag200_mode.c|  2 +-
  drivers/gpu/drm/msm/hdmi/hdmi_connector.c |  4 ++--
  drivers/gpu/drm/nouveau/nouveau_connector.c   |  4 ++--
  drivers/gpu/drm/omapdrm/omap_connector.c  |  4 ++--
  drivers/gpu/drm/qxl/qxl_display.c |  4 ++--
  drivers/gpu/drm/radeon/radeon_connectors.c|  6 +++---
  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  4 ++--
  drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |  4 ++--
  drivers/gpu/drm/shmobile/shmob_drm_crtc.c |  6 +++---
  drivers/gpu/drm/tegra/output.c|  4 ++--
  drivers/gpu/drm/tilcdc/tilcdc_panel.c |  2 +-
  drivers/gpu/drm/tilcdc/tilcdc_slave.c |  2 +-
  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c|  2 +-
  drivers/gpu/drm/udl/udl_connector.c   |  4 ++--
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c   |  2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c  |  2 +-
  drivers/staging/imx-drm/imx-drm-core.c|  6 +++---

You even caught imx.. and you removed the EXPORT_SYMBOL. So looks all
good to me.
I like that refactoring and I don't think we need an ACK from all
driver authors. This is:

Reviewed-by: David Herrmann dh.herrm...@gmail.com

Maybe Daniel or Dave can pick this up?

Thanks
David

  include/drm/drm_crtc.h|  2 ++
  49 files changed, 110 insertions(+), 82 deletions(-)

 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 00f1c25..0f96b25 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -1574,7 +1574,7 @@ int max_width, max_height;/synopsis
The connector is then registered with a call to
functiondrm_connector_init/function with a pointer to the 
 connector
functions and a connector type, and exposed through sysfs with a 
 call to
 -  functiondrm_sysfs_connector_add/function.
 +  functiondrm_connector_register/function.
  /para
  para
Supported connector types are
 @@ -1732,7 +1732,7 @@ int max_width, max_height;/synopsis
 (functiondrm_encoder_cleanup/function) and connectors
 (functiondrm_connector_cleanup/function). Furthermore, connectors
 that have been added to sysfs must be removed by a call to
 -   functiondrm_sysfs_connector_remove/function before calling
 +   functiondrm_connector_unregister/function before calling
 functiondrm_connector_cleanup/function.
/para
para
 @@ -1777,7 +1777,7 @@ void intel_crt_init(struct drm_device *dev)
 drm_encoder_helper_add(intel_output-enc, intel_crt_helper_funcs);
 drm_connector_helper_add(connector, 
 intel_crt_connector_helper_funcs);

 -   drm_sysfs_connector_add(connector);
 +   drm_connector_register(connector);
  }]]/programlisting
para
  In the example above (taken from the i915 driver

Re: [Intel-gfx] [PATCH 2/3] drm/debugfs: add a force file per connector

[David Herrmann]

Hi

On Thu, May 29, 2014 at 5:57 PM, Thomas Wood thomas.w...@intel.com wrote:
 Add a file to debugfs for each connector to enable modification of the
 force connector attribute. This allows connectors to be enabled or
 disabled for testing and debugging purposes.

 Signed-off-by: Thomas Wood thomas.w...@intel.com
 ---
  drivers/gpu/drm/drm_crtc.c|  17 ++-
  drivers/gpu/drm/drm_debugfs.c | 101 
 ++
  include/drm/drmP.h|  11 +
  include/drm/drm_crtc.h|   2 +
  4 files changed, 130 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 998663c..59a2784 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -841,6 +841,8 @@ int drm_connector_init(struct drm_device *dev,
 drm_object_attach_property(connector-base,
   dev-mode_config.dpms_property, 0);

 +   connector-debugfs_entry = NULL;
 +
  out_put:
 if (ret)
 drm_mode_object_put(dev, connector-base);
 @@ -891,7 +893,19 @@ EXPORT_SYMBOL(drm_connector_cleanup);
   */
  int drm_connector_register(struct drm_connector *connector)
  {
 -   return drm_sysfs_connector_add(connector);
 +   int ret;
 +
 +   ret = drm_sysfs_connector_add(connector);
 +   if (ret != 0)

nitpick: I've never seen xy != 0 in DRM code, I think if (ret) or
if (ret  0) is what we usually use..

 +   return ret;
 +
 +   ret = drm_debugfs_connector_add(connector);
 +   if (ret != 0) {
 +   drm_sysfs_connector_remove(connector);
 +   return ret;
 +   }
 +
 +   return 0;
  }
  EXPORT_SYMBOL(drm_connector_register);

 @@ -904,6 +918,7 @@ EXPORT_SYMBOL(drm_connector_register);
  void drm_connector_unregister(struct drm_connector *connector)
  {
 drm_sysfs_connector_remove(connector);
 +   drm_debugfs_connector_remove(connector);
  }
  EXPORT_SYMBOL(drm_connector_unregister);

 diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
 index b4b51d4..b57b614 100644
 --- a/drivers/gpu/drm/drm_debugfs.c
 +++ b/drivers/gpu/drm/drm_debugfs.c
 @@ -237,5 +237,106 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
 return 0;
  }

 +static int connector_show(struct seq_file *m, void *data)
 +{
 +   struct drm_connector *connector = m-private;
 +   const char *status;
 +
 +   switch (connector-force) {
 +   case DRM_FORCE_ON:
 +   status = on\n;
 +   break;
 +
 +   case DRM_FORCE_ON_DIGITAL:
 +   status = digital\n;
 +   break;
 +
 +   case DRM_FORCE_OFF:
 +   status = off\n;
 +   break;
 +
 +   case DRM_FORCE_UNSPECIFIED:
 +   status = unspecified\n;
 +   break;
 +
 +   default:
 +   return 0;
 +   }
 +
 +   seq_puts(m, status);
 +
 +   return 0;
 +}
 +
 +static int connector_open(struct inode *inode, struct file *file)
 +{
 +   struct drm_connector *dev = inode-i_private;
 +
 +   return single_open(file, connector_show, dev);
 +}
 +
 +static ssize_t connector_write(struct file *file, const char __user *ubuf,
 +  size_t len, loff_t *offp)
 +{
 +   struct seq_file *m = file-private_data;
 +   struct drm_connector *connector = m-private;
 +
 +   if (strncmp(ubuf, on, len) == 0)

That hits on o as strncmp(o, on, 1) == 0. We really need a
startswith() macro in the kernel.. same below.

 +   connector-force = DRM_FORCE_ON;
 +   else if (strncmp(ubuf, digital, len) == 0)
 +   connector-force = DRM_FORCE_ON_DIGITAL;
 +   else if (strncmp(ubuf, off, len) == 0)
 +   connector-force = DRM_FORCE_OFF;
 +   else if (strncmp(ubuf, unspecified, len) == 0)
 +   connector-force = DRM_FORCE_UNSPECIFIED;
 +   else
 +   return -EINVAL;
 +
 +   return len;
 +}
 +
 +static const struct file_operations drm_connector_fops = {
 +   .owner = THIS_MODULE,
 +   .open = connector_open,
 +   .read = seq_read,
 +   .llseek = seq_lseek,
 +   .release = single_release,
 +   .write = connector_write
 +};
 +
 +int drm_debugfs_connector_add(struct drm_connector *connector)
 +{
 +   struct drm_minor *minor = connector-dev-primary;
 +   struct dentry *root, *ent;
 +
 +   if (!minor-debugfs_root)
 +   return -1;
 +
 +   root = debugfs_create_dir(drm_get_connector_name(connector),
 + minor-debugfs_root);
 +   if (!root)
 +   return -ENOMEM;
 +
 +   connector-debugfs_entry = root;
 +
 +   /* force */
 +   ent = debugfs_create_file(force, S_IRUGO, root, connector,
 + drm_connector_fops);
 +   if (!ent)
 +   return -ENOMEM;

You need to cleanup connector-debugfs_entry here as you're not doing

Re: [Intel-gfx] [PATCH 3/3] drm/debugfs: add an edid_override file per connector

[David Herrmann]

Hi

On Thu, May 29, 2014 at 5:57 PM, Thomas Wood thomas.w...@intel.com wrote:
 Add a file to debugfs for each connector that allows the edid data to be
 overridden.

 Signed-off-by: Thomas Wood thomas.w...@intel.com
 ---
  drivers/gpu/drm/drm_crtc.c |  4 +++
  drivers/gpu/drm/drm_debugfs.c  | 56 
 ++
  drivers/gpu/drm/drm_probe_helper.c |  9 +-
  include/drm/drm_crtc.h |  1 +
  4 files changed, 69 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 59a2784..8543eac 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -3701,6 +3701,10 @@ int drm_mode_connector_update_edid_property(struct 
 drm_connector *connector,
 struct drm_device *dev = connector-dev;
 int ret, size;

 +   /* ignore requests to set edid when overridden */
 +   if (connector-override_edid)
 +   return 0;
 +
 if (connector-edid_blob_ptr)
 drm_property_destroy_blob(dev, connector-edid_blob_ptr);

 diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
 index b57b614..2c666ba 100644
 --- a/drivers/gpu/drm/drm_debugfs.c
 +++ b/drivers/gpu/drm/drm_debugfs.c
 @@ -35,6 +35,7 @@
  #include linux/slab.h
  #include linux/export.h
  #include drm/drmP.h
 +#include drm/drm_edid.h

  #if defined(CONFIG_DEBUG_FS)

 @@ -295,6 +296,55 @@ static ssize_t connector_write(struct file *file, const 
 char __user *ubuf,
 return len;
  }

 +static int edid_show(struct seq_file *m, void *data)
 +{
 +   struct drm_connector *connector = m-private;
 +   struct drm_property_blob *edid = connector-edid_blob_ptr;
 +
 +   if (connector-override_edid  edid)
 +   seq_write(m, edid-data, edid-length);
 +
 +   return 0;
 +}
 +
 +static int edid_open(struct inode *inode, struct file *file)
 +{
 +   struct drm_connector *dev = inode-i_private;
 +
 +   return single_open(file, edid_show, dev);
 +}
 +
 +static ssize_t edid_write(struct file *file, const char __user *ubuf,
 + size_t len, loff_t *offp)
 +{
 +   struct seq_file *m = file-private_data;
 +   struct drm_connector *connector = m-private;

Please copy ubuf before accessing it.. that's a user-space buffer.
 +
 +   if (len = EDID_LENGTH) {

What? So if you write any invalid EDID, you reset it? That's wrong..
You should return an error in those cases.

 +   drm_mode_connector_update_edid_property(connector,
 +   (struct edid *) ubuf);
 +   connector-override_edid = true;

Please check the error-code of update_edid_property() before setting
override_edid. You should also return that code if it is an error.

Furthermore, you must force override_edid = false; before calling
update_edid_property, otherwise writing twice to this file will
discard the second write (because update_edid_property() will do
nothing as override_edid is already true).

Last but not least, you *must* do an overflow check here!

 +   } else {
 +   if (connector-override_edid) {
 +   connector-override_edid = false;
 +   drm_mode_connector_update_edid_property(connector,
 +   NULL);
 +   }
 +   }
 +
 +   return len;


Maybe you want something like this (untested!):


char *buf;
struct edid *edid;
int ret;

buf = memdup_user(ubuf, len);
if (IS_ERR(buf))
return PTR_ERR(buf);

edid = buf;
connector-override_edid = false;

if (len == 5  !strcmp(buf, reset)) {
ret = drm_mode_connector_update_edid_property(connector, NULL);
} else if (len  EDID_LENGTH || EDID_LENGTH * (1 + edid-extensions)  len) {
ret = -EINVAL;
} else {
ret = drm_mode_connector_update_edid_property(connector,
(struct edid*)buf);
if (!ret)
connector-override_edid = true;
}

kfree(buf);
return ret ? : len;



Thanks
David

 +}
 +
 +static const struct file_operations drm_edid_fops = {
 +   .owner = THIS_MODULE,
 +   .open = edid_open,
 +   .read = seq_read,
 +   .llseek = seq_lseek,
 +   .release = single_release,
 +   .write = edid_write
 +};
 +
 +
  static const struct file_operations drm_connector_fops = {
 .owner = THIS_MODULE,
 .open = connector_open,
 @@ -325,6 +375,12 @@ int drm_debugfs_connector_add(struct drm_connector 
 *connector)
 if (!ent)
 return -ENOMEM;

 +   /* edid */
 +   ent = debugfs_create_file(edid_override, S_IRUGO, root, connector,

IRUGO? Shouldn't this be writable for root?

 + drm_edid_fops);
 +   if (!ent)
 +   return -ENOMEM;
 +
 return 0;
  }

 diff --git a/drivers/gpu/drm/drm_probe_helper.c 
 b/drivers/gpu/drm/drm_probe_helper.c
 index 79f07f2..1f0dc77 100644
 --- 

Re: [Intel-gfx] [PATCH 3/5] vt: Don't ignore unbind errors in vt_unbind

[David Herrmann]

Hi

On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 Otherwise the loop will never stop since we don't make any
 forward progress. Noticed while breaking this accidentally
 in a painful attempt to make vga_con unregistering work.

 With this patch we'll bail out on the first attempt, which
 at least leaves a useful enough system behind for debugging.
 Livelocks on console_lock just aren't fun.

 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 Cc: Jiri Slaby jsl...@suse.cz
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

We used to return 0 on errors here, which is very backwards to me.. so
your change to use retval looks fine to me. This is:

Reviewed-by: David Herrmann dh.herrm...@gmail.com

Thanks
David

 ---
  drivers/tty/vt/vt.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
 index 5077fe87324d..3c00dcb3b145 100644
 --- a/drivers/tty/vt/vt.c
 +++ b/drivers/tty/vt/vt.c
 @@ -3260,6 +3260,7 @@ static int vt_unbind(struct con_driver *con)
  {
 const struct consw *csw = NULL;
 int i, more = 1, first = -1, last = -1, deflt = 0;
 +   int ret;

 if (!con-con || !(con-flag  CON_DRIVER_FLAG_MODULE) ||
 con_is_graphics(con-con, con-first, con-last))
 @@ -3285,8 +3286,10 @@ static int vt_unbind(struct con_driver *con)

 if (first != -1) {
 console_lock();
 -   do_unbind_con_driver(csw, first, last, deflt);
 +   ret = do_unbind_con_driver(csw, first, last, deflt);
 console_unlock();
 +   if (ret != 0)
 +   return ret;
 }

 first = -1;
 --
 1.8.1.4

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] vt: Fix up unregistration of vt drivers

[David Herrmann]

Hi

On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 A bunch of issues:
 - We should not kick out the default console (which is tracked in
   conswitchp), so check for that.
 - Add better error codes so callers can differentiate between something
   went wrong and your driver isn't registered already. i915 needs
   that so it doesn't fall over when reloading the driver and hence
   vga_con is already unregistered.
 - There's a mess with the driver flags: What we need to check for is
   that the driver isn't used any more, i.e. unbound completely (FLAG_INIT).
   And not whether it's the boot console or not (which is the only one
   which doesn't have FLAG_MODULE). Otherwise there's no way to kick
   out the boot console, which i915 wants to do to prevent havoc with
   vga_con interferring (which tends to hang machines).

 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 Cc: Jiri Slaby jsl...@suse.cz
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/tty/vt/vt.c | 16 +---
  1 file changed, 9 insertions(+), 7 deletions(-)

 diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
 index ea600f482eeb..5077fe87324d 100644
 --- a/drivers/tty/vt/vt.c
 +++ b/drivers/tty/vt/vt.c
 @@ -3573,17 +3573,20 @@ err:
   */
  int do_unregister_con_driver(const struct consw *csw)
  {
 -   int i, retval = -ENODEV;
 +   int i;

 /* cannot unregister a bound driver */
 if (con_is_bound(csw))
 -   goto err;
 +   return -EBUSY;
 +
 +   if (csw == conswitchp)
 +   return -EINVAL;

Ugh, that fix is correct, but I'd rather like to see
do_unbind_con_driver() do the right thing. It currently resets
conswitchp _only_ if the new fallback is unbound. Why not _always_ set
conswitchp to defcsw _iff_ conswitchp == csw there?

This way, you _know_ here that if !con_is_bound(csw), then csw != conswitchp.


 for (i = 0; i  MAX_NR_CON_DRIVER; i++) {
 struct con_driver *con_driver = registered_con_driver[i];

 if (con_driver-con == csw 
 -   con_driver-flag  CON_DRIVER_FLAG_MODULE) {
 +   con_driver-flag  CON_DRIVER_FLAG_INIT) {

That makes FLAG_MODULE almost a no-op except for -unbind(). I wonder
why FLAG_MODULE exists, anyway.

Otherwise looks good.

Thanks
David

 vtconsole_deinit_device(con_driver);
 device_destroy(vtconsole_class,
MKDEV(0, con_driver-node));
 @@ -3594,12 +3597,11 @@ int do_unregister_con_driver(const struct consw *csw)
 con_driver-flag = 0;
 con_driver-first = 0;
 con_driver-last = 0;
 -   retval = 0;
 -   break;
 +   return 0;
 }
 }
 -err:
 -   return retval;
 +
 +   return -ENODEV;
  }
  EXPORT_SYMBOL_GPL(do_unregister_con_driver);

 --
 1.8.1.4

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console

[David Herrmann]

Hi

On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 Touching the VGA resources on an IVB EFI machine causes hard hangs when
 we then kick out the efifb. Ouch.

 Apparently this also prevents unclaimed register errors on hsw and
 hard machine hangs on my i855gm when trying to unbind fbcon.

 Also, we want this to make I915_FBDEV=n safe.

 v2: Rebase and pimp commit message.

 v3: We also need to unregister the vga console, otherwise the unbind
 of the fb console before module unload might resurrect it again.

 v4: Ignore errors when the vga console is already unregistered - this
 can happen when e.g. reloading i915.ko.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
 Cc: David Herrmann dh.herrm...@gmail.com
 Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
 Cc: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: linux-fb...@vger.kernel.org
 Cc: Jani Nikula jani.nik...@linux.intel.com
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk (v1)
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/i915_dma.c  | 43 
 +++-
  drivers/video/console/dummycon.c |  1 +
  drivers/video/console/vgacon.c   |  1 +
  3 files changed, 44 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index 27fe65ac5940..bcb66ddd649e 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -36,6 +36,8 @@
  #include i915_drv.h
  #include i915_trace.h
  #include linux/pci.h
 +#include linux/console.h
 +#include linux/vt.h
  #include linux/vgaarb.h
  #include linux/acpi.h
  #include linux/pnp.h
 @@ -1449,6 +1451,38 @@ static void i915_kick_out_firmware_fb(struct 
 drm_i915_private *dev_priv)
  }
  #endif

 +#if !defined(CONFIG_VGA_CONSOLE)
 +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
 +{
 +   return 0;
 +}
 +#elif !defined(CONFIG_DUMMY_CONSOLE)

Why not select DUMMY_CONSOLE if VT? It's really stupid to disable
DUMMY_CONSOLE.. Furthermore, we already rely on HW_CONSOLE_BINDING so
this should be safe.

Patch looks good to me:

Reviewed-by: David Herrmann dh.herrm...@gmail.com

Thanks
David

 +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
 +{
 +   return -ENODEV;
 +}
 +#else
 +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
 +{
 +   int ret;
 +
 +   DRM_INFO(Replacing VGA console driver\n);
 +
 +   console_lock();
 +   ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
 +   if (ret == 0) {
 +   ret = do_unregister_con_driver(vga_con);
 +
 +   /* Ignore already unregistered. */
 +   if (ret == -ENODEV)
 +   ret = 0;
 +   }
 +   console_unlock();
 +
 +   return ret;
 +}
 +#endif
 +
  static void i915_dump_device_info(struct drm_i915_private *dev_priv)
  {
 const struct intel_device_info *info = dev_priv-info;
 @@ -1622,8 +1656,15 @@ int i915_driver_load(struct drm_device *dev, unsigned 
 long flags)
 if (ret)
 goto out_regs;

 -   if (drm_core_check_feature(dev, DRIVER_MODESET))
 +   if (drm_core_check_feature(dev, DRIVER_MODESET)) {
 +   ret = i915_kick_out_vgacon(dev_priv);
 +   if (ret) {
 +   DRM_ERROR(failed to remove conflicting VGA 
 console\n);
 +   goto out_gtt;
 +   }
 +
 i915_kick_out_firmware_fb(dev_priv);
 +   }

 pci_set_master(dev-pdev);

 diff --git a/drivers/video/console/dummycon.c 
 b/drivers/video/console/dummycon.c
 index b63860f7beab..40bec8d64b0a 100644
 --- a/drivers/video/console/dummycon.c
 +++ b/drivers/video/console/dummycon.c
 @@ -77,3 +77,4 @@ const struct consw dummy_con = {
  .con_set_palette = DUMMY,
  .con_scrolldelta = DUMMY,
  };
 +EXPORT_SYMBOL_GPL(dummy_con);
 diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
 index 9d8feac67637..84acd6223dc5 100644
 --- a/drivers/video/console/vgacon.c
 +++ b/drivers/video/console/vgacon.c
 @@ -1440,5 +1440,6 @@ const struct consw vga_con = {
 .con_build_attr = vgacon_build_attr,
 .con_invert_region = vgacon_invert_region,
  };
 +EXPORT_SYMBOL(vga_con);

  MODULE_LICENSE(GPL);
 --
 1.8.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] vt: Fix up unregistration of vt drivers

[David Herrmann]

Hi

On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
 Hi

 On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
  A bunch of issues:
  - We should not kick out the default console (which is tracked in
conswitchp), so check for that.
  - Add better error codes so callers can differentiate between something
went wrong and your driver isn't registered already. i915 needs
that so it doesn't fall over when reloading the driver and hence
vga_con is already unregistered.
  - There's a mess with the driver flags: What we need to check for is
that the driver isn't used any more, i.e. unbound completely (FLAG_INIT).
And not whether it's the boot console or not (which is the only one
which doesn't have FLAG_MODULE). Otherwise there's no way to kick
out the boot console, which i915 wants to do to prevent havoc with
vga_con interferring (which tends to hang machines).
 
  Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
  Cc: Jiri Slaby jsl...@suse.cz
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
  ---
   drivers/tty/vt/vt.c | 16 +---
   1 file changed, 9 insertions(+), 7 deletions(-)
 
  diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
  index ea600f482eeb..5077fe87324d 100644
  --- a/drivers/tty/vt/vt.c
  +++ b/drivers/tty/vt/vt.c
  @@ -3573,17 +3573,20 @@ err:
*/
   int do_unregister_con_driver(const struct consw *csw)
   {
  -   int i, retval = -ENODEV;
  +   int i;
 
  /* cannot unregister a bound driver */
  if (con_is_bound(csw))
  -   goto err;
  +   return -EBUSY;
  +
  +   if (csw == conswitchp)
  +   return -EINVAL;

 Ugh, that fix is correct, but I'd rather like to see
 do_unbind_con_driver() do the right thing. It currently resets
 conswitchp _only_ if the new fallback is unbound. Why not _always_ set
 conswitchp to defcsw _iff_ conswitchp == csw there?

 Ha, that's what I've thought, too. But do_unbind doesn't actually change
 conswitchp, it only restores it because apparently the
 vga_con-con_startup function is a real con and changes it behind
 everyones back for no good reason. Or at least that's what the comment
 claims. Note how defconsw != defcsw ...

 I've tried to follow around how conswitchp is actually used, but besides
 that it's used to select the boot console I'm not sure at all what's going
 hence.

I missed that line:
  const struct consw *defconsw = conswitchp;

Now that I looked at it again, this looks _really_ wrong. If
conswitchp is vgacon and startup fails, we keep it set to vgacon..
ugh, weird. But ok, that's up to the people who wrote that.

Btw., conswitchp is used for visual_init(), that is, every new VT
allocation gets assigned to conswitchp. Therefore, it must be a valid
driver. (VTs are allocated and deallocated by agetty/systemd after a
session is started/ended).

 This way, you _know_ here that if !con_is_bound(csw), then csw != conswitchp.

 Hence why I dropped this approach again (I've done it originally) and
 opted for the straightforward but albeit crude direct check.

 
  for (i = 0; i  MAX_NR_CON_DRIVER; i++) {
  struct con_driver *con_driver = registered_con_driver[i];
 
  if (con_driver-con == csw 
  -   con_driver-flag  CON_DRIVER_FLAG_MODULE) {
  +   con_driver-flag  CON_DRIVER_FLAG_INIT) {

 That makes FLAG_MODULE almost a no-op except for -unbind(). I wonder
 why FLAG_MODULE exists, anyway.

 I've dug around in git history and it's less than useful. It was renamed
 from FLAG_BIND (which makes somewhat sense, since it roughly tracks
 whether a console is bound). But there's never been a justification for
 it, neither in the original patch nor in the one that renamed it.

 So I decided to not tempt fate and went with the small change here that
 I've understood somewhat (I've tried other, more invasive changes and
 failed).

 Otherwise looks good.

 I'm really reluctant to do the right thing here since the code overall has
 very unclear semantics with conswitchp and FLAG_MODULE. Can I convince
 yout that the more direct approach here is the right one?

Yeah, patch looks good.

Reviewed-by: David Herrmann dh.herrm...@gmail.com

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Kick out vga console

[David Herrmann]

Hi

On Wed, Jun 4, 2014 at 12:57 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 From: Chris Wilson ch...@chris-wilson.co.uk

 Touching the VGA resources on an IVB EFI machine causes hard hangs when
 we then kick out the efifb. Ouch.

 Apparently this also prevents unclaimed register errors on hsw and
 hard machine hangs on my i855gm when trying to unbind fbcon.

 Also, we want this to make I915_FBDEV=n safe.

 v2: Rebase and pimp commit message.

 v3: We also need to unregister the vga console, otherwise the unbind
 of the fb console before module unload might resurrect it again.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
 Cc: David Herrmann dh.herrm...@gmail.com
 Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
 Cc: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: linux-fb...@vger.kernel.org
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk (v1)
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/i915_dma.c  | 34 +-
  drivers/video/console/dummycon.c |  1 +
  drivers/video/console/vgacon.c   |  1 +
  3 files changed, 35 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index b9159ade5e85..a4df80740b37 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -36,6 +36,8 @@
  #include i915_drv.h
  #include i915_trace.h
  #include linux/pci.h
 +#include linux/console.h
 +#include linux/vt.h
  #include linux/vgaarb.h
  #include linux/acpi.h
  #include linux/pnp.h
 @@ -1450,6 +1452,29 @@ static void i915_kick_out_firmware_fb(struct 
 drm_i915_private *dev_priv)
  }
  #endif

 +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
 +{
 +#if !defined(CONFIG_VGA_CONSOLE)
 +   return 0;
 +#else
 +   int ret;
 +
 +#if !defined(CONFIG_DUMMY_CONSOLE)
 +   return -ENODEV;
 +#endif
 +
 +   DRM_INFO(Replacing VGA console driver\n);
 +
 +   console_lock();
 +   ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 1, 1);

You rely on compiler-optimizations here. dummy_con is not available
if !CONFIG_DUMMY_CONSOLE, but you use it. This causes linker-failure
if dead-code elimination is not done (-O0).

Thanks
David

 +   if (ret == 0)
 +   ret = do_unregister_con_driver(vga_con);
 +   console_unlock();
 +
 +   return ret;
 +#endif
 +}
 +
  static void i915_dump_device_info(struct drm_i915_private *dev_priv)
  {
 const struct intel_device_info *info = dev_priv-info;
 @@ -1623,8 +1648,15 @@ int i915_driver_load(struct drm_device *dev, unsigned 
 long flags)
 if (ret)
 goto out_regs;

 -   if (drm_core_check_feature(dev, DRIVER_MODESET))
 +   if (drm_core_check_feature(dev, DRIVER_MODESET)) {
 +   ret = i915_kick_out_vgacon(dev_priv);
 +   if (ret) {
 +   DRM_ERROR(failed to remove conflicting VGA 
 console\n);
 +   goto out_gtt;
 +   }
 +
 i915_kick_out_firmware_fb(dev_priv);
 +   }

 pci_set_master(dev-pdev);

 diff --git a/drivers/video/console/dummycon.c 
 b/drivers/video/console/dummycon.c
 index b63860f7beab..40bec8d64b0a 100644
 --- a/drivers/video/console/dummycon.c
 +++ b/drivers/video/console/dummycon.c
 @@ -77,3 +77,4 @@ const struct consw dummy_con = {
  .con_set_palette = DUMMY,
  .con_scrolldelta = DUMMY,
  };
 +EXPORT_SYMBOL_GPL(dummy_con);
 diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
 index 9d8feac67637..84acd6223dc5 100644
 --- a/drivers/video/console/vgacon.c
 +++ b/drivers/video/console/vgacon.c
 @@ -1440,5 +1440,6 @@ const struct consw vga_con = {
 .con_build_attr = vgacon_build_attr,
 .con_invert_region = vgacon_invert_region,
  };
 +EXPORT_SYMBOL(vga_con);

  MODULE_LICENSE(GPL);
 --
 1.8.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Kick out vga console

[David Herrmann]

Hi

On Wed, Jun 4, 2014 at 2:20 PM, Jani Nikula jani.nik...@linux.intel.com wrote:
 On Wed, 04 Jun 2014, David Herrmann dh.herrm...@gmail.com wrote:
 You rely on compiler-optimizations here. dummy_con is not available
 if !CONFIG_DUMMY_CONSOLE, but you use it. This causes linker-failure
 if dead-code elimination is not done (-O0).

 Nested #ifs too. How about

 #if !defined(CONFIG_VGA_CONSOLE)
 static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
 {
 return 0;
 }
 #elif !defined(CONFIG_DUMMY_CONSOLE)
 static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
 {
 return -ENODEV;
 }
 #else
 static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
 {
 /* ... */
 }
 #endif

 in proper kernel style?

Or even shorter:

#if defined(CONFIG_VGA_CONSOLE)  defined(CONFIG_DUMMY_CONSOLE)
static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
{
...
}
#else
static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
{
return IS_ENABLED(CONFIG_VGA_CONSOLE) ? -ENODEV : 0;
}
#endif

Thanks
David

On Wed, Jun 4, 2014 at 2:20 PM, Jani Nikula jani.nik...@linux.intel.com wrote:
 On Wed, 04 Jun 2014, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Wed, Jun 4, 2014 at 12:57 AM, Daniel Vetter daniel.vet...@ffwll.ch 
 wrote:
 From: Chris Wilson ch...@chris-wilson.co.uk

 Touching the VGA resources on an IVB EFI machine causes hard hangs when
 we then kick out the efifb. Ouch.

 Apparently this also prevents unclaimed register errors on hsw and
 hard machine hangs on my i855gm when trying to unbind fbcon.

 Also, we want this to make I915_FBDEV=n safe.

 v2: Rebase and pimp commit message.

 v3: We also need to unregister the vga console, otherwise the unbind
 of the fb console before module unload might resurrect it again.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
 Cc: David Herrmann dh.herrm...@gmail.com
 Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
 Cc: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: linux-fb...@vger.kernel.org
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk (v1)
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/i915_dma.c  | 34 +-
  drivers/video/console/dummycon.c |  1 +
  drivers/video/console/vgacon.c   |  1 +
  3 files changed, 35 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/i915_dma.c 
 b/drivers/gpu/drm/i915/i915_dma.c
 index b9159ade5e85..a4df80740b37 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -36,6 +36,8 @@
  #include i915_drv.h
  #include i915_trace.h
  #include linux/pci.h
 +#include linux/console.h
 +#include linux/vt.h
  #include linux/vgaarb.h
  #include linux/acpi.h
  #include linux/pnp.h
 @@ -1450,6 +1452,29 @@ static void i915_kick_out_firmware_fb(struct 
 drm_i915_private *dev_priv)
  }
  #endif

 +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
 +{
 +#if !defined(CONFIG_VGA_CONSOLE)
 +   return 0;
 +#else
 +   int ret;
 +
 +#if !defined(CONFIG_DUMMY_CONSOLE)
 +   return -ENODEV;
 +#endif
 +
 +   DRM_INFO(Replacing VGA console driver\n);
 +
 +   console_lock();
 +   ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 1, 1);

 You rely on compiler-optimizations here. dummy_con is not available
 if !CONFIG_DUMMY_CONSOLE, but you use it. This causes linker-failure
 if dead-code elimination is not done (-O0).

 Nested #ifs too. How about

 #if !defined(CONFIG_VGA_CONSOLE)
 static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
 {
 return 0;
 }
 #elif !defined(CONFIG_DUMMY_CONSOLE)
 static inline int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
 {
 return -ENODEV;
 }
 #else
 static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
 {
 /* ... */
 }
 #endif

 in proper kernel style?

 BR,
 Jani.



 Thanks
 David

 +   if (ret == 0)
 +   ret = do_unregister_con_driver(vga_con);
 +   console_unlock();
 +
 +   return ret;
 +#endif
 +}
 +
  static void i915_dump_device_info(struct drm_i915_private *dev_priv)
  {
 const struct intel_device_info *info = dev_priv-info;
 @@ -1623,8 +1648,15 @@ int i915_driver_load(struct drm_device *dev, 
 unsigned long flags)
 if (ret)
 goto out_regs;

 -   if (drm_core_check_feature(dev, DRIVER_MODESET))
 +   if (drm_core_check_feature(dev, DRIVER_MODESET)) {
 +   ret = i915_kick_out_vgacon(dev_priv);
 +   if (ret) {
 +   DRM_ERROR(failed to remove conflicting VGA 
 console\n);
 +   goto out_gtt;
 +   }
 +
 i915_kick_out_firmware_fb(dev_priv);
 +   }

 pci_set_master(dev-pdev);

 diff --git a/drivers/video/console/dummycon.c 
 b/drivers/video/console/dummycon.c
 index b63860f7beab..40bec8d64b0a 100644

Re: [Intel-gfx] [PATCH 0/7] drm drivers: kill drm_get_connector_name() and drm_get_encoder_name()

[David Herrmann]

Hi

On Mon, May 26, 2014 at 3:35 PM, Jani Nikula jani.nik...@intel.com wrote:
 As requested by David [1],[2].

 These are on top of drm-intel-nightly which carries the required core
 patches adding -name field to drm_connector and drm_encoder. The i915
 patches could go in right away, the last patch need to wait for radeon
 and nouveau patches to get merged, obviously.

I tried reviewing these, but it doesn't apply on drm-intel-next.
Trusting in coccinelle, this is:

Acked-by: David Herrmann dh.herrm...@gmail.com

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/sysfs: expose the force connector attribute

[David Herrmann]

Hi

On Mon, May 19, 2014 at 3:37 PM, Thomas Wood thomas.w...@intel.com wrote:
 Signed-off-by: Thomas Wood thomas.w...@intel.com

The commit-msg lacks any discussion why this change is done. What is
the reason to do that? Isn't the kernel-command-line enough? Why is
this a regular feature instead of a debugfs attribute?

 ---
  drivers/gpu/drm/drm_sysfs.c | 49 
 +
  1 file changed, 49 insertions(+)

 diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
 index c22c309..257816e 100644
 --- a/drivers/gpu/drm/drm_sysfs.c
 +++ b/drivers/gpu/drm/drm_sysfs.c
 @@ -338,11 +338,60 @@ static ssize_t select_subconnector_show(struct device 
 *device,
 drm_get_dvi_i_select_name((int)subconnector));
  }

 +static ssize_t force_show(struct device *device,
 + struct device_attribute *attr,
 + char *buf)
 +{
 +   struct drm_connector *connector = to_drm_connector(device);
 +   char *status;

const char * or gcc might warn on string assignments.

 +
 +   switch (connector-force) {
 +   case DRM_FORCE_ON:
 +   status = on;
 +   break;
 +
 +   case DRM_FORCE_ON_DIGITAL:
 +   status = digital;
 +   break;
 +
 +   case DRM_FORCE_OFF:
 +   status = off;
 +   break;
 +
 +   case DRM_FORCE_UNSPECIFIED:
 +   status = unspecified;
 +   break;
 +
 +   default:
 +   return 0;
 +   }
 +
 +   return snprintf(buf, PAGE_SIZE, %s\n, status);
 +}
 +
 +ssize_t force_store(struct device *device, struct device_attribute *attr,
 +   const char *buf, size_t count)
 +{
 +   struct drm_connector *connector = to_drm_connector(device);
 +
 +   if (strcmp(buf, on) == 0)
 +   connector-force = DRM_FORCE_ON;
 +   else if (strcmp(buf, digital) == 0)
 +   connector-force = DRM_FORCE_ON_DIGITAL;
 +   else if (strcmp(buf, off) == 0)
 +   connector-force = DRM_FORCE_OFF;
 +   else if (strcmp(buf, unspecified) == 0)
 +   connector-force = DRM_FORCE_UNSPECIFIED;

else
return -EINVAL;


This really looks like a debug-feature to me. If it's a real feature,
we _must_ rescan connectors here, otherwise it seems odd writing on
into that file but nothing happens until the next modeset.

Thanks
David

 +
 +   return count;
 +}
 +
  static struct device_attribute connector_attrs[] = {
 __ATTR_RO(status),
 __ATTR_RO(enabled),
 __ATTR_RO(dpms),
 __ATTR_RO(modes),
 +   __ATTR_RW(force),
  };

  /* These attributes are for both DVI-I connectors and all types of tv-out. */
 --
 1.9.0

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/sysfs: expose the force connector attribute

[David Herrmann]

Hi

On Mon, May 19, 2014 at 4:41 PM, Thomas Wood thomas.w...@intel.com wrote:
 On 19 May 2014 15:13, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Mon, May 19, 2014 at 3:37 PM, Thomas Wood thomas.w...@intel.com wrote:
 Signed-off-by: Thomas Wood thomas.w...@intel.com

 The commit-msg lacks any discussion why this change is done. What is
 the reason to do that? Isn't the kernel-command-line enough? Why is
 this a regular feature instead of a debugfs attribute?


 It was intended as a debug/testing feature to allow tests in
 intel-gpu-tools to enable or disable connectors:

 http://lists.freedesktop.org/archives/intel-gfx/2014-May/045556.html


 I'll update the commit message for the next version of the patch.

Thanks! But please make it a debugfs feature, if possible. We
shouldn't expose interfaces in sysfs that aren't part of the core API.
Note that this might require you to encode the connector-name in the
debugfs-attribute-name.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/sysfs: expose the force connector attribute

[David Herrmann]

Hi

On Mon, May 19, 2014 at 4:53 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote:
 On Mon, May 19, 2014 at 4:41 PM, Thomas Wood thomas.w...@intel.com wrote:
  It was intended as a debug/testing feature to allow tests in
  intel-gpu-tools to enable or disable connectors:
 
  http://lists.freedesktop.org/archives/intel-gfx/2014-May/045556.html
 
 
  I'll update the commit message for the next version of the patch.

 Thanks! But please make it a debugfs feature, if possible. We
 shouldn't expose interfaces in sysfs that aren't part of the core API.
 Note that this might require you to encode the connector-name in the
 debugfs-attribute-name.

 Imo having the read and write side in completely different parts doesn't
 make a lot of sense. Hence I think doing this in sysfs is ok. Also users
 might want to frob this for testing, and usually debugfs is a bit further
 away on most systems.

So the read-side is not debug-only? That wasn't clear to me. In that
case, I'm fine with keeping it in sysfs, although I'm not entirely
sure why anyone is interested in force information.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/10] i915: add DP 1.2 MST support (v0.3)

[David Herrmann]

Hi

On Wed, May 14, 2014 at 2:03 AM, Dave Airlie airl...@gmail.com wrote:
 Since any objects you get with find are only valid under mode_config.mutex,
 yes some drivers mess this up, but they should be fixed.

Didn't know that we have such a rule. Then it's fine, of course. The
page-flip code is what worried me, but drivers ought to cancel that
when destroying connectors, anyway.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Design review request: DRM color manager

[David Herrmann]

Hi

On Mon, May 12, 2014 at 12:26 PM, Sharma, Shashank
shashank.sha...@intel.com wrote:
 Benefits of using color manager:
 
 1. Unique framework for all the color correction properties, across all
DRM drivers, across various platforms.
 2. Only one set/get call for all kind of properties using the common
 protocol. One get call can tell what are the color correction capabilities
 of the SOC, registered by driver.

What's the advantage of that? We should add a
DRM_MODE_OBJ_SET_PROPERTIES call if we want to accelerate things,
instead of adding huge payloads.

I really think we should define one property for each color-correction
interface. I cannot see any downside of that except that we should add
DRM_MODE_OBJ_SET_PROPERTIES. But afaik that's already the plan for
atomic-modesetting, right?

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Design review request: DRM color manager

[David Herrmann]

Hi

On Mon, May 12, 2014 at 5:28 PM, Daniel Vetter dan...@ffwll.ch wrote:
 Those are all just reasons for atomic modeset and maybe an atomic modeget
 ioctl which transfers the entire blob of things. Maybe we should start
 with the atomic modeget to get things rolling. Otoh you can always do that
 in userspace since we assume there's only one display manager.

DRM_MODE_OBJ_GET_PROPERTIES is already available and allows atomic
retrieval of 'n' properties (as it calls drm_modeset_lock_all()). I
guess that qualifies as what you describe with atomic modeget?

 And for modeset we can throw efficiency of the marshalling/de-marshalling
 over board (within some limits of course) since we do about 60*num_pipes
 modeset/pageflip calls per second at most. And the overhead of the
 encoding/decoding of the properties will be completely washed out by all
 the register i/o we need to do to UC pci bars.

Yepp, I fully agree. And if properties turn out to become a
bottleneck, we should optimize them.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Design review request: DRM color manager

[David Herrmann]

Hi

On Tue, Apr 22, 2014 at 6:11 AM, Sharma, Shashank
shashank.sha...@intel.com wrote:
 Gentle reminder

Usual approach is to send any proposals as inline plain-text. It's
really hard to comment on attachments, especially if it's an MS-office
format. Anyhow, some comments on the proposal:

1) Why do you register only a single property? Why not register a
separate property for each color-correction that is available? This
way you can drop the property-id and use the high-level DRM-prop
IDs/names.

2) What is the CRTC-ID for? DRM properties can be set on a specific
CRTC and/or plane. Isn't that enough information for the driver?

3) Please document the payload for each of the properties you define.
If the property is a blob, there is no reason to make the properties
generic. User-space requires a common syntax across all drivers,
otherwise, it cannot make use of generic properties and you should use
driver-dependent properties instead.

4) We have a tuple-type for properties. So in case you only need 32bit
payloads for a given property, you can combine enable/disable and
value in a single 64bit property.

5) Please use common prefixes to group related functions: Use
drm_color_manager_register() instead of drm_register_color_manager().
Similarly, use drm_color_manager_set_property() instead of
drm_set_color_manager_property()..

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Design review request: DRM color manager

[David Herrmann]

Hi

On Tue, Apr 22, 2014 at 12:21 PM, Sharma, Shashank
shashank.sha...@intel.com wrote:
 1) Why do you register only a single property? Why not register a separate 
 property for each color-correction that is available? This way you can drop 
 the property-id and use the high-level DRM-prop IDs/names.
 That’s the whole idea of color manager. If we keep on creating properties 
 for each color correction, there would be a big list and a lot of 
 properties will be exposed. Instead one common blob which can represent all 
 the properties, correction values and identifiers. It would be easy to club 
 with atomic modeset kind-of designs also I believe.

Where is the difference? With one _well-defined_ property for each
type we simply move the identification one level up. With your
approach you just move the type-id one level down into the blob.

Or in other words: Where is the difference between calling
SetProperty() n-times, or calling it once but with a parameter
describing n-properties? With atomic-modesetting we can set as many
properties as we want and make the kernel apply them atomically.

 2) What is the CRTC-ID for? DRM properties can be set on a specific CRTC 
 and/or plane. Isn't that enough information for the driver?
 This is to make it HW agonist. Actually that's CRTC ID / Plane ID / PIPE ID 
 / all together an identifier. For example if I want to set gamma correction 
 for sprite planes only, not on primary plane or pipe level, on VLV, its 
 possible. This gives me flexibility to mention fine-tuned correction even 
 in a CRTC.  The driver's .enable method can take decision on this 
 identifier based on the hardware capabilities.

Yeah, but I meant the drmModeObjectSetProperty() ioctl already tales a
CRTC/Plane/Connector ID. So why duplicate that information in the
blob? And more importantly, what happens if you call
drmModeObjectSetProperty() on a plane but specify a CRTC ID in the
blob? Seems weird to me to support such setups.

 3) Please document the payload for each of the properties you define.
 If the property is a blob, there is no reason to make the properties generic. 
 User-space requires a common syntax across all drivers, otherwise, it cannot 
 make use of generic properties and you should use driver-dependent properties 
 instead.
 Can you please elaborate a bit more ? I believe that a blob is a superset 
 of single and multi-valued properties. So we can use the byte defined for 
 no of correction bytes and specify both single value and multi value 
 correction using the same interface,  method and protocol.  So any 
 userspace can just follow this, any can give commands to any driver.

Well, your document doesn't describe the payload at all. I just wanted
a description of what kind of information is expected. Number of
arguments, argument size, argument types, argument description.. and
so on.

 4) We have a tuple-type for properties. So in case you only need 32bit 
 payloads for a given property, you can combine enable/disable and value in a 
 single 64bit property.
 But properties like CSC and Gamma correction need multiple correction 
 values, up to 256 32-bit values. For this we need more no of values. AM I 
 getting it right ?

Sure.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 1/1] Documentation: drm: describing plane alpha and color blending property

[David Herrmann]

Hi

On Thu, Mar 27, 2014 at 10:50 AM,  sagar.a.kam...@intel.com wrote:
 From: Sagar Kamble sagar.a.kam...@intel.com

 v2: Added description for src-color and constant-alpha property.
 [Review by Laurent Pinchart]

 v3: Fixed typos. [Review by David Herrmann]

 Cc: Rob Landley rob at landley.net
 Cc: Dave Airlie airlied at redhat.com
 Cc: Daniel Vetter daniel.vetter at ffwll.ch
 Cc: Laurent Pinchart laurent.pinchart+renesas at ideasonboard.com
 Cc: David Herrmann dh.herrmann at gmail.com
 Cc: Alex Deucher alexander.deucher at amd.com
 Cc: Ville Syrjälä ville.syrjala at linux.intel.com
 Cc: Sagar Kamble sagar.a.kamble at intel.com
 Cc: Purushothaman, Vijay A vijay.a.purushothaman at intel.com
 Cc: linux-doc at vger.kernel.org
 Cc: dri-devel at lists.freedesktop.org
 Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
 ---
  Documentation/DocBook/drm.tmpl | 23 ++-
  1 file changed, 22 insertions(+), 1 deletion(-)

 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 104402a..66386d0 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2253,6 +2253,14 @@ void intel_crt_init(struct drm_device *dev)
  enumerated bits defined by the property./para/listitem
  /varlistentry
  varlistentry
 +  termDRM_MODE_PROP_32BIT_PAIR/term
 +  listitemparaThis flag restricts all enumerated values of 
 Bitmask properties
 +   to the 0..31 range.
 +'get_property' operation will get combination of instance values 
 of one or more of the
 +enumerated bits defined by the property. With 'set_property' 
 operation, user can specify
 +   {value (MSB 32 bits), type (LSB 32 bits)} pair with 64 bit value 
 for that property./para/listitem

This is a type description, right? I think this is overly complex (and
I actually don't understand it). How about this:

  Pair-properties store two packed 32 bit values as 64bit unsigned
integer (often used as key-value pair). The lower 32bits contain the
first value (also: key), while the upper 32bits contain the second
value. Written as: ({key (LSB 32 bits), value (MSB 32 bits)}).

That should be enough for anyone to understand it. Please note that I
inverted 'type' and 'value' here. It's unnatural to list the value
first.

 +/varlistentry
 +varlistentry
termDRM_MODE_PROP_BLOB/term
listitemparaBlob properties store a binary blob without any 
 format
  restriction. The binary blobs are created as KMS standalone 
 objects,
 @@ -2336,7 +2344,7 @@ void intel_crt_init(struct drm_device *dev)
 /tr
 tr
 td rowspan=19 valign=top DRM/td
 -   td rowspan=2 valign=top Generic/td
 +   td rowspan=3 valign=top Generic/td
 td valign=top EDID/td
 td valign=top BLOB | IMMUTABLE/td
 td valign=top 0/td
 @@ -2351,6 +2359,19 @@ void intel_crt_init(struct drm_device *dev)
 td valign=top Contains DPMS operation mode value./td
 /tr
 tr
 +   td valign=top blend/td
 +   td valign=top BITMASK | 32BIT_PAIR/td

Ugh? This is not a bitmask, is it? It's just a 32BIT_PAIR, right?

 +   td valign=top { {0, zero}, {1, one}, {2, src-color}, {3, 
 one-minus-src-color}
 +   , {4, dst-color}, {5, one-minus-dst-color}, {6, src-alpha}, {7, 
 one-minus-src-alpha}, {8, dst-alpha}
 +   , {9, one-minus-dst-alpha}, {10, constant-color}, {11, 
 one-minus-constant-color}, {12, constant-alpha}
 +   , {13, one-minus-constant-alpha}, {14, alpha-saturate} }/td

 I think brackets are weird to describe enums, a table would be nicer.
People might misread this as 32-bit pairs, which this isn't. If you
want to avoid writing yet another table, how about:

ZERO = 0, ONE = 1, SRC_COLOR = 2, .. and so on?

 +   td valign=top Plane/td
 +   td valign=top Contains plane alpha/color blending operation 
 values. These are modeled after glBlendFunc API

Remove 'API' (or add 'the', like 'the glBlendFunc API').

 +   in OpenGL. Currently only src-color and constant-alpha are 
 supported. parasrc-color will consider supplied fb

This is a driver-dependent statement. I don't think it belongs here.
I'd rather write it as Not all modes are supported by all drivers..

Also, please do line-breaks in front of para. They start
new-paragraphs, so we should do the same in the code (same below).

 +   with plane's pixel format as input without any additional color/alpha 
 changes./paraparaconstant-alpha will apply constant
 +   transparency to all pixels in addition to source color./para/td

I would just drop the description of each of the modes. They're
described in the man-pages of glBlendFunc and everyone knows them (and
they're fairly obvious).

However, this doc doesn't describe the second value at all?
glBlendFunc() takes two of these enums, one for the source, one for
the target. So please add some statement like:

  The first

Re: [Intel-gfx] [PATCH v2 4/4] Documentation: drm: describing plane alpha and color blending property

[David Herrmann]

Hi

On Tue, Mar 25, 2014 at 3:32 PM,  sagar.a.kam...@intel.com wrote:
 From: Sagar Kamble sagar.a.kam...@intel.com

 v2: Added description for src-color and constant-alpha property.

 Cc: Rob Landley rob at landley.net
 Cc: Dave Airlie airlied at redhat.com
 Cc: Daniel Vetter daniel.vetter at ffwll.ch
 Cc: Laurent Pinchart laurent.pinchart+renesas at ideasonboard.com
 Cc: David Herrmann dh.herrmann at gmail.com
 Cc: Alex Deucher alexander.deucher at amd.com
 Cc: Ville Syrjälä ville.syrjala at linux.intel.com
 Cc: Sagar Kamble sagar.a.kamble at intel.com
 Cc: Purushothaman, Vijay A vijay.a.purushothaman at intel.com
 Cc: linux-doc at vger.kernel.org
 Cc: dri-devel at lists.freedesktop.org
 Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
 ---
  Documentation/DocBook/drm.tmpl | 23 ++-
  1 file changed, 22 insertions(+), 1 deletion(-)

 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 104402a..77a45fb 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2253,6 +2253,14 @@ void intel_crt_init(struct drm_device *dev)
  enumerated bits defined by the property./para/listitem
  /varlistentry
  varlistentry
 +  termDRM_MODE_PROP_32BIT_PAIR/term
 +  listitemparaThis flag restricts Bitmask properties restricts 
 all
 +   enumerated values to the 0..31 range.
 +During get operation instance values combine one or more of the
 +enumerated bits defined by the property. During get user can 
 specify
 +   {type, value} pair./para/listitem

Please rewrite that, lots of typos in there. Furthermore, if you use
verbs as nouns, you should emphasize them. So in your text, please
somehow emphasize/quote 'get'.

Thanks
David

 +/varlistentry
 +varlistentry
termDRM_MODE_PROP_BLOB/term
listitemparaBlob properties store a binary blob without any 
 format
  restriction. The binary blobs are created as KMS standalone 
 objects,
 @@ -2336,7 +2344,7 @@ void intel_crt_init(struct drm_device *dev)
 /tr
 tr
 td rowspan=19 valign=top DRM/td
 -   td rowspan=2 valign=top Generic/td
 +   td rowspan=3 valign=top Generic/td
 td valign=top EDID/td
 td valign=top BLOB | IMMUTABLE/td
 td valign=top 0/td
 @@ -2351,6 +2359,19 @@ void intel_crt_init(struct drm_device *dev)
 td valign=top Contains DPMS operation mode value./td
 /tr
 tr
 +   td valign=top blend/td
 +   td valign=top BITMASK | 32BIT_PAIR/td
 +   td valign=top { {0, zero}, {1, one}, {2, src-color}, {3, 
 one-minus-src-color}
 +   , {4, dst-color}, {5, one-minus-dst-color}, {6, src-alpha}, {7, 
 one-minus-src-alpha}, {8, dst-alpha}
 +   , {9, one-minus-dst-alpha}, {10, constant-color}, {11, 
 one-minus-constant-color}, {12, constant-alpha}
 +   , {13, one-minus-constant-alpha}, {14, alpha-saturate} }/td
 +   td valign=top Plane/td
 +   td valign=top Contains plane alpha/color blending operation 
 values. These are modeled after glBlendFunc API
 +   in OpenGL. Currently only src-color and constant-alpha are 
 supported. parasrc-color will consider supplied fb
 +   with plane's pixel format as input without any additional color/alpha 
 changes./paraparaconstant-alpha will apply constant
 +   transparency to all pixels in addition to source color./para/td
 +   /tr
 +   tr
 td rowspan=2 valign=top DVI-I/td
 td valign=top subconnector/td
 td valign=top ENUM/td
 --
 1.8.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Fix use-after-free in the shadow-attache exit code

[David Herrmann]

Hi

On Thu, Jan 30, 2014 at 5:58 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 This regression has been introduced in

 commit b3f2333de8e81b089262b26d52272911523e605f
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Wed Dec 11 11:34:31 2013 +0100

 drm: restrict the device list for shadow attached drivers

 Reported-by: Dave Jones da...@redhat.com
 Cc: Dave Jones da...@redhat.com
 Cc: Dave Airlie airl...@redhat.com
 Cc: David Herrmann dh.herrm...@gmail.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/drm_pci.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
 index 5736aaa7e86c..f7af69bcf3f4 100644
 --- a/drivers/gpu/drm/drm_pci.c
 +++ b/drivers/gpu/drm/drm_pci.c
 @@ -468,8 +468,8 @@ void drm_pci_exit(struct drm_driver *driver, struct 
 pci_driver *pdriver)
 } else {
 list_for_each_entry_safe(dev, tmp, driver-legacy_dev_list,
  legacy_dev_list) {
 -   drm_put_dev(dev);
 list_del(dev-legacy_dev_list);
 +   drm_put_dev(dev);

This code-path is the only user of legacy_dev_list (besides -probe)
and both are locked against each other. So removing the device before
destroying it is fine. So no objections from me:

Reviewed-by: David Herrmann dh.herrm...@gmail.com

Thanks
David

 }
 }
 DRM_INFO(Module unloaded\n);
 --
 1.8.5.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/gem: Always initialize the gem object in object_init

[David Herrmann]

Hi

On Mon, Jan 20, 2014 at 8:21 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 At least drm/i915 expects that the obj-dev pointer is set even in
 failure paths. Specifically when the shmem initialization fails we
 call i915_gem_object_free which needs to deref obj-base.dev to get at
 the slab pointer in the device private structure. And the shmem
 allocation can easily fail when userspace is hitting open file limits.

 Doing the structure init even when the shmem file allocation fails
 prevents this Oops.

Makes the error-paths simpler, and drm_gem_private_object_init()
doesn't allocate anything, so looks good:
Reviewed-by: David Herrmann dh.herrm...@gmail.com

Thanks
David

 Testcase: igt/gem_fd_exhaustion
 Reported-and-Suggested-by: Linus Torvalds torva...@linux-foundation.org
 Cc: Linus Torvalds torva...@linux-foundation.org
 References: 
 http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html
 Cc: sta...@vger.kernel.org
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/drm_gem.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
 index 3ff39bb0402d..31c919903cd0 100644
 --- a/drivers/gpu/drm/drm_gem.c
 +++ b/drivers/gpu/drm/drm_gem.c
 @@ -129,11 +129,12 @@ int drm_gem_object_init(struct drm_device *dev,
  {
 struct file *filp;

 +   drm_gem_private_object_init(dev, obj, size);
 +
 filp = shmem_file_setup(drm mm object, size, VM_NORESERVE);
 if (IS_ERR(filp))
 return PTR_ERR(filp);

 -   drm_gem_private_object_init(dev, obj, size);
 obj-filp = filp;

 return 0;
 --
 1.8.1.4

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm: provide a helper for the encoder possible_crtcs mask

[David Herrmann]

Hi

On Mon, Jan 13, 2014 at 12:46 PM, Thierry Reding
thierry.red...@gmail.com wrote:
 From: Russell King rmk+ker...@arm.linux.org.uk

 The encoder possible_crtcs mask identifies which CRTCs can be bound to
 a particular encoder.  Each bit from bit 0 defines an index in the list
 of CRTCs held in the DRM mode_config crtc_list.  Rather than having
 drivers trying to track the position of their CRTCs in the list, expose
 the code which already exists for calculating the appropriate mask bit
 for a CRTC.

 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 Reviewed-by: David Herrmann dh.herrm...@gmail.com
 [tred...@nvidia.com: add drm_crtc_index(), move to core]
 Signed-off-by: Thierry Reding tred...@nvidia.com
 ---
 Changes in v2:
 - further extract a new drm_crtc_index() function
 - move to DRM core (drm_crtc.c)

  drivers/gpu/drm/drm_crtc.c| 38 ++
  drivers/gpu/drm/drm_crtc_helper.c | 16 +++-
  include/drm/drm_crtc.h|  2 ++
  3 files changed, 43 insertions(+), 13 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 266a01d7f635..fdfa5a0e51d6 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -675,6 +675,44 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
  EXPORT_SYMBOL(drm_crtc_cleanup);

  /**
 + * drm_crtc_index - find the index of a registered CRTC
 + * @crtc: CRTC to find index for
 + *
 + * Given a registered CRTC, return the index of that CRTC within a DRM
 + * device's list of CRTCs. If the CRTC isn't registered, return -1.
 + */
 +int drm_crtc_index(struct drm_crtc *crtc)
 +{
 +   struct drm_crtc *tmp;
 +   int index = 0;
 +
 +   list_for_each_entry(tmp, crtc-dev-mode_config.crtc_list, head) {
 +   if (tmp == crtc)
 +   return index;
 +
 +   index++;
 +   }
 +
 +   return -1;

Does that -1 ever make sense? We don't support mode-object-hotplugging
so all drm_crtc objects are known at initialization time. I'd rather
put a BUG() here than a silent -1. This also makes drm_crtc_mask()
redundant.

Anyhow, still r-b by me.

Thanks
David

 +}
 +EXPORT_SYMBOL(drm_crtc_index);
 +
 +/**
 + * drm_crtc_mask - find the mask of a registered CRTC
 + * @crtc: CRTC to find mask for
 + *
 + * Given a registered CRTC, return the mask bit of that CRTC for an
 + * encoder's possible_crtcs field.
 + */
 +uint32_t drm_crtc_mask(struct drm_crtc *crtc)
 +{
 +   int i = drm_crtc_index(crtc);
 +
 +   return i  0 ? 0 : 1  i;
 +}
 +EXPORT_SYMBOL(drm_crtc_mask);
 +
 +/**
   * drm_mode_probed_add - add a mode to a connector's probed mode list
   * @connector: connector the new mode
   * @mode: mode data
 diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
 b/drivers/gpu/drm/drm_crtc_helper.c
 index 01361aba033b..95b32098badf 100644
 --- a/drivers/gpu/drm/drm_crtc_helper.c
 +++ b/drivers/gpu/drm/drm_crtc_helper.c
 @@ -334,23 +334,13 @@ EXPORT_SYMBOL(drm_helper_disable_unused_functions);
  static bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
 struct drm_crtc *crtc)
  {
 -   struct drm_device *dev;
 -   struct drm_crtc *tmp;
 -   int crtc_mask = 1;
 +   uint32_t crtc_mask;

 WARN(!crtc, checking null crtc?\n);

 -   dev = crtc-dev;
 -
 -   list_for_each_entry(tmp, dev-mode_config.crtc_list, head) {
 -   if (tmp == crtc)
 -   break;
 -   crtc_mask = 1;
 -   }
 +   crtc_mask = drm_crtc_mask(crtc);

 -   if (encoder-possible_crtcs  crtc_mask)
 -   return true;
 -   return false;
 +   return !!(encoder-possible_crtcs  crtc_mask);
  }

  /*
 diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
 index f32c5cd51f41..a61fb73fdcb5 100644
 --- a/include/drm/drm_crtc.h
 +++ b/include/drm/drm_crtc.h
 @@ -929,6 +929,8 @@ extern int drm_crtc_init(struct drm_device *dev,
  struct drm_crtc *crtc,
  const struct drm_crtc_funcs *funcs);
  extern void drm_crtc_cleanup(struct drm_crtc *crtc);
 +extern int drm_crtc_index(struct drm_crtc *crtc);
 +extern uint32_t drm_crtc_mask(struct drm_crtc *crtc);

  extern void drm_connector_ida_init(void);
  extern void drm_connector_ida_destroy(void);
 --
 1.8.4.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm: provide a helper for the encoder possible_crtcs mask

[David Herrmann]

Hi Russel

On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote:
 Does that -1 ever make sense? We don't support mode-object-hotplugging
 so all drm_crtc objects are known at initialization time. I'd rather
 put a BUG() here than a silent -1. This also makes drm_crtc_mask()
 redundant.

 I disagree with that last statement.  drm_crtc_mask() is still useful
 for converting to the mask, rather than having that open coded all
 over the place.  It probably makes more sense for drm_crtc_mask() to
 become a helper in a header file though.

Thierry renamed your helper to drm_crtc_index() and added
drm_crtc_mask(). If we remove the -1, drm_crtc_mask() is redundant as
it just calls drm_crtc_index(). So I cannot follow what you mean by
open coded all over the place. I guess you were talking about
drm_crtc_index()?

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm: provide a helper for the encoder possible_crtcs mask

[David Herrmann]

Hi

On Mon, Jan 13, 2014 at 2:55 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Mon, Jan 13, 2014 at 02:50:46PM +0100, David Herrmann wrote:
 Hi Russel

 On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote:
  Does that -1 ever make sense? We don't support mode-object-hotplugging
  so all drm_crtc objects are known at initialization time. I'd rather
  put a BUG() here than a silent -1. This also makes drm_crtc_mask()
  redundant.
 
  I disagree with that last statement.  drm_crtc_mask() is still useful
  for converting to the mask, rather than having that open coded all
  over the place.  It probably makes more sense for drm_crtc_mask() to
  become a helper in a header file though.

 Thierry renamed your helper to drm_crtc_index() and added
 drm_crtc_mask(). If we remove the -1, drm_crtc_mask() is redundant as
 it just calls drm_crtc_index(). So I cannot follow what you mean by
 open coded all over the place. I guess you were talking about
 drm_crtc_index()?

 +uint32_t drm_crtc_mask(struct drm_crtc *crtc)
 +{
 +   int i = drm_crtc_index(crtc);
 +
 +   return i  0 ? 0 : 1  i;
 +}
 +EXPORT_SYMBOL(drm_crtc_mask);

 When drm_crtc_index() no longer returns negative numbers, this becomes:

 +uint32_t drm_crtc_mask(struct drm_crtc *crtc)
 +{
 +   return 1  drm_crtc_index(crtc);
 +}
 +EXPORT_SYMBOL(drm_crtc_mask);

 Notice the conversion from an index returned by drm_crtc_index() to a
 bitmask.

Oops, missed that, sorry for the noise.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm: Add support for subclassing struct drm_device

[David Herrmann]

Hi

On Thu, Jan 9, 2014 at 1:11 PM, Damien Lespiau damien.lesp...@intel.com wrote:
 On Wed, Jan 08, 2014 at 09:26:51PM +0100, Daniel Vetter wrote:
  So the parent structure is expected to have struct drm_device at
  offset 0? I'd rather like to see a drm_dev_init() alongside
  drm_dev_alloc() similar to device_initialize().

 Yeah, I think for subclassing we want drivers in charge to kmalloc the
 entire thing and embedded struct drm_device wherever they please to do so.
 Adding struct_size stuff all over the place still forces us through the
 midlayer ...

 I'm trying to get there with my giant drm cleanup series (which contains
 some of the same dev_priv_size cleanups like yours). Dunno whether it's
 worth all to much to start embedding before we have that all ready since
 imo the big value in demidlayering is that it allows us to fix up the
 init/teardown sequence. That it also allows struct drm_device embedding is
 kinda neat, but not my main goal.
 -Daniel

 I'm not sure why would people want struct drm_device at a non-0 offset,
 but in any case, if Daniel is already looking into this, let's scrap
 that series. At least we know that it doesn't have to be a long term
 plan and we can do it as soon as we want.

In case you embed multiple objects in your parent device and both have
this requirement, you're screwed. Obviously, this only works if at
most one of them has a ref-count, but see for instance the gem+ttm
combinations, which embed both, gem_object and ttm_bo in their private
bo.

Besides, it's more about clean code here than functionality. The code
doesn't get more complicated if we remove the restriction so lets use
the cleaner way similar to struct device.

Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm: Add support for subclassing struct drm_device

[David Herrmann]

Hi

On Wed, Jan 8, 2014 at 7:31 PM, Damien Lespiau damien.lesp...@intel.com wrote:
 Currently, drivers are expected to allocate private data and attach it
 to dev_private in struct drm_device.

 This has the unfortunate property to require driver code to juggle
 between the pointer to struct drm_device and dev-dev_private instead of
 using the same pointer if they could embed the device structure.

 This patch enables drivers to declare the size of the device structure
 they want DRM core to create for them.

 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  drivers/gpu/drm/drm_stub.c | 8 +++-
  include/drm/drmP.h | 8 
  2 files changed, 15 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
 index 98a33c580..161dd9a 100644
 --- a/drivers/gpu/drm/drm_stub.c
 +++ b/drivers/gpu/drm/drm_stub.c
 @@ -433,8 +433,14 @@ struct drm_device *drm_dev_alloc(struct drm_driver 
 *driver,
  {
 struct drm_device *dev;
 int ret;
 +   size_t device_struct_size;

 -   dev = kzalloc(sizeof(*dev), GFP_KERNEL);
 +   if (driver-device_struct_size)
 +   device_struct_size = driver-device_struct_size;
 +   else
 +   device_struct_size = sizeof(*dev);

How about a:
WARN_ON(driver-device_struct_size  sizeof(*dev))

 +
 +   dev = kzalloc(device_struct_size, GFP_KERNEL);

So the parent structure is expected to have struct drm_device at
offset 0? I'd rather like to see a drm_dev_init() alongside
drm_dev_alloc() similar to device_initialize().

Thanks
David

 if (!dev)
 return NULL;

 diff --git a/include/drm/drmP.h b/include/drm/drmP.h
 index 6800c20..219b153 100644
 --- a/include/drm/drmP.h
 +++ b/include/drm/drmP.h
 @@ -996,6 +996,14 @@ struct drm_driver {
 u32 driver_features;
 /* size of the private data attached to a struct drm_buf */
 int buf_priv_size;
 +   /*
 +* DRM drivers can subclass struct drm_device to have their own device
 +* structure to store private data. In this case, they need to declare
 +* the size of the child structure (ie the structure embedding a 
 struct
 +* drm_device as first field) for the DRM core to allocate a big
 +* enough device structure.
 +*/
 +   size_t device_struct_size;
 const struct drm_ioctl_desc *ioctls;
 int num_ioctls;
 const struct file_operations *fops;
 --
 1.8.3.1

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 46/48] drm: Optionally create mm blocks from top-to-bottom

[David Herrmann]

Hi

On Fri, Dec 6, 2013 at 11:11 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
 From: Chris Wilson ch...@chris-wilson.co.uk

 Clients like i915 needs to segregate cache domains within the GTT which
 can lead to small amounts of fragmentation. By allocating the uncached
 buffers from the bottom and the cacheable buffers from the top, we can
 reduce the amount of wasted space and also optimize allocation of the
 mappable portion of the GTT to only those buffers that require CPU
 access through the GTT.

 v2 by Ben:
 Update callers in i915_gem_object_bind_to_gtt()
 Turn search flags and allocation flags into separate enums
 Make checkpatch happy where logical/easy

 v3 by Ben:
 Rebased on top of the many drm_mm changes since the original patches
 Remove ATOMIC from allocator flags (Chris)
 Reverse order of TOPDOWN and BOTTOMUP

CC'ing dri-devel as I'm not subscribed to intel-gfx.

 Cc: David Herrmann dh.herrm...@gmail.com
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/drm_mm.c| 56 
 +++--
  drivers/gpu/drm/i915/i915_gem.c |  3 +-
  drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
  include/drm/drm_mm.h| 29 ---
  4 files changed, 69 insertions(+), 21 deletions(-)

 diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
 index af93cc5..4f5e4f6 100644
 --- a/drivers/gpu/drm/drm_mm.c
 +++ b/drivers/gpu/drm/drm_mm.c
 @@ -65,7 +65,8 @@ static struct drm_mm_node 
 *drm_mm_search_free_in_range_generic(const struct drm_
  static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
  struct drm_mm_node *node,
  unsigned long size, unsigned alignment,
 -unsigned long color)
 +unsigned long color,
 +enum drm_mm_allocator_flags flags)
  {
 struct drm_mm *mm = hole_node-mm;
 unsigned long hole_start = drm_mm_hole_node_start(hole_node);
 @@ -78,12 +79,22 @@ static void drm_mm_insert_helper(struct drm_mm_node 
 *hole_node,
 if (mm-color_adjust)
 mm-color_adjust(hole_node, color, adj_start, adj_end);

 +   if (flags  DRM_MM_CREATE_TOP)
 +   adj_start = adj_end - size;
 +

That should be above the call to mm-color_adjust(), imo. But I'm not
entirely sure what kind of adjustments drivers do. At least you should
be consistend with the range-helper below where you call it *before*
the color-adjustment.

 if (alignment) {
 unsigned tmp = adj_start % alignment;
 -   if (tmp)
 -   adj_start += alignment - tmp;
 +   if (tmp) {
 +   if (flags  DRM_MM_CREATE_TOP)
 +   adj_start -= tmp;
 +   else
 +   adj_start += alignment - tmp;
 +   }
 }

 +   BUG_ON(adj_start  hole_start);
 +   BUG_ON(adj_end  hole_end);
 +
 if (adj_start == hole_start) {
 hole_node-hole_follows = 0;
 list_del(hole_node-hole_stack);
 @@ -155,16 +166,17 @@ EXPORT_SYMBOL(drm_mm_reserve_node);
  int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
unsigned long size, unsigned alignment,
unsigned long color,
 -  enum drm_mm_search_flags flags)
 +  enum drm_mm_search_flags sflags,
 +  enum drm_mm_allocator_flags aflags)
  {
 struct drm_mm_node *hole_node;

 hole_node = drm_mm_search_free_generic(mm, size, alignment,
 -  color, flags);
 +  color, sflags);
 if (!hole_node)
 return -ENOSPC;

 -   drm_mm_insert_helper(hole_node, node, size, alignment, color);
 +   drm_mm_insert_helper(hole_node, node, size, alignment, color, aflags);
 return 0;
  }
  EXPORT_SYMBOL(drm_mm_insert_node_generic);
 @@ -173,7 +185,8 @@ static void drm_mm_insert_helper_range(struct drm_mm_node 
 *hole_node,
struct drm_mm_node *node,
unsigned long size, unsigned alignment,
unsigned long color,
 -  unsigned long start, unsigned long end)
 +  unsigned long start, unsigned long end,
 +  enum drm_mm_allocator_flags flags)
  {
 struct drm_mm *mm = hole_node-mm;
 unsigned long hole_start = drm_mm_hole_node_start(hole_node);
 @@ -188,13 +201,20 @@ static void drm_mm_insert_helper_range(struct 
 drm_mm_node *hole_node,
 if (adj_end  end

Re: [Intel-gfx] [PATCH 13/19] drm: do not steal the display if we have a master

[David Herrmann]

Hi

On Wed, Nov 27, 2013 at 9:24 PM, Paulo Zanoni przan...@gmail.com wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com

 Sometimes we want to disable all the screens on a system, because that
 will allow the graphics card to be put into low-power states. The
 problem is that, for example, while all screens are disabled, if we
 get a hotplug interrupt, fbcon will decide to set a mode instead of
 keeping everything disabled, which will remove us from our low power
 states.

 Let's assume that if there's a DRM master, it will be able to do
 whatever is appropriate when we get the hotplug.

 This problem can be reproduced by the runtime PM test program from
 intel-gpu-tools: we disable all the screens so the graphics device can
 be put into D3, then something triggers a hotplug interrupt, fbcon
 sets a mode and breaks our test suite. The problem can be reproduced
 more easily by the i2c subtest.

 Other approaches considered for the problem:
 - Return false if bound == 0 and the caller of
   drm_fb_helper_is_bound is a hotplug handler. This would break
   the case where the machine boots with no outputs connected, then
   the user plugs a monitor.
 - Add a new IOCTL to force fbcon to not set modes. This would keep
   all the current applications behaving the same, but adding a new
   IOCTL is not always the greatest idea.
 - Return false only if dev-primary-master  bound == 0. This
   was my first implementation, but Chris suggested we should do
   the check irrespective of the bound variable.

 Thanks to Daniel Vetter for the investigation, ideas and the
 implementation of the hotplug alternative.

 v2: - Do the check first, irrespective of bound.
 - Cc dri-devel

Thank god all that will get dropped with CONFIG_FB=n. Anyhow:

Reviewed-by: David Herrmann dh.herrm...@gmail.com

Thanks
David

 Cc: dri-de...@lists.freedesktop.org
 Credits-to: Daniel Vetter daniel.vet...@ffwll.ch
 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
 ---
  drivers/gpu/drm/drm_fb_helper.c | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
 index 0a19401..98a0363 100644
 --- a/drivers/gpu/drm/drm_fb_helper.c
 +++ b/drivers/gpu/drm/drm_fb_helper.c
 @@ -359,6 +359,11 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper 
 *fb_helper)
 struct drm_crtc *crtc;
 int bound = 0, crtcs_bound = 0;

 +   /* Sometimes user space wants everything disabled, so don't steal the
 +* display if there's a master. */
 +   if (dev-primary-master)
 +   return false;
 +
 list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
 if (crtc-fb)
 crtcs_bound++;
 @@ -368,6 +373,7 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper 
 *fb_helper)

 if (bound  crtcs_bound)
 return false;
 +
 return true;
  }

 --
 1.8.3.1

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm: Remove drm_mode_validate_clocks

[David Herrmann]

Hi

On Wed, Jul 31, 2013 at 2:23 AM, Stéphane Marchesin
marc...@chromium.org wrote:
 Signed-off-by: Stéphane Marchesin marc...@chromium.org

Something like unused in the commit message makes git log
[--oneline] much more verbose without the need to read the patch.
Apart from that:
  Reviewed-by: David Herrmann dh.herrm...@gmail.com

I also did a short grep MODE_CLOCK_RANGE and radeon/i915 tv-helpers
are the last users. All others use MODE_BAD. But I guess
MODE_CLOCK_RANGE is more verbose so there is no need to remove it.

Regards
David

 ---
  drivers/gpu/drm/drm_modes.c | 37 -
  include/drm/drm_crtc.h  |  3 ---
  2 files changed, 40 deletions(-)

 diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
 index a6729bf..504a602 100644
 --- a/drivers/gpu/drm/drm_modes.c
 +++ b/drivers/gpu/drm/drm_modes.c
 @@ -923,43 +923,6 @@ void drm_mode_validate_size(struct drm_device *dev,
  EXPORT_SYMBOL(drm_mode_validate_size);

  /**
 - * drm_mode_validate_clocks - validate modes against clock limits
 - * @dev: DRM device
 - * @mode_list: list of modes to check
 - * @min: minimum clock rate array
 - * @max: maximum clock rate array
 - * @n_ranges: number of clock ranges (size of arrays)
 - *
 - * LOCKING:
 - * Caller must hold a lock protecting @mode_list.
 - *
 - * Some code may need to check a mode list against the clock limits of the
 - * device in question.  This function walks the mode list, testing to make
 - * sure each mode falls within a given range (defined by @min and @max
 - * arrays) and sets @mode-status as needed.
 - */
 -void drm_mode_validate_clocks(struct drm_device *dev,
 - struct list_head *mode_list,
 - int *min, int *max, int n_ranges)
 -{
 -   struct drm_display_mode *mode;
 -   int i;
 -
 -   list_for_each_entry(mode, mode_list, head) {
 -   bool good = false;
 -   for (i = 0; i  n_ranges; i++) {
 -   if (mode-clock = min[i]  mode-clock = max[i]) {
 -   good = true;
 -   break;
 -   }
 -   }
 -   if (!good)
 -   mode-status = MODE_CLOCK_RANGE;
 -   }
 -}
 -EXPORT_SYMBOL(drm_mode_validate_clocks);
 -
 -/**
   * drm_mode_prune_invalid - remove invalid modes from mode list
   * @dev: DRM device
   * @mode_list: list of modes to check
 diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
 index fa12a2f..32e0820 100644
 --- a/include/drm/drm_crtc.h
 +++ b/include/drm/drm_crtc.h
 @@ -930,9 +930,6 @@ extern void drm_mode_list_concat(struct list_head *head,
  extern void drm_mode_validate_size(struct drm_device *dev,
struct list_head *mode_list,
int maxX, int maxY, int maxPitch);
 -extern void drm_mode_validate_clocks(struct drm_device *dev,
 -struct list_head *mode_list,
 -int *min, int *max, int n_ranges);
  extern void drm_mode_prune_invalid(struct drm_device *dev,
struct list_head *mode_list, bool verbose);
  extern void drm_mode_sort(struct list_head *mode_list);
 --
 1.8.3

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] drm: pre allocate node for create_block

[David Herrmann]

Hi

On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky b...@bwidawsk.net wrote:
 For an upcoming patch where we introduce the i915 VMA, it's ideal to
 have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
 Part of the conversion to VMAs is to kill off obj-gtt_space. Doing this
 will break a bunch of code, but amongst them are 2 callers of
 drm_mm_create_block(), both related to stolen memory.

 It also allows us to embed the drm_mm_node into the object currently
 which provides a nice transition over to the new code.

 v2: Reordered to do before ripping out obj-gtt_offset.
 Some minor cleanups made available because of reordering.

 CC: dri-de...@lists.freedesktop.org
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/drm_mm.c   | 16 +--
  drivers/gpu/drm/i915/i915_gem_gtt.c| 18 +
  drivers/gpu/drm/i915/i915_gem_stolen.c | 36 
 +++---
  include/drm/drm_mm.h   |  9 +
  4 files changed, 49 insertions(+), 30 deletions(-)

 diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
 index 07cf99c..9e8dfbc 100644
 --- a/drivers/gpu/drm/drm_mm.c
 +++ b/drivers/gpu/drm/drm_mm.c
 @@ -147,12 +147,10 @@ static void drm_mm_insert_helper(struct drm_mm_node 
 *hole_node,
 }
  }

 -struct drm_mm_node *drm_mm_create_block(struct drm_mm *mm,
 -   unsigned long start,
 -   unsigned long size,
 -   bool atomic)
 +int drm_mm_create_block(struct drm_mm *mm, struct drm_mm_node *node,
 +   unsigned long start, unsigned long size)
  {
 -   struct drm_mm_node *hole, *node;
 +   struct drm_mm_node *hole;
 unsigned long end = start + size;
 unsigned long hole_start;
 unsigned long hole_end;
 @@ -161,10 +159,6 @@ struct drm_mm_node *drm_mm_create_block(struct drm_mm 
 *mm,
 if (hole_start  start || hole_end  end)
 continue;

 -   node = drm_mm_kmalloc(mm, atomic);
 -   if (unlikely(node == NULL))
 -   return NULL;
 -
 node-start = start;
 node-size = size;
 node-mm = mm;
 @@ -184,11 +178,11 @@ struct drm_mm_node *drm_mm_create_block(struct drm_mm 
 *mm,
 node-hole_follows = 1;
 }

 -   return node;
 +   return 0;
 }

 WARN(1, no hole found for block 0x%lx + 0x%lx\n, start, size);
 -   return NULL;
 +   return -ENOSPC;
  }
  EXPORT_SYMBOL(drm_mm_create_block);

 diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
 b/drivers/gpu/drm/i915/i915_gem_gtt.c
 index 66929ea..5c6fc0e 100644
 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
 +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
 @@ -629,14 +629,24 @@ void i915_gem_setup_global_gtt(struct drm_device *dev,

 /* Mark any preallocated objects as occupied */
 list_for_each_entry(obj, dev_priv-mm.bound_list, global_list) {
 +   int ret;
 DRM_DEBUG_KMS(reserving preallocated space: %x + %zx\n,
   obj-gtt_offset, obj-base.size);

 BUG_ON(obj-gtt_space != I915_GTT_RESERVED);
 -   obj-gtt_space = drm_mm_create_block(dev_priv-mm.gtt_space,
 -obj-gtt_offset,
 -obj-base.size,
 -false);
 +   obj-gtt_space = kzalloc(sizeof(*obj-gtt_space), GFP_KERNEL);
 +   if (!obj-gtt_space) {
 +   DRM_ERROR(Failed to preserve all objects\n);
 +   break;
 +   }
 +   ret = drm_mm_create_block(dev_priv-mm.gtt_space,
 + obj-gtt_space,
 + obj-gtt_offset,
 + obj-base.size);
 +   if (ret) {
 +   DRM_DEBUG_KMS(Reservation failed\n);
 +   kfree(obj-gtt_space);

Are you sure you don't need:
  obj-gtt_space = NULL;
here?
I am no expert in i915 gem handling, but looking at i915_gem.c I think
you might run into bugs if not.

Also, why did you add the break; above, but not here? I am confused.

 +   }
 obj-has_global_gtt_mapping = 1;
 }

 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 8e02344..f9db84a 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -330,6 +330,7 @@ i915_gem_object_create_stolen_for_preallocated(struct 
 drm_device *dev,
 struct drm_i915_private *dev_priv = dev-dev_private;
 struct drm_i915_gem_object *obj;
 struct drm_mm_node *stolen;
 

Re: [Intel-gfx] [PATCH 1/6] drm: pre allocate node for create_block

[David Herrmann]

Hi

On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky b...@bwidawsk.net wrote:
 For an upcoming patch where we introduce the i915 VMA, it's ideal to
 have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
 Part of the conversion to VMAs is to kill off obj-gtt_space. Doing this
 will break a bunch of code, but amongst them are 2 callers of
 drm_mm_create_block(), both related to stolen memory.

 It also allows us to embed the drm_mm_node into the object currently
 which provides a nice transition over to the new code.

 v2: Reordered to do before ripping out obj-gtt_offset.
 Some minor cleanups made available because of reordering.

 CC: dri-de...@lists.freedesktop.org
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/drm_mm.c   | 16 +--
  drivers/gpu/drm/i915/i915_gem_gtt.c| 18 +
  drivers/gpu/drm/i915/i915_gem_stolen.c | 36 
 +++---
  include/drm/drm_mm.h   |  9 +
  4 files changed, 49 insertions(+), 30 deletions(-)

 diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
 index 07cf99c..9e8dfbc 100644
 --- a/drivers/gpu/drm/drm_mm.c
 +++ b/drivers/gpu/drm/drm_mm.c
 @@ -147,12 +147,10 @@ static void drm_mm_insert_helper(struct drm_mm_node 
 *hole_node,
 }
  }

 -struct drm_mm_node *drm_mm_create_block(struct drm_mm *mm,
 -   unsigned long start,
 -   unsigned long size,
 -   bool atomic)
 +int drm_mm_create_block(struct drm_mm *mm, struct drm_mm_node *node,
 +   unsigned long start, unsigned long size)
  {
 -   struct drm_mm_node *hole, *node;
 +   struct drm_mm_node *hole;
 unsigned long end = start + size;
 unsigned long hole_start;
 unsigned long hole_end;
 @@ -161,10 +159,6 @@ struct drm_mm_node *drm_mm_create_block(struct drm_mm 
 *mm,
 if (hole_start  start || hole_end  end)
 continue;

 -   node = drm_mm_kmalloc(mm, atomic);
 -   if (unlikely(node == NULL))
 -   return NULL;
 -
 node-start = start;
 node-size = size;
 node-mm = mm;
 @@ -184,11 +178,11 @@ struct drm_mm_node *drm_mm_create_block(struct drm_mm 
 *mm,
 node-hole_follows = 1;
 }

 -   return node;
 +   return 0;
 }

 WARN(1, no hole found for block 0x%lx + 0x%lx\n, start, size);
 -   return NULL;
 +   return -ENOSPC;
  }
  EXPORT_SYMBOL(drm_mm_create_block);

 diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
 b/drivers/gpu/drm/i915/i915_gem_gtt.c
 index 66929ea..5c6fc0e 100644
 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
 +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
 @@ -629,14 +629,24 @@ void i915_gem_setup_global_gtt(struct drm_device *dev,

 /* Mark any preallocated objects as occupied */
 list_for_each_entry(obj, dev_priv-mm.bound_list, global_list) {
 +   int ret;
 DRM_DEBUG_KMS(reserving preallocated space: %x + %zx\n,
   obj-gtt_offset, obj-base.size);

 BUG_ON(obj-gtt_space != I915_GTT_RESERVED);
 -   obj-gtt_space = drm_mm_create_block(dev_priv-mm.gtt_space,
 -obj-gtt_offset,
 -obj-base.size,
 -false);
 +   obj-gtt_space = kzalloc(sizeof(*obj-gtt_space), GFP_KERNEL);
 +   if (!obj-gtt_space) {
 +   DRM_ERROR(Failed to preserve all objects\n);
 +   break;
 +   }
 +   ret = drm_mm_create_block(dev_priv-mm.gtt_space,
 + obj-gtt_space,
 + obj-gtt_offset,
 + obj-base.size);
 +   if (ret) {
 +   DRM_DEBUG_KMS(Reservation failed\n);
 +   kfree(obj-gtt_space);
 +   }
 obj-has_global_gtt_mapping = 1;
 }

 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 8e02344..f9db84a 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -330,6 +330,7 @@ i915_gem_object_create_stolen_for_preallocated(struct 
 drm_device *dev,
 struct drm_i915_private *dev_priv = dev-dev_private;
 struct drm_i915_gem_object *obj;
 struct drm_mm_node *stolen;
 +   int ret;

 if (dev_priv-mm.stolen_base == 0)
 return NULL;
 @@ -344,11 +345,15 @@ i915_gem_object_create_stolen_for_preallocated(struct 
 drm_device *dev,
 if (WARN_ON(size == 0))
   

Re: [Intel-gfx] [PATCH] [v3] drm: pre allocate node for create_block

[David Herrmann]

Hi

On Thu, Jul 4, 2013 at 10:14 PM, Ben Widawsky b...@bwidawsk.net wrote:
 For an upcoming patch where we introduce the i915 VMA, it's ideal to
 have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
 Part of the conversion to VMAs is to kill off obj-gtt_space. Doing this
 will break a bunch of code, but amongst them are 2 callers of
 drm_mm_create_block(), both related to stolen memory.

 It also allows us to embed the drm_mm_node into the object currently
 which provides a nice transition over to the new code.

 v2: Reordered to do before ripping out obj-gtt_offset.
 Some minor cleanups made available because of reordering.

 v3: s/continue/break on failed stolen node allocation (David)
 Set obj-gtt_space on failed node allocation (David)
 Only unref stolen (fix double free) on failed create_stolen (David)
 Free node, and NULL it in failed create_stolen (David)
 Add back accidentally removed newline (David)

 CC: dri-de...@lists.freedesktop.org
 CC: David Herrmann dh.herrm...@gmail.com
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

I already suspected that you'd embed drm_mm_node in a follow-up patch
but I am not subscribed to intel-gfx so I didn't get the other
patches. Looks good now.

Reviewed-by: David Herrmann dh.herrm...@gmail.com

Cheers
David

 ---
  drivers/gpu/drm/drm_mm.c   | 16 +--
  drivers/gpu/drm/i915/i915_gem_gtt.c| 20 ++
  drivers/gpu/drm/i915/i915_gem_stolen.c | 37 
 +-
  include/drm/drm_mm.h   |  9 +
  4 files changed, 53 insertions(+), 29 deletions(-)

 diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
 index 07cf99c..9e8dfbc 100644
 --- a/drivers/gpu/drm/drm_mm.c
 +++ b/drivers/gpu/drm/drm_mm.c
 @@ -147,12 +147,10 @@ static void drm_mm_insert_helper(struct drm_mm_node 
 *hole_node,
 }
  }

 -struct drm_mm_node *drm_mm_create_block(struct drm_mm *mm,
 -   unsigned long start,
 -   unsigned long size,
 -   bool atomic)
 +int drm_mm_create_block(struct drm_mm *mm, struct drm_mm_node *node,
 +   unsigned long start, unsigned long size)
  {
 -   struct drm_mm_node *hole, *node;
 +   struct drm_mm_node *hole;
 unsigned long end = start + size;
 unsigned long hole_start;
 unsigned long hole_end;
 @@ -161,10 +159,6 @@ struct drm_mm_node *drm_mm_create_block(struct drm_mm 
 *mm,
 if (hole_start  start || hole_end  end)
 continue;

 -   node = drm_mm_kmalloc(mm, atomic);
 -   if (unlikely(node == NULL))
 -   return NULL;
 -
 node-start = start;
 node-size = size;
 node-mm = mm;
 @@ -184,11 +178,11 @@ struct drm_mm_node *drm_mm_create_block(struct drm_mm 
 *mm,
 node-hole_follows = 1;
 }

 -   return node;
 +   return 0;
 }

 WARN(1, no hole found for block 0x%lx + 0x%lx\n, start, size);
 -   return NULL;
 +   return -ENOSPC;
  }
  EXPORT_SYMBOL(drm_mm_create_block);

 diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
 b/drivers/gpu/drm/i915/i915_gem_gtt.c
 index 66929ea..88180a5 100644
 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
 +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
 @@ -629,14 +629,26 @@ void i915_gem_setup_global_gtt(struct drm_device *dev,

 /* Mark any preallocated objects as occupied */
 list_for_each_entry(obj, dev_priv-mm.bound_list, global_list) {
 +   int ret;
 DRM_DEBUG_KMS(reserving preallocated space: %x + %zx\n,
   obj-gtt_offset, obj-base.size);

 BUG_ON(obj-gtt_space != I915_GTT_RESERVED);
 -   obj-gtt_space = drm_mm_create_block(dev_priv-mm.gtt_space,
 -obj-gtt_offset,
 -obj-base.size,
 -false);
 +   obj-gtt_space = kzalloc(sizeof(*obj-gtt_space), GFP_KERNEL);
 +   if (!obj-gtt_space) {
 +   DRM_ERROR(Failed to preserve object at offset %x\n,
 + obj-gtt_offset);
 +   continue;
 +   }
 +   ret = drm_mm_create_block(dev_priv-mm.gtt_space,
 + obj-gtt_space,
 + obj-gtt_offset,
 + obj-base.size);
 +   if (ret) {
 +   DRM_DEBUG_KMS(Reservation failed\n);
 +   kfree(obj-gtt_space);
 +   obj-gtt_space = NULL;
 +   }
 obj-has_global_gtt_mapping = 1;
 }

 diff --git a/drivers

Re: [Intel-gfx] [PATCH 2/2] drm/i915: use drm_mm_remove_node instead of put_block

[David Herrmann]

Hi

On Mon, Jul 1, 2013 at 10:05 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 When converting to the preallocated drm_mm_node interfaces in

 commit dc9dd7a20fde95aa81a8307cde79c2dff9f83f3d
 Author: Chris Wilson ch...@chris-wilson.co.uk
 Date:   Fri Dec 7 20:37:07 2012 +

 drm/i915: Preallocate the drm_mm_node prior to manipulating the GTT drm_mm

 only the allocation side was converted, but not the freeing. Fix this
 up.

 Note that the only difference between put_block and remove_node is
 that the former fills up the preallocation cache. Which we don't need
 anyway and hence is just wasted space.

 Cc: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Ben Widawsky b...@bwidawsk.net
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/i915_gem.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 4200c32..30fd694 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -2620,7 +2620,7 @@ i915_gem_object_unbind(struct drm_i915_gem_object *obj)
 /* Avoid an unnecessary call to unbind on rebind. */
 obj-map_and_fenceable = true;

 -   drm_mm_put_block(obj-gtt_space);
 +   drm_mm_remove_node(obj-gtt_space);

kfree(obj-gtt_space);

 obj-gtt_space = NULL;
 obj-gtt_offset = 0;

 @@ -3137,14 +3137,14 @@ search_free:
 }
 if (WARN_ON(!i915_gem_valid_gtt_space(dev, node, obj-cache_level))) {
 i915_gem_object_unpin_pages(obj);
 -   drm_mm_put_block(node);
 +   drm_mm_remove_node(node);

kfree(node);

 return -EINVAL;
 }

 ret = i915_gem_gtt_prepare_object(obj);
 if (ret) {
 i915_gem_object_unpin_pages(obj);
 -   drm_mm_put_block(node);
 +   drm_mm_remove_node(node);

kfree(node);

drm_mm_remove_node() does unlink the node but not remove it. Btw., I
have these fixes in my series, too. I will push it later and write the
git-link to #dri-devel.

Cheers
David

 return ret;
 }

 --
 1.7.11.7

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/3] fbdev no more!

[David Herrmann]

Hi

On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 Hi all,

 So I've taken a look again at the locking mess in our fbdev support and cried.
 Fixing up the console_lock mess around the fbdev notifier will be real work,
 semanatically the fbdev layer does lots of stupid things (like the radeon 
 resume
 issue I've just debugged) and the panic notifier is pretty much a lost cause.

Hint: Take a look at fbdev ref-counting or sysfs integration. Totally
broken, too. I sometimes really wonder how that still works.

 So I've decided to instead rip it all out. It seems to work \o/

Yep, works for me pretty well, too.

 Of course a general purpose distro propably wants David's kmscon for any
 fallbacks needs and a system compositor to ditch the VT subsystem - atm my
 machine here runs with the dummy console so that VT switching between 
 different
 X sessions still works ;-)

I used CONFIG_VT=n for quite a while with user-space VTs as
replacement. But what we really need is a system-compositor (even if
it's not really a compositor). But for that we need dynamic modeset
nodes or we end up with the same problems as with VTs. It's on my TODO
list after render/modeset nodes are done. With user-space VTs this is
even backwards-compatible.

 Oh and: At least fedora's boot splash seems to be unhappy about the lack of an
 fbdev (it doesn't seem to do anything), which breaks early disk encryption a
 bit. The black screen itself shouldn't be a big issue at least for i915, since
 with all the fastboot work we can just hang onto the current config and
 framebuffer (one missing patch from Chris for the fb preservartion). So as 
 long
 as the bios/grub put up something nice, it'll look ok.

Plymouth should work just fine with KMS (afaik it was even airlied who
wrote the backends). It doesn't support GPU hotplugging, though. So
it's probably started before i915 is loaded and so doesn't pick up the
DRM device. Or with initrd user-space is started early without waiting
for device-initialization to finish. So even with i915 built-in it may
run before card0 shows up. The journal-log should probably help
debugging this.

Btw., It has /dev/dri/card0 hard-coded and only tries opening it once
during startup.

 So just a small step here really, but imo into the right direction. Now, 
 please
 bring on the flames!

Please, apply it! Now!

Thanks
David

 Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd
 like to wait for a bit of feedback first. And one more: This also removes the
 console_lock completely from our critical path in suspend/resume!

 One thing I haven't wasted a single thought about is kgdb and panic notifier
 support. But since the current code is pretty decently broken already (we have
 _tons_ of mutex grabbing and waits in there) I don't think people care that 
 much
 about it anyway. Using a sprite to smash the kgdb/panic output on top of
 whatever's currently displaying might be an approach.

 Cheers, Daniel

 Daniel Vetter (3):
   drm: Add separate Kconfig option for fbdev helpers
   drm/i915: Kconfig option to disable the legacy fbdev support
   drm/i915: rename intel_fb.c to intel_fbdev.c

  drivers/gpu/drm/Kconfig  |  57 ++-
  drivers/gpu/drm/Makefile |   3 +-
  drivers/gpu/drm/ast/Kconfig  |   1 +
  drivers/gpu/drm/cirrus/Kconfig   |   1 +
  drivers/gpu/drm/exynos/Kconfig   |   1 +
  drivers/gpu/drm/gma500/Kconfig   |   1 +
  drivers/gpu/drm/i915/Kconfig |  56 +++
  drivers/gpu/drm/i915/Makefile|   3 +-
  drivers/gpu/drm/i915/i915_debugfs.c  |   4 +-
  drivers/gpu/drm/i915/i915_dma.c  |   8 +-
  drivers/gpu/drm/i915/i915_drv.h  |   2 +
  drivers/gpu/drm/i915/intel_display.c |  12 +-
  drivers/gpu/drm/i915/intel_drv.h |  39 -
  drivers/gpu/drm/i915/intel_fb.c  | 314 
 ---
  drivers/gpu/drm/i915/intel_fbdev.c   | 314 
 +++
  drivers/gpu/drm/mgag200/Kconfig  |   1 +
  drivers/gpu/drm/nouveau/Kconfig  |   1 +
  drivers/gpu/drm/omapdrm/Kconfig  |   1 +
  drivers/gpu/drm/qxl/Kconfig  |   1 +
  drivers/gpu/drm/shmobile/Kconfig |   1 +
  drivers/gpu/drm/tilcdc/Kconfig   |   1 +
  drivers/gpu/drm/udl/Kconfig  |   1 +
  drivers/gpu/host1x/drm/Kconfig   |   1 +
  drivers/staging/imx-drm/Kconfig  |   1 +
  24 files changed, 452 insertions(+), 373 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/Kconfig
  delete mode 100644 drivers/gpu/drm/i915/intel_fb.c
  create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c

 --
 1.7.11.7

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/3] fbdev no more!

[David Herrmann]

Hi

On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski l...@amacapital.net wrote:
 On 06/16/2013 07:57 AM, Daniel Vetter wrote:
 Hi all,

 So I've taken a look again at the locking mess in our fbdev support and 
 cried.
 Fixing up the console_lock mess around the fbdev notifier will be real work,
 semanatically the fbdev layer does lots of stupid things (like the radeon 
 resume
 issue I've just debugged) and the panic notifier is pretty much a lost cause.

 So I've decided to instead rip it all out. It seems to work \o/

 I wonder how badly this breaks on EFI systems.  Currently, efifb is an
 fbdev driver.  When i915 calls register_framebuffer, the fbdev core
 removes efifb's framebuffer.  (This is scary already -- what if i915 has
 reused that memory for something else beforehand?)  But now, if i915
 doesn't call register_framebuffer, the efifb framebuffer might stick
 around forever.

See the i915 Patch (2/3). It still calls
remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will
kick out efifb regardless whether i915-fbdev support is enabled or
not.

 Presumably, efifb ought to become a framebuffer-only drm driver and
 there should be a saner way to hand control from efifb (or vesa?) to a
 real driver.

Already working on it.

Regards
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx