Re: [PATCH v3 0/3] soc: ti: Introduce wkup_m3_ipc driver
Hi, On 10/20/2015 11:18 AM, Tony Lindgren wrote: Hi all, * Dave Gerlach [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
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&p=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 = &mmc1;
+ mmcblk1 = &mmc2;
+ };
+
+ 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 = <&dcdc2_reg>;
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+
+ back_button {
+ label = "Back Button";
+ gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
+ linux,code = ;
+ debounce-interval = <1000>;
+ gpio-key,wakeup;
+ };
+
+ front_button {
+ label = "Front Button";
+ gpios = <&gpio1 25 GPIO_ACTIVE_HIGH>;
+ linux,code = ;
+ debounce-interval = <1000>;
+ gpio-key,wakeup;
+ };
+ };
+
+ leds {
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_leds_s0>;
+
+ compatible = "gpio-leds";
+
+ led@1 {
+ label = "shc:power:red";
+ gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led@2 {
+ label = "shc:power:bl";
+ gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "timer";
+
[PATCH v3 2/3] Documentation: dt: add bindings for TI Wakeup M3 IPC device
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
Signed-off-by: Suman Anna
---
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 = <&wkup_m3>;
+ mboxes = <&mailbox &mbox_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 v3 3/3] soc: ti: Add wkup_m3_ipc driver
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
---
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
+ *
+ * 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));
+}
+
+static unsigned int wkup_m3_ctrl_ipc_read(struct wkup_m3_ipc *m3_ipc,
+
[PATCH v3 0/3] soc: ti: Introduce wkup_m3_ipc driver
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 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle
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
[s-a...@ti.com: revise logic and update comments/patch description]
Signed-off-by: Suman Anna
---
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(&mdev->cfg_lock);
}
-static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
+static int omap_mbox_chan_send_noirq(struct omap_mbox *mbox, void *data)
{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
int ret = -EBUSY;
- if (!mbox)
- return -EINVAL;
+ if (!mbox_fifo_full(mbox)) {
+ _omap_mbox_enable_irq(mbox, IRQ_RX);
+ mbox_fifo_write(mbox, (mbox_msg_t)data);
+ ret = 0;
+ _omap_mbox_disable_irq(mbox, IRQ_RX);
+
+ /* we must read and ack the interrupt directly from here */
+ mbox_fifo_read(mbox);
+ ack_mbox_irq(mbox, IRQ_RX);
+ }
+
+ return ret;
+}
+
+static int omap_mbox_chan_send(struct omap_mbox *mbox, void *data)
+{
+ int ret = -EBUSY;
if (!mbox_fifo_full(mbox)) {
mbox_fifo_write(mbox, (mbox_msg_t)data);
@@ -604,6 +625,22 @@ static int omap_mbox_chan_send_data(struct mbox_chan
*chan, void *data)
return ret;
}
+static int omap_mbox_chan_send_data(struct mbox_ch
[PATCH] remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export alias
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
---
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] ARM: OMAP2+: AM43XX: Enable autoidle for clks in am43xx_init_late
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
---
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
[PATCH] input: touchscreen: ti_am335x_tsc: Fix HWPEN interrupt handling
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
---
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
Re: [PATCH v2 3/3] soc: ti: Add wkup_m3_ipc driver
On 07/20/2015 01:16 AM, Tony Lindgren wrote: * Dave Gerlach [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 3/4] ARM: dts: AM33xx: Add the wkup_m3_ipc node
From: Suman Anna
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
Signed-off-by: Dave Gerlach
---
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
[PATCH 2/4] ARM: dts: AM4372: Add ti,mbox-send-noirq to wkup_m3 mailbox
From: Keerthy
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
Acked-by: Dave Gerlach
[s-a...@ti.com: revise commit description]
Signed-off-by: Suman Anna
---
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 4/4] ARM: dts: AM4372: Add the wkup_m3_ipc node
From: Suman Anna
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
Signed-off-by: Dave Gerlach
---
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 = ;
+ 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
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 1/4] ARM: dts: AM33xx: Add ti,mbox-send-noirq to wkup_m3 mailbox
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
[s-a...@ti.com: revise commit description]
Signed-off-by: Suman Anna
---
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 2/3] Documentation: dt: add bindings for TI Wakeup M3 IPC device
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
Signed-off-by: Suman Anna
---
.../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 v2 3/3] soc: ti: Add wkup_m3_ipc driver
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
---
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
+ *
+ * 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
+#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
+
+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;
+
+ writel(val, m3_ipc->ipc_mem_base +
+ AM33XX_CTRL_IPC_REG_OFFSET(ipc_reg_num));
+}
+
+static unsigned int wkup_m3_ctrl_ipc_read(struct wkup_m3_ipc *m3_ipc,
+
[PATCH v2 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle
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
[s-a...@ti.com: revise logic and update comments/patch description]
Signed-off-by: Suman Anna
---
.../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(&mdev->cfg_lock);
}
-static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
+static int omap_mbox_chan_send_noirq(struct omap_mbox *mbox, void *data)
{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
int ret = -EBUSY;
- if (!mbox)
- return -EINVAL;
+ if (!mbox_fifo_full(mbox)) {
+ _omap_mbox_enable_irq(mbox, IRQ_RX);
+ mbox_fifo_write(mbox, (mbox_msg_t)data);
+ ret = 0;
+ _omap_mbox_disable_irq(mbox, IRQ_RX);
+
+ /* we must read and ack the interrupt directly from here */
+ mbox_fifo_read(mbox);
+ ack_mbox_irq(mbox, IRQ_RX);
+ }
+
+ return ret;
+}
+
+static int omap_mbox_chan_send(struct omap_mbox *mbox, void *data)
+{
+ int ret = -EBUSY;
if (!mbox_fifo_full(mbox)) {
mbox_fifo_write(mbox, (mbox_msg_t)data);
@@ -604,6 +625,22 @@ static int omap_mbox_chan_send_data(struct mbox_chan
*chan, void *data)
return ret;
}
+static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *dat
[PATCH v2 0/3] soc: ti: Introduce wkup_m3_ipc driver
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
Re: remoteproc: wkup_m3: suspend/resume for am335x bbone
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 : >> 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
[PATCH v4 0/3] ARM: OMAP2+: wkup_m3_rproc support patches
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
From: Suman Anna
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
Signed-off-by: Dave Gerlach
---
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
From: Suman Anna
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
Signed-off-by: Dave Gerlach
---
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
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
Signed-off-by: Dave Gerlach
---
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
#include
+#include
#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
Re: [PATCH v3 0/3] ARM: OMAP2+: wkup_m3_rproc support patches
On 07/13/2015 02:27 AM, Tony Lindgren wrote: > * Tony Lindgren [150713 00:28]: >> * Dave Gerlach [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] ARM: OMAP2+: Add HAVE_ARM_SCU for AM43XX
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 --- 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
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
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 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
>> Signed-off-by: Suman Anna
>> ---
>> 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
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
Signed-off-by: Suman Anna
---
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
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
-#include
#include
#include
#include
#include
+#include
/**
* 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
Re: Regression with AM43xx devices
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
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
> 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
> [p...@pwsan.com: updated to apply]
> Signed-off-by: Paul Walmsley
>
> 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
[PATCH v4 3/4] Documentation: dt: add bindings for TI Wakeup M3 processor
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
Signed-off-by: Dave Gerlach
Acked-by: Tony Lindgren
---
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 v4 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3
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
Signed-off-by: Dave Gerlach
---
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
+ * Suman Anna
+ *
+ * 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 "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
[PATCH v4 2/4] remoteproc: add a rproc ops for performing address translation
From: Suman Anna
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
Signed-off-by: Dave Gerlach
---
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 1/4] remoteproc: introduce rproc_get_by_phandle API
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
Signed-off-by: Dave Gerlach
---
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
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
-#include
#include
#include
#include
#include
+#include
/**
* 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 +4
[PATCH v4 0/4] remoteproc: Introduce wkup_m3_rproc driver
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 v3 3/3] ARM: dts: AM4372: Add the wkupm3 rproc node
From: Suman Anna
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
Signed-off-by: Dave Gerlach
---
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
[PATCH v3 0/3] ARM: OMAP2+: wkup_m3_rproc support patches
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 2/3] ARM: dts: AM33xx: Update and move wkup_m3 node to l4 node
From: Suman Anna
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
Signed-off-by: Dave Gerlach
---
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 1/3] ARM: OMAP2+: Use pdata-quirks for wkup_m3 reset management
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
Signed-off-by: Dave Gerlach
---
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
#include
+#include
#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 1/4] remoteproc: introduce rproc_get_by_phandle API
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
Signed-off-by: Suman Anna
---
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
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
#include
#include
+#include
#include
#include
#include
@@ -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)
[PATCH v3 3/4] Documentation: dt: add bindings for TI Wakeup M3 processor
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
Signed-off-by: Dave Gerlach
---
.../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 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3
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
Signed-off-by: Dave Gerlach
---
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
+ * Suman Anna
+ *
+ * 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 "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)) {
+ dev_err(dev, "Unable to assert reset of wkup_m3!\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+sta
[PATCH v3 2/4] remoteproc: add a rproc ops for performing address translation
From: Suman Anna
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
Signed-off-by: Dave Gerlach
---
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 0/4] remoteproc: Introduce wkup_m3_rproc driver
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-next&id=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
Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
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 [150306 09:28]: >>>>> On 03/05/2015 06:41 PM, Tony Lindgren wrote: >>>>>> * Tony Lindgren [150305 12:24]: >>>>>>> * Dave Gerlach [150305 11:53]: >>>>>>>> On 03/05/2015 12:49 PM, Tony Lindgren wrote: >>>>>>>>> * Paul Walmsley [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
Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges
Tony,
On 03/10/2015 11:09 AM, Tony Lindgren wrote:
> * Suman Anna [150309 16:59]:
>> On 03/05/2015 10:57 AM, Tony Lindgren wrote:
>>> * Suman Anna [150305 08:47]:
>>>> On 03/05/2015 09:40 AM, Tony Lindgren wrote:
>>>>> * Dave Gerlach [150304 20:14]:
>>>> Dave,
>>>>
>>>> Looks like the commit message disappeared during your patch preparation.
>>>>
>>>>>> Signed-off-by: Suman Anna
>>>>>> Signed-off-by: Dave Gerlach
>>>>>> ---
>>>>>> 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>,
Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
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 [150306 09:28]: >>> On 03/05/2015 06:41 PM, Tony Lindgren wrote: >>>> * Tony Lindgren [150305 12:24]: >>>>> * Dave Gerlach [150305 11:53]: >>>>>> On 03/05/2015 12:49 PM, Tony Lindgren wrote: >>>>>>> * Paul Walmsley [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,
Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
Tony, On 03/06/2015 11:45 AM, Tony Lindgren wrote: > * Dave Gerlach [150306 09:28]: >> On 03/05/2015 06:41 PM, Tony Lindgren wrote: >>> * Tony Lindgren [150305 12:24]: >>>> * Dave Gerlach [150305 11:53]: >>>>> On 03/05/2015 12:49 PM, Tony Lindgren wrote: >>>>>> * Paul Walmsley [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 >> seeme
Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
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
>>>> ---
>>>> 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 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
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
>> ---
>> 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 0/2] pinctrl: dt-bindings: Fix amx3 SLEWCTRL_FAST binding
On 03/06/2015 11:13 AM, Tony Lindgren wrote: > * Dave Gerlach [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 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
On 03/05/2015 06:41 PM, Tony Lindgren wrote: > * Tony Lindgren [150305 12:24]: >> * Dave Gerlach [150305 11:53]: >>> On 03/05/2015 12:49 PM, Tony Lindgren wrote: >>>> * Paul Walmsley [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
On 03/05/2015 12:49 PM, Tony Lindgren wrote: > * Paul Walmsley [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 3/4] ARM: dts: am43x-epos-evm: Add rtc node with ti,no-init property
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
---
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 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
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
---
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 0/4] Add AM437x RTC
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 4/4] ARM: dts: am437x-gp-evm: Enable RTC
From: Keerthy
Enable RTC on am437x-gp-evm.
Signed-off-by: Keerthy
Signed-off-by: Dave Gerlach
---
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
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
---
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 v2 1/2] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset
Use pdata-quirks to provide platform data required for reset
of the wkup_m3 during boot.
Signed-off-by: Dave Gerlach
---
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
#include
+#include
#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 0/2] ARM: OMAP2+: wkup_m3_rproc support patches
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 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges
Signed-off-by: Suman Anna
Signed-off-by: Dave Gerlach
---
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 1/3] remoteproc: add a rproc ops for performing address translation
From: Suman Anna
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
Signed-off-by: Dave Gerlach
---
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.
[PATCH v2 2/3] Documentation: dt: add ti,am3353-wkup-m3 bindings
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
---
.../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
[PATCH v2 3/3] remoteproc: wkup_m3: Add wkup_m3 remoteproc driver
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
---
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
+ *
+ * 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 "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 - wkupm3-&g
[PATCH v2 0/3] remoteproc: Introduce wkup_m3_rproc driver
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 1/2] pinctrl: am33xx: dt-bindings: fix SLEWCTRL_FAST binding
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 --- 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 0/2] pinctrl: dt-bindings: Fix amx3 SLEWCTRL_FAST binding
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
[PATCH 2/2] pinctrl: am43xx: dt-bindings: fix SLEWCTRL_FAST binding
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 --- 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
Re: [PATCH 2/3] soc: ti: Add wkup_m3_ipc driver
Tony, On 02/26/2015 04:08 PM, Tony Lindgren wrote: > * Dave Gerlach [150226 12:05]: >> Tony, >> On 01/05/2015 04:51 PM, Tony Lindgren wrote: >>> * Dave Gerlach [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 >>>>>> --- >>>>>> 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
Re: [PATCH 2/3] soc: ti: Add wkup_m3_ipc driver
Tony, On 01/05/2015 04:51 PM, Tony Lindgren wrote: > * Dave Gerlach [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 >>>> --- >>>> 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
Tony, On 01/20/2015 12:03 PM, Tony Lindgren wrote: > * Dave Gerlach [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
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 >> --- >> 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 >> + * >> + * 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 >> +#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_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 >
Re: [PATCH 3/3] remoteproc: wkup_m3: Add wkup_m3 remote proc driver
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
>> ---
>> 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
>> + *
>> + * 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 "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 soe
[PATCH 3/3] ARM: dts: am33xx: Add wkup_m3_ipc node
Add wkup_m3_ipc node for wkup_m3_ipc driver.
Signed-off-by: Dave Gerlach
---
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
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
---
.../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 2/3] soc: ti: Add wkup_m3_ipc driver
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
---
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
+ *
+ * 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
+#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_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));
+}
+
+static inline unsigned int wkup_m3_ctrl_ipc_read(struct wkup_m3_ipc *m3_ipc,
+int ipc_reg_num)
+{
+ if (ipc_reg_num <
[PATCH 0/3] drivers: soc: ti: Introduce wkup_m3_ipc driver
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-kernel&m=142022798923784&w=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 2/3] Documentation: dt: add ti,am3353-wkup-m3 bindings
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
---
.../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
[PATCH 1/3] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset
Use pdata-quirks to provide platform data required for reset
of the wkup_m3 during boot.
Signed-off-by: Dave Gerlach
---
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
#include
+#include
#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
+ *
+ * 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 3/3] remoteproc: wkup_m3: Add wkup_m3 remote proc driver
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
---
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
+ *
+ * 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 "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 struct of_device_id
[PATCH 0/3] remoteproc: Introduce wkup_m3_rproc driver
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] remoteproc: Introduce rproc_get_by_phandle API
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
---
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
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
#include
#include
+#include
#include
#include
#include
@@ -36,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -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);
dev_info(dev, "Note: remoteproc is still under developme
Re: [RFC PATCH 2/3] soc: ti: Add wkup_m3_ipc driver
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 v5 1/4] ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device
From: Vaibhav Bedia
OMAP timer code registers two timers - one as clocksource
and one as clockevent. Since AM33XX has only one usable timer
in the WKUP domain one of the timers needs suspend-resume
support to restore the configuration to pre-suspend state.
commit adc78e6b9946 ("timekeeping: Add suspend and resume
of clock event devices") introduced .suspend and .resume
callbacks for clock event devices. Leverage these
callbacks to have AM33XX clockevent timer behave properly
across system suspend.
Signed-off-by: Vaibhav Bedia
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/timer.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 4f61148..5c7ecde 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -67,6 +67,9 @@
static struct omap_dm_timer clkev;
static struct clock_event_device clockevent_gpt;
+/* Clockevent hwmod for am335x and am437x suspend */
+struct omap_hwmod *clockevent_gpt_hwmod;
+
#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
static unsigned long arch_timer_freq;
@@ -128,6 +131,23 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
}
+static void omap_clkevt_idle(struct clock_event_device *unused)
+{
+ if (!clockevent_gpt_hwmod)
+ return;
+
+ omap_hwmod_idle(clockevent_gpt_hwmod);
+}
+
+static void omap_clkevt_unidle(struct clock_event_device *unused)
+{
+ if (!clockevent_gpt_hwmod)
+ return;
+
+ omap_hwmod_enable(clockevent_gpt_hwmod);
+ __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
+}
+
static struct clock_event_device clockevent_gpt = {
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.rating = 300,
@@ -355,6 +375,14 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
3, /* Timer internal resynch latency */
0x);
+ if (soc_is_am33xx()) {
+ clockevent_gpt.suspend = omap_clkevt_idle;
+ clockevent_gpt.resume = omap_clkevt_unidle;
+
+ clockevent_gpt_hwmod =
+ omap_hwmod_lookup(clockevent_gpt.name);
+ }
+
pr_info("OMAP clockevent source: %s at %lu Hz\n", clockevent_gpt.name,
clkev.rate);
}
--
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 4/4] ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds
With all the requisite changes in place we can now enable basic
PM support for AM33xx. This patch updates the various OMAP files
to enable suspend-resume on AM33xx.
Because the suspend resume functionality is different on AM33xx
than other OMAP platforms due to the need for M3 firmware and an
IPC channel to be in place, separate PM ops are used instead of
omap_pm_ops.
Signed-off-by: Dave Gerlach
---
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 ++
4 files changed, 18 insertions(+)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d9e9412..6d1464d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -90,6 +90,7 @@ omap-4-5-pm-common= pm44xx.o
omap-mpuss-lowpower.o
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-pm-common)
obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-pm-common)
obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-pm-common)
+obj-$(CONFIG_SOC_AM33XX) += pm33xx.o sleep33xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
@@ -97,6 +98,7 @@ obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_sleep33xx.o :=-Wa,-march=armv7-a$(plus_sec)
endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 377eea8..64bf9a8 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -76,6 +76,15 @@ static inline int omap4_pm_init_early(void)
}
#endif
+#if defined(CONFIG_PM) && defined(CONFIG_SOC_AM33XX)
+int am33xx_pm_init(void);
+#else
+static inline int am33xx_pm_init(void)
+{
+ return 0;
+}
+#endif
+
#ifdef CONFIG_OMAP_MUX
int omap_mux_late_init(void);
#else
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 03cbb16..4b7828a 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -575,6 +575,7 @@ void __init am33xx_init_early(void)
void __init am33xx_init_late(void)
{
omap_common_late_init();
+ am33xx_pm_init();
}
#endif
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 425bfcd..9e19340 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -81,6 +81,12 @@ extern unsigned int omap3_do_wfi_sz;
/* ... and its pointer from SRAM after copy */
extern void (*omap3_do_wfi_sram)(void);
+/* am33xx_do_wfi function pointer and size, for copy to SRAM */
+extern void am33xx_do_wfi(void);
+extern unsigned int am33xx_do_wfi_sz;
+extern unsigned int am33xx_resume_offset;
+extern unsigned long am33xx_emif_sram_table;
+
/* save_secure_ram_context function pointer and size, for copy to SRAM */
extern int save_secure_ram_context(u32 *addr);
extern unsigned int save_secure_ram_context_sz;
--
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 2/4] ARM: OMAP2+: AM33XX: Add assembly code for PM operations
In preparation for suspend-resume support for AM33XX, add
the assembly file with the code which is copied to internal
memory (OCMC RAM) during bootup and runs from there.
As part of the low power entry (DeepSleep0 mode in AM33XX TRM),
the code running from OCMC RAM does the following
1. Calls routine to store the EMIF configuration
2. Calls routine to place external memory in self-refresh
3. Disables EMIF clock
4. Executes WFI after writing to MPU_CLKCTRL register.
If no interrupts have come, WFI execution on MPU gets registered
as an interrupt with the WKUP-M3. WKUP-M3 takes care of disabling
some clocks which MPU should not (L3, L4, OCMC RAM etc) and takes
care of clockdomain and powerdomain transitions as part of the
DeepSleep0 mode entry.
In case a late interrupt comes in, WFI ends up as a NOP and MPU
continues execution from internal memory. The 'abort path' code
undoes whatever was done as part of the low power entry and indicates
a suspend failure by passing a non-zero value to the cpu_resume routine.
The 'resume path' code is similar to the 'abort path' with the key
difference of MMU being enabled in the 'abort path' but being
disabled in the 'resume path' due to MPU getting powered off.
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/sleep33xx.S | 216
1 file changed, 216 insertions(+)
create mode 100644 arch/arm/mach-omap2/sleep33xx.S
diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S
new file mode 100644
index 000..9399a16
--- /dev/null
+++ b/arch/arm/mach-omap2/sleep33xx.S
@@ -0,0 +1,216 @@
+/*
+ * Low level suspend code for AM33XX SoCs
+ *
+ * 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
+#include
+#include
+
+#include "iomap.h"
+#include "cm33xx.h"
+
+#define AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE 0x0003
+#define AM33XX_CM_CLKCTRL_MODULEMODE_ENABLE0x0002
+
+ .text
+ .align 3
+
+ENTRY(am33xx_do_wfi)
+ stmfd sp!, {r4 - r11, lr} @ save registers on stack
+
+ /*
+* Flush all data from the L1 and L2 data cache before disabling
+* SCTLR.C bit.
+*/
+ ldr r1, kernel_flush
+ blx r1
+
+ /*
+* Clear the SCTLR.C bit to prevent further data cache
+* allocation. Clearing SCTLR.C would make all the data accesses
+* strongly ordered and would not hit the cache.
+*/
+ mrc p15, 0, r0, c1, c0, 0
+ bic r0, r0, #(1 << 2) @ Disable the C bit
+ mcr p15, 0, r0, c1, c0, 0
+ isb
+
+ /*
+* Invalidate L1 and L2 data cache.
+*/
+ ldr r1, kernel_flush
+ blx r1
+
+ ldr r1, ti_emif_save_context
+ blx r1
+
+ ldr r1, ti_emif_enter_sr
+ blx r1
+
+ /* Disable EMIF */
+ ldr r1, virt_emif_clkctrl
+ ldr r2, [r1]
+ bic r2, r2, #AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE
+ str r2, [r1]
+
+ ldr r1, virt_emif_clkctrl
+wait_emif_disable:
+ ldr r2, [r1]
+ ldr r3, module_disabled_val
+ cmp r2, r3
+ bne wait_emif_disable
+
+ /*
+* For the MPU WFI to be registered as an interrupt
+* to WKUP_M3, MPU_CLKCTRL.MODULEMODE needs to be set
+* to DISABLED
+*/
+ ldr r1, virt_mpu_clkctrl
+ ldr r2, [r1]
+ bic r2, r2, #AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE
+ str r2, [r1]
+
+ /*
+* Execute an ISB instruction to ensure that all of the
+* CP15 register changes have been committed.
+*/
+ isb
+
+ /*
+* Execute a barrier instruction to ensure that all cache,
+* TLB and branch predictor maintenance operations issued
+* have completed.
+*/
+ dsb
+ dmb
+
+ /*
+* Execute a WFI instruction and wait until the
+* STANDBYWFI output is asserted to indicate that the
+* CPU is in idle and low power state. CPU can specualatively
+* prefetch the instructions so add NOPs after WFI. Thirteen
+* NOPs as per Cortex-A8 pipeline.
+*/
+ wfi
+
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+
+
[RFC PATCH v5 0/4] ARM: OMAP2+: AM33XX: Add suspend-resume support
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
[RFC PATCH v5 3/4] ARM: OMAP2+: AM33XX: Basic suspend resume support
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
---
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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#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;
+
+ /* Try to put GFX to sleep */
+ omap_set_pwrdm_state(gfx_pwrdm, PWRDM_POWER_
[RFC PATCH 2/3] soc: ti: Add wkup_m3_ipc driver
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
---
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
+ *
+ * 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
+#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_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"},
+ {.irq_nr = 0, .src
[RFC PATCH 1/3] Documentation: dt: add ti,am3352-emif bindings
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
---
.../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 3/3] ARM: dts: am33xx: Add emif node
Add node for Texas Instruments AM335x EMIF to make use of the
ti-emif-sram driver.
Signed-off-by: Dave Gerlach
---
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] memory: ti-emif-sram: introduce relocatable suspend/resume handlers
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
---
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
+#include
+#include
+
+#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 slee
[RFC PATCH 3/3] ARM: dts: am33xx: Add wkup_m3_ipc node
Add wkup_m3_ipc node for wkup_m3_ipc driver.
Signed-off-by: Dave Gerlach
---
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 1/3] Documentation: dt: add ti,am3353-wkup-m3-ipc bindings
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
---
.../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 0/3] remoteproc: Introduce wkup_m3_rproc driver
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
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
---
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
+ *
+ * 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 "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 struct of_device_id
[RFC PATCH 2/3] Documentation: dt: add ti,am3353-wkup-m3 bindings
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
---
.../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 1/3] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset
Use pdata-quirks to provide platform data required for reset
of the wkup_m3 during boot.
Signed-off-by: Dave Gerlach
---
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
#include
+#include
#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
+ *
+ * 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] misc: SRAM: Add option to map SRAM to allow code execution
From: Russ Dill
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
Signed-off-by: Dave Gerlach
---
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 ,[-]
+- 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
#include
#include
+#include
#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
