New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Feature



Sign in to add a comment
link

Issue 907715: scarlet/kevin: Create an environment for video and camera testing on upstream kernels

Reported by tfiga@chromium.org, Nov 22 Project Member

Issue description

Creating this bug to track any changes needed to get a bootable and usable Chromium OS image on scarlet and kevin running an upstream kernel.

The two things discovered until now are:
- kernel config options for the Kingdisplay MIPI DSI panel missing in the fallback rockchip64_defconfig,
- portage overrides needed to install media-libs/mesa with LLVMpipe and  its dependencies (e.g. sys-devel/llvm) instead of the proprietary graphics stack.
 

Comment 1 by tfiga@chromium.org, Nov 22

Status: Started (was: Untriaged)

Comment 3 by tfiga@google.com, Nov 22

With all the CLs from the topic in #2 and with attached kernel patches on top of latest linux-next, building and flashing scarlet-upstream gives me a usable system that I can sign in to.
0001-FROMLIST-drm-panel-add-Kingdisplay-kd097d04-panel-dr.patch
14.3 KB Download
0002-CHROMIUM-drm-Add-drm_master_relax-debugfs-file-non-r.patch
6.2 KB Download
0003-CHROMIUM-drm-Allow-DRM_IOCTL_MODE_MAP_DUMB-for-rende.patch
2.8 KB Download
0004-CHROMIUM-drm-Allow-render-node-access-to-KMS-getters.patch
5.0 KB Download
0005-CHROMIUM-drm-Allow-DRM_IOCTL_MODE_DESTROY_DUMB-for-r.patch
2.3 KB Download
0006-CHROMIUM-drm-rockchip-Enable-rendernode.patch
1.3 KB Download
0007-CHROMIUM-drm-rockchip-Add-GEM-ioctls.patch
7.4 KB Download
0008-CHROMIUM-Revert-drm-vgem-create-a-render-node-for-vg.patch
1.2 KB Download

Comment 4 by bugdroid1@chromium.org, Nov 23

Project Member
Labels: merge-merged-arc-18.2.0-pre1
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/mesa/+/99760adafdb41739ee2b181827e71796ba7b202f

commit 99760adafdb41739ee2b181827e71796ba7b202f
Author: Ray Strode <rstrode@redhat.com>
Date: Fri Nov 23 03:07:55 2018

UPSTREAM: gallium/winsys/kms: don't unmap what wasn't mapped

At the moment, depending on pipe transfer flags, the dumb
buffer map address can end up at either kms_sw_dt->ro_mapped
or kms_sw_dt->mapped.

When it's time to unmap the dumb buffer, both locations get unmapped,
even though one is probably initialized to 0.

That leads to the code segment getting unmapped at runtime and
crashes when trying to call into unrelated code.

This commit addresses the problem by using MAP_FAILED instead of
NULL for ro_mapped and mapped when the dumb buffer is unmapped,
and only unmapping mapped addresses at unmap time.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107098
Signed-off-by: Ray Strode <rstrode@redhat.com>
Fixes: d891f28df9a ("gallium/winsys/kms: Fix possible leak in map/unmap.")
Cc: Lepton Wu <lepton@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 9baff597ce021f7691187b0d1d1bbc16d07b13e1)

BUG=chromium:907715
TEST=llvmpipe does not crash on scarlet anymore

Change-Id: I4b218d1dd0419ff3ef691179b75c6fcf91244882
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1343916
Reviewed-by: Lepton Wu <lepton@chromium.org>

[modify] https://crrev.com/99760adafdb41739ee2b181827e71796ba7b202f/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c

Comment 5 by bugdroid1@chromium.org, Nov 23

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/fd6b158722ed88bf0252b8cf04120c6549d9ec02

commit fd6b158722ed88bf0252b8cf04120c6549d9ec02
Author: Tomasz Figa <tfiga@chromium.org>
Date: Fri Nov 23 03:07:40 2018

media-libs/mesa: Fix spurious munmaps when kms-swrast is used

Add a patch to cherry pick an upstream commit that fixes the problem:
9baff597ce0 ("gallium/winsys/kms: don't unmap what wasn't mapped")

BUG=chromium:907715
TEST=llvmpipe does not crash anymore on scarlet

Change-Id: Ia14c92b4135c5a7e9285ab1d332b3c6124fb3dc6
Reviewed-on: https://chromium-review.googlesource.com/1343917
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Lepton Wu <lepton@chromium.org>

[modify] https://crrev.com/fd6b158722ed88bf0252b8cf04120c6549d9ec02/media-libs/mesa/mesa-9999.ebuild
[modify] https://crrev.com/fd6b158722ed88bf0252b8cf04120c6549d9ec02/media-libs/mesa/mesa-18.2_pre1.ebuild
[rename] https://crrev.com/fd6b158722ed88bf0252b8cf04120c6549d9ec02/media-libs/mesa/mesa-18.2_pre1-r25.ebuild
[add] https://crrev.com/fd6b158722ed88bf0252b8cf04120c6549d9ec02/media-libs/mesa/files/18.2-gallium-winsys-kms-dont-unmap-what-wasnt-mapped.patch

