mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>, linux-kernel@vger.kernel.org
Cc: Maxime Ripard <mripard@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH] drm/ssd130x: Allocate buffer in the CRTC's .atomic_check() callback
Date: Fri, 01 Sep 2023 09:48:09 +0200	[thread overview]
Message-ID: <87ledqbah2.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <6654778d-1f40-1775-c32c-ebf9728bc9a9@suse.de>

Thomas Zimmermann <tzimmermann@suse.de> writes:

> Hi Javier,
>
> another idea about this patch: why not just keep the allocation in the 
> plane's atomic check, but store the temporary buffers in a plane struct. 
> You'd only grow the arrays length in atomic_check and later fetch the 
> pointers in atomic_update. It needs some locking, but nothing complicated.
>

Yes, that would work too. Another option is to just move the buffers to
struct ssd130x_device as it was before commit 45b58669e532 ("drm/ssd130x:
Allocate buffer in the plane's .atomic_check() callback") but just make
them fixed arrays with the size of the biggest format.

That will be some memory wasted but will prevent the problem of trying to
allocate buffers after drm_atomic_helper_swap_state() has been called.

> Best regards
> Thomas
>
> Am 30.08.23 um 08:25 schrieb Javier Martinez Canillas:

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


  reply	other threads:[~2023-09-01  7:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-30  6:25 Javier Martinez Canillas
2023-08-30  7:08 ` Thomas Zimmermann
2023-08-30  7:40   ` Geert Uytterhoeven
2023-08-30  7:45     ` Thomas Zimmermann
2023-09-01  6:53 ` Thomas Zimmermann
2023-09-01  7:48   ` Javier Martinez Canillas [this message]
2023-09-01  8:25     ` Maxime Ripard
2023-09-01  9:19       ` Javier Martinez Canillas
2023-09-01 10:59     ` Thomas Zimmermann
2023-09-01 11:50       ` Javier Martinez Canillas
2023-09-01  8:22 ` Maxime Ripard
2023-09-01  8:36   ` Geert Uytterhoeven
2023-09-01  9:23     ` Javier Martinez Canillas
2023-09-01 12:00     ` Maxime Ripard
2023-09-01 12:08       ` Geert Uytterhoeven
2023-09-01 12:21         ` Javier Martinez Canillas
2023-09-04  8:04         ` Maxime Ripard
2023-09-06 12:04           ` Javier Martinez Canillas

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=87ledqbah2.fsf@minerva.mail-host-address-is-not-set \
    --to=javierm@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mripard@kernel.org \
    --cc=tzimmermann@suse.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

all inboxes | Powered by JetHome®