Re: [Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation

[Daniel Vetter]

On Mon, Apr 16, 2018 at 08:49:23PM +0200, Noralf Trønnes wrote:
> 
> Den 16.04.2018 10.21, skrev Daniel Vetter:
> > On Sat, Apr 14, 2018 at 01:52:53PM +0200, Noralf Trønnes wrote:
> > > This patchset explores the possibility of having generic fbdev emulation
> > > in DRM for drivers that supports dumb buffers which they can export. An
> > > API is added to support in-kernel clients in general.
> > > 
> > > In this version I was able to reuse the modesetting code from
> > > drm_fb_helper in the client API. This avoids code duplication, carries
> > > over lessons learned and the modesetting code is bisectable. The
> > > downside is that it takes +10 patches to rip drm_fb_helper in two, so
> > > maybe it's not worth it wrt possible breakage and a challenging review.
> > So my idea wasn't to rip the fbdev helper in  half first (that's indeed a
> > lot of work). But start out right away with using every piece of the
> > drm_client infrastructure you're adding in the existing fbdev code.
> > 
> > That way there's not a huge patch series which just adds code, with no
> > users, but every step of the way and every addition is tested almost right
> > away. That makes more gradual merging also easier. The things I have in
> > mind here is the generic fb_probe, or the drm_client block/unblock masters
> > and all that stuff.
> > 
> > Then, once we've demonstrated all these auxiliary pieces necessary for
> > drm_client.c work, we can cut the fb-helper in half and move the modeset
> > code into the drm_client library.
> 
> I agree. I wished for a way to cut this patchset in half, but I just
> couldn't see how. I was tired of working on this, so I just put it out
> hoping that you would provide some clarity. Which you did, thanks :-)

Yeah, that's why I'm also ok with things as-is. I think we've reached
agreement on the design and big picture now, which really is the important
part. How exactly we get there (as long as it's gradual steps in
bisectable patches) doesn't matter that much really.

> So, I think I'll strip this down to just the buffer part of the client API
> and use that in the generic fbdev emulation, and start converting some
> drivers.

Yes the buffer stuff is definitely the core parts. I think rolling out the
master_block/unblock stuff after that would be really neat too, since it
would fix a long-standing race in our fbdev emulation.

> I'll pick up the rest of the client API when I'm done with moving tinydrm
> over to vmalloc buffers and have added support for device unplug.

Sounds like a good plan.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation

[Noralf Trønnes]

Den 16.04.2018 10.21, skrev Daniel Vetter:

On Sat, Apr 14, 2018 at 01:52:53PM +0200, Noralf Trønnes wrote:

This patchset explores the possibility of having generic fbdev emulation
in DRM for drivers that supports dumb buffers which they can export. An
API is added to support in-kernel clients in general.

In this version I was able to reuse the modesetting code from
drm_fb_helper in the client API. This avoids code duplication, carries
over lessons learned and the modesetting code is bisectable. The
downside is that it takes +10 patches to rip drm_fb_helper in two, so
maybe it's not worth it wrt possible breakage and a challenging review.

So my idea wasn't to rip the fbdev helper in  half first (that's indeed a
lot of work). But start out right away with using every piece of the
drm_client infrastructure you're adding in the existing fbdev code.

That way there's not a huge patch series which just adds code, with no
users, but every step of the way and every addition is tested almost right
away. That makes more gradual merging also easier. The things I have in
mind here is the generic fb_probe, or the drm_client block/unblock masters
and all that stuff.

Then, once we've demonstrated all these auxiliary pieces necessary for
drm_client.c work, we can cut the fb-helper in half and move the modeset
code into the drm_client library.


I agree. I wished for a way to cut this patchset in half, but I just
couldn't see how. I was tired of working on this, so I just put it out
hoping that you would provide some clarity. Which you did, thanks :-)

So, I think I'll strip this down to just the buffer part of the client API
and use that in the generic fbdev emulation, and start converting some
drivers.

I'll pick up the rest of the client API when I'm done with moving tinydrm
over to vmalloc buffers and have added support for device unplug.

Noralf.



I still prefer an even more gradual path like this compared to what you
have in your patch series, but I understand that's yet another huge
shuffle. And the current series seems like a good enough approach to get
to essentially the same place.


Does the Intel CI test the fbdev emulation?

We have fbdev emulation enabled, and iirc there's even a few tests for
fbdev. Just booting it on 20+ machines is a lot of testing itsefl already.


Daniel had this concern with the previous version:

 The register/unregister model needs more thought. Allowing both clients
 to register whenever they want to, and drm_device instances to come and
 go is what fbcon has done, and the resulting locking is a horror show.

 I think if we require that all in-kernel drm_clients are registers when
 loading drm.ko (and enabled/disabled only per module options and
 Kconfig), then we can throw out all the locking. That avoids a lot of
 the headaches.

I have solved this by adding a notifier that fires when a new DRM device
is registered (I've removed the new() callback). Currently only
bootsplash uses this. The fbdev client needs to be setup from the driver
since it can't know on device registration if the driver will setup it's
own fbdev emulation later and the vtcon client hooks up to a user
provided device id.

Ugh, notifier is exactly what fbcon also uses. It just hides the locking
horror show slightly, but it's equally bad. I'm working on a multi-year
plan to rip out the fbcon notifier, please don't start another one. See

commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter 
Date:   Tue Aug 1 17:32:07 2017 +0200

 fbcon: Make fbcon a built-time depency for fbdev

for full details.


Since fbcon can't handle fb_open failing, the buffer has to be
pre-allocated. Exporting a GEM buffer pins the driver module making it
impossible to unload it.
I have included 2 solutions to the problem:
- sysfs file to remove/close clients: remove_internal_clients

This is the same thing that defacto happens already with fbcon: You have
to remove fbcon first (which holds a full ref on the fbdev, which prevents
the drm driver from unloading). I think explicitly asking for that
reference to disappear is ok.

It does mean everyone has to update their unload scripts, but oh well.


- Change drm_gem_prime_export() so it doesn't pin on client buffers

The double-loop in that patch definitely doesn't cut it, but worst case I
think something like that could be made to work.


If a dumb buffer is exported from a kernel thread (worker) context, the
file descriptor isn't closed and I leak a reference so the buffer isn't
freed. Please look at drm_client_buffer_create() in patch
'drm/client: Finish the in-kernel client API'.
This is a blocker that needs a solution.

Hm, missed that in my first cursory read of the series, I'l take another
look.
-Daniel



Noralf.

Changes since version 3:
Client API changes:
- Drop drm_client_register_funcs() which attached clients indirectly.
   Let clients attach directly using drm_client_new{_from_id}(). Clients
   

Re: [Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation

[Daniel Vetter]

On Sat, Apr 14, 2018 at 01:52:53PM +0200, Noralf Trønnes wrote:
> This patchset explores the possibility of having generic fbdev emulation
> in DRM for drivers that supports dumb buffers which they can export. An
> API is added to support in-kernel clients in general.
> 
> In this version I was able to reuse the modesetting code from
> drm_fb_helper in the client API. This avoids code duplication, carries
> over lessons learned and the modesetting code is bisectable. The
> downside is that it takes +10 patches to rip drm_fb_helper in two, so
> maybe it's not worth it wrt possible breakage and a challenging review.

So my idea wasn't to rip the fbdev helper in  half first (that's indeed a
lot of work). But start out right away with using every piece of the
drm_client infrastructure you're adding in the existing fbdev code.

That way there's not a huge patch series which just adds code, with no
users, but every step of the way and every addition is tested almost right
away. That makes more gradual merging also easier. The things I have in
mind here is the generic fb_probe, or the drm_client block/unblock masters
and all that stuff.

Then, once we've demonstrated all these auxiliary pieces necessary for
drm_client.c work, we can cut the fb-helper in half and move the modeset
code into the drm_client library.

I still prefer an even more gradual path like this compared to what you
have in your patch series, but I understand that's yet another huge
shuffle. And the current series seems like a good enough approach to get
to essentially the same place.

> Does the Intel CI test the fbdev emulation?

We have fbdev emulation enabled, and iirc there's even a few tests for
fbdev. Just booting it on 20+ machines is a lot of testing itsefl already.

> 
> Daniel had this concern with the previous version:
> 
> The register/unregister model needs more thought. Allowing both clients
> to register whenever they want to, and drm_device instances to come and
> go is what fbcon has done, and the resulting locking is a horror show.
> 
> I think if we require that all in-kernel drm_clients are registers when
> loading drm.ko (and enabled/disabled only per module options and
> Kconfig), then we can throw out all the locking. That avoids a lot of
> the headaches.
> 
> I have solved this by adding a notifier that fires when a new DRM device
> is registered (I've removed the new() callback). Currently only
> bootsplash uses this. The fbdev client needs to be setup from the driver
> since it can't know on device registration if the driver will setup it's
> own fbdev emulation later and the vtcon client hooks up to a user
> provided device id.

Ugh, notifier is exactly what fbcon also uses. It just hides the locking
horror show slightly, but it's equally bad. I'm working on a multi-year
plan to rip out the fbcon notifier, please don't start another one. See

commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter 
Date:   Tue Aug 1 17:32:07 2017 +0200

fbcon: Make fbcon a built-time depency for fbdev

for full details.

> Since fbcon can't handle fb_open failing, the buffer has to be
> pre-allocated. Exporting a GEM buffer pins the driver module making it
> impossible to unload it.
> I have included 2 solutions to the problem:
> - sysfs file to remove/close clients: remove_internal_clients

This is the same thing that defacto happens already with fbcon: You have
to remove fbcon first (which holds a full ref on the fbdev, which prevents
the drm driver from unloading). I think explicitly asking for that
reference to disappear is ok.

It does mean everyone has to update their unload scripts, but oh well.

> - Change drm_gem_prime_export() so it doesn't pin on client buffers

The double-loop in that patch definitely doesn't cut it, but worst case I
think something like that could be made to work.

> If a dumb buffer is exported from a kernel thread (worker) context, the
> file descriptor isn't closed and I leak a reference so the buffer isn't
> freed. Please look at drm_client_buffer_create() in patch
> 'drm/client: Finish the in-kernel client API'.
> This is a blocker that needs a solution.

Hm, missed that in my first cursory read of the series, I'l take another
look.
-Daniel

> 
> 
> Noralf.
> 
> Changes since version 3:
> Client API changes:
> - Drop drm_client_register_funcs() which attached clients indirectly.
>   Let clients attach directly using drm_client_new{_from_id}(). Clients
>   that wants to attach to all devices must be linked into drm.ko and use
>   the DRM device notifier. This is done to avoid the lock/race
>   register/unregister hell we have with fbcon. (Daniel Vetter)
> - drm_client_display_restore() checks if there is a master and if so
>   returns -EBUSY. (Daniel Vetter)
> - Allocate drm_file up front instead of on-demand. Since fbdev can't do
>   on demand buffer allocation because of fbcon, there's no need for this.
> - Add sysfs file to 

Re: [Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation

[Daniel Vetter]

On Thu, Apr 12, 2018 at 06:34:46PM +0200, Noralf Trønnes wrote:
> I hit a 'Sending rate exceeded' error with this patchset, so it didn't go
> out as it should.
> I will resend the patchset when I find out how to avoid this problem.

That's generally an issue with your ISP. gmail works ime for mail bombs,
even big ones.
-Daniel

> 
> Noralf.
> 
> 
> Den 12.04.2018 15.17, skrev Noralf Trønnes:
> > This patchset explores the possibility of having generic fbdev emulation
> > in DRM for drivers that supports dumb buffers which they can export. An
> > API is added to support in-kernel clients in general.
> > 
> > In this version I was able to reuse the modesetting code from
> > drm_fb_helper in the client API. This avoids code duplication, carries
> > over lessons learned and the modesetting code is bisectable. The
> > downside is that it takes +10 patches to rip drm_fb_helper in two, so
> > maybe it's not worth it wrt possible breakage and a challenging review.
> > 
> > Does the Intel CI test the fbdev emulation?
> > 
> > Daniel had this concern with the previous version:
> > 
> >  The register/unregister model needs more thought. Allowing both clients
> >  to register whenever they want to, and drm_device instances to come and
> >  go is what fbcon has done, and the resulting locking is a horror show.
> > 
> >  I think if we require that all in-kernel drm_clients are registers when
> >  loading drm.ko (and enabled/disabled only per module options and
> >  Kconfig), then we can throw out all the locking. That avoids a lot of
> >  the headaches.
> > 
> > I have solved this by adding a notifier that fires when a new DRM device
> > is registered (I've removed the new() callback). Currently only
> > bootsplash uses this. The fbdev client needs to be setup from the driver
> > since it can't know on device registration if the driver will setup it's
> > own fbdev emulation later and the vtcon client hooks up to a user
> > provided device id.
> > 
> > Since fbcon can't handle fb_open failing, the buffer has to be
> > pre-allocated. Exporting a GEM buffer pins the driver module making it
> > impossible to unload it.
> > I have included 2 solutions to the problem:
> > - sysfs file to remove/close clients: remove_internal_clients
> > - Change drm_gem_prime_export() so it doesn't pin on client buffers
> > 
> > If a dumb buffer is exported from a kernel thread (worker) context, the
> > file descriptor isn't closed and I leak a reference so the buffer isn't
> > freed. Please look at drm_client_buffer_create() in patch
> > 'drm/client: Finish the in-kernel client API'.
> > This is a blocker that needs a solution.
> > 
> > 
> > Noralf.
> > 
> > Changes since version 3:
> > Client API changes:
> > - Drop drm_client_register_funcs() which attached clients indirectly.
> >Let clients attach directly using drm_client_new{_from_id}(). Clients
> >that wants to attach to all devices must be linked into drm.ko and use
> >the DRM device notifier. This is done to avoid the lock/race
> >register/unregister hell we have with fbcon. (Daniel Vetter)
> > - drm_client_display_restore() checks if there is a master and if so
> >returns -EBUSY. (Daniel Vetter)
> > - Allocate drm_file up front instead of on-demand. Since fbdev can't do
> >on demand buffer allocation because of fbcon, there's no need for this.
> > - Add sysfs file to remove clients
> > - Don't pin driver module when exporting gem client buffers
> > - Dropped page flip support since drm_fb_helper is now used for fbdev
> >emulation.
> > 
> > - The bootsplash client now switches over to fbdev on keypress.
> > 
> > Changes since version 2:
> > - Don't set drm master for in-kernel clients. (Daniel Vetter)
> > - Add in-kernel client API
> > 
> > Changes since version 1:
> > - Don't add drm_fb_helper_fb_open() and drm_fb_helper_fb_release() to
> >DRM_FB_HELPER_DEFAULT_OPS(). (Fi.CI.STATIC)
> >The following uses that macro and sets fb_open/close: udlfb_ops,
> >amdgpufb_ops, drm_fb_helper_generic_fbdev_ops, nouveau_fbcon_ops,
> >nouveau_fbcon_sw_ops, radeonfb_ops.
> >This results in: warning: Initializer entry defined twice
> > - Support CONFIG_DRM_KMS_HELPER=m (kbuild test robot)
> >ERROR:  [drivers/gpu/drm/drm_kms_helper.ko] undefined!
> > - Drop buggy patch: (Chris Wilson)
> >drm/prime: Clear drm_gem_object->dma_buf on release
> > - Defer buffer creation until fb_open.
> > 
> > 
> > David Herrmann (1):
> >drm: provide management functions for drm_file
> > 
> > Noralf Trønnes (24):
> >drm/file: Don't set master on in-kernel clients
> >drm/fb-helper: No need to cache rotation and sw_rotations
> >drm/fb-helper: Remove drm_fb_helper_debug_enter/leave()
> >drm/fb-helper: dpms_legacy(): Only set on connectors in use
> >drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
> >drm: Begin an API for in-kernel clients
> >drm/fb-helper: Use struct drm_client_display
> >

Re: [Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation

[Noralf Trønnes]

Argh, it didn't go through this time either.
I'll just have to strip off recipients and just send to the lists when 
the cool off period is over.


Sorry about the noise, I'll have to investigate this further.

Noralf.


Den 13.04.2018 18.53, skrev Noralf Trønnes:

This patchset explores the possibility of having generic fbdev emulation
in DRM for drivers that supports dumb buffers which they can export. An
API is added to support in-kernel clients in general.

In this version I was able to reuse the modesetting code from
drm_fb_helper in the client API. This avoids code duplication, carries
over lessons learned and the modesetting code is bisectable. The
downside is that it takes +10 patches to rip drm_fb_helper in two, so
maybe it's not worth it wrt possible breakage and a challenging review.

Does the Intel CI test the fbdev emulation?

Daniel had this concern with the previous version:

 The register/unregister model needs more thought. Allowing both clients
 to register whenever they want to, and drm_device instances to come and
 go is what fbcon has done, and the resulting locking is a horror show.

 I think if we require that all in-kernel drm_clients are registers when
 loading drm.ko (and enabled/disabled only per module options and
 Kconfig), then we can throw out all the locking. That avoids a lot of
 the headaches.

I have solved this by adding a notifier that fires when a new DRM device
is registered (I've removed the new() callback). Currently only
bootsplash uses this. The fbdev client needs to be setup from the driver
since it can't know on device registration if the driver will setup it's
own fbdev emulation later and the vtcon client hooks up to a user
provided device id.

Since fbcon can't handle fb_open failing, the buffer has to be
pre-allocated. Exporting a GEM buffer pins the driver module making it
impossible to unload it.
I have included 2 solutions to the problem:
- sysfs file to remove/close clients: remove_internal_clients
- Change drm_gem_prime_export() so it doesn't pin on client buffers

If a dumb buffer is exported from a kernel thread (worker) context, the
file descriptor isn't closed and I leak a reference so the buffer isn't
freed. Please look at drm_client_buffer_create() in patch
'drm/client: Finish the in-kernel client API'.
This is a blocker that needs a solution.


Noralf.

Changes since version 3:
Client API changes:
- Drop drm_client_register_funcs() which attached clients indirectly.
   Let clients attach directly using drm_client_new{_from_id}(). Clients
   that wants to attach to all devices must be linked into drm.ko and use
   the DRM device notifier. This is done to avoid the lock/race
   register/unregister hell we have with fbcon. (Daniel Vetter)
- drm_client_display_restore() checks if there is a master and if so
   returns -EBUSY. (Daniel Vetter)
- Allocate drm_file up front instead of on-demand. Since fbdev can't do
   on demand buffer allocation because of fbcon, there's no need for this.
- Add sysfs file to remove clients
- Don't pin driver module when exporting gem client buffers
- Dropped page flip support since drm_fb_helper is now used for fbdev
   emulation.

- The bootsplash client now switches over to fbdev on keypress.

Changes since version 2:
- Don't set drm master for in-kernel clients. (Daniel Vetter)
- Add in-kernel client API

Changes since version 1:
- Don't add drm_fb_helper_fb_open() and drm_fb_helper_fb_release() to
   DRM_FB_HELPER_DEFAULT_OPS(). (Fi.CI.STATIC)
   The following uses that macro and sets fb_open/close: udlfb_ops,
   amdgpufb_ops, drm_fb_helper_generic_fbdev_ops, nouveau_fbcon_ops,
   nouveau_fbcon_sw_ops, radeonfb_ops.
   This results in: warning: Initializer entry defined twice
- Support CONFIG_DRM_KMS_HELPER=m (kbuild test robot)
   ERROR:  [drivers/gpu/drm/drm_kms_helper.ko] undefined!
- Drop buggy patch: (Chris Wilson)
   drm/prime: Clear drm_gem_object->dma_buf on release
- Defer buffer creation until fb_open.


David Herrmann (1):
   drm: provide management functions for drm_file

Noralf Trønnes (24):
   drm/file: Don't set master on in-kernel clients
   drm/fb-helper: No need to cache rotation and sw_rotations
   drm/fb-helper: Remove drm_fb_helper_debug_enter/leave()
   drm/fb-helper: dpms_legacy(): Only set on connectors in use
   drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
   drm: Begin an API for in-kernel clients
   drm/fb-helper: Use struct drm_client_display
   drm/fb-helper: Move modeset commit code to drm_client
   drm/connector: Add
 drm_connector_has_preferred_mode/pick_cmdline_mode()
   drm/connector: Add connector array functions
   drm/i915: Add drm_driver->initial_client_display callback
   drm/fb-helper: Remove struct drm_fb_helper_crtc
   drm/fb-helper: Remove struct drm_fb_helper_connector
   drm/fb-helper: Move modeset config code to drm_client
   drm: Make ioctls available for in-kernel clients
   drm/client: Bail out if there's a DRM 

Re: [Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation

[Noralf Trønnes]

I hit a 'Sending rate exceeded' error with this patchset, so it didn't 
go out as it should.

I will resend the patchset when I find out how to avoid this problem.

Noralf.


Den 12.04.2018 15.17, skrev Noralf Trønnes:

This patchset explores the possibility of having generic fbdev emulation
in DRM for drivers that supports dumb buffers which they can export. An
API is added to support in-kernel clients in general.

In this version I was able to reuse the modesetting code from
drm_fb_helper in the client API. This avoids code duplication, carries
over lessons learned and the modesetting code is bisectable. The
downside is that it takes +10 patches to rip drm_fb_helper in two, so
maybe it's not worth it wrt possible breakage and a challenging review.

Does the Intel CI test the fbdev emulation?

Daniel had this concern with the previous version:

 The register/unregister model needs more thought. Allowing both clients
 to register whenever they want to, and drm_device instances to come and
 go is what fbcon has done, and the resulting locking is a horror show.

 I think if we require that all in-kernel drm_clients are registers when
 loading drm.ko (and enabled/disabled only per module options and
 Kconfig), then we can throw out all the locking. That avoids a lot of
 the headaches.

I have solved this by adding a notifier that fires when a new DRM device
is registered (I've removed the new() callback). Currently only
bootsplash uses this. The fbdev client needs to be setup from the driver
since it can't know on device registration if the driver will setup it's
own fbdev emulation later and the vtcon client hooks up to a user
provided device id.

Since fbcon can't handle fb_open failing, the buffer has to be
pre-allocated. Exporting a GEM buffer pins the driver module making it
impossible to unload it.
I have included 2 solutions to the problem:
- sysfs file to remove/close clients: remove_internal_clients
- Change drm_gem_prime_export() so it doesn't pin on client buffers

If a dumb buffer is exported from a kernel thread (worker) context, the
file descriptor isn't closed and I leak a reference so the buffer isn't
freed. Please look at drm_client_buffer_create() in patch
'drm/client: Finish the in-kernel client API'.
This is a blocker that needs a solution.


Noralf.

Changes since version 3:
Client API changes:
- Drop drm_client_register_funcs() which attached clients indirectly.
   Let clients attach directly using drm_client_new{_from_id}(). Clients
   that wants to attach to all devices must be linked into drm.ko and use
   the DRM device notifier. This is done to avoid the lock/race
   register/unregister hell we have with fbcon. (Daniel Vetter)
- drm_client_display_restore() checks if there is a master and if so
   returns -EBUSY. (Daniel Vetter)
- Allocate drm_file up front instead of on-demand. Since fbdev can't do
   on demand buffer allocation because of fbcon, there's no need for this.
- Add sysfs file to remove clients
- Don't pin driver module when exporting gem client buffers
- Dropped page flip support since drm_fb_helper is now used for fbdev
   emulation.

- The bootsplash client now switches over to fbdev on keypress.

Changes since version 2:
- Don't set drm master for in-kernel clients. (Daniel Vetter)
- Add in-kernel client API

Changes since version 1:
- Don't add drm_fb_helper_fb_open() and drm_fb_helper_fb_release() to
   DRM_FB_HELPER_DEFAULT_OPS(). (Fi.CI.STATIC)
   The following uses that macro and sets fb_open/close: udlfb_ops,
   amdgpufb_ops, drm_fb_helper_generic_fbdev_ops, nouveau_fbcon_ops,
   nouveau_fbcon_sw_ops, radeonfb_ops.
   This results in: warning: Initializer entry defined twice
- Support CONFIG_DRM_KMS_HELPER=m (kbuild test robot)
   ERROR:  [drivers/gpu/drm/drm_kms_helper.ko] undefined!
- Drop buggy patch: (Chris Wilson)
   drm/prime: Clear drm_gem_object->dma_buf on release
- Defer buffer creation until fb_open.


David Herrmann (1):
   drm: provide management functions for drm_file

Noralf Trønnes (24):
   drm/file: Don't set master on in-kernel clients
   drm/fb-helper: No need to cache rotation and sw_rotations
   drm/fb-helper: Remove drm_fb_helper_debug_enter/leave()
   drm/fb-helper: dpms_legacy(): Only set on connectors in use
   drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
   drm: Begin an API for in-kernel clients
   drm/fb-helper: Use struct drm_client_display
   drm/fb-helper: Move modeset commit code to drm_client
   drm/connector: Add
 drm_connector_has_preferred_mode/pick_cmdline_mode()
   drm/connector: Add connector array functions
   drm/i915: Add drm_driver->initial_client_display callback
   drm/fb-helper: Remove struct drm_fb_helper_crtc
   drm/fb-helper: Remove struct drm_fb_helper_connector
   drm/fb-helper: Move modeset config code to drm_client
   drm: Make ioctls available for in-kernel clients
   drm/client: Bail out if there's a DRM master
   drm/client: Make the display modes