Riva n oss

AndroidKernel.mk

@@ -32,6 +32,16 @@ ifeq ($(TARGET_ARCH),arm)
 KERNEL_CONFIG_OVERRIDE := CONFIG_ANDROID_BINDER_IPC_32BIT=y
 endif
 endif
+ifeq ($(WT_FINAL_RELEASE),yes)
+KERNEL_CONFIG_OVERRIDE += CONFIG_DYNAMIC_DEBUG=n
+KERNEL_CONFIG_OVERRIDE += CONFIG_DEBUG_RODATA=n
+KERNEL_CONFIG_OVERRIDE += CONFIG_DEBUG_SPINLOCK=n
+KERNEL_CONFIG_OVERRIDE += CONFIG_MSM_DEBUG_LAR_UNLOCK=n
+KERNEL_CONFIG_OVERRIDE += CONFIG_CORESIGHT_DBGUI=n
+KERNEL_CONFIG_OVERRIDE += CONFIG_MSM_RTB=n
+KERNEL_CONFIG_OVERRIDE += CONFIG_MSM_RTB_SEPARATE_CPUS=n
+KERNEL_CONFIG_OVERRIDE += CONFIG_IKCONFIG=n
+endif
 
 TARGET_KERNEL_CROSS_COMPILE_PREFIX := $(strip $(TARGET_KERNEL_CROSS_COMPILE_PREFIX))
 ifeq ($(TARGET_KERNEL_CROSS_COMPILE_PREFIX),)
@@ -50,22 +60,22 @@ endif
 mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
 current_dir := $(notdir $(patsubst %/,%,$(dir $(mkfile_path))))
 ifeq ($(TARGET_KERNEL_VERSION),)
-    TARGET_KERNEL_VERSION := 3.18
+	TARGET_KERNEL_VERSION := 3.18
 endif
 TARGET_KERNEL := msm-$(TARGET_KERNEL_VERSION)
 ifeq ($(TARGET_KERNEL),$(current_dir))
-    # New style, kernel/msm-version
-    BUILD_ROOT_LOC := ../../
-    TARGET_KERNEL_SOURCE := kernel/$(TARGET_KERNEL)
-    KERNEL_OUT := $(TARGET_OUT_INTERMEDIATES)/kernel/$(TARGET_KERNEL)
-    KERNEL_SYMLINK := $(TARGET_OUT_INTERMEDIATES)/KERNEL_OBJ
-    KERNEL_USR := $(KERNEL_SYMLINK)/usr
+	# New style, kernel/msm-version
+	BUILD_ROOT_LOC := ../../
+	TARGET_KERNEL_SOURCE := kernel/$(TARGET_KERNEL)
+	KERNEL_OUT := $(TARGET_OUT_INTERMEDIATES)/kernel/$(TARGET_KERNEL)
+	KERNEL_SYMLINK := $(TARGET_OUT_INTERMEDIATES)/KERNEL_OBJ
+	KERNEL_USR := $(KERNEL_SYMLINK)/usr
 else
-    # Legacy style, kernel source directly under kernel
-    KERNEL_LEGACY_DIR := true
-    BUILD_ROOT_LOC := ../
-    TARGET_KERNEL_SOURCE := kernel
-    KERNEL_OUT := $(TARGET_OUT_INTERMEDIATES)/KERNEL_OBJ
+	# Legacy style, kernel source directly under kernel
+	KERNEL_LEGACY_DIR := true
+	BUILD_ROOT_LOC := ../
+	TARGET_KERNEL_SOURCE := kernel
+	KERNEL_OUT := $(TARGET_OUT_INTERMEDIATES)/KERNEL_OBJ
 endif
 
 KERNEL_CONFIG := $(KERNEL_OUT)/.config
@@ -127,7 +137,7 @@ $(KERNEL_CONFIG): $(KERNEL_OUT)
 	$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(KERNEL_DEFCONFIG)
 	$(hide) if [ ! -z "$(KERNEL_CONFIG_OVERRIDE)" ]; then \
 			echo "Overriding kernel config with '$(KERNEL_CONFIG_OVERRIDE)'"; \
-			echo $(KERNEL_CONFIG_OVERRIDE) >> $(KERNEL_OUT)/.config; \
+		for CONFIG_OVERRIDE in $(KERNEL_CONFIG_OVERRIDE);do echo $$CONFIG_OVERRIDE >> $(KERNEL_OUT)/.config;done; \
 			$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) oldconfig; fi
 
 $(TARGET_PREBUILT_INT_KERNEL): $(KERNEL_OUT) $(KERNEL_HEADERS_INSTALL)
@@ -150,7 +160,7 @@ $(KERNEL_HEADERS_INSTALL): $(KERNEL_OUT)
 			$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(KERNEL_DEFCONFIG); fi
 	$(hide) if [ ! -z "$(KERNEL_CONFIG_OVERRIDE)" ]; then \
 			echo "Overriding kernel config with '$(KERNEL_CONFIG_OVERRIDE)'"; \
-			echo $(KERNEL_CONFIG_OVERRIDE) >> $(KERNEL_OUT)/.config; \
+			for CONFIG_OVERRIDE in $(KERNEL_CONFIG_OVERRIDE);do echo $$CONFIG_OVERRIDE >> $(KERNEL_OUT)/.config;done; \
 			$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) oldconfig; fi
 
 kerneltags: $(KERNEL_OUT) $(KERNEL_CONFIG)

Documentation/device-mapper/verity.txt

@@ -17,11 +17,11 @@ Construction Parameters
 
     0 is the original format used in the Chromium OS.
       The salt is appended when hashing, digests are stored continuously and
-      the rest of the block is padded with zeros.
+      the rest of the block is padded with zeroes.
 
     1 is the current format that should be used for new devices.
       The salt is prepended when hashing and each digest is
-      padded with zeros to the power of two.
+      padded with zeroes to the power of two.
 
 <dev>
     This is the device containing data, the integrity of which needs to be
@@ -72,6 +72,37 @@ Construction Parameters
       notify user space.
 
 
+ignore_zero_blocks
+    Do not verify blocks that are expected to contain zeroes and always return
+    zeroes instead. This may be useful if the partition contains unused blocks
+    that are not guaranteed to contain zeroes.
+
+use_fec_from_device <fec_dev>
+    Use forward error correction (FEC) to recover from corruption if hash
+    verification fails. Use encoding data from the specified device. This
+    may be the same device where data and hash blocks reside, in which case
+    fec_start must be outside data and hash areas.
+
+    If the encoding data covers additional metadata, it must be accessible
+    on the hash device after the hash blocks.
+
+    Note: block sizes for data and hash devices must match. Also, if the
+    verity <dev> is encrypted the <fec_dev> should be too.
+
+fec_roots <num>
+    Number of generator roots. This equals to the number of parity bytes in
+    the encoding data. For example, in RS(M, N) encoding, the number of roots
+    is M-N.
+
+fec_blocks <num>
+    The number of encoding data blocks on the FEC device. The block size for
+    the FEC device is <data_block_size>.
+
+fec_start <offset>
+    This is the offset, in <data_block_size> blocks, from the start of the
+    FEC device to the beginning of the encoding data.
+
+
 Theory of operation
 ===================
 
@@ -91,6 +122,11 @@ per-block basis. This allows for a lightweight hash computation on first read
 into the page cache. Block hashes are stored linearly, aligned to the nearest
 block size.
 
+If forward error correction (FEC) support is enabled any recovery of
+corrupted data will be verified using the cryptographic hash of the
+corresponding data. This is why combining error correction with
+integrity checking is essential.
+
 Hash Tree
 ---------
 

Documentation/devicetree/bindings/arm/msm/clock-controller.txt

@@ -27,6 +27,7 @@ Required properties:
 			"qcom,gcc-spm-8937"
 			"qcom,gcc-8953"
 			"qcom,gcc-8940"
+			"qcom,gcc-8920"
 			"qcom,rpmcc-8994"
 			"qcom,rpmcc-8992"
 			"qcom,rpmcc-8916"
@@ -46,6 +47,7 @@ Required properties:
 			"qcom,cc-debug-8937"
 			"qcom,cc-debug-8917"
 			"qcom,cc-debug-8940"
+			"qcom,cc-debug-8920"
 			"qcom,gcc-mdss-8936"
 			"qcom,gcc-mdss-8909"
 			"qcom,gcc-mdss-8916"
@@ -54,6 +56,7 @@ Required properties:
 			"qcom,gcc-mdss-8917"
 			"qcom,gcc-mdss-8953"
 			"qcom,gcc-mdss-8940"
+			"qcom,gcc-mdss-8920"
 			"qcom,mmsscc-8994v2"
 			"qcom,mmsscc-8994"
 			"qcom,mmsscc-8992"
@@ -67,6 +70,7 @@ Required properties:
 			"qcom,gpucc-8996-v3.0"
 			"qcom,gpucc-8996-pro"
 			"qcom,gcc-gfx-8953"
+			"qcom,gcc-gfx-sdm450"
 			"qcom,gcc-californium"
 			"qcom,cc-debug-californium"
 			"qcom,gcc-mdm9607"

Documentation/devicetree/bindings/arm/msm/msm.txt

@@ -101,6 +101,9 @@ SoCs:
 - MSM8953
   compatible = "qcom,msm8953"
 
