All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carsten Haitzler <carsten.haitzler@foss.arm.com>
To: Brian Starkey <brian.starkey@arm.com>, james.qian.wang@arm.com
Cc: nd@arm.com, liviu.dudau@arm.com,
	Carsten Haitzler <carsten.haitzler@arm.com>,
	dri-devel@lists.freedesktop.org, steven.price@arm.com
Subject: Re: [PATCH] drm/komeda: Fix off-by-1 when with readback conn due to rounding
Date: Thu, 11 Mar 2021 11:55:08 +0000	[thread overview]
Message-ID: <b9832558-cb41-14a5-fadd-94f4b0aad81d@foss.arm.com> (raw)
In-Reply-To: <20210309113636.whdolt4v3k5qpgpx@DESKTOP-E1NTVVP.localdomain>

On 3/9/21 11:36 AM, Brian Starkey wrote:
> Hi Carsten, (+James for komeda)
> 
> Thanks for typing this up.
> 
> On Fri, Mar 05, 2021 at 04:38:53PM +0000, carsten.haitzler@foss.arm.com wrote:
>> From: Carsten Haitzler <carsten.haitzler@arm.com>
>>
>> When setting up a readback conenctor that writes data back to memory
> 
> s/readback conenctor/writeback connector/ (similar in the subject)
> 
>> rather than to an actual output device (HDMI etc.), rounding was ses
> 
> s/ses/set/

I swear I re-read the log text... I must be auto-correcting in my head 
as I read. :)

>> to round-down. As the DPU uses a higher internal number of bits when
> 
> "round-down" isn't really accurate - the rounding mode "rounds" based
> on the most-significant discarded bit - so can round-up too.
> 
> Come to think of it, I can't explain 0xff becoming 0xfe, but still,
> truncation is likely fine.

Actually it was the other way - I mixed up the src/dest, but TRC does 
fix it which is the important bit.

>> generating a color value, this round-down back to 8bit ended up with
>> everything being off-by one. e.g. #ffffff became #fefefe. This sets
>> rounding to "round" so things end up correct by turning on the round
>> flag (LW_TRC).
> 
> LW_TRC is the truncation flag. 0: Round, 1: Truncate
> 
>>
>> Signed-off-by: Carsten Haitzler <carsten.haitzler@arm.com>
>> ---
>>   drivers/gpu/drm/arm/display/komeda/d71/d71_component.c | 6 +++++-
>>   drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h      | 1 +
>>   2 files changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
>> index 8a02ade369db..d551e79fa0f1 100644
>> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
>> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
>> @@ -468,7 +468,11 @@ static void d71_wb_layer_update(struct komeda_component *c,
>>   	struct komeda_layer_state *st = to_layer_st(state);
>>   	struct drm_connector_state *conn_st = state->wb_conn->state;
>>   	struct komeda_fb *kfb = to_kfb(conn_st->writeback_job->fb);
>> -	u32 ctrl = L_EN | LW_OFM, mask = L_EN | LW_OFM | LW_TBU_EN;
>> +	/* LW_TRC sets rounding to round not truncate which is needed for
>> +         * the output of writeback to match the input in the most common
>> +         * use cases like RGB888 -> RGB888, so set this bit by default */
> 
> /*
>   * Comment style should be like this
>   */
> 
> Same as above though - your description is inverted. By setting the
> LW_TRC bit, you're forcing the hardware to truncate instead of round.

Yeah - inverted. But the source does have mixed comment styles with some
/*
  * xxxx
  */

and some

/* xxxx */

and some

/* xxxx
  */

with the last 2 most common.

>> +	u32 ctrl = L_EN | LW_OFM | LW_TRC;
>> +	u32 mask = L_EN | LW_OFM | LW_TBU_EN | LW_TRC;
> 
> Really nitpicking, but I think it'd be good to keep these in the same
> order as the bits in the register: L_EN | LW_TRC | LW_OFM | LW_TBU_EN

I can do that. I'll send another with the above.

> Cheers,
> -Brian
> 
>>   	u32 __iomem *reg = c->reg;
>>   
>>   	d71_layer_update_fb(c, kfb, st->addr);
>> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
>> index e80172a0b320..a8036689d721 100644
>> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
>> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
>> @@ -321,6 +321,7 @@
>>   #define LAYER_WR_FORMAT		0x0D8
>>   
>>   /* Layer_WR control bits */
>> +#define LW_TRC			BIT(1)
>>   #define LW_OFM			BIT(4)
>>   #define LW_LALPHA(x)		(((x) & 0xFF) << 8)
>>   #define LW_A_WCACHE(x)		(((x) & 0xF) << 28)
>> -- 
>> 2.30.0
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2021-03-11 11:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05 16:38 [PATCH] drm/komeda: Fix off-by-1 when with readback conn due to rounding carsten.haitzler
2021-03-09 11:36 ` Brian Starkey
2021-03-11 11:55   ` Carsten Haitzler [this message]
2021-03-11 12:08 carsten.haitzler
2021-03-12 10:55 ` Brian Starkey
2021-03-16  3:17   ` James Qian Wang
2021-03-29 15:27   ` Carsten Haitzler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b9832558-cb41-14a5-fadd-94f4b0aad81d@foss.arm.com \
    --to=carsten.haitzler@foss.arm.com \
    --cc=brian.starkey@arm.com \
    --cc=carsten.haitzler@arm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=james.qian.wang@arm.com \
    --cc=liviu.dudau@arm.com \
    --cc=nd@arm.com \
    --cc=steven.price@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.