Re: [PATCH] Fix failure of simpledrm probe when trying to grab FB from the EFI-based Framebuffer

[Andrew Worsley]

On Sat, 11 Nov 2023 at 20:10, Javier Martinez Canillas
<javierm@xxxxxxxxxx> wrote:
>
....
> > On Sat, 11 Nov 2023 at 15:30, Andrew Worsley <amworsley@xxxxxxxxx> wrote:
> >>
> >>    The simpledrm.c does not call aperture_remove_conflicting_devices() in it's probe
> >>    function as the drivers/video/aperture.c documentation says it should. Consequently
> >>    it's request for the FB memory fails.
> >>
>
> The current behaviour is correct since aperture_remove_conflicting_devices()
> is for native drivers to remove simple framebuffer devices such as simpledrm,
> simplefb, efifb, etc.

The efifb is the driver that has "grabbed" the FB earlier

Here's a debug output with a dump_stack() call in the devm_aperture_acquire()
% grep --color -A14 -B4 devm_aperture_acquire ~/dmesg2.txt
[    0.055752] efifb: framebuffer at 0xbd58dc000, using 16000k, total 16000k
[    0.055755] efifb: mode is 2560x1600x32, linelength=10240, pages=1
[    0.055758] efifb: scrolling: redraw
[    0.055759] efifb: Truecolor: size=2:10:10:10, shift=30:20:10:0
[    0.055771] devm_aperture_acquire: dump stack for debugging
[    0.055775] CPU: 2 PID: 1 Comm: swapper/0 Tainted: G S
   6.5.0-asahi-005
52-gb486fd3ed8fc-dirty #26
[    0.055779] Hardware name: Apple MacBook Air (M1, 2020) (DT)
[    0.055782] Call trace:
[    0.055784]  dump_backtrace+0xfc/0x150
[    0.055790]  show_stack+0x24/0x40
[    0.055793]  dump_stack_lvl+0x50/0x68
[    0.055797]  dump_stack+0x18/0x28
[    0.055800]  devm_aperture_acquire_for_platform_device+0x4c/0x190
[    0.055806]  efifb_probe+0x794/0x850
[    0.055809]  platform_probe+0xb4/0xe8
[    0.055815]  really_probe+0x178/0x410
[    0.055819]  __driver_probe_device+0xb0/0x180
[    0.055823]  driver_probe_device+0x50/0x258
[    0.055826]  __driver_attach+0x10c/0x270
[    0.055830]  bus_for_each_dev+0x90/0xf0
[    0.055832]  driver_attach+0x30/0x48
[    0.055835]  bus_add_driver+0x100/0x220
[    0.055838]  driver_register+0x74/0x118
[    0.055842]  __platform_driver_register+0x30/0x48
[    0.055846]  efifb_driver_init+0x28/0x40
[    0.055850]  do_one_initcall+0xe0/0x2f0
[    0.055853]  do_initcall_level+0xa4/0x128
--
[    2.724249] systemd-journald[277]: varlink-22: Changing state
pending-disconnect \xe2\
x86\x92 processing-disconnect
[    2.725413] systemd-journald[277]: varlink-22: Changing state
processing-disconnect \x
e2\x86\x92 disconnected
[    2.758337] systemd-journald[277]: Successfully sent stream file
descriptor to service
 manager.
[    2.765929] systemd-journald[277]: Successfully sent stream file
descriptor to service
 manager.
[    3.022207] devm_aperture_acquire: dump stack for debugging
[    3.024280] CPU: 3 PID: 56 Comm: kworker/u16:1 Tainted: G S
        6.5.0-asah
i-00552-gb486fd3ed8fc-dirty #26
[    3.026385] Hardware name: Apple MacBook Air (M1, 2020) (DT)
[    3.028483] Workqueue: events_unbound deferred_probe_work_func
[    3.030554] Call trace:
[    3.032564]  dump_backtrace+0xfc/0x150
[    3.034580]  show_stack+0x24/0x40
[    3.036557]  dump_stack_lvl+0x50/0x68
[    3.038500]  dump_stack+0x18/0x28
[    3.040408]  devm_aperture_acquire_for_platform_device+0x4c/0x190
[    3.042322]  devm_aperture_acquire_from_firmware+0x40/0x90
[    3.044226]  simpledrm_probe+0x800/0xe18
[    3.046109]  platform_probe+0xb4/0xe8
[    3.047992]  really_probe+0x178/0x410
[    3.049840]  __driver_probe_device+0xb0/0x180
[    3.051684]  driver_probe_device+0x50/0x258
[    3.053453]  __device_attach_driver+0x148/0x1f8
[    3.055162]  bus_for_each_drv+0x98/0xf8
[    3.056814]  __device_attach+0x108/0x1d0
[    3.058436]  device_initial_probe+0x20/0x38
[    3.060024]  bus_probe_device+0x4c/0xb8
[    3.061603]  deferred_probe_work_func+0xb8/0x120
[    3.063175]  process_one_work+0x1f0/0x458
[    3.064715]  worker_thread+0x2b8/0x4d0
[    3.066233]  kthread+0xe4/0x180

>
> >> ...
> >> [    3.085302] simple-framebuffer bd58dc000.framebuffer: [drm] *ERROR* could not acquire memory range [??? 0xffff6e1d8629d580-0x2a5000001a7 flags 0x0]: -16
> >> [    3.086433] simple-framebuffer: probe of bd58dc000.framebuffer failed with error -16
> >> ...
> >>
>
> This is -EBUSY. What is your kernel configuration? Can you share it please.

Attached - hope that's acceptable...


>
> >>    In my case no driver provided /dev/dri/card0 device is available on boot up and X
> >>    fails to start as per this from X start up log.
> >>
> >> ...
> >> [     5.616] (WW) Falling back to old probe method for modesetting
> >> [     5.616] (EE) open /dev/dri/card0: No such file or directory
> >> ...
> >>
> >>    Fault confirmed and fixed on Asahi 6.5.0 kernel with both CONFIG_FB_EFI and
> >>    CONFIG_DRM_SIMPLEDRM config options set.
> >>
> >> Signed-off-by: Andrew Worsley <amworsley@xxxxxxxxx>
> >> ---
>
> I wonder if this is anothe side effect of commit 60aebc955949
> ("drivers/firmware: Move sysfb_init() from device_initcall to
> subsys_initcall_sync").
>
> Can you try reverting that one and see if it helps?

Nope that still failing:
...
[    3.295896] simple-framebuffer bd58dc000.framebuffer: [drm] *ERROR*
could not acquire memory range [??? 0xffff79f30a29ee40-0x2a5000001a7
flags 0x0]: -16
[    3.298018] simple-framebuffer: probe of bd58dc000.framebuffer
failed with error -16
...
>
....
>
> DRM drivers should use drm_aperture_remove_framebuffers() instead. But
> this shouldn't be needed for the simpledrm driver as mentioned, since
> there shouldn't be another device grabbing this aperture at this point.

Ok tried this and it works:
 % d
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index c23bc4079a11..04d37ec98b29 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -859,6 +859,13 @@ static struct simpledrm_device
*simpledrm_device_create(struct drm_driver *drv,
        drm_dbg(dev, "framebuffer format=%p4cc, size=%dx%d, stride=%d byte\n",
                &format->format, width, height, stride);

+        /* Clear any other driver which holds it */
+        ret = drm_aperture_remove_framebuffers(drv);
+        if (ret) {
+                drm_err(dev, "drm_aperture_remove_framebuffers:%d\n",
__func__, ret);
+                return ERR_PTR(ret);
+        }
+
        /*
         * Memory management
         */

drm_aperture_remove_framebuffers() seems to eventually call
aperture_remove_conflicting_devices() with base=0 and size = -1
which I presume means memory anywhere.

>
> I would rather try to understand what is going on in your setup and why
> the acquire is returning -EBUSY.
>

Ok - thanks - let me know where to go from here.

Andrew

Attachment: config-6.5.0-asahi-00552-gb486fd3ed8f.gz
Description: application/gzip