+- SDM450
+  compatible = "qcom,sdm450"
+
 - MSM8937
   compatible = "qcom,msm8937"
 
@@ -223,6 +226,8 @@ compatible = "qcom,msm8917-qrd-sku5"
 compatible = "qcom,msm8917-qgp-tmo"
 compatible = "qcom,msm8920-cdp"
 compatible = "qcom,msm8920-mtp"
+compatible = "qcom,msm8920-qrd"
+compatible = "qcom,msm8920-qrd-sku7"
 compatible = "qcom,msm8940-cdp"
 compatible = "qcom,msm8940-mtp"
 compatible = "qcom,msm8940-rumi"
@@ -289,6 +294,9 @@ compatible = "qcom,msm8953-cdp"
 compatible = "qcom,msm8953-mtp"
 compatible = "qcom,msm8953-qrd"
 compatible = "qcom,msm8953-qrd-sku3"
+compatible = "qcom,sdm450-cdp"
+compatible = "qcom,sdm450-mtp"
+compatible = "qcom,sdm450-qrd"
 compatible = "qcom,mdm9640-cdp"
 compatible = "qcom,mdm9640-mtp"
 compatible = "qcom,mdm9640-rumi"

Documentation/devicetree/bindings/arm/msm/msm_bandwidth_monitor.txt

@@ -0,0 +1,52 @@
+Bandwidth Monitor driver(BW_MONITOR)
+=====================================
+
+Bandwidth Monitor driver creates logical sensor nodes with thermal core
+framework for the specified bus. This logical sensor will be used to monitor
+and mitigate the bus bandwidth. This driver can be configured to register
+any bus bandwidth as a sensor for it to be monitored.
+
+The device tree parameters for bandwidth monitor driver(BW_MONITOR) driver are:
+
+Properties:
+
+- compatible:
+        Usage: required
+        Value type: <string>
+        Definition: shall be "qcom,bm-sensors"
+
+- <child node>
+        Usage: required
+        Definition: Each child node represents a bandwidth sensor and name of
+			the node will be used as bandwidth sensor name. Each
+			sensor can represent either single bus bandwidth or
+			aggregation of multiple bus bandwidth.
+
+Child node Properties:
+- qcom,bm-sensor:
+        Usage: required
+        Value type: <array of phandle>
+        Definition: This bandwidth sensor monitors aggregated bandwidth of
+			these bus bandwidth.
+
+- qcom,bm-sensor-field:
+        Usage: required
+        Value type: <string>
+	Definition: This property defines the bandwidth to be monitored,
+			either average bandwidth(ab) or instantaneous
+			bandwidth(ib).
+
+Example:
+	qcom,bm-sensors {
+		compatible = "qcom,bm-sensors";
+
+		bw_mm {
+			qcom,bm-sensor = <&slv_snoc_bimc_0 &slv_snoc_bimc_2>;
+			qcom,bm-sensor-field = "ab";
+		};
+
+		bw_apps {
+			qcom,bm-sensor = <&mas_apps_proc>;
+			qcom,bm-sensor-field = "ib";
+		};
+	};

Documentation/devicetree/bindings/arm/msm/msm_bus_rules.txt

@@ -16,24 +16,28 @@ conditions to be monitored. The mandatory properties for the rules are
 
 - qcom,src-nodes:		An array of phandles denoting the source nodes
 				whose bandwidth votes need to be monitored.
-- qcom,src-field:		This field represents the voted field of the
-				source node to be monitored. Possible values
-				are FLD_IB/FLD_AB/FLD_CLK
-- qcom,src-op:			The operand to be used when evaluating a node's
-				bandwidth vote with a threshold.Possible values
-				are OP_LE/OP_LT/OP_GT/OP_GE.
-- qcom,thresh:			The threshold in Kbytes/s to be used in vote
-				evaluation.
+- qcom,src-field:		An array of fields represents the voted field
+				of the source node to be monitored. Possible
+				values are FLD_IB/FLD_AB/FLD_CLK.
+- qcom,src-op:			An array of operands to be used when evaluating
+				a node's bandwidth vote with a threshold.
+				Possible values are OP_LE/OP_LT/OP_GT/OP_GE.
+- qcom,thresh:			An array of thresholds in Kbytes/s
+				(in FLD_IB/FLD_AB case) or KHz (in FLD_CLK case)
+				to be used in vote evaluation.
 - qcom,mode:			The QoS mode to be applied when this rule's
 				criterion are satisfied. Possible values are
-				THROTTLE_ON/THROTTLE_OFF
+				THROTTLE_ON/THROTTLE_OFF.
 - qcom,dest-node:		An array of phandles representing the nodes to
 				which the QoS mode is to be applied.
 
 The optional properties for the rule node are:
 - qcom,dest-bw:			The destination bandwidth value in Kbytes/s to
 				be used toward the QoS mode for the destination
 				node.
+- qcom,combo-op:		A property that is only required when there
+				are multiple comparison operands to multiple
+				thresholds, can be OP_AND or OP_OR.
 
 Example:
 	static-rules {
@@ -42,13 +46,14 @@ Example:
 		#size-cells = <0>;
 
 		rule@0 {
-			qcom,src-nodes = <&mas_apss>;
-			qcom,src-field = <FLD_IB>;
-			qcom,src-op = <OP_LE>;
-			qcom,thresh = <1599078>;
+			qcom,src-nodes = <&mas_apss &mas_mdp>;
+			qcom,src-field = <FLD_IB FLD_AB>;
+			qcom,src-op = <OP_LE OP_GT>;
+			qcom,thresh = <1599078 0>;
 			qcom,mode = <THROTTLE_ON>;
 			qcom,dest-node = <&mas_apss>;
 			qcom,dest-bw = <1599078>;
+			qcom,combo-op = <OP_AND>;
 		};
 
 		rule@1 {

Documentation/devicetree/bindings/cnss/cnss-wlan.txt

@@ -47,8 +47,6 @@ Optional properties:
   - vdd-wlan-en-supply: WLAN_EN fixed regulator specified by QCA6174 specifications.
   - qcom,wlan-en-vreg-support: Boolean property to decide the whether the WLAN_EN pin
 				is a gpio or fixed regulator.
-  - qcom,enable-bootstrap-gpio: Boolean property to decide whether wlan bootstrap
-                                 gpio should be enabled or not in this platform.
 
 Example:
 

Documentation/devicetree/bindings/fb/mdss-dsi-panel.txt

@@ -326,6 +326,28 @@ Optional properties:
 					2A/2B command.
 - qcom,dcs-cmd-by-left:			Boolean to indicate that dcs command are sent
 					through the left DSI controller only in a dual-dsi configuration
+- qcom,mdss-dsi-panel-hdr-enabled:	Boolean to indicate HDR support in panel.
+- qcom,mdss-dsi-panel-hdr-color-primaries:
+					Array of 8 unsigned integers denoting chromaticity of panel.These
+					values are specified in nits units. The value range is 0 through 50000.
+					To obtain real chromacity, these values should be divided by factor of
+					50000. The structure of array is defined in below order
+						value 1: x value of white chromaticity of display panel
+						value 2: y value of white chromaticity of display panel
+						value 3: x value of red chromaticity of display panel
+						value 4: y value of red chromaticity of display panel
+						value 5: x value of green chromaticity of display panel
+						value 6: y value of green chromaticity of display panel
+						value 7: x value of blue chromaticity of display panel
+						value 8: y value of blue chromaticity of display panel
+- qcom,mdss-dsi-panel-peak-brightness:	Maximum brightness supported by panel.In absence of maximum value
+					typical value becomes peak brightness. Value is specified in nits units.
+					To obtail real peak brightness, this value should be divided by factor of
+					10000.
+- qcom,mdss-dsi-panel-blackness-level:	Blackness level supported by panel. Blackness level is defined as
+					ratio of peak brightness to contrast. Value is specified in nits units.
+					To obtail real blackness level, this value should be divided by factor of
+					10000.
 - qcom,mdss-dsi-lp11-init:		Boolean used to enable the DSI clocks and data lanes (low power 11)
 					before issuing hardware reset line.
 - qcom,mdss-dsi-init-delay-us:		Delay in microseconds(us) before performing any DSI activity in lp11

Documentation/devicetree/bindings/gpu/adreno.txt

@@ -80,6 +80,9 @@ DCVS Core info
 Optional Properties:
 - qcom,initial-powerlevel: This value indicates which qcom,gpu-pwrlevel should be used at start time
 			   and when coming back out of resume
+- qcom,restrict-powerlevel: This value to limit max GPU power level jump during the clock switch and
+			   while coming back out of slumber. Max GPU power level jump still allowed
+			   from the restricted-pwerlevel.
 - qcom,bus-control:	   Boolean. Enables an independent bus vote from the gpu frequency
 - qcom,bus-width:	   Bus width in number of bytes. This enables dynamic AB bus voting based on
 			   bus width and actual bus transactions.
@@ -148,6 +151,10 @@ Optional Properties:
 				baseAddr - base address of the gpu channels in the qdss stm memory region
 				size     - size of the gpu stm region
 
+- qcom,tsens-name:
+				Specify the name of GPU temperature sensor. This name will be used
+				to get the temperature from the thermal driver API.
+
 GPU Quirks:
 - qcom,gpu-quirk-two-pass-use-wfi:
 				Signal the GPU to set Set TWOPASSUSEWFI bit in