Comment 6 by bugdroid1@chromium.org, Nov 23

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/4f1c6852a110e55171af3c899d9f517b7e76d075

commit 4f1c6852a110e55171af3c899d9f517b7e76d075
Author: Tomasz Figa <tfiga@chromium.org>
Date: Fri Nov 23 03:07:40 2018

eclass/cros-kernel: Enable Kingdisplay config options in rockchip64_defconfig

Some variants of Scarlet are equipped with a MIPI DSI display by
Kingdisplay. Add necessary config options to rockchip64_defconfig.

BUG=chromium:907715
TEST=Display lights up with upstream kernel on a Kingdisplay Scarlet

Change-Id: Ida76fd2c81f5795d6b616d17ffd577bc78de8ac4
Reviewed-on: https://chromium-review.googlesource.com/1343918
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>

[modify] https://crrev.com/4f1c6852a110e55171af3c899d9f517b7e76d075/eclass/cros-kernel/rockchip64_defconfig

Comment 7 by tfiga@google.com, Nov 27

Doug suggested an idea of just setting the appropriate environment variables in the chroot and then use the regular workflow (build_packages, build_image, any manual emerges, etc.). It needs one CL to pull Mesa instead of the proprietary graphics libraries when LLVMpipe is enabled, but otherwise works really well and doesn't seem to require too many rebuilds from an already build Chrome OS for given board. Thanks Doug for the nice idea.

The current instructions are:

1) Cherry pick the CLs in
https://chromium-review.googlesource.com/q/hashtag:%2522scarlet-upstream%2522+status:open
(for anyone with internal checkout also:
https://chrome-internal-review.googlesource.com/q/hashtag:%2522scarlet-upstream%2522+status:open),

2) export VIDEO_CARDS=llvmpipe,

3) for scarlet:
export USE="llvm llvm_targets_ARM gpu_sandbox_failures_not_fatal -gpu_sandbox_start_early -tpm2 mocktpm"

for kevin:
USE="llvm llvm_targets_ARM gpu_sandbox_failures_not_fatal -gpu_sandbox_start_early",

4) check out your upstream branch of choice to src/third_party/kernel/v4.4,

5) apply the patches from comment #3,

6) cros_workon-$BOARD start minigbm chromeos-kernel-4_4,

7) follow the regular Chrome OS build flow, flash the image and get a working Chrome OS image on an (almost clean) upstream kernel.

Then you can just make any changes in the kernel and follow the normal emerge-$BOARD chromeos-kernel-4_4 && ./update_kernel.sh [...] workflow, or whatever you normally use with Chrome OS, to update the kernel on the device.

Comment 8 by tfiga@google.com, Nov 27

Cc: ezequ...@collabora.com

Comment 9 by tfiga@google.com, Nov 27

Also, that was tested on Scarlet. I'm going to try on Kevin as well.

Ezequiel reported that some display-related configs are missing from rockchip64_defconfig [1] and also USB devices not being detected (?).

[1] https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/eclass/cros-kernel/rockchip64_defconfig

Comment 10 by tfiga@google.com, Nov 27

Cc: marc...@chromium.org

Comment 11 by tfiga@chromium.org, Nov 27

Correction. In 2), it should be:

export VIDEO_CARDS="llvmpipe rockchip"

I just tested on my kevin and with some additions to rockchip64_defconfig (included in the cherry picks from 1)), both display and USB seem to work - I can SSH to the device over a USB ethernet.

Comment 12 by bugdroid1@chromium.org, Nov 30

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/eb9f1c352678d44ba2e624f65b98a73cfc26a57d

commit eb9f1c352678d44ba2e624f65b98a73cfc26a57d
Author: Tomasz Figa <tfiga@chromium.org>
Date: Fri Nov 30 00:09:05 2018

eclass/cros-kernel: Enable Analogix DP bridge in rockchip64_defconfig

The display on Kevin is routed via an Analogix DP bridge built into
the SoC. Add necessary config options to rockchip64_defconfig.

BUG=chromium:907715
TEST=Display lights up with upstream kernel on a kevin

Change-Id: I464ffc2b766641ef70e98a7481ae81a0113b2166
Reviewed-on: https://chromium-review.googlesource.com/1351313
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>

[modify] https://crrev.com/eb9f1c352678d44ba2e624f65b98a73cfc26a57d/eclass/cros-kernel/rockchip64_defconfig

Comment 13 by briannorris@chromium.org, Nov 30

For the record:

