[PATCH v3 0/3] soc: ti: Introduce wkup_m3_ipc driver

[PATCH v3 0/3] soc: ti: Introduce wkup_m3_ipc driver

[Dave Gerlach]

Hi,
This series is version 3 of the code to introduce a wkup_m3_ipc driver
to handle communication between the MPU and Cortex M3 present on TI AM335x
and AM437x SoCs. v2 of this series can be found at [1]. Only patch 3
has been changed based on a request from Tony and a few cleanups:

- Rather than exporting all of the functionality of the driver, added
  wkup_m3_ipc_get and wkup_m3_ipc_put to allow users to just get a handle
  containing an ops structure for use.

- Changed all ops (previously exported functions) to take pointer to
  struct wkup_m3_ipc as an argument now that user code will get this
  from wkup_m3_ipc_get.

- General cleanup to probe function

- Added MODULE_DEVICE_TABLE so driver can probe automatically.

The series containing the DT nodes can be found here [2]. The actual dt
nodes for wkup_m3_ipc (last two patches) have been merged but discussion
is still open for the ti,mbox-send-noirq flag patches and depends on the
comments provided for the omap-mailbox change presented in patch 1 of
this series.

A full branch containing all necessary PM code for both am335x and am437x
has been pushed here [3] to provide a big picture view of the plan for
this series.

This driver relies on the firmware at [4] in the next-upstream branch
being present in /lib/firmware in the rootfs or built in to the kernel.

Regards,
Dave

[1] https://lkml.org/lkml/2015/7/17/797
[2] https://lkml.org/lkml/2015/7/17/813
[3] https://github.com/dgerlach/linux-pm/tree/pm-v4.3-rc1-amx3-suspend
[4] https://git.ti.com/ti-cm3-pm-firmware

Dave Gerlach (3):
  mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle
  Documentation: dt: add bindings for TI Wakeup M3 IPC device
  soc: ti: Add wkup_m3_ipc driver

 .../devicetree/bindings/mailbox/omap-mailbox.txt   |   8 +
 .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt     |  57 +++
 drivers/mailbox/omap-mailbox.c                     |  49 +-
 drivers/soc/ti/Kconfig                             |  10 +
 drivers/soc/ti/Makefile                            |   1 +
 drivers/soc/ti/wkup_m3_ipc.c                       | 508 +++++++++++++++++++++
 include/linux/wkup_m3_ipc.h                        |  55 +++
 7 files changed, 684 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
 create mode 100644 drivers/soc/ti/wkup_m3_ipc.c
 create mode 100644 include/linux/wkup_m3_ipc.h

-- 
2.4.6

[PATCH v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

[Dave Gerlach]

The mailbox framework controls the transmission queue and requires
either its controller implementations or clients to run the state
machine for the Tx queue. The OMAP mailbox controller uses a Tx-ready
interrupt as the equivalent of a Tx-done interrupt to run this Tx
queue state-machine.

The WkupM3 processor on AM33xx and AM43xx SoCs is used to offload
certain PM tasks, like doing the necessary operations for Device
PM suspend/resume or for entering lower c-states during cpuidle.

The CPUIdle on AM33xx requires the messages to be sent without
having to trigger the Tx-ready interrupts, as the interrupt
would immediately terminate the CPUIdle operation. Support for
this has been added by introducing a DT quirk, "ti,mbox-send-noirq"
and using it to modify the normal OMAP mailbox controller behavior
on the sub-mailboxes used to communicate with the WkupM3 remote
processor. This also requires the wkup_m3_ipc driver to adjust
its mailbox usage logic to run the Tx state machine.

NOTE:
- AM43xx does not communicate with WkupM3 for CPU Idle, so is
  not affected by this behavior. But, it uses the same IPC driver
  for PM suspend/resume functionality, so requires the quirk as
  well, because of changes to the common wkup_m3_ipc driver.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[s-anna@ti.com: revise logic and update comments/patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2->v3: Unchanged.

 .../devicetree/bindings/mailbox/omap-mailbox.txt   |  8 ++++
 drivers/mailbox/omap-mailbox.c                     | 49 ++++++++++++++++++++--
 2 files changed, 53 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
index d1a0433..9b40c49 100644
--- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -75,6 +75,14 @@ data that represent the following:
     Cell #3 (usr_id)  - mailbox user id for identifying the interrupt line
                         associated with generating a tx/rx fifo interrupt.
 
+Optional Properties:
+--------------------
+- ti,mbox-send-noirq:   Quirk flag to allow the client user of this sub-mailbox
+                        to send messages without triggering a Tx ready interrupt,
+                        and to control the Tx ticker. Should be used only on
+                        sub-mailboxes used to communicate with WkupM3 remote
+                        processor on AM33xx/AM43xx SoCs.
+
 Mailbox Users:
 ==============
 A device needing to communicate with a target processor device should specify
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index a3dbfd9..b7f636f 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -38,6 +38,8 @@
 #include <linux/mailbox_controller.h>
 #include <linux/mailbox_client.h>
 
+#include "mailbox.h"
+
 #define MAILBOX_REVISION		0x000
 #define MAILBOX_MESSAGE(m)		(0x040 + 4 * (m))
 #define MAILBOX_FIFOSTATUS(m)		(0x080 + 4 * (m))
@@ -106,6 +108,7 @@ struct omap_mbox_fifo_info {
 	int rx_irq;
 
 	const char *name;
+	bool send_no_irq;
 };
 
 struct omap_mbox {
@@ -119,6 +122,7 @@ struct omap_mbox {
 	u32			ctx[OMAP4_MBOX_NR_REGS];
 	u32			intr_type;
 	struct mbox_chan	*chan;
+	bool			send_no_irq;
 };
 
 /* global variables for the mailbox devices */
@@ -418,6 +422,9 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
 		goto fail_request_irq;
 	}
 
+	if (mbox->send_no_irq)
+		mbox->chan->txdone_method = TXDONE_BY_ACK;
+
 	_omap_mbox_enable_irq(mbox, IRQ_RX);
 
 	return 0;
@@ -586,13 +593,27 @@ static void omap_mbox_chan_shutdown(struct mbox_chan *chan)
 	mutex_unlock(&mdev->cfg_lock);
 }
 
-static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
+static int omap_mbox_chan_send_noirq(struct omap_mbox *mbox, void *data)
 {
-	struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
 	int ret = -EBUSY;
 
-	if (!mbox)
-		return -EINVAL;
+	if (!mbox_fifo_full(mbox)) {
+		_omap_mbox_enable_irq(mbox, IRQ_RX);
+		mbox_fifo_write(mbox, (mbox_msg_t)data);
+		ret = 0;
+		_omap_mbox_disable_irq(mbox, IRQ_RX);
+
+		/* we must read and ack the interrupt directly from here */
+		mbox_fifo_read(mbox);
+		ack_mbox_irq(mbox, IRQ_RX);
+	}
+
+	return ret;
+}
+
+static int omap_mbox_chan_send(struct omap_mbox *mbox, void *data)
+{
+	int ret = -EBUSY;
 
 	if (!mbox_fifo_full(mbox)) {
 		mbox_fifo_write(mbox, (mbox_msg_t)data);
@@ -604,6 +625,22 @@ static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
 	return ret;
 }
 
+static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
+{
+	struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+	int ret;
+
+	if (!mbox)
+		return -EINVAL;
+
+	if (mbox->send_no_irq)
+		ret = omap_mbox_chan_send_noirq(mbox, data);
+	else
+		ret = omap_mbox_chan_send(mbox, data);
+
+	return ret;
+}
+
 static const struct mbox_chan_ops omap_mbox_chan_ops = {
 	.startup        = omap_mbox_chan_startup,
 	.send_data      = omap_mbox_chan_send_data,
@@ -732,6 +769,9 @@ static int omap_mbox_probe(struct platform_device *pdev)
 			finfo->rx_usr = tmp[2];
 
 			finfo->name = child->name;
+
+			if (of_find_property(child, "ti,mbox-send-noirq", NULL))
+				finfo->send_no_irq = true;
 		} else {
 			finfo->tx_id = info->tx_id;
 			finfo->rx_id = info->rx_id;
@@ -791,6 +831,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
 		fifo->irqstatus = MAILBOX_IRQSTATUS(intr_type, finfo->rx_usr);
 		fifo->irqdisable = MAILBOX_IRQDISABLE(intr_type, finfo->rx_usr);
 
+		mbox->send_no_irq = finfo->send_no_irq;
 		mbox->intr_type = intr_type;
 
 		mbox->parent = mdev;
-- 
2.4.6

Re: [PATCH v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

[Jassi Brar]

On Wed, Sep 23, 2015 at 5:44 AM, Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> wrote:
> The mailbox framework controls the transmission queue and requires
> either its controller implementations or clients to run the state
> machine for the Tx queue. The OMAP mailbox controller uses a Tx-ready
> interrupt as the equivalent of a Tx-done interrupt to run this Tx
> queue state-machine.
>
> The WkupM3 processor on AM33xx and AM43xx SoCs is used to offload
> certain PM tasks, like doing the necessary operations for Device
> PM suspend/resume or for entering lower c-states during cpuidle.
>
> The CPUIdle on AM33xx requires the messages to be sent without
> having to trigger the Tx-ready interrupts, as the interrupt
> would immediately terminate the CPUIdle operation. Support for
> this has been added by introducing a DT quirk, "ti,mbox-send-noirq"
> and using it to modify the normal OMAP mailbox controller behavior
> on the sub-mailboxes used to communicate with the WkupM3 remote
> processor. This also requires the wkup_m3_ipc driver to adjust
> its mailbox usage logic to run the Tx state machine.
>
Probably Suman already updated you on what was discussed about this
patch at Connect-SFO. My suggestion was to drive TX poll-based (I
know, I know...) because the "interrupt-driven" is just an impression,
it is not really. You get the interrupt as soon as you enable it
because it is the "FIFO not-full" interrupt which is always because
there is always space left after writing to the fifo. The cons are
that it buffers messages hidden from the client while abusing the irq.
If you guys could break away from the "interrupt-driven" illusion and
use polling which it actually is, everything falls into place and you
avoid the "ti,mbox-send-noirq" quirk.

  Anyways I am OK too, if you guys want to fix it with a platform
specific quirk. Let me know I'll pick this patch.

Cheers!
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

[Suman Anna]

Hi Jassi,

On 10/20/2015 11:44 PM, Jassi Brar wrote:
> On Wed, Sep 23, 2015 at 5:44 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>> The mailbox framework controls the transmission queue and requires
>> either its controller implementations or clients to run the state
>> machine for the Tx queue. The OMAP mailbox controller uses a Tx-ready
>> interrupt as the equivalent of a Tx-done interrupt to run this Tx
>> queue state-machine.
>>
>> The WkupM3 processor on AM33xx and AM43xx SoCs is used to offload
>> certain PM tasks, like doing the necessary operations for Device
>> PM suspend/resume or for entering lower c-states during cpuidle.
>>
>> The CPUIdle on AM33xx requires the messages to be sent without
>> having to trigger the Tx-ready interrupts, as the interrupt
>> would immediately terminate the CPUIdle operation. Support for
>> this has been added by introducing a DT quirk, "ti,mbox-send-noirq"
>> and using it to modify the normal OMAP mailbox controller behavior
>> on the sub-mailboxes used to communicate with the WkupM3 remote
>> processor. This also requires the wkup_m3_ipc driver to adjust
>> its mailbox usage logic to run the Tx state machine.
>>
> Probably Suman already updated you on what was discussed about this
> patch at Connect-SFO. My suggestion was to drive TX poll-based (I
> know, I know...) because the "interrupt-driven" is just an impression,
> it is not really. You get the interrupt as soon as you enable it
> because it is the "FIFO not-full" interrupt which is always because
> there is always space left after writing to the fifo. The cons are
> that it buffers messages hidden from the client while abusing the irq.
> If you guys could break away from the "interrupt-driven" illusion and
> use polling which it actually is, everything falls into place and you
> avoid the "ti,mbox-send-noirq" quirk.

Looking at this closely, even with that approach, we would still need a
quirk to deal with the weird behavior of our wakeup m3. Essentially we
have two independent things:
1. Tx state machine (currently interrupt driven) for ticking the mailbox
core tx state machine.
2. A quirk that we need for dealing with Wakeup M3 behavior, MPU needs
to take out the message on behalf of WkupM3 processor after transmission
and clearing the IP-level interrupt intended for WkupM3. This will be
irrespective of the Tx state machine choice, and this needs to be
different only on the specific mbox channel used to talk with WkupM3
processor.

Previously, we were doing #2 in the OMAP mailbox regular interrupt
handler (handles both Rx and Tx interrupts) as part of the Rx interrupt
handler with the rx mbox variables reflecting those of the WkupM3
processor. But when we remove the interrupt processing, we now actually
need to add code to deal with this.

>   Anyways I am OK too, if you guys want to fix it with a platform
> specific quirk. Let me know I'll pick this patch.

I haven't gotten a chance to try #1, and I won't be able to look at it
atleast for another month. I suggest that you go ahead and pick this
patch up, as a quirk is needed in one form or the other for #2, and #1
is anyways a bigger change that will affect all our IPC stacks across
all pairs of MPU - remote processors on different SoCs.

regards
Suman

Re: [PATCH v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

[Jassi Brar]

On 22 October 2015 at 05:35, Suman Anna <s-anna@ti.com> wrote:

>>   Anyways I am OK too, if you guys want to fix it with a platform
>> specific quirk. Let me know I'll pick this patch.
>
> I haven't gotten a chance to try #1, and I won't be able to look at it
> atleast for another month. I suggest that you go ahead and pick this
> patch up, as a quirk is needed in one form or the other for #2, and #1
> is anyways a bigger change that will affect all our IPC stacks across
> all pairs of MPU - remote processors on different SoCs.
>
Yeah that is the reason I offered to pick this patch as such.
OK I'll take this patch.

Re: [PATCH v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

[Suman Anna]

On 10/21/2015 11:42 PM, Jassi Brar wrote:
> On 22 October 2015 at 05:35, Suman Anna <s-anna@ti.com> wrote:
> 
>>>   Anyways I am OK too, if you guys want to fix it with a platform
>>> specific quirk. Let me know I'll pick this patch.
>>
>> I haven't gotten a chance to try #1, and I won't be able to look at it
>> atleast for another month. I suggest that you go ahead and pick this
>> patch up, as a quirk is needed in one form or the other for #2, and #1
>> is anyways a bigger change that will affect all our IPC stacks across
>> all pairs of MPU - remote processors on different SoCs.
>>
> Yeah that is the reason I offered to pick this patch as such.
> OK I'll take this patch.

Thanks a lot. We will be a lot closer to get PM working on AM335/AM437x
SoCs.

regards
Suman

[PATCH v3 2/3] Documentation: dt: add bindings for TI Wakeup M3 IPC device

[Dave Gerlach]

Add the device tree bindings document for the TI Wakeup M3 IPC
device on AM33xx and AM43xx SoCs. These devices are used by the
TI wkup_m3_ipc driver, and contain the registers upon which the
IPC protocol to communicate with the Wakeup M3 processor is
implemented.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2->v3: Unchanged.

 .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt     | 57 ++++++++++++++++++++++
 1 file changed, 57 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt

diff --git a/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt b/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
new file mode 100644
index 0000000..4015504
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
@@ -0,0 +1,57 @@
+Wakeup M3 IPC Driver
+=====================
+
+The TI AM33xx and AM43xx family of devices use a small Cortex M3 co-processor
+(commonly referred to as Wakeup M3 or CM3) to help with various low power tasks
+that cannot be controlled from the MPU, like suspend/resume and certain deep
+C-states for CPU Idle. Once the wkup_m3_ipc driver uses the wkup_m3_rproc driver
+to boot the wkup_m3, it handles communication with the CM3 using IPC registers
+present in the SoC's control module and a mailbox. The wkup_m3_ipc exposes an
+API to allow the SoC PM code to execute specific PM tasks.
+
+Wkup M3 Device Node:
+====================
+A wkup_m3_ipc device node is used to represent the IPC registers within an
+SoC.
+
+Required properties:
+--------------------
+- compatible:		Should be,
+				"ti,am3352-wkup-m3-ipc" for AM33xx SoCs
+				"ti,am4372-wkup-m3-ipc" for AM43xx SoCs
+- reg:			Contains the IPC register address space to communicate
+			with the Wakeup M3 processor
+- interrupts:		Contains the interrupt information for the wkup_m3
+			interrupt that signals the MPU.
+- ti,rproc:		phandle to the wkup_m3 rproc node so the IPC driver
+			can boot it.
+- mboxes:		phandles used by IPC framework to get correct mbox
+			channel for communication. Must point to appropriate
+			mbox_wkupm3 child node.
+
+Example:
+--------
+/* AM33xx */
+	l4_wkup: l4_wkup@44c00000 {
+		...
+
+		scm: scm@210000 {
+			compatible = "ti,am3-scm", "simple-bus";
+			reg = <0x210000 0x2000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x210000 0x2000>;
+
+			...
+
+			wkup_m3_ipc: wkup_m3_ipc@1324 {
+				compatible = "ti,am3352-wkup-m3-ipc";
+				reg = <0x1324 0x24>;
+				interrupts = <78>;
+				ti,rproc = <&wkup_m3>;
+				mboxes = <&mailbox &mbox_wkupm3>;
+			};
+
+			...
+		};
+	};
-- 
2.4.6

[PATCH v3 3/3] soc: ti: Add wkup_m3_ipc driver

[Dave Gerlach]

Introduce a wkup_m3_ipc driver to handle communication between the MPU
and Cortex M3 wkup_m3 present on am335x.

This driver is responsible for actually booting the wkup_m3_rproc and
also handling all IPC which is done using the IPC registers in the control
module, a mailbox, and a separate interrupt back from the wkup_m3. A small
API is exposed for executing specific power commands, which include
configuring for low power mode, request a transition to a low power mode,
and status info on a previous transition.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v2->v3:
	- Added wkup_m3_ipc_ops to hold pointers to functions provided,
	  don't export anymore
	- Add wkup_m3_ipc_get and wkup_m3_ipc_put to return handle
	  to wkup_m3_ipc and ops struct
	- Add MODULE_DEVICE_TABLE
	- General probe function cleanup
	
 drivers/soc/ti/Kconfig       |  10 +
 drivers/soc/ti/Makefile      |   1 +
 drivers/soc/ti/wkup_m3_ipc.c | 508 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/wkup_m3_ipc.h  |  55 +++++
 4 files changed, 574 insertions(+)
 create mode 100644 drivers/soc/ti/wkup_m3_ipc.c
 create mode 100644 include/linux/wkup_m3_ipc.h

diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 7266b21..3557c5e 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -28,4 +28,14 @@ config KEYSTONE_NAVIGATOR_DMA
 
 	  If unsure, say N.
 
+config WKUP_M3_IPC
+	tristate "TI AMx3 Wkup-M3 IPC Driver"
+	depends on WKUP_M3_RPROC
+	depends on OMAP2PLUS_MBOX
+	help
+	  TI AM33XX and AM43XX have a Cortex M3, the Wakeup M3, to handle
+	  low power transitions. This IPC driver provides the necessary API
+	  to communicate and use the Wakeup M3 for PM features like suspend
+	  resume and boots it using wkup_m3_rproc driver.
+
 endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 135bdad..48ff3a7 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -4,3 +4,4 @@
 obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS)	+= knav_qmss.o
 knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
 obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA)	+= knav_dma.o
+obj-$(CONFIG_WKUP_M3_IPC)		+= wkup_m3_ipc.o
diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
new file mode 100644
index 0000000..8823cc8
--- /dev/null
+++ b/drivers/soc/ti/wkup_m3_ipc.c
@@ -0,0 +1,508 @@
+/*
+ * AMx3 Wkup M3 IPC driver
+ *
+ * Copyright (C) 2015 Texas Instruments, Inc.
+ *
+ * Dave Gerlach <d-gerlach@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/omap-mailbox.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc.h>
+#include <linux/suspend.h>
+#include <linux/wkup_m3_ipc.h>
+
+#define AM33XX_CTRL_IPC_REG_COUNT	0x8
+#define AM33XX_CTRL_IPC_REG_OFFSET(m)	(0x4 + 4 * (m))
+
+/* AM33XX M3_TXEV_EOI register */
+#define AM33XX_CONTROL_M3_TXEV_EOI	0x00
+
+#define AM33XX_M3_TXEV_ACK		(0x1 << 0)
+#define AM33XX_M3_TXEV_ENABLE		(0x0 << 0)
+
+#define IPC_CMD_DS0			0x4
+#define IPC_CMD_STANDBY			0xc
+#define IPC_CMD_IDLE			0x10
+#define IPC_CMD_RESET			0xe
+#define DS_IPC_DEFAULT			0xffffffff
+#define M3_VERSION_UNKNOWN		0x0000ffff
+#define M3_BASELINE_VERSION		0x191
+#define M3_STATUS_RESP_MASK		(0xffff << 16)
+#define M3_FW_VERSION_MASK		0xffff
+
+#define M3_STATE_UNKNOWN		0
+#define M3_STATE_RESET			1
+#define M3_STATE_INITED			2
+#define M3_STATE_MSG_FOR_LP		3
+#define M3_STATE_MSG_FOR_RESET		4
+
+static struct wkup_m3_ipc *m3_ipc_state;
+
+static void am33xx_txev_eoi(struct wkup_m3_ipc *m3_ipc)
+{
+	writel(AM33XX_M3_TXEV_ACK,
+	       m3_ipc->ipc_mem_base + AM33XX_CONTROL_M3_TXEV_EOI);
+}
+
+static void am33xx_txev_enable(struct wkup_m3_ipc *m3_ipc)
+{
+	writel(AM33XX_M3_TXEV_ENABLE,
+	       m3_ipc->ipc_mem_base + AM33XX_CONTROL_M3_TXEV_EOI);
+}
+
+static void wkup_m3_ctrl_ipc_write(struct wkup_m3_ipc *m3_ipc,
+				   u32 val, int ipc_reg_num)
+{
+	if (WARN(ipc_reg_num < 0 || ipc_reg_num > AM33XX_CTRL_IPC_REG_COUNT,
+		 "ipc register operation out of range"))
+		return;
+
+	writel(val, m3_ipc->ipc_mem_base +
+	       AM33XX_CTRL_IPC_REG_OFFSET(ipc_reg_num));
+}
+
+static unsigned int wkup_m3_ctrl_ipc_read(struct wkup_m3_ipc *m3_ipc,
+					  int ipc_reg_num)
+{
+	if (WARN(ipc_reg_num < 0 || ipc_reg_num > AM33XX_CTRL_IPC_REG_COUNT,
+		 "ipc register operation out of range"))
+		return 0;
+
+	return readl(m3_ipc->ipc_mem_base +
+		     AM33XX_CTRL_IPC_REG_OFFSET(ipc_reg_num));
+}
+
+static int wkup_m3_fw_version_read(struct wkup_m3_ipc *m3_ipc)
+{
+	int val;
+
+	val = wkup_m3_ctrl_ipc_read(m3_ipc, 2);
+
+	return val & M3_FW_VERSION_MASK;
+}
+
+static irqreturn_t wkup_m3_txev_handler(int irq, void *ipc_data)
+{
+	struct wkup_m3_ipc *m3_ipc = ipc_data;
+	struct device *dev = m3_ipc->dev;
+	int ver = 0;
+
+	am33xx_txev_eoi(m3_ipc);
+
+	switch (m3_ipc->state) {
+	case M3_STATE_RESET:
+		ver = wkup_m3_fw_version_read(m3_ipc);
+
+		if (ver == M3_VERSION_UNKNOWN ||
+		    ver < M3_BASELINE_VERSION) {
+			dev_warn(dev, "CM3 Firmware Version %x not supported\n",
+				 ver);
+		} else {
+			dev_info(dev, "CM3 Firmware Version = 0x%x\n", ver);
+		}
+
+		m3_ipc->state = M3_STATE_INITED;
+		complete(&m3_ipc->sync_complete);
+		break;
+	case M3_STATE_MSG_FOR_RESET:
+		m3_ipc->state = M3_STATE_INITED;
+		complete(&m3_ipc->sync_complete);
+		break;
+	case M3_STATE_MSG_FOR_LP:
+		complete(&m3_ipc->sync_complete);
+		break;
+	case M3_STATE_UNKNOWN:
+		dev_warn(dev, "Unknown CM3 State\n");
+	}
+
+	am33xx_txev_enable(m3_ipc);
+
+	return IRQ_HANDLED;
+}
+
+static int wkup_m3_ping(struct wkup_m3_ipc *m3_ipc)
+{
+	struct device *dev = m3_ipc->dev;
+	mbox_msg_t dummy_msg = 0;
+	int ret;
+
+	if (!m3_ipc->mbox) {
+		dev_err(dev,
+			"No IPC channel to communicate with wkup_m3!\n");
+		return -EIO;
+	}
+
+	/*
+	 * Write a dummy message to the mailbox in order to trigger the RX
+	 * interrupt to alert the M3 that data is available in the IPC
+	 * registers. We must enable the IRQ here and disable it after in
+	 * the RX callback to avoid multiple interrupts being received
+	 * by the CM3.
+	 */
+	ret = mbox_send_message(m3_ipc->mbox, &dummy_msg);
+	if (ret < 0) {
+		dev_err(dev, "%s: mbox_send_message() failed: %d\n",
+			__func__, ret);
+		return ret;
+	}
+
+	ret = wait_for_completion_timeout(&m3_ipc->sync_complete,
+					  msecs_to_jiffies(500));
+	if (!ret) {
+		dev_err(dev, "MPU<->CM3 sync failure\n");
+		m3_ipc->state = M3_STATE_UNKNOWN;
+		return -EIO;
+	}
+
+	mbox_client_txdone(m3_ipc->mbox, 0);
+	return 0;
+}
+
+static int wkup_m3_ping_noirq(struct wkup_m3_ipc *m3_ipc)
+{
+	struct device *dev = m3_ipc->dev;
+	mbox_msg_t dummy_msg = 0;
+	int ret;
+
+	if (!m3_ipc->mbox) {
+		dev_err(dev,
+			"No IPC channel to communicate with wkup_m3!\n");
+		return -EIO;
+	}
+
+	ret = mbox_send_message(m3_ipc->mbox, &dummy_msg);
+	if (ret < 0) {
+		dev_err(dev, "%s: mbox_send_message() failed: %d\n",
+			__func__, ret);
+		return ret;
+	}
+
+	mbox_client_txdone(m3_ipc->mbox, 0);
+	return 0;
+}
+
+static int wkup_m3_is_available(struct wkup_m3_ipc *m3_ipc)
+{
+	return ((m3_ipc->state != M3_STATE_RESET) &&
+		(m3_ipc->state != M3_STATE_UNKNOWN));
+}
+
+/* Public functions */
+/**
+ * wkup_m3_set_mem_type - Pass wkup_m3 which type of memory is in use
+ * @mem_type: memory type value read directly from emif
+ *
+ * wkup_m3 must know what memory type is in use to properly suspend
+ * and resume.
+ */
+static void wkup_m3_set_mem_type(struct wkup_m3_ipc *m3_ipc, int mem_type)
+{
+	m3_ipc->mem_type = mem_type;
+}
+
+/**
+ * wkup_m3_set_resume_address - Pass wkup_m3 resume address
+ * @addr: Physical address from which resume code should execute
+ */
+static void wkup_m3_set_resume_address(struct wkup_m3_ipc *m3_ipc, void *addr)
+{
+	m3_ipc->resume_addr = (unsigned long)addr;
+}
+
+/**
+ * wkup_m3_request_pm_status - Retrieve wkup_m3 status code after suspend
+ *
+ * Returns code representing the status of a low power mode transition.
+ *	0 - Successful transition
+ *	1 - Failure to transition to low power state
+ */
+static int wkup_m3_request_pm_status(struct wkup_m3_ipc *m3_ipc)
+{
+	unsigned int i;
+	int val;
+
+	val = wkup_m3_ctrl_ipc_read(m3_ipc, 1);
+
+	i = M3_STATUS_RESP_MASK & val;
+	i >>= __ffs(M3_STATUS_RESP_MASK);
+
+	return i;
+}
+
+/**
+ * wkup_m3_prepare_low_power - Request preparation for transition to
+ *			       low power state
+ * @state: A kernel suspend state to enter, either MEM or STANDBY
+ *
+ * Returns 0 if preparation was successful, otherwise returns error code
+ */
+static int wkup_m3_prepare_low_power(struct wkup_m3_ipc *m3_ipc, int state)
+{
+	struct device *dev = m3_ipc->dev;
+	int m3_power_state;
+	int ret = 0;
+
+	if (!wkup_m3_is_available(m3_ipc))
+		return -ENODEV;
+
+	switch (state) {
+	case WKUP_M3_DEEPSLEEP:
+		m3_power_state = IPC_CMD_DS0;
+		break;
+	case WKUP_M3_STANDBY:
+		m3_power_state = IPC_CMD_STANDBY;
+		break;
+	case WKUP_M3_IDLE:
+		m3_power_state = IPC_CMD_IDLE;
+		break;
+	default:
+		return 1;
+	}
+
+	/* Program each required IPC register then write defaults to others */
+	wkup_m3_ctrl_ipc_write(m3_ipc, m3_ipc->resume_addr, 0);
+	wkup_m3_ctrl_ipc_write(m3_ipc, m3_power_state, 1);
+	wkup_m3_ctrl_ipc_write(m3_ipc, m3_ipc->mem_type, 4);
+
+	wkup_m3_ctrl_ipc_write(m3_ipc, DS_IPC_DEFAULT, 2);
+	wkup_m3_ctrl_ipc_write(m3_ipc, DS_IPC_DEFAULT, 3);
+	wkup_m3_ctrl_ipc_write(m3_ipc, DS_IPC_DEFAULT, 5);
+	wkup_m3_ctrl_ipc_write(m3_ipc, DS_IPC_DEFAULT, 6);
+	wkup_m3_ctrl_ipc_write(m3_ipc, DS_IPC_DEFAULT, 7);
+
+	m3_ipc->state = M3_STATE_MSG_FOR_LP;
+
+	if (state == WKUP_M3_IDLE)
+		ret = wkup_m3_ping_noirq(m3_ipc);
+	else
+		ret = wkup_m3_ping(m3_ipc);
+
+	if (ret) {
+		dev_err(dev, "Unable to ping CM3\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+/**
+ * wkup_m3_finish_low_power - Return m3 to reset state
+ *
+ * Returns 0 if reset was successful, otherwise returns error code
+ */
+static int wkup_m3_finish_low_power(struct wkup_m3_ipc *m3_ipc)
+{
+	struct device *dev = m3_ipc->dev;
+	int ret = 0;
+
+	if (!wkup_m3_is_available(m3_ipc))
+		return -ENODEV;
+
+	wkup_m3_ctrl_ipc_write(m3_ipc, IPC_CMD_RESET, 1);
+	wkup_m3_ctrl_ipc_write(m3_ipc, DS_IPC_DEFAULT, 2);
+
+	m3_ipc->state = M3_STATE_MSG_FOR_RESET;
+
+	ret = wkup_m3_ping(m3_ipc);
+	if (ret) {
+		dev_err(dev, "Unable to ping CM3\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static struct wkup_m3_ipc_ops ipc_ops = {
+	.set_mem_type = wkup_m3_set_mem_type,
+	.set_resume_address = wkup_m3_set_resume_address,
+	.prepare_low_power = wkup_m3_prepare_low_power,
+	.finish_low_power = wkup_m3_finish_low_power,
+	.request_pm_status = wkup_m3_request_pm_status,
+};
+
+/**
+ * wkup_m3_ipc_get - Return handle to wkup_m3_ipc
+ *
+ * Returns NULL if the wkup_m3 is not yet available, otherwise returns
+ * pointer to wkup_m3_ipc struct.
+ */
+struct wkup_m3_ipc *wkup_m3_ipc_get(void)
+{
+	if (m3_ipc_state)
+		get_device(m3_ipc_state->dev);
+	else
+		return NULL;
+
+	return m3_ipc_state;
+}
+EXPORT_SYMBOL_GPL(wkup_m3_ipc_get);
+
+/**
+ * wkup_m3_ipc_put - Free handle to wkup_m3_ipc returned from wkup_m3_ipc_get
+ * @m3_ipc: A pointer to wkup_m3_ipc struct returned by wkup_m3_ipc_get
+ */
+void wkup_m3_ipc_put(struct wkup_m3_ipc *m3_ipc)
+{
+	if (m3_ipc_state)
+		put_device(m3_ipc_state->dev);
+}
+EXPORT_SYMBOL_GPL(wkup_m3_ipc_put);
+
+static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
+{
+	struct device *dev = m3_ipc->dev;
+	int ret;
+
+	wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
+
+	init_completion(&m3_ipc->sync_complete);
+
+	ret = rproc_boot(m3_ipc->rproc);
+	if (ret)
+		dev_err(dev, "rproc_boot failed\n");
+
+	do_exit(0);
+}
+
+static int wkup_m3_ipc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	int irq, ret;
+	phandle rproc_phandle;
+	struct rproc *m3_rproc;
+	struct resource *res;
+	struct task_struct *task;
+	struct wkup_m3_ipc *m3_ipc;
+
+	m3_ipc = devm_kzalloc(dev, sizeof(*m3_ipc), GFP_KERNEL);
+	if (!m3_ipc)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	m3_ipc->ipc_mem_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(m3_ipc->ipc_mem_base)) {
+		dev_err(dev, "could not ioremap ipc_mem\n");
+		return PTR_ERR(m3_ipc->ipc_mem_base);
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (!irq) {
+		dev_err(&pdev->dev, "no irq resource\n");
+		return -ENXIO;
+	}
+
+	ret = devm_request_irq(dev, irq, wkup_m3_txev_handler,
+			       0, "wkup_m3_txev", m3_ipc);
+	if (ret) {
+		dev_err(dev, "request_irq failed\n");
+		return ret;
+	}
+
+	m3_ipc->mbox_client.dev = dev;
+	m3_ipc->mbox_client.tx_done = NULL;
+	m3_ipc->mbox_client.tx_prepare = NULL;
+	m3_ipc->mbox_client.rx_callback = NULL;
+	m3_ipc->mbox_client.tx_block = false;
+	m3_ipc->mbox_client.knows_txdone = false;
+
+	m3_ipc->mbox = mbox_request_channel(&m3_ipc->mbox_client, 0);
+
+	if (IS_ERR(m3_ipc->mbox)) {
+		dev_err(dev, "IPC Request for A8->M3 Channel failed! %ld\n",
+			PTR_ERR(m3_ipc->mbox));
+		return PTR_ERR(m3_ipc->mbox);
+	}
+
+	if (of_property_read_u32(dev->of_node, "ti,rproc", &rproc_phandle)) {
+		dev_err(&pdev->dev, "could not get rproc phandle\n");
+		ret = -ENODEV;
+		goto err_free_mbox;
+	}
+
+	m3_rproc = rproc_get_by_phandle(rproc_phandle);
+	if (!m3_rproc) {
+		dev_err(&pdev->dev, "could not get rproc handle\n");
+		ret = -EPROBE_DEFER;
+		goto err_free_mbox;
+	}
+
+	m3_ipc->rproc = m3_rproc;
+	m3_ipc->dev = dev;
+	m3_ipc->state = M3_STATE_RESET;
+
+	m3_ipc->ops = &ipc_ops;
+
+	/*
+	 * Wait for firmware loading completion in a thread so we
+	 * can boot the wkup_m3 as soon as it's ready without holding
+	 * up kernel boot
+	 */
+	task = kthread_run((void *)wkup_m3_rproc_boot_thread, m3_ipc,
+			   "wkup_m3_rproc_loader");
+
+	if (IS_ERR(task)) {
+		dev_err(dev, "can't create rproc_boot thread\n");
+		goto err_put_rproc;
+	}
+
+	m3_ipc_state = m3_ipc;
+
+	return 0;
+
+err_put_rproc:
+	rproc_put(m3_rproc);
+err_free_mbox:
+	mbox_free_channel(m3_ipc->mbox);
+	return ret;
+}
+
+static int wkup_m3_ipc_remove(struct platform_device *pdev)
+{
+	mbox_free_channel(m3_ipc_state->mbox);
+
+	rproc_shutdown(m3_ipc_state->rproc);
+	rproc_put(m3_ipc_state->rproc);
+
+	m3_ipc_state = NULL;
+
+	return 0;
+}
+
+static const struct of_device_id wkup_m3_ipc_of_match[] = {
+	{ .compatible = "ti,am3352-wkup-m3-ipc", },
+	{ .compatible = "ti,am4372-wkup-m3-ipc", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, wkup_m3_ipc_of_match);
+
+static struct platform_driver wkup_m3_ipc_driver = {
+	.probe = wkup_m3_ipc_probe,
+	.remove = wkup_m3_ipc_remove,
+	.driver = {
+		.name = "wkup_m3_ipc",
+		.of_match_table = wkup_m3_ipc_of_match,
+	},
+};
+
+module_platform_driver(wkup_m3_ipc_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("wkup m3 remote processor ipc driver");
+MODULE_AUTHOR("Dave Gerlach <d-gerlach@ti.com>");
diff --git a/include/linux/wkup_m3_ipc.h b/include/linux/wkup_m3_ipc.h
new file mode 100644
index 0000000..d6ba7d3
--- /dev/null
+++ b/include/linux/wkup_m3_ipc.h
@@ -0,0 +1,55 @@
+/*
+ * TI Wakeup M3 for AMx3 SoCs Power Management Routines
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ * Dave Gerlach <d-gerlach@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _LINUX_WKUP_M3_IPC_H
+#define _LINUX_WKUP_M3_IPC_H
+
+#define WKUP_M3_DEEPSLEEP	1
+#define WKUP_M3_STANDBY		2
+#define WKUP_M3_IDLE		3
+
+#include <linux/mailbox_client.h>
+
+struct wkup_m3_ipc_ops;
+
+struct wkup_m3_ipc {
+	struct rproc *rproc;
+
+	void __iomem *ipc_mem_base;
+	struct device *dev;
+
+	int mem_type;
+	unsigned long resume_addr;
+	int state;
+
+	struct completion sync_complete;
+	struct mbox_client mbox_client;
+	struct mbox_chan *mbox;
+
+	struct wkup_m3_ipc_ops *ops;
+};
+
+struct wkup_m3_ipc_ops {
+	void (*set_mem_type)(struct wkup_m3_ipc *m3_ipc, int mem_type);
+	void (*set_resume_address)(struct wkup_m3_ipc *m3_ipc, void *addr);
+	int (*prepare_low_power)(struct wkup_m3_ipc *m3_ipc, int state);
+	int (*finish_low_power)(struct wkup_m3_ipc *m3_ipc);
+	int (*request_pm_status)(struct wkup_m3_ipc *m3_ipc);
+};
+
+struct wkup_m3_ipc *wkup_m3_ipc_get(void);
+void wkup_m3_ipc_put(struct wkup_m3_ipc *m3_ipc);
+#endif /* _LINUX_WKUP_M3_IPC_H */
-- 
2.4.6

Re: [PATCH v3 0/3] soc: ti: Introduce wkup_m3_ipc driver

[Tony Lindgren]

Hi all,

* Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> [150922 17:20]:
> Hi,
> This series is version 3 of the code to introduce a wkup_m3_ipc driver
> to handle communication between the MPU and Cortex M3 present on TI AM335x
> and AM437x SoCs. v2 of this series can be found at [1]. Only patch 3
> has been changed based on a request from Tony and a few cleanups:
> 
> - Rather than exporting all of the functionality of the driver, added
>   wkup_m3_ipc_get and wkup_m3_ipc_put to allow users to just get a handle
>   containing an ops structure for use.
> 
> - Changed all ops (previously exported functions) to take pointer to
>   struct wkup_m3_ipc as an argument now that user code will get this
>   from wkup_m3_ipc_get.
> 
> - General cleanup to probe function
> 
> - Added MODULE_DEVICE_TABLE so driver can probe automatically.
> 
> The series containing the DT nodes can be found here [2]. The actual dt
> nodes for wkup_m3_ipc (last two patches) have been merged but discussion
> is still open for the ti,mbox-send-noirq flag patches and depends on the
> comments provided for the omap-mailbox change presented in patch 1 of
> this series.
> 
> A full branch containing all necessary PM code for both am335x and am437x
> has been pushed here [3] to provide a big picture view of the plan for
> this series.
> 
> This driver relies on the firmware at [4] in the next-upstream branch
> being present in /lib/firmware in the rootfs or built in to the kernel.

Anybody got comments on this one? Should I pick up this series or
what's the plan?

Regards,

Tony


> [1] https://lkml.org/lkml/2015/7/17/797
> [2] https://lkml.org/lkml/2015/7/17/813
> [3] https://github.com/dgerlach/linux-pm/tree/pm-v4.3-rc1-amx3-suspend
> [4] https://git.ti.com/ti-cm3-pm-firmware
> 
> Dave Gerlach (3):
>   mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle
>   Documentation: dt: add bindings for TI Wakeup M3 IPC device
>   soc: ti: Add wkup_m3_ipc driver
> 
>  .../devicetree/bindings/mailbox/omap-mailbox.txt   |   8 +
>  .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt     |  57 +++
>  drivers/mailbox/omap-mailbox.c                     |  49 +-
>  drivers/soc/ti/Kconfig                             |  10 +
>  drivers/soc/ti/Makefile                            |   1 +
>  drivers/soc/ti/wkup_m3_ipc.c                       | 508 +++++++++++++++++++++
>  include/linux/wkup_m3_ipc.h                        |  55 +++
>  7 files changed, 684 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
>  create mode 100644 drivers/soc/ti/wkup_m3_ipc.c
>  create mode 100644 include/linux/wkup_m3_ipc.h
> 
> -- 
> 2.4.6
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/3] soc: ti: Introduce wkup_m3_ipc driver

[Dave Gerlach]

Hi,
On 10/20/2015 11:18 AM, Tony Lindgren wrote:
> Hi all,
>
> * Dave Gerlach <d-gerlach@ti.com> [150922 17:20]:
>> Hi,
>> This series is version 3 of the code to introduce a wkup_m3_ipc driver
>> to handle communication between the MPU and Cortex M3 present on TI AM335x
>> and AM437x SoCs. v2 of this series can be found at [1]. Only patch 3
>> has been changed based on a request from Tony and a few cleanups:
>>
>> - Rather than exporting all of the functionality of the driver, added
>>    wkup_m3_ipc_get and wkup_m3_ipc_put to allow users to just get a handle
>>    containing an ops structure for use.
>>
>> - Changed all ops (previously exported functions) to take pointer to
>>    struct wkup_m3_ipc as an argument now that user code will get this
>>    from wkup_m3_ipc_get.
>>
>> - General cleanup to probe function
>>
>> - Added MODULE_DEVICE_TABLE so driver can probe automatically.
>>
>> The series containing the DT nodes can be found here [2]. The actual dt
>> nodes for wkup_m3_ipc (last two patches) have been merged but discussion
>> is still open for the ti,mbox-send-noirq flag patches and depends on the
>> comments provided for the omap-mailbox change presented in patch 1 of
>> this series.
>>
>> A full branch containing all necessary PM code for both am335x and am437x
>> has been pushed here [3] to provide a big picture view of the plan for
>> this series.
>>
>> This driver relies on the firmware at [4] in the next-upstream branch
>> being present in /lib/firmware in the rootfs or built in to the kernel.
>
> Anybody got comments on this one? Should I pick up this series or
> what's the plan?

Now that Patch 1 has been merged [1] can patch 2 and 3 be picked up? 
These apply cleanly on v4.4-rc3.

Regards,
Dave

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8e3c5952144f045a0c81bf674d3f5e1d9aafceb7

>
> Regards,
>
> Tony
>
>
>> [1] https://lkml.org/lkml/2015/7/17/797
>> [2] https://lkml.org/lkml/2015/7/17/813
>> [3] https://github.com/dgerlach/linux-pm/tree/pm-v4.3-rc1-amx3-suspend
>> [4] https://git.ti.com/ti-cm3-pm-firmware
>>
>> Dave Gerlach (3):
>>    mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle
>>    Documentation: dt: add bindings for TI Wakeup M3 IPC device
>>    soc: ti: Add wkup_m3_ipc driver
>>
>>   .../devicetree/bindings/mailbox/omap-mailbox.txt   |   8 +
>>   .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt     |  57 +++
>>   drivers/mailbox/omap-mailbox.c                     |  49 +-
>>   drivers/soc/ti/Kconfig                             |  10 +
>>   drivers/soc/ti/Makefile                            |   1 +
>>   drivers/soc/ti/wkup_m3_ipc.c                       | 508 +++++++++++++++++++++
>>   include/linux/wkup_m3_ipc.h                        |  55 +++
>>   7 files changed, 684 insertions(+), 4 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
>>   create mode 100644 drivers/soc/ti/wkup_m3_ipc.c
>>   create mode 100644 include/linux/wkup_m3_ipc.h
>>
>> --
>> 2.4.6
>>

Re: [PATCH v3 0/3] soc: ti: Introduce wkup_m3_ipc driver

[Tony Lindgren]

* Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> [151202 12:30]:
> On 10/20/2015 11:18 AM, Tony Lindgren wrote:
> >* Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> [150922 17:20]:
> >>This series is version 3 of the code to introduce a wkup_m3_ipc driver
> >>to handle communication between the MPU and Cortex M3 present on TI AM335x
> >>and AM437x SoCs. v2 of this series can be found at [1]. Only patch 3
> >>has been changed based on a request from Tony and a few cleanups:
> >>
> >>- Rather than exporting all of the functionality of the driver, added
> >>   wkup_m3_ipc_get and wkup_m3_ipc_put to allow users to just get a handle
> >>   containing an ops structure for use.
> >>
> >>- Changed all ops (previously exported functions) to take pointer to
> >>   struct wkup_m3_ipc as an argument now that user code will get this
> >>   from wkup_m3_ipc_get.
> >>
> >>- General cleanup to probe function
> >>
> >>- Added MODULE_DEVICE_TABLE so driver can probe automatically.
> >>
> >>The series containing the DT nodes can be found here [2]. The actual dt
> >>nodes for wkup_m3_ipc (last two patches) have been merged but discussion
> >>is still open for the ti,mbox-send-noirq flag patches and depends on the
> >>comments provided for the omap-mailbox change presented in patch 1 of
> >>this series.
> >>
> >>A full branch containing all necessary PM code for both am335x and am437x
> >>has been pushed here [3] to provide a big picture view of the plan for
> >>this series.
> >>
> >>This driver relies on the firmware at [4] in the next-upstream branch
> >>being present in /lib/firmware in the rootfs or built in to the kernel.
> >
> >Anybody got comments on this one? Should I pick up this series or
> >what's the plan?
> 
> Now that Patch 1 has been merged [1] can patch 2 and 3 be picked up? These
> apply cleanly on v4.4-rc3.

OK applying 1 & 2 into omap-for-v4.5/drivers.

Regards,

Tony

> [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8e3c5952144f045a0c81bf674d3f5e1d9aafceb7

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html