* linux-next on Chromebook2: DRM failing to allocate
@ 2014-06-10 17:56 Kevin Hilman
2014-06-10 18:04 ` Stéphane Marchesin
0 siblings, 1 reply; 12+ messages in thread
From: Kevin Hilman @ 2014-06-10 17:56 UTC (permalink / raw)
To: linux-samsung-soc
Cc: marcheu, seanpaul, djkurtz, Inki Dae, naveenkrishna.ch,
linaro-kernel, Tushar Behera, Tomasz Figa
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next on Chromebook2: DRM failing to allocate
2014-06-10 17:56 linux-next on Chromebook2: DRM failing to allocate Kevin Hilman
@ 2014-06-10 18:04 ` Stéphane Marchesin
2014-06-10 18:24 ` Kevin Hilman
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Stéphane Marchesin @ 2014-06-10 18:04 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-samsung-soc, Sean Paul, Daniel Kurtz, Inki Dae,
naveenkrishna.ch, linaro-kernel, Tushar Behera, Tomasz Figa
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next on Chromebook2: DRM failing to allocate
2014-06-10 18:04 ` Stéphane Marchesin
@ 2014-06-10 18:24 ` Kevin Hilman
2014-06-10 18:36 ` Kevin Hilman
2014-06-10 18:56 ` Tomasz Figa
2014-06-10 19:29 ` Kevin Hilman
2 siblings, 1 reply; 12+ messages in thread
From: Kevin Hilman @ 2014-06-10 18:24 UTC (permalink / raw)
To: Stéphane Marchesin
Cc: linux-samsung-soc, Sean Paul, Daniel Kurtz, Inki Dae,
naveenkrishna.ch, linaro-kernel, Tushar Behera, Tomasz Figa
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next on Chromebook2: DRM failing to allocate
2014-06-10 18:24 ` Kevin Hilman
@ 2014-06-10 18:36 ` Kevin Hilman
0 siblings, 0 replies; 12+ messages in thread
From: Kevin Hilman @ 2014-06-10 18:36 UTC (permalink / raw)
To: Stéphane Marchesin
Cc: linux-samsung-soc, Sean Paul, Daniel Kurtz, Inki Dae,
Naveen Krishna, linaro-kernel, Tushar Behera, Tomasz Figa
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next on Chromebook2: DRM failing to allocate
2014-06-10 18:04 ` Stéphane Marchesin
2014-06-10 18:24 ` Kevin Hilman
@ 2014-06-10 18:56 ` Tomasz Figa
2014-06-10 19:29 ` Kevin Hilman
2 siblings, 0 replies; 12+ messages in thread
From: Tomasz Figa @ 2014-06-10 18:56 UTC (permalink / raw)
To: Stéphane Marchesin, Kevin Hilman
Cc: linux-samsung-soc, Sean Paul, Daniel Kurtz, Inki Dae,
naveenkrishna.ch, linaro-kernel, Tushar Behera, 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next on Chromebook2: DRM failing to allocate
2014-06-10 18:04 ` Stéphane Marchesin
2014-06-10 18:24 ` Kevin Hilman
2014-06-10 18:56 ` Tomasz Figa
@ 2014-06-10 19:29 ` Kevin Hilman
2014-06-10 20:51 ` Ajay kumar
2 siblings, 1 reply; 12+ messages in thread
From: Kevin Hilman @ 2014-06-10 19:29 UTC (permalink / raw)
To: Stéphane Marchesin
Cc: linux-samsung-soc, Sean Paul, Daniel Kurtz, Inki Dae,
Naveen Krishna, linaro-kernel, Tushar Behera, Tomasz Figa,
Olof Johansson
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next on Chromebook2: DRM failing to allocate
2014-06-10 19:29 ` Kevin Hilman
@ 2014-06-10 20:51 ` Ajay kumar
2014-06-10 22:18 ` Kevin Hilman
0 siblings, 1 reply; 12+ messages in thread
From: Ajay kumar @ 2014-06-10 20:51 UTC (permalink / raw)
To: Kevin Hilman
Cc: Stéphane Marchesin, linux-samsung-soc, Sean Paul,
Daniel Kurtz, Inki Dae, Naveen Krishna, linaro-kernel,
Tushar Behera, Tomasz Figa, Olof Johansson
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next on Chromebook2: DRM failing to allocate
2014-06-10 20:51 ` Ajay kumar
@ 2014-06-10 22:18 ` Kevin Hilman
2014-06-11 3:47 ` Rahul Sharma
0 siblings, 1 reply; 12+ messages in thread
From: Kevin Hilman @ 2014-06-10 22:18 UTC (permalink / raw)
To: Ajay kumar
Cc: Stéphane Marchesin, linux-samsung-soc, Sean Paul,
Daniel Kurtz, Inki Dae, Naveen Krishna, linaro-kernel,
Tushar Behera, Tomasz Figa, Olof Johansson
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next on Chromebook2: DRM failing to allocate
2014-06-10 22:18 ` Kevin Hilman
@ 2014-06-11 3:47 ` Rahul Sharma
2014-06-11 21:18 ` Kevin Hilman
0 siblings, 1 reply; 12+ messages in thread
From: Rahul Sharma @ 2014-06-11 3:47 UTC (permalink / raw)
To: Kevin Hilman
Cc: Ajay kumar, Stéphane Marchesin, linux-samsung-soc,
Sean Paul, Daniel Kurtz, Inki Dae, Naveen Krishna, linaro-kernel,
Tushar Behera, Tomasz Figa, Olof Johansson, sunil joshi
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next on Chromebook2: DRM failing to allocate
2014-06-11 3:47 ` Rahul Sharma
@ 2014-06-11 21:18 ` Kevin Hilman
2014-06-12 8:44 ` Ajay kumar
0 siblings, 1 reply; 12+ messages in thread
From: Kevin Hilman @ 2014-06-11 21:18 UTC (permalink / raw)
To: Rahul Sharma
Cc: Ajay kumar, Stéphane Marchesin, linux-samsung-soc,
Sean Paul, Daniel Kurtz, Inki Dae, Naveen Krishna, linaro-kernel,
Tushar Behera, Tomasz Figa, Olof Johansson, sunil joshi
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next on Chromebook2: DRM failing to allocate
2014-06-11 21:18 ` Kevin Hilman
@ 2014-06-12 8:44 ` Ajay kumar
2014-06-12 19:50 ` Kevin Hilman
0 siblings, 1 reply; 12+ messages in thread
From: Ajay kumar @ 2014-06-12 8:44 UTC (permalink / raw)
To: Kevin Hilman
Cc: Rahul Sharma, Stéphane Marchesin, linux-samsung-soc,
Sean Paul, Daniel Kurtz, Inki Dae, Naveen Krishna, linaro-kernel,
Tushar Behera, Tomasz Figa, Olof Johansson, sunil joshi
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next on Chromebook2: DRM failing to allocate
2014-06-12 8:44 ` Ajay kumar
@ 2014-06-12 19:50 ` Kevin Hilman
0 siblings, 0 replies; 12+ messages in thread
From: Kevin Hilman @ 2014-06-12 19:50 UTC (permalink / raw)
To: Ajay kumar
Cc: Rahul Sharma, Stéphane Marchesin, linux-samsung-soc,
Sean Paul, Daniel Kurtz, Inki Dae, Naveen Krishna, linaro-kernel,
Tushar Behera, Tomasz Figa, Olof Johansson, sunil joshi
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-06-12 19:50 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-10 17:56 linux-next on Chromebook2: DRM failing to allocate Kevin Hilman
2014-06-10 18:04 ` Stéphane Marchesin
2014-06-10 18:24 ` Kevin Hilman
2014-06-10 18:36 ` Kevin Hilman
2014-06-10 18:56 ` Tomasz Figa
2014-06-10 19:29 ` Kevin Hilman
2014-06-10 20:51 ` Ajay kumar
2014-06-10 22:18 ` Kevin Hilman
2014-06-11 3:47 ` Rahul Sharma
2014-06-11 21:18 ` Kevin Hilman
2014-06-12 8:44 ` Ajay kumar
2014-06-12 19:50 ` Kevin Hilman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.