diff mbox series

[4/4] drm/atmel-hlcdc: do not immediately disable planes, wait for next frame

Message ID 20190110151020.30468-5-peda@axentia.se (mailing list archive)
State New, archived
Headers show
Series drm/atmel-hlcdc: fix plane clipping/rotation issues | expand

Commit Message

Peter Rosin Jan. 10, 2019, 3:10 p.m. UTC
The A2Q and UPDATE bits have no effect in the channel disable registers.
However, since they are present, assume that the intention is to disable
planes, not immediately as indicated by the RST bit, but on the next
frame shift since that is what A2Q and UPDATE means in the channel enable
registers.

Disabling the plane on the next frame shift is done with the EN bit,
so use that.

Signed-off-by: Peter Rosin <peda@axentia.se>
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

Comments

Boris Brezillon Jan. 10, 2019, 5:29 p.m. UTC | #1
On Thu, 10 Jan 2019 15:10:48 +0000
Peter Rosin <peda@axentia.se> wrote:

> The A2Q and UPDATE bits have no effect in the channel disable registers.
> However, since they are present, assume that the intention is to disable
> planes, not immediately as indicated by the RST bit, but on the next
> frame shift since that is what A2Q and UPDATE means in the channel enable
> registers.
> 
> Disabling the plane on the next frame shift is done with the EN bit,
> so use that.

It's been a long time, but I think I had a good reason for forcing a
reset. IIRC, when you don't do that and the CRTC is disabled before the
plane, the EN bit stays around, and next time you queue a plane update,
you'll start with an invalid buf pointer.

> 
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 05519e8c6586..f2f570642f84 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -728,9 +728,7 @@ static void atmel_hlcdc_plane_atomic_disable(struct drm_plane *p,
>  
>  	/* Disable the layer */
>  	atmel_hlcdc_layer_write_reg(&plane->layer, ATMEL_HLCDC_LAYER_CHDR,
> -				    ATMEL_HLCDC_LAYER_RST |
> -				    ATMEL_HLCDC_LAYER_A2Q |
> -				    ATMEL_HLCDC_LAYER_UPDATE);
> +				    ATMEL_HLCDC_LAYER_EN);
>  
>  	/* Clear all pending interrupts */
>  	atmel_hlcdc_layer_read_reg(&plane->layer, ATMEL_HLCDC_LAYER_ISR);
Peter Rosin Jan. 10, 2019, 6:51 p.m. UTC | #2
On 2019-01-10 18:29, Boris Brezillon wrote:
> On Thu, 10 Jan 2019 15:10:48 +0000
> Peter Rosin <peda@axentia.se> wrote:
> 
>> The A2Q and UPDATE bits have no effect in the channel disable registers.
>> However, since they are present, assume that the intention is to disable
>> planes, not immediately as indicated by the RST bit, but on the next
>> frame shift since that is what A2Q and UPDATE means in the channel enable
>> registers.
>>
>> Disabling the plane on the next frame shift is done with the EN bit,
>> so use that.
> 
> It's been a long time, but I think I had a good reason for forcing a
> reset. IIRC, when you don't do that and the CRTC is disabled before the
> plane, the EN bit stays around, and next time you queue a plane update,
> you'll start with an invalid buf pointer.

It might be possible to clear the EN bit in ...CHDR before enabling the
plane in ...CHER. Or is that too late? But this patch is not overly
important, I just wanted to avoid the resulting "black hole" when the
plane DMA is disabled mid-frame. But disabling planes is probably not
something that happens frequently and will perhaps not be noticed at
all...

Cheers,
Peter

>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>> ---
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> index 05519e8c6586..f2f570642f84 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> @@ -728,9 +728,7 @@ static void atmel_hlcdc_plane_atomic_disable(struct drm_plane *p,
>>  
>>  	/* Disable the layer */
>>  	atmel_hlcdc_layer_write_reg(&plane->layer, ATMEL_HLCDC_LAYER_CHDR,
>> -				    ATMEL_HLCDC_LAYER_RST |
>> -				    ATMEL_HLCDC_LAYER_A2Q |
>> -				    ATMEL_HLCDC_LAYER_UPDATE);
>> +				    ATMEL_HLCDC_LAYER_EN);
>>  
>>  	/* Clear all pending interrupts */
>>  	atmel_hlcdc_layer_read_reg(&plane->layer, ATMEL_HLCDC_LAYER_ISR);
>
Boris Brezillon Jan. 10, 2019, 7:25 p.m. UTC | #3
On Thu, 10 Jan 2019 18:51:21 +0000
Peter Rosin <peda@axentia.se> wrote:

> On 2019-01-10 18:29, Boris Brezillon wrote:
> > On Thu, 10 Jan 2019 15:10:48 +0000
> > Peter Rosin <peda@axentia.se> wrote:
> >   
> >> The A2Q and UPDATE bits have no effect in the channel disable registers.
> >> However, since they are present, assume that the intention is to disable
> >> planes, not immediately as indicated by the RST bit, but on the next
> >> frame shift since that is what A2Q and UPDATE means in the channel enable
> >> registers.
> >>
> >> Disabling the plane on the next frame shift is done with the EN bit,
> >> so use that.  
> > 
> > It's been a long time, but I think I had a good reason for forcing a
> > reset. IIRC, when you don't do that and the CRTC is disabled before the
> > plane, the EN bit stays around, and next time you queue a plane update,
> > you'll start with an invalid buf pointer.  
> 
> It might be possible to clear the EN bit in ...CHDR before enabling the
> plane in ...CHER. Or is that too late?

I think I tried that, but I'm not sure (BTW, this change was done in
bd4248bb5e8b ("drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when
disabling it")). Anyway, I'm not even sure this is still needed now
that atomic updates have a wait_for_flip_done/vblank() in the commit
path.

> But this patch is not overly
> important, I just wanted to avoid the resulting "black hole" when the
> plane DMA is disabled mid-frame. But disabling planes is probably not
> something that happens frequently and will perhaps not be noticed at
> all...

Okay. Other patches look good to me, I'm just waiting for Nicolas
feedback before applying them.
Peter Rosin Jan. 11, 2019, 2:29 p.m. UTC | #4
On 2019-01-10 20:25, Boris Brezillon wrote:
> On Thu, 10 Jan 2019 18:51:21 +0000
> Peter Rosin <peda@axentia.se> wrote:
> 
>> On 2019-01-10 18:29, Boris Brezillon wrote:
>>> On Thu, 10 Jan 2019 15:10:48 +0000
>>> Peter Rosin <peda@axentia.se> wrote:
>>>   
>>>> The A2Q and UPDATE bits have no effect in the channel disable registers.
>>>> However, since they are present, assume that the intention is to disable
>>>> planes, not immediately as indicated by the RST bit, but on the next
>>>> frame shift since that is what A2Q and UPDATE means in the channel enable
>>>> registers.
>>>>
>>>> Disabling the plane on the next frame shift is done with the EN bit,
>>>> so use that.  
>>>
>>> It's been a long time, but I think I had a good reason for forcing a
>>> reset. IIRC, when you don't do that and the CRTC is disabled before the
>>> plane, the EN bit stays around, and next time you queue a plane update,
>>> you'll start with an invalid buf pointer.  
>>
>> It might be possible to clear the EN bit in ...CHDR before enabling the
>> plane in ...CHER. Or is that too late?
> 
> I think I tried that, but I'm not sure (BTW, this change was done in
> bd4248bb5e8b ("drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when

That patch is a big fat NOP if you read the documentation. Those bits
are marked with a '-' for all LCDC channel disable registers, for all
supported chips IIUC. Are the effects of those bits mentioned in any
errata?

It would be good with a comment that the present undocumented disable
method is intentional. That would have kept me from assuming the whole
thing was just copy-paste junk from ..._enable that happened to work.

>> disabling it")). Anyway, I'm not even sure this is still needed now
>> that atomic updates have a wait_for_flip_done/vblank() in the commit
>> path.

The documentation for the RST bit states "Resets the layer immediately.
The frame is aborted." which sounds a bit scary and heavy-handed. But
again, I don't know what that actually means and what the effects are
but that was the reason for me wanting to avoid the RST bit.

Cheers,
Peter

>> But this patch is not overly
>> important, I just wanted to avoid the resulting "black hole" when the
>> plane DMA is disabled mid-frame. But disabling planes is probably not
>> something that happens frequently and will perhaps not be noticed at
>> all...
> 
> Okay. Other patches look good to me, I'm just waiting for Nicolas
> feedback before applying them.
>
Boris Brezillon Jan. 16, 2019, 2:45 p.m. UTC | #5
On Fri, 11 Jan 2019 14:29:28 +0000
Peter Rosin <peda@axentia.se> wrote:

> On 2019-01-10 20:25, Boris Brezillon wrote:
> > On Thu, 10 Jan 2019 18:51:21 +0000
> > Peter Rosin <peda@axentia.se> wrote:
> >   
> >> On 2019-01-10 18:29, Boris Brezillon wrote:  
> >>> On Thu, 10 Jan 2019 15:10:48 +0000
> >>> Peter Rosin <peda@axentia.se> wrote:
> >>>     
> >>>> The A2Q and UPDATE bits have no effect in the channel disable registers.
> >>>> However, since they are present, assume that the intention is to disable
> >>>> planes, not immediately as indicated by the RST bit, but on the next
> >>>> frame shift since that is what A2Q and UPDATE means in the channel enable
> >>>> registers.
> >>>>
> >>>> Disabling the plane on the next frame shift is done with the EN bit,
> >>>> so use that.    
> >>>
> >>> It's been a long time, but I think I had a good reason for forcing a
> >>> reset. IIRC, when you don't do that and the CRTC is disabled before the
> >>> plane, the EN bit stays around, and next time you queue a plane update,
> >>> you'll start with an invalid buf pointer.    
> >>
> >> It might be possible to clear the EN bit in ...CHDR before enabling the
> >> plane in ...CHER. Or is that too late?  
> > 
> > I think I tried that, but I'm not sure (BTW, this change was done in
> > bd4248bb5e8b ("drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when  
> 
> That patch is a big fat NOP if you read the documentation. Those bits
> are marked with a '-' for all LCDC channel disable registers, for all
> supported chips IIUC. Are the effects of those bits mentioned in any
> errata?

IIRC, it was not documented in the datasheet, but this came out during
a discussion with the IP designer.

> 
> It would be good with a comment that the present undocumented disable
> method is intentional.

Yes, I should have added a comment about that, my bad.

> That would have kept me from assuming the whole
> thing was just copy-paste junk from ..._enable that happened to work.
> 
> >> disabling it")). Anyway, I'm not even sure this is still needed now
> >> that atomic updates have a wait_for_flip_done/vblank() in the commit
> >> path.  
> 
> The documentation for the RST bit states "Resets the layer immediately.
> The frame is aborted." which sounds a bit scary and heavy-handed. But
> again, I don't know what that actually means and what the effects are
> but that was the reason for me wanting to avoid the RST bit.

As I said, I'm not even sure the problem I was trying to fix still
exists.
diff mbox series

Patch

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 05519e8c6586..f2f570642f84 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -728,9 +728,7 @@  static void atmel_hlcdc_plane_atomic_disable(struct drm_plane *p,
 
 	/* Disable the layer */
 	atmel_hlcdc_layer_write_reg(&plane->layer, ATMEL_HLCDC_LAYER_CHDR,
-				    ATMEL_HLCDC_LAYER_RST |
-				    ATMEL_HLCDC_LAYER_A2Q |
-				    ATMEL_HLCDC_LAYER_UPDATE);
+				    ATMEL_HLCDC_LAYER_EN);
 
 	/* Clear all pending interrupts */
 	atmel_hlcdc_layer_read_reg(&plane->layer, ATMEL_HLCDC_LAYER_ISR);