From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Nam Cao <namcao@linutronix.de>
Cc: Andy Shevchenko <andy@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: fbtft: Optimize partial write()
Date: Fri, 13 Feb 2026 12:18:51 +0200 [thread overview]
Message-ID: <aY76ixvOUEkvoPk0@smile.fi.intel.com> (raw)
In-Reply-To: <20260213085946.3673695-1-namcao@linutronix.de>
On Fri, Feb 13, 2026 at 09:59:46AM +0100, Nam Cao wrote:
> When user write() only to part of the screen, the driver still updates the
> entire screen. That wastes CPU cycles.
>
> Optimize by updating only the changed lines. Improvement is measured by a
> pair of trace_printk() at the beginning of fb_write() and at the end of
> fbtft_deferred_io().
Can you elaborate on the HW (the exact model of the panel and [sub]driver)
in use?
> Update type Before After
> ====================================
> full screen 196ms 200ms
> half screen 200ms 124ms
> quarter screen 193ms 81ms
> one pixle 199ms 43ms
>
> It is interesting to note that if the deferred IO's delay time (40ms) is
> subtracted, then the time amount scales linearly with the write size.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Some questions below, but they probably won't affect the decision on this change.
...
> - /* special case, needed ? */
Do you know the history of this comment? What is "special case" and when does it appear?
> - if (y == -1) {
> - y = 0;
> - height = info->var.yres;
> - }
...
> static void fbtft_ops_damage_range(struct fb_info *info, off_t off, size_t len)
> {
> struct fbtft_par *par = info->par;
> + u32 start, end;
> +
> + start = off / info->fix.line_length;
> + end = (off + len - 1) / info->fix.line_length;
>
> - /* TODO: only mark changed area update all for now */
Ah, this change actually targets the TODO!
> - par->fbtftops.mkdirty(info, -1, 0);
> + par->fbtftops.mkdirty(info, start, end - start + 1);
> }
...
In light of the last TODO line I think that the change is desired by
the original author. Nevertheless I am wondering about these side effects
that might be (very unlikely?) considered if this code (partial refresh)
runs for a significant period of time:
- some bits of the screen (on non-updated part) might be flipped
- the static picture may lead to wearing of (decolourisation) the panel
- what is the thermal distribution (probably with backlight off)?
Maybe it makes sense to refresh a full screen from time to time, but
TBH my knowledge of TFT panels from last decade is quite limited. I only
think from the point of the general physics and common sense. That's
why this long footnote rather philosophical, but I would be glad to
learn the state of affairs of the modern TFT panels in terms of the
physical parameters lasting over the time under different application
cases.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-02-13 10:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 8:59 [PATCH] staging: fbtft: Optimize partial write() Nam Cao
2026-02-13 10:18 ` Andy Shevchenko [this message]
2026-02-14 1:56 ` Nam Cao
2026-02-14 18:06 ` Andy Shevchenko
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=aY76ixvOUEkvoPk0@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=namcao@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox