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.
Kevin