From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Javier Martinez Canillas <javier@osg.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 16:16:01 +0900 [thread overview]
Message-ID: <55F27FB1.50100@samsung.com> (raw)
In-Reply-To: <55F27D9F.1000702@osg.samsung.com>
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
next prev parent reply other threads:[~2015-09-11 7:16 UTC|newest]
Thread overview: 6+ 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-11 5:01 ` Krzysztof Kozlowski
2015-09-11 7:07 ` Javier Martinez Canillas
2015-09-11 7:16 ` Krzysztof Kozlowski [this message]
2015-09-11 7:40 ` Javier Martinez Canillas
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=55F27FB1.50100@samsung.com \
--to=k.kozlowski@samsung.com \
--cc=javier@osg.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox