On Sat, 11 Nov 2023 at 20:10, Javier Martinez Canillas wrote: > .... > > On Sat, 11 Nov 2023 at 15:30, Andrew Worsley 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 > >> --- > > 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