On Thu, Jun 12, 2014 at 1:44 AM, Ajay kumar <ajaynumb@xxxxxxxxx> wrote: > Kevin, > > > On Thu, Jun 12, 2014 at 2:48 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >> Rahul Sharma <rahul.sharma@xxxxxxxxxxx> writes: >> >>> On 11 June 2014 03:48, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >>>> Hi Ajay, >>>> >>>> On Tue, Jun 10, 2014 at 1:51 PM, Ajay kumar <ajaynumb@xxxxxxxxx> wrote: >>>>> Hi, >>>>> >>>>> On 6/11/14, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >>>>>> On Tue, Jun 10, 2014 at 11:04 AM, Stéphane Marchesin >>>>>> <marcheu@xxxxxxxxxxxx> wrote: >>>>>>> On Tue, Jun 10, 2014 at 10:56 AM, Kevin Hilman <khilman@xxxxxxxxxx> >>>>>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |