<javierm>
not as I remembered, it seems robher wasn't sure either and Arnd said that the EFI-GOP was too dumb to know about stuff like regulators, clocks, etc and that OF should take precedence
<javierm>
*Ard
<javierm>
tzimmermann: I don't know what to say :) If you can convince people that OF should skip registering the device and rely on sysfb if a screen_info is filled, I'm OK with that
Company has quit [Ping timeout: 480 seconds]
SquareWinter68 has quit [Ping timeout: 480 seconds]
SquareWinter68 has joined #dri-devel
<tzimmermann>
javierm, that argument about regulators/clocks makes some sense
<tzimmermann>
i guess i leve it at that. although i'm still a bit worried that this will blow up somehow
<arnd>
tzimmermann: I think it would be nice to eventually get to making sysfb and screen_info completely x86 specific and remove them from the generic EFI code.
<tzimmermann>
arnd, sounds good
<tzimmermann>
what would be required?
<javierm>
arnd: the problem is when using EFI + ACPI on arm64, so not really x86 specific
<javierm>
tzimmermann: I don't is needed because AFAIK on PPC there's no combination with EFI-GOP to cause issues like for arm64
<tzimmermann>
ok
<javierm>
arnd: sysfb used to be x86 specific but we needed to make it platform independent to support simpledrm without OF on aarch64
pcercuei has joined #dri-devel
<javierm>
and even on x86 we have issues due the mentioned Coreboot + SeaBIOS where both firmware pass a sysfb description to the kernel
<javierm>
just like happens with DT/OF + u-boot/EFI-GOP
<tzimmermann>
javierm, i've been wrapping my head around bringing all this into some coherent design for some time. but it seem slike there's nothing we can do easily
<javierm>
same. It's all messy but I couldn't find a way to make it tidy
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
pixelcluster_ has quit []
lsntvt has joined #dri-devel
pixelcluster has joined #dri-devel
<tzimmermann>
javierm, BTW i've been posting an hdlcd patch this week, which you might want to take a look at
lsntvt has quit []
<tzimmermann>
javierm, anyway thanks for discussing this issue
lsntvt has joined #dri-devel
<javierm>
tzimmermann: reviewed
<arnd>
tzimmermann: what are the cases in which sysfb still registers a "efi-framebuffer" device instead of "simple-framebuffer" one? I would have expected all non-x86 platforms to come up with something that is complatible with simple-framebuffer
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
<javierm>
arnd: if someone is using the old efifb driver, since that only matches with an "efi-framebuffer" pdev
rasterman has joined #dri-devel
<arnd>
javierm: I thought it was the other way round: if you have a firmware that advertises a device that is incompatible with simpledrm, then you would need to use efifb
<javierm>
arnd: oh, you are right. I was looking now and the new efidrm also matches with "efi-framebuffer"
<arnd>
if the problem only exists for users that enable efifb, and it goes away by turning efifb off, couldn't we just make efifb config depend on !SIMPLEDRM
<javierm>
arnd: yeah, you are correct. It's a fallback if sysfb_parse_mode() is false and screen_info .orig_video_isVGA == VIDEO_TYPE_EFI
<arnd>
javierm: oh, I was looking at a 6.15 source tree, which doesn't have efidrm
<javierm>
arnd: yeah, that's in queue for 6.16
<javierm>
arnd: and I also wonder what type of platforms would not have a sysfb compatible format while setting VIDEO_TYPE_EFI
<javierm>
tzimmermann: do you know? ^
<arnd>
I think traditionally it was planar 16-colort vgafb
<javierm>
arnd: but wouldn't that set VIDEO_TYPE_EGAC or VIDEO_TYPE_VGAC ?
<arnd>
but if now both efidrm and simpledrm use the common sysfb, I would expect them to either both be able to do it or both be incmpatible
Nasina has quit [Read error: Connection reset by peer]
pcercuei has quit [Read error: No route to host]
<javierm>
arnd: indeed
<javierm>
once can also force for {efi,vesa}-framebuffer devices to be registered instead of "simple-framebuffer" by disabling CONFIG_SYSFB_SIMPLEFB
<arnd>
javierm: it's been too long for me that I looked at this stuff, but my impression was that vga16fb (VIDEO_TYPE_VGAC) is only for the IBM compatible 640x480 resolution, while any higher resolution would have to go through a BIOS initialization or svgalib to set it up.
<javierm>
arnd: I was asking because looking at drivers/video/fbdev/vga16fb.c, it checks if either of those types are set and if not it returns -ENODEV
<javierm>
so yeah, it seems that unless there's some EFI emulation for a BIOS setting a vga16fb format, the case of incompatible mode + VIDEO_TYPE_EFI will never happen
<tzimmermann>
arnd, anything-EFI should work with sysfb
<javierm>
tzimmermann: then the fallback is only for the case when CONFIG_SYSFB_SIMPLEFB is disabled?
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
<tzimmermann>
javierm, you can enable SYSFB_SIMPLEFB and boot on a plain-VGA system. that would give vga16fb
<javierm>
tzimmermann: yes, but I meant for the EFI case
<tzimmermann>
and there are VESA modes that are not supported by simpledrm. booting this load vesadrm/vesafb
<javierm>
that is, "efi-framebuffer" will never be registered if SYSFB_SIMPLEFB is enabled
<tzimmermann>
for the EFI cases, all modes should be supported by simple-frambuffer
<tzimmermann>
so, yes, efidrm/efifb would not be used
<javierm>
right. So the fallback in drivers/firmware/sysfb.c is only SYSFB_SIMPLEFB disabled
<javierm>
*only for
Nasina has joined #dri-devel
<tzimmermann>
not quite sure i understand. there are still non-EFI systems in use. (?)
<javierm>
tzimmermann: the fallback for the EFI case I meant
<tzimmermann>
yeah, i don't think you could trigger it
<javierm>
but thanks for the explanation, that makes sense
<tzimmermann>
TBH i think we should advice against SYSFB_SIMPLEFB=y. with efidrm/vesadrm there will be better alternatives.
<javierm>
indeed. It's just that is easier for distros to just built-in simpledrm than also built-in efidrm and vesadrm
<javierm>
but simplefb, vesafb and efifb were built-in before, so shouldn't be an issue
kts has joined #dri-devel
warpme has quit []
kts has quit [Ping timeout: 480 seconds]
Nasina has quit [Read error: Connection reset by peer]
Jeremy_Rand_Talos has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
Nasina has quit [Ping timeout: 480 seconds]
davispuh has joined #dri-devel
kts has joined #dri-devel
<arnd>
tzimmermann: I see that sysfb is disabled in of_platform_default_populate_init() when the dtb contains one or more "simple-framebuffer" device, so efidrm should not even be used in that case and this seems to be the reasonable choice to me for embedded systems
<arnd>
would it be possible to drop the case of sysfb creating its own "simple-framebuffer" platform device for sysfb instead? That way a kernel can have both efidrm and simpledrm built-in and the default choice becomes the best case in all combinations:
<arnd>
- on embedded machines with just one on-chip framebuffer, this gets picked up from the devicetree as simpledrm, while efidrm ignores it
davispuh has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
<arnd>
- on PC-style machines with PCIe graphics, sysfb registers the framebuffer on the PCIe device, and drivers/video/aperture.c unregisters it while probing the hardware driver
<arnd>
It seems like the code in drivers/firmware/sysfb.c that registers the simplefb-framebuffer device was only really needed for DRM-only builds without efifb, but now that efidrm exists, there is no need for that any more.
<arnd>
the only change would be for users that used to rely on simplefb to pick up an EFI framebuffer, but they can change to efifb or efidrm
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
asrivats__ has joined #dri-devel
<javierm>
arnd: as mentioned, disabling CONFIG_SYSFB_SIMPLEFB already does what you suggest
<javierm>
but I think we can't make it unconditionally due some distros only enabling simpledrm instead of {efi,vesa}drm
<tzimmermann>
arnd, we have arm machines with DT and grub. they see both sysfb and the OF device. raspi is one
<javierm>
tzimmermann: I think is u-boot and not grub that registers the EFI-GOP table? But yes
<tzimmermann>
and we have arm machines with only efi/grub, but not DT
<arnd>
javierm: sorry, I confused CONFIG_DRM_SIMPLEDRM and CONFIG_SYSFB_SIMPLEFB
<tzimmermann>
javierm, right. but you get the idea
<javierm>
tzimmermann: yeah
<javierm>
arnd: too many CONFIG_*_SIMPLE* :)
<tzimmermann>
to reliably detect this, sysfb needs a way to detect simple-framebuffer node from within sysfb. but that's no more trivial than calling sysfb_disable() directly
<arnd>
maybe the initcall order is wrong and the sysfb device gets created after of_platform_default_populate_init)()?
<javierm>
arnd: yeah, I believe that it relies on the init call ordering
<javierm>
which is fragile...
asrivats__ has quit [Ping timeout: 480 seconds]
<javierm>
arnd: sysfb is at device_initcall level while the of is at arch_initcall_sync
<javierm>
so the of code will disable sysfb before its init callback
<arnd>
javierm: but then sysfb_init() also does "if (disabled) return 0;"
<javierm>
arnd: yes, but that's OK because of_platform_default_populate() will register the "simple-framebuffer" device in that case
<arnd>
javierm: I mean the "disabled" logic seems to be broken if there are machines that still register the efi sysfb device despite sysfb being disabled early
<javierm>
arnd: sorry, I'm not following
<javierm>
ff a machine has both a OF "simple-frambuffer" DT node and an EFI-GOP table (that will fill screen_info with type == VIDEO_TYPE_EFI), the former should take precedence
<arnd>
javierm: as tzimmermann said above, there are devices that still try to register both, e.g. the raspi with u-boot/uefi
<javierm>
in that case, the of platform code will call sysfb_disable(), register the "simple-framebuffer" and sysfb_init() be a no-op
<arnd>
yes, I see in the code that this is what is supposed to happen, yet tzimmermann said it fails to do that
<javierm>
arnd: oh, I see. Yes that happened and was reported as a bug; and was the reason we added that sysfb_disable()
<javierm>
similarly, coreboot with a seabios payload had the same issue and in that case coreboot avoids creating a "simple-framebuffer" device and lets sysfb to do it
<javierm>
because were told that seabios had precedence over coreboot
<javierm>
that's why I said that's really a mess and I don't know how to make it more consistent
<tzimmermann>
arnd, i think you misunderstood. the current code works correctly
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
asrivats__ has joined #dri-devel
<arnd>
tzimmermann: I think I got it now. How about flipping the dependencies for SYSFB_SIMPLEFB to reflect the new recommendation then? https://www.irccloud.com/pastebin/8logjfIs/
enzuru has joined #dri-devel
<arnd>
I've tried to update the help text a bit, but it's still confusing because it was all originally written with the intention of obsoleting efifb/vesafb in favor of simplefb, but now we recommend efidrm/vesadrm instead of simpledrm
asrivats__ has quit [Ping timeout: 480 seconds]
alarumbe has joined #dri-devel
<tzimmermann>
arnd, the change to SYSFB_SIMPLEFB might break something. ok for DRM_EFIDRM and DRM_VESADRM. FB_EFI shout depend on (!EFIDRM || COMPILE_TEST); likewise for FB_VESA. the new text in the first paragraph sounds off
<arnd>
tzimmermann: how would the SYSFB_SIMPLEFB change break anything? The dependency on '!(DRM_EFIDRM || DRM_VESADRM)' is just equivalent to the removed dependency, while the added dependency on 'FB_SIMPLE || DRM_SIMPLEDRM' only guards against a case that was already broken
<tzimmermann>
arnd, there could display modes that are suported by vesa, but not by simplefb. the code should likely fallback to vesadrm in that case.
<tzimmermann>
and FB_VESA and FB_EFI are still a thing on some systems, so you'd have to check for those as well.
<tzimmermann>
i'd just leave this out
Sid127 has quit [Read error: Connection reset by peer]
Sid127 has joined #dri-devel
caitcatd- has joined #dri-devel
caitcatdev has quit [Ping timeout: 480 seconds]
asrivats__ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
phasta has quit [Quit: WeeChat 4.6.2]
<arnd>
tzimmermann: I'm still not following what you mean here. If there is a mode that is supported by vesadrm but not simpledrm, that is currently broken when SYSFB_SIMPLEFB is enabled, because DRM_VESADRM depends on !SYSFB_SIMPLEFB. With my patch, turning on DRM_VESADRM forces SYSFB_SIMPLEFB to be disabled. Regardless of my patch, the vesa framebuffer works with DRM_VESADRM=y and SYSFB_SIMPLEFB=n.
<tzimmermann>
arnd, could be. vesadrm is still new. not all edge cases have been tested. i meant, i just would not overthink the dependencies of SYSFB_SIMPLEFB
asrivats__ has quit [Ping timeout: 480 seconds]
<arnd>
the fallback is something that vesafb/efifb users may depend on, so existing configs with DRM_SIMPLEDRM=y, FB_VESA=y, FB_EFI=y, SYSFB_SIMPLEFB=y should ideally remain possible
davispuh has joined #dri-devel
<arnd>
I think it would be good if anyone starting to use vesadrm/efidrm now is forced to build with SYSFB_SIMPLEFB=n, so that by the time we remove vesafb/efifb, SYSFB_SIMPLEFB can also be removed
<arnd>
i.e. not offer too many new combinations that we want to eventually remove again
asrivats__ has joined #dri-devel
<javierm>
the idea then is to not allow simpledrm to be used with EFI and VESA/VGA anymore ?
feaneron has joined #dri-devel
<tzimmermann>
arnd, well, ok then
<arnd>
javierm: yes, based on what tzimmermann suggested earlier "TBH i think we should advice against SYSFB_SIMPLEFB=y. with efidrm/vesadrm there will be better alternatives"
asrivats__ has quit [Ping timeout: 480 seconds]
<arnd>
the old vesafb/efifb drivers are not very nice drivers, so the idea of sysfb_simplefb to use the more modern simplefb made sense at the time. Similarly, using simpledrm instead of simplefb is another step forward. With efidrm/vesadrm, I think the old issues of efifb/vesafb no longer apply, so sysfb_simplefb has served its purpose and can eventually get retired
<tzimmermann>
arnd, the simple* drivers are a bit overloaded. they handle DT's simple-framebuffer and the kernel-internal simplefb_platform_data. it would be nice to have two separate drivers at some point.
<javierm>
arnd: that's true. But then as tzimmermann said, we should make simpledrm only about "simple-framebuffer" devices and drop sysfb at all
<javierm>
either we want to have the convenience of a driver that could use any generic system framebuffer provided by firmware or have dedicated drivers for each firmware interface
<tzimmermann>
simplefb_platform_data is currently required by the coreboot framebuffer and the N64 framebuffer. they could likely be migrated to some sort of plain-framebuffer device (instead of being lumped together with simple-framebuffer)
<tzimmermann>
no hurries though
<javierm>
tzimmermann: simplesysfbdrm :D
<tzimmermann>
:D
<javierm>
tzimmermann: but yeah, I remember when you introduced ofdrm that I mentioned about removing the of-specific bits from simpledrm
<tzimmermann>
i'm pretty sure the n64 requires an fbdev driver
<javierm>
and you explained to me that ppc of and DT of were different
<tzimmermann>
coreboot could certainly go with drm
kzd has joined #dri-devel
<javierm>
tzimmermann: it feels wrong that simpledrm needs to know about DT properties parsing
<javierm>
so having a dedicated driver for DT "simple-framebuffer" sounds better indeed
<tzimmermann>
but isn't that what all drivers do?
<tzimmermann>
parse the DT?
<javierm>
tzimmermann: yeah, but simpledrm was supposed to be a driver that use generic system provided framebuffers
<javierm>
you mentioned that we could split in two drivers, and in that case the driver that would just use simplefb_platform_data will be platform agnostic
<tzimmermann>
provided by the DT
<arnd>
I think it makes sense to have the "simpledrm" driver be the one that parses DT properties for a device that is compatible with the "simple-framebuffer" binding, but that doesn't have to be the same driver that uses simplefb_platform_data
<javierm>
tzimmermann: I tried to say what arnd just mentioned
<tzimmermann>
simplefb_platform_data would become someinthg like pixelbuf_data
<javierm>
tzimmermann: you would have the platform OF code to register a "simple-framebuffer" and match with a simpledrm driver that parses DT properties
<javierm>
tzimmermann: and then sysfb will register a device (that won't be named "simple-framebuffer" anymore, but "generic-framebuffer" or something)
<javierm>
that will match with a sysfbdrm that won't know anything about FW interfaces
<javierm>
just use whatever is provided from screen_info
<tzimmermann>
sort of
<arnd>
drivers/firmware/google/framebuffer-coreboot.c converts the google specific data into simplefb_platform_data, but that file could easily be moved into drivers/gpu/drm/sysfb next to simpledrm/efidrm/vesadrm/ofdrm
<tzimmermann>
i think we should try to kill SYSFB_SIMPLEFB first
<tzimmermann>
then we'd not need the generic-framebuffer in sysfb
<tzimmermann>
it would be a thing of n64 and coreboot
kts has joined #dri-devel
<arnd>
mips/n64 can create device_property entries for its platform device to use the same probe function as the dtb case
<tzimmermann>
there's been talk about keeping the framebuffer across kexec/kdump. it could be build using the generic-framebuffer
<javierm>
arnd: interesting idea
<arnd>
tzimmermann: do you have an estimate about when we might consider removing the old efifb/vesafb? do you think it's worth removing sysfb_simplefb any earlier than that, or just remove them all at the same time?
<arnd>
also the old simplefb, I guess
<javierm>
arnd: I would first remove the {efi,vesa}fb in a few kernel releases, to give people time to migrate to {efi,vesa}drm
<javierm>
simplefb could really be removed IMO. I don't see a reason to keep it around anymore
<tzimmermann>
arnd, no earlier than 2 yrs from now
<tzimmermann>
still needs work and needs to make it to the distros for testing.
<tzimmermann>
and it's not really high prio
<javierm>
tzimmermann: I always wondered what is the policy of fbdev drivers removal
<javierm>
in practice I would guess that most distros already migrated from simple/efi/vesa fbdev drivers to simpledrm for some time
<tzimmermann>
javierm, there's always someone who appears to be using the old code. so it rarely happens
<tzimmermann>
i tried to remove udlfb. someone complained, yet we have a much better udl driver in drm
<javierm>
tzimmermann: yeah, that's the reason why I didn't attempt to remove the old ssd1307fb driver
<javierm>
even when the ssd130x drm driver now supports different families, I2C and SPI
<tzimmermann>
and most of the really old HW is hard to support in drm. the fbdev drivers have less overhead. that makes a difference on the old platforms
<arnd>
I see that the armv7 defconfig (arch/arm/configs/multi_v7_defconfig) still contains simplefb and efifb, but not simpledrm, we should probably fix that
<tzimmermann>
arnd, great
<javierm>
tzimmermann: right. That's why I never proposed removed an fbdev driver, but still said that "I would remove it" :)
<tzimmermann>
javierm, maybe we could move some drivers to staging?
<tzimmermann>
or make them depend on !DRM
<javierm>
tzimmermann: moving to staging makes sense. It seems that's the deprecation path that others drivers followed