All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suman Anna <s-anna@ti.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Ohad Ben-Cohen <ohad@wizery.com>
Cc: Santosh Shilimkar <ssantosh@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-remoteproc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, Suman Anna <s-anna@ti.com>,
	"Andrew F. Davis" <afd@ti.com>, Sam Nelson <sam.nelson@ti.com>
Subject: [PATCH v2 3/3] remoteproc/keystone: Ensure the DSPs are in reset in probe
Date: Wed, 7 Jun 2017 19:24:47 -0500	[thread overview]
Message-ID: <20170608002447.47580-4-s-anna@ti.com> (raw)
In-Reply-To: <20170608002447.47580-1-s-anna@ti.com>

From: "Andrew F. Davis" <afd@ti.com>

The DSPs are expected to be in reset when the driver probes a device.
If the DSPs are out of reset in probe, the system may crash when the
firmware is being loaded. So, add a check to make sure the DSP resets
are asserted, and if not, throw a eye-catchy warning and assert the
resets specifically.

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: replace warning with a WARN]
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: No code changes

 drivers/remoteproc/keystone_remoteproc.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/remoteproc/keystone_remoteproc.c b/drivers/remoteproc/keystone_remoteproc.c
index 6e09ef76f7c7..5f776bfd674a 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -456,6 +456,16 @@ static int keystone_rproc_probe(struct platform_device *pdev)
 	if (of_reserved_mem_device_init(dev))
 		dev_warn(dev, "device does not have specific CMA pool\n");
 
