rpmsg: omx: return actual user-provided bytes written in write

rpmsg: omx: return actual user-provided bytes written in write

The 'write' system call is expected to return the number of bytes
written back to userspace. The rpmsg omx driver adds a small packet
header when sending a message to the remote processor, and is
currently returning this header length as well in the driver's write
fop function. This results in the write call always returning more
bytes than what the user has requested. The header length is now
left out of the bytes returned back.

Change-Id: I7132001fbc6fb34d01913bb3c30f455626c91658
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: copy_from_user() errors should return -EFAULT

rpmsg: omx: copy_from_user() errors should return -EFAULT

Change-Id: Ib4a2d92dd3b8afa18e60019871cfea2e6b446a4d
Signed-off-by: David Schleef <ds@ti.com>
rpmsg: omx: return ENXIO in rpmsg_omx_write

rpmsg: omx: return ENXIO in rpmsg_omx_write

The error code, ENXIO is used in rpmsg_omx driver to indicate
a terminal error on the remote processor side. This status is
maintained during the recovery of the remote processor, while
the cdev gets reinitialized/recreated.

The rpmsg_omx's write file operation is currently not returning
this error. This has been added now to have it behave in the
same way as the read file operation.

Change-Id: I61d6e6c07aa39208d913da622ed32d809c51d409
Signed-off-by: Vidhoon Viswanathan <vidhoon@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: fix copy_to_user in register/unregister ioctls

rpmsg: omx: fix copy_to_user in register/unregister ioctls

The ION fd registration and deregistration ioctls has the
arguments reversed in the copy_to_user() calls. The same
has been fixed.

Also included a minor additional case for returning a NULL
ION handle back to user-space.

Change-Id: I9d45957f9b913fa1775e70618f0da82e914a41d6
Signed-off-by: Tyler Luu <tluu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: send disconnect only if omx state is connected

rpmsg: omx: send disconnect only if omx state is connected

The rpmsg_omx driver sends a disconnect message automatically when the
driver's .release is called. This should be done only if a connection
has been established, otherwise just destroy the local end point.

Change-Id: I21b84aa6d91ae0d456f49cbe958f8e64caf691d5
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
rpmsg: omx: initialize completion event in rpmsg_omx_open

rpmsg: omx: initialize completion event in rpmsg_omx_open

An omx object is created when opening the rpmsg-omx device. However
the "reply_arrived" completion event is not initialized until the
connection message is sent across.

When the rpmsg_omx driver is removed (like in recovery), all pending
threads waiting on the "reply_arrived" are unblocked by a complete_all
call, however, if the rpmsg-omx device was only opened, such event is
not initialized yet, so the complete_all call will dereference a null
object causing a panic.

This patch moves the initialization of the "reply_arrived" completion
event to the open call, after the allocation of the omx object.

Change-Id: I92cf9cf5ac748456cb43bedc88fe1a8d80addd6c
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
rpmsg: omx: implement separate register ioctl for sgx buffers

rpmsg: omx: implement separate register ioctl for sgx buffers

This implements a new register ioctl specifically meant for sgx
buffers. rpmsg_omx clients are expected to call register ioctl
for the specific buffer type (ion or sgx) before sending a buffer
to .write for mapping. The registration allows the rpmsg_omx
driver to hold a reference to the ion buffers making up the sgx
buffer, thereby preventing the buffer(s) to be freed up from
under the remote processor.

The individual imported ion handles are expected to be passed
into the .write call.

When a client no longer expects remote processor to use the buffer,
client should call unregister ioctl. A separate unregister ioctl
for pvr buffers is not created, and the same ion unregister ioctl
is expected to be used for all the ion handles a sgx buffer is
comprised of.

Change-Id: Ib36aab90136627899e98717aeb29bfa637ec09fd
Signed-off-by: Tyler Luu <tluu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: resmgr: disable aux_clk_src in case of error

rpmsg: resmgr: disable aux_clk_src in case of error

If set_rate of aux_clk failed aux_clk_src was being left
enabled affecting the core OFF, fix the same.

Also avoid changing the return value of clk_set_rate.

