Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1222203 > unrolled thread

[PATCH] ARM: exynos_defconfig: Disable simplefb support

Back to article view | Back to linux.kernel

Contents

  [PATCH] ARM: exynos_defconfig: Disable simplefb support Javier Martinez Canillas <javier@osg.samsung.com> - 2015-09-10 15:50 +0200
    Re: [PATCH] ARM: exynos_defconfig: Disable simplefb support Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-09-11 07:10 +0200
      Re: [PATCH] ARM: exynos_defconfig: Disable simplefb support Javier Martinez Canillas <javier@osg.samsung.com> - 2015-09-11 09:10 +0200
        Re: [PATCH] ARM: exynos_defconfig: Disable simplefb support Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-09-11 09:20 +0200
          Re: [PATCH] ARM: exynos_defconfig: Disable simplefb support Javier Martinez Canillas <javier@osg.samsung.com> - 2015-09-11 09:50 +0200
    Re: [PATCH] ARM: exynos_defconfig: Disable simplefb support Michael Turquette <mturquette@baylibre.com> - 2015-09-11 17:30 +0200

#1222203 — [PATCH] ARM: exynos_defconfig: Disable simplefb support

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(-)

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1222528

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222566

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,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222570

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222593

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,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222912

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web