Linux Framebuffer Layer development
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: Thomas Zimmermann <tzimmermann@suse.de>,
	linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/todo: Drop todo item to request memory regions in all fbdev drivers
Date: Fri, 24 Apr 2026 10:39:21 +0200	[thread overview]
Message-ID: <5ccb6ea6-37e5-48c9-a6cf-f794edf7a7fd@gmx.de> (raw)
In-Reply-To: <3fe83b69-b868-45a8-9862-50c6f0fdeb95@suse.de>

On 4/24/26 08:57, Thomas Zimmermann wrote:
> Hi
> 
> Am 23.04.26 um 22:55 schrieb Helge Deller:
>> This item is tagged for beginners, so often people not familiar with
>> the fbdev drivers think this is an easy task, start up their AI tools
>> and blindly send in the generated code as patches.
>>
>> The problem:
>> - Those patches often introduce bugs, so
>> - ideally want the code tested, since ressource misconfigurations
>>    often lead to failing drivers
>> - The patches are often unnecessary, since in the old machines with the
>>    old graphic cards resource conflicts usually don't happen as only one
>>    graphic card can be used at a time anyway.
>> - and today most relevant drivers have necessary patches already
>>    implemented.
>>
>> So, let's get rid of this todo item and silence the steady stream of
>> stupid patches.
> 
> I see that AI patches can be problematic, but reserving these
> regions is still the correct thing to do. Removing the TODO item
> will not change that.

Sure.
  
> Some background on why this item exists: we currently use aperture
> helpers [1] to manage ownership of the framebuffer memory during
> boot up. This is necessary to switch from the system-framebuffer
> driver (i..e, simplefb, simpledrm, etc) to the hardware's native
> driver. But this is all ad-hoc because Linux' resource management
> doesn't do this for us. Before we can integrate any such
> functionality, we have to fix all drivers to reserve their resources
> correctly.
> 
> If we remove the TODO item, we'd likely still want to move forward
> with improving resource management. If that breaks unfixed fbdev
> drivers, users would then also send bug reports.

Ok for me.

Helge

> And the other point is (again) that if there are no means of testing a driver and no information whether a driver is actually in used by anyone, it's maybe time to remove the driver.
> 
> [1] https://elixir.bootlin.com/linux/v7.0.1/source/drivers/video/aperture.c#L17
> 
> Best regards
> Thomas
> 
> 
>>
>> Signed-off-by: Helge Deller <deller@gmx.de>
>> ---
>>   Documentation/gpu/todo.rst | 16 ----------------
>>   1 file changed, 16 deletions(-)
>>
>> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
>> index bc9f14c8a2ec..b4dd64a8cc06 100644
>> --- a/Documentation/gpu/todo.rst
>> +++ b/Documentation/gpu/todo.rst
>> @@ -448,22 +448,6 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>
>>   Level: Intermediate
>> -Request memory regions in all fbdev drivers
>> ---------------------------------------------
>> -
>> -Old/ancient fbdev drivers do not request their memory properly.
>> -Go through these drivers and add code to request the memory regions
>> -that the driver uses. This requires adding calls to request_mem_region(),
>> -pci_request_region() or similar functions. Use helpers for managed cleanup
>> -where possible. Problematic areas include hardware that has exclusive ranges
>> -like VGA. VGA16fb does not request the range as it is expected.
>> -Drivers are pretty bad at doing this and there used to be conflicts among
>> -DRM and fbdev drivers. Still, it's the correct thing to do.
>> -
>> -Contact: Thomas Zimmermann <tzimmermann@suse.de>
>> -
>> -Level: Starter
>> -
>>   Remove driver dependencies on FB_DEVICE
>>   ---------------------------------------
> 


      reply	other threads:[~2026-04-24  8:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-23 20:55 [PATCH] drm/todo: Drop todo item to request memory regions in all fbdev drivers Helge Deller
2026-04-24  6:43 ` Geert Uytterhoeven
2026-04-24  7:01   ` Thomas Zimmermann
2026-04-24  8:36     ` Helge Deller
2026-04-24  8:52       ` Thomas Zimmermann
2026-04-24  6:57 ` Thomas Zimmermann
2026-04-24  8:39   ` Helge Deller [this message]

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=5ccb6ea6-37e5-48c9-a6cf-f794edf7a7fd@gmx.de \
    --to=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.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