Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

On Tue, 15 Feb 2022 at 16:37, Simon Ser wrote: > > On Tuesday, February 15th, 2022 at 15:38, Emil Velikov > wrote: > > > On Tue, 15 Feb 2022 at 13:55, Simon Ser wrote: > > > > > > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov > >

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

On Tue, 15 Feb 2022 at 13:55, Simon Ser wrote: > > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov > wrote: > > > Greetings everyone, > > > > Padron for joining in so late o/ > > > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang wrote: >

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

Greetings everyone, Padron for joining in so late o/ On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang wrote: > > drm_dev_register() sets connector->registration_state to > DRM_CONNECTOR_REGISTERED and dev->registered to true. If > drm_connector_set_panel_orientation() is first called after >

Re: [PATCH v4 5/7] i915/gvt: control pr_debug("gvt:")s with bits in parameters/debug_gvt

Hi Jim, On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote: > DYNDBG_BITMAP_DESC(__gvt_debug, "dyndbg bitmap desc", > { "gvt: cmd: ", "command processing" }, > { "gvt: core: ", "core help" }, > { "gvt: dpy: ", "display help" }, > { "gvt: el: ", "help" }, >

Re: [Intel-gfx] [PATCH v4 3/7] dyndbg: add dyndbg-bitmap definer and callbacks

Hi Jim, On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote: > +struct dyndbg_bitdesc { > + /* bitpos is inferred from index in containing array */ > + char *prefix; > + char *help; AFAICT these two should also be constant, right? > +int param_set_dyndbg(const char *instr, const

Re: [PATCH v4 2/7] moduleparam: add data member to struct kernel_param

Hi Jim, On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote: > Use of this new data member will be rare, it might be worth redoing > this as a separate/sub-type to keep the base case. > > Signed-off-by: Jim Cromie > --- > include/linux/moduleparam.h | 11 +-- > 1 file changed, 9

Re: [PATCH] drm/amdgpu: fix leftover drm_gem_object_put_unlocked call

On Fri, 22 May 2020 at 20:43, Emil Velikov wrote: > > On Fri, 22 May 2020 at 20:38, Simon Ser wrote: > > > > drm_gem_object_put_unlocked has been renamed to drm_gem_object_put. > > > > Signed-off-by: Simon Ser > > Fixes: e07ddb0ce7c

Re: [PATCH] drm/amdgpu: fix leftover drm_gem_object_put_unlocked call

On Fri, 22 May 2020 at 20:38, Simon Ser wrote: > > drm_gem_object_put_unlocked has been renamed to drm_gem_object_put. > > Signed-off-by: Simon Ser > Fixes: e07ddb0ce7cd ("drm/amd: remove _unlocked suffix in > drm_gem_object_put_unlocked") Wrong tag it seems. At that commit, the amdgpu code

[PATCH v2 07/38] drm/amdgpu: use the unlocked drm_gem_object_put

From: Emil Velikov The driver does not hold struct_mutex, thus using the locked version of the helper is incorrect. Cc: Alex Deucher Cc: Christian König Cc: amd-gfx@lists.freedesktop.org Fixes: a39414716ca0 ("drm/amdgpu: add independent DMA-buf import v9"): Signed-off-by: Emil Veli

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, 12 May 2020 at 20:48, Alex Deucher wrote: > > >> > > >> There's some AGP support code in the DRM core. Can some of that declared > > >> as legacy? > > >> > > >> Specifically, what about these AGP-related ioctl calls? Can they be > > >> declared as legacy? It would appear to me that

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Mon, 11 May 2020 at 21:43, Dave Airlie wrote: > > On Tue, 12 May 2020 at 06:28, Alex Deucher wrote: > > > > On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir > > wrote: > > > > > > On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote: > > > > Hi guys, > > > > > > > Well let's face it AGP

Re: [PATCH 06/36] drm/amdgpu: use the unlocked drm_gem_object_put

On Fri, 8 May 2020 at 09:16, Christian König wrote: > > Am 07.05.20 um 20:03 schrieb Sam Ravnborg: > > Hi Emil. > > > > On Thu, May 07, 2020 at 04:07:52PM +0100, Emil Velikov wrote: > >> From: Emil Velikov > >> > >> The driver does n

[PATCH 06/36] drm/amdgpu: use the unlocked drm_gem_object_put

From: Emil Velikov The driver does not hold struct_mutex, thus using the locked version of the helper is incorrect. Cc: Alex Deucher Cc: Christian König Cc: amd-gfx@lists.freedesktop.org Fixes: a39414716ca0 ("drm/amdgpu: add independent DMA-buf import v9"): Signed-off-by: Em

Re: [PATCH 2/3] drm/radeon: Inline drm_get_pci_dev

On Sat, 22 Feb 2020 at 17:54, Daniel Vetter wrote: > > It's the last user, and more importantly, it's the last non-legacy > user of anything in drm_pci.c. > > The only tricky bit is the agp initialization. But a close look shows > that radeon does not use the drm_agp midlayer (the main use of

Re: [PATCH 5/5] drm: drop DRM_AUTH from PRIME_TO/FROM_HANDLE ioctls

On Wed, 27 Nov 2019 at 18:37, Daniel Vetter wrote: > > On Wed, Nov 27, 2019 at 06:32:56PM +, Emil Velikov wrote: > > On Wed, 27 Nov 2019 at 18:04, Daniel Vetter wrote: > > > > > > On Wed, Nov 27, 2019 at 04:27:29PM +, Emil Velikov wrote: > > >

Re: [PATCH 5/5] drm: drop DRM_AUTH from PRIME_TO/FROM_HANDLE ioctls

On Wed, 27 Nov 2019 at 18:04, Daniel Vetter wrote: > > On Wed, Nov 27, 2019 at 04:27:29PM +, Emil Velikov wrote: > > On Wed, 27 Nov 2019 at 07:41, Boris Brezillon > > wrote: > > > > > > Hi Emil, > > > > > > On Fri, 1 Nov 2019 13:03:

Re: [PATCH 5/5] drm: drop DRM_AUTH from PRIME_TO/FROM_HANDLE ioctls

On Wed, 27 Nov 2019 at 07:41, Boris Brezillon wrote: > > Hi Emil, > > On Fri, 1 Nov 2019 13:03:13 + > Emil Velikov wrote: > > > From: Emil Velikov > > > > As mentioned by Christian, for drivers which support only primary nodes > > th

[PATCH v2] drm: drop DRM_AUTH from PRIME_TO/FROM_HANDLE ioctls

From: Emil Velikov Current validation requires that we're authenticated, even though we can bypass (by design) the authentication when using a render node. Let's address the former by following the design decision. v2: Add simpler validation in the ioctls themselves (Boris) Cc: Alex Deucher

Re: [PATCH 5/5] drm: drop DRM_AUTH from PRIME_TO/FROM_HANDLE ioctls

On Fri, 1 Nov 2019 at 13:05, Emil Velikov wrote: > > From: Emil Velikov > > As mentioned by Christian, for drivers which support only primary nodes > this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS. > > For others, this check in particular will be a

[PATCH 5/5] drm: drop DRM_AUTH from PRIME_TO/FROM_HANDLE ioctls

From: Emil Velikov As mentioned by Christian, for drivers which support only primary nodes this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS. For others, this check in particular will be a noop. So let's remove it as suggested by Christian. Cc: Alex Deucher Cc: amd-gfx

[PATCH v2 2/2] drm: drop DRM_AUTH from PRIME_TO/FROM_HANDLE ioctls

From: Emil Velikov As mentioned by Christian, for drivers which support only primary nodes this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS. For others, this check in particular will be a noop. So let's remove it as suggested by Christian. Cc: Alex Deucher Cc: amd-gfx

[PATCH 3/3] drm: drop DRM_AUTH from PRIME_TO/FROM_HANDLE ioctls

From: Emil Velikov As mentioned by Christian, for drivers which support only primary nodes this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS. For others, this check in particular will be a noop. So let's remove it as suggested by Christian. Cc: Alex Deucher Cc: Christian

Re: [PATCH v3 05/24] drm/amdgpu: remove memset after kzalloc

On 2019/07/15, Fuqian Huang wrote: > kzalloc has already zeroed the memory during the allocation. > So memset is unneeded. > > Signed-off-by: Fuqian Huang > --- > Changes in v3: > - Fix subject prefix: gpu/drm -> drm/amdgpu > Reviewed-by: Emil Velikov -Emil

Re: [PATCH 06/30] drm/amdgpu: Use kmemdup rather than duplicating its implementation

eads to smaller code and also reduce the chances of mistakes. > Suggestion to use kmemdup rather than using kmalloc/kzalloc + memset. > > Signed-off-by: Fuqian Huang Fuqian please add reviewed-by and other tags when sending new revisions. Fwiw the patch is: Reviewed-

Re: [PATCH 2/3] drm: introduce DRIVER_FORCE_AUTH

On Wed, 3 Jul 2019 at 15:58, Koenig, Christian wrote: > Am 03.07.2019 16:51 schrieb Emil Velikov : > > On Wed, 3 Jul 2019 at 15:33, Koenig, Christian > wrote: > > Am 03.07.2019 16:00 schrieb Emil Velikov : > > > > On Wed, 3 Jul 2019 at 14:48, Koenig, Christian

Re: [PATCH 2/3] drm: introduce DRIVER_FORCE_AUTH

On Wed, 3 Jul 2019 at 15:33, Koenig, Christian wrote: > Am 03.07.2019 16:00 schrieb Emil Velikov : > > On Wed, 3 Jul 2019 at 14:48, Koenig, Christian > wrote: > > > > Well this is still a NAK. > > > > As stated previously please just don't remove DRM_

Re: [PATCH 2/3] drm: introduce DRIVER_FORCE_AUTH

On Wed, 3 Jul 2019 at 14:48, Koenig, Christian wrote: > > Well this is still a NAK. > > As stated previously please just don't remove DRM_AUTH and keep the > functionality as it is. > AFAICT nobody was in favour of your suggestion to remove DRM_AUTH from the handle to/from fd ioclts. Thus this

[PATCH 2/3] drm: introduce DRIVER_FORCE_AUTH

From: Emil Velikov With earlier commits we've removed DRM_AUTH for driver ioctls annotated with DRM_AUTH | DRM_RENDER_ALLOW, as the protection it introduces is effectively not existent. With next commit, we'll effectively do the same for DRM core. Yet the AMD developers have voiced concerns

Re: [PATCH] drm/amdgpu: extend AMDGPU_CTX_PRIORITY_NORMAL comment

On Fri, 14 Jun 2019 at 19:02, Koenig, Christian wrote: > > Am 14.06.19 um 19:33 schrieb Emil Velikov: > > From: Emil Velikov > > > > Currently the AMDGPU_CTX_PRIORITY_* defines are used in both > > drm_amdgpu_ctx_in::priority and drm_amdgpu_sched_in::priori

Re: [PATCH v3 00/22] Associate ddc adapters with connectors

On Fri, 28 Jun 2019 at 17:45, Daniel Vetter wrote: > > On Fri, Jun 28, 2019 at 06:01:14PM +0200, Andrzej Pietrasiewicz wrote: > > It is difficult for a user to know which of the i2c adapters is for which > > drm connector. This series addresses this problem. > > > > The idea is to have a symbolic

Re: [PATCH v2 07/27] gpu: drm: remove memset after zalloc

; Thanks for fixing these. One nit pick: the commit message should start with "drm/amdgpu:" as you can see from git log. With that: Reviewed-by: Emil Velikov -Emil ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 1/9] amdgpu: Pass file descriptor directly to amdgpu_close_kms_handle

hel Dänzer > --- > amdgpu/amdgpu_bo.c | 35 +++ > 1 file changed, 15 insertions(+), 20 deletions(-) > Fwiw patches 1-3 are: Reviewed-by: Emil Velikov -Emil ___ amd-gfx mailing list amd-gfx@lists.freedesktop.or

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/06/21, Koenig, Christian wrote: > Am 21.06.19 um 13:58 schrieb Emil Velikov: > > On 2019/06/21, Koenig, Christian wrote: > >> Am 21.06.19 um 12:53 schrieb Emil Velikov: > >>> On 2019/06/21, Koenig, Christian wrote: > >>>> [SNIP] > >>>

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

, 2019 at 12:31 PM Koenig, Christian > > > > wrote: > > > >> Am 21.06.19 um 12:20 schrieb Emil Velikov: > > > >>> In particular, that user-space will "remove" render nodes. > > > >> Yes, that is my main concern here. You basically m

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/06/21, Koenig, Christian wrote: > Am 21.06.19 um 12:53 schrieb Emil Velikov: > > On 2019/06/21, Koenig, Christian wrote: > >> [SNIP] > >> Well partially. That RADV broke is unfortunate, but we have done so many > >> customized userspace stuff both

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/06/21, Koenig, Christian wrote: > No this should apply to all drivers, not just amdgpu. > > > While I suggested: > > - keeping amdgpu consistent with the rest > > - exposing the KConfig option for the whole of the kernel, and > > - merging it alongside this work > > > > So I

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/06/21, Daniel Vetter wrote: > On Fri, Jun 21, 2019 at 11:25 AM Koenig, Christian > wrote: > > > > Am 21.06.19 um 11:09 schrieb Daniel Vetter: > > > On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote: > > >> Am 20.06.19 um 18:30 schr

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/06/14, Koenig, Christian wrote: > Am 14.06.19 um 17:53 schrieb Emil Velikov: > > On 2019/06/14, Koenig, Christian wrote: > >> Am 14.06.19 um 14:09 schrieb Emil Velikov: > >>> On 2019/05/27, Emil Velikov wrote: > >>> [SNIP] > >>> Hi

Re: [PATCH 06/59] drm/prime: Actually remove DRIVER_PRIME everywhere

On 2019/06/14, Daniel Vetter wrote: > Split out to make the functional changes stick out more. > Since this patch flew-by, as standalone one (intentionally or not) I'd add, anything vaguely like: "Core users of DRIVER_PRIME were removed from core with prior patches." HTH Emil

[PATCH] drm/amdgpu: extend AMDGPU_CTX_PRIORITY_NORMAL comment

From: Emil Velikov Currently the AMDGPU_CTX_PRIORITY_* defines are used in both drm_amdgpu_ctx_in::priority and drm_amdgpu_sched_in::priority. Extend the comment to mention the CAP_SYS_NICE or DRM_MASTER requirement is only applicable with the former. Cc: Bas Nieuwenhuizen Cc: Christian König

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/06/14, Koenig, Christian wrote: > Am 14.06.19 um 17:53 schrieb Emil Velikov: > > On 2019/06/14, Koenig, Christian wrote: > >> Am 14.06.19 um 14:09 schrieb Emil Velikov: > >>> On 2019/05/27, Emil Velikov wrote: > >>> [SNIP] > >>> Hi

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/06/14, Koenig, Christian wrote: > Am 14.06.19 um 14:09 schrieb Emil Velikov: > > On 2019/05/27, Emil Velikov wrote: > > [SNIP] > > Hi Christian, > > > > > > In the following, I would like to summarise and emphasize the need for > > DRM_AUTH remo

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/27, Emil Velikov wrote: > From: Emil Velikov > > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the > render node. A seemingly deliberate design decision. > > Hence we can drop the DRM_AUTH all together (details in follow-up patch) > yet not

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/31, Koenig, Christian wrote: > Am 29.05.19 um 18:29 schrieb Emil Velikov: > > On 2019/05/29, Koenig, Christian wrote: > >> Am 29.05.19 um 15:03 schrieb Emil Velikov: > >>> On 2019/05/29, Dave Airlie wrote: > >>>> On Wed, 29 May 2019 at 02:47,

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/29, Koenig, Christian wrote: > Am 29.05.19 um 15:03 schrieb Emil Velikov: > > On 2019/05/29, Dave Airlie wrote: > >> On Wed, 29 May 2019 at 02:47, Emil Velikov > >> wrote: > >>> On 2019/05/28, Koenig, Christian wrote: > >>>> Am 2

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/29, Dave Airlie wrote: > On Wed, 29 May 2019 at 02:47, Emil Velikov wrote: > > > > On 2019/05/28, Koenig, Christian wrote: > > > Am 28.05.19 um 18:10 schrieb Emil Velikov: > > > > On 2019/05/28, Daniel Vetter wrote: > > > >>

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/28, Koenig, Christian wrote: > Am 28.05.19 um 18:10 schrieb Emil Velikov: > > On 2019/05/28, Daniel Vetter wrote: > >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian > >> wrote: > >>> Am 28.05.19 um 09:38 schrieb Daniel Vetter: > >&g

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/28, Daniel Vetter wrote: > On Tue, May 28, 2019 at 10:03 AM Koenig, Christian > wrote: > > > > Am 28.05.19 um 09:38 schrieb Daniel Vetter: > > > [SNIP] > > >> Might be a good idea looking into reverting it partially, so that at > > >> least command submission and buffer allocation is

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/27, Koenig, Christian wrote: > Am 27.05.19 um 15:26 schrieb Emil Velikov: > > On 2019/05/27, Daniel Vetter wrote: > >> On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote: > >>> Am 27.05.19 um 10:17 schrieb Emil Velikov: > >>>>

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/27, Daniel Vetter wrote: > On Mon, May 27, 2019 at 09:17:29AM +0100, Emil Velikov wrote: > > From: Emil Velikov > > > > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the > > render node. A seemingly deliberate design decision.

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/27, Daniel Vetter wrote: > On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote: > > Am 27.05.19 um 10:17 schrieb Emil Velikov: > > > From: Emil Velikov > > > > > > Currently one can circumvent DRM_AUTH, when the ioctl is exposed vi

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/27, Koenig, Christian wrote: > Am 27.05.19 um 14:05 schrieb Emil Velikov: > > On 2019/05/27, Koenig, Christian wrote: > >> Am 27.05.19 um 10:17 schrieb Emil Velikov: > >>> From: Emil Velikov > >>> > >>> Currently one

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/27, Koenig, Christian wrote: > Am 27.05.19 um 10:17 schrieb Emil Velikov: > > From: Emil Velikov > > > > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the > > render node. A seemingly deliberate design decision. > > > > Henc

[PATCH 02/13] drm/amdgpu: drop DRM_AUTH usage from the driver

From: Emil Velikov The authentication can be circumvented, by design, by using the render node. From the driver POV htere is no distinction between primary and render nodes, thus we can drop the token. Note: authentication is required on a single ioctl, due to a bug in userspace. The issue has

[PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

From: Emil Velikov Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the render node. A seemingly deliberate design decision. Hence we can drop the DRM_AUTH all together (details in follow-up patch) yet not all userspace checks if it's authenticated, but instead uses uncommon

[PATCH 10/13] drm/radeon: drop DRM_AUTH from DRM_RENDER_ALLOW ioctls

From: Emil Velikov The authentication can be circumvented, by design, by using the render node. From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Note: the outstanding DRM_AUTH instances are: - legacy DRI1 ioctls, which are already

Re: [PATCH libdrm] libdrm: Fix issue about differrent domainID but same BDF

On Mon, 25 Feb 2019 at 19:53, Deucher, Alexander wrote: > > > -Original Message- > > From: amd-gfx On Behalf Of Emil > > Velikov > > Sent: Monday, February 25, 2019 8:09 AM > > To: Alex Deucher > > Cc: Deng, Emily ; Maling list - DRI developers

Re: [PATCH libdrm] libdrm: Fix issue about differrent domainID but same BDF

Hi all, This patch causes unnecessary round trip by openning the nodes. As mentioned previously this could be trivially fixed [1]. Even Emily acknowledged that [1], yet the sub-par fix was merged. Can we revert+fixup this properly? Thanks Emil [1]

Re: [PATCH libdrm] libdrm: Fix issue about differrent domainID but same BDF

Hi Emily, Please note that code outside of amdgpu/ is used by all open source drivers. Thus patches should have dri-deve@ in to/cc as mentioned in CONTRIBUTING On Thu, 14 Feb 2019 at 07:53, Emily Deng wrote: > > For multiple GPUs which has the same BDF, but has different domain ID, > the

Re: [PATCH 01/26] drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install

> drivers/gpu/drm/vc4/vc4_drv.c| 1 - > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- > drivers/staging/vboxvideo/vbox_drv.c | 2 +- Local grep shows one more non-legacy entry in drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c With that file addressed and trivial comm

Re: [PATCH libdrm 1/5] [libdrm] new syncobj extension

Hi Chunming Zhou, On Fri, 2 Nov 2018 at 08:27, Chunming Zhou wrote: > > Signed-off-by: Chunming Zhou > --- > include/drm/drm.h | 38 ++ Please read through include/drm/README about how include/drm/ should be updated. Thanks Emil

Re: [PATCH] drm/amdgpu: Remove dead static variable

On Mon, 19 Nov 2018 at 11:19, Christian König wrote: > > Am 19.11.18 um 12:07 schrieb Rex Zhu: > > The static struct drm_driver *driver was > > not used because drm_pci_init was deprecated > > > > Signed-off-by: Rex Zhu > > Reviewed-by: Christian König > > Can you of hand see what "pdriver" is

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

On Sun, 30 Sep 2018 at 18:31, Thomas Hellstrom wrote: > > Hi, Emil, > > On 09/05/2018 03:53 PM, Emil Velikov wrote: > > On 5 September 2018 at 14:20, Thomas Hellstrom > > wrote: > > > >>> In that case, please give me 24h to do a libdrm releas

Re: [PATCH libdrm 2/5] [libdrm] addr cs chunk for syncobj timeline

On Wed, 19 Sep 2018 at 10:31, Chunming Zhou wrote: > > Signed-off-by: Chunming Zhou > --- > include/drm/amdgpu_drm.h | 10 ++ > 1 file changed, 10 insertions(+) > For this and 1/5 - see include/drm/README and git log for examples how files in include/drm should be updated. I'll pull

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

On 5 September 2018 at 14:20, Thomas Hellstrom wrote: >> In that case, please give me 24h to do a libdrm release before pushing. >> I had to push some workarounds for the sandboxing mentioned earlier :-\ >> >> Thanks >> Emil > > > Ouch, I just pushed the patch, but feel free to cut the release

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

On 5 September 2018 at 11:10, Thomas Hellstrom wrote: > Hi, Emil, > > > On 09/05/2018 11:33 AM, Emil Velikov wrote: >> >> On 4 September 2018 at 23:33, Dave Airlie wrote: >>> >>> On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom >>> wrote: &g

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

mas Hellstrom wrote: >> >>> On 08/31/2018 05:27 PM, Emil Velikov wrote: >> >>>> On 31 August 2018 at 15:38, Michel Dänzer wrote: >> >>>>> [ Adding the amd-gfx list ] >> >>>>> >> >>>>> On 2018-08-31 3:

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

On 31 August 2018 at 15:38, Michel Dänzer wrote: > > [ Adding the amd-gfx list ] > > On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>> On 31 August 2018 at 12:54, Thomas Hellstrom >>> wrote: >>>> To

Re: RFC: Migration to Gitlab

Hi Dan, On 22 August 2018 at 12:44, Daniel Vetter wrote: > Hi all, > > I think it's time to brainstorm a bit about the gitlab migration. Basic > reasons: > > - fd.o admins want to deprecate shell accounts and hand-rolled > infrastructure, because it's a pain to keep secure > > - gitlab will

Re: [PATCH xf86-video-amdgpu 03/19] Use ODEV_ATTRIB_PATH where possible for the device node.

On 10 April 2018 at 09:27, Michel Dänzer <mic...@daenzer.net> wrote: > On 2018-04-04 04:29 PM, Emil Velikov wrote: >> From: Emil Velikov <emil.veli...@collabora.com> >> >> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> >> --- >>

Re: [PATCH xf86-video-amdgpu 04/19] Remove drmCheckModesettingSupported and kernel module loading

On 10 April 2018 at 10:27, Michel Dänzer <mic...@daenzer.net> wrote: > On 2018-04-10 11:20 AM, Emil Velikov wrote: >> On 10 April 2018 at 09:26, Michel Dänzer <mic...@daenzer.net> wrote: >>> On 2018-04-04 04:29 PM, Emil Velikov wrote: >>>> From

Re: [PATCH xf86-video-amdgpu 11/19] Don't leak a AMDGPUEntRec instance if amdgpu_device_setup fails

On 10 April 2018 at 10:58, Michel Dänzer <mic...@daenzer.net> wrote: > On 2018-04-10 11:47 AM, Emil Velikov wrote: >> On 10 April 2018 at 09:28, Michel Dänzer <mic...@daenzer.net> wrote: >>> On 2018-04-04 04:29 PM, Emil Velikov wrote: >>>> From

Re: [PATCH xf86-video-amdgpu 19/19] TODO

On 10 April 2018 at 09:30, Michel Dänzer <mic...@daenzer.net> wrote: > On 2018-04-04 04:29 PM, Emil Velikov wrote: >> From: Emil Velikov <emil.veli...@collabora.com> >> >> Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com> >> --- >>

Re: [PATCH xf86-video-amdgpu 17/19] Store device_name as AMDGPUEntRec::master_node

On 10 April 2018 at 09:29, Michel Dänzer <mic...@daenzer.net> wrote: > On 2018-04-04 04:29 PM, Emil Velikov wrote: >> From: Emil Velikov <emil.veli...@collabora.com> >> >> Rename the variable to reflect what it is. Plus move it out of the dri2 >> section - i

Re: [PATCH xf86-video-amdgpu 11/19] Don't leak a AMDGPUEntRec instance if amdgpu_device_setup fails

On 10 April 2018 at 09:28, Michel Dänzer <mic...@daenzer.net> wrote: > On 2018-04-04 04:29 PM, Emil Velikov wrote: >> From: Emil Velikov <emil.veli...@collabora.com> >> >> Seems like we've been leaking this for years. It became more obvious >> with the recent

Re: [PATCH xf86-video-amdgpu 02/19] Guard ODEV_ATTRIB_FD usage with the correct ifdef

On 10 April 2018 at 09:27, Michel Dänzer <mic...@daenzer.net> wrote: > On 2018-04-04 04:29 PM, Emil Velikov wrote: >> From: Emil Velikov <emil.veli...@collabora.com> >> >> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> >> --- >> src/am

Re: [PATCH xf86-video-amdgpu 04/19] Remove drmCheckModesettingSupported and kernel module loading

On 10 April 2018 at 09:26, Michel Dänzer <mic...@daenzer.net> wrote: > On 2018-04-04 04:29 PM, Emil Velikov wrote: >> From: Emil Velikov <emil.veli...@collabora.com> >> >> The former of these is a UMS artefact which gives incorrect and >> mislea

[PATCH xf86-video-amdgpu 09/19] Remove error handling on xnfcalloc()

From: Emil Velikov <emil.veli...@collabora.com> The function "cannot fail", thus we'll never hit the error path. Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_probe.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/amdgpu_probe.c b/sr

[PATCH xf86-video-amdgpu 12/19] Remove ancient "pointer" macro

From: Emil Velikov <emil.veli...@collabora.com> Use "void *" over the macro. Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- Worth splitting this into separate patches and/or keeping compat-api.h as-is? --- src/amdgpu_dri2.c| 4 ++-- src/amdgpu

[PATCH xf86-video-amdgpu 11/19] Don't leak a AMDGPUEntRec instance if amdgpu_device_setup fails

From: Emil Velikov <emil.veli...@collabora.com> Seems like we've been leaking this for years. It became more obvious with the recent refactoring. Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_probe.c | 2 ++ 1 file changed, 2 insertions(+) diff

[PATCH xf86-video-amdgpu 13/19] configure: check for XORG_DRIVER_CHECK_EXT prior to using it

From: Emil Velikov <emil.veli...@collabora.com> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- Noticed while skimming through the intel driver - haven't came across this while building the amdgpu driver. --- configure.ac | 6 ++ 1 file changed, 6 insertions(+)

[PATCH xf86-video-amdgpu 19/19] TODO

From: Emil Velikov <emil.veli...@collabora.com> Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com> --- todo | 9 + 1 file changed, 9 insertions(+) create mode 100644 todo diff --git a/todo b/todo new file mode 100644 index 000..10c1ad5 --- /dev/null +++ b/todo

[PATCH xf86-video-amdgpu 14/19] Do not export gAMDGPUEntityIndex

From: Emil Velikov <emil.veli...@collabora.com> The modules should not export anything but a single *ModuleData symbol. Seemingly a copy/paste mistake from the radeon driver. Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- I'm aroung 70% sure on this one. Yet again, p

[PATCH xf86-video-amdgpu 10/19] Remove unneeded xf86GetEntityInfo() call

From: Emil Velikov <emil.veli...@collabora.com> We only use ent->index, which is the same as the argument fed into the function. Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- Note: I'm not 100% sure if the X API guarantees that, yet it seems to be the case f

[PATCH xf86-video-amdgpu 18/19] Keep track of who owns the fd in AMDGPUEnt

From: Emil Velikov <emil.veli...@collabora.com> Currently we're having xf86_platform_device pointer embedded, alongside a bunch of ifdef compiler guards. Swap that with a simple is_server_fd bool ;-) Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_

[PATCH xf86-video-amdgpu 15/19] Do not export the DriverRec AMDGPU

From: Emil Velikov <emil.veli...@collabora.com> Analogous to previous commit - unused externally and should not be exported. Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_probe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/amdg

[PATCH xf86-video-amdgpu 04/19] Remove drmCheckModesettingSupported and kernel module loading

From: Emil Velikov <emil.veli...@collabora.com> The former of these is a UMS artefact which gives incorrect and misleading promise whether "KMS" is supported. Not to mention that AMDGPU is a only KMS driver. In a similar fashion xf86LoadKernelModule() is a relic of the times, whe

[PATCH xf86-video-amdgpu 02/19] Guard ODEV_ATTRIB_FD usage with the correct ifdef

From: Emil Velikov <emil.veli...@collabora.com> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_probe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/amdgpu_probe.c b/src/amdgpu_probe.c index 075e5c1..e65c83b 100644 --- a/src/amdgpu_p

[PATCH xf86-video-amdgpu 16/19] Remove set but unused amdgpu_dri2::pKernelDRMVersion

From: Emil Velikov <emil.veli...@collabora.com> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_dri2.h | 1 - src/amdgpu_kms.c | 6 -- 2 files changed, 7 deletions(-) diff --git a/src/amdgpu_dri2.h b/src/amdgpu_dri2.h index c6a2ab6..a345e6b 1006

[PATCH xf86-video-amdgpu 17/19] Store device_name as AMDGPUEntRec::master_node

From: Emil Velikov <emil.veli...@collabora.com> Rename the variable to reflect what it is. Plus move it out of the dri2 section - it's used in dri2 and dri3. Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_dri2.c | 8 +--- src/amdgpu_dri2.h | 1 - src/a

[PATCH xf86-video-amdgpu 06/19] Introduce amdgpu_device_setup helper

From: Emil Velikov <emil.veli...@collabora.com> It folds the device specifics (open fd, device init) into a single place. Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_probe.c | 66 -- 1 file changed, 3

[PATCH xf86-video-amdgpu 01/19] Move amdgpu_bus_id/amgpu_kernel_mode within amdgpu_kernel_open_fd

From: Emil Velikov <emil.veli...@collabora.com> Small step towards unifying the code paths and removing a handful of duplication. Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_probe.c | 45 +++-- 1 file changed, 2

[PATCH xf86-video-amdgpu 03/19] Use ODEV_ATTRIB_PATH where possible for the device node.

From: Emil Velikov <emil.veli...@collabora.com> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_probe.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/src/amdgpu_probe.c b/src/amdgpu_probe.c index e65c83b..78cc005 1006

[PATCH xf86-video-amdgpu 08/19] Simplify fd_ref handling in amdgpu_probe()

From: Emil Velikov <emil.veli...@collabora.com> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_probe.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/src/amdgpu_probe.c b/src/amdgpu_probe.c index d1ad13f..8a16060 1006

[PATCH xf86-video-amdgpu 07/19] Factor out common code to amdgpu_probe()

From: Emil Velikov <emil.veli...@collabora.com> Keep the distinct pci/platform screen management in the separate probe entry point and fold the rest into a single function. Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- src/amdgpu_

[PATCH xf86-video-amdgpu 00/19] Removing UMS remnants and assorted patches

the {pci,platform}_probe duplication To top it up there's a TODO as 'Patch' 19. It mostly seeks to gather feedback on the items listed. As always, input is greatly appreciated. Thanks Emil Emil Velikov (19): Move amdgpu_bus_id/amgpu_kernel_mode within amdgpu_kernel_open_fd Guard

[PATCH xf86-video-amdgpu 05/19] Kill off drmOpen/Close/drmSetInterfaceVersion in favour of drmDevices

From: Emil Velikov <emil.veli...@collabora.com> The former has very subtle semantics (see the implementation in libdrm for details) which were required in the UMS days. With drmDevices around, we have enough information to build our heuristics and avoid drmOpen all together. Signed-off-by

Re: [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

On 22 March 2018 at 18:03, Harry Wentland <harry.wentl...@amd.com> wrote: > On 2018-03-22 01:54 PM, Emil Velikov wrote: >> Hi Ville, >> >> On 22 March 2018 at 15:22, Ville Syrjala <ville.syrj...@linux.intel.com> >> wrote: >>> From: Ville Syrjälä

Re: [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

Hi Ville, On 22 March 2018 at 15:22, Ville Syrjala wrote: > From: Ville Syrjälä > > I really just wanted to fix i915 to re-enable its planes afer load > detection (a two line patch). This is what I actually ended up with > after I

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

On 20 February 2018 at 13:12, Peter Zijlstra wrote: > On Tue, Feb 20, 2018 at 01:58:26PM +0100, Christian König wrote: >> amdgpu needs to verify if userspace sends us valid addresses and the simplest >> way of doing this is to check if the buffer object is locked with the

  1   2   >