similar to: [PATCH v3 00/28] DRM API Conversions

This patch set replaces the occurrences of drm_*_reference() and drm_*_unreference() with the new drm_*_get() and drm_*_put() functions. All patches in the series do the same thing, converting to the new APIs. I created patches per DRM driver as suggested by Daniel Vetter. Background: In the kernel, reference counting APIs use *_get(), *_put() style naming to reference-count the objects. But DRM

Looks good to me! Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> On 8/3/17 1:58 PM, Cihangir Akturk wrote: > drm_*_reference() and drm_*_unreference() functions are just > compatibility alias for drm_*_get() and drm_*_put() adn should not be > used by new code. So convert all users of compatibility functions to use > the new APIs. > >

After long term efforts of fixing non-common clock implementations, clk_disable() is a no-op for a NULL pointer input, and this is now tree-wide consistent. All clock consumers can safely call clk_disable(_unprepare) without NULL pointer check. Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com> --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 15 +++++----------

Added my rb to the amdgpu and radeon patches. Should we pick those up through the amd branches or do you want to push everything to drm-misc-next? I think the later since this should result in much merge clash. Christian. Am 15.09.20 um 16:59 schrieb Thomas Zimmermann: > The GEM and PRIME related callbacks in struct drm_driver are deprecated in > favor of GEM object functions in struct

Feel free to add an Acked-by: Christian K?nig <christian.koenig at amd.com> to all patches which I haven't explicitly reviewed. I would say we should just push this to drm-misc-next now. Thanks for the nice cleanup, Christian. Am 23.09.20 um 12:21 schrieb Thomas Zimmermann: > The GEM and PRIME related callbacks in struct drm_driver are deprecated in > favor of GEM object

Well I think we rejected that multiple times now. At least I find the symbolic permissions easier to read and I absolutely don't see any reason why we should only use one form. Christian. Am 24.05.2018 um 22:22 schrieb Joe Perches: > There is currently a mixture of octal and symbolic permissions uses > in files in drivers/gpu/drm and one file in drivers/gpu. > > There are ~270

On Wed, Apr 18, 2018 at 12:24:50PM +0300, Alexey Brodkin wrote: > After commit ad67b74 ("printk: hash addresses printed with %p") > pointers are being hashed when printed. However, this makes > debug output completely useless. Switch to %px in order to see the > unadorned kernel pointers. > > This was done with the following one-liner: > find drivers/gpu/drm -type

drm_*_reference() and drm_*_unreference() functions are just compatibility alias for drm_*_get() and drm_*_put() adn should not be used by new code. So convert all users of compatibility functions to use the new APIs. Signed-off-by: Cihangir Akturk <cakturk at gmail.com> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-

Hello, this patch series adapts the platform drivers below drivers/gpu/drm to use the .remove_new() callback. Compared to the traditional .remove() callback .remove_new() returns no value. This is a good thing because the driver core doesn't (and cannot) cope for errors during remove. The only effect of a non-zero return value in .remove() is that the driver core emits a warning. The device

Le lun. 10 déc. 2018 à 11:24, Thierry Reding <thierry.reding at gmail.com> a écrit : > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > > Having the probe helper stuff (which pretty much everyone needs) in > > the drm_crtc_helper.h file (which atomic drivers should never need) is > > confusing. Split them out. > > > > To make sure I

There is currently a mixture of octal and symbolic permissions uses in files in drivers/gpu/drm and one file in drivers/gpu. There are ~270 existing octal uses and ~115 S_<FOO> uses. Convert all the S_<FOO> symbolic permissions to their octal equivalents as using octal and not symbolic permissions is preferred by many as more readable. see: https://lkml.org/lkml/2016/8/2/1945 Done

vmwgfx part: Reviewed-by: Sinclair Yeh <syeh at vmware.com> On Wed, May 17, 2017 at 09:39:11PM -0400, Robert Foss wrote: > Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI > as a convenience. > > Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up > through the atomic API, but realizing that userspace is likely to take > shortcuts and assume

On Fri, May 19, 2017 at 04:50:17PM -0400, Robert Foss wrote: > Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI > as a convenience. > > Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up > through the atomic API, but realizing that userspace is likely to take > shortcuts and assume that the enum values are what is sent over the > wire. >

On Fri, May 19, 2017 at 04:50:17PM -0400, Robert Foss wrote: > Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI > as a convenience. > > Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up > through the atomic API, but realizing that userspace is likely to take > shortcuts and assume that the enum values are what is sent over the > wire. >

On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of >

On 15/01/2019 11:41, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. >

Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard <benjamin.gaignard at linaro.org> a écrit : > > Le lun. 10 déc. 2018 à 11:24, Thierry Reding > <thierry.reding at gmail.com> a écrit : > > > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > > > Having the probe helper stuff (which pretty much everyone needs) in > > > the

Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard <benjamin.gaignard at linaro.org> a écrit : > > Le lun. 10 déc. 2018 à 11:24, Thierry Reding > <thierry.reding at gmail.com> a écrit : > > > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > > > Having the probe helper stuff (which pretty much everyone needs) in > > > the

Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard <benjamin.gaignard at linaro.org> a écrit : > > Le lun. 10 déc. 2018 à 11:24, Thierry Reding > <thierry.reding at gmail.com> a écrit : > > > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > > > Having the probe helper stuff (which pretty much everyone needs) in > > > the

On 1/15/19 2:26 PM, Neil Armstrong wrote: > On 15/01/2019 11:41, Daniel Vetter wrote: >> Having the probe helper stuff (which pretty much everyone needs) in >> the drm_crtc_helper.h file (which atomic drivers should never need) is >> confusing. Split them out. >> >> To make sure I actually achieved the goal here I went through all >> drivers. And indeed, all