[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-20 Thread Joonyoung Shim 
On 09/20/2012 04:49 PM, Chris Wilson wrote:
> On Thu, 20 Sep 2012 15:10:39 +0900, Joonyoung Shim  samsung.com> wrote:
>> On 09/20/2012 02:38 PM, Rob Clark wrote:
>>> On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim >> samsung.com> wrote:
 On 09/17/2012 06:38 PM, Chris Wilson wrote:
> As during the plane cleanup, we wish to disable the hardware and
> so may modify state on the associated CRTC, that CRTC must continue to
> exist until we are finished.
 A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
 plane use same framebuffer and the framebuffer is destroyed, crtc is
 turned off prior to turning off plane.

>>> I imagine my patch to add refcnt'ing to fb would help in this case..
>>>
>>> BR,
>>> -R
>> Even if the patch to add refcnt'ing to fb is applied, same issue will
>> occur in the drm_framebuffer_remove(). It can delay to destroy the fb,
>> but cannot change crtc and plane disable order.
>>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
> Signed-off-by: Chris Wilson 
> Cc: Jesse Barnes 
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/drm_crtc.c |8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 6fbfc24..af81f77 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
> *dev)
>   fb->funcs->destroy(fb);
>   }
> - list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
> head) {
> -   crtc->funcs->destroy(crtc);
> -   }
> -
>   list_for_each_entry_safe(plane, plt, 
> >mode_config.plane_list,
>head) {
>   plane->funcs->destroy(plane);
>   }
> + list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
> head) {
> +   crtc->funcs->destroy(crtc);
> +   }
> +
>   idr_remove_all(>mode_config.crtc_idr);
>   idr_destroy(>mode_config.crtc_idr);
> }
 ___
 dri-devel mailing list
 dri-devel at lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
> From: Chris Wilson 
> Subject: Re: [PATCH] drm: Destroy the planes prior to destroying the 
> associated CRTC
> To: Rob Clark , Joonyoung Shim  samsung.com>
> Cc: airlied at redhat.com, stable at vger.kernel.org, dri-devel at 
> lists.freedesktop.org
> In-Reply-To:  mail.gmail.com>
> References: <1347874683-21191-1-git-send-email-chris at chris-wilson.co.uk> 
> <505A850A.4010205 at samsung.com> 
> 
>
> On Thu, 20 Sep 2012 00:38:04 -0500, Rob Clark  wrote:
>> On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim  
>> wrote:
>>> On 09/17/2012 06:38 PM, Chris Wilson wrote:
 As during the plane cleanup, we wish to disable the hardware and
 so may modify state on the associated CRTC, that CRTC must continue to
 exist until we are finished.
>>>
>>> A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
>>> plane use same framebuffer and the framebuffer is destroyed, crtc is
>>> turned off prior to turning off plane.
>>>
>> I imagine my patch to add refcnt'ing to fb would help in this case..
>>
>> BR,
>> -R
>>
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
 Signed-off-by: Chris Wilson 
 Cc: Jesse Barnes 
 Cc: stable at vger.kernel.org
 ---
drivers/gpu/drm/drm_crtc.c |8 
1 file changed, 4 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 6fbfc24..af81f77 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
 *dev)
  fb->funcs->destroy(fb);
  }
- list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
 head) {
 -   crtc->funcs->destroy(crtc);
 -   }
 -
  list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
   head) {
  plane->funcs->destroy(plane);
  }
+ list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
 head) {
 +   crtc->funcs->destroy(crtc);
 +   }
 +
  idr_remove_all(>mode_config.crtc_idr);
  idr_destroy(>mode_config.crtc_idr);
}
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> From: Chris Wilson 
> Subject: Re: [PATCH] drm: Destroy the planes prior to destroying the 
> associated CRTC
>

[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-20 Thread Joonyoung Shim 
On 09/20/2012 02:38 PM, Rob Clark wrote:
> On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim  
> wrote:
>> On 09/17/2012 06:38 PM, Chris Wilson wrote:
>>> As during the plane cleanup, we wish to disable the hardware and
>>> so may modify state on the associated CRTC, that CRTC must continue to
>>> exist until we are finished.
>>
>> A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
>> plane use same framebuffer and the framebuffer is destroyed, crtc is
>> turned off prior to turning off plane.
>>
> I imagine my patch to add refcnt'ing to fb would help in this case..
>
> BR,
> -R

Even if the patch to add refcnt'ing to fb is applied, same issue will
occur in the drm_framebuffer_remove(). It can delay to destroy the fb,
but cannot change crtc and plane disable order.

>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
>>> Signed-off-by: Chris Wilson 
>>> Cc: Jesse Barnes 
>>> Cc: stable at vger.kernel.org
>>> ---
>>>drivers/gpu/drm/drm_crtc.c |8 
>>>1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>> index 6fbfc24..af81f77 100644
>>> --- a/drivers/gpu/drm/drm_crtc.c
>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>> @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
>>> *dev)
>>>  fb->funcs->destroy(fb);
>>>  }
>>>- list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
>>> head) {
>>> -   crtc->funcs->destroy(crtc);
>>> -   }
>>> -
>>>  list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
>>>   head) {
>>>  plane->funcs->destroy(plane);
>>>  }
>>>+ list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
>>> head) {
>>> +   crtc->funcs->destroy(crtc);
>>> +   }
>>> +
>>>  idr_remove_all(>mode_config.crtc_idr);
>>>  idr_destroy(>mode_config.crtc_idr);
>>>}
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-20 Thread Joonyoung Shim 
On 09/17/2012 06:38 PM, Chris Wilson wrote:
> As during the plane cleanup, we wish to disable the hardware and
> so may modify state on the associated CRTC, that CRTC must continue to
> exist until we are finished.

A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
plane use same framebuffer and the framebuffer is destroyed, crtc is
turned off prior to turning off plane.

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
> Signed-off-by: Chris Wilson 
> Cc: Jesse Barnes 
> Cc: stable at vger.kernel.org
> ---
>   drivers/gpu/drm/drm_crtc.c |8 
>   1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 6fbfc24..af81f77 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>   fb->funcs->destroy(fb);
>   }
>   
> - list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list, head) {
> - crtc->funcs->destroy(crtc);
> - }
> -
>   list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
>head) {
>   plane->funcs->destroy(plane);
>   }
>   
> + list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list, head) {
> + crtc->funcs->destroy(crtc);
> + }
> +
>   idr_remove_all(>mode_config.crtc_idr);
>   idr_destroy(>mode_config.crtc_idr);
>   }

[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-20 Thread Chris Wilson 
On Thu, 20 Sep 2012 15:10:39 +0900, Joonyoung Shim  
wrote:
> On 09/20/2012 02:38 PM, Rob Clark wrote:
> > On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim  > samsung.com> wrote:
> >> On 09/17/2012 06:38 PM, Chris Wilson wrote:
> >>> As during the plane cleanup, we wish to disable the hardware and
> >>> so may modify state on the associated CRTC, that CRTC must continue to
> >>> exist until we are finished.
> >>
> >> A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
> >> plane use same framebuffer and the framebuffer is destroyed, crtc is
> >> turned off prior to turning off plane.
> >>
> > I imagine my patch to add refcnt'ing to fb would help in this case..
> >
> > BR,
> > -R
> 
> Even if the patch to add refcnt'ing to fb is applied, same issue will
> occur in the drm_framebuffer_remove(). It can delay to destroy the fb,
> but cannot change crtc and plane disable order.
> 
> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
> >>> Signed-off-by: Chris Wilson 
> >>> Cc: Jesse Barnes 
> >>> Cc: stable at vger.kernel.org
> >>> ---
> >>>drivers/gpu/drm/drm_crtc.c |8 
> >>>1 file changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >>> index 6fbfc24..af81f77 100644
> >>> --- a/drivers/gpu/drm/drm_crtc.c
> >>> +++ b/drivers/gpu/drm/drm_crtc.c
> >>> @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
> >>> *dev)
> >>>  fb->funcs->destroy(fb);
> >>>  }
> >>>- list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
> >>> head) {
> >>> -   crtc->funcs->destroy(crtc);
> >>> -   }
> >>> -
> >>>  list_for_each_entry_safe(plane, plt, 
> >>> >mode_config.plane_list,
> >>>   head) {
> >>>  plane->funcs->destroy(plane);
> >>>  }
> >>>+ list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
> >>> head) {
> >>> +   crtc->funcs->destroy(crtc);
> >>> +   }
> >>> +
> >>>  idr_remove_all(>mode_config.crtc_idr);
> >>>  idr_destroy(>mode_config.crtc_idr);
> >>>}
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
From: Chris Wilson 
Subject: Re: [PATCH] drm: Destroy the planes prior to destroying the associated 
CRTC
To: Rob Clark , Joonyoung Shim 
Cc: airlied at redhat.com, stable at vger.kernel.org, dri-devel at 
lists.freedesktop.org
In-Reply-To: 
References: <1347874683-21191-1-git-send-email-chris at chris-wilson.co.uk> 
<505A850A.4010205 at samsung.com> 


