| Message ID | 1441892552-13819-1-git-send-email-javier@osg.samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 10.09.2015 22:42, Javier Martinez Canillas wrote: > The simplefb driver allows the kernel to render on a pre-allocated > buffer that's been initialized by firmware before the kernel boots. > > This option was enabled to have display working on the Exynos5250 > Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig > update") since proper DRM/KMS support did not exist at that time. > > But now that the Exynos DRM driver has support for this hardware, > there is no need to have simplefb enabled. In fact, if a user has > a u-boot that injects the simplefb dev node to the FDT before pass > it to the kernel, display won't be properly initialized and only a > blank screen will be shown since there isn't a proper handoff from > the simplefb driver to the Exynos DRM driver. > > Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> > > --- > > arch/arm/configs/exynos_defconfig | 1 - > 1 file changed, 1 deletion(-) Seems logical. None of the boards use simple-framebuffer compatible anyway. I understand that on Snow simplefb was needed along with change in Uboot like this one: https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/changes/58/49358/2 and now none of Exynos boards use simplefb anymore? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Krzysztof, On 09/11/2015 07:01 AM, Krzysztof Kozlowski wrote: > On 10.09.2015 22:42, Javier Martinez Canillas wrote: >> The simplefb driver allows the kernel to render on a pre-allocated >> buffer that's been initialized by firmware before the kernel boots. >> >> This option was enabled to have display working on the Exynos5250 >> Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig >> update") since proper DRM/KMS support did not exist at that time. >> >> But now that the Exynos DRM driver has support for this hardware, >> there is no need to have simplefb enabled. In fact, if a user has >> a u-boot that injects the simplefb dev node to the FDT before pass >> it to the kernel, display won't be properly initialized and only a >> blank screen will be shown since there isn't a proper handoff from >> the simplefb driver to the Exynos DRM driver. >> >> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> >> >> --- >> >> arch/arm/configs/exynos_defconfig | 1 - >> 1 file changed, 1 deletion(-) > > Seems logical. None of the boards use simple-framebuffer compatible > anyway. I understand that on Snow simplefb was needed along with change > in Uboot like this one: > https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/changes/58/49358/2 > Exactly but you won't see the dev node with the "simple-framebuffer" compatible string in the DTS since is the bootloader that adds this device node to the FDT before passing it to the kernel. The bootloader shouldn't mangle the FDT (with the exception of the memory and choosen/bootargs nodes) but simplefb is just a hack to re-use the display HW initialization made by the bootloader. > and now none of Exynos boards use simplefb anymore? > Yes, there are no other Exynos boards using simplefb besides Snow that I'm aware of but since Exynos DRM is working well on this board from v4.0, there is no need for it anymore. In fact, as explained in the commit message, it could do more harm than good since users that are still booting with a u-boot that adds the simplefb device node, only get a blank screen since the simplefb driver is probed, creates a console and later the Exynos DRM probes and re-initializes the HW creating its own console, causing this issue. I got several reports of users that says that mainline stop booting for them but is just that they didn't get display working. Disabling simplefb makes display to work again so maybe this is even -rc material and should go to stable # v4.0+ > Best regards, > Krzysztof > > Best regards,
On 11.09.2015 16:07, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 09/11/2015 07:01 AM, Krzysztof Kozlowski wrote: >> On 10.09.2015 22:42, Javier Martinez Canillas wrote: >>> The simplefb driver allows the kernel to render on a pre-allocated >>> buffer that's been initialized by firmware before the kernel boots. >>> >>> This option was enabled to have display working on the Exynos5250 >>> Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig >>> update") since proper DRM/KMS support did not exist at that time. >>> >>> But now that the Exynos DRM driver has support for this hardware, >>> there is no need to have simplefb enabled. In fact, if a user has >>> a u-boot that injects the simplefb dev node to the FDT before pass >>> it to the kernel, display won't be properly initialized and only a >>> blank screen will be shown since there isn't a proper handoff from >>> the simplefb driver to the Exynos DRM driver. >>> >>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> >>> >>> --- >>> >>> arch/arm/configs/exynos_defconfig | 1 - >>> 1 file changed, 1 deletion(-) >> >> Seems logical. None of the boards use simple-framebuffer compatible >> anyway. I understand that on Snow simplefb was needed along with change >> in Uboot like this one: >> https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/changes/58/49358/2 >> > > Exactly but you won't see the dev node with the "simple-framebuffer" > compatible string in the DTS since is the bootloader that adds this > device node to the FDT before passing it to the kernel. > > The bootloader shouldn't mangle the FDT (with the exception of the > memory and choosen/bootargs nodes) but simplefb is just a hack to > re-use the display HW initialization made by the bootloader. > >> and now none of Exynos boards use simplefb anymore? >> > > Yes, there are no other Exynos boards using simplefb besides Snow > that I'm aware of but since Exynos DRM is working well on this board > from v4.0, there is no need for it anymore. OK, Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> > > In fact, as explained in the commit message, it could do more harm > than good since users that are still booting with a u-boot that adds > the simplefb device node, only get a blank screen since the simplefb > driver is probed, creates a console and later the Exynos DRM probes > and re-initializes the HW creating its own console, causing this issue. > > I got several reports of users that says that mainline stop booting for > them but is just that they didn't get display working. Disabling simplefb > makes display to work again so maybe this is even -rc material and should > go to stable # v4.0+ You know, it is only a defconfig. The issue is there regardless of change in defconfig. I am not convinced that defconfig problems are worth backporting. multi_v7 has it enabled anyway. Maybe the EXYNOS_DRM should have some anti-dependency on SIMPLE_FB? But on the other hand the issue is actually caused by hacks in bootloader... Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Krzysztof, On 09/11/2015 09:16 AM, Krzysztof Kozlowski wrote: > On 11.09.2015 16:07, Javier Martinez Canillas wrote: >> Hello Krzysztof, >> >> On 09/11/2015 07:01 AM, Krzysztof Kozlowski wrote: >>> On 10.09.2015 22:42, Javier Martinez Canillas wrote: >>>> The simplefb driver allows the kernel to render on a pre-allocated >>>> buffer that's been initialized by firmware before the kernel boots. >>>> >>>> This option was enabled to have display working on the Exynos5250 >>>> Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig >>>> update") since proper DRM/KMS support did not exist at that time. >>>> >>>> But now that the Exynos DRM driver has support for this hardware, >>>> there is no need to have simplefb enabled. In fact, if a user has >>>> a u-boot that injects the simplefb dev node to the FDT before pass >>>> it to the kernel, display won't be properly initialized and only a >>>> blank screen will be shown since there isn't a proper handoff from >>>> the simplefb driver to the Exynos DRM driver. >>>> >>>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> >>>> >>>> --- >>>> >>>> arch/arm/configs/exynos_defconfig | 1 - >>>> 1 file changed, 1 deletion(-) >>> >>> Seems logical. None of the boards use simple-framebuffer compatible >>> anyway. I understand that on Snow simplefb was needed along with change >>> in Uboot like this one: >>> https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/changes/58/49358/2 >>> >> >> Exactly but you won't see the dev node with the "simple-framebuffer" >> compatible string in the DTS since is the bootloader that adds this >> device node to the FDT before passing it to the kernel. >> >> The bootloader shouldn't mangle the FDT (with the exception of the >> memory and choosen/bootargs nodes) but simplefb is just a hack to >> re-use the display HW initialization made by the bootloader. >> >>> and now none of Exynos boards use simplefb anymore? >>> >> >> Yes, there are no other Exynos boards using simplefb besides Snow >> that I'm aware of but since Exynos DRM is working well on this board >> from v4.0, there is no need for it anymore. > > OK, > Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> > Thanks! >> >> In fact, as explained in the commit message, it could do more harm >> than good since users that are still booting with a u-boot that adds >> the simplefb device node, only get a blank screen since the simplefb >> driver is probed, creates a console and later the Exynos DRM probes >> and re-initializes the HW creating its own console, causing this issue. >> >> I got several reports of users that says that mainline stop booting for >> them but is just that they didn't get display working. Disabling simplefb >> makes display to work again so maybe this is even -rc material and should >> go to stable # v4.0+ > > You know, it is only a defconfig. The issue is there regardless of > change in defconfig. I am not convinced that defconfig problems are > worth backporting. multi_v7 has it enabled anyway. > Yes, that's why I said "maybe" :) > Maybe the EXYNOS_DRM should have some anti-dependency on SIMPLE_FB? But hrmm I don't know, I think this issue happens with any DRM driver. Hopefully there should be soon a nice hand off from simplefb to DRM drivers like early console does to the real console drivers for UARTs. > on the other hand the issue is actually caused by hacks in bootloader... > Yeah and in fact this does not happen with the stock bootloader that comes shipped on these devices, is with a special build that has this hack enabled. > > Best regards, > Krzysztof > > Thanks a lot for your feedback. Best regards,
Quoting Javier Martinez Canillas (2015-09-10 06:42:32) > The simplefb driver allows the kernel to render on a pre-allocated > buffer that's been initialized by firmware before the kernel boots. > > This option was enabled to have display working on the Exynos5250 > Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig > update") since proper DRM/KMS support did not exist at that time. > > But now that the Exynos DRM driver has support for this hardware, > there is no need to have simplefb enabled. In fact, if a user has > a u-boot that injects the simplefb dev node to the FDT before pass > it to the kernel, display won't be properly initialized and only a > blank screen will be shown since there isn't a proper handoff from > the simplefb driver to the Exynos DRM driver. > > Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by/Tested-by: Michael Turquette <mturquette@baylibre.com> Thanks, this resolved one of the issues I had with U-boot that injected the simplefb node. Regards, Mike > > --- > > arch/arm/configs/exynos_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig > index 62f677f76a0b..20d878c83193 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -139,7 +139,6 @@ CONFIG_DRM_EXYNOS_DSI=y > CONFIG_DRM_EXYNOS_HDMI=y > CONFIG_DRM_PANEL_SIMPLE=y > CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y > -CONFIG_FB_SIMPLE=y > CONFIG_EXYNOS_VIDEO=y > CONFIG_EXYNOS_MIPI_DSI=y > CONFIG_LCD_CLASS_DEVICE=y > -- > 2.4.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 62f677f76a0b..20d878c83193 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -139,7 +139,6 @@ CONFIG_DRM_EXYNOS_DSI=y CONFIG_DRM_EXYNOS_HDMI=y CONFIG_DRM_PANEL_SIMPLE=y CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y -CONFIG_FB_SIMPLE=y CONFIG_EXYNOS_VIDEO=y CONFIG_EXYNOS_MIPI_DSI=y CONFIG_LCD_CLASS_DEVICE=y
The simplefb driver allows the kernel to render on a pre-allocated buffer that's been initialized by firmware before the kernel boots. This option was enabled to have display working on the Exynos5250 Snow Chromebook by commit da9d0fbf5e9a ("ARM: exynos: defconfig update") since proper DRM/KMS support did not exist at that time. But now that the Exynos DRM driver has support for this hardware, there is no need to have simplefb enabled. In fact, if a user has a u-boot that injects the simplefb dev node to the FDT before pass it to the kernel, display won't be properly initialized and only a blank screen will be shown since there isn't a proper handoff from the simplefb driver to the Exynos DRM driver. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> --- arch/arm/configs/exynos_defconfig | 1 - 1 file changed, 1 deletion(-)