All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier@osg.samsung.com>
To: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	linux-kernel@vger.kernel.org
Cc: Michael Turquette <mturquette@baylibre.com>,
	Kukjin Kim <kgene@kernel.org>,
	Thierry Reding <treding@nvidia.com>,
	Anand Moon <linux.amoon@gmail.com>,
	Russell King <linux@arm.linux.org.uk>,
	linux-samsung-soc@vger.kernel.org,
	Lukasz Majewski <l.majewski@samsung.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: exynos_defconfig: Disable simplefb support
Date: Fri, 11 Sep 2015 09:40:43 +0200	[thread overview]
Message-ID: <55F2857B.4020800@osg.samsung.com> (raw)
In-Reply-To: <55F27FB1.50100@samsung.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: javier@osg.samsung.com (Javier Martinez Canillas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: exynos_defconfig: Disable simplefb support
Date: Fri, 11 Sep 2015 09:40:43 +0200	[thread overview]
Message-ID: <55F2857B.4020800@osg.samsung.com> (raw)
In-Reply-To: <55F27FB1.50100@samsung.com>

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

  reply	other threads:[~2015-09-11  7:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-10 13:42 [PATCH] ARM: exynos_defconfig: Disable simplefb support Javier Martinez Canillas
2015-09-10 13:42 ` Javier Martinez Canillas
2015-09-11  5:01 ` Krzysztof Kozlowski
2015-09-11  5:01   ` Krzysztof Kozlowski
2015-09-11  7:07   ` Javier Martinez Canillas
2015-09-11  7:07     ` Javier Martinez Canillas
2015-09-11  7:16     ` Krzysztof Kozlowski
2015-09-11  7:16       ` Krzysztof Kozlowski
2015-09-11  7:40       ` Javier Martinez Canillas [this message]
2015-09-11  7:40         ` Javier Martinez Canillas
2015-09-11 15:25 ` Michael Turquette
2015-09-11 15:25   ` Michael Turquette
2015-09-11 15:25   ` Michael Turquette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55F2857B.4020800@osg.samsung.com \
    --to=javier@osg.samsung.com \
    --cc=k.kozlowski@samsung.com \
    --cc=kgene@kernel.org \
    --cc=l.majewski@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux.amoon@gmail.com \
    --cc=linux@arm.linux.org.uk \
    --cc=mturquette@baylibre.com \
    --cc=treding@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.