On Thu, 20 Sep 2012 00:38:04 -0500, Rob Clark  wrote:
> On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim  
> wrote:
> > On 09/17/2012 06:38 PM, Chris Wilson wrote:
> >>
> >> As during the plane cleanup, we wish to disable the hardware and
> >> so may modify state on the associated CRTC, that CRTC must continue to
> >> exist until we are finished.
> >
> >
> > A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
> > plane use same framebuffer and the framebuffer is destroyed, crtc is
> > turned off prior to turning off plane.
> >
> 
> I imagine my patch to add refcnt'ing to fb would help in this case..
> 
> BR,
> -R
> 
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
> >> Signed-off-by: Chris Wilson 
> >> Cc: Jesse Barnes 
> >> Cc: stable at vger.kernel.org
> >> ---
> >>   drivers/gpu/drm/drm_crtc.c |8 
> >>   1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> index 6fbfc24..af81f77 100644
> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
> >> *dev)
> >> fb->funcs->destroy(fb);
> >> }
> >>   - list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
> >> head) {
> >> -   crtc->funcs->destroy(crtc);
> >> -   }
> >> -
> >> list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
> >>  head) {
> >> plane->funcs->destroy(plane);
> >> }
> >>   + list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
> >> head) {
> >> +   crtc->funcs->destroy(crtc);
> >> +   }
> >> +
> >> idr_remove_all(>mode_config.crtc_idr);
> >> idr_destroy(>mode_config.crtc_idr);
> >>   }
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Chris Wilson 
Subject: Re: [PATCH] drm: Destroy the planes prior to destroying the associated 
CRTC
To: Joonyoung Shim 
Cc: dri-devel at lists.freedesktop.org, airlied

[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-20 Thread Rob Clark 
On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim  
wrote:
> On 09/17/2012 06:38 PM, Chris Wilson wrote:
>>
>> As during the plane cleanup, we wish to disable the hardware and
>> so may modify state on the associated CRTC, that CRTC must continue to
>> exist until we are finished.
>
>
> A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
> plane use same framebuffer and the framebuffer is destroyed, crtc is
> turned off prior to turning off plane.
>

I imagine my patch to add refcnt'ing to fb would help in this case..

BR,
-R

>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
>> Signed-off-by: Chris Wilson 
>> Cc: Jesse Barnes 
>> Cc: stable at vger.kernel.org
>> ---
>>   drivers/gpu/drm/drm_crtc.c |8 
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 6fbfc24..af81f77 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
>> *dev)
>> fb->funcs->destroy(fb);
>> }
>>   - list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
>> head) {
>> -   crtc->funcs->destroy(crtc);
>> -   }
>> -
>> list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
>>  head) {
>> plane->funcs->destroy(plane);
>> }
>>   + list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list,
>> head) {
>> +   crtc->funcs->destroy(crtc);
>> +   }
>> +
>> idr_remove_all(>mode_config.crtc_idr);
>> idr_destroy(>mode_config.crtc_idr);
>>   }
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-20 Thread Rob Clark 
On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim jy0922.s...@samsung.com wrote:
 On 09/17/2012 06:38 PM, Chris Wilson wrote:

 As during the plane cleanup, we wish to disable the hardware and
 so may modify state on the associated CRTC, that CRTC must continue to
 exist until we are finished.


 A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
 plane use same framebuffer and the framebuffer is destroyed, crtc is
 turned off prior to turning off plane.


I imagine my patch to add refcnt'ing to fb would help in this case..

BR,
-R

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Jesse Barnes jbar...@virtuousgeek.org
 Cc: sta...@vger.kernel.org
 ---
   drivers/gpu/drm/drm_crtc.c |8 
   1 file changed, 4 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 6fbfc24..af81f77 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
 *dev)
 fb-funcs-destroy(fb);
 }
   - list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
 head) {
 -   crtc-funcs-destroy(crtc);
 -   }
 -
 list_for_each_entry_safe(plane, plt, dev-mode_config.plane_list,
  head) {
 plane-funcs-destroy(plane);
 }
   + list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
 head) {
 +   crtc-funcs-destroy(crtc);
 +   }
 +
 idr_remove_all(dev-mode_config.crtc_idr);
 idr_destroy(dev-mode_config.crtc_idr);
   }


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

Re: [PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-20 Thread Joonyoung Shim 

On 09/20/2012 02:38 PM, Rob Clark wrote:

On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim jy0922.s...@samsung.com wrote:

On 09/17/2012 06:38 PM, Chris Wilson wrote:

As during the plane cleanup, we wish to disable the hardware and
so may modify state on the associated CRTC, that CRTC must continue to
exist until we are finished.


A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
plane use same framebuffer and the framebuffer is destroyed, crtc is
turned off prior to turning off plane.


I imagine my patch to add refcnt'ing to fb would help in this case..

BR,
-R


Even if the patch to add refcnt'ing to fb is applied, same issue will
occur in the drm_framebuffer_remove(). It can delay to destroy the fb,
but cannot change crtc and plane disable order.


Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: sta...@vger.kernel.org
---
   drivers/gpu/drm/drm_crtc.c |8 
   1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6fbfc24..af81f77 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
*dev)
 fb-funcs-destroy(fb);
 }
   - list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
head) {
-   crtc-funcs-destroy(crtc);
-   }
-
 list_for_each_entry_safe(plane, plt, dev-mode_config.plane_list,
  head) {
 plane-funcs-destroy(plane);
 }
   + list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
head) {
+   crtc-funcs-destroy(crtc);
+   }
+
 idr_remove_all(dev-mode_config.crtc_idr);
 idr_destroy(dev-mode_config.crtc_idr);
   }


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


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

Re: [PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-20 Thread Chris Wilson 
On Thu, 20 Sep 2012 15:10:39 +0900, Joonyoung Shim jy0922.s...@samsung.com 
wrote:
 On 09/20/2012 02:38 PM, Rob Clark wrote:
  On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim jy0922.s...@samsung.com 
  wrote:
  On 09/17/2012 06:38 PM, Chris Wilson wrote:
  As during the plane cleanup, we wish to disable the hardware and
  so may modify state on the associated CRTC, that CRTC must continue to
  exist until we are finished.
 
  A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
  plane use same framebuffer and the framebuffer is destroyed, crtc is
  turned off prior to turning off plane.
 
  I imagine my patch to add refcnt'ing to fb would help in this case..
 
  BR,
  -R
 
 Even if the patch to add refcnt'ing to fb is applied, same issue will
 occur in the drm_framebuffer_remove(). It can delay to destroy the fb,
 but cannot change crtc and plane disable order.
 
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Cc: Jesse Barnes jbar...@virtuousgeek.org
  Cc: sta...@vger.kernel.org
  ---
 drivers/gpu/drm/drm_crtc.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 
  diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
  index 6fbfc24..af81f77 100644
  --- a/drivers/gpu/drm/drm_crtc.c
  +++ b/drivers/gpu/drm/drm_crtc.c
  @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
  *dev)
   fb-funcs-destroy(fb);
   }
 - list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
  head) {
  -   crtc-funcs-destroy(crtc);
  -   }
  -
   list_for_each_entry_safe(plane, plt, 
  dev-mode_config.plane_list,
head) {
   plane-funcs-destroy(plane);
   }
 + list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
  head) {
  +   crtc-funcs-destroy(crtc);
  +   }
  +
   idr_remove_all(dev-mode_config.crtc_idr);
   idr_destroy(dev-mode_config.crtc_idr);
 }
 
  ___
  dri-devel mailing list
  dri-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/dri-devel
 
From: Chris Wilson ch...@chris-wilson.co.uk
Subject: Re: [PATCH] drm: Destroy the planes prior to destroying the associated 
CRTC
To: Rob Clark rob.cl...@linaro.org, Joonyoung Shim jy0922.s...@samsung.com
Cc: airl...@redhat.com, sta...@vger.kernel.org, dri-devel@lists.freedesktop.org
In-Reply-To: 
caf6aegvoza_zhrjn212rsn-gmmuywolt6ufy9iindi8awx9...@mail.gmail.com
References: 1347874683-21191-1-git-send-email-ch...@chris-wilson.co.uk 
505a850a.4010...@samsung.com 
caf6aegvoza_zhrjn212rsn-gmmuywolt6ufy9iindi8awx9...@mail.gmail.com

On Thu, 20 Sep 2012 00:38:04 -0500, Rob Clark rob.cl...@linaro.org wrote:
 On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim jy0922.s...@samsung.com 
 wrote:
  On 09/17/2012 06:38 PM, Chris Wilson wrote:
 
  As during the plane cleanup, we wish to disable the hardware and
  so may modify state on the associated CRTC, that CRTC must continue to
  exist until we are finished.
 
 
  A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
  plane use same framebuffer and the framebuffer is destroyed, crtc is
  turned off prior to turning off plane.
 
 
 I imagine my patch to add refcnt'ing to fb would help in this case..
 
 BR,
 -R
 
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Cc: Jesse Barnes jbar...@virtuousgeek.org
  Cc: sta...@vger.kernel.org
  ---
drivers/gpu/drm/drm_crtc.c |8 
1 file changed, 4 insertions(+), 4 deletions(-)
 
  diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
  index 6fbfc24..af81f77 100644
  --- a/drivers/gpu/drm/drm_crtc.c
  +++ b/drivers/gpu/drm/drm_crtc.c
  @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
  *dev)
  fb-funcs-destroy(fb);
  }
- list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
  head) {
  -   crtc-funcs-destroy(crtc);
  -   }
  -
  list_for_each_entry_safe(plane, plt, dev-mode_config.plane_list,
   head) {
  plane-funcs-destroy(plane);
  }
+ list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
  head) {
  +   crtc-funcs-destroy(crtc);
  +   }
  +
  idr_remove_all(dev-mode_config.crtc_idr);
  idr_destroy(dev-mode_config.crtc_idr);
}
 
 
  ___
  dri-devel mailing list
  dri-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Chris Wilson ch...@chris-wilson.co.uk
Subject: Re: [PATCH] drm: Destroy the planes prior to destroying the associated 
CRTC
To: Joonyoung Shim jy0922.s...@samsung.com
Cc: dri-devel@lists.freedesktop.org,

Re: [PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-20 Thread Joonyoung Shim 

On 09/20/2012 04:49 PM, Chris Wilson wrote:

On Thu, 20 Sep 2012 15:10:39 +0900, Joonyoung Shim jy0922.s...@samsung.com 
wrote:

On 09/20/2012 02:38 PM, Rob Clark wrote:

On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim jy0922.s...@samsung.com wrote:

On 09/17/2012 06:38 PM, Chris Wilson wrote:

As during the plane cleanup, we wish to disable the hardware and
so may modify state on the associated CRTC, that CRTC must continue to
exist until we are finished.

A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
plane use same framebuffer and the framebuffer is destroyed, crtc is
turned off prior to turning off plane.


I imagine my patch to add refcnt'ing to fb would help in this case..

BR,
-R

Even if the patch to add refcnt'ing to fb is applied, same issue will
occur in the drm_framebuffer_remove(). It can delay to destroy the fb,
but cannot change crtc and plane disable order.


Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_crtc.c |8 
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6fbfc24..af81f77 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
*dev)
  fb-funcs-destroy(fb);
  }
- list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
head) {
-   crtc-funcs-destroy(crtc);
-   }
-
  list_for_each_entry_safe(plane, plt, dev-mode_config.plane_list,
   head) {
  plane-funcs-destroy(plane);
  }
+ list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
head) {
+   crtc-funcs-destroy(crtc);
+   }
+
  idr_remove_all(dev-mode_config.crtc_idr);
  idr_destroy(dev-mode_config.crtc_idr);
}

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

From: Chris Wilson ch...@chris-wilson.co.uk
Subject: Re: [PATCH] drm: Destroy the planes prior to destroying the associated 
CRTC
To: Rob Clark rob.cl...@linaro.org, Joonyoung Shim jy0922.s...@samsung.com
Cc: airl...@redhat.com, sta...@vger.kernel.org, dri-devel@lists.freedesktop.org
In-Reply-To: 
caf6aegvoza_zhrjn212rsn-gmmuywolt6ufy9iindi8awx9...@mail.gmail.com
References: 1347874683-21191-1-git-send-email-ch...@chris-wilson.co.uk 
505a850a.4010...@samsung.com 
caf6aegvoza_zhrjn212rsn-gmmuywolt6ufy9iindi8awx9...@mail.gmail.com

On Thu, 20 Sep 2012 00:38:04 -0500, Rob Clark rob.cl...@linaro.org wrote:

On Wed, Sep 19, 2012 at 9:52 PM, Joonyoung Shim jy0922.s...@samsung.com wrote:

On 09/17/2012 06:38 PM, Chris Wilson wrote:

As during the plane cleanup, we wish to disable the hardware and
so may modify state on the associated CRTC, that CRTC must continue to
exist until we are finished.


A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
plane use same framebuffer and the framebuffer is destroyed, crtc is
turned off prior to turning off plane.


I imagine my patch to add refcnt'ing to fb would help in this case..

BR,
-R


Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: sta...@vger.kernel.org
---
   drivers/gpu/drm/drm_crtc.c |8 
   1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6fbfc24..af81f77 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device
*dev)
 fb-funcs-destroy(fb);
 }
   - list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
head) {
-   crtc-funcs-destroy(crtc);
-   }
-
 list_for_each_entry_safe(plane, plt, dev-mode_config.plane_list,
  head) {
 plane-funcs-destroy(plane);
 }
   + list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list,
head) {
+   crtc-funcs-destroy(crtc);
+   }
+
 idr_remove_all(dev-mode_config.crtc_idr);
 idr_destroy(dev-mode_config.crtc_idr);
   }


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

From: Chris Wilson ch...@chris-wilson.co.uk
Subject: Re: [PATCH] drm: Destroy the planes prior to destroying the associated 
CRTC
To: Joonyoung Shim jy0922.s...@samsung.com
Cc: dri-devel@lists.freedesktop.org, airl...@redhat.com, sta...@vger.kernel.org
In-Reply-To: 505a850a.4010...@samsung.com
References:

[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-19 Thread Paul Menzel 
Am Mittwoch, den 19.09.2012, 11:34 +0200 schrieb Daniel Vetter:
> On Mon, Sep 17, 2012 at 04:04:23PM +0100, Chris Wilson wrote:
> > On Mon, 17 Sep 2012 07:55:59 -0700, Jesse Barnes  > virtuousgeek.org> wrote:
> > > Yeah, looks good.  Did we used to not touch the crtc in the plane
> > > cleanup?  Either way this is safer.
> > 
> > I think the bug only came to light because QA is now routinely running
> > with slub_debug.
> 
> And QA now confirmed that this patch fixes things:
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
> Tested-by: lu hua 

Lu Hua*x*?


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:

[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-19 Thread Daniel Vetter 
On Mon, Sep 17, 2012 at 04:04:23PM +0100, Chris Wilson wrote:
> On Mon, 17 Sep 2012 07:55:59 -0700, Jesse Barnes  virtuousgeek.org> wrote:
> > Yeah, looks good.  Did we used to not touch the crtc in the plane
> > cleanup?  Either way this is safer.
> 
> I think the bug only came to light because QA is now routinely running
> with slub_debug.

And QA now confirmed that this patch fixes things:

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
Tested-by: lu hua 

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

[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-19 Thread Chris Wilson 
On Wed, 19 Sep 2012 11:45:34 +0200, Paul Menzel  wrote:
> Am Mittwoch, den 19.09.2012, 11:34 +0200 schrieb Daniel Vetter:
> > On Mon, Sep 17, 2012 at 04:04:23PM +0100, Chris Wilson wrote:
> > > On Mon, 17 Sep 2012 07:55:59 -0700, Jesse Barnes  > > virtuousgeek.org> wrote:
> > > > Yeah, looks good.  Did we used to not touch the crtc in the plane
> > > > cleanup?  Either way this is safer.
> > > 
> > > I think the bug only came to light because QA is now routinely running
> > > with slub_debug.
> > 
> > And QA now confirmed that this patch fixes things:
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
> > Tested-by: lu hua 
> 
> Lu Hua*x*?

The 'x' is just part of Intel's policy for indicating a contractor in
email addresses, which can be quite confusing.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-19 Thread Daniel Vetter 
On Mon, Sep 17, 2012 at 04:04:23PM +0100, Chris Wilson wrote:
 On Mon, 17 Sep 2012 07:55:59 -0700, Jesse Barnes jbar...@virtuousgeek.org 
 wrote:
  Yeah, looks good.  Did we used to not touch the crtc in the plane
  cleanup?  Either way this is safer.
 
 I think the bug only came to light because QA is now routinely running
 with slub_debug.

And QA now confirmed that this patch fixes things:

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
Tested-by: lu hua huax...@intel.com

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

Re: [PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-19 Thread Paul Menzel 
Am Mittwoch, den 19.09.2012, 11:34 +0200 schrieb Daniel Vetter:
 On Mon, Sep 17, 2012 at 04:04:23PM +0100, Chris Wilson wrote:
  On Mon, 17 Sep 2012 07:55:59 -0700, Jesse Barnes jbar...@virtuousgeek.org 
  wrote:
   Yeah, looks good.  Did we used to not touch the crtc in the plane
   cleanup?  Either way this is safer.
  
  I think the bug only came to light because QA is now routinely running
  with slub_debug.
 
 And QA now confirmed that this patch fixes things:
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
 Tested-by: lu hua huax...@intel.com

Lu Hua*x*?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-19 Thread Chris Wilson 
On Wed, 19 Sep 2012 11:45:34 +0200, Paul Menzel 
paulepan...@users.sourceforge.net wrote:
 Am Mittwoch, den 19.09.2012, 11:34 +0200 schrieb Daniel Vetter:
  On Mon, Sep 17, 2012 at 04:04:23PM +0100, Chris Wilson wrote:
   On Mon, 17 Sep 2012 07:55:59 -0700, Jesse Barnes 
   jbar...@virtuousgeek.org wrote:
Yeah, looks good.  Did we used to not touch the crtc in the plane
cleanup?  Either way this is safer.
   
   I think the bug only came to light because QA is now routinely running
   with slub_debug.
  
  And QA now confirmed that this patch fixes things:
  
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
  Tested-by: lu hua huax...@intel.com
 
 Lu Hua*x*?

The 'x' is just part of Intel's policy for indicating a contractor in
email addresses, which can be quite confusing.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-19 Thread Joonyoung Shim 

On 09/17/2012 06:38 PM, Chris Wilson wrote:

As during the plane cleanup, we wish to disable the hardware and
so may modify state on the associated CRTC, that CRTC must continue to
exist until we are finished.


A similar issue can occur in the drm_framebuffer_cleanup(). If crtc and
plane use same framebuffer and the framebuffer is destroyed, crtc is
turned off prior to turning off plane.


Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: sta...@vger.kernel.org
---
  drivers/gpu/drm/drm_crtc.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6fbfc24..af81f77 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device *dev)
fb-funcs-destroy(fb);
}
  
-	list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list, head) {

-   crtc-funcs-destroy(crtc);
-   }
-
list_for_each_entry_safe(plane, plt, dev-mode_config.plane_list,
 head) {
plane-funcs-destroy(plane);
}
  
+	list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list, head) {

+   crtc-funcs-destroy(crtc);
+   }
+
idr_remove_all(dev-mode_config.crtc_idr);
idr_destroy(dev-mode_config.crtc_idr);
  }


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

[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-17 Thread Chris Wilson 
On Mon, 17 Sep 2012 07:55:59 -0700, Jesse Barnes  
wrote:
> Yeah, looks good.  Did we used to not touch the crtc in the plane
> cleanup?  Either way this is safer.

I think the bug only came to light because QA is now routinely running
with slub_debug.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-17 Thread Chris Wilson 
As during the plane cleanup, we wish to disable the hardware and
so may modify state on the associated CRTC, that CRTC must continue to
exist until we are finished.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
Signed-off-by: Chris Wilson 
Cc: Jesse Barnes 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/drm_crtc.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6fbfc24..af81f77 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device *dev)
fb->funcs->destroy(fb);
}

-   list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list, head) {
-   crtc->funcs->destroy(crtc);
-   }
-
list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
 head) {
plane->funcs->destroy(plane);
}

+   list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list, head) {
+   crtc->funcs->destroy(crtc);
+   }
+
idr_remove_all(>mode_config.crtc_idr);
idr_destroy(>mode_config.crtc_idr);
 }
-- 
1.7.10.4

[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-17 Thread Jesse Barnes 
On Mon, 17 Sep 2012 10:38:03 +0100
Chris Wilson  wrote:

> As during the plane cleanup, we wish to disable the hardware and
> so may modify state on the associated CRTC, that CRTC must continue to
> exist until we are finished.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
> Signed-off-by: Chris Wilson 
> Cc: Jesse Barnes 
> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/drm_crtc.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 6fbfc24..af81f77 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>   fb->funcs->destroy(fb);
>   }
>  
> - list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list, head) {
> - crtc->funcs->destroy(crtc);
> - }
> -
>   list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
>head) {
>   plane->funcs->destroy(plane);
>   }
>  
> + list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list, head) {
> + crtc->funcs->destroy(crtc);
> + }
> +
>   idr_remove_all(>mode_config.crtc_idr);
>   idr_destroy(>mode_config.crtc_idr);
>  }

Yeah, looks good.  Did we used to not touch the crtc in the plane
cleanup?  Either way this is safer.

Reviewed-by: Jesse Barnes 

-- 
Jesse Barnes, Intel Open Source Technology Center

[PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-17 Thread Chris Wilson 
As during the plane cleanup, we wish to disable the hardware and
so may modify state on the associated CRTC, that CRTC must continue to
exist until we are finished.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/drm_crtc.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6fbfc24..af81f77 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device *dev)
fb-funcs-destroy(fb);
}
 
-   list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list, head) {
-   crtc-funcs-destroy(crtc);
-   }
-
list_for_each_entry_safe(plane, plt, dev-mode_config.plane_list,
 head) {
plane-funcs-destroy(plane);
}
 
+   list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list, head) {
+   crtc-funcs-destroy(crtc);
+   }
+
idr_remove_all(dev-mode_config.crtc_idr);
idr_destroy(dev-mode_config.crtc_idr);
 }
-- 
1.7.10.4

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

Re: [PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-17 Thread Jesse Barnes 
On Mon, 17 Sep 2012 10:38:03 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:

 As during the plane cleanup, we wish to disable the hardware and
 so may modify state on the associated CRTC, that CRTC must continue to
 exist until we are finished.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Jesse Barnes jbar...@virtuousgeek.org
 Cc: sta...@vger.kernel.org
 ---
  drivers/gpu/drm/drm_crtc.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 6fbfc24..af81f77 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -1034,15 +1034,15 @@ void drm_mode_config_cleanup(struct drm_device *dev)
   fb-funcs-destroy(fb);
   }
  
 - list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list, head) {
 - crtc-funcs-destroy(crtc);
 - }
 -
   list_for_each_entry_safe(plane, plt, dev-mode_config.plane_list,
head) {
   plane-funcs-destroy(plane);
   }
  
 + list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list, head) {
 + crtc-funcs-destroy(crtc);
 + }
 +
   idr_remove_all(dev-mode_config.crtc_idr);
   idr_destroy(dev-mode_config.crtc_idr);
  }

Yeah, looks good.  Did we used to not touch the crtc in the plane
cleanup?  Either way this is safer.

Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Destroy the planes prior to destroying the associated CRTC

2012-09-17 Thread Chris Wilson 
On Mon, 17 Sep 2012 07:55:59 -0700, Jesse Barnes jbar...@virtuousgeek.org 
wrote:
 Yeah, looks good.  Did we used to not touch the crtc in the plane
 cleanup?  Either way this is safer.

I think the bug only came to light because QA is now routinely running
with slub_debug.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel