8 years agoi2c: Change i2c frequency from 400KHz to 100KHz as per PMIC team recommendation INT_AM438X_EPOS_SDK_02.02.01.02
i2c: Change i2c frequency from 400KHz to 100KHz as per PMIC team recommendation
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
AM437x: Fix for Suspend/Resume functionality with TI-MAGADC.
Added Entry point for runtime suspend operations for MAGADC as well as MFD Driver,
Which will decrement the device's usage count. Then carry out a suspend.
Also added Entry point for runtime resume operations for MAGADC as well as MFD Driver,
Which will increment the device's usage count. Then carry out a resume.
Signed-off-by: Kabir Sahane <x0153567@ti.com>
Added Entry point for runtime suspend operations for MAGADC as well as MFD Driver,
Which will decrement the device's usage count. Then carry out a suspend.
Also added Entry point for runtime resume operations for MAGADC as well as MFD Driver,
Which will increment the device's usage count. Then carry out a resume.
Signed-off-by: Kabir Sahane <x0153567@ti.com>
Revert "AM437x : l3_noc_bus : Clear the standard error log before suspend. L3_GCLK clock is not getting cut off due to error on L3 NOC bus, and system crashes in suspend /resume. and doesn't transition to deep sleep state.After clearing the error log in pre-suspend the L3_GCLK clock is cuts off properly and doesn't get stuck."
This reverts commit 70a7e3d0dea26193ad85cdeb1824b126db38843b.
This reverts commit 70a7e3d0dea26193ad85cdeb1824b126db38843b.
ti-phy: Fix for defaulting phy as ti-phy
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Conflicts:
arch/arm/boot/dts/am43x-epos-evm.dts
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Conflicts:
arch/arm/boot/dts/am43x-epos-evm.dts
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Fixed: Boot issue caused by configuration mismatched b'n device tree and defconfig
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
fixed: The compiler error caused by the cherry-pick
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
ARM: OMAP2+: Use pdata-quirks for sgx deassert_hardreset
Use pdata_quirks to provide platform data to the sgx driver. This is
used to provide a function pointer for the sgx driver to access
omap_device_deassert_hardreset along with the reset name as defined in
the corresponding hwmod entry.
This platform data will not be required when a separate reset driver is
available allowing decoupling from omap_hwmod and omap_device.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Eric Ruei <e-ruei1@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Conflicts:
arch/arm/mach-omap2/pdata-quirks.c
include/linux/platform_data/sgx-omap.h
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Use pdata_quirks to provide platform data to the sgx driver. This is
used to provide a function pointer for the sgx driver to access
omap_device_deassert_hardreset along with the reset name as defined in
the corresponding hwmod entry.
This platform data will not be required when a separate reset driver is
available allowing decoupling from omap_hwmod and omap_device.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Eric Ruei <e-ruei1@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Conflicts:
arch/arm/mach-omap2/pdata-quirks.c
include/linux/platform_data/sgx-omap.h
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
dts:Fixed typo issue with the comments in the main code
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
AM437x : l3_noc_bus : Clear the standard error log before suspend. L3_GCLK clock is not getting cut off due to error on L3 NOC bus, and system crashes in suspend /resume. and doesn't transition to deep sleep state.After clearing the error log in pre-suspend the L3_GCLK clock is cuts off properly and doesn't get stuck.
Signed-off-by: ranjit <x0222357@ti.com>
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Signed-off-by: ranjit <x0222357@ti.com>
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
EPOS: DS0 padconfig optimizations for EPOS EVM
Power consumption of the processor is measured to be ~ 5.5mW
Power Supply Shunt Jumper Shunt [Ohm] Voltage Drop [V] Voltage [V] Current [mA] Power [mW]
VDD_CORE J59 0.05 0.0000944 0.952 1.89 1.80
VDD_MPU J60 0.05 0.0000112 0.954 0.22 0.21
VDDS_DDR J40 0.05 0.0000130 1.204 0.26 0.31
V1_8D_AM437X J83 0.1 0.0001520 1.795 1.52 2.73
V3_3D_AM437X J84 0.1 1.48E-005 3.390 0.15 0.50
Total 5.5551
There are likely a few more pad config tweaks that can be made, but most will
only affect the V3_3D_AM437X rail, which looks fairly good as-is.
DDR_VREF voltage divider resistors were also increased to ~4.4K, resulting in about 0.2mW
savings.
Signed-off-by: Mike Erdahl <m-erdahl@ti.com>
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Conflicts:
arch/arm/boot/dts/am43x-epos-evm.dts
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Power consumption of the processor is measured to be ~ 5.5mW
Power Supply Shunt Jumper Shunt [Ohm] Voltage Drop [V] Voltage [V] Current [mA] Power [mW]
VDD_CORE J59 0.05 0.0000944 0.952 1.89 1.80
VDD_MPU J60 0.05 0.0000112 0.954 0.22 0.21
VDDS_DDR J40 0.05 0.0000130 1.204 0.26 0.31
V1_8D_AM437X J83 0.1 0.0001520 1.795 1.52 2.73
V3_3D_AM437X J84 0.1 1.48E-005 3.390 0.15 0.50
Total 5.5551
There are likely a few more pad config tweaks that can be made, but most will
only affect the V3_3D_AM437X rail, which looks fairly good as-is.
DDR_VREF voltage divider resistors were also increased to ~4.4K, resulting in about 0.2mW
savings.
Signed-off-by: Mike Erdahl <m-erdahl@ti.com>
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Conflicts:
arch/arm/boot/dts/am43x-epos-evm.dts
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Revert "AM43XX: Set cpu idle to no in defconfig for booting and MFD_TI disabled,"
This reverts commit f126ec88b4cb0ec4ca1a797a068003e1b4f78a6c.
With the latest changes for DS0 issue this hack is no longer requiredwq!
This reverts commit f126ec88b4cb0ec4ca1a797a068003e1b4f78a6c.
With the latest changes for DS0 issue this hack is no longer requiredwq!
kbuild: Create directory for target DTB
This fix issue observed with the Yocto build in 64-bit host
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
This fix issue observed with the Yocto build in 64-bit host
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
drm/omap: Add omapdrm plugin API
This work is based on Rob Clark's patch :
http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=commit;h=6a42bc1660b06464f9da796604ecd4934bb31acd
WIP: drm/omap: V2: add plugin API
from the GLP kernel tree available at
http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=summary
Omapdrm is fixed so that it can accept plugins.
Plugin add functions like load/unload etc are added in omap_drv.c
In omap_gem.c GEM object mapping functions has been added
This patch is required for gfx driver to be built as a drm plugin
Subhajit : k3.12: removed const from ioctls table
Anand : k3.14 : rebased with LCPD baseline
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Conflicts:
drivers/gpu/drm/omapdrm/omap_drv.c
drivers/gpu/drm/omapdrm/omap_drv.h
Change-Id: I72133ad08ddd4682320fa2e7f5f4dd017ee92dae
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
This work is based on Rob Clark's patch :
http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=commit;h=6a42bc1660b06464f9da796604ecd4934bb31acd
WIP: drm/omap: V2: add plugin API
from the GLP kernel tree available at
http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=summary
Omapdrm is fixed so that it can accept plugins.
Plugin add functions like load/unload etc are added in omap_drv.c
In omap_gem.c GEM object mapping functions has been added
This patch is required for gfx driver to be built as a drm plugin
Subhajit : k3.12: removed const from ioctls table
Anand : k3.14 : rebased with LCPD baseline
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Conflicts:
drivers/gpu/drm/omapdrm/omap_drv.c
drivers/gpu/drm/omapdrm/omap_drv.h
Change-Id: I72133ad08ddd4682320fa2e7f5f4dd017ee92dae
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
drm/omap: Add support for render nodes
Add support for render nodes in omap driver and allow required
ioctls to be accessible via render nodes.
Change-Id: Ia7b69f797d72b85442eb34401ead71d79297cc3d
Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
Add support for render nodes in omap driver and allow required
ioctls to be accessible via render nodes.
Change-Id: Ia7b69f797d72b85442eb34401ead71d79297cc3d
Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
AM43XX: Set cpu idle to no in defconfig for booting and MFD_TI disabled,
For PM
Signed-off-by: ranjit <x0222357@ti.com>
For PM
Signed-off-by: ranjit <x0222357@ti.com>
Merge branch 'ti-linux-kernel-new' into int_epos_linux_02.02.x
Conflicts:
arch/arm/mach-omap2/pm33xx.c
arch/arm/mach-omap2/sleep43xx.S
Conflicts:
arch/arm/mach-omap2/pm33xx.c
arch/arm/mach-omap2/sleep43xx.S
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
OMAPDSS: HDMI: Do not abort audio playback when display is turned off
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
OMAPDSS: HDMI: Do not abort audio playback when display is turned off
Signed-off-by: Dan Murphy <DMurphy@ti.com>
Merge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree into ti-linux-3.14.y
TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y
* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
ARM: dts: am437x-sk-evm: Reduce i2c0 bus speed for tps65218
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y
* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
ARM: dts: am437x-sk-evm: Reduce i2c0 bus speed for tps65218
Signed-off-by: Dan Murphy <DMurphy@ti.com>
ARM: dts: am437x-sk-evm: Reduce i2c0 bus speed for tps65218
Based on the latest timing specifications for the TPS65218 from the data
sheet, http://www.ti.com/lit/ds/symlink/tps65218.pdf, document SLDS206
from November 2014, we must change the i2c bus speed to better fit within
the minimum high SCL time required for proper i2c transfer.
When running at 400khz, measurements show that SCL spends
0.8125 uS/1.666 uS high/low which violates the requirement for minimum
high period of SCL provided in datasheet Table 7.6 which is 1 uS.
Switching to 100khz gives us 5 uS/5 uS high/low which both fall above
the minimum given values for 100 khz, 4.0 uS/4.7 uS high/low.
Without this patch occasionally a voltage set operation from the kernel
will appear to have worked but the actual voltage reflected on the PMIC
will not have updated, causing problems especially with cpufreq that may
update to a higher OPP without actually raising the voltage on DCDC2,
leading to a hang.
Based on debug effort by Nishanth Menon, Felipe Balbi, Aparna
Balasubramanian, Franklin Cooper, and Dave Gerlach.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Based on the latest timing specifications for the TPS65218 from the data
sheet, http://www.ti.com/lit/ds/symlink/tps65218.pdf, document SLDS206
from November 2014, we must change the i2c bus speed to better fit within
the minimum high SCL time required for proper i2c transfer.
When running at 400khz, measurements show that SCL spends
0.8125 uS/1.666 uS high/low which violates the requirement for minimum
high period of SCL provided in datasheet Table 7.6 which is 1 uS.
Switching to 100khz gives us 5 uS/5 uS high/low which both fall above
the minimum given values for 100 khz, 4.0 uS/4.7 uS high/low.
Without this patch occasionally a voltage set operation from the kernel
will appear to have worked but the actual voltage reflected on the PMIC
will not have updated, causing problems especially with cpufreq that may
update to a higher OPP without actually raising the voltage on DCDC2,
leading to a hang.
Based on debug effort by Nishanth Menon, Felipe Balbi, Aparna
Balasubramanian, Franklin Cooper, and Dave Gerlach.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
OMAPDSS: HDMI: Do not abort audio playback when display is turned off
Do not abort audio playback when display is turned off. The audio DMA
stops when the display turned off and the audio stream will timeout in
couple of seconds unless the display is enabled again in time. Without
this patch the audio playback is aborted immediately when display is
turned off.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Do not abort audio playback when display is turned off. The audio DMA
stops when the display turned off and the audio stream will timeout in
couple of seconds unless the display is enabled again in time. Without
this patch the audio playback is aborted immediately when display is
turned off.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y
* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
ARM: DRA7: GMAC: Apply Errata i877
ARM: OMAP2+: GMAC: Fix clock domain flags
ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property
Signed-off-by: Dan Murphy <dmurphy@ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y
* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
ARM: DRA7: GMAC: Apply Errata i877
ARM: OMAP2+: GMAC: Fix clock domain flags
ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property
Signed-off-by: Dan Murphy <dmurphy@ti.com>
ARM: DRA7: GMAC: Apply Errata i877
Errata ID: i877
Description:
The RGMII Transmit timing is based on the output clock (rgmiin_txc) being
driven relative to the rising edge of an internal clock and the output
control/data (rgmiin_txctl/txd) being driven relative to the falling edge
of an internal clock source. If the internal clock source is allowed to be
static low (i.e., disabled) for an extended period of time then when the
clock is actually enabled the timing delta between the rising edge and
falling edge can change over the lifetime of the device. This can result
in the device switching characteristics degrading over time, and
eventually failing to meet the Data Manual Delay Time/Skew specs.
To maintain RGMII IO Timings, SW should minimize the duration that the
Ethernet internal clock source is disabled. Note that the device reset
state for the Ethernet clock is "disabled".
Workaround:
If the SoC Ethernet interface(s) are used in RGMII mode, SW should minimize
the time the Ethernet internal clock source is disabled to a maximum of
200 hours in a device life cycle. This is done by enabling the clock as
early as possible in IPL (QNX) or SPL/u-boot (Linux/Android) by setting
the register CM_GMAC_CLKSTCTRL[1:0]CLKTRCTRL = 0x2:SW_WKUP.
In addition to programming SW_WKUP(0x2) on CM_GMAC_CLKSTCTRL, SW should
also program modulemode field as ENABLED(0x2) on CM_GMAC_GMAC_CLKCTRL
register.
Note that this erratum applies only when device may need to be used
for 1Gbit operation.
Since the POR is to use 1GB mode, enabling this errata by hooking
ti,no-idle flag to gmac node.
Acked-by: Roger Quadros <rogerq@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Errata ID: i877
Description:
The RGMII Transmit timing is based on the output clock (rgmiin_txc) being
driven relative to the rising edge of an internal clock and the output
control/data (rgmiin_txctl/txd) being driven relative to the falling edge
of an internal clock source. If the internal clock source is allowed to be
static low (i.e., disabled) for an extended period of time then when the
clock is actually enabled the timing delta between the rising edge and
falling edge can change over the lifetime of the device. This can result
in the device switching characteristics degrading over time, and
eventually failing to meet the Data Manual Delay Time/Skew specs.
To maintain RGMII IO Timings, SW should minimize the duration that the
Ethernet internal clock source is disabled. Note that the device reset
state for the Ethernet clock is "disabled".
Workaround:
If the SoC Ethernet interface(s) are used in RGMII mode, SW should minimize
the time the Ethernet internal clock source is disabled to a maximum of
200 hours in a device life cycle. This is done by enabling the clock as
early as possible in IPL (QNX) or SPL/u-boot (Linux/Android) by setting
the register CM_GMAC_CLKSTCTRL[1:0]CLKTRCTRL = 0x2:SW_WKUP.
In addition to programming SW_WKUP(0x2) on CM_GMAC_CLKSTCTRL, SW should
also program modulemode field as ENABLED(0x2) on CM_GMAC_GMAC_CLKCTRL
register.
Note that this erratum applies only when device may need to be used
for 1Gbit operation.
Since the POR is to use 1GB mode, enabling this errata by hooking
ti,no-idle flag to gmac node.
Acked-by: Roger Quadros <rogerq@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: OMAP2+: GMAC: Fix clock domain flags
According to AM57x TRM, Document SPRUHZ6, Revised October 2014,
Table 3-1021, SW_SLEEP and HW_AUTO must not be programmed for
gmac clock domain. And also as per the the Errata i877, gmac clock
domain should always be kept in SW_WKUP.
So making the gmac clock domain flag as SWSUP.
AM57x TRM can be found here: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
According to AM57x TRM, Document SPRUHZ6, Revised October 2014,
Table 3-1021, SW_SLEEP and HW_AUTO must not be programmed for
gmac clock domain. And also as per the the Errata i877, gmac clock
domain should always be kept in SW_WKUP.
So making the gmac clock domain flag as SWSUP.
AM57x TRM can be found here: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property
Introduce a dt property, ti,no-idle, that prevents an IP to idle at any
point. This is to handle Errata i877, which tells that GMAC clocks
cannot be disabled.
Acked-by: Roger Quadros <rogerq@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Introduce a dt property, ti,no-idle, that prevents an IP to idle at any
point. This is to handle Errata i877, which tells that GMAC clocks
cannot be disabled.
Acked-by: Roger Quadros <rogerq@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
media: ti-vpe: vpdma/vip/vpe: Fix race condition for firmware loading
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
media: ti-vpe: vpdma/vip/vpe: Fix race condition for firmware loading
Signed-off-by: Dan Murphy <DMurphy@ti.com>
media: ti-vpe: vpdma/vip/vpe: Fix race condition for firmware loading
vpdma_create API is supposed to allocated the struct vpdma_data and
return it to the driver. Also, it would call the callback function
when the VPDMA firmware is loaded.
Typically, VIP VPE drivers have following function call:
dev->vpdma = vpdma_create(pdev, firmware_load_callback);
And the callback implementation would continue the probe further.
Also, the dev->vpdma is accessed from the callback implementation.
This may lead to race condition between assignment of dev->vpdma
and the callback function being triggered.
This would lead to kernel crash because of NULL pointer access.
Fix this by passing a driver wrapped &vpdma_data instead of allocating
inside vpdma_create.
Change the vpdma_create prototype accordingly and fix return paths.
Also, update the VIP and VPE driver to use the updated API and
initialize the dev->vpdma before hand so that the race condition
is avoided.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
vpdma_create API is supposed to allocated the struct vpdma_data and
return it to the driver. Also, it would call the callback function
when the VPDMA firmware is loaded.
Typically, VIP VPE drivers have following function call:
dev->vpdma = vpdma_create(pdev, firmware_load_callback);
And the callback implementation would continue the probe further.
Also, the dev->vpdma is accessed from the callback implementation.
This may lead to race condition between assignment of dev->vpdma
and the callback function being triggered.
This would lead to kernel crash because of NULL pointer access.
Fix this by passing a driver wrapped &vpdma_data instead of allocating
inside vpdma_create.
Change the vpdma_create prototype accordingly and fix return paths.
Also, update the VIP and VPE driver to use the updated API and
initialize the dev->vpdma before hand so that the race condition
is avoided.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y
* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
mmc: host: omap_hsmmc: Fix DTO and DCRC handling
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y
* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
mmc: host: omap_hsmmc: Fix DTO and DCRC handling
Signed-off-by: Dan Murphy <DMurphy@ti.com>
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
drm/omap: ensure all displays have been probed
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
drm/omap: ensure all displays have been probed
Signed-off-by: Dan Murphy <DMurphy@ti.com>
mmc: host: omap_hsmmc: Fix DTO and DCRC handling
DTO/DCRC errors were not being informed to the mmc core since
commit ae4bf788ee ("mmc: omap_hsmmc: consolidate error report handling of
iHSMMC IRQ"). This commit made sure 'end_trans' is never set on DTO/DCRC
errors. This is because after this commit 'host->data' is checked after
it has been cleared to NULL by omap_hsmmc_dma_cleanup().
Because 'end_trans' is never set, omap_hsmmc_xfer_done() is never invoked
making core layer not to be aware of DTO/DCRC errors. Because of this
any command invoked after DTO/DCRC error leads to a hang.
Fix this by checking for 'host->data' before it is actually cleared.
Fixes: ae4bf788ee ("mmc: omap_hsmmc: consolidate error report handling of
iHSMMC IRQ")
Reported-by: Yan Liu <yan-liu@ti.com>
Tested-by: Yan Liu <yan-liu@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
DTO/DCRC errors were not being informed to the mmc core since
commit ae4bf788ee ("mmc: omap_hsmmc: consolidate error report handling of
iHSMMC IRQ"). This commit made sure 'end_trans' is never set on DTO/DCRC
errors. This is because after this commit 'host->data' is checked after
it has been cleared to NULL by omap_hsmmc_dma_cleanup().
Because 'end_trans' is never set, omap_hsmmc_xfer_done() is never invoked
making core layer not to be aware of DTO/DCRC errors. Because of this
any command invoked after DTO/DCRC error leads to a hang.
Fix this by checking for 'host->data' before it is actually cleared.
Fixes: ae4bf788ee ("mmc: omap_hsmmc: consolidate error report handling of
iHSMMC IRQ")
Reported-by: Yan Liu <yan-liu@ti.com>
Tested-by: Yan Liu <yan-liu@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
drm/omap: ensure all displays have been probed
DRM offers no ways to add new displays after the DRM driver has been
loaded. This causes issues on boards that have multiple displays, and
omapdrm is loaded when some of them are loaded but not all. The result
is that omapdrm starts with the displays that were loaded at that time,
ignoring the displays loaded later.
This patch changes the behavior so that omapdrm ensures all display are
loaded which have an alias in the .dts file.
The downside is that this prevents omapdrm from loading if, say, the
user has not compiled a kernel module for one of the displays, or
there's some kind of failure in one of the displays. Thus, after this
patch, all the displays have to work, or none does.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
DRM offers no ways to add new displays after the DRM driver has been
loaded. This causes issues on boards that have multiple displays, and
omapdrm is loaded when some of them are loaded but not all. The result
is that omapdrm starts with the displays that were loaded at that time,
ignoring the displays loaded later.
This patch changes the behavior so that omapdrm ensures all display are
loaded which have an alias in the .dts file.
The downside is that this prevents omapdrm from loading if, say, the
user has not compiled a kernel module for one of the displays, or
there's some kind of failure in one of the displays. Thus, after this
patch, all the displays have to work, or none does.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Merge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-3.14.y
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-3.14.y
* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
ARM: DRA7: hwmod: Fix gpmc hwmod
Conflicts:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-3.14.y
* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
ARM: DRA7: hwmod: Fix gpmc hwmod
Conflicts:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c
Signed-off-by: Dan Murphy <DMurphy@ti.com>
ARM: DRA7: hwmod: Fix gpmc hwmod
GPMC does not support smart idle with wakeup.
Instead of removing SIDLE_SMART_WKUP for gpmc, it was removed for
ocp2scp by mistake. Fix it.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
GPMC does not support smart idle with wakeup.
Instead of removing SIDLE_SMART_WKUP for gpmc, it was removed for
ocp2scp by mistake. Fix it.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Merge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree into ti-linux-3.14.y
TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y
* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
ARM: OMAP2+: AMX3XX: Add HWMOD_NEEDS_REIDLE to gpmc
ARM: OMAP2+: omap_hwmod: Reidle flagged hwmods when restoring context
ARM: OMAP2+: omap_hwmod: Add softreset to _reidle
ARM: OMAP2+: omap_hwmod: Refactor HWMOD_NEEDS_REIDLE support code
ARM: OMAP2+: omap_hwmod: Always restore saved hardreset context
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y
* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
ARM: OMAP2+: AMX3XX: Add HWMOD_NEEDS_REIDLE to gpmc
ARM: OMAP2+: omap_hwmod: Reidle flagged hwmods when restoring context
ARM: OMAP2+: omap_hwmod: Add softreset to _reidle
ARM: OMAP2+: omap_hwmod: Refactor HWMOD_NEEDS_REIDLE support code
ARM: OMAP2+: omap_hwmod: Always restore saved hardreset context
Signed-off-by: Dan Murphy <DMurphy@ti.com>
ARM: OMAP2+: AMX3XX: Add HWMOD_NEEDS_REIDLE to gpmc
gpmc hwmod on am43xx needs a softreset before idling, so add the
HWMOD_NEEDS_REIDLE flag so that in the case of no driver being present,
the module will get properly reidled and shut off after a suspend cycle
or when attempting to disable it after an RTC+DDR cycle.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
gpmc hwmod on am43xx needs a softreset before idling, so add the
HWMOD_NEEDS_REIDLE flag so that in the case of no driver being present,
the module will get properly reidled and shut off after a suspend cycle
or when attempting to disable it after an RTC+DDR cycle.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: omap_hwmod: Reidle flagged hwmods when restoring context
After the PRCM loses context in the case of an RTC+DDR cycle omap_hwmod
attempts to return all hwmods to their previous state, however as
indicated in patch c388763a9c88 ("ARM: OMAP2+: omap_hwmod: Introduce
HWMOD_NEEDS_REIDLE"), certain hwmods cannot just be disabled when in
their default state, which is why they need the special handling present
in that patch when no driver is present.
In RTC+DDR mode, even if all drivers are present, the modules are all
returned to their previous state before any driver resume happens so we
will still face the issue described above. This can be prevented by
calling _reidle on all hwmods that need it for any module that is being
disabled to return to it's previous state.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
After the PRCM loses context in the case of an RTC+DDR cycle omap_hwmod
attempts to return all hwmods to their previous state, however as
indicated in patch c388763a9c88 ("ARM: OMAP2+: omap_hwmod: Introduce
HWMOD_NEEDS_REIDLE"), certain hwmods cannot just be disabled when in
their default state, which is why they need the special handling present
in that patch when no driver is present.
In RTC+DDR mode, even if all drivers are present, the modules are all
returned to their previous state before any driver resume happens so we
will still face the issue described above. This can be prevented by
calling _reidle on all hwmods that need it for any module that is being
disabled to return to it's previous state.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: omap_hwmod: Add softreset to _reidle
Certain hwmods, like gpmc on am437x, require a softreset in order for
them to go idle. Add a call to omap_hwmod_softreset in our _reidle path
so that hwmods that must be reidled will have a software reset performed
on them before attempting to actually idle them.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Certain hwmods, like gpmc on am437x, require a softreset in order for
them to go idle. Add a call to omap_hwmod_softreset in our _reidle path
so that hwmods that must be reidled will have a software reset performed
on them before attempting to actually idle them.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: omap_hwmod: Refactor HWMOD_NEEDS_REIDLE support code
Refactor the _reidle_all function introduced by c388763a9c88 ("ARM:
OMAP2+: omap_hwmod: Introduce HWMOD_NEEDS_REIDLE") to use a _reidle
function that can reidle single omap_hwmods so that we are able to
call this for single hwmods rather than running it for the
oh_reidle_list.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Refactor the _reidle_all function introduced by c388763a9c88 ("ARM:
OMAP2+: omap_hwmod: Introduce HWMOD_NEEDS_REIDLE") to use a _reidle
function that can reidle single omap_hwmods so that we are able to
call this for single hwmods rather than running it for the
oh_reidle_list.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: omap_hwmod: Always restore saved hardreset context
Previously when restoring hardreset context during
omap_hwmod_restore_context we would only deassert the hardreset lines if
the module was previously active, however, if a hwmod has all hardresets
asserted then _enable will return without actually enabling the module.
This is a problem for the gfx hwmod on am437x as it gets disabled in
suspend path so it appears as disabled to the restore context code but
then during the attempted enable call during the regular kernel resume
path, the hwmod cannot actually be enabled.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Previously when restoring hardreset context during
omap_hwmod_restore_context we would only deassert the hardreset lines if
the module was previously active, however, if a hwmod has all hardresets
asserted then _enable will return without actually enabling the module.
This is a problem for the gfx hwmod on am437x as it gets disabled in
suspend path so it appears as disabled to the restore context code but
then during the attempted enable call during the regular kernel resume
path, the hwmod cannot actually be enabled.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Merge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-3.14.y
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-3.14.y
* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
ARM: DRA7: hwmod: Fix GPMC from preventing core suspend
ARM: DRA7: hwmod: fix gpmc hwmod
Conflicts:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-3.14.y
* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
ARM: DRA7: hwmod: Fix GPMC from preventing core suspend
ARM: DRA7: hwmod: fix gpmc hwmod
Conflicts:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c
Signed-off-by: Dan Murphy <DMurphy@ti.com>
ARM: DRA7: hwmod: Fix GPMC from preventing core suspend
GPMC hwmod is flagged as HWMOD_INIT_NO_IDLE so it is kept
enabled at boot. If the GPMC driver is not loaded then
GPMC will not be idled thus preventing CORE from going idle
during suspend.
Disable HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET.
The only reason HWMOD_INIT_NO_RESET was there was to retain
GPMC timings/settings configured by bootloader. We no longer
need that as we're configuring the timins in the kernel.
There is no reasoning as to why HWMOD_INIT_NO_IDLE was there.
Seems to have beein blindly copied from omap3/4 hwmod code.
Signed-off-by: Roger Quadros <rogerq@ti.com>
GPMC hwmod is flagged as HWMOD_INIT_NO_IDLE so it is kept
enabled at boot. If the GPMC driver is not loaded then
GPMC will not be idled thus preventing CORE from going idle
during suspend.
Disable HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET.
The only reason HWMOD_INIT_NO_RESET was there was to retain
GPMC timings/settings configured by bootloader. We no longer
need that as we're configuring the timins in the kernel.
There is no reasoning as to why HWMOD_INIT_NO_IDLE was there.
Seems to have beein blindly copied from omap3/4 hwmod code.
Signed-off-by: Roger Quadros <rogerq@ti.com>
ARM: DRA7: hwmod: fix gpmc hwmod
GPMC smart idle is not really broken but it does not support
smart idle with wakeup.
Fixes: 3a85559fcf34d ("ARM: OMAP: DRA7: hwmod: Make gpmc software supervised as the smart idle is broken")
Signed-off-by: Roger Quadros <rogerq@ti.com>
GPMC smart idle is not really broken but it does not support
smart idle with wakeup.
Fixes: 3a85559fcf34d ("ARM: OMAP: DRA7: hwmod: Make gpmc software supervised as the smart idle is broken")
Signed-off-by: Roger Quadros <rogerq@ti.com>
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
media: ti-vpe: vip: Fix input/std/parm reporting
media: ti-vpe: VIP/VPE/VPDMA: Correction of data type label.
media: ti-vpe: vip: Fix format negotiation with sub-device
OMAPDSS: dra7-tpd12s015: fix dependency to mcasp
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
media: ti-vpe: vip: Fix input/std/parm reporting
media: ti-vpe: VIP/VPE/VPDMA: Correction of data type label.
media: ti-vpe: vip: Fix format negotiation with sub-device
OMAPDSS: dra7-tpd12s015: fix dependency to mcasp
Signed-off-by: Dan Murphy <DMurphy@ti.com>
media: ti-vpe: vip: Fix input/std/parm reporting
v4l2-compliance was reporting errors and warning wrt
s/g/enum input, s/g/query std and s/g parm ioctl.
These currently return static values but were incomplete
causing the errors and warnings.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
v4l2-compliance was reporting errors and warning wrt
s/g/enum input, s/g/query std and s/g parm ioctl.
These currently return static values but were incomplete
causing the errors and warnings.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
media: ti-vpe: VIP/VPE/VPDMA: Correction of data type label.
The YUV data type definition below are taken from
both the TRM and i839 Errata information.
Use the correct data type considering byte
reordering of components.
Also since the single use of "C" in the 422 case
to mean "Cr" (i.e. V component). It was decided
to explictly label them CR to remove any confusion.
Bear in mind that the type label refer to the memory
packed order (LSB - MSB).
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
The YUV data type definition below are taken from
both the TRM and i839 Errata information.
Use the correct data type considering byte
reordering of components.
Also since the single use of "C" in the 422 case
to mean "Cr" (i.e. V component). It was decided
to explictly label them CR to remove any confusion.
Bear in mind that the type label refer to the memory
packed order (LSB - MSB).
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
media: ti-vpe: vip: Fix format negotiation with sub-device
As recently understood VIP only expect the input format to be in UYVY form.
Commit b74d2ff "YUV422 data is not interpreted correctly" was attempting
to allow all of the various subdevice supported bus format to be used
as input format to VIP. Unfortunately this is having side effect
when trying to convert any of these various input formats to NV12
for example. In order to have VIP generate the correct/expected
output format for instance UYVY, YUYV or NV12 the input data coming
from the sub-device must be in UYVY format.
As a result VIP will now expect the sub-device to support UYVY
and will be able to support at least:
- YUV422 UYVY
- YUV422 YUYV
- YUV422 VYUY
- YUV422 YVYU
- YUV420 NV12
Also v4l2-compliance was reporting errors and warning wrt
s/g/try fmt ioctl.
The errors were caused by mis-handling of invalid format details
which would generates error return codes.
These calls are not supposed to fail on invalid input.
Instead they are supposed to return a valid configuration
instead of an error as per v4l2-compliance tests.
Reworked g_fmt, s_fmt and try_fmt to simplify/streamlined them
Reworked the subdev fmt enumeration on subdev discovery.
Added subdev g_fmt call on device open to provide a valid initial format.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
As recently understood VIP only expect the input format to be in UYVY form.
Commit b74d2ff "YUV422 data is not interpreted correctly" was attempting
to allow all of the various subdevice supported bus format to be used
as input format to VIP. Unfortunately this is having side effect
when trying to convert any of these various input formats to NV12
for example. In order to have VIP generate the correct/expected
output format for instance UYVY, YUYV or NV12 the input data coming
from the sub-device must be in UYVY format.
As a result VIP will now expect the sub-device to support UYVY
and will be able to support at least:
- YUV422 UYVY
- YUV422 YUYV
- YUV422 VYUY
- YUV422 YVYU
- YUV420 NV12
Also v4l2-compliance was reporting errors and warning wrt
s/g/try fmt ioctl.
The errors were caused by mis-handling of invalid format details
which would generates error return codes.
These calls are not supposed to fail on invalid input.
Instead they are supposed to return a valid configuration
instead of an error as per v4l2-compliance tests.
Reworked g_fmt, s_fmt and try_fmt to simplify/streamlined them
Reworked the subdev fmt enumeration on subdev discovery.
Added subdev g_fmt call on device open to provide a valid initial format.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
OMAPDSS: dra7-tpd12s015: fix dependency to mcasp
The recent changes to dra7-tpd12s015 driver require mcasp, but it was
not expressed in the Kconfig, leading to errors like:
drivers/built-in.o: In function `hdmi_i2c2_hack_demux':
linux/git/drivers/video/fbdev/omap2/displays-new/dra7-evm-encoder-tpd12s015.c:117:
undefined reference to `dra7_mcasp_hdmi_gpio_set'
Add dependency to SND_DAVINCI_SOC_MCASP.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
The recent changes to dra7-tpd12s015 driver require mcasp, but it was
not expressed in the Kconfig, leading to errors like:
drivers/built-in.o: In function `hdmi_i2c2_hack_demux':
linux/git/drivers/video/fbdev/omap2/displays-new/dra7-evm-encoder-tpd12s015.c:117:
undefined reference to `dra7_mcasp_hdmi_gpio_set'
Add dependency to SND_DAVINCI_SOC_MCASP.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y
* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
usb: dwc3: core: don't break during suspend/resume while we're dual-role
usb: dwc3: core: Prevent otg events from disabling themselves
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y
* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
usb: dwc3: core: don't break during suspend/resume while we're dual-role
usb: dwc3: core: Prevent otg events from disabling themselves
Signed-off-by: Dan Murphy <DMurphy@ti.com>
Merge branch 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into ti-linux-3.14.y
TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-3.14.y
* 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
samples/rpmsg: add support for multiple instances
Revert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
iommu/omap: add pdata ops for setting powerdomain constraint
ARM: dts: OMAP5: Fix the standby info for IPU & DSP
remoteproc/omap: revise the comment about standby in _suspend
remoteproc/pruss: fix pruss_init return on error
remoteproc/pruss: lower the trace level in pru_rproc_mbox_callback
remoteproc/omap: fix a minor typo in a trace message
remoteproc/omap: add support for runtime auto-suspend/resume
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-3.14.y
* 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
samples/rpmsg: add support for multiple instances
Revert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
iommu/omap: add pdata ops for setting powerdomain constraint
ARM: dts: OMAP5: Fix the standby info for IPU & DSP
remoteproc/omap: revise the comment about standby in _suspend
remoteproc/pruss: fix pruss_init return on error
remoteproc/pruss: lower the trace level in pru_rproc_mbox_callback
remoteproc/omap: fix a minor typo in a trace message
remoteproc/omap: add support for runtime auto-suspend/resume
Signed-off-by: Dan Murphy <DMurphy@ti.com>
Merge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-3.14.y
Pull in a minor enhancement to the rpmsg_client_sample driver to support
multiple instances. This will allow the driver to communicate to each
instance that may be present on different remote processors.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
samples/rpmsg: add support for multiple instances
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in a minor enhancement to the rpmsg_client_sample driver to support
multiple instances. This will allow the driver to communicate to each
instance that may be present on different remote processors.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
samples/rpmsg: add support for multiple instances
Signed-off-by: Suman Anna <s-anna@ti.com>
samples/rpmsg: add support for multiple instances
The current rpmsg_client_sample is a very simple example and
is not designed to handle multiple instances. Add support for
multiple instances, so that the same number of pings are sent
to each instance. The instances can be on one or multiple
remote processors.
Signed-off-by: Suman Anna <s-anna@ti.com>
The current rpmsg_client_sample is a very simple example and
is not designed to handle multiple instances. Add support for
multiple instances, so that the same number of pings are sent
to each instance. The instances can be on one or multiple
remote processors.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in the updated remoteproc feature branch that includes the
necessary support to fix the DRA7 IPU1 boot issue when integrated
with PM tree or TI Integration kernel. The merge also syncs up
the RPMsg integration branch with the latest platform base code.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc: (132 commits)
Revert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
iommu/omap: add pdata ops for setting powerdomain constraint
ARM: dts: OMAP5: Fix the standby info for IPU & DSP
ARM: OMAP: Check for clocks which do not have parents
ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
ARM: dts: DRA7: Add DT node for AES2 IP
ARM: DRA7: hwmod: Add data for AES2 IP
crypto: omap-aes - Add support for multiple cores
crypto: omap-aes - Fix registration of Algos
crypto: omap-aes - Fix enabling clocks
crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
crypto: omap-aes - Add support for GCM mode
crypto: omap-aes - Fix configuring of AES mode
crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
crypto: omap-des: Fix unmapping of dma channels
dmaenegine: edma: allow pause/resume for non-cyclic mode
ARM: common: edma: clear completion interrupts on stop
bus: omap_l3_noc: Fix master id address decoding for OMAP5
...
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that includes the
necessary support to fix the DRA7 IPU1 boot issue when integrated
with PM tree or TI Integration kernel. The merge also syncs up
the RPMsg integration branch with the latest platform base code.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc: (132 commits)
Revert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
iommu/omap: add pdata ops for setting powerdomain constraint
ARM: dts: OMAP5: Fix the standby info for IPU & DSP
ARM: OMAP: Check for clocks which do not have parents
ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
ARM: dts: DRA7: Add DT node for AES2 IP
ARM: DRA7: hwmod: Add data for AES2 IP
crypto: omap-aes - Add support for multiple cores
crypto: omap-aes - Fix registration of Algos
crypto: omap-aes - Fix enabling clocks
crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
crypto: omap-aes - Add support for GCM mode
crypto: omap-aes - Fix configuring of AES mode
crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
crypto: omap-des: Fix unmapping of dma channels
dmaenegine: edma: allow pause/resume for non-cyclic mode
ARM: common: edma: clear completion interrupts on stop
bus: omap_l3_noc: Fix master id address decoding for OMAP5
...
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"
This reverts commit 6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0.
The commit 6d6dd44c5563 ("ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP
for proper boot") switched the IPU1 clock domain to SWSUP only to resolve
an IPU1 boot issue. However, this solution worked only because of another
pre-existing bug in the omap_hwmod code, wherein a usage count for the hwmod
parent clockdomain was incremented during omap_device_deassert_hardreset()
and was never balanced, causing the clockdomain to always remain on and
never allowing the corresponding power domain to enter a low power state.
This eliminated the pre-condition for the IPU1 boot issue. The bug in
omap_hwmod layer was resolved by commit e1d52c6d4ff7 ("ARM: OMAP2+: hwmod:
fix deassert hardreset clkdm usecounting"), and this resulted in the
recurrence of the IPU1 boot issue on some platforms.
The IPU1 boot issue has now been resolved by restricting the target power
domain state to ON during the power-up of the MMU and allowing RET or a
lower power state only when the MMU and the corresponding parent remoteproc
is suspended (system or runtime suspend). So revert back to the default
expected HWSUP mode for the IPU1 clock domain.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit 6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0.
The commit 6d6dd44c5563 ("ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP
for proper boot") switched the IPU1 clock domain to SWSUP only to resolve
an IPU1 boot issue. However, this solution worked only because of another
pre-existing bug in the omap_hwmod code, wherein a usage count for the hwmod
parent clockdomain was incremented during omap_device_deassert_hardreset()
and was never balanced, causing the clockdomain to always remain on and
never allowing the corresponding power domain to enter a low power state.
This eliminated the pre-condition for the IPU1 boot issue. The bug in
omap_hwmod layer was resolved by commit e1d52c6d4ff7 ("ARM: OMAP2+: hwmod:
fix deassert hardreset clkdm usecounting"), and this resulted in the
recurrence of the IPU1 boot issue on some platforms.
The IPU1 boot issue has now been resolved by restricting the target power
domain state to ON during the power-up of the MMU and allowing RET or a
lower power state only when the MMU and the corresponding parent remoteproc
is suspended (system or runtime suspend). So revert back to the default
expected HWSUP mode for the IPU1 clock domain.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.14.y
Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix the DRA7 IPU1 boot issue when
integrated with PM tree.
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
iommu/omap: add pdata ops for setting powerdomain constraint
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix the DRA7 IPU1 boot issue when
integrated with PM tree.
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
iommu/omap: add pdata ops for setting powerdomain constraint
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into rproc-linux-3.14.y
Resync with the latest platform base code. Relevant
fixes include fixes on DPLL bypass clock settings
and support for Timers 12 through 16.
* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree: (127 commits)
ARM: OMAP: Check for clocks which do not have parents
ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
ARM: dts: DRA7: Add DT node for AES2 IP
ARM: DRA7: hwmod: Add data for AES2 IP
crypto: omap-aes - Add support for multiple cores
crypto: omap-aes - Fix registration of Algos
crypto: omap-aes - Fix enabling clocks
crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
crypto: omap-aes - Add support for GCM mode
crypto: omap-aes - Fix configuring of AES mode
crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
crypto: omap-des: Fix unmapping of dma channels
dmaenegine: edma: allow pause/resume for non-cyclic mode
ARM: common: edma: clear completion interrupts on stop
bus: omap_l3_noc: Fix master id address decoding for OMAP5
ARM: edma: Clear IRQ if we get interrupted by a unknown event
bus: omap_l3_noc: Fix connID for OMAP4
bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instance
crypto: omap-sham: Use pm_runtime_irq_safe()
crypto: omap-sham: Add the offset of sg page to vaddr
...
Signed-off-by: Suman Anna <s-anna@ti.com>
Resync with the latest platform base code. Relevant
fixes include fixes on DPLL bypass clock settings
and support for Timers 12 through 16.
* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree: (127 commits)
ARM: OMAP: Check for clocks which do not have parents
ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
ARM: dts: DRA7: Add DT node for AES2 IP
ARM: DRA7: hwmod: Add data for AES2 IP
crypto: omap-aes - Add support for multiple cores
crypto: omap-aes - Fix registration of Algos
crypto: omap-aes - Fix enabling clocks
crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
crypto: omap-aes - Add support for GCM mode
crypto: omap-aes - Fix configuring of AES mode
crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
crypto: omap-des: Fix unmapping of dma channels
dmaenegine: edma: allow pause/resume for non-cyclic mode
ARM: common: edma: clear completion interrupts on stop
bus: omap_l3_noc: Fix master id address decoding for OMAP5
ARM: edma: Clear IRQ if we get interrupted by a unknown event
bus: omap_l3_noc: Fix connID for OMAP4
bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instance
crypto: omap-sham: Use pm_runtime_irq_safe()
crypto: omap-sham: Add the offset of sg page to vaddr
...
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
The IPU1 MMU has been using common IOMMU pdata quirks defined and
used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
plugged in, so that the IPU1 power domain can be restricted to ON
state during the boot and active period of the IPU1 remote processor.
This eliminates the pre-conditions for the IPU1 boot issue as
described in [1].
NOTE:
The fix is currently applied only to IPU1 on DRA7xx SoC, as the
other affected processors on OMAP4/OMAP5/DRA7 are in domains that
are not entering RET. The fix can be easily scaled if these domains
do hit RET in the future.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
The IPU1 MMU has been using common IOMMU pdata quirks defined and
used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
plugged in, so that the IPU1 power domain can be restricted to ON
state during the boot and active period of the IPU1 remote processor.
This eliminates the pre-conditions for the IPU1 boot issue as
described in [1].
NOTE:
The fix is currently applied only to IPU1 on DRA7xx SoC, as the
other affected processors on OMAP4/OMAP5/DRA7 are in domains that
are not entering RET. The fix can be easily scaled if these domains
do hit RET in the future.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
This patch invokes the .set_pwrdm_constraint pdata ops, if present,
during the runtime resume and suspend callbacks to resolve a possible
boot issue on remote processors with AMMU/Unicache, and whose power
domains enter RET between the time the MMU is powered ON to the time
the remote processor is released from reset. The issue is described
in detail in [1].
The pdata ops implementation restricts the target power domain to
ON during resume, and back to the original power domain state during
suspend, and thereby eliminating the conditions for the boot issue.
The implementation is effective only when the original power domain
state is either RET or OFF, and is a no-op when it is ON or INACTIVE.
Doing this in the PM runtime callbacks ensures that the target power
domain stays ON only during the time when the remote processor is
active. The remote processors are typically auto-suspended after an
inactivity period of 10 seconds.
The .set_pwrdm_constraint ops need to be plugged in pdata-quirks
for the affected remote processors to be able to boot properly.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
This patch invokes the .set_pwrdm_constraint pdata ops, if present,
during the runtime resume and suspend callbacks to resolve a possible
boot issue on remote processors with AMMU/Unicache, and whose power
domains enter RET between the time the MMU is powered ON to the time
the remote processor is released from reset. The issue is described
in detail in [1].
The pdata ops implementation restricts the target power domain to
ON during resume, and back to the original power domain state during
suspend, and thereby eliminating the conditions for the boot issue.
The implementation is effective only when the original power domain
state is either RET or OFF, and is a no-op when it is ON or INACTIVE.
Doing this in the PM runtime callbacks ensures that the target power
domain stays ON only during the time when the remote processor is
active. The remote processors are typically auto-suspended after an
inactivity period of 10 seconds.
The .set_pwrdm_constraint ops need to be plugged in pdata-quirks
for the affected remote processors to be able to boot properly.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree into ti-linux-3.14.y
TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y
* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
ARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff mode
regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs
mfd: tps65218: add version check to the PMIC probe
rtc: omap: fix ext-wakeup setup
rtc: omap: do not disable RTC alarm during shutdown
rtc: omap: setup the regulators for poweroff mode
ARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff mode
regulator: tps65218: force set power-up/down strobe to 3 for dcdc3
regulator: of: setup initial suspend state
ARM: dts: AM43xx: update regulator nodes for new layout
regulator: of: Add support for parsing regulator_state for suspend state
ARM: dts: dra7: add i810 errata dpll data
ARM: DRA7: dpll: add implementation for errata i810
Conflicts:
arch/arm/common/edma.c
arch/arm/mach-omap2/Makefile
drivers/regulator/palmas-regulator.c
include/dt-bindings/pinctrl/am43xx.h
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y
* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
ARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff mode
regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs
mfd: tps65218: add version check to the PMIC probe
rtc: omap: fix ext-wakeup setup
rtc: omap: do not disable RTC alarm during shutdown
rtc: omap: setup the regulators for poweroff mode
ARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff mode
regulator: tps65218: force set power-up/down strobe to 3 for dcdc3
regulator: of: setup initial suspend state
ARM: dts: AM43xx: update regulator nodes for new layout
regulator: of: Add support for parsing regulator_state for suspend state
ARM: dts: dra7: add i810 errata dpll data
ARM: DRA7: dpll: add implementation for errata i810
Conflicts:
arch/arm/common/edma.c
arch/arm/mach-omap2/Makefile
drivers/regulator/palmas-regulator.c
include/dt-bindings/pinctrl/am43xx.h
Signed-off-by: Dan Murphy <DMurphy@ti.com>
iommu/omap: add pdata ops for setting powerdomain constraint
Add a new platform data ops to allow the OMAP IOMMU driver to be able
to request a specific target power domain state for the domain it
belongs to. This ops is being added to resolve a boot issue on OMAP
remote processors like IPU that have an AMMU/Unicache, which will be
in an invalid state if the particular power domain enters RET between
the MMU programming and releasing the reset of the remote processor.
See [1] for more details on the issue.
The ops will allow to invoke the pwrdm_set_next_pwrst() API in a
multi-arch kernel environment. The ops also returns the current power
domain state while enforcing the constraint so that the driver can
store it and use it to set back the power domain state while releasing
the constraint.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
Add a new platform data ops to allow the OMAP IOMMU driver to be able
to request a specific target power domain state for the domain it
belongs to. This ops is being added to resolve a boot issue on OMAP
remote processors like IPU that have an AMMU/Unicache, which will be
in an invalid state if the particular power domain enters RET between
the MMU programming and releasing the reset of the remote processor.
See [1] for more details on the issue.
The ops will allow to invoke the pwrdm_set_next_pwrst() API in a
multi-arch kernel environment. The ops also returns the current power
domain state while enforcing the constraint so that the driver can
store it and use it to set back the power domain state while releasing
the constraint.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff mode
Without this, the memory will remain active during poweroff consuming
extra power. Please note revision 2.1 PMIC seems to fail when DCDC3
disable is attempted, so this is not done on that PMIC revision. The
PMIC revision checks in the regulator patches make sure of this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Without this, the memory will remain active during poweroff consuming
extra power. Please note revision 2.1 PMIC seems to fail when DCDC3
disable is attempted, so this is not done on that PMIC revision. The
PMIC revision checks in the regulator patches make sure of this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs
Some versions of tps65218 do not seem to support poweroff modes properly
if DCDC3 regulator is shut-down. Thus, keep it enabled even during
poweroff if the version info matches the broken silicon revision.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Some versions of tps65218 do not seem to support poweroff modes properly
if DCDC3 regulator is shut-down. Thus, keep it enabled even during
poweroff if the version info matches the broken silicon revision.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
mfd: tps65218: add version check to the PMIC probe
Version information will be needed to handle some error cases under the
regulator driver, so store the information once during MFD probe.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Version information will be needed to handle some error cases under the
regulator driver, so store the information once during MFD probe.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
rtc: omap: fix ext-wakeup setup
The register write for the ext-wakeup handling does not write the
EXT_WAKEUP_EN bit at all, which causes a system shutdown after
20 seconds after wakeup from EXT_WAKEUP (e.g. power button.) Fixed
by adding the missing bit.
Fixes: 4c71e686101d (drivers/rtc/rtc-omap.c: Enable power..)
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
The register write for the ext-wakeup handling does not write the
EXT_WAKEUP_EN bit at all, which causes a system shutdown after
20 seconds after wakeup from EXT_WAKEUP (e.g. power button.) Fixed
by adding the missing bit.
Fixes: 4c71e686101d (drivers/rtc/rtc-omap.c: Enable power..)
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
rtc: omap: do not disable RTC alarm during shutdown
This enables use cases like rtc-only mode, where most of the system is
shutdown just waiting for an RTC alarm to occur and boot the device up.
Only supported for systems that have the RTC act as a system power
controller at the moment (AM33xx/AM43xx.)
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
This enables use cases like rtc-only mode, where most of the system is
shutdown just waiting for an RTC alarm to occur and boot the device up.
Only supported for systems that have the RTC act as a system power
controller at the moment (AM33xx/AM43xx.)
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
rtc: omap: setup the regulators for poweroff mode
In certain cases, like rtc-only mode, the system regulators shall be
set to slightly different mode compared to suspend to mem. As the RTC
driver is handling the poweroff setup on some systems, add a callback
to regulator core from the RTC power off to setup the valid regulator
states.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
In certain cases, like rtc-only mode, the system regulators shall be
set to slightly different mode compared to suspend to mem. As the RTC
driver is handling the poweroff setup on some systems, add a callback
to regulator core from the RTC power off to setup the valid regulator
states.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff mode
Without this, the memory will remain active during poweroff consuming
extra power.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Without this, the memory will remain active during poweroff consuming
extra power.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
regulator: tps65218: force set power-up/down strobe to 3 for dcdc3
The reset value for this register seems broken on certain versions of
tps65218 chip, so make sure the dcdc3 settings is proper. Needed for
proper functionality of rtc+ddr / rtc-only modes.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
The reset value for this register seems broken on certain versions of
tps65218 chip, so make sure the dcdc3 settings is proper. Needed for
proper functionality of rtc+ddr / rtc-only modes.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
regulator: of: setup initial suspend state
Setup initial suspend state to mem, if suspend state is defined for
mem state. This makes sure that the regulators are in proper mode
already from boot.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Setup initial suspend state to mem, if suspend state is defined for
mem state. This makes sure that the regulators are in proper mode
already from boot.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: AM43xx: update regulator nodes for new layout
Upstream has support for regulator-state-mem, instead of the internal
version of regulator-suspend-enable. Update the AM43xx DT nodes to
support the upstream layout.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Upstream has support for regulator-state-mem, instead of the internal
version of regulator-suspend-enable. Update the AM43xx DT nodes to
support the upstream layout.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
regulator: of: Add support for parsing regulator_state for suspend state
[ Upstream commit 5e5e3a42c653c5ef1c281651f1882411601129bd ]
The regulation_constraints structure includes specific field to support
suspend state for global PMIC SUSPEND/HIBERNATE mode. This patch add support
for parsing regulator_state for suspend state.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Conflicts:
drivers/regulator/of_regulator.c
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[ Upstream commit 5e5e3a42c653c5ef1c281651f1882411601129bd ]
The regulation_constraints structure includes specific field to support
suspend state for global PMIC SUSPEND/HIBERNATE mode. This patch add support
for parsing regulator_state for suspend state.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Conflicts:
drivers/regulator/of_regulator.c
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: dra7: add i810 errata dpll data
Add DPLL sink clockdomain info for dra7. Required for errata i810;
downstream clockdomain for a DPLL must be force enabled while
changing the M/N ratios.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Add DPLL sink clockdomain info for dra7. Required for errata i810;
downstream clockdomain for a DPLL must be force enabled while
changing the M/N ratios.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: DRA7: dpll: add implementation for errata i810
Errata i810 states that the DPLL controller can be stuck if the downstream
clocks are disabled and DPLL is in auto mode while M/N ratios are changed.
Workaround for this is to force enable (SW_WKUP) the downstream clockdomain
while reprogramming the DPLL. This patch adds the support for this, the
actual clkdm-sink info needs to be added in a separate patch.
See DRA75x, DRA74x Errata; id i810 for more details.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Errata i810 states that the DPLL controller can be stuck if the downstream
clocks are disabled and DPLL is in auto mode while M/N ratios are changed.
Workaround for this is to force enable (SW_WKUP) the downstream clockdomain
while reprogramming the DPLL. This patch adds the support for this, the
actual clkdm-sink info needs to be added in a separate patch.
See DRA75x, DRA74x Errata; id i810 for more details.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Merge branch 'platform-ti-linux-3.14.y' into pm-ti-linux-3.14.y
Conflicts:
arch/arm/common/edma.c
arch/arm/mach-omap2/Makefile
drivers/regulator/palmas-regulator.c
include/dt-bindings/pinctrl/am43xx.h
include/linux/mfd/palmas.h
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Conflicts:
arch/arm/common/edma.c
arch/arm/mach-omap2/Makefile
drivers/regulator/palmas-regulator.c
include/dt-bindings/pinctrl/am43xx.h
include/linux/mfd/palmas.h
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
usb: dwc3: core: don't break during suspend/resume while we're dual-role
We can't rely just on dr_mode to decide if we're in host or gadget
mode when we're configured as otg/dual-role. So while dr_mode is
OTG, we find out from the otg state machine if we're in host
or gadget mode and take the necessary actions during suspend/resume.
Also make sure that we disable OTG irq and events during system suspend
so that we don't lockup the system during system suspend/resume.
Known Issue:
when otg-host, usb device disconnects and reconnects after system suspend/resume.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We can't rely just on dr_mode to decide if we're in host or gadget
mode when we're configured as otg/dual-role. So while dr_mode is
OTG, we find out from the otg state machine if we're in host
or gadget mode and take the necessary actions during suspend/resume.
Also make sure that we disable OTG irq and events during system suspend
so that we don't lockup the system during system suspend/resume.
Known Issue:
when otg-host, usb device disconnects and reconnects after system suspend/resume.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
usb: dwc3: core: Prevent otg events from disabling themselves
There is a race happening during dwc3_drd_init() that causes
otg events to get disabled. This is what happens.
dwc3_otg_irq() happens immediately when PRTCAP is set to OTG,
even though OEVTEN is 0. This is because BIT 31 IRQ of
OEVT can't be disabled by OEVTEN.
We configure OEVTEN in dwc3_otg_init() but dwc3_otg_irq() has
already saved OEVTEN as 0 into dwc->oevten. So finally when
dwc3_irq_thread_irq() is called we save 0 into OEVTEN
thus disabling OTG irqs forever.
We fix this by disabling IRQs when configuring OEVTEN in
dwc3_otg_init().
eviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
There is a race happening during dwc3_drd_init() that causes
otg events to get disabled. This is what happens.
dwc3_otg_irq() happens immediately when PRTCAP is set to OTG,
even though OEVTEN is 0. This is because BIT 31 IRQ of
OEVT can't be disabled by OEVTEN.
We configure OEVTEN in dwc3_otg_init() but dwc3_otg_irq() has
already saved OEVTEN as 0 into dwc->oevten. So finally when
dwc3_irq_thread_irq() is called we save 0 into OEVTEN
thus disabling OTG irqs forever.
We fix this by disabling IRQs when configuring OEVTEN in
dwc3_otg_init().
eviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: dts: OMAP5: Fix the standby info for IPU & DSP
The commit 04e7b6f76f6b ("ARM: dts: OMAP5: Add standby info for
IPU and DSP") added the ti,rproc-standby-info property mistakenly
to the IPU & DSP MMU nodes instead of adding them to the processor
nodes. This results in a probe failure of the OMAP remoteproc driver.
Fix this error by moving these properties from the MMU nodes to the
processor nodes.
Fixes: 04e7b6f76f6b ("ARM: dts: OMAP5: Add standby info for IPU and DSP")
Signed-off-by: Suman Anna <s-anna@ti.com>
The commit 04e7b6f76f6b ("ARM: dts: OMAP5: Add standby info for
IPU and DSP") added the ti,rproc-standby-info property mistakenly
to the IPU & DSP MMU nodes instead of adding them to the processor
nodes. This results in a probe failure of the OMAP remoteproc driver.
Fix this error by moving these properties from the MMU nodes to the
processor nodes.
Fixes: 04e7b6f76f6b ("ARM: dts: OMAP5: Add standby info for IPU and DSP")
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
OMAPDSS: dra7-tpd12s015: support system suspend
OMAPDSS: dra7-tpd12s015: lock i2c adapter when using DDC
OMAPDSS: dra7-tpd12s015: move ddc pixmux to .dts
OMAPDSS: dra7-tpd12s015: remove legacy platform data
ASoC: davinci-mcasp: HACK interface to handle dra7-evm's i2c2/HDMI mux
ARM: DTS: dra7-evm: Enable mcasp8
ARM: DTS: dra7: Add node for McASP8
ARM: DRA7: hwmod: Add data for McASP8
ARM: clk: dra7xx: Correct mcasp8_ahclkx_mux name
Signed-off-by: Dan Murphy <dmurphy@ti.com>
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
OMAPDSS: dra7-tpd12s015: support system suspend
OMAPDSS: dra7-tpd12s015: lock i2c adapter when using DDC
OMAPDSS: dra7-tpd12s015: move ddc pixmux to .dts
OMAPDSS: dra7-tpd12s015: remove legacy platform data
ASoC: davinci-mcasp: HACK interface to handle dra7-evm's i2c2/HDMI mux
ARM: DTS: dra7-evm: Enable mcasp8
ARM: DTS: dra7: Add node for McASP8
ARM: DRA7: hwmod: Add data for McASP8
ARM: clk: dra7xx: Correct mcasp8_ahclkx_mux name
Signed-off-by: Dan Murphy <dmurphy@ti.com>
OMAPDSS: dra7-tpd12s015: support system suspend
The driver uses mcasp2 pin for a gpio, with direct register writes. On
system suspend the mcasp2 is left alive, preventing suspend.
Also, mcasp2 may be used for other purposes, so directly touching the
mcasp2 registers can cause problems. Luckily, the same pin can be muxed
to mcasp8 mode, and mcasp8 is not used by anyone.
We now have hacks made to mcasp driver which allows the dra7-tpd12s015
driver to manage the mcasp8 pin via the mcasp driver. While the solution
is a pure hack, it allows us to do proper power management, and remove
all the direct register write hackery.
dra7-tpd12s015's device tree data contains a phandle to the mcasp8 node,
and dra7-tpd12s015 driver uses this handle to enable and disable the
mcasp8 module, and to set the gpio output value.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
The driver uses mcasp2 pin for a gpio, with direct register writes. On
system suspend the mcasp2 is left alive, preventing suspend.
Also, mcasp2 may be used for other purposes, so directly touching the
mcasp2 registers can cause problems. Luckily, the same pin can be muxed
to mcasp8 mode, and mcasp8 is not used by anyone.
We now have hacks made to mcasp driver which allows the dra7-tpd12s015
driver to manage the mcasp8 pin via the mcasp driver. While the solution
is a pure hack, it allows us to do proper power management, and remove
all the direct register write hackery.
dra7-tpd12s015's device tree data contains a phandle to the mcasp8 node,
and dra7-tpd12s015 driver uses this handle to enable and disable the
mcasp8 module, and to set the gpio output value.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
OMAPDSS: dra7-tpd12s015: lock i2c adapter when using DDC
On DRA7 the i2c2 bus is shared between i2c and DDC modes. At the moment
the TPD12S015 driver can switch the muxing at any time, which could lead
to an i2c device getting transfer errors if it is using i2c2 bus.
This patch solves the issue by making TPD12S015 driver use
i2c_lock_adapter() when the pins are in DDC mode.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
On DRA7 the i2c2 bus is shared between i2c and DDC modes. At the moment
the TPD12S015 driver can switch the muxing at any time, which could lead
to an i2c device getting transfer errors if it is using i2c2 bus.
This patch solves the issue by making TPD12S015 driver use
i2c_lock_adapter() when the pins are in DDC mode.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
OMAPDSS: dra7-tpd12s015: move ddc pixmux to .dts
We need to do runtime pinmuxing for HDMI, as the HDMI DDC lines are also
used as I2C2 lines. This is currently done in the DRA7 EVM specific
tpd12s015 driver, by writing directly to the pinmux registers.
Remove that hackery by moving the muxing to .dts.
We also need to use a McASP2 pin, which is used as a gpio via McASP2
functionality (i.e. not in GPIO mode). Muxing for this pin is also moved
to .dts, but changing the output value of the pin is still handled in
the driver via direct register writes.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
We need to do runtime pinmuxing for HDMI, as the HDMI DDC lines are also
used as I2C2 lines. This is currently done in the DRA7 EVM specific
tpd12s015 driver, by writing directly to the pinmux registers.
Remove that hackery by moving the muxing to .dts.
We also need to use a McASP2 pin, which is used as a gpio via McASP2
functionality (i.e. not in GPIO mode). Muxing for this pin is also moved
to .dts, but changing the output value of the pin is still handled in
the driver via direct register writes.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
OMAPDSS: dra7-tpd12s015: remove legacy platform data
The DRA7 specific TPD12S015 driver is neve used with legacy platform
data. So remove the related code.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
The DRA7 specific TPD12S015 driver is neve used with legacy platform
data. So remove the related code.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
ASoC: davinci-mcasp: HACK interface to handle dra7-evm's i2c2/HDMI mux
McASP2_ACLKR pin (in McASP8.AXR2 mode) is used in GPIO mode to control
the mux selection between I2C2 or HDMI.
This patch adds direct interface to handle this:
dra7_mcasp_hdmi_gpio_get() to select GPIO mode with pm_runtime_get
dra7_mcasp_hdmi_gpio_set() to change the GPIO pin state
dra7_mcasp_hdmi_gpio_put() to disable the GPIO mode and pm_runtime_put
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
McASP2_ACLKR pin (in McASP8.AXR2 mode) is used in GPIO mode to control
the mux selection between I2C2 or HDMI.
This patch adds direct interface to handle this:
dra7_mcasp_hdmi_gpio_get() to select GPIO mode with pm_runtime_get
dra7_mcasp_hdmi_gpio_set() to change the GPIO pin state
dra7_mcasp_hdmi_gpio_put() to disable the GPIO mode and pm_runtime_put
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
ARM: DTS: dra7-evm: Enable mcasp8
McASP8.AXR2 pin is going to be used as GPIO to control the I2C2/HDMI mux
on dra7-evm.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
McASP8.AXR2 pin is going to be used as GPIO to control the I2C2/HDMI mux
on dra7-evm.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
ARM: DTS: dra7: Add node for McASP8
McASP8.AXR2 pin is going to be used as GPIO to control the I2C2/HDMI mux
on dra7-evm.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
McASP8.AXR2 pin is going to be used as GPIO to control the I2C2/HDMI mux
on dra7-evm.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
ARM: DRA7: hwmod: Add data for McASP8
McASP8.AXR2 pin is going to be used as GPIO to control the I2C2/HDMI mux
on dra7-evm.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
McASP8.AXR2 pin is going to be used as GPIO to control the I2C2/HDMI mux
on dra7-evm.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
ARM: clk: dra7xx: Correct mcasp8_ahclkx_mux name
rename the mcasp8_ahclk_mux to mcasp8_ahclkx_mux.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
rename the mcasp8_ahclk_mux to mcasp8_ahclkx_mux.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in couple of minor patches from the remoteproc feature tree,
one is a minor bug fix in PRUSS remoteproc driver, and the other
is a comment correction in OMAP remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: revise the comment about standby in _suspend
remoteproc/pruss: fix pruss_init return on error
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in couple of minor patches from the remoteproc feature tree,
one is a minor bug fix in PRUSS remoteproc driver, and the other
is a comment correction in OMAP remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: revise the comment about standby in _suspend
remoteproc/pruss: fix pruss_init return on error
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: revise the comment about standby in _suspend
The _suspend() function has a TODO comment about implementing a
BIOS-independent hook to send a message to notify the MPU the
completion of the context save on the remoteproc side. This has
been clarified with the SYS/BIOS team now, and this race condition
between the remoteproc saving the context and the MPU waiting for
the sync point before it puts the remote processor into reset, can
never be resolved using a message ACK or a shared memory variable
signalling. So, update the comment appropriately.
Signed-off-by: Suman Anna <s-anna@ti.com>
The _suspend() function has a TODO comment about implementing a
BIOS-independent hook to send a message to notify the MPU the
completion of the context save on the remoteproc side. This has
been clarified with the SYS/BIOS team now, and this race condition
between the remoteproc saving the context and the MPU waiting for
the sync point before it puts the remote processor into reset, can
never be resolved using a message ACK or a shared memory variable
signalling. So, update the comment appropriately.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pruss: fix pruss_init return on error
If the pru_rproc_driver fails to register in pruss_init(),
the failure code should be returned instead of returning 0,
a success value. So, fix the pruss_init() return code
accordingly.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
If the pru_rproc_driver fails to register in pruss_init(),
the failure code should be returned instead of returning 0,
a success value. So, fix the pruss_init() return code
accordingly.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y
* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
usb: host: xhci-pci: Fix NULL pointer dereference error
ti_config_fragments/connectivity.cfg: disable CONFIG_USB_OTG_WHITELIST
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y
* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
usb: host: xhci-pci: Fix NULL pointer dereference error
ti_config_fragments/connectivity.cfg: disable CONFIG_USB_OTG_WHITELIST
Signed-off-by: Dan Murphy <DMurphy@ti.com>
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
media: ti-vpe: vpe: Fix kernel warning on close
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
media: ti-vpe: vpe: Fix kernel warning on close
Signed-off-by: Dan Murphy <DMurphy@ti.com>
usb: host: xhci-pci: Fix NULL pointer dereference error
commit 5fa63bd959 (usb: xhci: Fix suspend/resume when used
with OTG core) removes assigning xhci->main_hcd from xhci_gen_setup
and adds it in the probe of xhci-plat and xhci-pci.
In the case of xhci-pci, xhci_mem_init is invoked before main_hcd is
initialized in the probe causing a null pointer deferencing error.
Fix it by initializing xhci->main_hcd in xhci_gen_setup and removing
it from xhci_pci_probe().
Fixes: 5fa63bd959cc ("usb: xhci: Fix suspend/resume when used with OTG core")
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
commit 5fa63bd959 (usb: xhci: Fix suspend/resume when used
with OTG core) removes assigning xhci->main_hcd from xhci_gen_setup
and adds it in the probe of xhci-plat and xhci-pci.
In the case of xhci-pci, xhci_mem_init is invoked before main_hcd is
initialized in the probe causing a null pointer deferencing error.
Fix it by initializing xhci->main_hcd in xhci_gen_setup and removing
it from xhci_pci_probe().
Fixes: 5fa63bd959cc ("usb: xhci: Fix suspend/resume when used with OTG core")
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ti_config_fragments/connectivity.cfg: disable CONFIG_USB_OTG_WHITELIST
CONFIG_USB_OTG_WHITELIST is to be enabled for compliance to OTG
specification. However, on TI SoCs, we only support/test USB
dual-role device, not the full OTG specification.
Moreover, with CONFIG_USB_OTG_WHITELIST enabled, on AM335x
beaglebone black, on connecting a USB webcam we get:
[ 74.960459] musb-hdrc musb-hdrc.1.auto: otg: usb_otg_kick_fsm: invalid host/gadget device
[ 75.080228] usb 1-1: new high-speed USB device number 4 using musb-hdrc
[ 75.270151] usb 1-1: device v03f0 pa707 is not supported
[ 75.275670] hub 1-0:1.0: unable to enumerate USB device on port 1
This is because kernel refuses to enumerate peripherals which
are not listed in kernel's OTG whitelist. This is needed for
full compliance with OTG specification.
Disable CONFIG_USB_OTG_WHITELIST since we support only dual-role
device and do not need to reject non-whitelisted devices during
enumeration.
Suggested-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
CONFIG_USB_OTG_WHITELIST is to be enabled for compliance to OTG
specification. However, on TI SoCs, we only support/test USB
dual-role device, not the full OTG specification.
Moreover, with CONFIG_USB_OTG_WHITELIST enabled, on AM335x
beaglebone black, on connecting a USB webcam we get:
[ 74.960459] musb-hdrc musb-hdrc.1.auto: otg: usb_otg_kick_fsm: invalid host/gadget device
[ 75.080228] usb 1-1: new high-speed USB device number 4 using musb-hdrc
[ 75.270151] usb 1-1: device v03f0 pa707 is not supported
[ 75.275670] hub 1-0:1.0: unable to enumerate USB device on port 1
This is because kernel refuses to enumerate peripherals which
are not listed in kernel's OTG whitelist. This is needed for
full compliance with OTG specification.
Disable CONFIG_USB_OTG_WHITELIST since we support only dual-role
device and do not need to reject non-whitelisted devices during
enumeration.
Suggested-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
media: ti-vpe: vpe: Fix kernel warning on close
When running a VPE application, if the application is killed suddenly,
STREAMOFF ioctl won't get called and directly close syscall for the
video device is called.
As part of the cleanup process, all of the VPDMA buffers are freed.
Sometimes a kernel warning is printed if the buffers are being freed
before they are unmapped.
Fix this by adding a streamOFF call to each of the CAPTURE AND OUTPUT stream
so that proper cleanup happens, the transaction is finished properly and
all the video buffers / VPDMA buffers are unmapped and freed.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
When running a VPE application, if the application is killed suddenly,
STREAMOFF ioctl won't get called and directly close syscall for the
video device is called.
As part of the cleanup process, all of the VPDMA buffers are freed.
Sometimes a kernel warning is printed if the buffers are being freed
before they are unmapped.
Fix this by adding a streamOFF call to each of the CAPTURE AND OUTPUT stream
so that proper cleanup happens, the transaction is finished properly and
all the video buffers / VPDMA buffers are unmapped and freed.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
TI-Integration: usb: musb: fix botched up merge (again)
Merge bc058ac090e8 ("Merge tag 'v3.14.42' of
http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into
ti-linux-3.14.y") was a botched up merge.
commit df47ad1ce42b ("TI-Integration: Fix merge conflict
on musb_core.c") tried to fix it up but only did it
partially.
commit d0f5c460aac2 ("TI-Integration: Cherry picking this
commit to fix merge issue") tried to finish the job by
cherry-picking commit 889ad3b60f9c ("usb: musb: try a race-free
wakeup") which was the commit introducing code botched up by
original merge.
While doing this it was missed that a later commit 1007020e37f9
("usb: musb: fix device hotplug behind hub") had made further
fixes which now got reverted due to the cherry-pick. So,
cherry-picking an older commit to fix a bad merge was a bad idea.
This patch finally brings back code to where it should have
been after original merge bc058ac090e8.
Fixes: d0f5c460aac2 ("TI-Integration: Cherry picking this commit to fix merge issue")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merge bc058ac090e8 ("Merge tag 'v3.14.42' of
http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into
ti-linux-3.14.y") was a botched up merge.
commit df47ad1ce42b ("TI-Integration: Fix merge conflict
on musb_core.c") tried to fix it up but only did it
partially.
commit d0f5c460aac2 ("TI-Integration: Cherry picking this
commit to fix merge issue") tried to finish the job by
cherry-picking commit 889ad3b60f9c ("usb: musb: try a race-free
wakeup") which was the commit introducing code botched up by
original merge.
While doing this it was missed that a later commit 1007020e37f9
("usb: musb: fix device hotplug behind hub") had made further
fixes which now got reverted due to the cherry-pick. So,
cherry-picking an older commit to fix a bad merge was a bad idea.
This patch finally brings back code to where it should have
been after original merge bc058ac090e8.
Fixes: d0f5c460aac2 ("TI-Integration: Cherry picking this commit to fix merge issue")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in a minor trace change for the PRUSS remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/pruss: lower the trace level in pru_rproc_mbox_callback
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in a minor trace change for the PRUSS remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/pruss: lower the trace level in pru_rproc_mbox_callback
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pruss: lower the trace level in pru_rproc_mbox_callback
The current virtio rpmsg stack is such that it processes all the
pending messages in the vring on a single interrupt. So, it is
possible to see an empty interrupt without having to process any
messages, especially in cases where there is additional message
message communication that happens in-band within the callback
of a received message while processing it.
This behavior is seen when running the rpmsg_client_sample, and
printing the current trace message in pru_rproc_mbox_callback()
rather frequently, so lower the level of this trace from KERN_ERR
to KERN_DBG.
Reported-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The current virtio rpmsg stack is such that it processes all the
pending messages in the vring on a single interrupt. So, it is
possible to see an empty interrupt without having to process any
messages, especially in cases where there is additional message
message communication that happens in-band within the callback
of a received message while processing it.
This behavior is seen when running the rpmsg_client_sample, and
printing the current trace message in pru_rproc_mbox_callback()
rather frequently, so lower the level of this trace from KERN_ERR
to KERN_DBG.
Reported-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in the updated remoteproc feature branch that adds the runtime
auto-suspend/resume support on the IPU and DSP remote processors
that already support system suspend. Also, includes a minor typo fix.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: fix a minor typo in a trace message
remoteproc/omap: add support for runtime auto-suspend/resume
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that adds the runtime
auto-suspend/resume support on the IPU and DSP remote processors
that already support system suspend. Also, includes a minor typo fix.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: fix a minor typo in a trace message
remoteproc/omap: add support for runtime auto-suspend/resume
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: fix a minor typo in a trace message
The omap_mbox_msg_send() is the legacy API for sending a mailbox
message. It has been replaced with the mbox_send_message() from
the mailbox framework, so update the failure trace message
accordingly.
Signed-off-by: Suman Anna <s-anna@ti.com>
The omap_mbox_msg_send() is the legacy API for sending a mailbox
message. It has been replaced with the mbox_send_message() from
the mailbox framework, so update the failure trace message
accordingly.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: add support for runtime auto-suspend/resume
This patch enhances the PM support in the OMAP remoteproc driver to
support the runtime auto-suspend. A remoteproc may not be required to
be running all the time, and typically will need to be active only
during certain usecases. As such, to save power, it should be turned
off during potential long periods of inactivity between usecases.
This suspend and resume of the device is a relatively heavy process
in terms of latencies, so a remoteproc should be suspended only after
a certain period of prolonged inactivity. The OMAP remoteproc driver
leverages the runtime pm framework's auto_suspend feature to accomplish
this functionality. This feature is automatically enabled when a remote
processor has successfully booted. The 'autosuspend_delay_ms' for each
device dictates the inactivity period/time to wait for before
suspending the device.
The runtime auto-suspend design relies on marking the last busy time
on every communication (virtqueue kick) to and from the remote processor.
When there has been no activity for 'autosuspend_delay_ms' time, the
runtime PM framework invokes the driver's runtime pm suspend callback
to suspend the device. The remote processor will be woken up on the
initiation of the next communication message through the runtime pm
resume callback. The current auto-suspend design also allows a remote
processor to deny a auto-suspend attempt, if it wishes to, by sending a
NACK response to the initial suspend request message sent to the remote
processor as part of the suspend process. The auto-suspend request is
also only attempted if the remote processor is idled and in standby at
the time of inactivity timer expiry. This choice is made to avoid
unnecessary messaging, and the auto-suspend is simply rescheduled to
be attempted again after a further lapse of autosuspend_delay_ms.
The runtime pm callbacks functionality in this patch reuses most of the
core logic from the suspend/resume support code, and make use of an
additional auto_suspend flag to differentiate the logic in common code
from system suspend. The system suspend/resume sequences are also updated
to reflect the proper pm_runtime statuses, and also to really perform a
suspend/resume only if the remoteproc has not been auto-suspended at the
time of request. The remote processor is left in suspended state on a
system resume if it has been auto-suspended before, and will be woken up
only when a usecase needs to run. The other significant change in this
patch is to reset the remoteproc device's pm_domain so as to avoid
conflicts with the ordering sequences in the device pm_domain's runtime
callbacks and the reset management and clock management implemented
within the runtime callbacks in the driver.
The OMAP remoteproc driver currently uses a default value of 10 seconds
for all OMAP remoteprocs, and a different value can be chosen either by
choosing a positive value for the 'autosuspend_delay' in the device's
omap_rproc_fw_data in the driver match data or by updating the
'autosuspend_delay_ms' field at runtime through the sysfs interface.
Eg: To use 25 seconds for IPU2 on DRA7xx,
echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms
The runtime suspend feature can also be similarly enabled or disabled by
writing 'auto' or 'on' to the device's 'control' power field. The default
is enabled.
Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
echo on > /sys/bus/platform/devices/55020000.ipu/power/control
Signed-off-by: Suman Anna <s-anna@ti.com>
This patch enhances the PM support in the OMAP remoteproc driver to
support the runtime auto-suspend. A remoteproc may not be required to
be running all the time, and typically will need to be active only
during certain usecases. As such, to save power, it should be turned
off during potential long periods of inactivity between usecases.
This suspend and resume of the device is a relatively heavy process
in terms of latencies, so a remoteproc should be suspended only after
a certain period of prolonged inactivity. The OMAP remoteproc driver
leverages the runtime pm framework's auto_suspend feature to accomplish
this functionality. This feature is automatically enabled when a remote
processor has successfully booted. The 'autosuspend_delay_ms' for each
device dictates the inactivity period/time to wait for before
suspending the device.
The runtime auto-suspend design relies on marking the last busy time
on every communication (virtqueue kick) to and from the remote processor.
When there has been no activity for 'autosuspend_delay_ms' time, the
runtime PM framework invokes the driver's runtime pm suspend callback
to suspend the device. The remote processor will be woken up on the
initiation of the next communication message through the runtime pm
resume callback. The current auto-suspend design also allows a remote
processor to deny a auto-suspend attempt, if it wishes to, by sending a
NACK response to the initial suspend request message sent to the remote
processor as part of the suspend process. The auto-suspend request is
also only attempted if the remote processor is idled and in standby at
the time of inactivity timer expiry. This choice is made to avoid
unnecessary messaging, and the auto-suspend is simply rescheduled to
be attempted again after a further lapse of autosuspend_delay_ms.
The runtime pm callbacks functionality in this patch reuses most of the
core logic from the suspend/resume support code, and make use of an
additional auto_suspend flag to differentiate the logic in common code
from system suspend. The system suspend/resume sequences are also updated
to reflect the proper pm_runtime statuses, and also to really perform a
suspend/resume only if the remoteproc has not been auto-suspended at the
time of request. The remote processor is left in suspended state on a
system resume if it has been auto-suspended before, and will be woken up
only when a usecase needs to run. The other significant change in this
patch is to reset the remoteproc device's pm_domain so as to avoid
conflicts with the ordering sequences in the device pm_domain's runtime
callbacks and the reset management and clock management implemented
within the runtime callbacks in the driver.
The OMAP remoteproc driver currently uses a default value of 10 seconds
for all OMAP remoteprocs, and a different value can be chosen either by
choosing a positive value for the 'autosuspend_delay' in the device's
omap_rproc_fw_data in the driver match data or by updating the
'autosuspend_delay_ms' field at runtime through the sysfs interface.
Eg: To use 25 seconds for IPU2 on DRA7xx,
echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms
The runtime suspend feature can also be similarly enabled or disabled by
writing 'auto' or 'on' to the device's 'control' power field. The default
is enabled.
Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
echo on > /sys/bus/platform/devices/55020000.ipu/power/control
Signed-off-by: Suman Anna <s-anna@ti.com>
TI-Integration: Cherry picking this commit to fix merge issue
Cherry picking this commit to the top of the tree to fix a
merge of the stable that broke this file. Half of the
issue was the merge conflict resolution the other half
was gits auto merging of the file.
usb: musb: try a race-free wakeup
Attaching a keyboard, using it as a wakeup via
|for f in $(find /sys/devices/ocp.3/47400000.usb -name wakeup)
|do
| echo enabled > $f
|done
going into standby
| echo standby > /sys/power/state
and now a wake up by a pressing a key.
What happens is that the system wakes up but the USB device is dead. The
USB stack tries to send a few control URBs but nothing comes back.
Eventually it gaves up and the device remains dead:
|[ 632.559678] PM: Wakeup source USB1_PHY
|[ 632.581074] PM: noirq resume of devices complete after 21.261 msecs
|[ 632.607521] PM: early resume of devices complete after 10.360 msecs
|[ 632.616854] net eth2: initializing cpsw version 1.12 (0)
|[ 632.704126] net eth2: phy found : id is : 0x4dd074
|[ 636.704048] libphy: 4a101000.mdio:00 - Link is Up - 1000/Full
|[ 638.444620] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
|[ 653.713435] usb 1-1: device descriptor read/64, error -110
|[ 669.093435] usb 1-1: device descriptor read/64, error -110
|[ 669.473424] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
|[ 684.743436] usb 1-1: device descriptor read/64, error -110
|[ 690.065097] PM: resume of devices complete after 57450.744 msecs
|[ 690.076601] PM: Finishing wakeup.
|[ 690.076627] Restarting tasks ...
It seems that since we got woken up via MUSB_INTR_RESUME the
musb_host_finish_resume() callback is executed before the
resume-callbacks of the PHY and glue layer are invoked. If I delay it
until the glue layer resumed then I don't see this problem.
I also move musb_host_resume_root_hub() into that callback since I don't
see any reason in doing anything resume-link if there are still pieces
not restored.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
drivers/usb/musb/musb_core.c
Cherry picking this commit to the top of the tree to fix a
merge of the stable that broke this file. Half of the
issue was the merge conflict resolution the other half
was gits auto merging of the file.
usb: musb: try a race-free wakeup
Attaching a keyboard, using it as a wakeup via
|for f in $(find /sys/devices/ocp.3/47400000.usb -name wakeup)
|do
| echo enabled > $f
|done
going into standby
| echo standby > /sys/power/state
and now a wake up by a pressing a key.
What happens is that the system wakes up but the USB device is dead. The
USB stack tries to send a few control URBs but nothing comes back.
Eventually it gaves up and the device remains dead:
|[ 632.559678] PM: Wakeup source USB1_PHY
|[ 632.581074] PM: noirq resume of devices complete after 21.261 msecs
|[ 632.607521] PM: early resume of devices complete after 10.360 msecs
|[ 632.616854] net eth2: initializing cpsw version 1.12 (0)
|[ 632.704126] net eth2: phy found : id is : 0x4dd074
|[ 636.704048] libphy: 4a101000.mdio:00 - Link is Up - 1000/Full
|[ 638.444620] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
|[ 653.713435] usb 1-1: device descriptor read/64, error -110
|[ 669.093435] usb 1-1: device descriptor read/64, error -110
|[ 669.473424] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
|[ 684.743436] usb 1-1: device descriptor read/64, error -110
|[ 690.065097] PM: resume of devices complete after 57450.744 msecs
|[ 690.076601] PM: Finishing wakeup.
|[ 690.076627] Restarting tasks ...
It seems that since we got woken up via MUSB_INTR_RESUME the
musb_host_finish_resume() callback is executed before the
resume-callbacks of the PHY and glue layer are invoked. If I delay it
until the glue layer resumed then I don't see this problem.
I also move musb_host_resume_root_hub() into that callback since I don't
see any reason in doing anything resume-link if there are still pieces
not restored.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
drivers/usb/musb/musb_core.c