linux.git/drivers/firmware/imx, branch v5.5 Linux kernel source tree firmware: imx: add missing include of <linux/firmware/imx/sci.h> 2019-10-28T06:50:09+00:00 Ben Dooks (Codethink) ben.dooks@codethink.co.uk 2019-10-22T15:40:09+00:00 e4f9eefbb8a976bb86dbdc9d2dd1a2a113801464 Include <linux/firmware/imx/sci.h> for the declarations of the functions exported from this driver. This fixes the following sparse warnings: drivers/firmware/imx/imx-scu-irq.c:45:5: warning: symbol 'imx_scu_irq_register_notifier' was not declared. Should it be static? drivers/firmware/imx/imx-scu-irq.c:52:5: warning: symbol 'imx_scu_irq_unregister_notifier' was not declared. Should it be static? drivers/firmware/imx/imx-scu-irq.c:97:5: warning: symbol 'imx_scu_irq_group_enable' was not declared. Should it be static? drivers/firmware/imx/imx-scu-irq.c:130:5: warning: symbol 'imx_scu_enable_general_irq_channel' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk> Signed-off-by: Shawn Guo <shawnguo@kernel.org> 
Include <linux/firmware/imx/sci.h> for the declarations of the
functions exported from this driver. This fixes the following
sparse warnings:

drivers/firmware/imx/imx-scu-irq.c:45:5: warning: symbol 'imx_scu_irq_register_notifier' was not declared. Should it be static?
drivers/firmware/imx/imx-scu-irq.c:52:5: warning: symbol 'imx_scu_irq_unregister_notifier' was not declared. Should it be static?
drivers/firmware/imx/imx-scu-irq.c:97:5: warning: symbol 'imx_scu_irq_group_enable' was not declared. Should it be static?
drivers/firmware/imx/imx-scu-irq.c:130:5: warning: symbol 'imx_scu_enable_general_irq_channel' was not declared. Should it be static?

Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
firmware: imx: Remove call to devm_of_platform_populate 2019-10-28T01:57:13+00:00 Daniel Baluta daniel.baluta@nxp.com 2019-10-14T15:32:28+00:00 0e4e8cc30a2940c57448af1376e40d3c0996fb29 IMX DSP device is created by SOF layer. The current call to devm_of_platform_populate is not needed and it doesn't produce any effects. Fixes: ffbf23d50353915d ("firmware: imx: Add DSP IPC protocol interface) Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> 
IMX DSP device is created by SOF layer. The current call to
devm_of_platform_populate is not needed and it doesn't produce
any effects.

