RE: [PATCH V3 0/4] clk: imx8m: fix glitch/mux
Hi Stephen, > Subject: RE: [PATCH V3 0/4] clk: imx8m: fix glitch/mux > > Quoting Peng Fan (2019-09-16 23:20:15) > > Hi Stephen, Shawn, > > > > > Subject: [PATCH V3 0/4] clk: imx8m: fix glitch/mux > > > > Sorry to ping early. Is there a chance to land this patchset in 5.3 release? > > > > No, it won't be in 5.3 because that version is released. Shawn already sent > the > PR for 5.4 too so this will most likely be in v5.5 at the earliest. Thanks for the info. But this patchset is bugfix, so hope this could be accepted in 5.4. Thanks, Peng.
RE: [PATCH V3 0/4] clk: imx8m: fix glitch/mux
Hi Stephen, Shawn, > Subject: [PATCH V3 0/4] clk: imx8m: fix glitch/mux Sorry to ping early. Is there a chance to land this patchset in 5.3 release? Thanks, Peng. > > From: Peng Fan > > V3: > Add cover-letter > > V2: > Added patch [2,3,4]/4 and avoid glitch when prepare > > There is two bypass bit in the pll, BYPASS and EXT_BYPASS. > There is also a restriction that to avoid glitch, need set BYPASS bit when > RESETB changed from 0 to 1, otherwise there will be glitch. > > However the BYPASS bit is also used as mux bit in imx8mm/imx8mn clk driver. > > This means two paths touch the same bit which is wrong. So switch to use > EXT_BYPASS bit as the mux. > > Peng Fan (4): > clk: imx: pll14xx: avoid glitch when set rate > clk: imx: clk-pll14xx: unbypass PLL by default > clk: imx: imx8mm: fix pll mux bit > clk: imx: imx8mn: fix pll mux bit > > drivers/clk/imx/clk-imx8mm.c | 32 ++-- > drivers/clk/imx/clk-imx8mn.c | 32 ++-- > drivers/clk/imx/clk-pll14xx.c | 27 ++- > 3 files changed, 46 insertions(+), 45 deletions(-) > > -- > 2.16.4
[PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.
Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/
Cc: Andre Przywara
Signed-off-by: Peng Fan
---
drivers/mailbox/Kconfig | 7 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 167 ++
3 files changed, 176 insertions(+)
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config ARM_SMC_MBOX
+ tristate "Generic ARM smc mailbox"
+ depends on OF && HAVE_ARM_SMCCC
+ help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..c84aef39c8d9
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct arm_smc_chan_data {
+ unsigned int function_id;
+};
+
+struct arm_smccc_mbox_cmd {
+ unsigned int function_id;
+ union {
+ unsigned int args_smccc32[6];
+ unsigned long args_smccc64[6];
+ };
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+ struct arm_smc_chan_data *chan_data = link->con_priv;
+ struct arm_smccc_mbox_cmd *cmd = data;
+ unsigned long ret;
+ u32 function_id;
+
+ function_id = chan_data->function_id;
+ if (!function_id)
+ function_id = cmd->function_id;
+
+ if (function_id & BIT(30)) {
+ ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0],
+cmd->args_smccc64[1],
+cmd->args_smccc64[2],
+cmd->args_smccc64[3],
+cmd->args_smccc64[4],
+cmd->args_smccc64[5]);
+ } else {
+ ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0],
+cmd->args_smccc32[1],
+cmd->args_smccc32[2],
+cmd->args_smccc32[3],
+cmd->args_smccc32[4],
+cmd->args_smccc32[5]);
+ }
+
+ mbox_chan_received_data(link, (void *)ret);
+
+ return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned int function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, 0, );
+ return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned int function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned
[PATCH V6 0/2] mailbox: arm: introduce smc triggered mailbox
From: Peng Fan V6: Switch to per-channel a mbox controller Drop arm,num-chans, transports, method Add arm,hvc-mbox compatible Fix smc/hvc args, drop client id and use correct type. V5: yaml fix https://patchwork.kernel.org/cover/7741/ V4: yaml fix for num-chans in patch 1/2. https://patchwork.kernel.org/cover/6521/ V3: Drop interrupt Introduce transports for mem/reg usage Add chan-id for mem usage Convert to yaml format https://patchwork.kernel.org/cover/11043541/ V2: This is a modified version from Andre Przywara's patch series https://lore.kernel.org/patchwork/cover/812997/. The modification are mostly: Introduce arm,num-chans Introduce arm_smccc_mbox_cmd txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as an optional property. Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. Introduce interrupts notification. [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use smc as mailbox, power/clk is included, but only part of clk has been implemented to work with hardware, power domain only supports get name for now. The traditional Linux mailbox mechanism uses some kind of dedicated hardware IP to signal a condition to some other processing unit, typically a dedicated management processor. This mailbox feature is used for instance by the SCMI protocol to signal a request for some action to be taken by the management processor. However some SoCs does not have a dedicated management core to provide those services. In order to service TEE and to avoid linux shutdown power and clock that used by TEE, need let firmware to handle power and clock, the firmware here is ARM Trusted Firmware that could also run SCMI service. The existing SCMI implementation uses a rather flexible shared memory region to communicate commands and their parameters, it still requires a mailbox to actually trigger the action. This patch series provides a Linux mailbox compatible service which uses smc calls to invoke firmware code, for instance taking care of SCMI requests. The actual requests are still communicated using the standard SCMI way of shared memory regions, but a dedicated mailbox hardware IP can be replaced via this new driver. This simple driver uses the architected SMC calling convention to trigger firmware services, also allows for using "HVC" calls to call into hypervisors or firmware layers running in the EL2 exception level. Patch 1 contains the device tree binding documentation, patch 2 introduces the actual mailbox driver. Please note that this driver just provides a generic mailbox mechanism, It could support synchronous TX/RX, or synchronous TX with asynchronous RX. And while providing SCMI services was the reason for this exercise, this driver is in no way bound to this use case, but can be used generically where the OS wants to signal a mailbox condition to firmware or a hypervisor. Also the driver is in no way meant to replace any existing firmware interface, but actually to complement existing interfaces. [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi Peng Fan (2): dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox mailbox: introduce ARM SMC based mailbox .../devicetree/bindings/mailbox/arm-smc.yaml | 96 drivers/mailbox/Kconfig| 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 167 + 4 files changed, 272 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml create mode 100644 drivers/mailbox/arm-smc-mailbox.c -- 2.16.4
[PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan
The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Signed-off-by: Peng Fan
---
.../devicetree/bindings/mailbox/arm-smc.yaml | 96 ++
1 file changed, 96 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index ..bf01bec035fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+ - Peng Fan
+
+description: |
+ This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
+ call) instruction to trigger a mailbox-connected activity in firmware,
+ executing on the very same core as the caller. The value of r0/w0/x0
+ the firmware returns after the smc call is delivered as a received
+ message to the mailbox framework, so synchronous communication can be
+ established. The exact meaning of the action the mailbox triggers as
+ well as the return value is defined by their users and is not subject
+ to this binding.
+
+ One use case of this mailbox is the SCMI interface, which uses shared
+ memory to transfer commands and parameters, and a mailbox to trigger a
+ function call. This allows SoCs without a separate management processor
+ (or when such a processor is not available or used) to use this
+ standardized interface anyway.
+
+ This binding describes no hardware, but establishes a firmware interface.
+ Upon receiving an SMC using one of the described SMC function identifiers,
+ the firmware is expected to trigger some mailbox connected functionality.
+ The communication follows the ARM SMC calling convention.
+ Firmware expects an SMC function identifier in r0 or w0. The supported
+ identifiers are passed from consumers, or listed in the the arm,func-ids
+ properties as described below. The firmware can return one value in
+ the first SMC result register, it is expected to be an error value,
+ which shall be propagated to the mailbox client.
+
+ Any core which supports the SMC or HVC instruction can be used, as long
+ as a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+ compatible:
+oneOf:
+ - description:
+ For implementations using ARM SMC instruction.
+const: arm,smc-mbox
+
+ - description:
+ For implementations using ARM HVC instruction.
+const: arm,hvc-mbox
+
+ "#mbox-cells":
+const: 1
+
+ arm,func-id:
+description: |
+ An 32-bit value specifying the function ID used by the mailbox.
+ The function ID follow the ARM SMC calling convention standard [1].
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - "#mbox-cells"
+
+examples:
+ - |
+sram@93f000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x93f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x93f000 0x1000>;
+
+ cpu_scp_lpri: scp-shmem@0 {
+compatible = "arm,scmi-shmem";
+reg = <0x0 0x200>;
+ };
+};
+
+smc_tx_mbox: tx_mbox {
+ #mbox-cells = <1>;
+ compatible = "arm,smc-mbox";
+ /* optional */
+ arm,func-id = <0xc2fe>;
+};
+
+firmware {
+ scmi {
+compatible = "arm,scmi";
+mboxes = <_tx_mbox 0>;
+mbox-names = "tx";
+shmem = <_scp_lpri>;
+ };
+};
+
+...
--
2.16.4
RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Wed, Sep 11, 2019 at 10:03 AM Andre Przywara
> wrote:
> >
> > On Tue, 10 Sep 2019 21:44:11 -0500
> > Jassi Brar wrote:
> >
> > Hi,
> >
> > > On Mon, Sep 9, 2019 at 10:42 AM Andre Przywara
> wrote:
> > > >
> > > > On Wed, 28 Aug 2019 03:02:58 + Peng Fan
> > > > wrote:
> > > >
> > [ ... ]
> > > >
> > > > > +
> > > > > + arm,func-ids:
> > > > > +description: |
> > > > > + An array of 32-bit values specifying the function IDs used by
> each
> > > > > + mailbox channel. Those function IDs follow the ARM SMC
> calling
> > > > > + convention standard [1].
> > > > > +
> > > > > + There is one identifier per channel and the number of
> supported
> > > > > + channels is determined by the length of this array.
> > > >
> > > > I think this makes it obvious that arm,num-chans is not needed.
> > > >
> > > > Also this somewhat contradicts the driver implementation, which allows
> the array to be shorter, marking this as UINT_MAX and later on using the first
> data item as a function identifier. This is somewhat surprising and not
> documented (unless I missed something).
> > > >
> > > > So I would suggest:
> > > > - We drop the transports property, and always put the client provided
> data in the registers, according to the SMCCC. Document this here.
> > > > A client not needing those could always puts zeros (or garbage) in
> there, the respective firmware would just ignore the registers.
> > > > - We drop "arm,num-chans", as this is just redundant with the length of
> the func-ids array.
> > > > - We don't impose an arbitrary limit on the number of channels. From
> the firmware point of view this is just different function IDs, from Linux'
> point
> of view just the size of the memory used. Both don't need to be limited
> artificially IMHO.
> > > >
> > > Sounds like we are in sync.
> > >
> > > > - We mark arm,func-ids as required, as this needs to be fixed, allocated
> number.
> > > >
> > > I still think func-id can be done without. A client can always pass
> > > the value as it knows what it expects.
> >
> > I don't think it's the right abstraction. The mailbox *controller* uses a
> specific func-id, this has to match the one the firmware expects. So this is a
> property of the mailbox transport channel (the SMC call), and the *client*
> should *not* care about it. It just sees the logical channel ID (if we have
> one),
> which the controller translates into the func-ID.
> >
> arg0 is special only to the client/protocol, otherwise it is simply the first
> argument for the arm_smccc_smc *instruction* controller.
> arg[1,7] are already provided by the client, so it is only neater if
> arg0 is also taken from the client.
>
> But as I said, I am still ok if func-id is passed from dt and arg0 from
> client is
> ignored because we have one channel per controller design and we don't have
> to worry about number of channels there can be dedicated to specific
> functions.
Ok, so I'll make it an optional property.
>
> > So it should really look like this (assuming only single channel
> > controllers):
> > mailbox: smc-mailbox {
> > #mbox-cells = <0>;
> > compatible = "arm,smc-mbox";
> > method = "smc";
> >
> Do we want to do away with 'method' property and use different 'compatible'
> properties instead?
> compatible = "arm,smc-mbox"; orcompatible = "arm,hvc-mbox";
I am ok, just need add data in driver to differentiate smc/hvc.
Andre, are you ok?
Thanks,
Peng.
>
> > arm,func-id = <0x82fe>;
> > };
> > scmi {
> > compatible = "arm,scmi";
> > mboxes = <_mbox>;
> > mbox-names = "tx"; /* rx is optional */
> > shmem = <_scp_hpri>;
> > };
> >
> > If you allow the client to provide the function ID (and I am not saying
> > this is
> a good idea): where would this func ID come from? It would need to be a
> property of the client DT node, then. So one way would be to use the func ID
> as the Linux mailbox channel ID:
> > mailbox: smc-mailbox {
> > #mbox-cells = <1>;
> > compatible = "arm,smc-mbox";
> > method = "smc";
> > };
> > scmi {
> > compatible = "arm,scmi";
> > mboxes = <_mbox 0x82fe>;
> > mbox-names = "tx"; /* rx is optional */
> > shmem = <_scp_hpri>;
> > };
> >
> > But this doesn't look desirable.
> >
> > And as I mentioned this before: allowing some mailbox clients to provide
> the function IDs sound scary, as they could use anything they want, triggering
> random firmware actions (think PSCI_CPU_OFF).
> >
> That paranoia is unwarranted. We have to keep faith in kernel-space code
> doing the right thing.
> Either the illegitimate function request should be rejected by the firmware or
> client driver be called buggy just as we would call a block device driver
> buggy if it messed up the sector numbers in a write request.
>
> thnx.
RE: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
Hi Andre,
> Subject: Re: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Wed, 28 Aug 2019 03:03:02 +0000
> Peng Fan wrote:
>
> Hi,
>
> > From: Peng Fan
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7Cce8d04bcbdea4de6a77a08d7353c4e35%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C637036405476727893sdata=y5%2FI%2B
> w%2FPOypEh
> > zh6gWdXAGMGnl677B7gDZsX%2F5zfAQw%3Dreserved=0
> >
> > Cc: Andre Przywara
> > Signed-off-by: Peng Fan
> > ---
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 215
> > ++
> > 3 files changed, 224 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > ab4eb750bbdd..7707ee26251a 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -16,6 +16,13 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > + tristate "Generic ARM smc mailbox"
> > + depends on OF && HAVE_ARM_SMCCC
> > + help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> > config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..76a2ae11ee4d
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,215 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include #include
> > +#include
> > +
> > +#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
> > +
> > +struct arm_smc_chan_data {
> > + u32 function_id;
> > + u32 chan_id;
> > + u32 flags;
> > +};
> > +
> > +struct arm_smccc_mbox_cmd {
> > + unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
>
> I think this is one or even two registers too long?
> The SMCCC speaks of the function ID in x0/r0 and six arguments, with a
> "client ID" being an optional seventh argument. Looking at the description
> there I believe we cannot use the client ID here for this purpose, as this is
> supposed to be set by a hypervisor before passing on an SMC to EL3 firmware.
> KVM does not allow passing on SMCs in this way.
I'll drop a7.
>
> Also, while using "long" in here seems to make sense from the mailbox and
> SMC point of view, aliasing this to the mailbox client provided data seems
> dangerous to me, as this exposes the difference between arm32 and arm64
> to the client. I think this is not what we want, the client should not be
> architecture specific.
I see.
>
> > +};
> > +
> > +typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
> > + unsigned long, unsigned
RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Fri, 30 Aug 2019 03:12:29 -0500
> Jassi Brar wrote:
>
> Hi,
>
> > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan wrote:
> > >
> > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc
> > > > for the ARM SMC/HVC mailbox
> > > >
> > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan wrote:
> > > > >
> > > > > Hi Jassi,
> > > > >
> > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding
> > > > > > doc for the ARM SMC/HVC mailbox
> > > > > >
> > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan
> wrote:
> > > > > >
> > > > > > > > > +examples:
> > > > > > > > > + - |
> > > > > > > > > +sram@91 {
> > > > > > > > > + compatible = "mmio-sram";
> > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>;
> > > > > > > > > + #address-cells = <1>;
> > > > > > > > > + #size-cells = <1>;
> > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>;
> > > > > > > > > +
> > > > > > > > > + cpu_scp_lpri: scp-shmem@0 {
> > > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > > +reg = <0x0 0x200>;
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + cpu_scp_hpri: scp-shmem@200 {
> > > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > > +reg = <0x200 0x200>;
> > > > > > > > > + };
> > > > > > > > > +};
> > > > > > > > > +
> > > > > > > > > +firmware {
> > > > > > > > > + smc_mbox: mailbox {
> > > > > > > > > +#mbox-cells = <1>;
> > > > > > > > > +compatible = "arm,smc-mbox";
> > > > > > > > > +method = "smc";
> > > > > > > > > +arm,num-chans = <0x2>;
> > > > > > > > > +transports = "mem";
> > > > > > > > > +/* Optional */
> > > > > > > > > +arm,func-ids = <0xc2fe>, <0xc2ff>;
> > > > > > > > >
> > > > > > > > SMC/HVC is synchronously(block) running in "secure mode",
> > > > > > > > i.e, there can only be one instance running platform wide.
> > > > > > > > Right?
> > > > > > >
> > > > > > > I think there could be channel for TEE, and channel for Linux.
> > > > > > > For virtualization case, there could be dedicated channel for each
> VM.
> > > > > > >
> > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above,
> > > > > > can't both be active at the same time, right?
> > > > >
> > > > > If I get your point correctly,
> > > > > On UP, both could not be active. On SMP, tx/rx could be both
> > > > > active, anyway this depends on secure firmware and Linux firmware
> design.
> > > > >
> > > > > Do you have any suggestions about arm,func-ids here?
> > > > >
> > > > I was thinking if this is just an instruction, why can't each
> > > > channel be represented as a controller, i.e, have exactly one func-id
> > > > per
> controller node.
> > > > Define as many controllers as you need channels ?
> > >
> > > I am ok, this could make driver code simpler. Something as below?
> > >
> > > smc_tx_mbox: tx_mbox {
> > > #mbox-cells = <0>;
> > > compatible = "arm,smc-mbox";
> > > method = "smc";
> > > transports = "mem";
> > > arm,func-id = <0xc2fe>;
> > > };
> > >
> > > smc_rx_mbox: rx_mbox {
> > > #mbox-cells = <0>;
> &
[PATCH V3 2/4] clk: imx: clk-pll14xx: unbypass PLL by default
From: Peng Fan
When registering the PLL, unbypass the PLL.
The PLL has two bypass control bit, BYPASS and EXT_BYPASS.
we will expose EXT_BYPASS to clk driver for mux usage, and keep
BYPASS inside pll14xx usage. The PLL has a restriction that
when M/P change, need to RESET/BYPASS pll to avoid glitch, so
we could not expose BYPASS.
To make it easy for clk driver usage, unbypass PLL which does
not hurt current function.
Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Reviewed-by: Leonard Crestez
Signed-off-by: Peng Fan
---
V3:
None
V2:
New patch
drivers/clk/imx/clk-pll14xx.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index 656f48b002dd..7a815ec76aa5 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -368,6 +368,7 @@ struct clk *imx_clk_pll14xx(const char *name, const char
*parent_name,
struct clk_pll14xx *pll;
struct clk *clk;
struct clk_init_data init;
+ u32 val;
pll = kzalloc(sizeof(*pll), GFP_KERNEL);
if (!pll)
@@ -399,6 +400,10 @@ struct clk *imx_clk_pll14xx(const char *name, const char
*parent_name,
pll->rate_table = pll_clk->rate_table;
pll->rate_count = pll_clk->rate_count;
+ val = readl_relaxed(pll->base + GNRL_CTL);
+ val &= ~BYPASS_MASK;
+ writel_relaxed(val, pll->base + GNRL_CTL);
+
clk = clk_register(NULL, >hw);
if (IS_ERR(clk)) {
pr_err("%s: failed to register pll %s %lu\n",
--
2.16.4
RE: [PATCH V2 1/4] clk: imx: pll14xx: avoid glitch when set rate
Hi Stephen,
> Subject: Re: [PATCH V2 1/4] clk: imx: pll14xx: avoid glitch when set rate
>
> Quoting Peng Fan (2019-08-26 02:42:14)
> > From: Peng Fan
> >
> > According to PLL1443XA and PLL1416X spec, "When BYPASS is 0 and RESETB
> > is changed from 0 to 1, FOUT starts to output unstable clock until
> > lock time passes. PLL1416X/PLL1443XA may generate a glitch at FOUT."
> >
> > So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch.
> > In the end of set rate, BYPASS will be cleared.
> >
> > When prepare clock, also need to take care to avoid glitch. So we also
> > follow Spec to set BYPASS before RESETB changed from 0 to 1.
> > And add a check if the RESETB is already 0, directly return 0;
> >
> > Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
> > Reviewed-by: Leonard Crestez
> > Signed-off-by: Peng Fan
> > ---
>
> Please make cover letters for multi-patch series.
Just sent out v3 to include cover-letter, no other changes.
Thanks,
Peng.
[PATCH V3 3/4] clk: imx: imx8mm: fix pll mux bit
From: Peng Fan
pll BYPASS bit should be kept inside pll driver for glitchless freq
setting following spec. If exposing the bit, that means pll driver and
clk driver has two paths to touch this bit, which is wrong.
So use EXT_BYPASS bit here.
And drop uneeded set parent, because EXT_BYPASS default is 0.
Fixes: ba5625c3e272 ("clk: imx: Add clock driver support for imx8mm")
Suggested-by: Jacky Bai
Reviewed-by: Leonard Crestez
Signed-off-by: Peng Fan
---
V3:
None
V2:
New patch
drivers/clk/imx/clk-imx8mm.c | 32 ++--
1 file changed, 10 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 2758e3f0d15d..067ab876911d 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -408,28 +408,16 @@ static int imx8mm_clocks_probe(struct platform_device
*pdev)
clks[IMX8MM_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel",
base + 0x114, _sys_pll);
/* PLL bypass out */
- clks[IMX8MM_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass",
base, 4, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass",
base + 0x14, 4, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass",
base + 0x28, 4, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass",
base + 0x50, 4, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base
+ 0x64, 4, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base
+ 0x74, 4, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base
+ 0x84, 4, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_SYS_PLL1_BYPASS] = imx_clk_mux_flags("sys_pll1_bypass",
base + 0x94, 4, 1, sys_pll1_bypass_sels, ARRAY_SIZE(sys_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_SYS_PLL2_BYPASS] = imx_clk_mux_flags("sys_pll2_bypass",
base + 0x104, 4, 1, sys_pll2_bypass_sels, ARRAY_SIZE(sys_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_SYS_PLL3_BYPASS] = imx_clk_mux_flags("sys_pll3_bypass",
base + 0x114, 4, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels),
CLK_SET_RATE_PARENT);
-
- /* unbypass all the plls */
- clk_set_parent(clks[IMX8MM_AUDIO_PLL1_BYPASS], clks[IMX8MM_AUDIO_PLL1]);
- clk_set_parent(clks[IMX8MM_AUDIO_PLL2_BYPASS], clks[IMX8MM_AUDIO_PLL2]);
- clk_set_parent(clks[IMX8MM_VIDEO_PLL1_BYPASS], clks[IMX8MM_VIDEO_PLL1]);
- clk_set_parent(clks[IMX8MM_DRAM_PLL_BYPASS], clks[IMX8MM_DRAM_PLL]);
- clk_set_parent(clks[IMX8MM_GPU_PLL_BYPASS], clks[IMX8MM_GPU_PLL]);
- clk_set_parent(clks[IMX8MM_VPU_PLL_BYPASS], clks[IMX8MM_VPU_PLL]);
- clk_set_parent(clks[IMX8MM_ARM_PLL_BYPASS], clks[IMX8MM_ARM_PLL]);
- clk_set_parent(clks[IMX8MM_SYS_PLL1_BYPASS], clks[IMX8MM_SYS_PLL1]);
- clk_set_parent(clks[IMX8MM_SYS_PLL2_BYPASS], clks[IMX8MM_SYS_PLL2]);
- clk_set_parent(clks[IMX8MM_SYS_PLL3_BYPASS], clks[IMX8MM_SYS_PLL3]);
+ clks[IMX8MM_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass",
base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass",
base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass",
base + 0x28, 16, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass",
base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base
+ 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base
+ 0x74, 28, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base
+ 0x84, 28, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sel
[PATCH V3 4/4] clk: imx: imx8mn: fix pll mux bit
From: Peng Fan
pll BYPASS bit should be kept inside pll driver for glitchless freq
setting following spec. If exposing the bit, that means pll driver and
clk driver has two paths to touch this bit, which is wrong.
So use EXT_BYPASS bit here.
And drop uneeded set parent, because EXT_BYPASS default is 0.
Suggested-by: Jacky Bai
Reviewed-by: Leonard Crestez
Signed-off-by: Peng Fan
---
V3:
None
V2:
New patch
drivers/clk/imx/clk-imx8mn.c | 32 ++--
1 file changed, 10 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index f41116d59749..f767d18679ea 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -421,28 +421,16 @@ static int imx8mn_clocks_probe(struct platform_device
*pdev)
clks[IMX8MN_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel",
base + 0x114, _sys_pll);
/* PLL bypass out */
- clks[IMX8MN_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass",
base, 4, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass",
base + 0x14, 4, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass",
base + 0x28, 4, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass",
base + 0x50, 4, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base
+ 0x64, 4, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base
+ 0x74, 4, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base
+ 0x84, 4, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_SYS_PLL1_BYPASS] = imx_clk_mux_flags("sys_pll1_bypass",
base + 0x94, 4, 1, sys_pll1_bypass_sels, ARRAY_SIZE(sys_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_SYS_PLL2_BYPASS] = imx_clk_mux_flags("sys_pll2_bypass",
base + 0x104, 4, 1, sys_pll2_bypass_sels, ARRAY_SIZE(sys_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_SYS_PLL3_BYPASS] = imx_clk_mux_flags("sys_pll3_bypass",
base + 0x114, 4, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels),
CLK_SET_RATE_PARENT);
-
- /* unbypass all the plls */
- clk_set_parent(clks[IMX8MN_AUDIO_PLL1_BYPASS], clks[IMX8MN_AUDIO_PLL1]);
- clk_set_parent(clks[IMX8MN_AUDIO_PLL2_BYPASS], clks[IMX8MN_AUDIO_PLL2]);
- clk_set_parent(clks[IMX8MN_VIDEO_PLL1_BYPASS], clks[IMX8MN_VIDEO_PLL1]);
- clk_set_parent(clks[IMX8MN_DRAM_PLL_BYPASS], clks[IMX8MN_DRAM_PLL]);
- clk_set_parent(clks[IMX8MN_GPU_PLL_BYPASS], clks[IMX8MN_GPU_PLL]);
- clk_set_parent(clks[IMX8MN_VPU_PLL_BYPASS], clks[IMX8MN_VPU_PLL]);
- clk_set_parent(clks[IMX8MN_ARM_PLL_BYPASS], clks[IMX8MN_ARM_PLL]);
- clk_set_parent(clks[IMX8MN_SYS_PLL1_BYPASS], clks[IMX8MN_SYS_PLL1]);
- clk_set_parent(clks[IMX8MN_SYS_PLL2_BYPASS], clks[IMX8MN_SYS_PLL2]);
- clk_set_parent(clks[IMX8MN_SYS_PLL3_BYPASS], clks[IMX8MN_SYS_PLL3]);
+ clks[IMX8MN_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass",
base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass",
base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass",
base + 0x28, 16, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass",
base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base
+ 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base
+ 0x74, 28, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base
+ 0x84, 28, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_SYS_PLL1_BYPASS] = imx
[PATCH V3 1/4] clk: imx: pll14xx: avoid glitch when set rate
From: Peng Fan
According to PLL1443XA and PLL1416X spec,
"When BYPASS is 0 and RESETB is changed from 0 to 1, FOUT starts to
output unstable clock until lock time passes. PLL1416X/PLL1443XA may
generate a glitch at FOUT."
So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch.
In the end of set rate, BYPASS will be cleared.
When prepare clock, also need to take care to avoid glitch. So
we also follow Spec to set BYPASS before RESETB changed from 0 to 1.
And add a check if the RESETB is already 0, directly return 0;
Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Reviewed-by: Leonard Crestez
Signed-off-by: Peng Fan
---
V3:
None
V2:
Avoid glitch when prepare
update commit log
drivers/clk/imx/clk-pll14xx.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index b7213023b238..656f48b002dd 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -191,6 +191,10 @@ static int clk_pll1416x_set_rate(struct clk_hw *hw,
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
+ /* Enable BYPASS */
+ tmp |= BYPASS_MASK;
+ writel(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
@@ -250,6 +254,10 @@ static int clk_pll1443x_set_rate(struct clk_hw *hw,
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
+ /* Enable BYPASS */
+ tmp |= BYPASS_MASK;
+ writel_relaxed(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
@@ -283,16 +291,28 @@ static int clk_pll14xx_prepare(struct clk_hw *hw)
{
struct clk_pll14xx *pll = to_clk_pll14xx(hw);
u32 val;
+ int ret;
/*
* RESETB = 1 from 0, PLL starts its normal
* operation after lock time
*/
val = readl_relaxed(pll->base + GNRL_CTL);
+ if (val & RST_MASK)
+ return 0;
+ val |= BYPASS_MASK;
+ writel_relaxed(val, pll->base + GNRL_CTL);
val |= RST_MASK;
writel_relaxed(val, pll->base + GNRL_CTL);
- return clk_pll14xx_wait_lock(pll);
+ ret = clk_pll14xx_wait_lock(pll);
+ if (ret)
+ return ret;
+
+ val &= ~BYPASS_MASK;
+ writel_relaxed(val, pll->base + GNRL_CTL);
+
+ return 0;
}
static int clk_pll14xx_is_prepared(struct clk_hw *hw)
--
2.16.4
[PATCH V3 0/4] clk: imx8m: fix glitch/mux
From: Peng Fan V3: Add cover-letter V2: Added patch [2,3,4]/4 and avoid glitch when prepare There is two bypass bit in the pll, BYPASS and EXT_BYPASS. There is also a restriction that to avoid glitch, need set BYPASS bit when RESETB changed from 0 to 1, otherwise there will be glitch. However the BYPASS bit is also used as mux bit in imx8mm/imx8mn clk driver. This means two paths touch the same bit which is wrong. So switch to use EXT_BYPASS bit as the mux. Peng Fan (4): clk: imx: pll14xx: avoid glitch when set rate clk: imx: clk-pll14xx: unbypass PLL by default clk: imx: imx8mm: fix pll mux bit clk: imx: imx8mn: fix pll mux bit drivers/clk/imx/clk-imx8mm.c | 32 ++-- drivers/clk/imx/clk-imx8mn.c | 32 ++-- drivers/clk/imx/clk-pll14xx.c | 27 ++- 3 files changed, 46 insertions(+), 45 deletions(-) -- 2.16.4
RE: [PATCH 1/2] nvmem: imx: scu: support hole region check
> Subject: [PATCH 1/2] nvmem: imx: scu: support hole region check
Ping..
Thanks,
Peng.
>
> From: Peng Fan
>
> Introduce HOLE/ECC_REGION flag and in_hole helper to ease the check of
> hole region. The ECC_REGION is also introduced here which is preparing for
> programming support. ECC_REGION could only be programmed once, so need
> take care.
>
> Signed-off-by: Peng Fan
> ---
> drivers/nvmem/imx-ocotp-scu.c | 42
> +-
> 1 file changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
> index d9dc482ecb2f..2f339d7432e6 100644
> --- a/drivers/nvmem/imx-ocotp-scu.c
> +++ b/drivers/nvmem/imx-ocotp-scu.c
> @@ -18,9 +18,20 @@ enum ocotp_devtype {
> IMX8QXP,
> };
>
> +#define ECC_REGION BIT(0)
> +#define HOLE_REGION BIT(1)
> +
> +struct ocotp_region {
> + u32 start;
> + u32 end;
> + u32 flag;
> +};
> +
> struct ocotp_devtype_data {
> int devtype;
> int nregs;
> + u32 num_region;
> + struct ocotp_region region[];
> };
>
> struct ocotp_priv {
> @@ -37,8 +48,31 @@ struct imx_sc_msg_misc_fuse_read { static struct
> ocotp_devtype_data imx8qxp_data = {
> .devtype = IMX8QXP,
> .nregs = 800,
> + .num_region = 3,
> + .region = {
> + {0x10, 0x10f, ECC_REGION},
> + {0x110, 0x21F, HOLE_REGION},
> + {0x220, 0x31F, ECC_REGION},
> + },
> };
>
> +static bool in_hole(void *context, u32 index) {
> + struct ocotp_priv *priv = context;
> + const struct ocotp_devtype_data *data = priv->data;
> + int i;
> +
> + for (i = 0; i < data->num_region; i++) {
> + if (data->region[i].flag & HOLE_REGION) {
> + if ((index >= data->region[i].start) &&
> + (index <= data->region[i].end))
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
>u32 *val)
> {
> @@ -85,11 +119,9 @@ static int imx_scu_ocotp_read(void *context,
> unsigned int offset,
> buf = p;
>
> for (i = index; i < (index + count); i++) {
> - if (priv->data->devtype == IMX8QXP) {
> - if ((i > 271) && (i < 544)) {
> - *buf++ = 0;
> - continue;
> - }
> + if (in_hole(context, i)) {
> + *buf++ = 0;
> + continue;
> }
>
> ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
> --
> 2.16.4
RE: [PATCH 2/2] nvmem: imx: scu: support write
> Subject: [PATCH 2/2] nvmem: imx: scu: support write
Ping..
Thanks,
Peng.
>
> From: Peng Fan
>
> The fuse programming from non-secure world is blocked, so we could only use
> Arm Trusted Firmware SIP call to let ATF program fuse.
>
> Because there is ECC region that could only be programmed once, so add a
> heler in_ecc to check the ecc region.
>
> Signed-off-by: Peng Fan
> ---
>
> The ATF patch will soon be posted to ATF community.
>
> drivers/nvmem/imx-ocotp-scu.c | 73
> ++-
> 1 file changed, 72 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
> index 2f339d7432e6..0f064f2e74a8 100644
> --- a/drivers/nvmem/imx-ocotp-scu.c
> +++ b/drivers/nvmem/imx-ocotp-scu.c
> @@ -7,6 +7,7 @@
> * Peng Fan
> */
>
> +#include
> #include
> #include
> #include
> @@ -14,6 +15,9 @@
> #include
> #include
>
> +#define IMX_SIP_OTP 0xC20A
> +#define IMX_SIP_OTP_WRITE0x2
> +
> enum ocotp_devtype {
> IMX8QXP,
> };
> @@ -45,6 +49,8 @@ struct imx_sc_msg_misc_fuse_read {
> u32 word;
> } __packed;
>
> +static DEFINE_MUTEX(scu_ocotp_mutex);
> +
> static struct ocotp_devtype_data imx8qxp_data = {
> .devtype = IMX8QXP,
> .nregs = 800,
> @@ -73,6 +79,23 @@ static bool in_hole(void *context, u32 index)
> return false;
> }
>
> +static bool in_ecc(void *context, u32 index) {
> + struct ocotp_priv *priv = context;
> + const struct ocotp_devtype_data *data = priv->data;
> + int i;
> +
> + for (i = 0; i < data->num_region; i++) {
> + if (data->region[i].flag & ECC_REGION) {
> + if ((index >= data->region[i].start) &&
> + (index <= data->region[i].end))
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
>u32 *val)
> {
> @@ -116,6 +139,8 @@ static int imx_scu_ocotp_read(void *context,
> unsigned int offset,
> if (!p)
> return -ENOMEM;
>
> + mutex_lock(_ocotp_mutex);
> +
> buf = p;
>
> for (i = index; i < (index + count); i++) { @@ -126,6 +151,7 @@ static
> int
> imx_scu_ocotp_read(void *context, unsigned int offset,
>
> ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
> if (ret) {
> + mutex_unlock(_ocotp_mutex);
> kfree(p);
> return ret;
> }
> @@ -134,18 +160,63 @@ static int imx_scu_ocotp_read(void *context,
> unsigned int offset,
>
> memcpy(val, (u8 *)p + offset % 4, bytes);
>
> + mutex_unlock(_ocotp_mutex);
> +
> kfree(p);
>
> return 0;
> }
>
> +static int imx_scu_ocotp_write(void *context, unsigned int offset,
> +void *val, size_t bytes)
> +{
> + struct ocotp_priv *priv = context;
> + struct arm_smccc_res res;
> + u32 *buf = val;
> + u32 tmp;
> + u32 index;
> + int ret;
> +
> + /* allow only writing one complete OTP word at a time */
> + if ((bytes != 4) || (offset % 4))
> + return -EINVAL;
> +
> + index = offset >> 2;
> +
> + if (in_hole(context, index))
> + return -EINVAL;
> +
> + if (in_ecc(context, index)) {
> + pr_warn("ECC region, only program once\n");
> + mutex_lock(_ocotp_mutex);
> + ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, index, );
> + mutex_unlock(_ocotp_mutex);
> + if (ret)
> + return ret;
> + if (tmp) {
> + pr_warn("ECC region, already has value: %x\n", tmp);
> + return -EIO;
> + }
> + }
> +
> + mutex_lock(_ocotp_mutex);
> +
> + arm_smccc_smc(IMX_SIP_OTP, IMX_SIP_OTP_WRITE, index, *buf,
> + 0, 0, 0, 0, );
> +
> + mutex_unlock(_ocotp_mutex);
> +
> + return res.a0;
> +}
> +
> static struct nvmem_config imx_scu_ocotp_nvmem_config = {
> .name = "imx-scu-ocotp",
> - .read_only = true,
> + .read_only = false,
> .word_size = 4,
> .stride = 1,
> .owner = THIS_MODULE,
> .reg_read = imx_scu_ocotp_read,
> + .reg_write = imx_scu_ocotp_write,
> };
>
> static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
> --
> 2.16.4
RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
Hi Sudeep > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Fri, Aug 30, 2019 at 07:37:41AM +0000, Peng Fan wrote: > > Hi Jassi, > > > > I think there could be channel for TEE, and channel for Linux. > > > > For virtualization case, there could be dedicated channel for each VM. > > > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't > > > both be active at the same time, right? > > > > If I get your point correctly, > > On UP, both could not be active. On SMP, tx/rx could be both active, > > anyway this depends on secure firmware and Linux firmware design. > > > > Just to confirm, we can't have SMC/HVC based Rx channel as there's no > *architectural* way to achieve it. So it can be based on some interrupt from > secure side and hence will be a *different* type of channel/controller. > > Sorry to make this point repeatedly, but juts to be absolutely clear: > as it stands, SMC/HVC can be used only for Tx today. Since interrupt notification was dropped in v5, I need to drop RX description in v6. Thanks, Peng. > > -- > Regards, > Sudeep
RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Fri, Aug 30, 2019 at 3:07 AM Peng Fan wrote:
> >
> > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc
> > > for the ARM SMC/HVC mailbox
> > >
> > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan wrote:
> > > >
> > > > Hi Jassi,
> > > >
> > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding
> > > > > doc for the ARM SMC/HVC mailbox
> > > > >
> > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan wrote:
> > > > >
> > > > > > > > +examples:
> > > > > > > > + - |
> > > > > > > > +sram@91 {
> > > > > > > > + compatible = "mmio-sram";
> > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>;
> > > > > > > > + #address-cells = <1>;
> > > > > > > > + #size-cells = <1>;
> > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>;
> > > > > > > > +
> > > > > > > > + cpu_scp_lpri: scp-shmem@0 {
> > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > +reg = <0x0 0x200>;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + cpu_scp_hpri: scp-shmem@200 {
> > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > +reg = <0x200 0x200>;
> > > > > > > > + };
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +firmware {
> > > > > > > > + smc_mbox: mailbox {
> > > > > > > > +#mbox-cells = <1>;
> > > > > > > > +compatible = "arm,smc-mbox";
> > > > > > > > +method = "smc";
> > > > > > > > +arm,num-chans = <0x2>;
> > > > > > > > +transports = "mem";
> > > > > > > > +/* Optional */
> > > > > > > > +arm,func-ids = <0xc2fe>, <0xc2ff>;
> > > > > > > >
> > > > > > > SMC/HVC is synchronously(block) running in "secure mode",
> > > > > > > i.e, there can only be one instance running platform wide. Right?
> > > > > >
> > > > > > I think there could be channel for TEE, and channel for Linux.
> > > > > > For virtualization case, there could be dedicated channel for each
> VM.
> > > > > >
> > > > > I am talking from Linux pov. Functions 0xfe and 0xff above,
> > > > > can't both be active at the same time, right?
> > > >
> > > > If I get your point correctly,
> > > > On UP, both could not be active. On SMP, tx/rx could be both
> > > > active, anyway this depends on secure firmware and Linux firmware
> design.
> > > >
> > > > Do you have any suggestions about arm,func-ids here?
> > > >
> > > I was thinking if this is just an instruction, why can't each
> > > channel be represented as a controller, i.e, have exactly one func-id per
> controller node.
> > > Define as many controllers as you need channels ?
> >
> > I am ok, this could make driver code simpler. Something as below?
> >
> > smc_tx_mbox: tx_mbox {
> > #mbox-cells = <0>;
> > compatible = "arm,smc-mbox";
> > method = "smc";
> > transports = "mem";
> > arm,func-id = <0xc2fe>;
> > };
> >
> > smc_rx_mbox: rx_mbox {
> > #mbox-cells = <0>;
> > compatible = "arm,smc-mbox";
> > method = "smc";
> > transports = "mem";
> > arm,func-id = <0xc2ff>;
> > }
> >
> > firmware {
> > scmi {
> > compatible = "arm,scmi";
> > mboxes = <_tx_mbox>, <_rx_mbox 1>;
> > mbox-names = "tx", "rx";
> > shmem = <_scp_lpri>, <_scp_hpri>;
> > };
> > };
> >
> Yes, the channel part is good.
> But I am not convinced by the need to have SCMI specific "transport" mode.
SCMI spec only support shared memory message. However to make this driver
generic, need to take care of message using ARM registers.
If using shared memory message, the call will be
invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0, 0, 0);
If using ARM registers to transfer message, the call will be
invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
cmd->a4, cmd->a5, cmd->a6, cmd->a7);
So I added "transports" mode.
Code as below:
if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
if (chan_data->function_id != UINT_MAX)
function_id = chan_data->function_id;
else
function_id = cmd->a0;
chan_id = chan_data->chan_id;
ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
0, 0);
} else {
ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
cmd->a4, cmd->a5, cmd->a6, cmd->a7);
}
Per Sudeep's comments in previous version, better pass chan_id
to secure firmware.
If drop the "transports" mode, I do not have a good idea how to differentiate
the two cases, reg and mem. Any suggestions?
Thanks,
Peng.
>
> thanks
RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Fri, Aug 30, 2019 at 2:37 AM Peng Fan wrote:
> >
> > Hi Jassi,
> >
> > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc
> > > for the ARM SMC/HVC mailbox
> > >
> > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan wrote:
> > >
> > > > > > +examples:
> > > > > > + - |
> > > > > > +sram@91 {
> > > > > > + compatible = "mmio-sram";
> > > > > > + reg = <0x0 0x93f000 0x0 0x1000>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <1>;
> > > > > > + ranges = <0 0x0 0x93f000 0x1000>;
> > > > > > +
> > > > > > + cpu_scp_lpri: scp-shmem@0 {
> > > > > > +compatible = "arm,scmi-shmem";
> > > > > > +reg = <0x0 0x200>;
> > > > > > + };
> > > > > > +
> > > > > > + cpu_scp_hpri: scp-shmem@200 {
> > > > > > +compatible = "arm,scmi-shmem";
> > > > > > +reg = <0x200 0x200>;
> > > > > > + };
> > > > > > +};
> > > > > > +
> > > > > > +firmware {
> > > > > > + smc_mbox: mailbox {
> > > > > > +#mbox-cells = <1>;
> > > > > > +compatible = "arm,smc-mbox";
> > > > > > +method = "smc";
> > > > > > +arm,num-chans = <0x2>;
> > > > > > +transports = "mem";
> > > > > > +/* Optional */
> > > > > > +arm,func-ids = <0xc2fe>, <0xc2ff>;
> > > > > >
> > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e,
> > > > > there can only be one instance running platform wide. Right?
> > > >
> > > > I think there could be channel for TEE, and channel for Linux.
> > > > For virtualization case, there could be dedicated channel for each VM.
> > > >
> > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't
> > > both be active at the same time, right?
> >
> > If I get your point correctly,
> > On UP, both could not be active. On SMP, tx/rx could be both active,
> > anyway this depends on secure firmware and Linux firmware design.
> >
> > Do you have any suggestions about arm,func-ids here?
> >
> I was thinking if this is just an instruction, why can't each channel be
> represented as a controller, i.e, have exactly one func-id per controller
> node.
> Define as many controllers as you need channels ?
I am ok, this could make driver code simpler. Something as below?
smc_tx_mbox: tx_mbox {
#mbox-cells = <0>;
compatible = "arm,smc-mbox";
method = "smc";
transports = "mem";
arm,func-id = <0xc2fe>;
};
smc_rx_mbox: rx_mbox {
#mbox-cells = <0>;
compatible = "arm,smc-mbox";
method = "smc";
transports = "mem";
arm,func-id = <0xc2ff>;
};
firmware {
scmi {
compatible = "arm,scmi";
mboxes = <_tx_mbox>, <_rx_mbox 1>;
mbox-names = "tx", "rx";
shmem = <_scp_lpri>, <_scp_hpri>;
};
};
Thanks,
Peng.
>
> -j
RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
Hi Jassi,
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Fri, Aug 30, 2019 at 1:28 AM Peng Fan wrote:
>
> > > > +examples:
> > > > + - |
> > > > +sram@91 {
> > > > + compatible = "mmio-sram";
> > > > + reg = <0x0 0x93f000 0x0 0x1000>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + ranges = <0 0x0 0x93f000 0x1000>;
> > > > +
> > > > + cpu_scp_lpri: scp-shmem@0 {
> > > > +compatible = "arm,scmi-shmem";
> > > > +reg = <0x0 0x200>;
> > > > + };
> > > > +
> > > > + cpu_scp_hpri: scp-shmem@200 {
> > > > +compatible = "arm,scmi-shmem";
> > > > +reg = <0x200 0x200>;
> > > > + };
> > > > +};
> > > > +
> > > > +firmware {
> > > > + smc_mbox: mailbox {
> > > > +#mbox-cells = <1>;
> > > > +compatible = "arm,smc-mbox";
> > > > +method = "smc";
> > > > +arm,num-chans = <0x2>;
> > > > +transports = "mem";
> > > > +/* Optional */
> > > > +arm,func-ids = <0xc2fe>, <0xc2ff>;
> > > >
> > > SMC/HVC is synchronously(block) running in "secure mode", i.e, there
> > > can only be one instance running platform wide. Right?
> >
> > I think there could be channel for TEE, and channel for Linux.
> > For virtualization case, there could be dedicated channel for each VM.
> >
> I am talking from Linux pov. Functions 0xfe and 0xff above, can't both be
> active at the same time, right?
If I get your point correctly,
On UP, both could not be active. On SMP, tx/rx could be both active, anyway
this depends on secure firmware and Linux firmware design.
Do you have any suggestions about arm,func-ids here?
Thanks,
Peng.
RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
Hi Jassi, > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Tue, Aug 27, 2019 at 10:02 PM Peng Fan wrote: > > > > From: Peng Fan > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to > > trigger actions in software layers running in the EL2 or EL3 exception > > levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan > > --- > > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 > + > > 1 file changed, 125 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index ..f8eb28d5e307 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,125 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23data=02%7 > C01%7Cp > > > +eng.fan%40nxp.com%7C8aa671dfa4d04ba003b508d72d0f297f%7C686ea1d > 3bc2b4c > > > +6fa92cd99c5c301635%7C0%7C1%7C637027415448196145sdata=xd > nUObNqlRF > > +lu8NiXSuc35fYrHIzR%2Fyak6IzW05Q3nA%3Dreserved=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23data=02%7C01%7Cpe > ng.fan% > > > +40nxp.com%7C8aa671dfa4d04ba003b508d72d0f297f%7C686ea1d3bc2b4c6 > fa92cd9 > > > +9c5c301635%7C0%7C1%7C637027415448196145sdata=wl%2Fdg09 > QMS%2FoHgI > > +yD7ZBNpoIGXYxfFDRWhyYHogFd6A%3Dreserved=0 > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc > > +(hypervisor > > + call) instruction to trigger a mailbox-connected activity in > > +firmware, > > + executing on the very same core as the caller. By nature this > > +operation > > + is synchronous and this mailbox provides no way for asynchronous > > +messages > > + to be delivered the other way round, from firmware to the OS, but > > + asynchronous notification could also be supported. However the > > +value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a > > +received > > + message to the mailbox framework, so a synchronous communication > > +can be > > + established, for a asynchronous notification, no value will be returned. > > + The exact meaning of both the action the mailbox triggers as well > > +as the > > + return value is defined by their users and is not subject to this > > binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses > > + shared memory to transfer commands and parameters, and a mailbox > to > > + trigger a function call. This allows SoCs without a separate > > + management processor (or when such a processor is not available or > > + used) to use this standardized interface anyway. > > + > > + This binding describes no hardware, but establishes a firmware > interface. > > + Upon receiving an SMC using one of the described SMC function > > + identifiers, the firmware is expected to trigger some mailbox connected > functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The > > + supported identifiers are passed from consumers, or listed in the > > + the arm,func-ids properties as described below. The firmware can > > + return one value in the first SMC result register, it is expected > > + to be an error value, which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as > > + long as a firmware component running in EL3 or EL2 is handling these > calls. > > + > > +properties: > > + compatible: > > +const: arm,smc-mbox > > + > > + "#mbox-cells": > > +const: 1 > > + > > + arm,num-chans: > > +description: The number of channels supported. > > +items: > > + minimum: 1 > > +
RE: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
> Subject: Re: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Wed, Aug 28, 2019 at 03:03:02AM +0000, Peng Fan wrote:
> > From: Peng Fan
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7Ca1e96c6b782d43b2cfb208d72bc05898%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C637025977487779923sdata=rzC%2B4Y1c
> q9Y3tSDFR
> > %2Fsvf5ktk7INP2rwXN%2BXdWCVjNs%3Dreserved=0
> >
> > Cc: Andre Przywara
> > Signed-off-by: Peng Fan
> > ---
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 215
> > ++
> > 3 files changed, 224 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
>
> [...]
>
> > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > + struct device *dev = >dev;
> > + struct mbox_controller *mbox;
> > + struct arm_smc_chan_data *chan_data;
> > + const char *method;
> > + bool mem_trans = false;
> > + int ret, i;
> > + u32 val;
> > +
> > + if (!of_property_read_u32(dev->of_node, "arm,num-chans", )) {
> > + if (!val) {
> > + dev_err(dev, "invalid arm,num-chans value %u\n", val);
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + if (!of_property_read_string(dev->of_node, "transports", )) {
> > + if (!strcmp("mem", method)) {
> > + mem_trans = true;
> > + } else if (!strcmp("reg", method)) {
> > + mem_trans = false;
> > + } else {
> > + dev_warn(dev, "invalid \"transports\" property: %s\n",
> > +method);
> > +
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + if (!of_property_read_string(dev->of_node, "method", )) {
> > + if (!strcmp("hvc", method)) {
> > + invoke_smc_mbox_fn = __invoke_fn_hvc;
> > + } else if (!strcmp("smc", method)) {
> > + invoke_smc_mbox_fn = __invoke_fn_smc;
> > + } else {
> > + dev_warn(dev, "invalid \"method\" property: %s\n",
> > +method);
> > +
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> > + if (!mbox)
> > + return -ENOMEM;
> > +
> > + mbox->num_chans = val;
> > + mbox->chans = devm_kcalloc(dev, mbox->num_chans,
> sizeof(*mbox->chans),
> > + GFP_KERNEL);
> > + if (!mbox->chans)
> > + return -ENOMEM;
> > +
> > + chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
> > +GFP_KERNEL);
> > + if (!chan_data)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < mbox->num_chans; i++) {
> > + u32 function_id;
> > +
> > + ret = of_property_read_u32_index(dev->of_node,
> > +"arm,func-ids", i,
> > +_id);
>
> I missed it in binding but I thought we agreed to make this "arm,func-ids"
> a required property and not optional ?
Not sure Jassi is fine with it being a required property, but I could convert
it to a required property in V6.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan wrote: > > From: Peng Fan > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to > > trigger actions in software layers running in the EL2 or EL3 exception > > levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan > > --- > > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 > + > > 1 file changed, 125 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index ..f8eb28d5e307 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,125 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23data=02%7 > C01%7Cp > > > +eng.fan%40nxp.com%7C37aa729c94944730868b08d72bbfc121%7C686ea1 > d3bc2b4c > > > +6fa92cd99c5c301635%7C0%7C1%7C637025974936865698sdata=Inp > %2FLs39m > > +Gv1fe3dZMSaGmgmyWPT6awPh47s3mEtQ%2BQ%3Dreserved=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23data=02%7C01%7Cpe > ng.fan% > > > +40nxp.com%7C37aa729c94944730868b08d72bbfc121%7C686ea1d3bc2b4c > 6fa92cd9 > > > +9c5c301635%7C0%7C1%7C637025974936865698sdata=jmoR1Qqm7 > 6N5NwDbgFE > > +Fm8cpdW%2B%2FgqmG9mSGz9mXv58%3Dreserved=0 > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc > > +(hypervisor > > + call) instruction to trigger a mailbox-connected activity in > > +firmware, > > + executing on the very same core as the caller. By nature this > > +operation > > + is synchronous and this mailbox provides no way for asynchronous > > +messages > > + to be delivered the other way round, from firmware to the OS, but > > > > + asynchronous notification could also be supported. > > What do you mean by that ? I would prefer to drop the above line unless I am Ok. Dropped it in v6. > missing something. IMO it contradicts the previous statement less you > elaborate more on this. > > > However the value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a > > + received message to the mailbox framework, so a synchronous > > + communication can be established, for a asynchronous notification, no > value will be returned. > > I assume you refer to asynchronous communication from OS to firmware in > the above statement and "not asynchronous notification" from firmware to > OS. Since asynchronous notification dropped, so it should only be synchronous communication could be established. So I'll modify it as below: r0/w0/x0 the firmware returns after the smc call is delivered as a received message to the mailbox framework, so synchronous communication can be established > > > + The exact meaning of both the action the mailbox triggers as well > > + as the return value is defined by their users and is not subject to this > binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses > > + shared memory to transfer commands and parameters, and a mailbox > to > > + trigger a function call. This allows SoCs without a separate > > + management processor (or when such a processor is not available or > > + used) to use this standardized interface anyway. > > + > > Not sure if reference to SCMI is needed at all but I don't have any objections > to it, just thought worth mentioning. > > > + This binding describes no hardware, but establishes a firmware > interface. > > + Upon receiving an SMC using one of the described SMC function > > + identifiers, the firmware is expected to trigger some mailbox connected > functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The > > + supported identifiers are pas
RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
Hi Stefano,
> Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> On Wed, 28 Aug 2019, Peng Fan wrote:
> > Hi Robin,
> >
> > > Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> > >
> > > On 09/07/2019 09:22, Peng Fan wrote:
> > > > arm64 shares some code under arch/arm/xen, including mm.c.
> > > > However ZONE_DMA is removed by commit
> > > > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > > > So to ARM64, need use __GFP_DMA32.
>
> Hi Peng,
>
> Sorry for being so late in replying, this email got lost in the noise.
>
>
> > > > Signed-off-by: Peng Fan
> > > > ---
> > > > arch/arm/xen/mm.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > > > e1d44b903dfc..a95e76d18bf9 100644
> > > > --- a/arch/arm/xen/mm.c
> > > > +++ b/arch/arm/xen/mm.c
> > > > @@ -27,7 +27,7 @@ unsigned long
> > > > xen_get_swiotlb_free_pages(unsigned
> > > > int order)
> > > >
> > > > for_each_memblock(memory, reg) {
> > > > if (reg->base < (phys_addr_t)0x) {
> > > > - flags |= __GFP_DMA;
> > > > + flags |= __GFP_DMA | __GFP_DMA32;
> > >
> > > Given the definition of GFP_ZONE_BAD, I'm not sure this combination
> > > of flags is strictly valid, but rather is implicitly reliant on only
> > > one of those zones ever actually existing. As such, it seems liable
> > > to blow up if the plans to add ZONE_DMA to arm64[1] go ahead.
> >
> > How about this, or do you have any suggestions?
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > d33b77e9add3..f61c29a4430f 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -28,7 +28,11 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> > int order)
> >
> > for_each_memblock(memory, reg) {
> > if (reg->base < (phys_addr_t)0x) {
> > +#ifdef CONFIG_ARM64
> > + flags |= __GFP_DMA32; #else
> > flags |= __GFP_DMA;
> > +#endif
> > break;
> > }
> > }
>
> Yes I think this is the way to go, but we are trying not to add any #ifdef
> CONFIG_ARM64 under arch/arm. Maybe you could introduce a static inline
> function to set GFP_DMA:
>
> static inline void xen_set_gfp_dma(gfp_t *flags)
>
> it could be implemented under arch/arm/include/asm/xen/page.h for arm
> and under arch/arm64/include/asm/xen/page.h for arm64 using __GFP_DMA
> for the former and __GFP_DMA32 for the latter.
Thanks for your suggestion. I'll use this in V2.
Thanks,
Peng.
[PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan
The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Signed-off-by: Peng Fan
---
.../devicetree/bindings/mailbox/arm-smc.yaml | 125 +
1 file changed, 125 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index ..f8eb28d5e307
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+ - Peng Fan
+
+description: |
+ This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
+ call) instruction to trigger a mailbox-connected activity in firmware,
+ executing on the very same core as the caller. By nature this operation
+ is synchronous and this mailbox provides no way for asynchronous messages
+ to be delivered the other way round, from firmware to the OS, but
+ asynchronous notification could also be supported. However the value of
+ r0/w0/x0 the firmware returns after the smc call is delivered as a received
+ message to the mailbox framework, so a synchronous communication can be
+ established, for a asynchronous notification, no value will be returned.
+ The exact meaning of both the action the mailbox triggers as well as the
+ return value is defined by their users and is not subject to this binding.
+
+ One use case of this mailbox is the SCMI interface, which uses shared memory
+ to transfer commands and parameters, and a mailbox to trigger a function
+ call. This allows SoCs without a separate management processor (or when
+ such a processor is not available or used) to use this standardized
+ interface anyway.
+
+ This binding describes no hardware, but establishes a firmware interface.
+ Upon receiving an SMC using one of the described SMC function identifiers,
+ the firmware is expected to trigger some mailbox connected functionality.
+ The communication follows the ARM SMC calling convention.
+ Firmware expects an SMC function identifier in r0 or w0. The supported
+ identifiers are passed from consumers, or listed in the the arm,func-ids
+ properties as described below. The firmware can return one value in
+ the first SMC result register, it is expected to be an error value,
+ which shall be propagated to the mailbox client.
+
+ Any core which supports the SMC or HVC instruction can be used, as long as
+ a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+ compatible:
+const: arm,smc-mbox
+
+ "#mbox-cells":
+const: 1
+
+ arm,num-chans:
+description: The number of channels supported.
+items:
+ minimum: 1
+ maximum: 4096 # Should be enough?
+
+ method:
+- enum:
+- smc
+- hvc
+
+ transports:
+- enum:
+- mem
+- reg
+
+ arm,func-ids:
+description: |
+ An array of 32-bit values specifying the function IDs used by each
+ mailbox channel. Those function IDs follow the ARM SMC calling
+ convention standard [1].
+
+ There is one identifier per channel and the number of supported
+ channels is determined by the length of this array.
+$ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 0
+maxItems: 4096 # Should be enough?
+
+required:
+ - compatible
+ - "#mbox-cells"
+ - arm,num-chans
+ - transports
+ - method
+
+examples:
+ - |
+sram@91 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x93f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x93f000 0x1000>;
+
+ cpu_scp_lpri: scp-shmem@0 {
+compatible = "arm,scmi-shmem";
+reg = <0x0 0x200>;
+ };
+
+ cpu_scp_hpri: scp-shmem@200 {
+compatible = "arm,scmi-shmem";
+reg = <0x200 0x200>;
+ };
+};
+
+firmware {
+ smc_mbox: mailbox {
+#mbox-cells = <1>;
+compatible = "arm,smc-mbox";
+method = "smc";
+arm,num-chans = <0x2>;
+transports = "mem";
+/* Optional */
+arm,func-ids = <0xc2fe>, <0xc2ff>;
+ };
+
+ scmi {
+compatible = "arm,scmi";
+mboxes = <_mbox 0>, <_mbox 1>;
+mbox-names = "tx", "rx";
+shmem = <_scp_lpri>, <_scp_hpri>;
+ };
+};
+
+...
--
2.16.4
[PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.
Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/
Cc: Andre Przywara
Signed-off-by: Peng Fan
---
drivers/mailbox/Kconfig | 7 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 215 ++
3 files changed, 224 insertions(+)
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config ARM_SMC_MBOX
+ tristate "Generic ARM smc mailbox"
+ depends on OF && HAVE_ARM_SMCCC
+ help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..76a2ae11ee4d
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
+
+struct arm_smc_chan_data {
+ u32 function_id;
+ u32 chan_id;
+ u32 flags;
+};
+
+struct arm_smccc_mbox_cmd {
+ unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+ struct arm_smc_chan_data *chan_data = link->con_priv;
+ struct arm_smccc_mbox_cmd *cmd = data;
+ unsigned long ret;
+ u32 function_id;
+ u32 chan_id;
+
+ if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
+ if (chan_data->function_id != UINT_MAX)
+ function_id = chan_data->function_id;
+ else
+ function_id = cmd->a0;
+ chan_id = chan_data->chan_id;
+ ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
+0, 0);
+ } else {
+ ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
+cmd->a4, cmd->a5, cmd->a6, cmd->a7);
+ }
+
+ mbox_chan_received_data(link, (void *)ret);
+
+ return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, );
+ return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, );
+ re
[PATCH v5 0/2] mailbox: arm: introduce smc triggered mailbox
From: Peng Fan V5: yaml fix V4: yaml fix for num-chans in patch 1/2. https://patchwork.kernel.org/cover/6521/ V3: Drop interrupt Introduce transports for mem/reg usage Add chan-id for mem usage Convert to yaml format https://patchwork.kernel.org/cover/11043541/ V2: This is a modified version from Andre Przywara's patch series https://lore.kernel.org/patchwork/cover/812997/. The modification are mostly: Introduce arm,num-chans Introduce arm_smccc_mbox_cmd txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as an optional property. Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. Introduce interrupts notification. [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use smc as mailbox, power/clk is included, but only part of clk has been implemented to work with hardware, power domain only supports get name for now. The traditional Linux mailbox mechanism uses some kind of dedicated hardware IP to signal a condition to some other processing unit, typically a dedicated management processor. This mailbox feature is used for instance by the SCMI protocol to signal a request for some action to be taken by the management processor. However some SoCs does not have a dedicated management core to provide those services. In order to service TEE and to avoid linux shutdown power and clock that used by TEE, need let firmware to handle power and clock, the firmware here is ARM Trusted Firmware that could also run SCMI service. The existing SCMI implementation uses a rather flexible shared memory region to communicate commands and their parameters, it still requires a mailbox to actually trigger the action. This patch series provides a Linux mailbox compatible service which uses smc calls to invoke firmware code, for instance taking care of SCMI requests. The actual requests are still communicated using the standard SCMI way of shared memory regions, but a dedicated mailbox hardware IP can be replaced via this new driver. This simple driver uses the architected SMC calling convention to trigger firmware services, also allows for using "HVC" calls to call into hypervisors or firmware layers running in the EL2 exception level. Patch 1 contains the device tree binding documentation, patch 2 introduces the actual mailbox driver. Please note that this driver just provides a generic mailbox mechanism, It could support synchronous TX/RX, or synchronous TX with asynchronous RX. And while providing SCMI services was the reason for this exercise, this driver is in no way bound to this use case, but can be used generically where the OS wants to signal a mailbox condition to firmware or a hypervisor. Also the driver is in no way meant to replace any existing firmware interface, but actually to complement existing interfaces. [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi Peng Fan (2): dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox mailbox: introduce ARM SMC based mailbox .../devicetree/bindings/mailbox/arm-smc.yaml | 125 drivers/mailbox/Kconfig| 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 215 + 4 files changed, 349 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml create mode 100644 drivers/mailbox/arm-smc-mailbox.c -- 2.16.4
RE: [PATCH v4 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
Hi Rob, > Subject: Re: [PATCH v4 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Tue, Aug 27, 2019 at 4:51 AM Peng Fan wrote: > > > > From: Peng Fan > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to > > trigger actions in software layers running in the EL2 or EL3 exception > > levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan > > --- > > .../devicetree/bindings/mailbox/arm-smc.yaml | 126 > + > > 1 file changed, 126 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index ..ae677e0c0910 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,126 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23data=02%7 > C01%7Cp > > > +eng.fan%40nxp.com%7C0e905f3fe89b4dc9ee0608d72af06e30%7C686ea1d > 3bc2b4c > > > +6fa92cd99c5c301635%7C0%7C0%7C637025084458964761sdata=p8 > EeFkU5pW3 > > +D8bzpZu9IHCoFD%2F2ZBcSr6WyCsIK9LqU%3Dreserved=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23data=02%7C01%7Cpe > ng.fan% > > > +40nxp.com%7C0e905f3fe89b4dc9ee0608d72af06e30%7C686ea1d3bc2b4c6 > fa92cd9 > > > +9c5c301635%7C0%7C0%7C637025084458964761sdata=JFhz7meFyG > ozMLnt4Jb > > +RGneYty6cBSCKyxHpl26TAsI%3Dreserved=0 > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc > > +(hypervisor > > + call) instruction to trigger a mailbox-connected activity in > > +firmware, > > + executing on the very same core as the caller. By nature this > > +operation > > + is synchronous and this mailbox provides no way for asynchronous > > +messages > > + to be delivered the other way round, from firmware to the OS, but > > + asynchronous notification could also be supported. However the > > +value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a > > +received > > + message to the mailbox framework, so a synchronous communication > > +can be > > + established, for a asynchronous notification, no value will be returned. > > + The exact meaning of both the action the mailbox triggers as well > > +as the > > + return value is defined by their users and is not subject to this > > binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses > > + shared memory to transfer commands and parameters, and a mailbox > to > > + trigger a function call. This allows SoCs without a separate > > + management processor (or when such a processor is not available or > > + used) to use this standardized interface anyway. > > + > > + This binding describes no hardware, but establishes a firmware > interface. > > + Upon receiving an SMC using one of the described SMC function > > + identifiers, the firmware is expected to trigger some mailbox connected > functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The > > + supported identifiers are passed from consumers, or listed in the > > + the arm,func-ids properties as described below. The firmware can > > + return one value in the first SMC result register, it is expected > > + to be an error value, which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as > > + long as a firmware component running in EL3 or EL2 is handling these > calls. > > + > > +properties: > > + compatible: > > +const: arm,smc-mbox > > + > > + "#mbox-cells": > > +const: 1 > > + > > + arm,num-chans: > > +description: The number of channels supported. > > +items: > > + minimum: 1 > > + maximum: 4096 # Sho
RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
Hi Robin,
> Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> On 09/07/2019 09:22, Peng Fan wrote:
> > arm64 shares some code under arch/arm/xen, including mm.c.
> > However ZONE_DMA is removed by commit
> > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > So to ARM64, need use __GFP_DMA32.
> >
> > Signed-off-by: Peng Fan
> > ---
> > arch/arm/xen/mm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > e1d44b903dfc..a95e76d18bf9 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> > int order)
> >
> > for_each_memblock(memory, reg) {
> > if (reg->base < (phys_addr_t)0x) {
> > - flags |= __GFP_DMA;
> > + flags |= __GFP_DMA | __GFP_DMA32;
>
> Given the definition of GFP_ZONE_BAD, I'm not sure this combination of flags
> is strictly valid, but rather is implicitly reliant on only one of those
> zones ever
> actually existing. As such, it seems liable to blow up if the plans to add
> ZONE_DMA to arm64[1] go ahead.
How about this, or do you have any suggestions?
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d33b77e9add3..f61c29a4430f 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -28,7 +28,11 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
for_each_memblock(memory, reg) {
if (reg->base < (phys_addr_t)0x) {
+#ifdef CONFIG_ARM64
+ flags |= __GFP_DMA32;
+#else
flags |= __GFP_DMA;
+#endif
break;
}
}
Thanks,
Peng.
>
> Robin.
>
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Flinux-arm-kernel%2F20190820145821.27214-1-nsaenzjulienne%
> 40suse.de%2Fdata=02%7C01%7Cpeng.fan%40nxp.com%7C5d2a641b1
> e3f449562f908d72ae95d85%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7C637025054169859035sdata=1ZPGH0gZnvgmlMpX7VrjUNME
> XbEjiv4%2FZ9pYwTQTWxY%3Dreserved=0
>
> > break;
> > }
> > }
> >
[PATCH v4 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.
Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/
Cc: Andre Przywara
Signed-off-by: Peng Fan
---
drivers/mailbox/Kconfig | 7 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 215 ++
3 files changed, 224 insertions(+)
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config ARM_SMC_MBOX
+ tristate "Generic ARM smc mailbox"
+ depends on OF && HAVE_ARM_SMCCC
+ help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..76a2ae11ee4d
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
+
+struct arm_smc_chan_data {
+ u32 function_id;
+ u32 chan_id;
+ u32 flags;
+};
+
+struct arm_smccc_mbox_cmd {
+ unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+ struct arm_smc_chan_data *chan_data = link->con_priv;
+ struct arm_smccc_mbox_cmd *cmd = data;
+ unsigned long ret;
+ u32 function_id;
+ u32 chan_id;
+
+ if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
+ if (chan_data->function_id != UINT_MAX)
+ function_id = chan_data->function_id;
+ else
+ function_id = cmd->a0;
+ chan_id = chan_data->chan_id;
+ ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
+0, 0);
+ } else {
+ ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
+cmd->a4, cmd->a5, cmd->a6, cmd->a7);
+ }
+
+ mbox_chan_received_data(link, (void *)ret);
+
+ return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, );
+ return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, );
+ re
[PATCH v4 0/2] mailbox: arm: introduce smc triggered mailbox
From: Peng Fan V4: yaml fix for num-chans in patch 1/2. V3: Drop interrupt Introduce transports for mem/reg usage Add chan-id for mem usage Convert to yaml format https://patchwork.kernel.org/cover/11043541/ V2: This is a modified version from Andre Przywara's patch series https://lore.kernel.org/patchwork/cover/812997/. The modification are mostly: Introduce arm,num-chans Introduce arm_smccc_mbox_cmd txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as an optional property. Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. Introduce interrupts notification. [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use smc as mailbox, power/clk is included, but only part of clk has been implemented to work with hardware, power domain only supports get name for now. The traditional Linux mailbox mechanism uses some kind of dedicated hardware IP to signal a condition to some other processing unit, typically a dedicated management processor. This mailbox feature is used for instance by the SCMI protocol to signal a request for some action to be taken by the management processor. However some SoCs does not have a dedicated management core to provide those services. In order to service TEE and to avoid linux shutdown power and clock that used by TEE, need let firmware to handle power and clock, the firmware here is ARM Trusted Firmware that could also run SCMI service. The existing SCMI implementation uses a rather flexible shared memory region to communicate commands and their parameters, it still requires a mailbox to actually trigger the action. This patch series provides a Linux mailbox compatible service which uses smc calls to invoke firmware code, for instance taking care of SCMI requests. The actual requests are still communicated using the standard SCMI way of shared memory regions, but a dedicated mailbox hardware IP can be replaced via this new driver. This simple driver uses the architected SMC calling convention to trigger firmware services, also allows for using "HVC" calls to call into hypervisors or firmware layers running in the EL2 exception level. Patch 1 contains the device tree binding documentation, patch 2 introduces the actual mailbox driver. Please note that this driver just provides a generic mailbox mechanism, It could support synchronous TX/RX, or synchronous TX with asynchronous RX. And while providing SCMI services was the reason for this exercise, this driver is in no way bound to this use case, but can be used generically where the OS wants to signal a mailbox condition to firmware or a hypervisor. Also the driver is in no way meant to replace any existing firmware interface, but actually to complement existing interfaces. [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi Peng Fan (2): dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox mailbox: introduce ARM SMC based mailbox .../devicetree/bindings/mailbox/arm-smc.yaml | 126 drivers/mailbox/Kconfig| 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 215 + 4 files changed, 350 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml create mode 100644 drivers/mailbox/arm-smc-mailbox.c -- 2.16.4
[PATCH v4 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan
The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Signed-off-by: Peng Fan
---
.../devicetree/bindings/mailbox/arm-smc.yaml | 126 +
1 file changed, 126 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index ..ae677e0c0910
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+ - Peng Fan
+
+description: |
+ This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
+ call) instruction to trigger a mailbox-connected activity in firmware,
+ executing on the very same core as the caller. By nature this operation
+ is synchronous and this mailbox provides no way for asynchronous messages
+ to be delivered the other way round, from firmware to the OS, but
+ asynchronous notification could also be supported. However the value of
+ r0/w0/x0 the firmware returns after the smc call is delivered as a received
+ message to the mailbox framework, so a synchronous communication can be
+ established, for a asynchronous notification, no value will be returned.
+ The exact meaning of both the action the mailbox triggers as well as the
+ return value is defined by their users and is not subject to this binding.
+
+ One use case of this mailbox is the SCMI interface, which uses shared memory
+ to transfer commands and parameters, and a mailbox to trigger a function
+ call. This allows SoCs without a separate management processor (or when
+ such a processor is not available or used) to use this standardized
+ interface anyway.
+
+ This binding describes no hardware, but establishes a firmware interface.
+ Upon receiving an SMC using one of the described SMC function identifiers,
+ the firmware is expected to trigger some mailbox connected functionality.
+ The communication follows the ARM SMC calling convention.
+ Firmware expects an SMC function identifier in r0 or w0. The supported
+ identifiers are passed from consumers, or listed in the the arm,func-ids
+ properties as described below. The firmware can return one value in
+ the first SMC result register, it is expected to be an error value,
+ which shall be propagated to the mailbox client.
+
+ Any core which supports the SMC or HVC instruction can be used, as long as
+ a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+ compatible:
+const: arm,smc-mbox
+
+ "#mbox-cells":
+const: 1
+
+ arm,num-chans:
+description: The number of channels supported.
+items:
+ minimum: 1
+ maximum: 4096 # Should be enough?
+
+ method:
+items:
+ - enum:
+ - smc
+ - hvc
+
+ transports:
+items:
+ - enum:
+ - mem
+ - reg
+
+ arm,func-ids:
+description: |
+ An array of 32-bit values specifying the function IDs used by each
+ mailbox channel. Those function IDs follow the ARM SMC calling
+ convention standard [1].
+
+ There is one identifier per channel and the number of supported
+ channels is determined by the length of this array.
+minItems: 0
+maxItems: 4096 # Should be enough?
+
+required:
+ - compatible
+ - "#mbox-cells"
+ - arm,num-chans
+ - transports
+ - method
+
+examples:
+ - |
+sram@91 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x93f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x93f000 0x1000>;
+
+cpu_scp_lpri: scp-shmem@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x200>;
+};
+
+cpu_scp_hpri: scp-shmem@200 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x200 0x200>;
+};
+};
+
+firmware {
+ smc_mbox: mailbox {
+#mbox-cells = <1>;
+compatible = "arm,smc-mbox";
+method = "smc";
+arm,num-chans = <0x2>;
+transports = "mem";
+/* Optional */
+arm,func-ids = <0xc2fe>, <0xc2ff>;
+ };
+
+ scmi {
+compatible = "arm,scmi";
+mboxes = < 0 1>;
+mbox-names = "tx", "rx";
+shmem = <_scp_lpri _scp_hpri>;
+ };
+};
+
+...
--
2.16.4
RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
Ping again..
+Julien
> Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> Hi Russell, Stefano
>
> > Subject: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> Any comments?
>
> >
> > arm64 shares some code under arch/arm/xen, including mm.c.
> > However ZONE_DMA is removed by commit
> > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > So to ARM64, need use __GFP_DMA32.
> >
> > Signed-off-by: Peng Fan
> > ---
> > arch/arm/xen/mm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > e1d44b903dfc..a95e76d18bf9 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> int
> > order)
> >
> > for_each_memblock(memory, reg) {
> > if (reg->base < (phys_addr_t)0x) {
> > - flags |= __GFP_DMA;
> > + flags |= __GFP_DMA | __GFP_DMA32;
> > break;
> > }
> > }
>
> Thanks,
> Peng.
Thanks,
Peng.
>
> > --
> > 2.16.4
[PATCH] clk: imx: lpcg: write twice when writing lpcg regs
From: Peng Fan There is hardware issue that: The output clock the LPCG cell will not turn back on as expected, even though a read of the IPG registers in the LPCG indicates that the clock should be enabled. The software workaround is to write twice to enable the LPCG clock output. Signed-off-by: Peng Fan --- drivers/clk/imx/clk-lpcg-scu.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/clk/imx/clk-lpcg-scu.c b/drivers/clk/imx/clk-lpcg-scu.c index a73a799fb777..7391d0668ec4 100644 --- a/drivers/clk/imx/clk-lpcg-scu.c +++ b/drivers/clk/imx/clk-lpcg-scu.c @@ -54,6 +54,11 @@ static int clk_lpcg_scu_enable(struct clk_hw *hw) reg |= val << clk->bit_idx; writel(reg, clk->reg); + /* +* There is hardware bug. When enabling the LPCG clock +* output, SW can write the enabling value twice +*/ + writel(reg, clk->reg); spin_unlock_irqrestore(_lpcg_scu_lock, flags); @@ -71,6 +76,11 @@ static void clk_lpcg_scu_disable(struct clk_hw *hw) reg = readl_relaxed(clk->reg); reg &= ~(CLK_GATE_SCU_LPCG_MASK << clk->bit_idx); writel(reg, clk->reg); + /* +* There is hardware bug. When enabling the LPCG clock +* output, SW can write the enabling value twice +*/ + writel(reg, clk->reg); spin_unlock_irqrestore(_lpcg_scu_lock, flags); } -- 2.16.4
[PATCH V2 4/4] clk: imx: imx8mn: fix pll mux bit
From: Peng Fan
pll BYPASS bit should be kept inside pll driver for glitchless freq
setting following spec. If exposing the bit, that means pll driver and
clk driver has two paths to touch this bit, which is wrong.
So use EXT_BYPASS bit here.
And drop uneeded set parent, because EXT_BYPASS default is 0.
Suggested-by: Jacky Bai
Reviewed-by: Leonard Crestez
Signed-off-by: Peng Fan
---
V2:
New patch
drivers/clk/imx/clk-imx8mn.c | 32 ++--
1 file changed, 10 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index f41116d59749..f767d18679ea 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -421,28 +421,16 @@ static int imx8mn_clocks_probe(struct platform_device
*pdev)
clks[IMX8MN_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel",
base + 0x114, _sys_pll);
/* PLL bypass out */
- clks[IMX8MN_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass",
base, 4, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass",
base + 0x14, 4, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass",
base + 0x28, 4, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass",
base + 0x50, 4, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base
+ 0x64, 4, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base
+ 0x74, 4, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base
+ 0x84, 4, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_SYS_PLL1_BYPASS] = imx_clk_mux_flags("sys_pll1_bypass",
base + 0x94, 4, 1, sys_pll1_bypass_sels, ARRAY_SIZE(sys_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_SYS_PLL2_BYPASS] = imx_clk_mux_flags("sys_pll2_bypass",
base + 0x104, 4, 1, sys_pll2_bypass_sels, ARRAY_SIZE(sys_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MN_SYS_PLL3_BYPASS] = imx_clk_mux_flags("sys_pll3_bypass",
base + 0x114, 4, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels),
CLK_SET_RATE_PARENT);
-
- /* unbypass all the plls */
- clk_set_parent(clks[IMX8MN_AUDIO_PLL1_BYPASS], clks[IMX8MN_AUDIO_PLL1]);
- clk_set_parent(clks[IMX8MN_AUDIO_PLL2_BYPASS], clks[IMX8MN_AUDIO_PLL2]);
- clk_set_parent(clks[IMX8MN_VIDEO_PLL1_BYPASS], clks[IMX8MN_VIDEO_PLL1]);
- clk_set_parent(clks[IMX8MN_DRAM_PLL_BYPASS], clks[IMX8MN_DRAM_PLL]);
- clk_set_parent(clks[IMX8MN_GPU_PLL_BYPASS], clks[IMX8MN_GPU_PLL]);
- clk_set_parent(clks[IMX8MN_VPU_PLL_BYPASS], clks[IMX8MN_VPU_PLL]);
- clk_set_parent(clks[IMX8MN_ARM_PLL_BYPASS], clks[IMX8MN_ARM_PLL]);
- clk_set_parent(clks[IMX8MN_SYS_PLL1_BYPASS], clks[IMX8MN_SYS_PLL1]);
- clk_set_parent(clks[IMX8MN_SYS_PLL2_BYPASS], clks[IMX8MN_SYS_PLL2]);
- clk_set_parent(clks[IMX8MN_SYS_PLL3_BYPASS], clks[IMX8MN_SYS_PLL3]);
+ clks[IMX8MN_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass",
base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass",
base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass",
base + 0x28, 16, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass",
base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base
+ 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base
+ 0x74, 28, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base
+ 0x84, 28, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MN_SYS_PLL1_BYPASS] = imx_clk_mux_flags(&q
[PATCH V2 3/4] clk: imx: imx8mm: fix pll mux bit
From: Peng Fan
pll BYPASS bit should be kept inside pll driver for glitchless freq
setting following spec. If exposing the bit, that means pll driver and
clk driver has two paths to touch this bit, which is wrong.
So use EXT_BYPASS bit here.
And drop uneeded set parent, because EXT_BYPASS default is 0.
Fixes: ba5625c3e272 ("clk: imx: Add clock driver support for imx8mm")
Suggested-by: Jacky Bai
Reviewed-by: Leonard Crestez
Signed-off-by: Peng Fan
---
V2:
New patch
drivers/clk/imx/clk-imx8mm.c | 32 ++--
1 file changed, 10 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 2758e3f0d15d..067ab876911d 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -408,28 +408,16 @@ static int imx8mm_clocks_probe(struct platform_device
*pdev)
clks[IMX8MM_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel",
base + 0x114, _sys_pll);
/* PLL bypass out */
- clks[IMX8MM_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass",
base, 4, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass",
base + 0x14, 4, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass",
base + 0x28, 4, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass",
base + 0x50, 4, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base
+ 0x64, 4, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base
+ 0x74, 4, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base
+ 0x84, 4, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_SYS_PLL1_BYPASS] = imx_clk_mux_flags("sys_pll1_bypass",
base + 0x94, 4, 1, sys_pll1_bypass_sels, ARRAY_SIZE(sys_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_SYS_PLL2_BYPASS] = imx_clk_mux_flags("sys_pll2_bypass",
base + 0x104, 4, 1, sys_pll2_bypass_sels, ARRAY_SIZE(sys_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
- clks[IMX8MM_SYS_PLL3_BYPASS] = imx_clk_mux_flags("sys_pll3_bypass",
base + 0x114, 4, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels),
CLK_SET_RATE_PARENT);
-
- /* unbypass all the plls */
- clk_set_parent(clks[IMX8MM_AUDIO_PLL1_BYPASS], clks[IMX8MM_AUDIO_PLL1]);
- clk_set_parent(clks[IMX8MM_AUDIO_PLL2_BYPASS], clks[IMX8MM_AUDIO_PLL2]);
- clk_set_parent(clks[IMX8MM_VIDEO_PLL1_BYPASS], clks[IMX8MM_VIDEO_PLL1]);
- clk_set_parent(clks[IMX8MM_DRAM_PLL_BYPASS], clks[IMX8MM_DRAM_PLL]);
- clk_set_parent(clks[IMX8MM_GPU_PLL_BYPASS], clks[IMX8MM_GPU_PLL]);
- clk_set_parent(clks[IMX8MM_VPU_PLL_BYPASS], clks[IMX8MM_VPU_PLL]);
- clk_set_parent(clks[IMX8MM_ARM_PLL_BYPASS], clks[IMX8MM_ARM_PLL]);
- clk_set_parent(clks[IMX8MM_SYS_PLL1_BYPASS], clks[IMX8MM_SYS_PLL1]);
- clk_set_parent(clks[IMX8MM_SYS_PLL2_BYPASS], clks[IMX8MM_SYS_PLL2]);
- clk_set_parent(clks[IMX8MM_SYS_PLL3_BYPASS], clks[IMX8MM_SYS_PLL3]);
+ clks[IMX8MM_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass",
base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass",
base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass",
base + 0x28, 16, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass",
base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base
+ 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base
+ 0x74, 28, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels),
CLK_SET_RATE_PARENT);
+ clks[IMX8MM_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base
+ 0x84, 28, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sel
[PATCH V2 2/4] clk: imx: clk-pll14xx: unbypass PLL by default
From: Peng Fan
When registering the PLL, unbypass the PLL.
The PLL has two bypass control bit, BYPASS and EXT_BYPASS.
we will expose EXT_BYPASS to clk driver for mux usage, and keep
BYPASS inside pll14xx usage. The PLL has a restriction that
when M/P change, need to RESET/BYPASS pll to avoid glitch, so
we could not expose BYPASS.
To make it easy for clk driver usage, unbypass PLL which does
not hurt current function.
Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Reviewed-by: Leonard Crestez
Signed-off-by: Peng Fan
---
V2:
New patch
drivers/clk/imx/clk-pll14xx.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index 656f48b002dd..7a815ec76aa5 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -368,6 +368,7 @@ struct clk *imx_clk_pll14xx(const char *name, const char
*parent_name,
struct clk_pll14xx *pll;
struct clk *clk;
struct clk_init_data init;
+ u32 val;
pll = kzalloc(sizeof(*pll), GFP_KERNEL);
if (!pll)
@@ -399,6 +400,10 @@ struct clk *imx_clk_pll14xx(const char *name, const char
*parent_name,
pll->rate_table = pll_clk->rate_table;
pll->rate_count = pll_clk->rate_count;
+ val = readl_relaxed(pll->base + GNRL_CTL);
+ val &= ~BYPASS_MASK;
+ writel_relaxed(val, pll->base + GNRL_CTL);
+
clk = clk_register(NULL, >hw);
if (IS_ERR(clk)) {
pr_err("%s: failed to register pll %s %lu\n",
--
2.16.4
[PATCH V2 1/4] clk: imx: pll14xx: avoid glitch when set rate
From: Peng Fan
According to PLL1443XA and PLL1416X spec,
"When BYPASS is 0 and RESETB is changed from 0 to 1, FOUT starts to
output unstable clock until lock time passes. PLL1416X/PLL1443XA may
generate a glitch at FOUT."
So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch.
In the end of set rate, BYPASS will be cleared.
When prepare clock, also need to take care to avoid glitch. So
we also follow Spec to set BYPASS before RESETB changed from 0 to 1.
And add a check if the RESETB is already 0, directly return 0;
Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Reviewed-by: Leonard Crestez
Signed-off-by: Peng Fan
---
V2:
Avoid glitch when prepare
update commit log
drivers/clk/imx/clk-pll14xx.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index b7213023b238..656f48b002dd 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -191,6 +191,10 @@ static int clk_pll1416x_set_rate(struct clk_hw *hw,
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
+ /* Enable BYPASS */
+ tmp |= BYPASS_MASK;
+ writel(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
@@ -250,6 +254,10 @@ static int clk_pll1443x_set_rate(struct clk_hw *hw,
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
+ /* Enable BYPASS */
+ tmp |= BYPASS_MASK;
+ writel_relaxed(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
@@ -283,16 +291,28 @@ static int clk_pll14xx_prepare(struct clk_hw *hw)
{
struct clk_pll14xx *pll = to_clk_pll14xx(hw);
u32 val;
+ int ret;
/*
* RESETB = 1 from 0, PLL starts its normal
* operation after lock time
*/
val = readl_relaxed(pll->base + GNRL_CTL);
+ if (val & RST_MASK)
+ return 0;
+ val |= BYPASS_MASK;
+ writel_relaxed(val, pll->base + GNRL_CTL);
val |= RST_MASK;
writel_relaxed(val, pll->base + GNRL_CTL);
- return clk_pll14xx_wait_lock(pll);
+ ret = clk_pll14xx_wait_lock(pll);
+ if (ret)
+ return ret;
+
+ val &= ~BYPASS_MASK;
+ writel_relaxed(val, pll->base + GNRL_CTL);
+
+ return 0;
}
static int clk_pll14xx_is_prepared(struct clk_hw *hw)
--
2.16.4
RE: [PATCH] clk: imx: pll14xx: avoid glitch when set rate
> Subject: Re: [PATCH] clk: imx: pll14xx: avoid glitch when set rate > > On 20.08.2019 05:17, Peng Fan wrote: > > According to PLL1443XA and PLL1416X spec, "When BYPASS is 0 and RESETB > > is changed from 0 to 1, FOUT starts to output unstable clock until > > lock time passes. PLL1416X/PLL1443XA may generate a glitch at FOUT." > > > > So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch. > > In the end of set rate, BYPASS will be cleared. > > > > @@ -191,6 +191,10 @@ static int clk_pll1416x_set_rate(struct clk_hw *hw, > unsigned long drate, > > tmp &= ~RST_MASK; > > writel_relaxed(tmp, pll->base); > > > > + /* Enable BYPASS */ > > + tmp |= BYPASS_MASK; > > + writel(tmp, pll->base); > > + > > Shouldn't BYPASS be set before reset? No. the glitch happens when RESET changes from 0 to 1, not from 1 to 0. > > Also, isn't a similar bypass/unbypass dance also needed in > clk_pll14xx_prepare? As far as I understand that could also output glitches > until the PLL is locked. It could be a separate patch. Yes, that might also output glitch. Fix in v2. > > It's strange that this BYPASS bit is also handled by muxes like > audio_pll1_bypass in clk-imx8mm.c but that's a separate issue not strictly > related to the glitches you're trying to fix here. Yes, need use EXT_BYPASS for the mux usage. Regards, Peng. > > -- > Regards, > Leonard
[PATCH 1/2] nvmem: imx: scu: support hole region check
From: Peng Fan
Introduce HOLE/ECC_REGION flag and in_hole helper to ease the check
of hole region. The ECC_REGION is also introduced here which is
preparing for programming support. ECC_REGION could only be programmed
once, so need take care.
Signed-off-by: Peng Fan
---
drivers/nvmem/imx-ocotp-scu.c | 42 +-
1 file changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
index d9dc482ecb2f..2f339d7432e6 100644
--- a/drivers/nvmem/imx-ocotp-scu.c
+++ b/drivers/nvmem/imx-ocotp-scu.c
@@ -18,9 +18,20 @@ enum ocotp_devtype {
IMX8QXP,
};
+#define ECC_REGION BIT(0)
+#define HOLE_REGIONBIT(1)
+
+struct ocotp_region {
+ u32 start;
+ u32 end;
+ u32 flag;
+};
+
struct ocotp_devtype_data {
int devtype;
int nregs;
+ u32 num_region;
+ struct ocotp_region region[];
};
struct ocotp_priv {
@@ -37,8 +48,31 @@ struct imx_sc_msg_misc_fuse_read {
static struct ocotp_devtype_data imx8qxp_data = {
.devtype = IMX8QXP,
.nregs = 800,
+ .num_region = 3,
+ .region = {
+ {0x10, 0x10f, ECC_REGION},
+ {0x110, 0x21F, HOLE_REGION},
+ {0x220, 0x31F, ECC_REGION},
+ },
};
+static bool in_hole(void *context, u32 index)
+{
+ struct ocotp_priv *priv = context;
+ const struct ocotp_devtype_data *data = priv->data;
+ int i;
+
+ for (i = 0; i < data->num_region; i++) {
+ if (data->region[i].flag & HOLE_REGION) {
+ if ((index >= data->region[i].start) &&
+ (index <= data->region[i].end))
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
u32 *val)
{
@@ -85,11 +119,9 @@ static int imx_scu_ocotp_read(void *context, unsigned int
offset,
buf = p;
for (i = index; i < (index + count); i++) {
- if (priv->data->devtype == IMX8QXP) {
- if ((i > 271) && (i < 544)) {
- *buf++ = 0;
- continue;
- }
+ if (in_hole(context, i)) {
+ *buf++ = 0;
+ continue;
}
ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
--
2.16.4
[PATCH 2/2] nvmem: imx: scu: support write
From: Peng Fan
The fuse programming from non-secure world is blocked, so we could
only use Arm Trusted Firmware SIP call to let ATF program fuse.
Because there is ECC region that could only be programmed once,
so add a heler in_ecc to check the ecc region.
Signed-off-by: Peng Fan
---
The ATF patch will soon be posted to ATF community.
drivers/nvmem/imx-ocotp-scu.c | 73 ++-
1 file changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
index 2f339d7432e6..0f064f2e74a8 100644
--- a/drivers/nvmem/imx-ocotp-scu.c
+++ b/drivers/nvmem/imx-ocotp-scu.c
@@ -7,6 +7,7 @@
* Peng Fan
*/
+#include
#include
#include
#include
@@ -14,6 +15,9 @@
#include
#include
+#define IMX_SIP_OTP0xC20A
+#define IMX_SIP_OTP_WRITE 0x2
+
enum ocotp_devtype {
IMX8QXP,
};
@@ -45,6 +49,8 @@ struct imx_sc_msg_misc_fuse_read {
u32 word;
} __packed;
+static DEFINE_MUTEX(scu_ocotp_mutex);
+
static struct ocotp_devtype_data imx8qxp_data = {
.devtype = IMX8QXP,
.nregs = 800,
@@ -73,6 +79,23 @@ static bool in_hole(void *context, u32 index)
return false;
}
+static bool in_ecc(void *context, u32 index)
+{
+ struct ocotp_priv *priv = context;
+ const struct ocotp_devtype_data *data = priv->data;
+ int i;
+
+ for (i = 0; i < data->num_region; i++) {
+ if (data->region[i].flag & ECC_REGION) {
+ if ((index >= data->region[i].start) &&
+ (index <= data->region[i].end))
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
u32 *val)
{
@@ -116,6 +139,8 @@ static int imx_scu_ocotp_read(void *context, unsigned int
offset,
if (!p)
return -ENOMEM;
+ mutex_lock(_ocotp_mutex);
+
buf = p;
for (i = index; i < (index + count); i++) {
@@ -126,6 +151,7 @@ static int imx_scu_ocotp_read(void *context, unsigned int
offset,
ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
if (ret) {
+ mutex_unlock(_ocotp_mutex);
kfree(p);
return ret;
}
@@ -134,18 +160,63 @@ static int imx_scu_ocotp_read(void *context, unsigned int
offset,
memcpy(val, (u8 *)p + offset % 4, bytes);
+ mutex_unlock(_ocotp_mutex);
+
kfree(p);
return 0;
}
+static int imx_scu_ocotp_write(void *context, unsigned int offset,
+ void *val, size_t bytes)
+{
+ struct ocotp_priv *priv = context;
+ struct arm_smccc_res res;
+ u32 *buf = val;
+ u32 tmp;
+ u32 index;
+ int ret;
+
+ /* allow only writing one complete OTP word at a time */
+ if ((bytes != 4) || (offset % 4))
+ return -EINVAL;
+
+ index = offset >> 2;
+
+ if (in_hole(context, index))
+ return -EINVAL;
+
+ if (in_ecc(context, index)) {
+ pr_warn("ECC region, only program once\n");
+ mutex_lock(_ocotp_mutex);
+ ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, index, );
+ mutex_unlock(_ocotp_mutex);
+ if (ret)
+ return ret;
+ if (tmp) {
+ pr_warn("ECC region, already has value: %x\n", tmp);
+ return -EIO;
+ }
+ }
+
+ mutex_lock(_ocotp_mutex);
+
+ arm_smccc_smc(IMX_SIP_OTP, IMX_SIP_OTP_WRITE, index, *buf,
+ 0, 0, 0, 0, );
+
+ mutex_unlock(_ocotp_mutex);
+
+ return res.a0;
+}
+
static struct nvmem_config imx_scu_ocotp_nvmem_config = {
.name = "imx-scu-ocotp",
- .read_only = true,
+ .read_only = false,
.word_size = 4,
.stride = 1,
.owner = THIS_MODULE,
.reg_read = imx_scu_ocotp_read,
+ .reg_write = imx_scu_ocotp_write,
};
static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
--
2.16.4
[PATCH] clk: imx: pll14xx: avoid glitch when set rate
From: Peng Fan
According to PLL1443XA and PLL1416X spec,
"When BYPASS is 0 and RESETB is changed from 0 to 1, FOUT starts to
output unstable clock until lock time passes. PLL1416X/PLL1443XA may
generate a glitch at FOUT."
So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch.
In the end of set rate, BYPASS will be cleared.
Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Signed-off-by: Peng Fan
---
drivers/clk/imx/clk-pll14xx.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index b7213023b238..bd072556bc44 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -191,6 +191,10 @@ static int clk_pll1416x_set_rate(struct clk_hw *hw,
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
+ /* Enable BYPASS */
+ tmp |= BYPASS_MASK;
+ writel(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
@@ -250,6 +254,10 @@ static int clk_pll1443x_set_rate(struct clk_hw *hw,
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
+ /* Enable BYPASS */
+ tmp |= BYPASS_MASK;
+ writel_relaxed(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
--
2.16.4
[PATCH] clk: imx: imx8mn: fix audio pll setting
From: Peng Fan
The AUDIO PLL max support 650M, so the original clk settings violate
spec. This patch makes the output 786432000 -> 393216000,
and 722534400 -> 361267200 to aligned with NXP vendor kernel without any
impact on audio functionality and go within 650MHz PLL limit.
Signed-off-by: Peng Fan
Reviewed-by: Shengjiu Wang
---
drivers/clk/imx/clk-imx8mn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index c5838710e1d8..0e7fb39bcb44 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -51,8 +51,8 @@ static const struct imx_pll14xx_rate_table
imx8mn_pll1416x_tbl[] = {
};
static const struct imx_pll14xx_rate_table imx8mn_audiopll_tbl[] = {
- PLL_1443X_RATE(786432000U, 655, 5, 2, 23593),
- PLL_1443X_RATE(722534400U, 301, 5, 1, 3670),
+ PLL_1443X_RATE(393216000U, 262, 2, 3, 9437),
+ PLL_1443X_RATE(361267200U, 361, 3, 3, 17511),
};
static const struct imx_pll14xx_rate_table imx8mn_videopll_tbl[] = {
--
2.16.4
RE: [PATCH] clk: imx8mn: fix int pll clk gate
Hi Stephen,
> Subject: Re: [PATCH] clk: imx8mn: fix int pll clk gate
>
> Quoting peng@nxp.com (2019-08-13 18:53:12)
> > From: Peng Fan
> >
> > To Frac pll, the gate shift is 13, however to Int PLL the gate shift
> > is 11.
> >
> > Cc:
> > Fixes: 96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver")
> > Signed-off-by: Peng Fan
> > Reviewed-by: Jacky Bai
> > ---
>
> This is a fix for a change in -next. Why is stable Cced?
Sorry, that was added by mistaken. Should I resend v2 to drop it?
Thanks,
Peng.
[PATCH] clk: imx8mn: fix int pll clk gate
From: Peng Fan
To Frac pll, the gate shift is 13, however to Int PLL the gate shift
is 11.
Cc:
Fixes: 96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Peng Fan
Reviewed-by: Jacky Bai
---
drivers/clk/imx/clk-imx8mn.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index ecd1062f6847..c5838710e1d8 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -436,12 +436,12 @@ static int imx8mn_clocks_probe(struct platform_device
*pdev)
clks[IMX8MN_AUDIO_PLL2_OUT] = imx_clk_gate("audio_pll2_out",
"audio_pll2_bypass", base + 0x14, 13);
clks[IMX8MN_VIDEO_PLL1_OUT] = imx_clk_gate("video_pll1_out",
"video_pll1_bypass", base + 0x28, 13);
clks[IMX8MN_DRAM_PLL_OUT] = imx_clk_gate("dram_pll_out",
"dram_pll_bypass", base + 0x50, 13);
- clks[IMX8MN_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out",
"gpu_pll_bypass", base + 0x64, 13);
- clks[IMX8MN_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out",
"vpu_pll_bypass", base + 0x74, 13);
- clks[IMX8MN_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out",
"arm_pll_bypass", base + 0x84, 13);
- clks[IMX8MN_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out",
"sys_pll1_bypass", base + 0x94, 13);
- clks[IMX8MN_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out",
"sys_pll2_bypass", base + 0x104, 13);
- clks[IMX8MN_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out",
"sys_pll3_bypass", base + 0x114, 13);
+ clks[IMX8MN_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out",
"gpu_pll_bypass", base + 0x64, 11);
+ clks[IMX8MN_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out",
"vpu_pll_bypass", base + 0x74, 11);
+ clks[IMX8MN_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out",
"arm_pll_bypass", base + 0x84, 11);
+ clks[IMX8MN_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out",
"sys_pll1_bypass", base + 0x94, 11);
+ clks[IMX8MN_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out",
"sys_pll2_bypass", base + 0x104, 11);
+ clks[IMX8MN_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out",
"sys_pll3_bypass", base + 0x114, 11);
/* SYS PLL fixed output */
clks[IMX8MN_SYS_PLL1_40M] = imx_clk_fixed_factor("sys_pll1_40m",
"sys_pll1_out", 1, 20);
--
2.16.4
RE: [PATCH v2 4/5] firmware: arm_scmi: Add RESET protocol in SCMI v2.0
_reset_protocol_init);
> +}
> +subsys_initcall(scmi_reset_init);
> diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
> index f0f2b53a1dac..881fea47c83d 100644
> --- a/include/linux/scmi_protocol.h
> +++ b/include/linux/scmi_protocol.h
> @@ -187,6 +187,26 @@ struct scmi_sensor_ops {
> u64 *value);
> };
>
> +/**
> + * struct scmi_reset_ops - represents the various operations provided
> + * by SCMI Reset Protocol
> + *
> + * @num_domains_get: get the count of reset domains provided by SCMI
> + * @name_get: gets the name of a reset domain
> + * @latency_get: gets the reset latency for the specified reset domain
> + * @reset: resets the specified reset domain
> + * @assert: explicitly assert reset signal of the specified reset
> +domain
> + * @deassert: explicitly deassert reset signal of the specified reset
> +domain */ struct scmi_reset_ops {
> + int (*num_domains_get)(const struct scmi_handle *handle);
> + char *(*name_get)(const struct scmi_handle *handle, u32 domain);
> + int (*latency_get)(const struct scmi_handle *handle, u32 domain);
> + int (*reset)(const struct scmi_handle *handle, u32 domain);
> + int (*assert)(const struct scmi_handle *handle, u32 domain);
> + int (*deassert)(const struct scmi_handle *handle, u32 domain); };
> +
> /**
> * struct scmi_handle - Handle returned to ARM SCMI clients for usage.
> *
> @@ -196,6 +216,7 @@ struct scmi_sensor_ops {
> * @perf_ops: pointer to set of performance protocol operations
> * @clk_ops: pointer to set of clock protocol operations
> * @sensor_ops: pointer to set of sensor protocol operations
> + * @reset_ops: pointer to set of reset protocol operations
> * @perf_priv: pointer to private data structure specific to performance
> * protocol(for internal use only)
> * @clk_priv: pointer to private data structure specific to clock @@ -204,6
> +225,8 @@ struct scmi_sensor_ops {
> * protocol(for internal use only)
> * @sensor_priv: pointer to private data structure specific to sensors
> * protocol(for internal use only)
> + * @reset_priv: pointer to private data structure specific to reset
> + * protocol(for internal use only)
> */
> struct scmi_handle {
> struct device *dev;
> @@ -212,11 +235,13 @@ struct scmi_handle {
> struct scmi_clk_ops *clk_ops;
> struct scmi_power_ops *power_ops;
> struct scmi_sensor_ops *sensor_ops;
> + struct scmi_reset_ops *reset_ops;
> /* for protocol internal use */
> void *perf_priv;
> void *clk_priv;
> void *power_priv;
> void *sensor_priv;
> + void *reset_priv;
> };
>
> enum scmi_std_protocol {
> @@ -226,6 +251,7 @@ enum scmi_std_protocol {
> SCMI_PROTOCOL_PERF = 0x13,
> SCMI_PROTOCOL_CLOCK = 0x14,
> SCMI_PROTOCOL_SENSOR = 0x15,
> + SCMI_PROTOCOL_RESET = 0x16,
> };
Reviewed-by: Peng Fan
>
> struct scmi_device {
> --
> 2.17.1
RE: [PATCH v2 2/5] firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol
imit_get_addr + 4);
> + return 0;
> + }
> +
> + return scmi_perf_mb_limits_get(handle, domain, max_perf, min_perf); }
> +
> +static int scmi_perf_mb_level_set(const struct scmi_handle *handle, u32
> +domain,
> u32 level, bool poll)
> {
> int ret;
> @@ -365,7 +432,22 @@ static int scmi_perf_level_set(const struct
> scmi_handle *handle, u32 domain,
> return ret;
> }
>
> -static int scmi_perf_level_get(const struct scmi_handle *handle, u32 domain,
> +static int scmi_perf_level_set(const struct scmi_handle *handle, u32
> domain,
> +u32 level, bool poll)
> +{
> + struct scmi_perf_info *pi = handle->perf_priv;
> + struct perf_dom_info *dom = pi->dom_info + domain;
> +
> + if (dom->fc_info && dom->fc_info->level_set_addr) {
> + iowrite32(level, dom->fc_info->level_set_addr);
> + scmi_perf_fc_ring_db(dom->fc_info->level_set_db);
> + return 0;
> + }
> +
> + return scmi_perf_mb_level_set(handle, domain, level, poll); }
> +
> +static int scmi_perf_mb_level_get(const struct scmi_handle *handle, u32
> +domain,
> u32 *level, bool poll)
> {
> int ret;
> @@ -387,6 +469,20 @@ static int scmi_perf_level_get(const struct
> scmi_handle *handle, u32 domain,
> return ret;
> }
>
> +static int scmi_perf_level_get(const struct scmi_handle *handle, u32
> domain,
> +u32 *level, bool poll)
> +{
> + struct scmi_perf_info *pi = handle->perf_priv;
> + struct perf_dom_info *dom = pi->dom_info + domain;
> +
> + if (dom->fc_info && dom->fc_info->level_get_addr) {
> + *level = ioread32(dom->fc_info->level_get_addr);
> + return 0;
> + }
> +
> + return scmi_perf_mb_level_get(handle, domain, level, poll); }
> +
> static bool scmi_perf_fc_size_is_valid(u32 msg, u32 size) {
> if ((msg == PERF_LEVEL_GET || msg == PERF_LEVEL_SET) && size == 4)
Reviewed-by: Peng Fan
> --
> 2.17.1
RE: [PATCH v2 1/5] firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels
omain, }
>
> static int scmi_perf_limits_get(const struct scmi_handle *handle, u32
> domain,
> - u32 *max_perf, u32 *min_perf)
> +u32 *max_perf, u32 *min_perf)
> {
> int ret;
> struct scmi_xfer *t;
> @@ -299,7 +343,7 @@ static int scmi_perf_limits_get(const struct
> scmi_handle *handle, u32 domain, }
>
> static int scmi_perf_level_set(const struct scmi_handle *handle, u32
> domain,
> -u32 level, bool poll)
> + u32 level, bool poll)
> {
> int ret;
> struct scmi_xfer *t;
> @@ -322,7 +366,7 @@ static int scmi_perf_level_set(const struct
> scmi_handle *handle, u32 domain, }
>
> static int scmi_perf_level_get(const struct scmi_handle *handle, u32
> domain,
> -u32 *level, bool poll)
> + u32 *level, bool poll)
> {
> int ret;
> struct scmi_xfer *t;
> @@ -343,6 +387,104 @@ static int scmi_perf_level_get(const struct
> scmi_handle *handle, u32 domain,
> return ret;
> }
>
> +static bool scmi_perf_fc_size_is_valid(u32 msg, u32 size) {
> + if ((msg == PERF_LEVEL_GET || msg == PERF_LEVEL_SET) && size == 4)
> + return true;
> + if ((msg == PERF_LIMITS_GET || msg == PERF_LIMITS_SET) && size == 8)
> + return true;
> + return false;
> +}
> +
> +static void
> +scmi_perf_domain_desc_fc(const struct scmi_handle *handle, u32 domain,
> + u32 message_id, void __iomem **p_addr,
> + struct scmi_fc_db_info **p_db)
> +{
> + int ret;
> + u32 flags;
> + u64 phys_addr;
> + u8 size;
> + void __iomem *addr;
> + struct scmi_xfer *t;
> + struct scmi_fc_db_info *db;
> + struct scmi_perf_get_fc_info *info;
> + struct scmi_msg_resp_perf_desc_fc *resp;
> +
> + if (!p_addr)
> + return;
> +
> + ret = scmi_xfer_get_init(handle, PERF_DESCRIBE_FASTCHANNEL,
> + SCMI_PROTOCOL_PERF,
> + sizeof(*info), sizeof(*resp), );
> + if (ret)
> + return;
> +
> + info = t->tx.buf;
> + info->domain = cpu_to_le32(domain);
> + info->message_id = cpu_to_le32(message_id);
> +
> + ret = scmi_do_xfer(handle, t);
> + if (ret)
> + goto err_xfer;
> +
> + resp = t->rx.buf;
> + flags = le32_to_cpu(resp->attr);
> + size = le32_to_cpu(resp->chan_size);
> + if (!scmi_perf_fc_size_is_valid(message_id, size))
> + goto err_xfer;
> +
> + phys_addr = le32_to_cpu(resp->chan_addr_low);
> + phys_addr |= (u64)le32_to_cpu(resp->chan_addr_high) << 32;
> + addr = devm_ioremap(handle->dev, phys_addr, size);
> + if (!addr)
> + goto err_xfer;
> + *p_addr = addr;
> +
> + if (p_db && SUPPORTS_DOORBELL(flags)) {
> + db = devm_kzalloc(handle->dev, sizeof(*db), GFP_KERNEL);
> + if (!db)
> + goto err_xfer;
> +
> + size = 1 << DOORBELL_REG_WIDTH(flags);
> + phys_addr = le32_to_cpu(resp->db_addr_low);
> + phys_addr |= (u64)le32_to_cpu(resp->db_addr_high) << 32;
> + addr = devm_ioremap(handle->dev, phys_addr, size);
> + if (!addr)
> + goto err_xfer;
> +
> + db->addr = addr;
> + db->width = size;
> + db->set = le32_to_cpu(resp->db_set_lmask);
> + db->set |= (u64)le32_to_cpu(resp->db_set_hmask) << 32;
> + db->mask = le32_to_cpu(resp->db_preserve_lmask);
> + db->mask |= (u64)le32_to_cpu(resp->db_preserve_hmask) << 32;
> + *p_db = db;
> + }
> +err_xfer:
> + scmi_xfer_put(handle, t);
> +}
> +
> +static void scmi_perf_domain_init_fc(const struct scmi_handle *handle,
> + u32 domain, struct scmi_fc_info **p_fc) {
> + struct scmi_fc_info *fc;
> +
> + fc = devm_kzalloc(handle->dev, sizeof(*fc), GFP_KERNEL);
> + if (!fc)
> + return;
> +
> + scmi_perf_domain_desc_fc(handle, domain, PERF_LEVEL_SET,
> + >level_set_addr, >level_set_db);
> + scmi_perf_domain_desc_fc(handle, domain, PERF_LEVEL_GET,
> + >level_get_addr, NULL);
> + scmi_perf_domain_desc_fc(handle, domain, PERF_LIMITS_SET,
> + >limit_set_addr, >limit_set_db);
> + scmi_perf_domain_desc_fc(handle, domain, PERF_LIMITS_GET,
> + >limit_get_addr, NULL);
> + *p_fc = fc;
> +}
> +
> /* Device specific ops */
> static int scmi_dev_domain_id(struct device *dev) { @@ -494,6 +636,9
> @@ static int scmi_perf_protocol_init(struct scmi_handle *handle)
>
> scmi_perf_domain_attributes_get(handle, domain, dom);
> scmi_perf_describe_levels_get(handle, domain, dom);
> +
> + if (dom->perf_fastchannels)
> + scmi_perf_domain_init_fc(handle, domain, >fc_info);
> }
>
> handle->perf_ops = _ops;
Reviewed-by: Peng Fan
> --
> 2.17.1
RE: [PATCH v3 2/2] mailbox: introduce ARM SMC based mailbox
Hi All,
> Subject: [PATCH v3 2/2] mailbox: introduce ARM SMC based mailbox
Any comments with this patch?
>
> From: Peng Fan
>
> This mailbox driver implements a mailbox which signals transmitted data via
> an ARM smc (secure monitor call) instruction. The mailbox receiver is
> implemented in firmware and can synchronously return data when it returns
> execution to the non-secure world again.
> An asynchronous receive path is not implemented.
> This allows the usage of a mailbox to trigger firmware actions on SoCs which
> either don't have a separate management processor or on which such a core
> is not available. A user of this mailbox could be the SCP interface.
>
> Modified from Andre Przywara's v2 patch
> https://lore.kernel.org/patchwork/patch/812999/
>
> Cc: Andre Przywara
> Signed-off-by: Peng Fan
> ---
>
> V3:
> Drop interrupt.
> Introduce transports for mem/reg usage.
> Add chan-id for mem usage.
>
> V2:
> Add interrupts notification support.
>
> drivers/mailbox/Kconfig | 7 ++
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/arm-smc-mailbox.c | 215
> ++
> 3 files changed, 224 insertions(+)
> create mode 100644 drivers/mailbox/arm-smc-mailbox.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> 595542bfae85..c3bd0f1ddcd8 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -15,6 +15,13 @@ config ARM_MHU
> The controller has 3 mailbox channels, the last of which can be
> used in Secure mode only.
>
> +config ARM_SMC_MBOX
> + tristate "Generic ARM smc mailbox"
> + depends on OF && HAVE_ARM_SMCCC
> + help
> + Generic mailbox driver which uses ARM smc calls to call into
> + firmware for triggering mailboxes.
> +
> config IMX_MBOX
> tristate "i.MX Mailbox"
> depends on ARCH_MXC || COMPILE_TEST
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> c22fad6f696b..93918a84c91b 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)+= mailbox-test.o
>
> obj-$(CONFIG_ARM_MHU)+= arm_mhu.o
>
> +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> +
> obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
>
> obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) +=
> armada-37xx-rwtm-mailbox.o
> diff --git a/drivers/mailbox/arm-smc-mailbox.c
> b/drivers/mailbox/arm-smc-mailbox.c
> new file mode 100644
> index ..76a2ae11ee4d
> --- /dev/null
> +++ b/drivers/mailbox/arm-smc-mailbox.c
> @@ -0,0 +1,215 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2016,2017 ARM Ltd.
> + * Copyright 2019 NXP
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
> +
> +struct arm_smc_chan_data {
> + u32 function_id;
> + u32 chan_id;
> + u32 flags;
> +};
> +
> +struct arm_smccc_mbox_cmd {
> + unsigned long a0, a1, a2, a3, a4, a5, a6, a7; };
> +
> +typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
> + unsigned long, unsigned long,
> + unsigned long, unsigned long,
> + unsigned long, unsigned long);
> +static smc_mbox_fn *invoke_smc_mbox_fn;
> +
> +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> + struct arm_smc_chan_data *chan_data = link->con_priv;
> + struct arm_smccc_mbox_cmd *cmd = data;
> + unsigned long ret;
> + u32 function_id;
> + u32 chan_id;
> +
> + if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
> + if (chan_data->function_id != UINT_MAX)
> + function_id = chan_data->function_id;
> + else
> + function_id = cmd->a0;
> + chan_id = chan_data->chan_id;
> + ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
> + 0, 0);
> + } else {
> + ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
> + cmd->a4, cmd->a5, cmd->a6, cmd->a7);
> + }
> +
> + mbox_chan_received_data(link, (void *)ret);
> +
> + return 0;
> +}
> +
> +static unsigned long __invoke_fn_hvc(unsigned long function_id,
> + unsigned long arg0, unsigned long arg1,
> + unsigned long arg2,
RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
Hi Russell, Stefano
> Subject: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
Any comments?
>
> arm64 shares some code under arch/arm/xen, including mm.c.
> However ZONE_DMA is removed by commit
> ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> So to ARM64, need use __GFP_DMA32.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/xen/mm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> e1d44b903dfc..a95e76d18bf9 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int
> order)
>
> for_each_memblock(memory, reg) {
> if (reg->base < (phys_addr_t)0x) {
> - flags |= __GFP_DMA;
> + flags |= __GFP_DMA | __GFP_DMA32;
> break;
> }
> }
Thanks,
Peng.
> --
> 2.16.4
RE: [PATCH] clk: imx: imx8mm: fix audio pll setting
Hi Stephen,
> Subject: Re: [PATCH] clk: imx: imx8mm: fix audio pll setting
>
> Quoting Peng Fan (2019-07-14 19:55:43)
> > From: Peng Fan
> >
> > The AUDIO PLL max support 650M, so the original clk settings violate
> > spec. This patch makes the output 786432000 -> 393216000, and
> > 722534400 -> 361267200 to aligned with NXP vendor kernel without any
> > impact on audio functionality and go within 650MHz PLL limit.
> >
> > Cc:
> > Fixes: ba5625c3e272 ("clk: imx: Add clock driver support for imx8mm")
> > Signed-off-by: Peng Fan
> > ---
>
> Is this a problem right now, i.e. should I apply this to clk-fixes? Or can
> this wait
> until next merge window?
Could wait until next merge window.
Thanks,
Peng.
RE: [PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
Hi Sudeep, > Subject: Re: [PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > This looks much better now. > > On Mon, Jul 15, 2019 at 10:10:10AM +, Peng Fan wrote: > > From: Peng Fan > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to > > trigger actions in software layers running in the EL2 or EL3 exception > > levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan > > --- > > > > V3: > > Convert to yaml > > Drop interrupt > > Introudce transports to indicate mem/reg The func id is still kept > > as optional, because like SCMI it only cares about message. > > > > V2: > > Introduce interrupts as a property. > > > > .../devicetree/bindings/mailbox/arm-smc.yaml | 124 > + > > 1 file changed, 124 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index ..da9b1a03bc4e > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,124 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23data=02%7 > C01%7Cp > > > +eng.fan%40nxp.com%7Cb5039d50ce8c40928edb08d70adc20f9%7C686ea1 > d3bc2b4c > > > +6fa92cd99c5c301635%7C0%7C1%7C636989812923178414sdata=UT > 7r2vOLX4a > > +tv7Yfh750wdSXSh2ZPxeJOXLWl5yACK0%3Dreserved=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23data=02%7C01%7Cpe > ng.fan% > > > +40nxp.com%7Cb5039d50ce8c40928edb08d70adc20f9%7C686ea1d3bc2b4c > 6fa92cd9 > > > +9c5c301635%7C0%7C1%7C636989812923178414sdata=3Gjn1NQtO > PbvfTvyN3X > > +b89%2BvvGO2ff6DpGQUQejGAzU%3Dreserved=0 > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc > > +(hypervisor > > + call) instruction to trigger a mailbox-connected activity in > > +firmware, > > + executing on the very same core as the caller. By nature this > > +operation > > + is synchronous and this mailbox provides no way for asynchronous > > +messages > > + to be delivered the other way round, from firmware to the OS, but > > + asynchronous notification could also be supported. However the > > +value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a > > +received > > + message to the mailbox framework, so a synchronous communication > > +can be > > + established, for a asynchronous notification, no value will be returned. > > + The exact meaning of both the action the mailbox triggers as well > > +as the > > + return value is defined by their users and is not subject to this > > binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses > > + shared memory to transfer commands and parameters, and a mailbox > to > > + trigger a function call. This allows SoCs without a separate > > + management processor (or when such a processor is not available or > > + used) to use this standardized interface anyway. > > + > > + This binding describes no hardware, but establishes a firmware > interface. > > + Upon receiving an SMC using one of the described SMC function > > + identifiers, the firmware is expected to trigger some mailbox connected > functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The > > + supported identifiers are passed from consumers, or listed in the > > + the arm,func-ids properties as described below. The firmware can > > + return one value in the first SMC result register, it is expected > > + to be an error value, which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as > > + long as a firmware component running in EL3 or EL2 is handling these > calls. > &g
RE: [PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
Hi Rob, > Subject: Re: [PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Mon, Jul 15, 2019 at 4:10 AM Peng Fan wrote: > > > > From: Peng Fan > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to > > trigger actions in software layers running in the EL2 or EL3 exception > > levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan > > --- > > > > V3: > > Convert to yaml > > Drop interrupt > > Introudce transports to indicate mem/reg The func id is still kept > > as optional, because like SCMI it only cares about message. > > > > V2: > > Introduce interrupts as a property. > > > > .../devicetree/bindings/mailbox/arm-smc.yaml | 124 > + > > 1 file changed, 124 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index ..da9b1a03bc4e > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,124 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23data=02%7 > C01%7Cp > > > +eng.fan%40nxp.com%7C424e0d1c19c344406b6008d709465591%7C686ea1 > d3bc2b4c > > > +6fa92cd99c5c301635%7C0%7C0%7C636988070002772705sdata=DV > stQ%2FhuN > > +c67%2Bt08yXibQrX7sIeocHziYp3dkkeRoJ4%3Dreserved=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23data=02%7C01%7Cpe > ng.fan% > > > +40nxp.com%7C424e0d1c19c344406b6008d709465591%7C686ea1d3bc2b4 > c6fa92cd9 > > > +9c5c301635%7C0%7C0%7C636988070002782698sdata=D%2Fa2SU > W%2FCqclJdy > > +RbFggqqL%2BAEumER0K3rAaisY2bMc%3Dreserved=0 > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc > > +(hypervisor > > + call) instruction to trigger a mailbox-connected activity in > > +firmware, > > + executing on the very same core as the caller. By nature this > > +operation > > + is synchronous and this mailbox provides no way for asynchronous > > +messages > > + to be delivered the other way round, from firmware to the OS, but > > + asynchronous notification could also be supported. However the > > +value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a > > +received > > + message to the mailbox framework, so a synchronous communication > > +can be > > + established, for a asynchronous notification, no value will be returned. > > + The exact meaning of both the action the mailbox triggers as well > > +as the > > + return value is defined by their users and is not subject to this > > binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses > > + shared memory to transfer commands and parameters, and a mailbox > to > > + trigger a function call. This allows SoCs without a separate > > + management processor (or when such a processor is not available or > > + used) to use this standardized interface anyway. > > + > > + This binding describes no hardware, but establishes a firmware > interface. > > + Upon receiving an SMC using one of the described SMC function > > + identifiers, the firmware is expected to trigger some mailbox connected > functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The > > + supported identifiers are passed from consumers, or listed in the > > + the arm,func-ids properties as described below. The firmware can > > + return one value in the first SMC result register, it is expected > > + to be an error value, which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as > > + long as a firmware component running in EL3 or EL2 is handling these > calls. > > + > > +properties: >
[PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan
The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Signed-off-by: Peng Fan
---
V3:
Convert to yaml
Drop interrupt
Introudce transports to indicate mem/reg
The func id is still kept as optional, because like SCMI it only
cares about message.
V2:
Introduce interrupts as a property.
.../devicetree/bindings/mailbox/arm-smc.yaml | 124 +
1 file changed, 124 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index ..da9b1a03bc4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+ - Peng Fan
+
+description: |
+ This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
+ call) instruction to trigger a mailbox-connected activity in firmware,
+ executing on the very same core as the caller. By nature this operation
+ is synchronous and this mailbox provides no way for asynchronous messages
+ to be delivered the other way round, from firmware to the OS, but
+ asynchronous notification could also be supported. However the value of
+ r0/w0/x0 the firmware returns after the smc call is delivered as a received
+ message to the mailbox framework, so a synchronous communication can be
+ established, for a asynchronous notification, no value will be returned.
+ The exact meaning of both the action the mailbox triggers as well as the
+ return value is defined by their users and is not subject to this binding.
+
+ One use case of this mailbox is the SCMI interface, which uses shared memory
+ to transfer commands and parameters, and a mailbox to trigger a function
+ call. This allows SoCs without a separate management processor (or when
+ such a processor is not available or used) to use this standardized
+ interface anyway.
+
+ This binding describes no hardware, but establishes a firmware interface.
+ Upon receiving an SMC using one of the described SMC function identifiers,
+ the firmware is expected to trigger some mailbox connected functionality.
+ The communication follows the ARM SMC calling convention.
+ Firmware expects an SMC function identifier in r0 or w0. The supported
+ identifiers are passed from consumers, or listed in the the arm,func-ids
+ properties as described below. The firmware can return one value in
+ the first SMC result register, it is expected to be an error value,
+ which shall be propagated to the mailbox client.
+
+ Any core which supports the SMC or HVC instruction can be used, as long as
+ a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+ compatible:
+const: arm,smc-mbox
+
+ "#mbox-cells":
+const: 1
+
+ arm,num-chans:
+description: The number of channels supported.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+ method:
+items:
+ - enum:
+ - smc
+ - hvc
+
+ transports:
+items:
+ - enum:
+ - mem
+ - reg
+
+ arm,func-ids:
+description: |
+ An array of 32-bit values specifying the function IDs used by each
+ mailbox channel. Those function IDs follow the ARM SMC calling
+ convention standard [1].
+
+ There is one identifier per channel and the number of supported
+ channels is determined by the length of this array.
+minItems: 0
+maxItems: 4096 # Should be enough?
+
+required:
+ - compatible
+ - "#mbox-cells"
+ - arm,num-chans
+ - transports
+ - method
+
+examples:
+ - |
+sram@91 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x93f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x93f000 0x1000>;
+
+cpu_scp_lpri: scp-shmem@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x200>;
+};
+
+cpu_scp_hpri: scp-shmem@200 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x200 0x200>;
+};
+};
+
+firmware {
+ smc_mbox: mailbox {
+#mbox-cells = <1>;
+compatible = "arm,smc-mbox";
+method = "smc";
+arm,num-chans = <0x2>;
+transports = "mem";
+/* Optional */
+arm,func-ids = <0xc2fe>, <0xc2ff>;
+ }
[PATCH v3 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.
Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/
Cc: Andre Przywara
Signed-off-by: Peng Fan
---
V3:
Drop interrupt.
Introduce transports for mem/reg usage.
Add chan-id for mem usage.
V2:
Add interrupts notification support.
drivers/mailbox/Kconfig | 7 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 215 ++
3 files changed, 224 insertions(+)
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 595542bfae85..c3bd0f1ddcd8 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -15,6 +15,13 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config ARM_SMC_MBOX
+ tristate "Generic ARM smc mailbox"
+ depends on OF && HAVE_ARM_SMCCC
+ help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..76a2ae11ee4d
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
+
+struct arm_smc_chan_data {
+ u32 function_id;
+ u32 chan_id;
+ u32 flags;
+};
+
+struct arm_smccc_mbox_cmd {
+ unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+ struct arm_smc_chan_data *chan_data = link->con_priv;
+ struct arm_smccc_mbox_cmd *cmd = data;
+ unsigned long ret;
+ u32 function_id;
+ u32 chan_id;
+
+ if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
+ if (chan_data->function_id != UINT_MAX)
+ function_id = chan_data->function_id;
+ else
+ function_id = cmd->a0;
+ chan_id = chan_data->chan_id;
+ ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
+0, 0);
+ } else {
+ ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
+cmd->a4, cmd->a5, cmd->a6, cmd->a7);
+ }
+
+ mbox_chan_received_data(link, (void *)ret);
+
+ return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, );
+ return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+ struct arm_smccc_
[PATCH v3 0/2] mailbox: arm: introduce smc triggered mailbox
From: Peng Fan V3: Drop interrupt Introduce transports for mem/reg usage Add chan-id for mem usage Convert to yaml format V2: This is a modified version from Andre Przywara's patch series https://lore.kernel.org/patchwork/cover/812997/. The modification are mostly: Introduce arm,num-chans Introduce arm_smccc_mbox_cmd txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as an optional property. Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. Introduce interrupts notification. [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use smc as mailbox, power/clk is included, but only part of clk has been implemented to work with hardware, power domain only supports get name for now. The traditional Linux mailbox mechanism uses some kind of dedicated hardware IP to signal a condition to some other processing unit, typically a dedicated management processor. This mailbox feature is used for instance by the SCMI protocol to signal a request for some action to be taken by the management processor. However some SoCs does not have a dedicated management core to provide those services. In order to service TEE and to avoid linux shutdown power and clock that used by TEE, need let firmware to handle power and clock, the firmware here is ARM Trusted Firmware that could also run SCMI service. The existing SCMI implementation uses a rather flexible shared memory region to communicate commands and their parameters, it still requires a mailbox to actually trigger the action. This patch series provides a Linux mailbox compatible service which uses smc calls to invoke firmware code, for instance taking care of SCMI requests. The actual requests are still communicated using the standard SCMI way of shared memory regions, but a dedicated mailbox hardware IP can be replaced via this new driver. This simple driver uses the architected SMC calling convention to trigger firmware services, also allows for using "HVC" calls to call into hypervisors or firmware layers running in the EL2 exception level. Patch 1 contains the device tree binding documentation, patch 2 introduces the actual mailbox driver. Please note that this driver just provides a generic mailbox mechanism, It could support synchronous TX/RX, or synchronous TX with asynchronous RX. And while providing SCMI services was the reason for this exercise, this driver is in no way bound to this use case, but can be used generically where the OS wants to signal a mailbox condition to firmware or a hypervisor. Also the driver is in no way meant to replace any existing firmware interface, but actually to complement existing interfaces. [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi Peng Fan (2): dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox mailbox: introduce ARM SMC based mailbox .../devicetree/bindings/mailbox/arm-smc.yaml | 124 drivers/mailbox/Kconfig| 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 215 + 4 files changed, 348 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml create mode 100644 drivers/mailbox/arm-smc-mailbox.c -- 2.16.4
[PATCH] clk: imx: imx8mm: fix audio pll setting
From: Peng Fan
The AUDIO PLL max support 650M, so the original clk settings violate
spec. This patch makes the output 786432000 -> 393216000,
and 722534400 -> 361267200 to aligned with NXP vendor kernel without any
impact on audio functionality and go within 650MHz PLL limit.
Cc:
Fixes: ba5625c3e272 ("clk: imx: Add clock driver support for imx8mm")
Signed-off-by: Peng Fan
---
drivers/clk/imx/clk-imx8mm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 3a873e0e278f..b72bad064d8d 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -55,8 +55,8 @@ static const struct imx_pll14xx_rate_table
imx8mm_pll1416x_tbl[] = {
};
static const struct imx_pll14xx_rate_table imx8mm_audiopll_tbl[] = {
- PLL_1443X_RATE(786432000U, 655, 5, 2, 23593),
- PLL_1443X_RATE(722534400U, 301, 5, 1, 3670),
+ PLL_1443X_RATE(393216000U, 262, 2, 3, 9437),
+ PLL_1443X_RATE(361267200U, 361, 3, 3, 17511),
};
static const struct imx_pll14xx_rate_table imx8mm_videopll_tbl[] = {
--
2.16.4
[PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
arm64 shares some code under arch/arm/xen, including mm.c.
However ZONE_DMA is removed by commit
ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
So to ARM64, need use __GFP_DMA32.
Signed-off-by: Peng Fan
---
arch/arm/xen/mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index e1d44b903dfc..a95e76d18bf9 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
for_each_memblock(memory, reg) {
if (reg->base < (phys_addr_t)0x) {
- flags |= __GFP_DMA;
+ flags |= __GFP_DMA | __GFP_DMA32;
break;
}
}
--
2.16.4
RE: [PATCH V2 1/2] DT: mailbox: add binding doc for the ARM SMC mailbox
Hi Rob, > Subject: Re: [PATCH V2 1/2] DT: mailbox: add binding doc for the ARM SMC > mailbox > > On Mon, Jun 03, 2019 at 04:30:04PM +0800, peng@nxp.com wrote: > > From: Peng Fan > > > > The ARM SMC mailbox binding describes a firmware interface to trigger > > actions in software layers running in the EL2 or EL3 exception levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan > > --- > > > > V2: > > Introduce interrupts as a property. > > > > V1: > > arm,func-ids is still kept as an optional property, because there is > > no defined SMC funciton id passed from SCMI. So in my test, I still > > use arm,func-ids for ARM SIP service. > > > > .../devicetree/bindings/mailbox/arm-smc.txt| 101 > + > > 1 file changed, 101 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/arm-smc.txt > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt > > b/Documentation/devicetree/bindings/mailbox/arm-smc.txt > > new file mode 100644 > > index ..401887118c09 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt > > @@ -0,0 +1,101 @@ > > +ARM SMC Mailbox Interface > > += > > + > > +This mailbox uses the ARM smc (secure monitor call) instruction to > > +trigger a mailbox-connected activity in firmware, executing on the > > +very same core as the caller. By nature this operation is synchronous > > +and this mailbox provides no way for asynchronous messages to be > > +delivered the other way round, from firmware to the OS, but > > +asynchronous notification could also be supported. However the value > > +of r0/w0/x0 the firmware returns after the smc call is delivered as a > > +received message to the mailbox framework, so a synchronous > > +communication can be established, for a asynchronous notification, no > > +value will be returned. The exact meaning of both the action the > > +mailbox triggers as well as the return value is defined by their users and > > is > not subject to this binding. > > + > > +One use case of this mailbox is the SCMI interface, which uses shared > > +memory to transfer commands and parameters, and a mailbox to trigger > > +a function call. This allows SoCs without a separate management > > +processor (or when such a processor is not available or used) to use > > +this standardized interface anyway. > > + > > +This binding describes no hardware, but establishes a firmware interface. > > +Upon receiving an SMC using one of the described SMC function > > +identifiers, the firmware is expected to trigger some mailbox connected > functionality. > > +The communication follows the ARM SMC calling convention[1]. > > +Firmware expects an SMC function identifier in r0 or w0. The > > +supported identifiers are passed from consumers, or listed in the the > > +arm,func-ids properties as described below. The firmware can return > > +one value in the first SMC result register, it is expected to be an > > +error value, which shall be propagated to the mailbox client. > > + > > +Any core which supports the SMC or HVC instruction can be used, as > > +long as a firmware component running in EL3 or EL2 is handling these calls. > > + > > +Mailbox Device Node: > > + > > + > > +This node is expected to be a child of the /firmware node. > > + > > +Required properties: > > + > > +- compatible: Shall be "arm,smc-mbox" > > +- #mbox-cells Shall be 1 - the index of the channel needed. > > +- arm,num-chansThe number of channels supported. > > +- method: A string, either: > > + "hvc": if the driver shall use an HVC call, or > > + "smc": if the driver shall use an SMC call. > > + > > +Optional properties: > > +- arm,func-ids An array of 32-bit values specifying the > > function > > + IDs used by each mailbox channel. Those function IDs > > + follow the ARM SMC calling convention standard [1]. > > + There is one identifier per channel and the number > > + of supported channels is determined by the length > > + of this array. > > +- inte
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Hi All, > Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox > > On Tue, Jun 25, 2019 at 2:30 AM Peng Fan wrote: > > > > Hi Jassi > > > > > Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox > > > > > > On Mon, Jun 3, 2019 at 3:28 AM wrote: > > > > > > > > From: Peng Fan > > > > > > > > This mailbox driver implements a mailbox which signals transmitted > > > > data via an ARM smc (secure monitor call) instruction. The mailbox > > > > receiver is implemented in firmware and can synchronously return > > > > data when it returns execution to the non-secure world again. > > > > An asynchronous receive path is not implemented. > > > > This allows the usage of a mailbox to trigger firmware actions on > > > > SoCs which either don't have a separate management processor or on > > > > which such a core is not available. A user of this mailbox could > > > > be the SCP interface. > > > > > > > > Modified from Andre Przywara's v2 patch https://lore > > > > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C0 > 1%7 > > > Cpeng.fa > > > > > > > > n%40nxp.com%7C1237677cb01044ad714508d6f59f648f%7C686ea1d3bc2b4 > > > c6fa92cd > > > > > > > > 99c5c301635%7C0%7C0%7C636966462272457978sdata=Hzgeu43m5 > > > ZkeRMtL8Bx > > > > gUm3%2B6FBObib1OPHPlSccE%2B0%3Dreserved=0 > > > > > > > > Cc: Andre Przywara > > > > Signed-off-by: Peng Fan > > > > --- > > > > > > > > V2: > > > > Add interrupts notification support. > > > > > > > > drivers/mailbox/Kconfig | 7 ++ > > > > drivers/mailbox/Makefile| 2 + > > > > drivers/mailbox/arm-smc-mailbox.c | 190 > > > > > > > include/linux/mailbox/arm-smc-mailbox.h | 10 ++ > > > > 4 files changed, 209 insertions(+) > > > > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create > mode > > > > 100644 include/linux/mailbox/arm-smc-mailbox.h > > > > > > > > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index > > > > 595542bfae85..c3bd0f1ddcd8 100644 > > > > --- a/drivers/mailbox/Kconfig > > > > +++ b/drivers/mailbox/Kconfig > > > > @@ -15,6 +15,13 @@ config ARM_MHU > > > > The controller has 3 mailbox channels, the last of which can > be > > > > used in Secure mode only. > > > > > > > > +config ARM_SMC_MBOX > > > > + tristate "Generic ARM smc mailbox" > > > > + depends on OF && HAVE_ARM_SMCCC > > > > + help > > > > + Generic mailbox driver which uses ARM smc calls to call into > > > > + firmware for triggering mailboxes. > > > > + > > > > config IMX_MBOX > > > > tristate "i.MX Mailbox" > > > > depends on ARCH_MXC || COMPILE_TEST diff --git > > > > a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index > > > > c22fad6f696b..93918a84c91b 100644 > > > > --- a/drivers/mailbox/Makefile > > > > +++ b/drivers/mailbox/Makefile > > > > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += > mailbox-test.o > > > > > > > > obj-$(CONFIG_ARM_MHU) += arm_mhu.o > > > > > > > > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o > > > > + > > > > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o > > > > > > > > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= > > > armada-37xx-rwtm-mailbox.o > > > > diff --git a/drivers/mailbox/arm-smc-mailbox.c > > > > b/drivers/mailbox/arm-smc-mailbox.c > > > > new file mode 100644 > > > > index ..fef6e38d8b98 > > > > --- /dev/null > > > > +++ b/drivers/mailbox/arm-smc-mailbox.c > > > > @@ -0,0 +1,190 @@ > > > > +// SPDX-License-Identifier: GPL-2.0 > > > > +/* > > > > + * Copyright (C) 2016,2017 ARM Ltd. > > > > + * Copyright 2019 NXP > > > > + */ > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include #include > > > > + > > > > +#include > > >
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Hi Jassi
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Mon, Jun 3, 2019 at 3:28 AM wrote:
> >
> > From: Peng Fan
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C1237677cb01044ad714508d6f59f648f%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636966462272457978sdata=Hzgeu43m5
> ZkeRMtL8Bx
> > gUm3%2B6FBObib1OPHPlSccE%2B0%3Dreserved=0
> >
> > Cc: Andre Przywara
> > Signed-off-by: Peng Fan
> > ---
> >
> > V2:
> > Add interrupts notification support.
> >
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile| 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 190
>
> > include/linux/mailbox/arm-smc-mailbox.h | 10 ++
> > 4 files changed, 209 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode
> > 100644 include/linux/mailbox/arm-smc-mailbox.h
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > 595542bfae85..c3bd0f1ddcd8 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,13 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > + tristate "Generic ARM smc mailbox"
> > + depends on OF && HAVE_ARM_SMCCC
> > + help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> > config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST diff --git
> > a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..fef6e38d8b98
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include #include
> > +
> > +#include
> > +#include
> > +
> > +#define ARM_SMC_MBOX_USE_HVC BIT(0)
> > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> > +
> IRQ bit is unused (and unnecessary IMO)
>
> > +struct arm_smc_chan_data {
> > + u32 function_id;
> > + u32 flags;
> > + int irq;
> > +};
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > + struct arm_smccc_mbox_cmd *cmd = data;
> > + struct arm_smccc_res res;
> > + u32 function_id;
> > +
> > + if (chan_data->function_id != UINT_MAX)
> > + function_id = chan_data->function_id;
> > + else
> > + function_id = cmd->a0;
> > +
> Not sure about chan_data->function_id. Why restrict from DT?
> 'a0' is the function_id register, let the user pass func-id via the 'a0' like
> other
> values via 'a[1-7]'
Missed to reply this comment.
The firmware
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Hi Sudeep, > Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox > > On Thu, Jun 20, 2019 at 10:21:09AM +0000, Peng Fan wrote: > > Hi Sudeep, > > > > > Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox > > > > > > On Mon, Jun 03, 2019 at 04:30:05PM +0800, peng@nxp.com wrote: > > > > From: Peng Fan > > > > > > > > This mailbox driver implements a mailbox which signals transmitted > > > > data via an ARM smc (secure monitor call) instruction. The mailbox > > > > receiver is implemented in firmware and can synchronously return > > > > data when it returns execution to the non-secure world again. > > > > An asynchronous receive path is not implemented. > > > > This allows the usage of a mailbox to trigger firmware actions on > > > > SoCs which either don't have a separate management processor or on > > > > which such a core is not available. A user of this mailbox could > > > > be the SCP interface. > > > > > > > > Modified from Andre Przywara's v2 patch https://lore > > > > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C0 > 1%7 > > > Cpeng.fa > > > > > > > > n%40nxp.com%7C6b37f78032e446be750e08d6f560e707%7C686ea1d3bc2b4 > > > c6fa92cd > > > > > > > > 99c5c301635%7C0%7C0%7C636966193913988679sdata=UNM4MTPs > > > brqoMqWStEy > > > > YzzwMEWTmX7hHO3TeNEz%2BOAw%3Dreserved=0 > > > > > > > > Cc: Andre Przywara > > > > Signed-off-by: Peng Fan > > > > --- > > > > > > > > V2: > > > > Add interrupts notification support. > > > > > > > > drivers/mailbox/Kconfig | 7 ++ > > > > drivers/mailbox/Makefile| 2 + > > > > drivers/mailbox/arm-smc-mailbox.c | 190 > > > > > > > include/linux/mailbox/arm-smc-mailbox.h | 10 ++ > > > > 4 files changed, 209 insertions(+) > > > > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create > mode > > > > 100644 include/linux/mailbox/arm-smc-mailbox.h > > > > > > > > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index > > > > 595542bfae85..c3bd0f1ddcd8 100644 > > > > --- a/drivers/mailbox/Kconfig > > > > +++ b/drivers/mailbox/Kconfig > > > > @@ -15,6 +15,13 @@ config ARM_MHU > > > > The controller has 3 mailbox channels, the last of which can > > > > be > > > > used in Secure mode only. > > > > > > > > +config ARM_SMC_MBOX > > > > + tristate "Generic ARM smc mailbox" > > > > + depends on OF && HAVE_ARM_SMCCC > > > > + help > > > > + Generic mailbox driver which uses ARM smc calls to call into > > > > + firmware for triggering mailboxes. > > > > + > > > > config IMX_MBOX > > > > tristate "i.MX Mailbox" > > > > depends on ARCH_MXC || COMPILE_TEST > > > > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index > > > > c22fad6f696b..93918a84c91b 100644 > > > > --- a/drivers/mailbox/Makefile > > > > +++ b/drivers/mailbox/Makefile > > > > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o > > > > > > > > obj-$(CONFIG_ARM_MHU) += arm_mhu.o > > > > > > > > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o > > > > + > > > > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o > > > > > > > > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= > > > armada-37xx-rwtm-mailbox.o > > > > diff --git a/drivers/mailbox/arm-smc-mailbox.c > > > > b/drivers/mailbox/arm-smc-mailbox.c > > > > new file mode 100644 > > > > index ..fef6e38d8b98 > > > > --- /dev/null > > > > +++ b/drivers/mailbox/arm-smc-mailbox.c > > > > @@ -0,0 +1,190 @@ > > > > +// SPDX-License-Identifier: GPL-2.0 > > > > +/* > > > > + * Copyright (C) 2016,2017 ARM Ltd. > > > > + * Copyright 2019 NXP > > > > + */ > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include #include > > > > + > > > &g
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Hi Jassi,
> -Original Message-
> From: Jassi Brar [mailto:jassisinghb...@gmail.com]
> Sent: 2019年6月21日 0:50
> To: Peng Fan
> Cc: Rob Herring ; Mark Rutland
> ; Sudeep Holla ; Florian
> Fainelli ; , Sascha Hauer ;
> dl-linux-imx ; Shawn Guo ;
> feste...@gmail.com; Devicetree List ; Linux
> Kernel Mailing List ;
> linux-arm-ker...@lists.infradead.org; Andre Przywara
> ; van.free...@gmail.com
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Mon, Jun 3, 2019 at 3:28 AM wrote:
> >
> > From: Peng Fan
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C1237677cb01044ad714508d6f59f648f%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636966462272457978sdata=Hzgeu43m5
> ZkeRMtL8Bx
> > gUm3%2B6FBObib1OPHPlSccE%2B0%3Dreserved=0
> >
> > Cc: Andre Przywara
> > Signed-off-by: Peng Fan
> > ---
> >
> > V2:
> > Add interrupts notification support.
> >
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile| 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 190
>
> > include/linux/mailbox/arm-smc-mailbox.h | 10 ++
> > 4 files changed, 209 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode
> > 100644 include/linux/mailbox/arm-smc-mailbox.h
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > 595542bfae85..c3bd0f1ddcd8 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,13 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > + tristate "Generic ARM smc mailbox"
> > + depends on OF && HAVE_ARM_SMCCC
> > + help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> > config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST diff --git
> > a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..fef6e38d8b98
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include #include
> > +
> > +#include
> > +#include
> > +
> > +#define ARM_SMC_MBOX_USE_HVC BIT(0)
> > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> > +
> IRQ bit is unused (and unnecessary IMO)
This will be removed in next version.
>
> > +struct arm_smc_chan_data {
> > + u32 function_id;
> > + u32 flags;
> > + int irq;
> > +};
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > + struct arm_smccc_mbox_cmd *cmd = data;
> > + struct arm_smccc_res res;
> > + u32 functi
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Hi Sudeep,
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Mon, Jun 03, 2019 at 04:30:05PM +0800, peng@nxp.com wrote:
> > From: Peng Fan
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C6b37f78032e446be750e08d6f560e707%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636966193913988679sdata=UNM4MTPs
> brqoMqWStEy
> > YzzwMEWTmX7hHO3TeNEz%2BOAw%3Dreserved=0
> >
> > Cc: Andre Przywara
> > Signed-off-by: Peng Fan
> > ---
> >
> > V2:
> > Add interrupts notification support.
> >
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile| 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 190
>
> > include/linux/mailbox/arm-smc-mailbox.h | 10 ++
> > 4 files changed, 209 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode
> > 100644 include/linux/mailbox/arm-smc-mailbox.h
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > 595542bfae85..c3bd0f1ddcd8 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,13 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > + tristate "Generic ARM smc mailbox"
> > + depends on OF && HAVE_ARM_SMCCC
> > + help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> > config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..fef6e38d8b98
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include #include
> > +
> > +#include
> > +#include
> > +
> > +#define ARM_SMC_MBOX_USE_HVC BIT(0)
> > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> > +
> > +struct arm_smc_chan_data {
> > + u32 function_id;
> > + u32 flags;
> > + int irq;
> > +};
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > + struct arm_smccc_mbox_cmd *cmd = data;
> > + struct arm_smccc_res res;
> > + u32 function_id;
> > +
> > + if (chan_data->function_id != UINT_MAX)
> > + function_id = chan_data->function_id;
> > + else
> > + function_id = cmd->a0;
> > +
> > + if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> > + arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3,
> cmd->a4,
> > + cmd->a5, cmd->a6, cmd->a7, );
> > + else
> > + arm_smccc_smc(function_id, cmd->a1, cmd->a2,
RE: [RFC 1/2] dt-bindings: imx-ocotp: Add fusable-node property
Hi Rob,
> Subject: Re: [RFC 1/2] dt-bindings: imx-ocotp: Add fusable-node property
>
> On Mon, May 20, 2019 at 03:06:35AM +0000, Peng Fan wrote:
> > Introduce fusable-node property for i.MX OCOTP driver.
> > The property will only be used by Firmware(eg. U-Boot) to runtime
> > disable the nodes.
> >
> > Take i.MX6ULL for example, there are several parts that only have
> > limited modules enabled controlled by OCOTP fuse. It is not flexible
> > to provide several dts for the serval parts, instead we could provide
> > one device tree and let Firmware to runtime disable the device tree
> > nodes for those modules that are disable(fused).
> >
> > Signed-off-by: Peng Fan
> > ---
> >
> > Currently NXP vendor use U-Boot to set status to disabled for devices
> > that could not function,
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
> >
> ce.codeaurora.org%2Fexternal%2Fimx%2Fuboot-imx%2Ftree%2Farch%2Far
> m%2Fm
> >
> ach-imx%2Fmx6%2Fmodule_fuse.c%3Fh%3Dimx_v2018.03_4.14.98_2.0.0_g
> a%23n1
> >
> 49data=02%7C01%7Cpeng.fan%40nxp.com%7Ceb74876c943c4471d7f
> f08d6f05
> >
> 2fffb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63696063660
> 6051306&
> >
> amp;sdata=MrjCP0ufBu3uTb1ehTEu2g5eSQuYcho4UxuR9KUFEOA%3D
> reserved=
> > 0 But this approach is will not work if kernel dts node path changed.
>
> Why would the path change? The DT should be stable.
It changes sometimes, such as
efb9adb27475 ("ARM: dts: imx6ul: Remove leading zeroes from unit addresses"),
in bootloader, we are using node path, so if the node name changes, the
bootloader
will fail to disable the node.
Thanks,
Peng.
>
> Rob
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Hi Andre,
> Subject: RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> Hi Andre,
> > Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
> >
> > On Mon, 3 Jun 2019 09:32:42 -0700
> > Florian Fainelli wrote:
> >
> > Hi,
> >
> > > On 6/3/19 1:30 AM, peng@nxp.com wrote:
> > > > From: Peng Fan
> > > >
> > > > This mailbox driver implements a mailbox which signals transmitted
> > > > data via an ARM smc (secure monitor call) instruction. The mailbox
> > > > receiver is implemented in firmware and can synchronously return
> > > > data when it returns execution to the non-secure world again.
> > > > An asynchronous receive path is not implemented.
> > > > This allows the usage of a mailbox to trigger firmware actions on
> > > > SoCs which either don't have a separate management processor or on
> > > > which such a core is not available. A user of this mailbox could
> > > > be the SCP interface.
> > > >
> > > > Modified from Andre Przywara's v2 patch
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > lo
> > > >
> >
> re.kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%
> > 7Cpen
> > > >
> >
> g.fan%40nxp.com%7C15c4180b8fe5405d3de808d6ea81d5f1%7C686ea1d3bc
> > 2b4c6
> > > >
> > fa92cd99c5c301635%7C0%7C0%7C636954240720601454sdata=1Cp
> > WSgTH7lF
> > > > cBKxJnLeIDw%2FDAQJJO%2FVypV1LUU1BRQA%3Dreserved=0
> > > >
> > > > Cc: Andre Przywara
> > > > Signed-off-by: Peng Fan
> > > > ---
> > >
> > > [snip]
> > >
> > > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> > >
> > > That flag appears unused.
> > >
> > > > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > > > + struct device *dev = >dev;
> > > > + struct mbox_controller *mbox;
> > > > + struct arm_smc_chan_data *chan_data;
> > > > + const char *method;
> > > > + bool use_hvc = false;
> > > > + int ret, irq_count, i;
> > > > + u32 val;
> > > > +
> > > > + if (!of_property_read_u32(dev->of_node, "arm,num-chans", ))
> > > > {
> > > > + if (val < 1 || val > INT_MAX) {
> > > > + dev_err(dev, "invalid arm,num-chans value %u
> > of %pOFn\n", val,
> > > > +pdev->dev.of_node);
> >
> > Isn't the of_node parameter redundant, because dev_err() already takes
> > care of that?
>
> I'll remove that.
>
> >
> > > > + return -EINVAL;
> > > > + }
> > > > + }
> > >
> > > Should not the upper bound check be done against UINT_MAX since val
> > > is an unsigned int?
> >
> > But wouldn't that be somewhat pointless, given that val is a u32? So I
> > guess we could just condense this down to:
> > ...
> > if (!val) {
> > ...
>
> make sense.
>
> >
> > > > +
> > > > + irq_count = platform_irq_count(pdev);
> > > > + if (irq_count == -EPROBE_DEFER)
> > > > + return irq_count;
> > > > +
> > > > + if (irq_count && irq_count != val) {
> > > > + dev_err(dev, "Interrupts not match num-chans\n");
> > >
> > > Interrupts property does not match \"arm,num-chans\" would be more
> > correct.
> >
> > Given that interrupts are optional, do we have to rely on this?
>
> If there is interrupt property, the interrupts should match channel counts.
>
> Do we actually
> > need one interrupt per channel?
>
> I thought about this, provide one interrupt for all channels.
> But there is no good way to let interrupt handlers know which channel
> triggers the interrupt. So I use one interrupt per channel.
>
> >
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + if (!of_property_read_string(dev->of_node, "method", )) {
> > > > + if (!strcmp("hvc", method)) {
> > > > + use_hvc = true;
> > > > + } else if (!strcmp("smc", method)) {
> > > > +
RE: linux-next: Fixes tag needs some work in the imx-mxs tree
> Subject: Re: linux-next: Fixes tag needs some work in the imx-mxs tree
>
> On Tue, Jun 11, 2019 at 08:36:52AM +0000, Peng Fan wrote:
> > Hi Shawn, Stephen
> > > Subject: Re: linux-next: Fixes tag needs some work in the imx-mxs
> > > tree
> > >
> > > On Fri, Jun 07, 2019 at 07:46:52AM +1000, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > In commit
> > > >
> > > > f6a8ff82ce68 ("clk: imx: imx8mm: correct audio_pll2_clk to
> > > > audio_pll2_out")
> > > >
> > > > Fixes tag
> > > >
> > > > Fixes: ba5625c3e27 ("clk: imx: Add clock driver support for
> > > > imx8mm")
> > > >
> > > > has these problem(s):
> > > >
> > > > - SHA1 should be at least 12 digits long
> > > > Can be fixed by setting core.abbrev to 12 (or more) or (for git
> > > > v2.11
> > > > or later) just making sure it is not set (or set to "auto").
> > >
> > > Hi Stephen,
> > >
> > > Thanks for reporting. I just got it fixed, will be more careful
> > > about that in the future.
> > >
> > > @Peng, please check your git configuration as suggested above, thanks.
> >
> > Sorry for this. Do I need to resend the patch?
>
> No. I have fixed it on my branch.
Thanks. I'll take care in future.
Thanks,
Peng.
>
> Shawn
RE: linux-next: Fixes tag needs some work in the imx-mxs tree
Hi Shawn, Stephen
> Subject: Re: linux-next: Fixes tag needs some work in the imx-mxs tree
>
> On Fri, Jun 07, 2019 at 07:46:52AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > In commit
> >
> > f6a8ff82ce68 ("clk: imx: imx8mm: correct audio_pll2_clk to
> > audio_pll2_out")
> >
> > Fixes tag
> >
> > Fixes: ba5625c3e27 ("clk: imx: Add clock driver support for imx8mm")
> >
> > has these problem(s):
> >
> > - SHA1 should be at least 12 digits long
> > Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
> > or later) just making sure it is not set (or set to "auto").
>
> Hi Stephen,
>
> Thanks for reporting. I just got it fixed, will be more careful about that
> in the
> future.
>
> @Peng, please check your git configuration as suggested above, thanks.
Sorry for this. Do I need to resend the patch?
Thanks,
Peng.
>
> Shawn
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Hi Andre,
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Mon, 3 Jun 2019 09:32:42 -0700
> Florian Fainelli wrote:
>
> Hi,
>
> > On 6/3/19 1:30 AM, peng@nxp.com wrote:
> > > From: Peng Fan
> > >
> > > This mailbox driver implements a mailbox which signals transmitted
> > > data via an ARM smc (secure monitor call) instruction. The mailbox
> > > receiver is implemented in firmware and can synchronously return
> > > data when it returns execution to the non-secure world again.
> > > An asynchronous receive path is not implemented.
> > > This allows the usage of a mailbox to trigger firmware actions on
> > > SoCs which either don't have a separate management processor or on
> > > which such a core is not available. A user of this mailbox could be
> > > the SCP interface.
> > >
> > > Modified from Andre Przywara's v2 patch
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > >
> re.kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%
> 7Cpen
> > >
> g.fan%40nxp.com%7C15c4180b8fe5405d3de808d6ea81d5f1%7C686ea1d3bc
> 2b4c6
> > >
> fa92cd99c5c301635%7C0%7C0%7C636954240720601454sdata=1Cp
> WSgTH7lF
> > > cBKxJnLeIDw%2FDAQJJO%2FVypV1LUU1BRQA%3Dreserved=0
> > >
> > > Cc: Andre Przywara
> > > Signed-off-by: Peng Fan
> > > ---
> >
> > [snip]
> >
> > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> >
> > That flag appears unused.
> >
> > > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > > + struct device *dev = >dev;
> > > + struct mbox_controller *mbox;
> > > + struct arm_smc_chan_data *chan_data;
> > > + const char *method;
> > > + bool use_hvc = false;
> > > + int ret, irq_count, i;
> > > + u32 val;
> > > +
> > > + if (!of_property_read_u32(dev->of_node, "arm,num-chans", )) {
> > > + if (val < 1 || val > INT_MAX) {
> > > + dev_err(dev, "invalid arm,num-chans value %u
> of %pOFn\n", val,
> > > +pdev->dev.of_node);
>
> Isn't the of_node parameter redundant, because dev_err() already takes care
> of that?
I'll remove that.
>
> > > + return -EINVAL;
> > > + }
> > > + }
> >
> > Should not the upper bound check be done against UINT_MAX since val is
> > an unsigned int?
>
> But wouldn't that be somewhat pointless, given that val is a u32? So I guess
> we could just condense this down to:
> ...
> if (!val) {
> ...
make sense.
>
> > > +
> > > + irq_count = platform_irq_count(pdev);
> > > + if (irq_count == -EPROBE_DEFER)
> > > + return irq_count;
> > > +
> > > + if (irq_count && irq_count != val) {
> > > + dev_err(dev, "Interrupts not match num-chans\n");
> >
> > Interrupts property does not match \"arm,num-chans\" would be more
> correct.
>
> Given that interrupts are optional, do we have to rely on this?
If there is interrupt property, the interrupts should match channel counts.
Do we actually
> need one interrupt per channel?
I thought about this, provide one interrupt for all channels.
But there is no good way to let interrupt handlers know which
channel triggers the interrupt. So I use one interrupt per channel.
>
> > > + return -EINVAL;
> > > + }
> > > +
> > > + if (!of_property_read_string(dev->of_node, "method", )) {
> > > + if (!strcmp("hvc", method)) {
> > > + use_hvc = true;
> > > + } else if (!strcmp("smc", method)) {
> > > + use_hvc = false;
> > > + } else {
> > > + dev_warn(dev, "invalid \"method\" property: %s\n",
> > > + method);
> > > +
> > > + return -EINVAL;
> > > + }
> >
> > Having at least one method specified does not seem to be checked later
> > on in the code, so if I omitted to specify that property, we would
> > still register the mailbox and default to use "smc" since the
> > ARM_SMC_MBOX_USE_HVC flag would not be set, would not we want to
> make
> > sure that we do have in fact a valid method specified given the
> > binding documents that property as mandatory?
> >
> > [snip]
> >
> > > + mbox->txdone_poll =
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> On 6/3/19 1:30 AM, peng@nxp.com wrote:
> > From: Peng Fan
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7Caa396ba11ba244111fe408d6e8411fba%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636951763738548621sdata=UlNESNg7I7
> 4TM9xp%2F
> > VMce4CSbMuJ95lh68cQw%2FnQMOw%3Dreserved=0
> >
> > Cc: Andre Przywara
> > Signed-off-by: Peng Fan
> > ---
>
> [snip]
>
> +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
>
> That flag appears unused.
I'll remove this in V3.
>
> > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > + struct device *dev = >dev;
> > + struct mbox_controller *mbox;
> > + struct arm_smc_chan_data *chan_data;
> > + const char *method;
> > + bool use_hvc = false;
> > + int ret, irq_count, i;
> > + u32 val;
> > +
> > + if (!of_property_read_u32(dev->of_node, "arm,num-chans", )) {
> > + if (val < 1 || val > INT_MAX) {
> > + dev_err(dev, "invalid arm,num-chans value %u of
> > %pOFn\n",
> val, pdev->dev.of_node);
> > + return -EINVAL;
> > + }
> > + }
>
> Should not the upper bound check be done against UINT_MAX since val is an
> unsigned int?
Fix in V3.
>
> > +
> > + irq_count = platform_irq_count(pdev);
> > + if (irq_count == -EPROBE_DEFER)
> > + return irq_count;
> > +
> > + if (irq_count && irq_count != val) {
> > + dev_err(dev, "Interrupts not match num-chans\n");
>
> Interrupts property does not match \"arm,num-chans\" would be more
> correct.
Fix in V3.
>
> > + return -EINVAL;
> > + }
> > +
> > + if (!of_property_read_string(dev->of_node, "method", )) {
> > + if (!strcmp("hvc", method)) {
> > + use_hvc = true;
> > + } else if (!strcmp("smc", method)) {
> > + use_hvc = false;
> > + } else {
> > + dev_warn(dev, "invalid \"method\" property: %s\n",
> > +method);
> > +
> > + return -EINVAL;
> > + }
>
> Having at least one method specified does not seem to be checked later on in
> the code, so if I omitted to specify that property, we would still register
> the
> mailbox and default to use "smc" since the ARM_SMC_MBOX_USE_HVC flag
> would not be set, would not we want to make sure that we do have in fact a
> valid method specified given the binding documents that property as
> mandatory?
When arm_smc_send_data, it will check ARM_SMC_MBOX_USE_HVC,
you mean there are other places needs this flag check?
>
> [snip]
>
> > + mbox->txdone_poll = false;
> > + mbox->txdone_irq = false;
> > + mbox->ops = _smc_mbox_chan_ops;
> > + mbox->dev = dev;
> > +
> > + ret = mbox_controller_register(mbox);
> > + if (ret)
> > + return ret;
> > +
> > + platform_set_drvdata(pdev, mbox);
>
> I would move this above mbox_controller_register() that way there is no room
> for race conditions in case another part of the driver expects to have
> pdev->dev.drvdata set before the mbox controller is registered.
Right.
> Since you use devm_* functions for everything, you may even remove that
> call.
You mean remove " platform_set_drvdata(pdev, mbox);" ?
>
> [snip]
>
> > +#ifndef _LINUX_ARM_SMC_MAILBOX_H_
> > +#define _LINUX_ARM_SMC_MAILBOX_H_
> > +
> > +struct arm_smccc_mbox_cmd {
> > + unsigned long a0, a1, a2, a3, a4, a5, a6, a7; };
>
> Do you expect this to be used by other in-kernel users? If so, it might be
> good
> to document how a0 can have a special meaning and be used as a substitute
> for the function_id?
This was to address comments here:
https://lore.kernel.org/patchwork/patch/812999/#1010433
Thanks,
Peng.
> --
> Florian
RE: [PATCH V2 1/2] DT: mailbox: add binding doc for the ARM SMC mailbox
> Subject: Re: [PATCH V2 1/2] DT: mailbox: add binding doc for the ARM SMC > mailbox > > On Mon, 3 Jun 2019 17:56:51 +0100 > Sudeep Holla wrote: > > Hi, > > > On Mon, Jun 03, 2019 at 09:22:16AM -0700, Florian Fainelli wrote: > > > On 6/3/19 1:30 AM, peng....@nxp.com wrote: > > > > From: Peng Fan > > > > > > > > The ARM SMC mailbox binding describes a firmware interface to > > > > trigger actions in software layers running in the EL2 or EL3 exception > levels. > > > > The term "ARM" here relates to the SMC instruction as part of the > > > > ARM instruction set, not as a standard endorsed by ARM Ltd. > > > > > > > > Signed-off-by: Peng Fan > > > > --- > > > > > > > > V2: > > > > Introduce interrupts as a property. > > > > > > > > V1: > > > > arm,func-ids is still kept as an optional property, because there > > > > is no defined SMC funciton id passed from SCMI. So in my test, I > > > > still use arm,func-ids for ARM SIP service. > > > > > > > > .../devicetree/bindings/mailbox/arm-smc.txt| 101 > + > > > > 1 file changed, 101 insertions(+) create mode 100644 > > > > Documentation/devicetree/bindings/mailbox/arm-smc.txt > > > > > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt > > > > b/Documentation/devicetree/bindings/mailbox/arm-smc.txt > > > > new file mode 100644 > > > > index ..401887118c09 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt > > > > @@ -0,0 +1,101 @@ > > > > [...] > > > > > > +Optional properties: > > > > +- arm,func-ids An array of 32-bit values specifying the > > > > function > > > > + IDs used by each mailbox channel. Those > > > > function IDs > > > > + follow the ARM SMC calling convention standard > > > > [1]. > > > > + There is one identifier per channel and the > > > > number > > > > + of supported channels is determined by the > > > > length > > > > + of this array. > > > > +- interrupts SPI interrupts may be listed for notification, > > > > + each channel should use a dedicated interrupt > > > > + line. > > > > > > I would not go about defining a specific kind of interrupt, since > > > SPI is a GIC terminology, this firmware interface could be used in > > > premise with any parent interrupt controller, for which the concept > > > of a SPI/PPI/SGI may not be relevant. > > > > > > > While I agree the binding document may not contain specifics, I still > > don't see how to use SGI with this. Also note it's generally reserved > > for OS future use(IPC) and using this for other than IPC may be bit > > challenging IMO. It opens up lots of questions. > > Well, a PPI might be possible to use, although it's somewhat dodgy to hijack > the GIC's (re-)distributor from EL3 to write to GICD_ISPENDR. Need to ask > Marc about his feelings towards this. But it's definitely possible from a > hypervisor to inject arbitrary interrupts into a guest. > > But more importantly: is there any actual reason this needs to be a GIC > interrupt? No. I just test ATF with SPI when I posting out this. Should not restrict to be GIC. If I understand the code correctly, this could just be any interrupt, > including one of an interrupt combiner or a GPIO chip. So why not just use the > standard wording of: "exactly one interrupt specifier for each channel"? Agree. > > By the way: Shouldn't new bindings use the YAML format instead? I'll convert to YAML in next version. Thanks, Peng. > > Cheers, > Andre.
[PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.
Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/
Cc: Andre Przywara
Signed-off-by: Peng Fan
---
V2:
Add interrupts notification support.
drivers/mailbox/Kconfig | 7 ++
drivers/mailbox/Makefile| 2 +
drivers/mailbox/arm-smc-mailbox.c | 190
include/linux/mailbox/arm-smc-mailbox.h | 10 ++
4 files changed, 209 insertions(+)
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
create mode 100644 include/linux/mailbox/arm-smc-mailbox.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 595542bfae85..c3bd0f1ddcd8 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -15,6 +15,13 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config ARM_SMC_MBOX
+ tristate "Generic ARM smc mailbox"
+ depends on OF && HAVE_ARM_SMCCC
+ help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..fef6e38d8b98
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,190 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ARM_SMC_MBOX_USE_HVC BIT(0)
+#define ARM_SMC_MBOX_USB_IRQ BIT(1)
+
+struct arm_smc_chan_data {
+ u32 function_id;
+ u32 flags;
+ int irq;
+};
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+ struct arm_smc_chan_data *chan_data = link->con_priv;
+ struct arm_smccc_mbox_cmd *cmd = data;
+ struct arm_smccc_res res;
+ u32 function_id;
+
+ if (chan_data->function_id != UINT_MAX)
+ function_id = chan_data->function_id;
+ else
+ function_id = cmd->a0;
+
+ if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
+ arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ cmd->a5, cmd->a6, cmd->a7, );
+ else
+ arm_smccc_smc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ cmd->a5, cmd->a6, cmd->a7, );
+
+ if (chan_data->irq)
+ return 0;
+
+ mbox_chan_received_data(link, (void *)res.a0);
+
+ return 0;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+ .send_data = arm_smc_send_data,
+};
+
+static irqreturn_t chan_irq_handler(int irq, void *data)
+{
+ struct mbox_chan *chan = data;
+
+ mbox_chan_received_data(chan, NULL);
+
+ return IRQ_HANDLED;
+}
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct mbox_controller *mbox;
+ struct arm_smc_chan_data *chan_data;
+ const char *method;
+ bool use_hvc = false;
+ int ret, irq_count, i;
+ u32 val;
+
+ if (!of_property_read_u32(dev->of_node, "arm,num-chans", )) {
+ if (val < 1 || val > INT_MAX) {
+ dev_err(dev, "invalid arm,num-chans value %u of
%pOFn\n", val, pdev->dev.of_node);
+ return -EINVAL;
+ }
+ }
+
+ irq_count = platform_irq_count(pdev);
+ if (irq_count == -EPROBE_DEFER)
+ return irq_count;
+
+ if (irq_count && irq_count != val) {
+ dev_err(dev, "Interrupts not match num-chans\n");
+ return -EINVAL;
+ }
+
+ if (!of_property_read_string(dev->o
[PATCH V2 0/2] mailbox: arm: introduce smc triggered mailbox
From: Peng Fan This is a modified version from Andre Przywara's patch series https://lore.kernel.org/patchwork/cover/812997/. The modification are mostly: Introduce arm,num-chans Introduce arm_smccc_mbox_cmd txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as an optional property. Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. Introduce interrupts notification. [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use smc as mailbox, power/clk is included, but only part of clk has been implemented to work with hardware, power domain only supports get name for now. The traditional Linux mailbox mechanism uses some kind of dedicated hardware IP to signal a condition to some other processing unit, typically a dedicated management processor. This mailbox feature is used for instance by the SCMI protocol to signal a request for some action to be taken by the management processor. However some SoCs does not have a dedicated management core to provide those services. In order to service TEE and to avoid linux shutdown power and clock that used by TEE, need let firmware to handle power and clock, the firmware here is ARM Trusted Firmware that could also run SCMI service. The existing SCMI implementation uses a rather flexible shared memory region to communicate commands and their parameters, it still requires a mailbox to actually trigger the action. This patch series provides a Linux mailbox compatible service which uses smc calls to invoke firmware code, for instance taking care of SCMI requests. The actual requests are still communicated using the standard SCMI way of shared memory regions, but a dedicated mailbox hardware IP can be replaced via this new driver. This simple driver uses the architected SMC calling convention to trigger firmware services, also allows for using "HVC" calls to call into hypervisors or firmware layers running in the EL2 exception level. Patch 1 contains the device tree binding documentation, patch 2 introduces the actual mailbox driver. Please note that this driver just provides a generic mailbox mechanism, It could support synchronous TX/RX, or synchronous TX with asynchronous RX. And while providing SCMI services was the reason for this exercise, this driver is in no way bound to this use case, but can be used generically where the OS wants to signal a mailbox condition to firmware or a hypervisor. Also the driver is in no way meant to replace any existing firmware interface, but actually to complement existing interfaces. [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi Peng Fan (2): DT: mailbox: add binding doc for the ARM SMC mailbox mailbox: introduce ARM SMC based mailbox .../devicetree/bindings/mailbox/arm-smc.txt| 101 +++ drivers/mailbox/Kconfig| 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 190 + include/linux/mailbox/arm-smc-mailbox.h| 10 ++ 5 files changed, 310 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode 100644 include/linux/mailbox/arm-smc-mailbox.h -- 2.16.4
[PATCH V2 1/2] DT: mailbox: add binding doc for the ARM SMC mailbox
From: Peng Fan
The ARM SMC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Signed-off-by: Peng Fan
---
V2:
Introduce interrupts as a property.
V1:
arm,func-ids is still kept as an optional property, because there is no
defined SMC funciton id passed from SCMI. So in my test, I still use
arm,func-ids for ARM SIP service.
.../devicetree/bindings/mailbox/arm-smc.txt| 101 +
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt
b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
new file mode 100644
index ..401887118c09
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
@@ -0,0 +1,101 @@
+ARM SMC Mailbox Interface
+=
+
+This mailbox uses the ARM smc (secure monitor call) instruction to trigger
+a mailbox-connected activity in firmware, executing on the very same core
+as the caller. By nature this operation is synchronous and this mailbox
+provides no way for asynchronous messages to be delivered the other way
+round, from firmware to the OS, but asynchronous notification could also
+be supported. However the value of r0/w0/x0 the firmware returns after
+the smc call is delivered as a received message to the mailbox framework,
+so a synchronous communication can be established, for a asynchronous
+notification, no value will be returned. The exact meaning of both the
+action the mailbox triggers as well as the return value is defined by
+their users and is not subject to this binding.
+
+One use case of this mailbox is the SCMI interface, which uses shared memory
+to transfer commands and parameters, and a mailbox to trigger a function
+call. This allows SoCs without a separate management processor (or when
+such a processor is not available or used) to use this standardized
+interface anyway.
+
+This binding describes no hardware, but establishes a firmware interface.
+Upon receiving an SMC using one of the described SMC function identifiers,
+the firmware is expected to trigger some mailbox connected functionality.
+The communication follows the ARM SMC calling convention[1].
+Firmware expects an SMC function identifier in r0 or w0. The supported
+identifiers are passed from consumers, or listed in the the arm,func-ids
+properties as described below. The firmware can return one value in
+the first SMC result register, it is expected to be an error value,
+which shall be propagated to the mailbox client.
+
+Any core which supports the SMC or HVC instruction can be used, as long as
+a firmware component running in EL3 or EL2 is handling these calls.
+
+Mailbox Device Node:
+
+
+This node is expected to be a child of the /firmware node.
+
+Required properties:
+
+- compatible: Shall be "arm,smc-mbox"
+- #mbox-cells Shall be 1 - the index of the channel needed.
+- arm,num-chansThe number of channels supported.
+- method: A string, either:
+ "hvc": if the driver shall use an HVC call, or
+ "smc": if the driver shall use an SMC call.
+
+Optional properties:
+- arm,func-ids An array of 32-bit values specifying the function
+ IDs used by each mailbox channel. Those function IDs
+ follow the ARM SMC calling convention standard [1].
+ There is one identifier per channel and the number
+ of supported channels is determined by the length
+ of this array.
+- interrupts SPI interrupts may be listed for notification,
+ each channel should use a dedicated interrupt
+ line.
+
+Example:
+
+
+ sram@91 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x93f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x93f000 0x1000>;
+
+ cpu_scp_lpri: scp-shmem@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x200>;
+ };
+
+ cpu_scp_hpri: scp-shmem@200 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x200 0x200>;
+ };
+ };
+
+ smc_mbox: mailbox {
+ #mbox-cells = <1>;
+ compatible = "arm,smc-mbox";
+ method = "smc";
+ arm,num-chans = <0x2>;
+
RE: [PATCH] clk: imx: imx8mm: correct audio_pll2_clk to audio_pll2_out
Hi Shawn,
> Subject: Re: [PATCH] clk: imx: imx8mm: correct audio_pll2_clk to
> audio_pll2_out
>
> On Thu, May 30, 2019 at 01:22:57AM +0000, Peng Fan wrote:
> > Hi Stephen,
> >
> > > Subject: Re: [PATCH] clk: imx: imx8mm: correct audio_pll2_clk to
> > > audio_pll2_out
> > >
> > > Quoting Shawn Guo (2019-05-23 06:22:36)
> > > > On Wed, May 22, 2019 at 01:34:46AM +, Peng Fan wrote:
> > > > > There is no audio_pll2_clk registered, it should be audio_pll2_out.
> > > > >
> > > > > Cc:
> > > > > Fixes: ba5625c3e27 ("clk: imx: Add clock driver support for
> > > > > imx8mm")
> > > > > Signed-off-by: Peng Fan
> > > >
> > > > Stephen,
> > > >
> > > > I leave this to you, since it's a fix.
> > > >
> > >
> > > Is it a critical fix? Or is it an annoyance that can wait in -next
> > > until the next merge window?
> >
> > I did not run into issue without this fix currently, so it should be
> > fine to wait in -next until the next merge window.
>
> I was trying to pick up the patch, but the base64 Content-Transfer-Encoding
> make the applying difficult. Please talk to NXP colleague Anson Huang
> to find out how to fix it.
This patch was sent out before we find workaround in our IT.
Sorry for inconvenience. Patch was resent just now,
https://patchwork.kernel.org/patch/10969743/
Thanks,
Peng.
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fpatch%2F10944169%2F%2322656941data=02%7C
> 01%7Cpeng.fan%40nxp.com%7Ca54e9a2a6ebf4411be7808d6e59c4c2e%7C6
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636948856849287143&
> amp;sdata=9ONV36WZT2owv07e%2Faf2IzQU5KzRE3S111joTBzsXJQ%3D
> mp;reserved=0
>
> Shawn
[PATCH RESEND] clk: imx: imx8mm: correct audio_pll2_clk to audio_pll2_out
From: Peng Fan
There is no audio_pll2_clk registered, it should be audio_pll2_out.
Cc:
Fixes: ba5625c3e27 ("clk: imx: Add clock driver support for imx8mm")
Signed-off-by: Peng Fan
---
drivers/clk/imx/clk-imx8mm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 1ef8438e3d6d..3a889846a05c 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -325,7 +325,7 @@ static const char *imx8mm_dsi_dbi_sels[] = {"osc_24m",
"sys_pll1_266m", "sys_pll
"sys_pll2_1000m", "sys_pll3_out",
"audio_pll2_out", "video_pll1_out", };
static const char *imx8mm_usdhc3_sels[] = {"osc_24m", "sys_pll1_400m",
"sys_pll1_800m", "sys_pll2_500m",
- "sys_pll3_out", "sys_pll1_266m",
"audio_pll2_clk", "sys_pll1_100m", };
+ "sys_pll3_out", "sys_pll1_266m",
"audio_pll2_out", "sys_pll1_100m", };
static const char *imx8mm_csi1_core_sels[] = {"osc_24m", "sys_pll1_266m",
"sys_pll2_250m", "sys_pll1_800m",
"sys_pll2_1000m", "sys_pll3_out",
"audio_pll2_out", "video_pll1_out", };
@@ -361,11 +361,11 @@ static const char *imx8mm_pdm_sels[] = {"osc_24m",
"sys_pll2_100m", "audio_pll1_
"sys_pll2_1000m", "sys_pll3_out",
"clk_ext3", "audio_pll2_out", };
static const char *imx8mm_vpu_h1_sels[] = {"osc_24m", "vpu_pll_out",
"sys_pll1_800m", "sys_pll2_1000m",
- "audio_pll2_clk", "sys_pll2_125m",
"sys_pll3_clk", "audio_pll1_out", };
+ "audio_pll2_out", "sys_pll2_125m",
"sys_pll3_clk", "audio_pll1_out", };
static const char *imx8mm_dram_core_sels[] = {"dram_pll_out", "dram_alt_root",
};
-static const char *imx8mm_clko1_sels[] = {"osc_24m", "sys_pll1_800m",
"osc_27m", "sys_pll1_200m", "audio_pll2_clk",
+static const char *imx8mm_clko1_sels[] = {"osc_24m", "sys_pll1_800m",
"osc_27m", "sys_pll1_200m", "audio_pll2_out",
"vpu_pll", "sys_pll1_80m", };
static struct clk *clks[IMX8MM_CLK_END];
--
2.16.4
RE: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox
> > > > Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered > > > mailbox > > > > > > Hi, > > > > > > On 5/22/19 10:50 PM, Peng Fan wrote: > > > > This is a modified version from Andre Przywara's patch series > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo > > > re.ke > rnel.org%2Fpatchwork%2Fcover%2F812997%2Fdata=02%7C01%7Cpe > > > > ng.fan%40nxp.com%7C010c9ddd5df645c9c66b08d6dfa46cb2%7C686ea1d3b > > > > c2b4c6fa92cd99c5c301635%7C0%7C0%7C636942294631442665sdat > > > > a=BbS5ZQtzMANSwaKRDJ62NKrPrAyaED1%2BvymQaT6Qr8E%3Drese > > > rved=0. > > > > [1] is a draft implementation of i.MX8MM SCMI ATF implementation > > > > that use smc as mailbox, power/clk is included, but only part of > > > > clk has been implemented to work with hardware, power domain only > > > > supports get name for now. > > > > > > > > The traditional Linux mailbox mechanism uses some kind of > > > > dedicated hardware IP to signal a condition to some other > > > > processing unit, typically a dedicated management processor. > > > > This mailbox feature is used for instance by the SCMI protocol to > > > > signal a request for some action to be taken by the management > processor. > > > > However some SoCs does not have a dedicated management core to > > > provide > > > > those services. In order to service TEE and to avoid linux > > > > shutdown power and clock that used by TEE, need let firmware to > > > > handle power and clock, the firmware here is ARM Trusted Firmware > > > > that could also run SCMI service. > > > > > > > > The existing SCMI implementation uses a rather flexible shared > > > > memory region to communicate commands and their parameters, it > > > > still requires a mailbox to actually trigger the action. > > > > > > We have had something similar done internally with a couple of minor > > > differences: > > > > > > - a SGI is used to send SCMI notifications/delayed replies to > > > support asynchronism (patches are in the works to actually add that > > > to the Linux SCMI framework). There is no good support for SGI in > > > the kernel right now so we hacked up something from the existing SMP > > > code and adding the ability to register our own IPI handlers > > > (SHAME!). Using a PPI should work and should allow for using request_irq() > AFAICT. > > > > So you are also implementing a firmware inside ATF for SCMI usecase, right? > > > > Introducing SGI in ATF to notify Linux will introduce complexity, > > there is no good framework inside ATF for SCMI, and I use > > synchronization call for simplicity for now. > > I think we don't disagree, but just to clarify on one thing: > > I think we should avoid tying this driver to specific protocol or software on > the > other end, be it ATF or SCMI. After all it's just a mailbox driver, meant to > signal > some event (and parameters) to some external entity. Yes, SCMI (or SCPI back > then) was the reason to push for this, but it should be independent from that. Thanks, I agree. > I am not even sure we should mention it too much in the documentation. I think we need a usecase here, so it should be fine. > > So whether the receiving end is ATF or something else it irrelevant, I think. > For > instance we have had discussions in Xen to provide guests some virtualised > device management support, and using an HVC mailbox seems like a neat > solution. This could be using the SCMI (or SCPI) protocol, but that's not a > requirement. In this case the Xen hypervisor would be the one to pick up the > mailbox trigger, probably forwarding the request to something else (Dom0 in > this case). I do not get the point "forwarding the request", DomU HVC will trap to Xen, so how to forward to Dom0? Thanks, Peng. > Also having a generic SMC mailbox could avoid having the actual hardware > mailbox drivers in the kernel, so EL3 firmware could forward the request to an > external management processor, and Linux would just work, without the need > to describe the actual hardware mailbox device in some firmware tables. This > might help ACPI on those devices. > > Cheers, > Andre. > > > > > > > - the mailbox identifier is indicated as part of the SMC call such > > > that we can have multiple SCMI mailboxes serving both standard > > > protocols and non-standard (in the 0x80 and above) range, also
RE: [PATCH] clk: imx: imx8mm: correct audio_pll2_clk to audio_pll2_out
Hi Stephen,
> Subject: Re: [PATCH] clk: imx: imx8mm: correct audio_pll2_clk to
> audio_pll2_out
>
> Quoting Shawn Guo (2019-05-23 06:22:36)
> > On Wed, May 22, 2019 at 01:34:46AM +, Peng Fan wrote:
> > > There is no audio_pll2_clk registered, it should be audio_pll2_out.
> > >
> > > Cc:
> > > Fixes: ba5625c3e27 ("clk: imx: Add clock driver support for imx8mm")
> > > Signed-off-by: Peng Fan
> >
> > Stephen,
> >
> > I leave this to you, since it's a fix.
> >
>
> Is it a critical fix? Or is it an annoyance that can wait in -next until the
> next
> merge window?
I did not run into issue without this fix currently, so it should be fine to
wait
in -next until the next merge window.
Thanks,
Peng.
RE: [RFC 1/2] dt-bindings: imx-ocotp: Add fusable-node property
Hi Rob, Srinivas
> Subject: [RFC 1/2] dt-bindings: imx-ocotp: Add fusable-node property
Do you have any comments about this patch?
Thanks,
Peng.
>
> Introduce fusable-node property for i.MX OCOTP driver.
> The property will only be used by Firmware(eg. U-Boot) to runtime disable the
> nodes.
>
> Take i.MX6ULL for example, there are several parts that only have limited
> modules enabled controlled by OCOTP fuse. It is not flexible to provide
> several
> dts for the serval parts, instead we could provide one device tree and let
> Firmware to runtime disable the device tree nodes for those modules that are
> disable(fused).
>
> Signed-off-by: Peng Fan
> ---
>
> Currently NXP vendor use U-Boot to set status to disabled for devices that
> could not function,
> https://source.codeaurora.org/external/imx/uboot-imx/tree/arch/arm/mach
> -imx/mx6/module_fuse.c?h=imx_v2018.03_4.14.98_2.0.0_ga#n149
> But this approach is will not work if kernel dts node path changed.
>
> There are two approaches to resolve:
>
> 1. This patch is to add a fusable-node property, and Firmware will parse
>the property and read fuse to decide whether to disable or keeep enable
>the nodes.
>
> 2. There is another approach is that add nvmem-cells for all nodes that
>could be disabled(fused). Then in each linux driver to use nvmem
>api to detect fused or not, or in linux driver common code to check
>device functionable or not with nvmem API.
>
>
> To make it easy to work, we choose [1] here. Please advise whether it is
> acceptable, because the property is not used by linux driver in approach [1].
> Or you prefer [2] or please advise if any better solution.
>
> Thanks.
>
> Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> index 7a999a135e56..e9a998588dbd 100644
> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> @@ -21,6 +21,8 @@ Required properties:
>
> Optional properties:
> - read-only: disable write access
> +- fusable-node: array of phandles with reg base and bit offset, this
> + property is used by Firmware to runtime disable nodes.
>
> Optional Child nodes:
>
> @@ -42,4 +44,7 @@ Example:
> tempmon_temp_grade: temp-grade@20 {
> reg = <0x20 4>;
> };
> +
> + fusable-node = < 0x10 4
> + 0x10 5>;
> };
> --
> 2.16.4
RE: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox
Hi Andre, > Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox > > On 24/05/2019 18:56, Sudeep Holla wrote: > > On Thu, May 23, 2019 at 10:30:50AM -0700, Florian Fainelli wrote: > > Hi, > > >> On 5/22/19 10:50 PM, Peng Fan wrote: > >>> This is a modified version from Andre Przywara's patch series > >>> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke > rnel.org%2Fpatchwork%2Fcover%2F812997%2Fdata=02%7C01%7Cpe > ng.fan%40nxp.com%7C02ee9487370c4eb9158008d6e2363ca0%7C686ea1d3 > bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636945119959534576sda > ta=U8FzX3FX2PoEZhRuRMhFbkaAnb3cqjZsb9%2FTdt8OfuY%3Dreserve > d=0. > >>> [1] is a draft implementation of i.MX8MM SCMI ATF implementation > >>> that use smc as mailbox, power/clk is included, but only part of clk > >>> has been implemented to work with hardware, power domain only > >>> supports get name for now. > >>> > >>> The traditional Linux mailbox mechanism uses some kind of dedicated > >>> hardware IP to signal a condition to some other processing unit, > >>> typically a dedicated management processor. > >>> This mailbox feature is used for instance by the SCMI protocol to > >>> signal a request for some action to be taken by the management > processor. > >>> However some SoCs does not have a dedicated management core to > >>> provide those services. In order to service TEE and to avoid linux > >>> shutdown power and clock that used by TEE, need let firmware to > >>> handle power and clock, the firmware here is ARM Trusted Firmware > >>> that could also run SCMI service. > >>> > >>> The existing SCMI implementation uses a rather flexible shared > >>> memory region to communicate commands and their parameters, it still > >>> requires a mailbox to actually trigger the action. > >> > >> We have had something similar done internally with a couple of minor > >> differences: > >> > >> - a SGI is used to send SCMI notifications/delayed replies to support > >> asynchronism (patches are in the works to actually add that to the > >> Linux SCMI framework). There is no good support for SGI in the kernel > >> right now so we hacked up something from the existing SMP code and > >> adding the ability to register our own IPI handlers (SHAME!). Using a > >> PPI should work and should allow for using request_irq() AFAICT. > >> > > > > We have been thinking this since we were asked if SMC can be transport. > > Generally out of 16 SGIs, 8 are reserved for secure side and > > non-secure has 8. Of these 8, IIUC 7 is already being used by kernel. > > So unless we manage to get the last one reserved exclusive to SCMI, it > > makes it difficult to add SGI support in SCMI. > > > > We have been telling partners/vendors about this limitation if they > > use SMC as transport and need to have dedicated h/w interrupt for the > > notifications. > > > > Another issue could be with virtualisation(using HVC) and EL handling > > so called SCMI SGI. We need to think about those too. I will try to > > get more info on this and come back on this. > > I think regardless of the *current* feasibility of using SGIs in *Linux* we > should at least specify an "interrupts" property in the binding, to allow for > future usage. We might copy the pmuv3 way [1] of allowing to specify > multiple SPI interrupts as well, to give more flexibility. This needs to go with an optional property, agree? That means smc mailbox needs to support synchronous and asynchronous communication. I'll try to add that and write some porotype code to verify. Thanks, Peng. > After all an implementation could offload the asynchronous notification to a > separate core, and that could use SPIs, for instance. > > Cheers, > Andre. > > [1] Documentation/devicetree/bindings/arm/pmu.yaml:45
RE: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox
Hi Sudeep, > Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox > > On Thu, May 23, 2019 at 10:30:50AM -0700, Florian Fainelli wrote: > > Hi, > > > > On 5/22/19 10:50 PM, Peng Fan wrote: > > > This is a modified version from Andre Przywara's patch series > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke > rnel.org%2Fpatchwork%2Fcover%2F812997%2Fdata=02%7C01%7Cpe > ng.fan%40nxp.com%7Cfa2ba15f479b49eb219f08d6e0713ea3%7C686ea1d3b > c2b4c6fa92cd99c5c301635%7C0%7C0%7C636943174355592142sdat > a=Y94rnxDEoMm9nyRyjJrYBqRduc5XkvvQhno7zfIQ%2B04%3Dreserve > d=0. > > > [1] is a draft implementation of i.MX8MM SCMI ATF implementation > > > that use smc as mailbox, power/clk is included, but only part of clk > > > has been implemented to work with hardware, power domain only > > > supports get name for now. > > > > > > The traditional Linux mailbox mechanism uses some kind of dedicated > > > hardware IP to signal a condition to some other processing unit, > > > typically a dedicated management processor. > > > This mailbox feature is used for instance by the SCMI protocol to > > > signal a request for some action to be taken by the management > processor. > > > However some SoCs does not have a dedicated management core to > > > provide those services. In order to service TEE and to avoid linux > > > shutdown power and clock that used by TEE, need let firmware to > > > handle power and clock, the firmware here is ARM Trusted Firmware > > > that could also run SCMI service. > > > > > > The existing SCMI implementation uses a rather flexible shared > > > memory region to communicate commands and their parameters, it still > > > requires a mailbox to actually trigger the action. > > > > We have had something similar done internally with a couple of minor > > differences: > > > > - a SGI is used to send SCMI notifications/delayed replies to support > > asynchronism (patches are in the works to actually add that to the > > Linux SCMI framework). There is no good support for SGI in the kernel > > right now so we hacked up something from the existing SMP code and > > adding the ability to register our own IPI handlers (SHAME!). Using a > > PPI should work and should allow for using request_irq() AFAICT. > > > > We have been thinking this since we were asked if SMC can be transport. > Generally out of 16 SGIs, 8 are reserved for secure side and non-secure has 8. > Of these 8, IIUC 7 is already being used by kernel. So unless we manage to get > the last one reserved exclusive to SCMI, it makes it difficult to add SGI > support > in SCMI. > > We have been telling partners/vendors about this limitation if they use SMC > as transport and need to have dedicated h/w interrupt for the notifications. This is an option, and we could add optional property. > > Another issue could be with virtualisation(using HVC) and EL handling so > called > SCMI SGI. We need to think about those too. Using dedicated HW for virtualization that support vcpu scheduling might be not a good choice, do you mean this? Dedicated pin vcpu to pcpu should be fine, just like jailhouse hypervisor. I will try to get more info on this > and come back on this. Looking forward. Thanks, Peng. > > -- > Regards, > Sudeep
RE: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox
Hi Florian, > Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox > > Hi, > > On 5/22/19 10:50 PM, Peng Fan wrote: > > This is a modified version from Andre Przywara's patch series > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke > rnel.org%2Fpatchwork%2Fcover%2F812997%2Fdata=02%7C01%7Cpe > ng.fan%40nxp.com%7C010c9ddd5df645c9c66b08d6dfa46cb2%7C686ea1d3b > c2b4c6fa92cd99c5c301635%7C0%7C0%7C636942294631442665sdat > a=BbS5ZQtzMANSwaKRDJ62NKrPrAyaED1%2BvymQaT6Qr8E%3Drese > rved=0. > > [1] is a draft implementation of i.MX8MM SCMI ATF implementation that > > use smc as mailbox, power/clk is included, but only part of clk has > > been implemented to work with hardware, power domain only supports get > > name for now. > > > > The traditional Linux mailbox mechanism uses some kind of dedicated > > hardware IP to signal a condition to some other processing unit, > > typically a dedicated management processor. > > This mailbox feature is used for instance by the SCMI protocol to > > signal a request for some action to be taken by the management processor. > > However some SoCs does not have a dedicated management core to > provide > > those services. In order to service TEE and to avoid linux shutdown > > power and clock that used by TEE, need let firmware to handle power > > and clock, the firmware here is ARM Trusted Firmware that could also > > run SCMI service. > > > > The existing SCMI implementation uses a rather flexible shared memory > > region to communicate commands and their parameters, it still requires > > a mailbox to actually trigger the action. > > We have had something similar done internally with a couple of minor > differences: > > - a SGI is used to send SCMI notifications/delayed replies to support > asynchronism (patches are in the works to actually add that to the Linux SCMI > framework). There is no good support for SGI in the kernel right now so we > hacked up something from the existing SMP code and adding the ability to > register our own IPI handlers (SHAME!). Using a PPI should work and should > allow for using request_irq() AFAICT. So you are also implementing a firmware inside ATF for SCMI usecase, right? Introducing SGI in ATF to notify Linux will introduce complexity, there is no good framework inside ATF for SCMI, and I use synchronization call for simplicity for now. > > - the mailbox identifier is indicated as part of the SMC call such that we can > have multiple SCMI mailboxes serving both standard protocols and > non-standard (in the 0x80 and above) range, also they may have different > throughput (in hindsight, these could simply be different channels) > > Your patch series looks both good and useful to me, I would just put a > provision in the binding to support an optional interrupt such that > asynchronism gets reasonably easy to plug in when it is available (and > desirable). Ok. Let me think about and add that in new version patch. Thanks, Peng. > > > > > This patch series provides a Linux mailbox compatible service which > > uses smc calls to invoke firmware code, for instance taking care of SCMI > requests. > > The actual requests are still communicated using the standard SCMI way > > of shared memory regions, but a dedicated mailbox hardware IP can be > > replaced via this new driver. > > > > This simple driver uses the architected SMC calling convention to > > trigger firmware services, also allows for using "HVC" calls to call > > into hypervisors or firmware layers running in the EL2 exception level. > > > > Patch 1 contains the device tree binding documentation, patch 2 > > introduces the actual mailbox driver. > > > > Please note that this driver just provides a generic mailbox > > mechanism, though this is synchronous and one-way only (triggered by > > the OS only, without providing an asynchronous way of triggering > > request from the firmware). > > And while providing SCMI services was the reason for this exercise, > > this driver is in no way bound to this use case, but can be used > > generically where the OS wants to signal a mailbox condition to > > firmware or a hypervisor. > > Also the driver is in no way meant to replace any existing firmware > > interface, but actually to complement existing interfaces. > > > > [1] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > > ub.com%2FMrVan%2Farm-trusted-firmware%2Ftree%2Fscmidata=02 > %7C01%7 > > > Cpeng.fan%40nxp.com%7C010c9ddd5df645c9c66b08d6dfa46cb2%7C686ea1 > d3bc2b4 >
RE: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox
Hi Jassi, > Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox > > On Thu, May 23, 2019 at 12:50 AM Peng Fan wrote: > > > > This is a modified version from Andre Przywara's patch series > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke > rnel.org%2Fpatchwork%2Fcover%2F812997%2Fdata=02%7C01%7Cpe > ng.fan%40nxp.com%7C40bb1632f99248f24e1308d6e2467c8b%7C686ea1d3b > c2b4c6fa92cd99c5c301635%7C0%7C1%7C636945189705620796sdat > a=v6mLyDKLO8NaBMlX6XlOCtOs2C41TuOG9yFDY%2F7q8nU%3Dreser > ved=0. > > > Can you please specify exact modifications on top of Andre's last submission? > As in "Changes since v1: " Since Andre's last v2 version was sent in 2017, I thought no need to add that. The changes are mostly. Introduce arm,num-chans Introduce arm_smccc_mbox_cmd txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as an optional property. Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. I'll add the changes information after I collect more comments in this patchset. Thanks, Peng. > > Thanks.
RE: [PATCH V3 RESEND 3/4] defconfig: arm64: enable i.MX8 SCU octop driver
Hi Shawn, > -Original Message- > From: Shawn Guo [mailto:shawn...@kernel.org] > Sent: 2019年5月23日 20:53 > To: Peng Fan > Cc: srinivas.kandaga...@linaro.org; robh...@kernel.org; > s.ha...@pengutronix.de; feste...@gmail.com; dl-linux-imx > ; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; > van.free...@gmail.com; Catalin Marinas ; Will > Deacon ; Shawn Guo ; Andy > Gross ; Maxime Ripard > ; Olof Johansson ; Jagan Teki > ; Bjorn Andersson > ; Leonard Crestez ; > Marc Gonzalez ; Enric Balletbo i Serra > > Subject: Re: [PATCH V3 RESEND 3/4] defconfig: arm64: enable i.MX8 SCU > octop driver > > On Wed, May 22, 2019 at 01:47:05AM +, Peng Fan wrote: > > Build in CONFIG_NVMEM_IMX_OCOTP_SCU. > > > > Cc: Catalin Marinas > > Cc: Will Deacon > > Cc: Shawn Guo > > Cc: Andy Gross > > Cc: Maxime Ripard > > Cc: Olof Johansson > > Cc: Jagan Teki > > Cc: Bjorn Andersson > > Cc: Leonard Crestez > > Cc: Marc Gonzalez > > Cc: Enric Balletbo i Serra > > Cc: linux-arm-ker...@lists.infradead.org > > Reviewed-by: Dong Aisheng > > Signed-off-by: Peng Fan > > Please do not use base64 encoding for patch posting. Since Srinivas picked up patch 1/4 and 2/4, so just resend the patch 3/4 and patch 4/4. https://patchwork.kernel.org/patch/10959149/ https://patchwork.kernel.org/patch/10959151/ Thanks, Peng. > > Shawn > > > --- > > > > V3: > > No change > > V2: > > rename patch title, add review tag > > > > arch/arm64/configs/defconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm64/configs/defconfig > > b/arch/arm64/configs/defconfig index 979a95c915b6..32b85102b857 > 100644 > > --- a/arch/arm64/configs/defconfig > > +++ b/arch/arm64/configs/defconfig > > @@ -748,6 +748,7 @@ CONFIG_HISI_PMU=y > > CONFIG_QCOM_L2_PMU=y > > CONFIG_QCOM_L3_PMU=y > > CONFIG_NVMEM_IMX_OCOTP=y > > +CONFIG_NVMEM_IMX_OCOTP_SCU=y > > CONFIG_QCOM_QFPROM=y > > CONFIG_ROCKCHIP_EFUSE=y > > CONFIG_UNIPHIER_EFUSE=y > > -- > > 2.16.4 > >
[PATCH V3 RESEND AGAIN 1/2] defconfig: arm64: enable i.MX8 SCU octop driver
From: Peng Fan Build in CONFIG_NVMEM_IMX_OCOTP_SCU. Cc: Catalin Marinas Cc: Will Deacon Cc: Shawn Guo Cc: Andy Gross Cc: Maxime Ripard Cc: Olof Johansson Cc: Jagan Teki Cc: Bjorn Andersson Cc: Leonard Crestez Cc: Marc Gonzalez Cc: Enric Balletbo i Serra Cc: linux-arm-ker...@lists.infradead.org Reviewed-by: Dong Aisheng Signed-off-by: Peng Fan --- V3: No change V2: rename patch title, add review tag arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 979a95c915b6..32b85102b857 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -748,6 +748,7 @@ CONFIG_HISI_PMU=y CONFIG_QCOM_L2_PMU=y CONFIG_QCOM_L3_PMU=y CONFIG_NVMEM_IMX_OCOTP=y +CONFIG_NVMEM_IMX_OCOTP_SCU=y CONFIG_QCOM_QFPROM=y CONFIG_ROCKCHIP_EFUSE=y CONFIG_UNIPHIER_EFUSE=y -- 2.16.4
[PATCH V3 RESEND AGAIN 2/2] arm64: dts: imx: add i.MX8QXP ocotp support
From: Peng Fan
Add i.MX8QXP ocotp node
Cc: Rob Herring
Cc: Mark Rutland
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: Anson Huang
Cc: Daniel Baluta
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Dong Aisheng
Signed-off-by: Peng Fan
---
V3:
Add R-b tag
V2:
move address/size-cells below compatible, add "scu"
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 0683ee2a48ae..725d341ee160 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -141,6 +141,12 @@
compatible = "fsl,imx8qxp-iomuxc";
};
+ ocotp: imx8qx-ocotp {
+ compatible = "fsl,imx8qxp-scu-ocotp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd";
#power-domain-cells = <1>;
--
2.16.4
[PATCH 1/2] DT: mailbox: add binding doc for the ARM SMC mailbox
The ARM SMC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Signed-off-by: Peng Fan
---
V1:
arm,func-ids is still kept as an optional property, because there is no
defined SMC funciton id passed from SCMI. So in my test, I still use
arm,func-ids for ARM SIP service.
.../devicetree/bindings/mailbox/arm-smc.txt| 96 ++
1 file changed, 96 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt
b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
new file mode 100644
index ..12fc5997933d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
@@ -0,0 +1,96 @@
+ARM SMC Mailbox Interface
+=
+
+This mailbox uses the ARM smc (secure monitor call) instruction to
+trigger a mailbox-connected activity in firmware, executing on the very same
+core as the caller. By nature this operation is synchronous and this
+mailbox provides no way for asynchronous messages to be delivered the other
+way round, from firmware to the OS. However the value of r0/w0/x0 the firmware
+returns after the smc call is delivered as a received message to the
+mailbox framework, so a synchronous communication can be established.
+The exact meaning of both the action the mailbox triggers as well as the
+return value is defined by their users and is not subject to this binding.
+
+One use case of this mailbox is the SCMI interface, which uses shared memory
+to transfer commands and parameters, and a mailbox to trigger a function
+call. This allows SoCs without a separate management processor (or
+when such a processor is not available or used) to use this standardized
+interface anyway.
+
+This binding describes no hardware, but establishes a firmware interface.
+Upon receiving an SMC using one of the described SMC function identifiers,
+the firmware is expected to trigger some mailbox connected functionality.
+The communication follows the ARM SMC calling convention[1].
+Firmware expects an SMC function identifier in r0 or w0. The supported
+identifiers are passed from consumers, or listed in the the arm,func-ids
+properties as described below. The firmware can return one value in
+the first SMC result register, it is expected to be an error value,
+which shall be propagated to the mailbox client.
+
+Any core which supports the SMC or HVC instruction can be used, as long as
+a firmware component running in EL3 or EL2 is handling these calls.
+
+Mailbox Device Node:
+
+
+This node is expected to be a child of the /firmware node.
+
+Required properties:
+
+- compatible: Shall be "arm,smc-mbox"
+- #mbox-cells Shall be 1 - the index of the channel needed.
+- arm,num-chansThe number of channels supported.
+- method: A string, either:
+ "hvc": if the driver shall use an HVC call, or
+ "smc": if the driver shall use an SMC call.
+
+Optional properties:
+- arm,func-ids An array of 32-bit values specifying the function
+ IDs used by each mailbox channel. Those function IDs
+ follow the ARM SMC calling convention standard [1].
+ There is one identifier per channel and the number
+ of supported channels is determined by the length
+ of this array.
+
+Example:
+
+
+ sram@91 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x93f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x93f000 0x1000>;
+
+ cpu_scp_lpri: scp-shmem@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x200>;
+ };
+
+ cpu_scp_hpri: scp-shmem@200 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x200 0x200>;
+ };
+ };
+
+ smc_mbox: mailbox {
+ #mbox-cells = <1>;
+ compatible = "arm,smc-mbox";
+ method = "smc";
+ arm,num-chans = <0x2>;
+ /* Optional */
+ arm,func-ids = <0xc2fe>, <0xc2ff>;
+ };
+
+ firmware {
+ scmi {
+ compatible = "arm,scmi";
+ mboxes = < 0 1>;
+ mbox-names = "tx", "rx";
+ shmem = <_scp_lpri _scp_hpri>;
+ };
+ };
+
+
+[1]
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.html
--
2.16.4
[PATCH 2/2] mailbox: introduce ARM SMC based mailbox
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.
Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/
Cc: Andre Przywara
Signed-off-by: Peng Fan
---
drivers/mailbox/Kconfig | 7 ++
drivers/mailbox/Makefile| 2 +
drivers/mailbox/arm-smc-mailbox.c | 154
include/linux/mailbox/arm-smc-mailbox.h | 10 +++
4 files changed, 173 insertions(+)
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
create mode 100644 include/linux/mailbox/arm-smc-mailbox.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 595542bfae85..c3bd0f1ddcd8 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -15,6 +15,13 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config ARM_SMC_MBOX
+ tristate "Generic ARM smc mailbox"
+ depends on OF && HAVE_ARM_SMCCC
+ help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..f4da1061f7f0
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ARM_SMC_MBOX_USE_HVC BIT(0)
+
+struct arm_smc_chan_data {
+ u32 function_id;
+ u32 flags;
+};
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+ struct arm_smc_chan_data *chan_data = link->con_priv;
+ struct arm_smccc_mbox_cmd *cmd = data;
+ struct arm_smccc_res res;
+ u32 function_id;
+
+ if (chan_data->function_id != UINT_MAX)
+ function_id = chan_data->function_id;
+ else
+ function_id = cmd->a0;
+
+ if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
+ arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ cmd->a5, cmd->a6, cmd->a7, );
+ else
+ arm_smccc_smc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ cmd->a5, cmd->a6, cmd->a7, );
+
+ mbox_chan_received_data(link, (void *)res.a0);
+
+ return 0;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+ .send_data = arm_smc_send_data,
+};
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct mbox_controller *mbox;
+ struct arm_smc_chan_data *chan_data;
+ const char *method;
+ bool use_hvc = false;
+ int ret, i;
+ u32 val;
+
+ if (!of_property_read_u32(dev->of_node, "arm,num-chans", )) {
+ if (val < 1 || val > INT_MAX) {
+ dev_err(dev, "invalid arm,num-chans value %u of
%pOFn\n", val, pdev->dev.of_node);
+ return -EINVAL;
+ }
+ }
+
+ if (!of_property_read_string(dev->of_node, "method", )) {
+ if (!strcmp("hvc", method)) {
+ use_hvc = true;
+ } else if (!strcmp("smc", method)) {
+ use_hvc = false;
+ } else {
+ dev_warn(dev, "invalid \"method\" property: %s\n",
+method);
+
+ return -EINVAL;
+ }
+ }
+
+ mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+ if (!mbox)
+ return -ENOMEM;
+
+ mbox->num_chans = val;
+ mbox->chans = devm_kcalloc(dev, mbox->num_chan
[PATCH 0/2] mailbox: arm: introduce smc triggered mailbox
This is a modified version from Andre Przywara's patch series https://lore.kernel.org/patchwork/cover/812997/. [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use smc as mailbox, power/clk is included, but only part of clk has been implemented to work with hardware, power domain only supports get name for now. The traditional Linux mailbox mechanism uses some kind of dedicated hardware IP to signal a condition to some other processing unit, typically a dedicated management processor. This mailbox feature is used for instance by the SCMI protocol to signal a request for some action to be taken by the management processor. However some SoCs does not have a dedicated management core to provide those services. In order to service TEE and to avoid linux shutdown power and clock that used by TEE, need let firmware to handle power and clock, the firmware here is ARM Trusted Firmware that could also run SCMI service. The existing SCMI implementation uses a rather flexible shared memory region to communicate commands and their parameters, it still requires a mailbox to actually trigger the action. This patch series provides a Linux mailbox compatible service which uses smc calls to invoke firmware code, for instance taking care of SCMI requests. The actual requests are still communicated using the standard SCMI way of shared memory regions, but a dedicated mailbox hardware IP can be replaced via this new driver. This simple driver uses the architected SMC calling convention to trigger firmware services, also allows for using "HVC" calls to call into hypervisors or firmware layers running in the EL2 exception level. Patch 1 contains the device tree binding documentation, patch 2 introduces the actual mailbox driver. Please note that this driver just provides a generic mailbox mechanism, though this is synchronous and one-way only (triggered by the OS only, without providing an asynchronous way of triggering request from the firmware). And while providing SCMI services was the reason for this exercise, this driver is in no way bound to this use case, but can be used generically where the OS wants to signal a mailbox condition to firmware or a hypervisor. Also the driver is in no way meant to replace any existing firmware interface, but actually to complement existing interfaces. [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi Peng Fan (2): DT: mailbox: add binding doc for the ARM SMC mailbox mailbox: introduce ARM SMC based mailbox .../devicetree/bindings/mailbox/arm-smc.txt| 96 + drivers/mailbox/Kconfig| 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 154 + include/linux/mailbox/arm-smc-mailbox.h| 10 ++ 5 files changed, 269 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode 100644 include/linux/mailbox/arm-smc-mailbox.h -- 2.16.4
[PATCH] firmware: arm_scmi: clock: set rate_discrete
The rate_discrete needs to be assigned to clk->rate_discrete,
then scmi_clk_round_rate could get the value.
Fixes: 5f6c6430e904 ("firmware: arm_scmi: add initial support for clock
protocol")
Signed-off-by: Peng Fan
---
drivers/firmware/arm_scmi/clock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/firmware/arm_scmi/clock.c
b/drivers/firmware/arm_scmi/clock.c
index 30fc04e28431..0a194af92438 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -185,6 +185,8 @@ scmi_clock_describe_rates_get(const struct scmi_handle
*handle, u32 clk_id,
if (rate_discrete)
clk->list.num_rates = tot_rate_cnt;
+ clk->rate_discrete = rate_discrete;
+
err:
scmi_xfer_put(handle, t);
return ret;
--
2.16.4
RE: [PATCH V3 2/4] nvmem: imx: add i.MX8 nvmem driver
Hi Srinivas,
> Subject: Re: [PATCH V3 2/4] nvmem: imx: add i.MX8 nvmem driver
>
>
>
> On 15/05/2019 08:53, Peng Fan wrote:
> > This patch adds i.MX8 nvmem ocotp driver to access fuse via RPC to
> > i.MX8 system controller.
> >
> > Cc: Srinivas Kandagatla
> > Cc: Shawn Guo
> > Cc: Sascha Hauer
> > Cc: Pengutronix Kernel Team
> > Cc: Fabio Estevam
> > Cc: NXP Linux Team
> > Cc: linux-arm-ker...@lists.infradead.org
> > Signed-off-by: Peng Fan
>
> I don't see any dt-binding patches in my list. May be you forgot to add me in
> CC.
>
> Can You please make sure that you add me to the cc of the dt-bindings patch
> so that I can take the driver and dt-bindings together via nvmem tree.
> I will not be able to apply any driver patches without dt-bindings.
Sorry. Forgot to add you in that patch. Resent the whole v3 patchset with
you in To list just now.
Thanks,
Peng.
>
> Thanks,
> srini
> > ---
> >
> > V3:
> > Use imx_sc_msg_misc_fuse_read for req/resp
> > Drop uneccessary check
> > Drop the unnecessary type conversion
> > Minor fixes according to v2 comments
> >
> > V2:
> > Add "scu" or "SCU", Add imx_sc_misc_otp_fuse_read, minor fixes
> >
> > drivers/nvmem/Kconfig | 7 ++
> > drivers/nvmem/Makefile| 2 +
> > drivers/nvmem/imx-ocotp-scu.c | 161
> ++
> > 3 files changed, 170 insertions(+)
> > create mode 100644 drivers/nvmem/imx-ocotp-scu.c
> >
> > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig index
> > 530d570724c9..79afe44195a1 100644
> > --- a/drivers/nvmem/Kconfig
> > +++ b/drivers/nvmem/Kconfig
> > @@ -36,6 +36,13 @@ config NVMEM_IMX_OCOTP
> > This driver can also be built as a module. If so, the module
> > will be called nvmem-imx-ocotp.
> >
> > +config NVMEM_IMX_OCOTP_SCU
> > + tristate "i.MX8 SCU On-Chip OTP Controller support"
> > + depends on IMX_SCU
> > + help
> > + This is a driver for the SCU On-Chip OTP Controller (OCOTP)
> > + available on i.MX8 SoCs.
> > +
> > config NVMEM_LPC18XX_EEPROM
> > tristate "NXP LPC18XX EEPROM Memory Support"
> > depends on ARCH_LPC18XX || COMPILE_TEST diff --git
> > a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile index
> > 2ece8dda..30d653d34e57 100644
> > --- a/drivers/nvmem/Makefile
> > +++ b/drivers/nvmem/Makefile
> > @@ -13,6 +13,8 @@ obj-$(CONFIG_NVMEM_IMX_IIM) +=
> nvmem-imx-iim.o
> > nvmem-imx-iim-y := imx-iim.o
> > obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
> > nvmem-imx-ocotp-y := imx-ocotp.o
> > +obj-$(CONFIG_NVMEM_IMX_OCOTP_SCU) += nvmem-imx-ocotp-scu.o
> > +nvmem-imx-ocotp-scu-y := imx-ocotp-scu.o
> > obj-$(CONFIG_NVMEM_LPC18XX_EEPROM)+=
> nvmem_lpc18xx_eeprom.o
> > nvmem_lpc18xx_eeprom-y := lpc18xx_eeprom.o
> > obj-$(CONFIG_NVMEM_LPC18XX_OTP) += nvmem_lpc18xx_otp.o
> > diff --git a/drivers/nvmem/imx-ocotp-scu.c
> > b/drivers/nvmem/imx-ocotp-scu.c new file mode 100644 index
> > ..d9dc482ecb2f
> > --- /dev/null
> > +++ b/drivers/nvmem/imx-ocotp-scu.c
> > @@ -0,0 +1,161 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * i.MX8 OCOTP fusebox driver
> > + *
> > + * Copyright 2019 NXP
> > + *
> > + * Peng Fan
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +enum ocotp_devtype {
> > + IMX8QXP,
> > +};
> > +
> > +struct ocotp_devtype_data {
> > + int devtype;
> > + int nregs;
> > +};
> > +
> > +struct ocotp_priv {
> > + struct device *dev;
> > + const struct ocotp_devtype_data *data;
> > + struct imx_sc_ipc *nvmem_ipc;
> > +};
> > +
> > +struct imx_sc_msg_misc_fuse_read {
> > + struct imx_sc_rpc_msg hdr;
> > + u32 word;
> > +} __packed;
> > +
> > +static struct ocotp_devtype_data imx8qxp_data = {
> > + .devtype = IMX8QXP,
> > + .nregs = 800,
> > +};
> > +
> > +static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
> > +u32 *val)
> > +{
> > + struct imx_sc_msg_misc_fuse_read msg;
> > + struct imx_sc_rpc_msg *hdr =
> > + int ret;
> > +
> > + hdr->ver = IMX_SC_RPC_VERSION;
> > + hdr->svc = IMX_SC_RPC_S
[PATCH V3 RESEND 2/4] nvmem: imx: add i.MX8 nvmem driver
This patch adds i.MX8 nvmem ocotp driver to access fuse via
RPC to i.MX8 system controller.
Cc: Srinivas Kandagatla
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Peng Fan
---
V3:
Use imx_sc_msg_misc_fuse_read for req/resp
Drop uneccessary check
Drop the unnecessary type conversion
Minor fixes according to v2 comments
V2:
Add "scu" or "SCU", Add imx_sc_misc_otp_fuse_read, minor fixes
drivers/nvmem/Kconfig | 7 ++
drivers/nvmem/Makefile| 2 +
drivers/nvmem/imx-ocotp-scu.c | 161 ++
3 files changed, 170 insertions(+)
create mode 100644 drivers/nvmem/imx-ocotp-scu.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 530d570724c9..79afe44195a1 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -36,6 +36,13 @@ config NVMEM_IMX_OCOTP
This driver can also be built as a module. If so, the module
will be called nvmem-imx-ocotp.
+config NVMEM_IMX_OCOTP_SCU
+ tristate "i.MX8 SCU On-Chip OTP Controller support"
+ depends on IMX_SCU
+ help
+ This is a driver for the SCU On-Chip OTP Controller (OCOTP)
+ available on i.MX8 SoCs.
+
config NVMEM_LPC18XX_EEPROM
tristate "NXP LPC18XX EEPROM Memory Support"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 2ece8dda..30d653d34e57 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -13,6 +13,8 @@ obj-$(CONFIG_NVMEM_IMX_IIM) += nvmem-imx-iim.o
nvmem-imx-iim-y:= imx-iim.o
obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
nvmem-imx-ocotp-y := imx-ocotp.o
+obj-$(CONFIG_NVMEM_IMX_OCOTP_SCU) += nvmem-imx-ocotp-scu.o
+nvmem-imx-ocotp-scu-y := imx-ocotp-scu.o
obj-$(CONFIG_NVMEM_LPC18XX_EEPROM) += nvmem_lpc18xx_eeprom.o
nvmem_lpc18xx_eeprom-y := lpc18xx_eeprom.o
obj-$(CONFIG_NVMEM_LPC18XX_OTP)+= nvmem_lpc18xx_otp.o
diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
new file mode 100644
index ..d9dc482ecb2f
--- /dev/null
+++ b/drivers/nvmem/imx-ocotp-scu.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX8 OCOTP fusebox driver
+ *
+ * Copyright 2019 NXP
+ *
+ * Peng Fan
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum ocotp_devtype {
+ IMX8QXP,
+};
+
+struct ocotp_devtype_data {
+ int devtype;
+ int nregs;
+};
+
+struct ocotp_priv {
+ struct device *dev;
+ const struct ocotp_devtype_data *data;
+ struct imx_sc_ipc *nvmem_ipc;
+};
+
+struct imx_sc_msg_misc_fuse_read {
+ struct imx_sc_rpc_msg hdr;
+ u32 word;
+} __packed;
+
+static struct ocotp_devtype_data imx8qxp_data = {
+ .devtype = IMX8QXP,
+ .nregs = 800,
+};
+
+static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
+u32 *val)
+{
+ struct imx_sc_msg_misc_fuse_read msg;
+ struct imx_sc_rpc_msg *hdr =
+ int ret;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_OTP_FUSE_READ;
+ hdr->size = 2;
+
+ msg.word = word;
+
+ ret = imx_scu_call_rpc(ipc, , true);
+ if (ret)
+ return ret;
+
+ *val = msg.word;
+
+ return 0;
+}
+
+static int imx_scu_ocotp_read(void *context, unsigned int offset,
+ void *val, size_t bytes)
+{
+ struct ocotp_priv *priv = context;
+ u32 count, index, num_bytes;
+ u32 *buf;
+ void *p;
+ int i, ret;
+
+ index = offset >> 2;
+ num_bytes = round_up((offset % 4) + bytes, 4);
+ count = num_bytes >> 2;
+
+ if (count > (priv->data->nregs - index))
+ count = priv->data->nregs - index;
+
+ p = kzalloc(num_bytes, GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ buf = p;
+
+ for (i = index; i < (index + count); i++) {
+ if (priv->data->devtype == IMX8QXP) {
+ if ((i > 271) && (i < 544)) {
+ *buf++ = 0;
+ continue;
+ }
+ }
+
+ ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
+ if (ret) {
+ kfree(p);
+ return ret;
+ }
+ buf++;
+ }
+
+ memcpy(val, (u8 *)p + offset % 4, bytes);
+
+ kfree(p);
+
+ return 0;
+}
+
+static struct nvmem_config imx_scu_ocotp_nvmem_config = {
+ .name = "imx-scu-ocotp",
+ .read_only = true,
+ .word_size = 4,
+ .stride
[PATCH V3 RESEND 3/4] defconfig: arm64: enable i.MX8 SCU octop driver
Build in CONFIG_NVMEM_IMX_OCOTP_SCU. Cc: Catalin Marinas Cc: Will Deacon Cc: Shawn Guo Cc: Andy Gross Cc: Maxime Ripard Cc: Olof Johansson Cc: Jagan Teki Cc: Bjorn Andersson Cc: Leonard Crestez Cc: Marc Gonzalez Cc: Enric Balletbo i Serra Cc: linux-arm-ker...@lists.infradead.org Reviewed-by: Dong Aisheng Signed-off-by: Peng Fan --- V3: No change V2: rename patch title, add review tag arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 979a95c915b6..32b85102b857 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -748,6 +748,7 @@ CONFIG_HISI_PMU=y CONFIG_QCOM_L2_PMU=y CONFIG_QCOM_L3_PMU=y CONFIG_NVMEM_IMX_OCOTP=y +CONFIG_NVMEM_IMX_OCOTP_SCU=y CONFIG_QCOM_QFPROM=y CONFIG_ROCKCHIP_EFUSE=y CONFIG_UNIPHIER_EFUSE=y -- 2.16.4
[PATCH V3 RESEND 1/4] dt-bindings: fsl: scu: add ocotp binding
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller(SCU), the ocotp controller is being controlled
by the SCU, so Linux need use RPC to SCU for ocotp handling. This
patch adds binding doc for i.MX8 SCU OCOTP driver.
Cc: Mark Rutland
Cc: Shawn Guo
Cc: Ulf Hansson
Cc: Stephen Boyd
Cc: Anson Huang
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
Reviewed-by: Dong Aisheng
Signed-off-by: Peng Fan
---
V3:
Add R-b tag
V2:
Move OCOTP to end, add example, add "scu"
.../devicetree/bindings/arm/freescale/fsl,scu.txt | 22 ++
1 file changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 5d7dbabbb784..f378922906f6 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -133,6 +133,18 @@ RTC bindings based on SCU Message Protocol
Required properties:
- compatible: should be "fsl,imx8qxp-sc-rtc";
+OCOTP bindings based on SCU Message Protocol
+
+Required properties:
+- compatible: Should be "fsl,imx8qxp-scu-ocotp"
+- #address-cells: Must be 1. Contains byte index
+- #size-cells: Must be 1. Contains byte length
+
+Optional Child nodes:
+
+- Data cells of ocotp:
+ Detailed bindings are described in bindings/nvmem/nvmem.txt
+
Example (imx8qxp):
-
aliases {
@@ -177,6 +189,16 @@ firmware {
...
};
+ ocotp: imx8qx-ocotp {
+ compatible = "fsl,imx8qxp-scu-ocotp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ fec_mac0: mac@2c4 {
+ reg = <0x2c4 8>;
+ };
+ };
+
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
#power-domain-cells = <1>;
--
2.16.4
[PATCH V3 RESEND 4/4] arm64: dts: imx: add i.MX8QXP ocotp support
Add i.MX8QXP ocotp node
Cc: Rob Herring
Cc: Mark Rutland
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: Anson Huang
Cc: Daniel Baluta
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Dong Aisheng
Signed-off-by: Peng Fan
---
V3:
Add R-b tag
V2:
move address/size-cells below compatible, add "scu"
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 0683ee2a48ae..725d341ee160 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -141,6 +141,12 @@
compatible = "fsl,imx8qxp-iomuxc";
};
+ ocotp: imx8qx-ocotp {
+ compatible = "fsl,imx8qxp-scu-ocotp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd";
#power-domain-cells = <1>;
--
2.16.4
[PATCH] clk: imx: imx8mm: correct audio_pll2_clk to audio_pll2_out
There is no audio_pll2_clk registered, it should be audio_pll2_out.
Cc:
Fixes: ba5625c3e27 ("clk: imx: Add clock driver support for imx8mm")
Signed-off-by: Peng Fan
---
drivers/clk/imx/clk-imx8mm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 1ef8438e3d6d..3a889846a05c 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -325,7 +325,7 @@ static const char *imx8mm_dsi_dbi_sels[] = {"osc_24m",
"sys_pll1_266m", "sys_pll
"sys_pll2_1000m", "sys_pll3_out",
"audio_pll2_out", "video_pll1_out", };
static const char *imx8mm_usdhc3_sels[] = {"osc_24m", "sys_pll1_400m",
"sys_pll1_800m", "sys_pll2_500m",
- "sys_pll3_out", "sys_pll1_266m",
"audio_pll2_clk", "sys_pll1_100m", };
+ "sys_pll3_out", "sys_pll1_266m",
"audio_pll2_out", "sys_pll1_100m", };
static const char *imx8mm_csi1_core_sels[] = {"osc_24m", "sys_pll1_266m",
"sys_pll2_250m", "sys_pll1_800m",
"sys_pll2_1000m", "sys_pll3_out",
"audio_pll2_out", "video_pll1_out", };
@@ -361,11 +361,11 @@ static const char *imx8mm_pdm_sels[] = {"osc_24m",
"sys_pll2_100m", "audio_pll1_
"sys_pll2_1000m", "sys_pll3_out",
"clk_ext3", "audio_pll2_out", };
static const char *imx8mm_vpu_h1_sels[] = {"osc_24m", "vpu_pll_out",
"sys_pll1_800m", "sys_pll2_1000m",
- "audio_pll2_clk", "sys_pll2_125m",
"sys_pll3_clk", "audio_pll1_out", };
+ "audio_pll2_out", "sys_pll2_125m",
"sys_pll3_clk", "audio_pll1_out", };
static const char *imx8mm_dram_core_sels[] = {"dram_pll_out", "dram_alt_root",
};
-static const char *imx8mm_clko1_sels[] = {"osc_24m", "sys_pll1_800m",
"osc_27m", "sys_pll1_200m", "audio_pll2_clk",
+static const char *imx8mm_clko1_sels[] = {"osc_24m", "sys_pll1_800m",
"osc_27m", "sys_pll1_200m", "audio_pll2_out",
"vpu_pll", "sys_pll1_80m", };
static struct clk *clks[IMX8MM_CLK_END];
--
2.16.4
RE: [RFC 1/2] dt-bindings: imx-ocotp: Add fusable-node property
> Subject: Re: [RFC 1/2] dt-bindings: imx-ocotp: Add fusable-node property > > On 20.05.2019 06:06, Peng Fan wrote: > > Introduce fusable-node property for i.MX OCOTP driver. > > The property will only be used by Firmware(eg. U-Boot) to runtime > > disable the nodes. > > > > Take i.MX6ULL for example, there are several parts that only have > > limited modules enabled controlled by OCOTP fuse. It is not flexible > > to provide several dts for the serval parts, instead we could provide > > one device tree and let Firmware to runtime disable the device tree > > nodes for those modules that are disable(fused). > > > > Signed-off-by: Peng Fan > > --- > > > > Currently NXP vendor use U-Boot to set status to disabled for devices > > that could not function, > > > https://source.codeaurora.org/external/imx/uboot-imx/tree/arch/arm/mac > > h-imx/mx6/module_fuse.c?h=imx_v2018.03_4.14.98_2.0.0_ga#n149 > > But this approach is will not work if kernel dts node path changed. > > > > There are two approaches to resolve: > > > > 1. This patch is to add a fusable-node property, and Firmware will parse > > the property and read fuse to decide whether to disable or keeep > enable > > the nodes. > > > > 2. There is another approach is that add nvmem-cells for all nodes that > > could be disabled(fused). Then in each linux driver to use nvmem > > api to detect fused or not, or in linux driver common code to check > > device functionable or not with nvmem API. > > > > > > To make it easy to work, we choose [1] here. Please advise whether it > > is acceptable, because the property is not used by linux driver in > > approach [1]. Or you prefer [2] or please advise if any better solution. > > Couldn't firmware parse nvmem-cells? Even without a full nvmem subsystem > it would be possible for imx-specific code to walk the entire device tree, > parse > nvmem-cells and disable nodes which are disabled by fuse. Firmware could parse nvmem-cells, but there are lots of modules that could be fused. If using nvmem-cells, that means need to add nvmem property for all the modules that could be fused. To make is looks cleaner, so introduced a fusable-node property. Regards, Peng. > > -- > Regards, > Leonard
[RFC 2/2] ARM: dts: imx6ull/z: add fusable-node property
Add fusable-node property for OCOTP
Signed-off-by: Peng Fan
---
arch/arm/boot/dts/imx6ull.dtsi | 7 +++
arch/arm/boot/dts/imx6ulz.dtsi | 6 ++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
index 22e4a307fa59..b616ed6ee4bf 100644
--- a/arch/arm/boot/dts/imx6ull.dtsi
+++ b/arch/arm/boot/dts/imx6ull.dtsi
@@ -32,6 +32,13 @@
{
compatible = "fsl,imx6ull-ocotp", "syscon";
+
+ fusable-node = <0xc 22
+ 0xc 26
+ 0xc 27
+0x10 4
+0x10 5
+ >;
};
{
diff --git a/arch/arm/boot/dts/imx6ulz.dtsi b/arch/arm/boot/dts/imx6ulz.dtsi
index 0b5f1a763567..8edd9008e38b 100644
--- a/arch/arm/boot/dts/imx6ulz.dtsi
+++ b/arch/arm/boot/dts/imx6ulz.dtsi
@@ -19,6 +19,12 @@
};
};
+ {
+ fusable-node = < 0x10 4
+0x10 5
+ >;
+};
+
/delete-node/
/delete-node/
/delete-node/
--
2.16.4
[RFC 1/2] dt-bindings: imx-ocotp: Add fusable-node property
Introduce fusable-node property for i.MX OCOTP driver.
The property will only be used by Firmware(eg. U-Boot) to
runtime disable the nodes.
Take i.MX6ULL for example, there are several parts that only
have limited modules enabled controlled by OCOTP fuse. It is
not flexible to provide several dts for the serval parts, instead
we could provide one device tree and let Firmware to runtime disable
the device tree nodes for those modules that are disable(fused).
Signed-off-by: Peng Fan
---
Currently NXP vendor use U-Boot to set status to disabled for devices
that could not function,
https://source.codeaurora.org/external/imx/uboot-imx/tree/arch/arm/mach-imx/mx6/module_fuse.c?h=imx_v2018.03_4.14.98_2.0.0_ga#n149
But this approach is will not work if kernel dts node path changed.
There are two approaches to resolve:
1. This patch is to add a fusable-node property, and Firmware will parse
the property and read fuse to decide whether to disable or keeep enable
the nodes.
2. There is another approach is that add nvmem-cells for all nodes that
could be disabled(fused). Then in each linux driver to use nvmem
api to detect fused or not, or in linux driver common code to check
device functionable or not with nvmem API.
To make it easy to work, we choose [1] here. Please advise whether
it is acceptable, because the property is not used by linux driver in
approach [1]. Or you prefer [2] or please advise if any better solution.
Thanks.
Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
index 7a999a135e56..e9a998588dbd 100644
--- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
+++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
@@ -21,6 +21,8 @@ Required properties:
Optional properties:
- read-only: disable write access
+- fusable-node: array of phandles with reg base and bit offset, this
+ property is used by Firmware to runtime disable nodes.
Optional Child nodes:
@@ -42,4 +44,7 @@ Example:
tempmon_temp_grade: temp-grade@20 {
reg = <0x20 4>;
};
+
+ fusable-node = < 0x10 4
+0x10 5>;
};
--
2.16.4
[PATCH V3] clk: imx: imx8mm: fix int pll clk gate
To Frac pll, the gate shift is 13, however to Int PLL the gate shift
is 11.
Cc:
Fixes: ba5625c3e27 ("clk: imx: Add clock driver support for imx8mm")
Signed-off-by: Peng Fan
Reviewed-by: Fabio Estevam
Reviewed-by: Jacky Bai
---
V3:
Move Fixes Tag to correct place
V2:
Update commit with Fixes, Add R-b and cc stable
drivers/clk/imx/clk-imx8mm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 1ef8438e3d6d..122a81ab8e48 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -449,12 +449,12 @@ static int __init imx8mm_clocks_init(struct device_node
*ccm_node)
clks[IMX8MM_AUDIO_PLL2_OUT] = imx_clk_gate("audio_pll2_out",
"audio_pll2_bypass", base + 0x14, 13);
clks[IMX8MM_VIDEO_PLL1_OUT] = imx_clk_gate("video_pll1_out",
"video_pll1_bypass", base + 0x28, 13);
clks[IMX8MM_DRAM_PLL_OUT] = imx_clk_gate("dram_pll_out",
"dram_pll_bypass", base + 0x50, 13);
- clks[IMX8MM_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out",
"gpu_pll_bypass", base + 0x64, 13);
- clks[IMX8MM_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out",
"vpu_pll_bypass", base + 0x74, 13);
- clks[IMX8MM_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out",
"arm_pll_bypass", base + 0x84, 13);
- clks[IMX8MM_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out",
"sys_pll1_bypass", base + 0x94, 13);
- clks[IMX8MM_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out",
"sys_pll2_bypass", base + 0x104, 13);
- clks[IMX8MM_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out",
"sys_pll3_bypass", base + 0x114, 13);
+ clks[IMX8MM_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out",
"gpu_pll_bypass", base + 0x64, 11);
+ clks[IMX8MM_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out",
"vpu_pll_bypass", base + 0x74, 11);
+ clks[IMX8MM_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out",
"arm_pll_bypass", base + 0x84, 11);
+ clks[IMX8MM_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out",
"sys_pll1_bypass", base + 0x94, 11);
+ clks[IMX8MM_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out",
"sys_pll2_bypass", base + 0x104, 11);
+ clks[IMX8MM_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out",
"sys_pll3_bypass", base + 0x114, 11);
/* SYS PLL fixed output */
clks[IMX8MM_SYS_PLL1_40M] = imx_clk_fixed_factor("sys_pll1_40m",
"sys_pll1_out", 1, 20);
--
2.16.4
