drm/vgem: Fix vgem_init to get drm device avaliable.

Commit Message

Deepak Sharma Oct. 25, 2017, 11:02 p.m. UTC

From: Deepak Sharma <[e-mail]>

Modify vgem_init to take platform dev as parent in drm_dev_init.
This will make drm device available at "/sys/devices/platform/vgem"
in x86 chromebook.

Signed-off-by: Deepak Sharma <[e-mail]>
---
 drivers/gpu/drm/vgem/vgem_drv.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

Comments

Sean Paul Oct. 30, 2017, 1:03 p.m. UTC | #1

On Wed, Oct 25, 2017 at 04:02:26PM -0700, Deepak Sharma wrote:
> From: Deepak Sharma <[e-mail]>
> 
> Modify vgem_init to take platform dev as parent in drm_dev_init.
> This will make drm device available at "/sys/devices/platform/vgem"
> in x86 chromebook.
> 
> Signed-off-by: Deepak Sharma <[e-mail]>

Reviewed-by: Sean Paul <[e-mail]>

> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 15 +++++++--------
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index c938af8c40cf..17e2eafc62b8 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -471,31 +471,30 @@ static int __init vgem_init(void)
>  	if (!vgem_device)
>  		return -ENOMEM;
>  
> -	ret = drm_dev_init(&vgem_device->drm, &vgem_driver, NULL);
> -	if (ret)
> -		goto out_free;
> -
>  	vgem_device->platform =
>  		platform_device_register_simple("vgem", -1, NULL, 0);
>  	if (IS_ERR(vgem_device->platform)) {
>  		ret = PTR_ERR(vgem_device->platform);
> -		goto out_fini;
> +		goto out_free;
>  	}
>  
>  	dma_coerce_mask_and_coherent(&vgem_device->platform->dev,
>  				     DMA_BIT_MASK(64));
> +	ret = drm_dev_init(&vgem_device->drm, &vgem_driver, &vgem_device->platform->dev);
> +	if (ret)
> +		goto out_unregister;
>  
>  	/* Final step: expose the device/driver to userspace */
>  	ret  = drm_dev_register(&vgem_device->drm, 0);
>  	if (ret)
> -		goto out_unregister;
> +		goto out_fini;
>  
>  	return 0;
>  
> -out_unregister:
> -	platform_device_unregister(vgem_device->platform);
>  out_fini:
>  	drm_dev_fini(&vgem_device->drm);
> +out_unregister:
> +	platform_device_unregister(vgem_device->platform);
>  out_free:
>  	kfree(vgem_device);
>  	return ret;
> -- 
> 2.14.2
> 
> _______________________________________________
> dri-devel mailing list
> [e-mail]
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Emil Velikov Oct. 30, 2017, 1:23 p.m. UTC | #2

On 26 October 2017 at 00:02, Deepak Sharma <[e-mail]> wrote:
> From: Deepak Sharma <[e-mail]>
>
> Modify vgem_init to take platform dev as parent in drm_dev_init.
> This will make drm device available at "/sys/devices/platform/vgem"
> in x86 chromebook.
>
Shouldn't one update the drm_dev_init/drm_dev_alloc documentation
while doing this?
But more importantly, this will change the "unique" string (see
drm_dev_set_unique).

The topic around it rather convoluted and messy, so please check this
change doesn't cause subtle regressions.
There's a doc hunk in drm_ioctl.c to begin with, plus userspace such
as IGT [1] might rely on the current behaviour.

HTH
Emil

[1] https://cgit.freedesktop.org/drm/igt-gpu-tools/

Deepak Sharma Nov. 9, 2017, 11:46 p.m. UTC | #3

-----Original Message-----
From: Emil Velikov [mailto:[e-mail]] 

Sent: Monday, October 30, 2017 6:23 AM
To: Sharma, Deepak <[e-mail]>
Cc: ML dri-devel <[e-mail]>; Deucher, Alexander <[e-mail]>; Stéphane Marchesin <[e-mail]>
Subject: Re: [PATCH] drm/vgem: Fix vgem_init to get drm device avaliable.

On 26 October 2017 at 00:02, Deepak Sharma <[e-mail]> wrote:
> From: Deepak Sharma <[e-mail]>

>

> Modify vgem_init to take platform dev as parent in drm_dev_init.

> This will make drm device available at "/sys/devices/platform/vgem"

> in x86 chromebook.

>

Shouldn't one update the drm_dev_init/drm_dev_alloc documentation while doing this?
But more importantly, this will change the "unique" string (see drm_dev_set_unique).

Sorry I did not get your comment about updating drm_dev_init/drm_dev_alloc documentation 
for this change. Do you see any issue if this "unique string " is changed

The topic around it rather convoluted and messy, so please check this change doesn't cause subtle regressions.
There's a doc hunk in drm_ioctl.c to begin with, plus userspace such as IGT [1] might rely on the current behaviour.

HTH
Emil

[1] https://cgit.freedesktop.org/drm/igt-gpu-tools/

I did run vgem test from IGT to check for regression , do you suspect regression in other tests ?

Thanks,
Deepak

Emil Velikov Nov. 10, 2017, 1:10 p.m. UTC | #4

On 9 November 2017 at 23:46, Sharma, Deepak <[e-mail]> wrote:

>>>
>>> Modify vgem_init to take platform dev as parent in drm_dev_init.
>>> This will make drm device available at "/sys/devices/platform/vgem"
>>> in x86 chromebook.
>>>
>> Shouldn't one update the drm_dev_init/drm_dev_alloc documentation while doing this?
>> But more importantly, this will change the "unique" string (see drm_dev_set_unique).
>
> Sorry I did not get your comment about updating drm_dev_init/drm_dev_alloc documentation
> for this change. Do you see any issue if this "unique string " is changed
>
VGEM is unlike other DRM drivers and I'm not sure if there is any
userspace that depends on the exact value.
If there's none - great.

I'd still recommend updating the two functions' documentation, ideally
coupled with enforcing for *parent to be non NULL.
Could be code as follow-up though.

>> The topic around it rather convoluted and messy, so please check this change doesn't cause subtle regressions.
>> There's a doc hunk in drm_ioctl.c to begin with, plus userspace such as IGT [1] might rely on the current behaviour.
>>
>> HTH
>> Emil
>
> [1] https://cgit.freedesktop.org/drm/igt-gpu-tools/
>
> I did run vgem test from IGT to check for regression , do you suspect regression in other tests ?
>
There are two vgem only and a handful of others. Quick grep shows:

tests/amdgpu/amd_prime.c
tests/gem_concurrent_all.c
tests/gem_exec_await.c
tests/gem_exec_fence.c
tests/gem_exec_latency.c
tests/gem_exec_schedule.c
tests/gem_ringfill.c
tests/gem_wait.c
tests/prime_vgem.c
tests/vgem_basic.c
tests/vgem_slow.c

Most of which use i915 <> vgem. If you don't have the HW to test, one
can use the Intel GFX trybot.
Just keep [1] in the To/CC list and you'll get a report with the results.

HTH
Emil

[1] [e-mail]

Deepak Sharma Nov. 15, 2017, 9:25 p.m. UTC | #5

-----Original Message-----
From: Emil Velikov [mailto:[e-mail]] 

Sent: Friday, November 10, 2017 5:11 AM
To: Sharma, Deepak <[e-mail]>
Cc: ML dri-devel <[e-mail]>; Deucher, Alexander <[e-mail]>; Stéphane Marchesin <[e-mail]>
Subject: Re: [PATCH] drm/vgem: Fix vgem_init to get drm device avaliable.

On 9 November 2017 at 23:46, Sharma, Deepak <[e-mail]> wrote:

>>>

>>> Modify vgem_init to take platform dev as parent in drm_dev_init.

>>> This will make drm device available at "/sys/devices/platform/vgem"

>>> in x86 chromebook.

>>>

>> Shouldn't one update the drm_dev_init/drm_dev_alloc documentation while doing this?

>> But more importantly, this will change the "unique" string (see drm_dev_set_unique).

>

> Sorry I did not get your comment about updating 

> drm_dev_init/drm_dev_alloc documentation for this change. Do you see 

> any issue if this "unique string " is changed

>

VGEM is unlike other DRM drivers and I'm not sure if there is any userspace that depends on the exact value.
If there's none - great.

I'd still recommend updating the two functions' documentation, ideally coupled with enforcing for *parent to be non NULL.
Could be code as follow-up though.

If I got it correctly you are referring   "Note that for purely virtual devices @parent can be NULL" for said two functions.
I think changes might be required if it was "should/must be NULL"?

>> The topic around it rather convoluted and messy, so please check this change doesn't cause subtle regressions.

>> There's a doc hunk in drm_ioctl.c to begin with, plus userspace such as IGT [1] might rely on the current behaviour.

>>

>> HTH

>> Emil

>

> [1] https://cgit.freedesktop.org/drm/igt-gpu-tools/

>

> I did run vgem test from IGT to check for regression , do you suspect regression in other tests ?

>

There are two vgem only and a handful of others. Quick grep shows:

tests/amdgpu/amd_prime.c
tests/gem_concurrent_all.c
tests/gem_exec_await.c
tests/gem_exec_fence.c
tests/gem_exec_latency.c
tests/gem_exec_schedule.c
tests/gem_ringfill.c
tests/gem_wait.c
tests/prime_vgem.c
tests/vgem_basic.c
tests/vgem_slow.c

Most of which use i915 <> vgem. If you don't have the HW to test, one can use the Intel GFX trybot.
Just keep [1] in the To/CC list and you'll get a report with the results.

Thanks. I have added Intel GFX trybot in CC, that should be sufficient or I need to send patch again using git send-mail?

HTH
Emil

[1] [e-mail]

Emil Velikov Nov. 16, 2017, 3:40 p.m. UTC | #6

On 15 November 2017 at 21:25, Sharma, Deepak <[e-mail]> wrote:

>>
>> I'd still recommend updating the two functions' documentation, ideally coupled with enforcing for *parent to be non NULL.
>> Could be code as follow-up though.
>>
> If I got it correctly you are referring   "Note that for purely virtual devices @parent can be NULL" for said two functions.
> I think changes might be required if it was "should/must be NULL"?


Since you're changing the behaviour:
The statement "Note that for purely virtual devices @parent can be
NULL" is never true and should be dropped.

Additionally, you want to update the functions to error out when
parent is NULL since it indicates a driver bug.
For the drm_dev_set_unique hunk one can drop the comment (it's NA) and
simplify to:

ret = drm_dev_set_unique(dev, dev_name(parent));

As mentioned before - it can be code as follow-up.


>>
>> Most of which use i915 <> vgem. If you don't have the HW to test, one can use the Intel GFX trybot.
>> Just keep [1] in the To/CC list and you'll get a report with the results.
>>
>
> Thanks. I have added Intel GFX trybot in CC, that should be sufficient or I need to send patch again using git send-mail?
>
Right, should have been clearer - the actual patches should be send/cc'd.
Otherwise one has know way of retrieving (and thus testing) the patch ;-)

HTH
Emil

Deepak Sharma Nov. 20, 2017, 9:22 p.m. UTC | #7

I got your point . I can push follow up patch with document change and code update as discussed here. 
Keeping that I think this patch should be ok to land?

Thanks,
Deepak

-----Original Message-----
From: Emil Velikov [mailto:[e-mail]] 

Sent: Thursday, November 16, 2017 7:40 AM
To: Sharma, Deepak <[e-mail]>
Cc: ML dri-devel <[e-mail]>; Deucher, Alexander <[e-mail]>; Stéphane Marchesin <[e-mail]>; [e-mail]
Subject: Re: [PATCH] drm/vgem: Fix vgem_init to get drm device avaliable.

On 15 November 2017 at 21:25, Sharma, Deepak <[e-mail]> wrote:

>>

>> I'd still recommend updating the two functions' documentation, ideally coupled with enforcing for *parent to be non NULL.

>> Could be code as follow-up though.

>>

> If I got it correctly you are referring   "Note that for purely virtual devices @parent can be NULL" for said two functions.

> I think changes might be required if it was "should/must be NULL"?



Since you're changing the behaviour:
The statement "Note that for purely virtual devices @parent can be NULL" is never true and should be dropped.

Additionally, you want to update the functions to error out when parent is NULL since it indicates a driver bug.
For the drm_dev_set_unique hunk one can drop the comment (it's NA) and simplify to:

ret = drm_dev_set_unique(dev, dev_name(parent));

As mentioned before - it can be code as follow-up.


>>

>> Most of which use i915 <> vgem. If you don't have the HW to test, one can use the Intel GFX trybot.

>> Just keep [1] in the To/CC list and you'll get a report with the results.

>>

>

> Thanks. I have added Intel GFX trybot in CC, that should be sufficient or I need to send patch again using git send-mail?

>

Right, should have been clearer - the actual patches should be send/cc'd.
Otherwise one has know way of retrieving (and thus testing) the patch ;-)

HTH
Emil

Patch

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index c938af8c40cf..17e2eafc62b8 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -471,31 +471,30 @@  static int __init vgem_init(void)
 	if (!vgem_device)
 		return -ENOMEM;
 
-	ret = drm_dev_init(&vgem_device->drm, &vgem_driver, NULL);
-	if (ret)
-		goto out_free;
-
 	vgem_device->platform =
 		platform_device_register_simple("vgem", -1, NULL, 0);
 	if (IS_ERR(vgem_device->platform)) {
 		ret = PTR_ERR(vgem_device->platform);
-		goto out_fini;
+		goto out_free;
 	}
 
 	dma_coerce_mask_and_coherent(&vgem_device->platform->dev,
 				     DMA_BIT_MASK(64));
+	ret = drm_dev_init(&vgem_device->drm, &vgem_driver, &vgem_device->platform->dev);
+	if (ret)
+		goto out_unregister;
 
 	/* Final step: expose the device/driver to userspace */
 	ret  = drm_dev_register(&vgem_device->drm, 0);
 	if (ret)
-		goto out_unregister;
+		goto out_fini;
 
 	return 0;
 
-out_unregister:
-	platform_device_unregister(vgem_device->platform);
 out_fini:
 	drm_dev_fini(&vgem_device->drm);
+out_unregister:
+	platform_device_unregister(vgem_device->platform);
 out_free:
 	kfree(vgem_device);
 	return ret;