Create AMSDK defconfig
* Create kernel defconfig used by AM335x AMSDK 6.00.00.00
Signed-off-by: Franklin S. Cooper Jr <fcooper@ti.com>
* Create kernel defconfig used by AM335x AMSDK 6.00.00.00
Signed-off-by: Franklin S. Cooper Jr <fcooper@ti.com>
am335x:Re-enable Turbo and Nitro modes for Beaglebone Black The Beaglebone Black boards use a speed binned PG2.0 AM335x that operate up to 1GHz so re-enable those modes for Beaglebone Black.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
am335x:Add minimal support for Beaglebone Black
- Detect Beaglebone Black and do the appropriate pin mux
- Add pin mux for eMMC
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
- Detect Beaglebone Black and do the appropriate pin mux
- Add pin mux for eMMC
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
ARM: OMAP2+: AM335x: Update SPI flash layout
Current U-Boot has grown, and our size of the environment was never
correct, rework the offsets for minimal impact.
Signed-off-by: Tom Rini <trini@ti.com>
Current U-Boot has grown, and our size of the environment was never
correct, rework the offsets for minimal impact.
Signed-off-by: Tom Rini <trini@ti.com>
am335x: enable pullup on the WLAN enable pin for keeping wlan
* Enable pullup on the WLAN enable pin for keeping wlan active
during suspend in wowlan mode. The fix is relevant only in the case
of am335x-SK board.
Signed-off-by: Vita Preskovsky <vitap@ti.com>
* Enable pullup on the WLAN enable pin for keeping wlan active
during suspend in wowlan mode. The fix is relevant only in the case
of am335x-SK board.
Signed-off-by: Vita Preskovsky <vitap@ti.com>
am335xevm: using edge triggered interrupts for WLAN
*using edge triggered interrupts instead of default level triggered in
all platforms supporting WLAN. This reduces CPU cycles and possibility
for missed interrupts.
Signed-off-by: Vita Preskovsky <vitap@ti.com>
*using edge triggered interrupts instead of default level triggered in
all platforms supporting WLAN. This reduces CPU cycles and possibility
for missed interrupts.
Signed-off-by: Vita Preskovsky <vitap@ti.com>
am3358-sk: modified WLAN enable and irq to match board revision 1.2 * 1. WLAN enable and irq are modified to match board revision 1.2 2. support suspend/resume for SK board
Upstream-Status: Pending
Signed-off-by: Vita Preskovsky <vitap@ti.com>
Upstream-Status: Pending
Signed-off-by: Vita Preskovsky <vitap@ti.com>
omap-serial: add delay before suspending
In case suspending during Bluetooth traffic, after resume the bluetooth is
stuck.
It was identified that suspend is happening before the UART buffer was
fully drained which caused this hang after resume.
The folliwng delay is a temporary workaround until the issue is resolved
properly.
Upstream Status: Pending
Signed-off-by: Eyal Reizer <eyalr@ti.com>
In case suspending during Bluetooth traffic, after resume the bluetooth is
stuck.
It was identified that suspend is happening before the UART buffer was
fully drained which caused this hang after resume.
The folliwng delay is a temporary workaround until the issue is resolved
properly.
Upstream Status: Pending
Signed-off-by: Eyal Reizer <eyalr@ti.com>
Smartreflex support for ES 2.x and suspend resume
This change adds support for ES 2.x to the SmartReflex driver.
It also adds suspend/resume handlers which resolves an identified
problem. The voltage calculation has been improved in order
to settle more quickly and accurately to the target voltage.
Signed-off-by: Greg Guyotte <gguyotte@ti.com>
This change adds support for ES 2.x to the SmartReflex driver.
It also adds suspend/resume handlers which resolves an identified
problem. The voltage calculation has been improved in order
to settle more quickly and accurately to the target voltage.
Signed-off-by: Greg Guyotte <gguyotte@ti.com>
Smartreflex limited to ES 1.0
Pending complete characterization of Smartreflex on ES 2.0 silicon,
the smartreflex function is disabled. SR continues to operate
normally on ES 1.0 silicon. If running on AM335x ES 2.0 silicon,
the SR driver will cleanly abort, causing no side effects.
Signed-off-by: Greg Guyotte <gguyotte@ti.com>
Pending complete characterization of Smartreflex on ES 2.0 silicon,
the smartreflex function is disabled. SR continues to operate
normally on ES 1.0 silicon. If running on AM335x ES 2.0 silicon,
the SR driver will cleanly abort, causing no side effects.
Signed-off-by: Greg Guyotte <gguyotte@ti.com>
am33xx: Enable CONFIG_AM33XX_SMARTREFLEX
Simply enables the SmartReflex driver in the defconfig file.
Signed-off-by: Greg Guyotte <gguyotte@ti.com>
Simply enables the SmartReflex driver in the defconfig file.
Signed-off-by: Greg Guyotte <gguyotte@ti.com>
am33xx: Add SmartReflex support.
This patch introduces SmartReflex support to AM33XX devices. The
purpose of SmartReflex is to optimize (lower) voltage based upon
silicon process and temperature.
The SmartReflex driver requires the silicon to be programmed with
"nTarget" EFUSE values. If the values are not present (as with
pre-RTP samples), the driver will simply fail to load and kernel
boot will continue normally.
The SR driver logs several items in the debugfs at /debug/smartreflex.
To disable SmartReflex, use the command 'echo 0 > /debug/smartreflex/autocomp'.
The node /debug/smartreflex/smartreflex0 gives information about
the CORE voltage domain, and /smartreflex1 is related to the MPU voltage
domain.
To determine the effectiveness of SmartReflex, you can compare the
initial voltage with the current voltage for a given OPP. For example,
'cat /debug/smartreflex/smartreflex1/current_voltage' gives the current
MPU voltage. Comparing that with 'cat /debug/smartreflex/smartreflex1/
initial_voltage' will show you the voltage drop associated with SR
operation.
Signed-off-by: Greg Guyotte <gguyotte@ti.com>
This patch introduces SmartReflex support to AM33XX devices. The
purpose of SmartReflex is to optimize (lower) voltage based upon
silicon process and temperature.
The SmartReflex driver requires the silicon to be programmed with
"nTarget" EFUSE values. If the values are not present (as with
pre-RTP samples), the driver will simply fail to load and kernel
boot will continue normally.
The SR driver logs several items in the debugfs at /debug/smartreflex.
To disable SmartReflex, use the command 'echo 0 > /debug/smartreflex/autocomp'.
The node /debug/smartreflex/smartreflex0 gives information about
the CORE voltage domain, and /smartreflex1 is related to the MPU voltage
domain.
To determine the effectiveness of SmartReflex, you can compare the
initial voltage with the current voltage for a given OPP. For example,
'cat /debug/smartreflex/smartreflex1/current_voltage' gives the current
MPU voltage. Comparing that with 'cat /debug/smartreflex/smartreflex1/
initial_voltage' will show you the voltage drop associated with SR
operation.
Signed-off-by: Greg Guyotte <gguyotte@ti.com>
omap4-rng: Remove check for GP-only device type in RNG driver
HS devices can support RNG due to recent changes in firewall settings on L4.
The patch enables RNG support on HS device.
Signed-off-by: Joel A Fernandes <joelagnel@ti.com>
HS devices can support RNG due to recent changes in firewall settings on L4.
The patch enables RNG support on HS device.
Signed-off-by: Joel A Fernandes <joelagnel@ti.com>
hwrng: omap4-rng: Convert to use pm_runtime API
Convert the omap4-rng driver to use the pm_runtime
API instead of the clk API.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Convert the omap4-rng driver to use the pm_runtime
API instead of the clk API.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
ARM: AM33xx: hwmod: Convert RNG device data to hwmod
Convert the device data for the AM33xx RNG module
from explicit platform_data to hwmod.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Convert the device data for the AM33xx RNG module
from explicit platform_data to hwmod.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
crypto: omap4-aes: Don't use hardcoded base address
The omap4-aes driver currently uses a hardcoded base
address for its register set instead of the address
passed in by the system. Instead, use the address
passed in by the system.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
The omap4-aes driver currently uses a hardcoded base
address for its register set instead of the address
passed in by the system. Instead, use the address
passed in by the system.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
crypto: omap4-aes: Add suspend/resume PM support
Add suspend/resume PM support to the omap4-aes driver
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Add suspend/resume PM support to the omap4-aes driver
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
crypto: omap4-aes: User finer-grained PM management
Currently, the pm_runtime calls in omap4-aes enable
things when the driver is probed and leave them enabled
until the driver is removed. To fix this, move the
pm_runtime calls to only enable the aes module when
its actually in use.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Currently, the pm_runtime calls in omap4-aes enable
things when the driver is probed and leave them enabled
until the driver is removed. To fix this, move the
pm_runtime calls to only enable the aes module when
its actually in use.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
ARM: AM33xx: hwmod: Convert AES0 crypto device data to hwmod
Convert the device data for the AM33xx AES0 crypto modules
from explicit platform_data to hwmod.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Convert the device data for the AM33xx AES0 crypto modules
from explicit platform_data to hwmod.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
crypto: omap4-sham: Don't use hardcoded base address
The omap4-sham driver currently uses a hardcoded base
address for its register set instead of the address
passed in by the system. Instead, use the address
passed in by the system.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
The omap4-sham driver currently uses a hardcoded base
address for its register set instead of the address
passed in by the system. Instead, use the address
passed in by the system.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
crypto: omap4-sham: Add suspend/resume PM support
Add suspend/resume PM support to the omap4-sham driver
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Add suspend/resume PM support to the omap4-sham driver
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
crypto: omap4-sham: Use finer-grained PM management
Currently, the pm_runtime calls in omap4-sham enable
things when the driver is probed and leave them enabled
until the driver is removed. To fix this, move the
pm_runtime calls to only enable the sham module when
its actually in use.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Currently, the pm_runtime calls in omap4-sham enable
things when the driver is probed and leave them enabled
until the driver is removed. To fix this, move the
pm_runtime calls to only enable the sham module when
its actually in use.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
ARM: AM33xx: hwmod: Convert SHA0 crypto device data to hwmod
Convert the device data for the AM33xx SHA0 crypto modules
from explicit platform_data to hwmod.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Convert the device data for the AM33xx SHA0 crypto modules
from explicit platform_data to hwmod.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Add suspend resume routines to crypto driver
* Add suspend resume routines to AES crypto driver
* Add suspend resume routines to SHA crypto driver
* Cleaned up some build warnings
* Add suspend resume routines to AES crypto driver
* Add suspend resume routines to SHA crypto driver
* Cleaned up some build warnings
Add pm_runtime API to crypto driver
* Add pm_runtime API to crypto driver AES and SHA
* Mod devices.c file to add pm_runtime for crypto
* Mod omap_hwmod_33xx_data.c to add resources structures
* Crypto module clocks are enabled in probe function
and disabled only on remove or other error.
* Add pm_runtime API to crypto driver AES and SHA
* Mod devices.c file to add pm_runtime for crypto
* Mod omap_hwmod_33xx_data.c to add resources structures
* Crypto module clocks are enabled in probe function
and disabled only on remove or other error.
Add crypto driver settings to defconfig
* Add Crypto Driver and configuration to defconfig
* Add Crypto Driver and configuration to defconfig
AM335x OCF Driver for Linux 3
am33x: Create driver for SHA/MD5 crypto module
This is the initial version of the SHA/MD5 driver for OMAP4 derivative SOC's such as AM335x.
Signed-off-by: Greg Turner <gregturner@ti.com>
This is the initial version of the SHA/MD5 driver for OMAP4 derivative SOC's such as AM335x.
Signed-off-by: Greg Turner <gregturner@ti.com>
am33x: Create driver for AES crypto module
This is the initial version of the driver for the AES crypto module for a GP version of OMAP4 derivative SOC's such as AM335x.
Signed-off-by: Greg Turner <gregturner@ti.com>
This is the initial version of the driver for the AES crypto module for a GP version of OMAP4 derivative SOC's such as AM335x.
Signed-off-by: Greg Turner <gregturner@ti.com>
am33x: Create driver for TRNG crypto module
This is the initial version of the driver for the TRNG crypto module for a GP version of OMAP4 derivative SOC's such as AM335x.
Signed-off-by: Greg Turner <gregturner@ti.com>
This is the initial version of the driver for the TRNG crypto module for a GP version of OMAP4 derivative SOC's such as AM335x.
Signed-off-by: Greg Turner <gregturner@ti.com>
am33x: Create header file for OMAP4 crypto modules
* This header file defines addresses and macros used to access crypto modules on OMAP4 derivative SOC's like AM335x.
Signed-off-by: Greg Turner <gregturner@ti.com>
* This header file defines addresses and macros used to access crypto modules on OMAP4 derivative SOC's like AM335x.
Signed-off-by: Greg Turner <gregturner@ti.com>
am33x: Add crypto drivers to Kconfig and Makefiles
* Add OMAP4 TRNG driver to hw_random Kconfig and Makefile
* Add OMAP4 AES and SHA/MD5 driver to crypto Kconfig and Makefile
* Needed so that drivers can be selected during kernel config
Signed-off-by: Greg Turner <gregturner@ti.com>
* Add OMAP4 TRNG driver to hw_random Kconfig and Makefile
* Add OMAP4 AES and SHA/MD5 driver to crypto Kconfig and Makefile
* Needed so that drivers can be selected during kernel config
Signed-off-by: Greg Turner <gregturner@ti.com>
am33x: Add crypto device and resource structure for TRNG
* Add platform device and resource structure to devices.c
* Structures are for the TRNG crypto module
* Used in the OMAP4 crypto driver
Signed-off-by: Greg Turner <gregturner@ti.com>
* Add platform device and resource structure to devices.c
* Structures are for the TRNG crypto module
* Used in the OMAP4 crypto driver
Signed-off-by: Greg Turner <gregturner@ti.com>
am33x: Add crypto device and resource structures
* Add platform device and resource structures to devices.c
* Structures are for the AES and SHA/MD5 crypto modules
* Used in the OMAP4 crypto driver
Signed-off-by: Greg Turner <gregturner@ti.com>
* Add platform device and resource structures to devices.c
* Structures are for the AES and SHA/MD5 crypto modules
* Used in the OMAP4 crypto driver
Signed-off-by: Greg Turner <gregturner@ti.com>
am33x: Add memory addresses for crypto modules
* Add base memory addresses to the am33xx.h header file
These addresses are for the HW crypto modules including TRNG, AES, and SHA/MD5
Signed-off-by: Greg Turner <gregturner@ti.com>
* Add base memory addresses to the am33xx.h header file
These addresses are for the HW crypto modules including TRNG, AES, and SHA/MD5
Signed-off-by: Greg Turner <gregturner@ti.com>
mach-omap2: pm33xx: Disable VT switch
* Added a new config option TI_PM_DISABLE_VT_SWITCH which
disables the VT console switch which normally occurs during
suspend. This console switch can cause a hange when performed
with applications like Matrix running. The VT switch is
considered unnecessary.
* Modified the am335x_evm_defconfig file to default the
TI_PM_DISABLE_VT_SWITCH to "y".
* Based on a patch for the linux-omap3 kernel by Greg Guyotte
Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
* Added a new config option TI_PM_DISABLE_VT_SWITCH which
disables the VT console switch which normally occurs during
suspend. This console switch can cause a hange when performed
with applications like Matrix running. The VT switch is
considered unnecessary.
* Modified the am335x_evm_defconfig file to default the
TI_PM_DISABLE_VT_SWITCH to "y".
* Based on a patch for the linux-omap3 kernel by Greg Guyotte
Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
musb: update PIO mode help information in Kconfig
* Updated the Kconfig help information for the PIO mode for MUSB
to make it more clear to the customer when to select this option
and which devices currently have issues with this option.
* This is in accordance with the findings for CPPI4.1 DMA usage
for MUSB
Upstream-Status: Submitted
* Submitted to the PSP team using the lpr list
Signed-off-by: Matt Porter <mporter@ti.com>
Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
* Updated the Kconfig help information for the PIO mode for MUSB
to make it more clear to the customer when to select this option
and which devices currently have issues with this option.
* This is in accordance with the findings for CPPI4.1 DMA usage
for MUSB
Upstream-Status: Submitted
* Submitted to the PSP team using the lpr list
Signed-off-by: Matt Porter <mporter@ti.com>
Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
ARM: OMAP2+: AM335x: update OPP50 handling
Recent commit from Greg (OPP Table fix for 720MHZ and ZCE
support) added OPP120 support for PG 2.x.
OPP120 support needs to be disabled when the board is booted and
running at OPP50. This is as per the Advisory 1.0.15 (ARM Cortex-A8:
OPP50 Operation on MPU Domain Not Supported)
Voltage checked here are Core Voltage and not MPU. Hence, When here
correct the preprocessors to indicate correct voltages.
As per Sitara AM335x ARM Cortex -A8 Microprocessors (MPUs) data sheet
(SPRS717F) APRIL 2013 available at
http://www.ti.com/lit/ds/symlink/am3359.pdf
Table 3-7 and 3-9 has been updated to show the defined OPPs on ZCZ and
ZCE packages respectively
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
Recent commit from Greg (OPP Table fix for 720MHZ and ZCE
support) added OPP120 support for PG 2.x.
OPP120 support needs to be disabled when the board is booted and
running at OPP50. This is as per the Advisory 1.0.15 (ARM Cortex-A8:
OPP50 Operation on MPU Domain Not Supported)
Voltage checked here are Core Voltage and not MPU. Hence, When here
correct the preprocessors to indicate correct voltages.
As per Sitara AM335x ARM Cortex -A8 Microprocessors (MPUs) data sheet
(SPRS717F) APRIL 2013 available at
http://www.ti.com/lit/ds/symlink/am3359.pdf
Table 3-7 and 3-9 has been updated to show the defined OPPs on ZCZ and
ZCE packages respectively
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
OPP Table fix for 720MHZ and ZCE support
Current OPP table excludes 720MHz OPPs for ES 2.0 and ES 2.1. It also
excludes an 300MHz at 1.1V operating point required for ZCE support on
ES 2.1.
This patch implements support for the same.
As per Sitara AM335x ARM Cortex -A8 Microprocessors (MPUs) data sheet
(SPRS717F) APRIL 2013 available at
http://www.ti.com/lit/ds/symlink/am3359.pdf
Table 3-7 and 3-9 has been updated to show the defined OPPs on ZCZ and
ZCE packages respectively
[ Hebbar Gururaja]:
- Add Link to Documentation and reference table.
- Fix merge issue and remove whitespace warning
Signed-off-by: Greg Guyotte <gguyotte@ti.com>
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
Current OPP table excludes 720MHz OPPs for ES 2.0 and ES 2.1. It also
excludes an 300MHz at 1.1V operating point required for ZCE support on
ES 2.1.
This patch implements support for the same.
As per Sitara AM335x ARM Cortex -A8 Microprocessors (MPUs) data sheet
(SPRS717F) APRIL 2013 available at
http://www.ti.com/lit/ds/symlink/am3359.pdf
Table 3-7 and 3-9 has been updated to show the defined OPPs on ZCZ and
ZCE packages respectively
[ Hebbar Gururaja]:
- Add Link to Documentation and reference table.
- Fix merge issue and remove whitespace warning
Signed-off-by: Greg Guyotte <gguyotte@ti.com>
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
ARM: OMAP2+: AM33XX: Fix race between request_irq and gpio_mask_irq
After random iteration, uart standby using (gpio pin configs) hangs.
Upon deep observation (and lots of debug prints), it was observed that
the GPIO Rising/Falling detect registers were cleared (IRQ disabled)
before system entered standby. Any UART activity (key press) was not
detected.
This registers were properly setup by request_irq call from
am33xx_pm_prepare_late() (initial suspend stage).
However, driver suspend calls (.suspend()) come in later stage and due
to some race condition, gpio_mask_irq() masks/clears above registers.
The fix is to call the standby setup function (which calls request_irq)
at final stage just before the actual suspend call.
This fix was tested by placing the system under standby stress test for
more than 20 Hours.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
After random iteration, uart standby using (gpio pin configs) hangs.
Upon deep observation (and lots of debug prints), it was observed that
the GPIO Rising/Falling detect registers were cleared (IRQ disabled)
before system entered standby. Any UART activity (key press) was not
detected.
This registers were properly setup by request_irq call from
am33xx_pm_prepare_late() (initial suspend stage).
However, driver suspend calls (.suspend()) come in later stage and due
to some race condition, gpio_mask_irq() masks/clears above registers.
The fix is to call the standby setup function (which calls request_irq)
at final stage just before the actual suspend call.
This fix was tested by placing the system under standby stress test for
more than 20 Hours.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
ARM: OMAP: AM33XX: Add OPP table for PG2.1 AM335x
Add OPP table for MPU voltage domain.
Changes from PG2.0:
1. The Operating voltage for Nitro Mode is 1.35V
2. PG 2.1 SoC has a new efuse sma register which describes the device's
ARM maximum frequency capabilities and package type. Upon parsing this
register, the supported maximum frequency is obtained.
Note:
If this register is not populated (mpu max freq field is 0), then we
revert back to PG 2.0 OPP list.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
Add OPP table for MPU voltage domain.
Changes from PG2.0:
1. The Operating voltage for Nitro Mode is 1.35V
2. PG 2.1 SoC has a new efuse sma register which describes the device's
ARM maximum frequency capabilities and package type. Upon parsing this
register, the supported maximum frequency is obtained.
Note:
If this register is not populated (mpu max freq field is 0), then we
revert back to PG 2.0 OPP list.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
Revert "ARM: OMAP: AM33XX: Add OPP table for PG2.1 AM335x"
This reverts commit ee9dfd8d729d3e7b5ce9e404a0e87f27f6f79135.
This patch checks for the package type for checking the supported opp
bits & also if the bits are set, the opp table is updated.
However, checking package type bit is not required & also, the opp bit
checking must be reversed.
A fix for the same will follow after this commit
This reverts commit ee9dfd8d729d3e7b5ce9e404a0e87f27f6f79135.
This patch checks for the package type for checking the supported opp
bits & also if the bits are set, the opp table is updated.
However, checking package type bit is not required & also, the opp bit
checking must be reversed.
A fix for the same will follow after this commit
ARM: OMAP2+: AM335x: Handle OPP50 Bootup
As per Advisory 1.0.15 (ARM Cortex-A8: OPP50 Operation on MPU Domain Not
Supported), when the board is booted with OPP50, reliable operation is
not guaranteed for OPP greater than OPP100 (OPP120, TURBO, NITRO).
So, Check if the board is booted at OPP50 voltage & if yes, disable
higher OPP (OPP120, TURBO, NITRO).
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
As per Advisory 1.0.15 (ARM Cortex-A8: OPP50 Operation on MPU Domain Not
Supported), when the board is booted with OPP50, reliable operation is
not guaranteed for OPP greater than OPP100 (OPP120, TURBO, NITRO).
So, Check if the board is booted at OPP50 voltage & if yes, disable
higher OPP (OPP120, TURBO, NITRO).
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
ARM: OMAP: AM33XX: Add OPP table for PG2.1 AM335x
Add OPP table for MPU voltage domain.
Changes from PG2.0:
1. The Operating voltage for Nitro Mode is 1.35v
2. PG 2.1 SoC has a new efuse sma register which describes the device's
ARM maximum frequency capabilities and package type. Upon parsing this
register, the supported maximum frequency is obtained.
Note:
If this register is not populated or the data is invalid (package type),
then we revert back to PG 2.0 OPP list.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
Add OPP table for MPU voltage domain.
Changes from PG2.0:
1. The Operating voltage for Nitro Mode is 1.35v
2. PG 2.1 SoC has a new efuse sma register which describes the device's
ARM maximum frequency capabilities and package type. Upon parsing this
register, the supported maximum frequency is obtained.
Note:
If this register is not populated or the data is invalid (package type),
then we revert back to PG 2.0 OPP list.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.
GPTimer non-posted synchronization mode is not impacted by this
limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.
For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.
__omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
__omap_dm_timer_enable_posted(timer);
Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.
Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[hvaibhav@ti.com: Backported to v3.2 PSP kernel, also merged
commit 7b44cf2c15f (ARM: OMAP: Fix timer posted mode support)]
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.
GPTimer non-posted synchronization mode is not impacted by this
limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.
For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.
__omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
__omap_dm_timer_enable_posted(timer);
Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.
Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[hvaibhav@ti.com: Backported to v3.2 PSP kernel, also merged
commit 7b44cf2c15f (ARM: OMAP: Fix timer posted mode support)]
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
usb: musb: gadget: rxdma fix when data rcvd before usb request queued
In DMA mode, when the data is received from host before the next request
is programmed, the pio interrupt occurs and data lost since no request.
This scenario occurs sometimes in android gadget, when adb protocol receive
bigger size (>4KB) files.
The fix is not to disable the dma after completion of current rx request
so that dma interrupt will occur correctly for next request
when data received from host before next request is programmed.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
In DMA mode, when the data is received from host before the next request
is programmed, the pio interrupt occurs and data lost since no request.
This scenario occurs sometimes in android gadget, when adb protocol receive
bigger size (>4KB) files.
The fix is not to disable the dma after completion of current rx request
so that dma interrupt will occur correctly for next request
when data received from host before next request is programmed.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
usb: gadget: multi: compilation fixes for usb multi gadget
fixes the missing declaration for manufacturer & vendorID
for multi gadget configuration
Signed-off-by: Ravi Babu <ravibabu@ti.com>
fixes the missing declaration for manufacturer & vendorID
for multi gadget configuration
Signed-off-by: Ravi Babu <ravibabu@ti.com>
usb: musb: cppi41: g_multi gadget fixes in dma mode
- bug fixes for schedular table add_(remove) channel API's
- adds the sched_tbl_control flag to add/remove channel dynamically.
- This fixes the g_multi gadget issue.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
- bug fixes for schedular table add_(remove) channel API's
- adds the sched_tbl_control flag to add/remove channel dynamically.
- This fixes the g_multi gadget issue.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
ARM: AM335x: SGX: Graphics device registration using HWMOD
This adds the function for AM335x SGX device registration using HWMOD APIs.
Also added is omap_device handle creation for SGX module.
This is required for supporting pm_runtime APIs in SGX driver.
This patch is required for 3.2 kernel only.
Signed-off-by: Prathap M S <msprathap@ti.com>
This adds the function for AM335x SGX device registration using HWMOD APIs.
Also added is omap_device handle creation for SGX module.
This is required for supporting pm_runtime APIs in SGX driver.
This patch is required for 3.2 kernel only.
Signed-off-by: Prathap M S <msprathap@ti.com>
ARM: OMAP: AM33XX: PM: Enable RTC wakeup for standby
Add support for rtc wakeup from standby by keeping RTC module
enabled during standby.
RTC wakeup is corrected in the PG2.0 and hence it is supported
only on PG2.x boards.
To test RTC wakeup use below command:
@ rtcwake -d /dev/rtc0 -m standby -s 5
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Add support for rtc wakeup from standby by keeping RTC module
enabled during standby.
RTC wakeup is corrected in the PG2.0 and hence it is supported
only on PG2.x boards.
To test RTC wakeup use below command:
@ rtcwake -d /dev/rtc0 -m standby -s 5
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
ARM: OMAP2: AM33XX: id: Add support for new AM335x PG2.1 Si
Add support for chip id detection of AM335x PG2.1 Silicon.
Currently omap3xxx_check_revision() detects PG1.0 and PG2.0,
so this patch extends it by adding PG2.1 Si support.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Add support for chip id detection of AM335x PG2.1 Silicon.
Currently omap3xxx_check_revision() detects PG1.0 and PG2.0,
so this patch extends it by adding PG2.1 Si support.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
ARM: OMAP2+: AM33xx: Fix hard conditions check for PG2.0
Currently coupld of instances where code checks only for
PG2.0, which requires change when we add PG2.1 Si support.
So change the condition check from '==' to '>='.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Currently coupld of instances where code checks only for
PG2.0, which requires change when we add PG2.1 Si support.
So change the condition check from '==' to '>='.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
IIO: ti_adc: Fix capture operation during resume.
The ADC needs to go through a proper initialization sequence after
resuming from suspend.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
The ADC needs to go through a proper initialization sequence after
resuming from suspend.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Revert "IIO: ti_adc: Correct wrong samples received on 1st read in continuous mode"
This reverts commit 478af139295b451c59eeba8f851654964321cbfe.
With a proper fix to this code, this is no longer neccessary.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
This reverts commit 478af139295b451c59eeba8f851654964321cbfe.
With a proper fix to this code, this is no longer neccessary.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
IIO: ti_adc: Fix allocation count of FIFO buffer.
Allocating an extra byte is not necessary here. The driver will check
that the allocation is large enough to satisfy the IIO subsystem.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Allocating an extra byte is not necessary here. The driver will check
that the allocation is large enough to satisfy the IIO subsystem.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
IIO: ti_adc: Print error and handle short FIFO events
In the case that the FIFO threshold handler gets called when the
FIFO has not actually reached the threshold, the driver will pass
uninitialized memory to the IIO subsystem.
In the past, this would occur due to bugs in the driver, those bugs
have been fixed. However, it is still a good idea to close this just
in case additional bugs in hardware or software exist.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
In the case that the FIFO threshold handler gets called when the
FIFO has not actually reached the threshold, the driver will pass
uninitialized memory to the IIO subsystem.
In the past, this would occur due to bugs in the driver, those bugs
have been fixed. However, it is still a good idea to close this just
in case additional bugs in hardware or software exist.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
IIO: ti_adc: Properly handle out of memory situation.
If we fail to allocate a buffer, unmask the interrupt to allow a retry.
The interrupt handler will be re-run, and our workqueue rescheduled.
If we are able to allocate memory next time around, everything will
continue as normal, otherwise, we will eventually get an underrun.
Before this patch, the driver would stop capturing without any
indication of error to the IIO subsystem or the user.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
If we fail to allocate a buffer, unmask the interrupt to allow a retry.
The interrupt handler will be re-run, and our workqueue rescheduled.
If we are able to allocate memory next time around, everything will
continue as normal, otherwise, we will eventually get an underrun.
Before this patch, the driver would stop capturing without any
indication of error to the IIO subsystem or the user.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
IIO: ti_adc: Reset and clear overrun status before capture.
While not pulling out samples, the FIFO will fill up causing an
overrun event. Before starting up another continuous sample, clear that
event.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
While not pulling out samples, the FIFO will fill up causing an
overrun event. Before starting up another continuous sample, clear that
event.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
IIO: ti_adc: Also clear threshold event when clearing overrun event
When an overrun occurs, the FIFO is cleared. If a FIFO threshold event
was pending, the data is now gone. Clear the threshold event when
handling an overrun (or underflow).
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
When an overrun occurs, the FIFO is cleared. If a FIFO threshold event
was pending, the data is now gone. Clear the threshold event when
handling an overrun (or underflow).
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
IIO: ti_adc: Avoid double threshold event
The threshold event handler is being called before the FIFO has
actually reached the threshold.
The current code receives a FIFO threshold event, masks the interrupt,
clears the event, and schedules a workqueue. The workqueue is run, it
empties the FIFO, and unmasks the interrupt.
In the above sequence, after the event is cleared, it immediately
retriggers since the FIFO remains beyond the threshold. When the IRQ is
unmasked, this triggered event generates another IRQ. However, as the
FIFO has just been emptied, it is likely to not contain enough samples.
The waits to clear the event until the FIFO has actually been emptied,
in the workqueue. The unmasking and masking of the interrupt remains
unchanged.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
The threshold event handler is being called before the FIFO has
actually reached the threshold.
The current code receives a FIFO threshold event, masks the interrupt,
clears the event, and schedules a workqueue. The workqueue is run, it
empties the FIFO, and unmasks the interrupt.
In the above sequence, after the event is cleared, it immediately
retriggers since the FIFO remains beyond the threshold. When the IRQ is
unmasked, this triggered event generates another IRQ. However, as the
FIFO has just been emptied, it is likely to not contain enough samples.
The waits to clear the event until the FIFO has actually been emptied,
in the workqueue. The unmasking and masking of the interrupt remains
unchanged.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
IIO: ti_adc: Handle overrun before threshold event
If an overrun occurs, the threshold event is meaningless, handle
the overrun event first.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
If an overrun occurs, the threshold event is meaningless, handle
the overrun event first.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
IIO: ti_adc: Handle set to clear IRQSTATUS register properly.
The driver is currently mishandling the IRQSTATUS register by peforming
a read/update/write cycle. The actual functionality of the register is as follows:
Write 0 = No action.
Read 0 = No (enabled) event pending.
Read 1 = Event pending.
Write 1 = Clear (raw) event.
By reading the status and writing it back, the driver is clearing
all pending events, not just the one indicated in the bitmask.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
The driver is currently mishandling the IRQSTATUS register by peforming
a read/update/write cycle. The actual functionality of the register is as follows:
Write 0 = No action.
Read 0 = No (enabled) event pending.
Read 1 = Event pending.
Write 1 = Clear (raw) event.
By reading the status and writing it back, the driver is clearing
all pending events, not just the one indicated in the bitmask.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
IIO: ti_adc: Handle set to clear IRQENABLE register properly.
The driver is currently mishandling the IRQENABLE register. The driver
should write a 1 for bits it wishes to set, and a zero for bits it does not
wish to change. The read of the current register contents is not
necessary.
Write 0 = No action.
Read 0 = Interrupt disabled (masked).
Read 1 = Interrupt enabled.
Write 1 = Enable interrupt.
The current read/update/write method is currently not causing any
problems, but could cause confusion in the future.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
The driver is currently mishandling the IRQENABLE register. The driver
should write a 1 for bits it wishes to set, and a zero for bits it does not
wish to change. The read of the current register contents is not
necessary.
Write 0 = No action.
Read 0 = Interrupt disabled (masked).
Read 1 = Interrupt enabled.
Write 1 = Enable interrupt.
The current read/update/write method is currently not causing any
problems, but could cause confusion in the future.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
IO: ti_adc: Fix step enable and step co nfiguration in continuous mode
The current code does not enable all the input channels asked for.
For example if we want to read continuous data from 3 channels at a
time, the code only enables one channel.
Also the step configuration while switching from one shot to continuous,
configured the 1st input to the rest of the channels as well.
Hence in continuous mode voltage from 1st channel appears on all
the remaining channels. Fix the issue by configuring to correct input
channels.
Signed-off-by: Patil, Rachna <rachna@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
The current code does not enable all the input channels asked for.
For example if we want to read continuous data from 3 channels at a
time, the code only enables one channel.
Also the step configuration while switching from one shot to continuous,
configured the 1st input to the rest of the channels as well.
Hence in continuous mode voltage from 1st channel appears on all
the remaining channels. Fix the issue by configuring to correct input
channels.
Signed-off-by: Patil, Rachna <rachna@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
ARM: OMAP: AM33XX: PM: Fix TSC disable in standby path
Touchscreen once enabled in standby needs to be disabled again.
Writing 0x02 will only re-enable touchscreen. Fix the same by writing
0x00 to the registers.
Signed-off-by: Patil, Rachna <rachna@ti.com>
Touchscreen once enabled in standby needs to be disabled again.
Writing 0x02 will only re-enable touchscreen. Fix the same by writing
0x00 to the registers.
Signed-off-by: Patil, Rachna <rachna@ti.com>
input: ti_tsc: Handle fifo 0 underflow and overflow interrupts
Since TSC is configured to use FIFO 0 to store the touch data,
enable FIFO 0 underflow and overflow interrupts, so that all states of
FIFO can be addressed.
Signed-off-by: Patil, Rachna <rachna@ti.com>
Since TSC is configured to use FIFO 0 to store the touch data,
enable FIFO 0 underflow and overflow interrupts, so that all states of
FIFO can be addressed.
Signed-off-by: Patil, Rachna <rachna@ti.com>
MFD: ti_tscadc: Handle wakeup from touchscreen
Handle wakeup from TSC where in we could have data pending In FIFO
which needs to be flushed out.
Also make sure that we don't have any interrupts pending due to wakeup
from TSC.
Signed-off-by: Patil, Rachna <rachna@ti.com>
Handle wakeup from TSC where in we could have data pending In FIFO
which needs to be flushed out.
Also make sure that we don't have any interrupts pending due to wakeup
from TSC.
Signed-off-by: Patil, Rachna <rachna@ti.com>
input: ti_tsc: Configure TSC to use FIFO 0 only
The MFD device has 2 fifo's FIFO0 and FIFO1.
Previously these FIFO's were shared between touchscreen and ADC.
This led to a situation were in while using TSC, ADC interrupts were
also getting generated. Ideally this should not be the condition.
Hence TSC now has been updated to use FIFO 0 only to store touchscreen
samples.
By this we can even make sure that data between the clients is not lost
and corrupted.
Signed-off-by: Patil, Rachna <rachna@ti.com>
The MFD device has 2 fifo's FIFO0 and FIFO1.
Previously these FIFO's were shared between touchscreen and ADC.
This led to a situation were in while using TSC, ADC interrupts were
also getting generated. Ideally this should not be the condition.
Hence TSC now has been updated to use FIFO 0 only to store touchscreen
samples.
By this we can even make sure that data between the clients is not lost
and corrupted.
Signed-off-by: Patil, Rachna <rachna@ti.com>
IIO: ti_adc: Correct error handling path
The remove module and the error return path missed checks for buffer
management. Add the same in ADC driver.
Signed-off-by: Patil, Rachna <rachna@ti.com>
The remove module and the error return path missed checks for buffer
management. Add the same in ADC driver.
Signed-off-by: Patil, Rachna <rachna@ti.com>
MFD: ti_tscadc: ADC Clock check not required
ADC is ideally expected to work at a frequency of 3MHz.
The present code had a check, which returned error if the frequency
went below the threshold value. But since AM335x supports various
working frequencies, this check is not required.
Now the code just uses the internal ADC clock divider to set the ADC
frequency w.r.t the sys clock.
Signed-off-by: Patil, Rachna <rachna@ti.com>
ADC is ideally expected to work at a frequency of 3MHz.
The present code had a check, which returned error if the frequency
went below the threshold value. But since AM335x supports various
working frequencies, this check is not required.
Now the code just uses the internal ADC clock divider to set the ADC
frequency w.r.t the sys clock.
Signed-off-by: Patil, Rachna <rachna@ti.com>
IIO: ti_adc: Remove unused fifocount variable.
This line was added during debug, missed removing
fifo1count variable. Update the code.
Signed-off-by: Patil, Rachna <rachna@ti.com>
This line was added during debug, missed removing
fifo1count variable. Update the code.
Signed-off-by: Patil, Rachna <rachna@ti.com>
MFD: ti_tscadc: context save for irq added in suspend/resume
The code did not have context save done on IRQ register bits
for the MFD device.
Also the control register bits after resume were loaded to the
default value. Now changes have been made to save both IRQ and control
register bits in MFD core.
In ADC client the mode in which ADC is operating has to store,
hence modify the step_config function to pass the current mode.
Signed-off-by: Patil, Rachna <rachna@ti.com>
The code did not have context save done on IRQ register bits
for the MFD device.
Also the control register bits after resume were loaded to the
default value. Now changes have been made to save both IRQ and control
register bits in MFD core.
In ADC client the mode in which ADC is operating has to store,
hence modify the step_config function to pass the current mode.
Signed-off-by: Patil, Rachna <rachna@ti.com>
IIO: ti_adc: Enabling of IRQ for continuous mode
Since IRQ is a part of continuous mode feature, Enabling should also
take place when continuous data is asked for.
In default mode ADC is configured as one shot, IRQ need not be enabled
if one wants to use one shot mode only.
Signed-off-by: Patil, Rachna <rachna@ti.com>
Since IRQ is a part of continuous mode feature, Enabling should also
take place when continuous data is asked for.
In default mode ADC is configured as one shot, IRQ need not be enabled
if one wants to use one shot mode only.
Signed-off-by: Patil, Rachna <rachna@ti.com>
ARM: OMAP: Don't restore of DMTIMER TISTAT register
The timer TISTAT register is a read-only register and therefore restoring the
context is not needed. Furthermore, the context of TISTAT is never saved
anywhere in the current code. The TISTAT register is read-only for all OMAP
devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register.
[akshay.s@ti.com: Observed a crash when adding support for the
DMTIMER wakeup for standby mode.
This crash occurred during context restore when restoring values
to TIOCP_CFG and TISTAT registers in the function
omap_timer_restore_context().
This issue was fixed in the mainline. So backporting it to fix the same]
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
The timer TISTAT register is a read-only register and therefore restoring the
context is not needed. Furthermore, the context of TISTAT is never saved
anywhere in the current code. The TISTAT register is read-only for all OMAP
devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register.
[akshay.s@ti.com: Observed a crash when adding support for the
DMTIMER wakeup for standby mode.
This crash occurred during context restore when restoring values
to TIOCP_CFG and TISTAT registers in the function
omap_timer_restore_context().
This issue was fixed in the mainline. So backporting it to fix the same]
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
ARM: OMAP2+: dmtimer: remove redundant sysconfig context restore
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.
[akshay.s@ti.com: Observed a warning when adding support for the
DMTIMER wakeup for standby mode.
WARNING: at arch/arm/plat-omap/dmtimer.c:77
omap_dm_timer_write_reg+0x6c/0x74()
This issue was fixed in the mainline. So backporting this patch
to fix the same]
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.
[akshay.s@ti.com: Observed a warning when adding support for the
DMTIMER wakeup for standby mode.
WARNING: at arch/arm/plat-omap/dmtimer.c:77
omap_dm_timer_write_reg+0x6c/0x74()
This issue was fixed in the mainline. So backporting this patch
to fix the same]
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
ARM: OMAP2+: AM33xx: PM: Add support to wakeup via GPIO method for standby
Wakeup from standby mode is supported via GPIO method where peripherals
can be configured as gpios while entering standby and wakeup happens
through gpio interrupt.
This patch provides an method to handle the same through a debugfs
approach.
User should know the IO pads to be configured and the trigger value to
be written to them. The PAD offset & gpio configuration depends mainly
on the wake-up source selected.
Inside <debugfs-mount-dir>/omap_mux/board/ (Directory where these
features are available)
standby_gpio_pad_conf
standby_gpio_pad_conf
Expected input: pinmux_name=<value1>,<trigger>
Pin-mux name that is to be setup as gpio during standby
suspend with gpio interrupt trigger mode as per <trigger> field
with value <value1>.
Pin-mux name should be in "mode0_name.mode7_function_name"
format. Internally the pin-mux offset is calculated from the
pin-mux names. Invalid pin-mux names and values are ignored.
Remember,
- No spaces anywhere in the input.
- <value1> field is a must
- <trigger> field is a must and must be one of "rising",
"falling"
Example:
echo uart0_rxd.gpio1_10=0x27,rising > standby_gpio_pad_conf
sets up uart0_rxd.gpio1_10 for gpio mode with interrupt trigger
as rising and pin-mux value as 0x27 when entering standby mode.
During standby, If "standby_gpio_pad_conf" is configured, then the
respective pin-mux value is saved, the gpio pin-mux mode is selected
for the pin. Relevant gpio settings & interrupts are configured.
During resume, the original values saved are restored back.
User should make sure that the mux mode exists for the selected pin-mux
and the trigger is proper.
When here a duplicate header include (linux/io.h> is removed
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
Wakeup from standby mode is supported via GPIO method where peripherals
can be configured as gpios while entering standby and wakeup happens
through gpio interrupt.
This patch provides an method to handle the same through a debugfs
approach.
User should know the IO pads to be configured and the trigger value to
be written to them. The PAD offset & gpio configuration depends mainly
on the wake-up source selected.
Inside <debugfs-mount-dir>/omap_mux/board/ (Directory where these
features are available)
standby_gpio_pad_conf
standby_gpio_pad_conf
Expected input: pinmux_name=<value1>,<trigger>
Pin-mux name that is to be setup as gpio during standby
suspend with gpio interrupt trigger mode as per <trigger> field
with value <value1>.
Pin-mux name should be in "mode0_name.mode7_function_name"
format. Internally the pin-mux offset is calculated from the
pin-mux names. Invalid pin-mux names and values are ignored.
Remember,
- No spaces anywhere in the input.
- <value1> field is a must
- <trigger> field is a must and must be one of "rising",
"falling"
Example:
echo uart0_rxd.gpio1_10=0x27,rising > standby_gpio_pad_conf
sets up uart0_rxd.gpio1_10 for gpio mode with interrupt trigger
as rising and pin-mux value as 0x27 when entering standby mode.
During standby, If "standby_gpio_pad_conf" is configured, then the
respective pin-mux value is saved, the gpio pin-mux mode is selected
for the pin. Relevant gpio settings & interrupts are configured.
During resume, the original values saved are restored back.
User should make sure that the mux mode exists for the selected pin-mux
and the trigger is proper.
When here a duplicate header include (linux/io.h> is removed
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
ARM: OMAP: AM33XX: PM: Enable GPIO0 wakeup for standby
Keep GPIO0 module enabled during standby to support
GPIO0 io-pads to wakeup the system from standby mode.
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
Keep GPIO0 module enabled during standby to support
GPIO0 io-pads to wakeup the system from standby mode.
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
ARM: OMAP: AM33XX: PM: Enable touch screen wakeup for standby
This patch enables touch screen wakeup from standby by keeping
TSC module enabled during standby.
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
This patch enables touch screen wakeup from standby by keeping
TSC module enabled during standby.
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
ARM: OMAP: AM33XX: PM: Add usb remote wakeup from standby support
This patch adds support for USB remote wakeup from standby mode.
This has been tested as below.
- Connect a USB mouse to EVM.
- Run the following two commands
echo enabled > /sys/bus/usb/devices/1-1/power/wakeup
echo enabled > /sys/bus/usb/devices/usb1/power/wakeup
- Run "echo standby > /sys/power/state"
- Click the mouse to resume from standby
- Also tested for a keyboard key press.
Suggested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
This patch adds support for USB remote wakeup from standby mode.
This has been tested as below.
- Connect a USB mouse to EVM.
- Run the following two commands
echo enabled > /sys/bus/usb/devices/1-1/power/wakeup
echo enabled > /sys/bus/usb/devices/usb1/power/wakeup
- Run "echo standby > /sys/power/state"
- Click the mouse to resume from standby
- Also tested for a keyboard key press.
Suggested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
ARM: OMAP: AM33XX: PM: Add basic standby support
This patch adds basic support for Standby mode
wherein SDRAM is placed in self-refresh,
PLLs are put in bypass and MPU is power gated.
GFX power domain is under user control,
PER power domain is ON.
Wakeup happens via MPU_WAKE interrupt to Cortex-M3.
To enter standby mode, run
"echo standby > /sys/power/state"
Wakeup from standby mode is through gpio.
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
This patch adds basic support for Standby mode
wherein SDRAM is placed in self-refresh,
PLLs are put in bypass and MPU is power gated.
GFX power domain is under user control,
PER power domain is ON.
Wakeup happens via MPU_WAKE interrupt to Cortex-M3.
To enter standby mode, run
"echo standby > /sys/power/state"
Wakeup from standby mode is through gpio.
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
IIO: ti_adc: Handle FIFO1 underflow and Overrun Interrupts
The ADC driver did not check for FIFO1 underflow and overrun
conditions. Add support to handle these conditions.
TSC/ADC module does not recover from this state by itself,
a module reset is required.
Signed-off-by: Patil, Rachna <rachna@ti.com>
The ADC driver did not check for FIFO1 underflow and overrun
conditions. Add support to handle these conditions.
TSC/ADC module does not recover from this state by itself,
a module reset is required.
Signed-off-by: Patil, Rachna <rachna@ti.com>
IIO: ti_adc: Correct wrong samples received on 1st read in continuous mode
ADC reports few wrong/erroneous data on read in continuous mode.
Providing an appropriate delay so that ADC has sufficient time to
sequence data present on the input channel.
Signed-off-by: Patil, Rachna <rachna@ti.com>
ADC reports few wrong/erroneous data on read in continuous mode.
Providing an appropriate delay so that ADC has sufficient time to
sequence data present on the input channel.
Signed-off-by: Patil, Rachna <rachna@ti.com>
ARM: OMAP2+: AM33xx: Enable loss of context callback for mcasp
This patch adds context loss related platform data for mcasp.
This allows mcasp driver to check for the loss of context depending upon
the status it will decide whether to restore or not.
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
This patch adds context loss related platform data for mcasp.
This allows mcasp driver to check for the loss of context depending upon
the status it will decide whether to restore or not.
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
ASoC: McASP: Check for context loss during resume
Context restore is not required when there is no loss of context which
is the case with standby.
This patch adds support to check for loss of context and context restore
is done if there has been a loss of context.
This reduces the overall resume latency of Standby.
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
Context restore is not required when there is no loss of context which
is the case with standby.
This patch adds support to check for loss of context and context restore
is done if there has been a loss of context.
This reduces the overall resume latency of Standby.
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
ARM: OMAP2+: AM33xx: Enable loss of context callback for lcd
This patch adds context loss related platform data for lcd.
This allows lcd driver to check for the loss of context and
depending upon the status it will decide whether to restore or not.
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
This patch adds context loss related platform data for lcd.
This allows lcd driver to check for the loss of context and
depending upon the status it will decide whether to restore or not.
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
video: da8xx-fb: Check for context loss during resume
Context restore is not required when there is no loss of context which is
the case with standby.
This patch adds support for lcd to check for loss of context and
context restore is done if there has been a loss of context.
This reduces the overall resume latency of Standby approximately by
15ms.
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
Context restore is not required when there is no loss of context which is
the case with standby.
This patch adds support for lcd to check for loss of context and
context restore is done if there has been a loss of context.
This reduces the overall resume latency of Standby approximately by
15ms.
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
ARM: OMAP2+: AM33xx: Enable loss of context callback for USB
This patch adds context loss related platform data for USB.
This allows USB driver to check for the loss of context and
depending upon the status it will decide whether to restore or not.
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
This patch adds context loss related platform data for USB.
This allows USB driver to check for the loss of context and
depending upon the status it will decide whether to restore or not.
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
usb: musb: ti81xx: Check for context loss during resume
Context restore is not required when there is no loss of context which
is the case with standby.
This patch adds support to check for loss of context and context restore
is done if there has been a loss of context.
This reduces the overall resume latency of Standby approximately by
200ms.
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
Context restore is not required when there is no loss of context which
is the case with standby.
This patch adds support to check for loss of context and context restore
is done if there has been a loss of context.
This reduces the overall resume latency of Standby approximately by
200ms.
Signed-off-by: Satyanarayana Sandhya <sandhya.satyanarayana@ti.com>
Signed-off-by: ShankarMurthy, Akshay <akshay.s@ti.com>
usb: musb: debugfs: test mode packet fixes
The commit #793ba3e7 moved setting MUSB_CSR0 register out of
musb_load_testpacket(), which breaks generating test packet
through debugfs.
So added the MUSB_CSR0 setting in debugfs.
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Ravi Babu <ravibabu@ti.com>
The commit #793ba3e7 moved setting MUSB_CSR0 register out of
musb_load_testpacket(), which breaks generating test packet
through debugfs.
So added the MUSB_CSR0 setting in debugfs.
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Ravi Babu <ravibabu@ti.com>
davinci_mdio: Fix MDIO timeout check
Under heavy load (flood ping) it is possible for the MDIO timeout to
expire before the loop checks the GO bit again. This patch adds an
additional check whether the operation was done before actually
returning -ETIMEDOUT.
To reproduce this bug, flood ping the device, e.g., ping -f -l 1000
After some time, a "timed out waiting for user access" warning
may appear. And even worse, link may go down since the PHY reported a
timeout.
Signed-off-by: Christian Riesch <christian.riesch@omicron.at>
Cc: <stable@vger.kernel.org>
Cc: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Under heavy load (flood ping) it is possible for the MDIO timeout to
expire before the loop checks the GO bit again. This patch adds an
additional check whether the operation was done before actually
returning -ETIMEDOUT.
To reproduce this bug, flood ping the device, e.g., ping -f -l 1000
After some time, a "timed out waiting for user access" warning
may appear. And even worse, link may go down since the PHY reported a
timeout.
Signed-off-by: Christian Riesch <christian.riesch@omicron.at>
Cc: <stable@vger.kernel.org>
Cc: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
sd: limit the scope of the async probe domain
sd injects and synchronizes probe work on the global kernel-wide domain.
This runs into conflict with PM that wants to perform resume actions in
async context:
[ 494.237079] INFO: task kworker/u:3:554 blocked for more than 120 seconds.
[ 494.294396] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 494.360809] kworker/u:3 D 0000000000000000 0 554 2 0x00000000
[ 494.420739] ffff88012e4d3af0 0000000000000046 ffff88013200c160 ffff88012e4d3fd8
[ 494.484392] ffff88012e4d3fd8 0000000000012500 ffff8801394ea0b0 ffff88013200c160
[ 494.548038] ffff88012e4d3ae0 00000000000001e3 ffffffff81a249e0 ffff8801321c5398
[ 494.611685] Call Trace:
[ 494.632649] [<ffffffff8149dd25>] schedule+0x5a/0x5c
[ 494.674687] [<ffffffff8104b968>] async_synchronize_cookie_domain+0xb6/0x112
[ 494.734177] [<ffffffff810461ff>] ? __init_waitqueue_head+0x50/0x50
[ 494.787134] [<ffffffff8131a224>] ? scsi_remove_target+0x48/0x48
[ 494.837900] [<ffffffff8104b9d9>] async_synchronize_cookie+0x15/0x17
[ 494.891567] [<ffffffff8104ba49>] async_synchronize_full+0x54/0x70 <-- here we wait for async contexts to complete
[ 494.943783] [<ffffffff8104b9f5>] ? async_synchronize_full_domain+0x1a/0x1a
[ 495.002547] [<ffffffffa00114b1>] sd_remove+0x2c/0xa2 [sd_mod]
[ 495.051861] [<ffffffff812fe94f>] __device_release_driver+0x86/0xcf
[ 495.104807] [<ffffffff812fe9bd>] device_release_driver+0x25/0x32 <-- here we take device_lock()
[ 853.511341] INFO: task kworker/u:4:549 blocked for more than 120 seconds.
[ 853.568693] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 853.635119] kworker/u:4 D ffff88013097b5d0 0 549 2 0x00000000
[ 853.695129] ffff880132773c40 0000000000000046 ffff880130790000 ffff880132773fd8
[ 853.758990] ffff880132773fd8 0000000000012500 ffff88013288a0b0 ffff880130790000
[ 853.822796] 0000000000000246 0000000000000040 ffff88013097b5c8 ffff880130790000
[ 853.886633] Call Trace:
[ 853.907631] [<ffffffff8149dd25>] schedule+0x5a/0x5c
[ 853.949670] [<ffffffff8149cc44>] __mutex_lock_common+0x220/0x351
[ 854.001225] [<ffffffff81304bd7>] ? device_resume+0x58/0x1c4
[ 854.049082] [<ffffffff81304bd7>] ? device_resume+0x58/0x1c4
[ 854.097011] [<ffffffff8149ce48>] mutex_lock_nested+0x2f/0x36 <-- here we wait for device_lock()
[ 854.145591] [<ffffffff81304bd7>] device_resume+0x58/0x1c4
[ 854.192066] [<ffffffff81304d61>] async_resume+0x1e/0x45
[ 854.237019] [<ffffffff8104bc93>] async_run_entry_fn+0xc6/0x173 <-- ...while running in async context
Provide a 'scsi_sd_probe_domain' so that async probe actions actions can
be flushed without regard for the state of PM, and allow for the resume
path to handle devices that have transitioned from SDEV_QUIESCE to
SDEV_DEL prior to resume.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
[alan: uplevel scsi_sd_probe_domain, clarify scsi_device_resume]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
[jejb: remove unneeded config guards in include file]
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
sd injects and synchronizes probe work on the global kernel-wide domain.
This runs into conflict with PM that wants to perform resume actions in
async context:
[ 494.237079] INFO: task kworker/u:3:554 blocked for more than 120 seconds.
[ 494.294396] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 494.360809] kworker/u:3 D 0000000000000000 0 554 2 0x00000000
[ 494.420739] ffff88012e4d3af0 0000000000000046 ffff88013200c160 ffff88012e4d3fd8
[ 494.484392] ffff88012e4d3fd8 0000000000012500 ffff8801394ea0b0 ffff88013200c160
[ 494.548038] ffff88012e4d3ae0 00000000000001e3 ffffffff81a249e0 ffff8801321c5398
[ 494.611685] Call Trace:
[ 494.632649] [<ffffffff8149dd25>] schedule+0x5a/0x5c
[ 494.674687] [<ffffffff8104b968>] async_synchronize_cookie_domain+0xb6/0x112
[ 494.734177] [<ffffffff810461ff>] ? __init_waitqueue_head+0x50/0x50
[ 494.787134] [<ffffffff8131a224>] ? scsi_remove_target+0x48/0x48
[ 494.837900] [<ffffffff8104b9d9>] async_synchronize_cookie+0x15/0x17
[ 494.891567] [<ffffffff8104ba49>] async_synchronize_full+0x54/0x70 <-- here we wait for async contexts to complete
[ 494.943783] [<ffffffff8104b9f5>] ? async_synchronize_full_domain+0x1a/0x1a
[ 495.002547] [<ffffffffa00114b1>] sd_remove+0x2c/0xa2 [sd_mod]
[ 495.051861] [<ffffffff812fe94f>] __device_release_driver+0x86/0xcf
[ 495.104807] [<ffffffff812fe9bd>] device_release_driver+0x25/0x32 <-- here we take device_lock()
[ 853.511341] INFO: task kworker/u:4:549 blocked for more than 120 seconds.
[ 853.568693] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 853.635119] kworker/u:4 D ffff88013097b5d0 0 549 2 0x00000000
[ 853.695129] ffff880132773c40 0000000000000046 ffff880130790000 ffff880132773fd8
[ 853.758990] ffff880132773fd8 0000000000012500 ffff88013288a0b0 ffff880130790000
[ 853.822796] 0000000000000246 0000000000000040 ffff88013097b5c8 ffff880130790000
[ 853.886633] Call Trace:
[ 853.907631] [<ffffffff8149dd25>] schedule+0x5a/0x5c
[ 853.949670] [<ffffffff8149cc44>] __mutex_lock_common+0x220/0x351
[ 854.001225] [<ffffffff81304bd7>] ? device_resume+0x58/0x1c4
[ 854.049082] [<ffffffff81304bd7>] ? device_resume+0x58/0x1c4
[ 854.097011] [<ffffffff8149ce48>] mutex_lock_nested+0x2f/0x36 <-- here we wait for device_lock()
[ 854.145591] [<ffffffff81304bd7>] device_resume+0x58/0x1c4
[ 854.192066] [<ffffffff81304d61>] async_resume+0x1e/0x45
[ 854.237019] [<ffffffff8104bc93>] async_run_entry_fn+0xc6/0x173 <-- ...while running in async context
Provide a 'scsi_sd_probe_domain' so that async probe actions actions can
be flushed without regard for the state of PM, and allow for the resume
path to handle devices that have transitioned from SDEV_QUIESCE to
SDEV_DEL prior to resume.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
[alan: uplevel scsi_sd_probe_domain, clarify scsi_device_resume]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
[jejb: remove unneeded config guards in include file]
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
scsi_pm: Fix bug in the SCSI power management handler
This patch (as1520) fixes a bug in the SCSI layer's power management
implementation.
LUN scanning can be carried out asynchronously in do_scan_async(), and
sd uses an asynchronous thread for the time-consuming parts of disk
probing in sd_probe_async(). Currently nothing coordinates these
async threads with system sleep transitions; they can and do attempt
to continue scanning/probing SCSI devices even after the host adapter
has been suspended. As one might expect, the outcome is not ideal.
This is what the "prepare" stage of system suspend was created for.
After the prepare callback has been called for a host, target, or
device, drivers are not allowed to register any children underneath
them. Currently the SCSI prepare callback is not implemented; this
patch rectifies that omission.
For SCSI hosts, the prepare routine calls scsi_complete_async_scans()
to wait until async scanning is finished. It might be slightly more
efficient to wait only until the host in question has been scanned,
but there's currently no way to do that. Besides, during a sleep
transition we will ultimately have to wait until all the host scanning
has finished anyway.
For SCSI devices, the prepare routine calls async_synchronize_full()
to wait until sd probing is finished. The routine does nothing for
SCSI targets, because asynchronous target scanning is done only as
part of host scanning.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
This patch (as1520) fixes a bug in the SCSI layer's power management
implementation.
LUN scanning can be carried out asynchronously in do_scan_async(), and
sd uses an asynchronous thread for the time-consuming parts of disk
probing in sd_probe_async(). Currently nothing coordinates these
async threads with system sleep transitions; they can and do attempt
to continue scanning/probing SCSI devices even after the host adapter
has been suspended. As one might expect, the outcome is not ideal.
This is what the "prepare" stage of system suspend was created for.
After the prepare callback has been called for a host, target, or
device, drivers are not allowed to register any children underneath
them. Currently the SCSI prepare callback is not implemented; this
patch rectifies that omission.
For SCSI hosts, the prepare routine calls scsi_complete_async_scans()
to wait until async scanning is finished. It might be slightly more
efficient to wait only until the host in question has been scanned,
but there's currently no way to do that. Besides, during a sleep
transition we will ultimately have to wait until all the host scanning
has finished anyway.
For SCSI devices, the prepare routine calls async_synchronize_full()
to wait until sd probing is finished. The routine does nothing for
SCSI targets, because asynchronous target scanning is done only as
part of host scanning.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
usb: musb: core: in peripheral mode enter suspend when not connected to host
If MUSB is in peripheral mode system suspend is not allowed if connected
to USB HOST. The suspend should be initiated from USB HOST side.
Signed-off-by: George Cherian <george.cherian@ti.com>
If MUSB is in peripheral mode system suspend is not allowed if connected
to USB HOST. The suspend should be initiated from USB HOST side.
Signed-off-by: George Cherian <george.cherian@ti.com>
usb: musb: cppi41: schedule isochronous transfer using sof interrupt
This fixes the txdma early completion issue for shortpkt
isochronous transfer. Indirectly this fixes audio gap issue in host
and the g_webcam gadget issue for short packet transfer.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
This fixes the txdma early completion issue for shortpkt
isochronous transfer. Indirectly this fixes audio gap issue in host
and the g_webcam gadget issue for short packet transfer.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
usb: musb: ti81xx: rework on babble workaround fix
restart the controller during the babble condition, and
check controller is in host mode by checking occurence of
sof for two frames.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
restart the controller during the babble condition, and
check controller is in host mode by checking occurence of
sof for two frames.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
usb: musb: ti81xx: add api to enable or disable sof
Adding API to enable & disable musb sof interrupts
for ti81xx platform
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Adding API to enable & disable musb sof interrupts
for ti81xx platform
Signed-off-by: Ravi Babu <ravibabu@ti.com>
usb: musb: cppi41: txdma early completion fixes for short transfers
when the usb request len is N * max_epsize + [1 to 128] then there is
chance performing early completion in workthread when [1 to 128] bytes
is still in internal ppu fifo.
In order to avoid this condition, the tx request is split into
two PD, PD1 (len = N * max_ep_size) and PD2 (len <= 128). The
PD1 submitted to txdma input queue, after completion of PD1
the PD2 is submitted.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
when the usb request len is N * max_epsize + [1 to 128] then there is
chance performing early completion in workthread when [1 to 128] bytes
is still in internal ppu fifo.
In order to avoid this condition, the tx request is split into
two PD, PD1 (len = N * max_ep_size) and PD2 (len <= 128). The
PD1 submitted to txdma input queue, after completion of PD1
the PD2 is submitted.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
IIO: ti_adc: Add support for ADC continuous mode
Current ADC driver supports only one shot mode.
Now ADC driver is enhanced to capture data continuously
from /dev/iio:deviceX interface.
ADC is now IRQ based, on interrupt ADC copies data onto
a software buffer, which is exposed to user.
Signed-off-by: Patil, Rachna <rachna@ti.com>
Current ADC driver supports only one shot mode.
Now ADC driver is enhanced to capture data continuously
from /dev/iio:deviceX interface.
ADC is now IRQ based, on interrupt ADC copies data onto
a software buffer, which is exposed to user.
Signed-off-by: Patil, Rachna <rachna@ti.com>
input: ti_tsc: Enable shared IRQ for TSC
Touchscreen and ADC share the same IRQ line from parent
MFD core.
Previously only Touchscreen was interrupt based.
With continuous mode support added in ADC driver, now driver requires
interrupt to process the ADC samples, so enable shared IRQ flag bit for
touchscreen.
Signed-off-by: Patil, Rachna <rachna@ti.com>
Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Touchscreen and ADC share the same IRQ line from parent
MFD core.
Previously only Touchscreen was interrupt based.
With continuous mode support added in ADC driver, now driver requires
interrupt to process the ADC samples, so enable shared IRQ flag bit for
touchscreen.
Signed-off-by: Patil, Rachna <rachna@ti.com>
Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
IIO: ADC: ti_adc: Fix wrong samples received on 1st read
Previously we tried to read data form ADC even before ADC sequencer
finished sampling. This led to wrong samples.
We now wait on ADC status register idle bit to be set.
Signed-off-by: Patil, Rachna <rachna@ti.com>
Previously we tried to read data form ADC even before ADC sequencer
finished sampling. This led to wrong samples.
We now wait on ADC status register idle bit to be set.
Signed-off-by: Patil, Rachna <rachna@ti.com>