mirror of
https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git
synced 2025-09-05 07:57:45 -04:00
Fixed MTP to work with TWRP
This commit is contained in:
commit
f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
44
Documentation/xtensa/atomctl.txt
Normal file
44
Documentation/xtensa/atomctl.txt
Normal file
|
@ -0,0 +1,44 @@
|
|||
We Have Atomic Operation Control (ATOMCTL) Register.
|
||||
This register determines the effect of using a S32C1I instruction
|
||||
with various combinations of:
|
||||
|
||||
1. With and without an Coherent Cache Controller which
|
||||
can do Atomic Transactions to the memory internally.
|
||||
|
||||
2. With and without An Intelligent Memory Controller which
|
||||
can do Atomic Transactions itself.
|
||||
|
||||
The Core comes up with a default value of for the three types of cache ops:
|
||||
|
||||
0x28: (WB: Internal, WT: Internal, BY:Exception)
|
||||
|
||||
On the FPGA Cards we typically simulate an Intelligent Memory controller
|
||||
which can implement RCW transactions. For FPGA cards with an External
|
||||
Memory controller we let it to the atomic operations internally while
|
||||
doing a Cached (WB) transaction and use the Memory RCW for un-cached
|
||||
operations.
|
||||
|
||||
For systems without an coherent cache controller, non-MX, we always
|
||||
use the memory controllers RCW, thought non-MX controlers likely
|
||||
support the Internal Operation.
|
||||
|
||||
CUSTOMER-WARNING:
|
||||
Virtually all customers buy their memory controllers from vendors that
|
||||
don't support atomic RCW memory transactions and will likely want to
|
||||
configure this register to not use RCW.
|
||||
|
||||
Developers might find using RCW in Bypass mode convenient when testing
|
||||
with the cache being bypassed; for example studying cache alias problems.
|
||||
|
||||
See Section 4.3.12.4 of ISA; Bits:
|
||||
|
||||
WB WT BY
|
||||
5 4 | 3 2 | 1 0
|
||||
2 Bit
|
||||
Field
|
||||
Values WB - Write Back WT - Write Thru BY - Bypass
|
||||
--------- --------------- ----------------- ----------------
|
||||
0 Exception Exception Exception
|
||||
1 RCW Transaction RCW Transaction RCW Transaction
|
||||
2 Internal Operation Internal Operation Reserved
|
||||
3 Reserved Reserved Reserved
|
64
Documentation/xtensa/mmu.txt
Normal file
64
Documentation/xtensa/mmu.txt
Normal file
|
@ -0,0 +1,64 @@
|
|||
MMUv3 initialization sequence.
|
||||
|
||||
The code in the initialize_mmu macro sets up MMUv3 memory mapping
|
||||
identically to MMUv2 fixed memory mapping. Depending on
|
||||
CONFIG_INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX symbol this code is
|
||||
located in one of the following address ranges:
|
||||
|
||||
0xF0000000..0xFFFFFFFF (will keep same address in MMU v2 layout;
|
||||
typically ROM)
|
||||
0x00000000..0x07FFFFFF (system RAM; this code is actually linked
|
||||
at 0xD0000000..0xD7FFFFFF [cached]
|
||||
or 0xD8000000..0xDFFFFFFF [uncached];
|
||||
in any case, initially runs elsewhere
|
||||
than linked, so have to be careful)
|
||||
|
||||
The code has the following assumptions:
|
||||
This code fragment is run only on an MMU v3.
|
||||
TLBs are in their reset state.
|
||||
ITLBCFG and DTLBCFG are zero (reset state).
|
||||
RASID is 0x04030201 (reset state).
|
||||
PS.RING is zero (reset state).
|
||||
LITBASE is zero (reset state, PC-relative literals); required to be PIC.
|
||||
|
||||
TLB setup proceeds along the following steps.
|
||||
|
||||
Legend:
|
||||
VA = virtual address (two upper nibbles of it);
|
||||
PA = physical address (two upper nibbles of it);
|
||||
pc = physical range that contains this code;
|
||||
|
||||
After step 2, we jump to virtual address in 0x40000000..0x5fffffff
|
||||
that corresponds to next instruction to execute in this code.
|
||||
After step 4, we jump to intended (linked) address of this code.
|
||||
|
||||
Step 0 Step1 Step 2 Step3 Step 4 Step5
|
||||
============ ===== ============ ===== ============ =====
|
||||
VA PA PA VA PA PA VA PA PA
|
||||
------ -- -- ------ -- -- ------ -- --
|
||||
E0..FF -> E0 -> E0 E0..FF -> E0 F0..FF -> F0 -> F0
|
||||
C0..DF -> C0 -> C0 C0..DF -> C0 E0..EF -> F0 -> F0
|
||||
A0..BF -> A0 -> A0 A0..BF -> A0 D8..DF -> 00 -> 00
|
||||
80..9F -> 80 -> 80 80..9F -> 80 D0..D7 -> 00 -> 00
|
||||
60..7F -> 60 -> 60 60..7F -> 60
|
||||
40..5F -> 40 40..5F -> pc -> pc 40..5F -> pc
|
||||
20..3F -> 20 -> 20 20..3F -> 20
|
||||
00..1F -> 00 -> 00 00..1F -> 00
|
||||
|
||||
The default location of IO peripherals is above 0xf0000000. This may change
|
||||
using a "ranges" property in a device tree simple-bus node. See ePAPR 1.1, §6.5
|
||||
for details on the syntax and semantic of simple-bus nodes. The following
|
||||
limitations apply:
|
||||
|
||||
1. Only top level simple-bus nodes are considered
|
||||
|
||||
2. Only one (first) simple-bus node is considered
|
||||
|
||||
3. Empty "ranges" properties are not supported
|
||||
|
||||
4. Only the first triplet in the "ranges" property is considered
|
||||
|
||||
5. The parent-bus-address value is rounded down to the nearest 256MB boundary
|
||||
|
||||
6. The IO area covers the entire 256MB segment of parent-bus-address; the
|
||||
"ranges" triplet length field is ignored
|
Loading…
Add table
Add a link
Reference in a new issue