* Re: [PATCH v8 02/10] OPP: Add helpers for reading the binding properties
From: Viresh Kumar @ 2020-05-13 6:40 UTC (permalink / raw)
To: Georgi Djakov
Cc: vireshk, nm, sboyd, rjw, saravanak, sibis, mka, robh+dt, rnayak,
bjorn.andersson, vincent.guittot, jcrouse, evgreen, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20200512125327.1868-3-georgi.djakov@linaro.org>
On 12-05-20, 15:53, Georgi Djakov wrote:
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> @@ -558,26 +580,13 @@ static struct dev_pm_opp *_opp_add_static_v2(struct opp_table *opp_table,
> if (!new_opp)
> return ERR_PTR(-ENOMEM);
>
> - ret = of_property_read_u64(np, "opp-hz", &rate);
> - if (ret < 0) {
> - /* "opp-hz" is optional for devices like power domains. */
> - if (!opp_table->is_genpd) {
> - dev_err(dev, "%s: opp-hz not found\n", __func__);
> - goto free_opp;
> - }
> -
> - rate_not_available = true;
> - } else {
> - /*
> - * Rate is defined as an unsigned long in clk API, and so
> - * casting explicitly to its type. Must be fixed once rate is 64
> - * bit guaranteed in clk API.
> - */
> - new_opp->rate = (unsigned long)rate;
> + ret = _read_opp_key(new_opp, np, &rate_not_available);
> + /* The key is optional for devices like power domains. */
Dropped this comment as key isn't optional for genpd as well as you
handled that in a later patch..
> + if (ret < 0 && !opp_table->is_genpd) {
> + dev_err(dev, "%s: opp key field not found\n", __func__);
> + goto free_opp;
> }
--
viresh
^ permalink raw reply
* Re: [PATCH v4 2/2] mailbox: sprd: Add Spreadtrum mailbox driver
From: Baolin Wang @ 2020-05-13 6:32 UTC (permalink / raw)
To: Jassi Brar; +Cc: Rob Herring, Orson Zhai, Chunyan Zhang, Devicetree List, LKML
In-Reply-To: <CABb+yY1gXxpU=q9xKf14uZtJz51kLJ-k2EeWsjnFRyBzR5bmgA@mail.gmail.com>
On Wed, May 13, 2020 at 2:05 PM Jassi Brar <jassisinghbrar@gmail.com> wrote:
>
> On Tue, May 12, 2020 at 11:14 PM Baolin Wang <baolin.wang7@gmail.com> wrote:
> >
> > Hi Jassi,
> >
> > On Thu, May 7, 2020 at 11:23 AM Baolin Wang <baolin.wang7@gmail.com> wrote:
> > >
> > > Hi Jassi,
> > >
> > > On Thu, May 7, 2020 at 7:25 AM Jassi Brar <jassisinghbrar@gmail.com> wrote:
> > > >
> > > > On Wed, May 6, 2020 at 8:29 AM Baolin Wang <baolin.wang7@gmail.com> wrote:
> > > > >
> > > > > Hi Jassi,
> > > > >
> > > > > On Tue, Apr 28, 2020 at 11:10 AM Baolin Wang <baolin.wang7@gmail.com> wrote:
> > > > > >
> > > > > > From: Baolin Wang <baolin.wang@unisoc.com>
> > > > > >
> > > > > > The Spreadtrum mailbox controller supports 8 channels to communicate
> > > > > > with MCUs, and it contains 2 different parts: inbox and outbox, which
> > > > > > are used to send and receive messages by IRQ mode.
> > > > > >
> > > > > > Signed-off-by: Baolin Wang <baolin.wang@unisoc.com>
> > > > > > Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
> > > > > > ---
> > > > > > Changes from v3:
> > > > > > - Save the id in mbox_chan.con_priv and remove the 'sprd_mbox_chan'
> > > > > >
> > > > > > Changes from v2:
> > > > > > - None.
> > > > > >
> > > > > > Changes from v1:
> > > > > > - None
> > > > >
> > > > > Gentle ping, do you have any other comments? Thanks.
> > > > >
> > > > Yea, I am still not sure about the error returned in send_data(). It
> > > > will either never hit or there will be no easy recovery from it. The
> > > > api expects the driver to tell it the last-tx was done only when it
> > > > can send the next message. (There may be case like sending depend on
> > > > remote, which can't be ensured before hand).
> > >
> > > Actually this is an unusual case, suppose the remote target did not
> > > fetch the message as soon as possile, which will cause the FIFO
> > > overflow, so in this case we can not send messages to the remote
> > > target any more, otherwise messages will be lost. Thus we can return
> > > errors to users to indicate that something wrong with the remote
> > > target need to be checked.
> > >
> > > So this validation in send_data() is mostly for debugging for this
> > > abnormal case and we will not trigger this issue if the remote target
> > > works well. So I think it is useful to keep this validation in
> > > send_data(). Thanks.
> >
> > Any comments? Thanks.
> >
> Same as my last post.
I think I've explained the reason why we need add this validation in
my previous email, I am not sure how do you think? You still want to
remove this validation?
--
Baolin Wang
^ permalink raw reply
* Re: [PATCH v7 RESEND 03/13] Revert "dmaengine: imx-sdma: fix context cache"
From: Sascha Hauer @ 2020-05-13 6:05 UTC (permalink / raw)
To: Robin Gong
Cc: vkoul, shawnguo, u.kleine-koenig, robh+dt, festevam,
dan.j.williams, mark.rutland, catalin.marinas, will.deacon,
l.stach, martin.fuzzey, kernel, linux-spi, linux-arm-kernel,
linux-kernel, linux-imx, dmaengine, devicetree
In-Reply-To: <1589218356-17475-4-git-send-email-yibin.gong@nxp.com>
On Tue, May 12, 2020 at 01:32:26AM +0800, Robin Gong wrote:
> This reverts commit d288bddd8374e0a043ac9dde64a1ae6a09411d74, since
> 'context_loaded' finally removed.
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> ---
> drivers/dma/imx-sdma.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 4d4477d..3d4aac9 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -1338,7 +1338,6 @@ static void sdma_free_chan_resources(struct dma_chan *chan)
>
> sdmac->event_id0 = 0;
> sdmac->event_id1 = 0;
> - sdmac->context_loaded = false;
>
> sdma_set_channel_priority(sdmac, 0);
I think this can safely be folded into the next patch which makes it
more clear what is happening.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v7 RESEND 05/13] dmaengine: imx-sdma: remove dupilicated sdma_load_context
From: Sascha Hauer @ 2020-05-13 6:05 UTC (permalink / raw)
To: Robin Gong
Cc: vkoul, shawnguo, u.kleine-koenig, robh+dt, festevam,
dan.j.williams, mark.rutland, catalin.marinas, will.deacon,
l.stach, martin.fuzzey, kernel, linux-spi, linux-arm-kernel,
linux-kernel, linux-imx, dmaengine, devicetree
In-Reply-To: <1589218356-17475-6-git-send-email-yibin.gong@nxp.com>
In the subject: s/dupilicated/duplicated/
Sascha
On Tue, May 12, 2020 at 01:32:28AM +0800, Robin Gong wrote:
> Since sdma_transfer_init() will do sdma_load_context before any
> sdma transfer, no need once more in sdma_config_channel().
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> Acked-by: Vinod Koul <vkoul@kernel.org>
> ---
> drivers/dma/imx-sdma.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 397f11d..69ea44d 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -1137,7 +1137,6 @@ static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
> static int sdma_config_channel(struct dma_chan *chan)
> {
> struct sdma_channel *sdmac = to_sdma_chan(chan);
> - int ret;
>
> sdma_disable_channel(chan);
>
> @@ -1177,9 +1176,7 @@ static int sdma_config_channel(struct dma_chan *chan)
> sdmac->watermark_level = 0; /* FIXME: M3_BASE_ADDRESS */
> }
>
> - ret = sdma_load_context(sdmac);
> -
> - return ret;
> + return 0;
> }
>
> static int sdma_set_channel_priority(struct sdma_channel *sdmac,
> --
> 2.7.4
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v4 2/2] mailbox: sprd: Add Spreadtrum mailbox driver
From: Jassi Brar @ 2020-05-13 6:05 UTC (permalink / raw)
To: Baolin Wang; +Cc: Rob Herring, Orson Zhai, Chunyan Zhang, Devicetree List, LKML
In-Reply-To: <CADBw62oFTV3MPuFQSL0MWyYQWy9MuhL70w5HGHPPV1EXBd3KEQ@mail.gmail.com>
On Tue, May 12, 2020 at 11:14 PM Baolin Wang <baolin.wang7@gmail.com> wrote:
>
> Hi Jassi,
>
> On Thu, May 7, 2020 at 11:23 AM Baolin Wang <baolin.wang7@gmail.com> wrote:
> >
> > Hi Jassi,
> >
> > On Thu, May 7, 2020 at 7:25 AM Jassi Brar <jassisinghbrar@gmail.com> wrote:
> > >
> > > On Wed, May 6, 2020 at 8:29 AM Baolin Wang <baolin.wang7@gmail.com> wrote:
> > > >
> > > > Hi Jassi,
> > > >
> > > > On Tue, Apr 28, 2020 at 11:10 AM Baolin Wang <baolin.wang7@gmail.com> wrote:
> > > > >
> > > > > From: Baolin Wang <baolin.wang@unisoc.com>
> > > > >
> > > > > The Spreadtrum mailbox controller supports 8 channels to communicate
> > > > > with MCUs, and it contains 2 different parts: inbox and outbox, which
> > > > > are used to send and receive messages by IRQ mode.
> > > > >
> > > > > Signed-off-by: Baolin Wang <baolin.wang@unisoc.com>
> > > > > Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
> > > > > ---
> > > > > Changes from v3:
> > > > > - Save the id in mbox_chan.con_priv and remove the 'sprd_mbox_chan'
> > > > >
> > > > > Changes from v2:
> > > > > - None.
> > > > >
> > > > > Changes from v1:
> > > > > - None
> > > >
> > > > Gentle ping, do you have any other comments? Thanks.
> > > >
> > > Yea, I am still not sure about the error returned in send_data(). It
> > > will either never hit or there will be no easy recovery from it. The
> > > api expects the driver to tell it the last-tx was done only when it
> > > can send the next message. (There may be case like sending depend on
> > > remote, which can't be ensured before hand).
> >
> > Actually this is an unusual case, suppose the remote target did not
> > fetch the message as soon as possile, which will cause the FIFO
> > overflow, so in this case we can not send messages to the remote
> > target any more, otherwise messages will be lost. Thus we can return
> > errors to users to indicate that something wrong with the remote
> > target need to be checked.
> >
> > So this validation in send_data() is mostly for debugging for this
> > abnormal case and we will not trigger this issue if the remote target
> > works well. So I think it is useful to keep this validation in
> > send_data(). Thanks.
>
> Any comments? Thanks.
>
Same as my last post.
thnx
^ permalink raw reply
* [PATCH v2] dt-bindings: media: venus: Add an optional power domain for perf voting
From: Rajendra Nayak @ 2020-05-13 6:03 UTC (permalink / raw)
To: stanimir.varbanov, robh+dt, agross, bjorn.andersson
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, mka,
Rajendra Nayak
Add an optional power domain which when specified can be used for
setting the performance state of Venus.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
---
Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml | 6 +++++-
Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
index 764affa..ac1ed64 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
@@ -25,12 +25,16 @@ properties:
maxItems: 1
power-domains:
- maxItems: 2
+ minItems: 2
+ maxItems: 3
power-domain-names:
+ minItems: 2
+ maxItems: 3
items:
- const: venus
- const: vcodec0
+ - const: opp-pd
clocks:
maxItems: 5
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
index 8552f4a..9af78cb 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
@@ -25,13 +25,17 @@ properties:
maxItems: 1
power-domains:
- maxItems: 3
+ minItems: 3
+ maxItems: 4
power-domain-names:
+ minItems: 3
+ maxItems: 4
items:
- const: venus
- const: vcodec0
- const: vcodec1
+ - const: opp-pd
clocks:
maxItems: 7
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v5 4/5] arm64: dts: qcom: qcs404: Add IMEM and PIL info region
From: Bjorn Andersson @ 2020-05-13 5:56 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Ohad Ben-Cohen, Rob Herring
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Stephen Boyd
In-Reply-To: <20200513055641.1413100-1-bjorn.andersson@linaro.org>
Add a simple-mfd representing IMEM on QCS404 and define the PIL
relocation info region, so that post mortem tools will be able to locate
the loaded remoteprocs.
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v4:
- imem is no longer compatible with "syscon"
arch/arm64/boot/dts/qcom/qcs404.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index c685a1664810..b654b802e95c 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -1097,6 +1097,21 @@ blsp2_spi0: spi@7af5000 {
status = "disabled";
};
+ imem@8600000 {
+ compatible = "simple-mfd";
+ reg = <0x08600000 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ranges = <0 0x08600000 0x1000>;
+
+ pil-reloc@94c {
+ compatible = "qcom,pil-reloc-info";
+ reg = <0x94c 0xc8>;
+ };
+ };
+
intc: interrupt-controller@b000000 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
--
2.26.2
^ permalink raw reply related
* [PATCH v5 5/5] arm64: dts: qcom: sdm845: Add IMEM and PIL info region
From: Bjorn Andersson @ 2020-05-13 5:56 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Ohad Ben-Cohen, Rob Herring
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Stephen Boyd
In-Reply-To: <20200513055641.1413100-1-bjorn.andersson@linaro.org>
Add a simple-mfd representing IMEM on SDM845 and define the PIL
relocation info region, so that post mortem tools will be able to locate
the loaded remoteprocs.
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v4:
- imem is no longer compatible with "syscon"
arch/arm64/boot/dts/qcom/sdm845.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 7cce6f1b7c9e..1abbbe7a43a0 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -3716,6 +3716,21 @@ spmi_bus: spmi@c440000 {
cell-index = <0>;
};
+ imem@146bf000 {
+ compatible = "simple-mfd";
+ reg = <0 0x146bf000 0 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ranges = <0 0 0x146bf000 0x1000>;
+
+ pil-reloc@94c {
+ compatible = "qcom,pil-reloc-info";
+ reg = <0x94c 0xc8>;
+ };
+ };
+
apps_smmu: iommu@15000000 {
compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
reg = <0 0x15000000 0 0x80000>;
--
2.26.2
^ permalink raw reply related
* [PATCH v5 3/5] remoteproc: qcom: Update PIL relocation info on load
From: Bjorn Andersson @ 2020-05-13 5:56 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Ohad Ben-Cohen, Rob Herring
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20200513055641.1413100-1-bjorn.andersson@linaro.org>
Update the PIL relocation information in IMEM with information about
where the firmware for various remoteprocs are loaded.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v4:
- Dropped unnecessary comment about ignoring return value.
drivers/remoteproc/Kconfig | 3 +++
drivers/remoteproc/qcom_q6v5_adsp.c | 16 +++++++++++++---
drivers/remoteproc/qcom_q6v5_mss.c | 3 +++
drivers/remoteproc/qcom_q6v5_pas.c | 15 ++++++++++++---
drivers/remoteproc/qcom_q6v5_wcss.c | 14 +++++++++++---
drivers/remoteproc/qcom_wcnss.c | 14 +++++++++++---
6 files changed, 53 insertions(+), 12 deletions(-)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 8088ca4dd6dc..6bd42a411ca8 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -126,6 +126,7 @@ config QCOM_Q6V5_ADSP
depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
depends on QCOM_SYSMON || QCOM_SYSMON=n
select MFD_SYSCON
+ select QCOM_PIL_INFO
select QCOM_MDT_LOADER
select QCOM_Q6V5_COMMON
select QCOM_RPROC_COMMON
@@ -158,6 +159,7 @@ config QCOM_Q6V5_PAS
depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
depends on QCOM_SYSMON || QCOM_SYSMON=n
select MFD_SYSCON
+ select QCOM_PIL_INFO
select QCOM_MDT_LOADER
select QCOM_Q6V5_COMMON
select QCOM_RPROC_COMMON
@@ -209,6 +211,7 @@ config QCOM_WCNSS_PIL
depends on QCOM_SMEM
depends on QCOM_SYSMON || QCOM_SYSMON=n
select QCOM_MDT_LOADER
+ select QCOM_PIL_INFO
select QCOM_RPROC_COMMON
select QCOM_SCM
help
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c b/drivers/remoteproc/qcom_q6v5_adsp.c
index d2a2574dcf35..c539e89664cb 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -26,6 +26,7 @@
#include <linux/soc/qcom/smem_state.h>
#include "qcom_common.h"
+#include "qcom_pil_info.h"
#include "qcom_q6v5.h"
#include "remoteproc_internal.h"
@@ -82,6 +83,7 @@ struct qcom_adsp {
unsigned int halt_lpass;
int crash_reason_smem;
+ const char *info_name;
struct completion start_done;
struct completion stop_done;
@@ -164,10 +166,17 @@ static int qcom_adsp_shutdown(struct qcom_adsp *adsp)
static int adsp_load(struct rproc *rproc, const struct firmware *fw)
{
struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
+ int ret;
+
+ ret = qcom_mdt_load_no_init(adsp->dev, fw, rproc->firmware, 0,
+ adsp->mem_region, adsp->mem_phys,
+ adsp->mem_size, &adsp->mem_reloc);
+ if (ret)
+ return ret;
+
+ qcom_pil_info_store(adsp->info_name, adsp->mem_reloc, adsp->mem_size);
- return qcom_mdt_load_no_init(adsp->dev, fw, rproc->firmware, 0,
- adsp->mem_region, adsp->mem_phys, adsp->mem_size,
- &adsp->mem_reloc);
+ return 0;
}
static int adsp_start(struct rproc *rproc)
@@ -436,6 +445,7 @@ static int adsp_probe(struct platform_device *pdev)
adsp = (struct qcom_adsp *)rproc->priv;
adsp->dev = &pdev->dev;
adsp->rproc = rproc;
+ adsp->info_name = desc->sysmon_name;
platform_set_drvdata(pdev, adsp);
ret = adsp_alloc_memory_region(adsp);
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index c4936f4d1e80..fdbcae11ae64 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -29,6 +29,7 @@
#include "remoteproc_internal.h"
#include "qcom_common.h"
+#include "qcom_pil_info.h"
#include "qcom_q6v5.h"
#include <linux/qcom_scm.h>
@@ -1221,6 +1222,8 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
else if (ret < 0)
dev_err(qproc->dev, "MPSS authentication failed: %d\n", ret);
+ qcom_pil_info_store("modem", mpss_reloc, qproc->mpss_size);
+
release_firmware:
release_firmware(fw);
out:
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index 3bb69f58e086..84cb19231c35 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -25,6 +25,7 @@
#include <linux/soc/qcom/smem_state.h>
#include "qcom_common.h"
+#include "qcom_pil_info.h"
#include "qcom_q6v5.h"
#include "remoteproc_internal.h"
@@ -64,6 +65,7 @@ struct qcom_adsp {
int pas_id;
int crash_reason_smem;
bool has_aggre2_clk;
+ const char *info_name;
struct completion start_done;
struct completion stop_done;
@@ -117,11 +119,17 @@ static void adsp_pds_disable(struct qcom_adsp *adsp, struct device **pds,
static int adsp_load(struct rproc *rproc, const struct firmware *fw)
{
struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
+ int ret;
- return qcom_mdt_load(adsp->dev, fw, rproc->firmware, adsp->pas_id,
- adsp->mem_region, adsp->mem_phys, adsp->mem_size,
- &adsp->mem_reloc);
+ ret = qcom_mdt_load(adsp->dev, fw, rproc->firmware, adsp->pas_id,
+ adsp->mem_region, adsp->mem_phys, adsp->mem_size,
+ &adsp->mem_reloc);
+ if (ret)
+ return ret;
+ qcom_pil_info_store(adsp->info_name, adsp->mem_reloc, adsp->mem_size);
+
+ return 0;
}
static int adsp_start(struct rproc *rproc)
@@ -405,6 +413,7 @@ static int adsp_probe(struct platform_device *pdev)
adsp->rproc = rproc;
adsp->pas_id = desc->pas_id;
adsp->has_aggre2_clk = desc->has_aggre2_clk;
+ adsp->info_name = desc->sysmon_name;
platform_set_drvdata(pdev, adsp);
ret = adsp_alloc_memory_region(adsp);
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c b/drivers/remoteproc/qcom_q6v5_wcss.c
index f1924b740a10..962e37a86b8b 100644
--- a/drivers/remoteproc/qcom_q6v5_wcss.c
+++ b/drivers/remoteproc/qcom_q6v5_wcss.c
@@ -421,10 +421,18 @@ static void *q6v5_wcss_da_to_va(struct rproc *rproc, u64 da, size_t len)
static int q6v5_wcss_load(struct rproc *rproc, const struct firmware *fw)
{
struct q6v5_wcss *wcss = rproc->priv;
+ int ret;
+
+ ret = qcom_mdt_load_no_init(wcss->dev, fw, rproc->firmware,
+ 0, wcss->mem_region, wcss->mem_phys,
+ wcss->mem_size, &wcss->mem_reloc);
+ if (ret)
+ return ret;
+
+ /* Failures only affect post mortem debugging, so ignore return value */
+ qcom_pil_info_store("wcnss", wcss->mem_reloc, wcss->mem_size);
- return qcom_mdt_load_no_init(wcss->dev, fw, rproc->firmware,
- 0, wcss->mem_region, wcss->mem_phys,
- wcss->mem_size, &wcss->mem_reloc);
+ return ret;
}
static const struct rproc_ops q6v5_wcss_ops = {
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index 5d65e1a9329a..229482b3231f 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -27,6 +27,7 @@
#include "qcom_common.h"
#include "remoteproc_internal.h"
+#include "qcom_pil_info.h"
#include "qcom_wcnss.h"
#define WCNSS_CRASH_REASON_SMEM 422
@@ -145,10 +146,17 @@ void qcom_wcnss_assign_iris(struct qcom_wcnss *wcnss,
static int wcnss_load(struct rproc *rproc, const struct firmware *fw)
{
struct qcom_wcnss *wcnss = (struct qcom_wcnss *)rproc->priv;
+ int ret;
+
+ ret = qcom_mdt_load(wcnss->dev, fw, rproc->firmware, WCNSS_PAS_ID,
+ wcnss->mem_region, wcnss->mem_phys,
+ wcnss->mem_size, &wcnss->mem_reloc);
+ if (ret)
+ return ret;
+
+ qcom_pil_info_store("wcnss", wcnss->mem_reloc, wcnss->mem_size);
- return qcom_mdt_load(wcnss->dev, fw, rproc->firmware, WCNSS_PAS_ID,
- wcnss->mem_region, wcnss->mem_phys,
- wcnss->mem_size, &wcnss->mem_reloc);
+ return 0;
}
static void wcnss_indicate_nv_download(struct qcom_wcnss *wcnss)
--
2.26.2
^ permalink raw reply related
* [PATCH v5 2/5] remoteproc: qcom: Introduce helper to store pil info in IMEM
From: Bjorn Andersson @ 2020-05-13 5:56 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Ohad Ben-Cohen, Rob Herring
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20200513055641.1413100-1-bjorn.andersson@linaro.org>
A region in IMEM is used to communicate load addresses of remoteproc to
post mortem debug tools. Implement a helper function that can be used to
store this information in order to enable these tools to process
collected ramdumps.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v4:
- Replaced platform_driver by just a single helper function
- Lazy initialization of mapping
- Cleaned up search loop
- Replaced regmap access of IMEM with ioremap and normal accessors
drivers/remoteproc/Kconfig | 3 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/qcom_pil_info.c | 124 +++++++++++++++++++++++++++++
drivers/remoteproc/qcom_pil_info.h | 7 ++
4 files changed, 135 insertions(+)
create mode 100644 drivers/remoteproc/qcom_pil_info.c
create mode 100644 drivers/remoteproc/qcom_pil_info.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index fbaed079b299..8088ca4dd6dc 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -107,6 +107,9 @@ config KEYSTONE_REMOTEPROC
It's safe to say N here if you're not interested in the Keystone
DSPs or just want to use a bare minimum kernel.
+config QCOM_PIL_INFO
+ tristate
+
config QCOM_RPROC_COMMON
tristate
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 0effd3825035..cc0f631adb3b 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_WKUP_M3_RPROC) += wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
+obj-$(CONFIG_QCOM_PIL_INFO) += qcom_pil_info.o
obj-$(CONFIG_QCOM_RPROC_COMMON) += qcom_common.o
obj-$(CONFIG_QCOM_Q6V5_COMMON) += qcom_q6v5.o
obj-$(CONFIG_QCOM_Q6V5_ADSP) += qcom_q6v5_adsp.o
diff --git a/drivers/remoteproc/qcom_pil_info.c b/drivers/remoteproc/qcom_pil_info.c
new file mode 100644
index 000000000000..0785c7cde2d3
--- /dev/null
+++ b/drivers/remoteproc/qcom_pil_info.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2019-2020 Linaro Ltd.
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of_address.h>
+
+#define PIL_RELOC_NAME_LEN 8
+
+struct pil_reloc_entry {
+ char name[PIL_RELOC_NAME_LEN];
+ __le64 base;
+ __le32 size;
+} __packed;
+
+struct pil_reloc {
+ struct device *dev;
+ void __iomem *base;
+ size_t num_entries;
+};
+
+static struct pil_reloc _reloc __read_mostly;
+static DEFINE_MUTEX(reloc_mutex);
+
+static int qcom_pil_info_init(void)
+{
+ struct device_node *np;
+ struct resource imem;
+ void __iomem *base;
+ int ret;
+
+ /* Already initialized? */
+ if (_reloc.base)
+ return 0;
+
+ np = of_find_compatible_node(NULL, NULL, "qcom,pil-reloc-info");
+ if (!np)
+ return -ENOENT;
+
+ ret = of_address_to_resource(np, 0, &imem);
+ of_node_put(np);
+ if (ret < 0)
+ return ret;
+
+ base = ioremap(imem.start, resource_size(&imem));
+ if (!base) {
+ pr_err("failed to map PIL relocation info region\n");
+ return -ENOMEM;
+ }
+
+ memset_io(base, 0, resource_size(&imem));
+
+ _reloc.base = base;
+ _reloc.num_entries = resource_size(&imem) / sizeof(struct pil_reloc_entry);
+
+ return 0;
+}
+
+/**
+ * qcom_pil_info_store() - store PIL information of image in IMEM
+ * @image: name of the image
+ * @base: base address of the loaded image
+ * @size: size of the loaded image
+ *
+ * Return: 0 on success, negative errno on failure
+ */
+int qcom_pil_info_store(const char *image, phys_addr_t base, size_t size)
+{
+ char buf[PIL_RELOC_NAME_LEN];
+ void __iomem *entry;
+ int ret;
+ int i;
+
+ mutex_lock(&reloc_mutex);
+ ret = qcom_pil_info_init();
+ if (ret < 0) {
+ mutex_unlock(&reloc_mutex);
+ return ret;
+ }
+
+ for (i = 0; i < _reloc.num_entries; i++) {
+ entry = _reloc.base + i * sizeof(struct pil_reloc_entry);
+
+ memcpy_fromio(buf, entry, PIL_RELOC_NAME_LEN);
+
+ /*
+ * An empty record means we didn't find it, given that the
+ * records are packed.
+ */
+ if (!buf[0])
+ goto found_unused;
+
+ if (!strncmp(buf, image, PIL_RELOC_NAME_LEN))
+ goto found_existing;
+ }
+
+ pr_warn("insufficient PIL info slots\n");
+ mutex_unlock(&reloc_mutex);
+ return -ENOMEM;
+
+found_unused:
+ memcpy_toio(entry, image, PIL_RELOC_NAME_LEN);
+found_existing:
+ writel(base, entry + offsetof(struct pil_reloc_entry, base));
+ writel(size, entry + offsetof(struct pil_reloc_entry, size));
+ mutex_unlock(&reloc_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_pil_info_store);
+
+static void __exit pil_reloc_exit(void)
+{
+ mutex_lock(&reloc_mutex);
+ iounmap(_reloc.base);
+ _reloc.base = NULL;
+ mutex_unlock(&reloc_mutex);
+}
+module_exit(pil_reloc_exit);
+
+MODULE_DESCRIPTION("Qualcomm PIL relocation info");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/remoteproc/qcom_pil_info.h b/drivers/remoteproc/qcom_pil_info.h
new file mode 100644
index 000000000000..1b89a63ba82f
--- /dev/null
+++ b/drivers/remoteproc/qcom_pil_info.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __QCOM_PIL_INFO_H__
+#define __QCOM_PIL_INFO_H__
+
+int qcom_pil_info_store(const char *image, phys_addr_t base, size_t size);
+
+#endif
--
2.26.2
^ permalink raw reply related
* [PATCH v5 1/5] dt-bindings: remoteproc: Add Qualcomm PIL info binding
From: Bjorn Andersson @ 2020-05-13 5:56 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Ohad Ben-Cohen, Rob Herring
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Stephen Boyd
In-Reply-To: <20200513055641.1413100-1-bjorn.andersson@linaro.org>
Add a devicetree binding for the Qualcomm peripheral image loader
relocation information region found in the IMEM.
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v4:
- Fixed reg in example to make it compile
.../bindings/remoteproc/qcom,pil-info.yaml | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
new file mode 100644
index 000000000000..87c52316ddbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,pil-info.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm peripheral image loader relocation info binding
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description:
+ The Qualcomm peripheral image loader relocation memory region, in IMEM, is
+ used for communicating remoteproc relocation information to post mortem
+ debugging tools.
+
+properties:
+ compatible:
+ const: qcom,pil-reloc-info
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ imem@146bf000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x146bf000 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ranges = <0 0x146bf000 0x1000>;
+
+ pil-reloc@94c {
+ compatible = "qcom,pil-reloc-info";
+ reg = <0x94c 0xc8>;
+ };
+ };
+...
--
2.26.2
^ permalink raw reply related
* [PATCH v5 0/5] remoteproc: qcom: PIL info support
From: Bjorn Andersson @ 2020-05-13 5:56 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Ohad Ben-Cohen, Rob Herring
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
Introduce support for filling out the relocation information in IMEM, to aid
post mortem debug tools to locate the various remoteprocs.
Bjorn Andersson (5):
dt-bindings: remoteproc: Add Qualcomm PIL info binding
remoteproc: qcom: Introduce helper to store pil info in IMEM
remoteproc: qcom: Update PIL relocation info on load
arm64: dts: qcom: qcs404: Add IMEM and PIL info region
arm64: dts: qcom: sdm845: Add IMEM and PIL info region
.../bindings/remoteproc/qcom,pil-info.yaml | 44 +++++++
arch/arm64/boot/dts/qcom/qcs404.dtsi | 15 +++
arch/arm64/boot/dts/qcom/sdm845.dtsi | 15 +++
drivers/remoteproc/Kconfig | 6 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/qcom_pil_info.c | 124 ++++++++++++++++++
drivers/remoteproc/qcom_pil_info.h | 7 +
drivers/remoteproc/qcom_q6v5_adsp.c | 16 ++-
drivers/remoteproc/qcom_q6v5_mss.c | 3 +
drivers/remoteproc/qcom_q6v5_pas.c | 15 ++-
drivers/remoteproc/qcom_q6v5_wcss.c | 14 +-
drivers/remoteproc/qcom_wcnss.c | 14 +-
12 files changed, 262 insertions(+), 12 deletions(-)
create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
create mode 100644 drivers/remoteproc/qcom_pil_info.c
create mode 100644 drivers/remoteproc/qcom_pil_info.h
--
2.26.2
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: i2c-stm32: add SMBus Alert bindings
From: Alain Volmat @ 2020-05-13 5:42 UTC (permalink / raw)
To: Rob Herring
Cc: wsa@kernel.org, mark.rutland@arm.com, Pierre Yves MORDRET,
mcoquelin.stm32@gmail.com, Alexandre TORGUE,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Fabrice GASNIER
In-Reply-To: <20200513021932.GA9172@bogus>
Hello Rob,
On Wed, May 13, 2020 at 02:19:32AM +0000, Rob Herring wrote:
> On Tue, May 05, 2020 at 07:51:10AM +0200, Alain Volmat wrote:
> > Add a new binding of the i2c-stm32f7 driver to enable the handling
> > of the SMBUS-Alert
> >
> > Signed-off-by: Alain Volmat <alain.volmat@st.com>
> > ---
> > Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
> > index b50a2f420b36..04c0882c3661 100644
> > --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
> > +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
> > @@ -36,6 +36,10 @@ allOf:
> > minItems: 3
> > maxItems: 3
> >
> > + st,smbus-alert:
> > + description: Enable the SMBus Alert feature
> > + $ref: /schemas/types.yaml#/definitions/flag
> > +
>
> We already have smbus_alert interrupt. Can't you just check for this in
> the slave nodes and enable if found?
My understanding reading the code (smbalert_probe within i2c-smbus.c, of_i2c_setup_smbus_alert called when
registering an adapter within i2c-core-smbus.c) is that smbus_alert refers to an interrupt on the
adapter side. That is an interrupt that would be triggered when the adapter is receiving an smbus_alert
message.
In our case (stm32f7), we do not have specific interrupt for that purpose. The interrupt triggered when
an SMBUS Alert is received (by the adapter) is the same interrupt as for other reasons and we check
within the irq handler within stm32f7 the reason before calling i2c_handle_smbus_alert if the status
register indicated an SMBUS Alert.
So my understanding is that we cannot rely on the mechanism of naming an interrupt smbus_alert.
Did I misunderstood something ?
>
> > - if:
> > properties:
> > compatible:
> > --
> > 2.17.1
> >
^ permalink raw reply
* [PATCH] dt-bindings: watchdog: Convert UniPhier watchdog timer to json-schema
From: Kunihiko Hayashi @ 2020-05-13 5:42 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Masahiro Yamada,
Keiji Hayashibara
Cc: linux-watchdog, devicetree, linux-arm-kernel, linux-kernel,
Kunihiko Hayashi
Convert UniPhier watchdog timer binding to DT schema format.
Cc: Keiji Hayashibara <hayashibara.keiji@socionext.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
.../bindings/watchdog/socionext,uniphier-wdt.yaml | 36 ++++++++++++++++++++++
.../devicetree/bindings/watchdog/uniphier-wdt.txt | 20 ------------
2 files changed, 36 insertions(+), 20 deletions(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml
delete mode 100644 Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml
new file mode 100644
index 0000000..a059d16
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/socionext,uniphier-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier watchdog timer
+
+maintainers:
+ - Keiji Hayashibara <hayashibara.keiji@socionext.com>
+
+allOf:
+ - $ref: "watchdog.yaml#"
+
+properties:
+ compatible:
+ const: socionext,uniphier-wdt
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ // The UniPhier watchdog should be a subnode of a "syscon" compatible node.
+
+ sysctrl@61840000 {
+ compatible = "socionext,uniphier-ld11-sysctrl",
+ "simple-mfd", "syscon";
+ reg = <0x61840000 0x10000>;
+
+ watchdog {
+ compatible = "socionext,uniphier-wdt";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt b/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
deleted file mode 100644
index bf63375..0000000
--- a/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-UniPhier watchdog timer controller
-
-This UniPhier watchdog timer controller must be under sysctrl node.
-
-Required properties:
-- compatible: should be "socionext,uniphier-wdt"
-
-Example:
-
- sysctrl@61840000 {
- compatible = "socionext,uniphier-ld11-sysctrl",
- "simple-mfd", "syscon";
- reg = <0x61840000 0x4000>;
-
- watchdog {
- compatible = "socionext,uniphier-wdt";
- }
-
- other nodes ...
- };
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 2/2] mailbox: sprd: Add Spreadtrum mailbox driver
From: Baolin Wang @ 2020-05-13 4:13 UTC (permalink / raw)
To: Jassi Brar; +Cc: Rob Herring, Orson Zhai, Chunyan Zhang, Devicetree List, LKML
In-Reply-To: <CADBw62rrQ=Po76qpJoUj1za9Hg=T+=eEJf=Yv3UmLFLtRZvwsg@mail.gmail.com>
Hi Jassi,
On Thu, May 7, 2020 at 11:23 AM Baolin Wang <baolin.wang7@gmail.com> wrote:
>
> Hi Jassi,
>
> On Thu, May 7, 2020 at 7:25 AM Jassi Brar <jassisinghbrar@gmail.com> wrote:
> >
> > On Wed, May 6, 2020 at 8:29 AM Baolin Wang <baolin.wang7@gmail.com> wrote:
> > >
> > > Hi Jassi,
> > >
> > > On Tue, Apr 28, 2020 at 11:10 AM Baolin Wang <baolin.wang7@gmail.com> wrote:
> > > >
> > > > From: Baolin Wang <baolin.wang@unisoc.com>
> > > >
> > > > The Spreadtrum mailbox controller supports 8 channels to communicate
> > > > with MCUs, and it contains 2 different parts: inbox and outbox, which
> > > > are used to send and receive messages by IRQ mode.
> > > >
> > > > Signed-off-by: Baolin Wang <baolin.wang@unisoc.com>
> > > > Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
> > > > ---
> > > > Changes from v3:
> > > > - Save the id in mbox_chan.con_priv and remove the 'sprd_mbox_chan'
> > > >
> > > > Changes from v2:
> > > > - None.
> > > >
> > > > Changes from v1:
> > > > - None
> > >
> > > Gentle ping, do you have any other comments? Thanks.
> > >
> > Yea, I am still not sure about the error returned in send_data(). It
> > will either never hit or there will be no easy recovery from it. The
> > api expects the driver to tell it the last-tx was done only when it
> > can send the next message. (There may be case like sending depend on
> > remote, which can't be ensured before hand).
>
> Actually this is an unusual case, suppose the remote target did not
> fetch the message as soon as possile, which will cause the FIFO
> overflow, so in this case we can not send messages to the remote
> target any more, otherwise messages will be lost. Thus we can return
> errors to users to indicate that something wrong with the remote
> target need to be checked.
>
> So this validation in send_data() is mostly for debugging for this
> abnormal case and we will not trigger this issue if the remote target
> works well. So I think it is useful to keep this validation in
> send_data(). Thanks.
Any comments? Thanks.
--
Baolin Wang
^ permalink raw reply
* Re: [PATCH 3/4] hwspinlock: qcom: Allow mmio usage in addition to syscon
From: Baolin Wang @ 2020-05-13 3:57 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Ohad Ben-Cohen, Rob Herring, linux-arm-msm,
linux-remoteproc, Devicetree List, LKML
In-Reply-To: <20200513005441.1102586-4-bjorn.andersson@linaro.org>
On Wed, May 13, 2020 at 8:55 AM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> In all modern Qualcomm platforms the mutex region of the TCSR is forked
> off into its own block, all with a offset of 0 and stride of 4096. So
> add support for directly memory mapping this register space, to avoid
> the need to represent this block using a syscon.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> drivers/hwspinlock/qcom_hwspinlock.c | 72 +++++++++++++++++++++-------
> 1 file changed, 56 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/hwspinlock/qcom_hwspinlock.c b/drivers/hwspinlock/qcom_hwspinlock.c
> index f0da544b14d2..d8d4d729816c 100644
> --- a/drivers/hwspinlock/qcom_hwspinlock.c
> +++ b/drivers/hwspinlock/qcom_hwspinlock.c
> @@ -70,41 +70,81 @@ static const struct of_device_id qcom_hwspinlock_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, qcom_hwspinlock_of_match);
>
> -static int qcom_hwspinlock_probe(struct platform_device *pdev)
> +static struct regmap *qcom_hwspinlock_probe_syscon(struct platform_device *pdev,
> + u32 *base, u32 *stride)
> {
> - struct hwspinlock_device *bank;
> struct device_node *syscon;
> - struct reg_field field;
> struct regmap *regmap;
> - size_t array_size;
> - u32 stride;
> - u32 base;
> int ret;
> - int i;
>
> syscon = of_parse_phandle(pdev->dev.of_node, "syscon", 0);
> - if (!syscon) {
> - dev_err(&pdev->dev, "no syscon property\n");
> - return -ENODEV;
> - }
> + if (!syscon)
> + return ERR_PTR(-ENODEV);
>
> regmap = syscon_node_to_regmap(syscon);
> of_node_put(syscon);
> if (IS_ERR(regmap))
> - return PTR_ERR(regmap);
> + return regmap;
>
> - ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1, &base);
> + ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1, base);
> if (ret < 0) {
> dev_err(&pdev->dev, "no offset in syscon\n");
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
> }
>
> - ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 2, &stride);
> + ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 2, stride);
> if (ret < 0) {
> dev_err(&pdev->dev, "no stride syscon\n");
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
> }
>
> + return regmap;
> +}
> +
> +static const struct regmap_config tcsr_mutex_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> + .max_register = 0x40000,
> + .fast_io = true,
> +};
> +
> +static struct regmap *qcom_hwspinlock_probe_mmio(struct platform_device *pdev,
> + u32 *offset, u32 *stride)
> +{
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + void __iomem *base;
> +
> + /* All modern platform has offset 0 and stride of 4k */
> + *offset = 0;
> + *stride = 0x1000;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, res);
I think you can use devm_platform_ioremap_resource(pdev, 0) to
simplify your code, otherwise looks good to me.
Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
> + if (IS_ERR(base))
> + return ERR_CAST(base);
> +
> + return devm_regmap_init_mmio(dev, base, &tcsr_mutex_config);
> +}
> +
> +static int qcom_hwspinlock_probe(struct platform_device *pdev)
> +{
> + struct hwspinlock_device *bank;
> + struct reg_field field;
> + struct regmap *regmap;
> + size_t array_size;
> + u32 stride;
> + u32 base;
> + int i;
> +
> + regmap = qcom_hwspinlock_probe_syscon(pdev, &base, &stride);
> + if (IS_ERR(regmap) && PTR_ERR(regmap) == -ENODEV)
> + regmap = qcom_hwspinlock_probe_mmio(pdev, &base, &stride);
> +
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> array_size = QCOM_MUTEX_NUM_LOCKS * sizeof(struct hwspinlock);
> bank = devm_kzalloc(&pdev->dev, sizeof(*bank) + array_size, GFP_KERNEL);
> if (!bank)
> --
> 2.26.2
>
--
Baolin Wang
^ permalink raw reply
* Re: [PATCH V4 8/8] arm64: dts: ipq6018: Add a53 pll and apcs clock
From: Sivaprakash Murugesan @ 2020-05-13 3:55 UTC (permalink / raw)
To: Bjorn Andersson
Cc: agross, mturquette, sboyd, robh+dt, jassisinghbrar, linux-arm-msm,
linux-clk, devicetree, linux-kernel
In-Reply-To: <20200512202439.GK2165@builder.lan>
Hi Bjorn,
On 5/13/2020 1:54 AM, Bjorn Andersson wrote:
> On Sun 03 May 23:20 PDT 2020, Sivaprakash Murugesan wrote:
>
>> add support for apps pll and apcs clock.
>>
>> Signed-off-by: Sivaprakash Murugesan <sivaprak@codeaurora.org>
>> ---
>> arch/arm64/boot/dts/qcom/ipq6018.dtsi | 16 +++++++++++++---
>> 1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
>> index 1aa8d85..af2ceeb 100644
>> --- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
>> @@ -294,12 +294,22 @@
>> };
>>
>> apcs_glb: mailbox@b111000 {
>> - compatible = "qcom,ipq8074-apcs-apps-global";
>> - reg = <0x0b111000 0xc>;
>> -
>> + compatible = "qcom,ipq6018-apcs-apps-global";
>> + reg = <0x0b111000 0x1000>;
> My documentation states that IPQ8074 indeed has this block at
> 0x0b111000, but IPQ6018 it's at 0x6b111000. Can you confirm this is
> correct? Same with the pll below.
The address 0x6b111000 is how the RPM sees this block. For A53 it is
still 0xb111000
>
> Apart from that the patch looks good.
>
> Regards,
> Bjorn
^ permalink raw reply
* Re: [PATCH v2 RESEND 2/2] Input: remove msm-vibrator driver
From: Dmitry Torokhov @ 2020-05-13 3:18 UTC (permalink / raw)
To: Brian Masney
Cc: robh+dt, linux-input, linux-kernel, devicetree, linux-arm-msm,
sboyd
In-Reply-To: <20200513013140.69935-3-masneyb@onstation.org>
On Tue, May 12, 2020 at 09:31:40PM -0400, Brian Masney wrote:
> The address referenced by this driver is within the Qualcomm Clock
> namespace so let's drop the msm-vibrator bindings so that a more generic
> solution can be used instead. No one is currently using driver so this
> won't affect any users.
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 RESEND 1/2] dt-bindings: Input: remove msm-vibrator
From: Dmitry Torokhov @ 2020-05-13 3:18 UTC (permalink / raw)
To: Brian Masney
Cc: robh+dt, linux-input, linux-kernel, devicetree, linux-arm-msm,
sboyd, Rob Herring
In-Reply-To: <20200513013140.69935-2-masneyb@onstation.org>
On Tue, May 12, 2020 at 09:31:39PM -0400, Brian Masney wrote:
> The address referenced in this binding is within the Qualcomm Clock
> namespace so let's drop the msm-vibrator bindings so that a more
> generic solution can be used instead. No one is currently using these
> bindings so this won't affect any users.
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>
> Acked-by: Rob Herring <robh@kernel.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 5/5] ramoops: add max_reason optional field to ramoops DT node
From: Rob Herring @ 2020-05-13 2:42 UTC (permalink / raw)
To: Pavel Tatashin
Cc: jmorris, sashal, linux-kernel, pmladek, sergey.senozhatsky,
rostedt, keescook, anton, ccross, tony.luck, devicetree
In-Reply-To: <20200505154510.93506-6-pasha.tatashin@soleen.com>
On Tue, May 05, 2020 at 11:45:10AM -0400, Pavel Tatashin wrote:
> Currently, it is possible to dump kmsges for panic, or oops.
> With max_reason it is possible to dump messages for other
> kmesg_dump events, for example reboot, halt, shutdown, kexec.
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> ---
> .../devicetree/bindings/reserved-memory/ramoops.txt | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/reserved-memory/ramoops.txt b/Documentation/devicetree/bindings/reserved-memory/ramoops.txt
> index 0eba562fe5c6..886cff15d822 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/ramoops.txt
> +++ b/Documentation/devicetree/bindings/reserved-memory/ramoops.txt
> @@ -30,7 +30,7 @@ Optional properties:
> - ecc-size: enables ECC support and specifies ECC buffer size in bytes
> (defaults to 0: no ECC)
>
> -- record-size: maximum size in bytes of each dump done on oops/panic
> +- record-size: maximum size in bytes of each kmsg dump.
> (defaults to 0: disabled)
>
> - console-size: size in bytes of log buffer reserved for kernel messages
> @@ -45,7 +45,13 @@ Optional properties:
> - unbuffered: if present, use unbuffered mappings to map the reserved region
> (defaults to buffered mappings)
>
> -- no-dump-oops: if present, only dump panics (defaults to panics and oops)
> +- max_reason: maximum reason for kmsg dump. Defaults to 2 (dump oops and
max-reason
> + panics). Can be set to INT_MAX to dump for all reasons. See
> + include/linux/kmsg_dump.h KMSG_DUMP_* for other kmsg dump values.
> +
> +- no-dump-oops: deprecated, use max_reason instead.
> + if present, and max_reason is not specified is equivalent to
> + max_reason = 1 (KMSG_DUMP_PANIC).
>
> - flags: if present, pass ramoops behavioral flags (defaults to 0,
> see include/linux/pstore_ram.h RAMOOPS_FLAG_* for flag values).
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH 02/11] dt-bindings: new: add yaml bindings for MediaTek Ethernet MAC
From: Rob Herring @ 2020-05-13 2:41 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: David S . Miller, Matthias Brugger, Felix Fietkau, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Bartosz Golaszewski
In-Reply-To: <20200505140231.16600-3-brgl@bgdev.pl>
On Tue, May 05, 2020 at 04:02:22PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This adds yaml DT bindings for the MediaTek Ethernet MAC present on the
> mt8* family of SoCs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> .../bindings/net/mediatek,eth-mac.yaml | 80 +++++++++++++++++++
> 1 file changed, 80 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/mediatek,eth-mac.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/mediatek,eth-mac.yaml b/Documentation/devicetree/bindings/net/mediatek,eth-mac.yaml
> new file mode 100644
> index 000000000000..7682fe9d8109
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/mediatek,eth-mac.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/mediatek,eth-mac.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek Ethernet MAC Controller
> +
> +maintainers:
> + - Bartosz Golaszewski <bgolaszewski@baylibre.com>
> +
> +description:
> + This Ethernet MAC is used on the MT8* family of SoCs from MediaTek.
> + It's compliant with 802.3 standards and supports half- and full-duplex
> + modes with flow-control as well as CRC offloading and VLAN tags.
> +
> +properties:
> + compatible:
> + enum:
> + - mediatek,mt8516-eth
> + - mediatek,mt8518-eth
> + - mediatek,mt8175-eth
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + minItems: 3
> + maxItems: 3
> +
> + clock-names:
> + additionalItems: false
> + items:
> + - const: core
> + - const: reg
> + - const: trans
> +
> + mediatek,pericfg:
> + $ref: /schemas/types.yaml#definitions/phandle
> + description:
> + Phandle to the device containing the PERICFG register range.
Perhaps say what it is used for?
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - mediatek,pericfg
> + - phy-handle
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/mt8516-clk.h>
> +
> + ethernet: ethernet@11180000 {
> + compatible = "mediatek,mt8516-eth";
> + reg = <0 0x11180000 0 0x1000>;
Default addr and size is 1 cell.
> + mediatek,pericfg = <&pericfg>;
> + interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&topckgen CLK_TOP_RG_ETH>,
> + <&topckgen CLK_TOP_66M_ETH>,
> + <&topckgen CLK_TOP_133M_ETH>;
> + clock-names = "core", "reg", "trans";
> + phy-handle = <ð_phy>;
> + phy-mode = "rmii";
> +
> + mdio {
Not documented.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy: ethernet-phy@0 {
> + reg = <0>;
> + };
> + };
> + };
> --
> 2.25.0
>
^ permalink raw reply
* Re: [PATCH 01/11] dt-bindings: add a binding document for MediaTek PERICFG controller
From: Rob Herring @ 2020-05-13 2:38 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: David S . Miller, Matthias Brugger, Felix Fietkau, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Bartosz Golaszewski
In-Reply-To: <20200505140231.16600-2-brgl@bgdev.pl>
On Tue, May 05, 2020 at 04:02:21PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This adds a binding document for the PERICFG controller present on
> MediaTek SoCs. For now the only variant supported is 'mt8516-pericfg'.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> .../arm/mediatek/mediatek,pericfg.yaml | 34 +++++++++++++++++++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
> new file mode 100644
> index 000000000000..74b2a6173ffb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
> @@ -0,0 +1,34 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: MediaTek Peripheral Configuration Controller
> +
> +maintainers:
> + - Bartosz Golaszewski <bgolaszewski@baylibre.com>
> +
> +properties:
> + compatible:
> + oneOf:
Don't need oneOf.
> + - items:
> + - enum:
> + - mediatek,pericfg
PERICFG is exactly the same register set and functions on all Mediatek
SoCs? Needs to be more specific.
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + pericfg: pericfg@10003050 {
> + compatible = "mediatek,mt8516-pericfg", "syscon";
> + reg = <0 0x10003050 0 0x1000>;
Default for examples is 1 cell for addr and size.
> + };
> --
> 2.25.0
>
^ permalink raw reply
* Re: [PATCH v1] dt-bindings: net: nxp,tja11xx: rework validation support
From: Rob Herring @ 2020-05-13 2:36 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Rob Herring, Mark Rutland, Andrew Lunn, David S. Miller,
Florian Fainelli, Pengutronix Kernel Team, netdev, David Jander,
Heiner Kallweit, linux-kernel, devicetree, Marek Vasut
In-Reply-To: <20200505104215.8975-1-o.rempel@pengutronix.de>
On Tue, 5 May 2020 12:42:15 +0200, Oleksij Rempel wrote:
> To properly identify this node, we need to use ethernet-phy-id0180.dc80.
> And add missing required properties.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> .../devicetree/bindings/net/nxp,tja11xx.yaml | 55 ++++++++++++-------
> 1 file changed, 35 insertions(+), 20 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1] dt-bindings: net: nxp,tja11xx: rework validation support
From: Rob Herring @ 2020-05-13 2:34 UTC (permalink / raw)
To: Andrew Lunn
Cc: Oleksij Rempel, Florian Fainelli, Heiner Kallweit, Mark Rutland,
Pengutronix Kernel Team, linux-kernel, David S. Miller, netdev,
Marek Vasut, David Jander, devicetree
In-Reply-To: <20200505140127.GJ208718@lunn.ch>
On Tue, May 05, 2020 at 04:01:27PM +0200, Andrew Lunn wrote:
> On Tue, May 05, 2020 at 12:42:15PM +0200, Oleksij Rempel wrote:
> > To properly identify this node, we need to use ethernet-phy-id0180.dc80.
> > And add missing required properties.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > ---
> > .../devicetree/bindings/net/nxp,tja11xx.yaml | 55 ++++++++++++-------
> > 1 file changed, 35 insertions(+), 20 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
> > index 42be0255512b3..cc322107a24a2 100644
> > --- a/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
> > +++ b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
> > @@ -1,4 +1,4 @@
> > -# SPDX-License-Identifier: GPL-2.0+
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > %YAML 1.2
> > ---
> > $id: http://devicetree.org/schemas/net/nxp,tja11xx.yaml#
> > @@ -12,44 +12,59 @@ maintainers:
> > - Heiner Kallweit <hkallweit1@gmail.com>
> >
> > description:
> > - Bindings for NXP TJA11xx automotive PHYs
> > + Bindings for the NXP TJA1102 automotive PHY. This is a dual PHY package where
> > + only the first PHY has global configuration register and HW health
> > + monitoring.
> >
> > -allOf:
> > - - $ref: ethernet-phy.yaml#
> > +properties:
> > + compatible:
> > + const: ethernet-phy-id0180.dc80
> > + description: ethernet-phy-id0180.dc80 used for TJA1102 PHY
> > +
> > + reg:
> > + minimum: 0
> > + maximum: 14
> > + description:
> > + The PHY address of the parent PHY.
>
> Hi Oleksij
>
> reg is normally 0 to 31, since that is the address range for MDIO.
> Did you use 14 here because of what strapping allows?
>
> > +required:
> > + - compatible
> > + - reg
> > + - '#address-cells'
> > + - '#size-cells'
>
> So we have two different meanings of 'required' here.
>
> One meaning is the code requires it. compatible is not required, the
> driver will correctly be bind to the device based on its ID registers.
> Is reg also required by the code?
>
> The second meaning is about keeping the yaml verifier happy. It seems
> like compatible is needed for the verifier. Is reg also required? We
> do recommend having reg, but the generic code does not require it.
Well, you have to be able to match a discoverable device to a DT node.
Unless you only have one thing on the bus (how would you know though,
they're discoverable?), that's with reg. And if you need to say turn on
a regulator for the device to be discovered, then you need compatible to
know how to do that.
So either don't describe the device in DT because you can discover
everything or you describe it in DT with both 'compatible' and 'reg'.
MDIO is not special.
Rob
^ permalink raw reply
* Re: [RESEND PATCH v2 1/3] dt-bindings: phy: Drop reset-gpios from marvell,mmp3-hsic-phy
From: Kishon Vijay Abraham I @ 2020-05-13 2:33 UTC (permalink / raw)
To: Lubomir Rintel, Rob Herring; +Cc: linux-kernel, devicetree
In-Reply-To: <20200509081754.474787-2-lkundrak@v3.sk>
+Rob
On 5/9/2020 1:47 PM, Lubomir Rintel wrote:
> This has been added in error -- the PHY block doesn't have a reset pin.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
> .../devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
> index 00609ace677c..30e290c57930 100644
> --- a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
> @@ -18,27 +18,20 @@ properties:
> maxItems: 1
> description: base address of the device
>
> - reset-gpios:
> - maxItems: 1
> - description: GPIO connected to reset
> -
> "#phy-cells":
> const: 0
>
> required:
> - compatible
> - reg
> - - reset-gpios
> - "#phy-cells"
>
> additionalProperties: false
>
> examples:
> - |
> - #include <dt-bindings/gpio/gpio.h>
> hsic-phy@f0001800 {
> compatible = "marvell,mmp3-hsic-phy";
> reg = <0xf0001800 0x40>;
> - reset-gpios = <&gpio 63 GPIO_ACTIVE_HIGH>;
> #phy-cells = <0>;
> };
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox