| /OK3568_Linux_fs/kernel/Documentation/admin-guide/pm/ |
| H A D | cpuidle.rst | 19 Modern processors are generally able to enter states in which the execution of 21 memory or executed. Those states are the *idle* states of the processor. 23 Since part of the processor hardware is not used in idle states, entering them 24 generally allows power drawn by the processor to be reduced and, in consequence, 28 the idle states of processors for this purpose. 33 CPU idle time management operates on CPUs as seen by the *CPU scheduler* (that 34 is the part of the kernel responsible for the distribution of computational 35 work in the system). In its view, CPUs are *logical* units. That is, they need 42 First, if the whole processor can only follow one sequence of instructions (one 43 program) at a time, it is a CPU. In that case, if the hardware is asked to [all …]
|
| H A D | cpufreq.rst | 15 The Concept of CPU Performance Scaling 18 The majority of modern processors are capable of operating in a number of 21 the higher the clock frequency and the higher the voltage, the more instructions 22 can be retired by the CPU over a unit of time, but also the higher the clock 23 frequency and the higher the voltage, the more energy is consumed over a unit of 24 time (or the more power is drawn) by the CPU in the given P-state. Therefore 25 there is a natural tradeoff between the CPU capacity (the number of instructions 26 that can be executed over a unit of time) and the power drawn by the CPU. 28 In some situations it is desirable or even necessary to run the program as fast 29 as possible and then there is no reason to use any P-states different from the [all …]
|
| /OK3568_Linux_fs/kernel/include/linux/ |
| H A D | nvme-fc-driver.h | 23 * struct nvmefc_ls_req - Request structure passed from the transport 24 * to the LLDD to perform a NVME-FC LS request and obtain 29 * Used by the nvmet-fc transport (controller) to send 32 * Values set by the requestor prior to calling the LLDD ls_req entrypoint: 39 * @timeout: Maximum amount of time, in seconds, to wait for the LS response. 42 * @private: pointer to memory allocated alongside the ls request structure 43 * that is specifically for the LLDD to use while processing the 44 * request. The length of the buffer corresponds to the 45 * lsrqst_priv_sz value specified in the xxx_template supplied 46 * by the LLDD. [all …]
|
| H A D | lsm_hooks.h | 14 * it under the terms of the GNU General Public License as published by 15 * the Free Software Foundation; either version 2 of the License, or 18 * Due to this file being licensed under the GPL there is controversy over 20 * without placing your module under the GPL. Please consult a lawyer for 38 * If the setup in prepare_exec_creds did not setup @bprm->cred->security 39 * properly for executing @bprm->file, update the LSM's portion of 40 * @bprm->cred->security to be what commit_creds needs to install for the 43 * The hook must set @bprm->secureexec to 1 if AT_SECURE should be set to 45 * @bprm contains the linux_binprm structure. 46 * Return 0 if the hook is successful and permission is granted. [all …]
|
| /OK3568_Linux_fs/kernel/Documentation/scsi/ |
| H A D | st.rst | 4 The SCSI Tape Driver 7 This file contains brief information about the SCSI tape driver. 8 The driver is currently maintained by Kai Mäkisara (email 17 The driver is generic, i.e., it does not contain any code tailored 18 to any specific tape drive. The tape parameters can be specified with 19 one of the following three methods: 21 1. Each user can specify the tape parameters he/she wants to use 24 in a multiuser environment the next user finds the tape parameters in 25 state the previous user left them. 27 2. The system manager (root) can define default values for some tape [all …]
|
| /OK3568_Linux_fs/yocto/poky/documentation/sdk-manual/ |
| H A D | extensible.rst | 4 Using the Extensible SDK 7 This chapter describes the extensible SDK and how to install it. 8 Information covers the pieces of the SDK, how to install it, and 9 presents a look at using the ``devtool`` functionality. The extensible 11 modify the source for an existing component, test changes on the target 12 hardware, and ease integration into the rest of the 18 extensible SDK as compared to a standard SDK, see the 21 In addition to the functionality available through ``devtool``, you can 22 alternatively make use of the toolchain directly, for example from 23 Makefile and Autotools. See the [all …]
|
| /OK3568_Linux_fs/yocto/poky/meta/files/common-licenses/ |
| H A D | EUPL-1.2 | 2 EUPL © the European Union 2007, 2016 4 This European Union Public Licence (the ‘EUPL’) applies to the Work (as defined below) which is pro… 5 terms of this Licence. Any use of the Work, other than as authorised under this Licence is prohibit… 6 use is covered by a right of the copyright holder of the Work). 7 The Work is provided under the terms of this Licence when the Licensor (as defined below) has place… 8 notice immediately following the copyright notice for the Work: 9 Licensed under the EUPL 10 or has expressed by any other means his willingness to license under the EUPL. 13 In this Licence, the following terms have the following meaning: 14 — ‘The Licence’:this Licence. [all …]
|
| H A D | CECILL-1.1 | 5 …s a free software license that is the result of discussions between its authors in order to ensure… 6 …ench law, both as regards the law of torts and intellectual property law, and the protection that … 7 …- secondly, compliance with the principles for the distribution of free software: access to source… 9 The following bodies are the authors of this license CeCILL (Ce : CEA, C : CNRS, I : INRIA, LL : Lo… 19 The purpose of this Free Software Licensing Agreement is to grant users the right to modify and red… 21 The exercising of these rights is conditional upon certain obligations for users so as to ensure th… 23 …the access to the source code and rights to copy, modify and redistribute granted by the license, … 25 …the user's attention that the risks associated with loading, using, modifying and/or developing or… 27 …ement may apply to any or all software for which the holder of the economic rights decides to subm… 31 For the purposes of this Agreement, when the following expressions commence with a capital letter, … [all …]
|
| H A D | EUPL-1.1 | 4 EUPL © the European Community 2007 5 This European Union Public Licence (the “EUPL”) applies to the Work or Software 6 (as defined below) which is provided under the terms of this Licence. Any use of the 7 Work, other than as authorised under this Licence is prohibited (to the extent such use 8 is covered by a right of the copyright holder of the Work). 9 The Original Work is provided under the terms of this Licence when the Licensor (as 10 defined below) has placed the following notice immediately following the copyright 11 notice for the Original Work: 12 Licensed under the EUPL V.1.1 13 or has expressed by any other mean his willingness to license under the EUPL. [all …]
|
| H A D | CECILL-2.1 | 9 This Agreement is a Free Software license agreement that is the result 11 the two main principles guiding its drafting: 13 * firstly, compliance with the principles governing the distribution 15 * secondly, the election of a governing law, French law, with which it 16 is conformant, both as regards the law of torts and intellectual 17 property law, and the protection that it offers to both authors and 18 holders of the economic rights over software. 20 The authors of the CeCILL (for Ce[a] C[nrs] I[nria] L[ogiciel] L[ibre]) 40 The purpose of this Free Software license agreement is to grant users 41 the right to modify and redistribute the software governed by this [all …]
|
| H A D | EUPL-1.0 | 4 EUPL © the European Community 2007 5 This European Union Public Licence (the “EUPL”) applies to the Work or Software (as 6 defined below) which is provided under the terms of this Licence. Any use of the Work, other 7 than as authorised under this Licence is prohibited (to the extent such use is covered by a right 8 of the copyright holder of the Work). 9 The Original Work is provided under the terms of this Licence when the Licensor (as defined 10 below) has placed the following notice immediately following the copyright notice for the 12 Licensed under the EUPL V.1.0 13 or has expressed by any other mean his willingness to license under the EUPL. 15 In this Licence, the following terms have the following meaning: [all …]
|
| H A D | CC-BY-NC-SA-3.0-IGO | 3 …THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM ITS USE. THE LICENSOR… 7 THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE (“L… 11 …s and that accordingly enjoy immunity from legal process are also IGOs for the sole and exclusive … 13 …the literary and/or artistic work eligible for copyright protection, whatever may be the mode or f… 15 …c. "Licensor" means the individual, individuals, entity or entities that offer(s) the Work under t… 19 …e. "License Elements" means the following high-level license attributes as selected by the Licenso… 21 f. "Reproduce" means to make a copy of the Work in any manner or form, and by any means. 23 …the activity of making publicly available the Work or Adaptation (or copies of the Work or Adaptat… 25 …the Work and to communicate to the public those public recitations, by any means or process, inclu… 27 …the Work, or upon the Work and other pre-existing works. Adaptations may include works such as tra… [all …]
|
| /OK3568_Linux_fs/kernel/Documentation/crypto/ |
| H A D | userspace-if.rst | 7 The concepts of the kernel crypto API visible to kernel space is fully 8 applicable to the user space interface as well. Therefore, the kernel 9 crypto API high level discussion for the in-kernel use cases applies 12 The major difference, however, is that user space can only act as a 16 The following covers the user space interface exported by the kernel 19 applications that require cryptographic services from the kernel. 21 Some details of the in-kernel kernel crypto API aspects do not apply to 22 user space, however. This includes the difference between synchronous 23 and asynchronous invocations. The user space API call is fully 31 The kernel crypto API is accessible from user space. Currently, the [all …]
|
| /OK3568_Linux_fs/yocto/poky/documentation/ref-manual/ |
| H A D | variables.rst | 7 This chapter lists common variables used in the OpenEmbedded build 23 Extension to the Application Binary Interface (ABI) field of the GNU 26 ABI extensions are set in the machine include files. For example, the 27 ``meta/conf/machine/include/arm/arch-arm.inc`` file sets the 37 requirement on the existence of the package. 48 scheme. Sometimes the same command is provided in multiple packages. 49 When this occurs, the OpenEmbedded build system needs to use the 50 alternatives system to create a different binary naming scheme so the 53 To use the variable, list out the package's commands that are also 54 provided by another package. For example, if the ``busybox`` package [all …]
|
| /OK3568_Linux_fs/yocto/poky/meta/conf/ |
| H A D | documentation.conf | 10 do_checkuri[doc] = "Validates the SRC_URI value" 14 do_compile[doc] = "Compiles the source in the compilation directory" 15 do_compile_kernelmodules[doc] = "Compiles loadable modules for the Linux kernel" 16 do_compile_ptest_base[doc] = "Compiles the runtime test suite included in the software being built" 17 do_configure[doc] = "Configures the source by enabling and disabling any build-time and configurati… 18 do_configure_ptest_base[doc] = "Configures the runtime test suite included in the software being bu… 19 do_deploy[doc] = "Writes deployable output files to the deploy directory" 21 do_devshell[doc] = "Starts a shell with the environment set up for development/debugging" 22 do_diffconfig[doc] = "Compares the old and new config files after running do_menuconfig for the ker… 23 do_fetch[doc] = "Fetches the source code" [all …]
|
| /OK3568_Linux_fs/kernel/Documentation/input/ |
| H A D | multi-touch-protocol.rst | 13 In order to utilize the full power of the new multi-touch and multi-user 15 objects in direct contact with the device surface, is needed. This 16 document describes the multi-touch (MT) protocol which allows kernel 19 The protocol is divided into two types, depending on the capabilities of the 20 hardware. For devices handling anonymous contacts (type A), the protocol 21 describes how to send the raw data for all contacts to the receiver. For 22 devices capable of tracking identifiable contacts (type B), the protocol 33 events. Only the ABS_MT events are recognized as part of a contact 35 applications, the MT protocol can be implemented on top of the ST protocol 39 input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT [all …]
|
| /OK3568_Linux_fs/yocto/poky/documentation/overview-manual/ |
| H A D | concepts.rst | 8 beyond the surface of "how-to" information and reference (or look-up) 9 material. Concepts such as components, the :term:`OpenEmbedded Build System` 17 The :term:`BitBake` task executor 18 together with various types of configuration files form the 23 BitBake handles the parsing and execution of the data files. The data 32 decisions, and so forth. Configuration data acts as the glue to bind 36 to each data source as a layer. For information on layers, see the 38 section of the Yocto Project Development Tasks Manual. 42 see the 49 BitBake is the tool at the heart of the :term:`OpenEmbedded Build System` [all …]
|
| /OK3568_Linux_fs/kernel/Documentation/power/ |
| H A D | pci.rst | 7 An overview of concepts and the Linux kernel's interfaces related to PCI power 11 This document only covers the aspects of power management specific to PCI 12 devices. For general description of the kernel's interfaces related to device 31 devices into states in which they draw less power (low-power states) at the 35 completely inactive. However, when it is necessary to use the device once 36 again, it has to be put back into the "fully functional" state (full-power 37 state). This may happen when there are some data for the device to handle or 38 as a result of an external event requiring the device to be active, which may 39 be signaled by the device itself. 41 PCI devices may be put into low-power states in two ways, by using the device [all …]
|
| /OK3568_Linux_fs/external/mpp/tools/ |
| H A D | mpp_doxyfile | 3 # This file describes the settings to be used by the documentation system 7 # front of the TAG it is preceding. 10 # The format is: 20 # This tag specifies the encoding used for all characters in the config file 21 # that follow. The default is UTF-8 which is also the encoding used for all text 22 # before the first occurrence of this tag. Doxygen uses libiconv (or the iconv 23 # built into libc) for the transcoding. See http://www.gnu.org/software/libiconv 24 # for the list of possible encodings. 25 # The default value is: UTF-8. 29 # The PROJECT_NAME tag is a single word (or a sequence of words surrounded by [all …]
|
| /OK3568_Linux_fs/kernel/Documentation/filesystems/ |
| H A D | xfs-delayed-logging-design.rst | 11 such as inodes and dquots, are logged in logical format where the details 12 logged are made up of the changes to in-core structures rather than on-disk 14 logged. The reason for these differences is to reduce the amount of log space 17 than any other object (except maybe the superblock buffer) so keeping the 20 The reason that this is such a concern is that XFS allows multiple separate 21 modifications to a single object to be carried in the log at any given time. 22 This allows the log to avoid needing to flush each change to disk before 23 recording a new change to the object. XFS does this via a method called 25 new change to the object is recorded with a *new copy* of all the existing 26 changes in the new transaction that is written to the log. [all …]
|
| /OK3568_Linux_fs/external/chromium/licenses/ |
| H A D | LICENSE.67 | 6 a copy of this software and associated documentation files (the 7 "Software"), to deal in the Software without restriction, including 8 without limitation the rights to use, copy, modify, merge, publish, 9 distribute, sublicense, and/or sell copies of the Software, and to 10 permit persons to whom the Software is furnished to do so, subject to 11 the following conditions: 13 The above copyright notice and this permission notice shall be 14 included in all copies or substantial portions of the Software. 16 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 17 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF [all …]
|
| /OK3568_Linux_fs/external/xserver/hw/xfree86/man/ |
| H A D | xorg.conf.man | 10 run-time parameters: command line options, environment variables, the 12 and fallback defaults. When the same information is supplied in more 13 than one way, the highest precedence mechanism is used. The list of 15 all parameters can be supplied via all methods. The available command 17 described in the Xserver(@appmansuffix@) and 20 specific configuration parameters are described in the relevant driver 26 and files ending in the suffix 28 from the directory 33 configuration file is searched for in the following places when the 53 is a relative path (with no \(lq..\(rq components) specified with the [all …]
|
| /OK3568_Linux_fs/external/xserver/hw/dmx/doxygen/ |
| H A D | doxygen.conf.in | 3 # This file describes the settings to be used by the documentation system 7 # front of the TAG it is preceding. 10 # The format is: 20 # This tag specifies the encoding used for all characters in the config file 21 # that follow. The default is UTF-8 which is also the encoding used for all text 22 # before the first occurrence of this tag. Doxygen uses libiconv (or the iconv 23 # built into libc) for the transcoding. See http://www.gnu.org/software/libiconv 24 # for the list of possible encodings. 25 # The default value is: UTF-8. 29 # The PROJECT_NAME tag is a single word (or a sequence of words surrounded by [all …]
|
| /OK3568_Linux_fs/kernel/Documentation/locking/ |
| H A D | rt-mutex-design.rst | 7 Licensed under the GNU Free Documentation License, Version 1.2 10 This document tries to describe the design of the rtmutex.c implementation. 11 It doesn't describe the reasons why rtmutex.c exists. For that please see 13 that happen without this code, but that is in the concept to understand 14 what the code actually is doing. 16 The goal of this document is to help others understand the priority 17 inheritance (PI) algorithm that is used, as well as reasons for the 18 decisions that were made to implement PI in the manner that was done. 26 most of the time it can't be helped. Anytime a high priority process wants 28 the high priority process must wait until the lower priority process is done [all …]
|
| /OK3568_Linux_fs/kernel/Documentation/vm/ |
| H A D | hugetlbfs_reserv.rst | 12 task's address space at page fault time if the VMA indicates huge pages are 13 to be used. If no huge page exists at page fault time, the task is sent 16 of huge pages at mmap() time. The idea is that if there were not enough 17 huge pages to cover the mapping, the mmap() would fail. This was first 18 done with a simple check in the code at mmap() time to determine if there 19 were enough free huge pages to cover the mapping. Like most things in the 20 kernel, the code has evolved over time. However, the basic idea was to 22 available for page faults in that mapping. The description below attempts to 23 describe how huge page reserve processing is done in the v4.10 kernel. 32 The Data Structures [all …]
|