Re: [PATCH v2 00/14] improve the fb_setcmap helper
On 2017-06-26 11:35, Daniel Vetter wrote: > On Thu, Jun 22, 2017 at 08:06:23AM +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 and 3 are enough to make the atmel-hlcdc driver >> do what I need (when patched to support CLUT modes). 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 in this mostly mechanical change... >> >> 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). > > Ok some nits/questions on the first three, but in principle looks all ok I > think. The driver patches also look good (but I didn't yet carefully > review all the conversion). What we might want to do is entirely remove > driver's reliance on ->gamma_store (mostly amounts to in-lining the > load_lut functions) and only update ->gamma_store after gamma_set returned > successfully. But that's a bit more work. > > Save/restoring it instead might be simpler to fix that bug, but since it's > pre-existing also ok as follow-up. I'm traveling and cannot make progress this week. The merge window is also real close so this series will therefore probably miss it unless something unexpected happens... I'll get back to this for the next cycle, just a heads up. Cheers, peda ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 00/14] improve the fb_setcmap helper
> > I'm traveling and cannot make progress this week. The merge window is > also real close so this series will therefore probably miss it unless > something unexpected happens... Don't worry you missed the merge window for drm already, we don't merge things after -rc6. Please remember the Linus merge window is for maintainers to merge stuff to Linus, things need to be ready long before it, and for drm you shouldn't really tie yourself to the merge cycle. Dave. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 00/14] improve the fb_setcmap helper
On Thu, Jun 22, 2017 at 08:06:23AM +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 and 3 are enough to make the atmel-hlcdc driver > do what I need (when patched to support CLUT modes). 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 in this mostly mechanical change... > > 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). Ok some nits/questions on the first three, but in principle looks all ok I think. The driver patches also look good (but I didn't yet carefully review all the conversion). What we might want to do is entirely remove driver's reliance on ->gamma_store (mostly amounts to in-lining the load_lut functions) and only update ->gamma_store after gamma_set returned successfully. But that's a bit more work. Save/restoring it instead might be simpler to fix that bug, but since it's pre-existing also ok as follow-up. Cheers, Daniel > > Cheers, > peda > > Peter Rosin (14): > drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmap > drm/fb-helper: remove drm_fb_helper_save_lut_atomic > 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 | 27 ++--- > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 27 ++--- > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 27 ++--- > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 27 ++--- > drivers/gpu/drm/amd/amdgpu/dce_virtual.c| 23 > 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 | 26 + > drivers/gpu/drm/cirrus/cirrus_drv.h | 8 -- > drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 - > drivers/gpu/drm/cirrus/cirrus_mode.c| 71 +++- > drivers/gpu/drm/drm_fb_helper.c | 164 > +--- > drivers/gpu/drm/gma500/framebuffer.c| 22 > drivers/gpu/drm/gma500/gma_display.c| 32 ++ > 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 | 62 +++ > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 26 ++--- > drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 - > drivers/gpu/drm/nouveau/nouveau_fbcon.c | 22 > drivers/gpu/drm/nouveau/nv50_display.c | 40 +++ > drivers/gpu/drm/radeon/atombios_crtc.c | 1 - > drivers/gpu/drm/radeon/radeon_connectors.c | 7 +- > drivers/gpu/drm/radeon/radeon_display.c | 71 +--- > drivers/gpu/drm/radeon/radeon_fb.c | 2 - > drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 1 - > drivers/gpu/drm/radeon/radeon_mode.h
