kernelci / kernelci-pipeline

Modular pipeline based on the KernelCI API
GNU Lesser General Public License v2.1
6 stars 19 forks source link

Enable 'discoverable devices probe' kselftest on MediaTek Chromebooks #579

Open nfraprado opened 5 months ago

nfraprado commented 5 months ago

This task is to track progress on enabling the discoverable devices probe kselftest on all MediaTek Chromebooks.

nfraprado commented 4 months ago

I've put together the test definitions for the platforms:

google,tomato.yaml:

# SPDX-License-Identifier: GPL-2.0
- type: usb-controller
  dt-mmio: 112a0000
  usb-version: 2
  devices:
    - path: 1
      interfaces: [0, 1]
      name: camera
- type: usb-controller
  dt-mmio: 112b0000
  usb-version: 2
  devices:
    - path: 1
      interfaces: [0, 1]
      name: bluetooth
- type: pci-controller
  dt-mmio: 112f8000
  devices:
    - path: 0.0/0.0
      name: wifi

(LAVA run: https://lava.collabora.dev/scheduler/job/13713188)

google,juniper.yaml:

# SPDX-License-Identifier: GPL-2.0
- type: usb-controller
  dt-mmio: 11200000
  usb-version: 2
  devices:
    - path: 1.3
      interfaces: [0, 1]
      name: camera

(LAVA run: https://lava.collabora.dev/scheduler/job/13713523)

Note: On Juniper and Steelix the WIFI and Bluetooth are wired through SDIO (MMC controller), so they're tested by the DT kselftest.

google,steelix.yaml:

# SPDX-License-Identifier: GPL-2.0
- type: usb-controller
  dt-mmio: 11200000
  usb-version: 2
  devices:
    - path: 1
      interfaces: [0, 1]
      name: camera1
- type: usb-controller
  dt-mmio: 11280000
  usb-version: 2
  devices:
    - path: 1.3
      interfaces: [0, 1]
      name: camera2

(LAVA run: https://lava.collabora.dev/scheduler/job/13713399)

Note: To confirm, are there really two cameras or why are there two different devices binding to uvcvideo? And should the usbhid device be tested too? (the vendor is realtek)

google,spherion.yaml is provided upstream as an example.

Now what remains is to create a repository to host these files and make the test fetch them.

nfraprado commented 4 months ago

A repository has been created to host the files at https://github.com/kernelci/platform-test-parameters. As for how to overlay the files and access them from the kselftest, there are a few options:

  1. Change kselftest lava runner to overlay platform-test-parameters before running
    • Seems unlikely to be accepted in lava upstream
  2. Overlay platform-test-parameters when generating kselftest tarball
    • tarball is generated from a make target upstream: make kselftest-gen_tar, so it's not possible add files in a clean way
  3. Overlay platform-test-parameters to some directory before running the test and pass that directory as parameter to test

    • need to add support in test for such flag
    • need to have support in kernelci to pass arguments to kselftest
    • two options: 3.1 when generating rootfs

      • pro: allows same job template to be used for this and other kselftests
      • pro: more efficient - don't need to download and extract over and over

      3.2 when running the test, as a previous action in lava

Option 3.1 seems to be the best, so I'm going for that.

nfraprado commented 3 months ago

There's now a PR to allow passing parameters to kselftests: https://github.com/Linaro/test-definitions/pull/511

I have implemented locally support for a boards-dir parameter on the test, and to deploy platform-test-parameters to the kselftest rootfs. Next I'll see if I can already make use of that PR locally and if so I can test everything together (and it will serve as a review for the PR too).