power: max17040: do a sanity check in the fuel alert handler

Some max1704x devices have been seen to issue a bogus fuel alert.
When this happens, we sanity check the capacity value to make sure
that it is not a transient condition.

Added some more verbose logging when this condition occurs.

Change-Id: I537fb81ab2521469f53ee1ce6b4c16e255128dbe
Signed-off-by: Dima Zavin <dima@android.com>
net: wireless: bcmdhd: Fix scan crash in ibss mode

Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
net: wireless: bcmdhd: Fix proper scan command even if request is NULL

Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
omap: dispc: force L3_2 CD to NOSLEEP when dispc module is active

It has been identified that in addition to L3_1, L3_2 clock domain is
also suspetible to the erratum  (erratum ID is pending) described below.

Issue: Mstandby and disconnect protocol issue
impacts: all OMAP4 devices
Simplfied Description:
issue #1: The handshake between IP modules on L3_1 and L3_2 peripherals with
PRCM has a limitation in a certain time window of L4 clock cycle. Due to the
fact that a wrong variant of stall signal was used in circuit of PRCM, the
intitator-interconnect protocol is broken when the time window is hit where
the PRCM requires the interconnect to go to idle while intitator asks to
wakeup.
Issue #2: DISPC asserts a sub-mstandby signal for a short period. In this
time interval, IP block requests disconnection of Master port, and results
in Mstandby and wait request to PRCM. In parallel, if mstandby is de-asserted
by DISPC simultaneously, interconnect requests for a reconnect for one cycle
alone resulting in a disconnect protocol violation and a deadlock of the
system.

Workaround:
L3_1 clock domain must not be programmed in HW_AUTO if
Static dependency with DSS is enabled and DSS clock domain
is ON. Same for L3_2.

Patch with changeID I28ae362ad330a79a493927575c9570462c4303a7
(omap: dispc: force L3_1 CD to NOSLEEP when dispc module is active)
already introduces the work around for L3_1. Here we add L3_2
clock domain as well + update the comments and wrap the WA under
an OMAP4 flag.

Change-Id: I476eedbac34e1876d413a15a524c3b4bb3732b9f
Signed-off-by: Akash Choudhari <akashc@ti.com>
Signed-off-by: Mahesh Renduchintala <mahesh@ti.com>
CC: Todd Poynor <toddpoynor@google.com>
CC: Colin Cross <ccross@android.com>
CC: Nishanth Menon <nm@ti.com>
CC: Girish S G <girishsg@ti.com>
CC: Dandawate Saket <dsaket@ti.com>
CC: Lajos Molnar <molnar@ti.com>
omap: dispc: force L3_2 CD to NOSLEEP when dispc module is active

It has been identified that in addition to L3_1, L3_2 clock domain is
also suspetible to the erratum  (erratum ID is pending) described below.

Issue: Mstandby and disconnect protocol issue
impacts: all OMAP4 devices
Simplfied Description:
issue #1: The handshake between IP modules on L3_1 and L3_2 peripherals with
PRCM has a limitation in a certain time window of L4 clock cycle. Due to the
fact that a wrong variant of stall signal was used in circuit of PRCM, the
intitator-interconnect protocol is broken when the time window is hit where
the PRCM requires the interconnect to go to idle while intitator asks to
wakeup.
Issue #2: DISPC asserts a sub-mstandby signal for a short period. In this
time interval, IP block requests disconnection of Master port, and results
in Mstandby and wait request to PRCM. In parallel, if mstandby is de-asserted
by DISPC simultaneously, interconnect requests for a reconnect for one cycle
alone resulting in a disconnect protocol violation and a deadlock of the
system.

Workaround:
L3_1 clock domain must not be programmed in HW_AUTO if
Static dependency with DSS is enabled and DSS clock domain
is ON. Same for L3_2.

Patch with changeID I28ae362ad330a79a493927575c9570462c4303a7
(omap: dispc: force L3_1 CD to NOSLEEP when dispc module is active)
already introduces the work around for L3_1. Here we add L3_2
clock domain as well + update the comments and wrap the WA under
an OMAP4 flag.