+	/* ensure the DSP is in reset before loading firmware */
+	ret = reset_control_status(ksproc->reset);
+	if (ret < 0) {
+		dev_err(dev, "failed to get reset status, status = %d\n", ret);
+		goto release_mem;
+	} else if (ret == 0) {
+		WARN(1, "device is not in reset\n");
+		keystone_rproc_dsp_reset(ksproc);
+	}
+
 	ret = rproc_add(rproc);
 	if (ret) {
 		dev_err(dev, "failed to add register device with remoteproc core, status = %d\n",
-- 
2.12.0

WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Ohad Ben-Cohen <ohad@wizery.com>
Cc: Santosh Shilimkar <ssantosh@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	<linux-remoteproc@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Suman Anna <s-anna@ti.com>, "Andrew F. Davis" <afd@ti.com>,
	Sam Nelson <sam.nelson@ti.com>
Subject: [PATCH v2 3/3] remoteproc/keystone: Ensure the DSPs are in reset in probe
Date: Wed, 7 Jun 2017 19:24:47 -0500	[thread overview]
Message-ID: <20170608002447.47580-4-s-anna@ti.com> (raw)
In-Reply-To: <20170608002447.47580-1-s-anna@ti.com>

From: "Andrew F. Davis" <afd@ti.com>

The DSPs are expected to be in reset when the driver probes a device.
If the DSPs are out of reset in probe, the system may crash when the
firmware is being loaded. So, add a check to make sure the DSP resets
are asserted, and if not, throw a eye-catchy warning and assert the
resets specifically.

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: replace warning with a WARN]
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: No code changes

 drivers/remoteproc/keystone_remoteproc.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/remoteproc/keystone_remoteproc.c b/drivers/remoteproc/keystone_remoteproc.c
index 6e09ef76f7c7..5f776bfd674a 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -456,6 +456,16 @@ static int keystone_rproc_probe(struct platform_device *pdev)
 	if (of_reserved_mem_device_init(dev))
 		dev_warn(dev, "device does not have specific CMA pool\n");
 
+	/* ensure the DSP is in reset before loading firmware */
+	ret = reset_control_status(ksproc->reset);
+	if (ret < 0) {
+		dev_err(dev, "failed to get reset status, status = %d\n", ret);
+		goto release_mem;
+	} else if (ret == 0) {
+		WARN(1, "device is not in reset\n");
+		keystone_rproc_dsp_reset(ksproc);
+	}
+
 	ret = rproc_add(rproc);
 	if (ret) {
 		dev_err(dev, "failed to add register device with remoteproc core, status = %d\n",
-- 
2.12.0

WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Ohad Ben-Cohen <ohad@wizery.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org, "Andrew F. Davis" <afd@ti.com>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Sam Nelson <sam.nelson@ti.com>
Subject: [PATCH v2 3/3] remoteproc/keystone: Ensure the DSPs are in reset in probe
Date: Wed, 7 Jun 2017 19:24:47 -0500	[thread overview]
Message-ID: <20170608002447.47580-4-s-anna@ti.com> (raw)
In-Reply-To: <20170608002447.47580-1-s-anna@ti.com>

From: "Andrew F. Davis" <afd@ti.com>

The DSPs are expected to be in reset when the driver probes a device.
If the DSPs are out of reset in probe, the system may crash when the
firmware is being loaded. So, add a check to make sure the DSP resets
are asserted, and if not, throw a eye-catchy warning and assert the
resets specifically.

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: replace warning with a WARN]
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: No code changes

 drivers/remoteproc/keystone_remoteproc.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/remoteproc/keystone_remoteproc.c b/drivers/remoteproc/keystone_remoteproc.c
index 6e09ef76f7c7..5f776bfd674a 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -456,6 +456,16 @@ static int keystone_rproc_probe(struct platform_device *pdev)
 	if (of_reserved_mem_device_init(dev))
 		dev_warn(dev, "device does not have specific CMA pool\n");
 
+	/* ensure the DSP is in reset before loading firmware */
+	ret = reset_control_status(ksproc->reset);
+	if (ret < 0) {
+		dev_err(dev, "failed to get reset status, status = %d\n", ret);
+		goto release_mem;
+	} else if (ret == 0) {
+		WARN(1, "device is not in reset\n");
+		keystone_rproc_dsp_reset(ksproc);
+	}
+
 	ret = rproc_add(rproc);
 	if (ret) {
 		dev_err(dev, "failed to add register device with remoteproc core, status = %d\n",
-- 
2.12.0

WARNING: multiple messages have this Message-ID (diff)
From: s-anna@ti.com (Suman Anna)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/3] remoteproc/keystone: Ensure the DSPs are in reset in probe
Date: Wed, 7 Jun 2017 19:24:47 -0500	[thread overview]
Message-ID: <20170608002447.47580-4-s-anna@ti.com> (raw)
In-Reply-To: <20170608002447.47580-1-s-anna@ti.com>

From: "Andrew F. Davis" <afd@ti.com>

The DSPs are expected to be in reset when the driver probes a device.
If the DSPs are out of reset in probe, the system may crash when the
firmware is being loaded. So, add a check to make sure the DSP resets
are asserted, and if not, throw a eye-catchy warning and assert the
resets specifically.

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna at ti.com: replace warning with a WARN]
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: No code changes

 drivers/remoteproc/keystone_remoteproc.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/remoteproc/keystone_remoteproc.c b/drivers/remoteproc/keystone_remoteproc.c
index 6e09ef76f7c7..5f776bfd674a 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -456,6 +456,16 @@ static int keystone_rproc_probe(struct platform_device *pdev)
 	if (of_reserved_mem_device_init(dev))
 		dev_warn(dev, "device does not have specific CMA pool\n");
 
+	/* ensure the DSP is in reset before loading firmware */
+	ret = reset_control_status(ksproc->reset);
+	if (ret < 0) {
+		dev_err(dev, "failed to get reset status, status = %d\n", ret);
+		goto release_mem;
+	} else if (ret == 0) {
+		WARN(1, "device is not in reset\n");
+		keystone_rproc_dsp_reset(ksproc);
+	}
+
 	ret = rproc_add(rproc);
 	if (ret) {
 		dev_err(dev, "failed to add register device with remoteproc core, status = %d\n",
-- 
2.12.0

  parent reply	other threads:[~2017-06-08  0:24 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08  0:24 [PATCH v2 0/3] Add Keystone2 Remoteproc driver Suman Anna
2017-06-08  0:24 ` Suman Anna
2017-06-08  0:24 ` Suman Anna
2017-06-08  0:24 ` [PATCH v2 1/3] dt-bindings: remoteproc: Add Keystone DSP remoteproc binding Suman Anna
2017-06-08  0:24   ` Suman Anna
2017-06-08  0:24   ` Suman Anna
2017-06-08  0:24   ` Suman Anna
2017-06-09 14:27   ` Rob Herring
2017-06-09 14:27     ` Rob Herring
2017-06-10 19:33   ` Santosh Shilimkar
2017-06-10 19:33     ` Santosh Shilimkar
2017-06-10 19:33     ` Santosh Shilimkar
2017-06-08  0:24 ` [PATCH v2 2/3] remoteproc/keystone: Add a remoteproc driver for Keystone 2 DSPs Suman Anna
2017-06-08  0:24   ` Suman Anna
2017-06-08  0:24   ` Suman Anna
2017-06-10 19:32   ` Santosh Shilimkar
2017-06-10 19:32     ` Santosh Shilimkar
2017-06-10 19:32     ` Santosh Shilimkar
2017-06-08  0:24 ` Suman Anna [this message]
2017-06-08  0:24   ` [PATCH v2 3/3] remoteproc/keystone: Ensure the DSPs are in reset in probe Suman Anna
2017-06-08  0:24   ` Suman Anna
2017-06-08  0:24   ` Suman Anna
2017-06-10 19:32   ` Santosh Shilimkar
2017-06-10 19:32     ` Santosh Shilimkar
2017-06-10 19:32     ` Santosh Shilimkar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170608002447.47580-4-s-anna@ti.com \
    --to=s-anna@ti.com \
    --cc=afd@ti.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ohad@wizery.com \
    --cc=robh+dt@kernel.org \
    --cc=sam.nelson@ti.com \
    --cc=ssantosh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.