xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688

Browse Source 
The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a
contradiction in it's dependencies.
The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an
enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be
enabled. These options inherit a dependency from an enclosing menu,
that requires ARCH_MULTIPLATFORM to be 'enabled'.
This is a contradiction and made this option also unavailable for
non-multiplatform configurations.

Since there are no selects on OMAP4_ERRATA_I688, which would ignore
dependencies, the code related to that option is dead and can be
removed.

This (logical) defect has been found with the undertaker tool.
(https://undertaker.cs.fau.de)

Signed-off-by: Stefan Hengelein <stefan.hengelein@fau.de>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This commit is contained in:
Stefan Hengelein
2015-02-25 19:44:27 +01:00
committed by Tony Lindgren
parent 026da812a0
commit 606da4826b
7 changed files with 0 additions and 105 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
arch/arm/mach-omap2/Kconfig
View File

@@ -278,27 +278,6 @@ config OMAP3_SDRC_AC_TIMING
wish to say no. Selecting yes without understanding what is
going on could result in system crashes;
config OMAP4_ERRATA_I688
bool "OMAP4 errata: Async Bridge Corruption"
depends on (ARCH_OMAP4 || SOC_OMAP5) && !ARCH_MULTIPLATFORM
select ARCH_HAS_BARRIERS
help
If a data is stalled inside asynchronous bridge because of back
pressure, it may be accepted multiple times, creating pointer
misalignment that will corrupt next transfers on that data path
until next reset of the system (No recovery procedure once the
issue is hit, the path remains consistently broken). Async bridge
can be found on path between MPU to EMIF and MPU to L3 interconnect.
This situation can happen only when the idle is initiated by a
Master Request Disconnection (which is trigged by software when
executing WFI on CPU).
The work-around for this errata needs all the initiators connected
through async bridge must ensure that data path is properly drained
before issuing WFI. This condition will be met if one Strongly ordered
access is performed to the target right before executing the WFI.
In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained.
IO barrier ensure that there is no synchronisation loss on initiators
operating on both interconnect port simultaneously.
endmenu
endif