/openbmc/linux/arch/microblaze/kernel/cpu/ |
H A D | cpuinfo-pvr-full.c | 23 #define CI(c, p) { ci->c = PVR_##p(pvr); } macro 34 CI(ver_code, VERSION); in set_cpuinfo_pvr_full() 65 CI(pvr_user1, USER1); in set_cpuinfo_pvr_full() 66 CI(pvr_user2, USER2); in set_cpuinfo_pvr_full() 68 CI(mmu, USE_MMU); in set_cpuinfo_pvr_full() 69 CI(mmu_privins, MMU_PRIVINS); in set_cpuinfo_pvr_full() 70 CI(endian, ENDIAN); in set_cpuinfo_pvr_full() 72 CI(use_icache, USE_ICACHE); in set_cpuinfo_pvr_full() 73 CI(icache_tagbits, ICACHE_ADDR_TAG_BITS); in set_cpuinfo_pvr_full() 74 CI(icache_write, ICACHE_ALLOW_WR); in set_cpuinfo_pvr_full() [all …]
|
/openbmc/qemu/.gitlab-ci.d/cirrus/ |
H A D | README.rst | 1 Cirrus CI integration 4 GitLab CI shared runners only provide a docker environment running on Linux. 8 To work around this limitation, we take advantage of `Cirrus CI`_'s free 10 CI jobs from GitLab CI jobs so that Cirrus CI job output is integrated into 11 the main GitLab CI pipeline dashboard. 20 * enable the `Cirrus CI GitHub app`_ for your GitHub account; 22 * sign up for Cirrus CI. It's enough to log into the website using your GitHub 25 * grab an API token from the `Cirrus CI settings`_ page; 28 for Cirrus CI to properly recognize the project. You can check whether 29 Cirrus CI knows about your project by navigating to: [all …]
|
/openbmc/linux/Documentation/userspace-api/media/dvb/ |
H A D | ca_high_level.rst | 3 The High level CI API 10 This document describes the high level CI API as in accordance to the 14 With the High Level CI approach any new card with almost any random 21 array to/from the CI ioctls as defined in the Linux DVB API. No changes 25 Why the need for another CI interface? 31 The CI interface is defined in the DVB API in ca.h as: 39 #define CA_CI 1 /* CI high level interface */ 40 #define CA_CI_LINK 2 /* CI link layer level interface */ 41 #define CA_CI_PHYS 4 /* CI physical layer level interface */ 50 This CI interface follows the CI high level interface, which is not [all …]
|
/openbmc/openbmc-build-scripts/jenkins/ |
H A D | README.md | 8 | CI-MISC/ci-build-seed | jenkins/build-seed | | 9 | CI-MISC/ci-meta | jenkins/run-meta-ci | Deprecated | 10 | CI-MISC/ci-openbmc-build-scripts | jenkins/run-build-script-ci | | 11 | CI-MISC/ci-repository-ppc64le | run-unit-test-docker.sh | | 12 | CI-MISC/openbmc-node-cleaner | sstate-cache-management.sh | [1] | 13 | CI-MISC/openbmc-userid-validation | jenkins/userid-validation | | 14 | CI-MISC/run-ci-in-qemu | run-qemu-robot-test.sh | |
|
/openbmc/qemu/docs/devel/testing/ |
H A D | ci-jobs.rst.inc | 3 Custom CI/CD variables 6 QEMU CI pipelines can be tuned by setting some CI environment variables. 8 Set variable globally in the user's CI namespace 11 Variables can be set globally in the user's CI namespace setting. 37 CI configurations. For example define an alias for triggering CI: 62 The variables used by QEMU's CI configuration are grouped together 70 repository CI settings, or as git push variables, to influence 92 CI configuration file. 97 The job makes use of Cirrus CI infrastructure, requiring the 104 by default due to need to conserve limited CI resources. It is [all …]
|
H A D | ci.rst | 4 CI title 7 Most of QEMU's CI is run on GitLab's infrastructure although a number 8 of other CI services are used for specialised purposes. The most up to 10 `project wiki testing page <https://wiki.qemu.org/Testing/CI>`_.
|
H A D | ci-runners.rst.inc | 4 Besides the jobs run under the various CI systems listed before, there 6 These use the same GitLab CI's service/framework already used for all 7 other GitLab based CI jobs, but rely on additional systems, not the 10 The architecture of GitLab's CI service allows different machines to 16 The GitLab CI jobs definition for the custom runners are located under:: 21 currently deployed in the QEMU GitLab CI and their maintainers, please 73 * CI/CD, then 92 * CI/CD, then
|
H A D | index.rst | 4 Details about how to test QEMU and how it is integrated into our CI
|
/openbmc/linux/Documentation/admin-guide/media/ |
H A D | ci.rst | 11 This document describes the usage of the high level CI API as 13 existing low level CI API. 17 For the Twinhan/Twinhan clones, the dst_ca module handles the CI 18 hardware handling. This module is loaded automatically if a CI 65 CI modules that are supported 68 The CI module support is largely dependent upon the firmware on the cards 69 Some cards do support almost all of the available CI modules. There is 70 nothing much that can be done in order to make additional CI modules
|
H A D | dvb-usb-dvbsky-cardlist.rst | 31 * - TechnoTrend TT-connect CT2-4650 CI 33 * - TechnoTrend TT-connect CT2-4650 CI v1.1 35 * - TechnoTrend TT-connect S2-4650 CI
|
H A D | cx23885-cardlist.rst | 86 - NetUP Dual DVB-S2 CI 138 - NetUP Dual DVB-T/C-CI RF 210 - Technotrend TT-budget CT2-4500 CI
|
/openbmc/openbmc/meta-arm/documentation/ |
H A D | continuous-integration-and-kas.md | 1 # **CI for Yocto Project and meta-arm** 2 # **CI for Yocto Project** 8 # **CI for meta-arm** 9 meta-arm is using the Gitlab CI infrastructure. This is currently being done internal to Arm, but … 11 This CI is constantly being expanded to provide increased coverage of the software and hardware sup… 13 …ould be wise to run kas locally to verify everything works prior to pushing to the CI build system. 38 ## **Locked Revisions in CI with lockfiles** 39 …CI in meta-arm will generate a kas "lock file" when it starts to ensure that all of the builds che… 41 This lock file is saved as an artefact of the update-repos job by the CI, and only generated if it … 56 Commit this lockfile.yml to the top-level of the meta-arm repository and the CI will use it automat… [all …]
|
/openbmc/docs/testing/ |
H A D | local-ci-build.md | 1 # Local CI Build 3 These instructions pertain to running the upstream OpenBMC CI locally. 15 Each repository is built locally within the CI using the bootstrap.sh and 18 ## Download the CI Image 20 Start by making a place for your CI repositories to live, and clone the CI 33 clones and builds phosphor-hwmon directly. The upstream CI will try building 56 ## Run CI on local changed Repo 59 possible to run local CI as well by setting `NO_FORMAT_CODE=1` before running 72 ## Run CI for testing purposes only
|
/openbmc/docs/designs/ |
H A D | ci-authorization.md | 11 The OpenBMC project maintains a number of Jenkins CI jobs to ensure incoming 19 The project already has contributor authorization for CI. This proposal serves 27 team (or a general-developers sub-team), the automated CI processes are 30 project maintainer to trigger the automated CI processes. 46 An alternative authorization method for CI should: 49 authorized for CI. 86 Finally, any Jenkins CI jobs must be updated to test for membership of the
|
/openbmc/bmcweb/ |
H A D | CLIENTS.md | 22 Status: 100% passing. Integrated with CI to ensure no regressions. 28 Status: 100% of assertions passing. No CI integration. 33 Status: Passing for some machines with CI integration. 62 Status: Compatible. No CI integration.
|
/openbmc/linux/drivers/media/pci/cx23885/ |
H A D | Kconfig | 55 tristate "Altera FPGA based CI module" 59 An Altera FPGA CI module for NetUP Dual DVB-T/C RF CI card.
|
/openbmc/qemu/scripts/ci/ |
H A D | gitlab-ci-section | 7 # section" in a CI job log. See 11 # a CI config; the section_start and section_end functions will
|
/openbmc/webui-vue/docs/guide/coding-standards/ |
H A D | readme.md | 34 CI tool runs after a push to Gerrit. There is a shell script named 36 script in your CI.
|
/openbmc/phosphor-power/phosphor-power-sequencer/docs/ |
H A D | testing.md | 7 run during Continuous Integration (CI) testing. 36 CI test environment. Thus, in automated test cases they need to be mocked.
|
/openbmc/linux/kernel/configs/ |
H A D | debug.config | 1 # Help: Debugging for CI systems and finding regressions 3 # The config is based on running daily CI for enterprise Linux distros to
|
/openbmc/openbmc-build-scripts/ |
H A D | README.md | 3 Build script for CI jobs in Jenkins.
|
/openbmc/qemu/tests/docker/dockerfiles/ |
H A D | debian-hexagon-cross.docker | 5 # needs to be able to build QEMU itself in CI we include its 29 # Install QEMU build deps for use in CI
|
/openbmc/linux/Documentation/gpu/ |
H A D | automated_testing.rst | 32 This is the root configuration file for GitLab CI. Among other less interesting 37 Repository that contains the Mesa software infrastructure for CI 86 CI/CD configuration file from .gitlab-ci.yml to 89 3. Next time you push to this repository, you will see a CI pipeline being
|
/openbmc/qemu/target/ppc/translate/ |
H A D | misc-impl.c.inc | 103 * - loads from CI memory. 104 * - stores to CI memory. 119 * The end result is that CI memory ordering requires TCG_MO_ALL
|
/openbmc/linux/tools/testing/selftests/bpf/ |
H A D | README.rst | 10 BPF CI System 13 BPF employs a continuous integration (CI) system to check patch submission in an 21 The CI system executes tests on multiple architectures. It uses a kernel 30 In such a case tests in CI may fail. An example of such a shortcoming is BPF 54 would be run post-submit in the CI used by the Maintainers, with the exception 58 image from the system used by the CI. It builds the kernel (without overwriting
|