slimbootloader/Silicon/ElkhartlakePkg/Include/Register/PchRegsHda.h

36 lines
1.6 KiB
C
Raw Permalink Normal View History

Use LF line endings in the repository Convert the line endings stored for all text files in the repository to LF. The majority previously used DOS-style CRLF line endings. Add a .gitattributes file to enforce this and treat certain extensions as never being text files. Update PatchCheck.py to insist on LF line endings rather than CRLF. However, its other checks fail on this commit due to lots of pre-existing complaints that it only notices because the line endings have changed. Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch needs to be treated as binary since it contains a mixture of line endings. This change has implications depending on the client platform you are using the repository from: * Windows The usual configuration for Git on Windows means that text files will be checked out to the work tree with DOS-style CRLF line endings. If that's not the case then you can configure Git to do so for the entire machine with: git config --global core.autocrlf true or for just the repository with: git config core.autocrlf true Line endings will be normalised to LF when they are committed to the repository. If you commit a text file with only LF line endings then it will be converted to CRLF line endings in your work tree. * Linux, MacOS and other Unices The usual configuration for Git on such platforms is to check files out of the repository with LF line endings. This is probably the right thing for you. In the unlikely even that you are using Git on Unix but editing or compiling on Windows for some reason then you may need to tweak your configuration to force the use of CRLF line endings as described above. * General For more information see https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings . Fixes: https://github.com/slimbootloader/slimbootloader/issues/1400 Signed-off-by: Mike Crowe <mac@mcrowe.com>
2021-11-10 19:36:23 +08:00
/** @file
Register names for PCH High Definition Audio device.
Conventions:
- Prefixes:
Definitions beginning with "R_" are registers
Definitions beginning with "B_" are bits within registers
Definitions beginning with "V_" are meaningful values within the bits
Definitions beginning with "S_" are register sizes
Definitions beginning with "N_" are the bit position
- In general, PCH registers are denoted by "_PCH_" in register names
- Registers / bits that are different between PCH generations are denoted by
"_PCH_[generation_name]_" in register/bit names.
- Registers / bits that are specific to PCH-H denoted by "_H_" in register/bit names.
Registers / bits that are specific to PCH-LP denoted by "_LP_" in register/bit names.
e.g., "_PCH_H_", "_PCH_LP_"
Registers / bits names without _H_ or _LP_ apply for both H and LP.
- Registers / bits that are different between SKUs are denoted by "_[SKU_name]"
at the end of the register/bit names
- Registers / bits of new devices introduced in a PCH generation will be just named
as "_PCH_" without [generation_name] inserted.
Copyright (c) 1999 - 2016, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
#ifndef _PCH_REGS_HDA_H_
#define _PCH_REGS_HDA_H_
#define R_PCH_HDABA_MLC 0x0C00 // Multiple Links Capability Structure (Memory Space, offset 0C00h)
#define R_PCH_HDABA_LCTLX(x) (R_PCH_HDABA_MLC + (0x40 + (0x40 * (x)) + 0x04)) // x - Link index: 0 - HDA Link, 1 - iDisp Link
#endif