The CL for default labels is crosreview.com/802596 and crosreview.com/805636
I think the below are directories for chipsets.
SundyBridge: overlay-stumpy
Haswell: chipset-hsw
BayTrail(Rabmbi): chipset-byt
Broadwell: chipset-bdw
Braswell: chipset-bsw
Skylake: chipset-skl
ApolloLake: chipset-apl
KabyLake: chipset-kbl
CannonLake: chipset-cnl
Exynos5250: overlay-daisy
Exynos5420:overlay-peach
Tegra K1: overlay-nyan
RK3288: overlay-veyron
RK3399: chipset-rk3399
MTK8173: chipset-mt8173
What is a directory for IvyBridge?
I uploaded some CLs this week.
autotest-capability: this package installs capabilities /etc/autotest-capability on DUT
crosreview.com/805636crosreview.com/802596
video_Capability: test for verifying the static label solution.
crosreview.com/814254
I confirm video_Capability run on peach_pit.
In the current implementation, the test outputs results/capability.log.
The output result on peach_pit is the below
dec_h264_720_60
dec_h264_1080_30
dec_h264_1080_60
dec_h264_2160_30
dec_vp8_720_60
dec_vp8_1080_30
dec_vp8_1080_60
dec_jpeg
enc_h264_1080_30
enc_vp8_1080_30
webcam
I am going to address more detailed cases, for instance, SKEW problem and kepler next week.
I am also implementing a monitor program. It acquires video_Capability results on autotest lab and alert if it is changed.
I write a small script to visualize a tree structure in overlays.
The created graphs is attached. (Sorry for awful visual and I'd say it is possibly wrong.)
Some boards have no person, for example, sumo.
The parent of sumo should be chipset-byt.
I also found the parent of parrot-ivb is parrot. parrot-ivb is IvyBridge and parrot is SandyBridge.
In the case, we couldn't probably set the parent of parrot to "chipset-sb."
Of course, as you know, there is no "chipset-sb" now.
We don't and won't have chipset directories for SandyBridge and IvyBridge.
So it is necessary to put chipset and baseboard yaml files in each overlay directory.
SandyBridge:
butterfly, lumpy, parrot, stumpy
IvyBrdige:
link, parrot-ivb, stout
I updated the overlay CLs. crosreview.com/821391, crosreview.com/805636
The current CLs are expected to install the appropriate files to DUT.
I am going to review CLs carefully by myself and test some cases tomorrow.
It is better they will be reviewed by others after I would do.
I noticed IvyBridge supports JPEG decoding, and h264 hw encoding test run on lumpy, stumpy, link and stout.
For link and stout, IvyBridge and SandyBridge supports hw h264 encoding.
I changed as parrot-ivb doesn't support h264 encoding.
As for SandyBridge devices, supporting hw h264 encoding probably depends on SKU.
We actually know lumpy supports hw h264 encoding if its CPU type is intel i3.
Therefore, it would depend on SKU in the case of stumpy as well.
However, I checked stumpy on lab. All the stumpy support hw h264 encoding.
So I deicded to regard stumpy always supports hw h264 encoding.
Please see the following changes for them.
https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/805636/10..11https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/821391/5..6
I classified boards in crosreview.com/821391 by baseboard.
[auron]
buddy (samus, auron_yuna, gandof, etc.)
[jecht]
guado, rikku (tidus)
[beltino]
panther, tricky, zako (monroe, mccloud)
[slippy]
peppy, wolf (falco, leon, falco-li)
[?]
stumpy, variant-parrot-ivb, lumpy
The devices in () are ones whose baseboard is the same but don't have the capabilities.
If I put autotest-capability file in baseboard directory, the capabilities will be installed to all the same baseboard devices.
Thus, I can do so only for the case of baseboard-jecht.
It is worth noting that the status of HW H264 encoding in lab on Haswell, IvyBridge and SandyBridge devices on lab.
SandyBridge
[butterfly] x
[lumpy] i5:o, celeron:x
[parrot] x
[stumpy] o
IvyBridge
[link] o
[parrot-ivb] x
[stout] celeron 877: o, celeron 1007U: x
Haswell
[falco] x
[leon] x
[mccloud] o
[monroe] x
[panther] i3, i7: o, celeron: x
[peppy] i3: o, celeron: x
[tricky] i3, i7: o, celeron: x
[wolf] i3, i5: o, celeron: x
[zako] i7: o, celeron: x
Thanks to the above CLs, video_VideoCapability test runs by autotest scheduler.
The right test results will be shown from 10411.0.0, on which the fixing path CL (comment 28) will be landed.
I uploaded CLs; this autotest-capability is actually applied to our autotests.
I plan the first tests are video_VDAPerf an video_VEAPerf.
The CLs are crosreview.com/923609 and crosreview.com/923610
I plan to merge the CLs after I sufficiently verify autotest capability configuration settings by video_VideoCapability.
I summarize the current failure reason.
[bob, kevin]
HW jpeg decoding is not available by avtest_label_detect
[veyron_mickey]
webcam is not detected by avtest_label_detect
[beltino devices except monroe (mccloud, panther, tricky, zako)]
webcam is not detected by avtest_label_detect
[Skylake? (carolline, cave, chell, asuka, sentry)]
hw_enc_jpeg is detected by avtest_label_detect
[guado, rikku]
webcam is not detected by avtest_label_detect
(because I didn't set their parent to jecht.)
[ninja]
webcam is not detected by avtest_label_detect
[Apollolake? (pyro, sand, snappy)]
hw_enc_jpeg is detected by avtest_label_detect
[Braswell? (strago devices)]
hw_enc_jpeg is detected by avtest_label_detect
video_VideoCapability on veyron_jaq failed because of webcam capability mismatch.
avtest_label_detect doesn't detect 'webcam' on chromeos2-row6-rack8-host11.
The HWID and spec is https://www.google.com/chromeos/partner/fe/#hwid:q=JAQ%20D25-Q6R-C4A-A6A-A6K.
All the other veyron_jaq on lab has 'webcam' label.
Even the device whose hw id is the same has 'webcam'. (e.g. chromeos2-row6-rack8-host8)
Is something wrong in avtest_label_detect, driver or the device?
I still need to investigate and perhaps correct webcam availability on some devices, from video_VideoCapability results.
However, it seems the capability for HW video decoding/encoding are correct on devices.
I plan to apply autotest-capability to video_VDAPerf and video_VEAPerf this week, maybe from Thursday.
I plan the order of autotests to apply autotest-capability.
I list up all the autotests which run with dynamically detected label currently.
https://docs.google.com/spreadsheets/d/1E8SMBhLyEmnOmYzROX7A98CzDrCW_ao335cp820xiqY
I am going to apply in the following order.
video_VDAPerf (done)
video_VEAPerf
video_PlaybackPerf
video_MediaRecorderPerf
video_VideoSeek
video_HangoutHardwarePerf
video_ChromeVidResChangeHWDecode
video_VDASanity
video_MediaRecorderHWEncodeUsed
video_VideoDecodeAccelerator
video_VideoEncodeAccelerator
----Video Decoding/Encoding Test Migration Done----
video_JDAPerf
video_JEAPerf
video_JpegDecodeAccelerator
video_JpegEncodeAccelerator
----Jpeg Decoding/Encoding Test Migration Done----
video_WebRtcPeerConnectionWithCamera
video_WebRtcCamera
power_CameraSuspend
camera_V4L2
----Camera Test Migration Done----
video_ChromeHWDecodeUsed
video_ChromeRTCHWDecodeUsed
video_ChromeRTCHWEncodeUsed
cheets_MediaPlayerVideoHWDecodeUsed
cheets_CameraOrientation
----CQ Test Migration Done----
So far, I applied autotest-capability to
video_VDAPerf
video_VEAPerf
video_MediaRecorderPerf
video_VideoSeek
video_HangoutHardwarePerf
video_ChromeVidResChangeHWDecode
video_VDASanity
video_MediaRecorderHWEncodeUsed
video_VideoDecodeAccelerator
video_VideoEncodeAccelerator
All of them are running properly suite correct times.
This week, I am going to apply to all the tests in autotest.
Next, I will start applying tests in autotest-test-cheets.
* cheets_MediaPlayerVideoHWDecodeUsed
* cheets_MediaPlayerVideoHWDecodeUsed_P
* cheets_CameraOrientation
* cheets_CameraOrientation_P
* cheets_CameraSuspendResume
At beta channel, I don't apply autotest-capability to video_ChromeRTCHWEncodeUsed.
We enable HW VP8 encoding at dev channel.
Therefore, video_ChromeRTCHWEncodeUsed fails in the following step.
(1) at dev branch, avtest_label_detect hw_enc_vp8_acc
(2) at beta branch, the test looks the label, hw_enc_vp8_acc, on DUT and judge that the test can run on the device.
(3) the test is provided and runs.
(4) However, in the beta branch image, HW vp8 encoding is disabled and the test fails as a result.
We should fix this issue in some way.
The simplest way is to apply autotest-capability to beta branch.
As a result, even if the test is provided, it checks static-capability in beta image. There is no HW VP8 encoding capability in the list of beta image, and the test is skipped (not failed).
I created cherry-pick CL.
https://chromium-review.googlesource.com/c/chromiumos/third_party/autotest/+/1094934
This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
video_VDAStress doesn't run on lab.
So video_PowerConsumption is the last test to run on lab using a dynamic label.
There is no remained task about autotest capability framework.
Some work is required to run video_VDAStress. It is separated from this work and then I created crbug.com/855970 for the task.
Comment 1 by hiroh@chromium.org
, Dec 5 2017