Change-Id: I476eedbac34e1876d413a15a524c3b4bb3732b9f
Signed-off-by: Akash Choudhari <akashc@ti.com>
Signed-off-by: Mahesh Renduchintala <mahesh@ti.com>
CC: Todd Poynor <toddpoynor@google.com>
CC: Colin Cross <ccross@android.com>
CC: Nishanth Menon <nm@ti.com>
CC: Girish S G <girishsg@ti.com>
CC: Dandawate Saket <dsaket@ti.com>
CC: Lajos Molnar <molnar@ti.com>
usb: musb: Add a BUG_ON if trying to suspend musb in B_IDLE state

Musb sometimes failes to be suspended because it is active and in the
B_IDLE state. When this happens, USBPHY is left on and we don't hit OFF
mode. Add a BUG_ON to reboot in that case as it is better than emptying
the battery and so that we can see how often this happens.

Change-Id: Ic8d8c6918f3b9a8f0671f484d5d72fae63d7a61d
Signed-off-by: Benoit Goby <benoit@android.com>
omap4: prcm debug: Fix l4sec clkactivity bits

Change-Id: I38b298e1eaab1b8f905d916220c310a5dd2c33b6
Signed-off-by: Todd Poynor <toddpoynor@google.com>
usb: musb: Change BUG_ON to BUG to catch the issue as soon as it happens

Bug: 5696789

Change-Id: I660025d8632076cc6bf81cc7026677e7c1bca6d3
Signed-off-by: Benoit Goby <benoit@android.com>
misc: modem_if: link_mipi: Reset mipi phy when receive wrong packet

1. use mipi sw reset after get wrong packet for recovery.

Bug: 5852314
Change-Id: I8cd0ba82d913777d82a59284a657b42e318635ae
Signed-off-by: wonhee <wonhee48.seo@samsung.com>
ASoC: dsp - BE disconnection after pending flag is clear

Currently we can disconnect a BE and have its update flag incorrectly
set after reparenting. Fix this so we always clear the update flag
before any disconnections and reparenting.

dsp_run_update_startup() also called disconnect but this was always
called anyway by its caller soc_dsp_runtime_update() before the update
flag was cleared.

Change-Id: If0cde4c9df845a7189188bb49e6fb4fd496a925d
Signed-off-by: Liam Girdwood <lrg@ti.com>
ASoC: DSP: Split runtime startup/shutdown updates

A FE->BE-1 link can transition to FE->BE-2 in a single widget/kcontrol
change (e.g. Muxes). Currently, DSP framework searches for new and old
paths of the FE, and then perform the startup/shutdown runtime updates.
The single-step FE->BE-1 to FE->BE-2 transition has both: new and old
paths to be updated, hence BE-1 and BE-2 will be marked for runtime
update. However, startup and shutdown updates will both be performed
on BE-1 and BE-2, which is incorect as it would be expected to run
startup update on BE-2 and shutdown update on BE-1.

In order to handle these scenarios, the path search (new and old) is
performed along with its runtime update (startup and shutdown).

Change-Id: I5a687d6fcc51a968d9b0ae52d749935a92f00ef7
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Liam Girdwood <lrg@ti.com>
ASoC: dsp - BE disconnection after pending flag is clear

Currently we can disconnect a BE and have its update flag incorrectly
set after reparenting. Fix this so we always clear the update flag
before any disconnections and reparenting.

dsp_run_update_startup() also called disconnect but this was always
called anyway by its caller soc_dsp_runtime_update() before the update
flag was cleared.

Change-Id: If0cde4c9df845a7189188bb49e6fb4fd496a925d
Signed-off-by: Liam Girdwood <lrg@ti.com>
ASoC: DSP: Split runtime startup/shutdown updates

A FE->BE-1 link can transition to FE->BE-2 in a single widget/kcontrol
change (e.g. Muxes). Currently, DSP framework searches for new and old
paths of the FE, and then perform the startup/shutdown runtime updates.
The single-step FE->BE-1 to FE->BE-2 transition has both: new and old
paths to be updated, hence BE-1 and BE-2 will be marked for runtime
update. However, startup and shutdown updates will both be performed
on BE-1 and BE-2, which is incorect as it would be expected to run
startup update on BE-2 and shutdown update on BE-1.

In order to handle these scenarios, the path search (new and old) is
performed along with its runtime update (startup and shutdown).

Change-Id: I5a687d6fcc51a968d9b0ae52d749935a92f00ef7
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Liam Girdwood <lrg@ti.com>
misc: fsa9480: don't enable FSA IRQ when VBUS IRQ is enabled

We should never enable two detection IRQs inside the FSA9480
driver, otherwise we can get into a situation where we enable
the FSA IRQ multiple times. One way this can happen is if the
FSA IRQ fires when the VBUS IRQ is enabled and we end up
redetecting the same state (i.e. AV_365K_CHARGER).

Change-Id: Iefcf71c88451056b2be318284b0eadc16997e6d9
Signed-off-by: Simon Wilson <simonwilson@google.com>
OMAP4: HWMOD: UART1: disable smart-idle.

UART module gets stuck in transition when smart-idle enabled.
By enabling HWMOD_SWSUP_SIDLE flag in UART1 HWMOD, ensures that
module's smart-idle feature is disabled and it is put to
forced-idle and no-idle during pm-runtime.

Seen similar issue with UART3 and was fixed by enabling
HWMOD_SWSUP_SIDLE flag in uart3 HWMOD.

Change-Id: Id1d97a498a5ffd7323be15be0ba8d0fc02e6df85
Signed-off-by: Ambresh K <ambresh@ti.com>
OMAP4: TWL: ensure PREQ1 results in all active VCOREs to be down

Map VCORE1,2,3 appropriately to PREQ1 APP processor group so that
only APP processor can control it's power down status when OFF
mode is hit. Normally, OMAP sends a OFF voltage command to setup PMIC,
However, it is equally important to ensure that TWL will switch
off the relevant rail when the OFF voltage != 0.

Change-Id: Id623ecdd26bee0504058132835e0112bac1a630e
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: PM: work around for CPU1 onlining from OFF/OSWR state on older PPA

Originally detected in OMAP4430 ES2.3 HS samples, CPU1 crashes the
device upon calling PPA service DEFAULT_POR_NS_SMP(0x25).

Rootcause showed that cache maintenance operations required to be
performed before handing over control of CPU1 to HLOS, were incomplete
and not broadcasted from CPU0 to CPU1.

Kernel workaround for this is to use WFI to put CPU1 in OFF
state if CPU0 is not ready yet (this mechanism was in place in previous
versions of this code base but was meant to address a different need).
When putting CPU1 back to off, its internal MMU descriptors are reset
and sync'd with CPU0. CPU1 is brought online by later kernel subsystems.
Note: CPU0 power state is made to OFF for both OSWR and OFF modes.

This issue has been analysed to impact all OMAP4 non GP devices.

A config flag is introduced to allow platforms and distributions to
enable/disable if PPA version requirement is not met.

Change-Id: I82c5880ec2d9a98a54755dfbd01aa981cfed9852
[nm@ti.com, cileija@ti.com: improvements and rootcause support]
Signed-off-by: Carlos Leija <cileija@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com]
[wwang@ti.com: WA identification]
Signed-off-by: Wenbiao Wang <wwang@ti.com>
OMAP4460: TWL6030: Setup VDD_core OFF voltage to retention voltage

VDD_CORE must not be turned off before VDD_MPU due to OMAP4460
shifter/isolation implementation between MPU_VD and CORE_VD.

Since PWR_REQ is being used for voltage control, this situation
can be handled by using off voltage as retention voltage. This
contributes to the dummy I2C_SR command to setup the voltage
prior to the voltage going down to 0V for VDD_CORE along with
PWR_REQ going low when device OFF mode is achieved. When
device OFF mode is not achieved on an attempted OFF mode,
this has no impact.

Change-Id: Iceb41fbf6b361887c45eeba528ed7f836cff6482
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: PM: TPS6236x: ensure rampdown occurs fast on shutdown

Enable the discharge capacitor to ensure ramp down occurs fast.

Change-Id: I625b75e87e3a22239c14a3d22a3f7752999c05f1
Reported-by: Baek.Kyung-Han <wildtaz.baek@samsung.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: PM: TPS6236x: speed up voltage rampup rate

Increase the voltage ramp rate to 32mv/uSec from 8mV/uSec

This should fasten up our Voltage transition times and benefit
latencies as well.

Change-Id: I5246a75c2f7ec4cc187ba8ad63a7ad71c94616da
Signed-off-by: Nishanth Menon <nm@ti.com>