Fixes: ffbf23d50353915d ("firmware: imx: Add DSP IPC protocol interface)
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
firmware: imx: Skip return value check for some special SCU firmware APIs 2019-10-14T12:48:17+00:00 Anson Huang Anson.Huang@nxp.com 2019-10-07T01:15:59+00:00 51f5afabc07a13e3d030076c772a1c36e1687b99 The SCU firmware does NOT always have return value stored in message header's function element even the API has response data, those special APIs are defined as void function in SCU firmware, so they should be treated as return success always. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> 
The SCU firmware does NOT always have return value stored in message
header's function element even the API has response data, those special
APIs are defined as void function in SCU firmware, so they should be
treated as return success always.

Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
firmware: imx: warn on unexpected RX 2019-10-06T00:58:59+00:00 Leonard Crestez leonard.crestez@nxp.com 2019-09-04T07:54:58+00:00 cf0fd404455ce13850cc15423a3c2958933de384 The imx_scu_call_rpc function returns the result inside the same "msg" struct containing the transmitted message. This is implemented by holding a pointer to msg (which is usually on the stack) in sc_imx_rpc and writing to it from imx_scu_rx_callback. This means that if the have_resp parameter is incorrect or SCU sends an unexpected response for any reason the most likely result is kernel stack corruption. Fix this by only setting sc_imx_rpc.msg for the duration of the imx_scu_call_rpc call and warning in imx_scu_rx_callback if unset. Print the unexpected response data to help debugging. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Acked-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> 
The imx_scu_call_rpc function returns the result inside the
same "msg" struct containing the transmitted message. This is
implemented by holding a pointer to msg (which is usually on the stack)
in sc_imx_rpc and writing to it from imx_scu_rx_callback.

This means that if the have_resp parameter is incorrect or SCU sends an
unexpected response for any reason the most likely result is kernel stack
corruption.

Fix this by only setting sc_imx_rpc.msg for the duration of the
imx_scu_call_rpc call and warning in imx_scu_rx_callback if unset.

Print the unexpected response data to help debugging.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Acked-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
firmware: imx: Add DSP IPC protocol interface 2019-08-12T13:19:25+00:00 Daniel Baluta daniel.baluta@nxp.com 2019-08-01T09:56:36+00:00 ffbf23d50353915dc2622a3b7b4ddc678165f92d Some of i.MX8 processors (e.g i.MX8QM, i.MX8QXP) contain the Tensilica HiFi4 DSP for advanced pre- and post-audio processing. The communication between Host CPU and DSP firmware is taking place using a shared memory area for message passing and a dedicated Messaging Unit for notifications. DSP IPC protocol offers a doorbell interface using imx-mailbox API. We use 4 MU channels (2 x TXDB, 2 x RXDB) to implement a request-reply protocol. Connection 0 (txdb0, rxdb0): - Host writes messasge to shared memory [SHMEM] - Host sends a request [MU] - DSP handles request [SHMEM] - DSP sends reply [MU] Connection 1 (txdb1, rxdb1): - DSP writes a message to shared memory [SHMEM] - DSP sends a request [MU] - Host handles request [SHMEM] - Host sends reply [MU] The protocol interface will be used by a Host client to communicate with the DSP. First client will be the i.MX8 part from Sound Open Firmware infrastructure. The protocol offers the following interface: On Tx: - imx_dsp_ring_doorbell, will be called to notify the DSP that it needs to handle a request. On Rx: - clients need to provide two callbacks: .handle_reply .handle_request - the callbacks will be used by the protocol on notification arrival from DSP. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> 
Some of i.MX8 processors (e.g i.MX8QM, i.MX8QXP) contain
the Tensilica HiFi4 DSP for advanced pre- and post-audio
processing.

The communication between Host CPU and DSP firmware is
taking place using a shared memory area for message passing
and a dedicated Messaging Unit for notifications.

DSP IPC protocol offers a doorbell interface using
imx-mailbox API.

We use 4 MU channels (2 x TXDB, 2 x RXDB) to implement a
request-reply protocol.

Connection 0 (txdb0, rxdb0):
        - Host writes messasge to shared memory [SHMEM]
	- Host sends a request [MU]
	- DSP handles request [SHMEM]
	- DSP sends reply [MU]

Connection 1 (txdb1, rxdb1):
	- DSP writes a message to shared memory [SHMEM]
	- DSP sends a request [MU]
	- Host handles request [SHMEM]
	- Host sends reply [MU]

The protocol interface will be used by a Host client to
communicate with the DSP. First client will be the i.MX8
part from Sound Open Firmware infrastructure.

The protocol offers the following interface:

On Tx:
   - imx_dsp_ring_doorbell, will be called to notify the DSP
   that it needs to handle a request.

On Rx:
   - clients need to provide two callbacks:
	.handle_reply
	.handle_request
  - the callbacks will be used by the protocol on
    notification arrival from DSP.

Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
firmware: imx: scu-pd: Add IRQSTR_DSP PD range 2019-07-23T07:50:09+00:00 Daniel Baluta daniel.baluta@nxp.com 2019-07-18T10:25:19+00:00 d43dc52274d40a1543ca962008feb9ff784e3a49 The DSP interrupt steer gathers interrupts from the system and can be used to steer them to DSP. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> 
The DSP interrupt steer gathers interrupts from the system
and can be used to steer them to DSP.

Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
firmware: imx: scu-pd: Add mu13 b side PD range 2019-07-23T07:49:54+00:00 Daniel Baluta daniel.baluta@nxp.com 2019-07-18T10:25:18+00:00 590b346b58badfe87cb13a64abdc8af25e907846 LSIO subsystem contains 14 MU instances. 5 MUs to communicate between AP <-> SCU - side-A PD range managed by AP - side-B PD range managed by SCU 9 MUs to communicate between all cores (AP/M4/DSP). - side-A PD range managed by core-A (AP/M4/DSP) - side-B PD range managed by core-B (AP/M4/DSP). Communication between AP <-> DSP is done through the assigned MU number 13. So, we power up side-A by the AP and we decide to power up side-B also from AP. This is because powering it up from DSP would be painful. Powering up side B from DSP would require the DSP to communicate with SCU and to keep things simple we don't want that now. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> 
LSIO subsystem contains 14 MU instances.

5 MUs to communicate between AP <-> SCU
  - side-A PD range managed by AP
  - side-B PD range managed by SCU

9 MUs to communicate between all cores (AP/M4/DSP).
  - side-A PD range managed by core-A (AP/M4/DSP)
  - side-B PD range managed by core-B (AP/M4/DSP).

Communication between AP <-> DSP is done through the
assigned MU number 13.

So, we power up side-A by the AP and we decide to
power up side-B also from AP. This is because powering
it up from DSP would be painful.

Powering up side B from DSP would require the DSP to
communicate with SCU and to keep things simple we don't
want that now.

Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
firmware: imx: scu-pd: Rename mu PD range to mu_a 2019-07-23T07:49:32+00:00 Daniel Baluta daniel.baluta@nxp.com 2019-07-18T10:25:17+00:00 6d9d21711b38c9cd5f70e04623151f498f3129ac The Messaging Unit module enables two processors within the SoC to communicate and coordinate by passing messages through the MU interface. MUs have 2 “sides” with independent programming interfaces. Rename mu PD range to mu_a because it's actually side A of MUs. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> 
The Messaging Unit module enables two processors within the SoC to
communicate and coordinate by passing messages through the MU interface.

MUs have 2 “sides” with independent programming interfaces. Rename
mu PD range to mu_a because it's actually side A of MUs.

Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Merge tag 'imx-fixes-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes 2019-06-16T20:26:55+00:00 Olof Johansson olof@lixom.net 2019-06-16T20:26:55+00:00 4bded299838ffb2735b73598ed5a008bd03023f3 i.MX fixes for 5.2: - A build fix for soc-imx8 driver which needs SOC_BUS support. To avoid dealing with the dependency for every single i.MX SoC bus driver, we selects at from architecture level. - A fix on i.MX SCU firmware driver to ensure SCU irq is enabled only after IPC is ready. - A regression fix on cpuidle-imx6sx driver, which causes some characters loss on serial communication. * tag 'imx-fixes-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: imx: cpuidle-imx6sx: Restrict the SW2ISO increase to i.MX6SX firmware: imx: SCU irq should ONLY be enabled after SCU IPC is ready arm64: imx: Fix build error without CONFIG_SOC_BUS Signed-off-by: Olof Johansson <olof@lixom.net> 
i.MX fixes for 5.2:
 - A build fix for soc-imx8 driver which needs SOC_BUS support.  To
   avoid dealing with the dependency for every single i.MX SoC bus
   driver, we selects at from architecture level.
 - A fix on i.MX SCU firmware driver to ensure SCU irq is enabled only
   after IPC is ready.
 - A regression fix on cpuidle-imx6sx driver, which causes some
   characters loss on serial communication.

* tag 'imx-fixes-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
  ARM: imx: cpuidle-imx6sx: Restrict the SW2ISO increase to i.MX6SX
  firmware: imx: SCU irq should ONLY be enabled after SCU IPC is ready
  arm64: imx: Fix build error without CONFIG_SOC_BUS

Signed-off-by: Olof Johansson <olof@lixom.net>
treewide: Add SPDX license identifier - Makefile/Kconfig 2019-05-21T08:50:46+00:00 Thomas Gleixner tglx@linutronix.de 2019-05-19T12:07:45+00:00 ec8f24b7faaf3d4799a7c3f4c1b87f6b02778ad1 Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Add SPDX license identifiers to all Make/Kconfig files which:

 - Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>