Be careful with using Kevin on 4.19+. It's easy to get your Wifi into a deadlock:

https://patchwork.kernel.org/patch/10706959/
[4.20 PATCH] Revert "mwifiex: restructure rx_reorder_tbl_lock usage"

*SMH*

Hopefully that will get merged quickly.

Comment 14 by briannorris@chromium.org, Dec 5

Does anyone actually have Scarlet + K&D display working on 4.20-rc+? I'm using the DTS from rockchip/for-next, but I keep getting this super-helpful probe deferral loop:

[   24.576726] rockchip-drm display-subsystem: bound ff8f0000.vop (ops 0xffffff8008a72b60)
[   24.587245] rockchip-drm display-subsystem: bound ff900000.vop (ops 0xffffff8008a72b60)
[   24.596622] panel-kingdisplay-kd097d04 ff960000.mipi.0: Linked as a consumer to regulator.4
[   24.606065] rockchip-drm display-subsystem: bound ff960000.mipi (ops 0xffffff8008a75320)
[   24.615234] rockchip-drm display-subsystem: failed to bind ff968000.mipi (ops 0xffffff8008a75320): -517
[   24.625840] panel-kingdisplay-kd097d04 ff960000.mipi.0: Dropping the link to regulator.4
[   24.635077] rockchip-drm display-subsystem: master bind failed: -517
[   24.645403] rockchip-drm display-subsystem: bound ff8f0000.vop (ops 0xffffff8008a72b60)
[   24.655938] rockchip-drm display-subsystem: bound ff900000.vop (ops 0xffffff8008a72b60)
[   24.665307] panel-kingdisplay-kd097d04 ff960000.mipi.0: Linked as a consumer to regulator.4
[   24.674768] rockchip-drm display-subsystem: bound ff960000.mipi (ops 0xffffff8008a75320)
[   24.683942] rockchip-drm display-subsystem: failed to bind ff968000.mipi (ops 0xffffff8008a75320): -517

It appears to be an infinite loop. I'm impressed.

(A red herring: audio also was stuck in a probe deferral, but disabling it doesn't help. It appears the display subsystem is looping all by itself.)

Comment 15 by briannorris@chromium.org, Dec 5

Ah, the dual MIPI stuff was only in -next. (It still sucks that DRM can put itself in an infinite deferral loop like that though.)

With pulling the appropriate bits from drm-next, I have things working.

Comment 16 by groeck@chromium.org, Dec 5

517 is EPROBEDEFER. That means keep trying, so the loop isn't surprising. There maybe a bad dependency loop - a depends on b depends on c depends on a or similar.

Comment 17 by tfiga@chromium.org, Dec 11

Cc: acourbot@chromium.org

Comment 18 by tfiga@chromium.org, Dec 12

Updated the kernel patches to work with recent linux-next.
0001-FROMLIST-drm-panel-add-Kingdisplay-kd097d04-panel-dr.patch
14.3 KB Download
0002-CHROMIUM-drm-Add-drm_master_relax-debugfs-file-non-r.patch
6.2 KB Download
0003-CHROMIUM-drm-Allow-DRM_IOCTL_MODE_MAP_DUMB-for-rende.patch
2.8 KB Download
0004-CHROMIUM-drm-Allow-render-node-access-to-KMS-getters.patch
5.0 KB Download
0005-CHROMIUM-drm-Allow-DRM_IOCTL_MODE_DESTROY_DUMB-for-r.patch
2.3 KB Download
0006-CHROMIUM-drm-rockchip-Enable-rendernode.patch
1.3 KB Download
0007-CHROMIUM-drm-rockchip-Add-GEM-ioctls.patch
7.4 KB Download
0008-CHROMIUM-Revert-drm-vgem-create-a-render-node-for-vg.patch
1.2 KB Download

Comment 19 by ezequ...@collabora.com, Dec 13

I had to add this to get audio:

diff --git a/eclass/cros-kernel/rockchip64_defconfig b/eclass/cros-kernel/rockchip64_defconfig
index 8b082c1438b0..9a5aeeaba095 100644
--- a/eclass/cros-kernel/rockchip64_defconfig
+++ b/eclass/cros-kernel/rockchip64_defconfig
@@ -346,7 +346,7 @@ CONFIG_DRM_BRIDGE=y
 CONFIG_DRM_PANEL_BRIDGE=y
 CONFIG_DRM_ROCKCHIP=y
 CONFIG_ROCKCHIP_ANALOGIX_DP=y
-CONFIG_DRM_ROCKCHIP_CDN_DP=y
+CONFIG_ROCKCHIP_CDN_DP=y
 CONFIG_FB=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y

Comment 20 by tfiga@chromium.org, Dec 21

Just FYI, IIRC acourbot@ had some problems with recent linux-next, so here's my last known good tag: next-20181127.

Sign in to add a comment