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-gerl...@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



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

Re: [PATCH v2] arm, am335x: add support for the bosch shc board

[Dave Gerlach]

Hi,
On 11/17/2015 02:24 AM, Heiko Schocher wrote:

add support for the am335x based shc board.

UART: 0-2 and 4
DRAM: 512 MiB
MMC:  OMAP SD/MMC: 0 @ 26 MHz
   OMAP SD/MMC: 1 @ 26 MHz
I2C:  at24 eeprom, pcf8563
USB:  USB1 (host)

Signed-off-by: Heiko Schocher 
---
The following patches are needed to get all working
for the shc board:
- disable clkout on pcf8563
   accepted.
   http://www.spinics.net/lists/devicetree/msg98542.html

- leds: leds-gpio: add shutdown function
   accepted.
   https://lkml.org/lkml/2015/10/13/169

- net: phy: smsc: disable energy detect mode
   accepted
   [PATCH v2 2/2] net: phy: smsc: disable energy detect mode
   https://lkml.org/lkml/2015/10/17/2
   [PATCH v2 1/2] drivers: net: cpsw: add phy-handle parsing
   https://lkml.org/lkml/2015/10/17/4

- ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328204.html
   @Dave: What is the current state of this patch?
   I have the same problem here on this am335x based board



A different approach is being taken for resolving the issue of rtc hwmod 
on am43x epos evm [1], which is what I was attempting to solve with the 
patch you have linked. We decided to avoid changing omap_hwmod code and 
I haven't been pursuing the ti,no-init flag anymore.


Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg121987.html


- [PATCH v2] regulator: tps65217: remove tps65217.dtsi file
   http://www.kernelhub.org/?msg=868907=2

- bootlog and automated tests:
   http://xeidos.ddns.net/buildbot/waterfall

Changes in v2:
- Use IOPAD pinmux macro as Robert Nelson
   suggested.

  arch/arm/boot/dts/Makefile   |   3 +-
  arch/arm/boot/dts/am335x-shc.dts | 577 +++
  2 files changed, 579 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/boot/dts/am335x-shc.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..65d750f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -466,7 +466,8 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-pepper.dtb \
am335x-lxm.dtb \
am335x-chiliboard.dtb \
-   am335x-wega-rdk.dtb
+   am335x-wega-rdk.dtb \
+   am335x-shc.dtb
  dtb-$(CONFIG_ARCH_OMAP4) += \
omap4-duovero-parlor.dtb \
omap4-panda.dtb \
diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
new file mode 100644
index 000..1b5b044
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -0,0 +1,577 @@
+/*
+ * support for the bosch am335x based shc c3 board
+ *
+ * Copyright, C) 2015 Heiko Schocher 
+ *
+ * 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.
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include 
+
+/ {
+   model = "Bosch SHC";
+   compatible = "ti,am335x-shc", "ti,am335x-bone", "ti,am33xx";
+
+   aliases {
+   mmcblk0 = 
+   mmcblk1 = 
+   };
+
+   cpus {
+   cpu@0 {
+   /*
+* To consider voltage drop between PMIC and SoC,
+* tolerance value is reduced to 2% from 4% and
+* voltage value is increased as a precaution.
+*/
+   operating-points = <
+   /* kHzuV */
+   594000  1225000
+   294000  1125000
+   >;
+   voltage-tolerance = <2>; /* 2 percentage */
+   cpu0-supply = <_reg>;
+   };
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+
+   back_button {
+   label = "Back Button";
+   gpios = < 29 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   debounce-interval = <1000>;
+   gpio-key,wakeup;
+   };
+
+   front_button {
+   label = "Front Button";
+   gpios = < 25 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   debounce-interval = <1000>;
+   gpio-key,wakeup;
+   };
+   };
+
+   leds {
+   pinctrl-names = "default";
+   pinctrl-0 = <_leds_s0>;
+
+   compatible = "gpio-leds";
+
+   led@1 {
+   label = "shc:power:red";
+   gpios = < 23 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led@2 {
+   label = "shc:power:bl";
+   gpios = < 22 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "timer";
+   

[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-gerl...@ti.com>
[s-a...@ti.com: revise logic and update comments/patch description]
Signed-off-by: Suman Anna <s-a...@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 
 #include 
 
+#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;
+   boolsend_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(>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_ch

[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-gerl...@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 000..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-gerl...@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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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_DS00x4
+#define IPC_CMD_STANDBY0xc
+#define IPC_CMD_IDLE   0x10
+#define IPC_CMD_RESET  0xe
+#define DS_IPC_DEFAULT 0x
+#define M3_VERSION_UNKNOWN 0x
+#define M3_BASELINE_VERSION0x191
+#define M3_STATUS_RESP_MASK(0x << 16)
+#define M3_FW_VERSION_MASK 0x
+
+#define M3_STATE_UNKNOWN   0
+#define M3_STATE_RESET 1
+#define M3_STATE_INITED2
+#define M3_STATE_MSG_FOR_LP3
+#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));
+}
+
+

[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

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

[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-gerl...@ti.com>
Signed-off-by: Suman Anna <s-a...@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 000..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@44c0 {
+   ...
+
+   scm: scm@21 {
+   compatible = "ti,am3-scm", "simple-bus";
+   reg = <0x21 0x2000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x21 0x2000>;
+
+   ...
+
+   wkup_m3_ipc: wkup_m3_ipc@1324 {
+   compatible = "ti,am3352-wkup-m3-ipc";
+   reg = <0x1324 0x24>;
+   interrupts = <78>;
+   ti,rproc = <_m3>;
+   mboxes = < _wkupm3>;
+   };
+
+   ...
+   };
+   };
-- 
2.4.6

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

[PATCH] remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export alias

[Dave Gerlach]

Use MODULE_DEVICE_TABLE with wkup_m3_rproc_of_match so the module alias
is exported and the wkup_m3_rproc driver can automatically probe.

Signed-off-by: Dave Gerlach <d-gerl...@ti.com>
---
 drivers/remoteproc/wkup_m3_rproc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/remoteproc/wkup_m3_rproc.c 
b/drivers/remoteproc/wkup_m3_rproc.c
index edf8181..02d271d 100644
--- a/drivers/remoteproc/wkup_m3_rproc.c
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -122,6 +122,7 @@ static const struct of_device_id wkup_m3_rproc_of_match[] = 
{
{ .compatible = "ti,am4372-wkup-m3", },
{},
 };
+MODULE_DEVICE_TABLE(of, wkup_m3_rproc_of_match);
 
 static int wkup_m3_rproc_probe(struct platform_device *pdev)
 {
-- 
2.4.6

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

[PATCH] input: touchscreen: ti_am335x_tsc: Fix HWPEN interrupt handling

[Dave Gerlach]

Remove write to REG_IRQCLR and REG_IRQWAKEUP in interrupt handler for
IRQENB_HW_PEN as the resume handler should and does clear REG_IRQWAKEUP.
IRQENB_HW_PEN bit is set in irqclr so that all interrupts get cleared
later so let IRQENB_HW_PEN be cleared by that.

Without this patch wakeup events from TSC_ADC do not work because pending
interrupts in TSC_ADC were causing HW_PEN interrupt, needed for wake from
suspend modes, to get disabled immediately by IRQ handler after being
enabled and preventing wake from happening.

Signed-off-by: Dave Gerlach <d-gerl...@ti.com>
---
 drivers/input/touchscreen/ti_am335x_tsc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 191a1b8..a21a07c 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -273,8 +273,6 @@ static irqreturn_t titsc_irq(int irq, void *dev)
status = titsc_readl(ts_dev, REG_RAWIRQSTATUS);
if (status & IRQENB_HW_PEN) {
ts_dev->pen_down = true;
-   titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00);
-   titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
irqclr |= IRQENB_HW_PEN;
}
 
-- 
2.4.6

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

[PATCH] ARM: OMAP2+: AM43XX: Enable autoidle for clks in am43xx_init_late

[Dave Gerlach]

Add omap2_clk_enable_autoidle_all to am43xx_init_late otherwise the call
to omap2_clk_disable_autoidle_all in am43xx_init_early may cause some
clocks to always stay active and prevent low power mode transitions.

Signed-off-by: Dave Gerlach <d-gerl...@ti.com>
---
 arch/arm/mach-omap2/io.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 980c937..3eaeaca 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -676,6 +676,7 @@ void __init am43xx_init_early(void)
 void __init am43xx_init_late(void)
 {
omap_common_late_init();
+   omap2_clk_enable_autoidle_all();
 }
 #endif
 
-- 
2.4.6

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

Re: [PATCH v2 3/3] soc: ti: Add wkup_m3_ipc driver

[Dave Gerlach]

On 07/20/2015 01:16 AM, Tony Lindgren wrote:

* Dave Gerlach d-gerl...@ti.com [150717 13:59]:

+
+/* Public functions */

...

+EXPORT_SYMBOL_GPL(wkup_m3_set_mem_type);
+EXPORT_SYMBOL_GPL(wkup_m3_set_resume_address);
+EXPORT_SYMBOL_GPL(wkup_m3_request_pm_status);
+EXPORT_SYMBOL_GPL(wkup_m3_prepare_low_power);
+EXPORT_SYMBOL_GPL(wkup_m3_finish_low_power);


I think you can avoid exporting these SoC specific functions
by just exporting wkup_m3_request() and wkup_m3_free() type
functions with a data structure containing the necessary
function pointers.


Ok thanks for the comment, I can try that change out, I agree it 
probably isn't necessary to export so much.


Regards,
Dave



Regards,

Tony



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 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-gerl...@ti.com
---
 drivers/soc/ti/Kconfig   |  10 +
 drivers/soc/ti/Makefile  |   1 +
 drivers/soc/ti/wkup_m3_ipc.c | 486 +++
 include/linux/wkup_m3_ipc.h  |  30 +++
 4 files changed, 527 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 000..7eb05aa
--- /dev/null
+++ b/drivers/soc/ti/wkup_m3_ipc.c
@@ -0,0 +1,486 @@
+/*
+ * AMx3 Wkup M3 IPC driver
+ *
+ * Copyright (C) 2015 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@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/mailbox_client.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_DS00x4
+#define IPC_CMD_STANDBY0xc
+#define IPC_CMD_IDLE   0x10
+#define IPC_CMD_RESET  0xe
+#define DS_IPC_DEFAULT 0x
+#define M3_VERSION_UNKNOWN 0x
+#define M3_BASELINE_VERSION0x191
+#define M3_STATUS_RESP_MASK(0x  16)
+#define M3_FW_VERSION_MASK 0x
+
+#define M3_STATE_UNKNOWN   0
+#define M3_STATE_RESET 1
+#define M3_STATE_INITED2
+#define M3_STATE_MSG_FOR_LP3
+#define M3_STATE_MSG_FOR_RESET 4
+
+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;
+};
+
+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

[PATCH v2 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-gerl...@ti.com
[s-a...@ti.com: revise logic and update comments/patch description]
Signed-off-by: Suman Anna s-a...@ti.com
---
 .../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;
+   boolsend_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

[PATCH 4/4] ARM: dts: AM4372: Add the wkup_m3_ipc node

[Dave Gerlach]

From: Suman Anna s-a...@ti.com

Add the Wakeup M3 IPC device node for the wkup_m3_ipc driver on
AM4372 SoC. This node uses the IPC registers, part of the Control
Module, and is therefore added as a child of the scm node.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 5bccc48..45bcd1b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -136,6 +136,14 @@
};
};
 
+   wkup_m3_ipc: wkup_m3_ipc@1324 {
+   compatible = ti,am4372-wkup-m3-ipc;
+   reg = 0x1324 0x44;
+   interrupts = GIC_SPI 78 
IRQ_TYPE_LEVEL_HIGH;
+   ti,rproc = wkup_m3;
+   mboxes = mailbox mbox_wkupm3;
+   };
+
scm_clockdomains: clockdomains {
};
};
-- 
2.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] ARM: dts: am335x/am43xx: wkup_m3_ipc support patches

[Dave Gerlach]

Hi,

This series adds the necessary dt nodes for the wkup_m3_ipc on am335x
and am437x and also adds the ti,mbox-send-noirq flag to the wkup_m3
mailbox on both platforms as well so that we can use mailbox from
noirq context when needed. This series is to make use of the
driver introduced here [1].

Regards,
Dave

[1] http://www.spinics.net/lists/arm-kernel/msg432612.html

Dave Gerlach (1):
  ARM: dts: AM33xx: Add ti,mbox-send-noirq to wkup_m3 mailbox

Keerthy (1):
  ARM: dts: AM4372: Add ti,mbox-send-noirq to wkup_m3 mailbox

Suman Anna (2):
  ARM: dts: AM33xx: Add the wkup_m3_ipc node
  ARM: dts: AM4372: Add the wkup_m3_ipc node

 arch/arm/boot/dts/am33xx.dtsi | 9 +
 arch/arm/boot/dts/am4372.dtsi | 9 +
 2 files changed, 18 insertions(+)

-- 
2.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] ARM: dts: AM4372: Add ti,mbox-send-noirq to wkup_m3 mailbox

[Dave Gerlach]

From: Keerthy j-keer...@ti.com

Add ti,mbox-send-noirq to wkup_m3 mailbox so that messages using
wkup_m3 mailbox are sent without triggering any further interrupts.
This is required to be able to send multiple messages to the WkupM3
after the mailbox usage logic adjustment in the wkup_m3_ipc driver.

Signed-off-by: Keerthy j-keer...@ti.com
Acked-by: Dave Gerlach d-gerl...@ti.com
[s-a...@ti.com: revise commit description]
Signed-off-by: Suman Anna s-a...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 6f6f393..5bccc48 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -214,6 +214,7 @@
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
mbox_wkupm3: wkup_m3 {
+   ti,mbox-send-noirq;
ti,mbox-tx = 0 0 0;
ti,mbox-rx = 0 0 3;
};
-- 
2.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 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-gerl...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
 .../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 000..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@44c0 {
+   ...
+
+   scm: scm@21 {
+   compatible = ti,am3-scm, simple-bus;
+   reg = 0x21 0x2000;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges = 0 0x21 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.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] ARM: dts: AM33xx: Add ti,mbox-send-noirq to wkup_m3 mailbox

[Dave Gerlach]

Add ti,mbox-send-noirq to wkup_m3 mailbox so that messages using
wkup_m3 mailbox are sent without triggering any further interrupts.
This is needed to achieve lower power numbers during CPU idle on
AM33xx.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
[s-a...@ti.com: revise commit description]
Signed-off-by: Suman Anna s-a...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4c1b4a8..4f2c07a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -391,6 +391,7 @@
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
mbox_wkupm3: wkup_m3 {
+   ti,mbox-send-noirq;
ti,mbox-tx = 0 0 0;
ti,mbox-rx = 0 0 3;
};
-- 
2.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dave Gerlach]

Hi,

This series is version 2 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. v1 of this series can be found at [1]. Changes include:

- Buildable as a module
- Added am437x support
- Various cleanups and fixes based on comments on v1
- Ability to use mailbox in noirq mode for cpuidle on am335x

v2 contains an additional patch for the omap mailbox driver now to allow
us to set ti,mbox-send-noirq for the wkup_m3 mailbox to allow us to
support cpuidle on am335x. Although we can rely on interrupts during
the suspend path, we must send a message during the cpuidle path from
noirq context so we must have the ability to do this without using
an interrupt, so we introduce the flag to indicate this. The patch has
been included here with the wkup_m3_ipc patch so that the usage and
context is clear.

This series uses the wkup_m3_rproc driver which is merged as of v4.2-rc1,
but the required dt nodes are not yet merged and can be found here [2].
A full branch containing all necessary PM code for both am335x and am437x
has been pushed here [3] a big picture view of the plan for this series.

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

Regards,
Dave

[1] http://www.spinics.net/lists/arm-kernel/msg387990.html
[2] http://www.spinics.net/lists/linux-omap/msg119973.html
[3] https://github.com/dgerlach/linux-pm/tree/pm-v4.2-rc2-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   | 486 +
 include/linux/wkup_m3_ipc.h|  30 ++
 7 files changed, 637 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.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] ARM: dts: AM33xx: Add the wkup_m3_ipc node

[Dave Gerlach]

From: Suman Anna s-a...@ti.com

Add the Wakeup M3 IPC node for the wkup_m3_ipc driver on AM33xx SoCs.
This node uses the IPC registers, part of the Control Module, and is
therefore added as a child of the scm node.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4f2c07a..13f097f 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -153,6 +153,14 @@
};
};
 
+   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;
+   };
+
scm_clockdomains: clockdomains {
};
};
-- 
2.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: remoteproc: wkup_m3: suspend/resume for am335x bbone

[Dave Gerlach]

Andreas,
On 07/15/2015 11:19 AM, Andreas Fenkart wrote:
 Hi,
 
 just realized that I need these patches patches as well:
 https://github.com/dgerlach/linux-pm/commits/pm-v4.1-rc4-amx3-suspend
 
 I tried to merge that branch into current v4.2-rc2, but I made quite a mess 
 out
 of it. I'll try probably try cherry-picking next or will just wait for an 
 update

Yes, there are some additional patches, wkup_m3_rproc is just part of the whole
collection. However I did rebase my pm branch on v4.2-rc2 today in preparation
of sending the next series so you can check that out here:
https://github.com/dgerlach/linux-pm/tree/pm-v4.2-rc2-amx3-suspend.

The firmware you need can be found here:
https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next-upstream.

Regards,
Dave

 
 so ignore my previous mail, :-)
 
 
 2015-07-15 11:23 GMT+02:00 Andreas Fenkart afenk...@gmail.com:
 cat /sys/power/state is empty, should be 'mem'

 I applied these patches:
 https://lkml.org/lkml/2015/4/1/542

 here suspend support in kernel-config (shall I append the full .config?)
 #
 # Power management options
 #
 CONFIG_SUSPEND=y
 CONFIG_SUSPEND_FREEZER=y
 # CONFIG_HIBERNATION is not set
 CONFIG_PM_SLEEP=y
 # CONFIG_PM_AUTOSLEEP is not set
 # CONFIG_PM_WAKELOCKS is not set
 CONFIG_PM=y
 CONFIG_PM_DEBUG=y
 # CONFIG_PM_ADVANCED_DEBUG is not set
 # CONFIG_PM_TEST_SUSPEND is not set
 CONFIG_PM_SLEEP_DEBUG=y
 # CONFIG_APM_EMULATION is not set
 CONFIG_PM_OPP=y
 CONFIG_PM_CLK=y
 # CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
 CONFIG_CPU_PM=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_ARM_CPU_SUSPEND=y
 CONFIG_ARCH_HIBERNATION_POSSIBLE=y
 CONFIG_NET=y


 [1.642524]  remoteproc0: wkup_m3 is available
 [1.647570]  remoteproc0: Note: remoteproc is still under
 development and considered experimental.
 [1.657068]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED,
 and backward compatibility isn't yet guaranteed.
 [1.668418]  remoteproc0: unsupported resource 4
 [1.673275]  remoteproc0: unsupported resource 4
 [1.685122] usbcore: registered new interface driver snd-usb-audio
 [1.691835]  remoteproc0: unsupported resource 4
 [1.696777]  remoteproc0: unsupported resource 4

 tip of m3 firmware
 git://arago-project.org/git/projects/am33x-cm3.git
 Sun Mar 9 23:52:27 2014 -0700 32cf44e CM3: AM43XX: Add Tamper swakeup 
 settings

 Do I need to update my m3 firmware?

 kind regards,
 Andreas Fenkart

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/3] ARM: OMAP2+: wkup_m3_rproc support patches

[Dave Gerlach]

On 07/13/2015 02:27 AM, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [150713 00:28]:
 * Dave Gerlach d-gerl...@ti.com [150709 12:53]:
 Tony,
 On 04/01/2015 02:47 PM, Dave Gerlach wrote:
 This series adds the mach-omap2 code and DT nodes for v3 of the
 wkup_m3_rproc driver submitted here [1]. pdata-quirks patch requires
 the pdata added with patch 4 of the aforementioned series. Based on
 previous discussion here [2], the wkup_m3 DT node has been moved as a
 child of the l4_wkup as is done for l4_wkup components in Tero Kristo's
 series PRCM+SCM cleanup against 4.0-rc1 found here [3]. Because of that,
 this series applies cleanly on top of that series in order to leverage the
 l4_wkup parent node introduced there.

 In addition to the move of the wkup_m3 node for am33xx, a new patch
 has been added to introduce the wkup_m3 node in the same fashion for
 am43xx as both SoCs use the same configuration. With this change
 support was also added to pdata-quirks for passing reset handlers to
 the driver for the am43xx binding as was already done for am33xx.

 I have pushed a branch containing all patches for am335x suspend
 here for a big picture view of how all patches fit together with
 these wkup_m3_rproc series [4].

 v2-v3:
 -Change ti,am3353-wkup-m3 compat to ti,am3352-wkup-m3 to reflect
  binding documentation change
 -Add ti,am4372-wkup-m3 node to am4372 SoC dt file
 -Add am4372 support to pdata-quirks for reset handlers

 Now that Ohad has sent a pull request for the wkup_m3_rproc driver [1] and 
 it
 has been merged is it possible for this series with the DT nodes and 
 pdata-quirk
 to get picked up? Let me know and I can rebase and resend if you'd like.

 Yes this series looks good to me now, will queue for v4.3.
 
 Looks like you need to repost this series again against v4.2-rc2 
 to apply though.

Ok will do, thanks!

Regards,
Dave

  
 Regards,
 
 Tony
  
 [1] https://lkml.org/lkml/2015/7/1/354

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 0/3] ARM: OMAP2+: wkup_m3_rproc support patches

[Dave Gerlach]

Hi,

Now that wkup_m3_rproc driver [1] has been merged the support code
contained in this series can be merged. This is v4 which is just a
rebase of v3 [2] code on v4.2-rc2, no other changes.

Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg118768.html
[2] http://www.spinics.net/lists/linux-omap/msg117614.html

Dave Gerlach (1):
  ARM: OMAP2+: Use pdata-quirks for wkup_m3 reset management

Suman Anna (2):
  ARM: dts: AM33xx: Update and move wkup_m3 node to l4 node
  ARM: dts: AM4372: Add the wkupm3 rproc node

 arch/arm/boot/dts/am33xx.dtsi  | 17 +
 arch/arm/boot/dts/am4372.dtsi  |  9 +
 arch/arm/mach-omap2/pdata-quirks.c | 15 +++
 3 files changed, 33 insertions(+), 8 deletions(-)

-- 
2.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/3] ARM: dts: AM4372: Add the wkupm3 rproc node

[Dave Gerlach]

From: Suman Anna s-a...@ti.com

Add the Wakeup M3 remote processor device node for
the AM4372 SoC. The WkupM3 remote processor is used
to implement and achieve low-power functionality on
the AM33xx  AM43xx SoCs.

This node is added as a child of the recently added
l4_wkup node to reflect its presence within the SoC.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ade28c79..6f6f393 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -83,6 +83,15 @@
#size-cells = 1;
ranges = 0 0x44c0 0x287000;
 
+   wkup_m3: wkup_m3@10 {
+   compatible = ti,am4372-wkup-m3;
+   reg = 0x10 0x4000,
+ 0x18 0x2000;
+   reg-names = umem, dmem;
+   ti,hwmods = wkup_m3;
+   ti,pm-firmware = am335x-pm-firmware.elf;
+   };
+
prcm: prcm@1f {
compatible = ti,am4-prcm;
reg = 0x1f 0x11000;
-- 
2.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/3] ARM: dts: AM33xx: Update and move wkup_m3 node to l4 node

[Dave Gerlach]

From: Suman Anna s-a...@ti.com

The WakeupM3 remote processor device node has been moved to
be a child node of the newly created l4_wkup node, to reflect
its presence properly within the SoC. The node was added
previously before any driver support, it is now updated as
per the wkup_m3_rproc bindings added alongside the driver
support.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 21fcc44..4c1b4a8 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -103,6 +103,15 @@
#size-cells = 1;
ranges = 0 0x44c0 0x28;
 
+   wkup_m3: wkup_m3@10 {
+   compatible = ti,am3352-wkup-m3;
+   reg = 0x10 0x4000,
+ 0x18 0x2000;
+   reg-names = umem, dmem;
+   ti,hwmods = wkup_m3;
+   ti,pm-firmware = am335x-pm-firmware.elf;
+   };
+
prcm: prcm@20 {
compatible = ti,am3-prcm;
reg = 0x20 0x4000;
@@ -762,14 +771,6 @@
reg = 0x4030 0x1; /* 64k */
};
 
-   wkup_m3: wkup_m3@44d0 {
-   compatible = ti,am3353-wkup-m3;
-   reg = 0x44d0 0x4000/* M3 UMEM */
-  0x44d8 0x2000;  /* M3 DMEM */
-   ti,hwmods = wkup_m3;
-   ti,no-reset-on-init;
-   };
-
elm: elm@4808 {
compatible = ti,am3352-elm;
reg = 0x4808 0x2000;
-- 
2.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/3] ARM: OMAP2+: Use pdata-quirks for wkup_m3 reset management

[Dave Gerlach]

Use pdata-quirks to provide platform data required for reset
management during boot and shutdown of the wkup_m3 processor
on both the AM33xx and AM43xx SoCs. The WkupM3 remote processor
is used to implement and achieve low-power functionality on
the AM33xx  AM43xx SoCs.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/mach-omap2/pdata-quirks.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 821171c..5417f2c 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -17,6 +17,7 @@
 
 #include linux/platform_data/pinctrl-single.h
 #include linux/platform_data/iommu-omap.h
+#include linux/platform_data/wkup_m3.h
 
 #include common.h
 #include common-board-devices.h
@@ -278,6 +279,14 @@ static struct iommu_platform_data omap4_iommu_pdata = {
 };
 #endif
 
+#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
+static struct wkup_m3_platform_data wkup_m3_data = {
+   .reset_name = wkup_m3,
+   .assert_reset = omap_device_assert_hardreset,
+   .deassert_reset = omap_device_deassert_hardreset,
+};
+#endif
+
 #ifdef CONFIG_SOC_OMAP5
 static void __init omap5_uevm_legacy_init(void)
 {
@@ -340,6 +349,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
   am35xx_emac_pdata),
 #endif
+#ifdef CONFIG_SOC_AM33XX
+   OF_DEV_AUXDATA(ti,am3352-wkup-m3, 0x44d0, 44d0.wkup_m3,
+  wkup_m3_data),
+#endif
 #ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux, 
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux, 
pcs_pdata),
@@ -353,6 +366,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
 #endif
 #ifdef CONFIG_SOC_AM43XX
OF_DEV_AUXDATA(ti,am437-padconf, 0x44e10800, 44e10800.pinmux, 
pcs_pdata),
+   OF_DEV_AUXDATA(ti,am4372-wkup-m3, 0x44d0, 44d0.wkup_m3,
+  wkup_m3_data),
 #endif
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA(ti,omap4-iommu, 0x4a066000, 4a066000.mmu,
-- 
2.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP2+: Add HAVE_ARM_SCU for AM43XX

[Dave Gerlach]

CONFIG_HAVE_ARM_SCU only gets selected if CONFIG_SMP is selected in an OMAP
system, however AM43XX needs this option regardless of CONFIG_SMP and also
for an AM43XX only build as it is important for controlling power in the SoC.
Without this we cannot suspend the CPU for SoC suspend or cpuidle. The
ARM Cortex A9 needs SCU CPU Power Status bits to be set to off mode in order
for the PRCM to transition the MPU to low power modes.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/mach-omap2/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ecc04ff..4a023e8 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -60,6 +60,7 @@ config SOC_AM43XX
select ARM_GIC
select MACH_OMAP_GENERIC
select MIGHT_HAVE_CACHE_L2X0
+   select HAVE_ARM_SCU
 
 config SOC_DRA7XX
bool TI DRA7XX
-- 
2.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/3] ARM: OMAP2+: wkup_m3_rproc support patches

[Dave Gerlach]

Tony,
On 04/01/2015 02:47 PM, Dave Gerlach wrote:
 This series adds the mach-omap2 code and DT nodes for v3 of the
 wkup_m3_rproc driver submitted here [1]. pdata-quirks patch requires
 the pdata added with patch 4 of the aforementioned series. Based on
 previous discussion here [2], the wkup_m3 DT node has been moved as a
 child of the l4_wkup as is done for l4_wkup components in Tero Kristo's
 series PRCM+SCM cleanup against 4.0-rc1 found here [3]. Because of that,
 this series applies cleanly on top of that series in order to leverage the
 l4_wkup parent node introduced there.
 
 In addition to the move of the wkup_m3 node for am33xx, a new patch
 has been added to introduce the wkup_m3 node in the same fashion for
 am43xx as both SoCs use the same configuration. With this change
 support was also added to pdata-quirks for passing reset handlers to
 the driver for the am43xx binding as was already done for am33xx.
 
 I have pushed a branch containing all patches for am335x suspend
 here for a big picture view of how all patches fit together with
 these wkup_m3_rproc series [4].
 
 v2-v3:
 -Change ti,am3353-wkup-m3 compat to ti,am3352-wkup-m3 to reflect
  binding documentation change
 -Add ti,am4372-wkup-m3 node to am4372 SoC dt file
 -Add am4372 support to pdata-quirks for reset handlers

Now that Ohad has sent a pull request for the wkup_m3_rproc driver [1] and it
has been merged is it possible for this series with the DT nodes and pdata-quirk
to get picked up? Let me know and I can rebase and resend if you'd like.

Regards,
Dave

[1] https://lkml.org/lkml/2015/7/1/354

 
 Regards,
 Dave
 
 [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg115869.html
 [2] http://www.spinics.net/lists/linux-omap/msg116366.html
 [3] http://www.spinics.net/lists/arm-kernel/msg409842.html
 [4] https://github.com/dgerlach/linux-pm/tree/pm-v4.0-rc5-am335x-suspend
 
 Dave Gerlach (1):
   ARM: OMAP2+: Use pdata-quirks for wkup_m3 reset management
 
 Suman Anna (2):
   ARM: dts: AM33xx: Update and move wkup_m3 node to l4 node
   ARM: dts: AM4372: Add the wkupm3 rproc node
 
  arch/arm/boot/dts/am33xx.dtsi  | 17 +
  arch/arm/boot/dts/am4372.dtsi  |  9 +
  arch/arm/mach-omap2/pdata-quirks.c | 15 +++
  3 files changed, 33 insertions(+), 8 deletions(-)
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] remoteproc: introduce rproc_get_by_phandle API

[Dave Gerlach]

Ohad,
On 06/18/2015 04:04 AM, Ohad Ben-Cohen wrote:
 Hi Dave,
 
 On Wed, Jun 17, 2015 at 9:46 PM, Dave Gerlach d-gerl...@ti.com wrote:
 Allow users of remoteproc the ability to get a handle to an rproc by
 passing a phandle supplied in the user's device tree node. This is
 useful in situations that require manual booting of the rproc.

 This patch uses the code removed by commit 40e575b1d0b3 (remoteproc:
 remove the get_by_name/put API) for the ref counting but is modified
 to use a simple list and locking mechanism and has rproc_get_by_name
 replaced with an rproc_get_by_phandle API.

 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 Signed-off-by: Suman Anna s-a...@ti.com
 ---
 v4-v5: Fixed build error from of_find_node_by_phandle when !CONFIG_OF
 based on offline discussion.
 
 We can't rebase our for-next branch, so I've applied a
 similar fix in a separate patch.
 
 Please check our for-next branch to make sure things still work for you.
 

Oh sorry about. Pulled your for-next, tried it out, everything looks good to me,
thanks!

Regards,
Dave

 Thanks,
 Ohad.
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/4] remoteproc: introduce rproc_get_by_phandle API

[Dave Gerlach]

Allow users of remoteproc the ability to get a handle to an rproc by
passing a phandle supplied in the user's device tree node. This is
useful in situations that require manual booting of the rproc.

This patch uses the code removed by commit 40e575b1d0b3 (remoteproc:
remove the get_by_name/put API) for the ref counting but is modified
to use a simple list and locking mechanism and has rproc_get_by_name
replaced with an rproc_get_by_phandle API.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
v4-v5: Fixed build error from of_find_node_by_phandle when !CONFIG_OF
based on offline discussion.

 Documentation/remoteproc.txt |  6 +
 drivers/remoteproc/remoteproc_core.c | 52 
 include/linux/remoteproc.h   | 14 +++---
 3 files changed, 69 insertions(+), 3 deletions(-)

diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index e6469fd..ef0219f 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -51,6 +51,12 @@ cost.
 rproc_shutdown() returns, and users can still use it with a subsequent
 rproc_boot(), if needed.
 
+  struct rproc *rproc_get_by_phandle(phandle phandle)
+- Find an rproc handle using a device tree phandle. Returns the rproc
+  handle on success, and NULL on failure. This function increments
+  the remote processor's refcount, so always use rproc_put() to
+  decrement it back once rproc isn't needed anymore.
+
 3. Typical usage
 
 #include linux/remoteproc.h
diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index e991512..a898c48 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -44,6 +44,9 @@
 
 #include remoteproc_internal.h
 
+static DEFINE_MUTEX(rproc_list_mutex);
+static LIST_HEAD(rproc_list);
+
 typedef int (*rproc_handle_resources_t)(struct rproc *rproc,
struct resource_table *table, int len);
 typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
@@ -1144,6 +1147,45 @@ out:
 }
 EXPORT_SYMBOL(rproc_shutdown);
 
+#ifdef CONFIG_OF
+/**
+ * rproc_get_by_phandle() - find a remote processor by phandle
+ * @phandle: phandle to the rproc
+ *
+ * Finds an rproc handle using the remote processor's phandle, and then
+ * return a handle to the rproc.
+ *
+ * This function increments the remote processor's refcount, so always
+ * use rproc_put() to decrement it back once rproc isn't needed anymore.
+ *
+ * Returns the rproc handle on success, and NULL on failure.
+ */
+struct rproc *rproc_get_by_phandle(phandle phandle)
+{
+   struct rproc *rproc = NULL, *r;
+   struct device_node *np;
+
+   np = of_find_node_by_phandle(phandle);
+   if (!np)
+   return NULL;
+
+   mutex_lock(rproc_list_mutex);
+   list_for_each_entry(r, rproc_list, node) {
+   if (r-dev.parent  r-dev.parent-of_node == np) {
+   rproc = r;
+   get_device(rproc-dev);
+   break;
+   }
+   }
+   mutex_unlock(rproc_list_mutex);
+
+   of_node_put(np);
+
+   return rproc;
+}
+EXPORT_SYMBOL(rproc_get_by_phandle);
+#endif /* CONFIG_OF */
+
 /**
  * rproc_add() - register a remote processor
  * @rproc: the remote processor handle to register
@@ -1173,6 +1215,11 @@ int rproc_add(struct rproc *rproc)
if (ret  0)
return ret;
 
+   /* expose to rproc_get_by_phandle users */
+   mutex_lock(rproc_list_mutex);
+   list_add(rproc-node, rproc_list);
+   mutex_unlock(rproc_list_mutex);
+
dev_info(dev, %s is available\n, rproc-name);
 
dev_info(dev, Note: remoteproc is still under development and 
considered experimental.\n);
@@ -1360,6 +1407,11 @@ int rproc_del(struct rproc *rproc)
/* Free the copy of the resource table */
kfree(rproc-cached_table);
 
+   /* the rproc is downref'ed as soon as it's removed from the klist */
+   mutex_lock(rproc_list_mutex);
+   list_del(rproc-node);
+   mutex_unlock(rproc_list_mutex);
+
device_del(rproc-dev);
 
return 0;
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 78b8a9b..cccfe0b 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -36,11 +36,11 @@
 #define REMOTEPROC_H
 
 #include linux/types.h
-#include linux/klist.h
 #include linux/mutex.h
 #include linux/virtio.h
 #include linux/completion.h
 #include linux/idr.h
+#include linux/of.h
 
 /**
  * struct resource_table - firmware resource table header
@@ -375,7 +375,7 @@ enum rproc_crash_type {
 
 /**
  * struct rproc - represents a physical remote processor device
- * @node: klist node of this rproc object
+ * @node: list node of this rproc object
  * @domain: iommu domain
  * @name: human readable name of the rproc
  * @firmware: name of firmware file to be loaded
@@ -407,7

Re: Regression with AM43xx devices

[Dave Gerlach]

Hi Paul,
On 06/02/2015 02:28 PM, Paul Walmsley wrote:
 On Tue, 2 Jun 2015, Felipe Balbi wrote:
 
 You commit fabbe6df130a46d5b5e7484b2273d69c4be3012a (ARM: OMAP: AM43xx
 hwmod: Add data for am43xx emif hwmod) listed below added a new WARNING
 during boot to all AM43xx-based boards. Full boot logs can be found at
 [1],
 
 Speaking of which, could you guys please send along an AM43xx board for 
 the testbed?  That would help avoid these issues earlier.
 

We can work on this.

Regards,
Dave

 
 - Paul
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression with AM43xx devices

[Dave Gerlach]

On 06/02/2015 02:17 PM, Felipe Balbi wrote:
 Hi Dave,
 
 You commit fabbe6df130a46d5b5e7484b2273d69c4be3012a (ARM: OMAP: AM43xx
 hwmod: Add data for am43xx emif hwmod) listed below added a new WARNING
 during boot to all AM43xx-based boards. Full boot logs can be found at
 [1], but it seems like we should, at least for the merge window, revert
 said commit unless a fix could come it the next couple days or so.o
 
 ps: note that boot log is for AM43xx IDK, but the same thing has been
 reproduced on AM437x SK.
 
 [1] http://hastebin.com/kasenikevo
 

This is because the base address will come from the DT node, patch is here:
http://www.spinics.net/lists/arm-kernel/msg416286.html

Regards,
Dave

 
 
 commit fabbe6df130a46d5b5e7484b2273d69c4be3012a
 Author: Dave Gerlach d-gerl...@ti.com
 Date:   Mon Jun 1 19:22:11 2015 -0600
 
 ARM: OMAP: AM43xx hwmod: Add data for am43xx emif hwmod
 
 Without a hwmod for am43xx emif use counting for emif clockdomain does
 not happen correctly so it may be shut off by pm code unintentionally.
 
 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 [p...@pwsan.com: updated to apply]
 Signed-off-by: Paul Walmsley p...@pwsan.com
 
 diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h 
 b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
 index 130332c0534d..7f737965f543 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
 +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
 @@ -145,6 +145,7 @@ extern struct omap_hwmod am33xx_uart5_hwmod;
  extern struct omap_hwmod am33xx_uart6_hwmod;
  extern struct omap_hwmod am33xx_wd_timer1_hwmod;
  
 +extern struct omap_hwmod_class am33xx_emif_hwmod_class;
  extern struct omap_hwmod_class am33xx_l4_hwmod_class;
  extern struct omap_hwmod_class am33xx_wkup_m3_hwmod_class;
  extern struct omap_hwmod_class am33xx_control_hwmod_class;
 diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
 index ae0cb673a3d1..907a452b78ea 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
 @@ -203,6 +203,19 @@ struct omap_hwmod am33xx_prcm_hwmod = {
  };
  
  /*
 + * 'emif' class
 + * instance(s): emif
 + */
 +static struct omap_hwmod_class_sysconfig am33xx_emif_sysc = {
 + .rev_offs   = 0x,
 +};
 +
 +struct omap_hwmod_class am33xx_emif_hwmod_class = {
 + .name   = emif,
 + .sysc   = am33xx_emif_sysc,
 +};
 +
 +/*
   * 'aes0' class
   */
  static struct omap_hwmod_class_sysconfig am33xx_aes0_sysc = {
 diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
 index 0cf7b563dcd1..cc0791d9125b 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
 @@ -34,19 +34,6 @@
   * IP blocks
   */
  
 -/*
 - * 'emif' class
 - * instance(s): emif
 - */
 -static struct omap_hwmod_class_sysconfig am33xx_emif_sysc = {
 - .rev_offs   = 0x,
 -};
 -
 -static struct omap_hwmod_class am33xx_emif_hwmod_class = {
 - .name   = emif,
 - .sysc   = am33xx_emif_sysc,
 -};
 -
  /* emif */
  static struct omap_hwmod am33xx_emif_hwmod = {
   .name   = emif,
 diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 index 17e8004fc20f..215d5efa0dba 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 @@ -24,6 +24,20 @@
  
  
  /* IP blocks */
 +static struct omap_hwmod am43xx_emif_hwmod = {
 + .name   = emif,
 + .class  = am33xx_emif_hwmod_class,
 + .clkdm_name = emif_clkdm,
 + .flags  = HWMOD_INIT_NO_IDLE,
 + .main_clk   = dpll_ddr_m2_ck,
 + .prcm   = {
 + .omap4  = {
 + .clkctrl_offs   = AM43XX_CM_PER_EMIF_CLKCTRL_OFFSET,
 + .modulemode = MODULEMODE_SWCTRL,
 + },
 + },
 +};
 +
  static struct omap_hwmod am43xx_l4_hs_hwmod = {
   .name   = l4_hs,
   .class  = am33xx_l4_hwmod_class,
 @@ -583,6 +597,13 @@ static struct omap_hwmod am43xx_vpfe1_hwmod = {
  };
  
  /* Interfaces */
 +static struct omap_hwmod_ocp_if am43xx_l3_main__emif = {
 + .master = am33xx_l3_main_hwmod,
 + .slave  = am43xx_emif_hwmod,
 + .clk= dpll_core_m4_ck,
 + .user   = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
  static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
   .master = am33xx_l3_main_hwmod,
   .slave  = am43xx_l4_hs_hwmod,
 @@ -918,6 +939,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] 
 __initdata = {
   am33xx_l3_main__l3_instr,
   am33xx_l3_main__gfx,
   am33xx_l3_s__l3_main

[PATCH v4 1/4] remoteproc: introduce rproc_get_by_phandle API

[Dave Gerlach]

Allow users of remoteproc the ability to get a handle to an rproc by
passing a phandle supplied in the user's device tree node. This is
useful in situations that require manual booting of the rproc.

This patch uses the code removed by commit 40e575b1d0b3 (remoteproc:
remove the get_by_name/put API) for the ref counting but is modified
to use a simple list and locking mechanism and has rproc_get_by_name
replaced with an rproc_get_by_phandle API.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
v3-v4: Switch from using klist to using simple list and mutex for
rproc list.

 Documentation/remoteproc.txt |  6 +
 drivers/remoteproc/remoteproc_core.c | 50 
 include/linux/remoteproc.h   |  7 ++---
 3 files changed, 60 insertions(+), 3 deletions(-)

diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index e6469fd..ef0219f 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -51,6 +51,12 @@ cost.
 rproc_shutdown() returns, and users can still use it with a subsequent
 rproc_boot(), if needed.
 
+  struct rproc *rproc_get_by_phandle(phandle phandle)
+- Find an rproc handle using a device tree phandle. Returns the rproc
+  handle on success, and NULL on failure. This function increments
+  the remote processor's refcount, so always use rproc_put() to
+  decrement it back once rproc isn't needed anymore.
+
 3. Typical usage
 
 #include linux/remoteproc.h
diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 11cdb11..982f2fc 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -44,6 +44,9 @@
 
 #include remoteproc_internal.h
 
+static DEFINE_MUTEX(rproc_list_mutex);
+static LIST_HEAD(rproc_list);
+
 typedef int (*rproc_handle_resources_t)(struct rproc *rproc,
struct resource_table *table, int len);
 typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
@@ -1152,6 +1155,43 @@ out:
 EXPORT_SYMBOL(rproc_shutdown);
 
 /**
+ * rproc_get_by_phandle() - find a remote processor by phandle
+ * @phandle: phandle to the rproc
+ *
+ * Finds an rproc handle using the remote processor's phandle, and then
+ * return a handle to the rproc.
+ *
+ * This function increments the remote processor's refcount, so always
+ * use rproc_put() to decrement it back once rproc isn't needed anymore.
+ *
+ * Returns the rproc handle on success, and NULL on failure.
+ */
+struct rproc *rproc_get_by_phandle(phandle phandle)
+{
+   struct rproc *rproc = NULL, *r;
+   struct device_node *np;
+
+   np = of_find_node_by_phandle(phandle);
+   if (!np)
+   return NULL;
+
+   mutex_lock(rproc_list_mutex);
+   list_for_each_entry(r, rproc_list, node) {
+   if (r-dev.parent  r-dev.parent-of_node == np) {
+   rproc = r;
+   get_device(rproc-dev);
+   break;
+   }
+   }
+   mutex_unlock(rproc_list_mutex);
+
+   of_node_put(np);
+
+   return rproc;
+}
+EXPORT_SYMBOL(rproc_get_by_phandle);
+
+/**
  * rproc_add() - register a remote processor
  * @rproc: the remote processor handle to register
  *
@@ -1180,6 +1220,11 @@ int rproc_add(struct rproc *rproc)
if (ret  0)
return ret;
 
+   /* expose to rproc_get_by_phandle users */
+   mutex_lock(rproc_list_mutex);
+   list_add(rproc-node, rproc_list);
+   mutex_unlock(rproc_list_mutex);
+
dev_info(dev, %s is available\n, rproc-name);
 
dev_info(dev, Note: remoteproc is still under development and 
considered experimental.\n);
@@ -1369,6 +1414,11 @@ int rproc_del(struct rproc *rproc)
/* Free the copy of the resource table */
kfree(rproc-cached_table);
 
+   /* the rproc is downref'ed as soon as it's removed from the klist */
+   mutex_lock(rproc_list_mutex);
+   list_del(rproc-node);
+   mutex_unlock(rproc_list_mutex);
+
device_del(rproc-dev);
 
return 0;
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 78b8a9b..56739e5 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -36,11 +36,11 @@
 #define REMOTEPROC_H
 
 #include linux/types.h
-#include linux/klist.h
 #include linux/mutex.h
 #include linux/virtio.h
 #include linux/completion.h
 #include linux/idr.h
+#include linux/of.h
 
 /**
  * struct resource_table - firmware resource table header
@@ -375,7 +375,7 @@ enum rproc_crash_type {
 
 /**
  * struct rproc - represents a physical remote processor device
- * @node: klist node of this rproc object
+ * @node: list node of this rproc object
  * @domain: iommu domain
  * @name: human readable name of the rproc
  * @firmware: name of firmware file to be loaded
@@ -407,7 +407,7 @@ enum rproc_crash_type {
  * @has_iommu: flag to indicate

[PATCH v4 0/4] remoteproc: Introduce wkup_m3_rproc driver

[Dave Gerlach]

Hi,
This patch series is v4 of the series to add a wkup_m3_rproc driver
for TI AM335xi and AM437x SoCs. This family of SoCs contains an ARM
Cortex M3 coprocessor that is responsible for low-level power tasks
that cannot be handled by the main ARM Cortex A8 so firmware running
from the CM3 can be used instead. This driver handles loading
of the firmware and reset of the CM3. Change info can be found
with each patch.

The previous version of this series can be found here [1].
I have pushed a branch based on v4.1-rc4 containing the entire
am335x suspend series along with WIP am437x suspend patches for
a higher level view of the entire series of patch sets here [2].

The driver expects to load firmware am335x-pm-firmware.elf from
/lib/firmware which is found here [3].

Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg117611.html
[2] https://github.com/dgerlach/linux-pm/tree/pm-v4.1-rc4-amx3-suspend
[3] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next-upstream


Dave Gerlach (3):
  remoteproc: introduce rproc_get_by_phandle API
  Documentation: dt: add bindings for TI Wakeup M3 processor
  remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3

Suman Anna (1):
  remoteproc: add a rproc ops for performing address translation

 .../bindings/remoteproc/wkup_m3_rproc.txt  |  52 +
 Documentation/remoteproc.txt   |   6 +
 drivers/remoteproc/Kconfig |  13 ++
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/remoteproc_core.c   |  81 ++-
 drivers/remoteproc/wkup_m3_rproc.c | 257 +
 include/linux/platform_data/wkup_m3.h  |  30 +++
 include/linux/remoteproc.h |   9 +-
 8 files changed, 440 insertions(+), 9 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
 create mode 100644 include/linux/platform_data/wkup_m3.h

-- 
2.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/4] remoteproc: add a rproc ops for performing address translation

[Dave Gerlach]

From: Suman Anna s-a...@ti.com

The rproc_da_to_va API is currently used to perform any device to
kernel address translations to meet the different needs of the remoteproc
core/drivers (eg: loading). The functionality is achieved within the
remoteproc core, and is limited only for carveouts allocated within the
core.

A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
processing if the platform implementation cannot provide the translation.
This will allow any remoteproc implementations to translate addresses for
dedicated memories like internal memories.

While at this, also update the rproc_da_to_va() documentation since it
is an exported function.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
v3-v4: No changes.

 drivers/remoteproc/remoteproc_core.c | 31 +--
 include/linux/remoteproc.h   |  2 ++
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 982f2fc..4c6e43f 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -139,28 +139,46 @@ static void rproc_disable_iommu(struct rproc *rproc)
return;
 }
 
-/*
+/**
+ * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc 
address
+ * @rproc: handle of a remote processor
+ * @da: remoteproc device address to translate
+ * @len: length of the memory region @da is pointing to
+ *
  * Some remote processors will ask us to allocate them physically contiguous
  * memory regions (which we call carveouts), and map them to specific
- * device addresses (which are hardcoded in the firmware).
+ * device addresses (which are hardcoded in the firmware). They may also have
+ * dedicated memory regions internal to the processors, and use them either
+ * exclusively or alongside carveouts.
  *
  * They may then ask us to copy objects into specific device addresses (e.g.
  * code/data sections) or expose us certain symbols in other device address
  * (e.g. their trace buffer).
  *
- * This function is an internal helper with which we can go over the allocated
- * carveouts and translate specific device address to kernel virtual addresses
- * so we can access the referenced memory.
+ * This function is a helper function with which we can go over the allocated
+ * carveouts and translate specific device addresses to kernel virtual 
addresses
+ * so we can access the referenced memory. This function also allows to perform
+ * translations on the internal remoteproc memory regions through a platform
+ * implementation specific da_to_va ops, if present.
+ *
+ * The function returns a valid kernel address on success or NULL on failure.
  *
  * Note: phys_to_virt(iommu_iova_to_phys(rproc-domain, da)) will work too,
  * but only on kernel direct mapped RAM memory. Instead, we're just using
- * here the output of the DMA API, which should be more correct.
+ * here the output of the DMA API for the carveouts, which should be more
+ * correct.
  */
 void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
 {
struct rproc_mem_entry *carveout;
void *ptr = NULL;
 
+   if (rproc-ops-da_to_va) {
+   ptr = rproc-ops-da_to_va(rproc, da, len);
+   if (ptr)
+   goto out;
+   }
+
list_for_each_entry(carveout, rproc-carveouts, node) {
int offset = da - carveout-da;
 
@@ -177,6 +195,7 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
break;
}
 
+out:
return ptr;
 }
 EXPORT_SYMBOL(rproc_da_to_va);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 56739e5..9c4e138 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -330,11 +330,13 @@ struct rproc;
  * @start: power on the device and boot it
  * @stop:  power off the device
  * @kick:  kick a virtqueue (virtqueue id given as a parameter)
+ * @da_to_va:  optional platform hook to perform address translations
  */
 struct rproc_ops {
int (*start)(struct rproc *rproc);
int (*stop)(struct rproc *rproc);
void (*kick)(struct rproc *rproc, int vqid);
+   void * (*da_to_va)(struct rproc *rproc, u64 da, int len);
 };
 
 /**
-- 
2.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3

[Dave Gerlach]

Add a remoteproc driver to load the firmware and boot a small
Wakeup M3 processor present on TI AM33xx and AM43xx SoCs. This
Wakeup M3 remote processor is an integrated Cortex M3 that allows
the SoC to enter the lowest possible power state by taking control
from the MPU after it has gone into its own low power state and
shutting off any additional peripherals.

The Wakeup M3 processor has two internal memory regions - 16 kB of
unified instruction memory called UMEM used to store executable
code, and 8 kB of data memory called DMEM used for all data sections.
The Wakeup M3 processor executes its code entirely from within the
UMEM and uses the DMEM for any data. It does not use any external
memory or any other external resources. The device address view has
the UMEM at address 0x0 and DMEM at address 0x8, and these are
computed automatically within the driver based on relative address
calculation from the corresponding device tree IOMEM resources.
These device addresses are used to aid the core remoteproc ELF
loader code to properly translate and load the firmware segments
through the .rproc_da_to_va ops.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
v3-v4: Added explanation of memory management and regions in the
changelog, added a few additional comments to explain use
of __force and memory region probe order.

 drivers/remoteproc/Kconfig|  13 ++
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/wkup_m3_rproc.c| 257 ++
 include/linux/platform_data/wkup_m3.h |  30 
 4 files changed, 301 insertions(+)
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
 create mode 100644 include/linux/platform_data/wkup_m3.h

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 5e343ba..28c711f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -41,6 +41,19 @@ config STE_MODEM_RPROC
  This can be either built-in or a loadable module.
  If unsure say N.
 
+config WKUP_M3_RPROC
+   tristate AMx3xx Wakeup M3 remoteproc support
+   depends on SOC_AM33XX || SOC_AM43XX
+   select REMOTEPROC
+   help
+ Say y here to support Wakeup M3 remote processor on TI AM33xx
+ and AM43xx family of SoCs.
+
+ Required for Suspend-to-RAM on AM33xx and AM43xx SoCs. Also needed
+ for deep CPUIdle states on AM33xx SoCs. Allows for loading of the
+ firmware onto these remote processors.
+ If unsure say N.
+
 config DA8XX_REMOTEPROC
tristate DA8xx/OMAP-L13x remoteproc support
depends on ARCH_DAVINCI_DA8XX
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ac2ff75..81b04d1 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -9,4 +9,5 @@ remoteproc-y+= remoteproc_virtio.o
 remoteproc-y   += remoteproc_elf_loader.o
 obj-$(CONFIG_OMAP_REMOTEPROC)  += omap_remoteproc.o
 obj-$(CONFIG_STE_MODEM_RPROC)  += ste_modem_rproc.o
+obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/wkup_m3_rproc.c 
b/drivers/remoteproc/wkup_m3_rproc.c
new file mode 100644
index 000..edf8181
--- /dev/null
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -0,0 +1,257 @@
+/*
+ * TI AMx3 Wakeup M3 Remote Processor driver
+ *
+ * Copyright (C) 2014-2015 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@ti.com
+ * Suman Anna s-a...@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/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/remoteproc.h
+
+#include linux/platform_data/wkup_m3.h
+
+#include remoteproc_internal.h
+
+#define WKUPM3_MEM_MAX 2
+
+/**
+ * struct wkup_m3_mem - WkupM3 internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address from Wakeup M3 view
+ * @size: Size of the memory region
+ */
+struct wkup_m3_mem {
+   void __iomem *cpu_addr;
+   phys_addr_t bus_addr;
+   u32 dev_addr;
+   size_t size;
+};
+
+/**
+ * struct wkup_m3_rproc - WkupM3 remote processor state
+ * @rproc: rproc handle
+ * @pdev: pointer to platform device
+ * @mem: WkupM3 memory information

[PATCH v4 3/4] Documentation: dt: add bindings for TI Wakeup M3 processor

[Dave Gerlach]

Add the device tree bindings document for the TI Wakeup M3 remote
processor devices on AM33xx and AM43xx SoCs. These devices are used
to offload low-level power management functionality, and are handled
by the wkup_m3 remoteproc driver.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
v3-v4: No changes to patch, just added Tony's Ack.

 .../bindings/remoteproc/wkup_m3_rproc.txt  | 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt 
b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
new file mode 100644
index 000..3a70073
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
@@ -0,0 +1,52 @@
+TI Wakeup M3 Remoteproc 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. This CM3 processor requires a firmware
+binary to accomplish this. The wkup_m3 remoteproc driver handles the loading of
+the firmware and booting of the CM3.
+
+Wkup M3 Device Node:
+
+A wkup_m3 device node is used to represent the Wakeup M3 processor instance
+within the SoC. It is added as a child node of the parent interconnect bus
+(l4_wkup) through which it is accessible to the MPU.
+
+Required properties:
+
+- compatible:  Should be one of,
+   ti,am3352-wkup-m3 for AM33xx SoCs
+   ti,am4372-wkup-m3 for AM43xx SoCs
+- reg: Should contain the address ranges for the two internal
+   memory regions, UMEM and DMEM. The parent node should
+   provide an appropriate ranges property for properly
+   translating these into bus addresses.
+- reg-names:   Contains the corresponding names for the two memory
+   regions. These should be named umem  dmem.
+- ti,hwmods:   Name of the hwmod associated with the wkupm3 device.
+- ti,pm-firmware:  Name of firmware file to be used for loading and
+   booting the wkup_m3 remote processor.
+
+Example:
+
+/* AM33xx */
+ocp {
+l4_wkup: l4_wkup@44c0 {
+   compatible = am335-l4-wkup, simple-bus;
+   ranges = 0 0x44c0 0x40;
+   #address-cells = 1;
+   #size-cells = 1;
+
+   wkup_m3: wkup_m3@10 {
+   compatible = ti,am3352-wkup-m3;
+   reg = 0x10 0x4000,
+ 0x18 0x2000;
+   reg-names = umem, dmem;
+   ti,hwmods = wkup_m3;
+   ti,pm-firmware = am335x-pm-firmware.elf;
+   };
+   };
+
+   ...
+};
-- 
2.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/4] remoteproc: Introduce wkup_m3_rproc driver

[Dave Gerlach]

Hi,
This patch series is version three of the series to add a
wkup_m3_rproc driver for TI AM335x SoCs. This family of SoCs
contains an ARM Cortex M3 coprocessor that is responsible for
low-level power tasks that cannot be handled by the main ARM
Cortex A8 so firmware running from the CM3 can be used instead.
This driver handles loading of the firmware and reset of the CM3
once it is booted.

The previous version of this series can be found here [1].
I have pushed a branch based on v4.0-rc5 containing the entire
am335x suspend series here for a higher level view of the entire
series of patch sets here [2]. This series depends on remoteproc:
add IOMMU hardware capability flag which is currently queued
here [3].

Based on comments on the DT node included in the ARM: OMAP2+:
wkup_m3_rproc support patches series (v3 of that will immediately
follow this series) the DT node moved under a different parent
node so some changes to the driver were necessary to calculate proper
device addresses for firmware loading.

This series also now includes a patch to introduce an
rproc_get_by_phandle API to the remoteproc core so that users of
this wkup_m3_rproc driver are able to get a handle to the rproc
and boot it as the rproc must be booted directly by the user.
An example user, wkup_m3_ipc, can be seen in previously mentioned
branch at [2].

v2 - v3:
-Modify wkup_m3_rproc driver to properly handle device address
 based on new DT location in l4_wkup node.
-In binding doc, change ti,am3352-wkup-m3 from am3353-wkup_m3 to match
 other am3352 compats
-General cleanup of address representation in wkup_m3_rproc driver
-Includes rproc_get_by_phandle patch now

The driver expects to load firmware am335x-pm-firmware.elf from
/lib/firmware which is found here [4].

Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg116364.html
[2] https://github.com/dgerlach/linux-pm/tree/pm-v4.0-rc5-am335x-suspend
[3] 
https://git.kernel.org/cgit/linux/kernel/git/ohad/remoteproc.git/commit/?h=for-nextid=315491e5d6ee66838a18a8ca0c14e6ffb376e48c
[4] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next-upstream

Dave Gerlach (3):
  remoteproc: introduce rproc_get_by_phandle API
  Documentation: dt: add bindings for TI Wakeup M3 processor
  remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3

Suman Anna (1):
  remoteproc: add a rproc ops for performing address translation

 .../bindings/remoteproc/wkup_m3_rproc.txt  |  52 +
 Documentation/remoteproc.txt   |   6 +
 drivers/remoteproc/Kconfig |  13 ++
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/remoteproc_core.c   | 114 +-
 drivers/remoteproc/wkup_m3_rproc.c | 249 +
 include/linux/platform_data/wkup_m3.h  |  30 +++
 include/linux/remoteproc.h |   4 +
 8 files changed, 463 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
 create mode 100644 include/linux/platform_data/wkup_m3.h

-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3

[Dave Gerlach]

Add a remoteproc driver to load the firmware and boot a small
Wakeup M3 processor present on TI AM33xx and AM43xx SoCs. This
Wakeup M3 remote processor is an integrated Cortex M3 that allows
the SoC to enter the lowest possible power state by taking control
from the MPU after it has gone into its own low power state and
shutting off any additional peripherals.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 drivers/remoteproc/Kconfig|  13 ++
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/wkup_m3_rproc.c| 249 ++
 include/linux/platform_data/wkup_m3.h |  30 
 4 files changed, 293 insertions(+)
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
 create mode 100644 include/linux/platform_data/wkup_m3.h

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 5e343ba..28c711f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -41,6 +41,19 @@ config STE_MODEM_RPROC
  This can be either built-in or a loadable module.
  If unsure say N.
 
+config WKUP_M3_RPROC
+   tristate AMx3xx Wakeup M3 remoteproc support
+   depends on SOC_AM33XX || SOC_AM43XX
+   select REMOTEPROC
+   help
+ Say y here to support Wakeup M3 remote processor on TI AM33xx
+ and AM43xx family of SoCs.
+
+ Required for Suspend-to-RAM on AM33xx and AM43xx SoCs. Also needed
+ for deep CPUIdle states on AM33xx SoCs. Allows for loading of the
+ firmware onto these remote processors.
+ If unsure say N.
+
 config DA8XX_REMOTEPROC
tristate DA8xx/OMAP-L13x remoteproc support
depends on ARCH_DAVINCI_DA8XX
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ac2ff75..81b04d1 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -9,4 +9,5 @@ remoteproc-y+= remoteproc_virtio.o
 remoteproc-y   += remoteproc_elf_loader.o
 obj-$(CONFIG_OMAP_REMOTEPROC)  += omap_remoteproc.o
 obj-$(CONFIG_STE_MODEM_RPROC)  += ste_modem_rproc.o
+obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/wkup_m3_rproc.c 
b/drivers/remoteproc/wkup_m3_rproc.c
new file mode 100644
index 000..134ffa7
--- /dev/null
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -0,0 +1,249 @@
+/*
+ * TI AMx3 Wakeup M3 Remote Processor driver
+ *
+ * Copyright (C) 2014-2015 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@ti.com
+ * Suman Anna s-a...@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/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/remoteproc.h
+
+#include linux/platform_data/wkup_m3.h
+
+#include remoteproc_internal.h
+
+#define WKUPM3_MEM_MAX 2
+
+/**
+ * struct wkup_m3_mem - WkupM3 internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address from Wakeup M3 view
+ * @size: Size of the memory region
+ */
+struct wkup_m3_mem {
+   void __iomem *cpu_addr;
+   phys_addr_t bus_addr;
+   u32 dev_addr;
+   size_t size;
+};
+
+/**
+ * struct wkup_m3_rproc - WkupM3 remote processor state
+ * @rproc: rproc handle
+ * @pdev: pointer to platform device
+ * @mem: WkupM3 memory information
+ */
+struct wkup_m3_rproc {
+   struct rproc *rproc;
+   struct platform_device *pdev;
+   struct wkup_m3_mem mem[WKUPM3_MEM_MAX];
+};
+
+static int wkup_m3_rproc_start(struct rproc *rproc)
+{
+   struct wkup_m3_rproc *wkupm3 = rproc-priv;
+   struct platform_device *pdev = wkupm3-pdev;
+   struct device *dev = pdev-dev;
+   struct wkup_m3_platform_data *pdata = dev_get_platdata(dev);
+
+   if (pdata-deassert_reset(pdev, pdata-reset_name)) {
+   dev_err(dev, Unable to reset wkup_m3!\n);
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
+static int wkup_m3_rproc_stop(struct rproc *rproc)
+{
+   struct wkup_m3_rproc *wkupm3 = rproc-priv;
+   struct platform_device *pdev = wkupm3-pdev;
+   struct device *dev = pdev-dev;
+   struct wkup_m3_platform_data *pdata = dev_get_platdata(dev);
+
+   if (pdata-assert_reset(pdev, pdata-reset_name

[PATCH v3 2/4] remoteproc: add a rproc ops for performing address translation

[Dave Gerlach]

From: Suman Anna s-a...@ti.com

The rproc_da_to_va API is currently used to perform any device to
kernel address translations to meet the different needs of the remoteproc
core/drivers (eg: loading). The functionality is achieved within the
remoteproc core, and is limited only for carveouts allocated within the
core.

A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
processing if the platform implementation cannot provide the translation.
This will allow any remoteproc implementations to translate addresses for
dedicated memories like internal memories.

While at this, also update the rproc_da_to_va() documentation since it
is an exported function.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 drivers/remoteproc/remoteproc_core.c | 31 +--
 include/linux/remoteproc.h   |  2 ++
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 5a6c192..f1efe62 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -159,28 +159,46 @@ static void rproc_disable_iommu(struct rproc *rproc)
return;
 }
 
-/*
+/**
+ * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc 
address
+ * @rproc: handle of a remote processor
+ * @da: remoteproc device address to translate
+ * @len: length of the memory region @da is pointing to
+ *
  * Some remote processors will ask us to allocate them physically contiguous
  * memory regions (which we call carveouts), and map them to specific
- * device addresses (which are hardcoded in the firmware).
+ * device addresses (which are hardcoded in the firmware). They may also have
+ * dedicated memory regions internal to the processors, and use them either
+ * exclusively or alongside carveouts.
  *
  * They may then ask us to copy objects into specific device addresses (e.g.
  * code/data sections) or expose us certain symbols in other device address
  * (e.g. their trace buffer).
  *
- * This function is an internal helper with which we can go over the allocated
- * carveouts and translate specific device address to kernel virtual addresses
- * so we can access the referenced memory.
+ * This function is a helper function with which we can go over the allocated
+ * carveouts and translate specific device addresses to kernel virtual 
addresses
+ * so we can access the referenced memory. This function also allows to perform
+ * translations on the internal remoteproc memory regions through a platform
+ * implementation specific da_to_va ops, if present.
+ *
+ * The function returns a valid kernel address on success or NULL on failure.
  *
  * Note: phys_to_virt(iommu_iova_to_phys(rproc-domain, da)) will work too,
  * but only on kernel direct mapped RAM memory. Instead, we're just using
- * here the output of the DMA API, which should be more correct.
+ * here the output of the DMA API for the carveouts, which should be more
+ * correct.
  */
 void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
 {
struct rproc_mem_entry *carveout;
void *ptr = NULL;
 
+   if (rproc-ops-da_to_va) {
+   ptr = rproc-ops-da_to_va(rproc, da, len);
+   if (ptr)
+   goto out;
+   }
+
list_for_each_entry(carveout, rproc-carveouts, node) {
int offset = da - carveout-da;
 
@@ -197,6 +215,7 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
break;
}
 
+out:
return ptr;
 }
 EXPORT_SYMBOL(rproc_da_to_va);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 0c7d403..81b224d 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -331,11 +331,13 @@ struct rproc;
  * @start: power on the device and boot it
  * @stop:  power off the device
  * @kick:  kick a virtqueue (virtqueue id given as a parameter)
+ * @da_to_va:  optional platform hook to perform address translations
  */
 struct rproc_ops {
int (*start)(struct rproc *rproc);
int (*stop)(struct rproc *rproc);
void (*kick)(struct rproc *rproc, int vqid);
+   void * (*da_to_va)(struct rproc *rproc, u64 da, int len);
 };
 
 /**
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API

[Dave Gerlach]

Allow users of remoteproc the ability to get a handle to an rproc by
passing a phandle supplied in the user's device tree node. This is
useful in situations that require manual booting of the rproc.

This patch uses the code removed by commit 40e575b1d0b3 (remoteproc:
remove the get_by_name/put API) for the ref counting a rproc klist
code but has rproc_get_by_name replaced with an rproc_get_by_phandle API.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
 Documentation/remoteproc.txt |  6 +++
 drivers/remoteproc/remoteproc_core.c | 83 
 include/linux/remoteproc.h   |  2 +
 3 files changed, 91 insertions(+)

diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index e6469fd..ef0219f 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -51,6 +51,12 @@ cost.
 rproc_shutdown() returns, and users can still use it with a subsequent
 rproc_boot(), if needed.
 
+  struct rproc *rproc_get_by_phandle(phandle phandle)
+- Find an rproc handle using a device tree phandle. Returns the rproc
+  handle on success, and NULL on failure. This function increments
+  the remote processor's refcount, so always use rproc_put() to
+  decrement it back once rproc isn't needed anymore.
+
 3. Typical usage
 
 #include linux/remoteproc.h
diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 3cd85a63..5a6c192 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -36,6 +36,7 @@
 #include linux/remoteproc.h
 #include linux/iommu.h
 #include linux/idr.h
+#include linux/klist.h
 #include linux/elf.h
 #include linux/crc32.h
 #include linux/virtio_ids.h
@@ -44,6 +45,17 @@
 
 #include remoteproc_internal.h
 
+static void klist_rproc_get(struct klist_node *n);
+static void klist_rproc_put(struct klist_node *n);
+
+/*
+ * klist of the available remote processors.
+ *
+ * We need this in order to support rproc lookups (needed by the
+ * rproc_get_by_phandle()).
+ */
+static DEFINE_KLIST(rprocs, klist_rproc_get, klist_rproc_put);
+
 typedef int (*rproc_handle_resources_t)(struct rproc *rproc,
struct resource_table *table, int len);
 typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
@@ -1162,6 +1174,71 @@ out:
 }
 EXPORT_SYMBOL(rproc_shutdown);
 
+/* will be called when an rproc is added to the rprocs klist */
+static void klist_rproc_get(struct klist_node *n)
+{
+   struct rproc *rproc = container_of(n, struct rproc, node);
+
+   get_device(rproc-dev);
+}
+
+/* will be called when an rproc is removed from the rprocs klist */
+static void klist_rproc_put(struct klist_node *n)
+{
+   struct rproc *rproc = container_of(n, struct rproc, node);
+
+   put_device(rproc-dev);
+}
+
+static struct rproc *next_rproc(struct klist_iter *i)
+{
+   struct klist_node *n;
+
+   n = klist_next(i);
+   if (!n)
+   return NULL;
+
+   return container_of(n, struct rproc, node);
+}
+
+/**
+ * rproc_get_by_phandle() - find a remote processor by phandle
+ * @phandle: phandle to the rproc
+ *
+ * Finds an rproc handle using the remote processor's phandle, and then
+ * return a handle to the rproc.
+ *
+ * Returns the rproc handle on success, and NULL on failure.
+ *
+ * This function increments the remote processor's refcount, so always
+ * use rproc_put() to decrement it back once rproc isn't needed anymore.
+ *
+ */
+struct rproc *rproc_get_by_phandle(phandle phandle)
+{
+   struct rproc *rproc;
+   struct klist_iter i;
+   struct device_node *np;
+
+   np = of_find_node_by_phandle(phandle);
+   if (!np)
+   return NULL;
+
+   /* find the remote processor, and upref its refcount */
+   klist_iter_init(rprocs, i);
+   while ((rproc = next_rproc(i)) != NULL)
+   if (rproc-dev.parent  rproc-dev.parent-of_node == np) {
+   get_device(rproc-dev);
+   break;
+   }
+   klist_iter_exit(i);
+
+   of_node_put(np);
+
+   return rproc;
+}
+EXPORT_SYMBOL(rproc_get_by_phandle);
+
 /**
  * rproc_add() - register a remote processor
  * @rproc: the remote processor handle to register
@@ -1191,6 +1268,9 @@ int rproc_add(struct rproc *rproc)
if (ret  0)
return ret;
 
+   /* expose to rproc_get_by_phandle users */
+   klist_add_tail(rproc-node, rprocs);
+
dev_info(dev, %s is available\n, rproc-name);
 
dev_info(dev, Note: remoteproc is still under development and 
considered experimental.\n);
@@ -1380,6 +1460,9 @@ int rproc_del(struct rproc *rproc)
/* Free the copy of the resource table */
kfree(rproc-cached_table);
 
+   /* the rproc is downref'ed as soon as it's removed from the klist */
+   klist_del(rproc-node);
+
device_del(rproc-dev

[PATCH v3 3/4] Documentation: dt: add bindings for TI Wakeup M3 processor

[Dave Gerlach]

Add the device tree bindings document for the TI Wakeup M3 remote
processor devices on AM33xx and AM43xx SoCs. These devices are used
to offload low-level power management functionality, and are handled
by the wkup_m3 remoteproc driver.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 .../bindings/remoteproc/wkup_m3_rproc.txt  | 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt 
b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
new file mode 100644
index 000..3a70073
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
@@ -0,0 +1,52 @@
+TI Wakeup M3 Remoteproc 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. This CM3 processor requires a firmware
+binary to accomplish this. The wkup_m3 remoteproc driver handles the loading of
+the firmware and booting of the CM3.
+
+Wkup M3 Device Node:
+
+A wkup_m3 device node is used to represent the Wakeup M3 processor instance
+within the SoC. It is added as a child node of the parent interconnect bus
+(l4_wkup) through which it is accessible to the MPU.
+
+Required properties:
+
+- compatible:  Should be one of,
+   ti,am3352-wkup-m3 for AM33xx SoCs
+   ti,am4372-wkup-m3 for AM43xx SoCs
+- reg: Should contain the address ranges for the two internal
+   memory regions, UMEM and DMEM. The parent node should
+   provide an appropriate ranges property for properly
+   translating these into bus addresses.
+- reg-names:   Contains the corresponding names for the two memory
+   regions. These should be named umem  dmem.
+- ti,hwmods:   Name of the hwmod associated with the wkupm3 device.
+- ti,pm-firmware:  Name of firmware file to be used for loading and
+   booting the wkup_m3 remote processor.
+
+Example:
+
+/* AM33xx */
+ocp {
+l4_wkup: l4_wkup@44c0 {
+   compatible = am335-l4-wkup, simple-bus;
+   ranges = 0 0x44c0 0x40;
+   #address-cells = 1;
+   #size-cells = 1;
+
+   wkup_m3: wkup_m3@10 {
+   compatible = ti,am3352-wkup-m3;
+   reg = 0x10 0x4000,
+ 0x18 0x2000;
+   reg-names = umem, dmem;
+   ti,hwmods = wkup_m3;
+   ti,pm-firmware = am335x-pm-firmware.elf;
+   };
+   };
+
+   ...
+};
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/3] ARM: OMAP2+: Use pdata-quirks for wkup_m3 reset management

[Dave Gerlach]

Use pdata-quirks to provide platform data required for reset
management during boot and shutdown of the wkup_m3 processor
on both the AM33xx and AM43xx SoCs. The WkupM3 remote processor
is used to implement and achieve low-power functionality on
the AM33xx  AM43xx SoCs.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/mach-omap2/pdata-quirks.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index e642b07..7b4a4c1 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -18,6 +18,7 @@
 
 #include linux/platform_data/pinctrl-single.h
 #include linux/platform_data/iommu-omap.h
+#include linux/platform_data/wkup_m3.h
 
 #include common.h
 #include common-board-devices.h
@@ -314,6 +315,14 @@ static struct iommu_platform_data omap4_iommu_pdata = {
 };
 #endif
 
+#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
+static struct wkup_m3_platform_data wkup_m3_data = {
+   .reset_name = wkup_m3,
+   .assert_reset = omap_device_assert_hardreset,
+   .deassert_reset = omap_device_deassert_hardreset,
+};
+#endif
+
 #ifdef CONFIG_SOC_AM33XX
 static void __init am335x_evmsk_legacy_init(void)
 {
@@ -383,6 +392,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
   am35xx_emac_pdata),
 #endif
+#ifdef CONFIG_SOC_AM33XX
+   OF_DEV_AUXDATA(ti,am3352-wkup-m3, 0x44d0, 44d0.wkup_m3,
+  wkup_m3_data),
+#endif
 #ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux, 
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux, 
pcs_pdata),
@@ -396,6 +409,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
 #endif
 #ifdef CONFIG_SOC_AM43XX
OF_DEV_AUXDATA(ti,am437-padconf, 0x44e10800, 44e10800.pinmux, 
pcs_pdata),
+   OF_DEV_AUXDATA(ti,am4372-wkup-m3, 0x44d0, 44d0.wkup_m3,
+  wkup_m3_data),
 #endif
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA(ti,omap4-iommu, 0x4a066000, 4a066000.mmu,
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/3] ARM: dts: AM33xx: Update and move wkup_m3 node to l4 node

[Dave Gerlach]

From: Suman Anna s-a...@ti.com

The WakeupM3 remote processor device node has been moved to
be a child node of the newly created l4_wkup node, to reflect
its presence properly within the SoC. The node was added
previously before any driver support, it is now updated as
per the wkup_m3_rproc bindings added alongside the driver
support.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 21fcc44..4c1b4a8 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -103,6 +103,15 @@
#size-cells = 1;
ranges = 0 0x44c0 0x28;
 
+   wkup_m3: wkup_m3@10 {
+   compatible = ti,am3352-wkup-m3;
+   reg = 0x10 0x4000,
+ 0x18 0x2000;
+   reg-names = umem, dmem;
+   ti,hwmods = wkup_m3;
+   ti,pm-firmware = am335x-pm-firmware.elf;
+   };
+
prcm: prcm@20 {
compatible = ti,am3-prcm;
reg = 0x20 0x4000;
@@ -762,14 +771,6 @@
reg = 0x4030 0x1; /* 64k */
};
 
-   wkup_m3: wkup_m3@44d0 {
-   compatible = ti,am3353-wkup-m3;
-   reg = 0x44d0 0x4000/* M3 UMEM */
-  0x44d8 0x2000;  /* M3 DMEM */
-   ti,hwmods = wkup_m3;
-   ti,no-reset-on-init;
-   };
-
elm: elm@4808 {
compatible = ti,am3352-elm;
reg = 0x4808 0x2000;
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/3] ARM: OMAP2+: wkup_m3_rproc support patches

[Dave Gerlach]

This series adds the mach-omap2 code and DT nodes for v3 of the
wkup_m3_rproc driver submitted here [1]. pdata-quirks patch requires
the pdata added with patch 4 of the aforementioned series. Based on
previous discussion here [2], the wkup_m3 DT node has been moved as a
child of the l4_wkup as is done for l4_wkup components in Tero Kristo's
series PRCM+SCM cleanup against 4.0-rc1 found here [3]. Because of that,
this series applies cleanly on top of that series in order to leverage the
l4_wkup parent node introduced there.

In addition to the move of the wkup_m3 node for am33xx, a new patch
has been added to introduce the wkup_m3 node in the same fashion for
am43xx as both SoCs use the same configuration. With this change
support was also added to pdata-quirks for passing reset handlers to
the driver for the am43xx binding as was already done for am33xx.

I have pushed a branch containing all patches for am335x suspend
here for a big picture view of how all patches fit together with
these wkup_m3_rproc series [4].

v2-v3:
-Change ti,am3353-wkup-m3 compat to ti,am3352-wkup-m3 to reflect
 binding documentation change
-Add ti,am4372-wkup-m3 node to am4372 SoC dt file
-Add am4372 support to pdata-quirks for reset handlers

Regards,
Dave

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg115869.html
[2] http://www.spinics.net/lists/linux-omap/msg116366.html
[3] http://www.spinics.net/lists/arm-kernel/msg409842.html
[4] https://github.com/dgerlach/linux-pm/tree/pm-v4.0-rc5-am335x-suspend

Dave Gerlach (1):
  ARM: OMAP2+: Use pdata-quirks for wkup_m3 reset management

Suman Anna (2):
  ARM: dts: AM33xx: Update and move wkup_m3 node to l4 node
  ARM: dts: AM4372: Add the wkupm3 rproc node

 arch/arm/boot/dts/am33xx.dtsi  | 17 +
 arch/arm/boot/dts/am4372.dtsi  |  9 +
 arch/arm/mach-omap2/pdata-quirks.c | 15 +++
 3 files changed, 33 insertions(+), 8 deletions(-)

-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/3] ARM: dts: AM4372: Add the wkupm3 rproc node

[Dave Gerlach]

From: Suman Anna s-a...@ti.com

Add the Wakeup M3 remote processor device node for
the AM4372 SoC. The WkupM3 remote processor is used
to implement and achieve low-power functionality on
the AM33xx  AM43xx SoCs.

This node is added as a child of the recently added
l4_wkup node to reflect its presence within the SoC.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index f8a02a2..821bb772 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -74,6 +74,15 @@
#size-cells = 1;
ranges = 0 0x44c0 0x287000;
 
+   wkup_m3: wkup_m3@10 {
+   compatible = ti,am4372-wkup-m3;
+   reg = 0x10 0x4000,
+ 0x18 0x2000;
+   reg-names = umem, dmem;
+   ti,hwmods = wkup_m3;
+   ti,pm-firmware = am335x-pm-firmware.elf;
+   };
+
prcm: prcm@1f {
compatible = ti,am4-prcm;
reg = 0x1f 0x11000;
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property

[Dave Gerlach]

Grygorii,
On 03/11/2015 11:32 AM, Grygorii Strashko wrote:
 Hi Dave,
 
 On 03/10/2015 07:59 PM, Dave Gerlach wrote:
 On 03/10/2015 12:36 PM, Grygorii Strashko wrote:
 On 03/06/2015 07:45 PM, Tony Lindgren wrote:
 * Dave Gerlach d-gerl...@ti.com [150306 09:28]:
 On 03/05/2015 06:41 PM, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [150305 12:24]:
 * Dave Gerlach d-gerl...@ti.com [150305 11:53]:
 On 03/05/2015 12:49 PM, Tony Lindgren wrote:
 * Paul Walmsley p...@pwsan.com [150305 10:16]:
 On Thu, 5 Mar 2015, Dave Gerlach wrote:

 Introduce a dt property, ti,no-init, that prevents hwmod 
 initialization.
 Even if a dt node is marked as disabled, hwmod still at least 
 enables
 the hwmod and programs the sysconfig before attempting to idle it at
 boot. If an IP has been disabled by the hardware configuration on a
 platform, this will cause a hang due to writing to inactive 
 registers.
 This property prevents that from happening by marking the hwmod as
 _HWMOD_STATE_DISABLED during init.

 I'm kind of wondering if hwmod should even touch a device if it's 
 marked
 as disabled in the DT.  Tony, what do you think?

 Well nothing happens if a device is status = disabled. No dev entry
 gets created for it at all and hwmod won't have any data for the 
 device
 populated. The only way hwmod code could see that device if the device
 gets it's data from the legacy omap_hwmod_*_data.c instead of DT.


 We still need this for the sysconfig programming, correct? hwmod 
 programs that
 regardless of dt status and then idles the IP,

 Well hwmod does not even know about the IP IO addresses if it's marked
 with status = disabled.. Which IP are you having problems with?

 which is why I needed the ti,no-init for the epos evm. It isn't just a
 matter of we shouldnt write to it because we don't want to use it; we
 can't write to it because the module is held off so it causes an
 external abort if we do.

 Well hard to say not knowing which module this is.. Pretty much all
 the modules have drivers and the driver just does pm_runtime_get()
 on it?

 Heh OK this thread is about the RTC driver, so I assume that's the
 problem :) So if you set the rtc to status = disabled how can the
 hwmod code do anything as AFAIK it won't even get the rtc IO address?

 Or am I missing something here?

 Perhaps I am mistaken, but from what I understand, all hwmods have _init 
 and
 _setup called on them, and all hwmods read the IO address regardless of DT
 status at this point with _init_mpu_rt_base. In _setup, _setup_reset gets 
 called
 which calls _enable for the hwmod, and this calls both _enable_sysc and
 _update_sysc_cache which touch the sysconfig register of the IP.
 
 And that's the problem :) What ePar says:
 “disabled” - Indicates that the device is not presently operational, but it 
 might
 become operational in the future (for example, something is not plugged in, 
 or switched off).
 
 and current OF implementation will not register corresponding device
 in DD core and, as result, drivers will be never ever bound with these 
 devices.
 As i said before, such devices are invisible/absent/not present, so
 there are no reasons to touch them at all in Kernel, because result is 
 unpredictable
 in general. And there are no guarantee that there will be no other issues, 
 even if you'll fix this particular case.

I agree with all of this, but we can't do this entirely without breaking PM, at
least until omap_hwmod is entirely gone. If we were to prevent omap_hwmod from
touching any dt node marked as disabled, then we aren't going to be able to idle
all IPs. omap_hwmod/omap_device handles idling of unused IPs, and we many times
need the SYSCONFIG register to do that, so we can't ignore ALL disabled dt nodes
until that system is replaced. I dont think it's reasonable to ask people to
include every single driver just to get PM. But, this is far beyond the scope of
what this patch is trying to solve.

 

 Oh OK, I think you're right. I was thinking of omap_device_build_from_dt(),
 sorry. Looks like the hwmod IO address data does get populated even
 for status = disabled although the dev entry won't get created and
 omap_device_build_from_dt() never gets called.

 Normally this is fine regardless of whether or not we are using an IP 
 because
 the module will wake up for a moment, have it's sysc programmed, and then 
 be put
 back to sleep later, potentially never to be woken again if we bind no 
 driver
 for it, which is fine for 99% of cases. In the case of am43x epos evm, 
 you can
 
 ^^ if status=“disabled”/failed there will be no device and no driver will 
 have been bound :)
 
 take the same piece of silicon that will boot happily on the gp evm with 
 the rtc
 hwmod in place and it will hang during boot on the epos evm because the 
 board
 uses a pin to hold the RTC IP in reset. There is no way to detect this in
 software, the module can be turned on as normal using the clk_ctrl, but 
 if you
 touch any of the IP registers you

Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property

[Dave Gerlach]

Grygorii,
On 03/10/2015 12:36 PM, Grygorii Strashko wrote:
 Hi Dave,
 
 On 03/06/2015 07:45 PM, Tony Lindgren wrote:
 * Dave Gerlach d-gerl...@ti.com [150306 09:28]:
 On 03/05/2015 06:41 PM, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [150305 12:24]:
 * Dave Gerlach d-gerl...@ti.com [150305 11:53]:
 On 03/05/2015 12:49 PM, Tony Lindgren wrote:
 * Paul Walmsley p...@pwsan.com [150305 10:16]:
 On Thu, 5 Mar 2015, Dave Gerlach wrote:

 Introduce a dt property, ti,no-init, that prevents hwmod 
 initialization.
 Even if a dt node is marked as disabled, hwmod still at least enables
 the hwmod and programs the sysconfig before attempting to idle it at
 boot. If an IP has been disabled by the hardware configuration on a
 platform, this will cause a hang due to writing to inactive registers.
 This property prevents that from happening by marking the hwmod as
 _HWMOD_STATE_DISABLED during init.

 I'm kind of wondering if hwmod should even touch a device if it's 
 marked
 as disabled in the DT.  Tony, what do you think?

 Well nothing happens if a device is status = disabled. No dev entry
 gets created for it at all and hwmod won't have any data for the device
 populated. The only way hwmod code could see that device if the device
 gets it's data from the legacy omap_hwmod_*_data.c instead of DT.


 We still need this for the sysconfig programming, correct? hwmod 
 programs that
 regardless of dt status and then idles the IP,

 Well hwmod does not even know about the IP IO addresses if it's marked
 with status = disabled.. Which IP are you having problems with?

 which is why I needed the ti,no-init for the epos evm. It isn't just a
 matter of we shouldnt write to it because we don't want to use it; we
 can't write to it because the module is held off so it causes an
 external abort if we do.

 Well hard to say not knowing which module this is.. Pretty much all
 the modules have drivers and the driver just does pm_runtime_get()
 on it?

 Heh OK this thread is about the RTC driver, so I assume that's the
 problem :) So if you set the rtc to status = disabled how can the
 hwmod code do anything as AFAIK it won't even get the rtc IO address?

 Or am I missing something here?

 Perhaps I am mistaken, but from what I understand, all hwmods have _init and
 _setup called on them, and all hwmods read the IO address regardless of DT
 status at this point with _init_mpu_rt_base. In _setup, _setup_reset gets 
 called
 which calls _enable for the hwmod, and this calls both _enable_sysc and
 _update_sysc_cache which touch the sysconfig register of the IP.

 Oh OK, I think you're right. I was thinking of omap_device_build_from_dt(),
 sorry. Looks like the hwmod IO address data does get populated even
 for status = disabled although the dev entry won't get created and
 omap_device_build_from_dt() never gets called.

 Normally this is fine regardless of whether or not we are using an IP 
 because
 the module will wake up for a moment, have it's sysc programmed, and then 
 be put
 back to sleep later, potentially never to be woken again if we bind no 
 driver
 for it, which is fine for 99% of cases. In the case of am43x epos evm, you 
 can
 take the same piece of silicon that will boot happily on the gp evm with 
 the rtc
 hwmod in place and it will hang during boot on the epos evm because the 
 board
 uses a pin to hold the RTC IP in reset. There is no way to detect this in
 software, the module can be turned on as normal using the clk_ctrl, but if 
 you
 touch any of the IP registers you get an abort.

 OK sounds like some dts property is needed to signal this.
 
 As I understand, there is device RTC and this device has status 'disabled',
 so there is reasonable question why do we need to touch it at all?
 The HWMOD is some kind of SoC description, which was needed before DT.
 Now with DT in place it seems unreasonable to touch any IP block which:
 - are not defined in DT
 - has status 'disabled'.
 in above cases the u-boot has to dial with IP block if it's invisible for 
 Kernel.
 
 The HWMOD framework intended to reset and put in some predefined states IPs 
 which are
 visible for the Kernel, so then proper driver can start working with IP or IP 
 will be
 kept in some low-power state if there is no driver.

Currently we still need this hwmod behavior as not all IPs are in an ideal state
for PM by default. Not sure if you saw my last email in this thread but I gave
an example for USB hwmod:

If no USB driver is bound even just letting omap_device idle it using the USB_
CLKCTRL in the PRCM will not work properly, because the USB on am33xx expects
it's SYSCONFIG STANDBY_MODE to be software supervised, the default state
(SMART_STANDBY) does not let the IP go into standby so the IP gets stuck in a
partially off state but does not actually shut down as expected.

So we need to be able to touch the dt nodes even if they are marked as disabled
because we need to get the IO address to have access to the SYSCONFIG register.
I

Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property

[Dave Gerlach]

Tony,
On 03/06/2015 11:45 AM, Tony Lindgren wrote:
 * Dave Gerlach d-gerl...@ti.com [150306 09:28]:
 On 03/05/2015 06:41 PM, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [150305 12:24]:
 * Dave Gerlach d-gerl...@ti.com [150305 11:53]:
 On 03/05/2015 12:49 PM, Tony Lindgren wrote:
 * Paul Walmsley p...@pwsan.com [150305 10:16]:
 On Thu, 5 Mar 2015, Dave Gerlach wrote:

 Introduce a dt property, ti,no-init, that prevents hwmod 
 initialization.
 Even if a dt node is marked as disabled, hwmod still at least enables
 the hwmod and programs the sysconfig before attempting to idle it at
 boot. If an IP has been disabled by the hardware configuration on a
 platform, this will cause a hang due to writing to inactive registers.
 This property prevents that from happening by marking the hwmod as
 _HWMOD_STATE_DISABLED during init.

 I'm kind of wondering if hwmod should even touch a device if it's 
 marked 
 as disabled in the DT.  Tony, what do you think?

 Well nothing happens if a device is status = disabled. No dev entry
 gets created for it at all and hwmod won't have any data for the device
 populated. The only way hwmod code could see that device if the device
 gets it's data from the legacy omap_hwmod_*_data.c instead of DT.


 We still need this for the sysconfig programming, correct? hwmod programs 
 that
 regardless of dt status and then idles the IP,

 Well hwmod does not even know about the IP IO addresses if it's marked
 with status = disabled.. Which IP are you having problems with?

 which is why I needed the ti,no-init for the epos evm. It isn't just a
 matter of we shouldnt write to it because we don't want to use it; we
 can't write to it because the module is held off so it causes an
 external abort if we do.

 Well hard to say not knowing which module this is.. Pretty much all
 the modules have drivers and the driver just does pm_runtime_get()
 on it?

 Heh OK this thread is about the RTC driver, so I assume that's the
 problem :) So if you set the rtc to status = disabled how can the
 hwmod code do anything as AFAIK it won't even get the rtc IO address?

 Or am I missing something here?

 Perhaps I am mistaken, but from what I understand, all hwmods have _init and
 _setup called on them, and all hwmods read the IO address regardless of DT
 status at this point with _init_mpu_rt_base. In _setup, _setup_reset gets 
 called
 which calls _enable for the hwmod, and this calls both _enable_sysc and
 _update_sysc_cache which touch the sysconfig register of the IP.
 
 Oh OK, I think you're right. I was thinking of omap_device_build_from_dt(),
 sorry. Looks like the hwmod IO address data does get populated even
 for status = disabled although the dev entry won't get created and
 omap_device_build_from_dt() never gets called.
 
 Normally this is fine regardless of whether or not we are using an IP because
 the module will wake up for a moment, have it's sysc programmed, and then be 
 put
 back to sleep later, potentially never to be woken again if we bind no driver
 for it, which is fine for 99% of cases. In the case of am43x epos evm, you 
 can
 take the same piece of silicon that will boot happily on the gp evm with the 
 rtc
 hwmod in place and it will hang during boot on the epos evm because the board
 uses a pin to hold the RTC IP in reset. There is no way to detect this in
 software, the module can be turned on as normal using the clk_ctrl, but if 
 you
 touch any of the IP registers you get an abort.
 
 OK sounds like some dts property is needed to signal this.
  
 So we need to prevent this from happening but of course we can't selectively
 choose when the rtc hwmod gets added based on which board we are using so it
 seemed a DT flag was appropriate to indicate that we do not want to init the 
 rtc
 IP at all only on this board.

 Without this flag in place but with the rtc hwmod added, the am43x-epos-evm
 fails booting with an imprecise abort.
 
 OK thanks for explaining it. I'm fine with this patch, Paul may have
 other issues. The other option would be to use status = disabled to
 not touch the device at all like Paul suggested. I wonder if that's
 going to break PM on some devices though..

Well the initial programming of the SYSCONFIG register is pretty important for
certain modules, just take AM33xx USB hwmod for example.

If no USB driver is bound even just letting omap_device idle it using the USB_
CLKCTRL in the PRCM after no driver gets bound will not work properly, because
the USB on am33xx expects it's SYSCONFIG STANDBY_MODE to be software supervised,
the default state (SMART_STANDBY) does not let the IP go into standby so the IP
gets stuck in a partially off state but does not actually shut down as expected.

So I don't think we can change this without consequences elsewhere.

Regards,
Dave

 
 Regards,
 
 Tony
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http

Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges

[Dave Gerlach]

Tony,
On 03/10/2015 11:09 AM, Tony Lindgren wrote:
 * Suman Anna s-a...@ti.com [150309 16:59]:
 On 03/05/2015 10:57 AM, Tony Lindgren wrote:
 * Suman Anna s-a...@ti.com [150305 08:47]:
 On 03/05/2015 09:40 AM, Tony Lindgren wrote:
 * Dave Gerlach d-gerl...@ti.com [150304 20:14]:
 Dave,

 Looks like the commit message disappeared during your patch preparation.

 Signed-off-by: Suman Anna s-a...@ti.com
 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 ---
  arch/arm/boot/dts/am33xx.dtsi | 21 +
  1 file changed, 13 insertions(+), 8 deletions(-)

 diff --git a/arch/arm/boot/dts/am33xx.dtsi 
 b/arch/arm/boot/dts/am33xx.dtsi
 index acd3705..086415c 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -77,10 +77,23 @@
   */
  soc {
  compatible = ti,omap-infra;
 +#address-cells = 1;
 +#size-cells = 1;
 +ranges = 0x0 0x44d0 0x4000,
 + 0x8 0x44d8 0x2000;
 +

 I think putting the ranges here will cause issues for adding
 ranges for anything else.

 How about do something like this instead (untested):

 ocp {
   l4_wkup: l4_wkup@44c0 {
   compatible = am335-l4-wkup, simple-bus;
   ranges = 0 0x44c0 0x3f;

   wkup_m3: wkup_m3@44d0 {
   compatible = ti,am3353-wkup-m3;
   reg = 0x100 0x4000,   /* M3 UMEM */
 0x18  0x2000;   /* M3 DMEM */
   ti,hwmods = wkup_m3;
   ti,pm-firmware = am335x-pm-firmware.elf;
   };

   ...
   };
 };

 That way we can start moving also the other l4_wkup components there
 eventuallly without having to redo the ranges again for wkup_m3.

 You can also look at how the scm_conf was done for dm816x.dtsi for an
 example, and the recent large set of patches posted by Tero.

 I have taken a look at both the above. The L4_WKUP range includes the
 PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0
 etc. What all do we want to move here eventually?
 
 Well eventually all the children of L4_WKUP, but that can be done
 slowly as some of the drivers have weird hacks and may not work
 properly if moved around.
 
 For example, anything with reg entries for something like SCM area will
 break as that's not going to be in the L4_WKUP area ny longer :p And
 that's actually good as it will protect us from spaghetti code
 automatically later on for new code.
 
 Depending on that, we may have to use 2 address cells like in Tero's
 PRCM cleanup series rather than the single cell translation used by
 you in dm816x.dtsi so that we can retain the relative addresses
 w.r.t the existing node bases in the derivative child nodes.
 
 Hmm OK, care to paste a dts snippet example for that?

Suman and I have been looking at this together, so I can comment here. An
implementation like this is what Suman is referring to:

+   l4_wkup: l4_wkup@44c0 {
+   compatible = am335-l4-wkup, simple-bus;
+   #address-cells = 2;
+   #size-cells = 1;
+   ranges = 0 0   0x44c0 0x10,
+1 0x0 0x44d0 0x4000,
+2 0x8 0x44d8 0x2000;
+
+   wkup_m3: wkup_m3@1,0 {
+   compatible = ti,am3353-wkup-m3;
+   reg = 1 0x0 0x4000,   /* M3 UMEM */
+ 2 0x8 0x2000;   /* M3 DMEM */
+
+   ti,hwmods = wkup_m3;
+   ti,pm-firmware = am335x-pm-firmware.elf;
+   };
+   };
+

The of_* layer automatically translates everything so the pdata-quirks can still
match based on wkup_m3@44d0. The existing wkup_m3_rproc driver works almost
entirely as is with this, all cpu addresses are read and mapped correctly but
the driver no longer will read the actual device addresses correctly which we
need for understanding where to load the firmware sections.

These device addresses are being read directly using of_get_address, which reads
the first value in the reg entries which is 1 and 2 now for UMEM and DMEM. We
would need some sort of change there also to get the proper 0x0 and 0x8
device address values. Just advancing the pointer returned by of_get_address
does the trick but this doesn't seem like the cleanest solution.

Regards,
Dave

 
 Regards,
 
 Tony
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] pinctrl: dt-bindings: Fix amx3 SLEWCTRL_FAST binding

[Dave Gerlach]

On 03/06/2015 11:13 AM, Tony Lindgren wrote:
 * Dave Gerlach d-gerl...@ti.com [150227 17:14]:
 Currently both am33xx and am43xx have the macro for SLEWCTRL_FAST
 in pinctrl dt-bindings reversed so that selecting the macro actually
 sets SLEWCTRL_SLOW in the pad control registers. These patches
 correct the bindings but leave the pinctrl states that use the binding
 *UNMODIFIED*. Previously i2c and mdio on am33xx and i2c, mdio, and
 uart on am43xx had been using this macro and selecting SLEWCTRL_FAST
 while actually programming SLEWCTRL_SLOW in the pad config registers.

 Because the intended selection was SLEWCTRL_FAST the macros are
 unchanged. I tested on am335x-gp-evm and am437x-gp-evm with no
 difference in functionality seen.
 
 Applying both into omap-for-v4.0/fixes thanks.

Thanks!

Regards,
Dave

 
 Tony
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx

[Dave Gerlach]

Paul,
On 03/05/2015 10:26 PM, Paul Walmsley wrote:
 On Thu, 5 Mar 2015, Dave Gerlach wrote:
 
 RTC hwmod is needed for proper operation of PM features like
 rtcwake and rtc-only mode so reuse the am33xx rtc hwmod.

 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 index 8eb8592..9070535 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 @@ -889,6 +889,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] 
 __initdata = {
  am43xx_l4_ls__dss,
  am43xx_l4_ls__dss_dispc,
  am43xx_l4_ls__dss_rfbi,
 +am33xx_l4_wkup__rtc,
  NULL,
  };
 
 Thanks, queued for v4.1.

Thanks, but please note as I just commented in Patch 1 of this series, without
the ti,no-init flag in place that is introduced there this patch will cause the
am43x-epos-evm to fail to boot.

Regards,
Dave

 
 
 - Paul
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx

[Dave Gerlach]

Paul,

On 03/06/2015 11:44 AM, Paul Walmsley wrote:
 Hi Dave,
 
 On Fri, 6 Mar 2015, Dave Gerlach wrote:
 
 Paul,
 On 03/05/2015 10:26 PM, Paul Walmsley wrote:
 On Thu, 5 Mar 2015, Dave Gerlach wrote:

 RTC hwmod is needed for proper operation of PM features like
 rtcwake and rtc-only mode so reuse the am33xx rtc hwmod.

 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 index 8eb8592..9070535 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 @@ -889,6 +889,7 @@ static struct omap_hwmod_ocp_if 
 *am43xx_hwmod_ocp_ifs[] __initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
 +  am33xx_l4_wkup__rtc,
NULL,
  };

 Thanks, queued for v4.1.

 Thanks, but please note as I just commented in Patch 1 of this series, 
 without
 the ti,no-init flag in place that is introduced there this patch will cause 
 the
 am43x-epos-evm to fail to boot.
 
 If that's so, shouldn't it appear in the series after patch 3, then?  
 If only patches 1 and 2 are applied, then won't the boot be broken on 
 am43x-epos-evm ?

Hmm yes you are correct that would be the case, seems I should have swapped the
order. I've gotten into the habit of putting dt patches last to enable what gets
introduced previously, guess it's not always the best thing to do. Thanks for
pointing this out.

Regards,
Dave

 
 - Paul
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property

[Dave Gerlach]

On 03/05/2015 06:41 PM, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [150305 12:24]:
 * Dave Gerlach d-gerl...@ti.com [150305 11:53]:
 On 03/05/2015 12:49 PM, Tony Lindgren wrote:
 * Paul Walmsley p...@pwsan.com [150305 10:16]:
 On Thu, 5 Mar 2015, Dave Gerlach wrote:

 Introduce a dt property, ti,no-init, that prevents hwmod initialization.
 Even if a dt node is marked as disabled, hwmod still at least enables
 the hwmod and programs the sysconfig before attempting to idle it at
 boot. If an IP has been disabled by the hardware configuration on a
 platform, this will cause a hang due to writing to inactive registers.
 This property prevents that from happening by marking the hwmod as
 _HWMOD_STATE_DISABLED during init.

 I'm kind of wondering if hwmod should even touch a device if it's marked 
 as disabled in the DT.  Tony, what do you think?

 Well nothing happens if a device is status = disabled. No dev entry
 gets created for it at all and hwmod won't have any data for the device
 populated. The only way hwmod code could see that device if the device
 gets it's data from the legacy omap_hwmod_*_data.c instead of DT.


 We still need this for the sysconfig programming, correct? hwmod programs 
 that
 regardless of dt status and then idles the IP,

 Well hwmod does not even know about the IP IO addresses if it's marked
 with status = disabled.. Which IP are you having problems with?

 which is why I needed the ti,no-init for the epos evm. It isn't just a
 matter of we shouldnt write to it because we don't want to use it; we
 can't write to it because the module is held off so it causes an
 external abort if we do.

 Well hard to say not knowing which module this is.. Pretty much all
 the modules have drivers and the driver just does pm_runtime_get()
 on it?
 
 Heh OK this thread is about the RTC driver, so I assume that's the
 problem :) So if you set the rtc to status = disabled how can the
 hwmod code do anything as AFAIK it won't even get the rtc IO address?
 
 Or am I missing something here?

Perhaps I am mistaken, but from what I understand, all hwmods have _init and
_setup called on them, and all hwmods read the IO address regardless of DT
status at this point with _init_mpu_rt_base. In _setup, _setup_reset gets called
which calls _enable for the hwmod, and this calls both _enable_sysc and
_update_sysc_cache which touch the sysconfig register of the IP.

Normally this is fine regardless of whether or not we are using an IP because
the module will wake up for a moment, have it's sysc programmed, and then be put
back to sleep later, potentially never to be woken again if we bind no driver
for it, which is fine for 99% of cases. In the case of am43x epos evm, you can
take the same piece of silicon that will boot happily on the gp evm with the rtc
hwmod in place and it will hang during boot on the epos evm because the board
uses a pin to hold the RTC IP in reset. There is no way to detect this in
software, the module can be turned on as normal using the clk_ctrl, but if you
touch any of the IP registers you get an abort.

So we need to prevent this from happening but of course we can't selectively
choose when the rtc hwmod gets added based on which board we are using so it
seemed a DT flag was appropriate to indicate that we do not want to init the rtc
IP at all only on this board.

Without this flag in place but with the rtc hwmod added, the am43x-epos-evm
fails booting with an imprecise abort.

Regards,
Dave

 
 Regards,
 
 Tony
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property

[Dave Gerlach]

On 03/05/2015 12:49 PM, Tony Lindgren wrote:
 * Paul Walmsley p...@pwsan.com [150305 10:16]:
 On Thu, 5 Mar 2015, Dave Gerlach wrote:

 Introduce a dt property, ti,no-init, that prevents hwmod initialization.
 Even if a dt node is marked as disabled, hwmod still at least enables
 the hwmod and programs the sysconfig before attempting to idle it at
 boot. If an IP has been disabled by the hardware configuration on a
 platform, this will cause a hang due to writing to inactive registers.
 This property prevents that from happening by marking the hwmod as
 _HWMOD_STATE_DISABLED during init.

 I'm kind of wondering if hwmod should even touch a device if it's marked 
 as disabled in the DT.  Tony, what do you think?
 
 Well nothing happens if a device is status = disabled. No dev entry
 gets created for it at all and hwmod won't have any data for the device
 populated. The only way hwmod code could see that device if the device
 gets it's data from the legacy omap_hwmod_*_data.c instead of DT.
 

We still need this for the sysconfig programming, correct? hwmod programs that
regardless of dt status and then idles the IP, which is why I needed the
ti,no-init for the epos evm. It isn't just a matter of we shouldnt write to it
because we don't want to use it; we can't write to it because the module is held
off so it causes an external abort if we do.

Regards,
Dave

 So maybe the comments in the $subject patch are incorrect for that?
 
 What we really should have is also status = incomplete where the
 dev entry gets created, but the driver never probes. This would be for
 devices that are still there within the SoC, but not pinned out for
 the board in question.
 
 We still may need also ti,no-init too for devices that we don't want
 hwmod to do anything with, for example in secure mode if some blocks
 are not available to Linux at all. I believe that's what's going on with
 n900 crypto accelerators for example.
 
 Regards,
 
 Tony
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] ARM: dts: am437x-gp-evm: Enable RTC

[Dave Gerlach]

From: Keerthy j-keer...@ti.com

Enable RTC on am437x-gp-evm.

Signed-off-by: Keerthy j-keer...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index f84d971..b2a16c2 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -651,3 +651,7 @@
};
};
 };
+
+rtc {
+   status = okay;
+};
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property

[Dave Gerlach]

Introduce a dt property, ti,no-init, that prevents hwmod initialization.
Even if a dt node is marked as disabled, hwmod still at least enables
the hwmod and programs the sysconfig before attempting to idle it at
boot. If an IP has been disabled by the hardware configuration on a
platform, this will cause a hang due to writing to inactive registers.
This property prevents that from happening by marking the hwmod as
_HWMOD_STATE_DISABLED during init.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 Documentation/devicetree/bindings/arm/omap/omap.txt | 2 ++
 arch/arm/mach-omap2/omap_hwmod.c| 7 ++-
 arch/arm/mach-omap2/omap_hwmod.h| 4 
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 4f6a82c..7c0d3a53 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -23,6 +23,8 @@ Optional properties:
   during suspend.
 - ti,no-reset-on-init: When present, the module should not be reset at init
 - ti,no-idle-on-init: When present, the module should not be idled at init
+- ti,no_init: When present, the module is marked as disabled immediately and
+  no setup is done.
 
 Example:
 
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 92afb72..e835f61 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2471,9 +2471,14 @@ static int __init _init(struct omap_hwmod *oh, void 
*data)
oh-flags |= HWMOD_INIT_NO_RESET;
if (of_find_property(np, ti,no-idle-on-init, NULL))
oh-flags |= HWMOD_INIT_NO_IDLE;
+   if (of_find_property(np, ti,no-init, NULL))
+   oh-flags |= HWMOD_NO_INIT;
}
 
-   oh-_state = _HWMOD_STATE_INITIALIZED;
+   if (oh-flags  HWMOD_NO_INIT)
+   oh-_state = _HWMOD_STATE_DISABLED;
+   else
+   oh-_state = _HWMOD_STATE_INITIALIZED;
 
return 0;
 }
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 9d4bec6e..75061fc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -517,6 +517,9 @@ struct omap_hwmod_omap4_prcm {
  * HWMOD_RECONFIG_IO_CHAIN: omap_hwmod code needs to reconfigure wake-up 
  * events by calling _reconfigure_io_chain() when a device is enabled
  * or idled.
+ * HWMOD_NO_INIT: Do not initialize the hwmod. Useful for when certain
+ * platforms disable the IP through hardware configuration, like the
+ * RTC on the AM437x EPOS EVM.
  */
 #define HWMOD_SWSUP_SIDLE  (1  0)
 #define HWMOD_SWSUP_MSTANDBY   (1  1)
@@ -532,6 +535,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_FORCE_MSTANDBY   (1  11)
 #define HWMOD_SWSUP_SIDLE_ACT  (1  12)
 #define HWMOD_RECONFIG_IO_CHAIN(1  13)
+#define HWMOD_NO_INIT  (1  14)
 
 /*
  * omap_hwmod._int_flags definitions
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx

[Dave Gerlach]

RTC hwmod is needed for proper operation of PM features like
rtcwake and rtc-only mode so reuse the am33xx rtc hwmod.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 8eb8592..9070535 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -889,6 +889,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] 
__initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+   am33xx_l4_wkup__rtc,
NULL,
 };
 
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] ARM: dts: am43x-epos-evm: Add rtc node with ti,no-init property

[Dave Gerlach]

Add rtc node with ti,no-init property so that rtc hwmod does not get
initialized as the RTC IP is disabled in hardware by the board layout
on am43x-epos-evm so the SoC cannot access the IP at all. Without this,
hwmod writes to the RTC SYSCONFIG register and causes a kernel panic
during boot.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 257c099..ba7dbc0 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -687,3 +687,7 @@
};
};
 };
+
+rtc {
+   ti,no-init;
+};
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] Add AM437x RTC

[Dave Gerlach]

Hi,
This series adds support for the rtc on am437x, as previously the hwmod
and dt entries were missing. The am43x-epos-evm requires special treatment
because the RTC gets disabled in hardware with no way to tell through
software so we add a ti,no-init dt flag for the hwmod layer so we can
avoid writing to the SYSCONFIG register and triggering an external abort.
If we use this flag for the am43x-epos-evm we can add the rtc as normal
to am437x-gp-evm. am437x-sk-evm already has the required dt entry in place. 

Regards,
Dave

Dave Gerlach (3):
  ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
  ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
  ARM: dts: am43x-epos-evm: Add rtc node with ti,no-init property

Keerthy (1):
  ARM: dts: am437x-gp-evm: Enable RTC

 Documentation/devicetree/bindings/arm/omap/omap.txt | 2 ++
 arch/arm/boot/dts/am437x-gp-evm.dts | 4 
 arch/arm/boot/dts/am43x-epos-evm.dts| 4 
 arch/arm/mach-omap2/omap_hwmod.c| 7 ++-
 arch/arm/mach-omap2/omap_hwmod.h| 4 
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c  | 1 +
 6 files changed, 21 insertions(+), 1 deletion(-)

-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] remoteproc: wkup_m3: Add wkup_m3 remoteproc driver

[Dave Gerlach]

Add a remoteproc driver to load the firmware for and boot the wkup_m3
present on am33xx and am43xx. The wkup_m3 is an integrated Cortex M3
that allows the SoC to enter the lowest possible power state by taking
control from the MPU after it has gone into its own low power state and
shutting off any additional peripherals.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 drivers/remoteproc/Kconfig|  13 ++
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/wkup_m3_rproc.c| 229 ++
 include/linux/platform_data/wkup_m3.h |  25 
 4 files changed, 268 insertions(+)
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
 create mode 100644 include/linux/platform_data/wkup_m3.h

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 5e343ba..f73ba65 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -41,6 +41,19 @@ config STE_MODEM_RPROC
  This can be either built-in or a loadable module.
  If unsure say N.
 
+config WKUP_M3_RPROC
+   tristate AMx3xx wkup-m3 remoteproc support
+   depends on SOC_AM33XX || SOC_AM43XX
+   select REMOTEPROC
+   help
+ Say y here to support AMx3xx wkup-m3.
+
+ Required for Suspend-to-ram on AM33xx and AM43XX. Also needed
+ for deep CPUIdle states on AM33xx. Allows for loading of
+ firmware of CM3 PM coprocessor that is present on AMx3xx
+ family of SoCs.
+ If unsure say N.
+
 config DA8XX_REMOTEPROC
tristate DA8xx/OMAP-L13x remoteproc support
depends on ARCH_DAVINCI_DA8XX
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ac2ff75..81b04d1 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -9,4 +9,5 @@ remoteproc-y+= remoteproc_virtio.o
 remoteproc-y   += remoteproc_elf_loader.o
 obj-$(CONFIG_OMAP_REMOTEPROC)  += omap_remoteproc.o
 obj-$(CONFIG_STE_MODEM_RPROC)  += ste_modem_rproc.o
+obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/wkup_m3_rproc.c 
b/drivers/remoteproc/wkup_m3_rproc.c
new file mode 100644
index 000..252f6f7
--- /dev/null
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -0,0 +1,229 @@
+/*
+ * TI AMx3 Wkup M3 Remote Processor driver
+ *
+ * Copyright (C) 2014-2015 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@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/interrupt.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/remoteproc.h
+
+#include linux/platform_data/wkup_m3.h
+
+#include remoteproc_internal.h
+
+#define WKUPM3_MEM_MAX 2
+
+struct wkup_m3_mem {
+   void __iomem *cpu_addr;
+   phys_addr_t bus_addr;
+   u32 dev_addr;
+   size_t size;
+};
+
+struct wkup_m3_rproc {
+   struct rproc *rproc;
+   struct platform_device *pdev;
+   struct wkup_m3_mem mem[WKUPM3_MEM_MAX];
+};
+
+static int wkup_m3_rproc_start(struct rproc *rproc)
+{
+   struct wkup_m3_rproc *wkupm3 = rproc-priv;
+   struct platform_device *pdev = wkupm3-pdev;
+   struct device *dev = pdev-dev;
+   struct wkup_m3_platform_data *pdata = dev-platform_data;
+
+   if (pdata-deassert_reset(pdev, pdata-reset_name)) {
+   dev_err(dev, Unable to reset wkup_m3!\n);
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
+static int wkup_m3_rproc_stop(struct rproc *rproc)
+{
+   struct wkup_m3_rproc *wkupm3 = rproc-priv;
+   struct platform_device *pdev = wkupm3-pdev;
+   struct device *dev = pdev-dev;
+   struct wkup_m3_platform_data *pdata = dev-platform_data;
+
+   if (pdata-assert_reset(pdev, pdata-reset_name)) {
+   dev_err(dev, Unable to assert reset of wkup_m3!\n);
+   return -ENODEV;
+   }
+   return 0;
+}
+
+static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+{
+   struct wkup_m3_rproc *wkupm3 = rproc-priv;
+   void *va = NULL;
+   int i;
+   u32 offset;
+
+   if (len = 0)
+   return NULL;
+
+   for (i = 0; i  WKUPM3_MEM_MAX; i++) {
+   if (da = wkupm3-mem[i].dev_addr 
+   da + len = wkupm3-mem[i].dev_addr +
+   wkupm3-mem[i].size) {
+   offset = da

[PATCH v2 0/3] remoteproc: Introduce wkup_m3_rproc driver

[Dave Gerlach]

Hi,
This patch series is version two of the series to add a
wkup_m3_rproc driver for TI AM335x SoCs. This family of SoCs
contains an ARM Cortex M3 coprocessor that is responsible for
low-level power tasks that cannot be handled by the main ARM
Cortex A8 so firmware running from the CM3 can be used instead.
This driver handles loading of the firmware and reset of the CM3
once it is booted.

The previous version of this series can be found here [1].
I have pushed a branch based on v4.0-rc1 containing the entire 
am335x suspend series here for a higher level view of the entire
series of patch sets here [2].

This patch set contains a new patch from Suman Anna that replaces
the RSC_INTMEM patch that this series used to depend on based on
comments on that series. More info is included in the patch.
Additional changes are:

v1 - v2:
-firmware loaded has changed, new code added by Suman Anna
-wkup_m3_rproc can now be built and loaded as a module
-added binding info and docs for am437x support
-dts and pdata-quirks patch split to separate mach-omap2 series
-remove ti,no-reset-on-init from required dt binding as it asserts
 hardreset which is default state of wkup_m3 anyway

The driver expects to load firmware am335x-pm-firmware.elf from
/lib/firmware which is found here [3].

Regards,
Dave

[1] http://www.spinics.net/lists/arm-kernel/msg387984.html
[2] https://github.com/dgerlach/linux-pm/tree/pm-v4.0-rc1-am335x-suspend
[3] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next-upstream

Dave Gerlach (2):
  Documentation: dt: add ti,am3353-wkup-m3 bindings
  remoteproc: wkup_m3: Add wkup_m3 remoteproc driver

Suman Anna (1):
  remoteproc: add a rproc ops for performing address translation

 .../bindings/remoteproc/wkup_m3_rproc.txt  |  46 +
 drivers/remoteproc/Kconfig |  13 ++
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/remoteproc_core.c   |  31 ++-
 drivers/remoteproc/wkup_m3_rproc.c | 229 +
 include/linux/platform_data/wkup_m3.h  |  25 +++
 include/linux/remoteproc.h |   2 +
 7 files changed, 341 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
 create mode 100644 include/linux/platform_data/wkup_m3.h

-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges

[Dave Gerlach]

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index acd3705..086415c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -77,10 +77,23 @@
 */
soc {
compatible = ti,omap-infra;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges = 0x0 0x44d0 0x4000,
+0x8 0x44d8 0x2000;
+
mpu {
compatible = ti,omap3-mpu;
ti,hwmods = mpu;
};
+
+   wkup_m3: wkup_m3@44d0 {
+   compatible = ti,am3353-wkup-m3;
+   reg = 0x0 0x4000, /* M3 UMEM */
+ 0x8 0x2000; /* M3 DMEM */
+   ti,hwmods = wkup_m3;
+   ti,pm-firmware = am335x-pm-firmware.elf;
+   };
};
 
am33xx_control_module: control_module@4a002000 {
@@ -755,14 +768,6 @@
reg = 0x4030 0x1; /* 64k */
};
 
-   wkup_m3: wkup_m3@44d0 {
-   compatible = ti,am3353-wkup-m3;
-   reg = 0x44d0 0x4000/* M3 UMEM */
-  0x44d8 0x2000;  /* M3 DMEM */
-   ti,hwmods = wkup_m3;
-   ti,no-reset-on-init;
-   };
-
elm: elm@4808 {
compatible = ti,am3352-elm;
reg = 0x4808 0x2000;
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] ARM: OMAP2+: wkup_m3_rproc support patches

[Dave Gerlach]

Hi,
This series adds the mach-omap2 code for the wkup_m3_rproc driver
submitted here [1]. pdata-quirks patch requires the pdata added with
patch 3 of the aforementioned series. The dt patch was previously
included as part of the rproc series here [2]. Changes are:

v1-v2: 
-Because the firmware loading has changed, the wkup_m3 node
 has moved into the soc node and ranges have been added so the
 device address to virtual address translation can work.
-Removed the ti,no-reset-on-init flag as asserting the hard-reset
 line on init is what the wkup_m3 has by default already.

Regards,
Dave

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg114621.html
[2] http://www.spinics.net/lists/arm-kernel/msg387984.html

Dave Gerlach (2):
  ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset
  ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges

 arch/arm/boot/dts/am33xx.dtsi  | 21 +
 arch/arm/mach-omap2/pdata-quirks.c | 13 +
 2 files changed, 26 insertions(+), 8 deletions(-)

-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset

[Dave Gerlach]

Use pdata-quirks to provide platform data required for reset
of the wkup_m3 during boot.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
This patch requires the pdata introduced in this patch:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg114622.html

 arch/arm/mach-omap2/pdata-quirks.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 190fa43..7a09513 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -18,6 +18,7 @@
 
 #include linux/platform_data/pinctrl-single.h
 #include linux/platform_data/iommu-omap.h
+#include linux/platform_data/wkup_m3.h
 
 #include common.h
 #include common-board-devices.h
@@ -287,6 +288,14 @@ static void __init omap3_tao3530_legacy_init(void)
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
+#ifdef CONFIG_SOC_AM33XX
+static struct wkup_m3_platform_data wkup_m3_data = {
+   .reset_name = wkup_m3,
+   .assert_reset = omap_device_assert_hardreset,
+   .deassert_reset = omap_device_deassert_hardreset,
+};
+#endif
+
 #ifdef CONFIG_ARCH_OMAP4
 static void __init omap4_sdp_legacy_init(void)
 {
@@ -382,6 +391,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
   am35xx_emac_pdata),
 #endif
+#ifdef CONFIG_SOC_AM33XX
+   OF_DEV_AUXDATA(ti,am3353-wkup-m3, 0x44d0, 44d0.wkup_m3,
+  wkup_m3_data),
+#endif
 #ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux, 
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux, 
pcs_pdata),
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] remoteproc: add a rproc ops for performing address translation

[Dave Gerlach]

From: Suman Anna s-a...@ti.com

The rproc_da_to_va API is currently used to perform any device to
kernel address translations to meet the different needs of the remoteproc
core/drivers (eg: loading). The functionality is achieved within the
remoteproc core, and is limited only for carveouts allocated within the
core.

A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
processing if the platform implementation cannot provide the translation.
This will allow any remoteproc implementations to translate addresses for
dedicated memories like internal memories, and facilitate the remoteproc
core to also load certain firmware sections into internal memories (eg:
RAM at L1 or L2 levels) for performance or other reasons.

While at this, also update the rproc_da_to_va() documentation since it
is an exported function.

Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
This patch is a replacement for the patch (remoteproc: add support to
handle internal memories) @ https://patchwork.kernel.org/patch/5602981/
The representation of internal memory regions is left to the individual
platform implementations, as this might vary from one to another.

 drivers/remoteproc/remoteproc_core.c | 31 +--
 include/linux/remoteproc.h   |  2 ++
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 3cd85a63..e9825bd 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -147,28 +147,46 @@ static void rproc_disable_iommu(struct rproc *rproc)
return;
 }
 
-/*
+/**
+ * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc 
address
+ * @rproc: handle of a remote processor
+ * @da: remoteproc device address to translate
+ * @len: length of the memory region @da is pointing to
+ *
  * Some remote processors will ask us to allocate them physically contiguous
  * memory regions (which we call carveouts), and map them to specific
- * device addresses (which are hardcoded in the firmware).
+ * device addresses (which are hardcoded in the firmware). They may also have
+ * dedicated memory regions internal to the processors, and use them either
+ * exclusively or alongside carveouts.
  *
  * They may then ask us to copy objects into specific device addresses (e.g.
  * code/data sections) or expose us certain symbols in other device address
  * (e.g. their trace buffer).
  *
- * This function is an internal helper with which we can go over the allocated
- * carveouts and translate specific device address to kernel virtual addresses
- * so we can access the referenced memory.
+ * This function is a helper function with which we can go over the allocated
+ * carveouts and translate specific device addresses to kernel virtual 
addresses
+ * so we can access the referenced memory. This function also allows to perform
+ * translations on the internal remoteproc memory regions through a platform
+ * implementation specific da_to_va ops, if present.
+ *
+ * The function returns a valid kernel address on success or NULL on failure.
  *
  * Note: phys_to_virt(iommu_iova_to_phys(rproc-domain, da)) will work too,
  * but only on kernel direct mapped RAM memory. Instead, we're just using
- * here the output of the DMA API, which should be more correct.
+ * here the output of the DMA API for the carveouts, which should be more
+ * correct.
  */
 void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
 {
struct rproc_mem_entry *carveout;
void *ptr = NULL;
 
+   if (rproc-ops-da_to_va) {
+   ptr = rproc-ops-da_to_va(rproc, da, len);
+   if (ptr)
+   goto out;
+   }
+
list_for_each_entry(carveout, rproc-carveouts, node) {
int offset = da - carveout-da;
 
@@ -185,6 +203,7 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
break;
}
 
+out:
return ptr;
 }
 EXPORT_SYMBOL(rproc_da_to_va);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 9e7e745..e0c0715 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -330,11 +330,13 @@ struct rproc;
  * @start: power on the device and boot it
  * @stop:  power off the device
  * @kick:  kick a virtqueue (virtqueue id given as a parameter)
+ * @da_to_va:  optional platform hook to perform address translations
  */
 struct rproc_ops {
int (*start)(struct rproc *rproc);
int (*stop)(struct rproc *rproc);
void (*kick)(struct rproc *rproc, int vqid);
+   void * (*da_to_va)(struct rproc *rproc, u64 da, int len);
 };
 
 /**
-- 
2.3.0

--
To unsubscribe

[PATCH v2 2/3] Documentation: dt: add ti,am3353-wkup-m3 bindings

[Dave Gerlach]

Add the device tree bindings document for ti,am3353-wkup-m3 which is
used by the wkup_m3_rproc driver.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 .../bindings/remoteproc/wkup_m3_rproc.txt  | 46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt 
b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
new file mode 100644
index 000..995af3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
@@ -0,0 +1,46 @@
+Wakeup M3 Remoteproc Driver
+===
+
+TI AMx3 family of devices use a Cortex M3 co-processor to help with various
+low power tasks that cannot be controlled from the MPU. The CM3 requires
+a firmware binary to accomplish this. The wkup_m3 remoteproc driver handles
+the loading of the firmware and booting of the CM3.
+
+Wkup M3 Device Node:
+
+A wkup_m3 device node is used to represent a wakeup M3 IP instance within
+a SoC.
+
+Required properties:
+
+- compatible:  Should be:
+   ti,am3353-wkup-m3 for AM33xx SoCs
+   ti,am4372-wkup-m3 for AM43xx SoCs
+- reg: Contains the wkup_m3 register address ranges for
+   umem and dmem, from the devices address space.
+   NOTE: Parent node must contains ranges specifying
+ mapping from bus address space to device
+ address space.
+- ti,hwmods:   Name of the hwmod associated with the mailbox
+- ti,pm-firmware:  Name of firmware file to load for remoteproc.
+
+Example:
+
+/* AM33xx */
+soc {
+compatible = ti,omap-infra;
+#address-cells = 1;
+#size-cells = 1;
+ranges = 0x0 0x44d0 0x4000,
+ 0x8 0x44d8 0x2000;
+
+   ...
+
+   wkup_m3: wkup_m3@44d0 {
+   compatible = ti,am3353-wkup-m3;
+   reg = 0x0 0x4000   /* M3 UMEM */
+  0x8 0x2000; /* M3 DMEM */
+   ti,hwmods = wkup_m3;
+   ti,pm-firmware = am335x-pm-firmware.elf;
+   };
+};
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] soc: ti: Add wkup_m3_ipc driver

[Dave Gerlach]

Tony,
On 02/26/2015 04:08 PM, Tony Lindgren wrote:
 * Dave Gerlach d-gerl...@ti.com [150226 12:05]:
 Tony,
 On 01/05/2015 04:51 PM, Tony Lindgren wrote:
 * Dave Gerlach d-gerl...@ti.com [150105 14:51]:
 Felipe,
 On 01/02/2015 02:16 PM, Felipe Balbi wrote:
 On Fri, Jan 02, 2015 at 02:00:16PM -0600, Dave Gerlach wrote:
 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-gerl...@ti.com
 ---
  drivers/soc/ti/Kconfig   |  11 ++
  drivers/soc/ti/Makefile  |   1 +
  drivers/soc/ti/wkup_m3_ipc.c | 451 
 +++
  include/linux/wkup_m3_ipc.h  |  33 
  4 files changed, 496 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..61cda85 100644
 --- a/drivers/soc/ti/Kconfig
 +++ b/drivers/soc/ti/Kconfig
 @@ -28,4 +28,15 @@ config KEYSTONE_NAVIGATOR_DMA
  
If unsure, say N.
  
 +config WKUP_M3_IPC
 +bool TI AM33XX Wkup-M3 IPC Driver

 tristate ?

 If we want to allow this and the rproc driver to be built as modules than 
 we can
 change this.

 Yes please, the PM is never needed early, and should be optional.
 And doing that will make it a lot easier for you to do further work
 on your driver ;)

 And it will also make it easier to add support for other SoCs as
 it seems the same M3 is used at least on am437x.
  

 I can not build the PM code as a module at this time due to many mach-omap
 function calls it uses which are not exported, so I need handles to all five
 functions in this driver used in pm33xx to call from built-in PM code. Do you
 have a preference on how these function handles get passed?
 
 OK, you can pass the function pointers in platform_data. Care to
 list those functions? That might allow us to make other omap PM
 code into loadable modules in drivers/* :)

Sure, apart from the dependencies I create for myself in other modules that I
introduce I see:

ERROR: omap_pm_clkdms_setup [arch/arm/mach-omap2/pm33xx.ko] undefined!
ERROR: clkdm_for_each [arch/arm/mach-omap2/pm33xx.ko] undefined!
ERROR: clkdm_lookup [arch/arm/mach-omap2/pm33xx.ko] undefined!
ERROR: pwrdm_lookup [arch/arm/mach-omap2/pm33xx.ko] undefined!
ERROR: pwrdm_post_transition [arch/arm/mach-omap2/pm33xx.ko] undefined!
ERROR: clkdm_sleep [arch/arm/mach-omap2/pm33xx.ko] undefined!
ERROR: clkdm_wakeup [arch/arm/mach-omap2/pm33xx.ko] undefined!
ERROR: pwrdm_read_pwrst [arch/arm/mach-omap2/pm33xx.ko] undefined!
ERROR: cpu_suspend [arch/arm/mach-omap2/pm33xx.ko] undefined!
ERROR: omap_set_pwrdm_state [arch/arm/mach-omap2/pm33xx.ko] undefined!

So the mach-omap2 clockdomain and power domain functions along with arch arm
cpu_suspend code. I see similar dependencies in the other mach-omap2/pm.c
code also.

  
 I currently have added a pdata-quirks implementation that passes a function 
 to
 the wkup_m3_ipc driver through it's pdata which it then calls at probe to 
 pass a
 struct containing all used function pointers to the pm code that were 
 previously
 called directly. Is that what you would prefer or something else? I had also
 looked at making the struct of function pointers in the driver global and 
 just
 picking it up from the pm code with an extern declaration or even putting a 
 bus
 notifier in the PM code and watching for the wkup_m3_ipc driver to be bound.
 
 Yeah pdata-quirks.c is probably OK for populating the function pointers.
 We may have already some place in the PM code to pass it too.
  

Alright, thanks for your input.

 Thought I would see what you prefer and possibly avoid an unnecessary 
 re-spin.
 
 Sounds like we're getting close to getting am335x/am437x PM code working :)

Getting there!

Regards,
Dave

 
 Regards,
 
 Tony
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] pinctrl: am33xx: dt-bindings: fix SLEWCTRL_FAST binding

[Dave Gerlach]

According to AM335x TRM, Document spruh73l, Revised February 2015,
Section 9.2.2 Pad Control Registers, setting bit 6 of the pad control
registers actually sets the SLEWCTRL value to slow rather than fast as
the current macro indicates. Introduce a new macro, SLEWCTRL_SLOW, that
sets the bit, and modify SLEWCTRL_FAST to 0 but keep it for
completeness.

Current users of the macro (i2c and mdio) are left unmodified as
SLEWCTRL_FAST was the macro used and actual desired state. Tested on
am335x-gp-evm with no difference in software performance seen.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 include/dt-bindings/pinctrl/am33xx.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/dt-bindings/pinctrl/am33xx.h 
b/include/dt-bindings/pinctrl/am33xx.h
index 2fbc804..226f772 100644
--- a/include/dt-bindings/pinctrl/am33xx.h
+++ b/include/dt-bindings/pinctrl/am33xx.h
@@ -13,7 +13,8 @@
 
 #define PULL_DISABLE   (1  3)
 #define INPUT_EN   (1  5)
-#define SLEWCTRL_FAST  (1  6)
+#define SLEWCTRL_SLOW  (1  6)
+#define SLEWCTRL_FAST  0
 
 /* update macro depending on INPUT_EN and PULL_ENA */
 #undef PIN_OUTPUT
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] pinctrl: am43xx: dt-bindings: fix SLEWCTRL_FAST binding

[Dave Gerlach]

According to AM437x TRM, Document SPRUHL7B, Revised December 2014,
Section 7.2.1 Pad Control Registers, setting bit 19 of the pad control
registers actually sets the SLEWCTRL value to slow rather than fast as
the current macro indicates. Introduce a new macro, SLEWCTRL_SLOW, that
sets the bit, and modify SLEWCTRL_FAST to 0 but keep it for
completeness.

Current users of the macro (i2c, mdio, and uart) are left unmodified as
SLEWCTRL_FAST was the macro used and actual desired state. Tested on
am437x-gp-evm with no difference in software performance seen.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 include/dt-bindings/pinctrl/am43xx.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/dt-bindings/pinctrl/am43xx.h 
b/include/dt-bindings/pinctrl/am43xx.h
index 9c2e4f8..5f4d0189 100644
--- a/include/dt-bindings/pinctrl/am43xx.h
+++ b/include/dt-bindings/pinctrl/am43xx.h
@@ -18,7 +18,8 @@
 #define PULL_DISABLE   (1  16)
 #define PULL_UP(1  17)
 #define INPUT_EN   (1  18)
-#define SLEWCTRL_FAST  (1  19)
+#define SLEWCTRL_SLOW  (1  19)
+#define SLEWCTRL_FAST  0
 #define DS0_PULL_UP_DOWN_EN(1  27)
 
 #define PIN_OUTPUT (PULL_DISABLE)
-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] pinctrl: dt-bindings: Fix amx3 SLEWCTRL_FAST binding

[Dave Gerlach]

Currently both am33xx and am43xx have the macro for SLEWCTRL_FAST
in pinctrl dt-bindings reversed so that selecting the macro actually
sets SLEWCTRL_SLOW in the pad control registers. These patches
correct the bindings but leave the pinctrl states that use the binding
*UNMODIFIED*. Previously i2c and mdio on am33xx and i2c, mdio, and
uart on am43xx had been using this macro and selecting SLEWCTRL_FAST
while actually programming SLEWCTRL_SLOW in the pad config registers.

Because the intended selection was SLEWCTRL_FAST the macros are
unchanged. I tested on am335x-gp-evm and am437x-gp-evm with no
difference in functionality seen.

Regards,
Dave

Dave Gerlach (2):
  pinctrl: am33xx: dt-bindings: fix SLEWCTRL_FAST binding
  pinctrl: am43xx: dt-bindings: fix SLEWCTRL_FAST binding

 include/dt-bindings/pinctrl/am33xx.h | 3 ++-
 include/dt-bindings/pinctrl/am43xx.h | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.3.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] soc: ti: Add wkup_m3_ipc driver

[Dave Gerlach]

Tony,
On 01/05/2015 04:51 PM, Tony Lindgren wrote:
 * Dave Gerlach d-gerl...@ti.com [150105 14:51]:
 Felipe,
 On 01/02/2015 02:16 PM, Felipe Balbi wrote:
 On Fri, Jan 02, 2015 at 02:00:16PM -0600, Dave Gerlach wrote:
 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-gerl...@ti.com
 ---
  drivers/soc/ti/Kconfig   |  11 ++
  drivers/soc/ti/Makefile  |   1 +
  drivers/soc/ti/wkup_m3_ipc.c | 451 
 +++
  include/linux/wkup_m3_ipc.h  |  33 
  4 files changed, 496 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..61cda85 100644
 --- a/drivers/soc/ti/Kconfig
 +++ b/drivers/soc/ti/Kconfig
 @@ -28,4 +28,15 @@ config KEYSTONE_NAVIGATOR_DMA
  
  If unsure, say N.
  
 +config WKUP_M3_IPC
 +  bool TI AM33XX Wkup-M3 IPC Driver

 tristate ?

 If we want to allow this and the rproc driver to be built as modules than we 
 can
 change this.
 
 Yes please, the PM is never needed early, and should be optional.
 And doing that will make it a lot easier for you to do further work
 on your driver ;)
 
 And it will also make it easier to add support for other SoCs as
 it seems the same M3 is used at least on am437x.
  

I can not build the PM code as a module at this time due to many mach-omap
function calls it uses which are not exported, so I need handles to all five
functions in this driver used in pm33xx to call from built-in PM code. Do you
have a preference on how these function handles get passed?

I currently have added a pdata-quirks implementation that passes a function to
the wkup_m3_ipc driver through it's pdata which it then calls at probe to pass a
struct containing all used function pointers to the pm code that were previously
called directly. Is that what you would prefer or something else? I had also
looked at making the struct of function pointers in the driver global and just
picking it up from the pm code with an extern declaration or even putting a bus
notifier in the PM code and watching for the wkup_m3_ipc driver to be bound.

Thought I would see what you prefer and possibly avoid an unnecessary re-spin.

Regards,
Dave


 +  depends on WKUP_M3_RPROC
 +  select MAILBOX
 +  select OMAP2PLUS_MBOX

 selects are usually frowned upon.

 Followed example set by OMAP_REMOTEPROC which selects the mailbox, thought 
 that
 would be alright.
 
 The select should be only done if the option selected is a silen
 Kconfig option where it's never selectable by the user. Otherwise
 you will errors sooner or later with make randconfig builds as the
 dependencies change. Using depends on is better for those cases.
 
 Regards,
 
 Tony 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v5 0/4] ARM: OMAP2+: AM33XX: Add suspend-resume support

[Dave Gerlach]

Tony,
On 01/20/2015 12:03 PM, Tony Lindgren wrote:
 * Dave Gerlach d-gerl...@ti.com [141126 13:54]:
 Hi,
 This series is v5 of the series to add suspend/resume support for Texas
 Instruments AM335x SoC. It has gone through a rather major overhaul
 since the last version and because of that has been split into multiple
 different sets of patches, on which this series depends. Previous discussion
 that influenced there changes can be found here [1]. This series depends on
 generic sram exec mapping patch here [2], emif series here [3],
 and wkup_m3_ipc series here [4]. I have pushed a branch containing the 
 patches
 from ALL required series here [5] for testing or a view of the high level
 flow of the entire series.

 The largest change with this revision is the introduction of a
 wkup_m3_ipc driver which handles all communication with the Cortex M3
 present on am335x for handling low power tasks. Previously this was
 handled in the wkup_m3_rproc driver (also sent in an earlier series)
 but that driver is now only responsible for booting the wkup_m3. The
 wkup_m3_ipc driver exposes an API with all required PM functionality
 needed by the PM code introduced by this series, so the PM code has
 shrunk considerably.

 Another major change is that the EMIF code previously present in the
 sleep33xx asm code and pm33xx code for save and restore of EMIF context
 and entry into low power mode has all been moved in to a separate EMIF
 driver, further reducing the size of the PM code. Because of this, moving
 the emif header defines into include/linux/ti_emif.h is no longer necessary.

 Other changes include clean up of the timer suspend/resume handlers, now
 look up hwmod in init and use that handle along with renaming to
 *_idle/*_unidle to avoid confusion with true suspend handlers. 

 Suspend support requires:
 CONFIG_TI_EMIF_SRAM
 CONFIG_WKUP_M3_RPROC
 CONFIG_WKUP_M3_IPC

 And also requires AM335x USB support to be enabled to work for multiple
 cycles. If you want to load firmware from rootfs in /lib/firmware you now
 must also select CONFIG_FW_LOADER_USER_HELPER_FALLBACK.

 This code works with version 0x189 of the CM3 firmware found here [6] on
 the next branch, /bin/am335x-pm-firmware.elf.
 
 Dave, does this series have dependencies to the other patches? Can some
 parts of this already be applied without breaking anything?
 

The only patch with no dependencies is patch 1 (ARM: OMAP2+: timer: Add
suspend-resume callbacks for clkevent device). It's ready to be applied, I just
applied to v3.19-rc5 and built and booted on am335x-evm with no issue just to be
sure. It won't actually do anything until suspend is completely implemented.

Regards,
Dave

 Regards,
 
 Tony
  
 [1] http://www.spinics.net/lists/linux-omap/msg109331.html
 [2] http://www.spinics.net/linux/lists/kernel/msg1876629.html
 [3] http://www.spinics.net/linux/lists/kernel/msg1876646.html
 [4] http://www.spinics.net/linux/lists/kernel/msg1876642.html
 [5] https://github.com/dgerlach/linux-pm/tree/rfc-pm-am335x-v3.18-rc6
 [6] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next

 Dave Gerlach (3):
   ARM: OMAP2+: AM33XX: Add assembly code for PM operations
   ARM: OMAP2+: AM33XX: Basic suspend resume support
   ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds

 Vaibhav Bedia (1):
   ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device

  arch/arm/boot/dts/am33xx.dtsi   |   2 +
  arch/arm/mach-omap2/Makefile|   2 +
  arch/arm/mach-omap2/common.h|   9 ++
  arch/arm/mach-omap2/io.c|   1 +
  arch/arm/mach-omap2/pm.h|   6 +
  arch/arm/mach-omap2/pm33xx.c| 250 
 
  arch/arm/mach-omap2/sleep33xx.S | 216 ++
  arch/arm/mach-omap2/timer.c |  28 +
  8 files changed, 514 insertions(+)
  create mode 100644 arch/arm/mach-omap2/pm33xx.c
  create mode 100644 arch/arm/mach-omap2/sleep33xx.S

 -- 
 2.1.0


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] soc: ti: Add wkup_m3_ipc driver

[Dave Gerlach]

Felipe,
On 01/02/2015 02:16 PM, Felipe Balbi wrote:
 On Fri, Jan 02, 2015 at 02:00:16PM -0600, Dave Gerlach wrote:
 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-gerl...@ti.com
 ---
  drivers/soc/ti/Kconfig   |  11 ++
  drivers/soc/ti/Makefile  |   1 +
  drivers/soc/ti/wkup_m3_ipc.c | 451 
 +++
  include/linux/wkup_m3_ipc.h  |  33 
  4 files changed, 496 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..61cda85 100644
 --- a/drivers/soc/ti/Kconfig
 +++ b/drivers/soc/ti/Kconfig
 @@ -28,4 +28,15 @@ config KEYSTONE_NAVIGATOR_DMA
  
If unsure, say N.
  
 +config WKUP_M3_IPC
 +bool TI AM33XX Wkup-M3 IPC Driver
 
 tristate ?

If we want to allow this and the rproc driver to be built as modules than we can
change this.

 
 +depends on WKUP_M3_RPROC
 +select MAILBOX
 +select OMAP2PLUS_MBOX
 
 selects are usually frowned upon.

Followed example set by OMAP_REMOTEPROC which selects the mailbox, thought that
would be alright.

 
 +help
 +  TI AM33XX has a Cortex M3 to handle low power transitions. This IPC
 +  driver provides the necessary API to communicate and use the wkup m3
 +  for PM features like Suspend/Resume and boots the wkup_m3 using
 +  wkup_m3_rproc driver.
 +
  endif # SOC_TI
 diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
 index 6bed611..b6b8c8b 100644
 --- a/drivers/soc/ti/Makefile
 +++ b/drivers/soc/ti/Makefile
 @@ -3,3 +3,4 @@
  #
  obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS)   += 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 000..4dcf748
 --- /dev/null
 +++ b/drivers/soc/ti/wkup_m3_ipc.c
 @@ -0,0 +1,451 @@
 +/*
 + * AMx3 Wkup M3 IPC driver
 + *
 + * Copyright (C) 2014 Texas Instruments, Inc.
 + *
 + * Dave Gerlach d-gerl...@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/mailbox_client.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_RESET   0xe
 +#define DS_IPC_DEFAULT  0x
 +#define M3_VERSION_UNKNOWN  0x
 +#define M3_BASELINE_VERSION 0x187
 +#define M3_STATUS_RESP_MASK (0x  16)
 +#define M3_FW_VERSION_MASK  0x
 +
 +#define M3_STATE_UNKNOWN0
 +#define M3_STATE_RESET  1
 +#define M3_STATE_INITED 2
 +#define M3_STATE_MSG_FOR_LP 3
 +#define M3_STATE_MSG_FOR_RESET  4
 +
 +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 mbox_client mbox_client;
 +struct mbox_chan *mbox;
 +};
 +
 +static struct wkup_m3_ipc m3_ipc_state;
 +
 +static DECLARE_COMPLETION(m3_ipc_sync);
 
 either move this inside struct wkup_m3_ipc or make this
 DECLARE_COMPLETION_ONSTACK();

There is no reason this can't be in the struct, I will move it.

 
 +
 +static inline void am33xx_txev_eoi(struct wkup_m3_ipc *m3_ipc)
 +{
 +writel

Re: [PATCH 3/3] remoteproc: wkup_m3: Add wkup_m3 remote proc driver

[Dave Gerlach]

Felipe,
On 01/02/2015 02:04 PM, Felipe Balbi wrote:
 On Fri, Jan 02, 2015 at 01:51:59PM -0600, Dave Gerlach wrote:
 Add a remoteproc driver to load the firmware for and boot the wkup_m3
 present on am33xx. The wkup_m3 is an integrated Cortex M3 that allows
 the SoC to enter the lowest possible power state by taking control from
 the MPU after it has gone into its own low power state and shutting off
 any additional peripherals.

 The driver expects a resource table to be present in the wkup_m3
 firmware to define the required memory resources needed by the wkup_m3,
 at least the data memory so that the firmware can be copied to the proper
 place for execution.

 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 ---
  drivers/remoteproc/Kconfig |  12 +++
  drivers/remoteproc/Makefile|   1 +
  drivers/remoteproc/wkup_m3_rproc.c | 175 
 +
  3 files changed, 188 insertions(+)
  create mode 100644 drivers/remoteproc/wkup_m3_rproc.c

 diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
 index 5e343ba..7fbdb53 100644
 --- a/drivers/remoteproc/Kconfig
 +++ b/drivers/remoteproc/Kconfig
 @@ -41,6 +41,18 @@ config STE_MODEM_RPROC
This can be either built-in or a loadable module.
If unsure say N.
  
 +config WKUP_M3_RPROC
 +bool AM33xx wkup-m3 remoteproc support
 
 it would be nicer if this could be a loadable module.

Do we really want that though? This is required for core PM functionality like
CPUIdle and Suspend/resume, I feel that it should always be built in for am335x.
I had been taking this approach with all of the PM dependencies.

 
 +depends on SOC_AM33XX
 +select REMOTEPROC
 +help
 +  Say y here to support AM33xx wkup-m3.
 +
 +  Required for Suspend-to-ram and CPUIdle on AM33xx. Allows for
 +  loading of firmware of CM3 PM coprocessor that is present
 +  on AM33xx family of SoCs
 +  If unsure say N.
 +
  config DA8XX_REMOTEPROC
  tristate DA8xx/OMAP-L13x remoteproc support
  depends on ARCH_DAVINCI_DA8XX
 diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
 index ac2ff75..81b04d1 100644
 --- a/drivers/remoteproc/Makefile
 +++ b/drivers/remoteproc/Makefile
 @@ -9,4 +9,5 @@ remoteproc-y += remoteproc_virtio.o
  remoteproc-y+= remoteproc_elf_loader.o
  obj-$(CONFIG_OMAP_REMOTEPROC)   += omap_remoteproc.o
  obj-$(CONFIG_STE_MODEM_RPROC)   += ste_modem_rproc.o
 +obj-$(CONFIG_WKUP_M3_RPROC) += wkup_m3_rproc.o
  obj-$(CONFIG_DA8XX_REMOTEPROC)  += da8xx_remoteproc.o
 diff --git a/drivers/remoteproc/wkup_m3_rproc.c 
 b/drivers/remoteproc/wkup_m3_rproc.c
 new file mode 100644
 index 000..8686ca2
 --- /dev/null
 +++ b/drivers/remoteproc/wkup_m3_rproc.c
 @@ -0,0 +1,175 @@
 +/*
 + * AMx3 Wkup M3 Remote Processor driver
 + *
 + * Copyright (C) 2014 Texas Instruments, Inc.
 + *
 + * Dave Gerlach d-gerl...@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/interrupt.h
 +#include linux/module.h
 +#include linux/of_device.h
 +#include linux/platform_device.h
 +#include linux/pm_runtime.h
 +#include linux/remoteproc.h
 +
 +#include linux/platform_data/wkup_m3.h
 +
 +#include remoteproc_internal.h
 +
 +struct wkup_m3_rproc {
 +struct rproc *rproc;
 +struct platform_device *pdev;
 +};
 +
 +static int wkup_m3_rproc_start(struct rproc *rproc)
 +{
 +struct wkup_m3_rproc *m3_rproc = rproc-priv;
 +struct platform_device *pdev = m3_rproc-pdev;
 +struct device *dev = pdev-dev;
 +struct wkup_m3_platform_data *pdata = dev-platform_data;
 +int ret;
 +
 +ret = pdata-deassert_reset(pdev, pdata-reset_name);
 
 looks like here you should assert, wait, deassert. What if soemthing
 else used wkup_m3 before this loads ?
 

Hmm, that's unlikely but not impossible, and if the wkup_m3 is not properly
reset after firmware loading it won't boot, which kills all PM on am335x. I'll
look into doing that.

 +if (ret) {
 +dev_err(dev, Unable to reset wkup_m3!\n);
 +return -ENODEV;
 +}
 +
 +return 0;
 +}
 +
 +static int wkup_m3_rproc_stop(struct rproc *rproc)
 +{
 +struct wkup_m3_rproc *m3_rproc = rproc-priv;
 +struct platform_device *pdev = m3_rproc-pdev;
 +struct device *dev = pdev-dev;
 +struct wkup_m3_platform_data *pdata = dev-platform_data;
 +int ret;
 +
 +ret = pdata-assert_reset(pdev, pdata-reset_name);
 +if (ret

[PATCH 2/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-gerl...@ti.com
---
 drivers/soc/ti/Kconfig   |  11 ++
 drivers/soc/ti/Makefile  |   1 +
 drivers/soc/ti/wkup_m3_ipc.c | 451 +++
 include/linux/wkup_m3_ipc.h  |  33 
 4 files changed, 496 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..61cda85 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -28,4 +28,15 @@ config KEYSTONE_NAVIGATOR_DMA
 
  If unsure, say N.
 
+config WKUP_M3_IPC
+   bool TI AM33XX Wkup-M3 IPC Driver
+   depends on WKUP_M3_RPROC
+   select MAILBOX
+   select OMAP2PLUS_MBOX
+   help
+ TI AM33XX has a Cortex M3 to handle low power transitions. This IPC
+ driver provides the necessary API to communicate and use the wkup m3
+ for PM features like Suspend/Resume and boots the wkup_m3 using
+ wkup_m3_rproc driver.
+
 endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 6bed611..b6b8c8b 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -3,3 +3,4 @@
 #
 obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS)  += 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 000..4dcf748
--- /dev/null
+++ b/drivers/soc/ti/wkup_m3_ipc.c
@@ -0,0 +1,451 @@
+/*
+ * AMx3 Wkup M3 IPC driver
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@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/mailbox_client.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_DS00x4
+#define IPC_CMD_STANDBY0xc
+#define IPC_CMD_RESET  0xe
+#define DS_IPC_DEFAULT 0x
+#define M3_VERSION_UNKNOWN 0x
+#define M3_BASELINE_VERSION0x187
+#define M3_STATUS_RESP_MASK(0x  16)
+#define M3_FW_VERSION_MASK 0x
+
+#define M3_STATE_UNKNOWN   0
+#define M3_STATE_RESET 1
+#define M3_STATE_INITED2
+#define M3_STATE_MSG_FOR_LP3
+#define M3_STATE_MSG_FOR_RESET 4
+
+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 mbox_client mbox_client;
+   struct mbox_chan *mbox;
+};
+
+static struct wkup_m3_ipc m3_ipc_state;
+
+static DECLARE_COMPLETION(m3_ipc_sync);
+
+static inline 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 inline 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 inline void wkup_m3_ctrl_ipc_write(struct wkup_m3_ipc *m3_ipc,
+ u32 val, int ipc_reg_num)
+{
+   if (ipc_reg_num  0 || ipc_reg_num  AM33XX_CTRL_IPC_REG_COUNT)
+   return;
+
+   writel(val, m3_ipc-ipc_mem_base +
+  AM33XX_CTRL_IPC_REG_OFFSET(ipc_reg_num

[PATCH 3/3] remoteproc: wkup_m3: Add wkup_m3 remote proc driver

[Dave Gerlach]

Add a remoteproc driver to load the firmware for and boot the wkup_m3
present on am33xx. The wkup_m3 is an integrated Cortex M3 that allows
the SoC to enter the lowest possible power state by taking control from
the MPU after it has gone into its own low power state and shutting off
any additional peripherals.

The driver expects a resource table to be present in the wkup_m3
firmware to define the required memory resources needed by the wkup_m3,
at least the data memory so that the firmware can be copied to the proper
place for execution.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 drivers/remoteproc/Kconfig |  12 +++
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/wkup_m3_rproc.c | 175 +
 3 files changed, 188 insertions(+)
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 5e343ba..7fbdb53 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -41,6 +41,18 @@ config STE_MODEM_RPROC
  This can be either built-in or a loadable module.
  If unsure say N.
 
+config WKUP_M3_RPROC
+   bool AM33xx wkup-m3 remoteproc support
+   depends on SOC_AM33XX
+   select REMOTEPROC
+   help
+ Say y here to support AM33xx wkup-m3.
+
+ Required for Suspend-to-ram and CPUIdle on AM33xx. Allows for
+ loading of firmware of CM3 PM coprocessor that is present
+ on AM33xx family of SoCs
+ If unsure say N.
+
 config DA8XX_REMOTEPROC
tristate DA8xx/OMAP-L13x remoteproc support
depends on ARCH_DAVINCI_DA8XX
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ac2ff75..81b04d1 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -9,4 +9,5 @@ remoteproc-y+= remoteproc_virtio.o
 remoteproc-y   += remoteproc_elf_loader.o
 obj-$(CONFIG_OMAP_REMOTEPROC)  += omap_remoteproc.o
 obj-$(CONFIG_STE_MODEM_RPROC)  += ste_modem_rproc.o
+obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/wkup_m3_rproc.c 
b/drivers/remoteproc/wkup_m3_rproc.c
new file mode 100644
index 000..8686ca2
--- /dev/null
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -0,0 +1,175 @@
+/*
+ * AMx3 Wkup M3 Remote Processor driver
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@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/interrupt.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/remoteproc.h
+
+#include linux/platform_data/wkup_m3.h
+
+#include remoteproc_internal.h
+
+struct wkup_m3_rproc {
+   struct rproc *rproc;
+   struct platform_device *pdev;
+};
+
+static int wkup_m3_rproc_start(struct rproc *rproc)
+{
+   struct wkup_m3_rproc *m3_rproc = rproc-priv;
+   struct platform_device *pdev = m3_rproc-pdev;
+   struct device *dev = pdev-dev;
+   struct wkup_m3_platform_data *pdata = dev-platform_data;
+   int ret;
+
+   ret = pdata-deassert_reset(pdev, pdata-reset_name);
+   if (ret) {
+   dev_err(dev, Unable to reset wkup_m3!\n);
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
+static int wkup_m3_rproc_stop(struct rproc *rproc)
+{
+   struct wkup_m3_rproc *m3_rproc = rproc-priv;
+   struct platform_device *pdev = m3_rproc-pdev;
+   struct device *dev = pdev-dev;
+   struct wkup_m3_platform_data *pdata = dev-platform_data;
+   int ret;
+
+   ret = pdata-assert_reset(pdev, pdata-reset_name);
+   if (ret) {
+   dev_err(dev, Unable to assert reset of wkup_m3!\n);
+   return -ENODEV;
+   }
+   return 0;
+}
+
+static struct rproc_ops wkup_m3_rproc_ops = {
+   .start  = wkup_m3_rproc_start,
+   .stop   = wkup_m3_rproc_stop,
+};
+
+static const struct of_device_id wkup_m3_rproc_of_match[] = {
+   {
+   .compatible = ti,am3353-wkup-m3,
+   .data = (void *)am335x-pm-firmware.elf,
+   },
+   {},
+};
+
+static int wkup_m3_rproc_probe(struct platform_device *pdev)
+{
+   struct device *dev = pdev-dev;
+   const char *fw_name;
+   struct wkup_m3_platform_data *pdata = dev-platform_data;
+   struct wkup_m3_rproc *m3_rproc;
+   const

[PATCH] remoteproc: Introduce rproc_get_by_phandle API

[Dave Gerlach]

Allow users of remoteproc the ability to get a handle to an rproc by
passing a phandle supplied in the user's device tree node. This is
useful in situations that require manual booting of the rproc.

This patch uses the code removed by commit 40e575b1d0b3 (remoteproc:
remove the get_by_name/put API) for the ref counting a rproc klist
code but has rproc_get_by_name replaced with an rproc_get_by_phandle API.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 Documentation/remoteproc.txt |  6 +++
 drivers/remoteproc/remoteproc_core.c | 85 
 include/linux/remoteproc.h   |  1 +
 3 files changed, 92 insertions(+)

diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index e6469fd..81b5240 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -51,6 +51,12 @@ cost.
 rproc_shutdown() returns, and users can still use it with a subsequent
 rproc_boot(), if needed.
 
+  struct rproc *rproc_get_by_phandle(const char *name)
+- Find an rproc handle using a device tree phandle. Returns the rproc
+  handle on success, and NULL on failure. This function increments
+  the remote processor's refcount, so always use rproc_put() to
+  decrement it back once rproc isn't needed anymore.
+
 3. Typical usage
 
 #include linux/remoteproc.h
diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index e2bd869..6b78ba4 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -27,6 +27,7 @@
 #include linux/kernel.h
 #include linux/module.h
 #include linux/device.h
+#include linux/of.h
 #include linux/slab.h
 #include linux/mutex.h
 #include linux/dma-mapping.h
@@ -36,6 +37,7 @@
 #include linux/remoteproc.h
 #include linux/iommu.h
 #include linux/idr.h
+#include linux/klist.h
 #include linux/elf.h
 #include linux/crc32.h
 #include linux/virtio_ids.h
@@ -44,6 +46,17 @@
 
 #include remoteproc_internal.h
 
+static void klist_rproc_get(struct klist_node *n);
+static void klist_rproc_put(struct klist_node *n);
+
+/*
+ * klist of the available remote processors.
+ *
+ * We need this in order to support rproc lookups (needed by the
+ * rproc_get_by_phandle()).
+ */
+static DEFINE_KLIST(rprocs, klist_rproc_get, klist_rproc_put);
+
 typedef int (*rproc_handle_resources_t)(struct rproc *rproc,
struct resource_table *table, int len);
 typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
@@ -1234,6 +1247,72 @@ out:
 }
 EXPORT_SYMBOL(rproc_shutdown);
 
+/* will be called when an rproc is added to the rprocs klist */
+static void klist_rproc_get(struct klist_node *n)
+{
+   struct rproc *rproc = container_of(n, struct rproc, node);
+
+   get_device(rproc-dev);
+}
+
+/* will be called when an rproc is removed from the rprocs klist */
+static void klist_rproc_put(struct klist_node *n)
+{
+   struct rproc *rproc = container_of(n, struct rproc, node);
+
+   put_device(rproc-dev);
+}
+
+static struct rproc *next_rproc(struct klist_iter *i)
+{
+   struct klist_node *n;
+
+   n = klist_next(i);
+   if (!n)
+   return NULL;
+
+   return container_of(n, struct rproc, node);
+}
+
+/**
+ * rproc_get_by_phandle() - find a remote processor by phandle and boot it
+ * @phandle: phandle to the rproc
+ *
+ * Finds an rproc handle using the remote processor's phandle, and then
+ * boot it. If it's already powered on, then just immediately return
+ * (successfully).
+ *
+ * Returns the rproc handle on success, and NULL on failure.
+ *
+ * This function increments the remote processor's refcount, so always
+ * use rproc_put() to decrement it back once rproc isn't needed anymore.
+ *
+ * Note: currently this function (and its counterpart rproc_put()) are not
+ * being used. We need to scrutinize the use cases
+ * that still need them, and see if we can migrate them to use the non
+ * name-based boot/shutdown interface.
+ */
+struct rproc *rproc_get_by_phandle(uint32_t phandle)
+{
+   struct rproc *rproc;
+   struct klist_iter i;
+   struct device_node *np;
+
+   np = of_find_node_by_phandle(phandle);
+
+   /* find the remote processor, and upref its refcount */
+   klist_iter_init(rprocs, i);
+   while ((rproc = next_rproc(i)) != NULL)
+   if (rproc-dev.parent  rproc-dev.parent-of_node == np) {
+   get_device(rproc-dev);
+   break;
+   }
+   klist_iter_exit(i);
+
+   return rproc;
+}
+EXPORT_SYMBOL(rproc_get_by_phandle);
+
 /**
  * rproc_add() - register a remote processor
  * @rproc: the remote processor handle to register
@@ -1263,6 +1342,9 @@ int rproc_add(struct rproc *rproc)
if (ret  0)
return ret;
 
+   /* expose to rproc_get_by_phandle users */
+   klist_add_tail(rproc-node, rprocs);
+
dev_info(dev, %s is available\n, rproc-name

[PATCH 3/3] ARM: dts: am33xx: Add wkup_m3_ipc node

[Dave Gerlach]

Add wkup_m3_ipc node for wkup_m3_ipc driver.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index acd3705..1ebb230 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -863,6 +863,15 @@
reg = 0x4831 0x2000;
interrupts = 111;
};
+
+   wkup_m3_ipc: wkup_m3_ipc@44e11324 {
+   compatible = ti,am3353-wkup-m3-ipc;
+   reg = 0x44e11324 0x0024;
+   reg-names = ipc_regs;
+   interrupts = 78;
+   ti,rproc = wkup_m3;
+   mboxes = mailbox mbox_wkupm3;
+   };
};
 };
 
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] Documentation: dt: add ti,am3353-wkup-m3-ipc bindings

[Dave Gerlach]

Add the device tree bindings document for ti,am3353-wkup-m3-ipc which
is used by the wkup_m3_ipc driver.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt | 41 ++
 1 file changed, 41 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 000..ceb6acf
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
@@ -0,0 +1,41 @@
+Wakeup M3 IPC Driver
+=
+
+TI AMx3 family of devices use a Cortex M3 co-processor 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 a wakeup M3 IP instance within
+an SoC. The sub-mailboxes are represented as child node of this parent node.
+
+Required properties:
+
+- compatible:  Should be ti,am3353-wkup-m3-ipc for AM33xx SoCs
+- reg: Contains the wkup_m3 register address ranges for
+   ipc-regs.
+- reg-names:   Name for ipc-regs given above
+- 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 */
+wkup_m3_ipc: wkup_m3_ipc@44e11324 {
+   compatible = ti,am3353-wkup-m3-ipc;
+   reg = 0x44e11324 0x0024;
+   reg-names = ipc_regs;
+   interrupts = 78;
+   ti,rproc = wkup_m3;
+   mboxes = mailbox mbox_wkupm3;
+};
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dave Gerlach]

This series introduces a wkup_m3_ipc driver to handle communication
between the MPU and Cortex M3 present on TI AM335x SoCs. This is
required for much of the PM functionality for AM335x including suspend
support. This was split off from v4 of the am335x suspend series,
discussion that led to the implementation of this driver can be found
with the series here [1].  A previous RFC version of this series can be
found here [2]. The changes from that version are as follows:
 - Remove wake source reporting as it is unnecessary.
 - Use newly introduced rproc_get_by_phandle API to get rproc for
   booting [3].

This series depends on the patch remoteproc: Introduce
rproc_get_by_phandle API [3] and the wkup_m3_rproc series found
here [4]. A branch based on 3.19-rc1 containing this series and
all dependencies for the AM33xx suspend series can be found
here [5] for a high level view of what I am using this for.

A small API is exposed to allow the SoC PM code to execute the
specific tasks it needs to in order to enter and exit low power
modes. Communication works the same as it did in the past using the
IPC registers found within the control module, a mailbox module, and
an interrupt coming back from the CM3. All of that, including the
configurations needed for different low power tasks is encapsulated
within this driver.

Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg109331.html
[2] http://www.spinics.net/lists/linux-omap/msg113372.html
[3] http://marc.info/?l=linux-kernelm=142022798923784w=2
[4] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg795457.html
[5] https://github.com/dgerlach/linux-pm/tree/pm-am335x-v3.19-rc1

Dave Gerlach (3):
  Documentation: dt: add ti,am3353-wkup-m3-ipc bindings
  soc: ti: Add wkup_m3_ipc driver
  ARM: dts: am33xx: Add wkup_m3_ipc node

 .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt |  41 ++
 arch/arm/boot/dts/am33xx.dtsi  |   9 +
 drivers/soc/ti/Kconfig |  11 +
 drivers/soc/ti/Makefile|   1 +
 drivers/soc/ti/wkup_m3_ipc.c   | 451 +
 include/linux/wkup_m3_ipc.h|  33 ++
 6 files changed, 546 insertions(+)
 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.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset

[Dave Gerlach]

Use pdata-quirks to provide platform data required for reset
of the wkup_m3 during boot.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/mach-omap2/pdata-quirks.c| 13 +
 include/linux/platform_data/wkup_m3.h | 23 +++
 2 files changed, 36 insertions(+)
 create mode 100644 include/linux/platform_data/wkup_m3.h

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d7eee1..b0c5916 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -18,6 +18,7 @@
 
 #include linux/platform_data/pinctrl-single.h
 #include linux/platform_data/iommu-omap.h
+#include linux/platform_data/wkup_m3.h
 
 #include am35xx.h
 #include common.h
@@ -288,6 +289,14 @@ static void __init omap3_tao3530_legacy_init(void)
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
+#ifdef CONFIG_SOC_AM33XX
+static struct wkup_m3_platform_data wkup_m3_data = {
+   .reset_name = wkup_m3,
+   .assert_reset = omap_device_assert_hardreset,
+   .deassert_reset = omap_device_deassert_hardreset,
+};
+#endif
+
 #ifdef CONFIG_ARCH_OMAP4
 static void __init omap4_sdp_legacy_init(void)
 {
@@ -383,6 +392,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
   am35xx_emac_pdata),
 #endif
+#ifdef CONFIG_SOC_AM33XX
+   OF_DEV_AUXDATA(ti,am3353-wkup-m3, 0x44d0, 44d0.wkup_m3,
+  wkup_m3_data),
+#endif
 #ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux, 
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux, 
pcs_pdata),
diff --git a/include/linux/platform_data/wkup_m3.h 
b/include/linux/platform_data/wkup_m3.h
new file mode 100644
index 000..6ee33d7
--- /dev/null
+++ b/include/linux/platform_data/wkup_m3.h
@@ -0,0 +1,23 @@
+/*
+ * omap wkup_m3: platform data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@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.
+ */
+
+#ifndef _LINUX_PLATFORM_DATA_WKUP_M3_H
+#define _LINUX_PLATFORM_DATA_WKUP_M3_H
+
+struct wkup_m3_platform_data {
+   const char *reset_name;
+
+   int (*assert_reset)(struct platform_device *pdev, const char *name);
+   int (*deassert_reset)(struct platform_device *pdev, const char *name);
+};
+
+#endif /* _LINUX_PLATFORM_DATA_WKUP_M3_H */
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] remoteproc: Introduce wkup_m3_rproc driver

[Dave Gerlach]

Hi,
This patch series adds a wkup_m3_rproc driver for TI AM335x SoCs.
This family of SoCs contains an ARM Cortex M3 coprocessor that is
responsible for low-level power tasks that cannot be handled by
the main ARM Cortex A8 so firmware running from the CM3 can be
used instead. This driver handles loading of the firmware and
reset of the CM3 once it is booted.

This patch was split off from v4 of the am335x suspend series,
found here [1]. I have pushed a branch based on v3.19-rc1
containing all dependencies here [2] for am33xx suspend
for a higher level view of the entire series of patch sets. This
series is required for a coming series drivers: soc: ti:
Introduce wkup_m3_ipc driver that boots this rproc driver and
handles the communication layer between the SoC and this remote
processor.

This patch set depends on series couple of generic remoteproc
enhancements by Suman Anna found here [3]. The driver expects to
load firmware am335x-pm-firmware.elf from /lib/firmware which is
found here [4].

Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg109331.html
[2] https://github.com/dgerlach/linux-pm/tree/pm-am335x-v3.19-rc1
[3] http://www.spinics.net/lists/arm-kernel/msg362961.html
[4] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next


Dave Gerlach (3):
  ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset
  Documentation: dt: add ti,am3353-wkup-m3 bindings
  remoteproc: wkup_m3: Add wkup_m3 remote proc driver

 .../bindings/remoteproc/wkup_m3_rproc.txt  |  32 
 arch/arm/mach-omap2/pdata-quirks.c |  13 ++
 drivers/remoteproc/Kconfig |  12 ++
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/wkup_m3_rproc.c | 175 +
 include/linux/platform_data/wkup_m3.h  |  23 +++
 6 files changed, 256 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
 create mode 100644 include/linux/platform_data/wkup_m3.h

-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] Documentation: dt: add ti,am3353-wkup-m3 bindings

[Dave Gerlach]

Add the device tree bindings document for ti,am3353-wkup-m3 which is
used by the wkup_m3_rproc driver.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 .../bindings/remoteproc/wkup_m3_rproc.txt  | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt 
b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
new file mode 100644
index 000..4d64a23
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
@@ -0,0 +1,32 @@
+Wakeup M3 Remote Proc Driver
+=
+
+TI AMx3 family of devices use a Cortex M3 co-processor to help with various
+low power tasks that cannot be controlled from the MPU. The CM3 requires
+a firmware binary to accomplish this. The wkup_m3 remoteproc driver handles
+the loading of the firmware and booting of the CM3.
+
+Wkup M3 Device Node:
+
+A wkup_m3 device node is used to represent a wakeup M3 IP instance within
+a SoC.
+
+Required properties:
+
+- compatible:  Should be ti,am3353-wkup-m3 for AM33xx SoCs
+- reg: Contains the wkup_m3 register address ranges for
+   umem and dmem.
+- ti,hwmods:   Name of the hwmod associated with the mailbox
+- ti,no-reset-on-init: Reset is handled after fw has been loaded, not at
+   init of hwmod.
+
+Example:
+
+/* AM33xx */
+wkup_m3: wkup_m3@44d0 {
+   compatible = ti,am3353-wkup-m3;
+   reg = 0x44d0 0x4000/* M3 UMEM */
+  0x44d8 0x2000;  /* M3 DMEM */
+   ti,hwmods = wkup_m3;
+   ti,no-reset-on-init;
+};
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/3] soc: ti: Add wkup_m3_ipc driver

[Dave Gerlach]

On 11/26/2014 03:51 PM, Arnd Bergmann wrote:
 On Wednesday 26 November 2014 15:38:09 Dave Gerlach wrote:
 +
 +static const struct wkup_m3_wakeup_src wakeups[] = {
 +   {.irq_nr = 35,  .src = USB0_PHY},
 +   {.irq_nr = 36,  .src = USB1_PHY},
 +   {.irq_nr = 40,  .src = I2C0},
 +   {.irq_nr = 41,  .src = RTC Timer},
 +   {.irq_nr = 42,  .src = RTC Alarm},
 +   {.irq_nr = 43,  .src = Timer0},
 +   {.irq_nr = 44,  .src = Timer1},
 +   {.irq_nr = 45,  .src = UART},
 +   {.irq_nr = 46,  .src = GPIO0},
 +   {.irq_nr = 48,  .src = MPU_WAKE},
 +   {.irq_nr = 49,  .src = WDT0},
 +   {.irq_nr = 50,  .src = WDT1},
 +   {.irq_nr = 51,  .src = ADC_TSC},
 +   {.irq_nr = 0,   .src = Unknown},
 +};

 
 This seems awfully specific to some SoC version, and not aware of
 IRQ domains. It also seems to be only used in a dev_dbg statement,
 so I guess you could just kill this off entirely.

This is determined by the firmware in use on the remote processor and works for
both am335x and am437x. However it is not required information and I'd be fine
with taking it out.

 
 +static struct rproc *wkup_m3_get_rproc(struct device *dev)
 +{
 +   struct device_node *node;
 +   struct rproc *rp;
 +
 +   node = of_parse_phandle(dev-of_node, ti,rproc, 0);
 +   if (!node)
 +   return NULL;
 +
 +   dev = bus_find_device(platform_bus_type, NULL, node, match);
 +   if (!dev)
 +   return NULL;
 +
 +   rp = dev_get_drvdata(dev);
 +   return rp;
 
 This is wrong on a number of levels. I suspect what you really want
 is an interface exported from drivers/remoteproc that looks up
 a 'struct rproc' and performs the necessary reference counting.
 
 That one can just use of_find_node_by_phandle() to get to
 a device_node and use that to look up the rproc device in
 a linked list it maintains.

Added Ohad as I should have cc'd him in the first place..

Yes I agree that it's not the best solution. There used to be an
rproc_get/rproc_put api but that was removed, I'll look into adding
rproc_get_by_phandle into drivers/remoteproc as that would be ideal for this
situation and a cleaner way of doing it. Thanks for the comments.

Regards,
Dave

 
   Arnd
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 2/2] lib: devres: Add exec versions of devm_ioremap_resource and friends

[Dave Gerlach]

From: Russ Dill russ.d...@ti.com

Now that there is an _exec version of ioremap, add devm support for it.

Signed-off-by: Russ Dill russ.d...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 include/linux/device.h |  19 +++-
 include/linux/io.h |   9 +++-
 lib/devres.c   | 125 +++--
 3 files changed, 147 insertions(+), 6 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index ce1f2160..d336465 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -635,7 +635,24 @@ extern unsigned long devm_get_free_pages(struct device 
*dev,
 gfp_t gfp_mask, unsigned int order);
 extern void devm_free_pages(struct device *dev, unsigned long addr);
 
-void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+void __iomem *__devm_ioremap_resource(struct device *dev, struct resource *res,
+ bool exec);
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+ struct resource *res)
+{
+   return __devm_ioremap_resource(dev, res, false);
+}
+void __iomem *devm_request_and_ioremap(struct device *dev,
+  struct resource *res);
+
+static inline void __iomem *devm_ioremap_exec_resource(struct device *dev,
+  struct resource *res)
+{
+   return __devm_ioremap_resource(dev, res, true);
+}
+
+void __iomem *devm_request_and_ioremap_exec(struct device *dev,
+   struct resource *res);
 
 /* allows to add/remove a custom action to devres stack */
 int devm_add_action(struct device *dev, void (*action)(void *), void *data);
diff --git a/include/linux/io.h b/include/linux/io.h
index d5fc9b8..0c6405a 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -61,9 +61,14 @@ static inline void devm_ioport_unmap(struct device *dev, 
void __iomem *addr)
 #define IOMEM_ERR_PTR(err) (__force void __iomem *)ERR_PTR(err)
 
 void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
-   unsigned long size);
+  unsigned long size);
 void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
-   unsigned long size);
+  unsigned long size);
+void __iomem *devm_ioremap_exec(struct device *dev, resource_size_t offset,
+   unsigned long size);
+void __iomem *devm_ioremap_exec_nocache(struct device *dev,
+   resource_size_t offset,
+   unsigned long size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
 int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index f4a195a..f5d0eac 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,64 @@ void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
 EXPORT_SYMBOL(devm_ioremap_nocache);
 
 /**
+ * devm_ioremap_exec - Managed ioremap_exec()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_exec().  Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_exec(struct device *dev, resource_size_t offset,
+   unsigned long size)
+{
+   void __iomem **ptr, *addr;
+
+   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return NULL;
+
+   addr = ioremap_exec(offset, size);
+   if (addr) {
+   *ptr = addr;
+   devres_add(dev, ptr);
+   } else
+   devres_free(ptr);
+
+   return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_exec);
+
+/**
+ * devm_ioremap_exec_nocache - Managed ioremap_exec_nocache()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_exec_nocache().  Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem *devm_ioremap_exec_nocache(struct device *dev,
+   resource_size_t offset,
+   unsigned long size)
+{
+   void __iomem **ptr, *addr;
+
+   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return NULL;
+
+   addr = ioremap_exec_nocache(offset, size);
+   if (addr) {
+   *ptr = addr;
+   devres_add(dev, ptr);
+   } else
+   devres_free(ptr);
+
+   return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_exec_nocache);
+
+/**
  * devm_iounmap - Managed iounmap()
  * @dev: Generic device to unmap for
  * @addr: Address to unmap

[RFC PATCH 0/2] Add ioremap_exec enhancements

[Dave Gerlach]

Hi,

Some platforms need the ability to ioremap memory for use with small
chunks of code, like in certain PM applications that run from sram.

This series provides a common way to call an arch's ioremap_exec, which
currently only exists for ARM, so that we can use it in the generic
sram driver in a forthcoming patch.

This patch is part of a patch series split into several smaller sets
for introducing suspend on AM335x. I plan to use it to copy several
pieces of ASM code from an EMIF driver and the SoC PM code to run from
SRAM on the SoC. I have pushed a branch here [1] based on v3.18-rc6
with all required patches so that the higher level plan for these
patches can be seen.

Regards,
Dave

[1] https://github.com/dgerlach/linux-pm/tree/rfc-pm-am335x-v3.18-rc6

Russ Dill (2):
  asm-generic: io: Add exec versions of ioremap
  lib: devres: Add exec versions of devm_ioremap_resource and friends

 arch/arm/include/asm/io.h   |   2 +
 include/asm-generic/iomap.h |   5 ++
 include/linux/device.h  |  19 ++-
 include/linux/io.h  |   9 +++-
 lib/devres.c| 125 ++--
 5 files changed, 154 insertions(+), 6 deletions(-)

-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 1/2] asm-generic: io: Add exec versions of ioremap

[Dave Gerlach]

From: Russ Dill russ.d...@ti.com

If code is to be copied into and area (such as SRAM) and run,
it needs to be marked as exec. Currently only an ARM version
of this exists.

Signed-off-by: Russ Dill russ.d...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/include/asm/io.h   | 2 ++
 include/asm-generic/iomap.h | 5 +
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 1805674..1d99d42 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -344,6 +344,8 @@ extern void _memset_io(volatile void __iomem *, int, 
size_t);
 #define ioremap_nocache(cookie,size)   __arm_ioremap((cookie), (size), 
MT_DEVICE)
 #define ioremap_cache(cookie,size) __arm_ioremap((cookie), (size), 
MT_DEVICE_CACHED)
 #define ioremap_wc(cookie,size)__arm_ioremap((cookie), (size), 
MT_DEVICE_WC)
+#define ioremap_exec(cookie,size)  __arm_ioremap_exec((cookie), (size), 
true)
+#define ioremap_exec_nocache(cookie,size) __arm_ioremap_exec((cookie), (size), 
false)
 #define iounmap__arm_iounmap
 
 /*
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 1b41011..6648ff3 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -66,6 +66,11 @@ extern void ioport_unmap(void __iomem *);
 #define ioremap_wc ioremap_nocache
 #endif
 
+#ifndef ARCH_HAS_IOREMAP_EXEC
+#define ioremap_exec ioremap
+#define ioremap_exec_nocache ioremap_nocache
+#endif
+
 #ifdef CONFIG_PCI
 /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
 struct pci_dev;
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH] misc: SRAM: Add option to map SRAM to allow code execution

[Dave Gerlach]

From: Russ Dill russ.d...@ti.com

Allow option for mapping SRAM as executable. This is useful for
platforms using the sram driver that need to run PM code from sram
like several ARM platforms.

Signed-off-by: Russ Dill russ.d...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
This patch depends on the series here [1] and can be seen in context
as a dependency for am335x suspend in this branch based on v3.18-rc6
here [2].

[1] http://lkml.iu.edu/hypermail/linux/kernel/1411.3/02782.html
[2] https://github.com/dgerlach/linux-pm/tree/rfc-pm-am335x-v3.18-rc6

 Documentation/devicetree/bindings/misc/sram.txt |  1 +
 drivers/misc/sram.c | 13 -
 include/linux/platform_data/sram.h  |  8 
 3 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/platform_data/sram.h

diff --git a/Documentation/devicetree/bindings/misc/sram.txt 
b/Documentation/devicetree/bindings/misc/sram.txt
index 36cbe5a..c5ecde4 100644
--- a/Documentation/devicetree/bindings/misc/sram.txt
+++ b/Documentation/devicetree/bindings/misc/sram.txt
@@ -33,6 +33,7 @@ Optional properties in the area nodes:
 
 - compatible : standard definition, should contain a vendor specific string
in the form vendor,[device-]usage
+- map-exec :   Map range to allow code execution
 
 Example:
 
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 21181fa..f5822de 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -31,6 +31,7 @@
 #include linux/slab.h
 #include linux/spinlock.h
 #include linux/genalloc.h
+#include linux/platform_data/sram.h
 
 #define SRAM_GRANULARITY   32
 
@@ -56,6 +57,7 @@ static int sram_reserve_cmp(void *priv, struct list_head *a,
 
 static int sram_probe(struct platform_device *pdev)
 {
+   struct sram_platform_data *pdata = pdev-dev.platform_data;
void __iomem *virt_base;
struct sram_dev *sram;
struct resource *res;
@@ -64,12 +66,21 @@ static int sram_probe(struct platform_device *pdev)
struct sram_reserve *rblocks, *block;
struct list_head reserve_list;
unsigned int nblocks;
+   bool map_exec = false;
int ret;
 
INIT_LIST_HEAD(reserve_list);
 
+   if (of_get_property(pdev-dev.of_node, map-exec, NULL))
+   map_exec = true;
+   if (pdata  pdata-map_exec)
+   map_exec |= true;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   virt_base = devm_ioremap_resource(pdev-dev, res);
+   if (map_exec)
+   virt_base = devm_ioremap_exec_resource(pdev-dev, res);
+   else
+   virt_base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(virt_base))
return PTR_ERR(virt_base);
 
diff --git a/include/linux/platform_data/sram.h 
b/include/linux/platform_data/sram.h
new file mode 100644
index 000..8f5c4ba
--- /dev/null
+++ b/include/linux/platform_data/sram.h
@@ -0,0 +1,8 @@
+#ifndef _LINUX_SRAM_H
+#define _LINUX_SRAM_H
+
+struct sram_platform_data {
+   bool map_exec;
+};
+
+#endif
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 1/3] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset

[Dave Gerlach]

Use pdata-quirks to provide platform data required for reset
of the wkup_m3 during boot.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/mach-omap2/pdata-quirks.c| 13 +
 include/linux/platform_data/wkup_m3.h | 23 +++
 2 files changed, 36 insertions(+)
 create mode 100644 include/linux/platform_data/wkup_m3.h

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index cec9d6c..1c0bcdb 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -17,6 +17,7 @@
 
 #include linux/platform_data/pinctrl-single.h
 #include linux/platform_data/iommu-omap.h
+#include linux/platform_data/wkup_m3.h
 
 #include am35xx.h
 #include common.h
@@ -260,6 +261,14 @@ static void __init omap3_tao3530_legacy_init(void)
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
+#ifdef CONFIG_SOC_AM33XX
+static struct wkup_m3_platform_data wkup_m3_data = {
+   .reset_name = wkup_m3,
+   .assert_reset = omap_device_assert_hardreset,
+   .deassert_reset = omap_device_deassert_hardreset,
+};
+#endif
+
 #ifdef CONFIG_ARCH_OMAP4
 static void __init omap4_sdp_legacy_init(void)
 {
@@ -355,6 +364,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
   am35xx_emac_pdata),
 #endif
+#ifdef CONFIG_SOC_AM33XX
+   OF_DEV_AUXDATA(ti,am3353-wkup-m3, 0x44d0, 44d0.wkup_m3,
+  wkup_m3_data),
+#endif
 #ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux, 
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux, 
pcs_pdata),
diff --git a/include/linux/platform_data/wkup_m3.h 
b/include/linux/platform_data/wkup_m3.h
new file mode 100644
index 000..6ee33d7
--- /dev/null
+++ b/include/linux/platform_data/wkup_m3.h
@@ -0,0 +1,23 @@
+/*
+ * omap wkup_m3: platform data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@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.
+ */
+
+#ifndef _LINUX_PLATFORM_DATA_WKUP_M3_H
+#define _LINUX_PLATFORM_DATA_WKUP_M3_H
+
+struct wkup_m3_platform_data {
+   const char *reset_name;
+
+   int (*assert_reset)(struct platform_device *pdev, const char *name);
+   int (*deassert_reset)(struct platform_device *pdev, const char *name);
+};
+
+#endif /* _LINUX_PLATFORM_DATA_WKUP_M3_H */
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 2/3] Documentation: dt: add ti,am3353-wkup-m3 bindings

[Dave Gerlach]

Add the device tree bindings document for ti,am3353-wkup-m3 which is
used by the wkup_m3_rproc driver.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 .../bindings/remoteproc/wkup_m3_rproc.txt  | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt 
b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
new file mode 100644
index 000..4d64a23
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
@@ -0,0 +1,32 @@
+Wakeup M3 Remote Proc Driver
+=
+
+TI AMx3 family of devices use a Cortex M3 co-processor to help with various
+low power tasks that cannot be controlled from the MPU. The CM3 requires
+a firmware binary to accomplish this. The wkup_m3 remoteproc driver handles
+the loading of the firmware and booting of the CM3.
+
+Wkup M3 Device Node:
+
+A wkup_m3 device node is used to represent a wakeup M3 IP instance within
+a SoC.
+
+Required properties:
+
+- compatible:  Should be ti,am3353-wkup-m3 for AM33xx SoCs
+- reg: Contains the wkup_m3 register address ranges for
+   umem and dmem.
+- ti,hwmods:   Name of the hwmod associated with the mailbox
+- ti,no-reset-on-init: Reset is handled after fw has been loaded, not at
+   init of hwmod.
+
+Example:
+
+/* AM33xx */
+wkup_m3: wkup_m3@44d0 {
+   compatible = ti,am3353-wkup-m3;
+   reg = 0x44d0 0x4000/* M3 UMEM */
+  0x44d8 0x2000;  /* M3 DMEM */
+   ti,hwmods = wkup_m3;
+   ti,no-reset-on-init;
+};
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 0/3] remoteproc: Introduce wkup_m3_rproc driver

[Dave Gerlach]

Hi,
This patch series adds a wkup_m3_rproc driver for TI AM335x SoCs.
This family of SoCs contains an ARM Cortex M3 coprocessor that is
responsible for low-level power tasks that cannot be handled by the
main ARM Cortex A8 so firmware running from the CM3 can be used instead.
This driver handles loading of the firmware and reset of the CM3
once it is booted.

This patch was split off from v4 of the am335x suspend series, found
here [1]. Because of this it is a dependency for v5 of that series. I have
pushed a branch based on v3.18-rc6 containing all dependencies here [2] for
am33xx suspend for a higher level view of the entire series of patch sets.

This patch set depends on series couple of generic remoteproc enhancements
by Suman Anna found here [3] (Included already in previously mentioned branch)

Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg109331.html
[2] https://github.com/dgerlach/linux-pm/tree/rfc-pm-am335x-v3.18-rc6
[3] http://www.spinics.net/lists/arm-kernel/msg362961.html

Dave Gerlach (3):
  ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset
  Documentation: dt: add ti,am3353-wkup-m3 bindings
  remoteproc: wkup_m3: Add wkup_m3 remote proc driver

 .../bindings/remoteproc/wkup_m3_rproc.txt  |  32 
 arch/arm/mach-omap2/pdata-quirks.c |  13 ++
 drivers/remoteproc/Kconfig |  12 ++
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/wkup_m3_rproc.c | 175 +
 include/linux/platform_data/wkup_m3.h  |  23 +++
 6 files changed, 256 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
 create mode 100644 include/linux/platform_data/wkup_m3.h

-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 3/3] remoteproc: wkup_m3: Add wkup_m3 remote proc driver

[Dave Gerlach]

Add a remoteproc driver to load the firmware for and boot the wkup_m3
present on am33xx. The wkup_m3 is an integrated Cortex M3 that allows
the SoC to enter the lowest possible power state by taking control from
the MPU after it has gone into its own low power state and shutting off
any additional peripherals.

The driver expects a resource table to be present in the wkup_m3
firmware to define the required memory resources needed by the wkup_m3,
at least the data memory so that the firmware can be copied to the proper
place for execution.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 drivers/remoteproc/Kconfig |  12 +++
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/wkup_m3_rproc.c | 175 +
 3 files changed, 188 insertions(+)
 create mode 100644 drivers/remoteproc/wkup_m3_rproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 5e343ba..7fbdb53 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -41,6 +41,18 @@ config STE_MODEM_RPROC
  This can be either built-in or a loadable module.
  If unsure say N.
 
+config WKUP_M3_RPROC
+   bool AM33xx wkup-m3 remoteproc support
+   depends on SOC_AM33XX
+   select REMOTEPROC
+   help
+ Say y here to support AM33xx wkup-m3.
+
+ Required for Suspend-to-ram and CPUIdle on AM33xx. Allows for
+ loading of firmware of CM3 PM coprocessor that is present
+ on AM33xx family of SoCs
+ If unsure say N.
+
 config DA8XX_REMOTEPROC
tristate DA8xx/OMAP-L13x remoteproc support
depends on ARCH_DAVINCI_DA8XX
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ac2ff75..81b04d1 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -9,4 +9,5 @@ remoteproc-y+= remoteproc_virtio.o
 remoteproc-y   += remoteproc_elf_loader.o
 obj-$(CONFIG_OMAP_REMOTEPROC)  += omap_remoteproc.o
 obj-$(CONFIG_STE_MODEM_RPROC)  += ste_modem_rproc.o
+obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/wkup_m3_rproc.c 
b/drivers/remoteproc/wkup_m3_rproc.c
new file mode 100644
index 000..8686ca2
--- /dev/null
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -0,0 +1,175 @@
+/*
+ * AMx3 Wkup M3 Remote Processor driver
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@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/interrupt.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/remoteproc.h
+
+#include linux/platform_data/wkup_m3.h
+
+#include remoteproc_internal.h
+
+struct wkup_m3_rproc {
+   struct rproc *rproc;
+   struct platform_device *pdev;
+};
+
+static int wkup_m3_rproc_start(struct rproc *rproc)
+{
+   struct wkup_m3_rproc *m3_rproc = rproc-priv;
+   struct platform_device *pdev = m3_rproc-pdev;
+   struct device *dev = pdev-dev;
+   struct wkup_m3_platform_data *pdata = dev-platform_data;
+   int ret;
+
+   ret = pdata-deassert_reset(pdev, pdata-reset_name);
+   if (ret) {
+   dev_err(dev, Unable to reset wkup_m3!\n);
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
+static int wkup_m3_rproc_stop(struct rproc *rproc)
+{
+   struct wkup_m3_rproc *m3_rproc = rproc-priv;
+   struct platform_device *pdev = m3_rproc-pdev;
+   struct device *dev = pdev-dev;
+   struct wkup_m3_platform_data *pdata = dev-platform_data;
+   int ret;
+
+   ret = pdata-assert_reset(pdev, pdata-reset_name);
+   if (ret) {
+   dev_err(dev, Unable to assert reset of wkup_m3!\n);
+   return -ENODEV;
+   }
+   return 0;
+}
+
+static struct rproc_ops wkup_m3_rproc_ops = {
+   .start  = wkup_m3_rproc_start,
+   .stop   = wkup_m3_rproc_stop,
+};
+
+static const struct of_device_id wkup_m3_rproc_of_match[] = {
+   {
+   .compatible = ti,am3353-wkup-m3,
+   .data = (void *)am335x-pm-firmware.elf,
+   },
+   {},
+};
+
+static int wkup_m3_rproc_probe(struct platform_device *pdev)
+{
+   struct device *dev = pdev-dev;
+   const char *fw_name;
+   struct wkup_m3_platform_data *pdata = dev-platform_data;
+   struct wkup_m3_rproc *m3_rproc;
+   const

[RFC PATCH 1/3] Documentation: dt: add ti,am3353-wkup-m3-ipc bindings

[Dave Gerlach]

Add the device tree bindings document for ti,am3353-wkup-m3-ipc which
is used by the wkup_m3_ipc driver.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt | 41 ++
 1 file changed, 41 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 000..ceb6acf
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
@@ -0,0 +1,41 @@
+Wakeup M3 IPC Driver
+=
+
+TI AMx3 family of devices use a Cortex M3 co-processor 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 a wakeup M3 IP instance within
+an SoC. The sub-mailboxes are represented as child node of this parent node.
+
+Required properties:
+
+- compatible:  Should be ti,am3353-wkup-m3-ipc for AM33xx SoCs
+- reg: Contains the wkup_m3 register address ranges for
+   ipc-regs.
+- reg-names:   Name for ipc-regs given above
+- 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 */
+wkup_m3_ipc: wkup_m3_ipc@44e11324 {
+   compatible = ti,am3353-wkup-m3-ipc;
+   reg = 0x44e11324 0x0024;
+   reg-names = ipc_regs;
+   interrupts = 78;
+   ti,rproc = wkup_m3;
+   mboxes = mailbox mbox_wkupm3;
+};
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 3/3] ARM: dts: am33xx: Add wkup_m3_ipc node

[Dave Gerlach]

Add wkup_m3_ipc node for wkup_m3_ipc driver.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 41659df..b86d8c0 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -848,6 +848,15 @@
reg = 0x4831 0x2000;
interrupts = 111;
};
+
+   wkup_m3_ipc: wkup_m3_ipc@44e11324 {
+   compatible = ti,am3353-wkup-m3-ipc;
+   reg = 0x44e11324 0x0024;
+   reg-names = ipc_regs;
+   interrupts = 78;
+   ti,rproc = wkup_m3;
+   mboxes = mailbox mbox_wkupm3;
+   };
};
 };
 
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 2/3] memory: ti-emif-sram: introduce relocatable suspend/resume handlers

[Dave Gerlach]

Certain SoCs like Texas Instruments AM335x and AM437x require parts
of the EMIF PM code to run late in the suspend sequence from SRAM,
such as saving and restoring the EMIF context and placing the memory
into self-refresh.

One requirement for these SoC's to suspend and enter it's lowest power
mode, called DeepSleep0, is that the PER power domain must be shut
off. Because the EMIF (DDR Controller) resides within this power
domain, it will lose context during a suspend operation, so we must
save it to restore once we resume. However, we cannot execute this
code from external memory, as it is not available at this point, so
the code must be executed late in the suspend path from SRAM.

This patch introduces a ti-emif-sram driver that includes several
functions written in ARM ASM that are relocatable so the PM SRAM
code can use them. It can export a table containing the absolute
addresses of the available PM functions so that other SRAM code
can branch to them. This code is required for suspend/resume on
AM335x and AM437x to work.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 drivers/memory/Kconfig   |  10 ++
 drivers/memory/Makefile  |   3 +
 drivers/memory/emif.h|   8 ++
 drivers/memory/ti-emif-sram-pm.S | 233 +++
 drivers/memory/ti-emif-sram.c| 195 
 include/linux/ti-emif-sram.h |  26 +
 6 files changed, 475 insertions(+)
 create mode 100644 drivers/memory/ti-emif-sram-pm.S
 create mode 100644 drivers/memory/ti-emif-sram.c
 create mode 100644 include/linux/ti-emif-sram.h

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 6d91c27..02b778e 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -41,6 +41,16 @@ config TI_EMIF
  parameters and other settings during frequency, voltage and
  temperature changes
 
+config TI_EMIF_SRAM
+   bool Texas Instruments EMIF SRAM driver
+   depends on SOC_AM33XX
+   help
+ This driver is for the EMIF module available on Texas Instruments
+ AM33XX SoCs and is required for PM. Certain parts of the EMIF PM
+ code must run from on-chip SRAM late in the suspend sequence so
+ this driver provides several relocatable PM functions for the SoC
+ PM code to use.
+
 config MVEBU_DEVBUS
bool Marvell EBU Device Bus Controller
default y
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index c32d319..42888c2 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -13,3 +13,6 @@ obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
 obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)   += tegra20-mc.o
 obj-$(CONFIG_TEGRA30_MC)   += tegra30-mc.o
+obj-$(CONFIG_TI_EMIF_SRAM) += ti-emif-sram.o ti-emif-sram-pm.o
+
+AFLAGS_ti-emif-sram-pm.o   :=-Wa,-march=armv7-a
diff --git a/drivers/memory/emif.h b/drivers/memory/emif.h
index bfe08ba..8e86eb2 100644
--- a/drivers/memory/emif.h
+++ b/drivers/memory/emif.h
@@ -585,5 +585,13 @@ struct emif_regs {
u32 ext_phy_ctrl_3_shdw;
u32 ext_phy_ctrl_4_shdw;
 };
+
+struct ti_emif_pm_functions;
+
+extern unsigned int ti_emif_sram;
+extern unsigned int ti_emif_sram_sz;
+extern void __iomem *ti_emif_base_addr_virt;
+extern void __iomem *ti_emif_base_addr_phys;
+extern struct ti_emif_pm_functions ti_emif_pm;
 #endif /* __ASSEMBLY__ */
 #endif /* __EMIF_H */
diff --git a/drivers/memory/ti-emif-sram-pm.S b/drivers/memory/ti-emif-sram-pm.S
new file mode 100644
index 000..49b0be4
--- /dev/null
+++ b/drivers/memory/ti-emif-sram-pm.S
@@ -0,0 +1,233 @@
+/*
+ * Low level PM code for TI EMIF
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Dave Gerlach
+ *
+ * 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.
+ */
+
+#include linux/linkage.h
+#include asm/memory.h
+#include asm/assembler.h
+
+#include emif.h
+
+#define EMIF_POWER_MGMT_WAIT_SELF_REFRESH_8192_CYCLES  0x00a0
+#define EMIF_POWER_MGMT_SR_TIMER_MASK  0x00f0
+#define EMIF_POWER_MGMT_SELF_REFRESH_MODE  0x0200
+#define EMIF_POWER_MGMT_SELF_REFRESH_MODE_MASK 0x0700
+
+#define EMIF_SDCFG_TYPE_DDR2   0x2  SDRAM_TYPE_SHIFT
+#define EMIF_STATUS_READY  0x4
+
+   .text
+   .align 3
+
+ENTRY(ti_emif_sram)
+
+/*
+ * void ti_emif_save_context(void)
+ *
+ * Used during suspend to save the context of all required EMIF registers
+ * to local memory if the EMIF is going to lose context during the sleep

[RFC PATCH 3/3] ARM: dts: am33xx: Add emif node

[Dave Gerlach]

Add node for Texas Instruments AM335x EMIF to make use of the
ti-emif-sram driver.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index b86d8c0..b432499 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -153,6 +153,12 @@
#dma-cells = 1;
};
 
+   emif: emif@4c00 {
+   compatible = ti,am3352-emif;
+   reg =   0x4C00 0x1000;
+   sram = ocmcram;
+   };
+
gpio0: gpio@44e07000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 2/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-gerl...@ti.com
---
 drivers/soc/ti/Kconfig   |  11 +
 drivers/soc/ti/Makefile  |   1 +
 drivers/soc/ti/wkup_m3_ipc.c | 503 +++
 include/linux/wkup_m3_ipc.h  |  33 +++
 4 files changed, 548 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..61cda85 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -28,4 +28,15 @@ config KEYSTONE_NAVIGATOR_DMA
 
  If unsure, say N.
 
+config WKUP_M3_IPC
+   bool TI AM33XX Wkup-M3 IPC Driver
+   depends on WKUP_M3_RPROC
+   select MAILBOX
+   select OMAP2PLUS_MBOX
+   help
+ TI AM33XX has a Cortex M3 to handle low power transitions. This IPC
+ driver provides the necessary API to communicate and use the wkup m3
+ for PM features like Suspend/Resume and boots the wkup_m3 using
+ wkup_m3_rproc driver.
+
 endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 6bed611..b6b8c8b 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -3,3 +3,4 @@
 #
 obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS)  += 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 000..f915da6
--- /dev/null
+++ b/drivers/soc/ti/wkup_m3_ipc.c
@@ -0,0 +1,503 @@
+/*
+ * AMx3 Wkup M3 IPC driver
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@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/mailbox_client.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_DS00x4
+#define IPC_CMD_STANDBY0xc
+#define IPC_CMD_RESET  0xe
+#define DS_IPC_DEFAULT 0x
+#define M3_VERSION_UNKNOWN 0x
+#define M3_BASELINE_VERSION0x187
+#define M3_WAKE_SRC_MASK   0xFF
+#define M3_STATUS_RESP_MASK(0x  16)
+#define M3_FW_VERSION_MASK 0x
+
+#define M3_STATE_UNKNOWN   0
+#define M3_STATE_RESET 1
+#define M3_STATE_INITED2
+#define M3_STATE_MSG_FOR_LP3
+#define M3_STATE_MSG_FOR_RESET 4
+
+struct wkup_m3_wakeup_src {
+   int irq_nr;
+   char src[10];
+};
+
+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 mbox_client mbox_client;
+   struct mbox_chan *mbox;
+};
+
+static struct wkup_m3_ipc m3_ipc_state;
+
+static DECLARE_COMPLETION(m3_ipc_sync);
+
+static const struct wkup_m3_wakeup_src wakeups[] = {
+   {.irq_nr = 35,  .src = USB0_PHY},
+   {.irq_nr = 36,  .src = USB1_PHY},
+   {.irq_nr = 40,  .src = I2C0},
+   {.irq_nr = 41,  .src = RTC Timer},
+   {.irq_nr = 42,  .src = RTC Alarm},
+   {.irq_nr = 43,  .src = Timer0},
+   {.irq_nr = 44,  .src = Timer1},
+   {.irq_nr = 45,  .src = UART},
+   {.irq_nr = 46,  .src = GPIO0},
+   {.irq_nr = 48,  .src = MPU_WAKE},
+   {.irq_nr = 49,  .src = WDT0},
+   {.irq_nr = 50,  .src = WDT1},
+   {.irq_nr = 51,  .src = ADC_TSC

[RFC PATCH 1/3] Documentation: dt: add ti,am3352-emif bindings

[Dave Gerlach]

Add the device tree bindings document for ti,am3352-emif which
is used by the ti-emif-sram driver to provide low-level PM
functionality.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 .../bindings/memory-controllers/ti/emif-sram.txt   | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/ti/emif-sram.txt

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/ti/emif-sram.txt 
b/Documentation/devicetree/bindings/memory-controllers/ti/emif-sram.txt
new file mode 100644
index 000..72d6db0
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif-sram.txt
@@ -0,0 +1,31 @@
+EMIF SRAM Driver
+=
+
+TI AMx3 family of devices use a similar EMIF to other TI SoCs but have
+different PM requirements. Late suspend code runs from SRAM and requires
+save and restore of EMIF context and placing the SDRAM in and out of
+self-refresh. Because of this, the ti-emif-sram driver introduces
+relocatable PM function that can run from SRAM and place the EMIF in
+the proper state for low-power mode transition.
+
+EMIF Device Node:
+
+A emif node is used to represent an EMIF IP instance within an SoC. The node
+must contain a phandle to an sram node so the ti-emif-sram driver can allocate
+space within the sram and copy the relocatable PM functions.
+
+Required properties:
+
+- compatible:  Should be ti,am3352-emif for AM33xx SoCs
+- reg: Contains the emif register address ranges.
+- sram:Phandle for generic sram node for the driver
+   to use to copy PM functions to.
+
+Example:
+
+/* AM33xx */
+emif: emif@4c00 {
+   compatible = ti,am3352-emif;
+   reg =   0x4C00 0x1000;
+   sram = ocmcram;
+};
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v5 3/4] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Dave Gerlach]

AM335x supports various low power modes as documented
in section 8.1.4.3 of the AM335x Technical Reference Manual.

DeepSleep0 mode offers the lowest power mode with limited
wakeup sources without a system reboot and is mapped as
the suspend state in the kernel. In this state, MPU and
PER domains are turned off with the internal RAM held in
retention to facilitate the resume process. As part of
the boot process, the assembly code is copied over to OCMCRAM
so it can be executed to turn of the EMIF and put DDR into self
refresh.

AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU
in DeepSleep0 entry and exit. WKUP_M3 takes care
of the clockdomain and powerdomain transitions based on the
intended low power state. MPU needs to load the appropriate
WKUP_M3 binary onto the WKUP_M3 memory space before it can
leverage any of the PM features like DeepSleep. This loading
is handled by the remoteproc driver wkup_m3_rproc.

Communication with the WKUP_M3 is handled by a wkup_m3_ipc
driver that exposes the specific PM functionality to be used
the PM code.

In the current implementation when the suspend process
is initiated, MPU interrupts the WKUP_M3 to let it know about
the intent of entering DeepSleep0 and waits for an ACK. When
the ACK is received MPU continues with its suspend process
to suspend all the drivers and then jumps to assembly in
OCMC RAM. The assembly code puts the external RAM in self-refresh
mode, gates the MPU clock, and then finally executes the WFI
instruction. Execution of the WFI instruction with MPU clock gated
triggers another interrupt to the WKUP_M3 which then continues
with the power down sequence wherein the clockdomain and
powerdomain transition takes place. As part of the sleep sequence,
WKUP_M3 unmasks the interrupt lines for the wakeup sources. WFI
execution on WKUP_M3 causes the hardware to disable the main
oscillator of the SoC and from here system remains in sleep state
until a wake source brings the system into resume path.

When a wakeup event occurs, WKUP_M3 starts the power-up
sequence by switching on the power domains and finally
enabling the clock to MPU. Since the MPU gets powered down
as part of the sleep sequence in the resume path ROM code
starts executing. The ROM code detects a wakeup from sleep
and then jumps to the resume location in OCMC which was
populated in one of the IPC registers as part of the suspend
sequence.

Code is based on work by Vaibhav Bedia.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi |   2 +
 arch/arm/mach-omap2/pm33xx.c  | 250 ++
 2 files changed, 252 insertions(+)
 create mode 100644 arch/arm/mach-omap2/pm33xx.c

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index b432499..c4210d2 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -80,6 +80,7 @@
mpu {
compatible = ti,omap3-mpu;
ti,hwmods = mpu;
+   sram = ocmcram;
};
};
 
@@ -744,6 +745,7 @@
ocmcram: ocmcram@4030 {
compatible = mmio-sram;
reg = 0x4030 0x1; /* 64k */
+   map-exec;
};
 
wkup_m3: wkup_m3@44d0 {
diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c
new file mode 100644
index 000..2baf810
--- /dev/null
+++ b/arch/arm/mach-omap2/pm33xx.c
@@ -0,0 +1,250 @@
+/*
+ * AM33XX Power Management Routines
+ *
+ * Copyright (C) 2012-2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Vaibhav Bedia, Dave Gerlach
+ *
+ * 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.
+ */
+
+#include linux/cpu.h
+#include linux/err.h
+#include linux/genalloc.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/io.h
+#include linux/module.h
+#include linux/sizes.h
+#include linux/suspend.h
+#include linux/ti-emif-sram.h
+#include linux/wkup_m3_ipc.h
+
+#include asm/fncpy.h
+#include asm/proc-fns.h
+#include asm/suspend.h
+#include asm/system_misc.h
+
+#include clockdomain.h
+#include cm33xx.h
+#include common.h
+#include pm.h
+#include powerdomain.h
+#include soc.h
+
+static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm;
+static struct clockdomain *gfx_l4ls_clkdm;
+
+static int (*am33xx_do_wfi_sram)(unsigned long unused);
+static phys_addr_t am33xx_do_wfi_sram_phys;
+
+#ifdef CONFIG_SUSPEND
+static int am33xx_pm_suspend(void)
+{
+   int i, ret = 0;
+   int status = 0

[RFC PATCH v5 0/4] ARM: OMAP2+: AM33XX: Add suspend-resume support

[Dave Gerlach]

Hi,
This series is v5 of the series to add suspend/resume support for Texas
Instruments AM335x SoC. It has gone through a rather major overhaul
since the last version and because of that has been split into multiple
different sets of patches, on which this series depends. Previous discussion
that influenced there changes can be found here [1]. This series depends on
generic sram exec mapping patch here [2], emif series here [3],
and wkup_m3_ipc series here [4]. I have pushed a branch containing the patches
from ALL required series here [5] for testing or a view of the high level
flow of the entire series.

The largest change with this revision is the introduction of a
wkup_m3_ipc driver which handles all communication with the Cortex M3
present on am335x for handling low power tasks. Previously this was
handled in the wkup_m3_rproc driver (also sent in an earlier series)
but that driver is now only responsible for booting the wkup_m3. The
wkup_m3_ipc driver exposes an API with all required PM functionality
needed by the PM code introduced by this series, so the PM code has
shrunk considerably.

Another major change is that the EMIF code previously present in the
sleep33xx asm code and pm33xx code for save and restore of EMIF context
and entry into low power mode has all been moved in to a separate EMIF
driver, further reducing the size of the PM code. Because of this, moving
the emif header defines into include/linux/ti_emif.h is no longer necessary.

Other changes include clean up of the timer suspend/resume handlers, now
look up hwmod in init and use that handle along with renaming to
*_idle/*_unidle to avoid confusion with true suspend handlers. 

Suspend support requires:
CONFIG_TI_EMIF_SRAM
CONFIG_WKUP_M3_RPROC
CONFIG_WKUP_M3_IPC

And also requires AM335x USB support to be enabled to work for multiple
cycles. If you want to load firmware from rootfs in /lib/firmware you now
must also select CONFIG_FW_LOADER_USER_HELPER_FALLBACK.

This code works with version 0x189 of the CM3 firmware found here [6] on
the next branch, /bin/am335x-pm-firmware.elf.

Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg109331.html
[2] http://www.spinics.net/linux/lists/kernel/msg1876629.html
[3] http://www.spinics.net/linux/lists/kernel/msg1876646.html
[4] http://www.spinics.net/linux/lists/kernel/msg1876642.html
[5] https://github.com/dgerlach/linux-pm/tree/rfc-pm-am335x-v3.18-rc6
[6] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next

Dave Gerlach (3):
  ARM: OMAP2+: AM33XX: Add assembly code for PM operations
  ARM: OMAP2+: AM33XX: Basic suspend resume support
  ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds

Vaibhav Bedia (1):
  ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device

 arch/arm/boot/dts/am33xx.dtsi   |   2 +
 arch/arm/mach-omap2/Makefile|   2 +
 arch/arm/mach-omap2/common.h|   9 ++
 arch/arm/mach-omap2/io.c|   1 +
 arch/arm/mach-omap2/pm.h|   6 +
 arch/arm/mach-omap2/pm33xx.c| 250 
 arch/arm/mach-omap2/sleep33xx.S | 216 ++
 arch/arm/mach-omap2/timer.c |  28 +
 8 files changed, 514 insertions(+)
 create mode 100644 arch/arm/mach-omap2/pm33xx.c
 create mode 100644 arch/arm/mach-omap2/sleep33xx.S

-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html