[PATCH] drm: don't call ->firstopen for KMS drivers

2013-07-22 Thread Laurent Pinchart 
Hi Daniel,

Thank you for the patch.

On Saturday 13 July 2013 16:45:10 Daniel Vetter wrote:
> It has way too much potential for driver writers to do stupid things
> like delayed hw setup because the load sequence is somehow racy (e.g.
> the imx driver in staging). So don't call it for modesetting drivers,
> which reduces the complexity of the drm core -> driver interface a
> notch.
> 
> v2: Don't forget to update DocBook.
> 
> v3: Go with Laurent's slightly more elaborate proposal for the DocBook
> update. Add a few words on top of his diff to elaborate a bit on what
> KMS drivers should and shouldn't do in lastclose. There was already a
> paragraph present talking about restoring properties, I've simply
> extended that one.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 

Acked-by: Laurent Pinchart 

> ---
>  Documentation/DocBook/drm.tmpl | 27 ---
>  drivers/gpu/drm/drm_fops.c |  3 ++-
>  2 files changed, 18 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 4d54ac8..52d5eda 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct
> drm_file *); 
>
>  The firstopen method is called by the DRM
> core -when an application opens a device that has no other opened file
> handle. - Similarly the lastclose method is 
called
> when -the last application holding a file handle opened on the device
> closes -  it. Both methods are mostly used for UMS (User Mode Setting)
> drivers to -  acquire and release device resources which should be done in
> the - load and unload
> - methods for KMS drivers.
> + for legacy UMS (User Mode Setting) drivers only when an application
> + opens a device that has no other opened file handle. UMS drivers can
> + implement it to acquire device resources. KMS drivers can't use the
> + method and must acquire resources in the load
> + method instead.
>
>
> -Note that the lastclose method is also
> called -  at module unload time or, for hot-pluggable devices, when the
> device is -   unplugged. The firstopen and
> + Similarly the lastclose method is called when
> + the last application holding a file handle opened on the device closes
> + it, for both UMS and KMS drivers. Additionally, the method is also
> + called at module unload time or, for hot-pluggable devices, when the
> + device is unplugged. The firstopen and
>   lastclose calls can thus be unbalanced.
>
>
> @@ -2462,7 +2462,12 @@ void (*postclose) (struct drm_device *, struct
> drm_file *); 
>  The lastclose method should restore CRTC
> and plane properties to default value, so that a subsequent open of the
> - device will not inherit state from the previous user.
> + device will not inherit state from the previous user. It can also be
> + used to execute delayed power switching state changes, e.g. in
> + conjunction with the vga-switcheroo infrastructure. Beyond that KMS
> + drivers should not do any further cleanup. Only legacy UMS drivers might
> + need to clean up device state so that the vga console or an independent
> + fbdev driver could take over.
>
>  
>  
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 57e3014..fcde7d4 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
>   int i;
>   int ret;
> 
> - if (dev->driver->firstopen) {
> + if (dev->driver->firstopen &&
> + !drm_core_check_feature(dev, DRIVER_MODESET)) {
>   ret = dev->driver->firstopen(dev);
>   if (ret != 0)
>   return ret;
-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: don't call -firstopen for KMS drivers

2013-07-22 Thread Laurent Pinchart 
Hi Daniel,

Thank you for the patch.

On Saturday 13 July 2013 16:45:10 Daniel Vetter wrote:
 It has way too much potential for driver writers to do stupid things
 like delayed hw setup because the load sequence is somehow racy (e.g.
 the imx driver in staging). So don't call it for modesetting drivers,
 which reduces the complexity of the drm core - driver interface a
 notch.
 
 v2: Don't forget to update DocBook.
 
 v3: Go with Laurent's slightly more elaborate proposal for the DocBook
 update. Add a few words on top of his diff to elaborate a bit on what
 KMS drivers should and shouldn't do in lastclose. There was already a
 paragraph present talking about restoring properties, I've simply
 extended that one.
 
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

 ---
  Documentation/DocBook/drm.tmpl | 27 ---
  drivers/gpu/drm/drm_fops.c |  3 ++-
  2 files changed, 18 insertions(+), 12 deletions(-)
 
 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 4d54ac8..52d5eda 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct
 drm_file *);/synopsis /abstract
para
  The methodnamefirstopen/methodname method is called by the DRM
 core -when an application opens a device that has no other opened file
 handle. - Similarly the methodnamelastclose/methodname method is 
called
 when -the last application holding a file handle opened on the device
 closes -  it. Both methods are mostly used for UMS (User Mode Setting)
 drivers to -  acquire and release device resources which should be done in
 the - methodnameload/methodname and methodnameunload/methodname
 - methods for KMS drivers.
 + for legacy UMS (User Mode Setting) drivers only when an application
 + opens a device that has no other opened file handle. UMS drivers can
 + implement it to acquire device resources. KMS drivers can't use the
 + method and must acquire resources in the methodnameload/methodname
 + method instead.
/para
para
 -Note that the methodnamelastclose/methodname method is also
 called -  at module unload time or, for hot-pluggable devices, when the
 device is -   unplugged. The methodnamefirstopen/methodname and
 + Similarly the methodnamelastclose/methodname method is called when
 + the last application holding a file handle opened on the device closes
 + it, for both UMS and KMS drivers. Additionally, the method is also
 + called at module unload time or, for hot-pluggable devices, when the
 + device is unplugged. The methodnamefirstopen/methodname and
   methodnamelastclose/methodname calls can thus be unbalanced.
/para
para
 @@ -2462,7 +2462,12 @@ void (*postclose) (struct drm_device *, struct
 drm_file *);/synopsis para
  The methodnamelastclose/methodname method should restore CRTC
 and plane properties to default value, so that a subsequent open of the
 - device will not inherit state from the previous user.
 + device will not inherit state from the previous user. It can also be
 + used to execute delayed power switching state changes, e.g. in
 + conjunction with the vga-switcheroo infrastructure. Beyond that KMS
 + drivers should not do any further cleanup. Only legacy UMS drivers might
 + need to clean up device state so that the vga console or an independent
 + fbdev driver could take over.
/para
  /sect2
  sect2
 diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 index 57e3014..fcde7d4 100644
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
   int i;
   int ret;
 
 - if (dev-driver-firstopen) {
 + if (dev-driver-firstopen 
 + !drm_core_check_feature(dev, DRIVER_MODESET)) {
   ret = dev-driver-firstopen(dev);
   if (ret != 0)
   return ret;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: don't call ->firstopen for KMS drivers

2013-07-13 Thread Daniel Vetter 
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.

v2: Don't forget to update DocBook.

v3: Go with Laurent's slightly more elaborate proposal for the DocBook
update. Add a few words on top of his diff to elaborate a bit on what
KMS drivers should and shouldn't do in lastclose. There was already a
paragraph present talking about restoring properties, I've simply
extended that one.

Cc: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/drm.tmpl | 27 ---
 drivers/gpu/drm/drm_fops.c |  3 ++-
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 4d54ac8..52d5eda 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct drm_file 
*);
   
   
 The firstopen method is called by the DRM core
-   when an application opens a device that has no other opened file handle.
-   Similarly the lastclose method is called when
-   the last application holding a file handle opened on the device closes
-   it. Both methods are mostly used for UMS (User Mode Setting) drivers to
-   acquire and release device resources which should be done in the
-   load and unload
-   methods for KMS drivers.
+   for legacy UMS (User Mode Setting) drivers only when an application
+   opens a device that has no other opened file handle. UMS drivers can
+   implement it to acquire device resources. KMS drivers can't use the
+   method and must acquire resources in the load
+   method instead.
   
   
-Note that the lastclose method is also called
-   at module unload time or, for hot-pluggable devices, when the device is
-   unplugged. The firstopen and
+   Similarly the lastclose method is called when
+   the last application holding a file handle opened on the device closes
+   it, for both UMS and KMS drivers. Additionally, the method is also
+   called at module unload time or, for hot-pluggable devices, when the
+   device is unplugged. The firstopen and
lastclose calls can thus be unbalanced.
   
   
@@ -2462,7 +2462,12 @@ void (*postclose) (struct drm_device *, struct drm_file 
*);
   
 The lastclose method should restore CRTC and
plane properties to default value, so that a subsequent open of the
-   device will not inherit state from the previous user.
+   device will not inherit state from the previous user. It can also be
+   used to execute delayed power switching state changes, e.g. in
+   conjunction with the vga-switcheroo infrastructure. Beyond that KMS
+   drivers should not do any further cleanup. Only legacy UMS drivers might
+   need to clean up device state so that the vga console or an independent
+   fbdev driver could take over.
   
 
 
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 57e3014..fcde7d4 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
int i;
int ret;

-   if (dev->driver->firstopen) {
+   if (dev->driver->firstopen &&
+   !drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = dev->driver->firstopen(dev);
if (ret != 0)
return ret;
-- 
1.8.3.2

[PATCH] drm: don't call -firstopen for KMS drivers

2013-07-13 Thread Daniel Vetter 
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core - driver interface a
notch.

v2: Don't forget to update DocBook.

v3: Go with Laurent's slightly more elaborate proposal for the DocBook
update. Add a few words on top of his diff to elaborate a bit on what
KMS drivers should and shouldn't do in lastclose. There was already a
paragraph present talking about restoring properties, I've simply
extended that one.

Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 Documentation/DocBook/drm.tmpl | 27 ---
 drivers/gpu/drm/drm_fops.c |  3 ++-
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 4d54ac8..52d5eda 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct drm_file 
*);/synopsis
   /abstract
   para
 The methodnamefirstopen/methodname method is called by the DRM core
-   when an application opens a device that has no other opened file handle.
-   Similarly the methodnamelastclose/methodname method is called when
-   the last application holding a file handle opened on the device closes
-   it. Both methods are mostly used for UMS (User Mode Setting) drivers to
-   acquire and release device resources which should be done in the
-   methodnameload/methodname and methodnameunload/methodname
-   methods for KMS drivers.
+   for legacy UMS (User Mode Setting) drivers only when an application
+   opens a device that has no other opened file handle. UMS drivers can
+   implement it to acquire device resources. KMS drivers can't use the
+   method and must acquire resources in the methodnameload/methodname
+   method instead.
   /para
   para
-Note that the methodnamelastclose/methodname method is also called
-   at module unload time or, for hot-pluggable devices, when the device is
-   unplugged. The methodnamefirstopen/methodname and
+   Similarly the methodnamelastclose/methodname method is called when
+   the last application holding a file handle opened on the device closes
+   it, for both UMS and KMS drivers. Additionally, the method is also
+   called at module unload time or, for hot-pluggable devices, when the
+   device is unplugged. The methodnamefirstopen/methodname and
methodnamelastclose/methodname calls can thus be unbalanced.
   /para
   para
@@ -2462,7 +2462,12 @@ void (*postclose) (struct drm_device *, struct drm_file 
*);/synopsis
   para
 The methodnamelastclose/methodname method should restore CRTC and
plane properties to default value, so that a subsequent open of the
-   device will not inherit state from the previous user.
+   device will not inherit state from the previous user. It can also be
+   used to execute delayed power switching state changes, e.g. in
+   conjunction with the vga-switcheroo infrastructure. Beyond that KMS
+   drivers should not do any further cleanup. Only legacy UMS drivers might
+   need to clean up device state so that the vga console or an independent
+   fbdev driver could take over.
   /para
 /sect2
 sect2
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 57e3014..fcde7d4 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
int i;
int ret;
 
-   if (dev-driver-firstopen) {
+   if (dev-driver-firstopen 
+   !drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = dev-driver-firstopen(dev);
if (ret != 0)
return ret;
-- 
1.8.3.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: don't call ->firstopen for KMS drivers

2013-07-11 Thread Daniel Vetter 
On Thu, Jul 11, 2013 at 9:54 AM, Laurent Pinchart
 wrote:
> Hi Daniel,
>
> On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
>> It has way too much potential for driver writers to do stupid things
>> like delayed hw setup because the load sequence is somehow racy (e.g.
>> the imx driver in staging). So don't call it for modesetting drivers,
>> which reduces the complexity of the drm core -> driver interface a
>> notch.
>>
>> v2: Don't forget to update DocBook.
>>
>> Cc: Laurent Pinchart 
>> Signed-off-by: Daniel Vetter 
>> ---
>>  Documentation/DocBook/drm.tmpl | 2 ++
>>  drivers/gpu/drm/drm_fops.c | 3 ++-
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
>> index 4d54ac8..0e8a5a3 100644
>> --- a/Documentation/DocBook/drm.tmpl
>> +++ b/Documentation/DocBook/drm.tmpl
>> @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
>> drm_file *); 
>>  The firstopen method is called by the DRM
>> core when an application opens a device that has no other opened file
>> handle.
>> + Not that this callback is only called for legacy ums drm drivers, not
>> + for drm drivers that implement modesetting in the kernel.
>>   Similarly the lastclose method is called when
>>   the last application holding a file handle opened on the device closes
>>   it. Both methods are mostly used for UMS (User Mode Setting) drivers to
>
> What about

So if you think we should go overboard I guess it'd be useful to
explain what KMS drivers should and shouldn't do in lastclose:
- Delayed gpu switching with vga switcheroo.
- Restoring of the fbcon, as long as the core is still a bit deficient
in getting rid of mouse cursors and stupid sprite setups when X dies
untimely and leaves dirt behind. Eventually we should be able to get
rid of this though and rely on the magic sysrq to get out of graphics
mode and restore fbcon fully.
- Nothing else, ever, especially resource cleanups.

Can you maybe add a sentence or two to your proposed update for about
this? UMS drivers tend to do a lot of nefarious stuff in lastclose, so
stressing the difference would be good.

Otherwise I like your doc update much more than mine ;-)
-Daniel

>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 7d1278e..afa8d40 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct 
> drm_file *);
>
>
>  The firstopen method is called by the DRM 
> core
> -   when an application opens a device that has no other opened file 
> handle.
> -   Similarly the lastclose method is called when
> -   the last application holding a file handle opened on the device closes
> -   it. Both methods are mostly used for UMS (User Mode Setting) drivers 
> to
> -   acquire and release device resources which should be done in the
> -   load and unload
> -   methods for KMS drivers.
> +   for legacy UMS (User Mode Setting) drivers only when an application
> +   opens a device that has no other opened file handle. UMS drivers can
> +   implement it to acquire device resources. KMS drivers can't use the
> +   method and must acquire resources in the load
> +   method instead.
>
>
> -Note that the lastclose method is also 
> called
> -   at module unload time or, for hot-pluggable devices, when the device 
> is
> -   unplugged. The firstopen and
> +   Similarly the lastclose method is called when
> +   the last application holding a file handle opened on the device closes
> +   it, for both UMS and KMS drivers. Additionally, the method is also
> +   called at module unload time or, for hot-pluggable devices, when the
> +   device is unplugged. The firstopen and
> lastclose calls can thus be unbalanced.
>
>
>
>> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
>> index 57e3014..fcde7d4 100644
>> --- a/drivers/gpu/drm/drm_fops.c
>> +++ b/drivers/gpu/drm/drm_fops.c
>> @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
>>   int i;
>>   int ret;
>>
>> - if (dev->driver->firstopen) {
>> + if (dev->driver->firstopen &&
>> + !drm_core_check_feature(dev, DRIVER_MODESET)) {
>>   ret = dev->driver->firstopen(dev);
>>   if (ret != 0)
>>   return ret;
>
> --
> Regards,
>
> Laurent Pinchart



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: don't call ->firstopen for KMS drivers

2013-07-11 Thread Laurent Pinchart 
Hi Daniel,

On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
> It has way too much potential for driver writers to do stupid things
> like delayed hw setup because the load sequence is somehow racy (e.g.
> the imx driver in staging). So don't call it for modesetting drivers,
> which reduces the complexity of the drm core -> driver interface a
> notch.
> 
> v2: Don't forget to update DocBook.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/DocBook/drm.tmpl | 2 ++
>  drivers/gpu/drm/drm_fops.c | 3 ++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 4d54ac8..0e8a5a3 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
> drm_file *); 
>  The firstopen method is called by the DRM
> core when an application opens a device that has no other opened file
> handle.
> + Not that this callback is only called for legacy ums drm drivers, not
> + for drm drivers that implement modesetting in the kernel.
>   Similarly the lastclose method is called when
>   the last application holding a file handle opened on the device closes
>   it. Both methods are mostly used for UMS (User Mode Setting) drivers to

What about

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 7d1278e..afa8d40 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct drm_file 
*);
   
   
 The firstopen method is called by the DRM core
-   when an application opens a device that has no other opened file handle.
-   Similarly the lastclose method is called when
-   the last application holding a file handle opened on the device closes
-   it. Both methods are mostly used for UMS (User Mode Setting) drivers to
-   acquire and release device resources which should be done in the
-   load and unload
-   methods for KMS drivers.
+   for legacy UMS (User Mode Setting) drivers only when an application
+   opens a device that has no other opened file handle. UMS drivers can
+   implement it to acquire device resources. KMS drivers can't use the
+   method and must acquire resources in the load
+   method instead.
   
   
-Note that the lastclose method is also called
-   at module unload time or, for hot-pluggable devices, when the device is
-   unplugged. The firstopen and
+   Similarly the lastclose method is called when
+   the last application holding a file handle opened on the device closes
+   it, for both UMS and KMS drivers. Additionally, the method is also
+   called at module unload time or, for hot-pluggable devices, when the
+   device is unplugged. The firstopen and
lastclose calls can thus be unbalanced.
   
   

> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 57e3014..fcde7d4 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
>   int i;
>   int ret;
> 
> - if (dev->driver->firstopen) {
> + if (dev->driver->firstopen &&
> + !drm_core_check_feature(dev, DRIVER_MODESET)) {
>   ret = dev->driver->firstopen(dev);
>   if (ret != 0)
>   return ret;

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: don't call -firstopen for KMS drivers

2013-07-11 Thread Laurent Pinchart 
Hi Daniel,

On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
 It has way too much potential for driver writers to do stupid things
 like delayed hw setup because the load sequence is somehow racy (e.g.
 the imx driver in staging). So don't call it for modesetting drivers,
 which reduces the complexity of the drm core - driver interface a
 notch.
 
 v2: Don't forget to update DocBook.
 
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  Documentation/DocBook/drm.tmpl | 2 ++
  drivers/gpu/drm/drm_fops.c | 3 ++-
  2 files changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 4d54ac8..0e8a5a3 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
 drm_file *);/synopsis para
  The methodnamefirstopen/methodname method is called by the DRM
 core when an application opens a device that has no other opened file
 handle.
 + Not that this callback is only called for legacy ums drm drivers, not
 + for drm drivers that implement modesetting in the kernel.
   Similarly the methodnamelastclose/methodname method is called when
   the last application holding a file handle opened on the device closes
   it. Both methods are mostly used for UMS (User Mode Setting) drivers to

What about

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 7d1278e..afa8d40 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct drm_file 
*);/synopsis
   /abstract
   para
 The methodnamefirstopen/methodname method is called by the DRM core
-   when an application opens a device that has no other opened file handle.
-   Similarly the methodnamelastclose/methodname method is called when
-   the last application holding a file handle opened on the device closes
-   it. Both methods are mostly used for UMS (User Mode Setting) drivers to
-   acquire and release device resources which should be done in the
-   methodnameload/methodname and methodnameunload/methodname
-   methods for KMS drivers.
+   for legacy UMS (User Mode Setting) drivers only when an application
+   opens a device that has no other opened file handle. UMS drivers can
+   implement it to acquire device resources. KMS drivers can't use the
+   method and must acquire resources in the methodnameload/methodname
+   method instead.
   /para
   para
-Note that the methodnamelastclose/methodname method is also called
-   at module unload time or, for hot-pluggable devices, when the device is
-   unplugged. The methodnamefirstopen/methodname and
+   Similarly the methodnamelastclose/methodname method is called when
+   the last application holding a file handle opened on the device closes
+   it, for both UMS and KMS drivers. Additionally, the method is also
+   called at module unload time or, for hot-pluggable devices, when the
+   device is unplugged. The methodnamefirstopen/methodname and
methodnamelastclose/methodname calls can thus be unbalanced.
   /para
   para

 diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 index 57e3014..fcde7d4 100644
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
   int i;
   int ret;
 
 - if (dev-driver-firstopen) {
 + if (dev-driver-firstopen 
 + !drm_core_check_feature(dev, DRIVER_MODESET)) {
   ret = dev-driver-firstopen(dev);
   if (ret != 0)
   return ret;

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: don't call -firstopen for KMS drivers

2013-07-11 Thread Daniel Vetter 
On Thu, Jul 11, 2013 at 9:54 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Daniel,

 On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
 It has way too much potential for driver writers to do stupid things
 like delayed hw setup because the load sequence is somehow racy (e.g.
 the imx driver in staging). So don't call it for modesetting drivers,
 which reduces the complexity of the drm core - driver interface a
 notch.

 v2: Don't forget to update DocBook.

 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  Documentation/DocBook/drm.tmpl | 2 ++
  drivers/gpu/drm/drm_fops.c | 3 ++-
  2 files changed, 4 insertions(+), 1 deletion(-)

 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 4d54ac8..0e8a5a3 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
 drm_file *);/synopsis para
  The methodnamefirstopen/methodname method is called by the DRM
 core when an application opens a device that has no other opened file
 handle.
 + Not that this callback is only called for legacy ums drm drivers, not
 + for drm drivers that implement modesetting in the kernel.
   Similarly the methodnamelastclose/methodname method is called when
   the last application holding a file handle opened on the device closes
   it. Both methods are mostly used for UMS (User Mode Setting) drivers to

 What about

So if you think we should go overboard I guess it'd be useful to
explain what KMS drivers should and shouldn't do in lastclose:
- Delayed gpu switching with vga switcheroo.
- Restoring of the fbcon, as long as the core is still a bit deficient
in getting rid of mouse cursors and stupid sprite setups when X dies
untimely and leaves dirt behind. Eventually we should be able to get
rid of this though and rely on the magic sysrq to get out of graphics
mode and restore fbcon fully.
- Nothing else, ever, especially resource cleanups.

Can you maybe add a sentence or two to your proposed update for about
this? UMS drivers tend to do a lot of nefarious stuff in lastclose, so
stressing the difference would be good.

Otherwise I like your doc update much more than mine ;-)
-Daniel


 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 7d1278e..afa8d40 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct 
 drm_file *);/synopsis
/abstract
para
  The methodnamefirstopen/methodname method is called by the DRM 
 core
 -   when an application opens a device that has no other opened file 
 handle.
 -   Similarly the methodnamelastclose/methodname method is called when
 -   the last application holding a file handle opened on the device closes
 -   it. Both methods are mostly used for UMS (User Mode Setting) drivers 
 to
 -   acquire and release device resources which should be done in the
 -   methodnameload/methodname and methodnameunload/methodname
 -   methods for KMS drivers.
 +   for legacy UMS (User Mode Setting) drivers only when an application
 +   opens a device that has no other opened file handle. UMS drivers can
 +   implement it to acquire device resources. KMS drivers can't use the
 +   method and must acquire resources in the methodnameload/methodname
 +   method instead.
/para
para
 -Note that the methodnamelastclose/methodname method is also 
 called
 -   at module unload time or, for hot-pluggable devices, when the device 
 is
 -   unplugged. The methodnamefirstopen/methodname and
 +   Similarly the methodnamelastclose/methodname method is called when
 +   the last application holding a file handle opened on the device closes
 +   it, for both UMS and KMS drivers. Additionally, the method is also
 +   called at module unload time or, for hot-pluggable devices, when the
 +   device is unplugged. The methodnamefirstopen/methodname and
 methodnamelastclose/methodname calls can thus be unbalanced.
/para
para

 diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 index 57e3014..fcde7d4 100644
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
   int i;
   int ret;

 - if (dev-driver-firstopen) {
 + if (dev-driver-firstopen 
 + !drm_core_check_feature(dev, DRIVER_MODESET)) {
   ret = dev-driver-firstopen(dev);
   if (ret != 0)
   return ret;

 --
 Regards,

 Laurent Pinchart



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list

[PATCH] drm: don't call ->firstopen for KMS drivers

2013-07-10 Thread Daniel Vetter 
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.

v2: Don't forget to update DocBook.

Cc: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/drm.tmpl | 2 ++
 drivers/gpu/drm/drm_fops.c | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 4d54ac8..0e8a5a3 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct drm_file 
*);
   
 The firstopen method is called by the DRM core
when an application opens a device that has no other opened file handle.
+   Not that this callback is only called for legacy ums drm drivers, not
+   for drm drivers that implement modesetting in the kernel.
Similarly the lastclose method is called when
the last application holding a file handle opened on the device closes
it. Both methods are mostly used for UMS (User Mode Setting) drivers to
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 57e3014..fcde7d4 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
int i;
int ret;

-   if (dev->driver->firstopen) {
+   if (dev->driver->firstopen &&
+   !drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = dev->driver->firstopen(dev);
if (ret != 0)
return ret;
-- 
1.8.3.2

[PATCH] drm: don't call -firstopen for KMS drivers

2013-07-10 Thread Daniel Vetter 
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core - driver interface a
notch.

v2: Don't forget to update DocBook.

Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 Documentation/DocBook/drm.tmpl | 2 ++
 drivers/gpu/drm/drm_fops.c | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 4d54ac8..0e8a5a3 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct drm_file 
*);/synopsis
   para
 The methodnamefirstopen/methodname method is called by the DRM core
when an application opens a device that has no other opened file handle.
+   Not that this callback is only called for legacy ums drm drivers, not
+   for drm drivers that implement modesetting in the kernel.
Similarly the methodnamelastclose/methodname method is called when
the last application holding a file handle opened on the device closes
it. Both methods are mostly used for UMS (User Mode Setting) drivers to
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 57e3014..fcde7d4 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
int i;
int ret;
 
-   if (dev-driver-firstopen) {
+   if (dev-driver-firstopen 
+   !drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = dev-driver-firstopen(dev);
if (ret != 0)
return ret;
-- 
1.8.3.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel