* Re: [RFC][PATCH 0/2] Add support for using reserved memory for ima buffer pass
From: Prakhar Srivastava @ 2020-05-18 20:16 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, linux-arm-kernel, linux-kernel, linuxppc-dev,
devicetree, linux-integrity, linux-security-module,
catalin.marinas, will, mpe, benh, paulus, frowand.list, zohar,
dmitry.kasatkin, jmorris, serge, pasha.tatashin, allison,
kstewart, takahiro.akashi, tglx, vincenzo.frascino, masahiroy,
james.morse, bhsharma, mbrugger, hsinyi, tao.li, christophe.leroy,
gregkh, nramas, tusharsu, balajib
In-Reply-To: <20200512230509.GA2654@bogus>
On 5/12/20 4:05 PM, Rob Herring wrote:
> On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote:
>> Hi Mark,
>
> Please don't top post.
>
>> This patch set currently only address the Pure DT implementation.
>> EFI and ACPI implementations will be posted in subsequent patchsets.
>>
>> The logs are intended to be carried over the kexec and once read the
>> logs are no longer needed and in prior conversation with James(
>> https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1abb@arm.com/)
>> the apporach of using a chosen node doesn't
>> support the case.
>>
>> The DT entries make the reservation permanent and thus doesnt need kernel
>> segments to be used for this, however using a chosen-node with
>> reserved memory only changes the node information but memory still is
>> reserved via reserved-memory section.
>
> I think Mark's point was whether it needs to be permanent. We don't
> hardcode the initrd address for example.
>
Thankyou for clarifying my misunderstanding, i am modelling this keeping
to the TPM log implementation that uses a reserved memory. I will rev up
the version with chosen-node support.
That will make the memory reservation free after use.
>> On 5/5/20 2:59 AM, Mark Rutland wrote:
>>> Hi Prakhar,
>>>
>>> On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote:
>>>> IMA during kexec(kexec file load) verifies the kernel signature and measures
>
> What's IMAIMA is a LSM attempting to detect if files have been accidentally or
maliciously altered, both remotely and locally, it can also be used
to appraise a file's measurement against a "good" value stored as an
extended attribute, and enforce local file integrity.
IMA also validates and measures the signers of the kernel and initrd
during kexec. The measurements are extended to PCR 10(configurable) and
the logs stored in memory, however once kexec'd the logs are lost. Kexec
is used as secondary boot loader in may use cases and loosing the signer
creates a security hole.
This patch is an implementation to carry over the logs and making it
possible to remotely validate the signers of the kernel and initrd. Such
a support exits only in powerpc.
This patch makes the carry over of logs architecture independent and
puts the complexity in a driver.
Thanks,
Prakhar
>
>>>> the signature of the kernel. The signature in the logs can be used to verfiy the
>>>> authenticity of the kernel. The logs don not get carried over kexec and thus
>>>> remote attesation cannot verify the signature of the running kernel.
>>>>
>>>> Introduce an ABI to carry forward the ima logs over kexec.
>>>> Memory reserved via device tree reservation can be used to store and read
>>>> via the of_* functions.
>>>
>>> This flow needs to work for:
>>>
>>> 1) Pure DT
>>> 2) DT + EFI memory map
>>> 3) ACPI + EFI memory map
>>>
>>> ... and if this is just for transiently passing the log, I don't think
>>> that a reserved memory region is the right thing to use, since they're
>>> supposed to be more permanent.
>>>
>>> This sounds analogous to passing the initrd, and should probably use
>>> properties under the chosen node (which can be used for all three boot
>>> flows above).
>>>
>>> For reference, how big is the IMA log likely to be? Does it need
>>> physically contiguous space?
>>
>> It purely depends on the policy used and the modules/files that are accessed
>> for my local testing over a kexec session the log in
>> about 30KB.
>>
>> Current implementation expects enough contiguous memory to allocated to
>> carry forward the logs. If the log size exceeds the reserved memory the
>> call will fail.
>>
>> Thanks,
>> Prakhar Srivastava
>>>
>>> Thanks,
>>> Mark.
>>>
>>>>
>>>> Reserved memory stores the size(sizeof(size_t)) of the buffer in the starting
>>>> address, followed by the IMA log contents.
>>>>
>>>> Tested on:
>>>> arm64 with Uboot
>>>>
>>>> Prakhar Srivastava (2):
>>>> Add a layer of abstraction to use the memory reserved by device tree
>>>> for ima buffer pass.
>>>> Add support for ima buffer pass using reserved memory for arm64 kexec.
>>>> Update the arch sepcific code path in kexec file load to store the
>>>> ima buffer in the reserved memory. The same reserved memory is read
>>>> on kexec or cold boot.
>>>>
>>>> arch/arm64/Kconfig | 1 +
>>>> arch/arm64/include/asm/ima.h | 22 ++++
>>>> arch/arm64/include/asm/kexec.h | 5 +
>>>> arch/arm64/kernel/Makefile | 1 +
>>>> arch/arm64/kernel/ima_kexec.c | 64 ++++++++++
>>>> arch/arm64/kernel/machine_kexec_file.c | 1 +
>>>> arch/powerpc/include/asm/ima.h | 3 +-
>>>> arch/powerpc/kexec/ima.c | 14 ++-
>>>> drivers/of/Kconfig | 6 +
>>>> drivers/of/Makefile | 1 +
>>>> drivers/of/of_ima.c | 165 +++++++++++++++++++++++++
>>>> include/linux/of.h | 34 +++++
>>>> security/integrity/ima/ima_kexec.c | 15 ++-
>>>> 13 files changed, 325 insertions(+), 7 deletions(-)
>>>> create mode 100644 arch/arm64/include/asm/ima.h
>>>> create mode 100644 arch/arm64/kernel/ima_kexec.c
>>>> create mode 100644 drivers/of/of_ima.c
>>>>
>>>> --
>>>> 2.25.1
>>>>
^ permalink raw reply
* Re: [PATCH v7 5/6] clocksource: Add Low Power STM32 timers driver
From: Daniel Lezcano @ 2020-05-18 20:18 UTC (permalink / raw)
To: Benjamin Gaignard, fabrice.gasnier, lee.jones, robh+dt,
mark.rutland, mcoquelin.stm32, alexandre.torgue, tglx
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel,
Benjamin Gaignard, Pascal Paillet
In-Reply-To: <20200420121620.2099-6-benjamin.gaignard@st.com>
On 20/04/2020 14:16, Benjamin Gaignard wrote:
> From: Benjamin Gaignard <benjamin.gaignard@linaro.org>
>
> Implement clock event driver using low power STM32 timers.
> Low power timer counters running even when CPUs are stopped.
> It could be used as clock event broadcaster to wake up CPUs but not like
> a clocksource because each it rise an interrupt the counter restart from 0.
>
> Low power timers have a 16 bits counter and a prescaler which allow to
> divide the clock per power of 2 to up 128 to target a 32KHz rate.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> Signed-off-by: Pascal Paillet <p.paillet@st.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
[ ... ]
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH v3 0/2] Add Renesas RPC-IF support
From: Sergei Shtylyov @ 2020-05-18 20:31 UTC (permalink / raw)
To: Rob Herring, devicetree
Cc: Philipp Zabel, Mason Yang, linux-spi, Chris Brandt,
linux-mtd@lists.infradead.org
Hello!
Here's a set of 2 patches against Linus' repo. Renesas Reduced Pin Count
Interface (RPC-IF) allows a SPI flash or HyperFlash connected to the SoC
to be accessed via the external address space read mode or the manual mode.
The memory controller driver for RPC-IF registers either SPI or HyperFLash
subdevice, depending on the contents of the device tree subnode; it also
provides the abstract "back end" API that can be used by the "front end"
SPI/MTD drivers to talk to the real hardware...
Based on the original patch by Mason Yang <masonccyang@mxic.com.tw>.
[1/2] dt-bindings: memory: document Renesas RPC-IF bindings
[2/2] memory: add Renesas RPC-IF driver
MBR, Sergei
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: memory: document Renesas RPC-IF bindings
From: Sergei Shtylyov @ 2020-05-18 20:33 UTC (permalink / raw)
To: Rob Herring, devicetree
Cc: Philipp Zabel, Mason Yang, linux-spi, Chris Brandt,
linux-mtd@lists.infradead.org
In-Reply-To: <26faf5e8-26eb-cceb-a500-f0fd64609737@cogentembedded.com>
Renesas Reduced Pin Count Interface (RPC-IF) allows a SPI flash or
HyperFlash connected to the SoC to be accessed via the external address
space read mode or the manual mode.
Document the device tree bindings for the Renesas RPC-IF found in the R-Car
gen3 SoCs.
Based on the original patch by Mason Yang <masonccyang@mxic.com.tw>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 3:
- fixed up the whitespace and added hyphens in the "compatible" prop text, also
removed the comments;
- specified the subnode name as "flash", and used "enum" in the subnode text;
- fixed up the SPDX-License-Identifier: tag.
Changes in version 2:
- rewrote the bindings in YAML.
Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml | 88 ++++++++++
1 file changed, 88 insertions(+)
Index: linux/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
===================================================================
--- /dev/null
+++ linux/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/renesas,rpc-if.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas Reduced Pin Count Interface (RPC-IF)
+
+maintainers:
+ - Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
+
+description: |
+ Renesas RPC-IF allows a SPI flash or HyperFlash connected to the SoC to
+ be accessed via the external address space read mode or the manual mode.
+
+ The flash chip itself should be represented by a subnode of the RPC-IF node.
+ The flash interface is selected based on the "compatible" property of this
+ subnode:
+ - if it contains "jedec,spi-nor", then SPI is used;
+ - if it contains "cfi-flash", then HyperFlash is used.
+
+allOf:
+ - $ref: "/schemas/spi/spi-controller.yaml#"
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r8a77980-rpc-if
+ - renesas,r8a77995-rpc-if
+ - enum:
+ - renesas,rcar-gen3-rpc-if # a generic R-Car gen3 device
+
+ reg:
+ items:
+ - description: RPC-IF registers
+ - description: direct mapping read mode area
+ - description: write buffer area
+
+ reg-names:
+ items:
+ - const: regs
+ - const: dirmap
+ - const: wbuf
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+patternProperties:
+ "flash@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ - enum:
+ - cfi-flash
+ - jedec,spi-nor
+
+examples:
+ - |
+ #include <dt-bindings/clock/renesas-cpg-mssr.h>
+ #include <dt-bindings/power/r8a77995-sysc.h>
+
+ spi@ee200000 {
+ compatible = "renesas,r8a77995-rpc-if", "renesas,rcar-gen3-rpc-if";
+ reg = <0 0xee200000 0 0x200>,
+ <0 0x08000000 0 0x4000000>,
+ <0 0xee208000 0 0x100>;
+ reg-names = "regs", "dirmap", "wbuf";
+ clocks = <&cpg CPG_MOD 917>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 917>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+ };
^ permalink raw reply
* Re: [PATCH v2 03/12] dt-bindings: i2c: dw: Add Baikal-T1 SoC I2C controller
From: Rob Herring @ 2020-05-18 20:33 UTC (permalink / raw)
To: Serge Semin
Cc: Jarkko Nikula, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Paul Burton, Ralf Baechle, Andy Shevchenko, Mika Westerberg,
Wolfram Sang, Frank Rowand, linux-mips, linux-i2c, devicetree,
linux-kernel
In-Reply-To: <20200510095019.20981-4-Sergey.Semin@baikalelectronics.ru>
On Sun, May 10, 2020 at 12:50:09PM +0300, Serge Semin wrote:
> Add the "baikal,bt1-sys-i2c" compatible string to the DW I2C binding and
> make sure the reg property isn't required in this case because the
> controller is embedded into the Baikal-T1 System Controller. The rest of
> the DW APB I2C properties are compatible and can be freely used to describe
> the Baikal-T1 I2C controller dts-node.
Is there not a sub-range of the system controller with the I2C
registers? I'd assume there is, so you can still have 'reg' even if
Linux doesn't use it (currently).
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Rob, I had to remove your acked-by tag because of the changes introduced
> in v2 of the patch.
>
> Changelog v2:
> - Make the reg property being optional if it's Baikal-T1 System I2C DT
> node.
> ---
> .../devicetree/bindings/i2c/snps,designware-i2c.yaml | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> index 8d4e5fccbd1c..579964098eb9 100644
> --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> @@ -21,6 +21,15 @@ allOf:
> properties:
> reg:
> maxItems: 1
> + - if:
> + properties:
> + compatible:
> + not:
> + contains:
> + const: baikal,bt1-sys-i2c
> + then:
> + required:
> + - reg
>
> properties:
> compatible:
> @@ -31,6 +40,8 @@ properties:
> items:
> - const: mscc,ocelot-i2c
> - const: snps,designware-i2c
> + - description: Baikal-T1 SoC System I2C controller
> + const: baikal,bt1-sys-i2c
>
> reg:
> minItems: 1
> @@ -98,7 +109,6 @@ unevaluatedProperties: false
>
> required:
> - compatible
> - - reg
> - "#address-cells"
> - "#size-cells"
> - interrupts
> --
> 2.25.1
>
^ permalink raw reply
* Re: [RFC][PATCH 1/2] Add a layer of abstraction to use the memory reserved by device tree for ima buffer pass.
From: Prakhar Srivastava @ 2020-05-18 20:34 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel, linux-kernel, linuxppc-dev, devicetree,
linux-integrity, linux-security-module, catalin.marinas, will,
mpe, benh, paulus, frowand.list, zohar, dmitry.kasatkin, jmorris,
serge, pasha.tatashin, allison, kstewart, takahiro.akashi, tglx,
vincenzo.frascino, mark.rutland, masahiroy, james.morse, bhsharma,
mbrugger, hsinyi, tao.li, christophe.leroy, gregkh, nramas,
tusharsu, balajib
In-Reply-To: <20200512230954.GB2654@bogus>
On 5/12/20 4:09 PM, Rob Herring wrote:
> On Mon, May 04, 2020 at 01:38:28PM -0700, Prakhar Srivastava wrote:
>> Introduce a device tree layer for to read and store ima buffer
>> from the reserved memory section of a device tree.
>
> But why do I need 'a layer of abstraction'? I don't like them.
>
This is a common path for the all architectures to carry over the
IMA measurement logs. A single layer will avoid any code duplication.
>> Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
>> ---
>> drivers/of/Kconfig | 6 ++
>> drivers/of/Makefile | 1 +
>> drivers/of/of_ima.c | 165 ++++++++++++++++++++++++++++++++++++++++++++
>
> Who are the users of this code and why does it need to be here? Most
> code for specific bindings are not in drivers/of/ but with the user. It
> doesn't sound like there's more than 1 user.
>
Currently the path is exercised by arm64 kexec_file_load path. A slight
restructuring is needed on the powerpc side to use the same code path
and other architectures can follow to add carrying over IMA logs over
kexec with just a few function calls.
I have attempted to bring the code path down to the highest common
layer, however please do suggest if i can move this some where else.
Thanks,
Prakhar
>> include/linux/of.h | 34 +++++++++
>> 4 files changed, 206 insertions(+)
>> create mode 100644 drivers/of/of_ima.c
^ permalink raw reply
* [PATCH v3 2/2] memory: add Renesas RPC-IF driver
From: Sergei Shtylyov @ 2020-05-18 20:34 UTC (permalink / raw)
To: Rob Herring, devicetree
Cc: Philipp Zabel, Mason Yang, linux-spi, Chris Brandt,
linux-mtd@lists.infradead.org
In-Reply-To: <26faf5e8-26eb-cceb-a500-f0fd64609737@cogentembedded.com>
Add the memory driver for Renesas RPC-IF which registers either SPI or
HyperFLash device depending on the contents of the device tree subnode.
It also provides the absract "back end" device APIs that can be used by
the "front end" SPI/MTD drivers to talk to the real hardware.
Based on the original patch by Mason Yang <masonccyang@mxic.com.tw>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- stopped using the read cache to avoid the errata in rpcif_dirmap_read();
- zeroed out 'smcr', 'option', and 'dummy' fileds of the 'struct rpcif' and
reordered the assignments at the start of rpcif_prepare();
- renamed rpcif_io_xfer() to rpcif_manual_xfer();
- switched the lowercase in the hex numbers to the consistent uppercase;
- converted the OCTA #define's into a single bitfield #define and added the
DDRCAL/HS bits to the PHYCNT register bit #define's;
- write to the register PHYCNT.STRTIM(7) instead of PHYCNT.STRTIM(0) in
rpcif_hw_init();
- started flushing the read cache via DRCR after updating CMNCR.BSZ;
- changed the operators updating 'struct rpcif' fields from |= to = for the
command phase setup in rpcif_prepare();
- moved setting rpc->dir before the data phase setup in rpcif_prepare();
- moved pm_runtime_get_sync() call closer to the register setup in
rpcif_manual_xfer();
- added a dummy read from DRCR after a writing to it in rpcif_hw_init() and
rpcif_manual_xfer();
- swapped the 'command' and 'smadr' fields in the 'struct rpcif'.
- fixed up the whitespace in rpcif_manual_xfer() and rpcif_probe();
- changed "MFD" to "core" in the MODULE_DESCRIPTION() invocation.
drivers/memory/Kconfig | 9
drivers/memory/Makefile | 1
drivers/memory/renesas-rpc-if.c | 603 ++++++++++++++++++++++++++++++++++++++++
include/memory/renesas-rpc-if.h | 87 +++++
4 files changed, 700 insertions(+)
Index: linux/drivers/memory/Kconfig
===================================================================
--- linux.orig/drivers/memory/Kconfig
+++ linux/drivers/memory/Kconfig
@@ -163,6 +163,15 @@ config PL353_SMC
This driver is for the ARM PL351/PL353 Static Memory
Controller(SMC) module.
+config RENESAS_RPCIF
+ tristate "Renesas RPC-IF driver"
+ depends on ARCH_RENESAS
+ select REGMAP_MMIO
+ help
+ This supports Renesas R-Car Gen3 RPC-IF which provides either SPI
+ host or HyperFlash. You'll have to select individual components
+ under the corresponding menu.
+
source "drivers/memory/samsung/Kconfig"
source "drivers/memory/tegra/Kconfig"
Index: linux/drivers/memory/Makefile
===================================================================
--- linux.orig/drivers/memory/Makefile
+++ linux/drivers/memory/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_JZ4780_NEMC) += jz4780-nemc
obj-$(CONFIG_MTK_SMI) += mtk-smi.o
obj-$(CONFIG_DA8XX_DDRCTL) += da8xx-ddrctl.o
obj-$(CONFIG_PL353_SMC) += pl353-smc.o
+obj-$(CONFIG_RENESAS_RPCIF) += renesas-rpc-if.o
obj-$(CONFIG_SAMSUNG_MC) += samsung/
obj-$(CONFIG_TEGRA_MC) += tegra/
Index: linux/drivers/memory/renesas-rpc-if.c
===================================================================
--- /dev/null
+++ linux/drivers/memory/renesas-rpc-if.c
@@ -0,0 +1,603 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas RPC-IF driver
+ *
+ * Copyright (C) 2018 ~ 2019 Renesas Solutions Corp.
+ * Copyright (C) 2019 Macronix International Co., Ltd.
+ * Copyright (C) 2019 Cogent Embedded, Inc.
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+
+#include <memory/renesas-rpc-if.h>
+
+#define RPCIF_CMNCR 0x0000 /* R/W */
+#define RPCIF_CMNCR_MD BIT(31)
+#define RPCIF_CMNCR_SFDE BIT(24) /* undocumented but must be set */
+#define RPCIF_CMNCR_MOIIO3(val) (((val) & 0x3) << 22)
+#define RPCIF_CMNCR_MOIIO2(val) (((val) & 0x3) << 20)
+#define RPCIF_CMNCR_MOIIO1(val) (((val) & 0x3) << 18)
+#define RPCIF_CMNCR_MOIIO0(val) (((val) & 0x3) << 16)
+#define RPCIF_CMNCR_MOIIO_HIZ (RPCIF_CMNCR_MOIIO0(3) | \
+ RPCIF_CMNCR_MOIIO1(3) | \
+ RPCIF_CMNCR_MOIIO2(3) | RPCIF_CMNCR_MOIIO3(3))
+#define RPCIF_CMNCR_IO3FV(val) (((val) & 0x3) << 14) /* undocumented */
+#define RPCIF_CMNCR_IO2FV(val) (((val) & 0x3) << 12) /* undocumented */
+#define RPCIF_CMNCR_IO0FV(val) (((val) & 0x3) << 8)
+#define RPCIF_CMNCR_IOFV_HIZ (RPCIF_CMNCR_IO0FV(3) | RPCIF_CMNCR_IO2FV(3) | \
+ RPCIF_CMNCR_IO3FV(3))
+#define RPCIF_CMNCR_BSZ(val) (((val) & 0x3) << 0)
+
+#define RPCIF_SSLDR 0x0004 /* R/W */
+#define RPCIF_SSLDR_SPNDL(d) (((d) & 0x7) << 16)
+#define RPCIF_SSLDR_SLNDL(d) (((d) & 0x7) << 8)
+#define RPCIF_SSLDR_SCKDL(d) (((d) & 0x7) << 0)
+
+#define RPCIF_DRCR 0x000C /* R/W */
+#define RPCIF_DRCR_SSLN BIT(24)
+#define RPCIF_DRCR_RBURST(v) ((((v) - 1) & 0x1F) << 16)
+#define RPCIF_DRCR_RCF BIT(9)
+#define RPCIF_DRCR_RBE BIT(8)
+#define RPCIF_DRCR_SSLE BIT(0)
+
+#define RPCIF_DRCMR 0x0010 /* R/W */
+#define RPCIF_DRCMR_CMD(c) (((c) & 0xFF) << 16)
+#define RPCIF_DRCMR_OCMD(c) (((c) & 0xFF) << 0)
+
+#define RPCIF_DREAR 0x0014 /* R/W */
+#define RPCIF_DREAR_EAV(c) (((c) & 0xF) << 16)
+#define RPCIF_DREAR_EAC(c) (((c) & 0x7) << 0)
+
+#define RPCIF_DROPR 0x0018 /* R/W */
+
+#define RPCIF_DRENR 0x001C /* R/W */
+#define RPCIF_DRENR_CDB(o) (u32)((((o) & 0x3) << 30))
+#define RPCIF_DRENR_OCDB(o) (((o) & 0x3) << 28)
+#define RPCIF_DRENR_ADB(o) (((o) & 0x3) << 24)
+#define RPCIF_DRENR_OPDB(o) (((o) & 0x3) << 20)
+#define RPCIF_DRENR_DRDB(o) (((o) & 0x3) << 16)
+#define RPCIF_DRENR_DME BIT(15)
+#define RPCIF_DRENR_CDE BIT(14)
+#define RPCIF_DRENR_OCDE BIT(12)
+#define RPCIF_DRENR_ADE(v) (((v) & 0xF) << 8)
+#define RPCIF_DRENR_OPDE(v) (((v) & 0xF) << 4)
+
+#define RPCIF_SMCR 0x0020 /* R/W */
+#define RPCIF_SMCR_SSLKP BIT(8)
+#define RPCIF_SMCR_SPIRE BIT(2)
+#define RPCIF_SMCR_SPIWE BIT(1)
+#define RPCIF_SMCR_SPIE BIT(0)
+
+#define RPCIF_SMCMR 0x0024 /* R/W */
+#define RPCIF_SMCMR_CMD(c) (((c) & 0xFF) << 16)
+#define RPCIF_SMCMR_OCMD(c) (((c) & 0xFF) << 0)
+
+#define RPCIF_SMADR 0x0028 /* R/W */
+
+#define RPCIF_SMOPR 0x002C /* R/W */
+#define RPCIF_SMOPR_OPD3(o) (((o) & 0xFF) << 24)
+#define RPCIF_SMOPR_OPD2(o) (((o) & 0xFF) << 16)
+#define RPCIF_SMOPR_OPD1(o) (((o) & 0xFF) << 8)
+#define RPCIF_SMOPR_OPD0(o) (((o) & 0xFF) << 0)
+
+#define RPCIF_SMENR 0x0030 /* R/W */
+#define RPCIF_SMENR_CDB(o) (((o) & 0x3) << 30)
+#define RPCIF_SMENR_OCDB(o) (((o) & 0x3) << 28)
+#define RPCIF_SMENR_ADB(o) (((o) & 0x3) << 24)
+#define RPCIF_SMENR_OPDB(o) (((o) & 0x3) << 20)
+#define RPCIF_SMENR_SPIDB(o) (((o) & 0x3) << 16)
+#define RPCIF_SMENR_DME BIT(15)
+#define RPCIF_SMENR_CDE BIT(14)
+#define RPCIF_SMENR_OCDE BIT(12)
+#define RPCIF_SMENR_ADE(v) (((v) & 0xF) << 8)
+#define RPCIF_SMENR_OPDE(v) (((v) & 0xF) << 4)
+#define RPCIF_SMENR_SPIDE(v) (((v) & 0xF) << 0)
+
+#define RPCIF_SMRDR0 0x0038 /* R */
+#define RPCIF_SMRDR1 0x003C /* R */
+#define RPCIF_SMWDR0 0x0040 /* W */
+#define RPCIF_SMWDR1 0x0044 /* W */
+
+#define RPCIF_CMNSR 0x0048 /* R */
+#define RPCIF_CMNSR_SSLF BIT(1)
+#define RPCIF_CMNSR_TEND BIT(0)
+
+#define RPCIF_DRDMCR 0x0058 /* R/W */
+#define RPCIF_DMDMCR_DMCYC(v) ((((v) - 1) & 0x1F) << 0)
+
+#define RPCIF_DRDRENR 0x005C /* R/W */
+#define RPCIF_DRDRENR_HYPE(v) (((v) & 0x7) << 12)
+#define RPCIF_DRDRENR_ADDRE BIT(8)
+#define RPCIF_DRDRENR_OPDRE BIT(4)
+#define RPCIF_DRDRENR_DRDRE BIT(0)
+
+#define RPCIF_SMDMCR 0x0060 /* R/W */
+#define RPCIF_SMDMCR_DMCYC(v) ((((v) - 1) & 0x1F) << 0)
+
+#define RPCIF_SMDRENR 0x0064 /* R/W */
+#define RPCIF_SMDRENR_HYPE(v) (((v) & 0x7) << 12)
+#define RPCIF_SMDRENR_ADDRE BIT(8)
+#define RPCIF_SMDRENR_OPDRE BIT(4)
+#define RPCIF_SMDRENR_SPIDRE BIT(0)
+
+#define RPCIF_PHYCNT 0x007C /* R/W */
+#define RPCIF_PHYCNT_CAL BIT(31)
+#define RPCIF_PHYCNT_OCTA(v) (((v) & 0x3) << 22)
+#define RPCIF_PHYCNT_EXDS BIT(21)
+#define RPCIF_PHYCNT_OCT BIT(20)
+#define RPCIF_PHYCNT_DDRCAL BIT(19)
+#define RPCIF_PHYCNT_HS BIT(18)
+#define RPCIF_PHYCNT_STRTIM(v) (((v) & 0x7) << 15)
+#define RPCIF_PHYCNT_WBUF2 BIT(4)
+#define RPCIF_PHYCNT_WBUF BIT(2)
+#define RPCIF_PHYCNT_PHYMEM(v) (((v) & 0x3) << 0)
+
+#define RPCIF_PHYOFFSET1 0x0080 /* R/W */
+#define RPCIF_PHYOFFSET1_DDRTMG(v) (((v) & 0x3) << 28)
+
+#define RPCIF_PHYOFFSET2 0x0084 /* R/W */
+#define RPCIF_PHYOFFSET2_OCTTMG(v) (((v) & 0x7) << 8)
+
+#define RPCIF_PHYINT 0x0088 /* R/W */
+#define RPCIF_PHYINT_WPVAL BIT(1)
+
+#define RPCIF_DIRMAP_SIZE 0x4000000
+
+static const struct regmap_range rpcif_volatile_ranges[] = {
+ regmap_reg_range(RPCIF_SMRDR0, RPCIF_SMRDR1),
+ regmap_reg_range(RPCIF_SMWDR0, RPCIF_SMWDR1),
+ regmap_reg_range(RPCIF_CMNSR, RPCIF_CMNSR),
+};
+
+static const struct regmap_access_table rpcif_volatile_table = {
+ .yes_ranges = rpcif_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(rpcif_volatile_ranges),
+};
+
+static const struct regmap_config rpcif_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .fast_io = true,
+ .max_register = RPCIF_PHYINT,
+ .volatile_table = &rpcif_volatile_table,
+};
+
+int rpcif_sw_init(struct rpcif *rpc, struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct resource *res;
+ void __iomem *base;
+
+ rpc->dev = dev;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ rpc->regmap = devm_regmap_init_mmio(&pdev->dev, base,
+ &rpcif_regmap_config);
+ if (IS_ERR(rpc->regmap)) {
+ dev_err(&pdev->dev,
+ "failed to init regmap for rpcif, error %ld\n",
+ PTR_ERR(rpc->regmap));
+ return PTR_ERR(rpc->regmap);
+ }
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dirmap");
+ rpc->size = resource_size(res);
+ rpc->dirmap = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(rpc->dirmap))
+ rpc->dirmap = NULL;
+
+ rpc->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+ if (IS_ERR(rpc->rstc))
+ return PTR_ERR(rpc->rstc);
+
+ return 0;
+}
+EXPORT_SYMBOL(rpcif_sw_init);
+
+void rpcif_enable_rpm(struct rpcif *rpc)
+{
+ pm_runtime_enable(rpc->dev);
+}
+EXPORT_SYMBOL(rpcif_enable_rpm);
+
+void rpcif_disable_rpm(struct rpcif *rpc)
+{
+ pm_runtime_put_sync(rpc->dev);
+}
+EXPORT_SYMBOL(rpcif_disable_rpm);
+
+void rpcif_hw_init(struct rpcif *rpc, bool hyperflash)
+{
+ u32 dummy;
+
+ pm_runtime_get_sync(rpc->dev);
+
+ /*
+ * NOTE: The 0x260 are undocumented bits, but they must be set.
+ * RPCIF_PHYCNT_STRTIM is strobe timing adjustment bits,
+ * 0x0 : the delay is biggest,
+ * 0x1 : the delay is 2nd biggest,
+ * On H3 ES1.x, the value should be 0, while on others,
+ * the value should be 7.
+ */
+ regmap_write(rpc->regmap, RPCIF_PHYCNT, RPCIF_PHYCNT_STRTIM(7) |
+ RPCIF_PHYCNT_PHYMEM(hyperflash ? 3 : 0) | 0x260);
+
+ /*
+ * NOTE: The 0x1511144 are undocumented bits, but they must be set
+ * for RPCIF_PHYOFFSET1.
+ * The 0x31 are undocumented bits, but they must be set
+ * for RPCIF_PHYOFFSET2.
+ */
+ regmap_write(rpc->regmap, RPCIF_PHYOFFSET1, 0x1511144 |
+ RPCIF_PHYOFFSET1_DDRTMG(3));
+ regmap_write(rpc->regmap, RPCIF_PHYOFFSET2, 0x31 |
+ RPCIF_PHYOFFSET2_OCTTMG(4));
+
+ if (hyperflash)
+ regmap_update_bits(rpc->regmap, RPCIF_PHYINT,
+ RPCIF_PHYINT_WPVAL, 0);
+
+ regmap_write(rpc->regmap, RPCIF_CMNCR, RPCIF_CMNCR_SFDE |
+ RPCIF_CMNCR_MOIIO_HIZ | RPCIF_CMNCR_IOFV_HIZ |
+ RPCIF_CMNCR_BSZ(hyperflash ? 1 : 0));
+ /* Set RCF after BSZ update */
+ regmap_write(rpc->regmap, RPCIF_DRCR, RPCIF_DRCR_RCF);
+ /* Dummy read according to spec */
+ regmap_read(rpc->regmap, RPCIF_DRCR, &dummy);
+ regmap_write(rpc->regmap, RPCIF_SSLDR, RPCIF_SSLDR_SPNDL(7) |
+ RPCIF_SSLDR_SLNDL(7) | RPCIF_SSLDR_SCKDL(7));
+
+ pm_runtime_put(rpc->dev);
+
+ rpc->bus_size = hyperflash ? 2 : 1;
+}
+EXPORT_SYMBOL(rpcif_hw_init);
+
+static int wait_msg_xfer_end(struct rpcif *rpc)
+{
+ u32 sts;
+
+ return regmap_read_poll_timeout(rpc->regmap, RPCIF_CMNSR, sts,
+ sts & RPCIF_CMNSR_TEND, 0,
+ USEC_PER_SEC);
+}
+
+static u8 rpcif_bits_set(struct rpcif *rpc, u32 nbytes)
+{
+ if (rpc->bus_size == 2)
+ nbytes /= 2;
+ nbytes = clamp(nbytes, 1U, 4U);
+ return GENMASK(3, 4 - nbytes);
+}
+
+static u8 rpcif_bit_size(u8 buswidth)
+{
+ return buswidth > 4 ? 2 : ilog2(buswidth);
+}
+
+void rpcif_prepare(struct rpcif *rpc, const struct rpcif_op *op, u64 *offs,
+ size_t *len)
+{
+ rpc->smcr = 0;
+ rpc->smadr = 0;
+ rpc->enable = 0;
+ rpc->command = 0;
+ rpc->option = 0;
+ rpc->dummy = 0;
+ rpc->ddr = 0;
+ rpc->xferlen = 0;
+
+ if (op->cmd.buswidth) {
+ rpc->enable = RPCIF_SMENR_CDE |
+ RPCIF_SMENR_CDB(rpcif_bit_size(op->cmd.buswidth));
+ rpc->command = RPCIF_SMCMR_CMD(op->cmd.opcode);
+ if (op->cmd.ddr)
+ rpc->ddr = RPCIF_SMDRENR_HYPE(0x5);
+ }
+ if (op->ocmd.buswidth) {
+ rpc->enable |= RPCIF_SMENR_OCDE |
+ RPCIF_SMENR_OCDB(rpcif_bit_size(op->ocmd.buswidth));
+ rpc->command |= RPCIF_SMCMR_OCMD(op->ocmd.opcode);
+ }
+
+ if (op->addr.buswidth) {
+ rpc->enable |=
+ RPCIF_SMENR_ADB(rpcif_bit_size(op->addr.buswidth));
+ if (op->addr.nbytes == 4)
+ rpc->enable |= RPCIF_SMENR_ADE(0xF);
+ else
+ rpc->enable |= RPCIF_SMENR_ADE(GENMASK(
+ 2, 3 - op->addr.nbytes));
+ if (op->addr.ddr)
+ rpc->ddr |= RPCIF_SMDRENR_ADDRE;
+
+ if (offs && len)
+ rpc->smadr = *offs;
+ else
+ rpc->smadr = op->addr.val;
+ }
+
+ if (op->dummy.buswidth) {
+ rpc->enable |= RPCIF_SMENR_DME;
+ rpc->dummy = RPCIF_SMDMCR_DMCYC(op->dummy.ncycles /
+ op->dummy.buswidth);
+ }
+
+ if (op->option.buswidth) {
+ rpc->enable |= RPCIF_SMENR_OPDE(
+ rpcif_bits_set(rpc, op->option.nbytes)) |
+ RPCIF_SMENR_OPDB(rpcif_bit_size(op->option.buswidth));
+ if (op->option.ddr)
+ rpc->ddr |= RPCIF_SMDRENR_OPDRE;
+ rpc->option = op->option.val;
+ }
+
+ rpc->dir = op->data.dir;
+ if (op->data.buswidth) {
+ u32 nbytes;
+
+ rpc->buffer = op->data.buf.in;
+ switch (op->data.dir) {
+ case RPCIF_DATA_IN:
+ rpc->smcr = RPCIF_SMCR_SPIRE;
+ break;
+ case RPCIF_DATA_OUT:
+ rpc->smcr = RPCIF_SMCR_SPIWE;
+ break;
+ default:
+ break;
+ }
+ if (op->data.ddr)
+ rpc->ddr |= RPCIF_SMDRENR_SPIDRE;
+
+ if (offs && len)
+ nbytes = *len;
+ else
+ nbytes = op->data.nbytes;
+ rpc->xferlen = nbytes;
+
+ rpc->enable |= RPCIF_SMENR_SPIDE(rpcif_bits_set(rpc, nbytes)) |
+ RPCIF_SMENR_SPIDB(rpcif_bit_size(op->data.buswidth));
+ }
+}
+EXPORT_SYMBOL(rpcif_prepare);
+
+int rpcif_manual_xfer(struct rpcif *rpc)
+{
+ u32 smenr, smcr, pos = 0, max = 4;
+ int ret = 0;
+
+ if (rpc->bus_size == 2)
+ max = 8;
+
+ pm_runtime_get_sync(rpc->dev);
+
+ regmap_update_bits(rpc->regmap, RPCIF_PHYCNT,
+ RPCIF_PHYCNT_CAL, RPCIF_PHYCNT_CAL);
+ regmap_update_bits(rpc->regmap, RPCIF_CMNCR,
+ RPCIF_CMNCR_MD, RPCIF_CMNCR_MD);
+ regmap_write(rpc->regmap, RPCIF_SMCMR, rpc->command);
+ regmap_write(rpc->regmap, RPCIF_SMOPR, rpc->option);
+ regmap_write(rpc->regmap, RPCIF_SMDMCR, rpc->dummy);
+ regmap_write(rpc->regmap, RPCIF_SMDRENR, rpc->ddr);
+ smenr = rpc->enable;
+
+ switch (rpc->dir) {
+ case RPCIF_DATA_OUT:
+ while (pos < rpc->xferlen) {
+ u32 nbytes = rpc->xferlen - pos;
+ u32 data[2];
+
+ smcr = rpc->smcr | RPCIF_SMCR_SPIE;
+ if (nbytes > max) {
+ nbytes = max;
+ smcr |= RPCIF_SMCR_SSLKP;
+ }
+
+ memcpy(data, rpc->buffer + pos, nbytes);
+ if (nbytes > 4) {
+ regmap_write(rpc->regmap, RPCIF_SMWDR1,
+ data[0]);
+ regmap_write(rpc->regmap, RPCIF_SMWDR0,
+ data[1]);
+ } else if (nbytes > 2) {
+ regmap_write(rpc->regmap, RPCIF_SMWDR0,
+ data[0]);
+ } else {
+ regmap_write(rpc->regmap, RPCIF_SMWDR0,
+ data[0] << 16);
+ }
+
+ regmap_write(rpc->regmap, RPCIF_SMADR,
+ rpc->smadr + pos);
+ regmap_write(rpc->regmap, RPCIF_SMENR, smenr);
+ regmap_write(rpc->regmap, RPCIF_SMCR, smcr);
+ ret = wait_msg_xfer_end(rpc);
+ if (ret)
+ goto err_out;
+
+ pos += nbytes;
+ smenr = rpc->enable &
+ ~RPCIF_SMENR_CDE & ~RPCIF_SMENR_ADE(0xF);
+ }
+ break;
+ case RPCIF_DATA_IN:
+ /*
+ * RPC-IF spoils the data for the commands without an address
+ * phase (like RDID) in the manual mode, so we'll have to work
+ * around this issue by using the external address space read
+ * mode instead.
+ */
+ if (!(smenr & RPCIF_SMENR_ADE(0xF)) && rpc->dirmap) {
+ u32 dummy;
+
+ regmap_update_bits(rpc->regmap, RPCIF_CMNCR,
+ RPCIF_CMNCR_MD, 0);
+ regmap_write(rpc->regmap, RPCIF_DRCR,
+ RPCIF_DRCR_RBURST(32) | RPCIF_DRCR_RBE);
+ regmap_write(rpc->regmap, RPCIF_DRCMR, rpc->command);
+ regmap_write(rpc->regmap, RPCIF_DREAR,
+ RPCIF_DREAR_EAC(1));
+ regmap_write(rpc->regmap, RPCIF_DROPR, rpc->option);
+ regmap_write(rpc->regmap, RPCIF_DRENR,
+ smenr & ~RPCIF_SMENR_SPIDE(0xF));
+ regmap_write(rpc->regmap, RPCIF_DRDMCR, rpc->dummy);
+ regmap_write(rpc->regmap, RPCIF_DRDRENR, rpc->ddr);
+ memcpy_fromio(rpc->buffer, rpc->dirmap, rpc->xferlen);
+ regmap_write(rpc->regmap, RPCIF_DRCR, RPCIF_DRCR_RCF);
+ /* Dummy read according to spec */
+ regmap_read(rpc->regmap, RPCIF_DRCR, &dummy);
+ break;
+ }
+ while (pos < rpc->xferlen) {
+ u32 nbytes = rpc->xferlen - pos;
+ u32 data[2];
+
+ if (nbytes > max)
+ nbytes = max;
+
+ regmap_write(rpc->regmap, RPCIF_SMADR,
+ rpc->smadr + pos);
+ regmap_write(rpc->regmap, RPCIF_SMENR, smenr);
+ regmap_write(rpc->regmap, RPCIF_SMCR,
+ rpc->smcr | RPCIF_SMCR_SPIE);
+ ret = wait_msg_xfer_end(rpc);
+ if (ret)
+ goto err_out;
+
+ if (nbytes > 4) {
+ regmap_read(rpc->regmap, RPCIF_SMRDR1,
+ &data[0]);
+ regmap_read(rpc->regmap, RPCIF_SMRDR0,
+ &data[1]);
+ } else if (nbytes > 2) {
+ regmap_read(rpc->regmap, RPCIF_SMRDR0,
+ &data[0]);
+ } else {
+ regmap_read(rpc->regmap, RPCIF_SMRDR0,
+ &data[0]);
+ data[0] >>= 16;
+ }
+ memcpy(rpc->buffer + pos, data, nbytes);
+
+ pos += nbytes;
+ }
+ break;
+ default:
+ regmap_write(rpc->regmap, RPCIF_SMENR, rpc->enable);
+ regmap_write(rpc->regmap, RPCIF_SMCR,
+ rpc->smcr | RPCIF_SMCR_SPIE);
+ ret = wait_msg_xfer_end(rpc);
+ if (ret)
+ goto err_out;
+ }
+
+exit:
+ pm_runtime_put(rpc->dev);
+ return ret;
+
+err_out:
+ ret = reset_control_reset(rpc->rstc);
+ rpcif_hw_init(rpc, rpc->bus_size == 2);
+ goto exit;
+}
+EXPORT_SYMBOL(rpcif_manual_xfer);
+
+ssize_t rpcif_dirmap_read(struct rpcif *rpc, u64 offs, size_t len, void *buf)
+{
+ loff_t from = offs & (RPCIF_DIRMAP_SIZE - 1);
+ size_t size = RPCIF_DIRMAP_SIZE - from;
+
+ if (len > size)
+ len = size;
+
+ pm_runtime_get_sync(rpc->dev);
+
+ regmap_update_bits(rpc->regmap, RPCIF_CMNCR, RPCIF_CMNCR_MD, 0);
+ regmap_write(rpc->regmap, RPCIF_DRCR, 0);
+ regmap_write(rpc->regmap, RPCIF_DRCMR, rpc->command);
+ regmap_write(rpc->regmap, RPCIF_DREAR,
+ RPCIF_DREAR_EAV(offs >> 25) | RPCIF_DREAR_EAC(1));
+ regmap_write(rpc->regmap, RPCIF_DROPR, rpc->option);
+ regmap_write(rpc->regmap, RPCIF_DRENR,
+ rpc->enable & ~RPCIF_SMENR_SPIDE(0xF));
+ regmap_write(rpc->regmap, RPCIF_DRDMCR, rpc->dummy);
+ regmap_write(rpc->regmap, RPCIF_DRDRENR, rpc->ddr);
+
+ memcpy_fromio(buf, rpc->dirmap + from, len);
+
+ pm_runtime_put(rpc->dev);
+
+ return len;
+}
+EXPORT_SYMBOL(rpcif_dirmap_read);
+
+static int rpcif_probe(struct platform_device *pdev)
+{
+ struct platform_device *vdev;
+ struct device_node *flash;
+ const char *name;
+
+ flash = of_get_next_child(pdev->dev.of_node, NULL);
+ if (!flash) {
+ dev_warn(&pdev->dev, "no flash node found\n");
+ return -ENODEV;
+ }
+
+ if (of_device_is_compatible(flash, "jedec,spi-nor")) {
+ name = "rpc-if-spi";
+ } else if (of_device_is_compatible(flash, "cfi-flash")) {
+ name = "rpc-if-hyperflash";
+ } else {
+ dev_warn(&pdev->dev, "unknown flash type\n");
+ return -ENODEV;
+ }
+
+ vdev = platform_device_alloc(name, pdev->id);
+ if (!vdev)
+ return -ENOMEM;
+ vdev->dev.parent = &pdev->dev;
+ platform_set_drvdata(pdev, vdev);
+ return platform_device_add(vdev);
+}
+
+static int rpcif_remove(struct platform_device *pdev)
+{
+ struct platform_device *vdev = platform_get_drvdata(pdev);
+
+ platform_device_unregister(vdev);
+
+ return 0;
+}
+
+static const struct of_device_id rpcif_of_match[] = {
+ { .compatible = "renesas,rcar-gen3-rpc-if", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, rpcif_of_match);
+
+static struct platform_driver rpcif_driver = {
+ .probe = rpcif_probe,
+ .remove = rpcif_remove,
+ .driver = {
+ .name = "rpc-if",
+ .of_match_table = rpcif_of_match,
+ },
+};
+module_platform_driver(rpcif_driver);
+
+MODULE_DESCRIPTION("Renesas RPC-IF core driver");
+MODULE_LICENSE("GPL v2");
Index: linux/include/memory/renesas-rpc-if.h
===================================================================
--- /dev/null
+++ linux/include/memory/renesas-rpc-if.h
@@ -0,0 +1,87 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * R-Car Gen3 RPC-IF driver
+ *
+ * Copyright (C) 2018 ~ 2019 Renesas Solutions Corp.
+ * Copyright (C) 2019 Macronix International Co., Ltd.
+ * Copyright (C) 2019 Cogent Embedded, Inc.
+ */
+
+#ifndef __RENESAS_RPC_IF_H
+#define __RENESAS_RPC_IF_H
+
+#include <linux/types.h>
+
+enum rpcif_data_dir {
+ RPCIF_NO_DATA,
+ RPCIF_DATA_IN,
+ RPCIF_DATA_OUT,
+};
+
+struct rpcif_op {
+ struct {
+ u8 buswidth;
+ u8 opcode;
+ bool ddr;
+ } cmd, ocmd;
+
+ struct {
+ u8 nbytes;
+ u8 buswidth;
+ bool ddr;
+ u64 val;
+ } addr;
+
+ struct {
+ u8 ncycles;
+ u8 buswidth;
+ } dummy;
+
+ struct {
+ u8 nbytes;
+ u8 buswidth;
+ bool ddr;
+ u32 val;
+ } option;
+
+ struct {
+ u8 buswidth;
+ unsigned int nbytes;
+ enum rpcif_data_dir dir;
+ bool ddr;
+ union {
+ void *in;
+ const void *out;
+ } buf;
+ } data;
+};
+
+struct rpcif {
+ struct device *dev;
+ void __iomem *dirmap;
+ struct regmap *regmap;
+ struct reset_control *rstc;
+ size_t size;
+ enum rpcif_data_dir dir;
+ u8 bus_size;
+ void *buffer;
+ u32 xferlen;
+ u32 smcr;
+ u32 smadr;
+ u32 command; /* DRCMR or SMCMR */
+ u32 option; /* DROPR or SMOPR */
+ u32 enable; /* DRENR or SMENR */
+ u32 dummy; /* DRDMCR or SMDMCR */
+ u32 ddr; /* DRDRENR or SMDRENR */
+};
+
+int rpcif_sw_init(struct rpcif *rpc, struct device *dev);
+void rpcif_hw_init(struct rpcif *rpc, bool hyperflash);
+void rpcif_enable_rpm(struct rpcif *rpc);
+void rpcif_disable_rpm(struct rpcif *rpc);
+void rpcif_prepare(struct rpcif *rpc, const struct rpcif_op *op, u64 *offs,
+ size_t *len);
+int rpcif_manual_xfer(struct rpcif *rpc);
+ssize_t rpcif_dirmap_read(struct rpcif *rpc, u64 offs, size_t len, void *buf);
+
+#endif // __RENESAS_RPC_IF_H
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon: Add Baikal-T1 PVT sensor binding
From: Rob Herring @ 2020-05-18 20:34 UTC (permalink / raw)
To: Serge Semin
Cc: Jonathan Corbet, Paul Burton, Guenter Roeck, Maxim Kaurkin,
linux-hwmon, Serge Semin, linux-kernel, Ralf Baechle,
Alexey Malahov, linux-mips, Jean Delvare, Arnd Bergmann,
devicetree, Thomas Bogendoerfer, Rob Herring
In-Reply-To: <20200510103211.27905-2-Sergey.Semin@baikalelectronics.ru>
On Sun, 10 May 2020 13:32:10 +0300, Serge Semin wrote:
> Baikal-T1 SoC is equipped with an embedded process, voltage and
> temperature sensor to monitor the chip internal environment like
> temperature, supply voltage and transistors performance.
>
> This bindings describes the external Baikal-T1 PVT control interfaces
> like MMIO registers space, interrupt request number and clocks source.
> These are then used by the corresponding hwmon device driver to
> implement the sysfs files-based access to the sensors functionality.
>
> Co-developed-by: Maxim Kaurkin <maxim.kaurkin@baikalelectronics.ru>
> Signed-off-by: Maxim Kaurkin <maxim.kaurkin@baikalelectronics.ru>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Changelog v2:
> - Lowercase the node-name in the example.
> - Add dual-license header.
> - Don't use a multi-arg clock phandle reference in the examples dt-binding
> property. Thus reundant include pre-processor statement can be removed.
> - Replace "additionalProperties: false" property with
> "unevaluatedProperties: false".
> - Discard label definition from the example.
> - Align settings of the "#thermal-sensor-cells" property with two spaces
> ahead of the property line start.
> ---
> .../bindings/hwmon/baikal,bt1-pvt.yaml | 95 +++++++++++++++++++
> 1 file changed, 95 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: watchdog: Convert DW WDT binding to DT schema
From: Rob Herring @ 2020-05-18 20:35 UTC (permalink / raw)
To: Serge Semin
Cc: Alexey Malahov, Ralf Baechle, linux-watchdog, linux-mips,
Guenter Roeck, devicetree, Thomas Bogendoerfer, Philipp Zabel,
linux-kernel, Serge Semin, Rob Herring, Paul Burton,
Wim Van Sebroeck, Arnd Bergmann
In-Reply-To: <20200510105807.880-2-Sergey.Semin@baikalelectronics.ru>
On Sun, 10 May 2020 13:58:01 +0300, Serge Semin wrote:
> Modern device tree bindings are supposed to be created as YAML-files
> in accordance with dt-schema. This commit replaces the DW Watchdog
> legacy bare text bindings with YAML file. As before the binding states
> that the corresponding dts node is supposed to have a registers
> range, a watchdog timer references clock source, optional reset line and
> pre-timeout interrupt.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Changelog v2:
> - Rearrange SoBs.
> - Discard BE copyright header.
> - Replace "additionalProperties: false" with "unevaluatedProperties: false"
> property.
> - Discard interrupts property from the required properties list.
> - Remove a label definition from the binding example.
> - Move the asynchronous APB3 clock support into a dedicated patch.
> ---
> .../devicetree/bindings/watchdog/dw_wdt.txt | 24 ---------
> .../bindings/watchdog/snps,dw-wdt.yaml | 50 +++++++++++++++++++
> 2 files changed, 50 insertions(+), 24 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/watchdog/dw_wdt.txt
> create mode 100644 Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: watchdog: dw-wdt: Support devices with asynch clocks
From: Rob Herring @ 2020-05-18 20:36 UTC (permalink / raw)
To: Serge Semin
Cc: Alexey Malahov, linux-watchdog, Wim Van Sebroeck, Guenter Roeck,
Arnd Bergmann, Philipp Zabel, linux-mips, Paul Burton, devicetree,
linux-kernel, Rob Herring, Ralf Baechle, Serge Semin,
Thomas Bogendoerfer
In-Reply-To: <20200510105807.880-3-Sergey.Semin@baikalelectronics.ru>
On Sun, 10 May 2020 13:58:02 +0300, Serge Semin wrote:
> DW Watchdog IP core can be synthesised with asynchronous timer/APB
> clocks support (WDT_ASYNC_CLK_MODE_ENABLE == 1). In this case
> a separate clock signal is supposed to be used to feed watchdog timer
> and APB interface of the device. Lets along with the watchdog timer
> reference clock expect to have the optional APB3 bus interface clock
> sepcified in a DW WDT dt node.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Changelog v2:
> - It's a new patch unpinned from the previous one.
> ---
> .../devicetree/bindings/watchdog/snps,dw-wdt.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: watchdog: dw-wdt: Add watchdog TOPs array property
From: Rob Herring @ 2020-05-18 20:40 UTC (permalink / raw)
To: Serge Semin
Cc: Wim Van Sebroeck, Guenter Roeck, Serge Semin, Alexey Malahov,
Thomas Bogendoerfer, Paul Burton, Ralf Baechle, Arnd Bergmann,
Philipp Zabel, linux-mips, linux-watchdog, devicetree,
linux-kernel
In-Reply-To: <20200510105807.880-4-Sergey.Semin@baikalelectronics.ru>
On Sun, May 10, 2020 at 01:58:03PM +0300, Serge Semin wrote:
> In case if DW Watchdog IP core is built with WDT_USE_FIX_TOP == false,
> a custom timeout periods are used to preset the timer counter. In
> this case that periods should be specified in a new "snps,watchdog-tops"
> property of the DW watchdog dts node.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Rob, I had to remove your Reviewed-by tag, since the patch needed
> to be updated a bit (see changelog).
>
> Changelog v2:
> - Rearrange SoBs.
> - Move $ref to the root level of the "snps,watchdog-tops" property
> so does the constraints.
> - Add default TOP values array.
> - Discard the label definition from the new bindings example.
> ---
> .../bindings/watchdog/snps,dw-wdt.yaml | 33 +++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
> index 5bf6dc6377f3..cc741fb5a685 100644
> --- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
> +++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
> @@ -39,6 +39,24 @@ properties:
> description: Phandle to the DW Watchdog reset lane
> maxItems: 1
>
> + snps,watchdog-tops:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + DW APB Watchdog custom timer intervals - Timeout Period ranges (TOPs).
> + Each TOP is a number loaded into the watchdog counter at the moment of
> + the timer restart. The counter decrementing happens each tick of the
> + reference clock. Therefore the TOPs array is equivalent to an array of
> + the timer expiration intervals supported by the DW APB Watchdog. Note
> + DW APB Watchdog IP-core might be synthesized with fixed TOP values,
> + in which case this property is unnecessary with default TOPs utilized.
> + default: [0x0001000 0x0002000 0x0004000 0x0008000
> + 0x0010000 0x0020000 0x0040000 0x0080000
> + 0x0100000 0x0200000 0x0400000 0x0800000
> + 0x1000000 0x2000000 0x4000000 0x8000000]
> + items:
> + minItems: 16
> + maxItems: 16
Drop 'items' and move these up a level. That may have given you some
issues, but I made some fixes recently.
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* Re: [PATCH v14 1/2] dt-bindings: proximity: provide vcnl3020 device tree binding document
From: Rob Herring @ 2020-05-18 20:41 UTC (permalink / raw)
To: Ivan Mikhaylov
Cc: linux-kernel, Hartmut Knaack, linux-iio, Peter Meerwald-Stadler,
devicetree, Lars-Peter Clausen, Mark Rutland, Andy Shevchenko,
Rob Herring, Jonathan Cameron
In-Reply-To: <20200510184537.10335-2-i.mikhaylov@yadro.com>
On Sun, 10 May 2020 21:45:36 +0300, Ivan Mikhaylov wrote:
> Mostly standard i2c driver with some additional led-current option
> for vcnl3020.
>
> Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
> ---
> .../iio/proximity/vishay,vcnl3020.yaml | 62 +++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] docs/devicetree/i2c: brcm,bcm2835: fix node id in example
From: Rob Herring @ 2020-05-18 20:43 UTC (permalink / raw)
To: l4stpr0gr4m
Cc: trivial, linux-i2c, linux-arm-kernel, nsaenzjulienne,
linux-kernel, devicetree, linux-rpi-kernel
In-Reply-To: <1589140701-7516-1-git-send-email-l4stpr0gr4m@gmail.com>
On Mon, 11 May 2020 04:58:21 +0900, wrote:
> From: Kangmin Park <l4stpr0gr4m@gmail.com>
>
> This is a trivial patch to fix node id to match the reg in example.
>
> Signed-off-by: Kangmin Park <l4stpr0gr4m@gmail.com>
> ---
> Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pinctrl: Add bindings for mscc,ocelot-sgpio
From: Lars Povlsen @ 2020-05-18 20:49 UTC (permalink / raw)
To: Linus Walleij
Cc: Lars Povlsen, SoC Team, Rob Herring,
Microchip Linux Driver Support,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Linux ARM, linux-kernel@vger.kernel.org,
Alexandre Belloni
In-Reply-To: <CACRpkdZa7OM3bqB+zRprEQ3M4m9hG3uPCoYxrdH_O=oxD8zi8Q@mail.gmail.com>
Linus Walleij writes:
> On Wed, May 13, 2020 at 4:11 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
>
>> This adds DT bindings for the Microsemi SGPIO controller, bindings
>> mscc,ocelot-sgpio and mscc,luton-sgpio.
>>
>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>
>> + microchip,sgpio-ports:
>> + description: This is a 32-bit bitmask, configuring whether a
>> + particular port in the controller is enabled or not. This allows
>> + unused ports to be removed from the bitstream and reduce latency.
>> + $ref: "/schemas/types.yaml#/definitions/uint32"
>
> I don't know about this.
>
> You are saying this pin controller can have up to 32 GPIO "ports"
> (also known as banks).
>
> Why can't you just represent each such port as a separate GPIO
> node:
>
> pinctrl@nnn {
> gpio@0 {
> ....
> };
> gpio@1 {
> ....
> };
> ....
> gpio@31 {
> ....
> };
> };
>
> Then if some of them are unused just set it to status = "disabled";
>
> This also makes your Linux driver simpler because each GPIO port
> just becomes a set of 32bit registers and you can use
> select GPIO_GENERIC and bgpio_init() and save a whole
> slew of standard stock code.
>
Linus, thank you for your input.
The controller handles an array of 32*n signals, where n >= 1 && n <=
4.
The problem with the above approach is that the ports are disabled
*port*-wise - so they remove all (upto) 4 bits. That would be across the
banks.
You could of course have the "implied" semantics that a disabled port at
any bit position disabled all (bit positions for the same port).
But I don't know if this would be easier to understand, DT-wise.
What do you think...?
> Yours,
> Linus Walleij
--
Lars Povlsen,
Microchip
^ permalink raw reply
* Re: [PATCH v2 18/20] mips: csrc-r4k: Decrease r4k-clocksource rating if CPU_FREQ enabled
From: Serge Semin @ 2020-05-18 20:57 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Serge Semin, Alexey Malahov, Paul Burton, Ralf Baechle,
Greg Kroah-Hartman, Arnd Bergmann, Rob Herring, linux-pm,
devicetree, Vincenzo Frascino, Thomas Gleixner, linux-mips,
linux-kernel
In-Reply-To: <20200518163206.GA17800@alpha.franken.de>
On Mon, May 18, 2020 at 06:32:06PM +0200, Thomas Bogendoerfer wrote:
> On Mon, May 18, 2020 at 04:48:20PM +0300, Serge Semin wrote:
> > On Fri, May 15, 2020 at 11:06:47PM +0200, Thomas Bogendoerfer wrote:
> > > On Fri, May 15, 2020 at 10:48:27AM +0300, Serge Semin wrote:
> > > > Thomas,
> > > > Could you take a look at my comment below so I could proceed with the
> > > > patchset v3 development?
> > >
> > > I can't help, but using r4k clocksource with changing frequency is
> > > probaly only usefull as a random generator. So IMHO the only two
> > > options are disabling it or implement what arch/x86/kernel/tsc.c does.
> > >
> > > Thomas.
> >
> > Thomas, could you proceed with the rest of the patches review?
> > ├─>[PATCH v2 16/20] bus: cdmm: Add MIPS R5 arch support
> > ├─>[PATCH v2 15/20] mips: cdmm: Add mti,mips-cdmm dtb node support
>
> both are not my call, but look ok to me.
Can I add your Reviewed-by tag there then?
>
> > ├─>[PATCH v2 13/20] mips: early_printk_8250: Use offset-sized IO-mem accessors
>
> that's broken. A reg shift of 2 doesn't mean we could use 32bit access
> to the registers on other platforms. As I don't think adding some ifdefery
> makes things nicer, just implement the your prom_putchar in board code.
I thought about that initially, but then I decided to alter the generic
early_printk_8250 code instead. My version of prom_putchar() would be almost
the same as one implemented in the early_printk_8250 module except minor
modification of replacing readb/writeb methods with readl/writel. So I didn't
want to duplicate the code, but wanted to provide a general way to fix the
problem potentially also for another platforms.
Since you don't like this fix alternatively I'd suggest to add the reg_width
parameter passed to the setup_8250_early_printk_port() method like this:
-setup_8250_early_printk_port(unsigned long base, unsigned int reg_shift,
- unsigned int timeout)
+setup_8250_early_printk_port(unsigned long base, unsigned int reg_shift,
+ unsigned int reg_width, unsigned int timeout)
By reg_width parameter we could determine the actual width of the register:
static inline u8 serial_in(int offset)
{
- return readb(serial8250_base + (offset << serial8250_reg_shift));
+ u8 ret = 0xFF;
+
+ offset <<= serial8250_reg_shift;
+ switch (serial8250_reg_width) {
+ case 1:
+ ret = readb(serial8250_base + offset);
+ break;
+ case 2:
+ ret = readw(serial8250_base + offset);
+ break;
+ case 4:
+ ret = readl(serial8250_base + offset);
+ break;
+ default:
+ break;
+ }
+
+ return ret;
}
The similar modification will be implemented for serial_out(). I'll also modify
the currently available setup_8250_early_printk_port() calls so they would pass
the reg_with as 1 to activate the normal readb/writeb IO methods.
What do you think about this?
>
> > ├─>[PATCH v2 12/20] mips: MAAR: Add XPA mode support
>
> looks ok so far.
Can I add your Reviewed-by tag there then?
>
> > ├─>[PATCH v2 10/20] mips: Add CONFIG/CONFIG6/Cause reg fields macro
>
> that is fine
Can I add your Reviewed-by tag there then?
>
> > └─>[PATCH v2 09/20] mips: Add CP0 Write Merge config support
>
> this is IMHO a dangerous change. Enabling write merging for any
> CPU supporting it might triggers bugs. Do it in your board bringup
> code and at the moment I don't see a reason for the rest of that
> patch.
Let's at least leave the mm_config() implementation but without the write-merge
enabling by default. Providing features availability macro
cpu_has_mm_sysad/cpu_has_mm_full and c0 config fields
MIPS_CPU_MM_SYSAD/MIPS_CPU_MM_FULL defined will be useful in the platform-specific
Write-Merge enable/disable procedure. For instance, in the my prom_init() method
I could use them to implement a code pattern like:
+ if (cpu_has_mm_full) {
+ unsigned int config0 = read_c0_config();
+ config0 = (config0 & ~MIPS_CONF_MM) | MIPS_CONF_MM_FULL;
+ write_c0_config(config0);
+ }
By doing so I can manually enable/disable the MM feature in the
cpu-feature-overrides.h. Without that I'd have to locally define these macro,
which isn't good seeing they are in fact generic and can be useful for other
platforms with SYSAD and FULL MM feature available. What do you think?
-Sergey
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH 2/2] spi: Add Baikal-T1 System Boot SPI Controller driver
From: Serge Semin @ 2020-05-18 21:17 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Ramil Zaripov, Alexey Malahov, Thomas Bogendoerfer,
Paul Burton, Ralf Baechle, Lee Jones, Miquel Raynal,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, John Garry,
Chuanhong Guo, Andy Shevchenko, Eddie James, Geert Uytterhoeven,
Chris Packham, Tomer Maimon, Masahisa Kojima, Krzysztof Kozlowski,
Florian Fainelli, Jassi Brar, linux-kernel, linux-spi
In-Reply-To: <20200518151946.GH8699@sirena.org.uk>
On Mon, May 18, 2020 at 04:19:47PM +0100, Mark Brown wrote:
> On Mon, May 18, 2020 at 03:05:42AM +0300, Serge Semin wrote:
> > On Mon, May 11, 2020 at 10:25:06PM +0100, Mark Brown wrote:
>
> > > Yes, some flags should work here - the issue was that at least some
> > > controllers may end up trying to do multiple SPI operations for one
> > > spi-mem thing which will break if the chip select doesn't get changed to
> > > correspond with what's going on.
>
> > Ok. New SPI flag it is then. It will be something like this:
> > + #define SPI_CONTROLLER_FLASH_SS BIT(6)
>
> I'd rather use CS than SS (it's more common in the code).
Ok.
>
> > So, what do you think?
>
> Should be fine, controllers that have an issue implementing just
> shouldn't set the flag.
Yes, exactly what I intended.
>
> > > > > It's not clear to me that this hardware actually supports spi_mem in
> > > > > hardware?
>
> > > > SPI-mem operations are implemented by means of the EEPROM-read and Tx-only
> > > > modes of the controller.
>
> > > Sure, but those seem like normal SPI-level things rather than cases
> > > where the hardware understands that it has a flash attached and is doing
> > > flash specific things.
>
> > No, hardware can't detect whether the flash is attached. This must be defined by
> > the platform, like based on the DT sub-nodes.
>
> This isn't about autodetection, it's about the abstraction level the
> hardware is operating on - some hardware is able to generate flash
> operations by itself (possibly with some help programming the opcodes
> that are needed by a given flash), some hardware just works at the
> bytestream level.
>
> > > A very common case for this stuff is that
> > > controllers have acceleration blocks for read and fall back on normal
> > > SPI for writes and erases, that sounds like what's going on here.
> >
> > Well, yeah, they do provide some acceleration. EEPROM-read provides automatic
> > write-cmd-dummy-data-then-read operations. But in this case the only thing we
> > have to push into the SPI Tx FIFO is command and dummy bytes. The read operation
>
> So it's a write then read but you have to program the write each time?
Here is what we need to do to perform the EEPROM-read operation:
1) Enable EEPROM-read mode.
2) Initialize a corresponding registers with a number of SPI transfer words
(with bits-per-word taken into account) to read.
3) Push opcode + address + dummy bytes into the Tx FIFO. When it's done and
the Tx FIFO is empty, the controller will proceed with read operations by
pushing zeros (or ones, don't remember what level it's by default) to MOSI
and pulling data from MISO into the RX FIFO.
4) Keep up with getting data from the Rx FIFO so one wouldn't get overflown.
Regarding programming write each time. Well, it's up to the driver implementation.
If opcode, address, dummy bytes and number of words to read are the same as before,
then re-programming isn't required.
-Sergey
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: memory: document Renesas RPC-IF bindings
From: Geert Uytterhoeven @ 2020-05-18 21:23 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Chris Brandt, Mason Yang, linux-mtd@lists.infradead.org,
Philipp Zabel, linux-spi
In-Reply-To: <f998fe6c-c586-17cb-9343-30460ce0bf9d@cogentembedded.com>
Hi Sergei,
On Mon, May 18, 2020 at 10:33 PM Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Renesas Reduced Pin Count Interface (RPC-IF) allows a SPI flash or
> HyperFlash connected to the SoC to be accessed via the external address
> space read mode or the manual mode.
>
> Document the device tree bindings for the Renesas RPC-IF found in the R-Car
> gen3 SoCs.
>
> Based on the original patch by Mason Yang <masonccyang@mxic.com.tw>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Thanks for your patch!
> --- /dev/null
> +++ linux/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
> @@ -0,0 +1,88 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memory-controllers/renesas,rpc-if.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas Reduced Pin Count Interface (RPC-IF)
> +
> +maintainers:
> + - Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> +
> +description: |
> + Renesas RPC-IF allows a SPI flash or HyperFlash connected to the SoC to
> + be accessed via the external address space read mode or the manual mode.
> +
> + The flash chip itself should be represented by a subnode of the RPC-IF node.
> + The flash interface is selected based on the "compatible" property of this
> + subnode:
> + - if it contains "jedec,spi-nor", then SPI is used;
> + - if it contains "cfi-flash", then HyperFlash is used.
> +
> +allOf:
> + - $ref: "/schemas/spi/spi-controller.yaml#"
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - renesas,r8a77980-rpc-if
Usually we add a comment with the SoC name, e.g. "# R-Car V3H"
> + - renesas,r8a77995-rpc-if
> + - enum:
> + - renesas,rcar-gen3-rpc-if # a generic R-Car gen3 device
No need for an enum, just use "- const: renesas,rcar-gen3-rpc-if".
> +examples:
> + - |
> + #include <dt-bindings/clock/renesas-cpg-mssr.h>
> + #include <dt-bindings/power/r8a77995-sysc.h>
> +
> + spi@ee200000 {
> + compatible = "renesas,r8a77995-rpc-if", "renesas,rcar-gen3-rpc-if";
> + reg = <0 0xee200000 0 0x200>,
> + <0 0x08000000 0 0x4000000>,
> + <0 0xee208000 0 0x100>;
Examples are built with #{address,size}-cells = <1>, so please drop
the zeroes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: spi: Add Baikal-T1 System Boot SPI Controller binding
From: Serge Semin @ 2020-05-18 21:27 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Mark Brown, Ramil Zaripov, Alexey Malahov,
Thomas Bogendoerfer, Paul Burton, Ralf Baechle, John Garry,
Chuanhong Guo, Tomer Maimon, Lee Jones, Miquel Raynal,
Arnd Bergmann, linux-mips, linux-spi, devicetree, linux-kernel
In-Reply-To: <20200518152659.GA2525@bogus>
On Mon, May 18, 2020 at 09:26:59AM -0600, Rob Herring wrote:
> On Fri, May 08, 2020 at 12:36:20PM +0300, Serge Semin wrote:
> > Baikal-T1 Boot SPI is a part of the SoC System Controller and is
> > responsible for the system bootup from an external SPI flash. It's a DW
> > APB SSI-based SPI-controller with no interrupts, no DMA, with just one
> > native chip-select available and a single reference clock. Since Baikal-T1
> > SoC is normally booted up from an external SPI flash this SPI controller
> > in most of the cases is supposed to be connected to a single SPI-nor
> > flash. Additionally in order to provide a transparent from CPU point of
> > view initial code execution procedure the system designers created an IP
> > block which physically maps the SPI flash found at CS0 to a memory region.
> >
> > Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> > Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Paul Burton <paulburton@kernel.org>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: John Garry <john.garry@huawei.com>
> > Cc: Chuanhong Guo <gch981213@gmail.com>
> > Cc: Tomer Maimon <tmaimon77@gmail.com>
> > Cc: Lee Jones <lee.jones@linaro.org>
> > Cc: Miquel Raynal <miquel.raynal@bootlin.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: linux-mips@vger.kernel.org
> > Cc: linux-spi@vger.kernel.org
> > ---
> > .../bindings/spi/baikal,bt1-sys-ssi.yaml | 100 ++++++++++++++++++
> > 1 file changed, 100 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml b/Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml
> > new file mode 100644
> > index 000000000000..d9d3257d78f4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml
> > @@ -0,0 +1,100 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/spi/baikal,bt1-sys-ssi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Baikal-T1 System Boot SSI Controller
> > +
> > +description: |
> > + Baikal-T1 System Controller includes a Boot SPI Controller, which is
> > + responsible for loading chip bootup code from an external SPI flash. In order
> > + to do this transparently from CPU point of view there is a dedicated IP block
> > + mapping the 16MB flash to a dedicated MMIO range. The controller is based on
> > + the DW APB SSI IP-core but equipped with very limited resources: no IRQ,
> > + no DMA, a single native CS being necessarily connected to a 16MB SPI flash
> > + (otherwise the system won't bootup from the flash), internal Tx/Rx FIFO of
> > + just 8 bytes depth. Access to DW APB SSI controller registers is mutually
> > + exclusive from normal MMIO interface and from physically mapped SPI Flash
> > + memory. So either one or another way of using the controller functionality
> > + can be enabled at a time.
> > +
> > +maintainers:
> > + - Serge Semin <fancer.lancer@gmail.com>
> > +
> > +allOf:
> > + - $ref: spi-controller.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: baikal,bt1-sys-ssi
> > +
> > + reg:
> > + items:
> > + - description: Baikal-T1 Boot Controller configuration registers
> > + - description: Physically mapped SPI flash ROM found at CS0
> > +
> > + reg-names:
> > + items:
> > + - const: config
> > + - const: map
> > +
> > + clocks:
> > + description: SPI Controller reference clock source
>
> Can drop this.
Ok.
>
> > + maxItems: 1
> > +
> > + clock-names:
> > + items:
> > + - const: ssi_clk
> > +
> > + num-cs:
> > + const: 1
> > +
> > +patternProperties:
> > + "^.*@[0-9a-f]+":
> > + type: object
> > + properties:
> > + reg:
> > + minimum: 0
> > + maximum: 0
> > +
> > + spi-rx-bus-width:
> > + const: 1
> > +
> > + spi-tx-bus-width:
> > + const: 1
>
> What's the point of these 2 properties if they aren't required?
Yes, they are optional, but this is a constraint on the bus-width parameters.
DW APB SSI provides a single laned Tx and Rx.
>
> > +
> > +unevaluatedProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
>
> > + - "#address-cells"
> > + - "#size-cells"
>
> These 2 are required by spi-controller.yaml, so you can drop here.
Yes, "#address-cells" is required, but "#size-cells" isn't. Is this supposed to
be like that?
-Sergey
>
> > + - clocks
> > +
> > +examples:
> > + - |
> > + spi@1f040000 {
> > + compatible = "baikal,bt1-sys-ssi";
> > + reg = <0x1f040000 0x1000>,
> > + <0x1c000000 0x1000000>;
> > + reg-names = "config", "map";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + clocks = <&ccu_sys>;
> > + clock-names = "ssi_clk";
> > +
> > + boot_flash: flash@0 {
> > + compatible = "jedec,spi-nor";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + reg = <0>;
> > +
> > + spi-max-frequency = <25000000>;
> > + };
> > + };
> > +...
> > --
> > 2.25.1
> >
^ permalink raw reply
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Rob Herring @ 2020-05-18 21:27 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ricardo Cañuelo, kernel, devicetree, linux-arm-kernel,
geert+renesas, xuwei5
In-Reply-To: <20200514152239.GG5955@pendragon.ideasonboard.com>
On Thu, May 14, 2020 at 06:22:39PM +0300, Laurent Pinchart wrote:
> Hi Ricardo,
>
> On Thu, May 14, 2020 at 11:36:17AM +0200, Ricardo Cañuelo wrote:
> > Hi Laurent, thanks for the thorough review. Some comments below:
> >
> > On jue 14-05-2020 04:54:12, Laurent Pinchart wrote:
> > > > +description: |
> > > > + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> > > > + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> > > > + space conversion, S/PDIF, CEC and HDCP. They support RGB input
> > > > + interface.
> > >
> > > I would write the last sentence as "The transmitter input is parallel
> > > RGB or YUV data." as YUV is also supported.
> >
> > Ok.
> >
> > > > + adi,input-colorspace:
> > > > + description: Input color space.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/string
> > > > + - enum: [ rgb, yuv422, yuv444 ]
> > >
> > > Isn't string implied ? Can't you write
> > >
> > > adi,input-colorspace:
> > > description: Input color space.
> > > enum: [ rgb, yuv422, yuv444 ]
> >
> > example-schema.yaml says that
> >
> > Vendor specific properties have slightly different schema
> > requirements than common properties. They must have at least a type
> > definition and 'description'.
> >
> > However, dt_binding_check doesn't seem to enforce this rule for string
> > properties, and I saw a couple of vendor-specific string properties in
> > other bindings that don't define the type either, so I'm going to follow
> > your suggestion but only for string properties, the rest need a type
> > definition.
>
> I'll defer to Rob to tell the law here :-)
Yes, if you have a string with defined values, then a type isn't needed.
That only applies to strings as numeric values need a size.
>
> > I noticed I can remove the "allOf" keywords from these too.
Yes, that's a recent change. Both forms still work.
> > > > + adi,embedded-sync:
> > > > + description:
> > > > + The input uses synchronization signals embedded in the data
> > > > + stream (similar to BT.656). Defaults to 0 (separate H/V
> > > > + synchronization signals).
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - enum: [ 0, 1 ]
> > > > + - default: 0
> > >
> > > This be a boolean property (it is read as a bool by the driver, the
> > > property being absent means false, the property being present means
> > > true).
> >
> > You're completely right.
> >
> > > > + ports:
> > > > + description:
> > > > + The ADV7511(W)/13 has two video ports and one audio port. This node
> > > > + models their connections as documented in
> > > > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > > > + Documentation/devicetree/bindings/graph.txt
> > > > + type: object
> > > > + properties:
> > > > + port@0:
> > > > + description: Video port for the RGB, YUV or DSI input.
> > >
> > > s/RGB, YUV or DSI/RGB or YUV/
> >
> > Ok.
> >
> > > > +if:
> > > > + not:
> > > > + properties:
> > > > + adi,input-colorspace:
> > > > + contains:
> > > > + enum: [ rgb, yuv444 ]
> > > > + adi,input-clock:
> > > > + contains:
> > > > + const: 1x
> > >
> > > As both properties take a single value, I think you can omit
> > > "contains:".
> >
> > I think it's required here, removing it makes the test fail.
>
> I thought the following could work:
>
> if:
> not:
> properties:
> adi,input-colorspace:
> enum: [ rgb, yuv444 ]
> adi,input-clock:
> items:
> - const: 1x
>
> But no big deal, contains: is ok too.
In theory the above should work. However, this is probably a case where
we don't fix-up the properties. If you look at the DT yaml encoding,
everything is an array (as dtc doesn't know). For schemas, the tooling
expands scalars to arrays.
Rob
^ permalink raw reply
* Re: [PATCH v2 03/12] dt-bindings: i2c: dw: Add Baikal-T1 SoC I2C controller
From: Serge Semin @ 2020-05-18 21:39 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Jarkko Nikula, Alexey Malahov, Thomas Bogendoerfer,
Paul Burton, Ralf Baechle, Andy Shevchenko, Mika Westerberg,
Wolfram Sang, Frank Rowand, linux-mips, linux-i2c, devicetree,
linux-kernel
In-Reply-To: <20200518203319.GA14243@bogus>
On Mon, May 18, 2020 at 02:33:19PM -0600, Rob Herring wrote:
> On Sun, May 10, 2020 at 12:50:09PM +0300, Serge Semin wrote:
> > Add the "baikal,bt1-sys-i2c" compatible string to the DW I2C binding and
> > make sure the reg property isn't required in this case because the
> > controller is embedded into the Baikal-T1 System Controller. The rest of
> > the DW APB I2C properties are compatible and can be freely used to describe
> > the Baikal-T1 I2C controller dts-node.
>
> Is there not a sub-range of the system controller with the I2C
> registers? I'd assume there is, so you can still have 'reg' even if
> Linux doesn't use it (currently).
Yes, there is a range. It's just three access registers. Is it wrong to make the
reg property being optional in this case since it can be accessed over syscon
regmap? Do you suggest to get back the reg property being required for our
device?
-Sergey
>
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Paul Burton <paulburton@kernel.org>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Cc: Wolfram Sang <wsa@the-dreams.de>
> > Cc: Frank Rowand <frowand.list@gmail.com>
> > Cc: linux-mips@vger.kernel.org
> >
> > ---
> >
> > Rob, I had to remove your acked-by tag because of the changes introduced
> > in v2 of the patch.
> >
> > Changelog v2:
> > - Make the reg property being optional if it's Baikal-T1 System I2C DT
> > node.
> > ---
> > .../devicetree/bindings/i2c/snps,designware-i2c.yaml | 12 +++++++++++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > index 8d4e5fccbd1c..579964098eb9 100644
> > --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > @@ -21,6 +21,15 @@ allOf:
> > properties:
> > reg:
> > maxItems: 1
> > + - if:
> > + properties:
> > + compatible:
> > + not:
> > + contains:
> > + const: baikal,bt1-sys-i2c
> > + then:
> > + required:
> > + - reg
> >
> > properties:
> > compatible:
> > @@ -31,6 +40,8 @@ properties:
> > items:
> > - const: mscc,ocelot-i2c
> > - const: snps,designware-i2c
> > + - description: Baikal-T1 SoC System I2C controller
> > + const: baikal,bt1-sys-i2c
> >
> > reg:
> > minItems: 1
> > @@ -98,7 +109,6 @@ unevaluatedProperties: false
> >
> > required:
> > - compatible
> > - - reg
> > - "#address-cells"
> > - "#size-cells"
> > - interrupts
> > --
> > 2.25.1
> >
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: watchdog: dw-wdt: Add watchdog TOPs array property
From: Serge Semin @ 2020-05-18 21:42 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Wim Van Sebroeck, Guenter Roeck, Alexey Malahov,
Thomas Bogendoerfer, Paul Burton, Ralf Baechle, Arnd Bergmann,
Philipp Zabel, linux-mips, linux-watchdog, devicetree,
linux-kernel
In-Reply-To: <20200518204037.GA4909@bogus>
On Mon, May 18, 2020 at 02:40:37PM -0600, Rob Herring wrote:
> On Sun, May 10, 2020 at 01:58:03PM +0300, Serge Semin wrote:
> > In case if DW Watchdog IP core is built with WDT_USE_FIX_TOP == false,
> > a custom timeout periods are used to preset the timer counter. In
> > this case that periods should be specified in a new "snps,watchdog-tops"
> > property of the DW watchdog dts node.
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Paul Burton <paulburton@kernel.org>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Philipp Zabel <p.zabel@pengutronix.de>
> > Cc: linux-mips@vger.kernel.org
> >
> > ---
> >
> > Rob, I had to remove your Reviewed-by tag, since the patch needed
> > to be updated a bit (see changelog).
> >
> > Changelog v2:
> > - Rearrange SoBs.
> > - Move $ref to the root level of the "snps,watchdog-tops" property
> > so does the constraints.
> > - Add default TOP values array.
> > - Discard the label definition from the new bindings example.
> > ---
> > .../bindings/watchdog/snps,dw-wdt.yaml | 33 +++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
> > index 5bf6dc6377f3..cc741fb5a685 100644
> > --- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
> > +++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
> > @@ -39,6 +39,24 @@ properties:
> > description: Phandle to the DW Watchdog reset lane
> > maxItems: 1
> >
> > + snps,watchdog-tops:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > + description: |
> > + DW APB Watchdog custom timer intervals - Timeout Period ranges (TOPs).
> > + Each TOP is a number loaded into the watchdog counter at the moment of
> > + the timer restart. The counter decrementing happens each tick of the
> > + reference clock. Therefore the TOPs array is equivalent to an array of
> > + the timer expiration intervals supported by the DW APB Watchdog. Note
> > + DW APB Watchdog IP-core might be synthesized with fixed TOP values,
> > + in which case this property is unnecessary with default TOPs utilized.
> > + default: [0x0001000 0x0002000 0x0004000 0x0008000
> > + 0x0010000 0x0020000 0x0040000 0x0080000
> > + 0x0100000 0x0200000 0x0400000 0x0800000
> > + 0x1000000 0x2000000 0x4000000 0x8000000]
> > + items:
> > + minItems: 16
> > + maxItems: 16
>
> Drop 'items' and move these up a level. That may have given you some
> issues, but I made some fixes recently.
Ok. Thanks.
-Sergey
>
> With that,
>
> Reviewed-by: Rob Herring <robh@kernel.org>
>
> Rob
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sdm845-mtp: enable IPA
From: Alex Elder @ 2020-05-18 21:48 UTC (permalink / raw)
To: bjorn.andersson, agross
Cc: evgreen, subashab, cpratapa, robh+dt, linux-arm-msm, devicetree,
open list
Enable IPA on the SDM845 MTP.
Signed-off-by: Alex Elder <elder@linaro.org>
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 1372fe8601f5..2f942daeb9d1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -448,6 +448,11 @@
clock-frequency = <400000>;
};
+&ipa {
+ status = "okay";
+ modem-init;
+};
+
&mdss {
status = "okay";
};
--
2.20.1
^ permalink raw reply related
* [PATCH] arm64: dts: qcom: sc7180: add IPA information
From: Alex Elder @ 2020-05-18 21:49 UTC (permalink / raw)
To: bjorn.andersson, agross
Cc: evgreen, subashab, cpratapa, robh+dt, linux-arm-msm, devicetree,
open list
Add IPA-related nodes and definitions to "sc7180.dtsi".
Signed-off-by: Alex Elder <elder@linaro.org>
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 51 ++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index f1280e00b064..9a3686ce73ea 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -461,6 +461,17 @@
interrupt-controller;
#interrupt-cells = <2>;
};
+
+ ipa_smp2p_out: ipa-ap-to-modem {
+ qcom,entry-name = "ipa";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ ipa_smp2p_in: ipa-modem-to-ap {
+ qcom,entry-name = "ipa";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
};
psci {
@@ -1007,6 +1018,46 @@
qcom,bcm-voters = <&apps_bcm_voter>;
};
+ ipa: ipa@1e40000 {
+ compatible = "qcom,sc7180-ipa";
+
+ iommus = <&apps_smmu 0x440 0x3>;
+ reg = <0 0x1e40000 0 0x7000>,
+ <0 0x1e47000 0 0x2000>,
+ <0 0x1e04000 0 0x2c000>;
+ reg-names = "ipa-reg",
+ "ipa-shared",
+ "gsi";
+
+ interrupts-extended = <&intc 0 311 IRQ_TYPE_EDGE_RISING>,
+ <&intc 0 432 IRQ_TYPE_LEVEL_HIGH>,
+ <&ipa_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&ipa_smp2p_in 1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ipa",
+ "gsi",
+ "ipa-clock-query",
+ "ipa-setup-ready";
+
+ clocks = <&rpmhcc RPMH_IPA_CLK>;
+ clock-names = "core";
+
+ interconnects = <&aggre2_noc MASTER_IPA &mc_virt SLAVE_EBI1>,
+ <&aggre2_noc MASTER_IPA &system_noc SLAVE_IMEM>,
+ <&gem_noc MASTER_APPSS_PROC &config_noc SLAVE_IPA_CFG>;
+ interconnect-names = "memory",
+ "imem",
+ "config";
+
+ qcom,smem-states = <&ipa_smp2p_out 0>,
+ <&ipa_smp2p_out 1>;
+ qcom,smem-state-names = "ipa-clock-enabled-valid",
+ "ipa-clock-enabled";
+
+ modem-remoteproc = <&remoteproc_mpss>;
+
+ status = "disabled";
+ };
+
tcsr_mutex_regs: syscon@1f40000 {
compatible = "syscon";
reg = <0 0x01f40000 0 0x40000>;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: spi: Add Baikal-T1 System Boot SPI Controller binding
From: Serge Semin @ 2020-05-18 21:55 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Mark Brown, Ramil Zaripov, Alexey Malahov,
Thomas Bogendoerfer, Paul Burton, Ralf Baechle, John Garry,
Chuanhong Guo, Tomer Maimon, Lee Jones, Miquel Raynal,
Arnd Bergmann, linux-mips, linux-spi, devicetree, linux-kernel
In-Reply-To: <20200518152659.GA2525@bogus>
On Mon, May 18, 2020 at 09:26:59AM -0600, Rob Herring wrote:
> On Fri, May 08, 2020 at 12:36:20PM +0300, Serge Semin wrote:
> > Baikal-T1 Boot SPI is a part of the SoC System Controller and is
> > responsible for the system bootup from an external SPI flash. It's a DW
> > APB SSI-based SPI-controller with no interrupts, no DMA, with just one
> > native chip-select available and a single reference clock. Since Baikal-T1
> > SoC is normally booted up from an external SPI flash this SPI controller
> > in most of the cases is supposed to be connected to a single SPI-nor
> > flash. Additionally in order to provide a transparent from CPU point of
> > view initial code execution procedure the system designers created an IP
> > block which physically maps the SPI flash found at CS0 to a memory region.
BTW Rob, could you also provide your review for the next patch:
https://lore.kernel.org/linux-mips/20200515104758.6934-20-Sergey.Semin@baikalelectronics.ru/
?
We agreed with Mark to merge this driver into the generic DW APB SSI code so to
be available for another platforms. Since our DW APB SSI IP's got too many
peculiarities I'll have to provide a new compatible string. It would be great to
add it into the DW schema binding instead of currently available text-based
legacy binding file.
[nip]
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Shanghai Awinic Technology Co., Ltd.
From: Rob Herring @ 2020-05-18 22:14 UTC (permalink / raw)
To: nikitos.tr
Cc: dmurphy, robh+dt, linux-kernel, pavel, linux-leds, devicetree,
~postmarketos/upstreaming
In-Reply-To: <20200511111128.16210-1-nikitos.tr@gmail.com>
On Mon, 11 May 2020 16:11:26 +0500, wrote:
> From: Nikita Travkin <nikitos.tr@gmail.com>
>
> Add the "awinic" vendor prefix for Shanghai Awinic Technology Co., Ltd.
> Website: https://www.awinic.com/
>
> Signed-off-by: Nikita Travkin <nikitos.tr@gmail.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox