linux-next on Chromebook2: DRM failing to allocate

linux-next on Chromebook2: DRM failing to allocate

[Kevin Hilman]

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?

Thanks for any advice,

Kevin


[1] DRM output with drm.debug=0xf on command line

[    1.095622] [drm] Initialized drm 1.1.0 20060810
[    1.099792] [drm:drm_platform_init]
[    1.102311] [drm:drm_get_platform_dev]
[    1.106211] [drm:drm_minor_register]
[    1.110000] [drm:drm_minor_register] new minor assigned 64
[    1.115265] [drm:drm_minor_register]
[    1.118900] [drm:drm_minor_register]
[    1.122693] [drm:drm_minor_register] new minor assigned 0
[    1.127970] [drm:exynos_drm_encoder_create] possible_crtcs = 0x1
[    1.133915] [drm:exynos_drm_encoder_create] encoder has been created
[    1.140407] [drm:drm_sysfs_connector_add] adding "eDP-1" to sysfs
[    1.146335] [drm:drm_sysfs_hotplug_event] generating hotplug event
[    1.152488] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    1.159065] [drm] No driver support for vblank timestamp query.
[    1.164965] [drm:drm_helper_hpd_irq_event] [CONNECTOR:15:eDP-1]
status updated from unknown to connected
[    1.174418] [drm:drm_sysfs_hotplug_event] generating hotplug event
[    1.180590] [drm:exynos_drm_encoder_dpms] encoder dpms: 3
[    1.185959] [drm:exynos_drm_crtc_dpms] crtc[6] mode[3]
[    1.191074] [drm:exynos_drm_crtc_dpms] desired dpms mode is same as
previous one.
[    1.198538] [drm:drm_helper_probe_single_connector_modes_merge_bits]
[CONNECTOR:15:eDP-1]
[    1.206698] [drm:drm_helper_probe_single_connector_modes_merge_bits]
[CONNECTOR:15:eDP-1] probed modes :
[    1.216149] [drm:drm_mode_debug_printmodeline] Modeline
16:"1920x1080" 60 150660 1920 1980 2060 2232 1080 1090 1100 1125 0x48
0x0
[    1.227779] [drm:drm_setup_crtcs]
[    1.231135] [drm:drm_enable_connectors] connector 15 enabled? yes
[    1.237227] [drm:drm_target_preferred] looking for cmdline mode on
connector 15
[    1.244512] [drm:drm_target_preferred] looking for preferred mode
on connector 15
[    1.251972] [drm:drm_target_preferred] found mode 1920x1080
[    1.257525] [drm:drm_setup_crtcs] picking CRTCs for 4096x4096 config
[    1.263859] [drm:drm_setup_crtcs] desired mode 1920x1080 set on crtc 6
[    1.270367] [drm:exynos_drm_fbdev_create] surface width(1920),
height(1080) and bpp(32
[    1.278260] [drm:exynos_drm_init_buf] desired size = 0x7e9000
[    1.283995] [drm:exynos_drm_gem_init] created file object = 0xed7f9200
[    1.290502] ------------[ cut here ]------------
[    1.295094] WARNING: CPU: 1 PID: 1 at ../mm/page_alloc.c:2509
__alloc_pages_nodemask+0x220/0x76c()
[    1.304022] Modules linked in:
[    1.307044] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
3.15.0-rc8-next-20140605-00004-gde16f7d3b2b5-dirty #31
[    1.316882] [<800152ac>] (unwind_backtrace) from [<80011d94>]
(show_stack+0x20/0x24)
[    1.324595] [<80011d94>] (show_stack) from [<805128d8>]
(dump_stack+0x74/0x90)
[    1.331790] [<805128d8>] (dump_stack) from [<80024208>]
(warn_slowpath_common+0x78/0x9c)
[    1.339854] [<80024208>] (warn_slowpath_common) from [<80024258>]
(warn_slowpath_null+0x2c/0x34)
[    1.348622] [<80024258>] (warn_slowpath_null) from [<800c9334>]
(__alloc_pages_nodemask+0x220/0x76c)
[    1.357730] [<800c9334>] (__alloc_pages_nodemask) from [<80019fb8>]
(__dma_alloc_buffer.isra.13+0x3c/0x184)
[    1.367443] [<80019fb8>] (__dma_alloc_buffer.isra.13) from
[<8001a124>] (__alloc_remap_buffer.isra.15+0x24/0xc0)
[    1.377592] [<8001a124>] (__alloc_remap_buffer.isra.15) from
[<8001a410>] (__dma_alloc+0x250/0x2e0)
[    1.386613] [<8001a410>] (__dma_alloc) from [<8001a5d8>]
(arm_dma_alloc+0x94/0xa0)
[    1.394166] [<8001a5d8>] (arm_dma_alloc) from [<802cf650>]
(exynos_drm_alloc_buf+0x118/0x294)
[    1.402663] [<802cf650>] (exynos_drm_alloc_buf) from [<802cfd10>]
(exynos_drm_gem_create+0x84/0xec)
[    1.411684] [<802cfd10>] (exynos_drm_gem_create) from [<802cea14>]
(exynos_drm_fbdev_create+0xdc/0x2ec)
[    1.421056] [<802cea14>] (exynos_drm_fbdev_create) from
[<802b306c>] (drm_fb_helper_initial_config+0x324/0x440)
[    1.431117] [<802b306c>] (drm_fb_helper_initial_config) from
[<802ced58>] (exynos_drm_fbdev_init+0xd0/0x10c)
[    1.440918] [<802ced58>] (exynos_drm_fbdev_init) from [<802cef10>]
(exynos_drm_output_poll_changed+0x34/0x38)
[    1.450808] [<802cef10>] (exynos_drm_output_poll_changed) from
[<802b0a08>] (drm_kms_helper_hotplug_event+0x34/0x38)
[    1.461305] [<802b0a08>] (drm_kms_helper_hotplug_event) from
[<802b1148>] (drm_helper_hpd_irq_event+0x108/0x120)
[    1.471455] [<802b1148>] (drm_helper_hpd_irq_event) from
[<802cd998>] (exynos_drm_load+0xf0/0x130)
[    1.480390] [<802cd998>] (exynos_drm_load) from [<802bb654>]
(drm_dev_register+0x90/0x110)
[    1.488631] [<802bb654>] (drm_dev_register) from [<802bcff0>]
(drm_platform_init+0x80/0xf0)
[    1.496958] [<802bcff0>] (drm_platform_init) from [<802cda3c>]
(exynos_drm_platform_probe+0x64/0x74)
[    1.506069] [<802cda3c>] (exynos_drm_platform_probe) from
[<802de5c8>] (platform_drv_probe+0x28/0x58)
[    1.515263] [<802de5c8>] (platform_drv_probe) from [<802dcf20>]
(driver_probe_device+0xc4/0x214)
[    1.524024] [<802dcf20>] (driver_probe_device) from [<802dd144>]
(__device_attach+0x38/0x54)
[    1.532444] [<802dd144>] (__device_attach) from [<802db430>]
(bus_for_each_drv+0x5c/0xa4)
[    1.540594] [<802db430>] (bus_for_each_drv) from [<802dce04>]
(device_attach+0x74/0x98)
[    1.548575] [<802dce04>] (device_attach) from [<802dc430>]
(bus_probe_device+0x38/0xa8)
[    1.556556] [<802dc430>] (bus_probe_device) from [<802da628>]
(device_add+0x374/0x518)
[    1.564450] [<802da628>] (device_add) from [<802de7fc>]
(platform_device_add+0x140/0x1d0)
[    1.572604] [<802de7fc>] (platform_device_add) from [<802dee54>]
(platform_device_register_full+0xa8/0xe0)
[    1.582236] [<802dee54>] (platform_device_register_full) from
[<80754a04>] (exynos_drm_init+0x74/0xc8)
[    1.591517] [<80754a04>] (exynos_drm_init) from [<80008a48>]
(do_one_initcall+0x108/0x1d0)
[    1.599758] [<80008a48>] (do_one_initcall) from [<8072dd64>]
(kernel_init_freeable+0x108/0x1d4)
[    1.608433] [<8072dd64>] (kernel_init_freeable) from [<8050e66c>]
(kernel_init+0x1c/0xf4)
[    1.616588] [<8050e66c>] (kernel_init) from [<8000e698>]
(ret_from_fork+0x14/0x20)
[    1.624143] ---[ end trace 7efd36d9338b10a9 ]---
[    1.628729] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
[    1.635855] [drm] Initialized exynos 1.0.0 20110530 on minor 0

Re: linux-next on Chromebook2: DRM failing to allocate

[Stéphane Marchesin]

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?

Stéphane

>
> Thanks for any advice,
>
> Kevin
>
>
> [1] DRM output with drm.debug=0xf on command line
>
> [    1.095622] [drm] Initialized drm 1.1.0 20060810
> [    1.099792] [drm:drm_platform_init]
> [    1.102311] [drm:drm_get_platform_dev]
> [    1.106211] [drm:drm_minor_register]
> [    1.110000] [drm:drm_minor_register] new minor assigned 64
> [    1.115265] [drm:drm_minor_register]
> [    1.118900] [drm:drm_minor_register]
> [    1.122693] [drm:drm_minor_register] new minor assigned 0
> [    1.127970] [drm:exynos_drm_encoder_create] possible_crtcs = 0x1
> [    1.133915] [drm:exynos_drm_encoder_create] encoder has been created
> [    1.140407] [drm:drm_sysfs_connector_add] adding "eDP-1" to sysfs
> [    1.146335] [drm:drm_sysfs_hotplug_event] generating hotplug event
> [    1.152488] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [    1.159065] [drm] No driver support for vblank timestamp query.
> [    1.164965] [drm:drm_helper_hpd_irq_event] [CONNECTOR:15:eDP-1]
> status updated from unknown to connected
> [    1.174418] [drm:drm_sysfs_hotplug_event] generating hotplug event
> [    1.180590] [drm:exynos_drm_encoder_dpms] encoder dpms: 3
> [    1.185959] [drm:exynos_drm_crtc_dpms] crtc[6] mode[3]
> [    1.191074] [drm:exynos_drm_crtc_dpms] desired dpms mode is same as
> previous one.
> [    1.198538] [drm:drm_helper_probe_single_connector_modes_merge_bits]
> [CONNECTOR:15:eDP-1]
> [    1.206698] [drm:drm_helper_probe_single_connector_modes_merge_bits]
> [CONNECTOR:15:eDP-1] probed modes :
> [    1.216149] [drm:drm_mode_debug_printmodeline] Modeline
> 16:"1920x1080" 60 150660 1920 1980 2060 2232 1080 1090 1100 1125 0x48
> 0x0
> [    1.227779] [drm:drm_setup_crtcs]
> [    1.231135] [drm:drm_enable_connectors] connector 15 enabled? yes
> [    1.237227] [drm:drm_target_preferred] looking for cmdline mode on
> connector 15
> [    1.244512] [drm:drm_target_preferred] looking for preferred mode
> on connector 15
> [    1.251972] [drm:drm_target_preferred] found mode 1920x1080
> [    1.257525] [drm:drm_setup_crtcs] picking CRTCs for 4096x4096 config
> [    1.263859] [drm:drm_setup_crtcs] desired mode 1920x1080 set on crtc 6
> [    1.270367] [drm:exynos_drm_fbdev_create] surface width(1920),
> height(1080) and bpp(32
> [    1.278260] [drm:exynos_drm_init_buf] desired size = 0x7e9000
> [    1.283995] [drm:exynos_drm_gem_init] created file object = 0xed7f9200
> [    1.290502] ------------[ cut here ]------------
> [    1.295094] WARNING: CPU: 1 PID: 1 at ../mm/page_alloc.c:2509
> __alloc_pages_nodemask+0x220/0x76c()
> [    1.304022] Modules linked in:
> [    1.307044] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> 3.15.0-rc8-next-20140605-00004-gde16f7d3b2b5-dirty #31
> [    1.316882] [<800152ac>] (unwind_backtrace) from [<80011d94>]
> (show_stack+0x20/0x24)
> [    1.324595] [<80011d94>] (show_stack) from [<805128d8>]
> (dump_stack+0x74/0x90)
> [    1.331790] [<805128d8>] (dump_stack) from [<80024208>]
> (warn_slowpath_common+0x78/0x9c)
> [    1.339854] [<80024208>] (warn_slowpath_common) from [<80024258>]
> (warn_slowpath_null+0x2c/0x34)
> [    1.348622] [<80024258>] (warn_slowpath_null) from [<800c9334>]
> (__alloc_pages_nodemask+0x220/0x76c)
> [    1.357730] [<800c9334>] (__alloc_pages_nodemask) from [<80019fb8>]
> (__dma_alloc_buffer.isra.13+0x3c/0x184)
> [    1.367443] [<80019fb8>] (__dma_alloc_buffer.isra.13) from
> [<8001a124>] (__alloc_remap_buffer.isra.15+0x24/0xc0)
> [    1.377592] [<8001a124>] (__alloc_remap_buffer.isra.15) from
> [<8001a410>] (__dma_alloc+0x250/0x2e0)
> [    1.386613] [<8001a410>] (__dma_alloc) from [<8001a5d8>]
> (arm_dma_alloc+0x94/0xa0)
> [    1.394166] [<8001a5d8>] (arm_dma_alloc) from [<802cf650>]
> (exynos_drm_alloc_buf+0x118/0x294)
> [    1.402663] [<802cf650>] (exynos_drm_alloc_buf) from [<802cfd10>]
> (exynos_drm_gem_create+0x84/0xec)
> [    1.411684] [<802cfd10>] (exynos_drm_gem_create) from [<802cea14>]
> (exynos_drm_fbdev_create+0xdc/0x2ec)
> [    1.421056] [<802cea14>] (exynos_drm_fbdev_create) from
> [<802b306c>] (drm_fb_helper_initial_config+0x324/0x440)
> [    1.431117] [<802b306c>] (drm_fb_helper_initial_config) from
> [<802ced58>] (exynos_drm_fbdev_init+0xd0/0x10c)
> [    1.440918] [<802ced58>] (exynos_drm_fbdev_init) from [<802cef10>]
> (exynos_drm_output_poll_changed+0x34/0x38)
> [    1.450808] [<802cef10>] (exynos_drm_output_poll_changed) from
> [<802b0a08>] (drm_kms_helper_hotplug_event+0x34/0x38)
> [    1.461305] [<802b0a08>] (drm_kms_helper_hotplug_event) from
> [<802b1148>] (drm_helper_hpd_irq_event+0x108/0x120)
> [    1.471455] [<802b1148>] (drm_helper_hpd_irq_event) from
> [<802cd998>] (exynos_drm_load+0xf0/0x130)
> [    1.480390] [<802cd998>] (exynos_drm_load) from [<802bb654>]
> (drm_dev_register+0x90/0x110)
> [    1.488631] [<802bb654>] (drm_dev_register) from [<802bcff0>]
> (drm_platform_init+0x80/0xf0)
> [    1.496958] [<802bcff0>] (drm_platform_init) from [<802cda3c>]
> (exynos_drm_platform_probe+0x64/0x74)
> [    1.506069] [<802cda3c>] (exynos_drm_platform_probe) from
> [<802de5c8>] (platform_drv_probe+0x28/0x58)
> [    1.515263] [<802de5c8>] (platform_drv_probe) from [<802dcf20>]
> (driver_probe_device+0xc4/0x214)
> [    1.524024] [<802dcf20>] (driver_probe_device) from [<802dd144>]
> (__device_attach+0x38/0x54)
> [    1.532444] [<802dd144>] (__device_attach) from [<802db430>]
> (bus_for_each_drv+0x5c/0xa4)
> [    1.540594] [<802db430>] (bus_for_each_drv) from [<802dce04>]
> (device_attach+0x74/0x98)
> [    1.548575] [<802dce04>] (device_attach) from [<802dc430>]
> (bus_probe_device+0x38/0xa8)
> [    1.556556] [<802dc430>] (bus_probe_device) from [<802da628>]
> (device_add+0x374/0x518)
> [    1.564450] [<802da628>] (device_add) from [<802de7fc>]
> (platform_device_add+0x140/0x1d0)
> [    1.572604] [<802de7fc>] (platform_device_add) from [<802dee54>]
> (platform_device_register_full+0xa8/0xe0)
> [    1.582236] [<802dee54>] (platform_device_register_full) from
> [<80754a04>] (exynos_drm_init+0x74/0xc8)
> [    1.591517] [<80754a04>] (exynos_drm_init) from [<80008a48>]
> (do_one_initcall+0x108/0x1d0)
> [    1.599758] [<80008a48>] (do_one_initcall) from [<8072dd64>]
> (kernel_init_freeable+0x108/0x1d4)
> [    1.608433] [<8072dd64>] (kernel_init_freeable) from [<8050e66c>]
> (kernel_init+0x1c/0xf4)
> [    1.616588] [<8050e66c>] (kernel_init) from [<8000e698>]
> (ret_from_fork+0x14/0x20)
> [    1.624143] ---[ end trace 7efd36d9338b10a9 ]---
> [    1.628729] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
> [    1.635855] [drm] Initialized exynos 1.0.0 20110530 on minor 0

Re: linux-next on Chromebook2: DRM failing to allocate

[Kevin Hilman]

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?

Thanks!  I didn'th ave that enabled in the .config.
With that, it seems to allocate, but fails to probe:

[    0.829231] [drm] Initialized drm 1.1.0 20060810
[    0.833153] [drm:drm_platform_init]
[    0.835947] [drm:drm_get_platform_dev]
[    0.839813] [drm:drm_minor_register]
[    0.843580] [drm:drm_minor_register] new minor assigned 64
[    0.848877] [drm:drm_minor_register]
[    0.852512] [drm:drm_minor_register]
[    0.856319] [drm:drm_minor_register] new minor assigned 0
[    0.861568] [drm:exynos_drm_create_enc_conn] *ERROR* failed to create encoder
[    0.868651] [drm:exynos_drm_initialize_displays] *ERROR* Encoder
create [1] failed with -14
[    0.877420] exynos-drm: probe of exynos-drm failed with error -14

Re: linux-next on Chromebook2: DRM failing to allocate

[Kevin Hilman]

On Tue, Jun 10, 2014 at 11:24 AM, 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?
>
> Thanks!  I didn'th ave that enabled in the .config.
> With that, it seems to allocate, but fails to probe:

Oops, ignore this one... operator error.

Re: linux-next on Chromebook2: DRM failing to allocate

[Tomasz Figa]

On 10.06.2014 20:04, Stéphane Marchesin 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?
> 

It should work without IOMMU as well. We're using Exynos DRM on Exynos4
without IOMMU and with CMA instead and it works fine.

Best regards,
Tomasz

Re: linux-next on Chromebook2: DRM failing to allocate

[Kevin Hilman]

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?

Kevin

[1] DRM output with drm.debug=0xff  (full kernel boot log here:
http://hastebin.com/xigofelepe.vhdl

[    1.192850] [drm] Initialized drm 1.1.0 20060810
[    1.197676] [drm:drm_platform_init]
[    1.200224] [drm:drm_get_platform_dev]
[    1.204092] [drm:drm_minor_register]
[    1.207851] [drm:drm_minor_register] new minor assigned 64
[    1.213154] [drm:drm_minor_register]
[    1.216791] [drm:drm_minor_register]
[    1.220608] [drm:drm_minor_register] new minor assigned 0
[    1.225869] [drm:exynos_drm_encoder_create] possible_crtcs = 0x1
[    1.231820] [drm:exynos_drm_encoder_create] encoder has been created
[    1.238295] [drm:drm_sysfs_connector_add] adding "eDP-1" to sysfs
[    1.244222] [drm:drm_sysfs_hotplug_event] generating hotplug event
[    1.250371] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    1.256953] [drm] No driver support for vblank timestamp query.
[    1.262855] [drm:drm_helper_hpd_irq_event] [CONNECTOR:15:eDP-1]
status updated from unknown to connected
[    1.272309] [drm:drm_sysfs_hotplug_event] generating hotplug event
[    1.278480] [drm:exynos_drm_encoder_dpms] encoder dpms: 3
[    1.283849] [drm:exynos_drm_crtc_dpms] crtc[6] mode[3]
[    1.288964] [drm:exynos_drm_crtc_dpms] desired dpms mode is same as
previous one.
[    1.296428] [drm:drm_helper_probe_single_connector_modes_merge_bits]
[CONNECTOR:15:eDP-1]
[    1.304588] [drm:drm_helper_probe_single_connector_modes_merge_bits]
[CONNECTOR:15:eDP-1] probed modes :
[    1.314043] [drm:drm_mode_debug_printmodeline] Modeline
16:"1920x1080" 60 150660 1920 1980 2060 2232 1080 1090 1100 1125 0x48
0x0
[    1.325660] [drm:drm_setup_crtcs]
[    1.329044] [drm:drm_enable_connectors] connector 15 enabled? yes
[    1.335116] [drm:drm_target_preferred] looking for cmdline mode on
connector 15
[    1.342402] [drm:drm_target_preferred] looking for preferred mode
on connector 15
[    1.349862] [drm:drm_target_preferred] found mode 1920x1080
[    1.355414] [drm:drm_setup_crtcs] picking CRTCs for 4096x4096 config
[    1.361749] [drm:drm_setup_crtcs] desired mode 1920x1080 set on crtc 6
[    1.368257] [drm:exynos_drm_fbdev_create] surface width(1920),
height(1080) and bpp(32
[    1.376150] [drm:exynos_drm_init_buf] desired size = 0x7e9000
[    1.381886] [drm:exynos_drm_gem_init] created file object = 0xec7e2000
[    1.391732] [drm:lowlevel_buffer_allocate] dma_addr(0x8e900000),
size(0x7e9000)
[    1.397581] [drm:drm_framebuffer_reference] FB ID: 18
[    1.402614] [drm:exynos_drm_fb_buffer] dma_addr = 0x8e900000
[    1.408526] [drm:drm_crtc_helper_set_config]
[    1.408531] [drm:drm_crtc_helper_set_config] [CRTC:6] [FB:18]
#connectors=1 (x y) (0 0)
[    1.408536] [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set
[    1.408539] [drm:drm_crtc_helper_set_config] modes are different,
full mode set
[    1.408544] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0
0 0 0 0 0 0 0 0x0 0x0
[    1.408549] [drm:drm_mode_debug_printmodeline] Modeline
17:"1920x1080" 60 150660 1920 1980 2060 2232 1080 1090 1100 1125 0x48
0x0
[    1.408553] [drm:drm_crtc_helper_set_config] encoder changed, full
mode switch
[    1.408556] [drm:drm_crtc_helper_set_config] crtc changed, full mode switch
[    1.408560] [drm:drm_crtc_helper_set_config] [CONNECTOR:15:eDP-1] to [CRTC:6]
[    1.408563] [drm:drm_crtc_helper_set_config] attempting to set mode
from userspace
[    1.408568] [drm:drm_mode_debug_printmodeline] Modeline
17:"1920x1080" 60 150660 1920 1980 2060 2232 1080 1090 1100 1125 0x48
0x0
[    1.408574] [drm:drm_crtc_helper_set_mode] [CRTC:6]
[    1.408579] [drm:exynos_drm_fb_buffer] dma_addr = 0x8e900000
[    1.408582] [drm:exynos_plane_mode_set] buffer: 0, dma_addr = 0x8e900000
[    1.408590] [drm:exynos_plane_mode_set] overlay : offset_x/y(0,0),
width/height(1920,1080)
[    1.408591] [drm:fimd_win_mode_set] offset = 0x0, pitch = 1e00
[    1.408595] [drm:fimd_win_mode_set] offset_x = 0, offset_y = 0
[    1.408598] [drm:fimd_win_mode_set] ovl_width = 1920, ovl_height = 1080
[    1.408601] [drm:fimd_win_mode_set] paddr = 0x8e900000
[    1.408604] [drm:fimd_win_mode_set] fb_width = 1920, crtc_width = 1920
[    1.408607] [drm:drm_framebuffer_reference] FB ID: 18
[    1.408611] [drm:drm_crtc_helper_set_mode] [ENCODER:14:TMDS-14] set
[MODE:17:1920x1080]
[    1.408614] [drm:exynos_drm_crtc_dpms] crtc[6] mode[0]
[    1.408618] [drm:fimd_dpms] ../drivers/gpu/drm/exynos/exynos_drm_fimd.c, 0
[    1.408649] [drm:fimd_win_commit] start addr = 0x8e900000, end addr
= 0x8f0e9000, size = 0x7e9000
[    1.408652] [drm:fimd_win_commit] ovl_width = 1920, ovl_height = 1080
[    1.408656] [drm:fimd_win_commit] osd pos: tx = 0, ty = 0, bx =
1919, by = 1079
[    1.408660] [drm:fimd_win_commit] osd size = 0x1fa400
[    1.408663] [drm:fimd_win_set_pixfmt] bpp = 32
[    1.408948] [drm:drm_calc_timestamping_constants] crtc 6: hwmode:
htotal 2232, vtotal 1125, vdisplay 1080
[    1.408953] [drm:drm_calc_timestamping_constants] crtc 6: clock
150660 kHz framedur 16666666 linedur 14814, pixeldur 6
[    1.408958] [drm:drm_crtc_helper_set_config] Setting connector DPMS
state to on
[    1.408961] [drm:drm_crtc_helper_set_config] [CONNECTOR:15:eDP-1] set DPMS on
[    1.408966] [drm:drm_framebuffer_reference] FB ID: 18
[    1.409097] [drm:drm_crtc_helper_set_config]
[    1.409102] [drm:drm_crtc_helper_set_config] [CRTC:6] [FB:18]
#connectors=1 (x y) (0 0)
[    1.409107] [drm:drm_crtc_helper_set_config] [CONNECTOR:15:eDP-1] to [CRTC:6]
[    1.409110] [drm:drm_framebuffer_reference] FB ID: 18
[    1.409113] [drm:drm_framebuffer_unreference] FB ID: 18
[    1.422580] Console: switching to colour frame buffer device 274x77
[    1.422587] [drm:drm_crtc_helper_set_config]
[    1.422591] [drm:drm_crtc_helper_set_config] [CRTC:6] [FB:18]
#connectors=1 (x y) (0 0)
[    1.422596] [drm:drm_crtc_helper_set_config] [CONNECTOR:15:eDP-1] to [CRTC:6]
[    1.422600] [drm:drm_framebuffer_reference] FB ID: 18
[    1.422603] [drm:drm_framebuffer_unreference] FB ID: 18
[    1.745135] exynos-drm exynos-drm: fb0:  frame buffer device
[    1.752593] exynos-drm exynos-drm: registered panic notifier
[    1.773526] [drm] Initialized exynos 1.0.0 20110530 on minor 0

Re: linux-next on Chromebook2: DRM failing to allocate

[Ajay kumar]

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

And, Arun/me will be sending all the DT changes necessary for fimd, dp
and peach-pi panel, ASAP!

Ajay

> Kevin
>
> [1] DRM output with drm.debug=0xff  (full kernel boot log here:
> http://hastebin.com/xigofelepe.vhdl
>
> [    1.192850] [drm] Initialized drm 1.1.0 20060810
> [    1.197676] [drm:drm_platform_init]
> [    1.200224] [drm:drm_get_platform_dev]
> [    1.204092] [drm:drm_minor_register]
> [    1.207851] [drm:drm_minor_register] new minor assigned 64
> [    1.213154] [drm:drm_minor_register]
> [    1.216791] [drm:drm_minor_register]
> [    1.220608] [drm:drm_minor_register] new minor assigned 0
> [    1.225869] [drm:exynos_drm_encoder_create] possible_crtcs = 0x1
> [    1.231820] [drm:exynos_drm_encoder_create] encoder has been created
> [    1.238295] [drm:drm_sysfs_connector_add] adding "eDP-1" to sysfs
> [    1.244222] [drm:drm_sysfs_hotplug_event] generating hotplug event
> [    1.250371] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [    1.256953] [drm] No driver support for vblank timestamp query.
> [    1.262855] [drm:drm_helper_hpd_irq_event] [CONNECTOR:15:eDP-1]
> status updated from unknown to connected
> [    1.272309] [drm:drm_sysfs_hotplug_event] generating hotplug event
> [    1.278480] [drm:exynos_drm_encoder_dpms] encoder dpms: 3
> [    1.283849] [drm:exynos_drm_crtc_dpms] crtc[6] mode[3]
> [    1.288964] [drm:exynos_drm_crtc_dpms] desired dpms mode is same as
> previous one.
> [    1.296428] [drm:drm_helper_probe_single_connector_modes_merge_bits]
> [CONNECTOR:15:eDP-1]
> [    1.304588] [drm:drm_helper_probe_single_connector_modes_merge_bits]
> [CONNECTOR:15:eDP-1] probed modes :
> [    1.314043] [drm:drm_mode_debug_printmodeline] Modeline
> 16:"1920x1080" 60 150660 1920 1980 2060 2232 1080 1090 1100 1125 0x48
> 0x0
> [    1.325660] [drm:drm_setup_crtcs]
> [    1.329044] [drm:drm_enable_connectors] connector 15 enabled? yes
> [    1.335116] [drm:drm_target_preferred] looking for cmdline mode on
> connector 15
> [    1.342402] [drm:drm_target_preferred] looking for preferred mode
> on connector 15
> [    1.349862] [drm:drm_target_preferred] found mode 1920x1080
> [    1.355414] [drm:drm_setup_crtcs] picking CRTCs for 4096x4096 config
> [    1.361749] [drm:drm_setup_crtcs] desired mode 1920x1080 set on crtc 6
> [    1.368257] [drm:exynos_drm_fbdev_create] surface width(1920),
> height(1080) and bpp(32
> [    1.376150] [drm:exynos_drm_init_buf] desired size = 0x7e9000
> [    1.381886] [drm:exynos_drm_gem_init] created file object = 0xec7e2000
> [    1.391732] [drm:lowlevel_buffer_allocate] dma_addr(0x8e900000),
> size(0x7e9000)
> [    1.397581] [drm:drm_framebuffer_reference] FB ID: 18
> [    1.402614] [drm:exynos_drm_fb_buffer] dma_addr = 0x8e900000
> [    1.408526] [drm:drm_crtc_helper_set_config]
> [    1.408531] [drm:drm_crtc_helper_set_config] [CRTC:6] [FB:18]
> #connectors=1 (x y) (0 0)
> [    1.408536] [drm:drm_crtc_helper_set_config] crtc has no fb, full mode
> set
> [    1.408539] [drm:drm_crtc_helper_set_config] modes are different,
> full mode set
> [    1.408544] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0
> 0 0 0 0 0 0 0 0x0 0x0
> [    1.408549] [drm:drm_mode_debug_printmodeline] Modeline
> 17:"1920x1080" 60 150660 1920 1980 2060 2232 1080 1090 1100 1125 0x48
> 0x0
> [    1.408553] [drm:drm_crtc_helper_set_config] encoder changed, full
> mode switch
> [    1.408556] [drm:drm_crtc_helper_set_config] crtc changed, full mode
> switch
> [    1.408560] [drm:drm_crtc_helper_set_config] [CONNECTOR:15:eDP-1] to
> [CRTC:6]
> [    1.408563] [drm:drm_crtc_helper_set_config] attempting to set mode
> from userspace
> [    1.408568] [drm:drm_mode_debug_printmodeline] Modeline
> 17:"1920x1080" 60 150660 1920 1980 2060 2232 1080 1090 1100 1125 0x48
> 0x0
> [    1.408574] [drm:drm_crtc_helper_set_mode] [CRTC:6]
> [    1.408579] [drm:exynos_drm_fb_buffer] dma_addr = 0x8e900000
> [    1.408582] [drm:exynos_plane_mode_set] buffer: 0, dma_addr = 0x8e900000
> [    1.408590] [drm:exynos_plane_mode_set] overlay : offset_x/y(0,0),
> width/height(1920,1080)
> [    1.408591] [drm:fimd_win_mode_set] offset = 0x0, pitch = 1e00
> [    1.408595] [drm:fimd_win_mode_set] offset_x = 0, offset_y = 0
> [    1.408598] [drm:fimd_win_mode_set] ovl_width = 1920, ovl_height = 1080
> [    1.408601] [drm:fimd_win_mode_set] paddr = 0x8e900000
> [    1.408604] [drm:fimd_win_mode_set] fb_width = 1920, crtc_width = 1920
> [    1.408607] [drm:drm_framebuffer_reference] FB ID: 18
> [    1.408611] [drm:drm_crtc_helper_set_mode] [ENCODER:14:TMDS-14] set
> [MODE:17:1920x1080]
> [    1.408614] [drm:exynos_drm_crtc_dpms] crtc[6] mode[0]
> [    1.408618] [drm:fimd_dpms] ../drivers/gpu/drm/exynos/exynos_drm_fimd.c,
> 0
> [    1.408649] [drm:fimd_win_commit] start addr = 0x8e900000, end addr
> = 0x8f0e9000, size = 0x7e9000
> [    1.408652] [drm:fimd_win_commit] ovl_width = 1920, ovl_height = 1080
> [    1.408656] [drm:fimd_win_commit] osd pos: tx = 0, ty = 0, bx =
> 1919, by = 1079
> [    1.408660] [drm:fimd_win_commit] osd size = 0x1fa400
> [    1.408663] [drm:fimd_win_set_pixfmt] bpp = 32
> [    1.408948] [drm:drm_calc_timestamping_constants] crtc 6: hwmode:
> htotal 2232, vtotal 1125, vdisplay 1080
> [    1.408953] [drm:drm_calc_timestamping_constants] crtc 6: clock
> 150660 kHz framedur 16666666 linedur 14814, pixeldur 6
> [    1.408958] [drm:drm_crtc_helper_set_config] Setting connector DPMS
> state to on
> [    1.408961] [drm:drm_crtc_helper_set_config] [CONNECTOR:15:eDP-1] set
> DPMS on
> [    1.408966] [drm:drm_framebuffer_reference] FB ID: 18
> [    1.409097] [drm:drm_crtc_helper_set_config]
> [    1.409102] [drm:drm_crtc_helper_set_config] [CRTC:6] [FB:18]
> #connectors=1 (x y) (0 0)
> [    1.409107] [drm:drm_crtc_helper_set_config] [CONNECTOR:15:eDP-1] to
> [CRTC:6]
> [    1.409110] [drm:drm_framebuffer_reference] FB ID: 18
> [    1.409113] [drm:drm_framebuffer_unreference] FB ID: 18
> [    1.422580] Console: switching to colour frame buffer device 274x77
> [    1.422587] [drm:drm_crtc_helper_set_config]
> [    1.422591] [drm:drm_crtc_helper_set_config] [CRTC:6] [FB:18]
> #connectors=1 (x y) (0 0)
> [    1.422596] [drm:drm_crtc_helper_set_config] [CONNECTOR:15:eDP-1] to
> [CRTC:6]
> [    1.422600] [drm:drm_framebuffer_reference] FB ID: 18
> [    1.422603] [drm:drm_framebuffer_unreference] FB ID: 18
> [    1.745135] exynos-drm exynos-drm: fb0:  frame buffer device
> [    1.752593] exynos-drm exynos-drm: registered panic notifier
> [    1.773526] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: linux-next on Chromebook2: DRM failing to allocate

[Kevin Hilman]

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

Re: linux-next on Chromebook2: DRM failing to allocate

[Rahul Sharma]

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.

Regards,
Rahul sharma.

>
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next on Chromebook2: DRM failing to allocate

[Kevin Hilman]

[-- Attachment #1: Type: text/plain, Size: 3372 bytes --]

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.

I've configured the kernel using the chromeos configs provided:

  ./chromeos/scripts/prepareconfig chromeos-exynos5

And then I append the some kconfig fragments[1] to enable DT append, and
enable the serial port.

>From the kernel messages, it appears that everything is working ok, but
I don't see anything on the display yet.  Attached is the .config used
and the boot log with drm.drm_debug=0xff.

Kevin

[1] 
CONFIG_OF=y
CONFIG_PROC_DEVICETREE=y
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_SERIAL_SAMSUNG=y
CONFIG_SERIAL_SAMSUNG_CONSOLE=y
CONFIG_MALI_T6XX=n


[-- Attachment #2: dot.config.gz --]
[-- Type: application/octet-stream, Size: 23663 bytes --]

[-- Attachment #3: boot-chromebook2.log.gz --]
[-- Type: application/octet-stream, Size: 13556 bytes --]

Re: linux-next on Chromebook2: DRM failing to allocate

[Ajay kumar]

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.
Same DT changes should work, just make one change:
Rename the property in exynos5800-peach-pi.dts:
- "panel-enable-delay = <105>"
+ "panel-prepare-delay = <105>"


Ajay

> I've configured the kernel using the chromeos configs provided:
>
>   ./chromeos/scripts/prepareconfig chromeos-exynos5
>
> And then I append the some kconfig fragments[1] to enable DT append, and
> enable the serial port.
>
> From the kernel messages, it appears that everything is working ok, but
> I don't see anything on the display yet.  Attached is the .config used
> and the boot log with drm.drm_debug=0xff.
>
> Kevin
>
> [1]
> CONFIG_OF=y
> CONFIG_PROC_DEVICETREE=y
> CONFIG_ARM_APPENDED_DTB=y
> CONFIG_ARM_ATAG_DTB_COMPAT=y
> CONFIG_SERIAL_SAMSUNG=y
> CONFIG_SERIAL_SAMSUNG_CONSOLE=y
> CONFIG_MALI_T6XX=n
>

Re: linux-next on Chromebook2: DRM failing to allocate

[Kevin Hilman]

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