linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCHv3 00/15] remoteproc: updates for omap remoteproc support
@ 2019-12-13 12:55 Tero Kristo
  2019-12-13 12:55 ` [PATCHv3 01/15] dt-bindings: remoteproc: Add OMAP remoteproc bindings Tero Kristo
                   ` (14 more replies)
  0 siblings, 15 replies; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap

Hi,

This doesn't have any effective changes compared to v2 [1] of the
series, just rebased on top of 5.5-rc1. If someone is interested, I
have an integrated branch against 5.5-rc1 [2] which contains full OMAP
remoteproc support with all the still pending patches, large portion
of those are already posted in some form or another to the kernel
mailing lists.

-Tero

[1] https://lkml.org/lkml/2019/11/19/1199
[2] https://github.com/t-kristo/linux-pm/tree/5.5-rc1-ipc


--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* [PATCHv3 01/15] dt-bindings: remoteproc: Add OMAP remoteproc bindings
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-20  3:38   ` Suman Anna
  2019-12-13 12:55 ` [PATCHv3 02/15] remoteproc/omap: Add device tree support Tero Kristo
                   ` (13 subsequent siblings)
  14 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

Add the device tree bindings document for the IPU and DSP
remote processor devices on OMAP4+ SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to schema]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 .../remoteproc/ti,omap-remoteproc.yaml        | 315 ++++++++++++++++++
 1 file changed, 315 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml

diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
new file mode 100644
index 000000000000..c87dda0a6559
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
@@ -0,0 +1,315 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,omap-remoteproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP4+ Remoteproc Devices
+
+maintainers:
+  - Suman Anna <s-anna@ti.com>
+
+description:
+  The OMAP family of SoCs usually have one or more slave processor sub-systems
+  that are used to offload some of the processor-intensive tasks, or to manage
+  other hardware accelerators, for achieving various system level goals.
+
+  The processor cores in the sub-system are usually behind an IOMMU, and may
+  contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2
+  caches, an Interrupt Controller, a Cache Controller etc.
+
+  The OMAP SoCs usually have a DSP processor sub-system and/or an IPU processor
+  sub-system. The DSP processor sub-system can contain any of the TI's C64x,
+  C66x or C67x family of DSP cores as the main execution unit. The IPU processor
+  sub-system usually contains either a Dual-Core Cortex-M3 or Dual-Core
+  Cortex-M4 processors.
+
+  Each remote processor sub-system is represented as a single DT node. Each node
+  has a number of required or optional properties that enable the OS running on
+  the host processor (MPU) to perform the device management of the remote
+  processor and to communicate with the remote processor. The various properties
+  can be classified as constant or variable. The constant properties are
+  dictated by the SoC and does not change from one board to another having the
+  same SoC. Examples of constant properties include 'iommus', 'reg'. The
+  variable properties are dictated by the system integration aspects such as
+  memory on the board, or configuration used within the corresponding firmware
+  image. Examples of variable properties include 'mboxes', 'memory-region',
+  'timers', 'watchdog-timers' etc.
+
+properties:
+  compatible:
+    enum:
+      - ti,omap4-dsp
+      - ti,omap5-dsp
+      - ti,dra7-dsp
+      - ti,omap4-ipu
+      - ti,omap5-ipu
+      - ti,dra7-ipu
+
+  iommus:
+    minItems: 1
+    maxItems: 2
+    description: |
+      phandles to OMAP IOMMU nodes, that need to be programmed
+      for this remote processor to access any external RAM memory or
+      other peripheral device address spaces. This property usually
+      has only a single phandle. Multiple phandles are used only in
+      cases where the sub-system has different ports for different
+      sub-modules within the processor sub-system (eg: DRA7 DSPs),
+      and need the same programming in both the MMUs.
+
+  mboxes:
+    minItems: 1
+    maxItems: 2
+    description: |
+      OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+      communication with the remote processor. The specifier format is
+      as per the bindings,
+      Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
+      This property should match with the sub-mailbox node used in
+      the firmware image.
+
+  clocks:
+    description: |
+      Main functional clock for the remote processor
+
+  resets:
+    description: |
+      Reset handles for the remote processor
+
+  memory-region:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: |
+      phandle to the reserved memory node to be associated
+      with the remoteproc device. The reserved memory node
+      can be a CMA memory node, and should be defined as
+      per the bindings,
+      Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+
+  firmware-name:
+    description: |
+      Default name of the firmware to load to the remote processor.
+
+# Optional properties:
+# --------------------
+# Some of these properties are mandatory on some SoCs, and some are optional
+# depending on the configuration of the firmware image to be executed on the
+# remote processor. The conditions are mentioned for each property.
+#
+# The following are the optional properties:
+
+  reg:
+    description: |
+      Address space for any remoteproc memories present on
+      the SoC. Should contain an entry for each value in
+      'reg-names'. These are mandatory for all DSP and IPU
+      processors that have them (OMAP4/OMAP5 DSPs do not have
+      any RAMs)
+
+  reg-names:
+    description: |
+      Required names for each of the address spaces defined in
+      the 'reg' property. Should contain a string from among
+      the following names, each representing the corresponding
+      internal RAM memory region.
+    minItems: 1
+    maxItems: 3
+    items:
+      - const: l2ram
+      - const: l1pram
+      - const: l1dram
+
+  ti,bootreg:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description: |
+      Should be a pair of the phandle to the System Control
+      Configuration region that contains the boot address
+      register, and the register offset of the boot address
+      register within the System Control module. This property
+      is required for all the DSP instances on OMAP4, OMAP5
+      and DRA7xx SoCs.
+
+  ti,timers:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description: |
+      One or more phandles to OMAP DMTimer nodes, that serve
+      as System/Tick timers for the OS running on the remote
+      processors. This will usually be a single timer if the
+      processor sub-system is running in SMP mode, or one per
+      core in the processor sub-system. This can also be used
+      to reserve specific timers to be dedicated to the
+      remote processors.
+
+      This property is mandatory on remote processors requiring
+      external tick wakeup, and to support Power Management
+      features. The timers to be used should match with the
+      timers used in the firmware image.
+
+  ti,watchdog-timers:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description: |
+      One or more phandles to OMAP DMTimer nodes, used to
+      serve as Watchdog timers for the processor cores. This
+      will usually be one per executing processor core, even
+      if the processor sub-system is running a SMP OS.
+
+      The timers to be used should match with the watchdog
+      timers used in the firmware image.
+
+if:
+  properties:
+    compatible:
+      enum:
+        - ti,dra7-dsp
+then:
+  properties:
+    reg:
+      minItems: 3
+      maxItems: 3
+    ti,bootreg:
+      minItems: 1
+      maxItems: 1
+
+else:
+  if:
+    properties:
+      compatible:
+        enum:
+          - ti,omap4-ipu
+          - ti,omap5-ipu
+          - ti,dra7-ipu
+  then:
+    properties:
+      reg:
+        minItems: 1
+        maxItems: 1
+
+  else:
+    properties:
+      reg:
+        maxItems: 0
+      ti,bootreg:
+        minItems: 1
+        maxItems: 1
+
+required:
+  - compatible
+  - iommus
+  - mboxes
+  - memory-region
+  - clocks
+  - resets
+  - firmware-name
+
+additionalProperties: false
+
+examples:
+  - |
+
+    //Example 1: OMAP4 DSP
+
+    /* DSP Reserved Memory node */
+    #include <dt-bindings/clock/omap4.h>
+    reserved-memory {
+        #address-cells = <1>;
+        #size-cells = <1>;
+
+        dsp_memory_region: dsp-memory@98000000 {
+            compatible = "shared-dma-pool";
+            reg = <0x98000000 0x800000>;
+            reusable;
+        };
+    };
+
+    /* DSP node */
+    ocp {
+        dsp: dsp {
+            compatible = "ti,omap4-dsp";
+            ti,bootreg = <&scm_conf 0x304>;
+            iommus = <&mmu_dsp>;
+            mboxes = <&mailbox &mbox_dsp>;
+            memory-region = <&dsp_memory_region>;
+            ti,timers = <&timer5>;
+            ti,watchdog-timers = <&timer6>;
+            clocks = <&tesla_clkctrl OMAP4_DSP_CLKCTRL 0>;
+            resets = <&prm_tesla 0>, <&prm_tesla 1>;
+            firmware-name = "omap4-dsp-fw.xe64T";
+        };
+    };
+
+  - |+
+
+    //Example 2: OMAP5 IPU
+
+    /* IPU Reserved Memory node */
+    #include <dt-bindings/clock/omap5.h>
+    reserved-memory {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        ipu_memory_region: ipu-memory@95800000 {
+            compatible = "shared-dma-pool";
+            reg = <0 0x95800000 0 0x3800000>;
+            reusable;
+        };
+    };
+
+    /* IPU node */
+    ocp {
+        #address-cells = <1>;
+        #size-cells = <1>;
+
+        ipu: ipu@55020000 {
+            compatible = "ti,omap5-ipu";
+            reg = <0x55020000 0x10000>;
+            reg-names = "l2ram";
+            iommus = <&mmu_ipu>;
+            mboxes = <&mailbox &mbox_ipu>;
+            memory-region = <&ipu_memory_region>;
+            ti,timers = <&timer3>, <&timer4>;
+            ti,watchdog-timers = <&timer9>, <&timer11>;
+            clocks = <&ipu_clkctrl OMAP5_MMU_IPU_CLKCTRL 0>;
+            resets = <&prm_core 2>;
+            firmware-name = "omap5-ipu-fw.xem";
+        };
+    };
+
+  - |+
+
+    //Example 3: DRA7xx/AM57xx DSP
+
+    /* DSP1 Reserved Memory node */
+    #include <dt-bindings/clock/dra7.h>
+    reserved-memory {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        dsp1_memory_region: dsp1-memory@99000000 {
+            compatible = "shared-dma-pool";
+            reg = <0x0 0x99000000 0x0 0x4000000>;
+            reusable;
+        };
+    };
+
+    /* DSP1 node */
+    ocp {
+        #address-cells = <1>;
+        #size-cells = <1>;
+
+        dsp1: dsp@40800000 {
+            compatible = "ti,dra7-dsp";
+            reg = <0x40800000 0x48000>,
+                  <0x40e00000 0x8000>,
+                  <0x40f00000 0x8000>;
+            reg-names = "l2ram", "l1pram", "l1dram";
+            ti,bootreg = <&scm_conf 0x55c>;
+            iommus = <&mmu0_dsp1>, <&mmu1_dsp1>;
+            mboxes = <&mailbox5 &mbox_dsp1_ipc3x>;
+            memory-region = <&dsp1_memory_region>;
+            ti,timers = <&timer5>;
+            ti,watchdog-timers = <&timer10>;
+            resets = <&prm_dsp1 0>;
+            clocks = <&dsp1_clkctrl DRA7_DSP1_MMU0_DSP1_CLKCTRL 0>;
+            firmware-name = "dra7-dsp1-fw.xe66";
+        };
+    };
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 02/15] remoteproc/omap: Add device tree support
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
  2019-12-13 12:55 ` [PATCHv3 01/15] dt-bindings: remoteproc: Add OMAP remoteproc bindings Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-17 23:01   ` Mathieu Poirier
  2019-12-13 12:55 ` [PATCHv3 03/15] remoteproc/omap: Add a sanity check for DSP boot address alignment Tero Kristo
                   ` (12 subsequent siblings)
  14 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna,
	Tony Lindgren, Tero Kristo

From: Suman Anna <s-anna@ti.com>

OMAP4+ SoCs support device tree boot only. The OMAP remoteproc
driver is enhanced to support remoteproc devices created through
Device Tree, support for legacy platform devices has been
deprecated. The current DT support handles the IPU and DSP
processor subsystems on OMAP4 and OMAP5 SoCs.

The OMAP remoteproc driver relies on the ti-sysc, reset, and
syscon layers for performing clock, reset and boot vector
management (DSP remoteprocs only) of the devices, but some of
these are limited only to the machine-specific layers
in arch/arm. The dependency against control module API for boot
vector management of the DSP remoteprocs has now been removed
with added logic to parse the boot register from the DT node
and program it appropriately directly within the driver.

The OMAP remoteproc driver expects the firmware names to be
provided via device tree entries (firmware-name.) These are used
to load the proper firmware during boot of the remote processor.

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc framework]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 drivers/remoteproc/omap_remoteproc.c | 191 +++++++++++++++++++++++----
 1 file changed, 168 insertions(+), 23 deletions(-)

diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 6398194075aa..558634624590 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -2,7 +2,7 @@
 /*
  * OMAP Remote Processor driver
  *
- * Copyright (C) 2011 Texas Instruments, Inc.
+ * Copyright (C) 2011-2019 Texas Instruments Incorporated - http://www.ti.com/
  * Copyright (C) 2011 Google, Inc.
  *
  * Ohad Ben-Cohen <ohad@wizery.com>
@@ -16,27 +16,53 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/err.h>
+#include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
 #include <linux/remoteproc.h>
 #include <linux/mailbox_client.h>
 #include <linux/omap-mailbox.h>
-
-#include <linux/platform_data/remoteproc-omap.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/reset.h>
 
 #include "omap_remoteproc.h"
 #include "remoteproc_internal.h"
 
+/**
+ * struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
+ * @syscon: regmap handle for the system control configuration module
+ * @boot_reg: boot register offset within the @syscon regmap
+ */
+struct omap_rproc_boot_data {
+	struct regmap *syscon;
+	unsigned int boot_reg;
+};
+
 /**
  * struct omap_rproc - omap remote processor state
  * @mbox: mailbox channel handle
  * @client: mailbox client to request the mailbox channel
+ * @boot_data: boot data structure for setting processor boot address
  * @rproc: rproc handle
+ * @reset: reset handle
  */
 struct omap_rproc {
 	struct mbox_chan *mbox;
 	struct mbox_client client;
+	struct omap_rproc_boot_data *boot_data;
 	struct rproc *rproc;
+	struct reset_control *reset;
+};
+
+/**
+ * struct omap_rproc_dev_data - device data for the omap remote processor
+ * @device_name: device name of the remote processor
+ * @has_bootreg: true if this remote processor has boot register
+ */
+struct omap_rproc_dev_data {
+	const char *device_name;
+	bool has_bootreg;
 };
 
 /**
@@ -92,6 +118,21 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
 			ret);
 }
 
+/**
+ * omap_rproc_write_dsp_boot_addr - set boot address for a DSP remote processor
+ * @rproc: handle of a remote processor
+ *
+ * Set boot address for a supported DSP remote processor.
+ */
+static void omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
+{
+	struct omap_rproc *oproc = rproc->priv;
+	struct omap_rproc_boot_data *bdata = oproc->boot_data;
+	u32 offset = bdata->boot_reg;
+
+	regmap_write(bdata->syscon, offset, rproc->bootaddr);
+}
+
 /*
  * Power up the remote processor.
  *
@@ -103,13 +144,11 @@ static int omap_rproc_start(struct rproc *rproc)
 {
 	struct omap_rproc *oproc = rproc->priv;
 	struct device *dev = rproc->dev.parent;
-	struct platform_device *pdev = to_platform_device(dev);
-	struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
 	int ret;
 	struct mbox_client *client = &oproc->client;
 
-	if (pdata->set_bootaddr)
-		pdata->set_bootaddr(rproc->bootaddr);
+	if (oproc->boot_data)
+		omap_rproc_write_dsp_boot_addr(rproc);
 
 	client->dev = dev;
 	client->tx_done = NULL;
@@ -117,7 +156,7 @@ static int omap_rproc_start(struct rproc *rproc)
 	client->tx_block = false;
 	client->knows_txdone = false;
 
-	oproc->mbox = omap_mbox_request_channel(client, pdata->mbox_name);
+	oproc->mbox = mbox_request_channel(client, 0);
 	if (IS_ERR(oproc->mbox)) {
 		ret = -EBUSY;
 		dev_err(dev, "mbox_request_channel failed: %ld\n",
@@ -138,11 +177,7 @@ static int omap_rproc_start(struct rproc *rproc)
 		goto put_mbox;
 	}
 
-	ret = pdata->device_enable(pdev);
-	if (ret) {
-		dev_err(dev, "omap_device_enable failed: %d\n", ret);
-		goto put_mbox;
-	}
+	reset_control_deassert(oproc->reset);
 
 	return 0;
 
@@ -154,15 +189,9 @@ static int omap_rproc_start(struct rproc *rproc)
 /* power off the remote processor */
 static int omap_rproc_stop(struct rproc *rproc)
 {
-	struct device *dev = rproc->dev.parent;
-	struct platform_device *pdev = to_platform_device(dev);
-	struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
 	struct omap_rproc *oproc = rproc->priv;
-	int ret;
 
-	ret = pdata->device_shutdown(pdev);
-	if (ret)
-		return ret;
+	reset_control_assert(oproc->reset);
 
 	mbox_free_channel(oproc->mbox);
 
@@ -175,12 +204,122 @@ static const struct rproc_ops omap_rproc_ops = {
 	.kick		= omap_rproc_kick,
 };
 
+static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
+	.device_name	= "dsp",
+	.has_bootreg	= true,
+};
+
+static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
+	.device_name	= "ipu",
+};
+
+static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
+	.device_name	= "dsp",
+	.has_bootreg	= true,
+};
+
+static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
+	.device_name	= "ipu",
+};
+
+static const struct of_device_id omap_rproc_of_match[] = {
+	{
+		.compatible     = "ti,omap4-dsp",
+		.data           = &omap4_dsp_dev_data,
+	},
+	{
+		.compatible     = "ti,omap4-ipu",
+		.data           = &omap4_ipu_dev_data,
+	},
+	{
+		.compatible     = "ti,omap5-dsp",
+		.data           = &omap5_dsp_dev_data,
+	},
+	{
+		.compatible     = "ti,omap5-ipu",
+		.data           = &omap5_ipu_dev_data,
+	},
+	{
+		/* end */
+	},
+};
+MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
+
+static const char *omap_rproc_get_firmware(struct platform_device *pdev)
+{
+	const char *fw_name;
+	int ret;
+
+	ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
+				      &fw_name);
+	if (ret)
+		return ERR_PTR(ret);
+
+	return fw_name;
+}
+
+static int omap_rproc_get_boot_data(struct platform_device *pdev,
+				    struct rproc *rproc)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct omap_rproc *oproc = rproc->priv;
+	const struct omap_rproc_dev_data *data;
+	int ret;
+
+	data = of_device_get_match_data(&pdev->dev);
+	if (!data)
+		return -ENODEV;
+
+	if (!data->has_bootreg)
+		return 0;
+
+	oproc->boot_data = devm_kzalloc(&pdev->dev, sizeof(*oproc->boot_data),
+					GFP_KERNEL);
+	if (!oproc->boot_data)
+		return -ENOMEM;
+
+	if (!of_property_read_bool(np, "ti,bootreg")) {
+		dev_err(&pdev->dev, "ti,bootreg property is missing\n");
+		return -EINVAL;
+	}
+
+	oproc->boot_data->syscon =
+			syscon_regmap_lookup_by_phandle(np, "ti,bootreg");
+	if (IS_ERR(oproc->boot_data->syscon)) {
+		ret = PTR_ERR(oproc->boot_data->syscon);
+		return ret;
+	}
+
+	if (of_property_read_u32_index(np, "ti,bootreg", 1,
+				       &oproc->boot_data->boot_reg)) {
+		dev_err(&pdev->dev, "couldn't get the boot register\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 static int omap_rproc_probe(struct platform_device *pdev)
 {
-	struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
+	struct device_node *np = pdev->dev.of_node;
 	struct omap_rproc *oproc;
 	struct rproc *rproc;
+	const char *firmware;
 	int ret;
+	struct reset_control *reset;
+
+	if (!np) {
+		dev_err(&pdev->dev, "only DT-based devices are supported\n");
+		return -ENODEV;
+	}
+
+	reset = devm_reset_control_array_get_optional_exclusive(&pdev->dev);
+	if (IS_ERR(reset))
+		return PTR_ERR(reset);
+
+	firmware = omap_rproc_get_firmware(pdev);
+	if (IS_ERR(firmware))
+		return PTR_ERR(firmware);
 
 	ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
 	if (ret) {
@@ -188,16 +327,21 @@ static int omap_rproc_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	rproc = rproc_alloc(&pdev->dev, pdata->name, &omap_rproc_ops,
-			    pdata->firmware, sizeof(*oproc));
+	rproc = rproc_alloc(&pdev->dev, dev_name(&pdev->dev), &omap_rproc_ops,
+			    firmware, sizeof(*oproc));
 	if (!rproc)
 		return -ENOMEM;
 
 	oproc = rproc->priv;
 	oproc->rproc = rproc;
+	oproc->reset = reset;
 	/* All existing OMAP IPU and DSP processors have an MMU */
 	rproc->has_iommu = true;
 
+	ret = omap_rproc_get_boot_data(pdev, rproc);
+	if (ret)
+		goto free_rproc;
+
 	platform_set_drvdata(pdev, rproc);
 
 	ret = rproc_add(rproc);
@@ -226,6 +370,7 @@ static struct platform_driver omap_rproc_driver = {
 	.remove = omap_rproc_remove,
 	.driver = {
 		.name = "omap-rproc",
+		.of_match_table = omap_rproc_of_match,
 	},
 };
 
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 03/15] remoteproc/omap: Add a sanity check for DSP boot address alignment
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
  2019-12-13 12:55 ` [PATCHv3 01/15] dt-bindings: remoteproc: Add OMAP remoteproc bindings Tero Kristo
  2019-12-13 12:55 ` [PATCHv3 02/15] remoteproc/omap: Add device tree support Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-13 12:55 ` [PATCHv3 04/15] remoteproc/omap: Add support to parse internal memories from DT Tero Kristo
                   ` (11 subsequent siblings)
  14 siblings, 0 replies; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

The DSP remote processors on OMAP SoCs require a boot register to
be programmed with a boot address, and this boot address needs to
be on a 1KB boundary. The current code is simply masking the boot
address appropriately without performing any sanity checks before
releasing the resets. An unaligned boot address results in an
undefined execution behavior and can result in various bus errors
like MMU Faults or L3 NoC errors. Such errors are hard to debug and
can be easily avoided by adding a sanity check for the alignment
before booting a DSP remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 drivers/remoteproc/omap_remoteproc.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 558634624590..d80f5d7b5931 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -124,13 +124,22 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
  *
  * Set boot address for a supported DSP remote processor.
  */
-static void omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
+static int omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
 {
+	struct device *dev = rproc->dev.parent;
 	struct omap_rproc *oproc = rproc->priv;
 	struct omap_rproc_boot_data *bdata = oproc->boot_data;
 	u32 offset = bdata->boot_reg;
 
+	if (rproc->bootaddr & (SZ_1K - 1)) {
+		dev_err(dev, "invalid boot address 0x%x, must be aligned on a 1KB boundary\n",
+			rproc->bootaddr);
+		return -EINVAL;
+	}
+
 	regmap_write(bdata->syscon, offset, rproc->bootaddr);
+
+	return 0;
 }
 
 /*
@@ -147,8 +156,11 @@ static int omap_rproc_start(struct rproc *rproc)
 	int ret;
 	struct mbox_client *client = &oproc->client;
 
-	if (oproc->boot_data)
-		omap_rproc_write_dsp_boot_addr(rproc);
+	if (oproc->boot_data) {
+		ret = omap_rproc_write_dsp_boot_addr(rproc);
+		if (ret)
+			return ret;
+	}
 
 	client->dev = dev;
 	client->tx_done = NULL;
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 04/15] remoteproc/omap: Add support to parse internal memories from DT
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (2 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 03/15] remoteproc/omap: Add a sanity check for DSP boot address alignment Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-18  0:22   ` Mathieu Poirier
  2019-12-13 12:55 ` [PATCHv3 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation Tero Kristo
                   ` (10 subsequent siblings)
  14 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

The OMAP remoteproc driver has been enhanced to parse and store
the kernel mappings for different internal RAM memories that may
be present within each remote processor IP subsystem. Different
devices have varying memories present on current SoCs. The current
support handles the L2RAM for all IPU devices on OMAP4+ SoCs. The
DSPs on OMAP4/OMAP5 only have Unicaches and do not have any L1 or
L2 RAM memories.

IPUs are expected to have the L2RAM at a fixed device address of
0x20000000, based on the current limitations on Attribute MMU
configurations.

NOTE:
The current logic doesn't handle the parsing of memories for DRA7
remoteproc devices, and will be added alongside the DRA7 support.

Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo: converted to parse mem names / device addresses from pdata]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 drivers/remoteproc/omap_remoteproc.c | 86 ++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)

diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index d80f5d7b5931..844703507a74 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -39,11 +39,27 @@ struct omap_rproc_boot_data {
 	unsigned int boot_reg;
 };
 
+/*
+ * struct omap_rproc_mem - 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 of the memory region from DSP view
+ * @size: size of the memory region
+ */
+struct omap_rproc_mem {
+	void __iomem *cpu_addr;
+	phys_addr_t bus_addr;
+	u32 dev_addr;
+	size_t size;
+};
+
 /**
  * struct omap_rproc - omap remote processor state
  * @mbox: mailbox channel handle
  * @client: mailbox client to request the mailbox channel
  * @boot_data: boot data structure for setting processor boot address
+ * @mem: internal memory regions data
+ * @num_mems: number of internal memory regions
  * @rproc: rproc handle
  * @reset: reset handle
  */
@@ -51,6 +67,8 @@ struct omap_rproc {
 	struct mbox_chan *mbox;
 	struct mbox_client client;
 	struct omap_rproc_boot_data *boot_data;
+	struct omap_rproc_mem *mem;
+	int num_mems;
 	struct rproc *rproc;
 	struct reset_control *reset;
 };
@@ -59,10 +77,14 @@ struct omap_rproc {
  * struct omap_rproc_dev_data - device data for the omap remote processor
  * @device_name: device name of the remote processor
  * @has_bootreg: true if this remote processor has boot register
+ * @mem_names: memory names for this remote processor
+ * @dev_addrs: device addresses corresponding to the memory names
  */
 struct omap_rproc_dev_data {
 	const char *device_name;
 	bool has_bootreg;
+	const char * const *mem_names;
+	const u32 *dev_addrs;
 };
 
 /**
@@ -216,6 +238,14 @@ static const struct rproc_ops omap_rproc_ops = {
 	.kick		= omap_rproc_kick,
 };
 
+static const char * const ipu_mem_names[] = {
+	"l2ram", NULL
+};
+
+static const u32 ipu_dev_addrs[] = {
+	0x20000000,
+};
+
 static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
 	.device_name	= "dsp",
 	.has_bootreg	= true,
@@ -223,6 +253,8 @@ static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
 
 static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
 	.device_name	= "ipu",
+	.mem_names	= ipu_mem_names,
+	.dev_addrs	= ipu_dev_addrs,
 };
 
 static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
@@ -232,6 +264,8 @@ static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
 
 static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
 	.device_name	= "ipu",
+	.mem_names	= ipu_mem_names,
+	.dev_addrs	= ipu_dev_addrs,
 };
 
 static const struct of_device_id omap_rproc_of_match[] = {
@@ -311,6 +345,54 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev,
 	return 0;
 }
 
+static int omap_rproc_of_get_internal_memories(struct platform_device *pdev,
+					       struct rproc *rproc)
+{
+	struct omap_rproc *oproc = rproc->priv;
+	struct device *dev = &pdev->dev;
+	const struct omap_rproc_dev_data *data;
+	struct resource *res;
+	int num_mems;
+	int i;
+
+	data = of_device_get_match_data(&pdev->dev);
+	if (!data)
+		return -ENODEV;
+
+	if (!data->mem_names)
+		return 0;
+
+	for (num_mems = 0; data->mem_names[num_mems]; num_mems++)
+		;
+
+	oproc->mem = devm_kcalloc(dev, num_mems, sizeof(*oproc->mem),
+				  GFP_KERNEL);
+	if (!oproc->mem)
+		return -ENOMEM;
+
+	for (i = 0; i < num_mems; i++) {
+		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+						   data->mem_names[i]);
+		oproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
+		if (IS_ERR(oproc->mem[i].cpu_addr)) {
+			dev_err(dev, "failed to parse and map %s memory\n",
+				data->mem_names[i]);
+			return PTR_ERR(oproc->mem[i].cpu_addr);
+		}
+		oproc->mem[i].bus_addr = res->start;
+		oproc->mem[i].dev_addr = data->dev_addrs[i];
+		oproc->mem[i].size = resource_size(res);
+
+		dev_dbg(dev, "memory %8s: bus addr %pa size 0x%x va %p da 0x%x\n",
+			data->mem_names[i], &oproc->mem[i].bus_addr,
+			oproc->mem[i].size, oproc->mem[i].cpu_addr,
+			oproc->mem[i].dev_addr);
+	}
+	oproc->num_mems = num_mems;
+
+	return 0;
+}
+
 static int omap_rproc_probe(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
@@ -350,6 +432,10 @@ static int omap_rproc_probe(struct platform_device *pdev)
 	/* All existing OMAP IPU and DSP processors have an MMU */
 	rproc->has_iommu = true;
 
+	ret = omap_rproc_of_get_internal_memories(pdev, rproc);
+	if (ret)
+		goto free_rproc;
+
 	ret = omap_rproc_get_boot_data(pdev, rproc);
 	if (ret)
 		goto free_rproc;
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (3 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 04/15] remoteproc/omap: Add support to parse internal memories from DT Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-18  0:38   ` Mathieu Poirier
  2019-12-13 12:55 ` [PATCHv3 06/15] remoteproc/omap: Initialize and assign reserved memory node Tero Kristo
                   ` (9 subsequent siblings)
  14 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

An implementation for the rproc ops .da_to_va() has been added
that provides the address translation between device addresses
to kernel virtual addresses for internal RAMs present on that
particular remote processor device. The implementation provides
the translations based on the addresses parsed and stored during
the probe.

This ops gets invoked by the exported rproc_da_to_va() function
and allows the remoteproc core's ELF loader to be able to load
program data directly into the internal memories.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 drivers/remoteproc/omap_remoteproc.c | 39 ++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 844703507a74..28f14e24b389 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -232,10 +232,49 @@ static int omap_rproc_stop(struct rproc *rproc)
 	return 0;
 }
 
+/**
+ * omap_rproc_da_to_va() - internal memory translation helper
+ * @rproc: remote processor to apply the address translation for
+ * @da: device address to translate
+ * @len: length of the memory buffer
+ *
+ * Custom function implementing the rproc .da_to_va ops to provide address
+ * translation (device address to kernel virtual address) for internal RAMs
+ * present in a DSP or IPU device). The translated addresses can be used
+ * either by the remoteproc core for loading, or by any rpmsg bus drivers.
+ * Returns the translated virtual address in kernel memory space, or NULL
+ * in failure.
+ */
+static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+{
+	struct omap_rproc *oproc = rproc->priv;
+	int i;
+	u32 offset;
+
+	if (len <= 0)
+		return NULL;
+
+	if (!oproc->num_mems)
+		return NULL;
+
+	for (i = 0; i < oproc->num_mems; i++) {
+		if (da >= oproc->mem[i].dev_addr && da + len <=
+		    oproc->mem[i].dev_addr +  oproc->mem[i].size) {
+			offset = da -  oproc->mem[i].dev_addr;
+			/* __force to make sparse happy with type conversion */
+			return (__force void *)(oproc->mem[i].cpu_addr +
+						offset);
+		}
+	}
+
+	return NULL;
+}
+
 static const struct rproc_ops omap_rproc_ops = {
 	.start		= omap_rproc_start,
 	.stop		= omap_rproc_stop,
 	.kick		= omap_rproc_kick,
+	.da_to_va	= omap_rproc_da_to_va,
 };
 
 static const char * const ipu_mem_names[] = {
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 06/15] remoteproc/omap: Initialize and assign reserved memory node
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (4 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-13 12:55 ` [PATCHv3 07/15] remoteproc/omap: Add support for DRA7xx remote processors Tero Kristo
                   ` (8 subsequent siblings)
  14 siblings, 0 replies; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

The reserved memory nodes are not assigned to platform devices by
default in the driver core to avoid the lookup for every platform
device and incur a penalty as the real users are expected to be
only a few devices.

OMAP remoteproc devices fall into the above category and the OMAP
remoteproc driver _requires_ specific CMA pools to be assigned
for each device at the moment to align on the location of the
vrings and vring buffers in the RTOS-side firmware images. So,
use the of_reserved_mem_device_init/release() API appropriately
to assign the corresponding reserved memory region to the OMAP
remoteproc device. Note that only one region per device is
allowed by the framework.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 drivers/remoteproc/omap_remoteproc.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 28f14e24b389..3ad74c4b4071 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -17,6 +17,7 @@
 #include <linux/module.h>
 #include <linux/err.h>
 #include <linux/of_device.h>
+#include <linux/of_reserved_mem.h>
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
 #include <linux/remoteproc.h>
@@ -479,14 +480,22 @@ static int omap_rproc_probe(struct platform_device *pdev)
 	if (ret)
 		goto free_rproc;
 
+	ret = of_reserved_mem_device_init(&pdev->dev);
+	if (ret) {
+		dev_err(&pdev->dev, "device does not have specific CMA pool\n");
+		goto free_rproc;
+	}
+
 	platform_set_drvdata(pdev, rproc);
 
 	ret = rproc_add(rproc);
 	if (ret)
-		goto free_rproc;
+		goto release_mem;
 
 	return 0;
 
+release_mem:
+	of_reserved_mem_device_release(&pdev->dev);
 free_rproc:
 	rproc_free(rproc);
 	return ret;
@@ -498,6 +507,7 @@ static int omap_rproc_remove(struct platform_device *pdev)
 
 	rproc_del(rproc);
 	rproc_free(rproc);
+	of_reserved_mem_device_release(&pdev->dev);
 
 	return 0;
 }
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 07/15] remoteproc/omap: Add support for DRA7xx remote processors
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (5 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 06/15] remoteproc/omap: Initialize and assign reserved memory node Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-18 21:31   ` Mathieu Poirier
  2019-12-13 12:55 ` [PATCHv3 08/15] remoteproc/omap: Remove the unused fields from platform data Tero Kristo
                   ` (7 subsequent siblings)
  14 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems
for offloading different computation algorithms. The IPU processor
subsystem contains dual-core ARM Cortex-M4 processors, and is very
similar to those on OMAP5. The DSP processor subsystem is based on
the TI's standard TMS320C66x DSP CorePac core.

Support has been added to the OMAP remoteproc driver through new
DRA7xx specific compatibles for properly probing and booting all
the different processor subsystem instances on DRA7xx/AM57xx
SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX
is added to enable the driver to be built in DRA7xx-only configuration.

The DSP boot address programming needed enhancement for DRA7xx as the
boot register fields are different on DRA7 compared to OMAP4 and OMAP5
SoCs. The register on DRA7xx contains additional fields within the
register and the boot address bit-field is right-shifted by 10 bits.
The internal memory parsing logic has also been updated to compute
the device addresses for the L2 RAM for DSP devices using relative
addressing logic, and to parse two additional RAMs at L1 level - L1P
and L1D. This allows the remoteproc driver to support loading into
these regions for a small subset of firmware images requiring as
such. The most common usage would be to use the L1 programmable
RAMs as L1 Caches.

The firmware lookup logic also has to be adjusted for DRA7xx as
there are (can be) more than one instance of both the IPU and DSP
remote processors for the first time in OMAP4+ SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: moved address translation quirks to pdata]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 drivers/remoteproc/Kconfig           |  2 +-
 drivers/remoteproc/omap_remoteproc.c | 44 +++++++++++++++++++++++++++-
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 94afdde4bc9f..d6450d7fcf92 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -25,7 +25,7 @@ config IMX_REMOTEPROC
 
 config OMAP_REMOTEPROC
 	tristate "OMAP remoteproc support"
-	depends on ARCH_OMAP4 || SOC_OMAP5
+	depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX
 	depends on OMAP_IOMMU
 	select MAILBOX
 	select OMAP2PLUS_MBOX
diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 3ad74c4b4071..6cf7f0a9ba9a 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -34,10 +34,13 @@
  * struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
  * @syscon: regmap handle for the system control configuration module
  * @boot_reg: boot register offset within the @syscon regmap
+ * @boot_reg_shift: bit-field shift required for the boot address value in
+ *		    @boot_reg
  */
 struct omap_rproc_boot_data {
 	struct regmap *syscon;
 	unsigned int boot_reg;
+	unsigned int boot_reg_shift;
 };
 
 /*
@@ -78,12 +81,14 @@ struct omap_rproc {
  * struct omap_rproc_dev_data - device data for the omap remote processor
  * @device_name: device name of the remote processor
  * @has_bootreg: true if this remote processor has boot register
+ * @boot_reg_shift: bit shift for the boot register mask
  * @mem_names: memory names for this remote processor
  * @dev_addrs: device addresses corresponding to the memory names
  */
 struct omap_rproc_dev_data {
 	const char *device_name;
 	bool has_bootreg;
+	int boot_reg_shift;
 	const char * const *mem_names;
 	const u32 *dev_addrs;
 };
@@ -153,6 +158,8 @@ static int omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
 	struct omap_rproc *oproc = rproc->priv;
 	struct omap_rproc_boot_data *bdata = oproc->boot_data;
 	u32 offset = bdata->boot_reg;
+	u32 value;
+	u32 mask;
 
 	if (rproc->bootaddr & (SZ_1K - 1)) {
 		dev_err(dev, "invalid boot address 0x%x, must be aligned on a 1KB boundary\n",
@@ -160,7 +167,10 @@ static int omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
 		return -EINVAL;
 	}
 
-	regmap_write(bdata->syscon, offset, rproc->bootaddr);
+	value = rproc->bootaddr >> bdata->boot_reg_shift;
+	mask = ~(SZ_1K - 1) >> bdata->boot_reg_shift;
+
+	regmap_update_bits(bdata->syscon, offset, mask, value);
 
 	return 0;
 }
@@ -286,6 +296,14 @@ static const u32 ipu_dev_addrs[] = {
 	0x20000000,
 };
 
+static const char * const dra7_dsp_mem_names[] = {
+	"l2ram", "l1pram", "l1dram", NULL
+};
+
+static const u32 dra7_dsp_dev_addrs[] = {
+	0x800000, 0xe00000, 0xf00000,
+};
+
 static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
 	.device_name	= "dsp",
 	.has_bootreg	= true,
@@ -308,6 +326,20 @@ static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
 	.dev_addrs	= ipu_dev_addrs,
 };
 
+static const struct omap_rproc_dev_data dra7_dsp_dev_data = {
+	.device_name	= "dsp",
+	.has_bootreg	= true,
+	.boot_reg_shift	= 10,
+	.mem_names	= dra7_dsp_mem_names,
+	.dev_addrs	= dra7_dsp_dev_addrs,
+};
+
+static const struct omap_rproc_dev_data dra7_ipu_dev_data = {
+	.device_name	= "ipu",
+	.mem_names	= ipu_mem_names,
+	.dev_addrs	= ipu_dev_addrs,
+};
+
 static const struct of_device_id omap_rproc_of_match[] = {
 	{
 		.compatible     = "ti,omap4-dsp",
@@ -325,6 +357,14 @@ static const struct of_device_id omap_rproc_of_match[] = {
 		.compatible     = "ti,omap5-ipu",
 		.data           = &omap5_ipu_dev_data,
 	},
+	{
+		.compatible     = "ti,dra7-dsp",
+		.data           = &dra7_dsp_dev_data,
+	},
+	{
+		.compatible     = "ti,dra7-ipu",
+		.data           = &dra7_ipu_dev_data,
+	},
 	{
 		/* end */
 	},
@@ -382,6 +422,8 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev,
 		return -EINVAL;
 	}
 
+	oproc->boot_data->boot_reg_shift = data->boot_reg_shift;
+
 	return 0;
 }
 
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 08/15] remoteproc/omap: Remove the unused fields from platform data
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (6 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 07/15] remoteproc/omap: Add support for DRA7xx remote processors Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-20  2:44   ` Suman Anna
  2019-12-13 12:55 ` [PATCHv3 09/15] remoteproc/omap: Remove the omap_rproc_reserve_cma declaration Tero Kristo
                   ` (6 subsequent siblings)
  14 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

The following fields: .name, .oh_name, .oh_name_opt, .mbox_name,
.firmware, .ops and .set_bootaddr, are removed from the platform data,
as these are no longer needed after the addition of DT support to the
OMAP remoteproc driver.

The .name field was used to give a name to the remoteproc, and this
is replaced with the device name. The .ops field was never used by
the OMAP remoteproc driver. The .mbox_name was used to define the
sub-mailbox node used for communication with the remote processor,
and is retrieved using the 'mboxes' property in the DT node. The
.firmware field is encoded directly in the OMAP remoteproc driver and
is retrieved using driver match data. The .set_bootaddr ops was used
for using a OMAP Control Module API to configure the boot address for
the processor, and is now implemented within the driver using a
syscon property.

The .oh_name field is used to define the primary hwmod for the processor
node, and is represented using the 'ti,hwmods' property in the DT node.
The .oh_name_opt field was primarily defined to identify the hwmod for
the second cpu in a dual Cortex-M3/M4 IPU processor sub-system. This
hwmod entry is no longer defined usually, but rather a single hwmod
representing both the processors in the IPU sub-system is defined.
A single firmware image (either in SMP-mode or a combined image for
non-SMP mode) is used, with both the resets released together always
as part of the device management. Any power management and recovery
aspects require that both the processors be managed as one entity due
to the presence of shared MMU and unicache within the IPU sub-system.

The OMAP remoteproc platform data structure is eventually expected
to be removed completely once the other dependencies with the
mach-omap layer are met.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 include/linux/platform_data/remoteproc-omap.h | 17 +----------------
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/include/linux/platform_data/remoteproc-omap.h b/include/linux/platform_data/remoteproc-omap.h
index 7e3a16097672..6bea01e199fe 100644
--- a/include/linux/platform_data/remoteproc-omap.h
+++ b/include/linux/platform_data/remoteproc-omap.h
@@ -2,38 +2,23 @@
 /*
  * Remote Processor - omap-specific bits
  *
- * Copyright (C) 2011 Texas Instruments, Inc.
+ * Copyright (C) 2011-2018 Texas Instruments Incorporated - http://www.ti.com/
  * Copyright (C) 2011 Google, Inc.
  */
 
 #ifndef _PLAT_REMOTEPROC_H
 #define _PLAT_REMOTEPROC_H
 
-struct rproc_ops;
 struct platform_device;
 
 /*
  * struct omap_rproc_pdata - omap remoteproc's platform data
- * @name: the remoteproc's name
- * @oh_name: omap hwmod device
- * @oh_name_opt: optional, secondary omap hwmod device
- * @firmware: name of firmware file to load
- * @mbox_name: name of omap mailbox device to use with this rproc
- * @ops: start/stop rproc handlers
  * @device_enable: omap-specific handler for enabling a device
  * @device_shutdown: omap-specific handler for shutting down a device
- * @set_bootaddr: omap-specific handler for setting the rproc boot address
  */
 struct omap_rproc_pdata {
-	const char *name;
-	const char *oh_name;
-	const char *oh_name_opt;
-	const char *firmware;
-	const char *mbox_name;
-	const struct rproc_ops *ops;
 	int (*device_enable)(struct platform_device *pdev);
 	int (*device_shutdown)(struct platform_device *pdev);
-	void (*set_bootaddr)(u32);
 };
 
 #if defined(CONFIG_OMAP_REMOTEPROC) || defined(CONFIG_OMAP_REMOTEPROC_MODULE)
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 09/15] remoteproc/omap: Remove the omap_rproc_reserve_cma declaration
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (7 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 08/15] remoteproc/omap: Remove the unused fields from platform data Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-20  2:47   ` Suman Anna
  2019-12-13 12:55 ` [PATCHv3 10/15] remoteproc/omap: Check for undefined mailbox messages Tero Kristo
                   ` (5 subsequent siblings)
  14 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

The omap_rproc_reserve_cma() function is not defined at the moment.
This prototype was to be used to define a function to declare a
remoteproc device-specific CMA pool.

The remoteproc devices will be defined through DT going forward. A
device specific CMA pool will be defined under the reserved-memory
node, and will be associated with the appropriate remoteproc device
node. This function prototype will no longer be needed and has
therefore been cleaned up.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 include/linux/platform_data/remoteproc-omap.h | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/include/linux/platform_data/remoteproc-omap.h b/include/linux/platform_data/remoteproc-omap.h
index 6bea01e199fe..49c78805916f 100644
--- a/include/linux/platform_data/remoteproc-omap.h
+++ b/include/linux/platform_data/remoteproc-omap.h
@@ -21,16 +21,4 @@ struct omap_rproc_pdata {
 	int (*device_shutdown)(struct platform_device *pdev);
 };
 
-#if defined(CONFIG_OMAP_REMOTEPROC) || defined(CONFIG_OMAP_REMOTEPROC_MODULE)
-
-void __init omap_rproc_reserve_cma(void);
-
-#else
-
-static inline void __init omap_rproc_reserve_cma(void)
-{
-}
-
-#endif
-
 #endif /* _PLAT_REMOTEPROC_H */
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 10/15] remoteproc/omap: Check for undefined mailbox messages
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (8 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 09/15] remoteproc/omap: Remove the omap_rproc_reserve_cma declaration Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-13 12:55 ` [PATCHv3 11/15] remoteproc/omap: Request a timer(s) for remoteproc usage Tero Kristo
                   ` (4 subsequent siblings)
  14 siblings, 0 replies; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

Add some checks in the mailbox callback function to limit
any processing in the mailbox callback function to only
certain currently valid messages, and drop all the remaining
messages. A debug message is added to print any such invalid
messages when the appropriate trace control is enabled.

Co-developed-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 drivers/remoteproc/omap_remoteproc.c | 6 ++++++
 drivers/remoteproc/omap_remoteproc.h | 7 +++++++
 2 files changed, 13 insertions(+)

diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 6cf7f0a9ba9a..841981c50d8d 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -126,6 +126,12 @@ static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
 		dev_info(dev, "received echo reply from %s\n", name);
 		break;
 	default:
+		if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
+			return;
+		if (msg > oproc->rproc->max_notifyid) {
+			dev_dbg(dev, "dropping unknown message 0x%x", msg);
+			return;
+		}
 		/* msg contains the index of the triggered vring */
 		if (rproc_vq_interrupt(oproc->rproc, msg) == IRQ_NONE)
 			dev_dbg(dev, "no message was found in vqid %d\n", msg);
diff --git a/drivers/remoteproc/omap_remoteproc.h b/drivers/remoteproc/omap_remoteproc.h
index f6d2036d383d..72f656c93caa 100644
--- a/drivers/remoteproc/omap_remoteproc.h
+++ b/drivers/remoteproc/omap_remoteproc.h
@@ -56,6 +56,12 @@
  *
  * @RP_MBOX_ABORT_REQUEST: a "please crash" request, used for testing the
  * recovery mechanism (to some extent).
+ *
+ * Introduce new message definitions if any here.
+ *
+ * @RP_MBOX_END_MSG: Indicates end of known/defined messages from remote core
+ * This should be the last definition.
+ *
  */
 enum omap_rp_mbox_messages {
 	RP_MBOX_READY		= 0xFFFFFF00,
@@ -64,6 +70,7 @@ enum omap_rp_mbox_messages {
 	RP_MBOX_ECHO_REQUEST	= 0xFFFFFF03,
 	RP_MBOX_ECHO_REPLY	= 0xFFFFFF04,
 	RP_MBOX_ABORT_REQUEST	= 0xFFFFFF05,
+	RP_MBOX_END_MSG		= 0xFFFFFF06,
 };
 
 #endif /* _OMAP_RPMSG_H */
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 11/15] remoteproc/omap: Request a timer(s) for remoteproc usage
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (9 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 10/15] remoteproc/omap: Check for undefined mailbox messages Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-18 22:43   ` Mathieu Poirier
  2019-12-13 12:55 ` [PATCHv3 12/15] remoteproc/omap: add support for system suspend/resume Tero Kristo
                   ` (3 subsequent siblings)
  14 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

The remote processors in OMAP4+ SoCs are equipped with internal
timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or
the CTM timer within Unicache in IPU & DSP. However, these timers
are gated when the processor subsystem clock is gated, making
them rather difficult to use as OS tick sources. They will not
be able to wakeup the processor from any processor-sleep induced
clock-gating states.

This can be avoided by using an external timer as the tick source,
which can be controlled independently by the OMAP remoteproc
driver code, but still allowing the processor subsystem clock to
be auto-gated when the remoteproc cores are idle.

This patch adds the support for OMAP remote processors to request
timer(s) to be used by the remoteproc. The timers are enabled and
disabled in line with the enabling/disabling of the remoteproc.
The timer data is not mandatory if the advanced device management
features are not required.

The core timer functionality is provided by the OMAP DMTimer
clocksource driver, which does not export any API. The logic is
implemented through the timer device's platform data ops. The OMAP
remoteproc driver mainly requires ops to request/free a dmtimer,
and to start/stop a timer. The split ops helps in controlling the
timer state without having to request and release a timer everytime
it needs to use the timer.

NOTE: If the gptimer is already in use by the time IPU and/or
DSP are loaded, the processors will fail to boot.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 drivers/remoteproc/omap_remoteproc.c | 258 +++++++++++++++++++++++++++
 1 file changed, 258 insertions(+)

diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 841981c50d8d..9c750c2ab29d 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -26,6 +26,9 @@
 #include <linux/regmap.h>
 #include <linux/mfd/syscon.h>
 #include <linux/reset.h>
+#include <clocksource/timer-ti-dm.h>
+
+#include <linux/platform_data/dmtimer-omap.h>
 
 #include "omap_remoteproc.h"
 #include "remoteproc_internal.h"
@@ -57,6 +60,16 @@ struct omap_rproc_mem {
 	size_t size;
 };
 
+/**
+ * struct omap_rproc_timer - data structure for a timer used by a omap rproc
+ * @odt: timer pointer
+ * @timer_ops: OMAP dmtimer ops for @odt timer
+ */
+struct omap_rproc_timer {
+	struct omap_dm_timer *odt;
+	const struct omap_dm_timer_ops *timer_ops;
+};
+
 /**
  * struct omap_rproc - omap remote processor state
  * @mbox: mailbox channel handle
@@ -64,6 +77,8 @@ struct omap_rproc_mem {
  * @boot_data: boot data structure for setting processor boot address
  * @mem: internal memory regions data
  * @num_mems: number of internal memory regions
+ * @num_timers: number of rproc timer(s)
+ * @timers: timer(s) info used by rproc
  * @rproc: rproc handle
  * @reset: reset handle
  */
@@ -73,6 +88,8 @@ struct omap_rproc {
 	struct omap_rproc_boot_data *boot_data;
 	struct omap_rproc_mem *mem;
 	int num_mems;
+	int num_timers;
+	struct omap_rproc_timer *timers;
 	struct rproc *rproc;
 	struct reset_control *reset;
 };
@@ -93,6 +110,213 @@ struct omap_rproc_dev_data {
 	const u32 *dev_addrs;
 };
 
+/**
+ * omap_rproc_request_timer() - request a timer for a remoteproc
+ * @dev: device requesting the timer
+ * @np: device node pointer to the desired timer
+ * @timer: handle to a struct omap_rproc_timer to return the timer handle
+ *
+ * This helper function is used primarily to request a timer associated with
+ * a remoteproc. The returned handle is stored in the .odt field of the
+ * @timer structure passed in, and is used to invoke other timer specific
+ * ops (like starting a timer either during device initialization or during
+ * a resume operation, or for stopping/freeing a timer).
+ *
+ * Returns 0 on success, otherwise an appropriate failure
+ */
+static int omap_rproc_request_timer(struct device *dev, struct device_node *np,
+				    struct omap_rproc_timer *timer)
+{
+	int ret;
+
+	timer->odt = timer->timer_ops->request_by_node(np);
+	if (!timer->odt) {
+		dev_err(dev, "request for timer node %p failed\n", np);
+		return -EBUSY;
+	}
+
+	ret = timer->timer_ops->set_source(timer->odt, OMAP_TIMER_SRC_SYS_CLK);
+	if (ret) {
+		dev_err(dev, "error setting OMAP_TIMER_SRC_SYS_CLK as source for timer node %p\n",
+			np);
+		timer->timer_ops->free(timer->odt);
+		return ret;
+	}
+
+	/* clean counter, remoteproc code will set the value */
+	timer->timer_ops->set_load(timer->odt, 0, 0);
+
+	return 0;
+}
+
+/**
+ * omap_rproc_start_timer - start a timer for a remoteproc
+ * @timer: handle to a OMAP rproc timer
+ *
+ * This helper function is used to start a timer associated with a remoteproc,
+ * obtained using the request_timer ops. The helper function needs to be
+ * invoked by the driver to start the timer (during device initialization)
+ * or to just resume the timer.
+ *
+ * Returns 0 on success, otherwise a failure as returned by DMTimer ops
+ */
+static inline int omap_rproc_start_timer(struct omap_rproc_timer *timer)
+{
+	return timer->timer_ops->start(timer->odt);
+}
+
+/**
+ * omap_rproc_stop_timer - stop a timer for a remoteproc
+ * @timer: handle to a OMAP rproc timer
+ *
+ * This helper function is used to disable a timer associated with a
+ * remoteproc, and needs to be called either during a device shutdown
+ * or suspend operation. The separate helper function allows the driver
+ * to just stop a timer without having to release the timer during a
+ * suspend operation.
+ *
+ * Returns 0 on success, otherwise a failure as returned by DMTimer ops
+ */
+static inline int omap_rproc_stop_timer(struct omap_rproc_timer *timer)
+{
+	return timer->timer_ops->stop(timer->odt);
+}
+
+/**
+ * omap_rproc_release_timer - release a timer for a remoteproc
+ * @timer: handle to a OMAP rproc timer
+ *
+ * This helper function is used primarily to release a timer associated
+ * with a remoteproc. The dmtimer will be available for other clients to
+ * use once released.
+ *
+ * Returns 0 on success, otherwise a failure as returned by DMTimer ops
+ */
+static inline int omap_rproc_release_timer(struct omap_rproc_timer *timer)
+{
+	return timer->timer_ops->free(timer->odt);
+}
+
+/**
+ * omap_rproc_enable_timers - enable the timers for a remoteproc
+ * @rproc: handle of a remote processor
+ * @configure: boolean flag used to acquire and configure the timer handle
+ *
+ * This function is used primarily to enable the timers associated with
+ * a remoteproc. The configure flag is provided to allow the driver to
+ * to either acquire and start a timer (during device initialization) or
+ * to just start a timer (during a resume operation).
+ */
+static int omap_rproc_enable_timers(struct rproc *rproc, bool configure)
+{
+	int i;
+	int ret = 0;
+	struct platform_device *tpdev;
+	struct dmtimer_platform_data *tpdata;
+	const struct omap_dm_timer_ops *timer_ops;
+	struct omap_rproc *oproc = rproc->priv;
+	struct omap_rproc_timer *timers = oproc->timers;
+	struct device *dev = rproc->dev.parent;
+	struct device_node *np = NULL;
+
+	if (oproc->num_timers <= 0)
+		return 0;
+
+	if (!configure)
+		goto start_timers;
+
+	for (i = 0; i < oproc->num_timers; i++) {
+		np = of_parse_phandle(dev->of_node, "ti,timers", i);
+		if (!np) {
+			ret = -ENXIO;
+			dev_err(dev, "device node lookup for timer at index %d failed: %d\n",
+				i, ret);
+			goto free_timers;
+		}
+
+		tpdev = of_find_device_by_node(np);
+		if (!tpdev) {
+			ret = -ENODEV;
+			dev_err(dev, "could not get timer platform device\n");
+			goto put_node;
+		}
+
+		tpdata = dev_get_platdata(&tpdev->dev);
+		put_device(&tpdev->dev);
+		if (!tpdata) {
+			ret = -EINVAL;
+			dev_err(dev, "dmtimer pdata structure NULL\n");
+			goto put_node;
+		}
+
+		timer_ops = tpdata->timer_ops;
+		if (!timer_ops || !timer_ops->request_by_node ||
+		    !timer_ops->set_source || !timer_ops->set_load ||
+		    !timer_ops->free || !timer_ops->start ||
+		    !timer_ops->stop) {
+			ret = -EINVAL;
+			dev_err(dev, "device does not have required timer ops\n");
+			goto put_node;
+		}
+
+		timers[i].timer_ops = timer_ops;
+		ret = omap_rproc_request_timer(dev, np, &timers[i]);
+		if (ret) {
+			dev_err(dev, "request for timer %p failed: %d\n", np,
+				ret);
+			goto put_node;
+		}
+		of_node_put(np);
+	}
+
+start_timers:
+	for (i = 0; i < oproc->num_timers; i++)
+		omap_rproc_start_timer(&timers[i]);
+	return 0;
+
+put_node:
+	of_node_put(np);
+free_timers:
+	while (i--) {
+		omap_rproc_release_timer(&timers[i]);
+		timers[i].odt = NULL;
+		timers[i].timer_ops = NULL;
+	}
+
+	return ret;
+}
+
+/**
+ * omap_rproc_disable_timers - disable the timers for a remoteproc
+ * @rproc: handle of a remote processor
+ * @configure: boolean flag used to release the timer handle
+ *
+ * This function is used primarily to disable the timers associated with
+ * a remoteproc. The configure flag is provided to allow the driver to
+ * to either stop and release a timer (during device shutdown) or to just
+ * stop a timer (during a suspend operation).
+ */
+static int omap_rproc_disable_timers(struct rproc *rproc, bool configure)
+{
+	int i;
+	struct omap_rproc *oproc = rproc->priv;
+	struct omap_rproc_timer *timers = oproc->timers;
+
+	if (oproc->num_timers <= 0)
+		return 0;
+
+	for (i = 0; i < oproc->num_timers; i++) {
+		omap_rproc_stop_timer(&timers[i]);
+		if (configure) {
+			omap_rproc_release_timer(&timers[i]);
+			timers[i].odt = NULL;
+			timers[i].timer_ops = NULL;
+		}
+	}
+
+	return 0;
+}
+
 /**
  * omap_rproc_mbox_callback() - inbound mailbox message handler
  * @client: mailbox client pointer used for requesting the mailbox channel
@@ -228,6 +452,12 @@ static int omap_rproc_start(struct rproc *rproc)
 		goto put_mbox;
 	}
 
+	ret = omap_rproc_enable_timers(rproc, true);
+	if (ret) {
+		dev_err(dev, "omap_rproc_enable_timers failed: %d\n", ret);
+		goto put_mbox;
+	}
+
 	reset_control_deassert(oproc->reset);
 
 	return 0;
@@ -241,9 +471,14 @@ static int omap_rproc_start(struct rproc *rproc)
 static int omap_rproc_stop(struct rproc *rproc)
 {
 	struct omap_rproc *oproc = rproc->priv;
+	int ret;
 
 	reset_control_assert(oproc->reset);
 
+	ret = omap_rproc_disable_timers(rproc, true);
+	if (ret)
+		return ret;
+
 	mbox_free_channel(oproc->mbox);
 
 	return 0;
@@ -528,6 +763,29 @@ static int omap_rproc_probe(struct platform_device *pdev)
 	if (ret)
 		goto free_rproc;
 
+	/*
+	 * Timer nodes are directly used in client nodes as phandles, so
+	 * retrieve the count using appropriate size
+	 */
+	oproc->num_timers = of_count_phandle_with_args(np, "ti,timers", NULL);
+	if (oproc->num_timers <= 0) {
+		dev_dbg(&pdev->dev, "device does not have timers, status = %d\n",
+			oproc->num_timers);
+		oproc->num_timers = 0;
+	}
+
+	if (oproc->num_timers) {
+		oproc->timers = devm_kzalloc(&pdev->dev, sizeof(*oproc->timers)
+					     * oproc->num_timers, GFP_KERNEL);
+		if (!oproc->timers) {
+			ret = -ENOMEM;
+			goto free_rproc;
+		}
+
+		dev_dbg(&pdev->dev, "device has %d tick timers\n",
+			oproc->num_timers);
+	}
+
 	ret = of_reserved_mem_device_init(&pdev->dev);
 	if (ret) {
 		dev_err(&pdev->dev, "device does not have specific CMA pool\n");
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 12/15] remoteproc/omap: add support for system suspend/resume
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (10 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 11/15] remoteproc/omap: Request a timer(s) for remoteproc usage Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-19 21:46   ` Mathieu Poirier
  2019-12-13 12:55 ` [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume Tero Kristo
                   ` (2 subsequent siblings)
  14 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.

The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.

The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.

The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.

The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.

Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 drivers/remoteproc/omap_remoteproc.c | 179 +++++++++++++++++++++++++++
 drivers/remoteproc/omap_remoteproc.h |  18 ++-
 2 files changed, 195 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 9c750c2ab29d..0a9b9f7d20da 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -16,6 +16,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/err.h>
+#include <linux/io.h>
 #include <linux/of_device.h>
 #include <linux/of_reserved_mem.h>
 #include <linux/platform_device.h>
@@ -23,10 +24,13 @@
 #include <linux/remoteproc.h>
 #include <linux/mailbox_client.h>
 #include <linux/omap-mailbox.h>
+#include <linux/omap-iommu.h>
 #include <linux/regmap.h>
 #include <linux/mfd/syscon.h>
 #include <linux/reset.h>
 #include <clocksource/timer-ti-dm.h>
+#include <linux/clk.h>
+#include <linux/clk/ti.h>
 
 #include <linux/platform_data/dmtimer-omap.h>
 
@@ -81,6 +85,9 @@ struct omap_rproc_timer {
  * @timers: timer(s) info used by rproc
  * @rproc: rproc handle
  * @reset: reset handle
+ * @pm_comp: completion primitive to sync for suspend response
+ * @fck: functional clock for the remoteproc
+ * @suspend_acked: state machine flag to store the suspend request ack
  */
 struct omap_rproc {
 	struct mbox_chan *mbox;
@@ -92,6 +99,9 @@ struct omap_rproc {
 	struct omap_rproc_timer *timers;
 	struct rproc *rproc;
 	struct reset_control *reset;
+	struct completion pm_comp;
+	struct clk *fck;
+	bool suspend_acked;
 };
 
 /**
@@ -349,6 +359,11 @@ static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
 	case RP_MBOX_ECHO_REPLY:
 		dev_info(dev, "received echo reply from %s\n", name);
 		break;
+	case RP_MBOX_SUSPEND_ACK:
+	case RP_MBOX_SUSPEND_CANCEL:
+		oproc->suspend_acked = msg == RP_MBOX_SUSPEND_ACK;
+		complete(&oproc->pm_comp);
+		break;
 	default:
 		if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
 			return;
@@ -529,6 +544,157 @@ static const struct rproc_ops omap_rproc_ops = {
 	.da_to_va	= omap_rproc_da_to_va,
 };
 
+#ifdef CONFIG_PM
+static bool _is_rproc_in_standby(struct omap_rproc *oproc)
+{
+	return ti_clk_is_in_standby(oproc->fck);
+}
+
+/* 1 sec is long enough time to let the remoteproc side suspend the device */
+#define DEF_SUSPEND_TIMEOUT 1000
+static int _omap_rproc_suspend(struct rproc *rproc)
+{
+	struct device *dev = rproc->dev.parent;
+	struct omap_rproc *oproc = rproc->priv;
+	unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
+	unsigned long ta = jiffies + to;
+	int ret;
+
+	reinit_completion(&oproc->pm_comp);
+	oproc->suspend_acked = false;
+	ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_SUSPEND_SYSTEM);
+	if (ret < 0) {
+		dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
+		return ret;
+	}
+
+	ret = wait_for_completion_timeout(&oproc->pm_comp, to);
+	if (!oproc->suspend_acked)
+		return -EBUSY;
+
+	/*
+	 * The remoteproc side is returning the ACK message before saving the
+	 * context, because the context saving is performed within a SYS/BIOS
+	 * function, and it cannot have any inter-dependencies against the IPC
+	 * layer. Also, as the SYS/BIOS needs to preserve properly the processor
+	 * register set, sending this ACK or signalling the completion of the
+	 * context save through a shared memory variable can never be the
+	 * absolute last thing to be executed on the remoteproc side, and the
+	 * MPU cannot use the ACK message as a sync point to put the remoteproc
+	 * into reset. The only way to ensure that the remote processor has
+	 * completed saving the context is to check that the module has reached
+	 * STANDBY state (after saving the context, the SYS/BIOS executes the
+	 * appropriate target-specific WFI instruction causing the module to
+	 * enter STANDBY).
+	 */
+	while (!_is_rproc_in_standby(oproc)) {
+		if (time_after(jiffies, ta))
+			return -ETIME;
+		schedule();
+	}
+
+	reset_control_assert(oproc->reset);
+
+	ret = omap_rproc_disable_timers(rproc, false);
+	if (ret) {
+		dev_err(dev, "disabling timers during suspend failed %d\n",
+			ret);
+		goto enable_device;
+	}
+
+	return 0;
+
+enable_device:
+	reset_control_deassert(oproc->reset);
+	return ret;
+}
+
+static int _omap_rproc_resume(struct rproc *rproc)
+{
+	struct device *dev = rproc->dev.parent;
+	struct omap_rproc *oproc = rproc->priv;
+	int ret;
+
+	/* boot address could be lost after suspend, so restore it */
+	if (oproc->boot_data) {
+		ret = omap_rproc_write_dsp_boot_addr(rproc);
+		if (ret) {
+			dev_err(dev, "boot address restore failed %d\n", ret);
+			goto out;
+		}
+	}
+
+	ret = omap_rproc_enable_timers(rproc, false);
+	if (ret) {
+		dev_err(dev, "enabling timers during resume failed %d\n",
+			ret);
+		goto out;
+	}
+
+	reset_control_deassert(oproc->reset);
+
+out:
+	return ret;
+}
+
+static int __maybe_unused omap_rproc_suspend(struct device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct rproc *rproc = platform_get_drvdata(pdev);
+	int ret = 0;
+
+	mutex_lock(&rproc->lock);
+	if (rproc->state == RPROC_OFFLINE)
+		goto out;
+
+	if (rproc->state == RPROC_SUSPENDED)
+		goto out;
+
+	if (rproc->state != RPROC_RUNNING) {
+		ret = -EBUSY;
+		goto out;
+	}
+
+	ret = _omap_rproc_suspend(rproc);
+	if (ret) {
+		dev_err(dev, "suspend failed %d\n", ret);
+		goto out;
+	}
+
+	rproc->state = RPROC_SUSPENDED;
+out:
+	mutex_unlock(&rproc->lock);
+	return ret;
+}
+
+static int __maybe_unused omap_rproc_resume(struct device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct rproc *rproc = platform_get_drvdata(pdev);
+	int ret = 0;
+
+	mutex_lock(&rproc->lock);
+	if (rproc->state == RPROC_OFFLINE)
+		goto out;
+
+	if (rproc->state != RPROC_SUSPENDED) {
+		ret = -EBUSY;
+		goto out;
+	}
+
+	ret = _omap_rproc_resume(rproc);
+	if (ret) {
+		dev_err(dev, "resume failed %d\n", ret);
+		goto out;
+	}
+
+	rproc->state = RPROC_RUNNING;
+out:
+	mutex_unlock(&rproc->lock);
+	return ret;
+}
+#endif /* CONFIG_PM */
+
 static const char * const ipu_mem_names[] = {
 	"l2ram", NULL
 };
@@ -786,6 +952,14 @@ static int omap_rproc_probe(struct platform_device *pdev)
 			oproc->num_timers);
 	}
 
+	init_completion(&oproc->pm_comp);
+
+	oproc->fck = devm_clk_get(&pdev->dev, 0);
+	if (IS_ERR(oproc->fck)) {
+		ret = PTR_ERR(oproc->fck);
+		goto free_rproc;
+	}
+
 	ret = of_reserved_mem_device_init(&pdev->dev);
 	if (ret) {
 		dev_err(&pdev->dev, "device does not have specific CMA pool\n");
@@ -818,11 +992,16 @@ static int omap_rproc_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct dev_pm_ops omap_rproc_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
+};
+
 static struct platform_driver omap_rproc_driver = {
 	.probe = omap_rproc_probe,
 	.remove = omap_rproc_remove,
 	.driver = {
 		.name = "omap-rproc",
+		.pm = &omap_rproc_pm_ops,
 		.of_match_table = omap_rproc_of_match,
 	},
 };
diff --git a/drivers/remoteproc/omap_remoteproc.h b/drivers/remoteproc/omap_remoteproc.h
index 72f656c93caa..c73383e707c7 100644
--- a/drivers/remoteproc/omap_remoteproc.h
+++ b/drivers/remoteproc/omap_remoteproc.h
@@ -1,7 +1,7 @@
 /*
  * Remote processor messaging
  *
- * Copyright (C) 2011 Texas Instruments, Inc.
+ * Copyright (C) 2011-2018 Texas Instruments, Inc.
  * Copyright (C) 2011 Google, Inc.
  * All rights reserved.
  *
@@ -57,6 +57,16 @@
  * @RP_MBOX_ABORT_REQUEST: a "please crash" request, used for testing the
  * recovery mechanism (to some extent).
  *
+ * @RP_MBOX_SUSPEND_AUTO: auto suspend request for the remote processor
+ *
+ * @RP_MBOX_SUSPEND_SYSTEM: system suspend request for the remote processor
+ *
+ * @RP_MBOX_SUSPEND_ACK: successful response from remote processor for a
+ * suspend request
+ *
+ * @RP_MBOX_SUSPEND_CANCEL: a cancel suspend response from a remote processor
+ * on a suspend request
+ *
  * Introduce new message definitions if any here.
  *
  * @RP_MBOX_END_MSG: Indicates end of known/defined messages from remote core
@@ -70,7 +80,11 @@ enum omap_rp_mbox_messages {
 	RP_MBOX_ECHO_REQUEST	= 0xFFFFFF03,
 	RP_MBOX_ECHO_REPLY	= 0xFFFFFF04,
 	RP_MBOX_ABORT_REQUEST	= 0xFFFFFF05,
-	RP_MBOX_END_MSG		= 0xFFFFFF06,
+	RP_MBOX_SUSPEND_AUTO	= 0xFFFFFF10,
+	RP_MBOX_SUSPEND_SYSTEM	= 0xFFFFFF11,
+	RP_MBOX_SUSPEND_ACK	= 0xFFFFFF12,
+	RP_MBOX_SUSPEND_CANCEL	= 0xFFFFFF13,
+	RP_MBOX_END_MSG		= 0xFFFFFF14,
 };
 
 #endif /* _OMAP_RPMSG_H */
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (11 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 12/15] remoteproc/omap: add support for system suspend/resume Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-19 23:43   ` Mathieu Poirier
  2019-12-13 12:55 ` [PATCHv3 14/15] remoteproc/omap: report device exceptions and trigger recovery Tero Kristo
  2019-12-13 12:55 ` [PATCHv3 15/15] remoteproc/omap: add watchdog functionality for remote processors Tero Kristo
  14 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

This patch enhances the PM support in the OMAP remoteproc driver to
support the runtime auto-suspend. A remoteproc may not be required to
be running all the time, and typically will need to be active only
during certain usecases. As such, to save power, it should be turned
off during potential long periods of inactivity between usecases.
This suspend and resume of the device is a relatively heavy process
in terms of latencies, so a remoteproc should be suspended only after
a certain period of prolonged inactivity. The OMAP remoteproc driver
leverages the runtime pm framework's auto_suspend feature to accomplish
this functionality. This feature is automatically enabled when a remote
processor has successfully booted. The 'autosuspend_delay_ms' for each
device dictates the inactivity period/time to wait for before
suspending the device.

The runtime auto-suspend design relies on marking the last busy time
on every communication (virtqueue kick) to and from the remote processor.
When there has been no activity for 'autosuspend_delay_ms' time, the
runtime PM framework invokes the driver's runtime pm suspend callback
to suspend the device. The remote processor will be woken up on the
initiation of the next communication message through the runtime pm
resume callback. The current auto-suspend design also allows a remote
processor to deny a auto-suspend attempt, if it wishes to, by sending a
NACK response to the initial suspend request message sent to the remote
processor as part of the suspend process. The auto-suspend request is
also only attempted if the remote processor is idled and in standby at
the time of inactivity timer expiry. This choice is made to avoid
unnecessary messaging, and the auto-suspend is simply rescheduled to
be attempted again after a further lapse of autosuspend_delay_ms.

The runtime pm callbacks functionality in this patch reuses most of the
core logic from the suspend/resume support code, and make use of an
additional auto_suspend flag to differentiate the logic in common code
from system suspend. The system suspend/resume sequences are also updated
to reflect the proper pm_runtime statuses, and also to really perform a
suspend/resume only if the remoteproc has not been auto-suspended at the
time of request. The remote processor is left in suspended state on a
system resume if it has been auto-suspended before, and will be woken up
only when a usecase needs to run. The other significant change in this
patch is to reset the remoteproc device's pm_domain so as to avoid
conflicts with the ordering sequences in the device pm_domain's runtime
callbacks and the reset management and clock management implemented
within the runtime callbacks in the driver.

The OMAP remoteproc driver currently uses a default value of 10 seconds
for all OMAP remoteprocs, and a different value can be chosen either by
choosing a positive value for the 'autosuspend_delay' in the device's
omap_rproc_fw_data in the driver match data or by updating the
'autosuspend_delay_ms' field at runtime through the sysfs interface.
    Eg: To use 25 seconds for IPU2 on DRA7xx,
      echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms

The runtime suspend feature can also be similarly enabled or disabled by
writing 'auto' or 'on' to the device's 'control' power field. The default
is enabled.
    Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
      echo on > /sys/bus/platform/devices/55020000.ipu/power/control

Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 drivers/remoteproc/omap_remoteproc.c | 220 ++++++++++++++++++++++++++-
 1 file changed, 214 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 0a9b9f7d20da..463d6f60947a 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -20,6 +20,7 @@
 #include <linux/of_device.h>
 #include <linux/of_reserved_mem.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/dma-mapping.h>
 #include <linux/remoteproc.h>
 #include <linux/mailbox_client.h>
@@ -37,6 +38,9 @@
 #include "omap_remoteproc.h"
 #include "remoteproc_internal.h"
 
+/* default auto-suspend delay (ms) */
+#define DEFAULT_AUTOSUSPEND_DELAY		10000
+
 /**
  * struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
  * @syscon: regmap handle for the system control configuration module
@@ -83,6 +87,8 @@ struct omap_rproc_timer {
  * @num_mems: number of internal memory regions
  * @num_timers: number of rproc timer(s)
  * @timers: timer(s) info used by rproc
+ * @autosuspend_delay: auto-suspend delay value to be used for runtime pm
+ * @need_resume: if true a resume is needed in the system resume callback
  * @rproc: rproc handle
  * @reset: reset handle
  * @pm_comp: completion primitive to sync for suspend response
@@ -97,6 +103,8 @@ struct omap_rproc {
 	int num_mems;
 	int num_timers;
 	struct omap_rproc_timer *timers;
+	int autosuspend_delay;
+	bool need_resume;
 	struct rproc *rproc;
 	struct reset_control *reset;
 	struct completion pm_comp;
@@ -111,6 +119,7 @@ struct omap_rproc {
  * @boot_reg_shift: bit shift for the boot register mask
  * @mem_names: memory names for this remote processor
  * @dev_addrs: device addresses corresponding to the memory names
+ * @autosuspend_delay: custom auto-suspend delay value in milliseconds
  */
 struct omap_rproc_dev_data {
 	const char *device_name;
@@ -118,6 +127,7 @@ struct omap_rproc_dev_data {
 	int boot_reg_shift;
 	const char * const *mem_names;
 	const u32 *dev_addrs;
+	int autosuspend_delay;
 };
 
 /**
@@ -384,11 +394,23 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
 	struct device *dev = rproc->dev.parent;
 	int ret;
 
+	/* wake up the rproc before kicking it */
+	ret = pm_runtime_get_sync(dev);
+	if (WARN_ON(ret < 0)) {
+		dev_err(dev, "pm_runtime_get_sync() failed during kick, ret = %d\n",
+			ret);
+		pm_runtime_put_noidle(dev);
+		return;
+	}
+
 	/* send the index of the triggered virtqueue in the mailbox payload */
 	ret = mbox_send_message(oproc->mbox, (void *)vqid);
 	if (ret < 0)
 		dev_err(dev, "failed to send mailbox message, status = %d\n",
 			ret);
+
+	pm_runtime_mark_last_busy(dev);
+	pm_runtime_put_autosuspend(dev);
 }
 
 /**
@@ -473,6 +495,19 @@ static int omap_rproc_start(struct rproc *rproc)
 		goto put_mbox;
 	}
 
+	/*
+	 * remote processor is up, so update the runtime pm status and
+	 * enable the auto-suspend. The device usage count is incremented
+	 * manually for balancing it for auto-suspend
+	 */
+	pm_runtime_set_active(dev);
+	pm_runtime_set_autosuspend_delay(dev, oproc->autosuspend_delay);
+	pm_runtime_use_autosuspend(dev);
+	pm_runtime_get(dev);
+	pm_runtime_enable(dev);
+	pm_runtime_mark_last_busy(dev);
+	pm_runtime_put_autosuspend(dev);
+
 	reset_control_deassert(oproc->reset);
 
 	return 0;
@@ -485,9 +520,26 @@ static int omap_rproc_start(struct rproc *rproc)
 /* power off the remote processor */
 static int omap_rproc_stop(struct rproc *rproc)
 {
+	struct device *dev = rproc->dev.parent;
 	struct omap_rproc *oproc = rproc->priv;
 	int ret;
 
+	/*
+	 * cancel any possible scheduled runtime suspend by incrementing
+	 * the device usage count, and resuming the device. The remoteproc
+	 * also needs to be woken up if suspended, to avoid the remoteproc
+	 * OS to continue to remember any context that it has saved, and
+	 * avoid potential issues in misindentifying a subsequent device
+	 * reboot as a power restore boot
+	 */
+	ret = pm_runtime_get_sync(dev);
+	if (ret < 0) {
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	pm_runtime_put_sync(dev);
+
 	reset_control_assert(oproc->reset);
 
 	ret = omap_rproc_disable_timers(rproc, true);
@@ -496,6 +548,15 @@ static int omap_rproc_stop(struct rproc *rproc)
 
 	mbox_free_channel(oproc->mbox);
 
+	/*
+	 * update the runtime pm states and status now that the remoteproc
+	 * has stopped
+	 */
+	pm_runtime_disable(dev);
+	pm_runtime_dont_use_autosuspend(dev);
+	pm_runtime_put_noidle(dev);
+	pm_runtime_set_suspended(dev);
+
 	return 0;
 }
 
@@ -552,17 +613,19 @@ static bool _is_rproc_in_standby(struct omap_rproc *oproc)
 
 /* 1 sec is long enough time to let the remoteproc side suspend the device */
 #define DEF_SUSPEND_TIMEOUT 1000
-static int _omap_rproc_suspend(struct rproc *rproc)
+static int _omap_rproc_suspend(struct rproc *rproc, bool auto_suspend)
 {
 	struct device *dev = rproc->dev.parent;
 	struct omap_rproc *oproc = rproc->priv;
 	unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
 	unsigned long ta = jiffies + to;
+	u32 suspend_msg = auto_suspend ?
+				RP_MBOX_SUSPEND_AUTO : RP_MBOX_SUSPEND_SYSTEM;
 	int ret;
 
 	reinit_completion(&oproc->pm_comp);
 	oproc->suspend_acked = false;
-	ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_SUSPEND_SYSTEM);
+	ret = mbox_send_message(oproc->mbox, (void *)suspend_msg);
 	if (ret < 0) {
 		dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
 		return ret;
@@ -602,25 +665,55 @@ static int _omap_rproc_suspend(struct rproc *rproc)
 		goto enable_device;
 	}
 
+	/*
+	 * IOMMUs would have to be disabled specifically for runtime suspend.
+	 * They are handled automatically through System PM callbacks for
+	 * regular system suspend
+	 */
+	if (auto_suspend) {
+		ret = omap_iommu_domain_deactivate(rproc->domain);
+		if (ret) {
+			dev_err(dev, "iommu domain deactivate failed %d\n",
+				ret);
+			goto enable_timers;
+		}
+	}
+
 	return 0;
+enable_timers:
+	/* ignore errors on re-enabling code */
+	omap_rproc_enable_timers(rproc, false);
 
 enable_device:
 	reset_control_deassert(oproc->reset);
 	return ret;
 }
 
-static int _omap_rproc_resume(struct rproc *rproc)
+static int _omap_rproc_resume(struct rproc *rproc, bool auto_suspend)
 {
 	struct device *dev = rproc->dev.parent;
 	struct omap_rproc *oproc = rproc->priv;
 	int ret;
 
+	/*
+	 * IOMMUs would have to be enabled specifically for runtime resume.
+	 * They would have been already enabled automatically through System
+	 * PM callbacks for regular system resume
+	 */
+	if (auto_suspend) {
+		ret = omap_iommu_domain_activate(rproc->domain);
+		if (ret) {
+			dev_err(dev, "omap_iommu activate failed %d\n", ret);
+			goto out;
+		}
+	}
+
 	/* boot address could be lost after suspend, so restore it */
 	if (oproc->boot_data) {
 		ret = omap_rproc_write_dsp_boot_addr(rproc);
 		if (ret) {
 			dev_err(dev, "boot address restore failed %d\n", ret);
-			goto out;
+			goto suspend_iommu;
 		}
 	}
 
@@ -633,6 +726,12 @@ static int _omap_rproc_resume(struct rproc *rproc)
 
 	reset_control_deassert(oproc->reset);
 
+	return 0;
+
+suspend_iommu:
+	if (auto_suspend)
+		omap_iommu_domain_deactivate(rproc->domain);
+
 out:
 	return ret;
 }
@@ -641,6 +740,7 @@ static int __maybe_unused omap_rproc_suspend(struct device *dev)
 {
 	struct platform_device *pdev = to_platform_device(dev);
 	struct rproc *rproc = platform_get_drvdata(pdev);
+	struct omap_rproc *oproc = rproc->priv;
 	int ret = 0;
 
 	mutex_lock(&rproc->lock);
@@ -655,13 +755,25 @@ static int __maybe_unused omap_rproc_suspend(struct device *dev)
 		goto out;
 	}
 
-	ret = _omap_rproc_suspend(rproc);
+	ret = _omap_rproc_suspend(rproc, false);
 	if (ret) {
 		dev_err(dev, "suspend failed %d\n", ret);
 		goto out;
 	}
 
+	/*
+	 * remoteproc is running at the time of system suspend, so remember
+	 * it so as to wake it up during system resume
+	 */
+	oproc->need_resume = 1;
 	rproc->state = RPROC_SUSPENDED;
+
+	/*
+	 * update the runtime pm status to be suspended, without decrementing
+	 * the device usage count
+	 */
+	pm_runtime_disable(dev);
+	pm_runtime_set_suspended(dev);
 out:
 	mutex_unlock(&rproc->lock);
 	return ret;
@@ -671,6 +783,7 @@ static int __maybe_unused omap_rproc_resume(struct device *dev)
 {
 	struct platform_device *pdev = to_platform_device(dev);
 	struct rproc *rproc = platform_get_drvdata(pdev);
+	struct omap_rproc *oproc = rproc->priv;
 	int ret = 0;
 
 	mutex_lock(&rproc->lock);
@@ -682,17 +795,91 @@ static int __maybe_unused omap_rproc_resume(struct device *dev)
 		goto out;
 	}
 
-	ret = _omap_rproc_resume(rproc);
+	/*
+	 * remoteproc was auto-suspended at the time of system suspend,
+	 * so no need to wake-up the processor (leave it in suspended
+	 * state, will be woken up during a subsequent runtime_resume)
+	 */
+	if (!oproc->need_resume)
+		goto out;
+
+	ret = _omap_rproc_resume(rproc, false);
 	if (ret) {
 		dev_err(dev, "resume failed %d\n", ret);
 		goto out;
 	}
+	oproc->need_resume = false;
 
 	rproc->state = RPROC_RUNNING;
+
+	/*
+	 * update the runtime pm status to be active, without incrementing
+	 * the device usage count
+	 */
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+	pm_runtime_mark_last_busy(dev);
 out:
 	mutex_unlock(&rproc->lock);
 	return ret;
 }
+
+static int omap_rproc_runtime_suspend(struct device *dev)
+{
+	struct rproc *rproc = dev_get_drvdata(dev);
+	struct omap_rproc *oproc = rproc->priv;
+	int ret;
+
+	if (rproc->state == RPROC_CRASHED) {
+		dev_dbg(dev, "rproc cannot be runtime suspended when crashed!\n");
+		return -EBUSY;
+	}
+
+	if (WARN_ON(rproc->state != RPROC_RUNNING)) {
+		dev_err(dev, "rproc cannot be runtime suspended when not running!\n");
+		return -EBUSY;
+	}
+
+	/*
+	 * do not even attempt suspend if the remote processor is not
+	 * idled for runtime auto-suspend
+	 */
+	if (!_is_rproc_in_standby(oproc)) {
+		ret = -EBUSY;
+		goto abort;
+	}
+
+	ret = _omap_rproc_suspend(rproc, true);
+	if (ret)
+		goto abort;
+
+	rproc->state = RPROC_SUSPENDED;
+	return 0;
+
+abort:
+	pm_runtime_mark_last_busy(dev);
+	return ret;
+}
+
+static int omap_rproc_runtime_resume(struct device *dev)
+{
+	struct rproc *rproc = dev_get_drvdata(dev);
+	int ret;
+
+	if (WARN_ON(rproc->state != RPROC_SUSPENDED)) {
+		dev_err(dev, "rproc cannot be runtime resumed if not suspended!\n");
+		return -EBUSY;
+	}
+
+	ret = _omap_rproc_resume(rproc, true);
+	if (ret) {
+		dev_err(dev, "runtime resume failed %d\n", ret);
+		return ret;
+	}
+
+	rproc->state = RPROC_RUNNING;
+	return 0;
+}
 #endif /* CONFIG_PM */
 
 static const char * const ipu_mem_names[] = {
@@ -778,6 +965,20 @@ static const struct of_device_id omap_rproc_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
 
+static int omap_rproc_get_autosuspend_delay(struct platform_device *pdev)
+{
+	const struct omap_rproc_dev_data *data;
+	int delay;
+
+	data = of_device_get_match_data(&pdev->dev);
+	if (!data)
+		return -ENODEV;
+
+	delay = data->autosuspend_delay;
+
+	return (delay > 0) ? delay : DEFAULT_AUTOSUSPEND_DELAY;
+}
+
 static const char *omap_rproc_get_firmware(struct platform_device *pdev)
 {
 	const char *fw_name;
@@ -953,6 +1154,11 @@ static int omap_rproc_probe(struct platform_device *pdev)
 	}
 
 	init_completion(&oproc->pm_comp);
+	oproc->autosuspend_delay = omap_rproc_get_autosuspend_delay(pdev);
+	if (oproc->autosuspend_delay < 0) {
+		ret = oproc->autosuspend_delay;
+		goto free_rproc;
+	}
 
 	oproc->fck = devm_clk_get(&pdev->dev, 0);
 	if (IS_ERR(oproc->fck)) {
@@ -994,6 +1200,8 @@ static int omap_rproc_remove(struct platform_device *pdev)
 
 static const struct dev_pm_ops omap_rproc_pm_ops = {
 	SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
+	SET_RUNTIME_PM_OPS(omap_rproc_runtime_suspend,
+			   omap_rproc_runtime_resume, NULL)
 };
 
 static struct platform_driver omap_rproc_driver = {
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 14/15] remoteproc/omap: report device exceptions and trigger recovery
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (12 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  2019-12-13 12:55 ` [PATCHv3 15/15] remoteproc/omap: add watchdog functionality for remote processors Tero Kristo
  14 siblings, 0 replies; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

The OMAP remote processors send a special mailbox message
(RP_MBOX_CRASH) when they crash and detect an internal device
exception.

Add support to the mailbox handling function upon detection of
this special message to report this crash to the remoteproc core.
The remoteproc core can trigger a recovery using the prevailing
recovery mechanism, already in use for MMU Fault recovery.

Co-developed-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 drivers/remoteproc/omap_remoteproc.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 463d6f60947a..02599278263f 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -363,8 +363,12 @@ static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
 
 	switch (msg) {
 	case RP_MBOX_CRASH:
-		/* just log this for now. later, we'll also do recovery */
+		/*
+		 * remoteproc detected an exception, notify the rproc core.
+		 * The remoteproc core will handle the recovery.
+		 */
 		dev_err(dev, "omap rproc %s crashed\n", name);
+		rproc_report_crash(oproc->rproc, RPROC_FATAL_ERROR);
 		break;
 	case RP_MBOX_ECHO_REPLY:
 		dev_info(dev, "received echo reply from %s\n", name);
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCHv3 15/15] remoteproc/omap: add watchdog functionality for remote processors
  2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
                   ` (13 preceding siblings ...)
  2019-12-13 12:55 ` [PATCHv3 14/15] remoteproc/omap: report device exceptions and trigger recovery Tero Kristo
@ 2019-12-13 12:55 ` Tero Kristo
  14 siblings, 0 replies; 50+ messages in thread
From: Tero Kristo @ 2019-12-13 12:55 UTC (permalink / raw)
  To: bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap, Suman Anna, Tero Kristo

From: Suman Anna <s-anna@ti.com>

Remote processors can be stuck in a loop, and may not be recoverable
if they do not have a built-in watchdog. The watchdog implementation
for OMAP remote processors uses external gptimers that can be used
to interrupt both the Linux host as well as the remote processor.

Each remote processor is responsible for refreshing the timer during
normal behavior - during OS task scheduling or entering the idle loop
properly. During a watchdog condition (executing a tight loop causing
no scheduling), the host processor gets interrupts and schedules a
recovery for the corresponding remote processor. The remote processor
may also get interrupted to be able to print a back trace.

A menuconfig option has also been added to enable/disable the Watchdog
functionality, with the default as disabled.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 drivers/remoteproc/Kconfig           |  12 +++
 drivers/remoteproc/omap_remoteproc.c | 155 ++++++++++++++++++++++++---
 2 files changed, 155 insertions(+), 12 deletions(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index d6450d7fcf92..b2eaa18ad503 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -42,6 +42,18 @@ config OMAP_REMOTEPROC
 	  It's safe to say N here if you're not interested in multimedia
 	  offloading or just want a bare minimum kernel.
 
+config OMAP_REMOTEPROC_WATCHDOG
+	bool "OMAP remoteproc watchdog timer"
+	depends on OMAP_REMOTEPROC
+	default n
+	help
+	  Say Y here to enable watchdog timer for remote processors.
+
+	  This option controls the watchdog functionality for the remote
+	  processors in OMAP. Dedicated OMAP DMTimers are used by the remote
+	  processors and triggers the timer interrupt upon a watchdog
+	  detection.
+
 config WKUP_M3_RPROC
 	tristate "AMx3xx Wakeup M3 remoteproc support"
 	depends on SOC_AM33XX || SOC_AM43XX
diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 02599278263f..6b2f46f5a0e2 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -22,6 +22,7 @@
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
 #include <linux/remoteproc.h>
 #include <linux/mailbox_client.h>
 #include <linux/omap-mailbox.h>
@@ -72,10 +73,12 @@ struct omap_rproc_mem {
  * struct omap_rproc_timer - data structure for a timer used by a omap rproc
  * @odt: timer pointer
  * @timer_ops: OMAP dmtimer ops for @odt timer
+ * @irq: timer irq
  */
 struct omap_rproc_timer {
 	struct omap_dm_timer *odt;
 	const struct omap_dm_timer_ops *timer_ops;
+	int irq;
 };
 
 /**
@@ -86,6 +89,7 @@ struct omap_rproc_timer {
  * @mem: internal memory regions data
  * @num_mems: number of internal memory regions
  * @num_timers: number of rproc timer(s)
+ * @num_wd_timers: number of rproc watchdog timers
  * @timers: timer(s) info used by rproc
  * @autosuspend_delay: auto-suspend delay value to be used for runtime pm
  * @need_resume: if true a resume is needed in the system resume callback
@@ -102,6 +106,7 @@ struct omap_rproc {
 	struct omap_rproc_mem *mem;
 	int num_mems;
 	int num_timers;
+	int num_wd_timers;
 	struct omap_rproc_timer *timers;
 	int autosuspend_delay;
 	bool need_resume;
@@ -217,6 +222,81 @@ static inline int omap_rproc_release_timer(struct omap_rproc_timer *timer)
 	return timer->timer_ops->free(timer->odt);
 }
 
+/**
+ * omap_rproc_get_timer_irq - get the irq for a timer
+ * @timer - handle to a OMAP rproc timer
+ *
+ * This function is used to get the irq associated with a watchdog timer. The
+ * function is called by the OMAP remoteproc driver to register a interrupt
+ * handler to handle watchdog events on the remote processor.
+ *
+ * Returns the irq id on success, otherwise a failure as returned by DMTimer ops
+ */
+static inline int omap_rproc_get_timer_irq(struct omap_rproc_timer *timer)
+{
+	return timer->timer_ops->get_irq(timer->odt);
+}
+
+/**
+ * omap_rproc_ack_timer_irq - acknowledge a timer irq
+ * @timer: handle to a OMAP rproc timer
+ *
+ * This function is used to clear the irq associated with a watchdog timer. The
+ * The function is called by the OMAP remoteproc upon a watchdog event on the
+ * remote processor to clear the interrupt status of the watchdog timer.
+ *
+ * Returns the irq id on success, otherwise a failure as returned by DMTimer ops
+ */
+static inline void omap_rproc_ack_timer_irq(struct omap_rproc_timer *timer)
+{
+	timer->timer_ops->write_status(timer->odt, OMAP_TIMER_INT_OVERFLOW);
+}
+
+/**
+ * omap_rproc_watchdog_isr - Watchdog ISR handler for remoteproc device
+ * @irq: IRQ number associated with a watchdog timer
+ * @data: IRQ handler data
+ *
+ * This ISR routine executes the required necessary low-level code to
+ * acknowledge a watchdog timer interrupt. There can be multiple watchdog
+ * timers associated with a rproc (like IPUs which have 2 watchdog timers,
+ * one per Cortex M3/M4 core), so a lookup has to be performed to identify
+ * the timer to acknowledge its interrupt.
+ *
+ * The function also invokes rproc_report_crash to report the watchdog event
+ * to the remoteproc driver core, to trigger a recovery.
+ *
+ * Return: IRQ_HANDLED or IRQ_NONE
+ */
+static irqreturn_t omap_rproc_watchdog_isr(int irq, void *data)
+{
+	struct rproc *rproc = data;
+	struct omap_rproc *oproc = rproc->priv;
+	struct device *dev = rproc->dev.parent;
+	struct omap_rproc_timer *timers = oproc->timers;
+	struct omap_rproc_timer *wd_timer = NULL;
+	int num_timers = oproc->num_timers + oproc->num_wd_timers;
+	int i;
+
+	for (i = oproc->num_timers; i < num_timers; i++) {
+		if (timers[i].irq > 0 && irq == timers[i].irq) {
+			wd_timer = &timers[i];
+			break;
+		}
+	}
+
+	if (!wd_timer) {
+		dev_err(dev, "invalid timer\n");
+		return IRQ_NONE;
+	}
+
+	omap_rproc_ack_timer_irq(wd_timer);
+
+	rproc_report_crash(rproc, RPROC_WATCHDOG);
+
+	return IRQ_HANDLED;
+}
+
 /**
  * omap_rproc_enable_timers - enable the timers for a remoteproc
  * @rproc: handle of a remote processor
@@ -238,19 +318,26 @@ static int omap_rproc_enable_timers(struct rproc *rproc, bool configure)
 	struct omap_rproc_timer *timers = oproc->timers;
 	struct device *dev = rproc->dev.parent;
 	struct device_node *np = NULL;
+	int num_timers = oproc->num_timers + oproc->num_wd_timers;
 
-	if (oproc->num_timers <= 0)
+	if (num_timers <= 0)
 		return 0;
 
 	if (!configure)
 		goto start_timers;
 
-	for (i = 0; i < oproc->num_timers; i++) {
-		np = of_parse_phandle(dev->of_node, "ti,timers", i);
+	for (i = 0; i < num_timers; i++) {
+		if (i < oproc->num_timers)
+			np = of_parse_phandle(dev->of_node, "ti,timers", i);
+		else
+			np = of_parse_phandle(dev->of_node,
+					      "ti,watchdog-timers",
+					      (i - oproc->num_timers));
 		if (!np) {
 			ret = -ENXIO;
 			dev_err(dev, "device node lookup for timer at index %d failed: %d\n",
-				i, ret);
+				i < oproc->num_timers ? i :
+				i - oproc->num_timers, ret);
 			goto free_timers;
 		}
 
@@ -273,12 +360,14 @@ static int omap_rproc_enable_timers(struct rproc *rproc, bool configure)
 		if (!timer_ops || !timer_ops->request_by_node ||
 		    !timer_ops->set_source || !timer_ops->set_load ||
 		    !timer_ops->free || !timer_ops->start ||
-		    !timer_ops->stop) {
+		    !timer_ops->stop || !timer_ops->get_irq ||
+		    !timer_ops->write_status) {
 			ret = -EINVAL;
 			dev_err(dev, "device does not have required timer ops\n");
 			goto put_node;
 		}
 
+		timers[i].irq = -1;
 		timers[i].timer_ops = timer_ops;
 		ret = omap_rproc_request_timer(dev, np, &timers[i]);
 		if (ret) {
@@ -287,10 +376,33 @@ static int omap_rproc_enable_timers(struct rproc *rproc, bool configure)
 			goto put_node;
 		}
 		of_node_put(np);
+
+		if (i >= oproc->num_timers) {
+			timers[i].irq = omap_rproc_get_timer_irq(&timers[i]);
+			if (timers[i].irq < 0) {
+				dev_err(dev, "get_irq for timer %p failed: %d\n",
+					np, timers[i].irq);
+				ret = -EBUSY;
+				goto free_timers;
+			}
+
+			ret = request_irq(timers[i].irq,
+					  omap_rproc_watchdog_isr, IRQF_SHARED,
+					  "rproc-wdt", rproc);
+			if (ret) {
+				dev_err(dev, "error requesting irq for timer %p\n",
+					np);
+				omap_rproc_release_timer(&timers[i]);
+				timers[i].odt = NULL;
+				timers[i].timer_ops = NULL;
+				timers[i].irq = -1;
+				goto free_timers;
+			}
+		}
 	}
 
 start_timers:
-	for (i = 0; i < oproc->num_timers; i++)
+	for (i = 0; i < num_timers; i++)
 		omap_rproc_start_timer(&timers[i]);
 	return 0;
 
@@ -298,9 +410,12 @@ static int omap_rproc_enable_timers(struct rproc *rproc, bool configure)
 	of_node_put(np);
 free_timers:
 	while (i--) {
+		if (i >= oproc->num_timers)
+			free_irq(timers[i].irq, rproc);
 		omap_rproc_release_timer(&timers[i]);
 		timers[i].odt = NULL;
 		timers[i].timer_ops = NULL;
+		timers[i].irq = -1;
 	}
 
 	return ret;
@@ -321,16 +436,20 @@ static int omap_rproc_disable_timers(struct rproc *rproc, bool configure)
 	int i;
 	struct omap_rproc *oproc = rproc->priv;
 	struct omap_rproc_timer *timers = oproc->timers;
+	int num_timers = oproc->num_timers + oproc->num_wd_timers;
 
-	if (oproc->num_timers <= 0)
+	if (num_timers <= 0)
 		return 0;
 
-	for (i = 0; i < oproc->num_timers; i++) {
+	for (i = 0; i < num_timers; i++) {
 		omap_rproc_stop_timer(&timers[i]);
 		if (configure) {
+			if (i >= oproc->num_timers)
+				free_irq(timers[i].irq, rproc);
 			omap_rproc_release_timer(&timers[i]);
 			timers[i].odt = NULL;
 			timers[i].timer_ops = NULL;
+			timers[i].irq = -1;
 		}
 	}
 
@@ -1093,6 +1212,7 @@ static int omap_rproc_probe(struct platform_device *pdev)
 	struct omap_rproc *oproc;
 	struct rproc *rproc;
 	const char *firmware;
+	int num_timers;
 	int ret;
 	struct reset_control *reset;
 
@@ -1145,16 +1265,27 @@ static int omap_rproc_probe(struct platform_device *pdev)
 		oproc->num_timers = 0;
 	}
 
-	if (oproc->num_timers) {
+#ifdef CONFIG_OMAP_REMOTEPROC_WATCHDOG
+	oproc->num_wd_timers =
+		of_count_phandle_with_args(np, "ti,watchdog-timers", NULL);
+	if (oproc->num_wd_timers <= 0) {
+		dev_dbg(&pdev->dev, "device does not have watchdog timers, status = %d\n",
+			oproc->num_wd_timers);
+		oproc->num_wd_timers = 0;
+	}
+#endif
+
+	if (oproc->num_timers || oproc->num_wd_timers) {
+		num_timers = oproc->num_timers + oproc->num_wd_timers;
 		oproc->timers = devm_kzalloc(&pdev->dev, sizeof(*oproc->timers)
-					     * oproc->num_timers, GFP_KERNEL);
+					     * num_timers, GFP_KERNEL);
 		if (!oproc->timers) {
 			ret = -ENOMEM;
 			goto free_rproc;
 		}
 
-		dev_dbg(&pdev->dev, "device has %d tick timers\n",
-			oproc->num_timers);
+		dev_dbg(&pdev->dev, "device has %d tick timers and %d watchdog timers\n",
+			oproc->num_timers, oproc->num_wd_timers);
 	}
 
 	init_completion(&oproc->pm_comp);
-- 
2.17.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 02/15] remoteproc/omap: Add device tree support
  2019-12-13 12:55 ` [PATCHv3 02/15] remoteproc/omap: Add device tree support Tero Kristo
@ 2019-12-17 23:01   ` Mathieu Poirier
  2019-12-19 11:54     ` Tero Kristo
  0 siblings, 1 reply; 50+ messages in thread
From: Mathieu Poirier @ 2019-12-17 23:01 UTC (permalink / raw)
  To: Tero Kristo
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna, Tony Lindgren

Hi Tero,

On Fri, Dec 13, 2019 at 02:55:24PM +0200, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
> 
> OMAP4+ SoCs support device tree boot only. The OMAP remoteproc
> driver is enhanced to support remoteproc devices created through
> Device Tree, support for legacy platform devices has been
> deprecated. The current DT support handles the IPU and DSP
> processor subsystems on OMAP4 and OMAP5 SoCs.
> 
> The OMAP remoteproc driver relies on the ti-sysc, reset, and
> syscon layers for performing clock, reset and boot vector
> management (DSP remoteprocs only) of the devices, but some of
> these are limited only to the machine-specific layers
> in arch/arm. The dependency against control module API for boot
> vector management of the DSP remoteprocs has now been removed
> with added logic to parse the boot register from the DT node
> and program it appropriately directly within the driver.
> 
> The OMAP remoteproc driver expects the firmware names to be
> provided via device tree entries (firmware-name.) These are used
> to load the proper firmware during boot of the remote processor.
> 
> Cc: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> [t-kristo@ti.com: converted to use ti-sysc framework]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  drivers/remoteproc/omap_remoteproc.c | 191 +++++++++++++++++++++++----
>  1 file changed, 168 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index 6398194075aa..558634624590 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -2,7 +2,7 @@
>  /*
>   * OMAP Remote Processor driver
>   *
> - * Copyright (C) 2011 Texas Instruments, Inc.
> + * Copyright (C) 2011-2019 Texas Instruments Incorporated - http://www.ti.com/
>   * Copyright (C) 2011 Google, Inc.
>   *
>   * Ohad Ben-Cohen <ohad@wizery.com>
> @@ -16,27 +16,53 @@
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/err.h>
> +#include <linux/of_device.h>
>  #include <linux/platform_device.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/remoteproc.h>
>  #include <linux/mailbox_client.h>
>  #include <linux/omap-mailbox.h>
> -
> -#include <linux/platform_data/remoteproc-omap.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/reset.h>
>  
>  #include "omap_remoteproc.h"
>  #include "remoteproc_internal.h"
>  
> +/**
> + * struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
> + * @syscon: regmap handle for the system control configuration module
> + * @boot_reg: boot register offset within the @syscon regmap
> + */
> +struct omap_rproc_boot_data {
> +	struct regmap *syscon;
> +	unsigned int boot_reg;
> +};
> +
>  /**
>   * struct omap_rproc - omap remote processor state
>   * @mbox: mailbox channel handle
>   * @client: mailbox client to request the mailbox channel
> + * @boot_data: boot data structure for setting processor boot address
>   * @rproc: rproc handle
> + * @reset: reset handle
>   */
>  struct omap_rproc {
>  	struct mbox_chan *mbox;
>  	struct mbox_client client;
> +	struct omap_rproc_boot_data *boot_data;
>  	struct rproc *rproc;
> +	struct reset_control *reset;
> +};
> +
> +/**
> + * struct omap_rproc_dev_data - device data for the omap remote processor
> + * @device_name: device name of the remote processor
> + * @has_bootreg: true if this remote processor has boot register
> + */
> +struct omap_rproc_dev_data {
> +	const char *device_name;
> +	bool has_bootreg;
>  };
>  
>  /**
> @@ -92,6 +118,21 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
>  			ret);
>  }
>  
> +/**
> + * omap_rproc_write_dsp_boot_addr - set boot address for a DSP remote processor
> + * @rproc: handle of a remote processor
> + *
> + * Set boot address for a supported DSP remote processor.
> + */
> +static void omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
> +{
> +	struct omap_rproc *oproc = rproc->priv;
> +	struct omap_rproc_boot_data *bdata = oproc->boot_data;
> +	u32 offset = bdata->boot_reg;
> +
> +	regmap_write(bdata->syscon, offset, rproc->bootaddr);
> +}
> +
>  /*
>   * Power up the remote processor.
>   *
> @@ -103,13 +144,11 @@ static int omap_rproc_start(struct rproc *rproc)
>  {
>  	struct omap_rproc *oproc = rproc->priv;
>  	struct device *dev = rproc->dev.parent;
> -	struct platform_device *pdev = to_platform_device(dev);
> -	struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>  	int ret;
>  	struct mbox_client *client = &oproc->client;
>  
> -	if (pdata->set_bootaddr)
> -		pdata->set_bootaddr(rproc->bootaddr);
> +	if (oproc->boot_data)
> +		omap_rproc_write_dsp_boot_addr(rproc);
>  
>  	client->dev = dev;
>  	client->tx_done = NULL;
> @@ -117,7 +156,7 @@ static int omap_rproc_start(struct rproc *rproc)
>  	client->tx_block = false;
>  	client->knows_txdone = false;
>  
> -	oproc->mbox = omap_mbox_request_channel(client, pdata->mbox_name);
> +	oproc->mbox = mbox_request_channel(client, 0);
>  	if (IS_ERR(oproc->mbox)) {
>  		ret = -EBUSY;
>  		dev_err(dev, "mbox_request_channel failed: %ld\n",
> @@ -138,11 +177,7 @@ static int omap_rproc_start(struct rproc *rproc)
>  		goto put_mbox;
>  	}
>  
> -	ret = pdata->device_enable(pdev);
> -	if (ret) {
> -		dev_err(dev, "omap_device_enable failed: %d\n", ret);
> -		goto put_mbox;
> -	}
> +	reset_control_deassert(oproc->reset);
>  
>  	return 0;
>  
> @@ -154,15 +189,9 @@ static int omap_rproc_start(struct rproc *rproc)
>  /* power off the remote processor */
>  static int omap_rproc_stop(struct rproc *rproc)
>  {
> -	struct device *dev = rproc->dev.parent;
> -	struct platform_device *pdev = to_platform_device(dev);
> -	struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>  	struct omap_rproc *oproc = rproc->priv;
> -	int ret;
>  
> -	ret = pdata->device_shutdown(pdev);
> -	if (ret)
> -		return ret;
> +	reset_control_assert(oproc->reset);
>  
>  	mbox_free_channel(oproc->mbox);
>  
> @@ -175,12 +204,122 @@ static const struct rproc_ops omap_rproc_ops = {
>  	.kick		= omap_rproc_kick,
>  };
>  
> +static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
> +	.device_name	= "dsp",
> +	.has_bootreg	= true,
> +};
> +
> +static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
> +	.device_name	= "ipu",
> +};
> +
> +static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
> +	.device_name	= "dsp",
> +	.has_bootreg	= true,
> +};
> +
> +static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
> +	.device_name	= "ipu",
> +};
> +
> +static const struct of_device_id omap_rproc_of_match[] = {
> +	{
> +		.compatible     = "ti,omap4-dsp",
> +		.data           = &omap4_dsp_dev_data,
> +	},
> +	{
> +		.compatible     = "ti,omap4-ipu",
> +		.data           = &omap4_ipu_dev_data,
> +	},
> +	{
> +		.compatible     = "ti,omap5-dsp",
> +		.data           = &omap5_dsp_dev_data,
> +	},
> +	{
> +		.compatible     = "ti,omap5-ipu",
> +		.data           = &omap5_ipu_dev_data,
> +	},
> +	{
> +		/* end */
> +	},
> +};
> +MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
> +
> +static const char *omap_rproc_get_firmware(struct platform_device *pdev)
> +{
> +	const char *fw_name;
> +	int ret;
> +
> +	ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
> +				      &fw_name);
> +	if (ret)
> +		return ERR_PTR(ret);
> +
> +	return fw_name;
> +}
> +
> +static int omap_rproc_get_boot_data(struct platform_device *pdev,
> +				    struct rproc *rproc)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct omap_rproc *oproc = rproc->priv;
> +	const struct omap_rproc_dev_data *data;
> +	int ret;
> +
> +	data = of_device_get_match_data(&pdev->dev);
> +	if (!data)
> +		return -ENODEV;
> +
> +	if (!data->has_bootreg)
> +		return 0;
> +
> +	oproc->boot_data = devm_kzalloc(&pdev->dev, sizeof(*oproc->boot_data),
> +					GFP_KERNEL);
> +	if (!oproc->boot_data)
> +		return -ENOMEM;
> +
> +	if (!of_property_read_bool(np, "ti,bootreg")) {
> +		dev_err(&pdev->dev, "ti,bootreg property is missing\n");
> +		return -EINVAL;
> +	}
> +
> +	oproc->boot_data->syscon =
> +			syscon_regmap_lookup_by_phandle(np, "ti,bootreg");
> +	if (IS_ERR(oproc->boot_data->syscon)) {
> +		ret = PTR_ERR(oproc->boot_data->syscon);
> +		return ret;
> +	}
> +
> +	if (of_property_read_u32_index(np, "ti,bootreg", 1,
> +				       &oproc->boot_data->boot_reg)) {
> +		dev_err(&pdev->dev, "couldn't get the boot register\n");
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
>  static int omap_rproc_probe(struct platform_device *pdev)
>  {
> -	struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
> +	struct device_node *np = pdev->dev.of_node;
>  	struct omap_rproc *oproc;
>  	struct rproc *rproc;
> +	const char *firmware;
>  	int ret;
> +	struct reset_control *reset;
> +
> +	if (!np) {
> +		dev_err(&pdev->dev, "only DT-based devices are supported\n");
> +		return -ENODEV;
> +	}
> +
> +	reset = devm_reset_control_array_get_optional_exclusive(&pdev->dev);
> +	if (IS_ERR(reset))
> +		return PTR_ERR(reset);

Definition of a reset is listed as "required" in the bindings but here it is
optional.  If this is really what you want then adding a comment to exlain your
choice is probably a good idea.

> +
> +	firmware = omap_rproc_get_firmware(pdev);
> +	if (IS_ERR(firmware))
> +		return PTR_ERR(firmware);
>  
>  	ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
>  	if (ret) {
> @@ -188,16 +327,21 @@ static int omap_rproc_probe(struct platform_device *pdev)
>  		return ret;
>  	}
>  
> -	rproc = rproc_alloc(&pdev->dev, pdata->name, &omap_rproc_ops,
> -			    pdata->firmware, sizeof(*oproc));
> +	rproc = rproc_alloc(&pdev->dev, dev_name(&pdev->dev), &omap_rproc_ops,
> +			    firmware, sizeof(*oproc));
>  	if (!rproc)
>  		return -ENOMEM;
>  
>  	oproc = rproc->priv;
>  	oproc->rproc = rproc;
> +	oproc->reset = reset;
>  	/* All existing OMAP IPU and DSP processors have an MMU */
>  	rproc->has_iommu = true;
>  
> +	ret = omap_rproc_get_boot_data(pdev, rproc);
> +	if (ret)
> +		goto free_rproc;
> +
>  	platform_set_drvdata(pdev, rproc);
>  
>  	ret = rproc_add(rproc);
> @@ -226,6 +370,7 @@ static struct platform_driver omap_rproc_driver = {
>  	.remove = omap_rproc_remove,
>  	.driver = {
>  		.name = "omap-rproc",
> +		.of_match_table = omap_rproc_of_match,

                .of_match_table = of_match_ptr(omap_rproc_of_match),

Thanks,
Mathieu

>  	},
>  };
>  
> -- 
> 2.17.1
> 
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 04/15] remoteproc/omap: Add support to parse internal memories from DT
  2019-12-13 12:55 ` [PATCHv3 04/15] remoteproc/omap: Add support to parse internal memories from DT Tero Kristo
@ 2019-12-18  0:22   ` Mathieu Poirier
  2019-12-19 12:31     ` Tero Kristo
  0 siblings, 1 reply; 50+ messages in thread
From: Mathieu Poirier @ 2019-12-18  0:22 UTC (permalink / raw)
  To: Tero Kristo
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna

On Fri, Dec 13, 2019 at 02:55:26PM +0200, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
> 
> The OMAP remoteproc driver has been enhanced to parse and store
> the kernel mappings for different internal RAM memories that may
> be present within each remote processor IP subsystem. Different
> devices have varying memories present on current SoCs. The current
> support handles the L2RAM for all IPU devices on OMAP4+ SoCs. The
> DSPs on OMAP4/OMAP5 only have Unicaches and do not have any L1 or
> L2 RAM memories.
> 
> IPUs are expected to have the L2RAM at a fixed device address of
> 0x20000000, based on the current limitations on Attribute MMU
> configurations.
> 
> NOTE:
> The current logic doesn't handle the parsing of memories for DRA7
> remoteproc devices, and will be added alongside the DRA7 support.
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> [t-kristo: converted to parse mem names / device addresses from pdata]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  drivers/remoteproc/omap_remoteproc.c | 86 ++++++++++++++++++++++++++++
>  1 file changed, 86 insertions(+)
> 
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index d80f5d7b5931..844703507a74 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -39,11 +39,27 @@ struct omap_rproc_boot_data {
>  	unsigned int boot_reg;
>  };
>  
> +/*
> + * struct omap_rproc_mem - 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 of the memory region from DSP view
> + * @size: size of the memory region
> + */
> +struct omap_rproc_mem {
> +	void __iomem *cpu_addr;
> +	phys_addr_t bus_addr;
> +	u32 dev_addr;
> +	size_t size;
> +};
> +
>  /**
>   * struct omap_rproc - omap remote processor state
>   * @mbox: mailbox channel handle
>   * @client: mailbox client to request the mailbox channel
>   * @boot_data: boot data structure for setting processor boot address
> + * @mem: internal memory regions data
> + * @num_mems: number of internal memory regions
>   * @rproc: rproc handle
>   * @reset: reset handle
>   */
> @@ -51,6 +67,8 @@ struct omap_rproc {
>  	struct mbox_chan *mbox;
>  	struct mbox_client client;
>  	struct omap_rproc_boot_data *boot_data;
> +	struct omap_rproc_mem *mem;
> +	int num_mems;
>  	struct rproc *rproc;
>  	struct reset_control *reset;
>  };
> @@ -59,10 +77,14 @@ struct omap_rproc {
>   * struct omap_rproc_dev_data - device data for the omap remote processor
>   * @device_name: device name of the remote processor
>   * @has_bootreg: true if this remote processor has boot register
> + * @mem_names: memory names for this remote processor
> + * @dev_addrs: device addresses corresponding to the memory names
>   */
>  struct omap_rproc_dev_data {
>  	const char *device_name;
>  	bool has_bootreg;
> +	const char * const *mem_names;
> +	const u32 *dev_addrs;

Bunching these two in a new structure like omap_rproc_mem_data would clean
things up.  That way the two arrays in the next hunk get merged and there can't
be a difference in sizes, somthing that will sturdy the main loop in
omap_rproc_of_get_internal_memories() below. 

>  };
>  
>  /**
> @@ -216,6 +238,14 @@ static const struct rproc_ops omap_rproc_ops = {
>  	.kick		= omap_rproc_kick,
>  };
>  
> +static const char * const ipu_mem_names[] = {
> +	"l2ram", NULL
> +};
> +
> +static const u32 ipu_dev_addrs[] = {
> +	0x20000000,
> +};
> +
>  static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>  	.device_name	= "dsp",
>  	.has_bootreg	= true,
> @@ -223,6 +253,8 @@ static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>  
>  static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
>  	.device_name	= "ipu",
> +	.mem_names	= ipu_mem_names,
> +	.dev_addrs	= ipu_dev_addrs,
>  };
>  
>  static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
> @@ -232,6 +264,8 @@ static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
>  
>  static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
>  	.device_name	= "ipu",
> +	.mem_names	= ipu_mem_names,
> +	.dev_addrs	= ipu_dev_addrs,
>  };
>  
>  static const struct of_device_id omap_rproc_of_match[] = {
> @@ -311,6 +345,54 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev,
>  	return 0;
>  }
>  
> +static int omap_rproc_of_get_internal_memories(struct platform_device *pdev,
> +					       struct rproc *rproc)
> +{
> +	struct omap_rproc *oproc = rproc->priv;
> +	struct device *dev = &pdev->dev;
> +	const struct omap_rproc_dev_data *data;
> +	struct resource *res;
> +	int num_mems;
> +	int i;
> +
> +	data = of_device_get_match_data(&pdev->dev);
> +	if (!data)
> +		return -ENODEV;
> +
> +	if (!data->mem_names)
> +		return 0;
> +
> +	for (num_mems = 0; data->mem_names[num_mems]; num_mems++)
> +		;

Instead of doing this function of_property_count_elems_of_size() can be used on
the "reg" property.

In the loop below a check should be done to see if data->mem_data[i] (see above
comment) is valid before calling platform_get_resource_byname().  If not then
an error can be returned.

I'm running out of time for today - I will continue reviewing the other patches
tomorrow.

> +
> +	oproc->mem = devm_kcalloc(dev, num_mems, sizeof(*oproc->mem),
> +				  GFP_KERNEL);
> +	if (!oproc->mem)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < num_mems; i++) {
> +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> +						   data->mem_names[i]);
> +		oproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
> +		if (IS_ERR(oproc->mem[i].cpu_addr)) {
> +			dev_err(dev, "failed to parse and map %s memory\n",
> +				data->mem_names[i]);
> +			return PTR_ERR(oproc->mem[i].cpu_addr);
> +		}
> +		oproc->mem[i].bus_addr = res->start;
> +		oproc->mem[i].dev_addr = data->dev_addrs[i];
> +		oproc->mem[i].size = resource_size(res);
> +
> +		dev_dbg(dev, "memory %8s: bus addr %pa size 0x%x va %p da 0x%x\n",
> +			data->mem_names[i], &oproc->mem[i].bus_addr,
> +			oproc->mem[i].size, oproc->mem[i].cpu_addr,
> +			oproc->mem[i].dev_addr);
> +	}
> +	oproc->num_mems = num_mems;
> +
> +	return 0;
> +}
> +
>  static int omap_rproc_probe(struct platform_device *pdev)
>  {
>  	struct device_node *np = pdev->dev.of_node;
> @@ -350,6 +432,10 @@ static int omap_rproc_probe(struct platform_device *pdev)
>  	/* All existing OMAP IPU and DSP processors have an MMU */
>  	rproc->has_iommu = true;
>  
> +	ret = omap_rproc_of_get_internal_memories(pdev, rproc);
> +	if (ret)
> +		goto free_rproc;
> +
>  	ret = omap_rproc_get_boot_data(pdev, rproc);
>  	if (ret)
>  		goto free_rproc;
> -- 
> 2.17.1
> 
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation
  2019-12-13 12:55 ` [PATCHv3 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation Tero Kristo
@ 2019-12-18  0:38   ` Mathieu Poirier
  2019-12-19 13:18     ` Tero Kristo
  0 siblings, 1 reply; 50+ messages in thread
From: Mathieu Poirier @ 2019-12-18  0:38 UTC (permalink / raw)
  To: Tero Kristo
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna

On Fri, Dec 13, 2019 at 02:55:27PM +0200, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
> 
> An implementation for the rproc ops .da_to_va() has been added
> that provides the address translation between device addresses
> to kernel virtual addresses for internal RAMs present on that
> particular remote processor device. The implementation provides
> the translations based on the addresses parsed and stored during
> the probe.
> 
> This ops gets invoked by the exported rproc_da_to_va() function
> and allows the remoteproc core's ELF loader to be able to load
> program data directly into the internal memories.
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  drivers/remoteproc/omap_remoteproc.c | 39 ++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index 844703507a74..28f14e24b389 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -232,10 +232,49 @@ static int omap_rproc_stop(struct rproc *rproc)
>  	return 0;
>  }
>  
> +/**
> + * omap_rproc_da_to_va() - internal memory translation helper
> + * @rproc: remote processor to apply the address translation for
> + * @da: device address to translate
> + * @len: length of the memory buffer
> + *
> + * Custom function implementing the rproc .da_to_va ops to provide address
> + * translation (device address to kernel virtual address) for internal RAMs
> + * present in a DSP or IPU device). The translated addresses can be used
> + * either by the remoteproc core for loading, or by any rpmsg bus drivers.
> + * Returns the translated virtual address in kernel memory space, or NULL
> + * in failure.
> + */
> +static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> +{
> +	struct omap_rproc *oproc = rproc->priv;
> +	int i;
> +	u32 offset;
> +
> +	if (len <= 0)
> +		return NULL;
> +
> +	if (!oproc->num_mems)
> +		return NULL;
> +
> +	for (i = 0; i < oproc->num_mems; i++) {
> +		if (da >= oproc->mem[i].dev_addr && da + len <=

Shouldn't this be '<' rather than '<=' ?

> +		    oproc->mem[i].dev_addr +  oproc->mem[i].size) {

One space too many after the '+' .

> +			offset = da -  oproc->mem[i].dev_addr;

One space too many after then '-' .

> +			/* __force to make sparse happy with type conversion */
> +			return (__force void *)(oproc->mem[i].cpu_addr +
> +						offset);
> +		}
> +	}
> +
> +	return NULL;
> +}
> +
>  static const struct rproc_ops omap_rproc_ops = {
>  	.start		= omap_rproc_start,
>  	.stop		= omap_rproc_stop,
>  	.kick		= omap_rproc_kick,
> +	.da_to_va	= omap_rproc_da_to_va,
>  };
>  
>  static const char * const ipu_mem_names[] = {
> -- 
> 2.17.1
> 
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 07/15] remoteproc/omap: Add support for DRA7xx remote processors
  2019-12-13 12:55 ` [PATCHv3 07/15] remoteproc/omap: Add support for DRA7xx remote processors Tero Kristo
@ 2019-12-18 21:31   ` Mathieu Poirier
  2019-12-19 13:29     ` Tero Kristo
  0 siblings, 1 reply; 50+ messages in thread
From: Mathieu Poirier @ 2019-12-18 21:31 UTC (permalink / raw)
  To: Tero Kristo
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna

On Fri, Dec 13, 2019 at 02:55:29PM +0200, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
> 
> DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems
> for offloading different computation algorithms. The IPU processor
> subsystem contains dual-core ARM Cortex-M4 processors, and is very
> similar to those on OMAP5. The DSP processor subsystem is based on
> the TI's standard TMS320C66x DSP CorePac core.
> 
> Support has been added to the OMAP remoteproc driver through new
> DRA7xx specific compatibles for properly probing and booting all
> the different processor subsystem instances on DRA7xx/AM57xx
> SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX
> is added to enable the driver to be built in DRA7xx-only configuration.
> 
> The DSP boot address programming needed enhancement for DRA7xx as the
> boot register fields are different on DRA7 compared to OMAP4 and OMAP5
> SoCs. The register on DRA7xx contains additional fields within the
> register and the boot address bit-field is right-shifted by 10 bits.
> The internal memory parsing logic has also been updated to compute
> the device addresses for the L2 RAM for DSP devices using relative
> addressing logic, and to parse two additional RAMs at L1 level - L1P
> and L1D. This allows the remoteproc driver to support loading into
> these regions for a small subset of firmware images requiring as
> such. The most common usage would be to use the L1 programmable
> RAMs as L1 Caches.
> 
> The firmware lookup logic also has to be adjusted for DRA7xx as
> there are (can be) more than one instance of both the IPU and DSP
> remote processors for the first time in OMAP4+ SoCs.
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> [t-kristo@ti.com: moved address translation quirks to pdata]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  drivers/remoteproc/Kconfig           |  2 +-
>  drivers/remoteproc/omap_remoteproc.c | 44 +++++++++++++++++++++++++++-
>  2 files changed, 44 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 94afdde4bc9f..d6450d7fcf92 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -25,7 +25,7 @@ config IMX_REMOTEPROC
>  
>  config OMAP_REMOTEPROC
>  	tristate "OMAP remoteproc support"
> -	depends on ARCH_OMAP4 || SOC_OMAP5
> +	depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX
>  	depends on OMAP_IOMMU
>  	select MAILBOX
>  	select OMAP2PLUS_MBOX
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index 3ad74c4b4071..6cf7f0a9ba9a 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -34,10 +34,13 @@
>   * struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
>   * @syscon: regmap handle for the system control configuration module
>   * @boot_reg: boot register offset within the @syscon regmap
> + * @boot_reg_shift: bit-field shift required for the boot address value in
> + *		    @boot_reg
>   */
>  struct omap_rproc_boot_data {
>  	struct regmap *syscon;
>  	unsigned int boot_reg;
> +	unsigned int boot_reg_shift;
>  };
>  
>  /*
> @@ -78,12 +81,14 @@ struct omap_rproc {
>   * struct omap_rproc_dev_data - device data for the omap remote processor
>   * @device_name: device name of the remote processor
>   * @has_bootreg: true if this remote processor has boot register
> + * @boot_reg_shift: bit shift for the boot register mask
>   * @mem_names: memory names for this remote processor
>   * @dev_addrs: device addresses corresponding to the memory names
>   */
>  struct omap_rproc_dev_data {
>  	const char *device_name;
>  	bool has_bootreg;
> +	int boot_reg_shift;
>  	const char * const *mem_names;
>  	const u32 *dev_addrs;
>  };
> @@ -153,6 +158,8 @@ static int omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
>  	struct omap_rproc *oproc = rproc->priv;
>  	struct omap_rproc_boot_data *bdata = oproc->boot_data;
>  	u32 offset = bdata->boot_reg;
> +	u32 value;
> +	u32 mask;
>  
>  	if (rproc->bootaddr & (SZ_1K - 1)) {
>  		dev_err(dev, "invalid boot address 0x%x, must be aligned on a 1KB boundary\n",
> @@ -160,7 +167,10 @@ static int omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
>  		return -EINVAL;
>  	}
>  
> -	regmap_write(bdata->syscon, offset, rproc->bootaddr);
> +	value = rproc->bootaddr >> bdata->boot_reg_shift;
> +	mask = ~(SZ_1K - 1) >> bdata->boot_reg_shift;
> +
> +	regmap_update_bits(bdata->syscon, offset, mask, value);
>  
>  	return 0;
>  }
> @@ -286,6 +296,14 @@ static const u32 ipu_dev_addrs[] = {
>  	0x20000000,
>  };
>  
> +static const char * const dra7_dsp_mem_names[] = {
> +	"l2ram", "l1pram", "l1dram", NULL
> +};
> +
> +static const u32 dra7_dsp_dev_addrs[] = {
> +	0x800000, 0xe00000, 0xf00000,
> +};
> +
>  static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>  	.device_name	= "dsp",
>  	.has_bootreg	= true,
> @@ -308,6 +326,20 @@ static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
>  	.dev_addrs	= ipu_dev_addrs,
>  };
>  
> +static const struct omap_rproc_dev_data dra7_dsp_dev_data = {
> +	.device_name	= "dsp",
> +	.has_bootreg	= true,

Shouldn't this be solely driven from the DT?  If the "ti,bootreg" is specified
then we can count on omap_rproc::boot_data to provide the same functionality.   


> +	.boot_reg_shift	= 10,

I also think this should be driven from the DT.  Otherwise some information is
from the DT and other is hard coded in the omap_rproc_dev_data.

> +	.mem_names	= dra7_dsp_mem_names,
> +	.dev_addrs	= dra7_dsp_dev_addrs,
> +};
> +
> +static const struct omap_rproc_dev_data dra7_ipu_dev_data = {
> +	.device_name	= "ipu",
> +	.mem_names	= ipu_mem_names,
> +	.dev_addrs	= ipu_dev_addrs,
> +};
> +
>  static const struct of_device_id omap_rproc_of_match[] = {
>  	{
>  		.compatible     = "ti,omap4-dsp",
> @@ -325,6 +357,14 @@ static const struct of_device_id omap_rproc_of_match[] = {
>  		.compatible     = "ti,omap5-ipu",
>  		.data           = &omap5_ipu_dev_data,
>  	},
> +	{
> +		.compatible     = "ti,dra7-dsp",
> +		.data           = &dra7_dsp_dev_data,
> +	},
> +	{
> +		.compatible     = "ti,dra7-ipu",
> +		.data           = &dra7_ipu_dev_data,
> +	},
>  	{
>  		/* end */
>  	},
> @@ -382,6 +422,8 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev,
>  		return -EINVAL;
>  	}
>  
> +	oproc->boot_data->boot_reg_shift = data->boot_reg_shift;
> +
>  	return 0;
>  }
>  
> -- 
> 2.17.1
> 
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 11/15] remoteproc/omap: Request a timer(s) for remoteproc usage
  2019-12-13 12:55 ` [PATCHv3 11/15] remoteproc/omap: Request a timer(s) for remoteproc usage Tero Kristo
@ 2019-12-18 22:43   ` Mathieu Poirier
  2019-12-19 13:43     ` Tero Kristo
  0 siblings, 1 reply; 50+ messages in thread
From: Mathieu Poirier @ 2019-12-18 22:43 UTC (permalink / raw)
  To: Tero Kristo
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna

On Fri, Dec 13, 2019 at 02:55:33PM +0200, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
> 
> The remote processors in OMAP4+ SoCs are equipped with internal
> timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or
> the CTM timer within Unicache in IPU & DSP. However, these timers
> are gated when the processor subsystem clock is gated, making
> them rather difficult to use as OS tick sources. They will not
> be able to wakeup the processor from any processor-sleep induced
> clock-gating states.
> 
> This can be avoided by using an external timer as the tick source,
> which can be controlled independently by the OMAP remoteproc
> driver code, but still allowing the processor subsystem clock to
> be auto-gated when the remoteproc cores are idle.
> 
> This patch adds the support for OMAP remote processors to request
> timer(s) to be used by the remoteproc. The timers are enabled and
> disabled in line with the enabling/disabling of the remoteproc.
> The timer data is not mandatory if the advanced device management
> features are not required.
> 
> The core timer functionality is provided by the OMAP DMTimer
> clocksource driver, which does not export any API. The logic is
> implemented through the timer device's platform data ops. The OMAP
> remoteproc driver mainly requires ops to request/free a dmtimer,
> and to start/stop a timer. The split ops helps in controlling the
> timer state without having to request and release a timer everytime
> it needs to use the timer.
> 
> NOTE: If the gptimer is already in use by the time IPU and/or
> DSP are loaded, the processors will fail to boot.
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  drivers/remoteproc/omap_remoteproc.c | 258 +++++++++++++++++++++++++++
>  1 file changed, 258 insertions(+)
> 
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index 841981c50d8d..9c750c2ab29d 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -26,6 +26,9 @@
>  #include <linux/regmap.h>
>  #include <linux/mfd/syscon.h>
>  #include <linux/reset.h>
> +#include <clocksource/timer-ti-dm.h>
> +
> +#include <linux/platform_data/dmtimer-omap.h>
>  
>  #include "omap_remoteproc.h"
>  #include "remoteproc_internal.h"
> @@ -57,6 +60,16 @@ struct omap_rproc_mem {
>  	size_t size;
>  };
>  
> +/**
> + * struct omap_rproc_timer - data structure for a timer used by a omap rproc
> + * @odt: timer pointer
> + * @timer_ops: OMAP dmtimer ops for @odt timer
> + */
> +struct omap_rproc_timer {
> +	struct omap_dm_timer *odt;
> +	const struct omap_dm_timer_ops *timer_ops;
> +};
> +
>  /**
>   * struct omap_rproc - omap remote processor state
>   * @mbox: mailbox channel handle
> @@ -64,6 +77,8 @@ struct omap_rproc_mem {
>   * @boot_data: boot data structure for setting processor boot address
>   * @mem: internal memory regions data
>   * @num_mems: number of internal memory regions
> + * @num_timers: number of rproc timer(s)
> + * @timers: timer(s) info used by rproc
>   * @rproc: rproc handle
>   * @reset: reset handle
>   */
> @@ -73,6 +88,8 @@ struct omap_rproc {
>  	struct omap_rproc_boot_data *boot_data;
>  	struct omap_rproc_mem *mem;
>  	int num_mems;
> +	int num_timers;
> +	struct omap_rproc_timer *timers;
>  	struct rproc *rproc;
>  	struct reset_control *reset;
>  };
> @@ -93,6 +110,213 @@ struct omap_rproc_dev_data {
>  	const u32 *dev_addrs;
>  };
>  
> +/**
> + * omap_rproc_request_timer() - request a timer for a remoteproc
> + * @dev: device requesting the timer
> + * @np: device node pointer to the desired timer
> + * @timer: handle to a struct omap_rproc_timer to return the timer handle
> + *
> + * This helper function is used primarily to request a timer associated with
> + * a remoteproc. The returned handle is stored in the .odt field of the
> + * @timer structure passed in, and is used to invoke other timer specific
> + * ops (like starting a timer either during device initialization or during
> + * a resume operation, or for stopping/freeing a timer).
> + *
> + * Returns 0 on success, otherwise an appropriate failure
> + */
> +static int omap_rproc_request_timer(struct device *dev, struct device_node *np,
> +				    struct omap_rproc_timer *timer)
> +{
> +	int ret;
> +
> +	timer->odt = timer->timer_ops->request_by_node(np);
> +	if (!timer->odt) {
> +		dev_err(dev, "request for timer node %p failed\n", np);
> +		return -EBUSY;
> +	}
> +
> +	ret = timer->timer_ops->set_source(timer->odt, OMAP_TIMER_SRC_SYS_CLK);
> +	if (ret) {
> +		dev_err(dev, "error setting OMAP_TIMER_SRC_SYS_CLK as source for timer node %p\n",
> +			np);
> +		timer->timer_ops->free(timer->odt);
> +		return ret;
> +	}
> +
> +	/* clean counter, remoteproc code will set the value */
> +	timer->timer_ops->set_load(timer->odt, 0, 0);
> +
> +	return 0;
> +}
> +
> +/**
> + * omap_rproc_start_timer - start a timer for a remoteproc
> + * @timer: handle to a OMAP rproc timer
> + *
> + * This helper function is used to start a timer associated with a remoteproc,
> + * obtained using the request_timer ops. The helper function needs to be
> + * invoked by the driver to start the timer (during device initialization)
> + * or to just resume the timer.
> + *
> + * Returns 0 on success, otherwise a failure as returned by DMTimer ops
> + */
> +static inline int omap_rproc_start_timer(struct omap_rproc_timer *timer)
> +{
> +	return timer->timer_ops->start(timer->odt);
> +}
> +
> +/**
> + * omap_rproc_stop_timer - stop a timer for a remoteproc
> + * @timer: handle to a OMAP rproc timer
> + *
> + * This helper function is used to disable a timer associated with a
> + * remoteproc, and needs to be called either during a device shutdown
> + * or suspend operation. The separate helper function allows the driver
> + * to just stop a timer without having to release the timer during a
> + * suspend operation.
> + *
> + * Returns 0 on success, otherwise a failure as returned by DMTimer ops
> + */
> +static inline int omap_rproc_stop_timer(struct omap_rproc_timer *timer)
> +{
> +	return timer->timer_ops->stop(timer->odt);
> +}
> +
> +/**
> + * omap_rproc_release_timer - release a timer for a remoteproc
> + * @timer: handle to a OMAP rproc timer
> + *
> + * This helper function is used primarily to release a timer associated
> + * with a remoteproc. The dmtimer will be available for other clients to
> + * use once released.
> + *
> + * Returns 0 on success, otherwise a failure as returned by DMTimer ops
> + */
> +static inline int omap_rproc_release_timer(struct omap_rproc_timer *timer)
> +{
> +	return timer->timer_ops->free(timer->odt);
> +}
> +
> +/**
> + * omap_rproc_enable_timers - enable the timers for a remoteproc
> + * @rproc: handle of a remote processor
> + * @configure: boolean flag used to acquire and configure the timer handle
> + *
> + * This function is used primarily to enable the timers associated with
> + * a remoteproc. The configure flag is provided to allow the driver to
> + * to either acquire and start a timer (during device initialization) or
> + * to just start a timer (during a resume operation).
> + */
> +static int omap_rproc_enable_timers(struct rproc *rproc, bool configure)
> +{
> +	int i;
> +	int ret = 0;
> +	struct platform_device *tpdev;
> +	struct dmtimer_platform_data *tpdata;
> +	const struct omap_dm_timer_ops *timer_ops;
> +	struct omap_rproc *oproc = rproc->priv;
> +	struct omap_rproc_timer *timers = oproc->timers;
> +	struct device *dev = rproc->dev.parent;
> +	struct device_node *np = NULL;
> +
> +	if (oproc->num_timers <= 0)
> +		return 0;

Given the code in omap_rproc_probe() ->num_timers can only be >= 0.

> +
> +	if (!configure)
> +		goto start_timers;
> +
> +	for (i = 0; i < oproc->num_timers; i++) {
> +		np = of_parse_phandle(dev->of_node, "ti,timers", i);
> +		if (!np) {
> +			ret = -ENXIO;
> +			dev_err(dev, "device node lookup for timer at index %d failed: %d\n",
> +				i, ret);
> +			goto free_timers;
> +		}
> +
> +		tpdev = of_find_device_by_node(np);
> +		if (!tpdev) {
> +			ret = -ENODEV;
> +			dev_err(dev, "could not get timer platform device\n");
> +			goto put_node;
> +		}
> +
> +		tpdata = dev_get_platdata(&tpdev->dev);
> +		put_device(&tpdev->dev);
> +		if (!tpdata) {
> +			ret = -EINVAL;
> +			dev_err(dev, "dmtimer pdata structure NULL\n");
> +			goto put_node;
> +		}
> +
> +		timer_ops = tpdata->timer_ops;
> +		if (!timer_ops || !timer_ops->request_by_node ||
> +		    !timer_ops->set_source || !timer_ops->set_load ||
> +		    !timer_ops->free || !timer_ops->start ||
> +		    !timer_ops->stop) {
> +			ret = -EINVAL;
> +			dev_err(dev, "device does not have required timer ops\n");
> +			goto put_node;
> +		}
> +
> +		timers[i].timer_ops = timer_ops;
> +		ret = omap_rproc_request_timer(dev, np, &timers[i]);
> +		if (ret) {
> +			dev_err(dev, "request for timer %p failed: %d\n", np,
> +				ret);
> +			goto put_node;
> +		}
> +		of_node_put(np);
> +	}
> +
> +start_timers:
> +	for (i = 0; i < oproc->num_timers; i++)
> +		omap_rproc_start_timer(&timers[i]);

The return code for omap_rproc_start_timer() is ignored.  If this is intentional
then adding a comment to justify the choice is probably a good idea.  Otherwise
please consider refactoring.

> +	return 0;
> +
> +put_node:
> +	of_node_put(np);
> +free_timers:
> +	while (i--) {
> +		omap_rproc_release_timer(&timers[i]);
> +		timers[i].odt = NULL;
> +		timers[i].timer_ops = NULL;
> +	}
> +
> +	return ret;
> +}
> +
> +/**
> + * omap_rproc_disable_timers - disable the timers for a remoteproc
> + * @rproc: handle of a remote processor
> + * @configure: boolean flag used to release the timer handle
> + *
> + * This function is used primarily to disable the timers associated with
> + * a remoteproc. The configure flag is provided to allow the driver to
> + * to either stop and release a timer (during device shutdown) or to just
> + * stop a timer (during a suspend operation).
> + */
> +static int omap_rproc_disable_timers(struct rproc *rproc, bool configure)
> +{
> +	int i;
> +	struct omap_rproc *oproc = rproc->priv;
> +	struct omap_rproc_timer *timers = oproc->timers;
> +
> +	if (oproc->num_timers <= 0)

Same comment as above.

> +		return 0;
> +
> +	for (i = 0; i < oproc->num_timers; i++) {
> +		omap_rproc_stop_timer(&timers[i]);
> +		if (configure) {
> +			omap_rproc_release_timer(&timers[i]);
> +			timers[i].odt = NULL;
> +			timers[i].timer_ops = NULL;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
>  /**
>   * omap_rproc_mbox_callback() - inbound mailbox message handler
>   * @client: mailbox client pointer used for requesting the mailbox channel
> @@ -228,6 +452,12 @@ static int omap_rproc_start(struct rproc *rproc)
>  		goto put_mbox;
>  	}
>  
> +	ret = omap_rproc_enable_timers(rproc, true);
> +	if (ret) {
> +		dev_err(dev, "omap_rproc_enable_timers failed: %d\n", ret);
> +		goto put_mbox;
> +	}
> +
>  	reset_control_deassert(oproc->reset);
>  
>  	return 0;
> @@ -241,9 +471,14 @@ static int omap_rproc_start(struct rproc *rproc)
>  static int omap_rproc_stop(struct rproc *rproc)
>  {
>  	struct omap_rproc *oproc = rproc->priv;
> +	int ret;
>  
>  	reset_control_assert(oproc->reset);
>  
> +	ret = omap_rproc_disable_timers(rproc, true);
> +	if (ret)
> +		return ret;
> +
>  	mbox_free_channel(oproc->mbox);
>  
>  	return 0;
> @@ -528,6 +763,29 @@ static int omap_rproc_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto free_rproc;
>  
> +	/*
> +	 * Timer nodes are directly used in client nodes as phandles, so
> +	 * retrieve the count using appropriate size
> +	 */
> +	oproc->num_timers = of_count_phandle_with_args(np, "ti,timers", NULL);
> +	if (oproc->num_timers <= 0) {
> +		dev_dbg(&pdev->dev, "device does not have timers, status = %d\n",
> +			oproc->num_timers);
> +		oproc->num_timers = 0;
> +	}
> +
> +	if (oproc->num_timers) {
> +		oproc->timers = devm_kzalloc(&pdev->dev, sizeof(*oproc->timers)
> +					     * oproc->num_timers, GFP_KERNEL);

Please use devm_kcalloc().

More comments to come tomorrow,
Mathieu

> +		if (!oproc->timers) {
> +			ret = -ENOMEM;
> +			goto free_rproc;
> +		}
> +
> +		dev_dbg(&pdev->dev, "device has %d tick timers\n",
> +			oproc->num_timers);
> +	}
> +
>  	ret = of_reserved_mem_device_init(&pdev->dev);
>  	if (ret) {
>  		dev_err(&pdev->dev, "device does not have specific CMA pool\n");
> -- 
> 2.17.1
> 
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 02/15] remoteproc/omap: Add device tree support
  2019-12-17 23:01   ` Mathieu Poirier
@ 2019-12-19 11:54     ` Tero Kristo
  2019-12-20  2:08       ` Suman Anna
  0 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-19 11:54 UTC (permalink / raw)
  To: Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna, Tony Lindgren

On 18/12/2019 01:01, Mathieu Poirier wrote:
> Hi Tero,
> 
> On Fri, Dec 13, 2019 at 02:55:24PM +0200, Tero Kristo wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> OMAP4+ SoCs support device tree boot only. The OMAP remoteproc
>> driver is enhanced to support remoteproc devices created through
>> Device Tree, support for legacy platform devices has been
>> deprecated. The current DT support handles the IPU and DSP
>> processor subsystems on OMAP4 and OMAP5 SoCs.
>>
>> The OMAP remoteproc driver relies on the ti-sysc, reset, and
>> syscon layers for performing clock, reset and boot vector
>> management (DSP remoteprocs only) of the devices, but some of
>> these are limited only to the machine-specific layers
>> in arch/arm. The dependency against control module API for boot
>> vector management of the DSP remoteprocs has now been removed
>> with added logic to parse the boot register from the DT node
>> and program it appropriately directly within the driver.
>>
>> The OMAP remoteproc driver expects the firmware names to be
>> provided via device tree entries (firmware-name.) These are used
>> to load the proper firmware during boot of the remote processor.
>>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> [t-kristo@ti.com: converted to use ti-sysc framework]
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>   drivers/remoteproc/omap_remoteproc.c | 191 +++++++++++++++++++++++----
>>   1 file changed, 168 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>> index 6398194075aa..558634624590 100644
>> --- a/drivers/remoteproc/omap_remoteproc.c
>> +++ b/drivers/remoteproc/omap_remoteproc.c
>> @@ -2,7 +2,7 @@
>>   /*
>>    * OMAP Remote Processor driver
>>    *
>> - * Copyright (C) 2011 Texas Instruments, Inc.
>> + * Copyright (C) 2011-2019 Texas Instruments Incorporated - http://www.ti.com/
>>    * Copyright (C) 2011 Google, Inc.
>>    *
>>    * Ohad Ben-Cohen <ohad@wizery.com>
>> @@ -16,27 +16,53 @@
>>   #include <linux/kernel.h>
>>   #include <linux/module.h>
>>   #include <linux/err.h>
>> +#include <linux/of_device.h>
>>   #include <linux/platform_device.h>
>>   #include <linux/dma-mapping.h>
>>   #include <linux/remoteproc.h>
>>   #include <linux/mailbox_client.h>
>>   #include <linux/omap-mailbox.h>
>> -
>> -#include <linux/platform_data/remoteproc-omap.h>
>> +#include <linux/regmap.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/reset.h>
>>   
>>   #include "omap_remoteproc.h"
>>   #include "remoteproc_internal.h"
>>   
>> +/**
>> + * struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
>> + * @syscon: regmap handle for the system control configuration module
>> + * @boot_reg: boot register offset within the @syscon regmap
>> + */
>> +struct omap_rproc_boot_data {
>> +	struct regmap *syscon;
>> +	unsigned int boot_reg;
>> +};
>> +
>>   /**
>>    * struct omap_rproc - omap remote processor state
>>    * @mbox: mailbox channel handle
>>    * @client: mailbox client to request the mailbox channel
>> + * @boot_data: boot data structure for setting processor boot address
>>    * @rproc: rproc handle
>> + * @reset: reset handle
>>    */
>>   struct omap_rproc {
>>   	struct mbox_chan *mbox;
>>   	struct mbox_client client;
>> +	struct omap_rproc_boot_data *boot_data;
>>   	struct rproc *rproc;
>> +	struct reset_control *reset;
>> +};
>> +
>> +/**
>> + * struct omap_rproc_dev_data - device data for the omap remote processor
>> + * @device_name: device name of the remote processor
>> + * @has_bootreg: true if this remote processor has boot register
>> + */
>> +struct omap_rproc_dev_data {
>> +	const char *device_name;
>> +	bool has_bootreg;
>>   };
>>   
>>   /**
>> @@ -92,6 +118,21 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
>>   			ret);
>>   }
>>   
>> +/**
>> + * omap_rproc_write_dsp_boot_addr - set boot address for a DSP remote processor
>> + * @rproc: handle of a remote processor
>> + *
>> + * Set boot address for a supported DSP remote processor.
>> + */
>> +static void omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
>> +{
>> +	struct omap_rproc *oproc = rproc->priv;
>> +	struct omap_rproc_boot_data *bdata = oproc->boot_data;
>> +	u32 offset = bdata->boot_reg;
>> +
>> +	regmap_write(bdata->syscon, offset, rproc->bootaddr);
>> +}
>> +
>>   /*
>>    * Power up the remote processor.
>>    *
>> @@ -103,13 +144,11 @@ static int omap_rproc_start(struct rproc *rproc)
>>   {
>>   	struct omap_rproc *oproc = rproc->priv;
>>   	struct device *dev = rproc->dev.parent;
>> -	struct platform_device *pdev = to_platform_device(dev);
>> -	struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>>   	int ret;
>>   	struct mbox_client *client = &oproc->client;
>>   
>> -	if (pdata->set_bootaddr)
>> -		pdata->set_bootaddr(rproc->bootaddr);
>> +	if (oproc->boot_data)
>> +		omap_rproc_write_dsp_boot_addr(rproc);
>>   
>>   	client->dev = dev;
>>   	client->tx_done = NULL;
>> @@ -117,7 +156,7 @@ static int omap_rproc_start(struct rproc *rproc)
>>   	client->tx_block = false;
>>   	client->knows_txdone = false;
>>   
>> -	oproc->mbox = omap_mbox_request_channel(client, pdata->mbox_name);
>> +	oproc->mbox = mbox_request_channel(client, 0);
>>   	if (IS_ERR(oproc->mbox)) {
>>   		ret = -EBUSY;
>>   		dev_err(dev, "mbox_request_channel failed: %ld\n",
>> @@ -138,11 +177,7 @@ static int omap_rproc_start(struct rproc *rproc)
>>   		goto put_mbox;
>>   	}
>>   
>> -	ret = pdata->device_enable(pdev);
>> -	if (ret) {
>> -		dev_err(dev, "omap_device_enable failed: %d\n", ret);
>> -		goto put_mbox;
>> -	}
>> +	reset_control_deassert(oproc->reset);
>>   
>>   	return 0;
>>   
>> @@ -154,15 +189,9 @@ static int omap_rproc_start(struct rproc *rproc)
>>   /* power off the remote processor */
>>   static int omap_rproc_stop(struct rproc *rproc)
>>   {
>> -	struct device *dev = rproc->dev.parent;
>> -	struct platform_device *pdev = to_platform_device(dev);
>> -	struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>>   	struct omap_rproc *oproc = rproc->priv;
>> -	int ret;
>>   
>> -	ret = pdata->device_shutdown(pdev);
>> -	if (ret)
>> -		return ret;
>> +	reset_control_assert(oproc->reset);
>>   
>>   	mbox_free_channel(oproc->mbox);
>>   
>> @@ -175,12 +204,122 @@ static const struct rproc_ops omap_rproc_ops = {
>>   	.kick		= omap_rproc_kick,
>>   };
>>   
>> +static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>> +	.device_name	= "dsp",
>> +	.has_bootreg	= true,
>> +};
>> +
>> +static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
>> +	.device_name	= "ipu",
>> +};
>> +
>> +static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
>> +	.device_name	= "dsp",
>> +	.has_bootreg	= true,
>> +};
>> +
>> +static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
>> +	.device_name	= "ipu",
>> +};
>> +
>> +static const struct of_device_id omap_rproc_of_match[] = {
>> +	{
>> +		.compatible     = "ti,omap4-dsp",
>> +		.data           = &omap4_dsp_dev_data,
>> +	},
>> +	{
>> +		.compatible     = "ti,omap4-ipu",
>> +		.data           = &omap4_ipu_dev_data,
>> +	},
>> +	{
>> +		.compatible     = "ti,omap5-dsp",
>> +		.data           = &omap5_dsp_dev_data,
>> +	},
>> +	{
>> +		.compatible     = "ti,omap5-ipu",
>> +		.data           = &omap5_ipu_dev_data,
>> +	},
>> +	{
>> +		/* end */
>> +	},
>> +};
>> +MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
>> +
>> +static const char *omap_rproc_get_firmware(struct platform_device *pdev)
>> +{
>> +	const char *fw_name;
>> +	int ret;
>> +
>> +	ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
>> +				      &fw_name);
>> +	if (ret)
>> +		return ERR_PTR(ret);
>> +
>> +	return fw_name;
>> +}
>> +
>> +static int omap_rproc_get_boot_data(struct platform_device *pdev,
>> +				    struct rproc *rproc)
>> +{
>> +	struct device_node *np = pdev->dev.of_node;
>> +	struct omap_rproc *oproc = rproc->priv;
>> +	const struct omap_rproc_dev_data *data;
>> +	int ret;
>> +
>> +	data = of_device_get_match_data(&pdev->dev);
>> +	if (!data)
>> +		return -ENODEV;
>> +
>> +	if (!data->has_bootreg)
>> +		return 0;
>> +
>> +	oproc->boot_data = devm_kzalloc(&pdev->dev, sizeof(*oproc->boot_data),
>> +					GFP_KERNEL);
>> +	if (!oproc->boot_data)
>> +		return -ENOMEM;
>> +
>> +	if (!of_property_read_bool(np, "ti,bootreg")) {
>> +		dev_err(&pdev->dev, "ti,bootreg property is missing\n");
>> +		return -EINVAL;
>> +	}
>> +
>> +	oproc->boot_data->syscon =
>> +			syscon_regmap_lookup_by_phandle(np, "ti,bootreg");
>> +	if (IS_ERR(oproc->boot_data->syscon)) {
>> +		ret = PTR_ERR(oproc->boot_data->syscon);
>> +		return ret;
>> +	}
>> +
>> +	if (of_property_read_u32_index(np, "ti,bootreg", 1,
>> +				       &oproc->boot_data->boot_reg)) {
>> +		dev_err(&pdev->dev, "couldn't get the boot register\n");
>> +		return -EINVAL;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>   static int omap_rproc_probe(struct platform_device *pdev)
>>   {
>> -	struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>> +	struct device_node *np = pdev->dev.of_node;
>>   	struct omap_rproc *oproc;
>>   	struct rproc *rproc;
>> +	const char *firmware;
>>   	int ret;
>> +	struct reset_control *reset;
>> +
>> +	if (!np) {
>> +		dev_err(&pdev->dev, "only DT-based devices are supported\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	reset = devm_reset_control_array_get_optional_exclusive(&pdev->dev);
>> +	if (IS_ERR(reset))
>> +		return PTR_ERR(reset);
> 
> Definition of a reset is listed as "required" in the bindings but here it is
> optional.  If this is really what you want then adding a comment to exlain your
> choice is probably a good idea.

Right, I think I updated the binding to require this but forgot to 
update the driver for this part. Will fix this.

-Tero

> 
>> +
>> +	firmware = omap_rproc_get_firmware(pdev);
>> +	if (IS_ERR(firmware))
>> +		return PTR_ERR(firmware);
>>   
>>   	ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
>>   	if (ret) {
>> @@ -188,16 +327,21 @@ static int omap_rproc_probe(struct platform_device *pdev)
>>   		return ret;
>>   	}
>>   
>> -	rproc = rproc_alloc(&pdev->dev, pdata->name, &omap_rproc_ops,
>> -			    pdata->firmware, sizeof(*oproc));
>> +	rproc = rproc_alloc(&pdev->dev, dev_name(&pdev->dev), &omap_rproc_ops,
>> +			    firmware, sizeof(*oproc));
>>   	if (!rproc)
>>   		return -ENOMEM;
>>   
>>   	oproc = rproc->priv;
>>   	oproc->rproc = rproc;
>> +	oproc->reset = reset;
>>   	/* All existing OMAP IPU and DSP processors have an MMU */
>>   	rproc->has_iommu = true;
>>   
>> +	ret = omap_rproc_get_boot_data(pdev, rproc);
>> +	if (ret)
>> +		goto free_rproc;
>> +
>>   	platform_set_drvdata(pdev, rproc);
>>   
>>   	ret = rproc_add(rproc);
>> @@ -226,6 +370,7 @@ static struct platform_driver omap_rproc_driver = {
>>   	.remove = omap_rproc_remove,
>>   	.driver = {
>>   		.name = "omap-rproc",
>> +		.of_match_table = omap_rproc_of_match,
> 
>                  .of_match_table = of_match_ptr(omap_rproc_of_match),
> 
> Thanks,
> Mathieu
> 
>>   	},
>>   };
>>   
>> -- 
>> 2.17.1
>>
>> --

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 04/15] remoteproc/omap: Add support to parse internal memories from DT
  2019-12-18  0:22   ` Mathieu Poirier
@ 2019-12-19 12:31     ` Tero Kristo
  2019-12-19 17:37       ` Mathieu Poirier
  0 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-19 12:31 UTC (permalink / raw)
  To: Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna

On 18/12/2019 02:22, Mathieu Poirier wrote:
> On Fri, Dec 13, 2019 at 02:55:26PM +0200, Tero Kristo wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> The OMAP remoteproc driver has been enhanced to parse and store
>> the kernel mappings for different internal RAM memories that may
>> be present within each remote processor IP subsystem. Different
>> devices have varying memories present on current SoCs. The current
>> support handles the L2RAM for all IPU devices on OMAP4+ SoCs. The
>> DSPs on OMAP4/OMAP5 only have Unicaches and do not have any L1 or
>> L2 RAM memories.
>>
>> IPUs are expected to have the L2RAM at a fixed device address of
>> 0x20000000, based on the current limitations on Attribute MMU
>> configurations.
>>
>> NOTE:
>> The current logic doesn't handle the parsing of memories for DRA7
>> remoteproc devices, and will be added alongside the DRA7 support.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> [t-kristo: converted to parse mem names / device addresses from pdata]
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>   drivers/remoteproc/omap_remoteproc.c | 86 ++++++++++++++++++++++++++++
>>   1 file changed, 86 insertions(+)
>>
>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>> index d80f5d7b5931..844703507a74 100644
>> --- a/drivers/remoteproc/omap_remoteproc.c
>> +++ b/drivers/remoteproc/omap_remoteproc.c
>> @@ -39,11 +39,27 @@ struct omap_rproc_boot_data {
>>   	unsigned int boot_reg;
>>   };
>>   
>> +/*
>> + * struct omap_rproc_mem - 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 of the memory region from DSP view
>> + * @size: size of the memory region
>> + */
>> +struct omap_rproc_mem {
>> +	void __iomem *cpu_addr;
>> +	phys_addr_t bus_addr;
>> +	u32 dev_addr;
>> +	size_t size;
>> +};
>> +
>>   /**
>>    * struct omap_rproc - omap remote processor state
>>    * @mbox: mailbox channel handle
>>    * @client: mailbox client to request the mailbox channel
>>    * @boot_data: boot data structure for setting processor boot address
>> + * @mem: internal memory regions data
>> + * @num_mems: number of internal memory regions
>>    * @rproc: rproc handle
>>    * @reset: reset handle
>>    */
>> @@ -51,6 +67,8 @@ struct omap_rproc {
>>   	struct mbox_chan *mbox;
>>   	struct mbox_client client;
>>   	struct omap_rproc_boot_data *boot_data;
>> +	struct omap_rproc_mem *mem;
>> +	int num_mems;
>>   	struct rproc *rproc;
>>   	struct reset_control *reset;
>>   };
>> @@ -59,10 +77,14 @@ struct omap_rproc {
>>    * struct omap_rproc_dev_data - device data for the omap remote processor
>>    * @device_name: device name of the remote processor
>>    * @has_bootreg: true if this remote processor has boot register
>> + * @mem_names: memory names for this remote processor
>> + * @dev_addrs: device addresses corresponding to the memory names
>>    */
>>   struct omap_rproc_dev_data {
>>   	const char *device_name;
>>   	bool has_bootreg;
>> +	const char * const *mem_names;
>> +	const u32 *dev_addrs;
> 
> Bunching these two in a new structure like omap_rproc_mem_data would clean
> things up.  That way the two arrays in the next hunk get merged and there can't
> be a difference in sizes, somthing that will sturdy the main loop in
> omap_rproc_of_get_internal_memories() below.

Will fix this.

> 
>>   };
>>   
>>   /**
>> @@ -216,6 +238,14 @@ static const struct rproc_ops omap_rproc_ops = {
>>   	.kick		= omap_rproc_kick,
>>   };
>>   
>> +static const char * const ipu_mem_names[] = {
>> +	"l2ram", NULL
>> +};
>> +
>> +static const u32 ipu_dev_addrs[] = {
>> +	0x20000000,
>> +};
>> +
>>   static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>>   	.device_name	= "dsp",
>>   	.has_bootreg	= true,
>> @@ -223,6 +253,8 @@ static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>>   
>>   static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
>>   	.device_name	= "ipu",
>> +	.mem_names	= ipu_mem_names,
>> +	.dev_addrs	= ipu_dev_addrs,
>>   };
>>   
>>   static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
>> @@ -232,6 +264,8 @@ static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
>>   
>>   static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
>>   	.device_name	= "ipu",
>> +	.mem_names	= ipu_mem_names,
>> +	.dev_addrs	= ipu_dev_addrs,
>>   };
>>   
>>   static const struct of_device_id omap_rproc_of_match[] = {
>> @@ -311,6 +345,54 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev,
>>   	return 0;
>>   }
>>   
>> +static int omap_rproc_of_get_internal_memories(struct platform_device *pdev,
>> +					       struct rproc *rproc)
>> +{
>> +	struct omap_rproc *oproc = rproc->priv;
>> +	struct device *dev = &pdev->dev;
>> +	const struct omap_rproc_dev_data *data;
>> +	struct resource *res;
>> +	int num_mems;
>> +	int i;
>> +
>> +	data = of_device_get_match_data(&pdev->dev);
>> +	if (!data)
>> +		return -ENODEV;
>> +
>> +	if (!data->mem_names)
>> +		return 0;
>> +
>> +	for (num_mems = 0; data->mem_names[num_mems]; num_mems++)
>> +		;
> 
> Instead of doing this function of_property_count_elems_of_size() can be used on
> the "reg" property.

Hmm right, but the problem is then we don't know if someone left out one 
of the memories in DT. We want to check the presence for all defined in 
the platform data.

> 
> In the loop below a check should be done to see if data->mem_data[i] (see above
> comment) is valid before calling platform_get_resource_byname().  If not then
> an error can be returned.

Will add a check to it.

-Tero

> 
> I'm running out of time for today - I will continue reviewing the other patches
> tomorrow.
> 
>> +
>> +	oproc->mem = devm_kcalloc(dev, num_mems, sizeof(*oproc->mem),
>> +				  GFP_KERNEL);
>> +	if (!oproc->mem)
>> +		return -ENOMEM;
>> +
>> +	for (i = 0; i < num_mems; i++) {
>> +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> +						   data->mem_names[i]);
>> +		oproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
>> +		if (IS_ERR(oproc->mem[i].cpu_addr)) {
>> +			dev_err(dev, "failed to parse and map %s memory\n",
>> +				data->mem_names[i]);
>> +			return PTR_ERR(oproc->mem[i].cpu_addr);
>> +		}
>> +		oproc->mem[i].bus_addr = res->start;
>> +		oproc->mem[i].dev_addr = data->dev_addrs[i];
>> +		oproc->mem[i].size = resource_size(res);
>> +
>> +		dev_dbg(dev, "memory %8s: bus addr %pa size 0x%x va %p da 0x%x\n",
>> +			data->mem_names[i], &oproc->mem[i].bus_addr,
>> +			oproc->mem[i].size, oproc->mem[i].cpu_addr,
>> +			oproc->mem[i].dev_addr);
>> +	}
>> +	oproc->num_mems = num_mems;
>> +
>> +	return 0;
>> +}
>> +
>>   static int omap_rproc_probe(struct platform_device *pdev)
>>   {
>>   	struct device_node *np = pdev->dev.of_node;
>> @@ -350,6 +432,10 @@ static int omap_rproc_probe(struct platform_device *pdev)
>>   	/* All existing OMAP IPU and DSP processors have an MMU */
>>   	rproc->has_iommu = true;
>>   
>> +	ret = omap_rproc_of_get_internal_memories(pdev, rproc);
>> +	if (ret)
>> +		goto free_rproc;
>> +
>>   	ret = omap_rproc_get_boot_data(pdev, rproc);
>>   	if (ret)
>>   		goto free_rproc;
>> -- 
>> 2.17.1
>>
>> --

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation
  2019-12-18  0:38   ` Mathieu Poirier
@ 2019-12-19 13:18     ` Tero Kristo
  2019-12-20  0:12       ` Mathieu Poirier
  0 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-19 13:18 UTC (permalink / raw)
  To: Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna

On 18/12/2019 02:38, Mathieu Poirier wrote:
> On Fri, Dec 13, 2019 at 02:55:27PM +0200, Tero Kristo wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> An implementation for the rproc ops .da_to_va() has been added
>> that provides the address translation between device addresses
>> to kernel virtual addresses for internal RAMs present on that
>> particular remote processor device. The implementation provides
>> the translations based on the addresses parsed and stored during
>> the probe.
>>
>> This ops gets invoked by the exported rproc_da_to_va() function
>> and allows the remoteproc core's ELF loader to be able to load
>> program data directly into the internal memories.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>   drivers/remoteproc/omap_remoteproc.c | 39 ++++++++++++++++++++++++++++
>>   1 file changed, 39 insertions(+)
>>
>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>> index 844703507a74..28f14e24b389 100644
>> --- a/drivers/remoteproc/omap_remoteproc.c
>> +++ b/drivers/remoteproc/omap_remoteproc.c
>> @@ -232,10 +232,49 @@ static int omap_rproc_stop(struct rproc *rproc)
>>   	return 0;
>>   }
>>   
>> +/**
>> + * omap_rproc_da_to_va() - internal memory translation helper
>> + * @rproc: remote processor to apply the address translation for
>> + * @da: device address to translate
>> + * @len: length of the memory buffer
>> + *
>> + * Custom function implementing the rproc .da_to_va ops to provide address
>> + * translation (device address to kernel virtual address) for internal RAMs
>> + * present in a DSP or IPU device). The translated addresses can be used
>> + * either by the remoteproc core for loading, or by any rpmsg bus drivers.
>> + * Returns the translated virtual address in kernel memory space, or NULL
>> + * in failure.
>> + */
>> +static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
>> +{
>> +	struct omap_rproc *oproc = rproc->priv;
>> +	int i;
>> +	u32 offset;
>> +
>> +	if (len <= 0)
>> +		return NULL;
>> +
>> +	if (!oproc->num_mems)
>> +		return NULL;
>> +
>> +	for (i = 0; i < oproc->num_mems; i++) {
>> +		if (da >= oproc->mem[i].dev_addr && da + len <=
> 
> Shouldn't this be '<' rather than '<=' ?

No, I think <= is correct. You need to consider the initial byte in the 
range also. Consider a simple case where you provide the exact da + len 
corresponding to a specific memory range.

> 
>> +		    oproc->mem[i].dev_addr +  oproc->mem[i].size) {
> 
> One space too many after the '+' .

True, I wonder why checkpatch did not catch this.

> 
>> +			offset = da -  oproc->mem[i].dev_addr;
> 
> One space too many after then '-' .

Same, will fix these two.

-Tero

> 
>> +			/* __force to make sparse happy with type conversion */
>> +			return (__force void *)(oproc->mem[i].cpu_addr +
>> +						offset);
>> +		}
>> +	}
>> +
>> +	return NULL;
>> +}
>> +
>>   static const struct rproc_ops omap_rproc_ops = {
>>   	.start		= omap_rproc_start,
>>   	.stop		= omap_rproc_stop,
>>   	.kick		= omap_rproc_kick,
>> +	.da_to_va	= omap_rproc_da_to_va,
>>   };
>>   
>>   static const char * const ipu_mem_names[] = {
>> -- 
>> 2.17.1
>>
>> --

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 07/15] remoteproc/omap: Add support for DRA7xx remote processors
  2019-12-18 21:31   ` Mathieu Poirier
@ 2019-12-19 13:29     ` Tero Kristo
  0 siblings, 0 replies; 50+ messages in thread
From: Tero Kristo @ 2019-12-19 13:29 UTC (permalink / raw)
  To: Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna

On 18/12/2019 23:31, Mathieu Poirier wrote:
> On Fri, Dec 13, 2019 at 02:55:29PM +0200, Tero Kristo wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems
>> for offloading different computation algorithms. The IPU processor
>> subsystem contains dual-core ARM Cortex-M4 processors, and is very
>> similar to those on OMAP5. The DSP processor subsystem is based on
>> the TI's standard TMS320C66x DSP CorePac core.
>>
>> Support has been added to the OMAP remoteproc driver through new
>> DRA7xx specific compatibles for properly probing and booting all
>> the different processor subsystem instances on DRA7xx/AM57xx
>> SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX
>> is added to enable the driver to be built in DRA7xx-only configuration.
>>
>> The DSP boot address programming needed enhancement for DRA7xx as the
>> boot register fields are different on DRA7 compared to OMAP4 and OMAP5
>> SoCs. The register on DRA7xx contains additional fields within the
>> register and the boot address bit-field is right-shifted by 10 bits.
>> The internal memory parsing logic has also been updated to compute
>> the device addresses for the L2 RAM for DSP devices using relative
>> addressing logic, and to parse two additional RAMs at L1 level - L1P
>> and L1D. This allows the remoteproc driver to support loading into
>> these regions for a small subset of firmware images requiring as
>> such. The most common usage would be to use the L1 programmable
>> RAMs as L1 Caches.
>>
>> The firmware lookup logic also has to be adjusted for DRA7xx as
>> there are (can be) more than one instance of both the IPU and DSP
>> remote processors for the first time in OMAP4+ SoCs.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> [t-kristo@ti.com: moved address translation quirks to pdata]
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>   drivers/remoteproc/Kconfig           |  2 +-
>>   drivers/remoteproc/omap_remoteproc.c | 44 +++++++++++++++++++++++++++-
>>   2 files changed, 44 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>> index 94afdde4bc9f..d6450d7fcf92 100644
>> --- a/drivers/remoteproc/Kconfig
>> +++ b/drivers/remoteproc/Kconfig
>> @@ -25,7 +25,7 @@ config IMX_REMOTEPROC
>>   
>>   config OMAP_REMOTEPROC
>>   	tristate "OMAP remoteproc support"
>> -	depends on ARCH_OMAP4 || SOC_OMAP5
>> +	depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX
>>   	depends on OMAP_IOMMU
>>   	select MAILBOX
>>   	select OMAP2PLUS_MBOX
>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>> index 3ad74c4b4071..6cf7f0a9ba9a 100644
>> --- a/drivers/remoteproc/omap_remoteproc.c
>> +++ b/drivers/remoteproc/omap_remoteproc.c
>> @@ -34,10 +34,13 @@
>>    * struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
>>    * @syscon: regmap handle for the system control configuration module
>>    * @boot_reg: boot register offset within the @syscon regmap
>> + * @boot_reg_shift: bit-field shift required for the boot address value in
>> + *		    @boot_reg
>>    */
>>   struct omap_rproc_boot_data {
>>   	struct regmap *syscon;
>>   	unsigned int boot_reg;
>> +	unsigned int boot_reg_shift;
>>   };
>>   
>>   /*
>> @@ -78,12 +81,14 @@ struct omap_rproc {
>>    * struct omap_rproc_dev_data - device data for the omap remote processor
>>    * @device_name: device name of the remote processor
>>    * @has_bootreg: true if this remote processor has boot register
>> + * @boot_reg_shift: bit shift for the boot register mask
>>    * @mem_names: memory names for this remote processor
>>    * @dev_addrs: device addresses corresponding to the memory names
>>    */
>>   struct omap_rproc_dev_data {
>>   	const char *device_name;
>>   	bool has_bootreg;
>> +	int boot_reg_shift;
>>   	const char * const *mem_names;
>>   	const u32 *dev_addrs;
>>   };
>> @@ -153,6 +158,8 @@ static int omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
>>   	struct omap_rproc *oproc = rproc->priv;
>>   	struct omap_rproc_boot_data *bdata = oproc->boot_data;
>>   	u32 offset = bdata->boot_reg;
>> +	u32 value;
>> +	u32 mask;
>>   
>>   	if (rproc->bootaddr & (SZ_1K - 1)) {
>>   		dev_err(dev, "invalid boot address 0x%x, must be aligned on a 1KB boundary\n",
>> @@ -160,7 +167,10 @@ static int omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
>>   		return -EINVAL;
>>   	}
>>   
>> -	regmap_write(bdata->syscon, offset, rproc->bootaddr);
>> +	value = rproc->bootaddr >> bdata->boot_reg_shift;
>> +	mask = ~(SZ_1K - 1) >> bdata->boot_reg_shift;
>> +
>> +	regmap_update_bits(bdata->syscon, offset, mask, value);
>>   
>>   	return 0;
>>   }
>> @@ -286,6 +296,14 @@ static const u32 ipu_dev_addrs[] = {
>>   	0x20000000,
>>   };
>>   
>> +static const char * const dra7_dsp_mem_names[] = {
>> +	"l2ram", "l1pram", "l1dram", NULL
>> +};
>> +
>> +static const u32 dra7_dsp_dev_addrs[] = {
>> +	0x800000, 0xe00000, 0xf00000,
>> +};
>> +
>>   static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>>   	.device_name	= "dsp",
>>   	.has_bootreg	= true,
>> @@ -308,6 +326,20 @@ static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
>>   	.dev_addrs	= ipu_dev_addrs,
>>   };
>>   
>> +static const struct omap_rproc_dev_data dra7_dsp_dev_data = {
>> +	.device_name	= "dsp",
>> +	.has_bootreg	= true,
> 
> Shouldn't this be solely driven from the DT?  If the "ti,bootreg" is specified
> then we can count on omap_rproc::boot_data to provide the same functionality.
> 
> 
>> +	.boot_reg_shift	= 10,
> 
> I also think this should be driven from the DT.  Otherwise some information is
> from the DT and other is hard coded in the omap_rproc_dev_data.

Hmm right I believe this is a fair point. Let me fix that for next rev.

-Tero

> 
>> +	.mem_names	= dra7_dsp_mem_names,
>> +	.dev_addrs	= dra7_dsp_dev_addrs,
>> +};
>> +
>> +static const struct omap_rproc_dev_data dra7_ipu_dev_data = {
>> +	.device_name	= "ipu",
>> +	.mem_names	= ipu_mem_names,
>> +	.dev_addrs	= ipu_dev_addrs,
>> +};
>> +
>>   static const struct of_device_id omap_rproc_of_match[] = {
>>   	{
>>   		.compatible     = "ti,omap4-dsp",
>> @@ -325,6 +357,14 @@ static const struct of_device_id omap_rproc_of_match[] = {
>>   		.compatible     = "ti,omap5-ipu",
>>   		.data           = &omap5_ipu_dev_data,
>>   	},
>> +	{
>> +		.compatible     = "ti,dra7-dsp",
>> +		.data           = &dra7_dsp_dev_data,
>> +	},
>> +	{
>> +		.compatible     = "ti,dra7-ipu",
>> +		.data           = &dra7_ipu_dev_data,
>> +	},
>>   	{
>>   		/* end */
>>   	},
>> @@ -382,6 +422,8 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev,
>>   		return -EINVAL;
>>   	}
>>   
>> +	oproc->boot_data->boot_reg_shift = data->boot_reg_shift;
>> +
>>   	return 0;
>>   }
>>   
>> -- 
>> 2.17.1
>>
>> --

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 11/15] remoteproc/omap: Request a timer(s) for remoteproc usage
  2019-12-18 22:43   ` Mathieu Poirier
@ 2019-12-19 13:43     ` Tero Kristo
  0 siblings, 0 replies; 50+ messages in thread
From: Tero Kristo @ 2019-12-19 13:43 UTC (permalink / raw)
  To: Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna

On 19/12/2019 00:43, Mathieu Poirier wrote:
> On Fri, Dec 13, 2019 at 02:55:33PM +0200, Tero Kristo wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> The remote processors in OMAP4+ SoCs are equipped with internal
>> timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or
>> the CTM timer within Unicache in IPU & DSP. However, these timers
>> are gated when the processor subsystem clock is gated, making
>> them rather difficult to use as OS tick sources. They will not
>> be able to wakeup the processor from any processor-sleep induced
>> clock-gating states.
>>
>> This can be avoided by using an external timer as the tick source,
>> which can be controlled independently by the OMAP remoteproc
>> driver code, but still allowing the processor subsystem clock to
>> be auto-gated when the remoteproc cores are idle.
>>
>> This patch adds the support for OMAP remote processors to request
>> timer(s) to be used by the remoteproc. The timers are enabled and
>> disabled in line with the enabling/disabling of the remoteproc.
>> The timer data is not mandatory if the advanced device management
>> features are not required.
>>
>> The core timer functionality is provided by the OMAP DMTimer
>> clocksource driver, which does not export any API. The logic is
>> implemented through the timer device's platform data ops. The OMAP
>> remoteproc driver mainly requires ops to request/free a dmtimer,
>> and to start/stop a timer. The split ops helps in controlling the
>> timer state without having to request and release a timer everytime
>> it needs to use the timer.
>>
>> NOTE: If the gptimer is already in use by the time IPU and/or
>> DSP are loaded, the processors will fail to boot.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>   drivers/remoteproc/omap_remoteproc.c | 258 +++++++++++++++++++++++++++
>>   1 file changed, 258 insertions(+)
>>
>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>> index 841981c50d8d..9c750c2ab29d 100644
>> --- a/drivers/remoteproc/omap_remoteproc.c
>> +++ b/drivers/remoteproc/omap_remoteproc.c
>> @@ -26,6 +26,9 @@
>>   #include <linux/regmap.h>
>>   #include <linux/mfd/syscon.h>
>>   #include <linux/reset.h>
>> +#include <clocksource/timer-ti-dm.h>
>> +
>> +#include <linux/platform_data/dmtimer-omap.h>
>>   
>>   #include "omap_remoteproc.h"
>>   #include "remoteproc_internal.h"
>> @@ -57,6 +60,16 @@ struct omap_rproc_mem {
>>   	size_t size;
>>   };
>>   
>> +/**
>> + * struct omap_rproc_timer - data structure for a timer used by a omap rproc
>> + * @odt: timer pointer
>> + * @timer_ops: OMAP dmtimer ops for @odt timer
>> + */
>> +struct omap_rproc_timer {
>> +	struct omap_dm_timer *odt;
>> +	const struct omap_dm_timer_ops *timer_ops;
>> +};
>> +
>>   /**
>>    * struct omap_rproc - omap remote processor state
>>    * @mbox: mailbox channel handle
>> @@ -64,6 +77,8 @@ struct omap_rproc_mem {
>>    * @boot_data: boot data structure for setting processor boot address
>>    * @mem: internal memory regions data
>>    * @num_mems: number of internal memory regions
>> + * @num_timers: number of rproc timer(s)
>> + * @timers: timer(s) info used by rproc
>>    * @rproc: rproc handle
>>    * @reset: reset handle
>>    */
>> @@ -73,6 +88,8 @@ struct omap_rproc {
>>   	struct omap_rproc_boot_data *boot_data;
>>   	struct omap_rproc_mem *mem;
>>   	int num_mems;
>> +	int num_timers;
>> +	struct omap_rproc_timer *timers;
>>   	struct rproc *rproc;
>>   	struct reset_control *reset;
>>   };
>> @@ -93,6 +110,213 @@ struct omap_rproc_dev_data {
>>   	const u32 *dev_addrs;
>>   };
>>   
>> +/**
>> + * omap_rproc_request_timer() - request a timer for a remoteproc
>> + * @dev: device requesting the timer
>> + * @np: device node pointer to the desired timer
>> + * @timer: handle to a struct omap_rproc_timer to return the timer handle
>> + *
>> + * This helper function is used primarily to request a timer associated with
>> + * a remoteproc. The returned handle is stored in the .odt field of the
>> + * @timer structure passed in, and is used to invoke other timer specific
>> + * ops (like starting a timer either during device initialization or during
>> + * a resume operation, or for stopping/freeing a timer).
>> + *
>> + * Returns 0 on success, otherwise an appropriate failure
>> + */
>> +static int omap_rproc_request_timer(struct device *dev, struct device_node *np,
>> +				    struct omap_rproc_timer *timer)
>> +{
>> +	int ret;
>> +
>> +	timer->odt = timer->timer_ops->request_by_node(np);
>> +	if (!timer->odt) {
>> +		dev_err(dev, "request for timer node %p failed\n", np);
>> +		return -EBUSY;
>> +	}
>> +
>> +	ret = timer->timer_ops->set_source(timer->odt, OMAP_TIMER_SRC_SYS_CLK);
>> +	if (ret) {
>> +		dev_err(dev, "error setting OMAP_TIMER_SRC_SYS_CLK as source for timer node %p\n",
>> +			np);
>> +		timer->timer_ops->free(timer->odt);
>> +		return ret;
>> +	}
>> +
>> +	/* clean counter, remoteproc code will set the value */
>> +	timer->timer_ops->set_load(timer->odt, 0, 0);
>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * omap_rproc_start_timer - start a timer for a remoteproc
>> + * @timer: handle to a OMAP rproc timer
>> + *
>> + * This helper function is used to start a timer associated with a remoteproc,
>> + * obtained using the request_timer ops. The helper function needs to be
>> + * invoked by the driver to start the timer (during device initialization)
>> + * or to just resume the timer.
>> + *
>> + * Returns 0 on success, otherwise a failure as returned by DMTimer ops
>> + */
>> +static inline int omap_rproc_start_timer(struct omap_rproc_timer *timer)
>> +{
>> +	return timer->timer_ops->start(timer->odt);
>> +}
>> +
>> +/**
>> + * omap_rproc_stop_timer - stop a timer for a remoteproc
>> + * @timer: handle to a OMAP rproc timer
>> + *
>> + * This helper function is used to disable a timer associated with a
>> + * remoteproc, and needs to be called either during a device shutdown
>> + * or suspend operation. The separate helper function allows the driver
>> + * to just stop a timer without having to release the timer during a
>> + * suspend operation.
>> + *
>> + * Returns 0 on success, otherwise a failure as returned by DMTimer ops
>> + */
>> +static inline int omap_rproc_stop_timer(struct omap_rproc_timer *timer)
>> +{
>> +	return timer->timer_ops->stop(timer->odt);
>> +}
>> +
>> +/**
>> + * omap_rproc_release_timer - release a timer for a remoteproc
>> + * @timer: handle to a OMAP rproc timer
>> + *
>> + * This helper function is used primarily to release a timer associated
>> + * with a remoteproc. The dmtimer will be available for other clients to
>> + * use once released.
>> + *
>> + * Returns 0 on success, otherwise a failure as returned by DMTimer ops
>> + */
>> +static inline int omap_rproc_release_timer(struct omap_rproc_timer *timer)
>> +{
>> +	return timer->timer_ops->free(timer->odt);
>> +}
>> +
>> +/**
>> + * omap_rproc_enable_timers - enable the timers for a remoteproc
>> + * @rproc: handle of a remote processor
>> + * @configure: boolean flag used to acquire and configure the timer handle
>> + *
>> + * This function is used primarily to enable the timers associated with
>> + * a remoteproc. The configure flag is provided to allow the driver to
>> + * to either acquire and start a timer (during device initialization) or
>> + * to just start a timer (during a resume operation).
>> + */
>> +static int omap_rproc_enable_timers(struct rproc *rproc, bool configure)
>> +{
>> +	int i;
>> +	int ret = 0;
>> +	struct platform_device *tpdev;
>> +	struct dmtimer_platform_data *tpdata;
>> +	const struct omap_dm_timer_ops *timer_ops;
>> +	struct omap_rproc *oproc = rproc->priv;
>> +	struct omap_rproc_timer *timers = oproc->timers;
>> +	struct device *dev = rproc->dev.parent;
>> +	struct device_node *np = NULL;
>> +
>> +	if (oproc->num_timers <= 0)
>> +		return 0;
> 
> Given the code in omap_rproc_probe() ->num_timers can only be >= 0.

Will fix to check against 0 only.

> 
>> +
>> +	if (!configure)
>> +		goto start_timers;
>> +
>> +	for (i = 0; i < oproc->num_timers; i++) {
>> +		np = of_parse_phandle(dev->of_node, "ti,timers", i);
>> +		if (!np) {
>> +			ret = -ENXIO;
>> +			dev_err(dev, "device node lookup for timer at index %d failed: %d\n",
>> +				i, ret);
>> +			goto free_timers;
>> +		}
>> +
>> +		tpdev = of_find_device_by_node(np);
>> +		if (!tpdev) {
>> +			ret = -ENODEV;
>> +			dev_err(dev, "could not get timer platform device\n");
>> +			goto put_node;
>> +		}
>> +
>> +		tpdata = dev_get_platdata(&tpdev->dev);
>> +		put_device(&tpdev->dev);
>> +		if (!tpdata) {
>> +			ret = -EINVAL;
>> +			dev_err(dev, "dmtimer pdata structure NULL\n");
>> +			goto put_node;
>> +		}
>> +
>> +		timer_ops = tpdata->timer_ops;
>> +		if (!timer_ops || !timer_ops->request_by_node ||
>> +		    !timer_ops->set_source || !timer_ops->set_load ||
>> +		    !timer_ops->free || !timer_ops->start ||
>> +		    !timer_ops->stop) {
>> +			ret = -EINVAL;
>> +			dev_err(dev, "device does not have required timer ops\n");
>> +			goto put_node;
>> +		}
>> +
>> +		timers[i].timer_ops = timer_ops;
>> +		ret = omap_rproc_request_timer(dev, np, &timers[i]);
>> +		if (ret) {
>> +			dev_err(dev, "request for timer %p failed: %d\n", np,
>> +				ret);
>> +			goto put_node;
>> +		}
>> +		of_node_put(np);
>> +	}
>> +
>> +start_timers:
>> +	for (i = 0; i < oproc->num_timers; i++)
>> +		omap_rproc_start_timer(&timers[i]);
> 
> The return code for omap_rproc_start_timer() is ignored.  If this is intentional
> then adding a comment to justify the choice is probably a good idea.  Otherwise
> please consider refactoring.

Will add a cleanup loop to clear this in failure.

> 
>> +	return 0;
>> +
>> +put_node:
>> +	of_node_put(np);
>> +free_timers:
>> +	while (i--) {
>> +		omap_rproc_release_timer(&timers[i]);
>> +		timers[i].odt = NULL;
>> +		timers[i].timer_ops = NULL;
>> +	}
>> +
>> +	return ret;
>> +}
>> +
>> +/**
>> + * omap_rproc_disable_timers - disable the timers for a remoteproc
>> + * @rproc: handle of a remote processor
>> + * @configure: boolean flag used to release the timer handle
>> + *
>> + * This function is used primarily to disable the timers associated with
>> + * a remoteproc. The configure flag is provided to allow the driver to
>> + * to either stop and release a timer (during device shutdown) or to just
>> + * stop a timer (during a suspend operation).
>> + */
>> +static int omap_rproc_disable_timers(struct rproc *rproc, bool configure)
>> +{
>> +	int i;
>> +	struct omap_rproc *oproc = rproc->priv;
>> +	struct omap_rproc_timer *timers = oproc->timers;
>> +
>> +	if (oproc->num_timers <= 0)
> 
> Same comment as above.

Will fix to check against 0 only.

> 
>> +		return 0;
>> +
>> +	for (i = 0; i < oproc->num_timers; i++) {
>> +		omap_rproc_stop_timer(&timers[i]);
>> +		if (configure) {
>> +			omap_rproc_release_timer(&timers[i]);
>> +			timers[i].odt = NULL;
>> +			timers[i].timer_ops = NULL;
>> +		}
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>   /**
>>    * omap_rproc_mbox_callback() - inbound mailbox message handler
>>    * @client: mailbox client pointer used for requesting the mailbox channel
>> @@ -228,6 +452,12 @@ static int omap_rproc_start(struct rproc *rproc)
>>   		goto put_mbox;
>>   	}
>>   
>> +	ret = omap_rproc_enable_timers(rproc, true);
>> +	if (ret) {
>> +		dev_err(dev, "omap_rproc_enable_timers failed: %d\n", ret);
>> +		goto put_mbox;
>> +	}
>> +
>>   	reset_control_deassert(oproc->reset);
>>   
>>   	return 0;
>> @@ -241,9 +471,14 @@ static int omap_rproc_start(struct rproc *rproc)
>>   static int omap_rproc_stop(struct rproc *rproc)
>>   {
>>   	struct omap_rproc *oproc = rproc->priv;
>> +	int ret;
>>   
>>   	reset_control_assert(oproc->reset);
>>   
>> +	ret = omap_rproc_disable_timers(rproc, true);
>> +	if (ret)
>> +		return ret;
>> +
>>   	mbox_free_channel(oproc->mbox);
>>   
>>   	return 0;
>> @@ -528,6 +763,29 @@ static int omap_rproc_probe(struct platform_device *pdev)
>>   	if (ret)
>>   		goto free_rproc;
>>   
>> +	/*
>> +	 * Timer nodes are directly used in client nodes as phandles, so
>> +	 * retrieve the count using appropriate size
>> +	 */
>> +	oproc->num_timers = of_count_phandle_with_args(np, "ti,timers", NULL);
>> +	if (oproc->num_timers <= 0) {
>> +		dev_dbg(&pdev->dev, "device does not have timers, status = %d\n",
>> +			oproc->num_timers);
>> +		oproc->num_timers = 0;
>> +	}
>> +
>> +	if (oproc->num_timers) {
>> +		oproc->timers = devm_kzalloc(&pdev->dev, sizeof(*oproc->timers)
>> +					     * oproc->num_timers, GFP_KERNEL);
> 
> Please use devm_kcalloc().

Will fix that.

-Tero

> 
> More comments to come tomorrow,
> Mathieu
> 
>> +		if (!oproc->timers) {
>> +			ret = -ENOMEM;
>> +			goto free_rproc;
>> +		}
>> +
>> +		dev_dbg(&pdev->dev, "device has %d tick timers\n",
>> +			oproc->num_timers);
>> +	}
>> +
>>   	ret = of_reserved_mem_device_init(&pdev->dev);
>>   	if (ret) {
>>   		dev_err(&pdev->dev, "device does not have specific CMA pool\n");
>> -- 
>> 2.17.1
>>
>> --

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 04/15] remoteproc/omap: Add support to parse internal memories from DT
  2019-12-19 12:31     ` Tero Kristo
@ 2019-12-19 17:37       ` Mathieu Poirier
  2019-12-20  2:15         ` Suman Anna
  0 siblings, 1 reply; 50+ messages in thread
From: Mathieu Poirier @ 2019-12-19 17:37 UTC (permalink / raw)
  To: Tero Kristo
  Cc: Bjorn Andersson, Ohad Ben-Cohen, linux-remoteproc,
	Linux Kernel Mailing List, linux-omap, Suman Anna

On Thu, 19 Dec 2019 at 05:31, Tero Kristo <t-kristo@ti.com> wrote:
>
> On 18/12/2019 02:22, Mathieu Poirier wrote:
> > On Fri, Dec 13, 2019 at 02:55:26PM +0200, Tero Kristo wrote:
> >> From: Suman Anna <s-anna@ti.com>
> >>
> >> The OMAP remoteproc driver has been enhanced to parse and store
> >> the kernel mappings for different internal RAM memories that may
> >> be present within each remote processor IP subsystem. Different
> >> devices have varying memories present on current SoCs. The current
> >> support handles the L2RAM for all IPU devices on OMAP4+ SoCs. The
> >> DSPs on OMAP4/OMAP5 only have Unicaches and do not have any L1 or
> >> L2 RAM memories.
> >>
> >> IPUs are expected to have the L2RAM at a fixed device address of
> >> 0x20000000, based on the current limitations on Attribute MMU
> >> configurations.
> >>
> >> NOTE:
> >> The current logic doesn't handle the parsing of memories for DRA7
> >> remoteproc devices, and will be added alongside the DRA7 support.
> >>
> >> Signed-off-by: Suman Anna <s-anna@ti.com>
> >> [t-kristo: converted to parse mem names / device addresses from pdata]
> >> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> >> ---
> >>   drivers/remoteproc/omap_remoteproc.c | 86 ++++++++++++++++++++++++++++
> >>   1 file changed, 86 insertions(+)
> >>
> >> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> >> index d80f5d7b5931..844703507a74 100644
> >> --- a/drivers/remoteproc/omap_remoteproc.c
> >> +++ b/drivers/remoteproc/omap_remoteproc.c
> >> @@ -39,11 +39,27 @@ struct omap_rproc_boot_data {
> >>      unsigned int boot_reg;
> >>   };
> >>
> >> +/*
> >> + * struct omap_rproc_mem - 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 of the memory region from DSP view
> >> + * @size: size of the memory region
> >> + */
> >> +struct omap_rproc_mem {
> >> +    void __iomem *cpu_addr;
> >> +    phys_addr_t bus_addr;
> >> +    u32 dev_addr;
> >> +    size_t size;
> >> +};
> >> +
> >>   /**
> >>    * struct omap_rproc - omap remote processor state
> >>    * @mbox: mailbox channel handle
> >>    * @client: mailbox client to request the mailbox channel
> >>    * @boot_data: boot data structure for setting processor boot address
> >> + * @mem: internal memory regions data
> >> + * @num_mems: number of internal memory regions
> >>    * @rproc: rproc handle
> >>    * @reset: reset handle
> >>    */
> >> @@ -51,6 +67,8 @@ struct omap_rproc {
> >>      struct mbox_chan *mbox;
> >>      struct mbox_client client;
> >>      struct omap_rproc_boot_data *boot_data;
> >> +    struct omap_rproc_mem *mem;
> >> +    int num_mems;
> >>      struct rproc *rproc;
> >>      struct reset_control *reset;
> >>   };
> >> @@ -59,10 +77,14 @@ struct omap_rproc {
> >>    * struct omap_rproc_dev_data - device data for the omap remote processor
> >>    * @device_name: device name of the remote processor
> >>    * @has_bootreg: true if this remote processor has boot register
> >> + * @mem_names: memory names for this remote processor
> >> + * @dev_addrs: device addresses corresponding to the memory names
> >>    */
> >>   struct omap_rproc_dev_data {
> >>      const char *device_name;
> >>      bool has_bootreg;
> >> +    const char * const *mem_names;
> >> +    const u32 *dev_addrs;
> >
> > Bunching these two in a new structure like omap_rproc_mem_data would clean
> > things up.  That way the two arrays in the next hunk get merged and there can't
> > be a difference in sizes, somthing that will sturdy the main loop in
> > omap_rproc_of_get_internal_memories() below.
>
> Will fix this.
>
> >
> >>   };
> >>
> >>   /**
> >> @@ -216,6 +238,14 @@ static const struct rproc_ops omap_rproc_ops = {
> >>      .kick           = omap_rproc_kick,
> >>   };
> >>
> >> +static const char * const ipu_mem_names[] = {
> >> +    "l2ram", NULL
> >> +};
> >> +
> >> +static const u32 ipu_dev_addrs[] = {
> >> +    0x20000000,
> >> +};
> >> +
> >>   static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
> >>      .device_name    = "dsp",
> >>      .has_bootreg    = true,
> >> @@ -223,6 +253,8 @@ static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
> >>
> >>   static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
> >>      .device_name    = "ipu",
> >> +    .mem_names      = ipu_mem_names,
> >> +    .dev_addrs      = ipu_dev_addrs,
> >>   };
> >>
> >>   static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
> >> @@ -232,6 +264,8 @@ static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
> >>
> >>   static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
> >>      .device_name    = "ipu",
> >> +    .mem_names      = ipu_mem_names,
> >> +    .dev_addrs      = ipu_dev_addrs,
> >>   };
> >>
> >>   static const struct of_device_id omap_rproc_of_match[] = {
> >> @@ -311,6 +345,54 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev,
> >>      return 0;
> >>   }
> >>
> >> +static int omap_rproc_of_get_internal_memories(struct platform_device *pdev,
> >> +                                           struct rproc *rproc)
> >> +{
> >> +    struct omap_rproc *oproc = rproc->priv;
> >> +    struct device *dev = &pdev->dev;
> >> +    const struct omap_rproc_dev_data *data;
> >> +    struct resource *res;
> >> +    int num_mems;
> >> +    int i;
> >> +
> >> +    data = of_device_get_match_data(&pdev->dev);
> >> +    if (!data)
> >> +            return -ENODEV;
> >> +
> >> +    if (!data->mem_names)
> >> +            return 0;
> >> +
> >> +    for (num_mems = 0; data->mem_names[num_mems]; num_mems++)
> >> +            ;
> >
> > Instead of doing this function of_property_count_elems_of_size() can be used on
> > the "reg" property.
>
> Hmm right, but the problem is then we don't know if someone left out one
> of the memories in DT. We want to check the presence for all defined in
> the platform data.
>

In my opinion (and to go along what I advocated in a comment on
another patch) everything should be dictated from the DT.  If an area
of reserved memory is missing in the DT then the infrastructure should
recognise it and refuse to move forward with initialisation.

Thanks
Mathieu

> >
> > In the loop below a check should be done to see if data->mem_data[i] (see above
> > comment) is valid before calling platform_get_resource_byname().  If not then
> > an error can be returned.
>
> Will add a check to it.
>
> -Tero
>
> >
> > I'm running out of time for today - I will continue reviewing the other patches
> > tomorrow.
> >
> >> +
> >> +    oproc->mem = devm_kcalloc(dev, num_mems, sizeof(*oproc->mem),
> >> +                              GFP_KERNEL);
> >> +    if (!oproc->mem)
> >> +            return -ENOMEM;
> >> +
> >> +    for (i = 0; i < num_mems; i++) {
> >> +            res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> >> +                                               data->mem_names[i]);
> >> +            oproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
> >> +            if (IS_ERR(oproc->mem[i].cpu_addr)) {
> >> +                    dev_err(dev, "failed to parse and map %s memory\n",
> >> +                            data->mem_names[i]);
> >> +                    return PTR_ERR(oproc->mem[i].cpu_addr);
> >> +            }
> >> +            oproc->mem[i].bus_addr = res->start;
> >> +            oproc->mem[i].dev_addr = data->dev_addrs[i];
> >> +            oproc->mem[i].size = resource_size(res);
> >> +
> >> +            dev_dbg(dev, "memory %8s: bus addr %pa size 0x%x va %p da 0x%x\n",
> >> +                    data->mem_names[i], &oproc->mem[i].bus_addr,
> >> +                    oproc->mem[i].size, oproc->mem[i].cpu_addr,
> >> +                    oproc->mem[i].dev_addr);
> >> +    }
> >> +    oproc->num_mems = num_mems;
> >> +
> >> +    return 0;
> >> +}
> >> +
> >>   static int omap_rproc_probe(struct platform_device *pdev)
> >>   {
> >>      struct device_node *np = pdev->dev.of_node;
> >> @@ -350,6 +432,10 @@ static int omap_rproc_probe(struct platform_device *pdev)
> >>      /* All existing OMAP IPU and DSP processors have an MMU */
> >>      rproc->has_iommu = true;
> >>
> >> +    ret = omap_rproc_of_get_internal_memories(pdev, rproc);
> >> +    if (ret)
> >> +            goto free_rproc;
> >> +
> >>      ret = omap_rproc_get_boot_data(pdev, rproc);
> >>      if (ret)
> >>              goto free_rproc;
> >> --
> >> 2.17.1
> >>
> >> --
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 12/15] remoteproc/omap: add support for system suspend/resume
  2019-12-13 12:55 ` [PATCHv3 12/15] remoteproc/omap: add support for system suspend/resume Tero Kristo
@ 2019-12-19 21:46   ` Mathieu Poirier
  2019-12-20  3:11     ` Suman Anna
  0 siblings, 1 reply; 50+ messages in thread
From: Mathieu Poirier @ 2019-12-19 21:46 UTC (permalink / raw)
  To: Tero Kristo
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna

On Fri, Dec 13, 2019 at 02:55:34PM +0200, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
> 
> This patch adds the support for system suspend/resume to the
> OMAP remoteproc driver so that the OMAP remoteproc devices can
> be suspended/resumed during a system suspend/resume. The support
> is added through the driver PM .suspend/.resume callbacks, and
> requires appropriate support from the OS running on the remote
> processors.
> 
> The IPU & DSP remote processors typically have their own private
> modules like registers, internal memories, caches etc. The context
> of these modules need to be saved and restored properly for a
> suspend/resume to work. These are in general not accessible from
> the MPU, so the remote processors themselves have to implement
> the logic for the context save & restore of these modules.
> 
> The OMAP remoteproc driver initiates a suspend by sending a mailbox
> message requesting the remote processor to save its context and
> enter into an idle/standby state. The remote processor should
> usually stop whatever processing it is doing to switch to a context
> save mode. The OMAP remoteproc driver detects the completion of
> the context save by checking the module standby status for the
> remoteproc device. It also stops any resources used by the remote
> processors like the timers. The timers need to be running only
> when the processor is active and executing, and need to be stopped
> otherwise to allow the timer driver to reach low-power states. The
> IOMMUs are automatically suspended by the PM core during the late
> suspend stage, after the remoteproc suspend process is completed by
> putting the remote processor cores into reset. Thereafter, the Linux
> kernel can put the domain into further lower power states as possible.
> 
> The resume sequence undoes the operations performed in the PM suspend
> callback, by starting the timers and finally releasing the processors
> from reset. This requires that the remote processor side OS be able to
> distinguish a power-resume boot from a power-on/cold boot, restore the
> context of its private modules saved during the suspend phase, and
> resume executing code from where it was suspended. The IOMMUs would
> have been resumed by the PM core during early resume, so they are
> already enabled by the time remoteproc resume callback gets invoked.
> 
> The remote processors should save their context into System RAM (DDR),
> as any internal memories are not guaranteed to retain context as it
> depends on the lowest power domain that the remote processor device
> is put into. The management of the DDR contents will be managed by
> the Linux kernel.
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> [t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  drivers/remoteproc/omap_remoteproc.c | 179 +++++++++++++++++++++++++++
>  drivers/remoteproc/omap_remoteproc.h |  18 ++-
>  2 files changed, 195 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index 9c750c2ab29d..0a9b9f7d20da 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -16,6 +16,7 @@
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/err.h>
> +#include <linux/io.h>
>  #include <linux/of_device.h>
>  #include <linux/of_reserved_mem.h>
>  #include <linux/platform_device.h>
> @@ -23,10 +24,13 @@
>  #include <linux/remoteproc.h>
>  #include <linux/mailbox_client.h>
>  #include <linux/omap-mailbox.h>
> +#include <linux/omap-iommu.h>

Please move this up by one line.

>  #include <linux/regmap.h>
>  #include <linux/mfd/syscon.h>
>  #include <linux/reset.h>
>  #include <clocksource/timer-ti-dm.h>
> +#include <linux/clk.h>
> +#include <linux/clk/ti.h>

Unless there is a dependency with timer-ti-dm.h, these should go just above linux/err.h

>  
>  #include <linux/platform_data/dmtimer-omap.h>
>  
> @@ -81,6 +85,9 @@ struct omap_rproc_timer {
>   * @timers: timer(s) info used by rproc
>   * @rproc: rproc handle
>   * @reset: reset handle
> + * @pm_comp: completion primitive to sync for suspend response
> + * @fck: functional clock for the remoteproc
> + * @suspend_acked: state machine flag to store the suspend request ack
>   */
>  struct omap_rproc {
>  	struct mbox_chan *mbox;
> @@ -92,6 +99,9 @@ struct omap_rproc {
>  	struct omap_rproc_timer *timers;
>  	struct rproc *rproc;
>  	struct reset_control *reset;
> +	struct completion pm_comp;
> +	struct clk *fck;
> +	bool suspend_acked;
>  };
>  
>  /**
> @@ -349,6 +359,11 @@ static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
>  	case RP_MBOX_ECHO_REPLY:
>  		dev_info(dev, "received echo reply from %s\n", name);
>  		break;
> +	case RP_MBOX_SUSPEND_ACK:

We can't get away with implicit fallthroughs anymore - please add /* Fall through */"

> +	case RP_MBOX_SUSPEND_CANCEL:
> +		oproc->suspend_acked = msg == RP_MBOX_SUSPEND_ACK;
> +		complete(&oproc->pm_comp);
> +		break;
>  	default:
>  		if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
>  			return;
> @@ -529,6 +544,157 @@ static const struct rproc_ops omap_rproc_ops = {
>  	.da_to_va	= omap_rproc_da_to_va,
>  };
>  
> +#ifdef CONFIG_PM
> +static bool _is_rproc_in_standby(struct omap_rproc *oproc)
> +{
> +	return ti_clk_is_in_standby(oproc->fck);
> +}
> +
> +/* 1 sec is long enough time to let the remoteproc side suspend the device */
> +#define DEF_SUSPEND_TIMEOUT 1000
> +static int _omap_rproc_suspend(struct rproc *rproc)
> +{
> +	struct device *dev = rproc->dev.parent;
> +	struct omap_rproc *oproc = rproc->priv;
> +	unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
> +	unsigned long ta = jiffies + to;
> +	int ret;
> +
> +	reinit_completion(&oproc->pm_comp);
> +	oproc->suspend_acked = false;
> +	ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_SUSPEND_SYSTEM);
> +	if (ret < 0) {
> +		dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = wait_for_completion_timeout(&oproc->pm_comp, to);
> +	if (!oproc->suspend_acked)
> +		return -EBUSY;
> +
> +	/*
> +	 * The remoteproc side is returning the ACK message before saving the
> +	 * context, because the context saving is performed within a SYS/BIOS
> +	 * function, and it cannot have any inter-dependencies against the IPC
> +	 * layer. Also, as the SYS/BIOS needs to preserve properly the processor
> +	 * register set, sending this ACK or signalling the completion of the
> +	 * context save through a shared memory variable can never be the
> +	 * absolute last thing to be executed on the remoteproc side, and the
> +	 * MPU cannot use the ACK message as a sync point to put the remoteproc
> +	 * into reset. The only way to ensure that the remote processor has
> +	 * completed saving the context is to check that the module has reached
> +	 * STANDBY state (after saving the context, the SYS/BIOS executes the
> +	 * appropriate target-specific WFI instruction causing the module to
> +	 * enter STANDBY).
> +	 */
> +	while (!_is_rproc_in_standby(oproc)) {
> +		if (time_after(jiffies, ta))
> +			return -ETIME;
> +		schedule();
> +	}
> +
> +	reset_control_assert(oproc->reset);
> +
> +	ret = omap_rproc_disable_timers(rproc, false);
> +	if (ret) {
> +		dev_err(dev, "disabling timers during suspend failed %d\n",
> +			ret);
> +		goto enable_device;
> +	}
> +
> +	return 0;
> +
> +enable_device:
> +	reset_control_deassert(oproc->reset);
> +	return ret;
> +}
> +
> +static int _omap_rproc_resume(struct rproc *rproc)
> +{
> +	struct device *dev = rproc->dev.parent;
> +	struct omap_rproc *oproc = rproc->priv;
> +	int ret;
> +
> +	/* boot address could be lost after suspend, so restore it */
> +	if (oproc->boot_data) {
> +		ret = omap_rproc_write_dsp_boot_addr(rproc);
> +		if (ret) {
> +			dev_err(dev, "boot address restore failed %d\n", ret);
> +			goto out;
> +		}
> +	}
> +
> +	ret = omap_rproc_enable_timers(rproc, false);
> +	if (ret) {
> +		dev_err(dev, "enabling timers during resume failed %d\n",
> +			ret);

The "ret);" fits on the live above.

> +		goto out;
> +	}
> +
> +	reset_control_deassert(oproc->reset);
> +
> +out:
> +	return ret;
> +}
> +
> +static int __maybe_unused omap_rproc_suspend(struct device *dev)

The "__maybe_unused" can be dropped because this is within the #ifdef CONFIG_PM
block.

> +{
> +	struct platform_device *pdev = to_platform_device(dev);
> +	struct rproc *rproc = platform_get_drvdata(pdev);
> +	int ret = 0;
> +
> +	mutex_lock(&rproc->lock);
> +	if (rproc->state == RPROC_OFFLINE)
> +		goto out;
> +
> +	if (rproc->state == RPROC_SUSPENDED)
> +		goto out;
> +
> +	if (rproc->state != RPROC_RUNNING) {
> +		ret = -EBUSY;
> +		goto out;
> +	}
> +
> +	ret = _omap_rproc_suspend(rproc);
> +	if (ret) {
> +		dev_err(dev, "suspend failed %d\n", ret);
> +		goto out;
> +	}
> +
> +	rproc->state = RPROC_SUSPENDED;
> +out:
> +	mutex_unlock(&rproc->lock);
> +	return ret;
> +}
> +
> +static int __maybe_unused omap_rproc_resume(struct device *dev)

Same comment as above.

> +{
> +	struct platform_device *pdev = to_platform_device(dev);
> +	struct rproc *rproc = platform_get_drvdata(pdev);
> +	int ret = 0;
> +
> +	mutex_lock(&rproc->lock);
> +	if (rproc->state == RPROC_OFFLINE)
> +		goto out;
> +
> +	if (rproc->state != RPROC_SUSPENDED) {
> +		ret = -EBUSY;
> +		goto out;
> +	}
> +
> +	ret = _omap_rproc_resume(rproc);
> +	if (ret) {
> +		dev_err(dev, "resume failed %d\n", ret);
> +		goto out;
> +	}
> +
> +	rproc->state = RPROC_RUNNING;
> +out:
> +	mutex_unlock(&rproc->lock);
> +	return ret;
> +}
> +#endif /* CONFIG_PM */
> +
>  static const char * const ipu_mem_names[] = {
>  	"l2ram", NULL
>  };
> @@ -786,6 +952,14 @@ static int omap_rproc_probe(struct platform_device *pdev)
>  			oproc->num_timers);
>  	}
>  
> +	init_completion(&oproc->pm_comp);
> +
> +	oproc->fck = devm_clk_get(&pdev->dev, 0);
> +	if (IS_ERR(oproc->fck)) {
> +		ret = PTR_ERR(oproc->fck);
> +		goto free_rproc;
> +	}
> +

oproc->fck is not released if an error occurs in of_reserved_mem_device_init()
and rproc_add().

>  	ret = of_reserved_mem_device_init(&pdev->dev);
>  	if (ret) {
>  		dev_err(&pdev->dev, "device does not have specific CMA pool\n");
> @@ -818,11 +992,16 @@ static int omap_rproc_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +static const struct dev_pm_ops omap_rproc_pm_ops = {
> +	SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
> +};
> +
>  static struct platform_driver omap_rproc_driver = {
>  	.probe = omap_rproc_probe,
>  	.remove = omap_rproc_remove,
>  	.driver = {
>  		.name = "omap-rproc",
> +		.pm = &omap_rproc_pm_ops,
>  		.of_match_table = omap_rproc_of_match,
>  	},
>  };
> diff --git a/drivers/remoteproc/omap_remoteproc.h b/drivers/remoteproc/omap_remoteproc.h
> index 72f656c93caa..c73383e707c7 100644
> --- a/drivers/remoteproc/omap_remoteproc.h
> +++ b/drivers/remoteproc/omap_remoteproc.h
> @@ -1,7 +1,7 @@
>  /*
>   * Remote processor messaging
>   *
> - * Copyright (C) 2011 Texas Instruments, Inc.
> + * Copyright (C) 2011-2018 Texas Instruments, Inc.
>   * Copyright (C) 2011 Google, Inc.
>   * All rights reserved.
>   *
> @@ -57,6 +57,16 @@
>   * @RP_MBOX_ABORT_REQUEST: a "please crash" request, used for testing the
>   * recovery mechanism (to some extent).
>   *
> + * @RP_MBOX_SUSPEND_AUTO: auto suspend request for the remote processor
> + *
> + * @RP_MBOX_SUSPEND_SYSTEM: system suspend request for the remote processor
> + *
> + * @RP_MBOX_SUSPEND_ACK: successful response from remote processor for a
> + * suspend request
> + *
> + * @RP_MBOX_SUSPEND_CANCEL: a cancel suspend response from a remote processor
> + * on a suspend request
> + *
>   * Introduce new message definitions if any here.
>   *
>   * @RP_MBOX_END_MSG: Indicates end of known/defined messages from remote core
> @@ -70,7 +80,11 @@ enum omap_rp_mbox_messages {
>  	RP_MBOX_ECHO_REQUEST	= 0xFFFFFF03,
>  	RP_MBOX_ECHO_REPLY	= 0xFFFFFF04,
>  	RP_MBOX_ABORT_REQUEST	= 0xFFFFFF05,
> -	RP_MBOX_END_MSG		= 0xFFFFFF06,
> +	RP_MBOX_SUSPEND_AUTO	= 0xFFFFFF10,
> +	RP_MBOX_SUSPEND_SYSTEM	= 0xFFFFFF11,
> +	RP_MBOX_SUSPEND_ACK	= 0xFFFFFF12,
> +	RP_MBOX_SUSPEND_CANCEL	= 0xFFFFFF13,
> +	RP_MBOX_END_MSG		= 0xFFFFFF14,
>  };
>  
>  #endif /* _OMAP_RPMSG_H */
> -- 
> 2.17.1
> 
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume
  2019-12-13 12:55 ` [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume Tero Kristo
@ 2019-12-19 23:43   ` Mathieu Poirier
  2019-12-20  3:24     ` Suman Anna
  2019-12-20 11:08     ` Tero Kristo
  0 siblings, 2 replies; 50+ messages in thread
From: Mathieu Poirier @ 2019-12-19 23:43 UTC (permalink / raw)
  To: Tero Kristo
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna

On Fri, Dec 13, 2019 at 02:55:35PM +0200, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
> 
> This patch enhances the PM support in the OMAP remoteproc driver to
> support the runtime auto-suspend. A remoteproc may not be required to
> be running all the time, and typically will need to be active only
> during certain usecases. As such, to save power, it should be turned
> off during potential long periods of inactivity between usecases.
> This suspend and resume of the device is a relatively heavy process
> in terms of latencies, so a remoteproc should be suspended only after
> a certain period of prolonged inactivity. The OMAP remoteproc driver
> leverages the runtime pm framework's auto_suspend feature to accomplish
> this functionality. This feature is automatically enabled when a remote
> processor has successfully booted. The 'autosuspend_delay_ms' for each
> device dictates the inactivity period/time to wait for before
> suspending the device.
> 
> The runtime auto-suspend design relies on marking the last busy time
> on every communication (virtqueue kick) to and from the remote processor.
> When there has been no activity for 'autosuspend_delay_ms' time, the
> runtime PM framework invokes the driver's runtime pm suspend callback
> to suspend the device. The remote processor will be woken up on the
> initiation of the next communication message through the runtime pm
> resume callback. The current auto-suspend design also allows a remote
> processor to deny a auto-suspend attempt, if it wishes to, by sending a
> NACK response to the initial suspend request message sent to the remote
> processor as part of the suspend process. The auto-suspend request is
> also only attempted if the remote processor is idled and in standby at
> the time of inactivity timer expiry. This choice is made to avoid
> unnecessary messaging, and the auto-suspend is simply rescheduled to
> be attempted again after a further lapse of autosuspend_delay_ms.
> 
> The runtime pm callbacks functionality in this patch reuses most of the
> core logic from the suspend/resume support code, and make use of an
> additional auto_suspend flag to differentiate the logic in common code
> from system suspend. The system suspend/resume sequences are also updated
> to reflect the proper pm_runtime statuses, and also to really perform a
> suspend/resume only if the remoteproc has not been auto-suspended at the
> time of request. The remote processor is left in suspended state on a
> system resume if it has been auto-suspended before, and will be woken up
> only when a usecase needs to run. The other significant change in this
> patch is to reset the remoteproc device's pm_domain so as to avoid
> conflicts with the ordering sequences in the device pm_domain's runtime
> callbacks and the reset management and clock management implemented
> within the runtime callbacks in the driver.
> 
> The OMAP remoteproc driver currently uses a default value of 10 seconds
> for all OMAP remoteprocs, and a different value can be chosen either by
> choosing a positive value for the 'autosuspend_delay' in the device's
> omap_rproc_fw_data in the driver match data or by updating the
> 'autosuspend_delay_ms' field at runtime through the sysfs interface.
>     Eg: To use 25 seconds for IPU2 on DRA7xx,
>       echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms
> 
> The runtime suspend feature can also be similarly enabled or disabled by
> writing 'auto' or 'on' to the device's 'control' power field. The default
> is enabled.
>     Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
>       echo on > /sys/bus/platform/devices/55020000.ipu/power/control
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> [t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  drivers/remoteproc/omap_remoteproc.c | 220 ++++++++++++++++++++++++++-
>  1 file changed, 214 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index 0a9b9f7d20da..463d6f60947a 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -20,6 +20,7 @@
>  #include <linux/of_device.h>
>  #include <linux/of_reserved_mem.h>
>  #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/remoteproc.h>
>  #include <linux/mailbox_client.h>
> @@ -37,6 +38,9 @@
>  #include "omap_remoteproc.h"
>  #include "remoteproc_internal.h"
>  
> +/* default auto-suspend delay (ms) */
> +#define DEFAULT_AUTOSUSPEND_DELAY		10000
> +
>  /**
>   * struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
>   * @syscon: regmap handle for the system control configuration module
> @@ -83,6 +87,8 @@ struct omap_rproc_timer {
>   * @num_mems: number of internal memory regions
>   * @num_timers: number of rproc timer(s)
>   * @timers: timer(s) info used by rproc
> + * @autosuspend_delay: auto-suspend delay value to be used for runtime pm
> + * @need_resume: if true a resume is needed in the system resume callback
>   * @rproc: rproc handle
>   * @reset: reset handle
>   * @pm_comp: completion primitive to sync for suspend response
> @@ -97,6 +103,8 @@ struct omap_rproc {
>  	int num_mems;
>  	int num_timers;
>  	struct omap_rproc_timer *timers;
> +	int autosuspend_delay;
> +	bool need_resume;
>  	struct rproc *rproc;
>  	struct reset_control *reset;
>  	struct completion pm_comp;
> @@ -111,6 +119,7 @@ struct omap_rproc {
>   * @boot_reg_shift: bit shift for the boot register mask
>   * @mem_names: memory names for this remote processor
>   * @dev_addrs: device addresses corresponding to the memory names
> + * @autosuspend_delay: custom auto-suspend delay value in milliseconds
>   */
>  struct omap_rproc_dev_data {
>  	const char *device_name;
> @@ -118,6 +127,7 @@ struct omap_rproc_dev_data {
>  	int boot_reg_shift;
>  	const char * const *mem_names;
>  	const u32 *dev_addrs;
> +	int autosuspend_delay;
>  };
>  
>  /**
> @@ -384,11 +394,23 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
>  	struct device *dev = rproc->dev.parent;
>  	int ret;
>  
> +	/* wake up the rproc before kicking it */
> +	ret = pm_runtime_get_sync(dev);
> +	if (WARN_ON(ret < 0)) {
> +		dev_err(dev, "pm_runtime_get_sync() failed during kick, ret = %d\n",
> +			ret);
> +		pm_runtime_put_noidle(dev);
> +		return;
> +	}
> +
>  	/* send the index of the triggered virtqueue in the mailbox payload */
>  	ret = mbox_send_message(oproc->mbox, (void *)vqid);
>  	if (ret < 0)
>  		dev_err(dev, "failed to send mailbox message, status = %d\n",
>  			ret);
> +
> +	pm_runtime_mark_last_busy(dev);
> +	pm_runtime_put_autosuspend(dev);
>  }
>  
>  /**
> @@ -473,6 +495,19 @@ static int omap_rproc_start(struct rproc *rproc)
>  		goto put_mbox;
>  	}
>  
> +	/*
> +	 * remote processor is up, so update the runtime pm status and
> +	 * enable the auto-suspend. The device usage count is incremented
> +	 * manually for balancing it for auto-suspend
> +	 */
> +	pm_runtime_set_active(dev);
> +	pm_runtime_set_autosuspend_delay(dev, oproc->autosuspend_delay);
> +	pm_runtime_use_autosuspend(dev);
> +	pm_runtime_get(dev);
> +	pm_runtime_enable(dev);
> +	pm_runtime_mark_last_busy(dev);
> +	pm_runtime_put_autosuspend(dev);
> +
>  	reset_control_deassert(oproc->reset);
>  
>  	return 0;
> @@ -485,9 +520,26 @@ static int omap_rproc_start(struct rproc *rproc)
>  /* power off the remote processor */
>  static int omap_rproc_stop(struct rproc *rproc)
>  {
> +	struct device *dev = rproc->dev.parent;
>  	struct omap_rproc *oproc = rproc->priv;
>  	int ret;
>  
> +	/*
> +	 * cancel any possible scheduled runtime suspend by incrementing
> +	 * the device usage count, and resuming the device. The remoteproc
> +	 * also needs to be woken up if suspended, to avoid the remoteproc
> +	 * OS to continue to remember any context that it has saved, and
> +	 * avoid potential issues in misindentifying a subsequent device
> +	 * reboot as a power restore boot
> +	 */
> +	ret = pm_runtime_get_sync(dev);
> +	if (ret < 0) {
> +		pm_runtime_put_noidle(dev);
> +		return ret;
> +	}
> +
> +	pm_runtime_put_sync(dev);
> +
>  	reset_control_assert(oproc->reset);
>  
>  	ret = omap_rproc_disable_timers(rproc, true);
> @@ -496,6 +548,15 @@ static int omap_rproc_stop(struct rproc *rproc)
>  
>  	mbox_free_channel(oproc->mbox);
>  
> +	/*
> +	 * update the runtime pm states and status now that the remoteproc
> +	 * has stopped
> +	 */
> +	pm_runtime_disable(dev);
> +	pm_runtime_dont_use_autosuspend(dev);
> +	pm_runtime_put_noidle(dev);
> +	pm_runtime_set_suspended(dev);
> +
>  	return 0;
>  }
>  
> @@ -552,17 +613,19 @@ static bool _is_rproc_in_standby(struct omap_rproc *oproc)
>  
>  /* 1 sec is long enough time to let the remoteproc side suspend the device */
>  #define DEF_SUSPEND_TIMEOUT 1000
> -static int _omap_rproc_suspend(struct rproc *rproc)
> +static int _omap_rproc_suspend(struct rproc *rproc, bool auto_suspend)
>  {
>  	struct device *dev = rproc->dev.parent;
>  	struct omap_rproc *oproc = rproc->priv;
>  	unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
>  	unsigned long ta = jiffies + to;
> +	u32 suspend_msg = auto_suspend ?
> +				RP_MBOX_SUSPEND_AUTO : RP_MBOX_SUSPEND_SYSTEM;
>  	int ret;
>  
>  	reinit_completion(&oproc->pm_comp);
>  	oproc->suspend_acked = false;
> -	ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_SUSPEND_SYSTEM);
> +	ret = mbox_send_message(oproc->mbox, (void *)suspend_msg);
>  	if (ret < 0) {
>  		dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
>  		return ret;
> @@ -602,25 +665,55 @@ static int _omap_rproc_suspend(struct rproc *rproc)
>  		goto enable_device;
>  	}
>  
> +	/*
> +	 * IOMMUs would have to be disabled specifically for runtime suspend.
> +	 * They are handled automatically through System PM callbacks for
> +	 * regular system suspend
> +	 */
> +	if (auto_suspend) {
> +		ret = omap_iommu_domain_deactivate(rproc->domain);
> +		if (ret) {
> +			dev_err(dev, "iommu domain deactivate failed %d\n",
> +				ret);
> +			goto enable_timers;
> +		}
> +	}
> +
>  	return 0;
> +enable_timers:
> +	/* ignore errors on re-enabling code */
> +	omap_rproc_enable_timers(rproc, false);
>  
>  enable_device:
>  	reset_control_deassert(oproc->reset);
>  	return ret;
>  }
>  
> -static int _omap_rproc_resume(struct rproc *rproc)
> +static int _omap_rproc_resume(struct rproc *rproc, bool auto_suspend)
>  {
>  	struct device *dev = rproc->dev.parent;
>  	struct omap_rproc *oproc = rproc->priv;
>  	int ret;
>  
> +	/*
> +	 * IOMMUs would have to be enabled specifically for runtime resume.
> +	 * They would have been already enabled automatically through System
> +	 * PM callbacks for regular system resume
> +	 */
> +	if (auto_suspend) {
> +		ret = omap_iommu_domain_activate(rproc->domain);
> +		if (ret) {
> +			dev_err(dev, "omap_iommu activate failed %d\n", ret);
> +			goto out;
> +		}
> +	}
> +
>  	/* boot address could be lost after suspend, so restore it */
>  	if (oproc->boot_data) {
>  		ret = omap_rproc_write_dsp_boot_addr(rproc);
>  		if (ret) {
>  			dev_err(dev, "boot address restore failed %d\n", ret);
> -			goto out;
> +			goto suspend_iommu;

The same needs to be done if omap_rproc_enable_timers() fails.

>  		}
>  	}
>  
> @@ -633,6 +726,12 @@ static int _omap_rproc_resume(struct rproc *rproc)
>  
>  	reset_control_deassert(oproc->reset);
>  
> +	return 0;
> +
> +suspend_iommu:
> +	if (auto_suspend)
> +		omap_iommu_domain_deactivate(rproc->domain);
> +
>  out:
>  	return ret;
>  }
> @@ -641,6 +740,7 @@ static int __maybe_unused omap_rproc_suspend(struct device *dev)
>  {
>  	struct platform_device *pdev = to_platform_device(dev);
>  	struct rproc *rproc = platform_get_drvdata(pdev);
> +	struct omap_rproc *oproc = rproc->priv;
>  	int ret = 0;
>  
>  	mutex_lock(&rproc->lock);
> @@ -655,13 +755,25 @@ static int __maybe_unused omap_rproc_suspend(struct device *dev)
>  		goto out;
>  	}
>  
> -	ret = _omap_rproc_suspend(rproc);
> +	ret = _omap_rproc_suspend(rproc, false);
>  	if (ret) {
>  		dev_err(dev, "suspend failed %d\n", ret);
>  		goto out;
>  	}
>  
> +	/*
> +	 * remoteproc is running at the time of system suspend, so remember
> +	 * it so as to wake it up during system resume
> +	 */
> +	oproc->need_resume = 1;

Please use 'true' to be consistent with the type and omap_rproc_resume().

>  	rproc->state = RPROC_SUSPENDED;
> +
> +	/*
> +	 * update the runtime pm status to be suspended, without decrementing
> +	 * the device usage count
> +	 */
> +	pm_runtime_disable(dev);
> +	pm_runtime_set_suspended(dev);
>  out:
>  	mutex_unlock(&rproc->lock);
>  	return ret;
> @@ -671,6 +783,7 @@ static int __maybe_unused omap_rproc_resume(struct device *dev)
>  {
>  	struct platform_device *pdev = to_platform_device(dev);
>  	struct rproc *rproc = platform_get_drvdata(pdev);
> +	struct omap_rproc *oproc = rproc->priv;
>  	int ret = 0;
>  
>  	mutex_lock(&rproc->lock);
> @@ -682,17 +795,91 @@ static int __maybe_unused omap_rproc_resume(struct device *dev)
>  		goto out;
>  	}
>  
> -	ret = _omap_rproc_resume(rproc);
> +	/*
> +	 * remoteproc was auto-suspended at the time of system suspend,
> +	 * so no need to wake-up the processor (leave it in suspended
> +	 * state, will be woken up during a subsequent runtime_resume)
> +	 */
> +	if (!oproc->need_resume)
> +		goto out;
> +
> +	ret = _omap_rproc_resume(rproc, false);
>  	if (ret) {
>  		dev_err(dev, "resume failed %d\n", ret);
>  		goto out;
>  	}
> +	oproc->need_resume = false;
>  
>  	rproc->state = RPROC_RUNNING;
> +
> +	/*
> +	 * update the runtime pm status to be active, without incrementing
> +	 * the device usage count
> +	 */
> +	pm_runtime_set_active(dev);
> +	pm_runtime_enable(dev);
> +	pm_runtime_mark_last_busy(dev);
>  out:
>  	mutex_unlock(&rproc->lock);
>  	return ret;
>  }
> +
> +static int omap_rproc_runtime_suspend(struct device *dev)
> +{
> +	struct rproc *rproc = dev_get_drvdata(dev);
> +	struct omap_rproc *oproc = rproc->priv;
> +	int ret;
> +
> +	if (rproc->state == RPROC_CRASHED) {
> +		dev_dbg(dev, "rproc cannot be runtime suspended when crashed!\n");
> +		return -EBUSY;
> +	}
> +
> +	if (WARN_ON(rproc->state != RPROC_RUNNING)) {
> +		dev_err(dev, "rproc cannot be runtime suspended when not running!\n");
> +		return -EBUSY;
> +	}
> +
> +	/*
> +	 * do not even attempt suspend if the remote processor is not
> +	 * idled for runtime auto-suspend
> +	 */
> +	if (!_is_rproc_in_standby(oproc)) {
> +		ret = -EBUSY;
> +		goto abort;
> +	}
> +
> +	ret = _omap_rproc_suspend(rproc, true);
> +	if (ret)
> +		goto abort;
> +
> +	rproc->state = RPROC_SUSPENDED;
> +	return 0;
> +
> +abort:
> +	pm_runtime_mark_last_busy(dev);
> +	return ret;
> +}
> +
> +static int omap_rproc_runtime_resume(struct device *dev)
> +{
> +	struct rproc *rproc = dev_get_drvdata(dev);
> +	int ret;
> +
> +	if (WARN_ON(rproc->state != RPROC_SUSPENDED)) {
> +		dev_err(dev, "rproc cannot be runtime resumed if not suspended!\n");
> +		return -EBUSY;
> +	}
> +
> +	ret = _omap_rproc_resume(rproc, true);
> +	if (ret) {
> +		dev_err(dev, "runtime resume failed %d\n", ret);
> +		return ret;
> +	}
> +
> +	rproc->state = RPROC_RUNNING;
> +	return 0;
> +}
>  #endif /* CONFIG_PM */
>  
>  static const char * const ipu_mem_names[] = {
> @@ -778,6 +965,20 @@ static const struct of_device_id omap_rproc_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
>  
> +static int omap_rproc_get_autosuspend_delay(struct platform_device *pdev)
> +{
> +	const struct omap_rproc_dev_data *data;
> +	int delay;
> +
> +	data = of_device_get_match_data(&pdev->dev);
> +	if (!data)
> +		return -ENODEV;

This check is done in omap_rproc_of_get_internal_memories() and
omap_rproc_get_boot_data().  I think it would be best to do it once at the top
of the probe() function and be done with it.

That being said and as noted in a previous comment, I would push all tuneables
to the DT.  If the property is missing then things default to
DEFAULT_AUTOSUSPEND_DELAY.

> +
> +	delay = data->autosuspend_delay;
> +
> +	return (delay > 0) ? delay : DEFAULT_AUTOSUSPEND_DELAY;
> +}
> +
>  static const char *omap_rproc_get_firmware(struct platform_device *pdev)
>  {
>  	const char *fw_name;
> @@ -953,6 +1154,11 @@ static int omap_rproc_probe(struct platform_device *pdev)
>  	}
>  
>  	init_completion(&oproc->pm_comp);
> +	oproc->autosuspend_delay = omap_rproc_get_autosuspend_delay(pdev);
> +	if (oproc->autosuspend_delay < 0) {
> +		ret = oproc->autosuspend_delay;
> +		goto free_rproc;
> +	}
>  
>  	oproc->fck = devm_clk_get(&pdev->dev, 0);
>  	if (IS_ERR(oproc->fck)) {
> @@ -994,6 +1200,8 @@ static int omap_rproc_remove(struct platform_device *pdev)
>  
>  static const struct dev_pm_ops omap_rproc_pm_ops = {
>  	SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
> +	SET_RUNTIME_PM_OPS(omap_rproc_runtime_suspend,
> +			   omap_rproc_runtime_resume, NULL)
>  };
>  
>  static struct platform_driver omap_rproc_driver = {
> -- 
> 2.17.1
> 
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation
  2019-12-19 13:18     ` Tero Kristo
@ 2019-12-20  0:12       ` Mathieu Poirier
  2019-12-20  2:34         ` Suman Anna
  0 siblings, 1 reply; 50+ messages in thread
From: Mathieu Poirier @ 2019-12-20  0:12 UTC (permalink / raw)
  To: Tero Kristo
  Cc: Bjorn Andersson, Ohad Ben-Cohen, linux-remoteproc,
	Linux Kernel Mailing List, linux-omap, Suman Anna

On Thu, 19 Dec 2019 at 06:18, Tero Kristo <t-kristo@ti.com> wrote:
>
> On 18/12/2019 02:38, Mathieu Poirier wrote:
> > On Fri, Dec 13, 2019 at 02:55:27PM +0200, Tero Kristo wrote:
> >> From: Suman Anna <s-anna@ti.com>
> >>
> >> An implementation for the rproc ops .da_to_va() has been added
> >> that provides the address translation between device addresses
> >> to kernel virtual addresses for internal RAMs present on that
> >> particular remote processor device. The implementation provides
> >> the translations based on the addresses parsed and stored during
> >> the probe.
> >>
> >> This ops gets invoked by the exported rproc_da_to_va() function
> >> and allows the remoteproc core's ELF loader to be able to load
> >> program data directly into the internal memories.
> >>
> >> Signed-off-by: Suman Anna <s-anna@ti.com>
> >> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> >> ---
> >>   drivers/remoteproc/omap_remoteproc.c | 39 ++++++++++++++++++++++++++++
> >>   1 file changed, 39 insertions(+)
> >>
> >> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> >> index 844703507a74..28f14e24b389 100644
> >> --- a/drivers/remoteproc/omap_remoteproc.c
> >> +++ b/drivers/remoteproc/omap_remoteproc.c
> >> @@ -232,10 +232,49 @@ static int omap_rproc_stop(struct rproc *rproc)
> >>      return 0;
> >>   }
> >>
> >> +/**
> >> + * omap_rproc_da_to_va() - internal memory translation helper
> >> + * @rproc: remote processor to apply the address translation for
> >> + * @da: device address to translate
> >> + * @len: length of the memory buffer
> >> + *
> >> + * Custom function implementing the rproc .da_to_va ops to provide address
> >> + * translation (device address to kernel virtual address) for internal RAMs
> >> + * present in a DSP or IPU device). The translated addresses can be used
> >> + * either by the remoteproc core for loading, or by any rpmsg bus drivers.
> >> + * Returns the translated virtual address in kernel memory space, or NULL
> >> + * in failure.
> >> + */
> >> +static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> >> +{
> >> +    struct omap_rproc *oproc = rproc->priv;
> >> +    int i;
> >> +    u32 offset;
> >> +
> >> +    if (len <= 0)
> >> +            return NULL;
> >> +
> >> +    if (!oproc->num_mems)
> >> +            return NULL;
> >> +
> >> +    for (i = 0; i < oproc->num_mems; i++) {
> >> +            if (da >= oproc->mem[i].dev_addr && da + len <=
> >
> > Shouldn't this be '<' rather than '<=' ?
>
> No, I think <= is correct. You need to consider the initial byte in the
> range also. Consider a simple case where you provide the exact da + len
> corresponding to a specific memory range.

For that specific case you are correct.  On the flip side if @da falls
somewhere after @mem[i].dev_addr, there is a possibility to clobber
the first byte of the next range if <= is used.

Thanks,
Mathieu

>
> >
> >> +                oproc->mem[i].dev_addr +  oproc->mem[i].size) {
> >
> > One space too many after the '+' .
>
> True, I wonder why checkpatch did not catch this.
>
> >
> >> +                    offset = da -  oproc->mem[i].dev_addr;
> >
> > One space too many after then '-' .
>
> Same, will fix these two.
>
> -Tero
>
> >
> >> +                    /* __force to make sparse happy with type conversion */
> >> +                    return (__force void *)(oproc->mem[i].cpu_addr +
> >> +                                            offset);
> >> +            }
> >> +    }
> >> +
> >> +    return NULL;
> >> +}
> >> +
> >>   static const struct rproc_ops omap_rproc_ops = {
> >>      .start          = omap_rproc_start,
> >>      .stop           = omap_rproc_stop,
> >>      .kick           = omap_rproc_kick,
> >> +    .da_to_va       = omap_rproc_da_to_va,
> >>   };
> >>
> >>   static const char * const ipu_mem_names[] = {
> >> --
> >> 2.17.1
> >>
> >> --
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 02/15] remoteproc/omap: Add device tree support
  2019-12-19 11:54     ` Tero Kristo
@ 2019-12-20  2:08       ` Suman Anna
  2019-12-20  9:36         ` Tero Kristo
  0 siblings, 1 reply; 50+ messages in thread
From: Suman Anna @ 2019-12-20  2:08 UTC (permalink / raw)
  To: Tero Kristo, Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Tony Lindgren

Hi Tero, Mathieu,

On 12/19/19 5:54 AM, Tero Kristo wrote:
> On 18/12/2019 01:01, Mathieu Poirier wrote:
>> Hi Tero,
>>
>> On Fri, Dec 13, 2019 at 02:55:24PM +0200, Tero Kristo wrote:
>>> From: Suman Anna <s-anna@ti.com>
>>>
>>> OMAP4+ SoCs support device tree boot only. The OMAP remoteproc
>>> driver is enhanced to support remoteproc devices created through
>>> Device Tree, support for legacy platform devices has been
>>> deprecated. The current DT support handles the IPU and DSP
>>> processor subsystems on OMAP4 and OMAP5 SoCs.
>>>
>>> The OMAP remoteproc driver relies on the ti-sysc, reset, and
>>> syscon layers for performing clock, reset and boot vector
>>> management (DSP remoteprocs only) of the devices, but some of
>>> these are limited only to the machine-specific layers
>>> in arch/arm. The dependency against control module API for boot
>>> vector management of the DSP remoteprocs has now been removed
>>> with added logic to parse the boot register from the DT node
>>> and program it appropriately directly within the driver.
>>>
>>> The OMAP remoteproc driver expects the firmware names to be
>>> provided via device tree entries (firmware-name.) These are used
>>> to load the proper firmware during boot of the remote processor.
>>>
>>> Cc: Tony Lindgren <tony@atomide.com>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> [t-kristo@ti.com: converted to use ti-sysc framework]
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> ---
>>>   drivers/remoteproc/omap_remoteproc.c | 191 +++++++++++++++++++++++----
>>>   1 file changed, 168 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/remoteproc/omap_remoteproc.c
>>> b/drivers/remoteproc/omap_remoteproc.c
>>> index 6398194075aa..558634624590 100644
>>> --- a/drivers/remoteproc/omap_remoteproc.c
>>> +++ b/drivers/remoteproc/omap_remoteproc.c
>>> @@ -2,7 +2,7 @@
>>>   /*
>>>    * OMAP Remote Processor driver
>>>    *
>>> - * Copyright (C) 2011 Texas Instruments, Inc.
>>> + * Copyright (C) 2011-2019 Texas Instruments Incorporated -
>>> http://www.ti.com/
>>>    * Copyright (C) 2011 Google, Inc.
>>>    *
>>>    * Ohad Ben-Cohen <ohad@wizery.com>
>>> @@ -16,27 +16,53 @@
>>>   #include <linux/kernel.h>
>>>   #include <linux/module.h>
>>>   #include <linux/err.h>
>>> +#include <linux/of_device.h>
>>>   #include <linux/platform_device.h>
>>>   #include <linux/dma-mapping.h>
>>>   #include <linux/remoteproc.h>
>>>   #include <linux/mailbox_client.h>
>>>   #include <linux/omap-mailbox.h>
>>> -
>>> -#include <linux/platform_data/remoteproc-omap.h>
>>> +#include <linux/regmap.h>
>>> +#include <linux/mfd/syscon.h>
>>> +#include <linux/reset.h>
>>>     #include "omap_remoteproc.h"
>>>   #include "remoteproc_internal.h"
>>>   +/**
>>> + * struct omap_rproc_boot_data - boot data structure for the DSP
>>> omap rprocs
>>> + * @syscon: regmap handle for the system control configuration module
>>> + * @boot_reg: boot register offset within the @syscon regmap
>>> + */
>>> +struct omap_rproc_boot_data {
>>> +    struct regmap *syscon;
>>> +    unsigned int boot_reg;
>>> +};
>>> +
>>>   /**
>>>    * struct omap_rproc - omap remote processor state
>>>    * @mbox: mailbox channel handle
>>>    * @client: mailbox client to request the mailbox channel
>>> + * @boot_data: boot data structure for setting processor boot address
>>>    * @rproc: rproc handle
>>> + * @reset: reset handle
>>>    */
>>>   struct omap_rproc {
>>>       struct mbox_chan *mbox;
>>>       struct mbox_client client;
>>> +    struct omap_rproc_boot_data *boot_data;
>>>       struct rproc *rproc;
>>> +    struct reset_control *reset;
>>> +};
>>> +
>>> +/**
>>> + * struct omap_rproc_dev_data - device data for the omap remote
>>> processor
>>> + * @device_name: device name of the remote processor
>>> + * @has_bootreg: true if this remote processor has boot register
>>> + */
>>> +struct omap_rproc_dev_data {
>>> +    const char *device_name;
>>> +    bool has_bootreg;
>>>   };
>>>     /**
>>> @@ -92,6 +118,21 @@ static void omap_rproc_kick(struct rproc *rproc,
>>> int vqid)
>>>               ret);
>>>   }
>>>   +/**
>>> + * omap_rproc_write_dsp_boot_addr - set boot address for a DSP
>>> remote processor
>>> + * @rproc: handle of a remote processor
>>> + *
>>> + * Set boot address for a supported DSP remote processor.
>>> + */
>>> +static void omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
>>> +{
>>> +    struct omap_rproc *oproc = rproc->priv;
>>> +    struct omap_rproc_boot_data *bdata = oproc->boot_data;
>>> +    u32 offset = bdata->boot_reg;
>>> +
>>> +    regmap_write(bdata->syscon, offset, rproc->bootaddr);
>>> +}
>>> +
>>>   /*
>>>    * Power up the remote processor.
>>>    *
>>> @@ -103,13 +144,11 @@ static int omap_rproc_start(struct rproc *rproc)
>>>   {
>>>       struct omap_rproc *oproc = rproc->priv;
>>>       struct device *dev = rproc->dev.parent;
>>> -    struct platform_device *pdev = to_platform_device(dev);
>>> -    struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>>>       int ret;
>>>       struct mbox_client *client = &oproc->client;
>>>   -    if (pdata->set_bootaddr)
>>> -        pdata->set_bootaddr(rproc->bootaddr);
>>> +    if (oproc->boot_data)
>>> +        omap_rproc_write_dsp_boot_addr(rproc);
>>>         client->dev = dev;
>>>       client->tx_done = NULL;
>>> @@ -117,7 +156,7 @@ static int omap_rproc_start(struct rproc *rproc)
>>>       client->tx_block = false;
>>>       client->knows_txdone = false;
>>>   -    oproc->mbox = omap_mbox_request_channel(client,
>>> pdata->mbox_name);
>>> +    oproc->mbox = mbox_request_channel(client, 0);
>>>       if (IS_ERR(oproc->mbox)) {
>>>           ret = -EBUSY;
>>>           dev_err(dev, "mbox_request_channel failed: %ld\n",
>>> @@ -138,11 +177,7 @@ static int omap_rproc_start(struct rproc *rproc)
>>>           goto put_mbox;
>>>       }
>>>   -    ret = pdata->device_enable(pdev);
>>> -    if (ret) {
>>> -        dev_err(dev, "omap_device_enable failed: %d\n", ret);
>>> -        goto put_mbox;
>>> -    }
>>> +    reset_control_deassert(oproc->reset);
>>>         return 0;
>>>   @@ -154,15 +189,9 @@ static int omap_rproc_start(struct rproc *rproc)
>>>   /* power off the remote processor */
>>>   static int omap_rproc_stop(struct rproc *rproc)
>>>   {
>>> -    struct device *dev = rproc->dev.parent;
>>> -    struct platform_device *pdev = to_platform_device(dev);
>>> -    struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>>>       struct omap_rproc *oproc = rproc->priv;
>>> -    int ret;
>>>   -    ret = pdata->device_shutdown(pdev);
>>> -    if (ret)
>>> -        return ret;
>>> +    reset_control_assert(oproc->reset);

Any reasons for dropping the checks for the return status and wherever
you replaced the pdata callbacks with the desired reset API?

>>>         mbox_free_channel(oproc->mbox);
>>>   @@ -175,12 +204,122 @@ static const struct rproc_ops omap_rproc_ops
>>> = {
>>>       .kick        = omap_rproc_kick,
>>>   };
>>>   +static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>>> +    .device_name    = "dsp",
>>> +    .has_bootreg    = true,
>>> +};
>>> +
>>> +static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
>>> +    .device_name    = "ipu",
>>> +};
>>> +
>>> +static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
>>> +    .device_name    = "dsp",
>>> +    .has_bootreg    = true,
>>> +};
>>> +
>>> +static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
>>> +    .device_name    = "ipu",
>>> +};
>>> +
>>> +static const struct of_device_id omap_rproc_of_match[] = {
>>> +    {
>>> +        .compatible     = "ti,omap4-dsp",
>>> +        .data           = &omap4_dsp_dev_data,
>>> +    },
>>> +    {
>>> +        .compatible     = "ti,omap4-ipu",
>>> +        .data           = &omap4_ipu_dev_data,
>>> +    },
>>> +    {
>>> +        .compatible     = "ti,omap5-dsp",
>>> +        .data           = &omap5_dsp_dev_data,
>>> +    },
>>> +    {
>>> +        .compatible     = "ti,omap5-ipu",
>>> +        .data           = &omap5_ipu_dev_data,
>>> +    },
>>> +    {
>>> +        /* end */
>>> +    },
>>> +};
>>> +MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
>>> +
>>> +static const char *omap_rproc_get_firmware(struct platform_device
>>> *pdev)
>>> +{
>>> +    const char *fw_name;
>>> +    int ret;
>>> +
>>> +    ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
>>> +                      &fw_name);
>>> +    if (ret)
>>> +        return ERR_PTR(ret);
>>> +
>>> +    return fw_name;
>>> +}
>>> +
>>> +static int omap_rproc_get_boot_data(struct platform_device *pdev,
>>> +                    struct rproc *rproc)
>>> +{
>>> +    struct device_node *np = pdev->dev.of_node;
>>> +    struct omap_rproc *oproc = rproc->priv;
>>> +    const struct omap_rproc_dev_data *data;
>>> +    int ret;
>>> +
>>> +    data = of_device_get_match_data(&pdev->dev);
>>> +    if (!data)
>>> +        return -ENODEV;
>>> +
>>> +    if (!data->has_bootreg)
>>> +        return 0;
>>> +
>>> +    oproc->boot_data = devm_kzalloc(&pdev->dev,
>>> sizeof(*oproc->boot_data),
>>> +                    GFP_KERNEL);
>>> +    if (!oproc->boot_data)
>>> +        return -ENOMEM;
>>> +
>>> +    if (!of_property_read_bool(np, "ti,bootreg")) {
>>> +        dev_err(&pdev->dev, "ti,bootreg property is missing\n");
>>> +        return -EINVAL;
>>> +    }
>>> +
>>> +    oproc->boot_data->syscon =
>>> +            syscon_regmap_lookup_by_phandle(np, "ti,bootreg");
>>> +    if (IS_ERR(oproc->boot_data->syscon)) {
>>> +        ret = PTR_ERR(oproc->boot_data->syscon);
>>> +        return ret;
>>> +    }
>>> +
>>> +    if (of_property_read_u32_index(np, "ti,bootreg", 1,
>>> +                       &oproc->boot_data->boot_reg)) {
>>> +        dev_err(&pdev->dev, "couldn't get the boot register\n");
>>> +        return -EINVAL;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +
>>>   static int omap_rproc_probe(struct platform_device *pdev)
>>>   {
>>> -    struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>>> +    struct device_node *np = pdev->dev.of_node;
>>>       struct omap_rproc *oproc;
>>>       struct rproc *rproc;
>>> +    const char *firmware;
>>>       int ret;
>>> +    struct reset_control *reset;
>>> +
>>> +    if (!np) {
>>> +        dev_err(&pdev->dev, "only DT-based devices are supported\n");
>>> +        return -ENODEV;
>>> +    }
>>> +
>>> +    reset =
>>> devm_reset_control_array_get_optional_exclusive(&pdev->dev);
>>> +    if (IS_ERR(reset))
>>> +        return PTR_ERR(reset);
>>
>> Definition of a reset is listed as "required" in the bindings but here
>> it is
>> optional.  If this is really what you want then adding a comment to
>> exlain your
>> choice is probably a good idea.
> 
> Right, I think I updated the binding to require this but forgot to
> update the driver for this part. Will fix this.
> 
> -Tero
> 
>>
>>> +
>>> +    firmware = omap_rproc_get_firmware(pdev);
>>> +    if (IS_ERR(firmware))
>>> +        return PTR_ERR(firmware);
>>>         ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
>>>       if (ret) {
>>> @@ -188,16 +327,21 @@ static int omap_rproc_probe(struct
>>> platform_device *pdev)
>>>           return ret;
>>>       }
>>>   -    rproc = rproc_alloc(&pdev->dev, pdata->name, &omap_rproc_ops,
>>> -                pdata->firmware, sizeof(*oproc));
>>> +    rproc = rproc_alloc(&pdev->dev, dev_name(&pdev->dev),
>>> &omap_rproc_ops,
>>> +                firmware, sizeof(*oproc));
>>>       if (!rproc)
>>>           return -ENOMEM;
>>>         oproc = rproc->priv;
>>>       oproc->rproc = rproc;
>>> +    oproc->reset = reset;
>>>       /* All existing OMAP IPU and DSP processors have an MMU */
>>>       rproc->has_iommu = true;
>>>   +    ret = omap_rproc_get_boot_data(pdev, rproc);
>>> +    if (ret)
>>> +        goto free_rproc;
>>> +
>>>       platform_set_drvdata(pdev, rproc);
>>>         ret = rproc_add(rproc);
>>> @@ -226,6 +370,7 @@ static struct platform_driver omap_rproc_driver = {
>>>       .remove = omap_rproc_remove,
>>>       .driver = {
>>>           .name = "omap-rproc",
>>> +        .of_match_table = omap_rproc_of_match,
>>
>>                  .of_match_table = of_match_ptr(omap_rproc_of_match),

I had dropped this sometime back intentionally as all our platforms are
DT-only.

regards
Suman

>>
>> Thanks,
>> Mathieu
>>
>>>       },
>>>   };
>>>   -- 
>>> 2.17.1
>>>
>>> -- 
> 
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 04/15] remoteproc/omap: Add support to parse internal memories from DT
  2019-12-19 17:37       ` Mathieu Poirier
@ 2019-12-20  2:15         ` Suman Anna
  0 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2019-12-20  2:15 UTC (permalink / raw)
  To: Mathieu Poirier, Tero Kristo
  Cc: Bjorn Andersson, Ohad Ben-Cohen, linux-remoteproc,
	Linux Kernel Mailing List, linux-omap

On 12/19/19 11:37 AM, Mathieu Poirier wrote:
> On Thu, 19 Dec 2019 at 05:31, Tero Kristo <t-kristo@ti.com> wrote:
>>
>> On 18/12/2019 02:22, Mathieu Poirier wrote:
>>> On Fri, Dec 13, 2019 at 02:55:26PM +0200, Tero Kristo wrote:
>>>> From: Suman Anna <s-anna@ti.com>
>>>>
>>>> The OMAP remoteproc driver has been enhanced to parse and store
>>>> the kernel mappings for different internal RAM memories that may
>>>> be present within each remote processor IP subsystem. Different
>>>> devices have varying memories present on current SoCs. The current
>>>> support handles the L2RAM for all IPU devices on OMAP4+ SoCs. The
>>>> DSPs on OMAP4/OMAP5 only have Unicaches and do not have any L1 or
>>>> L2 RAM memories.
>>>>
>>>> IPUs are expected to have the L2RAM at a fixed device address of
>>>> 0x20000000, based on the current limitations on Attribute MMU
>>>> configurations.
>>>>
>>>> NOTE:
>>>> The current logic doesn't handle the parsing of memories for DRA7
>>>> remoteproc devices, and will be added alongside the DRA7 support.
>>>>
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>> [t-kristo: converted to parse mem names / device addresses from pdata]
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>>   drivers/remoteproc/omap_remoteproc.c | 86 ++++++++++++++++++++++++++++
>>>>   1 file changed, 86 insertions(+)
>>>>
>>>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>>>> index d80f5d7b5931..844703507a74 100644
>>>> --- a/drivers/remoteproc/omap_remoteproc.c
>>>> +++ b/drivers/remoteproc/omap_remoteproc.c
>>>> @@ -39,11 +39,27 @@ struct omap_rproc_boot_data {
>>>>      unsigned int boot_reg;
>>>>   };
>>>>
>>>> +/*

Somehow a second trailing * got dropped by mistake here.

>>>> + * struct omap_rproc_mem - 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 of the memory region from DSP view
>>>> + * @size: size of the memory region
>>>> + */
>>>> +struct omap_rproc_mem {
>>>> +    void __iomem *cpu_addr;
>>>> +    phys_addr_t bus_addr;
>>>> +    u32 dev_addr;
>>>> +    size_t size;
>>>> +};
>>>> +
>>>>   /**
>>>>    * struct omap_rproc - omap remote processor state
>>>>    * @mbox: mailbox channel handle
>>>>    * @client: mailbox client to request the mailbox channel
>>>>    * @boot_data: boot data structure for setting processor boot address
>>>> + * @mem: internal memory regions data
>>>> + * @num_mems: number of internal memory regions
>>>>    * @rproc: rproc handle
>>>>    * @reset: reset handle
>>>>    */
>>>> @@ -51,6 +67,8 @@ struct omap_rproc {
>>>>      struct mbox_chan *mbox;
>>>>      struct mbox_client client;
>>>>      struct omap_rproc_boot_data *boot_data;
>>>> +    struct omap_rproc_mem *mem;
>>>> +    int num_mems;
>>>>      struct rproc *rproc;
>>>>      struct reset_control *reset;
>>>>   };
>>>> @@ -59,10 +77,14 @@ struct omap_rproc {
>>>>    * struct omap_rproc_dev_data - device data for the omap remote processor
>>>>    * @device_name: device name of the remote processor
>>>>    * @has_bootreg: true if this remote processor has boot register
>>>> + * @mem_names: memory names for this remote processor
>>>> + * @dev_addrs: device addresses corresponding to the memory names
>>>>    */
>>>>   struct omap_rproc_dev_data {
>>>>      const char *device_name;
>>>>      bool has_bootreg;
>>>> +    const char * const *mem_names;
>>>> +    const u32 *dev_addrs;
>>>
>>> Bunching these two in a new structure like omap_rproc_mem_data would clean
>>> things up.  That way the two arrays in the next hunk get merged and there can't
>>> be a difference in sizes, somthing that will sturdy the main loop in
>>> omap_rproc_of_get_internal_memories() below.
>>
>> Will fix this.
>>
>>>
>>>>   };
>>>>
>>>>   /**
>>>> @@ -216,6 +238,14 @@ static const struct rproc_ops omap_rproc_ops = {
>>>>      .kick           = omap_rproc_kick,
>>>>   };
>>>>
>>>> +static const char * const ipu_mem_names[] = {
>>>> +    "l2ram", NULL
>>>> +};
>>>> +
>>>> +static const u32 ipu_dev_addrs[] = {
>>>> +    0x20000000,
>>>> +};
>>>> +
>>>>   static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>>>>      .device_name    = "dsp",
>>>>      .has_bootreg    = true,
>>>> @@ -223,6 +253,8 @@ static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>>>>
>>>>   static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
>>>>      .device_name    = "ipu",
>>>> +    .mem_names      = ipu_mem_names,
>>>> +    .dev_addrs      = ipu_dev_addrs,
>>>>   };
>>>>
>>>>   static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
>>>> @@ -232,6 +264,8 @@ static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
>>>>
>>>>   static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
>>>>      .device_name    = "ipu",
>>>> +    .mem_names      = ipu_mem_names,
>>>> +    .dev_addrs      = ipu_dev_addrs,
>>>>   };
>>>>
>>>>   static const struct of_device_id omap_rproc_of_match[] = {
>>>> @@ -311,6 +345,54 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev,
>>>>      return 0;
>>>>   }
>>>>
>>>> +static int omap_rproc_of_get_internal_memories(struct platform_device *pdev,
>>>> +                                           struct rproc *rproc)
>>>> +{
>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>> +    struct device *dev = &pdev->dev;
>>>> +    const struct omap_rproc_dev_data *data;
>>>> +    struct resource *res;
>>>> +    int num_mems;
>>>> +    int i;
>>>> +
>>>> +    data = of_device_get_match_data(&pdev->dev);
>>>> +    if (!data)
>>>> +            return -ENODEV;
>>>> +
>>>> +    if (!data->mem_names)
>>>> +            return 0;
>>>> +
>>>> +    for (num_mems = 0; data->mem_names[num_mems]; num_mems++)
>>>> +            ;
>>>
>>> Instead of doing this function of_property_count_elems_of_size() can be used on
>>> the "reg" property.
>>
>> Hmm right, but the problem is then we don't know if someone left out one
>> of the memories in DT. We want to check the presence for all defined in
>> the platform data.
>>
> 
> In my opinion (and to go along what I advocated in a comment on
> another patch) everything should be dictated from the DT.  If an area
> of reserved memory is missing in the DT then the infrastructure should
> recognise it and refuse to move forward with initialisation.

That's actually what the code does too. It is just different remoteprocs
have different internal memories, and that array of names is actually
retrieved here based on match data.

regards
Suman

> 
> Thanks
> Mathieu
> 
>>>
>>> In the loop below a check should be done to see if data->mem_data[i] (see above
>>> comment) is valid before calling platform_get_resource_byname().  If not then
>>> an error can be returned.
>>
>> Will add a check to it.
>>
>> -Tero
>>
>>>
>>> I'm running out of time for today - I will continue reviewing the other patches
>>> tomorrow.
>>>
>>>> +
>>>> +    oproc->mem = devm_kcalloc(dev, num_mems, sizeof(*oproc->mem),
>>>> +                              GFP_KERNEL);
>>>> +    if (!oproc->mem)
>>>> +            return -ENOMEM;
>>>> +
>>>> +    for (i = 0; i < num_mems; i++) {
>>>> +            res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>>>> +                                               data->mem_names[i]);
>>>> +            oproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
>>>> +            if (IS_ERR(oproc->mem[i].cpu_addr)) {
>>>> +                    dev_err(dev, "failed to parse and map %s memory\n",
>>>> +                            data->mem_names[i]);
>>>> +                    return PTR_ERR(oproc->mem[i].cpu_addr);
>>>> +            }
>>>> +            oproc->mem[i].bus_addr = res->start;
>>>> +            oproc->mem[i].dev_addr = data->dev_addrs[i];
>>>> +            oproc->mem[i].size = resource_size(res);
>>>> +
>>>> +            dev_dbg(dev, "memory %8s: bus addr %pa size 0x%x va %p da 0x%x\n",
>>>> +                    data->mem_names[i], &oproc->mem[i].bus_addr,
>>>> +                    oproc->mem[i].size, oproc->mem[i].cpu_addr,
>>>> +                    oproc->mem[i].dev_addr);
>>>> +    }
>>>> +    oproc->num_mems = num_mems;
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>>   static int omap_rproc_probe(struct platform_device *pdev)
>>>>   {
>>>>      struct device_node *np = pdev->dev.of_node;
>>>> @@ -350,6 +432,10 @@ static int omap_rproc_probe(struct platform_device *pdev)
>>>>      /* All existing OMAP IPU and DSP processors have an MMU */
>>>>      rproc->has_iommu = true;
>>>>
>>>> +    ret = omap_rproc_of_get_internal_memories(pdev, rproc);
>>>> +    if (ret)
>>>> +            goto free_rproc;
>>>> +
>>>>      ret = omap_rproc_get_boot_data(pdev, rproc);
>>>>      if (ret)
>>>>              goto free_rproc;
>>>> --
>>>> 2.17.1
>>>>
>>>> --
>>
>> --
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation
  2019-12-20  0:12       ` Mathieu Poirier
@ 2019-12-20  2:34         ` Suman Anna
  2019-12-20 22:15           ` Mathieu Poirier
  0 siblings, 1 reply; 50+ messages in thread
From: Suman Anna @ 2019-12-20  2:34 UTC (permalink / raw)
  To: Mathieu Poirier, Tero Kristo
  Cc: Bjorn Andersson, Ohad Ben-Cohen, linux-remoteproc,
	Linux Kernel Mailing List, linux-omap

On 12/19/19 6:12 PM, Mathieu Poirier wrote:
> On Thu, 19 Dec 2019 at 06:18, Tero Kristo <t-kristo@ti.com> wrote:
>>
>> On 18/12/2019 02:38, Mathieu Poirier wrote:
>>> On Fri, Dec 13, 2019 at 02:55:27PM +0200, Tero Kristo wrote:
>>>> From: Suman Anna <s-anna@ti.com>
>>>>
>>>> An implementation for the rproc ops .da_to_va() has been added
>>>> that provides the address translation between device addresses
>>>> to kernel virtual addresses for internal RAMs present on that
>>>> particular remote processor device. The implementation provides
>>>> the translations based on the addresses parsed and stored during
>>>> the probe.
>>>>
>>>> This ops gets invoked by the exported rproc_da_to_va() function
>>>> and allows the remoteproc core's ELF loader to be able to load
>>>> program data directly into the internal memories.
>>>>
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>>   drivers/remoteproc/omap_remoteproc.c | 39 ++++++++++++++++++++++++++++
>>>>   1 file changed, 39 insertions(+)
>>>>
>>>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>>>> index 844703507a74..28f14e24b389 100644
>>>> --- a/drivers/remoteproc/omap_remoteproc.c
>>>> +++ b/drivers/remoteproc/omap_remoteproc.c
>>>> @@ -232,10 +232,49 @@ static int omap_rproc_stop(struct rproc *rproc)
>>>>      return 0;
>>>>   }
>>>>
>>>> +/**
>>>> + * omap_rproc_da_to_va() - internal memory translation helper
>>>> + * @rproc: remote processor to apply the address translation for
>>>> + * @da: device address to translate
>>>> + * @len: length of the memory buffer
>>>> + *
>>>> + * Custom function implementing the rproc .da_to_va ops to provide address
>>>> + * translation (device address to kernel virtual address) for internal RAMs
>>>> + * present in a DSP or IPU device). The translated addresses can be used
>>>> + * either by the remoteproc core for loading, or by any rpmsg bus drivers.
>>>> + * Returns the translated virtual address in kernel memory space, or NULL
>>>> + * in failure.
>>>> + */
>>>> +static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
>>>> +{
>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>> +    int i;
>>>> +    u32 offset;
>>>> +
>>>> +    if (len <= 0)
>>>> +            return NULL;
>>>> +
>>>> +    if (!oproc->num_mems)
>>>> +            return NULL;
>>>> +
>>>> +    for (i = 0; i < oproc->num_mems; i++) {
>>>> +            if (da >= oproc->mem[i].dev_addr && da + len <=
>>>
>>> Shouldn't this be '<' rather than '<=' ?
>>
>> No, I think <= is correct. You need to consider the initial byte in the
>> range also. Consider a simple case where you provide the exact da + len
>> corresponding to a specific memory range.
> 
> For that specific case you are correct.  On the flip side if @da falls
> somewhere after @mem[i].dev_addr, there is a possibility to clobber
> the first byte of the next range if <= is used.

Not really, you will miss out on the last byte actually if you use just
<. This is just address range check, any memcpy would actually end one
byte before.

Eg: 0x80000 of len 0x10000. I should perfectly be able to copy 0x1000
bytes at 0x8f000.

regards
Suman


> 
> Thanks,
> Mathieu
> 
>>
>>>
>>>> +                oproc->mem[i].dev_addr +  oproc->mem[i].size) {
>>>
>>> One space too many after the '+' .
>>
>> True, I wonder why checkpatch did not catch this.
>>
>>>
>>>> +                    offset = da -  oproc->mem[i].dev_addr;
>>>
>>> One space too many after then '-' .
>>
>> Same, will fix these two.
>>
>> -Tero
>>
>>>
>>>> +                    /* __force to make sparse happy with type conversion */
>>>> +                    return (__force void *)(oproc->mem[i].cpu_addr +
>>>> +                                            offset);
>>>> +            }
>>>> +    }
>>>> +
>>>> +    return NULL;
>>>> +}
>>>> +
>>>>   static const struct rproc_ops omap_rproc_ops = {
>>>>      .start          = omap_rproc_start,
>>>>      .stop           = omap_rproc_stop,
>>>>      .kick           = omap_rproc_kick,
>>>> +    .da_to_va       = omap_rproc_da_to_va,
>>>>   };
>>>>
>>>>   static const char * const ipu_mem_names[] = {
>>>> --
>>>> 2.17.1
>>>>
>>>> --
>>
>> --
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 08/15] remoteproc/omap: Remove the unused fields from platform data
  2019-12-13 12:55 ` [PATCHv3 08/15] remoteproc/omap: Remove the unused fields from platform data Tero Kristo
@ 2019-12-20  2:44   ` Suman Anna
  2019-12-20  9:48     ` Tero Kristo
  0 siblings, 1 reply; 50+ messages in thread
From: Suman Anna @ 2019-12-20  2:44 UTC (permalink / raw)
  To: Tero Kristo, bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap

Hi Tero,

On 12/13/19 6:55 AM, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
> 
> The following fields: .name, .oh_name, .oh_name_opt, .mbox_name,
> .firmware, .ops and .set_bootaddr, are removed from the platform data,
> as these are no longer needed after the addition of DT support to the
> OMAP remoteproc driver.
> 
> The .name field was used to give a name to the remoteproc, and this
> is replaced with the device name. The .ops field was never used by
> the OMAP remoteproc driver. The .mbox_name was used to define the
> sub-mailbox node used for communication with the remote processor,
> and is retrieved using the 'mboxes' property in the DT node. The
> .firmware field is encoded directly in the OMAP remoteproc driver and
> is retrieved using driver match data. The .set_bootaddr ops was used
> for using a OMAP Control Module API to configure the boot address for
> the processor, and is now implemented within the driver using a
> syscon property.
> 
> The .oh_name field is used to define the primary hwmod for the processor
> node, and is represented using the 'ti,hwmods' property in the DT node.
> The .oh_name_opt field was primarily defined to identify the hwmod for
> the second cpu in a dual Cortex-M3/M4 IPU processor sub-system. This
> hwmod entry is no longer defined usually, but rather a single hwmod
> representing both the processors in the IPU sub-system is defined.
> A single firmware image (either in SMP-mode or a combined image for
> non-SMP mode) is used, with both the resets released together always
> as part of the device management. Any power management and recovery
> aspects require that both the processors be managed as one entity due
> to the presence of shared MMU and unicache within the IPU sub-system.
> 
> The OMAP remoteproc platform data structure is eventually expected
> to be removed completely once the other dependencies with the
> mach-omap layer are met.

This patch was a cleanup patch with DT using hwmod, and some of the
description is pertinent to that. Now that you have converted to ti,sysc
& reset with no dependencies against hwmod, the time for removing the
structure is here. Some of the patch description is no longer correct as
well since there is no 'ti,hwmods' :)

> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>  include/linux/platform_data/remoteproc-omap.h | 17 +----------------
>  1 file changed, 1 insertion(+), 16 deletions(-)
> 
> diff --git a/include/linux/platform_data/remoteproc-omap.h b/include/linux/platform_data/remoteproc-omap.h
> index 7e3a16097672..6bea01e199fe 100644
> --- a/include/linux/platform_data/remoteproc-omap.h
> +++ b/include/linux/platform_data/remoteproc-omap.h
> @@ -2,38 +2,23 @@
>  /*
>   * Remote Processor - omap-specific bits
>   *
> - * Copyright (C) 2011 Texas Instruments, Inc.
> + * Copyright (C) 2011-2018 Texas Instruments Incorporated - http://www.ti.com/

%s/2018/2019 when you do update the patch.

regards
Suman

>   * Copyright (C) 2011 Google, Inc.
>   */
>  
>  #ifndef _PLAT_REMOTEPROC_H
>  #define _PLAT_REMOTEPROC_H
>  
> -struct rproc_ops;
>  struct platform_device;
>  
>  /*
>   * struct omap_rproc_pdata - omap remoteproc's platform data
> - * @name: the remoteproc's name
> - * @oh_name: omap hwmod device
> - * @oh_name_opt: optional, secondary omap hwmod device
> - * @firmware: name of firmware file to load
> - * @mbox_name: name of omap mailbox device to use with this rproc
> - * @ops: start/stop rproc handlers
>   * @device_enable: omap-specific handler for enabling a device
>   * @device_shutdown: omap-specific handler for shutting down a device
> - * @set_bootaddr: omap-specific handler for setting the rproc boot address
>   */
>  struct omap_rproc_pdata {
> -	const char *name;
> -	const char *oh_name;
> -	const char *oh_name_opt;
> -	const char *firmware;
> -	const char *mbox_name;
> -	const struct rproc_ops *ops;
>  	int (*device_enable)(struct platform_device *pdev);
>  	int (*device_shutdown)(struct platform_device *pdev);
> -	void (*set_bootaddr)(u32);
>  };
>  
>  #if defined(CONFIG_OMAP_REMOTEPROC) || defined(CONFIG_OMAP_REMOTEPROC_MODULE)
> 


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 09/15] remoteproc/omap: Remove the omap_rproc_reserve_cma declaration
  2019-12-13 12:55 ` [PATCHv3 09/15] remoteproc/omap: Remove the omap_rproc_reserve_cma declaration Tero Kristo
@ 2019-12-20  2:47   ` Suman Anna
  2019-12-20  9:49     ` Tero Kristo
  0 siblings, 1 reply; 50+ messages in thread
From: Suman Anna @ 2019-12-20  2:47 UTC (permalink / raw)
  To: Tero Kristo, bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap

Hi Tero,

On 12/13/19 6:55 AM, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
> 
> The omap_rproc_reserve_cma() function is not defined at the moment.
> This prototype was to be used to define a function to declare a
> remoteproc device-specific CMA pool.
> 
> The remoteproc devices will be defined through DT going forward. A
> device specific CMA pool will be defined under the reserved-memory
> node, and will be associated with the appropriate remoteproc device
> node. This function prototype will no longer be needed and has
> therefore been cleaned up.
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>

With the structure removed, you can actually drop the file altogether.

regards
Suman

> ---
>  include/linux/platform_data/remoteproc-omap.h | 12 ------------
>  1 file changed, 12 deletions(-)
> 
> diff --git a/include/linux/platform_data/remoteproc-omap.h b/include/linux/platform_data/remoteproc-omap.h
> index 6bea01e199fe..49c78805916f 100644
> --- a/include/linux/platform_data/remoteproc-omap.h
> +++ b/include/linux/platform_data/remoteproc-omap.h
> @@ -21,16 +21,4 @@ struct omap_rproc_pdata {
>  	int (*device_shutdown)(struct platform_device *pdev);
>  };
>  
> -#if defined(CONFIG_OMAP_REMOTEPROC) || defined(CONFIG_OMAP_REMOTEPROC_MODULE)
> -
> -void __init omap_rproc_reserve_cma(void);
> -
> -#else
> -
> -static inline void __init omap_rproc_reserve_cma(void)
> -{
> -}
> -
> -#endif
> -
>  #endif /* _PLAT_REMOTEPROC_H */
> 


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 12/15] remoteproc/omap: add support for system suspend/resume
  2019-12-19 21:46   ` Mathieu Poirier
@ 2019-12-20  3:11     ` Suman Anna
  2019-12-20 11:04       ` Tero Kristo
  2019-12-20 21:58       ` Mathieu Poirier
  0 siblings, 2 replies; 50+ messages in thread
From: Suman Anna @ 2019-12-20  3:11 UTC (permalink / raw)
  To: Mathieu Poirier, Tero Kristo
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-omap

Hi Mathieu, Tero,

On 12/19/19 3:46 PM, Mathieu Poirier wrote:
> On Fri, Dec 13, 2019 at 02:55:34PM +0200, Tero Kristo wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> This patch adds the support for system suspend/resume to the
>> OMAP remoteproc driver so that the OMAP remoteproc devices can
>> be suspended/resumed during a system suspend/resume. The support
>> is added through the driver PM .suspend/.resume callbacks, and
>> requires appropriate support from the OS running on the remote
>> processors.
>>
>> The IPU & DSP remote processors typically have their own private
>> modules like registers, internal memories, caches etc. The context
>> of these modules need to be saved and restored properly for a
>> suspend/resume to work. These are in general not accessible from
>> the MPU, so the remote processors themselves have to implement
>> the logic for the context save & restore of these modules.
>>
>> The OMAP remoteproc driver initiates a suspend by sending a mailbox
>> message requesting the remote processor to save its context and
>> enter into an idle/standby state. The remote processor should
>> usually stop whatever processing it is doing to switch to a context
>> save mode. The OMAP remoteproc driver detects the completion of
>> the context save by checking the module standby status for the
>> remoteproc device. It also stops any resources used by the remote
>> processors like the timers. The timers need to be running only
>> when the processor is active and executing, and need to be stopped
>> otherwise to allow the timer driver to reach low-power states. The
>> IOMMUs are automatically suspended by the PM core during the late
>> suspend stage, after the remoteproc suspend process is completed by
>> putting the remote processor cores into reset. Thereafter, the Linux
>> kernel can put the domain into further lower power states as possible.
>>
>> The resume sequence undoes the operations performed in the PM suspend
>> callback, by starting the timers and finally releasing the processors
>> from reset. This requires that the remote processor side OS be able to
>> distinguish a power-resume boot from a power-on/cold boot, restore the
>> context of its private modules saved during the suspend phase, and
>> resume executing code from where it was suspended. The IOMMUs would
>> have been resumed by the PM core during early resume, so they are
>> already enabled by the time remoteproc resume callback gets invoked.
>>
>> The remote processors should save their context into System RAM (DDR),
>> as any internal memories are not guaranteed to retain context as it
>> depends on the lowest power domain that the remote processor device
>> is put into. The management of the DDR contents will be managed by
>> the Linux kernel.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> [t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>  drivers/remoteproc/omap_remoteproc.c | 179 +++++++++++++++++++++++++++
>>  drivers/remoteproc/omap_remoteproc.h |  18 ++-
>>  2 files changed, 195 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>> index 9c750c2ab29d..0a9b9f7d20da 100644
>> --- a/drivers/remoteproc/omap_remoteproc.c
>> +++ b/drivers/remoteproc/omap_remoteproc.c
>> @@ -16,6 +16,7 @@
>>  #include <linux/kernel.h>
>>  #include <linux/module.h>
>>  #include <linux/err.h>
>> +#include <linux/io.h>
>>  #include <linux/of_device.h>
>>  #include <linux/of_reserved_mem.h>
>>  #include <linux/platform_device.h>
>> @@ -23,10 +24,13 @@
>>  #include <linux/remoteproc.h>
>>  #include <linux/mailbox_client.h>
>>  #include <linux/omap-mailbox.h>
>> +#include <linux/omap-iommu.h>
> 
> Please move this up by one line.
> 
>>  #include <linux/regmap.h>
>>  #include <linux/mfd/syscon.h>
>>  #include <linux/reset.h>
>>  #include <clocksource/timer-ti-dm.h>
>> +#include <linux/clk.h>
>> +#include <linux/clk/ti.h>
> 
> Unless there is a dependency with timer-ti-dm.h, these should go just above linux/err.h

No depencencies, can be reordered.

> 
>>  
>>  #include <linux/platform_data/dmtimer-omap.h>
>>  
>> @@ -81,6 +85,9 @@ struct omap_rproc_timer {
>>   * @timers: timer(s) info used by rproc
>>   * @rproc: rproc handle
>>   * @reset: reset handle
>> + * @pm_comp: completion primitive to sync for suspend response
>> + * @fck: functional clock for the remoteproc
>> + * @suspend_acked: state machine flag to store the suspend request ack
>>   */
>>  struct omap_rproc {
>>  	struct mbox_chan *mbox;
>> @@ -92,6 +99,9 @@ struct omap_rproc {
>>  	struct omap_rproc_timer *timers;
>>  	struct rproc *rproc;
>>  	struct reset_control *reset;
>> +	struct completion pm_comp;
>> +	struct clk *fck;
>> +	bool suspend_acked;
>>  };
>>  
>>  /**
>> @@ -349,6 +359,11 @@ static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
>>  	case RP_MBOX_ECHO_REPLY:
>>  		dev_info(dev, "received echo reply from %s\n", name);
>>  		break;
>> +	case RP_MBOX_SUSPEND_ACK:
> 
> We can't get away with implicit fallthroughs anymore - please add /* Fall through */"
> 
>> +	case RP_MBOX_SUSPEND_CANCEL:
>> +		oproc->suspend_acked = msg == RP_MBOX_SUSPEND_ACK;
>> +		complete(&oproc->pm_comp);
>> +		break;
>>  	default:
>>  		if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
>>  			return;
>> @@ -529,6 +544,157 @@ static const struct rproc_ops omap_rproc_ops = {
>>  	.da_to_va	= omap_rproc_da_to_va,
>>  };
>>  
>> +#ifdef CONFIG_PM
>> +static bool _is_rproc_in_standby(struct omap_rproc *oproc)
>> +{
>> +	return ti_clk_is_in_standby(oproc->fck);
>> +}
>> +
>> +/* 1 sec is long enough time to let the remoteproc side suspend the device */
>> +#define DEF_SUSPEND_TIMEOUT 1000
>> +static int _omap_rproc_suspend(struct rproc *rproc)
>> +{
>> +	struct device *dev = rproc->dev.parent;
>> +	struct omap_rproc *oproc = rproc->priv;
>> +	unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
>> +	unsigned long ta = jiffies + to;
>> +	int ret;
>> +
>> +	reinit_completion(&oproc->pm_comp);
>> +	oproc->suspend_acked = false;
>> +	ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_SUSPEND_SYSTEM);
>> +	if (ret < 0) {
>> +		dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	ret = wait_for_completion_timeout(&oproc->pm_comp, to);
>> +	if (!oproc->suspend_acked)
>> +		return -EBUSY;
>> +
>> +	/*
>> +	 * The remoteproc side is returning the ACK message before saving the
>> +	 * context, because the context saving is performed within a SYS/BIOS
>> +	 * function, and it cannot have any inter-dependencies against the IPC
>> +	 * layer. Also, as the SYS/BIOS needs to preserve properly the processor
>> +	 * register set, sending this ACK or signalling the completion of the
>> +	 * context save through a shared memory variable can never be the
>> +	 * absolute last thing to be executed on the remoteproc side, and the
>> +	 * MPU cannot use the ACK message as a sync point to put the remoteproc
>> +	 * into reset. The only way to ensure that the remote processor has
>> +	 * completed saving the context is to check that the module has reached
>> +	 * STANDBY state (after saving the context, the SYS/BIOS executes the
>> +	 * appropriate target-specific WFI instruction causing the module to
>> +	 * enter STANDBY).
>> +	 */
>> +	while (!_is_rproc_in_standby(oproc)) {
>> +		if (time_after(jiffies, ta))
>> +			return -ETIME;
>> +		schedule();
>> +	}
>> +
>> +	reset_control_assert(oproc->reset);
>> +
>> +	ret = omap_rproc_disable_timers(rproc, false);
>> +	if (ret) {
>> +		dev_err(dev, "disabling timers during suspend failed %d\n",
>> +			ret);
>> +		goto enable_device;
>> +	}
>> +
>> +	return 0;
>> +
>> +enable_device:
>> +	reset_control_deassert(oproc->reset);
>> +	return ret;
>> +}
>> +
>> +static int _omap_rproc_resume(struct rproc *rproc)
>> +{
>> +	struct device *dev = rproc->dev.parent;
>> +	struct omap_rproc *oproc = rproc->priv;
>> +	int ret;
>> +
>> +	/* boot address could be lost after suspend, so restore it */
>> +	if (oproc->boot_data) {
>> +		ret = omap_rproc_write_dsp_boot_addr(rproc);
>> +		if (ret) {
>> +			dev_err(dev, "boot address restore failed %d\n", ret);
>> +			goto out;
>> +		}
>> +	}
>> +
>> +	ret = omap_rproc_enable_timers(rproc, false);
>> +	if (ret) {
>> +		dev_err(dev, "enabling timers during resume failed %d\n",
>> +			ret);
> 
> The "ret);" fits on the live above.
> 
>> +		goto out;
>> +	}
>> +
>> +	reset_control_deassert(oproc->reset);
>> +
>> +out:
>> +	return ret;
>> +}
>> +
>> +static int __maybe_unused omap_rproc_suspend(struct device *dev)
> 
> The "__maybe_unused" can be dropped because this is within the #ifdef CONFIG_PM
> block.

These are suspend/resume callbacks, so are actually controlled by
CONFIG_PM_SLEEP which can be disabled independently from runtime
suspend, and hence the annotation.

> 
>> +{
>> +	struct platform_device *pdev = to_platform_device(dev);
>> +	struct rproc *rproc = platform_get_drvdata(pdev);
>> +	int ret = 0;
>> +
>> +	mutex_lock(&rproc->lock);
>> +	if (rproc->state == RPROC_OFFLINE)
>> +		goto out;
>> +
>> +	if (rproc->state == RPROC_SUSPENDED)
>> +		goto out;
>> +
>> +	if (rproc->state != RPROC_RUNNING) {
>> +		ret = -EBUSY;
>> +		goto out;
>> +	}
>> +
>> +	ret = _omap_rproc_suspend(rproc);
>> +	if (ret) {
>> +		dev_err(dev, "suspend failed %d\n", ret);
>> +		goto out;
>> +	}
>> +
>> +	rproc->state = RPROC_SUSPENDED;
>> +out:
>> +	mutex_unlock(&rproc->lock);
>> +	return ret;
>> +}
>> +
>> +static int __maybe_unused omap_rproc_resume(struct device *dev)
> 
> Same comment as above.
> 
>> +{
>> +	struct platform_device *pdev = to_platform_device(dev);
>> +	struct rproc *rproc = platform_get_drvdata(pdev);
>> +	int ret = 0;
>> +
>> +	mutex_lock(&rproc->lock);
>> +	if (rproc->state == RPROC_OFFLINE)
>> +		goto out;
>> +
>> +	if (rproc->state != RPROC_SUSPENDED) {
>> +		ret = -EBUSY;
>> +		goto out;
>> +	}
>> +
>> +	ret = _omap_rproc_resume(rproc);
>> +	if (ret) {
>> +		dev_err(dev, "resume failed %d\n", ret);
>> +		goto out;
>> +	}
>> +
>> +	rproc->state = RPROC_RUNNING;
>> +out:
>> +	mutex_unlock(&rproc->lock);
>> +	return ret;
>> +}
>> +#endif /* CONFIG_PM */
>> +
>>  static const char * const ipu_mem_names[] = {
>>  	"l2ram", NULL
>>  };
>> @@ -786,6 +952,14 @@ static int omap_rproc_probe(struct platform_device *pdev)
>>  			oproc->num_timers);
>>  	}
>>  
>> +	init_completion(&oproc->pm_comp);
>> +
>> +	oproc->fck = devm_clk_get(&pdev->dev, 0);
>> +	if (IS_ERR(oproc->fck)) {
>> +		ret = PTR_ERR(oproc->fck);
>> +		goto free_rproc;
>> +	}
>> +
> 
> oproc->fck is not released if an error occurs in of_reserved_mem_device_init()
> and rproc_add().

We are using a devres managed API, so why do we need to release it
specifically?

> 
>>  	ret = of_reserved_mem_device_init(&pdev->dev);
>>  	if (ret) {
>>  		dev_err(&pdev->dev, "device does not have specific CMA pool\n");
>> @@ -818,11 +992,16 @@ static int omap_rproc_remove(struct platform_device *pdev)
>>  	return 0;
>>  }
>>  
>> +static const struct dev_pm_ops omap_rproc_pm_ops = {
>> +	SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
>> +};
>> +
>>  static struct platform_driver omap_rproc_driver = {
>>  	.probe = omap_rproc_probe,
>>  	.remove = omap_rproc_remove,
>>  	.driver = {
>>  		.name = "omap-rproc",
>> +		.pm = &omap_rproc_pm_ops,
>>  		.of_match_table = omap_rproc_of_match,
>>  	},
>>  };
>> diff --git a/drivers/remoteproc/omap_remoteproc.h b/drivers/remoteproc/omap_remoteproc.h
>> index 72f656c93caa..c73383e707c7 100644
>> --- a/drivers/remoteproc/omap_remoteproc.h
>> +++ b/drivers/remoteproc/omap_remoteproc.h
>> @@ -1,7 +1,7 @@
>>  /*
>>   * Remote processor messaging
>>   *
>> - * Copyright (C) 2011 Texas Instruments, Inc.
>> + * Copyright (C) 2011-2018 Texas Instruments, Inc.

%s/2018/2019/

regards
Suman

>>   * Copyright (C) 2011 Google, Inc.
>>   * All rights reserved.
>>   *
>> @@ -57,6 +57,16 @@
>>   * @RP_MBOX_ABORT_REQUEST: a "please crash" request, used for testing the
>>   * recovery mechanism (to some extent).
>>   *
>> + * @RP_MBOX_SUSPEND_AUTO: auto suspend request for the remote processor
>> + *
>> + * @RP_MBOX_SUSPEND_SYSTEM: system suspend request for the remote processor
>> + *
>> + * @RP_MBOX_SUSPEND_ACK: successful response from remote processor for a
>> + * suspend request
>> + *
>> + * @RP_MBOX_SUSPEND_CANCEL: a cancel suspend response from a remote processor
>> + * on a suspend request
>> + *
>>   * Introduce new message definitions if any here.
>>   *
>>   * @RP_MBOX_END_MSG: Indicates end of known/defined messages from remote core
>> @@ -70,7 +80,11 @@ enum omap_rp_mbox_messages {
>>  	RP_MBOX_ECHO_REQUEST	= 0xFFFFFF03,
>>  	RP_MBOX_ECHO_REPLY	= 0xFFFFFF04,
>>  	RP_MBOX_ABORT_REQUEST	= 0xFFFFFF05,
>> -	RP_MBOX_END_MSG		= 0xFFFFFF06,
>> +	RP_MBOX_SUSPEND_AUTO	= 0xFFFFFF10,
>> +	RP_MBOX_SUSPEND_SYSTEM	= 0xFFFFFF11,
>> +	RP_MBOX_SUSPEND_ACK	= 0xFFFFFF12,
>> +	RP_MBOX_SUSPEND_CANCEL	= 0xFFFFFF13,
>> +	RP_MBOX_END_MSG		= 0xFFFFFF14,
>>  };
>>  
>>  #endif /* _OMAP_RPMSG_H */
>> -- 
>> 2.17.1
>>
>> --
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume
  2019-12-19 23:43   ` Mathieu Poirier
@ 2019-12-20  3:24     ` Suman Anna
  2019-12-20 11:24       ` Tero Kristo
  2019-12-20 11:08     ` Tero Kristo
  1 sibling, 1 reply; 50+ messages in thread
From: Suman Anna @ 2019-12-20  3:24 UTC (permalink / raw)
  To: Mathieu Poirier, Tero Kristo
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-omap

Hi Tero,

On 12/19/19 5:43 PM, Mathieu Poirier wrote:
> On Fri, Dec 13, 2019 at 02:55:35PM +0200, Tero Kristo wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> This patch enhances the PM support in the OMAP remoteproc driver to
>> support the runtime auto-suspend. A remoteproc may not be required to
>> be running all the time, and typically will need to be active only
>> during certain usecases. As such, to save power, it should be turned
>> off during potential long periods of inactivity between usecases.
>> This suspend and resume of the device is a relatively heavy process
>> in terms of latencies, so a remoteproc should be suspended only after
>> a certain period of prolonged inactivity. The OMAP remoteproc driver
>> leverages the runtime pm framework's auto_suspend feature to accomplish
>> this functionality. This feature is automatically enabled when a remote
>> processor has successfully booted. The 'autosuspend_delay_ms' for each
>> device dictates the inactivity period/time to wait for before
>> suspending the device.
>>
>> The runtime auto-suspend design relies on marking the last busy time
>> on every communication (virtqueue kick) to and from the remote processor.
>> When there has been no activity for 'autosuspend_delay_ms' time, the
>> runtime PM framework invokes the driver's runtime pm suspend callback
>> to suspend the device. The remote processor will be woken up on the
>> initiation of the next communication message through the runtime pm
>> resume callback. The current auto-suspend design also allows a remote
>> processor to deny a auto-suspend attempt, if it wishes to, by sending a
>> NACK response to the initial suspend request message sent to the remote
>> processor as part of the suspend process. The auto-suspend request is
>> also only attempted if the remote processor is idled and in standby at
>> the time of inactivity timer expiry. This choice is made to avoid
>> unnecessary messaging, and the auto-suspend is simply rescheduled to
>> be attempted again after a further lapse of autosuspend_delay_ms.
>>
>> The runtime pm callbacks functionality in this patch reuses most of the
>> core logic from the suspend/resume support code, and make use of an
>> additional auto_suspend flag to differentiate the logic in common code
>> from system suspend. The system suspend/resume sequences are also updated
>> to reflect the proper pm_runtime statuses, and also to really perform a
>> suspend/resume only if the remoteproc has not been auto-suspended at the
>> time of request. The remote processor is left in suspended state on a
>> system resume if it has been auto-suspended before, and will be woken up
>> only when a usecase needs to run. The other significant change in this
>> patch is to reset the remoteproc device's pm_domain so as to avoid
>> conflicts with the ordering sequences in the device pm_domain's runtime
>> callbacks and the reset management and clock management implemented
>> within the runtime callbacks in the driver.
>>
>> The OMAP remoteproc driver currently uses a default value of 10 seconds
>> for all OMAP remoteprocs, and a different value can be chosen either by
>> choosing a positive value for the 'autosuspend_delay' in the device's
>> omap_rproc_fw_data in the driver match data or by updating the
>> 'autosuspend_delay_ms' field at runtime through the sysfs interface.
>>     Eg: To use 25 seconds for IPU2 on DRA7xx,
>>       echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms
>>
>> The runtime suspend feature can also be similarly enabled or disabled by
>> writing 'auto' or 'on' to the device's 'control' power field. The default
>> is enabled.
>>     Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
>>       echo on > /sys/bus/platform/devices/55020000.ipu/power/control
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> [t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>  drivers/remoteproc/omap_remoteproc.c | 220 ++++++++++++++++++++++++++-
>>  1 file changed, 214 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>> index 0a9b9f7d20da..463d6f60947a 100644
>> --- a/drivers/remoteproc/omap_remoteproc.c
>> +++ b/drivers/remoteproc/omap_remoteproc.c
>> @@ -20,6 +20,7 @@
>>  #include <linux/of_device.h>
>>  #include <linux/of_reserved_mem.h>
>>  #include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>>  #include <linux/dma-mapping.h>
>>  #include <linux/remoteproc.h>
>>  #include <linux/mailbox_client.h>
>> @@ -37,6 +38,9 @@
>>  #include "omap_remoteproc.h"
>>  #include "remoteproc_internal.h"
>>  
>> +/* default auto-suspend delay (ms) */
>> +#define DEFAULT_AUTOSUSPEND_DELAY		10000
>> +
>>  /**
>>   * struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
>>   * @syscon: regmap handle for the system control configuration module
>> @@ -83,6 +87,8 @@ struct omap_rproc_timer {
>>   * @num_mems: number of internal memory regions
>>   * @num_timers: number of rproc timer(s)
>>   * @timers: timer(s) info used by rproc
>> + * @autosuspend_delay: auto-suspend delay value to be used for runtime pm
>> + * @need_resume: if true a resume is needed in the system resume callback
>>   * @rproc: rproc handle
>>   * @reset: reset handle
>>   * @pm_comp: completion primitive to sync for suspend response
>> @@ -97,6 +103,8 @@ struct omap_rproc {
>>  	int num_mems;
>>  	int num_timers;
>>  	struct omap_rproc_timer *timers;
>> +	int autosuspend_delay;
>> +	bool need_resume;
>>  	struct rproc *rproc;
>>  	struct reset_control *reset;
>>  	struct completion pm_comp;
>> @@ -111,6 +119,7 @@ struct omap_rproc {
>>   * @boot_reg_shift: bit shift for the boot register mask
>>   * @mem_names: memory names for this remote processor
>>   * @dev_addrs: device addresses corresponding to the memory names
>> + * @autosuspend_delay: custom auto-suspend delay value in milliseconds
>>   */
>>  struct omap_rproc_dev_data {
>>  	const char *device_name;
>> @@ -118,6 +127,7 @@ struct omap_rproc_dev_data {
>>  	int boot_reg_shift;
>>  	const char * const *mem_names;
>>  	const u32 *dev_addrs;
>> +	int autosuspend_delay;
>>  };
>>  
>>  /**
>> @@ -384,11 +394,23 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
>>  	struct device *dev = rproc->dev.parent;
>>  	int ret;
>>  
>> +	/* wake up the rproc before kicking it */
>> +	ret = pm_runtime_get_sync(dev);
>> +	if (WARN_ON(ret < 0)) {
>> +		dev_err(dev, "pm_runtime_get_sync() failed during kick, ret = %d\n",
>> +			ret);
>> +		pm_runtime_put_noidle(dev);
>> +		return;
>> +	}
>> +
>>  	/* send the index of the triggered virtqueue in the mailbox payload */
>>  	ret = mbox_send_message(oproc->mbox, (void *)vqid);
>>  	if (ret < 0)
>>  		dev_err(dev, "failed to send mailbox message, status = %d\n",
>>  			ret);
>> +
>> +	pm_runtime_mark_last_busy(dev);
>> +	pm_runtime_put_autosuspend(dev);
>>  }
>>  
>>  /**
>> @@ -473,6 +495,19 @@ static int omap_rproc_start(struct rproc *rproc)
>>  		goto put_mbox;
>>  	}
>>  
>> +	/*
>> +	 * remote processor is up, so update the runtime pm status and
>> +	 * enable the auto-suspend. The device usage count is incremented
>> +	 * manually for balancing it for auto-suspend
>> +	 */
>> +	pm_runtime_set_active(dev);
>> +	pm_runtime_set_autosuspend_delay(dev, oproc->autosuspend_delay);
>> +	pm_runtime_use_autosuspend(dev);
>> +	pm_runtime_get(dev);
>> +	pm_runtime_enable(dev);
>> +	pm_runtime_mark_last_busy(dev);
>> +	pm_runtime_put_autosuspend(dev);
>> +
>>  	reset_control_deassert(oproc->reset);

I see that you have flipped the reset call and all the pm_runtime calls
(w.r.t my original code sequence) and pm_runtime_get instead of
pm_runtime_get_noresume(). Is there a reason for it? What is the backend
that gets exercised with pm_runtime?

>>  
>>  	return 0;
>> @@ -485,9 +520,26 @@ static int omap_rproc_start(struct rproc *rproc)
>>  /* power off the remote processor */
>>  static int omap_rproc_stop(struct rproc *rproc)
>>  {
>> +	struct device *dev = rproc->dev.parent;
>>  	struct omap_rproc *oproc = rproc->priv;
>>  	int ret;
>>  
>> +	/*
>> +	 * cancel any possible scheduled runtime suspend by incrementing
>> +	 * the device usage count, and resuming the device. The remoteproc
>> +	 * also needs to be woken up if suspended, to avoid the remoteproc
>> +	 * OS to continue to remember any context that it has saved, and
>> +	 * avoid potential issues in misindentifying a subsequent device
>> +	 * reboot as a power restore boot
>> +	 */
>> +	ret = pm_runtime_get_sync(dev);
>> +	if (ret < 0) {
>> +		pm_runtime_put_noidle(dev);
>> +		return ret;
>> +	}
>> +
>> +	pm_runtime_put_sync(dev);
>> +

I didn't have this call either. And get_sync() followed by put_sync() is
essentially a no-op. Am I missing something here?

>>  	reset_control_assert(oproc->reset);
>>  
>>  	ret = omap_rproc_disable_timers(rproc, true);
>> @@ -496,6 +548,15 @@ static int omap_rproc_stop(struct rproc *rproc)
>>  
>>  	mbox_free_channel(oproc->mbox);
>>  
>> +	/*
>> +	 * update the runtime pm states and status now that the remoteproc
>> +	 * has stopped
>> +	 */
>> +	pm_runtime_disable(dev);
>> +	pm_runtime_dont_use_autosuspend(dev);
>> +	pm_runtime_put_noidle(dev);
>> +	pm_runtime_set_suspended(dev);
>> +
>>  	return 0;
>>  }
>>  
>> @@ -552,17 +613,19 @@ static bool _is_rproc_in_standby(struct omap_rproc *oproc)
>>  
>>  /* 1 sec is long enough time to let the remoteproc side suspend the device */
>>  #define DEF_SUSPEND_TIMEOUT 1000
>> -static int _omap_rproc_suspend(struct rproc *rproc)
>> +static int _omap_rproc_suspend(struct rproc *rproc, bool auto_suspend)
>>  {
>>  	struct device *dev = rproc->dev.parent;
>>  	struct omap_rproc *oproc = rproc->priv;
>>  	unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
>>  	unsigned long ta = jiffies + to;
>> +	u32 suspend_msg = auto_suspend ?
>> +				RP_MBOX_SUSPEND_AUTO : RP_MBOX_SUSPEND_SYSTEM;
>>  	int ret;
>>  
>>  	reinit_completion(&oproc->pm_comp);
>>  	oproc->suspend_acked = false;
>> -	ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_SUSPEND_SYSTEM);
>> +	ret = mbox_send_message(oproc->mbox, (void *)suspend_msg);
>>  	if (ret < 0) {
>>  		dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
>>  		return ret;
>> @@ -602,25 +665,55 @@ static int _omap_rproc_suspend(struct rproc *rproc)
>>  		goto enable_device;
>>  	}
>>  
>> +	/*
>> +	 * IOMMUs would have to be disabled specifically for runtime suspend.
>> +	 * They are handled automatically through System PM callbacks for
>> +	 * regular system suspend
>> +	 */
>> +	if (auto_suspend) {
>> +		ret = omap_iommu_domain_deactivate(rproc->domain);
>> +		if (ret) {
>> +			dev_err(dev, "iommu domain deactivate failed %d\n",
>> +				ret);
>> +			goto enable_timers;
>> +		}
>> +	}
>> +
>>  	return 0;

blank line here, and remove the one before enable_device.

regards
Suman

>> +enable_timers:
>> +	/* ignore errors on re-enabling code */
>> +	omap_rproc_enable_timers(rproc, false);
>>  
>>  enable_device:
>>  	reset_control_deassert(oproc->reset);
>>  	return ret;
>>  }
>>  
>> -static int _omap_rproc_resume(struct rproc *rproc)
>> +static int _omap_rproc_resume(struct rproc *rproc, bool auto_suspend)
>>  {
>>  	struct device *dev = rproc->dev.parent;
>>  	struct omap_rproc *oproc = rproc->priv;
>>  	int ret;
>>  
>> +	/*
>> +	 * IOMMUs would have to be enabled specifically for runtime resume.
>> +	 * They would have been already enabled automatically through System
>> +	 * PM callbacks for regular system resume
>> +	 */
>> +	if (auto_suspend) {
>> +		ret = omap_iommu_domain_activate(rproc->domain);
>> +		if (ret) {
>> +			dev_err(dev, "omap_iommu activate failed %d\n", ret);
>> +			goto out;
>> +		}
>> +	}
>> +
>>  	/* boot address could be lost after suspend, so restore it */
>>  	if (oproc->boot_data) {
>>  		ret = omap_rproc_write_dsp_boot_addr(rproc);
>>  		if (ret) {
>>  			dev_err(dev, "boot address restore failed %d\n", ret);
>> -			goto out;
>> +			goto suspend_iommu;
> 
> The same needs to be done if omap_rproc_enable_timers() fails.
> 
>>  		}
>>  	}
>>  
>> @@ -633,6 +726,12 @@ static int _omap_rproc_resume(struct rproc *rproc)
>>  
>>  	reset_control_deassert(oproc->reset);
>>  
>> +	return 0;
>> +
>> +suspend_iommu:
>> +	if (auto_suspend)
>> +		omap_iommu_domain_deactivate(rproc->domain);
>> +
>>  out:
>>  	return ret;
>>  }
>> @@ -641,6 +740,7 @@ static int __maybe_unused omap_rproc_suspend(struct device *dev)
>>  {
>>  	struct platform_device *pdev = to_platform_device(dev);
>>  	struct rproc *rproc = platform_get_drvdata(pdev);
>> +	struct omap_rproc *oproc = rproc->priv;
>>  	int ret = 0;
>>  
>>  	mutex_lock(&rproc->lock);
>> @@ -655,13 +755,25 @@ static int __maybe_unused omap_rproc_suspend(struct device *dev)
>>  		goto out;
>>  	}
>>  
>> -	ret = _omap_rproc_suspend(rproc);
>> +	ret = _omap_rproc_suspend(rproc, false);
>>  	if (ret) {
>>  		dev_err(dev, "suspend failed %d\n", ret);
>>  		goto out;
>>  	}
>>  
>> +	/*
>> +	 * remoteproc is running at the time of system suspend, so remember
>> +	 * it so as to wake it up during system resume
>> +	 */
>> +	oproc->need_resume = 1;
> 
> Please use 'true' to be consistent with the type and omap_rproc_resume().
> 
>>  	rproc->state = RPROC_SUSPENDED;
>> +
>> +	/*
>> +	 * update the runtime pm status to be suspended, without decrementing
>> +	 * the device usage count
>> +	 */
>> +	pm_runtime_disable(dev);
>> +	pm_runtime_set_suspended(dev);
>>  out:
>>  	mutex_unlock(&rproc->lock);
>>  	return ret;
>> @@ -671,6 +783,7 @@ static int __maybe_unused omap_rproc_resume(struct device *dev)
>>  {
>>  	struct platform_device *pdev = to_platform_device(dev);
>>  	struct rproc *rproc = platform_get_drvdata(pdev);
>> +	struct omap_rproc *oproc = rproc->priv;
>>  	int ret = 0;
>>  
>>  	mutex_lock(&rproc->lock);
>> @@ -682,17 +795,91 @@ static int __maybe_unused omap_rproc_resume(struct device *dev)
>>  		goto out;
>>  	}
>>  
>> -	ret = _omap_rproc_resume(rproc);
>> +	/*
>> +	 * remoteproc was auto-suspended at the time of system suspend,
>> +	 * so no need to wake-up the processor (leave it in suspended
>> +	 * state, will be woken up during a subsequent runtime_resume)
>> +	 */
>> +	if (!oproc->need_resume)
>> +		goto out;
>> +
>> +	ret = _omap_rproc_resume(rproc, false);
>>  	if (ret) {
>>  		dev_err(dev, "resume failed %d\n", ret);
>>  		goto out;
>>  	}
>> +	oproc->need_resume = false;
>>  
>>  	rproc->state = RPROC_RUNNING;
>> +
>> +	/*
>> +	 * update the runtime pm status to be active, without incrementing
>> +	 * the device usage count
>> +	 */
>> +	pm_runtime_set_active(dev);
>> +	pm_runtime_enable(dev);
>> +	pm_runtime_mark_last_busy(dev);
>>  out:
>>  	mutex_unlock(&rproc->lock);
>>  	return ret;
>>  }
>> +
>> +static int omap_rproc_runtime_suspend(struct device *dev)
>> +{
>> +	struct rproc *rproc = dev_get_drvdata(dev);
>> +	struct omap_rproc *oproc = rproc->priv;
>> +	int ret;
>> +
>> +	if (rproc->state == RPROC_CRASHED) {
>> +		dev_dbg(dev, "rproc cannot be runtime suspended when crashed!\n");
>> +		return -EBUSY;
>> +	}
>> +
>> +	if (WARN_ON(rproc->state != RPROC_RUNNING)) {
>> +		dev_err(dev, "rproc cannot be runtime suspended when not running!\n");
>> +		return -EBUSY;
>> +	}
>> +
>> +	/*
>> +	 * do not even attempt suspend if the remote processor is not
>> +	 * idled for runtime auto-suspend
>> +	 */
>> +	if (!_is_rproc_in_standby(oproc)) {
>> +		ret = -EBUSY;
>> +		goto abort;
>> +	}
>> +
>> +	ret = _omap_rproc_suspend(rproc, true);
>> +	if (ret)
>> +		goto abort;
>> +
>> +	rproc->state = RPROC_SUSPENDED;
>> +	return 0;
>> +
>> +abort:
>> +	pm_runtime_mark_last_busy(dev);
>> +	return ret;
>> +}
>> +
>> +static int omap_rproc_runtime_resume(struct device *dev)
>> +{
>> +	struct rproc *rproc = dev_get_drvdata(dev);
>> +	int ret;
>> +
>> +	if (WARN_ON(rproc->state != RPROC_SUSPENDED)) {
>> +		dev_err(dev, "rproc cannot be runtime resumed if not suspended!\n");
>> +		return -EBUSY;
>> +	}
>> +
>> +	ret = _omap_rproc_resume(rproc, true);
>> +	if (ret) {
>> +		dev_err(dev, "runtime resume failed %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	rproc->state = RPROC_RUNNING;
>> +	return 0;
>> +}
>>  #endif /* CONFIG_PM */
>>  
>>  static const char * const ipu_mem_names[] = {
>> @@ -778,6 +965,20 @@ static const struct of_device_id omap_rproc_of_match[] = {
>>  };
>>  MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
>>  
>> +static int omap_rproc_get_autosuspend_delay(struct platform_device *pdev)
>> +{
>> +	const struct omap_rproc_dev_data *data;
>> +	int delay;
>> +
>> +	data = of_device_get_match_data(&pdev->dev);
>> +	if (!data)
>> +		return -ENODEV;
> 
> This check is done in omap_rproc_of_get_internal_memories() and
> omap_rproc_get_boot_data().  I think it would be best to do it once at the top
> of the probe() function and be done with it.
> 
> That being said and as noted in a previous comment, I would push all tuneables
> to the DT.  If the property is missing then things default to
> DEFAULT_AUTOSUSPEND_DELAY.
> 
>> +
>> +	delay = data->autosuspend_delay;
>> +
>> +	return (delay > 0) ? delay : DEFAULT_AUTOSUSPEND_DELAY;
>> +}
>> +
>>  static const char *omap_rproc_get_firmware(struct platform_device *pdev)
>>  {
>>  	const char *fw_name;
>> @@ -953,6 +1154,11 @@ static int omap_rproc_probe(struct platform_device *pdev)
>>  	}
>>  
>>  	init_completion(&oproc->pm_comp);
>> +	oproc->autosuspend_delay = omap_rproc_get_autosuspend_delay(pdev);
>> +	if (oproc->autosuspend_delay < 0) {
>> +		ret = oproc->autosuspend_delay;
>> +		goto free_rproc;
>> +	}
>>  
>>  	oproc->fck = devm_clk_get(&pdev->dev, 0);
>>  	if (IS_ERR(oproc->fck)) {
>> @@ -994,6 +1200,8 @@ static int omap_rproc_remove(struct platform_device *pdev)
>>  
>>  static const struct dev_pm_ops omap_rproc_pm_ops = {
>>  	SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
>> +	SET_RUNTIME_PM_OPS(omap_rproc_runtime_suspend,
>> +			   omap_rproc_runtime_resume, NULL)
>>  };
>>  
>>  static struct platform_driver omap_rproc_driver = {
>> -- 
>> 2.17.1
>>
>> --
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 01/15] dt-bindings: remoteproc: Add OMAP remoteproc bindings
  2019-12-13 12:55 ` [PATCHv3 01/15] dt-bindings: remoteproc: Add OMAP remoteproc bindings Tero Kristo
@ 2019-12-20  3:38   ` Suman Anna
  0 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2019-12-20  3:38 UTC (permalink / raw)
  To: Tero Kristo, bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap

On 12/13/19 6:55 AM, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
> 
> Add the device tree bindings document for the IPU and DSP
> remote processor devices on OMAP4+ SoCs.
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> [t-kristo@ti.com: converted to schema]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  .../remoteproc/ti,omap-remoteproc.yaml        | 315 ++++++++++++++++++
>  1 file changed, 315 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
> new file mode 100644
> index 000000000000..c87dda0a6559
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
> @@ -0,0 +1,315 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/ti,omap-remoteproc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: OMAP4+ Remoteproc Devices
> +
> +maintainers:
> +  - Suman Anna <s-anna@ti.com>
> +
> +description:
> +  The OMAP family of SoCs usually have one or more slave processor sub-systems
> +  that are used to offload some of the processor-intensive tasks, or to manage
> +  other hardware accelerators, for achieving various system level goals.
> +
> +  The processor cores in the sub-system are usually behind an IOMMU, and may
> +  contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2
> +  caches, an Interrupt Controller, a Cache Controller etc.
> +
> +  The OMAP SoCs usually have a DSP processor sub-system and/or an IPU processor
> +  sub-system. The DSP processor sub-system can contain any of the TI's C64x,
> +  C66x or C67x family of DSP cores as the main execution unit. The IPU processor
> +  sub-system usually contains either a Dual-Core Cortex-M3 or Dual-Core
> +  Cortex-M4 processors.
> +
> +  Each remote processor sub-system is represented as a single DT node. Each node
> +  has a number of required or optional properties that enable the OS running on
> +  the host processor (MPU) to perform the device management of the remote
> +  processor and to communicate with the remote processor. The various properties
> +  can be classified as constant or variable. The constant properties are
> +  dictated by the SoC and does not change from one board to another having the
> +  same SoC. Examples of constant properties include 'iommus', 'reg'. The
> +  variable properties are dictated by the system integration aspects such as
> +  memory on the board, or configuration used within the corresponding firmware
> +  image. Examples of variable properties include 'mboxes', 'memory-region',
> +  'timers', 'watchdog-timers' etc.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - ti,omap4-dsp
> +      - ti,omap5-dsp
> +      - ti,dra7-dsp
> +      - ti,omap4-ipu
> +      - ti,omap5-ipu
> +      - ti,dra7-ipu
> +
> +  iommus:
> +    minItems: 1
> +    maxItems: 2
> +    description: |
> +      phandles to OMAP IOMMU nodes, that need to be programmed
> +      for this remote processor to access any external RAM memory or
> +      other peripheral device address spaces. This property usually
> +      has only a single phandle. Multiple phandles are used only in
> +      cases where the sub-system has different ports for different
> +      sub-modules within the processor sub-system (eg: DRA7 DSPs),
> +      and need the same programming in both the MMUs.
> +
> +  mboxes:
> +    minItems: 1
> +    maxItems: 2
> +    description: |
> +      OMAP Mailbox specifier denoting the sub-mailbox, to be used for
> +      communication with the remote processor. The specifier format is
> +      as per the bindings,
> +      Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
> +      This property should match with the sub-mailbox node used in
> +      the firmware image.
> +
> +  clocks:
> +    description: |
> +      Main functional clock for the remote processor
> +
> +  resets:
> +    description: |
> +      Reset handles for the remote processor
> +
> +  memory-region:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: |
> +      phandle to the reserved memory node to be associated
> +      with the remoteproc device. The reserved memory node
> +      can be a CMA memory node, and should be defined as
> +      per the bindings,
> +      Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +
> +  firmware-name:
> +    description: |
> +      Default name of the firmware to load to the remote processor.
> +
> +# Optional properties:
> +# --------------------
> +# Some of these properties are mandatory on some SoCs, and some are optional
> +# depending on the configuration of the firmware image to be executed on the
> +# remote processor. The conditions are mentioned for each property.
> +#
> +# The following are the optional properties:
> +
> +  reg:
> +    description: |
> +      Address space for any remoteproc memories present on
> +      the SoC. Should contain an entry for each value in
> +      'reg-names'. These are mandatory for all DSP and IPU
> +      processors that have them (OMAP4/OMAP5 DSPs do not have
> +      any RAMs)
> +
> +  reg-names:
> +    description: |
> +      Required names for each of the address spaces defined in
> +      the 'reg' property. Should contain a string from among
> +      the following names, each representing the corresponding
> +      internal RAM memory region.
> +    minItems: 1
> +    maxItems: 3
> +    items:
> +      - const: l2ram
> +      - const: l1pram
> +      - const: l1dram
> +
> +  ti,bootreg:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description: |
> +      Should be a pair of the phandle to the System Control
> +      Configuration region that contains the boot address
> +      register, and the register offset of the boot address
> +      register within the System Control module. This property
> +      is required for all the DSP instances on OMAP4, OMAP5
> +      and DRA7xx SoCs.
> +
> +  ti,timers:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description: |
> +      One or more phandles to OMAP DMTimer nodes, that serve
> +      as System/Tick timers for the OS running on the remote
> +      processors. This will usually be a single timer if the
> +      processor sub-system is running in SMP mode, or one per
> +      core in the processor sub-system. This can also be used
> +      to reserve specific timers to be dedicated to the
> +      remote processors.
> +
> +      This property is mandatory on remote processors requiring
> +      external tick wakeup, and to support Power Management
> +      features. The timers to be used should match with the
> +      timers used in the firmware image.
> +
> +  ti,watchdog-timers:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description: |
> +      One or more phandles to OMAP DMTimer nodes, used to
> +      serve as Watchdog timers for the processor cores. This
> +      will usually be one per executing processor core, even
> +      if the processor sub-system is running a SMP OS.
> +
> +      The timers to be used should match with the watchdog
> +      timers used in the firmware image.
> +
> +if:
> +  properties:
> +    compatible:
> +      enum:
> +        - ti,dra7-dsp
> +then:
> +  properties:
> +    reg:
> +      minItems: 3
> +      maxItems: 3
> +    ti,bootreg:
> +      minItems: 1
> +      maxItems: 1
> +
> +else:
> +  if:
> +    properties:
> +      compatible:
> +        enum:
> +          - ti,omap4-ipu
> +          - ti,omap5-ipu
> +          - ti,dra7-ipu
> +  then:
> +    properties:
> +      reg:
> +        minItems: 1
> +        maxItems: 1
> +
> +  else:
> +    properties:
> +      reg:
> +        maxItems: 0
> +      ti,bootreg:
> +        minItems: 1
> +        maxItems: 1
> +
> +required:
> +  - compatible
> +  - iommus
> +  - mboxes
> +  - memory-region
> +  - clocks
> +  - resets
> +  - firmware-name
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +
> +    //Example 1: OMAP4 DSP
> +
> +    /* DSP Reserved Memory node */
> +    #include <dt-bindings/clock/omap4.h>
> +    reserved-memory {
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +
> +        dsp_memory_region: dsp-memory@98000000 {
> +            compatible = "shared-dma-pool";
> +            reg = <0x98000000 0x800000>;
> +            reusable;
> +        };
> +    };
> +
> +    /* DSP node */
> +    ocp {
> +        dsp: dsp {
> +            compatible = "ti,omap4-dsp";
> +            ti,bootreg = <&scm_conf 0x304>;
> +            iommus = <&mmu_dsp>;
> +            mboxes = <&mailbox &mbox_dsp>;
> +            memory-region = <&dsp_memory_region>;
> +            ti,timers = <&timer5>;
> +            ti,watchdog-timers = <&timer6>;
> +            clocks = <&tesla_clkctrl OMAP4_DSP_CLKCTRL 0>;
> +            resets = <&prm_tesla 0>, <&prm_tesla 1>;
> +            firmware-name = "omap4-dsp-fw.xe64T";
> +        };
> +    };
> +
> +  - |+
> +
> +    //Example 2: OMAP5 IPU
> +
> +    /* IPU Reserved Memory node */
> +    #include <dt-bindings/clock/omap5.h>
> +    reserved-memory {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +
> +        ipu_memory_region: ipu-memory@95800000 {
> +            compatible = "shared-dma-pool";
> +            reg = <0 0x95800000 0 0x3800000>;
> +            reusable;
> +        };
> +    };
> +
> +    /* IPU node */
> +    ocp {
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +
> +        ipu: ipu@55020000 {
> +            compatible = "ti,omap5-ipu";
> +            reg = <0x55020000 0x10000>;
> +            reg-names = "l2ram";
> +            iommus = <&mmu_ipu>;
> +            mboxes = <&mailbox &mbox_ipu>;
> +            memory-region = <&ipu_memory_region>;
> +            ti,timers = <&timer3>, <&timer4>;
> +            ti,watchdog-timers = <&timer9>, <&timer11>;
> +            clocks = <&ipu_clkctrl OMAP5_MMU_IPU_CLKCTRL 0>;
> +            resets = <&prm_core 2>;
> +            firmware-name = "omap5-ipu-fw.xem";

Minor typo here, compared to the actual name we use.

regards
Suman

> +        };
> +    };
> +
> +  - |+
> +
> +    //Example 3: DRA7xx/AM57xx DSP
> +
> +    /* DSP1 Reserved Memory node */
> +    #include <dt-bindings/clock/dra7.h>
> +    reserved-memory {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +
> +        dsp1_memory_region: dsp1-memory@99000000 {
> +            compatible = "shared-dma-pool";
> +            reg = <0x0 0x99000000 0x0 0x4000000>;
> +            reusable;
> +        };
> +    };
> +
> +    /* DSP1 node */
> +    ocp {
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +
> +        dsp1: dsp@40800000 {
> +            compatible = "ti,dra7-dsp";
> +            reg = <0x40800000 0x48000>,
> +                  <0x40e00000 0x8000>,
> +                  <0x40f00000 0x8000>;
> +            reg-names = "l2ram", "l1pram", "l1dram";
> +            ti,bootreg = <&scm_conf 0x55c>;
> +            iommus = <&mmu0_dsp1>, <&mmu1_dsp1>;
> +            mboxes = <&mailbox5 &mbox_dsp1_ipc3x>;
> +            memory-region = <&dsp1_memory_region>;
> +            ti,timers = <&timer5>;
> +            ti,watchdog-timers = <&timer10>;
> +            resets = <&prm_dsp1 0>;
> +            clocks = <&dsp1_clkctrl DRA7_DSP1_MMU0_DSP1_CLKCTRL 0>;
> +            firmware-name = "dra7-dsp1-fw.xe66";
> +        };
> +    };
> 


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 02/15] remoteproc/omap: Add device tree support
  2019-12-20  2:08       ` Suman Anna
@ 2019-12-20  9:36         ` Tero Kristo
  2019-12-20 18:17           ` Suman Anna
  0 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-20  9:36 UTC (permalink / raw)
  To: Suman Anna, Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Tony Lindgren

On 20/12/2019 04:08, Suman Anna wrote:
> Hi Tero, Mathieu,
> 
> On 12/19/19 5:54 AM, Tero Kristo wrote:
>> On 18/12/2019 01:01, Mathieu Poirier wrote:
>>> Hi Tero,
>>>
>>> On Fri, Dec 13, 2019 at 02:55:24PM +0200, Tero Kristo wrote:
>>>> From: Suman Anna <s-anna@ti.com>
>>>>
>>>> OMAP4+ SoCs support device tree boot only. The OMAP remoteproc
>>>> driver is enhanced to support remoteproc devices created through
>>>> Device Tree, support for legacy platform devices has been
>>>> deprecated. The current DT support handles the IPU and DSP
>>>> processor subsystems on OMAP4 and OMAP5 SoCs.
>>>>
>>>> The OMAP remoteproc driver relies on the ti-sysc, reset, and
>>>> syscon layers for performing clock, reset and boot vector
>>>> management (DSP remoteprocs only) of the devices, but some of
>>>> these are limited only to the machine-specific layers
>>>> in arch/arm. The dependency against control module API for boot
>>>> vector management of the DSP remoteprocs has now been removed
>>>> with added logic to parse the boot register from the DT node
>>>> and program it appropriately directly within the driver.
>>>>
>>>> The OMAP remoteproc driver expects the firmware names to be
>>>> provided via device tree entries (firmware-name.) These are used
>>>> to load the proper firmware during boot of the remote processor.
>>>>
>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>> [t-kristo@ti.com: converted to use ti-sysc framework]
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>>    drivers/remoteproc/omap_remoteproc.c | 191 +++++++++++++++++++++++----
>>>>    1 file changed, 168 insertions(+), 23 deletions(-)
>>>>
>>>> diff --git a/drivers/remoteproc/omap_remoteproc.c
>>>> b/drivers/remoteproc/omap_remoteproc.c
>>>> index 6398194075aa..558634624590 100644
>>>> --- a/drivers/remoteproc/omap_remoteproc.c
>>>> +++ b/drivers/remoteproc/omap_remoteproc.c
>>>> @@ -2,7 +2,7 @@
>>>>    /*
>>>>     * OMAP Remote Processor driver
>>>>     *
>>>> - * Copyright (C) 2011 Texas Instruments, Inc.
>>>> + * Copyright (C) 2011-2019 Texas Instruments Incorporated -
>>>> http://www.ti.com/
>>>>     * Copyright (C) 2011 Google, Inc.
>>>>     *
>>>>     * Ohad Ben-Cohen <ohad@wizery.com>
>>>> @@ -16,27 +16,53 @@
>>>>    #include <linux/kernel.h>
>>>>    #include <linux/module.h>
>>>>    #include <linux/err.h>
>>>> +#include <linux/of_device.h>
>>>>    #include <linux/platform_device.h>
>>>>    #include <linux/dma-mapping.h>
>>>>    #include <linux/remoteproc.h>
>>>>    #include <linux/mailbox_client.h>
>>>>    #include <linux/omap-mailbox.h>
>>>> -
>>>> -#include <linux/platform_data/remoteproc-omap.h>
>>>> +#include <linux/regmap.h>
>>>> +#include <linux/mfd/syscon.h>
>>>> +#include <linux/reset.h>
>>>>      #include "omap_remoteproc.h"
>>>>    #include "remoteproc_internal.h"
>>>>    +/**
>>>> + * struct omap_rproc_boot_data - boot data structure for the DSP
>>>> omap rprocs
>>>> + * @syscon: regmap handle for the system control configuration module
>>>> + * @boot_reg: boot register offset within the @syscon regmap
>>>> + */
>>>> +struct omap_rproc_boot_data {
>>>> +    struct regmap *syscon;
>>>> +    unsigned int boot_reg;
>>>> +};
>>>> +
>>>>    /**
>>>>     * struct omap_rproc - omap remote processor state
>>>>     * @mbox: mailbox channel handle
>>>>     * @client: mailbox client to request the mailbox channel
>>>> + * @boot_data: boot data structure for setting processor boot address
>>>>     * @rproc: rproc handle
>>>> + * @reset: reset handle
>>>>     */
>>>>    struct omap_rproc {
>>>>        struct mbox_chan *mbox;
>>>>        struct mbox_client client;
>>>> +    struct omap_rproc_boot_data *boot_data;
>>>>        struct rproc *rproc;
>>>> +    struct reset_control *reset;
>>>> +};
>>>> +
>>>> +/**
>>>> + * struct omap_rproc_dev_data - device data for the omap remote
>>>> processor
>>>> + * @device_name: device name of the remote processor
>>>> + * @has_bootreg: true if this remote processor has boot register
>>>> + */
>>>> +struct omap_rproc_dev_data {
>>>> +    const char *device_name;
>>>> +    bool has_bootreg;
>>>>    };
>>>>      /**
>>>> @@ -92,6 +118,21 @@ static void omap_rproc_kick(struct rproc *rproc,
>>>> int vqid)
>>>>                ret);
>>>>    }
>>>>    +/**
>>>> + * omap_rproc_write_dsp_boot_addr - set boot address for a DSP
>>>> remote processor
>>>> + * @rproc: handle of a remote processor
>>>> + *
>>>> + * Set boot address for a supported DSP remote processor.
>>>> + */
>>>> +static void omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
>>>> +{
>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>> +    struct omap_rproc_boot_data *bdata = oproc->boot_data;
>>>> +    u32 offset = bdata->boot_reg;
>>>> +
>>>> +    regmap_write(bdata->syscon, offset, rproc->bootaddr);
>>>> +}
>>>> +
>>>>    /*
>>>>     * Power up the remote processor.
>>>>     *
>>>> @@ -103,13 +144,11 @@ static int omap_rproc_start(struct rproc *rproc)
>>>>    {
>>>>        struct omap_rproc *oproc = rproc->priv;
>>>>        struct device *dev = rproc->dev.parent;
>>>> -    struct platform_device *pdev = to_platform_device(dev);
>>>> -    struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>>>>        int ret;
>>>>        struct mbox_client *client = &oproc->client;
>>>>    -    if (pdata->set_bootaddr)
>>>> -        pdata->set_bootaddr(rproc->bootaddr);
>>>> +    if (oproc->boot_data)
>>>> +        omap_rproc_write_dsp_boot_addr(rproc);
>>>>          client->dev = dev;
>>>>        client->tx_done = NULL;
>>>> @@ -117,7 +156,7 @@ static int omap_rproc_start(struct rproc *rproc)
>>>>        client->tx_block = false;
>>>>        client->knows_txdone = false;
>>>>    -    oproc->mbox = omap_mbox_request_channel(client,
>>>> pdata->mbox_name);
>>>> +    oproc->mbox = mbox_request_channel(client, 0);
>>>>        if (IS_ERR(oproc->mbox)) {
>>>>            ret = -EBUSY;
>>>>            dev_err(dev, "mbox_request_channel failed: %ld\n",
>>>> @@ -138,11 +177,7 @@ static int omap_rproc_start(struct rproc *rproc)
>>>>            goto put_mbox;
>>>>        }
>>>>    -    ret = pdata->device_enable(pdev);
>>>> -    if (ret) {
>>>> -        dev_err(dev, "omap_device_enable failed: %d\n", ret);
>>>> -        goto put_mbox;
>>>> -    }
>>>> +    reset_control_deassert(oproc->reset);
>>>>          return 0;
>>>>    @@ -154,15 +189,9 @@ static int omap_rproc_start(struct rproc *rproc)
>>>>    /* power off the remote processor */
>>>>    static int omap_rproc_stop(struct rproc *rproc)
>>>>    {
>>>> -    struct device *dev = rproc->dev.parent;
>>>> -    struct platform_device *pdev = to_platform_device(dev);
>>>> -    struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>>>>        struct omap_rproc *oproc = rproc->priv;
>>>> -    int ret;
>>>>    -    ret = pdata->device_shutdown(pdev);
>>>> -    if (ret)
>>>> -        return ret;
>>>> +    reset_control_assert(oproc->reset);
> 
> Any reasons for dropping the checks for the return status and wherever
> you replaced the pdata callbacks with the desired reset API?

Ok, let me try to add the checks back.

> 
>>>>          mbox_free_channel(oproc->mbox);
>>>>    @@ -175,12 +204,122 @@ static const struct rproc_ops omap_rproc_ops
>>>> = {
>>>>        .kick        = omap_rproc_kick,
>>>>    };
>>>>    +static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>>>> +    .device_name    = "dsp",
>>>> +    .has_bootreg    = true,
>>>> +};
>>>> +
>>>> +static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
>>>> +    .device_name    = "ipu",
>>>> +};
>>>> +
>>>> +static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
>>>> +    .device_name    = "dsp",
>>>> +    .has_bootreg    = true,
>>>> +};
>>>> +
>>>> +static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
>>>> +    .device_name    = "ipu",
>>>> +};
>>>> +
>>>> +static const struct of_device_id omap_rproc_of_match[] = {
>>>> +    {
>>>> +        .compatible     = "ti,omap4-dsp",
>>>> +        .data           = &omap4_dsp_dev_data,
>>>> +    },
>>>> +    {
>>>> +        .compatible     = "ti,omap4-ipu",
>>>> +        .data           = &omap4_ipu_dev_data,
>>>> +    },
>>>> +    {
>>>> +        .compatible     = "ti,omap5-dsp",
>>>> +        .data           = &omap5_dsp_dev_data,
>>>> +    },
>>>> +    {
>>>> +        .compatible     = "ti,omap5-ipu",
>>>> +        .data           = &omap5_ipu_dev_data,
>>>> +    },
>>>> +    {
>>>> +        /* end */
>>>> +    },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
>>>> +
>>>> +static const char *omap_rproc_get_firmware(struct platform_device
>>>> *pdev)
>>>> +{
>>>> +    const char *fw_name;
>>>> +    int ret;
>>>> +
>>>> +    ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
>>>> +                      &fw_name);
>>>> +    if (ret)
>>>> +        return ERR_PTR(ret);
>>>> +
>>>> +    return fw_name;
>>>> +}
>>>> +
>>>> +static int omap_rproc_get_boot_data(struct platform_device *pdev,
>>>> +                    struct rproc *rproc)
>>>> +{
>>>> +    struct device_node *np = pdev->dev.of_node;
>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>> +    const struct omap_rproc_dev_data *data;
>>>> +    int ret;
>>>> +
>>>> +    data = of_device_get_match_data(&pdev->dev);
>>>> +    if (!data)
>>>> +        return -ENODEV;
>>>> +
>>>> +    if (!data->has_bootreg)
>>>> +        return 0;
>>>> +
>>>> +    oproc->boot_data = devm_kzalloc(&pdev->dev,
>>>> sizeof(*oproc->boot_data),
>>>> +                    GFP_KERNEL);
>>>> +    if (!oproc->boot_data)
>>>> +        return -ENOMEM;
>>>> +
>>>> +    if (!of_property_read_bool(np, "ti,bootreg")) {
>>>> +        dev_err(&pdev->dev, "ti,bootreg property is missing\n");
>>>> +        return -EINVAL;
>>>> +    }
>>>> +
>>>> +    oproc->boot_data->syscon =
>>>> +            syscon_regmap_lookup_by_phandle(np, "ti,bootreg");
>>>> +    if (IS_ERR(oproc->boot_data->syscon)) {
>>>> +        ret = PTR_ERR(oproc->boot_data->syscon);
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    if (of_property_read_u32_index(np, "ti,bootreg", 1,
>>>> +                       &oproc->boot_data->boot_reg)) {
>>>> +        dev_err(&pdev->dev, "couldn't get the boot register\n");
>>>> +        return -EINVAL;
>>>> +    }
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>>    static int omap_rproc_probe(struct platform_device *pdev)
>>>>    {
>>>> -    struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>>>> +    struct device_node *np = pdev->dev.of_node;
>>>>        struct omap_rproc *oproc;
>>>>        struct rproc *rproc;
>>>> +    const char *firmware;
>>>>        int ret;
>>>> +    struct reset_control *reset;
>>>> +
>>>> +    if (!np) {
>>>> +        dev_err(&pdev->dev, "only DT-based devices are supported\n");
>>>> +        return -ENODEV;
>>>> +    }
>>>> +
>>>> +    reset =
>>>> devm_reset_control_array_get_optional_exclusive(&pdev->dev);
>>>> +    if (IS_ERR(reset))
>>>> +        return PTR_ERR(reset);
>>>
>>> Definition of a reset is listed as "required" in the bindings but here
>>> it is
>>> optional.  If this is really what you want then adding a comment to
>>> exlain your
>>> choice is probably a good idea.
>>
>> Right, I think I updated the binding to require this but forgot to
>> update the driver for this part. Will fix this.
>>
>> -Tero
>>
>>>
>>>> +
>>>> +    firmware = omap_rproc_get_firmware(pdev);
>>>> +    if (IS_ERR(firmware))
>>>> +        return PTR_ERR(firmware);
>>>>          ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
>>>>        if (ret) {
>>>> @@ -188,16 +327,21 @@ static int omap_rproc_probe(struct
>>>> platform_device *pdev)
>>>>            return ret;
>>>>        }
>>>>    -    rproc = rproc_alloc(&pdev->dev, pdata->name, &omap_rproc_ops,
>>>> -                pdata->firmware, sizeof(*oproc));
>>>> +    rproc = rproc_alloc(&pdev->dev, dev_name(&pdev->dev),
>>>> &omap_rproc_ops,
>>>> +                firmware, sizeof(*oproc));
>>>>        if (!rproc)
>>>>            return -ENOMEM;
>>>>          oproc = rproc->priv;
>>>>        oproc->rproc = rproc;
>>>> +    oproc->reset = reset;
>>>>        /* All existing OMAP IPU and DSP processors have an MMU */
>>>>        rproc->has_iommu = true;
>>>>    +    ret = omap_rproc_get_boot_data(pdev, rproc);
>>>> +    if (ret)
>>>> +        goto free_rproc;
>>>> +
>>>>        platform_set_drvdata(pdev, rproc);
>>>>          ret = rproc_add(rproc);
>>>> @@ -226,6 +370,7 @@ static struct platform_driver omap_rproc_driver = {
>>>>        .remove = omap_rproc_remove,
>>>>        .driver = {
>>>>            .name = "omap-rproc",
>>>> +        .of_match_table = omap_rproc_of_match,
>>>
>>>                   .of_match_table = of_match_ptr(omap_rproc_of_match),
> 
> I had dropped this sometime back intentionally as all our platforms are
> DT-only.

Hmm, dropped what?

-Tero

> 
> regards
> Suman
> 
>>>
>>> Thanks,
>>> Mathieu
>>>
>>>>        },
>>>>    };
>>>>    --
>>>> 2.17.1
>>>>
>>>> -- 
>>
>> -- 
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 08/15] remoteproc/omap: Remove the unused fields from platform data
  2019-12-20  2:44   ` Suman Anna
@ 2019-12-20  9:48     ` Tero Kristo
  0 siblings, 0 replies; 50+ messages in thread
From: Tero Kristo @ 2019-12-20  9:48 UTC (permalink / raw)
  To: Suman Anna, bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap

On 20/12/2019 04:44, Suman Anna wrote:
> Hi Tero,
> 
> On 12/13/19 6:55 AM, Tero Kristo wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> The following fields: .name, .oh_name, .oh_name_opt, .mbox_name,
>> .firmware, .ops and .set_bootaddr, are removed from the platform data,
>> as these are no longer needed after the addition of DT support to the
>> OMAP remoteproc driver.
>>
>> The .name field was used to give a name to the remoteproc, and this
>> is replaced with the device name. The .ops field was never used by
>> the OMAP remoteproc driver. The .mbox_name was used to define the
>> sub-mailbox node used for communication with the remote processor,
>> and is retrieved using the 'mboxes' property in the DT node. The
>> .firmware field is encoded directly in the OMAP remoteproc driver and
>> is retrieved using driver match data. The .set_bootaddr ops was used
>> for using a OMAP Control Module API to configure the boot address for
>> the processor, and is now implemented within the driver using a
>> syscon property.
>>
>> The .oh_name field is used to define the primary hwmod for the processor
>> node, and is represented using the 'ti,hwmods' property in the DT node.
>> The .oh_name_opt field was primarily defined to identify the hwmod for
>> the second cpu in a dual Cortex-M3/M4 IPU processor sub-system. This
>> hwmod entry is no longer defined usually, but rather a single hwmod
>> representing both the processors in the IPU sub-system is defined.
>> A single firmware image (either in SMP-mode or a combined image for
>> non-SMP mode) is used, with both the resets released together always
>> as part of the device management. Any power management and recovery
>> aspects require that both the processors be managed as one entity due
>> to the presence of shared MMU and unicache within the IPU sub-system.
>>
>> The OMAP remoteproc platform data structure is eventually expected
>> to be removed completely once the other dependencies with the
>> mach-omap layer are met.
> 
> This patch was a cleanup patch with DT using hwmod, and some of the
> description is pertinent to that. Now that you have converted to ti,sysc
> & reset with no dependencies against hwmod, the time for removing the
> structure is here. Some of the patch description is no longer correct as
> well since there is no 'ti,hwmods' :)

Hmm right, let me see if the header can be dropped completely.

-Tero

> 
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> ---
>>   include/linux/platform_data/remoteproc-omap.h | 17 +----------------
>>   1 file changed, 1 insertion(+), 16 deletions(-)
>>
>> diff --git a/include/linux/platform_data/remoteproc-omap.h b/include/linux/platform_data/remoteproc-omap.h
>> index 7e3a16097672..6bea01e199fe 100644
>> --- a/include/linux/platform_data/remoteproc-omap.h
>> +++ b/include/linux/platform_data/remoteproc-omap.h
>> @@ -2,38 +2,23 @@
>>   /*
>>    * Remote Processor - omap-specific bits
>>    *
>> - * Copyright (C) 2011 Texas Instruments, Inc.
>> + * Copyright (C) 2011-2018 Texas Instruments Incorporated - http://www.ti.com/
> 
> %s/2018/2019 when you do update the patch.
> 
> regards
> Suman
> 
>>    * Copyright (C) 2011 Google, Inc.
>>    */
>>   
>>   #ifndef _PLAT_REMOTEPROC_H
>>   #define _PLAT_REMOTEPROC_H
>>   
>> -struct rproc_ops;
>>   struct platform_device;
>>   
>>   /*
>>    * struct omap_rproc_pdata - omap remoteproc's platform data
>> - * @name: the remoteproc's name
>> - * @oh_name: omap hwmod device
>> - * @oh_name_opt: optional, secondary omap hwmod device
>> - * @firmware: name of firmware file to load
>> - * @mbox_name: name of omap mailbox device to use with this rproc
>> - * @ops: start/stop rproc handlers
>>    * @device_enable: omap-specific handler for enabling a device
>>    * @device_shutdown: omap-specific handler for shutting down a device
>> - * @set_bootaddr: omap-specific handler for setting the rproc boot address
>>    */
>>   struct omap_rproc_pdata {
>> -	const char *name;
>> -	const char *oh_name;
>> -	const char *oh_name_opt;
>> -	const char *firmware;
>> -	const char *mbox_name;
>> -	const struct rproc_ops *ops;
>>   	int (*device_enable)(struct platform_device *pdev);
>>   	int (*device_shutdown)(struct platform_device *pdev);
>> -	void (*set_bootaddr)(u32);
>>   };
>>   
>>   #if defined(CONFIG_OMAP_REMOTEPROC) || defined(CONFIG_OMAP_REMOTEPROC_MODULE)
>>
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 09/15] remoteproc/omap: Remove the omap_rproc_reserve_cma declaration
  2019-12-20  2:47   ` Suman Anna
@ 2019-12-20  9:49     ` Tero Kristo
  0 siblings, 0 replies; 50+ messages in thread
From: Tero Kristo @ 2019-12-20  9:49 UTC (permalink / raw)
  To: Suman Anna, bjorn.andersson, ohad, linux-remoteproc
  Cc: linux-kernel, mathieu.poirier, linux-omap

On 20/12/2019 04:47, Suman Anna wrote:
> Hi Tero,
> 
> On 12/13/19 6:55 AM, Tero Kristo wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> The omap_rproc_reserve_cma() function is not defined at the moment.
>> This prototype was to be used to define a function to declare a
>> remoteproc device-specific CMA pool.
>>
>> The remoteproc devices will be defined through DT going forward. A
>> device specific CMA pool will be defined under the reserved-memory
>> node, and will be associated with the appropriate remoteproc device
>> node. This function prototype will no longer be needed and has
>> therefore been cleaned up.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> 
> With the structure removed, you can actually drop the file altogether.

Yeah, let me check that out.

-Tero

> 
> regards
> Suman
> 
>> ---
>>   include/linux/platform_data/remoteproc-omap.h | 12 ------------
>>   1 file changed, 12 deletions(-)
>>
>> diff --git a/include/linux/platform_data/remoteproc-omap.h b/include/linux/platform_data/remoteproc-omap.h
>> index 6bea01e199fe..49c78805916f 100644
>> --- a/include/linux/platform_data/remoteproc-omap.h
>> +++ b/include/linux/platform_data/remoteproc-omap.h
>> @@ -21,16 +21,4 @@ struct omap_rproc_pdata {
>>   	int (*device_shutdown)(struct platform_device *pdev);
>>   };
>>   
>> -#if defined(CONFIG_OMAP_REMOTEPROC) || defined(CONFIG_OMAP_REMOTEPROC_MODULE)
>> -
>> -void __init omap_rproc_reserve_cma(void);
>> -
>> -#else
>> -
>> -static inline void __init omap_rproc_reserve_cma(void)
>> -{
>> -}
>> -
>> -#endif
>> -
>>   #endif /* _PLAT_REMOTEPROC_H */
>>
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 12/15] remoteproc/omap: add support for system suspend/resume
  2019-12-20  3:11     ` Suman Anna
@ 2019-12-20 11:04       ` Tero Kristo
  2019-12-20 18:23         ` Suman Anna
  2019-12-20 21:58       ` Mathieu Poirier
  1 sibling, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-20 11:04 UTC (permalink / raw)
  To: Suman Anna, Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-omap

On 20/12/2019 05:11, Suman Anna wrote:
> Hi Mathieu, Tero,
> 
> On 12/19/19 3:46 PM, Mathieu Poirier wrote:
>> On Fri, Dec 13, 2019 at 02:55:34PM +0200, Tero Kristo wrote:
>>> From: Suman Anna <s-anna@ti.com>
>>>
>>> This patch adds the support for system suspend/resume to the
>>> OMAP remoteproc driver so that the OMAP remoteproc devices can
>>> be suspended/resumed during a system suspend/resume. The support
>>> is added through the driver PM .suspend/.resume callbacks, and
>>> requires appropriate support from the OS running on the remote
>>> processors.
>>>
>>> The IPU & DSP remote processors typically have their own private
>>> modules like registers, internal memories, caches etc. The context
>>> of these modules need to be saved and restored properly for a
>>> suspend/resume to work. These are in general not accessible from
>>> the MPU, so the remote processors themselves have to implement
>>> the logic for the context save & restore of these modules.
>>>
>>> The OMAP remoteproc driver initiates a suspend by sending a mailbox
>>> message requesting the remote processor to save its context and
>>> enter into an idle/standby state. The remote processor should
>>> usually stop whatever processing it is doing to switch to a context
>>> save mode. The OMAP remoteproc driver detects the completion of
>>> the context save by checking the module standby status for the
>>> remoteproc device. It also stops any resources used by the remote
>>> processors like the timers. The timers need to be running only
>>> when the processor is active and executing, and need to be stopped
>>> otherwise to allow the timer driver to reach low-power states. The
>>> IOMMUs are automatically suspended by the PM core during the late
>>> suspend stage, after the remoteproc suspend process is completed by
>>> putting the remote processor cores into reset. Thereafter, the Linux
>>> kernel can put the domain into further lower power states as possible.
>>>
>>> The resume sequence undoes the operations performed in the PM suspend
>>> callback, by starting the timers and finally releasing the processors
>>> from reset. This requires that the remote processor side OS be able to
>>> distinguish a power-resume boot from a power-on/cold boot, restore the
>>> context of its private modules saved during the suspend phase, and
>>> resume executing code from where it was suspended. The IOMMUs would
>>> have been resumed by the PM core during early resume, so they are
>>> already enabled by the time remoteproc resume callback gets invoked.
>>>
>>> The remote processors should save their context into System RAM (DDR),
>>> as any internal memories are not guaranteed to retain context as it
>>> depends on the lowest power domain that the remote processor device
>>> is put into. The management of the DDR contents will be managed by
>>> the Linux kernel.
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> [t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> ---
>>>   drivers/remoteproc/omap_remoteproc.c | 179 +++++++++++++++++++++++++++
>>>   drivers/remoteproc/omap_remoteproc.h |  18 ++-
>>>   2 files changed, 195 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>>> index 9c750c2ab29d..0a9b9f7d20da 100644
>>> --- a/drivers/remoteproc/omap_remoteproc.c
>>> +++ b/drivers/remoteproc/omap_remoteproc.c
>>> @@ -16,6 +16,7 @@
>>>   #include <linux/kernel.h>
>>>   #include <linux/module.h>
>>>   #include <linux/err.h>
>>> +#include <linux/io.h>
>>>   #include <linux/of_device.h>
>>>   #include <linux/of_reserved_mem.h>
>>>   #include <linux/platform_device.h>
>>> @@ -23,10 +24,13 @@
>>>   #include <linux/remoteproc.h>
>>>   #include <linux/mailbox_client.h>
>>>   #include <linux/omap-mailbox.h>
>>> +#include <linux/omap-iommu.h>
>>
>> Please move this up by one line.
>>
>>>   #include <linux/regmap.h>
>>>   #include <linux/mfd/syscon.h>
>>>   #include <linux/reset.h>
>>>   #include <clocksource/timer-ti-dm.h>
>>> +#include <linux/clk.h>
>>> +#include <linux/clk/ti.h>
>>
>> Unless there is a dependency with timer-ti-dm.h, these should go just above linux/err.h
> 
> No depencencies, can be reordered.

Will fix these.

> 
>>
>>>   
>>>   #include <linux/platform_data/dmtimer-omap.h>
>>>   
>>> @@ -81,6 +85,9 @@ struct omap_rproc_timer {
>>>    * @timers: timer(s) info used by rproc
>>>    * @rproc: rproc handle
>>>    * @reset: reset handle
>>> + * @pm_comp: completion primitive to sync for suspend response
>>> + * @fck: functional clock for the remoteproc
>>> + * @suspend_acked: state machine flag to store the suspend request ack
>>>    */
>>>   struct omap_rproc {
>>>   	struct mbox_chan *mbox;
>>> @@ -92,6 +99,9 @@ struct omap_rproc {
>>>   	struct omap_rproc_timer *timers;
>>>   	struct rproc *rproc;
>>>   	struct reset_control *reset;
>>> +	struct completion pm_comp;
>>> +	struct clk *fck;
>>> +	bool suspend_acked;
>>>   };
>>>   
>>>   /**
>>> @@ -349,6 +359,11 @@ static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
>>>   	case RP_MBOX_ECHO_REPLY:
>>>   		dev_info(dev, "received echo reply from %s\n", name);
>>>   		break;
>>> +	case RP_MBOX_SUSPEND_ACK:
>>
>> We can't get away with implicit fallthroughs anymore - please add /* Fall through */"

Ok, will do.

>>
>>> +	case RP_MBOX_SUSPEND_CANCEL:
>>> +		oproc->suspend_acked = msg == RP_MBOX_SUSPEND_ACK;
>>> +		complete(&oproc->pm_comp);
>>> +		break;
>>>   	default:
>>>   		if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
>>>   			return;
>>> @@ -529,6 +544,157 @@ static const struct rproc_ops omap_rproc_ops = {
>>>   	.da_to_va	= omap_rproc_da_to_va,
>>>   };
>>>   
>>> +#ifdef CONFIG_PM
>>> +static bool _is_rproc_in_standby(struct omap_rproc *oproc)
>>> +{
>>> +	return ti_clk_is_in_standby(oproc->fck);
>>> +}
>>> +
>>> +/* 1 sec is long enough time to let the remoteproc side suspend the device */
>>> +#define DEF_SUSPEND_TIMEOUT 1000
>>> +static int _omap_rproc_suspend(struct rproc *rproc)
>>> +{
>>> +	struct device *dev = rproc->dev.parent;
>>> +	struct omap_rproc *oproc = rproc->priv;
>>> +	unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
>>> +	unsigned long ta = jiffies + to;
>>> +	int ret;
>>> +
>>> +	reinit_completion(&oproc->pm_comp);
>>> +	oproc->suspend_acked = false;
>>> +	ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_SUSPEND_SYSTEM);
>>> +	if (ret < 0) {
>>> +		dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
>>> +		return ret;
>>> +	}
>>> +
>>> +	ret = wait_for_completion_timeout(&oproc->pm_comp, to);
>>> +	if (!oproc->suspend_acked)
>>> +		return -EBUSY;
>>> +
>>> +	/*
>>> +	 * The remoteproc side is returning the ACK message before saving the
>>> +	 * context, because the context saving is performed within a SYS/BIOS
>>> +	 * function, and it cannot have any inter-dependencies against the IPC
>>> +	 * layer. Also, as the SYS/BIOS needs to preserve properly the processor
>>> +	 * register set, sending this ACK or signalling the completion of the
>>> +	 * context save through a shared memory variable can never be the
>>> +	 * absolute last thing to be executed on the remoteproc side, and the
>>> +	 * MPU cannot use the ACK message as a sync point to put the remoteproc
>>> +	 * into reset. The only way to ensure that the remote processor has
>>> +	 * completed saving the context is to check that the module has reached
>>> +	 * STANDBY state (after saving the context, the SYS/BIOS executes the
>>> +	 * appropriate target-specific WFI instruction causing the module to
>>> +	 * enter STANDBY).
>>> +	 */
>>> +	while (!_is_rproc_in_standby(oproc)) {
>>> +		if (time_after(jiffies, ta))
>>> +			return -ETIME;
>>> +		schedule();
>>> +	}
>>> +
>>> +	reset_control_assert(oproc->reset);
>>> +
>>> +	ret = omap_rproc_disable_timers(rproc, false);
>>> +	if (ret) {
>>> +		dev_err(dev, "disabling timers during suspend failed %d\n",
>>> +			ret);
>>> +		goto enable_device;
>>> +	}
>>> +
>>> +	return 0;
>>> +
>>> +enable_device:
>>> +	reset_control_deassert(oproc->reset);
>>> +	return ret;
>>> +}
>>> +
>>> +static int _omap_rproc_resume(struct rproc *rproc)
>>> +{
>>> +	struct device *dev = rproc->dev.parent;
>>> +	struct omap_rproc *oproc = rproc->priv;
>>> +	int ret;
>>> +
>>> +	/* boot address could be lost after suspend, so restore it */
>>> +	if (oproc->boot_data) {
>>> +		ret = omap_rproc_write_dsp_boot_addr(rproc);
>>> +		if (ret) {
>>> +			dev_err(dev, "boot address restore failed %d\n", ret);
>>> +			goto out;
>>> +		}
>>> +	}
>>> +
>>> +	ret = omap_rproc_enable_timers(rproc, false);
>>> +	if (ret) {
>>> +		dev_err(dev, "enabling timers during resume failed %d\n",
>>> +			ret);
>>
>> The "ret);" fits on the live above.

Ok, will fix.

>>
>>> +		goto out;
>>> +	}
>>> +
>>> +	reset_control_deassert(oproc->reset);
>>> +
>>> +out:
>>> +	return ret;
>>> +}
>>> +
>>> +static int __maybe_unused omap_rproc_suspend(struct device *dev)
>>
>> The "__maybe_unused" can be dropped because this is within the #ifdef CONFIG_PM
>> block.
> 
> These are suspend/resume callbacks, so are actually controlled by
> CONFIG_PM_SLEEP which can be disabled independently from runtime
> suspend, and hence the annotation.

I'll add these two behind CONFIG_PM_SLEEP, in addition to the whole lot 
being behind CONFIG_PM.

> 
>>
>>> +{
>>> +	struct platform_device *pdev = to_platform_device(dev);
>>> +	struct rproc *rproc = platform_get_drvdata(pdev);
>>> +	int ret = 0;
>>> +
>>> +	mutex_lock(&rproc->lock);
>>> +	if (rproc->state == RPROC_OFFLINE)
>>> +		goto out;
>>> +
>>> +	if (rproc->state == RPROC_SUSPENDED)
>>> +		goto out;
>>> +
>>> +	if (rproc->state != RPROC_RUNNING) {
>>> +		ret = -EBUSY;
>>> +		goto out;
>>> +	}
>>> +
>>> +	ret = _omap_rproc_suspend(rproc);
>>> +	if (ret) {
>>> +		dev_err(dev, "suspend failed %d\n", ret);
>>> +		goto out;
>>> +	}
>>> +
>>> +	rproc->state = RPROC_SUSPENDED;
>>> +out:
>>> +	mutex_unlock(&rproc->lock);
>>> +	return ret;
>>> +}
>>> +
>>> +static int __maybe_unused omap_rproc_resume(struct device *dev)
>>
>> Same comment as above.
>>
>>> +{
>>> +	struct platform_device *pdev = to_platform_device(dev);
>>> +	struct rproc *rproc = platform_get_drvdata(pdev);
>>> +	int ret = 0;
>>> +
>>> +	mutex_lock(&rproc->lock);
>>> +	if (rproc->state == RPROC_OFFLINE)
>>> +		goto out;
>>> +
>>> +	if (rproc->state != RPROC_SUSPENDED) {
>>> +		ret = -EBUSY;
>>> +		goto out;
>>> +	}
>>> +
>>> +	ret = _omap_rproc_resume(rproc);
>>> +	if (ret) {
>>> +		dev_err(dev, "resume failed %d\n", ret);
>>> +		goto out;
>>> +	}
>>> +
>>> +	rproc->state = RPROC_RUNNING;
>>> +out:
>>> +	mutex_unlock(&rproc->lock);
>>> +	return ret;
>>> +}
>>> +#endif /* CONFIG_PM */
>>> +
>>>   static const char * const ipu_mem_names[] = {
>>>   	"l2ram", NULL
>>>   };
>>> @@ -786,6 +952,14 @@ static int omap_rproc_probe(struct platform_device *pdev)
>>>   			oproc->num_timers);
>>>   	}
>>>   
>>> +	init_completion(&oproc->pm_comp);
>>> +
>>> +	oproc->fck = devm_clk_get(&pdev->dev, 0);
>>> +	if (IS_ERR(oproc->fck)) {
>>> +		ret = PTR_ERR(oproc->fck);
>>> +		goto free_rproc;
>>> +	}
>>> +
>>
>> oproc->fck is not released if an error occurs in of_reserved_mem_device_init()
>> and rproc_add().
> 
> We are using a devres managed API, so why do we need to release it
> specifically?

Yea I don't think this is needed.

> 
>>
>>>   	ret = of_reserved_mem_device_init(&pdev->dev);
>>>   	if (ret) {
>>>   		dev_err(&pdev->dev, "device does not have specific CMA pool\n");
>>> @@ -818,11 +992,16 @@ static int omap_rproc_remove(struct platform_device *pdev)
>>>   	return 0;
>>>   }
>>>   
>>> +static const struct dev_pm_ops omap_rproc_pm_ops = {
>>> +	SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
>>> +};
>>> +
>>>   static struct platform_driver omap_rproc_driver = {
>>>   	.probe = omap_rproc_probe,
>>>   	.remove = omap_rproc_remove,
>>>   	.driver = {
>>>   		.name = "omap-rproc",
>>> +		.pm = &omap_rproc_pm_ops,
>>>   		.of_match_table = omap_rproc_of_match,
>>>   	},
>>>   };
>>> diff --git a/drivers/remoteproc/omap_remoteproc.h b/drivers/remoteproc/omap_remoteproc.h
>>> index 72f656c93caa..c73383e707c7 100644
>>> --- a/drivers/remoteproc/omap_remoteproc.h
>>> +++ b/drivers/remoteproc/omap_remoteproc.h
>>> @@ -1,7 +1,7 @@
>>>   /*
>>>    * Remote processor messaging
>>>    *
>>> - * Copyright (C) 2011 Texas Instruments, Inc.
>>> + * Copyright (C) 2011-2018 Texas Instruments, Inc.
> 
> %s/2018/2019/

Yep, will fix.

-Tero

> 
> regards
> Suman
> 
>>>    * Copyright (C) 2011 Google, Inc.
>>>    * All rights reserved.
>>>    *
>>> @@ -57,6 +57,16 @@
>>>    * @RP_MBOX_ABORT_REQUEST: a "please crash" request, used for testing the
>>>    * recovery mechanism (to some extent).
>>>    *
>>> + * @RP_MBOX_SUSPEND_AUTO: auto suspend request for the remote processor
>>> + *
>>> + * @RP_MBOX_SUSPEND_SYSTEM: system suspend request for the remote processor
>>> + *
>>> + * @RP_MBOX_SUSPEND_ACK: successful response from remote processor for a
>>> + * suspend request
>>> + *
>>> + * @RP_MBOX_SUSPEND_CANCEL: a cancel suspend response from a remote processor
>>> + * on a suspend request
>>> + *
>>>    * Introduce new message definitions if any here.
>>>    *
>>>    * @RP_MBOX_END_MSG: Indicates end of known/defined messages from remote core
>>> @@ -70,7 +80,11 @@ enum omap_rp_mbox_messages {
>>>   	RP_MBOX_ECHO_REQUEST	= 0xFFFFFF03,
>>>   	RP_MBOX_ECHO_REPLY	= 0xFFFFFF04,
>>>   	RP_MBOX_ABORT_REQUEST	= 0xFFFFFF05,
>>> -	RP_MBOX_END_MSG		= 0xFFFFFF06,
>>> +	RP_MBOX_SUSPEND_AUTO	= 0xFFFFFF10,
>>> +	RP_MBOX_SUSPEND_SYSTEM	= 0xFFFFFF11,
>>> +	RP_MBOX_SUSPEND_ACK	= 0xFFFFFF12,
>>> +	RP_MBOX_SUSPEND_CANCEL	= 0xFFFFFF13,
>>> +	RP_MBOX_END_MSG		= 0xFFFFFF14,
>>>   };
>>>   
>>>   #endif /* _OMAP_RPMSG_H */
>>> -- 
>>> 2.17.1
>>>
>>> --
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume
  2019-12-19 23:43   ` Mathieu Poirier
  2019-12-20  3:24     ` Suman Anna
@ 2019-12-20 11:08     ` Tero Kristo
  1 sibling, 0 replies; 50+ messages in thread
From: Tero Kristo @ 2019-12-20 11:08 UTC (permalink / raw)
  To: Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Suman Anna

On 20/12/2019 01:43, Mathieu Poirier wrote:
> On Fri, Dec 13, 2019 at 02:55:35PM +0200, Tero Kristo wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> This patch enhances the PM support in the OMAP remoteproc driver to
>> support the runtime auto-suspend. A remoteproc may not be required to
>> be running all the time, and typically will need to be active only
>> during certain usecases. As such, to save power, it should be turned
>> off during potential long periods of inactivity between usecases.
>> This suspend and resume of the device is a relatively heavy process
>> in terms of latencies, so a remoteproc should be suspended only after
>> a certain period of prolonged inactivity. The OMAP remoteproc driver
>> leverages the runtime pm framework's auto_suspend feature to accomplish
>> this functionality. This feature is automatically enabled when a remote
>> processor has successfully booted. The 'autosuspend_delay_ms' for each
>> device dictates the inactivity period/time to wait for before
>> suspending the device.
>>
>> The runtime auto-suspend design relies on marking the last busy time
>> on every communication (virtqueue kick) to and from the remote processor.
>> When there has been no activity for 'autosuspend_delay_ms' time, the
>> runtime PM framework invokes the driver's runtime pm suspend callback
>> to suspend the device. The remote processor will be woken up on the
>> initiation of the next communication message through the runtime pm
>> resume callback. The current auto-suspend design also allows a remote
>> processor to deny a auto-suspend attempt, if it wishes to, by sending a
>> NACK response to the initial suspend request message sent to the remote
>> processor as part of the suspend process. The auto-suspend request is
>> also only attempted if the remote processor is idled and in standby at
>> the time of inactivity timer expiry. This choice is made to avoid
>> unnecessary messaging, and the auto-suspend is simply rescheduled to
>> be attempted again after a further lapse of autosuspend_delay_ms.
>>
>> The runtime pm callbacks functionality in this patch reuses most of the
>> core logic from the suspend/resume support code, and make use of an
>> additional auto_suspend flag to differentiate the logic in common code
>> from system suspend. The system suspend/resume sequences are also updated
>> to reflect the proper pm_runtime statuses, and also to really perform a
>> suspend/resume only if the remoteproc has not been auto-suspended at the
>> time of request. The remote processor is left in suspended state on a
>> system resume if it has been auto-suspended before, and will be woken up
>> only when a usecase needs to run. The other significant change in this
>> patch is to reset the remoteproc device's pm_domain so as to avoid
>> conflicts with the ordering sequences in the device pm_domain's runtime
>> callbacks and the reset management and clock management implemented
>> within the runtime callbacks in the driver.
>>
>> The OMAP remoteproc driver currently uses a default value of 10 seconds
>> for all OMAP remoteprocs, and a different value can be chosen either by
>> choosing a positive value for the 'autosuspend_delay' in the device's
>> omap_rproc_fw_data in the driver match data or by updating the
>> 'autosuspend_delay_ms' field at runtime through the sysfs interface.
>>      Eg: To use 25 seconds for IPU2 on DRA7xx,
>>        echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms
>>
>> The runtime suspend feature can also be similarly enabled or disabled by
>> writing 'auto' or 'on' to the device's 'control' power field. The default
>> is enabled.
>>      Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
>>        echo on > /sys/bus/platform/devices/55020000.ipu/power/control
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> [t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>   drivers/remoteproc/omap_remoteproc.c | 220 ++++++++++++++++++++++++++-
>>   1 file changed, 214 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>> index 0a9b9f7d20da..463d6f60947a 100644
>> --- a/drivers/remoteproc/omap_remoteproc.c
>> +++ b/drivers/remoteproc/omap_remoteproc.c
>> @@ -20,6 +20,7 @@
>>   #include <linux/of_device.h>
>>   #include <linux/of_reserved_mem.h>
>>   #include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>>   #include <linux/dma-mapping.h>
>>   #include <linux/remoteproc.h>
>>   #include <linux/mailbox_client.h>
>> @@ -37,6 +38,9 @@
>>   #include "omap_remoteproc.h"
>>   #include "remoteproc_internal.h"
>>   
>> +/* default auto-suspend delay (ms) */
>> +#define DEFAULT_AUTOSUSPEND_DELAY		10000
>> +
>>   /**
>>    * struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
>>    * @syscon: regmap handle for the system control configuration module
>> @@ -83,6 +87,8 @@ struct omap_rproc_timer {
>>    * @num_mems: number of internal memory regions
>>    * @num_timers: number of rproc timer(s)
>>    * @timers: timer(s) info used by rproc
>> + * @autosuspend_delay: auto-suspend delay value to be used for runtime pm
>> + * @need_resume: if true a resume is needed in the system resume callback
>>    * @rproc: rproc handle
>>    * @reset: reset handle
>>    * @pm_comp: completion primitive to sync for suspend response
>> @@ -97,6 +103,8 @@ struct omap_rproc {
>>   	int num_mems;
>>   	int num_timers;
>>   	struct omap_rproc_timer *timers;
>> +	int autosuspend_delay;
>> +	bool need_resume;
>>   	struct rproc *rproc;
>>   	struct reset_control *reset;
>>   	struct completion pm_comp;
>> @@ -111,6 +119,7 @@ struct omap_rproc {
>>    * @boot_reg_shift: bit shift for the boot register mask
>>    * @mem_names: memory names for this remote processor
>>    * @dev_addrs: device addresses corresponding to the memory names
>> + * @autosuspend_delay: custom auto-suspend delay value in milliseconds
>>    */
>>   struct omap_rproc_dev_data {
>>   	const char *device_name;
>> @@ -118,6 +127,7 @@ struct omap_rproc_dev_data {
>>   	int boot_reg_shift;
>>   	const char * const *mem_names;
>>   	const u32 *dev_addrs;
>> +	int autosuspend_delay;
>>   };
>>   
>>   /**
>> @@ -384,11 +394,23 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
>>   	struct device *dev = rproc->dev.parent;
>>   	int ret;
>>   
>> +	/* wake up the rproc before kicking it */
>> +	ret = pm_runtime_get_sync(dev);
>> +	if (WARN_ON(ret < 0)) {
>> +		dev_err(dev, "pm_runtime_get_sync() failed during kick, ret = %d\n",
>> +			ret);
>> +		pm_runtime_put_noidle(dev);
>> +		return;
>> +	}
>> +
>>   	/* send the index of the triggered virtqueue in the mailbox payload */
>>   	ret = mbox_send_message(oproc->mbox, (void *)vqid);
>>   	if (ret < 0)
>>   		dev_err(dev, "failed to send mailbox message, status = %d\n",
>>   			ret);
>> +
>> +	pm_runtime_mark_last_busy(dev);
>> +	pm_runtime_put_autosuspend(dev);
>>   }
>>   
>>   /**
>> @@ -473,6 +495,19 @@ static int omap_rproc_start(struct rproc *rproc)
>>   		goto put_mbox;
>>   	}
>>   
>> +	/*
>> +	 * remote processor is up, so update the runtime pm status and
>> +	 * enable the auto-suspend. The device usage count is incremented
>> +	 * manually for balancing it for auto-suspend
>> +	 */
>> +	pm_runtime_set_active(dev);
>> +	pm_runtime_set_autosuspend_delay(dev, oproc->autosuspend_delay);
>> +	pm_runtime_use_autosuspend(dev);
>> +	pm_runtime_get(dev);
>> +	pm_runtime_enable(dev);
>> +	pm_runtime_mark_last_busy(dev);
>> +	pm_runtime_put_autosuspend(dev);
>> +
>>   	reset_control_deassert(oproc->reset);
>>   
>>   	return 0;
>> @@ -485,9 +520,26 @@ static int omap_rproc_start(struct rproc *rproc)
>>   /* power off the remote processor */
>>   static int omap_rproc_stop(struct rproc *rproc)
>>   {
>> +	struct device *dev = rproc->dev.parent;
>>   	struct omap_rproc *oproc = rproc->priv;
>>   	int ret;
>>   
>> +	/*
>> +	 * cancel any possible scheduled runtime suspend by incrementing
>> +	 * the device usage count, and resuming the device. The remoteproc
>> +	 * also needs to be woken up if suspended, to avoid the remoteproc
>> +	 * OS to continue to remember any context that it has saved, and
>> +	 * avoid potential issues in misindentifying a subsequent device
>> +	 * reboot as a power restore boot
>> +	 */
>> +	ret = pm_runtime_get_sync(dev);
>> +	if (ret < 0) {
>> +		pm_runtime_put_noidle(dev);
>> +		return ret;
>> +	}
>> +
>> +	pm_runtime_put_sync(dev);
>> +
>>   	reset_control_assert(oproc->reset);
>>   
>>   	ret = omap_rproc_disable_timers(rproc, true);
>> @@ -496,6 +548,15 @@ static int omap_rproc_stop(struct rproc *rproc)
>>   
>>   	mbox_free_channel(oproc->mbox);
>>   
>> +	/*
>> +	 * update the runtime pm states and status now that the remoteproc
>> +	 * has stopped
>> +	 */
>> +	pm_runtime_disable(dev);
>> +	pm_runtime_dont_use_autosuspend(dev);
>> +	pm_runtime_put_noidle(dev);
>> +	pm_runtime_set_suspended(dev);
>> +
>>   	return 0;
>>   }
>>   
>> @@ -552,17 +613,19 @@ static bool _is_rproc_in_standby(struct omap_rproc *oproc)
>>   
>>   /* 1 sec is long enough time to let the remoteproc side suspend the device */
>>   #define DEF_SUSPEND_TIMEOUT 1000
>> -static int _omap_rproc_suspend(struct rproc *rproc)
>> +static int _omap_rproc_suspend(struct rproc *rproc, bool auto_suspend)
>>   {
>>   	struct device *dev = rproc->dev.parent;
>>   	struct omap_rproc *oproc = rproc->priv;
>>   	unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
>>   	unsigned long ta = jiffies + to;
>> +	u32 suspend_msg = auto_suspend ?
>> +				RP_MBOX_SUSPEND_AUTO : RP_MBOX_SUSPEND_SYSTEM;
>>   	int ret;
>>   
>>   	reinit_completion(&oproc->pm_comp);
>>   	oproc->suspend_acked = false;
>> -	ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_SUSPEND_SYSTEM);
>> +	ret = mbox_send_message(oproc->mbox, (void *)suspend_msg);
>>   	if (ret < 0) {
>>   		dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
>>   		return ret;
>> @@ -602,25 +665,55 @@ static int _omap_rproc_suspend(struct rproc *rproc)
>>   		goto enable_device;
>>   	}
>>   
>> +	/*
>> +	 * IOMMUs would have to be disabled specifically for runtime suspend.
>> +	 * They are handled automatically through System PM callbacks for
>> +	 * regular system suspend
>> +	 */
>> +	if (auto_suspend) {
>> +		ret = omap_iommu_domain_deactivate(rproc->domain);
>> +		if (ret) {
>> +			dev_err(dev, "iommu domain deactivate failed %d\n",
>> +				ret);
>> +			goto enable_timers;
>> +		}
>> +	}
>> +
>>   	return 0;
>> +enable_timers:
>> +	/* ignore errors on re-enabling code */
>> +	omap_rproc_enable_timers(rproc, false);
>>   
>>   enable_device:
>>   	reset_control_deassert(oproc->reset);
>>   	return ret;
>>   }
>>   
>> -static int _omap_rproc_resume(struct rproc *rproc)
>> +static int _omap_rproc_resume(struct rproc *rproc, bool auto_suspend)
>>   {
>>   	struct device *dev = rproc->dev.parent;
>>   	struct omap_rproc *oproc = rproc->priv;
>>   	int ret;
>>   
>> +	/*
>> +	 * IOMMUs would have to be enabled specifically for runtime resume.
>> +	 * They would have been already enabled automatically through System
>> +	 * PM callbacks for regular system resume
>> +	 */
>> +	if (auto_suspend) {
>> +		ret = omap_iommu_domain_activate(rproc->domain);
>> +		if (ret) {
>> +			dev_err(dev, "omap_iommu activate failed %d\n", ret);
>> +			goto out;
>> +		}
>> +	}
>> +
>>   	/* boot address could be lost after suspend, so restore it */
>>   	if (oproc->boot_data) {
>>   		ret = omap_rproc_write_dsp_boot_addr(rproc);
>>   		if (ret) {
>>   			dev_err(dev, "boot address restore failed %d\n", ret);
>> -			goto out;
>> +			goto suspend_iommu;
> 
> The same needs to be done if omap_rproc_enable_timers() fails.

Ok, will enhance the error handling logic a bit for v4.

> 
>>   		}
>>   	}
>>   
>> @@ -633,6 +726,12 @@ static int _omap_rproc_resume(struct rproc *rproc)
>>   
>>   	reset_control_deassert(oproc->reset);
>>   
>> +	return 0;
>> +
>> +suspend_iommu:
>> +	if (auto_suspend)
>> +		omap_iommu_domain_deactivate(rproc->domain);
>> +
>>   out:
>>   	return ret;
>>   }
>> @@ -641,6 +740,7 @@ static int __maybe_unused omap_rproc_suspend(struct device *dev)
>>   {
>>   	struct platform_device *pdev = to_platform_device(dev);
>>   	struct rproc *rproc = platform_get_drvdata(pdev);
>> +	struct omap_rproc *oproc = rproc->priv;
>>   	int ret = 0;
>>   
>>   	mutex_lock(&rproc->lock);
>> @@ -655,13 +755,25 @@ static int __maybe_unused omap_rproc_suspend(struct device *dev)
>>   		goto out;
>>   	}
>>   
>> -	ret = _omap_rproc_suspend(rproc);
>> +	ret = _omap_rproc_suspend(rproc, false);
>>   	if (ret) {
>>   		dev_err(dev, "suspend failed %d\n", ret);
>>   		goto out;
>>   	}
>>   
>> +	/*
>> +	 * remoteproc is running at the time of system suspend, so remember
>> +	 * it so as to wake it up during system resume
>> +	 */
>> +	oproc->need_resume = 1;
> 
> Please use 'true' to be consistent with the type and omap_rproc_resume().

Right.

> 
>>   	rproc->state = RPROC_SUSPENDED;
>> +
>> +	/*
>> +	 * update the runtime pm status to be suspended, without decrementing
>> +	 * the device usage count
>> +	 */
>> +	pm_runtime_disable(dev);
>> +	pm_runtime_set_suspended(dev);
>>   out:
>>   	mutex_unlock(&rproc->lock);
>>   	return ret;
>> @@ -671,6 +783,7 @@ static int __maybe_unused omap_rproc_resume(struct device *dev)
>>   {
>>   	struct platform_device *pdev = to_platform_device(dev);
>>   	struct rproc *rproc = platform_get_drvdata(pdev);
>> +	struct omap_rproc *oproc = rproc->priv;
>>   	int ret = 0;
>>   
>>   	mutex_lock(&rproc->lock);
>> @@ -682,17 +795,91 @@ static int __maybe_unused omap_rproc_resume(struct device *dev)
>>   		goto out;
>>   	}
>>   
>> -	ret = _omap_rproc_resume(rproc);
>> +	/*
>> +	 * remoteproc was auto-suspended at the time of system suspend,
>> +	 * so no need to wake-up the processor (leave it in suspended
>> +	 * state, will be woken up during a subsequent runtime_resume)
>> +	 */
>> +	if (!oproc->need_resume)
>> +		goto out;
>> +
>> +	ret = _omap_rproc_resume(rproc, false);
>>   	if (ret) {
>>   		dev_err(dev, "resume failed %d\n", ret);
>>   		goto out;
>>   	}
>> +	oproc->need_resume = false;
>>   
>>   	rproc->state = RPROC_RUNNING;
>> +
>> +	/*
>> +	 * update the runtime pm status to be active, without incrementing
>> +	 * the device usage count
>> +	 */
>> +	pm_runtime_set_active(dev);
>> +	pm_runtime_enable(dev);
>> +	pm_runtime_mark_last_busy(dev);
>>   out:
>>   	mutex_unlock(&rproc->lock);
>>   	return ret;
>>   }
>> +
>> +static int omap_rproc_runtime_suspend(struct device *dev)
>> +{
>> +	struct rproc *rproc = dev_get_drvdata(dev);
>> +	struct omap_rproc *oproc = rproc->priv;
>> +	int ret;
>> +
>> +	if (rproc->state == RPROC_CRASHED) {
>> +		dev_dbg(dev, "rproc cannot be runtime suspended when crashed!\n");
>> +		return -EBUSY;
>> +	}
>> +
>> +	if (WARN_ON(rproc->state != RPROC_RUNNING)) {
>> +		dev_err(dev, "rproc cannot be runtime suspended when not running!\n");
>> +		return -EBUSY;
>> +	}
>> +
>> +	/*
>> +	 * do not even attempt suspend if the remote processor is not
>> +	 * idled for runtime auto-suspend
>> +	 */
>> +	if (!_is_rproc_in_standby(oproc)) {
>> +		ret = -EBUSY;
>> +		goto abort;
>> +	}
>> +
>> +	ret = _omap_rproc_suspend(rproc, true);
>> +	if (ret)
>> +		goto abort;
>> +
>> +	rproc->state = RPROC_SUSPENDED;
>> +	return 0;
>> +
>> +abort:
>> +	pm_runtime_mark_last_busy(dev);
>> +	return ret;
>> +}
>> +
>> +static int omap_rproc_runtime_resume(struct device *dev)
>> +{
>> +	struct rproc *rproc = dev_get_drvdata(dev);
>> +	int ret;
>> +
>> +	if (WARN_ON(rproc->state != RPROC_SUSPENDED)) {
>> +		dev_err(dev, "rproc cannot be runtime resumed if not suspended!\n");
>> +		return -EBUSY;
>> +	}
>> +
>> +	ret = _omap_rproc_resume(rproc, true);
>> +	if (ret) {
>> +		dev_err(dev, "runtime resume failed %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	rproc->state = RPROC_RUNNING;
>> +	return 0;
>> +}
>>   #endif /* CONFIG_PM */
>>   
>>   static const char * const ipu_mem_names[] = {
>> @@ -778,6 +965,20 @@ static const struct of_device_id omap_rproc_of_match[] = {
>>   };
>>   MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
>>   
>> +static int omap_rproc_get_autosuspend_delay(struct platform_device *pdev)
>> +{
>> +	const struct omap_rproc_dev_data *data;
>> +	int delay;
>> +
>> +	data = of_device_get_match_data(&pdev->dev);
>> +	if (!data)
>> +		return -ENODEV;
> 
> This check is done in omap_rproc_of_get_internal_memories() and
> omap_rproc_get_boot_data().  I think it would be best to do it once at the top
> of the probe() function and be done with it.
> 
> That being said and as noted in a previous comment, I would push all tuneables
> to the DT.  If the property is missing then things default to
> DEFAULT_AUTOSUSPEND_DELAY.

Ok, let me do that.

-Tero

> 
>> +
>> +	delay = data->autosuspend_delay;
>> +
>> +	return (delay > 0) ? delay : DEFAULT_AUTOSUSPEND_DELAY;
>> +}
>> +
>>   static const char *omap_rproc_get_firmware(struct platform_device *pdev)
>>   {
>>   	const char *fw_name;
>> @@ -953,6 +1154,11 @@ static int omap_rproc_probe(struct platform_device *pdev)
>>   	}
>>   
>>   	init_completion(&oproc->pm_comp);
>> +	oproc->autosuspend_delay = omap_rproc_get_autosuspend_delay(pdev);
>> +	if (oproc->autosuspend_delay < 0) {
>> +		ret = oproc->autosuspend_delay;
>> +		goto free_rproc;
>> +	}
>>   
>>   	oproc->fck = devm_clk_get(&pdev->dev, 0);
>>   	if (IS_ERR(oproc->fck)) {
>> @@ -994,6 +1200,8 @@ static int omap_rproc_remove(struct platform_device *pdev)
>>   
>>   static const struct dev_pm_ops omap_rproc_pm_ops = {
>>   	SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
>> +	SET_RUNTIME_PM_OPS(omap_rproc_runtime_suspend,
>> +			   omap_rproc_runtime_resume, NULL)
>>   };
>>   
>>   static struct platform_driver omap_rproc_driver = {
>> -- 
>> 2.17.1
>>
>> --

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume
  2019-12-20  3:24     ` Suman Anna
@ 2019-12-20 11:24       ` Tero Kristo
  2019-12-20 18:44         ` Suman Anna
  0 siblings, 1 reply; 50+ messages in thread
From: Tero Kristo @ 2019-12-20 11:24 UTC (permalink / raw)
  To: Suman Anna, Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-omap

On 20/12/2019 05:24, Suman Anna wrote:
> Hi Tero,
> 
> On 12/19/19 5:43 PM, Mathieu Poirier wrote:
>> On Fri, Dec 13, 2019 at 02:55:35PM +0200, Tero Kristo wrote:
>>> From: Suman Anna <s-anna@ti.com>
>>>
>>> This patch enhances the PM support in the OMAP remoteproc driver to
>>> support the runtime auto-suspend. A remoteproc may not be required to
>>> be running all the time, and typically will need to be active only
>>> during certain usecases. As such, to save power, it should be turned
>>> off during potential long periods of inactivity between usecases.
>>> This suspend and resume of the device is a relatively heavy process
>>> in terms of latencies, so a remoteproc should be suspended only after
>>> a certain period of prolonged inactivity. The OMAP remoteproc driver
>>> leverages the runtime pm framework's auto_suspend feature to accomplish
>>> this functionality. This feature is automatically enabled when a remote
>>> processor has successfully booted. The 'autosuspend_delay_ms' for each
>>> device dictates the inactivity period/time to wait for before
>>> suspending the device.
>>>
>>> The runtime auto-suspend design relies on marking the last busy time
>>> on every communication (virtqueue kick) to and from the remote processor.
>>> When there has been no activity for 'autosuspend_delay_ms' time, the
>>> runtime PM framework invokes the driver's runtime pm suspend callback
>>> to suspend the device. The remote processor will be woken up on the
>>> initiation of the next communication message through the runtime pm
>>> resume callback. The current auto-suspend design also allows a remote
>>> processor to deny a auto-suspend attempt, if it wishes to, by sending a
>>> NACK response to the initial suspend request message sent to the remote
>>> processor as part of the suspend process. The auto-suspend request is
>>> also only attempted if the remote processor is idled and in standby at
>>> the time of inactivity timer expiry. This choice is made to avoid
>>> unnecessary messaging, and the auto-suspend is simply rescheduled to
>>> be attempted again after a further lapse of autosuspend_delay_ms.
>>>
>>> The runtime pm callbacks functionality in this patch reuses most of the
>>> core logic from the suspend/resume support code, and make use of an
>>> additional auto_suspend flag to differentiate the logic in common code
>>> from system suspend. The system suspend/resume sequences are also updated
>>> to reflect the proper pm_runtime statuses, and also to really perform a
>>> suspend/resume only if the remoteproc has not been auto-suspended at the
>>> time of request. The remote processor is left in suspended state on a
>>> system resume if it has been auto-suspended before, and will be woken up
>>> only when a usecase needs to run. The other significant change in this
>>> patch is to reset the remoteproc device's pm_domain so as to avoid
>>> conflicts with the ordering sequences in the device pm_domain's runtime
>>> callbacks and the reset management and clock management implemented
>>> within the runtime callbacks in the driver.
>>>
>>> The OMAP remoteproc driver currently uses a default value of 10 seconds
>>> for all OMAP remoteprocs, and a different value can be chosen either by
>>> choosing a positive value for the 'autosuspend_delay' in the device's
>>> omap_rproc_fw_data in the driver match data or by updating the
>>> 'autosuspend_delay_ms' field at runtime through the sysfs interface.
>>>      Eg: To use 25 seconds for IPU2 on DRA7xx,
>>>        echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms
>>>
>>> The runtime suspend feature can also be similarly enabled or disabled by
>>> writing 'auto' or 'on' to the device's 'control' power field. The default
>>> is enabled.
>>>      Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
>>>        echo on > /sys/bus/platform/devices/55020000.ipu/power/control
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> [t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> ---
>>>   drivers/remoteproc/omap_remoteproc.c | 220 ++++++++++++++++++++++++++-
>>>   1 file changed, 214 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
>>> index 0a9b9f7d20da..463d6f60947a 100644
>>> --- a/drivers/remoteproc/omap_remoteproc.c
>>> +++ b/drivers/remoteproc/omap_remoteproc.c
>>> @@ -20,6 +20,7 @@
>>>   #include <linux/of_device.h>
>>>   #include <linux/of_reserved_mem.h>
>>>   #include <linux/platform_device.h>
>>> +#include <linux/pm_runtime.h>
>>>   #include <linux/dma-mapping.h>
>>>   #include <linux/remoteproc.h>
>>>   #include <linux/mailbox_client.h>
>>> @@ -37,6 +38,9 @@
>>>   #include "omap_remoteproc.h"
>>>   #include "remoteproc_internal.h"
>>>   
>>> +/* default auto-suspend delay (ms) */
>>> +#define DEFAULT_AUTOSUSPEND_DELAY		10000
>>> +
>>>   /**
>>>    * struct omap_rproc_boot_data - boot data structure for the DSP omap rprocs
>>>    * @syscon: regmap handle for the system control configuration module
>>> @@ -83,6 +87,8 @@ struct omap_rproc_timer {
>>>    * @num_mems: number of internal memory regions
>>>    * @num_timers: number of rproc timer(s)
>>>    * @timers: timer(s) info used by rproc
>>> + * @autosuspend_delay: auto-suspend delay value to be used for runtime pm
>>> + * @need_resume: if true a resume is needed in the system resume callback
>>>    * @rproc: rproc handle
>>>    * @reset: reset handle
>>>    * @pm_comp: completion primitive to sync for suspend response
>>> @@ -97,6 +103,8 @@ struct omap_rproc {
>>>   	int num_mems;
>>>   	int num_timers;
>>>   	struct omap_rproc_timer *timers;
>>> +	int autosuspend_delay;
>>> +	bool need_resume;
>>>   	struct rproc *rproc;
>>>   	struct reset_control *reset;
>>>   	struct completion pm_comp;
>>> @@ -111,6 +119,7 @@ struct omap_rproc {
>>>    * @boot_reg_shift: bit shift for the boot register mask
>>>    * @mem_names: memory names for this remote processor
>>>    * @dev_addrs: device addresses corresponding to the memory names
>>> + * @autosuspend_delay: custom auto-suspend delay value in milliseconds
>>>    */
>>>   struct omap_rproc_dev_data {
>>>   	const char *device_name;
>>> @@ -118,6 +127,7 @@ struct omap_rproc_dev_data {
>>>   	int boot_reg_shift;
>>>   	const char * const *mem_names;
>>>   	const u32 *dev_addrs;
>>> +	int autosuspend_delay;
>>>   };
>>>   
>>>   /**
>>> @@ -384,11 +394,23 @@ static void omap_rproc_kick(struct rproc *rproc, int vqid)
>>>   	struct device *dev = rproc->dev.parent;
>>>   	int ret;
>>>   
>>> +	/* wake up the rproc before kicking it */
>>> +	ret = pm_runtime_get_sync(dev);
>>> +	if (WARN_ON(ret < 0)) {
>>> +		dev_err(dev, "pm_runtime_get_sync() failed during kick, ret = %d\n",
>>> +			ret);
>>> +		pm_runtime_put_noidle(dev);
>>> +		return;
>>> +	}
>>> +
>>>   	/* send the index of the triggered virtqueue in the mailbox payload */
>>>   	ret = mbox_send_message(oproc->mbox, (void *)vqid);
>>>   	if (ret < 0)
>>>   		dev_err(dev, "failed to send mailbox message, status = %d\n",
>>>   			ret);
>>> +
>>> +	pm_runtime_mark_last_busy(dev);
>>> +	pm_runtime_put_autosuspend(dev);
>>>   }
>>>   
>>>   /**
>>> @@ -473,6 +495,19 @@ static int omap_rproc_start(struct rproc *rproc)
>>>   		goto put_mbox;
>>>   	}
>>>   
>>> +	/*
>>> +	 * remote processor is up, so update the runtime pm status and
>>> +	 * enable the auto-suspend. The device usage count is incremented
>>> +	 * manually for balancing it for auto-suspend
>>> +	 */
>>> +	pm_runtime_set_active(dev);
>>> +	pm_runtime_set_autosuspend_delay(dev, oproc->autosuspend_delay);
>>> +	pm_runtime_use_autosuspend(dev);
>>> +	pm_runtime_get(dev);
>>> +	pm_runtime_enable(dev);
>>> +	pm_runtime_mark_last_busy(dev);
>>> +	pm_runtime_put_autosuspend(dev);
>>> +
>>>   	reset_control_deassert(oproc->reset);
> 
> I see that you have flipped the reset call and all the pm_runtime calls
> (w.r.t my original code sequence) and pm_runtime_get instead of
> pm_runtime_get_noresume(). Is there a reason for it? What is the backend
> that gets exercised with pm_runtime?

PM runtime nowadays exercises ti-sysc, and we can't deassert reset 
before we enable the clocks for the device. Thus, these are flipped.

In the old incarnation of this code, PM runtime just exercised the 
hacked up functionality implemented for omap rproc alone.

> 
>>>   
>>>   	return 0;
>>> @@ -485,9 +520,26 @@ static int omap_rproc_start(struct rproc *rproc)
>>>   /* power off the remote processor */
>>>   static int omap_rproc_stop(struct rproc *rproc)
>>>   {
>>> +	struct device *dev = rproc->dev.parent;
>>>   	struct omap_rproc *oproc = rproc->priv;
>>>   	int ret;
>>>   
>>> +	/*
>>> +	 * cancel any possible scheduled runtime suspend by incrementing
>>> +	 * the device usage count, and resuming the device. The remoteproc
>>> +	 * also needs to be woken up if suspended, to avoid the remoteproc
>>> +	 * OS to continue to remember any context that it has saved, and
>>> +	 * avoid potential issues in misindentifying a subsequent device
>>> +	 * reboot as a power restore boot
>>> +	 */
>>> +	ret = pm_runtime_get_sync(dev);
>>> +	if (ret < 0) {
>>> +		pm_runtime_put_noidle(dev);
>>> +		return ret;
>>> +	}
>>> +
>>> +	pm_runtime_put_sync(dev);
>>> +
> 
> I didn't have this call either. And get_sync() followed by put_sync() is
> essentially a no-op. Am I missing something here?

Hmm right, but you did have the device_shutdown() here, somehow this 
appears to simulate that, but you are right, it is just a no-op. I don't 
know if this code has actually ever done anything useful. Let me 
experiment with this one a bit and see what happens. It looks like it 
should be removed completely.

> 
>>>   	reset_control_assert(oproc->reset);
>>>   
>>>   	ret = omap_rproc_disable_timers(rproc, true);
>>> @@ -496,6 +548,15 @@ static int omap_rproc_stop(struct rproc *rproc)
>>>   
>>>   	mbox_free_channel(oproc->mbox);
>>>   
>>> +	/*
>>> +	 * update the runtime pm states and status now that the remoteproc
>>> +	 * has stopped
>>> +	 */
>>> +	pm_runtime_disable(dev);
>>> +	pm_runtime_dont_use_autosuspend(dev);
>>> +	pm_runtime_put_noidle(dev);
>>> +	pm_runtime_set_suspended(dev);
>>> +
>>>   	return 0;
>>>   }
>>>   
>>> @@ -552,17 +613,19 @@ static bool _is_rproc_in_standby(struct omap_rproc *oproc)
>>>   
>>>   /* 1 sec is long enough time to let the remoteproc side suspend the device */
>>>   #define DEF_SUSPEND_TIMEOUT 1000
>>> -static int _omap_rproc_suspend(struct rproc *rproc)
>>> +static int _omap_rproc_suspend(struct rproc *rproc, bool auto_suspend)
>>>   {
>>>   	struct device *dev = rproc->dev.parent;
>>>   	struct omap_rproc *oproc = rproc->priv;
>>>   	unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
>>>   	unsigned long ta = jiffies + to;
>>> +	u32 suspend_msg = auto_suspend ?
>>> +				RP_MBOX_SUSPEND_AUTO : RP_MBOX_SUSPEND_SYSTEM;
>>>   	int ret;
>>>   
>>>   	reinit_completion(&oproc->pm_comp);
>>>   	oproc->suspend_acked = false;
>>> -	ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_SUSPEND_SYSTEM);
>>> +	ret = mbox_send_message(oproc->mbox, (void *)suspend_msg);
>>>   	if (ret < 0) {
>>>   		dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
>>>   		return ret;
>>> @@ -602,25 +665,55 @@ static int _omap_rproc_suspend(struct rproc *rproc)
>>>   		goto enable_device;
>>>   	}
>>>   
>>> +	/*
>>> +	 * IOMMUs would have to be disabled specifically for runtime suspend.
>>> +	 * They are handled automatically through System PM callbacks for
>>> +	 * regular system suspend
>>> +	 */
>>> +	if (auto_suspend) {
>>> +		ret = omap_iommu_domain_deactivate(rproc->domain);
>>> +		if (ret) {
>>> +			dev_err(dev, "iommu domain deactivate failed %d\n",
>>> +				ret);
>>> +			goto enable_timers;
>>> +		}
>>> +	}
>>> +
>>>   	return 0;
> 
> blank line here, and remove the one before enable_device.

Hmm why? I don't think there is any coding guideline that would dictate 
this. However, I'll fix this as this is effectively your file anyways.

-Tero

> 
> regards
> Suman
> 
>>> +enable_timers:
>>> +	/* ignore errors on re-enabling code */
>>> +	omap_rproc_enable_timers(rproc, false);
>>>   
>>>   enable_device:
>>>   	reset_control_deassert(oproc->reset);
>>>   	return ret;
>>>   }
>>>   
>>> -static int _omap_rproc_resume(struct rproc *rproc)
>>> +static int _omap_rproc_resume(struct rproc *rproc, bool auto_suspend)
>>>   {
>>>   	struct device *dev = rproc->dev.parent;
>>>   	struct omap_rproc *oproc = rproc->priv;
>>>   	int ret;
>>>   
>>> +	/*
>>> +	 * IOMMUs would have to be enabled specifically for runtime resume.
>>> +	 * They would have been already enabled automatically through System
>>> +	 * PM callbacks for regular system resume
>>> +	 */
>>> +	if (auto_suspend) {
>>> +		ret = omap_iommu_domain_activate(rproc->domain);
>>> +		if (ret) {
>>> +			dev_err(dev, "omap_iommu activate failed %d\n", ret);
>>> +			goto out;
>>> +		}
>>> +	}
>>> +
>>>   	/* boot address could be lost after suspend, so restore it */
>>>   	if (oproc->boot_data) {
>>>   		ret = omap_rproc_write_dsp_boot_addr(rproc);
>>>   		if (ret) {
>>>   			dev_err(dev, "boot address restore failed %d\n", ret);
>>> -			goto out;
>>> +			goto suspend_iommu;
>>
>> The same needs to be done if omap_rproc_enable_timers() fails.
>>
>>>   		}
>>>   	}
>>>   
>>> @@ -633,6 +726,12 @@ static int _omap_rproc_resume(struct rproc *rproc)
>>>   
>>>   	reset_control_deassert(oproc->reset);
>>>   
>>> +	return 0;
>>> +
>>> +suspend_iommu:
>>> +	if (auto_suspend)
>>> +		omap_iommu_domain_deactivate(rproc->domain);
>>> +
>>>   out:
>>>   	return ret;
>>>   }
>>> @@ -641,6 +740,7 @@ static int __maybe_unused omap_rproc_suspend(struct device *dev)
>>>   {
>>>   	struct platform_device *pdev = to_platform_device(dev);
>>>   	struct rproc *rproc = platform_get_drvdata(pdev);
>>> +	struct omap_rproc *oproc = rproc->priv;
>>>   	int ret = 0;
>>>   
>>>   	mutex_lock(&rproc->lock);
>>> @@ -655,13 +755,25 @@ static int __maybe_unused omap_rproc_suspend(struct device *dev)
>>>   		goto out;
>>>   	}
>>>   
>>> -	ret = _omap_rproc_suspend(rproc);
>>> +	ret = _omap_rproc_suspend(rproc, false);
>>>   	if (ret) {
>>>   		dev_err(dev, "suspend failed %d\n", ret);
>>>   		goto out;
>>>   	}
>>>   
>>> +	/*
>>> +	 * remoteproc is running at the time of system suspend, so remember
>>> +	 * it so as to wake it up during system resume
>>> +	 */
>>> +	oproc->need_resume = 1;
>>
>> Please use 'true' to be consistent with the type and omap_rproc_resume().
>>
>>>   	rproc->state = RPROC_SUSPENDED;
>>> +
>>> +	/*
>>> +	 * update the runtime pm status to be suspended, without decrementing
>>> +	 * the device usage count
>>> +	 */
>>> +	pm_runtime_disable(dev);
>>> +	pm_runtime_set_suspended(dev);
>>>   out:
>>>   	mutex_unlock(&rproc->lock);
>>>   	return ret;
>>> @@ -671,6 +783,7 @@ static int __maybe_unused omap_rproc_resume(struct device *dev)
>>>   {
>>>   	struct platform_device *pdev = to_platform_device(dev);
>>>   	struct rproc *rproc = platform_get_drvdata(pdev);
>>> +	struct omap_rproc *oproc = rproc->priv;
>>>   	int ret = 0;
>>>   
>>>   	mutex_lock(&rproc->lock);
>>> @@ -682,17 +795,91 @@ static int __maybe_unused omap_rproc_resume(struct device *dev)
>>>   		goto out;
>>>   	}
>>>   
>>> -	ret = _omap_rproc_resume(rproc);
>>> +	/*
>>> +	 * remoteproc was auto-suspended at the time of system suspend,
>>> +	 * so no need to wake-up the processor (leave it in suspended
>>> +	 * state, will be woken up during a subsequent runtime_resume)
>>> +	 */
>>> +	if (!oproc->need_resume)
>>> +		goto out;
>>> +
>>> +	ret = _omap_rproc_resume(rproc, false);
>>>   	if (ret) {
>>>   		dev_err(dev, "resume failed %d\n", ret);
>>>   		goto out;
>>>   	}
>>> +	oproc->need_resume = false;
>>>   
>>>   	rproc->state = RPROC_RUNNING;
>>> +
>>> +	/*
>>> +	 * update the runtime pm status to be active, without incrementing
>>> +	 * the device usage count
>>> +	 */
>>> +	pm_runtime_set_active(dev);
>>> +	pm_runtime_enable(dev);
>>> +	pm_runtime_mark_last_busy(dev);
>>>   out:
>>>   	mutex_unlock(&rproc->lock);
>>>   	return ret;
>>>   }
>>> +
>>> +static int omap_rproc_runtime_suspend(struct device *dev)
>>> +{
>>> +	struct rproc *rproc = dev_get_drvdata(dev);
>>> +	struct omap_rproc *oproc = rproc->priv;
>>> +	int ret;
>>> +
>>> +	if (rproc->state == RPROC_CRASHED) {
>>> +		dev_dbg(dev, "rproc cannot be runtime suspended when crashed!\n");
>>> +		return -EBUSY;
>>> +	}
>>> +
>>> +	if (WARN_ON(rproc->state != RPROC_RUNNING)) {
>>> +		dev_err(dev, "rproc cannot be runtime suspended when not running!\n");
>>> +		return -EBUSY;
>>> +	}
>>> +
>>> +	/*
>>> +	 * do not even attempt suspend if the remote processor is not
>>> +	 * idled for runtime auto-suspend
>>> +	 */
>>> +	if (!_is_rproc_in_standby(oproc)) {
>>> +		ret = -EBUSY;
>>> +		goto abort;
>>> +	}
>>> +
>>> +	ret = _omap_rproc_suspend(rproc, true);
>>> +	if (ret)
>>> +		goto abort;
>>> +
>>> +	rproc->state = RPROC_SUSPENDED;
>>> +	return 0;
>>> +
>>> +abort:
>>> +	pm_runtime_mark_last_busy(dev);
>>> +	return ret;
>>> +}
>>> +
>>> +static int omap_rproc_runtime_resume(struct device *dev)
>>> +{
>>> +	struct rproc *rproc = dev_get_drvdata(dev);
>>> +	int ret;
>>> +
>>> +	if (WARN_ON(rproc->state != RPROC_SUSPENDED)) {
>>> +		dev_err(dev, "rproc cannot be runtime resumed if not suspended!\n");
>>> +		return -EBUSY;
>>> +	}
>>> +
>>> +	ret = _omap_rproc_resume(rproc, true);
>>> +	if (ret) {
>>> +		dev_err(dev, "runtime resume failed %d\n", ret);
>>> +		return ret;
>>> +	}
>>> +
>>> +	rproc->state = RPROC_RUNNING;
>>> +	return 0;
>>> +}
>>>   #endif /* CONFIG_PM */
>>>   
>>>   static const char * const ipu_mem_names[] = {
>>> @@ -778,6 +965,20 @@ static const struct of_device_id omap_rproc_of_match[] = {
>>>   };
>>>   MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
>>>   
>>> +static int omap_rproc_get_autosuspend_delay(struct platform_device *pdev)
>>> +{
>>> +	const struct omap_rproc_dev_data *data;
>>> +	int delay;
>>> +
>>> +	data = of_device_get_match_data(&pdev->dev);
>>> +	if (!data)
>>> +		return -ENODEV;
>>
>> This check is done in omap_rproc_of_get_internal_memories() and
>> omap_rproc_get_boot_data().  I think it would be best to do it once at the top
>> of the probe() function and be done with it.
>>
>> That being said and as noted in a previous comment, I would push all tuneables
>> to the DT.  If the property is missing then things default to
>> DEFAULT_AUTOSUSPEND_DELAY.
>>
>>> +
>>> +	delay = data->autosuspend_delay;
>>> +
>>> +	return (delay > 0) ? delay : DEFAULT_AUTOSUSPEND_DELAY;
>>> +}
>>> +
>>>   static const char *omap_rproc_get_firmware(struct platform_device *pdev)
>>>   {
>>>   	const char *fw_name;
>>> @@ -953,6 +1154,11 @@ static int omap_rproc_probe(struct platform_device *pdev)
>>>   	}
>>>   
>>>   	init_completion(&oproc->pm_comp);
>>> +	oproc->autosuspend_delay = omap_rproc_get_autosuspend_delay(pdev);
>>> +	if (oproc->autosuspend_delay < 0) {
>>> +		ret = oproc->autosuspend_delay;
>>> +		goto free_rproc;
>>> +	}
>>>   
>>>   	oproc->fck = devm_clk_get(&pdev->dev, 0);
>>>   	if (IS_ERR(oproc->fck)) {
>>> @@ -994,6 +1200,8 @@ static int omap_rproc_remove(struct platform_device *pdev)
>>>   
>>>   static const struct dev_pm_ops omap_rproc_pm_ops = {
>>>   	SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
>>> +	SET_RUNTIME_PM_OPS(omap_rproc_runtime_suspend,
>>> +			   omap_rproc_runtime_resume, NULL)
>>>   };
>>>   
>>>   static struct platform_driver omap_rproc_driver = {
>>> -- 
>>> 2.17.1
>>>
>>> --
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 02/15] remoteproc/omap: Add device tree support
  2019-12-20  9:36         ` Tero Kristo
@ 2019-12-20 18:17           ` Suman Anna
  0 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2019-12-20 18:17 UTC (permalink / raw)
  To: Tero Kristo, Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel,
	linux-omap, Tony Lindgren

On 12/20/19 3:36 AM, Tero Kristo wrote:
> On 20/12/2019 04:08, Suman Anna wrote:
>> Hi Tero, Mathieu,
>>
>> On 12/19/19 5:54 AM, Tero Kristo wrote:
>>> On 18/12/2019 01:01, Mathieu Poirier wrote:
>>>> Hi Tero,
>>>>
>>>> On Fri, Dec 13, 2019 at 02:55:24PM +0200, Tero Kristo wrote:
>>>>> From: Suman Anna <s-anna@ti.com>
>>>>>
>>>>> OMAP4+ SoCs support device tree boot only. The OMAP remoteproc
>>>>> driver is enhanced to support remoteproc devices created through
>>>>> Device Tree, support for legacy platform devices has been
>>>>> deprecated. The current DT support handles the IPU and DSP
>>>>> processor subsystems on OMAP4 and OMAP5 SoCs.
>>>>>
>>>>> The OMAP remoteproc driver relies on the ti-sysc, reset, and
>>>>> syscon layers for performing clock, reset and boot vector
>>>>> management (DSP remoteprocs only) of the devices, but some of
>>>>> these are limited only to the machine-specific layers
>>>>> in arch/arm. The dependency against control module API for boot
>>>>> vector management of the DSP remoteprocs has now been removed
>>>>> with added logic to parse the boot register from the DT node
>>>>> and program it appropriately directly within the driver.
>>>>>
>>>>> The OMAP remoteproc driver expects the firmware names to be
>>>>> provided via device tree entries (firmware-name.) These are used
>>>>> to load the proper firmware during boot of the remote processor.
>>>>>
>>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>>> [t-kristo@ti.com: converted to use ti-sysc framework]
>>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>>> ---
>>>>>    drivers/remoteproc/omap_remoteproc.c | 191
>>>>> +++++++++++++++++++++++----
>>>>>    1 file changed, 168 insertions(+), 23 deletions(-)
>>>>>
>>>>> diff --git a/drivers/remoteproc/omap_remoteproc.c
>>>>> b/drivers/remoteproc/omap_remoteproc.c
>>>>> index 6398194075aa..558634624590 100644
>>>>> --- a/drivers/remoteproc/omap_remoteproc.c
>>>>> +++ b/drivers/remoteproc/omap_remoteproc.c
>>>>> @@ -2,7 +2,7 @@
>>>>>    /*
>>>>>     * OMAP Remote Processor driver
>>>>>     *
>>>>> - * Copyright (C) 2011 Texas Instruments, Inc.
>>>>> + * Copyright (C) 2011-2019 Texas Instruments Incorporated -
>>>>> http://www.ti.com/
>>>>>     * Copyright (C) 2011 Google, Inc.
>>>>>     *
>>>>>     * Ohad Ben-Cohen <ohad@wizery.com>
>>>>> @@ -16,27 +16,53 @@
>>>>>    #include <linux/kernel.h>
>>>>>    #include <linux/module.h>
>>>>>    #include <linux/err.h>
>>>>> +#include <linux/of_device.h>
>>>>>    #include <linux/platform_device.h>
>>>>>    #include <linux/dma-mapping.h>
>>>>>    #include <linux/remoteproc.h>
>>>>>    #include <linux/mailbox_client.h>
>>>>>    #include <linux/omap-mailbox.h>
>>>>> -
>>>>> -#include <linux/platform_data/remoteproc-omap.h>
>>>>> +#include <linux/regmap.h>
>>>>> +#include <linux/mfd/syscon.h>
>>>>> +#include <linux/reset.h>
>>>>>      #include "omap_remoteproc.h"
>>>>>    #include "remoteproc_internal.h"
>>>>>    +/**
>>>>> + * struct omap_rproc_boot_data - boot data structure for the DSP
>>>>> omap rprocs
>>>>> + * @syscon: regmap handle for the system control configuration module
>>>>> + * @boot_reg: boot register offset within the @syscon regmap
>>>>> + */
>>>>> +struct omap_rproc_boot_data {
>>>>> +    struct regmap *syscon;
>>>>> +    unsigned int boot_reg;
>>>>> +};
>>>>> +
>>>>>    /**
>>>>>     * struct omap_rproc - omap remote processor state
>>>>>     * @mbox: mailbox channel handle
>>>>>     * @client: mailbox client to request the mailbox channel
>>>>> + * @boot_data: boot data structure for setting processor boot address
>>>>>     * @rproc: rproc handle
>>>>> + * @reset: reset handle
>>>>>     */
>>>>>    struct omap_rproc {
>>>>>        struct mbox_chan *mbox;
>>>>>        struct mbox_client client;
>>>>> +    struct omap_rproc_boot_data *boot_data;
>>>>>        struct rproc *rproc;
>>>>> +    struct reset_control *reset;
>>>>> +};
>>>>> +
>>>>> +/**
>>>>> + * struct omap_rproc_dev_data - device data for the omap remote
>>>>> processor
>>>>> + * @device_name: device name of the remote processor
>>>>> + * @has_bootreg: true if this remote processor has boot register
>>>>> + */
>>>>> +struct omap_rproc_dev_data {
>>>>> +    const char *device_name;
>>>>> +    bool has_bootreg;
>>>>>    };
>>>>>      /**
>>>>> @@ -92,6 +118,21 @@ static void omap_rproc_kick(struct rproc *rproc,
>>>>> int vqid)
>>>>>                ret);
>>>>>    }
>>>>>    +/**
>>>>> + * omap_rproc_write_dsp_boot_addr - set boot address for a DSP
>>>>> remote processor
>>>>> + * @rproc: handle of a remote processor
>>>>> + *
>>>>> + * Set boot address for a supported DSP remote processor.
>>>>> + */
>>>>> +static void omap_rproc_write_dsp_boot_addr(struct rproc *rproc)
>>>>> +{
>>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>>> +    struct omap_rproc_boot_data *bdata = oproc->boot_data;
>>>>> +    u32 offset = bdata->boot_reg;
>>>>> +
>>>>> +    regmap_write(bdata->syscon, offset, rproc->bootaddr);
>>>>> +}
>>>>> +
>>>>>    /*
>>>>>     * Power up the remote processor.
>>>>>     *
>>>>> @@ -103,13 +144,11 @@ static int omap_rproc_start(struct rproc *rproc)
>>>>>    {
>>>>>        struct omap_rproc *oproc = rproc->priv;
>>>>>        struct device *dev = rproc->dev.parent;
>>>>> -    struct platform_device *pdev = to_platform_device(dev);
>>>>> -    struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>>>>>        int ret;
>>>>>        struct mbox_client *client = &oproc->client;
>>>>>    -    if (pdata->set_bootaddr)
>>>>> -        pdata->set_bootaddr(rproc->bootaddr);
>>>>> +    if (oproc->boot_data)
>>>>> +        omap_rproc_write_dsp_boot_addr(rproc);
>>>>>          client->dev = dev;
>>>>>        client->tx_done = NULL;
>>>>> @@ -117,7 +156,7 @@ static int omap_rproc_start(struct rproc *rproc)
>>>>>        client->tx_block = false;
>>>>>        client->knows_txdone = false;
>>>>>    -    oproc->mbox = omap_mbox_request_channel(client,
>>>>> pdata->mbox_name);
>>>>> +    oproc->mbox = mbox_request_channel(client, 0);
>>>>>        if (IS_ERR(oproc->mbox)) {
>>>>>            ret = -EBUSY;
>>>>>            dev_err(dev, "mbox_request_channel failed: %ld\n",
>>>>> @@ -138,11 +177,7 @@ static int omap_rproc_start(struct rproc *rproc)
>>>>>            goto put_mbox;
>>>>>        }
>>>>>    -    ret = pdata->device_enable(pdev);
>>>>> -    if (ret) {
>>>>> -        dev_err(dev, "omap_device_enable failed: %d\n", ret);
>>>>> -        goto put_mbox;
>>>>> -    }
>>>>> +    reset_control_deassert(oproc->reset);
>>>>>          return 0;
>>>>>    @@ -154,15 +189,9 @@ static int omap_rproc_start(struct rproc
>>>>> *rproc)
>>>>>    /* power off the remote processor */
>>>>>    static int omap_rproc_stop(struct rproc *rproc)
>>>>>    {
>>>>> -    struct device *dev = rproc->dev.parent;
>>>>> -    struct platform_device *pdev = to_platform_device(dev);
>>>>> -    struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>>>>>        struct omap_rproc *oproc = rproc->priv;
>>>>> -    int ret;
>>>>>    -    ret = pdata->device_shutdown(pdev);
>>>>> -    if (ret)
>>>>> -        return ret;
>>>>> +    reset_control_assert(oproc->reset);
>>
>> Any reasons for dropping the checks for the return status and wherever
>> you replaced the pdata callbacks with the desired reset API?
> 
> Ok, let me try to add the checks back.
> 
>>
>>>>>          mbox_free_channel(oproc->mbox);
>>>>>    @@ -175,12 +204,122 @@ static const struct rproc_ops omap_rproc_ops
>>>>> = {
>>>>>        .kick        = omap_rproc_kick,
>>>>>    };
>>>>>    +static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
>>>>> +    .device_name    = "dsp",
>>>>> +    .has_bootreg    = true,
>>>>> +};
>>>>> +
>>>>> +static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
>>>>> +    .device_name    = "ipu",
>>>>> +};
>>>>> +
>>>>> +static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
>>>>> +    .device_name    = "dsp",
>>>>> +    .has_bootreg    = true,
>>>>> +};
>>>>> +
>>>>> +static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
>>>>> +    .device_name    = "ipu",
>>>>> +};
>>>>> +
>>>>> +static const struct of_device_id omap_rproc_of_match[] = {
>>>>> +    {
>>>>> +        .compatible     = "ti,omap4-dsp",
>>>>> +        .data           = &omap4_dsp_dev_data,
>>>>> +    },
>>>>> +    {
>>>>> +        .compatible     = "ti,omap4-ipu",
>>>>> +        .data           = &omap4_ipu_dev_data,
>>>>> +    },
>>>>> +    {
>>>>> +        .compatible     = "ti,omap5-dsp",
>>>>> +        .data           = &omap5_dsp_dev_data,
>>>>> +    },
>>>>> +    {
>>>>> +        .compatible     = "ti,omap5-ipu",
>>>>> +        .data           = &omap5_ipu_dev_data,
>>>>> +    },
>>>>> +    {
>>>>> +        /* end */
>>>>> +    },
>>>>> +};
>>>>> +MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
>>>>> +
>>>>> +static const char *omap_rproc_get_firmware(struct platform_device
>>>>> *pdev)
>>>>> +{
>>>>> +    const char *fw_name;
>>>>> +    int ret;
>>>>> +
>>>>> +    ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
>>>>> +                      &fw_name);
>>>>> +    if (ret)
>>>>> +        return ERR_PTR(ret);
>>>>> +
>>>>> +    return fw_name;
>>>>> +}
>>>>> +
>>>>> +static int omap_rproc_get_boot_data(struct platform_device *pdev,
>>>>> +                    struct rproc *rproc)
>>>>> +{
>>>>> +    struct device_node *np = pdev->dev.of_node;
>>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>>> +    const struct omap_rproc_dev_data *data;
>>>>> +    int ret;
>>>>> +
>>>>> +    data = of_device_get_match_data(&pdev->dev);
>>>>> +    if (!data)
>>>>> +        return -ENODEV;
>>>>> +
>>>>> +    if (!data->has_bootreg)
>>>>> +        return 0;
>>>>> +
>>>>> +    oproc->boot_data = devm_kzalloc(&pdev->dev,
>>>>> sizeof(*oproc->boot_data),
>>>>> +                    GFP_KERNEL);
>>>>> +    if (!oproc->boot_data)
>>>>> +        return -ENOMEM;
>>>>> +
>>>>> +    if (!of_property_read_bool(np, "ti,bootreg")) {
>>>>> +        dev_err(&pdev->dev, "ti,bootreg property is missing\n");
>>>>> +        return -EINVAL;
>>>>> +    }
>>>>> +
>>>>> +    oproc->boot_data->syscon =
>>>>> +            syscon_regmap_lookup_by_phandle(np, "ti,bootreg");
>>>>> +    if (IS_ERR(oproc->boot_data->syscon)) {
>>>>> +        ret = PTR_ERR(oproc->boot_data->syscon);
>>>>> +        return ret;
>>>>> +    }
>>>>> +
>>>>> +    if (of_property_read_u32_index(np, "ti,bootreg", 1,
>>>>> +                       &oproc->boot_data->boot_reg)) {
>>>>> +        dev_err(&pdev->dev, "couldn't get the boot register\n");
>>>>> +        return -EINVAL;
>>>>> +    }
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +
>>>>>    static int omap_rproc_probe(struct platform_device *pdev)
>>>>>    {
>>>>> -    struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
>>>>> +    struct device_node *np = pdev->dev.of_node;
>>>>>        struct omap_rproc *oproc;
>>>>>        struct rproc *rproc;
>>>>> +    const char *firmware;
>>>>>        int ret;
>>>>> +    struct reset_control *reset;
>>>>> +
>>>>> +    if (!np) {
>>>>> +        dev_err(&pdev->dev, "only DT-based devices are supported\n");
>>>>> +        return -ENODEV;
>>>>> +    }
>>>>> +
>>>>> +    reset =
>>>>> devm_reset_control_array_get_optional_exclusive(&pdev->dev);
>>>>> +    if (IS_ERR(reset))
>>>>> +        return PTR_ERR(reset);
>>>>
>>>> Definition of a reset is listed as "required" in the bindings but here
>>>> it is
>>>> optional.  If this is really what you want then adding a comment to
>>>> exlain your
>>>> choice is probably a good idea.
>>>
>>> Right, I think I updated the binding to require this but forgot to
>>> update the driver for this part. Will fix this.
>>>
>>> -Tero
>>>
>>>>
>>>>> +
>>>>> +    firmware = omap_rproc_get_firmware(pdev);
>>>>> +    if (IS_ERR(firmware))
>>>>> +        return PTR_ERR(firmware);
>>>>>          ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
>>>>>        if (ret) {
>>>>> @@ -188,16 +327,21 @@ static int omap_rproc_probe(struct
>>>>> platform_device *pdev)
>>>>>            return ret;
>>>>>        }
>>>>>    -    rproc = rproc_alloc(&pdev->dev, pdata->name, &omap_rproc_ops,
>>>>> -                pdata->firmware, sizeof(*oproc));
>>>>> +    rproc = rproc_alloc(&pdev->dev, dev_name(&pdev->dev),
>>>>> &omap_rproc_ops,
>>>>> +                firmware, sizeof(*oproc));
>>>>>        if (!rproc)
>>>>>            return -ENOMEM;
>>>>>          oproc = rproc->priv;
>>>>>        oproc->rproc = rproc;
>>>>> +    oproc->reset = reset;
>>>>>        /* All existing OMAP IPU and DSP processors have an MMU */
>>>>>        rproc->has_iommu = true;
>>>>>    +    ret = omap_rproc_get_boot_data(pdev, rproc);
>>>>> +    if (ret)
>>>>> +        goto free_rproc;
>>>>> +
>>>>>        platform_set_drvdata(pdev, rproc);
>>>>>          ret = rproc_add(rproc);
>>>>> @@ -226,6 +370,7 @@ static struct platform_driver omap_rproc_driver
>>>>> = {
>>>>>        .remove = omap_rproc_remove,
>>>>>        .driver = {
>>>>>            .name = "omap-rproc",
>>>>> +        .of_match_table = omap_rproc_of_match,
>>>>
>>>>                   .of_match_table = of_match_ptr(omap_rproc_of_match),
>>
>> I had dropped this sometime back intentionally as all our platforms are
>> DT-only.
> 
> Hmm, dropped what?

Dropped the of_match_ptr.

regards
Suman

> 
> -Tero
> 
>>
>> regards
>> Suman
>>
>>>>
>>>> Thanks,
>>>> Mathieu
>>>>
>>>>>        },
>>>>>    };
>>>>>    --
>>>>> 2.17.1
>>>>>
>>>>> -- 
>>>
>>> -- 
>>
> 
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 12/15] remoteproc/omap: add support for system suspend/resume
  2019-12-20 11:04       ` Tero Kristo
@ 2019-12-20 18:23         ` Suman Anna
  0 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2019-12-20 18:23 UTC (permalink / raw)
  To: Tero Kristo, Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-omap

On 12/20/19 5:04 AM, Tero Kristo wrote:
> On 20/12/2019 05:11, Suman Anna wrote:
>> Hi Mathieu, Tero,
>>
>> On 12/19/19 3:46 PM, Mathieu Poirier wrote:
>>> On Fri, Dec 13, 2019 at 02:55:34PM +0200, Tero Kristo wrote:
>>>> From: Suman Anna <s-anna@ti.com>
>>>>
>>>> This patch adds the support for system suspend/resume to the
>>>> OMAP remoteproc driver so that the OMAP remoteproc devices can
>>>> be suspended/resumed during a system suspend/resume. The support
>>>> is added through the driver PM .suspend/.resume callbacks, and
>>>> requires appropriate support from the OS running on the remote
>>>> processors.
>>>>
>>>> The IPU & DSP remote processors typically have their own private
>>>> modules like registers, internal memories, caches etc. The context
>>>> of these modules need to be saved and restored properly for a
>>>> suspend/resume to work. These are in general not accessible from
>>>> the MPU, so the remote processors themselves have to implement
>>>> the logic for the context save & restore of these modules.
>>>>
>>>> The OMAP remoteproc driver initiates a suspend by sending a mailbox
>>>> message requesting the remote processor to save its context and
>>>> enter into an idle/standby state. The remote processor should
>>>> usually stop whatever processing it is doing to switch to a context
>>>> save mode. The OMAP remoteproc driver detects the completion of
>>>> the context save by checking the module standby status for the
>>>> remoteproc device. It also stops any resources used by the remote
>>>> processors like the timers. The timers need to be running only
>>>> when the processor is active and executing, and need to be stopped
>>>> otherwise to allow the timer driver to reach low-power states. The
>>>> IOMMUs are automatically suspended by the PM core during the late
>>>> suspend stage, after the remoteproc suspend process is completed by
>>>> putting the remote processor cores into reset. Thereafter, the Linux
>>>> kernel can put the domain into further lower power states as possible.
>>>>
>>>> The resume sequence undoes the operations performed in the PM suspend
>>>> callback, by starting the timers and finally releasing the processors
>>>> from reset. This requires that the remote processor side OS be able to
>>>> distinguish a power-resume boot from a power-on/cold boot, restore the
>>>> context of its private modules saved during the suspend phase, and
>>>> resume executing code from where it was suspended. The IOMMUs would
>>>> have been resumed by the PM core during early resume, so they are
>>>> already enabled by the time remoteproc resume callback gets invoked.
>>>>
>>>> The remote processors should save their context into System RAM (DDR),
>>>> as any internal memories are not guaranteed to retain context as it
>>>> depends on the lowest power domain that the remote processor device
>>>> is put into. The management of the DDR contents will be managed by
>>>> the Linux kernel.
>>>>
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>> [t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>>   drivers/remoteproc/omap_remoteproc.c | 179
>>>> +++++++++++++++++++++++++++
>>>>   drivers/remoteproc/omap_remoteproc.h |  18 ++-
>>>>   2 files changed, 195 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/remoteproc/omap_remoteproc.c
>>>> b/drivers/remoteproc/omap_remoteproc.c
>>>> index 9c750c2ab29d..0a9b9f7d20da 100644
>>>> --- a/drivers/remoteproc/omap_remoteproc.c
>>>> +++ b/drivers/remoteproc/omap_remoteproc.c
>>>> @@ -16,6 +16,7 @@
>>>>   #include <linux/kernel.h>
>>>>   #include <linux/module.h>
>>>>   #include <linux/err.h>
>>>> +#include <linux/io.h>
>>>>   #include <linux/of_device.h>
>>>>   #include <linux/of_reserved_mem.h>
>>>>   #include <linux/platform_device.h>
>>>> @@ -23,10 +24,13 @@
>>>>   #include <linux/remoteproc.h>
>>>>   #include <linux/mailbox_client.h>
>>>>   #include <linux/omap-mailbox.h>
>>>> +#include <linux/omap-iommu.h>
>>>
>>> Please move this up by one line.
>>>
>>>>   #include <linux/regmap.h>
>>>>   #include <linux/mfd/syscon.h>
>>>>   #include <linux/reset.h>
>>>>   #include <clocksource/timer-ti-dm.h>
>>>> +#include <linux/clk.h>
>>>> +#include <linux/clk/ti.h>
>>>
>>> Unless there is a dependency with timer-ti-dm.h, these should go just
>>> above linux/err.h
>>
>> No depencencies, can be reordered.
> 
> Will fix these.
> 
>>
>>>
>>>>     #include <linux/platform_data/dmtimer-omap.h>
>>>>   @@ -81,6 +85,9 @@ struct omap_rproc_timer {
>>>>    * @timers: timer(s) info used by rproc
>>>>    * @rproc: rproc handle
>>>>    * @reset: reset handle
>>>> + * @pm_comp: completion primitive to sync for suspend response
>>>> + * @fck: functional clock for the remoteproc
>>>> + * @suspend_acked: state machine flag to store the suspend request ack
>>>>    */
>>>>   struct omap_rproc {
>>>>       struct mbox_chan *mbox;
>>>> @@ -92,6 +99,9 @@ struct omap_rproc {
>>>>       struct omap_rproc_timer *timers;
>>>>       struct rproc *rproc;
>>>>       struct reset_control *reset;
>>>> +    struct completion pm_comp;
>>>> +    struct clk *fck;
>>>> +    bool suspend_acked;
>>>>   };
>>>>     /**
>>>> @@ -349,6 +359,11 @@ static void omap_rproc_mbox_callback(struct
>>>> mbox_client *client, void *data)
>>>>       case RP_MBOX_ECHO_REPLY:
>>>>           dev_info(dev, "received echo reply from %s\n", name);
>>>>           break;
>>>> +    case RP_MBOX_SUSPEND_ACK:
>>>
>>> We can't get away with implicit fallthroughs anymore - please add /*
>>> Fall through */"
> 
> Ok, will do.
> 
>>>
>>>> +    case RP_MBOX_SUSPEND_CANCEL:
>>>> +        oproc->suspend_acked = msg == RP_MBOX_SUSPEND_ACK;
>>>> +        complete(&oproc->pm_comp);
>>>> +        break;
>>>>       default:
>>>>           if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
>>>>               return;
>>>> @@ -529,6 +544,157 @@ static const struct rproc_ops omap_rproc_ops = {
>>>>       .da_to_va    = omap_rproc_da_to_va,
>>>>   };
>>>>   +#ifdef CONFIG_PM
>>>> +static bool _is_rproc_in_standby(struct omap_rproc *oproc)
>>>> +{
>>>> +    return ti_clk_is_in_standby(oproc->fck);
>>>> +}
>>>> +
>>>> +/* 1 sec is long enough time to let the remoteproc side suspend the
>>>> device */
>>>> +#define DEF_SUSPEND_TIMEOUT 1000
>>>> +static int _omap_rproc_suspend(struct rproc *rproc)
>>>> +{
>>>> +    struct device *dev = rproc->dev.parent;
>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>> +    unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
>>>> +    unsigned long ta = jiffies + to;
>>>> +    int ret;
>>>> +
>>>> +    reinit_completion(&oproc->pm_comp);
>>>> +    oproc->suspend_acked = false;
>>>> +    ret = mbox_send_message(oproc->mbox, (void
>>>> *)RP_MBOX_SUSPEND_SYSTEM);
>>>> +    if (ret < 0) {
>>>> +        dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    ret = wait_for_completion_timeout(&oproc->pm_comp, to);
>>>> +    if (!oproc->suspend_acked)
>>>> +        return -EBUSY;
>>>> +
>>>> +    /*
>>>> +     * The remoteproc side is returning the ACK message before
>>>> saving the
>>>> +     * context, because the context saving is performed within a
>>>> SYS/BIOS
>>>> +     * function, and it cannot have any inter-dependencies against
>>>> the IPC
>>>> +     * layer. Also, as the SYS/BIOS needs to preserve properly the
>>>> processor
>>>> +     * register set, sending this ACK or signalling the completion
>>>> of the
>>>> +     * context save through a shared memory variable can never be the
>>>> +     * absolute last thing to be executed on the remoteproc side,
>>>> and the
>>>> +     * MPU cannot use the ACK message as a sync point to put the
>>>> remoteproc
>>>> +     * into reset. The only way to ensure that the remote processor
>>>> has
>>>> +     * completed saving the context is to check that the module has
>>>> reached
>>>> +     * STANDBY state (after saving the context, the SYS/BIOS
>>>> executes the
>>>> +     * appropriate target-specific WFI instruction causing the
>>>> module to
>>>> +     * enter STANDBY).
>>>> +     */
>>>> +    while (!_is_rproc_in_standby(oproc)) {
>>>> +        if (time_after(jiffies, ta))
>>>> +            return -ETIME;
>>>> +        schedule();
>>>> +    }
>>>> +
>>>> +    reset_control_assert(oproc->reset);
>>>> +
>>>> +    ret = omap_rproc_disable_timers(rproc, false);
>>>> +    if (ret) {
>>>> +        dev_err(dev, "disabling timers during suspend failed %d\n",
>>>> +            ret);
>>>> +        goto enable_device;
>>>> +    }
>>>> +
>>>> +    return 0;
>>>> +
>>>> +enable_device:
>>>> +    reset_control_deassert(oproc->reset);
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int _omap_rproc_resume(struct rproc *rproc)
>>>> +{
>>>> +    struct device *dev = rproc->dev.parent;
>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>> +    int ret;
>>>> +
>>>> +    /* boot address could be lost after suspend, so restore it */
>>>> +    if (oproc->boot_data) {
>>>> +        ret = omap_rproc_write_dsp_boot_addr(rproc);
>>>> +        if (ret) {
>>>> +            dev_err(dev, "boot address restore failed %d\n", ret);
>>>> +            goto out;
>>>> +        }
>>>> +    }
>>>> +
>>>> +    ret = omap_rproc_enable_timers(rproc, false);
>>>> +    if (ret) {
>>>> +        dev_err(dev, "enabling timers during resume failed %d\n",
>>>> +            ret);
>>>
>>> The "ret);" fits on the live above.
> 
> Ok, will fix.
> 
>>>
>>>> +        goto out;
>>>> +    }
>>>> +
>>>> +    reset_control_deassert(oproc->reset);
>>>> +
>>>> +out:
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int __maybe_unused omap_rproc_suspend(struct device *dev)
>>>
>>> The "__maybe_unused" can be dropped because this is within the #ifdef
>>> CONFIG_PM
>>> block.
>>
>> These are suspend/resume callbacks, so are actually controlled by
>> CONFIG_PM_SLEEP which can be disabled independently from runtime
>> suspend, and hence the annotation.
> 
> I'll add these two behind CONFIG_PM_SLEEP, in addition to the whole lot
> being behind CONFIG_PM.

AFAIK, the preferred method currently is to use the __may_unused
annotation. The SET_SYSTEM_SLEEP_PM_OPS is under that ifdef and the
compiler is smart enough to drop it when CONFIG_PM_SLEEP is not defined.
So, no need to change this.

regards
Suman

> 
>>
>>>
>>>> +{
>>>> +    struct platform_device *pdev = to_platform_device(dev);
>>>> +    struct rproc *rproc = platform_get_drvdata(pdev);
>>>> +    int ret = 0;
>>>> +
>>>> +    mutex_lock(&rproc->lock);
>>>> +    if (rproc->state == RPROC_OFFLINE)
>>>> +        goto out;
>>>> +
>>>> +    if (rproc->state == RPROC_SUSPENDED)
>>>> +        goto out;
>>>> +
>>>> +    if (rproc->state != RPROC_RUNNING) {
>>>> +        ret = -EBUSY;
>>>> +        goto out;
>>>> +    }
>>>> +
>>>> +    ret = _omap_rproc_suspend(rproc);
>>>> +    if (ret) {
>>>> +        dev_err(dev, "suspend failed %d\n", ret);
>>>> +        goto out;
>>>> +    }
>>>> +
>>>> +    rproc->state = RPROC_SUSPENDED;
>>>> +out:
>>>> +    mutex_unlock(&rproc->lock);
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int __maybe_unused omap_rproc_resume(struct device *dev)
>>>
>>> Same comment as above.
>>>
>>>> +{
>>>> +    struct platform_device *pdev = to_platform_device(dev);
>>>> +    struct rproc *rproc = platform_get_drvdata(pdev);
>>>> +    int ret = 0;
>>>> +
>>>> +    mutex_lock(&rproc->lock);
>>>> +    if (rproc->state == RPROC_OFFLINE)
>>>> +        goto out;
>>>> +
>>>> +    if (rproc->state != RPROC_SUSPENDED) {
>>>> +        ret = -EBUSY;
>>>> +        goto out;
>>>> +    }
>>>> +
>>>> +    ret = _omap_rproc_resume(rproc);
>>>> +    if (ret) {
>>>> +        dev_err(dev, "resume failed %d\n", ret);
>>>> +        goto out;
>>>> +    }
>>>> +
>>>> +    rproc->state = RPROC_RUNNING;
>>>> +out:
>>>> +    mutex_unlock(&rproc->lock);
>>>> +    return ret;
>>>> +}
>>>> +#endif /* CONFIG_PM */
>>>> +
>>>>   static const char * const ipu_mem_names[] = {
>>>>       "l2ram", NULL
>>>>   };
>>>> @@ -786,6 +952,14 @@ static int omap_rproc_probe(struct
>>>> platform_device *pdev)
>>>>               oproc->num_timers);
>>>>       }
>>>>   +    init_completion(&oproc->pm_comp);
>>>> +
>>>> +    oproc->fck = devm_clk_get(&pdev->dev, 0);
>>>> +    if (IS_ERR(oproc->fck)) {
>>>> +        ret = PTR_ERR(oproc->fck);
>>>> +        goto free_rproc;
>>>> +    }
>>>> +
>>>
>>> oproc->fck is not released if an error occurs in
>>> of_reserved_mem_device_init()
>>> and rproc_add().
>>
>> We are using a devres managed API, so why do we need to release it
>> specifically?
> 
> Yea I don't think this is needed.
> 
>>
>>>
>>>>       ret = of_reserved_mem_device_init(&pdev->dev);
>>>>       if (ret) {
>>>>           dev_err(&pdev->dev, "device does not have specific CMA
>>>> pool\n");
>>>> @@ -818,11 +992,16 @@ static int omap_rproc_remove(struct
>>>> platform_device *pdev)
>>>>       return 0;
>>>>   }
>>>>   +static const struct dev_pm_ops omap_rproc_pm_ops = {
>>>> +    SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
>>>> +};
>>>> +
>>>>   static struct platform_driver omap_rproc_driver = {
>>>>       .probe = omap_rproc_probe,
>>>>       .remove = omap_rproc_remove,
>>>>       .driver = {
>>>>           .name = "omap-rproc",
>>>> +        .pm = &omap_rproc_pm_ops,
>>>>           .of_match_table = omap_rproc_of_match,
>>>>       },
>>>>   };
>>>> diff --git a/drivers/remoteproc/omap_remoteproc.h
>>>> b/drivers/remoteproc/omap_remoteproc.h
>>>> index 72f656c93caa..c73383e707c7 100644
>>>> --- a/drivers/remoteproc/omap_remoteproc.h
>>>> +++ b/drivers/remoteproc/omap_remoteproc.h
>>>> @@ -1,7 +1,7 @@
>>>>   /*
>>>>    * Remote processor messaging
>>>>    *
>>>> - * Copyright (C) 2011 Texas Instruments, Inc.
>>>> + * Copyright (C) 2011-2018 Texas Instruments, Inc.
>>
>> %s/2018/2019/
> 
> Yep, will fix.
> 
> -Tero
> 
>>
>> regards
>> Suman
>>
>>>>    * Copyright (C) 2011 Google, Inc.
>>>>    * All rights reserved.
>>>>    *
>>>> @@ -57,6 +57,16 @@
>>>>    * @RP_MBOX_ABORT_REQUEST: a "please crash" request, used for
>>>> testing the
>>>>    * recovery mechanism (to some extent).
>>>>    *
>>>> + * @RP_MBOX_SUSPEND_AUTO: auto suspend request for the remote
>>>> processor
>>>> + *
>>>> + * @RP_MBOX_SUSPEND_SYSTEM: system suspend request for the remote
>>>> processor
>>>> + *
>>>> + * @RP_MBOX_SUSPEND_ACK: successful response from remote processor
>>>> for a
>>>> + * suspend request
>>>> + *
>>>> + * @RP_MBOX_SUSPEND_CANCEL: a cancel suspend response from a remote
>>>> processor
>>>> + * on a suspend request
>>>> + *
>>>>    * Introduce new message definitions if any here.
>>>>    *
>>>>    * @RP_MBOX_END_MSG: Indicates end of known/defined messages from
>>>> remote core
>>>> @@ -70,7 +80,11 @@ enum omap_rp_mbox_messages {
>>>>       RP_MBOX_ECHO_REQUEST    = 0xFFFFFF03,
>>>>       RP_MBOX_ECHO_REPLY    = 0xFFFFFF04,
>>>>       RP_MBOX_ABORT_REQUEST    = 0xFFFFFF05,
>>>> -    RP_MBOX_END_MSG        = 0xFFFFFF06,
>>>> +    RP_MBOX_SUSPEND_AUTO    = 0xFFFFFF10,
>>>> +    RP_MBOX_SUSPEND_SYSTEM    = 0xFFFFFF11,
>>>> +    RP_MBOX_SUSPEND_ACK    = 0xFFFFFF12,
>>>> +    RP_MBOX_SUSPEND_CANCEL    = 0xFFFFFF13,
>>>> +    RP_MBOX_END_MSG        = 0xFFFFFF14,
>>>>   };
>>>>     #endif /* _OMAP_RPMSG_H */
>>>> -- 
>>>> 2.17.1
>>>>
>>>> -- 
>>
> 
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume
  2019-12-20 11:24       ` Tero Kristo
@ 2019-12-20 18:44         ` Suman Anna
  2020-01-02 12:50           ` Tero Kristo
  0 siblings, 1 reply; 50+ messages in thread
From: Suman Anna @ 2019-12-20 18:44 UTC (permalink / raw)
  To: Tero Kristo, Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-omap

On 12/20/19 5:24 AM, Tero Kristo wrote:
> On 20/12/2019 05:24, Suman Anna wrote:
>> Hi Tero,
>>
>> On 12/19/19 5:43 PM, Mathieu Poirier wrote:
>>> On Fri, Dec 13, 2019 at 02:55:35PM +0200, Tero Kristo wrote:
>>>> From: Suman Anna <s-anna@ti.com>
>>>>
>>>> This patch enhances the PM support in the OMAP remoteproc driver to
>>>> support the runtime auto-suspend. A remoteproc may not be required to
>>>> be running all the time, and typically will need to be active only
>>>> during certain usecases. As such, to save power, it should be turned
>>>> off during potential long periods of inactivity between usecases.
>>>> This suspend and resume of the device is a relatively heavy process
>>>> in terms of latencies, so a remoteproc should be suspended only after
>>>> a certain period of prolonged inactivity. The OMAP remoteproc driver
>>>> leverages the runtime pm framework's auto_suspend feature to accomplish
>>>> this functionality. This feature is automatically enabled when a remote
>>>> processor has successfully booted. The 'autosuspend_delay_ms' for each
>>>> device dictates the inactivity period/time to wait for before
>>>> suspending the device.
>>>>
>>>> The runtime auto-suspend design relies on marking the last busy time
>>>> on every communication (virtqueue kick) to and from the remote
>>>> processor.
>>>> When there has been no activity for 'autosuspend_delay_ms' time, the
>>>> runtime PM framework invokes the driver's runtime pm suspend callback
>>>> to suspend the device. The remote processor will be woken up on the
>>>> initiation of the next communication message through the runtime pm
>>>> resume callback. The current auto-suspend design also allows a remote
>>>> processor to deny a auto-suspend attempt, if it wishes to, by sending a
>>>> NACK response to the initial suspend request message sent to the remote
>>>> processor as part of the suspend process. The auto-suspend request is
>>>> also only attempted if the remote processor is idled and in standby at
>>>> the time of inactivity timer expiry. This choice is made to avoid
>>>> unnecessary messaging, and the auto-suspend is simply rescheduled to
>>>> be attempted again after a further lapse of autosuspend_delay_ms.
>>>>
>>>> The runtime pm callbacks functionality in this patch reuses most of the
>>>> core logic from the suspend/resume support code, and make use of an
>>>> additional auto_suspend flag to differentiate the logic in common code
>>>> from system suspend. The system suspend/resume sequences are also
>>>> updated
>>>> to reflect the proper pm_runtime statuses, and also to really perform a
>>>> suspend/resume only if the remoteproc has not been auto-suspended at
>>>> the
>>>> time of request. The remote processor is left in suspended state on a
>>>> system resume if it has been auto-suspended before, and will be
>>>> woken up
>>>> only when a usecase needs to run. The other significant change in this
>>>> patch is to reset the remoteproc device's pm_domain so as to avoid
>>>> conflicts with the ordering sequences in the device pm_domain's runtime
>>>> callbacks and the reset management and clock management implemented
>>>> within the runtime callbacks in the driver.
>>>>
>>>> The OMAP remoteproc driver currently uses a default value of 10 seconds
>>>> for all OMAP remoteprocs, and a different value can be chosen either by
>>>> choosing a positive value for the 'autosuspend_delay' in the device's
>>>> omap_rproc_fw_data in the driver match data or by updating the
>>>> 'autosuspend_delay_ms' field at runtime through the sysfs interface.
>>>>      Eg: To use 25 seconds for IPU2 on DRA7xx,
>>>>        echo 25000 >
>>>> /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms
>>>>
>>>> The runtime suspend feature can also be similarly enabled or
>>>> disabled by
>>>> writing 'auto' or 'on' to the device's 'control' power field. The
>>>> default
>>>> is enabled.
>>>>      Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
>>>>        echo on > /sys/bus/platform/devices/55020000.ipu/power/control
>>>>
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>> [t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>>   drivers/remoteproc/omap_remoteproc.c | 220
>>>> ++++++++++++++++++++++++++-
>>>>   1 file changed, 214 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/remoteproc/omap_remoteproc.c
>>>> b/drivers/remoteproc/omap_remoteproc.c
>>>> index 0a9b9f7d20da..463d6f60947a 100644
>>>> --- a/drivers/remoteproc/omap_remoteproc.c
>>>> +++ b/drivers/remoteproc/omap_remoteproc.c
>>>> @@ -20,6 +20,7 @@
>>>>   #include <linux/of_device.h>
>>>>   #include <linux/of_reserved_mem.h>
>>>>   #include <linux/platform_device.h>
>>>> +#include <linux/pm_runtime.h>
>>>>   #include <linux/dma-mapping.h>
>>>>   #include <linux/remoteproc.h>
>>>>   #include <linux/mailbox_client.h>
>>>> @@ -37,6 +38,9 @@
>>>>   #include "omap_remoteproc.h"
>>>>   #include "remoteproc_internal.h"
>>>>   +/* default auto-suspend delay (ms) */
>>>> +#define DEFAULT_AUTOSUSPEND_DELAY        10000
>>>> +
>>>>   /**
>>>>    * struct omap_rproc_boot_data - boot data structure for the DSP
>>>> omap rprocs
>>>>    * @syscon: regmap handle for the system control configuration module
>>>> @@ -83,6 +87,8 @@ struct omap_rproc_timer {
>>>>    * @num_mems: number of internal memory regions
>>>>    * @num_timers: number of rproc timer(s)
>>>>    * @timers: timer(s) info used by rproc
>>>> + * @autosuspend_delay: auto-suspend delay value to be used for
>>>> runtime pm
>>>> + * @need_resume: if true a resume is needed in the system resume
>>>> callback
>>>>    * @rproc: rproc handle
>>>>    * @reset: reset handle
>>>>    * @pm_comp: completion primitive to sync for suspend response
>>>> @@ -97,6 +103,8 @@ struct omap_rproc {
>>>>       int num_mems;
>>>>       int num_timers;
>>>>       struct omap_rproc_timer *timers;
>>>> +    int autosuspend_delay;
>>>> +    bool need_resume;
>>>>       struct rproc *rproc;
>>>>       struct reset_control *reset;
>>>>       struct completion pm_comp;
>>>> @@ -111,6 +119,7 @@ struct omap_rproc {
>>>>    * @boot_reg_shift: bit shift for the boot register mask
>>>>    * @mem_names: memory names for this remote processor
>>>>    * @dev_addrs: device addresses corresponding to the memory names
>>>> + * @autosuspend_delay: custom auto-suspend delay value in milliseconds
>>>>    */
>>>>   struct omap_rproc_dev_data {
>>>>       const char *device_name;
>>>> @@ -118,6 +127,7 @@ struct omap_rproc_dev_data {
>>>>       int boot_reg_shift;
>>>>       const char * const *mem_names;
>>>>       const u32 *dev_addrs;
>>>> +    int autosuspend_delay;
>>>>   };
>>>>     /**
>>>> @@ -384,11 +394,23 @@ static void omap_rproc_kick(struct rproc
>>>> *rproc, int vqid)
>>>>       struct device *dev = rproc->dev.parent;
>>>>       int ret;
>>>>   +    /* wake up the rproc before kicking it */
>>>> +    ret = pm_runtime_get_sync(dev);
>>>> +    if (WARN_ON(ret < 0)) {
>>>> +        dev_err(dev, "pm_runtime_get_sync() failed during kick, ret
>>>> = %d\n",
>>>> +            ret);
>>>> +        pm_runtime_put_noidle(dev);
>>>> +        return;
>>>> +    }
>>>> +
>>>>       /* send the index of the triggered virtqueue in the mailbox
>>>> payload */
>>>>       ret = mbox_send_message(oproc->mbox, (void *)vqid);
>>>>       if (ret < 0)
>>>>           dev_err(dev, "failed to send mailbox message, status = %d\n",
>>>>               ret);
>>>> +
>>>> +    pm_runtime_mark_last_busy(dev);
>>>> +    pm_runtime_put_autosuspend(dev);
>>>>   }
>>>>     /**
>>>> @@ -473,6 +495,19 @@ static int omap_rproc_start(struct rproc *rproc)
>>>>           goto put_mbox;
>>>>       }
>>>>   +    /*
>>>> +     * remote processor is up, so update the runtime pm status and
>>>> +     * enable the auto-suspend. The device usage count is incremented
>>>> +     * manually for balancing it for auto-suspend
>>>> +     */
>>>> +    pm_runtime_set_active(dev);
>>>> +    pm_runtime_set_autosuspend_delay(dev, oproc->autosuspend_delay);
>>>> +    pm_runtime_use_autosuspend(dev);
>>>> +    pm_runtime_get(dev);
>>>> +    pm_runtime_enable(dev);
>>>> +    pm_runtime_mark_last_busy(dev);
>>>> +    pm_runtime_put_autosuspend(dev);
>>>> +
>>>>       reset_control_deassert(oproc->reset);
>>
>> I see that you have flipped the reset call and all the pm_runtime calls
>> (w.r.t my original code sequence) and pm_runtime_get instead of
>> pm_runtime_get_noresume(). Is there a reason for it? What is the backend
>> that gets exercised with pm_runtime?
> 
> PM runtime nowadays exercises ti-sysc, and we can't deassert reset
> before we enable the clocks for the device. Thus, these are flipped.

But the remoteprocs are not being added under a ti-sysc node from what I
have seen so far, only the MMUs. Even if that were the case, you would
have to actually revise the above pm_runtime call sequences, as
replacing get_noresume() with get() are not equivalent.

> 
> In the old incarnation of this code, PM runtime just exercised the
> hacked up functionality implemented for omap rproc alone.

Ha ha, it hadn't been easy to come up with that carefully crafted to
deal with default hwmod code around reset issues. The logic enabled the
clocking and reset independently while powering up and managed the
pm_runtime status appropriately originally.

> 
>>
>>>>         return 0;
>>>> @@ -485,9 +520,26 @@ static int omap_rproc_start(struct rproc *rproc)
>>>>   /* power off the remote processor */
>>>>   static int omap_rproc_stop(struct rproc *rproc)
>>>>   {
>>>> +    struct device *dev = rproc->dev.parent;
>>>>       struct omap_rproc *oproc = rproc->priv;
>>>>       int ret;
>>>>   +    /*
>>>> +     * cancel any possible scheduled runtime suspend by incrementing
>>>> +     * the device usage count, and resuming the device. The remoteproc
>>>> +     * also needs to be woken up if suspended, to avoid the remoteproc
>>>> +     * OS to continue to remember any context that it has saved, and
>>>> +     * avoid potential issues in misindentifying a subsequent device
>>>> +     * reboot as a power restore boot
>>>> +     */
>>>> +    ret = pm_runtime_get_sync(dev);
>>>> +    if (ret < 0) {
>>>> +        pm_runtime_put_noidle(dev);
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    pm_runtime_put_sync(dev);
>>>> +
>>
>> I didn't have this call either. And get_sync() followed by put_sync() is
>> essentially a no-op. Am I missing something here?
> 
> Hmm right, but you did have the device_shutdown() here, somehow this
> appears to simulate that, but you are right, it is just a no-op. I don't
> know if this code has actually ever done anything useful. Let me
> experiment with this one a bit and see what happens. It looks like it
> should be removed completely.

Yes, I did have the device_shutdown() here (turn off clocks and reset).
The processor had to be woken up before shutting down (see the comments
above the code hunk).

> 
>>
>>>>       reset_control_assert(oproc->reset);

Overall, the previous design relied on get_sync and put_sync calling the
driver's callbacks once started and used regular clock and reset
management outside of those during powering up (first time) and actual
shut down.


>>>>         ret = omap_rproc_disable_timers(rproc, true);
>>>> @@ -496,6 +548,15 @@ static int omap_rproc_stop(struct rproc *rproc)
>>>>         mbox_free_channel(oproc->mbox);
>>>>   +    /*
>>>> +     * update the runtime pm states and status now that the remoteproc
>>>> +     * has stopped
>>>> +     */
>>>> +    pm_runtime_disable(dev);
>>>> +    pm_runtime_dont_use_autosuspend(dev);
>>>> +    pm_runtime_put_noidle(dev);
>>>> +    pm_runtime_set_suspended(dev);
>>>> +
>>>>       return 0;
>>>>   }
>>>>   @@ -552,17 +613,19 @@ static bool _is_rproc_in_standby(struct
>>>> omap_rproc *oproc)
>>>>     /* 1 sec is long enough time to let the remoteproc side suspend
>>>> the device */
>>>>   #define DEF_SUSPEND_TIMEOUT 1000
>>>> -static int _omap_rproc_suspend(struct rproc *rproc)
>>>> +static int _omap_rproc_suspend(struct rproc *rproc, bool auto_suspend)
>>>>   {
>>>>       struct device *dev = rproc->dev.parent;
>>>>       struct omap_rproc *oproc = rproc->priv;
>>>>       unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
>>>>       unsigned long ta = jiffies + to;
>>>> +    u32 suspend_msg = auto_suspend ?
>>>> +                RP_MBOX_SUSPEND_AUTO : RP_MBOX_SUSPEND_SYSTEM;
>>>>       int ret;
>>>>         reinit_completion(&oproc->pm_comp);
>>>>       oproc->suspend_acked = false;
>>>> -    ret = mbox_send_message(oproc->mbox, (void
>>>> *)RP_MBOX_SUSPEND_SYSTEM);
>>>> +    ret = mbox_send_message(oproc->mbox, (void *)suspend_msg);
>>>>       if (ret < 0) {
>>>>           dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
>>>>           return ret;
>>>> @@ -602,25 +665,55 @@ static int _omap_rproc_suspend(struct rproc
>>>> *rproc)
>>>>           goto enable_device;
>>>>       }
>>>>   +    /*
>>>> +     * IOMMUs would have to be disabled specifically for runtime
>>>> suspend.
>>>> +     * They are handled automatically through System PM callbacks for
>>>> +     * regular system suspend
>>>> +     */
>>>> +    if (auto_suspend) {
>>>> +        ret = omap_iommu_domain_deactivate(rproc->domain);
>>>> +        if (ret) {
>>>> +            dev_err(dev, "iommu domain deactivate failed %d\n",
>>>> +                ret);
>>>> +            goto enable_timers;
>>>> +        }
>>>> +    }
>>>> +
>>>>       return 0;
>>
>> blank line here, and remove the one before enable_device.
> 
> Hmm why? I don't think there is any coding guideline that would dictate
> this. However, I'll fix this as this is effectively your file anyways.

Thanks, easier for readability between the success and failure paths.

regards
Suman

> 
> -Tero
> 
>>
>> regards
>> Suman
>>
>>>> +enable_timers:
>>>> +    /* ignore errors on re-enabling code */
>>>> +    omap_rproc_enable_timers(rproc, false);
>>>>     enable_device:
>>>>       reset_control_deassert(oproc->reset);
>>>>       return ret;
>>>>   }
>>>>   -static int _omap_rproc_resume(struct rproc *rproc)
>>>> +static int _omap_rproc_resume(struct rproc *rproc, bool auto_suspend)
>>>>   {
>>>>       struct device *dev = rproc->dev.parent;
>>>>       struct omap_rproc *oproc = rproc->priv;
>>>>       int ret;
>>>>   +    /*
>>>> +     * IOMMUs would have to be enabled specifically for runtime
>>>> resume.
>>>> +     * They would have been already enabled automatically through
>>>> System
>>>> +     * PM callbacks for regular system resume
>>>> +     */
>>>> +    if (auto_suspend) {
>>>> +        ret = omap_iommu_domain_activate(rproc->domain);
>>>> +        if (ret) {
>>>> +            dev_err(dev, "omap_iommu activate failed %d\n", ret);
>>>> +            goto out;
>>>> +        }
>>>> +    }
>>>> +
>>>>       /* boot address could be lost after suspend, so restore it */
>>>>       if (oproc->boot_data) {
>>>>           ret = omap_rproc_write_dsp_boot_addr(rproc);
>>>>           if (ret) {
>>>>               dev_err(dev, "boot address restore failed %d\n", ret);
>>>> -            goto out;
>>>> +            goto suspend_iommu;
>>>
>>> The same needs to be done if omap_rproc_enable_timers() fails.
>>>
>>>>           }
>>>>       }
>>>>   @@ -633,6 +726,12 @@ static int _omap_rproc_resume(struct rproc
>>>> *rproc)
>>>>         reset_control_deassert(oproc->reset);
>>>>   +    return 0;
>>>> +
>>>> +suspend_iommu:
>>>> +    if (auto_suspend)
>>>> +        omap_iommu_domain_deactivate(rproc->domain);
>>>> +
>>>>   out:
>>>>       return ret;
>>>>   }
>>>> @@ -641,6 +740,7 @@ static int __maybe_unused
>>>> omap_rproc_suspend(struct device *dev)
>>>>   {
>>>>       struct platform_device *pdev = to_platform_device(dev);
>>>>       struct rproc *rproc = platform_get_drvdata(pdev);
>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>>       int ret = 0;
>>>>         mutex_lock(&rproc->lock);
>>>> @@ -655,13 +755,25 @@ static int __maybe_unused
>>>> omap_rproc_suspend(struct device *dev)
>>>>           goto out;
>>>>       }
>>>>   -    ret = _omap_rproc_suspend(rproc);
>>>> +    ret = _omap_rproc_suspend(rproc, false);
>>>>       if (ret) {
>>>>           dev_err(dev, "suspend failed %d\n", ret);
>>>>           goto out;
>>>>       }
>>>>   +    /*
>>>> +     * remoteproc is running at the time of system suspend, so
>>>> remember
>>>> +     * it so as to wake it up during system resume
>>>> +     */
>>>> +    oproc->need_resume = 1;
>>>
>>> Please use 'true' to be consistent with the type and
>>> omap_rproc_resume().
>>>
>>>>       rproc->state = RPROC_SUSPENDED;
>>>> +
>>>> +    /*
>>>> +     * update the runtime pm status to be suspended, without
>>>> decrementing
>>>> +     * the device usage count
>>>> +     */
>>>> +    pm_runtime_disable(dev);
>>>> +    pm_runtime_set_suspended(dev);
>>>>   out:
>>>>       mutex_unlock(&rproc->lock);
>>>>       return ret;
>>>> @@ -671,6 +783,7 @@ static int __maybe_unused
>>>> omap_rproc_resume(struct device *dev)
>>>>   {
>>>>       struct platform_device *pdev = to_platform_device(dev);
>>>>       struct rproc *rproc = platform_get_drvdata(pdev);
>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>>       int ret = 0;
>>>>         mutex_lock(&rproc->lock);
>>>> @@ -682,17 +795,91 @@ static int __maybe_unused
>>>> omap_rproc_resume(struct device *dev)
>>>>           goto out;
>>>>       }
>>>>   -    ret = _omap_rproc_resume(rproc);
>>>> +    /*
>>>> +     * remoteproc was auto-suspended at the time of system suspend,
>>>> +     * so no need to wake-up the processor (leave it in suspended
>>>> +     * state, will be woken up during a subsequent runtime_resume)
>>>> +     */
>>>> +    if (!oproc->need_resume)
>>>> +        goto out;
>>>> +
>>>> +    ret = _omap_rproc_resume(rproc, false);
>>>>       if (ret) {
>>>>           dev_err(dev, "resume failed %d\n", ret);
>>>>           goto out;
>>>>       }
>>>> +    oproc->need_resume = false;
>>>>         rproc->state = RPROC_RUNNING;
>>>> +
>>>> +    /*
>>>> +     * update the runtime pm status to be active, without incrementing
>>>> +     * the device usage count
>>>> +     */
>>>> +    pm_runtime_set_active(dev);
>>>> +    pm_runtime_enable(dev);
>>>> +    pm_runtime_mark_last_busy(dev);
>>>>   out:
>>>>       mutex_unlock(&rproc->lock);
>>>>       return ret;
>>>>   }
>>>> +
>>>> +static int omap_rproc_runtime_suspend(struct device *dev)
>>>> +{
>>>> +    struct rproc *rproc = dev_get_drvdata(dev);
>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>> +    int ret;
>>>> +
>>>> +    if (rproc->state == RPROC_CRASHED) {
>>>> +        dev_dbg(dev, "rproc cannot be runtime suspended when
>>>> crashed!\n");
>>>> +        return -EBUSY;
>>>> +    }
>>>> +
>>>> +    if (WARN_ON(rproc->state != RPROC_RUNNING)) {
>>>> +        dev_err(dev, "rproc cannot be runtime suspended when not
>>>> running!\n");
>>>> +        return -EBUSY;
>>>> +    }
>>>> +
>>>> +    /*
>>>> +     * do not even attempt suspend if the remote processor is not
>>>> +     * idled for runtime auto-suspend
>>>> +     */
>>>> +    if (!_is_rproc_in_standby(oproc)) {
>>>> +        ret = -EBUSY;
>>>> +        goto abort;
>>>> +    }
>>>> +
>>>> +    ret = _omap_rproc_suspend(rproc, true);
>>>> +    if (ret)
>>>> +        goto abort;
>>>> +
>>>> +    rproc->state = RPROC_SUSPENDED;
>>>> +    return 0;
>>>> +
>>>> +abort:
>>>> +    pm_runtime_mark_last_busy(dev);
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int omap_rproc_runtime_resume(struct device *dev)
>>>> +{
>>>> +    struct rproc *rproc = dev_get_drvdata(dev);
>>>> +    int ret;
>>>> +
>>>> +    if (WARN_ON(rproc->state != RPROC_SUSPENDED)) {
>>>> +        dev_err(dev, "rproc cannot be runtime resumed if not
>>>> suspended!\n");
>>>> +        return -EBUSY;
>>>> +    }
>>>> +
>>>> +    ret = _omap_rproc_resume(rproc, true);
>>>> +    if (ret) {
>>>> +        dev_err(dev, "runtime resume failed %d\n", ret);
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    rproc->state = RPROC_RUNNING;
>>>> +    return 0;
>>>> +}
>>>>   #endif /* CONFIG_PM */
>>>>     static const char * const ipu_mem_names[] = {
>>>> @@ -778,6 +965,20 @@ static const struct of_device_id
>>>> omap_rproc_of_match[] = {
>>>>   };
>>>>   MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
>>>>   +static int omap_rproc_get_autosuspend_delay(struct
>>>> platform_device *pdev)
>>>> +{
>>>> +    const struct omap_rproc_dev_data *data;
>>>> +    int delay;
>>>> +
>>>> +    data = of_device_get_match_data(&pdev->dev);
>>>> +    if (!data)
>>>> +        return -ENODEV;
>>>
>>> This check is done in omap_rproc_of_get_internal_memories() and
>>> omap_rproc_get_boot_data().  I think it would be best to do it once
>>> at the top
>>> of the probe() function and be done with it.
>>>
>>> That being said and as noted in a previous comment, I would push all
>>> tuneables
>>> to the DT.  If the property is missing then things default to
>>> DEFAULT_AUTOSUSPEND_DELAY.
>>>
>>>> +
>>>> +    delay = data->autosuspend_delay;
>>>> +
>>>> +    return (delay > 0) ? delay : DEFAULT_AUTOSUSPEND_DELAY;
>>>> +}
>>>> +
>>>>   static const char *omap_rproc_get_firmware(struct platform_device
>>>> *pdev)
>>>>   {
>>>>       const char *fw_name;
>>>> @@ -953,6 +1154,11 @@ static int omap_rproc_probe(struct
>>>> platform_device *pdev)
>>>>       }
>>>>         init_completion(&oproc->pm_comp);
>>>> +    oproc->autosuspend_delay = omap_rproc_get_autosuspend_delay(pdev);
>>>> +    if (oproc->autosuspend_delay < 0) {
>>>> +        ret = oproc->autosuspend_delay;
>>>> +        goto free_rproc;
>>>> +    }
>>>>         oproc->fck = devm_clk_get(&pdev->dev, 0);
>>>>       if (IS_ERR(oproc->fck)) {
>>>> @@ -994,6 +1200,8 @@ static int omap_rproc_remove(struct
>>>> platform_device *pdev)
>>>>     static const struct dev_pm_ops omap_rproc_pm_ops = {
>>>>       SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
>>>> +    SET_RUNTIME_PM_OPS(omap_rproc_runtime_suspend,
>>>> +               omap_rproc_runtime_resume, NULL)
>>>>   };
>>>>     static struct platform_driver omap_rproc_driver = {
>>>> -- 
>>>> 2.17.1
>>>>
>>>> -- 
>>
> 
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 12/15] remoteproc/omap: add support for system suspend/resume
  2019-12-20  3:11     ` Suman Anna
  2019-12-20 11:04       ` Tero Kristo
@ 2019-12-20 21:58       ` Mathieu Poirier
  1 sibling, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2019-12-20 21:58 UTC (permalink / raw)
  To: Suman Anna
  Cc: Tero Kristo, Bjorn Andersson, Ohad Ben-Cohen, linux-remoteproc,
	Linux Kernel Mailing List, linux-omap

On Thu, 19 Dec 2019 at 20:11, Suman Anna <s-anna@ti.com> wrote:
>
> Hi Mathieu, Tero,
>
> On 12/19/19 3:46 PM, Mathieu Poirier wrote:
> > On Fri, Dec 13, 2019 at 02:55:34PM +0200, Tero Kristo wrote:
> >> From: Suman Anna <s-anna@ti.com>
> >>
> >> This patch adds the support for system suspend/resume to the
> >> OMAP remoteproc driver so that the OMAP remoteproc devices can
> >> be suspended/resumed during a system suspend/resume. The support
> >> is added through the driver PM .suspend/.resume callbacks, and
> >> requires appropriate support from the OS running on the remote
> >> processors.
> >>
> >> The IPU & DSP remote processors typically have their own private
> >> modules like registers, internal memories, caches etc. The context
> >> of these modules need to be saved and restored properly for a
> >> suspend/resume to work. These are in general not accessible from
> >> the MPU, so the remote processors themselves have to implement
> >> the logic for the context save & restore of these modules.
> >>
> >> The OMAP remoteproc driver initiates a suspend by sending a mailbox
> >> message requesting the remote processor to save its context and
> >> enter into an idle/standby state. The remote processor should
> >> usually stop whatever processing it is doing to switch to a context
> >> save mode. The OMAP remoteproc driver detects the completion of
> >> the context save by checking the module standby status for the
> >> remoteproc device. It also stops any resources used by the remote
> >> processors like the timers. The timers need to be running only
> >> when the processor is active and executing, and need to be stopped
> >> otherwise to allow the timer driver to reach low-power states. The
> >> IOMMUs are automatically suspended by the PM core during the late
> >> suspend stage, after the remoteproc suspend process is completed by
> >> putting the remote processor cores into reset. Thereafter, the Linux
> >> kernel can put the domain into further lower power states as possible.
> >>
> >> The resume sequence undoes the operations performed in the PM suspend
> >> callback, by starting the timers and finally releasing the processors
> >> from reset. This requires that the remote processor side OS be able to
> >> distinguish a power-resume boot from a power-on/cold boot, restore the
> >> context of its private modules saved during the suspend phase, and
> >> resume executing code from where it was suspended. The IOMMUs would
> >> have been resumed by the PM core during early resume, so they are
> >> already enabled by the time remoteproc resume callback gets invoked.
> >>
> >> The remote processors should save their context into System RAM (DDR),
> >> as any internal memories are not guaranteed to retain context as it
> >> depends on the lowest power domain that the remote processor device
> >> is put into. The management of the DDR contents will be managed by
> >> the Linux kernel.
> >>
> >> Signed-off-by: Suman Anna <s-anna@ti.com>
> >> [t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
> >> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> >> ---
> >>  drivers/remoteproc/omap_remoteproc.c | 179 +++++++++++++++++++++++++++
> >>  drivers/remoteproc/omap_remoteproc.h |  18 ++-
> >>  2 files changed, 195 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> >> index 9c750c2ab29d..0a9b9f7d20da 100644
> >> --- a/drivers/remoteproc/omap_remoteproc.c
> >> +++ b/drivers/remoteproc/omap_remoteproc.c
> >> @@ -16,6 +16,7 @@
> >>  #include <linux/kernel.h>
> >>  #include <linux/module.h>
> >>  #include <linux/err.h>
> >> +#include <linux/io.h>
> >>  #include <linux/of_device.h>
> >>  #include <linux/of_reserved_mem.h>
> >>  #include <linux/platform_device.h>
> >> @@ -23,10 +24,13 @@
> >>  #include <linux/remoteproc.h>
> >>  #include <linux/mailbox_client.h>
> >>  #include <linux/omap-mailbox.h>
> >> +#include <linux/omap-iommu.h>
> >
> > Please move this up by one line.
> >
> >>  #include <linux/regmap.h>
> >>  #include <linux/mfd/syscon.h>
> >>  #include <linux/reset.h>
> >>  #include <clocksource/timer-ti-dm.h>
> >> +#include <linux/clk.h>
> >> +#include <linux/clk/ti.h>
> >
> > Unless there is a dependency with timer-ti-dm.h, these should go just above linux/err.h
>
> No depencencies, can be reordered.
>
> >
> >>
> >>  #include <linux/platform_data/dmtimer-omap.h>
> >>
> >> @@ -81,6 +85,9 @@ struct omap_rproc_timer {
> >>   * @timers: timer(s) info used by rproc
> >>   * @rproc: rproc handle
> >>   * @reset: reset handle
> >> + * @pm_comp: completion primitive to sync for suspend response
> >> + * @fck: functional clock for the remoteproc
> >> + * @suspend_acked: state machine flag to store the suspend request ack
> >>   */
> >>  struct omap_rproc {
> >>      struct mbox_chan *mbox;
> >> @@ -92,6 +99,9 @@ struct omap_rproc {
> >>      struct omap_rproc_timer *timers;
> >>      struct rproc *rproc;
> >>      struct reset_control *reset;
> >> +    struct completion pm_comp;
> >> +    struct clk *fck;
> >> +    bool suspend_acked;
> >>  };
> >>
> >>  /**
> >> @@ -349,6 +359,11 @@ static void omap_rproc_mbox_callback(struct mbox_client *client, void *data)
> >>      case RP_MBOX_ECHO_REPLY:
> >>              dev_info(dev, "received echo reply from %s\n", name);
> >>              break;
> >> +    case RP_MBOX_SUSPEND_ACK:
> >
> > We can't get away with implicit fallthroughs anymore - please add /* Fall through */"
> >
> >> +    case RP_MBOX_SUSPEND_CANCEL:
> >> +            oproc->suspend_acked = msg == RP_MBOX_SUSPEND_ACK;
> >> +            complete(&oproc->pm_comp);
> >> +            break;
> >>      default:
> >>              if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
> >>                      return;
> >> @@ -529,6 +544,157 @@ static const struct rproc_ops omap_rproc_ops = {
> >>      .da_to_va       = omap_rproc_da_to_va,
> >>  };
> >>
> >> +#ifdef CONFIG_PM
> >> +static bool _is_rproc_in_standby(struct omap_rproc *oproc)
> >> +{
> >> +    return ti_clk_is_in_standby(oproc->fck);
> >> +}
> >> +
> >> +/* 1 sec is long enough time to let the remoteproc side suspend the device */
> >> +#define DEF_SUSPEND_TIMEOUT 1000
> >> +static int _omap_rproc_suspend(struct rproc *rproc)
> >> +{
> >> +    struct device *dev = rproc->dev.parent;
> >> +    struct omap_rproc *oproc = rproc->priv;
> >> +    unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
> >> +    unsigned long ta = jiffies + to;
> >> +    int ret;
> >> +
> >> +    reinit_completion(&oproc->pm_comp);
> >> +    oproc->suspend_acked = false;
> >> +    ret = mbox_send_message(oproc->mbox, (void *)RP_MBOX_SUSPEND_SYSTEM);
> >> +    if (ret < 0) {
> >> +            dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
> >> +            return ret;
> >> +    }
> >> +
> >> +    ret = wait_for_completion_timeout(&oproc->pm_comp, to);
> >> +    if (!oproc->suspend_acked)
> >> +            return -EBUSY;
> >> +
> >> +    /*
> >> +     * The remoteproc side is returning the ACK message before saving the
> >> +     * context, because the context saving is performed within a SYS/BIOS
> >> +     * function, and it cannot have any inter-dependencies against the IPC
> >> +     * layer. Also, as the SYS/BIOS needs to preserve properly the processor
> >> +     * register set, sending this ACK or signalling the completion of the
> >> +     * context save through a shared memory variable can never be the
> >> +     * absolute last thing to be executed on the remoteproc side, and the
> >> +     * MPU cannot use the ACK message as a sync point to put the remoteproc
> >> +     * into reset. The only way to ensure that the remote processor has
> >> +     * completed saving the context is to check that the module has reached
> >> +     * STANDBY state (after saving the context, the SYS/BIOS executes the
> >> +     * appropriate target-specific WFI instruction causing the module to
> >> +     * enter STANDBY).
> >> +     */
> >> +    while (!_is_rproc_in_standby(oproc)) {
> >> +            if (time_after(jiffies, ta))
> >> +                    return -ETIME;
> >> +            schedule();
> >> +    }
> >> +
> >> +    reset_control_assert(oproc->reset);
> >> +
> >> +    ret = omap_rproc_disable_timers(rproc, false);
> >> +    if (ret) {
> >> +            dev_err(dev, "disabling timers during suspend failed %d\n",
> >> +                    ret);
> >> +            goto enable_device;
> >> +    }
> >> +
> >> +    return 0;
> >> +
> >> +enable_device:
> >> +    reset_control_deassert(oproc->reset);
> >> +    return ret;
> >> +}
> >> +
> >> +static int _omap_rproc_resume(struct rproc *rproc)
> >> +{
> >> +    struct device *dev = rproc->dev.parent;
> >> +    struct omap_rproc *oproc = rproc->priv;
> >> +    int ret;
> >> +
> >> +    /* boot address could be lost after suspend, so restore it */
> >> +    if (oproc->boot_data) {
> >> +            ret = omap_rproc_write_dsp_boot_addr(rproc);
> >> +            if (ret) {
> >> +                    dev_err(dev, "boot address restore failed %d\n", ret);
> >> +                    goto out;
> >> +            }
> >> +    }
> >> +
> >> +    ret = omap_rproc_enable_timers(rproc, false);
> >> +    if (ret) {
> >> +            dev_err(dev, "enabling timers during resume failed %d\n",
> >> +                    ret);
> >
> > The "ret);" fits on the live above.
> >
> >> +            goto out;
> >> +    }
> >> +
> >> +    reset_control_deassert(oproc->reset);
> >> +
> >> +out:
> >> +    return ret;
> >> +}
> >> +
> >> +static int __maybe_unused omap_rproc_suspend(struct device *dev)
> >
> > The "__maybe_unused" can be dropped because this is within the #ifdef CONFIG_PM
> > block.
>
> These are suspend/resume callbacks, so are actually controlled by
> CONFIG_PM_SLEEP which can be disabled independently from runtime
> suspend, and hence the annotation.
>
> >
> >> +{
> >> +    struct platform_device *pdev = to_platform_device(dev);
> >> +    struct rproc *rproc = platform_get_drvdata(pdev);
> >> +    int ret = 0;
> >> +
> >> +    mutex_lock(&rproc->lock);
> >> +    if (rproc->state == RPROC_OFFLINE)
> >> +            goto out;
> >> +
> >> +    if (rproc->state == RPROC_SUSPENDED)
> >> +            goto out;
> >> +
> >> +    if (rproc->state != RPROC_RUNNING) {
> >> +            ret = -EBUSY;
> >> +            goto out;
> >> +    }
> >> +
> >> +    ret = _omap_rproc_suspend(rproc);
> >> +    if (ret) {
> >> +            dev_err(dev, "suspend failed %d\n", ret);
> >> +            goto out;
> >> +    }
> >> +
> >> +    rproc->state = RPROC_SUSPENDED;
> >> +out:
> >> +    mutex_unlock(&rproc->lock);
> >> +    return ret;
> >> +}
> >> +
> >> +static int __maybe_unused omap_rproc_resume(struct device *dev)
> >
> > Same comment as above.
> >
> >> +{
> >> +    struct platform_device *pdev = to_platform_device(dev);
> >> +    struct rproc *rproc = platform_get_drvdata(pdev);
> >> +    int ret = 0;
> >> +
> >> +    mutex_lock(&rproc->lock);
> >> +    if (rproc->state == RPROC_OFFLINE)
> >> +            goto out;
> >> +
> >> +    if (rproc->state != RPROC_SUSPENDED) {
> >> +            ret = -EBUSY;
> >> +            goto out;
> >> +    }
> >> +
> >> +    ret = _omap_rproc_resume(rproc);
> >> +    if (ret) {
> >> +            dev_err(dev, "resume failed %d\n", ret);
> >> +            goto out;
> >> +    }
> >> +
> >> +    rproc->state = RPROC_RUNNING;
> >> +out:
> >> +    mutex_unlock(&rproc->lock);
> >> +    return ret;
> >> +}
> >> +#endif /* CONFIG_PM */
> >> +
> >>  static const char * const ipu_mem_names[] = {
> >>      "l2ram", NULL
> >>  };
> >> @@ -786,6 +952,14 @@ static int omap_rproc_probe(struct platform_device *pdev)
> >>                      oproc->num_timers);
> >>      }
> >>
> >> +    init_completion(&oproc->pm_comp);
> >> +
> >> +    oproc->fck = devm_clk_get(&pdev->dev, 0);
> >> +    if (IS_ERR(oproc->fck)) {
> >> +            ret = PTR_ERR(oproc->fck);
> >> +            goto free_rproc;
> >> +    }
> >> +
> >
> > oproc->fck is not released if an error occurs in of_reserved_mem_device_init()
> > and rproc_add().
>
> We are using a devres managed API, so why do we need to release it
> specifically?

Disregard this comment - I looked at the implementation again and you are right.

>
> >
> >>      ret = of_reserved_mem_device_init(&pdev->dev);
> >>      if (ret) {
> >>              dev_err(&pdev->dev, "device does not have specific CMA pool\n");
> >> @@ -818,11 +992,16 @@ static int omap_rproc_remove(struct platform_device *pdev)
> >>      return 0;
> >>  }
> >>
> >> +static const struct dev_pm_ops omap_rproc_pm_ops = {
> >> +    SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
> >> +};
> >> +
> >>  static struct platform_driver omap_rproc_driver = {
> >>      .probe = omap_rproc_probe,
> >>      .remove = omap_rproc_remove,
> >>      .driver = {
> >>              .name = "omap-rproc",
> >> +            .pm = &omap_rproc_pm_ops,
> >>              .of_match_table = omap_rproc_of_match,
> >>      },
> >>  };
> >> diff --git a/drivers/remoteproc/omap_remoteproc.h b/drivers/remoteproc/omap_remoteproc.h
> >> index 72f656c93caa..c73383e707c7 100644
> >> --- a/drivers/remoteproc/omap_remoteproc.h
> >> +++ b/drivers/remoteproc/omap_remoteproc.h
> >> @@ -1,7 +1,7 @@
> >>  /*
> >>   * Remote processor messaging
> >>   *
> >> - * Copyright (C) 2011 Texas Instruments, Inc.
> >> + * Copyright (C) 2011-2018 Texas Instruments, Inc.
>
> %s/2018/2019/
>
> regards
> Suman
>
> >>   * Copyright (C) 2011 Google, Inc.
> >>   * All rights reserved.
> >>   *
> >> @@ -57,6 +57,16 @@
> >>   * @RP_MBOX_ABORT_REQUEST: a "please crash" request, used for testing the
> >>   * recovery mechanism (to some extent).
> >>   *
> >> + * @RP_MBOX_SUSPEND_AUTO: auto suspend request for the remote processor
> >> + *
> >> + * @RP_MBOX_SUSPEND_SYSTEM: system suspend request for the remote processor
> >> + *
> >> + * @RP_MBOX_SUSPEND_ACK: successful response from remote processor for a
> >> + * suspend request
> >> + *
> >> + * @RP_MBOX_SUSPEND_CANCEL: a cancel suspend response from a remote processor
> >> + * on a suspend request
> >> + *
> >>   * Introduce new message definitions if any here.
> >>   *
> >>   * @RP_MBOX_END_MSG: Indicates end of known/defined messages from remote core
> >> @@ -70,7 +80,11 @@ enum omap_rp_mbox_messages {
> >>      RP_MBOX_ECHO_REQUEST    = 0xFFFFFF03,
> >>      RP_MBOX_ECHO_REPLY      = 0xFFFFFF04,
> >>      RP_MBOX_ABORT_REQUEST   = 0xFFFFFF05,
> >> -    RP_MBOX_END_MSG         = 0xFFFFFF06,
> >> +    RP_MBOX_SUSPEND_AUTO    = 0xFFFFFF10,
> >> +    RP_MBOX_SUSPEND_SYSTEM  = 0xFFFFFF11,
> >> +    RP_MBOX_SUSPEND_ACK     = 0xFFFFFF12,
> >> +    RP_MBOX_SUSPEND_CANCEL  = 0xFFFFFF13,
> >> +    RP_MBOX_END_MSG         = 0xFFFFFF14,
> >>  };
> >>
> >>  #endif /* _OMAP_RPMSG_H */
> >> --
> >> 2.17.1
> >>
> >> --
> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation
  2019-12-20  2:34         ` Suman Anna
@ 2019-12-20 22:15           ` Mathieu Poirier
  0 siblings, 0 replies; 50+ messages in thread
From: Mathieu Poirier @ 2019-12-20 22:15 UTC (permalink / raw)
  To: Suman Anna
  Cc: Tero Kristo, Bjorn Andersson, Ohad Ben-Cohen, linux-remoteproc,
	Linux Kernel Mailing List, linux-omap

On Thu, 19 Dec 2019 at 19:34, Suman Anna <s-anna@ti.com> wrote:
>
> On 12/19/19 6:12 PM, Mathieu Poirier wrote:
> > On Thu, 19 Dec 2019 at 06:18, Tero Kristo <t-kristo@ti.com> wrote:
> >>
> >> On 18/12/2019 02:38, Mathieu Poirier wrote:
> >>> On Fri, Dec 13, 2019 at 02:55:27PM +0200, Tero Kristo wrote:
> >>>> From: Suman Anna <s-anna@ti.com>
> >>>>
> >>>> An implementation for the rproc ops .da_to_va() has been added
> >>>> that provides the address translation between device addresses
> >>>> to kernel virtual addresses for internal RAMs present on that
> >>>> particular remote processor device. The implementation provides
> >>>> the translations based on the addresses parsed and stored during
> >>>> the probe.
> >>>>
> >>>> This ops gets invoked by the exported rproc_da_to_va() function
> >>>> and allows the remoteproc core's ELF loader to be able to load
> >>>> program data directly into the internal memories.
> >>>>
> >>>> Signed-off-by: Suman Anna <s-anna@ti.com>
> >>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> >>>> ---
> >>>>   drivers/remoteproc/omap_remoteproc.c | 39 ++++++++++++++++++++++++++++
> >>>>   1 file changed, 39 insertions(+)
> >>>>
> >>>> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> >>>> index 844703507a74..28f14e24b389 100644
> >>>> --- a/drivers/remoteproc/omap_remoteproc.c
> >>>> +++ b/drivers/remoteproc/omap_remoteproc.c
> >>>> @@ -232,10 +232,49 @@ static int omap_rproc_stop(struct rproc *rproc)
> >>>>      return 0;
> >>>>   }
> >>>>
> >>>> +/**
> >>>> + * omap_rproc_da_to_va() - internal memory translation helper
> >>>> + * @rproc: remote processor to apply the address translation for
> >>>> + * @da: device address to translate
> >>>> + * @len: length of the memory buffer
> >>>> + *
> >>>> + * Custom function implementing the rproc .da_to_va ops to provide address
> >>>> + * translation (device address to kernel virtual address) for internal RAMs
> >>>> + * present in a DSP or IPU device). The translated addresses can be used
> >>>> + * either by the remoteproc core for loading, or by any rpmsg bus drivers.
> >>>> + * Returns the translated virtual address in kernel memory space, or NULL
> >>>> + * in failure.
> >>>> + */
> >>>> +static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> >>>> +{
> >>>> +    struct omap_rproc *oproc = rproc->priv;
> >>>> +    int i;
> >>>> +    u32 offset;
> >>>> +
> >>>> +    if (len <= 0)
> >>>> +            return NULL;
> >>>> +
> >>>> +    if (!oproc->num_mems)
> >>>> +            return NULL;
> >>>> +
> >>>> +    for (i = 0; i < oproc->num_mems; i++) {
> >>>> +            if (da >= oproc->mem[i].dev_addr && da + len <=
> >>>
> >>> Shouldn't this be '<' rather than '<=' ?
> >>
> >> No, I think <= is correct. You need to consider the initial byte in the
> >> range also. Consider a simple case where you provide the exact da + len
> >> corresponding to a specific memory range.
> >
> > For that specific case you are correct.  On the flip side if @da falls
> > somewhere after @mem[i].dev_addr, there is a possibility to clobber
> > the first byte of the next range if <= is used.
>
> Not really, you will miss out on the last byte actually if you use just
> <. This is just address range check, any memcpy would actually end one
> byte before.

I am indeed worried about actual memory accesses but rproc_da_to_va()
is using the same logic as you are when circling through carveouts.
As such you can forget about my comment.

Thanks,
Mathieu

>
> Eg: 0x80000 of len 0x10000. I should perfectly be able to copy 0x1000
> bytes at 0x8f000.
>
> regards
> Suman
>
>
> >
> > Thanks,
> > Mathieu
> >
> >>
> >>>
> >>>> +                oproc->mem[i].dev_addr +  oproc->mem[i].size) {
> >>>
> >>> One space too many after the '+' .
> >>
> >> True, I wonder why checkpatch did not catch this.
> >>
> >>>
> >>>> +                    offset = da -  oproc->mem[i].dev_addr;
> >>>
> >>> One space too many after then '-' .
> >>
> >> Same, will fix these two.
> >>
> >> -Tero
> >>
> >>>
> >>>> +                    /* __force to make sparse happy with type conversion */
> >>>> +                    return (__force void *)(oproc->mem[i].cpu_addr +
> >>>> +                                            offset);
> >>>> +            }
> >>>> +    }
> >>>> +
> >>>> +    return NULL;
> >>>> +}
> >>>> +
> >>>>   static const struct rproc_ops omap_rproc_ops = {
> >>>>      .start          = omap_rproc_start,
> >>>>      .stop           = omap_rproc_stop,
> >>>>      .kick           = omap_rproc_kick,
> >>>> +    .da_to_va       = omap_rproc_da_to_va,
> >>>>   };
> >>>>
> >>>>   static const char * const ipu_mem_names[] = {
> >>>> --
> >>>> 2.17.1
> >>>>
> >>>> --
> >>
> >> --
> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume
  2019-12-20 18:44         ` Suman Anna
@ 2020-01-02 12:50           ` Tero Kristo
  0 siblings, 0 replies; 50+ messages in thread
From: Tero Kristo @ 2020-01-02 12:50 UTC (permalink / raw)
  To: Suman Anna, Mathieu Poirier
  Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-omap

On 20/12/2019 20:44, Suman Anna wrote:
> On 12/20/19 5:24 AM, Tero Kristo wrote:
>> On 20/12/2019 05:24, Suman Anna wrote:
>>> Hi Tero,
>>>
>>> On 12/19/19 5:43 PM, Mathieu Poirier wrote:
>>>> On Fri, Dec 13, 2019 at 02:55:35PM +0200, Tero Kristo wrote:
>>>>> From: Suman Anna <s-anna@ti.com>
>>>>>
>>>>> This patch enhances the PM support in the OMAP remoteproc driver to
>>>>> support the runtime auto-suspend. A remoteproc may not be required to
>>>>> be running all the time, and typically will need to be active only
>>>>> during certain usecases. As such, to save power, it should be turned
>>>>> off during potential long periods of inactivity between usecases.
>>>>> This suspend and resume of the device is a relatively heavy process
>>>>> in terms of latencies, so a remoteproc should be suspended only after
>>>>> a certain period of prolonged inactivity. The OMAP remoteproc driver
>>>>> leverages the runtime pm framework's auto_suspend feature to accomplish
>>>>> this functionality. This feature is automatically enabled when a remote
>>>>> processor has successfully booted. The 'autosuspend_delay_ms' for each
>>>>> device dictates the inactivity period/time to wait for before
>>>>> suspending the device.
>>>>>
>>>>> The runtime auto-suspend design relies on marking the last busy time
>>>>> on every communication (virtqueue kick) to and from the remote
>>>>> processor.
>>>>> When there has been no activity for 'autosuspend_delay_ms' time, the
>>>>> runtime PM framework invokes the driver's runtime pm suspend callback
>>>>> to suspend the device. The remote processor will be woken up on the
>>>>> initiation of the next communication message through the runtime pm
>>>>> resume callback. The current auto-suspend design also allows a remote
>>>>> processor to deny a auto-suspend attempt, if it wishes to, by sending a
>>>>> NACK response to the initial suspend request message sent to the remote
>>>>> processor as part of the suspend process. The auto-suspend request is
>>>>> also only attempted if the remote processor is idled and in standby at
>>>>> the time of inactivity timer expiry. This choice is made to avoid
>>>>> unnecessary messaging, and the auto-suspend is simply rescheduled to
>>>>> be attempted again after a further lapse of autosuspend_delay_ms.
>>>>>
>>>>> The runtime pm callbacks functionality in this patch reuses most of the
>>>>> core logic from the suspend/resume support code, and make use of an
>>>>> additional auto_suspend flag to differentiate the logic in common code
>>>>> from system suspend. The system suspend/resume sequences are also
>>>>> updated
>>>>> to reflect the proper pm_runtime statuses, and also to really perform a
>>>>> suspend/resume only if the remoteproc has not been auto-suspended at
>>>>> the
>>>>> time of request. The remote processor is left in suspended state on a
>>>>> system resume if it has been auto-suspended before, and will be
>>>>> woken up
>>>>> only when a usecase needs to run. The other significant change in this
>>>>> patch is to reset the remoteproc device's pm_domain so as to avoid
>>>>> conflicts with the ordering sequences in the device pm_domain's runtime
>>>>> callbacks and the reset management and clock management implemented
>>>>> within the runtime callbacks in the driver.
>>>>>
>>>>> The OMAP remoteproc driver currently uses a default value of 10 seconds
>>>>> for all OMAP remoteprocs, and a different value can be chosen either by
>>>>> choosing a positive value for the 'autosuspend_delay' in the device's
>>>>> omap_rproc_fw_data in the driver match data or by updating the
>>>>> 'autosuspend_delay_ms' field at runtime through the sysfs interface.
>>>>>       Eg: To use 25 seconds for IPU2 on DRA7xx,
>>>>>         echo 25000 >
>>>>> /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms
>>>>>
>>>>> The runtime suspend feature can also be similarly enabled or
>>>>> disabled by
>>>>> writing 'auto' or 'on' to the device's 'control' power field. The
>>>>> default
>>>>> is enabled.
>>>>>       Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
>>>>>         echo on > /sys/bus/platform/devices/55020000.ipu/power/control
>>>>>
>>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>>> [t-kristo@ti.com: converted to use ti-sysc instead of hwmod]
>>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>>> ---
>>>>>    drivers/remoteproc/omap_remoteproc.c | 220
>>>>> ++++++++++++++++++++++++++-
>>>>>    1 file changed, 214 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/drivers/remoteproc/omap_remoteproc.c
>>>>> b/drivers/remoteproc/omap_remoteproc.c
>>>>> index 0a9b9f7d20da..463d6f60947a 100644
>>>>> --- a/drivers/remoteproc/omap_remoteproc.c
>>>>> +++ b/drivers/remoteproc/omap_remoteproc.c
>>>>> @@ -20,6 +20,7 @@
>>>>>    #include <linux/of_device.h>
>>>>>    #include <linux/of_reserved_mem.h>
>>>>>    #include <linux/platform_device.h>
>>>>> +#include <linux/pm_runtime.h>
>>>>>    #include <linux/dma-mapping.h>
>>>>>    #include <linux/remoteproc.h>
>>>>>    #include <linux/mailbox_client.h>
>>>>> @@ -37,6 +38,9 @@
>>>>>    #include "omap_remoteproc.h"
>>>>>    #include "remoteproc_internal.h"
>>>>>    +/* default auto-suspend delay (ms) */
>>>>> +#define DEFAULT_AUTOSUSPEND_DELAY        10000
>>>>> +
>>>>>    /**
>>>>>     * struct omap_rproc_boot_data - boot data structure for the DSP
>>>>> omap rprocs
>>>>>     * @syscon: regmap handle for the system control configuration module
>>>>> @@ -83,6 +87,8 @@ struct omap_rproc_timer {
>>>>>     * @num_mems: number of internal memory regions
>>>>>     * @num_timers: number of rproc timer(s)
>>>>>     * @timers: timer(s) info used by rproc
>>>>> + * @autosuspend_delay: auto-suspend delay value to be used for
>>>>> runtime pm
>>>>> + * @need_resume: if true a resume is needed in the system resume
>>>>> callback
>>>>>     * @rproc: rproc handle
>>>>>     * @reset: reset handle
>>>>>     * @pm_comp: completion primitive to sync for suspend response
>>>>> @@ -97,6 +103,8 @@ struct omap_rproc {
>>>>>        int num_mems;
>>>>>        int num_timers;
>>>>>        struct omap_rproc_timer *timers;
>>>>> +    int autosuspend_delay;
>>>>> +    bool need_resume;
>>>>>        struct rproc *rproc;
>>>>>        struct reset_control *reset;
>>>>>        struct completion pm_comp;
>>>>> @@ -111,6 +119,7 @@ struct omap_rproc {
>>>>>     * @boot_reg_shift: bit shift for the boot register mask
>>>>>     * @mem_names: memory names for this remote processor
>>>>>     * @dev_addrs: device addresses corresponding to the memory names
>>>>> + * @autosuspend_delay: custom auto-suspend delay value in milliseconds
>>>>>     */
>>>>>    struct omap_rproc_dev_data {
>>>>>        const char *device_name;
>>>>> @@ -118,6 +127,7 @@ struct omap_rproc_dev_data {
>>>>>        int boot_reg_shift;
>>>>>        const char * const *mem_names;
>>>>>        const u32 *dev_addrs;
>>>>> +    int autosuspend_delay;
>>>>>    };
>>>>>      /**
>>>>> @@ -384,11 +394,23 @@ static void omap_rproc_kick(struct rproc
>>>>> *rproc, int vqid)
>>>>>        struct device *dev = rproc->dev.parent;
>>>>>        int ret;
>>>>>    +    /* wake up the rproc before kicking it */
>>>>> +    ret = pm_runtime_get_sync(dev);
>>>>> +    if (WARN_ON(ret < 0)) {
>>>>> +        dev_err(dev, "pm_runtime_get_sync() failed during kick, ret
>>>>> = %d\n",
>>>>> +            ret);
>>>>> +        pm_runtime_put_noidle(dev);
>>>>> +        return;
>>>>> +    }
>>>>> +
>>>>>        /* send the index of the triggered virtqueue in the mailbox
>>>>> payload */
>>>>>        ret = mbox_send_message(oproc->mbox, (void *)vqid);
>>>>>        if (ret < 0)
>>>>>            dev_err(dev, "failed to send mailbox message, status = %d\n",
>>>>>                ret);
>>>>> +
>>>>> +    pm_runtime_mark_last_busy(dev);
>>>>> +    pm_runtime_put_autosuspend(dev);
>>>>>    }
>>>>>      /**
>>>>> @@ -473,6 +495,19 @@ static int omap_rproc_start(struct rproc *rproc)
>>>>>            goto put_mbox;
>>>>>        }
>>>>>    +    /*
>>>>> +     * remote processor is up, so update the runtime pm status and
>>>>> +     * enable the auto-suspend. The device usage count is incremented
>>>>> +     * manually for balancing it for auto-suspend
>>>>> +     */
>>>>> +    pm_runtime_set_active(dev);
>>>>> +    pm_runtime_set_autosuspend_delay(dev, oproc->autosuspend_delay);
>>>>> +    pm_runtime_use_autosuspend(dev);
>>>>> +    pm_runtime_get(dev);
>>>>> +    pm_runtime_enable(dev);
>>>>> +    pm_runtime_mark_last_busy(dev);
>>>>> +    pm_runtime_put_autosuspend(dev);
>>>>> +
>>>>>        reset_control_deassert(oproc->reset);
>>>
>>> I see that you have flipped the reset call and all the pm_runtime calls
>>> (w.r.t my original code sequence) and pm_runtime_get instead of
>>> pm_runtime_get_noresume(). Is there a reason for it? What is the backend
>>> that gets exercised with pm_runtime?
>>
>> PM runtime nowadays exercises ti-sysc, and we can't deassert reset
>> before we enable the clocks for the device. Thus, these are flipped.
> 
> But the remoteprocs are not being added under a ti-sysc node from what I
> have seen so far, only the MMUs. Even if that were the case, you would
> have to actually revise the above pm_runtime call sequences, as
> replacing get_noresume() with get() are not equivalent.

Well yes, but IOMMUs get exercised via the PM runtime calls of the 
remoteproc driver, which effectively enable the clkctrl part.

Anyways, I've done some local cleanup for the PM runtime handling of 
OMAP remoteproc, I'll post v4 shortly.

> 
>>
>> In the old incarnation of this code, PM runtime just exercised the
>> hacked up functionality implemented for omap rproc alone.
> 
> Ha ha, it hadn't been easy to come up with that carefully crafted to
> deal with default hwmod code around reset issues. The logic enabled the
> clocking and reset independently while powering up and managed the
> pm_runtime status appropriately originally.

Yeah, it is not quite that simple yet either, as we have the hard 
dependencies between reset + clkctrl still around... :)

-Tero

> 
>>
>>>
>>>>>          return 0;
>>>>> @@ -485,9 +520,26 @@ static int omap_rproc_start(struct rproc *rproc)
>>>>>    /* power off the remote processor */
>>>>>    static int omap_rproc_stop(struct rproc *rproc)
>>>>>    {
>>>>> +    struct device *dev = rproc->dev.parent;
>>>>>        struct omap_rproc *oproc = rproc->priv;
>>>>>        int ret;
>>>>>    +    /*
>>>>> +     * cancel any possible scheduled runtime suspend by incrementing
>>>>> +     * the device usage count, and resuming the device. The remoteproc
>>>>> +     * also needs to be woken up if suspended, to avoid the remoteproc
>>>>> +     * OS to continue to remember any context that it has saved, and
>>>>> +     * avoid potential issues in misindentifying a subsequent device
>>>>> +     * reboot as a power restore boot
>>>>> +     */
>>>>> +    ret = pm_runtime_get_sync(dev);
>>>>> +    if (ret < 0) {
>>>>> +        pm_runtime_put_noidle(dev);
>>>>> +        return ret;
>>>>> +    }
>>>>> +
>>>>> +    pm_runtime_put_sync(dev);
>>>>> +
>>>
>>> I didn't have this call either. And get_sync() followed by put_sync() is
>>> essentially a no-op. Am I missing something here?
>>
>> Hmm right, but you did have the device_shutdown() here, somehow this
>> appears to simulate that, but you are right, it is just a no-op. I don't
>> know if this code has actually ever done anything useful. Let me
>> experiment with this one a bit and see what happens. It looks like it
>> should be removed completely.
> 
> Yes, I did have the device_shutdown() here (turn off clocks and reset).
> The processor had to be woken up before shutting down (see the comments
> above the code hunk).
> 
>>
>>>
>>>>>        reset_control_assert(oproc->reset);
> 
> Overall, the previous design relied on get_sync and put_sync calling the
> driver's callbacks once started and used regular clock and reset
> management outside of those during powering up (first time) and actual
> shut down.
> 
> 
>>>>>          ret = omap_rproc_disable_timers(rproc, true);
>>>>> @@ -496,6 +548,15 @@ static int omap_rproc_stop(struct rproc *rproc)
>>>>>          mbox_free_channel(oproc->mbox);
>>>>>    +    /*
>>>>> +     * update the runtime pm states and status now that the remoteproc
>>>>> +     * has stopped
>>>>> +     */
>>>>> +    pm_runtime_disable(dev);
>>>>> +    pm_runtime_dont_use_autosuspend(dev);
>>>>> +    pm_runtime_put_noidle(dev);
>>>>> +    pm_runtime_set_suspended(dev);
>>>>> +
>>>>>        return 0;
>>>>>    }
>>>>>    @@ -552,17 +613,19 @@ static bool _is_rproc_in_standby(struct
>>>>> omap_rproc *oproc)
>>>>>      /* 1 sec is long enough time to let the remoteproc side suspend
>>>>> the device */
>>>>>    #define DEF_SUSPEND_TIMEOUT 1000
>>>>> -static int _omap_rproc_suspend(struct rproc *rproc)
>>>>> +static int _omap_rproc_suspend(struct rproc *rproc, bool auto_suspend)
>>>>>    {
>>>>>        struct device *dev = rproc->dev.parent;
>>>>>        struct omap_rproc *oproc = rproc->priv;
>>>>>        unsigned long to = msecs_to_jiffies(DEF_SUSPEND_TIMEOUT);
>>>>>        unsigned long ta = jiffies + to;
>>>>> +    u32 suspend_msg = auto_suspend ?
>>>>> +                RP_MBOX_SUSPEND_AUTO : RP_MBOX_SUSPEND_SYSTEM;
>>>>>        int ret;
>>>>>          reinit_completion(&oproc->pm_comp);
>>>>>        oproc->suspend_acked = false;
>>>>> -    ret = mbox_send_message(oproc->mbox, (void
>>>>> *)RP_MBOX_SUSPEND_SYSTEM);
>>>>> +    ret = mbox_send_message(oproc->mbox, (void *)suspend_msg);
>>>>>        if (ret < 0) {
>>>>>            dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
>>>>>            return ret;
>>>>> @@ -602,25 +665,55 @@ static int _omap_rproc_suspend(struct rproc
>>>>> *rproc)
>>>>>            goto enable_device;
>>>>>        }
>>>>>    +    /*
>>>>> +     * IOMMUs would have to be disabled specifically for runtime
>>>>> suspend.
>>>>> +     * They are handled automatically through System PM callbacks for
>>>>> +     * regular system suspend
>>>>> +     */
>>>>> +    if (auto_suspend) {
>>>>> +        ret = omap_iommu_domain_deactivate(rproc->domain);
>>>>> +        if (ret) {
>>>>> +            dev_err(dev, "iommu domain deactivate failed %d\n",
>>>>> +                ret);
>>>>> +            goto enable_timers;
>>>>> +        }
>>>>> +    }
>>>>> +
>>>>>        return 0;
>>>
>>> blank line here, and remove the one before enable_device.
>>
>> Hmm why? I don't think there is any coding guideline that would dictate
>> this. However, I'll fix this as this is effectively your file anyways.
> 
> Thanks, easier for readability between the success and failure paths.
> 
> regards
> Suman
> 
>>
>> -Tero
>>
>>>
>>> regards
>>> Suman
>>>
>>>>> +enable_timers:
>>>>> +    /* ignore errors on re-enabling code */
>>>>> +    omap_rproc_enable_timers(rproc, false);
>>>>>      enable_device:
>>>>>        reset_control_deassert(oproc->reset);
>>>>>        return ret;
>>>>>    }
>>>>>    -static int _omap_rproc_resume(struct rproc *rproc)
>>>>> +static int _omap_rproc_resume(struct rproc *rproc, bool auto_suspend)
>>>>>    {
>>>>>        struct device *dev = rproc->dev.parent;
>>>>>        struct omap_rproc *oproc = rproc->priv;
>>>>>        int ret;
>>>>>    +    /*
>>>>> +     * IOMMUs would have to be enabled specifically for runtime
>>>>> resume.
>>>>> +     * They would have been already enabled automatically through
>>>>> System
>>>>> +     * PM callbacks for regular system resume
>>>>> +     */
>>>>> +    if (auto_suspend) {
>>>>> +        ret = omap_iommu_domain_activate(rproc->domain);
>>>>> +        if (ret) {
>>>>> +            dev_err(dev, "omap_iommu activate failed %d\n", ret);
>>>>> +            goto out;
>>>>> +        }
>>>>> +    }
>>>>> +
>>>>>        /* boot address could be lost after suspend, so restore it */
>>>>>        if (oproc->boot_data) {
>>>>>            ret = omap_rproc_write_dsp_boot_addr(rproc);
>>>>>            if (ret) {
>>>>>                dev_err(dev, "boot address restore failed %d\n", ret);
>>>>> -            goto out;
>>>>> +            goto suspend_iommu;
>>>>
>>>> The same needs to be done if omap_rproc_enable_timers() fails.
>>>>
>>>>>            }
>>>>>        }
>>>>>    @@ -633,6 +726,12 @@ static int _omap_rproc_resume(struct rproc
>>>>> *rproc)
>>>>>          reset_control_deassert(oproc->reset);
>>>>>    +    return 0;
>>>>> +
>>>>> +suspend_iommu:
>>>>> +    if (auto_suspend)
>>>>> +        omap_iommu_domain_deactivate(rproc->domain);
>>>>> +
>>>>>    out:
>>>>>        return ret;
>>>>>    }
>>>>> @@ -641,6 +740,7 @@ static int __maybe_unused
>>>>> omap_rproc_suspend(struct device *dev)
>>>>>    {
>>>>>        struct platform_device *pdev = to_platform_device(dev);
>>>>>        struct rproc *rproc = platform_get_drvdata(pdev);
>>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>>>        int ret = 0;
>>>>>          mutex_lock(&rproc->lock);
>>>>> @@ -655,13 +755,25 @@ static int __maybe_unused
>>>>> omap_rproc_suspend(struct device *dev)
>>>>>            goto out;
>>>>>        }
>>>>>    -    ret = _omap_rproc_suspend(rproc);
>>>>> +    ret = _omap_rproc_suspend(rproc, false);
>>>>>        if (ret) {
>>>>>            dev_err(dev, "suspend failed %d\n", ret);
>>>>>            goto out;
>>>>>        }
>>>>>    +    /*
>>>>> +     * remoteproc is running at the time of system suspend, so
>>>>> remember
>>>>> +     * it so as to wake it up during system resume
>>>>> +     */
>>>>> +    oproc->need_resume = 1;
>>>>
>>>> Please use 'true' to be consistent with the type and
>>>> omap_rproc_resume().
>>>>
>>>>>        rproc->state = RPROC_SUSPENDED;
>>>>> +
>>>>> +    /*
>>>>> +     * update the runtime pm status to be suspended, without
>>>>> decrementing
>>>>> +     * the device usage count
>>>>> +     */
>>>>> +    pm_runtime_disable(dev);
>>>>> +    pm_runtime_set_suspended(dev);
>>>>>    out:
>>>>>        mutex_unlock(&rproc->lock);
>>>>>        return ret;
>>>>> @@ -671,6 +783,7 @@ static int __maybe_unused
>>>>> omap_rproc_resume(struct device *dev)
>>>>>    {
>>>>>        struct platform_device *pdev = to_platform_device(dev);
>>>>>        struct rproc *rproc = platform_get_drvdata(pdev);
>>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>>>        int ret = 0;
>>>>>          mutex_lock(&rproc->lock);
>>>>> @@ -682,17 +795,91 @@ static int __maybe_unused
>>>>> omap_rproc_resume(struct device *dev)
>>>>>            goto out;
>>>>>        }
>>>>>    -    ret = _omap_rproc_resume(rproc);
>>>>> +    /*
>>>>> +     * remoteproc was auto-suspended at the time of system suspend,
>>>>> +     * so no need to wake-up the processor (leave it in suspended
>>>>> +     * state, will be woken up during a subsequent runtime_resume)
>>>>> +     */
>>>>> +    if (!oproc->need_resume)
>>>>> +        goto out;
>>>>> +
>>>>> +    ret = _omap_rproc_resume(rproc, false);
>>>>>        if (ret) {
>>>>>            dev_err(dev, "resume failed %d\n", ret);
>>>>>            goto out;
>>>>>        }
>>>>> +    oproc->need_resume = false;
>>>>>          rproc->state = RPROC_RUNNING;
>>>>> +
>>>>> +    /*
>>>>> +     * update the runtime pm status to be active, without incrementing
>>>>> +     * the device usage count
>>>>> +     */
>>>>> +    pm_runtime_set_active(dev);
>>>>> +    pm_runtime_enable(dev);
>>>>> +    pm_runtime_mark_last_busy(dev);
>>>>>    out:
>>>>>        mutex_unlock(&rproc->lock);
>>>>>        return ret;
>>>>>    }
>>>>> +
>>>>> +static int omap_rproc_runtime_suspend(struct device *dev)
>>>>> +{
>>>>> +    struct rproc *rproc = dev_get_drvdata(dev);
>>>>> +    struct omap_rproc *oproc = rproc->priv;
>>>>> +    int ret;
>>>>> +
>>>>> +    if (rproc->state == RPROC_CRASHED) {
>>>>> +        dev_dbg(dev, "rproc cannot be runtime suspended when
>>>>> crashed!\n");
>>>>> +        return -EBUSY;
>>>>> +    }
>>>>> +
>>>>> +    if (WARN_ON(rproc->state != RPROC_RUNNING)) {
>>>>> +        dev_err(dev, "rproc cannot be runtime suspended when not
>>>>> running!\n");
>>>>> +        return -EBUSY;
>>>>> +    }
>>>>> +
>>>>> +    /*
>>>>> +     * do not even attempt suspend if the remote processor is not
>>>>> +     * idled for runtime auto-suspend
>>>>> +     */
>>>>> +    if (!_is_rproc_in_standby(oproc)) {
>>>>> +        ret = -EBUSY;
>>>>> +        goto abort;
>>>>> +    }
>>>>> +
>>>>> +    ret = _omap_rproc_suspend(rproc, true);
>>>>> +    if (ret)
>>>>> +        goto abort;
>>>>> +
>>>>> +    rproc->state = RPROC_SUSPENDED;
>>>>> +    return 0;
>>>>> +
>>>>> +abort:
>>>>> +    pm_runtime_mark_last_busy(dev);
>>>>> +    return ret;
>>>>> +}
>>>>> +
>>>>> +static int omap_rproc_runtime_resume(struct device *dev)
>>>>> +{
>>>>> +    struct rproc *rproc = dev_get_drvdata(dev);
>>>>> +    int ret;
>>>>> +
>>>>> +    if (WARN_ON(rproc->state != RPROC_SUSPENDED)) {
>>>>> +        dev_err(dev, "rproc cannot be runtime resumed if not
>>>>> suspended!\n");
>>>>> +        return -EBUSY;
>>>>> +    }
>>>>> +
>>>>> +    ret = _omap_rproc_resume(rproc, true);
>>>>> +    if (ret) {
>>>>> +        dev_err(dev, "runtime resume failed %d\n", ret);
>>>>> +        return ret;
>>>>> +    }
>>>>> +
>>>>> +    rproc->state = RPROC_RUNNING;
>>>>> +    return 0;
>>>>> +}
>>>>>    #endif /* CONFIG_PM */
>>>>>      static const char * const ipu_mem_names[] = {
>>>>> @@ -778,6 +965,20 @@ static const struct of_device_id
>>>>> omap_rproc_of_match[] = {
>>>>>    };
>>>>>    MODULE_DEVICE_TABLE(of, omap_rproc_of_match);
>>>>>    +static int omap_rproc_get_autosuspend_delay(struct
>>>>> platform_device *pdev)
>>>>> +{
>>>>> +    const struct omap_rproc_dev_data *data;
>>>>> +    int delay;
>>>>> +
>>>>> +    data = of_device_get_match_data(&pdev->dev);
>>>>> +    if (!data)
>>>>> +        return -ENODEV;
>>>>
>>>> This check is done in omap_rproc_of_get_internal_memories() and
>>>> omap_rproc_get_boot_data().  I think it would be best to do it once
>>>> at the top
>>>> of the probe() function and be done with it.
>>>>
>>>> That being said and as noted in a previous comment, I would push all
>>>> tuneables
>>>> to the DT.  If the property is missing then things default to
>>>> DEFAULT_AUTOSUSPEND_DELAY.
>>>>
>>>>> +
>>>>> +    delay = data->autosuspend_delay;
>>>>> +
>>>>> +    return (delay > 0) ? delay : DEFAULT_AUTOSUSPEND_DELAY;
>>>>> +}
>>>>> +
>>>>>    static const char *omap_rproc_get_firmware(struct platform_device
>>>>> *pdev)
>>>>>    {
>>>>>        const char *fw_name;
>>>>> @@ -953,6 +1154,11 @@ static int omap_rproc_probe(struct
>>>>> platform_device *pdev)
>>>>>        }
>>>>>          init_completion(&oproc->pm_comp);
>>>>> +    oproc->autosuspend_delay = omap_rproc_get_autosuspend_delay(pdev);
>>>>> +    if (oproc->autosuspend_delay < 0) {
>>>>> +        ret = oproc->autosuspend_delay;
>>>>> +        goto free_rproc;
>>>>> +    }
>>>>>          oproc->fck = devm_clk_get(&pdev->dev, 0);
>>>>>        if (IS_ERR(oproc->fck)) {
>>>>> @@ -994,6 +1200,8 @@ static int omap_rproc_remove(struct
>>>>> platform_device *pdev)
>>>>>      static const struct dev_pm_ops omap_rproc_pm_ops = {
>>>>>        SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
>>>>> +    SET_RUNTIME_PM_OPS(omap_rproc_runtime_suspend,
>>>>> +               omap_rproc_runtime_resume, NULL)
>>>>>    };
>>>>>      static struct platform_driver omap_rproc_driver = {
>>>>> -- 
>>>>> 2.17.1
>>>>>
>>>>> -- 
>>>
>>
>> -- 
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 50+ messages in thread

end of thread, other threads:[~2020-01-02 12:50 UTC | newest]

Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
2019-12-13 12:55 ` [PATCHv3 01/15] dt-bindings: remoteproc: Add OMAP remoteproc bindings Tero Kristo
2019-12-20  3:38   ` Suman Anna
2019-12-13 12:55 ` [PATCHv3 02/15] remoteproc/omap: Add device tree support Tero Kristo
2019-12-17 23:01   ` Mathieu Poirier
2019-12-19 11:54     ` Tero Kristo
2019-12-20  2:08       ` Suman Anna
2019-12-20  9:36         ` Tero Kristo
2019-12-20 18:17           ` Suman Anna
2019-12-13 12:55 ` [PATCHv3 03/15] remoteproc/omap: Add a sanity check for DSP boot address alignment Tero Kristo
2019-12-13 12:55 ` [PATCHv3 04/15] remoteproc/omap: Add support to parse internal memories from DT Tero Kristo
2019-12-18  0:22   ` Mathieu Poirier
2019-12-19 12:31     ` Tero Kristo
2019-12-19 17:37       ` Mathieu Poirier
2019-12-20  2:15         ` Suman Anna
2019-12-13 12:55 ` [PATCHv3 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation Tero Kristo
2019-12-18  0:38   ` Mathieu Poirier
2019-12-19 13:18     ` Tero Kristo
2019-12-20  0:12       ` Mathieu Poirier
2019-12-20  2:34         ` Suman Anna
2019-12-20 22:15           ` Mathieu Poirier
2019-12-13 12:55 ` [PATCHv3 06/15] remoteproc/omap: Initialize and assign reserved memory node Tero Kristo
2019-12-13 12:55 ` [PATCHv3 07/15] remoteproc/omap: Add support for DRA7xx remote processors Tero Kristo
2019-12-18 21:31   ` Mathieu Poirier
2019-12-19 13:29     ` Tero Kristo
2019-12-13 12:55 ` [PATCHv3 08/15] remoteproc/omap: Remove the unused fields from platform data Tero Kristo
2019-12-20  2:44   ` Suman Anna
2019-12-20  9:48     ` Tero Kristo
2019-12-13 12:55 ` [PATCHv3 09/15] remoteproc/omap: Remove the omap_rproc_reserve_cma declaration Tero Kristo
2019-12-20  2:47   ` Suman Anna
2019-12-20  9:49     ` Tero Kristo
2019-12-13 12:55 ` [PATCHv3 10/15] remoteproc/omap: Check for undefined mailbox messages Tero Kristo
2019-12-13 12:55 ` [PATCHv3 11/15] remoteproc/omap: Request a timer(s) for remoteproc usage Tero Kristo
2019-12-18 22:43   ` Mathieu Poirier
2019-12-19 13:43     ` Tero Kristo
2019-12-13 12:55 ` [PATCHv3 12/15] remoteproc/omap: add support for system suspend/resume Tero Kristo
2019-12-19 21:46   ` Mathieu Poirier
2019-12-20  3:11     ` Suman Anna
2019-12-20 11:04       ` Tero Kristo
2019-12-20 18:23         ` Suman Anna
2019-12-20 21:58       ` Mathieu Poirier
2019-12-13 12:55 ` [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume Tero Kristo
2019-12-19 23:43   ` Mathieu Poirier
2019-12-20  3:24     ` Suman Anna
2019-12-20 11:24       ` Tero Kristo
2019-12-20 18:44         ` Suman Anna
2020-01-02 12:50           ` Tero Kristo
2019-12-20 11:08     ` Tero Kristo
2019-12-13 12:55 ` [PATCHv3 14/15] remoteproc/omap: report device exceptions and trigger recovery Tero Kristo
2019-12-13 12:55 ` [PATCHv3 15/15] remoteproc/omap: add watchdog functionality for remote processors Tero Kristo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).