Fix below build warning:
warning: format ‘%li’ expects argument of type ‘long int’, but argument 3 has type ‘unsigned int’ [-Wformat=]
"Exceed max msg size (%li) on TX, got: %i\n",
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
IPC MU has no power domain assigned and there could be IPC
during noirq suspend phase, so IRQF_NO_SUSPEND flag is needed
for IPC MU. However, for other MUs, they have power domain
assigned and their power will be turned off during noirq suspend
phase, but their interrupts are NOT disabled even after their
power turned off, it will cause system crash when mailbox driver
trys to handle pending interrupts but the MU power is accidently
turned off.
So, IRQF_NO_SUSPEND flag should ONLY be added to IPC MU which
has power domain managed by SCU, then all other MUs' pending
interrupts after noirq suspend phase will be handled after
system resume.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
On i.MX8MP, the MU clock is combined with power domain and runtime
PM is enabled, during noirq suspend/resume phase, runtime PM is
disabled by device suspend, calling clock prepare will trigger
runtime resume failure and lead to system suspend failed.
There is no good way to handle such MU clocks combined with runtime
PM in noirq suspend phase, actually, the MU context save/restore is
ONLY necessary for SCU IPC MU, other MUs especially on i.MX8MP platforms
which have clocks assigned, they need to runtime request/free mailbox
channel in the consumer driver, so no need to save/restore MU context
for them, hence it can avoid this issue.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Some of i.MX8M SoCs have MU clock, they need to be managed in runtime
to make sure the MU domain can be off in runtime, add runtime PM
callback to handle MU clock.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
The remote processor can take some time to read/write to
the MU and the previous timeout was not based on a temporal
value. It is better to use a temporal variable so the code
will always have the same behavior.
There is no specification about the timeout to set, just to have
something in the range of few seconds, so chosen 3.
This patch changes the timeout to be based on time.
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
In case the reception of the message fails, the client is not
informed.
This patch sends the error to client using mbox_chan_received_data
with error code encoded in the address of the message.
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
During noirq suspend/resume, if MU context is NOT lost, such
as freeze mode suspend, when resume, there could be 2 CPUs
calling IPC, 1 CPU is in charge of handling wakeup event, the
other CPU is busy with device resume flow, the MU TIE could
be set during IPC called by the CPU handling wakeup event,
then the noirq resume callback in mailbox will be called by
the CPU executing device resume, it could overwrite the MU
settings and clear TIE by mistake, then cause the TX never
finish and IPC mutex lock never released, and system will
freeze, all CPUs are in idle and never wake up.
To avoid this issue, we should ONLY restore the MU settings
when its context is lost.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reported-by: Clark Wang <xiaoning.wang@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Some power hungry sub-systems like VPU has its own MUs which also
use mailbox driver, current mailbox driver uses platform driver
model and MU's power will be ON after driver probed and left ON
there, it may cause the whole sub-system can NOT enter lower power
mode, take VPU driver for example, it has runtime PM support, but
due to its MU always ON, the VPU sub-system will be always ON and
consume many power during kernel idle.
To save power in kernel idle, mailbox driver needs to support
runtime PM in order to power off MU when it is unused. However,
the runtime suspend/resume can ONLY be implemented in mailbox's
.shutdown/.startup callback, so its consumer needs to call
mbox_request_channel()/mbox_free_channel() in consumer driver's
runtime PM callback, then the MU's power will be ON/OFF along with
consumer's runtime PM status.
For those consumers never call mbox_free_channel(), MU's power will
be still ON always, if there is obvious power increase observed, we
will request the consumer to free mailbox channel to save power.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
i.MX8/8X SECO firmware IPC is an implementation of passing messages.
But current imx-mailbox driver only support one word message,
i.MX8/8X linux side firmware has to request four TX, four RX and a
TXDB to support IPC to SECO firmware. This is low efficent and
more interrupts triggered compared with one TX and one RX.
To make SECO MU work,
- parse the size of msg.
- Only enable TR0/RR0 interrupt for transmit/receive message.
- For TX/RX, only support one TX channel and one RX channel
- For RX, support receive msg of any size, linited by hardcoded value of 30.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
Add imx_mu_generic_tx for data send and imx_mu_generic_rx for interrupt
data receive.
Pack original mu chans related code into imx_mu_init_generic
Add tx/rx/init hooks into imx_mu_dcfg
With these, it will be a bit easy to introduce i.MX8/8X SCU type
MU dedicated to communicate with SCU.
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
There is a version 1.0 MU on i.MX7ULP platform.
One new version ID register is added, and it's offset is 0.
TRn registers are defined at the offset 0x20 ~ 0x2C.
RRn registers are defined at the offset 0x40 ~ 0x4C.
SR/CR registers are defined at 0x60/0x64.
Extend this driver to support it.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Suggested-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Make sure to only clear enabled interrupts keeping count
of the connection type.
Suggested-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
GIEn is enabled at startup for RX doorbell mailboxes so
we need to clear the bit at shutdown in order to avoid
leaving the interrupt line enabled.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Use the new helper devm_platform_ioremap_resource() which wraps the
platform_get_resource() and devm_ioremap_resource() together, to
simplify the code.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
During noirq suspend phase, mailbox MU irq will be masked
but many drivers still need to communicate with system
controller firmware via mailbox, if MU irq is masked, it
will cause RPC timeout as below:
[ 23.372103] imx-scu scu: RPC send msg timeout
Setting MU irq to be wakeup source is NOT working as GIC
driver does NOT have .irq_set_wake implemented, so to
support suspend/resume, just make imx mailbox driver NOT
suspend, since MU is always a wakeup source on i.MX platforms
with system controller inside, and its power/clock is
maintained by system controller, mailbox driver no need
to manage them.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Get rid of some boilerplate driver removal code by using the newly added
device-managed registration API.
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The i.MX Messaging Unit is a two side block which allows applications
implement communication over this sides.
The MU includes the following features:
- Messaging control by interrupts or by polling
- Four general-purpose interrupt requests reflected to the other side
- Three general-purpose flags reflected to the other side
- Four receive registers with maskable interrupt
- Four transmit registers with maskable interrupt
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Peng Fan