Maxime Ripard <mripard@xxxxxxxxxx> writes:
> On Fri, Sep 01, 2023 at 09:48:09AM +0200, Javier Martinez Canillas wrote:
>> Thomas Zimmermann <tzimmermann@xxxxxxx> 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.
>
> If we want to go that road, we don't even need an extra allocation, it
> can be part of the state or object structure itself.
>
Yes, I meant to have it as fixed-length arrays. But still the best option
seems to be to allocate them but in the CRTC's .atomic_check() and store
them in a CRTC private state as Thomas suggested.
Geert will post a v2 of his R1 support patches, I'll wait for those and
after that try to implement Thomas' suggestion.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
