Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

[Daniel Vetter]

On Wed, Jul 05, 2017 at 10:09:21AM +0200, Peter Rosin wrote:
> On 2017-07-05 08:08, Daniel Vetter wrote:
> > On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote:
> >> Hi!
> >>
> >> While trying to get CLUT support for the atmel_hlcdc driver, and
> >> specifically for the emulated fbdev interface, I received some
> >> push-back that my feeble in-driver attempts should be solved
> >> by the core. This is my attempt to do it right.
> >>
> >> I have obviously not tested all of this with more than a compile,
> >> but patches 1 through 5 are enough to make the atmel-hlcdc driver
> >> do what I need. The rest is just lots of removals and cleanup made
> >> possible by the improved core.
> >>
> >> Please test, I would not be surprised if I have fouled up some
> >> bit-manipulation somewhere, or if I have misunderstood something
> >> about atomics...
> >>
> >> Changes since v2:
> >> - Added patch 1/16 which factors out pseudo-palette handling.
> >> - Removed the if (cmap->start + cmap->len < cmap->start)
> >>   sanity check on the assumption that the fbdev core handles it.
> >> - Added patch 4/16 which factors out atomic state and commit
> >>   handling from drm_atomic_helper_legacy_gamma_set to
> >>   drm_mode_gamma_set_ioctl.
> >> - Do one atomic commit for all affected crtc.
> >> - Removed a now obsolete note in include/drm/drm_crtc.h (ammended
> >>   the last patch).
> >> - Cc list is getting long, so I have redused the list for the
> >>   individual patches. If you would like to get the full series
> >>   (or nothing at all) for the next round (if that is needed) just
> >>   say so.
> > 
> > Is this still on top of my locking rework? I tried to apply patches 1-3,
> > but there's minor conflicts ...
> > -Daniel
> 
> v3 has the same base as v2. I collected your locking rework sometime
> after june 21, you have perhaps changed things since? I saw an update
> of that dpms patch you Cc me, but figured there were no significant
> changes that I needed to handle since I didn't get the full set
> this time either. A bad assumption it seems...

There's a difference between my own private patches, and the maintainer
repo where stuff gets applied. But that explains why there was a conflict.

I plan to merge my locking changes tomorrow (they're reviewed and ready
now), I'll apply your patches after that. That should take care of the
conflicts.

Thanks, Daniel

> 
> Anyway, the base I have for v3 (and v2) is linux next-20170621 plus
> the following locking rework commits (in reverse order):
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:15 2017 +0200
> Subject: drm/hisilicon: Remove custom FB helper deferred setup
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:14 2017 +0200
> Subject: drm/exynos: Remove custom FB helper deferred setup
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:13 2017 +0200
> Subject: drm/fb-helper: Support deferred setup
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:12 2017 +0200
> Subject: drm/fb-helper: Split dpms handling into legacy and atomic paths
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:11 2017 +0200
> Subject: drm/fb-helper: Stop using mode_config.mutex for internals
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:10 2017 +0200
> Subject: drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:09 2017 +0200
> Subject: drm/fb-helper: Push locking into pan_display_atomic|legacy
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:08 2017 +0200
> Subject: drm/fb-helper: Drop locking from the vsync wait ioctl code
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:07 2017 +0200
> Subject: drm/fb-helper: Push locking in fb_is_bound
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:06 2017 +0200
> Subject: drm/fb-helper: Add top-level lock
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:05 2017 +0200
> Subject: drm/i915: Drop FBDEV #ifdev in mst code
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:04 2017 +0200
> Subject: drm/fb-helper: Push down modeset lock into FB helpers
> 
> Cheers,
> peda
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

[Daniel Vetter]

On Wed, Jul 05, 2017 at 10:09:21AM +0200, Peter Rosin wrote:
> On 2017-07-05 08:08, Daniel Vetter wrote:
> > On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote:
> >> Hi!
> >>
> >> While trying to get CLUT support for the atmel_hlcdc driver, and
> >> specifically for the emulated fbdev interface, I received some
> >> push-back that my feeble in-driver attempts should be solved
> >> by the core. This is my attempt to do it right.
> >>
> >> I have obviously not tested all of this with more than a compile,
> >> but patches 1 through 5 are enough to make the atmel-hlcdc driver
> >> do what I need. The rest is just lots of removals and cleanup made
> >> possible by the improved core.
> >>
> >> Please test, I would not be surprised if I have fouled up some
> >> bit-manipulation somewhere, or if I have misunderstood something
> >> about atomics...
> >>
> >> Changes since v2:
> >> - Added patch 1/16 which factors out pseudo-palette handling.
> >> - Removed the if (cmap->start + cmap->len < cmap->start)
> >>   sanity check on the assumption that the fbdev core handles it.
> >> - Added patch 4/16 which factors out atomic state and commit
> >>   handling from drm_atomic_helper_legacy_gamma_set to
> >>   drm_mode_gamma_set_ioctl.
> >> - Do one atomic commit for all affected crtc.
> >> - Removed a now obsolete note in include/drm/drm_crtc.h (ammended
> >>   the last patch).
> >> - Cc list is getting long, so I have redused the list for the
> >>   individual patches. If you would like to get the full series
> >>   (or nothing at all) for the next round (if that is needed) just
> >>   say so.
> > 
> > Is this still on top of my locking rework? I tried to apply patches 1-3,
> > but there's minor conflicts ...
> > -Daniel
> 
> v3 has the same base as v2. I collected your locking rework sometime
> after june 21, you have perhaps changed things since? I saw an update
> of that dpms patch you Cc me, but figured there were no significant
> changes that I needed to handle since I didn't get the full set
> this time either. A bad assumption it seems...

There's a difference between my own private patches, and the maintainer
repo where stuff gets applied. But that explains why there was a conflict.

I plan to merge my locking changes tomorrow (they're reviewed and ready
now), I'll apply your patches after that. That should take care of the
conflicts.

Thanks, Daniel

> 
> Anyway, the base I have for v3 (and v2) is linux next-20170621 plus
> the following locking rework commits (in reverse order):
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:15 2017 +0200
> Subject: drm/hisilicon: Remove custom FB helper deferred setup
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:14 2017 +0200
> Subject: drm/exynos: Remove custom FB helper deferred setup
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:13 2017 +0200
> Subject: drm/fb-helper: Support deferred setup
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:12 2017 +0200
> Subject: drm/fb-helper: Split dpms handling into legacy and atomic paths
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:11 2017 +0200
> Subject: drm/fb-helper: Stop using mode_config.mutex for internals
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:10 2017 +0200
> Subject: drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:09 2017 +0200
> Subject: drm/fb-helper: Push locking into pan_display_atomic|legacy
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:08 2017 +0200
> Subject: drm/fb-helper: Drop locking from the vsync wait ioctl code
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:07 2017 +0200
> Subject: drm/fb-helper: Push locking in fb_is_bound
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:06 2017 +0200
> Subject: drm/fb-helper: Add top-level lock
> 
> Author: Daniel Vetter 
> Date: Wed Jun 21 20:28:05 2017 +0200
> Subject: drm/i915: Drop FBDEV #ifdev in mst code
> 
> Author: Thierry Reding 
> Date: Wed Jun 21 20:28:04 2017 +0200
> Subject: drm/fb-helper: Push down modeset lock into FB helpers
> 
> Cheers,
> peda
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

[Peter Rosin]

On 2017-07-05 08:08, Daniel Vetter wrote:
> On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote:
>> Hi!
>>
>> While trying to get CLUT support for the atmel_hlcdc driver, and
>> specifically for the emulated fbdev interface, I received some
>> push-back that my feeble in-driver attempts should be solved
>> by the core. This is my attempt to do it right.
>>
>> I have obviously not tested all of this with more than a compile,
>> but patches 1 through 5 are enough to make the atmel-hlcdc driver
>> do what I need. The rest is just lots of removals and cleanup made
>> possible by the improved core.
>>
>> Please test, I would not be surprised if I have fouled up some
>> bit-manipulation somewhere, or if I have misunderstood something
>> about atomics...
>>
>> Changes since v2:
>> - Added patch 1/16 which factors out pseudo-palette handling.
>> - Removed the if (cmap->start + cmap->len < cmap->start)
>>   sanity check on the assumption that the fbdev core handles it.
>> - Added patch 4/16 which factors out atomic state and commit
>>   handling from drm_atomic_helper_legacy_gamma_set to
>>   drm_mode_gamma_set_ioctl.
>> - Do one atomic commit for all affected crtc.
>> - Removed a now obsolete note in include/drm/drm_crtc.h (ammended
>>   the last patch).
>> - Cc list is getting long, so I have redused the list for the
>>   individual patches. If you would like to get the full series
>>   (or nothing at all) for the next round (if that is needed) just
>>   say so.
> 
> Is this still on top of my locking rework? I tried to apply patches 1-3,
> but there's minor conflicts ...
> -Daniel

v3 has the same base as v2. I collected your locking rework sometime
after june 21, you have perhaps changed things since? I saw an update
of that dpms patch you Cc me, but figured there were no significant
changes that I needed to handle since I didn't get the full set
this time either. A bad assumption it seems...

Anyway, the base I have for v3 (and v2) is linux next-20170621 plus
the following locking rework commits (in reverse order):

Author: Thierry Reding 
Date: Wed Jun 21 20:28:15 2017 +0200
Subject: drm/hisilicon: Remove custom FB helper deferred setup

Author: Thierry Reding 
Date: Wed Jun 21 20:28:14 2017 +0200
Subject: drm/exynos: Remove custom FB helper deferred setup

Author: Thierry Reding 
Date: Wed Jun 21 20:28:13 2017 +0200
Subject: drm/fb-helper: Support deferred setup

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:12 2017 +0200
Subject: drm/fb-helper: Split dpms handling into legacy and atomic paths

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:11 2017 +0200
Subject: drm/fb-helper: Stop using mode_config.mutex for internals

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:10 2017 +0200
Subject: drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:09 2017 +0200
Subject: drm/fb-helper: Push locking into pan_display_atomic|legacy

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:08 2017 +0200
Subject: drm/fb-helper: Drop locking from the vsync wait ioctl code

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:07 2017 +0200
Subject: drm/fb-helper: Push locking in fb_is_bound

Author: Thierry Reding 
Date: Wed Jun 21 20:28:06 2017 +0200
Subject: drm/fb-helper: Add top-level lock

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:05 2017 +0200
Subject: drm/i915: Drop FBDEV #ifdev in mst code

Author: Thierry Reding 
Date: Wed Jun 21 20:28:04 2017 +0200
Subject: drm/fb-helper: Push down modeset lock into FB helpers

Cheers,
peda

Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

[Peter Rosin]

On 2017-07-05 08:08, Daniel Vetter wrote:
> On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote:
>> Hi!
>>
>> While trying to get CLUT support for the atmel_hlcdc driver, and
>> specifically for the emulated fbdev interface, I received some
>> push-back that my feeble in-driver attempts should be solved
>> by the core. This is my attempt to do it right.
>>
>> I have obviously not tested all of this with more than a compile,
>> but patches 1 through 5 are enough to make the atmel-hlcdc driver
>> do what I need. The rest is just lots of removals and cleanup made
>> possible by the improved core.
>>
>> Please test, I would not be surprised if I have fouled up some
>> bit-manipulation somewhere, or if I have misunderstood something
>> about atomics...
>>
>> Changes since v2:
>> - Added patch 1/16 which factors out pseudo-palette handling.
>> - Removed the if (cmap->start + cmap->len < cmap->start)
>>   sanity check on the assumption that the fbdev core handles it.
>> - Added patch 4/16 which factors out atomic state and commit
>>   handling from drm_atomic_helper_legacy_gamma_set to
>>   drm_mode_gamma_set_ioctl.
>> - Do one atomic commit for all affected crtc.
>> - Removed a now obsolete note in include/drm/drm_crtc.h (ammended
>>   the last patch).
>> - Cc list is getting long, so I have redused the list for the
>>   individual patches. If you would like to get the full series
>>   (or nothing at all) for the next round (if that is needed) just
>>   say so.
> 
> Is this still on top of my locking rework? I tried to apply patches 1-3,
> but there's minor conflicts ...
> -Daniel

v3 has the same base as v2. I collected your locking rework sometime
after june 21, you have perhaps changed things since? I saw an update
of that dpms patch you Cc me, but figured there were no significant
changes that I needed to handle since I didn't get the full set
this time either. A bad assumption it seems...

Anyway, the base I have for v3 (and v2) is linux next-20170621 plus
the following locking rework commits (in reverse order):

Author: Thierry Reding 
Date: Wed Jun 21 20:28:15 2017 +0200
Subject: drm/hisilicon: Remove custom FB helper deferred setup

Author: Thierry Reding 
Date: Wed Jun 21 20:28:14 2017 +0200
Subject: drm/exynos: Remove custom FB helper deferred setup

Author: Thierry Reding 
Date: Wed Jun 21 20:28:13 2017 +0200
Subject: drm/fb-helper: Support deferred setup

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:12 2017 +0200
Subject: drm/fb-helper: Split dpms handling into legacy and atomic paths

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:11 2017 +0200
Subject: drm/fb-helper: Stop using mode_config.mutex for internals

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:10 2017 +0200
Subject: drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:09 2017 +0200
Subject: drm/fb-helper: Push locking into pan_display_atomic|legacy

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:08 2017 +0200
Subject: drm/fb-helper: Drop locking from the vsync wait ioctl code

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:07 2017 +0200
Subject: drm/fb-helper: Push locking in fb_is_bound

Author: Thierry Reding 
Date: Wed Jun 21 20:28:06 2017 +0200
Subject: drm/fb-helper: Add top-level lock

Author: Daniel Vetter 
Date: Wed Jun 21 20:28:05 2017 +0200
Subject: drm/i915: Drop FBDEV #ifdev in mst code

Author: Thierry Reding 
Date: Wed Jun 21 20:28:04 2017 +0200
Subject: drm/fb-helper: Push down modeset lock into FB helpers

Cheers,
peda

Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

[Daniel Vetter]

On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote:
> Hi!
> 
> While trying to get CLUT support for the atmel_hlcdc driver, and
> specifically for the emulated fbdev interface, I received some
> push-back that my feeble in-driver attempts should be solved
> by the core. This is my attempt to do it right.
> 
> I have obviously not tested all of this with more than a compile,
> but patches 1 through 5 are enough to make the atmel-hlcdc driver
> do what I need. The rest is just lots of removals and cleanup made
> possible by the improved core.
> 
> Please test, I would not be surprised if I have fouled up some
> bit-manipulation somewhere, or if I have misunderstood something
> about atomics...
> 
> Changes since v2:
> - Added patch 1/16 which factors out pseudo-palette handling.
> - Removed the if (cmap->start + cmap->len < cmap->start)
>   sanity check on the assumption that the fbdev core handles it.
> - Added patch 4/16 which factors out atomic state and commit
>   handling from drm_atomic_helper_legacy_gamma_set to
>   drm_mode_gamma_set_ioctl.
> - Do one atomic commit for all affected crtc.
> - Removed a now obsolete note in include/drm/drm_crtc.h (ammended
>   the last patch).
> - Cc list is getting long, so I have redused the list for the
>   individual patches. If you would like to get the full series
>   (or nothing at all) for the next round (if that is needed) just
>   say so.

Is this still on top of my locking rework? I tried to apply patches 1-3,
but there's minor conflicts ...
-Daniel

> 
> Changes since v1:
> 
> - Rebased to next-20170621
> - Split 1/11 into a preparatory patch, a cleanup patch and then
>   the meat in 3/14.
> - Handle pseudo-palette for FB_VISUAL_TRUECOLOR.
> - Removed the empty .gamma_get/.gamma_set fb helpers from the
>   armada driver that I had somehow managed to ignore but which
>   0day found real quick.
> - Be less judgemental on drivers only providing .gamma_get and
>   .gamma_set, but no .load_lut. That's actually a valid thing
>   to do if you only need pseudo-palette for FB_VISUAL_TRUECOLOR.
> - Add a comment about colliding bitfields in the nouveau driver.
> - Remove gamma_set/gamma_get declarations from the radeon driver
>   (the definitions were removed in v1).
> 
> Cheers,
> peda
> 
> Peter Rosin (16):
>   drm/fb-helper: factor out pseudo-palette
>   drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmap
>   drm/fb-helper: remove drm_fb_helper_save_lut_atomic
>   drm/color-mgmt: move atomic state/commit out from .gamma_set
>   drm/fb-helper: do a generic fb_setcmap helper in terms of crtc
> .gamma_set
>   drm: amd: remove dead code and pointless local lut storage
>   drm: armada: remove dead empty functions
>   drm: ast: remove dead code and pointless local lut storage
>   drm: cirrus: remove dead code and pointless local lut storage
>   drm: gma500: remove dead code and pointless local lut storage
>   drm: i915: remove dead code and pointless local lut storage
>   drm: mgag200: remove dead code and pointless local lut storage
>   drm: nouveau: remove dead code and pointless local lut storage
>   drm: radeon: remove dead code and pointless local lut storage
>   drm: stm: remove dead code and pointless local lut storage
>   drm: remove unused and redundant callbacks
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |  24 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|   1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c|  25 +---
>  drivers/gpu/drm/armada/armada_crtc.c|  10 --
>  drivers/gpu/drm/armada/armada_crtc.h|   2 -
>  drivers/gpu/drm/armada/armada_fbdev.c   |   2 -
>  drivers/gpu/drm/ast/ast_drv.h   |   1 -
>  drivers/gpu/drm/ast/ast_fb.c|  20 ---
>  drivers/gpu/drm/ast/ast_mode.c  |  28 +---
>  drivers/gpu/drm/cirrus/cirrus_drv.h |   8 --
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c   |   2 -
>  drivers/gpu/drm/cirrus/cirrus_mode.c|  73 +++
>  drivers/gpu/drm/drm_atomic_helper.c |  37 ++
>  drivers/gpu/drm/drm_color_mgmt.c|  27 +++-
>  drivers/gpu/drm/drm_fb_helper.c | 195 
> +---
>  drivers/gpu/drm/gma500/framebuffer.c|  22 
>  drivers/gpu/drm/gma500/gma_display.c|  34 ++---
>  drivers/gpu/drm/gma500/gma_display.h|   2 +-
>  drivers/gpu/drm/gma500/psb_intel_display.c  |   7 +-
>  drivers/gpu/drm/gma500/psb_intel_drv.h  |   1 -
>  drivers/gpu/drm/i915/intel_drv.h|   1 -
>  drivers/gpu/drm/i915/intel_fbdev.c  |  31 -
>  drivers/gpu/drm/mgag200/mgag200_drv.h   |   5 -
>  drivers/gpu/drm/mgag200/mgag200_fb.c|   2 -
>  drivers/gpu/drm/mgag200/mgag200_mode.c  |  64 +++--
>  

Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

[Daniel Vetter]

On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote:
> Hi!
> 
> While trying to get CLUT support for the atmel_hlcdc driver, and
> specifically for the emulated fbdev interface, I received some
> push-back that my feeble in-driver attempts should be solved
> by the core. This is my attempt to do it right.
> 
> I have obviously not tested all of this with more than a compile,
> but patches 1 through 5 are enough to make the atmel-hlcdc driver
> do what I need. The rest is just lots of removals and cleanup made
> possible by the improved core.
> 
> Please test, I would not be surprised if I have fouled up some
> bit-manipulation somewhere, or if I have misunderstood something
> about atomics...
> 
> Changes since v2:
> - Added patch 1/16 which factors out pseudo-palette handling.
> - Removed the if (cmap->start + cmap->len < cmap->start)
>   sanity check on the assumption that the fbdev core handles it.
> - Added patch 4/16 which factors out atomic state and commit
>   handling from drm_atomic_helper_legacy_gamma_set to
>   drm_mode_gamma_set_ioctl.
> - Do one atomic commit for all affected crtc.
> - Removed a now obsolete note in include/drm/drm_crtc.h (ammended
>   the last patch).
> - Cc list is getting long, so I have redused the list for the
>   individual patches. If you would like to get the full series
>   (or nothing at all) for the next round (if that is needed) just
>   say so.

