AetherDroid/android_kernel_samsung_on5xelte
1
0
Fork 0
mirror of https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git synced 2025-09-06 08:18:05 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fixed MTP to work with TWRP

Browse source
This commit is contained in:
awab228 2018-06-19 23:16:04 +02:00
commit f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

71
Documentation/devicetree/bindings/iommu/arm,smmu.txt Normal file
View file

@ -0,0 +1,71 @@
* ARM System MMU Architecture Implementation
ARM SoCs may contain an implementation of the ARM System Memory
Management Unit Architecture, which can be used to provide 1 or 2 stages
of address translation to bus masters external to the CPU.
The SMMU may also raise interrupts in response to various fault
conditions.
** System MMU required properties:
- compatible : Should be one of:
"arm,smmu-v1"
"arm,smmu-v2"
"arm,mmu-400"
"arm,mmu-401"
"arm,mmu-500"
depending on the particular implementation and/or the
version of the architecture implemented.
- reg : Base address and size of the SMMU.
- #global-interrupts : The number of global interrupts exposed by the
device.
- interrupts : Interrupt list, with the first #global-irqs entries
corresponding to the global interrupts and any
following entries corresponding to context interrupts,
specified in order of their indexing by the SMMU.
For SMMUv2 implementations, there must be exactly one
interrupt per context bank. In the case of a single,
combined interrupt, it must be listed multiple times.
- mmu-masters : A list of phandles to device nodes representing bus
masters for which the SMMU can provide a translation
and their corresponding StreamIDs (see example below).
Each device node linked from this list must have a
"#stream-id-cells" property, indicating the number of
StreamIDs associated with it.
** System MMU optional properties:
- calxeda,smmu-secure-config-access : Enable proper handling of buggy
implementations that always use secure access to
SMMU configuration registers. In this case non-secure
aliases of secure registers have to be used during
SMMU configuration.
Example:
smmu {
compatible = "arm,smmu-v1";
reg = <0xba5e0000 0x10000>;
#global-interrupts = <2>;
interrupts = <0 32 4>,
<0 33 4>,
<0 34 4>, /* This is the first context interrupt */
<0 35 4>,
<0 36 4>,
<0 37 4>;
/*
* Two DMA controllers, the first with two StreamIDs (0xd01d
* and 0xd01e) and the second with only one (0xd11c).
*/
mmu-masters = <&dma0 0xd01d 0xd01e>,
<&dma1 0xd11c>;
};

182
Documentation/devicetree/bindings/iommu/iommu.txt Normal file
View file

@ -0,0 +1,182 @@
This document describes the generic device tree binding for IOMMUs and their
master(s).
IOMMU device node:
==================
An IOMMU can provide the following services:
* Remap address space to allow devices to access physical memory ranges that
they otherwise wouldn't be capable of accessing.
Example: 32-bit DMA to 64-bit physical addresses
* Implement scatter-gather at page level granularity so that the device does
not have to.
* Provide system protection against "rogue" DMA by forcing all accesses to go
through the IOMMU and faulting when encountering accesses to unmapped
address regions.
* Provide address space isolation between multiple contexts.
Example: Virtualization
Device nodes compatible with this binding represent hardware with some of the
above capabilities.
IOMMUs can be single-master or multiple-master. Single-master IOMMU devices
typically have a fixed association to the master device, whereas multiple-
master IOMMU devices can translate accesses from more than one master.
The device tree node of the IOMMU device's parent bus must contain a valid
"dma-ranges" property that describes how the physical address space of the
IOMMU maps to memory. An empty "dma-ranges" property means that there is a
1:1 mapping from IOMMU to memory.
Required properties:
--------------------
- #iommu-cells: The number of cells in an IOMMU specifier needed to encode an
address.
The meaning of the IOMMU specifier is defined by the device tree binding of
the specific IOMMU. Below are a few examples of typical use-cases:
- #iommu-cells = <0>: Single master IOMMU devices are not configurable and
therefore no additional information needs to be encoded in the specifier.
This may also apply to multiple master IOMMU devices that do not allow the
association of masters to be configured. Note that an IOMMU can by design
be multi-master yet only expose a single master in a given configuration.
In such cases the number of cells will usually be 1 as in the next case.
- #iommu-cells = <1>: Multiple master IOMMU devices may need to be configured
in order to enable translation for a given master. In such cases the single
address cell corresponds to the master device's ID. In some cases more than
one cell can be required to represent a single master ID.
- #iommu-cells = <4>: Some IOMMU devices allow the DMA window for masters to
be configured. The first cell of the address in this may contain the master
device's ID for example, while the second cell could contain the start of
the DMA window for the given device. The length of the DMA window is given
by the third and fourth cells.
Note that these are merely examples and real-world use-cases may use different
definitions to represent their individual needs. Always refer to the specific
IOMMU binding for the exact meaning of the cells that make up the specifier.
IOMMU master node:
==================
Devices that access memory through an IOMMU are called masters. A device can
have multiple master interfaces (to one or more IOMMU devices).
Required properties:
--------------------
- iommus: A list of phandle and IOMMU specifier pairs that describe the IOMMU
master interfaces of the device. One entry in the list describes one master
interface of the device.
When an "iommus" property is specified in a device tree node, the IOMMU will
be used for address translation. If a "dma-ranges" property exists in the
device's parent node it will be ignored. An exception to this rule is if the
referenced IOMMU is disabled, in which case the "dma-ranges" property of the
parent shall take effect. Note that merely disabling a device tree node does
not guarantee that the IOMMU is really disabled since the hardware may not
have a means to turn off translation. But it is invalid in such cases to
disable the IOMMU's device tree node in the first place because it would
prevent any driver from properly setting up the translations.
Notes:
======
One possible extension to the above is to use an "iommus" property along with
a "dma-ranges" property in a bus device node (such as PCI host bridges). This
can be useful to describe how children on the bus relate to the IOMMU if they
are not explicitly listed in the device tree (e.g. PCI devices). However, the
requirements of that use-case haven't been fully determined yet. Implementing
this is therefore not recommended without further discussion and extension of
this binding.
Examples:
=========
Single-master IOMMU:
--------------------
iommu {
#iommu-cells = <0>;
};
master {
iommus = <&{/iommu}>;
};
Multiple-master IOMMU with fixed associations:
----------------------------------------------
/* multiple-master IOMMU */
iommu {
/*
* Masters are statically associated with this IOMMU and share
* the same address translations because the IOMMU does not
* have sufficient information to distinguish between masters.
*
* Consequently address translation is always on or off for
* all masters at any given point in time.
*/
#iommu-cells = <0>;
};
/* static association with IOMMU */
master@1 {
reg = <1>;
iommus = <&{/iommu}>;
};
/* static association with IOMMU */
master@2 {
reg = <2>;
iommus = <&{/iommu}>;
};
Multiple-master IOMMU:
----------------------
iommu {
/* the specifier represents the ID of the master */
#iommu-cells = <1>;
};
master@1 {
/* device has master ID 42 in the IOMMU */
iommus = <&{/iommu} 42>;
};
master@2 {
/* device has master IDs 23 and 24 in the IOMMU */
iommus = <&{/iommu} 23>, <&{/iommu} 24>;
};
Multiple-master IOMMU with configurable DMA window:
---------------------------------------------------
/ {
iommu {
/*
* One cell for the master ID and one cell for the
* address of the DMA window. The length of the DMA
* window is encoded in two cells.
*
* The DMA window is the range addressable by the
* master (i.e. the I/O virtual address space).
*/
#iommu-cells = <4>;
};
master {
/* master ID 42, 4 GiB DMA window starting at 0 */
iommus = <&{/iommu} 42 0 0x1 0x0>;
};
};

14
Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt Normal file
View file

@ -0,0 +1,14 @@
NVIDIA Tegra 20 GART
Required properties:
- compatible: "nvidia,tegra20-gart"
- reg: Two pairs of cells specifying the physical address and size of
the memory controller registers and the GART aperture respectively.
Example:
gart {
compatible = "nvidia,tegra20-gart";
reg = <0x7000f024 0x00000018 /* controller registers */
0x58000000 0x02000000>; /* GART aperture */
};

21
Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt Normal file
View file

@ -0,0 +1,21 @@
NVIDIA Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit)
Required properties:
- compatible : "nvidia,tegra30-smmu"
- reg : Should contain 3 register banks(address and length) for each
of the SMMU register blocks.
- interrupts : Should contain MC General interrupt.
- nvidia,#asids : # of ASIDs
- dma-window : IOVA start address and length.
- nvidia,ahb : phandle to the ahb bus connected to SMMU.
Example:
smmu {
compatible = "nvidia,tegra30-smmu";
reg = <0x7000f010 0x02c
0x7000f1f0 0x010
0x7000f228 0x05c>;
nvidia,#asids = <4>; /* # of ASIDs */
dma-window = <0 0x40000000>; /* IOVA start & length */
nvidia,ahb = <&ahb>;
};

70
Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt Normal file
View file

@ -0,0 +1,70 @@
Samsung Exynos IOMMU H/W, System MMU (System Memory Management Unit)
Samsung's Exynos architecture contains System MMUs that enables scattered
physical memory chunks visible as a contiguous region to DMA-capable peripheral
devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
System MMU is an IOMMU and supports identical translation table format to
ARMv7 translation tables with minimum set of page properties including access
permissions, shareability and security protection. In addition, System MMU has
another capabilities like L2 TLB or block-fetch buffers to minimize translation
latency.
System MMUs are in many to one relation with peripheral devices, i.e. single
peripheral device might have multiple System MMUs (usually one for each bus
master), but one System MMU can handle transactions from only one peripheral
device. The relation between a System MMU and the peripheral device needs to be
defined in device node of the peripheral device.
MFC in all Exynos SoCs and FIMD, M2M Scalers and G2D in Exynos5420 has 2 System
MMUs.
* MFC has one System MMU on its left and right bus.
* FIMD in Exynos5420 has one System MMU for window 0 and 4, the other system MMU
for window 1, 2 and 3.
* M2M Scalers and G2D in Exynos5420 has one System MMU on the read channel and
the other System MMU on the write channel.
The drivers must consider how to handle those System MMUs. One of the idea is
to implement child devices or sub-devices which are the client devices of the
System MMU.
Note:
The current DT binding for the Exynos System MMU is incomplete.
The following properties can be removed or changed, if found incompatible with
the "Generic IOMMU Binding" support for attaching devices to the IOMMU.
Required properties:
- compatible: Should be "samsung,exynos-sysmmu"
- reg: A tuple of base address and size of System MMU registers.
- interrupt-parent: The phandle of the interrupt controller of System MMU
- interrupts: An interrupt specifier for interrupt signal of System MMU,
according to the format defined by a particular interrupt
controller.
- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
Optional "master" if the clock to the System MMU is gated by
another gate clock other than "sysmmu".
Exynos4 SoCs, there needs no "master" clock.
Exynos5 SoCs, some System MMUs must have "master" clocks.
- clocks: Required if the System MMU is needed to gate its clock.
- samsung,power-domain: Required if the System MMU is needed to gate its power.
Please refer to the following document:
Documentation/devicetree/bindings/arm/exynos/power_domain.txt
Examples:
gsc_0: gsc@13e00000 {
compatible = "samsung,exynos5-gsc";
reg = <0x13e00000 0x1000>;
interrupts = <0 85 0>;
samsung,power-domain = <&pd_gsc>;
clocks = <&clock CLK_GSCL0>;
clock-names = "gscl";
};
sysmmu_gsc0: sysmmu@13E80000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13E80000 0x1000>;
interrupt-parent = <&combiner>;
interrupts = <2 0>;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_GSCL0>, <&clock CLK_GSCL0>;
samsung,power-domain = <&pd_gsc>;
};

26
Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt Normal file
View file

@ -0,0 +1,26 @@
OMAP2+ IOMMU
Required properties:
- compatible : Should be one of,
"ti,omap2-iommu" for OMAP2/OMAP3 IOMMU instances
"ti,omap4-iommu" for OMAP4/OMAP5 IOMMU instances
"ti,dra7-iommu" for DRA7xx IOMMU instances
- ti,hwmods : Name of the hwmod associated with the IOMMU instance
- reg : Address space for the configuration registers
- interrupts : Interrupt specifier for the IOMMU instance
Optional properties:
- ti,#tlb-entries : Number of entries in the translation look-aside buffer.
Should be either 8 or 32 (default: 32)
- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing
back a bus error response on MMU faults.
Example:
/* OMAP3 ISP MMU */
mmu_isp: mmu@480bd400 {
compatible = "ti,omap2-iommu";
reg = <0x480bd400 0x80>;
interrupts = <24>;
ti,hwmods = "mmu_isp";
ti,#tlb-entries = <8>;
};