On Thu, Jun 12, 2014 at 1:44 AM, Ajay kumar ajaynumb@gmail.com wrote:
Kevin,
On Thu, Jun 12, 2014 at 2:48 AM, Kevin Hilman khilman@linaro.org wrote:
Rahul Sharma rahul.sharma@samsung.com writes:
On 11 June 2014 03:48, Kevin Hilman khilman@linaro.org wrote:
Hi Ajay,
On Tue, Jun 10, 2014 at 1:51 PM, Ajay kumar ajaynumb@gmail.com wrote:
Hi,
On 6/11/14, Kevin Hilman khilman@linaro.org wrote:
On Tue, Jun 10, 2014 at 11:04 AM, Stéphane Marchesin marcheu@chromium.org wrote: > On Tue, Jun 10, 2014 at 10:56 AM, Kevin Hilman khilman@linaro.org > wrote: >> I'm trying to get the latest linux-next working on my Chromebook2 >> (it's booting to a serial console) and am now trying to get the >> display working (at least for a frambuffer console.) >> >> Since the display nodes seem to be present in the exynos5800-peach-pi >> DTS, I tried enabling DRM and it's failing to allocate memory (log >> below[1] >> >> Is there some additional memory setup/allocations I should be doing? >> maybe with CMA? > > Probably not CMA, but maybe you don't have the iommu enabled?
Turns out it was missing CMA support. Specifically: CONFIG_CMA=y CONFIG_DMA_CMA=y are needed (my full .config is here: http://hastebin.com/uqopirazir.vbs)
With that, it allocates, appears to detect the panel and even claims "Console: switching to colour frame buffer device", but I don't see tux or any output on the display (DRM debug output below).
Note that I'm chain-loading nv_uboot from an SD card, and u-boot is driving the display (black text on white background.) As soon as it starts the kernel though, u-boot seems to shut down the display (though the backlight seems to still be on.)
Maybe the DT for peach-pi is missing the regulator used to power the panel, or maybe a GPIO used to power up the panel?
Any ideas?
Not only the DT patches, but few patches are missing to support the panel present on peach-pi. You should also take the following patches to be able to get the display up on peach-pi: http://www.spinics.net/lists/linux-samsung-soc/msg32122.html
Excellent, thanks for the pointer to those patches. I'll have a look.
Can you confirm that this should work even when chain-loading nv_uboot? It appears u-boot is powering down the panel.
If u-boot is powering down the panel, you also need EC and Tps DT patches to get regulators up in kernel. Those are not posted yet. I will send these patches to you.
I tested the patches you sent on top of next-2014060 but I'm still not seeing tux on the framebuffer. I do see the backlight turn off and back on twice during the boot, but nothing else interesting on the display.
Your configs seem to be fine, but when I analyzed the logs, I could make out that lcd_vdd being on from u-boot is the problem: [ 2.641456] lcd_vdd: no parameters [ 2.641522] lcd_vdd: supplied by vbat-supply
The eDP panel on peach-pi throws HPD approximately 100-150ms after powering up lcd_vdd. Since u-boot turns the display on, HPD was thrown at u-boot itself. When kernel boots up, it is not disabling and enabling lcd_vdd, but it is left in same voltage state. That means panel was not actually "reset", and hence HPD is not thrown again in kernel.
I have already fixed this problem and sent patches yesterday. Revert V3 series of bridge chip patches, and take the latest version here: http://www.spinics.net/lists/linux-samsung-soc/msg32393.html
Regarding the new configs, you should enable CONFIG_DRM_PANEL_BINDER and CONFIG_DRM_PANEL_EDP_LVDS.
Excellent, it works! I have 8 beautiful penguins on my display, and then a login prompt.
Thanks for the help. I anxiously await this stuff geting into the samsung tree for broader testing.
Kevin