Is this still on top of my locking rework? I tried to apply patches 1-3,
but there's minor conflicts ...
-Daniel

> 
> Changes since v1:
> 
> - Rebased to next-20170621
> - Split 1/11 into a preparatory patch, a cleanup patch and then
>   the meat in 3/14.
> - Handle pseudo-palette for FB_VISUAL_TRUECOLOR.
> - Removed the empty .gamma_get/.gamma_set fb helpers from the
>   armada driver that I had somehow managed to ignore but which
>   0day found real quick.
> - Be less judgemental on drivers only providing .gamma_get and
>   .gamma_set, but no .load_lut. That's actually a valid thing
>   to do if you only need pseudo-palette for FB_VISUAL_TRUECOLOR.
> - Add a comment about colliding bitfields in the nouveau driver.
> - Remove gamma_set/gamma_get declarations from the radeon driver
>   (the definitions were removed in v1).
> 
> Cheers,
> peda
> 
> Peter Rosin (16):
>   drm/fb-helper: factor out pseudo-palette
>   drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmap
>   drm/fb-helper: remove drm_fb_helper_save_lut_atomic
>   drm/color-mgmt: move atomic state/commit out from .gamma_set
>   drm/fb-helper: do a generic fb_setcmap helper in terms of crtc
> .gamma_set
>   drm: amd: remove dead code and pointless local lut storage
>   drm: armada: remove dead empty functions
>   drm: ast: remove dead code and pointless local lut storage
>   drm: cirrus: remove dead code and pointless local lut storage
>   drm: gma500: remove dead code and pointless local lut storage
>   drm: i915: remove dead code and pointless local lut storage
>   drm: mgag200: remove dead code and pointless local lut storage
>   drm: nouveau: remove dead code and pointless local lut storage
>   drm: radeon: remove dead code and pointless local lut storage
>   drm: stm: remove dead code and pointless local lut storage
>   drm: remove unused and redundant callbacks
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |  24 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|   1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  29 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c|  25 +---
>  drivers/gpu/drm/armada/armada_crtc.c|  10 --
>  drivers/gpu/drm/armada/armada_crtc.h|   2 -
>  drivers/gpu/drm/armada/armada_fbdev.c   |   2 -
>  drivers/gpu/drm/ast/ast_drv.h   |   1 -
>  drivers/gpu/drm/ast/ast_fb.c|  20 ---
>  drivers/gpu/drm/ast/ast_mode.c  |  28 +---
>  drivers/gpu/drm/cirrus/cirrus_drv.h |   8 --
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c   |   2 -
>  drivers/gpu/drm/cirrus/cirrus_mode.c|  73 +++
>  drivers/gpu/drm/drm_atomic_helper.c |  37 ++
>  drivers/gpu/drm/drm_color_mgmt.c|  27 +++-
>  drivers/gpu/drm/drm_fb_helper.c | 195 
> +---
>  drivers/gpu/drm/gma500/framebuffer.c|  22 
>  drivers/gpu/drm/gma500/gma_display.c|  34 ++---
>  drivers/gpu/drm/gma500/gma_display.h|   2 +-
>  drivers/gpu/drm/gma500/psb_intel_display.c  |   7 +-
>  drivers/gpu/drm/gma500/psb_intel_drv.h  |   1 -
>  drivers/gpu/drm/i915/intel_drv.h|   1 -
>  drivers/gpu/drm/i915/intel_fbdev.c  |  31 -
>  drivers/gpu/drm/mgag200/mgag200_drv.h   |   5 -
>  drivers/gpu/drm/mgag200/mgag200_fb.c|   2 -
>  drivers/gpu/drm/mgag200/mgag200_mode.c  |  64 +++--
>