Change-Id: I897d0669b43bf75ae49e9119ebfadf531bd585d5
Reported-by: Huzefa Kankroliwala <huzefank@ti.com>
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
omap: hwmod: enable clocks before deasserting hardreset

omap: hwmod: enable clocks before deasserting hardreset

The enable code currently deasserts the hard-reset before
turning on the clocks. These kind of reset lines are limited
only to processor-device like IPs such as DSP or IPU or
IVA, which actually need the clock to be enabled first.

The code that deasserts the hard-reset has therefore been
relocated to execute after the clocks are enabled, to avoid
the hard-deassert traces (failed to hard reset).

Change-Id: Id9c413b315c927295cf4be7f986f6e1a710b9ef8
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Oleg Matcovschi <oleg.matcovschi@ti.com>
Signed-off-by: Paul Hunt <hunt@ti.com>
OMAP4: HWMOD: UART1: disable smart-idle.

OMAP4: HWMOD: UART1: disable smart-idle.

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

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

Change-Id: Id1d97a498a5ffd7323be15be0ba8d0fc02e6df85
Signed-off-by: Ambresh K <ambresh@ti.com>
OMAP4: DSS: Implement workaround for Errata ID:i733.

OMAP4: DSS: Implement workaround for Errata ID:i733.

Description of Errata i733:
Due to wrong timings, all register accesses transitioning through the L4
interconnect toward DSS are not reliable.

Workaround:
DSS register access should be addressed through the L3 interconnect.

This change fixes errata by using L3 for access to DSS in dss_hwmod
instead of L4.

Silicon Versions Impacted:
OMAP4430 ES1.0, ES2.0, ES2.1, ES2.2, ES2.3
OMAP4460 ES1.0, ES1.1
OMAP4470 ES1.0

Change-Id: Ie087b861ee653a3beeacba74c3afe7b1a0490ed4
Co-author: Raghuveer Murthy <raghuveer.murthy@ti.com>
Signed-off-by: Mykhailo Denysiuk <x0172934@ti.com>
OMAP4: SAR: WA overwrite L3INIT CD mode to SW_SLEEP(1) in SAR

OMAP4: SAR: WA overwrite L3INIT CD mode to SW_SLEEP(1) in SAR

The wrong value of CM_L3INIT_CLKSTCTRL.CLKTRCTRL = 2 (SW_WKUP)
has been stored in SAR during omap4_sar_save() execution and
causes power over consumption on OFF mode due to C2C operation.
It happens because the L3INIT CD need to be enabled during
omap4_sar_save() execution for proper USBHOST module context storing.

Problematic use case:
1) OMAP goes to sleep,
2) modem wakeup the C2C, the EMIF but the MPU is still sleeping
(as expected)
3) Modem release all his constraints, C2C is turned to OFF.
4) but OMAP never reach again OFF while we don't wakeup the CPU
(by a keypress for example), sys_clk is already ON and voltages
are not equal to 0. (OPP 50 for CORE_3 and retention voltages
for both VCORE1 and VCORE2).

As WA overwrite CM_L3INIT_CLKSTCTRL.CLKTRCTRL = 0x1 (SW_SLEEP).

Change-Id: I2e453c07f61bab28a7213dd66044fd41a021961b
Signed-off-by: Arthur Cassegrain <a-cassegrain@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP4: PM: cold reset: wrong value is used to set LOGICRETSTATE

OMAP4: PM: cold reset: wrong value is used to set LOGICRETSTATE

The size of LOGICRETSTATE field is 1 bit, and pwrdm_set_logic_retst()
can accept only PWRDM_POWER_RET(0x1)/PWRDM_POWER_OFF(0x0) values.

Additional check of "pwrst" parameter and print out of error message
added in pwrdm_set_logic_retst() to minimize such issues in future.

Change-Id: I413e1e2ba3823574d4450225ed30cffb2cdfd565
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP: EMIF: fix LP_MODE_PWR_DN value definition

OMAP: EMIF: fix LP_MODE_PWR_DN value definition

According to TRM the EMIF Power-down mode is identified
by value 0x4 (EMIF_PWR_MGMT_CTRL.REG_LP_MODE)

Change-Id: I4d9b9534dea27ab4619af5b6d78de8ab14f0fead
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP4430: USB Host: Implement workaround for Errata i719

OMAP4430: USB Host: Implement workaround for Errata i719

The OMAP4 EHCI controller has the following defect (errata ID i719):

Title:
	HS USB: Multiple OFF Mode Transitions Introduce Corruption

Description:
	When the system enters off mode, the save-and-restore (SAR)
        process comes into play. When the save of the USB context
	occurs, an extra pulse of UTMI_root clock coming from USB
	DPLL is entering the IP, and generates a minor corruption.
	This corrupted context is saved and restored later.
	This corruption will impact the next use of the USB module:
	it could be while resuming a suspended device, or it could
	be upon the enumeration of a new device. The exact failure
	is not predictable: disconnection or stalls have been observed.
	TLL and external PHY modes are impacted.

WORKAROUND:
	During ON time, anytime before starting the next save sequence:
	• Set the CM_L3INIT_HSUSBHOST_CLKCTRL[1:0] MODULEMODE bit field
	  to 0x2 (enabled).
	• Wait 1 ms.
	• Set the same bit field back to 0x0 (disabled).

All OMAP4430 devices are impacted.

Change-Id: I63c866504ae3899c73755e6f6b00d388205c20bd
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
OMAP4430: USB Host: Implement workaround for Errata i687

OMAP4430: USB Host: Implement workaround for Errata i687

The OMAP4 EHCI controller has the following defect (errata ID i687):

Title:
	USB TLL Hold Timing Violation

Description:
	There is a timing hold violation on an internal logic on
	the clock USB TLL path resulting in a systematic connection
	failure on the TLL link

WORKAROUND:
	As part of workaround, next should be done:
	Set the I/O drive strength to 1.
	Depending which USB host subsystem is used,
	• Port B1 used: Set CONTROL.CONTROL_SMART2IO_PADCONF_2[11] USBB1_DR0_DS = 0x1
	• Port B2 used: Set CONTROL.CONTROL_SMART2IO_PADCONF_2[12] USBB2_DR0_DS = 0x1

All OMAP4430 devices are impacted.

Change-Id: Iba45e5a3b04a6180db3398edb8c00563f67f6105
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
ARM: OMAP4: USB: Update workaround for USB errata i719

ARM: OMAP4: USB: Update workaround for USB errata i719

Due to USB errata i719 the USB host save-and-restore context can be corrupted
if the device enters off mode more than two times without enabling the USB
host controller in between.

The corruption is occuring during the software save of the USB context which
occurs on entry to every off mode attempt. To avoid this problem only save the
USB context if the USB host controller has been enabled since the previous off
mode attempt. We do not need to save the USB context on every entry to off mode
if the USB controller has not been enabled.

Change-Id: I67e07963679af6494ef289eb10db09c0162d6f00
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Volodymyr Riazantsev <v.riazantsev@ti.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
usb: ehci: fix the host wakeup state machine.

usb: ehci: fix the host wakeup state machine.

Current code enables host clocks and disables immediately
which can have side effects if port status change is not propagated
and clocks are cut, so enable clocks if ports are suspended
in all wakeup paths either from io-pad wakeup or through
bus resume in suspend path.

Change-Id: I5a03fcf46160176289d41cda6574c0c261a13e94
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
ARM: OMAP: HS USB Host: fix unbalanced pm calls

ARM: OMAP: HS USB Host: fix unbalanced pm calls

There is an issue with unbalanced pm calls.
Only EHCI or only OHCI works good but not together.
Issue appears when OHCI suspends whereas EHCI is active
or vice versa - anyway all HSUSBHOST goes to suspend.
This patch fixes this issue.

Change-Id: Ie4c4e4d4ff210c8ceeec4415569660f8646e8ed5
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
USB: OHCI: do not poll root hub status if HC is not running

USB: OHCI: do not poll root hub status if HC is not running

If the OHCI root hub is suspended the clocks may be
not provided to HW and we get errors on OHCI registers
access. So do not poll it in such cases (like is done
for EHCI)

Change-Id: Ic81833a87c479822fe3c7f23792ee7ac7154e248
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>